* RE: [4/4] powerpc/85xx: Update mpc85xx_defconfig for C293PCIE
From: Liu Po-B43644 @ 2013-07-23 7:13 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: linuxppc-dev@ozlabs.org, Hu Mingkai-B21284
In-Reply-To: <20130722230026.GA26621@home.buserror.net>
-----Original Message-----
From: Wood Scott-B07421=20
Sent: Tuesday, July 23, 2013 7:00 AM
To: Liu Po-B43644
Cc: linuxppc-dev@ozlabs.org; Hu Mingkai-B21284
Subject: Re: [4/4] powerpc/85xx: Update mpc85xx_defconfig for C293PCIE
On Thu, Apr 25, 2013 at 09:54:17AM +0800, Po Liu wrote:
> From: Mingkai Hu <Mingkai.Hu@freescale.com>
>=20
> Signed-off-by: Mingkai Hu <Mingkai.Hu@freescale.com>
>=20
> ---
> Base on git://git.am.freescale.net/gitolite/mirrors/linux-2.6.git
> arch/powerpc/configs/mpc85xx_defconfig | 1 +
> 1 file changed, 1 insertion(+)
>=20
> diff --git a/arch/powerpc/configs/mpc85xx_defconfig=20
> b/arch/powerpc/configs/mpc85xx_defconfig
> index cf815e8..ddc33a2 100644
> --- a/arch/powerpc/configs/mpc85xx_defconfig
> +++ b/arch/powerpc/configs/mpc85xx_defconfig
> @@ -28,6 +28,7 @@ CONFIG_MPC85xx_MDS=3Dy CONFIG_MPC8536_DS=3Dy =20
> CONFIG_MPC85xx_DS=3Dy CONFIG_MPC85xx_RDB=3Dy
> +CONFIG_C293_PCIE=3Dy
> CONFIG_P1010_RDB=3Dy
> CONFIG_P1022_DS=3Dy
> CONFIG_P1022_RDK=3Dy
Also, why only mpc85xx_defconfig and mpc85xx_smp_defconfig? Just because t=
his board isn't SMP doesn't mean it can't be supported by an SMP kernel.
Action: I will add configure to mpc85xx_smp_defconfig. And merge it to Add=
-C293PCIE-board-support.patch.
-Scott
^ permalink raw reply
* cpuidle/pseries: Fix kernel command line parameter smt-snooze-delay
From: Deepthi Dharwar @ 2013-07-23 4:53 UTC (permalink / raw)
To: PowerPC email list, linux-kernel@vger.kernel.org
Cc: Preeti Murthy, Srivatsa S. Bhat
smt-snooze-delay is a tun-able provided currently on powerpc to delay the
entry of an idle cpu to NAP state. By default, the value is 100us,
which is entry criteria for NAP state i.e only if the idle period is
above 100us it would enter NAP. Value of -1 disables entry into NAP.
This value can be set either through sysfs, ppc64_cpu util or by
passing it via kernel command line. Currently this feature is broken
when the value is passed via the kernel command line.
This patch aims to fix this, by taking the appropriate action
based on the value after the pseries driver is registered.
This check is carried on in the back-end driver rather than
setup_smt_snooze_delay(), as one is not sure if the cpuidle driver
is even registered when setup routine is executed.
Also, this fixes re-enabling of NAP states by setting appropriate
value without having to reboot using smt-snooze-delay parameter.
Also, to note is, smt-snooze-delay is per-cpu variable.
This can be used to enable/disable NAP on per-cpu
basis using sysfs but when this variable is passed
via kernel command line or using the smt-snooze-delay
it applies to all the cpus. Per-cpu tuning can
only be done via sysfs.
Signed-off-by: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/processor_idle.c | 34 ++++++++++++++++++-----
1 file changed, 27 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/processor_idle.c b/arch/powerpc/platforms/pseries/processor_idle.c
index 4644efa0..8133f50 100644
--- a/arch/powerpc/platforms/pseries/processor_idle.c
+++ b/arch/powerpc/platforms/pseries/processor_idle.c
@@ -170,18 +170,36 @@ static struct cpuidle_state shared_states[MAX_IDLE_STATE_COUNT] = {
void update_smt_snooze_delay(int cpu, int residency)
{
struct cpuidle_driver *drv = cpuidle_get_driver();
- struct cpuidle_device *dev = per_cpu(cpuidle_devices, cpu);
+ struct cpuidle_device *dev;
if (cpuidle_state_table != dedicated_states)
return;
- if (residency < 0) {
- /* Disable the Nap state on that cpu */
- if (dev)
- dev->states_usage[1].disable = 1;
- } else
- if (drv)
+ if (!drv)
+ return;
+
+ if (cpu == -1) {
+ if (residency < 0) {
+ /* Disable NAP on all cpus */
+ drv->states[1].disabled = true;
+ } else {
drv->states[1].target_residency = residency;
+ drv->states[1].disabled = false;
+ }
+ return;
+ }
+
+ dev = per_cpu(cpuidle_devices, cpu);
+ if (!dev)
+ return;
+
+ if (residency < 0)
+ dev->states_usage[1].disable = 1;
+ else {
+ drv->states[1].target_residency = residency;
+ drv->states[1].disabled = false;
+ dev->states_usage[1].disable = 0;
+ }
}
static int pseries_cpuidle_add_cpu_notifier(struct notifier_block *n,
@@ -331,6 +349,8 @@ static int __init pseries_processor_idle_init(void)
return retval;
}
+ update_smt_snooze_delay(-1, per_cpu(smt_snooze_delay, 0));
+
retval = pseries_idle_devices_init();
if (retval) {
pseries_idle_devices_uninit();
Regards,
Deepthi
^ permalink raw reply related
* [PATCH 2/2] Powerpc: Add 3.3v voltage support for T4240QDS
From: Haijun Zhang @ 2013-07-23 2:59 UTC (permalink / raw)
To: linux-mmc, linuxppc-dev
Cc: r39252, AFLEMING, cbouatmailru, scottwood, cjb, Haijun Zhang
In-Reply-To: <1374548345-15017-1-git-send-email-Haijun.Zhang@freescale.com>
Freescale T4240QDS reference board has extra voltage shifters added
to allow 3.3V operation, so add 3.3v voltage support for T4240QDS.
Signed-off-by: Haijun Zhang <haijun.zhang@freescale.com>
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
---
changes for this patch set:
- split from patch [PATCH 1/2] Powerpc: Add
- voltage ranges support for T4
arch/powerpc/boot/dts/t4240qds.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/powerpc/boot/dts/t4240qds.dts b/arch/powerpc/boot/dts/t4240qds.dts
index 0555976..5beccdd 100644
--- a/arch/powerpc/boot/dts/t4240qds.dts
+++ b/arch/powerpc/boot/dts/t4240qds.dts
@@ -148,6 +148,11 @@
interrupts = <0x1 0x1 0 0>;
};
};
+
+ sdhc@114000 {
+ compatible = "fsl,t4240-esdhc", "fsl,esdhc";
+ voltage-ranges = <1800 1800 3300 3300>;
+ };
};
pci0: pcie@ffe240000 {
--
1.8.0
^ permalink raw reply related
* [PATCH 1/2] Powerpc: Add voltage support in dts file
From: Haijun Zhang @ 2013-07-23 2:59 UTC (permalink / raw)
To: linux-mmc, linuxppc-dev
Cc: r39252, AFLEMING, cbouatmailru, scottwood, cjb, Haijun Zhang
eSDHC of T4240 had 1.8v voltage support. Add this node to specify
eSDHC voltage capacity. If this node not specified eSDHC driver
still can read from eSDHC host capacity register.
Signed-off-by: Haijun Zhang <haijun.zhang@freescale.com>
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
---
changes for this patch set:
- split from patch [PATCH 1/2] Powerpc: Add
- voltage ranges support for T4
Documentation/devicetree/bindings/mmc/fsl-esdhc.txt | 3 +++
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 1 +
2 files changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt b/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt
index bd9be0b..f1ac253 100644
--- a/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt
+++ b/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt
@@ -19,6 +19,8 @@ Optional properties:
"bus-width = <1>" property.
- sdhci,auto-cmd12: specifies that a controller can only handle auto
CMD12.
+ - 3300 3300: specifies that eSDHC controller can support voltages ranges
+ from 3300 to 3300.
Example:
@@ -29,4 +31,5 @@ sdhci@2e000 {
interrupt-parent = <&ipic>;
/* Filled in by U-Boot */
clock-frequency = <0>;
+ voltage-ranges = <3300 3300>;
};
diff --git a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
index bd611a9..567d0fb 100644
--- a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
@@ -399,6 +399,7 @@
sdhc@114000 {
compatible = "fsl,t4240-esdhc", "fsl,esdhc";
sdhci,auto-cmd12;
+ voltage-ranges = <1800 1800>;
};
/include/ "qoriq-i2c-0.dtsi"
/include/ "qoriq-i2c-1.dtsi"
--
1.8.0
^ permalink raw reply related
* RE: [PATCH 2/2] mmc: esdhc: get voltage from dts file
From: Zhang Haijun-B42677 @ 2013-07-23 3:41 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org, cjb@laptop.org,
linux-mmc@vger.kernel.org, Fleming Andy-AFLEMING,
cbouatmailru@gmail.com
In-Reply-To: <1374547294.15592.22@snotra>
Thanks.
Regards
Haijun.
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Tuesday, July 23, 2013 10:42 AM
> To: Zhang Haijun-B42677
> Cc: Wood Scott-B07421; linux-mmc@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org; cbouatmailru@gmail.com; cjb@laptop.org; Fleming
> Andy-AFLEMING
> Subject: Re: [PATCH 2/2] mmc: esdhc: get voltage from dts file
>=20
> On 07/22/2013 09:38:33 PM, Zhang Haijun-B42677 wrote:
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Tuesday, July 23, 2013 1:41 AM
> > > To: Zhang Haijun-B42677
> > > Cc: linux-mmc@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > cbouatmailru@gmail.com; cjb@laptop.org; Fleming Andy-AFLEMING; Zhang
> > > Haijun-B42677; Zhang Haijun-B42677
> > > Subject: Re: [PATCH 2/2] mmc: esdhc: get voltage from dts file
> > >
> > > On 07/22/2013 02:53:56 AM, Haijun Zhang wrote:
> > > > Add voltage-range support in esdhc of T4, So we can choose to read
> > > > voltages from dts file as one optional.
> > > > If we can get a valid voltage-range from device node, we use this
> > > > voltage as the final voltage support. Else we still read from
> > capacity
> > > > or from other provider.
> > > >
> > > > Signed-off-by: Haijun Zhang <haijun.zhang@freescale.com>
> > > > Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
> > > > ---
> > > > drivers/mmc/host/sdhci-of-esdhc.c | 31
> > > > +++++++++++++++++++++++++++++++
> > > > drivers/mmc/host/sdhci.c | 3 +++
> > > > include/linux/mmc/sdhci.h | 1 +
> > > > 3 files changed, 35 insertions(+)
> > > >
> > > > diff --git a/drivers/mmc/host/sdhci-of-esdhc.c
> > > > b/drivers/mmc/host/sdhci-of-esdhc.c
> > > > index 15039e2..8b4b27a 100644
> > > > --- a/drivers/mmc/host/sdhci-of-esdhc.c
> > > > +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> > > > @@ -262,6 +262,35 @@ static int esdhc_pltfm_bus_width(struct
> > > > sdhci_host *host, int width)
> > > > return 0;
> > > > }
> > > >
> > > > +static void esdhc_get_voltage(struct sdhci_host *host,
> > > > + struct platform_device *pdev)
> > > > +{
> > > > + const u32 *voltage_ranges;
> > > > + int num_ranges, i;
> > > > + struct device_node *np;
> > > > + np =3D pdev->dev.of_node;
> > > > +
> > > > + voltage_ranges =3D of_get_property(np, "voltage-ranges",
> > > > &num_ranges);
> > > > + num_ranges =3D num_ranges / sizeof(*voltage_ranges) / 2;
> > > > + if (!voltage_ranges || !num_ranges) {
> > > > + dev_info(&pdev->dev, "OF: voltage-ranges
> > > > unspecified\n");
> > > > + return;
> > > > + }
> > > > +
> > > > + for (i =3D 0; i < num_ranges; i++) {
> > > > + const int j =3D i * 2;
> > > > + u32 mask;
> > > > + mask =3D
> > > > mmc_vddrange_to_ocrmask(be32_to_cpu(voltage_ranges[j]),
> > > > + be32_to_cpu(voltage_ranges[j + 1]));
> > > > + if (!mask) {
> > > > + dev_info(&pdev->dev,
> > > > + "OF: false voltage-ranges specified\n");
> > > > + return;
> > > > + }
> > > > + host->ocr_mask |=3D mask;
> > > > + }
> > > > +}
> > >
> > > Don't duplicate this code. Move it somewhere common and share it.
> > [Haijun Wrote:] So, move it drivers/mmc/host/sdhci-pltfm.c and share
> > it as Sdhc_get_voltage()....?
>=20
> I'll let the MMC maintainer say what the appropriate place would be...
> Don't capitalize the function name, though. :-)
[Haijun Wrote:] Thanks scott. I'm always expecting chris's advice.
>=20
> -Scott
^ permalink raw reply
* Re: [PATCH] hashtable: add hash_for_each_possible_rcu_notrace()
From: Joe Perches @ 2013-07-23 2:53 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: linux-kernel, Sasha Levin, Andrew Morton, Paul E . McKenney,
linuxppc-dev
In-Reply-To: <51EDEDC6.2040007@ozlabs.ru>
On Tue, 2013-07-23 at 12:43 +1000, Alexey Kardashevskiy wrote:
> On 07/23/2013 12:41 PM, Joe Perches wrote:
> > On Tue, 2013-07-23 at 12:28 +1000, Alexey Kardashevskiy wrote:
> >> Anyone, ping. Is it good, bad, ugly (ack/nack)? Thanks!
> >> Is there any "trivial patches" list? Could not find it on vger.
[]
> > MAINTAINERS has an entry:
> > TRIVIAL PATCHES
> > M: Jiri Kosina <trivial@kernel.org>
> > T: git git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial.git
[]
> Cool, thanks! But is that patch really trivial? :)
:) Was that the question?
Anyway, you cc'd all the right people already.
If no one responds after a couple weeks, either
send it to Jiri or directly to Linus.
^ permalink raw reply
* Re: [PATCH] hashtable: add hash_for_each_possible_rcu_notrace()
From: Alexey Kardashevskiy @ 2013-07-23 2:43 UTC (permalink / raw)
To: Joe Perches
Cc: linux-kernel, Sasha Levin, Andrew Morton, Paul E . McKenney,
linuxppc-dev
In-Reply-To: <1374547276.8308.12.camel@joe-AO722>
On 07/23/2013 12:41 PM, Joe Perches wrote:
> On Tue, 2013-07-23 at 12:28 +1000, Alexey Kardashevskiy wrote:
>> Anyone, ping. Is it good, bad, ugly (ack/nack)? Thanks!
>>
>> Is there any "trivial patches" list? Could not find it on vger.
>
> Jiri Kosina has trivial@kernel.org
>
> Also, there's kernel-janitors
>
> http://vger.kernel.org/vger-lists.html#kernel-janitors
> http://kernelnewbies.org/KernelJanitors
>
> MAINTAINERS has an entry:
>
> TRIVIAL PATCHES
> M: Jiri Kosina <trivial@kernel.org>
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial.git
> S: Maintained
> K: ^Subject:.*(?i)trivial
Cool, thanks! But is that patch really trivial? :)
--
Alexey
^ permalink raw reply
* Re: [PATCH 2/2] mmc: esdhc: get voltage from dts file
From: Scott Wood @ 2013-07-23 2:41 UTC (permalink / raw)
To: Zhang Haijun-B42677
Cc: Wood Scott-B07421, linux-mmc@vger.kernel.org,
Fleming Andy-AFLEMING, cbouatmailru@gmail.com, cjb@laptop.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <99E897753B6F7048BD8CCDB4661D02E13E49EC@039-SN2MPN1-022.039d.mgd.msft.net>
On 07/22/2013 09:38:33 PM, Zhang Haijun-B42677 wrote:
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Tuesday, July 23, 2013 1:41 AM
> > To: Zhang Haijun-B42677
> > Cc: linux-mmc@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > cbouatmailru@gmail.com; cjb@laptop.org; Fleming Andy-AFLEMING; Zhang
> > Haijun-B42677; Zhang Haijun-B42677
> > Subject: Re: [PATCH 2/2] mmc: esdhc: get voltage from dts file
> >
> > On 07/22/2013 02:53:56 AM, Haijun Zhang wrote:
> > > Add voltage-range support in esdhc of T4, So we can choose to read
> > > voltages from dts file as one optional.
> > > If we can get a valid voltage-range from device node, we use this
> > > voltage as the final voltage support. Else we still read from =20
> capacity
> > > or from other provider.
> > >
> > > Signed-off-by: Haijun Zhang <haijun.zhang@freescale.com>
> > > Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
> > > ---
> > > drivers/mmc/host/sdhci-of-esdhc.c | 31
> > > +++++++++++++++++++++++++++++++
> > > drivers/mmc/host/sdhci.c | 3 +++
> > > include/linux/mmc/sdhci.h | 1 +
> > > 3 files changed, 35 insertions(+)
> > >
> > > diff --git a/drivers/mmc/host/sdhci-of-esdhc.c
> > > b/drivers/mmc/host/sdhci-of-esdhc.c
> > > index 15039e2..8b4b27a 100644
> > > --- a/drivers/mmc/host/sdhci-of-esdhc.c
> > > +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> > > @@ -262,6 +262,35 @@ static int esdhc_pltfm_bus_width(struct
> > > sdhci_host *host, int width)
> > > return 0;
> > > }
> > >
> > > +static void esdhc_get_voltage(struct sdhci_host *host,
> > > + struct platform_device *pdev)
> > > +{
> > > + const u32 *voltage_ranges;
> > > + int num_ranges, i;
> > > + struct device_node *np;
> > > + np =3D pdev->dev.of_node;
> > > +
> > > + voltage_ranges =3D of_get_property(np, "voltage-ranges",
> > > &num_ranges);
> > > + num_ranges =3D num_ranges / sizeof(*voltage_ranges) / 2;
> > > + if (!voltage_ranges || !num_ranges) {
> > > + dev_info(&pdev->dev, "OF: voltage-ranges
> > > unspecified\n");
> > > + return;
> > > + }
> > > +
> > > + for (i =3D 0; i < num_ranges; i++) {
> > > + const int j =3D i * 2;
> > > + u32 mask;
> > > + mask =3D
> > > mmc_vddrange_to_ocrmask(be32_to_cpu(voltage_ranges[j]),
> > > + be32_to_cpu(voltage_ranges[j + 1]));
> > > + if (!mask) {
> > > + dev_info(&pdev->dev,
> > > + "OF: false voltage-ranges specified\n");
> > > + return;
> > > + }
> > > + host->ocr_mask |=3D mask;
> > > + }
> > > +}
> >
> > Don't duplicate this code. Move it somewhere common and share it.
> [Haijun Wrote:] So, move it drivers/mmc/host/sdhci-pltfm.c and share =20
> it as
> Sdhc_get_voltage()....?
I'll let the MMC maintainer say what the appropriate place would be... =20
Don't capitalize the function name, though. :-)
-Scott=
^ permalink raw reply
* Re: [PATCH] hashtable: add hash_for_each_possible_rcu_notrace()
From: Joe Perches @ 2013-07-23 2:41 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: linux-kernel, Sasha Levin, Andrew Morton, Paul E . McKenney,
linuxppc-dev
In-Reply-To: <51EDEA39.3000400@ozlabs.ru>
On Tue, 2013-07-23 at 12:28 +1000, Alexey Kardashevskiy wrote:
> Anyone, ping. Is it good, bad, ugly (ack/nack)? Thanks!
>
> Is there any "trivial patches" list? Could not find it on vger.
Jiri Kosina has trivial@kernel.org
Also, there's kernel-janitors
http://vger.kernel.org/vger-lists.html#kernel-janitors
http://kernelnewbies.org/KernelJanitors
MAINTAINERS has an entry:
TRIVIAL PATCHES
M: Jiri Kosina <trivial@kernel.org>
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial.git
S: Maintained
K: ^Subject:.*(?i)trivial
^ permalink raw reply
* RE: [PATCH 2/2] mmc: esdhc: get voltage from dts file
From: Zhang Haijun-B42677 @ 2013-07-23 2:38 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org, cjb@laptop.org,
linux-mmc@vger.kernel.org, Fleming Andy-AFLEMING,
cbouatmailru@gmail.com
In-Reply-To: <1374514847.15592.7@snotra>
Thanks.
Regards
Haijun.
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Tuesday, July 23, 2013 1:41 AM
> To: Zhang Haijun-B42677
> Cc: linux-mmc@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> cbouatmailru@gmail.com; cjb@laptop.org; Fleming Andy-AFLEMING; Zhang
> Haijun-B42677; Zhang Haijun-B42677
> Subject: Re: [PATCH 2/2] mmc: esdhc: get voltage from dts file
>=20
> On 07/22/2013 02:53:56 AM, Haijun Zhang wrote:
> > Add voltage-range support in esdhc of T4, So we can choose to read
> > voltages from dts file as one optional.
> > If we can get a valid voltage-range from device node, we use this
> > voltage as the final voltage support. Else we still read from capacity
> > or from other provider.
> >
> > Signed-off-by: Haijun Zhang <haijun.zhang@freescale.com>
> > Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
> > ---
> > drivers/mmc/host/sdhci-of-esdhc.c | 31
> > +++++++++++++++++++++++++++++++
> > drivers/mmc/host/sdhci.c | 3 +++
> > include/linux/mmc/sdhci.h | 1 +
> > 3 files changed, 35 insertions(+)
> >
> > diff --git a/drivers/mmc/host/sdhci-of-esdhc.c
> > b/drivers/mmc/host/sdhci-of-esdhc.c
> > index 15039e2..8b4b27a 100644
> > --- a/drivers/mmc/host/sdhci-of-esdhc.c
> > +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> > @@ -262,6 +262,35 @@ static int esdhc_pltfm_bus_width(struct
> > sdhci_host *host, int width)
> > return 0;
> > }
> >
> > +static void esdhc_get_voltage(struct sdhci_host *host,
> > + struct platform_device *pdev)
> > +{
> > + const u32 *voltage_ranges;
> > + int num_ranges, i;
> > + struct device_node *np;
> > + np =3D pdev->dev.of_node;
> > +
> > + voltage_ranges =3D of_get_property(np, "voltage-ranges",
> > &num_ranges);
> > + num_ranges =3D num_ranges / sizeof(*voltage_ranges) / 2;
> > + if (!voltage_ranges || !num_ranges) {
> > + dev_info(&pdev->dev, "OF: voltage-ranges
> > unspecified\n");
> > + return;
> > + }
> > +
> > + for (i =3D 0; i < num_ranges; i++) {
> > + const int j =3D i * 2;
> > + u32 mask;
> > + mask =3D
> > mmc_vddrange_to_ocrmask(be32_to_cpu(voltage_ranges[j]),
> > + be32_to_cpu(voltage_ranges[j + 1]));
> > + if (!mask) {
> > + dev_info(&pdev->dev,
> > + "OF: false voltage-ranges specified\n");
> > + return;
> > + }
> > + host->ocr_mask |=3D mask;
> > + }
> > +}
>=20
> Don't duplicate this code. Move it somewhere common and share it.
[Haijun Wrote:] So, move it drivers/mmc/host/sdhci-pltfm.c and share it as
Sdhc_get_voltage()....?
>=20
> Why did you remove the range index from the error string, and why did you
> change it from dev_err to dev_info?
[Haijun Wrote:] I'll correct this. In case voltage-range specified if there=
is still err.
It should be err.
>=20
> -Scott
^ permalink raw reply
* Re: [PATCH] hashtable: add hash_for_each_possible_rcu_notrace()
From: Alexey Kardashevskiy @ 2013-07-23 2:28 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: linux-kernel, Sasha Levin, Andrew Morton, Paul E. McKenney,
linuxppc-dev
In-Reply-To: <51E3C92B.2070704@ozlabs.ru>
Anyone, ping. Is it good, bad, ugly (ack/nack)? Thanks!
Is there any "trivial patches" list? Could not find it on vger.
On 07/15/2013 08:04 PM, Alexey Kardashevskiy wrote:
> Anyone, ping?
>
> On 07/06/2013 02:16 PM, Alexey Kardashevskiy wrote:
>> This adds hash_for_each_possible_rcu_notrace() which is basically
>> a notrace clone of hash_for_each_possible_rcu() which cannot be
>> used in real mode due to its tracing/debugging capability.
>>
>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>> ---
>> include/linux/hashtable.h | 15 +++++++++++++++
>> 1 file changed, 15 insertions(+)
>>
>> diff --git a/include/linux/hashtable.h b/include/linux/hashtable.h
>> index a9df51f..af8b169 100644
>> --- a/include/linux/hashtable.h
>> +++ b/include/linux/hashtable.h
>> @@ -174,6 +174,21 @@ static inline void hash_del_rcu(struct hlist_node *node)
>> member)
>>
>> /**
>> + * hash_for_each_possible_rcu_notrace - iterate over all possible objects hashing
>> + * to the same bucket in an rcu enabled hashtable in a rcu enabled hashtable
>> + * @name: hashtable to iterate
>> + * @obj: the type * to use as a loop cursor for each entry
>> + * @member: the name of the hlist_node within the struct
>> + * @key: the key of the objects to iterate over
>> + *
>> + * This is the same as hash_for_each_possible_rcu() except that it does
>> + * not do any RCU debugging or tracing.
>> + */
>> +#define hash_for_each_possible_rcu_notrace(name, obj, member, key) \
>> + hlist_for_each_entry_rcu_notrace(obj, &name[hash_min(key, HASH_BITS(name))],\
>> + member)
>> +
>> +/**
>> * hash_for_each_possible_safe - iterate over all possible objects hashing to the
>> * same bucket safe against removals
>> * @name: hashtable to iterate
>>
>
>
--
Alexey
^ permalink raw reply
* Re: [PATCH 03/10] vfio: add external user support
From: Alex Williamson @ 2013-07-23 2:23 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: kvm, Alexander Graf, kvm-ppc, linux-kernel, Paul Mackerras,
linuxppc-dev, David Gibson
In-Reply-To: <1373936045-22653-4-git-send-email-aik@ozlabs.ru>
On Tue, 2013-07-16 at 10:53 +1000, Alexey Kardashevskiy wrote:
> VFIO is designed to be used via ioctls on file descriptors
> returned by VFIO.
>
> However in some situations support for an external user is required.
> The first user is KVM on PPC64 (SPAPR TCE protocol) which is going to
> use the existing VFIO groups for exclusive access in real/virtual mode
> on a host to avoid passing map/unmap requests to the user space which
> would made things pretty slow.
>
> The protocol includes:
>
> 1. do normal VFIO init operation:
> - opening a new container;
> - attaching group(s) to it;
> - setting an IOMMU driver for a container.
> When IOMMU is set for a container, all groups in it are
> considered ready to use by an external user.
>
> 2. User space passes a group fd to an external user.
> The external user calls vfio_group_get_external_user()
> to verify that:
> - the group is initialized;
> - IOMMU is set for it.
> If both checks passed, vfio_group_get_external_user()
> increments the container user counter to prevent
> the VFIO group from disposal before KVM exits.
>
> 3. The external user calls vfio_external_user_iommu_id()
> to know an IOMMU ID. PPC64 KVM uses it to link logical bus
> number (LIOBN) with IOMMU ID.
>
> 4. When the external KVM finishes, it calls
> vfio_group_put_external_user() to release the VFIO group.
> This call decrements the container user counter.
> Everything gets released.
>
> The "vfio: Limit group opens" patch is also required for the consistency.
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
This looks fine to me. Is the plan to add this through the ppc tree
again? Thanks,
Alex
> ---
> Changes:
> 2013/07/11:
> * added vfio_group_get()/vfio_group_put()
> * protocol description changed
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
> drivers/vfio/vfio.c | 62 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/vfio.h | 7 ++++++
> 2 files changed, 69 insertions(+)
>
> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> index c488da5..58b034b 100644
> --- a/drivers/vfio/vfio.c
> +++ b/drivers/vfio/vfio.c
> @@ -1370,6 +1370,68 @@ static const struct file_operations vfio_device_fops = {
> };
>
> /**
> + * External user API, exported by symbols to be linked dynamically.
> + *
> + * The protocol includes:
> + * 1. do normal VFIO init operation:
> + * - opening a new container;
> + * - attaching group(s) to it;
> + * - setting an IOMMU driver for a container.
> + * When IOMMU is set for a container, all groups in it are
> + * considered ready to use by an external user.
> + *
> + * 2. User space passes a group fd to an external user.
> + * The external user calls vfio_group_get_external_user()
> + * to verify that:
> + * - the group is initialized;
> + * - IOMMU is set for it.
> + * If both checks passed, vfio_group_get_external_user()
> + * increments the container user counter to prevent
> + * the VFIO group from disposal before KVM exits.
> + *
> + * 3. The external user calls vfio_external_user_iommu_id()
> + * to know an IOMMU ID.
> + *
> + * 4. When the external KVM finishes, it calls
> + * vfio_group_put_external_user() to release the VFIO group.
> + * This call decrements the container user counter.
> + */
> +struct vfio_group *vfio_group_get_external_user(struct file *filep)
> +{
> + struct vfio_group *group = filep->private_data;
> +
> + if (filep->f_op != &vfio_group_fops)
> + return ERR_PTR(-EINVAL);
> +
> + if (!atomic_inc_not_zero(&group->container_users))
> + return ERR_PTR(-EINVAL);
> +
> + if (!group->container->iommu_driver ||
> + !vfio_group_viable(group)) {
> + atomic_dec(&group->container_users);
> + return ERR_PTR(-EINVAL);
> + }
> +
> + vfio_group_get(group);
> +
> + return group;
> +}
> +EXPORT_SYMBOL_GPL(vfio_group_get_external_user);
> +
> +void vfio_group_put_external_user(struct vfio_group *group)
> +{
> + vfio_group_put(group);
> + vfio_group_try_dissolve_container(group);
> +}
> +EXPORT_SYMBOL_GPL(vfio_group_put_external_user);
> +
> +int vfio_external_user_iommu_id(struct vfio_group *group)
> +{
> + return iommu_group_id(group->iommu_group);
> +}
> +EXPORT_SYMBOL_GPL(vfio_external_user_iommu_id);
> +
> +/**
> * Module/class support
> */
> static char *vfio_devnode(struct device *dev, umode_t *mode)
> diff --git a/include/linux/vfio.h b/include/linux/vfio.h
> index ac8d488..24579a0 100644
> --- a/include/linux/vfio.h
> +++ b/include/linux/vfio.h
> @@ -90,4 +90,11 @@ extern void vfio_unregister_iommu_driver(
> TYPE tmp; \
> offsetof(TYPE, MEMBER) + sizeof(tmp.MEMBER); }) \
>
> +/*
> + * External user API
> + */
> +extern struct vfio_group *vfio_group_get_external_user(struct file *filep);
> +extern void vfio_group_put_external_user(struct vfio_group *group);
> +extern int vfio_external_user_iommu_id(struct vfio_group *group);
> +
> #endif /* VFIO_H */
^ permalink raw reply
* Re: [PATCH 04/10] powerpc: Prepare to support kernel handling of IOMMU map/unmap
From: Alexey Kardashevskiy @ 2013-07-23 2:22 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: Andrea Arcangeli, kvm, Yasuaki Ishimatsu, Alexander Graf, kvm-ppc,
linux-kernel, linux-mm, Alex Williamson, Paul Mackerras,
Mel Gorman, Martin Schwidefsky, Andrew Morton, linuxppc-dev,
David Gibson
In-Reply-To: <1373936045-22653-5-git-send-email-aik@ozlabs.ru>
Ping, anyone, please?
Ben needs ack from any of MM people before proceeding with this patch. Thanks!
On 07/16/2013 10:53 AM, Alexey Kardashevskiy wrote:
> The current VFIO-on-POWER implementation supports only user mode
> driven mapping, i.e. QEMU is sending requests to map/unmap pages.
> However this approach is really slow, so we want to move that to KVM.
> Since H_PUT_TCE can be extremely performance sensitive (especially with
> network adapters where each packet needs to be mapped/unmapped) we chose
> to implement that as a "fast" hypercall directly in "real
> mode" (processor still in the guest context but MMU off).
>
> To be able to do that, we need to provide some facilities to
> access the struct page count within that real mode environment as things
> like the sparsemem vmemmap mappings aren't accessible.
>
> This adds an API to increment/decrement page counter as
> get_user_pages API used for user mode mapping does not work
> in the real mode.
>
> CONFIG_SPARSEMEM_VMEMMAP and CONFIG_FLATMEM are supported.
>
> Cc: linux-mm@kvack.org
> Reviewed-by: Paul Mackerras <paulus@samba.org>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>
> ---
>
> Changes:
> 2013/07/10:
> * adjusted comment (removed sentence about virtual mode)
> * get_page_unless_zero replaced with atomic_inc_not_zero to minimize
> effect of a possible get_page_unless_zero() rework (if it ever happens).
>
> 2013/06/27:
> * realmode_get_page() fixed to use get_page_unless_zero(). If failed,
> the call will be passed from real to virtual mode and safely handled.
> * added comment to PageCompound() in include/linux/page-flags.h.
>
> 2013/05/20:
> * PageTail() is replaced by PageCompound() in order to have the same checks
> for whether the page is huge in realmode_get_page() and realmode_put_page()
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
> arch/powerpc/include/asm/pgtable-ppc64.h | 4 ++
> arch/powerpc/mm/init_64.c | 76 +++++++++++++++++++++++++++++++-
> include/linux/page-flags.h | 4 +-
> 3 files changed, 82 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h b/arch/powerpc/include/asm/pgtable-ppc64.h
> index 46db094..aa7b169 100644
> --- a/arch/powerpc/include/asm/pgtable-ppc64.h
> +++ b/arch/powerpc/include/asm/pgtable-ppc64.h
> @@ -394,6 +394,10 @@ static inline void mark_hpte_slot_valid(unsigned char *hpte_slot_array,
> hpte_slot_array[index] = hidx << 4 | 0x1 << 3;
> }
>
> +struct page *realmode_pfn_to_page(unsigned long pfn);
> +int realmode_get_page(struct page *page);
> +int realmode_put_page(struct page *page);
> +
> static inline char *get_hpte_slot_array(pmd_t *pmdp)
> {
> /*
> diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
> index d0cd9e4..dcbb806 100644
> --- a/arch/powerpc/mm/init_64.c
> +++ b/arch/powerpc/mm/init_64.c
> @@ -300,5 +300,79 @@ void vmemmap_free(unsigned long start, unsigned long end)
> {
> }
>
> -#endif /* CONFIG_SPARSEMEM_VMEMMAP */
> +/*
> + * We do not have access to the sparsemem vmemmap, so we fallback to
> + * walking the list of sparsemem blocks which we already maintain for
> + * the sake of crashdump. In the long run, we might want to maintain
> + * a tree if performance of that linear walk becomes a problem.
> + *
> + * Any of realmode_XXXX functions can fail due to:
> + * 1) As real sparsemem blocks do not lay in RAM continously (they
> + * are in virtual address space which is not available in the real mode),
> + * the requested page struct can be split between blocks so get_page/put_page
> + * may fail.
> + * 2) When huge pages are used, the get_page/put_page API will fail
> + * in real mode as the linked addresses in the page struct are virtual
> + * too.
> + */
> +struct page *realmode_pfn_to_page(unsigned long pfn)
> +{
> + struct vmemmap_backing *vmem_back;
> + struct page *page;
> + unsigned long page_size = 1 << mmu_psize_defs[mmu_vmemmap_psize].shift;
> + unsigned long pg_va = (unsigned long) pfn_to_page(pfn);
>
> + for (vmem_back = vmemmap_list; vmem_back; vmem_back = vmem_back->list) {
> + if (pg_va < vmem_back->virt_addr)
> + continue;
> +
> + /* Check that page struct is not split between real pages */
> + if ((pg_va + sizeof(struct page)) >
> + (vmem_back->virt_addr + page_size))
> + return NULL;
> +
> + page = (struct page *) (vmem_back->phys + pg_va -
> + vmem_back->virt_addr);
> + return page;
> + }
> +
> + return NULL;
> +}
> +EXPORT_SYMBOL_GPL(realmode_pfn_to_page);
> +
> +#elif defined(CONFIG_FLATMEM)
> +
> +struct page *realmode_pfn_to_page(unsigned long pfn)
> +{
> + struct page *page = pfn_to_page(pfn);
> + return page;
> +}
> +EXPORT_SYMBOL_GPL(realmode_pfn_to_page);
> +
> +#endif /* CONFIG_SPARSEMEM_VMEMMAP/CONFIG_FLATMEM */
> +
> +#if defined(CONFIG_SPARSEMEM_VMEMMAP) || defined(CONFIG_FLATMEM)
> +int realmode_get_page(struct page *page)
> +{
> + if (PageCompound(page))
> + return -EAGAIN;
> +
> + if (!atomic_inc_not_zero(&page->_count))
> + return -EAGAIN;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(realmode_get_page);
> +
> +int realmode_put_page(struct page *page)
> +{
> + if (PageCompound(page))
> + return -EAGAIN;
> +
> + if (!atomic_add_unless(&page->_count, -1, 1))
> + return -EAGAIN;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(realmode_put_page);
> +#endif
> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> index 6d53675..98ada58 100644
> --- a/include/linux/page-flags.h
> +++ b/include/linux/page-flags.h
> @@ -329,7 +329,9 @@ static inline void set_page_writeback(struct page *page)
> * System with lots of page flags available. This allows separate
> * flags for PageHead() and PageTail() checks of compound pages so that bit
> * tests can be used in performance sensitive paths. PageCompound is
> - * generally not used in hot code paths.
> + * generally not used in hot code paths except arch/powerpc/mm/init_64.c
> + * and arch/powerpc/kvm/book3s_64_vio_hv.c which use it to detect huge pages
> + * and avoid handling those in real mode.
> */
> __PAGEFLAG(Head, head) CLEARPAGEFLAG(Head, head)
> __PAGEFLAG(Tail, tail)
>
--
Alexey
^ permalink raw reply
* RE: [PATCH 1/2] Powerpc: Add voltage ranges support for T4
From: Zhang Haijun-B42677 @ 2013-07-23 2:05 UTC (permalink / raw)
To: Kumar Gala, Wrobel Heinz-R39252
Cc: Wood Scott-B07421, linux-mmc@vger.kernel.org,
Fleming Andy-AFLEMING, cbouatmailru@gmail.com, cjb@laptop.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <18210A71-9F5A-40B7-AC3A-03CEF6C28982@kernel.crashing.org>
Thanks.
Regards
Haijun.
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Monday, July 22, 2013 10:40 PM
> To: Wrobel Heinz-R39252
> Cc: Zhang Haijun-B42677; linux-mmc@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org; Wood Scott-B07421; cjb@laptop.org; Fleming Andy-
> AFLEMING; cbouatmailru@gmail.com
> Subject: Re: [PATCH 1/2] Powerpc: Add voltage ranges support for T4
>=20
>=20
> On Jul 22, 2013, at 4:47 AM, Wrobel Heinz-R39252 wrote:
>=20
> >> Subject: [PATCH 1/2] Powerpc: Add voltage ranges support for T4
> >>
> >> Special voltages that can be support by eSDHC of T4 in esdhc node.
> >>
> >> Signed-off-by: Haijun Zhang <haijun.zhang@freescale.com>
> >> Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
> >
> >> --- a/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt
> >> +++ b/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt
> >> @@ -19,6 +19,8 @@ Optional properties:
> >> "bus-width =3D <1>" property.
> >> - sdhci,auto-cmd12: specifies that a controller can only handle auto
> >> CMD12.
> >> + - 3300 3300: specifies that eSDHC controller can support voltages
> >> ranges
> >> + from 3300 to 3300. This is an optional.
> >
> > "This is an optional." is an unclear statement.
> >
> >> +++ b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
> >> @@ -399,6 +399,7 @@
> >> sdhc@114000 {
> >> compatible =3D "fsl,t4240-esdhc", "fsl,esdhc";
> >> sdhci,auto-cmd12;
> >> + voltage-ranges =3D <1800 1800 3300 3300>;
> >
> > This is IMHO incorrect and potentially dangerous.
> > The T4 silicon will only support 1.8V on SDHC pins per hardware
> specification.
> > The Freescale T4240QDS reference board has extra voltage shifters added
> to allow 3.3V operation, but that is _not_ a silicon feature. It is a
> specific board feature that may or may not translate to other boards,
> depending on how SD spec conformant a board builder wants to be.
> >
> > If the intent is to state that a physical SDHC interface on a board has
> to be built to support 3.3V operation to be SD spec conformant for off-
> the-shelf cards because a reset would change the signal voltage to 3.3V,
> then I am not sure that putting this down as silicon "feature" without
> further explanation about the background anywhere is the right way to go.
> > IMHO silicon features are really just silicon features and not
> technically optional external circuitry additions implied by common use.
> >
> > Best regards,
> >
> > Heinz
>=20
> I'd say that the t4240si-post.dtsi should be:
>=20
> voltage-ranges =3D <1800 1800>;
>=20
> Than have the t4240qds.dts do:
>=20
> voltage-ranges =3D <1800 1800 3300 3300>;
>=20
> As the 3.3V sounds like a board specific feature.
>=20
> [ send this as 2 patches, on for the t4240si-post.dtsi and another for
> the t4240qds.dts ]
[Haijun Wrote:] ok, thanks Heinz and Kumar.
>=20
> - k
>=20
^ permalink raw reply
* RE: [PATCH 3/4 V2] mmc: esdhc: Correct host version of T4240-R1.0
From: Zhang Haijun-B42677 @ 2013-07-23 2:03 UTC (permalink / raw)
To: Kumar Gala
Cc: Wood Scott-B07421, linux-mmc@vger.kernel.org,
Fleming Andy-AFLEMING, cbouatmailru@gmail.com, cjb@laptop.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <25F3761C-ECFA-4397-A4F0-551BDAEDA4C7@kernel.crashing.org>
Thanks.
Regards
Haijun.
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Monday, July 22, 2013 10:30 PM
> To: Zhang Haijun-B42677
> Cc: linux-mmc@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Wood Scott-
> B07421; cjb@laptop.org; Fleming Andy-AFLEMING; cbouatmailru@gmail.com
> Subject: Re: [PATCH 3/4 V2] mmc: esdhc: Correct host version of T4240-
> R1.0
>=20
>=20
> On Jul 17, 2013, at 5:11 AM, Haijun Zhang wrote:
>=20
> > Vender version and sdhc spec version of T4240-R1.0 is incorrect.
> > The right value should be VVN=3D0x13, SVN =3D 0x1. The wrong version
> > number will break down the ADMA data transfer.
> > This defect only exist in T4240-R1.0. Will be fixed in T4240-R2.0.
> > Also share vvn and svr for public use.
> >
> > Signed-off-by: Haijun Zhang <haijun.zhang@freescale.com>
> > ---
> > changes for V2:
> > - Remove broken ADMA quirk.
> > - Rebuild patch of Add quirks to support T4240 board
> >
> > drivers/mmc/host/sdhci-of-esdhc.c | 29 +++++++++++++----------------
> > 1 file changed, 13 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/mmc/host/sdhci-of-esdhc.c
> > b/drivers/mmc/host/sdhci-of-esdhc.c
> > index adfaadd..570bca8 100644
> > --- a/drivers/mmc/host/sdhci-of-esdhc.c
> > +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> > @@ -26,7 +26,7 @@
> > #define VENDOR_V_22 0x12
> > #define VENDOR_V_23 0x13
> >
> > -static u32 svr;
> > +static u32 svr, vvn;
> >
> > static u32 esdhc_readl(struct sdhci_host *host, int reg) { @@ -43,11
> > +43,9 @@ static u32 esdhc_readl(struct sdhci_host *host, int reg)
> > * For FSL eSDHC, must aligned 4-byte, so use 0xFC to read the
> > * the verdor version number, oxFE is SDHCI_HOST_VERSION.
> > */
> > - if ((reg =3D=3D SDHCI_CAPABILITIES) && (ret & SDHCI_CAN_DO_ADMA1)) {
> > - u32 tmp =3D in_be32(host->ioaddr + SDHCI_SLOT_INT_STATUS);
> > - tmp =3D (tmp & SDHCI_VENDOR_VER_MASK) >> SDHCI_VENDOR_VER_SHIFT;
> > - if (tmp > VENDOR_V_22)
> > - ret |=3D SDHCI_CAN_DO_ADMA2;
> > + if ((reg =3D=3D SDHCI_CAPABILITIES) && (ret & SDHCI_CAN_DO_ADMA1) &&
> > + (vvn > VENDOR_V_22)) {
> > + ret |=3D SDHCI_CAN_DO_ADMA2;
> > }
> >
> > return ret;
> > @@ -63,6 +61,12 @@ static u16 esdhc_readw(struct sdhci_host *host, int
> reg)
> > ret =3D in_be32(host->ioaddr + base) & 0xffff;
> > else
> > ret =3D (in_be32(host->ioaddr + base) >> shift) & 0xffff;
> > +
> > + /* T4240-R1.0 had a incorrect vendor version and spec version */
> > + if ((reg =3D=3D SDHCI_HOST_VERSION) &&
> > + ((SVR_SOC_VER(svr) =3D=3D SVR_T4240) && (SVR_REV(svr) =3D=3D 0x10)))
> > + ret =3D (VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) |
> SDHCI_SPEC_200;
> > +
>=20
> is this check correct if this is on v2.0 Si as well?
[Haijun Wrote:] Oh, I forgot to rewrite the description above. This defect =
exist both
on T4-R1.0 and T4-R2.0. I'll send patch v3 to correct this. thanks
>=20
> - k
>=20
> > return ret;
> > }
> >
> > @@ -175,17 +179,12 @@ static void esdhc_reset(struct sdhci_host *host,
> > u8 mask) */ static void esdhci_of_adma_workaround(struct sdhci_host
> > *host, u32 intmask) {
> > - u32 tmp;
> > bool applicable;
> > dma_addr_t dmastart;
> > dma_addr_t dmanow;
> >
> > - tmp =3D esdhc_readl(host, SDHCI_SLOT_INT_STATUS);
> > - tmp =3D (tmp & SDHCI_VENDOR_VER_MASK) >> SDHCI_VENDOR_VER_SHIFT;
> > -
> > applicable =3D (intmask & SDHCI_INT_DATA_END) &&
> > - (intmask & SDHCI_INT_BLK_GAP) &&
> > - (tmp =3D=3D VENDOR_V_23);
> > + (intmask & SDHCI_INT_BLK_GAP) && (vvn =3D=3D VENDOR_V_23);
> > if (applicable) {
> >
> > esdhc_reset(host, SDHCI_RESET_DATA); @@ -318,10 +317,9 @@
> static
> > void esdhc_of_resume(struct sdhci_host *host)
> >
> > static void esdhc_of_platform_init(struct sdhci_host *host) {
> > - u32 vvn;
> > + svr =3D mfspr(SPRN_SVR);
> > + vvn =3D esdhc_readw(host, SDHCI_HOST_VERSION);
> >
> > - vvn =3D in_be32(host->ioaddr + SDHCI_SLOT_INT_STATUS);
> > - vvn =3D (vvn & SDHCI_VENDOR_VER_MASK) >> SDHCI_VENDOR_VER_SHIFT;
> > if (vvn =3D=3D VENDOR_V_22)
> > host->quirks2 |=3D SDHCI_QUIRK2_HOST_NO_CMD23;
> >
> > @@ -390,7 +388,6 @@ static int sdhci_esdhc_probe(struct platform_device
> *pdev)
> > struct device_node *np;
> > int ret;
> >
> > - svr =3D mfspr(SPRN_SVR);
> > host =3D sdhci_pltfm_init(pdev, &sdhci_esdhc_pdata, 0);
> > if (IS_ERR(host))
> > return PTR_ERR(host);
> > --
> > 1.8.0
> >
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
>=20
^ permalink raw reply
* RE: [PATCH] powerpc/msi: Fix compile error on mpc83xx
From: Jia Hongtao-B38951 @ 2013-07-23 1:58 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org, Li Yang-R58472
In-Reply-To: <1374513533.15592.3@snotra>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Tuesday, July 23, 2013 1:19 AM
> To: Jia Hongtao-B38951
> Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org;
> galak@kernel.crashing.org; Li Yang-R58472; Jia Hongtao-B38951
> Subject: Re: [PATCH] powerpc/msi: Fix compile error on mpc83xx
>=20
> On 07/21/2013 09:00:51 PM, Jia Hongtao-B38951 wrote:
> > Hi Scott,
> >
> > The fsl_msi.c build error on MPC83xx platform is fixed by this patch.
> >
> > Could you please have a review?
> >
> > Thanks.
> > -Hongtao
>=20
> I will apply it when I apply the patch that depends on it. I hope to
> resume applying patches soon.
>=20
> -Scott
Thanks.
- Hongtao
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/mm: Fix fallthrough bug in hpte_decode
From: Aneesh Kumar K.V @ 2013-07-23 1:51 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
In-Reply-To: <1372839603-8308-2-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> We should not fallthrough different case statements in hpte_decode. Add
> break statement to break out of the switch. The regression is introduced by
> dcda287a9b26309ae43a091d0ecde16f8f61b4c0 "powerpc/mm: Simplify hpte_decode"
>
> Reported-by: Paul Mackerras <paulus@samba.org>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> ---
> arch/powerpc/mm/hash_native_64.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/powerpc/mm/hash_native_64.c b/arch/powerpc/mm/hash_native_64.c
> index 0de15fc..e1f9b82 100644
> --- a/arch/powerpc/mm/hash_native_64.c
> +++ b/arch/powerpc/mm/hash_native_64.c
> @@ -560,6 +560,7 @@ static void hpte_decode(struct hash_pte *hpte, unsigned long slot,
> seg_off |= vpi << shift;
> }
> *vpn = vsid << (SID_SHIFT - VPN_SHIFT) | seg_off >> VPN_SHIFT;
> + break;
> case MMU_SEGSIZE_1T:
> /* We only have 40 - 23 bits of seg_off in avpn */
> seg_off = (avpn & 0x1ffff) << 23;
> @@ -569,6 +570,7 @@ static void hpte_decode(struct hash_pte *hpte, unsigned long slot,
> seg_off |= vpi << shift;
> }
> *vpn = vsid << (SID_SHIFT_1T - VPN_SHIFT) | seg_off >> VPN_SHIFT;
> + break;
> default:
> *vpn = size = 0;
> }
Any update on this ?
-aneesh
^ permalink raw reply
* Re: [PATCH -V2] powerpc/mm: Use the correct SLB(LLP) encoding in tlbie instruction
From: Aneesh Kumar K.V @ 2013-07-23 1:50 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
In-Reply-To: <1372914285-30562-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> The sllp value is stored in mmu_psize_defs in such a way that we can easily OR
> the value to get the operand for slbmte instruction. ie, the L and LP bits are
> not contiguous. Decode the bits and use them correctly in tlbie.
> regression is introduced by 1f6aaaccb1b3af8613fe45781c1aefee2ae8c6b3
> "powerpc: Update tlbie/tlbiel as per ISA doc"
>
> Reported-by: Paul Mackerras <paulus@samba.org>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> ---
> Changes from V1:
> * use #define constants instead of opencoded values
>
> arch/powerpc/mm/hash_native_64.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/mm/hash_native_64.c b/arch/powerpc/mm/hash_native_64.c
> index 0530ff7..c33d939 100644
> --- a/arch/powerpc/mm/hash_native_64.c
> +++ b/arch/powerpc/mm/hash_native_64.c
> @@ -43,6 +43,7 @@ static inline void __tlbie(unsigned long vpn, int psize, int apsize, int ssize)
> {
> unsigned long va;
> unsigned int penc;
> + unsigned long sllp;
>
> /*
> * We need 14 to 65 bits of va for a tlibe of 4K page
> @@ -64,7 +65,9 @@ static inline void __tlbie(unsigned long vpn, int psize, int apsize, int ssize)
> /* clear out bits after (52) [0....52.....63] */
> va &= ~((1ul << (64 - 52)) - 1);
> va |= ssize << 8;
> - va |= mmu_psize_defs[apsize].sllp << 6;
> + sllp = ((mmu_psize_defs[apsize].sllp & SLB_VSID_L) >> 6) |
> + ((mmu_psize_defs[apsize].sllp & SLB_VSID_LP) >> 4);
> + va |= sllp << 5;
> asm volatile(ASM_FTR_IFCLR("tlbie %0,0", PPC_TLBIE(%1,%0), %2)
> : : "r" (va), "r"(0), "i" (CPU_FTR_ARCH_206)
> : "memory");
> @@ -98,6 +101,7 @@ static inline void __tlbiel(unsigned long vpn, int psize, int apsize, int ssize)
> {
> unsigned long va;
> unsigned int penc;
> + unsigned long sllp;
>
> /* VPN_SHIFT can be atmost 12 */
> va = vpn << VPN_SHIFT;
> @@ -113,7 +117,9 @@ static inline void __tlbiel(unsigned long vpn, int psize, int apsize, int ssize)
> /* clear out bits after(52) [0....52.....63] */
> va &= ~((1ul << (64 - 52)) - 1);
> va |= ssize << 8;
> - va |= mmu_psize_defs[apsize].sllp << 6;
> + sllp = ((mmu_psize_defs[apsize].sllp & SLB_VSID_L) >> 6) |
> + ((mmu_psize_defs[apsize].sllp & SLB_VSID_LP) >> 4);
> + va |= sllp << 5;
> asm volatile(".long 0x7c000224 | (%0 << 11) | (0 << 21)"
> : : "r"(va) : "memory");
> break;
Any update on this ?
-aneesh
^ permalink raw reply
* Re: [PATCH] powerpc: platforms: powernv: add '__init' for pnv_pci_init_ioda2_phb()
From: Chen Gang @ 2013-07-23 0:37 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Richard Yang, Gavin Shan, Ram Pai, paulus@samba.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAErSpo6_537nW9+7MtLcA70HhiZwQG3TFCZCUumPk+b8GAgq3Q@mail.gmail.com>
On 07/23/2013 08:28 AM, Bjorn Helgaas wrote:
> On Mon, Jul 22, 2013 at 12:52 AM, Chen Gang <gang.chen@asianux.com> wrote:
>> pnv_pci_init_ioda2_phb() is only used during boot up, so need add
>> '__init' to save the related memory, and avoid related warning:
>>
>> The function .pnv_pci_init_ioda2_phb() references
>> the function __init .pnv_pci_init_ioda_phb().
>> This is often because .pnv_pci_init_ioda2_phb lacks a __init
>> annotation or the annotation of .pnv_pci_init_ioda_phb is wrong.
>>
>>
>> Signed-off-by: Chen Gang <gang.chen@asianux.com>
>
> Looks right to me.
>
Thanks.
>> ---
>> arch/powerpc/platforms/powernv/pci-ioda.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
>> index 49b57b9..d8140b1 100644
>> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
>> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
>> @@ -1266,7 +1266,7 @@ void __init pnv_pci_init_ioda_phb(struct device_node *np,
>> opal_pci_set_pe(phb_id, 0, 0, 7, 1, 1 , OPAL_MAP_PE);
>> }
>>
>> -void pnv_pci_init_ioda2_phb(struct device_node *np)
>> +void __init pnv_pci_init_ioda2_phb(struct device_node *np)
>> {
>> pnv_pci_init_ioda_phb(np, 0, PNV_PHB_IODA2);
>> }
>> --
>> 1.7.7.6
>
>
--
Chen Gang
^ permalink raw reply
* Re: [RFC] power/mpc85xx: Add delay after enabling I2C master
From: Scott Wood @ 2013-07-23 0:33 UTC (permalink / raw)
To: York Sun; +Cc: albrecht.dress, linuxppc-dev
In-Reply-To: <1368480428-23926-1-git-send-email-yorksun@freescale.com>
On Mon, May 13, 2013 at 02:27:08PM -0700, York Sun wrote:
> 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>
>
> ---
> I'd like to get rid of the #ifdef if mpc5121 is OK with the longer delay.
Are mpc5121 and mpc85xx the only things that use this?
Are you sure the delay always works out to be longer? What is the
relationship between fsl_get_sys_freq() and i2c->real_clk?
In any case, you should send this patch to the i2c maintainer and list.
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc: platforms: powernv: add '__init' for pnv_pci_init_ioda2_phb()
From: Bjorn Helgaas @ 2013-07-23 0:28 UTC (permalink / raw)
To: Chen Gang
Cc: Richard Yang, Gavin Shan, Ram Pai, paulus@samba.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <51ECD6A4.3050408@asianux.com>
On Mon, Jul 22, 2013 at 12:52 AM, Chen Gang <gang.chen@asianux.com> wrote:
> pnv_pci_init_ioda2_phb() is only used during boot up, so need add
> '__init' to save the related memory, and avoid related warning:
>
> The function .pnv_pci_init_ioda2_phb() references
> the function __init .pnv_pci_init_ioda_phb().
> This is often because .pnv_pci_init_ioda2_phb lacks a __init
> annotation or the annotation of .pnv_pci_init_ioda_phb is wrong.
>
>
> Signed-off-by: Chen Gang <gang.chen@asianux.com>
Looks right to me.
> ---
> arch/powerpc/platforms/powernv/pci-ioda.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
> index 49b57b9..d8140b1 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -1266,7 +1266,7 @@ void __init pnv_pci_init_ioda_phb(struct device_node *np,
> opal_pci_set_pe(phb_id, 0, 0, 7, 1, 1 , OPAL_MAP_PE);
> }
>
> -void pnv_pci_init_ioda2_phb(struct device_node *np)
> +void __init pnv_pci_init_ioda2_phb(struct device_node *np)
> {
> pnv_pci_init_ioda_phb(np, 0, PNV_PHB_IODA2);
> }
> --
> 1.7.7.6
^ permalink raw reply
* Re: powerpc/85xx: Add TWR-P1025 board support
From: Scott Wood @ 2013-07-22 23:11 UTC (permalink / raw)
To: Xie Xiaobo; +Cc: linuxppc-dev, Michael Johnston
In-Reply-To: <1366874028-18870-1-git-send-email-X.Xie@freescale.com>
On Thu, Apr 25, 2013 at 03:13:48PM +0800, Xie Xiaobo wrote:
> + partition@400000 {
> + /* 58.75MB for JFFS2 based Root file System */
> + reg = <0x00400000 0x03ac0000>;
> + label = "NOR JFFS2 Root File System";
> + };
Don't specify JFFS2.
> diff --git a/arch/powerpc/platforms/85xx/twr_p102x.c b/arch/powerpc/platforms/85xx/twr_p102x.c
> new file mode 100644
> index 0000000..a5de4e0
> --- /dev/null
> +++ b/arch/powerpc/platforms/85xx/twr_p102x.c
> @@ -0,0 +1,176 @@
> +/*
> + * Copyright 2010-2011, 2013 Freescale Semiconductor, Inc.
> + *
> + * Author: Michael Johnston <michael.johnston@freescale.com>
> + *
> + * Description:
> + * TWR-P102x Board Setup
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/errno.h>
> +#include <linux/pci.h>
> +#include <linux/delay.h>
> +#include <linux/module.h>
> +#include <linux/fsl_devices.h>
> +#include <linux/of_platform.h>
> +#include <linux/of_device.h>
> +#include <linux/memblock.h>
> +
> +#include <asm/time.h>
> +#include <asm/machdep.h>
> +#include <asm/pci-bridge.h>
> +#include <mm/mmu_decl.h>
> +#include <asm/prom.h>
> +#include <asm/udbg.h>
> +#include <asm/mpic.h>
> +#include <asm/qe.h>
> +#include <asm/qe_ic.h>
> +#include <asm/fsl_guts.h>
> +
> +#include <sysdev/fsl_soc.h>
> +#include <sysdev/fsl_pci.h>
> +#include "smp.h"
> +
> +#include "mpc85xx.h"
Are you sure you need all of these? I don't see any delays, for example.
> +static void __init twr_p1025_pic_init(void)
> +{
> + struct mpic *mpic;
> +
> +#ifdef CONFIG_QUICC_ENGINE
> + struct device_node *np;
> +#endif
> +
> + mpic = mpic_alloc(NULL, 0, MPIC_BIG_ENDIAN |
> + MPIC_SINGLE_DEST_CPU,
> + 0, 256, " OpenPIC ");
> +
> + BUG_ON(mpic == NULL);
> + mpic_init(mpic);
> +
> +#ifdef CONFIG_QUICC_ENGINE
> + np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
> + if (np) {
> + qe_ic_init(np, 0, qe_ic_cascade_low_mpic,
> + qe_ic_cascade_high_mpic);
> + of_node_put(np);
> + } else
> + printk(KERN_ERR "Could not find qe-ic node\n");
WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then
pr_err(... to printk(KERN_ERR ...
#529: FILE: arch/powerpc/platforms/85xx/twr_p102x.c:65:
+ printk(KERN_ERR "Could not find qe-ic node\n");
Likewise elsewhere.
Also, it'd be nice if this code (as well as the QE code later in this
file) were factored out to a QE file rather than being duplicated in
board files.
> +static int __init twr_p1025_probe(void)
> +{
> + unsigned long root = of_get_flat_dt_root();
> +
> + return of_flat_dt_is_compatible(root, "fsl,TWR-P1025");
> +
> +}
Remove the newline at the end of the function.
-Scott
^ permalink raw reply
* Re: [4/4] powerpc/85xx: Update mpc85xx_defconfig for C293PCIE
From: Scott Wood @ 2013-07-22 23:00 UTC (permalink / raw)
To: Po Liu; +Cc: linuxppc-dev, Mingkai Hu
In-Reply-To: <1366854857-22791-4-git-send-email-Po.Liu@freescale.com>
On Thu, Apr 25, 2013 at 09:54:17AM +0800, Po Liu wrote:
> From: Mingkai Hu <Mingkai.Hu@freescale.com>
>
> Signed-off-by: Mingkai Hu <Mingkai.Hu@freescale.com>
>
> ---
> Base on git://git.am.freescale.net/gitolite/mirrors/linux-2.6.git
> arch/powerpc/configs/mpc85xx_defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/mpc85xx_defconfig
> index cf815e8..ddc33a2 100644
> --- a/arch/powerpc/configs/mpc85xx_defconfig
> +++ b/arch/powerpc/configs/mpc85xx_defconfig
> @@ -28,6 +28,7 @@ CONFIG_MPC85xx_MDS=y
> CONFIG_MPC8536_DS=y
> CONFIG_MPC85xx_DS=y
> CONFIG_MPC85xx_RDB=y
> +CONFIG_C293_PCIE=y
> CONFIG_P1010_RDB=y
> CONFIG_P1022_DS=y
> CONFIG_P1022_RDK=y
Also, why only mpc85xx_defconfig and mpc85xx_smp_defconfig? Just because
this board isn't SMP doesn't mean it can't be supported by an SMP kernel.
-Scott
^ permalink raw reply
* Re: [4/4] powerpc/85xx: Update mpc85xx_defconfig for C293PCIE
From: Scott Wood @ 2013-07-22 22:59 UTC (permalink / raw)
To: Po Liu; +Cc: linuxppc-dev, Mingkai Hu
In-Reply-To: <1366854857-22791-4-git-send-email-Po.Liu@freescale.com>
On Thu, Apr 25, 2013 at 09:54:17AM +0800, Po Liu wrote:
> From: Mingkai Hu <Mingkai.Hu@freescale.com>
>
> Signed-off-by: Mingkai Hu <Mingkai.Hu@freescale.com>
>
> ---
> Base on git://git.am.freescale.net/gitolite/mirrors/linux-2.6.git
> arch/powerpc/configs/mpc85xx_defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/mpc85xx_defconfig
> index cf815e8..ddc33a2 100644
> --- a/arch/powerpc/configs/mpc85xx_defconfig
> +++ b/arch/powerpc/configs/mpc85xx_defconfig
> @@ -28,6 +28,7 @@ CONFIG_MPC85xx_MDS=y
> CONFIG_MPC8536_DS=y
> CONFIG_MPC85xx_DS=y
> CONFIG_MPC85xx_RDB=y
> +CONFIG_C293_PCIE=y
> CONFIG_P1010_RDB=y
> CONFIG_P1022_DS=y
> CONFIG_P1022_RDK=y
Please just merge this in with the patch that adds CONFIG_C293_PCIE
support, when you respin that patch.
-Scott
^ permalink raw reply
* Re: [3/4] powerpc/85xx: Add C293PCIE board support
From: Scott Wood @ 2013-07-22 22:58 UTC (permalink / raw)
To: Po Liu; +Cc: linuxppc-dev, Mingkai Hu
In-Reply-To: <1366854857-22791-3-git-send-email-Po.Liu@freescale.com>
On Thu, Apr 25, 2013 at 09:54:16AM +0800, Po Liu wrote:
> From: Mingkai Hu <Mingkai.Hu@freescale.com>
>
> C293PCIE board is a series of Freescale PCIe add-in cards to perform
> as public key crypto accelerator or secure key management module.
>
> - 512KB platform SRAM in addition to 512K L2 Cache/SRAM
> - 512MB soldered DDR3 32bit memory
> - CPLD System Logic
> - 64MB x16 NOR flash and 4GB x8 NAND flash
> - 16MB SPI flash
>
> Signed-off-by: Mingkai Hu <Mingkai.Hu@freescale.com>
> Singed-off-by: Po Liu <Po.Liu@freescale.com>
Signed
> + partition@900000 {
> + /* 33MB for rootfs */
> + reg = <0x00900000 0x02100000>;
> + label = "NOR Rootfs Image";
> + };
> +
> + partition@2a00000 {
> + /* 20MB for JFFS2 based Root file System */
> + reg = <0x02a00000 0x01400000>;
> + label = "NOR JFFS2 Root File System";
> + };
Don't specify JFFS2. Combine these two partitions into one.
> + partition@600000 {
> + /* 4MB for Compressed Root file System Image */
> + reg = <0x00600000 0x00400000>;
> + label = "NAND Compressed RFS Image";
> + };
> +
> + partition@a00000 {
> + /* 15MB for JFFS2 based Root file System */
> + reg = <0x00a00000 0x00f00000>;
> + label = "NAND JFFS2 Root File System";
> + };
Likewise.
> + partition@1900000 {
> + /* 7MB for User Area */
> + reg = <0x01900000 0x00700000>;
> + label = "NAND User area";
> + };
Above you say there's 4 GiB of NAND, but here you define partitions that
only cover 32 MiB.
> + };
> +
> + cpld@2,0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "fsl,c293pcie-cpld";
> + reg = <0x2 0x0 0x0000020>;
> + bank-width = <1>;
> + device-width = <1>;
> + };
What do bank-width and device-width mean here?
Why all the leading zeroes in 0x0000020?
> + partition@580000 {
> + /* 4MB for Compressed RFS Image */
> + reg = <0x00580000 0x00400000>;
> + label = "SPI Flash Compressed RFSImage";
> + };
> +
> + partition@980000 {
> + /* 6.5MB for JFFS2 based RFS */
> + reg = <0x00980000 0x00680000>;
> + label = "SPI Flash JFFS2 RFS";
> + };
Again, merge these two and don't specify JFFS2.
> diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
> index a0dcd57..df26b21 100644
> --- a/arch/powerpc/platforms/85xx/Kconfig
> +++ b/arch/powerpc/platforms/85xx/Kconfig
> @@ -32,6 +32,13 @@ config BSC9131_RDB
> StarCore SC3850 DSP
> Manufacturer : Freescale Semiconductor, Inc
>
> +config C293_PCIE
> + bool "Freescale C293PCIE"
> + select DEFAULT_UIMAGE
> + select SWIOTLB
> + help
> + This option enables support for the C293PCIE board
Why do you need SWIOTLB if the board has 512 MiB soldered RAM?
> diff --git a/arch/powerpc/platforms/85xx/c293pcie.c b/arch/powerpc/platforms/85xx/c293pcie.c
> new file mode 100644
> index 0000000..75dda12
> --- /dev/null
> +++ b/arch/powerpc/platforms/85xx/c293pcie.c
> @@ -0,0 +1,82 @@
> +/*
> + * C293PCIE Board Setup
> + *
> + * Copyright 2013 Freescale Semiconductor Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +#include <linux/stddef.h>
> +#include <linux/kernel.h>
> +#include <linux/pci.h>
> +#include <linux/delay.h>
> +#include <linux/interrupt.h>
> +#include <linux/of_platform.h>
> +
> +#include <asm/time.h>
> +#include <asm/machdep.h>
> +#include <asm/pci-bridge.h>
> +#include <mm/mmu_decl.h>
> +#include <asm/prom.h>
> +#include <asm/udbg.h>
> +#include <asm/mpic.h>
> +
> +#include <sysdev/fsl_soc.h>
> +#include <sysdev/fsl_pci.h>
> +
> +#include "mpc85xx.h"
Are you sure you need all of these? I don't see any delays, for example.
-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