Select Git revision
Search by author
- Any Author
- authors
-
Aaron Kim akim
-
Aaron Kloc akloc
-
Aaron Nabil aaronna
-
Abel Fang abel_fang
-
Abhijit Adsule adsule
-
Abhishek Kar abhiskar
-
Adam Ford aford
-
Adam Snyder adsnyder
-
Adam Yeh adam.yeh
-
Adigarla Devi adigarla.devi
-
aditya gunda agunda
-
Adrien Martinez adrien.martinez
-
Agathon Jung agathon.jung
-
Ahmed Ibrahim ahmedibrahim
-
Ahming Chrn ahmingchen
-
Aiden Chang achang
-
Aiden Li liang10
-
Akash Nair akash_thulasidharan
-
Akash Ranjan akash_ranjan
-
Akshay Mahajan akshay_mahajan
- Jan 08, 2021
-
-
Brian Norris authored
Don't use this branch. Change-Id: I1f54aa61c85b855e19bb516f19e4f61fcb5cec8d Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2616847 Reviewed-by:
Douglas Anderson <dianders@chromium.org> Tested-by:
Brian Norris <briannorris@chromium.org> Commit-Queue: Brian Norris <briannorris@chromium.org>
-
Brian Norris authored
Change-Id: I2bce7629e62d9eb55f6598dddbf056a9873644f5 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2616846 Reviewed-by:
-
- Aug 11, 2020
-
-
Fritz Koenig authored
This reverts commit 485b4ba8. Reason for revert: <wrong branch> Original change's description: > FROMLIST:venus: core: add shutdown callback for venus > > After the SMMU translation is disabled in the > arm-smmu shutdown callback during reboot, if > any subsystem are still alive then IOVAs they > are using will become PAs on bus, which may > lead to crash. > > Below are the consumers of smmu from venus > arm-smmu: consumer: aa00000.video-codec supplier=15000000.iommu > arm-smmu: consumer: video-firmware.0 supplier=15000000.iommu > > So implemented shutdown callback, which detach iommu maps. > > Signed-off-by:
Mansur Alisha Shaik <mansur@codeaurora.org> > > (am from https://lore.kernel.org/patchwork/patch/1284710/ ) > > BUG=b:149955289 > TEST=hw video plays back > > Signed-off-by:
Fritz Koenig <frkoenig@chromium.org> > > Change-Id: I8e7b00653c36bd0a20b52e35c77421b970474308 > Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2347212 > Reviewed-by:
Sean Paul <seanpaul@chromium.org> > Reviewed-by:
Matthias Kaehlcke <mka@chromium.org> > Reviewed-by:
-
Fritz Koenig authored
This reverts commit a04330ef. Reason for revert: <wrong branch> Original change's description: > FROMLIST:venus: parser: Prepare parser for multiple invocations > > Presently the hfi_parser has been called only once during driver > probe. To prepare the parser function to be called multiple times > from recovery we need to initialize few variables which are used > during parsing time. > > Signed-off-by:
Stanimir Varbanov <stanimir.varbanov@linaro.org> > Reviewed-by:
-
Fritz Koenig authored
This reverts commit d636cec7. Reason for revert: <wrong branch> Original change's description: > FROMLIST:venus: Rework recovery mechanism > > After power domains and clock restructuring the recovery for > sdm845 and v4 did not work properly. Fix that by reworking the > recovery function and the sequence. > > Signed-off-by:
-
Fritz Koenig authored
This reverts commit c9d6fd96. Reason for revert: <wrong branch> Original change's description: > FROMLIST:venus: Add new interface queues reinit > > Presently the recovery mechanism is using two hfi functions > to destroy and create interface queues. For the purpose of > recovery we don't need to free and allocate the memory used > for interface message queues, that's why we introduce new > function which just reinit the queues. Also this will give > to the recovery procedure one less reason to fail (if for > some reason we couldn't allocate memory). > > Signed-off-by:
-
Stanimir Varbanov authored
Presently the recovery mechanism is using two hfi functions to destroy and create interface queues. For the purpose of recovery we don't need to free and allocate the memory used for interface message queues, that's why we introduce new function which just reinit the queues. Also this will give to the recovery procedure one less reason to fail (if for some reason we couldn't allocate memory). Signed-off-by:
-
- Aug 10, 2020
-
-
Stanimir Varbanov authored
After power domains and clock restructuring the recovery for sdm845 and v4 did not work properly. Fix that by reworking the recovery function and the sequence. Signed-off-by:
-
Stanimir Varbanov authored
Presently the hfi_parser has been called only once during driver probe. To prepare the parser function to be called multiple times from recovery we need to initialize few variables which are used during parsing time. Signed-off-by:
-
Mansur Alisha Shaik authored
After the SMMU translation is disabled in the arm-smmu shutdown callback during reboot, if any subsystem are still alive then IOVAs they are using will become PAs on bus, which may lead to crash. Below are the consumers of smmu from venus arm-smmu: consumer: aa00000.video-codec supplier=15000000.iommu arm-smmu: consumer: video-firmware.0 supplier=15000000.iommu So implemented shutdown callback, which detach iommu maps. Signed-off-by:
-
- Jul 20, 2020
-
-
Harsha Priya authored
External HDMI receivers have analog circuitry that needs to be powered-on when exiting standby, and a mechanism to detect PCM v. IEC61937 data. These two steps take time and up to 2-3 seconds of audio may be muted when starting playback. Intel hardware (Haswell and beyond) can keep the link active with a 'silent stream', so that the receiver does not go through those two steps when valid audio is transmitted. This mechanism relies on an setting the channel_id as 0xf, sending info packet and preventing the codec from going to D3, which will increase the platform static power consumption. The info packet assumes a basic 2ch stereo, and the silent stream is enabled when connecting a monitor. In case of format changes the detection of PCM v. IEC61937 needs to be re-run. In this case there is no way to avoid the 2-3s mute. The silent stream is enabled with a Kconfig option, as well as a kernel parameter should there be a need to override the build time default. This approach is used based on the power_save capability as an example, but in the future, it may be used with a kcontrol, depending on UCM support for HDaudio legacy. Signed-off-by:
Harsha Priya <harshapriya.n@intel.com> Signed-off-by:
Emmanuel Jillela <emmanuel.jillela@intel.com> Reviewed-by:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Reported-by:
kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/r/1594068797-14011-1-git-send-email-harshapriya.n@intel.com Signed-off-by:
Takashi Iwai <tiwai@suse.de> (cherry picked from commit 951894cf https://github.com/tiwai/sound.git master) Conflicts: sound/pci/hda/patch_hdmi.c BUG=b:153123976 TEST=Play movie with Dell C5518QT monitor Change-Id: I877f6cc0bcfe9440b20ad76e1465debba89765b4 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2291207 Reviewed-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Cheng-Yi Chiang <cychiang@chromium.org> Tested-by:
Emmanuel Jillela <emmanuel.jillela@intel.corp-partner.google.com> Commit-Queue: Cheng-Yi Chiang <cychiang@chromium.org>
-
- Jul 02, 2020
-
-
Jitao Shi authored
To meet the panel's poweron sequrence. And avoid the backlight on before video. BUG=b:157102544 TEST=emerge-kukui chromeos-kernel-4_19 Signed-off-by:
Jitao Shi <jitao.shi@mediatek.com> Change-Id: Ic3c6ddd31a23e9044d0548ef8841daa9cfb643ef Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2255733 Reviewed-by:
Nicolas Boichat <drinkcat@chromium.org> Commit-Queue: Nicolas Boichat <drinkcat@chromium.org> Tested-by:
-
- Jun 01, 2020
-
-
Hikaru Nishida authored
There is no good reason for the virtio-wl driver not to be buildable as a module. To make it builable as a loadable module, change CONFIG_VIRTIO_WL to tristate. BUG=b:156872580 TEST=./scripts/config -m CONFIG_VIRTIO_WL && make Change-Id: Ie766dfb071acdd53dfb0b962d16bde7a28a7d624 Signed-off-by:
Hikaru Nishida <hikalium@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2215663 Reviewed-by:
Tomasz Figa <tfiga@chromium.org>
-
Hikaru Nishida authored
Export virtio_gpu_dma_buf_to_handle to make buildable virtio-wl as a loadable module. Fixes: cea7ac75 ("CHROMIUM: drm/virtio: Add interfaces to share dma bufs via virtwl.") BUG=b:156872580 TEST=make vmlinux Change-Id: I0b3e5aab7eb506d2958d97ffff2a9f04e7f46d35 Signed-off-by:
-
- May 28, 2020
-
-
Fritz Koenig authored
This reverts commit b6932a9a. Reason for revert: wrong branch, should have gone on cros/chromeos-5.4 Original change's description: > HACK: CHROMIUM: vidc: vdec: changes to enable UBWC on sc7180 > > Driver chagnes to enable UBWC on sc7180 > > There currently isn't any way of using modifiers to tell > v4l2 that a buffer is expecting UBWC video and that the > decoder should use UBWC when decoding. > > The long term approach is to use ioctls extensions that > have been purposed on the ml. > https://lore.kernel.org/linux-media/20191008091119.7294-1-boris.brezillon@collabora.com/ > > BUG=b:149525848 > TEST=build kernel for trogdor > > Change-Id: I8067bef4459ac5b26e250ef046936d487781ee78 > Signed-off-by:
-
- May 27, 2020
-
-
Mansur Alisha Shaik authored
Driver chagnes to enable UBWC on sc7180 There currently isn't any way of using modifiers to tell v4l2 that a buffer is expecting UBWC video and that the decoder should use UBWC when decoding. The long term approach is to use ioctls extensions that have been purposed on the ml. https://lore.kernel.org/linux-media/20191008091119.7294-1-boris.brezillon@collabora.com/ BUG=b:149525848 TEST=build kernel for trogdor Change-Id: I8067bef4459ac5b26e250ef046936d487781ee78 Signed-off-by:
-
- Mar 25, 2020
-
-
Joel Fernandes (Google) authored
Signed-off-by:Joel Fernandes (Google) <joel@joelfernandes.org> Change-Id: I2b9658c3aef9ac2c36d9d83ce121265a7a9f21f2
-
Joel Fernandes (Google) authored
Unfortunately this still causes deadlock. This reverts commit bc517a279907f23be3626a6eaa57af73888950c3 and uses rcu_read_lock_sched() instead. The drawback is a false +ve lockdep warning. Signed-off-by: -
Joel Fernandes (Google) authored
rcu_read_unlock() can incur an infrequent deadlock in sched_core_balance(). Fix this by disabling preemption instead. This fixes the following spinlock recursion observed when testing the core scheduling patches on PREEMPT=y kernel on ChromeOS: [ 3.240891] BUG: spinlock recursion on CPU#2, swapper/2/0 [ 3.240900] lock: 0xffff9cd1eeb28e40, .magic: dead4ead, .owner: swapper/2/0, .owner_cpu: 2 [ 3.240905] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 5.4.22htcore #4 [ 3.240908] Hardware name: Google Eve/Eve, BIOS Google_Eve.9584.174.0 05/29/2018 [ 3.240910] Call Trace: [ 3.240919] dump_stack+0x97/0xdb [ 3.240924] ? spin_bug+0xa4/0xb1 [ 3.240927] do_raw_spin_lock+0x79/0x98 [ 3.240931] try_to_wake_up+0x367/0x61b [ 3.240935] rcu_read_unlock_special+0xde/0x169 [ 3.240938] ? sched_core_balance+0xd9/0x11e [ 3.240941] __rcu_read_unlock+0x48/0x4a [ 3.240945] __balance_callback+0x50/0xa1 [ 3.240949] __schedule+0x55a/0x61e [ 3.240952] schedule_idle+0x21/0x2d [ 3.240956] do_idle+0x1d5/0x1f8 [ 3.240960] cpu_startup_entry+0x1d/0x1f [ 3.240964] start_secondary+0x159/0x174 [ 3.240967] secondary_startup_64+0xa4/0xb0 [ 14.998590] watchdog: BUG: soft lockup - CPU#0 stuck for 11s! [kworker/0:10:965] Cc: vpillai <vpillai@digitalocean.com> Cc: Aaron Lu <aaron.lwe@gmail.com> Cc: Aubrey Li <aubrey.intel@gmail.com> Cc: peterz@infradead.org Cc: paulmck@kernel.org Signed-off-by: -
Joel Fernandes (Google) authored
Signed-off-by: -
Joel Fernandes authored
Signed-off-by:Joel Fernandes <joelaf@google.com> Change-Id: Ib63e4ecf6ddad01f81ae7c56464f2bd1dfbfd84e
-
Joel Fernandes authored
Signed-off-by: -
Joel Fernandes (Google) authored
Change-Id: Id7d0f87c6678ad9bcd38d82325e69b9ca3e2e8b6 Signed-off-by: -
Joel Fernandes authored
Signed-off-by:
-
- Mar 18, 2020
-
-
Joel Fernandes (Google) authored
We don't have in 4.19: 3bd37062 ("sched/core: Provide a pointer to the valid CPU mask") So just use cpus_allowed to avoid backport hell. Signed-off-by:
-
Joel Fernandes (Google) authored
4.19 is missing the following patch which may have other dependencies. 039ae8bc ("sched/fair: Fix O(nr_cgroups) in the load balancing path") Just use for_each_leaf_cfs_rq() instead of for_each_leaf_cfs_rq_safe() as a workaround. Signed-off-by:
-
Tim Chen authored
When we bring a CPU online and enable core scheduler, tasks that need core scheduling need to be placed in the core's core scheduling queue. Likewise when we taks a CPU offline or disable core scheudling on a core, tasks in the core's core scheduling queue need to be removed. Without such mechanisms, the core scheduler causes OOPs due to inconsistent core scheduling state of a task. Implement such enqueue and dequeue mechanisms according to a CPU's change in core scheduling status. The switch of core scheduling mode of a core, and enqueue/dequeue of tasks on a core's queue due to the core scheduling mode change has to be run in a separate context as it cannot be done in the context taking cpu online/offline. Signed-off-by:Tim Chen <tim.c.chen@linux.intel.com>
-
Tim Chen authored
Core scheduler has extra overhead. Enable it only for core with more than one SMT hardware threads. Signed-off-by: -
Tim Chen authored
There could be races in core scheduler where a CPU is trying to pick a task for its sibling in core scheduler, when that CPU has just been offlined. We should not schedule any tasks on the CPU in this case. Return an idle task in pick_next_task for this situation. Signed-off-by: -
Tim Chen authored
A task will need to be moved into the core scheduler queue when the cgroup it belongs to is tagged to run with core scheduling. Similarly the task will need to be moved out of the core scheduler queue when the cgroup is untagged. Also after we forked a task, its core scheduler queue's presence will need to be updated according to its new cgroup's status. Implement these missing core scheduler queue update mechanisms. Otherwise, the core scheduler will OOPs the kernel when we toggle the cgroup's core scheduling tag due to inconsistent core scheduler queue status. Use stop machine mechanism to update all tasks in a cgroup to prevent a new task from sneaking into the cgroup, and missed out from the update while we iterates through all the tasks in the cgroup. A more complicated scheme could probably avoid the stop machine. Such scheme will also need to resovle inconsistency between a task's cgroup core scheduling tag and residency in core scheduler queue. We are opting for the simple stop machine mechanism for now that avoids such complications. Signed-off-by: -
Aubrey Li authored
For the NUMA load balance, don't migrate task to the CPU whose core cookie does not match with task's cookie Signed-off-by:Aubrey Li <aubrey.li@linux.intel.com>
-
Aubrey Li authored
In the slow path of task wakeup, find the idlest CPU whose core cookie matches with task's cookie Signed-off-by:
-
Aubrey Li authored
In the fast path of task wakeup, select the first cookie matched idle CPU instead of the first idle CPU. Signed-off-by: -
Aubrey Li authored
Load balance tries to move task from busiest CPU to the destination CPU. When core scheduling is enabled, if the task's cookie does not match with the destination CPU's core cookie and if the core is not idle, this task will be skipped by this CPU. This mitigates the forced idle time on the destination CPU. Signed-off-by: -
Aaron Lu authored
If the sibling of a forced idle cpu has only one task and if it has used up its timeslice, then we should try to wake up the forced idle cpu to give the starving task on it a chance. Signed-off-by:
Vineeth Remanan Pillai <vpillai@digitalocean.com> Signed-off-by:
Julien Desfossez <jdesfossez@digitalocean.com>
-
Aaron Lu authored
This patch provides a vruntime based way to compare two cfs task's priority, be it on the same cpu or different threads of the same core. When the two tasks are on the same CPU, we just need to find a common cfs_rq both sched_entities are on and then do the comparison. When the two tasks are on differen threads of the same core, the root level sched_entities to which the two tasks belong will be used to do the comparison. An ugly illustration for the cross CPU case: cpu0 cpu1 / | \ / | \ se1 se2 se3 se4 se5 se6 / \ / \ se21 se22 se61 se62 Assume CPU0 and CPU1 are smt siblings and task A's se is se21 while task B's se is se61. To compare priority of task A and B, we compare priority of se2 and se6. Whose vruntime is smaller, who wins. To make this work, the root level se should have a common cfs_rq min vuntime, which I call it the core cfs_rq min vruntime. When we adjust the min_vruntime of rq->core, we need to propgate that down the tree so as to not cause starvation of existing tasks based on previous vruntime. Signed-off-by:Aaron Lu <ziqian.lzq@antfin.com> Change-Id: Ibf44492085ff31f376b529b0b94034f6bdb31895
-
Aaron Lu authored
Add a wrapper function cfs_rq_min_vruntime(cfs_rq) to return cfs_rq->min_vruntime. It will be used in the following patch, no functionality change. Signed-off-by: -
Peter Zijlstra authored
Not-Signed-off-by:Peter Zijlstra (Intel) <peterz@infradead.org>
-
Peter Zijlstra authored
When a sibling is forced-idle to match the core-cookie; search for matching tasks to fill the core. Signed-off-by: -
Peter Zijlstra authored
Signed-off-by:
-
