Hi.
I'm currently fumbling around in the dark, trying to find a kernel which
I can use to compile the powervr drivers, as well as with rpmsg support.
Ideally the rpmsg should already be in the kernel, but I can see that
this might be hard, and cherry picking is an ok solution. I'm wondering
if one of the ti landing team kernels might be suitable for this, and if
one of these is considered a stable kernel?
Last kernel I looked at was the LEB 3.1.5+ kernel,
release-linux-2011-12, which worked fine for compiling the pvr drivers
from rsalveti, but didn't contain rpmsg drivers. When I tried the
release-linux-2012-01 kernel, 3.2.0+, it could compile the powervr
driver, but didn't contain the rpmsg drivers and didn't actually run, as
I got the message 'coherent pool not initialized' from the kernel when
trying to allocate for the ehci-omap.
The kernel will be run on a device with an omap4460 if this is of interest.
I would really appreciate your help on this, as I feel quite lost in all
the different branches and tags which reside in the different linaro
kernels, so a repo with a stable commit would really help. As most rpmsg
implementations I have seen follows the 3.2 kernel, that would really be
preferable if I need to cherry pick, but if not I don't really care if
it's 3.1 or 3.2.
If you have any questions, please do not hesitate to ask them.
Best regard
Martin Ertsas
Hello,
Continuing on the ARM Porting effort to fix the remaining issues with
Precise, we'll be having the ARM Porting Jam this friday as well!
The main focus for this Friday, besides the usual FTBFS issues
described at http://people.linaro.org/~rsalveti/arm-porting-queue/arm-porting-queue-repo…,
is porting the most packages we can to be multi-arch compatible. This
will allow us to increase the list of packages we can easily
cross-compile using multi-arch.
Wookey got a quite long list of things to do at
https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/MultiarchCrossBui…,
so please have a look and make sure to get in touch with him at
#linaro @ freenode if you need any extra help.
Happy porting!
--
Ricardo Salveti de Araujo
Hi there,
Launchpad now supports blueprint work items natively and we've already
migrated the work items from the whiteboards of most Linaro Blueprints.
Most of us wouldn't even notice those changes because we still have a
text field to enter work items and it uses the exact same format we used
before. In the future we might improve the user experience but for now
we decided to keep the same UI and format. There's a blog post with more
information, if you're curious:
http://blog.launchpad.net/
In practice this just means you'll enter the work items in the 'Work
items' field instead of the whiteboard (the meta info
[acceptance/headline] still go there, though), but the work items of
some of our Blueprints could not be migrated, so I've spammed^W sent an
email to the owner/assignee of each of them. It would be nice if those
of you who receive that email migrated your BPs manually but even if you
don't status.l.o is setup to pull work items from both the new field and
the whiteboard, so you'll still see your work items there.
And if you're curious why we're doing all this, it's so that we can
implement the monthly engineering views in Launchpad:
https://dev.launchpad.net/Projects/WorkItems
Cheers,
--
Guilherme Salgado <https://launchpad.net/~salgado>
The common clock framework defines a common struct clk as well as an
implementation of the clk api that unifies clock operations on various
platforms and devices.
The net result is consolidation of many different struct clk definitions
and platform-specific clock framework implementations.
Thanks to Sascha Hauer and Andrew Lunn for their great review and
feedback on the previous v5 series.
Major changes since v5:
* removed redundant HAVE_CLK_PREPARE in Kconfig
* new CONFIG_COMMON_CLK_DISABLE_UNUSED feature
* results in a new clk_op callback, .is_enabled
* standardized the hw-specific locking in the basic clock types
* export the individual ops for each basic clock type
* improve registration for single-parent basic clocks (thanks Sascha)
* fixed bugs in gate clock's static initializers (thanks Andrew)
* overall improvements to Documentation/clk.txt
* rebased onto Linus' v3.3-rc6 tag
Major changes since v4:
* rolled in TGLX's comments on overall design. We now have,
* proper handling of root clocks and orphan clocks
* multi-parent clocks are handled in the core
* struct clk is shielded from struct clk_foo and vice versa
* this is a return to the previous struct clk_hw design
* split basic clock types out into separate files
* split headers up by purpose
* clk.h remains the driver-level interface
* declarations for rate change notifiers are the only additions
* clk-provider.h is primary header for implementing clock operations
* clk-private.h allows for static initialization of clock data
* validation and bug fixes
* rebased onto Linus' v3.3-rc5 tag
Patches can be pulled from:
git://git.linaro.org/people/mturquette/linux.git v3.3-rc6-clkv6
v5 can be found at,
http://article.gmane.org/gmane.linux.kernel/1261472
v4 can be found at,
http://article.gmane.org/gmane.linux.linaro.devel/8896/
v3 can be found at,
http://article.gmane.org/gmane.linux.kernel/1218622
Mike Turquette (3):
Documentation: common clk API
clk: introduce the common clock framework
clk: basic clock hardware types
Documentation/clk.txt | 233 +++++++
drivers/clk/Kconfig | 39 ++
drivers/clk/Makefile | 2 +
drivers/clk/clk-divider.c | 204 ++++++
drivers/clk/clk-fixed-rate.c | 82 +++
drivers/clk/clk-gate.c | 157 +++++
drivers/clk/clk-mux.c | 123 ++++
drivers/clk/clk.c | 1424 ++++++++++++++++++++++++++++++++++++++++++
include/linux/clk-private.h | 192 ++++++
include/linux/clk-provider.h | 298 +++++++++
include/linux/clk.h | 68 ++-
11 files changed, 2817 insertions(+), 5 deletions(-)
create mode 100644 Documentation/clk.txt
create mode 100644 drivers/clk/clk-divider.c
create mode 100644 drivers/clk/clk-fixed-rate.c
create mode 100644 drivers/clk/clk-gate.c
create mode 100644 drivers/clk/clk-mux.c
create mode 100644 drivers/clk/clk.c
create mode 100644 include/linux/clk-private.h
create mode 100644 include/linux/clk-provider.h
--
1.7.5.4
For the 12.01 cycle the Linaro Platforms team is pleased to announce
the availability of the new linarotv-xbmc based image. This combines
the xbmc media server project with linaro's leb to result in a "works
out of the box" arm based media server image.
It can be found at http://snapshots.linaro.org/oneiric/linaro-o-linarotv-xbmc/
Currently the best experience can be found on Panda/Panda ES however
boards with hardware video acceleration enabled should work well. We
welcome feedback and suggestions on the image. Support is on a as
"best can" basis. Bugs if found should be written against
linaro-ubuntu in lauchpad.
Enjoy!
--
Regards,
Tom
"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian
Multimedia Tech Lead | Linaro.org │ Open source software for ARM SoCs
w) tom.gall att linaro.org
w) tom_gall att vnet.ibm.com
h) tom_gall att mac.com
Sorry disturbing you!
I have ask google for do ARM Cortex-A9 PMU supoort oprofile, but it do not have a answer definitely .
So i ask you do ARM Cortex-A9 PMU supoort oprofile.
Can u help me?
zachary6626
From: "Ying-Chun Liu (PaulLiu)" <paul.liu(a)linaro.org>
Anatop is a mfd chip embedded in Freescale i.MX6Q SoC.
Anatop provides regulators and thermal.
This driver handles the address space and the operation of the mfd device.
Signed-off-by: Ying-Chun Liu (PaulLiu) <paul.liu(a)linaro.org>
Acked-by: Shawn Guo <shawn.guo(a)linaro.org>
Cc: Samuel Ortiz <sameo(a)linux.intel.com>
Cc: Mark Brown <broonie(a)opensource.wolfsonmicro.com>
Cc: Venu Byravarasu <vbyravarasu(a)nvidia.com>
Cc: Peter Korsgaard <jacmet(a)sunsite.dk>
---
drivers/mfd/Kconfig | 8 +++
drivers/mfd/Makefile | 1 +
drivers/mfd/anatop-mfd.c | 142 ++++++++++++++++++++++++++++++++++++++++++++
include/linux/mfd/anatop.h | 40 ++++++++++++
4 files changed, 191 insertions(+), 0 deletions(-)
create mode 100644 drivers/mfd/anatop-mfd.c
create mode 100644 include/linux/mfd/anatop.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 82da448..c3a9f31 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -846,6 +846,14 @@ config MFD_INTEL_MSIC
Passage) chip. This chip embeds audio, battery, GPIO, etc.
devices used in Intel Medfield platforms.
+config MFD_ANATOP
+ bool "Support for Freescale i.MX on-chip ANATOP controller"
+ depends on SOC_IMX6Q
+ help
+ Select this option to enable Freescale i.MX on-chip ANATOP
+ MFD controller. This controller embeds regulator and
+ thermal devices for Freescale i.MX platforms.
+
endmenu
endif
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 27430d3..42c8bf6 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -113,3 +113,4 @@ obj-$(CONFIG_TPS65911_COMPARATOR) += tps65911-comparator.o
obj-$(CONFIG_MFD_AAT2870_CORE) += aat2870-core.o
obj-$(CONFIG_MFD_INTEL_MSIC) += intel_msic.o
obj-$(CONFIG_MFD_S5M_CORE) += s5m-core.o s5m-irq.o
+obj-$(CONFIG_MFD_ANATOP) += anatop-mfd.o
diff --git a/drivers/mfd/anatop-mfd.c b/drivers/mfd/anatop-mfd.c
new file mode 100644
index 0000000..4272e60
--- /dev/null
+++ b/drivers/mfd/anatop-mfd.c
@@ -0,0 +1,142 @@
+/*
+ * Anatop MFD driver
+ *
+ * Copyright (C) 2012 Ying-Chun Liu (PaulLiu) <paul.liu(a)linaro.org>
+ * Copyright (C) 2012 Linaro
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ */
+
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/of_address.h>
+#include <linux/mfd/anatop.h>
+
+u32 anatop_get_bits(struct anatop *adata, u32 addr, int bit_shift,
+ int bit_width)
+{
+ u32 val, mask;
+
+ if (bit_width == 32)
+ mask = ~0;
+ else
+ mask = (1 << bit_width) - 1;
+
+ val = readl(adata->ioreg + addr);
+ val = (val >> bit_shift) & mask;
+
+ return val;
+}
+EXPORT_SYMBOL(anatop_get_bits);
+
+void anatop_set_bits(struct anatop *adata, u32 addr, int bit_shift,
+ int bit_width, u32 data)
+{
+ u32 val, mask;
+
+ if (bit_width == 32)
+ mask = ~0;
+ else
+ mask = (1 << bit_width) - 1;
+
+ spin_lock(&adata->reglock);
+ val = readl(adata->ioreg + addr) & ~(mask << bit_shift);
+ writel((data << bit_shift) | val, adata->ioreg + addr);
+ spin_unlock(&adata->reglock);
+}
+EXPORT_SYMBOL(anatop_set_bits);
+
+static const struct of_device_id of_anatop_subdevice_match[] = {
+ { .compatible = "fsl,anatop-regulator", },
+ { .compatible = "fsl,anatop-thermal", },
+ { },
+};
+
+static int __devinit of_anatop_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node;
+ void *ioreg;
+ struct anatop *drvdata;
+
+ ioreg = of_iomap(np, 0);
+ if (!ioreg)
+ return -EADDRNOTAVAIL;
+ drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
+ if (!drvdata)
+ return -ENOMEM;
+ drvdata->ioreg = ioreg;
+ spin_lock_init(&drvdata->reglock);
+ platform_set_drvdata(pdev, drvdata);
+ of_platform_bus_probe(np, of_anatop_subdevice_match, dev);
+
+ return 0;
+}
+
+static int __devexit of_anatop_remove(struct platform_device *pdev)
+{
+ struct anatop *drvdata;
+ drvdata = platform_get_drvdata(pdev);
+ iounmap(drvdata->ioreg);
+ return 0;
+}
+
+static const struct of_device_id of_anatop_match[] = {
+ { .compatible = "fsl,imx6q-anatop", },
+ { },
+};
+
+static struct platform_driver anatop_of_driver = {
+ .driver = {
+ .name = "anatop-mfd",
+ .owner = THIS_MODULE,
+ .of_match_table = of_anatop_match,
+ },
+ .probe = of_anatop_probe,
+ .remove = of_anatop_remove,
+};
+
+static int __init anatop_init(void)
+{
+ return platform_driver_register(&anatop_of_driver);
+}
+postcore_initcall(anatop_init);
+
+static void __exit anatop_exit(void)
+{
+ platform_driver_unregister(&anatop_of_driver);
+}
+module_exit(anatop_exit);
+
+MODULE_AUTHOR("Ying-Chun Liu (PaulLiu) <paul.liu(a)linaro.org>");
+MODULE_DESCRIPTION("ANATOP MFD driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/mfd/anatop.h b/include/linux/mfd/anatop.h
new file mode 100644
index 0000000..22c1007
--- /dev/null
+++ b/include/linux/mfd/anatop.h
@@ -0,0 +1,40 @@
+/*
+ * anatop.h - Anatop MFD driver
+ *
+ * Copyright (C) 2012 Ying-Chun Liu (PaulLiu) <paul.liu(a)linaro.org>
+ * Copyright (C) 2012 Linaro
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef __LINUX_MFD_ANATOP_H
+#define __LINUX_MFD_ANATOP_H
+
+#include <linux/spinlock.h>
+
+/**
+ * anatop - MFD data
+ * @ioreg: ioremap register
+ * @reglock: spinlock for register read/write
+ */
+struct anatop {
+ void *ioreg;
+ spinlock_t reglock;
+};
+
+extern u32 anatop_get_bits(struct anatop *, u32, int, int);
+extern void anatop_set_bits(struct anatop *, u32, int, int, u32);
+
+#endif /* __LINUX_MFD_ANATOP_H */
--
1.7.9.1
Located in ppa:linaro-maintainers/tools can be found the newest
version of live-build, a45 with the following linaro features
applied:
1) armhf support (both native and cross)
2) linaro meta bld information as was discussed at 4Q11 Linaro Connect
3) cross support using multistrap
Live build a45 supports Maverick, Natty, Oneiric and Precise. With you
are you able to build your own images native on an armel or armhf host
or cross using either an i386 or x86_64 host creating either armel or
armhf targets.
For image targets up to oneiric, one is not able to cross assemble the
ubuntu-desktop image. However with precise all linaro images
including the ubuntu-desktop image can be cross assembled.
Enjoy!
--
Regards,
Tom
"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian
Multimedia Tech Lead | Linaro.org │ Open source software for ARM SoCs
w) tom.gall att linaro.org
w) tom_gall att vnet.ibm.com
h) tom_gall att mac.com
Hey,
On 03/15/2012 01:39 AM, Tony Mansson wrote:
> Hi,
>
> This is interesting. I'd like to reproduce the Ethernet speed tests.
>
> Do you have the exact command lines?
Sure. You'll need two machines, on being the board. Both need to be in
the same 100 or 1000 MBit/s LAN.
On the receiver's end, run:
netcat -l 8000 > /dev/null
This will listen for incoming data on a TCP socket on port 8000. Then,
given the receiver's IP address, run the following command on the
sender's end:
dd if=/dev/zero bs=1024k count=256 > /dev/tcp/<RECEIVER IP>/8000
Note that "/dev/tcp/XYZ/8000" is a bash-specific feature.
When this command has finished, it will tell you the transfer rate. You
can cancel it anytime and it will give you the same information. But be
sure not to cancel too early as that makes the measurement less
reliable. Obviously, you can change count= to whatever you want. E.g.
with the Origen, you'd probably want to only send 10-100 MByte.
Also, you can swap receiver and sender to make sure that running netcat
on the board is not causing things to slow down.
Not the best benchmark in the world, but it's simple and you can run it
as often if you want to make it more reliable.
Hope that helps,
Jannis
> ---------- Forwarded message ----------
> From: Jannis Pohlmann <jannis.pohlmann(a)codethink.co.uk>
> Date: 14 March 2012 21:04
> Subject: Slow/broken USB and Ethernet on Snowballs/Origen boards?
> To: linaro-dev(a)lists.linaro.org
>
>
> Hi,
>
> I am currently playing with a couple of the development boards for which
> there are Linaro hwpacks and LEBs. Since what I am trying to do requires
> a lot of disk and network I/O, I've been paying special attention to the
> data transfer rates I can get out of these boards.
>
> Below is a brief summary of my findings.
>
> 1) i.MX 53
>
> * disk I/O using an external SSD drive is very good; good enough to
> not require further measurements
>
> * network I/O is approximately 9-10 MByte/s (perhaps more) which
> seems ok given the 100 MBit/s Ethernet interface
>
> 2) Snowball (PDK, version 8)
>
> * it seems to be impossible to get the USB OTG host mode to work,
> therefore I could not test disk I/O with a USB drive; it appears
> the OTG port on the version 8 board does not even have enough power
> for a powered USB to actually go online (I am unaware of the
> details of how this works unfortunately)
>
> * performing network I/O with netcat casues netcat, ksoftirqd and
> kworker to use ~33% of the CPU each, resulting in 100% CPU usage
> only to handle the network data transfer
>
> * the resulting network transfer rate is about 5.5 MByte/s, which
> is significantly less than what the 100 MBit/s Ethernet interface
> should be able to produce
>
> 3) Origen
>
> * the internal USB hub runs at Full Speed (12 MBit/s), resulting in a
> maximum USB disk I/O of 1.5 MByte/s
>
> * since the board does not feature Ethernet itself, I tried to attach
> a USB Ethernet controller to it, but of course the transfer rate
> through that is by the I/O upper limit of the USB hub
>
> * I did not test wireless but it is not feasible for what I am trying
> to do anyway
>
> I guess not all of this is surprising. The i.MX performs quite well but
> unfortunately the CPU is quite slow compared to the others. However, I
> wonder whether the USB OTG host mode issue on the Snowball is a known
> problem? Also, network I/O occupying all of the CPU seems to be a bug or
> at least a dodgy driver. About the Origen: I assume there is nothing
> that can be done to have High Speed USB on it?
>
> Thanks in advance! If anyone needs me to provide more information, I'll
> gladly try to do that.
>
> Regards,
> Jannis
>
> _______________________________________________
> linaro-dev mailing list
> linaro-dev(a)lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
