On 15-03-2015 12:32, Alan Cudmore wrote:
Nice work Qiao!
Andre had submitted the patches for GPIO, SPI, and I2C including
recommended fixes. It was then recommended that we switch to the new
Linux based I2C API, and we ( or I ) got stuck there.
I have addressed almost every Pavel's suggestion
(https://lists.rtems.org/pipermail/devel/2014-October/008911.html), and
the current code can be found on my last commit on my github
(https://github.com/asuol/rtems/commit/eca62b41521da2e606f38320d31c83ec82e30ab6).
The difference from the last patch is that now each interrupt handler
runs on its own task, and each user-defined handler may have as many
arguments as the user may want (through a void pointer). Each pin can
also have multiple handlers at the same time, so multiple devices may
share a GPIO pin for interrupts, in which case each handler must inform
if their device acknowledge the interrupt. The code is not yet
thread-safe, so locking and compiler barriers are still missing if they
are to be used on a concurrent environment, will try to conclude as soon
as possible.
For the time I have available, it was not going to be a 1 or 2 day fix
to move Andre's I2C implementation to the new Linux based API. It was
taking me a while just to understand what needed to be done.
A little later today, I will try to come up with a proposal to split
the Pi work so it can be done by 3 participants.. But we need to
decide if re-doing the I2C implementation should be part of the work,
or if we should use Andre's initial implementation as a baseline for
everyone.
As soon as GPIO is in SPI can be sent directly, and the I2C is just a
matter of using the new API, just refactoring the code around a bit to
the new API functions (still have not looked at the new API
unfortunately). Will have a look at it this week.
Also, I will submit basic patches to create a raspberrypi2 BSP
variant. I have built both the raspberrypi and raspberrypi2 BSPs and
tested ticker so far.
I should receive my PI2 sometime this week, so I may be able to have a
look at it then.
--André.
Alan
On Sun, Mar 15, 2015 at 7:11 AM, Gedare Bloom <ged...@rtems.org
<mailto:ged...@rtems.org>> wrote:
On Sun, Mar 15, 2015 at 5:50 AM, QIAO YANG <yangqiao0...@me.com
<mailto:yangqiao0...@me.com>> wrote:
Hi !
I've managed to run a hello demo on RPI B/B+, including a demo
for loading an image by u-boot (I don't have an ethernet cable
on my hand, but I'm going to be able to load the image by tftp
for dev).
If I've got it right, to prepare my proposal I may choose part
of the TODO list , look into the implementation detail and
schedule it. The work list may be divided for 3 students to
complete.
I've checked out the André's branch with GPIO, I2C, SPI
implementations. Should we develop based on his branch or the
upstream? Have we said that the I2C, SPI API has changed? I
wonder that if anyone is working on it and if we will merge
Andre's work to upstream at the begining of GSOC. If not,
maybe I can get start by trying to do this job.
The obvious projects I see from
https://devel.rtems.org/wiki/Developer/Projects/Open/ImproveRaspberryPiBSP
are:
1) Get #1-3 mergeable. May not take much. Then do #4 SD-card
support and refactor the i2c to use the newer cpukit/dev/i2c
interface.
2) #5 Graphics Frame Buffer + #7 HDMI/Graphics console
3) #6 USB + #7 Networking
4) Raspberry Pi 2 support, but this probably isn't enough.
-Gedare
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
