gmane.comp.hardware.qi.general

NanoNote Roadmap

Paul Boddie — 2013-06-17T22:06:41

Hello,

Recently, there's been some apparent discontent expressed on the wiki about 
the NanoNote roadmap. Personally, I think it's distasteful to just write on 
wiki pages that those pages are "lies" and that they should be removed in 
shame by those who didn't deliver the goodies on schedule, but then I may 
have a somewhat old-fashioned perspective on what polite behaviour is. 
Starting an IRC or mailing list flame war would at least be engaging with 
other people, if not exactly polite, either.

Usually, it's Ron who brings up this topic, and I hope he is still reading 
this list, but maybe it's worth having a "State of the NanoNote" discussion. 
Maybe it would have to take the form of how one would do another NanoNote 
today, given that there isn't a button one can push to just resume 
everything, but I suppose that activity around open hardware is now at a 
completely different level to what it was a few years ago and that we could 
bring in things that other people are doing, too. I think someone suggested 
on IRC that I should be doing a qi-hardware newsletter, but I'll say "no" to 
that suggestion for now. ;-)

Probably most similar to the NanoNote architecturally is the GCW Zero, which 
appears to be almost available:

"The GCW Zeros will be shipped from US to Germany on June 20th. They should be 
available about 10 - 14 days later (depends on shipping speed)."

https://www.dragonbox.de/en/gcw-zero/111-gcw-zero.html

Maybe this is the closest there is, at least in terms of the numbers in the 
specification, to what might be expected of a NanoNote successor, although 
there are obviously things that may not be friendly to Free Software such as 
the Vivante GPU. Obviously the form factor is different, although I suppose 
you could plug in a USB keyboard and make your own clamshell exoskeleton like 
all those tablet keyboard docks that have appeared (and that Raspberry 
Pi "laptop" somebody did).

Elsewhere, the Rhombus Tech people seem to have been making some progress with 
their EOMA-68 card and, more interestingly, the Flying Squirrel tablet that 
the KDE developers wanted:

http://rhombus-tech.net/community_ideas/kde_tablet/news/

Although some people are critical of the whole EOMA-68 concept, I think that 
the community around it seems to have knowledgeable people in a range of 
areas, and collaboration with some of them could be interesting.

Does anyone have (or know of) any interesting NanoNote-related projects going 
on, whether it is just to extend the Ben or to make something similar? 
Personally, I'm more intrigued as to whether we are capable of making a 
successor than wanting one myself: I'm quite happy to use the Ben every now 
and again when I get the time.

Paul

Re: Iris

Bas Wijnen — 2013-06-04T21:34:57

There wasn't, but it's my own preprocessing tool so I just uploaded it
to github: http://github.com/wijnen/pypp/.

After running that, it's just normal C++ code, indeed (except that I'm
not using any features that require the standard library, such as
constructors or virtual functions).

I hope that helps.

Thanks for asking,
Bas

Mplayer OSD Menu For A GUI & Resume Playback Script

Alexander Stephen Thomas Ross — 2013-06-03T12:42:28

A decent,mostly complete Mplayer GUI/Interface, Menu System. Done using 
Mplayer1's OSD Menu Feature. Please note the fork mplayer2 does not 
support osd menu. There's a help text: 
/usr/share/doc/mplayerosdmenu/osdmenuhelp.txt with some info it it and 
the commands:

mp [file]

Note that "mp" does not need any parameters.

mp-dir <dir>


Included is a script for resuming playback from when you left off. 
Meaning you can start the movie you were watching earlier from where you 
stopped. Needs more work do on it. Originally it's bash script that 
expects full gnu bash programs so I have been finding busybox compatible 
ways of doing things and removing code that is for Xorg and other edits.

http://nn.aross.me/MplayerOSDMenu&Resume/

Finally got around to uploading it!

Re: Iris

Paul Boddie — 2013-06-01T22:23:00

One thing that seems awkward at the moment is obtaining the toolchain to 
compile the code. The code seems to be written in an indentation-based 
variant of C++, reminiscent of a project I saw once called pyplusplus (or 
something similar). Is there a permanent Web page for the toolchain?

Paul

Iris

Bas Wijnen — 2013-06-01T19:51:27

Like Paul, Werner's message triggered me to write something to this list
again.

I have some news, which I consider a breakthrough, but you probably
won't consider it all that important. ;-)  However, if you want to fix a
hard to reproduce bug in Linux, read on.  (Strictly speaking, I didn't
check if the bug really is in Linux, but I think I would have noticed if
it wasn't; I've read that source many times to find the solution for the
bug, and never saw it.)

What was Iris again?  It's my project to write a capability-based
microkernel.  Capability-based means that there is no global path for
communication; all kernel-communication (and therefore inter-process
communication) is done by invoking a capability.  If you don't have a
capability to another process' receiver, you cannot communicate.[1]
(Well, there's shared memory, but to set that up for communication you
need a capability as well.)

The Ben NanoNote is the primary target for this kernel.  I hope to add
other targets when the project is mature enough that that makes sense.

The state some time ago was that I had the kernel working, and I started
writing some userspace tools to test it.  Most hardware had a working
driver (keyboard, display, buzzer, SD card, limited USB; no support for
DMA or sound yet).  The next thing I wanted to do was make the device
wake itself up.  So I started to write a driver for the RTC module,
which can do that.

But things didn't go so well.  I kept locking the device up so badly
that I had to remove the battery and USB cable, wait some time (pressing
the power button seemed to help shortening that time) before powering it
up again.  I was unable to solve this for a long time, and was
demotivated by it; I didn't do any work on Iris for several months.

But now I decided to take a look again, and I found the problem.  And in
fact, this problem may also happen to Linux, where it should be a very
random unreproducible bug.  So it may be important information for those
who want to fix that.

The problem is the following: The RTC is a module which is quite
separate from the rest of the SoC.  In particular, it continues running
when the rest is turned off (the programmer's manual calls this
"hibernation", but it's the closest to "off" you get without removing
power).  Because of this, it was a logical choice of Ingenic to use this
module for wakeup of the device.

So, when the device is off, the RTC remains running and it has three
reasons to power the device on:
- The power button is pressed: power-on reset.  Only possible if the
  device is off.
- The reset button is pressed: similar, but also possible when the
  device is on.
- Timer alarm: timed wake-up.  This is what I wanted to get to work.

There are two registers which are important:
- HRCR (hibernate reset counter register), which determines how long the
  power button must be active before a power-on signal is given to the
  SoC core.  Having a high value in here was the reason the power button
  used to be so slow responding (you'd need to hold it down two seconds).
- HWFCR (hibernate wakeup filter counter register), which determines how
  long the "wake-up" signal is asserted in the event of a wake-up (no
  matter what source).

I had thought that the latter register was meant to allow external
hardware (which can also see this signal) which was slower than the
core, to respond to it.  So I set this to 0.  However, that really does
what it advertises: it asserts the line for 0 seconds, in other words,
not at all.  And then the core doesn't actually boot up.  The only way
to then boot the device again is by powering down long enough that
random data shows up in this register (it is not initialized
automaticaly).  I have now set it to write the maximum value (0xffe0) to
it, and everything works fine, including wake-up by alarm.  (I expect
the lowest value, 0x0020, to work as well, but I didn't check.)

That's it for my update.  If you got this far, I hope you liked it. :-)

If you want to try it out, that is possible.  Please let me know if you
need instructions (you probably do, but I'm not writing them unless
asked for, as they're changing all the time).  I'd like to discuss about
features that could be added (or removed), and I welcome other people
proposing changes (with or without patches).  Don't hesitate to contact
me.

If you want to try things out, but the installation seems prohibitively
hard (I can imagine ;-) ), then just say so and I'll make it a priority
to make it easier.

One cool thing about this project is that it is about the base of the
system; choices are made here that impact everything that runs on it.
Getting it right is a great challenge, IMO. :-)

Thanks,
Bas


[1] This architecture is very nice for security, but also for usability;
it forces developers to be explicit about things.  For example, if you
write a program that opens a window, it is easy to force this specific
window to be "always on top" or "start hidden" or whatever.  With X, you
can achieve similar results by instructing the window manager to handle
this for you.  But it's realy hard to start a program in a way that X
will know that the window opened by that program is the one you mean,
but another window opened by a different (or the same) instance of the
same program is not.  That's because the way it works is that you have
to tell the window manager what the program looks like (normally through
its class or window title) and there's no reason other programs can't
have these same features.

Some NanoNote Hardware Experiments

Paul Boddie — 2013-06-01T17:29:06

Hello,

Werner's statistics round-up has once again prompted me to post to the list. 
This time, it's about some experiments I have been doing with the Ben's 8:10 
port, with the Universal Breakout Board (or equivalents) being used to 
interface to various devices.

First off, some work to interface with an Arduino USB Host shield:

http://hgweb.boddie.org.uk/ben-arduino-usb/

Since such shields can provide USB Host capabilities to devices like the 
Arduino Duemilanove, it's not too surprising that they can do so for the Ben 
as well, although the Arduino's ATmega CPU provides hardware support for SPI, 
which is the mechanism used to talk to the shield's MAX3421E controller, and 
thus the Arduino is actually more capable than the Ben in this respect.

So far, I've only really managed to replicate some of the capabilities that 
the Arduino libraries provide, but basic communication is in place, and it's 
possible to get information from devices and to manage connections and 
disconnections. Managing the different USB workflows and supporting things 
like the Human Interface Device framework is tedious work, and the next step 
might reasonably be supporting this hardware as a kernel module instead, 
delegating the tedious stuff to code hopefully already written.

Another thing I got to play with recently was an e-paper display module using 
a screen from Pervasive Displays:

http://hgweb.boddie.org.uk/ben-epaper/

There is documentation and code available for displays from this vendor, and 
it seems that they are trying to get people to use their equipment. (Given 
that I've seen e-paper displays as shelf pricing labels in at least one 
supermarket, they may be getting somewhere.) I'm not sure whether my display 
module is open hardware, but Adafruit do seem to sell a similar module which 
might well be.

Neither of these projects are necessarily practical, and they may not inform 
us very much about hypothetical future NanoNotes. For USB, one would choose a 
SoC with built-in USB Host support which is exposed to the outside world; an 
e-paper display is useful as a secondary screen, but would be frustrating as 
the primary screen for this kind of device. Nevertheless, they do provide 
some experience with the technologies involved and help us decide whether 
they would be worthwhile supporting in future.

I hope this is interesting to some of you, at least.

Paul

Statistics: May 2013

Werner Almesberger — 2013-06-01T13:50:53

A quick update from the statistics department:

IRC traffic on #qi-hardware and #milkymist:

http://downloads.qi-hardware.com/people/werner/stat/irc-qihw-0513.png

The mailing lists:

http://downloads.qi-hardware.com/people/werner/stat/ml-qihw-0513.png

The Qi-Hardware mailing list took a vow of silence for this month
while the Milkymist list improved upon its already good April
result, mainly because of Yann's valiant MMU effort.

The IRC situation is similar, but the drop on #qi-hardware was less
pronounced than on the corresponding mailing list while #milkymist
had its busiest month since almost one year, mainly fueled by the
debugging of the new video mixer. For overall IRC traffic, we lately
(since December) have a pattern of busy and idle months neatly
alternating, where the busy ones have 120-150 kB/month while the
idle ones end up below 100 kB/month.

- Werner

Mic Interference :(

Alexander Stephen Thomas Ross — 2013-05-10T00:24:12

There is interference when recording from the mic. Recently I've been 
wondering if it is when the screen is updated or on or off.

Here is a dump of public domain (not that there much use.) recordings I 
have made: http://sutff.aross.me

Some are recorded in my computer room of interference doom, outside the 
house, in a school hall, on a walk, etc.

Some recordings are ok for 20secs then the interference kicks in :(.

I can upload more. In fact I think I have some that are a bit different 
from the ones I have uploaded. It's a start.

I have also tried experimenting with different sample rates. 200*-CD

Any thoughts please?

spidev (was Re: Carabola)

Paul Boddie — 2013-05-06T08:57:22

Actually, having surfed around on their wiki, I managed to discover a few 
things that I wasn't previously aware of. On an example of using Python with 
SPI...

http://8devices.com/wiki_carambola/doku.php/using_spi_from_python

...there's a mention of an SPI library for Python...

https://pypi.python.org/pypi/SPIlib/

...that mentions the spidev API for Linux...

https://www.kernel.org/doc/Documentation/spi/spidev

...and then I started to wonder how Werner's recent work fits into that, if at 
all. I only ask because if I get round to doing more stuff with the 8:10 
port, it might be interesting to consider how the Linux kernel supports SPI 
and as a first step to writing a kernel driver, I might want to look into 
this (although I'm not totally convinced, given that libubb seems to offer a 
reasonable level of abstraction for SPI).

Sorry for taking your thread in another direction, Ron!

Paul

Carabola

Ron K. Jeffries — 2013-05-06T01:03:12

Uses MIPS, runs OpenWrt, a collection of useful peripheral interfaces.
One might assume you could choose to not include BLOBs for e.g. wi-fi.

To a non-specialist [moi...], it appears they are making a serious effort
in direction of open hardware. This is not at teh level of a fully open
FPGA based computer or an SOC derived from a design proven via FPGA.

This may be total junk. I' confident people will inform me of all that's
wrong with it. ;)

http://8devices.com/carambola-2

p.s. I know very little about the company, nor am I affiliated in any way.
---
Ron K. Jeffries

Statistics: April 2013

Werner Almesberger — 2013-05-01T17:15:41

It's Worker's Day and time for the statistics department to do
some work:

IRC traffic on #qi-hardware and #milkymist:

http://downloads.qi-hardware.com/people/werner/stat/irc-qihw-0413.png

The mailing lists:

http://downloads.qi-hardware.com/people/werner/stat/ml-qihw-0413.png

The mailing lists maintained their usual level of traffic, with
a slight overall increase making April the busiest month of this
year so far. Qi-Hardware dropped a little while Milkymist saw
more activity. This resulted in Milkymist coming out on ahead of
Qi-Hardware, something that only happened three times within the
last year.

On IRC, things were relatively quiet, very similar to February.
This also ended the three months of continuous growth of
Milkymist IRC traffic.

- Werner

[RFC 3/3] add ATBEN framework for Ben NanoNote in arch/mips/jz4740/

Werner Almesberger — 2013-04-30T00:16:19

These are the driver and device definitions, and a platform-specific
reset function needed for operating an ATBEN IEEE 802.15.4 board on
the Ben NanoNote (aka QI_LB60).
---
 Kconfig         |   10 ++++
 Makefile        |    1 
 atben-qi_lb60.c |  124 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 135 insertions(+)

diff --git a/arch/mips/jz4740/Kconfig b/arch/mips/jz4740/Kconfig
index 4689030..3b0cde1 100644
--- a/arch/mips/jz4740/Kconfig
+++ b/arch/mips/jz4740/Kconfig
< at >< at > -6,4 +6,14 < at >< at > choice
 config JZ4740_QI_LB60
 bool "Qi Hardware Ben NanoNote"
 
+config JZ4740_QI_LB60_ATBEN
+bool "ATBEN 8:10 SPI-GPIO framework"
+depends on JZ4740_QI_LB60 && SPI && IEEE802154_AT86RF230
+---help---
+  Framework for the ATBEN IEEE 802.15.4 board in a Ben NanoNote.
+  Combines the AT86RF230 driver with a suitable SPI-GPIO driver
+  and provides glue functions and configuration data.
+
+  Say Y here to enable the ATBEN 8:10 SPI-GPIO framework.
+
 endchoice
diff --git a/arch/mips/jz4740/Makefile b/arch/mips/jz4740/Makefile
index 63bad0e..78a06dd 100644
--- a/arch/mips/jz4740/Makefile
+++ b/arch/mips/jz4740/Makefile
< at >< at > -12,6 +12,7 < at >< at > obj-$(CONFIG_DEBUG_FS) += clock-debugfs.o
 # board specific support
 
 obj-$(CONFIG_JZ4740_QI_LB60)+= board-qi_lb60.o
+obj-$(CONFIG_JZ4740_QI_LB60_ATBEN) += atben-qi_lb60.o
 
 # PM support
 
diff --git a/arch/mips/jz4740/atben-qi_lb60.c b/arch/mips/jz4740/atben-qi_lb60.c
new file mode 100644
index 0000000..148b2fd
--- /dev/null
+++ b/arch/mips/jz4740/atben-qi_lb60.c
< at >< at > -0,0 +1,124 < at >< at >
+/*
+ * atben-qi_lb60.c - SPI-GPIO framework for ATBEN on Jz4740
+ *
+ * Written 2011, 2013 by Werner Almesberger
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ */
+
+#include <linux/kernel.h>
+#include <linux/platform_device.h>
+#include <linux/interrupt.h>
+#include <linux/gpio.h>
+#include <linux/delay.h>
+#include <linux/spi/spi.h>
+#include <linux/spi/spi_gpio.h>
+#include <linux/spi/at86rf230.h>
+#include <asm/mach-jz4740/gpio.h>
+
+
+#if defined(CONFIG_SPI_JZ4740_GPIO) || defined(CONFIG_SPI_JZ4740_GPIO_MODULE)
+#defineSPI_GPIO_DRIVER"spi_jz4740_gpio"
+#else
+#defineSPI_GPIO_DRIVER"spi_gpio"
+#endif
+
+enum {
+VDD_OFF= 2,/* VDD disable, PD02 */
+MOSI= 8,/* CMD, PD08 */
+SLP_TR= 9,/* CLK, PD09 */
+MISO= 10,/* DAT0, PD10 */
+SCLK= 11,/* DAT1, PD11 */
+IRQ= 12,/* DAT2, PD12 */
+nSEL    = 13,/* DAT3/CD, PD13 */
+};
+
+
+/* ----- ATBEN reset ------------------------------------------------------- */
+
+
+static void atben_reset(void *dummy)
+{
+const int charge = 1 << nSEL | 1 << MOSI | 1 << SLP_TR | 1 << SCLK;
+const int discharge = charge | 1 << IRQ | 1 << MISO;
+
+/*
+ * Note: we need the next 6 lines only if using spi-gpio.
+ * Both jz4740_mmc and spi-jz4740-gpio take care of the function
+ * setting and neither need nor are bothered by having the pins
+ * configured here.
+ */
+
+jz_gpio_set_function(JZ_GPIO_PORTD(MOSI), JZ_GPIO_FUNC_NONE);
+jz_gpio_set_function(JZ_GPIO_PORTD(MISO), JZ_GPIO_FUNC_NONE);
+jz_gpio_set_function(JZ_GPIO_PORTD(SCLK), JZ_GPIO_FUNC_NONE);
+jz_gpio_set_function(JZ_GPIO_PORTD(nSEL), JZ_GPIO_FUNC_NONE);
+jz_gpio_set_function(JZ_GPIO_PORTD(SLP_TR), JZ_GPIO_FUNC_NONE);
+jz_gpio_set_function(JZ_GPIO_PORTD(IRQ), JZ_GPIO_FUNC_NONE);
+
+jz_gpio_port_set_value(JZ_GPIO_PORTD(0), 1 << VDD_OFF, 1 << VDD_OFF);
+jz_gpio_port_direction_output(JZ_GPIO_PORTD(0), discharge);
+jz_gpio_port_set_value(JZ_GPIO_PORTD(0), 0, discharge);
+msleep(100);    /* let power drop */
+
+/*
+ * Hack: PD12/DAT2/IRQ is an active-high interrupt input, which is
+ * indicated by setting its direction bit to 1. We thus must not
+ * configure it as an "input".
+ */
+jz_gpio_port_direction_input(JZ_GPIO_PORTD(0), 1 << MISO);
+jz_gpio_port_set_value(JZ_GPIO_PORTD(0), charge, charge);
+msleep(10);     /* precharge caps */
+
+jz_gpio_port_set_value(JZ_GPIO_PORTD(0), 0,
+       1 << VDD_OFF | 1 << SLP_TR | 1 << SCLK);
+msleep(10);
+}
+
+
+/* ----- SPI driver/device matching ---------------------------------------- */
+
+
+static const struct at86rf230_platform_data at86rf230_platform_data = {
+.rstn= -1,/* use reset function instead */
+.slp_tr= -1,/* not used */
+.dig2= -1,
+.irq_type= IRQF_TRIGGER_HIGH,
+.reset= atben_reset,
+};
+
+static struct spi_board_info atben_board_info = {
+.modalias= "at86rf230",
+/* set .irq later */
+.chip_select= 0,
+.bus_num= 2,
+.max_speed_hz= 8 * 1000 * 1000,
+.controller_data = (void *) JZ_GPIO_PORTD(nSEL),
+.platform_data= &at86rf230_platform_data,
+};
+
+struct spi_gpio_platform_data atben_spi_gpio_platform_data = {
+.mosi= JZ_GPIO_PORTD(MOSI),
+.miso= JZ_GPIO_PORTD(MISO),
+.sck= JZ_GPIO_PORTD(SCLK),
+.num_chipselect= 1,
+};
+
+static struct platform_device atben_device = {
+.name= SPI_GPIO_DRIVER,
+.id= 2,
+.dev= {
+.platform_data = &atben_spi_gpio_platform_data,
+},
+};
+
+static int __init atben_init(void)
+{
+atben_board_info.irq = gpio_to_irq(JZ_GPIO_PORTD(IRQ));
+spi_register_board_info(&atben_board_info, 1);
+
+return platform_device_register(&atben_device);
+}
+device_initcall(atben_init);

[RFC 2/3] SPI-GPIO variant optimized for the Ingenic Jz4740 SoC

Werner Almesberger — 2013-04-30T00:15:46

This is a drop-in replacement for spi-gpio.c optimized for Jz4740-based
systems. It is up to about six times faster than its generic counterpart.
Only supports SPI mode 0 and CS active-low. Furthermore, MOSI, MISO, and
SCK must be on the same port.

A detailed performance analysis can be found here:
http://projects.qi-hardware.com/index.php/p/ben-wpan/source/tree/master/atben/misc/atben-spi-performance.txt
---
 Kconfig           |    8 +
 Makefile          |    1 
 spi-jz4740-gpio.c |  424 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 433 insertions(+)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 2be0de9..897bdda 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
< at >< at > -187,6 +187,14 < at >< at > config SPI_IMX
   This enables using the Freescale i.MX SPI controllers in master
   mode.
 
+config SPI_JZ4740_GPIO
+tristate "GPIO-based SPI Master for Ingenic Jz4740"
+depends on GENERIC_GPIO && MACH_JZ4740
+select SPI_BITBANG
+help
+  This is a variant of SPI-GPIO optimized for the Ingenic Jz4740.
+  Only supports SPI mode 0 and CS active-low.
+
 config SPI_LM70_LLP
 tristate "Parallel port adapter for LM70 eval board (DEVELOPMENT)"
 depends on PARPORT
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index e53c309..18e5aee 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
< at >< at > -33,6 +33,7 < at >< at > obj-$(CONFIG_SPI_FSL_ESPI)+= spi-fsl-espi.o
 obj-$(CONFIG_SPI_FSL_SPI)+= spi-fsl-spi.o
 obj-$(CONFIG_SPI_GPIO)+= spi-gpio.o
 obj-$(CONFIG_SPI_IMX)+= spi-imx.o
+obj-$(CONFIG_SPI_JZ4740_GPIO)+= spi-jz4740-gpio.o
 obj-$(CONFIG_SPI_LM70_LLP)+= spi-lm70llp.o
 obj-$(CONFIG_SPI_MPC512x_PSC)+= spi-mpc512x-psc.o
 obj-$(CONFIG_SPI_MPC52xx_PSC)+= spi-mpc52xx-psc.o
diff --git a/drivers/spi/spi-jz4740-gpio.c b/drivers/spi/spi-jz4740-gpio.c
new file mode 100644
index 0000000..d8cdbfd
--- /dev/null
+++ b/drivers/spi/spi-jz4740-gpio.c
< at >< at > -0,0 +1,424 < at >< at >
+/*
+ * spi-jz4740-gpio.c - Bit-banging SPI host for the Jz4740
+ *
+ * Written 2011, 2013 by Werner Almesberger
+ * Based on spi-gpio.c, Copyright (C) 2006,2008 David Brownell
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ */
+
+/*
+ * This is a drop-in replacement for spi-gpio.c optimized for Jz4740-based
+ * systems. It is up to about six times faster than its generic counterpart.
+ *
+ * There are three restrictions and usage differences:
+ *
+ * 1) No other configurations than SPI mode 0 and CS active-low are
+ *    supported.
+ *
+ * 2) MOSI, MISO, and SCK must be on the same port. Driver probing fails
+ *    if they are not.
+ *
+ * 3) struct platform_device.name must be "spi_jz4740_gpio" instead of
+ *    "spi_gpio".
+ */
+
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/io.h>
+#include <linux/platform_device.h>
+#include <linux/gpio.h>
+#include <linux/spi/spi.h>
+#include <linux/spi/spi_gpio.h>
+#include <asm/mach-jz4740/base.h>
+
+
+#defineDRIVER_NAME"spi_jz4740_gpio"
+
+struct spi_jz4740_gpio {
+const struct spi_gpio_platform_data *pdata;
+struct device*dev;
+void __iomem*port_base;
+uint32_tmosi, miso, sck;
+unsigned longport_addr;
+};
+
+#definePxPIN(prv->port_base)
+#definePxDATS(prv->port_base+0x14)
+#definePxDATC(prv->port_base+0x18)
+
+#definePIN_TO_PORT(pin)((pin) >> 5)
+#definePIN_TO_MASK(pin)(1 << ((pin) & 31))
+
+
+/* ----- SPI transfers ----------------------------------------------------- */
+
+
+static void rx_only(const struct spi_jz4740_gpio *prv, uint8_t *buf, int len)
+{
+uint32_t miso = prv->miso;
+uint32_t sck = prv->sck;
+uint8_t v;
+
+while (len--) {
+writel(sck, PxDATS);
+v = readl(PxPIN) & miso ? 0x80 : 0;
+writel(sck, PxDATC);
+
+#defineDO_BIT(m)\
+writel(sck, PxDATS);\
+if (readl(PxPIN) & miso)\
+v |= (m);\
+writel(sck, PxDATC)
+
+DO_BIT(0x40);
+DO_BIT(0x20);
+DO_BIT(0x10);
+DO_BIT(0x08);
+DO_BIT(0x04);
+DO_BIT(0x02);
+DO_BIT(0x01);
+
+#undef DO_BIT
+
+*buf++ = v;
+}
+}
+
+
+static void tx_only(const struct spi_jz4740_gpio *prv,
+const uint8_t *buf, int len)
+{
+uint32_t mosi = prv->mosi;
+uint32_t sck = prv->sck;
+uint8_t tv;
+
+while (len--) {
+tv = *buf++;
+
+if (tv & 0x80) {
+writel(mosi, PxDATS);
+goto b6_1;
+} else {
+writel(mosi, PxDATC);
+goto b6_0;
+}
+
+#defineDO_BIT(m, this, next)\
+this##_1:\
+writel(sck, PxDATS);\
+if (tv & (m)) {\
+writel(sck, PxDATC);\
+goto next##_1;\
+} else {\
+writel(mosi | sck, PxDATC);\
+goto next##_0;\
+}\
+this##_0:\
+writel(sck, PxDATS);\
+writel(sck, PxDATC);\
+if (tv & (m)) {\
+writel(mosi, PxDATS);\
+goto next##_1;\
+} else {\
+goto next##_0;\
+}
+
+DO_BIT(0x40, b6, b5);
+DO_BIT(0x20, b5, b4);
+DO_BIT(0x10, b4, b3);
+DO_BIT(0x08, b3, b2);
+DO_BIT(0x04, b2, b1);
+DO_BIT(0x02, b1, b0);
+DO_BIT(0x01, b0, done);
+
+#undef DO_BIT
+
+done_1:
+done_0:
+writel(sck, PxDATS);
+writel(sck, PxDATC);
+}
+}
+
+
+static void bidir(const struct spi_jz4740_gpio *prv,
+const uint8_t *tx, uint8_t *rx, int len)
+{
+uint32_t mosi = prv->mosi;
+uint32_t miso = prv->miso;
+uint32_t sck = prv->sck;
+uint8_t mask, tv, rv = 0;
+
+while (len--) {
+tv = *tx++;
+for (mask = 0x80; mask; mask >>= 1) {
+if (tv & mask)
+writel(mosi, PxDATS);
+else
+writel(mosi, PxDATC);
+writel(sck, PxDATS);
+if (readl(PxPIN) & miso)
+rv |= mask;
+writel(sck, PxDATC);
+}
+*rx++ = rv;
+}
+}
+
+
+static inline unsigned get_nsel(struct spi_device *spi)
+{
+return (unsigned) spi->controller_data;
+}
+
+
+static int spi_jz4740_gpio_transfer_one(struct spi_master *master,
+struct spi_message *msg)
+{
+struct spi_jz4740_gpio *prv = spi_master_get_devdata(master);
+struct spi_device *spi = msg->spi;
+uint32_t nsel = get_nsel(spi);
+struct spi_transfer *xfer;
+const uint8_t *tx;
+uint8_t *rx;
+
+if (unlikely(list_empty(&msg->transfers))) {
+dev_err(&spi->dev, "transfer is empty\n");
+msg->status = -EINVAL;
+goto out;
+}
+
+msg->actual_length = 0;
+msg->status = 0;
+
+gpio_set_value(nsel, 0);
+list_for_each_entry(xfer, &msg->transfers, transfer_list) {
+tx = xfer->tx_buf;
+rx = xfer->rx_buf;
+msg->actual_length += xfer->len;
+
+if (!tx)
+rx_only(prv, rx, xfer->len);
+else if (!rx)
+tx_only(prv, tx, xfer->len);
+else
+bidir(prv, tx, rx, xfer->len);
+}
+gpio_set_value(nsel, 1);
+
+out:
+spi_finalize_current_message(master);
+
+return 0;
+}
+
+
+/* ----- Device-specific setup (nSEL) -------------------------------------- */
+
+
+static int get_gpio(struct spi_jz4740_gpio *prv,
+unsigned pin, const char *label, int value)
+{
+int err;
+unsigned long port;
+
+err = gpio_request(pin, label);
+if (err)
+return err;
+
+if (value >= 0)
+err = gpio_direction_output(pin, value);
+else
+err = gpio_direction_input(pin);
+if (err)
+goto fail;
+
+err = jz_gpio_set_function(pin, JZ_GPIO_FUNC_NONE);
+if (err)
+goto fail;
+
+if (!prv)
+return 0;
+
+port = JZ4740_GPIO_BASE_ADDR + 0x100 * PIN_TO_PORT(pin);
+if (prv->port_addr && prv->port_addr != port) {
+err = -EINVAL;
+goto fail;
+}
+prv->port_addr = port;
+
+return 0;
+
+fail:
+gpio_free(pin);
+return err;
+}
+
+static int spi_jz4740_gpio_setup(struct spi_device *spi)
+{
+unsigned nsel = get_nsel(spi);
+
+dev_dbg(&spi->dev, "%s\n", __func__);
+return get_gpio(NULL, nsel, dev_name(&spi->dev), 0);
+}
+
+static void spi_jz4740_gpio_cleanup(struct spi_device *spi)
+{
+unsigned nsel = get_nsel(spi);
+
+dev_dbg(&spi->dev, "%s\n", __func__);
+gpio_free(nsel);
+}
+
+
+/* ----- Non-nSEL GPIO allocation and configuration ------------------------ */
+
+
+static void free_gpios(struct spi_jz4740_gpio *prv)
+{
+const struct spi_gpio_platform_data *pdata = prv->pdata;
+
+if (prv->mosi)
+gpio_free(pdata->mosi);
+if (prv->miso)
+gpio_free(pdata->miso);
+if (prv->sck)
+gpio_free(pdata->sck);
+}
+
+
+static int setup_gpios(struct spi_jz4740_gpio *prv, const char *label,
+uint16_t *flags)
+{
+const struct spi_gpio_platform_data *pdata = prv->pdata;
+int err;
+
+if (pdata->mosi == -1) {
+*flags |= SPI_MASTER_NO_TX;
+} else {
+err = get_gpio(prv, pdata->mosi, label, 0);
+if (err)
+return err;
+prv->mosi = PIN_TO_MASK(pdata->mosi);
+}
+
+if (pdata->miso == -1) {
+*flags |= SPI_MASTER_NO_RX;
+} else {
+err = get_gpio(prv, pdata->miso, label, -1);
+if (err)
+goto fail;
+prv->miso = PIN_TO_MASK(pdata->miso);
+}
+
+err = get_gpio(prv, pdata->sck, label, 0);
+if (err)
+goto fail;
+prv->sck = PIN_TO_MASK(pdata->sck);
+
+return 0;
+
+fail:
+free_gpios(prv);
+return err;
+}
+
+
+/* ----- SPI master creation/removal --------------------------------------- */
+
+
+static int spi_jz4740_gpio_probe(struct platform_device *pdev)
+{
+const struct spi_gpio_platform_data *pdata = pdev->dev.platform_data;
+struct spi_master *master;
+struct spi_jz4740_gpio *prv;
+int err;
+
+dev_dbg(prv->dev, "%s\n", __func__);
+if (!pdata)
+return -ENODEV;
+
+master = spi_alloc_master(&pdev->dev, sizeof(*prv));
+if (!master)
+return -ENOMEM;
+
+prv = spi_master_get_devdata(master);
+prv->dev = &pdev->dev;
+prv->pdata = pdata;
+platform_set_drvdata(pdev, spi_master_get(master));
+
+err = setup_gpios(prv, dev_name(prv->dev), &master->flags);
+if (err)
+goto out;
+
+master->mode_bits= 0;/* SPI_MODE_0 only */
+master->bus_num= pdev->id;
+master->num_chipselect= pdata->num_chipselect;
+master->setup= spi_jz4740_gpio_setup;
+master->cleanup= spi_jz4740_gpio_cleanup;
+master->transfer_one_message = spi_jz4740_gpio_transfer_one;
+
+/*
+ * We don't [devm_]request_mem_region here since we don't need
+ * exclusive access to port registers. Pin access conflicts have
+ * already been resolved by gpiolib.
+ */
+
+prv->port_base = devm_ioremap(&pdev->dev, prv->port_addr, 0x100);
+if (!prv->port_base) {
+dev_err(prv->dev, "can't ioremap\n");
+goto out_busy;
+}
+
+err = spi_register_master(master);
+if (err) {
+dev_err(prv->dev, "can't register master\n");
+goto out_master;
+}
+
+return 0;
+
+out_busy:
+err = -EBUSY;
+out_master:
+free_gpios(prv);
+out:
+platform_set_drvdata(pdev, NULL);
+spi_master_put(master);
+
+return err;
+}
+
+static int spi_jz4740_gpio_remove(struct platform_device *pdev)
+{
+struct spi_master *master = platform_get_drvdata(pdev);
+struct spi_jz4740_gpio *prv = spi_master_get_devdata(master);
+
+spi_unregister_master(master);
+
+free_gpios(prv);
+
+platform_set_drvdata(pdev, NULL);
+spi_master_put(master);
+
+return 0;
+}
+
+static struct platform_driver spi_jz4740_gpio_driver = {
+.driver = {
+.name= DRIVER_NAME,
+.owner= THIS_MODULE,
+},
+.probe= spi_jz4740_gpio_probe,
+.remove= spi_jz4740_gpio_remove,
+};
+module_platform_driver(spi_jz4740_gpio_driver);
+
+MODULE_ALIAS("platform:" DRIVER_NAME);
+MODULE_DESCRIPTION("Jz4740 GPIO SPI Driver");
+MODULE_AUTHOR("Werner Almesberger <werner-SEdMjqphH88wryQfseakQg< at >public.gmane.org>");
+MODULE_LICENSE("GPL");

[RFC 1/3] at86rf230: add support for platform-specific reset function

Werner Almesberger — 2013-04-30T00:15:22

Some platforms may not connect the /RST line directly to a GPIO, or they
may not connect it at all and instead use power cycling to reset the
transceiver.

An example of the latter type is the ATBEN board on the Ben NanoNote.

This patch adds support for a platform-specific reset function to the
AT86RF230/1 driver. If the platform provides a reset function, "rstn"
is ignored and no GPIO is allocated for it.
---
 drivers/net/ieee802154/at86rf230.c |   45 +++++++++++++++++++++++++------------
 include/linux/spi/at86rf230.h      |    9 ++++++-
 2 files changed, 39 insertions(+), 15 deletions(-)

diff --git a/include/linux/spi/at86rf230.h b/include/linux/spi/at86rf230.h
index aa327a8..9fd1b29 100644
--- a/include/linux/spi/at86rf230.h
+++ b/include/linux/spi/at86rf230.h
< at >< at > -23,7 +23,7 < at >< at >
 #define AT86RF230_H
 
 struct at86rf230_platform_data {
-int rstn;
+int rstn;/* only used if "reset" (below) is NULL */
 int slp_tr;
 int dig2;
 
< at >< at > -40,6 +40,13 < at >< at > struct at86rf230_platform_data {
  * of the device to high active (the default value).
  */
 int irq_type;
+
+/* Platform-specific transceiver reset function, e.g., to use
+ * power cycling instead of the reset line. If "reset" is NULL,
+ * the driver resets the transceiver through the "rstn" GPIO.
+ */
+void (*reset)(void *reset_data);
+void *reset_data;
 };
 
 #endif
diff --git a/drivers/net/ieee802154/at86rf230.c b/drivers/net/ieee802154/at86rf230.c
index 6f10b49..7fa32f2 100644
--- a/drivers/net/ieee802154/at86rf230.c
+++ b/drivers/net/ieee802154/at86rf230.c
< at >< at > -834,6 +834,21 < at >< at > static void at86rf230_fill_data(struct spi_device *spi)
 lp->dig2 = pdata->dig2;
 }
 
+static void at86rf230_reset(struct at86rf230_local *lp)
+{
+struct at86rf230_platform_data *pdata = lp->spi->dev.platform_data;
+
+if (pdata->reset) {
+pdata->reset(pdata->reset_data);
+} else {
+msleep(1);
+gpio_set_value(lp->rstn, 0);
+msleep(1);
+gpio_set_value(lp->rstn, 1);
+}
+msleep(1);
+}
+
 static int at86rf230_probe(struct spi_device *spi)
 {
 struct at86rf230_platform_data *pdata;
< at >< at > -888,9 +903,11 < at >< at > static int at86rf230_probe(struct spi_device *spi)
 
 at86rf230_fill_data(spi);
 
-rc = gpio_request(lp->rstn, "rstn");
-if (rc)
-goto err_rstn;
+if (!pdata->reset) {
+rc = gpio_request(lp->rstn, "rstn");
+if (rc)
+goto err_rstn;
+}
 
 if (gpio_is_valid(lp->slp_tr)) {
 rc = gpio_request(lp->slp_tr, "slp_tr");
< at >< at > -898,9 +915,11 < at >< at > static int at86rf230_probe(struct spi_device *spi)
 goto err_slp_tr;
 }
 
-rc = gpio_direction_output(lp->rstn, 1);
-if (rc)
-goto err_gpio_dir;
+if (!pdata->reset) {
+rc = gpio_direction_output(lp->rstn, 1);
+if (rc)
+goto err_gpio_dir;
+}
 
 if (gpio_is_valid(lp->slp_tr)) {
 rc = gpio_direction_output(lp->slp_tr, 0);
< at >< at > -908,12 +927,7 < at >< at > static int at86rf230_probe(struct spi_device *spi)
 goto err_gpio_dir;
 }
 
-/* Reset */
-msleep(1);
-gpio_set_value(lp->rstn, 0);
-msleep(1);
-gpio_set_value(lp->rstn, 1);
-msleep(1);
+at86rf230_reset(lp);
 
 rc = at86rf230_read_subreg(lp, SR_MAN_ID_0, &man_id_0);
 if (rc)
< at >< at > -985,7 +999,8 < at >< at > err_gpio_dir:
 if (gpio_is_valid(lp->slp_tr))
 gpio_free(lp->slp_tr);
 err_slp_tr:
-gpio_free(lp->rstn);
+if (!pdata->reset)
+gpio_free(lp->rstn);
 err_rstn:
 spi_set_drvdata(spi, NULL);
 mutex_destroy(&lp->bmux);
< at >< at > -995,6 +1010,7 < at >< at > err_rstn:
 
 static int at86rf230_remove(struct spi_device *spi)
 {
+struct at86rf230_platform_data *pdata = spi->dev.platform_data;
 struct at86rf230_local *lp = spi_get_drvdata(spi);
 
 ieee802154_unregister_device(lp->dev);
< at >< at > -1004,7 +1020,8 < at >< at > static int at86rf230_remove(struct spi_device *spi)
 
 if (gpio_is_valid(lp->slp_tr))
 gpio_free(lp->slp_tr);
-gpio_free(lp->rstn);
+if (!pdata->reset)
+gpio_free(lp->rstn);
 
 spi_set_drvdata(spi, NULL);
 mutex_destroy(&lp->bmux);

[RFC 0/3] ATBEN kernel support for the Ben NanoNote

Werner Almesberger — 2013-04-30T00:14:41

For review before submitting things upstream:

This set of three patches adds support for the ATBEN IEEE 802.15.4 board,
along with the infrastructure needed for the Ben NanoNote. It consists
of three parts:

1) addition of a platform-specific reset function to the AT86RF230 driver.
   The driver assumes that it can reset the transceiver through a reset
   pin, but ATBEN uses power cycling instead. We therefore need a
   platform-specific function to perform the reset.

2) addition of an SPI-GPIO driver optimized for the Jz4740. ATBEN
   connects to a physical MMC interface but uses SPI (with some quirks)
   for communication. We therefore have to use bit-banging.

   The SPI-GPIO driver would be too slow, so we introduce a driver
   optimized for the Ingenic Jz4740 SoC that implements a subset of
   SPI-GPIO's functionality and is up to about six times faster.

3) last but not least, we add the platform definitions that connect
   the drivers and devices, and provide the platform-specific reset
   function. Since all this is specific to the Ben NanoNote, the code
   goes into arch/mips/jz4740/

Comments welcome.

- Werner

Why Is The Listener Package Not At Version 2?

Alexander Stephen Thomas Ross — 2013-04-29T00:56:33

Why is listener stuck at version 1.7.2 instead of version 2 alsa? I 
think I could make a easy action on loud noise script with v2.

I also have clap and whistle, detection and action apps off the WWW to 
try out.


I still have my existing goodies to upload... (this year or sooner!)

Re: Curious as to your thoughts re: Beaglebone Black

Paul Boddie — 2013-04-25T22:21:50

True enough. Even the Ben sitting in front of me on my desk (currently wired 
up to some ICs via the 8:10 port) is not completely free and open down to the 
level of the silicon, as we all know.

[...]


Yes, I welcome the availability of these boards. Their most potent impact may 
well be the erosion of Microsoft's influence on the personal computing 
business as people start to realise that their computing needs do not start 
with a parroting of various proprietary Wintel-oriented buzzwords as 
necessary criteria for their next purchase.

But even beyond this, these boards are rather attractive. I guess the debate 
can be distilled down to what you would want them for, what they are good 
for, and whether they are interesting to hardware hackers. Certainly, there's 
no shortage of these boards now, and there's something for everyone in a 
certain audience, at least.


As I may have already mentioned, I think that playing around with GPIO, SPI, 
I2C and all the other stuff that people were already doing with Arduino (more 
or less) is going to become more popular, and the mainstream may rediscover 
all the robotics stuff that was exciting and popular to an extent back in the 
home microcomputer era of the 1980s. They'll be able to afford it a bit 
better now as well.


I'm going to be tempted by one of these devices at some point once I can be 
sure that they can replace my aging desktop machine.

Paul

Re: Curious as to your thoughts re: Beaglebone Black

Sébastien Bourdeauducq — 2013-04-25T21:24:40

If I seriously get down to it, I believe I could get it done within a 
year or so, but who will want/buy it? Even if I make it as good as the 
BCM2835, it will still likely fail - see:
http://www.google.com/trends/explore#q=%22raspberry%20pi%22,%22allwinner%20a10%22,%20OLinuxXino,Beaglebone


And your advertising of ARM boards is not helping.

Sebastien

Re: Curious as to your thoughts re: Beaglebone Black

Ron K. Jeffries — 2013-04-25T21:04:01

My post did NOT intend to suggest that Beaglebone Black is a totally open
platform that meets the goals of qi-hardware.
But who among us uses pure open hardware compute platforms for all of our
general computer work?

That Venn diagram describes the null set. Every single one of you (I would
assume) use one or more non-open hardware computers for the vast majority
of your work.

There may come a day (not soon) when some person or group with deep pockets
creates a USABLE, for normal applications, computer system that is patent
free and totally open. It is not impossible, and work by Sebastian and
Wolfgang is significant and much appreciated.

The first such device will be based on FPGA technology, which is advancing
at a mind-boggling pace. More LUTS, cheaper prices, faster speeds, lower
power consumption, it's all good.

The Milkymist design, rather nice (!!!) does not appear to be adequate AT
THIS POINT IN TIME to replace even a middling PC in terms of compute
performance, never mind other aspects of usability. But that doesn't mean
it can not, eventually get done.

The challenge then will be to take the design and convert it to an SOC.
That is technically challenging, as we all know requires a lot of resources
in both engineering talent, time and money. It is not a casual project, it
will need on the order of a few million dollars, and may or may not work
after a first ASIC spin.

But let's assume some very wealthy person funds that effort. That could
happen.

At that point there could be a low to mid performance engine. It's an open
question what peripherals might be included, based on concerns about
totally open hardware.

This project is not impossible, but it is not happening right now that I am
aware of.

In the interim, if you need a nice, cheap little server to provide say a
file server or web server or mail server or other general computing tasks,
and you desire low energy consumption, then any of several mass produced
developer boards such as Beaglebone Black will serve your needs
brilliantly. This one is more open than some competing offerings. Others
that seem interesting to me include any of a few that leverage the Allwinner
SOCs most especially Cubieboard.

This is NOT perfection. It is a commercially available product that can run
any of several Linux distros. It costs $45, and is shipping now.

That's all. It is not alleged to be the second coming of Christ, nor the
answer to every desire someone who owns the venerable Ben Nanonote might
have. It is not a pocket, self-contained Linux clam shell. But it costs
less than half of a Nanonote, supports a broad array of peripherals, has
good access to low-level i/o e.g. gpio, SPI, I2C, analog capability and, oh
by the way, full-on USB.

It is a clever, cheap Linux box. Nothing wrong with that. Nobody is forced
to purchase it. LOL

I am pretty sure you will like it better than the wildly popular (well over
a million shipped) Raspberry Pi.

--Ron K Jeffries

---
Ron K. Jeffries
805-567-4670

On Thu, Apr 25, 2013 at 1:32 PM, Paul Boddie <paul-RlAhfoEKpGHe9xe1eoZjHA< at >public.gmane.org> wrote:

Re: Curious as to your thoughts re: Beaglebone Black

Paul Boddie — 2013-04-25T20:32:16

My impression was that at least in its earliest days and in certain forms, 
OMAP wasn't even properly usable unless, perhaps, you were a big manufacturer 
with contacts in TI to help you use the on-chip functionality correctly.

Meanwhile, the AM-series SoCs seem to have varying qualities:

http://rhombus-tech.net/ti/am335x/


For some people it is not interesting; for others it is enough for their needs 
or level of expertise.


If they're going out of their way to make actual boards to work with Arduino 
where both of those things could be replaced by something simpler, then I 
guess they should be investigating the AVR components independently. But 
Arduino is pretty good as something people don't have to think too hard about 
(or argue about) as they get started on a project.


As always, I think the big money contradicts you... ;-)

https://www.sparkfun.com/products/11712
http://www.kickstarter.com/projects/435742530/udoo-android-linux-arduino-in-a-tiny-single-board

The latter one gives an impression similar to the one you'd get if the Fiat 
Cinquecento were remade for the American market by the American car industry, 
but maybe there is a good reason for making a large board with everything on 
it after all.

Paul

_______________________________________________
Qi Hardware Discussion List
Mail to list (members only): discussion< at >lists.en.qi-hardware.com
Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion

Re: Ben NanoNote kernel, status of critical patches ?

Lars-Peter Clausen — 2013-04-25T17:52:15

Some are upstream, some are not. Those which are not upstream are primarily not
upstream because they aren't quite ready yet and need some more love.

E.g. There is already a driver for the usb gadget core in upstream (musb). But
it is used on a couple of SoCs and somebody needs to sit down and write the
jz4740 glue code.

- Lars