- Mar 28, 2019
-
-
Kieran Bingham authored
The drm_crtc_state documentation contains a subtle misspelling of the word subtle. Correct it. Signed-off-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Simon Horman <horms+renesas@verge.net.au> Reviewed-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
-
- Mar 23, 2019
-
-
Kairui Song authored
On machines where the GART aperture is mapped over physical RAM, /proc/kcore contains the GART aperture range. Accessing the GART range via /proc/kcore results in a kernel crash. vmcore used to have the same issue, until it was fixed with commit 2a3e83c6 ("x86/gart: Exclude GART aperture from vmcore")', leveraging existing hook infrastructure in vmcore to let /proc/vmcore return zeroes when attempting to read the aperture region, and so it won't read from the actual memory. Apply the same workaround for kcore. First implement the same hook infrastructure for kcore, then reuse the hook functions introduced in the previous vmcore fix. Just with some minor adjustment, rename some functions for more general usage, and simplify the hook infrastructure a bit as there is no module usage yet. Suggested-by:
Baoquan He <bhe@redhat.com> Signed-off-by:
Kairui Song <kasong@redhat.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Reviewed-by:
Jiri Bohac <jbohac@suse.cz> Acked-by:
-
- Mar 22, 2019
-
-
Shenghui Wang authored
"sbitmap_batch_clear" should be "sbitmap_deferred_clear" Acked-by:
Omar Sandoval <osandov@fb.com> Signed-off-by:
Shenghui Wang <shhuiw@foxmail.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
- Mar 21, 2019
-
-
Peter Xu authored
Signed-off-by:
Peter Xu <peterx@redhat.com> Signed-off-by:
-
Maarten Lankhorst authored
There has unfortunately been a conflict with the following 3 commits: commit e9961ab9 Author: Ayan Kumar Halder <ayan.halder@arm.com> Date: Fri Nov 9 17:21:12 2018 +0000 drm: Added a new format DRM_FORMAT_XVYU2101010 commit 7ba0fee2 Author: Brian Starkey <brian.starkey@arm.com> Date: Fri Oct 5 10:27:00 2018 +0100 drm/fourcc: Add AFBC yuv fourccs for Mali and commit 50bf5d7d Author: Swati Sharma <swati2.sharma@intel.com> Date: Mon Mar 4 17:26:33 2019 +0530 drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc Unfortunately gcc didn't warn about the redefinitions, because the double defines were the set to same value, and gcc apparently no longer warns about that. Fix this by using new XYVU for i915, without alpha, and making the Y41x definitions match msdn, with alpha. Fortunately we caught it early, and the conflict hasn't even landed in drm-next yet. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Brian Starkey <Brian.Starkey@arm.com> Cc: Swati Sharma <swati2.sharma@intel.com> Cc: Ayan Kumar Halder <ayan.halder@arm.com> Cc: malidp@foss.arm.com Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: Dave Airlie <airlied@linux.ie> Cc: Liviu Dudau <Liviu.Dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190319121702.6814-1-maarten.lankhorst@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com> #irc Acked-by:
Sean Paul <sean@poorly.run> Reviewed-by:
Ayan Kumar halder <ayan.halder@arm.com>
-
- Mar 20, 2019
-
-
Bart Van Assche authored
This function is not used outside the block layer core. Hence unexport it. Cc: Christoph Hellwig <hch@lst.de> Cc: Ming Lei <ming.lei@redhat.com> Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
-
Yufen Yu authored
For q->poll_nsec == -1, means doing classic poll, not hybrid poll. We introduce a new flag BLK_MQ_POLL_CLASSIC to replace -1, which may make code much easier to read. Additionally, since val is an int obtained with kstrtoint(), val can be a negative value other than -1, so return -EINVAL for that case. Thanks to Damien Le Moal for some good suggestion. Reviewed-by:
Damien Le Moal <damien.lemoal@wdc.com> Signed-off-by:
Yufen Yu <yuyufen@huawei.com> Signed-off-by:
-
Ilya Dryomov authored
Because map updates are distributed lazily, an OSD may not know about the new blacklist for quite some time after "osd blacklist add" command is completed. This makes it possible for a blacklisted but still alive client to overwrite a post-blacklist update, resulting in data corruption. Waiting for latest osdmap in ceph_monc_blacklist_add() and thus using the post-blacklist epoch for all post-blacklist requests ensures that all such requests "wait" for the blacklist to come into force on their respective OSDs. Cc: stable@vger.kernel.org Fixes: 6305a3b4 ("libceph: support for blacklisting clients") Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> Reviewed-by:
Jason Dillaman <dillaman@redhat.com>
-
Noralf Trønnes authored
Buffers passed to spi_sync() must be dma-safe even for tiny buffers since some SPI controllers use DMA for all transfers. Example splat with CONFIG_DMA_API_DEBUG enabled: [ 23.750467] DMA-API: dw_dmac_pci 0000:00:15.0: device driver maps memory from stack [probable addr=000000001e49185d] [ 23.750529] WARNING: CPU: 1 PID: 1296 at kernel/dma/debug.c:1161 check_for_stack+0xb7/0x190 [ 23.750533] Modules linked in: mmc_block(+) spi_pxa2xx_platform(+) pwm_lpss_pci pwm_lpss spi_pxa2xx_pci sdhci_pci cqhci intel_mrfld_pwrbtn extcon_intel_mrfld sdhci intel_mrfld_adc led_class mmc_core ili9341 mipi_dbi tinydrm backlight ti_ads7950 industrialio_triggered_buffer kfifo_buf intel_soc_pmic_mrfld hci_uart btbcm [ 23.750599] CPU: 1 PID: 1296 Comm: modprobe Not tainted 5.0.0-rc7+ #236 [ 23.750605] Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 2015.01.21:18.19.48 [ 23.750620] RIP: 0010:check_for_stack+0xb7/0x190 [ 23.750630] Code: 8b 6d 50 4d 85 ed 75 04 4c 8b 6d 10 48 89 ef e8 2f 8b 44 00 48 89 c6 4a 8d 0c 23 4c 89 ea 48 c7 c7 88 d0 82 b4 e8 40 7c f9 ff <0f> 0b 8b 05 79 00 4b 01 85 c0 74 07 5b 5d 41 5c 41 5d c3 8b 05 54 [ 23.750637] RSP: 0000:ffff97bbc0292fa0 EFLAGS: 00010286 [ 23.750646] RAX: 0000000000000000 RBX: ffff97bbc0290000 RCX: 0000000000000006 [ 23.750652] RDX: 0000000000000007 RSI: 0000000000000002 RDI: ffff94b33e115450 [ 23.750658] RBP: ffff94b33c8578b0 R08: 0000000000000002 R09: 00000000000201c0 [ 23.750664] R10: 00000006ecb0ccc6 R11: 0000000000034f38 R12: 000000000000316c [ 23.750670] R13: ffff94b33c84b250 R14: ffff94b33dedd5a0 R15: 0000000000000001 [ 23.750679] FS: 0000000000000000(0000) GS:ffff94b33e100000(0063) knlGS:00000000f7faf690 [ 23.750686] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 [ 23.750691] CR2: 00000000f7f54faf CR3: 000000000722c000 CR4: 00000000001006e0 [ 23.750696] Call Trace: [ 23.750713] debug_dma_map_sg+0x100/0x340 [ 23.750727] ? dma_direct_map_sg+0x3b/0xb0 [ 23.750739] spi_map_buf+0x25a/0x300 [ 23.750751] __spi_pump_messages+0x2a4/0x680 [ 23.750762] __spi_sync+0x1dd/0x1f0 [ 23.750773] spi_sync+0x26/0x40 [ 23.750790] mipi_dbi_typec3_command_read+0x14d/0x240 [mipi_dbi] [ 23.750802] ? spi_finalize_current_transfer+0x10/0x10 [ 23.750821] mipi_dbi_typec3_command+0x1bc/0x1d0 [mipi_dbi] Reported-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Tested-by:
-
- Mar 19, 2019
-
-
Dongli Zhang authored
There is no usage of 'nr_expired'. The 'nr_expired' was introduced by commit 1d9bd516 ("blk-mq: replace timeout synchronization with a RCU and generation based scheme"). Its usage was removed since commit 12f5b931 ("blk-mq: Remove generation seqeunce"). Signed-off-by:
Dongli Zhang <dongli.zhang@oracle.com> Signed-off-by:
-
- Mar 18, 2019
-
-
Jens Axboe authored
If bio_iov_iter_get_pages() is called on an iov_iter that is flagged with NO_REF, then we don't need to add a page reference for the pages that we add. Add BIO_NO_PAGE_REF to track this in the bio, so IO completion knows not to drop a reference to these pages. Signed-off-by: -
Jens Axboe authored
For ITER_BVEC, if we're holding on to kernel pages, the caller doesn't need to grab a reference to the bvec pages, and drop that same reference on IO completion. This is essentially safe for any ITER_BVEC, but some use cases end up reusing pages and uncondtionally dropping a page reference on completion. And example of that is sendfile(2), that ends up being a splice_in + splice_out on the pipe pages. Add a flag that tells us it's fine to not grab a page reference to the bvec pages, since that caller knows not to drop a reference when it's done with the pages. Signed-off-by: -
Laurent Pinchart authored
As writeback jobs contain a framebuffer, drivers may need to prepare and cleanup them the same way they can prepare and cleanup framebuffers for planes. Add two new optional connector helper operations, .prepare_writeback_job() and .cleanup_writeback_job() to support this. The job prepare operation is called from drm_atomic_helper_prepare_planes() to avoid a new atomic commit helper that would need to be called by all drivers not using drm_atomic_helper_commit(). The job cleanup operation is called from the existing drm_writeback_cleanup_job() function, invoked both when destroying the job as part of a aborted commit, or when the job completes. The drm_writeback_job structure is extended with a priv field to let drivers store per-job data, such as mappings related to the writeback framebuffer. For internal plumbing reasons the drm_writeback_job structure needs to store a back-pointer to the drm_writeback_connector. To avoid pushing too much writeback-specific knowledge to drm_atomic_uapi.c, create a drm_writeback_set_fb() function, move the writeback job setup code there, and set the connector backpointer. The prepare_signaling() function doesn't need to allocate writeback jobs and can ignore connectors without a job, as it is called after the writeback jobs are allocated to store framebuffers, and a writeback fence with a framebuffer is an invalid configuration that gets rejected by the commit check. Signed-off-by:
Liviu Dudau <liviu.dudau@arm.com>
-
Laurent Pinchart authored
The drm_writeback_queue_job() function takes ownership of the passed job and requires the caller to manually set the connector state writeback_job pointer to NULL. To simplify drivers and avoid errors (such as the missing NULL set in the vc4 driver), pass the connector state pointer to the function instead of the job pointer, and set the writeback_job pointer to NULL internally. Signed-off-by:
Brian Starkey <brian.starkey@arm.com> Acked-by:
Eric Anholt <eric@anholt.net> Acked-by:
-
Laurent Pinchart authored
Extend the vsp1_du_atomic_flush() API with writeback support by adding format, pitch and memory addresses of the writeback framebuffer. Writeback completion is reported through the existing frame completion callback with a new VSP1_DU_STATUS_WRITEBACK status flag. Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
-
Laurent Pinchart authored
The VSP1 driver will need to pass extra flags to the DU through the frame completion API. Replace the completed bool flag by a bitmask to support this. Signed-off-by:
-
Laurent Pinchart authored
This allows nicer kerneldoc with an easy way to reference the enum and the values. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Stefan Agner authored
The DRM bus flags convey additional information on pixel data on the bus. All current available bus flags might be of interest for a bridge. Remove the sampling_edge field and use bus_flags. In the case at hand a dumb VGA bridge needs a specific data enable polarity (DRM_BUS_FLAG_DE_LOW). Signed-off-by:
Stefan Agner <stefan@agner.ch> Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by:
-
Laurent Pinchart authored
The DRM_BUS_FLAG_PIXDATA_(POS|NEG)EDGE and DRM_BUS_FLAG_SYNC_(POS|NEG)EDGE flags are deprecated in favour of the new DRM_BUS_FLAG_PIXDATA_(DRIVE|SAMPLE)_(POS|NEG)EDGE and new DRM_BUS_FLAG_SYNC_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags. Replace them through the code. This effectively changes the value of the .sampling_edge bridge timings field in the dumb-vga-dac driver. This is safe to do as no driver consumes these values yet. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
-
Laurent Pinchart authored
The DRM_BUS_FLAG_PIXDATA_POSEDGE and DRM_BUS_FLAG_PIXDATA_NEGEDGE macros and their DRM_BUS_FLAG_SYNC_* counterparts define on which pixel clock edge data and sync signals are driven. They are however used in some drivers to define on which pixel clock edge data and sync signals are sampled, which should usually (but not always) be the opposite edge of the driving edge. This creates confusion. Create four new macros for both PIXDATA and SYNC that explicitly state the driving and sampling edge in their name to remove the confusion. The driving macros are defined as the opposite of the sampling macros to made code simpler based on the assumption that the driving and sampling edges are opposite. Signed-off-by:
-
Yishai Hadas authored
To prevent a hardware memory leak when a DEVX DCT object is destroyed without calling DRAIN DCT before, (e.g. under cleanup flow), need to manage its creation and destruction via mlx5 core. In that case the DRAIN DCT command will be called and only once that it will be completed the DESTROY DCT command will be called. Otherwise, the DESTROY DCT may fail and a hardware leak may occur. As of that change the DRAIN DCT command should not be exposed any more from DEVX, it's managed internally by the driver to work as expected by the device specification. Fixes: 7efce369 ("IB/mlx5: Add obj create and destroy functionality") Signed-off-by:
Yishai Hadas <yishaih@mellanox.com> Reviewed-by:
Artemy Kovalyov <artemyko@mellanox.com> Signed-off-by:
Leon Romanovsky <leonro@mellanox.com> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com>
-
- Mar 17, 2019
-
-
Andy Shevchenko authored
The charlcd_free() is a counterpart to charlcd_alloc() and should be called symmetrically on tear down. Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
-
Masahiro Yamada authored
Currently, every arch/*/include/uapi/asm/Kbuild explicitly includes the common Kbuild.asm file. Factor out the duplicated include directives to scripts/Makefile.asm-generic so that no architecture would opt out of the mandatory-y mechanism. um is not forced to include mandatory-y since it is a very exceptional case which does not support UAPI. Signed-off-by:Masahiro Yamada <yamada.masahiro@socionext.com>
-
- Mar 15, 2019
-
-
Josef Bacik authored
Patch series "drop the mmap_sem when doing IO in the fault path", v6. Now that we have proper isolation in place with cgroups2 we have started going through and fixing the various priority inversions. Most are all gone now, but this one is sort of weird since it's not necessarily a priority inversion that happens within the kernel, but rather because of something userspace does. We have giant applications that we want to protect, and parts of these giant applications do things like watch the system state to determine how healthy the box is for load balancing and such. This involves running 'ps' or other such utilities. These utilities will often walk /proc/<pid>/whatever, and these files can sometimes need to down_read(&task->mmap_sem). Not usually a big deal, but we noticed when we are stress testing that sometimes our protected application has latency spikes trying to get the mmap_sem for tasks that are in lower priority cgroups. This is because any down_write() on a semaphore essentially turns it into a mutex, so even if we currently have it held for reading, any new readers will not be allowed on to keep from starving the writer. This is fine, except a lower priority task could be stuck doing IO because it has been throttled to the point that its IO is taking much longer than normal. But because a higher priority group depends on this completing it is now stuck behind lower priority work. In order to avoid this particular priority inversion we want to use the existing retry mechanism to stop from holding the mmap_sem at all if we are going to do IO. This already exists in the read case sort of, but needed to be extended for more than just grabbing the page lock. With io.latency we throttle at submit_bio() time, so the readahead stuff can block and even page_cache_read can block, so all these paths need to have the mmap_sem dropped. The other big thing is ->page_mkwrite. btrfs is particularly shitty here because we have to reserve space for the dirty page, which can be a very expensive operation. We use the same retry method as the read path, and simply cache the page and verify the page is still setup properly the next pass through ->page_mkwrite(). I've tested these patches with xfstests and there are no regressions. This patch (of 3): If we do not have a page at filemap_fault time we'll do this weird forced page_cache_read thing to populate the page, and then drop it again and loop around and find it. This makes for 2 ways we can read a page in filemap_fault, and it's not really needed. Instead add a FGP_FOR_MMAP flag so that pagecache_get_page() will return a unlocked page that's in pagecache. Then use the normal page locking and readpage logic already in filemap_fault. This simplifies the no page in page cache case significantly. [akpm@linux-foundation.org: fix comment text] [josef@toxicpanda.com: don't unlock null page in FGP_FOR_MMAP case] Link: http://lkml.kernel.org/r/20190312201742.22935-1-josef@toxicpanda.com Link: http://lkml.kernel.org/r/20181211173801.29535-2-josef@toxicpanda.com Signed-off-by:
Josef Bacik <josef@toxicpanda.com> Acked-by:
Johannes Weiner <hannes@cmpxchg.org> Reviewed-by:
Jan Kara <jack@suse.cz> Reviewed-by:
Andrew Morton <akpm@linux-foundation.org> Cc: Tejun Heo <tj@kernel.org> Cc: Dave Chinner <david@fromorbit.com> Cc: Rik van Riel <riel@redhat.com> Cc: "Kirill A. Shutemov" <kirill@shutemov.name> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Mar 14, 2019
-
-
Pi-Hsun Shih authored
Use offsetof() to calculate offset of a field to take advantage of compiler built-in version when possible, and avoid UBSAN warning when compiling with Clang: UBSAN: Undefined behaviour in mm/swapfile.c:3010:38 member access within null pointer of type 'union swap_header' CPU: 6 PID: 1833 Comm: swapon Tainted: G S 4.19.23 #43 Call trace: dump_backtrace+0x0/0x194 show_stack+0x20/0x2c __dump_stack+0x20/0x28 dump_stack+0x70/0x94 ubsan_epilogue+0x14/0x44 ubsan_type_mismatch_common+0xf4/0xfc __ubsan_handle_type_mismatch_v1+0x34/0x54 __se_sys_swapon+0x654/0x1084 __arm64_sys_swapon+0x1c/0x24 el0_svc_common+0xa8/0x150 el0_svc_compat_handler+0x2c/0x38 el0_svc_compat+0x8/0x18 Link: http://lkml.kernel.org/r/20190312081902.223764-1-pihsun@chromium.org Signed-off-by:
Pi-Hsun Shih <pihsun@chromium.org> Acked-by:
Michal Hocko <mhocko@suse.com> Reviewed-by:
-
Noralf Trønnes authored
This adds a library for shmem backed GEM objects. v8: - export drm_gem_shmem_create_with_handle - call mapping_set_gfp_mask to set default zone to GFP_HIGHUSER - Add helper drm_gem_shmem_get_pages_sgt() v7: - Use write-combine for mmap instead. This is the more common case. (robher) v6: - Fix uninitialized variable issue in an error path (anholt). - Add a drm_gem_shmem_vm_open() to the fops to get proper refcounting of the pages (anholt). v5: - Drop drm_gem_shmem_prime_mmap() (Daniel Vetter) - drm_gem_shmem_mmap(): Subtract drm_vma_node_start() to get the real vma->vm_pgoff - drm_gem_shmem_fault(): Use vmf->pgoff now that vma->vm_pgoff is correct v4: - Drop cache modes (Thomas Hellstrom) - Add a GEM attached vtable v3: - Grammar (Sam Ravnborg) - s/drm_gem_shmem_put_pages_unlocked/drm_gem_shmem_put_pages_locked/ (Sam Ravnborg) - Add debug output in error path (Sam Ravnborg) Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Eric Anholt authored
Now that we have the reservation object in the GEM object, it's easy to provide a helper for this common case. Noticed while reviewing panfrost and lima drivers. This particular version came out of v3d, which in turn was a copy from vc4. v2: Fix kerneldoc warnings. Signed-off-by:
-
- Mar 13, 2019
-
-
Ricardo Biehl Pasquali authored
Signed-off-by:
Ricardo Biehl Pasquali <pasqualirb@gmail.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de>
-
Douglas Anderson authored
As reported back in 2016-11 [1], the "ftdump" kdb command triggers a BUG for "sleeping function called from invalid context". kdb's "ftdump" command wants to call ring_buffer_read_prepare() in atomic context. A very simple solution for this is to add allocation flags to ring_buffer_read_prepare() so kdb can call it without triggering the allocation error. This patch does that. Note that in the original email thread about this, it was suggested that perhaps the solution for kdb was to either preallocate the buffer ahead of time or create our own iterator. I'm hoping that this alternative of adding allocation flags to ring_buffer_read_prepare() can be considered since it means I don't need to duplicate more of the core trace code into "trace_kdb.c" (for either creating my own iterator or re-preparing a ring allocator whose memory was already allocated). NOTE: another option for kdb is to actually figure out how to make it reuse the existing ftrace_dump() function and totally eliminate the duplication. This sounds very appealing and actually works (the "sr z" command can be seen to properly dump the ftrace buffer). The downside here is that ftrace_dump() fully consumes the trace buffer. Unless that is changed I'd rather not use it because it means "ftdump | grep xyz" won't be very useful to search the ftrace buffer since it will throw away the whole trace on the first grep. A future patch to dump only the last few lines of the buffer will also be hard to implement. [1] https://lkml.kernel.org/r/20161117191605.GA21459@google.com Link: http://lkml.kernel.org/r/20190308193205.213659-1-dianders@chromium.org Reported-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org>
-
Kevin Strasser authored
Add 64 bpp 16:16:16:16 half float pixel formats. Each 16 bit component is formatted in IEEE-754 half-precision float (binary16) 1:5:10 MSb-sign:exponent:fraction form. This patch attempts to address the feedback provided when 2 of these formats were previosly proposed: https://patchwork.kernel.org/patch/10072545/ v2: - Fixed cpp (Ville) - Added detail pixel formatting (Ville) - Ordered formats in header (Ville) v5: - .depth should be 0 for new formats (Maarten) Cc: Tina Zhang <tina.zhang@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Kevin Strasser <kevin.strasser@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Adam Jackson <ajax@redhat.com> Signed-off-by:
-
Chao Yu authored
for better map_blocks trace. Signed-off-by:
Chao Yu <yuchao0@huawei.com> Signed-off-by:
Jaegeuk Kim <jaegeuk@kernel.org>
-
Chao Yu authored
This patch supports to trace f2fs_ioc_shutdown. Signed-off-by:
-
Zeng Guangyue authored
correct spelling mistake for "nunmber" Signed-off-by:
Zeng Guangyue <zengguangyue@hisilicon.com> Reviewed-by:
-
- Mar 12, 2019
-
-
Abel Vesa authored
IMX8MQ_CLK_USB_PHY_REF changes from 163 to 153, this way removing the gap. All the following clock ids are now decreased by 10 to keep the numbering right. Doing this, the IMX8MQ_CLK_CSI2_CORE is not overlapped with IMX8MQ_CLK_GPT1 anymore. IMX8MQ_CLK_GPT1_ROOT changes from 193 to 183 and all the following ids are updated accordingly. Reported-by:
Patrick Wildt <patrick@blueri.se> Fixes: 1cf3817b ("dt-bindings: Add binding for i.MX8MQ CCM") Signed-off-by:
Abel Vesa <abel.vesa@nxp.com> Signed-off-by:
Stephen Boyd <sboyd@kernel.org>
-
Olga Kornievskaia authored
Backchannel doesn't have the rq_task->tk_clientid pointer set. Otherwise can lead to the following oops: ocalhost login: [ 111.385319] BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 [ 111.388073] #PF error: [normal kernel read fault] [ 111.389452] PGD 80000000290d8067 P4D 80000000290d8067 PUD 75f25067 PMD 0 [ 111.391224] Oops: 0000 [#1] SMP PTI [ 111.392151] CPU: 0 PID: 3533 Comm: NFSv4 callback Not tainted 5.0.0-rc7+ #1 [ 111.393787] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015 [ 111.396340] RIP: 0010:trace_event_raw_event_xprt_enq_xmit+0x6f/0xf0 [sunrpc] [ 111.397974] Code: 00 00 00 48 89 ee 48 89 e7 e8 bd 0a 85 d7 48 85 c0 74 4a 41 0f b7 94 24 e0 00 00 00 48 89 e7 89 50 08 49 8b 94 24 a8 00 00 00 <8b> 52 04 89 50 0c 49 8b 94 24 c0 00 00 00 8b 92 a8 00 00 00 0f ca [ 111.402215] RSP: 0018:ffffb98743263cf8 EFLAGS: 00010286 [ 111.403406] RAX: ffffa0890fc3bc88 RBX: 0000000000000003 RCX: 0000000000000000 [ 111.405057] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffb98743263cf8 [ 111.406656] RBP: ffffa0896f5368f0 R08: 0000000000000246 R09: 0000000000000000 [ 111.408437] R10: ffffe19b01c01500 R11: 0000000000000000 R12: ffffa08977d28a00 [ 111.410210] R13: 0000000000000004 R14: ffffa089315303f0 R15: ffffa08931530000 [ 111.411856] FS: 0000000000000000(0000) GS:ffffa0897bc00000(0000) knlGS:0000000000000000 [ 111.413699] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 111.415068] CR2: 0000000000000004 CR3: 000000002ac90004 CR4: 00000000001606f0 [ 111.416745] Call Trace: [ 111.417339] xprt_request_enqueue_transmit+0x2b6/0x4a0 [sunrpc] [ 111.418709] ? rpc_task_need_encode+0x40/0x40 [sunrpc] [ 111.419957] call_bc_transmit+0xd5/0x170 [sunrpc] [ 111.421067] __rpc_execute+0x7e/0x3f0 [sunrpc] [ 111.422177] rpc_run_bc_task+0x78/0xd0 [sunrpc] [ 111.423212] bc_svc_process+0x281/0x340 [sunrpc] [ 111.424325] nfs41_callback_svc+0x130/0x1c0 [nfsv4] [ 111.425430] ? remove_wait_queue+0x60/0x60 [ 111.426398] kthread+0xf5/0x130 [ 111.427155] ? nfs_callback_authenticate+0x50/0x50 [nfsv4] [ 111.428388] ? kthread_bind+0x10/0x10 [ 111.429270] ret_from_fork+0x1f/0x30 localhost login: [ 467.462259] BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 [ 467.464411] #PF error: [normal kernel read fault] [ 467.465445] PGD 80000000728c1067 P4D 80000000728c1067 PUD 728c0067 PMD 0 [ 467.466980] Oops: 0000 [#1] SMP PTI [ 467.467759] CPU: 0 PID: 3517 Comm: NFSv4 callback Not tainted 5.0.0-rc7+ #1 [ 467.469393] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015 [ 467.471840] RIP: 0010:trace_event_raw_event_xprt_transmit+0x7c/0xf0 [sunrpc] [ 467.473392] Code: f6 48 85 c0 74 4b 49 8b 94 24 98 00 00 00 48 89 e7 0f b7 92 e0 00 00 00 89 50 08 49 8b 94 24 98 00 00 00 48 8b 92 a8 00 00 00 <8b> 52 04 89 50 0c 41 8b 94 24 a8 00 00 00 0f ca 89 50 10 41 8b 94 [ 467.477605] RSP: 0018:ffffabe7434fbcd0 EFLAGS: 00010282 [ 467.478793] RAX: ffff99720fc3bce0 RBX: 0000000000000003 RCX: 0000000000000000 [ 467.480409] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffabe7434fbcd0 [ 467.482011] RBP: ffff99726f631948 R08: 0000000000000246 R09: 0000000000000000 [ 467.483591] R10: 0000000070000000 R11: 0000000000000000 R12: ffff997277dfcc00 [ 467.485226] R13: 0000000000000000 R14: 0000000000000000 R15: ffff99722fecdca8 [ 467.486830] FS: 0000000000000000(0000) GS:ffff99727bc00000(0000) knlGS:0000000000000000 [ 467.488596] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 467.489931] CR2: 0000000000000004 CR3: 00000000270e6006 CR4: 00000000001606f0 [ 467.491559] Call Trace: [ 467.492128] xprt_transmit+0x303/0x3f0 [sunrpc] [ 467.493143] ? rpc_task_need_encode+0x40/0x40 [sunrpc] [ 467.494328] call_bc_transmit+0x49/0x170 [sunrpc] [ 467.495379] __rpc_execute+0x7e/0x3f0 [sunrpc] [ 467.496451] rpc_run_bc_task+0x78/0xd0 [sunrpc] [ 467.497467] bc_svc_process+0x281/0x340 [sunrpc] [ 467.498507] nfs41_callback_svc+0x130/0x1c0 [nfsv4] [ 467.499751] ? remove_wait_queue+0x60/0x60 [ 467.500686] kthread+0xf5/0x130 [ 467.501438] ? nfs_callback_authenticate+0x50/0x50 [nfsv4] [ 467.502640] ? kthread_bind+0x10/0x10 [ 467.503454] ret_from_fork+0x1f/0x30 Signed-off-by:
Olga Kornievskaia <kolga@netapp.com> Signed-off-by:
Trond Myklebust <trond.myklebust@hammerspace.com>
-
Ayan Kumar Halder authored
This new format is supported by DP550 and DP650 Changes since v3 (series): - Added the ack - Rebased on the latest drm-misc-next Signed-off-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io> Link: https://patchwork.freedesktop.org/patch/291758/?series=57895&rev=1
-
Brian Starkey authored
As we look to enable AFBC using DRM format modifiers, we run into problems which we've historically handled via vendor-private details (i.e. gralloc, on Android). AFBC (as an encoding) is fully flexible, and for example YUV data can be encoded into 1, 2 or 3 encoded "planes", much like the linear equivalents. Component order is also meaningful, as AFBC doesn't necessarily care about what each "channel" of the data it encodes contains. Therefore ABGR8888 and RGBA8888 can be encoded in AFBC with different representations. Similarly, 'X' components may be encoded into AFBC streams in cases where a decoder expects to decode a 4th component. In addition, AFBC is a licensable IP, meaning that to support the ecosystem we need to ensure that _all_ AFBC users are able to describe the encodings that they need. This is much better achieved by preserving meaning in the fourcc codes when they are combined with an AFBC modifier. In essence, we want to use the modifier to describe the parameters of the AFBC encode/decode, and use the fourcc code to describe the data being encoded/decoded. To do anything different would be to introduce redundancy - we would need to duplicate in the modifier information which is _already_ conveyed clearly and non-ambigiously by a fourcc code. I hope that for RGB this is non-controversial. (BGRA8888 + MODIFIER_AFBC) is a different format from (RGBA8888 + MODIFIER_AFBC). Possibly more controversial is that (XBGR8888 + MODIFIER_AFBC) is different from (BGR888 + MODIFIER_AFBC). I understand that in some schemes it is not the case - but in AFBC it is so. Where we run into problems is where there are not already fourcc codes which represent the data which the AFBC encoder/decoder is processing. To that end, we want to introduce new fourcc codes to describe the data being encoded/decoded, in the places where none of the existing fourcc codes are applicable. Where we don't support an equivalent non-compressed layout, or where no "obvious" linear layout exists, we are proposing adding fourcc codes which have no associated linear layout - because any layout we proposed would be completely arbitrary. Some formats are following the naming conventions from [2]. The summary of the new formats is: DRM_FORMAT_VUY888 - Packed 8-bit YUV 444. Y followed by U then V. DRM_FORMAT_VUY101010 - Packed 10-bit YUV 444. Y followed by U then V. No defined linear encoding. DRM_FORMAT_Y210 - Packed 10-bit YUV 422. Y followed by U (then Y) then V. 10-bit samples in 16-bit words. DRM_FORMAT_Y410 - Packed 10-bit YUV 444, with 2-bit alpha. DRM_FORMAT_P210 - Semi-planar 10-bit YUV 422. Y plane, followed by interleaved U-then-V plane. 10-bit samples in 16-bit words. DRM_FORMAT_YUV420_8BIT - Packed 8-bit YUV 420. Y followed by U then V. No defined linear encoding DRM_FORMAT_YUV420_10BIT - Packed 10-bit YUV 420. Y followed by U then V. No defined linear encoding Please also note that in the absence of AFBC, we would still need to add Y410, Y210 and P210. Full rationale follows: YUV 444 8-bit, 1-plane ---------------------- The currently defined AYUV format encodes a 4th alpha component, which makes it unsuitable for representing a 3-component YUV 444 AFBC stream. The proposed[1] XYUV format which is supported by Mali-DP in linear layout is also unsuitable, because the component order is the opposite of the AFBC version, and it encodes a 4th 'X' component. DRM_FORMAT_VUY888 is the "obvious" format for a 3-component, packed, YUV 444 8-bit format, with the component order which our HW expects to encode/decode. It conforms to the same naming convention as the existing packed YUV 444 format. The naming here is meant to be consistent with DRM_FORMAT_AYUV and DRM_FORMAT_XYUV[1] YUV 444 10-bit, 1-plane ----------------------- There is no currently-defined YUV 444 10-bit format in drm_fourcc.h, irrespective of number of planes. The proposed[1] XVYU2101010 format which is supported by Mali-DP in linear layout uses the wrong component order, and also encodes a 4th 'X' component, which doesn't match the AFBC version of YUV 444 10-bit which we support. DRM_FORMAT_Y410 is the same layout as XVYU2101010, but with 2 bits of alpha. This format is supported with linear layout by Mali GPUs. The naming follows[2]. There is no "obvious" linear encoding for a 3-component 10:10:10 packed format, and so DRM_FORMAT_VUY101010 defines a component order, but not a bit encoding. Again, the naming is meant to be consistent with DRM_FORMAT_AYUV. YUV 422 8-bit, 1-plane ---------------------- The existing DRM_FORMAT_YUYV (and the other component orders) are single-planar YUV 422 8-bit formats. Following the convention of the component orders of the RGB formats, YUYV has the correct component order for our AFBC encoding (Y followed by U followed by V). We can use YUYV for AFBC YUV 422 8-bit. YUV 422 10-bit, 1-plane ----------------------- There is no currently-defined YUV 422 10-bit format in drm_fourcc.h DRM_FORMAT_Y210 is analogous to YUYV, but with 10-bits per sample packed into the upper 10-bits of 16-bit samples. This format is supported in both linear and AFBC by Mali GPUs. YUV 422 10-bit, 2-plane ----------------------- The recently defined DRM_FORMAT_P010 format is a 10-bit semi-planar YUV 420 format, which has the correct component ordering for an AFBC 2-plane YUV 420 buffer. The linear layout contains meaningless padding bits, which will not be encoded in an AFBC stream. YUV 420 8-bit, 1-plane ---------------------- There is no currently defined single-planar YUV 420, 8-bit format in drm_fourcc.h. There's differing opinions on whether using the existing fourcc-implied n_planes where possible is a good idea or not when using modifiers. For me, it's much more "obvious" to use NV12 for 2-plane AFBC and YUV420 for 3-plane AFBC. This keeps the aforementioned separation between the AFBC codec settings (in the modifier) and the pixel data format (in the fourcc). With different vendors using AFBC, this helps to ensure that there is no confusion in interoperation. It also ensures that the AFBC modifiers describe AFBC itself (which is a licensable component), and not implementation details which are not defined by AFBC. The proposed[1] X0L0 format which Mali-DP supports with Linear layout is unsuitable, as it contains a 4th 'X' component, and our AFBC decoder expects only 3 components. To that end, we propose a new YUV 420 8-bit format. There is no "obvious" linear encoding for a 3-component 8:8:8, 420, packed format, and so DRM_FORMAT_YUV420_8BIT defines a component order, but not a bit encoding. I'm happy to hear different naming suggestions. YUV 420 8-bit, 2-, 3-plane -------------------------- These already exist, we can use NV12 and YUV420. YUV 420 10-bit, 1-plane ----------------------- As above, no current definition exists, and X0L2 encodes a 4th 'X' channel. Analogous to DRM_FORMAT_YUV420_8BIT, we define DRM_FORMAT_YUV420_10BIT. [1] https://lists.freedesktop.org/archives/dri-devel/2018-July/184598.html [2] https://docs.microsoft.com/en-us/windows/desktop/medfound/10-bit-and-16-bit-yuv-video-formats Changes since RFC v1: - Fix confusing subsampling vs bit-depth X:X:X notation in descriptions (danvet) - Rename DRM_FORMAT_AVYU1101010 to DRM_FORMAT_Y410 (Lisa Wu) - Add drm_format_info structures for the new formats, using the new 'bpp' field for those with non-integer bytes-per-pixel - Rebase, including Juha-Pekka Heikkila's format definitions Changes since RFC v2: - Rebase on top of latest changes in drm-misc-next - Change the description of DRM_FORMAT_P210 in __drm_format_info and drm_fourcc.h so as to make it consistent with other DRM_FORMAT_PXXX formats. Changes since v3: - Added the ack - Rebased on the latest drm-misc-next Signed-off-by: -
Kent Overstreet authored
All existing users have been converted to generic radix trees Link: http://lkml.kernel.org/r/20181217131929.11727-8-kent.overstreet@gmail.com Signed-off-by:
Kent Overstreet <kent.overstreet@gmail.com> Acked-by:
Dave Hansen <dave.hansen@intel.com> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Eric Paris <eparis@parisplace.org> Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Neil Horman <nhorman@tuxdriver.com> Cc: Paul Moore <paul@paul-moore.com> Cc: Pravin B Shelar <pshelar@ovn.org> Cc: Shaohua Li <shli@kernel.org> Cc: Stephen Smalley <sds@tycho.nsa.gov> Cc: Vlad Yasevich <vyasevich@gmail.com> Signed-off-by:
-
Kent Overstreet authored
This also makes sctp_stream_alloc_(out|in) saner, in that they no longer allocate new flex_arrays/genradixes, they just preallocate more elements. This code does however have a suspicious lack of locking. Link: http://lkml.kernel.org/r/20181217131929.11727-7-kent.overstreet@gmail.com Signed-off-by:
-
Kent Overstreet authored
Very simple radix tree implementation that supports storing arbitrary size entries, up to PAGE_SIZE - upcoming patches will convert existing flex_array users to genradixes. The new genradix code has a much simpler API and implementation, and doesn't have a hard limit on the number of elements like flex_array does. Link: http://lkml.kernel.org/r/20181217131929.11727-5-kent.overstreet@gmail.com Signed-off-by:
-
