Linux on ARM based TI OMAP SoCs
 help / color / mirror / Atom feed
From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: Paul Barker <paul@paulbarker.me.uk>
Cc: linux-omap@vger.kernel.org, Jarkko Nikula <jarkko.nikula@bitmer.com>
Subject: Re: McBSP functions not exported
Date: Fri, 11 Jan 2013 14:17:03 +0100	[thread overview]
Message-ID: <50F010CF.8020808@ti.com> (raw)
In-Reply-To: <20130111114846.00005679@unknown>

Hi,

On 01/11/2013 12:48 PM, Paul Barker wrote:
> Hi,
> 
> I'm currently working on a driver to talk to an analog-to-digital
> converter (specifically a Texas Instruments ADS1672) connected to the
> McBSP port on a Beagleboard-xM. I'm currently building my driver module
> against a 3.2 series kernel with Beagleboard patches and config from
> https://github.com/beagleboard/kernel (branch beagleboard-3.2). I'd
> like to keep up-to-date with the more recent kernels but my module
> won't compile with them.
> 
> When the OMAP McBSP driver stack was merged into a single driver
> (commit 45656b4 by Peter Ujfalusi, looks like it went into linux 3.3)
> all the EXPORT_SYMBOL macros were removed so I can no longer call the
> functions I was using from my external module. Alternatively I could
> just be missing something really obvious, let me know if I am!

Since 3.3 there were even more changes in the McBSP driver stack. We (I) did
removed lot's of code and it is more focused on it's main functionality (ASoC).
What functions you were using from the McBSP driver(s)?

> I'm just wondering what the best way forward is from here and I'm sure
> I can't be the only person who was using the McBSP driver code in the
> kernel to interface with external hardware. The two options I can think
> of are either that I move my driver into the kernel source tree itself
> or the McBSP driver functions are exported again so that they can be
> used by external modules. It's easier to maintain an external module
> than a series of patches against the kernel, unless a driver for an
> analog-to-digital converter connected to the McBSP port is something
> that would actually have a chance of being merged into the mainline
> kernel. I could look at making this driver more generic once I have the
> current hardware/driver combination working, so that it should work
> with most analog-to-digital converters - I haven't found such a driver
> in my previous googling.

I have taken a brief look at ADS1672 datasheet. At first glance I would think
that if you connect the ADC to SPI port of OMAP3 you should be able to read
the data out as well. On BeagleBoard-xM you should have access to McSPI3 (CS0,
CS1) and McSPI4 (CS0).

> If you have any advice on this or a pointer to a better place to ask
> this question please let me know.

Can you try to see if you can use McSPI for your application?

As background: we did not had any other uses of McBSP when I have decided to
merge the code and move it out from arch/arm/plat-omap/ This was needed to be
done in any ways. The decision back then was that since we don't have users
for McBSP other than audio, it is going to be moved under sound/soc/omap/

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2013-01-11 13:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-11 11:48 McBSP functions not exported Paul Barker
2013-01-11 13:17 ` Peter Ujfalusi [this message]
2013-01-11 16:27   ` Paul Barker
2013-01-14  8:48     ` Peter Ujfalusi
2013-01-15 17:43       ` Paul Barker
2013-01-16  7:44         ` Jarkko Nikula
2013-01-16  9:05         ` Peter Ujfalusi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50F010CF.8020808@ti.com \
    --to=peter.ujfalusi@ti.com \
    --cc=jarkko.nikula@bitmer.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=paul@paulbarker.me.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox