On Sun, 2008-09-21 at 09:19 +0800, Wang Jian wrote:
> The following patch works fine.
And will break platforms that explicitely want IO port 0 to be on the
primary bus, though I'm not sure there's many of these left...
Ben.
> diff --git a/arch/powerpc/kernel/pci-common.c
> b/arch/powerpc/kernel
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 addres
> > 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 fee
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 su
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 com
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
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.
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
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
https://ozlabs.org/mailman/listinfo
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 anymo
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., P.
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 <[EMAI
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 Mack
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 s
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 (end
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:
[EMA
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 di
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 rtas_l
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.
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:
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 t
* 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 aw
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 c
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 t
> "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
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] {
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.
>
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]>
Looks good to me, thanks.
Few comments below, might want to consider some of them if you want to.
> ---
> Changes since
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 b
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. :-)
WB
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.
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:
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 0;
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 ubo
* 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 infra
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 passing
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
> "Wolfgang" == Wolfgang Denk <[EMAIL PROTECTED]> writes:
Hi,
>> Support uImage., 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 wa
Dear Peter Korsgaard,
In message <[EMAIL PROTECTED]> you wrote:
> From: peter Korsgaard <[EMAIL PROTECTED]>
>
> Support uImage., 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.%: U
39 matches
Mail list logo
