{"push_id":839653668,"size":3,"distinct_size":3,"ref":"refs/heads/lollipop","head":"9be773bb530da28fe18acf2272f9000d10eca8af","before":"9792e615f201f280a9973ed324fa58af6f512b8d","commits":[{"sha":"51041861acb0092c74a126bf8dc2eb7a811e2c64","author":{"email":"bb05168246ed1a6b66d0e7b1ffb0c5e3707764ca@codeaurora.org","name":"Junjie Wu"},"message":"qcom-cpufreq: Fix frequency table registration\n\nCPUfreq device is the provider of CPU frequency table, and\nit should always keep track of freq tables for every CPU itself.\ncpufreq_frequency_get_table() is an API for frequency table user.\nqcom-cpufreq should not use this API to obtain CPU freq table in\nthe init function. Otherwise, the following sequence will lead to init\nfailure.\n\nAssume CPU 0 and 1 are under control of same policy and online. Say\npolicy->cpu is CPU 0.\n\n1) Hot unplug CPU0\n   update_policy_cpu() will transfer ownership of policy to CPU1\n   cpufreq_frequency_table_update_policy_cpu() is called during\n   the process to set CPU1's freq table to be the same as CPU0's freq\n   table. CPU0's freq table is now NULL.\n2) Hot unplug CPU1\n   All CPUs in policy are now offline.\n3) Hot plug in CPU0\n   cpufreq_driver->init() is called for initialization. If this init\n   function calls cpufreq_frequency_get_table() on CPU0, the result\n   will be NULL.\n\nCurrent qcom-cpufreq checks return value of cpufreq_frequency_get_table()\nand returns an error in init.\n\nRemove the usage of cpufreq_frequency_get_table() and fill in frequency\ntable for policy->cpu in msm_cpufreq_init().\n\nChange-Id: I2d41af776938c31b4444c9f280a341dd1bed1548\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/audahadi/android_kernel_xiaomi_dior/commits/51041861acb0092c74a126bf8dc2eb7a811e2c64"},{"sha":"2be88cb95789fe8c77b52081240d81583738bcad","author":{"email":"ce25c3cee4cc6c4c8acfc1680b3ed89cf644dba3@codeaurora.org","name":"Saravana Kannan"},"message":"devfreq: Backport MSM devfreq features from 3.10\n\nPM / devfreq: Rewrite devfreq_update_status() to fix multiple bugs\n\nThe current devfreq_update_status() has the following bugs:\n- When the new frequency doesn't have a valid level, the time spent in the\n  new frequency is counted towards the next valid frequency switch instead\n  of being ignored.\n- The time spent on the previous frequency is added to the new frequency's\n  stats instead of the previous frequency's stats.\n\nThis patch fixes all of this.\n\nChange-Id: I7bbdafca78d1565cdbf815356556fe6d6cca9e3f\nSigned-off-by: Saravana Kannan <skannan@codeaurora.org>\n\nPM / devfreq: Allocate memory using the right data type\n\nLong and int have different sizes on a 64-bit machine. Allocate\nmemory for the time_in_state table using the right data type.\n\nChange-Id: Iecc1acc12ddabdb436c212f205aaed8dbb49a2b4\nSigned-off-by: Suman Tatiraju <sumant@codeaurora.org>\n\ndevfreq: Make cpubw_hwmon governor reusable and hardware agnostic\n\nSince various hardware platforms might have different ways of monitoring\nthe CPU bandwidth, make the cpubw_hwmon governor hardware agnostic so that\nit can be reused across these hardware platforms.\n\nChange-Id: If7af01537dbf1df66551bea2bc73232d9e9264f7\nSigned-off-by: Saravana Kannan <skannan@codeaurora.org>\n\nPM / devfreq: Use freq_table for available_frequencies\n\nSome devices use freq_table instead of OPP. For those devices, the\navailable_frequencies file shows up empty. Fix that by using freq_table to\ngenerate the available_frequencies data when OPP is not present.\n\nChange-Id: Ibea8b388ee81c55d2eeddd8a1e2c18c91faed8c7\nSigned-off-by: Saravana Kannan <skannan@codeaurora.org>\n\nmsm: devfreq_cpubw: Move devfreq_cpubw to drivers/devfreq\n\nIn order to share devfreq_cpubw among all targets, it needs to be\nmoved outside arch/arm/mach-msm directory. Move the file and\nKconfig to drivers/devfreq.\n\nChange-Id: I4dd476b315b04f84b07855bec3ed5b6061549ea9\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>\n\nPM / devfreq: Generic cpufreq governor\n\nThis devfreq governor is a generic implementation that can scale any\ndevfreq device based on the current CPU frequency of all ONLINE CPUs. It\nallows for specifying CPU freq to devfreq mapping for specific devices.\nWhen such a mapping is not present, it defaults to scaling the device\nfrequency in proportion to the CPU frequency.\n\nChange-Id: I8d3b1fea26572defbad2ce8b6cf87930caa25ca6\nSigned-off-by: Saravana Kannan <skannan@codeaurora.org>\n\nPM / devfreq: Fix warning in governor_cpufreq\n\nThe cpu_khz variable would be uninitialized when debug messages are printed\nfor OFFLINE CPUs. Fix that by initializing it to 0.\n\nChange-Id: Ic707c13b1048625c0ecc0b0057af2f84f17462f6\nSigned-off-by: Saravana Kannan <skannan@codeaurora.org>\n\nPM / devfreq: Add devfreq driver for simple device\n\nThis driver registers a devfreq device that allows devfreq governors to\nscale the frequency of a device clock. This single driver can be used to\nsupport multiple devices as long as those devices don't have a need or\nmechanism to monitor their load and use clock APIs to control their\ndevice/core clock.\n\nIf devices need to support device specific status monitoring, they could\nextend this driver to allow registering device specific status monitoring\nfuntions or write their own specific devfreq device driver.\n\nChange-Id: Ie1797acf7b35cac6dc49428e270c23082634eb1e\nSigned-off-by: Saravana Kannan <skannan@codeaurora.org>\n\nPM / devfreq: Add cache HW monitor governor\n\nThe cache HW monitor devfreq governor uses the hardware counters to\ndetermine the load on the cache and the appropriate frequency needed to\nsupport that load. This governor can be used in conjunction with the cache\ndevfreq device to dynamically scale the cache frequency based on the\ndemand/actual usage from the CPU subsystem.\n\nThe governor is written to be agnostic of the actual counters used to\ndetermine the load. On Krait based CPUs, the governor uses the Krait L2 PM\ncounters which can conflict with certain profiling tools.\n\nThe Krait L2 performance monitor counters have the capability to count\ndifferent types of requests going to the L2 cache. They also have the\ncapability to raise interrupts when they overflow. This driver uses those\ncounters to determine the true usage of L2 from the Krait processor\nsubsystem and then recommends L2 frequency based on the measured values and\nthe following tunable parameters.\n\nThe driver provides various tunables that allow it to be tuned more in\nfavor of power or performance:\n\n- cycles_per_high_req: The no. of cache clock cycles that are necessary to\n  efficiently process a high-work request to the cache. A higher value\n  means higher power and potentially higher performance. A lower value\n  means lower power and potentially lower performance.\n\n- cycles_per_med_req: The no. of cache clock cycles that are necessary to\n  efficiently process a medium-work request to the cache. A higher value\n  means higher power and potentially higher performance. A lower value\n  means lower power and potentially lower performance.\n\n- polling_ms: The sampling period in milliseconds. This only affects the\n  sampling period when cache use is ramping down or is increasing very\n  slowly (See tolerance_mrps).\n\n- min_busy: The minimum percentage of time the cache should be busy. This\n  is also applied as a lower bound to the measured busy percentage before\n  it's used in calculations. This has to be lower than or equal to\n  max_busy. Lower values will make the scaling more aggressive.\n\n- max_busy: The maximum percentage of time the cache should be busy. This\n  is also applied as an upper bound to the measured busy percentage before\n  it's used in calculations. This has to be greater than or equal to\n  min_busy. Lower values will make the scaling more aggressive.\n\n- tolerance_mrps: The minimum increase (in millions of requests per second)\n  in cache requests, compared to previous sample, that will trigger an IRQ\n  to immediately re-evaluate the cache frequency.\n\n- decay_rate: The parameter controls the rate at which the history is\n  forgotten when ramping down. This is expressed as a percentage of history\n  to be forgotten. So 100% means ignore history, 0% means never forget the\n  historical max. The default 90% means forget 90% of history each time.\n\n- guard_band_mhz: This is a margin that's added to the computed cache\n  frequency to account for the time it takes between the load increasing\n  and the governor/device finishes ramping up the cache frequency.\n\nChange-Id: I918ae178cd3c9d14cb7714d7eb312cbbbb0d977b\nSigned-off-by: Saravana Kannan <skannan@codeaurora.org>\n\nclock-a7/krait: Change initcall level for early probe\n\nRequirement to probe CPU clock drivers and register msm-cpufreq early\nmandates initcall level changes in these drivers. Order among generic\nclock driver, CPU clock driver and msm-cpufreq is unchanged, but\nCPU clock drivers and msm-cpufreq are moved to earlier level to meet\nnew requirement.\n\nChange-Id: I91c615795e2b114059d34f41b2f562a3e394e341\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>\n\ncpufreq: delete __cpuinit usage from all cpufreq files\n\nThe __cpuinit type of throwaway sections might have made sense\nsome time ago when RAM was more constrained, but now the savings\ndo not offset the cost and complications.  For example, the fix in\ncommit 5e427ec2d0 (\"x86: Fix bit corruption at CPU resume time\")\nis a good example of the nasty type of bugs that can be created\nwith improper use of the various __init prefixes.\n\nAfter a discussion on LKML[1] it was decided that cpuinit should go\nthe way of devinit and be phased out.  Once all the users are gone,\nwe can then finally remove the macros themselves from linux/init.h.\n\nThis removes all the drivers/cpufreq uses of the __cpuinit macros\nfrom all C files.\n\n[1] https://lkml.org/lkml/2013/5/20/589\n\n[v2: leave 2nd lines of args misaligned as requested by Viresh]\nCc: \"Rafael J. Wysocki\" <rjw@sisk.pl>\nCc: Viresh Kumar <viresh.kumar@linaro.org>\nCc: cpufreq@vger.kernel.org\nCc: linux-pm@vger.kernel.org\nAcked-by: Dirk Brandewie <dirk.j.brandewie@intel.com>\nAcked-by: Viresh Kumar <viresh.kumar@linaro.org>\nSigned-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>\nGit-commit: 2760984f6578d5a462155bb4727766d0c8b68387\nGit-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git\n[junjiew@codeaurora.org: resolve trivial merge conflicts. Remove __cpuinit\n for arch/arm/mach-msm/cpufreq.c as well]\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>\n\nChange-Id: I9deb4ad1ffb557e928975f866c39e37f7180da35\n\nmsm: thermal: Make core control and PSM independent of cpu frequency\n\nUpdated the KTM to perform PMIC SW Mode(PSM) threshold monitoring\nand core control independent of the CPU frequency table\ninitialization.\n\nChange-Id: I45653ef3087830cc96326b8e770d826530b7fed5\nSigned-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>\n\nPM / devfreq: Move cpubw device from msm_cpufreq to cpufreq governor\n\nEnable the cpufreq governor for the cpubw device on all targets by:\n- Adding the devfreq-cpufreq node for mapping CPU freq to cpubw\n- Enabling the cpufreq governor configs when CPUBW config is selected\n- Switching the default governor for cpubw device to \"cpufreq\"\n\nChange-Id: Ic10b645123192ed13c66340f288d6a8553d6f251\nSigned-off-by: Saravana Kannan <skannan@codeaurora.org>\n\ncpufreq: Add policy create/remove notifiers\n\nChange-Id: I1158f2650b8f6ce141ac1253ed70a3d6c036a559\n\nof: Add support for reading a u32 from a multi-value property.\n\nThis patch adds an of_property_read_u32_index() function to allow\nreading a single indexed u32 value from a property containing multiple\nu32 values.\n\nChange-Id: I741d447bf90d0150939ced92a9a150b7a6de25bc\nSigned-off-by: Tony Prisk <linux@prisktech.co.nz>\nReviewed-by: Stephen Warren <swarren@nvidia.com>\nAcked-by: Linus Walleij <linus.walleij@linaro.org>\nAcked-by: Rob Herring <robherring2@gmail.com>\n\nARM: dts: msm: Scale cache with CPUfreq using devfreq governor and device\n\nFor SoCs with asynchronous cache:\n- Add qcom,cache device to provide the clock and the list of usable\n  frequencies to the devfreq clock driver. Also set the default governor\n  for this device to \"cpufreq\".\n- Add CPUfreq to cache freq mapping for the cache device.\n- Enable the DEVFREQ_SIMPLE_DEV config for these targets.\n\nChange-Id: I5bda30420e79935d8d660306dd25d45042a3945b\nSigned-off-by: Saravana Kannan <skannan@codeaurora.org>\n\nmsm: cpufreq: Remove acpuclock calls from cpufreq\n\nmsm-cpufreq has moved to use generic clock APIs for getting and\nsetting clock frequency. Remove the usage of deprecated acpuclock\nAPIs.\n\nChange-Id: Ia05a86a58e031a3ec4ea59cb00fba1c33cddc78b\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>\n\nmsm: cpufreq: Remove use of cpu_is_* API\n\ncpu_is_* API is deprecated. Relevant targets now rely on is_sync for\nproper cpufreq mask setup. Remove unnecessary cpu_is_* calls from\ncpufreq.c\n\nChange-Id: I326d24c24f37b34fba36dbf9fc08aa5071180b51\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>\n\nqcom-cpufreq: Block hotplug until cpufreq is ready\n\nHotplug before qcom-cpufreq is ready could lead to inconsistent CPU\nclock state. Block hotplug by returning NOTIFY_BAD in hotplug callback\nuntil qcom-cpufreq is probed.\n\nChange-Id: I72a2f98c083c9b21b95ecafdb5a5be7a7682e842\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>\n\nqcom-cpufreq: Fix hotplug blocking logic\n\nChange 2b63b10 qcom-cpufreq: Block hotplug until cpufreq is ready\nintended to block hotplug until qcom-cpufreq driver has got all\nclocks. However, its implementation still leaves a small window when\nCPU 0 has got its clock but others haven't. If a hotplug happens on\nanother CPU that doesn't have its clock pointer, refcount of that CPU\nclock will again be wrong.\n\nFix the issue by introducing a ready flag.\n\nChange-Id: I1e05b063b0584088f717b82709a3f1d55bc6561b\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>\n\nqcom-cpufreq: Remove use of device_suspended in the hotplug path\n\nThe CPU_DOWN_PREPARE notifier in cpufreq.c already takes care\nof performing a CPUFREQ_GOV_STOP, which waits for in-progress\nfrequency switches to complete and prevents any additional\nfrequency switches from being performed. Remove the redundant\ncode for accomplishing the same thing from qcom-cpufreq.\n\nBesides being good cleanup, this change should also resolve\na potential deadlock in out-of-memory conditions. The scenario\narises if CPU1, executing in msm_cpufreq_target(), holds the\nqcom-cpufreq suspend_mutex while waiting for the completion\nat the end of that same function. In an out-of-memory condition,\nthe work performing that completion may not be able to\nimmediately run.\n\nAt the same time, CPU2 may be executing CPU_DOWN_PREPARE hotplug\nnotifiers. It will be holding the global hotplug mutex at this\ntime, and will eventually become blocked in\nmsm_cpufreq_cpu_callback() while waiting for the CPU1 to release\nthe device_suspended lock.\n\nIf invoked, the out-of-memory killer will attempt to acquire\nthe hotplug mutex via get_online_cpus() as part of\nout_of_memory().  This lock is already held by CPU2. CPU2 will\nnot release the lock until the device_suspended lock is released\nby CPU1. The device_suspended lock will not be release until the\ncompletion in msm_cpufreq_target() is marked as complete, which\nwon't happen until the out-of-memory killer is able to free\nsome memory. Nasty deadlock.\n\nClearly, the out-of-memory condition itself needs to be resolved,\nbut there is no harm in resolving the deadlock also.\n\nChange-Id: I5f59864aeb12a8c2aa81de16446af09a6d514da4\nSigned-off-by: Matt Wagantall <mattw@codeaurora.org>\n\ncpufreq: msm: Clean up suspend hooks\n\nChange-Id: I241ecff962546f175c393283e5635f921c963525\n\nPM / devfreq: Move cpubw device from msm_cpufreq to cpufreq governor\n\nEnable the cpufreq governor for the cpubw device on all targets by:\n- Adding the devfreq-cpufreq node for mapping CPU freq to cpubw\n- Enabling the cpufreq governor configs when CPUBW config is selected\n- Switching the default governor for cpubw device to \"cpufreq\"\n\nChange-Id: Ic10b645123192ed13c66340f288d6a8553d6f251\nSigned-off-by: Saravana Kannan <skannan@codeaurora.org>\n\nConflicts:\n\tarch/arm/boot/dts/msm8974.dtsi\n\ncpufreq: Delete unused CPUBW and cache scaling code from cpufreq driver\n\nThe devfreq cpufreq governor and the devfreq devices for CPUBW and cache\nnow handle CPUBW and cache frequency scaling based on CPU frequency. So,\ndelete all the unused code in the cpufreq driver that relates to scaling\nCPUBW and cache.\n\nAlso update the msm-cpufreq DT format/data accordingly.\n\nChange-Id: I30bf7d8478c964ffa300dd78039cd8c280ec63fc\nSigned-off-by: Saravana Kannan <skannan@codeaurora.org>\n\ndrivers: qcom-cpufreq: Move disabling of clocks to CPU_DYING\n\nSome SoCs contain CPU clock trees the elements of which are\ngated off when the CPUs enter power collapse. This includes\nsources of glitch free muxes; therefore when the CPUs enter\npower collapse, those muxes cannot be switched.\n\nNow in the cpufreq driver, the CPU clocks are disabled in\nthe CPU_DEAD notifier, which implies that the CPU muxes\nare switched to a safe source *after* the CPUs are power\ncollapsed. However, the source of the GFMUX may already be\nturned off, causing the mux to get stuck.\n\nIdeally, the mux should allow a static switch, since the\nclock to the CPU is gated. Some implementations do not\nallow this.\n\nChange-Id: I37d3426f20250c59756a0b55d1284efad5359a23\nSigned-off-by: Vikram Mulukutla <markivx@codeaurora.org>\n\nqcom-cpufreq: Allow all CPUs to get cpu_clk on targets with sync CPUs\n\nFor targets with synchronous CPU clocks, only CPU0 has a clock pointer in\ncpu_clks[]. This forces CPU0 to be the last CPU to be hotplugged out, or go\nto certain low power mode that needs to disable CPU clocks.\n\nRemove this requirement by adding clock pointer for all CPUs. Drivers\nthat ask for CPU clocks will get same clock for CPUs in sync.\n\nChange-Id: Ib97af2c3b0fdbc8dbb78364178225cc64ed02036\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>\n\nqcom-cpufreq: Remove per-cpu workqueue\n\nIt's no longer a requirement to pin frequency change on the CPU that\nis being scaled. Therefore, there is no longer a need for per-cpu\nworkqueue in qcom-cpufreq. Remove the workqueue.\n\nChange-Id: Ic6fd7f898fa8b1b1226a178b04530c24f0398daa\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>\n\ncpufreq: Manage only online cpus\n\ncpufreq core doesn't manage offline cpus and if driver->init() has returned\nmask including offline cpus, it may result in unwanted behavior by cpufreq core\nor governors.\n\nWe need to get only online cpus in this mask. There are two places to fix this\nmask, cpufreq core and cpufreq driver. It makes sense to do this at common place\nand hence is done in core.\n\nSigned-off-by: Viresh Kumar <viresh.kumar@linaro.org>\nSigned-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>\n\ncpufreq: Notify governors when cpus are hot-[un]plugged\n\nBecause cpufreq core and governors worry only about the online cpus, if a cpu is\nhot [un]plugged, we must notify governors about it, otherwise be ready to expect\nsomething unexpected.\n\nWe already have notifiers in the form of CPUFREQ_GOV_START/CPUFREQ_GOV_STOP, we\njust need to call them now.\n\nSigned-off-by: Viresh Kumar <viresh.kumar@linaro.org>\nSigned-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>\n\ncpufreq: Simplify cpufreq_add_dev()\n\nCurrently cpufreq_add_dev() firsts allocates policy, calls\ndriver->init() and then checks if this CPU is already managed or not.\nAnd if it is already managed, its policy is freed.\n\nWe can save all this if we somehow know that CPU is managed or not in\nadvance.  policy->related_cpus contains the list of all valid sibling\nCPUs of policy->cpu. We can check this to see if the current CPU is\nalready managed.\n\nFrom now on, platforms don't really need to set related_cpus from\ntheir init() routines, as the same work is done by core too.\n\nIf a platform driver needs to set the related_cpus mask with some\nadditional CPUs, other than CPUs present in policy->cpus, they are\nfree to do it, though, as we don't override anything.\n\n[rjw: Changelog]\nSigned-off-by: Viresh Kumar <viresh.kumar@linaro.org>\nTested-by: Shawn Guo <shawn.guo@linaro.org>\nSigned-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>\n\nConflicts:\n\tdrivers/cpufreq/cpufreq.c\n\tdrivers/cpufreq/spear-cpufreq.c\n\nChange-Id: I9dbe6dc4ee385d2d0dfa1bd2c182cbaaa118cd06\n\ncpufreq: interactive: Remove unnecessary cpu_online() check\n\nCpufreq no longer calls governor callback for offlined cpus. i.e. All\npolicy->cpus are guaranteed to be online. Hence we don't need explicit check to\nsee if cpu is online or not.\n\nChange-Id: I9ad85ea4addd5b4a40952e59ed730dd15e328690\nSigned-off-by: Viresh Kumar <viresh.kumar@linaro.org>\n\nPM / devfreq: Refactor CPUBW HWmon governor to be more generic\n\nThe refactored governor will be called bw_hwmon since it's no longer\nlimited to monitoring the CPU BW in hardware.\n\nThe refactor allows the governor to support multiple devfreq devices. This\nis done by having different HW monitor instances register their capability\nto monitor different devfreq devices and then picking the right HW monitor\nbased on which devfreq device is using this governor.\n\nThe refactor also fixes a very unlikely race condition that can happen when\nstarting/stopping the governor.\n\nChange-Id: Ifeeeb256115f6ae3075f391d9b4b02666e06f737\nSigned-off-by: Saravana Kannan <skannan@codeaurora.org>\n\nConflicts:\n\tdrivers/devfreq/Kconfig\n\tdrivers/devfreq/governor_cpubw_hwmon.c\n\nPM / devfreq: bw_hwmon: Move IRQ handling to device specific drivers\n\nThe bandwidth monitoring devices might have more than one IRQ to handle or\nmight have notifications from other drivers instead of using actual IRQs.\nSo, refactor the governor to move the IRQ handling to the bandwidth\nmonitoring device specific drivers and just provide an API that can be used\nto request a re-evaluation.\n\nThe device specific driver can call this API to request an immediate\nre-evaluation whenever the bandwidth has exceeded the previously set limit\ninstead of waiting for the periodic update.\n\nChange-Id: I8bfd85d0cb59a1fd0116000aac430680e483b422\nSigned-off-by: Saravana Kannan <skannan@codeaurora.org>\n\nPM / devfreq: Make the CPUBW voting device driver to be more generic\n\nMaking the driver more generic would allow it to be reused for voting for\nBW requirements of other devices like GPU, etc.\n\nInstead of cpubw and qcom,cpubw, the driver and the device are now called\ndevbw and qcom,devbw respectively.\n\nChange-Id: I49e5a5ba6d46517da19d013413abd471a730af29\nSigned-off-by: Saravana Kannan <skannan@codeaurora.org>\n\nPM / devfreq: Add MSM BIMC bwmon support for bw_hwmon governor\n\nThe BIMC bwmon device supports monitoring read/write traffic from each BIMC\nmaster port. It also has the capability to raise an IRQ when the traffic\ncount exceeds a programmable threshold. This allows for it to be used with\nthe bw_hwmon governor to scale the BW requests from each BIMC master.\n\nChange-Id: Ie8a1471226411e23954ed556292186a5a864ddc1\nSigned-off-by: Saravana Kannan <skannan@codeaurora.org>\n\nConflicts:\n\tarch/arm64/Kconfig\n\nPM / devfreq: governor_bw_hwmon: Find the correct hwmon for a devfreq dev\n\nThe governor pointer match is only present to support legacy BW HW monitors\n(Krait) to maintain the legacy governor name. The newer BW HW monitor\ndevices do the matching using device pointer or of_node. So, the governor\npointer should not be checked if the BW HW monitor devices provide device\nor of_node pointers.\n\nChange-Id: Ic48f53e39a9b176b7dec415489bd1657d0df02e2\nSigned-off-by: Saravana Kannan <skannan@codeaurora.org>\n\nPM / devfreq: Revert addition of devfreq_governor_data and related changes\n\nThis reverts commit 0e5b3352b5f04919a250bba695444c3a29672525 and fixes\nother code that resulted from it. The devfreq_governor_data field is not\nneeded since the governors can use other means (like container_of) to find\nout device specific private data\n\nChange-Id: Ib7e5db29b40d9676bbb5cf6057e0072665ace821\nSigned-off-by: Saravana Kannan <skannan@codeaurora.org>\n\nPM / devfreq: Get priv data for msm-adreno-tz governor from dev_profile\n\nThe devfreq infrastructure has several bugs and general design flaws\nwith private governor data support. As a workaround the msm-adreno-tz\ngovernor gets it's private data from the device driver by doing a\ncontainer_of on the dev_profile registered by the device driver.\n\nChange-Id: Ib9dffd063fe3aa5cfd55727d41f7633e88b3f998\nSigned-off-by: Vladimir Razgulin <vrazguli@codeaurora.org>\n\ncpufreq: Notify all policy->cpus in cpufreq_notify_transition()\n\npolicy->cpus contains all online cpus that have single shared clock line. And\ntheir frequencies are always updated together.\n\nMany SMP system's cpufreq drivers take care of this in individual drivers but\nthe best place for this code is in cpufreq core.\n\nThis patch modifies cpufreq_notify_transition() to notify frequency change for\nall cpus in policy->cpus and hence updates all users of this API.\n\nChange-Id: Ib8699ed8fd47e0e90fadf00a4d966d8df9b62747\nSigned-off-by: Viresh Kumar <viresh.kumar@linaro.org>\nAcked-by: Stephen Warren <swarren@nvidia.com>\nTested-by: Stephen Warren <swarren@nvidia.com>\nSigned-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>\n\ncpufreq: Don't check cpu_online(policy->cpu)\n\npolicy->cpu or cpus in policy->cpus can't be offline anymore. And so we don't\nneed to check if they are online or not.\n\nChange-Id: Iade8855dfef39ce734bf0f3b7e241275d0f7107f\nSigned-off-by: Viresh Kumar <viresh.kumar@linaro.org>\nSigned-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>\n\nConflicts:\n\tarch/arm/mach-msm/cpufreq.c\n\nConflicts:\n\tarch/arm/mach-msm/cpufreq.c\n\tdrivers/cpufreq/cpufreq.c","distinct":true,"url":"https://api.github.com/repos/audahadi/android_kernel_xiaomi_dior/commits/2be88cb95789fe8c77b52081240d81583738bcad"},{"sha":"9be773bb530da28fe18acf2272f9000d10eca8af","author":{"email":"fa8a385479f9e6b154c6b04c95fe5ad29b1d0c11@codeaurora.org","name":"Karthik Reddy Katta"},"message":"msm: Fix for audio loss during WLAN & LTE call handover\n\nCurrent APR implementation doesn't support session based\nmultiple service registrations. The apr_deregister()\nfunction sets the destination and client IDs to zero, if\nderegister is called for a single service instance.\nFix this by registering for dummy services in voice SVC\ndriver.\n\nCRs-fixed: 690921\nChange-Id: I36ffee5102df25b3309032b64db7cd4c3dc0be1e\nSigned-off-by: Karthik Reddy Katta <a_katta@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/audahadi/android_kernel_xiaomi_dior/commits/9be773bb530da28fe18acf2272f9000d10eca8af"}]}