* Re: [RFC PATCH v3 02/12] powerpc/book3s: Introduce exclusive emergency stack for machine check exception.
From: Paul Mackerras @ 2013-09-09 4:30 UTC (permalink / raw)
To: Mahesh J Salgaonkar; +Cc: linuxppc-dev, Jeremy Kerr, Anton Blanchard
In-Reply-To: <20130826193132.2855.85275.stgit@mars>
On Tue, Aug 27, 2013 at 01:01:32AM +0530, Mahesh J Salgaonkar wrote:
> From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>
> This patch introduces exclusive emergency stack for machine check exception.
> We use emergency stack to handle machine check exception so that we can save
> MCE information (srr1, srr0, dar and dsisr) before turning on ME bit and be
> ready for re-entrancy. This helps us to prevent clobbering of MCE information
> in case of nested machine checks.
>
> The reason for using emergency stack over normal kernel stack is that the
> machine check might occur in the middle of setting up a stack frame which may
> result into improper use of kernel stack.
>
> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Acked-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: [RFC PATCH v3 01/12] powerpc/book3s: Split the common exception prolog logic into two section.
From: Paul Mackerras @ 2013-09-09 4:29 UTC (permalink / raw)
To: Mahesh J Salgaonkar; +Cc: linuxppc-dev, Jeremy Kerr, Anton Blanchard
In-Reply-To: <20130826193124.2855.96419.stgit@mars>
On Tue, Aug 27, 2013 at 01:01:24AM +0530, Mahesh J Salgaonkar wrote:
> From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>
> This patch splits the common exception prolog logic into two parts to
> facilitate reuse of existing code in the next patch. The second part will
> be reused in the machine check exception routine in the next patch.
>
> Please note that this patch does not introduce or change existing code
> logic. Instead it is just a code movement.
Looks OK. Note however that the diff would be a lot smaller if you
had put EXCEPTION_PROLOG_COMMON_2 after EXCEPTION_PROLOG_COMMON instead
of before it.
Acked-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* RE: [PATCH V3 2/2] powerpc/85xx: Add TWR-P1025 board support
From: Liu Shengzhou-B36685 @ 2013-09-09 3:57 UTC (permalink / raw)
To: Xie Xiaobo-R63061, Wood Scott-B07421
Cc: Johnston Michael-R49610, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <69EC9ED88E3CC04094A78F8074A7986D5D23CE@039-SN1MPN1-003.039d.mgd.msft.net>
Xiaobo,
You can use interrupts =3D <1 1 0 0> instead of interrupts =3D <1 1> with t=
est on P1025twr.
It was mislead by hardware issue on p1010rdb-pb board.
Regards,
Shengzhou
> -----Original Message-----
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+shengzhou.liu=3Dfreescale.com@lists.ozlabs.org] On Behalf Of Xie =
Xiaobo-
> R63061
> Sent: Friday, September 06, 2013 6:01 PM
> To: Wood Scott-B07421
> Cc: Johnston Michael-R49610; linuxppc-dev@lists.ozlabs.org
> Subject: RE: [PATCH V3 2/2] powerpc/85xx: Add TWR-P1025 board support
>=20
> Hi Scott,
>=20
> Thanks for your reminding and advice.
>=20
> I discuss this with Liu Shengzhou(the first person that remind me #interr=
upt-
> cells is 4), he advised removing the interrupts property from the phy nod=
e,
> because the mdio used the poll way preferentially.
>=20
> Best Regards
> Xie Xiaobo
>=20
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Thursday, September 05, 2013 12:26 AM
> To: Xie Xiaobo-R63061
> Cc: linuxppc-dev@lists.ozlabs.org; galak@kernel.crashing.org; Johnston Mi=
chael-
> R49610
> Subject: Re: [PATCH V3 2/2] powerpc/85xx: Add TWR-P1025 board support
>=20
> On Mon, 2013-09-02 at 18:11 +0800, Xie Xiaobo wrote:
> > +&soc {
> > + usb@22000 {
> > + phy_type =3D "ulpi";
> > + };
> > +
> > + mdio@24000 {
> > + phy0: ethernet-phy@2 {
> > + interrupt-parent =3D <&mpic>;
> > + interrupts =3D <1 1>;
> > + reg =3D <0x2>;
> > + };
> > +
> > + phy1: ethernet-phy@1 {
> > + interrupt-parent =3D <&mpic>;
> > + interrupts =3D <2 1>;
> > + reg =3D <0x1>;
> > + };
>=20
> Again, #interrupt-cells is 4.
>=20
> Please respond to feedback rather than ignoring it and reposting the same=
thing
> without comment.
>=20
> -Scott
>=20
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH V3] powerpc: Add I2C bus multiplexer node for B4 and T4240QDS
From: Jia Hongtao @ 2013-09-09 1:41 UTC (permalink / raw)
To: linuxppc-dev, galak, B07421; +Cc: hongtao.jia, Wei.Yang
In both B4 and T4240QDS platform PCA9547 I2C bus multiplexer is used.
The sub-nodes are also reorganized according to right I2C topology.
Signed-off-by: Jia Hongtao <hongtao.jia@freescale.com>
---
V3 change log:
* change "channel" to "i2c" based on i2c-mux binding.
V2 change log:
* Reorganized the sub-nodes under I2C multiplexer to represent right topology.
arch/powerpc/boot/dts/b4qds.dtsi | 51 +++++++++++++++++-----------
arch/powerpc/boot/dts/t4240qds.dts | 69 ++++++++++++++++++++++----------------
2 files changed, 73 insertions(+), 47 deletions(-)
diff --git a/arch/powerpc/boot/dts/b4qds.dtsi b/arch/powerpc/boot/dts/b4qds.dtsi
index e6d2f8f..e2ab6cb 100644
--- a/arch/powerpc/boot/dts/b4qds.dtsi
+++ b/arch/powerpc/boot/dts/b4qds.dtsi
@@ -120,25 +120,38 @@
};
i2c@118000 {
- eeprom@50 {
- compatible = "at24,24c64";
- reg = <0x50>;
- };
- eeprom@51 {
- compatible = "at24,24c256";
- reg = <0x51>;
- };
- eeprom@53 {
- compatible = "at24,24c256";
- reg = <0x53>;
- };
- eeprom@57 {
- compatible = "at24,24c256";
- reg = <0x57>;
- };
- rtc@68 {
- compatible = "dallas,ds3232";
- reg = <0x68>;
+ mux@77 {
+ compatible = "philips,pca9547";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ eeprom@50 {
+ compatible = "at24,24c64";
+ reg = <0x50>;
+ };
+ eeprom@51 {
+ compatible = "at24,24c256";
+ reg = <0x51>;
+ };
+ eeprom@53 {
+ compatible = "at24,24c256";
+ reg = <0x53>;
+ };
+ eeprom@57 {
+ compatible = "at24,24c256";
+ reg = <0x57>;
+ };
+ rtc@68 {
+ compatible = "dallas,ds3232";
+ reg = <0x68>;
+ };
+ };
};
};
diff --git a/arch/powerpc/boot/dts/t4240qds.dts b/arch/powerpc/boot/dts/t4240qds.dts
index 0555976..b354af5 100644
--- a/arch/powerpc/boot/dts/t4240qds.dts
+++ b/arch/powerpc/boot/dts/t4240qds.dts
@@ -118,34 +118,47 @@
};
i2c@118000 {
- eeprom@51 {
- compatible = "at24,24c256";
- reg = <0x51>;
- };
- eeprom@52 {
- compatible = "at24,24c256";
- reg = <0x52>;
- };
- eeprom@53 {
- compatible = "at24,24c256";
- reg = <0x53>;
- };
- eeprom@54 {
- compatible = "at24,24c256";
- reg = <0x54>;
- };
- eeprom@55 {
- compatible = "at24,24c256";
- reg = <0x55>;
- };
- eeprom@56 {
- compatible = "at24,24c256";
- reg = <0x56>;
- };
- rtc@68 {
- compatible = "dallas,ds3232";
- reg = <0x68>;
- interrupts = <0x1 0x1 0 0>;
+ mux@77 {
+ compatible = "philips,pca9547";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ eeprom@51 {
+ compatible = "at24,24c256";
+ reg = <0x51>;
+ };
+ eeprom@52 {
+ compatible = "at24,24c256";
+ reg = <0x52>;
+ };
+ eeprom@53 {
+ compatible = "at24,24c256";
+ reg = <0x53>;
+ };
+ eeprom@54 {
+ compatible = "at24,24c256";
+ reg = <0x54>;
+ };
+ eeprom@55 {
+ compatible = "at24,24c256";
+ reg = <0x55>;
+ };
+ eeprom@56 {
+ compatible = "at24,24c256";
+ reg = <0x56>;
+ };
+ rtc@68 {
+ compatible = "dallas,ds3232";
+ reg = <0x68>;
+ interrupts = <0x1 0x1 0 0>;
+ };
+ };
};
};
};
--
1.8.0
^ permalink raw reply related
* RE: [PATCH V2] powerpc: Add I2C bus multiplexer node for B4 and T4240QDS
From: Jia Hongtao-B38951 @ 2013-09-09 1:34 UTC (permalink / raw)
To: Kumar Gala
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
Wei.Yang@windriver.com
In-Reply-To: <AC1DB807-91FA-41F6-8468-371E02F41D35@kernel.crashing.org>
Great thanks.
I will update the patch and send it soon.
-Hongtao
> -----Original Message-----
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+b38951=3Dfreescale.com@lists.ozlabs.org] On Behalf Of Kumar Gala
> Sent: Saturday, September 07, 2013 12:10 AM
> To: Jia Hongtao-B38951
> Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org;
> Wei.Yang@windriver.com
> Subject: Re: [PATCH V2] powerpc: Add I2C bus multiplexer node for B4 and
> T4240QDS
>=20
>=20
> On Sep 5, 2013, at 10:33 PM, Jia Hongtao-B38951 wrote:
>=20
> >> -----Original Message-----
> >> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> >> Sent: Friday, September 06, 2013 2:41 AM
> >> To: Jia Hongtao-B38951
> >> Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421;
> >> Wei.Yang@windriver.com
> >> Subject: Re: [PATCH V2] powerpc: Add I2C bus multiplexer node for B4
> >> and T4240QDS
> >>
> >>
> >> On Sep 4, 2013, at 9:41 PM, Jia Hongtao wrote:
> >>
> >>> In both B4 and T4240QDS platform PCA9547 I2C bus multiplexer is used.
> >>> The sub-nodes are also reorganized according to right I2C topology.
> >>>
> >>> Signed-off-by: Jia Hongtao <hongtao.jia@freescale.com>
> >>> ---
> >>> V2 change log:
> >>> Reorganized the sub-nodes under I2C multiplexer to represent right
> >> topology.
> >>>
> >>> arch/powerpc/boot/dts/b4qds.dtsi | 49 +++++++++++++++++-----------
> >>> arch/powerpc/boot/dts/t4240qds.dts | 67
> >>> ++++++++++++++++++++++---------
> >> -------
> >>> 2 files changed, 69 insertions(+), 47 deletions(-)
> >>>
> >>> diff --git a/arch/powerpc/boot/dts/b4qds.dtsi
> >> b/arch/powerpc/boot/dts/b4qds.dtsi
> >>> index e6d2f8f..de8cb38 100644
> >>> --- a/arch/powerpc/boot/dts/b4qds.dtsi
> >>> +++ b/arch/powerpc/boot/dts/b4qds.dtsi
> >>> @@ -120,25 +120,36 @@
> >>> };
> >>>
> >>> i2c@118000 {
> >>> - eeprom@50 {
> >>> - compatible =3D "at24,24c64";
> >>> - reg =3D <0x50>;
> >>> - };
> >>> - eeprom@51 {
> >>> - compatible =3D "at24,24c256";
> >>> - reg =3D <0x51>;
> >>> - };
> >>> - eeprom@53 {
> >>> - compatible =3D "at24,24c256";
> >>> - reg =3D <0x53>;
> >>> - };
> >>> - eeprom@57 {
> >>> - compatible =3D "at24,24c256";
> >>> - reg =3D <0x57>;
> >>> - };
> >>> - rtc@68 {
> >>> - compatible =3D "dallas,ds3232";
> >>> - reg =3D <0x68>;
> >>> + pca9547@77 {
> >>> + compatible =3D "philips,pca9547";
> >>
> >> We seem to be using nxp instead of philips now.
>=20
> This is based on Documentation/devicetree/bindings/vendor-prefixes.txt
>=20
> >>
> >>> + reg =3D <0x77>;
> >>> + #address-cells =3D <1>;
> >>> + #size-cells =3D <0>;
> >>> + channel@0 {
> >>
> >> channel should probably be i2c
> >
> >
> > Is there any standard for the name?
> > i2c is ok but I think channel is more intuitional.
> >
> > Hi Scott,
> > What do you think of it.
>=20
> Basing my comments on Documentation/devicetree/bindings/i2c/i2c-mux.txt
>=20
>=20
> >
> > Thanks.
> > -Hongtao
> >
> >
> >>
> >> [same comments below]
> >>
> >>> + #address-cells =3D <1>;
> >>> + #size-cells =3D <0>;
> >>> + reg =3D <0>;
> >>> + eeprom@50 {
> >>> + compatible =3D "at24,24c64";
> >>> + reg =3D <0x50>;
> >>> + };
> >>> + eeprom@51 {
> >>> + compatible =3D "at24,24c256";
> >>> + reg =3D <0x51>;
> >>> + };
> >>> + eeprom@53 {
> >>> + compatible =3D "at24,24c256";
> >>> + reg =3D <0x53>;
> >>> + };
> >>> + eeprom@57 {
> >>> + compatible =3D "at24,24c256";
> >>> + reg =3D <0x57>;
> >>> + };
> >>> + rtc@68 {
> >>> + compatible =3D "dallas,ds3232";
> >>> + reg =3D <0x68>;
> >>> + };
> >>> + };
> >>> };
> >>> };
> >>>
> >>> diff --git a/arch/powerpc/boot/dts/t4240qds.dts
> >> b/arch/powerpc/boot/dts/t4240qds.dts
> >>> index 0555976..ae68595 100644
> >>> --- a/arch/powerpc/boot/dts/t4240qds.dts
> >>> +++ b/arch/powerpc/boot/dts/t4240qds.dts
> >>> @@ -118,34 +118,45 @@
> >>> };
> >>>
> >>> i2c@118000 {
> >>> - eeprom@51 {
> >>> - compatible =3D "at24,24c256";
> >>> - reg =3D <0x51>;
> >>> - };
> >>> - eeprom@52 {
> >>> - compatible =3D "at24,24c256";
> >>> - reg =3D <0x52>;
> >>> - };
> >>> - eeprom@53 {
> >>> - compatible =3D "at24,24c256";
> >>> - reg =3D <0x53>;
> >>> - };
> >>> - eeprom@54 {
> >>> - compatible =3D "at24,24c256";
> >>> - reg =3D <0x54>;
> >>> - };
> >>> - eeprom@55 {
> >>> - compatible =3D "at24,24c256";
> >>> - reg =3D <0x55>;
> >>> - };
> >>> - eeprom@56 {
> >>> - compatible =3D "at24,24c256";
> >>> - reg =3D <0x56>;
> >>> - };
> >>> - rtc@68 {
> >>> - compatible =3D "dallas,ds3232";
> >>> - reg =3D <0x68>;
> >>> - interrupts =3D <0x1 0x1 0 0>;
> >>> + pca9547@77 {
> >>> + compatible =3D "philips,pca9547";
> >>> + reg =3D <0x77>;
> >>> + #address-cells =3D <1>;
> >>> + #size-cells =3D <0>;
> >>> + channel@0 {
> >>> + #address-cells =3D <1>;
> >>> + #size-cells =3D <0>;
> >>> + reg =3D <0>;
> >>> + eeprom@51 {
> >>> + compatible =3D "at24,24c256";
> >>> + reg =3D <0x51>;
> >>> + };
> >>> + eeprom@52 {
> >>> + compatible =3D "at24,24c256";
> >>> + reg =3D <0x52>;
> >>> + };
> >>> + eeprom@53 {
> >>> + compatible =3D "at24,24c256";
> >>> + reg =3D <0x53>;
> >>> + };
> >>> + eeprom@54 {
> >>> + compatible =3D "at24,24c256";
> >>> + reg =3D <0x54>;
> >>> + };
> >>> + eeprom@55 {
> >>> + compatible =3D "at24,24c256";
> >>> + reg =3D <0x55>;
> >>> + };
> >>> + eeprom@56 {
> >>> + compatible =3D "at24,24c256";
> >>> + reg =3D <0x56>;
> >>> + };
> >>> + rtc@68 {
> >>> + compatible =3D "dallas,ds3232";
> >>> + reg =3D <0x68>;
> >>> + interrupts =3D <0x1 0x1 0 0>;
> >>> + };
> >>> + };
> >>> };
> >>> };
> >>> };
> >>> --
> >>> 1.8.0
> >>>
> >>>
> >>> _______________________________________________
> >>> Linuxppc-dev mailing list
> >>> Linuxppc-dev@lists.ozlabs.org
> >>> https://lists.ozlabs.org/listinfo/linuxppc-dev
> >>
> >
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* powerpc allmodconfig build broken due to commit 15863ff3b (powerpc: Make chip-id information available to userspace)
From: Guenter Roeck @ 2013-09-09 0:28 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org
Cc: Vasant Hegde, Shivaprasad G Bhat, linuxppc-dev, Paul Mackerras
Hi all,
powerpc allmodconfig build on the latest upstream kernel results in:
ERROR: ".cpu_to_chip_id" [drivers/block/mtip32xx/mtip32xx.ko] undefined!
This is due to commit 15863ff3b (powerpc: Make chip-id information available to userspace).
Not surprising, as cpu_to_chip_id() is not exported.
Reverting this commit fixes the problem. Any good idea how to fix it for real ?
Guenter
^ permalink raw reply
* Re: [PATCH] powerpc: OE=1 Form Instructions Not Decoded Correctly
From: Paul Mackerras @ 2013-09-08 22:35 UTC (permalink / raw)
To: Tom Musta; +Cc: linuxppc-dev
In-Reply-To: <CAJ-hshaxuJBMCFquT7J50rjuDYWer_0i1=2QmnOKGAxx4n=FUw@mail.gmail.com>
On Fri, Sep 06, 2013 at 10:13:00AM -0500, Tom Musta wrote:
> To: linuxppc-dev@lists.ozlabs.org
> Subject: [PATCH] powerpc: OE=1 Form Instructions Not Decoded Correctly
> From: Tom Musta <tommusta@gmail.com>
>
> PowerISA uses instruction bit 21 to indicate that the overflow (OV) bit
> of the XER is to be set, as well as its corresponding sticky bit (SO).
> This patch addresses two defects in the implementation of the PowerISA
> single step code for this category of instructions: (a) the OE=1 case
> is not correctly accounted for in the case statement for the extended
> opcode handling. (b) the implementation is not setting XER[OV] and
> XER[SO].
Are you seeing any actual problems arising from the OE=1 instructions
not being emulated? This code was designed primarily for emulating
instructions in the kernel, which is written in C, and the C compiler
doesn't emit OE=1 instructions -- or at least it didn't in the past.
So, does the impetus for this change come because the C compiler is
now emitting these instructions, or because this code is being used on
non-kernel instructions, or just for completeness? Your patch
description needs to include answers to these kinds of questions.
Also, you need to indent your code correctly according to
Documentation/CodingStyle.
Paul.
^ permalink raw reply
* Re: [PATCH v4 12/19] cpufreq: cpufreq-cpu0: remove device tree parsing for cpu nodes
From: Guennadi Liakhovetski @ 2013-09-06 13:44 UTC (permalink / raw)
To: Sudeep KarkadaNagesha
Cc: Jonas Bonn, devicetree, Michal Simek, linux-pm, Viresh Kumar,
linux-kernel, Rob Herring, Rafael J. Wysocki, Greg Kroah-Hartman,
Grant Likely, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1376991021-12160-13-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Hi
On Tue, 20 Aug 2013, Sudeep KarkadaNagesha wrote:
> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
>
> Now that the cpu device registration initialises the of_node(if available)
> appropriately for all the cpus, parsing here is redundant.
>
> This patch removes all DT parsing and uses cpu->of_node instead.
>
> Acked-by: Shawn Guo <shawn.guo@linaro.org>
> Acked-by: Rob Herring <rob.herring@calxeda.com>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
> ---
> drivers/cpufreq/cpufreq-cpu0.c | 23 ++++-------------------
> 1 file changed, 4 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.=
> c
> index ad1fde2..5b05c26 100644
> --- a/drivers/cpufreq/cpufreq-cpu0.c
> +++ b/drivers/cpufreq/cpufreq-cpu0.c
> @@ -174,29 +174,17 @@ static struct cpufreq_driver cpu0_cpufreq_driver =3D =
> {
> =20
> static int cpu0_cpufreq_probe(struct platform_device *pdev)
> {
> -=09struct device_node *np, *parent;
> +=09struct device_node *np;
> =09int ret;
> =20
> -=09parent =3D of_find_node_by_path("/cpus");
> -=09if (!parent) {
> -=09=09pr_err("failed to find OF /cpus\n");
> -=09=09return -ENOENT;
> -=09}
> -
> -=09for_each_child_of_node(parent, np) {
> -=09=09if (of_get_property(np, "operating-points", NULL))
> -=09=09=09break;
> -=09}
> +=09cpu_dev =3D &pdev->dev;
> =20
> +=09np =3D of_node_get(cpu_dev->of_node);
Has this actually been tested? This seems to break cpufreq-cpu0. The
reason is, that this probe function is called not for the DT CPU node, but
for a special virtual cpufreq-cpu0 platform device, typically created by
platforms, using
platform_device_register_simple("cpufreq-cpu0", -1, NULL, 0);
which then of course doesn't have on .of_node associated with it.
Thanks
Guennadi
> =09if (!np) {
> =09=09pr_err("failed to find cpu0 node\n");
> -=09=09ret =3D -ENOENT;
> -=09=09goto out_put_parent;
> +=09=09return -ENOENT;
> =09}
> =20
> -=09cpu_dev =3D &pdev->dev;
> -=09cpu_dev->of_node =3D np;
> -
> =09cpu_reg =3D devm_regulator_get(cpu_dev, "cpu0");
> =09if (IS_ERR(cpu_reg)) {
> =09=09/*
> @@ -269,15 +257,12 @@ static int cpu0_cpufreq_probe(struct platform_device =
> *pdev)
> =09}
> =20
> =09of_node_put(np);
> -=09of_node_put(parent);
> =09return 0;
> =20
> out_free_table:
> =09opp_free_cpufreq_table(cpu_dev, &freq_table);
> out_put_node:
> =09of_node_put(np);
> -out_put_parent:
> -=09of_node_put(parent);
> =09return ret;
> }
> =20
> --=20
> 1.8.1.2
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH v10 12/13] KVM: PPC: Add support for IOMMU in-kernel handling
From: Gleb Natapov @ 2013-09-08 14:12 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: kvm, Alexander Graf, kvm-ppc, linux-kernel, Paul Mackerras,
linuxppc-dev, David Gibson
In-Reply-To: <1378464026-32459-1-git-send-email-aik@ozlabs.ru>
On Fri, Sep 06, 2013 at 08:40:26PM +1000, Alexey Kardashevskiy wrote:
> This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT
> and H_STUFF_TCE requests targeted an IOMMU TCE table without passing
> them to user space which saves time on switching to user space and back.
>
> Both real and virtual modes are supported. The kernel tries to
> handle a TCE request in the real mode, if fails it passes the request
> to the virtual mode to complete the operation. If it a virtual mode
> handler fails, the request is passed to user space.
>
> The first user of this is VFIO on POWER. Trampolines to the VFIO external
> user API functions are required for this patch.
>
> This adds a "SPAPR TCE IOMMU" KVM device to associate a logical bus
> number (LIOBN) with an VFIO IOMMU group fd and enable in-kernel handling
> of map/unmap requests. The device supports a single attribute which is
> a struct with LIOBN and IOMMU fd. When the attribute is set, the device
> establishes the connection between KVM and VFIO.
>
> Tests show that this patch increases transmission speed from 220MB/s
> to 750..1020MB/s on 10Gb network (Chelsea CXGB3 10Gb ethernet card).
>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>
> ---
>
> Changes:
> v10:
> * all IOMMU TCE links are handled by one KVM device now
> * KVM device has its own list of TCE descriptors
> * the search-by-liobn function was extended to search through
> emulated and IOMMU lists
>
> v9:
> * KVM_CAP_SPAPR_TCE_IOMMU ioctl to KVM replaced with "SPAPR TCE IOMMU"
> KVM device
> * release_spapr_tce_table() is not shared between different TCE types
> * reduced the patch size by moving KVM device bits and VFIO external API
> trampolines to separate patches
> * moved documentation from Documentation/virtual/kvm/api.txt to
> Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
>
> v8:
> * fixed warnings from check_patch.pl
>
> 2013/07/11:
> * removed multiple #ifdef IOMMU_API as IOMMU_API is always enabled
> for KVM_BOOK3S_64
> * kvmppc_gpa_to_hva_and_get also returns host phys address. Not much sense
> for this here but the next patch for hugepages support will use it more.
>
> 2013/07/06:
> * added realmode arch_spin_lock to protect TCE table from races
> in real and virtual modes
> * POWERPC IOMMU API is changed to support real mode
> * iommu_take_ownership and iommu_release_ownership are protected by
> iommu_table's locks
> * VFIO external user API use rewritten
> * multiple small fixes
>
> 2013/06/27:
> * tce_list page is referenced now in order to protect it from accident
> invalidation during H_PUT_TCE_INDIRECT execution
> * added use of the external user VFIO API
>
> 2013/06/05:
> * changed capability number
> * changed ioctl number
> * update the doc article number
>
> 2013/05/20:
> * removed get_user() from real mode handlers
> * kvm_vcpu_arch::tce_tmp usage extended. Now real mode handler puts there
> translated TCEs, tries realmode_get_page() on those and if it fails, it
> passes control over the virtual mode handler which tries to finish
> the request handling
> * kvmppc_lookup_pte() now does realmode_get_page() protected by BUSY bit
> on a page
> * The only reason to pass the request to user mode now is when the user mode
> did not register TCE table in the kernel, in all other cases the virtual mode
> handler is expected to do the job
> ---
> .../virtual/kvm/devices/spapr_tce_iommu.txt | 40 +++
> arch/powerpc/include/asm/kvm_host.h | 8 +
> arch/powerpc/include/uapi/asm/kvm.h | 5 -
> arch/powerpc/kvm/book3s_64_vio.c | 327 ++++++++++++++++++++-
> arch/powerpc/kvm/book3s_64_vio_hv.c | 142 +++++++++
> arch/powerpc/kvm/powerpc.c | 1 +
> include/linux/kvm_host.h | 1 +
> virt/kvm/kvm_main.c | 5 +
> 8 files changed, 517 insertions(+), 12 deletions(-)
> create mode 100644 Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
>
> diff --git a/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt b/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
> new file mode 100644
> index 0000000..b911945
> --- /dev/null
> +++ b/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
> @@ -0,0 +1,40 @@
> +SPAPR TCE IOMMU device
> +
> +Capability: KVM_CAP_SPAPR_TCE_IOMMU
> +Architectures: powerpc
> +
> +Device type supported: KVM_DEV_TYPE_SPAPR_TCE_IOMMU
> +
> +Groups:
> + KVM_DEV_SPAPR_TCE_IOMMU_ATTR_LINKAGE
> + Attributes: one VFIO IOMMU fd per LIOBN, indexed by LIOBN
> +
> +This is completely made up device which provides API to link
> +logical bus number (LIOBN) and IOMMU group. The user space has
> +to create a new SPAPR TCE IOMMU device once per KVM session
> +and use "set_attr" to add or remove a logical bus.
> +
> +LIOBN is a PCI bus identifier from PPC64-server (sPAPR) DMA hypercalls
> +(H_PUT_TCE, H_PUT_TCE_INDIRECT, H_STUFF_TCE).
> +IOMMU group is a minimal isolated device set which can be passed to
> +the user space via VFIO.
> +
> +The userspace adds the new LIOBN-IOMMU link by calling KVM_SET_DEVICE_ATTR
> +with the attribute initialized as shown below:
> +struct kvm_device_attr attr = {
> + .flags = 0,
> + .group = KVM_DEV_SPAPR_TCE_IOMMU_ATTR_LINKAGE,
> + .attr = liobn,
> + .addr = (uint64_t)(uintptr_t)&group_fd,
> +};
> +
> +To remove the link, the userspace calls KVM_SET_DEVICE_ATTR with
> +the group_fd equal to zero.
> +
Zero is a valid fd descriptor. Lest make it -1.
> +As the device opens VFIO group fds and holds the file pointer,
> +it does not need to keep an fd internally and therefore KVM_GET_DEVICE_ATTR
> +is not supported.
> +
> +When KVM exits, all links are destroyed automatically.
> +
> +The kernel advertises this feature via KVM_CAP_SPAPR_TCE_IOMMU capability.
Why KVM_CAP_SPAPR_TCE_IOMMU is needed? Supported devices are
discoverable without capabilities.
> diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
> index a23f132..a2a481e 100644
> --- a/arch/powerpc/include/asm/kvm_host.h
> +++ b/arch/powerpc/include/asm/kvm_host.h
> @@ -181,9 +181,15 @@ struct kvmppc_spapr_tce_table {
> struct kvm *kvm;
> u64 liobn;
> u32 window_size;
> + struct iommu_group *grp; /* used for IOMMU groups */
> + struct vfio_group *vfio_grp; /* used for IOMMU groups */
> struct page *pages[0];
> };
>
> +struct kvmppc_spapr_tce_iommu_device {
> + struct list_head tables;
> +};
> +
> struct kvmppc_linear_info {
> void *base_virt;
> unsigned long base_pfn;
> @@ -264,6 +270,7 @@ struct kvm_arch {
> #endif /* CONFIG_KVM_BOOK3S_64_HV */
> #ifdef CONFIG_PPC_BOOK3S_64
> struct list_head spapr_tce_tables;
> + struct kvmppc_spapr_tce_iommu_device *tcedev;
> struct list_head rtas_tokens;
> #endif
> #ifdef CONFIG_KVM_MPIC
> @@ -612,6 +619,7 @@ struct kvm_vcpu_arch {
> u64 busy_preempt;
>
> unsigned long *tce_tmp_hpas; /* TCE cache for TCE_PUT_INDIRECT */
> + unsigned long tce_tmp_num; /* Number of handled TCEs in cache */
> enum {
> TCERM_NONE,
> TCERM_GETPAGE,
> diff --git a/arch/powerpc/include/uapi/asm/kvm.h b/arch/powerpc/include/uapi/asm/kvm.h
> index c1ae1e5..a9d3d73 100644
> --- a/arch/powerpc/include/uapi/asm/kvm.h
> +++ b/arch/powerpc/include/uapi/asm/kvm.h
> @@ -512,11 +512,6 @@ struct kvm_get_htab_header {
> #define KVM_XICS_PENDING (1ULL << 42)
>
> /* SPAPR TCE IOMMU device specification */
> -struct kvm_create_spapr_tce_iommu_linkage {
> - __u64 liobn;
> - __u32 fd;
> - __u32 flags;
> -};
> #define KVM_DEV_SPAPR_TCE_IOMMU_ATTR_LINKAGE 0
>
> #endif /* __LINUX_KVM_POWERPC_H */
> diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
> index 2880d2b..0978794 100644
> --- a/arch/powerpc/kvm/book3s_64_vio.c
> +++ b/arch/powerpc/kvm/book3s_64_vio.c
> @@ -29,6 +29,8 @@
> #include <linux/anon_inodes.h>
> #include <linux/module.h>
> #include <linux/vfio.h>
> +#include <linux/iommu.h>
> +#include <linux/file.h>
>
> #include <asm/tlbflush.h>
> #include <asm/kvm_ppc.h>
> @@ -158,10 +160,8 @@ long kvm_vm_ioctl_create_spapr_tce(struct kvm *kvm,
> int i;
>
> /* Check this LIOBN hasn't been previously allocated */
> - list_for_each_entry(stt, &kvm->arch.spapr_tce_tables, list) {
> - if (stt->liobn == args->liobn)
> - return -EBUSY;
> - }
> + if (kvmppc_find_tce_table(kvm, args->liobn))
> + return -EBUSY;
>
> npages = kvmppc_stt_npages(args->window_size);
>
> @@ -201,9 +201,175 @@ fail:
> return ret;
> }
>
> -/* Converts guest physical address to host virtual address */
> +static void kvmppc_spapr_tce_iommu_table_destroy(
> + struct kvm_device *dev,
> + struct kvmppc_spapr_tce_table *tt)
> +{
> + struct kvm *kvm = dev->kvm;
> +
> + mutex_lock(&kvm->lock);
> + list_del(&tt->list);
> +
> + if (tt->vfio_grp)
> + kvmppc_vfio_group_put_external_user(tt->vfio_grp);
> + iommu_group_put(tt->grp);
> +
> + kfree(tt);
> + mutex_unlock(&kvm->lock);
> +}
> +
> +static int kvmppc_spapr_tce_iommu_create(struct kvm_device *dev, u32 type)
> +{
> + struct kvmppc_spapr_tce_iommu_device *tcedev;
> + int ret = 0;
> +
> + tcedev = kzalloc(sizeof(*tcedev), GFP_KERNEL);
> + if (!tcedev)
> + return -ENOMEM;
> + dev->private = tcedev;
> +
> + INIT_LIST_HEAD(&tcedev->tables);
> +
> + /* Already there ? */
> + mutex_lock(&dev->kvm->lock);
> + if (dev->kvm->arch.tcedev)
> + ret = -EEXIST;
> + else
> + dev->kvm->arch.tcedev = tcedev;
> + mutex_unlock(&dev->kvm->lock);
> +
> + if (ret)
Need to free tcedev here.
> + return ret;
> +
> + return 0;
> +}
> +
--
Gleb.
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git next branch
From: Benjamin Herrenschmidt @ 2013-09-07 7:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, Linux Kernel list
In-Reply-To: <CA+55aFwvPNu6-PHJmDkqihiCgMy=TH_we8LtVKm31teWhmLQPw@mail.gmail.com>
On Fri, 2013-09-06 at 10:56 -0700, Linus Torvalds wrote:
> On Thu, Sep 5, 2013 at 7:24 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> >
> > * A bunch of endian fixes ! We don't have full LE support yet in that
> > release but this contains a lot of fixes all over arch/powerpc to use the
> > proper accessors, call the firmware with the right endian mode, etc...
>
> Ok, this caused a conflict in arch/powerpc/kernel/prom.c, where some
> of the OF CPU number accessors had been moved to generic OF code
> instead.
Ah yes, sorry, I completely forgot to tell you about that ! (I was in a
hurry to leave for the snow :-)
> It *looks* to me like those accessors had already been made
> endian-clean as part of the move to generic code, and so my conflict
> resolution was to just ignore the parts of the changes the code that
> no longer exists in prom.c, but you really should double-check my
> resolution. Maybe I screwed it up.
Ok, yes I had reviewed the new stuff and it should already be endian
safe, so it should be all good, but I'll double check everything as soon
as I'm back.
> But apparent'y the LE mode isn't finished, so hopefully even if I read
> those changes wrong it won't affect you guys too badly. I didn't
> test-compile any of it, yadda yadda..
Yup, that's fine :-) We have a full LE tree internally of course but we
are holding on some of the stuff until we decide what to do with the ABI
(it would be nice to get rid of function descriptors for example) and
fix some more bugs.
So I decided to merge a batch of the "easy" stuff just to get it out of
the way this time around, and hopefully the rest will be spread out
across the next one or two merge windows.
Cheers,
Ben.
> Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH v2 3/6] powerpc/pci: use pci_is_pcie() to simplify code
From: Bjorn Helgaas @ 2013-09-06 20:30 UTC (permalink / raw)
To: Yijing Wang
Cc: Gavin Shan, linux-pci, linux-kernel, James E.J. Bottomley,
Paul Mackerras, Hanjun Guo, linuxppc-dev
In-Reply-To: <1378367730-25996-3-git-send-email-wangyijing@huawei.com>
On Thu, Sep 05, 2013 at 03:55:27PM +0800, Yijing Wang wrote:
> Use pci_is_pcie() to simplify code.
>
> Acked-by: Kumar Gala <galak@kernel.crashing.org>
> Reviewed-by: Gavin Shan <shangw@linux.vnet.ibm.com>
> Signed-off-by: Yijing Wang <wangyijing@huawei.com>
> Cc: Gavin Shan <shangw@linux.vnet.ibm.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-kernel@vger.kernel.org
> ---
> arch/powerpc/kernel/eeh.c | 3 +--
> arch/powerpc/sysdev/fsl_pci.c | 2 +-
> 2 files changed, 2 insertions(+), 3 deletions(-)
Ben, Paul, this has no dependencies on anything new to PCI or any
other patches in this series, so you can take it through the POWERPC
tree. If you don't want to do that, let me know and I can take it.
If you want it:
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
> index 55593ee..6ebbe54 100644
> --- a/arch/powerpc/kernel/eeh.c
> +++ b/arch/powerpc/kernel/eeh.c
> @@ -189,8 +189,7 @@ static size_t eeh_gather_pci_data(struct eeh_dev *edev, char * buf, size_t len)
> }
>
> /* If PCI-E capable, dump PCI-E cap 10, and the AER */
> - cap = pci_find_capability(dev, PCI_CAP_ID_EXP);
> - if (cap) {
> + if (pci_is_pcie(dev)) {
> n += scnprintf(buf+n, len-n, "pci-e cap10:\n");
> printk(KERN_WARNING
> "EEH: PCI-E capabilities and status follow:\n");
> diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
> index 46ac1dd..5402a1d 100644
> --- a/arch/powerpc/sysdev/fsl_pci.c
> +++ b/arch/powerpc/sysdev/fsl_pci.c
> @@ -41,7 +41,7 @@ static void quirk_fsl_pcie_header(struct pci_dev *dev)
> u8 hdr_type;
>
> /* if we aren't a PCIe don't bother */
> - if (!pci_find_capability(dev, PCI_CAP_ID_EXP))
> + if (!pci_is_pcie(dev))
> return;
>
> /* if we aren't in host mode don't bother */
> --
> 1.7.1
>
>
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git next branch
From: Linus Torvalds @ 2013-09-06 17:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Linux Kernel list
In-Reply-To: <1378434264.4321.209.camel@pasglop>
On Thu, Sep 5, 2013 at 7:24 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
>
> * A bunch of endian fixes ! We don't have full LE support yet in that
> release but this contains a lot of fixes all over arch/powerpc to use the
> proper accessors, call the firmware with the right endian mode, etc...
Ok, this caused a conflict in arch/powerpc/kernel/prom.c, where some
of the OF CPU number accessors had been moved to generic OF code
instead.
It *looks* to me like those accessors had already been made
endian-clean as part of the move to generic code, and so my conflict
resolution was to just ignore the parts of the changes the code that
no longer exists in prom.c, but you really should double-check my
resolution. Maybe I screwed it up.
But apparent'y the LE mode isn't finished, so hopefully even if I read
those changes wrong it won't affect you guys too badly. I didn't
test-compile any of it, yadda yadda..
Linus
^ permalink raw reply
* Re: [PATCH V2 2/2] powerpc/85xx: workaround for chips with MSI hardware errata
From: Kumar Gala @ 2013-09-06 16:11 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Jia Hongtao, B07421
In-Reply-To: <1378481816.12204.191.camel@snotra.buserror.net>
On Sep 6, 2013, at 10:36 AM, Scott Wood wrote:
> On Fri, 2013-09-06 at 10:01 -0500, Kumar Gala wrote:
>> On Sep 5, 2013, at 1:37 PM, Scott Wood wrote:
>>=20
>>> On Thu, 2013-09-05 at 13:34 -0500, Kumar Gala wrote:
>>>> On Apr 2, 2013, at 9:03 PM, Jia Hongtao wrote:
>>>>> + msi->feature |=3D MSI_HW_ERRATA_ENDIAN;
>>>>> + }
>>>>> +
>>>>> /*
>>>>> * Remember the phandle, so that we can match with any PCI nodes
>>>>> * that have an "fsl,msi" property.
>>>>> diff --git a/arch/powerpc/sysdev/fsl_msi.h =
b/arch/powerpc/sysdev/fsl_msi.h
>>>>> index 8225f86..7389e8e 100644
>>>>> --- a/arch/powerpc/sysdev/fsl_msi.h
>>>>> +++ b/arch/powerpc/sysdev/fsl_msi.h
>>>>> @@ -25,6 +25,8 @@
>>>>> #define FSL_PIC_IP_IPIC 0x00000002
>>>>> #define FSL_PIC_IP_VMPIC 0x00000003
>>>>>=20
>>>>> +#define MSI_HW_ERRATA_ENDIAN 0x00000010
>>>>> +
>>>>=20
>>>> Why does this need to be in the header, why not just have it in the =
.c only
>>>=20
>>> Didn't you ask this last time around? :-)
>>>=20
>>> This flag is part of the same numberspace as FSL_PIC_IP_xxx and thus
>>> should be defined in the same place.
>>=20
>> I probably did, if its part of the FSL_PIC_IP_xxx namespace, than =
lets remove blank line between things to make that a bit more clear
>=20
> It's not part of the FSL_PIC_IP_MASK subnumberspace though, just the
> overall msi->features numberspace.
>=20
> It would be nice if these symbols could have some sort of prefix in
> common, though.
>=20
> -Scott
Maybe we should do something like MSI_FTR_ as a prefix
- k
^ permalink raw reply
* Re: [PATCH V2] powerpc: Add I2C bus multiplexer node for B4 and T4240QDS
From: Kumar Gala @ 2013-09-06 16:10 UTC (permalink / raw)
To: Jia Hongtao-B38951
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
Wei.Yang@windriver.com
In-Reply-To: <412C8208B4A0464FA894C5F0C278CD5D01D4824D@039-SN1MPN1-003.039d.mgd.msft.net>
On Sep 5, 2013, at 10:33 PM, Jia Hongtao-B38951 wrote:
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>> Sent: Friday, September 06, 2013 2:41 AM
>> To: Jia Hongtao-B38951
>> Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421;
>> Wei.Yang@windriver.com
>> Subject: Re: [PATCH V2] powerpc: Add I2C bus multiplexer node for B4 and
>> T4240QDS
>>
>>
>> On Sep 4, 2013, at 9:41 PM, Jia Hongtao wrote:
>>
>>> In both B4 and T4240QDS platform PCA9547 I2C bus multiplexer is used.
>>> The sub-nodes are also reorganized according to right I2C topology.
>>>
>>> Signed-off-by: Jia Hongtao <hongtao.jia@freescale.com>
>>> ---
>>> V2 change log:
>>> Reorganized the sub-nodes under I2C multiplexer to represent right
>> topology.
>>>
>>> arch/powerpc/boot/dts/b4qds.dtsi | 49 +++++++++++++++++-----------
>>> arch/powerpc/boot/dts/t4240qds.dts | 67 ++++++++++++++++++++++---------
>> -------
>>> 2 files changed, 69 insertions(+), 47 deletions(-)
>>>
>>> diff --git a/arch/powerpc/boot/dts/b4qds.dtsi
>> b/arch/powerpc/boot/dts/b4qds.dtsi
>>> index e6d2f8f..de8cb38 100644
>>> --- a/arch/powerpc/boot/dts/b4qds.dtsi
>>> +++ b/arch/powerpc/boot/dts/b4qds.dtsi
>>> @@ -120,25 +120,36 @@
>>> };
>>>
>>> i2c@118000 {
>>> - eeprom@50 {
>>> - compatible = "at24,24c64";
>>> - reg = <0x50>;
>>> - };
>>> - eeprom@51 {
>>> - compatible = "at24,24c256";
>>> - reg = <0x51>;
>>> - };
>>> - eeprom@53 {
>>> - compatible = "at24,24c256";
>>> - reg = <0x53>;
>>> - };
>>> - eeprom@57 {
>>> - compatible = "at24,24c256";
>>> - reg = <0x57>;
>>> - };
>>> - rtc@68 {
>>> - compatible = "dallas,ds3232";
>>> - reg = <0x68>;
>>> + pca9547@77 {
>>> + compatible = "philips,pca9547";
>>
>> We seem to be using nxp instead of philips now.
This is based on Documentation/devicetree/bindings/vendor-prefixes.txt
>>
>>> + reg = <0x77>;
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + channel@0 {
>>
>> channel should probably be i2c
>
>
> Is there any standard for the name?
> i2c is ok but I think channel is more intuitional.
>
> Hi Scott,
> What do you think of it.
Basing my comments on Documentation/devicetree/bindings/i2c/i2c-mux.txt
>
> Thanks.
> -Hongtao
>
>
>>
>> [same comments below]
>>
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + reg = <0>;
>>> + eeprom@50 {
>>> + compatible = "at24,24c64";
>>> + reg = <0x50>;
>>> + };
>>> + eeprom@51 {
>>> + compatible = "at24,24c256";
>>> + reg = <0x51>;
>>> + };
>>> + eeprom@53 {
>>> + compatible = "at24,24c256";
>>> + reg = <0x53>;
>>> + };
>>> + eeprom@57 {
>>> + compatible = "at24,24c256";
>>> + reg = <0x57>;
>>> + };
>>> + rtc@68 {
>>> + compatible = "dallas,ds3232";
>>> + reg = <0x68>;
>>> + };
>>> + };
>>> };
>>> };
>>>
>>> diff --git a/arch/powerpc/boot/dts/t4240qds.dts
>> b/arch/powerpc/boot/dts/t4240qds.dts
>>> index 0555976..ae68595 100644
>>> --- a/arch/powerpc/boot/dts/t4240qds.dts
>>> +++ b/arch/powerpc/boot/dts/t4240qds.dts
>>> @@ -118,34 +118,45 @@
>>> };
>>>
>>> i2c@118000 {
>>> - eeprom@51 {
>>> - compatible = "at24,24c256";
>>> - reg = <0x51>;
>>> - };
>>> - eeprom@52 {
>>> - compatible = "at24,24c256";
>>> - reg = <0x52>;
>>> - };
>>> - eeprom@53 {
>>> - compatible = "at24,24c256";
>>> - reg = <0x53>;
>>> - };
>>> - eeprom@54 {
>>> - compatible = "at24,24c256";
>>> - reg = <0x54>;
>>> - };
>>> - eeprom@55 {
>>> - compatible = "at24,24c256";
>>> - reg = <0x55>;
>>> - };
>>> - eeprom@56 {
>>> - compatible = "at24,24c256";
>>> - reg = <0x56>;
>>> - };
>>> - rtc@68 {
>>> - compatible = "dallas,ds3232";
>>> - reg = <0x68>;
>>> - interrupts = <0x1 0x1 0 0>;
>>> + pca9547@77 {
>>> + compatible = "philips,pca9547";
>>> + reg = <0x77>;
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + channel@0 {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + reg = <0>;
>>> + eeprom@51 {
>>> + compatible = "at24,24c256";
>>> + reg = <0x51>;
>>> + };
>>> + eeprom@52 {
>>> + compatible = "at24,24c256";
>>> + reg = <0x52>;
>>> + };
>>> + eeprom@53 {
>>> + compatible = "at24,24c256";
>>> + reg = <0x53>;
>>> + };
>>> + eeprom@54 {
>>> + compatible = "at24,24c256";
>>> + reg = <0x54>;
>>> + };
>>> + eeprom@55 {
>>> + compatible = "at24,24c256";
>>> + reg = <0x55>;
>>> + };
>>> + eeprom@56 {
>>> + compatible = "at24,24c256";
>>> + reg = <0x56>;
>>> + };
>>> + rtc@68 {
>>> + compatible = "dallas,ds3232";
>>> + reg = <0x68>;
>>> + interrupts = <0x1 0x1 0 0>;
>>> + };
>>> + };
>>> };
>>> };
>>> };
>>> --
>>> 1.8.0
>>>
>>>
>>> _______________________________________________
>>> Linuxppc-dev mailing list
>>> Linuxppc-dev@lists.ozlabs.org
>>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>
>
^ permalink raw reply
* Re: [PATCH v8 1/3] DMA: Freescale: revise device tree binding document
From: Scott Wood @ 2013-09-06 15:55 UTC (permalink / raw)
To: Mark Rutland
Cc: devicetree@vger.kernel.org, ian.campbell@citrix.com, Pawel Moll,
swarren@wwwdotorg.org, Hongbo Zhang, linux-kernel@vger.kernel.org,
rob.herring@calxeda.com, vinod.koul@intel.com, djbw@fb.com,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20130828124857.GB10250@e106331-lin.cambridge.arm.com>
On Wed, 2013-08-28 at 13:48 +0100, Mark Rutland wrote:
> On Wed, Aug 28, 2013 at 09:18:55AM +0100, Hongbo Zhang wrote:
> > On 08/27/2013 07:25 PM, Mark Rutland wrote:
> > > On Tue, Aug 27, 2013 at 11:42:01AM +0100, hongbo.zhang@freescale.com wrote:
> > >> From: Hongbo Zhang <hongbo.zhang@freescale.com>
> > >>
> > >> This patch updates the discription of each type of DMA controller and its
> > >> channels, it is preparation for adding another new DMA controller binding, it
> > >> also fixes some defects of indent for text alignment at the same time.
> > >>
> > >> Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
> > >> ---
> > >> .../devicetree/bindings/powerpc/fsl/dma.txt | 62 +++++++++-----------
> > >> 1 file changed, 27 insertions(+), 35 deletions(-)
> > >>
> > >> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
> > >> index 2a4b4bc..ddf17af 100644
> > >> --- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
> > >> +++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
> > >> @@ -1,33 +1,29 @@
> > >> -* Freescale 83xx DMA Controller
> > >> +* Freescale DMA Controllers
> > >>
> > >> -Freescale PowerPC 83xx have on chip general purpose DMA controllers.
> > >> +** Freescale Elo DMA Controller
> > >> + This is a little-endian DMA controller, used in Freescale mpc83xx series
> > >> + chips such as mpc8315, mpc8349, mpc8379 etc.
> > >>
> > >> Required properties:
> > >>
> > >> -- compatible : compatible list, contains 2 entries, first is
> > >> - "fsl,CHIP-dma", where CHIP is the processor
> > >> - (mpc8349, mpc8360, etc.) and the second is
> > >> - "fsl,elo-dma"
> > >> -- reg : <registers mapping for DMA general status reg>
> > >> -- ranges : Should be defined as specified in 1) to describe the
> > >> - DMA controller channels.
> > >> +- compatible : must include "fsl,elo-dma"
> > > We should list the other values that may be in the list also, unless
> > > they are really of no consequence, in which case their presence in dt is
> > > questionable.
> > Hmm. Stephen questioned here too, it seems this is a default rule.
> > Although Scott@freescale had explained our thoughts, I'd like to edit
> > this item like this:
> >
> > "must include "fsl,eloplus-dma", and a "fsl,CHIP-dma" is optional, where
> > CHIP is the processor name"
> >
> > We don't list all the chip name because we have tens of them and we
> > cannot list all of them, and it is unnecessary to list them because we
> > even don't use "fsl,CHIP-dma" in the new driver, add "fsl,CHIP-dma" here
> > just make it questionable when it presents in example and old dts files.
> >
> > I remove the examples in bracket "(mpc8349, mpc8360, etc.)" because we
> > can see the real example below.
> > I don't say" if "fsl,CHIP-dma" presents, it should be the first one, and
> > the "fsl,eloplus-dma" should be the second" because it is common rule.
> > the description language should be clear and concise too I think.
>
> Actually, you've convinced me for the form as you originally converted
> it (must include "fsl,elo-dma"), given that the other strings aren't
> used to give information anywhere and "fsl,CHIP-dma" doesn't fully
> define a valid string.
More generally, bindings should always specify "must include" rather
than "must be" for compatible, since by the nature of compatible you
could have a derivative device with more features that is compatible
with the device described in the binding, and the binding shouldn't
preclude identifying the derivative device.
-Scott
^ permalink raw reply
* [PATCH 6/7] powerpc/t4240emu: Add device tree file for t4240emu
From: York Sun @ 2013-09-06 15:43 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev, York Sun
In-Reply-To: <1378482199-10581-1-git-send-email-yorksun@freescale.com>
T4240EMU is an emulator target with minimum peripherals. It is based on
T4240QDS and trimmed down most peripherals due to either not modeled or
lack of board level connections. The main purpose of this minimum dts is
to speed up booting on emulator.
Signed-off-by: York Sun <yorksun@freescale.com>
Reviewed-by: Wood Scott-B07421 <scottwood@freescale.com>
Reviewed-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com>
Tested-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com>
---
arch/powerpc/boot/dts/t4240emu.dts | 278 ++++++++++++++++++++++++++++++++++++
1 file changed, 278 insertions(+)
create mode 100644 arch/powerpc/boot/dts/t4240emu.dts
diff --git a/arch/powerpc/boot/dts/t4240emu.dts b/arch/powerpc/boot/dts/t4240emu.dts
new file mode 100644
index 0000000..35a9c91
--- /dev/null
+++ b/arch/powerpc/boot/dts/t4240emu.dts
@@ -0,0 +1,278 @@
+/*
+ * T4240 emulator Device Tree Source
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/dts-v1/;
+
+/include/ "fsl/e6500_power_isa.dtsi"
+/ {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-parent = <&mpic>;
+
+ aliases {
+ ccsr = &soc;
+
+ serial0 = &serial0;
+ serial1 = &serial1;
+ serial2 = &serial2;
+ serial3 = &serial3;
+ dma0 = &dma0;
+ dma1 = &dma1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /*
+ * Temporarily add next-level-cache info in each cpu node so
+ * that uboot can do L2 cache fixup. This can be removed once
+ * u-boot can create cpu node with cache info.
+ */
+ cpu0: PowerPC,e6500@0 {
+ device_type = "cpu";
+ reg = <0 1>;
+ next-level-cache = <&L2_1>;
+ };
+ cpu1: PowerPC,e6500@2 {
+ device_type = "cpu";
+ reg = <2 3>;
+ next-level-cache = <&L2_1>;
+ };
+ cpu2: PowerPC,e6500@4 {
+ device_type = "cpu";
+ reg = <4 5>;
+ next-level-cache = <&L2_1>;
+ };
+ cpu3: PowerPC,e6500@6 {
+ device_type = "cpu";
+ reg = <6 7>;
+ next-level-cache = <&L2_1>;
+ };
+
+ cpu4: PowerPC,e6500@8 {
+ device_type = "cpu";
+ reg = <8 9>;
+ next-level-cache = <&L2_2>;
+ };
+ cpu5: PowerPC,e6500@10 {
+ device_type = "cpu";
+ reg = <10 11>;
+ next-level-cache = <&L2_2>;
+ };
+ cpu6: PowerPC,e6500@12 {
+ device_type = "cpu";
+ reg = <12 13>;
+ next-level-cache = <&L2_2>;
+ };
+ cpu7: PowerPC,e6500@14 {
+ device_type = "cpu";
+ reg = <14 15>;
+ next-level-cache = <&L2_2>;
+ };
+
+ cpu8: PowerPC,e6500@16 {
+ device_type = "cpu";
+ reg = <16 17>;
+ next-level-cache = <&L2_3>;
+ };
+ cpu9: PowerPC,e6500@18 {
+ device_type = "cpu";
+ reg = <18 19>;
+ next-level-cache = <&L2_3>;
+ };
+ cpu10: PowerPC,e6500@20 {
+ device_type = "cpu";
+ reg = <20 21>;
+ next-level-cache = <&L2_3>;
+ };
+ cpu11: PowerPC,e6500@22 {
+ device_type = "cpu";
+ reg = <22 23>;
+ next-level-cache = <&L2_3>;
+ };
+ };
+};
+
+/ {
+ model = "fsl,T4240QDS";
+ compatible = "fsl,t4240emu", "fsl,T4240QDS";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-parent = <&mpic>;
+
+ ifc: localbus@ffe124000 {
+ reg = <0xf 0xfe124000 0 0x2000>;
+ ranges = <0 0 0xf 0xe8000000 0x08000000
+ 2 0 0xf 0xff800000 0x00010000
+ 3 0 0xf 0xffdf0000 0x00008000>;
+
+ nor@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x8000000>;
+
+ bank-width = <2>;
+ device-width = <1>;
+ };
+
+ };
+
+ memory {
+ device_type = "memory";
+ };
+
+ soc: soc@ffe000000 {
+ ranges = <0x00000000 0xf 0xfe000000 0x1000000>;
+ reg = <0xf 0xfe000000 0 0x00001000>;
+
+ };
+
+};
+
+&ifc {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,ifc", "simple-bus";
+ interrupts = <25 2 0 0>;
+};
+
+&soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ compatible = "simple-bus";
+
+ soc-sram-error {
+ compatible = "fsl,soc-sram-error";
+ interrupts = <16 2 1 29>;
+ };
+
+ corenet-law@0 {
+ compatible = "fsl,corenet-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <32>;
+ };
+
+ ddr1: memory-controller@8000 {
+ compatible = "fsl,qoriq-memory-controller-v4.7",
+ "fsl,qoriq-memory-controller";
+ reg = <0x8000 0x1000>;
+ interrupts = <16 2 1 23>;
+ };
+
+ ddr2: memory-controller@9000 {
+ compatible = "fsl,qoriq-memory-controller-v4.7",
+ "fsl,qoriq-memory-controller";
+ reg = <0x9000 0x1000>;
+ interrupts = <16 2 1 22>;
+ };
+
+ ddr3: memory-controller@a000 {
+ compatible = "fsl,qoriq-memory-controller-v4.7",
+ "fsl,qoriq-memory-controller";
+ reg = <0xa000 0x1000>;
+ interrupts = <16 2 1 21>;
+ };
+
+ cpc: l3-cache-controller@10000 {
+ compatible = "fsl,p5020-l3-cache-controller", "fsl,p4080-l3-cache-controller", "cache";
+ reg = <0x10000 0x1000
+ 0x11000 0x1000>;
+ interrupts = <16 2 1 27
+ 16 2 1 26>;
+ };
+
+ corenet-cf@18000 {
+ compatible = "fsl,corenet-cf";
+ reg = <0x18000 0x1000>;
+ interrupts = <16 2 1 31>;
+ fsl,ccf-num-csdids = <32>;
+ fsl,ccf-num-snoopids = <32>;
+ };
+
+ iommu@20000 {
+ compatible = "fsl,pamu-v1.0", "fsl,pamu";
+ reg = <0x20000 0x6000>;
+ interrupts = <
+ 24 2 0 0
+ 16 2 1 30>;
+ };
+
+/include/ "fsl/qoriq-mpic.dtsi"
+
+ guts: global-utilities@e0000 {
+ compatible = "fsl,t4240-device-config";
+ reg = <0xe0000 0xe00>;
+ fsl,has-rstcr;
+ fsl,liodn-bits = <12>;
+ };
+
+ clockgen: global-utilities@e1000 {
+ compatible = "fsl,t4240-clockgen", "fsl,qoriq-clockgen-2";
+ reg = <0xe1000 0x1000>;
+ };
+
+/include/ "fsl/qoriq-dma-0.dtsi"
+/include/ "fsl/qoriq-dma-1.dtsi"
+
+/include/ "fsl/qoriq-i2c-0.dtsi"
+/include/ "fsl/qoriq-i2c-1.dtsi"
+/include/ "fsl/qoriq-duart-0.dtsi"
+/include/ "fsl/qoriq-duart-1.dtsi"
+
+
+ /*
+ * Temporarily define cluster 1/2/3's L2 cache nodes in order to pass
+ * next-level-cache info to uboot to do L3 cache fixup. This can be
+ * removed once u-boot can create cpu node with cache info.
+ */
+ L2_1: l2-cache-controller@c20000 {
+ compatible = "fsl,t4240-l2-cache-controller";
+ reg = <0xc20000 0x40000>;
+ next-level-cache = <&cpc>;
+ };
+ L2_2: l2-cache-controller@c60000 {
+ compatible = "fsl,t4240-l2-cache-controller";
+ reg = <0xc60000 0x40000>;
+ next-level-cache = <&cpc>;
+ };
+ L2_3: l2-cache-controller@ca0000 {
+ compatible = "fsl,t4240-l2-cache-controller";
+ reg = <0xca0000 0x40000>;
+ next-level-cache = <&cpc>;
+ };
+};
+
--
1.7.9.5
^ permalink raw reply related
* [PATCH 7/7] powerpc/b4860emu: Add device tree file for b4860emu
From: York Sun @ 2013-09-06 15:43 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev, York Sun
In-Reply-To: <1378482199-10581-1-git-send-email-yorksun@freescale.com>
B4860EMU is a emualtor target with minimum peripherals. It is based on
B4860QDS and trimmed down most peripherals due to either not modeled or
lack of board level connections. The main purpose of this minimum dts is
to speed up booting on emulator.
Signed-off-by: York Sun <yorksun@freescale.com>
Reviewed-by: Wood Scott-B07421 <scottwood@freescale.com>
Reviewed-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com>
Tested-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com>
---
arch/powerpc/boot/dts/b4860emu.dts | 201 ++++++++++++++++++++++++++++++++++++
1 file changed, 201 insertions(+)
create mode 100644 arch/powerpc/boot/dts/b4860emu.dts
diff --git a/arch/powerpc/boot/dts/b4860emu.dts b/arch/powerpc/boot/dts/b4860emu.dts
new file mode 100644
index 0000000..cb927ba
--- /dev/null
+++ b/arch/powerpc/boot/dts/b4860emu.dts
@@ -0,0 +1,201 @@
+/*
+ * B4860 emulator Device Tree Source
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/dts-v1/;
+
+/include/ "fsl/e6500_power_isa.dtsi"
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-parent = <&mpic>;
+
+ aliases {
+ ccsr = &soc;
+
+ serial0 = &serial0;
+ serial1 = &serial1;
+ serial2 = &serial2;
+ serial3 = &serial3;
+ dma0 = &dma0;
+ dma1 = &dma1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: PowerPC,e6500@0 {
+ device_type = "cpu";
+ reg = <0 1>;
+ next-level-cache = <&L2>;
+ };
+ cpu1: PowerPC,e6500@2 {
+ device_type = "cpu";
+ reg = <2 3>;
+ next-level-cache = <&L2>;
+ };
+ cpu2: PowerPC,e6500@4 {
+ device_type = "cpu";
+ reg = <4 5>;
+ next-level-cache = <&L2>;
+ };
+ cpu3: PowerPC,e6500@6 {
+ device_type = "cpu";
+ reg = <6 7>;
+ next-level-cache = <&L2>;
+ };
+ };
+};
+
+/ {
+ model = "fsl,B4860QDS";
+ compatible = "fsl,b4860emu", "fsl,B4860QDS";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-parent = <&mpic>;
+
+ ifc: localbus@ffe124000 {
+ reg = <0xf 0xfe124000 0 0x2000>;
+ ranges = <0 0 0xf 0xe8000000 0x08000000
+ 2 0 0xf 0xff800000 0x00010000
+ 3 0 0xf 0xffdf0000 0x00008000>;
+
+ nor@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x8000000>;
+ bank-width = <2>;
+ device-width = <1>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ };
+
+ soc: soc@ffe000000 {
+ ranges = <0x00000000 0xf 0xfe000000 0x1000000>;
+ reg = <0xf 0xfe000000 0 0x00001000>;
+
+ };
+};
+
+&ifc {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,ifc", "simple-bus";
+ interrupts = <25 2 0 0>;
+};
+
+&soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ compatible = "simple-bus";
+
+ soc-sram-error {
+ compatible = "fsl,soc-sram-error";
+ interrupts = <16 2 1 2>;
+ };
+
+ corenet-law@0 {
+ compatible = "fsl,corenet-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <32>;
+ };
+
+ ddr1: memory-controller@8000 {
+ compatible = "fsl,qoriq-memory-controller-v4.5", "fsl,qoriq-memory-controller";
+ reg = <0x8000 0x1000>;
+ interrupts = <16 2 1 8>;
+ };
+
+ ddr2: memory-controller@9000 {
+ compatible = "fsl,qoriq-memory-controller-v4.5","fsl,qoriq-memory-controller";
+ reg = <0x9000 0x1000>;
+ interrupts = <16 2 1 9>;
+ };
+
+ cpc: l3-cache-controller@10000 {
+ compatible = "fsl,p5020-l3-cache-controller", "fsl,p4080-l3-cache-controller", "cache";
+ reg = <0x10000 0x1000
+ 0x11000 0x1000>;
+ interrupts = <16 2 1 4
+ 16 2 1 5>;
+ };
+
+ corenet-cf@18000 {
+ compatible = "fsl,corenet-cf";
+ reg = <0x18000 0x1000>;
+ interrupts = <16 2 1 0>;
+ fsl,ccf-num-csdids = <32>;
+ fsl,ccf-num-snoopids = <32>;
+ };
+
+ iommu@20000 {
+ compatible = "fsl,pamu-v1.0", "fsl,pamu";
+ reg = <0x20000 0x4000>;
+ interrupts = <
+ 24 2 0 0
+ 16 2 1 1>;
+ };
+
+/include/ "fsl/qoriq-mpic.dtsi"
+
+ guts: global-utilities@e0000 {
+ compatible = "fsl,b4860-device-config";
+ reg = <0xe0000 0xe00>;
+ fsl,has-rstcr;
+ fsl,liodn-bits = <12>;
+ };
+
+ clockgen: global-utilities@e1000 {
+ compatible = "fsl,b4860-clockgen", "fsl,qoriq-clockgen-2";
+ reg = <0xe1000 0x1000>;
+ };
+
+/include/ "fsl/qoriq-dma-0.dtsi"
+/include/ "fsl/qoriq-dma-1.dtsi"
+
+/include/ "fsl/qoriq-i2c-0.dtsi"
+/include/ "fsl/qoriq-i2c-1.dtsi"
+/include/ "fsl/qoriq-duart-0.dtsi"
+/include/ "fsl/qoriq-duart-1.dtsi"
+
+ L2: l2-cache-controller@c20000 {
+ next-level-cache = <&cpc>;
+ };
+};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 5/7] powerpc/corenet64_smp_defconfig: Enable most SPI splash
From: York Sun @ 2013-09-06 15:43 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev, York Sun
In-Reply-To: <1378482199-10581-1-git-send-email-yorksun@freescale.com>
Enable CONFIG_MTD_M25P80 for corenet64_smp_defconfig. Verified on
P5040DS.
Signed-off-by: York Sun <yorksun@freescale.com>
Reviewed-by: Wood Scott-B07421 <scottwood@freescale.com>
Reviewed-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com>
Tested-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com>
---
arch/powerpc/configs/corenet64_smp_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig
index 6c8b020..1ec6f0c 100644
--- a/arch/powerpc/configs/corenet64_smp_defconfig
+++ b/arch/powerpc/configs/corenet64_smp_defconfig
@@ -66,6 +66,7 @@ CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
+CONFIG_MTD_M25P80=y
CONFIG_FTL=y
CONFIG_MTD_CFI=y
CONFIG_MTD_GEN_PROBE=y
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/7] power/mpc85xx: Add delay after enabling I2C master
From: York Sun @ 2013-09-06 15:43 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev, York Sun, linux-i2c
In-Reply-To: <1378482199-10581-1-git-send-email-yorksun@freescale.com>
Erratum A-006037 indicates I2C controller executes the write to I2CCR only
after it sees SCL idle for 64K cycle of internal I2C controller clocks. If
during this waiting period, I2C controller is disabled (I2CCR[MEN] set to
0), then the controller could end in bad state, and hang the future access
to I2C register.
The mpc_i2c_fixup() function tries to recover the bus from a stalled state
where the 9th clock pulse wasn't generated. However, this workaround
disables and enables I2C controller without meeting waiting requirement of
this erratum.
This erratum applies to some 85xx SoCs. It is safe to apply to all of them
for mpc_i2c_fixup().
Signed-off-by: York Sun <yorksun@freescale.com>
Reviewed-by: Wood Scott-B07421 <scottwood@freescale.com>
Reviewed-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com>
Tested-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com>
CC: linux-i2c@vger.kernel.org
---
drivers/i2c/busses/i2c-mpc.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index b80c768..55dce43 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -106,7 +106,12 @@ static irqreturn_t mpc_i2c_isr(int irq, void *dev_id)
static void mpc_i2c_fixup(struct mpc_i2c *i2c)
{
int k;
- u32 delay_val = 1000000 / i2c->real_clk + 1;
+ u32 delay_val;
+#ifdef CONFIG_PPC_85xx
+ delay_val = 65536 / (fsl_get_sys_freq() / 2000000); /* 64K cycle */
+#else
+ delay_val = 1000000 / i2c->real_clk + 1;
+#endif
if (delay_val < 2)
delay_val = 2;
@@ -116,7 +121,11 @@ static void mpc_i2c_fixup(struct mpc_i2c *i2c)
writeccr(i2c, CCR_MSTA | CCR_MTX | CCR_MEN);
udelay(delay_val);
writeccr(i2c, CCR_MEN);
+#ifdef CONFIG_PPC_85xx
+ udelay(delay_val);
+#else
udelay(delay_val << 1);
+#endif
}
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/7] i2c/rtc-ds3232: Fix irq for probing
From: York Sun @ 2013-09-06 15:43 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev, York Sun
In-Reply-To: <1378482199-10581-1-git-send-email-yorksun@freescale.com>
Driver shouldn't request irq when irq = 0. It is returned from parsing
device tree. 0 means no interrupt.
Signed-off-by: York Sun <yorksun@freescale.com>
Reviewed-by: Zang Tiefei-R61911 <tie-fei.zang@freescale.com>
Reviewed-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com>
Tested-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com>
---
drivers/rtc/rtc-ds3232.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-ds3232.c b/drivers/rtc/rtc-ds3232.c
index b83bb5a5..ae8a28e 100644
--- a/drivers/rtc/rtc-ds3232.c
+++ b/drivers/rtc/rtc-ds3232.c
@@ -418,7 +418,7 @@ static int ds3232_probe(struct i2c_client *client,
return PTR_ERR(ds3232->rtc);
}
- if (client->irq >= 0) {
+ if (client->irq > 0) {
ret = devm_request_irq(&client->dev, client->irq, ds3232_irq, 0,
"ds3232", client);
if (ret) {
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/7] powerpc/mpc8xxx: Change EDAC for FSL SoC
From: York Sun @ 2013-09-06 15:43 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev, York Sun
In-Reply-To: <1378482199-10581-1-git-send-email-yorksun@freescale.com>
Remove mpc83xx and mpc85xx as dependency.
Signed-off-by: York Sun <yorksun@freescale.com>
Reviewed-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com>
Tested-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com>
---
drivers/edac/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 878f090..53bf163 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -254,10 +254,10 @@ config EDAC_SBRIDGE
config EDAC_MPC85XX
tristate "Freescale MPC83xx / MPC85xx"
- depends on EDAC_MM_EDAC && FSL_SOC && (PPC_83xx || PPC_85xx)
+ depends on EDAC_MM_EDAC && FSL_SOC
help
Support for error detection and correction on the Freescale
- MPC8349, MPC8560, MPC8540, MPC8548
+ MPC8349, MPC8560, MPC8540, MPC8548, T4240
config EDAC_MV64X60
tristate "Marvell MV64x60"
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/7] powerpc/mpc85xx: Fix EDAC address capture
From: York Sun @ 2013-09-06 15:43 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev, York Sun
Extend err_addr to cover 64 bits for DDR errors.
Signed-off-by: York Sun <yorksun@freescale.com>
Reviewed-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com>
Tested-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com>
---
drivers/edac/mpc85xx_edac.c | 10 +++++++---
drivers/edac/mpc85xx_edac.h | 1 +
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index 3eb32f6..392178f 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -773,6 +773,8 @@ static void sbe_ecc_decode(u32 cap_high, u32 cap_low, u32 cap_ecc,
}
}
+#define make64(high, low) (((u64)(high) << 32) | (low))
+
static void mpc85xx_mc_check(struct mem_ctl_info *mci)
{
struct mpc85xx_mc_pdata *pdata = mci->pvt_info;
@@ -780,7 +782,7 @@ static void mpc85xx_mc_check(struct mem_ctl_info *mci)
u32 bus_width;
u32 err_detect;
u32 syndrome;
- u32 err_addr;
+ u64 err_addr;
u32 pfn;
int row_index;
u32 cap_high;
@@ -811,7 +813,9 @@ static void mpc85xx_mc_check(struct mem_ctl_info *mci)
else
syndrome &= 0xffff;
- err_addr = in_be32(pdata->mc_vbase + MPC85XX_MC_CAPTURE_ADDRESS);
+ err_addr = make64(
+ in_be32(pdata->mc_vbase + MPC85XX_MC_CAPTURE_EXT_ADDRESS),
+ in_be32(pdata->mc_vbase + MPC85XX_MC_CAPTURE_ADDRESS));
pfn = err_addr >> PAGE_SHIFT;
for (row_index = 0; row_index < mci->nr_csrows; row_index++) {
@@ -848,7 +852,7 @@ static void mpc85xx_mc_check(struct mem_ctl_info *mci)
mpc85xx_mc_printk(mci, KERN_ERR,
"Captured Data / ECC:\t%#8.8x_%08x / %#2.2x\n",
cap_high, cap_low, syndrome);
- mpc85xx_mc_printk(mci, KERN_ERR, "Err addr: %#8.8x\n", err_addr);
+ mpc85xx_mc_printk(mci, KERN_ERR, "Err addr: %#8.8llx\n", err_addr);
mpc85xx_mc_printk(mci, KERN_ERR, "PFN: %#8.8x\n", pfn);
/* we are out of range */
diff --git a/drivers/edac/mpc85xx_edac.h b/drivers/edac/mpc85xx_edac.h
index 932016f..efb25bc 100644
--- a/drivers/edac/mpc85xx_edac.h
+++ b/drivers/edac/mpc85xx_edac.h
@@ -43,6 +43,7 @@
#define MPC85XX_MC_ERR_INT_EN 0x0e48
#define MPC85XX_MC_CAPTURE_ATRIBUTES 0x0e4c
#define MPC85XX_MC_CAPTURE_ADDRESS 0x0e50
+#define MPC85XX_MC_CAPTURE_EXT_ADDRESS 0x0e54
#define MPC85XX_MC_ERR_SBE 0x0e58
#define DSC_MEM_EN 0x80000000
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH V2 2/2] powerpc/85xx: workaround for chips with MSI hardware errata
From: Scott Wood @ 2013-09-06 15:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Jia Hongtao, B07421
In-Reply-To: <D0460C0F-D497-4E6A-A0F3-03145FE4444D@kernel.crashing.org>
On Fri, 2013-09-06 at 10:01 -0500, Kumar Gala wrote:
> On Sep 5, 2013, at 1:37 PM, Scott Wood wrote:
>
> > On Thu, 2013-09-05 at 13:34 -0500, Kumar Gala wrote:
> >> On Apr 2, 2013, at 9:03 PM, Jia Hongtao wrote:
> >>> + msi->feature |= MSI_HW_ERRATA_ENDIAN;
> >>> + }
> >>> +
> >>> /*
> >>> * Remember the phandle, so that we can match with any PCI nodes
> >>> * that have an "fsl,msi" property.
> >>> diff --git a/arch/powerpc/sysdev/fsl_msi.h b/arch/powerpc/sysdev/fsl_msi.h
> >>> index 8225f86..7389e8e 100644
> >>> --- a/arch/powerpc/sysdev/fsl_msi.h
> >>> +++ b/arch/powerpc/sysdev/fsl_msi.h
> >>> @@ -25,6 +25,8 @@
> >>> #define FSL_PIC_IP_IPIC 0x00000002
> >>> #define FSL_PIC_IP_VMPIC 0x00000003
> >>>
> >>> +#define MSI_HW_ERRATA_ENDIAN 0x00000010
> >>> +
> >>
> >> Why does this need to be in the header, why not just have it in the .c only
> >
> > Didn't you ask this last time around? :-)
> >
> > This flag is part of the same numberspace as FSL_PIC_IP_xxx and thus
> > should be defined in the same place.
>
> I probably did, if its part of the FSL_PIC_IP_xxx namespace, than lets remove blank line between things to make that a bit more clear
It's not part of the FSL_PIC_IP_MASK subnumberspace though, just the
overall msi->features numberspace.
It would be nice if these symbols could have some sort of prefix in
common, though.
-Scott
^ permalink raw reply
* Re: [PATCH V3 2/2] powerpc/85xx: Add TWR-P1025 board support
From: Scott Wood @ 2013-09-06 15:25 UTC (permalink / raw)
To: Xie Xiaobo-R63061
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
Johnston Michael-R49610
In-Reply-To: <69EC9ED88E3CC04094A78F8074A7986D5D23CE@039-SN1MPN1-003.039d.mgd.msft.net>
On Fri, 2013-09-06 at 05:01 -0500, Xie Xiaobo-R63061 wrote:
> Hi Scott,
>
> Thanks for your reminding and advice.
>
> I discuss this with Liu Shengzhou(the first person that remind me
> #interrupt-cells is 4), he advised removing the interrupts property
> from the phy node, because the mdio used the poll way preferentially.
I don't follow... if the PHYs have interrupts, why would we prefer to
poll?
In any case, the device tree describes the hardware, not how you'd
prefer to use it.
-Scott
^ permalink raw reply
* Re: [PATCH V3 1/2] powerpc/85xx: Add QE common init functions
From: Scott Wood @ 2013-09-06 15:24 UTC (permalink / raw)
To: Xie Xiaobo-R63061; +Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <69EC9ED88E3CC04094A78F8074A7986D5D2378@039-SN1MPN1-003.039d.mgd.msft.net>
On Fri, 2013-09-06 at 04:52 -0500, Xie Xiaobo-R63061 wrote:
> Hi Scott,
>
> I already remove these code from the P1025TWR platform file(see the 2/2 patch). Do you means I also need to remove these codes from the others platforms and use the common call instead?
> Thank you.
Yes.
-Scott
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox