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
> unresp
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 4G
Hi,
On Tue, 22 Jun 2010 11:29:50 -0500
Timur Tabi wrote:
> On Thu, Apr 29, 2010 at 6:49 PM, Anatolij Gustschin 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
On 05/19/2010 04:47 PM, Grant Likely wrote:
On Wed, May 19, 2010 at 3:37 PM, Scott Wood 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 to 2 in some contexts a
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 se
>> 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 m
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 th
On Thu, Apr 29, 2010 at 6:49 PM, Anatolij Gustschin 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
> review. F
>> 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
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 beca
>> 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 U
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 p
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 c
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
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
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
>> 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 incl
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, sin
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
> th
>> 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
>> mic
On 06/22/2010 10:51 AM, Timur Tabi wrote:
> On Mon, Jun 21, 2010 at 2:00 PM, Gary Thomas 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 te
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
dri
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 p
On Mon, Jun 21, 2010 at 2:00 PM, Gary Thomas 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:
http://patchwork.ozlabs.org/patc
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 & descriptors
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
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 softwar
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
___
L
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
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 p
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 usi
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
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 impl
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
__
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 most
On Mon, Jun 21, 2010 at 7:20 PM, Anton Vorontsov 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
>> wrote:
>> > On Mon, Jun 21, 2010 at 03:22:48PM +0800, Barry Song wrote:
>> >> On Mon, Jun 21, 2010 at 3:15 PM, Anton Voront
36 matches
Mail list logo
