flo90 a écrit: +1 je vient juste de poser ma question sur xda en plus
!
Si jamais j'ai une réponse je post ici
flo90 a écrit: Voila je croit avoir eu la réponse! http://forum.xda-developers.com/archive/index.php/t-665110.html
Eh flo90 j'adore starbase MDR tiens c'est si dur que ca PTDR : http://lmgtfy.com/?q=xda+axi+scalling
Merci .
So I've been traipsing through some of the other Qualcomm repositories searching for tidbits that might be of use for N1 kernels. As far as I can tell, none of these changes have been merged in to the aosp or cyanogen kernels, although unfortunately the underlying kernels have diverged and these won't apply cleanly but it should be possible to manually merge with some effort.
First up, this patch reduces AXI (internal bus) speed when the apps CPU is running at lower clock speeds and increases it when at higher clock speeds. Memory would otherwise be the bottleneck for many applications.
https://www.codeaurora.org/gitweb/quic/chrome/?p=kernel.git;a=commit;h=6caa6d84d8c687b5f66f5b5ea 281183eae8947a8
msm: acpuclock-8x50: Couple CPU freq and AXI freq.
The memory throughput is directly proportional to the AXI frequency. The
AXI freq is coupled with the CPU freq to prevent the memory from being
the bottleneck when the CPU is running at one of its higher frequencies.
This will cause an increase in power consumption when the CPU is running
at higher frequencies, but will give a better performance/power ratio.
This patch adds core support for AXI clock changes.
https://www.codeaurora.org/gitweb/quic/chrome/?p=kernel.git;a=commit;h=009d997b1439edf1991e18120 6c74ee3e943787e
msm: clock: Add SoC/board independent APIs to set/get max AXI frequency.
Some drivers need to set the AXI frequency to the maximum frequency
supported by the board. Add a MSM_AXI_MAX_FREQ_KHZ magic value that
allows them to achieve that in a SoC/board independent manner.
The following two patches drop the AXI speed when the processor is idle but the screen is on, down to the minimum that will allow the framebuffer to keep driving the screen. Claims to save ~20 mA which would be somewhere around 10-20% at least. Unfortunately these will probably be harder to merge in, as the Chromium kernel uses quite a different mdp/framebuffer architecture. Still, worth trying!
https://www.codeaurora.org/gitweb/quic/chrome/?p=kernel.git;a=commit;h=fdb01a9945f2ac3a4cc76c507 ed0abf5dd5cfb57
msm_fb: Reduce AXI bus frequency to 62 Mhz from 128 Mhz
Reduced AXI bus frequency to 62 Mhx to save power during idle
screen mode/limited sleep mode.
https://www.codeaurora.org/gitweb/quic/chrome/?p=kernel.git;a=commit;h=dee586811e34cb24dedc1d058 7f3e31f1ba656a6
msm_fb: Reduce AXI bus frequency to 58 Mhz from 64 Mhz.
Reduce AXI bus frequency further to 58 Mhz for lcdc panels to save
~20mA power during idle screen mode/limited sleep mode.
traduction google arf c'est trop long a traduire lol :
Donc j'ai été traîne dans un des dépôts Qualcomm autres la recherche de petits morceaux qui pourraient être utiles pour les noyaux N1. Pour autant que je sache, aucune de ces modifications ont été fusionnées dans le PSBA ou noyaux de cyanogène, même si malheureusement, les noyaux sous-jacents ont divergé et celles-ci ne s'appliquent pas proprement, mais il devrait être possible de fusionner manuellement avec un certain effort.
Première place, ce correctif réduit AXI (bus interne) la vitesse lorsque le CPU est en cours d'exécution d'applications à des vitesses d'horloge inférieures et il augmente quand à des vitesses d'horloge plus élevées. Mémoire, autrement, serait le goulot d'étranglement pour de nombreuses applications.
https: / / www.codeaurora.org/gitweb/quic/chrome/?p=kernel.git; un engagement =; h = 6caa6d84d8c687b5f66f5b5ea 281183eae8947a8
MSM: acpuclock-8x50: Couple CPU freq et AXI freq.
Le débit de la mémoire est directement proportionnelle à la fréquence AXI. Le
AXI freq est couplé avec le processeur freq pour éviter d'être la mémoire
le goulot d'étranglement lorsque le CPU est en cours d'exécution à l'un de ses plus hautes fréquences.
Cela entraînera une augmentation de la consommation d'énergie lorsque le processeur est en cours d'exécution
à des fréquences plus élevées, mais donnera un meilleur rapport performance / puissance.
Ce patch ajoute le support de base pour les changements d'horloge AXI.
https: / / www.codeaurora.org/gitweb/quic/chrome/?p=kernel.git; un engagement =; h = 009d997b1439edf1991e18120 6c74ee3e943787e
MSM: l'horloge: Ajouter SoC / Conseil API indépendante pour définir et obtenir la fréquence max AXI.
Certains pilotes ont besoin de régler la fréquence AXI à la fréquence maximale
soutenu par le conseil d'administration. Ajouter une valeur magique qui MSM_AXI_MAX_FREQ_KHZ
leur permet d'atteindre que d'une manière SoC conseil / indépendant.
Les deux correctifs suivants baisse de la vitesse AXI lorsque le processeur est inactif, mais l'écran est activé, réduit au minimum qui permettra de garder le framebuffer de conduire l'écran. Revendications pour sauver ~ 20 mA qui serait autour de 10-20% au moins. Malheureusement, ces seront probablement plus difficiles à fusionner, comme le noyau de chrome utilise tout un mdp différents architecture framebuffer /. Pourtant, la peine d'essayer!
https: / / www.codeaurora.org/gitweb/quic/chrome/?p=kernel.git; un engagement =; h = fdb01a9945f2ac3a4cc76c507 ed0abf5dd5cfb57
msm_fb: Réduire la fréquence de bus à 62 Mhz AXI de 128 Mhz
Réduction de la fréquence de bus à 62 AXI Mhx pour économiser l'énergie en veille
mode d'écran / mode veille limitée.
https: / / www.codeaurora.org/gitweb/quic/chrome/?p=kernel.git; un engagement =; h = dee586811e34cb24dedc1d058 7f3e31f1ba656a6
msm_fb: Réduire la fréquence de bus à 58 Mhz AXI de 64 Mhz.
Réduire la fréquence de bus AXI à 58 Mhz pour les panneaux LLCM pour sauver
~ 20mA énergie en mode écran de veille / mode veille limitée.
