---
arch/arm/mach-omap2/board-omap3beagle.c |4 ++--
arch/arm/mach-omap2/devices.c | 15 +++
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 67999da..481c1a9 100644
omap2_mcspi_platform_config.cs_gpios.
Signed-off-by: Ben Gamari
---
arch/arm/plat-omap/include/plat/mcspi.h |1 +
drivers/spi/omap2_mcspi.c | 19 +--
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mcspi.h
b/arch/arm/plat-omap/include
Thanks for the poke. I've been meaning to send this set out again anyways.
This is the patch I am currently using (on top of v3.0). Conceptually it's
quite similar to the first patches I sent out but some implementation details
were slightly reworked to account for the generalization of the McSPI
On Mon, 14 Mar 2011 13:25:36 -0600, Grant Likely
wrote:
> I see two solutions:
> 1) platform code registers a bus notifier so that it gets called back
> before the device gets bound to a driver. Then it can augment the
> platform data.
>
This sounds like it might be a bit involved and I'm not t
I've included the OMAP list so that I can hopefully get some feedback
from folks more familiar with this code.
Background:
I've been working on adding support for GPIO chip select lines to the
McSPI driver. Grant has been working with me to try getting the
in-kernel interface right and we have fi
> Yes, this is a better approach. However, I'd rather see the gpio data
> passed as an array to the spi master platform_device via the
> private_data structure.
Sorry for my ignorance but I really have no idea how one would hook this
up in the board code (which IMHO is where this sort of chip sel
---
arch/arm/mach-omap2/board-omap3beagle.c | 204 ++-
1 files changed, 201 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 14f4224..ad72685 100644
--- a/arch/arm/mach-omap2/board-omap
: Ben Gamari
---
drivers/spi/omap2_mcspi.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 951a160..ca4a7dc 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -35,6 +35,7
On Sat, 12 Feb 2011 01:33:24 -0700, Grant Likely
wrote:
> (Sorry for the really laggy reply)
>
No worries, I was just starting to think about this again myself.
> I don't see it being that big a deal. gpio drivers are pretty
> lightweight and it is fine to have domain-specific limitations on h
On Thu, 23 Dec 2010 20:28:19 -0700, Grant Likely
wrote:
> On Thu, Dec 23, 2010 at 09:27:20PM -0500, Ben Gamari wrote:
> > I understand your concerns, but I'm not sure how to satisfy them without
> > crippling the design's ability to accomodate my use-case. I can&#
On Thu, 23 Dec 2010 17:37:12 -0700, Grant Likely
wrote:
> On Thu, Dec 23, 2010 at 4:09 PM, Ben Gamari wrote:
> > The reason I left this up to the board is it's easy to foresee cases
> > where you want a non-trivial mapping between logical CS numbers and CS
> > pin sta
On Thu, 23 Dec 2010 14:38:57 -0700, Grant Likely
wrote:
> On Tue, Dec 21, 2010 at 10:56 AM, Ben Gamari wrote:
> > This mechanism is in large part stolen from the s3c64xx-spi module. To
> > use this functionality, one simply must define a set_level function to
> > s
the appropriate csinfo struct. This will cause the driver to
call the csinfo->set_level function instead of toggling the McSPI chip
select lines.
Signed-off-by: Ben Gamari
---
arch/arm/plat-omap/include/plat/mcspi.h | 14 ++
drivers/spi/omap2_mcspi.c |
As you may recall, about a year ago I wrote wondering whether it was possible
to use GPIO lines as chip selects in the McSPI driver. A few of you pointed out
that this functionality had been added to other drivers and it should be quite
simple to do the same for McSPI. Two semesters then passed wi
Thank you very much for your response. As you might have gathered, I seem to
have it working but your feedback is really appreciated. I hope to do another
run of these boards with these fixes.
On Mon, 15 Mar 2010 16:57:27 -0400, Ned Forrester wrote:
>
> Your problem is likely caused by pulling
On Mon, 15 Mar 2010 08:25:09 -0400, Philip Balister wrote:
> For some reason you need to set the clock pin as an input. Here is the
> config for mcspi1 that is working for me:
>
> MUX_VAL(CP(MCSPI1_CLK), (IEN | PTD | DIS | M0)) /*McSPI1_CLK*/\
>
> (from u-boot)
>
Are you sure? Is thi
On Mon, 15 Mar 2010 10:38:38 -0400, Ned Forrester wrote:
> I'd be happy to check your circuit for you, if it were posted in a more
> widely used format. How about a PDF of the schematic.
>
Certainly, it's a available at
http://goldnerlab.physics.umass.edu/~bgamari/schematic.png.
- Ben
---
Thanks for your reply!
On Mon, 15 Mar 2010 11:55:56 +0900, jassi brar wrote:
> a) You might as well want to verify your SPIDEV setup by using the same pins
> in GPIO mode and controlling them by gpio-bitbanging i/f ... first on both
> boards and then on either, to more accurately diagnose the pr
Hey all,
As I've mentioned here in the past, I am currently putting together a board for
doing analog data acquisition on the BeagleBoard platform. Unfortunately, I
have wasted nearly the entire weekend trying to accomplish the (one would
think) simple goal of recieving data with the McSPI control
Excerpts from arjun rath's message of Sun Feb 14 23:29:18 -0500 2010:
> Let us try and see .If any body is having a reference driver for SPI based
> ADC,they can share.
>
Have a look here[1]. The code certainly isn't finished (we're at a
similar stage of development as you, it seem), but you shoul
Excerpts from arjun rath's message of Sat Feb 13 00:48:40 -0500 2010:
> Hi everybody,
>
> can anybody share how to start a spi based ADC linux driver.I am having a
> MAXIM 1242 ADC chip.
>
> Can anybody share some reference driver for the same chip
>
I've recently been working on a design for a
Excerpts from jassi brar's message of Thu Jan 28 20:09:47 -0500 2010:
> the arch/mach specific stuff will come via the SoC maintainer's(Ben
> Dooks) tree as I already mentioned.
Crap. Sorry for the noise. Looks like I just need to learn to read.
- Ben
Excerpts from jassi brar's message of Wed Jan 27 23:33:20 -0500 2010:
> On Thu, Jan 28, 2010 at 1:10 PM, Ben Gamari wrote:
> > Hey all!
> >
> > Recently I've been thinking about adding support to the McSPI driver for
> > using GPIO pins as chip selects.
Excerpts from Bill Gatliff's message of Wed Jan 27 23:15:05 -0500 2010:
> Ben Gamari wrote:
> > As I am writing this, it now occurs to me that perhaps the chip doesn't
> > start SPI_CLK until it has data to send.
>
> ... or receive. This is indeed the case.
Hey all!
Recently I've been thinking about adding support to the McSPI driver for
using GPIO pins as chip selects. As a starting point, I've browsed the
driver source trying to identify what changes would be necessary to add
this support. It seems like the rough idea is,
a) add a cs_gpio field
Excerpts from Ben Gamari's message of Wed Jan 20 14:47:23 -0500 2010:
> Bcc:
> Subject: GPIO chip select support in omap2_mcspi driver
>
> It seems like the rough idea is to add a cs_gpio field to the device
> struct (omap2_mcspi) and add the appropriate code to the
> omap2_mcspi_force_cs() to br
Bcc:
Subject: GPIO chip select support in omap2_mcspi driver
Hey,
Recently I have been looking to use a BeagleBoard to drive several
serial ADCs and DACs in a data acquisition and analysis setup. Unfortunately,
the
BeagleBoard is severely limited by the number of SPI controllers it
exposes on t
27 matches
Mail list logo
