On Tue, Jul 20, 2010 at 3:10 PM, Linus Walleij
wrote:
> 2010/7/20 David Brownell :
>
>>> 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
-287,5 +359,5 @@ module_init(pl022_init_dummy);
> module_exit(pl022_exit_dummy);
>
> MODULE_AUTHOR("Linus Walleij ");
> -MODULE_DESCRIPTION("PL022 SSP/SPI DUMMY Linux driver");
> +MODULE_DESCRIPTION("PL022 loopb
Yes, you can either base your patch on next-spi or on against Linus'
tree. If anything is sufficiently complex that it won't merge, then
I'll ask you to help me rebase it, but usually that isn't a problem.
Cheers,
g.
--
Grant Likely,
On Thu, Jul 8, 2010 at 1:23 PM, Brian Niebuhr wrote:
> INTRODUCTION
>
> I have been working on a custom OMAP-L138 board that has multiple spi
> devices (seven) on one controller. These devices have a wide range of
> transfer parameters (speed, phase, polarity, internal and gpio chip
> selects).
edition for
information on the device model. Read the source code for detailed
information about the spi bus type.
Cheers,
g.
>
> Thanks
> Ananth
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
-
f_match);
>
> static struct of_platform_driver mpc512x_psc_spi_of_driver = {
> .probe = mpc512x_psc_spi_of_probe,
> - .remove = __exit_p(mpc512x_psc_spi_of_remove),
> + .remove = __devexit_p(mp
On Fri, Jul 2, 2010 at 9:30 AM, Brian Niebuhr wrote:
> This patch fixes the setup_transfer logic to account for the case where
> multiple messages to different SPI devices are in the queue simultaneously.
> With the current logic, the second message in the queue will end up
> using the transfer pa
On Sat, Jul 3, 2010 at 11:05 AM, Antonio Ospite
wrote:
> On Tue, 29 Jun 2010 21:30:34 -0600
> Grant Likely wrote:
>
>> I've pushed out Ernst's spi bus locking API patches to the following
>> branch. Before I push them into linux-next, I'd like to get some
>
On Wed, Jun 30, 2010 at 5:00 AM, David Brownell wrote:
>
>
> --- On Thu, 6/17/10, Marek Szyprowski wrote:
>
>> From: Marek Szyprowski
>> 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 s
On Thu, Feb 18, 2010 at 11:29 AM, Grant Likely
wrote:
> On Thu, Feb 18, 2010 at 10:09 AM, Tony Lindgren wrote:
>> * Grant Likely [100218 08:26]:
>>> On Tue, Feb 9, 2010 at 3:25 PM, Tony Lindgren wrote:
>>> > * Hemanth V [100203 02:19]:
>>> >> From
pi/omap_spi_100k.c | 23 +++--
drivers/spi/spi.c | 225 ---
include/linux/spi/spi.h | 12 +++
4 files changed, 227 insertions(+), 92 deletions(-)
--
Grant Likely, B.Sc., P.Eng.
Se
t_rx = davinci_spi_rx_buf_u8;
> + davinci_spi->get_tx = davinci_spi_tx_buf_u8;
> +
> + init_completion(&davinci_spi->done);
> +
> + /* Reset In/OUT SPI module */
> + iowrite32(0, davinci_spi->base + SPIGCR0);
> + udelay(100);
> +
On Tue, Jun 29, 2010 at 2:01 AM, Grant Likely wrote:
> On Mon, Jun 28, 2010 at 11:27 AM, Grant Likely
> wrote:
>> On Mon, Jun 28, 2010 at 10:57 AM, Nori, Sekhar wrote:
>>> Hi Grant,
>>>
>>> On Sun, Jun 27, 2010 at 11:33:13, Grant Likely wrote:
>>&
On Mon, Jun 28, 2010 at 11:27 AM, Grant Likely
wrote:
> On Mon, Jun 28, 2010 at 10:57 AM, Nori, Sekhar wrote:
>> Hi Grant,
>>
>> On Sun, Jun 27, 2010 at 11:33:13, Grant Likely wrote:
>>> Any users of the current davinci_spi driver care to comment on this
>&g
On Mon, Jun 28, 2010 at 10:57 AM, Nori, Sekhar wrote:
> Hi Grant,
>
> On Sun, Jun 27, 2010 at 11:33:13, Grant Likely wrote:
>> Any users of the current davinci_spi driver care to comment on this
>> series? I'm hesitant to apply a complete replacement to a driver
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)
On Fri, Jun 4, 2010 at 2:13 PM, Brian Niebuhr wrote:
> This patch fixes the setup_transfer logic to account for the case where
> multiple messages
ransfers, transfer_list) {
>>> if (t->tx_buf == NULL && t->rx_buf == NULL &&
>>> t->len) {
>>> status = -EINVAL;
>>> @@ -931,6 +925,8 @@ static void omap2_mcspi_work(struct work_struct
>>> *work)
>>>
>
ED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit. See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> ___
> spi-devel-general mailing l
gt; list_for_each_entry(t, &m->transfers, transfer_list) {
> if (t->tx_buf == NULL && t->rx_buf == NULL && t->len) {
> status = -EINVAL;
> @@ -931,6 +925,8 @@ static void omap2_mcspi_work(struc
On Wed, Jun 9, 2010 at 1:14 AM, Marek Szyprowski
wrote:
> Hello,
>
> On Wednesday, June 02, 2010 11:00 AM Jassi Brar wrote:
>
>> On Wed, Jun 2, 2010 at 3:00 PM, Marek Szyprowski
>> wrote:
>> > On Tuesday, June 01, 2010 5:00 PM Grant Likely wrote:
>> &
On Mon, Jun 14, 2010 at 1:15 PM, Brian Niebuhr wrote:
>> Can you please post this series to SPI development list
>> (spi-devel-general@lists.sourceforge.net) CCing the maintainers
>> David Brownell and Grant Likely?
>
> Done
I had to go looking for these patches. I see t
On Thu, Jun 10, 2010 at 4:24 AM, Antonio Ospite
wrote:
> Hi,
>
> I would be interested to know about the status of the SPI bus locking
> API, especially related to mmc_spi, I see there is some discussion from
> February[1] mentioning a possible inclusion in 2.6.35[2], but I can't
> find the change
This patch fixes a build error caused by the OF device_node pointer
being moved into struct device.
Fixes bug introduced by commit 61c7a080a5a061c976988fd4b844dfb468dda255
(of: Always use 'struct device.of_node' to get device node pointer)
Signed-off-by: Grant Likely
CC: Sean MacLenna
On Tue, Jun 1, 2010 at 5:48 AM, Marek Szyprowski
wrote:
> Hello,
>
> On Thursday, April 01, 2010 12:36 PM Marek Szyprowski wrote:
>
>> There are some boards that do not strictly follow SPI standard and use
>> only 3 wires (SCLK, MOSI or MISO, SS) for connecting some simple auxiliary
>> chips and c
ges the transfer size for 16 and 8 bpw transfers to
something, for lack of a better word, more boring. I'd rather see a
patch that clamps the transfers size based on the bpw setting. Bonus
points for a patch that adds
available in the git repository at:
git://git.secretlab.ca/git/linux-2.6 next-spi
Anatolij Gustschin (2):
powerpc/mpc5121: move PSC FIFO memory init to platform code
spi/mpc5121: Add SPI master driver for MPC5121 PSC
Grant Likely (2):
Merge remote branch 'origin' into secr
ma(mcspi_dma->dma_rx_channel);
> + mcspi_dma->dma_rx_channel = -1;
> + }
> + if (mcspi_dma->dma_tx_channel != -
a.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> spi-devel-general mailing list
> spi-devel-general@lists.sourceforge.net
> https://lists.sourcef
annel);
> - mcspi_dma->dma_tx_channel = -1;
> + if (mcspi_dma->dma_rx_channel != -1) {
> + omap_free_dma(mcspi_dma->dma_rx_channel);
> + mcspi_dma->dma_rx_channel = -1;
> + }
> +
On Tue, Mar 9, 2010 at 4:56 PM, Brian Niebuhr wrote:
> It is possible that multiple messages for different SPI devices could
> be queued. The transfer parameters are currently only set for the
> first message in the bitbang work queue. If subsequent messages in
> the queue are for devices that d
On Fri, May 14, 2010 at 6:22 AM, Anton Vorontsov wrote:
> On Fri, May 14, 2010 at 11:14:27AM +0200, Joakim Tjernlund wrote:
>>
>> Signed-off-by: Joakim Tjernlund
>
> Acked-by: Anton Vorontsov
I don't think I'll apply this one. I know it's just sample code, but
it still smells of masking a corn
berg
>> Signed-off-by: H Hartley Sweeten
>> Acked-by: H Hartley Sweeten
>> Cc: Ryan Mallon
>> Cc: David Brownell
>> Cc: Grant Likely
>> Cc: Martin Guy
>
> Hi Grant,
>
> Ping. Any change getting this dri
On Fri, May 21, 2010 at 11:23 AM, Joakim Tjernlund
wrote:
> Anton Vorontsov wrote on 2010/05/17 15:22:54:
>>
>> On Mon, May 17, 2010 at 03:17:10PM +0200, Joakim Tjernlund wrote:
>> > This fixes a typo were map_tx_dma is used instead of
>> > map_rx_dma, casing the driver to unmap rx_dma when it
>>
On Mon, Apr 19, 2010 at 1:16 PM, Martin Guy wrote:
> On 4/19/10, Grant Likely wrote:
>> >> > + /* read all received data */
>> >> > + while ((ep93xx_spi_read_u8(espi, SSPSR) & SSPSR_RNE) &&
>> >> > + espi-
On Fri, May 7, 2010 at 2:40 AM, Linus Walleij
wrote:
> This adds support for a further ST variant of the PL022 called
> PL023. Some differences in the control registers due to being
> stripped down to SPI mode only, and a new clock feedback sample
> delay config setting is available.
>
> Signed-of
On Wed, May 19, 2010 at 1:25 PM, Prarit Bhargava wrote:
> Sorry everyone ... I left off [PATCH]: ... will resend shortly.
>
> (And then I top-posted too...)
[PATCH] is trivial and unnecessary. As long as it shows up in
patchwork, then I won't forget about it:
https://patchwork.kernel.org/patch/
On Wed, May 12, 2010 at 6:43 PM, Anton Vorontsov wrote:
> On Wed, May 12, 2010 at 06:28:51PM +0200, Joakim Tjernlund wrote:
>> Anton Vorontsov wrote on 2010/05/12 18:22:31:
>> >
>> > On Wed, May 12, 2010 at 05:50:50PM +0200, Joakim Tjernlund wrote:
>> > > tx_dma/rx_dma are already set to a dummy
quot;,
> - __func__, np->full_name);
> - iounmap(psc);
> - /*
> - * chances are that another device requests less
> - * fifo space, so we continue.
> -
On Mon, Apr 26, 2010 at 3:01 AM, wrote:
> From: Thomas Koeller
>
> Computation of the clock prescaler value returned bogus results if
> the requested SPI clock was impossible to set. It now sets either
> the maximum or minimum clock frequency, as appropriate.
>
> Signed-off-by: Thomas Koeller
>
On Mon, Apr 19, 2010 at 12:52 PM, Martin Guy wrote:
> On 4/19/10, Grant Likely wrote:
>> >> > + /*
>> >> > + * Calculate divisors so that we can get speed according the
>> >> > + * following formula:
>> >>
On Sat, Apr 17, 2010 at 5:00 AM, Mika Westerberg wrote:
> On Fri, Apr 16, 2010 at 11:30:45PM -0700, Grant Likely wrote:
>> Thanks for the patch. Comments below.
>
> Thanks for the comments. See below my replies.
>> On Tue, Apr 13, 2010 at 7:10 AM, Mika Westerberg
>&
just disable > 16-bit transfers altogether, since they are broken, and
> thus, obviously, unused.
>
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
>
transfer_method);
> + error = -EINVAL;
> + goto fail_put_clock;
> + }
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res) {
> + dev_err(&p
On Fri, Apr 9, 2010 at 2:38 AM, wrote:
>
>
>>-Original Message-
>>From: Oikarinen Juuso (Nokia-D/Tampere)
>>Sent: 09 April, 2010 10:52
>>To: Tereshonkov Roman (Nokia-D/Helsinki)
>>Cc: ext Grant Likely; spi-devel-general@lists.sourceforge.net;
>>S
On Thu, Apr 8, 2010 at 10:05 PM, Juuso Oikarinen
wrote:
> AFAIK performing the SPI transfer optimally should not affect other SPI
> clients in a negative way, and AFAIK there are no other SPI clients in
> Dali than the wl1271, so I guess this new threshold value could also be
> hard-coded into the
On Thu, Apr 8, 2010 at 9:25 AM, wrote:
>
> The others from wlan team need DMA_MIN_BYTES to be adjustable.
> Juuso can comment this.
Fair enough. I'm happy to either take both parts of the patch through
the spi tree, or for the changes to go in via the omap tree. There is
no sense in splitting
On Thu, Apr 8, 2010 at 4:33 AM, wrote:
>
> Hi,
>
>
>>-Original Message-
>>From: glik...@secretlab.ca [mailto:glik...@secretlab.ca] On
>>Behalf Of ext Grant Likely
>>Sent: 08 April, 2010 09:27
>>To: Tereshonkov Roman (Nokia-D/Helsinki)
>
On Tue, Mar 30, 2010 at 3:57 AM, Linus WALLEIJ
wrote:
> [Self]
>
>> This is a fourth iteration of the PrimeCell DMA API on top of the
>> generic DMA devices (sibling to the DMA engine). It's based on
>> the suggestion from Russell to try and define a specific extension
>> subset for DMA devices.
>
On Mon, Mar 29, 2010 at 5:36 PM, Linus Walleij
wrote:
> This extends the PL022 UART driver with generic DMA engine support
> using the PrimeCell DMA engine interface. Also fix up the test
> code for the U300 platform.
>
> Signed-off-by: Linus Walleij
> ---
> arch/arm/mach-u300/dummyspichip.c |
t; */
> u8 mode;
>
> + /* dma_min_bytes defines minimum bytes when dma is used */
> + u32 dma_min_bytes;
> /* ... may need additional spi_device chip config data here.
> * avoid stuff prot
On Mon, Apr 5, 2010 at 12:19 PM, christian pellegrin wrote:
> Hi,
>
> first of all I'm sorry for the late response, just now I found time to
> work on this.
>
> On Wed, Mar 31, 2010 at 8:04 AM, Grant Likely
> wrote:
>
>> Is checking the T bit really ne
a better idea here */
max3100->tx_buf[0] = max3100->tx_pending_data;
max3100->tx_pending = 0;
}
spi_async(&max3100->spi_msg);
max3100->busy = 1; /* cleared by the completion callback */
spin_unlock(&max3100->lock);
return HRTIMER_RESTART;
}
g.
--
Gr
dev_warn(&spi->dev,
> "uart_add_one_port failed for line %d with error
> %d\n",
> i, retval);
>
> - /* set shutdown mode to save power. Will be woken-up on open */
> - if (max3100s[i]->m
ic void max3100_timeout(unsigned long data)
> struct max3100_port *s = (struct max3100_port *)data;
>
> if (s->port.state) {
> - max3100_dowork(s);
> + raise_threaded_irq(s->irq);
> mod_timer(&s->timer, jiffies + s
s,
g.
The following changes since commit 57d54889cd00db2752994b389ba714138652e60c:
Linus Torvalds (1):
Linux 2.6.34-rc1
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6 merge
David Miller (1):
uartlite: Fix build on sparc.
Grant Likely (1):
powerpc/52
atch read, and
> provides a console.
>
> change log:
> since v5:
> * Make the spi data buffer DMA safe, thanks to Mssakazu Mokuno,
> David Brownell and Grant Likely for pointing the bug out
> since v4:
> * Add explanation why not using DMA
>
On Sun, Mar 7, 2010 at 7:11 PM, Feng Tang wrote:
> On Fri, 5 Mar 2010 15:44:50 +0800
> Erwin Authried wrote:
>
>>
>> The spi rate and the uart clock aren't synchronized, what happens if
>> the spi rate is slightly higher than the MAX3100's baud rate clock?
>> In addition, if there are other devic
On Tue, Mar 2, 2010 at 7:57 PM, Feng Tang wrote:
> Hi All,
>
> Here is a driver for Maxim 3110 SPI-UART device, please help to review.
>
> It has been validated with Designware SPI controller (drivers/spi: dw_spi.c &
> dw_spi_pci.c). It supports polling and IRQ mode, supports batch read, and
> pro
On Thu, Feb 25, 2010 at 10:25 AM, Ernst Schwab wrote:
> On Thu, 25 Feb 2010 09:38:48 -0700 Grant Likely
> wrote:
>
>> I looked at them all this morning. Without exception, every single
>> driver follows this pattern:
>> - [maybe check some stuff]
>> - spin_
/dw_spi: add return value to empty mrst_spi_debugfs_init()
spi/dw_spi: fixed a spelling typo in a warning message.
spi/dw_spi: remove conditional from 'poll_transfer'.
spi/dw_spi: conditional transfer mode changes
Grant Likely (2):
spi/dw_spi: fix __init/__devin
On Thu, Feb 25, 2010 at 3:36 AM, Ernst Schwab wrote:
> On Wed, 24 Feb 2010 13:32:43 -0700 Grant Likely
> wrote:
>> On Thu, Feb 18, 2010 at 5:10 AM, Ernst Schwab wrote:
> [...]
>> > I have concerns on the use of the spin lock around the
>> > __spi_async(
On Wed, Feb 17, 2010 at 2:41 PM, Mike Frysinger wrote:
> On Wed, Feb 17, 2010 at 16:07, Grant Likely wrote:
>> Also, even if I agreed with the premise that a cookie is needed for
>> deciding who can use the bus when locked, it is still a good idea to
>> use a different AP
if they work for you.
Ping me after Linus tags v2.6.34-rc1 to make sure I don't forget to
put it in my -next branch.
Some comments below...
On Thu, Feb 18, 2010 at 5:10 AM, Ernst Schwab wrote:
> I integrated your changes in V2, I hope I did not miss anything.
>
> On Wed, 17 Feb 2010 13
drivers/spi: dw_spi.c &
>> dw_spi_pci.c). It supports polling and IRQ mode, supports batch read, and
>> provides a console.
>
> Ack for the serial side
>
> Acked-by: Alan Cox
Ack for the SPI side
Acked-by: Grant Likely
g.
---
On Thu, Feb 18, 2010 at 10:09 AM, Tony Lindgren wrote:
> * Grant Likely [100218 08:26]:
>> On Tue, Feb 9, 2010 at 3:25 PM, Tony Lindgren wrote:
>> > * Hemanth V [100203 02:19]:
>> >> From ee48142ddc43129a21676dbb56a83e3e7d8063de Mon Sep 17 00:00:00 2001
>>
; 3?
Also, what is your feeling about patch 3/3, spi slave support. spi
slave usage model is still a matter under debate, but that patch
doesn't touch core spi code, so I'm okay to merge it as a
driver-specific feature. However, I'm not convinced that it is
actually a useful patch
On Wed, Feb 17, 2010 at 1:19 PM, Mike Frysinger wrote:
> On Wed, Feb 17, 2010 at 15:06, Grant Likely wrote:
>> On Wed, Feb 17, 2010 at 12:03 PM, Mike Frysinger wrote:
>>> On Wed, Feb 17, 2010 at 13:17, Ernst Schwab wrote:
>>>> The current runtime API looks li
ice won't be added later...
> - */
> - if (spi->master->num_chipselect > 1) {
> - struct count_children cc;
> -
> - cc.n = 0;
> - cc.bus = spi->dev.bus;
> - status
he spi device to be unique per bus.
> re-use that to check ownership of the mutex.
No. the bus locking operation is completely orthogonal to the spi
device being used for the transfer. A driver could even obtain the
lock, and then use multiple spi_devices to execute transfers before
releasi
On Wed, Feb 17, 2010 at 11:17 AM, Ernst Schwab wrote:
> From: Ernst Schwab
>
> SPI bus locking API to allow exclusive access to the SPI bus, especially, but
> not limited to, for the mmc_spi driver.
>
> Coded according to an outline from Grant Likely; here is his
> specif
On Wed, Feb 17, 2010 at 6:41 AM, Wolfram Sang wrote:
> On Wed, Feb 17, 2010 at 01:23:22PM +0100, Ernst Schwab wrote:
>> From: Ernst Schwab
>>
>> Added devicetree binding documentation for gpios used as chipselect. The
>> code to evaluate these is already present in spi_mpc8xxx.c.
>>
>> Signed-off
On Wed, Feb 17, 2010 at 6:30 AM, Grant Likely wrote:
> On Wed, Feb 17, 2010 at 12:35 AM, Ernst Schwab wrote:
>> Grant Likely wrote:
>>
>>> It sounds like you're very worried about making changes to the core
>>> code,
>>
>> Maybe...
>>
>
On Wed, Feb 17, 2010 at 12:35 AM, Ernst Schwab wrote:
> Grant Likely wrote:
>
>> It sounds like you're very worried about making changes to the core
>> code,
>
> Maybe...
>
>> In fact, now that I've had an evening to think about it, the solution
>&
On Tue, Feb 16, 2010 at 10:04 PM, Mike Frysinger wrote:
> On Tue, Feb 16, 2010 at 23:47, Grant Likely wrote:
>> On Tue, Feb 16, 2010 at 9:34 PM, Mike Frysinger wrote:
>>> On Tue, Feb 16, 2010 at 22:48, Grant Likely wrote:
>>>>> there's nothing Blackfin-s
On Tue, Feb 16, 2010 at 9:34 PM, Mike Frysinger wrote:
> On Tue, Feb 16, 2010 at 22:48, Grant Likely wrote:
>>> there's nothing Blackfin-specific in the implementation of these
>>> functions. i think the way we should be handling these is by doing:
>>> - remo
On Tue, Feb 16, 2010 at 5:07 PM, Mike Frysinger wrote:
> On Tue, Feb 16, 2010 at 15:43, Grant Likely wrote:
>> On Tue, Feb 16, 2010 at 12:57 PM, Ernst Schwab wrote:
>>> From: Yi Li
>>>
>>> For some MMC cards over SPI bus, it needs to lock the SPI bus for its
On Tue, Feb 16, 2010 at 5:16 PM, Ernst Schwab wrote:
> Grant Likely wrote:
>
>> This series seems to try and solve the problem the hard way, and by
>> creating a new locking scheme (and as history shows, new locking
>> schemes are *alwasy* broken).
>> Why is the lock
On Tue, Feb 16, 2010 at 5:07 PM, Mike Frysinger wrote:
> On Tue, Feb 16, 2010 at 15:43, Grant Likely wrote:
>> On Tue, Feb 16, 2010 at 12:57 PM, Ernst Schwab wrote:
>>> From: Yi Li
>>>
>>> For some MMC cards over SPI bus, it needs to lock the SPI bus for its
On Tue, Feb 16, 2010 at 1:48 PM, Ned Forrester wrote:
> On 02/16/2010 02:33 PM, Linus Walleij wrote:
>> 2010/2/15 jassi brar :
>>
>>> I don't think adding SPI_SLAVE support is just a matter of providing
>>> additional callbacks and structures, as is pointed out in this thread
>>> http://www.ma
On Tue, Feb 16, 2010 at 2:16 PM, Ned Forrester wrote:
> On 02/16/2010 03:43 PM, Grant Likely wrote:
>> On Tue, Feb 16, 2010 at 12:57 PM, Ernst Schwab wrote:
>>> From: Yi Li
>>>
>>> For some MMC cards over SPI bus, it needs to lock the SPI bus for its own
&g
On Tue, Feb 16, 2010 at 12:33 PM, Linus Walleij
wrote:
> 2010/2/15 jassi brar :
>
>> I don't think adding SPI_SLAVE support is just a matter of providing
>> additional callbacks and structures, as is pointed out in this thread
>> http://www.mail-archive.com/spi-devel-general@lists.sourceforge.
On Sun, Feb 14, 2010 at 6:37 PM, jassi brar wrote:
> On Mon, Feb 15, 2010 at 8:20 AM, Linus Walleij
> wrote:
>> 2010/1/19 Grant Likely :
>>
>>> The current model is that each spi_device is registered with an
>>> spi_master. Many device drivers operate on
On Tue, Feb 16, 2010 at 11:59 AM, Ernst Schwab wrote:
> Grant Likely wrote:
>
>> Add a property to the /chosen node to assign short labels to devices.
>
> I'm not familiar with this and will check - does anyone know of an
> existing example for this?
Oops, sorry.
reporting and
> @@ -953,8 +1204,6 @@ static int omap2_mcspi_transfer(struct spi_device *spi,
> struct spi_message *m)
> }
> }
>
> - mcspi = spi_master_get_devdata(spi->master);
> -
> spin_lock_irqsave(&mcspi->lock, flags);
> list_add_tai
On Tue, Feb 16, 2010 at 7:38 AM, Hemanth V wrote:
>> * Tony Lindgren [100209 15:03]:
>>> * Grant Likely [100209 14:38]:
>>> > On Tue, Feb 9, 2010 at 3:25 PM, Tony Lindgren wrote:
>>> > > * Hemanth V [100203 02:19]:
>>> > >> From
(*unlock_bus)(struct spi_device *spi);
> };
>
> static inline void *spi_master_get_devdata(struct spi_master *master)
> @@ -578,6 +583,8 @@ spi_async(struct spi_device *spi, struct spi_message
> *message)
> */
>
> extern int spi_sync(struct spi_device *spi, struc
mode = "cpu";
> + gpios = <&gpio 18 1 // device reg=<0>, low-active
> + &gpio 19 1>; // device reg=<1>, low-active
> };
>
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
---
On Tue, Feb 16, 2010 at 9:43 AM, Ernst Schwab wrote:
> Grant Likely wrote:
>
>> The change forces the division to always round up instead of down.
>> Please describe (for me now, and for people looking at the commit in
>> the future) the mathematical reason for the change
ansfer(struct sp
> if (pm > 16)
> pm = 16;
> } else
> - pm = mpc8xxx_spi->spibrg / (hz * 4);
> + pm = (mpc8xxx_spi->spibrg - 1) / (hz * 4) + 1;
> if (pm)
> pm--;
>
>
>
>
[cc'd spi-devel-generial too]
On Tue, Feb 16, 2010 at 8:08 AM, Ernst Schwab wrote:
> Grant Likely wrote:
>
>> No, unless you can provide a really compelling reason to do so, the
>> goal is to *not* specify Linux implementation detail things like bus
>> numbers in t
On Tue, Feb 9, 2010 at 4:07 PM, Tony Lindgren wrote:
> * Grant Likely [100209 14:38]:
>> On Tue, Feb 9, 2010 at 3:25 PM, Tony Lindgren wrote:
>> > * Hemanth V [100203 02:19]:
>> >> From ee48142ddc43129a21676dbb56a83e3e7d8063de Mon Sep 17 00:00:00 2001
>> >
spi
branch, since it means that my pull requests are less obvious for
Linus and there is greater chance of conflict.
But if you still really want me to merge it through my tree, (or if
getting the patches out of order will break things) then I'll pick it
up. Just let
On Mon, Feb 8, 2010 at 5:20 PM, Andrew Morton wrote:
> On Mon, 8 Feb 2010 16:59:46 +0800
> Feng Tang wrote:
>
>> Hi All,
>>
>> Here is a driver for Maxim 3110 SPI-UART device, please help to review.
>>
>> It has been validated with Designware SPI controller (drivers/spi: dw_spi.c &
>> dw_spi_pci.
he SPI tree, unless there are commit ordering issues
with arch code. I'm tracking SPI patches with patchwork:
http://patchwork.kernel.org/project/spi-devel-general/list/
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
-
Amtsgericht Mannheim
> HRB 110 300
> Gesch?ftsf?hrer: Dieter Baur, Ramona Maurer
> _
>
> Important Note:
> - This e-mail may contain trade secrets or privileged, undisclosed or
> otherwise confiden
On Tue, Feb 2, 2010 at 1:46 AM, Paul Mundt wrote:
> Ahh.. this is where the confusion came from. The initial version of the
> patch was only posted to the sh list, Magnus asked for it to be reposted
> to the spi list and I hadn't heard anything about it since then, so I
> assumed the poster just d
On Tue, Feb 2, 2010 at 1:21 AM, Paul Mundt wrote:
> On Tue, Feb 02, 2010 at 01:17:49AM -0700, Grant Likely wrote:
>> On Mon, Feb 1, 2010 at 9:06 PM, Paul Mundt wrote:
>> > Please pull from:
>> >
>> > ? ? ? ?master.kernel.org:/pub/scm/linux/kernel/git/l
On Tue, Feb 2, 2010 at 12:22 AM, Joe Perches wrote:
> String constants that are continued on subsequent lines with \
> are not good.
>
> Signed-off-by: Joe Perches
Merged into next-spi, thanks.
g.
--
The Planet: dedica
On Fri, Jan 29, 2010 at 6:37 AM, Pietrek, Markus
wrote:
> Hi,
>
> it seems to me that the spi_sh_msiof.c driver configures REDG and TEDG
> wrongly. TEDG==0 outputs data at the **rising edge** of the clock and REDG==0
> samples data at the **falling edge** of the clock. Therefore for SPI, TEDG
>
before picking up SPI
patches into your tree. I don't mind arch specific spi changes going
in via a different tree, but I'd like to know about it before I waste
time farting around with the same patch (like I did with this one
tonight, and only found out that you also picked it up when
801 - 900 of 1060 matches
Mail list logo
