* Re: commit e38c0a1f breaks powerpc boards with uli1575 chip
From: Rob Herring @ 2013-12-18 18:40 UTC (permalink / raw)
To: Nikita Yushchenko, Arnd Bergmann, Thierry Reding, Grant Likely,
devicetree@vger.kernel.org, Kumar Gala
Cc: Alexey Lugovskoy, linuxppc-dev, linux-kernel, Dmitry Krivoschekov
In-Reply-To: <201312171135.38576@blacky.localdomain>
[fixed DT maillist address]
On 12/17/2013 01:35 AM, Nikita Yushchenko wrote:
> Hi
>
> While trying to make freescale p2020ds and mpc8572ds boards working with mainline kernel, I faced that commit
> e38c0a1f (Handle #address-cells > 2 specially) breaks things with these boards.
Good to see this broke in v3.7 and is just now found...
>
> Both these boards have uli1575 chip.
> Corresponding part in device tree is something like
>
> uli1575@0 {
> reg = <0x0 0x0 0x0 0x0 0x0>;
> #size-cells = <2>;
> #address-cells = <3>;
> ranges = <0x2000000 0x0 0x80000000
> 0x2000000 0x0 0x80000000
> 0x0 0x20000000
>
> 0x1000000 0x0 0x0
> 0x1000000 0x0 0x0
> 0x0 0x10000>;
> isa@1e {
> ...
>
> I.e. it has #address-cells = <3>
>
>
> With commit e38c0a1f reverted, devices under uli1575 are registered correctly, e.g. for rtc
>
> OF: ** translation for device /pcie@ffe09000/pcie@0/uli1575@0/isa@1e/rtc@70 **
> OF: bus is isa (na=2, ns=1) on /pcie@ffe09000/pcie@0/uli1575@0/isa@1e
> OF: translating address: 00000001 00000070
> OF: parent bus is default (na=3, ns=2) on /pcie@ffe09000/pcie@0/uli1575@0
> OF: walking ranges...
> OF: ISA map, cp=0, s=1000, da=70
> OF: parent translation for: 01000000 00000000 00000000
> OF: with offset: 70
> OF: one level translation: 00000000 00000000 00000070
> OF: parent bus is pci (na=3, ns=2) on /pcie@ffe09000/pcie@0
> OF: walking ranges...
> OF: default map, cp=a0000000, s=20000000, da=70
> OF: default map, cp=0, s=10000, da=70
> OF: parent translation for: 01000000 00000000 00000000
> OF: with offset: 70
> OF: one level translation: 01000000 00000000 00000070
> OF: parent bus is pci (na=3, ns=2) on /pcie@ffe09000
> OF: walking ranges...
> OF: PCI map, cp=0, s=10000, da=70
> OF: parent translation for: 01000000 00000000 00000000
> OF: with offset: 70
> OF: one level translation: 01000000 00000000 00000070
> OF: parent bus is default (na=2, ns=2) on /
> OF: walking ranges...
> OF: PCI map, cp=0, s=10000, da=70
> OF: parent translation for: 00000000 ffc10000
> OF: with offset: 70
> OF: one level translation: 00000000 ffc10070
> OF: reached root node
>
> With commit e38c0a1f in place, address translation fails:
>
> OF: ** translation for device /pcie@ffe09000/pcie@0/uli1575@0/isa@1e/rtc@70 **
> OF: bus is isa (na=2, ns=1) on /pcie@ffe09000/pcie@0/uli1575@0/isa@1e
> OF: translating address: 00000001 00000070
> OF: parent bus is default (na=3, ns=2) on /pcie@ffe09000/pcie@0/uli1575@0
> OF: walking ranges...
> OF: ISA map, cp=0, s=1000, da=70
> OF: parent translation for: 01000000 00000000 00000000
> OF: with offset: 70
> OF: one level translation: 00000000 00000000 00000070
> OF: parent bus is pci (na=3, ns=2) on /pcie@ffe09000/pcie@0
> OF: walking ranges...
> OF: default map, cp=a0000000, s=20000000, da=70
> OF: default map, cp=0, s=10000, da=70
> OF: not found !
>
> Either e38c0a1f should be reverted, or uli1575 (and perhaps other similar devices) have to be described in device
> trees differently.
Reverting would break Tegra PCIe, but you should not have to change the
DT either. So we need a solution.
Is this something like this sufficient to fix it?
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 4b9317b..378aebd 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -74,7 +74,7 @@ static u64 of_bus_default_map(__be32 *addr, const
__be32 *range,
* mapping doesn't specify a physical address. Rather, the address
* specifies an identifier that must match exactly.
*/
- if (na > 2 && memcmp(range, addr, na * 4) != 0)
+ if (na > 2 && memcmp(range, addr, (na - 2) * 4) != 0)
return OF_BAD_ADDR;
if (da < cp || da >= (cp + s))
^ permalink raw reply related
* Re: [RFC][PATCH v1] ASoC: fsl_ssi: Add DAI master mode support for SSI on i.MX series
From: Mark Brown @ 2013-12-18 18:59 UTC (permalink / raw)
To: Nicolin Chen; +Cc: alsa-devel, lgirdwood, tiwai, timur, perex, linuxppc-dev
In-Reply-To: <1386845085-21682-1-git-send-email-Guangyu.Chen@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 681 bytes --]
On Thu, Dec 12, 2013 at 06:44:45PM +0800, Nicolin Chen wrote:
> +/**
> + * fsl_ssi_set_dai_tdm_slot - set TDM slot number
> + *
> + * Note: This function can be only called when using SSI as DAI master
> + */
> +static int fsl_ssi_set_dai_tdm_slot(struct snd_soc_dai *cpu_dai, u32 tx_mask,
> + u32 rx_mask, int slots, int slot_width)
> +{
> + struct fsl_ssi_private *ssi_private = snd_soc_dai_get_drvdata(cpu_dai);
> + struct ccsr_ssi __iomem *ssi = ssi_private->ssi;
> + u32 val;
I'm a bit concernred about what this is for and why it's required - is
it something that machine drivers have to call and if it is shouldn't
the driver be defaulting to a sensible configuration?
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] rapidio: add modular rapidio core build into powerpc and mips branches
From: Alexandre Bounine @ 2013-12-18 18:57 UTC (permalink / raw)
To: Andrew Morton, linux-kernel, linuxppc-dev
Cc: linux-mips, Ralf Baechle, Alexandre Bounine, Jean Delvare
Allow modular build option for RapidIO subsystem core in MIPS and PowerPC
architectural branches.
At this moment modular RapidIO subsystem build is enabled only for platforms
that use PCI/PCIe based RapidIO controllers (e.g. Tsi721).
Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Jean Delvare <jdelvare@suse.de>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Li Yang <leoli@freescale.com>
Cc: linux-mips@linux-mips.org
---
arch/mips/Kconfig | 2 +-
arch/powerpc/Kconfig | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 650de39..e6a8a7a 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -2442,7 +2442,7 @@ source "drivers/pcmcia/Kconfig"
source "drivers/pci/hotplug/Kconfig"
config RAPIDIO
- bool "RapidIO support"
+ tristate "RapidIO support"
depends on PCI
default n
help
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index b44b52c..992531f 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -790,7 +790,7 @@ config HAS_RAPIDIO
default n
config RAPIDIO
- bool "RapidIO support"
+ tristate "RapidIO support"
depends on HAS_RAPIDIO || PCI
help
If you say Y here, the kernel will include drivers and
@@ -798,7 +798,7 @@ config RAPIDIO
config FSL_RIO
bool "Freescale Embedded SRIO Controller support"
- depends on RAPIDIO && HAS_RAPIDIO
+ depends on RAPIDIO = y && HAS_RAPIDIO
default "n"
---help---
Include support for RapidIO controller on Freescale embedded
--
1.7.8.4
^ permalink raw reply related
* Re: [PATCH v1 0/4] powerpc/512x: update COMMON_CLK support for MPC5125
From: Anatolij Gustschin @ 2013-12-18 19:53 UTC (permalink / raw)
To: Gerhard Sittig
Cc: Mike Turquette, Detlev Zundel, Matteo Facchinetti, Scott Wood,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <1386681097-14126-1-git-send-email-gsi@denx.de>
On Tue, 10 Dec 2013 14:11:33 +0100
Gerhard Sittig <gsi@denx.de> wrote:
...
> Gerhard Sittig (4):
> powerpc/512x: clk: minor comment updates
> powerpc/512x: clk: enforce even SDHC divider values
> powerpc/512x: clk: support MPC5121/5123/5125 SoC variants
> powerpc/512x: dts: add MPC5125 clock specs
>
> arch/powerpc/boot/dts/mpc5125twr.dts | 53 +++-
> arch/powerpc/include/asm/mpc5121.h | 7 +-
> arch/powerpc/platforms/512x/clock-commonclk.c | 369 +++++++++++++++++++++----
> include/dt-bindings/clock/mpc512x-clock.h | 9 +-
> 4 files changed, 386 insertions(+), 52 deletions(-)
Applied this series to mpc5xxx next. Thanks!
Anatolij
^ permalink raw reply
* Re: [PATCH v1 1/1] powerpc/512x: dts: remove misplaced IRQ spec from 'soc' node (5125)
From: Anatolij Gustschin @ 2013-12-18 19:54 UTC (permalink / raw)
To: Gerhard Sittig; +Cc: devicetree, linuxppc-dev
In-Reply-To: <1386669068-2477-1-git-send-email-gsi@denx.de>
On Tue, 10 Dec 2013 10:51:08 +0100
Gerhard Sittig <gsi@denx.de> wrote:
> the 'soc' node in the MPC5125 "tower" board .dts has an '#interrupt-cells'
> property although this node is not an interrupt controller
>
> remove this erroneously placed property because starting with v3.13-rc1
> lookup and resolution of 'interrupts' specs for peripherals gets misled
> (tries to use the 'soc' as the interrupt parent which fails), emits
> 'no irq domain found' WARN() messages and breaks the boot process
>
> [ best viewed with 'git diff -U5' to have DT node names in the context ]
>
> Cc: Anatolij Gustschin <agust@denx.de>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Gerhard Sittig <gsi@denx.de>
>
> ---
>
> note that this is not a resend of the previous MPC5121 fix, but instead
> is a fix for MPC5125 along the same lines of the MPC5121 fix
> ---
> arch/powerpc/boot/dts/mpc5125twr.dts | 1 -
> 1 file changed, 1 deletion(-)
Applied. Thanks!
Anatolij
^ permalink raw reply
* Re: [PATCH] powerpc: book3s: kvm: Use the saved dsisr and dar values
From: Alexander Graf @ 2013-12-18 21:44 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Paul Mackerras, linuxppc-dev, kvm-ppc,
kvm@vger.kernel.org mailing list
In-Reply-To: <1384178577-23721-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On 11.11.2013, at 15:02, Aneesh Kumar K.V =
<aneesh.kumar@linux.vnet.ibm.com> wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>=20
> Don't try to compute these values.
>=20
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> ---
>=20
> NOTE: I am not sure why we were originally computing dsisr and dar. So =
may be
> we need a variant of this patch. But with this and the additional =
patch
> "powerpc: book3s: PR: Enable Little Endian PR guest" I am able to get =
a Little Endian
> PR guest to boot.
It's quite easy to find out - git blame tells you all the history and =
points you to commit ca7f4203b.
commit ca7f4203b9b66e12d0d9968ff7dfe781f3a9695a
Author: Alexander Graf <agraf@suse.de>
Date: Wed Mar 24 21:48:28 2010 +0100
KVM: PPC: Implement alignment interrupt
Mac OS X has some applications - namely the Finder - that require =
alignment
interrupts to work properly. So we need to implement them.
But the spec for 970 and 750 also looks different. While 750 =
requires the
DSISR and DAR fields to reflect some instruction bits (DSISR) and =
the fault
address (DAR), the 970 declares this as an optional feature. So we =
need
to reconstruct DSISR and DAR manually.
Signed-off-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Avi Kivity <avi@redhat.com>
Read this as "on 970, alignment interrupts don't give us DSISR and DAR =
of the faulting instruction" as otherwise I wouldn't have implemented =
it.
So this is clearly a nack on this patch :).
Alex
^ permalink raw reply
* RE: [PATCH v2 00/10] Kconfig: cleanup SERIO_I8042 dependencies
From: Luck, Tony @ 2013-12-18 21:59 UTC (permalink / raw)
To: Mark Salter, linux-kernel@vger.kernel.org
Cc: Yu, Fenghua, x86@kernel.org, Russell King,
linux-mips@linux-mips.org, linux-sh@vger.kernel.org,
Dmitry Torokhov, Ingo Molnar, Paul Mundt, Paul Mackerras,
linux-alpha@vger.kernel.org, sparclinux@vger.kernel.org,
linux-ia64@vger.kernel.org, Thomas Gleixner, Guan Xuetao,
linuxppc-dev@lists.ozlabs.org, David S. Miller,
linux-arm-kernel@lists.infradead.org, Richard Henderson
In-Reply-To: <1387295333-24684-1-git-send-email-msalter@redhat.com>
> This is v2 of the patch series. Changes from version 1:
>
> o Added acks. arm, ia64, and sh are only ones without acks.
ia64 bits look OK
Acked-by: Tony Luck <tony.luck@intel.com>
^ permalink raw reply
* Re: [PATCH v1 0/4] powerpc/512x: update COMMON_CLK support for MPC5125
From: Mike Turquette @ 2013-12-18 22:20 UTC (permalink / raw)
To: Gerhard Sittig, linuxppc-dev, linux-arm-kernel,
Anatolij Gustschin, Matteo Facchinetti
Cc: Scott Wood, Gerhard Sittig, Detlev Zundel
In-Reply-To: <1386681097-14126-1-git-send-email-gsi@denx.de>
Quoting Gerhard Sittig (2013-12-10 05:11:33)
> this series improves the previously introduced common clock support for
> MPC512x such that SoC variants 5123 and 5125 get addressed appropriately
> (MPC5125 turned out to be rather different from MPC5121 than I perceived
> before -- there is much more than "just two FECs and no MBX")
> =
> thus this series depends on "add COMMON_CLK support for PowerPC MPC512x"
> (v6 sent in <1385851897-23475-1-git-send-email-gsi@denx.de>, applicable
> on top of v3.13-rc1 or later, currently applied to mpc5xxx -next,
> available at git://git.denx.de/linux-2.6-agust.git next)
> =
> this series does not address the issue of outdated or missing device
> tree binding documentation for MPC512x peripherals -- that's the scope
> of a pending separate series
For the three clock patches:
Acked-by: Mike Turquette <mturquette@linaro.org>
> =
> v1 initial submission (2013-12-10)
> - enforce an even divider value for SDHC (on all MPC512x variants)
> - tell 5121/5123/5125 SoC variants apart and only register the
> appropriate set of clock items (i.e. refuse to access unused and
> reserved bits, and support those components which are only found on
> MPC5125)
> - update the MPC5125 "tower" board DTS (although the code still works in
> the absence of device tree clock specs)
> =
> the series passes 'checkpatch.pl --strict' except for two warnings which
> cannot get fixed because <linux/clk-provider.h> dictates the data type
> and "fixing" the warning would break the build
> =
> WARNING: static const char * array should probably be static const char=
* const
> #256: FILE: arch/powerpc/platforms/512x/clock-commonclk.c:500:
> +static const char *parent_names_mux0_spdif[] =3D {
> =
> WARNING: static const char * array should probably be static const char=
* const
> #260: FILE: arch/powerpc/platforms/512x/clock-commonclk.c:504:
> +static const char *parent_names_mux0_canin[] =3D {
> =
> total: 0 errors, 2 warnings, 0 checks, 495 lines checked
> =
> the series was build-tested, and was run-tested on the MPC5121 ADS board
> =
> Matteo, can you verify the crystal frequency in the DTS update, please?
> And that v3.13-rc kernels with v6 of the COMMON_CLK introduction for
> MPC512x plus this series for MPC5125 operate your peripherals, both with
> an updated device tree as well as with a former device tree that lacks
> clock specs? Thank you! Setting CONFIG_COMMON_CLK_DEBUG=3Dy in your
> .config and eyeballing /sys/kernel/debug/clk/clk_summary will help you.
> =
> Gerhard Sittig (4):
> powerpc/512x: clk: minor comment updates
> powerpc/512x: clk: enforce even SDHC divider values
> powerpc/512x: clk: support MPC5121/5123/5125 SoC variants
> powerpc/512x: dts: add MPC5125 clock specs
> =
> arch/powerpc/boot/dts/mpc5125twr.dts | 53 +++-
> arch/powerpc/include/asm/mpc5121.h | 7 +-
> arch/powerpc/platforms/512x/clock-commonclk.c | 369 +++++++++++++++++++=
++----
> include/dt-bindings/clock/mpc512x-clock.h | 9 +-
> 4 files changed, 386 insertions(+), 52 deletions(-)
> =
> -- =
> 1.7.10.4
>=20
^ permalink raw reply
* Re: [v3, 3/7] powerpc: enable the relocatable support for the fsl booke 32bit kernel
From: Scott Wood @ 2013-12-18 23:48 UTC (permalink / raw)
To: Kevin Hao; +Cc: linuxppc
In-Reply-To: <1375838315-27797-4-git-send-email-haokexin@gmail.com>
On Wed, Aug 07, 2013 at 09:18:31AM +0800, Kevin Hao wrote:
> This is based on the codes in the head_44x.S. The difference is that
> the init tlb size we used is 64M. With this patch we can only load the
> kernel at address between memstart_addr ~ memstart_addr + 64M. We will
> fix this restriction in the following patches.
Which following patch fixes the restriction? With all seven patches
applied, I was still only successful booting within 64M of memstart_addr.
-Scott
^ permalink raw reply
* Re: [2/2,v8] powerpc/fsl-booke: Add initial T104x_QDS board support
From: Scott Wood @ 2013-12-19 0:50 UTC (permalink / raw)
To: Prabhakar Kushwaha; +Cc: Poonam Aggrwal, linuxppc-dev, Priyanka Jain
In-Reply-To: <1380771889-2626-1-git-send-email-prabhakar@freescale.com>
On Thu, Oct 03, 2013 at 09:14:49AM +0530, Prabhakar Kushwaha wrote:
> diff --git a/arch/powerpc/boot/dts/t104xqds.dtsi b/arch/powerpc/boot/dts/t104xqds.dtsi
> new file mode 100644
> index 0000000..5a518b3
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/t104xqds.dtsi
[snip]
> +/ {
> + model = "fsl,T1040QDS";
> + compatible = "fsl,T1040QDS";
Remove model/compatible; they're supplied by the includer of this file.
> + nand@2,0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "fsl,ifc-nand";
> + reg = <0x2 0x0 0x10000>;
> +
> + partition@0 {
> + /* This location must not be altered */
> + /* 1MB for u-boot Bootloader Image */
> + reg = <0x0 0x00100000>;
> + label = "NAND U-Boot Image";
> + read-only;
> + };
> +
> + partition@100000 {
> + /* 1MB for DTB Image */
> + reg = <0x00100000 0x00100000>;
> + label = "NAND DTB Image";
> + };
> +
> + partition@200000 {
> + /* 10MB for Linux Kernel Image */
> + reg = <0x00200000 0x00A00000>;
> + label = "NAND Linux Kernel Image";
> + };
> +
> + partition@C00000 {
> + /* 500MB for Root file System Image */
> + reg = <0x00c00000 0x1F400000>;
> + label = "NAND RFS Image";
> + };
> + };
I'd really like to see us stop putting partition info in the dts files.
Alternatives are using the mtdparts command line option, or having U-Boot
use the mtdparts environment variable to add partition info to the dtb
(there's already code for this).
> + board-control@3,0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "fsl,tetra-fpga", "fsl,fpga-qixis";
> + reg = <3 0 0x300>;
> + };
Could you explain the relationship between "tetra" and "qixis"?
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc: book3s: kvm: Use the saved dsisr and dar values
From: Paul Mackerras @ 2013-12-19 2:26 UTC (permalink / raw)
To: Alexander Graf
Cc: linuxppc-dev, Aneesh Kumar K.V, kvm-ppc,
kvm@vger.kernel.org mailing list
In-Reply-To: <0AB88010-F2B7-44A1-8FA9-2A40079706BB@suse.de>
On Wed, Dec 18, 2013 at 10:44:08PM +0100, Alexander Graf wrote:
>
> On 11.11.2013, at 15:02, Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> wrote:
>
> > From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
> >
> > Don't try to compute these values.
> >
> > Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> > ---
> >
> > NOTE: I am not sure why we were originally computing dsisr and dar. So may be
> > we need a variant of this patch. But with this and the additional patch
> > "powerpc: book3s: PR: Enable Little Endian PR guest" I am able to get a Little Endian
> > PR guest to boot.
>
> It's quite easy to find out - git blame tells you all the history and points you to commit ca7f4203b.
>
> commit ca7f4203b9b66e12d0d9968ff7dfe781f3a9695a
> Author: Alexander Graf <agraf@suse.de>
> Date: Wed Mar 24 21:48:28 2010 +0100
>
> KVM: PPC: Implement alignment interrupt
>
> Mac OS X has some applications - namely the Finder - that require alignment
> interrupts to work properly. So we need to implement them.
>
> But the spec for 970 and 750 also looks different. While 750 requires the
> DSISR and DAR fields to reflect some instruction bits (DSISR) and the fault
> address (DAR), the 970 declares this as an optional feature. So we need
> to reconstruct DSISR and DAR manually.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
> Signed-off-by: Avi Kivity <avi@redhat.com>
>
> Read this as "on 970, alignment interrupts don't give us DSISR and DAR of the faulting instruction" as otherwise I wouldn't have implemented it.
Although it's optional, all IBM POWER cpus, and as far as I know all
PowerPC cpus, set DAR on an alignment interrupt to the effective
address being accessed. You have a valid point regarding DSISR, but
it would be nice to skip the computations where either the host CPU
provides the bits, or the virtual CPU doesn't.
Paul.
^ permalink raw reply
* Re: [RFC][PATCH v1] ASoC: fsl_ssi: Add DAI master mode support for SSI on i.MX series
From: Nicolin Chen @ 2013-12-19 2:14 UTC (permalink / raw)
To: Mark Brown; +Cc: alsa-devel, lgirdwood, tiwai, timur, perex, linuxppc-dev
In-Reply-To: <20131218185952.GM31886@sirena.org.uk>
On Wed, Dec 18, 2013 at 06:59:52PM +0000, Mark Brown wrote:
> On Thu, Dec 12, 2013 at 06:44:45PM +0800, Nicolin Chen wrote:
>
> > +/**
> > + * fsl_ssi_set_dai_tdm_slot - set TDM slot number
> > + *
> > + * Note: This function can be only called when using SSI as DAI master
> > + */
> > +static int fsl_ssi_set_dai_tdm_slot(struct snd_soc_dai *cpu_dai, u32 tx_mask,
> > + u32 rx_mask, int slots, int slot_width)
> > +{
> > + struct fsl_ssi_private *ssi_private = snd_soc_dai_get_drvdata(cpu_dai);
> > + struct ccsr_ssi __iomem *ssi = ssi_private->ssi;
> > + u32 val;
>
> I'm a bit concernred about what this is for and why it's required - is
> it something that machine drivers have to call and if it is shouldn't
> the driver be defaulting to a sensible configuration?
SSI can control how many slots to generate and which slot to send data. Yes,
the normal case, which should be defaulting to normal two slots I2S case, can
be configured by SSI driver itself as you mentioned. I'll add it to startup().
Then only those machine drivers using multiple slots (>2) need to call it.
Thank you for the comments.
Nicolin Chen
^ permalink raw reply
* Re: commit e38c0a1f breaks powerpc boards with uli1575 chip
From: Nikita Yushchenko @ 2013-12-19 4:42 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree@vger.kernel.org, Arnd Bergmann, Dmitry Krivoschekov,
Alexey Lugovskoy, Thierry Reding, linux-kernel, Grant Likely,
linuxppc-dev
In-Reply-To: <52B1EC15.5070606@gmail.com>
> Reverting would break Tegra PCIe, but you should not have to change the
> DT either. So we need a solution.
>
> Is this something like this sufficient to fix it?
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 4b9317b..378aebd 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -74,7 +74,7 @@ static u64 of_bus_default_map(__be32 *addr, const
> __be32 *range,
> * mapping doesn't specify a physical address. Rather, the
> address * specifies an identifier that must match exactly.
> */
> - if (na > 2 && memcmp(range, addr, na * 4) != 0)
> + if (na > 2 && memcmp(range, addr, (na - 2) * 4) != 0)
> return OF_BAD_ADDR;
>
> if (da < cp || da >= (cp + s))
No, this does not help.
I've dumped the actual content of 'range' and 'addr' at the failure point
(i.e. ar point that returns error with e38c0a1f but passes without
e38c0a1f ):
OF: default map, cp=0, s=10000, da=70
range: 01 00 00 00 00 00 00 00 00 00 00 00
addr: 00 00 00 00 00 00 00 00 00 00 00 70
Nikita
^ permalink raw reply
* Re: [PATCH] powerpc: book3s: kvm: Use the saved dsisr and dar values
From: Aneesh Kumar K.V @ 2013-12-19 7:02 UTC (permalink / raw)
To: Alexander Graf
Cc: Paul Mackerras, linuxppc-dev, kvm-ppc,
kvm@vger.kernel.org mailing list
In-Reply-To: <0AB88010-F2B7-44A1-8FA9-2A40079706BB@suse.de>
Alexander Graf <agraf@suse.de> writes:
> On 11.11.2013, at 15:02, Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> wrote:
>
>> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>>
>> Don't try to compute these values.
>>
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>> ---
>>
>> NOTE: I am not sure why we were originally computing dsisr and dar. So may be
>> we need a variant of this patch. But with this and the additional patch
>> "powerpc: book3s: PR: Enable Little Endian PR guest" I am able to get a Little Endian
>> PR guest to boot.
>
> It's quite easy to find out - git blame tells you all the history and points you to commit ca7f4203b.
>
> commit ca7f4203b9b66e12d0d9968ff7dfe781f3a9695a
> Author: Alexander Graf <agraf@suse.de>
> Date: Wed Mar 24 21:48:28 2010 +0100
>
> KVM: PPC: Implement alignment interrupt
>
> Mac OS X has some applications - namely the Finder - that require alignment
> interrupts to work properly. So we need to implement them.
>
> But the spec for 970 and 750 also looks different. While 750 requires the
> DSISR and DAR fields to reflect some instruction bits (DSISR) and the fault
> address (DAR), the 970 declares this as an optional feature. So we need
> to reconstruct DSISR and DAR manually.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
> Signed-off-by: Avi Kivity <avi@redhat.com>
>
> Read this as "on 970, alignment interrupts don't give us DSISR and DAR of the faulting instruction" as otherwise I wouldn't have implemented it.
>
> So this is clearly a nack on this patch :).
I can possibly do a if (cpu_has_feature(CPU_FTR_ARCH_201)). But do we need
to do that ? According to Paul we should always find DAR.
-aneesh
^ permalink raw reply
* [PATCH] powerpc/512x: dts: disable MPC5125 usb module
From: Matteo Facchinetti @ 2013-12-19 10:23 UTC (permalink / raw)
To: linuxppc-dev; +Cc: gsi, agust
USB controller pin-muxing is not initialized correctly and when system boot,
causes a kernel panic.
USB controller is also connected with a USB3320 ulpi tranciever and
DTS should be includes the correct dependency for initialize and activate
this component.
Signed-off-by: Matteo Facchinetti <matteo.facchinetti@sirius-es.it>
---
arch/powerpc/boot/dts/mpc5125twr.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/boot/dts/mpc5125twr.dts b/arch/powerpc/boot/dts/mpc5125twr.dts
index 806479f..85452a7 100644
--- a/arch/powerpc/boot/dts/mpc5125twr.dts
+++ b/arch/powerpc/boot/dts/mpc5125twr.dts
@@ -230,6 +230,9 @@
};
usb@3000 {
+ /* TODO correct pinmux config and fix USB3320 ulpi dependency */
+ status = "disabled";
+
compatible = "fsl,mpc5121-usb2-dr";
reg = <0x3000 0x400>;
#address-cells = <1>;
--
1.8.3.2
^ permalink raw reply related
* Re: [RFC][PATCH v1] ASoC: fsl_ssi: Add DAI master mode support for SSI on i.MX series
From: Mark Brown @ 2013-12-19 10:48 UTC (permalink / raw)
To: Nicolin Chen; +Cc: alsa-devel, lgirdwood, tiwai, timur, perex, linuxppc-dev
In-Reply-To: <1386845085-21682-1-git-send-email-Guangyu.Chen@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 502 bytes --]
On Thu, Dec 12, 2013 at 06:44:45PM +0800, Nicolin Chen wrote:
> From: Nicolin Chen <b42378@freescale.com>
>
> This patch adds three main functions for DAI master mode: set_dai_fmt(),
> set_dai_sysclk() and set_dai_tdm_slot(), and one essential baud clock
> accordingly. After appending this patch, the fsl_ssi driver on i.MX series
> has the ability to derive LRCLK and BCLK from baud clock source so as to
> support some audio Codecs which can only be used in slave mode.
Applied, thanks.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/512x: dts: disable MPC5125 usb module
From: Gerhard Sittig @ 2013-12-19 12:30 UTC (permalink / raw)
To: Matteo Facchinetti; +Cc: agust, linuxppc-dev
In-Reply-To: <1387448639-11050-1-git-send-email-matteo.facchinetti@sirius-es.it>
On Thu, Dec 19, 2013 at 11:23 +0100, Matteo Facchinetti wrote:
>
> USB controller pin-muxing is not initialized correctly and when system boot,
> causes a kernel panic.
> USB controller is also connected with a USB3320 ulpi tranciever and
> DTS should be includes the correct dependency for initialize and activate
> this component.
>
> Signed-off-by: Matteo Facchinetti <matteo.facchinetti@sirius-es.it>
> ---
> arch/powerpc/boot/dts/mpc5125twr.dts | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/powerpc/boot/dts/mpc5125twr.dts b/arch/powerpc/boot/dts/mpc5125twr.dts
> index 806479f..85452a7 100644
> --- a/arch/powerpc/boot/dts/mpc5125twr.dts
> +++ b/arch/powerpc/boot/dts/mpc5125twr.dts
> @@ -230,6 +230,9 @@
> };
>
> usb@3000 {
> + /* TODO correct pinmux config and fix USB3320 ulpi dependency */
> + status = "disabled";
> +
> compatible = "fsl,mpc5121-usb2-dr";
> reg = <0x3000 0x400>;
> #address-cells = <1>;
> --
> 1.8.3.2
I agree on the change to the board dts file, but suggest to
reword the commit description for improved reception.
I feel it's worth trying to phrase the subject line, the commit
message, and the patch such that they can get considered
independently from each other, as not all of them are necessarily
available at the same time. Often they get looked up from
different perspectives, like terse listing first for orientation,
log with description then to determine whether to have a closer
look, the patch only at the end after the other checks told you
to look into more details. Assuming that they always show up in
combination may turn out to be inaccurate.
So I suggest some text along those lines:
at the moment the USB controller's pin muxing is not setup
correctly and causes a kernel panic upon system startup, so
disable the USB1 device tree node in the MPC5125 tower board
dts file
the USB controller is connected to an USB3320 ULPI transceiver
and the device tree should receive an update to reflect correct
dependencies and required initialization data before the USB1
node can get re-enabled
Does that sound correct to you? Does it reflect your intention,
or did I put something in wrong terms?
A minor nit would be that other reviewers in the past suggested
to put the 'status = "disabled"' line last in the list of
properties (right before optional children). I don't have strong
feelings about this. Putting it first might better reflect your
motivation of only re-enabling the node after fixing the lack or
inappropriateness of existing information first.
A different matter is that I'd suggest to re-work the MPC5125
device tree. It recently escaped my attention because it did not
share any information with the MPC5121 trees. Comparing the
MPC5125 board DTS with the MPC5121 DTS include file resulted in a
lot of unnecessary "differences" that turned out to be whitespace
or comment style only, or differences in the order of nodes.
There were only few real differences in the information, and the
MPC5125 device tree appears to only describe a subset of what the
SoC actually contains.
It may be worth looking into
- identifying common parts that are shared among the MPC5121 and
MPC5125 (my recent CCF update lists differences, but does not
explicitly list similarities, and is from the clocks
perspective and may not cover all of the SoC components)
- putting those common parts into .dtsi files if possible
- making the MPC5125 tower board reference the DTS includes,
sharing as much as possible with the other SoC variants
This may involve another split of the mpc5121.dtsi into what's
common to all MPC512x variants, and what's exclusive to MPC5121
only.
But that is a bigger task than the above quick adjustment, and is
not a required fix but just an improvement in maintainability or
completeness of information. So I suggest to pick your USB1
disabling for -next and 3.14 now, and to address the DTS cleanup
and sharing later.
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* Re: [PATCH] powerpc: book3s: kvm: Use the saved dsisr and dar values
From: Alexander Graf @ 2013-12-19 12:35 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Paul Mackerras, linuxppc-dev@lists.ozlabs.org,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org mailing list
In-Reply-To: <87bo0d9vc5.fsf@linux.vnet.ibm.com>
> Am 19.12.2013 um 08:02 schrieb "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet=
.ibm.com>:
>=20
> Alexander Graf <agraf@suse.de> writes:
>=20
>>> On 11.11.2013, at 15:02, Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.c=
om> wrote:
>>>=20
>>> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>>>=20
>>> Don't try to compute these values.
>>>=20
>>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>>> ---
>>>=20
>>> NOTE: I am not sure why we were originally computing dsisr and dar. So m=
ay be
>>> we need a variant of this patch. But with this and the additional patch
>>> "powerpc: book3s: PR: Enable Little Endian PR guest" I am able to get a L=
ittle Endian
>>> PR guest to boot.
>>=20
>> It's quite easy to find out - git blame tells you all the history and poi=
nts you to commit ca7f4203b.
>>=20
>> commit ca7f4203b9b66e12d0d9968ff7dfe781f3a9695a
>> Author: Alexander Graf <agraf@suse.de>
>> Date: Wed Mar 24 21:48:28 2010 +0100
>>=20
>> KVM: PPC: Implement alignment interrupt
>>=20
>> Mac OS X has some applications - namely the Finder - that require alig=
nment
>> interrupts to work properly. So we need to implement them.
>>=20
>> But the spec for 970 and 750 also looks different. While 750 requires t=
he
>> DSISR and DAR fields to reflect some instruction bits (DSISR) and the f=
ault
>> address (DAR), the 970 declares this as an optional feature. So we nee=
d
>> to reconstruct DSISR and DAR manually.
>>=20
>> Signed-off-by: Alexander Graf <agraf@suse.de>
>> Signed-off-by: Avi Kivity <avi@redhat.com>
>>=20
>> Read this as "on 970, alignment interrupts don't give us DSISR and DAR of=
the faulting instruction" as otherwise I wouldn't have implemented it.
>>=20
>> So this is clearly a nack on this patch :).
>=20
> I can possibly do a if (cpu_has_feature(CPU_FTR_ARCH_201)). But do we need=
> to do that ? According to Paul we should always find DAR.
Paul only mentioned DAR, not DSISR. Please verify whether 970 gives us a pro=
per DAR value - we can then remove that part.
But for DSISR I'm not convinced CPUs above 970 handle this correctly. So we w=
ould at least need a guest cpu check to find out whether the vcpu expects a w=
orking dsisr and emulate it then.
I don't really fully understand the problem though. Why does the calculation=
break at all for you?
Alex
^ permalink raw reply
* Re: [PATCH] powerpc: Make 64-bit non-VMX __copy_tofrom_user bi-endian
From: Michael Ellerman @ 2013-12-19 13:17 UTC (permalink / raw)
To: Anton Blanchard; +Cc: paulmck, paulus, linuxppc-dev
In-Reply-To: <20131218211502.034c3eb0@kryten>
On Wed, 2013-12-18 at 21:15 +1100, Anton Blanchard wrote:
> Hi,
>
> > [ This is a rare but nasty LE issue. Most of the time we use the
> > POWER7 optimised __copy_tofrom_user_power7 loop, but when it hits an
> > exception we fall back to the base __copy_tofrom_user loop. - Anton ]
>
> To try and catch any screw ups in our ppc64 memcpy and copy_tofrom_user
> loops, I wrote a quick test:
>
> http://ozlabs.org/~anton/junkcode/validate_kernel_copyloops.tar.gz
Nice! How's this look?
cheers
selftests: Import Anton's memcpy / copy_tofrom_user tests
Turn Anton's memcpy / copy_tofrom_user test into something that can
live in tools/testing/selftests.
It requires one turd in arch/powerpc/lib/memcpy_64.S, but it's pretty
harmless IMHO.
We are sailing very close to the wind with the feature macros. We define
them to nothing, which currently means we get a few extra nops and
include the unaligned calls.
---
arch/powerpc/lib/memcpy_64.S | 2 +
tools/testing/selftests/powerpc/Makefile | 2 +-
tools/testing/selftests/powerpc/copyloops/Makefile | 29 +++++++
.../selftests/powerpc/copyloops/asm/ppc_asm.h | 86 +++++++++++++++++++
.../selftests/powerpc/copyloops/asm/processor.h | 0
.../selftests/powerpc/copyloops/copyuser_64.S | 1 +
.../selftests/powerpc/copyloops/copyuser_power7.S | 1 +
.../selftests/powerpc/copyloops/memcpy_64.S | 1 +
.../selftests/powerpc/copyloops/memcpy_power7.S | 1 +
.../testing/selftests/powerpc/copyloops/validate.c | 99 ++++++++++++++++++++++
tools/testing/selftests/powerpc/utils.h | 3 +
11 files changed, 224 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/powerpc/copyloops/Makefile
create mode 100644 tools/testing/selftests/powerpc/copyloops/asm/ppc_asm.h
create mode 100644 tools/testing/selftests/powerpc/copyloops/asm/processor.h
create mode 120000 tools/testing/selftests/powerpc/copyloops/copyuser_64.S
create mode 120000 tools/testing/selftests/powerpc/copyloops/copyuser_power7.S
create mode 120000 tools/testing/selftests/powerpc/copyloops/memcpy_64.S
create mode 120000 tools/testing/selftests/powerpc/copyloops/memcpy_power7.S
create mode 100644 tools/testing/selftests/powerpc/copyloops/validate.c
diff --git a/arch/powerpc/lib/memcpy_64.S b/arch/powerpc/lib/memcpy_64.S
index d2bbbc8..72ad055 100644
--- a/arch/powerpc/lib/memcpy_64.S
+++ b/arch/powerpc/lib/memcpy_64.S
@@ -14,7 +14,9 @@ _GLOBAL(memcpy)
BEGIN_FTR_SECTION
std r3,48(r1) /* save destination pointer for return value */
FTR_SECTION_ELSE
+#ifndef SELFTEST
b memcpy_power7
+#endif
ALT_FTR_SECTION_END_IFCLR(CPU_FTR_VMX_COPY)
PPC_MTOCRF(0x01,r5)
cmpldi cr1,r5,16
diff --git a/tools/testing/selftests/powerpc/Makefile b/tools/testing/selftests/powerpc/Makefile
index bd24ae5..316194f 100644
--- a/tools/testing/selftests/powerpc/Makefile
+++ b/tools/testing/selftests/powerpc/Makefile
@@ -13,7 +13,7 @@ CFLAGS := -Wall -O2 -flto -Wall -Werror -DGIT_VERSION='"$(GIT_VERSION)"' -I$(CUR
export CC CFLAGS
-TARGETS = pmu
+TARGETS = pmu copyloops
endif
diff --git a/tools/testing/selftests/powerpc/copyloops/Makefile b/tools/testing/selftests/powerpc/copyloops/Makefile
new file mode 100644
index 0000000..6f2d3be
--- /dev/null
+++ b/tools/testing/selftests/powerpc/copyloops/Makefile
@@ -0,0 +1,29 @@
+# The loops are all 64-bit code
+CFLAGS += -m64
+CFLAGS += -I$(CURDIR)
+CFLAGS += -D SELFTEST
+
+# Use our CFLAGS for the implicit .S rule
+ASFLAGS = $(CFLAGS)
+
+PROGS := copyuser_64 copyuser_power7 memcpy_64 memcpy_power7
+EXTRA_SOURCES := validate.c ../harness.c
+
+all: $(PROGS)
+
+copyuser_64: CPPFLAGS += -D COPY_LOOP=test___copy_tofrom_user_base
+copyuser_power7: CPPFLAGS += -D COPY_LOOP=test___copy_tofrom_user_power7
+memcpy_64: CPPFLAGS += -D COPY_LOOP=test_memcpy
+memcpy_power7: CPPFLAGS += -D COPY_LOOP=test_memcpy_power7
+
+$(PROGS): $(EXTRA_SOURCES)
+
+run_tests: all
+ @-for PROG in $(PROGS); do \
+ ./$$PROG; \
+ done;
+
+clean:
+ rm -f $(PROGS) *.o
+
+.PHONY: all run_tests clean
diff --git a/tools/testing/selftests/powerpc/copyloops/asm/ppc_asm.h b/tools/testing/selftests/powerpc/copyloops/asm/ppc_asm.h
new file mode 100644
index 0000000..ccd9c84
--- /dev/null
+++ b/tools/testing/selftests/powerpc/copyloops/asm/ppc_asm.h
@@ -0,0 +1,86 @@
+#include <ppc-asm.h>
+
+#define CONFIG_ALTIVEC
+
+#define r1 1
+
+#define vr0 0
+#define vr1 1
+#define vr2 2
+#define vr3 3
+#define vr4 4
+#define vr5 5
+#define vr6 6
+#define vr7 7
+#define vr8 8
+#define vr9 9
+#define vr10 10
+#define vr11 11
+#define vr12 12
+#define vr13 13
+#define vr14 14
+#define vr15 15
+#define vr16 16
+#define vr17 17
+#define vr18 18
+#define vr19 19
+#define vr20 20
+#define vr21 21
+#define vr22 22
+#define vr23 23
+#define vr24 24
+#define vr25 25
+#define vr26 26
+#define vr27 27
+#define vr28 28
+#define vr29 29
+#define vr30 30
+#define vr31 31
+
+#define R14 r14
+#define R15 r15
+#define R16 r16
+#define R17 r17
+#define R18 r18
+#define R19 r19
+#define R20 r20
+#define R21 r21
+#define R22 r22
+
+#define STACKFRAMESIZE 256
+#define STK_PARAM(i) (48 + ((i)-3)*8)
+#define STK_REG(i) (112 + ((i)-14)*8)
+
+#define _GLOBAL(A) FUNC_START(test_ ## A)
+
+#define PPC_MTOCRF(A, B) mtocrf A, B
+
+FUNC_START(enter_vmx_usercopy)
+ li r3,1
+ blr
+
+FUNC_START(exit_vmx_usercopy)
+ li r3,0
+ blr
+
+FUNC_START(enter_vmx_copy)
+ li r3,1
+ blr
+
+FUNC_START(exit_vmx_copy)
+ blr
+
+FUNC_START(memcpy_power7)
+ blr
+
+FUNC_START(__copy_tofrom_user_power7)
+ blr
+
+FUNC_START(__copy_tofrom_user_base)
+ blr
+
+#define BEGIN_FTR_SECTION
+#define FTR_SECTION_ELSE
+#define ALT_FTR_SECTION_END_IFCLR(x)
+#define ALT_FTR_SECTION_END(x, y)
+#define END_FTR_SECTION_IFCLR(x)
diff --git a/tools/testing/selftests/powerpc/copyloops/asm/processor.h b/tools/testing/selftests/powerpc/copyloops/asm/processor.h
new file mode 100644
index 0000000..e69de29
diff --git a/tools/testing/selftests/powerpc/copyloops/copyuser_64.S b/tools/testing/selftests/powerpc/copyloops/copyuser_64.S
new file mode 120000
index 0000000..f1c418a
--- /dev/null
+++ b/tools/testing/selftests/powerpc/copyloops/copyuser_64.S
@@ -0,0 +1 @@
+../../../../../arch/powerpc/lib/copyuser_64.S
\ No newline at end of file
diff --git a/tools/testing/selftests/powerpc/copyloops/copyuser_power7.S b/tools/testing/selftests/powerpc/copyloops/copyuser_power7.S
new file mode 120000
index 0000000..4786895
--- /dev/null
+++ b/tools/testing/selftests/powerpc/copyloops/copyuser_power7.S
@@ -0,0 +1 @@
+../../../../../arch/powerpc/lib/copyuser_power7.S
\ No newline at end of file
diff --git a/tools/testing/selftests/powerpc/copyloops/memcpy_64.S b/tools/testing/selftests/powerpc/copyloops/memcpy_64.S
new file mode 120000
index 0000000..cce33fb
--- /dev/null
+++ b/tools/testing/selftests/powerpc/copyloops/memcpy_64.S
@@ -0,0 +1 @@
+../../../../../arch/powerpc/lib/memcpy_64.S
\ No newline at end of file
diff --git a/tools/testing/selftests/powerpc/copyloops/memcpy_power7.S b/tools/testing/selftests/powerpc/copyloops/memcpy_power7.S
new file mode 120000
index 0000000..0d6fbfa
--- /dev/null
+++ b/tools/testing/selftests/powerpc/copyloops/memcpy_power7.S
@@ -0,0 +1 @@
+../../../../../arch/powerpc/lib/memcpy_power7.S
\ No newline at end of file
diff --git a/tools/testing/selftests/powerpc/copyloops/validate.c b/tools/testing/selftests/powerpc/copyloops/validate.c
new file mode 100644
index 0000000..1750ff5
--- /dev/null
+++ b/tools/testing/selftests/powerpc/copyloops/validate.c
@@ -0,0 +1,99 @@
+#include <malloc.h>
+#include <string.h>
+#include <stdlib.h>
+#include <stdbool.h>
+
+#include "../utils.h"
+
+#define MAX_LEN 8192
+#define MAX_OFFSET 16
+#define MIN_REDZONE 128
+#define BUFLEN (MAX_LEN+MAX_OFFSET+2*MIN_REDZONE)
+#define POISON 0xa5
+
+unsigned long COPY_LOOP(void *to, const void *from, unsigned long size);
+
+static void do_one(char *src, char *dst, unsigned long src_off,
+ unsigned long dst_off, unsigned long len, void *redzone,
+ void *fill)
+{
+ char *srcp, *dstp;
+ unsigned long ret;
+ unsigned long i;
+
+ srcp = src + MIN_REDZONE + src_off;
+ dstp = dst + MIN_REDZONE + dst_off;
+
+ memset(src, POISON, BUFLEN);
+ memset(dst, POISON, BUFLEN);
+ memcpy(srcp, fill, len);
+
+ ret = COPY_LOOP(dstp, srcp, len);
+ if (ret && ret != (unsigned long)dstp) {
+ printf("(%p,%p,%ld) returned %ld\n", dstp, srcp, len, ret);
+ abort();
+ }
+
+ if (memcmp(dstp, srcp, len)) {
+ printf("(%p,%p,%ld) miscompare\n", dstp, srcp, len);
+ printf("src: ");
+ for (i = 0; i < len; i++)
+ printf("%02x ", srcp[i]);
+ printf("\ndst: ");
+ for (i = 0; i < len; i++)
+ printf("%02x ", dstp[i]);
+ printf("\n");
+ abort();
+ }
+
+ if (memcmp(dst, redzone, dstp - dst)) {
+ printf("(%p,%p,%ld) redzone before corrupted\n",
+ dstp, srcp, len);
+ abort();
+ }
+
+ if (memcmp(dstp+len, redzone, dst+BUFLEN-(dstp+len))) {
+ printf("(%p,%p,%ld) redzone after corrupted\n",
+ dstp, srcp, len);
+ abort();
+ }
+}
+
+int test_copy_loop(void)
+{
+ char *src, *dst, *redzone, *fill;
+ unsigned long len, src_off, dst_off;
+ unsigned long i;
+
+ src = memalign(BUFLEN, BUFLEN);
+ dst = memalign(BUFLEN, BUFLEN);
+ redzone = malloc(BUFLEN);
+ fill = malloc(BUFLEN);
+
+ if (!src || !dst || !redzone || !fill) {
+ fprintf(stderr, "malloc failed\n");
+ exit(1);
+ }
+
+ memset(redzone, POISON, BUFLEN);
+
+ /* Fill with sequential bytes */
+ for (i = 0; i < BUFLEN; i++)
+ fill[i] = i & 0xff;
+
+ for (len = 1; len < MAX_LEN; len++) {
+ for (src_off = 0; src_off < MAX_OFFSET; src_off++) {
+ for (dst_off = 0; dst_off < MAX_OFFSET; dst_off++) {
+ do_one(src, dst, src_off, dst_off, len,
+ redzone, fill);
+ }
+ }
+ }
+
+ return 0;
+}
+
+int main(void)
+{
+ return test_harness(test_copy_loop, str(COPY_LOOP));
+}
diff --git a/tools/testing/selftests/powerpc/utils.h b/tools/testing/selftests/powerpc/utils.h
index 5851c4b..0de0644 100644
--- a/tools/testing/selftests/powerpc/utils.h
+++ b/tools/testing/selftests/powerpc/utils.h
@@ -31,4 +31,7 @@ do { \
} \
} while (0)
+#define _str(s) #s
+#define str(s) _str(s)
+
#endif /* _SELFTESTS_POWERPC_UTILS_H */
--
1.8.3.2
^ permalink raw reply related
* Re: commit e38c0a1f breaks powerpc boards with uli1575 chip
From: Thierry Reding @ 2013-12-19 14:24 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree@vger.kernel.org, Arnd Bergmann, Dmitry Krivoschekov,
Nikita Yushchenko, Thierry Reding, linux-kernel, Grant Likely,
linuxppc-dev, Alexey Lugovskoy
In-Reply-To: <52B1EC15.5070606@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4008 bytes --]
On Wed, Dec 18, 2013 at 12:40:21PM -0600, Rob Herring wrote:
> [fixed DT maillist address]
>
> On 12/17/2013 01:35 AM, Nikita Yushchenko wrote:
> > Hi
> >
> > While trying to make freescale p2020ds and mpc8572ds boards working with mainline kernel, I faced that commit
> > e38c0a1f (Handle #address-cells > 2 specially) breaks things with these boards.
>
> Good to see this broke in v3.7 and is just now found...
>
> >
> > Both these boards have uli1575 chip.
> > Corresponding part in device tree is something like
> >
> > uli1575@0 {
> > reg = <0x0 0x0 0x0 0x0 0x0>;
> > #size-cells = <2>;
> > #address-cells = <3>;
> > ranges = <0x2000000 0x0 0x80000000
> > 0x2000000 0x0 0x80000000
> > 0x0 0x20000000
> >
> > 0x1000000 0x0 0x0
> > 0x1000000 0x0 0x0
> > 0x0 0x10000>;
> > isa@1e {
> > ...
> >
> > I.e. it has #address-cells = <3>
> >
> >
> > With commit e38c0a1f reverted, devices under uli1575 are registered correctly, e.g. for rtc
> >
> > OF: ** translation for device /pcie@ffe09000/pcie@0/uli1575@0/isa@1e/rtc@70 **
> > OF: bus is isa (na=2, ns=1) on /pcie@ffe09000/pcie@0/uli1575@0/isa@1e
> > OF: translating address: 00000001 00000070
> > OF: parent bus is default (na=3, ns=2) on /pcie@ffe09000/pcie@0/uli1575@0
> > OF: walking ranges...
> > OF: ISA map, cp=0, s=1000, da=70
> > OF: parent translation for: 01000000 00000000 00000000
> > OF: with offset: 70
> > OF: one level translation: 00000000 00000000 00000070
> > OF: parent bus is pci (na=3, ns=2) on /pcie@ffe09000/pcie@0
> > OF: walking ranges...
> > OF: default map, cp=a0000000, s=20000000, da=70
> > OF: default map, cp=0, s=10000, da=70
> > OF: parent translation for: 01000000 00000000 00000000
> > OF: with offset: 70
> > OF: one level translation: 01000000 00000000 00000070
> > OF: parent bus is pci (na=3, ns=2) on /pcie@ffe09000
> > OF: walking ranges...
> > OF: PCI map, cp=0, s=10000, da=70
> > OF: parent translation for: 01000000 00000000 00000000
> > OF: with offset: 70
> > OF: one level translation: 01000000 00000000 00000070
> > OF: parent bus is default (na=2, ns=2) on /
> > OF: walking ranges...
> > OF: PCI map, cp=0, s=10000, da=70
> > OF: parent translation for: 00000000 ffc10000
> > OF: with offset: 70
> > OF: one level translation: 00000000 ffc10070
> > OF: reached root node
> >
> > With commit e38c0a1f in place, address translation fails:
> >
> > OF: ** translation for device /pcie@ffe09000/pcie@0/uli1575@0/isa@1e/rtc@70 **
> > OF: bus is isa (na=2, ns=1) on /pcie@ffe09000/pcie@0/uli1575@0/isa@1e
> > OF: translating address: 00000001 00000070
> > OF: parent bus is default (na=3, ns=2) on /pcie@ffe09000/pcie@0/uli1575@0
> > OF: walking ranges...
> > OF: ISA map, cp=0, s=1000, da=70
> > OF: parent translation for: 01000000 00000000 00000000
> > OF: with offset: 70
> > OF: one level translation: 00000000 00000000 00000070
> > OF: parent bus is pci (na=3, ns=2) on /pcie@ffe09000/pcie@0
> > OF: walking ranges...
> > OF: default map, cp=a0000000, s=20000000, da=70
> > OF: default map, cp=0, s=10000, da=70
> > OF: not found !
> >
> > Either e38c0a1f should be reverted, or uli1575 (and perhaps other similar devices) have to be described in device
> > trees differently.
>
> Reverting would break Tegra PCIe, but you should not have to change the
> DT either. So we need a solution.
We ended up merging a different address representation for Tegra PCIe
and I've confirmed that reverting this commit doesn't cause any obvious
regressions. I think all other drivers in drivers/pci/host ended up
copying what we did on Tegra, so I wouldn't expect any other breakage
either.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH 03/38] powerpc: cell: add missing put_device call
From: Levente Kurusa @ 2013-12-19 15:03 UTC (permalink / raw)
To: LKML
Cc: cbe-oss-dev, Levente Kurusa, Arnd Bergmann, Paul Mackerras,
linuxppc-dev
In-Reply-To: <1387465429-3568-2-git-send-email-levex@linux.com>
This is required so that we give up the last reference to the device.
Signed-off-by: Levente Kurusa <levex@linux.com>
---
arch/powerpc/platforms/cell/spu_base.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/platforms/cell/spu_base.c b/arch/powerpc/platforms/cell/spu_base.c
index f85db3a..f7fb0d9 100644
--- a/arch/powerpc/platforms/cell/spu_base.c
+++ b/arch/powerpc/platforms/cell/spu_base.c
@@ -597,6 +597,7 @@ static int spu_create_dev(struct spu *spu)
if (ret) {
printk(KERN_ERR "Can't register SPU %d with sysfs\n",
spu->number);
+ put_device(&spu->dev);
return ret;
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH 02/38] powerpc: qe_lib: add missing put_device call
From: Levente Kurusa @ 2013-12-19 15:03 UTC (permalink / raw)
To: LKML; +Cc: Levente Kurusa, Paul Mackerras, linuxppc-dev
In-Reply-To: <1387465429-3568-2-git-send-email-levex@linux.com>
This is required so that we give up the last reference to the device.
Signed-off-by: Levente Kurusa <levex@linux.com>
---
arch/powerpc/sysdev/qe_lib/qe_ic.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/sysdev/qe_lib/qe_ic.c b/arch/powerpc/sysdev/qe_lib/qe_ic.c
index b2b87c3..2e15262 100644
--- a/arch/powerpc/sysdev/qe_lib/qe_ic.c
+++ b/arch/powerpc/sysdev/qe_lib/qe_ic.c
@@ -493,6 +493,7 @@ static int __init init_qe_ic_sysfs(void)
rc = device_register(&device_qe_ic);
if (rc) {
printk(KERN_ERR "Failed registering qe_ic sys device\n");
+ put_device(&device_qe_ic);
return -ENODEV;
}
return 0;
--
1.8.3.1
^ permalink raw reply related
* [PATCH 04/38] powerpc: kernel: add missing put_device call
From: Levente Kurusa @ 2013-12-19 15:03 UTC (permalink / raw)
To: LKML
Cc: Prarit Bhargava, Levente Kurusa, Paul Mackerras, Anton Blanchard,
Greg Kroah-Hartman, linuxppc-dev
In-Reply-To: <1387465429-3568-2-git-send-email-levex@linux.com>
This is required so that we give up the last reference to the device.
Signed-off-by: Levente Kurusa <levex@linux.com>
---
arch/powerpc/kernel/vio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index e7d0c88f..e8ed87e 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -1494,6 +1494,7 @@ static int __init vio_bus_init(void)
if (err) {
printk(KERN_WARNING "%s: device_register returned %i\n",
__func__, err);
+ put_device(&vio_bus_device.dev);
return err;
}
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] powerpc/512x: dts: disable MPC5125 usb module
From: Matteo Facchinetti @ 2013-12-19 17:49 UTC (permalink / raw)
To: linuxppc-dev, agust, Gerhard Sittig
In-Reply-To: <20131219123017.GM8064@book.gsilab.sittig.org>
On 19/12/2013 13:30, Gerhard Sittig wrote:
> On Thu, Dec 19, 2013 at 11:23 +0100, Matteo Facchinetti wrote:
>> USB controller pin-muxing is not initialized correctly and when system boot,
>> causes a kernel panic.
>> USB controller is also connected with a USB3320 ulpi tranciever and
>> DTS should be includes the correct dependency for initialize and activate
>> this component.
>>
>> Signed-off-by: Matteo Facchinetti <matteo.facchinetti@sirius-es.it>
>> ---
>> arch/powerpc/boot/dts/mpc5125twr.dts | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/powerpc/boot/dts/mpc5125twr.dts b/arch/powerpc/boot/dts/mpc5125twr.dts
>> index 806479f..85452a7 100644
>> --- a/arch/powerpc/boot/dts/mpc5125twr.dts
>> +++ b/arch/powerpc/boot/dts/mpc5125twr.dts
>> @@ -230,6 +230,9 @@
>> };
>>
>> usb@3000 {
>> + /* TODO correct pinmux config and fix USB3320 ulpi dependency */
>> + status = "disabled";
>> +
>> compatible = "fsl,mpc5121-usb2-dr";
>> reg = <0x3000 0x400>;
>> #address-cells = <1>;
>> --
>> 1.8.3.2
> I agree on the change to the board dts file, but suggest to
> reword the commit description for improved reception.
>
> I feel it's worth trying to phrase the subject line, the commit
> message, and the patch such that they can get considered
> independently from each other, as not all of them are necessarily
> available at the same time. Often they get looked up from
> different perspectives, like terse listing first for orientation,
> log with description then to determine whether to have a closer
> look, the patch only at the end after the other checks told you
> to look into more details. Assuming that they always show up in
> combination may turn out to be inaccurate.
>
> So I suggest some text along those lines:
>
> at the moment the USB controller's pin muxing is not setup
> correctly and causes a kernel panic upon system startup, so
> disable the USB1 device tree node in the MPC5125 tower board
> dts file
>
> the USB controller is connected to an USB3320 ULPI transceiver
> and the device tree should receive an update to reflect correct
> dependencies and required initialization data before the USB1
> node can get re-enabled
>
> Does that sound correct to you? Does it reflect your intention,
> or did I put something in wrong terms?
Yes, it's exactly what I tried to explain. All is right.
Now, I learned. Thank you.
> A minor nit would be that other reviewers in the past suggested
> to put the 'status = "disabled"' line last in the list of
> properties (right before optional children). I don't have strong
> feelings about this. Putting it first might better reflect your
> motivation of only re-enabling the node after fixing the lack or
> inappropriateness of existing information first.
I put it as first property because is very temporary and because is the
most important information for the moment:
"the USB1 port doesn't works for these reasons...".
But, I think that if this property is usually at the and of the node
list, it's better follow this suggestion.
Then I'll send a v2 patch with the newer description and with this change.
>
> A different matter is that I'd suggest to re-work the MPC5125
> device tree. It recently escaped my attention because it did not
> share any information with the MPC5121 trees. Comparing the
> MPC5125 board DTS with the MPC5121 DTS include file resulted in a
> lot of unnecessary "differences" that turned out to be whitespace
> or comment style only, or differences in the order of nodes.
> There were only few real differences in the information, and the
> MPC5125 device tree appears to only describe a subset of what the
> SoC actually contains.
>
> It may be worth looking into
> - identifying common parts that are shared among the MPC5121 and
> MPC5125 (my recent CCF update lists differences, but does not
> explicitly list similarities, and is from the clocks
> perspective and may not cover all of the SoC components)
> - putting those common parts into .dtsi files if possible
> - making the MPC5125 tower board reference the DTS includes,
> sharing as much as possible with the other SoC variants
>
> This may involve another split of the mpc5121.dtsi into what's
> common to all MPC512x variants, and what's exclusive to MPC5121
> only.
>
> But that is a bigger task than the above quick adjustment, and is
> not a required fix but just an improvement in maintainability or
> completeness of information. So I suggest to pick your USB1
> disabling for -next and 3.14 now, and to address the DTS cleanup
> and sharing later.
It was from the first commit of mpc5125twr.dts file that I would have
liked to rework all mpc5xxx DTS tree.
At the moment I have already started this task but it's better to open
another thread for this discussion and I agree with you that it's not a
priority.
Now, I'm working to the NFC controller and I'm porting to linux 3.13 the
driver that we are using in linux 3.9.4.
When I done a preliminary version I'll post for starting a discussion
about its correct integration.
I think it's time to add this driver in mainline for use NFC as well.
Best regards,
Matteo Facchinetti
^ permalink raw reply
* Re: [PATCH] powerpc/sysdev: Fix a mpic section mismatch for MPC85xx
From: Christian Engelmayer @ 2013-12-19 23:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Scott Wood; +Cc: linuxppc-dev, Kevin Hao
In-Reply-To: <1387152653.15730.175.camel@pasglop>
On Mon, 16 Dec 2013 11:10:53 +1100 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Sun, 2013-12-15 at 19:38 +0100, Christian Engelmayer wrote:
> > Moved arch/powerpc/sysdev/mpic.c : smp_mpic_probe() out of the __init section.
> > It is referenced by arch/powerpc/platforms/85xx/smp.c : smp_85xx_setup_cpu().
>
> I don't like this. The reference is not actually going to call into the
> code at all and as such is not an error, it's just a pointer comparison.
That's correct. I proposed it that way because on first sight I was concerned
that there is an address of an __init function assigned to a function pointer
within a non __initdata struct at all that can be compared against. However,
further usage of smp_ops->probe is currently safe of course and *_ops symbols
within .data are whitelisted to refer to init sections.
> If there is no way to silence the warning, then I'd suggest to use a
> global flag, something like mpc85xx_pic_type and test that instead
> of comparing the pointers.
I've seen that there is currently a patch proposed against
commit dc2c9c52b604f51b1416ed87ff54a1c77a1a8b5b
powerpc/85xx: Set up doorbells even with no mpic
that introduced the section causing the warning:
http://patchwork.ozlabs.org/patch/289214/
powerpc/85xx: don't init the mpic ipi for the SoC which has doorbell support
This patch also removes the affected pointer comparison and if accepted would
thus also silence this warning.
> > Signed-off-by: Christian Engelmayer <cengelma@gmx.at>
> > ---
> > arch/powerpc/sysdev/mpic.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> > index 0e166ed..72c1e65 100644
> > --- a/arch/powerpc/sysdev/mpic.c
> > +++ b/arch/powerpc/sysdev/mpic.c
> > @@ -1924,7 +1924,7 @@ void smp_mpic_message_pass(int cpu, int msg)
> > msg * MPIC_INFO(CPU_IPI_DISPATCH_STRIDE), physmask);
> > }
> >
> > -int __init smp_mpic_probe(void)
> > +int smp_mpic_probe(void)
> > {
> > int nr_cpus;
> >
>
>
^ 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