I encountered following issue:
[0.283035] ibmvscsi 3015: couldn't initialize event pool
[5.688822] ibmvscsi: probe of 3015 failed with error -1
which prevents the storage from being recognized, and the machine from
booting.
After some digging, it seems that it is caused by commit
On Tue, 2013-11-19 at 15:04 +1100, Michael Ellerman wrote:
On Fri, Nov 15, 2013 at 03:36:04PM +0800, Li Zhong wrote:
This is seen when CONFIG_SMP is not enabled:
arch/powerpc/platforms/powernv/rng.c: In function 'rng_init_per_cpu':
arch/powerpc/platforms/powernv/rng.c:74: error: implicit
On Fri, Nov 15, 2013 at 8:16 AM, Liu Gang gang@freescale.com wrote:
For MPC8572/MPC8536, the status of GPIOs defined as output
cannot be determined by reading GPDAT register, so the code
use shadow data register instead. But if the input pins are
asserted high, they will always read high
On 19.11.2013, at 07:12, Liu Ping Fan kernelf...@gmail.com wrote:
Since kvmppc_hv_find_lock_hpte() is called from both virtmode and
realmode, so it can trigger the deadlock.
Suppose the following scene:
Two physical cpuM, cpuN, two VM instances A, B, each VM has a group of
vcpus.
If
On 19.11.2013, at 07:12, Liu Ping Fan kernelf...@gmail.com wrote:
In some scene, e.g openstack CI, PR guest can trigger sc 1 frequently,
this patch optimizes the path by directly delivering BOOK3S_INTERRUPT_SYSCALL
to HV guest, so powernv can return to HV guest without heavy exit, i.e,
no
Hello Anatolij, this is our code, used at University, but again it doesn’t work…
How i told, the only information we have about that reg are:
Chip select 4 specification:
Lp_cs4
bus size: 8 bit
bus control: 2 wait state R/W ACK disabled
size allocated: 4 KByte
Our Register 8 bit LP_cs4 (we want
On PPC_8xx, CRC32_SLICEBY4 is more efficient (almost twice) than CRC32_SLICEBY8,
as shown below:
With CRC32_SLICEBY8:
[1.109204] crc32: CRC_LE_BITS = 64, CRC_BE BITS = 64
[1.114401] crc32: self tests passed, processed 225944 bytes in 15118910 nsec
[1.130655] crc32c: CRC_LE_BITS = 64
[
I found the same on MPC8321 long time ago(when 64 bits change went in),
the 32 bits were much faster. I guess the smaller
CPUs cannot handle the cache trashing these big tables impose, I didn't
look into the details though.
So I think this is a good change for 8xx.
Acked-by: Joakim Tjernlund
On Fri, 15 Nov 2013 15:16:29 +0800
Liu Gang gang@freescale.com wrote:
For MPC8572/MPC8536, the status of GPIOs defined as output
cannot be determined by reading GPDAT register, so the code
use shadow data register instead. But if the input pins are
asserted high, they will always read
I don't think we should go littering the Kconfig with defaults for
various bits of hardware -- especially since you've already pointed out
non-8xx hardware that would also want this. Put it in defconfig
instead, unless you can identify very broad classes of machines for
which SLICEBY4 is faster.
Hi Lorenzo,
On Tue, 19 Nov 2013 11:20:24 +0100
neorf3k neor...@gmail.com wrote:
Hello Anatolij, this is our code, used at University, but again it doesn’t
work…
How i told, the only information we have about that reg are:
Chip select 4 specification:
Lp_cs4
bus size: 8 bit
bus
On Mon, 2013-11-18 at 00:06 +0100, Gerhard Sittig wrote:
make the Freescale PCI driver get, prepare and enable the PCI clock
during probe(); the clock gets put upon device shutdown by the devm
approach
clock lookup is non-fatal as not all platforms may provide clock specs
in their device
On Fri, 2013-11-15 at 15:16 +0800, Liu Gang wrote:
For MPC8572/MPC8536, the status of GPIOs defined as output
cannot be determined by reading GPDAT register, so the code
use shadow data register instead. But if the input pins are
asserted high, they will always read high due to the shadow
On 11/19/2013 02:09 AM, Ingo Molnar wrote:
* Jason Baron jba...@akamai.com wrote:
On 11/18/2013 05:30 PM, Andrew Morton wrote:
On Mon, 18 Nov 2013 21:04:36 + (GMT) Jason Baron jba...@akamai.com
wrote:
The panic_timeout value can be set via the command line option 'panic=x',
or via
Scott Wood scottw...@freescale.com wrote on 2013/11/19 19:29:26:
I don't think we should go littering the Kconfig with defaults for
various bits of hardware -- especially since you've already pointed out
non-8xx hardware that would also want this. Put it in defconfig
instead, unless you can
On Wed, 2013-11-20 at 00:39 +0100, Joakim Tjernlund wrote:
Scott Wood scottw...@freescale.com wrote on 2013/11/19 19:29:26:
I don't think we should go littering the Kconfig with defaults for
various bits of hardware -- especially since you've already pointed out
non-8xx hardware that
In commit a489043 Implement arch_get_random_long() based on H_RANDOM I
broke the SMP=n build. We were getting plpar_wrappers.h via spinlock.h
which breaks when SMP=n.
Signed-off-by: Michael Ellerman m...@ellerman.id.au
---
arch/powerpc/platforms/pseries/rng.c | 1 +
1 file changed, 1
Up until now we have only used cpu_to_chip_id() in the topology code,
which is only used on SMP builds. However my recent commit a4da0d5
Implement arch_get_random_long/int() for powernv added a usage when
SMP=n, breaking the build.
Move cpu_to_chip_id() into prom.c so it is available for SMP=n
On Tue, 2013-11-19 at 16:11 +0800, Li Zhong wrote:
I encountered following issue:
[0.283035] ibmvscsi 3015: couldn't initialize event pool
[5.688822] ibmvscsi: probe of 3015 failed with error -1
which prevents the storage from being recognized, and the machine from
booting.
On Wed, 2013-11-20 at 12:28 +1100, Benjamin Herrenschmidt wrote:
On Tue, 2013-11-19 at 16:11 +0800, Li Zhong wrote:
I encountered following issue:
[0.283035] ibmvscsi 3015: couldn't initialize event pool
[5.688822] ibmvscsi: probe of 3015 failed with error -1
which
On Tue, 2013-11-19 at 16:32 +0100, Anatolij Gustschin wrote:
On Fri, 15 Nov 2013 15:16:29 +0800
Liu Gang gang@freescale.com wrote:
For MPC8572/MPC8536, the status of GPIOs defined as output
cannot be determined by reading GPDAT register, so the code
use shadow data register instead.
On Tue, Nov 19, 2013 at 6:39 PM, Alexander Graf ag...@suse.de wrote:
On 19.11.2013, at 07:12, Liu Ping Fan kernelf...@gmail.com wrote:
Since kvmppc_hv_find_lock_hpte() is called from both virtmode and
realmode, so it can trigger the deadlock.
Suppose the following scene:
Two physical
On Tue, 2013-11-19 at 16:51 -0600, Scott Wood wrote:
@@ -71,6 +71,7 @@ static int mpc8572_gpio_get(struct gpio_chip *gc,
unsigned int gpio)
struct mpc8xxx_gpio_chip *mpc8xxx_gc = to_mpc8xxx_gpio_chip(mm);
val = in_be32(mm-regs + GPIO_DAT) ~in_be32(mm-regs + GPIO_DIR);
+
The udelay just doesn't make sense to what you are talking about.
Does SAI really need 10us delay between two register-updating?
No, this is not must be.
We basically use udelay only if the IP hardware actually needs it: some
IP needs time to boot itself up after doing software reset
On Wed, Nov 20, 2013 at 11:37:45AM +0800, Xiubo Li-B47053 wrote:
The udelay just doesn't make sense to what you are talking about.
Does SAI really need 10us delay between two register-updating?
No, this is not must be.
Then you should explain in your comments why you really put it
From: Thomas Petazzoni thomas.petazz...@free-electrons.com
Until now, the MSI architecture-specific functions could be overloaded
using a fairly complex set of #define and compile-time
conditionals. In order to prepare for the introduction of the msi_chip
infrastructure, it is desirable to switch
Zhu Richard-R65037 would like to recall the message, [PATCH 24/34] PCI: use
weak functions for MSI arch-specific functions.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
The udelay just doesn't make sense to what you are talking about.
Does SAI really need 10us delay between two register-updating?
No, this is not must be.
Then you should explain in your comments why you really put it here or
just drop it if it's just a mistake.
The udelay
On Mon, Nov 18, 2013 at 02:58:09PM +0530, Aneesh Kumar K.V wrote:
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Even though we have same value for linux PTE bits and hash PTE pits
bits, not pits :)
use the hash pte bits wen updating hash pte
when, not wen
Signed-off-by: Aneesh
On Mon, Nov 18, 2013 at 02:58:12PM +0530, Aneesh Kumar K.V wrote:
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
We want to make sure we don't use these function when updating a pte
or pmd entry that have a valid hpte entry, because these functions
don't invalidate them. So limit the
On Mon, Nov 18, 2013 at 02:58:13PM +0530, Aneesh Kumar K.V wrote:
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
We steal the _PAGE_COHERENCE bit and use that for indicating NUMA ptes.
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Acked-by: Paul Mackerras
On Mon, Nov 18, 2013 at 02:58:10PM +0530, Aneesh Kumar K.V wrote:
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Set memory coherence always on hash64 config. If
a platform cannot have memory coherence always set they
can infer that from _PAGE_NO_CACHE and _PAGE_WRITETHRU
like in
The VSX MSR bit in the user context indicates if the context contains VSX
state. Currently we set this when the process has touched VSX at any stage.
Unfortunately, if the user has not provided enough space to save the VSX state,
we can't save it but we currently still set the MSR VSX bit.
This
In addition to the external VFIO user API, a VFIO KVM device
has been introduced recently.
sPAPR TCE IOMMU is para-virtualized and the guest does map/unmap
via hypercalls which take a logical bus id (LIOBN) as a target IOMMU
identifier. LIOBNs are made up and linked to IOMMU groups by the user
2013/11/15 Gerhard Sittig g...@denx.de:
As for the not yet addressed feedback: From the top of my head I
can think of the execute comment which contradicts the code
(which suggests that at least one of them is wrong), and the data
type mismatch in the config routine (where code just happens
+ /* TODO: The SAI driver should figure this out for us */
+ switch (channels) {
+ case 2:
+ snd_soc_dai_set_tdm_slot(cpu_dai, 0xfffc, 0xfffc, 2,
0);
+ break;
+ case 1:
+ snd_soc_dai_set_tdm_slot(cpu_dai, 0xfffe, 0xfffe, 1,
0);
I compared the configuration hexdump of my pci controller and pci device
(FPGA) on old kernel(working 2.6.32) and new (3.8.13) and the only
difference was on the controller configuration on the memory base at Type 1
configuration header registers
.
what does it mean and could it be the trigger
37 matches
Mail list logo
