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 for
> > + /* 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, 0xfff
2013/11/15 Gerhard Sittig :
> 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 to
> work
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
spa
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
On Mon, Nov 18, 2013 at 02:58:10PM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V"
>
> 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 lpar. So we dont' really
On Mon, Nov 18, 2013 at 02:58:12PM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V"
>
> 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 check to _PAGE_PRESENT b
On Mon, Nov 18, 2013 at 02:58:13PM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V"
>
> We steal the _PAGE_COHERENCE bit and use that for indicating NUMA ptes.
>
> Signed-off-by: Aneesh Kumar K.V
Acked-by: Paul Mackerras
___
Linuxppc-dev ma
On Mon, Nov 18, 2013 at 02:58:09PM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V"
>
> 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 Kumar K.V
If you fix the
> > > 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
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
From: Thomas Petazzoni
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 all those functions to use
the 'wea
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 rea
> 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 re
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_D
On Tue, Nov 19, 2013 at 6:39 PM, Alexander Graf wrote:
>
> On 19.11.2013, at 07:12, Liu Ping Fan 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 inst
On Tue, 2013-11-19 at 16:32 +0100, Anatolij Gustschin wrote:
> On Fri, 15 Nov 2013 15:16:29 +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 inp
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
> >
> >
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
> boot
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 b
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
---
arch/powerpc/platforms/pseries/rng.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/ar
On Wed, 2013-11-20 at 00:39 +0100, Joakim Tjernlund wrote:
> Scott Wood 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 th
Scott Wood 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 identify very broa
On 11/19/2013 02:09 AM, Ingo Molnar wrote:
>
> * Jason Baron wrote:
>
>> On 11/18/2013 05:30 PM, Andrew Morton wrote:
>>> On Mon, 18 Nov 2013 21:04:36 + (GMT) Jason Baron
>>> wrote:
>>>
The panic_timeout value can be set via the command line option 'panic=x',
or via
/proc/s
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 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 devi
Hi Lorenzo,
On Tue, 19 Nov 2013 11:20:24 +0100
neorf3k 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 control: 2 wait
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.
On Fri, 15 Nov 2013 15:16:29 +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
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 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
[
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 19.11.2013, at 07:12, Liu Ping Fan 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 need to swap TLB,
On 19.11.2013, at 07:12, Liu Ping Fan 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 cpuM, vcp
On Fri, Nov 15, 2013 at 8:16 AM, 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 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:
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
37 matches
Mail list logo
