This series fixes a couple of problems with the ARM support in
libTBB; the build system did not detect ARM correctly and external
code that referenced TBB may have had problems building for Thumb
state.
These patches apply against tbb41_20130516oss, and have been
tested under Fedora 18 and Debian Wheezy (with `make test' and
`make examples').
Any comments/critique welcome, as I aim to send these patches
upstream.
Leif Lindholm (1):
ARM: Add IT instructions to inline assembler
Steve Capper (1):
ARM: Correct build architecture detection logic
build/linux.inc | 4 ++--
include/tbb/machine/gcc_armv7.h | 3 +++
2 files changed, 5 insertions(+), 2 deletions(-)
--
1.8.1.4
Hi Guys,
I really don't know whom to direct this mail to and hence the wide spread.
Problem: When we send a mail to kernel mailing lists with linaro-dev
or linaro-kernel
in cc, and we get replies to those mails, sometimes the mails from
outside people
doesn't reach us back on linaro mailing lists. And i hope the reason
behind that is
those people aren't subscribed to these lists.
For me it makes some sense to allow anyone to send mails to this list. Can that
request be considered?
I believe the idea behind blocking such use is for protecting against
spam mails, but
these mails/replies are really important and we certainly need them
delivered to us.
One solution (don't know if its possible) would be to monitor mails
from non-subscribers
and few people from Linaro can permit them on daily/hourly basis, so
that we don't get any
spam mails, but that would be a burden.
--
viresh
To address the case where physically contiguous memory MAY NOT be a mandatory
requirement for framebuffer for the application calling exynos_drm_gem_dumb_create,
the patch adds a feature to get non physically contiguous memory for framebuffer,
if physically contiguous memory allocation fails and if IOMMU is supported.
Signed-off-by: Vikas Sajjan <vikas.sajjan(a)linaro.org>
Signed-off-by: Arun Kumar <arun.kk(a)samsung.com>
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 2eabe1a..66d1b40 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -17,6 +17,7 @@
#include "exynos_drm_drv.h"
#include "exynos_drm_gem.h"
#include "exynos_drm_buf.h"
+#include "exynos_drm_iommu.h"
static unsigned int convert_to_vm_err_msg(int msg)
{
@@ -666,6 +667,18 @@ int exynos_drm_gem_dumb_create(struct drm_file *file_priv,
exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG |
EXYNOS_BO_WC, args->size);
+ /*
+ * If physically contiguous memory allocation fails and if IOMMU is
+ * supported then try to get buffer from non physically contiguous
+ * memory area.
+ */
+ if (IS_ERR(exynos_gem_obj) && is_drm_iommu_supported(dev)) {
+ dev_warn(dev->dev, "contiguous FB allocation failed, falling back to non-contiguous\n");
+ exynos_gem_obj = exynos_drm_gem_create(dev,
+ EXYNOS_BO_NONCONTIG | EXYNOS_BO_WC,
+ args->size);
+ }
+
if (IS_ERR(exynos_gem_obj))
return PTR_ERR(exynos_gem_obj);
--
1.7.9.5
> -----Original Message-----
> From: Wookey [mailto:wookey@wookware.org]
> Sent: Tuesday, August 20, 2013 0:31
> To: linaro-dev(a)lists.linaro.org; Embedded Debian
> Cc: Joey Ye
> Subject: Re: M0 and M3 patches in linaro toolchains
>
> +++ Matthew Gretton-Dann [2013-08-19 16:58 +0100]:
> > On 19 August 2013 15:04, Wookey <wookey(a)wookware.org> wrote:
> > > Debconf13 (last week) considered the matter of bare-metal
> > > cross-toolchains in Debian.
>
> > > The linaro embedded toolchains
> > > (https://launchpad.net/gcc-arm-embedded/4.7/4.7-2013-q1-update) are
> > > good, and work, both for M0 and M3. But building nominally the same
> > > thing from upstream gcc gets something where M3 works but M0 doesn't.
> >
> > OK - These aren't Linaro owned tools. They are produced by ARM. We
> > link to them to make sure people can find the tools they need.
>
> Aha. I had assumed it was something linaro was now doing. I'll see if I
can find
> some more details inside ARM then.
It is still a fully open source project though.
svn://gcc.gnu.org/branches/arm/embedded-4_8-branch/gcc/ChangeLog.arm listed
everything diff to FSF 4.8 branch.
>
> > Can you expand (possibly in a separate thread) on "M3 works but M0
> > doesn't"? I'd expect the gcc-arm-embedded tools to support all
> > M-profile cores out of the box.
>
> You misread (or I was unclear). The arm-provided toolchain referenced
> above does indeed work for M3 and M0. It's a toolchain built from debian
> sources that doesn't work for M0. Keithp did the tests and has the details
of
> exactly what he tested. (are we talking 4.7 or 4.8 (or
> both) here keith?)
I'm not sure what blocked M0. There are a few things suspicious:
* Which C library is used? The one gcc-arm-embedded works, and the only one
I know works for Cortex-M, is newlib. Other than that, good luck :-(
* What is the newlib version, if you are using newlib. There were some
patches for M0 when we enabled gcc-arm-embedded. But all of them are in
latest newlib mainline now.
Overall, sharing a source between arm-linux and arm-none-eabi sounds a good
idea, but library can be the road blocker. As bare-metal version should use
newlib and linux use glibc, it is not that straight-forward as assumed.
Please be aware of this extra burden.
Alternative approach is just grab the gcc-arm-embedded 4.8, which will be
ready by Q4, and build it for debian. It will be straight forward as it is
already built and released by launchpad as debian package and distributed as
PPA. Also it will behavior the same as any other gcc-arm-embedded running on
other linux distribution and Windows, which have been downloaded 100,000
copies.
I'm OK with both approaches but I believe the latter makes more sense.
>
> > > Also they are gcc 4.7 based whilst Debian is moving to a 4.8 default.
> >
> > If history is anything to go by there will be a 4.8 release of that
> > toolchain sometime in Q4 2013.
Yes, 4.8 will be release in Q4 this year. The arm/embedded-4_8-branch is now
under development and will be the release branch by then.
>
> OK, that will be useful but another big code dump with a huge diff is only
a
> partial solution. We really want to get to see which important bits are
actually
> missing in Debian.
As I mentioned in another email, everything is at
svn://gcc.gnu.org/branches/arm/embedded-4_x-branch/gcc/ChangeLog.arm given
that you got correct newlib. Major stuff to make it work is multilib
support, which is a piece of Makefile fragment to build library for
armv6-m/7-m/7-a/7-r.
>
> >
> > The Linaro branch for 4.8 is in the main SVN repository for GCC:
> > svn://gcc.gnu.org/branches/linaro/gcc-4_8-branch
>
> OK. And do you think that should support M0 and M3 correctly already?
> Do we expect M0/M3 support there to be good? Or should I ask Joey these
> questions?
Again, I'm not sure what blocked M0. I'm interested to know more details
about this.
>
> Debian is currently using 4.8.1 (with a pile of packaging patches and some
> backported fixes). So I guess the question really is whether that is
expected
> to work.
Should work with multilib Makefile fragment and correct newlib version
Regards,
Joey