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
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
> 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
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 git://nei
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 fro
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 b
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 Fri, Feb 5, 2010 at 6:42 AM, Anatolij Gustschin wrote:
> From: Piotr Ziecik
>
> Adds initial version of MPC512x DMA driver.
> Only memory to memory transfers are currenly supported.
>
> Signed-off-by: Piotr Ziecik
> Signed-off-by: Wolfgang Denk
> Signed-off-by: Anatolij Gustschin
> Cc: Dan
On Fri, Feb 5, 2010 at 6:42 AM, Anatolij Gustschin wrote:
> Adds NAND Flash Controller driver for MPC5121 Revision 2.
> All device features, except hardware ECC and power management,
> are supported.
>
> Signed-off-by: Piotr Ziecik
> Signed-off-by: Wolfgang Denk
> Signed-off-by: Anatolij Gustsch
On Fri, Feb 5, 2010 at 6:42 AM, Anatolij Gustschin wrote:
> Add support for MPC5121 real time clock module.
>
> Signed-off-by: John Rigby
> Signed-off-by: Piotr Ziecik
> Signed-off-by: Wolfgang Denk
> Signed-off-by: Anatolij Gustschin
> Cc:
> Cc: Grant Likely
> Cc: John Rigby
Acked-by: Gra
On Fri, Feb 5, 2010 at 6:42 AM, Anatolij Gustschin wrote:
> Add reset module registers representation and
> machine restart callback for mpc5121 platform.
>
> Signed-off-by: Piotr Ziecik
> Signed-off-by: Wolfgang Denk
> Signed-off-by: Anatolij Gustschin
> Cc: Grant Likely
> Cc: John Rigby
> -
On Tue, Feb 9, 2010 at 4:00 PM, John Linn 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;
>> grant.lik...@secret
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
> Signed-off-by: Wolfgang Denk
> Signed-off-by: Anatolij Gustschin
> Cc: Gran
> -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
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 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;
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 a
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 wrote:
> The support for mpc5121 PSC UART currently only works with
> serial console. This patch series re-enable PSC UART support for
> all 12
On Tue, Feb 9, 2010 at 12:23 PM, Wolfgang Grandegger
wrote:
> Wolfgang Grandegger wrote:
>> Hi Grant,
>>
>> Grant Likely wrote:
>>> On Thu, Jan 28, 2010 at 6:25 AM, Wolfgang Grandegger
>>> wrote:
From: Wolfgang Grandegger
This patch adds the MPC5121 to the list of supported devi
> > > 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 pat
On Tue, 09 Feb 2010 19:59:27 +1100
Michael Neuling 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 + EXTRA_STACK_VM_P
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
Acked-by: Grant Likely
---
No changes since v1.
arch/powerpc/include/asm/mpc52xx_psc.h |4
1 fi
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
Acked-by: Grant Likely
---
No changes since v1.
.../powerpc/dts-bindings/fsl/mp
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 functions.
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
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 {
From: Anatolij Gustschin
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 chips are a
Wolfgang Grandegger wrote:
> Hi Grant,
>
> Grant Likely wrote:
>> On Thu, Jan 28, 2010 at 6:25 AM, Wolfgang Grandegger
>> wrote:
>>> From: Wolfgang Grandegger
>>>
>>> This patch adds the MPC5121 to the list of supported devices,
>>> enhances the doc of the "clock-frequency" property and removes
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 c
On Tue, Feb 09, 2010 at 10:28:15AM -0700, Grant Likely wrote:
[...]
> Rather than having a lock at the device tree data pointer level which
> mixes usage with potentially many other drivers; wouldn't it make more
> sense to use a mutex at the of_gc subsystem context?
I don't think so.
of_gc = np-
On Tue, Feb 09, 2010 at 10:25:22AM -0700, Grant Likely wrote:
> On Fri, Feb 5, 2010 at 1:50 PM, Anton Vorontsov
> 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
> >
On Tue, Feb 09, 2010 at 10:08:00AM -0700, Grant Likely wrote:
> On Fri, Feb 5, 2010 at 1:32 PM, Anton Vorontsov
> 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 t
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
Hi Grant,
Grant Likely wrote:
> On Thu, Jan 28, 2010 at 6:25 AM, Wolfgang Grandegger
> wrote:
>> From: Wolfgang Grandegger
>>
>> 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
On Thu, Jan 28, 2010 at 6:25 AM, Wolfgang Grandegger
wrote:
> From: Wolfgang Grandegger
>
> 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 nodes.
> Furthermore an
On Thu, Jan 28, 2010 at 6:25 AM, Wolfgang Grandegger
wrote:
> From: Wolfgang Grandegger
>
> 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 slighly different way.
On Thu, Jan 28, 2010 at 6:25 AM, Wolfgang Grandegger
wrote:
> From: Wolfgang Grandegger
>
> "__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", which is even the bett
On Tue, Feb 9, 2010 at 2:40 AM, Michal Simek 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 controller.
>
On Fri, Feb 5, 2010 at 1:50 PM, 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.
>
> This scenario is possible:
>
> driver A
On Fri, Feb 5, 2010 at 1:50 PM, Anton Vorontsov
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 modified it later.
>
>
On Fri, Feb 5, 2010 at 1:50 PM, Anton Vorontsov
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
> ---
> arch/microblaze/kernel/prom.c | 4 ++--
> arch/powerpc/ke
On Fri, Feb 5, 2010 at 1:32 PM, Anton Vorontsov
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 the notifier for chi
On Fri, Feb 5, 2010 at 1:32 PM, Anton Vorontsov
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 can handle
> I2C and
On Fri, Feb 5, 2010 at 1:32 PM, Anton Vorontsov
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 can handle
> I2C and
On Tue, Feb 2, 2010 at 12:47 AM, Anatolij Gustschin 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
> Cc: Grant Likely
> ---
> arch/powe
On Tue, Feb 2, 2010 at 12:47 AM, Anatolij Gustschin 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
> Cc: Grant L
On Tue, Feb 2, 2010 at 12:47 AM, Anatolij Gustschin 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 controller i
...according to gcc docs, sp should be global, or placement in
register is not guaranteed (except at asm boundaries, but there are
none).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://at
> -Original Message-
> From: glik...@secretlab.ca [mailto:glik...@secretlab.ca] On Behalf Of Grant
> Likely
> Sent: Tuesday, February 09, 2010 8:45 AM
> To: John Linn
> Cc: net...@vger.kernel.org; linuxppc-...@ozlabs.org; jgar...@pobox.com;
> jwbo...@linux.vnet.ibm.com;
> john.willi...@pe
On Mon, Feb 8, 2010 at 7:09 AM, John Linn wrote:
>> -Original Message-
>> From: John Linn [mailto:john.l...@xilinx.com]
>> Sent: Friday, February 05, 2010 3:41 PM
>> To: net...@vger.kernel.org; linuxppc-...@ozlabs.org;
> jgar...@pobox.com; grant.lik...@secretlab.ca;
>> jwbo...@linux.vnet.i
On Thu, 21 Jan 2010 18:03:11 -0800 (PST)
David Miller wrote:
> From: Wolfgang Grandegger
> 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
> defines for the register offsets, and
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 indica
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:
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 < \[PAT
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\:\
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 not
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 len
On Fri, 5 Feb 2010 14:42:46 +0100
Anatolij Gustschin 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
59 matches
Mail list logo
