All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: Peter Seebach <peter.seebach@windriver.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 0/1] Change default for cortexa* to armv7at-neon.
Date: Sat, 23 Aug 2014 00:26:42 +0200	[thread overview]
Message-ID: <20140822222642.GG20524@jama> (raw)
In-Reply-To: <20140822170626.13280b11@e6410-2>

[-- Attachment #1: Type: text/plain, Size: 2072 bytes --]

On Fri, Aug 22, 2014 at 05:06:26PM -0500, Peter Seebach wrote:
> On Fri, 22 Aug 2014 23:46:26 +0200
> Martin Jansa <martin.jansa@gmail.com> wrote:
> 
> > changing
> > default DEFAULTTUNE (and TUNE_PKGARCH with that) to have thumb while
> > still building with -marm doesn't make much sense to me and is only
> > confusing.
> 
> I think the distinction is that if you use armv7at-neon, you *can* build
> specific packages with thumb. Mostly, I guess, I don't think it makes sense
> to use a tuning that specifically states that it can't run thumb code for
> processors which can. Although... May not be an important distinction, really,
> as you note.

> I don't think it makes sense to use a tuning that specifically states
> that it can't run thumb code

The problem is that "t" in DEFAULTUNE always adds "t2" to TUNE_PKGARCH
no matter if you've built the package with -marm or -mthumb. So as long
as ARM_INSTRUCTION_SET is "arm" by default, we should use the same
default for DEFAULTTUNE - I wouldn't mind changing ARM_INSTRUCTION_SET
at least more people will be hit by those ICEs I've reported earlier
(with patch forcing ARM_INSTRUCTION_SET to "arm" for gdb and icu
"gdb: force arm mode" http://patchwork.openembedded.org/patch/75703/
"icu: force arm mode" http://patchwork.openembedded.org/patch/75817/

It would be interesting to try
http://patchwork.openembedded.org/patch/70985/
with latest master to see if it can work correctly now, then I wouldn't
be so opposed to "enabling" thumb in DEFAULTTUNE (even without
ARM_INSTRUCTION_SET change)

> > Every distro can use something more "optimized" DEFAULTTUNEs for each
> > MACHINE they use, I do it for SHR:
> > https://github.com/shr-distribution/meta-smartphone/blob/shr/meta-shr-distro/conf/distro/include/defaulttunes.inc
> 
> Huh, that's an interesting point. I'll wave this at people and see what they
> think of it.
> 
> -s
> -- 
> Listen, get this.  Nobody with a good compiler needs to be justified.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

  reply	other threads:[~2014-08-22 22:26 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-21 19:54 [PATCH 0/1] Change default for cortexa* to armv7at-neon Peter Seebach
2014-08-21 19:54 ` [PATCH 1/1] tune-cortexa*.inc: use armv7at by default Peter Seebach
2014-08-25  5:09   ` Khem Raj
2014-08-22 16:44 ` [PATCH 0/1] Change default for cortexa* to armv7at-neon Philip Balister
2014-08-22 18:33   ` Peter Seebach
2014-08-22 19:39     ` Martin Jansa
2014-08-22 20:49       ` Peter Seebach
2014-08-22 21:46         ` Martin Jansa
2014-08-22 22:06           ` Peter Seebach
2014-08-22 22:26             ` Martin Jansa [this message]
2014-08-25 19:12               ` Mark Hatle
2014-08-25 19:35                 ` Khem Raj
2014-08-25 19:40                   ` Mark Hatle
2014-08-25 20:40                   ` Martin Jansa
2014-08-28 12:51                 ` Philip Balister
2014-08-28 13:50                 ` Koen Kooi
2014-08-28 13:57                   ` Mark Hatle
2014-08-28 14:08                     ` Koen Kooi
2014-08-28 14:21                       ` Mark Hatle
2014-08-28 14:24                         ` Mark Hatle
2014-08-29  6:12                     ` Mike Looijmans
2014-08-29 12:16                       ` Koen Kooi
2014-08-29 12:57                       ` Mark Hatle
2014-08-24 23:51       ` Khem Raj
2014-08-24  7:56   ` Mike Looijmans
2014-08-24 14:44     ` Philip Balister
2014-08-24 18:15       ` Koen Kooi
2014-08-23 17:32 ` Koen Kooi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140822222642.GG20524@jama \
    --to=martin.jansa@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=peter.seebach@windriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.