We have built some custom hardware based on a PPC440EPx. I saw
an oops that doesn't make much sense to me, so I'd like to ask
folks if this smells more like a hardware problem than a software
problem.
The oops is a signal 4 in kernel mode (trap 700). If I'm
interpreting this correctly, it is a
Lixin Yao wrote:
Hello, Steven,
I realized that and made change, I use reg-shift of 1 which u-boot uses
and works for the CF.
local...@f0010100 {
#address-cells = 2;
#size-cells = 1;
compatible = fsl,mpc8248-localbus,
Lixin Yao wrote:
Steven/Aaron,
I found the problem. On my board, the CF is on a 16 bit interface on bus
of MPC8248. The HW is connected in Big Endian format. PPC Bit D0 is
connected to CF Bit D15, and PPC D1 to CF Bit D14, till PPC D0 to CF
D15. I had to swap the bytes in u-boot. I forgot
Lixin Yao wrote:
I redefined io functions in libata-sff.c, byte operations are converted
to 16bit word operations. Maybe I should ask for HW changes in new
revisions of the board.
I do recommend that. We got it wrong on our first board too. :-) It
is much better to get the hardware right
On Wed, Apr 01, 2009 at 01:20:49PM -0400, Herrera-Bendezu, Luis wrote:
I am working on a PPC440EPx board with some FPGAs located at
addresses above 4 GB
Cc'ing the PPC list, since they have the most experience with this
CPU, and may have some useful insights. The topic is UIO on the
We have built a new board based on the PPC440EPx. We are
using an SMII-mode phy for the ethernet.
The .dts file started as the one for Sequoia, and I have
changed the phy specifier to phy-mode = smii - I've also
removed the has-mdio property from RGMII0. The ethernet
is working in U-Boot, but
to boot failure.
Signed-off-by: Steven A. Falco sfa...@harris.com
---
Here is a partial log showing what happens in the
ibm4xx_denali_fixup_memsize routine. This board has
128 Mbytes of RAM in a 32-bit wide configuration, but
the REDUC bug causes the path width to report as 8,
and the memory size
Valentine Barshak wrote:
Josh Boyer wrote:
On Thu, Apr 23, 2009 at 06:40:48PM +0400, Valentine Barshak wrote:
Stefan Roese wrote:
On Thursday 23 April 2009, Josh Boyer wrote:
On Thu, Apr 23, 2009 at 09:36:12AM -0400, Steven A. Falco wrote:
There is an error in the way
, DDR_MAX_ROW_REG_SHIFT);
+ cs = ibm4xx_denali_get_cs();
if (!cs)
fatal(No memory installed\n);
if (cs max_cs)
Thanks for doing this so quickly!
I applied your patch plus my patch - my custom board reports
the correct memory size. Therefore,
Acked-by: Steven A. Falco
Josh Boyer wrote:
On Fri, Apr 24, 2009 at 12:04:39AM +0400, Valentine wrote:
Thanks Steven,
Yes, both patches have to be applied.
Sorry, I missed a trailing space in the comment.
I'll resubmit another one in a bit.
Thanks,
Val.
Could you roll both patches into one, and include Steven's
+static inline void emac_rx_clk_default(struct emac_instance *dev)
+{
+ if (emac_has_feature(dev, EMAC_FTR_440EP_PHY_CLK_FIX)) {
+ unsigned long flags;
+
+ local_irq_save(flags);
+ mtdcri(SDR0, SDR0_MFR, mfdcri(SDR0, SDR0_MFR)
+
I am using a recent DENX git tree. I want to enable debugging in prom_parse.c.
When I do that, I see link warnings like:
WARNING: drivers/net/ibm_newemac/ibm_newemac.o(.data+0x6e0): Section mismatch
in reference from the variable emac_of_bus_notifier to the function
Hi - I have found a bug in the ARCH=powerpc Walnut BSP. The order of
the ethernet interrupts in the walnut.dts file doesn't match the
documentation. I discovered this when porting the BSP to a custom board
- the ethernet would not work. The attached patch corrects that.
This is the first
I realized that I should have done this from the root level. So here is
the corrected patch.
Signed-off-by: Steve Falco sfalco at harris.com
Steven A. Falco wrote:
Hi - I have found a bug in the ARCH=powerpc Walnut BSP. The order of
the ethernet interrupts in the walnut.dts file doesn't
Could you redo the patch with just this bit and send it again?
josh
Ok - this one is based off the Linus tree, and follows your style of one
interrupt per line, with a comment indicating which one it is.
Signed-off-by: Steve Falco sfalco at harris.com
diff --git
fails
[POWERPC] Device tree bindings for Xilinx devices
[POWERPC] Uartlite: speed up console output
[POWERPC] ppc405 Fix arithmatic rollover bug when memory size under 16M
Roel Kluin (1):
[POWERPC] allocation fix in ppc/platforms/4xx/luan.c
Steven A. Falco (1
I am attempting to access the CPLD on the AMCC Sequoia board from
user-land. I open /dev/mem, and mmap it, then try to access the
resulting pointer. That works fine when accessing physical addresses
that correspond to RAM, but as soon as I try to access the CPLD at
physical address
If I cat /proc/iomem on a Sequoia board, it never stops printing. Here
are the first 10 lines:
bash-3.00# head -10 /proc/iomem
e100-e17f : usb
e100-e17f : musbhsfc_udc
e300-e38f : ehci_hcd
18000-18fff : /plb/[EMAIL PROTECTED]
1d000-1d0001fff :
I am using the Denx 2.6.32 kernel, which does have powerpc/sequoia.
Xenomai is a real-time kernel built on Adeos/Ipipe. I'll dig into it
further.
Steve
Josh Boyer wrote:
On Fri, 09 Nov 2007 13:30:03 -0500
Steven A. Falco [EMAIL PROTECTED] wrote:
If I cat /proc/iomem on a Sequoia
children. But one node, B, points to itself both as parent
and child. I believe this is the problem, but I haven't confirmed that,
nor have I determined how the list gets into this state.
Steve
Stefan Roese wrote:
Hi Steve,
On Friday 09 November 2007, Steven A. Falco wrote:
I am using
,
then cat /proc/iomem loops forever.
So, just a wild guess - should there be two struct resources, one for
each platform_device, or is there some other way to break the loop in
the tree?
Steve
Stefan Roese wrote:
Hi Steve,
On Friday 09 November 2007, Steven A. Falco wrote:
I am using
I have noticed odd behavior on a Sequoia board. Kernel is built from
DENX git, ARCH=powerpc, 2.6.23.1.
Sequence that works:
1) In u-boot, do dhcp (this initializes the PHY)
2) Boot linux from flash
3) ifconfig eth0 192.168.0.101 netmask 255.255.255.0 up
Ethernet is now functional, and I can
Roese wrote:
On Monday 26 November 2007, Steven A. Falco wrote:
I have noticed odd behavior on a Sequoia board. Kernel is built from
DENX git, ARCH=powerpc, 2.6.23.1.
Sequence that works:
1) In u-boot, do dhcp (this initializes the PHY)
2) Boot linux from flash
3) ifconfig eth0 192.168.0.101
opb_bus_freq value
14) [PATCH 2/3] PowerPC: ibm_newemac tah_ph typo fix
15) [PATCH 3/3] PowerPC: ibm_newemac call dev_set_drvdata() before tah_reset()
Steve
Benjamin Herrenschmidt wrote:
On Mon, 2007-11-26 at 14:10 -0500, Steven A. Falco wrote:
I've attached a copy of my bootlog. I added
I've written a simple program to mmap /dev/mem (attached).
It just displays a little physical memory beginning at
address 0. I wrote this as a test case - I'm trying to
debug a user-space driver, but I wanted to post the
simplest example that illustrates the problem.
This program runs properly
Steven A. Falco wrote:
Apologies - previous crash dump was mangled by the
interspersed program output. Here is one showing
just the crash dump.
Interestingly, the program does produce correct output,
as verified by dd'ing from /dev/mem to a file, then
doing od on the result. So in some sense
as a
final patch(34113).
On Mon, Mar 8, 2010 at 3:32 PM, Steven A. Falco sfa...@harris.com
mailto:sfa...@harris.com wrote:
Steven A. Falco wrote:
Apologies - previous crash dump was mangled by the
interspersed program output. Here is one showing
just the crash dump
I have a Kilauea board with one custom PCIE card plugged
into the PCIE1 slot. The custom card contains four PCI
devices which are connected via a PCIE-PCI bridge to the
Kilauea.
These devices need to communicate directly with each other.
This is done by telling each device the PCI bus address of
I have added a compact flash to the external bus of a Sequoia
(PPC440EPx) evaluation board. It is wired to CS1, and U-boot is set to
configure CS1 to be at address 0xc100. U-boot can access the
device, and reports the correct partition table, etc. so I believe the
hardware is ok.
I've
Benjamin Herrenschmidt wrote:
On Thu, 2008-08-07 at 15:56 -0400, Steven A. Falco wrote:
I have added a compact flash to the external bus of a Sequoia
(PPC440EPx) evaluation board. It is wired to CS1, and U-boot is set to
configure CS1 to be at address 0xc100. U-boot can access
I think there is a bug in the communications between pata_of_platform
and pata_platform. I will refer to the master branch of the DENX git
tree, which is roughly v2.6.26.1 at this time. I am using a Sequoia
board with a PPC440EPx.
In pata_of_platform, we have:
ret = of_irq_to_resource(dn,
, the check will be true for `-1'.
Reported-by: Steven A. Falco [EMAIL PROTECTED]
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
Thanks! Your fix is better - I didn't really like the -1 stuff.
I found this bug because I had to disable the ATA interrupt on my system
in order to get a compact
will be true for `-1'.
Reported-by: Steven A. Falco [EMAIL PROTECTED]
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
On Mon, Aug 11, 2008 at 10:48:50AM -0400, Steven A. Falco wrote:
I think there is a bug in the communications between pata_of_platform
and pata_platform. I will refer
Benjamin Herrenschmidt wrote:
1. IDE status read does not work. (But am I understand correctly
that IDE works well if IRQ is unspecified? Then this is hardly
an issue.)
2. IDE interrupt comes when it should not. I'd recommend to use
oscilloscope to find out what is happening
Anton Vorontsov wrote:
On Tue, Aug 12, 2008 at 06:18:42PM +0400, Sergei Shtylyov wrote:
Anton Vorontsov wrote:
1. IDE status read does not work. (But am I understand correctly
that IDE works well if IRQ is unspecified? Then this is hardly
an issue.)
2. IDE interrupt comes when
I have just tried enabling I2C on a Sequoia board (kernel is DENX 2.6.26) and
doing that appears to corrupt the u-boot / kernel communications.
Prior to turning on I2C, I see the ethernet mac and kernel command line
correctly passed, but once I turn on I2C, the ethernet mac becomes 0 and the
Valentine Barshak wrote:
Stefan Roese wrote:
On Thursday 21 August 2008, Sean MacLennan wrote:
That's all output from the wrapper, not the kernel. And the kernel
config doesn't make a difference at all to the wrapper. I wonder if
there is some weird size issue going on there or if
I'm using DENX-2.6.26, and I've enabled the I2C_IBM_IIC on a Sequoia board,
but I don't see any probes happening.
It looks like of_register_i2c_devices is never being called. According to
cscope, it would be called in i2c-ibm_of.c, but that file is not part of
the build.
i2c-ibm_of.c would be
The following patch enables building the I2C driver for 4xx chips.
Tested on a Sequoia board. Comments invited.
Signed-off-by: Steven A. Falco [EMAIL PROTECTED]
---
drivers/i2c/busses/Kconfig |7 +++
drivers/i2c/busses/i2c-ibm_of.c |5 ++---
2 files changed, 9 insertions(+), 3
Stefan Roese wrote:
On Thursday 21 August 2008, Sean MacLennan wrote:
On Thu, 21 Aug 2008 13:06:24 -0400
Steven A. Falco [EMAIL PROTECTED] wrote:
However, while the i2c-ibm_of.c driver works with the sequoia .dts,
i2c-ibm_iic.c does not, because it is looking for an index property,
which
Alan Stern wrote:
Your original post mentioned that the 440EPx has only one USB 2.0 host
port. Then how can you use a keyboard and memory stick at the same
time? You'd have to plug them into a hub -- in which case only one
controller would be needed, the one driving the hub. The patch would
Alan Stern wrote:
On Thu, 28 Aug 2008, Steven A. Falco wrote:
Alan Stern wrote:
Your original post mentioned that the 440EPx has only one USB 2.0 host
port. Then how can you use a keyboard and memory stick at the same
time? You'd have to plug them into a hub -- in which case only one
The yosemite.dts has the following entry, which leads me to believe
that there is SPI support. I'd like to do something similar for a
Sequoia board, but looking in Josh's next branch, I don't see any
driver that would recognize the spi-440ep string. So my question is,
is there a SPI driver for
SIOCGMIIREG and SIOCSMIIREG access a user data structure via a void
pointer to user space. So, we need copy_from_user and copy_to_user
to move the data.
Signed-off-by: Steven A. Falco sfa...@harris.com
---
I believe there is a bug in the way the ibm_newemac driver handles the
SIOCGMIIREG
On 06/10/2010 10:31 AM, Arnd Bergmann wrote:
On Thursday 10 June 2010, Steven A. Falco wrote:
I believe there is a bug in the way the ibm_newemac driver handles the
SIOCGMIIREG (and SIOCSMIIREG) ioctl. The problem is that emac_ioctl
is handed a struct ifreq *rq which contains a user-land
On 06/10/2010 01:03 PM, Arnd Bergmann wrote:
On Thursday 10 June 2010, Steven A. Falco wrote:
The ifreq structure passed into the ndo_ioctl function is in kernel
space, it gets copied there by net/core/dev.c:dev_ioctl().
emac_ioctl only accesses the data in that structure, so
I have begun writing a driver for the GPIOs of the PPC440EPx. I just
noticed that the PIKA Warp .dts references a device ibm,gpio-440ep,
but so far I have not been able to find a driver for that device.
So, here is what I have so far (patch is off 2.6.27-rc9). It is not
sufficiently general to
Here is the remainder of the driver - just the structure of the
registers for the 440EPx. I put the struct in this file because that
is similar to what was done for the mpc52xx, but the struct could go
elsewhere if more appropriate.
Anyway, I'd like some feedback on this driver, because I
Anton - thanks very much for your comments. I learned a lot, and I've
incorporated your suggestions into the driver, copy attached.
Stefan - hope I didn't step on your toes, but I was not aware you were
also working on this. Anyway, it seemed like a good place to make my
first significant
Thanks again for the comments. I followed the structure of your
qe_lib/gpio.c; here is the result. At this point, I've tested input
and output, so it is looking pretty good for me.
I added __init to the ppc4xx_gpio_save_regs because it looks like it is
only needed when first adding the gpios.
Please disregard the previous version, and consider this one instead.
The only difference is making better use of to_ppc4xx_gpiochip(), which
helps readability.
Signed-off-by: Steve Falco sfalco at harris.com
diff --git a/arch/powerpc/include/asm/ppc4xx.h
b/arch/powerpc/include/asm/ppc4xx.h
This patch adds support for the GPIO functions of PPC40x and PPC44x
SOCs.
Signed-off-by: Steve Falco sfalco at harris.com
---
I looked more closely at the datasheet. Stefan is correct that the
shadow registers are not needed for these processors, because they have
separate registers for input
This patch adds support for the GPIO functions of PPC40x and PPC44x
SOCs.
Signed-off-by: Steve Falco sfalco at harris.com
---
Changes from the previous version:
1) Removed !! from the input routine. I'll work up a separate patch for
sysfs to sanitize input.
2) Used the clr/set macros to
gpiolib can export GPIOs to userspace via sysfs. This patch modifies
the gpio_value_show() so that any non-zero value is explicitly printed
as 1, rather than whatever numerical value the lower-level driver returns.
Signed-off-by: Steve Falco sfalco at harris.com
---
diff --git
This patch adds support for the GPIO functions of PPC40x and PPC44x
SOCs.
Signed-off-by: Steve Falco [EMAIL PROTECTED]
Acked-by: Stefan Roese [EMAIL PROTECTED]
Acked-by: Sean MacLennan [EMAIL PROTECTED]
---
I believe I've satisfied all the comments that have been made for this
driver.
Josh - is
Anton Vorontsov wrote:
Hi all,
Recently there was a question about I2C GPIO controllers and how should
we handle them with the OpenFirmware and such.
Here is the attempt to connect I2C GPIO controllers to the
OpenFirmware device tree, without writing an OF-specific bindings
for each
I have an FPGA that will be on the PCI bus of a PPC440 processor.
The FPGA unfortunately can only have one PCI function (thus one
vendor/device code). The unfortunate part is that the FPGA has
several logical functions, that should have separate drivers.
Is there a way that I can break out the
on those processors since we already handle flushing
on execute in the page fault path.
This should provide a nice speed up ;-)
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
I'm running with your patch on a 440 Sequoia board, and it
works fine for me.
Acked-by: Steven A. Falco [EMAIL
Stefan Roese wrote:
This adds a SPI driver for the SPI controller found in the IBM/AMCC
4xx PowerPC's.
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
Signed-off-by: Wolfgang Ocker [EMAIL PROTECTED]
Acked-by: Josh Boyer [EMAIL PROTECTED]
---
I have a question as to how to use this driver.
Steven A. Falco wrote:
Stefan Roese wrote:
This adds a SPI driver for the SPI controller found in the IBM/AMCC
4xx PowerPC's.
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
Signed-off-by: Wolfgang Ocker [EMAIL PROTECTED]
Acked-by: Josh Boyer [EMAIL PROTECTED]
---
How is this intended
This patch adds a dummy GPIO driver, which is useful for SPI devices
that do not have a physical chip select.
Signed-off-by: Steven A. Falco sfa...@harris.com
---
The SPI subsystem requires a chip-select for each connected slave
device. I have a custom board with an Atmel co-processor
Anton Vorontsov wrote:
On Fri, Dec 12, 2008 at 09:22:02AM -0500, Steven A. Falco wrote:
This patch adds a dummy GPIO driver, which is useful for SPI devices
that do not have a physical chip select.
Hm. Then you don't need a chip-select, and SPI driver must understand
this case. When SPI
Anton Vorontsov wrote:
On Fri, Dec 12, 2008 at 11:59:13AM -0500, Steven A. Falco wrote:
Anton Vorontsov wrote:
On Fri, Dec 12, 2008 at 09:22:02AM -0500, Steven A. Falco wrote:
This patch adds a dummy GPIO driver, which is useful for SPI devices
that do not have a physical chip select.
Hm
Benjamin Herrenschmidt wrote:
On Mon, 2009-01-05 at 15:09 -0500, Steven A. Falco wrote:
I have a Sequoia board (440EPx) with kernel 2.6.27.9. I've recently
plugged in a PLX adapter board to convert one of the PCI connectors
on the Sequoia to PCIe.
When the kernel boots, I get the following
Benjamin Herrenschmidt wrote:
Here is a complete startup log, with debug turned on as you requested.
This is still against 2.6.27.9, as it will take me a little time to
build 2.6.28. Hopefully, this log will be useful in the meantime.
Can you add debug to your kernel command line option
Benjamin Herrenschmidt wrote:
Here is a complete startup log, with debug turned on as you requested.
This is still against 2.6.27.9, as it will take me a little time to
build 2.6.28. Hopefully, this log will be useful in the meantime.
Can you add debug to your kernel command line option
Steven A. Falco wrote:
Benjamin Herrenschmidt wrote:
Here is a complete startup log, with debug turned on as you requested.
This is still against 2.6.27.9, as it will take me a little time to
build 2.6.28. Hopefully, this log will be useful in the meantime.
Can you add debug to your kernel
Benjamin Herrenschmidt wrote:
On Tue, 2009-01-06 at 16:38 -0500, Steven A. Falco wrote:
But this has no effect on Linux. So, I also changed the sequoia.dts
to make the outbound range larger, and now Linux is happy too. I now
have ranges for the device:
# cat :01:00.0/resource
Benjamin Herrenschmidt wrote:
I'm not sure if this should be changed in the mainline. This card works
out of the box when used with a generic x86 PC, but not when used with
a sequoia. But, maybe it's just me climbing the PPC learning curve.
Nah, I think 256M is ridiculously small :-) I
I'm getting an error message when trying to talk to some custom hardware:
dx83xx 0001:43:00.0: device not available because of BAR 0
[0xa100-0xa1ff] collisions
I see in setup-res.c that this message comes out when there is no parent for
a device resource.
I've been digging around in
On 04/25/2011 08:01 PM, Benjamin Herrenschmidt wrote:
On Mon, 2011-04-25 at 16:10 -0400, Steven A. Falco wrote:
I'm getting an error message when trying to talk to some custom
hardware:
dx83xx 0001:43:00.0: device not available because of BAR 0
[0xa100-0xa1ff] collisions
I see
On 04/26/2011 07:39 PM, Benjamin Herrenschmidt wrote:
On Tue, 2011-04-26 at 09:38 -0400, Steven A. Falco wrote:
On 04/25/2011 08:01 PM, Benjamin Herrenschmidt wrote:
On Mon, 2011-04-25 at 16:10 -0400, Steven A. Falco wrote:
I'm getting an error message when trying to talk to some custom
On 04/26/2011 07:39 PM, Benjamin Herrenschmidt wrote:
On Tue, 2011-04-26 at 09:38 -0400, Steven A. Falco wrote:
On 04/25/2011 08:01 PM, Benjamin Herrenschmidt wrote:
On Mon, 2011-04-25 at 16:10 -0400, Steven A. Falco wrote:
I'm getting an error message when trying to talk to some custom
On 04/27/2011 03:51 PM, Steven A. Falco wrote:
On 04/26/2011 07:39 PM, Benjamin Herrenschmidt wrote:
On Tue, 2011-04-26 at 09:38 -0400, Steven A. Falco wrote:
On 04/25/2011 08:01 PM, Benjamin Herrenschmidt wrote:
On Mon, 2011-04-25 at 16:10 -0400, Steven A. Falco wrote:
I'm getting an error
On 04/28/2011 04:55 PM, Benjamin Herrenschmidt wrote:
On Thu, 2011-04-28 at 13:29 -0400, Steven A. Falco wrote:
On 04/27/2011 03:51 PM, Steven A. Falco wrote:
On 04/26/2011 07:39 PM, Benjamin Herrenschmidt wrote:
On Tue, 2011-04-26 at 09:38 -0400, Steven A. Falco wrote:
On 04/25/2011 08:01 PM
On 04/28/2011 05:14 PM, Benjamin Herrenschmidt wrote:
On Thu, 2011-04-28 at 17:11 -0400, Steven A. Falco wrote:
It is in __dev_sort_resources() in setup-bus.c
There is this test:
/* Don't touch classless devices or host bridges or ioapics. */
if (class == PCI_CLASS_NOT_DEFINED
David Brownell wrote:
On Tuesday 23 June 2009, Steven A. Falco wrote:
m25p80 spi0.0: invalid bits-per-word (0)
This message comes from spi_ppc4xx_setupxfer. I believe your patch
is doing what you intended (i.e. forcing an initial call to
spi_ppc4xx_setupxfer), but it exposes an OF / SPI
If a SPI transfer is set up, but does not explicitly set bits-per-word
and speed_hz, then the transaction fails, because spi_ppc4xx_setupxfer
rejects it.
This patch modifies the logic to chose the struct spi_transfer parameters
only if they are non-zero. Otherwise, the struct spi_device
Stefan Roese wrote:
On Wednesday 24 June 2009 16:25:20 Steven A. Falco wrote:
Speaking of spi_ppc4xx issues ... I still have an oldish
copy in my review queue, it needs something like the
appended patch. (Plus something to accept bpw == 0.)
Is there a newer version?
That is a question
David Brownell wrote:
On Wednesday 24 June 2009, Steven A. Falco wrote:
Your changes to bitbang_work look good.
You tested?
Yes - I built a kernel with your patch, combined with the changes I
just posted to linuxppc-...@ozlabs.org as:
[PATCH v1] Make spi_ppc4xx.c tolerate 0 bits-per-word
Stefan suggested that I try to address the comments against the PPC4xx
SPI driver, so here goes...
A post of version 7 of the driver will follow this email, but I thought
it might make it easier on everyone to inline my comments here. Hence,
this brief, introductory top post.
On Thursday 08
This adds a SPI driver for the SPI controller found in the IBM/AMCC
4xx PowerPC's.
Signed-off-by: Stefan Roese s...@denx.de
Signed-off-by: Wolfgang Ocker w...@reccoware.de
Acked-by: Josh Boyer jwbo...@linux.vnet.ibm.com
Signed-off-by: Steven A. Falco sfa...@harris.com
---
Note, I have not removed
David Brownell wrote:
On Thursday 25 June 2009, Steven A. Falco wrote:
+ if (spi-mode ~MODEBITS) {
+ dev_dbg(spi-dev, setup: unsupported mode bits %x\n,
+ spi-mode ~MODEBITS);
+ return -EINVAL;
+ }
This wasn't tested against
This adds a SPI driver for the SPI controller found in the IBM/AMCC
4xx PowerPC's.
Signed-off-by: Stefan Roese s...@denx.de
Signed-off-by: Wolfgang Ocker w...@reccoware.de
Acked-by: Josh Boyer jwbo...@linux.vnet.ibm.com
Signed-off-by: Steven A. Falco sfa...@harris.com
---
Changes in v8:
- Removed
84 matches
Mail list logo
