Got it. The mpc52xx's still don't support interrupts i.e. reads require
polling.
As a consequence reads may time out.
But it doesn't prevent I2c from working.
Sorry for disturbing,
Eric Dujardin
---
Sagem DS - DP Combat Terrestre
178 rue de Paris - F-91344 Massy Cedex
> "Greg" == Greg KH <[EMAIL PROTECTED]> writes:
Greg> On Tue, Feb 19, 2008 at 04:09:19PM +0100, Peter Korsgaard wrote:
>> This patch adds HCD support for the Cypress c67x00 family of devices.
>>
>> Signed-off-by: Peter Korsgaard <[EMAIL PROTECTED]>
Greg> And it doesn't build:
Greg>
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 16bit
microcontroller inside the c67x00 device.
Communication is done over the HPI int
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 directly implement the HCD or gadget behavio
The Cypress c67x00 (EZ-Host/EZ-OTG) controllers are multi-role low/fullspeed
USB controllers. This patch series implements a HCD driver and shows the
work-in-progress status of a gadget driver.
I believe patch 1..3 are ready, and I would like to see them queued up for
mainline.
Changes since v7:
This patch adds HCD support for the Cypress c67x00 family of devices.
Signed-off-by: Peter Korsgaard <[EMAIL PROTECTED]>
---
drivers/usb/Makefile |2
drivers/usb/c67x00/Makefile| 11
drivers/usb/c67x00/c67x00-drv.c| 13
drivers/usb/c67x00/c67x00-hcd.c| 41
This patch adds USB gadget support for the Cypress c67x00 family of devices.
This is work in progress and not ready to be committed yet. I'm posting this
to show how it fits with the rest of the driver and to collect feedback.
The driver works good enought to use g_serial, but there are still iss
After the change to build images for several dts files the redboot image
failes to "wrap".
--
WRAParch/powerpc/boot/cuImage.adder875-uboot
DTC: dts->dtb on file ".../arch/powerpc/boot/dts/adder875-uboot.dts"
Image Name: Linux-2.6.25-rc2-00359-g101142c
Created: Wed Feb 20 10:38:21 20
Since the 4xx PCIe driver checks for 405ex compatibility, the
PCIe interface was not detected as it is currently defined as
"405exr" compatible. This patch changes it to "405ex".
The 405EX and 405EXr are identical exept that the 2nd PCIe and the
2nd EMAC interfaces are missing.
Signed-off-by: Ste
On Wed, Feb 20, 2008 at 11:56:35AM +1100, Paul Mackerras wrote:
> Andrew Morton writes:
>
> > Bizarrely, the original author of the patch (Anton) has fallen off the cc.
> > Could whoever did that please thwap himself?
> >
> > Anyway, my head is now officially spinning. Did anyone actually have
Hi,
I'm a little bit confused about the hash_native_64.c file, which is compiled
in the kernel, if PPC_NATIVE is defined. PPC_NATIVE seems to be defined also
for 32bit platforms (CHRP, PREP, etc.), but the name of the hash_native_64.c
file and the Makefile suggest that it is for 64bit platforms on
On Wed, 20 Feb 2008 11:45:58 +0100
Stefan Roese <[EMAIL PROTECTED]> wrote:
> Since the 4xx PCIe driver checks for 405ex compatibility, the
> PCIe interface was not detected as it is currently defined as
> "405exr" compatible. This patch changes it to "405ex".
>
> The 405EX and 405EXr are identica
On Wednesday 20 February 2008, Josh Boyer wrote:
> > Since the 4xx PCIe driver checks for 405ex compatibility, the
> > PCIe interface was not detected as it is currently defined as
> > "405exr" compatible. This patch changes it to "405ex".
> >
> > The 405EX and 405EXr are identical exept that the 2
then.
This oops is visible in the linux-next-20080220 kernel also.The machine is
power4+ box with four cpus and
has 30 GB RAM.
oops while running kernbench
-
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=32 NUMA pSeries
Modules linked in:
NIP
Paul Mackerras schrieb:
> Andrew Morton writes:
>
>> Bizarrely, the original author of the patch (Anton) has fallen off the cc.
>> Could whoever did that please thwap himself?
>>
>> Anyway, my head is now officially spinning. Did anyone actually have a
>> reason why we shouldn't proceed with Ant
Is the functionality provided by drivers/char/gen_rtc.c completely
handled by the rtc subsystem in drivers/rtc?
I ask for two reasons:
1. should we make it mutually exclusive in Kconfig
2. I've enabled both and get (we'll my defconfig did):
proc_dir_entry 'rtc' already registered
Call Trace:
[d
On Wed, Feb 20, 2008 at 10:07:28AM +0100, Peter Korsgaard wrote:
> 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 16bit
> microcon
On Wed, Feb 20, 2008 at 02:32:33AM +0300, Nikita V. Youshchenko wrote:
>
> powerpc: don't create two devices for each cpm_uart device tree node
>
> Code in arch/powerpc/sysdev/fsl_soc.c used to create two 'struct device'
> objects for each cpm_uart device tree node - one "fsl-cpm-
Thomas Klein wrote:
> This patch adds kdump support to the ehea driver. As the firmware doesn't free
> resource handles automatically, the driver has to run an as simple as possible
> free resource function in case of a crash shutdown. The function iterates over
> two arrays freeing all resource ha
On Wed, Feb 20, 2008 at 10:01:40AM +0100, Peter Korsgaard wrote:
> > "Greg" == Greg KH <[EMAIL PROTECTED]> writes:
>
> Greg> On Tue, Feb 19, 2008 at 04:09:19PM +0100, Peter Korsgaard wrote:
> >> This patch adds HCD support for the Cypress c67x00 family of devices.
> >>
> >> Signed-off-by:
On Wed, Feb 20, 2008 at 10:07:27AM +0100, Peter Korsgaard wrote:
> The Cypress c67x00 (EZ-Host/EZ-OTG) controllers are multi-role low/fullspeed
> USB controllers. This patch series implements a HCD driver and shows the
> work-in-progress status of a gadget driver.
>
> I believe patch 1..3 are read
> "Greg" == Greg KH <[EMAIL PROTECTED]> writes:
Greg> On Wed, Feb 20, 2008 at 10:07:27AM +0100, Peter Korsgaard wrote:
>> The Cypress c67x00 (EZ-Host/EZ-OTG) controllers are multi-role low/fullspeed
>> USB controllers. This patch series implements a HCD driver and shows the
>> work-in-prog
On Wed, Feb 20, 2008 at 05:57:06PM +0100, Peter Korsgaard wrote:
> > "Greg" == Greg KH <[EMAIL PROTECTED]> writes:
>
> Hi,
> Greg> I don't know, I selected the config option, and yet, it built
> Greg> as if it wasn't set.
>
> Sorry, I cannot reproduce that here. Could you try again?
I will
> "Greg" == Greg KH <[EMAIL PROTECTED]> writes:
Hi,
>> drivers/usb/c67x00/c67x00.h| 285 ++
Greg> Why not drivers/usb/hcd/c67x00/ instead?
Because the device can do both host and peripheral (E.G. see patch 4
in the series).
We could put it under hcd for no
> "Greg" == Greg KH <[EMAIL PROTECTED]> writes:
Hi,
Greg> I don't know, I selected the config option, and yet, it built
Greg> as if it wasn't set.
Sorry, I cannot reproduce that here. Could you try again?
Greg> Can you move the files under the hcd/ subdir
Sorry, I don't think that's a go
On Wed, 20 Feb 2008 10:11:23 -0600
Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> Is the functionality provided by drivers/char/gen_rtc.c completely
> handled by the rtc subsystem in drivers/rtc?
>
> I ask for two reasons:
> 1. should we make it mutually exclusive in Kconfig
> 2. I've enabled both
Scott Wood wrote:
> The lock acquisition in fs_ioctl() does not appear to actually be necessary,
> and thus is simply removed.
>
> Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
> ---
> This fixes the following bug:
> http://ozlabs.org/pipermail/linuxppc-dev/2008-February/051564.html
>
> drivers/
On Wed, Feb 20, 2008 at 05:59:36PM +0100, Peter Korsgaard wrote:
> > "Greg" == Greg KH <[EMAIL PROTECTED]> writes:
>
> Hi,
>
> >> drivers/usb/c67x00/c67x00.h| 285 ++
>
> Greg> Why not drivers/usb/hcd/c67x00/ instead?
>
> Because the device can do both host
On Wed, 20 Feb 2008 14:16:53 +0100
Stefan Roese <[EMAIL PROTECTED]> wrote:
> > > The 405EX and 405EXr are identical exept that the 2nd PCIe and the
> > > 2nd EMAC interfaces are missing.
> >
> > Does ppc405ex_pciex_core_init need to grow some logic to detect 405ex
> > from 405exr and return the co
On Mon, 2008-02-18 at 11:00 +0100, Jan-Bernd Themann wrote:
> Dave Hansen <[EMAIL PROTECTED]> wrote on 15.02.2008 17:55:38:
>
> > I've been thinking about that, and I don't think you really *need* to
> > keep a comprehensive map like that.
> >
> > When the memory is in a particular configuration
On Wednesday 20 February 2008, Greg KH wrote:
> > Greg> Can you move the files under the hcd/ subdir
>
> Oops, I ment "host/" not, "hcd/".
>
> > Sorry, I don't think that's a good idea as the hardware can do
> > peripheral as well, and as you can see in patch 4, a gadget driver is
> > on it's wa
I was running sparse on something else and noticed sparse warnings
and especially the bogus code that is fixed by the first hunk of
this patch, so I fixed them all while at it.
Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/
This fixes the following bug:
http://ozlabs.org/pipermail/linuxppc-dev/2008-February/051979.html
Separate defconfigs are no longer needed now that CONFIG_DEVICE_TREE is gone.
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
arch/powerpc/boot/wrapper |6 +-
arch/powe
On Wed, Feb 20, 2008 at 10:07:01AM -0800, David Brownell wrote:
> On Wednesday 20 February 2008, Greg KH wrote:
> > > ?Greg> Can you move the files under the hcd/ subdir
> >
> > Oops, I ment "host/" not, "hcd/".
> >
> > > Sorry, I don't think that's a good idea as the hardware can do
> > > periph
A property's data can be populated with a file's contents
as follows:
node {
prop = /incbin/("path/to/data");
};
A subset of a file can be included by passing start and size parameters.
For example, to include bytes 8 through 23:
node {
prop = /incbin/("path/to/data", 8, 16);
};
> "Greg" == Greg KH <[EMAIL PROTECTED]> writes:
>> Sorry, I cannot reproduce that here. Could you try again?
Greg> I will on the next round :)
Ok.
Greg> Can you move the files under the hcd/ subdir
Greg> Oops, I ment "host/" not, "hcd/".
Yeah, I guessed ;)
>> Sorry, I don't think th
The Cypress c67x00 (EZ-Host/EZ-OTG) controllers are multi-role low/fullspeed
USB controllers. This patch series implements a HCD driver and shows the
work-in-progress status of a gadget driver.
I believe patch 1..3 are ready, and I would like to see them queued up for
mainline.
Changes since v8:
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 16bit
microcontroller inside the c67x00 device.
Communication is done over the HPI int
This patch adds HCD support for the Cypress c67x00 family of devices.
Signed-off-by: Peter Korsgaard <[EMAIL PROTECTED]>
---
drivers/usb/Makefile |2
drivers/usb/c67x00/Makefile| 11
drivers/usb/c67x00/c67x00-drv.c| 13
drivers/usb/c67x00/c67x00-hcd.c| 41
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 directly implement the HCD or gadget behavio
This patch adds USB gadget support for the Cypress c67x00 family of devices.
This is work in progress and not ready to be committed yet. I'm posting this
to show how it fits with the rest of the driver and to collect feedback.
The driver works good enought to use g_serial, but there are still iss
On Wed, 2008-02-20 at 15:18 +0300, Anton Vorontsov wrote:
> On Wed, Feb 20, 2008 at 11:56:35AM +1100, Paul Mackerras wrote:
> > Andrew Morton writes:
> >
> > > Bizarrely, the original author of the patch (Anton) has fallen off the
> > > cc.
> > > Could whoever did that please thwap himself?
> >
Alessandro Zummo wrote:
> On Wed, 20 Feb 2008 10:11:23 -0600
> Kumar Gala <[EMAIL PROTECTED]> wrote:
>
>
>> Is the functionality provided by drivers/char/gen_rtc.c completely
>> handled by the rtc subsystem in drivers/rtc?
>>
>> I ask for two reasons:
>> 1. should we make it mutually exclusive
This is a note to let you know that I've just added the patch titled
Subject: POWERPC: fix typo in pseries/power.c
to my gregkh-2.6 tree. Its filename is
powerpc-fix-typo-in-pseries-power.c.patch
This tree can be found at
http://www.kernel.org/pub/linux/kernel/people/gregkh/gre
On Thu, Feb 21, 2008 at 10:32:25AM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> On Wed, 20 Feb 2008 13:57:27 -0800 <[EMAIL PROTECTED]> wrote:
> >
> > This is a note to let you know that I've just added the patch titled
> >
> > Subject: POWERPC: fix typo in pseries/power.c
> >
> > to my gre
Hi Greg,
On Wed, 20 Feb 2008 13:57:27 -0800 <[EMAIL PROTECTED]> wrote:
>
> This is a note to let you know that I've just added the patch titled
>
> Subject: POWERPC: fix typo in pseries/power.c
>
> to my gregkh-2.6 tree. Its filename is
>
> powerpc-fix-typo-in-pseries-power.c.patch
On Wed, 20 Feb 2008 15:37:28 -0500
woodys <[EMAIL PROTECTED]> wrote:
> On ARM genrtc has been arbitrary disabled in Kconfig circa 2.6.19 and
> the change to rtc_cmos it is not 100% transparent (ARM Netwinder, Debian).
> If I want to use a current (Etch) hwclock binary - I need genrtc with
> /dev
Setup i2c_board_info based on device tree contents. This has to be
a device_initcall since we need PCI to be probed by the time we
run it, but before the actual driver is initialized.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
---
This patch was posted previously, but not merged (by mys
Remove warning:
arch/powerpc/sysdev/mpic_pasemi_msi.c: In function 'pasemi_msi_setup_msi_irqs':
arch/powerpc/sysdev/mpic_pasemi_msi.c:135: warning: 'addr' is used
uninitialized in this function
Turns out addr wasn't even used, it's a leftover from the u3msi code.
Signed-off-by: Olof Johansson <
On Wednesday 20 February 2008, Peter Korsgaard wrote:
> +ifeq ($(CONFIG_USB_DEBUG),y)
> + EXTRA_CFLAGS+= -DDEBUG
> +endif
The canonical Sam Ravnborg comment is to replace that with:
+ccflags-$(CONFIG_USB_DEBUG)+= -DDEBUG
It's a newish idiom, most easily applied to new cod
Here's a set of updates for pasemi_mac for 2.6.26. Some of them touch
the dma_lib in the platform code as well, but it's easier if it's all
merged through netdev to avoid dependencies.
Major highlights are jumbo frame support and ethtool basics, the rest
is mostly minor plumbing around it.
--
_
Also stop both rx and tx sections before changing the configuration of
the dma device during init.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
Index: k.org/arch/powerpc/platforms/pasemi/dma_lib.c
===
--- k.org.orig/arch/powerpc
Used to allocate functions for crypto/checksum offload.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
Index: k.org/arch/powerpc/platforms/pasemi/dma_lib.c
===
--- k.org.orig/arch/powerpc/platforms/pasemi/dma_lib.c
+++ k.org/a
First cut at jumbo frame support. To support large MTU, one or several
separate channels must be allocated to calculate the TCP/UDP checksum
separately, since the mac lacks enough buffers to hold a whole packet
while it's being calculated.
Furthermore, it seems that a single function channel is no
Ethtool support will handle the runtime toggling, but we do quite a bit
better with it on by default so just leave it on for now.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
Index: k.org/drivers/net/pasemi_mac.c
===
--- k.org.
First cut at ethtool support, to be completed over time.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
Index: 2.6.25/drivers/net/Makefile
===
--- 2.6.25.orig/drivers/net/Makefile
+++ 2.6.25/drivers/net/Makefile
@@ -218,7 +218,8
Add functions to manage the channel syncronization flags to dma_lib
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
Index: k.org/arch/powerpc/platforms/pasemi/dma_lib.c
===
--- k.org.orig/arch/powerpc/platforms/pasemi/dma_lib.c
Kumar Gala writes:
> np. Are we trying to get this into 2.6.25 or .26?
I was going to put it into my powerpc-next branch and put it in
2.6.26. I don't see any need for it to go in 2.6.25.
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
ht
David Miller writes:
> I'm ambivalent but I would obviously prefer 2.6.25 because
> it would allow me to proceed more easily with my sparc64
> NUMA work as well as get your bug fixes in more smoothly.
Sounds like we should get Stephen to put it in linux-next-stable once
we're convinced it's all O
On Thu, 21 Feb 2008 13:15:58 +1100
Paul Mackerras <[EMAIL PROTECTED]> wrote:
> Kumar Gala writes:
>
> > np. Are we trying to get this into 2.6.25 or .26?
>
> I was going to put it into my powerpc-next branch and put it in
> 2.6.26. I don't see any need for it to go in 2.6.25.
Is that a new br
Gerhard Pircher writes:
> I'm a little bit confused about the hash_native_64.c file, which is compiled
> in the kernel, if PPC_NATIVE is defined. PPC_NATIVE seems to be defined also
> for 32bit platforms (CHRP, PREP, etc.), but the name of the hash_native_64.c
> file and the Makefile suggest that
Anton Vorontsov writes:
> > I was wondering if it would be sufficient to provide alternative
> > versions of fb_readl, fb_writel etc. that do byte-swapping.
>
> This is of course viable alternative. And I was considering this, but
> later I abandoned the idea: that way we'll end up doing math in
At Wed Feb 20 22:31:44 EST 2008, Johannes Berg wrote:
> I was running sparse on something else and noticed sparse warnings
> and especially the bogus code that is fixed by the first hunk of
> this patch, so I fixed them all while at it.
But your change is not equivalent!
> --- everything.orig/arc
> On Wed, Feb 20, 2008 at 02:32:33AM +0300, Nikita V. Youshchenko wrote:
> > powerpc: don't create two devices for each cpm_uart device tree
> > node
> >
> > Code in arch/powerpc/sysdev/fsl_soc.c used to create two 'struct
> > device' objects for each cpm_uart device tree node - one
> > "fs
> "David" == David Brownell <[EMAIL PROTECTED]> writes:
Hi,
David> +ccflags-$(CONFIG_USB_DEBUG)+= -DDEBUG
David> It's a newish idiom, most easily applied to new code before
David> it merges ... :)
Ok. I'll fix that.
David> And I realize that some of the drivers there have violat
65 matches
Mail list logo
