[U-Boot] [PATCH] AT91 rework: pm9261, pm9263 and pm9g45

[U-Boot] [PATCH] AT91 rework: pm9261, pm9263 and pm9g45

[RONETIX - Asen Dimov]

Hello,

I got several instances of the patches, probably you got it too,
so I apology for the mess.

Here is the list of patches:

[PM9261]
http://patchwork.ozlabs.org/patch/99663/
http://patchwork.ozlabs.org/patch/99665/
http://patchwork.ozlabs.org/patch/99666/

[PM9263]
http://patchwork.ozlabs.org/patch/99662/
http://patchwork.ozlabs.org/patch/99668/

[PM9G45]
http://patchwork.ozlabs.org/patch/99664/
http://patchwork.ozlabs.org/patch/99667/

Regards,
Asen

[U-Boot] [PATCH] AT91 rework: pm9261, pm9263 and pm9g45

[Reinhard Meyer]

Dear Asen Dimov,
> Hello,
> 
> I got several instances of the patches, probably you got it too,
> so I apology for the mess.

Actually, I did get none per e-Mail, I see them in patchworks only.

> 
> Here is the list of patches:
> 
> [PM9261]
> http://patchwork.ozlabs.org/patch/99663/

The empty reset_timer() function added there can obviously only
solve build issues.
On any account reset_timer() must not be used anymore.
As such this patch must get a NAK.

> http://patchwork.ozlabs.org/patch/99665/
> http://patchwork.ozlabs.org/patch/99666/
> 
> [PM9263]
> http://patchwork.ozlabs.org/patch/99662/
> http://patchwork.ozlabs.org/patch/99668/
> 
> [PM9G45]
> http://patchwork.ozlabs.org/patch/99664/
> http://patchwork.ozlabs.org/patch/99667/

I will check on those 6 remaining patches now.

Best Regards,
Reinhard

[U-Boot] [PATCH] AT91 rework: pm9261, pm9263 and pm9g45

[Reinhard Meyer]

Am 09.06.2011 12:57, schrieb Reinhard Meyer:
> Dear Asen Dimov,
>> Hello,
>>
>> I got several instances of the patches, probably you got it too,
>> so I apology for the mess.
> 
> Actually, I did get none per e-Mail, I see them in patchworks only.
> 
>>
>> Here is the list of patches:
>>
>> [PM9261]
>> http://patchwork.ozlabs.org/patch/99663/
> 
> The empty reset_timer() function added there can obviously only
> solve build issues.
> On any account reset_timer() must not be used anymore.
> As such this patch must get a NAK.
> 
>> http://patchwork.ozlabs.org/patch/99665/
>> http://patchwork.ozlabs.org/patch/99666/
>>
>> [PM9263]
>> http://patchwork.ozlabs.org/patch/99662/
>> http://patchwork.ozlabs.org/patch/99668/
>>
>> [PM9G45]
>> http://patchwork.ozlabs.org/patch/99664/
>> http://patchwork.ozlabs.org/patch/99667/

Ah, and patches should be numbered 1/n .. n/n; 0/n is only
for a descriptive summary.

Best Regards,
Reinhard

[U-Boot] [PATCH] AT91 rework: pm9261, pm9263 and pm9g45

[RONETIX - Asen Dimov]

Hello Reinhard,

On 06/09/2011 01:57 PM, Reinhard Meyer wrote:
...
> Dear Asen Dimov,
> The empty reset_timer() function added there can obviously only
> solve build issues.
> On any account reset_timer() must not be used anymore.
> As such this patch must get a NAK.
>
The architectures, except AT91 are using reset_timer() to make epochs
(start from zero). I don't want to break the other architectures
and I need the CFI driver for pm92613 and pm9261. I can not think of
another idea, except an empty reset_timer(). Any suggestions, ideas?
...
> Best Regards,
> Reinhard
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
Regards,
Asen

[U-Boot] [PATCH] AT91 rework: pm9261, pm9263 and pm9g45

[RONETIX - Asen Dimov]

Hi Reinhard,

On 06/09/2011 02:00 PM, Reinhard Meyer wrote:
...
>>> http://patchwork.ozlabs.org/patch/99665/
>>> http://patchwork.ozlabs.org/patch/99666/
>>>
>>> [PM9263]
>>> http://patchwork.ozlabs.org/patch/99662/
>>> http://patchwork.ozlabs.org/patch/99668/
>>>
>>> [PM9G45]
>>> http://patchwork.ozlabs.org/patch/99664/
>>> http://patchwork.ozlabs.org/patch/99667/
> Ah, and patches should be numbered 1/n .. n/n; 0/n is only
> for a descriptive summary.
>
should I repost them numbering with 1/n?
> Best Regards,
> Reinhard
Regards,
Asen

[U-Boot] [PATCH] AT91 rework: pm9261, pm9263 and pm9g45

[Reinhard Meyer]

Dear Asen Dimov,
> Hello Reinhard,
> 
> On 06/09/2011 01:57 PM, Reinhard Meyer wrote:
> ...
>> Dear Asen Dimov,
>> The empty reset_timer() function added there can obviously only
>> solve build issues.
>> On any account reset_timer() must not be used anymore.
>> As such this patch must get a NAK.
>>
> The architectures, except AT91 are using reset_timer() to make epochs
> (start from zero). I don't want to break the other architectures
> and I need the CFI driver for pm92613 and pm9261. I can not think of
> another idea, except an empty reset_timer(). Any suggestions, ideas?

1. an empty reset_timer() will allow you to build, but at runtime it
must break.

2._if_ the current CFI driver is based on reset_timer()
that should actually be fixed there.
Whereby the actual impact on other architectures that have a broken
get_timer() implementation and therefore _require_ reset_timer() is
unclear to me. We just had a lengthy discussion about timer API etc.
In essence, this discussion, whatever exact API will be implemented,
resulted in NOT having any reset_timer() and only a monotonous,
millisecond returning get_timer() function.

The only _interim_ solution would be to reintroduce the original reset_timer()
to AT91, which I am NOT fond of.

Wolfgang?

Best Regards,
Reinhard

[U-Boot] [PATCH] AT91 rework: pm9261, pm9263 and pm9g45

[Reinhard Meyer]

Dear Asen Dimov,
> Hi Reinhard,
> 
> On 06/09/2011 02:00 PM, Reinhard Meyer wrote:
> ...
>>>> http://patchwork.ozlabs.org/patch/99665/
>>>> http://patchwork.ozlabs.org/patch/99666/
>>>>
>>>> [PM9263]
>>>> http://patchwork.ozlabs.org/patch/99662/
>>>> http://patchwork.ozlabs.org/patch/99668/
>>>>
>>>> [PM9G45]
>>>> http://patchwork.ozlabs.org/patch/99664/
>>>> http://patchwork.ozlabs.org/patch/99667/
>> Ah, and patches should be numbered 1/n .. n/n; 0/n is only
>> for a descriptive summary.
>>
> should I repost them numbering with 1/n?
After applying, the text within [] is gone anyway,
so it is ok for me.

Unless someone mandates otherwise...

Best Regards,
Reinhard