This patch fixes timeout problems on t4240's sdhci controller:
mmc0: Too large timeout requested for CMD25!
mmc0: Too large timeout requested for CMD25!
mmc0: Too large timeout requested for CMD25!
Signed-off-by: Chunhe Lan
---
drivers/mmc/host/sdhci-pltfm.c |1 +
1
> -Original Message-
> From: David Laight [mailto:david.lai...@aculab.com]
> Sent: Wednesday, March 06, 2013 6:24 PM
> To: Jia Hongtao-B38951; Wood Scott-B07421
> Cc: linuxppc-dev@lists.ozlabs.org; Stuart Yoder
> Subject: RE: [PATCH V4] powerpc/85xx: Add machine check handler to fix
> PCI
Hi Joerg,
I have to post the next version of my patchset, should I base it on top of
3.9-rc1?
By when would you move the iommu git tree to 3.9-rc1?
Regards
Varun
> -Original Message-
> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> Sent: Thursday, February 28, 2013 9:15 PM
> To: S
Hello Mikey,
On Thu, Mar 07, 2013 at 10:14:30AM +1100, Michael Neuling wrote:
> Philippe De Muyter wrote:
>
> > On Thu, Mar 07, 2013 at 09:09:48AM +1100, Michael Neuling wrote:
> > > > bisect tells me that since your commit
> > > > 9422de3e953d0e60eb95f5430a9dd803eec1c6d7
> > > > "powerpc: Har
> In my understanding filling the register could warn the executing process
> an error occurred in some cases. But no way to fix the wrong behavior caused
> by the instruction lost. So let's say that filling the register may benefit
> a little.
IIRC the only ppc instructions that should be accessi
Yes, please base your patches on the latest upstream-tag. I will move my
tree to v3.9-rc1 soon, there are some fixes that need to go upstream.
On Thu, Mar 07, 2013 at 09:14:21AM +, Sethi Varun-B16395 wrote:
> Hi Joerg,
> I have to post the next version of my patchset, should I base it on top o
Added dtsi file for Freescale TDM controller.
This controller is available on many Freescale SOCs like MPC8315, P1020, P1010,
P1022 and P1024
Signed-off-by: Sandeep Singh
Signed-off-by: Poonam Aggrwal
---
arch/powerpc/boot/dts/fsl/pq3-tdm1.0-0.dtsi | 42 +++
1 files cha
This controller is available on many Freescale SOCs like MPC8315, P1020, P1010,
P1022 and P1024
Signed-off-by: Sandeep Singh
Signed-off-by: Poonam Aggrwal
---
Documentation/devicetree/bindings/tdm/fsl-tdm.txt | 65 +
1 files changed, 65 insertions(+), 0 deletions(-)
creat
P1010RDB, P1020RDB, P1020MBG-PC, P1022DS, P1020RDB-PC and P1024RDB
In this Patch:
1. TDM node included in .dtsi files.
2. Disabled TDM in 36bit configurations because of limitations
in TDM hardware block, details mentioned below.
Details of 36bit h/w limitaion:
SLIC device is connected on SPI bus on these platforms
Signed-off-by: Sandeep Singh
Signed-off-by: Poonam Aggrwal
---
arch/powerpc/boot/dts/p1010rdb.dtsi| 13 -
arch/powerpc/boot/dts/p1020mbg-pc.dtsi | 19 +++
arch/powerpc/boot/dts/p1020rdb-pc.dtsi | 18 +++
I know I'm probably missing something... but... why are these patches
copied to the ARM list? They appear to be PowerPC patches.
On Thu, Mar 07, 2013 at 04:57:45PM +0530, Sandeep Singh wrote:
> Added dtsi file for Freescale TDM controller.
> This controller is available on many Freescale SOCs lik
On Mar 7, 2013, at 2:05 AM, Chunhe Lan wrote:
> This patch fixes timeout problems on t4240's sdhci controller:
>
> mmc0: Too large timeout requested for CMD25!
> mmc0: Too large timeout requested for CMD25!
> mmc0: Too large timeout requested for CMD25!
>
> Signed-off-by: Chun
On Mar 6, 2013, at 3:16 AM,
wrote:
> From: Tang Yuantian
>
> config FSL_SOC and CPM do not really depend on PPC_CLOCK. So remove it.
> PPC_CLOCK also keeps powerpc archtecture from supporting COMMON_CLK.
>
> Signed-off-by: Tang Yuantian
> ---
> v2: correct the title
>
> arch/powerpc/Kconf
On 03/07/2013 02:06:05 AM, Jia Hongtao-B38951 wrote:
Here is the ideas from Scott:
"
> + if (is_in_pci_mem_space(addr)) {
> + inst = *(unsigned int *)regs->nip;
Be careful about taking a fault here. A simple TLB miss should be
safe
given that we shouldn't be accessing PCIe in the m
On Mar 5, 2013, at 6:15 PM, Scott Wood wrote:
> On 03/05/2013 05:15:57 PM, Kumar Gala wrote:
>> Enable a baseline T4240 SoC to boot. There are several things missing
>> from the device trees for T4240:
>> * Thread support on e6500
>
> Why did threads get removed from the device tree? It's supp
On 03/07/2013 11:09:50 AM, Kumar Gala wrote:
On Mar 5, 2013, at 6:15 PM, Scott Wood wrote:
> On 03/05/2013 05:15:57 PM, Kumar Gala wrote:
>> Enable a baseline T4240 SoC to boot. There are several things
missing
>> from the device trees for T4240:
>> * Thread support on e6500
>
> Why did thr
On Mar 7, 2013, at 11:47 AM, Scott Wood wrote:
> On 03/07/2013 11:09:50 AM, Kumar Gala wrote:
>> On Mar 5, 2013, at 6:15 PM, Scott Wood wrote:
>> > On 03/05/2013 05:15:57 PM, Kumar Gala wrote:
>> >> Enable a baseline T4240 SoC to boot. There are several things missing
>> >> from the device trees
Enable a baseline T4240 SoC to boot. There are several things missing
from the device trees for T4240:
* Proper PAMU topology information
* DPAA related nodes (Qman, Bman, Fman, Rman, DCE)
* Prefetch Manager
* Thermal monitor unit
* Interlaken
Signed-off-by: Roy Zang
Signed-off-by: Minghuan Lia
On 03/03/2013 08:24 PM, Benjamin Herrenschmidt wrote:
On Sun, 2013-03-03 at 20:16 +0100, Phileas Fogg wrote:
Benjamin Herrenschmidt wrote:
Thanks. It looks like a bisection might indeed be the way to go...
Out of curiosity, have you tried without some of your additional drivers ?
Maybe one of
On Thu, 2013-03-07 at 21:08 +0100, Phileas Fogg wrote:
> And the bisect couldn't find the commit which causes hangs on my
> machine.
> All commits which were provided by the bisect were bad.
> And the commit before tha last bad bisect commit was bad too.
> I did bisect several times, and got the sa
On 03/07/2013 09:22 PM, Benjamin Herrenschmidt wrote:
On Thu, 2013-03-07 at 21:08 +0100, Phileas Fogg wrote:
And the bisect couldn't find the commit which causes hangs on my
machine.
All commits which were provided by the bisect were bad.
And the commit before tha last bad bisect commit was bad
There is no Kconfig symbol PPC_WSP_COPRO. The select statement for it is
a nop. Drop it.
Signed-off-by: Paul Bolle
---
A short treatise on the uneventful life of PPC_WSP_COPRO in the mainline
kernel tree
Release v3.0 included commit 76b4eda866c4936af8d696f040abea56bf688e16
("powerpc: Add A2 cpu
Philippe De Muyter wrote:
> Hello Mikey,
>
> On Thu, Mar 07, 2013 at 10:14:30AM +1100, Michael Neuling wrote:
> > Philippe De Muyter wrote:
> >
> > > On Thu, Mar 07, 2013 at 09:09:48AM +1100, Michael Neuling wrote:
> > > > > bisect tells me that since your commit
> > > > > 9422de3e953d0e60eb9
Given a PCI device with multiple functions in a DDW capable slot, the
following situation can be encountered: When the first function sets a
64-bit DMA mask, enable_ddw() will be called and we can fail to properly
configure DDW (the most common reason being the new DMA window's size is
not large en
Michael Neuling wrote:
> Philippe De Muyter wrote:
>
> > Hello Mikey,
> >
> > On Thu, Mar 07, 2013 at 10:14:30AM +1100, Michael Neuling wrote:
> > > Philippe De Muyter wrote:
> > >
> > > > On Thu, Mar 07, 2013 at 09:09:48AM +1100, Michael Neuling wrote:
> > > > > > bisect tells me that since
On 03/08/2013 12:30 AM, Gala Kumar-B11780 wrote:
On Mar 7, 2013, at 2:05 AM, Chunhe Lan wrote:
This patch fixes timeout problems on t4240's sdhci controller:
mmc0: Too large timeout requested for CMD25!
mmc0: Too large timeout requested for CMD25!
mmc0: Too large timeou
> Subject: Re: [PATCH][V2] powerpc: remove the PPC_CLOCK dependency
>
>
> On Mar 6, 2013, at 3:16 AM,
> wrote:
>
> > From: Tang Yuantian
> >
> > config FSL_SOC and CPM do not really depend on PPC_CLOCK. So remove it.
> > PPC_CLOCK also keeps powerpc archtecture from supporting COMMON_CLK.
> >
originally I did not notice src buf len and dest buf len are the same.
so origianlly, it is not a bug issue, it is only for beautify code.
and now, using strcpy is better.
Signed-off-by: Chen Gang
Signed-off-by: Jiri Slaby
---
drivers/tty/hvc/hvcs.c |3 +--
1 files changed, 1 in
On Fri, 2013-03-08 at 11:38 +0800, Chen Gang wrote:
> originally I did not notice src buf len and dest buf len are the same.
> so origianlly, it is not a bug issue, it is only for beautify code.
> and now, using strcpy is better.
Being the same len doesn't mean it's safe to use strcpy ..
于 2013年03月08日 11:46, Benjamin Herrenschmidt 写道:
> strcpy is indeed safe but using strlcpy doesn't hurt does it ?
really it is: using strlcpy doesn't hurt.
the comments and subject of original commit are not quite precision:
it is not for a bug issue (originally I say it is for bug issue)
On Fri, 2013-03-08 at 12:23 +0800, Chen Gang wrote:
> really it is: using strlcpy doesn't hurt.
>
> the comments and subject of original commit are not quite precision:
> it is not for a bug issue (originally I say it is for bug issue)
> it is really for beautify code.
>
> can I sen
于 2013年03月08日 12:33, Benjamin Herrenschmidt 写道:
> On Fri, 2013-03-08 at 12:23 +0800, Chen Gang wrote:
>> > really it is: using strlcpy doesn't hurt.
>> >
>> > the comments and subject of original commit are not quite precision:
>> > it is not for a bug issue (originally I say it is for bug
On Fri, 2013-03-08 at 12:40 +0800, Chen Gang wrote:
> is it correct ?
Yes, the code is fine as it is now.
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
于 2013年03月08日 13:08, Benjamin Herrenschmidt 写道:
> Yes, the code is fine as it is now.
ok, thanks.
--
Chen Gang
Asianux Corporation
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
huh..My VDSO patch was not the culprit..! the issue was with
spin_lock_irqsave calls...! modify the same to
raw_spin_lock_irqsave..problem solved..!
the rtpatch was not applied properly.
--
View this message in context:
http://linuxppc.10917.n7.nabble.com/PREMPT-RT-tp68107p69101.html
Sent fro
Issue was with the USB mass storage i was using.. problem is specific to that
device.
--
View this message in context:
http://linuxppc.10917.n7.nabble.com/Issue-with-USB-Mass-storage-on-P5020-tp67725p69102.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
_
36 matches
Mail list logo