<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 15-03-2015 12:32, Alan Cudmore
wrote:<br>
</div>
<blockquote
cite="mid:CAJrjN73NyTCmrbPKYBdXpXmFHnFWZP88mzWR92E7seJmsrAeJA@mail.gmail.com"
type="cite">
<div dir="ltr">Nice work Qiao!
<div><br>
<div>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.</div>
</div>
</div>
</blockquote>
<br>
I have addressed almost every Pavel's suggestion
(<a class="moz-txt-link-freetext" href="https://lists.rtems.org/pipermail/devel/2014-October/008911.html">https://lists.rtems.org/pipermail/devel/2014-October/008911.html</a>),
and the current code can be found on my last commit on my github
(<a class="moz-txt-link-freetext" href="https://github.com/asuol/rtems/commit/eca62b41521da2e606f38320d31c83ec82e30ab6">https://github.com/asuol/rtems/commit/eca62b41521da2e606f38320d31c83ec82e30ab6</a>).<br>
<br>
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.<br>
<br>
<blockquote
cite="mid:CAJrjN73NyTCmrbPKYBdXpXmFHnFWZP88mzWR92E7seJmsrAeJA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote
cite="mid:CAJrjN73NyTCmrbPKYBdXpXmFHnFWZP88mzWR92E7seJmsrAeJA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>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.</div>
<div><br>
</div>
</div>
</div>
</blockquote>
<br>
I should receive my PI2 sometime this week, so I may be able to have
a look at it then.<br>
<br>
--André.<br>
<br>
<blockquote
cite="mid:CAJrjN73NyTCmrbPKYBdXpXmFHnFWZP88mzWR92E7seJmsrAeJA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>Alan</div>
<div><br>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sun, Mar 15, 2015 at 7:11 AM, Gedare
Bloom <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote"><span class="">On Sun, Mar 15,
2015 at 5:50 AM, QIAO YANG <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:yangqiao0505@me.com"
target="_blank">yangqiao0505@me.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<div>Hi !<br>
<br>
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).<br>
<br>
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. <br>
<br>
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. <br>
<br>
</div>
</div>
</blockquote>
</span>
<div><span class="">
<div>The obvious projects I see from <a
moz-do-not-send="true"
href="https://devel.rtems.org/wiki/Developer/Projects/Open/ImproveRaspberryPiBSP"
target="_blank">https://devel.rtems.org/wiki/Developer/Projects/Open/ImproveRaspberryPiBSP</a>
are:<br>
</div>
<div>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.<br>
</div>
<div>2) #5 Graphics Frame Buffer + #7
HDMI/Graphics console<br>
</div>
<div>3) #6 USB + #7 Networking<br>
</div>
<div>4) Raspberry Pi 2 support, but this probably
isn't enough.<br>
<br>
</div>
</span><span class="HOEnZb"><font color="#888888">-Gedare<br>
</font></span></div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>