There are brief notes about how to enable Thumb-2 kernel building here:
https://wiki.linaro.org/Resources/HowTo/KernelDeploy#From_a_generic_base
Currently, omap and vexpress are known to work in this configuration,
and mx51evk seems to have basic support. Other platforms might not
work at all.
If people can get into the habit of testing both ARM and Thumb-2
kernel configurations when testing the linaro kernel tree, that would
be great!
Cheers
---Dave
Linus (W),
Some more thoughts on pinmux:
========== GPIO/pinmux API interactions
I'd like to understand how the gpio and pinmux subsystems are intended
to interact.
Quoting from Documentation/gpio.txt:
Note that requesting a GPIO does NOT cause it to be configured in any
way; it just marks that GPIO as in use. Separate code must handle any
pin setup (e.g. controlling which pin the GPIO uses, pullup/pulldown).
Due to this, the current Tegra GPIO driver contains additional non-
standard functions:
void tegra_gpio_enable(int gpio);
void tegra_gpio_disable(int gpio);
In some cases, those functions are called by board files at boot time,
and in other cases by drivers themselves, right before gpio_request().
Is it your intention that such custom functions be replaced by
pinmux_request_gpio(), and the Tegra pinmux driver's gpio_request_enable
op should call tegra_gpio_enable?
That seems like the right idea to me.
========== pinmux calling GPIO or vice-versa?
Having pinmux call gpio appears to conflict with a couple of things from
your recent pinmux patchset:
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> +# pinctrl before gpio - gpio drivers may need it
> +
> +source "drivers/pinctrl/Kconfig"
> +
> source "drivers/gpio/Kconfig"
>
> diff --git a/drivers/Makefile b/drivers/Makefile
>...
> +# GPIO must come after pinctrl as gpios may need to mux pins etc
> +obj-y += pinctrl/
Don't those patches imply that the GPIO controller code is calling into
the pinmux code to perform muxing, not the other way around?
========== When pins get marked as in-used
There seems to be a discrepancy in the way the client APIs work: For
special functions, the client calls pinmux_get, then later pinmux_enable,
whereas for GPIOs, the client just calls pinmux_request_gpio. I'm not
sure of the benefit of having separate pinmux_get and pinmux_enable
calls; I thought the idea was that a client could:
a = pinmux_get(dev, "funca");
b = pinmux_get(dev, "funcb");
pinmux_enable(a);
...
pinmux_disable(a);
pinmux_enable(b);
...
pinmux_disable(b);
pinmux_put(b);
pinmux_put(a);
However, since the pins are marked as reserved/in-use when pinmux_get
is called rather than pinmux_enable, the code above won't work; it'd
need to be:
a = pinmux_get(dev, "funca");
pinmux_enable(a);
...
pinmux_disable(a);
pinmux_put(a);
b = pinmux_get(dev, "funcb");
pinmux_enable(b);
...
pinmux_disable(b);
pinmux_put(b);
Perhaps pin usage marking should be moved into enable/disable?
========== Matched request/free calls for GPIOs
A couple more comments on your recent pinmux patches in light of this:
>From pin_request():
+ /*
+ * If there is no kind of request function for the pin we just assume
+ * we got it by default and proceed.
+ */
+ if (gpio && ops->gpio_request_enable)
+ /* This requests and enables a single GPIO pin */
+ status = ops->gpio_request_enable(pmxdev,
+ pin - pmxdev->desc->base);
+ else if (ops->request)
+ status = ops->request(pmxdev,
+ pin - pmxdev->desc->base);
+ else
+ status = 0;
a) I feel the default should be to error out, not succeed; the whole
point of the API is for HW where something must be programmed to enable
each function. As such, if you don't provide that ops->request* function,
that seems like an error.
I think the logic above should be to always call ops->gpio_request_enable
if (gpio):
if (gpio)
if (ops->gpio_request_enable)
/* This requests and enables a single GPIO pin */
status = ops->gpio_request_enable(pmxdev,
pin - pmxdev->desc->base);
else
status = ops->request(pmxdev,
pin - pmxdev->desc->base);
(ops->gpio_request_enable could be optional if GPIOs aren't supported on
any pinmux pins, whereas ops->request isn't optional, and should be checked
during pinmux_register)
Also, ops->gpio_request_enable should also be passed the GPIO number,
so the driver can validate that it's the correct one. Often, only
one value would be legal, but perhaps some pinmuxs allow 1 of N different
GPIOs to be mapped to some pin, so selection of which GPIO is on par with
selection of which special function to mux out, yet the driver still
doesn't want to expose every GPIO possibility as a pinmux "function" due
to explosion of the number of functions if it did that.
b) When ops->gpio_request_enable is called to request a pin, it'd be nice
if the core could track this, and specifically call a new ops->gpio_disable
to free it, rather than the generic ops->free. There are two cases in HW:
b1) "GPIO" is just another special function in a list, e.g. SPI, I2C, GPIO.
In this case, free for a GPIO needs to either do nothing (the next call to
request will simply set the desired function), or possibly do something to
disable the pin in the same way as any other function. This works fine with
a single free function.
b2) GPIO enable/disable is a separate concept from the pinmuxing; on Tegra
it'll be implemented by calling tegra_gpio_enable/disable. As such, a
single free function would require the pinmux driver to store state
indicating whether ops->free should call tegra_gpio_disable, or whether it
should do cleanup to the pinmux registers. Since the core is managing GPIO
vs. function allocation, I think the storing that state in the core makes
sense.
Thanks for reading. Hopefully this email didn't jump about too much.
--
nvpublic
Hi,
I am Marc-Andre from the FreeRDP project, an open source RDP client. I want
to work on optimizing FreeRDP for ARM using the NEON processor extensions.
The main computer is running Ubuntu 11.04 64-bit, while the target system is
a pandaboard running Ubuntu 11.04 for ARM. I started looking into linaro
because it aims at improving the current set of development tools for ARM,
and I like where the project is going. Once I will have figured out how to
get started, I will document the procedure specific to cross-compiling
FreeRDP and redirect developers to it. It is my first time cross-compiling,
so thank you for your understanding.
I have asked some questions on IRC, and read various pages from the wiki,
but I haven't managed to successfully cross-compile FreeRDP yet. Compiling
directly on the pandaboard works, but it is atrociously slow. I have made a
chroot environment following and adapting the instructions from the
following wiki page:
https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/UsingXdeb
I took notes while setting up my chroot environment, such that I could use
those notes later on for a wiki article:
# bootstrap ubuntu natty
sudo debootstrap natty natty-armel
# chroot to new environment
sudo chroot natty-armel
# mount partitions
mount -t proc proc /proc
mount -t devpts none /dev/pts
# export environment variables
export LC_ALL=C
# append "universe" after "main" in sources.list
sed -i 's/main/main universe/' /etc/apt/sources.list
# add source repository
sudo echo "deb [arch=armel] http://ports.ubuntu.com/ natty main universe" >>
/etc/apt/sources.list
# update and install packages
apt-get update
apt-get install gcc-arm-linux-gnueabi xdeb
I have tried both xdeb and xapt, both causing problems. You can find the
regular compilation procedure here:
http://www.freerdp.com/wiki/doku.php?id=compilation
Following the regular procedure, one can compile directly on the pandaboard,
but it's very slow.
xapt:
I managed to fetch and convert packages with xapt, using the following
command:
sudo xapt -a armel -k -b --suite natty --mirror
http://ports.ubuntu.com/libssl-dev libx11-dev libxv-dev libxkbfile-dev
libxcursor-dev libasound2-dev
libxcb1 libxcb1-dev libdirectfb-dev libc6 libc6-dev zlib1g zlib1g-dev
The problem is then that xapt will fail to install the converted packages,
saying the package architecture is different from the current architecture,
as well as missing dependencies. I worked around the problem with this ugly
hack:
cd /var/lib/xapt/output/
sudo dpkg -i --force-all *.deb
Following this, I could get the FreeRDP configure script to work, even
though it would fail to detect X11 properly:
PKG_CONFIG_PATH=/usr/arm-linux-gnueabi/lib/pkgconfig ./configure
--host=arm-linux-gnueabi --with-neon
When trying to build after that, it will still fail to link in the end,
complaining about missing libraries such as zlib, X11, crypto, etc. I tried
installing various packages more with xapt, but I couldn't get it to work.
xdeb:
I tried the following:
root@workstation:/# xdeb -a armel --prefer-apt libssl-dev libx11-dev
libxv-dev libxkbfile-dev libxcursor-dev libasound2-dev
Building source package cache ...
Using file ports.ubuntu.com_dists_natty_main_source_Sources for apt cache
Using file ports.ubuntu.com_dists_natty_universe_source_Sources for apt
cache
Using file archive.ubuntu.com_ubuntu_dists_natty_main_source_Sources for apt
cache
Using file archive.ubuntu.com_ubuntu_dists_natty_universe_source_Sources for
apt cache
Building working tree cache ...
No source package found: libssl-dev
Or, alternatively, the following:
root@workstation:/# xdeb -a armel --convert libssl-dev libx11-dev libxv-dev
libxkbfile-dev libxcursor-dev libasound2-dev
Traceback (most recent call last):
File "/usr/bin/xdeb", line 849, in <module>
main()
File "/usr/bin/xdeb", line 767, in main
crossed_debs = cross_convert(options, args)
File "/usr/bin/xdeb", line 409, in cross_convert
deb)).debcontrol()
File "/usr/lib/pymodules/python2.7/debian/debfile.py", line 208, in
__init__
ArFile.__init__(self, filename, mode, fileobj)
File "/usr/lib/pymodules/python2.7/debian/arfile.py", line 47, in __init__
self.__index_archive()
File "/usr/lib/pymodules/python2.7/debian/arfile.py", line 52, in
__index_archive
fp = open(self.__fname, "rb")
IOError: [Errno 2] No such file or directory: './libssl-dev'
Here is my sources.list file:
root@workstation:/# cat /etc/apt/sources.list
deb http://archive.ubuntu.com/ubuntu natty main universe
deb-src http://archive.ubuntu.com/ubuntu natty main universe
deb [arch=armel] http://ports.ubuntu.com/ natty main universe
deb-src [arch=armel] http://ports.ubuntu.com/ natty main universe
I'm stuck at this point. Can anybody point me towards possible solution
paths on how to cross-compile FreeRDP for ARM, given the above information?
Best regards,
- Marc-Andre
Function declaration differs between file:s3c-pl330.c and file:dma.h
and SPARSE (Documentation/sparse.txt) gives error messages
Signed-off-by: Sangwook Lee <sangwook.lee(a)linaro.org>
---
arch/arm/plat-samsung/include/plat/dma.h | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/plat-samsung/include/plat/dma.h b/arch/arm/plat-samsung/include/plat/dma.h
index 2e8f8c6..7365f46 100644
--- a/arch/arm/plat-samsung/include/plat/dma.h
+++ b/arch/arm/plat-samsung/include/plat/dma.h
@@ -62,7 +62,7 @@ typedef int (*s3c2410_dma_opfn_t)(struct s3c2410_dma_chan *,
* request a dma channel exclusivley
*/
-extern int s3c2410_dma_request(unsigned int channel,
+extern int s3c2410_dma_request(enum dma_ch id,
struct s3c2410_dma_client *, void *dev);
@@ -71,14 +71,14 @@ extern int s3c2410_dma_request(unsigned int channel,
* change the state of the dma channel
*/
-extern int s3c2410_dma_ctrl(unsigned int channel, enum s3c2410_chan_op op);
+extern int s3c2410_dma_ctrl(enum dma_ch id, enum s3c2410_chan_op op);
/* s3c2410_dma_setflags
*
* set the channel's flags to a given state
*/
-extern int s3c2410_dma_setflags(unsigned int channel,
+extern int s3c2410_dma_setflags(enum dma_ch id,
unsigned int flags);
/* s3c2410_dma_free
@@ -86,7 +86,7 @@ extern int s3c2410_dma_setflags(unsigned int channel,
* free the dma channel (will also abort any outstanding operations)
*/
-extern int s3c2410_dma_free(unsigned int channel, struct s3c2410_dma_client *);
+extern int s3c2410_dma_free(enum dma_ch id, struct s3c2410_dma_client *);
/* s3c2410_dma_enqueue
*
@@ -95,7 +95,7 @@ extern int s3c2410_dma_free(unsigned int channel, struct s3c2410_dma_client *);
* drained before the buffer is given to the DMA system.
*/
-extern int s3c2410_dma_enqueue(unsigned int channel, void *id,
+extern int s3c2410_dma_enqueue(enum dma_ch idx, void *id,
dma_addr_t data, int size);
/* s3c2410_dma_config
@@ -103,14 +103,14 @@ extern int s3c2410_dma_enqueue(unsigned int channel, void *id,
* configure the dma channel
*/
-extern int s3c2410_dma_config(unsigned int channel, int xferunit);
+extern int s3c2410_dma_config(enum dma_ch id, int xferunit);
/* s3c2410_dma_devconfig
*
* configure the device we're talking to
*/
-extern int s3c2410_dma_devconfig(unsigned int channel,
+extern int s3c2410_dma_devconfig(enum dma_ch id,
enum s3c2410_dmasrc source, unsigned long devaddr);
/* s3c2410_dma_getposition
@@ -118,7 +118,7 @@ extern int s3c2410_dma_devconfig(unsigned int channel,
* get the position that the dma transfer is currently at
*/
-extern int s3c2410_dma_getposition(unsigned int channel,
+extern int s3c2410_dma_getposition(enum dma_ch id,
dma_addr_t *src, dma_addr_t *dest);
extern int s3c2410_dma_set_opfn(unsigned int, s3c2410_dma_opfn_t rtn);
--
1.7.4.1
Hi,
Linaro Android has now moved up to 2.3.4 and all of our patches on the
linaro_android_2.3.3 branches have been rebased.
The official builds (https://android-build.linaro.org/index) are now
based on the linaro_android_2.3.4 branch of the manifest.
Please rebase any dev_branches you have to 2.3.4. The
linaro_android_2.3.3 branch will no longer be supported.
Regards
Patrik
When there is no clock available, we even register the display ops.
The 'enter' callbakc is set but not data is available int the row
private data which leads to a segfaults.
This patch fix this problem by not registering the ops if the pm
subsystem was not correctly initialized.
In the meantime, we have to erase the window when we are switching
from one window to another. We can say it is the "default" display
callback.
Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org>
Reported-by: Milo (Woogyom) Kim <woogyom.kim(a)gmail.com>
---
clocks.c | 8 ++++----
display.c | 5 ++++-
regulator.c | 8 ++++----
sensor.c | 8 ++++----
4 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/clocks.c b/clocks.c
index 0bd0a0e..20a245c 100644
--- a/clocks.c
+++ b/clocks.c
@@ -405,9 +405,6 @@ int clock_init(void)
{
char clk_dir_path[PATH_MAX];
- if (display_register(CLOCK, &clock_ops))
- return -1;
-
if (locate_debugfs(clk_dir_path))
return -1;
@@ -420,5 +417,8 @@ int clock_init(void)
if (!clock_tree)
return -1;
- return fill_clock_tree();
+ if (fill_clock_tree())
+ return -1;
+
+ return display_register(CLOCK, &clock_ops);
}
diff --git a/display.c b/display.c
index 0cfbf94..ebc4de6 100644
--- a/display.c
+++ b/display.c
@@ -120,7 +120,10 @@ static int display_refresh(int win, bool read)
if (windata[win].ops && windata[win].ops->display)
return windata[win].ops->display(read);
- return 0;
+ if (werase(main_win))
+ return -1;
+
+ return wrefresh(main_win);
}
int display_refresh_pad(int win)
diff --git a/regulator.c b/regulator.c
index 849f906..e9b01bb 100644
--- a/regulator.c
+++ b/regulator.c
@@ -236,12 +236,12 @@ static struct display_ops regulator_ops = {
int regulator_init(void)
{
- if (display_register(REGULATOR, ®ulator_ops))
- return -1;
-
reg_tree = tree_load(SYSFS_REGULATOR, regulator_filter_cb);
if (!reg_tree)
return -1;
- return fill_regulator_tree();
+ if (fill_regulator_tree())
+ return -1;
+
+ return display_register(REGULATOR, ®ulator_ops);
}
diff --git a/sensor.c b/sensor.c
index d63510e..e172f88 100644
--- a/sensor.c
+++ b/sensor.c
@@ -271,12 +271,12 @@ static struct display_ops sensor_ops = {
int sensor_init(void)
{
- if (display_register(SENSOR, &sensor_ops))
- return -1;
-
sensor_tree = tree_load(SYSFS_SENSOR, sensor_filter_cb);
if (!sensor_tree)
return -1;
- return fill_sensor_tree();
+ if (fill_sensor_tree())
+ return -1;
+
+ return display_register(SENSOR, &sensor_ops);
}
--
1.7.1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/27/2011 09:36 AM, Milo (Woogyom) Kim wrote:
>
> Hi, Daniel
>
> I found some segmentation fault in the powerdebug.
> If there is no clock information, then windata[win].rowdata is null.
> (If clock_display() returns -1, then display_set_row_data() is not called)
> In this case the seg fault error occurs when display_get_row_data() is
> called.
Thanks Milo for reporting the problem.
I opened a bug in launchpad for this:
https://bugs.launchpad.net/linaro-powerdebug/+bug/802387
Your patches are fixing the problem but I think that does not fix the
root problem which is we are setting the display ops on the clocks.
At the first glance, I think we should not call display_register in the
clock_init function if we are not able to access debugfs.
The same should apply to all init function for the different subsystems.
(cc'ed linaro-dev)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOCD4vAAoJEAKBbMCpUGYAvW4IALXI8nNyrtiej97/9gjFBhZT
cfHZgAgY5f4J+GoCyxX2tyCfbqkHgDGaJDvAWkWxMjBLQiVpnjchOG96aj+o5qud
YQ3vFXuLKmXWyAjxhxuXfOKyjhvHf6QcKLXWS7OMBoxfozYJ0EwEvSjfGVL2sF3e
rurZVZYU47Ms8jVq/MzaEyi1GZiE5D6ZhjfuSc9XhJ70+NORaVcgChOE3E2XGh5O
DfKjFHfr/nsjVGXPp0vTdlHH4ZgecDCkuorK8a9Bi0xX7ijRVUUVgjepuK/Fflqo
33/I995r2utVK+x/FgcyNBi28qhNieeVIBcVdZHEFKGPCiGFdbGkqz2JDagJxnc=
=99OZ
-----END PGP SIGNATURE-----
I'm considering starting an extra branch of Linaro GCC for use in the
final stages of development and would like your input.
Our goal is improve the performance of real, shipping products and to
help the their time to market. We make improvements and fixes to FSF
GCC and then backport them to Linaro GCC so that you can pick up these
improvements early. The problem comes when you're nearing release
time as picking up a new release for a needed bug fix also pulls in
new features which might introduce bugs.
To reduce the risk, we could run a stable branch or bolster up the FSF
stable branch.
The Linaro stable branch would:
* Start from Linaro GCC and its many performance improvements
* Only take bug fixes
* Be tested and released every month
* Run for six months at a time
* Work in the same way as our main release including support and
having binary builds
The idea is that you could track the main branch during development
and switch to the stable branch during the last few months. This
gives a good mix of the latest performance with less risk at release
time.
Bolstering up the FSF stable branch approaches the problem a different
way. We work upstream, so all of our improvements are available in an
upstream release, but perhaps a year later than via Linaro GCC. We
could take the mainline releases, add binary builds, and generally
boost mainline support.
The FSF stable branch would:
* Start at the upstream 4.x.1 release such as 4.6.1
* Only take regression fixes
* Be tested and release with each (roughly quarterly) mainline release
* Run for the roughly twelve months until the next mainline 4.y.1 release
* Give a good path if you move away from Linaro in the future
Any comments are appreciated. There's more background and discussion
on the wiki at:
https://wiki.linaro.org/MichaelHope/Sandbox/StableBranch
I'm particularly interested in comments from people making products,
distributions, or IDEs such as:
* Is a stable branch useful?
* How long does it need to be supported for?
* When do you freeze your toolchain?
* Should we spend our time elsewhere such as on more performance,
faster bug fixes, more documentation, being in more distributions, or
being available in other ways such as binary builds?
-- Michael
