 Hello everybody, I must tell you that I am very pleased to be here today in front of you and also very glad that so many people are interested in power management, that's cool. So again my name is Patrick Titiano, I am a system power management expert. I spent the last nine years at TI doing power management stuff from architecture to system integration and system power management optimization. Aujourd'hui, après TI, j'ai décidé avec mes collègues de co-founder le belibre-compagnie, la consultancy et l'entraînement d'une compagnie spécialisée en technologie Linux Embedit. Parce que nous pensons qu'on peut partager tout le knowledge qu'on a de cette année à TI pour les autres gens et les autres marchés. Le topic d'aujourd'hui sera l'optimisation de power management d'identifier et de tracéir des indicators de power. C'est la discussion que je vous propose aujourd'hui. Et pour cela, je commencerai avec le problème. Qu'est-ce que c'est le problème exactement avec le power management ? Pourquoi est-ce que c'est important ? C'est important parce que les plateformes de wireless Embedit, leurs performances, ils augmentent beaucoup. Tous les ans, il y a un nouveau dispositif avec plus de CPUs, plus de MHz. Nous avons ouvert la barrière de 2 GHz. Il y a des accélérateurs de Hardware, des mémoires de high speed, des buses de high speed, etc. Donc, tout ça continue à augmenter. Mais en même temps, votre budget power et votre budget thermal pour votre produit final sont toujours les mêmes. Nous sommes toujours dans les zones de 5 watts de budget power pour la plateforme. La température du casque ne peut pas accéder à 45 degrés, sinon, ça va burner votre corps. Et encore, nous avons besoin d'avoir votre téléphone, au moins, pour un jour. Et aujourd'hui, nous savons comment est-ce que c'est difficile. Donc, en fin de compte, c'est que, nous avons plus et plus de pression sur le side power management pour faire cela. Donc, ici, nous allons décrire une méthodologie pour essayer de prendre soin de cela. Donc, j'ai proposé la prochaine menu pour vous, si vous voulez. En débutant, vous avez une description de ce que nous considérons être les key performance indicators, ou KPIs. Ensuite, nous allons décrire une méthodologie. Nous allons donner quelques exemples pratiques et des considérations thermologiques, parce que le thermo est aussi très connecté à le power management. Et enfin, quelques pensées et des recommandations. Donc, nous allons voir la première partie, la description de ce que nous considérons être les critiques KPIs. Donc, ce que nous appelons KPIs, ou Key Power Indicators, c'est des statistiques qui profitent les activités sur votre plateforme et qui sont relevantes au power management. Et donc, en other words, c'est de l'informe que vous pouvez extraire de la plateforme qui vous aidera à comprendre pourquoi votre consommation power est bonne ou faite, identifier des causes et fixer-la. Probablement les plus obvious, les clots et les ressources power. Donc, évidemment, la grande chose sur le power management, c'est que la première priorité c'est de l'utiliser ce qu'il faut pour faire ce scénario. Mais tout ce qui est extrait, ce qui n'est pas utilisé, et d'autres accélérateurs que vous n'avez pas besoin, il doit être off. Donc, la première chose à faire, c'est d'identifier toutes ces ressources power de clots, power switches et réguliers de voltage, GPS, etc. Vous le listez un par un et ensuite vous vérifiez ce qui est très important. Parce que c'est quelque part à la start de tout ce qu'on va définir. Tout ce qu'il faut pour tout le temps, toute la duration de l'utilisation, il y a des sortes de baselines et tout ce qu'il faut c'est construit au-delà de ce qu'il faut. Si vous avez le moins possible, c'est un grand gain. Puis, nous avons aussi monitoré les STATES ou les STATES idle les STATES idle c'est tout les STATES low power que la CPU peut mettre ce n'est pas seulement la CPU mais aussi les peripherals. Donc, c'est tendu par la fréquence de CPU idle automatiquement, je dirais, et c'est tout les STATES low power que la CPU peut mettre et il y a plusieurs, les plus simples qui n'est qu'un gain il y a un minimum de latency mais aussi un minimum de sauvage il n'y a presque aucun gain et ensuite, vous allez au maximum où vous mettez presque tout mais ensuite, vous avez une pénalité en termes de sleep and wake up latencies. Donc, vous devez utiliser les STATES exportés par la fréquence de CPU idle pour comprendre si votre CPU est en train d'exploiter la fréquence de CPU si vous allez dans les STATES low power et si vous restez assez longs dans ces STATES. Sur une chose similaire, les statistiques des points opératifs. Donc, on a déjà vu les STATES low power maintenant, quand la CPU fait des processions, il peut être de différents niveaux et donc, il y a maintenant des points opératifs et ici, encore, vous devez monitorer cela vous devez savoir combien de temps la CPU a été expérimentée dans chaque OPP et combien de transitions il y avait pour que vous le connaissiez si cela a été votre expectation ou pas. C'est aussi un bon indicateur quand vous avez des issues thermaux parce que si vous monitorz les statistiques et vous voyez que les hauts opératifs ne sont pas interdits, potentiellement il n'y a pas besoin de thermo management throttling qui prévient les hauts opératifs pour être interdits. En passant plus loin dans la partie dynamique du processus le load est aussi très important pour le monitor. Mais pas seulement la CPU, mais aussi tous les autres accélérateurs n'ont pas de processus typiquement sur la plateforme pour le monitor. Ce n'est pas toujours disponible quand il y a encore quelque chose besoin. Parce que c'est aussi expliqué par monitor le load et les procédures que vous pouvez identifier les procédures ou les services qui sont en train de générer beaucoup de procédures et donc de préventer la CPU pour dormir. Parce que pour le power management expert plus la CPU s'éteint, le meilleur c'est. C'est très utile parfois sur le UI, il y a des lags le frame rate n'est pas celui qu'on veut peut-être que c'est parce que la CPU est assez pro-sync dans quelque chose d'autre. La banque de mémoire est aussi un important item. On ne parle pas seulement de la load de la CPU, mais en fait la load de la mémoire est aussi très importante. Parce que parfois le bottleneck n'est pas la performance de la CPU, mais la performance de la mémoire. La CPU peut réunir à une très, très haute vitesse, mais la mémoire ne peut pas répondre si rapidement. Donc parfois, la CPU est juste malade pour la mémoire. Donc c'est important de vérifier que la load de la bus est pas trop high ou c'est comme prévu et que les latencies sont aussi faibles. Le next item to monitor c'est les interruptions de la CPU. Ça donne une bonne picture de les activités de perifer. Vous savez que ces interruptions sont toutes les événements de la synchronisation d'interruptions de la CPU d'une procédure régulière pour faire ces très courtes, mais toujours importantes activités. Dependant le nombre et le rate de interruptions, ça peut être un problème pour le management parce que si le rate est trop high votre CPU sera interruptée tout le temps et la police idol n'aura pas décidé d'aller dans un état pour assurer que la CPU va réunir immédiatement. Donc c'est très important de vérifier ça. Et c'est aussi important parce que potentiellement il y a un problème avec un driver perifer. Ce driver qui génère interruptions pour l'MPU et ça cause un performance et un power issue. En même page comme les interruptions, les timers de software sont aussi importants. Deux fois, ils continuent de réunir la CPU tout le temps, donc de préventer les états d'idle pour être interprétés. Le plus bas. C'est pourquoi vous avez probablement vu dans les kernels des tentatives de synchroniser les timers quand possible. C'est pour réduire le nombre de réunions et maximiser la température d'idle. Finalement, les dernières items que je vais vous décrire sont les températures. C'est quelque chose très important parce qu'actuellement la consommation pour le même travail explique avec la température. C'est exponentiel. Donc en faisant le même travail, on peut consommer deux ou quatre fois plus si c'est fait avec une haute température. Donc c'est très important de le garder bas tout le temps. Et c'est aussi une bonne explication quand vous mesurez la consommation c'est plus haut que c'est ce que vous avez estimé et peut-être c'est juste parce que la température. Le processus est bien, la configuration est bien, mais la température est plus haute. Ok, donc c'était une description de l'API, j'espère que vous n'avez pas perdu le temps. Maintenant je vais proposer une méthodologie pour faire une optimisation de l'uscase. Juste pour faire sure la définition de l'uscase est claire, ce que nous considérons l'uscase est tout l'interaction dans votre plateforme pour accomplir un goût. Bien, vous pensez que la optimisation commence avec les mesures mais en fait, non. Elle commence beaucoup plus tard que l'uscase de votre plateforme. Elle commence avec la définition de la plateforme. Parce que pour optimiser quelque chose, vous avez besoin d'un target. Il n'y a pas de point de optimiser et d'optimiser quand vous ne savez pas où commencer. Peut-être que vous êtes bon, donc vous avez besoin d'un target. Et pour avoir un target, vous avez besoin d'une estimation. Et ces estimations sont basées sur la modélisation de l'uscase. Donc quand vous définissez une nouvelle plateforme vous allez aussi créer un power model de cette plateforme et vous vous décriverez comment votre uscase est faite. Donc tout le processus qui est requisé, tout les nécessaires des blocs de hardware qui sont récris. Vous vous mettez dans votre power model et cela vous générera une estimation de ce que devrait être la consommation pour cette uscase. Et cela va devenir votre target power. Et plus tard, quand vous avez le software et le silicone vous allez prendre les mesures, le but sera d'acheter les targets. Donc, quand vous définissez votre target, vous devez mettre des choses en place pour les mesures et d'être sûrs de comparer les mesures aux targets. Donc je n'appelle pas l'instrumentation. Et ce n'est pas seulement sur l'instrumentation le software, mais c'est aussi sur l'instrumentation du hardware. Donc, vous avez évidemment tous les équipements de la lab pour prendre les mesures. Mais vous devez aussi être sûrs que quand la PCB de la plate-forme est designée, il y a des ressources de sens qui sont mises dans le right place pour prendre, en même temps, les mesures currentes et les mesures voltages. Vous avez le right des sensors de température dans les places correctes. Et ultimement, le state de l'art serait d'avoir des traces de hardware dans le silicone et des capacités d'imposées pour les mesures dans la compagnie pour la compagnie. Parce que, ce n'est pas le seul moyen d'arriver la route. Je vais discuter ceci un peu plus tard. La prochaine étape est d'automater. Vous avez mis tous les choses en place dans votre software, dans votre plate-forme pour faire les mesures et les indicators de track. Vous devez automater toutes ces choses. Parce que c'est vraiment un long, anoyant, approximé et source de tasks. Sans l'automation, vous ne pouvez pas comparer les appels avec les appels. La courante, la voltage et la puissance. Ce sont des paramètres analogues. Donc, si vous n'avez pas les mêmes mesures, ce ne sera pas exactement le même. Nous ne sommes pas dans le monde digital. Donc, ce qui signifie que pour prendre des mesures, ce n'est pas en fait un seul, mais c'est en faisant plusieurs fois d'arriver-le pour faire sure que c'est bon. Donc, je donnerai deux bonnes exemples, mais c'est en fait la réalité. Mesurer un bon temps avec un switch n'est pas bon. Ok? Il n'y a pas de précision, pas d'accuracy. Ce n'est pas bon et c'est bruyant. Le second exemple est de prendre plusieurs mesures d'autres routes pour différentes cases d'utilisation. Tout d'abord, vous faites les mesures sur votre équipement lab et vous vous rapporte par la main et vous vous rapportez les mesures. C'est juste un sens. Ok, donc nous sommes près de les mesures maintenant, mais pas encore. Vous avez enfin votre silicone? Et vous avez un software en train de rire. Le next step est de caractériser les performances de votre silicone. Ce qui signifie que il y a été des assumptions passées lors de la phase définition de la plateforme sur comment la silicone consomme quand c'est actif et maintenant vous devez faire sure que ces assumptions soient bonnes. Donc, en ce cas, vous allez faire de très bases softwares comme Drystone, GL Bench pour charger la GPU, faire les mesures de la consumption etc. Tout ça est pour faire sure que votre modèle est accurate. Donc, le next step est exactement d'asseter le modèle. Il n'y a pas peut-être trop bas ou peut-être trop bas. Si c'est trop bas, vous n'avez pas optimisé votre plateforme. C'est trop bas, c'est pas achievable et ce sera un temps de consommation et des ressources pour rien. Donc, dans ce step, vous devez converger avec ces caractéristiques de votre plateforme. Vous devez converger avec le modèle. Et donc, en fin, vous savez, vous avez un niveau de confiance dans vos targets. Oui. Oui. Donc, pour exemple, c'est le liquide du silicone. Donc, vous savez, le silicone n'est pas parfait et même si il n'y a rien à faire, il y aura des liquides passant par la pièce. Et donc, vous devez avoir une consommation. Donc, même quand c'est off, c'est consumable. Oui. Oui. Oui. Oui. Oui. Oui. mais vous ne devez pas, donc la performance du silicone est la même pour tout le logiciel du silicone. Donc, faire le truc sur le CPU est suffisant, donc c'est presque suffisant. Vous avez fait presque tout le travail. Oui, oui, oui, oui, c'est pas tout à fait sur l'usage, c'est juste pour assurer le modèle de pouvoir. Donc, généralement, les gens de hardware, ils sont revenus pour vous avec des caractéristiques de pouvoir du silicone. Ils vous disent que, ok, dans cet état, il consomme beaucoup de temps. Avec ce niveau de procédure et cette vitesse, il consomme beaucoup de pouvoir. Et ici, le travail est d'assurer que c'est correct. Ok? Merci, pas de problème. Et puis, finalement, vous avez fait ça. Vous pouvez commencer à faire des mesures de l'usage. Donc, ici, c'est très simple. C'est automatisé. Si vous avez fait le travail, c'est bien. Et donc, vous devez juste s'assurer que les mesures... Vous faites plusieurs mesures et vous vous assurez que c'est dans le même ballpark. Si il y a beaucoup de variations, de l'une à l'autre, il n'y a pas de problème sur le setup, ou sur la définition de l'usage. Parce que ce n'est pas reproduisable. Et n'oubliez pas de collecter toutes les statistiques que nous avons mentionnées avant, pour une prochaine analyse. Donc, 99% de la temps, quand vous faites les mesures, ce n'est pas aligné avec les targets dans la phase de développement. Donc, c'est le temps pour l'analysie. Donc, comme je l'ai dit, vous avez une partie statique appelée l'unité de la consommation et une partie dynamique. Vous devez commencer avec la partie statique. Parce que ce sera votre consommation basée. Et c'est la première à optimiser. Donc, cela inclut la voltage supply, la configuration IO, en s'assurant qu'il n'y ait pas de misconfiguration de IO, ou des outils nécessaires, etc. Toutes ces paramètres ici. Vous devez vérifier que c'est installé. Donc, quand la ligueur est sous contrôle, ensuite vous changez et changez pour l'extra-processing. Ou la performance de votre plateforme. Donc, ici on parle de la CPU, la GPU et tous les accélérateurs hardware qui génèrent des consommations basées sur le load de processus. Donc, ici, c'est pour s'assurer que les voltages supply sont les prévenus. Vous devez vérifier les timers, les interruptions, les durations de sleep, etc, etc. Et, à nouveau, vous devez vérifier que c'est aligné avec ce que l'on disait dans votre modèle de power et de power. N'oubliez pas de vérifier la consommation du bus et de la RAM. C'est un grand contributaire pour la consommation. Donc, vous devez vérifier que c'est aussi en range. La dernière étape, c'est de analyser la température. Comme je l'ai expliqué, c'est un item critique. Donc, vous devez vérifier que les températures sont en range. Et maintenant, c'est temps de fixer. Mais pas seulement le code, potentiellement, mais aussi le modèle de power. Dans toute cette analyse, vous devez trouver que votre description de l'utilisation n'était pas très précise, que ce n'est pas possible de générer exactement cette utilisation. Vous devez avoir des services basés qui n'étaient pas partie de l'estimation. Donc, cette étape, c'est un processus d'intervention entre vous, le software et l'ingénieur, l'architecte qui a designé la plateforme et qui a produisé les targets de power et les développeurs qui ont décidé de choisir qui l'est et qui l'est. Et aussi, n'oubliez pas de mettre un limiter acceptable. Ce n'est pas possible d'achever les targets de power parce que c'est le meilleur cas. Donc, vous devez définir un limiter, comme, si je suis en train d'acheter 5% sur le target, je suis prêt. Mais en fait, vous n'êtes pas prêt. Parce que vous ne devez pas laisser le power diverger de nouveau. Il y aura une longue perte de développement du produit. Il y aura un nouveau software et donc potentiellement un nouveau patch qui aura le power et le dégrader de nouveau. Donc, cela signifie que ces mesures doivent être prises de nouveau et de nouveau pour chaque nouvelle relance. Et vous devez être fort. C'était une grande et faible tâche dans mon travail précédemment. Power n'est pas encore, dans la plupart des entreprises, en tant que priorité de performances et de features. Donc, généralement, le power est la dernière roue de la voiture. C'est très difficile de dire que je ne veux pas que ce patch s'entend parce que c'est un power d'air. Vous devez vraiment être fort. Mais, encore une fois, ce travail, si l'automation est mis en place, ce n'est pas un grand problème. Parce que la version potentielle va être automatiquement élevé par les outils. Ok, donc c'était beaucoup des descriptions. Je voudrais vous donner un exemple d'analyses. Donc, pour cet exemple, je vais utiliser un outil que j'ai développé pendant que j'étais à TI pour les processus de la map pour automater la capture et la procédure de tous ces indicateurs. Donc, cette application s'appelle la MapConf. Et c'est publié et disponible pour tout le monde. La idée est que dans une seule ligne de commande, je pourrais obtenir les infos que j'ai besoin sans d'autres processus de moi-même. Parfois, je suis un peu malade donc j'ai besoin d'un outil pour le faire pour moi. Donc, ici, le outil que j'ai proposé pour vous montrer est un papier 3D qui m'a apprécié de l'eau. C'est un outil qui m'a apprécié d'un outil 4.2.2 qui m'a apprécié d'un outil 4.2.2 Donc, ici, je vous présenterai les rapports que cet outil est capable d'automater automatiquement. Je ne vais pas vraiment aller dans les détails sur les valeurs, parce que je n'y crois pas. C'est le but. La idée est de vous montrer comment l'automation est bien. Donc, cet outil est capable de vous montrer d'un outil 4.2.2.2.2. Donc, ici, nous allons vous montrer un outil 4.2.2.2.2.2. C'est un outil 3.2.2.2.2. Donc, ici, nous allons vous montrer comment l'automation est bien. Vous pouvez vous montrer ce que vous avez fait dans ce genre de vidéo. Donc, ici, nous allons vous montrer ce qu'on a fait. Vous avez les dégoudissements et les clés de clés. Et donc, vous avez ce que vous avez déduit, ce que vous avez prévu et les statues finies. Donc, juste en une visite, vous savez exactement exactement ce que c'est bon et ce qu'il est mauvais. Et clairement, vous pouvez déjà râcher dans ce objet pour comprendre pourquoi cela n'est pas comme cela. Donc, vous avez tous les statues mais ce n'est pas une ligne avec l'estimation. Si nous continuons dans le reportage, il y a d'autres paramètres de hardwares, le C-State, donc le STAT, on va vérifier qui est entré, le plus bas, en fait, et faire sure que c'est une ligne, toutes les clés, etc. Donc ici, encore, vous pouvez voir que le STAT n'est pas dans le state prévenu. Le STAT, le GPU aussi, et des ABDPL n'ont pas été arrêtés, comme l'on l'a dit. Au bout du reportage, il y a une date passée, qui est displays. C'est très utile, comme je l'ai dit, pour les trackings, parce que pour ces données, vous pouvez les prendre et les sauver pour chaque nouvelle relance, et vous pouvez, vous savez, l'évolue. Certains autres détails, que l'on pourrait extraire, que pour chaque single clock de la plateforme, on pourrait dire si le rate de ce clock était bon ou pas. Donc ici, très rapidement, vous avez la passée. Certains autres paramètres de dynamique ne sont pas montrés avant, et il y a une autre ligne qui est utilisée pour ça. Mais ici, il va vous montrer des paramètres de dynamique et des statistiques. Donc la première, elle vous montre, quelles études, et combien de temps l'EPU s'est installée dans ces études. C'est très facile de vérifier les estimations. C'est la même chose pour l'OPP. Vous avez exactement le temps de la transition de l'OPP durant la duration de l'audition. Donc ici, ce qui pourrait être étrange c'est que pour une sorte de low performance de l'usage, le state la plus bas de l'EPU n'a pas été installé. Donc peut-être qu'il y a quelque chose qui va être installé, peut-être un constrain installé par l'utilisateur. Et aussi, vous pouvez voir que même si il n'y a pas rien à faire sur le site de l'EPU, il n'est pas encore beaucoup de temps dans l'OPP. Donc il y a un problème. Plus d'infos encore. Donc ici, c'est sur les interruptes. En regardant tous les interruptes qui ont s'occuper durant l'usage, c'est très utile parce que vous pouvez extraire différents types d'informations. D'abord, vous pouvez vérifier qu'il n'y a pas d'interrupte qui a été installé. Et ici, clairement, il y a le WAL, c'est le link wireless. C'est le Wifi chip de la plateforme. C'est généré d'interruptes. Le MMC aussi. Vous ne l'aurez pas attendu. Et c'est aussi très utile de vérifier le rate. Si vous regardez le SGX ISR, donc c'est l'interrupte GPU. Vous voyez, c'est attiré à 120 interruptes par seconde. En fait, c'est deux fois le frame rate, donc 60. Donc c'est aussi un très facile de vérifier le rate. Et donc, finalement, la dernière chose que je voulais vous montrer dans cet exemple est que nous avons vu des sortes de reports sur ce qui s'est passé, mais nous ne pouvons pas vraiment le voir. Donc ici, il y a aussi la possibilité d'exporter une trace, de capture une trace de tous ces paramètres en temps et de le montrer dans un charte. Donc ici, encore, un report sur ces paramètres, le GPU low, et les températures. Mais je préfère vous montrer ça, ce qui est en fait des scripts de GPU automatiquement générés par le tool. Et ça vous représente. Donc, la vitesse des processors, le load, ainsi que le load de mémoire et la température. Donc, si vous observez ça, dans cet endroit, vous verrez qu'il y a d'autres processus. Je veux dire, plus de processus et vous pouvez aussi l'identifier en regardant le CPU et l'OPP, parce que vous voyez que vous spentez plus de temps à la hausse. Et enfin, vous pouvez voir qu'il a un impact immédiat sur la température. Donc, la duration est très courte. Vous voyez, c'est deux secondes. Mais encore, vous avez réussi à créer la température à 2 ou 3 degrés. Donc, c'était l'analyse. Et comment conclurez-vous ? Je ne conclurai pas mais je vous donne des pensées finlles ou des recommandations sur tout cela. Le premier conseil serait d'interroger. C'est trop tard pour fixer les problèmes de power quand vous facez ça. Si vous n'avez pas fait toutes les choses que l'on a décroche, c'est trop tard parce qu'il n'y aura pas d'infrastructure sur votre plateforme, sur votre hardware ou sur le software pour comprendre ce qui s'occupe. Donc, c'est très important de l'interroger. Alors, twice, quand vous designez votre nouveau silicone et partagez-le pour la puissance, vous devez avoir de la puissance en mind. Vous ne devez pas construire votre maison avec une seule puissance. Donc, ce qui signifie que chaque periferole de l'AVD est dédicatée par la puissance. Vous devez poursuivre la periferole par l'usage. Donc, c'est très efficace. Ne partagez pas les réguliers de voltage, les réguliers de voltage parce que c'est inéficient. Et utilisez aussi bien les techniques de tension avec les latencies lourdes pour que la puissance puisse dormir le plus vite possible. Parce que l'un des choses qu'on sait c'est que le voltage est le quai du problème. Le quai du problème n'est pas le problème. Parce que la puissance est proportionnelle pour le quai du voltage. Donc, scalez la puissance sans scalez la puissance c'est un waste de temps et ça consomme plus de puissance. Parce que votre CPU va rester active plus longtemps. Faisons les policiers. Toutes les policiers de la puissance et les policiers de la puissance qui arrivent par défaut et qui font des plateformes. Il y a plus de plateformes et des services. Ils peuvent travailler bien pour certaines situations mais pas pour toutes les situations. Et en fait, il n'y a pas un policier parfait qui est bon pour tout. Donc, n'hésitez pas à changer les policiers sur le vol dans la détection de l'usage et faichons les paramètres basé sur votre plateforme. Donc, c'est plus facile de wasteer moins de puissance que de trouver une solution mécanique pour disparaître plus de puissance. Nous sommes dans le monde ambitieux. Nous ne sommes pas dans le monde desktop PC. Donc, nous n'avons pas de fan. Nous n'avons qu'un cas et votre peau pour disparaître la température. L'entraînement de la température est aussi important parce que c'est un bon moyen pour éviter le problème d'utiliser la dégradation de l'interface. Si vous commencez à déclarer la température parce que vous êtes en train d'améliorer la température donc la plateforme sera moins responsable. Et donc, l'utilise va le voir. Et ce n'est pas bien, généralement. Finalement, la première recommandation est que la seule chose qui m'intéresse est la batterie. Donc, vous devez focusser sur les principaux contributaires pour cette consommation. Il n'y a pas de point de sauver 30 % de la batterie que vous comptez pour un couple de % de la consommation totale. Vous ne verrez pas. Et aussi, n'oubliez pas que vous êtes en train d'améliorer un système très complexe. Donc, les choses sont peut-être que vous faites des optimisations sur l'une de l'autre mais sur l'autre de l'autre il est en train d'améliorer la température parce que peut-être que vous arrêtez un processeur sur l'un de l'autre mais cela signifie que ça va rire plus longtemps. Donc, peut-être que la consommation sera plus grande. Donc, c'est très important pour ce système. Ce n'est pas tout le CPU. Ce n'est pas tout le GPU. C'est tout le plateforme. Et c'est la fin. Et je vous remercie d'avoir suivi cette session et j'espère que vous trouverez ce qui est intéressant. C'est maintenant ouvert pour des questions. Oui ? Oui, on a trouvé quelque chose. On a identifié quelques causes de route. Je veux dire, j'ai fait ceci pour cette présentation. Ce n'est pas plus mon travail de faire ça. Clairement, vous avez beaucoup d'informations de cette analyse. Vous avez beaucoup d'informations de hints. Ok, je dois vérifier le processeur de CPU parce que clairement, c'est très haut. Il y a beaucoup de transition d'OPP. Peut-être que ma police, la police de CPU fric qui est en train est oscillée ou est trop sensible. Et donc, ça continue à mettre le CPU haut, quand il n'y a pas besoin. Des choses comme ça. Donc, ces tools, des tools comme ça, sont très aidables pour vous aider, à proposer les problèmes. Ce n'est pas de vous fixer les problèmes, mais de vous proposer les problèmes. Et donc après, vous pouvez retourner à votre code et voir ce qu'est le problème. Une autre question ? Oui ? Oui. Ce tool est publiément disponible. Pour sûr, c'était le premier place de targeter la plateforme OMAP. Donc, c'est en train d'établir l'OMAP-4 et l'OMAP-5. Et maintenant, TI est en train de porter sur la plateforme Citara. Certaines fonctions sont clairement spécifiques. Parce que ce tool est capable d'aller directement prendre l'information dans les registres de la CPU. Ce n'est pas générique, mais certaines autres fonctions, comme ces traits, etc. Certaines paramètres, comme la CPU load. Oui, oui, c'est générique. Donc, partie du tool est en fait générique. L'un de mes goles est d'ajouter un tool plus générique que l'OMAP-5. Oui. TI est toujours en train de maintenir. Mais c'est disponible sur GitHub. Oui, oui. Oui. Une autre question? Ok. Merci beaucoup.