On Tue, Jun 29, 2010 at 04:13:24PM -0700, David Daney wrote:
> On 06/29/2010 03:41 PM, David Brownell wrote:
> >Good -- MUSB won't be the only one. ;)
> >
> >Could you mention a few Linux-enabled chips which
> >include this controller?
> >
>
> I can. Some members of the Octeon family: arch/mips
Hi Fushen, Hi Mark,
On Tuesday 29 June 2010 23:26:54 Fushen Chen wrote:
> The DWC OTG driver module provides the initialization and cleanup
> entry points for the DWC OTG USB driver.
>
> Signed-off-by: Fushen Chen
> Signed-off-by: Mark Miesfeld
I tried to compare this driver with the version t
Hello.
Fushen Chen wrote:
The DWC OTG driver module provides the initialization and cleanup
entry points for the DWC OTG USB driver.
Signed-off-by: Fushen Chen
Signed-off-by: Mark Miesfeld
[...]
diff --git a/arch/powerpc/boot/dts/kilauea.dts
b/arch/powerpc/boot/dts/kilauea.dts
index 083
On 06/30/2010 12:41 AM, David Brownell wrote:
> Could you mention a few Linux-enabled chips which
> include this controller?
Ralink APSoC chips (rt2880, rt305x) do:
http://svn.dd-wrt.com:8000/dd-wrt/browser/src/linux/rt2880/linux-2.6.23/drivers/usb/dwc_otg/Kconfig
Daniel
--
Dipl.-Math. Daniel
While running fs_racer test from LTP on a POWER6 box against latest
git(2.6.35-rc3-git4 - commitid 984bc9601f64fd)
came across the following warning followed by multiple oops.
[ cut here ]
Badness at kernel/mutex-debug.c:64
NIP: c00be9e8 LR: c00be9cc CTR:
Dear Rupjyoti Sarmah,
In message <201006241327.o5odry6m032...@amcc.com> you wrote:
> This patch enables the on-chip DWC SATA controller of the AppliedMicro
> processor 460EX.
>
> Signed-off-by: Rupjyoti Sarmah
> Signed-off-by: Mark Miesfeld
> Signed-off-by: Prodyut Hazarika
>
> ---
> This p
Hi Wolfgang,
I took the mainline kernel v2.6.35-rc3 and downloaded using the git
download link.
I created the patch on 6/24/2010 after doing a git pull.
With the kernel tree on 6/24/2010 the driver compiled. I also tested the
functionality on the SATA drive & it worked.
Regards,
Rup
-Orig
We just introduced generic functions to handle shadow pages on PPC.
This patch makes the respective backends make use of them, getting
rid of a lot of duplicate code along the way.
Signed-off-by: Alexander Graf
---
v2 -> v3:
- use hlist
- use global kmem cache
---
arch/powerpc/include/asm
Book3s suffered from my really bad shadow MMU implementation so far. So
I finally got around to implement a combined hash and list mechanism that
allows for much faster lookup of mapped pages.
To show that it really is faster, I tried to run simple process spawning
code inside the guest with and w
Currently the shadow paging code keeps an array of entries it knows about.
Whenever the guest invalidates an entry, we loop through that entry,
trying to invalidate matching parts.
While this is a really simple implementation, it is probably the most
ineffective one possible. So instead, let's kee
On Fri, 2010-06-25 at 13:18 +0200, Jakub Jelinek wrote:
> On Fri, Jun 25, 2010 at 01:08:23PM +0200, Segher Boessenkool wrote:
> > > - stw%U0%X0 %L2,%1"
> > > - : "=m" (*ptep), "=m" (*((unsigned char *)ptep+4))
> > > + stw%U1%X1 %L2,%1"
> > > + : "=m<>" (*ptep), "=m<>" (*((unsigned c
Hi, David, Segher,
Maybe it was caused by floating exception.I found that,system received
a program check exception,the reason for it was REASON_ILLEGAL.
I also use show_regs to print the NIP in exception,it seemed that
,this exception was caused by 'vmhaddshs' instruction in user mode of
init p
On 06/30/2010 01:14 AM, Shawn Jin wrote:
Hi Scott,
Bus Fault @ 0x00404c40, fixup 0x
Machine check in kernel mode.
Caused by (from msr): regs 07d1cb80 Unknown values in msr
NIP: 00404C40 XER: LR: 00404C24 REGS: 07d1cb80 TRAP: 0200 DAR: 0001
MSR: 1002 EE: 0 PR: 0 FP: 0 ME
On Tue, Jun 29, 2010 at 03:16:26PM -0700, David Miller wrote:
>
> I really don't see any value at all to this config option,
> the errata fixup code should be there all the time.
Well, at least for eTSEC76 erratum (patch 2/3) we have to touch
fast path (i.e. start_xmit), so I just wanted to make
MPC8313ECE says:
"If MACCFG2[Huge Frame]=0 and the Ethernet controller receives frames
which are larger than MAXFRM, the controller truncates the frames to
length MAXFRM and marks RxBD[TR]=1 to indicate the error. The controller
also erroneously marks RxBD[TR]=1 if the received frame length is
MPC8313ECE says:
"For TOE=1 huge or jumbo frames, the data required to generate the
checksum may exceed the 2500-byte threshold beyond which the controller
constrains itself to one memory fetch every 256 eTSEC system clocks.
This throttling threshold is supposed to trigger only when the
contr
MPC8313ECE says:
"If the controller receives a 1- or 2-byte frame (such as an illegal
runt packet or a packet with RX_ER asserted) before GRS is asserted
and does not receive any other frames, the controller may fail to set
GRSC even when the receive logic is completely idle. Any subsequent
re
Dear Rupjyoti Sarmah,
In message <3b928476b2fffdcf0694e5436e8a4...@mail.gmail.com> you wrote:
>
> I took the mainline kernel v2.6.35-rc3 and downloaded using the git
> download link.
> I created the patch on 6/24/2010 after doing a git pull.
>
> With the kernel tree on 6/24/2010 the driver compi
From: Anton Vorontsov
Date: Wed, 30 Jun 2010 20:38:04 +0400
> On Tue, Jun 29, 2010 at 03:16:26PM -0700, David Miller wrote:
>>
>> I really don't see any value at all to this config option,
>> the errata fixup code should be there all the time.
>
> Well, at least for eTSEC76 erratum (patch 2/3)
From: Anton Vorontsov
Date: Wed, 30 Jun 2010 20:39:12 +0400
> MPC8313ECE says:
>
> "If MACCFG2[Huge Frame]=0 and the Ethernet controller receives frames
> which are larger than MAXFRM, the controller truncates the frames to
> length MAXFRM and marks RxBD[TR]=1 to indicate the error. The contro
From: Anton Vorontsov
Date: Wed, 30 Jun 2010 20:39:13 +0400
> MPC8313ECE says:
>
> "For TOE=1 huge or jumbo frames, the data required to generate the
> checksum may exceed the 2500-byte threshold beyond which the controller
> constrains itself to one memory fetch every 256 eTSEC system clocks.
From: Anton Vorontsov
Date: Wed, 30 Jun 2010 20:39:15 +0400
> MPC8313ECE says:
>
> "If the controller receives a 1- or 2-byte frame (such as an illegal
> runt packet or a packet with RX_ER asserted) before GRS is asserted
> and does not receive any other frames, the controller may fail to set
Dear Rupjyoti Sarmah,
In message <3b928476b2fffdcf0694e5436e8a4...@mail.gmail.com> you wrote:
>
> I took the mainline kernel v2.6.35-rc3 and downloaded using the git
> download link.
> I created the patch on 6/24/2010 after doing a git pull.
I don;t think that you used v2.6.35-rc3; using this ve
On 06/30/2010 02:47 PM, Wolfgang Denk wrote:
Dear Rupjyoti Sarmah,
In message<3b928476b2fffdcf0694e5436e8a4...@mail.gmail.com> you wrote:
I took the mainline kernel v2.6.35-rc3 and downloaded using the git
download link.
I created the patch on 6/24/2010 after doing a git pull.
I don;t think
There are no BATS on BookE - we have the TLBCAM instead. Also correct
the page size information to included extended (1G and 4G) sizes.
Signed-off-by: Becky Bruce
---
Lame, I know, but this drives me batty every time I see it, and I've had
customers get confused because of it. I've finally gott
On Wed, Jun 30, 2010 at 03:17:05PM -0400, Jeff Garzik wrote:
> On 06/30/2010 02:47 PM, Wolfgang Denk wrote:
>> Dear Rupjyoti Sarmah,
>>
>> In message<3b928476b2fffdcf0694e5436e8a4...@mail.gmail.com> you wrote:
>>>
>>> I took the mainline kernel v2.6.35-rc3 and downloaded using the git
>>> download
Stefan,
The driver is based on Synopsys driver 2.60a.
We started to prepare open source submission based on our internal
version. We sync this version to linux-2.6-denx repository from time to
time. I'll sync the driver to the latest linux-2.6-denx as Wolfgang
pointed out, and re-submit patch to
There are no BATS on BookE - we have the TLBCAM instead. Also correct
the page size information to included extended sizes. We don't actually allow
a 4G page size to be used, so comment on that as well.
Signed-off-by: Becky Bruce
---
Even lamer, I forgot that we don't actually allow use of a 4G
On Mon, Mar 8, 2010 at 2:10 PM, Alexandre Bounine wrote:
>
> From: Alexandre Bounine
>
> Add Machine Check exception handling into RapidIO port driver
> for Freescale SoCs (MPC85xx).
>
> Signed-off-by: Alexandre Bounine
> Tested-by: Thomas Moll
...
> +static int fsl_rio_mcheck_exception(struct
On Wed, Jun 30, 2010 at 3:55 PM, Timur Tabi wrote:
> MCSR_MASK is not defined anywhere, so when I compile this code, I get this:
Never mind. I see that it's been fixed already, and that the patch
that removed MCSR_MASK was posted around the same time that this patch
was posted.
--
Timur Tabi
David,
AppliedMicro has PPC-405EX and PPC-460EX SOC using this controller.
There will be another arch/powerpc/boot/dts/canyonlands.dts for
PPC-460EX board.
Thanks,
Fushen
On Tue, 2010-06-29 at 15:41 -0700, David Brownell wrote:
> Good -- MUSB won't be the only one. ;)
>
> Could you mention
Just whitelist these extra compiler generated symbols.
Fixes these errors:
[...]
I've used an identical patch for almost a year now, so...
Signed-off-by: Stephen Rothwell
Acked-by: Segher Boessenkool
You probably also need something similar to http://git.infradead.org/
users/segher/linux
Hi Scott,
> Does u-boot on your board put IMMR somewhere other than 0xff00? If so,
> you'll need to update the device tree to reflect this.
Thanks a lot. I think you got something here. Please bear with me.
This is the first dts file I'm creating. I have some question
regarding to dts first.
- stw%U0%X0 %L2,%1"
- : "=m" (*ptep), "=m" (*((unsigned char *)ptep+4))
+ stw%U1%X1 %L2,%1"
+ : "=m<>" (*ptep), "=m<>" (*((unsigned char *)ptep+4))
: "r" (pte) : "memory");
This still isn't correct -- the constraint says that a byte
is written, but
Hi Segher,
On Thu, 1 Jul 2010 00:16:40 +0200 Segher Boessenkool
wrote:
>
> I've used an identical patch for almost a year now, so...
>
> > Signed-off-by: Stephen Rothwell
> Acked-by: Segher Boessenkool
Thanks.
> You probably also need something similar to http://git.infradead.org/
> users/
Maybe it was caused by floating exception.I found that,system received
a program check exception,the reason for it was REASON_ILLEGAL.
I also use show_regs to print the NIP in exception,it seemed that
,this exception was caused by 'vmhaddshs' instruction in user mode of
init process .
Is vmhadds
You probably also need something similar to http://git.infradead.org/
users/segher/linux.git/commitdiff/
98194f54cc8e19ecd752bc10e2d19ef94074f502
(note: only build-tested, not run-tested).
See http://patchwork.ozlabs.org/patch/57379/ submitted yesterday.
Yeah saw that right after I hit "send"
Dear Josh Boyer,
In message <20100630200325.gd7...@zod.rchland.ibm.com> you wrote:
>
> The driver doesn't depend on CONFIG_ATA_SFF in it's Kconfig file, but seems to
> require it at build time. Isn't that something that needs fixing in the
> driver?
Right. Next question is if this is really nee
On Thu, 1 Jul 2010 00:50:36 +0200 Segher Boessenkool
wrote:
>
> >> You probably also need something similar to http://git.infradead.org/
> >> users/segher/linux.git/commitdiff/
> >> 98194f54cc8e19ecd752bc10e2d19ef94074f502
> >> (note: only build-tested, not run-tested).
> >
> > See http://patchwo
2010/7/1 Segher Boessenkool :
>> Maybe it was caused by floating exception.I found that,system received
>> a program check exception,the reason for it was REASON_ILLEGAL.
>>
>> I also use show_regs to print the NIP in exception,it seemed that
>> ,this exception was caused by 'vmhaddshs' instruction
See http://patchwork.ozlabs.org/patch/57379/ submitted yesterday.
Yeah saw that right after I hit "send" :-) Either it's way more
complete than what I did, or way more complex because we still
don't link with libgcc :-P
Actually, the 64bit versions of the routines are supplied by the
linker
> While running fs_racer test from LTP on a POWER6 box against latest git(2.6.3
5-rc3-git4 - commitid 984bc9601f64fd)
> came across the following warning followed by multiple oops.
>
> [ cut here ]
>
> Badness at kernel/mutex-debug.c:64
> NIP: c00be9e8 LR: c000
42 matches
Mail list logo
