[PATCH] rnndb: Add GBIF registers for a6xx GPU
Add GBIF register definitions required to implement a618 GPU revision Signed-off-by: Sharat Masetty --- rnndb/adreno/a6xx.xml | 26 ++ 1 file changed, 26 insertions(+) diff --git a/rnndb/adreno/a6xx.xml b/rnndb/adreno/a6xx.xml index 747f071..2d2063a 100644 --- a/rnndb/adreno/a6xx.xml +++ b/rnndb/adreno/a6xx.xml @@ -1748,6 +1748,32 @@ to upconvert to 32b float internally? + + + + + + + + + + + + + + + + + + + + + + + + + + -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205585] [Regression] [amdgpu] AMD Vega 64 GPU invalid access and EEH under load
https://bugzilla.kernel.org/show_bug.cgi?id=205585 --- Comment #3 from Timothy Pearson (tpear...@raptorengineering.com) --- Just had a chance to test on 5.4.0, still fails (haven't had a chance to bisect yet; I suspect it's more related to the 64-bit enablement on POWER in 5.4 than anything else). The EEH is quite strange, the PEST register decodes as: MMIO CFG Read Other Transaction Type An MMIO Load, MMIO I/O Write, or other transaction returned from the PCIe link with a status of Unsupported Request (UR) Failure address: 0x Full trace [20341.276752702,3] PHB#0033[8:3]: PHB Freeze/Fence detected ! [20341.276848173,3] PHB#0033[8:3]: PCI FIR=2000 [20341.276900504,3] PHB#0033[8:3]: PCI FIR WOF=2000 [20341.276939625,3] PHB#0033[8:3]:NEST FIR=8000 [20341.276979866,3] PHB#0033[8:3]:NEST FIR WOF=8000 [20341.277023394,3] PHB#0033[8:3]:ERR RPT0=0001 [20341.277068184,3] PHB#0033[8:3]:ERR RPT1= [20341.277110812,3] PHB#0033[8:3]: AIB ERR=2000 [20341.277830701,3] PHB#0033[8:3]: brdgCtl = 0002 [20341.277906614,3] PHB#0033[8:3]: deviceStatus = 0020 [20341.277946469,3] PHB#0033[8:3]: slotStatus = 00402000 [20341.277981186,3] PHB#0033[8:3]: linkStatus = e9010008 [20341.278025974,3] PHB#0033[8:3]: devCmdStatus = 00100107 [20341.278068859,3] PHB#0033[8:3]: devSecStatus = [20341.278109829,3] PHB#0033[8:3]: rootErrorStatus = [20341.278149196,3] PHB#0033[8:3]: corrErrorStatus = [20341.278190145,3] PHB#0033[8:3]:uncorrErrorStatus = [20341.278223684,3] PHB#0033[8:3]: devctl = 0020 [20341.278276525,3] PHB#0033[8:3]: devStat = [20341.278314241,3] PHB#0033[8:3]: tlpHdr1 = [20341.278356746,3] PHB#0033[8:3]: tlpHdr2 = [20341.278397163,3] PHB#0033[8:3]: tlpHdr3 = [20341.278440709,3] PHB#0033[8:3]: tlpHdr4 = [20341.278478424,3] PHB#0033[8:3]: sourceId = [20341.278516547,3] PHB#0033[8:3]: nFir = 8000 [20341.278555975,3] PHB#0033[8:3]: nFirMask = 0030001c [20341.278598653,3] PHB#0033[8:3]: nFirWOF = 8000 [20341.278642004,3] PHB#0033[8:3]: phbPlssr = 0018 [20341.278686870,3] PHB#0033[8:3]: phbCsr = 0018 [20341.278731874,3] PHB#0033[8:3]: lemFir = 000400010100 [20341.278776158,3] PHB#0033[8:3]: lemErrorMask = [20341.278815229,3] PHB#0033[8:3]: lemWOF = 0001 [20341.278857015,3] PHB#0033[8:3]: phbErrorStatus = 05a0 [20341.278909821,3] PHB#0033[8:3]: phbFirstErrorStatus = 0020 [20341.278951950,3] PHB#0033[8:3]: phbErrorLog0 = 214898000240 [20341.278999524,3] PHB#0033[8:3]: phbErrorLog1 = a0084000 [20341.279042839,3] PHB#0033[8:3]:phbTxeErrorStatus = 2000 [20341.279081676,3] PHB#0033[8:3]: phbTxeFirstErrorStatus = 2000 [20341.279120945,3] PHB#0033[8:3]: phbTxeErrorLog0 = 4000 [20341.279160833,3] PHB#0033[8:3]: phbTxeErrorLog1 = [20341.279207802,3] PHB#0033[8:3]: phbRxeArbErrorStatus = [20341.279254658,3] PHB#0033[8:3]: phbRxeArbFrstErrorStatus = [20341.279297181,3] PHB#0033[8:3]: phbRxeArbErrorLog0 = [20341.279334227,3] PHB#0033[8:3]: phbRxeArbErrorLog1 = [20341.279376968,3] PHB#0033[8:3]: phbRxeMrgErrorStatus = 0001 [20341.279420726,3] PHB#0033[8:3]: phbRxeMrgFrstErrorStatus = 0001 [20341.279469009,3] PHB#0033[8:3]: phbRxeMrgErrorLog0 = [20341.279512839,3] PHB#0033[8:3]: phbRxeMrgErrorLog1 = [20341.279561496,3] PHB#0033[8:3]: phbRxeTceErrorStatus = [20341.279604696,3] PHB#0033[8:3]: phbRxeTceFrstErrorStatus = [20341.279645952,3] PHB#0033[8:3]: phbRxeTceErrorLog0 = [20341.279685644,3] PHB#0033[8:3]: phbRxeTceErrorLog1 = [20341.279731458,3] PHB#0033[8:3]:phbPblErrorStatus = 0800 [20341.279778323,3] PHB#0033[8:3]: phbPblFirstErrorStatus = 0800 [20341.279825433,3] PHB#0033[8:3]: phbPblErrorLog0 = [20341.279866852,3] PHB#0033[8:3]: phbPblErrorLog1 = 028de410 [20341.279903104,3] PHB#0033[8:3]: phbPcieDlpErrorLog1 = [20341.279942888,3] PHB#0033[8:3]: phbPcieDlpErrorLog2 = [20341.279984925,3] PHB#0033[8:3]:
Re: [PATCH RFC v4 07/16] drm, cgroup: Add total GEM buffer allocation limit
On Tue, Oct 1, 2019 at 10:30 AM Michal Koutný wrote:
> On Thu, Aug 29, 2019 at 02:05:24AM -0400, Kenny Ho wrote:
> > drm.buffer.default
> > A read-only flat-keyed file which exists on the root cgroup.
> > Each entry is keyed by the drm device's major:minor.
> >
> > Default limits on the total GEM buffer allocation in bytes.
> What is the purpose of this attribute (and alikes for other resources)?
> I can't see it being set differently but S64_MAX in
> drmcg_device_early_init.
cgroup has a number of conventions and one of which is the idea of a
default. The idea here is to allow for device specific defaults. For
this specific resource, I can probably not expose it since it's not
particularly useful, but for other resources (such as the lgpu
resource) the concept of a default is useful (for example, different
devices can have different number of lgpu.)
> > +static ssize_t drmcg_limit_write(struct kernfs_open_file *of, char *buf,
> > [...]
> > + switch (type) {
> > + case DRMCG_TYPE_BO_TOTAL:
> > + p_max = parent == NULL ? S64_MAX :
> > + parent->dev_resources[minor]->
> > + bo_limits_total_allocated;
> > +
> > + rc = drmcg_process_limit_s64_val(sattr, true,
> > + props->bo_limits_total_allocated_default,
> > + p_max,
> > + );
> IIUC, this allows initiating the particular limit value based either on
> parent or the default per-device value. This is alas rather an
> antipattern. The most stringent limit on the path from a cgroup to the
> root should be applied at the charging time. However, the child should
> not inherit the verbatim value from the parent (may race with parent and
> it won't be updated upon parent change).
I think this was a mistake during one of my refactor and I shrunk the
critical section protected by a mutex a bit too much. But you are
right in the sense that I don't propagate the limits downward to the
children when the parent's limit is updated. But from the user
interface perspective, wouldn't this be confusing? When a sysadmin
sets a limit using the 'max' keyword, the value would be a global one
even though the actual allowable maximum for the particular cgroup is
less in reality because of the ancestor cgroups? (If this is the
established norm, I am ok to go along but seems confusing to me.) I
am probably missing something because as I implemented this, the 'max'
and 'default' semantic has been confusing to me especially for the
children cgroups due to the context of the ancestors.
> You already do the appropriate hierarchical check in
> drmcg_try_chb_bo_alloc, so the parent propagation could be simply
> dropped if I'm not mistaken.
I will need to double check. But I think interaction between parent
and children (or perhaps between siblings) will be needed eventually
because there seems to be a desire to implement "weight" type of
resource. Also, from performance perspective, wouldn't it make more
sense to make sure the limits are set correctly during configuration
than to have to check all the cgroups up through the parents? I don't
have comprehensive knowledge of the implementation of other cgroup
controllers so if more experience folks can comment that would be
great. (Although, I probably should just do one approach instead of
doing both... or 1.5.)
>
> Also, I can't find how the read of
> parent->dev_resources[minor]->bo_limits_total_allocated and its
> concurrent update are synchronized (i.e. someone writing
> buffer.total.max for parent and child in parallel). (It may just my
> oversight.)
This is probably the refactor mistake I mentioned earlier.
Regards,
Kenny
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v4 02/16] cgroup: Introduce cgroup for drm subsystem
On Tue, Oct 1, 2019 at 10:31 AM Michal Koutný wrote:
> On Thu, Aug 29, 2019 at 02:05:19AM -0400, Kenny Ho wrote:
> > +struct cgroup_subsys drm_cgrp_subsys = {
> > + .css_alloc = drmcg_css_alloc,
> > + .css_free = drmcg_css_free,
> > + .early_init = false,
> > + .legacy_cftypes = files,
> Do you really want to expose the DRM controller on v1 hierarchies (where
> threads of one process can be in different cgroups, or children cgroups
> compete with their parents)?
(Sorry for the delay, I have been distracted by something else.)
Yes, I am hoping to make the functionality as widely available as
possible since the ecosystem is still transitioning to v2. Do you see
inherent problem with this approach?
Regards,
Kenny
>
> > + .dfl_cftypes= files,
> > +};
>
> Just asking,
> Michal
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] mm + drm vmwgfx coherent
Hi Linus, This is just a separated pull for the mm pagewalking + drm/vmwgfx work Thomas did and you were involved in, I've left it separate in case you don't feel as comfortable with it as the other stuff. It has mm acks/r-b in the right places from what I can see. Dave. drm-vmwgfx-coherent-2019-11-29: mm + drm coherent memory support for vmwgfx The following changes since commit acc61b8929365e63a3e8c8c8913177795aa45594: Merge tag 'drm-next-5.5-2019-11-22' of git://people.freedesktop.org/~agd5f/linux into drm-next (2019-11-26 08:40:23 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-vmwgfx-coherent-2019-11-29 for you to fetch changes up to 0a6cad5df541108cfd3fbd79eef48eb824c89bdc: Merge branch 'vmwgfx-coherent' of git://people.freedesktop.org/~thomash/linux into drm-next (2019-11-28 14:33:01 +1000) mm + drm coherent memory support for vmwgfx Dave Airlie (1): Merge branch 'vmwgfx-coherent' of git://people.freedesktop.org/~thomash/linux into drm-next Thomas Hellstrom (10): drm/ttm: Remove explicit typecasts of vm_private_data drm/ttm: Convert vm callbacks to helpers mm: Remove BUG_ON mmap_sem not held from xxx_trans_huge_lock() mm: pagewalk: Take the pagetable lock in walk_pte_range() mm: Add a walk_page_mapping() function to the pagewalk code mm: Add write-protect and clean utilities for address space ranges drm/vmwgfx: Implement an infrastructure for write-coherent resources drm/vmwgfx: Use an RBtree instead of linked list for MOB resources drm/vmwgfx: Implement an infrastructure for read-coherent resources drm/vmwgfx: Add surface dirty-tracking callbacks drivers/gpu/drm/ttm/ttm_bo_vm.c| 174 +--- drivers/gpu/drm/vmwgfx/Kconfig | 1 + drivers/gpu/drm/vmwgfx/Makefile| 2 +- .../drm/vmwgfx/device_include/svga3d_surfacedefs.h | 233 +- drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 10 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 44 +- drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c| 1 - drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c | 488 + drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 193 +++- drivers/gpu/drm/vmwgfx/vmwgfx_resource_priv.h | 13 + drivers/gpu/drm/vmwgfx/vmwgfx_surface.c| 395 - drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 15 +- drivers/gpu/drm/vmwgfx/vmwgfx_validation.c | 74 +++- drivers/gpu/drm/vmwgfx/vmwgfx_validation.h | 16 +- include/drm/ttm/ttm_bo_api.h | 14 + include/linux/huge_mm.h| 2 - include/linux/mm.h | 13 +- include/linux/pagewalk.h | 9 + include/uapi/drm/vmwgfx_drm.h | 4 +- mm/Kconfig | 3 + mm/Makefile| 1 + mm/mapping_dirty_helpers.c | 315 + mm/pagewalk.c | 99 - 23 files changed, 1996 insertions(+), 123 deletions(-) create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c create mode 100644 mm/mapping_dirty_helpers.c ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for 5.5-rc1
Hi Dave, On Fri, 29 Nov 2019 09:13:16 +1000 Dave Airlie wrote: > > On Fri, 29 Nov 2019 at 07:55, Stephen Rothwell wrote: > > > > Hi Dave, > > > > On Thu, 28 Nov 2019 12:37:06 +1000 Dave Airlie wrote: > > > > > > > And apparently nobody bothered to tell me about the semantic conflict > > > > with the media tree due to the changed calling convention of > > > > cec_notifier_cec_adap_unregister(). Didn't that show up in linux-next? > > > > > > I can see no mention of it, I've got > > > > > > Hans saying > > > > > > "This will only be a problem if a new CEC adapter driver is added to the > > > media > > > subsystem for v5.5, but I am not aware of any plans for that." when I > > > landed that > > > in my tree, but I assume the ao-cec change in the media tree collided > > > with it. > > > > > > But I hadn't seen any mention of it from -next before you mentioned it > > > now. > > > > See https://lore.kernel.org/lkml/20191014111225.66b36...@canb.auug.org.au/ > > Indeed, the misc team didn't remention that to me, when I pulled their > tree, perhaps I should make them do so, not sure why my search > yesterday failed to find this in my inbox. It was form Oct 14 ... I should have resent it earlier this week (or last) as a reminder. -- Cheers, Stephen Rothwell pgpmeeJGR3aL5.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for 5.5-rc1
On Fri, 29 Nov 2019 at 07:55, Stephen Rothwell wrote: > > Hi Dave, > > On Thu, 28 Nov 2019 12:37:06 +1000 Dave Airlie wrote: > > > > > And apparently nobody bothered to tell me about the semantic conflict > > > with the media tree due to the changed calling convention of > > > cec_notifier_cec_adap_unregister(). Didn't that show up in linux-next? > > > > I can see no mention of it, I've got > > > > Hans saying > > > > "This will only be a problem if a new CEC adapter driver is added to the > > media > > subsystem for v5.5, but I am not aware of any plans for that." when I > > landed that > > in my tree, but I assume the ao-cec change in the media tree collided with > > it. > > > > But I hadn't seen any mention of it from -next before you mentioned it now. > > See https://lore.kernel.org/lkml/20191014111225.66b36...@canb.auug.org.au/ Indeed, the misc team didn't remention that to me, when I pulled their tree, perhaps I should make them do so, not sure why my search yesterday failed to find this in my inbox. Thanks, Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] PM / runtime: Allow drivers to override runtime PM behaviour on sleep
On Thursday, November 28, 2019 11:03:57 PM CET Rafael J. Wysocki wrote: > On Thursday, November 28, 2019 5:50:26 PM CET Thierry Reding wrote: > > > > --0F1p//8PRICkK4MW > > Content-Type: text/plain; charset=us-ascii > > Content-Disposition: inline > > Content-Transfer-Encoding: quoted-printable > > > > On Thu, Nov 28, 2019 at 05:14:51PM +0100, Rafael J. Wysocki wrote: > > > On Thu, Nov 28, 2019 at 5:03 PM Thierry Reding = > > wrote: > > > > > > > > From: Thierry Reding > > > > > > > > Currently the driver PM core will automatically acquire a runtime PM > > > > reference for devices before system sleep is entered. This is needed > > > > to avoid potential issues related to devices' parents getting put to > > > > runtime suspend at the wrong time and causing problems with their > > > > children. > > >=20 > > > Not only for that. > > >=20 > > > > In some cases drivers are carefully written to avoid such issues and > > > > the default behaviour can be changed to allow runtime PM to operate > > > > regularly during system sleep. > > >=20 > > > But this change breaks quite a few assumptions in the core too, so no, > > > it can't be made. > > > > Anything in particular that I can look at? I'm not seeing any issues > > when I test this, which could of course mean that I'm just getting > > lucky. > > There are races and such that you may never hit during casual testing. > > > One thing that irritated me is that I think this used to work. I do > > recall testing suspend/resume a few years ago and devices would get > > properly runtime suspended/resumed. > > Not true at all. > > The PM core has always taken PM-runtime references on all devices pretty much > since when PM-runtime was introduced. > > > I did some digging but couldn't > > find anything that would have had an impact on this. > > > > Given that this is completely opt-in feature, why are you categorically > > NAK'ing this? > > The general problem is that if any device has been touched by system-wide > suspend code, it should not be subject to PM-runtime any more until the > subsequent system-wide resume is able to undo whatever the suspend did. > > Moreover, if a device is runtime-suspended, the system-wide suspend code > may mishandle it, in general. That's why PM-runtime suspend is not allowed > during system-wide transitions at all. And it has always been like that. > > For a specific platform you may be able to overcome these limitations if > you are careful enough, but certainly they are there in general and surely > you cannot prevent people from using your opt-in just because they think > that they know what they are doing. BTW, what if user space prevents PM-runtime from suspending devices by writing "on" to their "control" files? System-wide suspend is (of course) still expected to work in that case, so how exactly would you overcome that? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] PM / runtime: Allow drivers to override runtime PM behaviour on sleep
On Thursday, November 28, 2019 5:50:26 PM CET Thierry Reding wrote: > > --0F1p//8PRICkK4MW > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Thu, Nov 28, 2019 at 05:14:51PM +0100, Rafael J. Wysocki wrote: > > On Thu, Nov 28, 2019 at 5:03 PM Thierry Reding = > wrote: > > > > > > From: Thierry Reding > > > > > > Currently the driver PM core will automatically acquire a runtime PM > > > reference for devices before system sleep is entered. This is needed > > > to avoid potential issues related to devices' parents getting put to > > > runtime suspend at the wrong time and causing problems with their > > > children. > >=20 > > Not only for that. > >=20 > > > In some cases drivers are carefully written to avoid such issues and > > > the default behaviour can be changed to allow runtime PM to operate > > > regularly during system sleep. > >=20 > > But this change breaks quite a few assumptions in the core too, so no, > > it can't be made. > > Anything in particular that I can look at? I'm not seeing any issues > when I test this, which could of course mean that I'm just getting > lucky. There are races and such that you may never hit during casual testing. > One thing that irritated me is that I think this used to work. I do > recall testing suspend/resume a few years ago and devices would get > properly runtime suspended/resumed. Not true at all. The PM core has always taken PM-runtime references on all devices pretty much since when PM-runtime was introduced. > I did some digging but couldn't > find anything that would have had an impact on this. > > Given that this is completely opt-in feature, why are you categorically > NAK'ing this? The general problem is that if any device has been touched by system-wide suspend code, it should not be subject to PM-runtime any more until the subsequent system-wide resume is able to undo whatever the suspend did. Moreover, if a device is runtime-suspended, the system-wide suspend code may mishandle it, in general. That's why PM-runtime suspend is not allowed during system-wide transitions at all. And it has always been like that. For a specific platform you may be able to overcome these limitations if you are careful enough, but certainly they are there in general and surely you cannot prevent people from using your opt-in just because they think that they know what they are doing. > Is there some other alternative that I can look into? First of all, ensure that the dpm_list ordering is what it should be on the system/platform in question. That can be done with the help of device links. In addition, make sure that the devices needed to suspend other devices are suspended in the noirq phase of system-wide suspend and resumed in the noirq phase of system-wide resume. Or at least all of the other devices need to be suspended before them and resumed after them. These two things should allow you to cover the vast majority of cases if not all of them without messing up with the rules. Thanks! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for 5.5-rc1
Hi Dave, On Thu, 28 Nov 2019 12:37:06 +1000 Dave Airlie wrote: > > > And apparently nobody bothered to tell me about the semantic conflict > > with the media tree due to the changed calling convention of > > cec_notifier_cec_adap_unregister(). Didn't that show up in linux-next? > > I can see no mention of it, I've got > > Hans saying > > "This will only be a problem if a new CEC adapter driver is added to the media > subsystem for v5.5, but I am not aware of any plans for that." when I > landed that > in my tree, but I assume the ao-cec change in the media tree collided with it. > > But I hadn't seen any mention of it from -next before you mentioned it now. See https://lore.kernel.org/lkml/20191014111225.66b36...@canb.auug.org.au/ -- Cheers, Stephen Rothwell pgpfPU_NDpqNt.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panfrost: Register devfreq cooling device
When we have devfreq, also try to register a basic cooling device in
case GPU workloads manage to hit thermal throttling thresholds.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 32 ++---
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 4c4e8a30a1ac..fe8ee77c96e4 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
/* Copyright 2019 Collabora ltd. */
#include
+#include
#include
#include
#include
@@ -81,8 +82,11 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
int ret;
struct dev_pm_opp *opp;
unsigned long cur_freq;
+ struct device *dev = >pdev->dev;
+ struct devfreq *devfreq;
+ struct thermal_cooling_device *cooling;
- ret = dev_pm_opp_of_add_table(>pdev->dev);
+ ret = dev_pm_opp_of_add_table(dev);
if (ret == -ENODEV) /* Optional, continue without devfreq */
return 0;
else if (ret)
@@ -92,29 +96,35 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
cur_freq = clk_get_rate(pfdev->clock);
- opp = devfreq_recommended_opp(>pdev->dev, _freq, 0);
+ opp = devfreq_recommended_opp(dev, _freq, 0);
if (IS_ERR(opp))
return PTR_ERR(opp);
panfrost_devfreq_profile.initial_freq = cur_freq;
dev_pm_opp_put(opp);
- pfdev->devfreq.devfreq = devm_devfreq_add_device(>pdev->dev,
- _devfreq_profile, DEVFREQ_GOV_SIMPLE_ONDEMAND,
- NULL);
- if (IS_ERR(pfdev->devfreq.devfreq)) {
- DRM_DEV_ERROR(>pdev->dev, "Couldn't initialize GPU
devfreq\n");
- ret = PTR_ERR(pfdev->devfreq.devfreq);
- pfdev->devfreq.devfreq = NULL;
- dev_pm_opp_of_remove_table(>pdev->dev);
- return ret;
+ devfreq = devm_devfreq_add_device(dev, _devfreq_profile,
+ DEVFREQ_GOV_SIMPLE_ONDEMAND, NULL);
+ if (IS_ERR(devfreq)) {
+ DRM_DEV_ERROR(dev, "Couldn't initialize GPU devfreq\n");
+ dev_pm_opp_of_remove_table(dev);
+ return PTR_ERR(devfreq);
}
+ pfdev->devfreq.devfreq = devfreq;
+
+ cooling = of_devfreq_cooling_register(dev->of_node, devfreq);
+ if (IS_ERR(cooling))
+ DRM_DEV_INFO(dev, "Failed to register cooling device\n");
+ else
+ pfdev->devfreq.cooling = cooling;
return 0;
}
void panfrost_devfreq_fini(struct panfrost_device *pfdev)
{
+ if (pfdev->devfreq.cooling)
+ devfreq_cooling_unregister(pfdev->devfreq.cooling);
dev_pm_opp_of_remove_table(>pdev->dev);
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205661] Upgrade to 5.4 from K5.3.13 fails x2 attempts
https://bugzilla.kernel.org/show_bug.cgi?id=205661 --- Comment #2 from Ivan Ratoyevsky (i...@cyteck.co.uk) --- Hi Jani, Thanks for your response but I don't really understand what you mean? a) I have resolved the 1st firmware error. Managed to source a current copy of the missing firmware file for a realtek NIC. I copied the file to the required folder and the error is now gone. b) The Nvidia driver error is still a major problem. This error only showed up with K5.4. I downgraded back to K5.3.13 and I have no driver issues now. So its definitely something within K5.4 that's a problem with Nvidia graphics drivers. Its related to DKMS but more than that is beyond my knowledge or experience with Linux & the kernel. -- 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: [PATCH 1/2] dt-bindings: display: DT schema for rocktech,rk101ii01d-ct panel
On 28/11/2019 18:45, Jyri Sarha wrote:
> Add DT schema binding for Rocktech Displays Limited RK101II01D-CT
> 10.1" TFT 1280x800 Pixels with LVDS interface, LED Backlight and
> capacitive touch panel.
>
> Signed-off-by: Jyri Sarha
> ---
> .../display/panel/rocktech,rk101ii01d-ct.yaml | 48 +++
> 1 file changed, 48 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/rocktech,rk101ii01d-ct.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/rocktech,rk101ii01d-ct.yaml
> b/Documentation/devicetree/bindings/display/panel/rocktech,rk101ii01d-ct.yaml
> new file mode 100644
> index ..09caeee8701d
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/display/panel/rocktech,rk101ii01d-ct.yaml
> @@ -0,0 +1,48 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/dlc,dlc0700yzg-1.yaml#
Argh, at least one copy-paste error here: ^
So not to be applied as such.
BR,
Jyri
/me wonders why he always sees these only right after sending the patch.
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Rocktech Displays Ltd RK101II01D-CT 10.1" TFT 1280x800 Pixels
> +
> +maintainers:
> + - Jyri Sarha
> + - Thierry Reding
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +description: |
> + Rocktech Displays Limited RK101II01D-CT 10.1" TFT 1280x800 Pixels
> + with LVDS interface, LED Backlight and capacitive touch panel. For
> + touch screen details see "goodix,gt928" in:
> + Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> +
> +properties:
> + compatible:
> +const: rocktech,rk101ii01d-ct
> +
> + reset-gpios: true
> + enable-gpios: true
> + backlight: true
> + port: true
> +
> +required:
> + - compatible
> + - power-supply
> +
> +examples:
> + - |
> +display0 {
> +compatible = "rocktech,rk101ii01d-ct";
> +backlight = <_bl>;
> +enable-gpios = < 8 GPIO_ACTIVE_HIGH>;
> +power-supply = <_supply>;
> +
> +port {
> +lcd_in0: endpoint {
> +remote-endpoint = <_out0>;
> +};
> +};
> +};
>
--
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 0/2] PM / runtime: Allow drivers to override runtime PM behaviour on sleep
On Thu, Nov 28, 2019 at 05:47:05PM +0100, Daniel Vetter wrote:
> On Thu, Nov 28, 2019 at 5:03 PM Thierry Reding
> wrote:
> >
> > From: Thierry Reding
> >
> > This is a result of looking into a more formal way of doing what was
> > proposed here:
> >
> > http://patchwork.ozlabs.org/patch/1145363/
> >
> > The Tegra DRM driver is written such that runtime PM controls all
> > aspects of bringing up and shutting down the hardware associated with a
> > display pipeline. This works very nicely with the DRM/KMS atomic mode-
> > setting framework that has very rigorous call sequences. There are also
> > suspend/resume helpers for system sleep that are built on top of these
> > generic helpers and that cause the same code sequences to be run as if
> > users had simply chosen to disable all display pipelines at normal
> > runtime.
> >
> > The current behaviour of the PM core to disallow runtime suspend/resume
> > during system sleep gets in the way of this because the devices do not
> > in fact runtime suspend/resume during that time. Most of the time this
> > causes display outputs to malfunction upon resume.
> >
> > Now, there are good reasons for preventing runtime suspend during system
> > sleep, as given in commit eea3fc0357eb ("PCI / PM: Detect early wakeup
> > in pci_pm_prepare()") that originally introduced this mechanism. There
> > can, however, also be cases, like the one described above, where it is
> > safe to allow this. Add a flag and a set of helpers to set or clear that
> > new flag so that drivers that know it will be safe to runtime suspend a
> > device at system sleep time can mark the device as such.
> >
> > If a device has the flag set, the PM core will no longer take a runtime
> > PM reference for it, thus allowing the device to runtime suspend at the
> > expected time.
>
> What about sprinkling tons of device_links all over this to make sure
> system suspend/resume is done in the same order too? Slightly less
> neat from a driver pov, but I think that should get the job done.
> Maybe could even do a convenience function which converts a dt phandle
> (or whatever that was called again) into a device_link?
That wouldn't actually fix the issue that I'm trying to solve. While it
seems like forcefully runtime suspending devices on system sleep, as is
done in Dmitry's patch that I linked to above, results in the system
resuming normally, I do recall that the exact point in time where we
reset and power-cycle the hardware can be crucial.
The strange thing is that I do recall this to have worked in the past.
This must have been around the time when we worked on atomic modesetting
(about 4 years ago) because all of the runtime PM code in Tegra DRM is
from around that time. And I remember at the time thinking how neatly
this all fit together, because system suspend/resume really wasn't at
all a special case.
Unfortunately, looking at the git log I don't see how it ever could've
worked given that extra runtime PM reference that the PM core acquires.
I tried to go back and test on one of the old kernel trees, but I can't
find a GCC that builds those versions. I may need to go and dig through
some archives to find an old enough version.
Anyway, the situation being what it is, I think that quite a few of the
DRM/KMS drivers may be running into the same problem, since most today
use the drm_mode_config_helper_{suspend,resume}() helpers and quite a
few do pm_runtime_get_sync() in ->atomic_enable() and pm_runtime_put()
in ->atomic_disable(). Now, for some hardware it may not matter whether
we actually get suspended, but I'm not sure that's an assumption that
we can make.
One possible solution that I can think of is to side-step runtime PM
entirely and just call the functions directly. At least on Tegra we
don't rely on the reference counting. I'm not entirely sure that would
work, though, because what we do rely on is interoperability with
generic power domains via runtime PM. The way this was supposed to work
was that the various hardware engines would get powered off and after
the runtime suspend callbacks had successfully executed, the reference
count on their power domains would also be decreased, which would
eventually cause the power domains to be powered off at the right time.
Moving away from runtime suspend callbacks in the drivers would require
at least leaving in a few of the pm_runtime_{get,put}() calls to make
sure the power domains are on/off at the right time.
Thierry
> -Daniel
>
> > Thierry
> >
> > Thierry Reding (2):
> > PM / runtime: Allow drivers to override runtime PM behaviour on sleep
> > drm/tegra: Allow runtime suspend on system sleep
> >
> > drivers/base/power/main.c| 6 --
> > drivers/base/power/runtime.c | 16
> > drivers/gpu/drm/tegra/dc.c | 1 +
> > drivers/gpu/drm/tegra/dsi.c | 1 +
> > drivers/gpu/drm/tegra/hdmi.c | 1 +
> > drivers/gpu/drm/tegra/hub.c | 1 +
> > drivers/gpu/drm/tegra/sor.c | 1 +
> > include/linux/pm.h
Re: [PATCH 1/2] PM / runtime: Allow drivers to override runtime PM behaviour on sleep
On Thu, Nov 28, 2019 at 05:14:51PM +0100, Rafael J. Wysocki wrote: > On Thu, Nov 28, 2019 at 5:03 PM Thierry Reding > wrote: > > > > From: Thierry Reding > > > > Currently the driver PM core will automatically acquire a runtime PM > > reference for devices before system sleep is entered. This is needed > > to avoid potential issues related to devices' parents getting put to > > runtime suspend at the wrong time and causing problems with their > > children. > > Not only for that. > > > In some cases drivers are carefully written to avoid such issues and > > the default behaviour can be changed to allow runtime PM to operate > > regularly during system sleep. > > But this change breaks quite a few assumptions in the core too, so no, > it can't be made. Anything in particular that I can look at? I'm not seeing any issues when I test this, which could of course mean that I'm just getting lucky. One thing that irritated me is that I think this used to work. I do recall testing suspend/resume a few years ago and devices would get properly runtime suspended/resumed. I did some digging but couldn't find anything that would have had an impact on this. Given that this is completely opt-in feature, why are you categorically NAK'ing this? Is there some other alternative that I can look into? Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] PM / runtime: Allow drivers to override runtime PM behaviour on sleep
On Thu, Nov 28, 2019 at 5:03 PM Thierry Reding wrote:
>
> From: Thierry Reding
>
> This is a result of looking into a more formal way of doing what was
> proposed here:
>
> http://patchwork.ozlabs.org/patch/1145363/
>
> The Tegra DRM driver is written such that runtime PM controls all
> aspects of bringing up and shutting down the hardware associated with a
> display pipeline. This works very nicely with the DRM/KMS atomic mode-
> setting framework that has very rigorous call sequences. There are also
> suspend/resume helpers for system sleep that are built on top of these
> generic helpers and that cause the same code sequences to be run as if
> users had simply chosen to disable all display pipelines at normal
> runtime.
>
> The current behaviour of the PM core to disallow runtime suspend/resume
> during system sleep gets in the way of this because the devices do not
> in fact runtime suspend/resume during that time. Most of the time this
> causes display outputs to malfunction upon resume.
>
> Now, there are good reasons for preventing runtime suspend during system
> sleep, as given in commit eea3fc0357eb ("PCI / PM: Detect early wakeup
> in pci_pm_prepare()") that originally introduced this mechanism. There
> can, however, also be cases, like the one described above, where it is
> safe to allow this. Add a flag and a set of helpers to set or clear that
> new flag so that drivers that know it will be safe to runtime suspend a
> device at system sleep time can mark the device as such.
>
> If a device has the flag set, the PM core will no longer take a runtime
> PM reference for it, thus allowing the device to runtime suspend at the
> expected time.
What about sprinkling tons of device_links all over this to make sure
system suspend/resume is done in the same order too? Slightly less
neat from a driver pov, but I think that should get the job done.
Maybe could even do a convenience function which converts a dt phandle
(or whatever that was called again) into a device_link?
-Daniel
> Thierry
>
> Thierry Reding (2):
> PM / runtime: Allow drivers to override runtime PM behaviour on sleep
> drm/tegra: Allow runtime suspend on system sleep
>
> drivers/base/power/main.c| 6 --
> drivers/base/power/runtime.c | 16
> drivers/gpu/drm/tegra/dc.c | 1 +
> drivers/gpu/drm/tegra/dsi.c | 1 +
> drivers/gpu/drm/tegra/hdmi.c | 1 +
> drivers/gpu/drm/tegra/hub.c | 1 +
> drivers/gpu/drm/tegra/sor.c | 1 +
> include/linux/pm.h | 1 +
> include/linux/pm_runtime.h | 2 ++
> 9 files changed, 28 insertions(+), 2 deletions(-)
>
> --
> 2.23.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/panel: simple: Add Rocktech RK101II01D-CT panel
Add support for Rocktech RK101II01D-CT, 10.1" 1280x800 TFT with LVDS
interface, LED backlight and integrated Goodix GT928 capacitive touch
panel.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/panel/panel-simple.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 5d487686d25c..489e217102ea 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2479,6 +2479,35 @@ static const struct panel_desc rocktech_rk070er9427 = {
.bus_format = MEDIA_BUS_FMT_RGB666_1X18,
};
+static const struct drm_display_mode rocktech_rk101ii01d_ct_mode = {
+ .clock = 71100,
+ .hdisplay = 1280,
+ .hsync_start = 1280 + 48,
+ .hsync_end = 1280 + 48 + 32,
+ .htotal = 1280 + 48 + 32 + 80,
+ .vdisplay = 800,
+ .vsync_start = 800 + 2,
+ .vsync_end = 800 + 2 + 5,
+ .vtotal = 800 + 2 + 5 + 16,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc rocktech_rk101ii01d_ct = {
+ .modes = _rk101ii01d_ct_mode,
+ .num_modes = 1,
+ .size = {
+ .width = 217,
+ .height = 136,
+ },
+ .delay = {
+ .prepare = 50,
+ .disable = 50,
+ },
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
static const struct drm_display_mode samsung_lsn122dl01_c01_mode = {
.clock = 271560,
.hdisplay = 2560,
@@ -3338,6 +3367,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "rocktech,rk070er9427",
.data = _rk070er9427,
+ }, {
+ .compatible = "rocktech,rk101ii01d-ct",
+ .data = _rk101ii01d_ct,
}, {
.compatible = "samsung,lsn122dl01-c01",
.data = _lsn122dl01_c01,
--
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
[PATCH 1/2] dt-bindings: display: DT schema for rocktech, rk101ii01d-ct panel
Add DT schema binding for Rocktech Displays Limited RK101II01D-CT
10.1" TFT 1280x800 Pixels with LVDS interface, LED Backlight and
capacitive touch panel.
Signed-off-by: Jyri Sarha
---
.../display/panel/rocktech,rk101ii01d-ct.yaml | 48 +++
1 file changed, 48 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/rocktech,rk101ii01d-ct.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/rocktech,rk101ii01d-ct.yaml
b/Documentation/devicetree/bindings/display/panel/rocktech,rk101ii01d-ct.yaml
new file mode 100644
index ..09caeee8701d
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/panel/rocktech,rk101ii01d-ct.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/dlc,dlc0700yzg-1.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rocktech Displays Ltd RK101II01D-CT 10.1" TFT 1280x800 Pixels
+
+maintainers:
+ - Jyri Sarha
+ - Thierry Reding
+
+allOf:
+ - $ref: panel-common.yaml#
+
+description: |
+ Rocktech Displays Limited RK101II01D-CT 10.1" TFT 1280x800 Pixels
+ with LVDS interface, LED Backlight and capacitive touch panel. For
+ touch screen details see "goodix,gt928" in:
+ Documentation/devicetree/bindings/input/touchscreen/goodix.txt
+
+properties:
+ compatible:
+const: rocktech,rk101ii01d-ct
+
+ reset-gpios: true
+ enable-gpios: true
+ backlight: true
+ port: true
+
+required:
+ - compatible
+ - power-supply
+
+examples:
+ - |
+display0 {
+compatible = "rocktech,rk101ii01d-ct";
+backlight = <_bl>;
+enable-gpios = < 8 GPIO_ACTIVE_HIGH>;
+power-supply = <_supply>;
+
+port {
+lcd_in0: endpoint {
+remote-endpoint = <_out0>;
+};
+};
+};
--
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
[PATCH 0/2] drm/panel: simple: Rocktech RK101II01D-CT + binding
Add support for Rocktech RK101II01D-CT panel to panel-simple and add yaml binding for it. Jyri Sarha (2): dt-bindings: display: DT schema for rocktech,rk101ii01d-ct panel drm/panel: simple: Add Rocktech RK101II01D-CT panel .../display/panel/rocktech,rk101ii01d-ct.yaml | 48 +++ drivers/gpu/drm/panel/panel-simple.c | 32 + 2 files changed, 80 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/rocktech,rk101ii01d-ct.yaml -- 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: [RFC PATCH 05/12] video: fbdev: matrox: convert to i2c_new_scanned_device
On Thu, Nov 07, 2019 at 09:33:54AM +0100, Daniel Vetter wrote: > On Wed, Nov 06, 2019 at 10:50:23AM +0100, Wolfram Sang wrote: > > Move from the deprecated i2c_new_probed_device() to the new > > i2c_new_scanned_device(). Make use of the new ERRPTR if suitable. > > > > Signed-off-by: Wolfram Sang > > Ack for merging through whatever tree you think this should best land > through. Ok, because it is a single and simple patch, I'll apply it simply via I2C. Thanks! signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 05/12] video: fbdev: matrox: convert to i2c_new_scanned_device
On Wed, Nov 06, 2019 at 10:50:23AM +0100, Wolfram Sang wrote: > Move from the deprecated i2c_new_probed_device() to the new > i2c_new_scanned_device(). Make use of the new ERRPTR if suitable. > > Signed-off-by: Wolfram Sang Applied to for-next, thanks! signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] PM / runtime: Allow drivers to override runtime PM behaviour on sleep
On Thu, Nov 28, 2019 at 5:03 PM Thierry Reding wrote: > > From: Thierry Reding > > Currently the driver PM core will automatically acquire a runtime PM > reference for devices before system sleep is entered. This is needed > to avoid potential issues related to devices' parents getting put to > runtime suspend at the wrong time and causing problems with their > children. Not only for that. > In some cases drivers are carefully written to avoid such issues and > the default behaviour can be changed to allow runtime PM to operate > regularly during system sleep. But this change breaks quite a few assumptions in the core too, so no, it can't be made. Thanks! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] PM / runtime: Allow drivers to override runtime PM behaviour on sleep
From: Thierry Reding
This is a result of looking into a more formal way of doing what was
proposed here:
http://patchwork.ozlabs.org/patch/1145363/
The Tegra DRM driver is written such that runtime PM controls all
aspects of bringing up and shutting down the hardware associated with a
display pipeline. This works very nicely with the DRM/KMS atomic mode-
setting framework that has very rigorous call sequences. There are also
suspend/resume helpers for system sleep that are built on top of these
generic helpers and that cause the same code sequences to be run as if
users had simply chosen to disable all display pipelines at normal
runtime.
The current behaviour of the PM core to disallow runtime suspend/resume
during system sleep gets in the way of this because the devices do not
in fact runtime suspend/resume during that time. Most of the time this
causes display outputs to malfunction upon resume.
Now, there are good reasons for preventing runtime suspend during system
sleep, as given in commit eea3fc0357eb ("PCI / PM: Detect early wakeup
in pci_pm_prepare()") that originally introduced this mechanism. There
can, however, also be cases, like the one described above, where it is
safe to allow this. Add a flag and a set of helpers to set or clear that
new flag so that drivers that know it will be safe to runtime suspend a
device at system sleep time can mark the device as such.
If a device has the flag set, the PM core will no longer take a runtime
PM reference for it, thus allowing the device to runtime suspend at the
expected time.
Thierry
Thierry Reding (2):
PM / runtime: Allow drivers to override runtime PM behaviour on sleep
drm/tegra: Allow runtime suspend on system sleep
drivers/base/power/main.c| 6 --
drivers/base/power/runtime.c | 16
drivers/gpu/drm/tegra/dc.c | 1 +
drivers/gpu/drm/tegra/dsi.c | 1 +
drivers/gpu/drm/tegra/hdmi.c | 1 +
drivers/gpu/drm/tegra/hub.c | 1 +
drivers/gpu/drm/tegra/sor.c | 1 +
include/linux/pm.h | 1 +
include/linux/pm_runtime.h | 2 ++
9 files changed, 28 insertions(+), 2 deletions(-)
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] PM / runtime: Allow drivers to override runtime PM behaviour on sleep
From: Thierry Reding
Currently the driver PM core will automatically acquire a runtime PM
reference for devices before system sleep is entered. This is needed
to avoid potential issues related to devices' parents getting put to
runtime suspend at the wrong time and causing problems with their
children.
In some cases drivers are carefully written to avoid such issues and
the default behaviour can be changed to allow runtime PM to operate
regularly during system sleep.
Add helpers to flag devices as being safe to be runtime suspended at
system sleep time.
Signed-off-by: Thierry Reding
---
drivers/base/power/main.c| 6 --
drivers/base/power/runtime.c | 16
include/linux/pm.h | 1 +
include/linux/pm_runtime.h | 2 ++
4 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 134a8af51511..f8dbf00c703b 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -1113,7 +1113,8 @@ static void device_complete(struct device *dev,
pm_message_t state)
device_unlock(dev);
- pm_runtime_put(dev);
+ if (!dev->power.always_runtime)
+ pm_runtime_put(dev);
}
/**
@@ -1896,7 +1897,8 @@ static int device_prepare(struct device *dev,
pm_message_t state)
* block runtime suspend here, during the prepare phase, and allow
* it again during the complete phase.
*/
- pm_runtime_get_noresume(dev);
+ if (!dev->power.always_runtime)
+ pm_runtime_get_noresume(dev);
device_lock(dev);
diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 48616f358854..699803984426 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -1440,6 +1440,22 @@ void pm_runtime_allow(struct device *dev)
}
EXPORT_SYMBOL_GPL(pm_runtime_allow);
+void pm_runtime_always_allow(struct device *dev)
+{
+ spin_lock_irq(>power.lock);
+ dev->power.always_runtime = 1;
+ spin_unlock_irq(>power.lock);
+}
+EXPORT_SYMBOL_GPL(pm_runtime_always_allow);
+
+void pm_runtime_always_forbid(struct device *dev)
+{
+ spin_lock_irq(>power.lock);
+ dev->power.always_runtime = 0;
+ spin_unlock_irq(>power.lock);
+}
+EXPORT_SYMBOL_GPL(pm_runtime_always_forbid);
+
/**
* pm_runtime_no_callbacks - Ignore runtime PM callbacks for a device.
* @dev: Device to handle.
diff --git a/include/linux/pm.h b/include/linux/pm.h
index e057d1fa2469..6133cf496878 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -615,6 +615,7 @@ struct dev_pm_info {
unsigned intuse_autosuspend:1;
unsigned inttimer_autosuspends:1;
unsigned intmemalloc_noio:1;
+ unsigned intalways_runtime:1;
unsigned intlinks_count;
enum rpm_requestrequest;
enum rpm_status runtime_status;
diff --git a/include/linux/pm_runtime.h b/include/linux/pm_runtime.h
index 22af69d237a6..28204baf01cb 100644
--- a/include/linux/pm_runtime.h
+++ b/include/linux/pm_runtime.h
@@ -46,6 +46,8 @@ extern void pm_runtime_enable(struct device *dev);
extern void __pm_runtime_disable(struct device *dev, bool check_resume);
extern void pm_runtime_allow(struct device *dev);
extern void pm_runtime_forbid(struct device *dev);
+extern void pm_runtime_always_allow(struct device *dev);
+extern void pm_runtime_always_forbid(struct device *dev);
extern void pm_runtime_no_callbacks(struct device *dev);
extern void pm_runtime_irq_safe(struct device *dev);
extern void __pm_runtime_use_autosuspend(struct device *dev, bool use);
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/tegra: Allow runtime suspend on system sleep
From: Thierry Reding By default the PM core prevents devices from being runtime suspended during system sleep. This is needed to avoid some common cases where devices cannot be properly resumed because their parents are runtime suspended at an unfortunate point in time. However, there are cases where suspend/resume works in a way that it becomes possible for devices to be runtime suspended at system sleep time. In fact, for some devices runtime suspension can be equivalent to their state in system sleep. Typically this would be solved by making the runtime suspend/resume callbacks the same as the system suspend/resume callbacks. For some subsystems it isn't quite that simple, unfortunately. For example, the DRM subsystem has subsystem-level suspend/resume helpers that control how display pipelines are shut down on suspend and brought up again on resume. This procedure is the same as their operation under normal circumstances (when the user switches on/off a subset of the displays in their configuration). These helpers are carefully ordering the operations to make sure the right sequences between connectors, encoders and display controllers are respected. In order for suspend/resume to not get in the way of the sequencing that's already happening at the subsystem level, allow the devices involved in the display pipelines to runtime suspend during system sleep. Signed-off-by: Thierry Reding --- drivers/gpu/drm/tegra/dc.c | 1 + drivers/gpu/drm/tegra/dsi.c | 1 + drivers/gpu/drm/tegra/hdmi.c | 1 + drivers/gpu/drm/tegra/hub.c | 1 + drivers/gpu/drm/tegra/sor.c | 1 + 5 files changed, 5 insertions(+) diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c index 2b9a25c977c0..386819b4662b 100644 --- a/drivers/gpu/drm/tegra/dc.c +++ b/drivers/gpu/drm/tegra/dc.c @@ -2506,6 +2506,7 @@ static int tegra_dc_probe(struct platform_device *pdev) } platform_set_drvdata(pdev, dc); + pm_runtime_always_allow(>dev); pm_runtime_enable(>dev); INIT_LIST_HEAD(>client.list); diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c index a5d47e301c5f..683a27f9ba52 100644 --- a/drivers/gpu/drm/tegra/dsi.c +++ b/drivers/gpu/drm/tegra/dsi.c @@ -1552,6 +1552,7 @@ static int tegra_dsi_probe(struct platform_device *pdev) } platform_set_drvdata(pdev, dsi); + pm_runtime_always_allow(>dev); pm_runtime_enable(>dev); INIT_LIST_HEAD(>client.list); diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c index 50269ffbcb6b..2562bf607be1 100644 --- a/drivers/gpu/drm/tegra/hdmi.c +++ b/drivers/gpu/drm/tegra/hdmi.c @@ -1664,6 +1664,7 @@ static int tegra_hdmi_probe(struct platform_device *pdev) } platform_set_drvdata(pdev, hdmi); + pm_runtime_always_allow(>dev); pm_runtime_enable(>dev); INIT_LIST_HEAD(>client.list); diff --git a/drivers/gpu/drm/tegra/hub.c b/drivers/gpu/drm/tegra/hub.c index e56c0f7d3a13..aced537ac990 100644 --- a/drivers/gpu/drm/tegra/hub.c +++ b/drivers/gpu/drm/tegra/hub.c @@ -844,6 +844,7 @@ static int tegra_display_hub_probe(struct platform_device *pdev) return err; platform_set_drvdata(pdev, hub); + pm_runtime_always_allow(>dev); pm_runtime_enable(>dev); INIT_LIST_HEAD(>client.list); diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c index a68d3b36b972..20058f11bf81 100644 --- a/drivers/gpu/drm/tegra/sor.c +++ b/drivers/gpu/drm/tegra/sor.c @@ -3833,6 +3833,7 @@ static int tegra_sor_probe(struct platform_device *pdev) } platform_set_drvdata(pdev, sor); + pm_runtime_always_allow(>dev); pm_runtime_enable(>dev); /* -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/rockchip: Use drm_gem_fb_create_with_dirty
W dniu 27.11.2019 o 19:00, Daniel Vetter pisze:
If rockchip would switch over to the generic fbdev setup we could
grabage collect even more of all this code (all of the remaining fb
handling code really).
v2: Actually use _with_dirty like the patch subject promised (Andrzej)
Cc: Andrzej Pietrasiewicz
Signed-off-by: Daniel Vetter
Cc: Sandy Huang
Cc: "Heiko Stübner"
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
I understand that computing min_size is changing as per
042bf753842dd
drm/fourcc: Add char_per_block, block_w and block_h in drm_format_info.
With other questions I had before answered in your previous reply the current
version of this patch is
Reviewed-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 54 +-
1 file changed, 1 insertion(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index ca01234c037c..221e72e71432 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -53,64 +53,12 @@ rockchip_fb_alloc(struct drm_device *dev, const struct
drm_mode_fb_cmd2 *mode_cm
return fb;
}
-static struct drm_framebuffer *
-rockchip_user_fb_create(struct drm_device *dev, struct drm_file *file_priv,
- const struct drm_mode_fb_cmd2 *mode_cmd)
-{
- const struct drm_format_info *info = drm_get_format_info(dev,
-mode_cmd);
- struct drm_framebuffer *fb;
- struct drm_gem_object *objs[ROCKCHIP_MAX_FB_BUFFER];
- struct drm_gem_object *obj;
- int num_planes = min_t(int, info->num_planes, ROCKCHIP_MAX_FB_BUFFER);
- int ret;
- int i;
-
- for (i = 0; i < num_planes; i++) {
- unsigned int width = mode_cmd->width / (i ? info->hsub : 1);
- unsigned int height = mode_cmd->height / (i ? info->vsub : 1);
- unsigned int min_size;
-
- obj = drm_gem_object_lookup(file_priv, mode_cmd->handles[i]);
- if (!obj) {
- DRM_DEV_ERROR(dev->dev,
- "Failed to lookup GEM object\n");
- ret = -ENXIO;
- goto err_gem_object_unreference;
- }
-
- min_size = (height - 1) * mode_cmd->pitches[i] +
- mode_cmd->offsets[i] +
- width * info->cpp[i];
-
- if (obj->size < min_size) {
- drm_gem_object_put_unlocked(obj);
- ret = -EINVAL;
- goto err_gem_object_unreference;
- }
- objs[i] = obj;
- }
-
- fb = rockchip_fb_alloc(dev, mode_cmd, objs, i);
- if (IS_ERR(fb)) {
- ret = PTR_ERR(fb);
- goto err_gem_object_unreference;
- }
-
- return fb;
-
-err_gem_object_unreference:
- for (i--; i >= 0; i--)
- drm_gem_object_put_unlocked(objs[i]);
- return ERR_PTR(ret);
-}
-
static const struct drm_mode_config_helper_funcs rockchip_mode_config_helpers
= {
.atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
};
static const struct drm_mode_config_funcs rockchip_drm_mode_config_funcs = {
- .fb_create = rockchip_user_fb_create,
+ .fb_create = drm_gem_fb_create_with_dirty,
.output_poll_changed = drm_fb_helper_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/9] drm/tegra: vic: Export module device table
From: Thierry Reding
Export the module device table to ensure the VIC compatible strings are
listed in the module's aliases table. This in turn causes the driver to
be automatically loaded on boot if VIC is the only enabled subdevice of
the logical host1x DRM device.
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/vic.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tegra/vic.c b/drivers/gpu/drm/tegra/vic.c
index 9444ba183990..c4d82b8b3065 100644
--- a/drivers/gpu/drm/tegra/vic.c
+++ b/drivers/gpu/drm/tegra/vic.c
@@ -386,13 +386,14 @@ static const struct vic_config vic_t194_config = {
.supports_sid = true,
};
-static const struct of_device_id vic_match[] = {
+static const struct of_device_id tegra_vic_of_match[] = {
{ .compatible = "nvidia,tegra124-vic", .data = _t124_config },
{ .compatible = "nvidia,tegra210-vic", .data = _t210_config },
{ .compatible = "nvidia,tegra186-vic", .data = _t186_config },
{ .compatible = "nvidia,tegra194-vic", .data = _t194_config },
{ },
};
+MODULE_DEVICE_TABLE(of, tegra_vic_of_match);
static int vic_probe(struct platform_device *pdev)
{
@@ -516,7 +517,7 @@ static const struct dev_pm_ops vic_pm_ops = {
struct platform_driver tegra_vic_driver = {
.driver = {
.name = "tegra-vic",
- .of_match_table = vic_match,
+ .of_match_table = tegra_vic_of_match,
.pm = _pm_ops
},
.probe = vic_probe,
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/9] drm/tegra: Use proper IOVA address for cursor image
From: Thierry Reding
The IOVA address for the cursor is the result of mapping the buffer
object for the given display controller. Make sure to use the proper
IOVA address as stored in the cursor's plane state.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dc.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index d03b33c3b114..0a5f86b61fda 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -847,16 +847,15 @@ static int tegra_cursor_atomic_check(struct drm_plane
*plane,
static void tegra_cursor_atomic_update(struct drm_plane *plane,
struct drm_plane_state *old_state)
{
- struct tegra_bo *bo = tegra_fb_get_plane(plane->state->fb, 0);
+ struct tegra_plane_state *state = to_tegra_plane_state(plane->state);
struct tegra_dc *dc = to_tegra_dc(plane->state->crtc);
- struct drm_plane_state *state = plane->state;
u32 value = CURSOR_CLIP_DISPLAY;
/* rien ne va plus */
if (!plane->state->crtc || !plane->state->fb)
return;
- switch (state->crtc_w) {
+ switch (plane->state->crtc_w) {
case 32:
value |= CURSOR_SIZE_32x32;
break;
@@ -874,16 +873,16 @@ static void tegra_cursor_atomic_update(struct drm_plane
*plane,
break;
default:
- WARN(1, "cursor size %ux%u not supported\n", state->crtc_w,
-state->crtc_h);
+ WARN(1, "cursor size %ux%u not supported\n",
+plane->state->crtc_w, plane->state->crtc_h);
return;
}
- value |= (bo->iova >> 10) & 0x3f;
+ value |= (state->iova[0] >> 10) & 0x3f;
tegra_dc_writel(dc, value, DC_DISP_CURSOR_START_ADDR);
#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
- value = (bo->iova >> 32) & 0x3;
+ value = (state->iova[0] >> 32) & 0x3;
tegra_dc_writel(dc, value, DC_DISP_CURSOR_START_ADDR_HI);
#endif
@@ -902,7 +901,8 @@ static void tegra_cursor_atomic_update(struct drm_plane
*plane,
tegra_dc_writel(dc, value, DC_DISP_BLEND_CURSOR_CONTROL);
/* position the cursor */
- value = (state->crtc_y & 0x3fff) << 16 | (state->crtc_x & 0x3fff);
+ value = (plane->state->crtc_y & 0x3fff) << 16 |
+ (plane->state->crtc_x & 0x3fff);
tegra_dc_writel(dc, value, DC_DISP_CURSOR_POSITION);
}
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/9] drm/tegra: sor: Implement system suspend/resume
From: Thierry Reding
Upon system suspend, make sure the +5V HDMI regulator is disabled. This
avoids potentially leaking current to the HDMI connector. This also
makes sure that upon resume the regulator is enabled again, which in
some cases is necessary to properly restore the state of the supply on
resume.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/sor.c | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 615cb319fa8b..2200f4cd397a 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -3912,8 +3912,7 @@ static int tegra_sor_remove(struct platform_device *pdev)
return 0;
}
-#ifdef CONFIG_PM
-static int tegra_sor_suspend(struct device *dev)
+static int tegra_sor_runtime_suspend(struct device *dev)
{
struct tegra_sor *sor = dev_get_drvdata(dev);
int err;
@@ -3935,7 +3934,7 @@ static int tegra_sor_suspend(struct device *dev)
return 0;
}
-static int tegra_sor_resume(struct device *dev)
+static int tegra_sor_runtime_resume(struct device *dev)
{
struct tegra_sor *sor = dev_get_drvdata(dev);
int err;
@@ -3967,10 +3966,25 @@ static int tegra_sor_resume(struct device *dev)
return 0;
}
-#endif
+
+static int tegra_sor_suspend(struct device *dev)
+{
+ struct tegra_sor *sor = dev_get_drvdata(dev);
+
+ return regulator_disable(sor->hdmi_supply);
+}
+
+static int tegra_sor_resume(struct device *dev)
+{
+ struct tegra_sor *sor = dev_get_drvdata(dev);
+
+ return regulator_enable(sor->hdmi_supply);
+}
static const struct dev_pm_ops tegra_sor_pm_ops = {
- SET_RUNTIME_PM_OPS(tegra_sor_suspend, tegra_sor_resume, NULL)
+ SET_RUNTIME_PM_OPS(tegra_sor_runtime_suspend, tegra_sor_runtime_resume,
+ NULL)
+ SET_SYSTEM_SLEEP_PM_OPS(tegra_sor_suspend, tegra_sor_resume)
};
struct platform_driver tegra_sor_driver = {
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/9] drm/tegra: gem: Properly pin imported buffers
From: Thierry Reding
Buffers that are imported from a DMA-BUF don't have pages allocated with
them. At the same time an SG table for them can't be derived using the
DMA API helpers because the necessary information doesn't exist. However
there's already an SG table that was created during import, so this can
simply be duplicated.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/gem.c | 43 +
1 file changed, 43 insertions(+)
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 746dae32c484..6dfad56eee2b 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -27,6 +27,29 @@ static void tegra_bo_put(struct host1x_bo *bo)
drm_gem_object_put_unlocked(>gem);
}
+/* XXX move this into lib/scatterlist.c? */
+static int sg_alloc_table_from_sg(struct sg_table *sgt, struct scatterlist *sg,
+ unsigned int nents, gfp_t gfp_mask)
+{
+ struct scatterlist *dst;
+ unsigned int i;
+ int err;
+
+ err = sg_alloc_table(sgt, nents, gfp_mask);
+ if (err < 0)
+ return err;
+
+ dst = sgt->sgl;
+
+ for (i = 0; i < nents; i++) {
+ sg_set_page(dst, sg_page(sg), sg->length, 0);
+ dst = sg_next(dst);
+ sg = sg_next(sg);
+ }
+
+ return 0;
+}
+
static struct sg_table *tegra_bo_pin(struct device *dev, struct host1x_bo *bo,
dma_addr_t *phys)
{
@@ -52,11 +75,31 @@ static struct sg_table *tegra_bo_pin(struct device *dev,
struct host1x_bo *bo,
return ERR_PTR(-ENOMEM);
if (obj->pages) {
+ /*
+* If the buffer object was allocated from the explicit IOMMU
+* API code paths, construct an SG table from the pages.
+*/
err = sg_alloc_table_from_pages(sgt, obj->pages, obj->num_pages,
0, obj->gem.size, GFP_KERNEL);
if (err < 0)
goto free;
+ } else if (obj->sgt) {
+ /*
+* If the buffer object already has an SG table but no pages
+* were allocated for it, it means the buffer was imported and
+* the SG table needs to be copied to avoid overwriting any
+* other potential users of the original SG table.
+*/
+ err = sg_alloc_table_from_sg(sgt, obj->sgt->sgl,
obj->sgt->nents,
+GFP_KERNEL);
+ if (err < 0)
+ goto free;
} else {
+ /*
+* If the buffer object had no pages allocated and if it was
+* not imported, it had to be allocated with the DMA API, so
+* the DMA API helper can be used.
+*/
err = dma_get_sgtable(dev, sgt, obj->vaddr, obj->iova,
obj->gem.size);
if (err < 0)
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/9] drm/tegra: dpaux: Add missing runtime PM references
From: Thierry Reding
Ensure that a runtime PM reference is acquired each time the DPAUX
registers are accessed. Otherwise the code may end up running without
the controller being powered, out-of-reset or clocked in some corner
cases, resulting in a crash.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dpaux.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
index 622cdf1ad246..4b2b86aed1a5 100644
--- a/drivers/gpu/drm/tegra/dpaux.c
+++ b/drivers/gpu/drm/tegra/dpaux.c
@@ -434,8 +434,13 @@ static int tegra_dpaux_set_mux(struct pinctrl_dev *pinctrl,
unsigned int function, unsigned int group)
{
struct tegra_dpaux *dpaux = pinctrl_dev_get_drvdata(pinctrl);
+ int err;
+
+ pm_runtime_get_sync(dpaux->dev);
+ err = tegra_dpaux_pad_config(dpaux, function);
+ pm_runtime_put(dpaux->dev);
- return tegra_dpaux_pad_config(dpaux, function);
+ return err;
}
static const struct pinmux_ops tegra_dpaux_pinmux_ops = {
@@ -809,15 +814,22 @@ enum drm_connector_status drm_dp_aux_detect(struct
drm_dp_aux *aux)
int drm_dp_aux_enable(struct drm_dp_aux *aux)
{
struct tegra_dpaux *dpaux = to_dpaux(aux);
+ int err;
+
+ pm_runtime_get_sync(dpaux->dev);
+ err = tegra_dpaux_pad_config(dpaux, DPAUX_PADCTL_FUNC_AUX);
+ pm_runtime_put(dpaux->dev);
- return tegra_dpaux_pad_config(dpaux, DPAUX_PADCTL_FUNC_AUX);
+ return err;
}
int drm_dp_aux_disable(struct drm_dp_aux *aux)
{
struct tegra_dpaux *dpaux = to_dpaux(aux);
+ pm_runtime_get_sync(dpaux->dev);
tegra_dpaux_pad_power_down(dpaux);
+ pm_runtime_put(dpaux->dev);
return 0;
}
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/9] drm/tegra: hub: Remove bogus connection mutex check
From: Thierry Reding
I have no recollection why that check is there, but it seems to trigger
all the time, so remove it. Everything works fine without.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/hub.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/tegra/hub.c b/drivers/gpu/drm/tegra/hub.c
index 6aca0fd5a8e5..e56c0f7d3a13 100644
--- a/drivers/gpu/drm/tegra/hub.c
+++ b/drivers/gpu/drm/tegra/hub.c
@@ -615,11 +615,8 @@ static struct tegra_display_hub_state *
tegra_display_hub_get_state(struct tegra_display_hub *hub,
struct drm_atomic_state *state)
{
- struct drm_device *drm = dev_get_drvdata(hub->client.parent);
struct drm_private_state *priv;
- WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
-
priv = drm_atomic_get_private_obj_state(state, >base);
if (IS_ERR(priv))
return ERR_CAST(priv);
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/9] drm/tegra: gem: Remove premature import restrictions
From: Thierry Reding
It's not known at import time whether or not all users of a DMA-BUF will
be able to deal with non-contiguous memory. Each user needs to verify at
map-time whether it can access the buffer.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/gem.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 6dfad56eee2b..bc15b430156d 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -440,13 +440,6 @@ static struct tegra_bo *tegra_bo_import(struct drm_device
*drm,
err = tegra_bo_iommu_map(tegra, bo);
if (err < 0)
goto detach;
- } else {
- if (bo->sgt->nents > 1) {
- err = -EINVAL;
- goto detach;
- }
-
- bo->iova = sg_dma_address(bo->sgt->sgl);
}
bo->gem.import_attach = attach;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 9/9] drm/tegra: sor: Make the +5V HDMI supply optional
From: Thierry Reding
The SOR supports multiple display modes, but only when driving an HDMI
monitor does it make sense to control the +5V power supply. eDP and DP
don't need this, so make it optional.
This fixes a crash observed during system suspend/resume.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/sor.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 2200f4cd397a..a68d3b36b972 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -3970,15 +3970,29 @@ static int tegra_sor_runtime_resume(struct device *dev)
static int tegra_sor_suspend(struct device *dev)
{
struct tegra_sor *sor = dev_get_drvdata(dev);
+ int err;
+
+ if (sor->hdmi_supply) {
+ err = regulator_disable(sor->hdmi_supply);
+ if (err < 0)
+ return err;
+ }
- return regulator_disable(sor->hdmi_supply);
+ return 0;
}
static int tegra_sor_resume(struct device *dev)
{
struct tegra_sor *sor = dev_get_drvdata(dev);
+ int err;
+
+ if (sor->hdmi_supply) {
+ err = regulator_enable(sor->hdmi_supply);
+ if (err < 0)
+ return err;
+ }
- return regulator_enable(sor->hdmi_supply);
+ return 0;
}
static const struct dev_pm_ops tegra_sor_pm_ops = {
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/9] drm/tegra: Miscellaneous fixes
From: Thierry Reding Here's a random assortment of fixes for issues that I ran into as I've been testing suspend/resume and other things recently. Thierry Thierry Reding (9): drm/tegra: hub: Remove bogus connection mutex check drm/tegra: gem: Properly pin imported buffers drm/tegra: gem: Remove premature import restrictions drm/tegra: Use proper IOVA address for cursor image drm/tegra: sor: Implement system suspend/resume drm/tegra: vic: Export module device table drm/tegra: Silence expected errors on IOMMU attach drm/tegra: dpaux: Add missing runtime PM references drm/tegra: sor: Make the +5V HDMI supply optional drivers/gpu/drm/tegra/dc.c| 18 ++--- drivers/gpu/drm/tegra/dpaux.c | 16 +-- drivers/gpu/drm/tegra/drm.c | 4 +-- drivers/gpu/drm/tegra/gem.c | 50 ++- drivers/gpu/drm/tegra/hub.c | 3 --- drivers/gpu/drm/tegra/sor.c | 38 ++ drivers/gpu/drm/tegra/vic.c | 7 ++--- 7 files changed, 104 insertions(+), 32 deletions(-) -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/9] drm/tegra: Silence expected errors on IOMMU attach
From: Thierry Reding
Subdevices may not be hooked up to an IOMMU via device tree. Detect such
situations and avoid confusing users by not emitting an error message.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dc.c | 2 +-
drivers/gpu/drm/tegra/drm.c | 4 +---
drivers/gpu/drm/tegra/vic.c | 2 +-
3 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 0a5f86b61fda..2b9a25c977c0 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -2027,7 +2027,7 @@ static int tegra_dc_init(struct host1x_client *client)
dev_warn(dc->dev, "failed to allocate syncpoint\n");
err = host1x_client_iommu_attach(client);
- if (err < 0) {
+ if (err < 0 && err != -ENODEV) {
dev_err(client->dev, "failed to attach to domain: %d\n", err);
return err;
}
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 56e5e7a5c108..7a16b51eaa2d 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -920,10 +920,8 @@ int host1x_client_iommu_attach(struct host1x_client
*client)
if (tegra->domain) {
group = iommu_group_get(client->dev);
- if (!group) {
- dev_err(client->dev, "failed to get IOMMU group\n");
+ if (!group)
return -ENODEV;
- }
if (domain != tegra->domain) {
err = iommu_attach_group(tegra->domain, group);
diff --git a/drivers/gpu/drm/tegra/vic.c b/drivers/gpu/drm/tegra/vic.c
index c4d82b8b3065..3526c2892ddb 100644
--- a/drivers/gpu/drm/tegra/vic.c
+++ b/drivers/gpu/drm/tegra/vic.c
@@ -167,7 +167,7 @@ static int vic_init(struct host1x_client *client)
int err;
err = host1x_client_iommu_attach(client);
- if (err < 0) {
+ if (err < 0 && err != -ENODEV) {
dev_err(vic->dev, "failed to attach to domain: %d\n", err);
return err;
}
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 29/30] drm/bridge: add support for device links to bridge
On Tuesday, 26 November 2019 14:35:34 GMT Daniel Vetter wrote:
> On Tue, Nov 26, 2019 at 01:16:26PM +, Mihail Atanassov wrote:
> > From: Russell King
> >
> > Bridge devices have been a potential for kernel oops as their lifetime
> > is independent of the DRM device that they are bound to. Hence, if a
> > bridge device is unbound while the parent DRM device is using them, the
> > parent happily continues to use the bridge device, calling the driver
> > and accessing its objects that have been freed.
> >
> > This can cause kernel memory corruption and kernel oops.
> >
> > To control this, use device links to ensure that the parent DRM device
> > is unbound when the bridge device is unbound, and when the bridge
> > device is re-bound, automatically rebind the parent DRM device.
> >
> > Signed-off-by: Russell King
> > Tested-by: Mihail Atanassov
> > [reworked to use drm_bridge_init() for setting bridge->device]
> > Signed-off-by: Mihail Atanassov
>
> So I thought the big plan was to put the device_link setup into
> drm_bridge_attach, so that it's done for everyone. And we could then
> slowly go through the existing drivers that use the component framework to
> get this handled correctly.
>
> So my questions:
> - is there a problem if we add the device_link for everyone?
So after spending time looking at the code and thinking
about it, I'm slowly coming to the conclusion that getting device
links right for everyone in one go is a much bigger task than this
opt-in quick-fix here. I've hit, at the very least, the following
snags in trying to apply it universally:
panel_bridge - removing one via drm_of_panel_bridge_remove() uses
of_drm_find_bridge(), which would add a devlink at a very inopportune
time;
mipi_dsi_host - attach/detach, where e.g. dw-mipi-dsi.c handles bridge
creation/destruction, doesn't correspond directly to a struct device's
lifetime, so the device link would linger longer than is required;
others that add/remove bridges at times different from probe/remove
(drivers using the component framework?).
I think it'd still be valuable even with limiting the scope to drivers
that get their bridge in probe() and drop it in remove() for now, and
only roll it out as an opt-in. Thoughts?
I think to get it right we need to use the links' refcount, with e.g.
of_drm_find_bridge() giving you a refcount of 1, and bridge_detach()
maybe dropping the refcount, but I can envision ways where this breaks
too, so maybe just an of_drm_{get,put}_bridge()?
> - is there an issue if we only add it at drm_bridge_attach time? I kinda
> assumed that it's not needed before that (EPROBE_DEFER should handle
> load dependencies as before), but it could be that some drivers ask for
> a bridge and then check more stuff and then drop the bridge without
> calling drm_bridge_attach. We probably don't have a case like this yet,
> but better robust than sorry.
>
> Anyway, I scrolled through the bridge patches, looked all good, huge
> thanks for tackling this! Once we have some agreement on the bigger
> questions here I'll try to go through them and review.
>
> Cheers, Daniel
> > ---
> > drivers/gpu/drm/drm_bridge.c | 49 ++--
> > include/drm/drm_bridge.h | 4 +++
> > 2 files changed, 40 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > index cbe680aa6eac..e1f8db84651a 100644
> > --- a/drivers/gpu/drm/drm_bridge.c
> > +++ b/drivers/gpu/drm/drm_bridge.c
> > @@ -26,6 +26,7 @@
> > #include
> >
> > #include
> > +#include
> > #include
> >
> > #include "drm_crtc_internal.h"
> > @@ -109,6 +110,7 @@ void drm_bridge_init(struct drm_bridge *bridge, struct
> > device *dev,
> > bridge->encoder = NULL;
> > bridge->next = NULL;
> >
> > + bridge->device = dev;
> > #ifdef CONFIG_OF
> > bridge->of_node = dev->of_node;
> > #endif
> > @@ -492,6 +494,32 @@ void drm_atomic_bridge_enable(struct drm_bridge
> > *bridge,
> > EXPORT_SYMBOL(drm_atomic_bridge_enable);
> >
> > #ifdef CONFIG_OF
> > +static struct drm_bridge *drm_bridge_find(struct drm_device *dev,
> > + struct device_node *np, bool link)
> > +{
> > + struct drm_bridge *bridge, *found = NULL;
> > + struct device_link *dl;
> > +
> > + mutex_lock(_lock);
> > +
> > + list_for_each_entry(bridge, _list, list)
> > + if (bridge->of_node == np) {
> > + found = bridge;
> > + break;
> > + }
> > +
> > + if (found && link) {
> > + dl = device_link_add(dev->dev, found->device,
> > +DL_FLAG_AUTOPROBE_CONSUMER);
> > + if (!dl)
> > + found = NULL;
> > + }
> > +
> > + mutex_unlock(_lock);
> > +
> > + return found;
> > +}
> > +
> > /**
> > * of_drm_find_bridge - find the bridge corresponding to the device node in
> > * the global bridge list
> > @@
[Bug 205661] Upgrade to 5.4 from K5.3.13 fails x2 attempts
https://bugzilla.kernel.org/show_bug.cgi?id=205661 --- Comment #1 from Jani Nikula (jani.nik...@intel.com) --- FYI, the bugzilla is for upstream kernel, not out-of-tree code. -- 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] drm/i915: Provide ddc symlink in hdmi connector sysfs directory
Use the ddc pointer provided by the generic connector. Signed-off-by: Andrzej Pietrasiewicz Acked-by: Sam Ravnborg Reviewed-by: Emil Velikov --- Rebased onto drm-intel-next-queued. drivers/gpu/drm/i915/display/intel_hdmi.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c index 29a174af5314..6ec8d14bccd7 100644 --- a/drivers/gpu/drm/i915/display/intel_hdmi.c +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c @@ -3134,6 +3134,7 @@ void intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port, struct intel_encoder *intel_encoder = _dig_port->base; struct drm_device *dev = intel_encoder->base.dev; struct drm_i915_private *dev_priv = to_i915(dev); + struct i2c_adapter *ddc; enum port port = intel_encoder->port; struct cec_connector_info conn_info; @@ -3149,8 +3150,13 @@ void intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port, intel_encoder->base.name)) return; - drm_connector_init(dev, connector, _hdmi_connector_funcs, - DRM_MODE_CONNECTOR_HDMIA); + intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port); + ddc = intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus); + + drm_connector_init_with_ddc(dev, connector, + _hdmi_connector_funcs, + DRM_MODE_CONNECTOR_HDMIA, + ddc); drm_connector_helper_add(connector, _hdmi_connector_helper_funcs); connector->interlace_allowed = 1; @@ -3160,8 +3166,6 @@ void intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port, if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) connector->ycbcr_420_allowed = true; - intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port); - intel_encoder->hpd_pin = intel_hpd_pin_default(dev_priv, port); if (HAS_DDI(dev_priv)) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] drm/amd/display: Remove unneeded semicolon
Series is Reviewed-by: Harry Wentland Harry On 2019-11-27 9:31 p.m., zhengbin wrote: > zhengbin (4): > drm/amd/display: Remove unneeded semicolon in bios_parser.c > drm/amd/display: Remove unneeded semicolon in bios_parser2.c > drm/amd/display: Remove unneeded semicolon in hdcp.c > drm/amd/display: Remove unneeded semicolon in display_rq_dlg_calc_21.c > > drivers/gpu/drm/amd/display/dc/bios/bios_parser.c | 2 +- > drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c| 2 +- > drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c | 4 ++-- > drivers/gpu/drm/amd/display/modules/hdcp/hdcp.c | 2 +- > 4 files changed, 5 insertions(+), 5 deletions(-) > > -- > 2.7.4 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] drm/mgag200: Add workaround for HW that does not support 'startadd'
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 81da87f63a1e ("drm: Replace drm_gem_vram_push_to_system() with
kunmap + unpin").
The bot has tested the following trees: v5.3.13.
v5.3.13: Build failed! Errors:
drivers/gpu/drm/mgag200/mgag200_drv.c:104:18: error:
âdrm_vram_mm_debugfs_initâ undeclared here (not in a function); did you
mean âdrm_client_debugfs_initâ?
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks,
Sasha
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/3] drm/mgag200: Store flags from PCI driver data in device structure
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 81da87f63a1e ("drm: Replace drm_gem_vram_push_to_system() with
kunmap + unpin").
The bot has tested the following trees: v5.3.13.
v5.3.13: Failed to apply! Possible dependencies:
1c355c0ecfc0 ("drm/mgag200: Extract device type from flags")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks,
Sasha
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/7] drm/udl: Move udl_handle_damage() into udl_modeset.c
On Tue, Nov 26, 2019 at 02:47:07PM +0100, Thomas Zimmermann wrote:
> The only caller of udl_handle_damage() in the plane-update function
> in udl_modeset.c. Move udl_handle_damage() there, make it static, and
> remove several left-over macros.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/udl/Makefile | 2 +-
> drivers/gpu/drm/udl/udl_drv.h | 3 -
> drivers/gpu/drm/udl/udl_fb.c | 142 --
> drivers/gpu/drm/udl/udl_modeset.c | 88 ++
> 4 files changed, 89 insertions(+), 146 deletions(-)
> delete mode 100644 drivers/gpu/drm/udl/udl_fb.c
>
> diff --git a/drivers/gpu/drm/udl/Makefile b/drivers/gpu/drm/udl/Makefile
> index 177ce74f4cf4..b50179bb4de0 100644
> --- a/drivers/gpu/drm/udl/Makefile
> +++ b/drivers/gpu/drm/udl/Makefile
> @@ -1,4 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0-only
> -udl-y := udl_drv.o udl_modeset.o udl_connector.o udl_main.o udl_fb.o
> udl_transfer.o udl_gem.o
> +udl-y := udl_drv.o udl_modeset.o udl_connector.o udl_main.o udl_transfer.o
> udl_gem.o
>
> obj-$(CONFIG_DRM_UDL) := udl.o
> diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
> index e540f8e64aa1..ab62a6aecd06 100644
> --- a/drivers/gpu/drm/udl/udl_drv.h
> +++ b/drivers/gpu/drm/udl/udl_drv.h
> @@ -93,9 +93,6 @@ int udl_render_hline(struct drm_device *dev, int log_bpp,
> struct urb **urb_ptr,
> struct drm_gem_object *udl_driver_gem_create_object(struct drm_device *dev,
> size_t size);
>
> -int udl_handle_damage(struct drm_framebuffer *fb, int x, int y,
> - int width, int height);
> -
> int udl_drop_usb(struct drm_device *dev);
>
> #define CMD_WRITE_RAW8 "\xAF\x60" /**< 8 bit raw write command. */
> diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
> deleted file mode 100644
> index 3d8cf674dfa5..
> --- a/drivers/gpu/drm/udl/udl_fb.c
> +++ /dev/null
> @@ -1,142 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0-only
> -/*
> - * Copyright (C) 2012 Red Hat
> - *
> - * based in parts on udlfb.c:
> - * Copyright (C) 2009 Roberto De Ioris
> - * Copyright (C) 2009 Jaya Kumar
> - * Copyright (C) 2009 Bernie Thompson
> - */
> -
> -#include
> -
> -#include
> -#include
> -
> -#include "udl_drv.h"
> -
> -#define DL_ALIGN_UP(x, a) ALIGN(x, a)
> -#define DL_ALIGN_DOWN(x, a) ALIGN_DOWN(x, a)
> -
> -/** Read the red component (0..255) of a 32 bpp colour. */
> -#define DLO_RGB_GETRED(col) (uint8_t)((col) & 0xFF)
> -
> -/** Read the green component (0..255) of a 32 bpp colour. */
> -#define DLO_RGB_GETGRN(col) (uint8_t)(((col) >> 8) & 0xFF)
> -
> -/** Read the blue component (0..255) of a 32 bpp colour. */
> -#define DLO_RGB_GETBLU(col) (uint8_t)(((col) >> 16) & 0xFF)
> -
> -/** Return red/green component of a 16 bpp colour number. */
> -#define DLO_RG16(red, grn) (uint8_t)red) & 0xF8) | ((grn) >> 5)) & 0xFF)
> -
> -/** Return green/blue component of a 16 bpp colour number. */
> -#define DLO_GB16(grn, blu) (uint8_t)(grn) & 0x1C) << 3) | ((blu) >> 3))
> & 0xFF)
> -
> -/** Return 8 bpp colour number from red, green and blue components. */
> -#define DLO_RGB8(red, grn, blu) red) << 5) | (((grn) & 3) << 3) | ((blu)
> & 7)) & 0xFF)
> -
> -#if 0
> -static uint8_t rgb8(uint32_t col)
> -{
> - uint8_t red = DLO_RGB_GETRED(col);
> - uint8_t grn = DLO_RGB_GETGRN(col);
> - uint8_t blu = DLO_RGB_GETBLU(col);
> -
> - return DLO_RGB8(red, grn, blu);
> -}
> -
> -static uint16_t rgb16(uint32_t col)
> -{
> - uint8_t red = DLO_RGB_GETRED(col);
> - uint8_t grn = DLO_RGB_GETGRN(col);
> - uint8_t blu = DLO_RGB_GETBLU(col);
> -
> - return (DLO_RG16(red, grn) << 8) + DLO_GB16(grn, blu);
> -}
> -#endif
> -
> -int udl_handle_damage(struct drm_framebuffer *fb, int x, int y,
> - int width, int height)
> -{
> - struct drm_device *dev = fb->dev;
> - struct udl_device *udl = to_udl(dev);
> - int i, ret;
> - char *cmd;
> - cycles_t start_cycles, end_cycles;
> - int bytes_sent = 0;
> - int bytes_identical = 0;
> - struct urb *urb;
> - int aligned_x;
> - int log_bpp;
> - void *vaddr;
> -
> - if (WARN_ON(!is_power_of_2(fb->format->cpp[0])))
> - return -EINVAL;
> -
> - log_bpp = __ffs(fb->format->cpp[0]);
> -
> - vaddr = drm_gem_shmem_vmap(fb->obj[0]);
> - if (IS_ERR(vaddr)) {
> - DRM_ERROR("failed to vmap fb\n");
> - return 0;
> - }
> -
> - aligned_x = DL_ALIGN_DOWN(x, sizeof(unsigned long));
> - width = DL_ALIGN_UP(width + (x-aligned_x), sizeof(unsigned long));
> - x = aligned_x;
> -
> - if ((width <= 0) ||
> - (x + width > fb->width) ||
> - (y + height > fb->height)) {
> - ret = -EINVAL;
> - goto err_drm_gem_shmem_vunmap;
> - }
> -
> - start_cycles = get_cycles();
> -
> - urb = udl_get_urb(dev);
>
[PULL] drm-intel-next-fixes
Hi Dave & Daniel, Most importantly we have the fix to power regression that was introduced by the security fixes. Then fix for query uAPI and increase in request pre-emption timeout to accommodate super heavy benchmarks. Couple of display voltage programming fixes too. Thanks to Chris for fixing the power regression on such tight schedule. Regards, Joonas *** drm-intel-next-fixes-2019-11-28: - Important fix to uAPI alignment on query IOCTL - Fixes for the power regression introduced by the previous security patches - Avoid regressing super heavy benchmarks by increasing the default request pre-emption timeout from 100 ms to 640 ms to - Resulting set of smaller fixes done while problem was inspected - Display fixes for EHL voltage level programming and TGL DKL PHY vswing for HDMI The following changes since commit 15b9cbb2c5e1cf22c13fe38bf513bab821b47630: Revert "drm/i915/gt: Wait for new requests in intel_gt_retire_requests()" (2019-11-22 17:24:22 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2019-11-28 for you to fetch changes up to 3cc44feb9861d2f5267af9b962ae92c5ea1b48fd: drm/i915: Reduce nested prepare_remote_context() to a trylock (2019-11-27 10:12:19 +0200) - Important fix to uAPI alignment on query IOCTL - Fixes for the power regression introduced by the previous security patches - Avoid regressing super heavy benchmarks by increasing the default request pre-emption timeout from 100 ms to 640 ms to - Resulting set of smaller fixes done while problem was inspected - Display fixes for EHL voltage level programming and TGL DKL PHY vswing for HDMI Chris Wilson (12): drm/i915/gt: Fixup config ifdeffery for pm_suspend_target_state drm/i915: Wait until the intel_wakeref idle callback is complete drm/i915: Mark up the calling context for intel_wakeref_put() drm/i915/gt: Close race between engine_park and intel_gt_retire_requests drm/i915/gt: Unlock engine-pm after queuing the kernel context switch drm/i915/gt: Mark the execlists->active as the primary volatile access drm/i915/execlists: Fixup cancel_port_requests() drm/i915/gt: Adapt engine_park synchronisation rules for engine_retire drm/i915/gt: Schedule request retirement when timeline idles drm/i915/gt: Make intel_ring_unpin() safe for concurrent pint drm/i915: Default to a more lenient forced preemption timeout drm/i915: Reduce nested prepare_remote_context() to a trylock Matt Roper (2): drm/i915/ehl: Update voltage level checks drm/i915/tgl: Add DKL PHY vswing table for HDMI Tvrtko Ursulin (1): drm/i915/query: Align flavour of engine data lookup drivers/gpu/drm/i915/Kconfig.profile | 2 +- drivers/gpu/drm/i915/display/intel_cdclk.c | 4 +- drivers/gpu/drm/i915/display/intel_ddi.c | 29 +++-- drivers/gpu/drm/i915/gt/intel_context.c| 21 +-- drivers/gpu/drm/i915/gt/intel_engine.h | 4 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 8 ++- drivers/gpu/drm/i915/gt/intel_engine_pm.c | 67 ++--- drivers/gpu/drm/i915/gt/intel_engine_pm.h | 10 drivers/gpu/drm/i915/gt/intel_engine_types.h | 8 +++ drivers/gpu/drm/i915/gt/intel_gt_pm.c | 3 +- drivers/gpu/drm/i915/gt/intel_gt_pm.h | 5 ++ drivers/gpu/drm/i915/gt/intel_gt_requests.c| 83 -- drivers/gpu/drm/i915/gt/intel_gt_requests.h| 7 +++ drivers/gpu/drm/i915/gt/intel_lrc.c| 50 ++-- drivers/gpu/drm/i915/gt/intel_reset.c | 2 +- drivers/gpu/drm/i915/gt/intel_ring.c | 13 ++-- drivers/gpu/drm/i915/gt/intel_timeline.c | 35 --- drivers/gpu/drm/i915/gt/intel_timeline_types.h | 5 +- drivers/gpu/drm/i915/gt/selftest_engine_pm.c | 7 ++- drivers/gpu/drm/i915/i915_active.c | 5 +- drivers/gpu/drm/i915/i915_pmu.c| 6 +- drivers/gpu/drm/i915/i915_query.c | 7 ++- drivers/gpu/drm/i915/intel_wakeref.c | 21 +-- drivers/gpu/drm/i915/intel_wakeref.h | 45 +++--- 24 files changed, 354 insertions(+), 93 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/7] drm/udl: Remove struct udl_device.active_fb_16
On Tue, Nov 26, 2019 at 02:47:06PM +0100, Thomas Zimmermann wrote:
> The udl driver stores the currently active framebuffer to know from
> where to accept damage updates.
>
> With the conversion to plane-state damage handling, this is not necessary
> any longer. The currently active framebuffer and damaged area are always
> stored in the plane state.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Imo makes sense to garbage-collect that as a follow-up since it's not
really functional stuff, so doesn't make sense to squash that into the
previous patch.
-Daniel
> ---
> drivers/gpu/drm/udl/udl_drv.h | 4
> drivers/gpu/drm/udl/udl_fb.c | 7 ---
> drivers/gpu/drm/udl/udl_main.c| 3 ---
> drivers/gpu/drm/udl/udl_modeset.c | 9 -
> 4 files changed, 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
> index c6fd5c08f5fc..e540f8e64aa1 100644
> --- a/drivers/gpu/drm/udl/udl_drv.h
> +++ b/drivers/gpu/drm/udl/udl_drv.h
> @@ -55,10 +55,6 @@ struct udl_device {
>
> struct drm_simple_display_pipe display_pipe;
>
> - /* active framebuffer on the 16-bit channel */
> - const struct drm_framebuffer *active_fb_16;
> - spinlock_t active_fb_16_lock;
> -
> struct mutex gem_lock;
>
> int sku_pixel_limit;
> diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
> index ed01ebaaf468..3d8cf674dfa5 100644
> --- a/drivers/gpu/drm/udl/udl_fb.c
> +++ b/drivers/gpu/drm/udl/udl_fb.c
> @@ -76,13 +76,6 @@ int udl_handle_damage(struct drm_framebuffer *fb, int x,
> int y,
>
> log_bpp = __ffs(fb->format->cpp[0]);
>
> - spin_lock(>active_fb_16_lock);
> - if (udl->active_fb_16 != fb) {
> - spin_unlock(>active_fb_16_lock);
> - return 0;
> - }
> - spin_unlock(>active_fb_16_lock);
> -
> vaddr = drm_gem_shmem_vmap(fb->obj[0]);
> if (IS_ERR(vaddr)) {
> DRM_ERROR("failed to vmap fb\n");
> diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
> index a23218fc7d8e..9b091b5b063e 100644
> --- a/drivers/gpu/drm/udl/udl_main.c
> +++ b/drivers/gpu/drm/udl/udl_main.c
> @@ -317,9 +317,6 @@ int udl_init(struct udl_device *udl)
>
> DRM_DEBUG("\n");
>
> - udl->active_fb_16 = NULL;
> - spin_lock_init(>active_fb_16_lock);
> -
> mutex_init(>gem_lock);
>
> if (!udl_parse_vendor_descriptor(dev, udl->udev)) {
> diff --git a/drivers/gpu/drm/udl/udl_modeset.c
> b/drivers/gpu/drm/udl/udl_modeset.c
> index aade61ad097b..83e80083e0b2 100644
> --- a/drivers/gpu/drm/udl/udl_modeset.c
> +++ b/drivers/gpu/drm/udl/udl_modeset.c
> @@ -333,9 +333,6 @@ udl_simple_display_pipe_enable(struct
> drm_simple_display_pipe *pipe,
>
> wrptr = udl_dummy_render(wrptr);
>
> - spin_lock(>active_fb_16_lock);
> - udl->active_fb_16 = fb;
> - spin_unlock(>active_fb_16_lock);
> udl->mode_buf_len = wrptr - buf;
>
> udl_handle_damage(fb, 0, 0, fb->width, fb->height);
> @@ -363,16 +360,10 @@ static void
> udl_simple_display_pipe_update(struct drm_simple_display_pipe *pipe,
> struct drm_plane_state *old_plane_state)
> {
> - struct drm_device *dev = pipe->crtc.dev;
> - struct udl_device *udl = dev->dev_private;
> struct drm_plane_state *state = pipe->plane.state;
> struct drm_framebuffer *fb = state->fb;
> struct drm_rect rect;
>
> - spin_lock(>active_fb_16_lock);
> - udl->active_fb_16 = fb;
> - spin_unlock(>active_fb_16_lock);
> -
> if (!fb)
> return;
>
> --
> 2.23.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/7] drm/udl: Convert to drm_atomic_helper_dirtyfb()
On Tue, Nov 26, 2019 at 02:47:05PM +0100, Thomas Zimmermann wrote:
> The infrastruture for atomic modesetting allows us to use the generic
> code for dirty-FB and damage handling. Switch over udl and remove the
> driver's implementation.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/udl/udl_drv.h | 5 ---
> drivers/gpu/drm/udl/udl_fb.c | 67 ---
> drivers/gpu/drm/udl/udl_modeset.c | 11 +++--
> 3 files changed, 8 insertions(+), 75 deletions(-)
>
> diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
> index 77b57d6abd23..c6fd5c08f5fc 100644
> --- a/drivers/gpu/drm/udl/udl_drv.h
> +++ b/drivers/gpu/drm/udl/udl_drv.h
> @@ -89,11 +89,6 @@ void udl_urb_completion(struct urb *urb);
> int udl_init(struct udl_device *udl);
> void udl_fini(struct drm_device *dev);
>
> -struct drm_framebuffer *
> -udl_fb_user_fb_create(struct drm_device *dev,
> - struct drm_file *file,
> - const struct drm_mode_fb_cmd2 *mode_cmd);
> -
> int udl_render_hline(struct drm_device *dev, int log_bpp, struct urb
> **urb_ptr,
>const char *front, char **urb_buf_ptr,
>u32 byte_offset, u32 device_byte_offset, u32 byte_width,
> diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
> index c1996ac73a1f..ed01ebaaf468 100644
> --- a/drivers/gpu/drm/udl/udl_fb.c
> +++ b/drivers/gpu/drm/udl/udl_fb.c
> @@ -9,14 +9,9 @@
> */
>
> #include
> -#include
>
> -#include
> -#include
> #include
> -#include
> #include
> -#include
>
> #include "udl_drv.h"
>
> @@ -152,65 +147,3 @@ int udl_handle_damage(struct drm_framebuffer *fb, int x,
> int y,
> drm_gem_shmem_vunmap(fb->obj[0], vaddr);
> return ret;
> }
> -
> -static int udl_user_framebuffer_dirty(struct drm_framebuffer *fb,
> - struct drm_file *file,
> - unsigned flags, unsigned color,
> - struct drm_clip_rect *clips,
> - unsigned num_clips)
> -{
> - struct udl_device *udl = fb->dev->dev_private;
> - struct dma_buf_attachment *import_attach;
> - int i;
> - int ret = 0;
> -
> - drm_modeset_lock_all(fb->dev);
> -
> - spin_lock(>active_fb_16_lock);
> - if (udl->active_fb_16 != fb) {
> - spin_unlock(>active_fb_16_lock);
> - goto unlock;
> - }
> - spin_unlock(>active_fb_16_lock);
> -
> - import_attach = fb->obj[0]->import_attach;
> -
> - if (import_attach) {
> - ret = dma_buf_begin_cpu_access(import_attach->dmabuf,
> -DMA_FROM_DEVICE);
> - if (ret)
> - goto unlock;
> - }
> -
> - for (i = 0; i < num_clips; i++) {
> - ret = udl_handle_damage(fb, clips[i].x1, clips[i].y1,
> - clips[i].x2 - clips[i].x1,
> - clips[i].y2 - clips[i].y1);
> - if (ret)
> - break;
> - }
> -
> - if (import_attach)
> - ret = dma_buf_end_cpu_access(import_attach->dmabuf,
> - DMA_FROM_DEVICE);
> -
> - unlock:
> - drm_modeset_unlock_all(fb->dev);
> -
> - return ret;
> -}
> -
> -static const struct drm_framebuffer_funcs udlfb_funcs = {
> - .destroy= drm_gem_fb_destroy,
> - .create_handle = drm_gem_fb_create_handle,
> - .dirty = udl_user_framebuffer_dirty,
> -};
> -
> -struct drm_framebuffer *
> -udl_fb_user_fb_create(struct drm_device *dev,
> -struct drm_file *file,
> -const struct drm_mode_fb_cmd2 *mode_cmd)
> -{
> - return drm_gem_fb_create_with_funcs(dev, file, mode_cmd,
> - _funcs);
> -}
> diff --git a/drivers/gpu/drm/udl/udl_modeset.c
> b/drivers/gpu/drm/udl/udl_modeset.c
> index 1b5a46a91cb4..aade61ad097b 100644
> --- a/drivers/gpu/drm/udl/udl_modeset.c
> +++ b/drivers/gpu/drm/udl/udl_modeset.c
> @@ -11,6 +11,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -364,7 +365,9 @@ udl_simple_display_pipe_update(struct
> drm_simple_display_pipe *pipe,
> {
> struct drm_device *dev = pipe->crtc.dev;
> struct udl_device *udl = dev->dev_private;
> - struct drm_framebuffer *fb = pipe->plane.state->fb;
> + struct drm_plane_state *state = pipe->plane.state;
> + struct drm_framebuffer *fb = state->fb;
> + struct drm_rect rect;
>
> spin_lock(>active_fb_16_lock);
> udl->active_fb_16 = fb;
> @@ -373,7 +376,9 @@ udl_simple_display_pipe_update(struct
> drm_simple_display_pipe *pipe,
> if (!fb)
> return;
>
> - udl_handle_damage(fb, 0, 0, fb->width, fb->height);
> + if (drm_atomic_helper_damage_merged(old_plane_state, state, ))
> +
Re: [PATCH 3/7] drm/udl: Remove unused encoder and CRTC code
On Tue, Nov 26, 2019 at 02:47:03PM +0100, Thomas Zimmermann wrote:
> The removed functionality is provided by simple-pipe helpers.
>
> Signed-off-by: Thomas Zimmermann
Needs to be squashed into the previous patch, ideally with the new
functions in the same place as the old ones (as much as possible), so that
diff reviewing is easier. If you feel like that makes the previous patch
too big, split out the suspend/resume refactor.
-Daniel
> ---
> drivers/gpu/drm/udl/Makefile | 2 +-
> drivers/gpu/drm/udl/udl_drv.h | 3 -
> drivers/gpu/drm/udl/udl_encoder.c | 70 ---
> drivers/gpu/drm/udl/udl_modeset.c | 138 --
> 4 files changed, 1 insertion(+), 212 deletions(-)
> delete mode 100644 drivers/gpu/drm/udl/udl_encoder.c
>
> diff --git a/drivers/gpu/drm/udl/Makefile b/drivers/gpu/drm/udl/Makefile
> index 9c42820ae33d..177ce74f4cf4 100644
> --- a/drivers/gpu/drm/udl/Makefile
> +++ b/drivers/gpu/drm/udl/Makefile
> @@ -1,4 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0-only
> -udl-y := udl_drv.o udl_modeset.o udl_connector.o udl_encoder.o udl_main.o
> udl_fb.o udl_transfer.o udl_gem.o
> +udl-y := udl_drv.o udl_modeset.o udl_connector.o udl_main.o udl_fb.o
> udl_transfer.o udl_gem.o
>
> obj-$(CONFIG_DRM_UDL) := udl.o
> diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
> index 23346bdc74bc..77b57d6abd23 100644
> --- a/drivers/gpu/drm/udl/udl_drv.h
> +++ b/drivers/gpu/drm/udl/udl_drv.h
> @@ -19,7 +19,6 @@
> #include
> #include
>
> -struct drm_encoder;
> struct drm_mode_create_dumb;
>
> #define DRIVER_NAME "udl"
> @@ -82,8 +81,6 @@ int udl_modeset_init(struct drm_device *dev);
> void udl_modeset_cleanup(struct drm_device *dev);
> struct drm_connector *udl_connector_init(struct drm_device *dev);
>
> -struct drm_encoder *udl_encoder_init(struct drm_device *dev);
> -
> struct urb *udl_get_urb(struct drm_device *dev);
>
> int udl_submit_urb(struct drm_device *dev, struct urb *urb, size_t len);
> diff --git a/drivers/gpu/drm/udl/udl_encoder.c
> b/drivers/gpu/drm/udl/udl_encoder.c
> deleted file mode 100644
> index 203f041e737c..
> --- a/drivers/gpu/drm/udl/udl_encoder.c
> +++ /dev/null
> @@ -1,70 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0-only
> -/*
> - * Copyright (C) 2012 Red Hat
> - * based in parts on udlfb.c:
> - * Copyright (C) 2009 Roberto De Ioris
> - * Copyright (C) 2009 Jaya Kumar
> - * Copyright (C) 2009 Bernie Thompson
> - */
> -
> -#include
> -#include
> -
> -#include "udl_drv.h"
> -
> -/* dummy encoder */
> -static void udl_enc_destroy(struct drm_encoder *encoder)
> -{
> - drm_encoder_cleanup(encoder);
> - kfree(encoder);
> -}
> -
> -static void udl_encoder_disable(struct drm_encoder *encoder)
> -{
> -}
> -
> -static void udl_encoder_prepare(struct drm_encoder *encoder)
> -{
> -}
> -
> -static void udl_encoder_commit(struct drm_encoder *encoder)
> -{
> -}
> -
> -static void udl_encoder_mode_set(struct drm_encoder *encoder,
> - struct drm_display_mode *mode,
> - struct drm_display_mode *adjusted_mode)
> -{
> -}
> -
> -static void
> -udl_encoder_dpms(struct drm_encoder *encoder, int mode)
> -{
> -}
> -
> -static const struct drm_encoder_helper_funcs udl_helper_funcs = {
> - .dpms = udl_encoder_dpms,
> - .prepare = udl_encoder_prepare,
> - .mode_set = udl_encoder_mode_set,
> - .commit = udl_encoder_commit,
> - .disable = udl_encoder_disable,
> -};
> -
> -static const struct drm_encoder_funcs udl_enc_funcs = {
> - .destroy = udl_enc_destroy,
> -};
> -
> -struct drm_encoder *udl_encoder_init(struct drm_device *dev)
> -{
> - struct drm_encoder *encoder;
> -
> - encoder = kzalloc(sizeof(struct drm_encoder), GFP_KERNEL);
> - if (!encoder)
> - return NULL;
> -
> - drm_encoder_init(dev, encoder, _enc_funcs, DRM_MODE_ENCODER_TMDS,
> - NULL);
> - drm_encoder_helper_add(encoder, _helper_funcs);
> - encoder->possible_crtcs = 1;
> - return encoder;
> -}
> diff --git a/drivers/gpu/drm/udl/udl_modeset.c
> b/drivers/gpu/drm/udl/udl_modeset.c
> index c8bd438de6e9..72884cbda131 100644
> --- a/drivers/gpu/drm/udl/udl_modeset.c
> +++ b/drivers/gpu/drm/udl/udl_modeset.c
> @@ -281,144 +281,6 @@ static void udl_crtc_dpms(struct drm_crtc *crtc, int
> mode)
>
> }
>
> -#if 0
> -static int
> -udl_pipe_set_base_atomic(struct drm_crtc *crtc, struct drm_framebuffer *fb,
> -int x, int y, enum mode_set_atomic state)
> -{
> - return 0;
> -}
> -
> -static int
> -udl_pipe_set_base(struct drm_crtc *crtc, int x, int y,
> - struct drm_framebuffer *old_fb)
> -{
> - return 0;
> -}
> -#endif
> -
> -static int udl_crtc_mode_set(struct drm_crtc *crtc,
> -struct drm_display_mode *mode,
> -struct drm_display_mode *adjusted_mode,
> -int
Re: [PATCH 2/7] drm/udl: Convert to struct drm_simple_display_pipe
On Tue, Nov 26, 2019 at 02:47:02PM +0100, Thomas Zimmermann wrote:
> Udl has a single display pipeline with aprimary plane; perfect for
> simple-pipe helpers. Convert it over. The old encoder and CRTC code
> becomes unused and obsolete.
>
> Exported formats for the primary plane are RGB565 and XRGB, with
> the latter being emulated. The 16-bit format is the default and what
> is used when communicating with the device.
>
> This patch enables atomic modesetting for udl devices.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/udl/udl_connector.c | 12 +--
> drivers/gpu/drm/udl/udl_drv.c | 9 +-
> drivers/gpu/drm/udl/udl_drv.h | 4 +-
> drivers/gpu/drm/udl/udl_modeset.c | 142
> 4 files changed, 136 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/udl/udl_connector.c
> b/drivers/gpu/drm/udl/udl_connector.c
> index 68e113ae44f7..47ab8d150f1a 100644
> --- a/drivers/gpu/drm/udl/udl_connector.c
> +++ b/drivers/gpu/drm/udl/udl_connector.c
> @@ -7,6 +7,7 @@
> * Copyright (C) 2009 Bernie Thompson
> */
>
> +#include
> #include
> #include
>
> @@ -90,13 +91,6 @@ udl_detect(struct drm_connector *connector, bool force)
> return connector_status_connected;
> }
>
> -static int udl_connector_set_property(struct drm_connector *connector,
> - struct drm_property *property,
> - uint64_t val)
> -{
> - return 0;
> -}
> -
> static void udl_connector_destroy(struct drm_connector *connector)
> {
> struct udl_drm_connector *udl_connector =
> @@ -117,10 +111,12 @@ static const struct drm_connector_helper_funcs
> udl_connector_helper_funcs = {
>
> static const struct drm_connector_funcs udl_connector_funcs = {
> .dpms = drm_helper_connector_dpms,
> + .reset = drm_atomic_helper_connector_reset,
> .detect = udl_detect,
> .fill_modes = drm_helper_probe_single_connector_modes,
> .destroy = udl_connector_destroy,
> - .set_property = udl_connector_set_property,
> + .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> };
>
> struct drm_connector *udl_connector_init(struct drm_device *dev)
> diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
> index d5783fa32c5b..b3fa6bf41acc 100644
> --- a/drivers/gpu/drm/udl/udl_drv.c
> +++ b/drivers/gpu/drm/udl/udl_drv.c
> @@ -21,17 +21,14 @@ static int udl_usb_suspend(struct usb_interface
> *interface,
> {
> struct drm_device *dev = usb_get_intfdata(interface);
>
> - drm_kms_helper_poll_disable(dev);
> - return 0;
> + return drm_mode_config_helper_suspend(dev);
> }
>
> static int udl_usb_resume(struct usb_interface *interface)
> {
> struct drm_device *dev = usb_get_intfdata(interface);
>
> - drm_kms_helper_poll_enable(dev);
> - udl_modeset_restore(dev);
> - return 0;
> + return drm_mode_config_helper_resume(dev);
Please mention in the commit message that you're also switching over to
the atomic-based generic suspend/resume helpers. Might even want to split
that out as a separate patch (but will require minor adjustements in
udl_modeset_restore).
> }
>
> DEFINE_DRM_GEM_FOPS(udl_driver_fops);
> @@ -45,7 +42,7 @@ static void udl_driver_release(struct drm_device *dev)
> }
>
> static struct drm_driver driver = {
> - .driver_features = DRIVER_MODESET | DRIVER_GEM,
> + .driver_features = DRIVER_ATOMIC | DRIVER_GEM | DRIVER_MODESET,
> .release = udl_driver_release,
>
> /* gem hooks */
> diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
> index 8dc04717abac..23346bdc74bc 100644
> --- a/drivers/gpu/drm/udl/udl_drv.h
> +++ b/drivers/gpu/drm/udl/udl_drv.h
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
>
> struct drm_encoder;
> struct drm_mode_create_dumb;
> @@ -53,6 +54,8 @@ struct udl_device {
> struct usb_device *udev;
> struct drm_crtc *crtc;
>
> + struct drm_simple_display_pipe display_pipe;
> +
> /* active framebuffer on the 16-bit channel */
> const struct drm_framebuffer *active_fb_16;
> spinlock_t active_fb_16_lock;
> @@ -76,7 +79,6 @@ struct udl_device {
>
> /* modeset */
> int udl_modeset_init(struct drm_device *dev);
> -void udl_modeset_restore(struct drm_device *dev);
> void udl_modeset_cleanup(struct drm_device *dev);
> struct drm_connector *udl_connector_init(struct drm_device *dev);
>
> diff --git a/drivers/gpu/drm/udl/udl_modeset.c
> b/drivers/gpu/drm/udl/udl_modeset.c
> index 5bb1522036c7..c8bd438de6e9 100644
> --- a/drivers/gpu/drm/udl/udl_modeset.c
> +++ b/drivers/gpu/drm/udl/udl_modeset.c
> @@ -9,12 +9,16 @@
>
> */
>
> +#include
> #include
> +#include
> #include
> #include
>
> #include "udl_drv.h"
>
> +#define UDL_COLOR_DEPTH_16BPP0
> +
> /*
Re: [Intel-gfx] [PATCH 02/13] drm/fb-helper: don't preserve fb_ops across deferred IO use
Den 28.11.2019 13.05, skrev Jani Nikula:
> On Thu, 28 Nov 2019, Noralf Trønnes wrote:
>> Den 27.11.2019 17.31, skrev Jani Nikula:
>>> Deferred IO now preserves the fb_ops.
>>>
>>> Cc: Noralf Trønnes
>>> Cc: dri-devel@lists.freedesktop.org
>>> Signed-off-by: Jani Nikula
>>> ---
>>> drivers/gpu/drm/drm_fb_helper.c | 18 ++
>>> 1 file changed, 2 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_fb_helper.c
>>> b/drivers/gpu/drm/drm_fb_helper.c
>>> index 0c088ea70ad0..a5a2a538d085 100644
>>> --- a/drivers/gpu/drm/drm_fb_helper.c
>>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>>> @@ -1954,7 +1954,6 @@ static int drm_fbdev_fb_release(struct fb_info *info,
>>> int user)
>>> static void drm_fbdev_cleanup(struct drm_fb_helper *fb_helper)
>>> {
>>> struct fb_info *fbi = fb_helper->fbdev;
>>> - struct fb_ops *fbops = NULL;
>>> void *shadow = NULL;
>>>
>>> if (!fb_helper->dev)
>>> @@ -1963,15 +1962,11 @@ static void drm_fbdev_cleanup(struct drm_fb_helper
>>> *fb_helper)
>>> if (fbi && fbi->fbdefio) {
>>> fb_deferred_io_cleanup(fbi);
>>> shadow = fbi->screen_buffer;
>>> - fbops = fbi->fbops;
>>> }
>>>
>>> drm_fb_helper_fini(fb_helper);
>>>
>>> - if (shadow) {
>>> - vfree(shadow);
>>> - kfree(fbops);
>>> - }
>>> + vfree(shadow);
>>>
>>> drm_client_framebuffer_delete(fb_helper->buffer);
>>> }
>>> @@ -2062,23 +2057,14 @@ static int drm_fb_helper_generic_probe(struct
>>> drm_fb_helper *fb_helper,
>>> drm_fb_helper_fill_info(fbi, fb_helper, sizes);
>>>
>>> if (drm_fbdev_use_shadow_fb(fb_helper)) {
>>> - struct fb_ops *fbops;
>>> void *shadow;
>>>
>>> - /*
>>> -* fb_deferred_io_cleanup() clears >fb_mmap so a per
>>> -* instance version is necessary.
>>> -*/
>>> - fbops = kzalloc(sizeof(*fbops), GFP_KERNEL);
>>> shadow = vzalloc(fbi->screen_size);
>>> - if (!fbops || !shadow) {
>>> - kfree(fbops);
>>> + if (!shadow) {
>>> vfree(shadow);
>>
>> This vfree can is a no-op now and can be dropped. With that:
>
> D'oh!
>
> With that I think I'd also drop the shadow local variable and assign to
> fbi->screen_buffer directly. Fine with that?
Sure, that's even better.
Noralf.
>
> Thanks.
>
> BR,
> Jani.
>
>>
>> Reviewed-by: Noralf Trønnes
>>
>>> return -ENOMEM;
>>> }
>>>
>>> - *fbops = *fbi->fbops;
>>> - fbi->fbops = fbops;
>>> fbi->screen_buffer = shadow;
>>> fbi->fbdefio = _fbdev_defio;
>>>
>>>
>> ___
>> Intel-gfx mailing list
>> intel-...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] drm/udl: Init connector before encoder and CRTC
On Tue, Nov 26, 2019 at 02:47:01PM +0100, Thomas Zimmermann wrote:
> To mimic simple-pipe, we initialize the connector before the rest of
> the display pipeline.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/udl/udl_connector.c | 7 +++
> drivers/gpu/drm/udl/udl_drv.h | 2 +-
> drivers/gpu/drm/udl/udl_modeset.c | 16 ++--
> 3 files changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/udl/udl_connector.c
> b/drivers/gpu/drm/udl/udl_connector.c
> index b4ae3e89a7b4..68e113ae44f7 100644
> --- a/drivers/gpu/drm/udl/udl_connector.c
> +++ b/drivers/gpu/drm/udl/udl_connector.c
> @@ -123,14 +123,14 @@ static const struct drm_connector_funcs
> udl_connector_funcs = {
> .set_property = udl_connector_set_property,
> };
>
> -int udl_connector_init(struct drm_device *dev, struct drm_encoder *encoder)
> +struct drm_connector *udl_connector_init(struct drm_device *dev)
> {
> struct udl_drm_connector *udl_connector;
> struct drm_connector *connector;
>
> udl_connector = kzalloc(sizeof(struct udl_drm_connector), GFP_KERNEL);
> if (!udl_connector)
> - return -ENOMEM;
> + return ERR_PTR(-ENOMEM);
>
> connector = _connector->connector;
> drm_connector_init(dev, connector, _connector_funcs,
> @@ -138,9 +138,8 @@ int udl_connector_init(struct drm_device *dev, struct
> drm_encoder *encoder)
> drm_connector_helper_add(connector, _connector_helper_funcs);
>
> drm_connector_register(connector);
While at it, might want to ditch this line, it's a no-op and only meant to
be called by drivers for hotplugged connectors. But kinda separate patch,
plus there's an entire pile of drivers which get this wrong.
> - drm_connector_attach_encoder(connector, encoder);
> connector->polled = DRM_CONNECTOR_POLL_HPD |
> DRM_CONNECTOR_POLL_CONNECT | DRM_CONNECTOR_POLL_DISCONNECT;
>
> - return 0;
> + return connector;
> }
> diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
> index 66cbe04f832a..8dc04717abac 100644
> --- a/drivers/gpu/drm/udl/udl_drv.h
> +++ b/drivers/gpu/drm/udl/udl_drv.h
> @@ -78,7 +78,7 @@ struct udl_device {
> int udl_modeset_init(struct drm_device *dev);
> void udl_modeset_restore(struct drm_device *dev);
> void udl_modeset_cleanup(struct drm_device *dev);
> -int udl_connector_init(struct drm_device *dev, struct drm_encoder *encoder);
> +struct drm_connector *udl_connector_init(struct drm_device *dev);
>
> struct drm_encoder *udl_encoder_init(struct drm_device *dev);
>
> diff --git a/drivers/gpu/drm/udl/udl_modeset.c
> b/drivers/gpu/drm/udl/udl_modeset.c
> index 91af25caed64..5bb1522036c7 100644
> --- a/drivers/gpu/drm/udl/udl_modeset.c
> +++ b/drivers/gpu/drm/udl/udl_modeset.c
> @@ -421,7 +421,10 @@ static const struct drm_mode_config_funcs udl_mode_funcs
> = {
>
> int udl_modeset_init(struct drm_device *dev)
> {
> + struct drm_connector *connector;
> struct drm_encoder *encoder;
> + int ret;
> +
> drm_mode_config_init(dev);
>
> dev->mode_config.min_width = 640;
> @@ -435,13 +438,22 @@ int udl_modeset_init(struct drm_device *dev)
>
> dev->mode_config.funcs = _mode_funcs;
>
> + connector = udl_connector_init(dev);
> + if (IS_ERR(connector)) {
> + ret = PTR_ERR(connector);
> + goto err_drm_mode_config_cleanup;
> + }
> +
> udl_crtc_init(dev);
>
> encoder = udl_encoder_init(dev);
> -
> - udl_connector_init(dev, encoder);
> + drm_connector_attach_encoder(connector, encoder);
>
> return 0;
> +
> +err_drm_mode_config_cleanup:
> + drm_mode_config_cleanup(dev);
> + return ret;
> }
>
> void udl_modeset_restore(struct drm_device *dev)
Reviewed-by: Daniel Vetter
> --
> 2.23.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Provide ddc symlink in hdmi connector sysfs directory
On Thu, 28 Nov 2019, Andrzej Pietrasiewicz wrote: > Use the ddc pointer provided by the generic connector. > > Signed-off-by: Andrzej Pietrasiewicz > Acked-by: Sam Ravnborg > Reviewed-by: Emil Velikov > --- > Rebased onto drm-misc-next as of 28 Nov 2019 The conflict is in drm-intel-next-queued where this would be applied. Please rebase on drm-tip or drm-intel-next-queued. BR, Jani. > > drivers/gpu/drm/i915/display/intel_hdmi.c | 12 > 1 file changed, 8 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c > b/drivers/gpu/drm/i915/display/intel_hdmi.c > index b54ccbb5aad5..40f32f2d8af1 100644 > --- a/drivers/gpu/drm/i915/display/intel_hdmi.c > +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c > @@ -3128,6 +3128,7 @@ void intel_hdmi_init_connector(struct > intel_digital_port *intel_dig_port, > struct intel_encoder *intel_encoder = _dig_port->base; > struct drm_device *dev = intel_encoder->base.dev; > struct drm_i915_private *dev_priv = to_i915(dev); > + struct i2c_adapter *ddc; > enum port port = intel_encoder->port; > struct cec_connector_info conn_info; > > @@ -3140,8 +3141,13 @@ void intel_hdmi_init_connector(struct > intel_digital_port *intel_dig_port, >intel_encoder->base.name)) > return; > > - drm_connector_init(dev, connector, _hdmi_connector_funcs, > -DRM_MODE_CONNECTOR_HDMIA); > + intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port); > + ddc = intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus); > + > + drm_connector_init_with_ddc(dev, connector, > + _hdmi_connector_funcs, > + DRM_MODE_CONNECTOR_HDMIA, > + ddc); > drm_connector_helper_add(connector, _hdmi_connector_helper_funcs); > > connector->interlace_allowed = 1; > @@ -3151,8 +3157,6 @@ void intel_hdmi_init_connector(struct > intel_digital_port *intel_dig_port, > if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) > connector->ycbcr_420_allowed = true; > > - intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port); > - > if (WARN_ON(port == PORT_A)) > return; > intel_encoder->hpd_pin = intel_hpd_pin_default(dev_priv, port); -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/dp_mst: Fix W=1 warnings
On Thu, Nov 28, 2019 at 03:34:21PM +0200, Jani Nikula wrote:
> On Thu, 28 Nov 2019, Benjamin GAIGNARD wrote:
> > On 11/28/19 12:21 PM, Jani Nikula wrote:
> >> On Thu, 28 Nov 2019, Benjamin Gaignard wrote:
> >>> Fix the warnings that show up with W=1.
> >>> They are all about unused but set variables.
> >>> If functions returns are not used anymore make them void.
> >>>
> >>> Signed-off-by: Benjamin Gaignard
> >>> CC: Jani Nikula
> >>> ---
> >>> changes in version 2:
> >>> - fix indentations
> >>> - when possible change functions prototype to void
> >>>
> >>> Note: this patch may conflict with c485e2c97dae ("drm/dp_mst: Refactor pdt
> >>> setup/teardown, add more locking") when it will hit drm-misc-next
> >> Well, why create an unnecessary conflict when the referenced commit also
> >> fixes the same warnings as a side-effect?
> >
> > Because this commit is not merged (yet ?) in drm-misc-next which where I
> > start.
>
> I mean just leave the hunk out and the problem will fix itself once the
> stuff gets backmerged to drm-misc-next.
Or ask -misc maintainers to do the backmerge to get stuff resolved before
you land your patch.
-Daniel
>
> BR,
> Jani.
>
>
> >
> > Benjamin
> >
> >> BR,
> >> Jani.
> >>
> >>
> >>> drivers/gpu/drm/drm_dp_mst_topology.c | 83
> >>> +--
> >>> 1 file changed, 31 insertions(+), 52 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> >>> b/drivers/gpu/drm/drm_dp_mst_topology.c
> >>> index b854a422a523..ff2d81db0778 100644
> >>> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> >>> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> >>> @@ -672,7 +672,6 @@ static bool drm_dp_sideband_msg_build(struct
> >>> drm_dp_sideband_msg_rx *msg,
> >>> u8 *replybuf, u8 replybuflen,
> >>> bool hdr)
> >>> {
> >>> int ret;
> >>> - u8 crc4;
> >>>
> >>> if (hdr) {
> >>> u8 hdrlen;
> >>> @@ -714,8 +713,6 @@ static bool drm_dp_sideband_msg_build(struct
> >>> drm_dp_sideband_msg_rx *msg,
> >>> }
> >>>
> >>> if (msg->curchunk_idx >= msg->curchunk_len) {
> >>> - /* do CRC */
> >>> - crc4 = drm_dp_msg_data_crc4(msg->chunk, msg->curchunk_len - 1);
> >>> /* copy chunk into bigger msg */
> >>> memcpy(>msg[msg->curlen], msg->chunk,
> >>> msg->curchunk_len - 1);
> >>> msg->curlen += msg->curchunk_len - 1;
> >>> @@ -1012,7 +1009,7 @@ static bool drm_dp_sideband_parse_req(struct
> >>> drm_dp_sideband_msg_rx *raw,
> >>> }
> >>> }
> >>>
> >>> -static int build_dpcd_write(struct drm_dp_sideband_msg_tx *msg, u8
> >>> port_num, u32 offset, u8 num_bytes, u8 *bytes)
> >>> +static void build_dpcd_write(struct drm_dp_sideband_msg_tx *msg, u8
> >>> port_num, u32 offset, u8 num_bytes, u8 *bytes)
> >>> {
> >>> struct drm_dp_sideband_msg_req_body req;
> >>>
> >>> @@ -1022,17 +1019,14 @@ static int build_dpcd_write(struct
> >>> drm_dp_sideband_msg_tx *msg, u8 port_num, u32
> >>> req.u.dpcd_write.num_bytes = num_bytes;
> >>> req.u.dpcd_write.bytes = bytes;
> >>> drm_dp_encode_sideband_req(, msg);
> >>> -
> >>> - return 0;
> >>> }
> >>>
> >>> -static int build_link_address(struct drm_dp_sideband_msg_tx *msg)
> >>> +static void build_link_address(struct drm_dp_sideband_msg_tx *msg)
> >>> {
> >>> struct drm_dp_sideband_msg_req_body req;
> >>>
> >>> req.req_type = DP_LINK_ADDRESS;
> >>> drm_dp_encode_sideband_req(, msg);
> >>> - return 0;
> >>> }
> >>>
> >>> static int build_enum_path_resources(struct drm_dp_sideband_msg_tx
> >>> *msg, int port_num)
> >>> @@ -1046,7 +1040,7 @@ static int build_enum_path_resources(struct
> >>> drm_dp_sideband_msg_tx *msg, int por
> >>> return 0;
> >>> }
> >>>
> >>> -static int build_allocate_payload(struct drm_dp_sideband_msg_tx *msg,
> >>> int port_num,
> >>> +static void build_allocate_payload(struct drm_dp_sideband_msg_tx *msg,
> >>> int port_num,
> >>> u8 vcpi, uint16_t pbn,
> >>> u8 number_sdp_streams,
> >>> u8 *sdp_stream_sink)
> >>> @@ -1062,10 +1056,9 @@ static int build_allocate_payload(struct
> >>> drm_dp_sideband_msg_tx *msg, int port_n
> >>> number_sdp_streams);
> >>> drm_dp_encode_sideband_req(, msg);
> >>> msg->path_msg = true;
> >>> - return 0;
> >>> }
> >>>
> >>> -static int build_power_updown_phy(struct drm_dp_sideband_msg_tx *msg,
> >>> +static void build_power_updown_phy(struct drm_dp_sideband_msg_tx *msg,
> >>> int port_num, bool power_up)
> >>> {
> >>> struct drm_dp_sideband_msg_req_body req;
> >>> @@ -1078,7 +1071,6 @@ static int build_power_updown_phy(struct
> >>> drm_dp_sideband_msg_tx *msg,
> >>>
Re: [PATCH v2] drm/dsc: Return unsigned long on compute offset
On Fri, 22 Nov 2019, wrote:
> From: Mikita Lipski
>
> We shouldn't compare int with unsigned long to find the max value
> and since we are not expecting negative value returned from
> compute_offset we should make this function return unsigned long
> so we can compare the values when computing rc parameters.
>
> v2: Modified function parameters to unsigned type for type
> consistency
I don't think that really addresses the review.
But all the same, current drm-tip does not have a compute_offset()
function, and the only reference to it in my email are your patches, so
this is completely unactionable anyway.
In any case I think the root cause for your issues is the unfounded use
of unsigned longs in drm_dsc_compute_rc_parameters(). Fix that and many
of your problems go away.
BR,
Jani.
>
> Cc: Ville Syrjälä
> Cc: Nikola Cornij
> Cc: Harry Wentland
> Signed-off-by: Mikita Lipski
> ---
> drivers/gpu/drm/drm_dsc.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
> index 74f3527f567d..ccce0297da64 100644
> --- a/drivers/gpu/drm/drm_dsc.c
> +++ b/drivers/gpu/drm/drm_dsc.c
> @@ -245,11 +245,11 @@ void drm_dsc_pps_payload_pack(struct
> drm_dsc_picture_parameter_set *pps_payload,
> }
> EXPORT_SYMBOL(drm_dsc_pps_payload_pack);
>
> -static int compute_offset(struct drm_dsc_config *vdsc_cfg, int
> pixels_per_group,
> - int groups_per_line, int grpcnt)
> +static unsigned long compute_offset(struct drm_dsc_config *vdsc_cfg,
> unsigned int pixels_per_group,
> + unsigned long groups_per_line, unsigned long
> grpcnt)
> {
> - int offset = 0;
> - int grpcnt_id = DIV_ROUND_UP(vdsc_cfg->initial_xmit_delay,
> pixels_per_group);
> + unsigned long offset = 0;
> + unsigned long grpcnt_id = DIV_ROUND_UP(vdsc_cfg->initial_xmit_delay,
> pixels_per_group);
>
> if (grpcnt <= grpcnt_id)
> offset = DIV_ROUND_UP(grpcnt * pixels_per_group *
> vdsc_cfg->bits_per_pixel, 16);
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: Provide ddc symlink in hdmi connector sysfs directory
Use the ddc pointer provided by the generic connector. Signed-off-by: Andrzej Pietrasiewicz Acked-by: Sam Ravnborg Reviewed-by: Emil Velikov --- Rebased onto drm-misc-next as of 28 Nov 2019 drivers/gpu/drm/i915/display/intel_hdmi.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c index b54ccbb5aad5..40f32f2d8af1 100644 --- a/drivers/gpu/drm/i915/display/intel_hdmi.c +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c @@ -3128,6 +3128,7 @@ void intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port, struct intel_encoder *intel_encoder = _dig_port->base; struct drm_device *dev = intel_encoder->base.dev; struct drm_i915_private *dev_priv = to_i915(dev); + struct i2c_adapter *ddc; enum port port = intel_encoder->port; struct cec_connector_info conn_info; @@ -3140,8 +3141,13 @@ void intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port, intel_encoder->base.name)) return; - drm_connector_init(dev, connector, _hdmi_connector_funcs, - DRM_MODE_CONNECTOR_HDMIA); + intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port); + ddc = intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus); + + drm_connector_init_with_ddc(dev, connector, + _hdmi_connector_funcs, + DRM_MODE_CONNECTOR_HDMIA, + ddc); drm_connector_helper_add(connector, _hdmi_connector_helper_funcs); connector->interlace_allowed = 1; @@ -3151,8 +3157,6 @@ void intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port, if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) connector->ycbcr_420_allowed = true; - intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port); - if (WARN_ON(port == PORT_A)) return; intel_encoder->hpd_pin = intel_hpd_pin_default(dev_priv, port); -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/dp_mst: Fix W=1 warnings
On Thu, 28 Nov 2019, Benjamin GAIGNARD wrote:
> On 11/28/19 12:21 PM, Jani Nikula wrote:
>> On Thu, 28 Nov 2019, Benjamin Gaignard wrote:
>>> Fix the warnings that show up with W=1.
>>> They are all about unused but set variables.
>>> If functions returns are not used anymore make them void.
>>>
>>> Signed-off-by: Benjamin Gaignard
>>> CC: Jani Nikula
>>> ---
>>> changes in version 2:
>>> - fix indentations
>>> - when possible change functions prototype to void
>>>
>>> Note: this patch may conflict with c485e2c97dae ("drm/dp_mst: Refactor pdt
>>> setup/teardown, add more locking") when it will hit drm-misc-next
>> Well, why create an unnecessary conflict when the referenced commit also
>> fixes the same warnings as a side-effect?
>
> Because this commit is not merged (yet ?) in drm-misc-next which where I
> start.
I mean just leave the hunk out and the problem will fix itself once the
stuff gets backmerged to drm-misc-next.
BR,
Jani.
>
> Benjamin
>
>> BR,
>> Jani.
>>
>>
>>> drivers/gpu/drm/drm_dp_mst_topology.c | 83
>>> +--
>>> 1 file changed, 31 insertions(+), 52 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
>>> b/drivers/gpu/drm/drm_dp_mst_topology.c
>>> index b854a422a523..ff2d81db0778 100644
>>> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
>>> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
>>> @@ -672,7 +672,6 @@ static bool drm_dp_sideband_msg_build(struct
>>> drm_dp_sideband_msg_rx *msg,
>>> u8 *replybuf, u8 replybuflen, bool hdr)
>>> {
>>> int ret;
>>> - u8 crc4;
>>>
>>> if (hdr) {
>>> u8 hdrlen;
>>> @@ -714,8 +713,6 @@ static bool drm_dp_sideband_msg_build(struct
>>> drm_dp_sideband_msg_rx *msg,
>>> }
>>>
>>> if (msg->curchunk_idx >= msg->curchunk_len) {
>>> - /* do CRC */
>>> - crc4 = drm_dp_msg_data_crc4(msg->chunk, msg->curchunk_len - 1);
>>> /* copy chunk into bigger msg */
>>> memcpy(>msg[msg->curlen], msg->chunk, msg->curchunk_len -
>>> 1);
>>> msg->curlen += msg->curchunk_len - 1;
>>> @@ -1012,7 +1009,7 @@ static bool drm_dp_sideband_parse_req(struct
>>> drm_dp_sideband_msg_rx *raw,
>>> }
>>> }
>>>
>>> -static int build_dpcd_write(struct drm_dp_sideband_msg_tx *msg, u8
>>> port_num, u32 offset, u8 num_bytes, u8 *bytes)
>>> +static void build_dpcd_write(struct drm_dp_sideband_msg_tx *msg, u8
>>> port_num, u32 offset, u8 num_bytes, u8 *bytes)
>>> {
>>> struct drm_dp_sideband_msg_req_body req;
>>>
>>> @@ -1022,17 +1019,14 @@ static int build_dpcd_write(struct
>>> drm_dp_sideband_msg_tx *msg, u8 port_num, u32
>>> req.u.dpcd_write.num_bytes = num_bytes;
>>> req.u.dpcd_write.bytes = bytes;
>>> drm_dp_encode_sideband_req(, msg);
>>> -
>>> - return 0;
>>> }
>>>
>>> -static int build_link_address(struct drm_dp_sideband_msg_tx *msg)
>>> +static void build_link_address(struct drm_dp_sideband_msg_tx *msg)
>>> {
>>> struct drm_dp_sideband_msg_req_body req;
>>>
>>> req.req_type = DP_LINK_ADDRESS;
>>> drm_dp_encode_sideband_req(, msg);
>>> - return 0;
>>> }
>>>
>>> static int build_enum_path_resources(struct drm_dp_sideband_msg_tx *msg,
>>> int port_num)
>>> @@ -1046,7 +1040,7 @@ static int build_enum_path_resources(struct
>>> drm_dp_sideband_msg_tx *msg, int por
>>> return 0;
>>> }
>>>
>>> -static int build_allocate_payload(struct drm_dp_sideband_msg_tx *msg, int
>>> port_num,
>>> +static void build_allocate_payload(struct drm_dp_sideband_msg_tx *msg, int
>>> port_num,
>>> u8 vcpi, uint16_t pbn,
>>> u8 number_sdp_streams,
>>> u8 *sdp_stream_sink)
>>> @@ -1062,10 +1056,9 @@ static int build_allocate_payload(struct
>>> drm_dp_sideband_msg_tx *msg, int port_n
>>>number_sdp_streams);
>>> drm_dp_encode_sideband_req(, msg);
>>> msg->path_msg = true;
>>> - return 0;
>>> }
>>>
>>> -static int build_power_updown_phy(struct drm_dp_sideband_msg_tx *msg,
>>> +static void build_power_updown_phy(struct drm_dp_sideband_msg_tx *msg,
>>> int port_num, bool power_up)
>>> {
>>> struct drm_dp_sideband_msg_req_body req;
>>> @@ -1078,7 +1071,6 @@ static int build_power_updown_phy(struct
>>> drm_dp_sideband_msg_tx *msg,
>>> req.u.port_num.port_number = port_num;
>>> drm_dp_encode_sideband_req(, msg);
>>> msg->path_msg = true;
>>> - return 0;
>>> }
>>>
>>> static int drm_dp_mst_assign_payload_id(struct drm_dp_mst_topology_mgr
>>> *mgr,
>>> @@ -1744,14 +1736,13 @@ static u8 drm_dp_calculate_rad(struct
>>> drm_dp_mst_port *port,
>>>*/
>>> static bool drm_dp_port_setup_pdt(struct drm_dp_mst_port *port)
>>> {
>>> - int ret;
>>> u8 rad[6], lct;
>>> bool send_link = false;
>>> switch (port->pdt) {
>>> case DP_PEER_DEVICE_DP_LEGACY_CONV:
>>> case
Re: [PATCH] drm/panel: Add Boe Himax8279d MIPI-DSI LCD panel
Hi Jerry,
On Tue, 26 Nov 2019 at 08:14, Jerry Han wrote:
>
> Support Boe Himax8279d 8.0" 1200x1920 TFT LCD panel, it is a MIPI DSI
> panel.
>
> V9:
> - Adjust init code, make the format more concise
> - kill off default_off_cmds (Emil)
> - use mipi_dsi_dcs_set_display_{on,off} in their enable/disable
> callbacks. (Emil)
> - Adjusting the delay function (Emil)
>
> V8:
> - modify PARENTHESIS_ALIGNMENT format (Sam)
> - use gpios are required API replace optional gpio API (Emil)
>
> V7:
> - Modify communication address
>
> V6:
> - Add the information of the reviewer
> - Remove unnecessary delays, The udelay_range code gracefully returns
> without hitting the scheduler on a delay of 0. (Derek)
> - Merge the same data structures, like display_mode and off_cmds (Derek)
> - Optimize the processing of results returned by
> devm_gpiod_get_optional (Derek)
>
> V5:
> - Add the information of the reviewer (Sam)
> - Delete unnecessary header files #include (Sam)
> - The config DRM_PANEL_BOE_HIMAX8279D appears twice. Drop one of them (Sam)
> - ADD static, set_gpios function is not used outside this module (Sam)
>
> V4:
> - Frefix all function maes with boe_ (Sam)
> - Fsed "enable_gpio" replace "reset_gpio", Make it look clearer (Sam)
> - Sort include lines alphabetically (Sam)
> - Fixed entries in the makefile must be sorted alphabetically (Sam)
> - Add send_mipi_cmds function to avoid duplicating the code (Sam)
> - Add the necessary delay(reset_delay_t5) between reset and sending
> the initialization command (Rock wang)
>
> V3:
> - Remove unnecessary delays in sending initialization commands (Jitao Shi)
>
> V2:
> - Use SPDX identifier (Sam)
> - Use necessary header files replace drmP.h (Sam)
> - Delete unnecessary header files #include (Sam)
> - Specifies a GPIOs array to control the reset timing,
> instead of reading "dsi-reset-sequence" data from DTS (Sam)
> - Delete backlight_disable() function when already disabled (Sam)
> - Use devm_of_find_backlight() replace of_find_backlight_by_node() (Sam)
> - Move the necessary data in the DTS to the current file,
> like porch, display_mode and Init code etc. (Sam)
> - Add compatible device "boe,himax8279d10p" (Sam)
>
> V1:
> - Support Boe Himax8279d 8.0" 1200x1920 TFT LCD panel, it is a MIPI DSI
> panel.
>
> Signed-off-by: Jerry Han
> Reviewed-by: Sam Ravnborg
> Reviewed-by: Derek Basehore
> Reviewed-by: Emil Velikov
Please don't add tags unless they are explicitly provided by the individual.
Namely you're just sending this revision, so I'm yet to review it.
> Cc: Jitao Shi
> Cc: Rock wang
> ---
> MAINTAINERS | 6 +
> drivers/gpu/drm/panel/Kconfig| 11 +
> drivers/gpu/drm/panel/Makefile | 2 +
> drivers/gpu/drm/panel/panel-boe-himax8279d.c | 990 +++
> 4 files changed, 1009 insertions(+)
> create mode 100644 drivers/gpu/drm/panel/panel-boe-himax8279d.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c2b89453805f..295cb214834c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5135,6 +5135,12 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
> S: Maintained
> F: drivers/gpu/drm/bochs/
>
> +DRM DRIVER FOR BOE HIMAX8279D PANELS
> +M: Jerry Han
> +S: Maintained
> +F: drivers/gpu/drm/panel/panel-boe-himax8279d.c
> +F: Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt
> +
> DRM DRIVER FOR FARADAY TVE200 TV ENCODER
> M: Linus Walleij
> T: git git://anongit.freedesktop.org/drm/drm-misc
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index f152bc4eeb53..683ff77a3733 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -18,6 +18,17 @@ config DRM_PANEL_ARM_VERSATILE
> reference designs. The panel is detected using special registers
> in the Versatile family syscon registers.
>
> +config DRM_PANEL_BOE_HIMAX8279D
> + tristate "Boe Himax8279d panel"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + depends on BACKLIGHT_CLASS_DEVICE
> + help
> + Say Y here if you want to enable support for Boe Himax8279d
> + TFT-LCD modules. The panel has a 1200x1920 resolution and uses
> + 24 bit RGB per pixel. It provides a MIPI DSI interface to
> + the host and has a built-in LED backlight.
> +
> config DRM_PANEL_LVDS
> tristate "Generic LVDS panel driver"
> depends on OF
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index b6cd39fe0f20..4beae2ab427f 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -1,5 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0
> obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
> +obj-$(CONFIG_DRM_PANEL_BOE_HIMAX8279D) += panel-boe-himax8279d.o
> obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
> obj-$(CONFIG_DRM_PANEL_SIMPLE) +=
Re: [PATCH v2 1/3] drm/mgag200: Extract device type from flags
On 2019/11/27, Thomas Zimmermann wrote:
> Hi Emil
>
> Am 27.11.19 um 17:29 schrieb Emil Velikov:
> > Hi Thomas,
> >
> > On Tue, 26 Nov 2019 at 10:15, Thomas Zimmermann wrote:
> >>
> >> Adds a conversion function that extracts the device type from the
> >> PCI id-table flags. Allows for storing additional information in the
> >> other flag bits.
> >>
> >> Signed-off-by: Thomas Zimmermann
> >> Fixes: 81da87f63a1e ("drm: Replace drm_gem_vram_push_to_system() with
> >> kunmap + unpin")
> >
> > Are you sure the fixes tag is correct? Neither the commit summary nor
> > the patch itself seems related to the changes below.
>
> Yes, it's correct. It's part of a patch series [1][2][3] that fixes the bug.
>
> Best regards
> Thomas
>
> [1]
> https://cgit.freedesktop.org/drm/drm-tip/commit/?id=3a8a5aba142a44eaeba0cb0ec1b4a8f177b5e59a
> [2]
> https://cgit.freedesktop.org/drm/drm-tip/commit/?id=d6d437d97d54c85a1a93967b2745e31dff03365a
> [3]
> https://cgit.freedesktop.org/drm/drm-tip/commit/?id=1591fadf857cdbaf2baa55e421af99a61354713c
>
I see, different alignment is required for one mga200 GPU.
Personally, I would have mentioned that in the commit message.
Regardless, hats off for the prompt fixup.
Thanks
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/rect: update kerneldoc for drm_rect_clip_scaled()
On Tue, Nov 26, 2019 at 05:10:14PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 26, 2019 at 03:52:13PM +0100, Daniel Vetter wrote:
> > This was forgotten in f96bdf564f3e ("drm/rect: Handle rounding errors
> > in drm_rect_clip_scaled, v3.")
> >
> > Spotted while reviewing patches from Ville touching this area.
> >
> > Fixes: f96bdf564f3e ("drm/rect: Handle rounding errors in
> > drm_rect_clip_scaled, v3.")
> > Cc: Maarten Lankhorst
> > Cc: Benjamin Gaignard
> > Cc: Ville Syrjala
> > Signed-off-by: Daniel Vetter
>
> Reviewed-by: Ville Syrjälä
Thanks for taking a look, patch pushed.
-Daniel
>
> > ---
> > drivers/gpu/drm/drm_rect.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
> > index b8363aaa9032..e6e640f2d5e3 100644
> > --- a/drivers/gpu/drm/drm_rect.c
> > +++ b/drivers/gpu/drm/drm_rect.c
> > @@ -73,11 +73,13 @@ static u32 clip_scaled(u32 src, u32 dst, u32 clip)
> > * @clip: clip rectangle
> > *
> > * Clip rectangle @dst by rectangle @clip. Clip rectangle @src by the
> > - * same amounts multiplied by @hscale and @vscale.
> > + * the corresponding amounts, retaining the vertical and horizontal scaling
> > + * factors from @src to @dst.
> > *
> > * RETURNS:
> > + *
> > * %true if rectangle @dst is still visible after being clipped,
> > - * %false otherwise
> > + * %false otherwise.
> > */
> > bool drm_rect_clip_scaled(struct drm_rect *src, struct drm_rect *dst,
> > const struct drm_rect *clip)
> > --
> > 2.24.0
>
> --
> Ville Syrjälä
> Intel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [RFC 03/13] drm/i915/svm: Runtime (RT) allocator support
Quoting Niranjan Vishwanathapura (2019-11-27 21:23:56)
> >We should try to have the uAPI as final as early as possible. The
> >change process is harder the later it is done, even for RFC :)
> >
> >On the same note, I'm inclined to have I915_SVM_MIGRATE called
> >I915_GEM_VM_PREFAULT from the start, as I already have got some
> >confused questions from folks who mix it with memory pressure
> >initiated migration. And it's inherently racy as anybody could
> >race with it, so PREFAULT would give an impression of that.
> >
> >And I think I915_GEM_VM_PREFAULT would be a generally applicable
> >function, just like I915_GEM_VM_BIND. So we should use a struct
> >member names that are close to I915_GEM_VM_BIND.
> >
> >Better ideas for name to emphasis the nature of what is being
> >done? I915_GEM_VM_FAULT/I915_GEM_VM_{M,}ADVICE...
> >
>
> Though current patchset only supports migrating pages from
> host to device memory, I intend to support migrating from device
> to host memory as well with same ioctl. User would want that.
> Not sure what would be a good name then, _MIGRATE/_PREFETCH/_MOVE?
In the HMM concept the CPU access would trigger fault, and trigger
the transition, wouldn't it? But you're correct that it is kind of
tied to the HMM concept, and may be confusing for BOs.
_PREFETCH is a good suggestion for the term, which lead to
discussion to avoid explosion of IOCTLs, Chris suggested
consolidation, maybe we should have I915_GEM_VM_{M,}ADVISE?
If we're looking at connections to fadvise(2), we're basically
talking about equivalent of FADV_WILLNEED. That concept would
be quite familiar to users. GEM_VM_{M,}ADVISE with WILLNEED
and explicitly passing the memory region? Because we can't decipher
that from the running thread like CPU.
Thoughts?
> Also, migrating gem objects is currently handled by separate ioctl
> which is part of LMEM patch series. I am open to merging these
> ioctls together (similart to VM_BIND) into a single MIGRATE ioctl.
The IOCTL in the LMEM series is about setting the allowed backing
store types of a BO, not about the residency. There was some
discussion around doing explicit migrations by changing that list.
Current thinking is that we only need to allow setting it once
at creation. That also means it might be convertible to creation
time only property.
That'd eliminate the need for BO freeze IOCTL that was discussed
with Mesa folks.
Regard, Joonas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 02/13] drm/fb-helper: don't preserve fb_ops across deferred IO use
On Thu, 28 Nov 2019, Noralf Trønnes wrote:
> Den 27.11.2019 17.31, skrev Jani Nikula:
>> Deferred IO now preserves the fb_ops.
>>
>> Cc: Noralf Trønnes
>> Cc: dri-devel@lists.freedesktop.org
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/drm_fb_helper.c | 18 ++
>> 1 file changed, 2 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_fb_helper.c
>> b/drivers/gpu/drm/drm_fb_helper.c
>> index 0c088ea70ad0..a5a2a538d085 100644
>> --- a/drivers/gpu/drm/drm_fb_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> @@ -1954,7 +1954,6 @@ static int drm_fbdev_fb_release(struct fb_info *info,
>> int user)
>> static void drm_fbdev_cleanup(struct drm_fb_helper *fb_helper)
>> {
>> struct fb_info *fbi = fb_helper->fbdev;
>> -struct fb_ops *fbops = NULL;
>> void *shadow = NULL;
>>
>> if (!fb_helper->dev)
>> @@ -1963,15 +1962,11 @@ static void drm_fbdev_cleanup(struct drm_fb_helper
>> *fb_helper)
>> if (fbi && fbi->fbdefio) {
>> fb_deferred_io_cleanup(fbi);
>> shadow = fbi->screen_buffer;
>> -fbops = fbi->fbops;
>> }
>>
>> drm_fb_helper_fini(fb_helper);
>>
>> -if (shadow) {
>> -vfree(shadow);
>> -kfree(fbops);
>> -}
>> +vfree(shadow);
>>
>> drm_client_framebuffer_delete(fb_helper->buffer);
>> }
>> @@ -2062,23 +2057,14 @@ static int drm_fb_helper_generic_probe(struct
>> drm_fb_helper *fb_helper,
>> drm_fb_helper_fill_info(fbi, fb_helper, sizes);
>>
>> if (drm_fbdev_use_shadow_fb(fb_helper)) {
>> -struct fb_ops *fbops;
>> void *shadow;
>>
>> -/*
>> - * fb_deferred_io_cleanup() clears >fb_mmap so a per
>> - * instance version is necessary.
>> - */
>> -fbops = kzalloc(sizeof(*fbops), GFP_KERNEL);
>> shadow = vzalloc(fbi->screen_size);
>> -if (!fbops || !shadow) {
>> -kfree(fbops);
>> +if (!shadow) {
>> vfree(shadow);
>
> This vfree can is a no-op now and can be dropped. With that:
D'oh!
With that I think I'd also drop the shadow local variable and assign to
fbi->screen_buffer directly. Fine with that?
Thanks.
BR,
Jani.
>
> Reviewed-by: Noralf Trønnes
>
>> return -ENOMEM;
>> }
>>
>> -*fbops = *fbi->fbops;
>> -fbi->fbops = fbops;
>> fbi->screen_buffer = shadow;
>> fbi->fbdefio = _fbdev_defio;
>>
>>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] udmabuf: allow userspace to set map attributes
Hi,
> diff --git a/include/uapi/linux/udmabuf.h b/include/uapi/linux/udmabuf.h
> index 46b6532ed855..f90831f2bb0d 100644
> --- a/include/uapi/linux/udmabuf.h
> +++ b/include/uapi/linux/udmabuf.h
> @@ -6,6 +6,8 @@
> #include
>
> #define UDMABUF_FLAGS_CLOEXEC0x01
> +#define UDMABUF_FLAGS_WC 0x02
> +#define UDMABUF_FLAGS_NONCACHED 0x04
>
> struct udmabuf_create {
> __u32 memfd;
This is a uapi change and should go to a separate patch,
clearly flagging that in $subject.
(new policy by airlied for the drm tree).
Otherwise the series looks good to me.
cheers,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/2] drm: call drm_gem_object_funcs.mmap with fake offset
On Wed, Nov 27, 2019 at 10:25:22AM +0100, Gerd Hoffmann wrote:
> The fake offset is going to stay, so change the calling convention for
> drm_gem_object_funcs.mmap to include the fake offset. Update all users
> accordingly.
>
> Note that this reverts 83b8a6f242ea ("drm/gem: Fix mmap fake offset
> handling for drm_gem_object_funcs.mmap") and on top then adds the fake
> offset to drm_gem_prime_mmap to make sure all paths leading to
> obj->funcs->mmap are consistent.
>
> v3: move fake-offset tweak in drm_gem_prime_mmap() so we have this code
> only once in the function (Rob Herring).
Now this series fails in Intel CI. Can't see why though. The
difference between v2 and v3 is just the place where vma->vm_pgoff gets
updated, and no code between the v2 and v3 location touches vma ...
confused,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/13] drm/fb-helper: don't preserve fb_ops across deferred IO use
Den 27.11.2019 17.31, skrev Jani Nikula:
> Deferred IO now preserves the fb_ops.
>
> Cc: Noralf Trønnes
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_fb_helper.c | 18 ++
> 1 file changed, 2 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 0c088ea70ad0..a5a2a538d085 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1954,7 +1954,6 @@ static int drm_fbdev_fb_release(struct fb_info *info,
> int user)
> static void drm_fbdev_cleanup(struct drm_fb_helper *fb_helper)
> {
> struct fb_info *fbi = fb_helper->fbdev;
> - struct fb_ops *fbops = NULL;
> void *shadow = NULL;
>
> if (!fb_helper->dev)
> @@ -1963,15 +1962,11 @@ static void drm_fbdev_cleanup(struct drm_fb_helper
> *fb_helper)
> if (fbi && fbi->fbdefio) {
> fb_deferred_io_cleanup(fbi);
> shadow = fbi->screen_buffer;
> - fbops = fbi->fbops;
> }
>
> drm_fb_helper_fini(fb_helper);
>
> - if (shadow) {
> - vfree(shadow);
> - kfree(fbops);
> - }
> + vfree(shadow);
>
> drm_client_framebuffer_delete(fb_helper->buffer);
> }
> @@ -2062,23 +2057,14 @@ static int drm_fb_helper_generic_probe(struct
> drm_fb_helper *fb_helper,
> drm_fb_helper_fill_info(fbi, fb_helper, sizes);
>
> if (drm_fbdev_use_shadow_fb(fb_helper)) {
> - struct fb_ops *fbops;
> void *shadow;
>
> - /*
> - * fb_deferred_io_cleanup() clears >fb_mmap so a per
> - * instance version is necessary.
> - */
> - fbops = kzalloc(sizeof(*fbops), GFP_KERNEL);
> shadow = vzalloc(fbi->screen_size);
> - if (!fbops || !shadow) {
> - kfree(fbops);
> + if (!shadow) {
> vfree(shadow);
This vfree can is a no-op now and can be dropped. With that:
Reviewed-by: Noralf Trønnes
> return -ENOMEM;
> }
>
> - *fbops = *fbi->fbops;
> - fbi->fbops = fbops;
> fbi->screen_buffer = shadow;
> fbi->fbdefio = _fbdev_defio;
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/dp_mst: Fix W=1 warnings
On Thu, 28 Nov 2019, Benjamin Gaignard wrote:
> Fix the warnings that show up with W=1.
> They are all about unused but set variables.
> If functions returns are not used anymore make them void.
>
> Signed-off-by: Benjamin Gaignard
> CC: Jani Nikula
> ---
> changes in version 2:
> - fix indentations
> - when possible change functions prototype to void
>
> Note: this patch may conflict with c485e2c97dae ("drm/dp_mst: Refactor pdt
> setup/teardown, add more locking") when it will hit drm-misc-next
Well, why create an unnecessary conflict when the referenced commit also
fixes the same warnings as a side-effect?
BR,
Jani.
>
> drivers/gpu/drm/drm_dp_mst_topology.c | 83
> +--
> 1 file changed, 31 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index b854a422a523..ff2d81db0778 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -672,7 +672,6 @@ static bool drm_dp_sideband_msg_build(struct
> drm_dp_sideband_msg_rx *msg,
> u8 *replybuf, u8 replybuflen, bool hdr)
> {
> int ret;
> - u8 crc4;
>
> if (hdr) {
> u8 hdrlen;
> @@ -714,8 +713,6 @@ static bool drm_dp_sideband_msg_build(struct
> drm_dp_sideband_msg_rx *msg,
> }
>
> if (msg->curchunk_idx >= msg->curchunk_len) {
> - /* do CRC */
> - crc4 = drm_dp_msg_data_crc4(msg->chunk, msg->curchunk_len - 1);
> /* copy chunk into bigger msg */
> memcpy(>msg[msg->curlen], msg->chunk, msg->curchunk_len -
> 1);
> msg->curlen += msg->curchunk_len - 1;
> @@ -1012,7 +1009,7 @@ static bool drm_dp_sideband_parse_req(struct
> drm_dp_sideband_msg_rx *raw,
> }
> }
>
> -static int build_dpcd_write(struct drm_dp_sideband_msg_tx *msg, u8 port_num,
> u32 offset, u8 num_bytes, u8 *bytes)
> +static void build_dpcd_write(struct drm_dp_sideband_msg_tx *msg, u8
> port_num, u32 offset, u8 num_bytes, u8 *bytes)
> {
> struct drm_dp_sideband_msg_req_body req;
>
> @@ -1022,17 +1019,14 @@ static int build_dpcd_write(struct
> drm_dp_sideband_msg_tx *msg, u8 port_num, u32
> req.u.dpcd_write.num_bytes = num_bytes;
> req.u.dpcd_write.bytes = bytes;
> drm_dp_encode_sideband_req(, msg);
> -
> - return 0;
> }
>
> -static int build_link_address(struct drm_dp_sideband_msg_tx *msg)
> +static void build_link_address(struct drm_dp_sideband_msg_tx *msg)
> {
> struct drm_dp_sideband_msg_req_body req;
>
> req.req_type = DP_LINK_ADDRESS;
> drm_dp_encode_sideband_req(, msg);
> - return 0;
> }
>
> static int build_enum_path_resources(struct drm_dp_sideband_msg_tx *msg, int
> port_num)
> @@ -1046,7 +1040,7 @@ static int build_enum_path_resources(struct
> drm_dp_sideband_msg_tx *msg, int por
> return 0;
> }
>
> -static int build_allocate_payload(struct drm_dp_sideband_msg_tx *msg, int
> port_num,
> +static void build_allocate_payload(struct drm_dp_sideband_msg_tx *msg, int
> port_num,
> u8 vcpi, uint16_t pbn,
> u8 number_sdp_streams,
> u8 *sdp_stream_sink)
> @@ -1062,10 +1056,9 @@ static int build_allocate_payload(struct
> drm_dp_sideband_msg_tx *msg, int port_n
> number_sdp_streams);
> drm_dp_encode_sideband_req(, msg);
> msg->path_msg = true;
> - return 0;
> }
>
> -static int build_power_updown_phy(struct drm_dp_sideband_msg_tx *msg,
> +static void build_power_updown_phy(struct drm_dp_sideband_msg_tx *msg,
> int port_num, bool power_up)
> {
> struct drm_dp_sideband_msg_req_body req;
> @@ -1078,7 +1071,6 @@ static int build_power_updown_phy(struct
> drm_dp_sideband_msg_tx *msg,
> req.u.port_num.port_number = port_num;
> drm_dp_encode_sideband_req(, msg);
> msg->path_msg = true;
> - return 0;
> }
>
> static int drm_dp_mst_assign_payload_id(struct drm_dp_mst_topology_mgr *mgr,
> @@ -1744,14 +1736,13 @@ static u8 drm_dp_calculate_rad(struct drm_dp_mst_port
> *port,
> */
> static bool drm_dp_port_setup_pdt(struct drm_dp_mst_port *port)
> {
> - int ret;
> u8 rad[6], lct;
> bool send_link = false;
> switch (port->pdt) {
> case DP_PEER_DEVICE_DP_LEGACY_CONV:
> case DP_PEER_DEVICE_SST_SINK:
> /* add i2c over sideband */
> - ret = drm_dp_mst_register_i2c_bus(>aux);
> + drm_dp_mst_register_i2c_bus(>aux);
> break;
> case DP_PEER_DEVICE_MST_BRANCHING:
> lct = drm_dp_calculate_rad(port, rad);
> @@ -1821,25 +1812,20 @@ ssize_t drm_dp_mst_dpcd_write(struct drm_dp_aux *aux,
>
> static void drm_dp_check_mstb_guid(struct drm_dp_mst_branch *mstb, u8 *guid)
> {
> - int ret;
> -
> memcpy(mstb->guid, guid, 16);
Re: [EXT] Re: [PATCH] drm: fix HDR static metadata type field numbering
On Thu, Nov 28, 2019 at 08:39:41AM +, Laurentiu Palcu wrote: > On Wed, Nov 27, 2019 at 05:17:03PM +0200, Ville Syrjälä wrote: > > Caution: EXT Email > > > > On Wed, Nov 27, 2019 at 02:42:35PM +, Laurentiu Palcu wrote: > > > According to CTA-861 specification, HDR static metadata data block allows > > > a > > > sink to indicate which HDR metadata types it supports by setting the SM_0 > > > to > > > SM_7 bits. Currently, only Static Metadata Type 1 is supported and this is > > > indicated by setting the SM_0 bit to 1. > > > > > > However, the connector->hdr_sink_metadata.hdmi_type1.metadata_type is > > > always > > > 0, because hdr_metadata_type() in drm_edid.c checks the wrong bit. > > > > > > This patch corrects the HDMI_STATIC_METADATA_TYPE1 bit position. > > > > Was confused for a while why this has even been workning, but I guess > > that's due to userspace populating the metadata infoframe blob correctly > > even if we misreported the metadata types in the parsed EDID metadata > > blob. > > > > Hmm. Actually on further inspection this all seems to be dead code. The > > only thing we seem to use from the parsed EDID metadata stuff is > > eotf bitmask. We check that in drm_hdmi_infoframe_set_hdr_metadata() > > but we don't check the metadata type. > > > > Maybe we should just nuke this EDID parsing stuff entirely? Seems > > pretty much pointless. > > I've been thinking about that but we may need the rest of the fields as > well, even though they're not currently used. I'm referring to sink's > min/max luminance data. Shouldn't we also check min/max cll, besides > eotf, to make sure the source does not pass higher/lower luminance > values, than the sink supports, for optimal content rendering? > > However, CTA-861 is not very clear on how a sink should behave if > the CLL values exceed the allowed range... :/ Also, if the CLL range or > the FALL values passed in the DRM infoframe exceed the sink's advertised > min/max values, I guess the sink cannot go lower/higher than it can > anyway. In which case, we don't really need the rest of the HDR static > metadata block and nuking that part should be ok. I'm thinking we should just conclude that such userspace is a buggy mess and deserves whatever it gets. -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv3/RFC 1/4] drm/arm: Factor out generic afbc helpers
On Mon, Nov 25, 2019 at 09:55:06AM +0100, Daniel Vetter wrote:
> On Thu, Nov 21, 2019 at 06:22:44PM +0100, Andrzej Pietrasiewicz wrote:
> > These are useful for other users of afbc, e.g. rockchip.
> >
> > Signed-off-by: Andrzej Pietrasiewicz
> > ---
> > drivers/gpu/drm/Makefile | 2 +-
> > drivers/gpu/drm/drm_afbc.c| 84 +++
> > drivers/gpu/drm/drm_fourcc.c | 11 +++-
> > drivers/gpu/drm/drm_framebuffer.c | 71 +-
> > include/drm/drm_afbc.h| 35 +
> > 5 files changed, 199 insertions(+), 4 deletions(-)
> > create mode 100644 drivers/gpu/drm/drm_afbc.c
> > create mode 100644 include/drm/drm_afbc.h
> >
> > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > index d9bcc9f2a0a4..3a58f30b83a6 100644
> > --- a/drivers/gpu/drm/Makefile
> > +++ b/drivers/gpu/drm/Makefile
> > @@ -44,7 +44,7 @@ drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o
> > drm_dsc.o drm_probe_helper
> > drm_simple_kms_helper.o drm_modeset_helper.o \
> > drm_scdc_helper.o drm_gem_framebuffer_helper.o \
> > drm_atomic_state_helper.o drm_damage_helper.o \
> > - drm_format_helper.o drm_self_refresh_helper.o
> > + drm_format_helper.o drm_self_refresh_helper.o drm_afbc.o
>
> Just a quick drive-by:
> - you can't put this into helpers and call from core code. This should be
> core code. Also, I'd have just stuffed it into drm_format.c.
>
> - If you want to keep your separate file, please include it in the doc
> template, next to the format handling functions.
> >
> > drm_kms_helper-$(CONFIG_DRM_PANEL_BRIDGE) += bridge/panel.o
> > drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
> > diff --git a/drivers/gpu/drm/drm_afbc.c b/drivers/gpu/drm/drm_afbc.c
> > new file mode 100644
> > index ..f308c4719546
> > --- /dev/null
> > +++ b/drivers/gpu/drm/drm_afbc.c
> > @@ -0,0 +1,84 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * (C) 2019 Collabora Ltd.
> > + *
> > + * author: Andrzej Pietrasiewicz
> > + *
> > + */
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +/**
> > + * drm_afbc_get_superblk_wh - extract afbc block width/height from modifier
> > + * @modifier: the modifier to be looked at
> > + * @w: address of a place to store the block width
> > + * @h: address of a place to store the block height
> > + *
> > + * Returns: true if the modifier describes a supported block size
> > + */
> > +bool drm_afbc_get_superblk_wh(u64 modifier, u32 *w, u32 *h)
> > +{
> > + switch (modifier & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) {
> > + case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16:
> > + *w = 16;
> > + *h = 16;
> > + break;
> > + case AFBC_FORMAT_MOD_BLOCK_SIZE_32x8:
> > + *w = 32;
> > + *h = 8;
> > + break;
> > + case AFBC_FORMAT_MOD_BLOCK_SIZE_64x4:
> > + /* fall through */
> > + case AFBC_FORMAT_MOD_BLOCK_SIZE_32x8_64x4:
> > + /* fall through */
> > + default:
> > + DRM_DEBUG_KMS("Invalid AFBC_FORMAT_MOD_BLOCK_SIZE: %lld.\n",
> > + modifier & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK);
> > + return false;
> > + }
> > + return true;
> > +}
> > +EXPORT_SYMBOL_GPL(drm_afbc_get_superblk_wh);
> > +
> > +/**
> > + * drm_afbc_get_parameters - extract afbc parameters from mode command
> > + * @mode_cmd: mode command to be looked at
> > + * @afbc: address of a struct to be filled in
> > + */
> > +void drm_afbc_get_parameters(const struct drm_mode_fb_cmd2 *mode_cmd,
> > +struct drm_afbc *afbc)
> > +{
> > + drm_afbc_get_superblk_wh(mode_cmd->modifier[0],
> > +>tile_w, >tile_h);
> > + afbc->width = mode_cmd->pitches[0];
> > + afbc->height =
> > + DIV_ROUND_UP(mode_cmd->height, afbc->tile_h) * afbc->tile_h;
> > + afbc->offset = mode_cmd->offsets[0];
> > +}
> > +EXPORT_SYMBOL(drm_afbc_get_parameters);
> > +
> > +/**
> > + * drm_is_afbc - test if the modifier describes an afbc buffer
> > + * @modifier - modifier to be tested
> > + *
> > + * Returns: true if the modifier describes an afbc buffer
> > + */
> > +bool drm_is_afbc(u64 modifier)
> > +{
> > + /* is it ARM AFBC? */
> > + if ((modifier & DRM_FORMAT_MOD_ARM_AFBC(0)) == 0)
> > + return false;
> > +
> > + /* Block size must be known */
> > + if ((modifier & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) == 0)
> > + return false;
> > +
> > + return true;
> > +}
> > +EXPORT_SYMBOL_GPL(drm_is_afbc);
> > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > index c630064ccf41..8d9f197cc0ab 100644
> > --- a/drivers/gpu/drm/drm_fourcc.c
> > +++ b/drivers/gpu/drm/drm_fourcc.c
> > @@ -27,6 +27,7 @@
> > #include
> > #include
> >
> > +#include
> > #include
> > #include
> >
> > @@ -322,8 +323,14 @@
Re: [PATCH 08/13] video: fbdev: make fbops member of struct fb_info a const pointer
Hi Jani,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v5.4 next-20191127]
[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/Jani-Nikula/video-drm-constify-fbops-in-struct-fb_info/20191128-022047
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-14) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/udl/udl_fb.c: In function 'udl_fb_release':
>> drivers/gpu/drm/udl/udl_fb.c:256:24: error: assignment of member 'fb_mmap'
>> in read-only object
info->fbops->fb_mmap = udl_fb_mmap;
^
vim +/fb_mmap +256 drivers/gpu/drm/udl/udl_fb.c
5320918b9a8786 Dave Airlie 2010-12-15 240
5320918b9a8786 Dave Airlie 2010-12-15 241
5320918b9a8786 Dave Airlie 2010-12-15 242 /*
5320918b9a8786 Dave Airlie 2010-12-15 243 * Assumes caller is holding
info->lock mutex (for open and release at least)
5320918b9a8786 Dave Airlie 2010-12-15 244 */
5320918b9a8786 Dave Airlie 2010-12-15 245 static int
udl_fb_release(struct fb_info *info, int user)
5320918b9a8786 Dave Airlie 2010-12-15 246 {
5320918b9a8786 Dave Airlie 2010-12-15 247 struct udl_fbdev
*ufbdev = info->par;
5320918b9a8786 Dave Airlie 2010-12-15 248
5320918b9a8786 Dave Airlie 2010-12-15 249 ufbdev->fb_count--;
5320918b9a8786 Dave Airlie 2010-12-15 250
2b721f20770ccb Daniel Vetter 2016-08-10 251 #ifdef
CONFIG_DRM_FBDEV_EMULATION
5320918b9a8786 Dave Airlie 2010-12-15 252 if ((ufbdev->fb_count
== 0) && (info->fbdefio)) {
5320918b9a8786 Dave Airlie 2010-12-15 253
fb_deferred_io_cleanup(info);
5320918b9a8786 Dave Airlie 2010-12-15 254
kfree(info->fbdefio);
5320918b9a8786 Dave Airlie 2010-12-15 255 info->fbdefio =
NULL;
5320918b9a8786 Dave Airlie 2010-12-15 @256
info->fbops->fb_mmap = udl_fb_mmap;
5320918b9a8786 Dave Airlie 2010-12-15 257 }
2b721f20770ccb Daniel Vetter 2016-08-10 258 #endif
5320918b9a8786 Dave Airlie 2010-12-15 259
90991209837ab6 Mikulas Patocka 2018-06-03 260 pr_debug("released
/dev/fb%d user=%d count=%d\n",
5320918b9a8786 Dave Airlie 2010-12-15 261 info->node,
user, ufbdev->fb_count);
5320918b9a8786 Dave Airlie 2010-12-15 262
5320918b9a8786 Dave Airlie 2010-12-15 263 return 0;
5320918b9a8786 Dave Airlie 2010-12-15 264 }
5320918b9a8786 Dave Airlie 2010-12-15 265
:: The code at line 256 was first introduced by commit
:: 5320918b9a87865223fd6b228e530bf30bc64d9d drm/udl: initial UDL driver (v4)
:: TO: Dave Airlie
:: CC: Dave Airlie
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/13] samples: vfio-mdev: constify fb ops
On Thu, 28 Nov 2019, Christophe de Dinechin
wrote:
>> On 27 Nov 2019, at 17:32, Jani Nikula wrote:
>>
>> Now that the fbops member of struct fb_info is const, we can star making
> s/star/start/
Ooops, thanks.
BR,
Jani.
>
>> the ops const as well.
>>
>> Cc: Kirti Wankhede
>> Cc: k...@vger.kernel.org
>> Signed-off-by: Jani Nikula
>> ---
>> samples/vfio-mdev/mdpy-fb.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/samples/vfio-mdev/mdpy-fb.c b/samples/vfio-mdev/mdpy-fb.c
>> index 2719bb259653..21dbf63d6e41 100644
>> --- a/samples/vfio-mdev/mdpy-fb.c
>> +++ b/samples/vfio-mdev/mdpy-fb.c
>> @@ -86,7 +86,7 @@ static void mdpy_fb_destroy(struct fb_info *info)
>> iounmap(info->screen_base);
>> }
>>
>> -static struct fb_ops mdpy_fb_ops = {
>> +static const struct fb_ops mdpy_fb_ops = {
>> .owner = THIS_MODULE,
>> .fb_destroy = mdpy_fb_destroy,
>> .fb_setcolreg = mdpy_fb_setcolreg,
>> --
>> 2.20.1
>>
>
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 01/13] video: fb_defio: preserve user fb_ops
On Thu, 28 Nov 2019, Daniel Vetter wrote:
> On Thu, Nov 28, 2019 at 11:05:57AM +0100, Daniel Vetter wrote:
>> On Thu, Nov 28, 2019 at 11:09:46AM +0200, Jani Nikula wrote:
>> > On Wed, 27 Nov 2019, Daniel Vetter wrote:
>> > > On Wed, Nov 27, 2019 at 07:17:41PM +0100, Daniel Vetter wrote:
>> > >> On Wed, Nov 27, 2019 at 06:31:57PM +0200, Jani Nikula wrote:
>> > >> > Modifying fb_ops directly to override fb_mmap with fb_deferred_io_mmap
>> > >> > and then resetting it to NULL afterwards causes problems all over the
>> > >> > place. First, it prevents making the fbops member of struct fb_info a
>> > >> > const pointer, which means we can't make struct fb_ops const
>> > >> > anywhere. Second, a few places have to go out of their way to restore
>> > >> > the original fb_mmap pointer that gets reset to NULL.
>> > >> >
>> > >> > Preserve the passed in fb_ops by making a copy of it and modifying
>> > >> > that
>> > >> > instead. Add a deferred_io_private member to struct fb_info to store
>> > >> > the
>> > >> > pointer to the old fb_ops, and restore that at cleanup.
>> > >> >
>> > >> > Cc: Jaya Kumar
>> > >> > Cc: linux-fb...@vger.kernel.org
>> > >> > Signed-off-by: Jani Nikula
>> > >> >
>> > >> > ---
>> > >> >
>> > >> > Note: If the approach is acceptable, we'll also need to handle the
>> > >> > error
>> > >> > returns on memory allocation failures at fb_deferred_io_init() call
>> > >> > sites. There are 13.
>> > >>
>> > >> it's fbdev defio, I think we can do worse with less effort. Just embed a
>> > >> copy of fb_ops into fb_info, and use that, and tada! no memory
>> > >> allocation
>> > >> needed :-)
>> > >>
>> > >> I'd totally r-b that patch.
>> > >>
>> > >> Or do what Ville suggested, add an fb_info->fbdefio.enabled, set that in
>> > >> the _init function and in fb_mmap call fb_deferred_io_mmap for that case
>> > >> instead of the driver's fb_ops->fb_mmap. There's only one caller of that
>> > >> in the entire tree, in fbmem.c. Also, we could/should nuke the
>> > >> EXPORT_SYMBOL(fb_deferred_io_mmap) I think.
>> > >
>> > > I just realized that fb_info->fbdefio is a pointer, so this would be
>> > > really simple to pull off I think.
>> >
>> > Heh, having a
>> >
>> >int (*fb_deferred_io_mmap)(struct fb_info *, struct vm_area_struct *);
>> >
>> > member in struct fb_info, and using that in fbmem.c if non-NULL, was
>> > actually my first idea. I didn't think it was particularly pretty, but
>> > if we don't care about aesthetics...
>> >
>> > Would you like that instead of the patch at hand?
>>
>>
>> diff --git a/drivers/video/fbdev/core/fb_defio.c
>> b/drivers/video/fbdev/core/fb_defio.c
>> index 82c20c6047b0..9275c6bd71da 100644
>> --- a/drivers/video/fbdev/core/fb_defio.c
>> +++ b/drivers/video/fbdev/core/fb_defio.c
>> @@ -206,13 +206,11 @@ void fb_deferred_io_init(struct fb_info *info)
>>
>> BUG_ON(!fbdefio);
>> mutex_init(>lock);
>> -info->fbops->fb_mmap = fb_deferred_io_mmap;
>> INIT_DELAYED_WORK(>deferred_work, fb_deferred_io_work);
>> INIT_LIST_HEAD(>pagelist);
>> if (fbdefio->delay == 0) /* set a default of 1 s */
>> fbdefio->delay = HZ;
>> }
>> -EXPORT_SYMBOL_GPL(fb_deferred_io_init);
>>
>> void fb_deferred_io_open(struct fb_info *info,
>> struct inode *inode,
>> diff --git a/drivers/video/fbdev/core/fbmem.c
>> b/drivers/video/fbdev/core/fbmem.c
>> index 86b06a599f96..6af627f281c3 100644
>> --- a/drivers/video/fbdev/core/fbmem.c
>> +++ b/drivers/video/fbdev/core/fbmem.c
>> @@ -1341,7 +1341,16 @@ fb_mmap(struct file *file, struct vm_area_struct *
>> vma)
>> return -ENODEV;
>> fb = info->fbops;
>> mutex_lock(>mm_lock);
>> -if (fb->fb_mmap) {
>> +if (fb->fbdefio) {
>> +/*
>> + * The framebuffer needs to be accessed decrypted, be sure
>> + * SME protection is removed ahead of the call
>> + */
>> +vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
>> +res = fb_deferred_io_mmap(info, vma);
>> +mutex_unlock(>mm_lock);
>> +return res;
>> +} else if (fb->fb_mmap) {
>> int res;
>>
>> /*
>>
>> Is what I was thinking off as the pretty solution. Add an explicit
>> fb_info->fbdefio_enabled boolean if you don't feel like auditing all the
>> drivers for whether they really call defio_init() every time they assign
>> something to that pointer. A quick scan brought some nasties to light in
>> that area.
>
> Correction, brain wasn't awake yet, I've done the audit and the above diff
> should work afaict.
It just felt sketchy to me to depend on that pointer being set as the
decider, independent of defio init. But if you think that's the way to
go, I'm not going to argue. I'll bet it won't go unnoticed if
fb_deferred_io_mmap() gets called without the init. ;)
BR,
Jani.
> -Daniel
>
>>
>> I think a function pointer here is pointless because we clearly don't need
>>
Re: Next round of associating ddc adapters with connectors
On Fri, 22 Nov 2019, Andrzej Pietrasiewicz wrote: > Dear Maintainers, > > Can you please express your opinion on these patches: > > [tegra] https://patchwork.freedesktop.org/patch/327099/?series=65831=1 > [vc4] https://patchwork.freedesktop.org/patch/327102/?series=65831=1 > [zte] https://patchwork.freedesktop.org/patch/327106/?series=65831=1 > [zte] https://patchwork.freedesktop.org/patch/327112/?series=65831=1 > [i915] https://patchwork.freedesktop.org/patch/327120/?series=65831=1 I've expressed my opinion in [1] and that hasn't changed. I don't like the interface, and a few years down the line I expect there's going to be a patch series renaming drm_connector_init_with_ddc() back to drm_connector_init() with an extra parameter, and NULL will be passed where ddc is not relevant. Anyway, that ship has sailed, you didn't even care to reply, and nobody else seems to mind, so meh, and ack on the patch. Indeed I would've applied it already, but it no longer applies, so please send the rebased i915 patch individually to intel-...@lists.freedesktop.org so we'll also get CI coverage against the current drm-tip tree. BR, Jani. [1] http://lore.kernel.org/r/875znlp6yk@intel.com > > ? > > Of the originally posted patches: > > https://patchwork.freedesktop.org/series/62764/ > > only the above are still outstanding, the others have been applied > to at least drm-misc-next or are already upstream. > > Regards, > > Andrzej -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/fourcc: Fill out all block sizes for P210
On Tue, Nov 26, 2019 at 11:46:54AM +, Liviu Dudau wrote:
> On Tue, Nov 26, 2019 at 10:14:14AM +0100, Daniel Vetter wrote:
> > 0 means 1 as the default, but it's mighty confusing if the block size
> > for the first plane is spelled out explicitly, but not for the 2nd
> > plane.
> >
> > No cc: stable because this is just confusion, but 0 functional issue.
>
> Agree!
>
> >
> > Fixes: 7ba0fee247ee ("drm/fourcc: Add AFBC yuv fourccs for Mali")
> > Cc: Brian Starkey
> > Cc: Ayan Kumar Halder
> > Cc: Liviu Dudau
>
> Acked-by: Liviu Dudau
Both patches applied, thanks for taking a look.
-Daniel
>
> Best regards,
>
> > Cc: Alyssa Rosenzweig
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripard
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_fourcc.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > index fe79ce857c8a..b234bfaeda06 100644
> > --- a/drivers/gpu/drm/drm_fourcc.c
> > +++ b/drivers/gpu/drm/drm_fourcc.c
> > @@ -263,7 +263,7 @@ const struct drm_format_info *__drm_format_info(u32
> > format)
> > .hsub = 2, .vsub = 2, .is_yuv = true},
> > { .format = DRM_FORMAT_P210,.depth = 0,
> > .num_planes = 2, .char_per_block = { 2, 4, 0 },
> > - .block_w = { 1, 0, 0 }, .block_h = { 1, 0, 0 }, .hsub = 2,
> > + .block_w = { 1, 1, 0 }, .block_h = { 1, 1, 0 }, .hsub = 2,
> > .vsub = 1, .is_yuv = true },
> > { .format = DRM_FORMAT_VUY101010, .depth = 0,
> > .num_planes = 1, .cpp = { 0, 0, 0 }, .hsub = 1, .vsub = 1,
> > --
> > 2.24.0
> >
>
> --
>
> | I would like to |
> | fix the world, |
> | but they're not |
> | giving me the |
> \ source code! /
> ---
> ¯\_(ツ)_/¯
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/hibmc: Use drm_gem_fb_create
On Thu, Nov 28, 2019 at 04:44:32PM +0800, kbuild test robot wrote:
> Hi Daniel,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on drm-intel/for-linux-next]
> [also build test ERROR on v5.4 next-20191127]
> [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/Daniel-Vetter/drm-rockchip-Use-drm_gem_fb_create_with_dirty/20191128-023917
> base: git://anongit.freedesktop.org/drm-intel for-linux-next
> config: arm64-randconfig-a001-20191128 (attached as .config)
> compiler: aarch64-linux-gcc (GCC) 7.4.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
> GCC_VERSION=7.4.0 make.cross ARCH=arm64
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot
>
> All errors (new ones prefixed by >>):
Oops, I meant to drop this patch from this series, but forgot. It's
superseeded by the series Thomas has (which actually compiles).
-Daniel
>
>drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c: In function
> 'hibmc_plane_atomic_update':
> >> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c:107:28: error: 'fb'
> >> undeclared (first use in this function); did you mean 'mb'?
> gbo = drm_gem_vram_of_gem(fb->obj[0]);
>^~
>mb
>drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c:107:28: note: each
> undeclared identifier is reported only once for each function it appears in
> --
>drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c: In function
> 'hibmc_drm_fb_create':
> >> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c:119:37: error: 'struct
> >> drm_framebuffer' has no member named 'fb'
> hi_fbdev->helper.fb = _fbdev->fb->fb;
> ^~
>
> vim +107 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
>
> 93
> 94static void hibmc_plane_atomic_update(struct drm_plane *plane,
> 95 struct drm_plane_state
> *old_state)
> 96{
> 97struct drm_plane_state *state = plane->state;
> 98u32 reg;
> 99s64 gpu_addr = 0;
>100unsigned int line_l;
>101struct hibmc_drm_private *priv =
> plane->dev->dev_private;
>102struct drm_gem_vram_object *gbo;
>103
>104if (!state->fb)
>105return;
>106
> > 107gbo = drm_gem_vram_of_gem(fb->obj[0]);
>108
>109gpu_addr = drm_gem_vram_offset(gbo);
>110if (WARN_ON_ONCE(gpu_addr < 0))
>111return; /* Bug: we didn't pin the BO to VRAM in
> prepare_fb. */
>112
>113writel(gpu_addr, priv->mmio + HIBMC_CRT_FB_ADDRESS);
>114
>115reg = state->fb->width * (state->fb->format->cpp[0]);
>116/* now line_pad is 16 */
>117reg = PADDING(16, reg);
>118
>119line_l = state->fb->width * state->fb->format->cpp[0];
>120line_l = PADDING(16, line_l);
>121writel(HIBMC_FIELD(HIBMC_CRT_FB_WIDTH_WIDTH, reg) |
>122 HIBMC_FIELD(HIBMC_CRT_FB_WIDTH_OFFS, line_l),
>123 priv->mmio + HIBMC_CRT_FB_WIDTH);
>124
>125/* SET PIXEL FORMAT */
>126reg = readl(priv->mmio + HIBMC_CRT_DISP_CTL);
>127reg &= ~HIBMC_CRT_DISP_CTL_FORMAT_MASK;
>128reg |= HIBMC_FIELD(HIBMC_CRT_DISP_CTL_FORMAT,
>129 state->fb->format->cpp[0] * 8 / 16);
>130writel(reg, priv->mmio + HIBMC_CRT_DISP_CTL);
>131}
>132
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org Intel Corporation
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/13] samples: vfio-mdev: constify fb ops
On Thu, Nov 28, 2019 at 11:22:23AM +0200, Jani Nikula wrote:
> On Wed, 27 Nov 2019, Daniel Vetter wrote:
> > On Wed, Nov 27, 2019 at 06:32:09PM +0200, Jani Nikula wrote:
> >> Now that the fbops member of struct fb_info is const, we can star making
> >> the ops const as well.
> >>
> >> Cc: Kirti Wankhede
> >> Cc: k...@vger.kernel.org
> >> Signed-off-by: Jani Nikula
> >
> > You've missed at least drivers/staging/fbtft in your search. I guess you
> > need to do a full make allyesconfig on x86/arm and arm64 (the latter
> > because some stupid drivers only compile there, not on arm, don't ask).
> > Still misses a pile of mips/ppc only stuff and maybe the sparcs and
> > alphas, but should be good enough.
>
> fbtft dynamically allocates the fbops, for whatever reason. There were
> others like that too. Some of the drivers modify the fbops runtime to
> choose different hooks for different configurations. Can't change them
> all anyway.
>
> Facilitating making the fbops const is one thing (patches 1-8), but I'm
> not really sure I want to sign up for exhaustively moving fbops to
> rodata on anything beyond drivers/gpu/drm. It's not like I leave stuff
> broken. Besides I am trying to cover all the low hanging fruit where I
> can simply add the "const" and be done with it.
Uh indeed, I didn't check the output of my grep with sufficient finesses.
r-b as-is on that pile.
Since fbdev is officially in drm-misc you can just merge it all once the
prep is done - feels silly not to when you've done the work already.
-Daniel
>
> BR,
> Jani.
>
> >
> > With that done, on the remaining patches:
> >
> > Reviewed-by: Daniel Vetter
> >
> >> ---
> >> samples/vfio-mdev/mdpy-fb.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/samples/vfio-mdev/mdpy-fb.c b/samples/vfio-mdev/mdpy-fb.c
> >> index 2719bb259653..21dbf63d6e41 100644
> >> --- a/samples/vfio-mdev/mdpy-fb.c
> >> +++ b/samples/vfio-mdev/mdpy-fb.c
> >> @@ -86,7 +86,7 @@ static void mdpy_fb_destroy(struct fb_info *info)
> >>iounmap(info->screen_base);
> >> }
> >>
> >> -static struct fb_ops mdpy_fb_ops = {
> >> +static const struct fb_ops mdpy_fb_ops = {
> >>.owner = THIS_MODULE,
> >>.fb_destroy = mdpy_fb_destroy,
> >>.fb_setcolreg = mdpy_fb_setcolreg,
> >> --
> >> 2.20.1
> >>
> >> ___
> >> dri-devel mailing list
> >> dri-devel@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 01/13] video: fb_defio: preserve user fb_ops
On Thu, Nov 28, 2019 at 11:05:57AM +0100, Daniel Vetter wrote:
> On Thu, Nov 28, 2019 at 11:09:46AM +0200, Jani Nikula wrote:
> > On Wed, 27 Nov 2019, Daniel Vetter wrote:
> > > On Wed, Nov 27, 2019 at 07:17:41PM +0100, Daniel Vetter wrote:
> > >> On Wed, Nov 27, 2019 at 06:31:57PM +0200, Jani Nikula wrote:
> > >> > Modifying fb_ops directly to override fb_mmap with fb_deferred_io_mmap
> > >> > and then resetting it to NULL afterwards causes problems all over the
> > >> > place. First, it prevents making the fbops member of struct fb_info a
> > >> > const pointer, which means we can't make struct fb_ops const
> > >> > anywhere. Second, a few places have to go out of their way to restore
> > >> > the original fb_mmap pointer that gets reset to NULL.
> > >> >
> > >> > Preserve the passed in fb_ops by making a copy of it and modifying that
> > >> > instead. Add a deferred_io_private member to struct fb_info to store
> > >> > the
> > >> > pointer to the old fb_ops, and restore that at cleanup.
> > >> >
> > >> > Cc: Jaya Kumar
> > >> > Cc: linux-fb...@vger.kernel.org
> > >> > Signed-off-by: Jani Nikula
> > >> >
> > >> > ---
> > >> >
> > >> > Note: If the approach is acceptable, we'll also need to handle the
> > >> > error
> > >> > returns on memory allocation failures at fb_deferred_io_init() call
> > >> > sites. There are 13.
> > >>
> > >> it's fbdev defio, I think we can do worse with less effort. Just embed a
> > >> copy of fb_ops into fb_info, and use that, and tada! no memory allocation
> > >> needed :-)
> > >>
> > >> I'd totally r-b that patch.
> > >>
> > >> Or do what Ville suggested, add an fb_info->fbdefio.enabled, set that in
> > >> the _init function and in fb_mmap call fb_deferred_io_mmap for that case
> > >> instead of the driver's fb_ops->fb_mmap. There's only one caller of that
> > >> in the entire tree, in fbmem.c. Also, we could/should nuke the
> > >> EXPORT_SYMBOL(fb_deferred_io_mmap) I think.
> > >
> > > I just realized that fb_info->fbdefio is a pointer, so this would be
> > > really simple to pull off I think.
> >
> > Heh, having a
> >
> > int (*fb_deferred_io_mmap)(struct fb_info *, struct vm_area_struct *);
> >
> > member in struct fb_info, and using that in fbmem.c if non-NULL, was
> > actually my first idea. I didn't think it was particularly pretty, but
> > if we don't care about aesthetics...
> >
> > Would you like that instead of the patch at hand?
>
>
> diff --git a/drivers/video/fbdev/core/fb_defio.c
> b/drivers/video/fbdev/core/fb_defio.c
> index 82c20c6047b0..9275c6bd71da 100644
> --- a/drivers/video/fbdev/core/fb_defio.c
> +++ b/drivers/video/fbdev/core/fb_defio.c
> @@ -206,13 +206,11 @@ void fb_deferred_io_init(struct fb_info *info)
>
> BUG_ON(!fbdefio);
> mutex_init(>lock);
> - info->fbops->fb_mmap = fb_deferred_io_mmap;
> INIT_DELAYED_WORK(>deferred_work, fb_deferred_io_work);
> INIT_LIST_HEAD(>pagelist);
> if (fbdefio->delay == 0) /* set a default of 1 s */
> fbdefio->delay = HZ;
> }
> -EXPORT_SYMBOL_GPL(fb_deferred_io_init);
>
> void fb_deferred_io_open(struct fb_info *info,
>struct inode *inode,
> diff --git a/drivers/video/fbdev/core/fbmem.c
> b/drivers/video/fbdev/core/fbmem.c
> index 86b06a599f96..6af627f281c3 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1341,7 +1341,16 @@ fb_mmap(struct file *file, struct vm_area_struct * vma)
> return -ENODEV;
> fb = info->fbops;
> mutex_lock(>mm_lock);
> - if (fb->fb_mmap) {
> + if (fb->fbdefio) {
> + /*
> + * The framebuffer needs to be accessed decrypted, be sure
> + * SME protection is removed ahead of the call
> + */
> + vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
> + res = fb_deferred_io_mmap(info, vma);
> + mutex_unlock(>mm_lock);
> + return res;
> + } else if (fb->fb_mmap) {
> int res;
>
> /*
>
> Is what I was thinking off as the pretty solution. Add an explicit
> fb_info->fbdefio_enabled boolean if you don't feel like auditing all the
> drivers for whether they really call defio_init() every time they assign
> something to that pointer. A quick scan brought some nasties to light in
> that area.
Correction, brain wasn't awake yet, I've done the audit and the above diff
should work afaict.
-Daniel
>
> I think a function pointer here is pointless because we clearly don't need
> it, and with all the panic around function pointers a direct call feels
> much better :-)
> -Daniel
>
> >
> > BR,
> > Jani.
> >
> >
> > > -Daniel
> > >
> > >>
> > >> That version would also get my r-b stamp. So up to you what you prefer.
> > >> -Daniel
> > >>
> > >> > ---
> > >> > drivers/video/fbdev/core/fb_defio.c | 25 ++---
> > >> > include/linux/fb.h | 3 ++-
> > >> > 2 files
Re: [Intel-gfx] [PATCH 01/13] video: fb_defio: preserve user fb_ops
On Thu, Nov 28, 2019 at 11:09:46AM +0200, Jani Nikula wrote:
> On Wed, 27 Nov 2019, Daniel Vetter wrote:
> > On Wed, Nov 27, 2019 at 07:17:41PM +0100, Daniel Vetter wrote:
> >> On Wed, Nov 27, 2019 at 06:31:57PM +0200, Jani Nikula wrote:
> >> > Modifying fb_ops directly to override fb_mmap with fb_deferred_io_mmap
> >> > and then resetting it to NULL afterwards causes problems all over the
> >> > place. First, it prevents making the fbops member of struct fb_info a
> >> > const pointer, which means we can't make struct fb_ops const
> >> > anywhere. Second, a few places have to go out of their way to restore
> >> > the original fb_mmap pointer that gets reset to NULL.
> >> >
> >> > Preserve the passed in fb_ops by making a copy of it and modifying that
> >> > instead. Add a deferred_io_private member to struct fb_info to store the
> >> > pointer to the old fb_ops, and restore that at cleanup.
> >> >
> >> > Cc: Jaya Kumar
> >> > Cc: linux-fb...@vger.kernel.org
> >> > Signed-off-by: Jani Nikula
> >> >
> >> > ---
> >> >
> >> > Note: If the approach is acceptable, we'll also need to handle the error
> >> > returns on memory allocation failures at fb_deferred_io_init() call
> >> > sites. There are 13.
> >>
> >> it's fbdev defio, I think we can do worse with less effort. Just embed a
> >> copy of fb_ops into fb_info, and use that, and tada! no memory allocation
> >> needed :-)
> >>
> >> I'd totally r-b that patch.
> >>
> >> Or do what Ville suggested, add an fb_info->fbdefio.enabled, set that in
> >> the _init function and in fb_mmap call fb_deferred_io_mmap for that case
> >> instead of the driver's fb_ops->fb_mmap. There's only one caller of that
> >> in the entire tree, in fbmem.c. Also, we could/should nuke the
> >> EXPORT_SYMBOL(fb_deferred_io_mmap) I think.
> >
> > I just realized that fb_info->fbdefio is a pointer, so this would be
> > really simple to pull off I think.
>
> Heh, having a
>
> int (*fb_deferred_io_mmap)(struct fb_info *, struct vm_area_struct *);
>
> member in struct fb_info, and using that in fbmem.c if non-NULL, was
> actually my first idea. I didn't think it was particularly pretty, but
> if we don't care about aesthetics...
>
> Would you like that instead of the patch at hand?
diff --git a/drivers/video/fbdev/core/fb_defio.c
b/drivers/video/fbdev/core/fb_defio.c
index 82c20c6047b0..9275c6bd71da 100644
--- a/drivers/video/fbdev/core/fb_defio.c
+++ b/drivers/video/fbdev/core/fb_defio.c
@@ -206,13 +206,11 @@ void fb_deferred_io_init(struct fb_info *info)
BUG_ON(!fbdefio);
mutex_init(>lock);
- info->fbops->fb_mmap = fb_deferred_io_mmap;
INIT_DELAYED_WORK(>deferred_work, fb_deferred_io_work);
INIT_LIST_HEAD(>pagelist);
if (fbdefio->delay == 0) /* set a default of 1 s */
fbdefio->delay = HZ;
}
-EXPORT_SYMBOL_GPL(fb_deferred_io_init);
void fb_deferred_io_open(struct fb_info *info,
struct inode *inode,
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 86b06a599f96..6af627f281c3 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1341,7 +1341,16 @@ fb_mmap(struct file *file, struct vm_area_struct * vma)
return -ENODEV;
fb = info->fbops;
mutex_lock(>mm_lock);
- if (fb->fb_mmap) {
+ if (fb->fbdefio) {
+ /*
+* The framebuffer needs to be accessed decrypted, be sure
+* SME protection is removed ahead of the call
+*/
+ vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
+ res = fb_deferred_io_mmap(info, vma);
+ mutex_unlock(>mm_lock);
+ return res;
+ } else if (fb->fb_mmap) {
int res;
/*
Is what I was thinking off as the pretty solution. Add an explicit
fb_info->fbdefio_enabled boolean if you don't feel like auditing all the
drivers for whether they really call defio_init() every time they assign
something to that pointer. A quick scan brought some nasties to light in
that area.
I think a function pointer here is pointless because we clearly don't need
it, and with all the panic around function pointers a direct call feels
much better :-)
-Daniel
>
> BR,
> Jani.
>
>
> > -Daniel
> >
> >>
> >> That version would also get my r-b stamp. So up to you what you prefer.
> >> -Daniel
> >>
> >> > ---
> >> > drivers/video/fbdev/core/fb_defio.c | 25 ++---
> >> > include/linux/fb.h | 3 ++-
> >> > 2 files changed, 24 insertions(+), 4 deletions(-)
> >> >
> >> > diff --git a/drivers/video/fbdev/core/fb_defio.c
> >> > b/drivers/video/fbdev/core/fb_defio.c
> >> > index 82c20c6047b0..36697844c1e0 100644
> >> > --- a/drivers/video/fbdev/core/fb_defio.c
> >> > +++ b/drivers/video/fbdev/core/fb_defio.c
> >> > @@ -200,13 +200,23 @@ static void fb_deferred_io_work(struct work_struct
Re: [PATCH] drm/dp_mst: Fix W=1 warnings
On Tue, 12 Nov 2019, Benjamin Gaignard wrote:
> Fix the warnings that show up with W=1.
> They are all about unused but set variables.
>
> Signed-off-by: Benjamin Gaignard
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 50
> +--
> 1 file changed, 19 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index b854a422a523..6ff554be8000 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -672,7 +672,6 @@ static bool drm_dp_sideband_msg_build(struct
> drm_dp_sideband_msg_rx *msg,
> u8 *replybuf, u8 replybuflen, bool hdr)
> {
> int ret;
> - u8 crc4;
>
> if (hdr) {
> u8 hdrlen;
> @@ -714,8 +713,6 @@ static bool drm_dp_sideband_msg_build(struct
> drm_dp_sideband_msg_rx *msg,
> }
>
> if (msg->curchunk_idx >= msg->curchunk_len) {
> - /* do CRC */
> - crc4 = drm_dp_msg_data_crc4(msg->chunk, msg->curchunk_len - 1);
Someone who knows this code really needs to check if we should be using
crc4 instead of just throwing this away as unused.
> /* copy chunk into bigger msg */
> memcpy(>msg[msg->curlen], msg->chunk, msg->curchunk_len -
> 1);
> msg->curlen += msg->curchunk_len - 1;
> @@ -1744,14 +1741,13 @@ static u8 drm_dp_calculate_rad(struct drm_dp_mst_port
> *port,
> */
> static bool drm_dp_port_setup_pdt(struct drm_dp_mst_port *port)
The function changed in c485e2c97dae ("drm/dp_mst: Refactor pdt
setup/teardown, add more locking").
> {
> - int ret;
> u8 rad[6], lct;
> bool send_link = false;
> switch (port->pdt) {
> case DP_PEER_DEVICE_DP_LEGACY_CONV:
> case DP_PEER_DEVICE_SST_SINK:
> /* add i2c over sideband */
> - ret = drm_dp_mst_register_i2c_bus(>aux);
> + drm_dp_mst_register_i2c_bus(>aux);
> break;
> case DP_PEER_DEVICE_MST_BRANCHING:
> lct = drm_dp_calculate_rad(port, rad);
> @@ -1821,21 +1817,18 @@ ssize_t drm_dp_mst_dpcd_write(struct drm_dp_aux *aux,
>
> static void drm_dp_check_mstb_guid(struct drm_dp_mst_branch *mstb, u8 *guid)
> {
> - int ret;
> -
> memcpy(mstb->guid, guid, 16);
>
> if (!drm_dp_validate_guid(mstb->mgr, mstb->guid)) {
> if (mstb->port_parent) {
> - ret = drm_dp_send_dpcd_write(
> + drm_dp_send_dpcd_write(
> mstb->mgr,
> mstb->port_parent,
> DP_GUID,
> 16,
> mstb->guid);
Indentation could be fixed while at it.
> } else {
> -
> - ret = drm_dp_dpcd_write(
> + drm_dp_dpcd_write(
> mstb->mgr->aux,
> DP_GUID,
> mstb->guid,
> @@ -2427,14 +2420,14 @@ static void drm_dp_send_link_address(struct
> drm_dp_mst_topology_mgr *mgr,
> {
> struct drm_dp_sideband_msg_tx *txmsg;
> struct drm_dp_link_address_ack_reply *reply;
> - int i, len, ret;
> + int i, ret;
>
> txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> if (!txmsg)
> return;
>
> txmsg->dst = mstb;
> - len = build_link_address(txmsg);
> + build_link_address(txmsg);
Maybe you should make the function void while at it?
>
> mstb->link_address_sent = true;
> drm_dp_queue_down_tx(mgr, txmsg);
> @@ -2476,7 +2469,6 @@ drm_dp_send_enum_path_resources(struct
> drm_dp_mst_topology_mgr *mgr,
> {
> struct drm_dp_enum_path_resources_ack_reply *path_res;
> struct drm_dp_sideband_msg_tx *txmsg;
> - int len;
> int ret;
>
> txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> @@ -2484,7 +2476,7 @@ drm_dp_send_enum_path_resources(struct
> drm_dp_mst_topology_mgr *mgr,
> return -ENOMEM;
>
> txmsg->dst = mstb;
> - len = build_enum_path_resources(txmsg, port->port_num);
> + build_enum_path_resources(txmsg, port->port_num);
Maybe you should make the function void while at it?
> drm_dp_queue_down_tx(mgr, txmsg);
>
> @@ -2567,7 +2559,7 @@ static int drm_dp_payload_send_msg(struct
> drm_dp_mst_topology_mgr *mgr,
> {
> struct drm_dp_sideband_msg_tx *txmsg;
> struct drm_dp_mst_branch *mstb;
> - int len, ret, port_num;
> + int ret, port_num;
> u8 sinks[DRM_DP_MAX_SDP_STREAMS];
> int i;
>
> @@ -2592,9 +2584,9 @@ static int drm_dp_payload_send_msg(struct
> drm_dp_mst_topology_mgr *mgr,
> sinks[i] = i;
>
> txmsg->dst = mstb;
> - len = build_allocate_payload(txmsg, port_num,
> - id,
> -
Re: [PATCH 08/13] video: fbdev: make fbops member of struct fb_info a const pointer
Hi Jani, I love your patch! Yet something to improve: [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on v5.4 next-20191127] [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/Jani-Nikula/video-drm-constify-fbops-in-struct-fb_info/20191128-022047 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: x86_64-randconfig-s1-20191128 (attached as .config) compiler: gcc-7 (Debian 7.4.0-14) 7.4.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): drivers/video/fbdev/uvesafb.c: In function 'uvesafb_init_info': >> drivers/video/fbdev/uvesafb.c:1443:25: error: assignment of member >> 'fb_blank' in read-only object info->fbops->fb_blank = NULL; ^ >> drivers/video/fbdev/uvesafb.c:1513:31: error: assignment of member >> 'fb_pan_display' in read-only object info->fbops->fb_pan_display = NULL; ^ -- drivers/video/fbdev/mb862xx/mb862xxfb_accel.c: In function 'mb862xxfb_init_accel': >> drivers/video/fbdev/mb862xx/mb862xxfb_accel.c:311:28: error: assignment of >> member 'fb_fillrect' in read-only object info->fbops->fb_fillrect = cfb_fillrect; ^ >> drivers/video/fbdev/mb862xx/mb862xxfb_accel.c:312:28: error: assignment of >> member 'fb_copyarea' in read-only object info->fbops->fb_copyarea = cfb_copyarea; ^ >> drivers/video/fbdev/mb862xx/mb862xxfb_accel.c:313:29: error: assignment of >> member 'fb_imageblit' in read-only object info->fbops->fb_imageblit = cfb_imageblit; ^ drivers/video/fbdev/mb862xx/mb862xxfb_accel.c:316:28: error: assignment of member 'fb_fillrect' in read-only object info->fbops->fb_fillrect = mb86290fb_fillrect; ^ drivers/video/fbdev/mb862xx/mb862xxfb_accel.c:317:28: error: assignment of member 'fb_copyarea' in read-only object info->fbops->fb_copyarea = mb86290fb_copyarea; ^ drivers/video/fbdev/mb862xx/mb862xxfb_accel.c:318:29: error: assignment of member 'fb_imageblit' in read-only object info->fbops->fb_imageblit = mb86290fb_imageblit; ^ -- drivers/video/fbdev/nvidia/nvidia.c: In function 'nvidiafb_set_par': >> drivers/video/fbdev/nvidia/nvidia.c:663:29: error: assignment of member >> 'fb_imageblit' in read-only object info->fbops->fb_imageblit = nvidiafb_imageblit; ^ >> drivers/video/fbdev/nvidia/nvidia.c:664:28: error: assignment of member >> 'fb_fillrect' in read-only object info->fbops->fb_fillrect = nvidiafb_fillrect; ^ >> drivers/video/fbdev/nvidia/nvidia.c:665:28: error: assignment of member >> 'fb_copyarea' in read-only object info->fbops->fb_copyarea = nvidiafb_copyarea; ^ >> drivers/video/fbdev/nvidia/nvidia.c:666:24: error: assignment of member >> 'fb_sync' in read-only object info->fbops->fb_sync = nvidiafb_sync; ^ drivers/video/fbdev/nvidia/nvidia.c:672:29: error: assignment of member 'fb_imageblit' in read-only object info->fbops->fb_imageblit = cfb_imageblit; ^ drivers/video/fbdev/nvidia/nvidia.c:673:28: error: assignment of member 'fb_fillrect' in read-only object info->fbops->fb_fillrect = cfb_fillrect; ^ drivers/video/fbdev/nvidia/nvidia.c:674:28: error: assignment of member 'fb_copyarea' in read-only object info->fbops->fb_copyarea = cfb_copyarea; ^ drivers/video/fbdev/nvidia/nvidia.c:675:24: error: assignment of member 'fb_sync' in read-only object info->fbops->fb_sync = NULL; ^ drivers/video/fbdev/nvidia/nvidia.c: In function 'nvidia_set_fbinfo': >> drivers/video/fbdev/nvidia/nvidia.c:1168:29: error: assignment of member >> 'fb_cursor' in read-only object info->fbops->fb_cursor = NULL; ^ vim +/fb_blank +1443 drivers/video/fbdev/uvesafb.c 8bdb3a2d7df48b drivers/video/uvesafb.c Michal Januszewski 2007-10-16 1427 48c68c4f1b5424 drivers/video/uvesafb.c Greg Kroah-Hartman 2012-12-21 1428 static void uvesafb_init_info(struct fb_info *in
Re: [PATCH 13/13] samples: vfio-mdev: constify fb ops
On Wed, 27 Nov 2019, Daniel Vetter wrote:
> On Wed, Nov 27, 2019 at 06:32:09PM +0200, Jani Nikula wrote:
>> Now that the fbops member of struct fb_info is const, we can star making
>> the ops const as well.
>>
>> Cc: Kirti Wankhede
>> Cc: k...@vger.kernel.org
>> Signed-off-by: Jani Nikula
>
> You've missed at least drivers/staging/fbtft in your search. I guess you
> need to do a full make allyesconfig on x86/arm and arm64 (the latter
> because some stupid drivers only compile there, not on arm, don't ask).
> Still misses a pile of mips/ppc only stuff and maybe the sparcs and
> alphas, but should be good enough.
fbtft dynamically allocates the fbops, for whatever reason. There were
others like that too. Some of the drivers modify the fbops runtime to
choose different hooks for different configurations. Can't change them
all anyway.
Facilitating making the fbops const is one thing (patches 1-8), but I'm
not really sure I want to sign up for exhaustively moving fbops to
rodata on anything beyond drivers/gpu/drm. It's not like I leave stuff
broken. Besides I am trying to cover all the low hanging fruit where I
can simply add the "const" and be done with it.
BR,
Jani.
>
> With that done, on the remaining patches:
>
> Reviewed-by: Daniel Vetter
>
>> ---
>> samples/vfio-mdev/mdpy-fb.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/samples/vfio-mdev/mdpy-fb.c b/samples/vfio-mdev/mdpy-fb.c
>> index 2719bb259653..21dbf63d6e41 100644
>> --- a/samples/vfio-mdev/mdpy-fb.c
>> +++ b/samples/vfio-mdev/mdpy-fb.c
>> @@ -86,7 +86,7 @@ static void mdpy_fb_destroy(struct fb_info *info)
>> iounmap(info->screen_base);
>> }
>>
>> -static struct fb_ops mdpy_fb_ops = {
>> +static const struct fb_ops mdpy_fb_ops = {
>> .owner = THIS_MODULE,
>> .fb_destroy = mdpy_fb_destroy,
>> .fb_setcolreg = mdpy_fb_setcolreg,
>> --
>> 2.20.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 01/13] video: fb_defio: preserve user fb_ops
On Wed, 27 Nov 2019, Daniel Vetter wrote:
> On Wed, Nov 27, 2019 at 07:17:41PM +0100, Daniel Vetter wrote:
>> On Wed, Nov 27, 2019 at 06:31:57PM +0200, Jani Nikula wrote:
>> > Modifying fb_ops directly to override fb_mmap with fb_deferred_io_mmap
>> > and then resetting it to NULL afterwards causes problems all over the
>> > place. First, it prevents making the fbops member of struct fb_info a
>> > const pointer, which means we can't make struct fb_ops const
>> > anywhere. Second, a few places have to go out of their way to restore
>> > the original fb_mmap pointer that gets reset to NULL.
>> >
>> > Preserve the passed in fb_ops by making a copy of it and modifying that
>> > instead. Add a deferred_io_private member to struct fb_info to store the
>> > pointer to the old fb_ops, and restore that at cleanup.
>> >
>> > Cc: Jaya Kumar
>> > Cc: linux-fb...@vger.kernel.org
>> > Signed-off-by: Jani Nikula
>> >
>> > ---
>> >
>> > Note: If the approach is acceptable, we'll also need to handle the error
>> > returns on memory allocation failures at fb_deferred_io_init() call
>> > sites. There are 13.
>>
>> it's fbdev defio, I think we can do worse with less effort. Just embed a
>> copy of fb_ops into fb_info, and use that, and tada! no memory allocation
>> needed :-)
>>
>> I'd totally r-b that patch.
>>
>> Or do what Ville suggested, add an fb_info->fbdefio.enabled, set that in
>> the _init function and in fb_mmap call fb_deferred_io_mmap for that case
>> instead of the driver's fb_ops->fb_mmap. There's only one caller of that
>> in the entire tree, in fbmem.c. Also, we could/should nuke the
>> EXPORT_SYMBOL(fb_deferred_io_mmap) I think.
>
> I just realized that fb_info->fbdefio is a pointer, so this would be
> really simple to pull off I think.
Heh, having a
int (*fb_deferred_io_mmap)(struct fb_info *, struct vm_area_struct *);
member in struct fb_info, and using that in fbmem.c if non-NULL, was
actually my first idea. I didn't think it was particularly pretty, but
if we don't care about aesthetics...
Would you like that instead of the patch at hand?
BR,
Jani.
> -Daniel
>
>>
>> That version would also get my r-b stamp. So up to you what you prefer.
>> -Daniel
>>
>> > ---
>> > drivers/video/fbdev/core/fb_defio.c | 25 ++---
>> > include/linux/fb.h | 3 ++-
>> > 2 files changed, 24 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/drivers/video/fbdev/core/fb_defio.c
>> > b/drivers/video/fbdev/core/fb_defio.c
>> > index 82c20c6047b0..36697844c1e0 100644
>> > --- a/drivers/video/fbdev/core/fb_defio.c
>> > +++ b/drivers/video/fbdev/core/fb_defio.c
>> > @@ -200,13 +200,23 @@ static void fb_deferred_io_work(struct work_struct
>> > *work)
>> >mutex_unlock(>lock);
>> > }
>> >
>> > -void fb_deferred_io_init(struct fb_info *info)
>> > +int fb_deferred_io_init(struct fb_info *info)
>> > {
>> >struct fb_deferred_io *fbdefio = info->fbdefio;
>> > + struct fb_ops *fbops;
>> >
>> >BUG_ON(!fbdefio);
>> > +
>> > + fbops = kmemdup(info->fbops, sizeof(*fbops), GFP_KERNEL);
>> > + if (!fbops)
>> > + return -ENOMEM;
>> > +
>> > + fbops->fb_mmap = fb_deferred_io_mmap;
>> > + info->deferred_io_private = info->fbops;
>> > + info->fbops = fbops;
>> > +
>> >mutex_init(>lock);
>> > - info->fbops->fb_mmap = fb_deferred_io_mmap;
>> > +
>> >INIT_DELAYED_WORK(>deferred_work, fb_deferred_io_work);
>> >INIT_LIST_HEAD(>pagelist);
>> >if (fbdefio->delay == 0) /* set a default of 1 s */
>> > @@ -229,6 +239,12 @@ void fb_deferred_io_cleanup(struct fb_info *info)
>> >int i;
>> >
>> >BUG_ON(!fbdefio);
>> > +
>> > + /* sanity check against misuse */
>> > + if (WARN_ON(!info->deferred_io_private ||
>> > + info->fbops->fb_mmap != fb_deferred_io_mmap))
>> > + return;
>> > +
>> >cancel_delayed_work_sync(>deferred_work);
>> >
>> >/* clear out the mapping that we setup */
>> > @@ -237,7 +253,10 @@ void fb_deferred_io_cleanup(struct fb_info *info)
>> >page->mapping = NULL;
>> >}
>> >
>> > - info->fbops->fb_mmap = NULL;
>> > + kfree(info->fbops);
>> > + info->fbops = info->deferred_io_private;
>> > + info->deferred_io_private = NULL;
>> > +
>> >mutex_destroy(>lock);
>> > }
>> > EXPORT_SYMBOL_GPL(fb_deferred_io_cleanup);
>> > diff --git a/include/linux/fb.h b/include/linux/fb.h
>> > index a6ad528990de..65f2abd47745 100644
>> > --- a/include/linux/fb.h
>> > +++ b/include/linux/fb.h
>> > @@ -470,6 +470,7 @@ struct fb_info {
>> > #ifdef CONFIG_FB_DEFERRED_IO
>> >struct delayed_work deferred_work;
>> >struct fb_deferred_io *fbdefio;
>> > + void *deferred_io_private;
>> > #endif
>> >
>> >struct fb_ops *fbops;
>> > @@ -658,7 +659,7 @@ static inline void __fb_pad_aligned_buffer(u8 *dst,
>> > u32 d_pitch,
>> >
>> > /* drivers/video/fb_defio.c */
>> > int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct *vma);
>> > -extern void
Re: [PATCH 24/30] drm/mcde: dsi: Use drm_bridge_init()
On Tue, Nov 26, 2019 at 2:16 PM Mihail Atanassov wrote: > No functional change. > > Signed-off-by: Mihail Atanassov Acked-by: Linus Walleij Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6] drm/panel: Add generic DSI display controller YAML bindings
This adds a starting point for processing and defining generic bindings used by DSI display controllers and panels attached to the virtual DSI ports. Cc: Stephan Gerhold Cc: devicet...@vger.kernel.org Suggested-by: Rob Herring Signed-off-by: Linus Walleij --- ChangeLog v5->v6: - Rename subject to pertain to DSI display controllers in general. - Change some of the wording in the DSI controller description text, making it clear that the binding pertains to the combination of a DSI controller with at least one panel attached. - Add a proper compiling example. ChangeLog v4->v5: - Drop the example. - I still have a vert annoying error message in the Sony panel bindings that uses this schema: sony,acx424akp.example.dt.yaml: panel@0: $nodename:0: 'panel@0' does not match '^dsi-controller(@.*)?$' As this is modeled very closely to Documentation/devicetree/bindings/net/mdio.yaml and that one doesn't emit this type of warning for its ethernet-phy@0 etc I am pretty much clueless and just can't see what the problem is. - If I can't figure this out the only viable next step is to drop the ambition to create yaml bindings simply because I'm unable to do it, and go back to traditional text bindings :( ChangeLog v3->v4: - Rename into display/dsi-controller.yaml - Require a virtual channel number for the DSI panel, as DSI have this 2-bit virtual address field. - Bring in some but not all properties from the existing MIPI DSI bindings. This schema can be used with simpler panels but not complex panels with multiple virtual channels for the moment. Let's handle it when we get there. - Add an example. ChangeLog v2->v3: - Make a more complete DSI panel binding including the controller and its address-cells and size-cells and a pattern for the panel nodes. The panel is one per DSI master, the reg property is compulsory but should always be 0 (as far as I can tell) as only one panel can be connected. The bus doesn't really have any addresses for the panel, the address/reg notation seems to be cargo-culted from the port graphs and is not necessary to parse some device trees, it is used to tell whether the node is a panel or not rather than any addressing. - I have no idea how many displays you can daisychain on a single DSI master, I just guess 15 will be enough. The MIPI-specs are memberwalled. Someone who knows can tell perhaps? ChangeLog v1->v2: - New patch after feedback. --- .../bindings/display/dsi-controller.yaml | 91 +++ 1 file changed, 91 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/dsi-controller.yaml diff --git a/Documentation/devicetree/bindings/display/dsi-controller.yaml b/Documentation/devicetree/bindings/display/dsi-controller.yaml new file mode 100644 index ..fd986c36c737 --- /dev/null +++ b/Documentation/devicetree/bindings/display/dsi-controller.yaml @@ -0,0 +1,91 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/dsi-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common Properties for DSI Display Panels + +maintainers: + - Linus Walleij + +description: | + This document defines device tree properties common to DSI, Display + Serial Interface controllers and attached panels. It doesn't constitute + a device tree binding specification by itself but is meant to be referenced + by device tree bindings. + + When referenced from panel device tree bindings the properties defined in + this document are defined as follows. The panel device tree bindings are + responsible for defining whether each property is required or optional. + + Notice: this binding concerns DSI panels connected directly to a master + without any intermediate port graph to the panel. Each DSI master + can control one to four virtual channels to one panel. Each virtual + channel should have a node "panel" for their virtual channel with their + reg-property set to the virtual channel number, usually there is just + one virtual channel, number 0. + +properties: + $nodename: +pattern: "^dsi-controller(@.*)?$" + + "#address-cells": +const: 1 + + "#size-cells": +const: 0 + +patternProperties: + "^panel@[0-3]$": +description: Panels connected to the DSI link +type: object + +properties: + reg: +minimum: 0 +maximum: 3 +description: + The virtual channel number of a DSI peripheral. Must be in the range + from 0 to 3, as DSI uses a 2-bit addressing scheme. Some DSI + peripherals respond to more than a single virtual channel. In that + case the reg property can take multiple entries, one for each virtual + channel that the peripheral responds to. + + clock-master: +type: boolean +description: + Should be enabled if the host is being used in conjunction with + another DSI host
Re: [PATCH 2/3] drm/hibmc: Use drm_gem_fb_create
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v5.4 next-20191127]
[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/Daniel-Vetter/drm-rockchip-Use-drm_gem_fb_create_with_dirty/20191128-023917
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: arm64-randconfig-a001-20191128 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 7.4.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
GCC_VERSION=7.4.0 make.cross ARCH=arm64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c: In function
'hibmc_plane_atomic_update':
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c:107:28: error: 'fb'
>> undeclared (first use in this function); did you mean 'mb'?
gbo = drm_gem_vram_of_gem(fb->obj[0]);
^~
mb
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c:107:28: note: each undeclared
identifier is reported only once for each function it appears in
--
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c: In function
'hibmc_drm_fb_create':
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c:119:37: error: 'struct
>> drm_framebuffer' has no member named 'fb'
hi_fbdev->helper.fb = _fbdev->fb->fb;
^~
vim +107 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
93
94 static void hibmc_plane_atomic_update(struct drm_plane *plane,
95struct drm_plane_state *old_state)
96 {
97 struct drm_plane_state *state = plane->state;
98 u32 reg;
99 s64 gpu_addr = 0;
100 unsigned int line_l;
101 struct hibmc_drm_private *priv = plane->dev->dev_private;
102 struct drm_gem_vram_object *gbo;
103
104 if (!state->fb)
105 return;
106
> 107 gbo = drm_gem_vram_of_gem(fb->obj[0]);
108
109 gpu_addr = drm_gem_vram_offset(gbo);
110 if (WARN_ON_ONCE(gpu_addr < 0))
111 return; /* Bug: we didn't pin the BO to VRAM in
prepare_fb. */
112
113 writel(gpu_addr, priv->mmio + HIBMC_CRT_FB_ADDRESS);
114
115 reg = state->fb->width * (state->fb->format->cpp[0]);
116 /* now line_pad is 16 */
117 reg = PADDING(16, reg);
118
119 line_l = state->fb->width * state->fb->format->cpp[0];
120 line_l = PADDING(16, line_l);
121 writel(HIBMC_FIELD(HIBMC_CRT_FB_WIDTH_WIDTH, reg) |
122 HIBMC_FIELD(HIBMC_CRT_FB_WIDTH_OFFS, line_l),
123 priv->mmio + HIBMC_CRT_FB_WIDTH);
124
125 /* SET PIXEL FORMAT */
126 reg = readl(priv->mmio + HIBMC_CRT_DISP_CTL);
127 reg &= ~HIBMC_CRT_DISP_CTL_FORMAT_MASK;
128 reg |= HIBMC_FIELD(HIBMC_CRT_DISP_CTL_FORMAT,
129 state->fb->format->cpp[0] * 8 / 16);
130 writel(reg, priv->mmio + HIBMC_CRT_DISP_CTL);
131 }
132
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [EXT] Re: [PATCH] drm: fix HDR static metadata type field numbering
On Wed, Nov 27, 2019 at 05:17:03PM +0200, Ville Syrjälä wrote:
> Caution: EXT Email
>
> On Wed, Nov 27, 2019 at 02:42:35PM +, Laurentiu Palcu wrote:
> > According to CTA-861 specification, HDR static metadata data block allows a
> > sink to indicate which HDR metadata types it supports by setting the SM_0 to
> > SM_7 bits. Currently, only Static Metadata Type 1 is supported and this is
> > indicated by setting the SM_0 bit to 1.
> >
> > However, the connector->hdr_sink_metadata.hdmi_type1.metadata_type is always
> > 0, because hdr_metadata_type() in drm_edid.c checks the wrong bit.
> >
> > This patch corrects the HDMI_STATIC_METADATA_TYPE1 bit position.
>
> Was confused for a while why this has even been workning, but I guess
> that's due to userspace populating the metadata infoframe blob correctly
> even if we misreported the metadata types in the parsed EDID metadata
> blob.
>
> Hmm. Actually on further inspection this all seems to be dead code. The
> only thing we seem to use from the parsed EDID metadata stuff is
> eotf bitmask. We check that in drm_hdmi_infoframe_set_hdr_metadata()
> but we don't check the metadata type.
>
> Maybe we should just nuke this EDID parsing stuff entirely? Seems
> pretty much pointless.
I've been thinking about that but we may need the rest of the fields as
well, even though they're not currently used. I'm referring to sink's
min/max luminance data. Shouldn't we also check min/max cll, besides
eotf, to make sure the source does not pass higher/lower luminance
values, than the sink supports, for optimal content rendering?
However, CTA-861 is not very clear on how a sink should behave if
the CLL values exceed the allowed range... :/ Also, if the CLL range or
the FALL values passed in the DRM infoframe exceed the sink's advertised
min/max values, I guess the sink cannot go lower/higher than it can
anyway. In which case, we don't really need the rest of the HDR static
metadata block and nuking that part should be ok.
Thanks,
laurentiu
>
> >
> > Signed-off-by: Laurentiu Palcu
> > ---
> > include/linux/hdmi.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> > index 9918a6c..216e25e 100644
> > --- a/include/linux/hdmi.h
> > +++ b/include/linux/hdmi.h
> > @@ -155,7 +155,7 @@ enum hdmi_content_type {
> > };
> >
> > enum hdmi_metadata_type {
> > - HDMI_STATIC_METADATA_TYPE1 = 1,
> > + HDMI_STATIC_METADATA_TYPE1 = 0,
> > };
> >
> > enum hdmi_eotf {
> > --
> > 2.7.4
>
> --
> Ville Syrjälä
> Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/4] drm/rect: Bugfixes and selftests
On 11/22/19 6:56 PM, Ville Syrjala wrote: > From: Ville Syrjälä > > My earlier fixes for drm_rect + div-by-zero fix + some > selftests that Daniel requested. > > Cc: Maarten Lankhorst > Cc: Benjamin Gaignard > Cc: Daniel Vetter Thanks to have handle this. Reviewed-by: Benjamin Gaignard > > Ville Syrjälä (4): >drm/rect: Avoid division by zero >drm/rect: Keep the scaled clip bounded >drm/rect: Keep the clipped dst rectangle in place >drm/selftests: Add drm_rect selftests > > drivers/gpu/drm/drm_rect.c| 36 +-- > drivers/gpu/drm/selftests/Makefile| 3 +- > .../gpu/drm/selftests/drm_modeset_selftests.h | 4 + > .../drm/selftests/test-drm_modeset_common.h | 7 + > drivers/gpu/drm/selftests/test-drm_rect.c | 220 ++ > include/drm/drm_rect.h| 2 + > 6 files changed, 257 insertions(+), 15 deletions(-) > create mode 100644 drivers/gpu/drm/selftests/test-drm_rect.c > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] drm/arc: Yet another set of minor fixes
Hi David, Daniel! The following changes since commit 8082731830a0b95f7f7a63b78de67de446013c80: drm/vram: remove unused declaration (2019-11-27 07:51:49 +0100) are available in the Git repository at: g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2019.11.27 for you to fetch changes up to b2c68fb15a4c2e27f80353d3067dce30882a0972: DRM: ARC: PGU: add ARGB format to supported format list (2019-11-27 10:38:24 +0300) Clean-up and fixes for FourCC handling in ARC PGU. Eugeniy Paltsev (4): DRM: ARC: PGU: fix framebuffer format switching DRM: ARC: PGU: cleanup supported format list code DRM: ARC: PGU: replace unsupported by HW RGB888 format by XRGB888 DRM: ARC: PGU: add ARGB format to supported format list drivers/gpu/drm/arc/arcpgu_crtc.c | 36 ++-- drivers/gpu/drm/arc/arcpgu_regs.h | 2 +- 2 files changed, 19 insertions(+), 19 deletions(-) Thanks, Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] drm/amd/powerplay: Remove unneeded variable
zhengbin (5): drm/amd/powerplay: Remove unneeded variable 'result' in smu10_hwmgr.c drm/amd/powerplay: Remove unneeded variable 'result' in vega10_hwmgr.c drm/amd/powerplay: Remove unneeded variable 'ret' in smu7_hwmgr.c drm/amd/powerplay: Remove unneeded variable 'result' in vega12_hwmgr.c drm/amd/powerplay: Remove unneeded variable 'ret' in amdgpu_smu.c drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 8 +++- drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c | 3 +-- drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 4 +--- drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 3 +-- drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c | 4 +--- 5 files changed, 7 insertions(+), 15 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 3/7] drm: rcar-du: Add support for CMM
Hi Laurent,
On Thu, Nov 28, 2019 at 9:09 AM Laurent Pinchart
wrote:
> On Thu, Nov 28, 2019 at 08:56:14AM +0100, Geert Uytterhoeven wrote:
> > On Wed, Nov 13, 2019 at 11:04 AM Jacopo Mondi
> > wrote:
> > > Add a driver for the R-Car Display Unit Color Correction Module.
> > > In most of Gen3 SoCs, each DU output channel is provided with a CMM unit
> > > to perform image enhancement and color correction.
> > >
> > > Add support for CMM through a driver that supports configuration of
> > > the 1-dimensional LUT table. More advanced CMM features will be
> > > implemented on top of this initial one.
> > >
> > > Reviewed-by: Laurent Pinchart
> > > Reviewed-by: Kieran Bingham
> > > Signed-off-by: Jacopo Mondi
> >
> > > --- a/drivers/gpu/drm/rcar-du/Kconfig
> > > +++ b/drivers/gpu/drm/rcar-du/Kconfig
> > > @@ -5,6 +5,7 @@ config DRM_RCAR_DU
> > > depends on ARM || ARM64
> > > depends on ARCH_RENESAS || COMPILE_TEST
> > > imply DRM_RCAR_LVDS
> > > + imply DRM_RCAR_CMM
> > > select DRM_KMS_HELPER
> > > select DRM_KMS_CMA_HELPER
> > > select DRM_GEM_CMA_HELPER
> > > @@ -13,6 +14,13 @@ config DRM_RCAR_DU
> > > Choose this option if you have an R-Car chipset.
> > > If M is selected the module will be called rcar-du-drm.
> > >
> > > +config DRM_RCAR_CMM
> > > + tristate "R-Car DU Color Management Module (CMM) Support"
> > > + depends on DRM && OF
> > > + depends on DRM_RCAR_DU
> >
> > DRM_RCAR_DU already depends on DRM && OF, so the line above
> > can be removed.
>
> I've sent a pull request already. Can we address this on top ? Or is it
> worth a separate patch, should we wait until we have to touch this and
> then fix it in a "while at it" fashion ?
Sure. "while at it" is fine for me. It's not blocker.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm/amd/display: Remove unneeded semicolon in hdcp.c
Fixes coccicheck warning: drivers/gpu/drm/amd/display/modules/hdcp/hdcp.c:506:2-3: Unneeded semicolon Reported-by: Hulk Robot Signed-off-by: zhengbin --- drivers/gpu/drm/amd/display/modules/hdcp/hdcp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp.c b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp.c index cbb5e9c..8aa528e 100644 --- a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp.c +++ b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp.c @@ -503,7 +503,7 @@ enum mod_hdcp_operation_mode mod_hdcp_signal_type_to_operation_mode( break; default: break; - }; + } return mode; } -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Re: [PATCH v2 2/2] drm: bridge: adv7511: Add support for ADV7535
Hi Bogdan,
On 21.08.19 07:34, Togorean, Bogdan wrote:
> On Tue, 2019-08-20 at 10:53 +0200, Daniel Vetter wrote:
>> [External]
>>
>> On Mon, Aug 19, 2019 at 12:46:16PM +0200, Sam Ravnborg wrote:
>>> Hi Bogdan.
>>>
>> adv7533_detach_dsi(adv7511);
>> i2c_unregister_device(adv7511->i2c_cec);
>> if (adv7511->cec_clk)
>> @@ -1266,8 +1278,9 @@ static const struct i2c_device_id
>> adv7511_i2c_ids[] = {
>> { "adv7511", ADV7511 },
>> { "adv7511w", ADV7511 },
>> { "adv7513", ADV7511 },
>> -#ifdef CONFIG_DRM_I2C_ADV7533
>> +#ifdef CONFIG_DRM_I2C_ADV753x
>> { "adv7533", ADV7533 },
>> +{ "adv7535", ADV7535 },
>> #endif
>
> This ifdef may not be needed??
> If we did not get this type we will not look it up.
But if we have defined in DT adv7533/5 device but
CONFIG_DRM_I2C_ADV753x not selected probe will fail with ENODEV.
That
would be ok?
>>>
>>> What do we gain from this complexity in the end.
>>> Why not let the driver always support all variants.
>>>
>>> If this result in a simpler driver, and less choices in Kconfig
>>> then it is a win-win.
>>
>> Yeah in general we don't Kconfig within drivers in drm to disable
>> specific
>> code-paths. It's not worth the pain.
>
> Ack,
> Thank you for clarification. Will remove in V3.
Are you still working on this? Do you plan to send a v3?
I will soon lay my hands on a board with the ADV7535 and would like to
see this merged.
Also for patch 1/2, it seems you already have a R-b for v1 from Laurent,
but you didn't carry the tag to v2.
Thanks,
Frieder
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] drm/amd/display: Remove unneeded semicolon
zhengbin (4): drm/amd/display: Remove unneeded semicolon in bios_parser.c drm/amd/display: Remove unneeded semicolon in bios_parser2.c drm/amd/display: Remove unneeded semicolon in hdcp.c drm/amd/display: Remove unneeded semicolon in display_rq_dlg_calc_21.c drivers/gpu/drm/amd/display/dc/bios/bios_parser.c | 2 +- drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c| 2 +- drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c | 4 ++-- drivers/gpu/drm/amd/display/modules/hdcp/hdcp.c | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm: bridge: adv7511: Add support for ADV7535
On 27.11.19 15:22, Togorean, Bogdan wrote:
> Hi Frieder,
>
> I'm glad to find there are other persons interested in this driver and
> especially support for ADV7535. Unfortunately I had to put on hold the
> development due to other activities but I'll send V3 tomorrow.
Great to hear that. Thanks for your effort. I will try to test your v3
when I have received the new hardware and got it up and running.
>
> I also started work on HDCP support for this driver and hope to send
> soon a patch for that.
>
> Best regards,
> Bogdan
>
> On Wed, 2019-11-27 at 11:52 +, Schrempf Frieder wrote:
>> [External]
>>
>> Hi Bogdan,
>>
>> On 21.08.19 07:34, Togorean, Bogdan wrote:
>>> On Tue, 2019-08-20 at 10:53 +0200, Daniel Vetter wrote:
[External]
On Mon, Aug 19, 2019 at 12:46:16PM +0200, Sam Ravnborg wrote:
> Hi Bogdan.
>
adv7533_detach_dsi(adv7511);
i2c_unregister_device(adv7511->i2c_cec);
if (adv7511->cec_clk)
@@ -1266,8 +1278,9 @@ static const struct i2c_device_id
adv7511_i2c_ids[] = {
{ "adv7511", ADV7511 },
{ "adv7511w", ADV7511 },
{ "adv7513", ADV7511 },
-#ifdef CONFIG_DRM_I2C_ADV7533
+#ifdef CONFIG_DRM_I2C_ADV753x
{ "adv7533", ADV7533 },
+ { "adv7535", ADV7535 },
#endif
>>>
>>> This ifdef may not be needed??
>>> If we did not get this type we will not look it up.
>> But if we have defined in DT adv7533/5 device but
>> CONFIG_DRM_I2C_ADV753x not selected probe will fail with
>> ENODEV.
>> That
>> would be ok?
>
> What do we gain from this complexity in the end.
> Why not let the driver always support all variants.
>
> If this result in a simpler driver, and less choices in Kconfig
> then it is a win-win.
Yeah in general we don't Kconfig within drivers in drm to disable
specific
code-paths. It's not worth the pain.
>> >
>>> Ack,
>>> Thank you for clarification. Will remove in V3.
>>
>> Are you still working on this? Do you plan to send a v3?
>> I will soon lay my hands on a board with the ADV7535 and would like
>> to
>> see this merged.
>> Also for patch 1/2, it seems you already have a R-b for v1 from
>> Laurent,
>> but you didn't carry the tag to v2.
>>
>> Thanks,
>> Frieder
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] msm:disp:dpu1: add scaler support on SC7180 display
Add scaler support for display driver.
This patch has dependency on the below series
https://patchwork.kernel.org/patch/11260267/
Co-developed-by: Raviteja Tamatam
Signed-off-by: Raviteja Tamatam
Signed-off-by: Shubhashree Dhar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 21 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 3 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c| 4 +++-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h| 3 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 20 +---
5 files changed, 39 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 1f2ac6e..89df411 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -182,7 +182,7 @@
.maxvdeciexp = MAX_VERT_DECIMATION,
};
-#define _VIG_SBLK(num, sdma_pri) \
+#define _VIG_SBLK(num, sdma_pri, qseed_ver) \
{ \
.common = _sspp_common, \
.maxdwnscale = MAX_DOWNSCALE_RATIO, \
@@ -191,7 +191,7 @@
.src_blk = {.name = STRCAT("sspp_src_", num), \
.id = DPU_SSPP_SRC, .base = 0x00, .len = 0x150,}, \
.scaler_blk = {.name = STRCAT("sspp_scaler", num), \
- .id = DPU_SSPP_SCALER_QSEED3, \
+ .id = qseed_ver, \
.base = 0xa00, .len = 0xa0,}, \
.csc_blk = {.name = STRCAT("sspp_csc", num), \
.id = DPU_SSPP_CSC_10BIT, \
@@ -216,10 +216,14 @@
.virt_num_formats = ARRAY_SIZE(plane_formats), \
}
-static const struct dpu_sspp_sub_blks sdm845_vig_sblk_0 = _VIG_SBLK("0", 5);
-static const struct dpu_sspp_sub_blks sdm845_vig_sblk_1 = _VIG_SBLK("1", 6);
-static const struct dpu_sspp_sub_blks sdm845_vig_sblk_2 = _VIG_SBLK("2", 7);
-static const struct dpu_sspp_sub_blks sdm845_vig_sblk_3 = _VIG_SBLK("3", 8);
+static const struct dpu_sspp_sub_blks sdm845_vig_sblk_0 =
+ _VIG_SBLK("0", 5, DPU_SSPP_SCALER_QSEED3);
+static const struct dpu_sspp_sub_blks sdm845_vig_sblk_1 =
+ _VIG_SBLK("1", 6, DPU_SSPP_SCALER_QSEED3);
+static const struct dpu_sspp_sub_blks sdm845_vig_sblk_2 =
+ _VIG_SBLK("2", 7, DPU_SSPP_SCALER_QSEED3);
+static const struct dpu_sspp_sub_blks sdm845_vig_sblk_3 =
+ _VIG_SBLK("3", 8, DPU_SSPP_SCALER_QSEED3);
static const struct dpu_sspp_sub_blks sdm845_dma_sblk_0 = _DMA_SBLK("8", 1);
static const struct dpu_sspp_sub_blks sdm845_dma_sblk_1 = _DMA_SBLK("9", 2);
@@ -257,9 +261,12 @@
sdm845_dma_sblk_3, 13, SSPP_TYPE_DMA, DPU_CLK_CTRL_CURSOR1),
};
+static const struct dpu_sspp_sub_blks sc7180_vig_sblk_0 =
+ _VIG_SBLK("0", 4, DPU_SSPP_SCALER_QSEED4);
+
static struct dpu_sspp_cfg sc7180_sspp[] = {
SSPP_BLK("sspp_0", SSPP_VIG0, 0x4000, VIG_SC7180_MASK,
- sdm845_vig_sblk_0, 0, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG0),
+ sc7180_vig_sblk_0, 0, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG0),
SSPP_BLK("sspp_8", SSPP_DMA0, 0x24000, DMA_SDM845_MASK,
sdm845_dma_sblk_0, 1, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA0),
SSPP_BLK("sspp_9", SSPP_DMA1, 0x26000, DMA_SDM845_MASK,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index e7e731b..a5b124d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -94,6 +94,7 @@ enum {
* @DPU_SSPP_SRC Src and fetch part of the pipes,
* @DPU_SSPP_SCALER_QSEED2, QSEED2 algorithm support
* @DPU_SSPP_SCALER_QSEED3, QSEED3 alogorithm support
+ * @DPU_SSPP_SCALER_QSEED4, QSEED4 algorithm support
* @DPU_SSPP_SCALER_RGB, RGB Scaler, supported by RGB pipes
* @DPU_SSPP_CSC,Support of Color space converion
* @DPU_SSPP_CSC_10BIT, Support of 10-bit Color space conversion
@@ -324,6 +325,7 @@ struct dpu_sspp_blks_common {
* @maxupscale: maxupscale ratio supported
* @smart_dma_priority: hw priority of rect1 of multirect pipe
* @max_per_pipe_bw: maximum allowable bandwidth of this pipe in kBps
+ * @qseed_ver: qseed version
* @src_blk:
* @scaler_blk:
* @csc_blk:
@@ -344,6 +346,7 @@ struct dpu_sspp_sub_blks {
u32 maxupscale;
u32 smart_dma_priority;
u32 max_per_pipe_bw;
+ u32 qseed_ver;
struct dpu_src_blk src_blk;
struct dpu_scaler_blk scaler_blk;
struct dpu_pp_blk csc_blk;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
index 4f8b813..a8e30de 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
@@ -132,6 +132,7 @@
/* traffic shaper clock in Hz */
#define TS_CLK 1920
+
static int _sspp_subblk_offset(struct dpu_hw_pipe *ctx,
[PATCH 5/5] drm/amd/powerplay: Remove unneeded variable 'ret' in amdgpu_smu.c
Fixes coccicheck warning:
drivers/gpu/drm/amd/powerplay/amdgpu_smu.c:1192:5-8: Unneeded variable: "ret".
Return "0" on line 1195
drivers/gpu/drm/amd/powerplay/amdgpu_smu.c:1945:5-8: Unneeded variable: "ret".
Return "0" on line 1961
Reported-by: Hulk Robot
Signed-off-by: zhengbin
---
drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
index 36001a4..98691d4 100644
--- a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
@@ -1189,10 +1189,9 @@ static int smu_free_memory_pool(struct smu_context *smu)
{
struct smu_table_context *smu_table = >smu_table;
struct smu_table *memory_pool = _table->memory_pool;
- int ret = 0;
if (memory_pool->size == SMU_MEMORY_POOL_SIZE_ZERO)
- return ret;
+ return 0;
amdgpu_bo_free_kernel(_pool->bo,
_pool->mc_address,
@@ -1200,7 +1199,7 @@ static int smu_free_memory_pool(struct smu_context *smu)
memset(memory_pool, 0, sizeof(struct smu_table));
- return ret;
+ return 0;
}
static int smu_start_smc_engine(struct smu_context *smu)
@@ -1942,7 +1941,6 @@ int smu_write_watermarks_table(struct smu_context *smu)
int smu_set_watermarks_for_clock_ranges(struct smu_context *smu,
struct dm_pp_wm_sets_with_clock_ranges_soc15 *clock_ranges)
{
- int ret = 0;
struct smu_table *watermarks =
>smu_table.tables[SMU_TABLE_WATERMARKS];
void *table = watermarks->cpu_addr;
@@ -1958,7 +1956,7 @@ int smu_set_watermarks_for_clock_ranges(struct
smu_context *smu,
mutex_unlock(>mutex);
- return ret;
+ return 0;
}
const struct amd_ip_funcs smu_ip_funcs = {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm/amd/powerplay: Remove unneeded variable 'result' in vega10_hwmgr.c
Fixes coccicheck warning:
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c:4363:5-11: Unneeded
variable: "result". Return "0" on line 4370
Reported-by: Hulk Robot
Signed-off-by: zhengbin
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
index b29e996..4685193 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
@@ -4360,14 +4360,13 @@ static int
vega10_set_watermarks_for_clocks_ranges(struct pp_hwmgr *hwmgr,
struct vega10_hwmgr *data = hwmgr->backend;
struct dm_pp_wm_sets_with_clock_ranges_soc15 *wm_with_clock_ranges =
clock_range;
Watermarks_t *table = &(data->smc_state_table.water_marks_table);
- int result = 0;
if (!data->registry_data.disable_water_mark) {
smu_set_watermarks_for_clocks_ranges(table,
wm_with_clock_ranges);
data->water_marks_bitmap = WaterMarksExist;
}
- return result;
+ return 0;
}
static int vega10_get_ppfeature_status(struct pp_hwmgr *hwmgr, char *buf)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/amd/display: Remove unneeded semicolon in display_rq_dlg_calc_21.c
Fixes coccicheck warning: drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c:1525:144-145: Unneeded semicolon drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c:1526:142-143: Unneeded semicolon Reported-by: Hulk Robot Signed-off-by: zhengbin --- drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c b/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c index a4b103e..e60af38 100644 --- a/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c @@ -1522,8 +1522,8 @@ static void dml_rq_dlg_get_dlg_params( disp_dlg_regs->refcyc_per_vm_group_vblank = get_refcyc_per_vm_group_vblank(mode_lib, e2e_pipe_param, num_pipes, pipe_idx) * refclk_freq_in_mhz; disp_dlg_regs->refcyc_per_vm_group_flip = get_refcyc_per_vm_group_flip(mode_lib, e2e_pipe_param, num_pipes, pipe_idx) * refclk_freq_in_mhz; - disp_dlg_regs->refcyc_per_vm_req_vblank = get_refcyc_per_vm_req_vblank(mode_lib, e2e_pipe_param, num_pipes, pipe_idx) * refclk_freq_in_mhz;; - disp_dlg_regs->refcyc_per_vm_req_flip = get_refcyc_per_vm_req_flip(mode_lib, e2e_pipe_param, num_pipes, pipe_idx) * refclk_freq_in_mhz;; + disp_dlg_regs->refcyc_per_vm_req_vblank = get_refcyc_per_vm_req_vblank(mode_lib, e2e_pipe_param, num_pipes, pipe_idx) * refclk_freq_in_mhz; + disp_dlg_regs->refcyc_per_vm_req_flip = get_refcyc_per_vm_req_flip(mode_lib, e2e_pipe_param, num_pipes, pipe_idx) * refclk_freq_in_mhz; // Clamp to max for now if (disp_dlg_regs->refcyc_per_vm_group_vblank >= (unsigned int)dml_pow(2, 23)) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] msm:disp:dpu1: Fix core clk rate in display driver
Fix max core clk rate during dt parsing in display driver. Signed-off-by: Shubhashree Dhar --- drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c index 27fbeb5..991fff1 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c @@ -187,6 +187,7 @@ int msm_dss_parse_clock(struct platform_device *pdev, continue; mp->clk_config[i].rate = rate; mp->clk_config[i].type = DSS_CLK_PCLK; + mp->clk_config[i].max_rate = rate; } mp->num_clk = num_clk; -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/amd/powerplay: Remove unneeded variable 'ret' in smu7_hwmgr.c
Fixes coccicheck warning:
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:5188:5-8: Unneeded variable:
"ret". Return "0" on line 5196
Reported-by: Hulk Robot
Signed-off-by: zhengbin
---
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
index c3f5866..d70abad 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
@@ -5185,13 +5185,11 @@ uint8_t smu7_get_sleep_divider_id_from_clock(uint32_t
clock,
int smu7_init_function_pointers(struct pp_hwmgr *hwmgr)
{
- int ret = 0;
-
hwmgr->hwmgr_func = _hwmgr_funcs;
if (hwmgr->pp_table_version == PP_TABLE_V0)
hwmgr->pptable_func = _funcs;
else if (hwmgr->pp_table_version == PP_TABLE_V1)
hwmgr->pptable_func = _v1_0_funcs;
- return ret;
+ return 0;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [GIT PULL] drm/arc: Yet another set of minor fixes
Hi Daniel, > -Original Message- > From: Daniel Vetter > Sent: Wednesday, November 27, 2019 1:07 PM > To: Alexey Brodkin > Cc: Daniel Vetter ; David Airlie ; arcml > a...@lists.infradead.org>; Eugeniy Paltsev ; > dri-devel@lists.freedesktop.org > Subject: Re: [GIT PULL] drm/arc: Yet another set of minor fixes > > On Wed, Nov 27, 2019 at 07:48:04AM +, Alexey Brodkin wrote: > > Hi David, Daniel! > > > > The following changes since commit 8082731830a0b95f7f7a63b78de67de446013c80: > > > > drm/vram: remove unused declaration (2019-11-27 07:51:49 +0100) > > > > are available in the Git repository at: > > > > g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2019.11.27 > > > > for you to fetch changes up to b2c68fb15a4c2e27f80353d3067dce30882a0972: > > > > DRM: ARC: PGU: add ARGB format to supported format list (2019-11-27 > > 10:38:24 +0300) > > > > > > Clean-up and fixes for FourCC handling in ARC PGU. > > > > > > Eugeniy Paltsev (4): > > DRM: ARC: PGU: fix framebuffer format switching > > DRM: ARC: PGU: cleanup supported format list code > > DRM: ARC: PGU: replace unsupported by HW RGB888 format by XRGB888 > > DRM: ARC: PGU: add ARGB format to supported format list > > Uh, this seems to be based on some random snapshot of drm-misc-next, so > contains a _lot_ more than just these 4 patches (compared to drm-next). Indeed it's based off of today's "drm-misc-next". That's because I still get lost when I have to deal with DRM trees which we have a plenty. I guess there should be a clean explanation of which repo and branch should be used for which purpose, right? May I have a reference to it then? > If you want to move arcpgu to drm-misc (which would make tons of sense imo) Could you please elaborate a bit on this? Given we have a couple a patches if at all for each kernel release I'd prefer to escape a need to use yet another repo, tools etc as this doesn't simplify anything but instead makes simple things much more complex (if done rarely). > then: > - create a MAINTAINER patch to add drm-misc as the git repo for it > - request your account for drm-misc, see > https://www.freedesktop.org/wiki/AccountRequests/ > - and set up the scripts > https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html Thanks for the pointers > Or respin this one, but these small pulls have a habit of occasionally > getting lost :-/ Well I'd better re-spin this, see below. The following changes since commit acc61b8929365e63a3e8c8c8913177795aa45594: Merge tag 'drm-next-5.5-2019-11-22' of git://people.freedesktop.org/~agd5f/linux into drm-next (2019-11-26 08:40:23 +1000) are available in the Git repository at: g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2019.11.27 for you to fetch changes up to 9c2acc26c899aa12ad009dff10a5573ef769a7fd: DRM: ARC: PGU: add ARGB format to supported format list (2019-11-27 16:43:39 +0300) Clean-up and fixes for FourCC handling in ARC PGU. Eugeniy Paltsev (4): DRM: ARC: PGU: fix framebuffer format switching DRM: ARC: PGU: cleanup supported format list code DRM: ARC: PGU: replace unsupported by HW RGB888 format by XRGB888 DRM: ARC: PGU: add ARGB format to supported format list drivers/gpu/drm/arc/arcpgu_crtc.c | 36 ++-- drivers/gpu/drm/arc/arcpgu_regs.h | 2 +- 2 files changed, 19 insertions(+), 19 deletions(-) -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm/bridge/synopsys: dsi: read status error during transfer
Hi Yannick,
Could you please share why you are adding this retry?
Are you trying to solve an issue with the generic interface buffs/fifos
overflow?
I think that it could be nice read the CMD_PKT_STATUS register to ensure
that buffs/fifos are not full or empty before a read or write.
> From: Yannick Fertre
> Date: Wed, Nov 27, 2019 at 10:23:13
>
> From: Yannick Fertré
>
> Read the DSI_INT_ST1 status register to check if
> errors occur while reading/writing a command to panel.
> In case of error, the transfer is retried 3 times.
>
> Signed-off-by: Yannick Fertre
> ---
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 99
> +++
> 1 file changed, 85 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index b6e793b..cc806ba 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -212,6 +212,20 @@
>
> #define DSI_INT_ST0 0xbc
> #define DSI_INT_ST1 0xc0
> +#define GPRXEBIT(12)
> +#define GPRDEBIT(11)
> +#define GPTXEBIT(10)
> +#define GPWREBIT(9)
> +#define GCWREBIT(8)
> +#define DPIPLDWE BIT(7)
> +#define EOTPEBIT(6)
> +#define PSE BIT(5)
> +#define CRCE BIT(4)
> +#define ECCMEBIT(3)
> +#define ECCSEBIT(2)
> +#define TOLPRX BIT(1)
> +#define TOHSTX BIT(0)
> +
> #define DSI_INT_MSK0 0xc4
> #define DSI_INT_MSK1 0xc8
>
> @@ -397,6 +411,42 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct
> dw_mipi_dsi *dsi, u32 hdr_val)
> return 0;
> }
>
> +static int dw_mipi_dsi_read_status(struct dw_mipi_dsi *dsi)
> +{
> + u32 val;
> +
> + val = dsi_read(dsi, DSI_INT_ST1);
> +
> + if (val & GPRXE)
> + DRM_DEBUG_DRIVER("DSI Generic payload receive error\n");
> + if (val & GPRDE)
> + DRM_DEBUG_DRIVER("DSI Generic payload read error\n");
> + if (val & GPTXE)
> + DRM_DEBUG_DRIVER("DSI Generic payload transmit error\n");
> + if (val & GPWRE)
> + DRM_DEBUG_DRIVER("DSI Generic payload write error\n");
> + if (val & GCWRE)
> + DRM_DEBUG_DRIVER("DSI Generic command write error\n");
> + if (val & DPIPLDWE)
> + DRM_DEBUG_DRIVER("DSI DPI payload write error\n");
> + if (val & EOTPE)
> + DRM_DEBUG_DRIVER("DSI EoTp error\n");
> + if (val & PSE)
> + DRM_DEBUG_DRIVER("DSI Packet size error\n");
> + if (val & CRCE)
> + DRM_DEBUG_DRIVER("DSI CRC error\n");
> + if (val & ECCME)
> + DRM_DEBUG_DRIVER("DSI ECC multi-bit error\n");
> + if (val & ECCSE)
> + DRM_DEBUG_DRIVER("DSI ECC single-bit error\n");
> + if (val & TOLPRX)
> + DRM_DEBUG_DRIVER("DSI Timeout low-power reception\n");
> + if (val & TOHSTX)
> + DRM_DEBUG_DRIVER("DSI Timeout high-speed transmission\n");
> +
> + return val;
> +}
> +
> static int dw_mipi_dsi_write(struct dw_mipi_dsi *dsi,
>const struct mipi_dsi_packet *packet)
> {
> @@ -426,6 +476,12 @@ static int dw_mipi_dsi_write(struct dw_mipi_dsi *dsi,
> "failed to get available write payload FIFO\n");
> return ret;
> }
> +
> + val = dw_mipi_dsi_read_status(dsi);
> + if (val) {
> + dev_err(dsi->dev, "dsi status error 0x%0x\n", val);
> + return -EINVAL;
> + }
> }
>
> word = 0;
> @@ -459,6 +515,12 @@ static int dw_mipi_dsi_read(struct dw_mipi_dsi *dsi,
> return ret;
> }
>
> + val = dw_mipi_dsi_read_status(dsi);
> + if (val) {
> + dev_err(dsi->dev, "dsi status error 0x%0x\n", val);
> + return -EINVAL;
> + }
> +
> val = dsi_read(dsi, DSI_GEN_PLD_DATA);
> for (j = 0; j < 4 && j + i < len; j++)
> buf[i + j] = val >> (8 * j);
> @@ -473,6 +535,7 @@ static ssize_t dw_mipi_dsi_host_transfer(struct
> mipi_dsi_host *host,
> struct dw_mipi_dsi *dsi = host_to_dsi(host);
> struct mipi_dsi_packet packet;
> int ret, nb_bytes;
> + int retry = 3;
>
> ret = mipi_dsi_create_packet(, msg);
> if (ret) {
> @@ -484,24 +547,32 @@ static ssize_t dw_mipi_dsi_host_transfer(struct
> mipi_dsi_host *host,
> if (dsi->slave)
> dw_mipi_message_config(dsi->slave, msg);
>
> - ret =
RE: [GIT PULL] drm/arc: Minor improvements
Hi all, As Jose suggested I'm adding "drm-misc" maintainers as that tree might be a better fit for ARC PGU patches. -Alexey > -Original Message- > From: linux-snps-arc On Behalf > Of Alexey Brodkin > Sent: Wednesday, November 27, 2019 10:25 AM > To: Daniel Vetter ; David Airlie > Cc: arcml ; Eugeniy Paltsev > ; dri- > de...@lists.freedesktop.org > Subject: RE: [GIT PULL] drm/arc: Minor improvements > > Hi Daniel, David! > > Any chance for this one to be processed sometime soon? > It's been quite some time since July when I initially sent > this pull-request. > > -Alexey > > > -Original Message- > > From: linux-snps-arc On Behalf > > Of Alexey Brodkin > > Sent: Wednesday, November 13, 2019 2:30 PM > > To: Daniel Vetter ; David Airlie > > Cc: arcml ; Eugeniy Paltsev > > ; dri- > > de...@lists.freedesktop.org > > Subject: RE: [GIT PULL] drm/arc: Minor improvements > > > > Hi Daniel, David, > > > > > -Original Message- > > > From: linux-snps-arc On > > > Behalf Of Alexey Brodkin > > > Sent: Thursday, July 18, 2019 12:09 AM > > > To: Daniel Vetter ; David Airlie > > > Cc: arcml ; > > > dri-devel@lists.freedesktop.org > > > Subject: [GIT PULL] drm/arc: Minor improvements > > > > > > Hi Dave, Daniel, > > > > > > The following changes since commit > > > 7aaddd96d5febcf5b24357a326b3038d49a20532: > > > > > > drm/modes: Don't apply cmdline's rotation if it wasn't specified > > > (2019-07-16 10:34:38 +0200) > > > > > > are available in the Git repository at: > > > > > > g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2019.07.18 > > > > > > for you to fetch changes up to cee17a71656e9e1b5ffc01767844026550d5f4a9: > > > > > > drm/arcpgu: rework encoder search (2019-07-17 23:36:56 +0300) > > > > > > > > > This is a pretty simple improvement that allows to find encoder > > > as the one and only (ARC PGU doesn't support more than one) endpoint > > > instead of using non-standard "encoder-slave" property. > > > > > > > > > Eugeniy Paltsev (1): > > > drm/arcpgu: rework encoder search > > > > > > drivers/gpu/drm/arc/arcpgu_drv.c | 16 +--- > > > 1 file changed, 13 insertions(+), 3 deletions(-) > > > > Any chance for this one to get pulled into your tree(s) sometime soon? > > > > -Alexey > > > > ___ > > linux-snps-arc mailing list > > linux-snps-...@lists.infradead.org > > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_linux- > 2Dsnps- > > > 2Darc=DwICAg=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=f3bFSjs3gZI9vC > > LJW5sa6Kxu43yXUsCXhaUNhtEymmk=eFO6mnw8IJyfrQZYrMEbJ-bryplfw9LvcYBSCEyj5XA= > > ___ > linux-snps-arc mailing list > linux-snps-...@lists.infradead.org > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_linux-2Dsnps- > 2Darc=DwICAg=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=c8DhCL8_- > 0iY2tS35o8kpDyvbHZ_Cu762s4qtn2hDVg=sGFaDT7yPIbVcjW49E_rjb6ND82Nrq0kplYjbztlh3A= ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
