On Mon, Jun 21, 2010 at 7:20 PM, Anton Vorontsov cbouatmai...@gmail.com wrote:
On Mon, Jun 21, 2010 at 06:31:44PM +0800, Barry Song wrote:
On Mon, Jun 21, 2010 at 3:39 PM, Anton Vorontsov cbouatmai...@gmail.com
wrote:
On Mon, Jun 21, 2010 at 03:22:48PM +0800, Barry Song wrote:
On Mon, Jun
On 06/21/2010 04:44 PM, Alexander Graf wrote:
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
On 06/21/2010 04:25 PM, Alexander Graf wrote:
Initially we had to search for pte entries to invalidate them. Since
the logic has improved since then, we can just get rid of the search
function.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
Avi Kivity wrote:
On 06/21/2010 04:44 PM, Alexander Graf wrote:
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,
On 06/21/2010 04:25 PM, Alexander Graf wrote:
The linux kernel already provides a hash function. Let's reuse that
instead of reinventing the wheel!
Applied, thanks.
--
error compiling committee.c: too many arguments to function
___
Linuxppc-dev
On 06/21/2010 04:24 PM, Alexander Graf wrote:
When a guest sets its SR entry to invalid, we may still find a
corresponding entry in a BAT. So we need to make sure we're not
faulting on invalid SR entries, but instead just claim them to be
BAT resolved.
This resolves breakage experienced when
On 06/22/2010 03:04 PM, Alexander Graf wrote:
Avi Kivity wrote:
On 06/21/2010 04:44 PM, Alexander Graf wrote:
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
Avi Kivity wrote:
On 06/22/2010 03:04 PM, Alexander Graf wrote:
Avi Kivity wrote:
On 06/21/2010 04:44 PM, Alexander Graf wrote:
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
On 06/22/2010 03:10 PM, Alexander Graf wrote:
If you have more performance hints, I'll gladly take them :).
Using a cpu that virtualizes the mmu in hardware helps tremendously.
--
error compiling committee.c: too many arguments to function
___
Avi Kivity wrote:
On 06/22/2010 03:10 PM, Alexander Graf wrote:
If you have more performance hints, I'll gladly take them :).
Using a cpu that virtualizes the mmu in hardware helps tremendously.
PPC never does that. Even with the virtualization extensions the MMU is
still software
On 06/22/2010 03:14 PM, Alexander Graf wrote:
Avi Kivity wrote:
On 06/22/2010 03:10 PM, Alexander Graf wrote:
If you have more performance hints, I'll gladly take them :).
Using a cpu that virtualizes the mmu in hardware helps tremendously.
PPC never does that. Even
I'm still trying to get UCC UART to work on my MPC8358 with
the 2.6.33.3 kernel.
When I try to send data to the port, there is no output, not
even any interrupts on the device. What I see is that the UART
driver seems to initialize fine and pushes characters into
the output buffers
On Mon, Jun 21, 2010 at 2:00 PM, Gary Thomas g...@mlbassoc.com wrote:
I'm running 2.6.33.3 on MPC8358. I have UCC1+UCC2 working fine
for ethernet, but when I add UCC3 as a UART, the network devices
quit working.
Since you're using QE UART, would you mind testing this patch:
On 06/22/2010 10:55 AM, Gary Thomas wrote:
I'm still trying to get UCC UART to work on my MPC8358 with
the 2.6.33.3 kernel.
When I try to send data to the port, there is no output, not
even any interrupts on the device. What I see is that the UART
driver seems to initialize fine and pushes
On 06/22/2010 09:10 AM, Chuck Meade wrote:
On 06/22/2010 10:55 AM, Gary Thomas wrote:
I'm still trying to get UCC UART to work on my MPC8358 with
the 2.6.33.3 kernel.
When I try to send data to the port, there is no output, not
even any interrupts on the device. What I see is that the UART
On 06/22/2010 10:51 AM, Timur Tabi wrote:
On Mon, Jun 21, 2010 at 2:00 PM, Gary Thomas g...@mlbassoc.com wrote:
I'm running 2.6.33.3 on MPC8358. I have UCC1+UCC2 working fine
for ethernet, but when I add UCC3 as a UART, the network devices
quit working.
Since you're using QE UART, would
Hi Gary,
According to the errata, it looks like the MPC8358 is subject to
erratum QE_UART6. You'll need to use soft UART mode and load the
microcode patch. Once that is done you will also need to use two
different BRG's, one for tx and one for rx, since the soft UART mode
microcode patch
Gary Thomas wrote:
I'm still trying to get UCC UART to work on my MPC8358 with
the 2.6.33.3 kernel.
When I try to send data to the port, there is no output, not
even any interrupts on the device. What I see is that the UART
driver seems to initialize fine and pushes characters into
the
On 06/22/2010 09:28 AM, Chuck Meade wrote:
Hi Gary,
According to the errata, it looks like the MPC8358 is subject to
erratum QE_UART6. You'll need to use soft UART mode and load the
microcode patch. Once that is done you will also need to use two
different BRG's, one for tx and one for rx,
Sure. Go to opensource.freescale.com/firmware and download (for your
MPC8358)
the 8360 soft UART mode microcode patch. You will need to know if
your CPU
is a 2.0 or 2.1 silicon, since there is a different microcode patch
for each.
Then in the kernel config I believe I included
On Tue, Jun 22, 2010 at 02:37:52PM +0800, Barry Song wrote:
[...]
jid = jedec_probe(spi);
if (!jid) {
- dev_info(spi-dev, non-JEDEC variant of %s\n,
- id-name);
+ return -ENODEV;
The
Since commit 18c6182bae0acca220ed6611f741034d563cd19f (Rework
probing/JEDEC code), m25p80 driver successfully registers chips
even if JEDEC probing fails.
This was needed to support non-JEDEC flashes. Though, it appears
that some platforms (e.g. blackfin bf533 stamp[1]) used the old
behavior to
spi_write_then_read() may return its own return codes (e.g. -EIO),
so let's propagate the value down to the probe().
Also, remove jedec == 0 check, it isn't needed as nowadays we use
dedicated SPI device IDs for non-JEDEC flashes.
Suggested-by: Barry Song 21cn...@gmail.com
Signed-off-by: Anton
On 06/22/2010 09:53 AM, Chuck Meade wrote:
Sure. Go to opensource.freescale.com/firmware and download (for your
MPC8358)
the 8360 soft UART mode microcode patch. You will need to know if
your CPU
is a 2.0 or 2.1 silicon, since there is a different microcode patch
for each.
Then in the kernel
On Tue, Jun 22, 2010 at 12:57, Anton Vorontsov wrote:
Since commit 18c6182bae0acca220ed6611f741034d563cd19f (Rework
probing/JEDEC code), m25p80 driver successfully registers chips
even if JEDEC probing fails.
This was needed to support non-JEDEC flashes. Though, it appears
that some
I did not do that, and I have it running here. I will say though that I
hardcoded the driver to run in soft UART mode. You will need to at least
add the appropriate line to your dts to get the driver to operate in
Soft UART mode.
I hardcoded mine because I had to backport this UCC UART
On 06/22/2010 12:14 PM, Chuck Meade wrote:
I did not do that, and I have it running here. I will say though that I
hardcoded the driver to run in soft UART mode. You will need to at least
add the appropriate line to your dts to get the driver to operate in
Soft UART mode.
I hardcoded mine
What BRGs did you choose for tx and rx?
BRG1 BRG2
OK
Get a scope on the UCC3 tx pin and try to output some chars. See if
there is
any digital activity on that pin at all. If you are looking at a
terminal for
output, there are too many things that could be wrong between that tx
pin
On Thu, Apr 29, 2010 at 6:49 PM, Anatolij Gustschin ag...@denx.de wrote:
This patch series rework DIU support patches submitted
previously. Comments to the previos patch series have
been addressed, not related changes are dropped and some
changes are split out to separate patches to simplify
On 06/22/2010 01:01 PM, Chuck Meade wrote:
What BRGs did you choose for tx and rx?
BRG1 BRG2
OK
Get a scope on the UCC3 tx pin and try to output some chars. See if
there is
any digital activity on that pin at all. If you are looking at a
terminal for
output, there are too many things
Also in the current Linux kernel, there is a dependence on the
correctness
of the brg-frequency property from the dts. Look up above
qe_setbrg() at
the qe_get_brg_clk() function. Before the return (there are multiple
return
points) printk the brg_clk being returned. That must be correct
On Thu, Jun 10, 2010 at 10:04:28AM +0800, hellohello wrote:
Although I haven't used scc port as uart, I think your smc1 part in your
dts file maybe is wrong.
ser...@11a82 { ...
reg = 0x11a80 0x20 0x87fc 2;
should be:
reg = 0x11a80 0x20 XXX 40;
XXX is the value which is set at 0x87fc
On 05/19/2010 04:47 PM, Grant Likely wrote:
On Wed, May 19, 2010 at 3:37 PM, Scott Woodscottw...@freescale.com wrote:
I believe the only part of this that is new with ePAPR is that it asks that
the interrupt controller address cells be explicitly specified, as it's a
bit icky for it to default
Hi,
On Tue, 22 Jun 2010 11:29:50 -0500
Timur Tabi ti...@freescale.com wrote:
On Thu, Apr 29, 2010 at 6:49 PM, Anatolij Gustschin ag...@denx.de wrote:
This patch series rework DIU support patches submitted
previously. Comments to the previos patch series have
been addressed, not related
On Wed, Jun 16, 2010 at 09:23:38AM -0500, Timur Tabi wrote:
I'm sorry, but Linux does depend on the boot loader,
In some ways, but we try not to do so too gratuitously.
and U-Boot does need to know whether Linux is going to use 36-bit
addressing.
U-Boot knows whether it puts things over
On Tue, Jun 15, 2010 at 12:05:05PM -0400, Eric Millbrandt wrote:
These patches reimplement the reset fuction in the ac97 to use gpio pins
instead of using the mpc5200 ac97 reset functionality in the psc. This
avoids a problem in which attached ac97 devices go into test mode appear
36 matches
Mail list logo
