On Thu, Jul 11, 2013 at 12:42:31AM -0400, Vince Weaver wrote:
On Wed, 10 Jul 2013, Ingo Molnar wrote:
Exactly - PMUs enumerated in /sys should be self-identifying, it's a
hardware topology after all ...
Anytime userspace is forced to look into /proc, or into weird places in
/sys
+#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 only that,
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 populated in
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; Zhang
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 instruction 'fsqrt'
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
MMU is off)
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 w...@nvidia.com
---
Documentation/devicetree/bindings/mmc/mmc.txt |2 ++
drivers/mmc/host/sdhci-pltfm.c|3 +++
2 files changed, 5 insertions(+)
diff
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 time to a
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 handlers for the
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 image size,
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
lrwxrwxrwx 1 root
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/10/2013 03:02 AM,
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
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 haoke...@gmail.com
---
arch/powerpc/kernel/traps.c | 9 -
arch/powerpc/math-emu/math.c | 9 +
2 files changed, 9 insertions(+), 9
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/powerpc/
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 Makefile
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 enable sPAPR
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 handle
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 for
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
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?
I'd say
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 keep
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 points, etc)
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 that
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 multi-TCE.
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
systemd
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 [1] :
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 like
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.
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
them to do
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
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 are
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 chance
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 to
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
b...@kernel.crashing.org 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
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.
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
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.
___
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
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
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
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 older
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 do use
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 function
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
-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.ozlabs.org
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 a
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
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
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 one I
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 hongbo.zh...@freescale.com
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
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 haoke...@gmail.com
---
v2: No change.
arch/powerpc/kernel/traps.c | 9 -
arch/powerpc/math-emu/math.c | 9 +
2 files changed, 9
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
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
From: Wang Dongsheng dongsheng.w...@freescale.com
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
65 matches
Mail list logo
