* Re: [PATCH v1 1/1] powerpc/512x: dts: remove misplaced IRQ spec from 'soc' node
From: Gerhard Sittig @ 2013-12-10 11:24 UTC (permalink / raw)
To: Anatolij Gustschin, linuxppc-dev, devicetree, matteo.facchinetti
In-Reply-To: <20131210100501.GO2982@book.gsilab.sittig.org>
On Tue, Dec 10, 2013 at 11:05 +0100, Gerhard Sittig wrote:
>
> FYI: I only noticed yesterday that MPC5125 suffers from the same
> issue, have sent <1386669068-2477-1-git-send-email-gsi@denx.de>
> to fix that as well. Both patches may get squashed when going
> upstream. Don't have a dump at hand for MPC5125 as I don't have
> access to hardware.
Had a thinko there, the MPC5121 fix already went upstream, while
the MPC5125 fix is pending. So there is no squashing. Nevermind.
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] DTS: DMA: Fix DMA3 interrupts
From: Scott Wood @ 2013-12-10 18:33 UTC (permalink / raw)
To: Hongbo Zhang; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <52A6EDE8.5060903@freescale.com>
On Tue, 2013-12-10 at 18:33 +0800, Hongbo Zhang wrote:
> Scott,
> This issue is due to the non-continuous MPIC register, I think there is
> two ways to fix it.
>
> The first one is as what we are discussing, in fact the Bman/Qman DT
> author had introduced this way, and I had to follow it, it is a trick,
> adding 208 is a bit ugly I think, and even difficult to explain it to
> customers etc, but this way changes less codes.
>
> The second one is editing MPIC related codes without adding 208 to high
> interrupts. The point of translate interrupt number to MPIC register
> address is a so called 'isu' mechanism, we can do like the following
> example codes, then the tricky adding 208 isn't needed any more.
>
> Which one do you prefer?
> In fact I myself prefer the second, if the idea is acceptable, I will
> send a patch instead of this one. (and also alone with the internal
> patch decreasing 208 for the Bman/Qman)
>
> void __init corenet_ds_pic_init(void)
> {
> ......
>
> mpic = mpic_alloc(NULL, 0, flags, 0, 512, "OpenPIC");
> BUG_ON(mpic == NULL);
>
> // Add this start
> for (i = 0; i < 17; i++) {
> if (i < 11)
> addr_off = 0x10000 + 0x20 * 16 * i;
> else
> addr_off = 0x13000 + 0x20 * 16 * (i - 11); /* scape the
> address not for interrupts */
> mpic_assign_isu(mpic, i, mpic->paddr + addr_off);
> }
> // Add this end
>
> mpic_init(mpic);
> }
NACK
We already have a binding that states that the interrupt number is based
on the register offset, rather than whatever arbitrary numbers hardware
documenters decide to use next week.
While I'm not terribly happy with the usability of this, especially now
that it's not a simple "add 16", redefining the existing binding is not
OK (and in any case the code above seems obfuscatory). If we decide to
do something other than continue with register offset divided by 32,
then we need to define a new interrupt type (similar to current defined
types of error interrupt, timer, and IPI) for the new numberspace -- and
it should be handled when decoding that type of interrupt specifier,
rather than with the isu mechanism.
-Scott
^ permalink raw reply
* Re: [PATCH v2] powerpc 8xx: Loading kernels over 8Mbytes without CONFIG_PIN_TLB
From: Scott Wood @ 2013-12-10 22:24 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <20131210112945.E4E311A2BF3@localhost.localdomain>
On Tue, 2013-12-10 at 12:29 +0100, Christophe Leroy wrote:
> Today, the only way to load kernels whose size is greater than 8Mbytes is to
> activate CONFIG_PIN_TLB. Otherwise, the physical memory initially mapped is
> limited to 8Mbytes. This patch adds the capability to select the size of initial
> memory between 8/16/24 Mbytes and this is regardless of whether CONFIG_PIN_TLB
> is active or not. It allows to load "big" kernels (for instance when activating
> CONFIG_LOCKDEP_SUPPORT) without having to activate CONFIG_PIN_TLB.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>
> diff -ur a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -980,6 +980,29 @@
> config PIN_TLB
> bool "Pinned Kernel TLBs (860 ONLY)"
> depends on ADVANCED_OPTIONS && 8xx
> +
> +choice
> + prompt "Initial Data Memory Mapped on 8xx"
> + default 8xx_MAP_8M
> + depends on ADVANCED_OPTIONS && 8xx
> +
> +config 8xx_INIT_MAP_8M
> + bool "8 Mbytes"
> +
> +config 8xx_INIT_MAP_16M
> + bool "16 Mbytes"
> +
> +config 8xx_INIT_MAP_24M
> + bool "24 Mbytes"
Are you working with a loader that passes initial-mapped-area size in r7
as per ePAPR? If so, we could rely on that at runtime. If you're using
a non-ancient U-Boot, it should qualify here even if it's not fully
ePAPR compliant (it passes the value of the bootm_mapsize variable in
r7).
> -#ifdef CONFIG_PIN_TLB
> +#if defined (CONFIG_8xx_INIT_MAP_16M) || defined (CONFIG_8xx_INIT_MAP_24M)
> /* Map two more 8M kernel data pages.
> */
> +#ifdef CONFIG_PIN_TLB
> addi r10, r10, 0x0100
> mtspr SPRN_MD_CTR, r10
> +#endif
>
> lis r8, KERNELBASE@h /* Create vaddr for TLB */
> addis r8, r8, 0x0080 /* Add 8M */
> @@ -858,15 +860,19 @@
> addis r11, r11, 0x0080 /* Add 8M */
> mtspr SPRN_MD_RPN, r11
>
> +#ifdef CONFIG_8xx_INIT_MAP_24M
> +#ifdef CONFIG_PIN_TLB
> addi r10, r10, 0x0100
> mtspr SPRN_MD_CTR, r10
> +#endif
Are these ifdefs for CONFIG_PIN_TLB really needed? It shouldn't harm
anything to use those entries even if they're not being pinned.
-Scott
^ permalink raw reply
* Re: [PATCH v6 00/17] add COMMON_CLK support for PowerPC MPC512x
From: Gerhard Sittig @ 2013-12-10 13:20 UTC (permalink / raw)
To: linuxppc-dev, linux-arm-kernel, Anatolij Gustschin,
Mike Turquette
Cc: Scott Wood, Paul Mackerras, Detlev Zundel
In-Reply-To: <1385851897-23475-1-git-send-email-gsi@denx.de>
[ trimmed Cc: list to PowerPC and CCF ]
On Sat, Nov 30, 2013 at 23:51 +0100, Gerhard Sittig wrote:
>
> this series introduces support for the common clock framework (CCF,
> COMMON_CLK Kconfig option) in the PowerPC based MPC512x platform,
> which brings device tree based clock lookup as well
For the record: MPC5125 turned out to be quite different
compared to MPC5121/5123 with regard to the set of peripherals
and clock features, so I sent an update of this COMMON_CLK
support motivated by MPC5125:
From: Gerhard Sittig <gsi@denx.de>
To: linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org,
Anatolij Gustschin <agust@denx.de>, Mike Turquette <mturquette@linaro.org>,
Matteo Facchinetti <matteo.facchinetti@sirius-es.it>
Cc: Scott Wood <scottwood@freescale.com>, Detlev Zundel <dzu@denx.de>,
Gerhard Sittig <gsi@denx.de>
Subject: [PATCH v1 0/4] powerpc/512x: update COMMON_CLK support for MPC5125
Date: Tue, 10 Dec 2013 14:11:33 +0100
Message-Id: <1386681097-14126-1-git-send-email-gsi@denx.de>
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 1/9] PCI: Use dev_is_pci() to check whether it is pci device
From: Bjorn Helgaas @ 2013-12-10 17:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-ia64@vger.kernel.org, linux-parisc,
linux-pci@vger.kernel.org, linux-alpha,
linux-kernel@vger.kernel.org, sparclinux, Hanjun Guo, Yijing Wang,
linuxppc-dev, linux-arm
In-Reply-To: <1386647973.32037.57.camel@pasglop>
On Mon, Dec 9, 2013 at 8:59 PM, Benjamin Herrenschmidt <benh@au1.ibm.com> wrote:
> On Mon, 2013-12-09 at 17:01 -0700, Bjorn Helgaas wrote:
>> [+cc arch lists]
>>
>> On Thu, Dec 05, 2013 at 07:52:53PM +0800, Yijing Wang wrote:
>> > Use dev_is_pci() instead of directly compare
>> > pci_bus_type to check whether it is pci device.
>> >
>> > Signed-off-by: Yijing Wang <wangyijing@huawei.com>
>>
>> I applied all these to my pci/yijing-dev_is_pci branch for v3.14, thanks!
>>
>> Browse them here: http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/yijing-dev_is_pci
>
> Ah ok. I also have the powerpc one in powerpc -next, no biggie though
I'll drop the powerpc one.
^ permalink raw reply
* Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)
From: Scott Wood @ 2013-12-10 20:29 UTC (permalink / raw)
To: Bharat.Bhushan@freescale.com
Cc: Stuart Yoder, linux-pci@vger.kernel.org, Alex Williamson,
agraf@suse.de, bhelgaas@google.com,
iommu@lists.linux-foundation.org, 'Wood Scott-B07421',
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <34c6142137194b1cbd2336013ed3b10d@BN1PR03MB266.namprd03.prod.outlook.com>
My e-mail address is <scottwood@freescale.com>, not
<IMCEAEX-_O=MMS_OU=EXTERNAL+20+28FYDIBOHF25SPDLT
+29_CN=RECIPIENTS_CN=F0FAAC8D7E74473A9EE1C45B068D838A@namprd03.prod.outlook.com>
On Tue, 2013-12-10 at 05:37 +0000, Bharat.Bhushan@freescale.com wrote:
>
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Saturday, December 07, 2013 12:55 AM
> > To: Bhushan Bharat-R65777
> > Cc: Alex Williamson; linux-pci@vger.kernel.org; agraf@suse.de; Yoder Stuart-
> > B08248; iommu@lists.linux-foundation.org; bhelgaas@google.com; linuxppc-
> > dev@lists.ozlabs.org; linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)
> >
> > If the administrator does not opt into this partial loss of isolation, then once
> > you run out of MSI groups, new users should not be able to set up MSIs.
>
> So mean vfio should use Legacy when out of MSI banks?
Yes, if the administrator hasn't granted permission to share.
-Scott
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Use schedule instead of cond_resched
From: Peter Zijlstra @ 2013-12-10 22:48 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: kvm@vger.kernel.org mailing list, Alexander Graf, kvm-ppc,
Paul Mackerras, Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <1386708771.32037.73.camel@pasglop>
On Wed, Dec 11, 2013 at 07:52:51AM +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2013-12-10 at 15:40 +0100, Alexander Graf wrote:
> > On 10.12.2013, at 15:21, Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> wrote:
> >
> > > From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
> > >
> > > We already checked need_resched. So we can call schedule directly
> > >
> > > Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> >
> > The real fix for the issue you're seeing is
> >
> > https://lkml.org/lkml/2013/11/28/241
> >
>
> And is still not upstream.... Peter ?
Yeah, I went on holidays and the patch just sat there. I'll prod Ingo
into merging it.
^ permalink raw reply
* [PATCH v1 2/4] powerpc/512x: clk: enforce even SDHC divider values
From: Gerhard Sittig @ 2013-12-10 13:11 UTC (permalink / raw)
To: linuxppc-dev, linux-arm-kernel, Anatolij Gustschin,
Mike Turquette, Matteo Facchinetti
Cc: Scott Wood, Gerhard Sittig, Detlev Zundel
In-Reply-To: <1386681097-14126-1-git-send-email-gsi@denx.de>
the SDHC clock is derived from CSB with a fractional divider which can
address "quarters"; the implementation multiplies CSB by 4 and divides
it by the (integer) divider value
a bug in the clock domain synchronisation requires that only even
divider values get setup; we achieve this by
- multiplying CSB by 2 only instead of 4
- registering with CCF the divider's bit field without bit0
- the divider's lowest bit remains clear as this is the reset value
and later operations won't touch it
this change keeps fully utilizing common clock primitives (needs no
additional support logic, and avoids an excessive divider table) and
satisfies the hardware's constraint of only supporting even divider
values
Signed-off-by: Gerhard Sittig <gsi@denx.de>
---
arch/powerpc/platforms/512x/clock-commonclk.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/512x/clock-commonclk.c b/arch/powerpc/platforms/512x/clock-commonclk.c
index 079eb1137260..b5190fcb81bb 100644
--- a/arch/powerpc/platforms/512x/clock-commonclk.c
+++ b/arch/powerpc/platforms/512x/clock-commonclk.c
@@ -560,9 +560,21 @@ static void mpc512x_clk_setup_clock_tree(struct device_node *np, int busfreq)
/* now setup anything below SYS and CSB and IPS */
clks[MPC512x_CLK_DDR_UG] = mpc512x_clk_factor("ddr-ug", "sys", 1, 2);
- clks[MPC512x_CLK_SDHC_x4] = mpc512x_clk_factor("sdhc-x4", "csb", 4, 1);
+
+ /*
+ * the Reference Manual discusses that for SDHC only even divide
+ * ratios are supported because clock domain synchronization
+ * between 'per' and 'ipg' is broken;
+ * keep the divider's bit 0 cleared (per reset value), and only
+ * allow to setup the divider's bits 7:1, which results in that
+ * only even divide ratios can get configured upon rate changes;
+ * keep the "x4" name because this bit shift hack is an internal
+ * implementation detail, the "fractional divider with quarters"
+ * semantics remains
+ */
+ clks[MPC512x_CLK_SDHC_x4] = mpc512x_clk_factor("sdhc-x4", "csb", 2, 1);
clks[MPC512x_CLK_SDHC_UG] = mpc512x_clk_divider("sdhc-ug", "sdhc-x4", 0,
- &clkregs->scfr2, 0, 8,
+ &clkregs->scfr2, 1, 7,
CLK_DIVIDER_ONE_BASED);
clks[MPC512x_CLK_DIU_x4] = mpc512x_clk_factor("diu-x4", "csb", 4, 1);
clks[MPC512x_CLK_DIU_UG] = mpc512x_clk_divider("diu-ug", "diu-x4", 0,
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] KVM: PPC: Use schedule instead of cond_resched
From: Alexander Graf @ 2013-12-10 17:00 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Paul Mackerras, linuxppc-dev, kvm-ppc,
kvm@vger.kernel.org mailing list
In-Reply-To: <877gbcsn81.fsf@linux.vnet.ibm.com>
On 10.12.2013, at 17:08, Aneesh Kumar K.V =
<aneesh.kumar@linux.vnet.ibm.com> wrote:
> Alexander Graf <agraf@suse.de> writes:
>=20
>> On 10.12.2013, at 15:21, Aneesh Kumar K.V =
<aneesh.kumar@linux.vnet.ibm.com> wrote:
>>=20
>>> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>>>=20
>>> We already checked need_resched. So we can call schedule directly
>>>=20
>>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>>=20
>> The real fix for the issue you're seeing is
>>=20
>> https://lkml.org/lkml/2013/11/28/241
>=20
> True, I mentioned that in the thread
>=20
> https://lkml.org/lkml/2013/12/9/64
>=20
> But do we need to do cond_resched after we checked for need_resched() =
?
This is really just copying the logic from kvm_resched() from =
virt/kvm/kvm_main.c. And I'd prefer not to diverge from that. I do agree =
that there's a good chance we don't need it, as it seems to predate =
preempt notifiers:
=
https://git.kernel.org/cgit/virt/kvm/kvm.git/commit/?id=3D3fca03653010b8c5=
fa63b99fc94c78cbfb433d00
But this is a discussion that should occur on the non-ppc specific code =
first :).
Alex
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Use schedule instead of cond_resched
From: Alexander Graf @ 2013-12-10 14:40 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Paul Mackerras, linuxppc-dev, kvm-ppc,
kvm@vger.kernel.org mailing list
In-Reply-To: <1386685284-3862-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On 10.12.2013, at 15:21, Aneesh Kumar K.V =
<aneesh.kumar@linux.vnet.ibm.com> wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>=20
> We already checked need_resched. So we can call schedule directly
>=20
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
The real fix for the issue you're seeing is
https://lkml.org/lkml/2013/11/28/241
Alex
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Use schedule instead of cond_resched
From: Benjamin Herrenschmidt @ 2013-12-10 22:59 UTC (permalink / raw)
To: Peter Zijlstra
Cc: kvm@vger.kernel.org mailing list, Alexander Graf, kvm-ppc,
Paul Mackerras, Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <20131210224851.GH13532@twins.programming.kicks-ass.net>
On Tue, 2013-12-10 at 23:48 +0100, Peter Zijlstra wrote:
>
> Yeah, I went on holidays and the patch just sat there. I'll prod Ingo
> into merging it.
Thanks !
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v2] powerpc 8xx: Loading kernels over 8Mbytes without CONFIG_PIN_TLB
From: leroy christophe @ 2013-12-10 23:05 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <1386714253.10013.123.camel@snotra.buserror.net>
Le 10/12/2013 23:24, Scott Wood a écrit :
> On Tue, 2013-12-10 at 12:29 +0100, Christophe Leroy wrote:
>> Today, the only way to load kernels whose size is greater than 8Mbytes is to
>> activate CONFIG_PIN_TLB. Otherwise, the physical memory initially mapped is
>> limited to 8Mbytes. This patch adds the capability to select the size of initial
>> memory between 8/16/24 Mbytes and this is regardless of whether CONFIG_PIN_TLB
>> is active or not. It allows to load "big" kernels (for instance when activating
>> CONFIG_LOCKDEP_SUPPORT) without having to activate CONFIG_PIN_TLB.
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>>
>> diff -ur a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>> --- a/arch/powerpc/Kconfig
>> +++ b/arch/powerpc/Kconfig
>> @@ -980,6 +980,29 @@
>> config PIN_TLB
>> bool "Pinned Kernel TLBs (860 ONLY)"
>> depends on ADVANCED_OPTIONS && 8xx
>> +
>> +choice
>> + prompt "Initial Data Memory Mapped on 8xx"
>> + default 8xx_MAP_8M
>> + depends on ADVANCED_OPTIONS && 8xx
>> +
>> +config 8xx_INIT_MAP_8M
>> + bool "8 Mbytes"
>> +
>> +config 8xx_INIT_MAP_16M
>> + bool "16 Mbytes"
>> +
>> +config 8xx_INIT_MAP_24M
>> + bool "24 Mbytes"
> Are you working with a loader that passes initial-mapped-area size in r7
> as per ePAPR? If so, we could rely on that at runtime. If you're using
> a non-ancient U-Boot, it should qualify here even if it's not fully
> ePAPR compliant (it passes the value of the bootm_mapsize variable in
> r7).
Ok, let me check that. But it means that the size of the kernel I can
boot will depend on the initial memory mapped by uboot ? Isn't it
limitating ?
Even if uboot only maps 8Mbytes, why couldn't I be allowed to boot a
kernel having 10 Mbytes data if I have 32 Mbytes mem on the board ?
I don't like the idea of having to change the bootloader just because I
want to activate CONFIG_LOCKDEP to debug my kernel.
>
>> -#ifdef CONFIG_PIN_TLB
>> +#if defined (CONFIG_8xx_INIT_MAP_16M) || defined (CONFIG_8xx_INIT_MAP_24M)
>> /* Map two more 8M kernel data pages.
>> */
>> +#ifdef CONFIG_PIN_TLB
>> addi r10, r10, 0x0100
>> mtspr SPRN_MD_CTR, r10
>> +#endif
>>
>> lis r8, KERNELBASE@h /* Create vaddr for TLB */
>> addis r8, r8, 0x0080 /* Add 8M */
>> @@ -858,15 +860,19 @@
>> addis r11, r11, 0x0080 /* Add 8M */
>> mtspr SPRN_MD_RPN, r11
>>
>> +#ifdef CONFIG_8xx_INIT_MAP_24M
>> +#ifdef CONFIG_PIN_TLB
>> addi r10, r10, 0x0100
>> mtspr SPRN_MD_CTR, r10
>> +#endif
> Are these ifdefs for CONFIG_PIN_TLB really needed? It shouldn't harm
> anything to use those entries even if they're not being pinned.
I'm not sure I understand your comment.
ifdef for CONFIG_PIN_TLB was already there before, but was enclosing the
whole block, so 24 Mbytes were automatically mapped when you selected
CONFIG_PIN_TLB and only 8 Mbytes were mapped when you didn't select
CONFIG_PIN_TLB.
I reduced the scope of those ifdefs so that they now apply on the
pinning only.
Christophe
^ permalink raw reply
* [PATCHv2 1/6] powerpc: fix exception clearing in e500 SPE float emulation
From: Joseph S. Myers @ 2013-12-10 23:07 UTC (permalink / raw)
To: Scott Wood; +Cc: Liu Yu, linuxppc-dev, linux-kernel, Shan Hai
In-Reply-To: <1386376365.7375.209.camel@snotra.buserror.net>
From: Joseph Myers <joseph@codesourcery.com>
The e500 SPE floating-point emulation code clears existing exceptions
(__FPU_FPSCR &= ~FP_EX_MASK;) before ORing in the exceptions from the
emulated operation. However, these exception bits are the "sticky",
cumulative exception bits, and should only be cleared by the user
program setting SPEFSCR, not implicitly by any floating-point
instruction (whether executed purely by the hardware or emulated).
The spurious clearing of these bits shows up as missing exceptions in
glibc testing.
Fixing this, however, is not as simple as just not clearing the bits,
because while the bits may be from previous floating-point operations
(in which case they should not be cleared), the processor can also set
the sticky bits itself before the interrupt for an exception occurs,
and this can happen in cases when IEEE 754 semantics are that the
sticky bit should not be set. Specifically, the "invalid" sticky bit
is set in various cases with non-finite operands, where IEEE 754
semantics do not involve raising such an exception, and the
"underflow" sticky bit is set in cases of exact underflow, whereas
IEEE 754 semantics are that this flag is set only for inexact
underflow. Thus, for correct emulation the kernel needs to know the
setting of these two sticky bits before the instruction being
emulated.
When a floating-point operation raises an exception, the kernel can
note the state of the sticky bits immediately afterwards. Some
<fenv.h> functions that affect the state of these bits, such as
fesetenv and feholdexcept, need to use prctl with PR_GET_FPEXC and
PR_SET_FPEXC anyway, and so it is natural to record the state of those
bits during that call into the kernel and so avoid any need for a
separate call into the kernel to inform it of a change to those bits.
Thus, the interface I chose to use (in this patch and the glibc port)
is that one of those prctl calls must be made after any userspace
change to those sticky bits, other than through a floating-point
operation that traps into the kernel anyway. feclearexcept and
fesetexceptflag duly make those calls, which would not be required
were it not for this issue.
The previous EGLIBC port, and the uClibc code copied from it, is
fundamentally broken as regards any use of prctl for floating-point
exceptions because it didn't use the PR_FP_EXC_SW_ENABLE bit in its
prctl calls (and did various worse things, such as passing a pointer
when prctl expected an integer). If you avoid anything where prctl is
used, the clearing of sticky bits still means it will never give
anything approximating correct exception semantics with existing
kernels. I don't believe the patch makes things any worse for
existing code that doesn't try to inform the kernel of changes to
sticky bits - such code may get incorrect exceptions in some cases,
but it would have done so anyway in other cases.
Signed-off-by: Joseph Myers <joseph@codesourcery.com>
---
> OK -- please mention this in the changelog.
The description of brokenness of existing code attempting to use
floating-point exceptions on e500 is now included above.
> I don't know of a formal place for it, but there should at least be a
> code comment somewhere.
This version now adds a comment alongside the relevant settings of
spefscr_last.
The other patches in this series (2-6) remain independent of this one
(and as previously noted, with no dependencies except that patch 5
depends on patch 2) and so are not resent.
diff --git a/arch/powerpc/include/asm/processor.h b/arch/powerpc/include/asm/processor.h
index fc14a38..91441d9 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -256,6 +256,8 @@ struct thread_struct {
unsigned long evr[32]; /* upper 32-bits of SPE regs */
u64 acc; /* Accumulator */
unsigned long spefscr; /* SPE & eFP status */
+ unsigned long spefscr_last; /* SPEFSCR value on last prctl
+ call or trap return */
int used_spe; /* set if process has used spe */
#endif /* CONFIG_SPE */
#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
@@ -317,7 +319,9 @@ struct thread_struct {
(_ALIGN_UP(sizeof(init_thread_info), 16) + (unsigned long) &init_stack)
#ifdef CONFIG_SPE
-#define SPEFSCR_INIT .spefscr = SPEFSCR_FINVE | SPEFSCR_FDBZE | SPEFSCR_FUNFE | SPEFSCR_FOVFE,
+#define SPEFSCR_INIT \
+ .spefscr = SPEFSCR_FINVE | SPEFSCR_FDBZE | SPEFSCR_FUNFE | SPEFSCR_FOVFE, \
+ .spefscr_last = SPEFSCR_FINVE | SPEFSCR_FDBZE | SPEFSCR_FUNFE | SPEFSCR_FOVFE,
#else
#define SPEFSCR_INIT
#endif
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 3386d8a..b08c0d0 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1175,6 +1175,19 @@ int set_fpexc_mode(struct task_struct *tsk, unsigned int val)
if (val & PR_FP_EXC_SW_ENABLE) {
#ifdef CONFIG_SPE
if (cpu_has_feature(CPU_FTR_SPE)) {
+ /*
+ * When the sticky exception bits are set
+ * directly by userspace, it must call prctl
+ * with PR_GET_FPEXC (with PR_FP_EXC_SW_ENABLE
+ * in the existing prctl settings) or
+ * PR_SET_FPEXC (with PR_FP_EXC_SW_ENABLE in
+ * the bits being set). <fenv.h> functions
+ * saving and restoring the whole
+ * floating-point environment need to do so
+ * anyway to restore the prctl settings from
+ * the saved environment.
+ */
+ tsk->thread.spefscr_last = mfspr(SPRN_SPEFSCR);
tsk->thread.fpexc_mode = val &
(PR_FP_EXC_SW_ENABLE | PR_FP_ALL_EXCEPT);
return 0;
@@ -1206,9 +1219,22 @@ int get_fpexc_mode(struct task_struct *tsk, unsigned long adr)
if (tsk->thread.fpexc_mode & PR_FP_EXC_SW_ENABLE)
#ifdef CONFIG_SPE
- if (cpu_has_feature(CPU_FTR_SPE))
+ if (cpu_has_feature(CPU_FTR_SPE)) {
+ /*
+ * When the sticky exception bits are set
+ * directly by userspace, it must call prctl
+ * with PR_GET_FPEXC (with PR_FP_EXC_SW_ENABLE
+ * in the existing prctl settings) or
+ * PR_SET_FPEXC (with PR_FP_EXC_SW_ENABLE in
+ * the bits being set). <fenv.h> functions
+ * saving and restoring the whole
+ * floating-point environment need to do so
+ * anyway to restore the prctl settings from
+ * the saved environment.
+ */
+ tsk->thread.spefscr_last = mfspr(SPRN_SPEFSCR);
val = tsk->thread.fpexc_mode;
- else
+ } else
return -EINVAL;
#else
return -EINVAL;
diff --git a/arch/powerpc/math-emu/math_efp.c b/arch/powerpc/math-emu/math_efp.c
index a73f088..59835c6 100644
--- a/arch/powerpc/math-emu/math_efp.c
+++ b/arch/powerpc/math-emu/math_efp.c
@@ -630,9 +630,27 @@ update_ccr:
regs->ccr |= (IR << ((7 - ((speinsn >> 23) & 0x7)) << 2));
update_regs:
- __FPU_FPSCR &= ~FP_EX_MASK;
+ /*
+ * If the "invalid" exception sticky bit was set by the
+ * processor for non-finite input, but was not set before the
+ * instruction being emulated, clear it. Likewise for the
+ * "underflow" bit, which may have been set by the processor
+ * for exact underflow, not just inexact underflow when the
+ * flag should be set for IEEE 754 semantics. Other sticky
+ * exceptions will only be set by the processor when they are
+ * correct according to IEEE 754 semantics, and we must not
+ * clear sticky bits that were already set before the emulated
+ * instruction as they represent the user-visible sticky
+ * exception status. "inexact" traps to kernel are not
+ * required for IEEE semantics and are not enabled by default,
+ * so the "inexact" sticky bit may have been set by a previous
+ * instruction without the kernel being aware of it.
+ */
+ __FPU_FPSCR
+ &= ~(FP_EX_INVALID | FP_EX_UNDERFLOW) | current->thread.spefscr_last;
__FPU_FPSCR |= (FP_CUR_EXCEPTIONS & FP_EX_MASK);
mtspr(SPRN_SPEFSCR, __FPU_FPSCR);
+ current->thread.spefscr_last = __FPU_FPSCR;
current->thread.evr[fc] = vc.wp[0];
regs->gpr[fc] = vc.wp[1];
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply related
* Re: [PATCH] KVM: PPC: Use schedule instead of cond_resched
From: Benjamin Herrenschmidt @ 2013-12-10 20:52 UTC (permalink / raw)
To: Peter Zijlstra
Cc: kvm@vger.kernel.org mailing list, Alexander Graf, kvm-ppc,
Paul Mackerras, Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <C3F93DB3-202A-427D-A7B6-A868F3743507@suse.de>
On Tue, 2013-12-10 at 15:40 +0100, Alexander Graf wrote:
> On 10.12.2013, at 15:21, Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> wrote:
>
> > From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
> >
> > We already checked need_resched. So we can call schedule directly
> >
> > Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>
> The real fix for the issue you're seeing is
>
> https://lkml.org/lkml/2013/11/28/241
>
And is still not upstream.... Peter ?
Cheers,
Ben.
^ permalink raw reply
* [PATCH v1 4/4] powerpc/512x: dts: add MPC5125 clock specs
From: Gerhard Sittig @ 2013-12-10 13:11 UTC (permalink / raw)
To: linuxppc-dev, linux-arm-kernel, Anatolij Gustschin,
Mike Turquette, Matteo Facchinetti
Cc: Scott Wood, Gerhard Sittig, Detlev Zundel
In-Reply-To: <1386681097-14126-1-git-send-email-gsi@denx.de>
add clock related specs to the MPC5125 "tower" board DTS
- add clock providers (crystal/oscillator, clock control module)
- add consumers (the CAN, SDHC, I2C, DIU, FEC, USB, PSC peripherals)
Signed-off-by: Gerhard Sittig <gsi@denx.de>
---
arch/powerpc/boot/dts/mpc5125twr.dts | 53 +++++++++++++++++++++++++++++++++-
1 file changed, 52 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/dts/mpc5125twr.dts b/arch/powerpc/boot/dts/mpc5125twr.dts
index 0a0fe92216ae..806479ffc607 100644
--- a/arch/powerpc/boot/dts/mpc5125twr.dts
+++ b/arch/powerpc/boot/dts/mpc5125twr.dts
@@ -12,6 +12,8 @@
* option) any later version.
*/
+#include <dt-bindings/clock/mpc512x-clock.h>
+
/dts-v1/;
/ {
@@ -54,6 +56,17 @@
reg = <0x30000000 0x08000>; // 32K at 0x30000000
};
+ clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ osc: osc {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <33000000>;
+ };
+ };
+
soc@80000000 {
compatible = "fsl,mpc5121-immr";
#address-cells = <1>;
@@ -87,9 +100,12 @@
reg = <0xe00 0x100>;
};
- clock@f00 { // Clock control
+ clks: clock@f00 { // Clock control
compatible = "fsl,mpc5121-clock";
reg = <0xf00 0x100>;
+ #clock-cells = <1>;
+ clocks = <&osc>;
+ clock-names = "osc";
};
pmc@1000{ // Power Management Controller
@@ -114,18 +130,33 @@
compatible = "fsl,mpc5121-mscan";
interrupts = <12 0x8>;
reg = <0x1300 0x80>;
+ clocks = <&clks MPC512x_CLK_BDLC>,
+ <&clks MPC512x_CLK_IPS>,
+ <&clks MPC512x_CLK_SYS>,
+ <&clks MPC512x_CLK_REF>,
+ <&clks MPC512x_CLK_MSCAN0_MCLK>;
+ clock-names = "ipg", "ips", "sys", "ref", "mclk";
};
can@1380 {
compatible = "fsl,mpc5121-mscan";
interrupts = <13 0x8>;
reg = <0x1380 0x80>;
+ clocks = <&clks MPC512x_CLK_BDLC>,
+ <&clks MPC512x_CLK_IPS>,
+ <&clks MPC512x_CLK_SYS>,
+ <&clks MPC512x_CLK_REF>,
+ <&clks MPC512x_CLK_MSCAN1_MCLK>;
+ clock-names = "ipg", "ips", "sys", "ref", "mclk";
};
sdhc@1500 {
compatible = "fsl,mpc5121-sdhc";
interrupts = <8 0x8>;
reg = <0x1500 0x100>;
+ clocks = <&clks MPC512x_CLK_IPS>,
+ <&clks MPC512x_CLK_SDHC>;
+ clock-names = "ipg", "per";
};
i2c@1700 {
@@ -134,6 +165,8 @@
compatible = "fsl,mpc5121-i2c", "fsl-i2c";
reg = <0x1700 0x20>;
interrupts = <0x9 0x8>;
+ clocks = <&clks MPC512x_CLK_I2C>;
+ clock-names = "ipg";
};
i2c@1720 {
@@ -142,6 +175,8 @@
compatible = "fsl,mpc5121-i2c", "fsl-i2c";
reg = <0x1720 0x20>;
interrupts = <0xa 0x8>;
+ clocks = <&clks MPC512x_CLK_I2C>;
+ clock-names = "ipg";
};
i2c@1740 {
@@ -150,6 +185,8 @@
compatible = "fsl,mpc5121-i2c", "fsl-i2c";
reg = <0x1740 0x20>;
interrupts = <0xb 0x8>;
+ clocks = <&clks MPC512x_CLK_I2C>;
+ clock-names = "ipg";
};
i2ccontrol@1760 {
@@ -161,6 +198,8 @@
compatible = "fsl,mpc5121-diu";
reg = <0x2100 0x100>;
interrupts = <64 0x8>;
+ clocks = <&clks MPC512x_CLK_DIU>;
+ clock-names = "ipg";
};
mdio@2800 {
@@ -180,6 +219,8 @@
interrupts = <4 0x8>;
phy-handle = < &phy0 >;
phy-connection-type = "rmii";
+ clocks = <&clks MPC512x_CLK_FEC>;
+ clock-names = "per";
};
// IO control
@@ -196,6 +237,8 @@
interrupts = <43 0x8>;
dr_mode = "host";
phy_type = "ulpi";
+ clocks = <&clks MPC512x_CLK_USB1>;
+ clock-names = "ipg";
};
// 5125 PSCs are not 52xx or 5121 PSC compatible
@@ -206,6 +249,9 @@
interrupts = <40 0x8>;
fsl,rx-fifo-size = <16>;
fsl,tx-fifo-size = <16>;
+ clocks = <&clks MPC512x_CLK_PSC1>,
+ <&clks MPC512x_CLK_PSC1_MCLK>;
+ clock-names = "ipg", "mclk";
};
// PSC9 uart1 aka ttyPSC1
@@ -215,12 +261,17 @@
interrupts = <40 0x8>;
fsl,rx-fifo-size = <16>;
fsl,tx-fifo-size = <16>;
+ clocks = <&clks MPC512x_CLK_PSC9>,
+ <&clks MPC512x_CLK_PSC9_MCLK>;
+ clock-names = "ipg", "mclk";
};
pscfifo@11f00 {
compatible = "fsl,mpc5121-psc-fifo";
reg = <0x11f00 0x100>;
interrupts = <40 0x8>;
+ clocks = <&clks MPC512x_CLK_PSC_FIFO>;
+ clock-names = "ipg";
};
dma@14000 {
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH v2] powerpc 8xx: Loading kernels over 8Mbytes without CONFIG_PIN_TLB
From: Scott Wood @ 2013-12-10 23:18 UTC (permalink / raw)
To: leroy christophe; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <52A79E31.9070304@c-s.fr>
On Wed, 2013-12-11 at 00:05 +0100, leroy christophe wrote:
> Le 10/12/2013 23:24, Scott Wood a =C3=A9crit :
> > On Tue, 2013-12-10 at 12:29 +0100, Christophe Leroy wrote:
> >> Today, the only way to load kernels whose size is greater than 8Mbyt=
es is to
> >> activate CONFIG_PIN_TLB. Otherwise, the physical memory initially ma=
pped is
> >> limited to 8Mbytes. This patch adds the capability to select the siz=
e of initial
> >> memory between 8/16/24 Mbytes and this is regardless of whether CONF=
IG_PIN_TLB
> >> is active or not. It allows to load "big" kernels (for instance when=
activating
> >> CONFIG_LOCKDEP_SUPPORT) without having to activate CONFIG_PIN_TLB.
> >>
> >> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> >>
> >> diff -ur a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> >> --- a/arch/powerpc/Kconfig
> >> +++ b/arch/powerpc/Kconfig
> >> @@ -980,6 +980,29 @@
> >> config PIN_TLB
> >> bool "Pinned Kernel TLBs (860 ONLY)"
> >> depends on ADVANCED_OPTIONS && 8xx
> >> +
> >> +choice
> >> + prompt "Initial Data Memory Mapped on 8xx"
> >> + default 8xx_MAP_8M
> >> + depends on ADVANCED_OPTIONS && 8xx
> >> +
> >> +config 8xx_INIT_MAP_8M
> >> + bool "8 Mbytes"
> >> +
> >> +config 8xx_INIT_MAP_16M
> >> + bool "16 Mbytes"
> >> +
> >> +config 8xx_INIT_MAP_24M
> >> + bool "24 Mbytes"
> > Are you working with a loader that passes initial-mapped-area size in=
r7
> > as per ePAPR? If so, we could rely on that at runtime. If you're us=
ing
> > a non-ancient U-Boot, it should qualify here even if it's not fully
> > ePAPR compliant (it passes the value of the bootm_mapsize variable in
> > r7).
> Ok, let me check that. But it means that the size of the kernel I can=20
> boot will depend on the initial memory mapped by uboot ? Isn't it=20
> limitating ?
The ePAPR IMA is supposed to be large enough to include the OS image,
device tree, etc.
> Even if uboot only maps 8Mbytes, why couldn't I be allowed to boot a=20
> kernel having 10 Mbytes data if I have 32 Mbytes mem on the board ?
> I don't like the idea of having to change the bootloader just because I=
=20
> want to activate CONFIG_LOCKDEP to debug my kernel.
Well, as noted, if you're using a non-ancient U-Boot you shouldn't have
to change anything because it already implements r7. Now, the value of
r7 it passes might be a lie as far as ePAPR is concerned, since it's
supposed to represent what's actually mapped, but that's another matter.
Even fixing that wouldn't mean you have to change U-Boot every time the
kernel size changes; you'd just set it to something reasonable and be
done with it. I'm not fond of adding kconfigs to hack around a problem
that has already been addressed in the standard that governs the PPC
boot process that U-Boot claims to implement.
> >> -#ifdef CONFIG_PIN_TLB
> >> +#if defined (CONFIG_8xx_INIT_MAP_16M) || defined (CONFIG_8xx_INIT_M=
AP_24M)
> >> /* Map two more 8M kernel data pages.
> >> */
> >> +#ifdef CONFIG_PIN_TLB
> >> addi r10, r10, 0x0100
> >> mtspr SPRN_MD_CTR, r10
> >> +#endif
> >> =20
> >> lis r8, KERNELBASE@h /* Create vaddr for TLB */
> >> addis r8, r8, 0x0080 /* Add 8M */
> >> @@ -858,15 +860,19 @@
> >> addis r11, r11, 0x0080 /* Add 8M */
> >> mtspr SPRN_MD_RPN, r11
> >> =20
> >> +#ifdef CONFIG_8xx_INIT_MAP_24M
> >> +#ifdef CONFIG_PIN_TLB
> >> addi r10, r10, 0x0100
> >> mtspr SPRN_MD_CTR, r10
> >> +#endif
> > Are these ifdefs for CONFIG_PIN_TLB really needed? It shouldn't harm
> > anything to use those entries even if they're not being pinned.
>=20
> I'm not sure I understand your comment.
> ifdef for CONFIG_PIN_TLB was already there before, but was enclosing th=
e=20
> whole block, so 24 Mbytes were automatically mapped when you selected=20
> CONFIG_PIN_TLB and only 8 Mbytes were mapped when you didn't select=20
> CONFIG_PIN_TLB.
> I reduced the scope of those ifdefs so that they now apply on the=20
> pinning only.
There wasn't previously an ifdef specifically around the setting of
SPRN_MD_CTR. That's new. There was an ifdef around the entire block,
which has gone away because you are now trying to map more than 8M
regardless of CONFIG_PIN_TLB, but that has nothing to do with whether
there should be an ifdef around SPRN_MD_CTR.
-Scott
^ permalink raw reply
* Re: [PATCH v2] powerpc 8xx: Loading kernels over 8Mbytes without CONFIG_PIN_TLB
From: leroy christophe @ 2013-12-10 23:36 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <1386717537.10013.150.camel@snotra.buserror.net>
Le 11/12/2013 00:18, Scott Wood a écrit :
> On Wed, 2013-12-11 at 00:05 +0100, leroy christophe wrote:
>> Le 10/12/2013 23:24, Scott Wood a écrit :
>>> On Tue, 2013-12-10 at 12:29 +0100, Christophe Leroy wrote:
>>>> Today, the only way to load kernels whose size is greater than 8Mbytes is to
>>>> activate CONFIG_PIN_TLB. Otherwise, the physical memory initially mapped is
>>>> limited to 8Mbytes. This patch adds the capability to select the size of initial
>>>> memory between 8/16/24 Mbytes and this is regardless of whether CONFIG_PIN_TLB
>>>> is active or not. It allows to load "big" kernels (for instance when activating
>>>> CONFIG_LOCKDEP_SUPPORT) without having to activate CONFIG_PIN_TLB.
>>>>
>>>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>>>>
>>>> diff -ur a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>>>> --- a/arch/powerpc/Kconfig
>>>> +++ b/arch/powerpc/Kconfig
>>>> @@ -980,6 +980,29 @@
>>>> config PIN_TLB
>>>> bool "Pinned Kernel TLBs (860 ONLY)"
>>>> depends on ADVANCED_OPTIONS && 8xx
>>>> +
>>>> +choice
>>>> + prompt "Initial Data Memory Mapped on 8xx"
>>>> + default 8xx_MAP_8M
>>>> + depends on ADVANCED_OPTIONS && 8xx
>>>> +
>>>> +config 8xx_INIT_MAP_8M
>>>> + bool "8 Mbytes"
>>>> +
>>>> +config 8xx_INIT_MAP_16M
>>>> + bool "16 Mbytes"
>>>> +
>>>> +config 8xx_INIT_MAP_24M
>>>> + bool "24 Mbytes"
>>> Are you working with a loader that passes initial-mapped-area size in r7
>>> as per ePAPR? If so, we could rely on that at runtime. If you're using
>>> a non-ancient U-Boot, it should qualify here even if it's not fully
>>> ePAPR compliant (it passes the value of the bootm_mapsize variable in
>>> r7).
>> Ok, let me check that. But it means that the size of the kernel I can
>> boot will depend on the initial memory mapped by uboot ? Isn't it
>> limitating ?
> The ePAPR IMA is supposed to be large enough to include the OS image,
> device tree, etc.
>
>> Even if uboot only maps 8Mbytes, why couldn't I be allowed to boot a
>> kernel having 10 Mbytes data if I have 32 Mbytes mem on the board ?
>> I don't like the idea of having to change the bootloader just because I
>> want to activate CONFIG_LOCKDEP to debug my kernel.
> Well, as noted, if you're using a non-ancient U-Boot you shouldn't have
> to change anything because it already implements r7. Now, the value of
> r7 it passes might be a lie as far as ePAPR is concerned, since it's
> supposed to represent what's actually mapped, but that's another matter.
>
> Even fixing that wouldn't mean you have to change U-Boot every time the
> kernel size changes; you'd just set it to something reasonable and be
> done with it. I'm not fond of adding kconfigs to hack around a problem
> that has already been addressed in the standard that governs the PPC
> boot process that U-Boot claims to implement.
Well, ok, that makes sense. I'll investigate around that solution.
>
>>>> -#ifdef CONFIG_PIN_TLB
>>>> +#if defined (CONFIG_8xx_INIT_MAP_16M) || defined (CONFIG_8xx_INIT_MAP_24M)
>>>> /* Map two more 8M kernel data pages.
>>>> */
>>>> +#ifdef CONFIG_PIN_TLB
>>>> addi r10, r10, 0x0100
>>>> mtspr SPRN_MD_CTR, r10
>>>> +#endif
>>>>
>>>> lis r8, KERNELBASE@h /* Create vaddr for TLB */
>>>> addis r8, r8, 0x0080 /* Add 8M */
>>>> @@ -858,15 +860,19 @@
>>>> addis r11, r11, 0x0080 /* Add 8M */
>>>> mtspr SPRN_MD_RPN, r11
>>>>
>>>> +#ifdef CONFIG_8xx_INIT_MAP_24M
>>>> +#ifdef CONFIG_PIN_TLB
>>>> addi r10, r10, 0x0100
>>>> mtspr SPRN_MD_CTR, r10
>>>> +#endif
>>> Are these ifdefs for CONFIG_PIN_TLB really needed? It shouldn't harm
>>> anything to use those entries even if they're not being pinned.
>> I'm not sure I understand your comment.
>> ifdef for CONFIG_PIN_TLB was already there before, but was enclosing the
>> whole block, so 24 Mbytes were automatically mapped when you selected
>> CONFIG_PIN_TLB and only 8 Mbytes were mapped when you didn't select
>> CONFIG_PIN_TLB.
>> I reduced the scope of those ifdefs so that they now apply on the
>> pinning only.
> There wasn't previously an ifdef specifically around the setting of
> SPRN_MD_CTR. That's new. There was an ifdef around the entire block,
> which has gone away because you are now trying to map more than 8M
> regardless of CONFIG_PIN_TLB, but that has nothing to do with whether
> there should be an ifdef around SPRN_MD_CTR.
>
>
Euh, ok, but then we have to fix it in the whole function, not only in
this block. Do you think it is worth doing it ?
Then we are back to the problem we discussed some months ago which is
that the 8xx is decrementing the MD_CTR after writting a TLB entry, and
if pinning is activated it decrements it out of the pinnable area. So it
would still be needed to:
* Reposition it for each entry for when the pinning is activated
* Make sure we set it out of the area at the end when the pinning is not
active hence the area not protected.
* Then we should probably reverse the entries, start at 31 and go down
to 28 instead of going from 28 to 31 as do today.
But is it worth doing such a big change which will not add anything
functionnaly speaking ?
Christophe
^ permalink raw reply
* [PATCH v1 3/4] powerpc/512x: clk: support MPC5121/5123/5125 SoC variants
From: Gerhard Sittig @ 2013-12-10 13:11 UTC (permalink / raw)
To: linuxppc-dev, linux-arm-kernel, Anatolij Gustschin,
Mike Turquette, Matteo Facchinetti
Cc: Scott Wood, Gerhard Sittig, Detlev Zundel
In-Reply-To: <1386681097-14126-1-git-send-email-gsi@denx.de>
improve the common clock support code for MPC512x
- expand the CCM register set declaration with MPC5125 related registers
(which reside in the previously "reserved" area)
- tell the MPC5121, MPC5123, and MPC5125 SoC variants apart, and derive
the availability of components and their clocks from the detected SoC
(MBX, AXE, VIU, SPDIF, PATA, SATA, PCI, second FEC, second SDHC,
number of PSC components, type of NAND flash controller,
interpretation of the CPMF bitfield, PSC/CAN mux0 stage input clocks,
output clocks on SoC pins)
- add backwards compatibility (allow operation against a device tree
which lacks clock related specs) for MPC5125 FECs, too
telling SoC variants apart and adjusting the clock tree's generation
occurs at runtime, a common generic binary supports all of the chips
the MPC5125 approach to the NFC clock (one register with two counters
for the high and low periods of the clock) is not implemented, as there
are no users and there is no common implementation which supports this
kind of clock -- the new implementation would be unused and could not
get verified, so it shall wait until there is demand
Signed-off-by: Gerhard Sittig <gsi@denx.de>
---
arch/powerpc/include/asm/mpc5121.h | 7 +-
arch/powerpc/platforms/512x/clock-commonclk.c | 339 +++++++++++++++++++++----
include/dt-bindings/clock/mpc512x-clock.h | 9 +-
3 files changed, 309 insertions(+), 46 deletions(-)
diff --git a/arch/powerpc/include/asm/mpc5121.h b/arch/powerpc/include/asm/mpc5121.h
index 887d3d6133e3..4a69cd1d5041 100644
--- a/arch/powerpc/include/asm/mpc5121.h
+++ b/arch/powerpc/include/asm/mpc5121.h
@@ -37,7 +37,12 @@ struct mpc512x_ccm {
u32 cccr; /* CFM Clock Control Register */
u32 dccr; /* DIU Clock Control Register */
u32 mscan_ccr[4]; /* MSCAN Clock Control Registers */
- u8 res[0x98]; /* Reserved */
+ u32 out_ccr[4]; /* OUT CLK Configure Registers */
+ u32 rsv0[2]; /* Reserved */
+ u32 scfr3; /* System Clock Frequency Register 3 */
+ u32 rsv1[3]; /* Reserved */
+ u32 spll_lock_cnt; /* System PLL Lock Counter */
+ u8 res[0x6c]; /* Reserved */
};
/*
diff --git a/arch/powerpc/platforms/512x/clock-commonclk.c b/arch/powerpc/platforms/512x/clock-commonclk.c
index b5190fcb81bb..af8d50d58af5 100644
--- a/arch/powerpc/platforms/512x/clock-commonclk.c
+++ b/arch/powerpc/platforms/512x/clock-commonclk.c
@@ -36,7 +36,8 @@ enum {
#define NR_PSCS 12
#define NR_MSCANS 4
#define NR_SPDIFS 1
-#define NR_MCLKS (NR_PSCS + NR_MSCANS + NR_SPDIFS)
+#define NR_OUTCLK 4
+#define NR_MCLKS (NR_PSCS + NR_MSCANS + NR_SPDIFS + NR_OUTCLK)
/* extend the public set of clocks by adding internal slots for management */
enum {
@@ -46,11 +47,11 @@ enum {
MPC512x_CLK_DDR,
MPC512x_CLK_MEM,
MPC512x_CLK_IIM,
- MPC512x_CLK_SDHC_2,
/* intermediates in div+gate combos or fractional dividers */
MPC512x_CLK_DDR_UG,
MPC512x_CLK_SDHC_x4,
MPC512x_CLK_SDHC_UG,
+ MPC512x_CLK_SDHC2_UG,
MPC512x_CLK_DIU_x4,
MPC512x_CLK_DIU_UG,
MPC512x_CLK_MBX_BUS_UG,
@@ -76,6 +77,144 @@ static struct clk_onecell_data clk_data;
static struct mpc512x_ccm __iomem *clkregs;
static DEFINE_SPINLOCK(clklock);
+/* SoC variants {{{ */
+
+/*
+ * tell SoC variants apart as they are rather similar yet not identical,
+ * cache the result in an enum to not repeatedly run the expensive OF test
+ *
+ * MPC5123 is an MPC5121 without the MBX graphics accelerator
+ *
+ * MPC5125 has many more differences: no MBX, no AXE, no VIU, no SPDIF,
+ * no PATA, no SATA, no PCI, two FECs (of different compatibility name),
+ * only 10 PSCs (of different compatibility name), two SDHCs, different
+ * NFC IP block, output clocks, system PLL status query, different CPMF
+ * interpretation, no CFM, different fourth PSC/CAN mux0 input -- yet
+ * those differences can get folded into this clock provider support
+ * code and don't warrant a separate highly redundant implementation
+ */
+
+static enum soc_type {
+ MPC512x_SOC_MPC5121,
+ MPC512x_SOC_MPC5123,
+ MPC512x_SOC_MPC5125,
+} soc;
+
+static void mpc512x_clk_determine_soc(void)
+{
+ if (of_machine_is_compatible("fsl,mpc5121")) {
+ soc = MPC512x_SOC_MPC5121;
+ return;
+ }
+ if (of_machine_is_compatible("fsl,mpc5123")) {
+ soc = MPC512x_SOC_MPC5123;
+ return;
+ }
+ if (of_machine_is_compatible("fsl,mpc5125")) {
+ soc = MPC512x_SOC_MPC5125;
+ return;
+ }
+}
+
+static bool soc_has_mbx(void)
+{
+ if (soc == MPC512x_SOC_MPC5121)
+ return true;
+ return false;
+}
+
+static bool soc_has_axe(void)
+{
+ if (soc == MPC512x_SOC_MPC5125)
+ return false;
+ return true;
+}
+
+static bool soc_has_viu(void)
+{
+ if (soc == MPC512x_SOC_MPC5125)
+ return false;
+ return true;
+}
+
+static bool soc_has_spdif(void)
+{
+ if (soc == MPC512x_SOC_MPC5125)
+ return false;
+ return true;
+}
+
+static bool soc_has_pata(void)
+{
+ if (soc == MPC512x_SOC_MPC5125)
+ return false;
+ return true;
+}
+
+static bool soc_has_sata(void)
+{
+ if (soc == MPC512x_SOC_MPC5125)
+ return false;
+ return true;
+}
+
+static bool soc_has_pci(void)
+{
+ if (soc == MPC512x_SOC_MPC5125)
+ return false;
+ return true;
+}
+
+static bool soc_has_fec2(void)
+{
+ if (soc == MPC512x_SOC_MPC5125)
+ return true;
+ return false;
+}
+
+static int soc_max_pscnum(void)
+{
+ if (soc == MPC512x_SOC_MPC5125)
+ return 10;
+ return 12;
+}
+
+static bool soc_has_sdhc2(void)
+{
+ if (soc == MPC512x_SOC_MPC5125)
+ return true;
+ return false;
+}
+
+static bool soc_has_nfc_5125(void)
+{
+ if (soc == MPC512x_SOC_MPC5125)
+ return true;
+ return false;
+}
+
+static bool soc_has_outclk(void)
+{
+ if (soc == MPC512x_SOC_MPC5125)
+ return true;
+ return false;
+}
+
+static bool soc_has_cpmf_0_bypass(void)
+{
+ if (soc == MPC512x_SOC_MPC5125)
+ return true;
+ return false;
+}
+
+static bool soc_has_mclk_mux0_canin(void)
+{
+ if (soc == MPC512x_SOC_MPC5125)
+ return true;
+ return false;
+}
+
+/* }}} SoC variants */
/* common clk API wrappers {{{ */
/* convenience wrappers around the common clk API */
@@ -196,12 +335,23 @@ static int get_sys_div_x2(void)
*/
static int get_cpmf_mult_x2(void)
{
- static int cpmf_to_mult[] = {
+ static int cpmf_to_mult_x36[] = {
+ /* 0b000 is "times 36" */
72, 2, 2, 3, 4, 5, 6, 7,
};
+ static int cpmf_to_mult_0by[] = {
+ /* 0b000 is "bypass" */
+ 2, 2, 2, 3, 4, 5, 6, 7,
+ };
+
+ int *cpmf_to_mult;
int cpmf;
cpmf = get_bit_field(&clkregs->spmr, 16, 4);
+ if (soc_has_cpmf_0_bypass())
+ cpmf_to_mult = cpmf_to_mult_0by;
+ else
+ cpmf_to_mult = cpmf_to_mult_x36;
return cpmf_to_mult[cpmf];
}
@@ -347,14 +497,19 @@ static void mpc512x_clk_setup_ref_clock(struct device_node *np, int bus_freq,
* it's the very data type dictated by <linux/clk-provider.h>,
* "fixing" this warning will break compilation
*/
-static const char *parent_names_mux0[] = {
+static const char *parent_names_mux0_spdif[] = {
"sys", "ref", "psc-mclk-in", "spdif-tx",
};
+static const char *parent_names_mux0_canin[] = {
+ "sys", "ref", "psc-mclk-in", "can-clk-in",
+};
+
enum mclk_type {
MCLK_TYPE_PSC,
MCLK_TYPE_MSCAN,
MCLK_TYPE_SPDIF,
+ MCLK_TYPE_OUTCLK,
};
struct mclk_setup_data {
@@ -394,6 +549,15 @@ struct mclk_setup_data {
"spdif_mclk", \
}
+#define MCLK_SETUP_DATA_OUTCLK(id) { \
+ MCLK_TYPE_OUTCLK, 0, \
+ "out" #id "-mux0", \
+ "out" #id "-en0", \
+ "out" #id "_mclk_div", \
+ { "out" #id "_mclk_div", "dummy", }, \
+ "out" #id "_clk", \
+}
+
static struct mclk_setup_data mclk_psc_data[] = {
MCLK_SETUP_DATA_PSC(0),
MCLK_SETUP_DATA_PSC(1),
@@ -420,6 +584,13 @@ static struct mclk_setup_data mclk_spdif_data[] = {
MCLK_SETUP_DATA_SPDIF,
};
+static struct mclk_setup_data mclk_outclk_data[] = {
+ MCLK_SETUP_DATA_OUTCLK(0),
+ MCLK_SETUP_DATA_OUTCLK(1),
+ MCLK_SETUP_DATA_OUTCLK(2),
+ MCLK_SETUP_DATA_OUTCLK(3),
+};
+
/* setup the MCLK clock subtree of an individual PSC/MSCAN/SPDIF */
static void mpc512x_clk_setup_mclk(struct mclk_setup_data *entry, size_t idx)
{
@@ -447,6 +618,13 @@ static void mpc512x_clk_setup_mclk(struct mclk_setup_data *entry, size_t idx)
+ (NR_PSCS + NR_MSCANS) * MCLK_MAX_IDX;
mccr_reg = &clkregs->spccr;
break;
+ case MCLK_TYPE_OUTCLK:
+ clks_idx_pub = MPC512x_CLK_OUT0_CLK + idx;
+ clks_idx_int = MPC512x_CLK_MCLKS_FIRST
+ + (NR_PSCS + NR_MSCANS + NR_SPDIFS + idx)
+ * MCLK_MAX_IDX;
+ mccr_reg = &clkregs->out_ccr[idx];
+ break;
default:
return;
}
@@ -495,7 +673,10 @@ static void mpc512x_clk_setup_mclk(struct mclk_setup_data *entry, size_t idx)
*/
clks[clks_idx_int + MCLK_IDX_MUX0] = mpc512x_clk_muxed(
entry->name_mux0,
- &parent_names_mux0[0], ARRAY_SIZE(parent_names_mux0),
+ soc_has_mclk_mux0_canin()
+ ? &parent_names_mux0_canin[0]
+ : &parent_names_mux0_spdif[0],
+ ARRAY_SIZE(parent_names_mux0_spdif),
mccr_reg, 14, 2);
clks[clks_idx_int + MCLK_IDX_EN0] = mpc512x_clk_gated(
entry->name_en0, entry->name_mux0,
@@ -576,6 +757,12 @@ static void mpc512x_clk_setup_clock_tree(struct device_node *np, int busfreq)
clks[MPC512x_CLK_SDHC_UG] = mpc512x_clk_divider("sdhc-ug", "sdhc-x4", 0,
&clkregs->scfr2, 1, 7,
CLK_DIVIDER_ONE_BASED);
+ if (soc_has_sdhc2()) {
+ clks[MPC512x_CLK_SDHC2_UG] = mpc512x_clk_divider(
+ "sdhc2-ug", "sdhc-x4", 0, &clkregs->scfr2,
+ 9, 7, CLK_DIVIDER_ONE_BASED);
+ }
+
clks[MPC512x_CLK_DIU_x4] = mpc512x_clk_factor("diu-x4", "csb", 4, 1);
clks[MPC512x_CLK_DIU_UG] = mpc512x_clk_divider("diu-ug", "diu-x4", 0,
&clkregs->scfr1, 0, 8,
@@ -592,19 +779,32 @@ static void mpc512x_clk_setup_clock_tree(struct device_node *np, int busfreq)
div = 2; /* compensate for the fractional factor */
clks[MPC512x_CLK_E300] = mpc512x_clk_factor("e300", "csb", mul, div);
- clks[MPC512x_CLK_MBX_BUS_UG] = mpc512x_clk_factor("mbx-bus-ug", "csb",
- 1, 2);
- clks[MPC512x_CLK_MBX_UG] = mpc512x_clk_divtable("mbx-ug", "mbx-bus-ug",
- &clkregs->scfr1, 14, 3,
- divtab_1234);
- clks[MPC512x_CLK_MBX_3D_UG] = mpc512x_clk_factor("mbx-3d-ug", "mbx-ug",
- 1, 1);
- clks[MPC512x_CLK_PCI_UG] = mpc512x_clk_divtable("pci-ug", "csb",
- &clkregs->scfr1, 20, 3,
- divtab_2346);
- clks[MPC512x_CLK_NFC_UG] = mpc512x_clk_divtable("nfc-ug", "ips",
- &clkregs->scfr1, 8, 3,
- divtab_1234);
+ if (soc_has_mbx()) {
+ clks[MPC512x_CLK_MBX_BUS_UG] = mpc512x_clk_factor(
+ "mbx-bus-ug", "csb", 1, 2);
+ clks[MPC512x_CLK_MBX_UG] = mpc512x_clk_divtable(
+ "mbx-ug", "mbx-bus-ug", &clkregs->scfr1,
+ 14, 3, divtab_1234);
+ clks[MPC512x_CLK_MBX_3D_UG] = mpc512x_clk_factor(
+ "mbx-3d-ug", "mbx-ug", 1, 1);
+ }
+ if (soc_has_pci()) {
+ clks[MPC512x_CLK_PCI_UG] = mpc512x_clk_divtable(
+ "pci-ug", "csb", &clkregs->scfr1,
+ 20, 3, divtab_2346);
+ }
+ if (soc_has_nfc_5125()) {
+ /*
+ * XXX TODO implement 5125 NFC clock setup logic,
+ * with high/low period counters in clkregs->scfr3,
+ * currently there are no users so it's ENOIMPL
+ */
+ clks[MPC512x_CLK_NFC_UG] = ERR_PTR(-ENOTSUPP);
+ } else {
+ clks[MPC512x_CLK_NFC_UG] = mpc512x_clk_divtable(
+ "nfc-ug", "ips", &clkregs->scfr1,
+ 8, 3, divtab_1234);
+ }
clks[MPC512x_CLK_LPC_UG] = mpc512x_clk_divtable("lpc-ug", "ips",
&clkregs->scfr1, 11, 3,
divtab_1234);
@@ -613,10 +813,12 @@ static void mpc512x_clk_setup_clock_tree(struct device_node *np, int busfreq)
&clkregs->sccr1, 30);
clks[MPC512x_CLK_NFC] = mpc512x_clk_gated("nfc", "nfc-ug",
&clkregs->sccr1, 29);
- clks[MPC512x_CLK_PATA] = mpc512x_clk_gated("pata", "ips",
- &clkregs->sccr1, 28);
+ if (soc_has_pata()) {
+ clks[MPC512x_CLK_PATA] = mpc512x_clk_gated(
+ "pata", "ips", &clkregs->sccr1, 28);
+ }
/* for PSCs there is a "registers" gate and a bitrate MCLK subtree */
- for (mclk_idx = 0; mclk_idx < ARRAY_SIZE(mclk_psc_data); mclk_idx++) {
+ for (mclk_idx = 0; mclk_idx < soc_max_pscnum(); mclk_idx++) {
char name[12];
snprintf(name, sizeof(name), "psc%d", mclk_idx);
clks[MPC512x_CLK_PSC0 + mclk_idx] = mpc512x_clk_gated(
@@ -625,19 +827,29 @@ static void mpc512x_clk_setup_clock_tree(struct device_node *np, int busfreq)
}
clks[MPC512x_CLK_PSC_FIFO] = mpc512x_clk_gated("psc-fifo", "ips",
&clkregs->sccr1, 15);
- clks[MPC512x_CLK_SATA] = mpc512x_clk_gated("sata", "ips",
- &clkregs->sccr1, 14);
+ if (soc_has_sata()) {
+ clks[MPC512x_CLK_SATA] = mpc512x_clk_gated(
+ "sata", "ips", &clkregs->sccr1, 14);
+ }
clks[MPC512x_CLK_FEC] = mpc512x_clk_gated("fec", "ips",
&clkregs->sccr1, 13);
- clks[MPC512x_CLK_PCI] = mpc512x_clk_gated("pci", "pci-ug",
- &clkregs->sccr1, 11);
+ if (soc_has_pci()) {
+ clks[MPC512x_CLK_PCI] = mpc512x_clk_gated(
+ "pci", "pci-ug", &clkregs->sccr1, 11);
+ }
clks[MPC512x_CLK_DDR] = mpc512x_clk_gated("ddr", "ddr-ug",
&clkregs->sccr1, 10);
+ if (soc_has_fec2()) {
+ clks[MPC512x_CLK_FEC2] = mpc512x_clk_gated(
+ "fec2", "ips", &clkregs->sccr1, 9);
+ }
clks[MPC512x_CLK_DIU] = mpc512x_clk_gated("diu", "diu-ug",
&clkregs->sccr2, 31);
- clks[MPC512x_CLK_AXE] = mpc512x_clk_gated("axe", "csb",
- &clkregs->sccr2, 30);
+ if (soc_has_axe()) {
+ clks[MPC512x_CLK_AXE] = mpc512x_clk_gated(
+ "axe", "csb", &clkregs->sccr2, 30);
+ }
clks[MPC512x_CLK_MEM] = mpc512x_clk_gated("mem", "ips",
&clkregs->sccr2, 29);
clks[MPC512x_CLK_USB1] = mpc512x_clk_gated("usb1", "csb",
@@ -654,21 +866,35 @@ static void mpc512x_clk_setup_clock_tree(struct device_node *np, int busfreq)
clks[MPC512x_CLK_SDHC] = mpc512x_clk_gated("sdhc", "sdhc-ug",
&clkregs->sccr2, 24);
/* there is only one SPDIF component, which shares MCLK support code */
- clks[MPC512x_CLK_SPDIF] = mpc512x_clk_gated("spdif", "ips",
- &clkregs->sccr2, 23);
- mpc512x_clk_setup_mclk(&mclk_spdif_data[0], 0);
- clks[MPC512x_CLK_MBX_BUS] = mpc512x_clk_gated("mbx-bus", "mbx-bus-ug",
- &clkregs->sccr2, 22);
- clks[MPC512x_CLK_MBX] = mpc512x_clk_gated("mbx", "mbx-ug",
- &clkregs->sccr2, 21);
- clks[MPC512x_CLK_MBX_3D] = mpc512x_clk_gated("mbx-3d", "mbx-3d-ug",
- &clkregs->sccr2, 20);
+ if (soc_has_spdif()) {
+ clks[MPC512x_CLK_SPDIF] = mpc512x_clk_gated(
+ "spdif", "ips", &clkregs->sccr2, 23);
+ mpc512x_clk_setup_mclk(&mclk_spdif_data[0], 0);
+ }
+ if (soc_has_mbx()) {
+ clks[MPC512x_CLK_MBX_BUS] = mpc512x_clk_gated(
+ "mbx-bus", "mbx-bus-ug", &clkregs->sccr2, 22);
+ clks[MPC512x_CLK_MBX] = mpc512x_clk_gated(
+ "mbx", "mbx-ug", &clkregs->sccr2, 21);
+ clks[MPC512x_CLK_MBX_3D] = mpc512x_clk_gated(
+ "mbx-3d", "mbx-3d-ug", &clkregs->sccr2, 20);
+ }
clks[MPC512x_CLK_IIM] = mpc512x_clk_gated("iim", "csb",
&clkregs->sccr2, 19);
- clks[MPC512x_CLK_VIU] = mpc512x_clk_gated("viu", "csb",
- &clkregs->sccr2, 18);
- clks[MPC512x_CLK_SDHC_2] = mpc512x_clk_gated("sdhc-2", "sdhc-ug",
- &clkregs->sccr2, 17);
+ if (soc_has_viu()) {
+ clks[MPC512x_CLK_VIU] = mpc512x_clk_gated(
+ "viu", "csb", &clkregs->sccr2, 18);
+ }
+ if (soc_has_sdhc2()) {
+ clks[MPC512x_CLK_SDHC2] = mpc512x_clk_gated(
+ "sdhc-2", "sdhc2-ug", &clkregs->sccr2, 17);
+ }
+
+ if (soc_has_outclk()) {
+ size_t idx; /* used as mclk_idx, just to trim line length */
+ for (idx = 0; idx < ARRAY_SIZE(mclk_outclk_data); idx++)
+ mpc512x_clk_setup_mclk(&mclk_outclk_data[idx], idx);
+ }
/*
* externally provided clocks (when implemented in hardware,
@@ -678,10 +904,18 @@ static void mpc512x_clk_setup_clock_tree(struct device_node *np, int busfreq)
if (!freq)
freq = 25000000;
clks[MPC512x_CLK_PSC_MCLK_IN] = mpc512x_clk_fixed("psc_mclk_in", freq);
- freq = get_freq_from_dt("spdif_tx_in");
- clks[MPC512x_CLK_SPDIF_TX_IN] = mpc512x_clk_fixed("spdif_tx_in", freq);
- freq = get_freq_from_dt("spdif_rx_in");
- clks[MPC512x_CLK_SPDIF_TX_IN] = mpc512x_clk_fixed("spdif_rx_in", freq);
+ if (soc_has_mclk_mux0_canin()) {
+ freq = get_freq_from_dt("can_clk_in");
+ clks[MPC512x_CLK_CAN_CLK_IN] = mpc512x_clk_fixed(
+ "can_clk_in", freq);
+ } else {
+ freq = get_freq_from_dt("spdif_tx_in");
+ clks[MPC512x_CLK_SPDIF_TX_IN] = mpc512x_clk_fixed(
+ "spdif_tx_in", freq);
+ freq = get_freq_from_dt("spdif_rx_in");
+ clks[MPC512x_CLK_SPDIF_TX_IN] = mpc512x_clk_fixed(
+ "spdif_rx_in", freq);
+ }
/* fixed frequency for AC97, always 24.567MHz */
clks[MPC512x_CLK_AC97] = mpc512x_clk_fixed("ac97", 24567000);
@@ -884,6 +1118,20 @@ static void mpc5121_clk_provide_backwards_compat(void)
NODE_PREP;
NODE_CHK("per", clks[MPC512x_CLK_FEC], 0, FEC);
}
+ /*
+ * MPC5125 has two FECs: FEC1 at 0x2800, FEC2 at 0x4800;
+ * the clock items don't "form an array" since FEC2 was
+ * added only later and was not allowed to shift all other
+ * clock item indices, so the numbers aren't adjacent
+ */
+ FOR_NODES("fsl,mpc5125-fec") {
+ NODE_PREP;
+ if (res.start & 0x4000)
+ idx = MPC512x_CLK_FEC2;
+ else
+ idx = MPC512x_CLK_FEC;
+ NODE_CHK("per", clks[idx], 0, FEC);
+ }
FOR_NODES("fsl,mpc5121-usb2-dr") {
NODE_PREP;
@@ -933,6 +1181,9 @@ int __init mpc5121_clk_init(void)
clkregs = of_iomap(clk_np, 0);
WARN_ON(!clkregs);
+ /* determine the SoC variant we run on */
+ mpc512x_clk_determine_soc();
+
/* invalidate all not yet registered clock slots */
mpc512x_clk_preset_data();
diff --git a/include/dt-bindings/clock/mpc512x-clock.h b/include/dt-bindings/clock/mpc512x-clock.h
index 9e81b3b99a32..4f94919327ce 100644
--- a/include/dt-bindings/clock/mpc512x-clock.h
+++ b/include/dt-bindings/clock/mpc512x-clock.h
@@ -63,7 +63,14 @@
#define MPC512x_CLK_PSC9 55
#define MPC512x_CLK_PSC10 56
#define MPC512x_CLK_PSC11 57
+#define MPC512x_CLK_SDHC2 58
+#define MPC512x_CLK_FEC2 59
+#define MPC512x_CLK_OUT0_CLK 60
+#define MPC512x_CLK_OUT1_CLK 61
+#define MPC512x_CLK_OUT2_CLK 62
+#define MPC512x_CLK_OUT3_CLK 63
+#define MPC512x_CLK_CAN_CLK_IN 64
-#define MPC512x_CLK_LAST_PUBLIC 57
+#define MPC512x_CLK_LAST_PUBLIC 64
#endif
--
1.7.10.4
^ permalink raw reply related
* [PATCH v1 0/4] powerpc/512x: update COMMON_CLK support for MPC5125
From: Gerhard Sittig @ 2013-12-10 13:11 UTC (permalink / raw)
To: linuxppc-dev, linux-arm-kernel, Anatolij Gustschin,
Mike Turquette, Matteo Facchinetti
Cc: Scott Wood, Gerhard Sittig, Detlev Zundel
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
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[] = {
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[] = {
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=y 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
^ permalink raw reply
* [PATCH v1 1/4] powerpc/512x: clk: minor comment updates
From: Gerhard Sittig @ 2013-12-10 13:11 UTC (permalink / raw)
To: linuxppc-dev, linux-arm-kernel, Anatolij Gustschin,
Mike Turquette, Matteo Facchinetti
Cc: Scott Wood, Gerhard Sittig, Detlev Zundel
In-Reply-To: <1386681097-14126-1-git-send-email-gsi@denx.de>
adjust (expand on or move) a few comments,
add markers for easier navigation around helpers
Signed-off-by: Gerhard Sittig <gsi@denx.de>
---
arch/powerpc/platforms/512x/clock-commonclk.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/512x/clock-commonclk.c b/arch/powerpc/platforms/512x/clock-commonclk.c
index 189be4a4cb42..079eb1137260 100644
--- a/arch/powerpc/platforms/512x/clock-commonclk.c
+++ b/arch/powerpc/platforms/512x/clock-commonclk.c
@@ -76,6 +76,8 @@ static struct clk_onecell_data clk_data;
static struct mpc512x_ccm __iomem *clkregs;
static DEFINE_SPINLOCK(clklock);
+/* common clk API wrappers {{{ */
+
/* convenience wrappers around the common clk API */
static inline struct clk *mpc512x_clk_fixed(const char *name, int rate)
{
@@ -139,6 +141,8 @@ static inline struct clk *mpc512x_clk_muxed(const char *name,
reg, pos, len, muxflags, &clklock);
}
+/* }}} common clk API wrappers */
+
/* helper to isolate a bit field from a register */
static inline int get_bit_field(uint32_t __iomem *reg, uint8_t pos, uint8_t len)
{
@@ -308,6 +312,8 @@ static void mpc512x_clk_setup_ref_clock(struct device_node *np, int bus_freq,
}
}
+/* MCLK helpers {{{ */
+
/*
* helper code for the MCLK subtree setup
*
@@ -338,8 +344,8 @@ static void mpc512x_clk_setup_ref_clock(struct device_node *np, int bus_freq,
/*
* note that this declaration raises a checkpatch warning, but
- * it's the very data type which <linux/clk-provider.h> expects,
- * making this declaration pass checkpatch will break compilation
+ * it's the very data type dictated by <linux/clk-provider.h>,
+ * "fixing" this warning will break compilation
*/
static const char *parent_names_mux0[] = {
"sys", "ref", "psc-mclk-in", "spdif-tx",
@@ -512,6 +518,8 @@ static void mpc512x_clk_setup_mclk(struct mclk_setup_data *entry, size_t idx)
}
}
+/* }}} MCLK helpers */
+
static void mpc512x_clk_setup_clock_tree(struct device_node *np, int busfreq)
{
int sys_mul, sys_div, ips_div;
@@ -549,8 +557,8 @@ static void mpc512x_clk_setup_clock_tree(struct device_node *np, int busfreq)
clks[MPC512x_CLK_IPS] = mpc512x_clk_divtable("ips", "csb",
&clkregs->scfr1, 23, 3,
divtab_2346);
-
/* now setup anything below SYS and CSB and IPS */
+
clks[MPC512x_CLK_DDR_UG] = mpc512x_clk_factor("ddr-ug", "sys", 1, 2);
clks[MPC512x_CLK_SDHC_x4] = mpc512x_clk_factor("sdhc-x4", "csb", 4, 1);
clks[MPC512x_CLK_SDHC_UG] = mpc512x_clk_divider("sdhc-ug", "sdhc-x4", 0,
--
1.7.10.4
^ permalink raw reply related
* [PATCH] KVM: PPC: Use schedule instead of cond_resched
From: Aneesh Kumar K.V @ 2013-12-10 14:21 UTC (permalink / raw)
To: agraf, benh, paulus; +Cc: linuxppc-dev, kvm, kvm-ppc, Aneesh Kumar K.V
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
We already checked need_resched. So we can call schedule directly
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
NOTE: This patch also work around a regression upstream w.r.t PR KVM
BUG: soft lockup - CPU#0 stuck for 23s! [qemu-system-ppc:4394]
Modules linked in:
CPU: 0 PID: 4394 Comm: qemu-system-ppc Not tainted 3.13.0-rc3+ #98
task: c0000001d0788400 ti: c0000001dca00000 task.ti: c0000001dca00000
NIP: c00000000082dd80 LR: c000000000081ae0 CTR: c000000000062ba0
REGS: c0000001dca02f70 TRAP: 0901 Not tainted (3.13.0-rc3+)
MSR: 8000000000009032 <SF,EE,ME,IR,DR,RI> CR: 24822024 XER: 00000000
CFAR: c000000000081adc SOFTE: 1
GPR00: c000000000081ae0 c0000001dca031f0 c000000000d67ab0 0000000000000001
GPR04: 0000000071000002 0000000000000001 00000189a0d786b7 00000000018c0000
GPR08: 0000000000000001 0000000000000000 0000000000000000 c000000000da0000
GPR12: 0000000000000c00 c00000000fef0000
NIP [c00000000082dd80] ._cond_resched+0x0/0x40
LR [c000000000081ae0] .kvmppc_prepare_to_enter+0x2a0/0x2e0
Call Trace:
[c0000001dca031f0] [c000000000081ae0] .kvmppc_prepare_to_enter+0x2a0/0x2e0 (unreliable)
[c0000001dca03290] [c00000000008f2cc] .kvmppc_handle_exit_pr+0xec/0xa40
[c0000001dca03340] [c0000000000918c4] kvm_start_lightweight+0xac/0xbc
[c0000001dca03510] [c00000000008efe0] .kvmppc_vcpu_run_pr+0x130/0x2a0
[c0000001dca039e0] [c0000000000855bc] .kvmppc_vcpu_run+0x2c/0x40
[c0000001dca03a50] [c000000000082c94] .kvm_arch_vcpu_ioctl_run+0x54/0x1b0
[c0000001dca03ae0] [c00000000007d5f8] .kvm_vcpu_ioctl+0x478/0x740
[c0000001dca03ca0] [c000000000218864] .do_vfs_ioctl+0x4a4/0x760
[c0000001dca03d80] [c000000000218b78] .SyS_ioctl+0x58/0xb0
[c0000001dca03e30] [c000000000009e58] syscall_exit+0x0/0x98
Instruction dump:
e92d0260 e94911c0 812a0004 5529f07e 5529103e 912a0004 38210080 e8010010
ebc1fff0 ebe1fff8 7c0803a6 4e800020 <7c0802a6> 38600000 f8010010 f821ff91
arch/powerpc/kvm/powerpc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index e4d511c8b38b..6a49b23a3276 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -74,7 +74,7 @@ int kvmppc_prepare_to_enter(struct kvm_vcpu *vcpu)
while (true) {
if (need_resched()) {
local_irq_enable();
- cond_resched();
+ schedule();
local_irq_disable();
continue;
}
--
1.8.3.2
^ permalink raw reply related
* [PATCH v2] powerpc 8xx: Loading kernels over 8Mbytes without CONFIG_PIN_TLB
From: Christophe Leroy @ 2013-12-10 11:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, scottwood
Cc: linuxppc-dev, linux-kernel
Today, the only way to load kernels whose size is greater than 8Mbytes is to
activate CONFIG_PIN_TLB. Otherwise, the physical memory initially mapped is
limited to 8Mbytes. This patch adds the capability to select the size of initial
memory between 8/16/24 Mbytes and this is regardless of whether CONFIG_PIN_TLB
is active or not. It allows to load "big" kernels (for instance when activating
CONFIG_LOCKDEP_SUPPORT) without having to activate CONFIG_PIN_TLB.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
diff -ur a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -980,6 +980,29 @@
config PIN_TLB
bool "Pinned Kernel TLBs (860 ONLY)"
depends on ADVANCED_OPTIONS && 8xx
+
+choice
+ prompt "Initial Data Memory Mapped on 8xx"
+ default 8xx_MAP_8M
+ depends on ADVANCED_OPTIONS && 8xx
+
+config 8xx_INIT_MAP_8M
+ bool "8 Mbytes"
+
+config 8xx_INIT_MAP_16M
+ bool "16 Mbytes"
+
+config 8xx_INIT_MAP_24M
+ bool "24 Mbytes"
+
+endchoice
+
+config 8xx_INIT_MAP
+ hex
+ default 0x01800000 if 8xx_INIT_MAP_24M
+ default 0x01000000 if 8xx_INIT_MAP_16M
+ default 0x00800000
+
endmenu
if PPC64
diff -ur a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -841,11 +841,13 @@
ori r8, r8, MI_BOOTINIT|0x2 /* Inhibit cache -- Cort */
mtspr SPRN_MD_RPN, r8
-#ifdef CONFIG_PIN_TLB
+#if defined (CONFIG_8xx_INIT_MAP_16M) || defined (CONFIG_8xx_INIT_MAP_24M)
/* Map two more 8M kernel data pages.
*/
+#ifdef CONFIG_PIN_TLB
addi r10, r10, 0x0100
mtspr SPRN_MD_CTR, r10
+#endif
lis r8, KERNELBASE@h /* Create vaddr for TLB */
addis r8, r8, 0x0080 /* Add 8M */
@@ -858,15 +860,19 @@
addis r11, r11, 0x0080 /* Add 8M */
mtspr SPRN_MD_RPN, r11
+#ifdef CONFIG_8xx_INIT_MAP_24M
+#ifdef CONFIG_PIN_TLB
addi r10, r10, 0x0100
mtspr SPRN_MD_CTR, r10
+#endif
addis r8, r8, 0x0080 /* Add 8M */
mtspr SPRN_MD_EPN, r8
mtspr SPRN_MD_TWC, r9
addis r11, r11, 0x0080 /* Add 8M */
mtspr SPRN_MD_RPN, r11
-#endif
+#endif /* CONFIG_8xx_INIT_MAP_24M */
+#endif /* CONFIG_8xx_INIT_MAP_16M || CONFIG_8xx_INIT_MAP_24M */
/* Since the cache is enabled according to the information we
* just loaded into the TLB, invalidate and enable the caches here.
diff -ur a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
--- a/arch/powerpc/mm/init_32.c
+++ b/arch/powerpc/mm/init_32.c
@@ -213,12 +213,8 @@
*/
BUG_ON(first_memblock_base != 0);
-#ifdef CONFIG_PIN_TLB
/* 8xx can only access 24MB at the moment */
- memblock_set_current_limit(min_t(u64, first_memblock_size, 0x01800000));
-#else
- /* 8xx can only access 8MB at the moment */
- memblock_set_current_limit(min_t(u64, first_memblock_size, 0x00800000));
-#endif
+ memblock_set_current_limit(min_t(u64, first_memblock_size,
+ CONFIG_8xx_INIT_MAP));
}
#endif /* CONFIG_8xx */
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Use schedule instead of cond_resched
From: Aneesh Kumar K.V @ 2013-12-10 16:08 UTC (permalink / raw)
To: Alexander Graf
Cc: Paul Mackerras, linuxppc-dev, kvm-ppc,
kvm@vger.kernel.org mailing list
In-Reply-To: <C3F93DB3-202A-427D-A7B6-A868F3743507@suse.de>
Alexander Graf <agraf@suse.de> writes:
> On 10.12.2013, at 15:21, Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> wrote:
>
>> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>>
>> We already checked need_resched. So we can call schedule directly
>>
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>
> The real fix for the issue you're seeing is
>
> https://lkml.org/lkml/2013/11/28/241
True, I mentioned that in the thread
https://lkml.org/lkml/2013/12/9/64
But do we need to do cond_resched after we checked for need_resched() ?
-aneesh
^ permalink raw reply
* Re: [V2 PATCH 3/3] powerpc: Fix Unaligned LE Floating Point Loads and Stores
From: Paul Mackerras @ 2013-12-11 3:54 UTC (permalink / raw)
To: Tom; +Cc: linuxppc-dev
In-Reply-To: <1383244738-5986-4-git-send-email-tommusta@gmail.com>
On Thu, Oct 31, 2013 at 01:38:58PM -0500, Tom wrote:
> From: Tom Musta <tommusta@gmail.com>
>
> This patch addresses unaligned single precision floating point loads
> and stores in the single-step code. The old implementation
> improperly treated an 8 byte structure as an array of two 4 byte
> words, which is a classic little endian bug.
>
> Signed-off-by: Tom Musta <tommusta@gmail.com>
> ---
> arch/powerpc/lib/sstep.c | 52 +++++++++++++++++++++++++++++++++++----------
> 1 files changed, 40 insertions(+), 12 deletions(-)
>
> diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
> index c8743e1..1cfd150 100644
> --- a/arch/powerpc/lib/sstep.c
> +++ b/arch/powerpc/lib/sstep.c
> @@ -355,22 +355,36 @@ static int __kprobes do_fp_load(int rn, int (*func)(int, unsigned long),
> struct pt_regs *regs)
> {
> int err;
> - unsigned long val[sizeof(double) / sizeof(long)];
> + union {
> + double dbl;
> + unsigned long ul[2];
> + struct {
> +#ifdef __BIG_ENDIAN__
> + unsigned _pad_;
> + unsigned word;
> +#endif
> +#ifdef __LITTLE_ENDIAN__
> + unsigned word;
> + unsigned _pad_;
> +#endif
> + } single;
> + } data;
> unsigned long ptr;
>
> if (!address_ok(regs, ea, nb))
> return -EFAULT;
> if ((ea & 3) == 0)
> return (*func)(rn, ea);
> - ptr = (unsigned long) &val[0];
> + ptr = (unsigned long) &data.ul;
> if (sizeof(unsigned long) == 8 || nb == 4) {
> - err = read_mem_unaligned(&val[0], ea, nb, regs);
> - ptr += sizeof(unsigned long) - nb;
> + err = read_mem_unaligned(&data.ul[0], ea, nb, regs);
> + if (nb == 4)
> + ptr = (unsigned long)&(data.single.word);
> } else {
> /* reading a double on 32-bit */
> - err = read_mem_unaligned(&val[0], ea, 4, regs);
> + err = read_mem_unaligned(&data.ul[0], ea, 4, regs);
> if (!err)
> - err = read_mem_unaligned(&val[1], ea + 4, 4, regs);
> + err = read_mem_unaligned(&data.ul[1], ea + 4, 4, regs);
This breaks 32-bit big-endian (as well as making the code longer and
more complex).
In fact, to make this work for 64-bit little-endian, all you really
needed to do was ifdef out the statement:
ptr += sizeof(unsigned long) - nb;
Paul.
^ permalink raw reply
* Re: [V2 PATCH 3/3] powerpc: Fix Unaligned LE Floating Point Loads and Stores
From: Paul Mackerras @ 2013-12-11 4:57 UTC (permalink / raw)
To: Tom; +Cc: linuxppc-dev
In-Reply-To: <20131211035440.GA9399@drongo>
On Wed, Dec 11, 2013 at 02:54:40PM +1100, Paul Mackerras wrote:
> On Thu, Oct 31, 2013 at 01:38:58PM -0500, Tom wrote:
> > From: Tom Musta <tommusta@gmail.com>
> >
> > This patch addresses unaligned single precision floating point loads
> > and stores in the single-step code. The old implementation
> > improperly treated an 8 byte structure as an array of two 4 byte
> > words, which is a classic little endian bug.
> >
> > Signed-off-by: Tom Musta <tommusta@gmail.com>
> > ---
> > arch/powerpc/lib/sstep.c | 52 +++++++++++++++++++++++++++++++++++----------
> > 1 files changed, 40 insertions(+), 12 deletions(-)
> >
> > diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
> > index c8743e1..1cfd150 100644
> > --- a/arch/powerpc/lib/sstep.c
> > +++ b/arch/powerpc/lib/sstep.c
> > @@ -355,22 +355,36 @@ static int __kprobes do_fp_load(int rn, int (*func)(int, unsigned long),
> > struct pt_regs *regs)
> > {
> > int err;
> > - unsigned long val[sizeof(double) / sizeof(long)];
> > + union {
> > + double dbl;
> > + unsigned long ul[2];
> > + struct {
> > +#ifdef __BIG_ENDIAN__
> > + unsigned _pad_;
> > + unsigned word;
> > +#endif
> > +#ifdef __LITTLE_ENDIAN__
> > + unsigned word;
> > + unsigned _pad_;
> > +#endif
> > + } single;
> > + } data;
> > unsigned long ptr;
> >
> > if (!address_ok(regs, ea, nb))
> > return -EFAULT;
> > if ((ea & 3) == 0)
> > return (*func)(rn, ea);
> > - ptr = (unsigned long) &val[0];
> > + ptr = (unsigned long) &data.ul;
> > if (sizeof(unsigned long) == 8 || nb == 4) {
> > - err = read_mem_unaligned(&val[0], ea, nb, regs);
> > - ptr += sizeof(unsigned long) - nb;
> > + err = read_mem_unaligned(&data.ul[0], ea, nb, regs);
> > + if (nb == 4)
> > + ptr = (unsigned long)&(data.single.word);
> > } else {
> > /* reading a double on 32-bit */
> > - err = read_mem_unaligned(&val[0], ea, 4, regs);
> > + err = read_mem_unaligned(&data.ul[0], ea, 4, regs);
> > if (!err)
> > - err = read_mem_unaligned(&val[1], ea + 4, 4, regs);
> > + err = read_mem_unaligned(&data.ul[1], ea + 4, 4, regs);
>
> This breaks 32-bit big-endian (as well as making the code longer and
> more complex).
And in fact none of this code will get executed in little-endian mode
anyway, since we still have this in the middle of emulate_step():
/*
* Following cases are for loads and stores, so bail out
* if we're in little-endian mode.
*/
if (regs->msr & MSR_LE)
return 0;
Paul.
^ 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