{"push_id":946972261,"size":238,"distinct_size":1,"ref":"refs/heads/0xAX-tree","head":"a19821a08181035238d58c1245df3559da60e73e","before":"ae4bfd08d88cc320fe3b9399ec7a9d40bcc068be","commits":[{"sha":"099a6644f5be438dd63c81ba942e7ffbb2c59099","author":{"email":"3055038c414aef68bf32c33b8118623e7554e0f2@nvidia.com","name":"Thierry Reding"},"message":"soc/tegra: Provide per-SoC Kconfig symbols\n\nMove per-SoC generation Kconfig symbols to drivers/soc/tegra/Kconfig to\ngather them all in a single place. This directory is a natural location\nfor these options since it already contains the drivers that are shared\nacross 32-bit and 64-bit ARM architectures.\n\nSigned-off-by: Thierry Reding <treding@nvidia.com>","distinct":false,"url":"https://api.github.com/repos/0xAX/linux/commits/099a6644f5be438dd63c81ba942e7ffbb2c59099"},{"sha":"9544595262f32f0e6dd6e0170e31ca8582c9cbb0","author":{"email":"3055038c414aef68bf32c33b8118623e7554e0f2@nvidia.com","name":"Thierry Reding"},"message":"soc/tegra: Add Tegra210 support\n\nAlso known as Tegra X1, the Tegra210 has four Cortex-A57 cores paired\nwith four Cortex-A53 cores in a switched configuration. It features a\nGPU using the Maxwell architecture with support for DX11, SM4, OpenGL\n4.5, OpenGL ES 3.1 and providing 256 CUDA cores. It supports hardware\naccelerated en- and decoding of various video standards including\nH.265, H.264 and VP8 at 4K resolutions and up to 60 fps.\n\nBesides the multimedia features it also comes with a variety of I/O\ncontrollers such as GPIO, I2C, SPI, SDHCI, PCIe, SATA and XHCI, to\nname only a few.\n\nAdd a Kconfig option for Tegra210 to allow SoC-specific support to be\nenabled for this new generation.\n\nSigned-off-by: Thierry Reding <treding@nvidia.com>","distinct":false,"url":"https://api.github.com/repos/0xAX/linux/commits/9544595262f32f0e6dd6e0170e31ca8582c9cbb0"},{"sha":"b73c48859895ec32a12ae9670a82c463f280ae35","author":{"email":"3055038c414aef68bf32c33b8118623e7554e0f2@nvidia.com","name":"Thierry Reding"},"message":"amba: Hide TEGRA_AHB symbol\n\nThe symbol depends on ARCH_TEGRA and will default to y. There are no\ncircumstances under which it is desirable to disable this option.\n\nSigned-off-by: Thierry Reding <treding@nvidia.com>","distinct":false,"url":"https://api.github.com/repos/0xAX/linux/commits/b73c48859895ec32a12ae9670a82c463f280ae35"},{"sha":"5883ac2010ef801cb9beb9606d3d50b3dca87113","author":{"email":"cbbc2a491dd609dc667a5c30620606c73351583d@nvidia.com","name":"Jon Hunter"},"message":"ARM: tegra: Ensure entire dcache is flushed on entering LP0/1\n\nTegra support several low-power (LPx) states, which are:\n- LP0: CPU + Core voltage off and DRAM in self-refresh\n- LP1: CPU voltage off and DRAM in self-refresh\n- LP2: CPU voltage off\n\nWhen entering any of the above states the tegra_disable_clean_inv_dcache()\nfunction is called to flush the dcache. The function\ntegra_disable_clean_inv_dcache() will either flush the entire data cache or\nup to the Level of Unification Inner Shareable (LoUIS) depending on the\nvalue in r0. When tegra_disable_clean_inv_dcache() is called by\ntegra20_sleep_core_finish() or tegra30_sleep_core_finish(), to enter LP0\nand LP1 power state, the r0 register contains a physical memory address\nwhich will not be equal to TEGRA_FLUSH_CACHE_ALL (1) and so the data cache\nwill be only flushed to the LoUIS. However, when\ntegra_disable_clean_inv_dcache() called by tegra_sleep_cpu_finish() to\nenter to LP2 power state, r0 is set to TEGRA_FLUSH_CACHE_ALL to flush the\nentire dcache.\n\nPlease note that tegra20_sleep_core_finish(), tegra30_sleep_core_finish()\nand tegra_sleep_cpu_finish() are called by the boot CPU once all other CPUs\nhave been disabled and so it seems appropriate to flush the entire cache at\nthis stage.\n\nTherefore, ensure that r0 is set to TEGRA_FLUSH_CACHE_ALL when calling\ntegra_disable_clean_inv_dcache() from tegra20_sleep_core_finish() and\ntegra30_sleep_core_finish().\n\nSigned-off-by: Jon Hunter <jonathanh@nvidia.com>\nReviewed-by: Joseph Lo <josephl@nvidia.com>\nSigned-off-by: Thierry Reding <treding@nvidia.com>","distinct":false,"url":"https://api.github.com/repos/0xAX/linux/commits/5883ac2010ef801cb9beb9606d3d50b3dca87113"},{"sha":"a262e87ff354f12447bb6268bd63edf7ba1c20e0","author":{"email":"f2c659f01951776204a6c5b902787d9019fbeebd@arndb.de","name":"Arnd Bergmann"},"message":"ARM: tegra: select USB_ULPI from EHCI rather than platform\n\nFor historic reasons, the tegra platform selects USB_ULPI from architecture\ncode, but that hasn't really made sense for a long time, as the only\nuser of that code is the Tegra EHCI driver that has its own Kconfig\nsymbol.\n\nThis removes the 'select' statements from mach-tegra and drivers/soc/tegra\nand adds them with the device driver that actually needs them.\n\nSigned-off-by: Arnd Bergmann <arnd@arndb.de>\nSigned-off-by: Thierry Reding <treding@nvidia.com>","distinct":false,"url":"https://api.github.com/repos/0xAX/linux/commits/a262e87ff354f12447bb6268bd63edf7ba1c20e0"},{"sha":"00ccc34b3e1432bdb4e1892b1eb56898d82db353","author":{"email":"3055038c414aef68bf32c33b8118623e7554e0f2@nvidia.com","name":"Thierry Reding"},"message":"Merge branch 'for-4.5/clk' into for-4.5/dt","distinct":false,"url":"https://api.github.com/repos/0xAX/linux/commits/00ccc34b3e1432bdb4e1892b1eb56898d82db353"},{"sha":"1d1bac6bbcb771fc685b05d7d32cae6225bb5379","author":{"email":"3055038c414aef68bf32c33b8118623e7554e0f2@nvidia.com","name":"Thierry Reding"},"message":"Merge branch 'for-4.5/soc' into for-4.5/dt","distinct":false,"url":"https://api.github.com/repos/0xAX/linux/commits/1d1bac6bbcb771fc685b05d7d32cae6225bb5379"},{"sha":"34b4f6d0599e920e0aca34816e5940b418188b03","author":{"email":"3055038c414aef68bf32c33b8118623e7554e0f2@nvidia.com","name":"Thierry Reding"},"message":"arm64: tegra: Add Tegra132 support\n\nNVIDIA Tegra132 (also known as Tegra K1 64-bit) is a variant of Tegra124\nbut with 2 Denver CPUs instead of the 4+1 Cortex-A15. This adds the DTSI\nfile for the SoC, which is mostly similar to the one for Tegra124.\n\nBased on work by Allen Martin <amartin@nvidia.com>\n\nCc: Paul Walmsley <pwalmsley@nvidia.com>\nCc: Allen Martin <amartin@nvidia.com>\nSigned-off-by: Thierry Reding <treding@nvidia.com>","distinct":false,"url":"https://api.github.com/repos/0xAX/linux/commits/34b4f6d0599e920e0aca34816e5940b418188b03"},{"sha":"0f279ebdf3ce5cd3ee23010a46680dca93282e34","author":{"email":"3055038c414aef68bf32c33b8118623e7554e0f2@nvidia.com","name":"Thierry Reding"},"message":"arm64: tegra: Add NVIDIA Tegra132 Norrin support\n\nNorrin is a Tegra132-based FFD used as reference platform within NVIDIA.\n\nBased on work by Allen Martin <amartin@nvidia.com>\n\nCc: Paul Walmsley <pwalmsley@nvidia.com>\nCc: Allen Martin <amartin@nvidia.com>\nSigned-off-by: Thierry Reding <treding@nvidia.com>","distinct":false,"url":"https://api.github.com/repos/0xAX/linux/commits/0f279ebdf3ce5cd3ee23010a46680dca93282e34"},{"sha":"742af7e7a0a132afe85cc7b8ac82fd20c7b63743","author":{"email":"3055038c414aef68bf32c33b8118623e7554e0f2@nvidia.com","name":"Thierry Reding"},"message":"arm64: tegra: Add Tegra210 support\n\nAlso known as Tegra X1, the Tegra210 has four Cortex-A57 cores paired\nwith four Cortex-A53 cores in a switched configuration. It features a\nGPU using the Maxwell architecture with support for DX11, SM4, OpenGL\n4.5, OpenGL ES 3.1 and providing 256 CUDA cores. It supports hardware\naccelerated en- and decoding of various video standards including\nH.265, H.264 and VP8 at 4K resolutions and up to 60 fps.\n\nBesides the multimedia features it also comes with a variety of I/O\ncontrollers such as GPIO, I2C, SPI, SDHCI, PCIe, SATA and XHCI, to\nname only a few.\n\nAdd a SoC-level device tree file that describes most of the hardware\navailable on the SoC. This includes only hardware for which a device\ntree binding already exists or which is trivial to describe.\n\nSigned-off-by: Thierry Reding <treding@nvidia.com>","distinct":false,"url":"https://api.github.com/repos/0xAX/linux/commits/742af7e7a0a132afe85cc7b8ac82fd20c7b63743"},{"sha":"c552cca31cfdef63182a2114f63d322a9d9bc54f","author":{"email":"3055038c414aef68bf32c33b8118623e7554e0f2@nvidia.com","name":"Thierry Reding"},"message":"arm64: tegra: Add NVIDIA P2530 main board support\n\nThe NVIDIA P2530 is a processor module used in several reference designs\nthat features a Tegra210 SoC, 4 GiB of LPDDR4 RAM, 16 GiB eMMC and other\nessentials. It is typically connected to some I/O board that provides\nthe connectors needed to hook it up to the outside world.\n\nSigned-off-by: Thierry Reding <treding@nvidia.com>","distinct":false,"url":"https://api.github.com/repos/0xAX/linux/commits/c552cca31cfdef63182a2114f63d322a9d9bc54f"},{"sha":"c24d2e13c6f66ea69adcccd6a74d11de9adfb157","author":{"email":"3055038c414aef68bf32c33b8118623e7554e0f2@nvidia.com","name":"Thierry Reding"},"message":"arm64: tegra: Add NVIDIA P2595 I/O board support\n\nThe NVIDIA P2595 I/O board is used in several reference designs and has\nthe connectors to connect the P2530 compute module to the outside world.\nIt features a USB 3.0 network adapter, a USB 3.0 port, an HDMI port, a\nSATA port, an audio codec, a microSD card slot and a display connector,\namong others.\n\nSigned-off-by: Thierry Reding <treding@nvidia.com>","distinct":false,"url":"https://api.github.com/repos/0xAX/linux/commits/c24d2e13c6f66ea69adcccd6a74d11de9adfb157"},{"sha":"63023e95bec0f0d22172c870b960641d663396a0","author":{"email":"3055038c414aef68bf32c33b8118623e7554e0f2@nvidia.com","name":"Thierry Reding"},"message":"arm64: tegra: Add NVIDIA P2371 board support\n\nThe NVIDIA P2371 is an internal reference design that uses a P2530\nprocessor module hooked up to a P2595 I/O board and an optional display\nmodule for a 1200x1920 MIPI DSI panel.\n\nSigned-off-by: Thierry Reding <treding@nvidia.com>","distinct":false,"url":"https://api.github.com/repos/0xAX/linux/commits/63023e95bec0f0d22172c870b960641d663396a0"},{"sha":"2cc85bd903370781ef2e85e8b03afc3653e26e36","author":{"email":"3055038c414aef68bf32c33b8118623e7554e0f2@nvidia.com","name":"Thierry Reding"},"message":"arm64: tegra: Add NVIDIA P2571 board support\n\nThe NVIDIA P2571 is an internal reference design that's very similar to\nthe P2371, but targetting different use-cases.\n\nSigned-off-by: Thierry Reding <treding@nvidia.com>","distinct":false,"url":"https://api.github.com/repos/0xAX/linux/commits/2cc85bd903370781ef2e85e8b03afc3653e26e36"},{"sha":"9e71045f1b770cd609509fc77fe19f84281d0b78","author":{"email":"3055038c414aef68bf32c33b8118623e7554e0f2@nvidia.com","name":"Thierry Reding"},"message":"arm64: tegra: Add NVIDIA Jetson TX1 support\n\nThe NVIDIA Jetson TX1 is a processor module that features a Tegra210 SoC\nwith 4 GiB of LPDDR4 RAM attached, a 32 GiB eMMC and other essentials.\n\nIt is typically connected to some I/O board (such as the P2597) that has\nthe connectors needed to hook it up to the outside world.\n\nSigned-off-by: Thierry Reding <treding@nvidia.com>","distinct":false,"url":"https://api.github.com/repos/0xAX/linux/commits/9e71045f1b770cd609509fc77fe19f84281d0b78"},{"sha":"2e6340577675536efc4f6028fb326f13e95724eb","author":{"email":"3055038c414aef68bf32c33b8118623e7554e0f2@nvidia.com","name":"Thierry Reding"},"message":"arm64: tegra: Add NVIDIA P2597 I/O board support\n\nThe NVIDIA P2597 I/O board is a carrier board for the Jetson TX1 module\nand together they are also known as the Jetson TX1 Developer Kit. The\nI/O board provides an RJ45 connector routed to the network adapter that\nis part of the Jetson TX1 module. It exposes many other connectors such\nas SATA, USB 3.0, HDMI, JTAG and PCIe, among others, as well. Dedicated\nconnectors allow display and camera modules to be attached. A full-size\nSD slot is provided to extend storage beyond the 32 GiB of eMMC found\non the Jetson TX1 module.\n\nSigned-off-by: Thierry Reding <treding@nvidia.com>","distinct":false,"url":"https://api.github.com/repos/0xAX/linux/commits/2e6340577675536efc4f6028fb326f13e95724eb"},{"sha":"336f79c7b6d7d04f7dad0361b9f4c8995107c062","author":{"email":"3055038c414aef68bf32c33b8118623e7554e0f2@nvidia.com","name":"Thierry Reding"},"message":"arm64: tegra: Add NVIDIA Jetson TX1 Developer Kit support\n\nThe Jetson TX1 Development Kit is the successor of the Jetson TK1. The\nJetson TX1 is composed of the Jetson TX1 module (P2180) that connects to\nthe P2597 I/O board. It comes with a 1200x1920 MIPI DSI panel connected\nvia the P2597's display connector.\n\nSigned-off-by: Thierry Reding <treding@nvidia.com>","distinct":false,"url":"https://api.github.com/repos/0xAX/linux/commits/336f79c7b6d7d04f7dad0361b9f4c8995107c062"},{"sha":"ea3d7209ca01da209cda6f0dea8be9cc4b7a933b","author":{"email":"596727c8a0ea4db3ba2ceceedccbacd3d7b371b8@suse.com","name":"Jan Kara"},"message":"ext4: fix races between page faults and hole punching\n\nCurrently, page faults and hole punching are completely unsynchronized.\nThis can result in page fault faulting in a page into a range that we\nare punching after truncate_pagecache_range() has been called and thus\nwe can end up with a page mapped to disk blocks that will be shortly\nfreed. Filesystem corruption will shortly follow. Note that the same\nrace is avoided for truncate by checking page fault offset against\ni_size but there isn't similar mechanism available for punching holes.\n\nFix the problem by creating new rw semaphore i_mmap_sem in inode and\ngrab it for writing over truncate, hole punching, and other functions\nremoving blocks from extent tree and for read over page faults. We\ncannot easily use i_data_sem for this since that ranks below transaction\nstart and we need something ranking above it so that it can be held over\nthe whole truncate / hole punching operation. Also remove various\nworkarounds we had in the code to reduce race window when page fault\ncould have created pages with stale mapping information.\n\nSigned-off-by: Jan Kara <jack@suse.com>\nSigned-off-by: Theodore Ts'o <tytso@mit.edu>","distinct":false,"url":"https://api.github.com/repos/0xAX/linux/commits/ea3d7209ca01da209cda6f0dea8be9cc4b7a933b"},{"sha":"17048e8a083fec7ad841d88ef0812707fbc7e39f","author":{"email":"596727c8a0ea4db3ba2ceceedccbacd3d7b371b8@suse.com","name":"Jan Kara"},"message":"ext4: move unlocked dio protection from ext4_alloc_file_blocks()\n\nCurrently ext4_alloc_file_blocks() was handling protection against\nunlocked DIO. However we now need to sometimes call it under i_mmap_sem\nand sometimes not and DIO protection ranks above it (although strictly\nspeaking this cannot currently create any deadlocks). Also\next4_zero_range() was actually getting & releasing unlocked DIO\nprotection twice in some cases. Luckily it didn't introduce any real bug\nbut it was a land mine waiting to be stepped on.  So move DIO protection\nout from ext4_alloc_file_blocks() into the two callsites.\n\nSigned-off-by: Jan Kara <jack@suse.com>\nSigned-off-by: Theodore Ts'o <tytso@mit.edu>","distinct":false,"url":"https://api.github.com/repos/0xAX/linux/commits/17048e8a083fec7ad841d88ef0812707fbc7e39f"},{"sha":"32ebffd3bbb4162da5ff88f9a35dd32d0a28ea70","author":{"email":"596727c8a0ea4db3ba2ceceedccbacd3d7b371b8@suse.com","name":"Jan Kara"},"message":"ext4: fix races between buffered IO and collapse / insert range\n\nCurrent code implementing FALLOC_FL_COLLAPSE_RANGE and\nFALLOC_FL_INSERT_RANGE is prone to races with buffered writes and page\nfaults. If buffered write or write via mmap manages to squeeze between\nfilemap_write_and_wait_range() and truncate_pagecache() in the fallocate\nimplementations, the written data is simply discarded by\ntruncate_pagecache() although it should have been shifted.\n\nFix the problem by moving filemap_write_and_wait_range() call inside\ni_mutex and i_mmap_sem. That way we are protected against races with\nboth buffered writes and page faults.\n\nSigned-off-by: Jan Kara <jack@suse.com>\nSigned-off-by: Theodore Ts'o <tytso@mit.edu>","distinct":false,"url":"https://api.github.com/repos/0xAX/linux/commits/32ebffd3bbb4162da5ff88f9a35dd32d0a28ea70"}]}