Kumar == Kumar Gala [EMAIL PROTECTED] writes:
Hi,
Kumar Also, any plans to follow this up with .dts updates to add the
Kumar GPIO block into the various files we have?
Yes, but I wanted to get the driver/dts bindings in the tree first.
--
Bye, Peter Korsgaard
Kumar == Kumar Gala [EMAIL PROTECTED] writes:
Kumar On Sep 21, 2008, at 2:46 PM, Peter Korsgaard wrote:
+GPIO controllers on MPC8xxx SoCs
+
+Every GPIO controller node must have #gpio-cells property defined,
+this information will be used to translate gpio-specifiers.
+
Kumar Can
Structured similar to the existing QE GPIO support.
Signed-off-by: Peter Korsgaard [EMAIL PROTECTED]
---
Changes since v2:
- Clarified documentation as requested by Kumar.
Changes since v1:
Incorporated feedback from Anton and Kumar:
- Core is also used on 8572/8610 so s/83xx/8xxx/
- Use
Dear Peter Korsgaard,
In message [EMAIL PROTECTED] you wrote:
From: peter Korsgaard [EMAIL PROTECTED]
Support uImage.platform, which are U-Boot multi component images
containing a kernel, dtb and possibly an initrd.
NAK.
Please do not add such a patch to mainline.
+ uImage.%:
Wolfgang == Wolfgang Denk [EMAIL PROTECTED] writes:
Hi,
Support uImage.platform, which are U-Boot multi component images
containing a kernel, dtb and possibly an initrd.
Wolfgang NAK.
Wolfgang Please do not add such a patch to mainline.
I agree that FIT images probably are the way to
Hello.
Jon Smirl wrote:
Implementing the poll_controller() method in the network driver is usually
staightforward.
Good tip, the simple implementation worked.
What controls this? carrier detect appears untrustworthy, waiting 4 seconds
IIRC, it happens if netpoll code sees the
Currently a SIGTRAP signal can denote any one of below reasons.
- Breakpoint hit
- H/W debug register hit
- Single step
- SIGTRAP signal sent through kill() or rasie()
Architectures like powerpc/parisc provides infrastructure to demultiplex
SIGTRAP signal by
* Srinivasa Ds [EMAIL PROTECTED] wrote:
Currently a SIGTRAP signal can denote any one of below reasons.
- Breakpoint hit
- H/W debug register hit
- Single step
- SIGTRAP signal sent through kill() or rasie()
Architectures like powerpc/parisc provides
Dear Peter,
In message [EMAIL PROTECTED] you wrote:
Wolfgang NAK.
Wolfgang Please do not add such a patch to mainline.
I agree that FIT images probably are the way to go for the future, but
I do think there's room for uImage.% just like we have cuImage.% for
really old uboots.
I
Hello, I wrote:
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index 4e4f683..72541b5 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -401,6 +401,16 @@ static int mpc52xx_fec_hard_start_xmit(struct
sk_buff *skb, struct net_device *d
return
Hello.
Benjamin Herrenschmidt wrote:
Implementing the poll_controller() method in the network driver is usually
staightforward.
Good tip, the simple implementation worked.
What controls this? carrier detect appears untrustworthy, waiting 4 seconds
Get that fixed and this patch could
Hello, I wrote:
What controls this? carrier detect appears untrustworthy, waiting 4
seconds
Get that fixed and this patch could be useful,
Does the driver properly uses netif_carrier_on/off to signal the
system when the link is up/down ?
Implementing the poll_controller() method in
Hello.
Jon Smirl wrote:
Does anyone have a solution to the problem of printk() to a serial
console blocking interrupts for too long? I'm losing interrupts I need
because my hardware is getting overrun.
It's a strange piece of hardware that loses interrupts on getting
overrun. :-)
On Monday 22 September 2008 16:12:02 Ingo Molnar wrote:
no fundamental objections - assuming existing x86 apps have not grown an
ABI dependency on the existing send_sigtrap() semantics. (Debuggers and
JITs would be a candidate for such dependencies.)
Assuming that no ABI dependency exist
On Mon, Sep 22, 2008 at 7:21 AM, Sergei Shtylyov
[EMAIL PROTECTED] wrote:
Hello.
Jon Smirl wrote:
Does anyone have a solution to the problem of printk() to a serial
console blocking interrupts for too long? I'm losing interrupts I need
because my hardware is getting overrun.
It's a
Hi,
my MPC5200 based platform has one PCI slot, with the following interrupt
routing:
PCI slot MPC5200
INT A IRQ0
INT B IRQ1
INT C IRQ2
INT D IRQ3
In my oftree I'm using these lines to describe this routing (slot's IDSEL is
0x18)
[...]
[EMAIL PROTECTED] {
Anton == Anton Vorontsov [EMAIL PROTECTED] writes:
Anton On Mon, Sep 22, 2008 at 08:32:34AM +0200, Peter Korsgaard wrote:
Structured similar to the existing QE GPIO support.
Signed-off-by: Peter Korsgaard [EMAIL PROTECTED]
Anton Looks good to me, thanks.
Anton Few comments below,
Hello, I wrote:
Not sure if Stephen was the right person to CC, including Matt now...
What controls this? carrier detect appears untrustworthy, waiting 4
seconds
Get that fixed and this patch could be useful,
Does the driver properly uses netif_carrier_on/off to signal the
system when
On Mon, Sep 22, 2008 at 10:39 AM, Sergei Shtylyov
[EMAIL PROTECTED] wrote:
Hello, I wrote:
Not sure if Stephen was the right person to CC, including Matt now...
What controls this? carrier detect appears untrustworthy, waiting 4
seconds
Get that fixed and this patch could be useful,
Does
* Srinivasa Ds [EMAIL PROTECTED] wrote:
--- linux-2.6.27-rc7.orig/arch/ia64/include/asm/siginfo.h
+++ linux-2.6.27-rc7/arch/ia64/include/asm/siginfo.h
please do not send patches that modify include/asm/ files, the
include/asm-x86/ file should be modified instead.
(this problem will go away
Jon Smirl wrote:
Not sure if Stephen was the right person to CC, including Matt now...
What controls this? carrier detect appears untrustworthy, waiting 4
seconds
Get that fixed and this patch could be useful,
Does the driver properly uses netif_carrier_on/off to signal the
system when
Structured similar to the existing QE GPIO support.
Signed-off-by: Peter Korsgaard [EMAIL PROTECTED]
---
Changes since v3:
- Incorporated feedback from Anton
Changes since v2:
- Clarified documentation as requested by Kumar.
Changes since v1:
Incorporated feedback from Anton and Kumar:
On Montag, 22. September 2008, Juergen Beisert wrote:
$ lspci
00:18.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1
Controller (rev 61) 00:18.1 USB Controller: VIA Technologies, Inc.
VT82x UHCI USB 1.1 Controller (rev 61) 00:18.2 USB Controller: VIA
Technologies, Inc. USB
Fix rtas_log_read() to correctly check its buffer after sleeping. A competing
process may have swiped the error we're attempting to retrieve between us being
woken up and retaking the lock, but we return an event and account for it
anyway without checking.
Any positive result from checking
I am having issues using LOAD_REG_ADDR and LOAD_REG_IMMEDIATE macros on a ppc64
kernel which I have tried on both 2.6.16 and 2.6.17 kernels.
I noticed that these macros by default loading value 0 instead of the actual
address. Is this a bug of the compiler that can be fixed, I noticed when I
Hello all,
I understood that the device-tree is for describing hardware and should
not contain driver specific information. I have problems drawing this
line right now. I made a driver for watchdogs which are pinged by
toggling a gpio. Currently the device-tree entry looks like this:
Juergen Beisert wrote:
Hi,
$ lspci
00:18.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1
Controller (rev 61)
00:18.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1
Controller (rev 61)
00:18.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 63)
USB driver
On Mon, 2008-09-22 at 15:11 +0400, Sergei Shtylyov wrote:
Hello, I wrote:
What controls this? carrier detect appears untrustworthy, waiting 4
seconds
Get that fixed and this patch could be useful,
Does the driver properly uses netif_carrier_on/off to signal the
system when
From: Kumar Gala [EMAIL PROTECTED]
Now that arch/ppc is dead CONFIG_PPC_MERGE is always defined for all
powerpc platforms and we want to get rid of CONFIG_PPC_MERGE use
CONFIG_PPC instead.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Cc: Paul Mackerras
On Mon, 2008-09-22 at 14:41 -0700, [EMAIL PROTECTED] wrote:
From: Kumar Gala [EMAIL PROTECTED]
Now that arch/ppc is dead CONFIG_PPC_MERGE is always defined for all
powerpc platforms and we want to get rid of CONFIG_PPC_MERGE use
CONFIG_PPC instead.
Signed-off-by: Kumar Gala [EMAIL
Jeremy,
Can we eliminate the linuxppc-embedded mailing list and merge it with
linuxppc-dev? I don't think we need two separate lists anymore and
patches to linuxppc-embedded don't always get dealt with.
Anyone have any objections to eliminating linuxppc-embedded?
g.
--
Grant Likely, B.Sc.,
On Mon, Sep 22, 2008 at 4:11 PM, Mike Frysinger [EMAIL PROTECTED] wrote:
On Mon, Sep 22, 2008 at 18:08, Grant Likely [EMAIL PROTECTED] wrote:
Jeremy,
Can we eliminate the linuxppc-embedded mailing list and merge it with
linuxppc-dev? I don't think we need two separate lists anymore and
I am trying to figure out what IRQ number I should use for
external IRQ pins IRQ2-4. Can somebody please drop me a note
on how the IRQ numbering works?
Jocke
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
Hi Grant,
Can we eliminate the linuxppc-embedded mailing list and merge it with
linuxppc-dev?
That's not really up to me - more of a community question I think. I
imagine Paul would have the final decision though.
Cheers,
Jeremy
___
Linuxppc-dev
On Fri, Sep 19, 2008 at 10:03:54PM +0400, Anton Vorontsov wrote:
On MPC8349E-mITX, MPC8315E-RDB and MPC837x-RDB boards there is a
Freescale MC9S08QG8 (MCU) chip with the custom firmware
pre-programmed. The chip is used to power-off the board by the
software, and to control some GPIO pins.
I
On Sep 22, 2008, at 6:09 PM, Jeremy Kerr wrote:
Hi Grant,
Can we eliminate the linuxppc-embedded mailing list and merge it with
linuxppc-dev?
That's not really up to me - more of a community question I think. I
imagine Paul would have the final decision though.
I'm pretty sure I saw paul
Hi Josh,
You need to look in the 'next' branch.
http://git.kernel.org/?p=linux/kernel/git/jwboyer/powerpc-4xx.git;a=tree;f=arch/powerpc/platforms/44x;h=c5cae8d37f170193ed45b7b76e3cb2cbb8be927a;hb=next
josh
I am not sure how to get your next branch.
I usually just use the following command.
On Mon, Sep 22, 2008 at 06:34:37PM -0500, Kumar Gala wrote:
Can we eliminate the linuxppc-embedded mailing list and merge it with
linuxppc-dev?
That's not really up to me - more of a community question I think. I
imagine Paul would have the final decision though.
I'm pretty sure I saw paul
It's a strange piece of hardware that loses interrupts on getting overrun.
:-)
The 4 second pause slows down the debug/test cycle a lot. I'm using a
net booted monolithic kernel on the hardware and using the reset
button every time I make a change.
I'm not going to have much feelings
On Mon, 2008-09-22 at 12:16 -0600, Mitesh R. Meswani wrote:
I am having issues using LOAD_REG_ADDR and LOAD_REG_IMMEDIATE macros
on a ppc64 kernel which I have tried on both 2.6.16 and 2.6.17
kernels.
I noticed that these macros by default loading value 0 instead of the
actual address. Is
40 matches
Mail list logo
