On Tuesday 23 February 2010, Feng Tang wrote:
+config SERIAL_MAX3110
+ tristate SPI UART driver for Max3110
+ select SERIAL_CORE
+ select SERIAL_CORE_CONSOLE
Shouldn't that depend on SPI_MASTER? As it stands, you're
permitting it to build on systems that you *know* don't
On Tuesday 29 December 2009, Erwin Authried wrote:
I think there's no need for a MAX3100 **and** a MAX3110 driver, this is
just confusing. The MAX3110 driver is identical to the MAX3100 from the
software view, it is simply a MAX3100 with transceivers added to the
chip. If there's any
On Wednesday 24 February 2010, Feng Tang wrote:
Good point about the DW controller specific data, I'll remove them.
Good.
For those bits_per_word setting, I think we can put it here instead of
the board initialization code, as many types of boards can leverage the
setting here as it only
On Friday 26 February 2010, Masakazu Mokuno wrote:
+static int max3110_read_multi(struct uart_max3110 *max, u8 *buf)
+{
+ u16 obuf[M3110_RX_FIFO_DEPTH], ibuf[M3110_RX_FIFO_DEPTH];
Doing I/O on stack is guaranteed safe for spi functions?
Good catch ... no it's not safe.
No
On Tuesday 02 March 2010, Feng Tang wrote:
+ * 3. This driver doesn't support work with a spi cotnroller in DMA mode,
As Grant said: That's a bug ... one that will randomly
kick in based on whether the underlying SPI controller driver
happens to use DMA for a given transaction.
On Tuesday 02 March 2010, Feng Tang wrote:
On Wed, 3 Mar 2010 12:51:58 +0800
David Brownell davi...@pacbell.net wrote:
On Tuesday 02 March 2010, Feng Tang wrote:
+ * 3. This driver doesn't support work with a spi cotnroller in
DMA mode,
As Grant said: That's a bug ... one
On Tuesday 02 March 2010, Feng Tang wrote:
Here comes another idea, can we add a capability flag in struct
spi_master indicating the master supporting poll or dma or both.
Also we add similar bits in struct spi_transfer indicating the this
transfer wants to be handled in poll or dma
On Sunday 21 March 2010, christian pellegrin wrote:
Anybody know the right thing to do here?
when to register consoles is a general mess. I've seeen some
success in having it be board-specific data, at the level of
port 3 should be a console ... or in this case, maybe having
platform data say
--- On Sun, 5/30/10, Cory Maccarrone darkstar6...@gmail.com wrote:
I don't see the point in having a separate driver
for this chip ... it's just an updated ADS7846,
and the ads7846 driver has handled it for quite
a few years now, as I recall. There's no need for
second driver.
This driver
--- On Sat, 6/26/10, Grant Likely grant.lik...@secretlab.ca wrote:
Vitaly and David, can you please take
a look at this. You both know
this code better than I, and I'd like as second opinion.
(see my
comments below)
First fix $SUBJECT: it's not a generic SPI
issue, it's just for one
--- On Thu, 6/17/10, Marek Szyprowski m.szyprow...@samsung.com wrote:
From: Marek Szyprowski m.szyprow...@samsung.com
Subject: [PATCH 2/2] drivers: spi-gpio: add support for controllers without
MISO or MOSI pin
I basically like this pair of patches. I had a
very similar update a while
--- On Thu, 7/1/10, ananth ananth86cool...@gmail.com wrote:
I am learning the SPI framework in linux. I read the
spi-summary and
documentation. I couldn't get a clear picture of what's
happening. Is there
any other document or article which gives a overview of the
SPI framework in
No matter how much I look at it, it seems like
all use of this require you to first register
*some* device,
OBVIOUSLY. You can't use SPI without a device;
it's like any other driver framework in Linux.
What else should you expect???
Look at the sample code though, ISTR you'll see
that when
There are things wrong with the concept of this
particular patch. First, that it's mpc5121-only.
Second, that it's not already handled as part of
registering the platform's SPI devices.
--
The Palm PDK Hot Apps Program
Second, that it's not already handled as part of
registering the platform's SPI devices.
The reason is that in this use case
the platform code doesn't provide
a list of spi devices. The list of devices is
contained in the
flattened device tree, and the data is parsed
after the spi bus
--- On Tue, 7/27/10, Feng Tang feng.t...@intel.com wrote:
be delayed registering, can we adjust it to make
register_board_info()
be callable after spi controller is inited? Which makes spi
bus like
general pci/usb bus, where devices/drivers have no
registering order limit.
They require
--- On Tue, 7/27/10, Feng Tang feng.t...@intel.com wrote:
What I want to say is the matching mechanism between spi
board info
and spi master, currently they use bus number to match, but
there is
a ordering limit now. For general device/driver matching in
linux
device model, there is no
--- On Tue, 7/27/10, Feng Tang feng.t...@intel.com wrote:
know which spi_master it is connecting to, while our
platform need kind
of blind registering (just register something to spi-bus).
Sounding worse and worse. each device is going
to be connected to one specific controller, not
--- On Tue, 7/27/10, Feng Tang feng.t...@intel.com wrote:
In current spi core, spi_register_info() has to be
called before the spi controller driver call
spi_register_master(),
then these board info will be matched and used to create a new spi device.
But if spi_register_info() are
It's not all of drivrers/spi -- just one
specific driver. Please update $SUBJECT and
patch description to be more accurate.
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the
--- On Mon, 8/9/10, Grant Likely grant.lik...@secretlab.ca wrote:
+ nr_parts =
of_mtd_parse_partitions(spi-dev, np, parts);
Let's keep OF-specific logic out of drivers like
this one ... intended to work without OF.
NAK on adding dependencies like OF to drivers
and other
--- On Tue, 8/10/10, Grant Likely grant.lik...@secretlab.ca wrote:
This one bothers me, but I can't put my
finger on it. The flag feels
like a controller specific hack.
That's because it *IS* ...
Not clear what a good fix would look like.
But in general, SPI master controllers are
Is a SPI device as bitbanged over GPIO enough of
a real SPI device
that the spidev can be used for it?
Yes -- modulo bugs. The bitbanging would be via
the SPI master controller, and that's written to
be fairly close to a reference implementation.
and spidev is just one possible client.
--- On Wed, 9/1/10, Feng Tang feng.t...@intel.com wrote:
What's the case where platform code could
know better than the driver?
Grant also asked me the same question.
I saw him ask a different question (which
I quoted) ...
Yes, driver itself
know the bits_per_word info best in
You know, in retrospect, I shouldn't have put
most of those SPI device setup params into the
board setup data.
There's one which MUST be there: polarity of
the chip select line. The rest seem like they
could (and arguably should) all be handled by
driver-specific params. (Possible exception:
On Thu, 2010-10-21 at 21:06 +0200, Linus Walleij wrote:
Those things in the SPI core just strike me as particularly odd:
dev_dbg() used in an obvious error branch,
When debugging, that can be fine. return errcode... is how the error
gets reported; callers can handle that ... but they never
On Mon, 2010-10-18 at 15:25 -0400, Cyril Chemparathy wrote:
This patch adds a GPIO driver based on TI's SSP device. This driver does not
support GPIO-IRQs.
Doesn't look particularly evil, except I don't much like the notion of
needing a stack if it's not being used like an MFD where numerous
Doesn't look particularly evil, except I don't much
like the notion of
needing a stack if it's not being used
like an MFD where numerous
functions are accessed concurrently,
better IMO to just have each function's driver bind exclusively to the chip
(and
drive it in the
mode it
--- On Fri, 10/22/10, Grant Likely grant.lik...@secretlab.ca wrote:
We're quibbling over *bytes* in the
single digits in a multi-megabyte kernel.
The total size of printk messages
is indeed a problem, but it isn't going
to be solved by the
kind of micro-optimizations here.
True.
--- On Wed, 11/3/10, Linus Walleij linus.ml.wall...@gmail.com wrote:
\
Date: Wednesday, November 3, 2010, 3:18 AM
2010/11/3 David Brownell davi...@pacbell.net:
That seems like
a better structure for various vendors' SSP
hardware (multifunction serial interface logic)
Incidentally
I thought the point of this device was that a single [SSP] device
hosted a
pair of multi-function serial interfaces, with each
implementing a
separate function.
function chosen based on what the board needs.
Codec interface, SPI, GPIO, etc.
If so, then it makes sense for the
base driver
On Tue, Nov 16, 2010 at 07:17:18PM
-0500, Cyril Chemparathy wrote:
The ability to wait on multiple devices may come
handy.
... You mean you'd like to add such a
mechanism to the framework?
Or do you want a driver-specific
mechanism (non-portable)?
If I had
to do that, I'd just use
--- On Sat, 11/20/10, Uwe Kleine-König u.kleine-koe...@pengutronix.de wrote:
+ void
*nonconst_tx = (void *)xfer-tx_buf; /* shut up gcc */
Reads like a bad patch to me. Fix the bug,
don't just silence GCC. Or at least use
a better comment mentioning a constness
cast problems).
-
On Mon, 2010-11-22 at 10:58 +0100, Alexis RODET wrote:
Hello,
there is a problem with the double
definition of 'struct flash_platform_data' that are incompatible:
in arch/arm/include/asm/mach/flash.h:
in include/linux/spi/flash.h:
Both headers are included in a number of machines
--- On Mon, 11/22/10, Alexis RODET alexis.ro...@bvs-tech.com wrote:
And this patch doesn't touch machine or driver code,
so it's incomplete.
Look at the patch in previous mail attachment and you'll
see it does.
Couldn't do that. Submit another patch, or
combine it with this one. Either
an active trransfer,
which must not happen during OFF or other
suspend states.
Acked-by: David Brownell dbrown...@users.sourceforge.net
Also, in the last patch I suggested you do more of a
save/restore of
this value instead of a restore to a hard-coded
value. IOW, save the
value in the suspend
--- On Thu, 11/25/10, Grant Likely grant.lik...@secretlab.ca wrote:
as to be able to pair them up. Anyone have a better
idea or an example of
what someone else has done in similar circumstances?
Have a single driver private data structure that contains
and
registers 2 spi_device
Date: Wednesday, December 29, 2010, 12:11 AM
On Thu, Dec 02, 2010 at 06:47:29PM
+0100, Sebastian Andrzej Siewior wrote:
use platform_driver_register instead of
platform_driver_probe. The
latter only checks available devices at the time of
calling. So if a
device gets inserter at a
--- On Wed, 12/29/10, Grant Likely grant.lik...@secretlab.ca wrote:
From: Grant Likely grant.lik...@secretlab.ca
Subject: Re: [PATCH 1/9] spi/pxa2xx: register
I detect an effort to change the classic model for
board initialization in Linux: first set up
and register all system/platform
--- On Mon, 1/10/11, H Hartley Sweeten hartl...@visionengravers.com wrote:
From: H Hartley Sweeten hartl...@visionengravers.com
Subject: [PATCH] mtd: sst25l: fix reads with broken spi-masters
NAK. I'm surprised you even thought to submit
such a clearly-wrong patch.
The bug is in the SPI
--- On Fri, 1/14/11, Grant Likely grant.lik...@secretlab.ca wrote:
The bug _is_ in the spi peripheral on the ep93xx.
No, David is correct. The fault is in the master
driver. It is perfectly valid (and common) for spi
peripherals to required the SS line to remain asserted over
the
Only this, and nothing more.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
Sent already to Pierre ... this should get into 2.6.22-rc5!
drivers/mmc/core/sd.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- g26.orig/drivers/mmc/core/sd.c 2007-05-06 08:27:52.0
This is a draft API and reference implementation for a new SPI protocol
tweaking option, which supports more complex protocol stacks over SPI.
Examples: MMC/SD-over-SPI, wireless network chips, and hardware tools
at the JTAG/ISP level.
- A new SPI protocol tweaking interface, giving one driver
-by: David Brownell [EMAIL PROTECTED]
---
drivers/mmc/card/block.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
--- g26.orig/drivers/mmc/card/block.c 2007-05-24 12:04:46.0 -0700
+++ g26/drivers/mmc/card/block.c2007-06-04 19:59:00.0 -0700
... even
though some MMC controllers could do that.
Evidently the very newest MMC cards (like v4.2) differ from older ones
in how they handle things like CMD8 ... lacking specs, much less one
of the high capacity cards, this doesn't attempt to handle those cases.
Signed-off-by: David Brownell [EMAIL
On Wednesday 06 June 2007, Andrei Konovalov wrote:
Would be nice to get this driver into mainline.
Reviews and comments are welcome.
I'll ignore the Kconfig flamage ... ;)
--- /dev/null
+++ b/drivers/spi/xilinx_spi.c
@@ -0,0 +1,447 @@
+/*
+ * xilinx_spi.c
+ *
+ * Xilinx SPI controler
* Status bits used native to SPI: R1_SPI_*, R2_SPI_*
- Fix a few (unrelated) whitespace bugs in the headers.
None of these changes affects current code.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
include/linux/mmc/core.h | 21 ++--
include/linux/mmc/host.h |4
Here's the latest, which (modulo review issues) should be mergeable
against the latest git-mmc code (plus the crc7 patch, also in mm;
and the 4wire patch).
- headers learn about SPI ... a minor change from the last version,
removing that R1D message type hack
- mmc_block learns about SPI
-off-by: David Brownell [EMAIL PROTECTED]
---
drivers/mmc/card/block.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
--- pxa.orig/drivers/mmc/card/block.c 2007-06-10 13:00:21.0 -0700
+++ pxa/drivers/mmc/card/block.c2007-06-10 13:00:30.0 -0700
On Wednesday 13 June 2007, Pierre Ossman wrote:
David Brownell wrote:
The point is that this way we can keep the host driver out of the business
of deciding whether or not to enable CRC mode. The main alternative would
be to move that module parameter into the MMC core.
Why would we
On Friday 15 June 2007, Pierre Ossman wrote:
David Brownell wrote:
It starts off, and needs to be turned on. Reasons to leave it
off include performance (I measured over 30% slower with CRCs on while
writing a 120+ MB SD partition), and of course the fact that the CRC
stuff
On Friday 22 June 2007, Atsushi Nemoto wrote:
This is a driver for SPI controller built into TXx9 MIPS SoCs.
Looks mostly pretty good. I made a few minor changes/cleanups
in the appended version, notably:
- checking for spi-mode bits this code doesn't understand;
- updating to match latest
On Wednesday 20 June 2007, Pierre Ossman wrote:
David Brownell wrote:
Right now it looks like the main reason to keep including mmc.h is
to handle one aspect of mapping the data error token. ...
Don't map at all. Just give the core what you got from the card.
Tried that, it fails
On Wednesday 20 June 2007, Pierre Ossman wrote:
David Brownell wrote:
On Friday 15 June 2007, Pierre Ossman wrote:
Any CRC bugs should surface rather quickly, so that shouldn't be an isse.
Surfaced != fixed. The issue is that resolving them isn't all that
straightforward. There's
On Wednesday 20 June 2007, Pierre Ossman wrote:
You seem to be stuck in the idea that we want some voodoo translation layer
between native MMC and the SPI version. That is not desirable for a multitude
of
reasons, so make sure the core knows SPI and the host driver is just a
hardware
On Wednesday 27 June 2007, Atsushi Nemoto wrote:
This is a driver for SPI controller built into TXx9 MIPS SoCs.
This driver is derived from arch/mips/tx4938/toshiba_rbtx4938/spi_txx9.c.
Signed-off-by: Atsushi Nemoto [EMAIL PROTECTED]
---
Changes from previous version:
Better, but still not
-by: David Brownell [EMAIL PROTECTED]
---
drivers/mmc/core/core.c| 24 +-
drivers/mmc/core/mmc.c | 33 ++---
drivers/mmc/core/mmc_ops.c | 158 -
drivers/mmc/core/mmc_ops.h |4 +
drivers/mmc/core/sd.c | 31 +---
drivers
)
Changes from previous versions include more code shrinkage and cleanup,
reducing the number of I/O requests needed per operation, and moving
even more nuances into the MMC core code.
Signed-off-by: David Brownell [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED],
Cc: Hans-Peter Nilsson [EMAIL PROTECTED]
Cc: Jan
On Monday 23 July 2007, Anton Vorontsov wrote:
On Thu, Jul 19, 2007 at 01:28:17PM -0700, David Brownell wrote:
I notice that driver disregards the cs_change instructions in the
messages ... I could imagine how that could make a big difference.
For example, the extra flapping
On Wednesday 01 August 2007, Pierre Ossman wrote:
I need a MAINTAINERS entry aswell.
I was hoping someone would sign up for that, so I don't
have to stick myself there with Odd fixes status...
Have you poked someone? I don't even have any SPI hardware, so I'm
definitely the
On Wednesday 01 August 2007, Pierre Ossman wrote:
On Thu, 26 Jul 2007 16:32:36 -0700
David Brownell [EMAIL PROTECTED] wrote:
You said you weren't going to update the MMC core to check
the status bits after every request, and I'm certainly not
about to change *EVERY MMC/SD REQUEST
On Wednesday 01 August 2007, Pierre Ossman wrote:
On Thu, 26 Jul 2007 14:58:54 -0700
David Brownell [EMAIL PROTECTED] wrote:
This will fail to initialise a high capacity MMC card. From the MMC
spec:
Without the CMD58 with bits [30:29] set as 10b in prior to the
CMD1 a higher
On Saturday 04 August 2007, Pierre Ossman wrote:
On Thu, 2 Aug 2007 13:34:49 -0700
David Brownell [EMAIL PROTECTED] wrote:
The intended design of an MMC/SD host driver has never
been all that clear. It's becoming more clear with your
recent work ... but it's not there yet
On Monday 06 August 2007, Anton Vorontsov wrote:
+
+ if (pm)
+ pm--;
+ else /* this floods dmesg if using mmc_spi, so dbg */
+ dev_dbg(spi-dev, Requested speed is too
+
.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
Against: git-mmc.patch from 2.6.21-rc1-mm2. Changes since last version:
restore the lock/unlock hooks; SDIO is coded-to-spec. So it's bigger.
drivers/mmc/core/core.c | 39 +++--
drivers/mmc/core/core.h |2
drivers/mmc
Same deal as before ... refreshed against the latest git-mmc.patch,
four patches:
- headers
- block
- core
- mmc_spi host
Differences from the very last patches sent are primarily that this one
includes the lock/unlock changes again (since it's against git-mmc not
against kernel.org), and
On Thursday 09 August 2007, llandre wrote:
At a first glance, I wonder if you're not spending too much time
in the spi_imx pump_transfers tasklet. I have no idea how well
tuned that driver is...
Hmmm ... how do you suggest me to investigate around this tasklet? Do I
need to use the
This wasn't merged correctly into 2.6.23-rc2-mm2's version of git-mmc,
and that goof guarantees oopsing while enumerating at least SD-cards.
When the merge botch is fixed, that version of git-mmc.patch passes
sanity testing with MMC-over-SPI.
On Wednesday 08 August 2007, David Brownell wrote
driver name; less desirable.
Most systems will link SPI controller drivers statically, but
there's no point in being needlessly broken.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
Build-tested for the ARM drivers.
drivers/spi/spi_bfin5xx.c |3 ++-
drivers/spi/spi_imx.c
For spi_txx9 part, I can make a patch to fix the driver name and
relevant platform code (there is only one now) ether, if you dropped
the part from your patch. I'd like to go preferable in the long
term way for this new driver.
Of course we can remove MODULE_ALIAS when we changed the name,
On Wednesday 29 August 2007, Sascha Hauer wrote:
Hi,
On Wed, Aug 08, 2007 at 09:12:54AM -0700, David Brownell wrote:
+
+ dev_dbg(spi-dev, mmc_spi: STOP_TRAN\n);
+
+ /* Tweak the per-block message we set up earlier by morphing
+* it to hold single
On Wednesday 29 August 2007, Pierre Ossman wrote:
I need the following patch on my (little endian) System to
successfully read the csd/cid structure.
The resp field should already be in host order, so there must be a bug
in the mmc/spi host controller driver.
I wouldn't think it could
On Thursday 11 October 2007, Juergen Beisert wrote:
Hi,
the following error happens on my system:
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT
Modules linked in: cam_spi_driver
NIP: LR: C30626C4 CTR:
REGS: c0329a30 TRAP: 0400
On Thursday 11 October 2007, Bryan Wu wrote:
On Thu, 2007-10-11 at 23:26 -0700, David Brownell wrote:
On Thursday 11 October 2007, Bryan Wu wrote:
@@ -1182,12 +1198,9 @@ static int __init bfin5xx_spi_probe(struct
platform_device *pdev)
return -ENOMEM
On Friday 12 October 2007, Juergen Beisert wrote:
I've not had the best luck with jffs2 recently. Even on fairly
generic NOR flash it's crapped out quickly ... so I run NFS root
more often than I'd really like. Where crapping out means the
JFFS partition turns itself to garbage,
From: Tony Jones [EMAIL PROTECTED]
Make the SPI framework and drivers stop using class_device.
Update docs accordingly ... highlighting just which sysfs
paths should be safe/stable.
Signed-off-by: Tony Jones [EMAIL PROTECTED]
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
Documentation/spi
ug. Half of this patch seems to have got into Greg's tree, as
spi-convert-from-class_device-to-device-for-spi.patch.
Greg was supposed to remove that partial/incomplete patch ...
when he added it, I told him it was the wrong version.
- Dave
From: Girish [EMAIL PROTECTED]
Date: Mon, 15 Oct 2007 21:38:22 +0530
The first task is to come up with a workable design. Then would
come implementing it.
A second issue is how to factor the programming interface. The
notion of an spi_message isn't necessarily wrong, but when should
And the interaction model. Masters choose when to interact with
the hardware to send messages ... slave must react to those
choices, e.g. by seeing that they've been selected/deselected
and by processing the data they've been fed. Plus, there are
faults that can appear only in slave mode
From: Marc Pignat [EMAIL PROTECTED]
Date: Thu, 18 Oct 2007 18:40:38 +0200
spi_read and spi_write functions don't report late errors, for
instance fifo underrun.
Signed-off-by: Marc Pignat [EMAIL PROTECTED]
---
Seems right to me. This aspect of the spi_sync() calling
convention can be
In fact, if I look at the kernel.org GIT tree, it doesn't have
them either. Your tree must have somehow gotten a bunch of
private changes.
Did you apply these patches, or I need resent a new patchset against
latest Linus GIT tree?
I'm still not quite sure why the patches you sent didn't
that all vendors seem to have
this same confusion in their *25* series SPI memory parts.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
One person was about to forward patches teaching this driver how
to talk to a flash chip. Such wasted efforts should be avoided.
drivers/spi/at25.c |7
On Wednesday 17 October 2007, Pierre Ossman wrote:
On Wed, 17 Oct 2007 12:37:13 -0700
David Brownell [EMAIL PROTECTED] wrote:
That issue is 49dce689ad4ef0fd1f970ef762168e4bd46f69a3, the
classdev-elimination patch from Tony Jones. It broke the
does this bus have more than one device test
Pignat [EMAIL PROTECTED]
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
drivers/spi/spi.c | 13 +
1 files changed, 5 insertions(+), 8 deletions(-)
--- a/drivers/spi/spi.c 2007-10-27 18:37:42.0 -0700
+++ b/drivers/spi/spi.c 2007-10-27 18:42:32.0 -0700
@@ -539,10
On Tuesday 30 October 2007, Bryan Wu wrote:
@@ -211,6 +211,10 @@ static void cs_deactive(struct driver_data *drv_data,
struct chip_data *chip)
flag |= (chip-flag 8);
write_FLAG(drv_data, flag);
+
+ /* Move delay here for consistency */
+ if
On Tuesday 30 October 2007, Bryan Wu wrote:
- BF54x supported
- multi-port supported
- bunch of bug fixing
OK, I forwarded these with some more checkpatch.pl fixes.
But as I commented elsewhere, please work harder to make sure
that your patch comments actually match the patches!!
And
On Wednesday 31 October 2007, Bryan Wu wrote:
IMO, the spi_transfer.speed_hz = spi_board_info.max_speed_hz and if
spi_trasnfer.speed_hz is 0, we should use spi_board_info.max_speed_hz.
From the meaning of max_speed_hz, the spi_transfer.speed_hz should not
beyond max_speed_hz.
According to the
On Wednesday 31 October 2007, Mike Frysinger wrote:
On 10/31/07, David Brownell [EMAIL PROTECTED] wrote:
(ISTR the M25P16 in $SUBJECT has two read commands, one of
which is only usable at clock rates below 33 MHz or so, but
most other commands can work above that speed just fine.)
pretty
On Thursday 01 November 2007, Bryan Wu wrote:
--- a/include/asm-blackfin/bfin5xx_spi.h
+++ b/include/asm-blackfin/bfin5xx_spi.h
@@ -152,6 +152,7 @@
struct bfin5xx_spi_master {
u16 num_chipselect;
u8 enable_dma;
+ u16 pin_req[4];
};
/*
On Tuesday 06 November 2007, cksim wrote:
I have 2 questions with regards to SD/MMC over SPI.
Answering one at a time ...
1) In the code, I have commented out all other SPI devices on SPI0 bus
except for the SD card at spi0.3. However, I got an error can't share SPI
bus. Anyone can advise
On Tuesday 06 November 2007, cksim wrote:
2) The kernel 2.6.24-rc1 boots up and detected the SD card with the console
output new SD card on SPI. However, no device name, such as mmcblk0p1,
were allocated.
Did you load the mmc_block driver, and include partitioning support?
In addition, I
FYI -- this doesn't affect the issue noted (which happens
on reads, seemingly due to a too-busy bus) but otherwise it
seems like a reasonable notion and I've forwarded it to the
driver's maintainer.
-- Forwarded Message --
Subject: [RFC, PATCH] atmel_spi: Reduce memory
Basic driver for 8-bit SPI based MCP23S08 GPIO expander, without
support for IRQs or the shared chipselect mechanism.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
drivers/spi/Kconfig |7
drivers/spi/Makefile |1
drivers/spi/mcp23s08.c | 355
If this checks out for me too, I'll likely forward it for inclusion
in the MM tree, and with a note to the ARM list.
Silvester, thanks for this patch ... it sounds like it'll be a
winner!
-- Forwarded Message --
Subject: Re: Fwd: [spi-devel-general] [PATCH] atmel_spi: Allow
On Tuesday 04 September 2007, Sascha Hauer wrote:
Hi David,
On Fri, Aug 31, 2007 at 04:00:51PM -0700, David Brownell wrote:
The problem with the crc is reproducible. I watched this on the logic
analyzer, it's the response from the card to a SPI_TOKEN_STOP_TRAN
transfer
are issued, ensuring that one is
issued each time a transfer is started instead of once per call.
Also, properly indent the can this transfer be chained test so it's
not hidden as if it were non-conditional code.
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
Signed-off-by: David Brownell [EMAIL
On Friday 23 November 2007, Haavard Skinnemoen wrote:
Hmm. I can swear I've seen David respond to this before, but I can't
seem to find the thread. Anyway...
Yes, the linux-arm-kernel thread by steve birtles seems to have been
mangled for some reason. And this exact message seems to have been
are issued, ensuring that one is
issued each time a transfer is started.
Also, properly indent the can this transfer be chained test so it's
not hidden as if it were non-conditional code.
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
Against
From: David Brownell [EMAIL PROTECTED]
Fix a glitch reported by lockdep in the spi_bitbang code: it needs
to consistently block IRQs when holding that spinlock.
Signed-off-by: David Brownell [EMAIL PROTECTED]
--- a/drivers/spi/spi_bitbang.c
+++ b/drivers/spi/spi_bitbang.c
@@ -184,6 +184,7
On Friday 28 December 2007, chri wrote:
Hi,
I'm facing a problem with a driver for a SPI device: I think the
problem may be more general or perhaps I'm just missing something
obvious. I want to put a SPI device to sleep and this is done by
sending a command on the SPI bus. The first place I
1 - 100 of 321 matches
Mail list logo
