[PATCHv2] export clock debug information to user space
Change log: 1. rebased on the latest code of git://kernel.ubuntu.com/jk/dt/linux-2.6.git 2. changes according last round of comments ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCHv2] export clock debug information to user space
From: Yong Shen
create a tree-like directory structure in debugfs so user space
tools like powerdebug can generate readable clock information.
more functions tend to be add in, like individual clock enable/disable
by writing to this debug interface.
Signed-off-by: Yong Shen
---
arch/arm/common/Kconfig |6 ++
arch/arm/common/clkdev.c |3 +
include/linux/clk.h | 18 +++
kernel/clk.c | 124 ++
4 files changed, 151 insertions(+), 0 deletions(-)
diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
index 0a34c81..13d7cf9 100644
--- a/arch/arm/common/Kconfig
+++ b/arch/arm/common/Kconfig
@@ -41,3 +41,9 @@ config SHARP_SCOOP
config COMMON_CLKDEV
bool
select HAVE_CLK
+
+config CLK_DEBUG
+ bool "clock debug information export to user space"
+ depends on USE_COMMON_STRUCT_CLK && PM_DEBUG && DEBUG_FS
+ help
+ export clk debug information to user space
diff --git a/arch/arm/common/clkdev.c b/arch/arm/common/clkdev.c
index 9e4c4d9..1d08fb3 100644
--- a/arch/arm/common/clkdev.c
+++ b/arch/arm/common/clkdev.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
@@ -104,6 +105,7 @@ EXPORT_SYMBOL(clk_put);
void clkdev_add(struct clk_lookup *cl)
{
+ clk_debug_register(cl->clk);
mutex_lock(&clocks_mutex);
list_add_tail(&cl->node, &clocks);
mutex_unlock(&clocks_mutex);
@@ -114,6 +116,7 @@ void __init clkdev_add_table(struct clk_lookup *cl, size_t
num)
{
mutex_lock(&clocks_mutex);
while (num--) {
+ clk_debug_register(cl->clk);
list_add_tail(&cl->node, &clocks);
cl++;
}
diff --git a/include/linux/clk.h b/include/linux/clk.h
index ae7e4ed..bf9396a 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -64,14 +64,26 @@ struct clk {
struct mutexmutex;
spinlock_t spinlock;
} lock;
+#ifdef CONFIG_CLK_DEBUG
+#define CLK_NAME_LEN 32
+ char name[CLK_NAME_LEN];
+ struct dentry *dentry;
+#endif
};
+#ifdef CONFIG_CLK_DEBUG
+#define __INIT_CLK_DEBUG(n) .name = #n,
+#else
+#define __INIT_CLK_DEBUG(n)
+#endif
+
/* static initialiser for non-atomic clocks */
#define INIT_CLK(name, o) {\
.ops= &o, \
.enable_count = 0,\
.flags = 0,\
.lock.mutex = __MUTEX_INITIALIZER(name.lock.mutex), \
+ __INIT_CLK_DEBUG(name) \
}
/* static initialiser for atomic clocks */
@@ -308,4 +320,10 @@ struct clk *clk_get_sys(const char *dev_id, const char
*con_id);
int clk_add_alias(const char *alias, const char *alias_dev_name, char *id,
struct device *dev);
+#ifdef CONFIG_CLK_DEBUG
+void clk_debug_register(struct clk *clk);
+#else
+static inline void clk_debug_register(struct clk *clk) {}
+#endif
+
#endif
diff --git a/kernel/clk.c b/kernel/clk.c
index 2779abb..89996f3 100644
--- a/kernel/clk.c
+++ b/kernel/clk.c
@@ -10,6 +10,8 @@
#include
#include
+#include
+#include
int clk_enable(struct clk *clk)
{
@@ -112,3 +114,125 @@ struct clk_ops clk_fixed_ops = {
.get_rate = clk_fixed_get_rate,
};
EXPORT_SYMBOL_GPL(clk_fixed_ops);
+
+#ifdef CONFIG_CLK_DEBUG
+/*
+ * debugfs support to trace clock tree hierarchy and attributes
+ */
+static int clk_debug_rate_get(void *data, u64 *val)
+{
+ struct clk *clk = data;
+
+ *val = (u64)clk_get_rate(clk);
+ return 0;
+}
+DEFINE_SIMPLE_ATTRIBUTE(clk_debug_rate_fops, clk_debug_rate_get, NULL,
+ "%llu\n");
+
+
+static struct dentry *clk_root;
+static int clk_debug_register_one(struct clk *clk)
+{
+ int err;
+ struct dentry *d, *child, *child_tmp;
+ struct clk *pa = clk_get_parent(clk);
+
+ if (pa && !IS_ERR(pa))
+ d = debugfs_create_dir(clk->name, pa->dentry);
+ else {
+ if (!clk_root)
+ clk_root = debugfs_create_dir("clocks", NULL);
+ if (!clk_root)
+ return -ENOMEM;
+ d = debugfs_create_dir(clk->name, clk_root);
+ }
+
+ if (!d)
+ return -ENOMEM;
+
+ clk->dentry = d;
+
+ d = debugfs_create_u32("enable_count", S_IRUGO, clk->dentry,
+ (u32 *)&clk->enable_count);
+ if (!d) {
+ err = -ENOMEM;
+ goto err_out;
+ }
+
+ d = debugfs_create_file("rate", S_IRUGO, clk->dentry, (void *)clk,
+ &clk_debug_rate_fops);
+ if (!d) {
+ err = -ENOMEM;
+ goto err_out;
+ }
+
+ return 0;
+
+err_out:
+ d = clk->dentry;
+ list_for_each_entry_safe(child, chi
Re: Freescale Linux BSP review
On Sun, Dec 12, 2010 at 5:41 AM, Arnd Bergmann wrote: > Following a discussion we had on the Freescale BSP, I started a tree > at http://git.linaro.org/gitweb?p=people/arnd/imx.git;a=summary > that has the same contents as the tree on the freescale git > server, but splits them into six branches at this time, though > the number should increase. > And in addition to Arnd's great analysis, by looking at the statistics of the differences as a whole based on each directory, here are some more insights: NOTE: FSL's latest imx_2.6.35_10.10.01 release is based on v2.6.35.3. 1. arch/arm $> git diff --shortstat v2.6.35.3.. arch/arm 378 files changed, 140310 insertions(+), 1969 deletions(-) However, not all of these changes are i.MX 51 or i.MX 53 based, $> git diff --dirstat v2.6.35.3.. arch/arm 10.2% arch/arm/configs/ 5.6% arch/arm/mach-mx23/include/mach/ 8.3% arch/arm/mach-mx23/ 5.2% arch/arm/mach-mx25/ 5.4% arch/arm/mach-mx28/include/mach/ 11.4% arch/arm/mach-mx28/ 5.6% arch/arm/mach-mx3/ 21.3% arch/arm/mach-mx5/ 10.7% arch/arm/plat-mxc/include/mach/ 3.9% arch/arm/plat-mxc/sdma/iapi/ 5.6% arch/arm/plat-mxc/ 6.0% arch/arm/plat-mxs/ Excluding arch/arm/configs, which we need to sort out a bit for a more structural Kconfig scheme - the i.MX 5 related changes are basically: arch/arm/mach-mx5/ 53 files changed, 31554 insertions(+), 1221 deletions(-) arch/arm/plat-mxc/ 109 files changed, 26618 insertions(+), 381 deletions(-) - The number of total of patches involved in the above changes is 132: $> git log --pretty=oneline 6d23f50.. arch/arm/mach-mx5 arch/arm/plat-mxc | wc -l 132 - Of all the changes to arch/arm/mach-mx5 and arch/arm/plat-mxc, some are more significant, esp. the files below: arch/arm/mach-mx5/clock.c | 5098 ++ arch/arm/mach-mx5/clock_mx50.c | 3435 ++ arch/arm/plat-mxc/include/mach/pmic_audio.h| 2315 + arch/arm/plat-mxc/include/mach/pmic_convity.h | 873 + arch/arm/plat-mxc/include/mach/pmic_power.h| 1358 + arch/arm/plat-mxc/sdma/iapi/src/iapiHigh.c | 2750 + arch/arm/plat-mxc/sdma/sdma.c | 1551 + However, the changes above are mostly trivial definitions. - The change to generic ARM architecture code is actually not much, excluding those SoC specific, here's the summary: arch/arm/Kconfig | 39 +- arch/arm/Makefile |3 + arch/arm/boot/compressed/Makefile |1 + arch/arm/boot/compressed/head.S| 53 + arch/arm/kernel/head.S | 31 +- arch/arm/kernel/setup.c| 10 +- arch/arm/mm/cache-l2x0.c | 34 + arch/arm/mm/proc-v6.S | 16 + arch/arm/tools/mach-types | 161 +- The changes to above are relatively trivial, including an early patch of dynamic PHYS_OFFSET offset (not yet merged in mainline), Catalin's patch of partial low interrupt latency mode for ARM1136, enabling/disabling of L2 cache, and the change to mach-types as always. - As a result, the components need love are highlighted below, some of the code should have already been merged since Amit pushed the first base port of i.MX 51: * bus_freq.c [1] * clocks and devices * DMA * USB * SDMA [1] it seems to be a workaround of having the bus frequency stays somewhere before suspend For the peripheral driver specific changes, a preliminary scan resulted in a list of the drivers below: - crypto driver (DCP) - PATA driver - Random Number Generator - One-Time-Programming Fuse - SIM controller - Internal Memory (IIM) - I2C master/slave - Keypad - Power Management IC (MC13892 and else?) - Camera Capture - OPL (An in-kernel software rotation library?) - IPU Post-Processing Unit - MMC - NAND - ADC - CAN Bus - Ethernet - InfraRed - RTC - UART (should have been supported already in mainline) - USB Host/Gadget/OTG - Framebuffer - EPD (E-Ink controller) ?? - Audio controller (AC97/SSI) As Arnd has pointed out, the drivers/mxc/* directory contains those code that is very freescale specific and needs special love to get them into individual drivers, including the GPU driver. And some of the drivers have two versions, one FSL version and one mainline version, we need to figure out and fill the gaps. For those off-chip/on-board peripherals, below drivers need love: - Si4702 (FM radio), there is driver already there supporting this in drivers/media/radio/si470x/ - hwmon (isl29003, max17135, mma7450) - MC9S08DZ60 Keypad module - MPR084 Touch Sensor Keypad module - TSC2007 (there is already support in upstream) - Various audio codecs The off-chip peripherals are not necessary part of Freescale code , but needs to be there in our kernel
Re: Freescale Linux BSP review
Dnia niedziela, 12 grudnia 2010 o 21:45:37 Linus Walleij napisał(a): > Is the AMD GPU exposing all functionality in its kernel driver or > is there some userspace blob somewhere with lots of e.g. GL > goodies? There is libgsl.so which do glue between kernel and X11 driver. closed source. Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: OMAP query about GPMC FIFOTHRESHOLDSTATUS bit
> From: Peter Maydell [mailto:peter.mayd...@linaro.org] > Sent: Sunday, December 12, 2010 3:02 PM > In case you're collecting things to clean up for the next issue, > here's > another :-) The Rev M OMAP35x TRM says on page 1139: > > "In both prefetch and write-posting modes, the engine respectivelly > uses byte or Word16 access requests for an 8- or 16-bit wide NAND > device attached to the linked chip-select. The FIFOTHRESHOLD and > TRANSFERCOUNT fields must be programmed accordingly as a > number of bytes or a number of Word16." Yes that appears wrong in all TRM and underlying specs. > However the register descriptions just say that FIFOTHRESHOLD > and TRANSFERCOUNT are byte counts. > > In this case I'm going to trust the register descriptions because > that's how Linux programs them (and it doesn't boot if you model > them as Word16 counts...) A search on TRANSFERCOUNT does show 3 spots where it explicitly says bytes. I'll forward to TRM owners. I know the right folks for 34xx,36xx,44xx, I think that should propagate to 35xx and other variants. Regards, Richard W. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Freescale Linux BSP review
On Monday 13 December 2010, Eric Miao wrote: > However, not all of these changes are i.MX 51 or i.MX 53 based, > > $> git diff --dirstat v2.6.35.3.. arch/arm > > 10.2% arch/arm/configs/ >5.6% arch/arm/mach-mx23/include/mach/ >8.3% arch/arm/mach-mx23/ >5.2% arch/arm/mach-mx25/ >5.4% arch/arm/mach-mx28/include/mach/ > 11.4% arch/arm/mach-mx28/ >5.6% arch/arm/mach-mx3/ > 21.3% arch/arm/mach-mx5/ > 10.7% arch/arm/plat-mxc/include/mach/ >3.9% arch/arm/plat-mxc/sdma/iapi/ >5.6% arch/arm/plat-mxc/ >6.0% arch/arm/plat-mxs/ FWIW, I've split out the mach-mx23/mx28 and plat-mxs changes into another branch now. The mach-mx25/mx3/mx5 changes could probably be split up further as well, but that will be a bit harder because they all share infrastructure in plat-mxc. More importantly, I think the sdma stuff needs to be split out from the rest, as this is likely more controversial. This will also be hard to do, since there are a number of changesets that touch both sdma and arch code. > Excluding arch/arm/configs, which we need to sort out a bit for a more > structural Kconfig scheme > > - the i.MX 5 related changes are basically: > >arch/arm/mach-mx5/ 53 files changed, 31554 insertions(+), 1221 > deletions(-) >arch/arm/plat-mxc/ 109 files changed, 26618 insertions(+), 381 > deletions(-) The plat-mxc changes are mostly, but not all i.MX5 specific. We need to be careful there. > - Of all the changes to arch/arm/mach-mx5 and arch/arm/plat-mxc, some >are more significant, esp. the files below: > >arch/arm/mach-mx5/clock.c | 5098 ++ >arch/arm/mach-mx5/clock_mx50.c | 3435 ++ >arch/arm/plat-mxc/include/mach/pmic_audio.h| 2315 + >arch/arm/plat-mxc/include/mach/pmic_convity.h | 873 + >arch/arm/plat-mxc/include/mach/pmic_power.h| 1358 + >arch/arm/plat-mxc/sdma/iapi/src/iapiHigh.c | 2750 + >arch/arm/plat-mxc/sdma/sdma.c | 1551 + > >However, the changes above are mostly trivial definitions. SDMA as a whole is interesting. It would be worthwhile to find out how it fits in with the rest of the drivers and architecture, and what it would take to bring this upstream. > - The change to generic ARM architecture code is actually not much, >excluding those SoC specific, here's the summary: > >arch/arm/Kconfig | 39 +- >arch/arm/Makefile |3 + >arch/arm/boot/compressed/Makefile |1 + >arch/arm/boot/compressed/head.S| 53 + >arch/arm/kernel/head.S | 31 +- >arch/arm/kernel/setup.c| 10 +- >arch/arm/mm/cache-l2x0.c | 34 + >arch/arm/mm/proc-v6.S | 16 + >arch/arm/tools/mach-types | 161 +- > >The changes to above are relatively trivial, including an early patch of >dynamic PHYS_OFFSET offset (not yet merged in mainline), Catalin's patch >of partial low interrupt latency mode for ARM1136, enabling/disabling of >L2 cache, and the change to mach-types as always. I think all of these changes are upstream in one way or another. > And some of the drivers have two versions, one FSL version and one > mainline version, we need to figure out and fill the gaps. Good point, I had not realized this. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Neon registers in core files
On 12/03/2010 10:57 PM, Dave Martin wrote: [Apologized for delayed reply] > My guess is that it shouldn't be hard to dump the VFP/NEON state, but > GDB and the kernel need to agree on the format. > Exactly. That is why we need your guys' support from kernel side. :) > Rather that trying to hack the existing register dump format in a > compatible way, I suggest it's simplest if the kernel creates an extra > section in the dump containing something like: w.r.t creating a new section in dump, here are some cents from GDB, or even other related tools, point of view, - GDB has an infrastructure to read register values from sections other than ".reg" and ".reg2". Different targets have to define its own hooks to achieve that. - arm-linux gdb doesn't use this infrastructure, register values are still read from section ".reg" and ".reg2". However, it is not hard to change to use that infrastructure. - No sure how much impact to other related tools. Take readelf for an example. readelf should be change a little bit. Current readelf displays some info like this, Notes at offset 0x0234 with length 0x0264: Owner Data size Description CORE 0x007c NT_PRPSINFO (prpsinfo structure) [...] After we add extra section in dump, output is like, Notes at offset 0x0234 with length 0x0264: Owner Data size Description CORE 0x007c NT_PRPSINFO (prpsinfo structure) [...] Notes at offset 0x0XX with length 0x0XXX: Owner Data size Description CORE 0x00XX NT_NEONREGSET (NEON registers) - how easy it will be to make these changes accepted upstreams, both kernel side and toolchain side. So far, as far as I know about kernel and GDB sides, I prefer "single section" approach a little bit, but "extra section" approach is also acceptable to me. Finally, we need an agreement on this, so any comments/suggestions on this are welcome. > > .longformat_version /* reserved for future expansion - must be 0 > */ > .longFPSID > .longFPSCR > .longMVFR0 /* or 0 if not present in the hardware */ > .longMVFR1 /* or 0 if not present in the hardware */ > .longd0 > .longd1 > /* ... d2-d14 ... */ > .longd15 > If 32 D-registers in the hardware [ > .long d16 > .long d17 > /* ... d18-d30 ... */ > .long d31 > ] > > I believe we don't need any extra flags to indicate whether the MVFRx > fields are valid, since 0 in these registers indicates the > VFPv2/legacy behaviour anyway. Note that some VFPv2 implementations > (such as ARM1176) do provide these registers, and where the hardware > has them, the kernel can fill them in when doing the coredump. > Due to my very limited knowledge on ARM arch, I have no comment on this. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Freescale Linux BSP review
On Monday 13 December 2010, Jammy Zhou wrote: > On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij > wrote: > > > On 11 December 2010 22:41, Arnd Bergmann wrote: > > > > * amd-gpu -- a single but huge driver for the GPU. As is normally the > >> case with GPU drivers, we can expect long discussions > >> before it will get considered for mainline > >> 4 patches > >> 98 files changed, 278321 insertions(+), 0 deletions(-) > >> > > > > Just out of curiosity, following the discussion between Dave Airlie > > and Codeaurora this summer re GPU driver shims. > > > > Is the AMD GPU exposing all functionality in its kernel driver or > > is there some userspace blob somewhere with lots of e.g. GL > > goodies? > > > All the functionality for the kernel driver of AMD GPU Z430/Z160 (now > belongs to Qualcom) is exposed. But we need accompanied userspace library to > call these functionality (buffer management, command submission, ...). Who owns these components? If it's closed source, the only options we have are lobbying for complete release of the specs for a reimplementation or reverse-engineering the drivers, which may at least get easier with a user space driver than it would be with a kernel driver. Until there is a solution with an open source user space part, I would suggest that the driver better be dropped from the Freescale BSP and we should at least not waste time reviewing it. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Freescale Linux BSP review
On Mon, Dec 13, 2010 at 10:18 AM, Arnd Bergmann wrote: > On Monday 13 December 2010, Jammy Zhou wrote: >> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij >> wrote: >> >> > On 11 December 2010 22:41, Arnd Bergmann wrote: >> > >> > * amd-gpu -- a single but huge driver for the GPU. As is normally the >> >> case with GPU drivers, we can expect long discussions >> >> before it will get considered for mainline >> >> 4 patches >> >> 98 files changed, 278321 insertions(+), 0 deletions(-) >> >> >> > >> > Just out of curiosity, following the discussion between Dave Airlie >> > and Codeaurora this summer re GPU driver shims. >> > >> > Is the AMD GPU exposing all functionality in its kernel driver or >> > is there some userspace blob somewhere with lots of e.g. GL >> > goodies? >> > >> All the functionality for the kernel driver of AMD GPU Z430/Z160 (now >> belongs to Qualcom) is exposed. But we need accompanied userspace library to >> call these functionality (buffer management, command submission, ...). > > Who owns these components? If it's closed source, the only options we > have are lobbying for complete release of the specs for a reimplementation > or reverse-engineering the drivers, which may at least get easier with > a user space driver than it would be with a kernel driver. > > Until there is a solution with an open source user space part, I would > suggest that the driver better be dropped from the Freescale BSP and > we should at least not waste time reviewing it. > > Arnd >From a quick look it also seems that the API exposed to userspace would allow easy abuse of the GPU to access any system ram. There is a reason we do expensive command checking in the other amd gpu driver (drivers/gpu/drm/radeon/*cs.c files) Cheers, Jerome ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro gcc ICE bug
Khem Raj wrote: > The bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46883 files > against GCC trunk also happens with linaro gcc 4.5 > My guess is that there is a backported patch from trunk into linaro > 4.5 tree thats causing this ICE > > This ICE does not happen on upstream gcc-4.5 branch Thanks for the bug report! > I havent figured out the commit yet. It looks like the regression was introduced by Bernd Schmidt's patch to improve zero-/sign-extensions (PR 42172), which we did indeed backport to Linaro GCC 4.5. (I've updated the PR 46883 bugzilla with more details.) > Should you need a bug in linaro > bug tracker I will be happy to file one Yes, please do so; this makes it easier to track the problem on the Linaro side. Thanks! Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Notes & Actions: Linaro Graphics Working Group - Dec 13, 2010
Hi, notes and actions from our Monday graphics cross-vendor call are available on the wiki: + https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Notes/2010-12-13 Details about when and where of this meeting can be found here: + https://wiki.linaro.org/WorkingGroups/Middleware/Graphics#Weekly%20Public%20Call Thanks, -- - Alexandros ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Notes & Actions: Linaro User Platform Weekly Status Meeting 12/08
Greetings, Enclosed you'll find a link to the agenda, notes and actions from the Linaro User Platforms Weekly Status meeting dated December 8th held in #linaro-meeting on irc.freenode.net at 13:00 UTC. https://wiki.linaro.org/Platform/UserPlatforms/WeeklyStatus/2010-12-08 Status Summary: - Kurt Taylor aka krtaylor joined the team as Multmedia Engineer (Audio) - first patch for linaro 11.05 cairo GLES efforts upstreamed (pending) - Alexandros Frantzis - first patch for gstreamer colorspace converter submitted - Benjamin Gaignard - minisprint for OBS toolchain delivery and first steps together with linuxfoundation - Alexandros recognized for this good work by ubuntu community with the title: Ubuntu Contributing Developer - vp8 and and omax standardization specs approved - proof of concept for a glproxy library that will allow runtime selecting of GL vs. GLES finished - Jammy Zhou Regards, Tom (tgall_foo) User Platforms Team "We want great men who, when fortune frowns will not be discouraged." - Colonel Henry Knox w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Freescale Linux BSP review
On Mon, Dec 13, 2010 at 11:18 PM, Arnd Bergmann wrote: > On Monday 13 December 2010, Jammy Zhou wrote: > > On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij >wrote: > > > > > On 11 December 2010 22:41, Arnd Bergmann wrote: > > > > > > * amd-gpu -- a single but huge driver for the GPU. As is normally the > > >> case with GPU drivers, we can expect long discussions > > >> before it will get considered for mainline > > >> 4 patches > > >> 98 files changed, 278321 insertions(+), 0 deletions(-) > > >> > > > > > > Just out of curiosity, following the discussion between Dave Airlie > > > and Codeaurora this summer re GPU driver shims. > > > > > > Is the AMD GPU exposing all functionality in its kernel driver or > > > is there some userspace blob somewhere with lots of e.g. GL > > > goodies? > > > > > All the functionality for the kernel driver of AMD GPU Z430/Z160 (now > > belongs to Qualcom) is exposed. But we need accompanied userspace library > to > > call these functionality (buffer management, command submission, ...). > > Who owns these components? If it's closed source, the only options we > have are lobbying for complete release of the specs for a reimplementation > or reverse-engineering the drivers, which may at least get easier with > a user space driver than it would be with a kernel driver. > The user space library is closed source, and it is owned by Qualcomm. > > Until there is a solution with an open source user space part, I would > suggest that the driver better be dropped from the Freescale BSP and > we should at least not waste time reviewing it. > I think it is beneficial for us to integrate the kernel part into our Linaro tree, so that we can build/use it together with the kernel image. As for the user space libraries, how about adding them into the hwpack? (Is there any legal issue for this?) > >Arnd > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Freescale Linux BSP review
On Tue, Dec 14, 2010 at 12:11 AM, Jerome Glisse wrote: > On Mon, Dec 13, 2010 at 10:18 AM, Arnd Bergmann wrote: > > On Monday 13 December 2010, Jammy Zhou wrote: > >> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij < > linus.wall...@linaro.org>wrote: > >> > >> > On 11 December 2010 22:41, Arnd Bergmann wrote: > >> > > >> > * amd-gpu -- a single but huge driver for the GPU. As is normally the > >> >> case with GPU drivers, we can expect long discussions > >> >> before it will get considered for mainline > >> >> 4 patches > >> >> 98 files changed, 278321 insertions(+), 0 deletions(-) > >> >> > >> > > >> > Just out of curiosity, following the discussion between Dave Airlie > >> > and Codeaurora this summer re GPU driver shims. > >> > > >> > Is the AMD GPU exposing all functionality in its kernel driver or > >> > is there some userspace blob somewhere with lots of e.g. GL > >> > goodies? > >> > > >> All the functionality for the kernel driver of AMD GPU Z430/Z160 (now > >> belongs to Qualcom) is exposed. But we need accompanied userspace > library to > >> call these functionality (buffer management, command submission, ...). > > > > Who owns these components? If it's closed source, the only options we > > have are lobbying for complete release of the specs for a > reimplementation > > or reverse-engineering the drivers, which may at least get easier with > > a user space driver than it would be with a kernel driver. > > > > Until there is a solution with an open source user space part, I would > > suggest that the driver better be dropped from the Freescale BSP and > > we should at least not waste time reviewing it. > > > >Arnd > > From a quick look it also seems that the API exposed to userspace > would allow easy abuse of the GPU to access any system ram. There is a > reason we do expensive command checking in the other amd gpu driver > (drivers/gpu/drm/radeon/*cs.c files) > No, the memory used by the GPU is reserved at boot time, so I think there is no such a problem. > > Cheers, > Jerome > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Freescale Linux BSP review
On Tue, Dec 14, 2010 at 10:06 AM, Jerome Glisse wrote: > On Mon, Dec 13, 2010 at 9:04 PM, Jammy Zhou wrote: > > > > > > On Tue, Dec 14, 2010 at 12:11 AM, Jerome Glisse > wrote: > >> > >> On Mon, Dec 13, 2010 at 10:18 AM, Arnd Bergmann wrote: > >> > On Monday 13 December 2010, Jammy Zhou wrote: > >> >> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij > >> >> wrote: > >> >> > >> >> > On 11 December 2010 22:41, Arnd Bergmann wrote: > >> >> > > >> >> > * amd-gpu -- a single but huge driver for the GPU. As is normally > the > >> >> >> case with GPU drivers, we can expect long discussions > >> >> >> before it will get considered for mainline > >> >> >> 4 patches > >> >> >> 98 files changed, 278321 insertions(+), 0 deletions(-) > >> >> >> > >> >> > > >> >> > Just out of curiosity, following the discussion between Dave Airlie > >> >> > and Codeaurora this summer re GPU driver shims. > >> >> > > >> >> > Is the AMD GPU exposing all functionality in its kernel driver or > >> >> > is there some userspace blob somewhere with lots of e.g. GL > >> >> > goodies? > >> >> > > >> >> All the functionality for the kernel driver of AMD GPU Z430/Z160 (now > >> >> belongs to Qualcom) is exposed. But we need accompanied userspace > >> >> library to > >> >> call these functionality (buffer management, command submission, > ...). > >> > > >> > Who owns these components? If it's closed source, the only options we > >> > have are lobbying for complete release of the specs for a > >> > reimplementation > >> > or reverse-engineering the drivers, which may at least get easier with > >> > a user space driver than it would be with a kernel driver. > >> > > >> > Until there is a solution with an open source user space part, I would > >> > suggest that the driver better be dropped from the Freescale BSP and > >> > we should at least not waste time reviewing it. > >> > > >> >Arnd > >> > >> From a quick look it also seems that the API exposed to userspace > >> would allow easy abuse of the GPU to access any system ram. There is a > >> reason we do expensive command checking in the other amd gpu driver > >> (drivers/gpu/drm/radeon/*cs.c files) > > > > No, the memory used by the GPU is reserved at boot time, so I think there > is > > no such a problem. > > > >> > >> Cheers, > >> Jerome > > > > > > This isn't about what's reserved, this is about GPU capacity, if the > GPU is isolated through an IOMMU and the GPU can't reprogram it then > fine. But if not, then it's easy to abuse packet to reprogram the GPU > GART (either by reprogramming GART register or by overwritting GART > table) to point to any system ram. > For non-PCI GPU in embedded world, there is no GART concept. Besides, the GPU MMU is disabled currently for some hardware problem. > > Cheers, > Jerome > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Freescale Linux BSP review
On Tue, Dec 14, 2010 at 9:59 AM, Jammy Zhou wrote: > > > On Mon, Dec 13, 2010 at 11:18 PM, Arnd Bergmann wrote: >> >> On Monday 13 December 2010, Jammy Zhou wrote: >> > On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij >> > wrote: >> > >> > > On 11 December 2010 22:41, Arnd Bergmann wrote: >> > > >> > > * amd-gpu -- a single but huge driver for the GPU. As is normally the >> > >> case with GPU drivers, we can expect long discussions >> > >> before it will get considered for mainline >> > >> 4 patches >> > >> 98 files changed, 278321 insertions(+), 0 deletions(-) >> > >> >> > > >> > > Just out of curiosity, following the discussion between Dave Airlie >> > > and Codeaurora this summer re GPU driver shims. >> > > >> > > Is the AMD GPU exposing all functionality in its kernel driver or >> > > is there some userspace blob somewhere with lots of e.g. GL >> > > goodies? >> > > >> > All the functionality for the kernel driver of AMD GPU Z430/Z160 (now >> > belongs to Qualcom) is exposed. But we need accompanied userspace >> > library to >> > call these functionality (buffer management, command submission, ...). >> >> Who owns these components? If it's closed source, the only options we >> have are lobbying for complete release of the specs for a reimplementation >> or reverse-engineering the drivers, which may at least get easier with >> a user space driver than it would be with a kernel driver. > > The user space library is closed source, and it is owned by Qualcomm. > >> >> Until there is a solution with an open source user space part, I would >> suggest that the driver better be dropped from the Freescale BSP and >> we should at least not waste time reviewing it. > > I think it is beneficial for us to integrate the kernel part into our Linaro > tree, so that we can build/use it together with the kernel image. As for the > user space libraries, how about adding them into the hwpack? (Is there any > legal issue for this?) I think so, there's normally a rule if free redistribution is allowed or not, even it's closed source. > >> >> Arnd > > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
The Linaro kernel tree maintenance now documented
Several people were asking me what the Linaro kernel actually is, what it contains, the patch acceptance criteria, etc. And since this happened while I was also questioning our previous kernel maintenance process[1], I took upon myself to formally document what the current process is for the benefit of all, so people (including myself) could refer to it in the future. So, per popular requests, this is now live: https://wiki.linaro.org/WorkingGroups/KernelConsolidation/KernelTree Please feel free to send me comments, or ask more questions if something is not clear. Nicolas [1] http://lists.linaro.org/pipermail/linaro-dev/2010-November/001505.html ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
