On Fri, Jun 11, 2010 at 5:47 PM, Dan Malek wrote:
>
> Hi Grant.
>
> On Jun 11, 2010, at 3:59 PM, Grant Likely wrote:
>
>> I've been doing a bit of work on some introductory level documentation
>> of the flattened device tree.
>
> Wow, I feel empowered to create device trees now :-)
> Seriously, I
On Wed, Aug 19, 2009 at 5:46 AM, Anton Vorontsov
wrote:
>
> Previosly the driver always tried JEDEC probing, assuming that non-JEDEC
> chips will return '0'. But truly non-JEDEC chips (like CAT25) won't do
> that, their behaviour on RDID command is undefined, so the driver should
> not call jedec_
Hi,
I am having a ppc based target on which linux-2.4.20 kernel is running
with u-boot 1.3.4 as boot loader. The target is having MPC7410 as processor
and MPC107 as system controller. Regarding memory it is having 128 MB of ram
and 16 MB of Flash memory. Also the kernel is patched with RTLin
Benjamin Herrenschmidt wrote:
On Fri, 2010-06-11 at 16:47 -0700, Dan Malek wrote:
Hi Grant.
On Jun 11, 2010, at 3:59 PM, Grant Likely wrote:
I've been doing a bit of work on some introductory level documentation
of the flattened device tree.
Wow, I feel empowered to create dev
On Sat, 2010-06-12 at 13:00 +1000, Benjamin Herrenschmidt wrote:
>
> Quite nice. Maybe the introduction could use a very quick blurb on
> the
> various data types that dtc supports for properties, and something on
> labels & phandles (references to nodes).
>
> I just flew over it. I'll try to gi
On Fri, 2010-06-11 at 16:59 -0600, Grant Likely wrote:
> I've been doing a bit of work on some introductory level documentation
> of the flattened device tree. I've got a rough copy up on the
> devicetree.org wiki, and I could use some feedback. If anyone has
> some time to look at it, you can fi
On Fri, 2010-06-11 at 16:47 -0700, Dan Malek wrote:
> Hi Grant.
>
> On Jun 11, 2010, at 3:59 PM, Grant Likely wrote:
>
> > I've been doing a bit of work on some introductory level documentation
> > of the flattened device tree.
>
> Wow, I feel empowered to create device trees now :-)
> Seriously
Hi Grant.
On Jun 11, 2010, at 3:59 PM, Grant Likely wrote:
I've been doing a bit of work on some introductory level documentation
of the flattened device tree.
Wow, I feel empowered to create device trees now :-)
Seriously, I never understood this well and this is a
great document.
I have o
I've been doing a bit of work on some introductory level documentation
of the flattened device tree. I've got a rough copy up on the
devicetree.org wiki, and I could use some feedback. If anyone has
some time to look at it, you can find it here:
http://devicetree.org/Device_Tree_Usage
Thanks,
g
On Fri, 2010-06-11 at 22:55 +0200, Johannes Berg wrote:
> When SPARSE_IRQ is set, irq_to_desc() can
> return NULL. While the code here has a
> check for NULL, it's not really correct.
> Fix it by separating the check for it.
Incidentally, there's another quirk in fixup_irqs():
...
alloc_c
On Wed, 9 Jun 2010 16:14:10 -0700 (PDT)
Linus Torvalds wrote:
> On Wed, 9 Jun 2010, Jesse Barnes wrote:
> >
> > Nothing too big here; I do have a couple of fixes in the queue that
> > aren't included here though. I'll be pulling them together over the
> > next couple of days.
>
> Hmm. None of t
When SPARSE_IRQ is set, irq_to_desc() can
return NULL. While the code here has a
check for NULL, it's not really correct.
Fix it by separating the check for it.
This fixes CPU hot unplug for me.
Reported-by: Alastair Bridgewater
Cc: sta...@kernel.org
Signed-off-by: Johannes Berg
---
v2: cc Alas
Issuing the following command on host:
$ ifconfig eth2 mtu 1600 ; ping 10.0.0.27 -s 1485 -c 1
Makes some boards (tested with MPC8315 rev 1.1 and MPC8313 rev 1.0)
oops like this:
skb_over_panic: text:c0195914 len:1537 put:1537 head:c79e4800 data:c79e4880
tail:0xc79e4e81 end:0xc79e4e80 dev:eth1
On Fri, Jun 11, 2010 at 5:24 AM, Anatolij Gustschin wrote:
> On Wed, 19 May 2010 14:47:47 -0600
> Grant Likely wrote:
>
>> On Thu, May 6, 2010 at 1:18 PM, Anatolij Gustschin wrote:
>> > Hi Grant,
>> >
>> > On Tue, 27 Apr 2010 10:51:21 -0600
>> > Grant Likely wrote:
>> >
>> >> On Tue, Apr 27, 20
- "Stephen Rothwell" wrote:
> Hi John,
>
> On Thu, 10 Jun 2010 13:03:00 +0200 John Kacur
> wrote:
> >
> > From: Amit Shah
> >
> > Alan pointed out a race in the code where hvc_remove is invoked.
> The
> > recent virtio_console work is the first user of hvc_remove().
>
> I am not sure wh
Michael Ellerman wrote:
>
> On Tue, 2010-05-18 at 16:30 +, nello martuscielli wrote:
>> Michael Ellerman ellerman.id.au> writes:
>>
>> _omissis__
>> > >
>> > > hi, is there available that patch?
>> > > With the fresh new 2.6.34 the logflood problem is still present.
>> >
>> > You could t
Benjamin Herrenschmidt wrote:
>
> On Mon, 2009-06-01 at 09:32 +0200, Giuseppe Coviello wrote:
>
>>
>> Signed-off-by: Nico Macrionitis
>> Signed-off-by: Giuseppe Coviello
>
> As long as you guys have verified that it actually works, I have
> no objection.
>
> Ack.
>
> Cheers,
> Ben.
>
h
hi all,
this powermac G5 ( PowerMac7,2 - dual 1.8 pci-x) fails to power off and just
stops there and after a minute or so the fans start to roar. Reboot works
fine.
Here my kernel config:
http://clinker.cruxppc.org/~acrux/config-2.6.33.5-powermacg5
thanks,
Nico
--
View this message in context
On (Fri) Jun 11 2010 [09:13:49], John Kacur wrote:
>
> I was just listing patches that Thomas could potentially include
> in the real-time kernel which is currently based on 2.6.33.5
There's a fix to this patch: 320718ee074acce5ffced6506cb51af1388942aa
that you might want to include as well.
Previously the RCTRL_TS_ENABLE bit was set unconditionally. However, if
the RCTRL_TS_ENABLE is set without TMR_CTRL[TE], the driver does not work
properly on some boards (Anton had problems with the MPC8313ERDB and
MPC8568EMDS).
With this patch the bit will only be set if requested from user space
On Fri, Jun 11, 2010 at 01:49:05PM +0200, Manfred Rudigier wrote:
> Previously the RCTRL_TS_ENABLE bit was set unconditionally. However, if
> the RCTRL_TS_ENABLE is set without TMR_CTRL[TE], the driver does not work
> properly on some boards (Anton had problems with the MPC8313ERDB and
> MPC8568EMD
When going to standby mode mpc code maps the whole soc5200 node
to access warious MBAR registers. However as of_iomap uses 'reg'
property of device node, only small part of MBAR is getting mapped.
Thus pm code gets oops when trying to access high parts of MBAR.
As a way to overcome this, make mpc52
Add dts descriptions for onboard 256 byte I2C eeprom (pcf8582C-2)
and 16MB NOR flash (am29lv652d).
Signed-off-by: Dmitry Eremin-Solenikov
Cc: Grant Likely
---
arch/powerpc/boot/dts/lite5200.dts | 24
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch
On Wed, 19 May 2010 14:47:47 -0600
Grant Likely wrote:
> On Thu, May 6, 2010 at 1:18 PM, Anatolij Gustschin wrote:
> > Hi Grant,
> >
> > On Tue, 27 Apr 2010 10:51:21 -0600
> > Grant Likely wrote:
> >
> >> On Tue, Apr 27, 2010 at 10:11 AM, Anatolij Gustschin wrote:
> >> > Factor out common code
Joe Perches writes:
> (cc's trimmed and rpjday added)
>
> On Wed, 2010-06-09 at 11:58 +0200, Christoph Egger wrote:
>> I've been running a check on the arch/powerpc sourcetree for
>> config Items not defined in Kconfig and found5 such chases.
>
> Are you aware of
> http://www.crashcourse.ca/wiki/
On Wed, Mar 3, 2010 at 8:18 PM, Anton Vorontsov
wrote:
> Starting with commit a3bc1f11e9b867a4f49505 ("gianfar: Revive SKB
> recycling") gianfar driver sooner or later stops transmitting any
> packets on SMP machines.
>
> start_xmit() prepares new skb for transmitting, generally it does
> three th
From: Matthias Fuchs
This patch adds a gpio driver for MPC512X PowerPCs.
It has been tested on our CAN-CBX-CPU5201 module that
uses a MPC5121 CPU. This platform comes with a couple of
LEDs and configuration switches that have been used for testing.
After change to the of-gpio api the reworked d
On Wed, 9 Jun 2010 at about 16:01:10 +1000 Anton Blanchard wrote:
>
> When trying to flash a machine via the update_flash command, I received the
> following error:
>
>
> Restarting system.
> FLASH: kernel bug...flash list header addr above 4GB
>
>
> The code in question has a comment
When trying to flash a machine via the update_flash command, Anton received the
following error:
Restarting system.
FLASH: kernel bug...flash list header addr above 4GB
The code in question has a comment that the flash list should be in
the kernel data and therefore under 4GB:
On Thu, 2010-06-10 at 09:50 -0400, Mark Crichton wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I've dug up and revived my old Mac Mini (PPC) and been trying to get it
> to work again. I was looking at getting the system to suspend to ram,
> but it didn't seem to be working. So, I tr
On Fri, 2010-06-11 at 09:30 +0800, jxnuxdy wrote:
> Hi guys,
>
> I encountered a PCIe problem under linux, the two PCIe bus on my board seems
> work,
> at least I can access the registers through the PCIe bus, however the dma for
> the
> PCIe bus can't work, so I just dumped the pci device, but
31 matches
Mail list logo
