Re: [PATCH v3] of_device: removed #include that caused a recursion in included headers
Hi Hadar,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on sparc/master]
[also build test ERROR on stm32/stm32-next linus/master v5.7-rc2 next-20200422]
[cannot apply to sparc-next/master]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Hadar-Gat/of_device-removed-include-that-caused-a-recursion-in-included-headers/20200423-040844
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git master
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day GCC_VERSION=9.3.0 make.cross
ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/firmware/ti_sci.c: In function 'ti_sci_probe':
>> drivers/firmware/ti_sci.c:3520:9: error: implicit declaration of function
>> 'of_platform_populate' [-Werror=implicit-function-declaration]
3520 | return of_platform_populate(dev->of_node, NULL, NULL, dev);
| ^~~~
drivers/firmware/ti_sci.c: In function 'ti_sci_remove':
>> drivers/firmware/ti_sci.c:3536:2: error: implicit declaration of function
>> 'of_platform_depopulate' [-Werror=implicit-function-declaration]
3536 | of_platform_depopulate(dev);
| ^~
cc1: some warnings being treated as errors
--
drivers/firmware/tegra/bpmp.c: In function 'tegra_bpmp_get':
>> drivers/firmware/tegra/bpmp.c:51:9: error: implicit declaration of function
>> 'of_find_device_by_node'; did you mean 'bus_find_device_by_fwnode'?
>> [-Werror=implicit-function-declaration]
51 | pdev = of_find_device_by_node(np);
| ^~
| bus_find_device_by_fwnode
drivers/firmware/tegra/bpmp.c:51:7: warning: assignment to 'struct
platform_device *' from 'int' makes pointer from integer without a cast
[-Wint-conversion]
51 | pdev = of_find_device_by_node(np);
| ^
drivers/firmware/tegra/bpmp.c: In function 'tegra_bpmp_probe':
>> drivers/firmware/tegra/bpmp.c:759:8: error: implicit declaration of function
>> 'of_platform_default_populate' [-Werror=implicit-function-declaration]
759 | err = of_platform_default_populate(pdev->dev.of_node, NULL,
&pdev->dev);
|^~~~
cc1: some warnings being treated as errors
--
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c: In function
'sun8i_dw_hdmi_find_connector_pdev':
>> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c:115:9: error: implicit declaration of
>> function 'of_find_device_by_node'; did you mean
>> 'of_find_i2c_device_by_node'? [-Werror=implicit-function-declaration]
115 | pdev = of_find_device_by_node(remote);
| ^~
| of_find_i2c_device_by_node
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c:115:7: warning: assignment to 'struct
platform_device *' from 'int' makes pointer from integer without a cast
[-Wint-conversion]
115 | pdev = of_find_device_by_node(remote);
| ^
cc1: some warnings being treated as errors
vim +/of_platform_populate +3520 drivers/firmware/ti_sci.c
aa276781a64a5f Nishanth Menon 2016-10-18 3385
aa276781a64a5f Nishanth Menon 2016-10-18 3386 static int ti_sci_probe(struct
platform_device *pdev)
aa276781a64a5f Nishanth Menon 2016-10-18 3387 {
aa276781a64a5f Nishanth Menon 2016-10-18 3388 struct device *dev =
&pdev->dev;
aa276781a64a5f Nishanth Menon 2016-10-18 3389 const struct
of_device_id *of_id;
aa276781a64a5f Nishanth Menon 2016-10-18 3390 const struct
ti_sci_desc *desc;
aa276781a64a5f Nishanth Menon 2016-10-18 3391 struct ti_sci_xfer
*xfer;
aa276781a64a5f Nishanth Menon 2016-10-18 3392 struct ti_sci_info
*info = NULL;
aa276781a64a5f Nishanth Menon 2016-10-18 3393 struct
ti_sci_xfers_info *minfo;
aa276781a64a5f Nishanth Menon 2016-10-18 3394 struct mbox_client *cl;
aa276781a64a5f Nishanth Menon 2016-10-18 3395 int ret = -EINVAL;
aa276781a64a5f Nishanth Menon 2016-10-18 3396 int i;
912cffb4ed8612 Nishanth Menon 2016-10-18 3397 int reboot = 0;
e69a35531589a2 Nishanth Menon 2018-08-28 3398
Re: Rule for bridge yaml dt binding maintainers?
Hi Joe.
> >
> > > I would also be great if you or someone else could:
> > > - teach get_maintainers about .yaml file listed maintainers
> >
> > It already does to some extent. IIRC, there's a mode to extract email
> > addresses from files.
>
> --file-emails
>
> > I was hoping that the MAINTAINERS file split happens sometime and we
> > can just generate a MAINTAINERS file for bindings.
>
> I don't see the value really.
>
> > > - teach checkpatch that it is OK to convert .txt to .yaml
>
> I suppose that get_maintainer _could_ enable --file-emails
> for .yaml files.
>
> something like this (more comments below too)
> ---
> scripts/get_maintainer.pl | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
> index 6cbcd1..9d947a0 100755
> --- a/scripts/get_maintainer.pl
> +++ b/scripts/get_maintainer.pl
> @@ -527,7 +527,7 @@ foreach my $file (@ARGV) {
> $file =~ s/^\Q${cur_path}\E//; #strip any absolute path
> $file =~ s/^\Q${lk_path}\E//; #or the path to the lk tree
> push(@files, $file);
> - if ($file ne "MAINTAINERS" && -f $file && ($keywords || $file_emails)) {
> + if ($file ne "MAINTAINERS" && -f $file && ($keywords || $file_emails ||
> $file =~ /\.yaml$/)) {
> open(my $f, '<', $file)
> or die "$P: Can't open $file: $!\n";
> my $text = do { local($/) ; <$f> };
> @@ -539,7 +539,7 @@ foreach my $file (@ARGV) {
> }
> }
> }
> - if ($file_emails) {
> + if ($file_emails || $file =~ /\.yaml$/) {
> my @poss_addr = $text =~ m$[A-Za-zÀ-ÿ\"\'
> \,\.\+-]*\s*[\,]*\s*[\(\<\{]{0,1}[A-Za-z0-9_\.\+-]+\@[A-Za-z0-9\.-]+\.[A-Za-z0-9]+[\)\>\}]{0,1}$g;
> push(@file_emails, clean_file_emails(@poss_addr));
> }
>
That would be a good step forward. So people editing yaml file
will actually copy the maintainers and not just Rob as it is today.
There is a growing tendency to rely on tools only for the
list of people on cc, which is fine, but we should make those tools
then do a good job.
Thanks for looking into this.
Patch is:
Acked-by: Sam Ravnborg
> > I don't see checkpatch being able to check much of what comes up in
> > review. Maybe indentation.
>
> Likely better done with another external tool.
>
> Could be added to checkpatch as an external
> call like spdxcheck.py
If we grow anything more than:
"Indent shall always be an even number of spaces and no tabs" kind of
rules then yes, an external tool would be fine.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206987] [drm] [amdgpu] Whole system crashes when the driver is in mode_support_and_system_configuration
https://bugzilla.kernel.org/show_bug.cgi?id=206987 Cyrax (ev...@hotmail.com) changed: What|Removed |Added Kernel Version|5.6.4 |5.6.5 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206987] [drm] [amdgpu] Whole system crashes when the driver is in mode_support_and_system_configuration
https://bugzilla.kernel.org/show_bug.cgi?id=206987 --- Comment #9 from Cyrax (ev...@hotmail.com) --- Created attachment 288679 --> https://bugzilla.kernel.org/attachment.cgi?id=288679&action=edit dmesg output And again. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207383] [Regression] 5.7-rc: amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #3 from Duncan (1i5t5.dun...@cox.net) --- CCed the two from MAINTAINERS bugzi would let me add. It wouldn't let me add amd-gfx@ or david1.zhou@, and Alex's gmail address according to bugzi isn't what's in MAINTAINERS. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree
Hi all,
On Tue, 21 Apr 2020 09:10:25 +0300 Tomi Valkeinen wrote:
>
> On 21/04/2020 04:52, Stephen Rothwell wrote:
> >
> > Today's linux-next merge of the drm-misc tree got a conflict in:he drm-misc
> > tree with the drm-misc-fixes tree
> >
> >drivers/gpu/drm/tidss/tidss_encoder.c
> >
> > between commit:
> >
> >9da67433f64e ("drm/tidss: fix crash related to accessing freed memory")
> >
> > from the drm-misc-fixes tree and commit:
> >
> >b28ad7deb2f2 ("drm/tidss: Use simple encoder")
> >
> > from the drm-misc tree.
> >
> > I fixed it up (I just used the latter version of this file) and can
>
> We need to use "drm/tidss: fix crash related to accessing freed memory"
> version.
>
> > 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 have fixed this with drm-misc's dim tool, so I presume the conflict goes
> away when drm-misc-fixes
> is merged to drm-fixes, and drm-fixes is then at some point merged to
> drm-misc-next.
>
> It was a bit bad timing with the "drm/tidss: Use simple encoder", which
> removes the plumbing I
> needed to implement the fix. So I effectively revert the "drm/tidss: Use
> simple encoder".
>
> Tomi
>
This is now a conflict between the drm and drm-misc-fixes trees.
--
Cheers,
Stephen Rothwell
pgpXMBKWZRlXW.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: manual merge of the amdgpu tree with the drm tree
Hi all,
Today's linux-next merge of the amdgpu tree got a conflict in:
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
between commit:
09b974e8983a ("drm/amd/amdgpu_dm/mst: Remove ->destroy_connector() callback")
from the drm tree and commit:
c33f212c0c92 ("drm/amdgpu/display: create fake mst encoders ahead of time")
from the amdgpu tree.
I fixed it up (see 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.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 3db1ec35d2b4,4f0072a9396b..
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@@ -136,23 -93,14 +93,20 @@@ static ssize_t dm_dp_aux_transfer(struc
static void
dm_dp_mst_connector_destroy(struct drm_connector *connector)
{
- struct amdgpu_dm_connector *amdgpu_dm_connector =
to_amdgpu_dm_connector(connector);
+ struct amdgpu_dm_connector *aconnector =
+ to_amdgpu_dm_connector(connector);
- struct amdgpu_encoder *amdgpu_encoder = aconnector->mst_encoder;
+
+ if (aconnector->dc_sink) {
+ dc_link_remove_remote_sink(aconnector->dc_link,
+ aconnector->dc_sink);
+ dc_sink_release(aconnector->dc_sink);
+ }
- kfree(amdgpu_dm_connector->edid);
- amdgpu_dm_connector->edid = NULL;
+ kfree(aconnector->edid);
- drm_encoder_cleanup(&amdgpu_encoder->base);
- kfree(amdgpu_encoder);
drm_connector_cleanup(connector);
- drm_dp_mst_put_port_malloc(amdgpu_dm_connector->port);
- kfree(amdgpu_dm_connector);
+ drm_dp_mst_put_port_malloc(aconnector->port);
+ kfree(aconnector);
}
static int
@@@ -412,10 -358,11 +364,19 @@@ dm_dp_add_mst_connector(struct drm_dp_m
master->dc_link,
master->connector_id);
- aconnector->mst_encoder = dm_dp_create_fake_mst_encoder(master);
- drm_connector_attach_encoder(&aconnector->base,
-&aconnector->mst_encoder->base);
+ for (i = 0; i < AMDGPU_DM_MAX_CRTC; i++) {
+ drm_connector_attach_encoder(&aconnector->base,
+&aconnector->mst_encoders[i].base);
+ }
+
++ connector->max_bpc_property = master->base.max_bpc_property;
++ if (connector->max_bpc_property)
++ drm_connector_attach_max_bpc_property(connector, 8, 16);
++
++ connector->vrr_capable_property = master->base.vrr_capable_property;
++ if (connector->vrr_capable_property)
++ drm_connector_attach_vrr_capable_property(connector);
+
connector->max_bpc_property = master->base.max_bpc_property;
if (connector->max_bpc_property)
drm_connector_attach_max_bpc_property(connector, 8, 16);
pgpxqbXeEhu2l.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Rule for bridge yaml dt binding maintainers?
On Wed, 2020-04-22 at 15:02 -0500, Rob Herring wrote:
> On Mon, Apr 20, 2020 at 12:59 PM Sam Ravnborg wrote:
> > Hi Adrian
> >
> > On Mon, Apr 20, 2020 at 02:19:24PM +0300, Adrian Ratiu wrote:
> > > Hello,
> > >
> > > I got confused while doing the txt -> yaml conversion at [1] and it's
> > > still
> > > not clear to me who should be added in the "maintainers" field. Clearly
> > > not
> > > the maintainers as returned by get_maintainer.pl. :)
> > >
> > > Rob mentioned that "owners" should be manintainers but I also have trouble
> > > picking the persons who should be owners / yaml maintainers.
> > >
> > > Looking at the completed bridge conversions in the latest linux-next, I
> > > couldn't find a rule and the majority of bindings are still txt:
> > >
> > > $ find ./devicetree/bindings/display/bridge/ -name *txt | wc -l
> > > 23
> > > $ find ./devicetree/bindings/display/bridge/ -name *yaml | wc -l
> > > 5
> > >
> > > So my questions are:
> > > 1. Is there a general rule for assigning yaml file owners/maintainers?
> > >
> > > 2. Is this vagueness specific to the bridge dt bindings only?
> > >
> > > 3. Who should step up and maintain these bindings? Original/new authors,
> > > SoC, bridge, DRM maintainers etc.?
> > >
> > > It would be useful to have a rule to make it easier to do these
> > > conversions.
> > > We (Collabora) are considering doing the conversion work.
> >
> > For the panel conversion I did recently it was simple:
> > 1) If listed in MAINTAINERS - use this info
> > 2) Otherwise use the person(s) that authored the original .txt file.
> >Using git log --follow foo.txt
> > 3) In a few cases I may have decided otherwise, but the above covers the
> >majority.
>
> Yes.
>
> > I would also be great if you or someone else could:
> > - teach get_maintainers about .yaml file listed maintainers
>
> It already does to some extent. IIRC, there's a mode to extract email
> addresses from files.
--file-emails
> I was hoping that the MAINTAINERS file split happens sometime and we
> can just generate a MAINTAINERS file for bindings.
I don't see the value really.
> > - teach checkpatch that it is OK to convert .txt to .yaml
I suppose that get_maintainer _could_ enable --file-emails
for .yaml files.
something like this (more comments below too)
---
scripts/get_maintainer.pl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index 6cbcd1..9d947a0 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -527,7 +527,7 @@ foreach my $file (@ARGV) {
$file =~ s/^\Q${cur_path}\E//; #strip any absolute path
$file =~ s/^\Q${lk_path}\E//; #or the path to the lk tree
push(@files, $file);
- if ($file ne "MAINTAINERS" && -f $file && ($keywords || $file_emails)) {
+ if ($file ne "MAINTAINERS" && -f $file && ($keywords || $file_emails ||
$file =~ /\.yaml$/)) {
open(my $f, '<', $file)
or die "$P: Can't open $file: $!\n";
my $text = do { local($/) ; <$f> };
@@ -539,7 +539,7 @@ foreach my $file (@ARGV) {
}
}
}
- if ($file_emails) {
+ if ($file_emails || $file =~ /\.yaml$/) {
my @poss_addr = $text =~ m$[A-Za-zÀ-ÿ\"\'
\,\.\+-]*\s*[\,]*\s*[\(\<\{]{0,1}[A-Za-z0-9_\.\+-]+\@[A-Za-z0-9\.-]+\.[A-Za-z0-9]+[\)\>\}]{0,1}$g;
push(@file_emails, clean_file_emails(@poss_addr));
}
---
> Yeah, I should fix my bug.
>
> > - teach checkpatch about some simple yaml validation (maybe)
>
> I don't see checkpatch being able to check much of what comes up in
> review. Maybe indentation.
Likely better done with another external tool.
Could be added to checkpatch as an external
call like spdxcheck.py
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu drm-fixes-5.7
Hi Dave, Daniel, Fixes for 5.7. The following changes since commit 4da858c086433cd012c0bb16b5921f6fafe3f803: Merge branch 'linux-5.7' of git://github.com/skeggsb/linux into drm-fixes (2020-04-16 15:40:02 +1000) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux tags/amd-drm-fixes-5.7-2020-04-22 for you to fetch changes up to 7daec99fdcde7b01595134a3d8f385bc1009f1d8: drm/amdgpu/display: give aux i2c buses more meaningful names (2020-04-17 17:31:38 -0400) amd-drm-fixes-5.7-2020-04-22: amdgpu: - Fix resume issue on renoir - Thermal fix for older CI dGPUs - Fix some fallout from dropping drm load/unload callbacks Alex Deucher (2): drm/amdgpu/display: fix aux registration (v2) drm/amdgpu/display: give aux i2c buses more meaningful names Prike Liang (1): drm/amd/powerplay: fix resume failed as smu table initialize early exit Sandeep Raghuraman (1): drm/amdgpu: Correctly initialize thermal controller for GPUs with Powerplay table v0 (e.g Hawaii) drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 ++-- .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 15 - .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.h| 3 ++- .../gpu/drm/amd/powerplay/hwmgr/processpptables.c | 26 ++ drivers/gpu/drm/amd/powerplay/renoir_ppt.c | 7 +- 5 files changed, 55 insertions(+), 10 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
drm/i915: Teaching i915 dmabuf about LMEM
With the addition of device memory (lmem) for the i915 driver, the dma-buf interface needs a little polishing. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/i915/dmabuf Introduce dmabuf mmap to LMEM
The i915 GEM dmabuf mmap interface assumes all BOs are SHMEM. When
the BO is backed by LMEM, this assumption doesn't work so well.
Introduce the dmabuf mmap interface to LMEM by adding the appropriate
VMA faulting mechanism.
Update dmabuf to allow for LMEM backed BOs by leveraging the gem_mman
path.
Signed-off-by: Michael J. Ruhl
CC: Brian Welty
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 58 --
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 103 ++
drivers/gpu/drm/i915/gem/i915_gem_mman.h | 8 ++
.../drm/i915/gem/selftests/i915_gem_mman.c| 10 +-
4 files changed, 118 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 988778cc8539..72d312d04421 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -11,6 +11,8 @@
#include
#include "i915_drv.h"
+#include "i915_gem_lmem.h"
+#include "i915_gem_mman.h"
#include "i915_gem_object.h"
#include "i915_scatterlist.h"
@@ -169,7 +171,41 @@ static void i915_gem_dmabuf_vunmap(struct dma_buf
*dma_buf, void *vaddr)
i915_gem_object_unpin_map(obj);
}
-static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct
*vma)
+/**
+ * i915_gem_dmabuf_update_vma - Setup VMA information for exported LMEM
+ * objects
+ * @obj: valid LMEM object
+ * @vma: va;od vma
+ *
+ * NOTE: on success, the final _object_put() will be done by the VMA
+ * vm_close() callback.
+ */
+static int i915_gem_dmabuf_update_vma(struct drm_i915_gem_object *obj,
+ struct vm_area_struct *vma)
+{
+ struct i915_mmap_offset *mmo;
+ int err;
+
+ i915_gem_object_get(obj);
+ mmo = i915_gem_mmap_offset_attach(obj, I915_MMAP_TYPE_WC, NULL);
+ if (IS_ERR(mmo)) {
+ err = PTR_ERR(mmo);
+ goto out;
+ }
+
+ err = i915_gem_update_vma_info(mmo, vma);
+ if (err)
+ goto out;
+
+ return 0;
+
+out:
+ i915_gem_object_put(obj);
+ return err;
+}
+
+static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf,
+ struct vm_area_struct *vma)
{
struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
int ret;
@@ -177,17 +213,21 @@ static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf,
struct vm_area_struct *
if (obj->base.size < vma->vm_end - vma->vm_start)
return -EINVAL;
- if (!obj->base.filp)
- return -ENODEV;
+ /* shmem */
+ if (obj->base.filp) {
+ ret = call_mmap(obj->base.filp, vma);
+ if (ret)
+ return ret;
+ fput(vma->vm_file);
+ vma->vm_file = get_file(obj->base.filp);
- ret = call_mmap(obj->base.filp, vma);
- if (ret)
- return ret;
+ return 0;
+ }
- fput(vma->vm_file);
- vma->vm_file = get_file(obj->base.filp);
+ if (i915_gem_object_is_lmem(obj))
+ return i915_gem_dmabuf_update_vma(obj, vma);
- return 0;
+ return -ENODEV;
}
static int i915_gem_begin_cpu_access(struct dma_buf *dma_buf, enum
dma_data_direction direction)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index b39c24dae64e..70b00c41f6d3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -549,10 +549,10 @@ insert_mmo(struct drm_i915_gem_object *obj, struct
i915_mmap_offset *mmo)
return mmo;
}
-static struct i915_mmap_offset *
-mmap_offset_attach(struct drm_i915_gem_object *obj,
- enum i915_mmap_type mmap_type,
- struct drm_file *file)
+struct i915_mmap_offset *
+i915_gem_mmap_offset_attach(struct drm_i915_gem_object *obj,
+ enum i915_mmap_type mmap_type,
+ struct drm_file *file)
{
struct drm_i915_private *i915 = to_i915(obj->base.dev);
struct i915_mmap_offset *mmo;
@@ -626,7 +626,7 @@ __assign_mmap_offset(struct drm_file *file,
goto out;
}
- mmo = mmap_offset_attach(obj, mmap_type, file);
+ mmo = i915_gem_mmap_offset_attach(obj, mmap_type, file);
if (IS_ERR(mmo)) {
err = PTR_ERR(mmo);
goto out;
@@ -795,56 +795,21 @@ static struct file *mmap_singleton(struct
drm_i915_private *i915)
return file;
}
-/*
- * This overcomes the limitation in drm_gem_mmap's assignment of a
- * drm_gem_object as the vma->vm_private_data. Since we need to
- * be able to resolve multiple mmap offsets which could be tied
- * to a single gem object.
- */
-int i915_gem_mmap(struct file *filp, struct vm_area_struct *vma)
+int i915_gem_update_vma_info(struct i915_mmap_offset *mmo,
+struct vm_area_struct *vma)
{
-
[PATCH 4/5] drm/i915/dmabuf: Add LMEM support for cpu access and vmap interfaces
LMEM backed buffer objects do not have struct page information, and
are not WB compatible. Currently the cpu access and vmap interfaces
only support struct page backed objects.
Update the dma-buf interfaces begin/end_cpu_access and vmap/vunmap
to be LMEM aware.
Signed-off-by: Michael J. Ruhl
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 402c989cc23d..988778cc8539 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -155,7 +155,10 @@ static void *i915_gem_dmabuf_vmap(struct dma_buf *dma_buf)
{
struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
- return i915_gem_object_pin_map(obj, I915_MAP_WB);
+ if (i915_gem_object_has_struct_page(obj))
+ return i915_gem_object_pin_map(obj, I915_MAP_WB);
+ else
+ return i915_gem_object_pin_map(obj, I915_MAP_WC);
}
static void i915_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void *vaddr)
@@ -201,7 +204,11 @@ static int i915_gem_begin_cpu_access(struct dma_buf
*dma_buf, enum dma_data_dire
if (err)
goto out;
- err = i915_gem_object_set_to_cpu_domain(obj, write);
+ if (i915_gem_object_has_struct_page(obj))
+ err = i915_gem_object_set_to_cpu_domain(obj, write);
+ else
+ err = i915_gem_object_set_to_wc_domain(obj, write);
+
i915_gem_object_unlock(obj);
out:
@@ -222,7 +229,9 @@ static int i915_gem_end_cpu_access(struct dma_buf *dma_buf,
enum dma_data_direct
if (err)
goto out;
- err = i915_gem_object_set_to_gtt_domain(obj, false);
+ if (i915_gem_object_has_struct_page(obj))
+ err = i915_gem_object_set_to_gtt_domain(obj, false);
+
i915_gem_object_unlock(obj);
out:
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm/i915/dmabuf: Use scatterlist for_each_sg API
Update open coded for loop to use the standard scatterlist
for_each_sg API.
Signed-off-by: Michael J. Ruhl
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 0d9124ad549a..7ea4abb6a896 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include "i915_drv.h"
#include "i915_gem_object.h"
@@ -40,12 +41,10 @@ static struct sg_table *i915_gem_map_dma_buf(struct
dma_buf_attachment *attach,
if (ret)
goto err_free;
- src = obj->mm.pages->sgl;
dst = sgt->sgl;
- for (i = 0; i < obj->mm.pages->nents; i++) {
+ for_each_sg(obj->mm.pages->sgl, src, obj->mm.pages->nents, i) {
sg_set_page(dst, sg_page(src), src->length, 0);
dst = sg_next(dst);
- src = sg_next(src);
}
if (!dma_map_sg_attrs(attach->dev,
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/i915/dmabuf: Add LMEM knowledge to dmabuf map handler
LMEM backed buffer objects do not have struct page information.
Instead the dma_address of the struct sg is used to store the
LMEM address information (relative to the device, this is not
the CPU physical address).
The dmabuf map handler requires pages to do a dma_map_xx.
Add new mapping/unmapping functions, based on the LMEM usage
of the dma_address to allow LMEM backed buffer objects to be
mapped.
Before mapping check the peer2peer distance to verify that P2P
dma can occur.
Signed-off-by: Michael J. Ruhl
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 82 --
1 file changed, 76 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 7ea4abb6a896..402c989cc23d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include "i915_drv.h"
@@ -18,6 +19,67 @@ static struct drm_i915_gem_object *dma_buf_to_obj(struct
dma_buf *buf)
return to_intel_bo(buf->priv);
}
+static void dmabuf_unmap_addr(struct device *dev, struct scatterlist *sgl,
+ int nents, enum dma_data_direction dir)
+{
+ struct scatterlist *sg;
+ int i;
+
+ for_each_sg(sgl, sg, nents, i)
+ dma_unmap_resource(dev, sg_dma_address(sg), sg_dma_len(sg),
+ dir, 0);
+}
+
+/**
+ * dmabuf_map_addr - Update LMEM address to a physical address and map the
+ * resource.
+ * @dev: valid device
+ * @obj: valid i915 GEM object
+ * @sg: scatter list to appy mapping to
+ * @nents: number of entries in the scatter list
+ * @dir: DMA direction
+ *
+ * The dma_address of the scatter list is the LMEM "address". From this the
+ * actual physical address can be determined.
+ *
+ * Return of 0 means error.
+ *
+ */
+static int dmabuf_map_addr(struct device *dev, struct drm_i915_gem_object *obj,
+ struct scatterlist *sgl, int nents,
+ enum dma_data_direction dir)
+{
+ struct scatterlist *sg;
+ phys_addr_t addr;
+ int distance;
+ int i;
+
+ distance = pci_p2pdma_distance_many(obj->base.dev->pdev, &dev, 1,
+ true);
+ if (distance < 0) {
+ pr_info("%s: from: %s to: %s distance: %d\n", __func__,
+ pci_name(obj->base.dev->pdev), dev_name(dev),
+ distance);
+ return 0;
+ }
+
+ for_each_sg(sgl, sg, nents, i) {
+ addr = sg_dma_address(sg) + obj->mm.region->io_start;
+
+ sg->dma_address = dma_map_resource(dev, addr, sg->length, dir,
+ 0);
+ if (dma_mapping_error(dev, sg->dma_address))
+ goto unmap;
+ sg->dma_length = sg->length;
+ }
+
+ return nents;
+
+unmap:
+ dmabuf_unmap_addr(dev, sgl, i, dir);
+ return 0;
+}
+
static struct sg_table *i915_gem_map_dma_buf(struct dma_buf_attachment *attach,
enum dma_data_direction dir)
{
@@ -44,12 +106,17 @@ static struct sg_table *i915_gem_map_dma_buf(struct
dma_buf_attachment *attach,
dst = sgt->sgl;
for_each_sg(obj->mm.pages->sgl, src, obj->mm.pages->nents, i) {
sg_set_page(dst, sg_page(src), src->length, 0);
+ sg_dma_address(dst) = sg_dma_address(src);
dst = sg_next(dst);
}
- if (!dma_map_sg_attrs(attach->dev,
- sgt->sgl, sgt->nents, dir,
- DMA_ATTR_SKIP_CPU_SYNC)) {
+ if (i915_gem_object_has_struct_page(obj))
+ ret = dma_map_sg_attrs(attach->dev, sgt->sgl, sgt->nents, dir,
+ DMA_ATTR_SKIP_CPU_SYNC);
+ else
+ ret = dmabuf_map_addr(attach->dev, obj, sgt->sgl, sgt->nents,
+ dir);
+ if (!ret) {
ret = -ENOMEM;
goto err_free_sg;
}
@@ -72,9 +139,12 @@ static void i915_gem_unmap_dma_buf(struct
dma_buf_attachment *attach,
{
struct drm_i915_gem_object *obj = dma_buf_to_obj(attach->dmabuf);
- dma_unmap_sg_attrs(attach->dev,
- sgt->sgl, sgt->nents, dir,
- DMA_ATTR_SKIP_CPU_SYNC);
+ if (i915_gem_object_has_struct_page(obj))
+ dma_unmap_sg_attrs(attach->dev, sgt->sgl, sgt->nents, dir,
+ DMA_ATTR_SKIP_CPU_SYNC);
+ else
+ dmabuf_unmap_addr(attach->dev, sgt->sgl, sgt->nents, dir);
+
sg_free_table(sgt);
kfree(sgt);
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-d
[PATCH 1/5] drm/i915/dmabuf: dmabuf cleanup
Some minor cleanup of some variables to make upcoming patches
a little easier.
Normalize struct sg_table to sgt.
Normalize struct dma_buf_attachment to attach.
checkpatch issues sizeof(), !NULL updates.
Signed-off-by: Michael J. Ruhl
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 58 +++---
1 file changed, 29 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 7db5a793739d..0d9124ad549a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -17,11 +17,11 @@ static struct drm_i915_gem_object *dma_buf_to_obj(struct
dma_buf *buf)
return to_intel_bo(buf->priv);
}
-static struct sg_table *i915_gem_map_dma_buf(struct dma_buf_attachment
*attachment,
+static struct sg_table *i915_gem_map_dma_buf(struct dma_buf_attachment *attach,
enum dma_data_direction dir)
{
- struct drm_i915_gem_object *obj = dma_buf_to_obj(attachment->dmabuf);
- struct sg_table *st;
+ struct drm_i915_gem_object *obj = dma_buf_to_obj(attach->dmabuf);
+ struct sg_table *sgt;
struct scatterlist *src, *dst;
int ret, i;
@@ -30,54 +30,54 @@ static struct sg_table *i915_gem_map_dma_buf(struct
dma_buf_attachment *attachme
goto err;
/* Copy sg so that we make an independent mapping */
- st = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
- if (st == NULL) {
+ sgt = kmalloc(sizeof(*sgt), GFP_KERNEL);
+ if (!sgt) {
ret = -ENOMEM;
goto err_unpin_pages;
}
- ret = sg_alloc_table(st, obj->mm.pages->nents, GFP_KERNEL);
+ ret = sg_alloc_table(sgt, obj->mm.pages->nents, GFP_KERNEL);
if (ret)
goto err_free;
src = obj->mm.pages->sgl;
- dst = st->sgl;
+ dst = sgt->sgl;
for (i = 0; i < obj->mm.pages->nents; i++) {
sg_set_page(dst, sg_page(src), src->length, 0);
dst = sg_next(dst);
src = sg_next(src);
}
- if (!dma_map_sg_attrs(attachment->dev,
- st->sgl, st->nents, dir,
+ if (!dma_map_sg_attrs(attach->dev,
+ sgt->sgl, sgt->nents, dir,
DMA_ATTR_SKIP_CPU_SYNC)) {
ret = -ENOMEM;
goto err_free_sg;
}
- return st;
+ return sgt;
err_free_sg:
- sg_free_table(st);
+ sg_free_table(sgt);
err_free:
- kfree(st);
+ kfree(sgt);
err_unpin_pages:
i915_gem_object_unpin_pages(obj);
err:
return ERR_PTR(ret);
}
-static void i915_gem_unmap_dma_buf(struct dma_buf_attachment *attachment,
- struct sg_table *sg,
+static void i915_gem_unmap_dma_buf(struct dma_buf_attachment *attach,
+ struct sg_table *sgt,
enum dma_data_direction dir)
{
- struct drm_i915_gem_object *obj = dma_buf_to_obj(attachment->dmabuf);
+ struct drm_i915_gem_object *obj = dma_buf_to_obj(attach->dmabuf);
- dma_unmap_sg_attrs(attachment->dev,
- sg->sgl, sg->nents, dir,
+ dma_unmap_sg_attrs(attach->dev,
+ sgt->sgl, sgt->nents, dir,
DMA_ATTR_SKIP_CPU_SYNC);
- sg_free_table(sg);
- kfree(sg);
+ sg_free_table(sgt);
+ kfree(sgt);
i915_gem_object_unpin_pages(obj);
}
@@ -194,25 +194,25 @@ struct dma_buf *i915_gem_prime_export(struct
drm_gem_object *gem_obj, int flags)
static int i915_gem_object_get_pages_dmabuf(struct drm_i915_gem_object *obj)
{
- struct sg_table *pages;
+ struct sg_table *sgt;
unsigned int sg_page_sizes;
- pages = dma_buf_map_attachment(obj->base.import_attach,
- DMA_BIDIRECTIONAL);
- if (IS_ERR(pages))
- return PTR_ERR(pages);
+ sgt = dma_buf_map_attachment(obj->base.import_attach,
+DMA_BIDIRECTIONAL);
+ if (IS_ERR(sgt))
+ return PTR_ERR(sgt);
- sg_page_sizes = i915_sg_page_sizes(pages->sgl);
+ sg_page_sizes = i915_sg_page_sizes(sgt->sgl);
- __i915_gem_object_set_pages(obj, pages, sg_page_sizes);
+ __i915_gem_object_set_pages(obj, sgt, sg_page_sizes);
return 0;
}
static void i915_gem_object_put_pages_dmabuf(struct drm_i915_gem_object *obj,
-struct sg_table *pages)
+struct sg_table *sgt)
{
- dma_buf_unmap_attachment(obj->base.import_attach, pages,
+ dma_buf_unmap_attachment(obj->base.import_attach, sgt,
DMA_BIDIRECTIONAL);
}
@@ -250,7 +250,7 @@ struct drm_gem_object *i915_gem_prime_impo
Re: [PATCH v2 7/9] PM: sleep: core: Rename DPM_FLAG_NEVER_SKIP
On Sat, Apr 18, 2020 at 1:11 PM Rafael J. Wysocki wrote:
>
> From: "Rafael J. Wysocki"
>
> Rename DPM_FLAG_NEVER_SKIP to DPM_FLAG_NO_DIRECT_COMPLETE which
> matches its purpose more closely.
>
> No functional impact.
>
> Signed-off-by: Rafael J. Wysocki
> Acked-by: Bjorn Helgaas # for PCI parts
> Acked-by: Jeff Kirsher
Acked-by: Alex Deucher
for radeon and amdgpu
Alex
> ---
>
> -> v2:
>* Rebased.
>* Added tags received so far.
>
> ---
> Documentation/driver-api/pm/devices.rst| 6 +++---
> Documentation/power/pci.rst| 10 +-
> drivers/base/power/main.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 2 +-
> drivers/gpu/drm/i915/intel_runtime_pm.c| 2 +-
> drivers/gpu/drm/radeon/radeon_kms.c| 2 +-
> drivers/misc/mei/pci-me.c | 2 +-
> drivers/misc/mei/pci-txe.c | 2 +-
> drivers/net/ethernet/intel/e1000e/netdev.c | 2 +-
> drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
> drivers/net/ethernet/intel/igc/igc_main.c | 2 +-
> drivers/pci/pcie/portdrv_pci.c | 2 +-
> include/linux/pm.h | 6 +++---
> 13 files changed, 21 insertions(+), 21 deletions(-)
>
> diff --git a/Documentation/driver-api/pm/devices.rst
> b/Documentation/driver-api/pm/devices.rst
> index f66c7b9126ea..4ace0eba4506 100644
> --- a/Documentation/driver-api/pm/devices.rst
> +++ b/Documentation/driver-api/pm/devices.rst
> @@ -361,9 +361,9 @@ the phases are: ``prepare``, ``suspend``,
> ``suspend_late``, ``suspend_noirq``.
> runtime PM disabled.
>
> This feature also can be controlled by device drivers by using the
> - ``DPM_FLAG_NEVER_SKIP`` and ``DPM_FLAG_SMART_PREPARE`` driver power
> - management flags. [Typically, they are set at the time the driver is
> - probed against the device in question by passing them to the
> + ``DPM_FLAG_NO_DIRECT_COMPLETE`` and ``DPM_FLAG_SMART_PREPARE`` driver
> + power management flags. [Typically, they are set at the time the
> driver
> + is probed against the device in question by passing them to the
> :c:func:`dev_pm_set_driver_flags` helper function.] If the first of
> these flags is set, the PM core will not apply the direct-complete
> procedure described above to the given device and, consequenty, to any
> diff --git a/Documentation/power/pci.rst b/Documentation/power/pci.rst
> index aa1c7fce6cd0..9e1408121bea 100644
> --- a/Documentation/power/pci.rst
> +++ b/Documentation/power/pci.rst
> @@ -1004,11 +1004,11 @@ including the PCI bus type. The flags should be set
> once at the driver probe
> time with the help of the dev_pm_set_driver_flags() function and they should
> not
> be updated directly afterwards.
>
> -The DPM_FLAG_NEVER_SKIP flag prevents the PM core from using the
> direct-complete
> -mechanism allowing device suspend/resume callbacks to be skipped if the
> device
> -is in runtime suspend when the system suspend starts. That also affects all
> of
> -the ancestors of the device, so this flag should only be used if absolutely
> -necessary.
> +The DPM_FLAG_NO_DIRECT_COMPLETE flag prevents the PM core from using the
> +direct-complete mechanism allowing device suspend/resume callbacks to be
> skipped
> +if the device is in runtime suspend when the system suspend starts. That
> also
> +affects all of the ancestors of the device, so this flag should only be used
> if
> +absolutely necessary.
>
> The DPM_FLAG_SMART_PREPARE flag instructs the PCI bus type to only return a
> positive value from pci_pm_prepare() if the ->prepare callback provided by
> the
> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> index 3170d93e29f9..dbc1e5e7346b 100644
> --- a/drivers/base/power/main.c
> +++ b/drivers/base/power/main.c
> @@ -1844,7 +1844,7 @@ static int device_prepare(struct device *dev,
> pm_message_t state)
> spin_lock_irq(&dev->power.lock);
> dev->power.direct_complete = state.event == PM_EVENT_SUSPEND &&
> (ret > 0 || dev->power.no_pm_callbacks) &&
> - !dev_pm_test_driver_flags(dev, DPM_FLAG_NEVER_SKIP);
> + !dev_pm_test_driver_flags(dev, DPM_FLAG_NO_DIRECT_COMPLETE);
> spin_unlock_irq(&dev->power.lock);
> return 0;
> }
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> index fd1dc3236eca..a9086ea1ab60 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> @@ -191,7 +191,7 @@ int amdgpu_driver_load_kms(struct drm_device *dev,
> unsigned long flags)
> }
>
> if (adev->runpm) {
> - dev_pm_set_driver_flags(dev->dev, DPM_FLAG_NEVER_SKIP);
> + dev_pm_set_driver_flags(dev->dev,
> DPM_FLAG_NO_DIRECT_COMPLETE);
> pm_runtime_use_autosuspend(dev->dev);
> pm_runtime_set_autosuspend_delay(de
Re: [PATCH v3] dt-bindings: display: dw_mipi_dsi.txt: convert to yaml
On Wed, Apr 22, 2020 at 12:59 PM Adrian Ratiu wrote: > > This converts the Synopsis MIPI DSI binding documentation to yaml and > should be quite straightforward. I've added a missing ref clk and also > added Philippe as maintainer b/c he's the original txt author following > the algorithm provided in Message-ID 20200420175909.ga5...@ravnborg.org. > > Cc: Rob Herring > Cc: Philippe CORNU > Cc: devicet...@vger.kernel.org > Suggested-by: Laurent Pinchart > Signed-off-by: Adrian Ratiu > --- > Changes in v3: > - Added ports property and its children which are required (Laurent) > - Sorted required list alphabetically > > Changes in v2: > - Removed unnecessary descriptions and maxItems (Rob) > - Changed maintainers entry / dropped Mark (Rob) > - Added dsi-controller.yaml ref (Rob) > --- > .../bindings/display/bridge/dw_mipi_dsi.txt | 32 - > .../display/bridge/snps,dw-mipi-dsi.yaml | 72 +++ > 2 files changed, 72 insertions(+), 32 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt > create mode 100644 > Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml > > diff --git a/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt > b/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt > deleted file mode 100644 > index b13adf30b8d3b..0 > --- a/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt > +++ /dev/null > @@ -1,32 +0,0 @@ > -Synopsys DesignWare MIPI DSI host controller > - > - > -This document defines device tree properties for the Synopsys DesignWare MIPI > -DSI host controller. It doesn't constitue a device tree binding specification > -by itself but is meant to be referenced by platform-specific device tree > -bindings. > - > -When referenced from platform device tree bindings the properties defined in > -this document are defined as follows. The platform device tree bindings are > -responsible for defining whether each optional property is used or not. > - > -- reg: Memory mapped base address and length of the DesignWare MIPI DSI > - host controller registers. (mandatory) > - > -- clocks: References to all the clocks specified in the clock-names property > - as specified in [1]. (mandatory) > - > -- clock-names: > - - "pclk" is the peripheral clock for either AHB and APB. (mandatory) > - - "px_clk" is the pixel clock for the DPI/RGB input. (optional) > - > -- resets: References to all the resets specified in the reset-names property > - as specified in [2]. (optional) > - > -- reset-names: string reset name, must be "apb" if used. (optional) > - > -- panel or bridge node: see [3]. (mandatory) > - > -[1] Documentation/devicetree/bindings/clock/clock-bindings.txt > -[2] Documentation/devicetree/bindings/reset/reset.txt > -[3] Documentation/devicetree/bindings/display/mipi-dsi-bus.txt > diff --git > a/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml > b/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml > new file mode 100644 > index 0..076567d8d8ec1 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml > @@ -0,0 +1,72 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/bridge/snps,dw-mipi-dsi.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Synopsys DesignWare MIPI DSI host controller > + > +maintainers: > + - Philippe CORNU > + > +description: | > + This document defines device tree properties for the Synopsys DesignWare > MIPI > + DSI host controller. It doesn't constitue a device tree binding > specification > + by itself but is meant to be referenced by platform-specific device tree > + bindings. > + > + When referenced from platform device tree bindings the properties defined > in > + this document are defined as follows. The platform device tree bindings are > + responsible for defining whether each property is required or optional. > + > +allOf: > + - $ref: ../dsi-controller.yaml# > + > +properties: > + reg: > +maxItems: 1 > + > + clocks: > +items: > + - description: Module clock > + - description: DSI bus clock for either AHB and APB > + - description: Pixel clock for the DPI/RGB input > +minItems: 2 > + > + clock-names: > +items: > + - const: ref > + - const: pclk > + - const: px_clk > +minItems: 2 > + > + resets: > +maxItems: 1 > + > + reset-names: > +const: apb > + > + ports: > +type: object > + > +properties: > + port@0: > +type: object > +description: Input node to receive pixel data. > + port@1: > +type: object > +description: DSI output node to panel. > + > +required: > + - port@0 > + - port@1 > + > +patternProperties: > + "^panel@[0-3]$":
Re: [PATCH] drm: amdgpu: fix kernel-doc struct warning
On Tue, Apr 21, 2020 at 10:34 AM Christian König
wrote:
>
> Am 21.04.20 um 16:33 schrieb Christian König:
> > Am 20.04.20 um 03:50 schrieb Randy Dunlap:
> >> Fix a kernel-doc warning of missing struct field desription:
> >>
> >> ../drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:92: warning: Function
> >> parameter or member 'vm' not described in 'amdgpu_vm_eviction_lock'
> >
> > Can't we just document the function parameter instead? Should only be
> > one IIRC.
>
> On the other hand forget that, the format doesn't match a proper
> kernel-doc for a function anyway.
>
> Reviewed-by: Christian König
>
Applied. Thanks!
Alex
> >
> > Thanks,
> > Christian.
> >
> >>
> >> Fixes: a269e44989f3 ("drm/amdgpu: Avoid reclaim fs while eviction lock")
> >> Signed-off-by: Randy Dunlap
> >> Cc: Signed-off-by: Alex Sierra
> >> Cc: Felix Kuehling
> >> Cc: Christian König
> >> Cc: Alex Deucher
> >> Cc: David (ChunMing) Zhou
> >> Cc: amd-...@lists.freedesktop.org
> >> ---
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> --- lnx-57-rc2.orig/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> >> +++ lnx-57-rc2/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> >> @@ -82,7 +82,7 @@ struct amdgpu_prt_cb {
> >> struct dma_fence_cb cb;
> >> };
> >> -/**
> >> +/*
> >>* vm eviction_lock can be taken in MMU notifiers. Make sure no
> >> reclaim-FS
> >>* happens while holding this lock anywhere to prevent deadlocks when
> >>* an MMU notifier runs in reclaim-FS context.
> >
> > ___
> > amd-gfx mailing list
> > amd-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Rule for bridge yaml dt binding maintainers?
On Mon, Apr 20, 2020 at 12:59 PM Sam Ravnborg wrote: > > Hi Adrian > > On Mon, Apr 20, 2020 at 02:19:24PM +0300, Adrian Ratiu wrote: > > Hello, > > > > I got confused while doing the txt -> yaml conversion at [1] and it's still > > not clear to me who should be added in the "maintainers" field. Clearly not > > the maintainers as returned by get_maintainer.pl. :) > > > > Rob mentioned that "owners" should be manintainers but I also have trouble > > picking the persons who should be owners / yaml maintainers. > > > > Looking at the completed bridge conversions in the latest linux-next, I > > couldn't find a rule and the majority of bindings are still txt: > > > > $ find ./devicetree/bindings/display/bridge/ -name *txt | wc -l > > 23 > > $ find ./devicetree/bindings/display/bridge/ -name *yaml | wc -l > > 5 > > > > So my questions are: > > 1. Is there a general rule for assigning yaml file owners/maintainers? > > > > 2. Is this vagueness specific to the bridge dt bindings only? > > > > 3. Who should step up and maintain these bindings? Original/new authors, > > SoC, bridge, DRM maintainers etc.? > > > > It would be useful to have a rule to make it easier to do these conversions. > > We (Collabora) are considering doing the conversion work. > > For the panel conversion I did recently it was simple: > 1) If listed in MAINTAINERS - use this info > 2) Otherwise use the person(s) that authored the original .txt file. >Using git log --follow foo.txt > 3) In a few cases I may have decided otherwise, but the above covers the >majority. Yes. > I would also be great if you or someone else could: > - teach get_maintainers about .yaml file listed maintainers It already does to some extent. IIRC, there's a mode to extract email addresses from files. I was hoping that the MAINTAINERS file split happens sometime and we can just generate a MAINTAINERS file for bindings. > - teach checkpatch that it is OK to convert .txt to .yaml Yeah, I should fix my bug. > - teach checkpatch about some simple yaml validation (maybe) I don't see checkpatch being able to check much of what comes up in review. Maybe indentation. > I am looking forward to the day we have more .yaml files > than .txt files in Documentation/devicetree/binding/* 700 vs. 3000 currently. It's about 60-70 new bindings and ~100 conversions per cycle. At this point we're review limited I think and at the current rate, we should be done in 7 years. Yay! :( We need a faster way. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: amd/display: fix Kconfig help text
On Wed, Apr 22, 2020 at 10:00 AM Harry Wentland wrote:
>
> On 2020-04-21 7:34 p.m., Randy Dunlap wrote:
> > From: Randy Dunlap
> >
> > Fix help text: indent one tab + 2 spaces; end a sentence with a
> > period; and collapse short lines of text to one line.
> >
> > Fixes: 23c61b4599c4 ("drm/amd: Fix Kconfig indentation")
> > Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
> > Signed-off-by: Randy Dunlap
> > Cc: Harry Wentland
> > Cc: Alex Deucher
> > Cc: Krzysztof Kozlowski
>
> Reviewed-by: Harry Wentland
>
Applied. Thanks!
Alex
> Harry
>
> > ---
> > drivers/gpu/drm/amd/display/Kconfig |8 ++--
> > 1 file changed, 2 insertions(+), 6 deletions(-)
> >
> > --- linux-next-20200421.orig/drivers/gpu/drm/amd/display/Kconfig
> > +++ linux-next-20200421/drivers/gpu/drm/amd/display/Kconfig
> > @@ -21,16 +21,12 @@ config DRM_AMD_DC_HDCP
> > bool "Enable HDCP support in DC"
> > depends on DRM_AMD_DC
> > help
> > - Choose this option
> > - if you want to support
> > - HDCP authentication
> > + Choose this option if you want to support HDCP authentication.
> >
> > config DEBUG_KERNEL_DC
> > bool "Enable kgdb break in DC"
> > depends on DRM_AMD_DC
> > help
> > - Choose this option
> > - if you want to hit
> > - kdgb_break in assert.
> > + Choose this option if you want to hit kdgb_break in assert.
> >
> > endmenu
> >
> ___
> 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 v7 5/8] dt-bindings: display: add i.MX6 MIPI DSI host controller doc
On Tue, 21 Apr 2020 19:16:07 +0300, Adrian Ratiu wrote: > This provides an example DT binding for the MIPI DSI host controller > present on the i.MX6 SoC based on Synopsis DesignWare v1.01 IP. > > Cc: Rob Herring > Cc: Neil Armstrong > Cc: Fabio Estevam > Cc: Laurent Pinchart > Cc: devicet...@vger.kernel.org > Tested-by: Adrian Pop > Tested-by: Arnaud Ferraris > Signed-off-by: Sjoerd Simons > Signed-off-by: Martyn Welch > Signed-off-by: Adrian Ratiu > --- > Changes since v6: > - Added ref to the newly created snps,dw-mipi-dsi.yaml (Laurent) > - Moved *-cells properties outside patternProperties (Laurent) > - Removed the panel port documentation (Laurent) > - Wrapped lines at 80 chars, typo fixes, sort includes (Laurent) > > Changes since v5: > - Fixed missing reg warning (Fabio) > - Updated dt-schema and fixed warnings (Rob) > > Changes since v4: > - Fixed yaml binding to pass `make dt_binding_check dtbs_check` > and addressed received binding feedback (Rob) > > Changes since v3: > - Added commit message (Neil) > - Converted to yaml format (Neil) > - Minor dt node + driver fixes (Rob) > - Added small panel example to the host controller binding > > Changes since v2: > - Fixed commit tags (Emil) > --- > .../display/imx/fsl,mipi-dsi-imx6.yaml| 135 ++ > 1 file changed, 135 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml > My bot found errors running 'make dt_binding_check' on your patch: Unknown file referenced: [Errno 2] No such file or directory: '/usr/local/lib/python3.6/dist-packages/dtschema/schemas/display/bridge/snps,dw-mipi-dsi.yaml' Documentation/devicetree/bindings/Makefile:11: recipe for target 'Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.example.dts' failed make[1]: *** [Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.example.dts] Error 255 make[1]: *** Waiting for unfinished jobs Makefile:1300: recipe for target 'dt_binding_check' failed make: *** [dt_binding_check] Error 2 See https://patchwork.ozlabs.org/patch/1274360 If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure dt-schema is up to date: pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade Please check and re-submit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 2/2] dt-bindings: documenting compatible string vendor "visionox"
On Tue, 21 Apr 2020 10:25:08 +0530, Harigovindan P wrote:
> Documenting compatible string vendor "visionox" in vendor-prefix yaml file.
>
> Signed-off-by: Harigovindan P
> ---
> Changes in v11:
> - Added visionox compatible string in vendor-prefixes.yaml
> - Added as a part of checkpatch script error for panel driver.
>
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/vendor-prefixes.yaml:
patternProperties:visionox,.*: {'description': 'Visionox'} is not valid under
any of the given schemas (Possible causes of the failure):
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/vendor-prefixes.yaml:
patternProperties:visionox,.*: 'not' is a required property
Documentation/devicetree/bindings/Makefile:11: recipe for target
'Documentation/devicetree/bindings/vendor-prefixes.example.dts' failed
make[1]: *** [Documentation/devicetree/bindings/vendor-prefixes.example.dts]
Error 1
make[1]: *** Waiting for unfinished jobs
warning: no schema found in file:
Documentation/devicetree/bindings/vendor-prefixes.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/vendor-prefixes.yaml:
ignoring, error in schema: patternProperties: visionox,.*
warning: no schema found in file:
Documentation/devicetree/bindings/vendor-prefixes.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/vendor-prefixes.yaml:
ignoring, error in schema: patternProperties: visionox,.*
Makefile:1300: recipe for target 'dt_binding_check' failed
make: *** [dt_binding_check] Error 2
See https://patchwork.ozlabs.org/patch/1273941
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:
pip3 install git+https://github.com/devicetree-org/dt-schema.git@master
--upgrade
Please check and re-submit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH hmm 0/5] Adjust hmm_range_fault() API
On 4/21/20 5:21 PM, Jason Gunthorpe wrote: From: Jason Gunthorpe The API is a bit complicated for the uses we actually have, and disucssions for simplifying have come up a number of times. This small series removes the customizable pfn format and simplifies the return code of hmm_range_fault() All the drivers are adjusted to process in the simplified format. I would appreciated tested-by's for the two drivers, thanks! For nouveau you can add: Tested-by: Ralph Campbell ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] amdgpu: fixes memleak issue when init failed
Am 22.04.20 um 17:51 schrieb Ruhl, Michael J:
-Original Message-
From: dri-devel On Behalf Of
Bernard Zhao
Sent: Tuesday, April 21, 2020 7:17 AM
To: Alex Deucher ; Christian König
; David (ChunMing) Zhou
; David Airlie ; Daniel Vetter
; Tom St Denis ; Ori Messinger
; Sam Ravnborg ; Bernard
Zhao ; amd-...@lists.freedesktop.org; dri-
de...@lists.freedesktop.org; linux-ker...@vger.kernel.org
Cc: opensource.ker...@vivo.com
Subject: [PATCH] amdgpu: fixes memleak issue when init failed
VRAM manager and DRM MM when init failed, there is no operaction
to free kzalloc memory & remove device file.
This will lead to memleak & cause stability issue.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 24
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index 82a3299e53c0..4c5fb153e6b4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -175,30 +175,44 @@ static int amdgpu_vram_mgr_init(struct
ttm_mem_type_manager *man,
ret = device_create_file(adev->dev,
&dev_attr_mem_info_vram_total);
if (ret) {
DRM_ERROR("Failed to create device file
mem_info_vram_total\n");
- return ret;
+ goto VRAM_TOTAL_FAIL;
}
ret = device_create_file(adev->dev,
&dev_attr_mem_info_vis_vram_total);
Have you looked at the DEVICE_ATTR mechanism?
Yeah, I've thought about that as well. But didn't had time to look into
detail if that could be applied here or not.
Regards,
Christian.
It is set up to add device files. You won't get the granularity of each file,
but it has a lot more automatic-ness to setting this stuff up.
Mike
if (ret) {
DRM_ERROR("Failed to create device file
mem_info_vis_vram_total\n");
- return ret;
+ goto VIS_VRAM_TOTA_FAIL;
}
ret = device_create_file(adev->dev,
&dev_attr_mem_info_vram_used);
if (ret) {
DRM_ERROR("Failed to create device file
mem_info_vram_used\n");
- return ret;
+ goto VRAM_USED_FAIL;
}
ret = device_create_file(adev->dev,
&dev_attr_mem_info_vis_vram_used);
if (ret) {
DRM_ERROR("Failed to create device file
mem_info_vis_vram_used\n");
- return ret;
+ goto VIS_VRAM_USED_FAIL;
}
ret = device_create_file(adev->dev,
&dev_attr_mem_info_vram_vendor);
if (ret) {
DRM_ERROR("Failed to create device file
mem_info_vram_vendor\n");
- return ret;
+ goto VRAM_VERDOR_FAIL;
}
return 0;
+
+VRAM_VERDOR_FAIL:
+ device_remove_file(adev->dev,
&dev_attr_mem_info_vis_vram_used);
+VIS_VRAM_USED_FAIL:
+ device_remove_file(adev->dev, &dev_attr_mem_info_vram_used);
+RVAM_USED_FAIL:
+ device_remove_file(adev->dev,
&dev_attr_mem_info_vis_vram_total);
+VIS_VRAM_TOTA_FAIL:
+ device_remove_file(adev->dev, &dev_attr_mem_info_vram_total);
+VRAM_TOTAL_FAIL:
+ kfree(mgr);
+ man->priv = NULL;
+
+ return ret;
}
/**
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 5/8] dt-bindings: display: add i.MX6 MIPI DSI host controller doc
On Wed, 22 Apr 2020, Laurent Pinchart
wrote:
Hi Adrian,
Thank you for the patch.
On Tue, Apr 21, 2020 at 07:16:07PM +0300, Adrian Ratiu wrote:
This provides an example DT binding for the MIPI DSI host
controller present on the i.MX6 SoC based on Synopsis
DesignWare v1.01 IP. Cc: Rob Herring Cc:
Neil Armstrong Cc: Fabio Estevam
Cc: Laurent Pinchart
Cc:
devicet...@vger.kernel.org Tested-by: Adrian Pop
Tested-by: Arnaud Ferraris
Signed-off-by: Sjoerd Simons
Signed-off-by: Martyn Welch
Signed-off-by: Adrian Ratiu
--- Changes since v6:
- Added ref to the newly created snps,dw-mipi-dsi.yaml
(Laurent) - Moved *-cells properties outside
patternProperties (Laurent) - Removed the panel port
documentation (Laurent) - Wrapped lines at 80 chars, typo
fixes, sort includes (Laurent)
Changes since v5:
- Fixed missing reg warning (Fabio) - Updated dt-schema and
fixed warnings (Rob)
Changes since v4:
- Fixed yaml binding to pass `make dt_binding_check
dtbs_check` and addressed received binding feedback (Rob)
Changes since v3:
- Added commit message (Neil) - Converted to yaml format
(Neil) - Minor dt node + driver fixes (Rob) - Added small
panel example to the host controller binding
Changes since v2:
- Fixed commit tags (Emil)
---
.../display/imx/fsl,mipi-dsi-imx6.yaml| 135
++ 1 file changed, 135 insertions(+) create
mode 100644
Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml
diff --git
a/Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml
b/Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml
new file mode 100644 index 0..b73e3ae33a852 ---
/dev/null +++
b/Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml
@@ -0,0 +1,135 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR
BSD-2-Clause) +%YAML 1.2 +--- +$id:
http://devicetree.org/schemas/display/imx/fsl,mipi-dsi-imx6.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml# +
+title: Freescale i.MX6 DW MIPI DSI Host Controller +
+maintainers: + - Adrian Ratiu +
+description: | + The i.MX6 DSI host controller is a Synopsys
DesignWare MIPI DSI v1.01 + IP block with a companion PHY IP.
+ + These DT bindings follow the Synopsys DW MIPI DSI bindings
defined in +
Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt
with + the following device-specific properties. + +allOf: +
- $ref: ../bridge/snps,dw-mipi-dsi.yaml# + +properties: +
'#address-cells': +const: 1 + + '#size-cells': +const:
0 + + compatible: +items: + - const:
fsl,imx6q-mipi-dsi + - const: snps,dw-mipi-dsi + + reg: +
maxItems: 1 + + interrupts: +maxItems: 1 + + clocks: +
items: + - description: Module Clock + - description:
DSI bus clock + + clock-names: +items: + - const: ref
+ - const: pclk + + fsl,gpr: +description: +
Phandle to the iomuxc-gpr region containing the multiplexer
ctrl register. +$ref:
/schemas/types.yaml#/definitions/phandle + + ports: +type:
object +description: | + A node containing DSI input &
output port nodes with endpoint + definitions as
documented in +
Documentation/devicetree/bindings/media/video-interfaces.txt +
Documentation/devicetree/bindings/graph.txt +properties: +
port@0: +type: object +description: +
DSI input port node, connected to the ltdc rgb output port. +
+ port@1: +type: object +description: +
RGB output port node, connected to a panel or a bridge input
port.
Isn't it the other way around, doesn't the bridge take RGB input
and output DSI ? And to be precise, it's not about RGB, but
about the input being parallel interface (DSI will also carry
RGB).
I would add
required:
- port@0 - port@1
Sorry for the confusions and omissions :) Will fix the names to
avoid ambiguities and also add the required property and the
missing port@0 in the example below in v8.
Many thanks,
Adrian
+
+additionalProperties: false
+
+patternProperties:
+ "^panel@[0-3]$":
+type: object
+
+required:
+ - "#address-cells"
+ - "#size-cells"
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - ports
+
+examples:
+ - |+
+#include
+#include
+#include
+
+dsi: dsi@21e {
+#address-cells = <1>;
+#size-cells = <0>;
+compatible = "fsl,imx6q-mipi-dsi", "snps,dw-mipi-dsi";
+reg = <0x021e 0x4000>;
+interrupts = <0 102 IRQ_TYPE_LEVEL_HIGH>;
+fsl,gpr = <&gpr>;
+clocks = <&clks IMX6QDL_CLK_MIPI_CORE_CFG>,
+ <&clks IMX6QDL_CLK_MIPI_IPG>;
+clock-names = "ref", "pclk";
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
port@0 is missing.
+port@1 {
+reg = <1>;
+dsi_out: endpoint {
+remote-en
[PATCH v3] dt-bindings: display: dw_mipi_dsi.txt: convert to yaml
This converts the Synopsis MIPI DSI binding documentation to yaml and should be quite straightforward. I've added a missing ref clk and also added Philippe as maintainer b/c he's the original txt author following the algorithm provided in Message-ID 20200420175909.ga5...@ravnborg.org. Cc: Rob Herring Cc: Philippe CORNU Cc: devicet...@vger.kernel.org Suggested-by: Laurent Pinchart Signed-off-by: Adrian Ratiu --- Changes in v3: - Added ports property and its children which are required (Laurent) - Sorted required list alphabetically Changes in v2: - Removed unnecessary descriptions and maxItems (Rob) - Changed maintainers entry / dropped Mark (Rob) - Added dsi-controller.yaml ref (Rob) --- .../bindings/display/bridge/dw_mipi_dsi.txt | 32 - .../display/bridge/snps,dw-mipi-dsi.yaml | 72 +++ 2 files changed, 72 insertions(+), 32 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt create mode 100644 Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml diff --git a/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt b/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt deleted file mode 100644 index b13adf30b8d3b..0 --- a/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt +++ /dev/null @@ -1,32 +0,0 @@ -Synopsys DesignWare MIPI DSI host controller - - -This document defines device tree properties for the Synopsys DesignWare MIPI -DSI host controller. It doesn't constitue a device tree binding specification -by itself but is meant to be referenced by platform-specific device tree -bindings. - -When referenced from platform device tree bindings the properties defined in -this document are defined as follows. The platform device tree bindings are -responsible for defining whether each optional property is used or not. - -- reg: Memory mapped base address and length of the DesignWare MIPI DSI - host controller registers. (mandatory) - -- clocks: References to all the clocks specified in the clock-names property - as specified in [1]. (mandatory) - -- clock-names: - - "pclk" is the peripheral clock for either AHB and APB. (mandatory) - - "px_clk" is the pixel clock for the DPI/RGB input. (optional) - -- resets: References to all the resets specified in the reset-names property - as specified in [2]. (optional) - -- reset-names: string reset name, must be "apb" if used. (optional) - -- panel or bridge node: see [3]. (mandatory) - -[1] Documentation/devicetree/bindings/clock/clock-bindings.txt -[2] Documentation/devicetree/bindings/reset/reset.txt -[3] Documentation/devicetree/bindings/display/mipi-dsi-bus.txt diff --git a/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml b/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml new file mode 100644 index 0..076567d8d8ec1 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/snps,dw-mipi-dsi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Synopsys DesignWare MIPI DSI host controller + +maintainers: + - Philippe CORNU + +description: | + This document defines device tree properties for the Synopsys DesignWare MIPI + DSI host controller. It doesn't constitue a device tree binding specification + by itself but is meant to be referenced by platform-specific device tree + bindings. + + When referenced from platform device tree bindings the properties defined in + this document are defined as follows. The platform device tree bindings are + responsible for defining whether each property is required or optional. + +allOf: + - $ref: ../dsi-controller.yaml# + +properties: + reg: +maxItems: 1 + + clocks: +items: + - description: Module clock + - description: DSI bus clock for either AHB and APB + - description: Pixel clock for the DPI/RGB input +minItems: 2 + + clock-names: +items: + - const: ref + - const: pclk + - const: px_clk +minItems: 2 + + resets: +maxItems: 1 + + reset-names: +const: apb + + ports: +type: object + +properties: + port@0: +type: object +description: Input node to receive pixel data. + port@1: +type: object +description: DSI output node to panel. + +required: + - port@0 + - port@1 + +patternProperties: + "^panel@[0-3]$": +type: object + +required: + - clock-names + - clocks + - ports + - reg -- 2.26.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] dt-bindings: display: dw_mipi_dsi.txt: convert to yaml
This converts the Synopsis MIPI DSI binding documentation to yaml and should be quite straightforward. I've added a missing ref clk and also added Philippe as maintainer b/c he's the original txt author following the algorithm provided in Message-ID 20200420175909.ga5...@ravnborg.org. Cc: Rob Herring Cc: Philippe CORNU Cc: devicet...@vger.kernel.org Suggested-by: Laurent Pinchart Signed-off-by: Adrian Ratiu --- Changes in v3: - Added ports property and its children which are required (Laurent) - Sorted required list alphabetically Changes in v2: - Removed unnecessary descriptions and maxItems (Rob) - Changed maintainers entry / dropped Mark (Rob) - Added dsi-controller.yaml ref (Rob) --- .../bindings/display/bridge/dw_mipi_dsi.txt | 32 - .../display/bridge/snps,dw-mipi-dsi.yaml | 72 +++ 2 files changed, 72 insertions(+), 32 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt create mode 100644 Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml diff --git a/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt b/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt deleted file mode 100644 index b13adf30b8d3b..0 --- a/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt +++ /dev/null @@ -1,32 +0,0 @@ -Synopsys DesignWare MIPI DSI host controller - - -This document defines device tree properties for the Synopsys DesignWare MIPI -DSI host controller. It doesn't constitue a device tree binding specification -by itself but is meant to be referenced by platform-specific device tree -bindings. - -When referenced from platform device tree bindings the properties defined in -this document are defined as follows. The platform device tree bindings are -responsible for defining whether each optional property is used or not. - -- reg: Memory mapped base address and length of the DesignWare MIPI DSI - host controller registers. (mandatory) - -- clocks: References to all the clocks specified in the clock-names property - as specified in [1]. (mandatory) - -- clock-names: - - "pclk" is the peripheral clock for either AHB and APB. (mandatory) - - "px_clk" is the pixel clock for the DPI/RGB input. (optional) - -- resets: References to all the resets specified in the reset-names property - as specified in [2]. (optional) - -- reset-names: string reset name, must be "apb" if used. (optional) - -- panel or bridge node: see [3]. (mandatory) - -[1] Documentation/devicetree/bindings/clock/clock-bindings.txt -[2] Documentation/devicetree/bindings/reset/reset.txt -[3] Documentation/devicetree/bindings/display/mipi-dsi-bus.txt diff --git a/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml b/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml new file mode 100644 index 0..076567d8d8ec1 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/snps,dw-mipi-dsi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Synopsys DesignWare MIPI DSI host controller + +maintainers: + - Philippe CORNU + +description: | + This document defines device tree properties for the Synopsys DesignWare MIPI + DSI host controller. It doesn't constitue a device tree binding specification + by itself but is meant to be referenced by platform-specific device tree + bindings. + + When referenced from platform device tree bindings the properties defined in + this document are defined as follows. The platform device tree bindings are + responsible for defining whether each property is required or optional. + +allOf: + - $ref: ../dsi-controller.yaml# + +properties: + reg: +maxItems: 1 + + clocks: +items: + - description: Module clock + - description: DSI bus clock for either AHB and APB + - description: Pixel clock for the DPI/RGB input +minItems: 2 + + clock-names: +items: + - const: ref + - const: pclk + - const: px_clk +minItems: 2 + + resets: +maxItems: 1 + + reset-names: +const: apb + + ports: +type: object + +properties: + port@0: +type: object +description: Input node to receive pixel data. + port@1: +type: object +description: DSI output node to panel. + +required: + - port@0 + - port@1 + +patternProperties: + "^panel@[0-3]$": +type: object + +required: + - clock-names + - clocks + - ports + - reg -- 2.26.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH hmm 5/5] mm/hmm: remove the customizable pfn format from hmm_range_fault
[+Philip Yang]
Am 2020-04-21 um 8:21 p.m. schrieb Jason Gunthorpe:
> From: Jason Gunthorpe
>
> Presumably the intent here was that hmm_range_fault() could put the data
> into some HW specific format and thus avoid some work. However, nothing
> actually does that, and it isn't clear how anything actually could do that
> as hmm_range_fault() provides CPU addresses which must be DMA mapped.
>
> Perhaps there is some special HW that does not need DMA mapping, but we
> don't have any examples of this, and the theoretical performance win of
> avoiding an extra scan over the pfns array doesn't seem worth the
> complexity. Plus pfns needs to be scanned anyhow to sort out any
> DEVICE_PRIVATE pages.
>
> This version replaces the uint64_t with an usigned long containing a pfn
> and fix flags. On input flags is filled with the HMM_PFN_REQ_* values, on
> successful output it is filled with HMM_PFN_* values, describing the state
> of the pages.
>
> amdgpu is simple to convert, it doesn't use snapshot and doesn't use
> per-page flags.
>
> nouveau uses only 16 hmm_pte entries at most (ie fits in a few cache
> lines), and it sweeps over its pfns array a couple of times anyhow.
>
> Signed-off-by: Jason Gunthorpe
> Signed-off-by: Christoph Hellwig
Hi Jason,
I pointed out a typo in the documentation inline. Other than that, the
series is
Acked-by: Felix Kuehling
I'll try to build it and run some basic tests later.
> ---
> Documentation/vm/hmm.rst| 26 ++--
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 35 ++
> drivers/gpu/drm/nouveau/nouveau_dmem.c | 60 +++--
> drivers/gpu/drm/nouveau/nouveau_dmem.h | 4 +-
> drivers/gpu/drm/nouveau/nouveau_svm.c | 52
> include/linux/hmm.h | 99 ++-
> mm/hmm.c| 160 +++-
> 7 files changed, 204 insertions(+), 232 deletions(-)
>
> diff --git a/Documentation/vm/hmm.rst b/Documentation/vm/hmm.rst
> index 9924f2caa0184c..73a9b8c858e5d9 100644
> --- a/Documentation/vm/hmm.rst
> +++ b/Documentation/vm/hmm.rst
> @@ -185,9 +185,6 @@ The usage pattern is::
>range.start = ...;
>range.end = ...;
>range.pfns = ...;
> - range.flags = ...;
> - range.values = ...;
> - range.pfn_shift = ...;
>
>if (!mmget_not_zero(interval_sub->notifier.mm))
>return -EFAULT;
> @@ -229,15 +226,10 @@ The hmm_range struct has 2 fields, default_flags and
> pfn_flags_mask, that specif
> fault or snapshot policy for the whole range instead of having to set them
> for each entry in the pfns array.
>
> -For instance, if the device flags for range.flags are::
> +For instance if the device driver wants pages for a range with at least read
> +permission, it sets::
>
> -range.flags[HMM_PFN_VALID] = (1 << 63);
> -range.flags[HMM_PFN_WRITE] = (1 << 62);
> -
> -and the device driver wants pages for a range with at least read permission,
> -it sets::
> -
> -range->default_flags = (1 << 63);
> +range->default_flags = HMM_PFN_REQ_VALID;
This should be HMM_PFN_REQ_FAULT.
> range->pfn_flags_mask = 0;
>
> and calls hmm_range_fault() as described above. This will fill fault all
> pages
> @@ -246,18 +238,18 @@ in the range with at least read permission.
> Now let's say the driver wants to do the same except for one page in the
> range for
> which it wants to have write permission. Now driver set::
>
> -range->default_flags = (1 << 63);
> -range->pfn_flags_mask = (1 << 62);
> -range->pfns[index_of_write] = (1 << 62);
> +range->default_flags = HMM_PFN_REQ_VALID;
HMM_PFN_REQ_FAULT
Regards,
Felix
> +range->pfn_flags_mask = HMM_PFN_REQ_WRITE;
> +range->pfns[index_of_write] = HMM_PFN_REQ_WRITE;
>
> With this, HMM will fault in all pages with at least read (i.e., valid) and
> for the
> address == range->start + (index_of_write << PAGE_SHIFT) it will fault with
> write permission i.e., if the CPU pte does not have write permission set
> then HMM
> will call handle_mm_fault().
>
> -Note that HMM will populate the pfns array with write permission for any page
> -that is mapped with CPU write permission no matter what values are set
> -in default_flags or pfn_flags_mask.
> +After hmm_range_fault completes the flag bits are set to the current state of
> +the page tables, ie HMM_PFN_VALID | HMM_PFN_WRITE will be set if the page is
> +writable.
>
>
> Represent and manage device memory from core kernel point of view
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 449083f9f8a2bf..bcfa8c26647d5e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -766,17 +766,6 @@ struct amdgpu_ttm_tt {
> };
>
> #ifdef CONFIG_DRM_AMDGPU_USERPTR
> -/* flags used by HMM internal, not related to CPU/GPU PTE flags */
> -static const uint64_t hmm_range_flags[HMM_PFN_FLAG_MAX] = {
> -
Re: [Poke: Tejun] Re: [RFC v3 03/11] drm/vblank: Add vblank works
Hello, On Tue, Apr 21, 2020 at 02:34:59PM +0200, Daniel Vetter wrote: > > > Also, of course, let me know if yu're not happy with the > > > __kthread_queue_work() changes/kthread_worker usage in drm_vblank_work as > > > well > > > > Just glanced over it and I still wonder whether it needs to be that tightly > > integrated, but we can look into that once we settle on whether this is the > > right direction. > > I don't think we absolutely have to do this, simply means some nested > irq-safe spinlock. One in vblank_work, other in kthread_worker. Since the > delayed work doesn't do that I think it'd be nice if the drm_vblank > (instead of timer) delayed work could use the same pattern. I'd prefer if they were two separate locks unless that makes practical difference, but if it does, please go ahead. Thanks. -- tejun ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 5/8] dt-bindings: display: add i.MX6 MIPI DSI host controller doc
On Wed, 22 Apr 2020, Laurent Pinchart wrote: Hi Adrian, On Wed, Apr 22, 2020 at 01:15:41PM +0300, Adrian Ratiu wrote: On Wed, 22 Apr 2020, Laurent Pinchart wrote: > On Wed, Apr 22, 2020 at 03:58:33AM +0300, Laurent Pinchart > wrote: >> On Tue, Apr 21, 2020 at 07:16:07PM +0300, Adrian Ratiu >> wrote: >>> This provides an example DT binding for the MIPI DSI host >>> controller present on the i.MX6 SoC based on Synopsis >>> DesignWare v1.01 IP. Cc: Rob Herring >>> Cc: Neil Armstrong Cc: Fabio >>> Estevam Cc: Laurent Pinchart >>> Cc: >>> devicet...@vger.kernel.org Tested-by: Adrian Pop >>> Tested-by: Arnaud Ferraris >>> Signed-off-by: Sjoerd >>> Simons Signed-off-by: Martyn >>> Welch Signed-off-by: Adrian >>> Ratiu --- Changes since v6: >>> - Added ref to the newly created snps,dw-mipi-dsi.yaml >>> (Laurent) - Moved *-cells properties outside >>> patternProperties (Laurent) - Removed the panel port >>> documentation (Laurent) - Wrapped lines at 80 chars, typo >>> fixes, sort includes (Laurent) >>> Changes since v5: >>> - Fixed missing reg warning (Fabio) - Updated dt-schema >>> and fixed warnings (Rob) >>> Changes since v4: >>> - Fixed yaml binding to pass `make dt_binding_check >>> dtbs_check` and addressed received binding feedback (Rob) >>> Changes since v3: >>> - Added commit message (Neil) - Converted to yaml format >>> (Neil) - Minor dt node + driver fixes (Rob) - Added small >>> panel example to the host controller binding >>> Changes since v2: >>> - Fixed commit tags (Emil) >>> --- >>> .../display/imx/fsl,mipi-dsi-imx6.yaml| 135 >>> ++ 1 file changed, 135 insertions(+) >>> create mode 100644 >>> Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml >>> diff --git >>> a/Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml >>> b/Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml >>> new file mode 100644 index 0..b73e3ae33a852 --- >>> /dev/null +++ >>> b/Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml >>> @@ -0,0 +1,135 @@ +# SPDX-License-Identifier: (GPL-2.0-only >>> OR BSD-2-Clause) +%YAML 1.2 +--- +$id: >>> http://devicetree.org/schemas/display/imx/fsl,mipi-dsi-imx6.yaml# >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# + >>> +title: Freescale i.MX6 DW MIPI DSI Host Controller + >>> +maintainers: + - Adrian Ratiu >>> + +description: | + The >>> i.MX6 DSI host controller is a Synopsys DesignWare MIPI >>> DSI v1.01 + IP block with a companion PHY IP. > I forgot to mention, if there's a companion PHY, shouldn't > it be referenced from the DT bindings ? I don't think so, that description was copied verbatim from the imx6 ref manual IIRC, the physical layer is the same for MIPI DSI which does TX as for MIPI CSI which does RX, but looking at the ref manual and how drivers are written I don't think it's necessary. Does that mean that the PHY is controlled through the registers specified by the reg property ? If so then this is fine. Yes that is correct, there is just a single set of conf registers specified via reg. This might change if we wanted to unify the DSI and CSI drivers a bit, but considering the scope already associated with this patch series I'm a bit afraid to open a subject like that =) That's understandable :-) >>> + >>> + These DT bindings follow the Synopsys DW MIPI DSI bindings defined in >>> + Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt with >>> + the following device-specific properties. >>> + >>> +allOf: >>> + - $ref: ../bridge/snps,dw-mipi-dsi.yaml# >>> + >>> +properties: >>> + '#address-cells': >>> +const: 1 >>> + >>> + '#size-cells': >>> +const: 0 >>> + >>> + compatible: >>> +items: >>> + - const: fsl,imx6q-mipi-dsi >>> + - const: snps,dw-mipi-dsi >>> + >>> + reg: >>> +maxItems: 1 >>> + >>> + interrupts: >>> +maxItems: 1 >>> + >>> + clocks: >>> +items: >>> + - description: Module Clock >>> + - description: DSI bus clock >>> + >>> + clock-names: >>> +items: >>> + - const: ref >>> + - const: pclk >>> + >>> + fsl,gpr: >>> +description: >>> + Phandle to the iomuxc-gpr region containing the multiplexer ctrl register. >>> +$ref: /schemas/types.yaml#/definitions/phandle >>> + >>> + ports: >>> +type: object >>> +description: | >>> + A node containing DSI input & output port nodes with endpoint >>> + definitions as documented in >>> + Documentation/devicetree/bindings/media/video-interfaces.txt >>> + Documentation/devicetree/bindings/graph.txt >>> +properties: >>> + port@0: >>> +type: object >>> +description: >>> + DSI input port node, connected to the ltdc rgb output port. >>> + >>> + port@1: >>> +type: object >>> +description: >>>
Re: [PATCH v2 1/6] drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux
Hi,
On Wed, Apr 22, 2020 at 3:23 AM Stephen Boyd wrote:
>
> Quoting Douglas Anderson (2020-04-20 22:06:17)
> > The ti-sn65dsi86 MIPI DSI to eDP bridge chip has 4 pins on it that can
> > be used as GPIOs in a system. Each pin can be configured as input,
> > output, or a special function for the bridge chip. These are:
> > - GPIO1: SUSPEND Input
> > - GPIO2: DSIA VSYNC
> > - GPIO3: DSIA HSYNC or VSYNC
> > - GPIO4: PWM
> >
> > Let's expose these pins as GPIOs. A few notes:
> > - Access to ti-sn65dsi86 is via i2c so we set "can_sleep".
> > - These pins can't be configured for IRQ.
> > - There are no programmable pulls or other fancy features.
> > - Keeping the bridge chip powered might be expensive. The driver is
> > setup such that if all used GPIOs are only inputs we'll power the
> > bridge chip on just long enough to read the GPIO and then power it
> > off again. Setting a GPIO as output will keep the bridge powered.
> > - If someone releases a GPIO we'll implicitly switch it to an input so
> > we no longer need to keep the bridge powered for it.
> >
> > Becaue of all of the above limitations we just need to implement a
>
> Because
>
> > bare-bones GPIO driver. The device tree bindings already account for
> > this device being a GPIO controller so we only need the driver changes
> > for it.
> >
> > NOTE: Despite the fact that these pins are nominally muxable I don't
> > believe it makes sense to expose them through the pinctrl interface as
> > well as the GPIO interface. The special functions are things that the
> > bridge chip driver itself would care about and it can just configure
> > the pins as needed.
> >
> > Signed-off-by: Douglas Anderson
> > Cc: Linus Walleij
> > Cc: Bartosz Golaszewski
> > ---
> >
>
> Cool patch.
>
> > Changes in v2:
> > - ("Export...GPIOs") is 1/2 of replacement for ("Allow...bridge GPIOs")
> >
> > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 165 ++
> > 1 file changed, 165 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > index 6ad688b320ae..d04c2b83d699 100644
> > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > @@ -874,6 +886,153 @@ static int ti_sn_bridge_parse_dsi_host(struct
> > ti_sn_bridge *pdata)
> > return 0;
> > }
> >
> > +static struct ti_sn_bridge *gchip_to_pdata(struct gpio_chip *chip)
> > +{
> > + return container_of(chip, struct ti_sn_bridge, gchip);
> > +}
> > +
> > +static int ti_sn_bridge_gpio_get_direction(struct gpio_chip *chip,
> > + unsigned int offset)
> > +{
> > + struct ti_sn_bridge *pdata = gchip_to_pdata(chip);
> > +
> > + return (atomic_read(&pdata->gchip_output) & BIT(offset)) ?
>
> Any reason this isn't a bitmap?
Don't bitmaps need an external lock to protect against concurrent
access? When I looked I wasn't convinced that the GPIO subsystem
prevented two callers from changing two GPIOs at the same time. See
below for a bigger discussion.
> > + GPIOF_DIR_OUT : GPIOF_DIR_IN;
>
> And why can't we read the hardware to figure out if it's in output or
> input mode?
A few reasons:
1. If nobody else had the bridge powered on this would be a slow
operation involving powering the bridge on, querying via i2c, and then
powering the bridge off. Not only would it be slow but you'd be
powering the chip up for no really good reason. You didn't need to
know anything that only the chip could tell you.
2. If nobody else had the bridge powered on then the bridge loses
state and resets to defaults (everything resets to "input"). Yes, we
could still power the bridge up and confirm this, but...
3. This bitmap does double-duty of not only knowing whether a pin is
input or output but also whether we've incremented the "pm_runtime"
refcount in order to keep the output driven. Knowing whether we've
already incremented the "pm_runtime" refcount can simplify a bit of
the code because we know whether it's powered without having to power
it on and query. If we didn't have a cache, then when we changed a
pin to input we'd do:
pm_runtime_get() // Make sure we can access
if dir_was_output:
pm_runtime_put() // Not driving anymore
set_to_input();
pm_runtime_put() // Done with access
...basically in some cases we'd do pm_runtime_put() twice in the same
function. It'd work, but feels like a worse solution than the one in
my patch.
4. When I bootup I see that this call gets made once per GPIO in
gpiochip_add_data_with_key(). There's no reason to go through all the
slowness when we know these pins are inputs.
In the next version of the patch I'll plan to add a kerneldoc comment
to "struct ti_sn_bridge" and add a summary of the above for
"gchip_output".
> > +}
> > +
> [...]
> > +static int ti_sn_bridge_gpio_direction_output(struct gpio_chip *chip,
> > + unsigned int offset, int val)
RE: [PATCH] amdgpu: fixes memleak issue when init failed
>-Original Message-
>From: dri-devel On Behalf Of
>Bernard Zhao
>Sent: Tuesday, April 21, 2020 7:17 AM
>To: Alex Deucher ; Christian König
>; David (ChunMing) Zhou
>; David Airlie ; Daniel Vetter
>; Tom St Denis ; Ori Messinger
>; Sam Ravnborg ; Bernard
>Zhao ; amd-...@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org; linux-ker...@vger.kernel.org
>Cc: opensource.ker...@vivo.com
>Subject: [PATCH] amdgpu: fixes memleak issue when init failed
>
>VRAM manager and DRM MM when init failed, there is no operaction
>to free kzalloc memory & remove device file.
>This will lead to memleak & cause stability issue.
>
>Signed-off-by: Bernard Zhao
>---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 24
>
> 1 file changed, 19 insertions(+), 5 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>index 82a3299e53c0..4c5fb153e6b4 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>@@ -175,30 +175,44 @@ static int amdgpu_vram_mgr_init(struct
>ttm_mem_type_manager *man,
> ret = device_create_file(adev->dev,
>&dev_attr_mem_info_vram_total);
> if (ret) {
> DRM_ERROR("Failed to create device file
>mem_info_vram_total\n");
>- return ret;
>+ goto VRAM_TOTAL_FAIL;
> }
> ret = device_create_file(adev->dev,
>&dev_attr_mem_info_vis_vram_total);
Have you looked at the DEVICE_ATTR mechanism?
It is set up to add device files. You won't get the granularity of each file,
but it has a lot more automatic-ness to setting this stuff up.
Mike
> if (ret) {
> DRM_ERROR("Failed to create device file
>mem_info_vis_vram_total\n");
>- return ret;
>+ goto VIS_VRAM_TOTA_FAIL;
> }
> ret = device_create_file(adev->dev,
>&dev_attr_mem_info_vram_used);
> if (ret) {
> DRM_ERROR("Failed to create device file
>mem_info_vram_used\n");
>- return ret;
>+ goto VRAM_USED_FAIL;
> }
> ret = device_create_file(adev->dev,
>&dev_attr_mem_info_vis_vram_used);
> if (ret) {
> DRM_ERROR("Failed to create device file
>mem_info_vis_vram_used\n");
>- return ret;
>+ goto VIS_VRAM_USED_FAIL;
> }
> ret = device_create_file(adev->dev,
>&dev_attr_mem_info_vram_vendor);
> if (ret) {
> DRM_ERROR("Failed to create device file
>mem_info_vram_vendor\n");
>- return ret;
>+ goto VRAM_VERDOR_FAIL;
> }
>
> return 0;
>+
>+VRAM_VERDOR_FAIL:
>+ device_remove_file(adev->dev,
>&dev_attr_mem_info_vis_vram_used);
>+VIS_VRAM_USED_FAIL:
>+ device_remove_file(adev->dev, &dev_attr_mem_info_vram_used);
>+RVAM_USED_FAIL:
>+ device_remove_file(adev->dev,
>&dev_attr_mem_info_vis_vram_total);
>+VIS_VRAM_TOTA_FAIL:
>+ device_remove_file(adev->dev, &dev_attr_mem_info_vram_total);
>+VRAM_TOTAL_FAIL:
>+ kfree(mgr);
>+ man->priv = NULL;
>+
>+ return ret;
> }
>
> /**
>--
>2.26.2
>
>___
>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 v7 5/8] dt-bindings: display: add i.MX6 MIPI DSI host controller doc
Hi Adrian, On Wed, Apr 22, 2020 at 01:15:41PM +0300, Adrian Ratiu wrote: > On Wed, 22 Apr 2020, Laurent Pinchart wrote: > > On Wed, Apr 22, 2020 at 03:58:33AM +0300, Laurent Pinchart wrote: > >> On Tue, Apr 21, 2020 at 07:16:07PM +0300, Adrian Ratiu wrote: > >>> This provides an example DT binding for the MIPI DSI host > >>> controller present on the i.MX6 SoC based on Synopsis > >>> DesignWare v1.01 IP. Cc: Rob Herring Cc: > >>> Neil Armstrong Cc: Fabio Estevam > >>> Cc: Laurent Pinchart > >>> Cc: > >>> devicet...@vger.kernel.org Tested-by: Adrian Pop > >>> Tested-by: Arnaud Ferraris > >>> Signed-off-by: Sjoerd Simons > >>> Signed-off-by: Martyn Welch > >>> Signed-off-by: Adrian Ratiu > >>> --- Changes since v6: > >>> - Added ref to the newly created snps,dw-mipi-dsi.yaml > >>> (Laurent) - Moved *-cells properties outside > >>> patternProperties (Laurent) - Removed the panel port > >>> documentation (Laurent) - Wrapped lines at 80 chars, typo > >>> fixes, sort includes (Laurent) > >>> Changes since v5: > >>> - Fixed missing reg warning (Fabio) - Updated dt-schema and > >>> fixed warnings (Rob) > >>> Changes since v4: > >>> - Fixed yaml binding to pass `make dt_binding_check > >>> dtbs_check` and addressed received binding feedback (Rob) > >>> Changes since v3: > >>> - Added commit message (Neil) - Converted to yaml format > >>> (Neil) - Minor dt node + driver fixes (Rob) - Added small > >>> panel example to the host controller binding > >>> Changes since v2: > >>> - Fixed commit tags (Emil) > >>> --- > >>> .../display/imx/fsl,mipi-dsi-imx6.yaml| 135 > >>> ++ 1 file changed, 135 insertions(+) create > >>> mode 100644 > >>> Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml > >>> diff --git > >>> a/Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml > >>> b/Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml > >>> new file mode 100644 index 0..b73e3ae33a852 --- > >>> /dev/null +++ > >>> b/Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml > >>> @@ -0,0 +1,135 @@ +# SPDX-License-Identifier: (GPL-2.0-only > >>> OR BSD-2-Clause) +%YAML 1.2 +--- +$id: > >>> http://devicetree.org/schemas/display/imx/fsl,mipi-dsi-imx6.yaml# > >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# + > >>> +title: Freescale i.MX6 DW MIPI DSI Host Controller + > >>> +maintainers: + - Adrian Ratiu > >>> + +description: | + The i.MX6 DSI host controller is a > >>> Synopsys DesignWare MIPI DSI v1.01 + IP block with a > >>> companion PHY IP. > > > > I forgot to mention, if there's a companion PHY, shouldn't it be > > referenced from the DT bindings ? > > I don't think so, that description was copied verbatim from the > imx6 ref manual IIRC, the physical layer is the same for MIPI DSI > which does TX as for MIPI CSI which does RX, but looking at the > ref manual and how drivers are written I don't think it's > necessary. Does that mean that the PHY is controlled through the registers specified by the reg property ? If so then this is fine. > This might change if we wanted to unify the DSI and CSI drivers a > bit, but considering the scope already associated with this patch > series I'm a bit afraid to open a subject like that =) That's understandable :-) > >>> + > >>> + These DT bindings follow the Synopsys DW MIPI DSI bindings defined in > >>> + Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt with > >>> + the following device-specific properties. > >>> + > >>> +allOf: > >>> + - $ref: ../bridge/snps,dw-mipi-dsi.yaml# > >>> + > >>> +properties: > >>> + '#address-cells': > >>> +const: 1 > >>> + > >>> + '#size-cells': > >>> +const: 0 > >>> + > >>> + compatible: > >>> +items: > >>> + - const: fsl,imx6q-mipi-dsi > >>> + - const: snps,dw-mipi-dsi > >>> + > >>> + reg: > >>> +maxItems: 1 > >>> + > >>> + interrupts: > >>> +maxItems: 1 > >>> + > >>> + clocks: > >>> +items: > >>> + - description: Module Clock > >>> + - description: DSI bus clock > >>> + > >>> + clock-names: > >>> +items: > >>> + - const: ref > >>> + - const: pclk > >>> + > >>> + fsl,gpr: > >>> +description: > >>> + Phandle to the iomuxc-gpr region containing the multiplexer ctrl > >>> register. > >>> +$ref: /schemas/types.yaml#/definitions/phandle > >>> + > >>> + ports: > >>> +type: object > >>> +description: | > >>> + A node containing DSI input & output port nodes with endpoint > >>> + definitions as documented in > >>> + Documentation/devicetree/bindings/media/video-interfaces.txt > >>> + Documentation/devicetree/bindings/graph.txt > >>> +properties: > >>> + port@0: > >>> +type: object > >>> +description: > >>> + DSI input port node, connected to the ltdc rgb output port. > >>> + > >>> + po
Re: [PATCH] drm/tegra: Clean up GPIO includes
On Wed, Apr 22, 2020 at 12:15 AM Thierry Reding wrote: > On Wed, Apr 15, 2020 at 02:24:27PM +0200, Linus Walleij wrote: > > The Tegra DRM drivers includes the legacy GPIO headers > > and but what it really > > uses is since only gpio_desc > > structs are ever referenced. > > > > Include the right header on the top level tegra/drm.h > > file and drop all the surplus includes. > > > > Signed-off-by: Linus Walleij > > --- > > drivers/gpu/drm/tegra/dpaux.c | 2 -- > > drivers/gpu/drm/tegra/drm.h | 2 +- > > drivers/gpu/drm/tegra/hdmi.c | 1 - > > drivers/gpu/drm/tegra/sor.c | 1 - > > 4 files changed, 1 insertion(+), 5 deletions(-) > > Applied, thanks. I think I already applied it to the drm misc tree the other day, sorry if that wasn't clear. If tegra has a separate tree I suppose git will figure it all out in the end. Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 4/8] drm: imx: Add i.MX 6 MIPI DSI host platform driver
Hi Adrian,
On Wed, Apr 22, 2020 at 12:33:10PM +0300, Adrian Ratiu wrote:
> On Wed, 22 Apr 2020, Laurent Pinchart wrote:
> > On Tue, Apr 21, 2020 at 07:16:06PM +0300, Adrian Ratiu wrote:
> >> This adds support for the Synopsis DesignWare MIPI DSI v1.01
> >> host controller which is embedded in i.MX 6 SoCs. Based on
> >> following patches, but updated/extended to work with existing
> >> support found in the kernel: - drm: imx: Support Synopsys
> >> DesignWare MIPI DSI host controller
> >> Signed-off-by: Liu Ying
> >> Cc: Fabio Estevam Cc: Enric Balletbo
> >> Serra Reviewed-by: Emil Velikov
> >> Tested-by: Adrian Pop
> >> Tested-by: Arnaud Ferraris
> >> Signed-off-by: Sjoerd Simons
> >> Signed-off-by: Martyn Welch
> >> Signed-off-by: Adrian Ratiu
> >> --- Changes since v6:
> >> - Replaced custom noop encoder with the simple drm encoder
> >> (Enric) - Added CONFIG_DRM_IMX6_MIPI_DSI depends on CONFIG_OF
> >> (Enric) - Dropped imx_mipi_dsi_register() because now it only
> >> creates the dummy encoder which can easily be done directly
> >> in imx_dsi_bind()
> >> Changes since v5:
> >> - Reword to remove unrelated device tree patch mention
> >> (Fabio) - Move pllref_clk enable/disable to bind/unbind
> >> (Ezequiel) - Fix freescale.com -> nxp.com email addresses
> >> (Fabio) - Also added myself as module author (Fabio) - Use
> >> DRM_DEV_* macros for consistency, print more error msg
> >> Changes since v4:
> >> - Split off driver-specific configuration of phy timings due
> >> to new upstream API. - Move regmap infrastructure logic to
> >> separate commit (Ezequiel) - Move dsi v1.01 layout addition
> >> to a separate commit (Ezequiel) - Minor warnings and driver
> >> name fixes
> >> Changes since v3:
> >> - Renamed platform driver to reflect it's i.MX6 only. (Fabio)
> >> Changes since v2:
> >> - Fixed commit tags. (Emil)
> >> Changes since v1:
> >> - Moved register definitions & regmap initialization into
> >> bridge module. Platform drivers get the regmap via plat_data
> >> after calling the bridge probe. (Emil)
> >> ---
> >> drivers/gpu/drm/imx/Kconfig| 8 +
> >> drivers/gpu/drm/imx/Makefile | 1 +
> >> drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c | 391 +
> >> 3 files changed, 400 insertions(+)
> >> create mode 100644 drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c
> >> diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig
> >> index 207bf7409dfba..0dffc72df7922 100644
> >> --- a/drivers/gpu/drm/imx/Kconfig
> >> +++ b/drivers/gpu/drm/imx/Kconfig
> >> @@ -39,3 +39,11 @@ config DRM_IMX_HDMI
> >>depends on DRM_IMX help Choose this if you want to use
> >> HDMI on i.MX6.
> >> + +config DRM_IMX6_MIPI_DSI + tristate "Freescale i.MX6
> >> DRM MIPI DSI" +select DRM_DW_MIPI_DSI +depends on
> >> DRM_IMX + depends on OF + help +Choose this if you want
> >> to use MIPI DSI on i.MX6. diff --git
> >> a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile
> >> index 21cdcc2faabc8..9a7843c593478 100644 ---
> >> a/drivers/gpu/drm/imx/Makefile +++
> >> b/drivers/gpu/drm/imx/Makefile @@ -9,3 +9,4 @@
> >> obj-$(CONFIG_DRM_IMX_TVE) += imx-tve.o
> >> obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o
> >> obj-$(CONFIG_DRM_IMX_HDMI) += dw_hdmi-imx.o
> >> +obj-$(CONFIG_DRM_IMX6_MIPI_DSI) += dw_mipi_dsi-imx6.o diff
> >> --git a/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c
> >> b/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c new file mode 100644
> >> index 0..f8a0a4fe16e21 --- /dev/null +++
> >> b/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c @@ -0,0 +1,391 @@ +//
> >> SPDX-License-Identifier: GPL-2.0+ +/* + * i.MX6 drm driver -
> >> MIPI DSI Host Controller + * + * Copyright (C) 2011-2015
> >> Freescale Semiconductor, Inc. + * Copyright (C) 2019-2020
> >> Collabora, Ltd. + */ + +#include +#include
> >> +#include +#include
> >> +#include
> >> +#include +#include
> >> +#include +#include
> >> +#include
> >> +#include +#include
> >> +#include + +#include "imx-drm.h" + +#define
> >> DSI_PWR_UP 0x04 +#define RESET
> >> 0 +#define POWERUP BIT(0) + +#define
> >> DSI_PHY_IF_CTRL0x5c +#define
> >> PHY_IF_CTRL_RESET 0x0 + +#define DSI_PHY_TST_CTRL0
> >> 0x64 +#define PHY_TESTCLK BIT(1) +#define
> >> PHY_UNTESTCLK 0 +#define PHY_TESTCLR
> >> BIT(0) +#define PHY_UNTESTCLR 0 +
> >> +#define DSI_PHY_TST_CTRL1 0x68 +#define PHY_TESTEN
> >> BIT(16) +#define PHY_UNTESTEN 0 +#define
> >> PHY_TESTDOUT(n)(((n) & 0xff) << 8)
> >> +#define PHY_TESTDIN(n)(((n) & 0xff) <<
> >> 0) + +struct imx_mipi_dsi { + struct drm_encoder
> >> encoder; + struct device *dev; + struct regmap *mux_sel; +
> >> struct dw_mipi_dsi *mipi_dsi; +s
[PATCH 1/2] drm/vram-helper: Don't put new BOs into VRAM
Most drivers that use VRAM helpers have only a few MiB of framebuffer memory available. To reduce fragmentation, new BOs are now put into system memory by default. Only pin operations are allowed to move BOs into VRAM. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/drm_gem_vram_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c b/drivers/gpu/drm/drm_gem_vram_helper.c index 8b2d5c945c95c..5d5bfb38bbed4 100644 --- a/drivers/gpu/drm/drm_gem_vram_helper.c +++ b/drivers/gpu/drm/drm_gem_vram_helper.c @@ -197,7 +197,7 @@ static int drm_gem_vram_init(struct drm_device *dev, acc_size = ttm_bo_dma_acc_size(bdev, size, sizeof(*gbo)); gbo->bo.bdev = bdev; - drm_gem_vram_placement(gbo, TTM_PL_FLAG_VRAM | TTM_PL_FLAG_SYSTEM); + drm_gem_vram_placement(gbo, TTM_PL_FLAG_SYSTEM); ret = ttm_bo_init(bdev, &gbo->bo, size, ttm_bo_type_device, &gbo->placement, pg_align, false, acc_size, -- 2.26.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/vram-helper: Alternate between bottom-up and top-down placement
With limited VRAM available, fragmentation can lead to OOM errors.
Alternating between bottom-up and top-down placement keeps BOs near the
ends of the VRAM and the available pages consecutively near the middle.
A real-world example with 16 MiB of VRAM is shown below.
> cat /sys/kernel/debug/dri/0/vram-mm
0x-0x057f: 1407: free
0x057f-0x0b5b: 1500: used
0x0b5b-0x0ff0: 1173: free
The first free area was the location of the fbdev framebuffer. The used
area is Weston's current framebuffer of 1500 pages. Weston now cannot
do a pageflip to another 1500 page-wide framebuffer, even though enough
pages are available. The patch resolves this problem to
> cat /sys/kernel/debug/dri/0/vram-mm
0x-0x05dc: 1500: used
0x05dc-0x0a14: 1080: free
0x0a14-0x0ff0: 1500: used
with both of Weston's framebuffers located near the ends of the VRAM
memory.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 28 ++-
include/drm/drm_gem_vram_helper.h | 10 ++
2 files changed, 29 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 5d5bfb38bbed4..2d0b7474288de 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -146,15 +146,33 @@ static void drm_gem_vram_placement(struct
drm_gem_vram_object *gbo,
unsigned int i;
unsigned int c = 0;
u32 invariant_flags = pl_flag & TTM_PL_FLAG_TOPDOWN;
+ struct drm_device *dev = gbo->bo.base.dev;
+ struct drm_vram_mm *vmm = dev->vram_mm;
gbo->placement.placement = gbo->placements;
gbo->placement.busy_placement = gbo->placements;
- if (pl_flag & TTM_PL_FLAG_VRAM)
- gbo->placements[c++].flags = TTM_PL_FLAG_WC |
-TTM_PL_FLAG_UNCACHED |
-TTM_PL_FLAG_VRAM |
-invariant_flags;
+ if (pl_flag & TTM_PL_FLAG_VRAM) {
+ /*
+* We usually have at most 2 pinned BOs during pageflips,
+* plus cursor BOs. Even with a significant number of free
+' pages, always placing bottom-up can lead to fragmentation
+* and OOM situations. So if there's no explicit request for
+* top-down placement, we alternatingly place BOs bottom-up
+* and top-down. The placement strategy should help to keep
+* free VRAM pages available near the middle of the VRAM.
+*/
+ gbo->placements[c].flags = TTM_PL_FLAG_WC |
+ TTM_PL_FLAG_UNCACHED |
+ TTM_PL_FLAG_VRAM |
+ invariant_flags;
+ if (!(invariant_flags & TTM_PL_FLAG_TOPDOWN)) {
+ if (vmm->place_topdown)
+ gbo->placements[c].flags |= TTM_PL_FLAG_TOPDOWN;
+ vmm->place_topdown = !vmm->place_topdown;
+ }
+ ++c;
+ }
if (pl_flag & TTM_PL_FLAG_SYSTEM)
gbo->placements[c++].flags = TTM_PL_MASK_CACHING |
diff --git a/include/drm/drm_gem_vram_helper.h
b/include/drm/drm_gem_vram_helper.h
index b63bcd1b996da..04767d0ff23a6 100644
--- a/include/drm/drm_gem_vram_helper.h
+++ b/include/drm/drm_gem_vram_helper.h
@@ -165,10 +165,10 @@ void drm_gem_vram_simple_display_pipe_cleanup_fb(
/**
* struct drm_vram_mm - An instance of VRAM MM
- * @vram_base: Base address of the managed video memory
- * @vram_size: Size of the managed video memory in bytes
- * @bdev: The TTM BO device.
- * @funcs: TTM BO functions
+ * @vram_base: Base address of the managed video memory
+ * @vram_size: Size of the managed video memory in bytes
+ * @bdev: The TTM BO device
+ * @place_topdown: Flags the next BO to be placed at the VRAM's high end
*
* The fields &struct drm_vram_mm.vram_base and
* &struct drm_vram_mm.vrm_size are managed by VRAM MM, but are
@@ -180,6 +180,8 @@ struct drm_vram_mm {
size_t vram_size;
struct ttm_bo_device bdev;
+
+ bool place_topdown;
};
/**
--
2.26.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] drm/vram-helper: Reduce memory fragmentation
VRAM memory can easily fragment, which leads to OOM errors on devices with little VRAM available (i.e., all of them). This patchset addresses the problem by placing BOs near the bottom and top ends of the VRAM and keeping available areas near the middle. Thomas Zimmermann (2): drm/vram-helper: Don't put new BOs into VRAM drm/vram-helper: Alternate between bottom-up and top-down placement drivers/gpu/drm/drm_gem_vram_helper.c | 30 +-- include/drm/drm_gem_vram_helper.h | 10 + 2 files changed, 30 insertions(+), 10 deletions(-) -- 2.26.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] drm/bochs: fix an issue of ioremap() leak
On Wed, Apr 22, 2020 at 4:52 PM Dejin Zheng wrote:
>
> On Tue, Apr 21, 2020 at 08:24:24PM +0300, Andy Shevchenko wrote:
> > On Tue, Apr 21, 2020 at 7:45 PM Dejin Zheng wrote:
> > >
> > > It forgot to call bochs_hw_fini() to release related resources when
> > > bochs_pci_probe() fail. eg: io virtual address get by ioremap().
> >
> > Good start, although I think the best is to switch this driver to use
> > pcim_*() functions and drop tons of legacy code.
> >
> Andy, thanks for your encouragement, I think we might be able to fix this
> issue first, after that, drop tons of legacy code by pcim_*() functions.
> Do you think it is ok?
It's really up to maintainer. I'm not the one here.
> > > Fixes: 81da8c3b8d3df6 ("drm/bochs: add drm_driver.release callback.")
> > > CC: Andy Shevchenko
> > > Signed-off-by: Dejin Zheng
> > > ---
> > > drivers/gpu/drm/bochs/bochs_drv.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/gpu/drm/bochs/bochs_drv.c
> > > b/drivers/gpu/drm/bochs/bochs_drv.c
> > > index addb0568c1af..210a60135c8a 100644
> > > --- a/drivers/gpu/drm/bochs/bochs_drv.c
> > > +++ b/drivers/gpu/drm/bochs/bochs_drv.c
> > > @@ -138,6 +138,7 @@ static int bochs_pci_probe(struct pci_dev *pdev,
> > > return ret;
> > >
> > > err_unload:
> > > + bochs_hw_fini(dev);
> > > bochs_unload(dev);
> > > err_free_dev:
> > > drm_dev_put(dev);
> > > --
> > > 2.25.0
> > >
> >
> >
> > --
> > With Best Regards,
> > Andy Shevchenko
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: amd/display: fix Kconfig help text
On 2020-04-21 7:34 p.m., Randy Dunlap wrote:
> From: Randy Dunlap
>
> Fix help text: indent one tab + 2 spaces; end a sentence with a
> period; and collapse short lines of text to one line.
>
> Fixes: 23c61b4599c4 ("drm/amd: Fix Kconfig indentation")
> Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
> Signed-off-by: Randy Dunlap
> Cc: Harry Wentland
> Cc: Alex Deucher
> Cc: Krzysztof Kozlowski
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/Kconfig |8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> --- linux-next-20200421.orig/drivers/gpu/drm/amd/display/Kconfig
> +++ linux-next-20200421/drivers/gpu/drm/amd/display/Kconfig
> @@ -21,16 +21,12 @@ config DRM_AMD_DC_HDCP
> bool "Enable HDCP support in DC"
> depends on DRM_AMD_DC
> help
> - Choose this option
> - if you want to support
> - HDCP authentication
> + Choose this option if you want to support HDCP authentication.
>
> config DEBUG_KERNEL_DC
> bool "Enable kgdb break in DC"
> depends on DRM_AMD_DC
> help
> - Choose this option
> - if you want to hit
> - kdgb_break in assert.
> + Choose this option if you want to hit kdgb_break in assert.
>
> endmenu
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] of_device: removed #include that caused a recursion in included headers
On Mon, Apr 20, 2020 at 06:04:29PM +0300, Hadar Gat wrote: > Both of_platform.h and of_device.h were included each other. > In of_device.h, removed unneeded #include to of_platform.h > and added include to of_platform.h in the files that needs it. > > Signed-off-by: Hadar Gat > Reported-by: kbuild test robot > Acked-by: Jonathan Cameron #for-iio > Acked-by: Stephen Boyd # clk > --- > v3: add include to of_platform.h in more files. (reported due other builds) > v2: add include to of_platform.h in more files. (reported due other builds) > > arch/sparc/kernel/pci.c | 1 + > arch/sparc/kernel/pci_sabre.c | 1 + > arch/sparc/kernel/pci_schizo.c| 1 + > arch/sparc/kernel/sbus.c | 1 + > arch/sparc/mm/io-unit.c | 1 + > arch/sparc/mm/iommu.c | 1 + > drivers/base/platform.c | 1 + > drivers/bus/imx-weim.c| 1 + > drivers/bus/vexpress-config.c | 1 + For drivers/bus/vexpress-config.c: Acked-by: Liviu Dudau Best regards, Liviu > drivers/clk/mediatek/clk-mt7622-aud.c | 1 + > drivers/dma/at_hdmac.c| 1 + > drivers/dma/stm32-dmamux.c| 1 + > drivers/dma/ti/dma-crossbar.c | 1 + > drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 1 + > drivers/gpu/drm/msm/hdmi/hdmi.c | 1 + > drivers/gpu/drm/msm/msm_drv.c | 1 + > drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 1 + > drivers/gpu/drm/sun4i/sun4i_tcon.c| 1 + > drivers/iio/adc/stm32-adc-core.c | 1 + > drivers/iio/adc/stm32-dfsdm-adc.c | 1 + > drivers/iio/adc/stm32-dfsdm-core.c| 1 + > drivers/iommu/tegra-smmu.c| 1 + > drivers/media/platform/coda/coda-common.c | 1 + > drivers/memory/atmel-ebi.c| 1 + > drivers/mfd/palmas.c | 1 + > drivers/mfd/ssbi.c| 1 + > drivers/mtd/nand/raw/omap2.c | 1 + > drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 1 + > drivers/net/ethernet/ti/cpsw.c| 1 + > drivers/phy/tegra/xusb.c | 1 + > drivers/pinctrl/freescale/pinctrl-imx1-core.c | 1 + > drivers/pinctrl/nomadik/pinctrl-nomadik.c | 1 + > drivers/soc/samsung/exynos-pmu.c | 1 + > drivers/soc/sunxi/sunxi_sram.c| 1 + > include/linux/of_device.h | 2 -- > lib/genalloc.c| 1 + > 36 files changed, 35 insertions(+), 2 deletions(-) > > diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c > index 5ed4382..89ea658 100644 > --- a/arch/sparc/kernel/pci.c > +++ b/arch/sparc/kernel/pci.c > @@ -21,6 +21,7 @@ > #include > #include > #include > +#include > > #include > #include > diff --git a/arch/sparc/kernel/pci_sabre.c b/arch/sparc/kernel/pci_sabre.c > index 3c38ca4..16761d0 100644 > --- a/arch/sparc/kernel/pci_sabre.c > +++ b/arch/sparc/kernel/pci_sabre.c > @@ -14,6 +14,7 @@ > #include > #include > #include > +#include > > #include > #include > diff --git a/arch/sparc/kernel/pci_schizo.c b/arch/sparc/kernel/pci_schizo.c > index 421aba0..733f069 100644 > --- a/arch/sparc/kernel/pci_schizo.c > +++ b/arch/sparc/kernel/pci_schizo.c > @@ -12,6 +12,7 @@ > #include > #include > #include > +#include > #include > > #include > diff --git a/arch/sparc/kernel/sbus.c b/arch/sparc/kernel/sbus.c > index 32141e1..2f4051f 100644 > --- a/arch/sparc/kernel/sbus.c > +++ b/arch/sparc/kernel/sbus.c > @@ -15,6 +15,7 @@ > #include > #include > #include > +#include > #include > > #include > diff --git a/arch/sparc/mm/io-unit.c b/arch/sparc/mm/io-unit.c > index 289276b..5638399 100644 > --- a/arch/sparc/mm/io-unit.c > +++ b/arch/sparc/mm/io-unit.c > @@ -15,6 +15,7 @@ > #include > #include > #include > +#include > > #include > #include > diff --git a/arch/sparc/mm/iommu.c b/arch/sparc/mm/iommu.c > index b00dde1..9cbb2e7 100644 > --- a/arch/sparc/mm/iommu.c > +++ b/arch/sparc/mm/iommu.c > @@ -16,6 +16,7 @@ > #include > #include > #include > +#include > > #include > #include > diff --git a/drivers/base/platform.c b/drivers/base/platform.c > index 520..f549274b 100644 > --- a/drivers/base/platform.c > +++ b/drivers/base/platform.c > @@ -12,6 +12,7 @@ > #include > #include > #include > +#include > #include > #include > #include > diff --git a/drivers/bus/imx-weim.c b/drivers/bus/imx-weim.c > index 28bb65a..8c786da 100644 > --- a/drivers/bus/imx-weim.c > +++ b/drivers/bus/imx-weim.c > @@ -11,6 +11,7 @@ > #include > #include > #include > +#include > #include > #include > #include > diff --git a/driv
[Bug 205291] Cannot switch off Radeon HD 4330/4350/4550 with vgaswitcheroo
https://bugzilla.kernel.org/show_bug.cgi?id=205291 --- Comment #10 from K J Petrie (kernel.b...@kjpetrie.co.uk) --- Looks like I need to recompile with CONFIG_PM_ADVANCED_DEBUG, I suspect. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205291] Cannot switch off Radeon HD 4330/4350/4550 with vgaswitcheroo
https://bugzilla.kernel.org/show_bug.cgi?id=205291 --- Comment #9 from K J Petrie (kernel.b...@kjpetrie.co.uk) --- Well, it'll take time to patch and recompile the kernel, but in the meantime here is all the contents of the power directories: AMD Radeon GPU cat /sys/bus/pci/devices/\:01\:00.0/power/runtime_status active cat /sys/bus/pci/devices/\:01\:00.0/power/control auto cat /sys/bus/pci/devices/\:01\:00.0/power/autosuspend_delay_ms 5000 cat /sys/bus/pci/devices/\:01\:00.0/power/runtime_active_time 1744516 cat /sys/bus/pci/devices/\:01\:00.0/power/runtime_suspended_time 184197 AMD HDA cat /sys/bus/pci/devices/\:01\:00.1/power/runtime_status active cat /sys/bus/pci/devices/\:01\:00.1/power/control auto cat /sys/bus/pci/devices/\:01\:00.1/power/autosuspend_delay_ms cat: '/sys/bus/pci/devices/:01:00.1/power/autosuspend_delay_ms': Input/output error cat /sys/bus/pci/devices/\:01\:00.1/power/runtime_active_time 2415454 cat /sys/bus/pci/devices/\:01\:00.1/power/runtime_suspended_time 214644 I double-checked that IO error, in case it was just a fluke, but it's consistent. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm v2] include/drm: sync up drm_fourcc.h
From: Binu R S
a) Adds new format modifiers for Intel Gen-12
- I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS
- I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS
b) Generated using make headers_install
c) Generated from drm-next
Signed-off-by: Binu R S
---
include/drm/drm_fourcc.h | 54 +---
1 file changed, 51 insertions(+), 3 deletions(-)
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index 5c69090d505a..8bc0b31597d8 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -69,7 +69,7 @@ extern "C" {
#define fourcc_code(a, b, c, d) ((__u32)(a) | ((__u32)(b) << 8) | \
((__u32)(c) << 16) | ((__u32)(d) << 24))
-#define DRM_FORMAT_BIG_ENDIAN (1<<31) /* format is big endian instead of
little endian */
+#define DRM_FORMAT_BIG_ENDIAN (1U<<31) /* format is big endian instead of
little endian */
/* Reserve 0 for the invalid format specifier */
#define DRM_FORMAT_INVALID 0
@@ -381,7 +381,7 @@ extern "C" {
* This is a tiled layout using 4Kb tiles in row-major layout.
* Within the tile pixels are laid out in 16 256 byte units / sub-tiles which
* are arranged in four groups (two wide, two high) with column-major layout.
- * Each group therefore consists out of four 256 byte units, which are also
laid
+ * Each group therefore consits out of four 256 byte units, which are also laid
* out as 2x2 column-major.
* 256 byte units are made out of four 64 byte blocks of pixels, producing
* either a square block or a 2:1 unit.
@@ -410,6 +410,30 @@ extern "C" {
#define I915_FORMAT_MOD_Y_TILED_CCSfourcc_mod_code(INTEL, 4)
#define I915_FORMAT_MOD_Yf_TILED_CCS fourcc_mod_code(INTEL, 5)
+/*
+ * Intel color control surfaces (CCS) for Gen-12 render compression.
+ *
+ * The main surface is Y-tiled and at plane index 0, the CCS is linear and
+ * at index 1. A 64B CCS cache line corresponds to an area of 4x1 tiles in
+ * main surface. In other words, 4 bits in CCS map to a main surface cache
+ * line pair. The main surface pitch is required to be a multiple of four
+ * Y-tile widths.
+ */
+#define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS fourcc_mod_code(INTEL, 6)
+
+/*
+ * Intel color control surfaces (CCS) for Gen-12 media compression
+ *
+ * The main surface is Y-tiled and at plane index 0, the CCS is linear and
+ * at index 1. A 64B CCS cache line corresponds to an area of 4x1 tiles in
+ * main surface. In other words, 4 bits in CCS map to a main surface cache
+ * line pair. The main surface pitch is required to be a multiple of four
+ * Y-tile widths. For semi-planar formats like NV12, CCS planes follow the
+ * Y and UV planes i.e., planes 0 and 1 are used for Y and UV surfaces,
+ * planes 2 and 3 for the respective CCS.
+ */
+#define I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS fourcc_mod_code(INTEL, 7)
+
/*
* Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
*
@@ -648,7 +672,21 @@ extern "C" {
* Further information on the use of AFBC modifiers can be found in
* Documentation/gpu/afbc.rst
*/
-#define DRM_FORMAT_MOD_ARM_AFBC(__afbc_mode) fourcc_mod_code(ARM,
__afbc_mode)
+
+/*
+ * The top 4 bits (out of the 56 bits alloted for specifying vendor specific
+ * modifiers) denote the category for modifiers. Currently we have only two
+ * categories of modifiers ie AFBC and MISC. We can have a maximum of sixteen
+ * different categories.
+ */
+#define DRM_FORMAT_MOD_ARM_CODE(__type, __val) \
+ fourcc_mod_code(ARM, ((__u64)(__type) << 52) | ((__val) &
0x000fULL))
+
+#define DRM_FORMAT_MOD_ARM_TYPE_AFBC 0x00
+#define DRM_FORMAT_MOD_ARM_TYPE_MISC 0x01
+
+#define DRM_FORMAT_MOD_ARM_AFBC(__afbc_mode) \
+ DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_TYPE_AFBC, __afbc_mode)
/*
* AFBC superblock size
@@ -742,6 +780,16 @@ extern "C" {
*/
#define AFBC_FORMAT_MOD_BCH (1ULL << 11)
+/*
+ * Arm 16x16 Block U-Interleaved modifier
+ *
+ * This is used by Arm Mali Utgard and Midgard GPUs. It divides the image
+ * into 16x16 pixel blocks. Blocks are stored linearly in order, but pixels
+ * in the block are reordered.
+ */
+#define DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED \
+ DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_TYPE_MISC, 1ULL)
+
/*
* Allwinner tiled modifier
*
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/3] drm/exynos: gem: rework scatter-list contiguity check on prime import
Explicitly check if the imported buffer has been mapped as contiguous in
the DMA address space, what is required by all Exynos DRM CRTC drivers.
While touching this, set buffer flags depending on the availability of
the IOMMU.
Signed-off-by: Marek Szyprowski
---
v2:
- reworked a check for sgt->nents
- added a comment about a scatter-list contiguity check
- removed additional 'return ERR_PTR(-EINVAL)' accidentaly left after debugging
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 42 -
1 file changed, 31 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 40514d3..f136efb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -458,6 +458,29 @@ struct drm_gem_object *
int npages;
int ret;
+ if (sgt->nents < 1)
+ return ERR_PTR(-EINVAL);
+
+ /*
+* Check if the provided buffer has been mapped as contiguous
+* into DMA address space.
+*/
+ if (sgt->nents > 1) {
+ dma_addr_t next_addr = sg_dma_address(sgt->sgl);
+ struct scatterlist *s;
+ unsigned int i;
+
+ for_each_sg(sgt->sgl, s, sgt->nents, i) {
+ if (!sg_dma_len(s))
+ break;
+ if (sg_dma_address(s) != next_addr) {
+ DRM_ERROR("buffer chunks must be mapped
contiguously");
+ return ERR_PTR(-EINVAL);
+ }
+ next_addr = sg_dma_address(s) + sg_dma_len(s);
+ }
+ }
+
exynos_gem = exynos_drm_gem_init(dev, attach->dmabuf->size);
if (IS_ERR(exynos_gem)) {
ret = PTR_ERR(exynos_gem);
@@ -480,18 +503,15 @@ struct drm_gem_object *
exynos_gem->sgt = sgt;
- if (sgt->nents == 1) {
- /* always physically continuous memory if sgt->nents is 1. */
- exynos_gem->flags |= EXYNOS_BO_CONTIG;
- } else {
- /*
-* this case could be CONTIG or NONCONTIG type but for now
-* sets NONCONTIG.
-* TODO. we have to find a way that exporter can notify
-* the type of its own buffer to importer.
-*/
+ /*
+* Buffer has been mapped as contiguous into DMA address space,
+* but if there is IOMMU, it can be either CONTIG or NONCONTIG.
+* We assume a simplified logic below:
+*/
+ if (is_drm_iommu_supported(dev))
exynos_gem->flags |= EXYNOS_BO_NONCONTIG;
- }
+ else
+ exynos_gem->flags |= EXYNOS_BO_CONTIG;
return &exynos_gem->base;
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v5, 2/3] drm/i915/dp: Attach and set drm connector VRR property
From: Aditya Swarup
From: Aditya Swarup
This function sets the VRR property for connector based
on the platform support, EDID monitor range and DP sink
DPCD capability of outputing video without msa
timing information.
v4:
* Rebase (Mansi)
v3:
* intel_dp_is_vrr_capable can be used for debugfs, make it
non static (Manasi)
v2:
* Just set this in intel_dp_get_modes instead of new hook (Jani)
Cc: Ville Syrjälä
Cc: Jani Nikula
Signed-off-by: Aditya Swarup
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_dp.c | 24
drivers/gpu/drm/i915/display/intel_dp.h | 2 ++
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 66f8a9d1503d..eda112a27e71 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6476,6 +6476,23 @@ intel_dp_force(struct drm_connector *connector)
intel_display_power_put(dev_priv, aux_domain, wakeref);
}
+bool intel_dp_is_vrr_capable(struct drm_connector *connector)
+{
+ struct intel_dp *intel_dp =
intel_attached_dp(to_intel_connector(connector));
+ const struct drm_display_info *info = &connector->display_info;
+ struct drm_i915_private *dev_priv = to_i915(connector->dev);
+
+ /*
+* DP Sink is capable of Variable refresh video timings if
+* Ignore MSA bit is set in DPCD.
+* EDID monitor range also should be atleast 10 for reasonable
+* Adaptive sync/ VRR end user experience.
+*/
+ return INTEL_GEN(dev_priv) >= 12 &&
+ drm_dp_sink_can_do_video_without_timing_msa(intel_dp->dpcd) &&
+ info->monitor_range.max_vfreq - info->monitor_range.min_vfreq >
10;
+}
+
static int intel_dp_get_modes(struct drm_connector *connector)
{
struct intel_connector *intel_connector = to_intel_connector(connector);
@@ -6486,6 +6503,10 @@ static int intel_dp_get_modes(struct drm_connector
*connector)
int ret = intel_connector_update_modes(connector, edid);
if (ret)
return ret;
+
+ if (intel_dp_is_vrr_capable(connector))
+ drm_connector_set_vrr_capable_property(connector,
+ true);
}
/* if eDP has no EDID, fall back to fixed mode */
@@ -7570,6 +7591,9 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct
drm_connector *connect
connector->state->scaling_mode = DRM_MODE_SCALE_ASPECT;
}
+
+ if (INTEL_GEN(dev_priv) >= 12)
+ drm_connector_attach_vrr_capable_property(connector);
}
static void intel_dp_init_panel_power_timestamps(struct intel_dp *intel_dp)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
b/drivers/gpu/drm/i915/display/intel_dp.h
index 6659ce15a693..aa7c1f530d5e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -14,6 +14,7 @@ enum pipe;
enum port;
struct drm_connector_state;
struct drm_encoder;
+struct drm_connector;
struct drm_i915_private;
struct drm_modeset_acquire_ctx;
struct intel_connector;
@@ -119,6 +120,7 @@ void intel_dp_set_infoframes(struct intel_encoder *encoder,
bool enable,
const struct drm_connector_state *conn_state);
bool intel_digital_port_connected(struct intel_encoder *encoder);
void intel_dp_process_phy_request(struct intel_dp *intel_dp);
+bool intel_dp_is_vrr_capable(struct drm_connector *connector);
static inline unsigned int intel_dp_unused_lane_mask(int lane_count)
{
--
2.24.1.1.gb6d4d82bd5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v5, 1/3] drm/dp: DRM DP helper for reading Ignore MSA from DPCD
From: Manasi Navare
From: Manasi Navare
DP sink device sets the Ignore MSA bit in its
DP_DOWNSTREAM_PORT_COUNT register to indicate its ability to
ignore the MSA video timing parameters and its ability to support
seamless video timing change over a range of timing exposed by
DisplayID and EDID.
This is required for the sink to indicate that it is Adaptive sync
capable.
v3:
* Fi the typo in commit message (Manasi)
v2:
* Rename to describe what the function does (Jani Nikula)
Cc: Jani Nikula
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
Signed-off-by: Manasi Navare
Reviewed-by: Harry Wentland
---
include/drm/drm_dp_helper.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 3beb2aac8c4c..87264b561632 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1454,6 +1454,14 @@ drm_dp_alternate_scrambler_reset_cap(const u8
dpcd[DP_RECEIVER_CAP_SIZE])
DP_ALTERNATE_SCRAMBLER_RESET_CAP;
}
+/* Ignore MSA timing for Adaptive Sync support on DP 1.4 */
+static inline bool
+drm_dp_sink_can_do_video_without_timing_msa(const u8
dpcd[DP_RECEIVER_CAP_SIZE])
+{
+ return dpcd[DP_DOWN_STREAM_PORT_COUNT] &
+ DP_MSA_TIMING_PAR_IGNORED;
+}
+
/*
* DisplayPort AUX channel
*/
--
2.24.1.1.gb6d4d82bd5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v5, 3/3] drm/i915/dp: Expose connector VRR info via debugfs
From: Bhanuprakash Modem
[Why]
It's useful to know the min and max vrr range for IGT testing.
[How]
Expose the min and max vfreq for the connector via a debugfs file
on the connector, "vrr_range".
Example usage: cat /sys/kernel/debug/dri/0/DP-1/vrr_range
v4:
* Rebase (Bhanu)
* Remove "Vrr_capable", userspace can read this property
through DRM_IOCTL_MODE_OBJ_GETPROPERTIES (Bhanu)
* Change the name of the node to "vrr_range", so we can avoid code
churn in IGT to reuse existing VRR tests (Bhanu)
v3:
* Remove the unnecessary debug print (Manasi)
v2:
* Fix the typo in max_vfreq (Manasi)
* Change the name of node to i915_vrr_info so we can add
other vrr info for more debug info (Manasi)
* Change the VRR capable to display Yes or No (Manasi)
* Fix indentation checkpatch errors (Manasi)
Signed-off-by: Bhanuprakash Modem
Signed-off-by: Manasi Navare
Cc: Jani Nikula
Cc: Ville Syrjälä
Tested-by: Manasi Navare
---
.../drm/i915/display/intel_display_debugfs.c | 21 ++-
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 70525623bcdf..d53ffe600ced 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -2185,6 +2185,20 @@ static const struct file_operations
i915_dsc_fec_support_fops = {
.write = i915_dsc_fec_support_write
};
+static int vrr_range_show(struct seq_file *m, void *data)
+{
+ struct drm_connector *connector = m->private;
+
+ if (connector->status != connector_status_connected)
+ return -ENODEV;
+
+ seq_printf(m, "Min: %u\n",
(u8)connector->display_info.monitor_range.min_vfreq);
+ seq_printf(m, "Max: %u\n",
(u8)connector->display_info.monitor_range.max_vfreq);
+
+ return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(vrr_range);
+
/**
* intel_connector_debugfs_add - add i915 specific connector debugfs files
* @connector: pointer to a registered drm_connector
@@ -2219,10 +2233,15 @@ int intel_connector_debugfs_add(struct drm_connector
*connector)
if (INTEL_GEN(dev_priv) >= 10 &&
(connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
-connector->connector_type == DRM_MODE_CONNECTOR_eDP))
+connector->connector_type == DRM_MODE_CONNECTOR_eDP)) {
debugfs_create_file("i915_dsc_fec_support", S_IRUGO, root,
connector, &i915_dsc_fec_support_fops);
+ if (INTEL_GEN(dev_priv) >= 12)
+ debugfs_create_file("vrr_range", S_IRUGO, root,
+ connector, &vrr_range_fops);
+ }
+
/* Legacy panels doesn't lpsp on any platform */
if ((INTEL_GEN(dev_priv) >= 9 || IS_HASWELL(dev_priv) ||
IS_BROADWELL(dev_priv)) &&
--
2.24.1.1.gb6d4d82bd5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: drm_fourcc: Add uncompressed AFBC modifier
AFBC has a mode that allows use of AFBC with an uncompressed buffer,
we add a new modifier to support this mode.
Signed-off-by: Ben Davis
---
include/uapi/drm/drm_fourcc.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 8bc0b31597d8..97c47baef7fc 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -780,6 +780,12 @@ extern "C" {
*/
#define AFBC_FORMAT_MOD_BCH (1ULL << 11)
+/* AFBC uncompressed storage mode
+ *
+ * Indicates that the buffer is using uncompressed AFBC mode.
+ */
+#define AFBC_FORMAT_MOD_USM(1ULL << 12)
+
/*
* Arm 16x16 Block U-Interleaved modifier
*
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: drm_fourcc: add NV15, Q410, Q401 YUV formats
DRM_FORMAT_NV15 is a 2 plane format suitable for linear and 16x16
block-linear memory layouts. The format is similar to P010 with 4:2:0
sub-sampling but has no padding between components. Instead, luminance
and chrominance samples are grouped into 4s so that each group is packed
into an integer number of bytes:
= UVUV = 4 * 10 bits = 40 bits = 5 bytes
The '15' suffix refers to the optimum effective bits per pixel which is
achieved when the total number of luminance samples is a multiple of 8.
Q410 and Q401 are both 3 plane non-subsampled formats with 16 bits per
component, but only 10 bits are used and 6 are padded. 'Q' is chosen
as the first letter to denote 3 plane YUV444, (and is the next letter
along from P which is usually 2 plane).
Signed-off-by: Ben Davis
---
drivers/gpu/drm/drm_fourcc.c | 12
include/uapi/drm/drm_fourcc.h | 24
2 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index b234bfaeda06..0c0a65481afd 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -274,6 +274,18 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_YUV420_10BIT,.depth = 0,
.num_planes = 1, .cpp = { 0, 0, 0 }, .hsub = 2, .vsub = 2,
.is_yuv = true },
+ { .format = DRM_FORMAT_NV15,.depth = 0,
+ .num_planes = 2, .char_per_block = { 5, 5, 0 },
+ .block_w = { 4, 4, 0 }, .block_h = { 1, 1, 0 }, .hsub = 2,
+ .vsub = 2, .is_yuv = true },
+ { .format = DRM_FORMAT_Q410,.depth = 0,
+ .num_planes = 3, .char_per_block = { 2, 2, 2 },
+ .block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 0,
+ .vsub = 0, .is_yuv = true },
+ { .format = DRM_FORMAT_Q401,.depth = 0,
+ .num_planes = 3, .char_per_block = { 2, 2, 2 },
+ .block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 0,
+ .vsub = 0, .is_yuv = true },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 8bc0b31597d8..232b9ad3534d 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -236,6 +236,12 @@ extern "C" {
#define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /* 2x1
subsampled Cb:Cr plane */
#define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /*
non-subsampled Cr:Cb plane */
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
+/*
+ * 2 plane YCbCr
+ * index 0 = Y plane, [39:0] Y3:Y2:Y1:Y0 little endian
+ * index 1 = Cr:Cb plane, [39:0] Cr1:Cb1:Cr0:Cb0 little endian
+ */
+#define DRM_FORMAT_NV15fourcc_code('N', 'V', '1', '5') /* 2x2
subsampled Cr:Cb plane */
/*
* 2 plane YCbCr MSB aligned
@@ -265,6 +271,24 @@ extern "C" {
*/
#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2
subsampled Cr:Cb plane 16 bits per channel */
+
+/* 3 plane non-subsampled (444) YCbCr
+ * 16 bits per component, but only 10 bits are used and 6 bits are padded
+ * index 0: Y plane, [15:0] Y:x [10:6] little endian
+ * index 1: Cb plane, [15:0] Cb:x [10:6] little endian
+ * index 2: Cr plane, [15:0] Cr:x [10:6] little endian
+ */
+#define DRM_FORMAT_Q410fourcc_code('Q', '4', '1', '0')
+
+/* 3 plane non-subsampled (444) YCrCb
+ * 16 bits per component, but only 10 bits are used and 6 bits are padded
+ * index 0: Y plane, [15:0] Y:x [10:6] little endian
+ * index 1: Cr plane, [15:0] Cr:x [10:6] little endian
+ * index 2: Cb plane, [15:0] Cb:x [10:6] little endian
+ */
+#define DRM_FORMAT_Q401fourcc_code('Q', '4', '0', '1')
+
+
/*
* 3 plane YCbCr
* index 0: Y plane, [7:0] Y
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5.6 108/166] drm/nouveau: workaround runpm fail by disabling PCI power management on certain intel bridges
From: Karol Herbst
[ Upstream commit 434fdb51513bf3057ac144d152e6f2f2b509e857 ]
Fixes the infamous 'runtime PM' bug many users are facing on Laptops with
Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU.
Depending on the used kernel there might be messages like those in demsg:
"nouveau :01:00.0: Refused to change power state, currently in D3"
"nouveau :01:00.0: can't change power state from D3cold to D0 (config
space inaccessible)"
followed by backtraces of kernel crashes or timeouts within nouveau.
It's still unkown why this issue exists, but this is a reliable workaround
and solves a very annoying issue for user having to choose between a
crashing kernel or higher power consumption of their Laptops.
Signed-off-by: Karol Herbst
Cc: Bjorn Helgaas
Cc: Lyude Paul
Cc: Rafael J. Wysocki
Cc: Mika Westerberg
Cc: linux-...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205623
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 63 +++
drivers/gpu/drm/nouveau/nouveau_drv.h | 2 +
2 files changed, 65 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index b65ae817eabf5..2d4c899e1f8b9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -618,6 +618,64 @@ nouveau_drm_device_fini(struct drm_device *dev)
kfree(drm);
}
+/*
+ * On some Intel PCIe bridge controllers doing a
+ * D0 -> D3hot -> D3cold -> D0 sequence causes Nvidia GPUs to not reappear.
+ * Skipping the intermediate D3hot step seems to make it work again. This is
+ * probably caused by not meeting the expectation the involved AML code has
+ * when the GPU is put into D3hot state before invoking it.
+ *
+ * This leads to various manifestations of this issue:
+ * - AML code execution to power on the GPU hits an infinite loop (as the
+ *code waits on device memory to change).
+ * - kernel crashes, as all PCI reads return -1, which most code isn't able
+ *to handle well enough.
+ *
+ * In all cases dmesg will contain at least one line like this:
+ * 'nouveau :01:00.0: Refused to change power state, currently in D3'
+ * followed by a lot of nouveau timeouts.
+ *
+ * In the \_SB.PCI0.PEG0.PG00._OFF code deeper down writes bit 0x80 to the not
+ * documented PCI config space register 0x248 of the Intel PCIe bridge
+ * controller (0x1901) in order to change the state of the PCIe link between
+ * the PCIe port and the GPU. There are alternative code paths using other
+ * registers, which seem to work fine (executed pre Windows 8):
+ * - 0xbc bit 0x20 (publicly available documentation claims 'reserved')
+ * - 0xb0 bit 0x10 (link disable)
+ * Changing the conditions inside the firmware by poking into the relevant
+ * addresses does resolve the issue, but it seemed to be ACPI private memory
+ * and not any device accessible memory at all, so there is no portable way of
+ * changing the conditions.
+ * On a XPS 9560 that means bits [0,3] on \CPEX need to be cleared.
+ *
+ * The only systems where this behavior can be seen are hybrid graphics laptops
+ * with a secondary Nvidia Maxwell, Pascal or Turing GPU. It's unclear whether
+ * this issue only occurs in combination with listed Intel PCIe bridge
+ * controllers and the mentioned GPUs or other devices as well.
+ *
+ * documentation on the PCIe bridge controller can be found in the
+ * "7th Generation Intel® Processor Families for H Platforms Datasheet Volume
2"
+ * Section "12 PCI Express* Controller (x16) Registers"
+ */
+
+static void quirk_broken_nv_runpm(struct pci_dev *pdev)
+{
+ struct drm_device *dev = pci_get_drvdata(pdev);
+ struct nouveau_drm *drm = nouveau_drm(dev);
+ struct pci_dev *bridge = pci_upstream_bridge(pdev);
+
+ if (!bridge || bridge->vendor != PCI_VENDOR_ID_INTEL)
+ return;
+
+ switch (bridge->device) {
+ case 0x1901:
+ drm->old_pm_cap = pdev->pm_cap;
+ pdev->pm_cap = 0;
+ NV_INFO(drm, "Disabling PCI power management to avoid bug\n");
+ break;
+ }
+}
+
static int nouveau_drm_probe(struct pci_dev *pdev,
const struct pci_device_id *pent)
{
@@ -699,6 +757,7 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
if (ret)
goto fail_drm_dev_init;
+ quirk_broken_nv_runpm(pdev);
return 0;
fail_drm_dev_init:
@@ -734,7 +793,11 @@ static void
nouveau_drm_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
+ struct nouveau_drm *drm = nouveau_drm(dev);
+ /* revert our workaround */
+ if (drm->old_pm_cap)
+ pdev->pm_cap = drm->old_pm_cap;
nouveau_drm_device_remove(dev);
pci_disable_dev
[PATCH 5.4 076/118] drm/nouveau: workaround runpm fail by disabling PCI power management on certain intel bridges
From: Karol Herbst
[ Upstream commit 434fdb51513bf3057ac144d152e6f2f2b509e857 ]
Fixes the infamous 'runtime PM' bug many users are facing on Laptops with
Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU.
Depending on the used kernel there might be messages like those in demsg:
"nouveau :01:00.0: Refused to change power state, currently in D3"
"nouveau :01:00.0: can't change power state from D3cold to D0 (config
space inaccessible)"
followed by backtraces of kernel crashes or timeouts within nouveau.
It's still unkown why this issue exists, but this is a reliable workaround
and solves a very annoying issue for user having to choose between a
crashing kernel or higher power consumption of their Laptops.
Signed-off-by: Karol Herbst
Cc: Bjorn Helgaas
Cc: Lyude Paul
Cc: Rafael J. Wysocki
Cc: Mika Westerberg
Cc: linux-...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205623
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 63 +++
drivers/gpu/drm/nouveau/nouveau_drv.h | 2 +
2 files changed, 65 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 2cd83849600f3..b1beed40e746a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -618,6 +618,64 @@ nouveau_drm_device_fini(struct drm_device *dev)
kfree(drm);
}
+/*
+ * On some Intel PCIe bridge controllers doing a
+ * D0 -> D3hot -> D3cold -> D0 sequence causes Nvidia GPUs to not reappear.
+ * Skipping the intermediate D3hot step seems to make it work again. This is
+ * probably caused by not meeting the expectation the involved AML code has
+ * when the GPU is put into D3hot state before invoking it.
+ *
+ * This leads to various manifestations of this issue:
+ * - AML code execution to power on the GPU hits an infinite loop (as the
+ *code waits on device memory to change).
+ * - kernel crashes, as all PCI reads return -1, which most code isn't able
+ *to handle well enough.
+ *
+ * In all cases dmesg will contain at least one line like this:
+ * 'nouveau :01:00.0: Refused to change power state, currently in D3'
+ * followed by a lot of nouveau timeouts.
+ *
+ * In the \_SB.PCI0.PEG0.PG00._OFF code deeper down writes bit 0x80 to the not
+ * documented PCI config space register 0x248 of the Intel PCIe bridge
+ * controller (0x1901) in order to change the state of the PCIe link between
+ * the PCIe port and the GPU. There are alternative code paths using other
+ * registers, which seem to work fine (executed pre Windows 8):
+ * - 0xbc bit 0x20 (publicly available documentation claims 'reserved')
+ * - 0xb0 bit 0x10 (link disable)
+ * Changing the conditions inside the firmware by poking into the relevant
+ * addresses does resolve the issue, but it seemed to be ACPI private memory
+ * and not any device accessible memory at all, so there is no portable way of
+ * changing the conditions.
+ * On a XPS 9560 that means bits [0,3] on \CPEX need to be cleared.
+ *
+ * The only systems where this behavior can be seen are hybrid graphics laptops
+ * with a secondary Nvidia Maxwell, Pascal or Turing GPU. It's unclear whether
+ * this issue only occurs in combination with listed Intel PCIe bridge
+ * controllers and the mentioned GPUs or other devices as well.
+ *
+ * documentation on the PCIe bridge controller can be found in the
+ * "7th Generation Intel® Processor Families for H Platforms Datasheet Volume
2"
+ * Section "12 PCI Express* Controller (x16) Registers"
+ */
+
+static void quirk_broken_nv_runpm(struct pci_dev *pdev)
+{
+ struct drm_device *dev = pci_get_drvdata(pdev);
+ struct nouveau_drm *drm = nouveau_drm(dev);
+ struct pci_dev *bridge = pci_upstream_bridge(pdev);
+
+ if (!bridge || bridge->vendor != PCI_VENDOR_ID_INTEL)
+ return;
+
+ switch (bridge->device) {
+ case 0x1901:
+ drm->old_pm_cap = pdev->pm_cap;
+ pdev->pm_cap = 0;
+ NV_INFO(drm, "Disabling PCI power management to avoid bug\n");
+ break;
+ }
+}
+
static int nouveau_drm_probe(struct pci_dev *pdev,
const struct pci_device_id *pent)
{
@@ -699,6 +757,7 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
if (ret)
goto fail_drm_dev_init;
+ quirk_broken_nv_runpm(pdev);
return 0;
fail_drm_dev_init:
@@ -736,7 +795,11 @@ static void
nouveau_drm_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
+ struct nouveau_drm *drm = nouveau_drm(dev);
+ /* revert our workaround */
+ if (drm->old_pm_cap)
+ pdev->pm_cap = drm->old_pm_cap;
nouveau_drm_device_remove(dev);
}
diff --git a/drive
Re: [PATCH v7 5/8] dt-bindings: display: add i.MX6 MIPI DSI host controller doc
On Wed, 22 Apr 2020, Laurent Pinchart wrote: Hi Adrian, Hi Laurent, On Wed, Apr 22, 2020 at 03:58:33AM +0300, Laurent Pinchart wrote: On Tue, Apr 21, 2020 at 07:16:07PM +0300, Adrian Ratiu wrote: > This provides an example DT binding for the MIPI DSI host > controller present on the i.MX6 SoC based on Synopsis > DesignWare v1.01 IP. Cc: Rob Herring Cc: > Neil Armstrong Cc: Fabio Estevam > Cc: Laurent Pinchart > Cc: > devicet...@vger.kernel.org Tested-by: Adrian Pop > Tested-by: Arnaud Ferraris > Signed-off-by: Sjoerd Simons > Signed-off-by: Martyn Welch > Signed-off-by: Adrian Ratiu > --- Changes since v6: > - Added ref to the newly created snps,dw-mipi-dsi.yaml > (Laurent) - Moved *-cells properties outside > patternProperties (Laurent) - Removed the panel port > documentation (Laurent) - Wrapped lines at 80 chars, typo > fixes, sort includes (Laurent) > Changes since v5: > - Fixed missing reg warning (Fabio) - Updated dt-schema and > fixed warnings (Rob) > Changes since v4: > - Fixed yaml binding to pass `make dt_binding_check > dtbs_check` and addressed received binding feedback (Rob) > Changes since v3: > - Added commit message (Neil) - Converted to yaml format > (Neil) - Minor dt node + driver fixes (Rob) - Added small > panel example to the host controller binding > Changes since v2: > - Fixed commit tags (Emil) > --- > .../display/imx/fsl,mipi-dsi-imx6.yaml| 135 > ++ 1 file changed, 135 insertions(+) create > mode 100644 > Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml > diff --git > a/Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml > b/Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml > new file mode 100644 index 0..b73e3ae33a852 --- > /dev/null +++ > b/Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml > @@ -0,0 +1,135 @@ +# SPDX-License-Identifier: (GPL-2.0-only > OR BSD-2-Clause) +%YAML 1.2 +--- +$id: > http://devicetree.org/schemas/display/imx/fsl,mipi-dsi-imx6.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# + > +title: Freescale i.MX6 DW MIPI DSI Host Controller + > +maintainers: + - Adrian Ratiu > + +description: | + The i.MX6 DSI host controller is a > Synopsys DesignWare MIPI DSI v1.01 + IP block with a > companion PHY IP. I forgot to mention, if there's a companion PHY, shouldn't it be referenced from the DT bindings ? I don't think so, that description was copied verbatim from the imx6 ref manual IIRC, the physical layer is the same for MIPI DSI which does TX as for MIPI CSI which does RX, but looking at the ref manual and how drivers are written I don't think it's necessary. This might change if we wanted to unify the DSI and CSI drivers a bit, but considering the scope already associated with this patch series I'm a bit afraid to open a subject like that =) > + > + These DT bindings follow the Synopsys DW MIPI DSI bindings defined in > + Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt with > + the following device-specific properties. > + > +allOf: > + - $ref: ../bridge/snps,dw-mipi-dsi.yaml# > + > +properties: > + '#address-cells': > +const: 1 > + > + '#size-cells': > +const: 0 > + > + compatible: > +items: > + - const: fsl,imx6q-mipi-dsi > + - const: snps,dw-mipi-dsi > + > + reg: > +maxItems: 1 > + > + interrupts: > +maxItems: 1 > + > + clocks: > +items: > + - description: Module Clock > + - description: DSI bus clock > + > + clock-names: > +items: > + - const: ref > + - const: pclk > + > + fsl,gpr: > +description: > + Phandle to the iomuxc-gpr region containing the multiplexer ctrl register. > +$ref: /schemas/types.yaml#/definitions/phandle > + > + ports: > +type: object > +description: | > + A node containing DSI input & output port nodes with endpoint > + definitions as documented in > + Documentation/devicetree/bindings/media/video-interfaces.txt > + Documentation/devicetree/bindings/graph.txt > +properties: > + port@0: > +type: object > +description: > + DSI input port node, connected to the ltdc rgb output port. > + > + port@1: > +type: object > +description: > + RGB output port node, connected to a panel or a bridge input port. Isn't it the other way around, doesn't the bridge take RGB input and output DSI ? And to be precise, it's not about RGB, but about the input being parallel interface (DSI will also carry RGB). I would add required: - port@0 - port@1 > + > +additionalProperties: false > + > +patternProperties: > + "^panel@[0-3]$": > +type: object > + > +required: > + - "#address-cells" > + - "#size-cells" > + - compatible > + - reg > + - interrupts > + - clocks > + - clock-names > + - ports > +
[PATCH libdrm] include/drm: sync up drm_fourcc.h
From: Binu R S
a) Adds new format modifiers for Format modifier for Intel Gen-12
- I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS
- I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS
b) Generated using make headers_install
c) Taken from drm-next
Signed-off-by: Binu R S
---
include/drm/drm_fourcc.h | 54 +---
1 file changed, 51 insertions(+), 3 deletions(-)
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index 5c69090d505a..8bc0b31597d8 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -69,7 +69,7 @@ extern "C" {
#define fourcc_code(a, b, c, d) ((__u32)(a) | ((__u32)(b) << 8) | \
((__u32)(c) << 16) | ((__u32)(d) << 24))
-#define DRM_FORMAT_BIG_ENDIAN (1<<31) /* format is big endian instead of
little endian */
+#define DRM_FORMAT_BIG_ENDIAN (1U<<31) /* format is big endian instead of
little endian */
/* Reserve 0 for the invalid format specifier */
#define DRM_FORMAT_INVALID 0
@@ -381,7 +381,7 @@ extern "C" {
* This is a tiled layout using 4Kb tiles in row-major layout.
* Within the tile pixels are laid out in 16 256 byte units / sub-tiles which
* are arranged in four groups (two wide, two high) with column-major layout.
- * Each group therefore consists out of four 256 byte units, which are also
laid
+ * Each group therefore consits out of four 256 byte units, which are also laid
* out as 2x2 column-major.
* 256 byte units are made out of four 64 byte blocks of pixels, producing
* either a square block or a 2:1 unit.
@@ -410,6 +410,30 @@ extern "C" {
#define I915_FORMAT_MOD_Y_TILED_CCSfourcc_mod_code(INTEL, 4)
#define I915_FORMAT_MOD_Yf_TILED_CCS fourcc_mod_code(INTEL, 5)
+/*
+ * Intel color control surfaces (CCS) for Gen-12 render compression.
+ *
+ * The main surface is Y-tiled and at plane index 0, the CCS is linear and
+ * at index 1. A 64B CCS cache line corresponds to an area of 4x1 tiles in
+ * main surface. In other words, 4 bits in CCS map to a main surface cache
+ * line pair. The main surface pitch is required to be a multiple of four
+ * Y-tile widths.
+ */
+#define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS fourcc_mod_code(INTEL, 6)
+
+/*
+ * Intel color control surfaces (CCS) for Gen-12 media compression
+ *
+ * The main surface is Y-tiled and at plane index 0, the CCS is linear and
+ * at index 1. A 64B CCS cache line corresponds to an area of 4x1 tiles in
+ * main surface. In other words, 4 bits in CCS map to a main surface cache
+ * line pair. The main surface pitch is required to be a multiple of four
+ * Y-tile widths. For semi-planar formats like NV12, CCS planes follow the
+ * Y and UV planes i.e., planes 0 and 1 are used for Y and UV surfaces,
+ * planes 2 and 3 for the respective CCS.
+ */
+#define I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS fourcc_mod_code(INTEL, 7)
+
/*
* Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
*
@@ -648,7 +672,21 @@ extern "C" {
* Further information on the use of AFBC modifiers can be found in
* Documentation/gpu/afbc.rst
*/
-#define DRM_FORMAT_MOD_ARM_AFBC(__afbc_mode) fourcc_mod_code(ARM,
__afbc_mode)
+
+/*
+ * The top 4 bits (out of the 56 bits alloted for specifying vendor specific
+ * modifiers) denote the category for modifiers. Currently we have only two
+ * categories of modifiers ie AFBC and MISC. We can have a maximum of sixteen
+ * different categories.
+ */
+#define DRM_FORMAT_MOD_ARM_CODE(__type, __val) \
+ fourcc_mod_code(ARM, ((__u64)(__type) << 52) | ((__val) &
0x000fULL))
+
+#define DRM_FORMAT_MOD_ARM_TYPE_AFBC 0x00
+#define DRM_FORMAT_MOD_ARM_TYPE_MISC 0x01
+
+#define DRM_FORMAT_MOD_ARM_AFBC(__afbc_mode) \
+ DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_TYPE_AFBC, __afbc_mode)
/*
* AFBC superblock size
@@ -742,6 +780,16 @@ extern "C" {
*/
#define AFBC_FORMAT_MOD_BCH (1ULL << 11)
+/*
+ * Arm 16x16 Block U-Interleaved modifier
+ *
+ * This is used by Arm Mali Utgard and Midgard GPUs. It divides the image
+ * into 16x16 pixel blocks. Blocks are stored linearly in order, but pixels
+ * in the block are reordered.
+ */
+#define DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED \
+ DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_TYPE_MISC, 1ULL)
+
/*
* Allwinner tiled modifier
*
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 4/8] drm: imx: Add i.MX 6 MIPI DSI host platform driver
On Wed, 22 Apr 2020, Laurent Pinchart
wrote:
Hi Adrian,
Hi Laurent,
On Tue, Apr 21, 2020 at 07:16:06PM +0300, Adrian Ratiu wrote:
This adds support for the Synopsis DesignWare MIPI DSI v1.01
host controller which is embedded in i.MX 6 SoCs. Based on
following patches, but updated/extended to work with existing
support found in the kernel: - drm: imx: Support Synopsys
DesignWare MIPI DSI host controller
Signed-off-by: Liu Ying
Cc: Fabio Estevam Cc: Enric Balletbo
Serra Reviewed-by: Emil Velikov
Tested-by: Adrian Pop
Tested-by: Arnaud Ferraris
Signed-off-by: Sjoerd Simons
Signed-off-by: Martyn Welch
Signed-off-by: Adrian Ratiu
--- Changes since v6:
- Replaced custom noop encoder with the simple drm encoder
(Enric) - Added CONFIG_DRM_IMX6_MIPI_DSI depends on CONFIG_OF
(Enric) - Dropped imx_mipi_dsi_register() because now it only
creates the dummy encoder which can easily be done directly
in imx_dsi_bind()
Changes since v5:
- Reword to remove unrelated device tree patch mention
(Fabio) - Move pllref_clk enable/disable to bind/unbind
(Ezequiel) - Fix freescale.com -> nxp.com email addresses
(Fabio) - Also added myself as module author (Fabio) - Use
DRM_DEV_* macros for consistency, print more error msg
Changes since v4:
- Split off driver-specific configuration of phy timings due
to new upstream API. - Move regmap infrastructure logic to
separate commit (Ezequiel) - Move dsi v1.01 layout addition
to a separate commit (Ezequiel) - Minor warnings and driver
name fixes
Changes since v3:
- Renamed platform driver to reflect it's i.MX6 only. (Fabio)
Changes since v2:
- Fixed commit tags. (Emil)
Changes since v1:
- Moved register definitions & regmap initialization into
bridge module. Platform drivers get the regmap via plat_data
after calling the bridge probe. (Emil)
---
drivers/gpu/drm/imx/Kconfig| 8 +
drivers/gpu/drm/imx/Makefile | 1 +
drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c | 391
+ 3 files changed, 400 insertions(+)
create mode 100644 drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c
diff --git a/drivers/gpu/drm/imx/Kconfig
b/drivers/gpu/drm/imx/Kconfig index
207bf7409dfba..0dffc72df7922 100644 ---
a/drivers/gpu/drm/imx/Kconfig +++ b/drivers/gpu/drm/imx/Kconfig
@@ -39,3 +39,11 @@ config DRM_IMX_HDMI
depends on DRM_IMX help Choose this if you want to use
HDMI on i.MX6.
+ +config DRM_IMX6_MIPI_DSI + tristate "Freescale i.MX6
DRM MIPI DSI" + select DRM_DW_MIPI_DSI + depends on
DRM_IMX + depends on OF + help + Choose this if you want
to use MIPI DSI on i.MX6. diff --git
a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile
index 21cdcc2faabc8..9a7843c593478 100644 ---
a/drivers/gpu/drm/imx/Makefile +++
b/drivers/gpu/drm/imx/Makefile @@ -9,3 +9,4 @@
obj-$(CONFIG_DRM_IMX_TVE) += imx-tve.o
obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o
obj-$(CONFIG_DRM_IMX_HDMI) += dw_hdmi-imx.o
+obj-$(CONFIG_DRM_IMX6_MIPI_DSI) += dw_mipi_dsi-imx6.o diff
--git a/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c
b/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c new file mode 100644
index 0..f8a0a4fe16e21 --- /dev/null +++
b/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c @@ -0,0 +1,391 @@ +//
SPDX-License-Identifier: GPL-2.0+ +/* + * i.MX6 drm driver -
MIPI DSI Host Controller + * + * Copyright (C) 2011-2015
Freescale Semiconductor, Inc. + * Copyright (C) 2019-2020
Collabora, Ltd. + */ + +#include +#include
+#include +#include
+#include
+#include +#include
+#include +#include
+#include
+#include +#include
+#include + +#include "imx-drm.h" + +#define
DSI_PWR_UP 0x04 +#define RESET
0 +#define POWERUPBIT(0) + +#define
DSI_PHY_IF_CTRL 0x5c +#define
PHY_IF_CTRL_RESET 0x0 + +#define DSI_PHY_TST_CTRL0
0x64 +#define PHY_TESTCLK BIT(1) +#define
PHY_UNTESTCLK 0 +#define PHY_TESTCLR
BIT(0) +#define PHY_UNTESTCLR 0 +
+#define DSI_PHY_TST_CTRL1 0x68 +#define PHY_TESTEN
BIT(16) +#define PHY_UNTESTEN 0 +#define
PHY_TESTDOUT(n) (((n) & 0xff) << 8)
+#define PHY_TESTDIN(n) (((n) & 0xff) <<
0) + +struct imx_mipi_dsi { + struct drm_encoder
encoder; + struct device *dev; + struct regmap *mux_sel; +
struct dw_mipi_dsi *mipi_dsi; + struct clk *pllref_clk; +
+ void __iomem *base; + unsigned int lane_mbps; +}; +
+struct dphy_pll_testdin_map { + unsigned int max_mbps; +
u8 testdin; +}; + +/* The table is based on 27MHz DPHY pll
reference clock. */ +static const struct dphy_pll_testdin_map
dptdin_map[] = { + {160, 0x04}, {180, 0x24}, {200, 0x44},
{210, 0x06}, + {240, 0x26}, {250, 0x46}, {270, 0x08},
{300, 0x28}, + {330, 0x48}, {360, 0x2a}, {400, 0x4a},
{450, 0x0c}, + {500, 0x2c}, {550, 0x0e}, {600, 0x2e},
{650, 0x10}, + {700, 0x30}, {750, 0x12}, {800, 0x32},
{850, 0x14}, + {900, 0x34}, {950, 0x54}, {1000, 0x74} +};
+ +static inline struct imx_mipi_dsi *enc_to_dsi(struct
drm_encoder *enc) +{ + return container_of(enc, struc
Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64
On Tue, Apr 21, 2020 at 07:57:12PM -0700, Guru Das Srinagesh wrote: > [REQUEST] > > Would it be possible for the patches that have already received Acked-by's in > this series to be accepted and applied to the tree? I lost an Acked-by (in > intel-panel.c) because it had a merge conflict with a new change that came in > after I rebased to tip. I wasn't sure earlier about accepting single patches > as > opposed to the entire series en masse, but this event has got me thinking. Has there been a positive maintainer review of patch 11 at any point in the thread (most of the people you are asking to commit patches have not been able to see the discussion about the actual feature these patches are preparing for)? Daniel. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv3 4/4] backlight: led_bl: fix led -> backlight brightness mapping
On Wed, Apr 22, 2020 at 09:51:14AM +0300, Tomi Valkeinen wrote: > The code that maps the LED default brightness to backlight levels has > two issues: 1) if the default brightness is the first backlight level > (usually 0), the code fails to find it, and 2) when the code fails to > find a backlight level, it ends up using max_brightness + 1 as the > default brightness. > > Fix these two issues. > > Signed-off-by: Tomi Valkeinen Reviewed-by: Daniel Thompson Daniel. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/exynos: gem: Rework scatter-list contiguity check on Prime import
Hi Inki,
On 22.04.2020 06:36, Inki Dae wrote:
> 20. 4. 22. 오후 12:37에 Inki Dae 이(가) 쓴 글:
>> 20. 4. 21. 오후 5:09에 Marek Szyprowski 이(가) 쓴 글:
>>> On 21.04.2020 09:38, Inki Dae wrote:
20. 4. 7. 오후 10:42에 Marek Szyprowski 이(가) 쓴 글:
> Explicitly check if the imported buffer has been mapped as contiguous in
> the DMA address space, what is required by all Exynos DRM CRTC drivers.
> While touching this, set buffer flags depending on the availability of
> the IOMMU.
>
> Signed-off-by: Marek Szyprowski
> ---
>drivers/gpu/drm/exynos/exynos_drm_gem.c | 36 +
>1 file changed, 25 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index 40514d3dcf60..9d4e4d321bda 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -458,6 +458,23 @@ exynos_drm_gem_prime_import_sg_table(struct
> drm_device *dev,
> int npages;
> int ret;
>
(Optional) could you leave one comment here?
i.e., /* Check if DMA memory region from a exporter are mapped
contiguously or not. */
>>> Okay.
>>>
> + if (sgt->nents != 1) {
How about using below condition instead?
if (sgt->nents > 0) {
>>> This is not the same. My check for != 1 is intended. Checking contiguity
>>> of the scatterlist if it has only 1 element doesn't have much sense.
>> Oops sorry. My intention was 'if (sgt->nents > 1)' because if (sgt->nents !=
>> 1) allows
>> - sgt->nents < 1
>> - sgt->nents > 1
>>
>> I think the checking would be valid only in case of having multiple entries
>> - sgt->nents > 1.
Okay, I can change the check to sgt->nents > 1.
> + dma_addr_t next_addr = sg_dma_address(sgt->sgl);
> + struct scatterlist *s;
> + unsigned int i;
> +
> + for_each_sg(sgt->sgl, s, sgt->nents, i) {
> + if (!sg_dma_len(s))
> + continue;
Isn't it an error case if sg_dma_len(s) is 0? I think length of s is 0
then it would be invalid because all entries of sgt should be mapped
before sg_dma_len() is called.
>>> Well, it is a grey area. Some code incorrectly sets nents as orig_nents,
>>> thus this version is simply safe for both approaches. sg entries unused
>>> for DMA chunks have sg_dma_len() == 0.
>>>
>>> The above check is more or less copied from
>>> drm_gem_cma_prime_import_sg_table() (drivers/gpu/drm/drm_gem_cma_helper.c).
> I looked into above original code but it seems that it allows sgt->nents to
> have negative value, 'sgt->nents < 1', which could incur some bugs.
Okay, I will add a check for negative or zero nents.
> So I think the original code can be fixed like below,
> if (sgt->nents > 1) { // <- here
> /* check if the entries in the sg_table are contiguous */
> dma_addr_t next_addr = sg_dma_address(sgt->sgl);
> struct scatterlist *s;
> unsigned int i;
>
> for_each_sg(sgt->sgl, s, sgt->nents, i) {
> /*
>* sg_dma_address(s) is only valid for entries
>* that have sg_dma_len(s) > 0 // <- here
>*/
> if (!sg_dma_len(s))
> continue;
>
> if (sg_dma_address(s) != next_addr)
> return ERR_PTR(-EINVAL);
>
> next_addr = sg_dma_address(s) + sg_dma_len(s);
> }
> }
>
> So if you agree with me then we don't have to copy and paste this code as-is.
>
> Regarding 'if (!sg_dma_len(s))' condition here, I'm not clear whether we are
> using it correctly because scatterlist.h header description says,
> /*
> * These macros should be used after a dma_map_sg call has been done
> * to get bus addresses of each of the SG entries and their lengths.
> * You should only work with the number of sg entries dma_map_sg
> * returns, or alternatively stop on the first sg_dma_len(sg) which
> * is 0.
> */
>
> According to above description, sg_dma_len() should be called after
> dma_map_sg() call. Even it says to stop on the first sg_dma_len(sg) which is
> 0.
> And we could avoid the checking function code from being duplicated by
> introducing one function which checks if the entries in the sg_table are
> contiguous or not as a separate patch later.
Okay, I will rework this, then I will prepare a patch which will unify
scatterlist contiguity checks for all DRM drivers.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] omapfb/dss: fix comparison to bool warning
On 22/04/2020 10:19, Jason Yan wrote: Fix the following coccicheck warning: drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c:461:15-32: WARNING: Comparison to bool drivers/video/fbdev/omap2/omapfb/dss/dispc.c:891:5-35: WARNING: Comparison of 0/1 to bool variable Signed-off-by: Jason Yan --- drivers/video/fbdev/omap2/omapfb/dss/dispc.c | 2 +- drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c | 4 +--- 2 files changed, 2 insertions(+), 4 deletions(-) Reviewed-by: Tomi Valkeinen Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] amdgpu: fixes memleak issue when init failed
Am 22.04.20 um 02:56 schrieb 赵军奎:
发件人："Christian König"
发送日期：2020-04-21 22:53:47
收件人："赵军奎"
抄送人：Alex Deucher ,"David (ChunMing) Zhou" ,David Airlie
,Daniel Vetter ,Tom St Denis ,Ori Messinger
,Sam Ravnborg
,amd-...@lists.freedesktop.org,dri-devel@lists.freedesktop.org,linux-ker...@vger.kernel.org,opensource.ker...@vivo.com
主题：Re: [PATCH] amdgpu: fixes memleak issue when init failed>Am 21.04.20 um
15:39 schrieb 赵军奎:
发件人："Christian König"
发送日期：2020-04-21 21:02:27
收件人："赵军奎"
抄送人：Alex Deucher ,"David (ChunMing) Zhou" ,David Airlie
,Daniel Vetter ,Tom St Denis ,Ori Messinger
,Sam Ravnborg
,amd-...@lists.freedesktop.org,dri-devel@lists.freedesktop.org,linux-ker...@vger.kernel.org,opensource.ker...@vivo.com
主题：Re: [PATCH] amdgpu: fixes memleak issue when init failed>Am 21.04.20 um
14:09 schrieb 赵军奎:
From: "Christian König"
Date: 2020-04-21 19:22:49
To: Bernard Zhao ,Alex Deucher ,"David (ChunMing) Zhou"
,David Airlie ,Daniel Vetter ,Tom St Denis
,Ori Messinger ,Sam Ravnborg
,amd-...@lists.freedesktop.org,dri-devel@lists.freedesktop.org,linux-ker...@vger.kernel.org
Cc: opensource.ker...@vivo.com
Subject: Re: [PATCH] amdgpu: fixes memleak issue when init failed>Am 21.04.20
um 13:17 schrieb Bernard Zhao:
VRAM manager and DRM MM when init failed, there is no operaction
to free kzalloc memory & remove device file.
This will lead to memleak & cause stability issue.
NAK, failure to create sysfs nodes are not critical.
Christian.
OK, get it.
By the way, should i modify this patch to just handle in error
branch, or that it is also unnecessary?
What you can do is to drop the "return ret" if anything with the sysfs
nodes goes wrong and instead print the error code.
Emmm, for this part, i am not sure, my modify first print the error, secone
release not free memory,
and last return error, make everything clear to the system.
I think it`s the same with what you mentioned, is there something that I
misunderstood?
Yes, maybe an example makes it more clear what to do here. Currently we
print and error and return when something with the sysfs files goes wrong:
if (ret) {
DRM_ERROR("Failed to create device file mem_info_vram_total\n");
return ret;
}
But what we should do instead is just to print an error and continue and
in the end return success status:
if (ret)
DRM_ERROR("Failed to create device file mem_info_vram_total
(%d)\n", r);
...
return 0;
Regards,
Christian.
Emmm, i am still confused about two points:
1 Does that mean there is no failed case in this function?
Well the kzalloc can still fail.
2 There is no need to free the kzmalloc space(no possibility of memory leak )?
Correct, yes.
Regards,
Christian.
Regards,
Bernard
It's really annoying that loading, unloading and loading the driver
again sometimes fails because we have a bug in the sysfs files cleanup.
We certainly should fix those bugs as well, but they are just not
critical for correct driver functionality.
Regards,
Christian.
Regards,
Bernard
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 24
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index 82a3299e53c0..4c5fb153e6b4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -175,30 +175,44 @@ static int amdgpu_vram_mgr_init(struct
ttm_mem_type_manager *man,
ret = device_create_file(adev->dev, &dev_attr_mem_info_vram_total);
if (ret) {
DRM_ERROR("Failed to create device file mem_info_vram_total\n");
- return ret;
+ goto VRAM_TOTAL_FAIL;
}
ret = device_create_file(adev->dev, &dev_attr_mem_info_vis_vram_total);
if (ret) {
DRM_ERROR("Failed to create device file
mem_info_vis_vram_total\n");
- return ret;
+ goto VIS_VRAM_TOTA_FAIL;
}
ret = device_create_file(adev->dev, &dev_attr_mem_info_vram_used);
if (ret) {
DRM_ERROR("Failed to create device file mem_info_vram_used\n");
- return ret;
+ goto VRAM_USED_FAIL;
}
ret = device_create_file(adev->dev, &dev_attr_mem_info_vis_vram_used);
if (ret) {
DRM_ERROR("Failed to create device file
mem_info_vis_vram_used\n");
- return ret;
+ goto VIS_VRAM_USED_FAIL;
}
ret = device_create_file(adev->dev, &dev_attr_mem_info_vram_vendor);
if (ret) {
DRM_ERROR("Failed to create device file
mem_info_vram_vendor\n");
- return ret;
+ goto VRAM_VERDOR_FAIL;
}
return 0;
+
+VRAM_VERDOR_FAIL:
+ device_remove_file(adev->dev, &dev_attr_mem_info_vis_vram_used);
+VIS_VRAM_USED_FAIL:
+ device_remove_file(adev->dev, &dev_attr_mem_info_vram_used)
Re: [bug report] drm/xen-front: Add support for Xen PV display frontend
On 4/21/20 14:51, Dan Carpenter wrote:
> It turns out there aren't that many of these in xen.
>
> $ grep IS_ERR_OR_NULL drivers/gpu/drm/xen/ -Rn
> drivers/gpu/drm/xen/xen_drm_front_kms.c:63: if (IS_ERR_OR_NULL(fb))
> drivers/gpu/drm/xen/xen_drm_front_gem.c:86: if (IS_ERR_OR_NULL(xen_obj))
> drivers/gpu/drm/xen/xen_drm_front_gem.c:120:if
> (IS_ERR_OR_NULL(xen_obj->pages)) {
> drivers/gpu/drm/xen/xen_drm_front_gem.c:139:if (IS_ERR_OR_NULL(xen_obj))
> drivers/gpu/drm/xen/xen_drm_front_gem.c:197:if (IS_ERR_OR_NULL(xen_obj))
> drivers/gpu/drm/xen/xen_drm_front.c:403:if (IS_ERR_OR_NULL(obj)) {
>
> They're all wrong, because if the pointer was really NULL then it's
> not handled correctly and would eventually lead to a runtime failure.
>
> Normally Smatch is smart enough to know that the pointer isn't NULL so
> it doesn't generate a warning but yesterday I introduced a bug in Smatch
> by mistake. It's fixed now.
>
> regards,
> dan carpenter
>
Thank you,
I'll have a look at those
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [bug report] drm/xen-front: Add support for Xen PV display frontend
On 4/21/20 13:45, Dan Carpenter wrote:
> Hi Kernel Janitors,
Hi
>
> Here is another idea that someone could work on, fixing the
> IS_ERR_OR_NULL() checks in the xen driver.
>
> The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
> display frontend" from Apr 3, 2018, leads to the following static
> checker warning:
>
> drivers/gpu/drm/xen/xen_drm_front_gem.c:140 xen_drm_front_gem_create()
> warn: passing zero to 'ERR_CAST'
>
> drivers/gpu/drm/xen/xen_drm_front_gem.c
> 133 struct drm_gem_object *xen_drm_front_gem_create(struct drm_device
> *dev,
> 134 size_t size)
> 135 {
> 136 struct xen_gem_object *xen_obj;
> 137
> 138 xen_obj = gem_create(dev, size);
> 139 if (IS_ERR_OR_NULL(xen_obj))
> 140 return ERR_CAST(xen_obj);
>
> This warning is old and it's actually the result of a bug I had in my
> devel version of Smatch yesterday. xen_obj can't really be NULL, but
> if it were then the caller would return success which would probably
> create some issues.
>
> When a function returns both error pointers and NULL then NULL is a
> special case of success. Like say you have: "p = start_feature();".
> If there is an allocation failure, then the code should return -ENOMEM
> and the whole thing should fail. But if the feature is optional and
> the user has disabled it in the config then we return NULL and the
> caller has to be able to accept that. There are a lot of these
> IS_ERR_OR_NULL() checks in the xen driver...
>
> The one here is clearly buggy because returning NULL would lead to a
> run time failure. All these IS_ERR_OR_NULL() should be checked and
> probably changed to just IS_ERR().
>
> This sort of change is probably change is probably easiest if you build
> the Smatch DB and you can check if Smatch thinks the functions return
> NULL.
>
> ~/smatch/smatch_data/db/smdb.py return_states gem_create | grep INTERNAL
> drivers/gpu/drm/xen/xen_drm_front_gem.c | gem_create | 58 | (-4095)-(-1) |
>INTERNAL | -1 | | struct xen_gem_object*(*)(struct
> drm_device*, ulong) |
> drivers/gpu/drm/xen/xen_drm_front_gem.c | gem_create | 62 |
> 4065035897849303040 | INTERNAL | -1 | | struct
> xen_gem_object*(*)(struct drm_device*, ulong) |
> drivers/gpu/drm/xen/xen_drm_front_gem.c | gem_create | 66 |
> 4065035897849303040 | INTERNAL | -1 | | struct
> xen_gem_object*(*)(struct drm_device*, ulong) |
> drivers/gpu/drm/xen/xen_drm_front_gem.c | gem_create | 68 | 0,(-4095)-(-1) |
> INTERNAL | -1 | | struct xen_gem_object*(*)(struct
> drm_device*, ulong) |
>
> Smatch thinks that gem_create() sometimes returns NULL or error pointers
> but that's because of a bug in the unreleased version of Smatch and
> because gem_create() uses IS_ERR_OR_NULL().
>
> 141
> 142 return &xen_obj->base;
> 143 }
>
> regards,
> dan carpenter
Thank you for the report, I will try to find some time to look into this
and come up with fixes.
Could you please (probably off-list) instruct me or give any pointers to
how to reproduce
the results of the analyzer shown above?
Thank you,
Oleksandr
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv3 4/4] backlight: led_bl: fix led -> backlight brightness mapping
The code that maps the LED default brightness to backlight levels has
two issues: 1) if the default brightness is the first backlight level
(usually 0), the code fails to find it, and 2) when the code fails to
find a backlight level, it ends up using max_brightness + 1 as the
default brightness.
Fix these two issues.
Signed-off-by: Tomi Valkeinen
---
drivers/video/backlight/led_bl.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/video/backlight/led_bl.c b/drivers/video/backlight/led_bl.c
index 63693c4f0883..699424b111ec 100644
--- a/drivers/video/backlight/led_bl.c
+++ b/drivers/video/backlight/led_bl.c
@@ -139,7 +139,6 @@ static int led_bl_parse_levels(struct device *dev,
num_levels = of_property_count_u32_elems(node, "brightness-levels");
if (num_levels > 1) {
int i;
- unsigned int db;
u32 *levels;
levels = devm_kzalloc(dev, sizeof(u32) * num_levels,
@@ -153,15 +152,11 @@ static int led_bl_parse_levels(struct device *dev,
if (ret < 0)
return ret;
- /*
-* Try to map actual LED brightness to backlight brightness
-* level
-*/
- db = priv->default_brightness;
- for (i = 0 ; i < num_levels; i++) {
- if ((i && db > levels[i - 1]) && db <= levels[i])
+ /* Map LED brightness to backlight brightness level */
+ for (i = 0; i < num_levels - 1; i++)
+ if (levels[i] >= priv->default_brightness)
break;
- }
+
priv->default_brightness = i;
priv->max_brightness = num_levels - 1;
priv->levels = levels;
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv3 3/4] backlight: led_bl: add led_access locking
led_bl does not lock 'led_access' when calling led_sysfs_disable and
led_sysfs_enable, causing the below WARN. Add the locking.
WARNING: CPU: 0 PID: 223 at drivers/leds/led-core.c:353
led_sysfs_disable+0x4c/0x5c
Signed-off-by: Tomi Valkeinen
Reviewed-by: Daniel Thompson
---
drivers/video/backlight/led_bl.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/led_bl.c b/drivers/video/backlight/led_bl.c
index c46ecdfe8b0a..63693c4f0883 100644
--- a/drivers/video/backlight/led_bl.c
+++ b/drivers/video/backlight/led_bl.c
@@ -216,8 +216,11 @@ static int led_bl_probe(struct platform_device *pdev)
return PTR_ERR(priv->bl_dev);
}
- for (i = 0; i < priv->nb_leds; i++)
+ for (i = 0; i < priv->nb_leds; i++) {
+ mutex_lock(&priv->leds[i]->led_access);
led_sysfs_disable(priv->leds[i]);
+ mutex_unlock(&priv->leds[i]->led_access);
+ }
backlight_update_status(priv->bl_dev);
@@ -233,8 +236,11 @@ static int led_bl_remove(struct platform_device *pdev)
backlight_device_unregister(bl);
led_bl_power_off(priv);
- for (i = 0; i < priv->nb_leds; i++)
+ for (i = 0; i < priv->nb_leds; i++) {
+ mutex_lock(&priv->leds[i]->led_access);
led_sysfs_enable(priv->leds[i]);
+ mutex_unlock(&priv->leds[i]->led_access);
+ }
return 0;
}
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv3 2/4] backlight: led_bl: drop useless NULL initialization
There's no need to set 'levels' to NULL.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Daniel Thompson
---
drivers/video/backlight/led_bl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/led_bl.c b/drivers/video/backlight/led_bl.c
index d4e1ce684366..c46ecdfe8b0a 100644
--- a/drivers/video/backlight/led_bl.c
+++ b/drivers/video/backlight/led_bl.c
@@ -140,7 +140,7 @@ static int led_bl_parse_levels(struct device *dev,
if (num_levels > 1) {
int i;
unsigned int db;
- u32 *levels = NULL;
+ u32 *levels;
levels = devm_kzalloc(dev, sizeof(u32) * num_levels,
GFP_KERNEL);
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv3 0/4] led-backlight cleanups & fixes
Hi, Changes in v3: - "backlight: led_bl: fix led -> backlight brightness mapping": Simplify the for loop as suggested by Daniel Changes in v2: - Drop "backlight: led_bl: rewrite led_bl_parse_levels()". The patch changed the behavior, and the new behavior may not be wanted. So lets drop this for now. - "backlight: led_bl: fix led -> backlight brightness mapping" will now use max brightness if LED's brightness is higher than highest backlight brightness level. - Added reviewed-bys. Tomi Tomi Valkeinen (4): backlight: led_bl: fix cosmetic issues backlight: led_bl: drop useless NULL initialization backlight: led_bl: add led_access locking backlight: led_bl: fix led -> backlight brightness mapping drivers/video/backlight/led_bl.c | 37 +--- 1 file changed, 20 insertions(+), 17 deletions(-) -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv3 1/4] backlight: led_bl: fix cosmetic issues
Fix issues reported by checkpatch. No functional changes.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Daniel Thompson
---
drivers/video/backlight/led_bl.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/video/backlight/led_bl.c b/drivers/video/backlight/led_bl.c
index 3f66549997c8..d4e1ce684366 100644
--- a/drivers/video/backlight/led_bl.c
+++ b/drivers/video/backlight/led_bl.c
@@ -126,7 +126,7 @@ static int led_bl_get_leds(struct device *dev,
}
static int led_bl_parse_levels(struct device *dev,
- struct led_bl_data *priv)
+ struct led_bl_data *priv)
{
struct device_node *node = dev->of_node;
int num_levels;
@@ -148,8 +148,8 @@ static int led_bl_parse_levels(struct device *dev,
return -ENOMEM;
ret = of_property_read_u32_array(node, "brightness-levels",
- levels,
- num_levels);
+levels,
+num_levels);
if (ret < 0)
return ret;
@@ -159,14 +159,15 @@ static int led_bl_parse_levels(struct device *dev,
*/
db = priv->default_brightness;
for (i = 0 ; i < num_levels; i++) {
- if ((i && db > levels[i-1]) && db <= levels[i])
+ if ((i && db > levels[i - 1]) && db <= levels[i])
break;
}
priv->default_brightness = i;
priv->max_brightness = num_levels - 1;
priv->levels = levels;
- } else if (num_levels >= 0)
+ } else if (num_levels >= 0) {
dev_warn(dev, "Not enough levels defined\n");
+ }
ret = of_property_read_u32(node, "default-brightness-level", &value);
if (!ret && value <= priv->max_brightness)
@@ -208,7 +209,8 @@ static int led_bl_probe(struct platform_device *pdev)
props.power = (priv->default_brightness > 0) ? FB_BLANK_POWERDOWN :
FB_BLANK_UNBLANK;
priv->bl_dev = backlight_device_register(dev_name(&pdev->dev),
- &pdev->dev, priv, &led_bl_ops, &props);
+&pdev->dev, priv, &led_bl_ops,
+&props);
if (IS_ERR(priv->bl_dev)) {
dev_err(&pdev->dev, "Failed to register backlight\n");
return PTR_ERR(priv->bl_dev);
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
