[Gta04-owner] Kernel 3.14-rc5 for GTA04

[Dr. H. Nikolaus Schaller]

Am 07.03.2014 um 20:14 schrieb Belisko Marek:

> On Fri, Mar 7, 2014 at 6:00 PM, Dr. H. Nikolaus Schaller
> <hns at goldelico.com> wrote:
>> 
>> Am 07.03.2014 um 17:41 schrieb mx4812 at arcor.de:
>> 
>>> 
>>> 
>>>>> Did you check if the delay loop is correctly calibrated?
>>>>> Somewhere the kernel says: "Calibrating delay loop" and prints out
>>>>> some value: lpj=11969856
>>>> 
>>>> here is the 3.14 kernel
>>>> [    0.001495] Calibrating delay loop... 594.73 BogoMIPS (lpj=2973696)
>>>> 
>>>> and here the 3.12 kernel
>>>> 
>>>> [    0.000274] Calibrating delay loop... 319.48 BogoMIPS (lpj=1597440)
>> 
>> And the SD card with the 3.12 kernel on the board where I did test the 3.14:
>> 
>> [    0.000305] Calibrating delay loop... 334.23 BogoMIPS (lpj=1671168)
>> 
>> So there is a small difference - as expected. But not the factor 2.
>> 
>>> 
>>> I remember from previous notebooks that I used that such timings also had the tendency
>>> to get messed up after resume events (slugishness and slooweerr soouunnd aaoouutpuut).
>> 
>> Interesting!
>> 
>> It may also explain why the OTG port is detecting a cable but not working. If some clock
>> is not initialized correctly it is simply not running the USB protocols correctly.
>> 
>> What makes me wonder a lot is why it is different at all.
>> 
>> It is the same hardware and the same message right at the beginning of a fresh boot (not
>> even a resume).
>> 
>> And I have not found a significant patch or diff to 3.12.7 - where it works.
>> 
>> The only difference is that we now boot with device tree and have no board file
>> (well, we use the board-generic.c instead of board-gta04.c).
> I don't think it's caused by bogomips. Booting with sme devicetree
> work fine on linux-next (without our
> changes).

Well, it may indeed not be the bogo mips but something in the device tree which
makes a clock difference. Maybe one of our patches conflicts with something fixed
differently in mainline linux-next.

So are you able to boot linux-next w/o our changes?

Then, we should be able to do sort of bisect/rebase/cherry-pick our patches and find
out which one breaks things. It may not work with standard git bisect.

BR,
Nikolaus