From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: linux-sh@vger.kernel.org
Subject: Re: [PATCH 02/11] ARM: mach-shmobile: setup-r8a7740: add MERAM work-around
Date: Tue, 22 May 2012 10:07:57 +0000 [thread overview]
Message-ID: <2466037.rcNLRglKLo@avalon> (raw)
In-Reply-To: <87fwatar29.wl%kuninori.morimoto.gx@renesas.com>
Hi,
On Tuesday 22 May 2012 13:41:54 Paul Mundt wrote:
> On Mon, May 21, 2012 at 09:27:03PM -0700, Kuninori Morimoto wrote:
> > > If this exists within the MERAM register space, it should probably be
> > > handled in the MERAM driver itself. If this is all going to go to DT in
> > > the future it will be easy to to node to quirk matching then, but in the
> > > mean time we can match on CPU or machine types.
> >
> > It is difficult.
> > A1 MERAM datasheet doesn't have detail explain / register map.
>
> Yes, I'm familiar with the quality/reliability of our documentation.
>
> > It just say
> >
> > ------------------------------------------
> > Set the following register in the MERAM
> >
> > Register name: ICBR buffer control
> > Address: H?$B!GFE95 0098
> > Access size: 32 bits
> > Initial value: H?$B!G0160 0168
> > Setting value: H?$B!G0160 0164
> >
> > ------------------------------------------
> >
> > This work-around fixup MERAM memroy access erorr bug
> > (CEU/VIO6C/2D-DMAC/VCP1/VPU5F/JPU/DISP)
> > But we don't know what is these value.
>
> The problem with doing these sorts of setting outside of the context of
> the MERAM driver is that the MERAM driver could just turn around and undo
> the work by setting whatever bit this workaround is clearing.
>
> As long as this exists outside of the MERAM register map and we don't have
> to worry about the MERAM driver touching these values then having it as a
> board-specific thing is probably fine. If it falls within the MERAM mapping
> somewhere then the MERAM driver really should be dealing with it (or we can
> set it as a board-specific thing when the MERAM driver isn't being used),
> even if it is a magic value for the given CPU.
I agree. 0xFE950098 is outside of the MERAM registers address space (at least
in the SH7372 datasheet I have). I'm thus fine with setting the register in
board code.
> The main thing is avoiding subtle hard to debug problems where the board
> config workarounds are inadvertently trampled later on.
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2012-05-22 10:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-22 2:27 [PATCH 02/11] ARM: mach-shmobile: setup-r8a7740: add MERAM work-around Kuninori Morimoto
2012-05-22 2:56 ` Paul Mundt
2012-05-22 4:27 ` Kuninori Morimoto
2012-05-22 4:41 ` Paul Mundt
2012-05-22 8:04 ` kuninori.morimoto.gx
2012-05-22 10:07 ` Laurent Pinchart [this message]
2012-05-22 10:17 ` Paul Mundt
2012-05-23 0:23 ` Kuninori Morimoto
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=2466037.rcNLRglKLo@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=linux-sh@vger.kernel.org \
/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.