mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bertrand Roussel <bertrand.roussel@cor-net.org>
To: linux-kernel@vger.kernel.org
Subject: Kernel driver with multiple SPI sources
Date: Fri, 16 Oct 2009 21:50:43 +1300	[thread overview]
Message-ID: <a5b9b4700910160150o146a8f21n1c76c14755d64da8@mail.gmail.com> (raw)

Hello,

I am currently writing a kernel driver for an IMU, this is a basic
driver that is taking infos from
two SPI devices (an adc and a magnetic sensor), that are running on
the same bus, but different with different CS.

I'm having troubles to determine if the architecture I am currently
thinking about is a good way to do things.
In order to write portable code I was thinking in using general kernel
APIs, and came out with something like this:
 _____      ______
|     | <> |  ADC |
|     |    |______|
| IMU |     ______  <> Bus SPI
|     | <> |  MAG |
|_____|    |______|

Each block correspond to a driver:
* IMU is a basic char driver, depending on both ADC and MAG driver,
and that register new spi_device to the spi_master
* ADC and MAG are instances of an spi_driver, with a char driver as an interface

The IMU must take samples from the devices at a fixed rate.
A problem is that to retrieve infos from the MAG for example, a
command must be send first, then there is a delay from
1 to 4ms before the result are available, which is known when a PIN gets high.

Since I'm a beginner in kernel writing, I really don't know if the
approach I took is a good way to do things or not.
If that's not the case, can anyone give me some hints about how I
should consider doing things ?

However, in the case as my approach is right, I am really worried
about the delay part, since I don't want the kernel
to block for 5ms doing nothing a hundred times per second just because
it is reading from the SPI, I was considering
asynchronous IO implementation on the ADC/MAG side.
A timer would generate the sample rate in the IMU driver, tell the
ADC, which would send the command, then return.
On the gpio interrupt, the driver would read the ADC, and return the
result to the IMU. Which would then tell the MAG,
which would send the command, then return. Then gpio interrupt, the
driver read from the MAG, and return the result to
the IMU again, which would then store both results in a buffer, until
an application in user space decide to read it.

I am having trouble writing the Imu <=> Adc and Imu <=> Mag
communication part, did I got it wrong ?

Best regards,
Bertrand

             reply	other threads:[~2009-10-16  8:58 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-16  8:50 Bertrand Roussel [this message]
2009-10-17  0:34 ` Ben Nizette
2009-10-17 16:05 ` Jonathan Cameron

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=a5b9b4700910160150o146a8f21n1c76c14755d64da8@mail.gmail.com \
    --to=bertrand.roussel@cor-net.org \
    --cc=linux-kernel@vger.kernel.org \
    /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

all inboxes | Powered by JetHome®