On Fri, Nov 23, 2007 at 07:49:33PM -0500, Jeff Garzik wrote:
> Anton Vorontsov wrote:
> >Here is the PATA Platform driver using OF infrastructure.
> >
> >Mostly it's just a wrapper around a bit modified pata_platform
> >driver.
> >
> >Patches are well split for the easier review:
> >
> >First one f
It was the edk-derived driver for the uartlite.. The functionality is now
provided by the open source driver.
Steve
-Original Message-
From: [EMAIL PROTECTED] on behalf of Peter Korsgaard
Sent: Thu 11/22/2007 7:45 AM
To: Grant Likely
Cc: linuxppc-dev@ozlabs.org; Wolfgang Reissnegger
Su
On Fri, Nov 23, 2007 at 05:24:31PM -0700, Grant Likely wrote:
> From: Peter Korsgaard <[EMAIL PROTECTED]>
>
> Some multi-role (host/peripheral) USB controllers use a shared interrupt
> line for all parts of the chip. Export usb_hcd_irq so drivers can call it
> from their interrupt handler instead
On Fri, 23 Nov 2007, Grant Likely wrote:
> From: Grant Likely <[EMAIL PROTECTED]>
>
> This patch adds HDC support for the Cypress c67x00 family of devices.
>
> Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
> +static void c67x00_sched_done(unsigned long __c67x00)
> +{
> + struct c67x00_hcd
Thomas Klein wrote:
> Using own tx_packets counter instead of firmware counters.
>
> Signed-off-by: Thomas Klein <[EMAIL PROTECTED]>
>
> ---
> drivers/net/ehea/ehea.h |2 +-
> drivers/net/ehea/ehea_main.c |9 +++--
> 2 files changed, 8 insertions(+), 3 deletions(-)
applies 1-2
Benjamin Herrenschmidt wrote:
> The e1000 driver stores the content of the PCI resources into
> unsigned long's before ioremapping. This breaks on 32 bits
> platforms that support 64 bits MMIO resources such as ppc 44x.
>
> This fixes it by removing those temporary variables and passing
> directly
On Fri, 23 Nov 2007 20:52:29 +0300
Anton Vorontsov wrote:
> Hi all,
>
> Here is the PATA Platform driver using OF infrastructure.
>
> Mostly it's just a wrapper around a bit modified pata_platform
> driver.
>
> Patches are well split for the easier review:
>
> First one factors out platform_de
Benjamin Herrenschmidt wrote:
> It's a bad idea to call flush_scheduled_work from within a
> netdev->stop because the linkwatch will occasionally take the
> rtnl lock from a workqueue context, and thus that can deadlock.
>
> This reworks things a bit in that area to avoid the problem.
>
> Signed-
Benjamin Herrenschmidt wrote:
> Here are the patches I have pending for EMAC. With some non-released
> patches from Hugh Blemings, I get a taishan (440GX) booting now,
> in addition to Ebony (440GP) and various 405GP boards.
>
> This is 2.6.25 material except for patch #1 which has already been
>
On Fri, 2007-11-23 at 20:20 -0500, Jeff Garzik wrote:
> Benjamin Herrenschmidt wrote:
> > On Fri, 2007-11-23 at 22:07 +0300, Valentine Barshak wrote:
> >
> >> These patches have some minor ibm_newemac fixes.
> >
> > All 3 patches look good, thanks. I'll sign them off and forward them
> > to Jeff
On Fri, 2007-11-23 at 20:52 +0300, Anton Vorontsov wrote:
> As an alternative approach we can use plain pata_platform
> driver, but I'm not sure how Linux OF bindings' ideologists will
> or will not like it.
>
> So, these patches are strongly Request For Comments. Feel free
> to train your nitpi
Benjamin Herrenschmidt wrote:
> On Fri, 2007-11-23 at 22:07 +0300, Valentine Barshak wrote:
>
>> These patches have some minor ibm_newemac fixes.
>
> All 3 patches look good, thanks. I'll sign them off and forward them
> to Jeff in my next batch.
>
> Jeff, did you already pick up my previous dro
On Fri, 2007-11-23 at 22:07 +0300, Valentine Barshak wrote:
> These patches have some minor ibm_newemac fixes.
All 3 patches look good, thanks. I'll sign them off and forward them
to Jeff in my next batch.
Jeff, did you already pick up my previous drop of EMAC patches from last
week for .25 or
Anton Vorontsov wrote:
> Hi all,
>
> Here is the PATA Platform driver using OF infrastructure.
>
> Mostly it's just a wrapper around a bit modified pata_platform
> driver.
>
> Patches are well split for the easier review:
>
> First one factors out platform_device specific bits and modifies
> pa
From: Grant Likely <[EMAIL PROTECTED]>
add c67x00 driver to build
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
---
drivers/usb/Kconfig |2 ++
drivers/usb/Makefile|2 ++
drivers/usb/c67x00/Kconfig | 22 ++
drivers/usb/c67x00/Makefile | 14 +
From: Grant Likely <[EMAIL PROTECTED]>
This patch adds the low level support code for the Cypress c67x00 family of
OTG controllers. The low level code is responsible for register access and
implements the software protocol for communicating with the c67x00 device.
Signed-off-by: Grant Likely <[E
This patch series is based on the c67x00 work done by Peter Korsgaard and
posted back in April this year.
The Cypress c67x00 is an OTG controller so it can behave as either a host
or gadget controller. This series implements the HCD behaviour.
The c67x00 is found on a number of the Xilinx MLxxx
From: Peter Korsgaard <[EMAIL PROTECTED]>
Some multi-role (host/peripheral) USB controllers use a shared interrupt
line for all parts of the chip. Export usb_hcd_irq so drivers can call it
from their interrupt handler instead of duplicating code.
Drivers pass an irqnum of 0 to usb_add_hcd to signa
From: Grant Likely <[EMAIL PROTECTED]>
This patch adds HDC support for the Cypress c67x00 family of devices.
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
---
drivers/usb/c67x00/c67x00-hcd.c | 390
drivers/usb/c67x00/c67x00-hcd.h | 163 +
drivers/usb/c67x00/c67x00-sched
From: Grant Likely <[EMAIL PROTECTED]>
This patch add the core driver for the c67x00 USB OTG controller. The core
driver is responsible for the platform bus binding and creating either
USB HCD or USB Gadget instances for each of the serial interface engines
on the chip.
This driver does not dire
On Thu, 22 Nov 2007 17:54:03 +0100
Jochen Friedrich wrote:
> fs_enet and cpm_uart need symbols from commproc.c (for CPM1) or
> cpm2_common.c. Add EXPORT_SYMBOL for cpmp, cpm_setbrg and cpm2_immr,
> so the drivers can be compiled as modules.
>
I think this is not required. We are having very gross
On Fri, 2007-11-23 at 21:37 +0100, Johannes Berg wrote:
> Hi,
> > - 25: 18063968 MPIC 1Level VIA-PMU
> > + 25: 18064241 MPIC 1Level VIA-PMU
> > - 42:1415066 MPIC 1Level keywest i2c
> > - 47:2075159 MPIC 1Level GPIO1 ADB
> > - 48:6686659 M
Hi,
> % diff /proc/interrupts <(sleep 2; cat /proc/interrupts)
> --- /proc/interrupts2007-11-23 15:04:06.004846901 +0100
> +++ /proc/self/fd/112007-11-23 15:04:05.952841422 +0100
> @@ -1,15 +1,15 @@
> CPU0
> 21: 5 MPIC 1Edge PMac Output
> 24:
On 11/23/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> On 11/23/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> > On 11/22/07, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> > >
> > > On Thu, 2007-11-22 at 19:00 -0500, Jon Smirl wrote:
> > > > > It seems like AMCC does provide the necessary infos for
On 11/23/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> On 11/22/07, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> >
> > On Thu, 2007-11-22 at 19:00 -0500, Jon Smirl wrote:
> > > > It seems like AMCC does provide the necessary infos for 4xx
> > > processors
> > > > though. Jon, do you think what
The patch moves dev_set_drvdata(&ofdev->dev, dev) up before tah_reset(ofdev)
is called to avoid a NULL pointer dereference, since tah_reset uses drvdata.
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/tah.c |3 ++-
1 files changed, 2 insertions(+), 1 deletion
This patch fixes a typo in ibm_newemac/core.c
(tah_port should be used instead of tah_ph)
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/core.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -pruN linux-2.6.orig/drivers/net/ibm_newemac/core.c
li
The EMAC4_MR1_OBCI(freq) macro expects freg in MHz,
while opb_bus_freq is kept in Hz. Correct this.
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/core.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -pruN linux-2.6.orig/drivers/net/ibm_newemac/
These patches have some minor ibm_newemac fixes.
Thanks,
Valentine.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8349emitx.dts|9 +++--
arch/powerpc/platforms/83xx/mpc834x_itx.c | 17 +
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts
b/arch/pow
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
drivers/ata/Kconfig| 10 +
drivers/ata/Makefile |1 +
drivers/ata/pata_of_platform.c | 88
3 files changed, 99 insertions(+), 0 deletions(-)
create mode 100644 driver
Split pata_platform_{probe,remove} into two pieces:
1. pata_platform_{probe,remove} -- platform_device-dependant bits
2. __ptata_platform_{probe,remove} -- device type neutral bits.
This is done to not duplicate code for the OF-platform driver.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
-
Hi all,
Here is the PATA Platform driver using OF infrastructure.
Mostly it's just a wrapper around a bit modified pata_platform
driver.
Patches are well split for the easier review:
First one factors out platform_device specific bits and modifies
pata_platform to be a library-alike driver (wit
Hello
I have a custom 8349 ppc board. I have defined the spi master in the
configuration.
While booting my board, I driver is well added and linked to platform
bus, however I don't see that the probe entry point is reached.
I don't succeed to understand who is triggering the probe. Can someone
Hallo Johannes,
Johannes Berg <[EMAIL PROTECTED]> wrote:
> Doing some scripting to read /proc/stat every half second and print the
> differences, I get output like this on a mostly idle system:
>
> # for reference:
> # [user, nice, system, idle, iowait, irq, softirq, steal, guest]
>
> [4, 0, 3, 46
On 11/22/07, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2007-11-22 at 19:00 -0500, Jon Smirl wrote:
> > > It seems like AMCC does provide the necessary infos for 4xx
> > processors
> > > though. Jon, do you think what they provide is enough to use an open
> > > source debugger ?
Hi,
On my powerbook, with NO_HZ and HIGH_RES_TIMERS, I observed recently
that powernowd would not ever switch between CPU speeds.
Doing some scripting to read /proc/stat every half second and print the
differences, I get output like this on a mostly idle system:
# for reference:
# [user, nice, s
37 matches
Mail list logo
