Reviewed-by: Evan Quan
> -Original Message-
> From: Chen Wandun
> Sent: Monday, November 18, 2019 4:04 PM
> To: Quan, Evan ; Deucher, Alexander
> ; amd-...@lists.freedesktop.org; linux-
> ker...@vger.kernel.org; dri-devel@lists.freedesktop.org
> Cc: chenwan...@huawei.com
> Subject: [PATC
program_hpd_filter() currently fails to check for the errors
returned in construct(). This patch returns error in
case of failure.
Signed-off-by: Aditya Pakki
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/a
Some A3xx and all A4xx Adreno GPUs do not have GMEM inside the GPU core
and must use the On Chip MEMory (OCMEM) in order to be functional.
There's a separate interconnect path that needs to be setup to OCMEM.
Let's document this second interconnect path that's available.
Signed-off-by: Brian Masne
The driver forgets to call pm_runtime_disable in probe failure
and remove.
Add the missed calls to fix it.
Signed-off-by: Chuhong Yuan
---
drivers/gpu/drm/v3d/v3d_drv.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
index 3506
This driver forgets to call pm_runtime_disable and clk_disable_unprepare
in remove.
Add the calls to fix it.
Signed-off-by: Chuhong Yuan
---
Changes in v2:
- Add the missed pm_runtime_disable.
drivers/gpu/ipu-v3/ipu-prg.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/ipu-
Commit 8c0d3a02c130 ("PCI: Add accessors for PCI Express Capability")
added accessors for the PCI Express Capability so that drivers didn't
need to be aware of differences between v1 and v2 of the PCI
Express Capability.
Replace pci_read_config_word() and pci_write_config_word() calls with
pcie_ca
Hi,
> Am 17.11.2019 um 03:40 schrieb Sebastian Reichel
> :
>
> This converts the DSI module to expect common drm_panel display
> drivers instead of dssdev based ones.
>
> This commit is WIP. We somehow need to know the panels resolution
> in omap_dsi_host_attach(), so that we can properly confi
Some A3xx and all A4xx Adreno GPUs do not have GMEM inside the GPU core
and must use the On Chip MEMory (OCMEM) in order to be functional.
There's a separate interconnect path that needs to be setup to OCMEM.
Add support for this second path to the GPU core.
In the downstream MSM 3.4 sources, the
Set the two interconnect paths for the GPU to maximum speed for now to
work towards getting the GPU working upstream. We can revisit a later
time to optimize this for battery life.
Signed-off-by: Brian Masney
---
drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 8
1 file changed, 8 insertions(+)
Some A3xx and all A4xx Adreno GPUs do not have GMEM inside the GPU core
and must use the On Chip MEMory (OCMEM) in order to be functional.
There's a separate interconnect path that needs to be setup to OCMEM.
This patch series adds support for that path, and sets the votes for the
two interconnect
return errno code to caller when error occur, and meanwhile
remove gcc '-Wunused-but-set-variable' warning.
drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c: In function
vegam_populate_smc_boot_level:
drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:1364:6: warning:
var
OK, it indeed should return the 'result' to caller,
I will make a modification and repost the patch.
Thanks
Chen Wandun
On 2019/11/18 14:50, Quan, Evan wrote:
Thanks. But it's better to return the 'result' out on 'result != 0'.
Regards,
Evan
-Original Message-
From: Chen Wandun
Sent:
Set the two interconnect paths for the GPU to maximum speed for now to
work towards getting the GPU working upstream. We can revisit a later
time to optimize this for battery life.
Signed-off-by: Brian Masney
---
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 8
1 file changed, 8 insertions(+)
The driver calls register_framebuffer in probe but does not call
unregister_framebuffer in remove.
Add the missed call to fix it.
Signed-off-by: Chuhong Yuan
---
drivers/video/fbdev/s1d13xxxfb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/fbdev/s1d13xxxfb.c b/drivers/video/
The mtk_drm_ddp_comp_for_plane can return NULL, but the usage doesn't
check for it. Add check for it.
Fixes: d6b53f68356f ("drm/mediatek: Add helper to get component for a plane")
Signed-off-by: Pi-Hsun Shih
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 13 +
1 file changed, 9 insert
On Mon, Nov 18, 2019 at 07:09:56AM +, james qian wang (Arm Technology
China) wrote:
> On Thu, Nov 14, 2019 at 11:12:13AM +0100, Daniel Vetter wrote:
> > On Thu, Nov 14, 2019 at 2:52 AM james qian wang (Arm Technology China)
> > wrote:
> > > On Wed, Nov 13, 2019 at 12:39:54PM +0100, Daniel Vet
On Sat, Nov 16, 2019 at 07:04:28PM +0800, zhengbin wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/gma500/cdv_intel_dp.c: In function
> cdv_intel_dp_complete_link_train:
> drivers/gpu/drm/gma500/cdv_intel_dp.c:1596:7: warning: variable channel_eq
> set but not used [-
[Why]
HDMI 2.0 adds aspect ratio attribute to distinguish different
4k modes. According to Appendix E of HDMI 2.0 spec, source should
use VSIF to indicate video mode only when the mode is one defined
in HDMI 1.4b 4K modes. Otherwise, use AVI infoframes to convey VIC.
Current code doesn't take aspe
[Why]
In hdmi_mode_alternate_clock(), it adds an exception for VIC 4
mode (4096x2160@24) due to there is no alternate clock defined for
that mode in HDMI1.4b. But HDMI2.0 adds 23.98Hz for that mode.
[How]
Remove the exception
v2: Adjust the comment description of hdmi_mode_alternate_clock()
due t
There's no callers in-tree anymore.
For merging probably best to stuff this into drm-misc, since that's
where the dma-buf heaps will land too. And the resulting conflict
hopefully ensures that dma-buf heaps wont have a new ->kmap/unmap
implemenation.
Signed-off-by: Daniel Vetter
Cc: Laura Abbott
Hi all,
Way back when we created the dma-buf spec it made sense to have kmap/unmap
interfaces, since 32bit kernels with limited vmalloc space were still
rather ubiquitous. But that idea (like many others) never caught on, was
quickly replaced by vmaps covering the entire buffer for all real uses,
A few reasons to drop kmap:
- For native objects all we do is look at obj->vaddr anyway, so might
as well not call functions for every page.
- Reloc-processing on dma-buf is ... questionable.
- Plus most dma-buf that bother kernel cpu mmaps give you at least
vmap, much less kmaps. And all th
All implementations are gone now.
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
include/linux/dma-buf.h | 25 -
1 file changed, 25 deletions(-)
diff --git a/include/linux/dma-buf.h b/include/linux/dm
There's no in-tree users anymore.
Signed-off-by: Daniel Vetter
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Jens Wiklander
Cc: tee-...@lists.linaro.org
--
Ack for merging this through drm trees very much appreciated.
-Daniel
---
drivers/misc/fastrpc.c | 8
drivers/tee/tee_shm.c | 6
No in-tree users left.
Signed-off-by: Daniel Vetter
Cc: Thierry Reding
Cc: Jonathan Hunter
Cc: linux-te...@vger.kernel.org
---
drivers/gpu/drm/tegra/gem.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 662cb7c87e
It's unused.
10 years ago, back when 32bit was still fairly common and trying to
not exhaust vmalloc space sounded like a worthwhile goal, adding these
to dma_buf made sense.
Reality is that they simply never caught on, and nowadays everyone who
needs plenty of buffers will run in 64bit mode anyw
It doesn't have any callers anymore.
Aside: The ->mmap/munmap hooks have a bit a confusing name, they don't
do userspace mmaps, but a kernel vmap. I think most places use vmap
for this, except ttm, which uses kmap for vmap for added confusion.
mmap seems entirely for userspace mappings set up thro
No in-tree users left.
Signed-off-by: Daniel Vetter
Cc: Kirti Wankhede
Cc: k...@vger.kernel.org
--
Ack for merging this through drm trees very much appreciated.
-Daniel
---
samples/vfio-mdev/mbochs.c | 16
1 file changed, 16 deletions(-)
diff --git a/samples/vfio-mdev/mbochs.c
No in-tree users left.
Aside, I think mock_dmabuf would be a nice addition to drm
mock/selftest helpers (we have some already), with an
EXPORT_SYMBOL_FOR_TESTS_ONLY.
Signed-off-by: Daniel Vetter
Cc: Chris Wilson
Cc: Matthew Auld
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Sam Ravnborg
Cc: "Christ
It's a dummy anyway.
Signed-off-by: Daniel Vetter
Cc: Russell King
---
drivers/gpu/drm/armada/armada_gem.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_gem.c
b/drivers/gpu/drm/armada/armada_gem.c
index 93cf8b8bfcff..976685f2939e 100644
--- a/dr
There's no in-kernel users for the k(un)map stuff. And the mmap one is
actively harmful - return 0 and then _not_ actually mmaping can't end
well.
Signed-off-by: Daniel Vetter
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: xen-de...@lists.xenproject.org
--
Ack for merging thi
It's the only user left in the entire kernel for dma_buf_kmap/_kunmap.
Delete it, before we start garbage-collecting the various
implementations.
Signed-off-by: Daniel Vetter
Cc: Chris Wilson
Cc: Matthew Auld
Cc: Daniel Vetter
Cc: Mika Kuoppala
Cc: Dave Airlie
---
.../drm/i915/gem/selftests
No in-tree users left.
Signed-off-by: Daniel Vetter
Cc: Pawel Osciak
Cc: Marek Szyprowski
Cc: Kyungmin Park
Cc: Tomasz Figa
Cc: linux-me...@vger.kernel.org
--
Ack for merging this through drm trees very much appreciated.
-Daniel
---
drivers/media/common/videobuf2/videobuf2-dma-contig.c | 8 -
No in-tree users left.
Note that this is one of the few (if only) implementations of dma-buf
that provided a kmap, but not a vmap implemenation. Given that the
only real user (in-tree at least) of kmap was tegra, and it's
impossible to buy a chip with tegra host1x and ompadrm on the same
SoC, ther
No need for stubs, dma-buf.c takes care of that.
Aside, not having a ->release callback smelled like refcounting leak
somewhere. It will also score you a WARN_ON backtrace in dma-buf.c on
every export. But then I found that ttm_device_object_init overwrites
it. Overwriting const memory is not goin
On Fri, Nov 15, 2019 at 03:52:36PM -0500, Sean Paul wrote:
> Cc: Dave Airlie
> Cc: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Signed-off-by: Sean Paul
> ---
>
> I need to step away from -misc to prioritize other work that I have on
> my plate. It's been great fun (most of the
Hi,
> > > > Is any move buffer good enough to trigger this, i.e. will SYSTEM -> VRAM
> > > > work too? That'll be easier because all I need to do is map the buffer
> > > > to a crtc to force pinning to vram, then check if the mappings are
> > > > intact still ...
> > >
> > > I think that should
On 2019/11/18 下午2:16, Jason Wang wrote:
Hi all:
There are hardwares that can do virtio datapath offloading while
having its own control path. This path tries to implement a mdev based
unified API to support using kernel virtio driver to drive those
devices. This is done by introducing a new mde
On Mon, Nov 18, 2019 at 02:17:02PM +0800, Jason Wang wrote:
> This patch introduces a new mdev transport for virtio. This is used to
> use kernel virtio driver to drive the mediated device that is capable
> of populating virtqueue directly.
>
> A new virtio-mdev driver will be registered to the md
On 11/18/19 12:35 PM, Daniel Vetter wrote:
There's no in-kernel users for the k(un)map stuff. And the mmap one is
actively harmful - return 0 and then _not_ actually mmaping can't end
well.
Signed-off-by: Daniel Vetter
Reviewed-by: Oleksandr Andrushchenko
Cc: Boris Ostrovsky
Cc: Juergen Gro
On 18.11.19 11:35, Daniel Vetter wrote:
There's no in-kernel users for the k(un)map stuff. And the mmap one is
actively harmful - return 0 and then _not_ actually mmaping can't end
well.
Signed-off-by: Daniel Vetter
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: xen-de...@l
On 2019/11/18 下午6:44, Michael S. Tsirkin wrote:
+static const struct mdev_virtio_class_id virtio_id_table[] = {
+ { MDEV_VIRTIO_CLASS_ID_VIRTIO },
+ { 0 },
+};
+
Do we still need the class ID? It's a virtio mdev bus,
do we need a virtio class as well?
If we want to have auto matc
On 18.11.2019 11:35, Daniel Vetter wrote:
> No in-tree users left.
>
> Signed-off-by: Daniel Vetter
> Cc: Pawel Osciak
> Cc: Marek Szyprowski
> Cc: Kyungmin Park
> Cc: Tomasz Figa
> Cc: linux-me...@vger.kernel.org
Acked-by: Marek Szyprowski
> --
> Ack for merging this through drm trees ver
Hi all:
There are hardwares that can do virtio datapath offloading while
having its own control path. This path tries to implement a mdev based
unified API to support using kernel virtio driver to drive those
devices. This is done by introducing a new mdev transport for virtio
(virtio_mdev) and re
Current mdev is tied to a VFIO specific "mdev" bus. This prevent mdev
from being used by other types of API/buses. So this patch tries to make
mdev bus agnostic through making a mdev core a thin module:
- decouple VFIO bus specific bits from mdev_core.c to mdev_vfio.c and
introduce mdev_vfio mod
Mdev now is nothing VFIO specific, let's move it to upper
directory.
Signed-off-by: Jason Wang
---
MAINTAINERS | 7 +--
drivers/Kconfig | 2 ++
drivers/Makefile | 1 +
drivers/mdev/Kconfig
The only thing left for generalizing mdev is the VFIO specific parent
ops. This is basically the open/release/read/write/ioctl/mmap.
To support this, mdev core is extend to support a specific size
of structure during create, this will allow to compose mdev structure
into mdev vfio structure and pl
On 11/18/19 11:35 AM, Daniel Vetter wrote:
> No in-tree users left.
>
> Signed-off-by: Daniel Vetter
Acked-by: Hans Verkuil
Thanks!
Hans
> Cc: Pawel Osciak
> Cc: Marek Szyprowski
> Cc: Kyungmin Park
> Cc: Tomasz Figa
> Cc: linux-me...@vger.kernel.org
> --
> Ack for merging this t
This patch implements a mediated virtio bus over mdev framework. This
will be used by the future virtio-mdev and vhost-mdev on top to allow
driver from either userspace or kernel to control the device which is
capable of offloading virtio datapath.
Signed-off-by: Jason Wang
---
MAINTAINERS
This patch introduces a new mdev transport for virtio. This is used to
use kernel virtio driver to drive the mediated device that is capable
of populating virtqueue directly.
A new virtio-mdev driver will be registered to the mdev bus, when a
new virtio-mdev device is probed, it will register the
This sample driver creates mdev device that simulate virtio net device
over virtio mdev transport. The device is implemented through vringh
and workqueue. A device specific dma ops is to make sure HVA is used
directly as the IOVA. This should be sufficient for kernel virtio
driver to work.
Only 'v
On Mon, Nov 18, 2019 at 11:35:33AM +0100, Daniel Vetter wrote:
> There's no in-tree users anymore.
>
> Signed-off-by: Daniel Vetter
> Cc: Arnd Bergmann
> Cc: Greg Kroah-Hartman
> Cc: Jens Wiklander
> Cc: tee-...@lists.linaro.org
> --
> Ack for merging this through drm trees very much appreciat
On Mon, Nov 18, 2019 at 11:35:25AM +0100, Daniel Vetter wrote:
> There's no callers in-tree anymore.
>
> For merging probably best to stuff this into drm-misc, since that's
> where the dma-buf heaps will land too. And the resulting conflict
> hopefully ensures that dma-buf heaps wont have a new ->
Am 18.11.19 um 11:35 schrieb Daniel Vetter:
No in-tree users left.
Good to know, thanks.
Aside, I think mock_dmabuf would be a nice addition to drm
mock/selftest helpers (we have some already), with an
EXPORT_SYMBOL_FOR_TESTS_ONLY.
Signed-off-by: Daniel Vetter
Cc: Chris Wilson
Cc: Matthew
On Mon, Nov 18, 2019 at 11:35:35AM +0100, Daniel Vetter wrote:
> No in-tree users left.
>
> Signed-off-by: Daniel Vetter
> Cc: Kirti Wankhede
> Cc: k...@vger.kernel.org
> --
> Ack for merging this through drm trees very much appreciated.
> -Daniel
Acked-by: Gerd Hoffmann
cheers,
Gerd
_
On Thu 14-11-19 21:53:33, John Hubbard wrote:
> Add tracking of pages that were pinned via FOLL_PIN.
>
> As mentioned in the FOLL_PIN documentation, callers who effectively set
> FOLL_PIN are required to ultimately free such pages via put_user_page().
> The effect is similar to FOLL_GET, and may b
On Thu 14-11-19 21:53:31, John Hubbard wrote:
> Convert fs/io_uring to use the new pin_user_pages() call, which sets
> FOLL_PIN. Setting FOLL_PIN is now required for code that requires
> tracking of pinned pages, and therefore for any code that calls
> put_user_page().
>
> In partial anticipation
On Thu 14-11-19 21:53:26, John Hubbard wrote:
> /*
> - * NOTE on FOLL_LONGTERM:
> + * FOLL_PIN and FOLL_LONGTERM may be used in various combinations with each
> + * other. Here is what they mean, and how to use them:
> *
> * FOLL_LONGTERM indicates that the page will be held for an indefinite
On Thu 14-11-19 21:53:18, John Hubbard wrote:
> There are four locations in gup.c that have a fair amount of code
> duplication. This means that changing one requires making the same
> changes in four places, not to mention reading the same code four
> times, and wondering if there are subtle diffe
On Thu 14-11-19 21:53:27, John Hubbard wrote:
> 1. Call the new global pin_user_pages_fast(), from pin_goldfish_pages().
>
> 2. As required by pin_user_pages(), release these pages via
> put_user_page(). In this case, do so via put_user_pages_dirty_lock().
>
> That has the side effect of calling
On Thu 14-11-19 21:53:29, John Hubbard wrote:
> Convert process_vm_access to use the new pin_user_pages_remote()
> call, which sets FOLL_PIN. Setting FOLL_PIN is now required for
> code that requires tracking of pinned pages.
>
> Also, release the pages via put_user_page*().
>
> Also, rename "pag
On Thu 14-11-19 21:53:22, John Hubbard wrote:
> 1. Avoid naming conflicts: rename local static function from
> "pin_user_pages()" to "pin_goldfish_pages()".
>
> An upcoming patch will introduce a global pin_user_pages()
> function.
>
> Reviewed-by: Jérôme Glisse
> Reviewed-by: Ira Weiny
> Signe
On Thu 14-11-19 21:53:23, John Hubbard wrote:
> And get rid of the mmap_sem calls, as part of that. Note
> that get_user_pages_fast() will, if necessary, fall back to
> __gup_longterm_unlocked(), which takes the mmap_sem as needed.
>
> Reviewed-by: Jason Gunthorpe
> Reviewed-by: Ira Weiny
> Sign
Hi zhengbin,
On 18/11/2019 14:07, zhengbin wrote:
zhengbin (4):
drm/omap: dss: Use PTR_ERR_OR_ZERO() to simplify code in
hdmi_audio_register
drm/omap: dss: Use PTR_ERR_OR_ZERO() to simplify code in
hdmi4_core_init
drm/omap: dss: Use PTR_ERR_OR_ZERO() to simplify code in
h
On Wed, Nov 13, 2019 at 05:44:34PM +0100, Hans de Goede wrote:
> If the new video=... panel_orientation option is set for a connector, honor
> it and setup a matching "panel orientation" property on the connector.
>
> BugLink: https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/83
> Sig
On Wed, Nov 13, 2019 at 05:44:31PM +0100, Hans de Goede wrote:
> fb_get_options() will return fb_mode_option if no video=
> argument is present on the kernel commandline, so there is no need to also
> do this in drm_mode_parse_command_line_for_connector() as our only caller
> uses fb_get_options()
On Wed, Nov 13, 2019 at 05:44:30PM +0100, Hans de Goede wrote:
> Sometimes we want to override a connector's panel_orientation from the
> kernel commandline. Either for testing and for special cases, e.g. a kiosk
> like setup which uses a TV mounted in portrait mode.
>
> Users can already specify a
On Wed, Nov 13, 2019 at 05:44:32PM +0100, Hans de Goede wrote:
> Instead of only setting mode->specified on false on an early exit and
> leaving e.g. mode->bpp_specified and mode->refresh_specified as is,
> lets be consistent and just zero out the entire passed in struct at
> the top of drm_mode_pa
Hi,
On 18-11-2019 13:28, Maxime Ripard wrote:
On Wed, Nov 13, 2019 at 05:44:32PM +0100, Hans de Goede wrote:
Instead of only setting mode->specified on false on an early exit and
leaving e.g. mode->bpp_specified and mode->refresh_specified as is,
lets be consistent and just zero out the entire
On 18/11/2019 12:35, Daniel Vetter wrote:
> No in-tree users left.
>
> Note that this is one of the few (if only) implementations of dma-buf
> that provided a kmap, but not a vmap implemenation. Given that the
> only real user (in-tree at least) of kmap was tegra, and it's
> impossible to buy a ch
Quoting Daniel Vetter (2019-11-18 10:35:27)
> No in-tree users left.
Fair enough then,
Reviewed-by: Chris Wilson
> Aside, I think mock_dmabuf would be a nice addition to drm
> mock/selftest helpers (we have some already), with an
> EXPORT_SYMBOL_FOR_TESTS_ONLY.
We've also started on some dmabuf
On Mon, Nov 18, 2019 at 01:33:55PM +0100, Hans de Goede wrote:
> Hi,
>
> On 18-11-2019 13:28, Maxime Ripard wrote:
> > On Wed, Nov 13, 2019 at 05:44:32PM +0100, Hans de Goede wrote:
> > > Instead of only setting mode->specified on false on an early exit and
> > > leaving e.g. mode->bpp_specified an
Quoting Daniel Vetter (2019-11-18 10:35:24)
> It's the only user left in the entire kernel for dma_buf_kmap/_kunmap.
> Delete it, before we start garbage-collecting the various
> implementations.
Ok then, I'm still mourning the loss of kmap. I definitely do not think
we should _only_ have a whole-
On Mon, Nov 18, 2019 at 08:34:40PM +0800, zhengbin wrote:
> Fixes coccicheck warning:
>
> drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c:281:1-3: WARNING: PTR_ERR_OR_ZERO can
> be used
>
> Reported-by: Hulk Robot
> Signed-off-by: zhengbin
> ---
> drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c | 5 +
> 1 fi
The "panel" pointer is not reset to NULL if of_drm_find_panel()
returns an error. Therefore we later assume that a panel was found,
and try to dereference the error pointer, resulting in:
mcde-dsi a0351000.dsi: failed to find panel try bridge (4294966779)
Unable to handle kernel paging req
On 17/11/2019 04:39, Sebastian Reichel wrote:
The standard binding for DSI requires, that the channel number
of the panel is encoded in DT. This adds the channel number in
all OMAP3-5 boards, in preparation for using common infrastructure.
Signed-off-by: Sebastian Reichel
---
.../devicetree/b
On Mon, Nov 18, 2019 at 07:46:10PM +0800, zhengbin wrote:
> zhengbin (2):
> drm/tegra: Use PTR_ERR_OR_ZERO() to simplify code in
> tegra_bo_dumb_create
> drm/tegra: Use PTR_ERR_OR_ZERO() to simplify code in tegra_gem_create
>
> drivers/gpu/drm/tegra/drm.c | 5 +
> drivers/gpu/drm/tegr
On Fri, Nov 15, 2019 at 04:07:19PM -0500, Lyude Paul wrote:
> In order to be able to use bpc values that are different from what the
> connector reports, we want to be able to store the bpc value we decide
> on using for an atomic state in nv50_head_atom and refer to that instead
> of simply using
On Fri, Nov 15, 2019 at 04:07:20PM -0500, Lyude Paul wrote:
> Noticed this while working on some unrelated CRC stuff. Currently,
> userspace has very little support for BPCs higher than 8. While this
> doesn't matter for most things, on MST topologies we need to be careful
> about ensuring that we
On Fri, Nov 15, 2019 at 04:07:18PM -0500, Lyude Paul wrote:
> Since nv50_outp_atomic_check_view() can set crtc_state->mode_changed, we
> probably should be calling it before handling any PBN changes. Just a
> precaution.
>
> Signed-off-by: Lyude Paul
> Fixes: 232c9eec417a ("drm/nouveau: Use atomi
On Sat, Nov 02, 2019 at 06:56:28PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Hi Ben,
>
> here's a revised subset of the patches I had sent out a couple of weeks
> ago. I've reworked the BAR2 accesses in the way that you had suggested,
> which at least for GP10B turned out to be fai
Hi,
On 18-11-2019 13:28, Maxime Ripard wrote:
On Wed, Nov 13, 2019 at 05:44:32PM +0100, Hans de Goede wrote:
Instead of only setting mode->specified on false on an early exit and
leaving e.g. mode->bpp_specified and mode->refresh_specified as is,
lets be consistent and just zero out the entire
On 11/18/19 5:35 AM, Daniel Vetter wrote:
There's no callers in-tree anymore.
For merging probably best to stuff this into drm-misc, since that's
where the dma-buf heaps will land too. And the resulting conflict
hopefully ensures that dma-buf heaps wont have a new ->kmap/unmap
implemenation.
Si
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #236 from Alex Deucher ---
(In reply to Marko Popovic from comment #235)
> (In reply to Alex Deucher from comment #233)
> > Does attachment 145971 [details] [review] [review] help?
>
> No, this is for flip hangs that only happen in
https://bugzilla.kernel.org/show_bug.cgi?id=205497
--- Comment #19 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to Luya Tshimbalanga from comment #18)
> Reading another bug report on
> https://bugzilla.kernel.org/show_bug.cgi?id=204689 taken from amdgfx mailing
> list, could that issue
On Mon, Nov 18, 2019 at 06:59:23PM +0800, Jason Wang wrote:
> +static void mvnet_device_release(struct device *dev)
> +{
> + dev_dbg(dev, "mvnet: released\n");
> +}
We used to have documentation in the kernel source tree that said that
whenever anyone did this, I got to make fun of them. Unfo
https://bugs.freedesktop.org/show_bug.cgi?id=112303
--- Comment #1 from Alex Deucher ---
Does it work with kernel 5.4? There were several fixes for resume that were
added (which will be making their way back to stable kernels).
--
You are receiving this mail because:
You are the assignee for t
On Fri, Nov 15, 2019 at 1:34 PM Ville Syrjälä
wrote:
>
> On Thu, Nov 14, 2019 at 08:01:32PM +, co...@sdf.org wrote:
> > Hi Daniel,
> >
> > I don't think we can make any complaints about GPL being more widely
> > used in the DRM code. It's nice to have the code at all, the MIT license
> > is a
-base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/Retire-dma_buf_k-un-map/20191118-184537
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: m68k-al
atest linux-next tree, next-20191118.
v2 -> v3:
* Added const declarations to dw-mipi-dsi.c structs (Emil)
* Fixed Reviewed-by tags and cc'd some more relevant ML (Emil)
v1 -> v2:
* Moved register definitions & regmap initialization into bridge
module. Platform drivers get the
Register existence, address/offsets, field layouts, reserved bits and
so on differ between MIPI-DSI versions and between SoC vendor boards.
Despite these differences the hw IP and protocols are mostly the same
so the generic driver can be made to compensate these differences.
The current Rockchip
This adds support for the Synopsis DesignWare MIPI DSI v1.01 host
controller which is embedded in i.MX 6 SoCs.
Based on following patches, but updated/extended to work with existing
support found in the kernel:
- drm: imx: Support Synopsys DesignWare MIPI DSI host controller
Signed-off-by: Liu
Convert the common bridge code and the two rockchip & stm drivers
which currently use it to the regmap API in anticipation for further
changes to make it more generic and add older DSI host controller
support as found on i.mx6 based devices.
The regmap becomes an internal state of the bridge. No f
Signed-off-by: Sjoerd Simons
Signed-off-by: Martyn Welch
Signed-off-by: Adrian Ratiu
---
.../bindings/display/imx/mipi-dsi.txt | 56 +++
1 file changed, 56 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/imx/mipi-dsi.txt
diff --git a/Document
On Mon, 18 Nov 2019 18:59:23 +0800
Jason Wang wrote:
[Note: I have not looked into the reworked architecture of this *at all*
so far; just something that I noted...]
> This sample driver creates mdev device that simulate virtio net device
> over virtio mdev transport. The device is implemented t
Some options which can be specified on the commandline, such as
margin_right=..., margin_left=..., etc. are applied not only to the
specified mode, but to all modes. As such it would be nice if the user
can simply say e.g.
video=HDMI-1:margin_right=14,margin_left=24,margin_bottom=36,margin_top=42
drm_connector_get_cmdline_mode() calls
drm_mode_parse_command_line_for_connector() with &connector->cmdline_mode
as mode argument, so anything which we store in the mode arguments gets
kept even if we return false.
Avoid storing a possibly false-postive bpp/refresh_specified setting
in connector->
Before this commit it was impossible to combine an extra mode argument
specified directly after the resolution with an option, e.g.
video=HDMI-1:720x480e,rotate=180 would not work, either the "e" to force
enable would need to be dropped or the ",rotate=180", otherwise the
mode_option would not be a
Add a freestanding function argument to drm_mode_parse_cmdline_options()
similar to how drm_mode_parse_cmdline_extra() already has this.
This is a preparation patch for allowing parsing of stand-alone options
without a mode before them, e.g.: video=HDMI-1:margin_right=14,...
Acked-by: Maxime Ripa
We are not supposed to modify the passed in string, make char pointers
used in drm_mode_parse_cmdline_options() const char * where possible.
Acked-by: Maxime Ripard
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_modes.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
dif
1 - 100 of 205 matches
Mail list logo
