On Tue, Jul 28, 2009 at 6:50 AM, Albrecht Dreà wrote:
> Hi all,
>
> I run linux 2.6.29.1 from kernel.org on a custom Freescale MPC5200B based
> board, which has a CF card attached to the 5200's ATA. Â The CF seems to run
> nicely, but I am somewhat confused by the interrupts reproted by the kern
On Fri, Jul 17, 2009 at 6:39 AM, Wolfram Sang wrote:
> Use physmap_of to access RAMs as mtd and add documenation for it. This
> approach
> is a lot less intrusive as adding an of-wrapper around plat-ram.c. As most
> extensions of plat-ram.c (e.g. custom map-functions) can't be mapped to the
> devi
Enabling extended addressing in the h/w requires we always assign the
extended address component (eptr) of the talitos h/w pointer. This is
for e500 based platforms with large memories.
Signed-off-by: Kim Phillips
---
drivers/crypto/talitos.c | 69 ++---
align channel access locks onto separate cache lines (for performance
reasons). This is done by placing per-channel variables into their own
private struct, and using the cacheline_aligned attribute within that
struct.
Signed-off-by: Kim Phillips
---
drivers/crypto/talitos.c | 141
don't do request->src vs. assoc pointer math - it's the same as adding
assoclen and ivsize (just with more effort).
Signed-off-by: Kim Phillips
---
drivers/crypto/talitos.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/t
On Fri, 2009-08-07 at 17:48 +0200, Geert Uytterhoeven wrote:
> | Allocating 0x85e784 bytes for kernel ...
> | platform_ops.vmlinux_alloc = 0x
> | _end = 0x792000
> | The final kernel image would overwrite the device tree?
>
> and it reboots.
>
> However, nm says _end = c085f000.
>
> So i
Anton Vorontsov wrote:
> eSDHC fails to recognize some SDHS cards, throwing timeout errors:
>
> mmc0: error -110 whilst initialising SD card
>
> That's because we calculate timeout value in a wrong way: on eSDHC
> hosts the timeout clock is derivied from the SD clock, which is set
> dynamically
This patch simply adds sdhci node to the device tree.
We specify clock-frequency manually, so that eSDHC will work without
upgrading U-Boot. Though, that'll only work for default setup (1500
MHz) on new board revisions. For non-default setups, it's recommended
to upgrade U-Boot, since it will fixu
- Get rid of incomprehensible "if { for { if } }" construction for the
exponential divisor calculation. The first if statement isn't correct
at all, since it should check for "host->max_clk / pre_div / 16 >
clock". The error doesn't cause any bugs because the check in the for
loop does the
MPC85xx SOCs have normal write-protect state reporting, so we shouldn't
hard-code the quirk.
Instead, look for "sdhci,wp-inverted" property, plus check for
mpc837x_{rdb,mds} machines since older device trees don't specify the
new property.
Signed-off-by: Anton Vorontsov
---
drivers/mmc/host/sdh
eSDHC block in MPC837x SOCs reports inverted write-protect state,
soon sdhci-of driver will look for sdhci,wp-inverted properties to
decide whether apply a specific quirk.
So, document the property and add it to device tree source files.
Signed-off-by: Anton Vorontsov
---
Documentation/powerpc/
eSDHC fails to recognize some SDHS cards, throwing timeout errors:
mmc0: error -110 whilst initialising SD card
That's because we calculate timeout value in a wrong way: on eSDHC
hosts the timeout clock is derivied from the SD clock, which is set
dynamically.
As David Vrabel suggested, derivin
SDHCI core tries to write HISPD bit into the host control register,
but the eSDHC controllers don't have that bit, and that causes
all sorts of misbehaviour when using 4-bit mode capable SD cards.
Signed-off-by: Anton Vorontsov
---
drivers/mmc/host/sdhci-of.c |6 ++
1 files changed, 6 in
Linear divisor's values in a register start at 0 (zero means
"divide by 1"). Before this patch the code didn't account that
fact, so SD cards were running underclocked.
Signed-off-by: Anton Vorontsov
---
drivers/mmc/host/sdhci-of.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff
In v2:
- Addressed David Vrabel's comments;
- New patches added:
powerpc: Introduce and document sdhci,wp-inverted property for eSDHC
sdhci-of: Don't hard-code inverted write-protect quirk
powerpc/85xx: Add eSDHC support for MPC8536DS boards
___
Li
On Fri, Aug 07, 2009 at 02:53:52PM +0200, Kenneth Johansson wrote:
> on 5121 there is a e300 core that unfortunately is connected to the rest
> of the SOC with a bus that do not support coherency.
>
> solution for many driver has been to use uncached memory. But for the
> framebuffer that is not g
On Fri, Aug 07, 2009 at 05:47:00PM +0900, HongWoo Lee wrote:
> #2: Is b similar to the jmp in x86 ?
Yes, specifically a relative near jmp.
> and bl is similar to the call in x86 ?
Sort of (and again, specifically a relative near call). Call on x86
pushes the return address on the stack, while
Use clock freqency from the device tree to calculate correct MPC5200 PSC clock.
Previous code had errors or used a constant. This versions computes
the right clock based on the xtal and register settings.
Signed-off-by: Jon Smirl
---
arch/powerpc/include/asm/mpc52xx.h |2 +-
arch/p
On Fri, Aug 7, 2009 at 12:41 PM, Jon Smirl wrote:
> Use clock freqency from the device tree to calculate correct MPC5200 PSC
> clock.
> Previous code had errors or used a constant. This versions computes
> the right clock based on the xtal and register settings.
Looks good to me; one comment belo
On Fri, Aug 07, 2009 at 06:08:59PM +0100, David Vrabel wrote:
> Anton Vorontsov wrote:
> > eSDHC fails to recognize some SDHS cards, throwing timeout errors:
> >
> > mmc0: error -110 whilst initialising SD card
> >
> > That's because we calculate timeout value in a wrong way: on eSDHC
> > hosts
Use clock freqency from the device tree to calculate correct MPC5200 PSC clock.
Previous code had errors or used a constant. This versions computes
the right clock based on the xtal and register settings.
---
arch/powerpc/include/asm/mpc52xx.h |2 +-
arch/powerpc/platforms/52xx/mpc52
On Fri, Aug 07, 2009 at 08:39:40PM +0400, Anton Vorontsov wrote:
> Hi all,
>
> Finally I've got a bunch of SD cards to test eSDHC in various ways,
> and more importantly now I have a lot of SDHS cards. ;-)
>
> So, here are few fixes that make eSDHC work flawlessly on MPC83xx
> SOCs with all SD an
On Fri, Aug 7, 2009 at 10:34 AM, Jon Smirl wrote:
> On Fri, Aug 7, 2009 at 12:15 PM, Grant Likely
> wrote:
>>> Should I modify mpc52xx_set_psc_clkdiv() to take in a frequency and
>>> them move this code into mpc52xx_common.c? That allows the sysclk
>>> parameter to be eliminated for SPI.
>>
>> Yes
- Get rid of incomprehensible "if { for { if } }" construction for the
exponential divisor calculation. The first if statement isn't correct
at all, since it should check for "host->max_clk / pre_div / 16 >
clock". The error doesn't cause any bugs because the check in the for
loop does the
eSDHC fails to recognize some SDHS cards, throwing timeout errors:
mmc0: error -110 whilst initialising SD card
That's because we calculate timeout value in a wrong way: on eSDHC
hosts the timeout clock is derivied from the SD clock, which is set
dynamically.
This patch fixes the issue by intr
SDHCI core tries to write HISPD bit into the host control register,
but the eSDHC controllers don't have that bit, and that causes
all sorts of misbehaviour when using 4-bit mode capable SD cards.
Signed-off-by: Anton Vorontsov
---
drivers/mmc/host/sdhci-of.c |6 ++
1 files changed, 6 in
Linear divisor's values in a register start at 0 (zero means
"divide by 1"). Before this patch the code didn't account that
fact, so SD cards were running underclocked.
Signed-off-by: Anton Vorontsov
---
drivers/mmc/host/sdhci-of.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff
On Fri, Aug 7, 2009 at 12:15 PM, Grant Likely wrote:
>> Should I modify mpc52xx_set_psc_clkdiv() to take in a frequency and
>> them move this code into mpc52xx_common.c? That allows the sysclk
>> parameter to be eliminated for SPI.
>
> Yes, please do.
Can mpc5xxx_clocks.c be eliminated and this fu
Hi all,
Finally I've got a bunch of SD cards to test eSDHC in various ways,
and more importantly now I have a lot of SDHS cards. ;-)
So, here are few fixes that make eSDHC work flawlessly on MPC83xx
SOCs with all SD and MMC cards that I have.
On MPC85xx (namely MPC8536 and MPC8569) SOCs there is
On Fri, Aug 7, 2009 at 10:03 AM, Jon Smirl wrote:
> mpc52xx_set_psc_clkdiv() has problems. It take the clk divider as a
> parameter. But this divisor is not always gettting calculated
> correctly. My code in i2s was doing it wrong.
>
> Take this snippet from the SPI driver, it just assumes a fsyste
mpc52xx_set_psc_clkdiv() has problems. It take the clk divider as a
parameter. But this divisor is not always gettting calculated
correctly. My code in i2s was doing it wrong.
Take this snippet from the SPI driver, it just assumes a fsystem of
512Mhz. fsystem is 533Mhz on my boards.
/* de
On Tue, 28 Jul 2009, Geert Uytterhoeven wrote:
> Current kernel (2.6.31-rc4) fails to boot on sequoia:
>
> | ## Booting image at 0010 ...
> |Image Name: Linux-2.6.31-rc4-3-g52c6890-
> |Image Type: PowerPC Linux Kernel Image (gzip compressed)
> |Data Size:1680490 Bytes =
Adds P2020RDB basic support in linux.
Overview of P2020RDB platform
- DDR
DDR2 1G
- NOR Flash
16MByte
- NAND Flash
32MByte
- 3 Ethernet interfaces
1) etSEC1
- RGMII
- connected to a 5 port Vitess
Hi Stefan,
> I'm having trouble with my Ethernet device on a TQM5200 based board with
> LXT971 Phy. I'm running U-Boot 2009.03 and a Kernel 2.6.30.
>
> When doing a ping under U-Boot before booting into Linux, Ethernet works
> fine in Linux also. Dmesg reads:
> [ 262.369444] net eth0: Using PHY a
On Fri, Aug 07, 2009 at 08:05:49PM +0530, M. Mohan Kumar wrote:
> Hi,
>
> After enabling EARLY_DEBUG (and DEBUG in some of the files in
> arch/powerpc/kernel directory), without forcing the dtstruct variable to 8
> byte alignment:
>
> # ./kexec -e
> Starting new kernel
> console [udbg0] enabled
Hi,
After enabling EARLY_DEBUG (and DEBUG in some of the files in
arch/powerpc/kernel directory), without forcing the dtstruct variable to 8
byte alignment:
# ./kexec -e
Starting new kernel
console [udbg0] enabled
-> early_setup(), dt_ptr: 0x7723000
-> early_init_devtree(c7723000)
Inva
> -Original Message-
> From: Felix Radensky [mailto:fe...@embedded-sol.com]
> Sent: Friday, August 07, 2009 4:42 PM
> To: Aggrwal Poonam-B10812
> Cc: linuxppc-...@ozlabs.org
> Subject: Re: [PATCH][v2][powerpc/85xx] P2020RDB Platform Support Added
>
> Hi, Poonam
>
> See some more comme
on 5121 there is a e300 core that unfortunately is connected to the rest
of the SOC with a bus that do not support coherency.
solution for many driver has been to use uncached memory. But for the
framebuffer that is not going to work as the performance impact of doing
graphics operations on uncach
Hi, Poonam
See some more comments below.
Poonam Aggrwal wrote:
Adds P2020RDB basic support in linux.
Overview of P2020RDB platform
- DDR
DDR2 1G
- NOR Flash
16MByte
- NAND Flash
32MByte
- 3 Ethernet interfaces
1) etSEC1
Hi all,
I am trying to boot linux kernel (2.6.30) on a custom built board.I am using
simple ppc platform and attached are my dts file and boot log..
I've 26Mb of RAM,UART and UIC with powerpc 440x5 processor.Kernel Image size is
less than 1 mb.
cgc,skybeam board is added in arch/powerpc/platfor
On Fri, Aug 07, 2009 at 12:56:54PM +0200, Lutz Jaenicke wrote:
> On Fri, Aug 07, 2009 at 04:08:50PM +0800, Liu Dave-R63238 wrote:
> >
> > > Some discussion with the the freescale rep. lead to the CSB frequency
> > > of the 8313 (166MHz) being significantly lower than that of the 8343.
> > > Is the
On Fri, Aug 07, 2009 at 04:08:50PM +0800, Liu Dave-R63238 wrote:
>
> > Some discussion with the the freescale rep. lead to the CSB frequency
> > of the 8313 (166MHz) being significantly lower than that of the 8343.
> > Is the CSB the critical point here?
>
> I believe the CSB is critical point he
On Fri, 2009-08-07 at 17:47 +0900, HongWoo Lee wrote:
> #1: Is there any special reason to concatenate 0b00 ? Why 0b00 ??
Because instructions have to be aligned on 4 bytes boundaries ?
> #2: Is b similar to the jmp in x86 ? and bl is similar to the call in x86 ?
I'm not totally familiar with
Hi~
I want to know about bl instruction and the difference between branch
instructions.
I found this code segment.
{{{
bl go_to_real
insrdi r18, r19, 32, 0
}}}
And I found the explanation about branch instructions in PowerISA 2.06
document.
{{{
b target_addr (AA=0 LK=0)
ba targ
Adds P2020RDB basic support in linux.
Overview of P2020RDB platform
- DDR
DDR2 1G
- NOR Flash
16MByte
- NAND Flash
32MByte
- 3 Ethernet interfaces
1) etSEC1
- RGMII
- connected to a 5 port Vitess
> Some discussion with the the freescale rep. lead to the CSB frequency
> of the 8313 (166MHz) being significantly lower than that of the 8343.
> Is the CSB the critical point here?
I believe the CSB is critical point here. They are right.
> Note: the IXP42x uses an internal bus speed of 133MHz
> > On Aug 6, 2009, at 1:00 PM, Lutz Jaenicke wrote:
> >> With the mpc8...@400mhz I get a throughput of approx.
> 24500 frames/s
> >> using the predefined firewall rules.
>
> >> With the MPC8313 I get a significantly lower value:
> >> mpc8...@250mhz 12500fps
> >> mpc8...@333mhz
On Thu, Aug 06, 2009 at 02:16:55PM -0500, Kumar Gala wrote:
>
> On Aug 6, 2009, at 1:00 PM, Lutz Jaenicke wrote:
>> With the mpc8...@400mhz I get a throughput of approx. 24500 frames/s
>> using the predefined firewall rules.
>> With the MPC8313 I get a significantly lower value:
>> mpc8...@250mhz
From: Julia Lawall
Check that the result of kmalloc/kzalloc is not NULL before dereferencing it.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
//
@@
expression *x;
identifier f;
constant char *C;
@@
x = \(kmalloc\|kcalloc\|kzalloc\)(...);
... when != x
Julia Lawall wrote:
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -1057,6 +1057,10 @@ int fsl_rio_setup(struct of_device *dev)
law_start, law_size);
ops = kmalloc(sizeof(struct rio_ops), GFP_KERNEL);
+ if (!ops) {
+ rc
50 matches
Mail list logo
