On Sep 11, 2007, at 12:03 PM, Scott Wood wrote:
> Kumar Gala wrote:
>> On Sep 11, 2007, at 11:24 AM, Scott Wood wrote:
>>> I propose we do it by defining the first (and ideally only, but
>>> that's another argument) entry in ranges as the immr, and getting
>>> rid of /soc/reg.
>> I disagree.
On Tue, 11 Sep 2007 12:03:31 -0500
Scott Wood <[EMAIL PROTECTED]> wrote:
>
> It'd probably be more efficient to discuss this in person; can you stop
> by my cube sometime when you're around and not in a meeting?
Please be sure to post a summary of the discussion if you do that so the
other people
Kumar Gala wrote:
> On Sep 11, 2007, at 11:24 AM, Scott Wood wrote:
>> I propose we do it by defining the first (and ideally only, but
>> that's another argument) entry in ranges as the immr, and getting
>> rid of /soc/reg.
>
> I disagree.
I'm shocked. :-)
> I don't think we want to start over
On Sep 11, 2007, at 11:24 AM, Scott Wood wrote:
> Kumar Gala wrote:
>> On Sep 11, 2007, at 10:51 AM, Scott Wood wrote:
>>> Any particular reason to special-case it, when we already need
>>> code to do it the other way for every other fsl soc?
>> If you suggest a sane way of getting the value le
Kumar Gala wrote:
> On Sep 11, 2007, at 10:51 AM, Scott Wood wrote:
>> Any particular reason to special-case it, when we already need code to
>> do it the other way for every other fsl soc?
>
> If you suggest a sane way of getting the value let me know. The mpc8xx
> doesn't appear to have what
On Sep 11, 2007, at 10:51 AM, Scott Wood wrote:
> Kumar Gala wrote:
>> Yep. However, after some discussion with Segher on this for 83xx/
>> 85xx/86xx I think we want to keep the reg prop and have it cover
>> the initial soc registers [size on 83xx is 0x100, size on 85xx/
>> 86xx would be 0x1
Kumar Gala wrote:
> Yep. However, after some discussion with Segher on this for
> 83xx/85xx/86xx I think we want to keep the reg prop and have it cover
> the initial soc registers [size on 83xx is 0x100, size on 85xx/86xx
> would be 0x1000].
>
> What we need is a saner way to determine immr on
On Sep 11, 2007, at 8:57 AM, Scott Wood wrote:
> On Tue, Sep 11, 2007 at 12:35:56AM -0500, Kumar Gala wrote:
>>
>> On Aug 28, 2007, at 3:16 PM, Scott Wood wrote:
>>
>>> 1. Fix get_immrbase() to use ranges, rather than reg.
>>>
>>> It is not always the case that the SoC's first reg property points
On Tue, Sep 11, 2007 at 12:35:56AM -0500, Kumar Gala wrote:
>
> On Aug 28, 2007, at 3:16 PM, Scott Wood wrote:
>
> >1. Fix get_immrbase() to use ranges, rather than reg.
> >
> >It is not always the case that the SoC's first reg property points
> >to the beginning of the entire SoC block.
>
> whe
On Aug 28, 2007, at 3:16 PM, Scott Wood wrote:
> 1. Fix get_immrbase() to use ranges, rather than reg.
>
> It is not always the case that the SoC's first reg property points
> to the beginning of the entire SoC block.
when is this true?
Upon further testing this breaks some platforms. I don't
Hrm.. in future could you add a separate 0/N for each of your series,
and make sure the In-Reply-To fields are right... as it is, my mailer
has threaded together these 4 or so patch series you posted into one
great wodge.
--
David Gibson| I'll have my music baroque, and my cod
1. Fix get_immrbase() to use ranges, rather than reg.
It is not always the case that the SoC's first reg property points
to the beginning of the entire SoC block.
2. Update the way get_brgfreq() finds things in the device tree.
It now uses names that are less namespace polluting. The old names
12 matches
Mail list logo
