Hi Simon,
On 08/01/12 09:39, Simon Glass wrote:
> Hi Gururaja,
>
> On Thu, Jan 5, 2012 at 11:25 PM, Hebbar, Gururaja
> wrote:
>> On Fri, Jan 06, 2012 at 12:05:40, Wolfgang Denk wrote:
>>> Dear "Hebbar, Gururaja",
>>>
>>
>> [snip]
>>
> _after_ the list has been created - If this breaks depend
Hi Gururaja,
On Thu, Jan 5, 2012 at 11:25 PM, Hebbar, Gururaja
wrote:
> On Fri, Jan 06, 2012 at 12:05:40, Wolfgang Denk wrote:
>> Dear "Hebbar, Gururaja",
>>
>
> [snip]
>
>> > > _after_ the list has been created - If this breaks dependencies that's
>> > > your problem ;). It is up to you as the '
Dear "Hebbar, Gururaja",
In message <1bafe6f6c881bf42822005164f1491c305c...@dbde01.ent.ti.com> you wrote:
>
> > Well I kind of like see that a particular init function is explicitly a
> > pre- or post- relocation function. But yes, having barrier pre-requisites
> > would achieve the same effect.
Dear Graeme Russ,
In message
you wrote:
>
> > Can we get rid of the 'f' parameter? If we invent a prerequisite
> > called 'relocated' or something like that, to act as a barrier, then
> > maybe the order can be defined just like any other function which
> > depends on being before or after some
Hi,
On Fri, Jan 06, 2012 at 10:29:48, Graeme Russ wrote:
> Hi Simon,
>
> On Fri, Jan 6, 2012 at 3:30 PM, Simon Glass wrote:
> > Hi Graham,
> >
> > On Thu, Jan 5, 2012 at 2:18 PM, Graeme Russ wrote:
> >> Hi Wolfgang,
> >>
> >> On Wed, Jan 4, 2012 at 1:44 AM, Wolfgang Denk wrote:
> >>> Dear Grae
Hi Simon,
On Fri, Jan 6, 2012 at 3:30 PM, Simon Glass wrote:
> Hi Graham,
>
> On Thu, Jan 5, 2012 at 2:18 PM, Graeme Russ wrote:
>> Hi Wolfgang,
>>
>> On Wed, Jan 4, 2012 at 1:44 AM, Wolfgang Denk wrote:
>>> Dear Graeme,
>>>
>>> In message <4f02da64.60...@gmail.com> you wrote:
>>
[snip]
Hi Graham,
On Thu, Jan 5, 2012 at 2:18 PM, Graeme Russ wrote:
> Hi Wolfgang,
>
> On Wed, Jan 4, 2012 at 1:44 AM, Wolfgang Denk wrote:
>> Dear Graeme,
>>
>> In message <4f02da64.60...@gmail.com> you wrote:
>>>
>
> [snip]
>
>>> INIT_FUNC(cpu_init_f, f, "fred", "blah", "foo");
>>>
>>> Generates the
Hi Wolfgang,
On Wed, Jan 4, 2012 at 1:44 AM, Wolfgang Denk wrote:
> Dear Graeme,
>
> In message <4f02da64.60...@gmail.com> you wrote:
>>
[snip]
>> INIT_FUNC(cpu_init_f, f, "fred", "blah", "foo");
>>
>> Generates the string:
>> f:cpu_init_f:"fred":"blah":"foo"
>>
>> and we can parse each of the
Hi Wolfgang,
On Tue, Jan 3, 2012 at 2:36 PM, Wolfgang Denk wrote:
> Dear Simon Glass,
>
> In message
> you
> wrote:
>>
>> I have been thinking if there is a way we can avoid the
>> post-processing perhaps by specifying two function parameters to the
>> macro (the init function to call and its
Dear Simon Glass,
In message
you wrote:
>
> I have been thinking if there is a way we can avoid the
> post-processing perhaps by specifying two function parameters to the
> macro (the init function to call and its prerequisite) and having the
> initcall code sort the list before starting. We co
Hi Wolfgang,
On Wed, Jan 4, 2012 at 1:44 AM, Wolfgang Denk wrote:
> Dear Graeme,
>
> In message <4f02da64.60...@gmail.com> you wrote:
>>
[snip]
> One thing comes to mind: it would be nice if we can find a way that
> the INIT_FUNC definitions behave similar to "weak" functions - if an
> init_fun
Hi Graham,
On Tue, Jan 3, 2012 at 2:37 AM, Graeme Russ wrote:
> Hi Wolfgang,
>
> On 03/01/12 01:49, Wolfgang Denk wrote:
>> Dear Graeme Russ,
>>
>> In message <4f019abb.9010...@gmail.com> you wrote:
>>>
>>> Which got me to thinking, what if we had an initcall macro which included
>>> the dependen
Dear Graeme,
In message <4f02da64.60...@gmail.com> you wrote:
>
> >> INITCALL(display_banner, "banner", "dram,board_early")
> >>
> >> Which says that the display_banner() function, when completed fulfils the
> >> 'banner' dependency, and requires both the 'dram' and 'board_early'
> >> dependencie
Hi Wolfgang,
On 03/01/12 01:49, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message <4f019abb.9010...@gmail.com> you wrote:
>>
>> Which got me to thinking, what if we had an initcall macro which included
>> the dependency information. Imagine this rough example:
> ...
>> INITCALL(display_bann
Dear Graeme Russ,
In message <4f019abb.9010...@gmail.com> you wrote:
>
> Which got me to thinking, what if we had an initcall macro which included
> the dependency information. Imagine this rough example:
...
> INITCALL(display_banner, "banner", "dram,board_early")
>
> Which says that the displa
Hi All,
I've been thinking about the renaissance of the arch-independent
initialisation sequence that has been generating a somewhat 'warm'
discussion lately and had a thought based on a comment passed on by
Wolfgang from Detlev:
"basicly what we are trying to solve is a dependency issue: each in
16 matches
Mail list logo
