> > +#define IS_SVR_REV(svr, maj, min) \
> > + ((SVR_MAJ(svr) == (maj)) && (SVR_MIN(svr) == (min)))
>
> I don't think IS_SVR_REV is needed. Callers can just do "if
> (SVR_REV(svr) == 0x30)" or whatever, especially since we're relying on
> them to do this for greater/less than comparisons.
Not
On 07/10/2013 03:32 AM, Alexander Graf wrote:
> On 07/06/2013 05:07 PM, Alexey Kardashevskiy wrote:
>> This adds special support for huge pages (16MB). The reference
>> counting cannot be easily done for such pages in real mode (when
>> MMU is off) so we added a list of huge pages. It is populate
Thanks.
Regards
Haijun.
> -Original Message-
> From: David Laight [mailto:david.lai...@aculab.com]
> Sent: Thursday, July 11, 2013 4:44 PM
> To: Wood Scott-B07421; Zhang Haijun-B42677
> Cc: Zhao Chenhui-B35336; linux-...@vger.kernel.org; Wrobel Heinz-R39252;
> Fleming Andy-AFLEMING; Zh
On Wed, Jul 10, 2013 at 04:40:03PM -0500, Scott Wood wrote:
> On 07/09/2013 08:49:52 PM, Kevin Hao wrote:
> >I got the following error on my t4240qds board.
> > ntpd[2713]: unhandled signal 4 at 0fd5b448 nip 0fd5b448 lr
> >0fd5b424 code 30001
> >
> >The root cause is that the float point instructi
On 11.07.2013, at 10:57, Alexey Kardashevskiy wrote:
> On 07/10/2013 03:32 AM, Alexander Graf wrote:
>> On 07/06/2013 05:07 PM, Alexey Kardashevskiy wrote:
>>> This adds special support for huge pages (16MB). The reference
>>> counting cannot be easily done for such pages in real mode (when
>>>
Add "host-off-card-on" dt property and parse it to support the
quirk SDHCI_QUIRK2_HOST_OFF_CARD_ON.
Signed-off-by: Wei Ni
---
Documentation/devicetree/bindings/mmc/mmc.txt |2 ++
drivers/mmc/host/sdhci-pltfm.c|3 +++
2 files changed, 5 insertions(+)
diff --git a/Document
> > It'd also be nice if we had an option to only include the portions
> > of math-emu that are known to be missing in some CPUs (excluding
> > CPUs that are missing the entire FPU, of course). Besides its
> > effect on kernel image size, in my experience math-emu adds a
> > non-trivial amount of
On 11.07.2013, at 07:12, Alexey Kardashevskiy wrote:
> On 07/10/2013 08:05 PM, Alexander Graf wrote:
>>
>> On 10.07.2013, at 07:00, Alexey Kardashevskiy wrote:
>>
>>> On 07/10/2013 03:02 AM, Alexander Graf wrote:
On 07/06/2013 05:07 PM, Alexey Kardashevskiy wrote:
> This adds real mode
On Thu, Jul 11, 2013 at 11:04:06AM +0100, David Laight wrote:
> > > It'd also be nice if we had an option to only include the portions
> > > of math-emu that are known to be missing in some CPUs (excluding
> > > CPUs that are missing the entire FPU, of course). Besides its
> > > effect on kernel i
On 07/11/2013 08:11 PM, Alexander Graf wrote:
>
> On 11.07.2013, at 07:12, Alexey Kardashevskiy wrote:
>
>> On 07/10/2013 08:05 PM, Alexander Graf wrote:
>>>
>>> On 10.07.2013, at 07:00, Alexey Kardashevskiy wrote:
>>>
On 07/10/2013 03:02 AM, Alexander Graf wrote:
> On 07/06/2013 05:07 P
On Tue, Jul 09, 2013 at 04:05:30PM +0100, Vince Weaver wrote:
> On Tue, 9 Jul 2013, Peter Zijlstra wrote:
>
> > On Mon, Jul 08, 2013 at 10:24:34PM -0400, Vince Weaver wrote:
> > >
> > > So something like they have on ARM?
> > >
> > > vince@pandaboard:/sys/bus/event_source/devices$ ls -l
> > > lr
On 11.07.2013, at 12:54, Alexey Kardashevskiy wrote:
> On 07/11/2013 08:11 PM, Alexander Graf wrote:
>>
>> On 11.07.2013, at 07:12, Alexey Kardashevskiy wrote:
>>
>>> On 07/10/2013 08:05 PM, Alexander Graf wrote:
On 10.07.2013, at 07:00, Alexey Kardashevskiy wrote:
> On 07/
Some cores (such as Freescale BookE) don't implement all floating
point instructions in ISA. But some gcc versions do use these
instructions. So we would have to enable the math emulation in this
case. Add this to emulated instructions tracking statistics so that
the user has a way to know that its
These two patches are for the emulation of the FPU unimplemented instructions.
The first is just a bit optimization for the FPU state flush.
The second is requested by Scott.
Kevin Hao (2):
powerpc/math-emu: move the flush FPU state function into do_mathemu
powerpc/math-emu: keep track of the
By doing this we can make sure that the FPU state is only flushed to
the thread struct when it is really needed.
Signed-off-by: Kevin Hao
---
arch/powerpc/kernel/traps.c | 9 -
arch/powerpc/math-emu/math.c | 9 +
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arc
On Thu, 2013-07-11 at 15:12 +1000, Alexey Kardashevskiy wrote:
> >> Any debug code is prohibited? Ok, I'll remove.
> >
> > Debug code that requires code changes is prohibited, yes.
> > Debug code that is runtime switchable (pr_debug, trace points, etc)
> > are allowed.
Bollox.
$ grep DBG\( arch/
On Thu, 2013-07-11 at 11:52 +0200, Alexander Graf wrote:
> > Where exactly (it is rather SPAPR_TCE_IOMMU but does not really
> matter)?
> > Select it on KVM_BOOK3S_64? CONFIG_KVM_BOOK3S_64_HV?
> > CONFIG_KVM_BOOK3S_64_PR? PPC_BOOK3S_64?
>
> I'd say the most logical choice would be to check the Mak
On Thu, 2013-07-11 at 12:11 +0200, Alexander Graf wrote:
> > So I must add one more ioctl to enable MULTITCE in kernel handling. Is it
> > what you are saying?
> >
> > I can see KVM_CHECK_EXTENSION but I do not see KVM_ENABLE_EXTENSION or
> > anything like that.
>
> KVM_ENABLE_CAP. It's how we en
On Thu, 2013-07-11 at 13:15 +0200, Alexander Graf wrote:
> And that's bad. Jeez, seriously. Don't argue this case. We enable new
> features individually unless we're 100% sure we can keep everything
> working. In this case an ENABLE_CAP doesn't hurt at all, because user
> space still needs to handl
On Thu, 2013-07-11 at 13:15 +0200, Alexander Graf wrote:
> There are 2 ways of dealing with this:
>
> 1) Call the ENABLE_CAP on every vcpu. That way one CPU may handle
> this hypercall in the kernel while another one may not. The same as we
> handle PAPR today.
>
> 2) Create a new ENABLE_CAP
On Thu, 2013-07-11 at 20:21 +0800, Kevin Hao wrote:
> Some cores (such as Freescale BookE) don't implement all floating
> point instructions in ISA. But some gcc versions do use these
> instructions. So we would have to enable the math emulation in this
> case. Add this to emulated instructions tra
On 11.07.2013, at 14:37, Benjamin Herrenschmidt wrote:
> On Thu, 2013-07-11 at 11:52 +0200, Alexander Graf wrote:
>>> Where exactly (it is rather SPAPR_TCE_IOMMU but does not really
>> matter)?
>>> Select it on KVM_BOOK3S_64? CONFIG_KVM_BOOK3S_64_HV?
>>> CONFIG_KVM_BOOK3S_64_PR? PPC_BOOK3S_64?
>>
On 11.07.2013, at 14:39, Benjamin Herrenschmidt wrote:
> On Thu, 2013-07-11 at 13:15 +0200, Alexander Graf wrote:
>> And that's bad. Jeez, seriously. Don't argue this case. We enable new
>> features individually unless we're 100% sure we can keep everything
>> working. In this case an ENABLE_CAP
On 07/11/2013 10:51 PM, Alexander Graf wrote:
>
> On 11.07.2013, at 14:39, Benjamin Herrenschmidt wrote:
>
>> On Thu, 2013-07-11 at 13:15 +0200, Alexander Graf wrote:
>>> And that's bad. Jeez, seriously. Don't argue this case. We enable new
>>> features individually unless we're 100% sure we can
On Thu, 2013-07-11 at 14:50 +0200, Alexander Graf wrote:
> > Not really no. But that would do. You could have give a more useful
> > answer in the first place though rather than stringing him along.
>
> Sorry, I figured it was obvious.
It wasn't no, because of the mess with modules and the nasty
On Thu, 2013-07-11 at 14:51 +0200, Alexander Graf wrote:
> I don't like bloat usually. But Alexey even had an #ifdef DEBUG in
> there to selectively disable in-kernel handling of multi-TCE. Not
> calling ENABLE_CAP would give him exactly that without ugly #ifdefs in
> the kernel.
I don't see much
On 11.07.2013, at 14:33, Benjamin Herrenschmidt wrote:
> On Thu, 2013-07-11 at 15:12 +1000, Alexey Kardashevskiy wrote:
Any debug code is prohibited? Ok, I'll remove.
>>>
>>> Debug code that requires code changes is prohibited, yes.
>>> Debug code that is runtime switchable (pr_debug, trace
On 07/11/2013 10:58 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2013-07-11 at 14:51 +0200, Alexander Graf wrote:
>> I don't like bloat usually. But Alexey even had an #ifdef DEBUG in
>> there to selectively disable in-kernel handling of multi-TCE. Not
>> calling ENABLE_CAP would give him exactly th
On 11.07.2013, at 15:13, Alexey Kardashevskiy wrote:
> On 07/11/2013 10:58 PM, Benjamin Herrenschmidt wrote:
>> On Thu, 2013-07-11 at 14:51 +0200, Alexander Graf wrote:
>>> I don't like bloat usually. But Alexey even had an #ifdef DEBUG in
>>> there to selectively disable in-kernel handling of mu
On 11.07.2013, at 15:41, chandrashekar shastri wrote:
> Hi All,
>
> I complied the latest kernel 3.10.0+ pulled from the git on top of
> 3.10.0-rc5+ by enabling the new Virtualiztaion features. The compliation was
> sucessfull, when I rebooted the machine it fails to boot with error as "
> s
On 07/11/2013 11:41 PM, chandrashekar shastri wrote:
> Hi All,
>
> I complied the latest kernel 3.10.0+ pulled from the git on top of
> 3.10.0-rc5+ by enabling the new Virtualiztaion features. The compliation
> was sucessfull, when I rebooted the machine it fails to boot with error as
> " systemd
On Wed, Jul 10, 2013 at 06:43:54PM +0800, Nicolin Chen wrote:
> The code enabled SSIEN when triggered by SNDRV_PCM_TRIGGER_START,
> so move the disable code to SNDRV_PCM_TRIGGER_STOP for symmetric.
>
> This also allows us to use the SSI driver more flexible so that
> it can support some use cases
On 07/10/2013 10:00:33 PM, tiejun.chen wrote:
On 07/11/2013 03:15 AM, Scott Wood wrote:
On 07/10/2013 01:02:19 AM, Tiejun Chen wrote:
We should ensure the preemption cannot occur while calling
get_paca()
insdide hard_irq_disable(), otherwise the paca_struct may be the
wrong one just after. An
On 07/11/2013 03:43:35 AM, David Laight wrote:
> > +#define IS_SVR_REV(svr, maj, min) \
> > + ((SVR_MAJ(svr) == (maj)) && (SVR_MIN(svr) == (min)))
>
> I don't think IS_SVR_REV is needed. Callers can just do "if
> (SVR_REV(svr) == 0x30)" or whatever, especially since we're relying
on
> the
On 07/11/2013 07:45:21 AM, Benjamin Herrenschmidt wrote:
On Thu, 2013-07-11 at 20:21 +0800, Kevin Hao wrote:
> Some cores (such as Freescale BookE) don't implement all floating
> point instructions in ISA. But some gcc versions do use these
> instructions. So we would have to enable the math emul
On 07/10/2013 08:02:31 PM, Zhang Haijun-B42677 wrote:
> Also make sure that you only do this for quirks that are actually
board-
> specific. In your last patch you had two quirks keyed off of the
board,
> one of which is keyed off of the SoC for other chips.
>
[Haijun Wrote:] Actually there
Hi All,
I complied the latest kernel 3.10.0+ pulled from the git on top of
3.10.0-rc5+ by enabling the new Virtualiztaion features. The compliation
was sucessfull, when I rebooted the machine it fails to boot with error
as " systemd [1] : Failed to mount /dev : no such device.
Is it problem
On 07/11/2013 11:54 AM, Mark Brown wrote:
>> > The code enabled SSIEN when triggered by SNDRV_PCM_TRIGGER_START,
>> > so move the disable code to SNDRV_PCM_TRIGGER_STOP for symmetric.
> Applied, thanks.
Don't you need an ACK from the maintainer of the driver before applying
it? I haven't had a ch
On Wed, Jul 10, 2013 at 06:43:54PM +0800, Nicolin Chen wrote:
> The code enabled SSIEN when triggered by SNDRV_PCM_TRIGGER_START,
> so move the disable code to SNDRV_PCM_TRIGGER_STOP for symmetric.
Applied, thanks.
signature.asc
Description: Digital signature
On Thu, 11 Jul 2013, Will Deacon wrote:
> On Tue, Jul 09, 2013 at 04:05:30PM +0100, Vince Weaver wrote:
> > libpfm4 uses the
> >CPU part : 0xc09
> > line in /proc/cpuinfo on ARM, and that's enough for the processors PAPI
>
> The CPU part you cite is actually A9-specific, so you probably want
On 07/09/2013 09:24:57 PM, Haijun Zhang wrote:
+ nand@1,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,p1020-fcm-nand",
+"fsl,elbc-fcm-nand";
+
On Wed, Jul 10, 2013 at 2:40 PM, Benjamin Herrenschmidt
wrote:
> Did you get any traces that show the flow that happens around a case of
> corruption ?
Well, I captured a lot of data, both logging kernel output and
capturing PCI traffic. I've put the full console log output on
pastebin at http:/
Hi Tony/Greg/Liu,
I'am Ravi working on a P2040 based custom board which has a compact flash
connected to USB port via CYPRESS USB to IDE bridge. I am able to see the USB
mass storage device from uboot but when I boot to kernel it hangs.
Below is the dump that shows the part where it hangs. I
Hi,
I'm running 2.6.34 with kexec 2.0.1 on a Freescale p5020-based system with 8GB
of memory. (It's an embedded system and I can't do much about the fact that
it's using older software.)
I booted the original kernel with "crashkernel=224M@32M" in the boot args. I
then loaded the crash kernel
On 07/11/2013 02:55 PM, Chris Friesen wrote:
Hi,
I'm running 2.6.34 with kexec 2.0.1 on a Freescale p5020-based system
with 8GB of memory. (It's an embedded system and I can't do much
about the fact that it's using older software.)
I should probably clarify this...I may be able to update kexe
I am out of the office until 15/07/2013.
Note: This is an automated response to your message "Linuxppc-dev Digest,
Vol 107, Issue 89" sent on 11/07/2013 18:17:55.
This is the only notification you will receive while this person is away.
___
Linuxp
Ben,
Why do I have 21 patches from you marked for -stable trees in the
3.11-rc1 merge window, like the one quoted below? All of these look
serious enough that they should have gone into the 3.10-rc releases,
especially as the date of when they were submitted gave you plenty of
time to get them me
On 07/11/2013 03:22 PM, Chris Friesen wrote:
On 07/11/2013 02:55 PM, Chris Friesen wrote:
Hi,
I'm running 2.6.34 with kexec 2.0.1 on a Freescale p5020-based system
with 8GB of memory. (It's an embedded system and I can't do much
about the fact that it's using older software.)
I should probabl
Overview of P1020RDB-PD device:
- DDR3 2GB
- NOR flash 64MB
- NAND flash 128MB
- SPI flash 16MB
- I2C EEPROM 256Kb
- eTSEC1 (RGMII PHY) connected to VSC7385 L2 switch
- eTSEC2 (SGMII PHY)
- eTSEC3 (RGMII PHY)
- SDHC
- 1 USB ports
- TDM ports
- PCIe
Signed-off-by: Haijun Zhang
Signed-off-by: Jerry
On Thu, Jul 11, 2013 at 03:22:49PM -0600, Chris Friesen wrote:
> On 07/11/2013 02:55 PM, Chris Friesen wrote:
> >Hi,
> >
> >I'm running 2.6.34 with kexec 2.0.1 on a Freescale p5020-based system
> >with 8GB of memory. (It's an embedded system and I can't do much
> >about the fact that it's using ol
On Thu, Jul 11, 2013 at 10:45:21PM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2013-07-11 at 20:21 +0800, Kevin Hao wrote:
> > Some cores (such as Freescale BookE) don't implement all floating
> > point instructions in ISA. But some gcc versions do use these
> > instructions. So we would have to
On Thu, Jul 11, 2013 at 09:30:02AM -0500, Scott Wood wrote:
> On 07/11/2013 07:45:21 AM, Benjamin Herrenschmidt wrote:
> >On Thu, 2013-07-11 at 20:21 +0800, Kevin Hao wrote:
> >> Some cores (such as Freescale BookE) don't implement all floating
> >> point instructions in ISA. But some gcc versions
On Fri, 2013-07-12 at 10:07 +0800, Kevin Hao wrote:
> There are two invocations of do_mathemu() in the traps.c. The one in the
> function program_check_exception() doesn't call the PPC_WARN_EMULATED.
> This is also the one I try to fix. Of course my patch will definitely corrupt
> the one in functi
Hi Timur,
On Thu, Jul 11, 2013 at 12:14:56PM -0500, ti...@tabi.org wrote:
> Don't you need an ACK from the maintainer of the driver before applying
> it? I haven't had a chance to test it yet.
If I'm not missing some part of branch updating, it looks like Mark hasn't
pushed it to the branch yet.
Nicolin Chen wrote:
Hi Timur,
On Thu, Jul 11, 2013 at 12:14:56PM -0500, ti...@tabi.org wrote:
Don't you need an ACK from the maintainer of the driver before applying
it? I haven't had a chance to test it yet.
If I'm not missing some part of branch updating, it looks like Mark hasn't
pushed it
> -Original Message-
> From: Wood Scott-B07421
> Sent: Thursday, July 11, 2013 5:43 AM
> To: Wang Dongsheng-B40534
> Cc: Wang Dongsheng-B40534; b...@kernel.crashing.org; Wood Scott-B07421;
> johan...@sipsolutions.net; an...@enomsg.org; ga...@kernel.crashing.org;
> linuxppc-dev@lists.ozlab
On Thu, Jul 11, 2013 at 11:00:15PM -0500, Timur Tabi wrote:
> I definitely want to. Unfortunately, I'm literally in the middle of
> moving into a new house, and so everything is packed up. I won't be
> able to look at it for another week.
Oh, I see. Actually we've been using this patch for quite
Nicolin Chen wrote:
Oh, I see. Actually we've been using this patch for quite a while,
it should be okay.
Have you tested it on PowerPC?
--
Timur Tabi
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linux
On Thu, Jul 11, 2013 at 11:13:32PM -0500, Timur Tabi wrote:
> Have you tested it on PowerPC?
Not actually. But I think it won't break the work flow since
the SSI modules on two platform should be literally identical.
But if you still have concern with it, you can ask Mark to wait
and test it late
On Fri, Jul 12, 2013 at 01:56:03PM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2013-07-12 at 10:07 +0800, Kevin Hao wrote:
> > There are two invocations of do_mathemu() in the traps.c. The one in the
> > function program_check_exception() doesn't call the PPC_WARN_EMULATED.
> > This is also the
On 07/10/2013 12:48 AM, Scott Wood wrote:
On 07/05/2013 01:27:05 AM, hongbo.zh...@freescale.com wrote:
From: Hongbo Zhang
Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this
patch add
the device tree nodes for them.
Signed-off-by: Hongbo Zhang
---
arch/powerpc/boot/dts/fsl
By doing this we can make sure that the FPU state is only flushed to
the thread struct when it is really needed.
Signed-off-by: Kevin Hao
---
v2: No change.
arch/powerpc/kernel/traps.c | 9 -
arch/powerpc/math-emu/math.c | 9 +
2 files changed, 9 insertions(+), 9 deletions(-)
v2:
Tweak the patch 2 as suggested by Benjamin and Scott.
v1:
These two patches are for the emulation of the FPU unimplemented instructions.
The first is just a bit optimization for the FPU state flush.
The second is requested by Scott.
Kevin Hao (2):
powerpc/math-emu: move the flush FPU state
There are two invocations of do_mathemu() in traps.c. And the codes
in these two places are almost the same. Introduce a locale function
to eliminate the duplication. With this change we can also make sure
that in program_check_exception() the PPC_WARN_EMULATED is invoked for
the correctly emulated
From: Wang Dongsheng
Update the 64-bit hibernation code to support Book E CPUs.
Some registers and instructions are not defined for Book3e
(SDR reg, tlbia instruction).
SDR: Storage Description Register. Book3S and Book3E have different
address translation mode, we do not need HTABORG & HTABSIZE
65 matches
Mail list logo
