Re: Yet another memory provider: can linaro organize a meeting?
Sorry but I feel the discussion is a bit off the point. We're not going to compare the pros and cons of current code (GEM/TTM, HWMEM, UMP, CMA, VCM, CMEM, PMEM, etc.) The real problem is to find a suitable unified memory management module for various kinds of HW components (including CPU, VPU, GPU, camera, FB/OVL, etc.), especially for ARM based SOC. Some HW requires physical continuous big chunk of memory (e.g. some VPU & OVL); while others could live with DMA chain (e.g. some powerful GPU has built-in MMU). So, what's current situation? 1) As Hans mentioned, there're GEM & TTM in upstream kernel, under the DRM framework (w/ KMS, etc.). This works fine on conventional (mostly Xorg-based) Linux distribution. 2) But DRM (or GEM/TTM) is still too heavy and complex to some embedded OS, which only want a cheaper memory management module. So... 2.1) Google uses PMEM in Android - However PMEM was removed from upstream kernel for well-known reasons; 2.2) Qualcomm writes a hybrid KGSL based DRM+PMEM solution - However KGSL was shamed in dri-devel list because their close user space binary. 2.3) ARM starts UMP/MaliDRM for both of Android and X11/DRI2 - This makes things even more complicated. (Therefore I personally think this is actually a shame for ARM to create another private SW. As a leader of Linaro, ARM should think more and coordinate with partners better to come up a unified solution to make our life easier.) 2.4) Other companies also have their own private solutions because nobody can get a STANDARD interface from upstream, including Marvell, TI, Freescale. In general, it would be highly appreciated if Linaro guys could sit down together around a table, co-work with silicon vendors and upstream Linux kernel maintainers to make a unified (and cheaper than GEM/TTM/DRM) memory management module. This module should be reviewed carefully and strong enough to replace any other private memory manager mentioned above. It should replace PMEM for Android (with respect to Gralloc). And it could even be leveraged in DRM framework (as a primitive memory allocation provider under GEM). Anyway, such a module is necessary, because user space application cannot exchange enough information by a single virtual address (among different per-process virtual address space). Gstreamer, V4L and any other middleware could remain using a single virtual address in the same process. But a global handler/ID is also necessary for sharing buffers between processes. Furthermore, besides those well-known basic features, some advanced APIs should be provided for application to map the same physical memory region into another process, with 1) manageable fine CACHEable/BUFFERable attributes and cache flush mechanism (for performance); 2) lock/unlock synchronization; 3) swap/migration ability (optional in current stage, as those buffer are often expected to stay in RAM for better performance). Finally, and the most important, THIS MODULE SHOULD BE PUSHED TO UPSTREAM (sorry, please ignore all the nonsense I wrote above if we can achieve this) so that everyone treat it as a de facto well supported memory management module. Thus all companies could transit from current private design to this public one. And, let's cheer for the end of this damn chaos! Thanks, Lea On Wed, Mar 16, 2011 at 12:47 AM, Alex Deucher wrote: > On Tue, Mar 15, 2011 at 12:07 PM, Robert Fekete > wrote: >> On 8 March 2011 20:23, Laurent Pinchart >> wrote: >>> Hi Andy, >>> >>> On Tuesday 08 March 2011 20:12:45 Andy Walls wrote: On Tue, 2011-03-08 at 16:52 +0100, Laurent Pinchart wrote: [snip] > > > It really shouldn't be that hard to get everyone involved together > > > and settle on a single solution (either based on an existing > > > proposal or create a 'the best of' vendor-neutral solution). > > > > "Single" might be making the problem impossibly hard to solve well. > > One-size-fits-all solutions have a tendency to fall short on meeting > > someone's critical requirement. I will agree that "less than n", for > > some small n, is certainly desirable. > > > > The memory allocators and managers are ideally satisfying the > > requirements imposed by device hardware, what userspace applications > > are expected to do with the buffers, and system performance. (And > > maybe the platform architecture, I/O bus, and dedicated video memory?) > > In the embedded world, a very common use case is to capture video data > from an ISP (V4L2+MC), process it in a DSP (V4L2+M2M, tidspbridge, ...) > and display it on the GPU (OpenGL/ES). We need to be able to share a > data buffer between the ISP and the DSP, and another buffer between the > DSP and the GPU. If processing is not required, sharing a data buffer > between the ISP and the GPU is required. Achieving zero-copy requires a > single memory management solution used by the ISP, the DSP and
Re: [PATCH] arm/dt: Add dtb make rule
On Mon, Mar 14, 2011 at 06:34:53PM -0500, Rob Herring wrote: > Grant, > > On 03/10/2011 01:46 PM, Rob Herring wrote: > >From: Rob Herring > > > >Add a make rule to compile dt blobs for ARM. > > > >Signed-off-by: Rob Herring > > Can you pick this one up in your ARM tree. Done. Will be pushed out alter tonight. g. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Yet another memory provider: can linaro organize a meeting?
On Wed, Mar 16, 2011 at 4:37 PM, Li Li wrote: > Sorry but I feel the discussion is a bit off the point. We're not > going to compare the pros and cons of current code (GEM/TTM, HWMEM, > UMP, CMA, VCM, CMEM, PMEM, etc.) > > The real problem is to find a suitable unified memory management > module for various kinds of HW components (including CPU, VPU, GPU, > camera, FB/OVL, etc.), especially for ARM based SOC. Some HW requires > physical continuous big chunk of memory (e.g. some VPU & OVL); while > others could live with DMA chain (e.g. some powerful GPU has built-in > MMU). > > So, what's current situation? > > 1) As Hans mentioned, there're GEM & TTM in upstream kernel, under the > DRM framework (w/ KMS, etc.). This works fine on conventional (mostly > Xorg-based) Linux distribution. > > 2) But DRM (or GEM/TTM) is still too heavy and complex to some > embedded OS, which only want a cheaper memory management module. So... > > 2.1) Google uses PMEM in Android - However PMEM was removed from > upstream kernel for well-known reasons; > > 2.2) Qualcomm writes a hybrid KGSL based DRM+PMEM solution - However > KGSL was shamed in dri-devel list because their close user space > binary. > > 2.3) ARM starts UMP/MaliDRM for both of Android and X11/DRI2 - This > makes things even more complicated. (Therefore I personally think this > is actually a shame for ARM to create another private SW. As a leader > of Linaro, ARM should think more and coordinate with partners better > to come up a unified solution to make our life easier.) > > 2.4) Other companies also have their own private solutions because > nobody can get a STANDARD interface from upstream, including Marvell, > TI, Freescale. > > > > In general, it would be highly appreciated if Linaro guys could sit > down together around a table, co-work with silicon vendors and > upstream Linux kernel maintainers to make a unified (and cheaper than > GEM/TTM/DRM) memory management module. This module should be reviewed > carefully and strong enough to replace any other private memory > manager mentioned above. It should replace PMEM for Android (with > respect to Gralloc). And it could even be leveraged in DRM framework > (as a primitive memory allocation provider under GEM). > > Anyway, such a module is necessary, because user space application > cannot exchange enough information by a single virtual address (among > different per-process virtual address space). Gstreamer, V4L and any > other middleware could remain using a single virtual address in the > same process. But a global handler/ID is also necessary for sharing > buffers between processes. > > Furthermore, besides those well-known basic features, some advanced > APIs should be provided for application to map the same physical > memory region into another process, with 1) manageable fine > CACHEable/BUFFERable attributes and cache flush mechanism (for > performance); 2) lock/unlock synchronization; 3) swap/migration > ability (optional in current stage, as those buffer are often expected > to stay in RAM for better performance). > > Finally, and the most important, THIS MODULE SHOULD BE PUSHED TO > UPSTREAM (sorry, please ignore all the nonsense I wrote above if we > can achieve this) so that everyone treat it as a de facto well > supported memory management module. Thus all companies could transit > from current private design to this public one. And, let's cheer for > the end of this damn chaos! Rough schedules. 1. Warsaw meetings (3/16~3/18): mostly v4l2 person and some SoC vendors Make a consensence at media developers. and share the information. Please note that it's v4l2 brainstorming meeting. so memory management is not the main issue. 2. ELC (4/11~4/13): DRM, DRI and v4l2 person. Discuss GEM/TTM is acceptable for non-X86 system and find out the which modules are acceptable. We studied the GEM for our environment. but it's too huge and not much benefit for us since current frameworks are enough. The missing is that no generic memory passing mechanism. We need the generic memory passing interface. that's all. 3. Linaro (5/9~5/13): ARM, SoC vendors and v4l2 persons. I hope several person are anticipated and made a small step for final goal. Thank you, Kyungmin Park > > Thanks, > Lea > > On Wed, Mar 16, 2011 at 12:47 AM, Alex Deucher wrote: >> On Tue, Mar 15, 2011 at 12:07 PM, Robert Fekete >> wrote: >>> On 8 March 2011 20:23, Laurent Pinchart >>> wrote: Hi Andy, On Tuesday 08 March 2011 20:12:45 Andy Walls wrote: > On Tue, 2011-03-08 at 16:52 +0100, Laurent Pinchart wrote: > > [snip] > > > > > It really shouldn't be that hard to get everyone involved together > > > > and settle on a single solution (either based on an existing > > > > proposal or create a 'the best of' vendor-neutral solution). > > > > > > "Single" might be making the problem impossibly hard to solve well. > > > One-size-fits-all solutions have a tendency to fall sh
Re: [PATCH V4 1/5] arm/dt: add basic mx51 device tree support
On Tue, Mar 15, 2011 aFt 11:03:55PM -0600, Grant Likely wrote: > On Tue, Mar 15, 2011 at 9:34 PM, Jason Hui wrote: > > Hi, Grant, > > > > On Tue, Mar 15, 2011 at 3:03 PM, Grant Likely > > wrote: > >> Hi Jason, > >> > >> Minor comments below. > >> > >> On Thu, Mar 10, 2011 at 12:59:41PM +0800, Jason Liu wrote: > >>> Signed-off-by: Jason Liu > >>> Signed-off-by: Jason Liu > >> > >> This looks wrong. You should only have one s-o-b line. Use one email > >> addr or the other. Not both. > > > > I just take the same approach as this link: > > https://lkml.org/lkml/2010/12/17/363 > > If you think it's not applicable, I can change it. > > Yeah, I don't think that's right. A s-o-b is a personal assertion > that the patch is to the best of your knowledge that you have the > right to submit it for inclusion in the kernel (see section 12 of > Documentation/SubmittingPatches). It doesn't make any statements > about who owns the copyright on the patch or other issues of corporate > ownership. Companies may have policies about which email address > employees use when signing off, but that isn't what the s-o-b protocol > is for. > > Since there isn't more than one of you, you should only have one s-o-b > line. :-) > > Paul, since your email was presented as evidence, would you care to > offer a counter-argument? :-) How about https://lkml.org/lkml/2011/2/22/668? ;-) There is only one of me, but I am acting in two roles. Thanx, Paul ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH-Android] [android/build] Disable Werror option to avoid build errors using GCC 4.5/4.6.
Hmm ... I think disabling Werror completely is not something we should take into our main android branches. Sachin, were there just too many issues in dalvik to fix them properly? On Wed, Mar 16, 2011 at 6:16 AM, Sachin Kamat wrote: > Signed-off-by: Sachin Kamat > > Change-Id: I471e831d569b37345752d788f5a213ffd6616690 > --- > core/config.mk | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/core/config.mk b/core/config.mk > index a76aec8..45100fb 100644 > --- a/core/config.mk > +++ b/core/config.mk > @@ -98,7 +98,7 @@ COMMON_JAVA_PACKAGE_SUFFIX := .jar > COMMON_ANDROID_PACKAGE_SUFFIX := .apk > > # list of flags to turn specific warnings in to errors > -TARGET_ERROR_FLAGS := -Werror=return-type -Werror=non-virtual-dtor > -Werror=address -Werror=sequence-point > +TARGET_ERROR_FLAGS := > > # TODO: do symbol compression > TARGET_COMPRESS_MODULE_SYMBOLS := false > -- > 1.7.1 > > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: LAVA integration effort for Android validation
On Wed, Mar 16, 2011 at 6:24 AM, Sachin Kamat wrote: > > > On 16 March 2011 10:03, Michael Hudson-Doyle > wrote: >> >> On Tue, 15 Mar 2011 11:17:14 -0500, Paul Larson >> wrote: >> > > I like statically IP. How do we know which board would get which IP? >> > > One idea would be to set up a DNS for internal board names. e.g. >> > > panda01.internal.network would resolve to our preallocated static IP >> > > for board "panda01". >> > > >> > > This could then be used by the dispatcher to resolve the IP and pass >> > > it to the board through kernel cmdline. >> > > >> > > I hadn't really thought of passing it via cmdline. If we need to >> > > bring it >> > up statically, we could possibly do that, or possibly just make the >> > necessary adjustments before booting the image. What I was proposing, >> > if >> > the image is already set up to dhcp by default, we could run a dhcp >> > server >> > on the control node with the static ip assignments already in place for >> > each >> > board. >> >> How would you do this? Most boards don't have a fixed MAC address. You >> can set up a dhcp-name but that (AIUI) means a different rootfs for each >> board and then you might as well just allocate a static IP... >> > Also, some boards of the same type have the same MAC as well.. Is setting a static IP for those boards actually enough or do we also need to set some reasonable MAC? -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: gcc: Thumb interworking and weakly linked functions
Hi Ulrich,
On Tuesday 15 March 2011 09:00 PM, Ulrich Weigand wrote:
Aneesh V wrote:
I was trying to build u-boot in Thumb2 for OMAP4. Everything was fine
until I added some patches recently. One of these patches introduced an
API (let's say foo()) that has a weakly linked alias(let's say
__foo()) and a strongly linked implementation(the real foo()) in an
assembly file.
Although I give -mthumb and -mthumb-interwork for all the files,
apparently GCC generates ARM code for assembly files. In the final
image foobar() calls foo() using a BL. Since foobar() is in Thumb and
foo() in ARM, it ends up crashing. Looks like foobar() assumed foo()
to be Thumb because __foo() is Thumb.
I'm unable to reproduce this. Do you have a complete test case?
Thank you for looking into this problem.
I've tried with the following small example:
foo1.c:
extern void foo (void) __attribute__ ((weak, alias ("__foo")));
void __foo (void)
{
}
int main (void)
{
foo ();
}
foo2.S:
.text
.align 2
.global foo
.type foo, %function
foo:
push{r7}
add r7, sp, #0
mov sp, r7
pop {r7}
bx lr
.size foo, .-foo
Can you try this sequence:
arm-linux-gnueabi-gcc -march=armv7-a -mthumb -mthumb-interwork -o foo1.o
foo1.c -c
arm-linux-gnueabi-gcc -march=armv7-a -mthumb -mthumb-interwork -o foo2.o
foo2.S -c
arm-linux-gnueabi-ld -r foo1.o foo2.o
arm-linux-gnueabi-objdump -S a.out
With this sequence I get the following output:
<__foo>:
0: b480push{r7}
2: af00add r7, sp, #0
4: 46bdmov sp, r7
6: bc80pop {r7}
8: 4770bx lr
a: bf00nop
000c :
c: b580push{r7, lr}
e: af00add r7, sp, #0
10: f7ff fffe bl 18
14: 4618mov r0, r3
16: bd80pop {r7, pc}
0018 :
18: e92d0080push{r7}
1c: e28d7000add r7, sp, #0
20: e1a0d007mov sp, r7
24: e8bd0080pop {r7}
28: e12fff1ebx lr
When building just "gcc foo1.c", I get:
835c<__foo>:
835c: b480push{r7}
835e: af00add r7, sp, #0
8360: 46bdmov sp, r7
8362: bc80pop {r7}
8364: 4770bx lr
8366: bf00nop
8368:
8368: b580push{r7, lr}
836a: af00add r7, sp, #0
836c: f7ff fff6 bl 835c<__foo>
8370: 4618mov r0, r3
8372: bd80pop {r7, pc}
When building both files "gcc foo1.c foo2.S", I get instead:
8368:
8368: b580push{r7, lr}
836a: af00add r7, sp, #0
836c: f000 e802 blx 8374
8370: 4618mov r0, r3
8372: bd80pop {r7, pc}
8374:
8374: e92d0080push{r7}
8378: e28d7000add r7, sp, #0
837c: e1a0d007mov sp, r7
8380: e8bd0080pop {r7}
8384: e12fff1ebx lr
So it seems to me the linker is handling this correctly ...
(This is on Ubuntu Natty using system gcc and binutils.)
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
Re: Yet another memory provider: can linaro organize a meeting?
On Tuesday 15 March 2011 17:07:10 Robert Fekete wrote: > On 8 March 2011 20:23, Laurent Pinchart wrote: > > On Tuesday 08 March 2011 20:12:45 Andy Walls wrote: > >> On Tue, 2011-03-08 at 16:52 +0100, Laurent Pinchart wrote: > >> > >> [snip] > >> > >> > > > It really shouldn't be that hard to get everyone involved together > >> > > > and settle on a single solution (either based on an existing > >> > > > proposal or create a 'the best of' vendor-neutral solution). > >> > > > >> > > "Single" might be making the problem impossibly hard to solve well. > >> > > One-size-fits-all solutions have a tendency to fall short on meeting > >> > > someone's critical requirement. I will agree that "less than n", > >> > > for some small n, is certainly desirable. > >> > > > >> > > The memory allocators and managers are ideally satisfying the > >> > > requirements imposed by device hardware, what userspace applications > >> > > are expected to do with the buffers, and system performance. (And > >> > > maybe the platform architecture, I/O bus, and dedicated video > >> > > memory?) > >> > > >> > In the embedded world, a very common use case is to capture video data > >> > from an ISP (V4L2+MC), process it in a DSP (V4L2+M2M, tidspbridge, > >> > ...) and display it on the GPU (OpenGL/ES). We need to be able to > >> > share a data buffer between the ISP and the DSP, and another buffer > >> > between the DSP and the GPU. If processing is not required, sharing a > >> > data buffer between the ISP and the GPU is required. Achieving > >> > zero-copy requires a single memory management solution used by the > >> > ISP, the DSP and the GPU. > >> > >> Ah. I guess I misunderstood what was meant by "memory provider" to some > >> extent. > >> > >> So what I read is a common way of providing in kernel persistent buffers > >> (buffer objects? buffer entities?) for drivers and userspace > >> applications to pass around by reference (no copies). Userspace may or > >> may not want to see the contents of the buffer objects. > > > > Exactly. How that memory is allocated in irrelevant here, and we can have > > several different allocators as long as the buffer objects can be managed > > through a single API. That API will probably have to expose buffer > > properties related to allocation, in order for all components in the > > system to verify that the buffers are suitable for their needs, but the > > allocation process itself is irrelevant. > > > >> So I understand now why a single solution is desirable. > > Exactly, > > It is important to know that there are 3 topics of discussion which > all are a separate topic of its own: > > 1. The actual memory allocator > 2. In-kernel API > 3. Userland API I think there's an agreement on this. Memory allocation and memory management must be separated, in order to have a single buffer management API working with several different memory providers. Given the wild creativity of hardware engineers, it's pretty much guaranteed that we'll see even more exotic memory allocation requirements in the future :-) > Explained: > 1. This is how you acquire the actual physical or virtual memory, > defrag, swap, etc. This can be enhanced by CMA, hotswap, memory > regions or whatever and the main topic for a system wide memory > allocator does not deal much with how this is done. > 2. In-kernel API is important from a device driver point of view in > order to resolve buffers, pin memory when used(enable defrag when > unpinned) > 3. Userland API deals with alloc/free, import/export(IPC), security, > and set-domain capabilities among others and is meant to pass buffers > between processes in userland and enable no-copy data paths. > > We need to resolve 2. and 3. > > GEM/TTM is mentioned in this thread and there is an overlap of what is > happening within DRM/DRI/GEM/TTM/KMS and V4L2. The whole idea behind > DRM is to have one device driver for everything (well at least 2D/3D, > video codecs, display output/composition), while on a SoC all this is > on several drivers/IP's. A V4L2 device cannot resolve a GEM handle. > GEM only lives inside one DRM device (AFAIK). GEM is also mainly for > "dedicated memory-less" graphics cards while TTM mainly targets > advanced Graphics Card with dedicated memory. From a SoC point of view > DRM looks very "fluffy" and not quite slimmed for an embedded device, > and you cannot get GEM/TTM without bringing in all of DRM/DRI. KMS on > the other hand is very attractive as a framebuffer device replacer. It > is not an easy task to decide on a multimedia user interface for a SoC > vendor. > > Uniting the frameworks within the kernel will likely fail(too big of a > task) but a common system wide memory manager would for sure make life > easier enabling the possibility to pass buffers between drivers(and > user-land as well). In order for No-copy to work on a system level the > general multimedia infrastructure in User-land (i.e. > Gstreamer/X11/wayland/stagefright/flinge
Re: Yet another memory provider: can linaro organize a meeting?
Hi Alex, On Tuesday 15 March 2011 17:47:47 Alex Deucher wrote: [snip] > FWIW, I have yet to see any v4l developers ever email the dri mailing > list while discussing GEM, TTM, or the DRM, all the while conjecturing > on aspects of it they admit to not fully understanding. For future > reference, the address is: . We are > happy to answer questions. Please don't see any malice there. Even though the topic has been on our table for quite some time now, we're only starting to actively work on it. The first step is to gather our requirements (this will likely be done this week, during the V4L2 brainstorming meeting in Warsaw). We will then of course contact DRM/DRI developers. -- Regards, Laurent Pinchart ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH-Android] [android/external/elfcopy] Modified to eliminate build errors using GCC 4.5/4.6.
On Wednesday 16 March 2011, Sachin Kamat wrote: > --- a/elfcopy.c > +++ b/elfcopy.c > @@ -2456,7 +2456,6 @@ update_symbol_values(Elf *elf, GElf_Ehdr *ehdr, > out why and also figure out whether the zero > value should have > been adjusted, after all. > */ > -ASSERT(!(shdr_info[sym->st_shndx].shdr.sh_flags & > SHF_ALLOC)); > ASSERT(shdr_info[i].shdr.sh_type == SHT_SYMTAB); > } Like the -Werror changes that Alexander commented on, this change circumvents the error output, but does not address the underlying problem. If you remove an assertion, that at least needs a very good explanation why the assertion was incorrect in the first place. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH-Android] [android/external/elfcopy] Modified to eliminate build errors using GCC 4.5/4.6.
Hi Arnd, Alexander, Some of the work arounds are just make shift solutions so that those dependent on the build can carry on with their work. Meanwhile as you guys said, the underlying problem needs to be addressed and fixed. This might take a while. Regards Sachin On 16 March 2011 17:17, Arnd Bergmann wrote: > On Wednesday 16 March 2011, Sachin Kamat wrote: > > --- a/elfcopy.c > > +++ b/elfcopy.c > > @@ -2456,7 +2456,6 @@ update_symbol_values(Elf *elf, GElf_Ehdr *ehdr, > > out why and also figure out whether the zero > value should have > > been adjusted, after all. > > */ > > -ASSERT(!(shdr_info[sym->st_shndx].shdr.sh_flags > & SHF_ALLOC)); > > ASSERT(shdr_info[i].shdr.sh_type == SHT_SYMTAB); > > } > > Like the -Werror changes that Alexander commented on, this change > circumvents the error output, but does not address the underlying > problem. If you remove an assertion, that at least needs a very > good explanation why the assertion was incorrect in the first > place. > >Arnd > -- With warm regards, Sachin ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 3/5] arm/dt: mx51: dynamically add gpt and uart related clocks per dt nodes
On Tue, Mar 15, 2011 at 01:37:31AM -0600, Grant Likely wrote:
> On Tue, Mar 08, 2011 at 12:22:10AM +0800, Shawn Guo wrote:
> > This patch is to change the static clock creating and registering to
> > the dynamic way, which scans dt clock nodes, associate clk with
> > device_node, and then add them to clkdev accordingly.
> >
> > Signed-off-by: Shawn Guo
> > ---
> > arch/arm/mach-mx5/clock-mx51-mx53.c | 436
> > +--
> > 1 files changed, 422 insertions(+), 14 deletions(-)
> >
> > diff --git a/arch/arm/mach-mx5/clock-mx51-mx53.c
> > b/arch/arm/mach-mx5/clock-mx51-mx53.c
> > index dedb7f9..1940171 100644
> > --- a/arch/arm/mach-mx5/clock-mx51-mx53.c
> > +++ b/arch/arm/mach-mx5/clock-mx51-mx53.c
> > @@ -135,6 +135,9 @@ static inline u32 _get_mux(struct clk *parent, struct
> > clk *m0,
> >
> > static inline void __iomem *_mx51_get_pll_base(struct clk *pll)
> > {
> > +#ifdef CONFIG_OF
> > + return pll->pll_base;
> > +#else
> > if (pll == &pll1_main_clk)
> > return MX51_DPLL1_BASE;
> > else if (pll == &pll2_sw_clk)
> > @@ -145,6 +148,7 @@ static inline void __iomem *_mx51_get_pll_base(struct
> > clk *pll)
> > BUG();
> >
> > return NULL;
> > +#endif
> > }
> >
> > static inline void __iomem *_mx53_get_pll_base(struct clk *pll)
> > @@ -1439,33 +1443,437 @@ int __init mx53_clocks_init(unsigned long ckil,
> > unsigned long osc,
> > return 0;
> > }
> >
> > +/*
> > + * Dynamically create and register clks per dt nodes
> > + */
> > #ifdef CONFIG_OF
> > -static struct clk *mx5_dt_clk_get(struct device_node *np,
> > - const char *output_id, void *data)
> > +
> > +#define ALLOC_CLK_LOOKUP() \
> > + struct clk_lookup *cl; \
> > + struct clk *clk;\
> > + int ret;\
> > + \
> > + do {\
> > + cl = kzalloc(sizeof(*cl) + sizeof(*clk), GFP_KERNEL); \
> > + if (!cl)\
> > + return -ENOMEM; \
> > + clk = (struct clk *) (cl + 1); \
> > + \
> > + clk->parent = mx5_get_source_clk(node); \
> > + clk->secondary = mx5_get_source_clk(node); \
> > + } while (0)
> > +
> > +#define ADD_CLK_LOOKUP() \
> > + do {\
> > + node->data = clk; \
> > + cl->dev_id = of_get_property(node, \
> > + "clock-outputs", NULL); \
> > + cl->con_id = of_get_property(node, \
> > + "clock-alias", NULL); \
> > + if (!cl->dev_id && !cl->con_id) { \
> > + ret = -EINVAL; \
> > + goto out_kfree; \
> > + } \
> > + cl->clk = clk; \
> > + clkdev_add(cl); \
> > + \
> > + return 0; \
> > + \
> > + out_kfree: \
> > + kfree(cl); \
> > + return ret; \
> > + } while (0)
>
> Yikes! Doing this as a macro will be a nightmare for debugging.
> This needs refactoring into functions.
>
> > +
> > +static unsigned long get_fixed_clk_rate(struct clk *clk)
> > {
> > - return data;
> > + return clk->rate;
> > }
> >
> > -static __init void mx5_dt_scan_clks(void)
> > +static __init int mx5_scan_fixed_clks(void)
> > {
> > struct device_node *node;
> > + struct clk_lookup *cl;
> > struct clk *clk;
> > - const char *id;
> > - int rc;
> > + const __be32 *rate;
> > + int ret = 0;
> >
> > - for_each_compatible_node(node, NULL, "clock") {
> > - id = of_get_property(node, "clock-outputs", NULL);
> > - if (!id)
> > + for_each_compatible_node(node, NULL, "fixed-clock") {
> > + cl = kzalloc(sizeof(*cl) + sizeof(*clk), GFP_KERNEL);
> > + if (!cl) {
> > + ret = -ENOMEM;
> >
Re: [PATCH-Android] [android/external/elfcopy] Modified to eliminate build errors using GCC 4.5/4.6.
Ack, we discussed this today in android meeting and will take your patches to a special toolchain branch that allows us to experiement with 4.5/4.6 toolchain while not hiding the underlying problems. Thanks for your work! On Wed, Mar 16, 2011 at 1:01 PM, Sachin Kamat wrote: > Hi Arnd, Alexander, > > Some of the work arounds are just make shift solutions so that those > dependent on the build can carry on with their work. > Meanwhile as you guys said, the underlying problem needs to be addressed and > fixed. This might take a while. > > Regards > Sachin > > On 16 March 2011 17:17, Arnd Bergmann wrote: >> >> On Wednesday 16 March 2011, Sachin Kamat wrote: >> > --- a/elfcopy.c >> > +++ b/elfcopy.c >> > @@ -2456,7 +2456,6 @@ update_symbol_values(Elf *elf, GElf_Ehdr *ehdr, >> > out why and also figure out whether the zero >> > value should have >> > been adjusted, after all. >> > */ >> > - ASSERT(!(shdr_info[sym->st_shndx].shdr.sh_flags >> > & SHF_ALLOC)); >> > ASSERT(shdr_info[i].shdr.sh_type == >> > SHT_SYMTAB); >> > } >> >> Like the -Werror changes that Alexander commented on, this change >> circumvents the error output, but does not address the underlying >> problem. If you remove an assertion, that at least needs a very >> good explanation why the assertion was incorrect in the first >> place. >> >> Arnd > > > > -- > With warm regards, > Sachin > -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: linaro android build system issues
On Wed, 16 Mar 2011 11:43:57 +1300, Michael Hudson-Doyle wrote: > I've figured it out (jenkins was counting _all_ instances running in the > account it has the credentials for, not just those it launched, against > its instance cap) and have worked around it for now (raised the instance > cap) pending a better fix (using security groups to identify instances > jenkins has launched). So it is stateless here and doesn't just remember which instances it launched? Thanks, James ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH-Android] [android/external/elfcopy] Modified to eliminate build errors using GCC 4.5/4.6.
On 16/03/11 at 05:31pm, Sachin Kamat wrote: > Hi Arnd, Alexander, > > Some of the work arounds are just make shift solutions so that those > dependent on the build can carry on with their work. > Meanwhile as you guys said, the underlying problem needs to be addressed and > fixed. This might take a while. Maybe a comment just above each of these 'make shift solutions' will help you a) locate them later to fix up and b) give commentary on why you are temporarily doing them. > Regards > Sachin Regards, Jamie. > On 16 March 2011 17:17, Arnd Bergmann wrote: > > > On Wednesday 16 March 2011, Sachin Kamat wrote: > > > --- a/elfcopy.c > > > +++ b/elfcopy.c > > > @@ -2456,7 +2456,6 @@ update_symbol_values(Elf *elf, GElf_Ehdr *ehdr, > > > out why and also figure out whether the zero > > value should have > > > been adjusted, after all. > > > */ > > > -ASSERT(!(shdr_info[sym->st_shndx].shdr.sh_flags > > & SHF_ALLOC)); > > > ASSERT(shdr_info[i].shdr.sh_type == SHT_SYMTAB); > > > } > > > > Like the -Werror changes that Alexander commented on, this change > > circumvents the error output, but does not address the underlying > > problem. If you remove an assertion, that at least needs a very > > good explanation why the assertion was incorrect in the first > > place. > > > >Arnd > > > > > > -- > With warm regards, > Sachin > ___ > 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
Re: gcc: Thumb interworking and weakly linked functions
Aneesh V wrote on 03/16/2011 10:32:50 AM:
> Can you try this sequence:
>
> arm-linux-gnueabi-gcc -march=armv7-a -mthumb -mthumb-interwork -o foo1.o
> foo1.c -c
> arm-linux-gnueabi-gcc -march=armv7-a -mthumb -mthumb-interwork -o foo2.o
> foo2.S -c
> arm-linux-gnueabi-ld -r foo1.o foo2.o
> arm-linux-gnueabi-objdump -S a.out
>
> With this sequence I get the following output:
> 000c :
> c: b580 push {r7, lr}
> e: af00 add r7, sp, #0
>10: f7ff fffebl 18
>14: 4618 mov r0, r3
>16: bd80 pop {r7, pc}
>
> 0018 :
>18: e92d0080push {r7}
>1c: e28d7000add r7, sp, #0
>20: e1a0d007mov sp, r7
>24: e8bd0080pop {r7}
>28: e12fff1ebx lr
Well, sure, but the result of "ld -r" is not a final executable, but just
another relocatable object file. In particular, it will still carry
relocation records. In fact, if you add --reloc to the objdump line,
you should see:
000c :
c: b580push{r7, lr}
e: af00add r7, sp, #0
10: f7ff fffe bl 18
10: R_ARM_THM_CALL foo
14: 4618mov r0, r3
16: bd80pop {r7, pc}
The R_ARM_THM_CALL marks the branch instruction as still to be processed
by the final link step. And once you actually *perform* the final link,
e.g. via "gcc -o final a.out", the branch gets indeed converted to a blx
by the linker for me:
836c :
836c: b580push{r7, lr}
836e: af00add r7, sp, #0
8370: f000 e802 blx 8378
8374: 4618mov r0, r3
8376: bd80pop {r7, pc}
8378 :
8378: e92d0080push{r7}
837c: e28d7000add r7, sp, #0
8380: e1a0d007mov sp, r7
8384: e8bd0080pop {r7}
8388: e12fff1ebx lr
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
Re: No support of platform device instance id?
On Mon, Mar 14, 2011 at 03:10:19PM -0600, Grant Likely wrote: > [...] > Several weeks back I posted a patch for of_platform_bus_snoop() which > matches platform_device registrations to nodes in the device tree > instead of allocating and registering a new device. I've spent some > more time on that patch in the last couple of weeks to the point that > I'm happy with the model and I'm almost ready to push it out to my > devicetree/test branch. John Bonesio is currently refactoring and I have seen it on devicetree/test branch. > cleaning it up for me so that it can get posted. You can see the > current state in my devicetree/preregister branch, with tegra modified > to use it. > > The model is: > > 1) Platform code calls of_platform_device_preregister() to tell the DT >code about the nodes it /intends/ to register as devices. > 2) Platform code can register as many or as few platform_devices as it >likes. If any of these devices match one of the nodes passed by >of_platform_device_preregister(), then the DT code will set the >of_node pointer before it gets bound to a device. > 3) Platform code calls of_platform_device_probe() which will >register platform_devices for any nodes which *did not* get >assigned to a device in step 2. > > I implemented this as a way to allow dt and non-dt use-cases to share > the same SoC setup code so that anything on-chip would get registered > in the same way, but would also get the benefit of being linked to its > device tree node. For example, to obtain the list of i2c devices or > gpio connections from the tree. It also helps solve the problem of > matching nodes to clks which are currently matched by name. I think > it would also solve your use case, at least in the short term. > I'm seeing this approach benefits the smooth moving of dt on ARM, but will this be the ultimate shape of dt support on ARM? -- Regards, Shawn ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 3/5] arm/dt: mx51: dynamically add clocks per dt nodes
On Tue, Mar 15, 2011 at 01:48:08AM -0600, Grant Likely wrote: > On Mon, Mar 14, 2011 at 09:18:40PM +0800, Shawn Guo wrote: > > This patch is to change the static clock creating and registering to > > the dynamic way, which scans dt clock nodes, associate clk with > > device_node, and then add them to clkdev accordingly. > > > > It's a pretty straight translation from non-dt clock code to dt one, > > and it does not really change any actual clock code. > > > > Signed-off-by: Shawn Guo > > --- > > arch/arm/mach-mx5/clock-mx51-mx53.c | 1401 > > ++- > > 1 files changed, 1387 insertions(+), 14 deletions(-) > > > > diff --git a/arch/arm/mach-mx5/clock-mx51-mx53.c > > b/arch/arm/mach-mx5/clock-mx51-mx53.c > > index dedb7f9..c3ec7f6 100644 > > --- a/arch/arm/mach-mx5/clock-mx51-mx53.c > > +++ b/arch/arm/mach-mx5/clock-mx51-mx53.c > > @@ -49,6 +49,30 @@ static struct clk emi_fast_clk; > > static struct clk ipu_clk; > > static struct clk mipi_hsc1_clk; > > > > +#ifdef CONFIG_OF > > +/* > > + * The pointers are defined to save the references to the clocks > > + * dynamically created, and then could be used to replace those > > + * static references in non-dt clock code. > > + */ > > +static struct clk *osc_clk_dt; > > +static struct clk *pll1_main_clk_dt; > > +static struct clk *pll1_sw_clk_dt; > > +static struct clk *pll2_sw_clk_dt; > > +static struct clk *pll3_sw_clk_dt; > > +static struct clk *lp_apm_clk_dt; > > +static struct clk *periph_apm_clk_dt; > > +static struct clk *main_bus_clk_dt; > > +static struct clk *ipg_clk_dt; > > +static struct clk *ipg_per_clk_dt; > > +static struct clk *cpu_clk_dt; > > +static struct clk *iim_clk_dt; > > +static struct clk *usboh3_clk_dt; > > +static struct clk *usb_phy1_clk_dt; > > +static struct clk *esdhc1_clk_dt; > > +static struct clk *esdhc2_clk_dt; > > +#endif > > Heh, yeah this seems sub-optimal. It would be better to share common > clock initialization between dt and non-dt boards, even if it means > that a lot of the clocks are node described in the device tree (at > least for the on-chip SoC clocks; board-accessible clocks still need > to appear in the device tree though. > I do not understand the above comment. These are not statically defining 'struct clk' but the pointers to them. They are used to solve the references to static 'clk' in existing code, since all clk are created dynamically in dt code. -- Regards, Shawn ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 5/5] of/clock: eliminate function __of_clk_get_from_provider
On Tue, Mar 15, 2011 at 01:54:05AM -0600, Grant Likely wrote:
> On Mon, Mar 14, 2011 at 09:18:42PM +0800, Shawn Guo wrote:
> > With the platform clock support, the 'struct clk' should have been
> > associated with device_node->data. So the use of function
> > __of_clk_get_from_provider can be eliminated.
> >
> > Signed-off-by: Shawn Guo
> > ---
> > drivers/of/clock.c | 23 ++-
> > 1 files changed, 2 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/of/clock.c b/drivers/of/clock.c
> > index 7b5ea67..f124d0a 100644
> > --- a/drivers/of/clock.c
> > +++ b/drivers/of/clock.c
> > @@ -71,24 +71,6 @@ void of_clk_del_provider(struct device_node *np,
> > mutex_unlock(&of_clk_lock);
> > }
> >
> > -static struct clk *__of_clk_get_from_provider(struct device_node *np,
> > const char *clk_output)
> > -{
> > - struct of_clk_provider *provider;
> > - struct clk *clk = NULL;
> > -
> > - /* Check if we have such a provider in our array */
> > - mutex_lock(&of_clk_lock);
> > - list_for_each_entry(provider, &of_clk_providers, link) {
> > - if (provider->node == np)
> > - clk = provider->get(np, clk_output, provider->data);
> > - if (clk)
> > - break;
> > - }
> > - mutex_unlock(&of_clk_lock);
> > -
> > - return clk;
> > -}
> > -
> > struct clk *of_clk_get(struct device *dev, const char *id)
> > {
> > struct device_node *provnode;
> > @@ -123,9 +105,8 @@ struct clk *of_clk_get(struct device *dev, const char
> > *id)
> > __func__, prop_name, dev->of_node->full_name);
> > return NULL;
> > }
> > - clk = __of_clk_get_from_provider(provnode, prop);
> > - if (clk)
> > - dev_dbg(dev, "Using clock from %s\n", provnode->full_name);
> > +
> > + clk = provnode->data;
>
> Where is the device_node->data pointer getting set?
>
> In general the ->data pointer of struct device_node should be avoided.
> There are no strong rules about its usage which means there is a very
> real risk that another driver or subsystem will try to use it for a
> different purpose.
>
> Iterating over the whole device tree is safer, and it really isn't
> very expensive. If you really want to store the struct_clk pointer in
I do not understand how we can get the pointer to the 'struct clk'
from device tree. The clock code reads nodes from device tree and
creates 'struct clk' dynamically. If we do not save the pointer
somewhere, the pointer will get lost outside the clock code. How
can we possibly get it back from device tree later?
> the device node, then it would be better to add a struct clk * field
> to struct device_node.
>
--
Regards,
Shawn
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 5/7] mmc: support sdhci-esdhc-imx as an OF device
On Tue, Mar 15, 2011 at 01:59:26PM -0600, Grant Likely wrote: > On Mon, Mar 14, 2011 at 10:25:57PM +0800, Shawn Guo wrote: > > Signed-off-by: Shawn Guo > > dt support can be added directly to sdchi-pltfm.c drivers now. There > is no longer any need to use sdhci-of-core.c any more. For an > example, see the patch titled "of/tegra: add sdhci device tree > handling" in my devicetree/test branch. > I mentioned this a little bit in the cover letter of the patch set as below. "This patch set is to support sdhci-esdhc-imx as an OF device. As there is already powerpc based esdhc OF support, it chose to add OF support for imx esdhc driver in a different way from what sdhci-tegra did." The tegra approach you made was one of the two options I had, and I happened to love the another more, as it consolidates the eSDHC OF driver for Freescale MPCxxx and i.MX family. I can turn it around to your approach if you can convince me :) -- Regards, Shawn ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH V5 3/4] serial/imx: parse from device tree support
Signed-off-by: Jeremy Kerr
Signed-off-by: Jason Liu
---
.../bindings/tty/serial/fsl-imx-uart.txt | 19 +
drivers/tty/serial/imx.c | 78 +---
2 files changed, 87 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt
b/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt
new file mode 100644
index 000..b7ece32
--- /dev/null
+++ b/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt
@@ -0,0 +1,19 @@
+* UART (Universal Asynchronous Receiver/Transmitter)
+
+Required properties:
+- compatible : "fsl,imx51-uart".
+- reg : Offset and length of the register set for the device.
+- interrupts : should contain uart interrupt.
+- fsl,has-rts-cts : indicate it has rts-cts.
+- uart-clock : the uart clock input information.
+
+Example:
+
+imx-uart@bc000 {
+ compatible = "fsl,imx51-uart";
+ reg = <0xbc000 0x1000>;
+ interrupts = <0x1f>;
+ fsl,has-rts-cts;
+ uart-clock = <&uart0_clk>, "uart";
+};
+
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index dfcf4b1..568550d 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -47,6 +47,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -1224,6 +1226,53 @@ static int serial_imx_resume(struct platform_device *dev)
return 0;
}
+#ifdef CONFIG_OF
+static int serial_imx_probe_dt(struct imx_port *sport,
+ struct platform_device *pdev)
+{
+ struct device_node *node = pdev->dev.of_node;
+ static int line;
+
+ if (!node)
+ return -ENODEV;
+
+ if (of_get_property(node, "fsl,has-rts-cts", NULL))
+ sport->have_rtscts = 1;
+
+ if (of_get_property(node, "fsl,irda-mode", NULL))
+ sport->use_irda = 1;
+
+ sport->port.line = line++;
+
+ return 0;
+}
+#else
+static int serial_imx_probe_dt(struct imx_port *sport,
+ struct platform_device *pdev)
+{
+ return -ENODEV;
+}
+#endif
+
+static int serial_imx_probe_pdata(struct imx_port *sport,
+ struct platform_device *pdev)
+{
+ struct imxuart_platform_data *pdata = pdev->dev.platform_data;
+
+ if (!pdata)
+ return 0;
+
+ if (pdata->flags & IMXUART_HAVE_RTSCTS)
+ sport->have_rtscts = 1;
+
+#ifdef CONFIG_IRDA
+ if (pdata->flags & IMXUART_IRDA)
+ sport->use_irda = 1;
+#endif
+ sport->port.line = pdev->id;
+
+ return 0;
+}
static int serial_imx_probe(struct platform_device *pdev)
{
struct imx_port *sport;
@@ -1236,6 +1285,12 @@ static int serial_imx_probe(struct platform_device *pdev)
if (!sport)
return -ENOMEM;
+ ret = serial_imx_probe_dt(sport, pdev);
+ if (ret == -ENODEV)
+ ret = serial_imx_probe_pdata(sport, pdev);
+ if (ret)
+ goto free;
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
ret = -ENODEV;
@@ -1260,7 +1315,6 @@ static int serial_imx_probe(struct platform_device *pdev)
sport->port.fifosize = 32;
sport->port.ops = &imx_pops;
sport->port.flags = UPF_BOOT_AUTOCONF;
- sport->port.line = pdev->id;
init_timer(&sport->timer);
sport->timer.function = imx_timeout;
sport->timer.data = (unsigned long)sport;
@@ -1274,17 +1328,13 @@ static int serial_imx_probe(struct platform_device
*pdev)
sport->port.uartclk = clk_get_rate(sport->clk);
- imx_ports[pdev->id] = sport;
+ if (imx_ports[sport->port.line]) {
+ ret = -EBUSY;
+ goto clkput;
+ }
+ imx_ports[sport->port.line] = sport;
pdata = pdev->dev.platform_data;
- if (pdata && (pdata->flags & IMXUART_HAVE_RTSCTS))
- sport->have_rtscts = 1;
-
-#ifdef CONFIG_IRDA
- if (pdata && (pdata->flags & IMXUART_IRDA))
- sport->use_irda = 1;
-#endif
-
if (pdata && pdata->init) {
ret = pdata->init(pdev);
if (ret)
@@ -1336,6 +1386,11 @@ static int serial_imx_remove(struct platform_device
*pdev)
return 0;
}
+static struct of_device_id imx_uart_matches[] = {
+ { .compatible = "fsl,imx51-uart" },
+ {},
+};
+
static struct platform_driver serial_imx_driver = {
.probe = serial_imx_probe,
.remove = serial_imx_remove,
@@ -1345,6 +1400,9 @@ static struct platform_driver serial_imx_driver = {
.driver = {
.name = "imx-uart",
.owner = THIS_MODULE,
+#if defined(CONFIG_OF)
+ .of_match_table = imx_uart_matches,
+#endif
},
};
--
1.7.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH V5 0/4] Add MX51 basic DT support
From: Jason Liu This patchset adds Freescale i.mx51 device tree support. This is based on git://git.secretlab.ca/git/linux-2.6 devicetree/test This patch has been tested on MX51 babbage board and can boot up succesfully to linux console with DT enabled. Grant, I think it's almost ready for you to merge it. V5: - Add bidings for uart and fec - resolve s-o-b issue - move dt clock part to seperate file V4: - Add Linaro sign off and copyrightt V3: - prefix the property name with the vendor name as like: "fsl,has-rts-cts" and "fsl,irda-mode" - use the ttymxc0 as the console - add FEC support, nfs can be used now Jason Liu (4): arm/dt: add basic mx51 device tree support arm/dt: add very basic dts file for babbage board serial/imx: parse from device tree support net/fec: add device tree matching support .../devicetree/bindings/net/fsl-imx-fec.txt| 17 +++ .../bindings/tty/serial/fsl-imx-uart.txt | 19 +++ arch/arm/boot/dts/babbage.dts | 122 arch/arm/mach-mx5/Kconfig |8 ++ arch/arm/mach-mx5/Makefile |1 + arch/arm/mach-mx5/board-dt.c | 64 ++ arch/arm/mach-mx5/clock-dt.c | 52 + arch/arm/plat-mxc/include/mach/common.h|1 + drivers/net/fec.c | 17 +++ drivers/tty/serial/imx.c | 78 +++-- 10 files changed, 369 insertions(+), 10 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/fsl-imx-fec.txt create mode 100644 Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt create mode 100644 arch/arm/boot/dts/babbage.dts create mode 100644 arch/arm/mach-mx5/board-dt.c create mode 100644 arch/arm/mach-mx5/clock-dt.c ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH V5 2/4] arm/dt: add very basic dts file for babbage board
Singed-off-by: Rob Herring
Signed-off-by: Jason Liu
---
arch/arm/boot/dts/babbage.dts | 122 +
1 files changed, 122 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/babbage.dts b/arch/arm/boot/dts/babbage.dts
new file mode 100644
index 000..8f9b47c
--- /dev/null
+++ b/arch/arm/boot/dts/babbage.dts
@@ -0,0 +1,122 @@
+/*
+ * Copyright 2011 Linaro Ltd.
+ * Copyright 2011 Freescale Semiconductor, Inc.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+
+/ {
+ model = "Freescale i.MX51 Babbage";
+ compatible = "fsl,mx51-babbage";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&tzic>;
+
+ memory {
+ reg = <0x9000 0x2000>;
+ };
+
+ chosen {
+ bootargs = "console=ttymxc0,115200n8 debug earlyprintk ip=dhcp";
+ };
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ ranges;
+
+ tzic: tz-interrupt-controller {
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ reg = <0xe000 0x1000>;
+ compatible = "fsl,imx51-tzic";
+ };
+ };
+
+ clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ uart0_clk: uart0 {
+ compatible = "clock";
+ clock-outputs = "imx-uart.0";
+ };
+
+ uart1_clk: uart1 {
+ compatible = "clock";
+ clock-outputs = "imx-uart.1";
+ };
+
+ uart2_clk: uart2 {
+ compatible = "clock";
+ clock-outputs = "imx-uart.2";
+ };
+
+ fec_clk: fec {
+ compatible = "clock";
+ clock-outputs = "fec.0";
+ };
+ };
+
+ aips@73f0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ ranges = <0x0 0x73f0 0x10>;
+
+ imx-uart@bc000 {
+ compatible = "fsl,imx51-uart";
+ reg = <0xbc000 0x1000>;
+ interrupts = <0x1f>;
+ fsl,has-rts-cts;
+ uart-clock = <&uart0_clk>, "uart";
+ };
+
+ imx-uart@c {
+ compatible = "fsl,imx51-uart";
+ reg = <0xc 0x1000>;
+ interrupts = <0x20>;
+ fsl,has-rts-cts;
+ uart-clock = <&uart1_clk>, "uart";
+ };
+ };
+
+ spba@7000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ ranges = <0x0 0x7000 0x10>;
+
+ imx-uart@c000 {
+ compatible = "fsl,imx51-uart";
+ reg = <0xc000 0x1000>;
+ interrupts = <0x21>;
+ fsl,has-rts-cts;
+ uart-clock = <&uart2_clk>, "uart";
+ };
+ };
+
+ aips@83f0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ ranges = <0x0 0x83f0 0x10>;
+
+ fec@ec000 {
+ compatible = "fsl,imx51-fec";
+ reg = <0xec000 0x1000>;
+ interrupts = <0x57>;
+ fec_clk-clock = <&fec_clk>, "fec";
+ };
+ };
+};
--
1.7.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH V5 4/4] net/fec: add device tree matching support
Signed-off-by: Jason Liu
---
.../devicetree/bindings/net/fsl-imx-fec.txt| 17 +
drivers/net/fec.c | 17 +
2 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/fsl-imx-fec.txt
b/Documentation/devicetree/bindings/net/fsl-imx-fec.txt
new file mode 100644
index 000..cff97cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/fsl-imx-fec.txt
@@ -0,0 +1,17 @@
+* FEC (Fast Ethernet Controller)
+
+Required properties:
+- compatible : "fsl,imx51-fec".
+- reg : Offset and length of the register set for the device.
+- interrupts : should contain uart interrupt.
+- fec_clk-clock : the fec clock input information.
+
+Example:
+
+fec@ec000 {
+ compatible = "fsl,imx51-fec";
+ reg = <0xec000 0x1000>;
+ interrupts = <0x57>;
+ fec_clk-clock = <&fec_clk>, "fec";
+} ;
+
diff --git a/drivers/net/fec.c b/drivers/net/fec.c
index 2a71373..b6b7446 100644
--- a/drivers/net/fec.c
+++ b/drivers/net/fec.c
@@ -44,6 +44,8 @@
#include
#include
#include
+#include
+#include
#include
@@ -77,6 +79,13 @@ static struct platform_device_id fec_devtype[] = {
}
};
+#ifdef CONFIG_OF
+static const struct of_device_id fec_dt_ids[] = {
+ { .compatible = "fsl,imx51-fec", .data = &fec_devtype[0], },
+ {},
+};
+#endif
+
static unsigned char macaddr[ETH_ALEN];
module_param_array(macaddr, byte, NULL, 0);
MODULE_PARM_DESC(macaddr, "FEC Ethernet MAC address");
@@ -1366,6 +1375,11 @@ fec_probe(struct platform_device *pdev)
struct net_device *ndev;
int i, irq, ret = 0;
struct resource *r;
+ const struct of_device_id *of_id;
+
+ of_id = of_match_device(fec_dt_ids, &pdev->dev);
+ if (of_id)
+ pdev->id_entry = (struct platform_device_id *)of_id->data;
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!r)
@@ -1530,6 +1544,9 @@ static struct platform_driver fec_driver = {
#ifdef CONFIG_PM
.pm = &fec_pm_ops,
#endif
+#ifdef CONFIG_OF
+ .of_match_table = fec_dt_ids,
+#endif
},
.id_table = fec_devtype,
.probe = fec_probe,
--
1.7.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH V5 1/4] arm/dt: add basic mx51 device tree support
Signed-off-by: Jason Liu
---
arch/arm/mach-mx5/Kconfig |8
arch/arm/mach-mx5/Makefile |1 +
arch/arm/mach-mx5/board-dt.c| 64 +++
arch/arm/mach-mx5/clock-dt.c| 52 +
arch/arm/plat-mxc/include/mach/common.h |1 +
5 files changed, 126 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
index de4fa99..6438f87 100644
--- a/arch/arm/mach-mx5/Kconfig
+++ b/arch/arm/mach-mx5/Kconfig
@@ -47,6 +47,14 @@ config MACH_MX51_BABBAGE
u-boot. This includes specific configurations for the board and its
peripherals.
+config MACH_MX51_DT
+ bool "Generic MX51 board (FDT support)"
+ select USE_OF
+ select SOC_IMX51
+ help
+Support for generic Freescale i.MX51 boards using Flattened Device
+Tree.
+
config MACH_MX51_3DS
bool "Support MX51PDK (3DS)"
select SOC_IMX51
diff --git a/arch/arm/mach-mx5/Makefile b/arch/arm/mach-mx5/Makefile
index 0d43be9..bd4542d 100644
--- a/arch/arm/mach-mx5/Makefile
+++ b/arch/arm/mach-mx5/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_MACH_EUKREA_CPUIMX51SD) += board-cpuimx51sd.o
obj-$(CONFIG_MACH_EUKREA_MBIMXSD51_BASEBOARD) += eukrea_mbimxsd-baseboard.o
obj-$(CONFIG_MACH_MX51_EFIKAMX) += board-mx51_efikamx.o
obj-$(CONFIG_MACH_MX50_RDP) += board-mx50_rdp.o
+obj-$(CONFIG_MACH_MX51_DT) += board-dt.o clock-dt.o
diff --git a/arch/arm/mach-mx5/board-dt.c b/arch/arm/mach-mx5/board-dt.c
new file mode 100644
index 000..62ca693
--- /dev/null
+++ b/arch/arm/mach-mx5/board-dt.c
@@ -0,0 +1,64 @@
+/*
+ * Copyright 2011 Linaro Ltd.
+ * Copyright 2011 Freescale Semiconductor, Inc.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include "devices.h"
+
+static struct of_device_id mx51_dt_match_table[] __initdata = {
+ { .compatible = "simple-bus", },
+ {}
+};
+
+static void __init mx51_dt_board_init(void)
+{
+ of_platform_bus_probe(NULL, mx51_dt_match_table, NULL);
+}
+
+static void __init mx51_dt_timer_init(void)
+{
+ mx51_clocks_init(32768, 2400, 22579200, 0);
+ mx5_clk_dt_init();
+}
+
+static struct sys_timer mxc_timer = {
+ .init = mx51_dt_timer_init,
+};
+
+static const char *mx51_dt_board_compat[] = {
+ "fsl,mx51-babbage",
+ NULL
+};
+
+DT_MACHINE_START(MX51_DT, "Freescale MX51 (Flattened Device Tree)")
+ .map_io = mx51_map_io,
+ .init_irq = mx51_init_irq,
+ .init_machine = mx51_dt_board_init,
+ .dt_compat= mx51_dt_board_compat,
+ .timer= &mxc_timer,
+MACHINE_END
diff --git a/arch/arm/mach-mx5/clock-dt.c b/arch/arm/mach-mx5/clock-dt.c
new file mode 100644
index 000..9c04475
--- /dev/null
+++ b/arch/arm/mach-mx5/clock-dt.c
@@ -0,0 +1,52 @@
+
+/*
+ * Copyright 2011 Linaro Ltd.
+ * Jason Liu
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static struct clk *mx5_dt_clk_get(struct device_node *np,
+ const char *output_id, void *data)
+{
+ return data;
+}
+
+static __init void mx5_dt_scan_clks(void)
+{
+ struct device_node *node;
+ struct clk *clk;
+ const char *id;
+ int rc;
+
+ for_each_compatible_node(node, NULL, "clock") {
+ id = of_get_property(node, "clock-outputs", NULL);
+ if (!id)
+ continue;
+
+ clk = clk_get_sys(id, NULL);
+ if (IS_ERR(clk))
+ continue;
+
+ rc = of_clk_add_provider(node, mx5_dt_clk_get, clk);
+ if (rc)
+ pr_err("error adding fixed clk %s\n", node->name);
+ }
+}
+
+void __init mx5_clk_dt_init(void)
+{
+ mx5_dt_scan_clks();
+}
diff --git a/arch/arm/plat-mxc/include/mach/common.h
b/arch/arm/plat-mxc/include/mach/common.h
index aea2cd3..a28e84a 100644
--- a/arch/arm/plat-mxc/include/mach/common.h
+++ b/arch/arm/plat-mxc/include/mach/common.h
@@ -58,4 +58,5 @@ extern void mxc91231_arch_reset(int, const char *);
extern void mxc91231_prepare_idle(void);
extern void mx51_efikamx_reset(void);
extern int mx53_revision(void);
+extern void mx5_clk_dt_init(void);
#endif
--
1
a different fix for panda hang
Nicolas, Today hrw pointed out this patch. It seems to be the proper fix for the panda hang. http://marc.info/?l=linux-omap&m=130021624629574&w=2 John ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Yet another memory provider: can linaro organize a meeting?
Hi all, I should probably have mentioned earlier that I am planning a session for Linaro @ UDS for this in May. cheers, Jesse On Wed, Mar 16, 2011 at 1:49 AM, Laurent Pinchart < laurent.pinch...@ideasonboard.com> wrote: > On Tuesday 15 March 2011 17:07:10 Robert Fekete wrote: > > On 8 March 2011 20:23, Laurent Pinchart wrote: > > > On Tuesday 08 March 2011 20:12:45 Andy Walls wrote: > > >> On Tue, 2011-03-08 at 16:52 +0100, Laurent Pinchart wrote: > > >> > > >> [snip] > > >> > > >> > > > It really shouldn't be that hard to get everyone involved > together > > >> > > > and settle on a single solution (either based on an existing > > >> > > > proposal or create a 'the best of' vendor-neutral solution). > > >> > > > > >> > > "Single" might be making the problem impossibly hard to solve > well. > > >> > > One-size-fits-all solutions have a tendency to fall short on > meeting > > >> > > someone's critical requirement. I will agree that "less than n", > > >> > > for some small n, is certainly desirable. > > >> > > > > >> > > The memory allocators and managers are ideally satisfying the > > >> > > requirements imposed by device hardware, what userspace > applications > > >> > > are expected to do with the buffers, and system performance. (And > > >> > > maybe the platform architecture, I/O bus, and dedicated video > > >> > > memory?) > > >> > > > >> > In the embedded world, a very common use case is to capture video > data > > >> > from an ISP (V4L2+MC), process it in a DSP (V4L2+M2M, tidspbridge, > > >> > ...) and display it on the GPU (OpenGL/ES). We need to be able to > > >> > share a data buffer between the ISP and the DSP, and another buffer > > >> > between the DSP and the GPU. If processing is not required, sharing > a > > >> > data buffer between the ISP and the GPU is required. Achieving > > >> > zero-copy requires a single memory management solution used by the > > >> > ISP, the DSP and the GPU. > > >> > > >> Ah. I guess I misunderstood what was meant by "memory provider" to > some > > >> extent. > > >> > > >> So what I read is a common way of providing in kernel persistent > buffers > > >> (buffer objects? buffer entities?) for drivers and userspace > > >> applications to pass around by reference (no copies). Userspace may > or > > >> may not want to see the contents of the buffer objects. > > > > > > Exactly. How that memory is allocated in irrelevant here, and we can > have > > > several different allocators as long as the buffer objects can be > managed > > > through a single API. That API will probably have to expose buffer > > > properties related to allocation, in order for all components in the > > > system to verify that the buffers are suitable for their needs, but the > > > allocation process itself is irrelevant. > > > > > >> So I understand now why a single solution is desirable. > > > > Exactly, > > > > It is important to know that there are 3 topics of discussion which > > all are a separate topic of its own: > > > > 1. The actual memory allocator > > 2. In-kernel API > > 3. Userland API > > I think there's an agreement on this. Memory allocation and memory > management > must be separated, in order to have a single buffer management API working > with several different memory providers. Given the wild creativity of > hardware > engineers, it's pretty much guaranteed that we'll see even more exotic > memory > allocation requirements in the future :-) > > > Explained: > > 1. This is how you acquire the actual physical or virtual memory, > > defrag, swap, etc. This can be enhanced by CMA, hotswap, memory > > regions or whatever and the main topic for a system wide memory > > allocator does not deal much with how this is done. > > 2. In-kernel API is important from a device driver point of view in > > order to resolve buffers, pin memory when used(enable defrag when > > unpinned) > > 3. Userland API deals with alloc/free, import/export(IPC), security, > > and set-domain capabilities among others and is meant to pass buffers > > between processes in userland and enable no-copy data paths. > > > > We need to resolve 2. and 3. > > > > GEM/TTM is mentioned in this thread and there is an overlap of what is > > happening within DRM/DRI/GEM/TTM/KMS and V4L2. The whole idea behind > > DRM is to have one device driver for everything (well at least 2D/3D, > > video codecs, display output/composition), while on a SoC all this is > > on several drivers/IP's. A V4L2 device cannot resolve a GEM handle. > > GEM only lives inside one DRM device (AFAIK). GEM is also mainly for > > "dedicated memory-less" graphics cards while TTM mainly targets > > advanced Graphics Card with dedicated memory. From a SoC point of view > > DRM looks very "fluffy" and not quite slimmed for an embedded device, > > and you cannot get GEM/TTM without bringing in all of DRM/DRI. KMS on > > the other hand is very attractive as a framebuffer device replacer. It > > is not an easy task to decide on a multimedia user interface
Re: Yet another memory provider: can linaro organize a meeting?
Hi Alex, On Wednesday 16 March 2011 17:09:45 Alex Deucher wrote: > On Wed, Mar 16, 2011 at 3:37 AM, Li Li wrote: > > Sorry but I feel the discussion is a bit off the point. We're not > > going to compare the pros and cons of current code (GEM/TTM, HWMEM, > > UMP, CMA, VCM, CMEM, PMEM, etc.) > > > > The real problem is to find a suitable unified memory management > > module for various kinds of HW components (including CPU, VPU, GPU, > > camera, FB/OVL, etc.), especially for ARM based SOC. Some HW requires > > physical continuous big chunk of memory (e.g. some VPU & OVL); while > > others could live with DMA chain (e.g. some powerful GPU has built-in > > MMU). > > > > So, what's current situation? > > > > 1) As Hans mentioned, there're GEM & TTM in upstream kernel, under the > > DRM framework (w/ KMS, etc.). This works fine on conventional (mostly > > Xorg-based) Linux distribution. > > > > 2) But DRM (or GEM/TTM) is still too heavy and complex to some > > embedded OS, which only want a cheaper memory management module. So... > > > > 2.1) Google uses PMEM in Android - However PMEM was removed from > > upstream kernel for well-known reasons; > > > > 2.2) Qualcomm writes a hybrid KGSL based DRM+PMEM solution - However > > KGSL was shamed in dri-devel list because their close user space > > binary. > > > > 2.3) ARM starts UMP/MaliDRM for both of Android and X11/DRI2 - This > > makes things even more complicated. (Therefore I personally think this > > is actually a shame for ARM to create another private SW. As a leader > > of Linaro, ARM should think more and coordinate with partners better > > to come up a unified solution to make our life easier.) > > > > 2.4) Other companies also have their own private solutions because > > nobody can get a STANDARD interface from upstream, including Marvell, > > TI, Freescale. > > > > > > > > In general, it would be highly appreciated if Linaro guys could sit > > down together around a table, co-work with silicon vendors and > > upstream Linux kernel maintainers to make a unified (and cheaper than > > GEM/TTM/DRM) memory management module. This module should be reviewed > > carefully and strong enough to replace any other private memory > > manager mentioned above. It should replace PMEM for Android (with > > respect to Gralloc). And it could even be leveraged in DRM framework > > (as a primitive memory allocation provider under GEM). > > > > Anyway, such a module is necessary, because user space application > > cannot exchange enough information by a single virtual address (among > > different per-process virtual address space). Gstreamer, V4L and any > > other middleware could remain using a single virtual address in the > > same process. But a global handler/ID is also necessary for sharing > > buffers between processes. > > > > Furthermore, besides those well-known basic features, some advanced > > APIs should be provided for application to map the same physical > > memory region into another process, with 1) manageable fine > > CACHEable/BUFFERable attributes and cache flush mechanism (for > > performance); 2) lock/unlock synchronization; 3) swap/migration > > ability (optional in current stage, as those buffer are often expected > > to stay in RAM for better performance). > > > > Finally, and the most important, THIS MODULE SHOULD BE PUSHED TO > > UPSTREAM (sorry, please ignore all the nonsense I wrote above if we > > can achieve this) so that everyone treat it as a de facto well > > supported memory management module. Thus all companies could transit > > from current private design to this public one. And, let's cheer for > > the end of this damn chaos! > > FWIW, I don't know if a common memory management API is possible. On > the GPU side we tried, but there ended up being too many weird > hardware quirks from vendor to vendor (types of memory addressable, > strange tiling formats, etc.). You might be able to come up with some > kind of basic framework like TTM, but by the time you add the > necessary quirks for various hw, it may be bigger than you want. > That's why we have GEM and TTM and driver specific memory management > ioctls in the drm. I agree that we might not be able to use the same memory buffers for all devices, as they all have more or less complex requirements regarding the memory properties (type, alignment, ...). However, having a common API to pass buffers around between drivers and applications using a common ID would be highly interesting. I'm not sure how complex that would be, I might not have all the nasty small details in mind. -- Regards, Laurent Pinchart ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Yet another memory provider: can linaro organize a meeting?
Hi Alex, On Wednesday 16 March 2011 17:00:03 Alex Deucher wrote: > On Wed, Mar 16, 2011 at 4:52 AM, Laurent Pinchart wrote: > > On Tuesday 15 March 2011 17:47:47 Alex Deucher wrote: > > > > [snip] > > > >> FWIW, I have yet to see any v4l developers ever email the dri mailing > >> list while discussing GEM, TTM, or the DRM, all the while conjecturing > >> on aspects of it they admit to not fully understanding. For future > >> reference, the address is: . We are > >> happy to answer questions. > > > > Please don't see any malice there. Even though the topic has been on our > > table for quite some time now, we're only starting to actively work on > > it. The first step is to gather our requirements (this will likely be > > done this week, during the V4L2 brainstorming meeting in Warsaw). We > > will then of course contact DRM/DRI developers. > > Sorry, it came out a little harsher than I wanted. I just want to > avoid duplication of effort if possible. No worries. I share you concerns about this. As long as everyone remains polite I have absolutely no issue with critics :-) -- Regards, Laurent Pinchart ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Yet another memory provider: can linaro organize a meeting?
On Wed, Mar 16, 2011 at 4:52 AM, Laurent Pinchart wrote: > Hi Alex, > > On Tuesday 15 March 2011 17:47:47 Alex Deucher wrote: > > [snip] > >> FWIW, I have yet to see any v4l developers ever email the dri mailing >> list while discussing GEM, TTM, or the DRM, all the while conjecturing >> on aspects of it they admit to not fully understanding. For future >> reference, the address is: . We are >> happy to answer questions. > > Please don't see any malice there. Even though the topic has been on our table > for quite some time now, we're only starting to actively work on it. The first > step is to gather our requirements (this will likely be done this week, during > the V4L2 brainstorming meeting in Warsaw). We will then of course contact > DRM/DRI developers. Sorry, it came out a little harsher than I wanted. I just want to avoid duplication of effort if possible. Alex ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Yet another memory provider: can linaro organize a meeting?
On Wed, Mar 16, 2011 at 3:37 AM, Li Li wrote: > Sorry but I feel the discussion is a bit off the point. We're not > going to compare the pros and cons of current code (GEM/TTM, HWMEM, > UMP, CMA, VCM, CMEM, PMEM, etc.) > > The real problem is to find a suitable unified memory management > module for various kinds of HW components (including CPU, VPU, GPU, > camera, FB/OVL, etc.), especially for ARM based SOC. Some HW requires > physical continuous big chunk of memory (e.g. some VPU & OVL); while > others could live with DMA chain (e.g. some powerful GPU has built-in > MMU). > > So, what's current situation? > > 1) As Hans mentioned, there're GEM & TTM in upstream kernel, under the > DRM framework (w/ KMS, etc.). This works fine on conventional (mostly > Xorg-based) Linux distribution. > > 2) But DRM (or GEM/TTM) is still too heavy and complex to some > embedded OS, which only want a cheaper memory management module. So... > > 2.1) Google uses PMEM in Android - However PMEM was removed from > upstream kernel for well-known reasons; > > 2.2) Qualcomm writes a hybrid KGSL based DRM+PMEM solution - However > KGSL was shamed in dri-devel list because their close user space > binary. > > 2.3) ARM starts UMP/MaliDRM for both of Android and X11/DRI2 - This > makes things even more complicated. (Therefore I personally think this > is actually a shame for ARM to create another private SW. As a leader > of Linaro, ARM should think more and coordinate with partners better > to come up a unified solution to make our life easier.) > > 2.4) Other companies also have their own private solutions because > nobody can get a STANDARD interface from upstream, including Marvell, > TI, Freescale. > > > > In general, it would be highly appreciated if Linaro guys could sit > down together around a table, co-work with silicon vendors and > upstream Linux kernel maintainers to make a unified (and cheaper than > GEM/TTM/DRM) memory management module. This module should be reviewed > carefully and strong enough to replace any other private memory > manager mentioned above. It should replace PMEM for Android (with > respect to Gralloc). And it could even be leveraged in DRM framework > (as a primitive memory allocation provider under GEM). > > Anyway, such a module is necessary, because user space application > cannot exchange enough information by a single virtual address (among > different per-process virtual address space). Gstreamer, V4L and any > other middleware could remain using a single virtual address in the > same process. But a global handler/ID is also necessary for sharing > buffers between processes. > > Furthermore, besides those well-known basic features, some advanced > APIs should be provided for application to map the same physical > memory region into another process, with 1) manageable fine > CACHEable/BUFFERable attributes and cache flush mechanism (for > performance); 2) lock/unlock synchronization; 3) swap/migration > ability (optional in current stage, as those buffer are often expected > to stay in RAM for better performance). > > Finally, and the most important, THIS MODULE SHOULD BE PUSHED TO > UPSTREAM (sorry, please ignore all the nonsense I wrote above if we > can achieve this) so that everyone treat it as a de facto well > supported memory management module. Thus all companies could transit > from current private design to this public one. And, let's cheer for > the end of this damn chaos! FWIW, I don't know if a common memory management API is possible. On the GPU side we tried, but there ended up being too many weird hardware quirks from vendor to vendor (types of memory addressable, strange tiling formats, etc.). You might be able to come up with some kind of basic framework like TTM, but by the time you add the necessary quirks for various hw, it may be bigger than you want. That's why we have GEM and TTM and driver specific memory management ioctls in the drm. Alex > > Thanks, > Lea > > On Wed, Mar 16, 2011 at 12:47 AM, Alex Deucher wrote: >> On Tue, Mar 15, 2011 at 12:07 PM, Robert Fekete >> wrote: >>> On 8 March 2011 20:23, Laurent Pinchart >>> wrote: Hi Andy, On Tuesday 08 March 2011 20:12:45 Andy Walls wrote: > On Tue, 2011-03-08 at 16:52 +0100, Laurent Pinchart wrote: > > [snip] > > > > > It really shouldn't be that hard to get everyone involved together > > > > and settle on a single solution (either based on an existing > > > > proposal or create a 'the best of' vendor-neutral solution). > > > > > > "Single" might be making the problem impossibly hard to solve well. > > > One-size-fits-all solutions have a tendency to fall short on meeting > > > someone's critical requirement. I will agree that "less than n", for > > > some small n, is certainly desirable. > > > > > > The memory allocators and managers are ideally satisfying the > > > requirements imposed by device hardware, what userspace applications >
Re: a different fix for panda hang
On Wed, 16 Mar 2011, John Rigby wrote: > Nicolas, > > Today hrw pointed out this patch. It seems to be the proper fix for > the panda hang. > > http://marc.info/?l=linux-omap&m=130021624629574&w=2 Good. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Yet another memory provider: can linaro organize a meeting?
On Wed, Mar 16, 2011 at 1:49 PM, Laurent Pinchart wrote: > Hi Alex, > > On Wednesday 16 March 2011 17:09:45 Alex Deucher wrote: >> On Wed, Mar 16, 2011 at 3:37 AM, Li Li wrote: >> > Sorry but I feel the discussion is a bit off the point. We're not >> > going to compare the pros and cons of current code (GEM/TTM, HWMEM, >> > UMP, CMA, VCM, CMEM, PMEM, etc.) >> > >> > The real problem is to find a suitable unified memory management >> > module for various kinds of HW components (including CPU, VPU, GPU, >> > camera, FB/OVL, etc.), especially for ARM based SOC. Some HW requires >> > physical continuous big chunk of memory (e.g. some VPU & OVL); while >> > others could live with DMA chain (e.g. some powerful GPU has built-in >> > MMU). >> > >> > So, what's current situation? >> > >> > 1) As Hans mentioned, there're GEM & TTM in upstream kernel, under the >> > DRM framework (w/ KMS, etc.). This works fine on conventional (mostly >> > Xorg-based) Linux distribution. >> > >> > 2) But DRM (or GEM/TTM) is still too heavy and complex to some >> > embedded OS, which only want a cheaper memory management module. So... >> > >> > 2.1) Google uses PMEM in Android - However PMEM was removed from >> > upstream kernel for well-known reasons; >> > >> > 2.2) Qualcomm writes a hybrid KGSL based DRM+PMEM solution - However >> > KGSL was shamed in dri-devel list because their close user space >> > binary. >> > >> > 2.3) ARM starts UMP/MaliDRM for both of Android and X11/DRI2 - This >> > makes things even more complicated. (Therefore I personally think this >> > is actually a shame for ARM to create another private SW. As a leader >> > of Linaro, ARM should think more and coordinate with partners better >> > to come up a unified solution to make our life easier.) >> > >> > 2.4) Other companies also have their own private solutions because >> > nobody can get a STANDARD interface from upstream, including Marvell, >> > TI, Freescale. >> > >> > >> > >> > In general, it would be highly appreciated if Linaro guys could sit >> > down together around a table, co-work with silicon vendors and >> > upstream Linux kernel maintainers to make a unified (and cheaper than >> > GEM/TTM/DRM) memory management module. This module should be reviewed >> > carefully and strong enough to replace any other private memory >> > manager mentioned above. It should replace PMEM for Android (with >> > respect to Gralloc). And it could even be leveraged in DRM framework >> > (as a primitive memory allocation provider under GEM). >> > >> > Anyway, such a module is necessary, because user space application >> > cannot exchange enough information by a single virtual address (among >> > different per-process virtual address space). Gstreamer, V4L and any >> > other middleware could remain using a single virtual address in the >> > same process. But a global handler/ID is also necessary for sharing >> > buffers between processes. >> > >> > Furthermore, besides those well-known basic features, some advanced >> > APIs should be provided for application to map the same physical >> > memory region into another process, with 1) manageable fine >> > CACHEable/BUFFERable attributes and cache flush mechanism (for >> > performance); 2) lock/unlock synchronization; 3) swap/migration >> > ability (optional in current stage, as those buffer are often expected >> > to stay in RAM for better performance). >> > >> > Finally, and the most important, THIS MODULE SHOULD BE PUSHED TO >> > UPSTREAM (sorry, please ignore all the nonsense I wrote above if we >> > can achieve this) so that everyone treat it as a de facto well >> > supported memory management module. Thus all companies could transit >> > from current private design to this public one. And, let's cheer for >> > the end of this damn chaos! >> >> FWIW, I don't know if a common memory management API is possible. On >> the GPU side we tried, but there ended up being too many weird >> hardware quirks from vendor to vendor (types of memory addressable, >> strange tiling formats, etc.). You might be able to come up with some >> kind of basic framework like TTM, but by the time you add the >> necessary quirks for various hw, it may be bigger than you want. >> That's why we have GEM and TTM and driver specific memory management >> ioctls in the drm. > > I agree that we might not be able to use the same memory buffers for all > devices, as they all have more or less complex requirements regarding the > memory properties (type, alignment, ...). However, having a common API to pass > buffers around between drivers and applications using a common ID would be > highly interesting. I'm not sure how complex that would be, I might not have > all the nasty small details in mind. On the userspace side, we pass buffers around using the DRI protocol. Buffers are passed as handles, and the protocol is generic, however all of the relevant clients are GPU specific at this point. That may change as we work on support for sharing buffers be
Re: linaro android build system issues
On Wed, 16 Mar 2011 09:14:31 -0400, James Westby wrote: > On Wed, 16 Mar 2011 11:43:57 +1300, Michael Hudson-Doyle > wrote: > > I've figured it out (jenkins was counting _all_ instances running in the > > account it has the credentials for, not just those it launched, against > > its instance cap) and have worked around it for now (raised the instance > > cap) pending a better fix (using security groups to identify instances > > jenkins has launched). > > So it is stateless here and doesn't just remember which instances it > launched? AIUI, it does remember, but according to the documentation, but applying the limit like this is a belt and suspenders thing in case Jenkins manages to lose this state. Cheers, mwh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: linaro android build system issues
On Thu, 17 Mar 2011 10:59:53 +1300, Michael Hudson-Doyle wrote: > AIUI, it does remember, but according to the documentation, but applying > the limit like this is a belt and suspenders thing in case Jenkins > manages to lose this state. Aha, thanks, that sounds somewhat sensible on its part anyway. Are you planning to work on the more complete fix yourself, or just report the bug and move on? Thanks, James ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: No support of platform device instance id?
[widening cc: list to solicit feedback on the new model] On Wed, Mar 16, 2011 at 09:58:01PM +0800, Shawn Guo wrote: > On Mon, Mar 14, 2011 at 03:10:19PM -0600, Grant Likely wrote: > > > [...] > > Several weeks back I posted a patch for of_platform_bus_snoop() which > > matches platform_device registrations to nodes in the device tree > > instead of allocating and registering a new device. I've spent some > > more time on that patch in the last couple of weeks to the point that > > I'm happy with the model and I'm almost ready to push it out to my > > devicetree/test branch. John Bonesio is currently refactoring and > > I have seen it on devicetree/test branch. Good. I don't know if you've seen it yet, but I also posted and pushed out an updated version last night that cleans up the usage model quite a bit. New code uses of_platform_prepare() for flagging nodes that will be registered later, and both of_platform_bus_probe() and of_platform_populate() will respect the discoveries made by of_platform_prepare(). > > cleaning it up for me so that it can get posted. You can see the > > current state in my devicetree/preregister branch, with tegra modified > > to use it. > > > > The model is: > > > > 1) Platform code calls of_platform_device_preregister() to tell the DT > >code about the nodes it /intends/ to register as devices. > > 2) Platform code can register as many or as few platform_devices as it > >likes. If any of these devices match one of the nodes passed by > >of_platform_device_preregister(), then the DT code will set the > >of_node pointer before it gets bound to a device. > > 3) Platform code calls of_platform_device_probe() which will > >register platform_devices for any nodes which *did not* get > >assigned to a device in step 2. > > > > I implemented this as a way to allow dt and non-dt use-cases to share > > the same SoC setup code so that anything on-chip would get registered > > in the same way, but would also get the benefit of being linked to its > > device tree node. For example, to obtain the list of i2c devices or > > gpio connections from the tree. It also helps solve the problem of > > matching nodes to clks which are currently matched by name. I think > > it would also solve your use case, at least in the short term. > > > I'm seeing this approach benefits the smooth moving of dt on ARM, but > will this be the ultimate shape of dt support on ARM? I've been spending a *lot* of time thinking about this (which is part of the reason why it's taken so long to get full dt support for ARM hammered out; decisions made now will be with us for a long time to come). On powerpc the design was easy because all of the BSPs were converted to require a device tree. Therefore it made complete sense to obtain all device information from the tree. On ARM however, SoC support code must handle both DT and non-DT use cases, which means that the internal SoC device layout is going to be encoded in the kernel regardless of whether or not it is available in the device tree. If we follow the lead of PowerPC here and obtain all device information from the DT, then it means DT and non-DT initialization uses entirely different code paths for the same SoC. Sure, the DT init code will a lot simpler that its non-DT counterpart, but is that really an advantage when the non-DT init code needs to be written regardless? Perhaps not. To answer your question, "will this be the ultimate shape of dt support on ARM?" I think that ultimately that decision needs to be made by each sub-arch maintainer. For existing SoCs, yes I think that this new model will be the right thing to do, with SoC internals registered statically, and board-level devices and clocks probed entirely from the device tree. I also expect that some maintainers will decide to go 100% device tree for their SoC. The Xilinx ARM FPGA is a likely candidate here. In that scenario, this new model wouldn't make much sense, and it would be better to follow the powerpc lead by registering everything directly from the DT. Either choice is valid. It is a tradeoff between sharing initialization code and the simplicity of full DT device registration. I'd like to have feedback on the new code to make sure that the model is sane. There are some fiddly code it there which is used to match platform_device registrations to nodes in the device tree. I *think* it makes sense, but I'd like to hear other opinions. g. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: how to sync with mainline
Sorry for not answering earlier. I was on vacation last week, and my email backlog is incredibly large. I'm going through it with generous usage of the delete key so it is possible that I might have missed something. On Fri, 11 Mar 2011, Barry Song wrote: > 2011/3/9 Lee Jones : > > On 09/03/11 02:44, Barry Song wrote: > >> 2011/3/8 Amit Kucheria : > >>> On Tue, Mar 8, 2011 at 10:34 AM, Barry Song <21cn...@gmail.com> wrote: > Hi Lee, > Great! Thanks a lot. It looks like the communication between linaro > and mainline is that linaro can backport some bug fixes and features > from mainline to linaro tree. Linaro doesn't help to review patches > and send to mainline. > >>> We prefer to see it this way: > >>> > >>> Develop against mainline and get those features integrated there. Keep > >>> linaro-dev in cc if these are features might be something Linaro would > >>> care about. > >>> > >>> The Linaro kernel (maintained by Nicolas Pitre and packaged by John > >>> Rigby) is a sort of technology demonstration to show what we achieve > >>> every 6 months. Some patches in it are backports, others are features > >>> that are still under review in mainline. But I doubt if Nicolas will > >>> take un-reviewed code directly into his tree. Exact. > Then I have two more questions > 1. is there a detailed list of backport and bug fix in linaro kernel > tree since those are the difference between mainline and linaro tree? > >>> 'git log' with the right incantations should be able to tell you that. > >>> Look up Nicolas' email announcements for the high-level overview of > >>> what he has integrated. The general policy for the Linaro kernel tree is described here: https://wiki.linaro.org/WorkingGroups/KernelConsolidation/KernelTree > 2. will linaro accept patches from non-member companies and help to > maintain, I mean a SoC company which doesn't join linaro? > >>> Linaro doesn't want to maintain dead code that isn't going upstream. > >>> It won't even do it for member companies. At most it is the incubator > >>> where the code lives and gets wider testing _while_ it is being > >>> reworked for mainline. > >> If patches are going mainline, but they are not from members TI, > >> Freescale, ST-E etc, can they be merged into linaro kernel? > > > > I don't see any reason why not, but the overall decision will be made by > > Nico. Yes they can, as long as there is some assurance that they are headed for mainline as well. But the Linaro kernel won't help maintain patches. Long term maintenance should be done in the upstream kernel. > That's important to market. In case customers of TI, Freescale, ST-E > are also using SoC from non-member companies, since they are using > linaro kernel and utilitis well on TI/Freescale/ST-E, > they want to use the same linaro kernel on non-member chips, if linaro > accepts and maintains non-member patches, then this tree can be useful > and customers can use the only tree as their platform to support both > member chips and non-member chips. Sure. > If so, maybe SoC companies don't need to join linaro, but they can get > the benefit of linaro too. So what's the opinion of Nico? You should realize that for your patches to be merged into the Linaro kernel, they must be in a similar state as if you were about to submit them upstream. Therefore you must have made the effort of making your code clean already. And once you're there, then you may just post them for upstream inclusion as well -- that's always our ultimate goal. The advantage of having those patches also merged into the Linaro kernel is all about early visibility and exposure. The latest developments from upstream and the Linaro members are put together, in a kernel that gets packaged and distributed along with user space components through the Linaro infrastructure, to test and demonstrate the technology being worked on without having to wait for the next upstream kernel release. Of course, if you are not a Linaro member, then you might have more difficulties keeping up to date with the work being done in the various groups as your platform won't be covered explicitly by those working groups, and it won't be supported in the Linaro release. But your patches would be accepted nevertheless, given that they also are on their way to be merged upstream. I hope this helps. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 00/12][RFC] Intial Kconfig Fragment Demo
On Fri, 11 Mar 2011, Amit Kucheria wrote: > On Fri, Mar 11, 2011 at 12:32 PM, Dave Martin wrote: > > On Wed, Mar 9, 2011 at 9:13 AM, Andy Green wrote: > >> On 03/09/2011 09:04 AM, Somebody in the thread at some point said: > >> > I take it this magic of SMP or not is hidden in this config layering > scheme > you mentioned and it isn't really using the same config for say igep0020 > and > >>> > >>> No, it is in the black depths of ARM assembly and TBH, it is voodoo to > >>> me. Nothing to do with kernel config as such. The SMP kernel, at > >>> runtime, (binary) patches itself to convert locking primitives to > >>> no-ops in the UP case. Or something to the effect. > >> > >> Hum my IGEP0020 config here has CONFIG_BROKEN_ON_SMP=y set so I guess this > >> is to do with what you mentioned. > >> > Panda. In any event, there's a performance tradeoff running SMP kernel > on > uniprocessor to consider too. > >>> > >>> Apparently, with this one-time patching (per boot) there isn't such a > >>> tradeoff. > >> > >> OK thanks for the explanation. > > > > SMP-on-UP appears to be fully working nowadays. We currently don't > > build a single SMP kernel for omap4 and omap3, but I've been playing > > with that and it's been shown to work. Does anyone know whether we're > > planning to move to a single OMAP kernel? Has anyone measured the > > performance delta? > > > > In principle, we could make this move; but there could be issues I'm > > not aware of. > > > > Note that the SMP-on-UP support is fairly minimal -- only those things > > which literally will fail on UP are patched out. > > Do you have a pointer to the patches that enabled this support? SHA > ids are fine. I'm curious what the runtime patching voodoo looks like. commit f00ec48fadf5e37e7889f14cff900aa70d18b644 ARM: Allow SMP kernels to boot on UP systems http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f00ec48fad We now have a similar clever trick for a runtime determined PHYS_OFFSET: commit f47ecb85ba9c67cf6f6eba39c19cc528f783f5e7 ARM: P2V: introduce phys_to_virt/virt_to_phys runtime patching http://ftp.arm.linux.org.uk/git/gitweb.cgi?p=linux-2.6-arm.git;a=commitdiff;h=f47ecb85ba This one has been drafted for human understanding here: https://wiki.ubuntu.com/Specs/ARMSingleKernel (the "Optimized virt_to_phys() with a runtime determined PHYS_OFFSET" section) Nicolas___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V4 1/5] arm/dt: add basic mx51 device tree support
On Tue, Mar 15, 2011 at 01:03:42AM -0600, Grant Likely wrote:
> Hi Jason,
>
> Minor comments below.
>
> On Thu, Mar 10, 2011 at 12:59:41PM +0800, Jason Liu wrote:
> > Signed-off-by: Jason Liu
> > Signed-off-by: Jason Liu
>
> This looks wrong. You should only have one s-o-b line. Use one email
> addr or the other. Not both.
>
> > ---
> > arch/arm/mach-mx5/Kconfig |8
> > arch/arm/mach-mx5/Makefile |1 +
> > arch/arm/mach-mx5/board-dt.c| 65
> > +++
> > arch/arm/mach-mx5/clock-mx51-mx53.c | 43 -
> > arch/arm/plat-mxc/include/mach/common.h |1 +
> > 5 files changed, 117 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
> > index de4fa99..6438f87 100644
> > --- a/arch/arm/mach-mx5/Kconfig
> > +++ b/arch/arm/mach-mx5/Kconfig
> > @@ -47,6 +47,14 @@ config MACH_MX51_BABBAGE
> > u-boot. This includes specific configurations for the board and its
> > peripherals.
> >
> > +config MACH_MX51_DT
> > + bool "Generic MX51 board (FDT support)"
> > + select USE_OF
> > + select SOC_IMX51
> > + help
> > +Support for generic Freescale i.MX51 boards using Flattened Device
> > +Tree.
> > +
> > config MACH_MX51_3DS
> > bool "Support MX51PDK (3DS)"
> > select SOC_IMX51
> > diff --git a/arch/arm/mach-mx5/Makefile b/arch/arm/mach-mx5/Makefile
> > index 0d43be9..540697e 100644
> > --- a/arch/arm/mach-mx5/Makefile
> > +++ b/arch/arm/mach-mx5/Makefile
> > @@ -18,3 +18,4 @@ obj-$(CONFIG_MACH_EUKREA_CPUIMX51SD) += board-cpuimx51sd.o
> > obj-$(CONFIG_MACH_EUKREA_MBIMXSD51_BASEBOARD) += eukrea_mbimxsd-baseboard.o
> > obj-$(CONFIG_MACH_MX51_EFIKAMX) += board-mx51_efikamx.o
> > obj-$(CONFIG_MACH_MX50_RDP) += board-mx50_rdp.o
> > +obj-$(CONFIG_MACH_MX51_DT) += board-dt.o
> > diff --git a/arch/arm/mach-mx5/board-dt.c b/arch/arm/mach-mx5/board-dt.c
> > new file mode 100644
> > index 000..19c60a4
> > --- /dev/null
> > +++ b/arch/arm/mach-mx5/board-dt.c
> > @@ -0,0 +1,65 @@
> > +/*
> > + * Copyright 2011 Linaro Ltd.
> > + * Copyright 2011 Freescale Semiconductor, Inc.
> > + *
> > + * The code contained herein is licensed under the GNU General Public
> > + * License. You may obtain a copy of the GNU General Public License
> > + * Version 2 or later at the following locations:
> > + *
> > + * http://www.opensource.org/licenses/gpl-license.html
> > + * http://www.gnu.org/copyleft/gpl.html
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "devices.h"
> > +
> > +static struct of_device_id mx51_dt_match_table[] __initdata = {
> > + { .compatible = "simple-bus", },
> > + {}
> > +};
> > +
> > +static void __init mx51_dt_board_init(void)
> > +{
> > + of_platform_bus_probe(NULL, mx51_dt_match_table, NULL);
> > +}
> > +
> > +static void __init mx51_dt_timer_init(void)
> > +{
> > + mx51_clocks_init(32768, 2400, 22579200, 0);
> > + mx5_clk_dt_init();
> > +}
> > +
> > +static struct sys_timer mxc_timer = {
> > + .init = mx51_dt_timer_init,
> > +};
> > +
> > +static const char *mx51_dt_board_compat[] = {
> > + "fsl,mx51-babbage",
> > + NULL
> > +};
> > +
> > +DT_MACHINE_START(MX51_DT, "Freescale MX51 (Flattened Device Tree)")
> > + .boot_params = PHYS_OFFSET + 0x100,
>
> You should be able to drop the .boot_params line.
>
> > + .map_io = mx51_map_io,
> > + .init_irq = mx51_init_irq,
> > + .init_machine = mx51_dt_board_init,
> > + .dt_compat= mx51_dt_board_compat,
> > + .timer= &mxc_timer,
> > +MACHINE_END
> > diff --git a/arch/arm/mach-mx5/clock-mx51-mx53.c
> > b/arch/arm/mach-mx5/clock-mx51-mx53.c
> > index 0a19e75..dedb7f9 100644
> > --- a/arch/arm/mach-mx5/clock-mx51-mx53.c
> > +++ b/arch/arm/mach-mx5/clock-mx51-mx53.c
> > @@ -15,13 +15,19 @@
> > #include
> > #include
> > #include
> > -
> > +#include
> > #include
> >
> > #include
> > #include
> > #include
> >
> > +#ifdef CONFIG_OF
> > +#include
> > +#include
> > +#include
> > +#endif /* CONFIG_OF */
>
> You can drop the #ifdef CONFIG_OF here. linux/of*.h is safe to
> include when CONFIG_OF is not selected.
>
> > +
> > #include "crm_regs.h"
> >
> > /* External clock values passed-in by the board code */
> > @@ -1432,3 +1438,38 @@ int __init mx53_clocks_init(unsigned long ckil,
> > unsigned long osc,
> > MX53_INT_GPT);
> > return 0;
> > }
> > +
> > +#ifdef CONFIG_OF
> > +static struct clk *mx5_dt_clk_get(struct device_node *np,
> > + const char *output_id, void *data)
> > +{
> > + return data;
> > +}
> > +
> > +static __init void mx5_dt_scan_clks(void)
> > +{
> > + struct device_node *node;
> > + struct clk *clk;
> > + const
Re: linaro android build system issues
On Wed, 16 Mar 2011 18:16:34 -0400, James Westby wrote: > On Thu, 17 Mar 2011 10:59:53 +1300, Michael Hudson-Doyle > wrote: > > AIUI, it does remember, but according to the documentation, but applying > > the limit like this is a belt and suspenders thing in case Jenkins > > manages to lose this state. > > Aha, thanks, that sounds somewhat sensible on its part anyway. > > Are you planning to work on the more complete fix yourself, or just > report the bug and move on? I did the first step yesterday: https://github.com/jenkinsci/ec2-plugin/pull/7 Whether I do the rest is up to you to some extent I guess :-) It's probably around a day's work. Cheers, mwh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: No support of platform device instance id?
On Wed, Mar 16, 2011 at 05:05:00PM -0600, Grant Likely wrote: > [...] > I'd like to have feedback on the new code to make sure that the model > is sane. There are some fiddly code it there which is used to match > platform_device registrations to nodes in the device tree. I *think* > it makes sense, but I'd like to hear other opinions. > Binding platform_device with of_node via resources matching seems a little fiddly, but your implementation looks solid to me. I made a quick scan on all the platform_device registration under arch/arm/plat-mxc/devices, nothing would be broken, only except platform-gpio_keys which is not an on-chip device. Looking at the code, I'm wondering how the binding of resource type IORESOURCE_DMA looks like. I'm seeing some platform_device is using this flag to tell dma channel fixed for the device. I'm not sure if it can be fit in property 'dma-ranges'. And I only see IORESOURCE_MEM and IORESOURCE_IRQ being used in the matching model. -- Regards, Shawn ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 4/7] mmc: consolidate sdhci_pltfm_data and sdhci_of_data into one
On Tue, Mar 15, 2011 at 01:55:13PM -0600, Grant Likely wrote: > On Mon, Mar 14, 2011 at 10:25:56PM +0800, Shawn Guo wrote: > > This patch is motivated by the work of supporting sdhci-esdhc-imx as > > an OF device. The sdhci-esdhc-imx driver was well designed to be > > able to work with either platform or OF bus, with a little effort to > > decouple the driver from sdhci_pltfm_data. > > > > Like sdhci_ops works for both platform and OF sdhci driver, the patch > > demonstrates that sdhci_pltfm_data and sdhci_of_data can be > > consolidated into sdhci_data, which should work for both. As one of > > the results, header linux/mmc/sdhci-pltfm.h can be deleted. > > > > Signed-off-by: Shawn Guo > > I like the push to unify DT and non-DT usage with the SDHCI drivers, > but I'm not convinced on the approach. Actually, that's more a > comment on the existing code than it is on the this patch. > Yes, this patch is not supposed to mean that much. It only intends to unify one data structure so that sdhci-esdhc-imx.c can work for both cases. The topic you raised here is a bigger one which may involve debate with authors of both sdhci-pltfm.c and sdhci-of-core.c. We can take it as the final goal, and this patch could be a first step to that goal. -- Regards, Shawn > I don't like the way that sdhci-pltfm.c and sdhci-of-core.c each take > responsibility for the .probe hook on each of the implementations. > Doing it that way means that each implementation needs to add a set of > hooks into those core files protected by #ifdefs based on whether or > not the driver is enabled. It also means that loading one driver > means that all the configured sdhci drivers get loaded into the > kernel. This seems backwards. > > From what I can see, sdhci-pltfm.c and sdhci-of-core.c both provide > useful common functions that would be used by all sdhci host drivers. > The interface would be a lot cleaner if those routines were exported > for use by other modules, and each driver registered its own probe > hook. It would keep all the driver specific stuff out of > sdhci_pltfm_ids and I think it would result in a cleaner interface > overall. > > Here is how I would do it: > > 1) break the bulk of the sdhci_pltfm.c and sdhci_of_core.c .probe and > .remove hooks out into separate functions; callable by other modules > 2) for each driver, add its own probe and remove hooks which calls > into the new functions created in step 1. This would eliminate the > need for the ->exit and ->init callbacks since they would get rolled > into the new .probe and .remove callbacks > 3) finally, when all drivers are removed; eliminate the driver > registration from sdhci_pltfm.c and sdhci_of_core.c because there > wouldn't be any users left. > > drivers/mmc/host/sdhci-pxa.c appears to be a good example of how I > think sdhci platform_drivers should be structured. > > At the same time, the functionality from sdhci_of_core.c could easily > be migrated into sdhci_pltfm.c. > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
