Re: linux-next: manual merge of the drm-misc tree with Linus' tree
On Thu, May 23, 2019 at 11:10:39AM -0500, Rob Herring wrote:
> On Thu, May 23, 2019 at 6:54 AM Maxime Ripard
> wrote:
> >
> > On Tue, May 21, 2019 at 10:51:51AM +1000, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > Today's linux-next merge of the drm-misc tree got a conflict in:
> > >
> > > Documentation/devicetree/bindings/vendor-prefixes.txt
> > >
> > > between commit:
> > >
> > > 8122de54602e ("dt-bindings: Convert vendor prefixes to json-schema")
> > >
> > > from Linus' tree and commits:
> > >
> > > b4a2c0055a4f ("dt-bindings: Add vendor prefix for VXT Ltd")
> > > b1b0d36bdb15 ("dt-bindings: drm/panel: simple: Add binding for TFC
> > > S9700RTWV43TR-01B")
> > > fbd8b69ab616 ("dt-bindings: Add vendor prefix for Evervision
> > > Electronics")
> > >
> > > from the drm-misc tree.
> > >
> > > I fixed it up (I deleted the file and added the patch below) and can
> > > carry the fix as necessary. This is now fixed as far as linux-next is
> > > concerned, but any non trivial conflicts should be mentioned to your
> > > upstream maintainer when your tree is submitted for merging. You may
> > > also want to consider cooperating with the maintainer of the conflicting
> > > tree to minimise any particularly complex conflicts.
> >
> > I just took your patch and pushed a temp branch there:
> > https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/commit/?h=drm-misc-next&id=3832f2cad5307ebcedeead13fbd8d3cf06ba5e90
> >
> > Rob, Stephen, are you ok with the change? If so, I'll push it.
>
> The 'tfc' line is missing a ':' on the end.
That's on me, sorry.
> Does the file pass dt_binding_check like that?
No, it didn't but I overlooked it somehow. I've pushed that patch with
the extra semi-column.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Maintain consistent documentation subsection ordering
On Thu, 23 May 2019, Jonathan Corbet wrote: > With Sphinx 2.0 (or prior versions with the deprecation warnings fixed) the > docs build fails with: > > Documentation/gpu/i915.rst:403: WARNING: Title level inconsistent: > > Global GTT Fence Handling > ~ > > reST markup error: > Documentation/gpu/i915.rst:403: (SEVERE/4) Title level inconsistent: > > I "fixed" it by changing the subsections in i915.rst, but that didn't seem > like the correct change. It turns out that a couple of i915 files create > their own subsections in kerneldoc comments using apostrophes as the > heading marker: > > Layout > '' > > That breaks the normal subsection marker ordering, and newer Sphinx is > rather more strict about enforcing that ordering. So fix the offending > comments to make Sphinx happy. > > (This is unfortunate, in that kerneldoc comments shouldn't need to be aware > of where they might be included in the heading hierarchy, but I don't see > a better way around it). > > Signed-off-by: Jonathan Corbet > --- > [If I can possibly get an ack for this, I would like to send it up soon > with the other Sphinx-related fixes.] Thanks, whatever works, Acked-by: Jani Nikula > > drivers/gpu/drm/i915/i915_reg.h | 6 +++--- > drivers/gpu/drm/i915/intel_workarounds.c | 2 +- > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index b74824f0b5b1..249d35c12a75 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -35,7 +35,7 @@ > * macros. Do **not** mass change existing definitions just to update the > style. > * > * Layout > - * '' > + * ~~ > * > * Keep helper macros near the top. For example, _PIPE() and friends. > * > @@ -79,7 +79,7 @@ > * style. Use lower case in hexadecimal values. > * > * Naming > - * '' > + * ~~ > * > * Try to name registers according to the specs. If the register name > changes in > * the specs from platform to another, stick to the original name. > @@ -97,7 +97,7 @@ > * suffix to the name. For example, ``_SKL`` or ``_GEN8``. > * > * Examples > - * > + * > * > * (Note that the values in the example are indented using spaces instead of > * TABs to avoid misalignment in generated documentation. Use TABs in the > diff --git a/drivers/gpu/drm/i915/intel_workarounds.c > b/drivers/gpu/drm/i915/intel_workarounds.c > index 9682dd575152..6decd432f4d3 100644 > --- a/drivers/gpu/drm/i915/intel_workarounds.c > +++ b/drivers/gpu/drm/i915/intel_workarounds.c > @@ -37,7 +37,7 @@ > *costly and simplifies things. We can revisit this in the future. > * > * Layout > - * '' > + * ~~ > * > * Keep things in this file ordered by WA type, as per the above (context, > GT, > * display, register whitelist, batchbuffer). Then, inside each type, keep > the -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110616] vce module in h264 encode
https://bugs.freedesktop.org/show_bug.cgi?id=110616 Andre Klapper changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEEDINFO|RESOLVED --- Comment #4 from Andre Klapper --- No reply by the reporter, hence closing. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm/vmwgfx: use core drm to extend/check vmw_execbuf_ioctl
On Fri, May 24, 2019 at 8:05 AM Thomas Hellstrom wrote:
>
> On Wed, 2019-05-22 at 21:09 +0200, Daniel Vetter wrote:
> > On Wed, May 22, 2019 at 9:01 PM Thomas Hellstrom <
> > thellst...@vmware.com> wrote:
> > > Hi, Emil,
> > >
> > > On Wed, 2019-05-22 at 17:41 +0100, Emil Velikov wrote:
> > > > From: Emil Velikov
> > > >
> > > > Currently vmw_execbuf_ioctl() open-codes the permission checking,
> > > > size
> > > > extending and copying that is already done in core drm.
> > > >
> > > > Kill all the duplication, adding a few comments for clarity.
> > >
> > > Ah, there is core functionality for this now.
> > >
> > > What worries me though with the core approach is that the sizes are
> > > not
> > > capped by the size of the kernel argument definition, which makes
> > > mailicious user-space being able to force kmallocs() the size of
> > > the
> > > maximum ioctl size. Should probably be fixed before pushing this.
> >
> > Hm I always worked under the assumption that kmalloc and friends
> > should be userspace hardened. Otherwise stuff like kmalloc_array
> > doesn't make any sense, everyone just feeds it unchecked input and
> > expects that helper to handle overflows.
> >
> > If we assume kmalloc isn't hardened against that, then we have a much
> > bigger problem than just vmwgfx ioctls ...
>
> After checking the drm_ioctl code I realize that what I thought was new
> behaviour actually has been around for a couple of years, so
> fixing isn't really tied to this patch series...
>
> What caused me to react was that previously we used to have this
>
> e4fda9f264e1 ("drm: Perform ioctl command validation on the stored
> kernel values")
>
> and we seem to have lost that now, if not for the io flags then at
> least for the size part. For the size of the ioctl arguments, I think
> in general if the kernel only touches a subset of the user-space
> specified size I see no reason why we should malloc / copy more than
> that?
I guess we could optimize that, but we'd probably still need to zero
clear the added size for forward compat with newer userspace. Iirc
we've had some issues in this area.
> Now, given the fact that the maximum ioctl argument size is quite
> limited, that might not be a big problem or a problem at all. Otherwise
> it would be pretty easy for a malicious process to allocate most or all
> of a system's resident memory?
The biggest you can allocate from kmalloc is limited by the largest
contiguous chunk alloc_pages gives you, which is limited by MAX_ORDER
from the page buddy allocator. You need lots of process to be able to
exhaust memory like that (and like I said, the entire kernel would be
broken if we'd consider this a security issue). If you want to make
sure that a process group can't exhaust memory this way then you need
to set appropriate cgroups limits.
-Daniel
>
> /Thomas
>
>
>
>
>
>
>
> > -Daniel
> >
> > >
> > > > Cc: "VMware Graphics"
> > > > Cc: Thomas Hellstrom
> > > > Cc: Daniel Vetter
> > > > Signed-off-by: Emil Velikov
> > > > ---
> > > > Thomas, VMware team,
> > > >
> > > > Please give this some testing on your end. I've only tested it
> > > > against
> > > > mesa-master.
> > >
> > > I'll review tomorrow and do some testing. Need to see if I can dig
> > > up
> > > user-space apps with version 0...
> > >
> > > Thanks,
> > >
> > > Thomas
> > >
> > > > Thanks
> > > > Emil
> > > > ---
> > > > drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 12 +-
> > > > drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 4 +-
> > > > drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 52 +
> > > >
> > > >
> > > > 3 files changed, 23 insertions(+), 45 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > > > b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > > > index d3f108f7e52d..2cb6ae219e43 100644
> > > > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > > > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > > > @@ -186,7 +186,7 @@ static const struct drm_ioctl_desc
> > > > vmw_ioctls[] =
> > > > {
> > > > DRM_RENDER_ALLOW),
> > > > VMW_IOCTL_DEF(VMW_REF_SURFACE, vmw_surface_reference_ioctl,
> > > > DRM_AUTH | DRM_RENDER_ALLOW),
> > > > - VMW_IOCTL_DEF(VMW_EXECBUF, NULL, DRM_AUTH |
> > > > + VMW_IOCTL_DEF(VMW_EXECBUF, vmw_execbuf_ioctl, DRM_AUTH |
> > > > DRM_RENDER_ALLOW),
> > > > VMW_IOCTL_DEF(VMW_FENCE_WAIT, vmw_fence_obj_wait_ioctl,
> > > > DRM_RENDER_ALLOW),
> > > > @@ -1140,15 +1140,7 @@ static long vmw_generic_ioctl(struct file
> > > > *filp, unsigned int cmd,
> > > > &vmw_ioctls[nr - DRM_COMMAND_BASE];
> > > >
> > > > if (nr == DRM_COMMAND_BASE + DRM_VMW_EXECBUF) {
> > > > - ret = (long) drm_ioctl_permit(ioctl->flags,
> > > > file_priv);
> > > > - if (unlikely(ret != 0))
> > > > - return ret;
> > > > -
> > > > - if (unlikely((cmd & (IOC_IN | IOC_O
Re: linux-next: build failure after merge of the drm-fixes tree
On Fri, May 24, 2019 at 12:29 AM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the drm-fixes tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function
> 'load_dmcu_fw':
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:667:7: error:
> implicit declaration of function 'ASICREV_IS_PICASSO'; did you mean
> 'ASICREV_IS_VEGA12_P'? [-Werror=implicit-function-declaration]
>if (ASICREV_IS_PICASSO(adev->external_rev_id))
>^~
>ASICREV_IS_VEGA12_P
>
> Caused by commit
>
> 55143dc23ca4 ("drm/amd/display: Don't load DMCU for Raven 1")
>
> I have reverted that commit for today.
Seems to compile fine here, and Dave just sent out the pull so I guess
works for him too. What's your .config?
-Daniel
>
> --
> Cheers,
> Stephen Rothwell
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110752] Make kms_ccs clearer
https://bugs.freedesktop.org/show_bug.cgi?id=110752 Bug ID: 110752 Summary: Make kms_ccs clearer Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: IGT Assignee: dri-devel@lists.freedesktop.org Reporter: arkadiusz.hi...@intel.com The test is written in a clever manner but that makes the skip results hard to parse both by humans and machines. igt_requires should be moved inside test_output and we should not use for_each_valid_output_on_pipe to find the first one valid. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110752] Make kms_ccs clearer
https://bugs.freedesktop.org/show_bug.cgi?id=110752 Arek Hiler changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |arkadiusz.hi...@intel.com |.org| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH] drm/ttm, drm/vmwgfx: Have TTM support AMD SEV encryption
From: Thomas Hellstrom
With SEV encryption, all DMA memory must be marked decrypted
(AKA "shared") for devices to be able to read it. In the future we might
want to be able to switch normal (encrypted) memory to decrypted in exactly
the same way as we handle caching states, and that would require additional
memory pools. But for now, rely on memory allocated with
dma_alloc_coherent() which is already decrypted with SEV enabled. Set up
the page protection accordingly. Drivers must detect SEV enabled and switch
to the dma page pool.
This patch has not yet been tested. As a follow-up, we might want to
cache decrypted pages in the dma page pool regardless of their caching
state.
Cc: Christian König
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo_util.c| 17 +
drivers/gpu/drm/ttm/ttm_bo_vm.c | 6 --
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 3 +++
drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 6 --
include/drm/ttm/ttm_bo_driver.h | 8 +---
include/drm/ttm/ttm_tt.h | 1 +
6 files changed, 30 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 895d77d799e4..1d6643bd0b01 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -419,11 +419,13 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
page = i * dir + add;
if (old_iomap == NULL) {
pgprot_t prot = ttm_io_prot(old_mem->placement,
+ ttm->page_flags,
PAGE_KERNEL);
ret = ttm_copy_ttm_io_page(ttm, new_iomap, page,
prot);
} else if (new_iomap == NULL) {
pgprot_t prot = ttm_io_prot(new_mem->placement,
+ ttm->page_flags,
PAGE_KERNEL);
ret = ttm_copy_io_ttm_page(ttm, old_iomap, page,
prot);
@@ -526,11 +528,11 @@ static int ttm_buffer_object_transfer(struct
ttm_buffer_object *bo,
return 0;
}
-pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t tmp)
+pgprot_t ttm_io_prot(u32 caching_flags, u32 tt_page_flags, pgprot_t tmp)
{
/* Cached mappings need no adjustment */
if (caching_flags & TTM_PL_FLAG_CACHED)
- return tmp;
+ goto check_encryption;
#if defined(__i386__) || defined(__x86_64__)
if (caching_flags & TTM_PL_FLAG_WC)
@@ -548,6 +550,11 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t tmp)
#if defined(__sparc__) || defined(__mips__)
tmp = pgprot_noncached(tmp);
#endif
+
+check_encryption:
+ if (tt_page_flags & TTM_PAGE_FLAG_DECRYPTED)
+ tmp = pgprot_decrypted(tmp);
+
return tmp;
}
EXPORT_SYMBOL(ttm_io_prot);
@@ -594,7 +601,8 @@ static int ttm_bo_kmap_ttm(struct ttm_buffer_object *bo,
if (ret)
return ret;
- if (num_pages == 1 && (mem->placement & TTM_PL_FLAG_CACHED)) {
+ if (num_pages == 1 && (mem->placement & TTM_PL_FLAG_CACHED) &&
+ !(ttm->page_flags & TTM_PAGE_FLAG_DECRYPTED)) {
/*
* We're mapping a single page, and the desired
* page protection is consistent with the bo.
@@ -608,7 +616,8 @@ static int ttm_bo_kmap_ttm(struct ttm_buffer_object *bo,
* We need to use vmap to get the desired page protection
* or to make the buffer object look contiguous.
*/
- prot = ttm_io_prot(mem->placement, PAGE_KERNEL);
+ prot = ttm_io_prot(mem->placement, ttm->page_flags,
+ PAGE_KERNEL);
map->bo_kmap_type = ttm_bo_map_vmap;
map->virtual = vmap(ttm->pages + start_page, num_pages,
0, prot);
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 2d9862fcf6fd..e12247edd243 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -245,7 +245,6 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,
goto out_io_unlock;
}
- cvma.vm_page_prot = ttm_io_prot(bo->mem.placement, prot);
if (!bo->mem.bus.is_iomem) {
struct ttm_operation_ctx ctx = {
.interruptible = false,
@@ -255,13 +254,16 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,
};
ttm = bo->ttm;
+ cvma.vm_page_prot = ttm_io_prot(bo->mem.placement,
+ ttm->page_flags, prot);
if (ttm_tt_populate(bo->ttm, &ctx)) {
ret = VM_
Re: [git pull] drm fixes for 5.2-rc2
fyi sfr reported that 55143dc23ca4 ("drm/amd/display: Don't load DMCU
for Raven 1") breaks the build on x86-64. But I can't repro and didn't
immediately see what Kconfig it would need to trigger this, so no
idea. So just heads up in case this is real and there's some odd
config that hits a bug here ...
-Daniel
On Fri, May 24, 2019 at 6:28 AM Dave Airlie wrote:
>
> Hey Linus,
>
> Nothing too unusual here for rc2.
>
> i915:
> - boosting fix
> - bump ready task fixes
> - GVT - reset fix, error return, TRTT handling fix
>
> amdgpu:
> - DMCU firmware loading fix
> - Polaris 10 pci id for kfd
> - picasso screen corruption fix
> - SR-IOV fixes
> - vega driver reload fixes
> - SMU locking fix
> - compute profile fix for kfd
>
> vmwgfx:
> - integer overflow fixes
> - dma sg fix
>
> sun4i:
> - HDMI phy fixes
>
> gma500:
> - LVDS detection fix
>
> panfrost:
> - devfreq selection fix
>
> drm-fixes-2019-05-24:
> drm i915, amdgpu, vmwgfx, sun4i, panfrost, gma500 fixes.
> The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9:
>
> Linux 5.2-rc1 (2019-05-19 15:47:09 -0700)
>
> are available in the Git repository at:
>
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-05-24
>
> for you to fetch changes up to e1e52981f292b4e321781794eaf6e8a087f4f300:
>
> Merge tag 'drm-intel-fixes-2019-05-23' of
> git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2019-05-24
> 14:01:00 +1000)
>
>
> drm i915, amdgpu, vmwgfx, sun4i, panfrost, gma500 fixes.
>
>
> Alex Deucher (2):
> drm/amdgpu/soc15: skip reset on init
> drm/amdgpu/gmc9: set vram_width properly for SR-IOV
>
> Chris Wilson (5):
> drm/i915: Rearrange i915_scheduler.c
> drm/i915: Pass i915_sched_node around internally
> drm/i915: Bump signaler priority on adding a waiter
> drm/i915: Downgrade NEWCLIENT to non-preemptive
> drm/i915: Truly bump ready tasks ahead of busywaits
>
> Dan Carpenter (2):
> drm/amd/powerplay: fix locking in smu_feature_set_supported()
> drm/i915/gvt: Fix an error code in ppgtt_populate_spt_by_guest_entry()
>
> Dave Airlie (4):
> Merge branch 'vmwgfx-fixes-5.2' of
> git://people.freedesktop.org/~thomash/linux into drm-fixes
> Merge tag 'drm-misc-fixes-2019-05-22' of
> git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
> Merge branch 'drm-fixes-5.2' of
> git://people.freedesktop.org/~agd5f/linux into drm-fixes
> Merge tag 'drm-intel-fixes-2019-05-23' of
> git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
>
> Ezequiel Garcia (1):
> drm/panfrost: Select devfreq
>
> Flora Cui (1):
> drm/amdgpu: keep stolen memory on picasso
>
> Harish Kasiviswanathan (1):
> drm/amdkfd: Fix compute profile switching
>
> Harry Wentland (2):
> drm/amd/display: Add ASICREV_IS_PICASSO
> drm/amd/display: Don't load DMCU for Raven 1
>
> Jagan Teki (1):
> drm/sun4i: sun6i_mipi_dsi: Fix hsync_porch overflow
>
> Jernej Skrabec (2):
> drm/sun4i: Fix sun8i HDMI PHY clock initialization
> drm/sun4i: Fix sun8i HDMI PHY configuration for > 148.5 MHz
>
> Joonas Lahtinen (1):
> Merge tag 'gvt-fixes-2019-05-21' of
> https://github.com/intel/gvt-linux into drm-intel-fixes
>
> Kent Russell (1):
> drm/amdkfd: Add missing Polaris10 ID
>
> Murray McAllister (2):
> drm/vmwgfx: NULL pointer dereference from vmw_cmd_dx_view_define()
> drm/vmwgfx: integer underflow in vmw_cmd_dx_set_shader() leading
> to an invalid read
>
> Patrik Jakobsson (1):
> drm/gma500/cdv: Check vbt config bits when detecting lvds panels
>
> Sean Paul (1):
> Merge drm-misc-next-fixes-2019-05-20 into drm-misc-fixes
>
> Thomas Hellstrom (4):
> drm/vmwgfx: Don't send drm sysfs hotplug events on initial master set
> drm/vmwgfx: Fix user space handle equal to zero
> drm/vmwgfx: Fix compat mode shader operation
> drm/vmwgfx: Use the dma scatter-gather iterator to get dma addresses
>
> Weinan (1):
> drm/i915/gvt: emit init breadcrumb for gvt request
>
> Yan Zhao (4):
> drm/i915/gvt: use cmd to restore in-context mmios to hw for gen9
> platform
> drm/i915/gvt: Tiled Resources mmios are in-context mmios for gen9+
> drm/i915/gvt: add 0x4dfc to gen9 save-restore list
> drm/i915/gvt: do not let TRTTE and 0x4dfc write passthrough to hardware
>
> Yintian Tao (1):
> drm/amdgpu: skip fw pri bo alloc for SRIOV
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c| 17 +-
> drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 11 +-
> drivers/gpu/drm/amd/amdgpu/soc15.c | 5 +
> drivers/gpu/drm/amd/amdkfd/kfd_device.c| 17 ++
> .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 11 +-
> drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 7 +
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |
Re: [PATCH 2/2] video: fbdev: pvr2fb: add COMPILE_TEST support
Hi Bartlomiej,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.2-rc1 next-20190524]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Bartlomiej-Zolnierkiewicz/video-fbdev-pvr2fb-remove-function-prototypes/20190524-145925
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>):
drivers/video//fbdev/pvr2fb.c: In function 'pvr2_get_param':
>> drivers/video//fbdev/pvr2fb.c:737:12: warning: cast from pointer to integer
>> of different size [-Wpointer-to-int-cast]
return (int)p[i].name;
^
In file included from include/linux/kernel.h:15:0,
from include/linux/list.h:9,
from include/linux/module.h:9,
from drivers/video//fbdev/pvr2fb.c:48:
drivers/video//fbdev/pvr2fb.c: In function 'pvr2fb_common_init':
>> drivers/video//fbdev/pvr2fb.c:823:3: warning: cast to pointer from integer
>> of different size [-Wint-to-pointer-cast]
(char *)pvr2_get_param(cables, NULL, cable_type, 3),
^
include/linux/printk.h:311:34: note: in definition of macro 'pr_info'
printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^~~
>> drivers/video//fbdev/pvr2fb.c:819:2: note: in expansion of macro 'fb_info'
fb_info(fb_info, "Mode %dx%d-%d pitch = %ld cable: %s video output: %s\n",
^~~
drivers/video//fbdev/pvr2fb.c:824:3: warning: cast to pointer from integer
of different size [-Wint-to-pointer-cast]
(char *)pvr2_get_param(outputs, NULL, video_output, 3));
^
include/linux/printk.h:311:34: note: in definition of macro 'pr_info'
printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^~~
>> drivers/video//fbdev/pvr2fb.c:819:2: note: in expansion of macro 'fb_info'
fb_info(fb_info, "Mode %dx%d-%d pitch = %ld cable: %s video output: %s\n",
^~~
sparse warnings: (new ones prefixed by >>)
>> drivers/video/fbdev/pvr2fb.c:1050:11: sparse: sparse: Using plain integer as
>> NULL pointer
>> drivers/video/fbdev/pvr2fb.c:737:46: sparse: sparse: non size-preserving
>> pointer to integer cast
>> drivers/video/fbdev/pvr2fb.c:819:9: sparse: sparse: non size-preserving
>> integer to pointer cast
>> drivers/video/fbdev/pvr2fb.c:819:9: sparse: sparse: non size-preserving
>> integer to pointer cast
vim +/fb_info +819 drivers/video//fbdev/pvr2fb.c
970866e8 drivers/video/fbdev/pvr2fb.c Bartlomiej Zolnierkiewicz 2019-05-22 725
970866e8 drivers/video/fbdev/pvr2fb.c Bartlomiej Zolnierkiewicz 2019-05-22 726
static int pvr2_get_param(const struct pvr2_params *p, const char *s, int val,
970866e8 drivers/video/fbdev/pvr2fb.c Bartlomiej Zolnierkiewicz 2019-05-22 727
int size)
970866e8 drivers/video/fbdev/pvr2fb.c Bartlomiej Zolnierkiewicz 2019-05-22 728
{
970866e8 drivers/video/fbdev/pvr2fb.c Bartlomiej Zolnierkiewicz 2019-05-22 729
int i;
970866e8 drivers/video/fbdev/pvr2fb.c Bartlomiej Zolnierkiewicz 2019-05-22 730
970866e8 drivers/video/fbdev/pvr2fb.c Bartlomiej Zolnierkiewicz 2019-05-22 731
for (i = 0 ; i < size ; i++ ) {
970866e8 drivers/video/fbdev/pvr2fb.c Bartlomiej Zolnierkiewicz 2019-05-22 732
if (s != NULL) {
970866e8 drivers/video/fbdev/pvr2fb.c Bartlomiej Zolnierkiewicz 2019-05-22 733
if (!strncasecmp(p[i].name, s, strlen(s)))
970866e8 drivers/video/fbdev/pvr2fb.c Bartlomiej Zolnierkiewicz 2019-05-22 734
return p[i].val;
970866e8 drivers/video/fbdev/pvr2fb.c Bartlomiej Zolnierkiewicz 2019-05-22 735
} else {
970866e8 drivers/video/fbdev/pvr2fb.c Bartlomiej Zolnierkiewicz 2019-05-22 736
if (p[i].val == val)
970866e8 drivers/video/fbdev/pvr2fb.c Bartlomiej Zolnierkiewicz 2019-05-22 @737
return (int)p[i].name;
970866e8 drivers/video/fbdev/pvr2fb.c Bartlomiej Zolnierkiewicz 2019-05-22 738
}
970866e8 drivers/video/fbdev/pvr2fb.c Bartlomiej Zolnierkiewicz 2019-05-22 739
}
970866e8 drivers/video/fbdev/pvr2fb.c Bartlomiej Zolnierkiewicz 2019-05-22 740
return -1;
970866e8 drivers/video/fbdev/pvr2fb.c Bartlomiej Zolnierkiewicz 2019-05-22 741
}
970866e8 drivers/video/fbdev/pvr2fb.c Bartlomiej Zolnierkiewicz 2019-05-22 742
^1da177e drivers/video/pvr2fb.c Linus Torvalds
Re: [PATCH] drm/stm: dsi: check hardware version
Le ven. 10 mai 2019 à 18:31, Philippe CORNU a écrit :
>
>
> Dear Yannick,
> Thank you for your patch,
>
> Acked-by: Philippe Cornu
>
> Dear Benjamin,
> If you are fine with this patch, please push it *after* the patch named
> "drm/stm: dsi: add support of an optional regulator" (if I well
> understood those two patches)
>
> Thank you
> Philippe :-)
Applied on drm-misc-next,
Benjamin
>
>
> On 5/10/19 5:02 PM, Yannick Fertré wrote:
> > Check version of DSI hardware IP. Only versions 1.30 & 1.31
> > are supported.
> >
> > Signed-off-by: Yannick Fertré
> > ---
> > drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 24 +++-
> > 1 file changed, 23 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> > b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> > index 22bd095..29105e9 100644
> > --- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> > +++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> > @@ -227,7 +227,6 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
> > drm_display_mode *mode,
> > u32 val;
> >
> > /* Update lane capabilities according to hw version */
> > - dsi->hw_version = dsi_read(dsi, DSI_VERSION) & VERSION;
> > dsi->lane_min_kbps = LANE_MIN_KBPS;
> > dsi->lane_max_kbps = LANE_MAX_KBPS;
> > if (dsi->hw_version == HWVER_131) {
> > @@ -306,6 +305,7 @@ static int dw_mipi_dsi_stm_probe(struct platform_device
> > *pdev)
> > {
> > struct device *dev = &pdev->dev;
> > struct dw_mipi_dsi_stm *dsi;
> > + struct clk *pclk;
> > struct resource *res;
> > int ret;
> >
> > @@ -347,6 +347,28 @@ static int dw_mipi_dsi_stm_probe(struct
> > platform_device *pdev)
> > goto err_clk_get;
> > }
> >
> > + pclk = devm_clk_get(dev, "pclk");
> > + if (IS_ERR(pclk)) {
> > + ret = PTR_ERR(pclk);
> > + DRM_ERROR("Unable to get peripheral clock: %d\n", ret);
> > + goto err_dsi_probe;
> > + }
> > +
> > + ret = clk_prepare_enable(pclk);
> > + if (ret) {
> > + DRM_ERROR("%s: Failed to enable peripheral clk\n", __func__);
> > + goto err_dsi_probe;
> > + }
> > +
> > + dsi->hw_version = dsi_read(dsi, DSI_VERSION) & VERSION;
> > + clk_disable_unprepare(pclk);
> > +
> > + if (dsi->hw_version != HWVER_130 && dsi->hw_version != HWVER_131) {
> > + ret = -ENODEV;
> > + DRM_ERROR("bad dsi hardware version\n");
> > + goto err_dsi_probe;
> > + }
> > +
> > dw_mipi_dsi_stm_plat_data.base = dsi->base;
> > dw_mipi_dsi_stm_plat_data.priv_data = dsi;
> >
> >
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/stm: ltdc: remove clk_round_rate comment
Le lun. 13 mai 2019 à 16:46, Philippe CORNU a écrit :
>
> Dear Yannick,
>
> Acked-by: Philippe Cornu
>
Applied on drm-misc-next,
Benjamin
> Thank you,
>
> Philippe :-)
>
> On 5/13/19 3:15 PM, Yannick Fertré wrote:
> > Clk_round_rate returns rounded clock without changing
> > the hardware in any way.
> > This function couldn't replace set_rate/get_rate calls.
> > Todo comment has been removed & a new log inserted.
> >
> > Signed-off-by: Yannick Fertré
> > ---
> > Changes in v2:
> > - Clk_enable & clk_disable are needed for the SOC STM32F7
> >(not for STM32MP1). I return this part of the patch to make sure the
> >driver is compatible with all SOC STM32.
> >
> > drivers/gpu/drm/stm/ltdc.c | 8 +++-
> > 1 file changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
> > index 97912e2..1104e78 100644
> > --- a/drivers/gpu/drm/stm/ltdc.c
> > +++ b/drivers/gpu/drm/stm/ltdc.c
> > @@ -507,11 +507,6 @@ static bool ltdc_crtc_mode_fixup(struct drm_crtc *crtc,
> > struct ltdc_device *ldev = crtc_to_ltdc(crtc);
> > int rate = mode->clock * 1000;
> >
> > - /*
> > - * TODO clk_round_rate() does not work yet. When ready, it can
> > - * be used instead of clk_set_rate() then clk_get_rate().
> > - */
> > -
> > clk_disable(ldev->pixel_clk);
> > if (clk_set_rate(ldev->pixel_clk, rate) < 0) {
> > DRM_ERROR("Cannot set rate (%dHz) for pixel clk\n", rate);
> > @@ -521,6 +516,9 @@ static bool ltdc_crtc_mode_fixup(struct drm_crtc *crtc,
> >
> > adjusted_mode->clock = clk_get_rate(ldev->pixel_clk) / 1000;
> >
> > + DRM_DEBUG_DRIVER("requested clock %dkHz, adjusted clock %dkHz\n",
> > + mode->clock, adjusted_mode->clock);
> > +
> > return true;
> > }
> >
> > --
> > 2.7.4
> >
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: assure aux_dev is nonzero before using it
On Thu, 23 May 2019, tcamuso wrote:
> From Daniel Kwon
>
> The system was crashed due to invalid memory access while trying to access
> auxiliary device.
>
> crash> bt
> PID: 9863 TASK: 89d1bdf11040 CPU: 1 COMMAND: "ipmitool"
> #0 [89cedd7f3868] machine_kexec at b0663674
> #1 [89cedd7f38c8] __crash_kexec at b071cf62
> #2 [89cedd7f3998] crash_kexec at b071d050
> #3 [89cedd7f39b0] oops_end at b0d6d758
> #4 [89cedd7f39d8] no_context at b0d5bcde
> #5 [89cedd7f3a28] __bad_area_nosemaphore at b0d5bd75
> #6 [89cedd7f3a78] bad_area at b0d5c085
> #7 [89cedd7f3aa0] __do_page_fault at b0d7080c
> #8 [89cedd7f3b10] do_page_fault at b0d70905
> #9 [89cedd7f3b40] page_fault at b0d6c758
> [exception RIP: drm_dp_aux_dev_get_by_minor+0x3d]
> RIP: c0a589bd RSP: 89cedd7f3bf0 RFLAGS: 00010246
> RAX: RBX: RCX: 89cedd7f3fd8
> RDX: RSI: RDI: c0a613e0
> RBP: 89cedd7f3bf8 R8: 89f1bcbabbd0 R9:
> R10: 89f1be7a1cc0 R11: R12:
> R13: 89f1b32a2830 R14: 89d18fadfa00 R15:
> ORIG_RAX: CS: 0010 SS: 0018
> RIP: 2b45f0d80d30 RSP: 7ffc416066a0 RFLAGS: 00010246
> RAX: 0002 RBX: 56062e212d80 RCX: 7ffc41606810
> RDX: RSI: 0002 RDI: 7ffc41606ec0
> RBP: R8: 56062dfed229 R9: 2b45f0cdf14d
> R10: 0002 R11: 0246 R12: 7ffc41606ec0
> R13: 7ffc41606ed0 R14: 7ffc41606ee0 R15:
> ORIG_RAX: 0002 CS: 0033 SS: 002b
>
>
>
> It was trying to open '/dev/ipmi0', but as no entry in aux_dir, it returned
> NULL from 'idr_find()'. This drm_dp_aux_dev_get_by_minor() should have done a
> check on this, but had failed to do it.
I think the better question is, *why* does the idr_find() return NULL? I
don't think it should, under any circumstances. I fear adding the check
here papers over some other problem, taking us further away from the
root cause.
Also, can you reproduce this on a recent upstream kernel? The aux device
nodes were introduced in kernel v4.6. Whatever you reproduced on v3.10
is pretty much irrelevant for upstream.
BR,
Jani.
>
>
> /usr/src/debug/kernel-3.10.0-957.12.1.el7/linux-3.10.0-957.12.1.el7.x86_64/include/linux/idr.h:
> 114
> 114 struct idr_layer *hint = rcu_dereference_raw(idr->hint);
> 0xc0a58998 :mov
> 0x8a41(%rip),%rax# 0xc0a613e0
> /usr/src/debug/kernel-3.10.0-957.12.1.el7/linux-3.10.0-957.12.1.el7.x86_64/include/linux/idr.h:
> 116
> 116 if (hint && (id & ~IDR_MASK) == hint->prefix)
> 117 return rcu_dereference_raw(hint->ary[id & IDR_MASK]);
> 0xc0a5899f :test %rax,%rax
> 0xc0a589a2 :je
> 0xc0a589ac
> 0xc0a589a4 :mov%ebx,%edx
> 0xc0a589a6 :xor%dl,%dl
> 0xc0a589a8 :cmp
> (%rax),%edx
> 0xc0a589aa :je
> 0xc0a589f0
> /usr/src/debug/kernel-3.10.0-957.12.1.el7/linux-3.10.0-957.12.1.el7.x86_64/include/linux/idr.h:
> 119
> 119 return idr_find_slowpath(idr, id);
> 0xc0a589ac :mov%ebx,%esi
> 0xc0a589ae :mov
> $0xc0a613e0,%rdi
> 0xc0a589b5 :callq
> 0xb09771b0
> 0xc0a589ba :mov%rax,%rbx
> /usr/src/debug/kernel-3.10.0-957.12.1.el7/linux-3.10.0-957.12.1.el7.x86_64/arch/x86/include/asm/atomic.h:
> 25
> 25 return ACCESS_ONCE((v)->counter);
> 0xc0a589bd :mov
> 0x18(%rbx),%edx
>
> crash> struct file.f_path 0x89d18fadfa00
> f_path = {
> mnt = 0x89f23feaa620,
> dentry = 0x89f1be7a1cc0
> }
> crash> files -d 0x89f1be7a1cc0
> DENTRY INODE SUPERBLK TYPE PATH
> 89f1be7a1cc0 89f1b32a2830 89d293aa8800 CHR /dev/ipmi0
>
> crash> struct inode.i_rdev 89f1b32a2830
> i_rdev = 0xf20
> crash> eval (0xf & 0xf20)
> hexadecimal: 0
> decimal: 0
> octal: 0
> binary:
>
>
> As the index value was 0 and aux_idr had value 0 for all, it can have value
> NULL from idr_find() function, but the below function doesn't check and just
> tries to use it.
>
>
> crash> aux_idr
> aux_idr = $8 = {
> hint = 0x0
[Bug 110754] Add tests checking how stable the CRCs are
https://bugs.freedesktop.org/show_bug.cgi?id=110754 Bug ID: 110754 Summary: Add tests checking how stable the CRCs are Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: IGT Assignee: dri-devel@lists.freedesktop.org Reporter: arkadiusz.hi...@intel.com Such test can be made part of BAT to give us overview of the health of pipe CRCs. Initial idea: 1. run collecting CRCs 2. pull off the chaos monkey doing hotplugs, workloads, etc 3. make sure that CRC is stable This way we will know which platforms suffer from unstable CRC and we can filter out all of the CRC mismatches using CI buglog. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/ttm, drm/vmwgfx: Have TTM support AMD SEV encryption
Am 24.05.19 um 10:11 schrieb Thomas Hellström (VMware):
> [CAUTION: External Email]
>
> From: Thomas Hellstrom
>
> With SEV encryption, all DMA memory must be marked decrypted
> (AKA "shared") for devices to be able to read it. In the future we might
> want to be able to switch normal (encrypted) memory to decrypted in exactly
> the same way as we handle caching states, and that would require additional
> memory pools. But for now, rely on memory allocated with
> dma_alloc_coherent() which is already decrypted with SEV enabled. Set up
> the page protection accordingly. Drivers must detect SEV enabled and switch
> to the dma page pool.
>
> This patch has not yet been tested. As a follow-up, we might want to
> cache decrypted pages in the dma page pool regardless of their caching
> state.
This patch is unnecessary, SEV support already works fine with at least
amdgpu and I would expect that it also works with other drivers as well.
Also see this patch:
commit 64e1f830ea5b3516a4256ed1c504a265d7f2a65c
Author: Christian König
Date: Wed Mar 13 10:11:19 2019 +0100
drm: fallback to dma_alloc_coherent when memory encryption is active
We can't just map any randome page we get when memory encryption is
active.
Signed-off-by: Christian König
Acked-by: Alex Deucher
Link: https://patchwork.kernel.org/patch/10850833/
Regards,
Christian.
>
> Cc: Christian König
> Signed-off-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/ttm/ttm_bo_util.c| 17 +
> drivers/gpu/drm/ttm/ttm_bo_vm.c | 6 --
> drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 3 +++
> drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 6 --
> include/drm/ttm/ttm_bo_driver.h | 8 +---
> include/drm/ttm/ttm_tt.h | 1 +
> 6 files changed, 30 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
> b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index 895d77d799e4..1d6643bd0b01 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -419,11 +419,13 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
> page = i * dir + add;
> if (old_iomap == NULL) {
> pgprot_t prot = ttm_io_prot(old_mem->placement,
> + ttm->page_flags,
> PAGE_KERNEL);
> ret = ttm_copy_ttm_io_page(ttm, new_iomap, page,
> prot);
> } else if (new_iomap == NULL) {
> pgprot_t prot = ttm_io_prot(new_mem->placement,
> + ttm->page_flags,
> PAGE_KERNEL);
> ret = ttm_copy_io_ttm_page(ttm, old_iomap, page,
> prot);
> @@ -526,11 +528,11 @@ static int ttm_buffer_object_transfer(struct
> ttm_buffer_object *bo,
> return 0;
> }
>
> -pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t tmp)
> +pgprot_t ttm_io_prot(u32 caching_flags, u32 tt_page_flags, pgprot_t tmp)
> {
> /* Cached mappings need no adjustment */
> if (caching_flags & TTM_PL_FLAG_CACHED)
> - return tmp;
> + goto check_encryption;
>
> #if defined(__i386__) || defined(__x86_64__)
> if (caching_flags & TTM_PL_FLAG_WC)
> @@ -548,6 +550,11 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t
> tmp)
> #if defined(__sparc__) || defined(__mips__)
> tmp = pgprot_noncached(tmp);
> #endif
> +
> +check_encryption:
> + if (tt_page_flags & TTM_PAGE_FLAG_DECRYPTED)
> + tmp = pgprot_decrypted(tmp);
> +
> return tmp;
> }
> EXPORT_SYMBOL(ttm_io_prot);
> @@ -594,7 +601,8 @@ static int ttm_bo_kmap_ttm(struct ttm_buffer_object *bo,
> if (ret)
> return ret;
>
> - if (num_pages == 1 && (mem->placement & TTM_PL_FLAG_CACHED)) {
> + if (num_pages == 1 && (mem->placement & TTM_PL_FLAG_CACHED) &&
> + !(ttm->page_flags & TTM_PAGE_FLAG_DECRYPTED)) {
> /*
> * We're mapping a single page, and the desired
> * page protection is consistent with the bo.
> @@ -608,7 +616,8 @@ static int ttm_bo_kmap_ttm(struct ttm_buffer_object *bo,
> * We need to use vmap to get the desired page protection
> * or to make the buffer object look contiguous.
> */
> - prot = ttm_io_prot(mem->placement, PAGE_KERNEL);
> + prot = ttm_io_prot(mem->placement, ttm->page_flags,
> + PAGE_KERNEL);
> map->bo_kmap_type = ttm_bo_map_vmap;
> map->virtual = vmap(ttm->pages + start_page, num_pages,
>
Re: [PATCH] drm/meson: imply dw-hdmi i2s audio for meson hdmi
On 29/04/2019 12:23, Jerome Brunet wrote: > Imply the i2s part of the Synopsys HDMI driver for Amlogic SoCs. > This will enable the i2s part by default when meson hdmi driver > is enable but let platforms not supported by the audio subsystem > disable it if necessary. > > Signed-off-by: Jerome Brunet > --- > drivers/gpu/drm/meson/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/meson/Kconfig b/drivers/gpu/drm/meson/Kconfig > index c28b69f48555..a480e4a80bea 100644 > --- a/drivers/gpu/drm/meson/Kconfig > +++ b/drivers/gpu/drm/meson/Kconfig > @@ -14,3 +14,4 @@ config DRM_MESON_DW_HDMI > depends on DRM_MESON > default y if DRM_MESON > select DRM_DW_HDMI > + imply DRM_DW_HDMI_I2S_AUDIO > Reviewed-by: Neil Armstrong And applying to drm-misc-next Thanks, Neil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/10] drm/ttm: fix busy memory to fail other user v10
Yeah, that shouldn't be a problem. We just need to make sure we don't
busy wait for the BOs to become available.
Christian.
Am 24.05.19 um 07:35 schrieb Liang, Prike:
Use Abaqus torturing the amdgpu driver more times will running into locking
first busy BO deadlock .Then the caller will
return EAGAIN and eventually dm_plane_helper_prepare_fb popups out pinned
failed message .For this case, the patch#7
can we add EAGAIN as ERESTARTSYS which filter out the annoying error message .
Thanks,
Prike
-Original Message-
From: Christian König
Sent: Thursday, May 23, 2019 7:04 PM
To: Zhou, David(ChunMing) ; Olsak, Marek ; Zhou,
David(ChunMing) ; Liang, Prike ;
dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
Subject: Re: [PATCH 06/10] drm/ttm: fix busy memory to fail other user v10
[CAUTION: External Email]
Am 23.05.19 um 12:24 schrieb zhoucm1:
On 2019年05月22日 20:59, Christian König wrote:
[CAUTION: External Email]
BOs on the LRU might be blocked during command submission and cause
OOM situations.
Avoid this by blocking for the first busy BO not locked by the same
ticket as the BO we are searching space for.
v10: completely start over with the patch since we didn't
handled a whole bunch of corner cases.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 77 ++--
1 file changed, 66 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
b/drivers/gpu/drm/ttm/ttm_bo.c index 4c6389d849ed..861facac33d4
100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -771,32 +771,72 @@ EXPORT_SYMBOL(ttm_bo_eviction_valuable);
* b. Otherwise, trylock it.
*/
static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object
*bo,
- struct ttm_operation_ctx *ctx, bool *locked)
+ struct ttm_operation_ctx *ctx, bool *locked,
bool *busy)
{
bool ret = false;
- *locked = false;
if (bo->resv == ctx->resv) {
reservation_object_assert_held(bo->resv);
if (ctx->flags & TTM_OPT_FLAG_ALLOW_RES_EVICT
|| !list_empty(&bo->ddestroy))
ret = true;
+ *locked = false;
+ if (busy)
+ *busy = false;
} else {
- *locked = reservation_object_trylock(bo->resv);
- ret = *locked;
+ ret = reservation_object_trylock(bo->resv);
+ *locked = ret;
+ if (busy)
+ *busy = !ret;
}
return ret;
}
+/**
+ * ttm_mem_evict_wait_busy - wait for a busy BO to become available
+ *
+ * @busy_bo: BO which couldn't be locked with trylock
+ * @ctx: operation context
+ * @ticket: acquire ticket
+ *
+ * Try to lock a busy buffer object to avoid failing eviction.
+ */
+static int ttm_mem_evict_wait_busy(struct ttm_buffer_object *busy_bo,
+ struct ttm_operation_ctx *ctx,
+ struct ww_acquire_ctx *ticket) {
+ int r;
+
+ if (!busy_bo || !ticket)
+ return -EBUSY;
+
+ if (ctx->interruptible)
+ r =
+ reservation_object_lock_interruptible(busy_bo->resv,
+ ticket);
+ else
+ r = reservation_object_lock(busy_bo->resv, ticket);
+
+ /*
+* TODO: It would be better to keep the BO locked until
allocation is at
+* least tried one more time, but that would mean a much
larger rework
+* of TTM.
+*/
+ if (!r)
+ reservation_object_unlock(busy_bo->resv);
+
+ return r == -EDEADLK ? -EAGAIN : r; }
+
static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
uint32_t mem_type,
const struct ttm_place *place,
- struct ttm_operation_ctx *ctx)
+ struct ttm_operation_ctx *ctx,
+ struct ww_acquire_ctx *ticket)
{
+ struct ttm_buffer_object *bo = NULL, *busy_bo = NULL;
struct ttm_bo_global *glob = bdev->glob;
struct ttm_mem_type_manager *man = &bdev->man[mem_type];
- struct ttm_buffer_object *bo = NULL;
bool locked = false;
unsigned i;
int ret;
@@ -804,8 +844,15 @@ static int ttm_mem_evict_first(struct
ttm_bo_device *bdev,
spin_lock(&glob->lru_lock);
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
list_for_each_entry(bo, &man->lru[i], lru) {
- if (!ttm_bo_evict_swapout_allowable(bo, ctx,
&locked))
+ bool busy;
+
+ if (!ttm_bo_evict_swapout_allowable(bo, ctx,
&locked,
+ &busy)) {
+ if (busy && !busy_bo &&
+ bo->resv->lock.ctx != ticket)
+
[PATCH 01/33] dummycon: Sprinkle locking checks
As part of trying to understand the locking (or lack thereof) in the
fbcon/vt/fbdev maze, annotate everything.
Signed-off-by: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Hans de Goede
Cc: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: Kees Cook
Cc: Nicolas Pitre
---
drivers/video/console/dummycon.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/video/console/dummycon.c b/drivers/video/console/dummycon.c
index 45ad925ad5f8..2352b4c37826 100644
--- a/drivers/video/console/dummycon.c
+++ b/drivers/video/console/dummycon.c
@@ -33,6 +33,8 @@ static bool dummycon_putc_called;
void dummycon_register_output_notifier(struct notifier_block *nb)
{
+ WARN_CONSOLE_UNLOCKED();
+
raw_notifier_chain_register(&dummycon_output_nh, nb);
if (dummycon_putc_called)
@@ -41,11 +43,15 @@ void dummycon_register_output_notifier(struct
notifier_block *nb)
void dummycon_unregister_output_notifier(struct notifier_block *nb)
{
+ WARN_CONSOLE_UNLOCKED();
+
raw_notifier_chain_unregister(&dummycon_output_nh, nb);
}
static void dummycon_putc(struct vc_data *vc, int c, int ypos, int xpos)
{
+ WARN_CONSOLE_UNLOCKED();
+
dummycon_putc_called = true;
raw_notifier_call_chain(&dummycon_output_nh, 0, NULL);
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/33] vt: More locking checks
I honestly have no idea what the subtle differences between
con_is_visible, con_is_fg (internal to vt.c) and con_is_bound are. But
it looks like both vc->vc_display_fg and con_driver_map are protected
by the console_lock, so probably better if we hold that when checking
this.
To do that I had to deinline the con_is_visible function.
Signed-off-by: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: Nicolas Pitre
Cc: Martin Hostettler
Cc: Adam Borowski
Cc: Daniel Vetter
Cc: Mikulas Patocka
---
drivers/tty/vt/vt.c| 16
include/linux/console_struct.h | 5 +
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index bc9813b14c58..a8988a085138 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3815,6 +3815,8 @@ int con_is_bound(const struct consw *csw)
{
int i, bound = 0;
+ WARN_CONSOLE_UNLOCKED();
+
for (i = 0; i < MAX_NR_CONSOLES; i++) {
if (con_driver_map[i] == csw) {
bound = 1;
@@ -3826,6 +3828,20 @@ int con_is_bound(const struct consw *csw)
}
EXPORT_SYMBOL(con_is_bound);
+/**
+ * con_is_visible - checks whether the current console is visible
+ * @vc: virtual console
+ *
+ * RETURNS: zero if not visible, nonzero if visible
+ */
+bool con_is_visible(const struct vc_data *vc)
+{
+ WARN_CONSOLE_UNLOCKED();
+
+ return *vc->vc_display_fg == vc;
+}
+EXPORT_SYMBOL(con_is_visible);
+
/**
* con_debug_enter - prepare the console for the kernel debugger
* @sw: console driver
diff --git a/include/linux/console_struct.h b/include/linux/console_struct.h
index ed798e114663..24d4c16e3ae0 100644
--- a/include/linux/console_struct.h
+++ b/include/linux/console_struct.h
@@ -168,9 +168,6 @@ extern void vc_SAK(struct work_struct *work);
#define CUR_DEFAULT CUR_UNDERLINE
-static inline bool con_is_visible(const struct vc_data *vc)
-{
- return *vc->vc_display_fg == vc;
-}
+bool con_is_visible(const struct vc_data *vc);
#endif /* _LINUX_CONSOLE_STRUCT_H */
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/33] fbcon: call fbcon_fb_(un)registered directly
With
commit 6104c37094e729f3d4ce65797002112735d49cd1
Author: Daniel Vetter
Date: Tue Aug 1 17:32:07 2017 +0200
fbcon: Make fbcon a built-time depency for fbdev
we have a static dependency between fbcon and fbdev, and we can
replace the indirection through the notifier chain with a function
call.
v2: Sam Ravnborg noticed that mach-pxa/am200epd.c has a notifier too,
and listens to this.
...
Looking at the code it seems to wait for some fb to show up, so that
it can get the framebuffer base address from the fb_info struct. I
suspect his is some firmware fbdev. Then it uses that information to
let the real fbdev driver (metronomefb.c by the looks) get at the
framebuffer memory.
This doesn't looke like it's easy to fix (except by deleting the
entire thing, seems untouched since 2008, we might be able to get away
with that), so let's just stuff a few #ifdef into fb.h and fbmem.c and
cry over them for a bit.
Signed-off-by: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
Cc: Hans de Goede
Cc: Greg Kroah-Hartman
Cc: "Noralf Trønnes"
Cc: Yisheng Xie
Cc: Peter Rosin
Cc: "Michał Mirosław"
Cc: Thomas Zimmermann
Cc: Mikulas Patocka
Cc: linux-fb...@vger.kernel.org
Cc: Daniel Mack
Cc: Haojian Zhuang
Cc: Robert Jarzmik
Cc: Konstantin Khorenko
Cc: Prarit Bhargava
Cc: Gerd Hoffmann
Cc: Steve Sakoman
Cc: Steve Sakoman
Cc: linux-arm-ker...@lists.infradead.org
---
arch/arm/mach-pxa/am200epd.c | 13 +++--
drivers/video/fbdev/core/fbcon.c | 14 +++---
drivers/video/fbdev/core/fbmem.c | 24 +---
include/linux/fb.h | 7 +--
include/linux/fbcon.h| 4
5 files changed, 40 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-pxa/am200epd.c b/arch/arm/mach-pxa/am200epd.c
index 50e18ed37fa6..cac0bb09db14 100644
--- a/arch/arm/mach-pxa/am200epd.c
+++ b/arch/arm/mach-pxa/am200epd.c
@@ -347,8 +347,17 @@ int __init am200_init(void)
{
int ret;
- /* before anything else, we request notification for any fb
-* creation events */
+ /*
+* Before anything else, we request notification for any fb
+* creation events.
+*
+* FIXME: This is terrible and needs to be nuked. The notifier is used
+* to get at the fb base address from the boot splash fb driver, which
+* is then passed to metronomefb. Instaed of metronomfb or this board
+* support file here figuring this out on their own.
+*
+* See also the #ifdef in fbmem.c.
+*/
fb_register_client(&am200_fb_notif);
pxa2xx_mfp_config(ARRAY_AND_SIZE(am200_pin_config));
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 622d336cfc81..54d01f7284cb 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -3119,14 +3119,14 @@ static int fbcon_fb_unbind(int idx)
}
/* called with console_lock held */
-static int fbcon_fb_unregistered(struct fb_info *info)
+void fbcon_fb_unregistered(struct fb_info *info)
{
int i, idx;
WARN_CONSOLE_UNLOCKED();
if (deferred_takeover)
- return 0;
+ return;
idx = info->node;
for (i = first_fb_vc; i <= last_fb_vc; i++) {
@@ -3155,8 +3155,6 @@ static int fbcon_fb_unregistered(struct fb_info *info)
if (!num_registered_fb)
do_unregister_con_driver(&fb_con);
-
- return 0;
}
/* called with console_lock held */
@@ -3215,7 +3213,7 @@ static inline void fbcon_select_primary(struct fb_info
*info)
#endif /* CONFIG_FRAMEBUFFER_DETECT_PRIMARY */
/* called with console_lock held */
-static int fbcon_fb_registered(struct fb_info *info)
+int fbcon_fb_registered(struct fb_info *info)
{
int ret = 0, i, idx;
@@ -3359,12 +3357,6 @@ static int fbcon_event_notify(struct notifier_block
*self,
idx = info->node;
ret = fbcon_fb_unbind(idx);
break;
- case FB_EVENT_FB_REGISTERED:
- ret = fbcon_fb_registered(info);
- break;
- case FB_EVENT_FB_UNREGISTERED:
- ret = fbcon_fb_unregistered(info);
- break;
case FB_EVENT_SET_CONSOLE_MAP:
/* called with console lock held */
con2fb = event->data;
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 8ba674ffb3c9..bed7698ad18a 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1660,7 +1660,6 @@ MODULE_PARM_DESC(lockless_register_fb,
static int do_register_framebuffer(struct fb_info *fb_info)
{
int i, ret;
- struct fb_event event;
struct fb_videomode mode;
if (fb_check_foreignness(fb_info))
@@ -1723,7 +1722,14 @@ static int do_register_framebuffer(struct fb_info
*fb_info)
fb_add_videomode(&mode, &fb_info->modelist);
registered_fb[i] = fb_info;
-
[PATCH 12/33] fbdev/omap: sysfs files can't disappear before the device is gone
Which means lock_fb_info can never fail. Remove the error handling.
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
---
.../video/fbdev/omap2/omapfb/omapfb-sysfs.c | 21 +++
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c
b/drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c
index 8087a009c54f..bd0d20283372 100644
--- a/drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c
+++ b/drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c
@@ -60,8 +60,7 @@ static ssize_t store_rotate_type(struct device *dev,
if (rot_type != OMAP_DSS_ROT_DMA && rot_type != OMAP_DSS_ROT_VRFB)
return -EINVAL;
- if (!lock_fb_info(fbi))
- return -ENODEV;
+ lock_fb_info(fbi);
r = 0;
if (rot_type == ofbi->rotation_type)
@@ -112,8 +111,7 @@ static ssize_t store_mirror(struct device *dev,
if (r)
return r;
- if (!lock_fb_info(fbi))
- return -ENODEV;
+ lock_fb_info(fbi);
ofbi->mirror = mirror;
@@ -149,8 +147,7 @@ static ssize_t show_overlays(struct device *dev,
ssize_t l = 0;
int t;
- if (!lock_fb_info(fbi))
- return -ENODEV;
+ lock_fb_info(fbi);
omapfb_lock(fbdev);
for (t = 0; t < ofbi->num_overlays; t++) {
@@ -208,8 +205,7 @@ static ssize_t store_overlays(struct device *dev, struct
device_attribute *attr,
if (buf[len - 1] == '\n')
len = len - 1;
- if (!lock_fb_info(fbi))
- return -ENODEV;
+ lock_fb_info(fbi);
omapfb_lock(fbdev);
if (len > 0) {
@@ -340,8 +336,7 @@ static ssize_t show_overlays_rotate(struct device *dev,
ssize_t l = 0;
int t;
- if (!lock_fb_info(fbi))
- return -ENODEV;
+ lock_fb_info(fbi);
for (t = 0; t < ofbi->num_overlays; t++) {
l += snprintf(buf + l, PAGE_SIZE - l, "%s%d",
@@ -369,8 +364,7 @@ static ssize_t store_overlays_rotate(struct device *dev,
if (buf[len - 1] == '\n')
len = len - 1;
- if (!lock_fb_info(fbi))
- return -ENODEV;
+ lock_fb_info(fbi);
if (len > 0) {
char *p = (char *)buf;
@@ -453,8 +447,7 @@ static ssize_t store_size(struct device *dev, struct
device_attribute *attr,
size = PAGE_ALIGN(size);
- if (!lock_fb_info(fbi))
- return -ENODEV;
+ lock_fb_info(fbi);
if (display && display->driver->sync)
display->driver->sync(display);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/33] fbdev/aty128fb: Remove dead code
Motivated because it contains a struct display, which is a fbcon
internal data structure that I want to rename. It seems to have been
formerly used in drivers, but that's very long time ago.
Signed-off-by: Daniel Vetter
Cc: Paul Mackerras
Cc: linux-fb...@vger.kernel.org
---
drivers/video/fbdev/aty/aty128fb.c | 64 --
1 file changed, 64 deletions(-)
diff --git a/drivers/video/fbdev/aty/aty128fb.c
b/drivers/video/fbdev/aty/aty128fb.c
index 6cc46867ff57..c022ad7a49c2 100644
--- a/drivers/video/fbdev/aty/aty128fb.c
+++ b/drivers/video/fbdev/aty/aty128fb.c
@@ -2349,70 +2349,6 @@ static int aty128fb_ioctl(struct fb_info *info, u_int
cmd, u_long arg)
return -EINVAL;
}
-#if 0
-/*
- * Accelerated functions
- */
-
-static inline void aty128_rectcopy(int srcx, int srcy, int dstx, int dsty,
- u_int width, u_int height,
- struct fb_info_aty128 *par)
-{
- u32 save_dp_datatype, save_dp_cntl, dstval;
-
- if (!width || !height)
- return;
-
- dstval = depth_to_dst(par->current_par.crtc.depth);
- if (dstval == DST_24BPP) {
- srcx *= 3;
- dstx *= 3;
- width *= 3;
- } else if (dstval == -EINVAL) {
- printk("aty128fb: invalid depth or RGBA\n");
- return;
- }
-
- wait_for_fifo(2, par);
- save_dp_datatype = aty_ld_le32(DP_DATATYPE);
- save_dp_cntl = aty_ld_le32(DP_CNTL);
-
- wait_for_fifo(6, par);
- aty_st_le32(SRC_Y_X, (srcy << 16) | srcx);
- aty_st_le32(DP_MIX, ROP3_SRCCOPY | DP_SRC_RECT);
- aty_st_le32(DP_CNTL, DST_X_LEFT_TO_RIGHT | DST_Y_TOP_TO_BOTTOM);
- aty_st_le32(DP_DATATYPE, save_dp_datatype | dstval | SRC_DSTCOLOR);
-
- aty_st_le32(DST_Y_X, (dsty << 16) | dstx);
- aty_st_le32(DST_HEIGHT_WIDTH, (height << 16) | width);
-
- par->blitter_may_be_busy = 1;
-
- wait_for_fifo(2, par);
- aty_st_le32(DP_DATATYPE, save_dp_datatype);
- aty_st_le32(DP_CNTL, save_dp_cntl);
-}
-
-
-/*
- * Text mode accelerated functions
- */
-
-static void fbcon_aty128_bmove(struct display *p, int sy, int sx, int dy,
- int dx, int height, int width)
-{
- sx *= fontwidth(p);
- sy *= fontheight(p);
- dx *= fontwidth(p);
- dy *= fontheight(p);
- width *= fontwidth(p);
- height *= fontheight(p);
-
- aty128_rectcopy(sx, sy, dx, dy, width, height,
- (struct fb_info_aty128 *)p->fb_info);
-}
-#endif /* 0 */
-
static void aty128_set_suspend(struct aty128fb_par *par, int suspend)
{
u32 pmgt;
--
2.20.1
[PATCH 05/33] fbdev/sa1100fb: Remove dead code
Motivated because it contains a struct display, which is a fbcon
internal data structure that I want to rename. It seems to have been
formerly used in drivers, but that's very long time ago.
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
---
drivers/video/fbdev/sa1100fb.c | 25 -
1 file changed, 25 deletions(-)
diff --git a/drivers/video/fbdev/sa1100fb.c b/drivers/video/fbdev/sa1100fb.c
index 15ae50063296..f7f8dee044b1 100644
--- a/drivers/video/fbdev/sa1100fb.c
+++ b/drivers/video/fbdev/sa1100fb.c
@@ -974,35 +974,10 @@ static void sa1100fb_task(struct work_struct *w)
*/
static unsigned int sa1100fb_min_dma_period(struct sa1100fb_info *fbi)
{
-#if 0
- unsigned int min_period = (unsigned int)-1;
- int i;
-
- for (i = 0; i < MAX_NR_CONSOLES; i++) {
- struct display *disp = &fb_display[i];
- unsigned int period;
-
- /*
-* Do we own this display?
-*/
- if (disp->fb_info != &fbi->fb)
- continue;
-
- /*
-* Ok, calculate its DMA period
-*/
- period = sa1100fb_display_dma_period(&disp->var);
- if (period < min_period)
- min_period = period;
- }
-
- return min_period;
-#else
/*
* FIXME: we need to verify _all_ consoles.
*/
return sa1100fb_display_dma_period(&fbi->fb.var);
-#endif
}
/*
--
2.20.1
[PATCH 08/33] fbcon: s/struct display/struct fbcon_display/
This was formerly used in fbdev drivers (not sure why, predates most
git history), but now it's entirely an fbcon internal thing. Give it a
more specific name.
Signed-off-by: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
Cc: Hans de Goede
Cc: Greg Kroah-Hartman
Cc: Kees Cook
Cc: Prarit Bhargava
Cc: Konstantin Khorenko
Cc: Peter Rosin
Cc: Yisheng Xie
---
drivers/video/fbdev/core/fbcon.c | 74
drivers/video/fbdev/core/fbcon.h | 6 +--
2 files changed, 40 insertions(+), 40 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 786f9aab55df..5424051c8e1a 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -93,7 +93,7 @@ enum {
FBCON_LOGO_DONTSHOW = -3/* do not show the logo */
};
-static struct display fb_display[MAX_NR_CONSOLES];
+static struct fbcon_display fb_display[MAX_NR_CONSOLES];
static signed char con2fb_map[MAX_NR_CONSOLES];
static signed char con2fb_map_boot[MAX_NR_CONSOLES];
@@ -185,11 +185,11 @@ static __inline__ void ywrap_up(struct vc_data *vc, int
count);
static __inline__ void ywrap_down(struct vc_data *vc, int count);
static __inline__ void ypan_up(struct vc_data *vc, int count);
static __inline__ void ypan_down(struct vc_data *vc, int count);
-static void fbcon_bmove_rec(struct vc_data *vc, struct display *p, int sy, int
sx,
+static void fbcon_bmove_rec(struct vc_data *vc, struct fbcon_display *p, int
sy, int sx,
int dy, int dx, int height, int width, u_int
y_break);
static void fbcon_set_disp(struct fb_info *info, struct fb_var_screeninfo *var,
int unit);
-static void fbcon_redraw_move(struct vc_data *vc, struct display *p,
+static void fbcon_redraw_move(struct vc_data *vc, struct fbcon_display *p,
int line, int count, int dy);
static void fbcon_modechanged(struct fb_info *info);
static void fbcon_set_all_vcs(struct fb_info *info);
@@ -220,7 +220,7 @@ static void fbcon_rotate(struct fb_info *info, u32 rotate)
fb_info = registered_fb[con2fb_map[ops->currcon]];
if (info == fb_info) {
- struct display *p = &fb_display[ops->currcon];
+ struct fbcon_display *p = &fb_display[ops->currcon];
if (rotate < 4)
p->con_rotate = rotate;
@@ -235,7 +235,7 @@ static void fbcon_rotate_all(struct fb_info *info, u32
rotate)
{
struct fbcon_ops *ops = info->fbcon_par;
struct vc_data *vc;
- struct display *p;
+ struct fbcon_display *p;
int i;
if (!ops || ops->currcon < 0 || rotate > 3)
@@ -900,7 +900,7 @@ static int set_con2fb_map(int unit, int newidx, int user)
* Low Level Operations
*/
/* NOTE: fbcon cannot be __init: it may be called from do_take_over_console
later */
-static int var_to_display(struct display *disp,
+static int var_to_display(struct fbcon_display *disp,
struct fb_var_screeninfo *var,
struct fb_info *info)
{
@@ -925,7 +925,7 @@ static int var_to_display(struct display *disp,
}
static void display_to_var(struct fb_var_screeninfo *var,
- struct display *disp)
+ struct fbcon_display *disp)
{
fb_videomode_to_var(var, disp->mode);
var->xres_virtual = disp->xres_virtual;
@@ -946,7 +946,7 @@ static void display_to_var(struct fb_var_screeninfo *var,
static const char *fbcon_startup(void)
{
const char *display_desc = "frame buffer device";
- struct display *p = &fb_display[fg_console];
+ struct fbcon_display *p = &fb_display[fg_console];
struct vc_data *vc = vc_cons[fg_console].d;
const struct font_desc *font = NULL;
struct module *owner;
@@ -1060,7 +1060,7 @@ static void fbcon_init(struct vc_data *vc, int init)
struct fbcon_ops *ops;
struct vc_data **default_mode = vc->vc_display_fg;
struct vc_data *svc = *default_mode;
- struct display *t, *p = &fb_display[vc->vc_num];
+ struct fbcon_display *t, *p = &fb_display[vc->vc_num];
int logo = 1, new_rows, new_cols, rows, cols, charcnt = 256;
int cap, ret;
@@ -1203,7 +1203,7 @@ static void fbcon_init(struct vc_data *vc, int init)
ops->p = &fb_display[fg_console];
}
-static void fbcon_free_font(struct display *p, bool freefont)
+static void fbcon_free_font(struct fbcon_display *p, bool freefont)
{
if (freefont && p->userfont && p->fontdata && (--REFCOUNT(p->fontdata)
== 0))
kfree(p->fontdata - FONT_EXTRA_WORDS * sizeof(int));
@@ -1215,7 +1215,7 @@ static void set_vc_hi_font(struct vc_data *vc, bool set);
static void fbcon_deinit(struct vc_data *vc)
{
- struct display *p = &fb_display[vc->vc_num];
+ struct fbcon_display *p = &fb_display[vc->vc_num];
struct fb_info *info;
struc
[PATCH 02/33] fbdev: locking check for fb_set_suspend
Just drive-by, nothing systematic yet.
Signed-off-by: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
Cc: "Michał Mirosław"
Cc: Peter Rosin
Cc: Hans de Goede
Cc: Thomas Zimmermann
Cc: Manfred Schlaegl
Cc: Mikulas Patocka
Cc: Kees Cook
---
drivers/video/fbdev/core/fbmem.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index d1949c92be98..8ba674ffb3c9 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1985,6 +1985,8 @@ void fb_set_suspend(struct fb_info *info, int state)
{
struct fb_event event;
+ WARN_CONSOLE_UNLOCKED();
+
event.info = info;
if (state) {
fb_notifier_call_chain(FB_EVENT_SUSPEND, &event);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/33] vt: might_sleep() annotation for do_blank_screen
For symmetry reasons with do_unblank_screen, except without the
oops_in_progress special case.
Just a drive-by annotation while I'm trying to untangle the fbcon vs.
fbdev screen blank/unblank maze.
Signed-off-by: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: Nicolas Pitre
Cc: Adam Borowski
Cc: Martin Hostettler
Cc: Daniel Vetter
Cc: Mikulas Patocka
---
drivers/tty/vt/vt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index fdd12f8c3deb..bc9813b14c58 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -4159,6 +4159,8 @@ void do_blank_screen(int entering_gfx)
struct vc_data *vc = vc_cons[fg_console].d;
int i;
+ might_sleep();
+
WARN_CONSOLE_UNLOCKED();
if (console_blanked) {
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/33] fbdev/cyber2000: Remove struct display
Entirely unused.
Signed-off-by: Daniel Vetter
Cc: Russell King
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/video/fbdev/cyber2000fb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/cyber2000fb.c
b/drivers/video/fbdev/cyber2000fb.c
index 9a5751cb4e16..452ef07b3a06 100644
--- a/drivers/video/fbdev/cyber2000fb.c
+++ b/drivers/video/fbdev/cyber2000fb.c
@@ -61,7 +61,6 @@
struct cfb_info {
struct fb_info fb;
struct display_switch *dispsw;
- struct display *display;
unsigned char __iomem *region;
unsigned char __iomem *regs;
u_int id;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/33] fbcon notifier begone!
Hi all, I fixed the fbcon_exited mess that CI spotted (hopefully it works now, the code is still rather brittle imo). Plus all the little nits 0day and people found. Maarten slapped an rb onto the entire pile, but I feel like enough has changed that a 2nd look from him is warranted. I also added a backlight patch on top, I think that nicely highlights how the fb notifier is now only used for backlight notifications. Maybe we could rename it as a follow-up to make that clear. Oh and one rather badly looking thing: am200epd is abusing the notifier in very interesting ways. I guess a proper fix would be to figure out where the display boot memory reservation is some more direct way, instead of listening to the fw fb driver. But that's definitely outside of my knowledge, so I left it at a bunch of #ifdef and comments. I think we also still need an ack from Greg KH for the vt and staging bits. As usual, comments, review and testing very much welcome. btw for future plans: I think this is tricky enough (it's old code and all that) that we should let this soak for 2-3 kernel releases. I think the following would be nice subsequent cleanup/fixes: - push the console lock completely from fbmem.c to fbcon.c. I think we're mostly there with prep, but needs to pondering of corner cases. - move fbcon.c from using indices for tracking fb_info (and accessing registered_fbs without proper locking all the time) to real fb_info pointers with the right amount of refcounting. Mostly motivated by the fun I had trying to simplify fbcon_exit(). - make sure that fbcon call lock/unlock_fb when it calls fbmem.c functions, and sprinkle assert_lockdep_held around in fbmem.c. This needs the console_lock cleanups first. But I think that's material for maybe next year or so. Cheers, Daniel Daniel Vetter (33): dummycon: Sprinkle locking checks fbdev: locking check for fb_set_suspend vt: might_sleep() annotation for do_blank_screen vt: More locking checks fbdev/sa1100fb: Remove dead code fbdev/cyber2000: Remove struct display fbdev/aty128fb: Remove dead code fbcon: s/struct display/struct fbcon_display/ fbcon: Remove fbcon_has_exited fbcon: call fbcon_fb_(un)registered directly fbdev/sh_mobile: remove sh_mobile_lcdc_display_notify fbdev/omap: sysfs files can't disappear before the device is gone fbdev: sysfs files can't disappear before the device is gone staging/olpc: lock_fb_info can't fail fbdev/atyfb: lock_fb_info can't fail fbdev: lock_fb_info cannot fail fbcon: call fbcon_fb_bind directly fbdev: make unregister/unlink functions not fail fbdev: unify unlink_framebuffer paths fbdev/sh_mob: Remove fb notifier callback fbdev: directly call fbcon_suspended/resumed fbcon: Call fbcon_mode_deleted/new_modelist directly fbdev: Call fbcon_get_requirement directly Revert "backlight/fbcon: Add FB_EVENT_CONBLANK" fbmem: pull fbcon_fb_blanked out of fb_blank fbdev: remove FBINFO_MISC_USEREVENT around fb_blank fb: Flatten control flow in fb_set_var fbcon: replace FB_EVENT_MODE_CHANGE/_ALL with direct calls vgaswitcheroo: call fbcon_remap_all directly fbcon: Call con2fb_map functions directly fbcon: Document what I learned about fbcon locking staging/olpc_dcon: Add drm conversion to TODO backlight: simplify lcd notifier arch/arm/mach-pxa/am200epd.c | 13 +- drivers/gpu/vga/vga_switcheroo.c | 11 +- drivers/media/pci/ivtv/ivtvfb.c | 6 +- drivers/staging/fbtft/fbtft-core.c| 4 +- drivers/staging/olpc_dcon/TODO| 7 + drivers/staging/olpc_dcon/olpc_dcon.c | 6 +- drivers/tty/vt/vt.c | 18 + drivers/video/backlight/backlight.c | 2 +- drivers/video/backlight/lcd.c | 12 - drivers/video/console/dummycon.c | 6 + drivers/video/fbdev/aty/aty128fb.c| 64 --- drivers/video/fbdev/aty/atyfb_base.c | 3 +- drivers/video/fbdev/core/fbcmap.c | 6 +- drivers/video/fbdev/core/fbcon.c | 311 ++ drivers/video/fbdev/core/fbcon.h | 6 +- drivers/video/fbdev/core/fbmem.c | 399 +++--- drivers/video/fbdev/core/fbsysfs.c| 20 +- drivers/video/fbdev/cyber2000fb.c | 1 - drivers/video/fbdev/neofb.c | 9 +- .../video/fbdev/omap2/omapfb/omapfb-sysfs.c | 21 +- drivers/video/fbdev/sa1100fb.c| 25 -- drivers/video/fbdev/savage/savagefb_driver.c | 9 +- drivers/video/fbdev/sh_mobile_lcdcfb.c| 112 + drivers/video/fbdev/sh_mobile_lcdcfb.h| 5 - include/linux/console_struct.h| 5 +- include/linux/fb.h| 45 +- include/linux/fbcon.h | 30 ++ 27 files changed, 394 insertions(+), 762 deletions(-) -- 2.20.1 ___ dri-devel mailing
[PATCH 11/33] fbdev/sh_mobile: remove sh_mobile_lcdc_display_notify
It's dead code, and removing it avoids me having to understand
what it's doing with lock_fb_info.
Signed-off-by: Daniel Vetter
Reviewed-by: Geert Uytterhoeven
Cc: Geert Uytterhoeven
Cc: Daniel Vetter
---
drivers/video/fbdev/sh_mobile_lcdcfb.c | 63 --
drivers/video/fbdev/sh_mobile_lcdcfb.h | 5 --
2 files changed, 68 deletions(-)
diff --git a/drivers/video/fbdev/sh_mobile_lcdcfb.c
b/drivers/video/fbdev/sh_mobile_lcdcfb.c
index dc46be38c970..c5924f5e98c6 100644
--- a/drivers/video/fbdev/sh_mobile_lcdcfb.c
+++ b/drivers/video/fbdev/sh_mobile_lcdcfb.c
@@ -556,67 +556,6 @@ sh_mobile_lcdc_must_reconfigure(struct sh_mobile_lcdc_chan
*ch,
static int sh_mobile_lcdc_check_var(struct fb_var_screeninfo *var,
struct fb_info *info);
-static int sh_mobile_lcdc_display_notify(struct sh_mobile_lcdc_chan *ch,
-enum sh_mobile_lcdc_entity_event event,
-const struct fb_videomode *mode,
-const struct fb_monspecs *monspec)
-{
- struct fb_info *info = ch->info;
- struct fb_var_screeninfo var;
- int ret = 0;
-
- switch (event) {
- case SH_MOBILE_LCDC_EVENT_DISPLAY_CONNECT:
- /* HDMI plug in */
- console_lock();
- if (lock_fb_info(info)) {
-
-
- ch->display.width = monspec->max_x * 10;
- ch->display.height = monspec->max_y * 10;
-
- if (!sh_mobile_lcdc_must_reconfigure(ch, mode) &&
- info->state == FBINFO_STATE_RUNNING) {
- /* First activation with the default monitor.
-* Just turn on, if we run a resume here, the
-* logo disappears.
-*/
- info->var.width = ch->display.width;
- info->var.height = ch->display.height;
- sh_mobile_lcdc_display_on(ch);
- } else {
- /* New monitor or have to wake up */
- fb_set_suspend(info, 0);
- }
-
-
- unlock_fb_info(info);
- }
- console_unlock();
- break;
-
- case SH_MOBILE_LCDC_EVENT_DISPLAY_DISCONNECT:
- /* HDMI disconnect */
- console_lock();
- if (lock_fb_info(info)) {
- fb_set_suspend(info, 1);
- unlock_fb_info(info);
- }
- console_unlock();
- break;
-
- case SH_MOBILE_LCDC_EVENT_DISPLAY_MODE:
- /* Validate a proposed new mode */
- fb_videomode_to_var(&var, mode);
- var.bits_per_pixel = info->var.bits_per_pixel;
- var.grayscale = info->var.grayscale;
- ret = sh_mobile_lcdc_check_var(&var, info);
- break;
- }
-
- return ret;
-}
-
/*
-
* Format helpers
*/
@@ -2540,8 +2479,6 @@ sh_mobile_lcdc_channel_init(struct sh_mobile_lcdc_chan
*ch)
unsigned int max_size;
unsigned int i;
- ch->notify = sh_mobile_lcdc_display_notify;
-
/* Validate the format. */
format = sh_mobile_format_info(cfg->fourcc);
if (format == NULL) {
diff --git a/drivers/video/fbdev/sh_mobile_lcdcfb.h
b/drivers/video/fbdev/sh_mobile_lcdcfb.h
index b8e47a8bd8ab..589400372098 100644
--- a/drivers/video/fbdev/sh_mobile_lcdcfb.h
+++ b/drivers/video/fbdev/sh_mobile_lcdcfb.h
@@ -87,11 +87,6 @@ struct sh_mobile_lcdc_chan {
unsigned long base_addr_c;
unsigned int line_size;
- int (*notify)(struct sh_mobile_lcdc_chan *ch,
- enum sh_mobile_lcdc_entity_event event,
- const struct fb_videomode *mode,
- const struct fb_monspecs *monspec);
-
/* Backlight */
struct backlight_device *bl;
unsigned int bl_brightness;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 13/33] fbdev: sysfs files can't disappear before the device is gone
Which means lock_fb_info can never fail. Remove the error handling.
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Rob Clark
---
drivers/video/fbdev/core/fbsysfs.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/video/fbdev/core/fbsysfs.c
b/drivers/video/fbdev/core/fbsysfs.c
index 44cca39f2b51..5f329278e55f 100644
--- a/drivers/video/fbdev/core/fbsysfs.c
+++ b/drivers/video/fbdev/core/fbsysfs.c
@@ -179,10 +179,7 @@ static ssize_t store_modes(struct device *device,
return -EINVAL;
console_lock();
- if (!lock_fb_info(fb_info)) {
- console_unlock();
- return -ENODEV;
- }
+ lock_fb_info(fb_info);
list_splice(&fb_info->modelist, &old_list);
fb_videomode_to_modelist((const struct fb_videomode *)buf, i,
@@ -409,10 +406,7 @@ static ssize_t store_fbstate(struct device *device,
state = simple_strtoul(buf, &last, 0);
console_lock();
- if (!lock_fb_info(fb_info)) {
- console_unlock();
- return -ENODEV;
- }
+ lock_fb_info(fb_info);
fb_set_suspend(fb_info, (int)state);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/33] fbcon: Remove fbcon_has_exited
This is unused code since
commit 6104c37094e729f3d4ce65797002112735d49cd1
Author: Daniel Vetter
Date: Tue Aug 1 17:32:07 2017 +0200
fbcon: Make fbcon a built-time depency for fbdev
when fbcon was made a compile-time static dependency of fbdev. We
can't exit fbcon anymore without exiting fbdev first, which only works
if all fbdev drivers have unloaded already. Hence this is all dead
code.
v2: I missed that fbcon_exit is also called from con_deinit stuff, and
there fbcon_has_exited prevents double-cleanup. But we can fix that
by properly resetting con2fb_map[] to all -1, which is used everywhere
else to indicate "no fb_info allocate to this console". With that
change the double-cleanup (which resulted in a module refcount underflow,
among other things) is prevented.
Aside: con2fb_map is a signed char, so don't register more than 128 fb_info
or hilarity will ensue.
v3: CI showed me that I still didn't fully understand what's going on
here. The leaked references in con2fb_map have been used upon
rebinding the fb console in fbcon_init. It worked because fbdev
unregistering still cleaned out con2fb_map, and reset it to info_idx.
If the last fbdev driver unregistered, then it also reset info_idx,
and unregistered the fbcon driver.
Imo that's all a bit fragile, so let's keep the con2fb_map reset to
-1, and in fbcon_init pick info_idx if we're starting fresh. That
means unbinding and rebinding will cleanse the mapping, but why are
you doing that if you want to retain the mapping, so should be fine.
Also, I think info_idx == -1 is impossible in fbcon_init - we
unregister the fbcon in that case. So catch&warn about that.
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
Cc: Hans de Goede
Cc: "Noralf Trønnes"
Cc: Yisheng Xie
Cc: Konstantin Khorenko
Cc: Prarit Bhargava
Cc: Kees Cook
---
drivers/video/fbdev/core/fbcon.c | 39 +---
1 file changed, 6 insertions(+), 33 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 5424051c8e1a..622d336cfc81 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -112,7 +112,6 @@ static int softback_lines;
static int first_fb_vc;
static int last_fb_vc = MAX_NR_CONSOLES - 1;
static int fbcon_is_default = 1;
-static int fbcon_has_exited;
static int primary_device = -1;
static int fbcon_has_console_bind;
@@ -1050,7 +1049,6 @@ static const char *fbcon_startup(void)
info->var.bits_per_pixel);
fbcon_add_cursor_timer(info);
- fbcon_has_exited = 0;
return display_desc;
}
@@ -1064,9 +1062,13 @@ static void fbcon_init(struct vc_data *vc, int init)
int logo = 1, new_rows, new_cols, rows, cols, charcnt = 256;
int cap, ret;
- if (info_idx == -1 || info == NULL)
+ if (WARN_ON(info_idx == -1))
return;
+ if (con2fb_map[vc->vc_num] == -1)
+ con2fb_map[vc->vc_num] = info_idx;
+
+ info = registered_fb[con2fb_map[vc->vc_num]];
cap = info->flags;
if (logo_shown < 0 && console_loglevel <= CONSOLE_LOGLEVEL_QUIET)
@@ -3336,14 +3338,6 @@ static int fbcon_event_notify(struct notifier_block
*self,
struct fb_blit_caps *caps;
int idx, ret = 0;
- /*
-* ignore all events except driver registration and deregistration
-* if fbcon is not active
-*/
- if (fbcon_has_exited && !(action == FB_EVENT_FB_REGISTERED ||
- action == FB_EVENT_FB_UNREGISTERED))
- goto done;
-
switch(action) {
case FB_EVENT_SUSPEND:
fbcon_suspended(info);
@@ -3396,7 +3390,6 @@ static int fbcon_event_notify(struct notifier_block *self,
fbcon_remap_all(idx);
break;
}
-done:
return ret;
}
@@ -3443,9 +3436,6 @@ static ssize_t store_rotate(struct device *device,
int rotate, idx;
char **last = NULL;
- if (fbcon_has_exited)
- return count;
-
console_lock();
idx = con2fb_map[fg_console];
@@ -3468,9 +3458,6 @@ static ssize_t store_rotate_all(struct device *device,
int rotate, idx;
char **last = NULL;
- if (fbcon_has_exited)
- return count;
-
console_lock();
idx = con2fb_map[fg_console];
@@ -3491,9 +3478,6 @@ static ssize_t show_rotate(struct device *device,
struct fb_info *info;
int rotate = 0, idx;
- if (fbcon_has_exited)
- return 0;
-
console_lock();
idx = con2fb_map[fg_console];
@@ -3514,9 +3498,6 @@ static ssize_t show_cursor_blink(struct device *device,
struct fbcon_ops *ops;
int idx, blink = -1;
- if (fbcon_has_exited)
- return 0;
-
console_lock();
idx = con2fb_map[fg_console];
@@ -3543,9 +3524,6 @@ static ssize_t store_cursor_blink
[PATCH 21/33] fbdev: directly call fbcon_suspended/resumed
With the sh_mobile notifier removed we can just directly call the
fbcon code here.
v2: Remove now unused local variable.
v3: fixup !CONFIG_FRAMEBUFFER_CONSOLE, noticed by kbuild
Signed-off-by: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
Cc: Hans de Goede
Cc: Greg Kroah-Hartman
Cc: Prarit Bhargava
Cc: Kees Cook
Cc: Konstantin Khorenko
Cc: Yisheng Xie
Cc: "Michał Mirosław"
Cc: Peter Rosin
Cc: Mikulas Patocka
Cc: linux-fb...@vger.kernel.org
---
drivers/video/fbdev/core/fbcon.c | 10 ++
drivers/video/fbdev/core/fbmem.c | 7 ++-
include/linux/fb.h | 8
include/linux/fbcon.h| 4
4 files changed, 8 insertions(+), 21 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index f114b4c88796..24ea6e4fbee0 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2919,7 +2919,7 @@ static int fbcon_set_origin(struct vc_data *vc)
return 0;
}
-static void fbcon_suspended(struct fb_info *info)
+void fbcon_suspended(struct fb_info *info)
{
struct vc_data *vc = NULL;
struct fbcon_ops *ops = info->fbcon_par;
@@ -2932,7 +2932,7 @@ static void fbcon_suspended(struct fb_info *info)
fbcon_cursor(vc, CM_ERASE);
}
-static void fbcon_resumed(struct fb_info *info)
+void fbcon_resumed(struct fb_info *info)
{
struct vc_data *vc;
struct fbcon_ops *ops = info->fbcon_par;
@@ -3330,12 +3330,6 @@ static int fbcon_event_notify(struct notifier_block
*self,
int idx, ret = 0;
switch(action) {
- case FB_EVENT_SUSPEND:
- fbcon_suspended(info);
- break;
- case FB_EVENT_RESUME:
- fbcon_resumed(info);
- break;
case FB_EVENT_MODE_CHANGE:
fbcon_modechanged(info);
break;
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index bee45e9405b8..73269dedcd45 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1917,17 +1917,14 @@ EXPORT_SYMBOL(unregister_framebuffer);
*/
void fb_set_suspend(struct fb_info *info, int state)
{
- struct fb_event event;
-
WARN_CONSOLE_UNLOCKED();
- event.info = info;
if (state) {
- fb_notifier_call_chain(FB_EVENT_SUSPEND, &event);
+ fbcon_suspended(info);
info->state = FBINFO_STATE_SUSPENDED;
} else {
info->state = FBINFO_STATE_RUNNING;
- fb_notifier_call_chain(FB_EVENT_RESUME, &event);
+ fbcon_resumed(info);
}
}
EXPORT_SYMBOL(fb_set_suspend);
diff --git a/include/linux/fb.h b/include/linux/fb.h
index b90cf7d56bd8..794b386415b7 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -126,14 +126,6 @@ struct fb_cursor_user {
/* The resolution of the passed in fb_info about to change */
#define FB_EVENT_MODE_CHANGE 0x01
-/* The display on this fb_info is being suspended, no access to the
- * framebuffer is allowed any more after that call returns
- */
-#define FB_EVENT_SUSPEND 0x02
-/* The display on this fb_info was resumed, you can restore the display
- * if you own it
- */
-#define FB_EVENT_RESUME0x03
/* An entry from the modelist was removed */
#define FB_EVENT_MODE_DELETE0x04
diff --git a/include/linux/fbcon.h b/include/linux/fbcon.h
index 38d44fdb6d14..790c42ec7b5d 100644
--- a/include/linux/fbcon.h
+++ b/include/linux/fbcon.h
@@ -7,12 +7,16 @@ void __exit fb_console_exit(void);
int fbcon_fb_registered(struct fb_info *info);
void fbcon_fb_unregistered(struct fb_info *info);
void fbcon_fb_unbind(struct fb_info *info);
+void fbcon_suspended(struct fb_info *info);
+void fbcon_resumed(struct fb_info *info);
#else
static inline void fb_console_init(void) {}
static inline void fb_console_exit(void) {}
static inline int fbcon_fb_registered(struct fb_info *info) { return 0; }
static inline void fbcon_fb_unregistered(struct fb_info *info) {}
static inline void fbcon_fb_unbind(struct fb_info *info) {}
+static inline void fbcon_suspended(struct fb_info *info) {}
+static inline void fbcon_resumed(struct fb_info *info) {}
#endif
#endif /* _LINUX_FBCON_H */
--
2.20.1
[PATCH 33/33] backlight: simplify lcd notifier
With all the work I've done on replacing fb notifier calls with direct
calls into fbcon the backlight/lcd notifier is the only user left.
It will only receive events now that it cares about, hence we can
remove this check.
Signed-off-by: Daniel Vetter
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
---
drivers/video/backlight/lcd.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/video/backlight/lcd.c b/drivers/video/backlight/lcd.c
index a758039475d0..8ea5e5937ae2 100644
--- a/drivers/video/backlight/lcd.c
+++ b/drivers/video/backlight/lcd.c
@@ -29,17 +29,6 @@ static int fb_notifier_callback(struct notifier_block *self,
struct lcd_device *ld;
struct fb_event *evdata = data;
- /* If we aren't interested in this event, skip it immediately ... */
- switch (event) {
- case FB_EVENT_BLANK:
- case FB_EVENT_MODE_CHANGE:
- case FB_EARLY_EVENT_BLANK:
- case FB_R_EARLY_EVENT_BLANK:
- break;
- default:
- return 0;
- }
-
ld = container_of(self, struct lcd_device, fb_notif);
if (!ld->ops)
return 0;
--
2.20.1
[PATCH 15/33] fbdev/atyfb: lock_fb_info can't fail
It's properly protected by reboot_lock. Signed-off-by: Daniel Vetter Cc: Mikulas Patocka Cc: "David S. Miller" Cc: "Ville Syrjälä" Cc: Bartlomiej Zolnierkiewicz Cc: Daniel Vetter --- drivers/video/fbdev/aty/atyfb_base.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/video/fbdev/aty/atyfb_base.c b/drivers/video/fbdev/aty/atyfb_base.c index b6fe103df145..eebb62d82a23 100644 --- a/drivers/video/fbdev/aty/atyfb_base.c +++ b/drivers/video/fbdev/aty/atyfb_base.c @@ -3916,8 +3916,7 @@ static int atyfb_reboot_notify(struct notifier_block *nb, if (!reboot_info) goto out; - if (!lock_fb_info(reboot_info)) - goto out; + lock_fb_info(reboot_info); par = reboot_info->par; -- 2.20.1
[PATCH 29/33] vgaswitcheroo: call fbcon_remap_all directly
While at it, clean up the interface a bit and push the console locking
into fbcon.c.
v2: Remove now outdated comment (Lukas).
v3: Forgot to add static inline to the dummy function.
Acked-by: Lukas Wunner
Signed-off-by: Daniel Vetter
Cc: Lukas Wunner
Cc: David Airlie
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: Bartlomiej Zolnierkiewicz
Cc: Hans de Goede
Cc: Yisheng Xie
Cc: linux-fb...@vger.kernel.org
---
drivers/gpu/vga/vga_switcheroo.c | 11 +++
drivers/video/fbdev/core/fbcon.c | 14 +-
include/linux/fb.h | 2 --
include/linux/fbcon.h| 2 ++
4 files changed, 10 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index a132c37d7334..65d7541c413a 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -736,14 +737,8 @@ static int vga_switchto_stage2(struct
vga_switcheroo_client *new_client)
if (!active->driver_power_control)
set_audio_state(active->id, VGA_SWITCHEROO_OFF);
- if (new_client->fb_info) {
- struct fb_event event;
-
- console_lock();
- event.info = new_client->fb_info;
- fb_notifier_call_chain(FB_EVENT_REMAP_ALL_CONSOLE, &event);
- console_unlock();
- }
+ if (new_client->fb_info)
+ fbcon_remap_all(new_client->fb_info);
mutex_lock(&vgasr_priv.mux_hw_lock);
ret = vgasr_priv.handler->switchto(new_client->id);
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index a07c261da53a..e08e984e2511 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -3149,17 +3149,16 @@ void fbcon_fb_unregistered(struct fb_info *info)
do_unregister_con_driver(&fb_con);
}
-/* called with console_lock held */
-static void fbcon_remap_all(int idx)
+void fbcon_remap_all(struct fb_info *info)
{
- int i;
-
- WARN_CONSOLE_UNLOCKED();
+ int i, idx = info->node;
+ console_lock();
if (deferred_takeover) {
for (i = first_fb_vc; i <= last_fb_vc; i++)
con2fb_map_boot[i] = idx;
fbcon_map_override();
+ console_unlock();
return;
}
@@ -3172,6 +3171,7 @@ static void fbcon_remap_all(int idx)
first_fb_vc + 1, last_fb_vc + 1);
info_idx = idx;
}
+ console_unlock();
}
#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY
@@ -3337,10 +3337,6 @@ static int fbcon_event_notify(struct notifier_block
*self,
con2fb = event->data;
con2fb->framebuffer = con2fb_map[con2fb->console - 1];
break;
- case FB_EVENT_REMAP_ALL_CONSOLE:
- idx = info->node;
- fbcon_remap_all(idx);
- break;
}
return ret;
}
diff --git a/include/linux/fb.h b/include/linux/fb.h
index f9c212f9b661..25e4b885f5b3 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -139,8 +139,6 @@ struct fb_cursor_user {
#define FB_EVENT_SET_CONSOLE_MAP0x08
/* A display blank is requested */
#define FB_EVENT_BLANK 0x09
-/* CONSOLE-SPECIFIC: remap all consoles to new fb - for vga_switcheroo */
-#define FB_EVENT_REMAP_ALL_CONSOLE 0x0F
/* A hardware display blank early change occurred */
#define FB_EARLY_EVENT_BLANK 0x10
/* A hardware display blank revert early change occurred */
diff --git a/include/linux/fbcon.h b/include/linux/fbcon.h
index de31eeb22c97..69f900d289b2 100644
--- a/include/linux/fbcon.h
+++ b/include/linux/fbcon.h
@@ -16,6 +16,7 @@ void fbcon_get_requirement(struct fb_info *info,
struct fb_blit_caps *caps);
void fbcon_fb_blanked(struct fb_info *info, int blank);
void fbcon_update_vcs(struct fb_info *info, bool all);
+void fbcon_remap_all(struct fb_info *info);
#else
static inline void fb_console_init(void) {}
static inline void fb_console_exit(void) {}
@@ -31,6 +32,7 @@ static inline void fbcon_get_requirement(struct fb_info *info,
struct fb_blit_caps *caps) {}
static inline void fbcon_fb_blanked(struct fb_info *info, int blank) {}
static inline void fbcon_update_vcs(struct fb_info *info, bool all) {}
+static inline void fbcon_remap_all(struct fb_info *info) {}
#endif
#endif /* _LINUX_FBCON_H */
--
2.20.1
[PATCH 32/33] staging/olpc_dcon: Add drm conversion to TODO
this driver is pretty horrible from a design pov, and needs a complete overhaul. Concrete thing that annoys me is that it looks at registered_fb, which is an internal thing to fbmem.c and fbcon.c. And ofc it gets the lifetime rules all wrong (it should at least use get/put_fb_info). Looking at the history, there's been an attempt at dropping this from staging in 2016, but that had to be reverted. Since then not real effort except the usual stream of trivial patches, and fbdev has been formally closed for any new hw support. Time to try again and drop this? Signed-off-by: Daniel Vetter Cc: Jens Frederich Cc: Daniel Drake Cc: Jon Nettleton --- drivers/staging/olpc_dcon/TODO | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/staging/olpc_dcon/TODO b/drivers/staging/olpc_dcon/TODO index 665a0b061719..fe09efbc7f77 100644 --- a/drivers/staging/olpc_dcon/TODO +++ b/drivers/staging/olpc_dcon/TODO @@ -1,4 +1,11 @@ TODO: + - complete rewrite: + 1. The underlying fbdev drivers need to be converted into drm kernel +modesetting drivers. + 2. The dcon low-power display mode can then be integrated using the +drm damage tracking and self-refresh helpers. + This bolted-on self-refresh support that digs around in fbdev + internals, but isn't properly integrated, is not the correct solution. - see if vx855 gpio API can be made similar enough to cs5535 so we can share more code - convert all uses of the old GPIO API from to the -- 2.20.1
[PATCH 30/33] fbcon: Call con2fb_map functions directly
These are actually fbcon ioctls which just happen to be exposed
through /dev/fb*. They completely ignore which fb_info they're called
on, and I think the userspace tool even hardcodes to /dev/fb0.
Hence just forward the entire thing to fbcon.c wholesale.
Note that this patch drops the fb_lock/unlock on the set side. Since
the ioctl can operate on any fb (as passed in through
con2fb.framebuffer) this is bogus. Also note that fbcon.c in general
never calls fb_lock on anything, so this has been badly broken
already.
With this the last user of the fbcon notifier callback is gone, and we
can garbage collect that too.
v2: add missing uaccess.h include (alpha fails to compile otherwise),
reported by kbuild.
v3: Remember to also drop the #defines (Maarten)
v4: Add the static inline to dummy functions.
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Hans de Goede
Cc: Yisheng Xie
Cc: "Michał Mirosław"
Cc: Peter Rosin
Cc: Mikulas Patocka
---
drivers/video/fbdev/core/fbcon.c | 59 +++-
drivers/video/fbdev/core/fbmem.c | 34 ++
include/linux/fb.h | 4 ---
include/linux/fbcon.h| 4 +++
4 files changed, 42 insertions(+), 59 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index e08e984e2511..6a4bbb8407c0 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -76,6 +76,7 @@
#include
#include
#include /* For counting font checksums */
+#include
#include
#include
@@ -3318,29 +3319,47 @@ void fbcon_get_requirement(struct fb_info *info,
}
}
-static int fbcon_event_notify(struct notifier_block *self,
- unsigned long action, void *data)
+int fbcon_set_con2fb_map_ioctl(void __user *argp)
{
- struct fb_event *event = data;
- struct fb_info *info = event->info;
- struct fb_con2fbmap *con2fb;
- int idx, ret = 0;
+ struct fb_con2fbmap con2fb;
+ int ret;
- switch(action) {
- case FB_EVENT_SET_CONSOLE_MAP:
- /* called with console lock held */
- con2fb = event->data;
- ret = set_con2fb_map(con2fb->console - 1,
-con2fb->framebuffer, 1);
- break;
- case FB_EVENT_GET_CONSOLE_MAP:
- con2fb = event->data;
- con2fb->framebuffer = con2fb_map[con2fb->console - 1];
- break;
+ if (copy_from_user(&con2fb, argp, sizeof(con2fb)))
+ return -EFAULT;
+ if (con2fb.console < 1 || con2fb.console > MAX_NR_CONSOLES)
+ return -EINVAL;
+ if (con2fb.framebuffer >= FB_MAX)
+ return -EINVAL;
+ if (!registered_fb[con2fb.framebuffer])
+ request_module("fb%d", con2fb.framebuffer);
+ if (!registered_fb[con2fb.framebuffer]) {
+ return -EINVAL;
}
+
+ console_lock();
+ ret = set_con2fb_map(con2fb.console - 1,
+con2fb.framebuffer, 1);
+ console_unlock();
+
return ret;
}
+int fbcon_get_con2fb_map_ioctl(void __user *argp)
+{
+ struct fb_con2fbmap con2fb;
+
+ if (copy_from_user(&con2fb, argp, sizeof(con2fb)))
+ return -EFAULT;
+ if (con2fb.console < 1 || con2fb.console > MAX_NR_CONSOLES)
+ return -EINVAL;
+
+ console_lock();
+ con2fb.framebuffer = con2fb_map[con2fb.console - 1];
+ console_unlock();
+
+ return copy_to_user(argp, &con2fb, sizeof(con2fb)) ? -EFAULT : 0;
+}
+
/*
* The console `switch' structure for the frame buffer based console
*/
@@ -3372,10 +3391,6 @@ static const struct consw fb_con = {
.con_debug_leave= fbcon_debug_leave,
};
-static struct notifier_block fbcon_event_notifier = {
- .notifier_call = fbcon_event_notify,
-};
-
static ssize_t store_rotate(struct device *device,
struct device_attribute *attr, const char *buf,
size_t count)
@@ -3648,7 +3663,6 @@ void __init fb_console_init(void)
int i;
console_lock();
- fb_register_client(&fbcon_event_notifier);
fbcon_device = device_create(fb_class, NULL, MKDEV(0, 0), NULL,
"fbcon");
@@ -3684,7 +3698,6 @@ static void __exit fbcon_deinit_device(void)
void __exit fb_console_exit(void)
{
console_lock();
- fb_unregister_client(&fbcon_event_notifier);
fbcon_deinit_device();
device_destroy(fb_class, MKDEV(0, 0));
fbcon_exit();
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index dd1a708df1a7..64dd732021d8 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1092,10 +1092,8 @@ static long do_fb_ioctl(struct fb_info *info, unsigned
int cmd,
struct fb_ops *
[PATCH 16/33] fbdev: lock_fb_info cannot fail
Ever since
commit c47747fde931c02455683bd00ea43eaa62f35b0e
Author: Linus Torvalds
Date: Wed May 11 14:58:34 2011 -0700
fbmem: make read/write/ioctl use the frame buffer at open time
fbdev has gained proper refcounting for the fbinfo attached to any
open files, which means that the backing driver (stored in
fb_info->fbops) cannot untimely disappear anymore.
The only thing that can happen is that the entire device just outright
disappears and gets unregistered, but file_fb_info does check for
that. Except that it's racy - it only checks once at the start of a
file_ops, there's no guarantee that the underlying fbdev won't
untimely disappear. Aside: A proper way to fix that race is probably
to replicate the srcu trickery we've rolled out in drm.
But given that this race has existed since forever it's probably not
one we need to fix right away. do_unregister_framebuffer also nowhere
clears fb_info->fbops, hence the check in lock_fb_info can't possible
catch a disappearing fbdev later on.
Long story short: Ever since the above commit the fb_info->fbops
checks have essentially become dead code. Remove this all.
Aside from the file_ops callbacks, and stuff called from there
there's only register/unregister code left. If that goes wrong a driver
managed to register/unregister a device instance twice or in the wrong
order. That's just a driver bug.
v2:
- fb_mmap had an open-coded version of the fbinfo->fops check, because
it doesn't need the fbinfo->lock. Delete that too.
- Use the wrapper function in fb_open/release now, since no difference
anymore.
Signed-off-by: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
Cc: Hans de Goede
Cc: Yisheng Xie
Cc: Sergey Senozhatsky
Cc: "Noralf Trønnes"
Cc: Peter Rosin
Cc: "Michał Mirosław"
Cc: Mikulas Patocka
Cc: "Gustavo A. R. Silva"
Cc: linux-fb...@vger.kernel.org
---
drivers/video/fbdev/core/fbcmap.c | 6 +--
drivers/video/fbdev/core/fbcon.c | 3 +-
drivers/video/fbdev/core/fbmem.c | 73 +++
include/linux/fb.h| 5 ++-
4 files changed, 23 insertions(+), 64 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcmap.c
b/drivers/video/fbdev/core/fbcmap.c
index 2811c4afde01..e5ae33c1a8e8 100644
--- a/drivers/video/fbdev/core/fbcmap.c
+++ b/drivers/video/fbdev/core/fbcmap.c
@@ -285,11 +285,7 @@ int fb_set_user_cmap(struct fb_cmap_user *cmap, struct
fb_info *info)
goto out;
}
umap.start = cmap->start;
- if (!lock_fb_info(info)) {
- rc = -ENODEV;
- goto out;
- }
-
+ lock_fb_info(info);
rc = fb_set_cmap(&umap, info);
unlock_fb_info(info);
out:
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 54d01f7284cb..c3353db35adc 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2364,8 +2364,7 @@ static void fbcon_generic_blank(struct vc_data *vc,
struct fb_info *info,
}
- if (!lock_fb_info(info))
- return;
+ lock_fb_info(info);
event.info = info;
event.data = ␣
fb_notifier_call_chain(FB_EVENT_CONBLANK, &event);
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index bed7698ad18a..d73762324ca2 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -80,17 +80,6 @@ static void put_fb_info(struct fb_info *fb_info)
fb_info->fbops->fb_destroy(fb_info);
}
-int lock_fb_info(struct fb_info *info)
-{
- mutex_lock(&info->lock);
- if (!info->fbops) {
- mutex_unlock(&info->lock);
- return 0;
- }
- return 1;
-}
-EXPORT_SYMBOL(lock_fb_info);
-
/*
* Helpers
*/
@@ -1121,8 +1110,7 @@ static long do_fb_ioctl(struct fb_info *info, unsigned
int cmd,
switch (cmd) {
case FBIOGET_VSCREENINFO:
- if (!lock_fb_info(info))
- return -ENODEV;
+ lock_fb_info(info);
var = info->var;
unlock_fb_info(info);
@@ -1132,10 +1120,7 @@ static long do_fb_ioctl(struct fb_info *info, unsigned
int cmd,
if (copy_from_user(&var, argp, sizeof(var)))
return -EFAULT;
console_lock();
- if (!lock_fb_info(info)) {
- console_unlock();
- return -ENODEV;
- }
+ lock_fb_info(info);
info->flags |= FBINFO_MISC_USEREVENT;
ret = fb_set_var(info, &var);
info->flags &= ~FBINFO_MISC_USEREVENT;
@@ -1145,8 +1130,7 @@ static long do_fb_ioctl(struct fb_info *info, unsigned
int cmd,
ret = -EFAULT;
break;
case FBIOGET_FSCREENINFO:
- if (!lock_fb_info(info))
- return -ENODEV;
+ lock_fb_info(info);
fix
[PATCH 20/33] fbdev/sh_mob: Remove fb notifier callback
This seems to be entirely defunct:
- The FB_EVEN_SUSPEND/RESUME events are only sent out by
fb_set_suspend. Which is supposed to be called by drivers in their
suspend/resume hooks, and not itself call into drivers. Luckily
sh_mob doesn't call fb_set_suspend, so this seems to do nothing
useful.
- The notify hook calls sh_mobile_fb_reconfig() which in turn can
call into the fb notifier. Or attempt too, since that would
deadlock.
So looks like leftover hacks from when this was originally introduced
in
commit 6011bdeaa6089d49c02de69f05980da7bad314ab
Author: Guennadi Liakhovetski
Date: Wed Jul 21 10:13:21 2010 +
fbdev: sh-mobile: HDMI support for SH-Mobile SoCs
So let's just remove it.
Signed-off-by: Daniel Vetter
Reviewed-by: Geert Uytterhoeven
Tested-by: Geert Uytterhoeven
Cc: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Markus Elfring
Cc: Geert Uytterhoeven
Cc: Wolfram Sang
---
drivers/video/fbdev/sh_mobile_lcdcfb.c | 38 --
1 file changed, 38 deletions(-)
diff --git a/drivers/video/fbdev/sh_mobile_lcdcfb.c
b/drivers/video/fbdev/sh_mobile_lcdcfb.c
index c5924f5e98c6..0d7a044852d7 100644
--- a/drivers/video/fbdev/sh_mobile_lcdcfb.c
+++ b/drivers/video/fbdev/sh_mobile_lcdcfb.c
@@ -213,7 +213,6 @@ struct sh_mobile_lcdc_priv {
struct sh_mobile_lcdc_chan ch[2];
struct sh_mobile_lcdc_overlay overlays[4];
- struct notifier_block notifier;
int started;
int forced_fourcc; /* 2 channel LCDC must share fourcc setting */
};
@@ -2258,37 +2257,6 @@ static const struct dev_pm_ops sh_mobile_lcdc_dev_pm_ops
= {
* Framebuffer notifier
*/
-/* locking: called with info->lock held */
-static int sh_mobile_lcdc_notify(struct notifier_block *nb,
-unsigned long action, void *data)
-{
- struct fb_event *event = data;
- struct fb_info *info = event->info;
- struct sh_mobile_lcdc_chan *ch = info->par;
-
- if (&ch->lcdc->notifier != nb)
- return NOTIFY_DONE;
-
- dev_dbg(info->dev, "%s(): action = %lu, data = %p\n",
- __func__, action, event->data);
-
- switch(action) {
- case FB_EVENT_SUSPEND:
- sh_mobile_lcdc_display_off(ch);
- sh_mobile_lcdc_stop(ch->lcdc);
- break;
- case FB_EVENT_RESUME:
- mutex_lock(&ch->open_lock);
- sh_mobile_fb_reconfig(info);
- mutex_unlock(&ch->open_lock);
-
- sh_mobile_lcdc_display_on(ch);
- sh_mobile_lcdc_start(ch->lcdc);
- }
-
- return NOTIFY_OK;
-}
-
/*
-
* Probe/remove and driver init/exit
*/
@@ -2316,8 +2284,6 @@ static int sh_mobile_lcdc_remove(struct platform_device
*pdev)
struct sh_mobile_lcdc_priv *priv = platform_get_drvdata(pdev);
unsigned int i;
- fb_unregister_client(&priv->notifier);
-
for (i = 0; i < ARRAY_SIZE(priv->overlays); i++)
sh_mobile_lcdc_overlay_fb_unregister(&priv->overlays[i]);
for (i = 0; i < ARRAY_SIZE(priv->ch); i++)
@@ -2707,10 +2673,6 @@ static int sh_mobile_lcdc_probe(struct platform_device
*pdev)
goto err1;
}
- /* Failure ignored */
- priv->notifier.notifier_call = sh_mobile_lcdc_notify;
- fb_register_client(&priv->notifier);
-
return 0;
err1:
sh_mobile_lcdc_remove(pdev);
--
2.20.1
[PATCH 18/33] fbdev: make unregister/unlink functions not fail
Except for driver bugs (which we'll catch with a WARN_ON) this is only
to report failures of the new driver taking over the console. There's
nothing the outgoing driver can do about that, and no one ever
bothered to actually look at these return values. So remove them all.
v2: fixup unregister_framebuffer in savagefb, fbtft, ivtvfb, and neofb
drivers, reported by kbuild.
Signed-off-by: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
Cc: "Michał Mirosław"
Cc: Peter Rosin
Cc: Hans de Goede
Cc: Mikulas Patocka
Cc: linux-fb...@vger.kernel.org
---
drivers/media/pci/ivtv/ivtvfb.c | 6 +-
drivers/staging/fbtft/fbtft-core.c | 4 +-
drivers/video/fbdev/core/fbmem.c | 73 ++--
drivers/video/fbdev/neofb.c | 9 +--
drivers/video/fbdev/savage/savagefb_driver.c | 9 +--
include/linux/fb.h | 4 +-
6 files changed, 31 insertions(+), 74 deletions(-)
diff --git a/drivers/media/pci/ivtv/ivtvfb.c b/drivers/media/pci/ivtv/ivtvfb.c
index cfd21040d0e3..6435c72ff58e 100644
--- a/drivers/media/pci/ivtv/ivtvfb.c
+++ b/drivers/media/pci/ivtv/ivtvfb.c
@@ -1258,11 +1258,7 @@ static int ivtvfb_callback_cleanup(struct device *dev,
void *p)
struct osd_info *oi = itv->osd_info;
if (itv->v4l2_cap & V4L2_CAP_VIDEO_OUTPUT) {
- if (unregister_framebuffer(&itv->osd_info->ivtvfb_info)) {
- IVTVFB_WARN("Framebuffer %d is in use, cannot unload\n",
- itv->instance);
- return 0;
- }
+ unregister_framebuffer(&itv->osd_info->ivtvfb_info);
IVTVFB_INFO("Unregister framebuffer %d\n", itv->instance);
itv->ivtvfb_restore = NULL;
ivtvfb_blank(FB_BLANK_VSYNC_SUSPEND, &oi->ivtvfb_info);
diff --git a/drivers/staging/fbtft/fbtft-core.c
b/drivers/staging/fbtft/fbtft-core.c
index 9b07badf4c6c..7cbc1bdd2d8a 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -891,7 +891,9 @@ int fbtft_unregister_framebuffer(struct fb_info *fb_info)
if (par->fbtftops.unregister_backlight)
par->fbtftops.unregister_backlight(par);
fbtft_sysfs_exit(par);
- return unregister_framebuffer(fb_info);
+ unregister_framebuffer(fb_info);
+
+ return 0;
}
EXPORT_SYMBOL(fbtft_unregister_framebuffer);
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index f3fc2e5b193c..f3bcad30d3ba 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1590,13 +1590,13 @@ static bool fb_do_apertures_overlap(struct
apertures_struct *gena,
return false;
}
-static int do_unregister_framebuffer(struct fb_info *fb_info);
+static void do_unregister_framebuffer(struct fb_info *fb_info);
#define VGA_FB_PHYS 0xA
-static int do_remove_conflicting_framebuffers(struct apertures_struct *a,
- const char *name, bool primary)
+static void do_remove_conflicting_framebuffers(struct apertures_struct *a,
+ const char *name, bool primary)
{
- int i, ret;
+ int i;
/* check all firmware fbs and kick off if the base addr overlaps */
for_each_registered_fb(i) {
@@ -1612,13 +1612,9 @@ static int do_remove_conflicting_framebuffers(struct
apertures_struct *a,
printk(KERN_INFO "fb%d: switching to %s from %s\n",
i, name, registered_fb[i]->fix.id);
- ret = do_unregister_framebuffer(registered_fb[i]);
- if (ret)
- return ret;
+ do_unregister_framebuffer(registered_fb[i]);
}
}
-
- return 0;
}
static bool lockless_register_fb;
@@ -1634,11 +1630,9 @@ static int do_register_framebuffer(struct fb_info
*fb_info)
if (fb_check_foreignness(fb_info))
return -ENOSYS;
- ret = do_remove_conflicting_framebuffers(fb_info->apertures,
-fb_info->fix.id,
-fb_is_primary_device(fb_info));
- if (ret)
- return ret;
+ do_remove_conflicting_framebuffers(fb_info->apertures,
+ fb_info->fix.id,
+ fb_is_primary_device(fb_info));
if (num_registered_fb == FB_MAX)
return -ENXIO;
@@ -1714,32 +1708,25 @@ static int do_register_framebuffer(struct fb_info
*fb_info)
return ret;
}
-static int unbind_console(struct fb_info *fb_info)
+static void unbind_console(struct fb_info *fb_info)
{
int i = fb_info->node;
- if (i < 0 || i >= FB_MAX || registered_fb[i] != fb_info)
- return -EINVAL;
+ if
[PATCH 19/33] fbdev: unify unlink_framebuffer paths
For some reasons the pm_vt_switch_unregister call was missing from the
direct unregister_framebuffer path. Fix this.
v2: fbinfo->dev is used to decided whether unlink_framebuffer has been
called already. I botched that in v1. Make this all clearer by
inlining __unlink_framebuffer.
v3: Fix typoe in subject (Maarten).
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
Cc: "Michał Mirosław"
Cc: Peter Rosin
Cc: Hans de Goede
Cc: Mikulas Patocka
---
drivers/video/fbdev/core/fbmem.c | 47 ++--
1 file changed, 20 insertions(+), 27 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index f3bcad30d3ba..bee45e9405b8 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1722,15 +1722,30 @@ static void unbind_console(struct fb_info *fb_info)
console_unlock();
}
-static void __unlink_framebuffer(struct fb_info *fb_info);
-
-static void do_unregister_framebuffer(struct fb_info *fb_info)
+void unlink_framebuffer(struct fb_info *fb_info)
{
- unbind_console(fb_info);
+ int i;
+
+ i = fb_info->node;
+ if (WARN_ON(i < 0 || i >= FB_MAX || registered_fb[i] != fb_info))
+ return;
+
+ if (!fb_info->dev)
+ return;
+
+ device_destroy(fb_class, MKDEV(FB_MAJOR, i));
pm_vt_switch_unregister(fb_info->dev);
- __unlink_framebuffer(fb_info);
+ unbind_console(fb_info);
+
+ fb_info->dev = NULL;
+}
+EXPORT_SYMBOL(unlink_framebuffer);
+
+static void do_unregister_framebuffer(struct fb_info *fb_info)
+{
+ unlink_framebuffer(fb_info);
if (fb_info->pixmap.addr &&
(fb_info->pixmap.flags & FB_PIXMAP_DEFAULT))
kfree(fb_info->pixmap.addr);
@@ -1753,28 +1768,6 @@ static void do_unregister_framebuffer(struct fb_info
*fb_info)
put_fb_info(fb_info);
}
-static void __unlink_framebuffer(struct fb_info *fb_info)
-{
- int i;
-
- i = fb_info->node;
- if (WARN_ON(i < 0 || i >= FB_MAX || registered_fb[i] != fb_info))
- return;
-
- if (fb_info->dev) {
- device_destroy(fb_class, MKDEV(FB_MAJOR, i));
- fb_info->dev = NULL;
- }
-}
-
-void unlink_framebuffer(struct fb_info *fb_info)
-{
- __unlink_framebuffer(fb_info);
-
- unbind_console(fb_info);
-}
-EXPORT_SYMBOL(unlink_framebuffer);
-
/**
* remove_conflicting_framebuffers - remove firmware-configured framebuffers
* @a: memory range, users of which are to be removed
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 28/33] fbcon: replace FB_EVENT_MODE_CHANGE/_ALL with direct calls
Create a new wrapper function for this, feels like there's some
refactoring room here between the two modes.
v2: backlight notifier is also interested in the mode change event,
it calls lcd->set_mode, of which there are 3 implementations. Thanks
to Maarten for spotting this. So we keep that. We can ditch the differentiation
between mode change and all mode changes (because backlight notifier
doesn't care), and we can drop the FBINFO_MISC_USEREVENT stuff too,
because that's just to prevent recursion between fbmem.c and fbcon.c.
While at it flatten the control flow a bit.
v3: Need to add a static inline to the dummy function.
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
Cc: Hans de Goede
Cc: Yisheng Xie
Cc: "Michał Mirosław"
Cc: Peter Rosin
Cc: Mikulas Patocka
Cc: linux-fb...@vger.kernel.org
---
drivers/video/backlight/lcd.c | 1 -
drivers/video/fbdev/core/fbcon.c | 15 +--
drivers/video/fbdev/core/fbmem.c | 21 ++---
drivers/video/fbdev/sh_mobile_lcdcfb.c | 11 +--
include/linux/fb.h | 2 --
include/linux/fbcon.h | 2 ++
6 files changed, 22 insertions(+), 30 deletions(-)
diff --git a/drivers/video/backlight/lcd.c b/drivers/video/backlight/lcd.c
index 4b40c6a4d441..a758039475d0 100644
--- a/drivers/video/backlight/lcd.c
+++ b/drivers/video/backlight/lcd.c
@@ -33,7 +33,6 @@ static int fb_notifier_callback(struct notifier_block *self,
switch (event) {
case FB_EVENT_BLANK:
case FB_EVENT_MODE_CHANGE:
- case FB_EVENT_MODE_CHANGE_ALL:
case FB_EARLY_EVENT_BLANK:
case FB_R_EARLY_EVENT_BLANK:
break;
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 8a67505167ae..a07c261da53a 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -3009,6 +3009,15 @@ static void fbcon_set_all_vcs(struct fb_info *info)
fbcon_modechanged(info);
}
+
+void fbcon_update_vcs(struct fb_info *info, bool all)
+{
+ if (all)
+ fbcon_set_all_vcs(info);
+ else
+ fbcon_modechanged(info);
+}
+
int fbcon_mode_deleted(struct fb_info *info,
struct fb_videomode *mode)
{
@@ -3318,12 +3327,6 @@ static int fbcon_event_notify(struct notifier_block
*self,
int idx, ret = 0;
switch(action) {
- case FB_EVENT_MODE_CHANGE:
- fbcon_modechanged(info);
- break;
- case FB_EVENT_MODE_CHANGE_ALL:
- fbcon_set_all_vcs(info);
- break;
case FB_EVENT_SET_CONSOLE_MAP:
/* called with console lock held */
con2fb = event->data;
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 96805fe85332..dd1a708df1a7 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -957,6 +957,7 @@ fb_set_var(struct fb_info *info, struct fb_var_screeninfo
*var)
u32 activate;
struct fb_var_screeninfo old_var;
struct fb_videomode mode;
+ struct fb_event event;
if (var->activate & FB_ACTIVATE_INV_MODE) {
struct fb_videomode mode1, mode2;
@@ -1039,19 +1040,17 @@ fb_set_var(struct fb_info *info, struct
fb_var_screeninfo *var)
!list_empty(&info->modelist))
ret = fb_add_videomode(&mode, &info->modelist);
- if (!ret && (flags & FBINFO_MISC_USEREVENT)) {
- struct fb_event event;
- int evnt = (activate & FB_ACTIVATE_ALL) ?
- FB_EVENT_MODE_CHANGE_ALL :
- FB_EVENT_MODE_CHANGE;
+ if (ret)
+ return ret;
- info->flags &= ~FBINFO_MISC_USEREVENT;
- event.info = info;
- event.data = &mode;
- fb_notifier_call_chain(evnt, &event);
- }
+ event.info = info;
+ event.data = &mode;
+ fb_notifier_call_chain(FB_EVENT_MODE_CHANGE, &event);
- return ret;
+ if (flags & FBINFO_MISC_USEREVENT)
+ fbcon_update_vcs(info, activate & FB_ACTIVATE_ALL);
+
+ return 0;
}
EXPORT_SYMBOL(fb_set_var);
diff --git a/drivers/video/fbdev/sh_mobile_lcdcfb.c
b/drivers/video/fbdev/sh_mobile_lcdcfb.c
index 0d7a044852d7..bb1a610d0363 100644
--- a/drivers/video/fbdev/sh_mobile_lcdcfb.c
+++ b/drivers/video/fbdev/sh_mobile_lcdcfb.c
@@ -1776,8 +1776,6 @@ static void sh_mobile_fb_reconfig(struct fb_info *info)
struct sh_mobile_lcdc_chan *ch = info->par;
struct fb_var_screeninfo var;
struct fb_videomode mode;
- struct fb_event event;
- int evnt = FB_EVENT_MODE_CHANGE_ALL;
if (ch->use_count > 1 || (ch->use_count == 1 && !info->fbcon_par))
/* More framebuffer users are active */
@@ -
[PATCH 22/33] fbcon: Call fbcon_mode_deleted/new_modelist directly
I'm not entirely clear on what new_modelist actually does, it seems
exclusively for a sysfs interface. Which in the end does amount to a
normal fb_set_par to check the mode, but then takes a different path
in both fbmem.c and fbcon.c.
I have no idea why these 2 paths are different, but then I also don't
really want to find out. So just do the simple conversion to a direct
function call.
v2: static inline for the dummy versions, I forgot.
Signed-off-by: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
Cc: Hans de Goede
Cc: Mikulas Patocka
Cc: Sergey Senozhatsky
Cc: Kees Cook
Cc: Peter Rosin
Cc: Yisheng Xie
Cc: "Michał Mirosław"
Cc: linux-fb...@vger.kernel.org
---
drivers/video/fbdev/core/fbcon.c | 14 +++---
drivers/video/fbdev/core/fbmem.c | 22 +++---
include/linux/fb.h | 5 -
include/linux/fbcon.h| 6 ++
4 files changed, 16 insertions(+), 31 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 24ea6e4fbee0..35ecd25b385c 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -3019,8 +3019,8 @@ static void fbcon_set_all_vcs(struct fb_info *info)
fbcon_modechanged(info);
}
-static int fbcon_mode_deleted(struct fb_info *info,
- struct fb_videomode *mode)
+int fbcon_mode_deleted(struct fb_info *info,
+ struct fb_videomode *mode)
{
struct fb_info *fb_info;
struct fbcon_display *p;
@@ -3262,7 +3262,7 @@ static void fbcon_fb_blanked(struct fb_info *info, int
blank)
ops->blank_state = blank;
}
-static void fbcon_new_modelist(struct fb_info *info)
+void fbcon_new_modelist(struct fb_info *info)
{
int i;
struct vc_data *vc;
@@ -3324,7 +3324,6 @@ static int fbcon_event_notify(struct notifier_block *self,
{
struct fb_event *event = data;
struct fb_info *info = event->info;
- struct fb_videomode *mode;
struct fb_con2fbmap *con2fb;
struct fb_blit_caps *caps;
int idx, ret = 0;
@@ -3336,10 +3335,6 @@ static int fbcon_event_notify(struct notifier_block
*self,
case FB_EVENT_MODE_CHANGE_ALL:
fbcon_set_all_vcs(info);
break;
- case FB_EVENT_MODE_DELETE:
- mode = event->data;
- ret = fbcon_mode_deleted(info, mode);
- break;
case FB_EVENT_SET_CONSOLE_MAP:
/* called with console lock held */
con2fb = event->data;
@@ -3353,9 +3348,6 @@ static int fbcon_event_notify(struct notifier_block *self,
case FB_EVENT_BLANK:
fbcon_fb_blanked(info, *(int *)event->data);
break;
- case FB_EVENT_NEW_MODELIST:
- fbcon_new_modelist(info);
- break;
case FB_EVENT_GET_REQ:
caps = event->data;
fbcon_get_requirement(info, caps);
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 73269dedcd45..cbdd141e7695 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -966,16 +966,11 @@ fb_set_var(struct fb_info *info, struct fb_var_screeninfo
*var)
/* make sure we don't delete the videomode of current var */
ret = fb_mode_is_equal(&mode1, &mode2);
- if (!ret) {
- struct fb_event event;
-
- event.info = info;
- event.data = &mode1;
- ret = fb_notifier_call_chain(FB_EVENT_MODE_DELETE, &event);
- }
+ if (!ret)
+ fbcon_mode_deleted(info, &mode1);
if (!ret)
- fb_delete_videomode(&mode1, &info->modelist);
+ fb_delete_videomode(&mode1, &info->modelist);
ret = (ret) ? -EINVAL : 0;
@@ -1992,7 +1987,6 @@ subsys_initcall(fbmem_init);
int fb_new_modelist(struct fb_info *info)
{
- struct fb_event event;
struct fb_var_screeninfo var = info->var;
struct list_head *pos, *n;
struct fb_modelist *modelist;
@@ -2012,14 +2006,12 @@ int fb_new_modelist(struct fb_info *info)
}
}
- err = 1;
+ if (list_empty(&info->modelist))
+ return 1;
- if (!list_empty(&info->modelist)) {
- event.info = info;
- err = fb_notifier_call_chain(FB_EVENT_NEW_MODELIST, &event);
- }
+ fbcon_new_modelist(info);
- return err;
+ return 0;
}
MODULE_LICENSE("GPL");
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 794b386415b7..7a788ed8c7b5 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -126,8 +126,6 @@ struct fb_cursor_user {
/* The resolution of the passed in fb_info about to change */
#define FB_EVENT_MODE_CHANGE 0x01
-/* An entry from the m
[PATCH 27/33] fb: Flatten control flow in fb_set_var
Instead of wiring almost everything down to the very last line using
goto soup (but not consistently, where would the fun be otherwise)
drop out early when checks fail. This allows us to flatten the huge
indent levels to just 1.
Aside: If a driver doesn't set ->fb_check_var, then FB_ACTIVATE_NOW
does nothing. This bug exists ever since this code was extracted as a
common helper in 2002, hence I decided against fixing it. Everyone
just better have a fb_check_var to make sure things work correctly.
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: "Michał Mirosław"
Cc: Peter Rosin
Cc: Hans de Goede
Cc: Mikulas Patocka
---
drivers/video/fbdev/core/fbmem.c | 126 +++
1 file changed, 63 insertions(+), 63 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 25ae466ba593..96805fe85332 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -954,6 +954,9 @@ fb_set_var(struct fb_info *info, struct fb_var_screeninfo
*var)
{
int flags = info->flags;
int ret = 0;
+ u32 activate;
+ struct fb_var_screeninfo old_var;
+ struct fb_videomode mode;
if (var->activate & FB_ACTIVATE_INV_MODE) {
struct fb_videomode mode1, mode2;
@@ -970,87 +973,84 @@ fb_set_var(struct fb_info *info, struct fb_var_screeninfo
*var)
fb_delete_videomode(&mode1, &info->modelist);
- ret = (ret) ? -EINVAL : 0;
- goto done;
+ return ret ? -EINVAL : 0;
}
- if ((var->activate & FB_ACTIVATE_FORCE) ||
- memcmp(&info->var, var, sizeof(struct fb_var_screeninfo))) {
- u32 activate = var->activate;
+ if (!(var->activate & FB_ACTIVATE_FORCE) &&
+ !memcmp(&info->var, var, sizeof(struct fb_var_screeninfo)))
+ return 0;
- /* When using FOURCC mode, make sure the red, green, blue and
-* transp fields are set to 0.
-*/
- if ((info->fix.capabilities & FB_CAP_FOURCC) &&
- var->grayscale > 1) {
- if (var->red.offset || var->green.offset||
- var->blue.offset|| var->transp.offset ||
- var->red.length || var->green.length||
- var->blue.length|| var->transp.length ||
- var->red.msb_right || var->green.msb_right ||
- var->blue.msb_right || var->transp.msb_right)
- return -EINVAL;
- }
+ activate = var->activate;
- if (!info->fbops->fb_check_var) {
- *var = info->var;
- goto done;
- }
+ /* When using FOURCC mode, make sure the red, green, blue and
+* transp fields are set to 0.
+*/
+ if ((info->fix.capabilities & FB_CAP_FOURCC) &&
+ var->grayscale > 1) {
+ if (var->red.offset || var->green.offset||
+ var->blue.offset|| var->transp.offset ||
+ var->red.length || var->green.length||
+ var->blue.length|| var->transp.length ||
+ var->red.msb_right || var->green.msb_right ||
+ var->blue.msb_right || var->transp.msb_right)
+ return -EINVAL;
+ }
- ret = info->fbops->fb_check_var(var, info);
+ if (!info->fbops->fb_check_var) {
+ *var = info->var;
+ return 0;
+ }
- if (ret)
- goto done;
+ ret = info->fbops->fb_check_var(var, info);
- if ((var->activate & FB_ACTIVATE_MASK) == FB_ACTIVATE_NOW) {
- struct fb_var_screeninfo old_var;
- struct fb_videomode mode;
+ if (ret)
+ return ret;
- if (info->fbops->fb_get_caps) {
- ret = fb_check_caps(info, var, activate);
+ if ((var->activate & FB_ACTIVATE_MASK) != FB_ACTIVATE_NOW)
+ return 0;
- if (ret)
- goto done;
- }
+ if (info->fbops->fb_get_caps) {
+ ret = fb_check_caps(info, var, activate);
- old_var = info->var;
- info->var = *var;
+ if (ret)
+ return ret;
+ }
- if (info->fbops->fb_set_par) {
- ret = info->fbops->fb_set_par(info);
+ old_var = info->var;
+ info->var = *var;
- if (ret) {
- info->var = old_var;
-
[PULL] drm-misc-next, v2!
drm-misc-next-2019-05-24: drm-misc-next for v5.3, try #2: Cross-subsystem Changes: - Fix device tree bindings in drm-misc-next after a botched merge. Core Changes: - Docbook fix for drm_hdmi_infoframe_set_hdr_metadata. Driver Changes: - mediatek: Fix compiler warning after merging the HDR series. - vc4: Rework binner bo handling. drm-misc-next-2019-05-23: drm-misc-next for v5.3: UAPI Changes: - Add HDR source metadata property. - Make drm.h compile on GNU/kFreeBSD by including stdint.h - Clarify how the userspace reviewer has to review new kernel UAPI. - Clarify that for using new UAPI, merging to drm-next or drm-misc-next should be enough. Cross-subsystem Changes: - video/hdmi: Add unpack function for DRM infoframes. - Device tree bindings: * Updating a property for Mali Midgard GPUs * Updating a property for STM32 DSI panel * Adding support for FriendlyELEC HD702E 800x1280 panel * Adding support for Evervision VGG804821 800x480 5.0" WVGA TFT panel * Adding support for the EDT ET035012DM6 3.5" 320x240 QVGA 24-bit RGB TFT. * Adding support for Three Five displays TFC S9700RTWV43TR-01B 800x480 panel with resistive touch found on TI's AM335X-EVM. * Adding support for EDT ETM0430G0DH6 480x272 panel. - Add OSD101T2587-53TS driver with DT bindings. - Add Samsung S6E63M0 panel driver with DT bindings. - Add VXT VL050-8048NT-C01 800x480 panel with DT bindings. - Dma-buf: - Make mmap callback actually optional. - Documentation updates. - Fix debugfs refcount inbalance. - Remove unused sync_dump function. Core Changes: - Add support for HDR infoframes and related EDID parsing. - Remove prime sg_table caching, now done inside dma-buf. - Add shiny new drm_gem_vram helpers for simple VRAM drivers; with some fixes to the new API on top. - Small fix to job cleanup without timeout handler. - Documentation fixes to drm_fourcc. - Replace lookups of drm_format with struct drm_format_info; remove functions that become obsolete by this conversion. - Remove double include in bridge/panel.c and some drivers. - Remove drmP.h include from drm/edid and drm/dp. - Fix null pointer deref in drm_fb_helper_hotplug_event(). - Remove most members from drm_fb_helper_crtc, only mode_set is kept. - Remove race of fb helpers with userspace; only restore mode when userspace is not master. - Move legacy setup from drm_file.c to drm_legacy_misc.c - Rework scheduler job destruction. - drm/bus was removed, remove from TODO. - Add __drm_atomic_helper_crtc_reset() to subclass crtc_state, and convert some drivers to use it (conversion is not complete yet). - Bump vblank timeout wait to 100 ms for atomic. Driver Changes: - sun4i: Use DRM_GEM_CMA_VMAP_DRIVER_OPS instead of definining manually. - v3d: Small cleanups, adding support for compute shaders, reservation/synchronization fixes and job management refactoring, fixes MMU and debugfs. - lima: Fix null pointer in irq handler on startup, set default timeout for scheduled jobs. - stm/ltdc: Assorted fixes and adding FB modifier support. - amdgpu: Avoid hw reset if guilty job was already signaled. - virtio: Add seqno to fences, add trace events, use correct flags for fence allocation. - Convert AST, bochs, mgag200, vboxvideo, hisilicon to the new drm_gem_vram API. - sun6i_mipi_dsi: Support DSI GENERIC_SHORT_WRITE_2 transfers. - bochs: Small fix to use PTR_RET_OR_ZERO and driver unload. - gma500: header fixes - cirrus: Remove unused files. The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9: Linux 5.2-rc1 (2019-05-19 15:47:09 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2019-05-24 for you to fetch changes up to 909fa3321d348ef69366aad9e84e1dd9ee0bd060: dt-bindings: fix up for vendor prefixes file conversion (2019-05-24 09:13:52 +0200) Andreas Pretzsch (1): drm/panel: simple: Add support for EDT ET035012DM6 Andrew F. Davis (3): dma-buf: Remove leftover [un]map_atomic comments dma-buf: Update [un]map documentation to match the other functions dma-buf: Make mmap callback actually optional Andrey Grodzovsky (3): drm/sched: Keep s_fence->parent pointer drm/scheduler: Add flag to hint the release of guilty job. drm/amdgpu: Avoid HW reset if guilty job already signaled. Chia-I Wu (4): drm/virtio: set seqno for dma-fence drm/virtio: trace drm_fence_emit drm/virtio: add trace events for commands drm/virtio: allocate fences with GFP_KERNEL Chris Wilson (1): dma-buf: Remove unused sync_dump() Christian König (4): drm/scheduler: rework job destruction MAINTAINERS: drop Jerry as TTM maintainer dma-buf: start caching of sg_table objects v2 drm: remove prime sg_table caching Clément Péron (2): drm: panfrost: add optional bus_clock dt-bindings: gpu: mali-midgard: Add H6 m
[PATCH 14/33] staging/olpc: lock_fb_info can't fail
Simply because olpc never unregisters the damn thing. It also
registers the framebuffer directly by poking around in fbdev
core internals, so it's all around rather broken.
Signed-off-by: Daniel Vetter
Cc: Jens Frederich
Cc: Daniel Drake
Cc: Jon Nettleton
---
drivers/staging/olpc_dcon/olpc_dcon.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/staging/olpc_dcon/olpc_dcon.c
b/drivers/staging/olpc_dcon/olpc_dcon.c
index 6b714f740ac3..a254238be181 100644
--- a/drivers/staging/olpc_dcon/olpc_dcon.c
+++ b/drivers/staging/olpc_dcon/olpc_dcon.c
@@ -250,11 +250,7 @@ static bool dcon_blank_fb(struct dcon_priv *dcon, bool
blank)
int err;
console_lock();
- if (!lock_fb_info(dcon->fbinfo)) {
- console_unlock();
- dev_err(&dcon->client->dev, "unable to lock framebuffer\n");
- return false;
- }
+ lock_fb_info(dcon->fbinfo);
dcon->ignore_fb_events = true;
err = fb_blank(dcon->fbinfo,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 24/33] Revert "backlight/fbcon: Add FB_EVENT_CONBLANK"
This reverts commit 994efacdf9a087b52f71e620b58dfa526b0cf928.
The justification is that if hw blanking fails (i.e. fbops->fb_blank)
fails, then we still want to shut down the backlight. Which is exactly
_not_ what fb_blank() does and so rather inconsistent if we end up
with different behaviour between fbcon and direct fbdev usage. Given
that the entire notifier maze is getting in the way anyway I figured
it's simplest to revert this not well justified commit.
v2: Add static inline to the dummy version.
Cc: Richard Purdie
Signed-off-by: Daniel Vetter
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
Cc: Hans de Goede
Cc: Yisheng Xie
Cc: linux-fb...@vger.kernel.org
---
drivers/video/backlight/backlight.c | 2 +-
drivers/video/fbdev/core/fbcon.c| 14 +-
drivers/video/fbdev/core/fbmem.c| 1 +
include/linux/fb.h | 4 +---
include/linux/fbcon.h | 2 ++
5 files changed, 6 insertions(+), 17 deletions(-)
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index deb824bef6e2..c55590ec0057 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -46,7 +46,7 @@ static int fb_notifier_callback(struct notifier_block *self,
int fb_blank = 0;
/* If we aren't interested in this event, skip it immediately ... */
- if (event != FB_EVENT_BLANK && event != FB_EVENT_CONBLANK)
+ if (event != FB_EVENT_BLANK)
return 0;
bd = container_of(self, struct backlight_device, fb_notif);
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 259cdd118475..d9f545f1a81b 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2350,8 +2350,6 @@ static int fbcon_switch(struct vc_data *vc)
static void fbcon_generic_blank(struct vc_data *vc, struct fb_info *info,
int blank)
{
- struct fb_event event;
-
if (blank) {
unsigned short charmask = vc->vc_hi_font_mask ?
0x1ff : 0xff;
@@ -2362,13 +2360,6 @@ static void fbcon_generic_blank(struct vc_data *vc,
struct fb_info *info,
fbcon_clear(vc, 0, 0, vc->vc_rows, vc->vc_cols);
vc->vc_video_erase_char = oldc;
}
-
-
- lock_fb_info(info);
- event.info = info;
- event.data = ␣
- fb_notifier_call_chain(FB_EVENT_CONBLANK, &event);
- unlock_fb_info(info);
}
static int fbcon_blank(struct vc_data *vc, int blank, int mode_switch)
@@ -3240,7 +3231,7 @@ int fbcon_fb_registered(struct fb_info *info)
return ret;
}
-static void fbcon_fb_blanked(struct fb_info *info, int blank)
+void fbcon_fb_blanked(struct fb_info *info, int blank)
{
struct fbcon_ops *ops = info->fbcon_par;
struct vc_data *vc;
@@ -3344,9 +3335,6 @@ static int fbcon_event_notify(struct notifier_block *self,
con2fb = event->data;
con2fb->framebuffer = con2fb_map[con2fb->console - 1];
break;
- case FB_EVENT_BLANK:
- fbcon_fb_blanked(info, *(int *)event->data);
- break;
case FB_EVENT_REMAP_ALL_CONSOLE:
idx = info->node;
fbcon_remap_all(idx);
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index ddc0c16b8bbf..9366fbe99a58 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1068,6 +1068,7 @@ fb_blank(struct fb_info *info, int blank)
event.data = ␣
early_ret = fb_notifier_call_chain(FB_EARLY_EVENT_BLANK, &event);
+ fbcon_fb_blanked(info, blank);
if (info->fbops->fb_blank)
ret = info->fbops->fb_blank(blank, info);
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 0d86aa31bf8d..1e66fac3124f 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -137,12 +137,10 @@ struct fb_cursor_user {
#define FB_EVENT_GET_CONSOLE_MAP0x07
/* CONSOLE-SPECIFIC: set console to framebuffer mapping */
#define FB_EVENT_SET_CONSOLE_MAP0x08
-/* A hardware display blank change occurred */
+/* A display blank is requested */
#define FB_EVENT_BLANK 0x09
/* Private modelist is to be replaced */
#define FB_EVENT_MODE_CHANGE_ALL 0x0B
-/* A software display blank change occurred */
-#define FB_EVENT_CONBLANK 0x0C
/* CONSOLE-SPECIFIC: remap all consoles to new fb - for vga_switcheroo */
#define FB_EVENT_REMAP_ALL_CONSOLE 0x0F
/* A hardware display blank early change occurred */
diff --git a/include/linux/fbcon.h b/include/linux/fbcon.h
index 305e4f2eddac..d67d7ec51ef9 100644
--- a/include/linux/fbcon.h
+++ b/include/linux/fbcon.h
@@ -14,6 +14,7 @@ int fbcon_mode_deleted(struct fb_info *info,
void fbcon_new_modelist(struct fb_info *info);
void f
[PATCH 31/33] fbcon: Document what I learned about fbcon locking
It's not pretty.
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Hans de Goede
Cc: Yisheng Xie
---
drivers/video/fbdev/core/fbcon.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 6a4bbb8407c0..8444d5151c2d 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -88,6 +88,25 @@
# define DPRINTK(fmt, args...)
#endif
+/*
+ * FIXME: Locking
+ *
+ * - fbcon state itself is protected by the console_lock, and the code does a
+ * pretty good job at making sure that lock is held everywhere it's needed.
+ *
+ * - access to the registered_fb array is entirely unprotected. This should use
+ * proper object lifetime handling, i.e. get/put_fb_info. This also means
+ * switching from indices to proper pointers for fb_info everywhere.
+ *
+ * - fbcon doesn't bother with fb_lock/unlock at all. This is buggy, since it
+ * means concurrent access to the same fbdev from both fbcon and userspace
+ * will blow up. To fix this all fbcon calls from fbmem.c need to be moved
out
+ * of fb_lock/unlock protected sections, since otherwise we'll recurse and
+ * deadlock eventually. Aside: Due to these deadlock issues the fbdev code in
+ * fbmem.c cannot use locking asserts, and there's lots of callers which get
+ * the rules wrong, e.g. fbsysfs.c entirely missed fb_lock/unlock calls too.
+ */
+
enum {
FBCON_LOGO_CANSHOW = -1, /* the logo can be shown */
FBCON_LOGO_DRAW = -2, /* draw the logo to a console */
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 17/33] fbcon: call fbcon_fb_bind directly
Also remove the error return value. That's all errors for either
driver bugs (trying to unbind something that isn't bound), or errors
of the new driver that will take over.
There's nothing the outgoing driver can do about this anyway, so
switch over to void.
Signed-off-by: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
Cc: Hans de Goede
Cc: Sergey Senozhatsky
Cc: Peter Rosin
Cc: Kees Cook
Cc: Konstantin Khorenko
Cc: Yisheng Xie
Cc: "Michał Mirosław"
Cc: Mikulas Patocka
Cc: Thomas Zimmermann
Cc: linux-fb...@vger.kernel.org
---
drivers/video/fbdev/core/fbcon.c | 24 +++-
drivers/video/fbdev/core/fbmem.c | 7 ++-
include/linux/fb.h | 2 --
include/linux/fbcon.h| 2 ++
4 files changed, 11 insertions(+), 24 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index c3353db35adc..f114b4c88796 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -3046,7 +3046,7 @@ static int fbcon_mode_deleted(struct fb_info *info,
}
#ifdef CONFIG_VT_HW_CONSOLE_BINDING
-static int fbcon_unbind(void)
+static void fbcon_unbind(void)
{
int ret;
@@ -3055,25 +3055,21 @@ static int fbcon_unbind(void)
if (!ret)
fbcon_has_console_bind = 0;
-
- return ret;
}
#else
-static inline int fbcon_unbind(void)
-{
- return -EINVAL;
-}
+static inline void fbcon_unbind(void) {}
#endif /* CONFIG_VT_HW_CONSOLE_BINDING */
/* called with console_lock held */
-static int fbcon_fb_unbind(int idx)
+void fbcon_fb_unbind(struct fb_info *info)
{
int i, new_idx = -1, ret = 0;
+ int idx = info->node;
WARN_CONSOLE_UNLOCKED();
if (!fbcon_has_console_bind)
- return 0;
+ return;
for (i = first_fb_vc; i <= last_fb_vc; i++) {
if (con2fb_map[i] != idx &&
@@ -3106,15 +3102,13 @@ static int fbcon_fb_unbind(int idx)
idx, 0);
if (ret) {
con2fb_map[i] = idx;
- return ret;
+ return;
}
}
}
}
- ret = fbcon_unbind();
+ fbcon_unbind();
}
-
- return ret;
}
/* called with console_lock held */
@@ -3352,10 +3346,6 @@ static int fbcon_event_notify(struct notifier_block
*self,
mode = event->data;
ret = fbcon_mode_deleted(info, mode);
break;
- case FB_EVENT_FB_UNBIND:
- idx = info->node;
- ret = fbcon_fb_unbind(idx);
- break;
case FB_EVENT_SET_CONSOLE_MAP:
/* called with console lock held */
con2fb = event->data;
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index d73762324ca2..f3fc2e5b193c 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1716,8 +1716,6 @@ static int do_register_framebuffer(struct fb_info
*fb_info)
static int unbind_console(struct fb_info *fb_info)
{
- struct fb_event event;
- int ret;
int i = fb_info->node;
if (i < 0 || i >= FB_MAX || registered_fb[i] != fb_info)
@@ -1725,12 +1723,11 @@ static int unbind_console(struct fb_info *fb_info)
console_lock();
lock_fb_info(fb_info);
- event.info = fb_info;
- ret = fb_notifier_call_chain(FB_EVENT_FB_UNBIND, &event);
+ fbcon_fb_unbind(fb_info);
unlock_fb_info(fb_info);
console_unlock();
- return ret;
+ return 0;
}
static int __unlink_framebuffer(struct fb_info *fb_info);
diff --git a/include/linux/fb.h b/include/linux/fb.h
index aa8f18163151..b6ce041d9e13 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -158,8 +158,6 @@ struct fb_cursor_user {
#define FB_EVENT_CONBLANK 0x0C
/* Get drawing requirements*/
#define FB_EVENT_GET_REQ0x0D
-/* Unbind from the console if possible */
-#define FB_EVENT_FB_UNBIND 0x0E
/* CONSOLE-SPECIFIC: remap all consoles to new fb - for vga_switcheroo */
#define FB_EVENT_REMAP_ALL_CONSOLE 0x0F
/* A hardware display blank early change occurred */
diff --git a/include/linux/fbcon.h b/include/linux/fbcon.h
index 94a71e9e1257..38d44fdb6d14 100644
--- a/include/linux/fbcon.h
+++ b/include/linux/fbcon.h
@@ -6,11 +6,13 @@ void __init fb_console_init(void);
void __exit fb_console_exit(void);
int fbcon_fb_registered(struct fb_info *info);
void fbcon_fb_unregistered(struct fb_info *info);
+void fbcon_fb_unbind(struct fb_info *info);
#else
static inline void fb_console_init(void) {}
static inline void fb_
[PATCH 23/33] fbdev: Call fbcon_get_requirement directly
Pretty simple case really.
v2: Forgot to remove a break;
v3: Add static inline to the dummy versions.
Signed-off-by: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
Cc: Hans de Goede
Cc: "Steven Rostedt (VMware)"
Cc: Prarit Bhargava
Cc: Kees Cook
Cc: Yisheng Xie
Cc: "Michał Mirosław"
Cc: Peter Rosin
Cc: Mikulas Patocka
Cc: linux-fb...@vger.kernel.org
---
drivers/video/fbdev/core/fbcon.c | 9 ++---
drivers/video/fbdev/core/fbmem.c | 5 +
include/linux/fb.h | 2 --
include/linux/fbcon.h| 4
4 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 35ecd25b385c..259cdd118475 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -3283,8 +3283,8 @@ void fbcon_new_modelist(struct fb_info *info)
}
}
-static void fbcon_get_requirement(struct fb_info *info,
- struct fb_blit_caps *caps)
+void fbcon_get_requirement(struct fb_info *info,
+ struct fb_blit_caps *caps)
{
struct vc_data *vc;
struct fbcon_display *p;
@@ -3325,7 +3325,6 @@ static int fbcon_event_notify(struct notifier_block *self,
struct fb_event *event = data;
struct fb_info *info = event->info;
struct fb_con2fbmap *con2fb;
- struct fb_blit_caps *caps;
int idx, ret = 0;
switch(action) {
@@ -3348,10 +3347,6 @@ static int fbcon_event_notify(struct notifier_block
*self,
case FB_EVENT_BLANK:
fbcon_fb_blanked(info, *(int *)event->data);
break;
- case FB_EVENT_GET_REQ:
- caps = event->data;
- fbcon_get_requirement(info, caps);
- break;
case FB_EVENT_REMAP_ALL_CONSOLE:
idx = info->node;
fbcon_remap_all(idx);
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index cbdd141e7695..ddc0c16b8bbf 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -932,16 +932,13 @@ EXPORT_SYMBOL(fb_pan_display);
static int fb_check_caps(struct fb_info *info, struct fb_var_screeninfo *var,
u32 activate)
{
- struct fb_event event;
struct fb_blit_caps caps, fbcaps;
int err = 0;
memset(&caps, 0, sizeof(caps));
memset(&fbcaps, 0, sizeof(fbcaps));
caps.flags = (activate & FB_ACTIVATE_ALL) ? 1 : 0;
- event.info = info;
- event.data = ∩︀
- fb_notifier_call_chain(FB_EVENT_GET_REQ, &event);
+ fbcon_get_requirement(info, &caps);
info->fbops->fb_get_caps(info, &fbcaps, var);
if (((fbcaps.x ^ caps.x) & caps.x) ||
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 7a788ed8c7b5..0d86aa31bf8d 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -143,8 +143,6 @@ struct fb_cursor_user {
#define FB_EVENT_MODE_CHANGE_ALL 0x0B
/* A software display blank change occurred */
#define FB_EVENT_CONBLANK 0x0C
-/* Get drawing requirements*/
-#define FB_EVENT_GET_REQ0x0D
/* CONSOLE-SPECIFIC: remap all consoles to new fb - for vga_switcheroo */
#define FB_EVENT_REMAP_ALL_CONSOLE 0x0F
/* A hardware display blank early change occurred */
diff --git a/include/linux/fbcon.h b/include/linux/fbcon.h
index c139834342f5..305e4f2eddac 100644
--- a/include/linux/fbcon.h
+++ b/include/linux/fbcon.h
@@ -12,6 +12,8 @@ void fbcon_resumed(struct fb_info *info);
int fbcon_mode_deleted(struct fb_info *info,
struct fb_videomode *mode);
void fbcon_new_modelist(struct fb_info *info);
+void fbcon_get_requirement(struct fb_info *info,
+ struct fb_blit_caps *caps);
#else
static inline void fb_console_init(void) {}
static inline void fb_console_exit(void) {}
@@ -23,6 +25,8 @@ static inline void fbcon_resumed(struct fb_info *info) {}
static inline int fbcon_mode_deleted(struct fb_info *info,
struct fb_videomode *mode) { return 0; }
static inline void fbcon_new_modelist(struct fb_info *info) {}
+static inline void fbcon_get_requirement(struct fb_info *info,
+struct fb_blit_caps *caps) {}
#endif
#endif /* _LINUX_FBCON_H */
--
2.20.1
[PATCH 25/33] fbmem: pull fbcon_fb_blanked out of fb_blank
There's a callchain of:
fbcon_fb_blaned -> do_(un)blank_screen -> consw->con_blank
-> fbcon_blank -> fb_blank
Things don't go horribly wrong because the BKL console_lock safes the
day, but that's about it. And the seeming recursion is broken in 2
ways:
- Starting from the fbdev ioctl we set FBINFO_MISC_USEREVENT, which
tells the fbcon_blank code to not call fb_blank. This was required
to not deadlock when recursing on the fb_notifier_chain mutex.
- Starting from the con_blank hook we're getting saved by the
console_blanked checks in do_blank/unblank_screen. Or at least
that's my theory.
Anyway, recursion isn't awesome, so let's stop it. Breaking the
recursion avoids the need to be in the FBINFO_MISC_USEREVENT critical
section, so lets move it out of that too.
The astute reader will notice that fb_blank seems to require
lock_fb_info(), which the fbcon code seems to ignore. I have no idea
how to fix that problem, so let's keep ignoring it.
v2: I forgot the sysfs blanking code.
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: "Michał Mirosław"
Cc: Peter Rosin
Cc: Hans de Goede
Cc: Mikulas Patocka
Cc: Rob Clark
---
drivers/video/fbdev/core/fbmem.c | 4 +++-
drivers/video/fbdev/core/fbsysfs.c | 8 ++--
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 9366fbe99a58..d6713dce9e31 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1068,7 +1068,6 @@ fb_blank(struct fb_info *info, int blank)
event.data = ␣
early_ret = fb_notifier_call_chain(FB_EARLY_EVENT_BLANK, &event);
- fbcon_fb_blanked(info, blank);
if (info->fbops->fb_blank)
ret = info->fbops->fb_blank(blank, info);
@@ -1198,6 +1197,9 @@ static long do_fb_ioctl(struct fb_info *info, unsigned
int cmd,
info->flags |= FBINFO_MISC_USEREVENT;
ret = fb_blank(info, arg);
info->flags &= ~FBINFO_MISC_USEREVENT;
+
+ /* might again call into fb_blank */
+ fbcon_fb_blanked(info, arg);
unlock_fb_info(info);
console_unlock();
break;
diff --git a/drivers/video/fbdev/core/fbsysfs.c
b/drivers/video/fbdev/core/fbsysfs.c
index 5f329278e55f..252d4f52d2a5 100644
--- a/drivers/video/fbdev/core/fbsysfs.c
+++ b/drivers/video/fbdev/core/fbsysfs.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
@@ -305,12 +306,15 @@ static ssize_t store_blank(struct device *device,
{
struct fb_info *fb_info = dev_get_drvdata(device);
char *last = NULL;
- int err;
+ int err, arg;
+ arg = simple_strtoul(buf, &last, 0);
console_lock();
fb_info->flags |= FBINFO_MISC_USEREVENT;
- err = fb_blank(fb_info, simple_strtoul(buf, &last, 0));
+ err = fb_blank(fb_info, arg);
fb_info->flags &= ~FBINFO_MISC_USEREVENT;
+ /* might again call into fb_blank */
+ fbcon_fb_blanked(fb_info, arg);
console_unlock();
if (err < 0)
return err;
--
2.20.1
[PATCH 26/33] fbdev: remove FBINFO_MISC_USEREVENT around fb_blank
With the recursion broken in the previous patch we can drop the FBINFO_MISC_USEREVENT flag around calls to fb_blank - recursion prevention was it's only job. Signed-off-by: Daniel Vetter Cc: Daniel Vetter Cc: Bartlomiej Zolnierkiewicz Cc: Hans de Goede Cc: Yisheng Xie Cc: "Michał Mirosław" Cc: Peter Rosin Cc: Mikulas Patocka Cc: Rob Clark --- drivers/video/fbdev/core/fbcon.c | 5 ++--- drivers/video/fbdev/core/fbmem.c | 3 --- drivers/video/fbdev/core/fbsysfs.c | 2 -- 3 files changed, 2 insertions(+), 8 deletions(-) diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c index d9f545f1a81b..8a67505167ae 100644 --- a/drivers/video/fbdev/core/fbcon.c +++ b/drivers/video/fbdev/core/fbcon.c @@ -2386,9 +2386,8 @@ static int fbcon_blank(struct vc_data *vc, int blank, int mode_switch) fbcon_cursor(vc, blank ? CM_ERASE : CM_DRAW); ops->cursor_flash = (!blank); - if (!(info->flags & FBINFO_MISC_USEREVENT)) - if (fb_blank(info, blank)) - fbcon_generic_blank(vc, info, blank); + if (fb_blank(info, blank)) + fbcon_generic_blank(vc, info, blank); } if (!blank) diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c index d6713dce9e31..25ae466ba593 100644 --- a/drivers/video/fbdev/core/fbmem.c +++ b/drivers/video/fbdev/core/fbmem.c @@ -1194,10 +1194,7 @@ static long do_fb_ioctl(struct fb_info *info, unsigned int cmd, case FBIOBLANK: console_lock(); lock_fb_info(info); - info->flags |= FBINFO_MISC_USEREVENT; ret = fb_blank(info, arg); - info->flags &= ~FBINFO_MISC_USEREVENT; - /* might again call into fb_blank */ fbcon_fb_blanked(info, arg); unlock_fb_info(info); diff --git a/drivers/video/fbdev/core/fbsysfs.c b/drivers/video/fbdev/core/fbsysfs.c index 252d4f52d2a5..882b471d619e 100644 --- a/drivers/video/fbdev/core/fbsysfs.c +++ b/drivers/video/fbdev/core/fbsysfs.c @@ -310,9 +310,7 @@ static ssize_t store_blank(struct device *device, arg = simple_strtoul(buf, &last, 0); console_lock(); - fb_info->flags |= FBINFO_MISC_USEREVENT; err = fb_blank(fb_info, arg); - fb_info->flags &= ~FBINFO_MISC_USEREVENT; /* might again call into fb_blank */ fbcon_fb_blanked(fb_info, arg); console_unlock(); -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/ttm, drm/vmwgfx: Have TTM support AMD SEV encryption
Hi, Christian,
On 5/24/19 10:37 AM, Koenig, Christian wrote:
Am 24.05.19 um 10:11 schrieb Thomas Hellström (VMware):
[CAUTION: External Email]
From: Thomas Hellstrom
With SEV encryption, all DMA memory must be marked decrypted
(AKA "shared") for devices to be able to read it. In the future we might
want to be able to switch normal (encrypted) memory to decrypted in exactly
the same way as we handle caching states, and that would require additional
memory pools. But for now, rely on memory allocated with
dma_alloc_coherent() which is already decrypted with SEV enabled. Set up
the page protection accordingly. Drivers must detect SEV enabled and switch
to the dma page pool.
This patch has not yet been tested. As a follow-up, we might want to
cache decrypted pages in the dma page pool regardless of their caching
state.
This patch is unnecessary, SEV support already works fine with at least
amdgpu and I would expect that it also works with other drivers as well.
Also see this patch:
commit 64e1f830ea5b3516a4256ed1c504a265d7f2a65c
Author: Christian König
Date: Wed Mar 13 10:11:19 2019 +0100
drm: fallback to dma_alloc_coherent when memory encryption is active
We can't just map any randome page we get when memory encryption is
active.
Signed-off-by: Christian König
Acked-by: Alex Deucher
Link: https://patchwork.kernel.org/patch/10850833/
Regards,
Christian.
Yes, I noticed that. Although I fail to see where we automagically clear
the PTE encrypted bit when mapping coherent memory? For the linear
kernel map, that's done within dma_alloc_coherent() but for kernel vmaps
and and user-space maps? Is that done automatically by the x86 platform
layer?
/Thomas
Cc: Christian König
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo_util.c| 17 +
drivers/gpu/drm/ttm/ttm_bo_vm.c | 6 --
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 3 +++
drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 6 --
include/drm/ttm/ttm_bo_driver.h | 8 +---
include/drm/ttm/ttm_tt.h | 1 +
6 files changed, 30 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 895d77d799e4..1d6643bd0b01 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -419,11 +419,13 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
page = i * dir + add;
if (old_iomap == NULL) {
pgprot_t prot = ttm_io_prot(old_mem->placement,
+ ttm->page_flags,
PAGE_KERNEL);
ret = ttm_copy_ttm_io_page(ttm, new_iomap, page,
prot);
} else if (new_iomap == NULL) {
pgprot_t prot = ttm_io_prot(new_mem->placement,
+ ttm->page_flags,
PAGE_KERNEL);
ret = ttm_copy_io_ttm_page(ttm, old_iomap, page,
prot);
@@ -526,11 +528,11 @@ static int ttm_buffer_object_transfer(struct
ttm_buffer_object *bo,
return 0;
}
-pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t tmp)
+pgprot_t ttm_io_prot(u32 caching_flags, u32 tt_page_flags, pgprot_t tmp)
{
/* Cached mappings need no adjustment */
if (caching_flags & TTM_PL_FLAG_CACHED)
- return tmp;
+ goto check_encryption;
#if defined(__i386__) || defined(__x86_64__)
if (caching_flags & TTM_PL_FLAG_WC)
@@ -548,6 +550,11 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t tmp)
#if defined(__sparc__) || defined(__mips__)
tmp = pgprot_noncached(tmp);
#endif
+
+check_encryption:
+ if (tt_page_flags & TTM_PAGE_FLAG_DECRYPTED)
+ tmp = pgprot_decrypted(tmp);
+
return tmp;
}
EXPORT_SYMBOL(ttm_io_prot);
@@ -594,7 +601,8 @@ static int ttm_bo_kmap_ttm(struct ttm_buffer_object *bo,
if (ret)
return ret;
- if (num_pages == 1 && (mem->placement & TTM_PL_FLAG_CACHED)) {
+ if (num_pages == 1 && (mem->placement & TTM_PL_FLAG_CACHED) &&
+ !(ttm->page_flags & TTM_PAGE_FLAG_DECRYPTED)) {
/*
* We're mapping a single page, and the desired
* page protection is consistent with the bo.
@@ -608,7 +616,8 @@ static int ttm_bo_kmap_ttm(struct ttm_buffer_object *bo,
* We need to use vmap to get the desired page protection
* or to make the buffer object look contiguous.
*/
- prot = ttm_io_prot(mem->placement, PAGE_KERNEL);
+ prot = ttm_io_prot(mem-
[PATCH] drm/komeda: Creates plane alpha and blend mode properties
From: "Lowry Li (Arm Technology China)" Creates plane alpha and blend mode properties attached to plane. This patch depends on: - https://patchwork.freedesktop.org/series/59915/ - https://patchwork.freedesktop.org/series/58665/ - https://patchwork.freedesktop.org/series/59000/ - https://patchwork.freedesktop.org/series/59002/ - https://patchwork.freedesktop.org/series/59471/ Changes since v1: - Adds patch denpendency in the comment Changes since v2: - Remove [RFC] from the subject Changes since v3: - Rebase the code Signed-off-by: Lowry Li (Arm Technology China) --- drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c index e7cd690..9b87c25 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c @@ -303,6 +303,17 @@ static int komeda_plane_add(struct komeda_kms_dev *kms, drm_plane_helper_add(plane, &komeda_plane_helper_funcs); + err = drm_plane_create_alpha_property(plane); + if (err) + goto cleanup; + + err = drm_plane_create_blend_mode_property(plane, + BIT(DRM_MODE_BLEND_PIXEL_NONE) | + BIT(DRM_MODE_BLEND_PREMULTI) | + BIT(DRM_MODE_BLEND_COVERAGE)); + if (err) + goto cleanup; + err = komeda_plane_create_layer_properties(kplane, layer); if (err) goto cleanup; -- 1.9.1
Re: [RFC PATCH] drm/ttm, drm/vmwgfx: Have TTM support AMD SEV encryption
On 5/24/19 11:11 AM, Thomas Hellstrom wrote: Hi, Christian, On 5/24/19 10:37 AM, Koenig, Christian wrote: Am 24.05.19 um 10:11 schrieb Thomas Hellström (VMware): [CAUTION: External Email] From: Thomas Hellstrom With SEV encryption, all DMA memory must be marked decrypted (AKA "shared") for devices to be able to read it. In the future we might want to be able to switch normal (encrypted) memory to decrypted in exactly the same way as we handle caching states, and that would require additional memory pools. But for now, rely on memory allocated with dma_alloc_coherent() which is already decrypted with SEV enabled. Set up the page protection accordingly. Drivers must detect SEV enabled and switch to the dma page pool. This patch has not yet been tested. As a follow-up, we might want to cache decrypted pages in the dma page pool regardless of their caching state. This patch is unnecessary, SEV support already works fine with at least amdgpu and I would expect that it also works with other drivers as well. Also see this patch: commit 64e1f830ea5b3516a4256ed1c504a265d7f2a65c Author: Christian König Date: Wed Mar 13 10:11:19 2019 +0100 drm: fallback to dma_alloc_coherent when memory encryption is active We can't just map any randome page we get when memory encryption is active. Signed-off-by: Christian König Acked-by: Alex Deucher Link: https://patchwork.kernel.org/patch/10850833/ Regards, Christian. Yes, I noticed that. Although I fail to see where we automagically clear the PTE encrypted bit when mapping coherent memory? For the linear kernel map, that's done within dma_alloc_coherent() but for kernel vmaps and and user-space maps? Is that done automatically by the x86 platform layer? /Thomas And, as a follow up question, why do we need dma_alloc_coherent() when using SME? I thought the hardware performs the decryption when DMA-ing to / from an encrypted page with SME, but not with SEV? Thanks, Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes for 5.2-rc2
On Fri, 24 May 2019 at 18:11, Daniel Vetter wrote:
>
> fyi sfr reported that 55143dc23ca4 ("drm/amd/display: Don't load DMCU
> for Raven 1") breaks the build on x86-64. But I can't repro and didn't
> immediately see what Kconfig it would need to trigger this, so no
> idea. So just heads up in case this is real and there's some odd
> config that hits a bug here ...
> -Daniel
Okay I've dropped a revert onto fixes, new PR coming up for Linus.
Dave.
>
>
> On Fri, May 24, 2019 at 6:28 AM Dave Airlie wrote:
> >
> > Hey Linus,
> >
> > Nothing too unusual here for rc2.
> >
> > i915:
> > - boosting fix
> > - bump ready task fixes
> > - GVT - reset fix, error return, TRTT handling fix
> >
> > amdgpu:
> > - DMCU firmware loading fix
> > - Polaris 10 pci id for kfd
> > - picasso screen corruption fix
> > - SR-IOV fixes
> > - vega driver reload fixes
> > - SMU locking fix
> > - compute profile fix for kfd
> >
> > vmwgfx:
> > - integer overflow fixes
> > - dma sg fix
> >
> > sun4i:
> > - HDMI phy fixes
> >
> > gma500:
> > - LVDS detection fix
> >
> > panfrost:
> > - devfreq selection fix
> >
> > drm-fixes-2019-05-24:
> > drm i915, amdgpu, vmwgfx, sun4i, panfrost, gma500 fixes.
> > The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9:
> >
> > Linux 5.2-rc1 (2019-05-19 15:47:09 -0700)
> >
> > are available in the Git repository at:
> >
> > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-05-24
> >
> > for you to fetch changes up to e1e52981f292b4e321781794eaf6e8a087f4f300:
> >
> > Merge tag 'drm-intel-fixes-2019-05-23' of
> > git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2019-05-24
> > 14:01:00 +1000)
> >
> >
> > drm i915, amdgpu, vmwgfx, sun4i, panfrost, gma500 fixes.
> >
> >
> > Alex Deucher (2):
> > drm/amdgpu/soc15: skip reset on init
> > drm/amdgpu/gmc9: set vram_width properly for SR-IOV
> >
> > Chris Wilson (5):
> > drm/i915: Rearrange i915_scheduler.c
> > drm/i915: Pass i915_sched_node around internally
> > drm/i915: Bump signaler priority on adding a waiter
> > drm/i915: Downgrade NEWCLIENT to non-preemptive
> > drm/i915: Truly bump ready tasks ahead of busywaits
> >
> > Dan Carpenter (2):
> > drm/amd/powerplay: fix locking in smu_feature_set_supported()
> > drm/i915/gvt: Fix an error code in ppgtt_populate_spt_by_guest_entry()
> >
> > Dave Airlie (4):
> > Merge branch 'vmwgfx-fixes-5.2' of
> > git://people.freedesktop.org/~thomash/linux into drm-fixes
> > Merge tag 'drm-misc-fixes-2019-05-22' of
> > git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
> > Merge branch 'drm-fixes-5.2' of
> > git://people.freedesktop.org/~agd5f/linux into drm-fixes
> > Merge tag 'drm-intel-fixes-2019-05-23' of
> > git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
> >
> > Ezequiel Garcia (1):
> > drm/panfrost: Select devfreq
> >
> > Flora Cui (1):
> > drm/amdgpu: keep stolen memory on picasso
> >
> > Harish Kasiviswanathan (1):
> > drm/amdkfd: Fix compute profile switching
> >
> > Harry Wentland (2):
> > drm/amd/display: Add ASICREV_IS_PICASSO
> > drm/amd/display: Don't load DMCU for Raven 1
> >
> > Jagan Teki (1):
> > drm/sun4i: sun6i_mipi_dsi: Fix hsync_porch overflow
> >
> > Jernej Skrabec (2):
> > drm/sun4i: Fix sun8i HDMI PHY clock initialization
> > drm/sun4i: Fix sun8i HDMI PHY configuration for > 148.5 MHz
> >
> > Joonas Lahtinen (1):
> > Merge tag 'gvt-fixes-2019-05-21' of
> > https://github.com/intel/gvt-linux into drm-intel-fixes
> >
> > Kent Russell (1):
> > drm/amdkfd: Add missing Polaris10 ID
> >
> > Murray McAllister (2):
> > drm/vmwgfx: NULL pointer dereference from vmw_cmd_dx_view_define()
> > drm/vmwgfx: integer underflow in vmw_cmd_dx_set_shader() leading
> > to an invalid read
> >
> > Patrik Jakobsson (1):
> > drm/gma500/cdv: Check vbt config bits when detecting lvds panels
> >
> > Sean Paul (1):
> > Merge drm-misc-next-fixes-2019-05-20 into drm-misc-fixes
> >
> > Thomas Hellstrom (4):
> > drm/vmwgfx: Don't send drm sysfs hotplug events on initial master set
> > drm/vmwgfx: Fix user space handle equal to zero
> > drm/vmwgfx: Fix compat mode shader operation
> > drm/vmwgfx: Use the dma scatter-gather iterator to get dma addresses
> >
> > Weinan (1):
> > drm/i915/gvt: emit init breadcrumb for gvt request
> >
> > Yan Zhao (4):
> > drm/i915/gvt: use cmd to restore in-context mmios to hw for gen9
> > platform
> > drm/i915/gvt: Tiled Resources mmios are in-context mmios for gen9+
> > drm/i915/gvt: add 0x4dfc to gen9 save-restore list
> > drm/i915/gvt: do not let TRTTE and 0x4dfc write passthrough to
> > hardware
> >
> > Yintian Tao (1):
> > drm/amdgpu: skip fw pri bo alloc for SRIOV
> >
> > drivers/g
[git pull] drm fixes for 5.2-rc2 (try two)
Hey Linus, Nothing too unusual here for rc2. Except the amdgpu DMCU firmware loading fix caused build breakage with a different set of Kconfig options. I've just reverted it for now until the AMD folks can rewrite it to avoid that problem. i915: - boosting fix - bump ready task fixes - GVT - reset fix, error return, TRTT handling fix amdgpu: - DMCU firmware loading fix - Polaris 10 pci id for kfd - picasso screen corruption fix - SR-IOV fixes - vega driver reload fixes - SMU locking fix - compute profile fix for kfd vmwgfx: - integer overflow fixes - dma sg fix sun4i: - HDMI phy fixes gma500: - LVDS detection fix panfrost: - devfreq selection fix drm-fixes-2019-05-24-1: drm i915, amdgpu, vmwgfx, sun4i, panfrost, gma500 fixes. + revert build breakage The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9: Linux 5.2-rc1 (2019-05-19 15:47:09 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-05-24-1 for you to fetch changes up to c074989171801171af6c5f53dd16b27f36b31deb: Revert "drm/amd/display: Don't load DMCU for Raven 1" (2019-05-24 19:56:50 +1000) drm i915, amdgpu, vmwgfx, sun4i, panfrost, gma500 fixes. + revert build breakage Alex Deucher (2): drm/amdgpu/soc15: skip reset on init drm/amdgpu/gmc9: set vram_width properly for SR-IOV Chris Wilson (5): drm/i915: Rearrange i915_scheduler.c drm/i915: Pass i915_sched_node around internally drm/i915: Bump signaler priority on adding a waiter drm/i915: Downgrade NEWCLIENT to non-preemptive drm/i915: Truly bump ready tasks ahead of busywaits Dan Carpenter (2): drm/amd/powerplay: fix locking in smu_feature_set_supported() drm/i915/gvt: Fix an error code in ppgtt_populate_spt_by_guest_entry() Dave Airlie (5): Merge branch 'vmwgfx-fixes-5.2' of git://people.freedesktop.org/~thomash/linux into drm-fixes Merge tag 'drm-misc-fixes-2019-05-22' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Merge branch 'drm-fixes-5.2' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge tag 'drm-intel-fixes-2019-05-23' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Revert "drm/amd/display: Don't load DMCU for Raven 1" Ezequiel Garcia (1): drm/panfrost: Select devfreq Flora Cui (1): drm/amdgpu: keep stolen memory on picasso Harish Kasiviswanathan (1): drm/amdkfd: Fix compute profile switching Harry Wentland (2): drm/amd/display: Add ASICREV_IS_PICASSO drm/amd/display: Don't load DMCU for Raven 1 Jagan Teki (1): drm/sun4i: sun6i_mipi_dsi: Fix hsync_porch overflow Jernej Skrabec (2): drm/sun4i: Fix sun8i HDMI PHY clock initialization drm/sun4i: Fix sun8i HDMI PHY configuration for > 148.5 MHz Joonas Lahtinen (1): Merge tag 'gvt-fixes-2019-05-21' of https://github.com/intel/gvt-linux into drm-intel-fixes Kent Russell (1): drm/amdkfd: Add missing Polaris10 ID Murray McAllister (2): drm/vmwgfx: NULL pointer dereference from vmw_cmd_dx_view_define() drm/vmwgfx: integer underflow in vmw_cmd_dx_set_shader() leading to an invalid read Patrik Jakobsson (1): drm/gma500/cdv: Check vbt config bits when detecting lvds panels Sean Paul (1): Merge drm-misc-next-fixes-2019-05-20 into drm-misc-fixes Thomas Hellstrom (4): drm/vmwgfx: Don't send drm sysfs hotplug events on initial master set drm/vmwgfx: Fix user space handle equal to zero drm/vmwgfx: Fix compat mode shader operation drm/vmwgfx: Use the dma scatter-gather iterator to get dma addresses Weinan (1): drm/i915/gvt: emit init breadcrumb for gvt request Yan Zhao (4): drm/i915/gvt: use cmd to restore in-context mmios to hw for gen9 platform drm/i915/gvt: Tiled Resources mmios are in-context mmios for gen9+ drm/i915/gvt: add 0x4dfc to gen9 save-restore list drm/i915/gvt: do not let TRTTE and 0x4dfc write passthrough to hardware Yintian Tao (1): drm/amdgpu: skip fw pri bo alloc for SRIOV drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c| 17 +- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 11 +- drivers/gpu/drm/amd/amdgpu/soc15.c | 5 + drivers/gpu/drm/amd/amdkfd/kfd_device.c| 17 ++ .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 11 +- drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 7 + drivers/gpu/drm/amd/display/include/dal_asic_id.h | 7 +- drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 2 +- drivers/gpu/drm/gma500/cdv_intel_lvds.c| 3 + drivers/gpu/drm/gma500/intel_bios.c| 3 + drivers/gpu/drm/gma500/psb_drv.h | 1 + drivers/gpu/drm/i915/gvt/cmd_parser.c | 14 +- drivers/gpu/drm/i915/gvt/gtt.c
Re: [PATCH v10 04/11] drm/sun4i: tcon: Compute DCLK dividers based on format, lanes
On Fri, May 24, 2019 at 2:18 AM Maxime Ripard wrote: > > On Mon, May 20, 2019 at 02:33:11PM +0530, Jagan Teki wrote: > > pll-video => pll-mipi => tcon0 => tcon0-pixel-clock is the typical > > MIPI clock topology in Allwinner DSI controller. > > > > TCON dotclock driver is computing the desired DCLK divider based on > > panel pixel clock along with input DCLK min, max divider values from > > tcon driver and that would eventually set the pll-mipi clock rate. > > > > The current code is passing dsi min and max divider value as 4 via > > tcon driver which would ended-up triggering below vblank wait timed out > > warning on "bananapi,s070wv20-ct16" panel. > > > > WARNING: CPU: 0 PID: 31 at drivers/gpu/drm/drm_atomic_helper.c:1429 > > drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 > > [CRTC:46:crtc-0] vblank wait timed out > > Modules linked in: > > CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted > > 5.1.0-next-20190514-00025-g5186cdf10757-dirty #6 > > Hardware name: Allwinner sun8i Family > > Workqueue: events deferred_probe_work_func > > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > > [] (show_stack) from [] (dump_stack+0x84/0x98) > > [] (dump_stack) from [] (__warn+0xfc/0x114) > > [] (__warn) from [] (warn_slowpath_fmt+0x44/0x68) > > [] (warn_slowpath_fmt) from [] > > (drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) > > [] (drm_atomic_helper_wait_for_vblanks.part.1) from [] > > (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) > > [] (drm_atomic_helper_commit_tail_rpm) from [] > > (commit_tail+0x40/0x6c) > > [] (commit_tail) from [] > > (drm_atomic_helper_commit+0xbc/0x128) > > [] (drm_atomic_helper_commit) from [] > > (restore_fbdev_mode_atomic+0x1cc/0x1dc) > > [] (restore_fbdev_mode_atomic) from [] > > (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) > > [] (drm_fb_helper_restore_fbdev_mode_unlocked) from [] > > (drm_fb_helper_set_par+0x30/0x54) > > [] (drm_fb_helper_set_par) from [] > > (fbcon_init+0x560/0x5ac) > > [] (fbcon_init) from [] (visual_init+0xbc/0x104) > > [] (visual_init) from [] > > (do_bind_con_driver+0x1b0/0x390) > > [] (do_bind_con_driver) from [] > > (do_take_over_console+0x13c/0x1c4) > > [] (do_take_over_console) from [] > > (do_fbcon_takeover+0x74/0xcc) > > [] (do_fbcon_takeover) from [] > > (notifier_call_chain+0x44/0x84) > > [] (notifier_call_chain) from [] > > (__blocking_notifier_call_chain+0x48/0x60) > > [] (__blocking_notifier_call_chain) from [] > > (blocking_notifier_call_chain+0x18/0x20) > > [] (blocking_notifier_call_chain) from [] > > (register_framebuffer+0x1e0/0x2f8) > > [] (register_framebuffer) from [] > > (__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c) > > [] (__drm_fb_helper_initial_config_and_unlock) from [] > > (drm_fbdev_client_hotplug+0xe8/0x1b8) > > [] (drm_fbdev_client_hotplug) from [] > > (drm_fbdev_generic_setup+0x88/0x118) > > [] (drm_fbdev_generic_setup) from [] > > (sun4i_drv_bind+0x128/0x160) > > [] (sun4i_drv_bind) from [] > > (try_to_bring_up_master+0x164/0x1a0) > > [] (try_to_bring_up_master) from [] > > (__component_add+0x94/0x140) > > [] (__component_add) from [] > > (sun6i_dsi_probe+0x144/0x234) > > [] (sun6i_dsi_probe) from [] > > (platform_drv_probe+0x48/0x9c) > > [] (platform_drv_probe) from [] > > (really_probe+0x1dc/0x2c8) > > [] (really_probe) from [] > > (driver_probe_device+0x60/0x160) > > [] (driver_probe_device) from [] > > (bus_for_each_drv+0x74/0xb8) > > [] (bus_for_each_drv) from [] > > (__device_attach+0xd0/0x13c) > > [] (__device_attach) from [] > > (bus_probe_device+0x84/0x8c) > > [] (bus_probe_device) from [] > > (deferred_probe_work_func+0x64/0x90) > > [] (deferred_probe_work_func) from [] > > (process_one_work+0x204/0x420) > > [] (process_one_work) from [] > > (worker_thread+0x274/0x5a0) > > [] (worker_thread) from [] (kthread+0x11c/0x14c) > > [] (kthread) from [] (ret_from_fork+0x14/0x2c) > > Exception stack(0xde539fb0 to 0xde539ff8) > > 9fa0: > > > > 9fc0: > > > > 9fe0: 0013 > > ---[ end trace 4017fea4906ab391 ]--- > > > > But accordingly to Allwinner A33, A64 BSP codes [1] [2] this divider > > is clearly using 'format/lanes' for dsi divider value, dsi_clk.clk_div > > > > Which would compute the pll_freq and set a clock rate for it in > > [3] and [4] respectively. > > > > The same issue has reproduced in A33, A64 with 4-lane and 2-lane devices > > and got fixed with this computation logic 'format/lanes', so this patch > > using dclk min and max dividers as per BSP. > > > > [1] > > https://github.com/BPI-SINOVOIP/BPI-M2M-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp/de/disp_lcd.c#L1106 > > [2] > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/disp_al.
Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
On Fri, Feb 1, 2019 at 8:01 PM Maxime Ripard wrote: > > On Tue, Jan 29, 2019 at 11:01:31PM +0530, Jagan Teki wrote: > > On Tue, Jan 29, 2019 at 8:43 PM Maxime Ripard > > wrote: > > > > > > On Mon, Jan 28, 2019 at 03:06:10PM +0530, Jagan Teki wrote: > > > > On Sat, Jan 26, 2019 at 2:54 AM Maxime Ripard > > > > wrote: > > > > > > > > > > On Fri, Jan 25, 2019 at 01:28:49AM +0530, Jagan Teki wrote: > > > > > > Minimum PLL used for MIPI is 500MHz, as per manual, but > > > > > > lowering the min rate by 300MHz can result proper working > > > > > > nkms divider with the help of desired dclock rate from > > > > > > panel driver. > > > > > > > > > > > > Signed-off-by: Jagan Teki > > > > > > Acked-by: Stephen Boyd > > > > > > > > > > Going 200MHz below the minimum doesn't seem really reasonable. What > > > > > is the issue that you are trying to fix here? > > > > > > > > > > It looks like it's picking bad dividers, but if that's the case, this > > > > > isn't the proper fix. > > > > > > > > As I stated in earlier patches, the whole idea is pick the desired > > > > dclk divider based dclk rate. So the dotclock, sun4i_dclk_round_rate > > > > is unable to get the proper dclk divider at the end, so it eventually > > > > picking up wrong divider value and fired vblank timeout. > > > > > > > > So, we come-up with optimal and working min_rate 300MHz in pll-mipi to > > > > get the desired clock something like below. > > > > [2.415773] [drm] No driver support for vblank timestamp query. > > > > [2.424116] sun4i_dclk_round_rate: min_div = 4 max_div = 127, rate = > > > > 5500 > > > > [2.424172] ideal = 22000, rounded = 0 > > > > [2.424176] ideal = 27500, rounded = 0 > > > > [2.424194] ccu_nkm_round_rate: rate = 33000 > > > > [2.424197] ideal = 33000, rounded = 33000 > > > > [2.424201] sun4i_dclk_round_rate: div = 6 rate = 5500 > > > > [2.424205] sun4i_dclk_round_rate: min_div = 4 max_div = 127, rate = > > > > 5500 > > > > [2.424209] ideal = 22000, rounded = 0 > > > > [2.424213] ideal = 27500, rounded = 0 > > > > [2.424230] ccu_nkm_round_rate: rate = 33000 > > > > [2.424233] ideal = 33000, rounded = 33000 > > > > [2.424236] sun4i_dclk_round_rate: div = 6 rate = 5500 > > > > [2.424253] ccu_nkm_round_rate: rate = 33000 > > > > [2.424270] ccu_nkm_round_rate: rate = 33000 > > > > [2.424278] sun4i_dclk_recalc_rate: val = 1, rate = 33000 > > > > [2.424281] sun4i_dclk_recalc_rate: val = 1, rate = 33000 > > > > [2.424306] ccu_nkm_set_rate: rate = 33000, parent_rate = > > > > 29700 > > > > [2.424309] ccu_nkm_set_rate: _nkm.n = 5 > > > > [2.424311] ccu_nkm_set_rate: _nkm.k = 2 > > > > [2.424313] ccu_nkm_set_rate: _nkm.m = 9 > > > > [2.424661] sun4i_dclk_set_rate div 6 > > > > [2.424668] sun4i_dclk_recalc_rate: val = 6, rate = 5500 > > > > > > > > But look like this wouldn't valid for all other dclock rates, say BPI > > > > panel has 30MHz clock that would failed with this logic. > > > > > > > > On the other side Allwinner BSP calculating dclk divider based on the > > > > SoC's. for A33 [1] it is fixed dclk divider of 4 and for A64 is is > > > > calculated based on the bpp/lanes. > > > > > > It looks like the A64 has the same divider of 4: > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c#L12 > > > > > > I think you're confusing it with the ratio between the pixel clock and > > > the dotclock, called dsi_div: > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/disp_al.c#L198 > > > > Ahh.. I thought this initially but as far as DSI clock computation is > > concern, the L12 tcon_div is local variable which is used for edge0 > > computation in burst mode and not for the dsi clock computation. Since > > the BSP is unable to get the tcon_div during edge0 computation, they > > defined it locally I think. > > > > You can see the lcd_clk_config() code [2], where we can see DSI clock > > computation using dsi_div value. > > > > Here is dump after the in Line 792 which is after computation[3] > > [ 10.800737] lcd_clk_config: dsi_div = 6, tcon_div = 4, lcd_div = 1 > > [ 10.800743] lcd_clk_config: lcd_dclk_freq = 55, dclk_rate = 5500 > > [ 10.800749] lcd_clk_config: lcd_rate = 33000, pll_rate = 33000 > > > > The above dump the lcd_rate 330MHz is computed with panel clock, 55MHz > > into dsi_div 6. So this can be our actual divider values dclk_min_div, > > dclk_max_div in sun4i_dclk_round_rate (from > > drivers/gpu/drm/sun4i/sun4i_dotclock.c) > > I wish it was in your commit log in the first place, instead of having > to exchange multiple mails over this. > > However, I don't think that's quite true, and it might be a bug in > Allwinner's implementation (or rather something quite confusing). > >
Re: linux-next: build failure after merge of the drm-fixes tree
Hi Daniel,
On Fri, 24 May 2019 10:09:28 +0200 Daniel Vetter wrote:
>
> On Fri, May 24, 2019 at 12:29 AM Stephen Rothwell
> wrote:
> >
> > After merging the drm-fixes tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function
> > 'load_dmcu_fw':
> > drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:667:7: error:
> > implicit declaration of function 'ASICREV_IS_PICASSO'; did you mean
> > 'ASICREV_IS_VEGA12_P'? [-Werror=implicit-function-declaration]
> >if (ASICREV_IS_PICASSO(adev->external_rev_id))
> >^~
> >ASICREV_IS_VEGA12_P
> >
> > Caused by commit
> >
> > 55143dc23ca4 ("drm/amd/display: Don't load DMCU for Raven 1")
> >
> > I have reverted that commit for today.
>
> Seems to compile fine here, and Dave just sent out the pull so I guess
> works for him too. What's your .config?
See above "x86_64 allmodconfig"
Looking at it closely now, I can't see how that error comes about.
Ah, in the drm-fixes tree, the definition of is protected by
#if defined(CONFIG_DRM_AMD_DC_DCN1_01)
which gets removed in the amdgpu tree (merged later). So I can only
presume that CONFIG_DRM_AMD_DC_DCN1_01 was not set for the build I did.
config DRM_AMD_DC
bool "AMD DC - Enable new display engine"
default y
select DRM_AMD_DC_DCN1_0 if X86 && !(KCOV_INSTRUMENT_ALL && KCOV_ENABLE_
COMPARISONS)KCOV_INSTRUMENT_ALL && KCOV_ENABLE_COMPARISONS
select DRM_AMD_DC_DCN1_01 if X86 && !(KCOV_INSTRUMENT_ALL &&
KCOV_ENABLE_COMPARISONS)
So maybe KCOV_INSTRUMENT_ALL && KCOV_ENABLE_COMPARISONS are set for
allmodconfig. I no longer have the actual .config file any more, sorry.
--
Cheers,
Stephen Rothwell
pgp73a2Ujt9W_.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/ttm, drm/vmwgfx: Have TTM support AMD SEV encryption
Am 24.05.19 um 11:55 schrieb Thomas Hellstrom: > [CAUTION: External Email] > > On 5/24/19 11:11 AM, Thomas Hellstrom wrote: >> Hi, Christian, >> >> On 5/24/19 10:37 AM, Koenig, Christian wrote: >>> Am 24.05.19 um 10:11 schrieb Thomas Hellström (VMware): [CAUTION: External Email] From: Thomas Hellstrom With SEV encryption, all DMA memory must be marked decrypted (AKA "shared") for devices to be able to read it. In the future we might want to be able to switch normal (encrypted) memory to decrypted in exactly the same way as we handle caching states, and that would require additional memory pools. But for now, rely on memory allocated with dma_alloc_coherent() which is already decrypted with SEV enabled. Set up the page protection accordingly. Drivers must detect SEV enabled and switch to the dma page pool. This patch has not yet been tested. As a follow-up, we might want to cache decrypted pages in the dma page pool regardless of their caching state. >>> This patch is unnecessary, SEV support already works fine with at least >>> amdgpu and I would expect that it also works with other drivers as >>> well. >>> >>> Also see this patch: >>> >>> commit 64e1f830ea5b3516a4256ed1c504a265d7f2a65c >>> Author: Christian König >>> Date: Wed Mar 13 10:11:19 2019 +0100 >>> >>> drm: fallback to dma_alloc_coherent when memory encryption is >>> active >>> >>> We can't just map any randome page we get when memory >>> encryption is >>> active. >>> >>> Signed-off-by: Christian König >>> Acked-by: Alex Deucher >>> Link: https://patchwork.kernel.org/patch/10850833/ >>> >>> Regards, >>> Christian. >> >> Yes, I noticed that. Although I fail to see where we automagically >> clear the PTE encrypted bit when mapping coherent memory? For the >> linear kernel map, that's done within dma_alloc_coherent() but for >> kernel vmaps and and user-space maps? Is that done automatically by >> the x86 platform layer? Yes, I think so. Haven't looked to closely at this either. >> >> /Thomas >> > And, as a follow up question, why do we need dma_alloc_coherent() when > using SME? I thought the hardware performs the decryption when DMA-ing > to / from an encrypted page with SME, but not with SEV? I think the issue was that the DMA API would try to use a bounce buffer in this case. Christian. > > Thanks, Thomas > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 01/11] drm/sun4i: dsi: Fix TCON DRQ set bits
On Fri, May 24, 2019 at 2:04 AM Maxime Ripard wrote: > > On Mon, May 20, 2019 at 02:33:08PM +0530, Jagan Teki wrote: > > According to "DRM kernel-internal display mode structure" in > > include/drm/drm_modes.h the current driver is trying to include > > sync timings along with front porch value while checking and > > computing drq set bits in non-burst mode. > > > > mode->hsync_end - mode->hdisplay => horizontal front porch + sync > > > > With adding additional sync timings, the dsi controller leads to > > wrong drq set bits for "bananapi,s070wv20-ct16" panel which indeed > > trigger panel flip_done timed out as: > > > > WARNING: CPU: 0 PID: 31 at drivers/gpu/drm/drm_atomic_helper.c:1429 > > drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 > > [CRTC:46:crtc-0] vblank wait timed out > > Modules linked in: > > CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted > > 5.1.0-next-20190514-00026-g01f0c75b902d-dirty #13 > > Hardware name: Allwinner sun8i Family > > Workqueue: events deferred_probe_work_func > > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > > [] (show_stack) from [] (dump_stack+0x84/0x98) > > [] (dump_stack) from [] (__warn+0xfc/0x114) > > [] (__warn) from [] (warn_slowpath_fmt+0x44/0x68) > > [] (warn_slowpath_fmt) from [] > > (drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) > > [] (drm_atomic_helper_wait_for_vblanks.part.1) from [] > > (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) > > [] (drm_atomic_helper_commit_tail_rpm) from [] > > (commit_tail+0x40/0x6c) > > [] (commit_tail) from [] > > (drm_atomic_helper_commit+0xbc/0x128) > > [] (drm_atomic_helper_commit) from [] > > (restore_fbdev_mode_atomic+0x1cc/0x1dc) > > [] (restore_fbdev_mode_atomic) from [] > > (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) > > [] (drm_fb_helper_restore_fbdev_mode_unlocked) from [] > > (drm_fb_helper_set_par+0x30/0x54) > > [] (drm_fb_helper_set_par) from [] > > (fbcon_init+0x560/0x5ac) > > [] (fbcon_init) from [] (visual_init+0xbc/0x104) > > [] (visual_init) from [] > > (do_bind_con_driver+0x1b0/0x390) > > [] (do_bind_con_driver) from [] > > (do_take_over_console+0x13c/0x1c4) > > [] (do_take_over_console) from [] > > (do_fbcon_takeover+0x74/0xcc) > > [] (do_fbcon_takeover) from [] > > (notifier_call_chain+0x44/0x84) > > [] (notifier_call_chain) from [] > > (__blocking_notifier_call_chain+0x48/0x60) > > [] (__blocking_notifier_call_chain) from [] > > (blocking_notifier_call_chain+0x18/0x20) > > [] (blocking_notifier_call_chain) from [] > > (register_framebuffer+0x1e0/0x2f8) > > [] (register_framebuffer) from [] > > (__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c) > > [] (__drm_fb_helper_initial_config_and_unlock) from [] > > (drm_fbdev_client_hotplug+0xe8/0x1b8) > > [] (drm_fbdev_client_hotplug) from [] > > (drm_fbdev_generic_setup+0x88/0x118) > > [] (drm_fbdev_generic_setup) from [] > > (sun4i_drv_bind+0x128/0x160) > > [] (sun4i_drv_bind) from [] > > (try_to_bring_up_master+0x164/0x1a0) > > [] (try_to_bring_up_master) from [] > > (__component_add+0x94/0x140) > > [] (__component_add) from [] > > (sun6i_dsi_probe+0x144/0x234) > > [] (sun6i_dsi_probe) from [] > > (platform_drv_probe+0x48/0x9c) > > [] (platform_drv_probe) from [] > > (really_probe+0x1dc/0x2c8) > > [] (really_probe) from [] > > (driver_probe_device+0x60/0x160) > > [] (driver_probe_device) from [] > > (bus_for_each_drv+0x74/0xb8) > > [] (bus_for_each_drv) from [] > > (__device_attach+0xd0/0x13c) > > [] (__device_attach) from [] > > (bus_probe_device+0x84/0x8c) > > [] (bus_probe_device) from [] > > (deferred_probe_work_func+0x64/0x90) > > [] (deferred_probe_work_func) from [] > > (process_one_work+0x204/0x420) > > [] (process_one_work) from [] > > (worker_thread+0x274/0x5a0) > > [] (worker_thread) from [] (kthread+0x11c/0x14c) > > [] (kthread) from [] (ret_from_fork+0x14/0x2c) > > Exception stack(0xde539fb0 to 0xde539ff8) > > 9fa0: > > > > 9fc0: > > > > 9fe0: 0013 > > ---[ end trace b57eb1e5c64c6b8b ]--- > > random: fast init done > > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:46:crtc-0] > > flip_done timed out > > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:48:DSI-1] > > flip_done timed out > > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:30:plane-0] > > flip_done timed out > > > > But according to Allwinner A33, A64 BSP code [1] [3] the TCON DRQ for > > non-burst DSI mode can be computed based on "horizontal front porch" > > value only (no sync timings included). > > > > Detailed evidence for drq set bits based on A33 BSP [1] [2] > > > > => panel->lcd_ht - panel->lcd_x - panel->lcd_hbp - 20 > > => (tt->hor_front_porch + lcdp->panel_info.lcd_hbp + > > lcdp->panel_info.lcd_x) - panel->lcd_x - pane
Re: [PATCH v4] drm/komeda: Add writeback support
On Thu, May 23, 2019 at 10:36:38AM +0100, james qian wang (Arm Technology
China) wrote:
> Komeda driver uses a individual component to describe the HW's writeback
> caps, but drivers doesn't define a new structure and still uses the
> existing "struct komeda_layer" to describe this new component.
> The detailed changes as follow:
>
> 1. Initialize wb_layer according to HW and report it to CORE.
> 2. CORE exposes wb_layer as a resource to KMS by private_obj.
> 3. Report writeback supporting by add a wb_connector to KMS, and then
>wb_connector will take act as a component resources user,
>so the func komeda_wb_encoder_atomic_check claims komeda resources
>(scaler and wb_layer) accroding to its state configuration to the
>wb_connector. and the wb_state configuration will be validated on the
>specific component resources to see if the caps of component can
>meet the requirement of wb_connector. if not check failed.
> 4. Update irq_handler to notify the completion of writeback.
>
> NOTE:
> This change doesn't add scaling writeback support, that support will
> be added in the future after the scaler support.
>
> v2: Rebase
> v3: Rebase and constify the d71_wb_layer_funcs
> v4: Addressed Ayan's comments
>
> Depends on:
> - https://patchwork.freedesktop.org/series/59915/
>
> Signed-off-by: James Qian Wang (Arm Technology China)
>
> ---
> drivers/gpu/drm/arm/display/komeda/Makefile | 1 +
> .../arm/display/komeda/d71/d71_component.c| 90 -
> .../gpu/drm/arm/display/komeda/komeda_crtc.c | 15 ++
> .../arm/display/komeda/komeda_framebuffer.c | 19 ++
> .../gpu/drm/arm/display/komeda/komeda_kms.c | 4 +
> .../gpu/drm/arm/display/komeda/komeda_kms.h | 27 +++
> .../drm/arm/display/komeda/komeda_pipeline.h | 7 +
> .../display/komeda/komeda_pipeline_state.c| 51 -
> .../arm/display/komeda/komeda_private_obj.c | 6 +
> .../arm/display/komeda/komeda_wb_connector.c | 181 ++
> 10 files changed, 398 insertions(+), 3 deletions(-)
> create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/Makefile
> b/drivers/gpu/drm/arm/display/komeda/Makefile
> index 62bd1bff66a3..d7e29fc688c3 100644
> --- a/drivers/gpu/drm/arm/display/komeda/Makefile
> +++ b/drivers/gpu/drm/arm/display/komeda/Makefile
> @@ -14,6 +14,7 @@ komeda-y := \
> komeda_kms.o \
> komeda_crtc.o \
> komeda_plane.o \
> + komeda_wb_connector.o \
> komeda_private_obj.o
>
> komeda-y += \
> diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> index 6bab816ed8e7..323e5994a55c 100644
> --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> @@ -288,10 +288,98 @@ static int d71_layer_init(struct d71_dev *d71,
> return 0;
> }
>
> +static void d71_wb_layer_update(struct komeda_component *c,
> + struct komeda_component_state *state)
> +{
> + struct komeda_layer_state *st = to_layer_st(state);
> + struct drm_connector_state *conn_st = state->wb_conn->state;
> + struct drm_framebuffer *fb = conn_st->writeback_job->fb;
> + struct komeda_fb *kfb = to_kfb(fb);
> + u32 __iomem *reg = c->reg;
> + u32 ctrl = L_EN | LW_OFM, mask = L_EN | LW_OFM | LW_TBU_EN;
> + int i;
> +
> + for (i = 0; i < fb->format->num_planes; i++) {
> + malidp_write32(reg + i * LAYER_PER_PLANE_REGS, BLK_P0_PTR_LOW,
> +lower_32_bits(st->addr[i]));
> + malidp_write32(reg + i * LAYER_PER_PLANE_REGS, BLK_P0_PTR_HIGH,
> +upper_32_bits(st->addr[i]));
> +
> + malidp_write32(reg + i * LAYER_PER_PLANE_REGS, BLK_P0_STRIDE,
> +fb->pitches[i] & 0x);
> + }
> +
> + malidp_write32(reg, LAYER_FMT, kfb->format_caps->hw_id);
> + malidp_write32(reg, BLK_IN_SIZE, HV_SIZE(st->hsize, st->vsize));
> + malidp_write32(reg, BLK_INPUT_ID0, to_d71_input_id(&state->inputs[0]));
> + malidp_write32_mask(reg, BLK_CONTROL, mask, ctrl);
> +}
> +
> +static void d71_wb_layer_dump(struct komeda_component *c, struct seq_file
> *sf)
> +{
> + u32 v[12], i;
> +
> + dump_block_header(sf, c->reg);
> +
> + get_values_from_reg(c->reg, 0x80, 1, v);
> + seq_printf(sf, "LW_INPUT_ID0:\t\t0x%X\n", v[0]);
> +
> + get_values_from_reg(c->reg, 0xD0, 3, v);
> + seq_printf(sf, "LW_CONTROL:\t\t0x%X\n", v[0]);
> + seq_printf(sf, "LW_PROG_LINE:\t\t0x%X\n", v[1]);
> + seq_printf(sf, "LW_FORMAT:\t\t0x%X\n", v[2]);
> +
> + get_values_from_reg(c->reg, 0xE0, 1, v);
> + seq_printf(sf, "LW_IN_SIZE:\t\t0x%X\n", v[0]);
> +
> + for (i = 0; i < 2; i++) {
> + get_values_from_reg(c->reg, 0x100 + i * 0x10, 3, v);
> + seq_printf(sf, "LW_P%u_PTR_LOW:\t\t0x%X\n", i, v[0]);
Re: [PATCH v10 02/11] drm/sun4i: dsi: Update start value in video start delay
On Fri, May 24, 2019 at 2:07 AM Maxime Ripard wrote: > > On Mon, May 20, 2019 at 02:33:09PM +0530, Jagan Teki wrote: > > start value in video start delay computation done in below commit > > is as per the legacy bsp drivers/video/sunxi/legacy.. > > "drm/sun4i: dsi: Change the start delay calculation" > > (sha1: da676c6aa6413d59ab0a80c97bbc273025e640b2) > > > > This existing start delay computation gives start value of 35, > > for "bananapi,s070wv20-ct16" panel timings which indeed trigger > > panel flip_done timed out as: > > > > WARNING: CPU: 0 PID: 31 at drivers/gpu/drm/drm_atomic_helper.c:1429 > > drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 > > [CRTC:46:crtc-0] vblank wait timed out > > Modules linked in: > > CPU: 0 PID: 31 Comm: kworker/0:1 Tainted: GW > > 5.1.0-next-20190514-00025-gf928bc7cc146 #15 > > Hardware name: Allwinner sun8i Family > > Workqueue: events deferred_probe_work_func > > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > > [] (show_stack) from [] (dump_stack+0x84/0x98) > > [] (dump_stack) from [] (__warn+0xfc/0x114) > > [] (__warn) from [] (warn_slowpath_fmt+0x44/0x68) > > [] (warn_slowpath_fmt) from [] > > (drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) > > [] (drm_atomic_helper_wait_for_vblanks.part.1) from [] > > (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) > > [] (drm_atomic_helper_commit_tail_rpm) from [] > > (commit_tail+0x40/0x6c) > > [] (commit_tail) from [] > > (drm_atomic_helper_commit+0xbc/0x128) > > [] (drm_atomic_helper_commit) from [] > > (restore_fbdev_mode_atomic+0x1cc/0x1dc) > > [] (restore_fbdev_mode_atomic) from [] > > (drm_fb_helper_pan_display+0xac/0x1d0) > > [] (drm_fb_helper_pan_display) from [] > > (fb_pan_display+0xcc/0x134) > > [] (fb_pan_display) from [] > > (bit_update_start+0x14/0x30) > > [] (bit_update_start) from [] > > (fbcon_switch+0x3d8/0x4e0) > > [] (fbcon_switch) from [] (redraw_screen+0x174/0x238) > > [] (redraw_screen) from [] > > (fbcon_prepare_logo+0x3c4/0x400) > > [] (fbcon_prepare_logo) from [] > > (fbcon_init+0x3c8/0x5ac) > > [] (fbcon_init) from [] (visual_init+0xbc/0x104) > > [] (visual_init) from [] > > (do_bind_con_driver+0x1b0/0x390) > > [] (do_bind_con_driver) from [] > > (do_take_over_console+0x13c/0x1c4) > > [] (do_take_over_console) from [] > > (do_fbcon_takeover+0x74/0xcc) > > [] (do_fbcon_takeover) from [] > > (notifier_call_chain+0x44/0x84) > > [] (notifier_call_chain) from [] > > (__blocking_notifier_call_chain+0x48/0x60) > > [] (__blocking_notifier_call_chain) from [] > > (blocking_notifier_call_chain+0x18/0x20) > > [] (blocking_notifier_call_chain) from [] > > (register_framebuffer+0x1e0/0x2f8) > > [] (register_framebuffer) from [] > > (__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c) > > [] (__drm_fb_helper_initial_config_and_unlock) from [] > > (drm_fbdev_client_hotplug+0xe8/0x1b8) > > [] (drm_fbdev_client_hotplug) from [] > > (drm_fbdev_generic_setup+0x88/0x118) > > [] (drm_fbdev_generic_setup) from [] > > (sun4i_drv_bind+0x128/0x160) > > [] (sun4i_drv_bind) from [] > > (try_to_bring_up_master+0x164/0x1a0) > > [] (try_to_bring_up_master) from [] > > (__component_add+0x94/0x140) > > [] (__component_add) from [] > > (sun6i_dsi_probe+0x144/0x234) > > [] (sun6i_dsi_probe) from [] > > (platform_drv_probe+0x48/0x9c) > > [] (platform_drv_probe) from [] > > (really_probe+0x1dc/0x2c8) > > [] (really_probe) from [] > > (driver_probe_device+0x60/0x160) > > [] (driver_probe_device) from [] > > (bus_for_each_drv+0x74/0xb8) > > [] (bus_for_each_drv) from [] > > (__device_attach+0xd0/0x13c) > > [] (__device_attach) from [] > > (bus_probe_device+0x84/0x8c) > > [] (bus_probe_device) from [] > > (deferred_probe_work_func+0x64/0x90) > > [] (deferred_probe_work_func) from [] > > (process_one_work+0x204/0x420) > > [] (process_one_work) from [] > > (worker_thread+0x274/0x5a0) > > [] (worker_thread) from [] (kthread+0x11c/0x14c) > > [] (kthread) from [] (ret_from_fork+0x14/0x2c) > > Exception stack(0xde539fb0 to 0xde539ff8) > > 9fa0: > > > > 9fc0: > > > > 9fe0: 0013 > > ---[ end trace 755e10f62b83f396 ]--- > > Console: switching to colour frame buffer device 100x30 > > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:46:crtc-0] > > flip_done timed out > > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:48:DSI-1] > > flip_done timed out > > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:30:plane-0] > > flip_done timed out > > > > But the expected start delay value is 1 which is confirmed from > > new bsp [2]. > > If you're saying that the "legacy" link (second one) is the new BSP. Will update, thanks. > > > The important and unclear note on legacy and new bsp codes [1] [2]
Re: [PATCH v10 03/11] drm/sun4i: dsi: Fix video start delay computation
On Fri, May 24, 2019 at 2:18 AM Maxime Ripard wrote: > > On Mon, May 20, 2019 at 02:33:10PM +0530, Jagan Teki wrote: > > The current code is computing vertical video start delay as > > > > delay = mode->vtotal - (mode->vsync_end - mode->vdisplay) + start; > > > > On which the second parameter > > > > mode->vsync_end - mode->vdisplay = front porch + sync timings > > > > according to "DRM kernel-internal display mode structure" in > > include/drm/drm_modes.h > > > > With adding additional sync timings, the desired video start delay > > value as 510 for "bananapi,s070wv20-ct16" panel timings which indeed > > trigger panel flip_done timed out as: > > > > WARNING: CPU: 0 PID: 31 at drivers/gpu/drm/drm_atomic_helper.c:1429 > > drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 > > [CRTC:46:crtc-0] vblank wait timed out > > Modules linked in: > > CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted > > 5.1.0-next-20190514-00029-g09e5b0ed0a58 #18 > > Hardware name: Allwinner sun8i Family > > Workqueue: events deferred_probe_work_func > > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > > [] (show_stack) from [] (dump_stack+0x84/0x98) > > [] (dump_stack) from [] (__warn+0xfc/0x114) > > [] (__warn) from [] (warn_slowpath_fmt+0x44/0x68) > > [] (warn_slowpath_fmt) from [] > > (drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) > > [] (drm_atomic_helper_wait_for_vblanks.part.1) from [] > > (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) > > [] (drm_atomic_helper_commit_tail_rpm) from [] > > (commit_tail+0x40/0x6c) > > [] (commit_tail) from [] > > (drm_atomic_helper_commit+0xbc/0x128) > > [] (drm_atomic_helper_commit) from [] > > (restore_fbdev_mode_atomic+0x1cc/0x1dc) > > [] (restore_fbdev_mode_atomic) from [] > > (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) > > [] (drm_fb_helper_restore_fbdev_mode_unlocked) from [] > > (drm_fb_helper_set_par+0x30/0x54) > > [] (drm_fb_helper_set_par) from [] > > (fbcon_init+0x560/0x5ac) > > [] (fbcon_init) from [] (visual_init+0xbc/0x104) > > [] (visual_init) from [] > > (do_bind_con_driver+0x1b0/0x390) > > [] (do_bind_con_driver) from [] > > (do_take_over_console+0x13c/0x1c4) > > [] (do_take_over_console) from [] > > (do_fbcon_takeover+0x74/0xcc) > > [] (do_fbcon_takeover) from [] > > (notifier_call_chain+0x44/0x84) > > [] (notifier_call_chain) from [] > > (__blocking_notifier_call_chain+0x48/0x60) > > [] (__blocking_notifier_call_chain) from [] > > (blocking_notifier_call_chain+0x18/0x20) > > [] (blocking_notifier_call_chain) from [] > > (register_framebuffer+0x1e0/0x2f8) > > [] (register_framebuffer) from [] > > (__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c) > > [] (__drm_fb_helper_initial_config_and_unlock) from [] > > (drm_fbdev_client_hotplug+0xe8/0x1b8) > > [] (drm_fbdev_client_hotplug) from [] > > (drm_fbdev_generic_setup+0x88/0x118) > > [] (drm_fbdev_generic_setup) from [] > > (sun4i_drv_bind+0x128/0x160) > > [] (sun4i_drv_bind) from [] > > (try_to_bring_up_master+0x164/0x1a0) > > [] (try_to_bring_up_master) from [] > > (__component_add+0x94/0x140) > > [] (__component_add) from [] > > (sun6i_dsi_probe+0x144/0x234) > > [] (sun6i_dsi_probe) from [] > > (platform_drv_probe+0x48/0x9c) > > [] (platform_drv_probe) from [] > > (really_probe+0x1dc/0x2c8) > > [] (really_probe) from [] > > (driver_probe_device+0x60/0x160) > > [] (driver_probe_device) from [] > > (bus_for_each_drv+0x74/0xb8) > > [] (bus_for_each_drv) from [] > > (__device_attach+0xd0/0x13c) > > [] (__device_attach) from [] > > (bus_probe_device+0x84/0x8c) > > [] (bus_probe_device) from [] > > (deferred_probe_work_func+0x64/0x90) > > [] (deferred_probe_work_func) from [] > > (process_one_work+0x204/0x420) > > [] (process_one_work) from [] > > (worker_thread+0x274/0x5a0) > > [] (worker_thread) from [] (kthread+0x11c/0x14c) > > [] (kthread) from [] (ret_from_fork+0x14/0x2c) > > Exception stack(0xde539fb0 to 0xde539ff8) > > 9fa0: > > > > 9fc0: > > > > 9fe0: 0013 > > ---[ end trace 495200a78b24980e ]--- > > random: fast init done > > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:46:crtc-0] > > flip_done timed out > > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:48:DSI-1] > > flip_done timed out > > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:30:plane-0] > > flip_done timed out > > > > But the expected video start delay value is 513 which states that > > the second parameter on the computation is "front porch" value > > (no sync timings included). > > > > This is clearly confirmed from the legacy [1] and new [2] bsp codes > > that the second parameter on the video start delay is "front porch" > > > > Here is the detailed evidence for calculating front porch as per > > bsp code
Re: [RFC PATCH] drm/ttm, drm/vmwgfx: Have TTM support AMD SEV encryption
On 5/24/19 12:18 PM, Koenig, Christian wrote: Am 24.05.19 um 11:55 schrieb Thomas Hellstrom: [CAUTION: External Email] On 5/24/19 11:11 AM, Thomas Hellstrom wrote: Hi, Christian, On 5/24/19 10:37 AM, Koenig, Christian wrote: Am 24.05.19 um 10:11 schrieb Thomas Hellström (VMware): [CAUTION: External Email] From: Thomas Hellstrom With SEV encryption, all DMA memory must be marked decrypted (AKA "shared") for devices to be able to read it. In the future we might want to be able to switch normal (encrypted) memory to decrypted in exactly the same way as we handle caching states, and that would require additional memory pools. But for now, rely on memory allocated with dma_alloc_coherent() which is already decrypted with SEV enabled. Set up the page protection accordingly. Drivers must detect SEV enabled and switch to the dma page pool. This patch has not yet been tested. As a follow-up, we might want to cache decrypted pages in the dma page pool regardless of their caching state. This patch is unnecessary, SEV support already works fine with at least amdgpu and I would expect that it also works with other drivers as well. Also see this patch: commit 64e1f830ea5b3516a4256ed1c504a265d7f2a65c Author: Christian König Date: Wed Mar 13 10:11:19 2019 +0100 drm: fallback to dma_alloc_coherent when memory encryption is active We can't just map any randome page we get when memory encryption is active. Signed-off-by: Christian König Acked-by: Alex Deucher Link: https://patchwork.kernel.org/patch/10850833/ Regards, Christian. Yes, I noticed that. Although I fail to see where we automagically clear the PTE encrypted bit when mapping coherent memory? For the linear kernel map, that's done within dma_alloc_coherent() but for kernel vmaps and and user-space maps? Is that done automatically by the x86 platform layer? Yes, I think so. Haven't looked to closely at this either. This sounds a bit odd. If that were the case, the natural place would be the PAT tracking code, but it only handles caching flags AFAICT. Not encryption flags. But when you tested AMD with SEV, was that running as hypervisor rather than a guest, or did you run an SEV guest with PCI passthrough to the AMD device? /Thomas And, as a follow up question, why do we need dma_alloc_coherent() when using SME? I thought the hardware performs the decryption when DMA-ing to / from an encrypted page with SME, but not with SEV? I think the issue was that the DMA API would try to use a bounce buffer in this case. SEV forces SWIOTLB bouncing on, but not SME. So it should probably be possible to avoid dma_alloc_coherent() in the SME case. /Thomas Christian. Thanks, Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build failure after merge of the drm-fixes tree
Hi all, On Fri, 24 May 2019 20:15:48 +1000 Stephen Rothwell wrote: > > Ah, in the drm-fixes tree, the definition of is protected by ^ ASICREV_IS_PICASSO -- Cheers, Stephen Rothwell pgpbeG7pS2izu.pgp Description: OpenPGP digital signature
[PATCH v2 0/6] drm/bridge: Add ICN6211 MIPI-DSI/RGB bridge
drm/bridge: Add ICN6211 MIPI-DSI/RGB bridge This is v2 series for supporting Chipone ICN6211 DSI/RGB bridge, here is the previous version set[1] The overlay patch, has Bananapi panel which would depends on, previous MIPI DSI fixes series[2] to make the panel works. Changes for v2: - use panel_or_bridge for finding panel and bridge - add panel overlay dts patch for port based panel enablement - update the bridge sequence dynamically, by getting mode timings from panel-simple - correct the brinding compatible - add more information in binding example - replace the bridge detach with proper ops - add bridge overlay dts patch for port based panel enablement [2] https://patchwork.freedesktop.org/series/60847/ [1] https://patchwork.freedesktop.org/series/58060/ Any inputs? Jagan. Jagan Teki (6): drm/sun4i: dsi: Use drm panel_or_bridge call [DO NOT MERGE] ARM: dts: sun8i: bananapi-m2m: Enable Bananapi S070WV20-CT16 DSI panel drm/sun4i: dsi: Add bridge support dt-bindings: display: bridge: Add ICN6211 MIPI-DSI to RGB converter bridge drm/bridge: Add Chipone ICN6211 MIPI-DSI/RGB converter bridge [DO NOT MERGE] ARM: dts: sun8i: bananapi-m2m: Enable Bananapi S070WV20-CT16 DSI panel .../display/bridge/chipone,icn6211.txt| 78 MAINTAINERS | 6 + arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts | 86 + drivers/gpu/drm/bridge/Kconfig| 10 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/chipone-icn6211.c | 344 ++ drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c| 67 +++- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h| 1 + 8 files changed, 575 insertions(+), 18 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/chipone,icn6211.txt create mode 100644 drivers/gpu/drm/bridge/chipone-icn6211.c -- 2.18.0.321.gffc6fa0e3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/6] drm/sun4i: dsi: Use drm panel_or_bridge call
Right now the driver is finding the panel using of_drm_find_panel,
replace the same with drm_of_find_panel_or_bridge which would help
to find the panel or bridge on the same call if bridge support added
in future.
Added NULL in bridge argument, same will replace with bridge parameter
once bridge supported.
Cc: Paul Kocialkowski
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 65771e9a343a..ae2fe31b05b1 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
@@ -964,11 +965,13 @@ static int sun6i_dsi_attach(struct mipi_dsi_host *host,
struct mipi_dsi_device *device)
{
struct sun6i_dsi *dsi = host_to_sun6i_dsi(host);
+ int ret;
dsi->device = device;
- dsi->panel = of_drm_find_panel(device->dev.of_node);
- if (IS_ERR(dsi->panel))
- return PTR_ERR(dsi->panel);
+ ret = drm_of_find_panel_or_bridge(host->dev->of_node, 0, 0,
+ &dsi->panel, NULL);
+ if (ret)
+ return ret;
dev_info(host->dev, "Attached device %s\n", device->name);
--
2.18.0.321.gffc6fa0e3
[PATCH] drm/qxl: drop WARN_ONCE()
There is no good reason to flood the kernel log with a WARN
stacktrace just because someone tried to mmap a prime buffer.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_prime.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/qxl/qxl_prime.c b/drivers/gpu/drm/qxl/qxl_prime.c
index 114653b471c6..7d3816fca5a8 100644
--- a/drivers/gpu/drm/qxl/qxl_prime.c
+++ b/drivers/gpu/drm/qxl/qxl_prime.c
@@ -77,6 +77,5 @@ void qxl_gem_prime_vunmap(struct drm_gem_object *obj, void
*vaddr)
int qxl_gem_prime_mmap(struct drm_gem_object *obj,
struct vm_area_struct *area)
{
- WARN_ONCE(1, "not implemented");
return -ENOSYS;
}
--
2.18.1
[DO NOT MERGE] [PATCH v2 2/6] ARM: dts: sun8i: bananapi-m2m: Enable Bananapi S070WV20-CT16 DSI panel
This patch add support for Bananapi S070WV20-CT16 DSI panel to
BPI-M2M board.
DSI panel connected via board DSI port with,
- DCDC1 as VCC-DSI supply
- PL5 gpio for lcd reset gpio pin
- PB7 gpio for lcd enable gpio pin
- PL4 gpio for backlight enable pin
Signed-off-by: Jagan Teki
---
arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts | 59
1 file changed, 59 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
b/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
index e1c75f7fa3ca..762d4cfcff01 100644
--- a/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
+++ b/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
@@ -44,6 +44,7 @@
#include "sun8i-a33.dtsi"
#include
+#include
/ {
model = "BananaPi M2 Magic";
@@ -61,6 +62,14 @@
stdout-path = "serial0:115200n8";
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm 0 5 PWM_POLARITY_INVERTED>;
+ brightness-levels = <1 2 4 8 16 32 64 128 255>;
+ default-brightness-level = <8>;
+ enable-gpios = <&r_pio 0 4 GPIO_ACTIVE_HIGH>; /* LCD-BL-EN: PL4
*/
+ };
+
leds {
compatible = "gpio-leds";
@@ -122,6 +131,46 @@
status = "okay";
};
+&de {
+ status = "okay";
+};
+
+&dphy {
+ status = "okay";
+};
+
+&dsi {
+ vcc-dsi-supply = <®_dcdc1>; /* VCC-DSI */
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dsi_out: port@0 {
+ reg = <0>;
+
+ dsi_out_panel: endpoint {
+ remote-endpoint = <&panel_out_dsi>;
+ };
+ };
+ };
+
+ panel@0 {
+ compatible = "bananapi,s070wv20-ct16-icn6211";
+ reg = <0>;
+ enable-gpios = <&pio 1 7 GPIO_ACTIVE_HIGH>; /* LCD-PWR-EN: PB7
*/
+ reset-gpios = <&r_pio 0 5 GPIO_ACTIVE_HIGH>; /* LCD-RST: PL5 */
+ backlight = <&backlight>;
+
+ port {
+ panel_out_dsi: endpoint {
+ remote-endpoint = <&dsi_out_panel>;
+ };
+ };
+ };
+};
+
&ehci0 {
status = "okay";
};
@@ -157,6 +206,12 @@
status = "okay";
};
+&pwm {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm0_pin>;
+ status = "okay";
+};
+
&r_rsb {
status = "okay";
@@ -269,6 +324,10 @@
status = "okay";
};
+&tcon0 {
+ status = "okay";
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pb_pins>;
--
2.18.0.321.gffc6fa0e3
[PATCH v2 4/6] dt-bindings: display: bridge: Add ICN6211 MIPI-DSI to RGB converter bridge
ICN6211 is MIPI-DSI/RGB converter bridge from chipone.
It has a flexible configuration of MIPI DSI signal input
and produce RGB565, RGB666, RGB888 output format.
Add dt-bingings for it.
Signed-off-by: Jagan Teki
---
.../display/bridge/chipone,icn6211.txt| 78 +++
1 file changed, 78 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/chipone,icn6211.txt
diff --git
a/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.txt
b/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.txt
new file mode 100644
index ..53a9848ef8b6
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.txt
@@ -0,0 +1,78 @@
+Chipone ICN6211 MIPI-DSI to RGB Converter Bridge
+
+ICN6211 is MIPI-DSI/RGB converter bridge from chipone.
+It has a flexible configuration of MIPI DSI signal input
+and produce RGB565, RGB666, RGB888 output format.
+
+Required properties for RGB:
+- compatible: must be "chipone,icn6211"
+- reg: the virtual channel number of a DSI peripheral
+- reset-gpios: a GPIO phandle for the reset pin
+
+The device node can contain following 'port' child nodes,
+according to the OF graph bindings defined in [1]:
+ 0: DSI Input, not required, if the bridge is DSI controlled
+ 1: RGB Output, mandatory
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+ panel {
+ compatible = "bananapi,s070wv20-ct16", "simple-panel";
+ enable-gpios = <&pio 1 7 GPIO_ACTIVE_HIGH>; /* LCD-PWR-EN: PB7
*/
+ backlight = <&backlight>;
+
+ port {
+ panel_out_bridge: endpoint {
+ remote-endpoint = <&bridge_out_panel>;
+ };
+ };
+ };
+
+&dsi {
+ vcc-dsi-supply = <®_dcdc1>; /* VCC-DSI */
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dsi_out: port@0 {
+ reg = <0>;
+
+ dsi_out_bridge: endpoint {
+ remote-endpoint = <&bridge_out_dsi>;
+ };
+ };
+ };
+
+ bridge@0 {
+ compatible = "chipone,icn6211";
+ reg = <0>;
+ reset-gpios = <&r_pio 0 5 GPIO_ACTIVE_HIGH>; /* LCD-RST: PL5 */
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bridge_in: port@0 {
+ reg = <0>;
+
+ bridge_out_dsi: endpoint {
+ remote-endpoint = <&dsi_out_bridge>;
+ };
+ };
+
+ bridge_out: port@1 {
+ reg = <1>;
+
+ bridge_out_panel: endpoint {
+ remote-endpoint = <&panel_out_bridge>;
+ };
+ };
+ };
+ };
+};
--
2.18.0.321.gffc6fa0e3
[PATCH v2 3/6] drm/sun4i: dsi: Add bridge support
Some display panels would come up with a non-DSI output which
can have an option to connect DSI interface by means of bridge
converter.
This DSI to non-DSI bridge converter would require a bridge
driver that would communicate the DSI controller for bridge
functionalities.
So, add support for bridge functionalities in Allwinner DSI
controller.
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 60 +++---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 1 +
2 files changed, 45 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index ae2fe31b05b1..2b4b1355a88f 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -775,6 +775,9 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder
*encoder)
if (!IS_ERR(dsi->panel))
drm_panel_prepare(dsi->panel);
+ if (!IS_ERR(dsi->bridge))
+ drm_bridge_pre_enable(dsi->bridge);
+
/*
* FIXME: This should be moved after the switch to HS mode.
*
@@ -790,6 +793,9 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder
*encoder)
if (!IS_ERR(dsi->panel))
drm_panel_enable(dsi->panel);
+ if (!IS_ERR(dsi->bridge))
+ drm_bridge_enable(dsi->bridge);
+
sun6i_dsi_start(dsi, DSI_START_HSC);
udelay(1000);
@@ -806,6 +812,9 @@ static void sun6i_dsi_encoder_disable(struct drm_encoder
*encoder)
if (!IS_ERR(dsi->panel)) {
drm_panel_disable(dsi->panel);
drm_panel_unprepare(dsi->panel);
+ } else if (!IS_ERR(dsi->bridge)) {
+ drm_bridge_disable(dsi->bridge);
+ drm_bridge_post_disable(dsi->bridge);
}
phy_power_off(dsi->dphy);
@@ -969,11 +978,12 @@ static int sun6i_dsi_attach(struct mipi_dsi_host *host,
dsi->device = device;
ret = drm_of_find_panel_or_bridge(host->dev->of_node, 0, 0,
- &dsi->panel, NULL);
+ &dsi->panel, &dsi->bridge);
if (ret)
return ret;
- dev_info(host->dev, "Attached device %s\n", device->name);
+ dev_info(host->dev, "Attached %s %s\n",
+dsi->bridge ? "bridge" : "panel", device->name);
return 0;
}
@@ -983,7 +993,10 @@ static int sun6i_dsi_detach(struct mipi_dsi_host *host,
{
struct sun6i_dsi *dsi = host_to_sun6i_dsi(host);
- dsi->panel = NULL;
+ if (dsi->panel)
+ dsi->panel = NULL;
+ else if (dsi->bridge)
+ dsi->bridge = NULL;
dsi->device = NULL;
return 0;
@@ -1055,8 +1068,10 @@ static int sun6i_dsi_bind(struct device *dev, struct
device *master,
struct sun4i_tcon *tcon0 = sun4i_get_tcon0(drm);
int ret;
- if (!dsi->panel)
+ if (!(dsi->panel || dsi->bridge)) {
+ dev_info(drm->dev, "No panel or bridge found... DSI output
disabled\n");
return -EPROBE_DEFER;
+ }
dsi->drv = drv;
@@ -1078,19 +1093,29 @@ static int sun6i_dsi_bind(struct device *dev, struct
device *master,
}
dsi->encoder.possible_crtcs = BIT(0);
- drm_connector_helper_add(&dsi->connector,
-&sun6i_dsi_connector_helper_funcs);
- ret = drm_connector_init(drm, &dsi->connector,
-&sun6i_dsi_connector_funcs,
-DRM_MODE_CONNECTOR_DSI);
- if (ret) {
- dev_err(dsi->dev,
- "Couldn't initialise the DSI connector\n");
- goto err_cleanup_connector;
+ if (dsi->panel) {
+ drm_connector_helper_add(&dsi->connector,
+&sun6i_dsi_connector_helper_funcs);
+ ret = drm_connector_init(drm, &dsi->connector,
+&sun6i_dsi_connector_funcs,
+DRM_MODE_CONNECTOR_DSI);
+ if (ret) {
+ dev_err(dsi->dev,
+ "Couldn't initialise the DSI connector\n");
+ goto err_cleanup_connector;
+ }
+
+ drm_connector_attach_encoder(&dsi->connector, &dsi->encoder);
+ drm_panel_attach(dsi->panel, &dsi->connector);
}
- drm_connector_attach_encoder(&dsi->connector, &dsi->encoder);
- drm_panel_attach(dsi->panel, &dsi->connector);
+ if (dsi->bridge) {
+ ret = drm_bridge_attach(&dsi->encoder, dsi->bridge, NULL);
+ if (ret) {
+ dev_err(dsi->dev, "Couldn't attach the DSI bridge\n");
+ goto err_cleanup_connector;
+ }
+ }
return 0;
@@ -1104,7 +1129,10 @@ static void sun6i_dsi_unbind(struct device *
[DO NOT MERGE] [PATCH v2 6/6] ARM: dts: sun8i: bananapi-m2m: Enable Bananapi S070WV20-CT16 DSI panel
This patch add support for Bananapi S070WV20-CT16 DSI panel to
BPI-M2M board.
Bananapi S070WV20-CT16 is a pure RGB output panel with ICN6211 DSI/RGB
convertor bridge, so enable bridge along with associated panel.
DSI panel connected via board DSI port with,
- DCDC1 as VCC-DSI supply
- PL5 gpio for bridge reset gpio pin
- PB7 gpio for lcd enable gpio pin
- PL4 gpio for backlight enable pin
Signed-off-by: Jagan Teki
---
arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts | 86
1 file changed, 86 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
b/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
index e1c75f7fa3ca..5f3f9523a03e 100644
--- a/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
+++ b/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
@@ -44,6 +44,7 @@
#include "sun8i-a33.dtsi"
#include
+#include
/ {
model = "BananaPi M2 Magic";
@@ -61,6 +62,14 @@
stdout-path = "serial0:115200n8";
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm 0 5 PWM_POLARITY_INVERTED>;
+ brightness-levels = <1 2 4 8 16 32 64 128 255>;
+ default-brightness-level = <8>;
+ enable-gpios = <&r_pio 0 4 GPIO_ACTIVE_HIGH>; /* LCD-BL-EN: PL4
*/
+ };
+
leds {
compatible = "gpio-leds";
@@ -81,6 +90,18 @@
};
};
+ panel {
+ compatible = "bananapi,s070wv20-ct16", "simple-panel";
+ enable-gpios = <&pio 1 7 GPIO_ACTIVE_HIGH>; /* LCD-PWR-EN: PB7
*/
+ backlight = <&backlight>;
+
+ port {
+ panel_out_bridge: endpoint {
+ remote-endpoint = <&bridge_out_panel>;
+ };
+ };
+ };
+
reg_vcc5v0: vcc5v0 {
compatible = "regulator-fixed";
regulator-name = "vcc5v0";
@@ -122,6 +143,61 @@
status = "okay";
};
+&de {
+ status = "okay";
+};
+
+&dphy {
+ status = "okay";
+};
+
+&dsi {
+ vcc-dsi-supply = <®_dcdc1>; /* VCC-DSI */
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dsi_out: port@0 {
+ reg = <0>;
+
+ dsi_out_bridge: endpoint {
+ remote-endpoint = <&bridge_out_dsi>;
+ };
+ };
+ };
+
+ bridge@0 {
+ compatible = "chipone,icn6211";
+ reg = <0>;
+ reset-gpios = <&r_pio 0 5 GPIO_ACTIVE_HIGH>; /* LCD-RST: PL5 */
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bridge_in: port@0 {
+ reg = <0>;
+
+ bridge_out_dsi: endpoint {
+ remote-endpoint = <&dsi_out_bridge>;
+ };
+ };
+
+ bridge_out: port@1 {
+ reg = <1>;
+
+ bridge_out_panel: endpoint {
+ remote-endpoint = <&panel_out_bridge>;
+ };
+ };
+ };
+ };
+};
+
&ehci0 {
status = "okay";
};
@@ -157,6 +233,12 @@
status = "okay";
};
+&pwm {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm0_pin>;
+ status = "okay";
+};
+
&r_rsb {
status = "okay";
@@ -269,6 +351,10 @@
status = "okay";
};
+&tcon0 {
+ status = "okay";
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pb_pins>;
--
2.18.0.321.gffc6fa0e3
Re: [PATCH] drm: assure aux_dev is nonzero before using it
On 5/24/19 4:36 AM, Jani Nikula wrote: On Thu, 23 May 2019, tcamuso wrote: From Daniel Kwon The system was crashed due to invalid memory access while trying to access auxiliary device. crash> bt PID: 9863 TASK: 89d1bdf11040 CPU: 1 COMMAND: "ipmitool" #0 [89cedd7f3868] machine_kexec at b0663674 #1 [89cedd7f38c8] __crash_kexec at b071cf62 #2 [89cedd7f3998] crash_kexec at b071d050 #3 [89cedd7f39b0] oops_end at b0d6d758 #4 [89cedd7f39d8] no_context at b0d5bcde #5 [89cedd7f3a28] __bad_area_nosemaphore at b0d5bd75 #6 [89cedd7f3a78] bad_area at b0d5c085 #7 [89cedd7f3aa0] __do_page_fault at b0d7080c #8 [89cedd7f3b10] do_page_fault at b0d70905 #9 [89cedd7f3b40] page_fault at b0d6c758 [exception RIP: drm_dp_aux_dev_get_by_minor+0x3d] RIP: c0a589bd RSP: 89cedd7f3bf0 RFLAGS: 00010246 RAX: RBX: RCX: 89cedd7f3fd8 RDX: RSI: RDI: c0a613e0 RBP: 89cedd7f3bf8 R8: 89f1bcbabbd0 R9: R10: 89f1be7a1cc0 R11: R12: R13: 89f1b32a2830 R14: 89d18fadfa00 R15: ORIG_RAX: CS: 0010 SS: 0018 RIP: 2b45f0d80d30 RSP: 7ffc416066a0 RFLAGS: 00010246 RAX: 0002 RBX: 56062e212d80 RCX: 7ffc41606810 RDX: RSI: 0002 RDI: 7ffc41606ec0 RBP: R8: 56062dfed229 R9: 2b45f0cdf14d R10: 0002 R11: 0246 R12: 7ffc41606ec0 R13: 7ffc41606ed0 R14: 7ffc41606ee0 R15: ORIG_RAX: 0002 CS: 0033 SS: 002b It was trying to open '/dev/ipmi0', but as no entry in aux_dir, it returned NULL from 'idr_find()'. This drm_dp_aux_dev_get_by_minor() should have done a check on this, but had failed to do it. I think the better question is, *why* does the idr_find() return NULL? I don't think it should, under any circumstances. I fear adding the check here papers over some other problem, taking us further away from the root cause. That's a very good question. Also, can you reproduce this on a recent upstream kernel? The aux device nodes were introduced in kernel v4.6. Whatever you reproduced on v3.10 is pretty much irrelevant for upstream. I will look into this deeper, using the upstream kernel. BR, Jani. -- snip --
Re: [PATCH] drm/komeda: Creates plane alpha and blend mode properties
On Fri, May 24, 2019 at 05:20:24PM +0800, Lowry Li (Arm Technology China) wrote: > From: "Lowry Li (Arm Technology China)" > > Creates plane alpha and blend mode properties attached to plane. > > This patch depends on: > - https://patchwork.freedesktop.org/series/59915/ > - https://patchwork.freedesktop.org/series/58665/ > - https://patchwork.freedesktop.org/series/59000/ > - https://patchwork.freedesktop.org/series/59002/ > - https://patchwork.freedesktop.org/series/59471/ > > Changes since v1: > - Adds patch denpendency in the comment > > Changes since v2: > - Remove [RFC] from the subject > > Changes since v3: > - Rebase the code > > Signed-off-by: Lowry Li (Arm Technology China) > --- > drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c > b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c > index e7cd690..9b87c25 100644 > --- a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c > @@ -303,6 +303,17 @@ static int komeda_plane_add(struct komeda_kms_dev *kms, > > drm_plane_helper_add(plane, &komeda_plane_helper_funcs); > > + err = drm_plane_create_alpha_property(plane); > + if (err) > + goto cleanup; > + > + err = drm_plane_create_blend_mode_property(plane, > + BIT(DRM_MODE_BLEND_PIXEL_NONE) | > + BIT(DRM_MODE_BLEND_PREMULTI) | > + BIT(DRM_MODE_BLEND_COVERAGE)); > + if (err) > + goto cleanup; > + > err = komeda_plane_create_layer_properties(kplane, layer); > if (err) > goto cleanup; > -- > 1.9.1 > lgtm. Reviewed-by: James Qian Wang (Arm Technology China)
[PATCH v2 5/6] drm/bridge: Add Chipone ICN6211 MIPI-DSI/RGB converter bridge
ICN6211 is MIPI-DSI/RGB converter bridge from chipone.
It has a flexible configuration of MIPI DSI signal input
and produce RGB565, RGB666, RGB888 output format.
Add bridge driver for it.
Signed-off-by: Jagan Teki
---
Note:
- drm_panel_bridge_add seems not working or incompatible
as per driver setup. any inputs on this would be great.
MAINTAINERS | 6 +
drivers/gpu/drm/bridge/Kconfig | 10 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/chipone-icn6211.c | 344 +++
4 files changed, 361 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/chipone-icn6211.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 4cc30c360fda..97ffb265bedc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4991,6 +4991,12 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
S: Maintained
F: drivers/gpu/drm/bochs/
+DRM DRIVER FOR CHIPONE ICN6211 MIPI-DSI to RGB CONVERTOR BRIDGE
+M: Jagan Teki
+S: Maintained
+F: drivers/gpu/drm/bridge/chipone-icn6211.c
+F: Documentation/devicetree/bindings/display/bridge/chipone,icn6211.txt
+
DRM DRIVER FOR FARADAY TVE200 TV ENCODER
M: Linus Walleij
T: git git://anongit.freedesktop.org/drm/drm-misc
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3dff9997f5e3..2e06be1aaca3 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -36,6 +36,16 @@ config DRM_CDNS_DSI
Support Cadence DPI to DSI bridge. This is an internal
bridge and is meant to be directly embedded in a SoC.
+config DRM_CHIPONE_ICN6211
+ tristate "Chipone ICN6211 MIPI-DSI/RGB converter bridge"
+ depends on DRM && DRM_PANEL
+ depends on OF
+ select DRM_MIPI_DSI
+ help
+ ICN6211 is MIPI-DSI/RGB converter bridge from chipone.
+ It has a flexible configuration of MIPI DSI signal input
+ and produce RGB565, RGB666, RGB888 output format.
+
config DRM_DUMB_VGA_DAC
tristate "Dumb VGA DAC Bridge support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 4934fcf5a6f8..541fdccad10b 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
+obj-$(CONFIG_DRM_CHIPONE_ICN6211) += chipone-icn6211.o
obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
megachips-stdp-ge-b850v3-fw.o
diff --git a/drivers/gpu/drm/bridge/chipone-icn6211.c
b/drivers/gpu/drm/bridge/chipone-icn6211.c
new file mode 100644
index ..76edda52dc57
--- /dev/null
+++ b/drivers/gpu/drm/bridge/chipone-icn6211.c
@@ -0,0 +1,344 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Amarula Solutions
+ * Author: Jagan Teki
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct chipone_bridge_desc {
+ unsigned int lanes;
+ unsigned long mode_flags;
+ enum mipi_dsi_pixel_format format;
+ void (*chipone_bridge_init)(struct drm_bridge *bridge);
+};
+
+struct chipone {
+ struct device *dev;
+ struct drm_bridge bridge;
+ struct drm_connector connector;
+ struct drm_panel *panel;
+ const struct drm_display_mode *mode;
+ const struct chipone_bridge_desc *desc;
+
+ struct gpio_desc *reset_gpio;
+};
+
+static inline struct chipone *bridge_to_chipone(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct chipone, bridge);
+}
+
+static inline
+struct chipone *connector_to_chipone(struct drm_connector *connector)
+{
+ return container_of(connector, struct chipone, connector);
+}
+
+static int chipone_get_modes(struct drm_connector *connector)
+{
+ struct chipone *icn = connector_to_chipone(connector);
+
+ return drm_panel_get_modes(icn->panel);
+}
+
+static const
+struct drm_connector_helper_funcs chipone_connector_helper_funcs = {
+ .get_modes = chipone_get_modes,
+};
+
+static const struct drm_connector_funcs chipone_connector_funcs = {
+ .fill_modes = drm_helper_probe_single_connector_modes,
+ .destroy = drm_connector_cleanup,
+ .reset = drm_atomic_helper_connector_reset,
+ .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+static void chipone_disable(struct drm_bridge *bridge)
+{
+ struct chipone *icn = bridge_to_chipone(bridge);
+ int ret;
+
+ ret = drm_panel_disable(bridge_to_chipone(bridge)->panel);
+ if (ret < 0)
+ DRM_DEV_ERROR(icn->dev, "error disabling panel (%d)\n", ret);
+}
+
+st
Re: [PATCH 3/5] drm/vmwgfx: use core drm to extend/check vmw_execbuf_ioctl
On 2019/05/24, Daniel Vetter wrote:
> On Fri, May 24, 2019 at 8:05 AM Thomas Hellstrom
> wrote:
> >
> > On Wed, 2019-05-22 at 21:09 +0200, Daniel Vetter wrote:
> > > On Wed, May 22, 2019 at 9:01 PM Thomas Hellstrom <
> > > thellst...@vmware.com> wrote:
> > > > Hi, Emil,
> > > >
> > > > On Wed, 2019-05-22 at 17:41 +0100, Emil Velikov wrote:
> > > > > From: Emil Velikov
> > > > >
> > > > > Currently vmw_execbuf_ioctl() open-codes the permission checking,
> > > > > size
> > > > > extending and copying that is already done in core drm.
> > > > >
> > > > > Kill all the duplication, adding a few comments for clarity.
> > > >
> > > > Ah, there is core functionality for this now.
> > > >
> > > > What worries me though with the core approach is that the sizes are
> > > > not
> > > > capped by the size of the kernel argument definition, which makes
> > > > mailicious user-space being able to force kmallocs() the size of
> > > > the
> > > > maximum ioctl size. Should probably be fixed before pushing this.
> > >
> > > Hm I always worked under the assumption that kmalloc and friends
> > > should be userspace hardened. Otherwise stuff like kmalloc_array
> > > doesn't make any sense, everyone just feeds it unchecked input and
> > > expects that helper to handle overflows.
> > >
> > > If we assume kmalloc isn't hardened against that, then we have a much
> > > bigger problem than just vmwgfx ioctls ...
> >
> > After checking the drm_ioctl code I realize that what I thought was new
> > behaviour actually has been around for a couple of years, so
> > fixing isn't really tied to this patch series...
> >
> > What caused me to react was that previously we used to have this
> >
> > e4fda9f264e1 ("drm: Perform ioctl command validation on the stored
> > kernel values")
> >
> > and we seem to have lost that now, if not for the io flags then at
> > least for the size part. For the size of the ioctl arguments, I think
> > in general if the kernel only touches a subset of the user-space
> > specified size I see no reason why we should malloc / copy more than
> > that?
>
> I guess we could optimize that, but we'd probably still need to zero
> clear the added size for forward compat with newer userspace. Iirc
> we've had some issues in this area.
>
> > Now, given the fact that the maximum ioctl argument size is quite
> > limited, that might not be a big problem or a problem at all. Otherwise
> > it would be pretty easy for a malicious process to allocate most or all
> > of a system's resident memory?
>
> The biggest you can allocate from kmalloc is limited by the largest
> contiguous chunk alloc_pages gives you, which is limited by MAX_ORDER
> from the page buddy allocator. You need lots of process to be able to
> exhaust memory like that (and like I said, the entire kernel would be
> broken if we'd consider this a security issue). If you want to make
> sure that a process group can't exhaust memory this way then you need
> to set appropriate cgroups limits.
I do agree with all the sentiments that drm_ioctl() could use some extra
optimisation and hardening. At the same time I would remind that the
code has been used as-is by vmwgfx and other drivers for years.
In other words: let's keep that work as orthogonal series.
What do you guys think?
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm/vmwgfx: use core drm to extend/check vmw_execbuf_ioctl
On 5/24/19 12:53 PM, Emil Velikov wrote:
On 2019/05/24, Daniel Vetter wrote:
On Fri, May 24, 2019 at 8:05 AM Thomas Hellstrom wrote:
On Wed, 2019-05-22 at 21:09 +0200, Daniel Vetter wrote:
On Wed, May 22, 2019 at 9:01 PM Thomas Hellstrom <
thellst...@vmware.com> wrote:
Hi, Emil,
On Wed, 2019-05-22 at 17:41 +0100, Emil Velikov wrote:
From: Emil Velikov
Currently vmw_execbuf_ioctl() open-codes the permission checking,
size
extending and copying that is already done in core drm.
Kill all the duplication, adding a few comments for clarity.
Ah, there is core functionality for this now.
What worries me though with the core approach is that the sizes are
not
capped by the size of the kernel argument definition, which makes
mailicious user-space being able to force kmallocs() the size of
the
maximum ioctl size. Should probably be fixed before pushing this.
Hm I always worked under the assumption that kmalloc and friends
should be userspace hardened. Otherwise stuff like kmalloc_array
doesn't make any sense, everyone just feeds it unchecked input and
expects that helper to handle overflows.
If we assume kmalloc isn't hardened against that, then we have a much
bigger problem than just vmwgfx ioctls ...
After checking the drm_ioctl code I realize that what I thought was new
behaviour actually has been around for a couple of years, so
fixing isn't really tied to this patch series...
What caused me to react was that previously we used to have this
e4fda9f264e1 ("drm: Perform ioctl command validation on the stored
kernel values")
and we seem to have lost that now, if not for the io flags then at
least for the size part. For the size of the ioctl arguments, I think
in general if the kernel only touches a subset of the user-space
specified size I see no reason why we should malloc / copy more than
that?
I guess we could optimize that, but we'd probably still need to zero
clear the added size for forward compat with newer userspace. Iirc
we've had some issues in this area.
Now, given the fact that the maximum ioctl argument size is quite
limited, that might not be a big problem or a problem at all. Otherwise
it would be pretty easy for a malicious process to allocate most or all
of a system's resident memory?
The biggest you can allocate from kmalloc is limited by the largest
contiguous chunk alloc_pages gives you, which is limited by MAX_ORDER
from the page buddy allocator. You need lots of process to be able to
exhaust memory like that (and like I said, the entire kernel would be
broken if we'd consider this a security issue). If you want to make
sure that a process group can't exhaust memory this way then you need
to set appropriate cgroups limits.
I do agree with all the sentiments that drm_ioctl() could use some extra
optimisation and hardening. At the same time I would remind that the
code has been used as-is by vmwgfx and other drivers for years.
In other words: let's keep that work as orthogonal series.
What do you guys think?
I agree. Then I only had a concern with one of the patches.
/Thomas
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/komeda: Added AFBC support for komeda driver
Hi,
On Tue, May 21, 2019 at 09:45:58AM +0100, james qian wang (Arm Technology
China) wrote:
> On Thu, May 16, 2019 at 09:57:49PM +0800, Ayan Halder wrote:
> > On Thu, Apr 04, 2019 at 12:06:14PM +0100, james qian wang (Arm Technology
> > China) wrote:
> > >
> > > +static int
> > > +komeda_fb_afbc_size_check(struct komeda_fb *kfb, struct drm_file *file,
> > > + const struct drm_mode_fb_cmd2 *mode_cmd)
> > > +{
> > > + struct drm_framebuffer *fb = &kfb->base;
> > > + const struct drm_format_info *info = fb->format;
> > > + struct drm_gem_object *obj;
> > > + u32 alignment_w = 0, alignment_h = 0, alignment_header;
> > > + u32 n_blocks = 0, min_size = 0;
> > > +
> > > + obj = drm_gem_object_lookup(file, mode_cmd->handles[0]);
> > > + if (!obj) {
> > > + DRM_DEBUG_KMS("Failed to lookup GEM object\n");
> > > + return -ENOENT;
> > > + }
> > > +
> > > + switch (fb->modifier & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) {
> > > + case AFBC_FORMAT_MOD_BLOCK_SIZE_32x8:
> > > + alignment_w = 32;
> > > + alignment_h = 8;
> > > + break;
> > > + case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16:
> > > + alignment_w = 16;
> > > + alignment_h = 16;
> > > + break;
> > > + default:
> > Can we have something like a warn here ?
>
> will add a WARN here.
>
I think it's better not to. fb->modifier comes from
userspace, so a malicious app could spam us with WARNs, effectively
dos-ing the system. -EINVAL should be sufficient.
Thanks,
-Brian
Re: [PATCH v2 3/6] drm/sun4i: dsi: Add bridge support
Hi, On Fri, May 24, 2019 at 04:13:14PM +0530, Jagan Teki wrote: > Some display panels would come up with a non-DSI output which > can have an option to connect DSI interface by means of bridge > converter. > > This DSI to non-DSI bridge converter would require a bridge > driver that would communicate the DSI controller for bridge > functionalities. > > So, add support for bridge functionalities in Allwinner DSI > controller. > > Signed-off-by: Jagan Teki > --- > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 60 +++--- > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 1 + > 2 files changed, 45 insertions(+), 16 deletions(-) > > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > index ae2fe31b05b1..2b4b1355a88f 100644 > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > @@ -775,6 +775,9 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder > *encoder) > if (!IS_ERR(dsi->panel)) > drm_panel_prepare(dsi->panel); > > + if (!IS_ERR(dsi->bridge)) > + drm_bridge_pre_enable(dsi->bridge); > + drm_panel_bridge provides what's needed to deal with both a panel and a bridge, I guess it would make sense to use this instead of duplicating everything. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] video: fbdev: pvr2fb: add COMPILE_TEST support
Add COMPILE_TEST support to pvr2fb driver for better compile
testing coverage.
While at it:
- mark pvr2fb_interrupt() and pvr2fb_common_init() with
__maybe_unused tag (to silence build warnings when
!SH_DREAMCAST)
- convert mmio_base in struct pvr2fb_par to 'void __iomem *'
from 'unsigned long' (needed to silence build warnings on
ARM).
- split pvr2_get_param() on pvr2_get_param_name() and
pvr2_get_param_val() (needed to silence build warnings on
x86).
Signed-off-by: Bartlomiej Zolnierkiewicz
---
v2: fix build warnings on x86 reported by kbuild test robot
patch #1/2 is unchanged so I'm not sending it again
drivers/video/fbdev/Kconfig |3 +-
drivers/video/fbdev/pvr2fb.c | 61 +++
2 files changed, 36 insertions(+), 28 deletions(-)
Index: b/drivers/video/fbdev/Kconfig
===
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -807,7 +807,8 @@ config FB_XVR1000
config FB_PVR2
tristate "NEC PowerVR 2 display support"
- depends on FB && SH_DREAMCAST
+ depends on FB && HAS_IOMEM
+ depends on SH_DREAMCAST || COMPILE_TEST
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
Index: b/drivers/video/fbdev/pvr2fb.c
===
--- a/drivers/video/fbdev/pvr2fb.c
+++ b/drivers/video/fbdev/pvr2fb.c
@@ -139,7 +139,7 @@ static struct pvr2fb_par {
unsigned char is_doublescan;/* Are scanlines output twice?
(doublescan) */
unsigned char is_lowres;/* Is horizontal pixel-doubling
enabled? */
- unsigned long mmio_base;/* MMIO base */
+ void __iomem *mmio_base;/* MMIO base */
u32 palette[16];
} *currentpar;
@@ -325,9 +325,9 @@ static int pvr2fb_setcolreg(unsigned int
* anything if the cable type has been overidden (via "cable:XX").
*/
-#define PCTRA 0xff80002c
-#define PDTRA 0xff800030
-#define VOUTC 0xa0702c00
+#define PCTRA ((void __iomem *)0xff80002c)
+#define PDTRA ((void __iomem *)0xff800030)
+#define VOUTC ((void __iomem *)0xa0702c00)
static int pvr2_init_cable(void)
{
@@ -619,7 +619,7 @@ static void pvr2_do_blank(void)
is_blanked = do_blank > 0 ? do_blank : 0;
}
-static irqreturn_t pvr2fb_interrupt(int irq, void *dev_id)
+static irqreturn_t __maybe_unused pvr2fb_interrupt(int irq, void *dev_id)
{
struct fb_info *info = dev_id;
@@ -722,23 +722,30 @@ static struct fb_ops pvr2fb_ops = {
.fb_imageblit = cfb_imageblit,
};
-static int pvr2_get_param(const struct pvr2_params *p, const char *s, int val,
- int size)
+static int pvr2_get_param_val(const struct pvr2_params *p, const char *s,
+ int size)
{
int i;
- for (i = 0 ; i < size ; i++ ) {
- if (s != NULL) {
- if (!strncasecmp(p[i].name, s, strlen(s)))
- return p[i].val;
- } else {
- if (p[i].val == val)
- return (int)p[i].name;
- }
+ for (i = 0 ; i < size; i++ ) {
+ if (!strncasecmp(p[i].name, s, strlen(s)))
+ return p[i].val;
}
return -1;
}
+static char *pvr2_get_param_name(const struct pvr2_params *p, int val,
+ int size)
+{
+ int i;
+
+ for (i = 0 ; i < size; i++ ) {
+ if (p[i].val == val)
+ return p[i].name;
+ }
+ return NULL;
+}
+
/**
* pvr2fb_common_init
*
@@ -757,7 +764,7 @@ static int pvr2_get_param(const struct p
* in for flexibility anyways. Who knows, maybe someone has tv-out on a
* PCI-based version of these things ;-)
*/
-static int pvr2fb_common_init(void)
+static int __maybe_unused pvr2fb_common_init(void)
{
struct pvr2fb_par *par = currentpar;
unsigned long modememused, rev;
@@ -770,8 +777,8 @@ static int pvr2fb_common_init(void)
goto out_err;
}
- par->mmio_base = (unsigned long)ioremap_nocache(pvr2_fix.mmio_start,
- pvr2_fix.mmio_len);
+ par->mmio_base = ioremap_nocache(pvr2_fix.mmio_start,
+pvr2_fix.mmio_len);
if (!par->mmio_base) {
printk(KERN_ERR "pvr2fb: Failed to remap mmio space\n");
goto out_err;
@@ -819,8 +826,8 @@ static int pvr2fb_common_init(void)
fb_info->var.xres, fb_info->var.yres,
fb_info->var.bits_per_pixel,
get_line_length(fb_info->var.xres, fb_info->var.bits_per_pixel),
- (char *)pvr2_get_param(cables, NULL, cable_type, 3),
- (char *)pvr2_get_param(outputs, NULL, video_output, 3));
+ pvr2_get_param_name(cables, cable_type,
Re: [PATCH] drm/vmwgfx: fix a warning due to missing dma_parms
On Fri, 2019-05-24 at 08:19 +0200, Christoph Hellwig wrote: > On Thu, May 23, 2019 at 10:37:19PM -0400, Qian Cai wrote: > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c > > b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c > > index bf6c3500d363..5c567b81174f 100644 > > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c > > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c > > @@ -747,6 +747,13 @@ static int vmw_driver_load(struct drm_device > > *dev, unsigned long chipset) > > if (unlikely(ret != 0)) > > goto out_err0; > > > > + dev->dev->dma_parms = kzalloc(sizeof(*dev->dev->dma_parms), > > + GFP_KERNEL); > > + if (!dev->dev->dma_parms) > > + goto out_err0; > > What bus does this device come from? I though vmgfx was a > (virtualized) > PCI device, in which case this should be provided by the PCI core. > Or are we calling DMA mapping routines on arbitrary other struct > device, > in which case that is the real bug and we should switch the PCI > device > instead. It's a PCI device. The struct device * used in dma_map_sg() is the same as the &pci_dev->dev handed to the probe() callback. But at probe time, the struct device::dma_parms is non-NULL, at least on my system so there shouldn't really be a need to kzalloc() it. > > > + dma_set_max_seg_size(dev->dev, *dev->dev->dma_mask); The max is U32_MAX. /Thomas > > That looks odd. If you want to support an unlimited segment size > just pass UINT_MAX here. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/2] video: fbdev: pvr2fb: add COMPILE_TEST support
Add COMPILE_TEST support to pvr2fb driver for better compile
testing coverage.
While at it:
- mark pvr2fb_interrupt() and pvr2fb_common_init() with
__maybe_unused tag (to silence build warnings when
!SH_DREAMCAST)
- convert mmio_base in struct pvr2fb_par to 'void __iomem *'
from 'unsigned long' (needed to silence build warnings on
ARM).
- split pvr2_get_param() on pvr2_get_param_name() and
pvr2_get_param_val() (needed to silence build warnings on
x86).
Signed-off-by: Bartlomiej Zolnierkiewicz
---
v3: fix 'space prohibited before that close parenthesis ')'
checkpatch errors
v2: fix build warnings on x86 reported by kbuild test robot
patch #1/2 is unchanged so I'm not sending it again
drivers/video/fbdev/Kconfig |3 +-
drivers/video/fbdev/pvr2fb.c | 61 +++
2 files changed, 36 insertions(+), 28 deletions(-)
Index: b/drivers/video/fbdev/Kconfig
===
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -807,7 +807,8 @@ config FB_XVR1000
config FB_PVR2
tristate "NEC PowerVR 2 display support"
- depends on FB && SH_DREAMCAST
+ depends on FB && HAS_IOMEM
+ depends on SH_DREAMCAST || COMPILE_TEST
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
Index: b/drivers/video/fbdev/pvr2fb.c
===
--- a/drivers/video/fbdev/pvr2fb.c
+++ b/drivers/video/fbdev/pvr2fb.c
@@ -139,7 +139,7 @@ static struct pvr2fb_par {
unsigned char is_doublescan;/* Are scanlines output twice?
(doublescan) */
unsigned char is_lowres;/* Is horizontal pixel-doubling
enabled? */
- unsigned long mmio_base;/* MMIO base */
+ void __iomem *mmio_base;/* MMIO base */
u32 palette[16];
} *currentpar;
@@ -325,9 +325,9 @@ static int pvr2fb_setcolreg(unsigned int
* anything if the cable type has been overidden (via "cable:XX").
*/
-#define PCTRA 0xff80002c
-#define PDTRA 0xff800030
-#define VOUTC 0xa0702c00
+#define PCTRA ((void __iomem *)0xff80002c)
+#define PDTRA ((void __iomem *)0xff800030)
+#define VOUTC ((void __iomem *)0xa0702c00)
static int pvr2_init_cable(void)
{
@@ -619,7 +619,7 @@ static void pvr2_do_blank(void)
is_blanked = do_blank > 0 ? do_blank : 0;
}
-static irqreturn_t pvr2fb_interrupt(int irq, void *dev_id)
+static irqreturn_t __maybe_unused pvr2fb_interrupt(int irq, void *dev_id)
{
struct fb_info *info = dev_id;
@@ -722,23 +722,30 @@ static struct fb_ops pvr2fb_ops = {
.fb_imageblit = cfb_imageblit,
};
-static int pvr2_get_param(const struct pvr2_params *p, const char *s, int val,
- int size)
+static int pvr2_get_param_val(const struct pvr2_params *p, const char *s,
+ int size)
{
int i;
- for (i = 0 ; i < size ; i++ ) {
- if (s != NULL) {
- if (!strncasecmp(p[i].name, s, strlen(s)))
- return p[i].val;
- } else {
- if (p[i].val == val)
- return (int)p[i].name;
- }
+ for (i = 0 ; i < size; i++) {
+ if (!strncasecmp(p[i].name, s, strlen(s)))
+ return p[i].val;
}
return -1;
}
+static char *pvr2_get_param_name(const struct pvr2_params *p, int val,
+ int size)
+{
+ int i;
+
+ for (i = 0 ; i < size; i++) {
+ if (p[i].val == val)
+ return p[i].name;
+ }
+ return NULL;
+}
+
/**
* pvr2fb_common_init
*
@@ -757,7 +764,7 @@ static int pvr2_get_param(const struct p
* in for flexibility anyways. Who knows, maybe someone has tv-out on a
* PCI-based version of these things ;-)
*/
-static int pvr2fb_common_init(void)
+static int __maybe_unused pvr2fb_common_init(void)
{
struct pvr2fb_par *par = currentpar;
unsigned long modememused, rev;
@@ -770,8 +777,8 @@ static int pvr2fb_common_init(void)
goto out_err;
}
- par->mmio_base = (unsigned long)ioremap_nocache(pvr2_fix.mmio_start,
- pvr2_fix.mmio_len);
+ par->mmio_base = ioremap_nocache(pvr2_fix.mmio_start,
+pvr2_fix.mmio_len);
if (!par->mmio_base) {
printk(KERN_ERR "pvr2fb: Failed to remap mmio space\n");
goto out_err;
@@ -819,8 +826,8 @@ static int pvr2fb_common_init(void)
fb_info->var.xres, fb_info->var.yres,
fb_info->var.bits_per_pixel,
get_line_length(fb_info->var.xres, fb_info->var.bits_per_pixel),
- (char *)pvr2_get_param(cables, NULL, cable_type, 3),
- (char *)pvr2_get_param(outputs,
Re: [PATCH] drm: assure aux_dev is nonzero before using it
On Fri, May 24, 2019 at 06:48:32AM -0400, tony camuso wrote: > On 5/24/19 4:36 AM, Jani Nikula wrote: > > On Thu, 23 May 2019, tcamuso wrote: > >> From Daniel Kwon > >> > >> The system was crashed due to invalid memory access while trying to access > >> auxiliary device. > >> > >> crash> bt > >> PID: 9863 TASK: 89d1bdf11040 CPU: 1 COMMAND: "ipmitool" > >> #0 [89cedd7f3868] machine_kexec at b0663674 > >> #1 [89cedd7f38c8] __crash_kexec at b071cf62 > >> #2 [89cedd7f3998] crash_kexec at b071d050 > >> #3 [89cedd7f39b0] oops_end at b0d6d758 > >> #4 [89cedd7f39d8] no_context at b0d5bcde > >> #5 [89cedd7f3a28] __bad_area_nosemaphore at b0d5bd75 > >> #6 [89cedd7f3a78] bad_area at b0d5c085 > >> #7 [89cedd7f3aa0] __do_page_fault at b0d7080c > >> #8 [89cedd7f3b10] do_page_fault at b0d70905 > >> #9 [89cedd7f3b40] page_fault at b0d6c758 > >> [exception RIP: drm_dp_aux_dev_get_by_minor+0x3d] > >> RIP: c0a589bd RSP: 89cedd7f3bf0 RFLAGS: 00010246 > >> RAX: RBX: RCX: 89cedd7f3fd8 > >> RDX: RSI: RDI: c0a613e0 > >> RBP: 89cedd7f3bf8 R8: 89f1bcbabbd0 R9: > >> R10: 89f1be7a1cc0 R11: R12: > >> R13: 89f1b32a2830 R14: 89d18fadfa00 R15: > >> ORIG_RAX: CS: 0010 SS: 0018 > >> RIP: 2b45f0d80d30 RSP: 7ffc416066a0 RFLAGS: 00010246 > >> RAX: 0002 RBX: 56062e212d80 RCX: 7ffc41606810 > >> RDX: RSI: 0002 RDI: 7ffc41606ec0 > >> RBP: R8: 56062dfed229 R9: 2b45f0cdf14d > >> R10: 0002 R11: 0246 R12: 7ffc41606ec0 > >> R13: 7ffc41606ed0 R14: 7ffc41606ee0 R15: > >> ORIG_RAX: 0002 CS: 0033 SS: 002b > >> > >> > >> > >> It was trying to open '/dev/ipmi0', but as no entry in aux_dir, it returned > >> NULL from 'idr_find()'. This drm_dp_aux_dev_get_by_minor() should have > >> done a > >> check on this, but had failed to do it. > > > > I think the better question is, *why* does the idr_find() return NULL? I > > don't think it should, under any circumstances. I fear adding the check > > here papers over some other problem, taking us further away from the > > root cause. > > That's a very good question. > > > Also, can you reproduce this on a recent upstream kernel? The aux device > > nodes were introduced in kernel v4.6. Whatever you reproduced on v3.10 > > is pretty much irrelevant for upstream. > > I will look into this deeper, using the upstream kernel. Should be trivial to reproduce with mknod. I wonder if we should stick a test like that into igt actually. Not sure how happy people would be if igt creates new device nodes... -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/ttm, drm/vmwgfx: Have TTM support AMD SEV encryption
Am 24.05.19 um 12:37 schrieb Thomas Hellstrom: > [CAUTION: External Email] > > On 5/24/19 12:18 PM, Koenig, Christian wrote: >> Am 24.05.19 um 11:55 schrieb Thomas Hellstrom: >>> [CAUTION: External Email] >>> >>> On 5/24/19 11:11 AM, Thomas Hellstrom wrote: Hi, Christian, On 5/24/19 10:37 AM, Koenig, Christian wrote: > Am 24.05.19 um 10:11 schrieb Thomas Hellström (VMware): >> [CAUTION: External Email] >> >> From: Thomas Hellstrom >> >> With SEV encryption, all DMA memory must be marked decrypted >> (AKA "shared") for devices to be able to read it. In the future we >> might >> want to be able to switch normal (encrypted) memory to decrypted in >> exactly >> the same way as we handle caching states, and that would require >> additional >> memory pools. But for now, rely on memory allocated with >> dma_alloc_coherent() which is already decrypted with SEV enabled. >> Set up >> the page protection accordingly. Drivers must detect SEV enabled and >> switch >> to the dma page pool. >> >> This patch has not yet been tested. As a follow-up, we might want to >> cache decrypted pages in the dma page pool regardless of their >> caching >> state. > This patch is unnecessary, SEV support already works fine with at > least > amdgpu and I would expect that it also works with other drivers as > well. > > Also see this patch: > > commit 64e1f830ea5b3516a4256ed1c504a265d7f2a65c > Author: Christian König > Date: Wed Mar 13 10:11:19 2019 +0100 > > drm: fallback to dma_alloc_coherent when memory encryption is > active > > We can't just map any randome page we get when memory > encryption is > active. > > Signed-off-by: Christian König > Acked-by: Alex Deucher > Link: https://patchwork.kernel.org/patch/10850833/ > > Regards, > Christian. Yes, I noticed that. Although I fail to see where we automagically clear the PTE encrypted bit when mapping coherent memory? For the linear kernel map, that's done within dma_alloc_coherent() but for kernel vmaps and and user-space maps? Is that done automatically by the x86 platform layer? >> Yes, I think so. Haven't looked to closely at this either. > > This sounds a bit odd. If that were the case, the natural place would be > the PAT tracking code, but it only handles caching flags AFAICT. Not > encryption flags. > > But when you tested AMD with SEV, was that running as hypervisor rather > than a guest, or did you run an SEV guest with PCI passthrough to the > AMD device? Yeah, well the problem is we never tested this ourself :) > >> /Thomas >>> And, as a follow up question, why do we need dma_alloc_coherent() when >>> using SME? I thought the hardware performs the decryption when DMA-ing >>> to / from an encrypted page with SME, but not with SEV? >> I think the issue was that the DMA API would try to use a bounce buffer >> in this case. > > SEV forces SWIOTLB bouncing on, but not SME. So it should probably be > possible to avoid dma_alloc_coherent() in the SME case. In this case I don't have an explanation for this. For the background what happened is that we got reports that SVE/SME doesn't work with amdgpu. So we told the people to try using the dma_alloc_coherent() path and that worked fine. Because of this we came up with the patch I noted earlier. I can confirm that it indeed works now for a couple of users, but we still don't have a test system for this in our team. Christian. > > /Thomas > > >> >> Christian. >> >>> Thanks, Thomas >>> >>> >>> > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 0/8] drm/fb-helper: Move modesetting code to drm_client
On Thu, May 23, 2019 at 06:53:20PM +0200, Sam Ravnborg wrote: > Hi Linus, Gerd. > > > This moves the modesetting code from drm_fb_helper to drm_client so it > > can be shared by all internal clients. > > Could one of you take a look at this series. > Daniel already ack'ed the series on irc, but an extra pair of eyes > is never bad. > > For my part I have been through them all, but I still do not have > the full picture of the DRM subsystem so my review may not > suffice. Looks sane to me overall. Tried to give the series a spin in qemu, but: ERROR: "drm_client_panel_rotation" [drivers/gpu/drm/drm_kms_helper.ko] undefined! EXPORT_SYMBOL() missing? cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/komeda: Added AFBC support for komeda driver
On Fri, May 24, 2019 at 11:10:09AM +, Brian Starkey wrote:
> Hi,
>
> On Tue, May 21, 2019 at 09:45:58AM +0100, james qian wang (Arm Technology
> China) wrote:
> > On Thu, May 16, 2019 at 09:57:49PM +0800, Ayan Halder wrote:
> > > On Thu, Apr 04, 2019 at 12:06:14PM +0100, james qian wang (Arm Technology
> > > China) wrote:
> > > >
> > > > +static int
> > > > +komeda_fb_afbc_size_check(struct komeda_fb *kfb, struct drm_file *file,
> > > > + const struct drm_mode_fb_cmd2 *mode_cmd)
> > > > +{
> > > > + struct drm_framebuffer *fb = &kfb->base;
> > > > + const struct drm_format_info *info = fb->format;
> > > > + struct drm_gem_object *obj;
> > > > + u32 alignment_w = 0, alignment_h = 0, alignment_header;
> > > > + u32 n_blocks = 0, min_size = 0;
> > > > +
> > > > + obj = drm_gem_object_lookup(file, mode_cmd->handles[0]);
> > > > + if (!obj) {
> > > > + DRM_DEBUG_KMS("Failed to lookup GEM object\n");
> > > > + return -ENOENT;
> > > > + }
> > > > +
> > > > + switch (fb->modifier & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) {
> > > > + case AFBC_FORMAT_MOD_BLOCK_SIZE_32x8:
> > > > + alignment_w = 32;
> > > > + alignment_h = 8;
> > > > + break;
> > > > + case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16:
> > > > + alignment_w = 16;
> > > > + alignment_h = 16;
> > > > + break;
> > > > + default:
> > > Can we have something like a warn here ?
> >
> > will add a WARN here.
> >
>
> I think it's better not to. fb->modifier comes from
> userspace, so a malicious app could spam us with WARNs, effectively
> dos-ing the system. -EINVAL should be sufficient.
Should probably check that the entire modifier+format is
actually valid. Otherwise you risk passing on a bogus
modifier deeper into the driver which may trigger
interesting bugs.
Also theoretically (however unlikely) some broken userspace
might start to depend on the ability to create framebuffers
with crap modifiers, which could later break if you change
the way you handle the modifiers. Then you're stuck between
the rock and hard place because you can't break existing
userspace but you still want to change the way modifiers
are handled in the kernel.
Best not give userspace too much rope IMO. Two ways to go about
that:
1) drm_any_plane_has_format() (assumes your .format_mod_supported()
does its job properly)
2) roll your own
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/6] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
On Thu, May 23, 2019 at 07:48:03AM -0700, Vasily Khoruzhick wrote:
> On Wed, May 22, 2019 at 11:54 PM Torsten Duwe wrote:
> >
> >
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> > @@ -65,6 +65,21 @@
> > };
> > };
> >
> > + panel: panel {
> > + compatible ="innolux,n116bge", "simple-panel";
>
> IIRC Rob wanted it to be edp-connector, not simple-panel. Also you
> need to introduce edp-connector binding.
This line is identically found in
arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi and
arch/arm64/boot/dts/nvidia/tegra132-norrin.dts
> > + status = "okay";
> > + power-supply = <®_dcdc1>;
> > + backlight = <&backlight>;
> > +
> > + ports {
> > + panel_in: port {
> > + panel_in_edp: endpoint {
> > + remote-endpoint = <&anx6345_out>;
> > + };
> > + };
> > + };
The whole node is the same as in rk3288-veyron-chromebook.dtsi; I only adapted
the power-supply and remote-endpoint properties.
Is there anything wrong with that?
Torsten
Re: [PATCH 4/5] drm/vmwgfx: remove custom ioctl io encoding check
On 2019/05/23, Thomas Hellstrom wrote: > Hi, Emil, > > On Wed, 2019-05-22 at 17:41 +0100, Emil Velikov wrote: > > From: Emil Velikov > > > > Drop the custom ioctl io encoding check - core drm does it for us. > > I fail to see where the core does this, or do I miss something? drm_ioctl() allows for the encoding to be changed and attributes that only the appropriate size is copied in/out of the kernel. Technically the function is more relaxed relative to the vmwgfx check, yet seems perfectly reasonable. Is there any corner-case that isn't but should be handled in drm_ioctl()? -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 2/2] phy: Add driver for mixel mipi dphy found on NXP's i.MX8 SoCs
Hi Kishon, On Sun, May 12, 2019 at 7:49 AM Guido Günther wrote: > > This adds support for the Mixel DPHY as found on i.MX8 CPUs but since > this is an IP core it will likely be found on others in the future. So > instead of adding this to the nwl host driver make it a generic PHY > driver. > > The driver supports the i.MX8MQ. Support for i.MX8QM and i.MX8QXP can be > added once the necessary system controller bits are in via > mixel_dphy_devdata. > > Signed-off-by: Guido Günther > Co-developed-by: Robert Chiras > Signed-off-by: Robert Chiras > Reviewed-by: Fabio Estevam > Reviewed-by: Sam Ravnborg Would you have any comments on this series, please? Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #23 from Sylvain BERTRAND --- It seems I get the same freezes than you. It takes hours of gaming to get some random hard hang (no log). I thought I was overheating, but realized that my system is on "vacation" while playing. linux amd-staging-drm-new/x11 native/mesa/llvm(erk...), all git no older than a week. playing mostly dota2 vulkan on AMD TAHITI XT -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
It seems I get the same freezes than you. It takes hours of gaming to get some random hard hang (no log). I thought I was overheating, but realized that my system is on "vacation" while playing. linux amd-staging-drm-new/x11 native/mesa/llvm(erk...), all git no older than a week. playing mostly dota2 vulkan on AMD TAHITI XT ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/ttm, drm/vmwgfx: Have TTM support AMD SEV encryption
On 5/24/19 2:03 PM, Koenig, Christian wrote: Am 24.05.19 um 12:37 schrieb Thomas Hellstrom: [CAUTION: External Email] On 5/24/19 12:18 PM, Koenig, Christian wrote: Am 24.05.19 um 11:55 schrieb Thomas Hellstrom: [CAUTION: External Email] On 5/24/19 11:11 AM, Thomas Hellstrom wrote: Hi, Christian, On 5/24/19 10:37 AM, Koenig, Christian wrote: Am 24.05.19 um 10:11 schrieb Thomas Hellström (VMware): [CAUTION: External Email] From: Thomas Hellstrom With SEV encryption, all DMA memory must be marked decrypted (AKA "shared") for devices to be able to read it. In the future we might want to be able to switch normal (encrypted) memory to decrypted in exactly the same way as we handle caching states, and that would require additional memory pools. But for now, rely on memory allocated with dma_alloc_coherent() which is already decrypted with SEV enabled. Set up the page protection accordingly. Drivers must detect SEV enabled and switch to the dma page pool. This patch has not yet been tested. As a follow-up, we might want to cache decrypted pages in the dma page pool regardless of their caching state. This patch is unnecessary, SEV support already works fine with at least amdgpu and I would expect that it also works with other drivers as well. Also see this patch: commit 64e1f830ea5b3516a4256ed1c504a265d7f2a65c Author: Christian König Date: Wed Mar 13 10:11:19 2019 +0100 drm: fallback to dma_alloc_coherent when memory encryption is active We can't just map any randome page we get when memory encryption is active. Signed-off-by: Christian König Acked-by: Alex Deucher Link: https://patchwork.kernel.org/patch/10850833/ Regards, Christian. Yes, I noticed that. Although I fail to see where we automagically clear the PTE encrypted bit when mapping coherent memory? For the linear kernel map, that's done within dma_alloc_coherent() but for kernel vmaps and and user-space maps? Is that done automatically by the x86 platform layer? Yes, I think so. Haven't looked to closely at this either. This sounds a bit odd. If that were the case, the natural place would be the PAT tracking code, but it only handles caching flags AFAICT. Not encryption flags. But when you tested AMD with SEV, was that running as hypervisor rather than a guest, or did you run an SEV guest with PCI passthrough to the AMD device? Yeah, well the problem is we never tested this ourself :) /Thomas And, as a follow up question, why do we need dma_alloc_coherent() when using SME? I thought the hardware performs the decryption when DMA-ing to / from an encrypted page with SME, but not with SEV? I think the issue was that the DMA API would try to use a bounce buffer in this case. SEV forces SWIOTLB bouncing on, but not SME. So it should probably be possible to avoid dma_alloc_coherent() in the SME case. In this case I don't have an explanation for this. For the background what happened is that we got reports that SVE/SME doesn't work with amdgpu. So we told the people to try using the dma_alloc_coherent() path and that worked fine. Because of this we came up with the patch I noted earlier. I can confirm that it indeed works now for a couple of users, but we still don't have a test system for this in our team. Christian. OK, undestood, But unless there is some strange magic going on, (which there might be of course),I do think the patch I sent is correct, and the reason that SEV works is that the AMD card is used by the hypervisor and not the guest, and TTM is actually incorrectly creating conflicting maps and treating the coherent memory as encrypted. But since the memory is only accessed through encrypted PTEs, the hardware does the right thing, using the hypervisor key for decryption But that's only a guess, and this is not super-urgent. I will be able to follow up if / when we bring vmwgfx up for SEV. /Thomas /Thomas Christian. Thanks, Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/vmwgfx: fix a warning due to missing dma_parms
Booting up with DMA_API_DEBUG_SG=y generates a warning due to the driver
forgot to set dma_parms appropriately. Set it just after vmw_dma_masks()
in vmw_driver_load().
DMA-API: vmwgfx :00:0f.0: mapping sg segment longer than device
claims to support [len=2097152] [max=65536]
WARNING: CPU: 2 PID: 261 at kernel/dma/debug.c:1232
debug_dma_map_sg+0x360/0x480
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop
Reference Platform, BIOS 6.00 04/13/2018
RIP: 0010:debug_dma_map_sg+0x360/0x480
Call Trace:
vmw_ttm_map_dma+0x3b1/0x5b0 [vmwgfx]
vmw_bo_map_dma+0x25/0x30 [vmwgfx]
vmw_otables_setup+0x2a8/0x750 [vmwgfx]
vmw_request_device_late+0x78/0xc0 [vmwgfx]
vmw_request_device+0xee/0x4e0 [vmwgfx]
vmw_driver_load.cold+0x757/0xd84 [vmwgfx]
drm_dev_register+0x1ff/0x340 [drm]
drm_get_pci_dev+0x110/0x290 [drm]
vmw_probe+0x15/0x20 [vmwgfx]
local_pci_probe+0x7a/0xc0
pci_device_probe+0x1b9/0x290
really_probe+0x1b5/0x630
driver_probe_device+0xa3/0x1a0
device_driver_attach+0x94/0xa0
__driver_attach+0xdd/0x1c0
bus_for_each_dev+0xfe/0x150
driver_attach+0x2d/0x40
bus_add_driver+0x290/0x350
driver_register+0xdc/0x1d0
__pci_register_driver+0xda/0xf0
vmwgfx_init+0x34/0x1000 [vmwgfx]
do_one_initcall+0xe5/0x40a
do_init_module+0x10f/0x3a0
load_module+0x16a5/0x1a40
__se_sys_finit_module+0x183/0x1c0
__x64_sys_finit_module+0x43/0x50
do_syscall_64+0xc8/0x606
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes: fb1d9738ca05 ("drm/vmwgfx: Add DRM driver for VMware Virtual GPU")
Signed-off-by: Qian Cai
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index bf6c3500d363..e10fe109ee48 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -747,6 +747,8 @@ static int vmw_driver_load(struct drm_device *dev, unsigned
long chipset)
if (unlikely(ret != 0))
goto out_err0;
+ dma_set_max_seg_size(dev->dev, U32_MAX);
+
if (dev_priv->capabilities & SVGA_CAP_GMR2) {
DRM_INFO("Max GMR ids is %u\n",
(unsigned)dev_priv->max_gmr_ids);
--
2.20.1 (Apple Git-117)
RFC: Run a dedicated hmm.git for 5.3
On Thu, May 23, 2019 at 11:40:51PM -0700, Christoph Hellwig wrote: > On Thu, May 23, 2019 at 04:10:38PM -0300, Jason Gunthorpe wrote: > > > > On Thu, May 23, 2019 at 02:24:58PM -0400, Jerome Glisse wrote: > > > I can not take mmap_sem in range_register, the READ_ONCE is fine and > > > they are no race as we do take a reference on the hmm struct thus > > > > Of course there are use after free races with a READ_ONCE scheme, I > > shouldn't have to explain this. > > > > If you cannot take the read mmap sem (why not?), then please use my > > version and push the update to the driver through -mm.. > > I think it would really help if we queue up these changes in a git tree > that can be pulled into the driver trees. Given that you've been > doing so much work to actually make it usable I'd nominate rdma for the > "lead" tree. Sure, I'm willing to do that. RDMA has experience successfully running shared git trees with netdev. It can work very well, but requires discipline and understanding of the limitations. I really want to see the complete HMM solution from Jerome (ie the kconfig fixes, arm64, api fixes, etc) in one cohesive view, not forced to be sprinkled across multiple kernel releases to work around a submission process/coordination problem. Now that -mm merged the basic hmm API skeleton I think running like this would get us quickly to the place we all want: comprehensive in tree users of hmm. Andrew, would this be acceptable to you? Dave, would you be willing to merge a clean HMM tree into DRM if it is required for DRM driver work in 5.3? I'm fine to merge a tree like this for RDMA, we already do this pattern with netdev. Background: The issue that is motivating this is we want to make changes to some of the API's for hmm, which mean changes in existing DRM, changes in to-be-accepted RDMA code, and to-be-accepted DRM driver code. Coordintating the mm/hmm.c, RDMA and DRM changes is best done with the proven shared git tree pattern. As CH explains I would run a clean/minimal hmm tree that can be merged into driver trees as required, and I will commit to sending a PR to Linus for this tree very early in the merge window so that driver PR's are 'clean'. The tree will only contain uncontroversial hmm related commits, bug fixes, etc. Obviouisly I will also commit to providing review for patches flowing through this tree. Regards, Jason (rdma subsystem co-maintainer, FWIW)
Re: [PATCH v3 2/3] media: uapi: Add RGB bus formats for the GiantPlus GPM940B0 panel
Em Mon, 22 Apr 2019 11:37:21 +0200 Paul Cercueil escreveu: > The GiantPlus GPM940B0 is a 24-bit TFT panel where the RGB components > are transferred sequentially on a 8-bit bus. > > Signed-off-by: Paul Cercueil > --- > > Notes: > v2: New patch > > v3: No change > > include/uapi/linux/media-bus-format.h | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/include/uapi/linux/media-bus-format.h > b/include/uapi/linux/media-bus-format.h > index d6a5a3bfe6c4..f31724d6cd40 100644 > --- a/include/uapi/linux/media-bus-format.h > +++ b/include/uapi/linux/media-bus-format.h > @@ -34,7 +34,7 @@ > > #define MEDIA_BUS_FMT_FIXED 0x0001 > > -/* RGB - next is 0x101b */ > +/* RGB - next is 0x101d */ > #define MEDIA_BUS_FMT_RGB444_1X120x1016 > #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE0x1001 > #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE0x1002 > @@ -54,6 +54,8 @@ > #define MEDIA_BUS_FMT_RGB888_1X240x100a > #define MEDIA_BUS_FMT_RGB888_2X12_BE 0x100b > #define MEDIA_BUS_FMT_RGB888_2X12_LE 0x100c > +#define MEDIA_BUS_FMT_RGB888_3X8_BE 0x101b > +#define MEDIA_BUS_FMT_RGB888_3X8_LE 0x101c > #define MEDIA_BUS_FMT_RGB888_1X7X4_SPWG 0x1011 > #define MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA 0x1012 > #define MEDIA_BUS_FMT_ARGB_1X32 0x100d You should also patch the documentation text at: Documentation/media/uapi/v4l/subdev-formats.rst In order to describe the new formats that will be included. (also patch needs to be rebased, as it conflicts to some other new formats added there) Thanks, Mauro
[PATCH v2 1/2] drm: panel-orientation-quirks: Add quirk for GPD pocket2
GPD has done it again, make a nice device (good), use way too generic
DMI strings (bad) and use a portrait screen rotated 90 degrees (ugly).
Because of the too generic DMI strings this entry is also doing bios-date
matching, so the gpd_pocket2 data struct may very well need to be updated
with some extra bios-dates in the future.
Changes in v2:
-Add one more known BIOS date to the list of BIOS dates
Cc: Jurgen Kramer
Reported-by: Jurgen Kramer
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 521aff99b08a..98679c831f66 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -50,6 +50,14 @@ static const struct drm_dmi_panel_orientation_data
gpd_pocket = {
.orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
};
+static const struct drm_dmi_panel_orientation_data gpd_pocket2 = {
+ .width = 1200,
+ .height = 1920,
+ .bios_dates = (const char * const []){ "06/28/2018", "08/28/2018",
+ "12/07/2018", NULL },
+ .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
+};
+
static const struct drm_dmi_panel_orientation_data gpd_win = {
.width = 720,
.height = 1280,
@@ -112,6 +120,14 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Default string"),
},
.driver_data = (void *)&gpd_pocket,
+ }, {/* GPD Pocket 2 (generic strings, also match on bios date) */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Default string"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Default string"),
+ DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "Default string"),
+ DMI_EXACT_MATCH(DMI_BOARD_NAME, "Default string"),
+ },
+ .driver_data = (void *)&gpd_pocket2,
}, {/* GPD Win (same note on DMI match as GPD Pocket) */
.matches = {
DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"),
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm: panel-orientation-quirks: Add quirk for GPD MicroPC
GPD has done it again, make a nice device (good), use way too generic
DMI strings (bad) and use a portrait screen rotated 90 degrees (ugly).
Because of the too generic DMI strings this entry is also doing bios-date
matching, so the gpd_micropc data struct may very well need to be updated
with some extra bios-dates in the future.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 98679c831f66..d8a0bcd02f34 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -42,6 +42,14 @@ static const struct drm_dmi_panel_orientation_data
asus_t100ha = {
.orientation = DRM_MODE_PANEL_ORIENTATION_LEFT_UP,
};
+static const struct drm_dmi_panel_orientation_data gpd_micropc = {
+ .width = 720,
+ .height = 1280,
+ .bios_dates = (const char * const []){ "04/26/2019",
+ NULL },
+ .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
+};
+
static const struct drm_dmi_panel_orientation_data gpd_pocket = {
.width = 1200,
.height = 1920,
@@ -107,6 +115,14 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100HAN"),
},
.driver_data = (void *)&asus_t100ha,
+ }, {/* GPD MicroPC (generic strings, also match on bios date) */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Default string"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Default string"),
+ DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "Default string"),
+ DMI_EXACT_MATCH(DMI_BOARD_NAME, "Default string"),
+ },
+ .driver_data = (void *)&gpd_micropc,
}, {/*
* GPD Pocket, note that the the DMI data is less generic then
* it seems, devices with a board-vendor of "AMI Corporation"
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] drm/vmwgfx: remove custom ioctl io encoding check
On Fri, 2019-05-24 at 13:14 +0100, Emil Velikov wrote: > On 2019/05/23, Thomas Hellstrom wrote: > > Hi, Emil, > > > > On Wed, 2019-05-22 at 17:41 +0100, Emil Velikov wrote: > > > From: Emil Velikov > > > > > > Drop the custom ioctl io encoding check - core drm does it for > > > us. > > > > I fail to see where the core does this, or do I miss something? > > drm_ioctl() allows for the encoding to be changed and attributes that > only the > appropriate size is copied in/out of the kernel. > > Technically the function is more relaxed relative to the vmwgfx > check, yet > seems perfectly reasonable. > > Is there any corner-case that isn't but should be handled in > drm_ioctl()? I'd like to turn the question around and ask whether there's a reason we should relax the vmwgfx test? In the past it has trapped quite a few user-space errors. Thanks, Thomas > > -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
