From: Anton Vorontsov <cbouatmailru@gmail.com>
To: LEROY Christophe <christophe.leroy@c-s.fr>
Cc: Grant Likely <grant.likely@secretlab.ca>,
David Brownell <dbrownell@users.sourceforge.net>,
spi-devel-general@lists.sourceforge.net,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Kumar Gala <galak@kernel.crashing.org>
Subject: Re: [PATCH] spi_mpc8xxx: issue with using definition of pram in Device Tree
Date: Fri, 24 Sep 2010 11:57:40 +0400 [thread overview]
Message-ID: <20100924075740.GA20599@oksana.dev.rtsoft.ru> (raw)
In-Reply-To: <4C9C513B.40501@c-s.fr>
Hello,
On Fri, Sep 24, 2010 at 09:20:27AM +0200, LEROY Christophe wrote:
> The issue is that cpm_muram_alloc_fixed() allocates memory from the
> general purpose muram area (from 0x0 to 0x1bff).
> Here we need to return a pointer to the parameter RAM, which is
> located somewhere starting at 0x1c00. It is not a dynamic allocation
> that is required here but only to point on the correct location in
> the parameter RAM.
>
> For the CPM2, I don't know. I'm working with a MPC866.
>
> Attached is a previous discussion on the subject where I explain a
> bit more in details the issue.
The patch looks OK, I think.
Doesn't explain why that worked on MPC8272 (CPM2) and MPC8560
(also CPM2) machines though. But here's my guess (I no longer
have these boards to test it):
On 8272 I used this node:
+ spi@4c0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,cpm2-spi", "fsl,spi";
+ reg = <0x11a80 0x40 0x89fc 0x2>;
On that SOC there are two muram data regions 0x0..0x2000 and
0x9000..0x9100. Note that we actually don't want "data" regions,
and the only reason why that worked is that sysdev/cpm_common.c
maps muram(0)..muram(max).
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
WARNING: multiple messages have this Message-ID (diff)
From: Anton Vorontsov <cbouatmailru@gmail.com>
To: LEROY Christophe <christophe.leroy@c-s.fr>
Cc: David Brownell <dbrownell@users.sourceforge.net>,
linux-kernel@vger.kernel.org,
spi-devel-general@lists.sourceforge.net,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] spi_mpc8xxx: issue with using definition of pram in Device Tree
Date: Fri, 24 Sep 2010 11:57:40 +0400 [thread overview]
Message-ID: <20100924075740.GA20599@oksana.dev.rtsoft.ru> (raw)
In-Reply-To: <4C9C513B.40501@c-s.fr>
Hello,
On Fri, Sep 24, 2010 at 09:20:27AM +0200, LEROY Christophe wrote:
> The issue is that cpm_muram_alloc_fixed() allocates memory from the
> general purpose muram area (from 0x0 to 0x1bff).
> Here we need to return a pointer to the parameter RAM, which is
> located somewhere starting at 0x1c00. It is not a dynamic allocation
> that is required here but only to point on the correct location in
> the parameter RAM.
>
> For the CPM2, I don't know. I'm working with a MPC866.
>
> Attached is a previous discussion on the subject where I explain a
> bit more in details the issue.
The patch looks OK, I think.
Doesn't explain why that worked on MPC8272 (CPM2) and MPC8560
(also CPM2) machines though. But here's my guess (I no longer
have these boards to test it):
On 8272 I used this node:
+ spi@4c0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,cpm2-spi", "fsl,spi";
+ reg = <0x11a80 0x40 0x89fc 0x2>;
On that SOC there are two muram data regions 0x0..0x2000 and
0x9000..0x9100. Note that we actually don't want "data" regions,
and the only reason why that worked is that sysdev/cpm_common.c
maps muram(0)..muram(max).
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
next prev parent reply other threads:[~2010-09-24 7:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-16 7:05 [PATCH] spi_mpc8xxx: issue with using definition of pram in Device Tree christophe leroy
2010-09-24 7:10 ` Grant Likely
2010-09-24 7:10 ` Grant Likely
2010-09-24 7:20 ` LEROY Christophe
2010-09-24 7:20 ` LEROY Christophe
2010-09-24 7:57 ` Anton Vorontsov [this message]
2010-09-24 7:57 ` Anton Vorontsov
2010-09-24 15:12 ` Scott Wood
2010-09-24 15:12 ` Scott Wood
2010-09-24 15:07 ` Scott Wood
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=20100924075740.GA20599@oksana.dev.rtsoft.ru \
--to=cbouatmailru@gmail.com \
--cc=christophe.leroy@c-s.fr \
--cc=dbrownell@users.sourceforge.net \
--cc=galak@kernel.crashing.org \
--cc=grant.likely@secretlab.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=spi-devel-general@lists.sourceforge.net \
/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.