On Fri, 5 Feb 2010 14:42:46 +0100
Anatolij Gustschin ag...@denx.de wrote:
The patches are based on v2.6.33-rc6 and cover the following
items:
These patches can also be pulled from
git://git.denx.de/linux-2.6-denx.git mpc512x-v2.6.33-devel
branch now.
Anatolij
In message 20100209154141.03f0.a69d9...@jp.fujitsu.com you wrote:
When reserving stack space for a new process, make sure we're not
attempting to expand the stack by more than rlimit allows.
This fixes a bug caused by b6a2fea39318e43fee84fa7b0b90d68bed92d2ba mm:
variable length argument
Hi Grant,
Grant Likely wrote:
Hi everyone. Here are a few patches that I've got sitting in my
test-devicetree branch, but I haven't posted for review yet. Please
take a look and let me know if they are okay. Once I've collected
acks I'll move them over to my next-devicetree branch.
I am
Anton Vorontsov wrote:
OF GPIO infrastructure is using dynamic GPIO bases, so it is possible
that of_get_gpio()'s returned GPIO number will be no longer valid, or
worse, it may point to an unexpected GPIO controller.
I am not able to apply this last patch.
$ git-am \[PATCH\ 3_3\]\ of_gpio\:\
Michal Simek wrote:
Anton Vorontsov wrote:
OF GPIO infrastructure is using dynamic GPIO bases, so it is possible
that of_get_gpio()'s returned GPIO number will be no longer valid, or
worse, it may point to an unexpected GPIO controller.
I am not able to apply this last patch.
$ git-am
Anton Vorontsov wrote:
Hi all,
OF GPIO infrastructure is using dynamic GPIO bases, so it is possible
that of_get_gpio()'s returned GPIO number will be no longer valid, or
worse, it may point to an unexpected GPIO controller.
This scenario is possible:
driver A: driver B:
Hi Stefan,
thanks for you reply, as per Amcc 440 ep h/w spec . I can see 10 External
interrupts can be configured !! So can i use the GPIO ping mapped to one of
these external IRQ's ? Or should the h/w deisgn also support it or is it
pure s/w configurations. So i would just like to get an
On Thu, 21 Jan 2010 18:03:11 -0800 (PST)
David Miller da...@davemloft.net wrote:
From: Wolfgang Grandegger w...@grandegger.com
Date: Thu, 21 Jan 2010 16:25:38 +0100
Do you see a more clever solution to this problem?
See how we handle this in the ESP scsi driver. We have a set of
On Tue, Feb 2, 2010 at 12:47 AM, Anatolij Gustschin ag...@denx.de wrote:
Currently the support for MPC5121 PSC UART in the mpc52xx_uart
driver is broken (only console pre-initialized by the bootloader
works). Re-enable it now by providing MPC5121 specific ops
for PSCx clock activation, FIFO
On Tue, Feb 2, 2010 at 12:47 AM, Anatolij Gustschin ag...@denx.de wrote:
Support for MPC5121 PSC UART in the mpc52xx_uart driver
added new DTS properties for FSL MPC5121 PSC FIFO Controller.
Provide documentation of the new properties and some examples.
Signed-off-by: Anatolij Gustschin
On Tue, Feb 2, 2010 at 12:47 AM, Anatolij Gustschin ag...@denx.de wrote:
MPC5121 has 12 PSC devices. Enable UART support for all of
them by defining the number of max. PSCs depending on
selection of PPC_MPC512x platform support.
Signed-off-by: Anatolij Gustschin ag...@denx.de
Cc: Grant
On Fri, Feb 5, 2010 at 1:32 PM, Anton Vorontsov
avoront...@ru.mvista.com wrote:
This patch implements GPIOLIB notifier hooks, and thus makes device-enabled
GPIO chips (i.e. the ones that have gpio_chip-dev specified) automatically
attached to the OpenFirmware subsystem. Which means that now we
On Fri, Feb 5, 2010 at 1:32 PM, Anton Vorontsov
avoront...@ru.mvista.com wrote:
This patch implements GPIOLIB notifier hooks, and thus makes device-enabled
GPIO chips (i.e. the ones that have gpio_chip-dev specified) automatically
attached to the OpenFirmware subsystem. Which means that now we
On Fri, Feb 5, 2010 at 1:32 PM, Anton Vorontsov
avoront...@ru.mvista.com wrote:
Some platforms (e.g. OpenFirmware) want to know when a particular chip
added or removed, so that the platforms could add their specifics for
non-platform devices, like I2C or SPI GPIO chips.
This patch implements
On Fri, Feb 5, 2010 at 1:50 PM, Anton Vorontsov
avoront...@ru.mvista.com wrote:
So far of_node_init() just initializes a kref, later we'll have to
initialize other fields (for example node-data_lock).
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
arch/microblaze/kernel/prom.c
On Fri, Feb 5, 2010 at 1:50 PM, Anton Vorontsov
avoront...@ru.mvista.com wrote:
Platform code use node-data to store some private information
associated with a node.
Previously there was no need for any locks and accessors since we were
initializing the data mostly at boot time and never
On Fri, Feb 5, 2010 at 1:50 PM, Anton Vorontsov
avoront...@ru.mvista.com wrote:
OF GPIO infrastructure is using dynamic GPIO bases, so it is possible
that of_get_gpio()'s returned GPIO number will be no longer valid, or
worse, it may point to an unexpected GPIO controller.
This scenario is
On Tue, Feb 9, 2010 at 2:40 AM, Michal Simek michal.si...@petalogix.com wrote:
Anton Vorontsov wrote:
Hi all,
OF GPIO infrastructure is using dynamic GPIO bases, so it is possible
that of_get_gpio()'s returned GPIO number will be no longer valid, or
worse, it may point to an unexpected GPIO
On Thu, Jan 28, 2010 at 6:25 AM, Wolfgang Grandegger w...@grandegger.com
wrote:
From: Wolfgang Grandegger w...@denx.de
__devinit[data] has not yet been used for all initialization functions
and data. To avoid truncating lines, the struct mpc_i2c_match_data has
been renamed to mpc_i2c_data,
On Thu, Jan 28, 2010 at 6:25 AM, Wolfgang Grandegger w...@grandegger.com
wrote:
From: Wolfgang Grandegger w...@denx.de
The setclock initialization functions have been renamed to setup
because I2C interrupts must be enabled for the MPC512x. This requires
to handle fsl,preserve-clocking in a
On Thu, Jan 28, 2010 at 6:25 AM, Wolfgang Grandegger w...@grandegger.com
wrote:
From: Wolfgang Grandegger w...@denx.de
This patch adds the MPC5121 to the list of supported devices,
enhances the doc of the clock-frequency property and removes
the obsolete cell-index property from the example
Hi Grant,
Grant Likely wrote:
On Thu, Jan 28, 2010 at 6:25 AM, Wolfgang Grandegger w...@grandegger.com
wrote:
From: Wolfgang Grandegger w...@denx.de
This patch adds the MPC5121 to the list of supported devices,
enhances the doc of the clock-frequency property and removes
the obsolete
On Tue, Feb 09, 2010 at 10:40:53AM +0100, Michal Simek wrote:
[...]
The above situation is hard to trigger, but the issue is there
nonetheless, and so needs fixing.
I tested xilinx gpio driver, heartbeat trigger and access through
sysfs and I haven't found any problem. There is only small
On Tue, Feb 09, 2010 at 10:08:00AM -0700, Grant Likely wrote:
On Fri, Feb 5, 2010 at 1:32 PM, Anton Vorontsov
avoront...@ru.mvista.com wrote:
This patch implements GPIOLIB notifier hooks, and thus makes device-enabled
GPIO chips (i.e. the ones that have gpio_chip-dev specified) automatically
On Tue, Feb 09, 2010 at 10:25:22AM -0700, Grant Likely wrote:
On Fri, Feb 5, 2010 at 1:50 PM, Anton Vorontsov
avoront...@ru.mvista.com wrote:
Platform code use node-data to store some private information
associated with a node.
Previously there was no need for any locks and accessors
On Tue, Feb 09, 2010 at 10:13:11AM -0700, Grant Likely wrote:
[...]
+static int __init of_gpio_notifier_init(void)
+{
+ return blocking_notifier_chain_register(gpio_notifier,
of_gpio_nb);
+}
+arch_initcall(of_gpio_notifier_init);
Another concern; if any gpio chips get
Wolfgang Grandegger wrote:
Hi Grant,
Grant Likely wrote:
On Thu, Jan 28, 2010 at 6:25 AM, Wolfgang Grandegger w...@grandegger.com
wrote:
From: Wolfgang Grandegger w...@denx.de
This patch adds the MPC5121 to the list of supported devices,
enhances the doc of the clock-frequency property
From: Anatolij Gustschin ag...@denx.de
Date: Tue, 9 Feb 2010 15:23:17 +0100
In my understanding, in the ESP scsi driver the set of defines for
the register offsets is common for all chip drivers. The chip driver
methods for register access translate the offsets because the
registers on some
These changes add MDIO and phy lib support to the driver as the
IP core now supports the MDIO bus.
The MDIO bus and phy are added as a child to the emaclite in the device
tree as illustrated below.
mdio {
#address-cells = 1;
#size-cells = 0;
phy0: p...@7 {
The support for mpc5121 PSC UART currently only works with
serial console. This patch series re-enable PSC UART support for
all 12 PSCs and document added DTS bingings.
Anatolij Gustschin (3):
serial: mpc52xx_uart: re-enable mpc5121 PSC UART support
powerpc: doc/dts-bindings: document mpc5121
Currently the support for MPC5121 PSC UART in the mpc52xx_uart
driver is broken (only console pre-initialized by the bootloader
works). Re-enable it now by providing MPC5121 specific ops
for PSCx clock activation, FIFO controller init/uninit and
MPC5121 PSC FIFO shared interrupt handling
Support for MPC5121 PSC UART in the mpc52xx_uart driver
added new DTS properties for FSL MPC5121 PSC FIFO Controller.
Provide documentation of the new properties and some examples.
Signed-off-by: Anatolij Gustschin ag...@denx.de
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
No changes
MPC5121 has 12 PSC devices. Enable UART support for all of
them by defining the number of max. PSCs depending on
selection of PPC_MPC512x platform support.
Signed-off-by: Anatolij Gustschin ag...@denx.de
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
No changes since v1.
On Tue, 09 Feb 2010 19:59:27 +1100
Michael Neuling mi...@neuling.org wrote:
+ /* Initial stack must not cause stack overflow. */
+ if (stack_expand stack_expand_lim)
+ stack_expand = stack_expand_lim;
#ifdef CONFIG_STACK_GROWSUP
- stack_base = vma-vm_end +
note: it's untested.
Works for me on ppc64 with 4k and 64k pages. Thanks!
I'd still like someone with a CONFIG_STACK_GROWSUP arch to test/ACK it
as well.
There's only one CONFIG_GROWSUP arch - parisc.
Guys, here's the rolled-up patch.
FYI the rolled up patch still works
Greg, since this touches powerpc stuff, do you mind if I pick up the
series into my tree?
Thanks,
g.
On Tue, Feb 9, 2010 at 2:13 PM, Anatolij Gustschin ag...@denx.de wrote:
The support for mpc5121 PSC UART currently only works with
serial console. This patch series re-enable PSC UART support
On 02/09/2010 10:51 PM, Michael Neuling wrote:
I'd still like someone with a CONFIG_STACK_GROWSUP arch to test/ACK it
as well.
There's only one CONFIG_GROWSUP arch - parisc.
Could someone please test it on parisc?
I did.
How about doing:
'ulimit -s 15; ls'
before and after the patch is
Hi John,
Sorry If I'm painting bike-sheds here, just one tiny tweak might be in
order to standardise your mutex_unlock exit path:
+static int xemaclite_mdio_read(struct mii_bus *bus, int phy_id, int reg)
+{
+ struct net_local *lp = bus-priv;
+ u32 ctrl_reg;
+ u32 rc;
+
+
-Original Message-
From: John Williams [mailto:john.willi...@petalogix.com]
Sent: Tuesday, February 09, 2010 3:30 PM
To: John Linn
Cc: net...@vger.kernel.org; linuxppc-...@ozlabs.org; jgar...@pobox.com;
grant.lik...@secretlab.ca;
jwbo...@linux.vnet.ibm.com; Sadanand Mutyala
On Tue, Feb 09, 2010 at 03:18:57PM -0700, Grant Likely wrote:
Greg, since this touches powerpc stuff, do you mind if I pick up the
series into my tree?
No objection at all, feel free to add an:
Acked-by: Greg Kroah-Hartman gre...@suse.de
to the patches.
thanks,
greg k-h
-Original Message-
From: John Williams [mailto:john.willi...@petalogix.com]
Sent: Tuesday, February 09, 2010 3:30 PM
To: John Linn
Cc: net...@vger.kernel.org; linuxppc-...@ozlabs.org; jgar...@pobox.com;
grant.lik...@secretlab.ca;
jwbo...@linux.vnet.ibm.com; Sadanand Mutyala
Hi,
On Fri, Feb 05, 2010 at 02:42:48PM +0100, Anatolij Gustschin wrote:
Add reset module registers representation and
machine restart callback for mpc5121 platform.
Two comments:
Signed-off-by: Piotr Ziecik ko...@semihalf.com
Signed-off-by: Wolfgang Denk w...@denx.de
Signed-off-by:
On Tue, Feb 9, 2010 at 4:00 PM, John Linn john.l...@xilinx.com wrote:
-Original Message-
From: John Williams [mailto:john.willi...@petalogix.com]
Sent: Tuesday, February 09, 2010 3:30 PM
To: John Linn
Cc: net...@vger.kernel.org; linuxppc-...@ozlabs.org; jgar...@pobox.com;
On Fri, Feb 5, 2010 at 6:42 AM, Anatolij Gustschin ag...@denx.de wrote:
Add reset module registers representation and
machine restart callback for mpc5121 platform.
Signed-off-by: Piotr Ziecik ko...@semihalf.com
Signed-off-by: Wolfgang Denk w...@denx.de
Signed-off-by: Anatolij Gustschin
On Fri, Feb 5, 2010 at 6:42 AM, Anatolij Gustschin ag...@denx.de wrote:
Add support for MPC5121 real time clock module.
Signed-off-by: John Rigby jcri...@gmail.com
Signed-off-by: Piotr Ziecik ko...@semihalf.com
Signed-off-by: Wolfgang Denk w...@denx.de
Signed-off-by: Anatolij Gustschin
On Fri, Feb 5, 2010 at 6:42 AM, Anatolij Gustschin ag...@denx.de wrote:
From: Piotr Ziecik ko...@semihalf.com
Adds initial version of MPC512x DMA driver.
Only memory to memory transfers are currenly supported.
Signed-off-by: Piotr Ziecik ko...@semihalf.com
Signed-off-by: Wolfgang Denk
Recent versions of the PowerPC architecture added a hint bit to the larx
instructions to differentiate between an atomic operation and a lock operation:
0 Other programs might attempt to modify the word in storage addressed by EA
even if the subsequent Store Conditional succeeds.
1 Other
On Wed, Feb 10, 2010 at 01:50:11PM +1100, Anton Blanchard wrote:
Recent versions of the PowerPC architecture added a hint bit to the larx
instructions to differentiate between an atomic operation and a lock operation:
0 Other programs might attempt to modify the word in storage addressed by EA
Hi,
Perhaps this is my misunderstanding, but I'm looking at the bit of
code in of_irq_map_raw() that iterates the interrupt-map DTS node,
which I am seeing to behave strangely when handling the interrupt-map
property on a PCI bridge node.
Early in the function, we get the #address-cells value
Hi Linus !
Here's a fix for a nasty regression that went in this release cycle
and breaks 64K pages on HW that only does 4K such as 970's.
Cheers,
Ben.
The following changes since commit ac73fddfc523bf3c3525d16356b44527c44fae6d:
Linus Torvalds (1):
Merge branch 'for-linus' of
On 02/09/2010 10:51 PM, Michael Neuling wrote:
I'd still like someone with a CONFIG_STACK_GROWSUP arch to test/ACK it
as well.
There's only one CONFIG_GROWSUP arch - parisc.
Could someone please test it on parisc?
I did.
How about doing:
'ulimit -s 15; ls'
before and after
In message 20100210141016.4d18.a69d9...@jp.fujitsu.com you wrote:
On 02/09/2010 10:51 PM, Michael Neuling wrote:
I'd still like someone with a CONFIG_STACK_GROWSUP arch to test/ACK it
as well.
There's only one CONFIG_GROWSUP arch - parisc.
Could someone please test it on parisc?
In message 20100210141016.4d18.a69d9...@jp.fujitsu.com you wrote:
On 02/09/2010 10:51 PM, Michael Neuling wrote:
I'd still like someone with a CONFIG_STACK_GROWSUP arch to test/ACK it
as well.
There's only one CONFIG_GROWSUP arch - parisc.
Could someone please test it on parisc?
53 matches
Mail list logo
