From: Tirumala Marri
Signed-off-by: Tirumala Marri
---
Kernel version: 2.6.33-rc1
Testing:
When 460SX configured as root as a end point E1000(Intell Ethernet card)
was plugged into the one of the PCI-E ports. I was able to run the
traffic
with MSI interrupts.
---
arch/p
Use #define pr_fmt(fmt) "viod: " fmt
Remove #define VIOD_KERN_WARNING and VIOD_KERN_INFO
Convert printk(VIOD_KERN_ to pr_
Coalesce long format strings
Signed-off-by: Joe Perches
Acked-by: Stephen Rothwell
drivers/block/viodasd.c | 86 +++---
1 files ch
In message <4b317324.3000...@redhat.com> you wrote:
> Michael Neuling wrote:
> > In message <4b2b934c.1060...@redhat.com> you wrote:
> >>
> >>
> >> Mahesh Jagannath Salgaonkar wrote:
> >>> Michael Neuling wrote:
> In message <4b29ee5f.9020...@linux.vnet.ibm.com> you wrote:
> > Hi Michael
Currenly, proc_devtree.c depends on asm/prom.h to include linux/of.h, to
provide some device-tree definitions (eg, struct property).
Instead, include linux/of.h directly. We still need asm/prom.h for
HAVE_ARCH_DEVTREE_FIXUPS.
Signed-off-by: Jeremy Kerr
---
fs/proc/proc_devtree.c |1 +
1 fi
We only need set_node_proc_entry in proc_devtree.c, so move it there.
This fixes the !HAVE_ARCH_DEVTREE_FIXUPS build, as we can't make make
the definition in linux/of.h conditional on this #define (definitions in
asm/prom.h can't be exposed to linux/of.h, due to the enforced #include
ordering).
S
We use a few procfs-specific functions (eg, proc_device_tree_*) which
aren't covered by the current includes. This causes the following build
error on arm:
drivers/of/base.c: In function 'prom_add_property':
drivers/of/base.c:861: error: implicit declaration of function
'proc_device_tree_add_prop
Hi all,
A small series of patches to fix minor build breakages when compiling
gcl's test-devicetree tree on ARM.
I've CC-ed lkml & linuxppc-dev for the fs/proc/ changes, but these
patches are only applicable to gcl's tree at present.
Cheers,
Jeremy
---
Jeremy Kerr (3):
of: include linux
Michael Neuling wrote:
> In message <4b2b934c.1060...@redhat.com> you wrote:
>>
>>
>> Mahesh Jagannath Salgaonkar wrote:
>>> Michael Neuling wrote:
In message <4b29ee5f.9020...@linux.vnet.ibm.com> you wrote:
> Hi Michael,
>
> Michael Neuling wrote:
>>> + * regs_get_argument_nth
On Tue, 2009-12-22 at 08:45 -0600, Nathan Fontenot wrote:
> The recently introduced cpu_hotplug_driver_lock used to serialize
> cpu hotplug operations, namely for the pseries platform, causes a build
> issue for other platforms. The base cpu hotplug code attempts
> to take this lock, but it may no
Sometimes ucc_geth fails to suspend with the following trace:
ucc_geth e0103000.ucc: suspend
ucc_geth e0102000.ucc: suspend
NETDEV WATCHDOG: eth0 (ucc_geth): transmit queue 0 timed out
[ cut here ]
Badness at net/sched/sch_generic.c:255
NIP: c021cb5c LR: c021cb5c CTR:
Since hibernation assumes power loss, we should fully reinitialize
PHYs (including platform fixups), as if PHYs were just attached.
This patch factors phy_init_hw() out of phy_attach_direct(), then
converts mdio_bus to dev_pm_ops and adds an appropriate restore()
callback.
Signed-off-by: Anton Vo
Sometimes kernel hangs on resume with the following trace:
ucc_geth e0102000.ucc: resume
INFO: task bash:1764 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
bash D 0fecf43c 0 1764 1763 0x
Call Trace:
[cf9a7
> "Bill" == Bill Gatliff writes:
Bill> Guys:
Bill> Is it possible to specify an individual GPIO pin as an interrupt source
Bill> with the current MPC52xx code?
No (not yet). In Ben's latest pull request there's a patch from me to
add basic infrastructure for gpio_to_irq(). I've recently a
Guys:
Is it possible to specify an individual GPIO pin as an interrupt source
with the current MPC52xx code?
I don't see anything in mpc52xx_gpio.c that registers an interrupt
handler, which I think would be a necessary step towards demultiplexing
the GPIO interrupt event. So I'm thinking that
Hi Felix,
Felix Radensky wrote:
> Hi, Wolfgang
>
> Wolfgang Grandegger wrote:
[snip]
>> The trees provided by Freescale are usually based on older kernel
>> version. Borrow from such trees is OK, but the project developers should
>> use a recent kernel version for development.
>>
>
> I was ta
Hi, Wolfgang
Wolfgang Grandegger wrote:
Felix Radensky wrote:
Hi, Wolfgang
Wolfgang Grandegger wrote:
Felix Radensky wrote:
Hi,
Almost all MPC85XX based systems have the compatible=:"fsl-i2c" in
respective
i2c device tree nodes. This causes FSL i2c driver to use the followi
Felix Radensky wrote:
> Hi, Wolfgang
>
> Wolfgang Grandegger wrote:
>> Felix Radensky wrote:
>>
>>> Hi,
>>>
>>> Almost all MPC85XX based systems have the compatible=:"fsl-i2c" in
>>> respective
>>> i2c device tree nodes. This causes FSL i2c driver to use the following
>>> "backward
>>> compatibl
Hi, Wolfgang
Wolfgang Grandegger wrote:
Felix Radensky wrote:
Hi,
Almost all MPC85XX based systems have the compatible=:"fsl-i2c" in
respective
i2c device tree nodes. This causes FSL i2c driver to use the following
"backward
compatible" values: FSR=0x31 DFSR=0x10. This is regardless of CCB
Josh,
Thanks for the comments. I will fix them re-submit it.
Regards,
Marri
-Original Message-
From: Josh Boyer [mailto:jwbo...@gmail.com] On Behalf Of Josh Boyer
Sent: Tuesday, December 22, 2009 4:08 AM
To: Tirumala Reddy Marri
Cc: linuxppc-dev@lists.ozlabs.org; writetoma...@yahoo.com
Su
One possible cause is the two board has different RCW.
So that the freq of core/csb/ Is different.
> -Original Message-
> From:
> linuxppc-dev-bounces+daveliu=freescale@lists.ozlabs.org
> [mailto:linuxppc-dev-bounces+daveliu=freescale@lists.ozlab
> s.org] On Behalf Of RONETI
Felix Radensky wrote:
> Hi,
>
> Almost all MPC85XX based systems have the compatible=:"fsl-i2c" in
> respective
> i2c device tree nodes. This causes FSL i2c driver to use the following
> "backward
> compatible" values: FSR=0x31 DFSR=0x10. This is regardless of CCB clock
> frequency and i2c clock p
Hi,
Almost all MPC85XX based systems have the compatible=:"fsl-i2c" in
respective
i2c device tree nodes. This causes FSL i2c driver to use the following
"backward
compatible" values: FSR=0x31 DFSR=0x10. This is regardless of CCB clock
frequency and i2c clock prescaler.
On my custom MPC8536 ba
The recently introduced cpu_hotplug_driver_lock used to serialize
cpu hotplug operations, namely for the pseries platform, causes a build
issue for other platforms. The base cpu hotplug code attempts
to take this lock, but it may not be needed for all platforms. This patch
moves the lock/unlock
Virtio consoles can be hotplugged, so hvc_alloc gets called from
multiple sites: from the initial probe() routine as well as later on
from workqueue handlers which aren't __devinit code.
So, drop the __devinit annotation for hvc_alloc.
Signed-off-by: Amit Shah
Cc: linuxppc-...@ozlabs.org
---
dr
From: Rusty Russell
This is nicer for modern R/O protection. And noone needs it non-const, so
constify the callers as well.
Signed-off-by: Rusty Russell
Signed-off-by: Amit Shah
To: Christian Borntraeger
Cc: linuxppc-...@ozlabs.org
---
drivers/char/hvc_beat.c |2 +-
drivers/char/h
On Tue, 2009-12-22 at 18:54 +0800, Jeremy Kerr wrote:
> Hi Michael,
>
> > > void early_init_dt_setup_initrd_arch(unsigned long start,
> > > unsigned long end);
> >
> > arch_early_init_dt_setup_initrd() makes more sense to me, but ..
>
> _arch has been the general
On Tue, Dec 22, 2009 at 12:49:51AM -0800, tma...@amcc.com wrote:
>From: Tirumala Marri
>
>
>Signed-off-by: Tirumala Marri
>---
>Kernel version: 2.6.33-rc1
>Testing:
> When 460SX configured as root as a end point E1000(Intell Ethernet
> card)
> was plugged into the one of the PCI-E p
On Tue, Dec 22, 2009 at 12:49:41AM -0800, tma...@amcc.com wrote:
>From: Tirumala Marri
>
>
>Signed-off-by: Tirumala Marri
Acked-by: Josh Boyer ---
>Kerenl:2.6.33-rc1
>Testing: This patch has been tested on 460SX based redwood board . One board
>configured as
>root complex and other as Endpoin
Hi Michael,
> > void early_init_dt_setup_initrd_arch(unsigned long start,
> > unsigned long end);
>
> arch_early_init_dt_setup_initrd() makes more sense to me, but ..
_arch has been the general convention for arch-specific hooks in
drivers/of/.
> > +#ifdef CO
On Tue, 2009-12-22 at 17:39 +0800, Jeremy Kerr wrote:
> At present, the fdt code sets the kernel-wide initrd_start and
> initrd_end variables when parsing /chosen. On ARM, we only set these
> once the bootmem has been reserved.
>
> This change adds an arch callback to setup the initrd from the dev
At present, the fdt code sets the kernel-wide initrd_start and
initrd_end variables when parsing /chosen. On ARM, we only set these
once the bootmem has been reserved.
This change adds an arch callback to setup the initrd from the device
tree:
void early_init_dt_setup_initrd_arch(unsigned long s
Hi,
I checked the RCW(RCWLR and RCWHR) and they are the same(taken from
NOR), S3 and S4 switches are the same too.
I will take a look at the priority levels on CSB.
Regards,
Asen
Liu Dave-R63238 wrote:
One possible cause is the two board has different RCW.
So that the freq of core/csb/ Is
From: Tirumala Marri
Signed-off-by: Tirumala Marri
---
Kernel version: 2.6.33-rc1
Testing:
When 460SX configured as root as a end point E1000(Intell Ethernet
card)
was plugged into the one of the PCI-E ports. I was able to run the
traffic
with MSI interrupts.
---
ar
From: Tirumala Marri
Signed-off-by: Tirumala Marri
---
Kerenl:2.6.33-rc1
Testing: This patch has been tested on 460SX based redwood board . One board
configured as
root complex and other as Endpoint. Checked for link up . From root complex
lspci command
shows the end point. Also programmed
34 matches
Mail list logo