public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 0/5] Create an API for safely accessing BMP header fields
Date: Tue, 5 Feb 2013 20:37:30 +0100	[thread overview]
Message-ID: <20130205203730.435fc4a8@lilith> (raw)
In-Reply-To: <20130205145852.GA19886@bill-the-cat>

Hi Tom,

On Tue, 5 Feb 2013 09:58:52 -0500, Tom Rini <trini@ti.com> wrote:

> On Mon, Feb 04, 2013 at 03:19:56PM +0100, Albert ARIBAUD wrote:
> > Hi Nikita,
> > 
> > On Mon, 04 Feb 2013 14:37:06 +0200, Nikita Kiryanov
> > <nikita@compulab.co.il> wrote:
> > 
> > > Hi Albert,
> > > 
> > > On 02/04/2013 01:57 PM, Albert ARIBAUD wrote:
> > > >
> > > > IIRC, you has submitted a fix so that BMP loads would result in
> > > > correctly aligned fields and thus no need for accessors. Why this
> > > > change of mind?
> > >  >
> > > 
> > > I did mention that I consider that fix as temporary. I believe this fix
> > > is better because it addresses the issue everywhere and does so in a
> > > more maintainable way (does not require the address fix to be duplicated
> > > everywhere there is a problem).
> > 
> > I actually like the new fix less, as it adds an API where there is no
> > need of one -- it's not like the implementation of BMP is at risk of
> > changing. What is the problem in fixing the load address at load time
> > and then passing this fixed address around?
> 
> OK, so I'm wondering.  Isn't this an example of where our idea that
> unaligned accesses are a software problem to fix, rather than an area to
> let the hardware fixup for us, when able, is wrong?
> 
> In other words, a real life example of why we should go with
> -munaligned-access being set for v7, set the HW bit and let things go?

I feel this is addressed to me. :)

And no, I don't think the BMP issue should be solved by relaxing HW
constraints. BMP is not a HW-enforced or protocol format.

Anyway, as I said, even if we really could not avoid misaligned
fields (and we know at least two ways we could), then the solution would
not be to flip a general HW switch controlling all accesses, since
only the BMP accesses are a problem! We could just make sure we access
the poorly aligned fields through dedicated unaligned accessors, e.g.
readl_u(&field) / writel_u(&field).

Amicalement,
-- 
Albert.

  reply	other threads:[~2013-02-05 19:37 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-04 11:39 [U-Boot] [PATCH 0/5] Create an API for safely accessing BMP header fields Nikita Kiryanov
2013-02-04 11:39 ` [U-Boot] [PATCH 1/5] Add bmp_layout module for accessing BMP header data Nikita Kiryanov
2013-02-04 19:26   ` Wolfgang Denk
2013-02-04 21:26     ` Albert ARIBAUD
2013-02-04 23:11       ` Wolfgang Denk
2013-02-05  8:07         ` Igor Grinberg
2013-02-05  9:57           ` Wolfgang Denk
2013-02-05 11:38             ` Igor Grinberg
2013-02-05 13:20               ` Wolfgang Denk
2013-02-05 14:49                 ` Igor Grinberg
2013-02-05 19:27                   ` Wolfgang Denk
2013-02-05  6:52     ` Nikita Kiryanov
2013-02-05  9:47       ` Wolfgang Denk
2013-02-04 11:39 ` [U-Boot] [PATCH 2/5] lcd: use bmp_layout API Nikita Kiryanov
2013-02-04 11:39 ` [U-Boot] [PATCH 3/5] cmd_bmp: " Nikita Kiryanov
2013-02-04 11:39 ` [U-Boot] [PATCH 4/5] video/cfb_console: " Nikita Kiryanov
2013-02-04 11:39 ` [U-Boot] [PATCH 5/5] video/bus_vcxk: " Nikita Kiryanov
2013-02-04 11:57 ` [U-Boot] [PATCH 0/5] Create an API for safely accessing BMP header fields Albert ARIBAUD
2013-02-04 12:37   ` Nikita Kiryanov
2013-02-04 14:19     ` Albert ARIBAUD
2013-02-04 15:07       ` Nikita Kiryanov
2013-02-04 15:25         ` Albert ARIBAUD
2013-02-04 20:48           ` Wolfgang Denk
2013-02-05  7:20           ` Nikita Kiryanov
2013-02-04 20:39       ` Wolfgang Denk
2013-02-05 14:58       ` Tom Rini
2013-02-05 19:37         ` Albert ARIBAUD [this message]
2013-02-04 20:35     ` Wolfgang Denk
2013-02-04 21:02       ` Jeroen Hofstee
2013-02-05  7:39         ` Igor Grinberg
2013-02-05  6:53 ` Igor Grinberg
2013-02-05  7:22   ` Nikita Kiryanov

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=20130205203730.435fc4a8@lilith \
    --to=albert.u.boot@aribaud.net \
    --cc=u-boot@lists.denx.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox