Both I and Paolo are engineers (BEng) in embedded systems. I had made 2 (kernel space) drivers before (not in the kernel tree), and Paolo had done "ARM7TDMI and DSP speech codecs programming before, ... and RasPi has a DSP" <-- I'm quoting a tweet from Paolo.

The Foundation will not include a GPIO driver in the initial release, standard Linux GPIO drivers should work with minimal modification.
The Foundation will not include an SPI driver in the initial release, we hope the community might write one.
The Foundation will not include an I²C driver in the initial release, we hope the community might provide one, standard Linux I²C drivers should work with minimal modification.

We will make the kernel space device drivers mentioned in the above list, except the first. If GPIO is done via polling everything from the above list will be made.

We can, of course, not release anything before we have a Pi to test the drivers on.

I'm writing on a more detailed Readme file, which is to be released on this projects GitHub page.

I will post a link to the repository at GitHub as soon as i have just a little bit to show: Readme file, userland documentation (how to use device drivers from programs/software libraries), and of course the kernel source code and example userland (C) source code, including kernel source code for the alpha (=unstable, for daredevils only) device drivers.

Note that SPI and (high-speed) I²C makes it possible to have audio/mic input for the Pi via a 16-bit stereo ADC chip and some custom electronics.

The device driver could, if instructed to do so, redirect raw audio capture from a specific SPI port (SPI1 or SPI2) or I²C device to Linux's sound subsystem. Any desktop should then discover the new sound device via the X11 server (or in the near future: Wayland). Programs are also capable of discovering the audio device.

If anyone is working on SPI and I²C kernel space device drivers for the Pi, i would like to know about it.

And now 3 question to the reader. Thanks to anyone in advance for any useful answer.

1st Question:

I have to ask this question about the GPIO and the Pi:
Does it use polling or does it use the hardware-interrupt support from the BCM2835?

If polling is used, then there is a room for optimization (read: Use hardware-interrupt + a tiny kernel space driver + a UIO driver).

2nd question:

How do you make layered device drivers in the Linux kernel? How to depend on some lower level device driver? Post links if you know anything. Thanks.

Based on what has been said in the past on this forum, I believe 2708 and 2835 are either the same or at least have the same peripherals. But somebody please correct me if this is not the case.

Lars T. Hansen said:

I have to ask this question about the GPIO and the Pi:
Does it use polling or does it use the hardware-interrupt support from the BCM2835?

If polling is used, then there is a room for optimization (read: Use hardware-interrupt + a tiny kernel space driver + a UIO driver).

The GPIO driver appears to already exist here: https://github.com/raspberrypi/linux/bl ... 708_gpio.c and it does seem to have optional support for interrupts. I don't know if it is complete or if it needs any modifications for the Raspberry PI. The GPIO subsystem of the kernel already has a userspace interface, which allows both polling and waiting for events.

How do you make layered device drivers in the Linux kernel? How to depend on some lower level device driver? Post links if you know anything. Thanks.

If you mean, how do you interface the bus drivers with the SPI and I²C subsystems – you can check Documentation/spi and Documentation/i2c in the kernel tree. You can also look at the the existing drivers in drivers/spi and drivers/i2c/busses. The bitbang/gpio examples (spi_bitbang and i2c-gpio) are more generic and may be easier to follow and there is also i2c-stub.

Thanks for the reply from you, and forum users Enlightenment, and bjs. Nice to know that another is writes on a SPI device driver.

I will make an I²C host device driver for the Pi.

From Paolo's tweets i guess that he is interested in doing something with stereo sound input. Maybe a SPI client driver for the Linux sound subsystem?, and the hardware to make it possible <— 16-bit ADC chips is difficult to use, because of analog noise.

Yes I am, but I am waiting for an answer from forum user selsinork. He has a Pi and can start working on a host adapter driver. I can only start working when I have a Pi.

... so you are doing memory mapped i/o?

That does only works if you are doing I²C I/O from only 1 program, because you will get concurrency troubles if more than 1 program try to do memory mapped I²C I/O on 1 I²C bus.

You program is also very inefficient (context switches).

You should use i2c-dev and do a Linux UIO device driver, and let the I²C host adapter driver speak with the I²C hardware. The i2c-dev client device driver will then talk with an I²C host adapter driver.

This is the Linux driver model.

Apropos busy waiting. That can be avoided, because an I²C host adapter driver can make use of the I²C hardware interrupts. You code cannot do that because you software are not in kernel space. You does of course need to have a time-out soft intterupt running (the full capacity of the write FIFO and/or the read FIFO can be not used completely). FIFOs are 16-byte in length and are read from and written to on the same address.

For now you can use 2 GPIO pins, the i2c-gpio host adapter driver, and the i2c-dev client device driver to create Linux UIO drivers in userspace.

If you are lucky there are already a client device driver in kernel space for you I²C hardware.

Yes I am, but I am waiting for an answer from forum user selsinork. He has a Pi and can start working on a host adapter driver. I can only start working when I have a Pi.

I'll be starting to look at it over the next few days, however I'm currently limited to compiling the kernel on the Pi and that's a bit slower than I'm used to on a 64 core x86, so I may be a while..

I'm in the process of ordering some parts for an I2C RTC, so I may not make lots of progress until I get that built.

Maybe we should create a repo on github so that several of us can contribute ? Even if only a few can actually test stuff, others can pitch in and help fix my crappy coding

You can cross-compile for the Pi on x86 - also you only have to create a kernel with debugging, and the I²C subsystem enabled only once.

I expect the kernel module to be tiny (a <15 KB bcm2835-i2c.ko file), so it doesn't take that long to compile on the Pi, and cross-compileing on x86 should be very fast.

I had been in the process of creating a GitHub repo but I got stuck, because I couldn't remember the password to my key, so I has to recreate the key again.

I think it is a very good idea to do code peer-reviews. I had good experience with working 2 (or more) on a project, also my Linux kernel hacking knowledge is a little bit rusty - it is about 3 years ago since i last did 2 kernel space device drivers.

BTW i'm larsth on GitHub, and @LarsTHansen on Twitter, and larsth on IRC (freenode), if my computer is running i am online at the #raspberrypi channel.

Both I and Paolo are engineers (BEng) in embedded systems. I had made 2 (kernel space) drivers before (not in the kernel tree), and Paolo had done "ARM7TDMI and DSP speech codecs programming before, ... and RasPi has a DSP" <-- I'm quoting a tweet from Paolo.

The Foundation will not include a GPIO driver in the initial release, standard Linux GPIO drivers should work with minimal modification.
The Foundation will not include an SPI driver in the initial release, we hope the community might write one.
The Foundation will not include an I²C driver in the initial release, we hope the community might provide one, standard Linux I²C drivers should work with minimal modification.

We will make the kernel space device drivers mentioned in the above list, except the first. If GPIO is done via polling everything from the above list will be made.

We can, of course, not release anything before we have a Pi to test the drivers on.

I'm writing on a more detailed Readme file, which is to be released on this projects GitHub page.

I will post a link to the repository at GitHub as soon as i have just a little bit to show: Readme file, userland documentation (how to use device drivers from programs/software libraries), and of course the kernel source code and example userland (C) source code, including kernel source code for the alpha (=unstable, for daredevils only) device drivers.

Note that SPI and (high-speed) I²C makes it possible to have audio/mic input for the Pi via a 16-bit stereo ADC chip and some custom electronics.

The device driver could, if instructed to do so, redirect raw audio capture from a specific SPI port (SPI1 or SPI2) or I²C device to Linux's sound subsystem. Any desktop should then discover the new sound device via the X11 server (or in the near future: Wayland). Programs are also capable of discovering the audio device.

If anyone is working on SPI and I²C kernel space device drivers for the Pi, i would like to know about it.

And now 3 question to the reader. Thanks to anyone in advance for any useful answer.

1st Question:

I have to ask this question about the GPIO and the Pi:
Does it use polling or does it use the hardware-interrupt support from the BCM2835?

If polling is used, then there is a room for optimization (read: Use hardware-interrupt + a tiny kernel space driver + a UIO driver).

2nd question:

How do you make layered device drivers in the Linux kernel? How to depend on some lower level device driver? Post links if you know anything. Thanks.

Does the BCM2835 and the BCM2708 shares some of the same on-chip peripherals? If yes, which?

What is you opinion about these device drivers?

Would you use SPI, and I²C in you own DIY hardware project together with a Pi?

Thank you for offering to develop these drivers. I have a PIC controlled system, which uses I2C to communicate with two devices:

1. Supercap backuped RTC and Thermometer (DS1629)

2. Seven segment LED driver (SAA1064)

I can make available the schematics right the way, but the PCB has a connector with a different pinout than the Raspberrz Pi requires (an adapting cable is needed). I am also not sure, whether the RaPi can deliver enough power for the Seven segment LED display (4 digits).

Thank you for offering to develop these drivers. I have a PIC controlled system, which uses I2C to communicate with two devices:
1. Supercap backuped RTC and Thermometer (DS1629)

2. Seven segment LED driver (SAA1064)

I can make available the schematics right the way, but the PCB has a connector with a different pinout than the Raspberrz Pi requires (an adapting cable is needed). I am also not sure, whether the RaPi can deliver enough power for the Seven segment LED display (4 digits).

You only need 3 pins: SDA, SCL, and the return-signal wire GND. I guess that if you use a stupid USB hub (one which doesn't try to control the +5 volt power) you can power the Pi and anything connected to it, but be careful not to burn the +5 volt wires on the RPi PCB: Because of that it might be better idea to use a separate USB cable from that stupid USB hub to power you expansion board.

Note that SDA and SCL I²C signals are 3,3 volt and are not 5 volt tolerant.

You drivers are so called I²C client device drivers, they talk with an I²C host adapter driver <– the one i and selsinork will make.

Currently you can use another host adapter driver which uses GPIO pins, its name is i2c-gpio.

With the i2c-dev client device driver in kernel space you can build you client device drivers in user space as a software library (a *.so file). Note that there are existing client device drivers in the kernel, and lm-sensors also have a lot of client device drivers (link to website in an previous post in this thread).

With the i2c-gpio and the i2c-dev drivers you can get something to work before I and selsinork have the host adapter driver ready for real use. That can be important if you are doing an embedded system product in a business.

AFAIK the I²C subsystem is not compiled into the current RPi kernel, so you has to cross-compile one with the I²C subsystems enabled. Then you are at configuring a new kernel, do yourself the favour of adding kernel debugging, so you can get a lot more debugging messages form the kernel than usual.

Your I2C client should use an open-drain output to make the high level. That will be 3.3V because that's what the pullups on the RPI are connected to. The other way around, your 5V board will detect anything above 2.5V as high, so 3.3V will suffice.

Your I2C client should use an open-drain output to make the high level. That will be 3.3V because that's what the pullups on the RPI are connected to. The other way around, your 5V board will detect anything above 2.5V as high, so 3.3V will suffice.

I've tested this with a real RPI and a 5V I2C device, and it works.

i wrote:

You board must:

* run on 3,3 volt

or

* use a bi-directional level shifter circuit ...

What i tried to tell you:

So i wrote that if you are using 3,3 volt logic everything is ok=you don't need a level shifter.

However, if it outputs a signal with >3,3 volt logic you should use a level shifter.

The "or" should imply that in the above text, but because English is my 2nd language I might not always be good at explaining advanced stuff in that foreign language.

It is a neat little trick, if it works w/o making harm to the bcm2835.

Your I2C client should use an open-drain output to make the high level. That will be 3.3V because that's what the pullups on the RPI are connected to. The other way around, your 5V board will detect anything above 2.5V as high, so 3.3V will suffice.

I've tested this with a real RPI and a 5V I2C device, and it works.

Am I missing something, or do they want to charge 24 Euro's to shipo it to the UK?

Your I2C client should use an open-drain output to make the high level. That will be 3.3V because that's what the pullups on the RPI are connected to. The other way around, your 5V board will detect anything above 2.5V as high, so 3.3V will suffice.

There's no actual guarantee that a 5v device detects anything over 2.5v as high, you would need to check the datasheet for the part in question to be sure.

"Due to the variety of different technology devices (CMOS, NMOS, bipolar) that can be
connected to the I2C-bus, the levels of the logical ‘0’ (LOW) and ‘1’ (HIGH) are not fixed
and depend on the associated level of VDD. Input reference levels are set as 30 % and
70 % of VDD; VIL is 0.3VDD and VIH is 0.7VDD."

So at 5v, 0.7VDD is 3.5v.

I've tested this with a real RPI and a 5V I2C device, and it works.

The trouble with things like i2c is that it depends a lot on what other devices are on the bus, what speed you're driving it at, are the pullups strong enough to overcome the capacitance of the bus and get the voltage above the threshold in the necessary time etc.
i.e. what works at 100kHz may not at 400kHz, 1MHz, or 3.4MHz

So while it's nice to know that you have something that happens to work for you, I don't think it's something we can assume will always work for everyone. In practise, with a very short bus, it just might, but ymmv.

With all of the SD card problems being posted, I'm always left thinking that things are not always what they seem... something that works for me, but the exact same doesn't for you, just isn't nice and it's damn hard to debug

I should also say that the majority of the i2c devices I've been looking at lately are 3.3v ones anyway.

Indeed, the one I'm looking at for my Pi/rtc project will operate down to 1.8v, so it's quite likely that anything current will happily work at the 3.3v used by the Pi without any problems and no need to worry about 5v at all.

I'm a driver guy from the I2C thread mentioned earlier and must admit I haven't looked at my driver code for at least a week. I'm in the same boat as others here in that I don't have a Pi ... my order might go through by the end of June, but who knows. The driver task looks fairly straight-forward to me and I'm maybe half done (the *easy* half, of course . I'll dig back into it and hopefully have something others can look at this weekend.

selsinork, do you have some I2C device to test talking with the Pi? I'm thinking either a really simple device where it's own data "protocol" won't obscure the driver's behavior or one with existing higher level support would be best. Even without a test device, one might still be able to test that the BSC master can talk using an o-scope.

Is the I2C bus already pulled up on the Pi or does one need to terminate it to do testing?

Other trivia: The 2835 has 3 BSCs (0-2) where BSC2 is dedicated to the HDMI port and out of our hands. I'm focused on making BSC0 work, but since they appear to be identical but for the register mapping, it should work for BSC1 too (assuming it works at all!).