Re: Ack to merge through DRM? WAS [PATCH v6 0/9] Huge page-table entries for TTM
On Thu, 19 Mar 2020 11:20:44 +0100 Thomas Hellström (VMware) wrote: > On 3/19/20 12:27 AM, Andrew Morton wrote: > > On Mon, 16 Mar 2020 13:32:08 +0100 Thomas Hellström (VMware) > > wrote: > > > >>> ___ > >>> dri-devel mailing list > >>> dri-devel@lists.freedesktop.org > >>> https://lists.freedesktop.org/mailman/listinfo/dri-devel > >> Andrew, would it be possible to have an ack for merge using a DRM tree > >> for the -mm patches? > > Yes, please do. It's all pretty straightforward addition of new > > functionality which won't affect existing code. > > Thanks Andrew. Can I add your Acked-by: To the mm patches for Linus' > reference? > Please do. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
On Fri, Mar 20, 2020 at 11:19 PM Bjorn Helgaas wrote:
>
> On Tue, Mar 10, 2020 at 08:26:27PM +0100, Karol Herbst wrote:
> > Fixes the infamous 'runtime PM' bug many users are facing on Laptops with
> > Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU.
> >
> > Depending on the used kernel there might be messages like those in demsg:
> >
> > "nouveau :01:00.0: Refused to change power state, currently in D3"
> > "nouveau :01:00.0: can't change power state from D3cold to D0 (config
> > space inaccessible)"
> > followed by backtraces of kernel crashes or timeouts within nouveau.
> >
> > It's still unkown why this issue exists, but this is a reliable workaround
> > and solves a very annoying issue for user having to choose between a
> > crashing kernel or higher power consumption of their Laptops.
>
> Thanks for the bugzilla link. The bugzilla mentions lots of mailing
> list discussion. Can you include links to some of that?
>
> IIUC this basically just turns off PCI power management for the GPU.
> Can you do that with something like the following? I don't know
> anything about DRM, so I don't know where you could save the pm_cap,
> but I'm sure the driver could keep it somewhere.
>
Sure this would work? From a quick look over the pci code, it looks
like a of code would be skipped we really need, like the platform code
to turn off the GPU via ACPI. But I could also remember incorrectly on
how all of that worked again. I can of course try and see what the
effect of this patch would be. And would the parent bus even go into
D3hot if it knows one of its children is still at D0? Because that's
what the result of that would be as well, no? And I know that if the
bus stays in D0, that it has a negative impact on power consumption.
Anyway, I will try that out, I am just not seeing how that would help.
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
> b/drivers/gpu/drm/nouveau/nouveau_drm.c
> index b65ae817eabf..2ad825e8891c 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> @@ -618,6 +618,23 @@ nouveau_drm_device_fini(struct drm_device *dev)
> kfree(drm);
> }
>
> +static void quirk_broken_nv_runpm(struct drm_device *drm_dev)
> +{
> + struct pci_dev *pdev = drm_dev->pdev;
> + struct pci_dev *bridge = pci_upstream_bridge(pdev);
> +
> + if (!bridge || bridge->vendor != PCI_VENDOR_ID_INTEL)
> + return;
> +
> + switch (bridge->device) {
> + case 0x1901:
> + STASH->pm_cap = pdev->pm_cap;
> + pdev->pm_cap = 0;
> + NV_INFO(drm_dev, "Disabling PCI power management to avoid
> bug\n");
> + break;
> + }
> +}
> +
> static int nouveau_drm_probe(struct pci_dev *pdev,
> const struct pci_device_id *pent)
> {
> @@ -699,6 +716,7 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
> if (ret)
> goto fail_drm_dev_init;
>
> + quirk_broken_nv_runpm(drm_dev);
> return 0;
>
> fail_drm_dev_init:
> @@ -735,6 +753,9 @@ nouveau_drm_remove(struct pci_dev *pdev)
> {
> struct drm_device *dev = pci_get_drvdata(pdev);
>
> + /* If we disabled PCI power management, restore it */
> + if (STASH->pm_cap)
> + pdev->pm_cap = STASH->pm_cap;
> nouveau_drm_device_remove(dev);
> pci_disable_device(pdev);
> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v12 3/5] clk / soc: mediatek: Move mt8173 MMSYS to platform driver
Quoting Enric Balletbo i Serra (2020-03-11 09:53:20) > From: Matthias Brugger > > There is no strong reason for this to use CLK_OF_DECLARE instead of > being a platform driver. Plus, MMSYS provides clocks but also a shared > register space for the mediatek-drm and the mediatek-mdp > driver. So move the MMSYS clocks to a new platform driver and also > create a new MMSYS platform driver in drivers/soc/mediatek that > instantiates the clock driver. > > Signed-off-by: Matthias Brugger > Signed-off-by: Enric Balletbo i Serra > Reviewed-by: CK Hu > --- Reviewed-by: Stephen Boyd Unless you want me to pick this up by itself? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v12 2/5] dt-bindings: mediatek: Update mmsys binding to reflect it is a system controller
Quoting Enric Balletbo i Serra (2020-03-11 09:53:19) > The mmsys system controller is not only a pure clock controller, so > update the binding documentation to reflect that apart from providing > clocks, it also provides routing and miscellaneous control registers. > > Signed-off-by: Enric Balletbo i Serra > Reviewed-by: Matthias Brugger > Reviewed-by: CK Hu > --- Reviewed-by: Stephen Boyd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] feature/staging_sm5
Dave, Daniel, vmwgfx pull for for 5.7. Needed for GL4 functionality. Sync up device headers, add support for new commands, code refactoring around surface definition. Preliminary mesa userspace code using these new vmwgfx features can be found at: https://gitlab.freedesktop.org/bhenden/mesa The following changes since commit dad569af718c4e603c35f59ed03bf0555633dd95: drm/vmwgfx: Refuse DMA operation when SEV encryption is active (2020-01-28 09:27:45 +0100) are available in the Git repository at: g...@gitlab.freedesktop.org:sroland/vmwgfx_drm.git feature/staging_sm5 for you to fetch changes up to 4526035058cc6cc09afbca3a5d86862438ae1edf: drm/vmwgfx: Use vmwgfx version 2.18 to signal SM5 compatibility (2020-03-20 23:35:53 +0100) Deepak Rawat (16): drm/vmwgfx: Also check for SVGA_CAP_DX before reading DX context support drm/vmwgfx: Sync legacy multisampling device capability drm/vmwgfx: Deprecate logic ops commands drm/vmwgfx: Use enum to represent graphics context capabilities drm/vmwgfx: Sync virtual device headers for new feature drm/vmwgfx: Add a new enum for SM5 graphics context capability drm/vmwgfx: Read new register for GB memory when available drm/vmwgfx: Support SM5 shader type in command buffer drm/vmwgfx: Add support for UA view commands drm/vmwgfx: Add support for indirect and dispatch commands drm/vmwgfx: Rename stream output target binding tracker struct drm/vmwgfx: Add support for streamoutput with mob commands drm/vmwgfx: Split surface metadata from struct vmw_surface drm/vmwgfx: Refactor surface_define to use vmw_surface_metadata drm/vmwgfx: Add surface define v4 command drm/vmwgfx: Add SM5 param for userspace Thomas Hellström (VMware) (1): drm/vmwgfx: Use vmwgfx version 2.18 to signal SM5 compatibility drivers/gpu/drm/vmwgfx/Makefile| 2 +- drivers/gpu/drm/vmwgfx/device_include/svga3d_cmd.h | 161 - .../gpu/drm/vmwgfx/device_include/svga3d_devcaps.h | 787 +++-- drivers/gpu/drm/vmwgfx/device_include/svga3d_dx.h | 466 +++- .../gpu/drm/vmwgfx/device_include/svga3d_limits.h | 36 +- .../drm/vmwgfx/device_include/svga3d_surfacedefs.h | 58 +- .../gpu/drm/vmwgfx/device_include/svga3d_types.h | 347 +++-- drivers/gpu/drm/vmwgfx/device_include/svga_reg.h | 382 +++--- drivers/gpu/drm/vmwgfx/device_include/svga_types.h | 1 + drivers/gpu/drm/vmwgfx/vmwgfx_binding.c| 213 +- drivers/gpu/drm/vmwgfx/vmwgfx_binding.h| 33 +- drivers/gpu/drm/vmwgfx/vmwgfx_context.c| 28 +- drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c| 6 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 59 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 152 +++- drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c| 429 ++- drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 18 +- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c| 43 +- drivers/gpu/drm/vmwgfx/vmwgfx_mob.c| 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_so.c | 12 +- drivers/gpu/drm/vmwgfx/vmwgfx_so.h | 7 + drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 61 +- drivers/gpu/drm/vmwgfx/vmwgfx_streamoutput.c | 387 ++ drivers/gpu/drm/vmwgfx/vmwgfx_surface.c| 608 include/uapi/drm/vmwgfx_drm.h | 16 +- 25 files changed, 3252 insertions(+), 1062 deletions(-) create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_streamoutput.c ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
On Tue, Mar 10, 2020 at 08:26:27PM +0100, Karol Herbst wrote:
> Fixes the infamous 'runtime PM' bug many users are facing on Laptops with
> Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU.
>
> Depending on the used kernel there might be messages like those in demsg:
>
> "nouveau :01:00.0: Refused to change power state, currently in D3"
> "nouveau :01:00.0: can't change power state from D3cold to D0 (config
> space inaccessible)"
> followed by backtraces of kernel crashes or timeouts within nouveau.
>
> It's still unkown why this issue exists, but this is a reliable workaround
> and solves a very annoying issue for user having to choose between a
> crashing kernel or higher power consumption of their Laptops.
Thanks for the bugzilla link. The bugzilla mentions lots of mailing
list discussion. Can you include links to some of that?
IIUC this basically just turns off PCI power management for the GPU.
Can you do that with something like the following? I don't know
anything about DRM, so I don't know where you could save the pm_cap,
but I'm sure the driver could keep it somewhere.
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index b65ae817eabf..2ad825e8891c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -618,6 +618,23 @@ nouveau_drm_device_fini(struct drm_device *dev)
kfree(drm);
}
+static void quirk_broken_nv_runpm(struct drm_device *drm_dev)
+{
+ struct pci_dev *pdev = drm_dev->pdev;
+ struct pci_dev *bridge = pci_upstream_bridge(pdev);
+
+ if (!bridge || bridge->vendor != PCI_VENDOR_ID_INTEL)
+ return;
+
+ switch (bridge->device) {
+ case 0x1901:
+ STASH->pm_cap = pdev->pm_cap;
+ pdev->pm_cap = 0;
+ NV_INFO(drm_dev, "Disabling PCI power management to avoid
bug\n");
+ break;
+ }
+}
+
static int nouveau_drm_probe(struct pci_dev *pdev,
const struct pci_device_id *pent)
{
@@ -699,6 +716,7 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
if (ret)
goto fail_drm_dev_init;
+ quirk_broken_nv_runpm(drm_dev);
return 0;
fail_drm_dev_init:
@@ -735,6 +753,9 @@ nouveau_drm_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
+ /* If we disabled PCI power management, restore it */
+ if (STASH->pm_cap)
+ pdev->pm_cap = STASH->pm_cap;
nouveau_drm_device_remove(dev);
pci_disable_device(pdev);
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206575] [amdgpu] [drm] No video signal on resume from suspend, R9 380
https://bugzilla.kernel.org/show_bug.cgi?id=206575 --- Comment #16 from Joe Ramsey (kernel_bugzi...@joeramsey.com) --- (In reply to Alex Deucher from comment #15) > (In reply to Joe Ramsey from comment #14) > > Looks like this has been corrected in 5.6... is there any intent to include > > the fix in any 5.5 kernel or will we just have to wait for 5.6? > > Can you identify the fix? If I understood Noel Maersk's and Thomas Frank's posts reverting 1ea8751bd28d1ec2b36a56ec6bc1ac28903d09b4 resolves the issue. The Reddit thread that was referenced (https://www.reddit.com/r/archlinux/comments/f7oti1/issue_with_resume_from_suspend_black_backlit/) seems to indicate that it's resolved in 5.6. Was wondering if whatever fix was applied to 5.6 would also be applied to 5.5. Could be I've completely misunderstood things. I'm running Slackware and have been using the -current kernel packages (currently at 5.4.25), but the kernel modules for virtualbox don't seem to be compiling under that kernel for some reason. I tried several of the recent 5.5 releases (5.5.8-5.5.10), and can get the virtualbox kernel modules to compile under them, but they all seem to have this bug. Was hoping to get one kernel that would allow my laptop to suspend and also compile the virtualbox modules. :^) -- 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 hmm 0/6] Small hmm_range_fault() cleanups
On 3/20/20 9:48 AM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
I've had these in my work queue for a bit, nothing profound here, just some
small edits for clarity.
Ralph's hmm tester will need a small diff to work after this - which
illustrates how setting default_flags == 0 is the same as what was called
SNAPSHOT:
diff --git a/lib/test_hmm.c b/lib/test_hmm.c
index 6ca953926dc13f..5f31f5b3e64cb9 100644
--- a/lib/test_hmm.c
+++ b/lib/test_hmm.c
@@ -300,7 +300,7 @@ static int dmirror_range_fault(struct dmirror *dmirror,
range->notifier_seq = mmu_interval_read_begin(range->notifier);
down_read(>mmap_sem);
- count = hmm_range_fault(range, 0);
+ count = hmm_range_fault(range);
up_read(>mmap_sem);
if (count <= 0) {
if (count == 0 || count == -EBUSY)
@@ -337,8 +337,7 @@ static int dmirror_fault(struct dmirror *dmirror, unsigned
long start,
.flags = dmirror_hmm_flags,
.values = dmirror_hmm_values,
.pfn_shift = DPT_SHIFT,
- .pfn_flags_mask = ~(dmirror_hmm_flags[HMM_PFN_VALID] |
- dmirror_hmm_flags[HMM_PFN_WRITE]),
+ .pfn_flags_mask = 0,
.default_flags = dmirror_hmm_flags[HMM_PFN_VALID] |
(write ? dmirror_hmm_flags[HMM_PFN_WRITE] : 0),
.dev_private_owner = dmirror->mdevice,
@@ -872,7 +871,7 @@ static int dmirror_range_snapshot(struct dmirror *dmirror,
range->notifier_seq = mmu_interval_read_begin(range->notifier);
down_read(>mmap_sem);
- count = hmm_range_fault(range, HMM_FAULT_SNAPSHOT);
+ count = hmm_range_fault(range);
up_read(>mmap_sem);
if (count <= 0) {
if (count == 0 || count == -EBUSY)
@@ -916,7 +915,7 @@ static int dmirror_snapshot(struct dmirror *dmirror,
.flags = dmirror_hmm_flags,
.values = dmirror_hmm_values,
.pfn_shift = DPT_SHIFT,
- .pfn_flags_mask = ~0ULL,
+ .pfn_flags_mask = 0,
.dev_private_owner = dmirror->mdevice,
};
int ret = 0;
Jason Gunthorpe (6):
mm/hmm: remove pgmap checking for devmap pages
mm/hmm: return the fault type from hmm_pte_need_fault()
mm/hmm: remove unused code and tidy comments
mm/hmm: remove HMM_FAULT_SNAPSHOT
mm/hmm: remove the CONFIG_TRANSPARENT_HUGEPAGE #ifdef
mm/hmm: use device_private_entry_to_pfn()
Documentation/vm/hmm.rst| 12 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_svm.c | 2 +-
include/linux/hmm.h | 55 +-
mm/hmm.c| 238 +---
5 files changed, 98 insertions(+), 211 deletions(-)
The series looks good to me so,
Reviewed-by: Ralph Campbell
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH hmm 3/6] mm/hmm: remove unused code and tidy comments
On 3/20/20 9:49 AM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
Delete several functions that are never called, fix some desync between
comments and structure content, remove an unused ret, and move one
function only used by hmm.c into hmm.c
Signed-off-by: Jason Gunthorpe
Reviewed-by: Ralph Campbell
---
include/linux/hmm.h | 50 -
mm/hmm.c| 12 +++
2 files changed, 12 insertions(+), 50 deletions(-)
diff --git a/include/linux/hmm.h b/include/linux/hmm.h
index bb6be4428633a8..184a8633260f9d 100644
--- a/include/linux/hmm.h
+++ b/include/linux/hmm.h
@@ -120,9 +120,6 @@ enum hmm_pfn_value_e {
*
* @notifier: a mmu_interval_notifier that includes the start/end
* @notifier_seq: result of mmu_interval_read_begin()
- * @hmm: the core HMM structure this range is active against
- * @vma: the vm area struct for the range
- * @list: all range lock are on a list
* @start: range virtual start address (inclusive)
* @end: range virtual end address (exclusive)
* @pfns: array of pfns (big enough for the range)
@@ -131,7 +128,6 @@ enum hmm_pfn_value_e {
* @default_flags: default flags for the range (write, read, ... see hmm doc)
* @pfn_flags_mask: allows to mask pfn flags so that only default_flags matter
* @pfn_shifts: pfn shift value (should be <= PAGE_SHIFT)
s/pfn_shifts/pfn_shift
- * @valid: pfns array did not change since it has been fill by an HMM function
* @dev_private_owner: owner of device private pages
*/
struct hmm_range {
@@ -171,52 +167,6 @@ static inline struct page *hmm_device_entry_to_page(const
struct hmm_range *rang
return pfn_to_page(entry >> range->pfn_shift);
}
-/*
- * hmm_device_entry_to_pfn() - return pfn value store in a device entry
- * @range: range use to decode device entry value
- * @entry: device entry to extract pfn from
- * Return: pfn value if device entry is valid, -1UL otherwise
- */
-static inline unsigned long
-hmm_device_entry_to_pfn(const struct hmm_range *range, uint64_t pfn)
-{
- if (pfn == range->values[HMM_PFN_NONE])
- return -1UL;
- if (pfn == range->values[HMM_PFN_ERROR])
- return -1UL;
- if (pfn == range->values[HMM_PFN_SPECIAL])
- return -1UL;
- if (!(pfn & range->flags[HMM_PFN_VALID]))
- return -1UL;
- return (pfn >> range->pfn_shift);
-}
-
-/*
- * hmm_device_entry_from_page() - create a valid device entry for a page
- * @range: range use to encode HMM pfn value
- * @page: page for which to create the device entry
- * Return: valid device entry for the page
- */
-static inline uint64_t hmm_device_entry_from_page(const struct hmm_range
*range,
- struct page *page)
-{
- return (page_to_pfn(page) << range->pfn_shift) |
- range->flags[HMM_PFN_VALID];
-}
-
-/*
- * hmm_device_entry_from_pfn() - create a valid device entry value from pfn
- * @range: range use to encode HMM pfn value
- * @pfn: pfn value for which to create the device entry
- * Return: valid device entry for the pfn
- */
-static inline uint64_t hmm_device_entry_from_pfn(const struct hmm_range *range,
-unsigned long pfn)
-{
- return (pfn << range->pfn_shift) |
- range->flags[HMM_PFN_VALID];
-}
-
/* Don't fault in missing PTEs, just snapshot the current state. */
#define HMM_FAULT_SNAPSHOT(1 << 1)
diff --git a/mm/hmm.c b/mm/hmm.c
index b4f662eadb7a7c..687d21c675ee60 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -37,6 +37,18 @@ enum {
NEED_WRITE_FAULT = 1 << 1,
};
+/*
+ * hmm_device_entry_from_pfn() - create a valid device entry value from pfn
+ * @range: range use to encode HMM pfn value
+ * @pfn: pfn value for which to create the device entry
+ * Return: valid device entry for the pfn
+ */
+static uint64_t hmm_device_entry_from_pfn(const struct hmm_range *range,
+ unsigned long pfn)
+{
+ return (pfn << range->pfn_shift) | range->flags[HMM_PFN_VALID];
+}
+
static int hmm_pfns_fill(unsigned long addr, unsigned long end,
struct hmm_range *range, enum hmm_pfn_value_e value)
{
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206895] [amdgpu] crash while using opencl from amdgpu-pro on kernel 5.5.10
https://bugzilla.kernel.org/show_bug.cgi?id=206895 --- Comment #2 from bigbeesh...@gmail.com --- Yes, should be able to over the weekend. Will report my findings. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206895] [amdgpu] crash while using opencl from amdgpu-pro on kernel 5.5.10
https://bugzilla.kernel.org/show_bug.cgi?id=206895 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) --- Can you bisect? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206575] [amdgpu] [drm] No video signal on resume from suspend, R9 380
https://bugzilla.kernel.org/show_bug.cgi?id=206575 --- Comment #15 from Alex Deucher (alexdeuc...@gmail.com) --- (In reply to Joe Ramsey from comment #14) > Looks like this has been corrected in 5.6... is there any intent to include > the fix in any 5.5 kernel or will we just have to wait for 5.6? Can you identify the fix? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206895] New: [amdgpu] crash while using opencl from amdgpu-pro on kernel 5.5.10
https://bugzilla.kernel.org/show_bug.cgi?id=206895 Bug ID: 206895 Summary: [amdgpu] crash while using opencl from amdgpu-pro on kernel 5.5.10 Product: Drivers Version: 2.5 Kernel Version: 5.5.10 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: bigbeesh...@gmail.com Regression: No Created attachment 287987 --> https://bugzilla.kernel.org/attachment.cgi?id=287987=edit crash log I have found that using the amdgpu-pro OpenCL stack with kernel 5.5.10 causes a crash (see attached log) I have seen this while using folding@home. I have tested reverting back to 5.4.26 with no other changes, this fixes the issue. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206575] [amdgpu] [drm] No video signal on resume from suspend, R9 380
https://bugzilla.kernel.org/show_bug.cgi?id=206575 Joe Ramsey (kernel_bugzi...@joeramsey.com) changed: What|Removed |Added CC||kernel_bugzilla@joeramsey.c ||om --- Comment #14 from Joe Ramsey (kernel_bugzi...@joeramsey.com) --- Looks like this has been corrected in 5.6... is there any intent to include the fix in any 5.5 kernel or will we just have to wait for 5.6? -- 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
[GIT PULL] etnaviv-next for 5.7
Hi Daniel, Dave, nothing too exciting this time, mostly making newer hardware more stable. - fix for potential out-of-bounds reads in the perfmon ioctl implementation from Christian - override to expose proper feature flags for the GC400 found on the STM32MP1 SoC, also from Christian - Guido fixed an issue where we would spuriously fail to enter runtime suspend due to a new GPU engine status bit on GC7000 - tree-wide change from Gustavo to get rid of zero-length arrays - fix for missed TS cache flush on GC7000, leading to spurious MMU faults from me - request pages from DMA32 zone on systems where we can't address all present memory from me Regards, Lucas The following changes since commit bb6d3fb354c5ee8d6bde2d576eb7220ea09862b9: Linux 5.6-rc1 (2020-02-09 16:08:48 -0800) are available in the Git repository at: https://git.pengutronix.de/git/lst/linux etnaviv/next for you to fetch changes up to f232d9ec029ce3e2543b05213e2979e01e503408: drm/etnaviv: fix TS cache flushing on GPUs with BLT engine (2020-03-20 18:40:44 +0100) Christian Gmeiner (7): drm/etnaviv: update hardware headers from rnndb drm/etnaviv: determine product, customer and eco id drm/etnaviv: show identity information in debugfs drm/etnaviv: update gc7000 chip identity entry drm/etnaviv: update hwdb selection logic drm/etnaviv: add hwdb entry for gc400 found in STM32 drm/etnaviv: rework perfmon query infrastructure Guido Günther (5): drm/etnaviv: Fix typo in comment drm/etnaviv: Update idle bits drm/etnaviv: Consider all kwnown idle bits in debugfs drm/etnaviv: Ignore MC when checking runtime suspend idleness drm/etnaviv: Warn when GPU doesn't idle fast enough Gustavo A. R. Silva (1): drm/etnaviv: Replace zero-length array with flexible-array member Lucas Stach (2): drm/etnaviv: request pages from DMA32 zone when needed drm/etnaviv: fix TS cache flushing on GPUs with BLT engine drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 60 +++- drivers/gpu/drm/etnaviv/etnaviv_drv.c | 1 + drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 + drivers/gpu/drm/etnaviv/etnaviv_gem.c | 4 ++-- drivers/gpu/drm/etnaviv/etnaviv_gem.h | 2 +- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 52 +++- drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 6 +++--- drivers/gpu/drm/etnaviv/etnaviv_hwdb.c| 42 +- drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 59 --- drivers/gpu/drm/etnaviv/state_blt.xml.h | 2 ++ drivers/gpu/drm/etnaviv/state_hi.xml.h| 36 +--- 11 files changed, 230 insertions(+), 35 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH hmm 0/6] Small hmm_range_fault() cleanups
On 3/20/20 9:48 AM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
I've had these in my work queue for a bit, nothing profound here, just some
small edits for clarity.
The hmm tester changes are clear enough but I'm having a bit of trouble
figuring out
what this series applies cleanly to since I'm trying to apply it on top of the
other patches you and Christoph have sent out.
Is there a private git tree/branch where everything is applied?
Ralph's hmm tester will need a small diff to work after this - which
illustrates how setting default_flags == 0 is the same as what was called
SNAPSHOT:
diff --git a/lib/test_hmm.c b/lib/test_hmm.c
index 6ca953926dc13f..5f31f5b3e64cb9 100644
--- a/lib/test_hmm.c
+++ b/lib/test_hmm.c
@@ -300,7 +300,7 @@ static int dmirror_range_fault(struct dmirror *dmirror,
range->notifier_seq = mmu_interval_read_begin(range->notifier);
down_read(>mmap_sem);
- count = hmm_range_fault(range, 0);
+ count = hmm_range_fault(range);
up_read(>mmap_sem);
if (count <= 0) {
if (count == 0 || count == -EBUSY)
@@ -337,8 +337,7 @@ static int dmirror_fault(struct dmirror *dmirror, unsigned
long start,
.flags = dmirror_hmm_flags,
.values = dmirror_hmm_values,
.pfn_shift = DPT_SHIFT,
- .pfn_flags_mask = ~(dmirror_hmm_flags[HMM_PFN_VALID] |
- dmirror_hmm_flags[HMM_PFN_WRITE]),
+ .pfn_flags_mask = 0,
.default_flags = dmirror_hmm_flags[HMM_PFN_VALID] |
(write ? dmirror_hmm_flags[HMM_PFN_WRITE] : 0),
.dev_private_owner = dmirror->mdevice,
@@ -872,7 +871,7 @@ static int dmirror_range_snapshot(struct dmirror *dmirror,
range->notifier_seq = mmu_interval_read_begin(range->notifier);
down_read(>mmap_sem);
- count = hmm_range_fault(range, HMM_FAULT_SNAPSHOT);
+ count = hmm_range_fault(range);
up_read(>mmap_sem);
if (count <= 0) {
if (count == 0 || count == -EBUSY)
@@ -916,7 +915,7 @@ static int dmirror_snapshot(struct dmirror *dmirror,
.flags = dmirror_hmm_flags,
.values = dmirror_hmm_values,
.pfn_shift = DPT_SHIFT,
- .pfn_flags_mask = ~0ULL,
+ .pfn_flags_mask = 0,
.dev_private_owner = dmirror->mdevice,
};
int ret = 0;
Jason Gunthorpe (6):
mm/hmm: remove pgmap checking for devmap pages
mm/hmm: return the fault type from hmm_pte_need_fault()
mm/hmm: remove unused code and tidy comments
mm/hmm: remove HMM_FAULT_SNAPSHOT
mm/hmm: remove the CONFIG_TRANSPARENT_HUGEPAGE #ifdef
mm/hmm: use device_private_entry_to_pfn()
Documentation/vm/hmm.rst| 12 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_svm.c | 2 +-
include/linux/hmm.h | 55 +-
mm/hmm.c| 238 +---
5 files changed, 98 insertions(+), 211 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 1/2] dt-bindings: display/bridge: Add binding for NWL mipi dsi host controller
The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs.
Signed-off-by: Guido Günther
Tested-by: Robert Chiras
Reviewed-by: Rob Herring
Acked-by: Sam Ravnborg
---
.../bindings/display/bridge/nwl-dsi.yaml | 216 ++
1 file changed, 216 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
new file mode 100644
index ..ec1e7e12719d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
@@ -0,0 +1,216 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/nwl-dsi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Northwest Logic MIPI-DSI controller on i.MX SoCs
+
+maintainers:
+ - Guido Gúnther
+ - Robert Chiras
+
+description: |
+ NWL MIPI-DSI host controller found on i.MX8 platforms. This is a dsi bridge
for
+ the SOCs NWL MIPI-DSI host controller.
+
+properties:
+ compatible:
+const: fsl,imx8mq-nwl-dsi
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ '#address-cells':
+const: 1
+
+ '#size-cells':
+const: 0
+
+ clocks:
+items:
+ - description: DSI core clock
+ - description: RX_ESC clock (used in escape mode)
+ - description: TX_ESC clock (used in escape mode)
+ - description: PHY_REF clock
+ - description: LCDIF clock
+
+ clock-names:
+items:
+ - const: core
+ - const: rx_esc
+ - const: tx_esc
+ - const: phy_ref
+ - const: lcdif
+
+ mux-controls:
+description:
+ mux controller node to use for operating the input mux
+
+ phys:
+maxItems: 1
+description:
+ A phandle to the phy module representing the DPHY
+
+ phy-names:
+items:
+ - const: dphy
+
+ power-domains:
+maxItems: 1
+
+ resets:
+items:
+ - description: dsi byte reset line
+ - description: dsi dpi reset line
+ - description: dsi esc reset line
+ - description: dsi pclk reset line
+
+ reset-names:
+items:
+ - const: byte
+ - const: dpi
+ - const: esc
+ - const: pclk
+
+ ports:
+type: object
+description:
+ A node containing DSI input & output port nodes with endpoint
+ definitions as documented in
+ Documentation/devicetree/bindings/graph.txt.
+properties:
+ port@0:
+type: object
+description:
+ Input port node to receive pixel data from the
+ display controller. Exactly one endpoint must be
+ specified.
+properties:
+ '#address-cells':
+const: 1
+
+ '#size-cells':
+const: 0
+
+ endpoint@0:
+description: sub-node describing the input from LCDIF
+type: object
+
+ endpoint@1:
+description: sub-node describing the input from DCSS
+type: object
+
+ reg:
+const: 0
+
+required:
+ - '#address-cells'
+ - '#size-cells'
+ - reg
+additionalProperties: false
+
+ port@1:
+type: object
+description:
+ DSI output port node to the panel or the next bridge
+ in the chain
+
+ '#address-cells':
+const: 1
+
+ '#size-cells':
+const: 0
+
+required:
+ - '#address-cells'
+ - '#size-cells'
+ - port@0
+ - port@1
+
+additionalProperties: false
+
+patternProperties:
+ "^panel@[0-9]+$":
+type: object
+
+required:
+ - '#address-cells'
+ - '#size-cells'
+ - clock-names
+ - clocks
+ - compatible
+ - interrupts
+ - mux-controls
+ - phy-names
+ - phys
+ - ports
+ - reg
+ - reset-names
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+
+ #include
+ #include
+ #include
+
+ mipi_dsi: mipi_dsi@30a0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,imx8mq-nwl-dsi";
+ reg = <0x30A0 0x300>;
+ clocks = < IMX8MQ_CLK_DSI_CORE>,
+ < IMX8MQ_CLK_DSI_AHB>,
+ < IMX8MQ_CLK_DSI_IPG_DIV>,
+ < IMX8MQ_CLK_DSI_PHY_REF>,
+ < IMX8MQ_CLK_LCDIF_PIXEL>;
+ clock-names = "core", "rx_esc", "tx_esc", "phy_ref", "lcdif";
+ interrupts = ;
+ mux-controls = < 0>;
+ power-domains = <_mipi>;
+ resets = < IMX8MQ_RESET_MIPI_DSI_RESET_BYTE_N>,
+ < IMX8MQ_RESET_MIPI_DSI_DPI_RESET_N>,
+ < IMX8MQ_RESET_MIPI_DSI_ESC_RESET_N>,
+ < IMX8MQ_RESET_MIPI_DSI_PCLK_RESET_N>;
+ reset-names = "byte", "dpi", "esc", "pclk";
+ phys = <>;
+ phy-names = "dphy";
+
+ panel@0
[PATCH v10 2/2] drm/bridge: Add NWL MIPI DSI host controller support
This adds initial support for the NWL MIPI DSI Host controller found on
i.MX8 SoCs.
It adds support for the i.MX8MQ but the same IP can be found on
e.g. the i.MX8QXP.
It has been tested on the Librem 5 devkit using mxsfb.
Signed-off-by: Guido Günther
Co-developed-by: Robert Chiras
Signed-off-by: Robert Chiras
Tested-by: Robert Chiras
Tested-by: Martin Kepplinger
---
drivers/gpu/drm/bridge/Kconfig | 16 +
drivers/gpu/drm/bridge/Makefile |1 +
drivers/gpu/drm/bridge/nwl-dsi.c | 1218 ++
drivers/gpu/drm/bridge/nwl-dsi.h | 144
4 files changed, 1379 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/nwl-dsi.c
create mode 100644 drivers/gpu/drm/bridge/nwl-dsi.h
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index aaed2347ace9..6ec945f837b8 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -58,6 +58,22 @@ config DRM_MEGACHIPS_STDP_GE_B850V3_FW
to DP++. This is used with the i.MX6 imx-ldb
driver. You are likely to say N here.
+config DRM_NWL_MIPI_DSI
+ tristate "Northwest Logic MIPI DSI Host controller"
+ depends on DRM
+ depends on COMMON_CLK
+ depends on OF && HAS_IOMEM
+ select DRM_KMS_HELPER
+ select DRM_MIPI_DSI
+ select DRM_PANEL_BRIDGE
+ select GENERIC_PHY_MIPI_DPHY
+ select MFD_SYSCON
+ select MULTIPLEXER
+ select REGMAP_MMIO
+ help
+ This enables the Northwest Logic MIPI DSI Host controller as
+ for example found on NXP's i.MX8 Processors.
+
config DRM_NXP_PTN3460
tristate "NXP PTN3460 DP/LVDS bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 6fb062b5b0f0..b04ac2dfa22c 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o
+obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi.o
obj-y += analogix/
obj-y += synopsys/
diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
new file mode 100644
index ..12d1c5548e2d
--- /dev/null
+++ b/drivers/gpu/drm/bridge/nwl-dsi.c
@@ -0,0 +1,1218 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * i.MX8 NWL MIPI DSI host driver
+ *
+ * Copyright (C) 2017 NXP
+ * Copyright (C) 2020 Purism SPC
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include "nwl-dsi.h"
+
+#define DRV_NAME "nwl-dsi"
+
+/* i.MX8 NWL quirks */
+/* i.MX8MQ errata E11418 */
+#define E11418_HS_MODE_QUIRK BIT(0)
+
+#define NWL_DSI_MIPI_FIFO_TIMEOUT msecs_to_jiffies(500)
+
+enum transfer_direction {
+ DSI_PACKET_SEND,
+ DSI_PACKET_RECEIVE,
+};
+
+#define NWL_DSI_ENDPOINT_LCDIF 0
+#define NWL_DSI_ENDPOINT_DCSS 1
+
+struct nwl_dsi_plat_clk_config {
+ const char *id;
+ struct clk *clk;
+ bool present;
+};
+
+struct nwl_dsi_transfer {
+ const struct mipi_dsi_msg *msg;
+ struct mipi_dsi_packet packet;
+ struct completion completed;
+
+ int status; /* status of transmission */
+ enum transfer_direction direction;
+ bool need_bta;
+ u8 cmd;
+ u16 rx_word_count;
+ size_t tx_len; /* in bytes */
+ size_t rx_len; /* in bytes */
+};
+
+struct nwl_dsi {
+ struct drm_bridge bridge;
+ struct mipi_dsi_host dsi_host;
+ struct drm_bridge *panel_bridge;
+ struct device *dev;
+ struct phy *phy;
+ union phy_configure_opts phy_cfg;
+ unsigned int quirks;
+
+ struct regmap *regmap;
+ int irq;
+ /*
+* The DSI host controller needs this reset sequence according to NWL:
+* 1. Deassert pclk reset to get access to DSI regs
+* 2. Configure DSI Host and DPHY and enable DPHY
+* 3. Deassert ESC and BYTE resets to allow host TX operations)
+* 4. Send DSI cmds to configure peripheral (handled by panel drv)
+* 5. Deassert DPI reset so DPI receives pixels and starts sending
+*DSI data
+*
+* TODO: Since panel_bridges do their DSI setup in enable we
+* currently have 4. and 5. swapped.
+*/
+ struct reset_control *rst_byte;
+ struct reset_control *rst_esc;
+ struct reset_control *rst_dpi;
+ struct reset_control *rst_pclk;
+ struct mux_control *mux;
+
+ /* DSI clocks */
+ struct clk *phy_ref_clk;
+ struct clk *rx_esc_clk;
+ struct clk *tx_esc_clk;
+ struct clk *core_clk;
+ /*
+* hardware bug: the i.MX8MQ needs this clock on during reset
+* even when
[PATCH v10 0/2] drm: bridge: Add NWL MIPI DSI host controller support
This adds initial support for the NWL MIPI DSI Host controller found on i.MX8
SoCs.
It adds support for the i.MX8MQ but the same IP core can also be found on e.g.
i.MX8QXP. I added the necessary hooks to support other imx8 variants but since
I only have imx8mq boards to test I omitted the platform data for other SoCs.
The code is based on NXPs BSP so I added Robert Chiras as Co-authored-by.
The most notable changes over the BSP driver are
- Calculate HS mode timing from phy_configure_opts_mipi_dphy
- Perform all clock setup via DT
- Merge nwl-imx and nwl drivers
- Add B0 silion revision quirk
- become a bridge driver to hook into mxsfb / dcss
imx-display-subsystem so it makes sense to make it drive a bridge for dsi as
well).
- Use panel_bridge to attach the panel
- Use multiplex framework instead of accessing syscon directly
This has been tested on a Librem 5 devkit using mxsfb with Robert's patches[1]
and the mainline rocktech-jh057n00900 DSI panel driver on next-20200317 and on
the Librem5 with the a Mantix MLAF057WE51-X DSI panel driver (not yet mainline)
The DCSS (submitted for mainline inclusion now too) can also act as input
source.
Changes from v10:
- Per review comments by Sam Ravnborg
https://lore.kernel.org/dri-devel/20200318214639.ga...@ravnborg.org/
- Drop header-test-y since kernel lost support
- Handle drm_bridge_attach's new flags argument
- Add Acked-by: to binding patch, thanks!
- Move to next-20200319
Changes from v9:
- Per review comments by Robert Chiras
https://lore.kernel.org/dri-devel/1575366594.6423.61.ca...@nxp.com/
- don't mix DSI host and bridge initialization
- only select output source once
- defer probe when panel is not ready to fix usage as a module
- use correct reset sequence as described by Robert
(and provided by NWL)
- use mode->clock instead of mode->crtc_clock
- Add tested by from Martin Kepplinger, thanks!
- Drop platform specific data (as suggested previously by Laurent Pinchart and
Andrzej Hajda) since imx8q* needs another set of abstractions with the new
reset sequence and that's easier to do when adding imx8q* support rather then
adding wrong abstraction now.
- Update bindings to use proper clock and irq names to make the example match
reality more closely.
- Use `fallthrough;` instead of /* Fall through */ in switch statements
- Move to next-20200226
Changes from v8:
- Drop reset quirk. It's not needed with mxsfb and sometimes triggers a shifted
display.
Changes from v7:
- Per review comments by Andrzej Hajda
https://lore.kernel.org/linux-arm-kernel/c86b7ca2-7799-eafd-c380-e4b551520...@samsung.com/
- Drop spare empty line
- handle nwl_dsi_write errors
- better handle read errors
- unwind in case of error in nwl_dsi_enable
- use bridge_to_dsi() instead of accessing driver_private
- don't log on -EPROBEDEFER when fething the reset controller
- use endpoint number to determine input
- Spotted by kbuild test robot
https://lore.kernel.org/linux-arm-kernel/201909230644.qfskbnf9%25...@intel.com/
Use signed return type for nwl_dsi_get_dpi_pixel_format
- Drop connector type from drm_panel_bridge_add
- Don't forget to set an error value on dsi reads
Changes from v5:
- Per review comments by Andrzej Hajda
https://lists.freedesktop.org/archives/dri-devel/2019-September/235281.html
- Fix include file ordering
- Add a comment to nwl_dsi_platform_data that will allow to add support
at least for the i.MX8QM
- Merge driver into a single file plus the register defs in a separate header
- Make more functions and structs static
Changes from v4:
- Collect Reviewed-by: from Rob Herring, thanks!
https://lists.freedesktop.org/archives/dri-devel/2019-September/233979.html
- Spotted by kbuild test robot
https://lists.freedesktop.org/archives/dri-devel/2019-September/233860.html
https://lists.freedesktop.org/archives/dri-devel/2019-September/233863.html
- fix format string for size_t
- Use DIV64_U64_ROUND_UP to fix build on 32 bit architectures
We can't use simple shift sind d and n are similar in size and
we need full precision
- Fix debug cfg_t_post debug print out
- Avoid PSEC_PER_SEC
- Move timeout / overflow handling out of nwl_dsi_finish_transmission,
it would never end up being reported since the call to the function
was guarded by flags.
- Drop 'support for' from KConfig title to make it match the other
drivers in that submenu
Changes from v3:
- Per review comments by Robert Chiras
https://lists.freedesktop.org/archives/dri-devel/2019-August/232580.html
- Add Robert's {Signed-off,Tested}-by:
- Respect number of lanes when calculting bandwidth limits
- Drop duplicate NWL_DSI_ENABLE_MULT_PKTS setup
- Per testing by Rober Chiras
https://lists.freedesktop.org/archives/dri-devel/2019-August/233688.html
- Drop duplicate (and too early) drm_bridge_add() in nwl_dsi_probe() that
made mxsfb fail to connect to the bridge since the panel_bridge was not up
Re: [PATCH v8 1/2] dt-bindings: display: add visionox rm69299 panel variant
On Fri, Mar 20, 2020 at 11:14:08AM +0530, Harigovindan P wrote:
> Add bindings for visionox rm69299 panel.
>
> Signed-off-by: Harigovindan P
> ---
>
> Changes in v2:
> - Removed unwanted properties from description.
> - Creating source files without execute permissions(Rob Herring).
> Changes in v3:
> - Changing txt file into yaml
> Changes in v4:
> - Updating license identifier.
> - Moving yaml file inside panel directory.
> - Removing pinctrl entries.
> - Adding documentation for reset-gpios.
> Changes in v5:
> - No changes. Updated 2/2 Patch.
> Changes in v6:
> - Removing patternProperties.
> - Added " |" after description.
> - Setting port and reset-gpios to true.
> - Removing @ae94000 for dsi node.
> Changes in v7:
> - Added reg property.
> Changes in v8:
> - Rearranged additionalProperties.
Still not right...
> - Dropping improper reg property.
>
> .../display/panel/visionox,rm69299.yaml | 73 +++
> 1 file changed, 73 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml
> b/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml
> new file mode 100644
> index ..5fd277602a66
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml
> @@ -0,0 +1,73 @@
> +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/visionox,rm69299.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Visionox model RM69299 Panels Device Tree Bindings.
> +
> +maintainers:
> + - Harigovindan P
> +
> +description: |
> + This binding is for display panels using a Visionox RM692999 panel.
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +properties:
> + compatible:
> +const: visionox,rm69299-1080p-display
> +
> + reg:
> +maxItems: 1
> +
> + vdda-supply:
> +description: |
> + Phandle of the regulator that provides the vdda supply voltage.
> +
> + vdd3p3-supply:
> +description: |
> + Phandle of the regulator that provides the vdd3p3 supply voltage.
> +
> + ports:
> +type: object
> +description: |
> + A node containing DSI input & output port nodes with endpoint
> + definitions as documented in
> + Documentation/devicetree/bindings/media/video-interfaces.txt
> + Documentation/devicetree/bindings/graph.txt
> + properties:
> +port: true
This is not taking effect because it's just description. You need to
indent 2 fewer spaces.
'port' is not equal to 'port@0' which the example has. So fix the
example.
And you need to add 'additionalProperties: false' here at the same level
as 'properties'.
> +
> + reset-gpios: true
> +
> +additionalProperties: false
> +
> +required:
> + - compatible
> + - vdda-supply
> + - vdd3p3-supply
> + - reset-gpios
> +
> +examples:
> + - |
> +panel {
> +compatible = "visionox,rm69299-1080p-display";
> +
> +vdda-supply = <_pp1800_l8c>;
> +vdd3p3-supply = <_pp2800_l18a>;
> +
> +reset-gpios = <_gpio 3 0>;
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +port@0 {
> +reg = <0>;
> +panel0_in: endpoint {
> +remote-endpoint = <_out>;
> +};
> +};
> +};
> +};
> +...
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull drm fixes for 5.6-rc7
The pull request you sent on Fri, 20 Mar 2020 13:01:44 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-03-20 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/69d3e5a5a66bb59c39f36dcb9cf4e9a4239aa8cd Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/client: Dual licence the header in GPL-2 and MIT
On Fri, Mar 20, 2020 at 03:21:13AM +0100, Emmanuel Vadot wrote: > Source file was dual licenced but the header was omitted, fix that. > Contributors for this file are: > Daniel Vetter > Matt Roper > Maxime Ripard > Noralf Trønnes > Thomas Zimmermann Acked-by: Matt Roper > > Signed-off-by: Emmanuel Vadot > --- > include/drm/drm_client.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/drm/drm_client.h b/include/drm/drm_client.h > index 3ed5dee899fd..94c9c72c206d 100644 > --- a/include/drm/drm_client.h > +++ b/include/drm/drm_client.h > @@ -1,4 +1,4 @@ > -/* SPDX-License-Identifier: GPL-2.0 */ > +/* SPDX-License-Identifier: GPL-2.0 or MIT */ > > #ifndef _DRM_CLIENT_H_ > #define _DRM_CLIENT_H_ > -- > 2.25.1 > -- Matt Roper Graphics Software Engineer VTT-OSGC Platform Enablement Intel Corporation (916) 356-2795 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: fbdev: fix -Wextra build warnings
On 3/15/20 5:09 AM, Randy Dunlap wrote: > This patch series fixes warnings in fbdev that are found when > -Wextra is used. In fixing these, there were a few other build > errors discovered (mostly caused by bitrot) and fixed. > > [PATCH 1/6] fbdev: fbmon: fix -Wextra build warnings > [PATCH 2/6] fbdev: aty: fix -Wextra build warning > [PATCH 3/6] fbdev: matrox: fix -Wextra build warnings > [PATCH 4/6] fbdev: savage: fix -Wextra build warning > [PATCH 5/6] fbdev: pm[23]fb.c: fix -Wextra build warnings and errors > [PATCH 6/6] fbdev: via: fix -Wextra build warning and format warning > > drivers/video/fbdev/aty/atyfb_base.c |2 +- > drivers/video/fbdev/core/fbmon.c |2 +- > drivers/video/fbdev/matrox/matroxfb_base.h |2 +- > drivers/video/fbdev/pm2fb.c|2 +- > drivers/video/fbdev/pm3fb.c|8 > drivers/video/fbdev/savage/savagefb.h |2 +- > drivers/video/fbdev/via/debug.h|6 -- > drivers/video/fbdev/via/viafbdev.c |2 +- > 8 files changed, 14 insertions(+), 12 deletions(-) Patches #1-6 queued for v5.7, thanks! Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] omapfb: Remove unused writeback code
On 3/13/20 1:24 PM, Tomi Valkeinen wrote:
> Remove unused writeback code. This code will never be used, as omapfb is
> being deprecated.
>
> Signed-off-by: Tomi Valkeinen
Patch queued for v5.7, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/omap2/omapfb/dss/dispc.c | 114 ---
> drivers/video/fbdev/omap2/omapfb/dss/dss.h | 20
> 2 files changed, 134 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
> b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
> index ce37da85cc45..4a16798b2ecd 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
> @@ -557,11 +557,6 @@ u32 dispc_mgr_get_sync_lost_irq(enum omap_channel
> channel)
> }
> EXPORT_SYMBOL(dispc_mgr_get_sync_lost_irq);
>
> -u32 dispc_wb_get_framedone_irq(void)
> -{
> - return DISPC_IRQ_FRAMEDONEWB;
> -}
> -
> bool dispc_mgr_go_busy(enum omap_channel channel)
> {
> return mgr_fld_read(channel, DISPC_MGR_FLD_GO) == 1;
> @@ -579,30 +574,6 @@ void dispc_mgr_go(enum omap_channel channel)
> }
> EXPORT_SYMBOL(dispc_mgr_go);
>
> -bool dispc_wb_go_busy(void)
> -{
> - return REG_GET(DISPC_CONTROL2, 6, 6) == 1;
> -}
> -
> -void dispc_wb_go(void)
> -{
> - enum omap_plane plane = OMAP_DSS_WB;
> - bool enable, go;
> -
> - enable = REG_GET(DISPC_OVL_ATTRIBUTES(plane), 0, 0) == 1;
> -
> - if (!enable)
> - return;
> -
> - go = REG_GET(DISPC_CONTROL2, 6, 6) == 1;
> - if (go) {
> - DSSERR("GO bit not down for WB\n");
> - return;
> - }
> -
> - REG_FLD_MOD(DISPC_CONTROL2, 1, 6, 6);
> -}
> -
> static void dispc_ovl_write_firh_reg(enum omap_plane plane, int reg, u32
> value)
> {
> dispc_write_reg(DISPC_OVL_FIR_COEF_H(plane, reg), value);
> @@ -1028,13 +999,6 @@ static enum omap_channel dispc_ovl_get_channel_out(enum
> omap_plane plane)
> }
> }
>
> -void dispc_wb_set_channel_in(enum dss_writeback_channel channel)
> -{
> - enum omap_plane plane = OMAP_DSS_WB;
> -
> - REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), channel, 18, 16);
> -}
> -
> static void dispc_ovl_set_burst_size(enum omap_plane plane,
> enum omap_burst_size burst_size)
> {
> @@ -2805,74 +2769,6 @@ int dispc_ovl_setup(enum omap_plane plane, const
> struct omap_overlay_info *oi,
> }
> EXPORT_SYMBOL(dispc_ovl_setup);
>
> -int dispc_wb_setup(const struct omap_dss_writeback_info *wi,
> - bool mem_to_mem, const struct omap_video_timings *mgr_timings)
> -{
> - int r;
> - u32 l;
> - enum omap_plane plane = OMAP_DSS_WB;
> - const int pos_x = 0, pos_y = 0;
> - const u8 zorder = 0, global_alpha = 0;
> - const bool replication = false;
> - bool truncation;
> - int in_width = mgr_timings->x_res;
> - int in_height = mgr_timings->y_res;
> - enum omap_overlay_caps caps =
> - OMAP_DSS_OVL_CAP_SCALE | OMAP_DSS_OVL_CAP_PRE_MULT_ALPHA;
> -
> - DSSDBG("dispc_wb_setup, pa %x, pa_uv %x, %d,%d -> %dx%d, cmode %x, "
> - "rot %d, mir %d\n", wi->paddr, wi->p_uv_addr, in_width,
> - in_height, wi->width, wi->height, wi->color_mode, wi->rotation,
> - wi->mirror);
> -
> - r = dispc_ovl_setup_common(plane, caps, wi->paddr, wi->p_uv_addr,
> - wi->buf_width, pos_x, pos_y, in_width, in_height, wi->width,
> - wi->height, wi->color_mode, wi->rotation, wi->mirror, zorder,
> - wi->pre_mult_alpha, global_alpha, wi->rotation_type,
> - replication, mgr_timings, mem_to_mem);
> -
> - switch (wi->color_mode) {
> - case OMAP_DSS_COLOR_RGB16:
> - case OMAP_DSS_COLOR_RGB24P:
> - case OMAP_DSS_COLOR_ARGB16:
> - case OMAP_DSS_COLOR_RGBA16:
> - case OMAP_DSS_COLOR_RGB12U:
> - case OMAP_DSS_COLOR_ARGB16_1555:
> - case OMAP_DSS_COLOR_XRGB16_1555:
> - case OMAP_DSS_COLOR_RGBX16:
> - truncation = true;
> - break;
> - default:
> - truncation = false;
> - break;
> - }
> -
> - /* setup extra DISPC_WB_ATTRIBUTES */
> - l = dispc_read_reg(DISPC_OVL_ATTRIBUTES(plane));
> - l = FLD_MOD(l, truncation, 10, 10); /* TRUNCATIONENABLE */
> - l = FLD_MOD(l, mem_to_mem, 19, 19); /* WRITEBACKMODE */
> - if (mem_to_mem)
> - l = FLD_MOD(l, 1, 26, 24); /* CAPTUREMODE */
> - else
> - l = FLD_MOD(l, 0, 26, 24); /* CAPTUREMODE */
> - dispc_write_reg(DISPC_OVL_ATTRIBUTES(plane), l);
> -
> - if (mem_to_mem) {
> - /* WBDELAYCOUNT */
> - REG_FLD_MOD(DISPC_OVL_ATTRIBUTES2(plane), 0, 7, 0);
> - } else {
> - int wbdelay;
> -
> - wbdelay = min(mgr_timings->vfp + mgr_timings->vsw +
> - mgr_timings->vbp, 255);
> -
> - /* WBDELAYCOUNT */
> -
Re: [PATCH 0/3] video: Use scnprintf() for avoiding potential buffer overflow
On 3/19/20 4:49 PM, Takashi Iwai wrote: > On Wed, 11 Mar 2020 10:32:27 +0100, > Takashi Iwai wrote: >> >> Hi, >> >> here is a series of trivial patches just to convert suspicious >> snprintf() usages with the more safer one, scnprintf(). >> >> >> Takashi >> >> === >> >> Takashi Iwai (3): >> video: omapfb: Use scnprintf() for avoiding potential buffer overflow >> video: omap2: Use scnprintf() for avoiding potential buffer overflow >> video: uvesafb: Use scnprintf() for avoiding potential buffer overflow >> >> drivers/video/fbdev/omap/omapfb_main.c | 14 +++--- >> drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c | 8 >> drivers/video/fbdev/uvesafb.c | 2 +- >> 3 files changed, 12 insertions(+), 12 deletions(-) > > Just a gentle ping about those patches. > Let me know if any further changes needed. Patches #1-3 queued for v5.7, thanks! Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Fix off by one in nvidia driver strncpy size arg
On 3/9/20 1:49 PM, Dominik 'disconnect3d' Czarnota wrote:
> From: disconnect3d
>
> This patch fixes an off-by-one error in strncpy size argument in
> drivers/video/fbdev/nvidia/nvidia.c. The issue is that in:
>
> strncmp(this_opt, "noaccel", 6)
>
> the passed string literal: "noaccel" has 7 bytes (without the NULL byte)
> and the passed size argument is 6. As a result, the logic will also
> match/accept string "noacce" or "noacceX".
>
> This bug doesn't seem to have any security impact since its present in
> the driver's setup and just accepts slighty changed string to enable the
> `noaccel` flag.
>
> Signed-off-by: disconnect3d
Patch looks fine but please fix 'From:' and 'S-o-b:' lines,
per Documentation/process/submitting-patches.rst:
...
then you just add a line saying::
Signed-off-by: Random J Developer
using your real name (sorry, no pseudonyms or anonymous contributions.)
...
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
> ---
>
> Notes:
> The bug could also be fixed by changing the size argument to
> `sizeof("string literal")-1` but I am not proposing this change as that
> would have to be changed in other places.
>
> There are also more cases like this in kernel sources which I
> reported/will report soon.
>
> This bug has been found by running a massive grep-like search using
> Google's BigQuery on GitHub repositories data. I am also going to work
> on a CodeQL/Semmle query to be able to find more sophisticated cases
> like this that can't be found via grepping.
>
> drivers/video/fbdev/nvidia/nvidia.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/nvidia/nvidia.c
> b/drivers/video/fbdev/nvidia/nvidia.c
> index c583c018304d..b77efeb33477 100644
> --- a/drivers/video/fbdev/nvidia/nvidia.c
> +++ b/drivers/video/fbdev/nvidia/nvidia.c
> @@ -1470,7 +1470,7 @@ static int nvidiafb_setup(char *options)
> flatpanel = 1;
> } else if (!strncmp(this_opt, "hwcur", 5)) {
> hwcur = 1;
> - } else if (!strncmp(this_opt, "noaccel", 6)) {
> + } else if (!strncmp(this_opt, "noaccel", 7)) {
> noaccel = 1;
> } else if (!strncmp(this_opt, "noscale", 7)) {
> noscale = 1;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 10/12] backlight: pwm_bl: Use 64-bit division function
On Thu, 19 Mar 2020, Guru Das Srinagesh wrote: > Since the PWM framework is switching struct pwm_state.period's datatype > to u64, prepare for this transition by using div_u64 to handle a 64-bit > dividend instead of a straight division operation. > > Cc: Lee Jones > Cc: Daniel Thompson > Cc: Jingoo Han > Cc: Bartlomiej Zolnierkiewicz > Cc: linux-...@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > Cc: linux-fb...@vger.kernel.org > > Signed-off-by: Guru Das Srinagesh > Reviewed-by: Daniel Thompson > --- > drivers/video/backlight/pwm_bl.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Can this patch be taken on its own? > diff --git a/drivers/video/backlight/pwm_bl.c > b/drivers/video/backlight/pwm_bl.c > index efb4efc..3e5dbcf 100644 > --- a/drivers/video/backlight/pwm_bl.c > +++ b/drivers/video/backlight/pwm_bl.c > @@ -625,7 +625,8 @@ static int pwm_backlight_probe(struct platform_device > *pdev) > pb->scale = data->max_brightness; > } > > - pb->lth_brightness = data->lth_brightness * (state.period / pb->scale); > + pb->lth_brightness = data->lth_brightness * (div_u64(state.period, > + pb->scale)); > > props.type = BACKLIGHT_RAW; > props.max_brightness = data->max_brightness; -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH net-next] drm/amdgpu: Uninitialized variable in gfx_v9_0_rlcg_wreg()
The "shadow" variable was never set to false.
There is a quirk in current versions of GCC where it will sometimes set
it to false and not warn about the uninitiliazed variable. That means
that this bug wouldn't have been discovered in normal testing.
Fixes: 2e0cc4d48b91 ("drm/amdgpu: revise RLCG access path")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 7bc2486167e7..affbff76758c 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -735,7 +735,7 @@ void gfx_v9_0_rlcg_wreg(struct amdgpu_device *adev, u32
offset, u32 v)
static void *spare_int;
static uint32_t grbm_cntl;
static uint32_t grbm_idx;
- bool shadow;
+ bool shadow = false;
scratch_reg0 = adev->rmmio +
(adev->reg_offset[GC_HWIP][0][mmSCRATCH_REG0_BASE_IDX] + mmSCRATCH_REG0)*4;
scratch_reg1 = adev->rmmio +
(adev->reg_offset[GC_HWIP][0][mmSCRATCH_REG1_BASE_IDX] + mmSCRATCH_REG1)*4;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/gem: Fix a leak in drm_gem_objects_lookup()
If the "handles" allocation or the copy_from_user() fails then we leak
"objs". It's supposed to be freed in panfrost_job_cleanup().
Fixes: c117aa4d8701 ("drm: Add a drm_gem_objects_lookup helper")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/drm_gem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index a9e4a610445a..f28724f2eb69 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -710,6 +710,8 @@ int drm_gem_objects_lookup(struct drm_file *filp, void
__user *bo_handles,
if (!objs)
return -ENOMEM;
+ *objs_out = objs;
+
handles = kvmalloc_array(count, sizeof(u32), GFP_KERNEL);
if (!handles) {
ret = -ENOMEM;
@@ -723,8 +725,6 @@ int drm_gem_objects_lookup(struct drm_file *filp, void
__user *bo_handles,
}
ret = objects_lookup(filp, handles, count, objs);
- *objs_out = objs;
-
out:
kvfree(handles);
return ret;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mipi-dbi: Make mipi_dbi_command_stackbuf() data parameter const
Den 20.03.2020 13.28, skrev Sam Ravnborg:
> Hi Noralf.
>
> On Mon, Mar 16, 2020 at 05:42:49PM +0100, Geert Uytterhoeven wrote:
>> mipi_dbi_command_stackbuf() copies the passed buffer data, so it can be
>> const.
>>
>> Signed-off-by: Geert Uytterhoeven
>
> OK to merge?
> Looks good to me and build did not break.
Sure, I planned to look at it this weekend, but if you can apply it, great.
Reviewed-by: Noralf Trønnes
Noralf.
>
> Sam
>
>> ---
>> drivers/gpu/drm/drm_mipi_dbi.c | 3 ++-
>> include/drm/drm_mipi_dbi.h | 5 +++--
>> 2 files changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
>> index 558baf989f5a8432..89e911ccea06cf99 100644
>> --- a/drivers/gpu/drm/drm_mipi_dbi.c
>> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
>> @@ -169,7 +169,8 @@ int mipi_dbi_command_buf(struct mipi_dbi *dbi, u8 cmd,
>> u8 *data, size_t len)
>> EXPORT_SYMBOL(mipi_dbi_command_buf);
>>
>> /* This should only be used by mipi_dbi_command() */
>> -int mipi_dbi_command_stackbuf(struct mipi_dbi *dbi, u8 cmd, u8 *data,
>> size_t len)
>> +int mipi_dbi_command_stackbuf(struct mipi_dbi *dbi, u8 cmd, const u8 *data,
>> + size_t len)
>> {
>> u8 *buf;
>> int ret;
>> diff --git a/include/drm/drm_mipi_dbi.h b/include/drm/drm_mipi_dbi.h
>> index 33f325f5af2b921f..9333b9086c30bd3c 100644
>> --- a/include/drm/drm_mipi_dbi.h
>> +++ b/include/drm/drm_mipi_dbi.h
>> @@ -170,7 +170,8 @@ int mipi_dbi_spi_transfer(struct spi_device *spi, u32
>> speed_hz,
>>
>> int mipi_dbi_command_read(struct mipi_dbi *dbi, u8 cmd, u8 *val);
>> int mipi_dbi_command_buf(struct mipi_dbi *dbi, u8 cmd, u8 *data, size_t
>> len);
>> -int mipi_dbi_command_stackbuf(struct mipi_dbi *dbi, u8 cmd, u8 *data,
>> size_t len);
>> +int mipi_dbi_command_stackbuf(struct mipi_dbi *dbi, u8 cmd, const u8 *data,
>> + size_t len);
>> int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer *fb,
>>struct drm_rect *clip, bool swap);
>> /**
>> @@ -187,7 +188,7 @@ int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer
>> *fb,
>> */
>> #define mipi_dbi_command(dbi, cmd, seq...) \
>> ({ \
>> -u8 d[] = { seq }; \
>> +const u8 d[] = { seq }; \
>> mipi_dbi_command_stackbuf(dbi, cmd, d, ARRAY_SIZE(d)); \
>> })
>>
>> --
>> 2.17.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mipi-dbi: Make mipi_dbi_command_stackbuf() data parameter const
Hi Noralf.
On Mon, Mar 16, 2020 at 05:42:49PM +0100, Geert Uytterhoeven wrote:
> mipi_dbi_command_stackbuf() copies the passed buffer data, so it can be
> const.
>
> Signed-off-by: Geert Uytterhoeven
OK to merge?
Looks good to me and build did not break.
Sam
> ---
> drivers/gpu/drm/drm_mipi_dbi.c | 3 ++-
> include/drm/drm_mipi_dbi.h | 5 +++--
> 2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
> index 558baf989f5a8432..89e911ccea06cf99 100644
> --- a/drivers/gpu/drm/drm_mipi_dbi.c
> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
> @@ -169,7 +169,8 @@ int mipi_dbi_command_buf(struct mipi_dbi *dbi, u8 cmd, u8
> *data, size_t len)
> EXPORT_SYMBOL(mipi_dbi_command_buf);
>
> /* This should only be used by mipi_dbi_command() */
> -int mipi_dbi_command_stackbuf(struct mipi_dbi *dbi, u8 cmd, u8 *data, size_t
> len)
> +int mipi_dbi_command_stackbuf(struct mipi_dbi *dbi, u8 cmd, const u8 *data,
> + size_t len)
> {
> u8 *buf;
> int ret;
> diff --git a/include/drm/drm_mipi_dbi.h b/include/drm/drm_mipi_dbi.h
> index 33f325f5af2b921f..9333b9086c30bd3c 100644
> --- a/include/drm/drm_mipi_dbi.h
> +++ b/include/drm/drm_mipi_dbi.h
> @@ -170,7 +170,8 @@ int mipi_dbi_spi_transfer(struct spi_device *spi, u32
> speed_hz,
>
> int mipi_dbi_command_read(struct mipi_dbi *dbi, u8 cmd, u8 *val);
> int mipi_dbi_command_buf(struct mipi_dbi *dbi, u8 cmd, u8 *data, size_t len);
> -int mipi_dbi_command_stackbuf(struct mipi_dbi *dbi, u8 cmd, u8 *data, size_t
> len);
> +int mipi_dbi_command_stackbuf(struct mipi_dbi *dbi, u8 cmd, const u8 *data,
> + size_t len);
> int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer *fb,
> struct drm_rect *clip, bool swap);
> /**
> @@ -187,7 +188,7 @@ int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer
> *fb,
> */
> #define mipi_dbi_command(dbi, cmd, seq...) \
> ({ \
> - u8 d[] = { seq }; \
> + const u8 d[] = { seq }; \
> mipi_dbi_command_stackbuf(dbi, cmd, d, ARRAY_SIZE(d)); \
> })
>
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] fbdev: s1d13xxxfb: add missed unregister_framebuffer in remove
On 3/10/20 3:30 PM, Chuhong Yuan wrote:
> The driver calls register_framebuffer() in probe but does not call
> unregister_framebuffer() in remove.
> Rename current remove to __s1d13xxxfb_remove() for error handler.
> Then add a new remove to call unregister_framebuffer().
>
> Signed-off-by: Chuhong Yuan
> ---
> Changes in v2:
> - Rename the existing remove and add a new one to ensure the correctness
> of error handler in probe.
>
> drivers/video/fbdev/s1d13xxxfb.c | 17 ++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/fbdev/s1d13xxxfb.c
> b/drivers/video/fbdev/s1d13xxxfb.c
> index 8048499e398d..bafea3d09bba 100644
> --- a/drivers/video/fbdev/s1d13xxxfb.c
> +++ b/drivers/video/fbdev/s1d13xxxfb.c
> @@ -721,9 +721,8 @@ static void s1d13xxxfb_fetch_hw_state(struct fb_info
> *info)
> xres, yres, xres_virtual, yres_virtual, is_color, is_dual,
> is_tft);
> }
>
> -
> static int
> -s1d13xxxfb_remove(struct platform_device *pdev)
> +__s1d13xxxfb_remove(struct platform_device *pdev)
The new function can be made void as it always returns 0.
Also please use the standard CodingStyle while at it:
void __s1d13xxxfb_remove(struct platform_device *pdev)
> {
> struct fb_info *info = platform_get_drvdata(pdev);
> struct s1d13xxxfb_par *par = NULL;
> @@ -752,6 +751,18 @@ s1d13xxxfb_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static int
> +s1d13xxxfb_remove(struct platform_device *pdev)
Please use the standard CodingStyle while at it:
static int s1d13xxxfb_remove(struct platform_device *pdev)
> +{
> + struct fb_info *info = platform_get_drvdata(pdev);
> +
> + if (info)
'info' check is superfluous in the ->remove only code-path.
> + unregister_framebuffer(info);
> +
> + return __s1d13xxxfb_remove(pdev);
> +}
> +
> +
> static int s1d13xxxfb_probe(struct platform_device *pdev)
> {
> struct s1d13xxxfb_par *default_par;
> @@ -895,7 +906,7 @@ static int s1d13xxxfb_probe(struct platform_device *pdev)
> return 0;
>
> bail:
> - s1d13xxxfb_remove(pdev);
> + __s1d13xxxfb_remove(pdev);
> return ret;
>
> }
>
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v7 04/18] drm/i915/dp: Add writing of DP SDPs
On Mon, 16 Mar 2020, "Shankar, Uma" wrote:
>> -Original Message-
>> From: dri-devel On Behalf Of Gwan-
>> gyeong Mun
>> Sent: Tuesday, February 11, 2020 1:17 PM
>> To: intel-...@lists.freedesktop.org
>> Cc: linux-fb...@vger.kernel.org; dri-devel@lists.freedesktop.org
>> Subject: [PATCH v7 04/18] drm/i915/dp: Add writing of DP SDPs
>>
>> It adds routines that write DP VSC SDP and DP HDR Metadata Infoframe SDP.
>> In order to pack DP VSC SDP, it adds intel_dp_vsc_sdp_pack() function.
>> It follows DP 1.4a spec. [Table 2-116: VSC SDP Header Bytes] and [Table
>> 2-117: VSC
>> SDP Payload for DB16 through DB18]
>>
>> In order to pack DP HDR Metadata Infoframe SDP, it adds
>> intel_dp_hdr_metadata_infoframe_sdp_pack() function.
>> And it follows DP 1.4a spec.
>> ([Table 2-125: INFOFRAME SDP v1.2 Header Bytes] and [Table 2-126: INFOFRAME
>> SDP v1.2 Payload Data Bytes - DB0 through DB31]) and CTA-861-G spec.
>> [Table-42
>> Dynamic Range and Mastering InfoFrame].
>>
>> A mechanism and a naming rule of intel_dp_set_infoframes() function
>> references
>> intel_encoder->set_infoframes() of intel_hdmi.c .
>> VSC SDP is used for PSR and Pixel Encoding and Colorimetry Formats cases.
>> Because PSR routine has its own routine of writing a VSC SDP, when the PSR is
>> enabled, intel_dp_set_infoframes() does not write a VSC SDP.
>>
>> v3:
>> - Explicitly disable unused DIPs (AVI, GCP, VS, SPD, DRM. They will be
>> used for HDMI), when intel_dp_set_infoframes() function will be called.
>> - Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp.
>> v4: Use struct drm_device logging macros
>> v5:
>> - use intel_de_*() functions for register access
>> - Addressed review comments from Uma
>> Polish commit message and comments
>> Add 6bpc to packing of VSC SDP
>
> Looks good to me.
> Reviewed-by: Uma Shankar
Pushed up to and including this patch, thanks for the patches and
review.
BR,
Jani.
>
>> Signed-off-by: Gwan-gyeong Mun
>> ---
>> drivers/gpu/drm/i915/display/intel_dp.c | 199
>> drivers/gpu/drm/i915/display/intel_dp.h | 3 +
>> 2 files changed, 202 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
>> b/drivers/gpu/drm/i915/display/intel_dp.c
>> index fb008168ca83..5bbc55113325 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>> @@ -4741,6 +4741,205 @@ intel_dp_needs_vsc_sdp(const struct intel_crtc_state
>> *crtc_state,
>> return false;
>> }
>>
>> +static ssize_t intel_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
>> + struct dp_sdp *sdp, size_t size) {
>> +size_t length = sizeof(struct dp_sdp);
>> +
>> +if (size < length)
>> +return -ENOSPC;
>> +
>> +memset(sdp, 0, size);
>> +
>> +/*
>> + * Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119
>> + * VSC SDP Header Bytes
>> + */
>> +sdp->sdp_header.HB0 = 0; /* Secondary-Data Packet ID = 0 */
>> +sdp->sdp_header.HB1 = vsc->sdp_type; /* Secondary-data Packet Type */
>> +sdp->sdp_header.HB2 = vsc->revision; /* Revision Number */
>> +sdp->sdp_header.HB3 = vsc->length; /* Number of Valid Data Bytes */
>> +
>> +/* VSC SDP Payload for DB16 through DB18 */
>> +/* Pixel Encoding and Colorimetry Formats */
>> +sdp->db[16] = (vsc->pixelformat & 0xf) << 4; /* DB16[7:4] */
>> +sdp->db[16] |= vsc->colorimetry & 0xf; /* DB16[3:0] */
>> +
>> +switch (vsc->bpc) {
>> +case 6:
>> +/* 6bpc: 0x0 */
>> +break;
>> +case 8:
>> +sdp->db[17] = 0x1; /* DB17[3:0] */
>> +break;
>> +case 10:
>> +sdp->db[17] = 0x2;
>> +break;
>> +case 12:
>> +sdp->db[17] = 0x3;
>> +break;
>> +case 16:
>> +sdp->db[17] = 0x4;
>> +break;
>> +default:
>> +MISSING_CASE(vsc->bpc);
>> +break;
>> +}
>> +/* Dynamic Range and Component Bit Depth */
>> +if (vsc->dynamic_range == DP_DYNAMIC_RANGE_CTA)
>> +sdp->db[17] |= 0x80; /* DB17[7] */
>> +
>> +/* Content Type */
>> +sdp->db[18] = vsc->content_type & 0x7;
>> +
>> +return length;
>> +}
>> +
>> +static ssize_t
>> +intel_dp_hdr_metadata_infoframe_sdp_pack(const struct hdmi_drm_infoframe
>> *drm_infoframe,
>> + struct dp_sdp *sdp,
>> + size_t size)
>> +{
>> +size_t length = sizeof(struct dp_sdp);
>> +const int infoframe_size = HDMI_INFOFRAME_HEADER_SIZE +
>> HDMI_DRM_INFOFRAME_SIZE;
>> +unsigned char buf[HDMI_INFOFRAME_HEADER_SIZE +
>> HDMI_DRM_INFOFRAME_SIZE];
>> +ssize_t len;
>> +
>> +if (size < length)
>> +return -ENOSPC;
>> +
>> +memset(sdp, 0, size);
>> +
>> +len = hdmi_drm_infoframe_pack_only(drm_infoframe, buf, sizeof(buf));
>> +if (len < 0) {
>> +
Re: [PATCH 2/2] drm/format_helper: Dual licence the header in GPL-2 and MIT
Den 20.03.2020 03.21, skrev Emmanuel Vadot: > Source file was dual licenced but the header was omitted, fix that. > Contributors for this file are: > Noralf Trønnes > Gerd Hoffmann > Thomas Gleixner > > Signed-off-by: Emmanuel Vadot > --- Acked-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/client: Dual licence the header in GPL-2 and MIT
Den 20.03.2020 03.21, skrev Emmanuel Vadot: > Source file was dual licenced but the header was omitted, fix that. > Contributors for this file are: > Daniel Vetter > Matt Roper > Maxime Ripard > Noralf Trønnes > Thomas Zimmermann > > Signed-off-by: Emmanuel Vadot > --- Acked-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Proposal to report GPU private memory allocations with sysfs nodes [plain text version]
Hi Yiwei
After some deliberation on how to move forward with my BO Labeling patches[1],
we've come up with the following structure for debugfs entries:
/debugfs/dri/128/bo//label
/debugfs/dri/128/bo//size
My initial idea was to count the total memory allocated for a particular label
in kernel space, but that turned out to be far too complicated to implement.
Which is why we decided to move towards something simpler and handle collating
this information on the userspace side of things.
Would this satisfy most of the Android teams requirements? I understand that
it would leave out the memory tracking requirements tied to a specific PID,
but correct me if I'm wrong, would this not possible with gralloc on Android?
Cheers
Rohan Garg
[1] https://patchwork.freedesktop.org/patch/335508/?series=66752=4
On lunes, 6 de enero de 2020 21:47:21 (CET) Yiwei Zhang wrote:
> Thanks, I'll check it out.
>
> Best,
> Yiwei
>
> On Mon, Jan 6, 2020 at 2:46 AM Rohan Garg wrote:
> > Hi Yiwei
> >
> > On jueves, 19 de diciembre de 2019 19:52:26 (CET) Yiwei Zhang wrote:
> > > Hi Rohan,
> > >
> > > Thanks for pointing out the pids issue! Then the index would be
> >
> > {namespace
> >
> > > + pid(in that namespace)}. I'll grab a setup and play with the driver to
> > > see what I can do. I know how to find an Intel or Freedreno setup, but
> >
> > I'd
> >
> > > still like to know is there a development friendly Mali setup?
> >
> > You should be able to setup a Mali T860 compatible device with this guide
> > [1].
> >
> > Cheers
> > Rohan Garg
> >
> > [1] https://panfrost.freedesktop.org/building-panfrost-mesa.html
signature.asc
Description: This is a digitally signed message part.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] video: fbdev: vesafb: add missed release_region
On 3/10/20 3:35 AM, Chuhong Yuan wrote:
> The driver forgets to free the I/O region in remove and probe
> failure.
> Add the missed calls to fix it.
>
> Signed-off-by: Chuhong Yuan
> ---
> Changes in v3:
> - Revise the commit message.
> - Add an error handler to suit the "goto error" before request_region().
> - Revise the order of operations in remove.
>
> drivers/video/fbdev/vesafb.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/fbdev/vesafb.c b/drivers/video/fbdev/vesafb.c
> index a1fe24ea869b..c7bc9ace47d4 100644
> --- a/drivers/video/fbdev/vesafb.c
> +++ b/drivers/video/fbdev/vesafb.c
> @@ -439,7 +439,7 @@ static int vesafb_probe(struct platform_device *dev)
> "vesafb: abort, cannot ioremap video memory 0x%x @
> 0x%lx\n",
> vesafb_fix.smem_len, vesafb_fix.smem_start);
> err = -EIO;
> - goto err;
> + goto err_release_region;
> }
>
> printk(KERN_INFO "vesafb: framebuffer at 0x%lx, mapped to 0x%p, "
> @@ -458,15 +458,17 @@ static int vesafb_probe(struct platform_device *dev)
>
> if (fb_alloc_cmap(>cmap, 256, 0) < 0) {
> err = -ENOMEM;
> - goto err;
> + goto err_release_region;
> }
> if (register_framebuffer(info)<0) {
> err = -EINVAL;
> fb_dealloc_cmap(>cmap);
> - goto err;
> + goto err_release_region;
> }
> fb_info(info, "%s frame buffer device\n", info->fix.id);
> return 0;
> +err_release_region:
> + release_region(0x3c0, 32);
This is incorrect.
The cleanup order should be the reverse of the probing order.
Also request_region() return value is not checked by the driver
(there is a comment that it can fail and is optional):
/* request failure does not faze us, as vgacon probably has this
* region already (FIXME) */
request_region(0x3c0, 32, "vesafb");
so what would happen in such case? It seems that unconditionally
doing the release will result in freeing the I/O region owned by
the other driver (vgacon)..
> err:
> arch_phys_wc_del(par->wc_cookie);
> if (info->screen_base)
> @@ -481,6 +483,7 @@ static int vesafb_remove(struct platform_device *pdev)
> struct fb_info *info = platform_get_drvdata(pdev);
>
> unregister_framebuffer(info);
> + release_region(0x3c0, 32);
> framebuffer_release(info);
>
> return 0;
>
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v7 05/18] video/hdmi: Add Unpack only function for DRM infoframe
Hi Jani,
On Fri, Mar 20, 2020 at 01:32:17PM +0200, Jani Nikula wrote:
> On Fri, 20 Mar 2020, Jani Nikula wrote:
> > On Tue, 11 Feb 2020, Gwan-gyeong Mun wrote:
> >> It adds an unpack only function for DRM infoframe for dynamic range and
> >> mastering infoframe readout.
> >> It unpacks the information data block contained in the binary buffer into
> >> a structured frame of the HDMI Dynamic Range and Mastering (DRM)
> >> information frame.
> >>
> >> In contrast to hdmi_drm_infoframe_unpack() function, it does not verify
> >> a checksum.
> >>
> >> It can be used for unpacking a DP HDR Metadata Infoframe SDP case.
> >> DP HDR Metadata Infoframe SDP uses the same Dynamic Range and Mastering
> >> (DRM) information (CTA-861-G spec.) such as HDMI DRM infoframe.
> >> But DP SDP header and payload structure are different from HDMI DRM
> >> Infoframe. Therefore unpacking DRM infoframe for DP requires skipping of
> >> a verifying checksum.
> >>
> >> Signed-off-by: Gwan-gyeong Mun
> >> Reviewed-by: Uma Shankar
> >
> > Bartlomiej, can I have your ack for merging this via drm-intel along
> > with the rest of the series, please?
>
> Or Hans or Laurent, from v4l/video point of view.
I'm no expert on InfoFrame, I'll only comment on the API below.
> >> ---
> >> drivers/video/hdmi.c | 58 +++-
> >> include/linux/hdmi.h | 2 ++
> >> 2 files changed, 43 insertions(+), 17 deletions(-)
> >>
> >> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> >> index 9c82e2a0a411..9818836d82b7 100644
> >> --- a/drivers/video/hdmi.c
> >> +++ b/drivers/video/hdmi.c
> >> @@ -1775,20 +1775,18 @@ hdmi_vendor_any_infoframe_unpack(union
> >> hdmi_vendor_any_infoframe *frame,
> >> }
> >>
> >> /**
> >> - * hdmi_drm_infoframe_unpack() - unpack binary buffer to a HDMI DRM
> >> infoframe
> >> + * hdmi_drm_infoframe_unpack_only() - unpack binary buffer to a HDMI DRM
> >> infoframe
> >> * @frame: HDMI DRM infoframe
> >> * @buffer: source buffer
> >> * @size: size of buffer
> >> *
> >> - * Unpacks the information contained in binary @buffer into a structured
> >> + * Unpacks the information data block contained in binary @buffer into a
> >> structured
Line wrap please.
This needs to be clarified to explain exactly what the buffer points to.
Also, as this is applicable to DP too, shouldn't we drop the hdmi_
prefix ? Is there another prefix that could be used for functions that
are application to infoframe handling shared by different display
interfaces ? A bit of refactoring would help making all this clear.
> >> * @frame of the HDMI Dynamic Range and Mastering (DRM) information frame.
> >> - * Also verifies the checksum as required by section 5.3.5 of the HDMI 1.4
> >> - * specification.
> >> *
> >> * Returns 0 on success or a negative error code on failure.
> >> */
> >> -static int hdmi_drm_infoframe_unpack(struct hdmi_drm_infoframe *frame,
> >> - const void *buffer, size_t size)
> >> +int hdmi_drm_infoframe_unpack_only(struct hdmi_drm_infoframe *frame,
> >> + const void *buffer, size_t size)
> >> {
> >>const u8 *ptr = buffer;
> >>const u8 *temp;
> >> @@ -1797,23 +1795,13 @@ static int hdmi_drm_infoframe_unpack(struct
> >> hdmi_drm_infoframe *frame,
> >>int ret;
> >>int i;
> >>
> >> - if (size < HDMI_INFOFRAME_SIZE(DRM))
> >> - return -EINVAL;
> >> -
> >> - if (ptr[0] != HDMI_INFOFRAME_TYPE_DRM ||
> >> - ptr[1] != 1 ||
> >> - ptr[2] != HDMI_DRM_INFOFRAME_SIZE)
> >> - return -EINVAL;
> >> -
> >> - if (hdmi_infoframe_checksum(buffer, HDMI_INFOFRAME_SIZE(DRM)) != 0)
> >> + if (size < HDMI_DRM_INFOFRAME_SIZE)
> >>return -EINVAL;
> >>
> >>ret = hdmi_drm_infoframe_init(frame);
> >>if (ret)
> >>return ret;
> >>
> >> - ptr += HDMI_INFOFRAME_HEADER_SIZE;
> >> -
> >>frame->eotf = ptr[0] & 0x7;
> >>frame->metadata_type = ptr[1] & 0x7;
> >>
> >> @@ -1837,6 +1825,42 @@ static int hdmi_drm_infoframe_unpack(struct
> >> hdmi_drm_infoframe *frame,
> >>
> >>return 0;
> >> }
> >> +EXPORT_SYMBOL(hdmi_drm_infoframe_unpack_only);
> >> +
> >> +/**
> >> + * hdmi_drm_infoframe_unpack() - unpack binary buffer to a HDMI DRM
> >> infoframe
> >> + * @frame: HDMI DRM infoframe
> >> + * @buffer: source buffer
> >> + * @size: size of buffer
> >> + *
> >> + * Unpacks the information contained in binary @buffer into a structured
Same here. The difference between the two functions is "information data
block" vs. "information", it's very unclear to the reader without
looking at either the commit message or the implementation.
> >> + * @frame of the HDMI Dynamic Range and Mastering (DRM) information frame.
> >> + * Also verifies the checksum as required by section 5.3.5 of the HDMI 1.4
> >> + * specification.
> >> + *
> >> + * Returns 0 on success or a negative error code on failure.
> >> + */
> >> +static int
Re: [PATCH v3] video: fbdev: arcfb: add missed free_irq and fix the order of request_irq
On 3/10/20 3:30 PM, Chuhong Yuan wrote:
> The driver forgets to free irq in remove which is requested in
> probe.
> Add the missed call to fix it.
> Also, the position of request_irq() in probe should be put before
> register_framebuffer().
>
> Signed-off-by: Chuhong Yuan
> ---
> Changes in v3:
> - Add missed variable par in remove.
>
> drivers/video/fbdev/arcfb.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/fbdev/arcfb.c b/drivers/video/fbdev/arcfb.c
> index 314ab82e01c0..9a720c14056c 100644
> --- a/drivers/video/fbdev/arcfb.c
> +++ b/drivers/video/fbdev/arcfb.c
> @@ -544,10 +544,6 @@ static int arcfb_probe(struct platform_device *dev)
> par->cslut[1] = 0x06;
> info->flags = FBINFO_FLAG_DEFAULT;
> spin_lock_init(>lock);
> - retval = register_framebuffer(info);
> - if (retval < 0)
> - goto err1;
> - platform_set_drvdata(dev, info);
> if (irq) {
> par->irq = irq;
> if (request_irq(par->irq, _interrupt, IRQF_SHARED,
> @@ -558,6 +554,10 @@ static int arcfb_probe(struct platform_device *dev)
> goto err1;
> }
> }
> + retval = register_framebuffer(info);
> + if (retval < 0)
> + goto err1;
> + platform_set_drvdata(dev, info);
> fb_info(info, "Arc frame buffer device, using %dK of video memory\n",
> videomemorysize >> 10);
>
> @@ -590,9 +590,12 @@ static int arcfb_probe(struct platform_device *dev)
> static int arcfb_remove(struct platform_device *dev)
> {
> struct fb_info *info = platform_get_drvdata(dev);
> + struct arcfb_par *par = info->par;
Please look at the line below, 'info' is checked for being NULL so
either 'par = info->par' can dereference NULL pointer or the check is
superfluous and should be removed.
Also there is no need for 'par' variable (it is used only once),
why not simply use info->par->irq in free_irq() call below?
> if (info) {
> unregister_framebuffer(info);
> + if (irq)
> + free_irq(par->irq, info);
> vfree((void __force *)info->screen_base);
> framebuffer_release(info);
> }
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Atomic KMS API lacks the ability to set cursor hot-spot coordinates
On 3/20/20 12:27 PM, Simon Ser wrote: On Friday, March 20, 2020 11:59 AM, Thomas Hellström wrote: On 3/20/20 10:13 AM, Pekka Paalanen wrote: On Thu, 19 Mar 2020 23:57:09 +0100 Thomas Hellström (VMware) thomas...@shipmail.org wrote: Hi, On 3/19/20 10:07 PM, Simon Ser wrote: Is that something that should be done? If the hotspot property also had a "disabled" value, then Weston could set the hotspot to disabled when it is using the cursor plane for non-cursor content and not lose the feature. And of course set hotspot correctly when it in fact is a cursor (but for what input?). I believe cursor planes in the affected virtual gfx-cards do not really have a mode where they can actually be used as a generic overlay plane, certainly not in a useful manner (if anything works it will all be software emulation), implementing a hotspot disabled mode would be tricky and this would needs to be duplicated in all virtual-gfx cards kms drivers. If I understood Daniel's proposal for how to deal with this properly, then only cursor planes which actually need them would get the new hotspot x/y properties. If we do that then Weston could use the presence of the hotspot x/y properties to detect if it is dealing with a proper hw plane which can also be used as a generic plane; or a virtual-gfx cards cursor-plane, and then just not bother with trying to use the plane as a generic hw plane. Would that work? That would need to at least be hidden behind a DRM capability, otherwise it would break existing user-space ignoring the hotspot props (e.g. current Weston). Current Weston is already broken, fixing that is what this whole thread is about. The virtual gfx-cards drivers simply must now the hotspot for things to work; and a capability is not going to help here for 2 reasons: 1. Short of disabling seamless mode there is nothing the virtual gfx-cards drivers can do when clients do not pass the hotspot info; and in some cases they cannot even do this as it is under control of a userspace agent process with its own channel to the hypervisor. 2. Most existing clients which obviously do not set this to-be-introduced capability already pass the hotspot info using the DRM_IOCTL_MODE_CURSOR2 ioctl. Disabling seamless mode when this to-be-introduced capability is not set would cause a huge regression for all these existing clients. Compositors which don't support the hotspot prop are and will continue to break seamless mode. Setting the prop will never be mandatory, because all user-space today doesn't do it. Since we need to update all user-space to add support for this prop, it would be a good idea to recognize user-space that doesn't support it. Doing something sensible with user-space that doesn't support the prop is up to the virtual driver. If we have a capability, the virtual driver could for instance not advertise a cursor plane at all if user-space won't correctly set the hotspot anyway. What compositors do we have around today that wouldn't want to support setting the hotspot correctly? Do we like to keep them that way, and do we want to encourage any new compositors to also not do this properly? All compositors that sometimes want to use cursor planes for non-cursor content. If a cursor plane does not actually have any performance benefits, then somehow userspace would need to know to not use it in that case. Yes, but is that Weston only? Do we know about others? wlroots plans to do the same as Weston. I think the capability is a well-designed solution: a driver that knows the cursor plane will not be always exactly like userspace programs it should not advertise the cursor plane at all if userspace does not set the new cap, and the cap is a promise that userspace will set the hotspot correctly. This cap will not break userspace that uses DRM_IOCTL_MODE_CURSOR2 with correct hotspot info because that is a legacy KMS API and we are talking about atomic here. The legacy ioctl can continue to ignore the new cap. It does mean that if legacy KMS userspace uses the cursor plane for non-cursor content, it keeps being broken for drivers that mangle cursor planes. I can certainly live with that. What I'm afraid of is that people writing compositors will just leave that cap off, ignoring the huge benefit for virtual environments and future kms-based remoting solutions. Couldn't compositors that see hotspot properties on a plane just ignore that plane for other stuff than cursors? KMS clients will need patching anyway to populate the new prop. Enabling a cap is a one-liner. Is the plan to intentionally break KMS clients to force them to add support for the property? We can't do that. As Hans pointed out, some KMS clients are already broken, and hardware planes that doesn't fiddle with the cursor (on which Weston works now) don't have to expose the hotspot properties. This increases the number of things KMS clients need to do in order to correctly work. I
Re: [Intel-gfx] [PATCH v7 05/18] video/hdmi: Add Unpack only function for DRM infoframe
On Fri, 20 Mar 2020, Jani Nikula wrote:
> On Tue, 11 Feb 2020, Gwan-gyeong Mun wrote:
>> It adds an unpack only function for DRM infoframe for dynamic range and
>> mastering infoframe readout.
>> It unpacks the information data block contained in the binary buffer into
>> a structured frame of the HDMI Dynamic Range and Mastering (DRM)
>> information frame.
>>
>> In contrast to hdmi_drm_infoframe_unpack() function, it does not verify
>> a checksum.
>>
>> It can be used for unpacking a DP HDR Metadata Infoframe SDP case.
>> DP HDR Metadata Infoframe SDP uses the same Dynamic Range and Mastering
>> (DRM) information (CTA-861-G spec.) such as HDMI DRM infoframe.
>> But DP SDP header and payload structure are different from HDMI DRM
>> Infoframe. Therefore unpacking DRM infoframe for DP requires skipping of
>> a verifying checksum.
>>
>> Signed-off-by: Gwan-gyeong Mun
>> Reviewed-by: Uma Shankar
>
> Bartlomiej, can I have your ack for merging this via drm-intel along
> with the rest of the series, please?
Or Hans or Laurent, from v4l/video point of view.
Thanks,
Jani.
>
> BR,
> Jani.
>
>
>> ---
>> drivers/video/hdmi.c | 58 +++-
>> include/linux/hdmi.h | 2 ++
>> 2 files changed, 43 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
>> index 9c82e2a0a411..9818836d82b7 100644
>> --- a/drivers/video/hdmi.c
>> +++ b/drivers/video/hdmi.c
>> @@ -1775,20 +1775,18 @@ hdmi_vendor_any_infoframe_unpack(union
>> hdmi_vendor_any_infoframe *frame,
>> }
>>
>> /**
>> - * hdmi_drm_infoframe_unpack() - unpack binary buffer to a HDMI DRM
>> infoframe
>> + * hdmi_drm_infoframe_unpack_only() - unpack binary buffer to a HDMI DRM
>> infoframe
>> * @frame: HDMI DRM infoframe
>> * @buffer: source buffer
>> * @size: size of buffer
>> *
>> - * Unpacks the information contained in binary @buffer into a structured
>> + * Unpacks the information data block contained in binary @buffer into a
>> structured
>> * @frame of the HDMI Dynamic Range and Mastering (DRM) information frame.
>> - * Also verifies the checksum as required by section 5.3.5 of the HDMI 1.4
>> - * specification.
>> *
>> * Returns 0 on success or a negative error code on failure.
>> */
>> -static int hdmi_drm_infoframe_unpack(struct hdmi_drm_infoframe *frame,
>> - const void *buffer, size_t size)
>> +int hdmi_drm_infoframe_unpack_only(struct hdmi_drm_infoframe *frame,
>> + const void *buffer, size_t size)
>> {
>> const u8 *ptr = buffer;
>> const u8 *temp;
>> @@ -1797,23 +1795,13 @@ static int hdmi_drm_infoframe_unpack(struct
>> hdmi_drm_infoframe *frame,
>> int ret;
>> int i;
>>
>> -if (size < HDMI_INFOFRAME_SIZE(DRM))
>> -return -EINVAL;
>> -
>> -if (ptr[0] != HDMI_INFOFRAME_TYPE_DRM ||
>> -ptr[1] != 1 ||
>> -ptr[2] != HDMI_DRM_INFOFRAME_SIZE)
>> -return -EINVAL;
>> -
>> -if (hdmi_infoframe_checksum(buffer, HDMI_INFOFRAME_SIZE(DRM)) != 0)
>> +if (size < HDMI_DRM_INFOFRAME_SIZE)
>> return -EINVAL;
>>
>> ret = hdmi_drm_infoframe_init(frame);
>> if (ret)
>> return ret;
>>
>> -ptr += HDMI_INFOFRAME_HEADER_SIZE;
>> -
>> frame->eotf = ptr[0] & 0x7;
>> frame->metadata_type = ptr[1] & 0x7;
>>
>> @@ -1837,6 +1825,42 @@ static int hdmi_drm_infoframe_unpack(struct
>> hdmi_drm_infoframe *frame,
>>
>> return 0;
>> }
>> +EXPORT_SYMBOL(hdmi_drm_infoframe_unpack_only);
>> +
>> +/**
>> + * hdmi_drm_infoframe_unpack() - unpack binary buffer to a HDMI DRM
>> infoframe
>> + * @frame: HDMI DRM infoframe
>> + * @buffer: source buffer
>> + * @size: size of buffer
>> + *
>> + * Unpacks the information contained in binary @buffer into a structured
>> + * @frame of the HDMI Dynamic Range and Mastering (DRM) information frame.
>> + * Also verifies the checksum as required by section 5.3.5 of the HDMI 1.4
>> + * specification.
>> + *
>> + * Returns 0 on success or a negative error code on failure.
>> + */
>> +static int hdmi_drm_infoframe_unpack(struct hdmi_drm_infoframe *frame,
>> + const void *buffer, size_t size)
>> +{
>> +const u8 *ptr = buffer;
>> +int ret;
>> +
>> +if (size < HDMI_INFOFRAME_SIZE(DRM))
>> +return -EINVAL;
>> +
>> +if (ptr[0] != HDMI_INFOFRAME_TYPE_DRM ||
>> +ptr[1] != 1 ||
>> +ptr[2] != HDMI_DRM_INFOFRAME_SIZE)
>> +return -EINVAL;
>> +
>> +if (hdmi_infoframe_checksum(buffer, HDMI_INFOFRAME_SIZE(DRM)) != 0)
>> +return -EINVAL;
>> +
>> +ret = hdmi_drm_infoframe_unpack_only(frame, ptr +
>> HDMI_INFOFRAME_HEADER_SIZE,
>> + size - HDMI_INFOFRAME_HEADER_SIZE);
>> +return ret;
>> +}
>>
>> /**
>> * hdmi_infoframe_unpack() - unpack binary buffer to a HDMI infoframe
>> diff --git a/include/linux/hdmi.h
Re: Atomic KMS API lacks the ability to set cursor hot-spot coordinates
On Friday, March 20, 2020 11:59 AM, Thomas Hellström wrote: > On 3/20/20 10:13 AM, Pekka Paalanen wrote: > > > On Thu, 19 Mar 2020 23:57:09 +0100 > > Thomas Hellström (VMware) thomas...@shipmail.org wrote: > > > > > Hi, > > > On 3/19/20 10:07 PM, Simon Ser wrote: > > > > > > > > > > > Is that something that should be done? > > > > > > > > If the hotspot property also had a "disabled" value, then > > > > > > > > Weston could > > > > > > > > set the hotspot to disabled when it is using the cursor plane > > > > > > > > for > > > > > > > > non-cursor content and not lose the feature. And of course set > > > > > > > > hotspot > > > > > > > > correctly when it in fact is a cursor (but for what input?). > > > > > > > > I believe cursor planes in the affected virtual gfx-cards do not > > > > > > > > really have a mode where they can actually be used as a generic > > > > > > > > overlay > > > > > > > > plane, certainly not in a useful manner (if anything works it > > > > > > > > will all > > > > > > > > be software emulation), implementing a hotspot disabled mode > > > > > > > > would be > > > > > > > > tricky and this would needs to be duplicated in all virtual-gfx > > > > > > > > cards > > > > > > > > kms drivers. > > > > > > > > > > > > > > If I understood Daniel's proposal for how to deal with this > > > > > > > properly, > > > > > > > then only cursor planes which actually need them would get the new > > > > > > > hotspot x/y properties. If we do that then Weston could use the > > > > > > > presence of the hotspot x/y properties to detect if it is dealing > > > > > > > with a proper hw plane which can also be used as a generic > > > > > > > plane; or a virtual-gfx cards cursor-plane, and then just not > > > > > > > bother with trying to use the plane as a generic hw plane. > > > > > > > Would that work? > > > > > > > That would need to at least be hidden behind a DRM capability, > > > > > > > otherwise > > > > > > > it would break existing user-space ignoring the hotspot props > > > > > > > (e.g. > > > > > > > current Weston). > > > > > > > Current Weston is already broken, fixing that is what this whole > > > > > > > thread is about. > > > > > > > > > > The virtual gfx-cards drivers simply must now the hotspot for things > > > > > to > > > > > work; and a capability is not going to help here for 2 reasons: > > > > > > > > > > 1. Short of disabling seamless mode there is nothing the virtual > > > > > gfx-cards drivers can do when clients do not pass the hotspot > > > > > info; > > > > > and in some cases they cannot even do this as it is under control > > > > > of a userspace agent process with its own channel to the > > > > > hypervisor. > > > > > > > > > > 2. Most existing clients which obviously do not set this > > > > > to-be-introduced > > > > > capability already pass the hotspot info using the > > > > > DRM_IOCTL_MODE_CURSOR2 > > > > > ioctl. Disabling seamless mode when this to-be-introduced > > > > > capability is > > > > > not set would cause a huge regression for all these existing > > > > > clients. > > > > > Compositors which don't support the hotspot prop are and will > > > > > continue to break > > > > > seamless mode. Setting the prop will never be mandatory, because > > > > > all user-space > > > > > today doesn't do it. > > > > > > > > > > > > > Since we need to update all user-space to add support for this prop, it > > > > would > > > > be a good idea to recognize user-space that doesn't support it. Doing > > > > something > > > > sensible with user-space that doesn't support the prop is up to the > > > > virtual > > > > driver. > > > > If we have a capability, the virtual driver could for instance not > > > > advertise a > > > > cursor plane at all if user-space won't correctly set the hotspot > > > > anyway. > > > > What compositors do we have around today that wouldn't want to support > > > > setting the hotspot correctly? Do we like to keep them that way, and do > > > > we want to encourage any new compositors to also not do this properly? > > > > All compositors that sometimes want to use cursor planes for non-cursor > > > > content. If a cursor plane does not actually have any performance > > > > benefits, then somehow userspace would need to know to not use it in > > > > that case. > > Yes, but is that Weston only? Do we know about others? wlroots plans to do the same as Weston. > > I think the capability is a well-designed solution: a driver that > > knows the cursor plane will not be always exactly like userspace > > programs it should not advertise the cursor plane at all if userspace > > does not set the new cap, and the cap is a promise that userspace will > > set the hotspot correctly. > > This cap will not break userspace that uses DRM_IOCTL_MODE_CURSOR2 with > > correct hotspot info because that is a legacy KMS API and we are > > talking about atomic here. The legacy ioctl can continue to ignore the > > new
Re: [Intel-gfx] [PATCH v7 05/18] video/hdmi: Add Unpack only function for DRM infoframe
On Tue, 11 Feb 2020, Gwan-gyeong Mun wrote:
> It adds an unpack only function for DRM infoframe for dynamic range and
> mastering infoframe readout.
> It unpacks the information data block contained in the binary buffer into
> a structured frame of the HDMI Dynamic Range and Mastering (DRM)
> information frame.
>
> In contrast to hdmi_drm_infoframe_unpack() function, it does not verify
> a checksum.
>
> It can be used for unpacking a DP HDR Metadata Infoframe SDP case.
> DP HDR Metadata Infoframe SDP uses the same Dynamic Range and Mastering
> (DRM) information (CTA-861-G spec.) such as HDMI DRM infoframe.
> But DP SDP header and payload structure are different from HDMI DRM
> Infoframe. Therefore unpacking DRM infoframe for DP requires skipping of
> a verifying checksum.
>
> Signed-off-by: Gwan-gyeong Mun
> Reviewed-by: Uma Shankar
Bartlomiej, can I have your ack for merging this via drm-intel along
with the rest of the series, please?
BR,
Jani.
> ---
> drivers/video/hdmi.c | 58 +++-
> include/linux/hdmi.h | 2 ++
> 2 files changed, 43 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index 9c82e2a0a411..9818836d82b7 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -1775,20 +1775,18 @@ hdmi_vendor_any_infoframe_unpack(union
> hdmi_vendor_any_infoframe *frame,
> }
>
> /**
> - * hdmi_drm_infoframe_unpack() - unpack binary buffer to a HDMI DRM infoframe
> + * hdmi_drm_infoframe_unpack_only() - unpack binary buffer to a HDMI DRM
> infoframe
> * @frame: HDMI DRM infoframe
> * @buffer: source buffer
> * @size: size of buffer
> *
> - * Unpacks the information contained in binary @buffer into a structured
> + * Unpacks the information data block contained in binary @buffer into a
> structured
> * @frame of the HDMI Dynamic Range and Mastering (DRM) information frame.
> - * Also verifies the checksum as required by section 5.3.5 of the HDMI 1.4
> - * specification.
> *
> * Returns 0 on success or a negative error code on failure.
> */
> -static int hdmi_drm_infoframe_unpack(struct hdmi_drm_infoframe *frame,
> - const void *buffer, size_t size)
> +int hdmi_drm_infoframe_unpack_only(struct hdmi_drm_infoframe *frame,
> +const void *buffer, size_t size)
> {
> const u8 *ptr = buffer;
> const u8 *temp;
> @@ -1797,23 +1795,13 @@ static int hdmi_drm_infoframe_unpack(struct
> hdmi_drm_infoframe *frame,
> int ret;
> int i;
>
> - if (size < HDMI_INFOFRAME_SIZE(DRM))
> - return -EINVAL;
> -
> - if (ptr[0] != HDMI_INFOFRAME_TYPE_DRM ||
> - ptr[1] != 1 ||
> - ptr[2] != HDMI_DRM_INFOFRAME_SIZE)
> - return -EINVAL;
> -
> - if (hdmi_infoframe_checksum(buffer, HDMI_INFOFRAME_SIZE(DRM)) != 0)
> + if (size < HDMI_DRM_INFOFRAME_SIZE)
> return -EINVAL;
>
> ret = hdmi_drm_infoframe_init(frame);
> if (ret)
> return ret;
>
> - ptr += HDMI_INFOFRAME_HEADER_SIZE;
> -
> frame->eotf = ptr[0] & 0x7;
> frame->metadata_type = ptr[1] & 0x7;
>
> @@ -1837,6 +1825,42 @@ static int hdmi_drm_infoframe_unpack(struct
> hdmi_drm_infoframe *frame,
>
> return 0;
> }
> +EXPORT_SYMBOL(hdmi_drm_infoframe_unpack_only);
> +
> +/**
> + * hdmi_drm_infoframe_unpack() - unpack binary buffer to a HDMI DRM infoframe
> + * @frame: HDMI DRM infoframe
> + * @buffer: source buffer
> + * @size: size of buffer
> + *
> + * Unpacks the information contained in binary @buffer into a structured
> + * @frame of the HDMI Dynamic Range and Mastering (DRM) information frame.
> + * Also verifies the checksum as required by section 5.3.5 of the HDMI 1.4
> + * specification.
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +static int hdmi_drm_infoframe_unpack(struct hdmi_drm_infoframe *frame,
> + const void *buffer, size_t size)
> +{
> + const u8 *ptr = buffer;
> + int ret;
> +
> + if (size < HDMI_INFOFRAME_SIZE(DRM))
> + return -EINVAL;
> +
> + if (ptr[0] != HDMI_INFOFRAME_TYPE_DRM ||
> + ptr[1] != 1 ||
> + ptr[2] != HDMI_DRM_INFOFRAME_SIZE)
> + return -EINVAL;
> +
> + if (hdmi_infoframe_checksum(buffer, HDMI_INFOFRAME_SIZE(DRM)) != 0)
> + return -EINVAL;
> +
> + ret = hdmi_drm_infoframe_unpack_only(frame, ptr +
> HDMI_INFOFRAME_HEADER_SIZE,
> + size - HDMI_INFOFRAME_HEADER_SIZE);
> + return ret;
> +}
>
> /**
> * hdmi_infoframe_unpack() - unpack binary buffer to a HDMI infoframe
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index 9918a6c910c5..afb43efc03e0 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -219,6 +219,8 @@ ssize_t hdmi_drm_infoframe_pack(struct hdmi_drm_infoframe
> *frame, void *buffer,
>
Re: Atomic KMS API lacks the ability to set cursor hot-spot coordinates
On 3/20/20 10:13 AM, Pekka Paalanen wrote: On Thu, 19 Mar 2020 23:57:09 +0100 Thomas Hellström (VMware) wrote: Hi, On 3/19/20 10:07 PM, Simon Ser wrote: Is that something that should be done? If the hotspot property also had a "disabled" value, then Weston could set the hotspot to disabled when it is using the cursor plane for non-cursor content and not lose the feature. And of course set hotspot correctly when it in fact is a cursor (but for what input?). I believe cursor planes in the affected virtual gfx-cards do not really have a mode where they can actually be used as a generic overlay plane, certainly not in a useful manner (if anything works it will all be software emulation), implementing a hotspot disabled mode would be tricky and this would needs to be duplicated in all virtual-gfx cards kms drivers. If I understood Daniel's proposal for how to deal with this properly, then only cursor planes which actually need them would get the new hotspot x/y properties. If we do that then Weston could use the presence of the hotspot x/y properties to detect if it is dealing with a proper hw plane which can also be used as a generic plane; or a virtual-gfx cards cursor-plane, and then just not bother with trying to use the plane as a generic hw plane. Would that work? That would need to at least be hidden behind a DRM capability, otherwise it would break existing user-space ignoring the hotspot props (e.g. current Weston). Current Weston is already broken, fixing that is what this whole thread is about. The virtual gfx-cards drivers simply must now the hotspot for things to work; and a capability is not going to help here for 2 reasons: 1) Short of disabling seamless mode there is nothing the virtual gfx-cards drivers can do when clients do not pass the hotspot info; and in some cases they cannot even do this as it is under control of a userspace agent process with its own channel to the hypervisor. 2) Most existing clients which obviously do not set this to-be-introduced capability already pass the hotspot info using the DRM_IOCTL_MODE_CURSOR2 ioctl. Disabling seamless mode when this to-be-introduced capability is not set would cause a huge regression for all these existing clients. Compositors which don't support the hotspot prop are and will continue to break seamless mode. Setting the prop will never be mandatory, because all user-space today doesn't do it. Since we need to update all user-space to add support for this prop, it would be a good idea to recognize user-space that doesn't support it. Doing something sensible with user-space that doesn't support the prop is up to the virtual driver. If we have a capability, the virtual driver could for instance not advertise a cursor plane at all if user-space won't correctly set the hotspot anyway. What compositors do we have around today that wouldn't want to support setting the hotspot correctly? Do we like to keep them that way, and do we want to encourage any new compositors to also not do this properly? All compositors that sometimes want to use cursor planes for non-cursor content. If a cursor plane does not actually have any performance benefits, then somehow userspace would need to know to not use it in that case. Yes, but is that Weston only? Do we know about others? I think the capability is a well-designed solution: a driver that knows the cursor plane will not be always exactly like userspace programs it should not advertise the cursor plane at all if userspace does not set the new cap, and the cap is a promise that userspace will set the hotspot correctly. This cap will not break userspace that uses DRM_IOCTL_MODE_CURSOR2 with correct hotspot info because that is a legacy KMS API and we are talking about atomic here. The legacy ioctl can continue to ignore the new cap. It does mean that if legacy KMS userspace uses the cursor plane for non-cursor content, it keeps being broken for drivers that mangle cursor planes. I can certainly live with that. What I'm afraid of is that people writing compositors will just leave that cap off, ignoring the huge benefit for virtual environments and future kms-based remoting solutions. Couldn't compositors that see hotspot properties on a plane just ignore that plane for other stuff than cursors? It seems people are also forgetting the problem of associating the cursor plane with an input device, so that whatever is looking to mangle the cursor plane behind the KMS app's back would know how to do it right. My first thought for that is a new cursor plane property with the value of major, minor of the kernel input device that userspace is using to control the cursor plane. This property should be set by userspace only when there is exactly one kernel input device it uses for controlling the cursor plane. Setting this property to none/disabled would be a clear indication that "seamless mode" would be unwanted. The DRM driver or whatever it talks to could then check if the
Re: [PATCH v2 3/5] drm: panel: add Xingbangda XBD599 panel
So following up on this: We should state in the commit message that this driver is for all displays using the Sitronix ST770x display controllers. The driver should be named panel-sitronix-st770x.c. On Thu, Mar 19, 2020 at 3:08 PM Linus Walleij wrote: > > +/* Manufacturer specific Commands send via DSI */ > > +#define ST7703_CMD_ALL_PIXEL_OFF 0x22 > > +#define ST7703_CMD_ALL_PIXEL_ON 0x23 > > +#define ST7703_CMD_SETDISP 0xB2 > > +#define ST7703_CMD_SETRGBIF 0xB3 > > +#define ST7703_CMD_SETCYC 0xB4 > > +#define ST7703_CMD_SETBGP 0xB5 > > +#define ST7703_CMD_SETVCOM 0xB6 > > +#define ST7703_CMD_SETOTP 0xB7 > > +#define ST7703_CMD_SETPOWER_EXT 0xB8 > > +#define ST7703_CMD_SETEXTC 0xB9 > > +#define ST7703_CMD_SETMIPI 0xBA > > +#define ST7703_CMD_SETVDC 0xBC > > +#define ST7703_CMD_SETSCR 0xC0 > > +#define ST7703_CMD_SETPOWER 0xC1 > > +#define ST7703_CMD_UNK_C6 0xC6 > > +#define ST7703_CMD_SETPANEL 0xCC > > +#define ST7703_CMD_SETGAMMA 0xE0 > > +#define ST7703_CMD_SETEQ0xE3 > > +#define ST7703_CMD_SETGIP1 0xE9 > > +#define ST7703_CMD_SETGIP2 0xEA I should have seen the ST7703 prefix shouldn't I... > This actually looks very much like an Ilitek display controller. > Some commands are clearly identical to Ilitek ILI9342: > http://www.ampdisplay.com/documents/pdf/ILI9342_DS_V008_20100331.pdf I'm still wondering about the apparent similarity between ST770x and Ilitek ILI9342, haha :D > 1. Try to determine what the actual display controller > is. I think it is some Ilitek. OK so this is Sitronix ST770x. > 2. Write a panel-ilitek-ili9342.c (if that is the actual controller) > and parameterize it for this display controller the same > way we do in e.g. panel-novatek-nt35510.c or > panel-ilitek-ili9322.c, so you use the compatible string > to set up the actual per-display settings for this display > controller. This should be panel-sitronix-st770x.c Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Atomic KMS API lacks the ability to set cursor hot-spot coordinates
On Thu, 19 Mar 2020 23:57:09 +0100 Thomas Hellström (VMware) wrote: > Hi, > > On 3/19/20 10:07 PM, Simon Ser wrote: > > Is that something that should be done? > > If the hotspot property also had a "disabled" value, then Weston could > > set the hotspot to disabled when it is using the cursor plane for > > non-cursor content and not lose the feature. And of course set hotspot > > correctly when it in fact is a cursor (but for what input?). > I believe cursor planes in the affected virtual gfx-cards do not > really have a mode where they can actually be used as a generic overlay > plane, certainly not in a useful manner (if anything works it will all > be software emulation), implementing a hotspot disabled mode would be > tricky and this would needs to be duplicated in all virtual-gfx cards > kms drivers. > > If I understood Daniel's proposal for how to deal with this properly, > then only cursor planes which actually need them would get the new > hotspot x/y properties. If we do that then Weston could use the > presence of the hotspot x/y properties to detect if it is dealing > with a proper hw plane which can also be used as a generic > plane; or a virtual-gfx cards cursor-plane, and then just not > bother with trying to use the plane as a generic hw plane. > > Would that work? > >>> That would need to at least be hidden behind a DRM capability, otherwise > >>> it would break existing user-space ignoring the hotspot props (e.g. > >>> current Weston). > >> Current Weston is already broken, fixing that is what this whole > >> thread is about. > >> > >> The virtual gfx-cards drivers simply must now the hotspot for things to > >> work; and a capability is not going to help here for 2 reasons: > >> > >> 1) Short of disabling seamless mode there is nothing the virtual > >> gfx-cards drivers can do when clients do not pass the hotspot info; > >> and in some cases they cannot even do this as it is under control > >> of a userspace agent process with its own channel to the hypervisor. > >> > >> 2) Most existing clients which obviously do not set this to-be-introduced > >> capability already pass the hotspot info using the DRM_IOCTL_MODE_CURSOR2 > >> ioctl. Disabling seamless mode when this to-be-introduced capability is > >> not set would cause a huge regression for all these existing clients. > > Compositors which don't support the hotspot prop are and will continue to > > break > > seamless mode. Setting the prop will never be mandatory, because all > > user-space > > today doesn't do it. > > > > Since we need to update all user-space to add support for this prop, it > > would > > be a good idea to recognize user-space that doesn't support it. Doing > > something > > sensible with user-space that doesn't support the prop is up to the virtual > > driver. > > > > If we have a capability, the virtual driver could for instance not > > advertise a > > cursor plane at all if user-space won't correctly set the hotspot anyway. > > What compositors do we have around today that wouldn't want to support > setting the hotspot correctly? Do we like to keep them that way, and do > we want to encourage any new compositors to also not do this properly? All compositors that sometimes want to use cursor planes for non-cursor content. If a cursor plane does not actually have any performance benefits, then somehow userspace would need to know to not use it in that case. I think the capability is a well-designed solution: a driver that knows the cursor plane will not be always exactly like userspace programs it should not advertise the cursor plane at all if userspace does not set the new cap, and the cap is a promise that userspace will set the hotspot correctly. This cap will not break userspace that uses DRM_IOCTL_MODE_CURSOR2 with correct hotspot info because that is a legacy KMS API and we are talking about atomic here. The legacy ioctl can continue to ignore the new cap. It does mean that if legacy KMS userspace uses the cursor plane for non-cursor content, it keeps being broken for drivers that mangle cursor planes. I can certainly live with that. It seems people are also forgetting the problem of associating the cursor plane with an input device, so that whatever is looking to mangle the cursor plane behind the KMS app's back would know how to do it right. My first thought for that is a new cursor plane property with the value of major, minor of the kernel input device that userspace is using to control the cursor plane. This property should be set by userspace only when there is exactly one kernel input device it uses for controlling the cursor plane. Setting this property to none/disabled would be a clear indication that "seamless mode" would be unwanted. The DRM driver or whatever it talks to could then check if the cursor plane is indeed controlled by the input it so far has only assumed and
Re: [PATCH v2 2/5] dt-bindings: panel: add binding for Xingbangda XBD599 panel
On Fri, Mar 20, 2020 at 9:07 AM Icenowy Zheng wrote: > 于 2020年3月19日 GMT+08:00 下午10:14:27, Linus Walleij > 写到: > >On Mon, Mar 16, 2020 at 2:37 PM Icenowy Zheng wrote: > >As noticed in the review of the driver, this display is very close to > >himax,hx8363. > > > >I think the best is to determin what actual display controller it is, > >I think it is some kind of Ilitek controller since Ilitek ili9342 is > >clearly very similar. > > It's Sitronix ST7703, same as the Librem 5 panel. Heh, I wonder how it comes that it is so similar to Ilitek. I guess I will never understand how the silicon ecosystem works in asia (I did read a lot of Bunnie Huang's articles and hardware hacking book to try to understand...) This file should be named sitronix,st7703.yaml then. According to the code in the Librem 5: https://source.puri.sm/Librem5/linux-next/blob/imx8-current-librem5/drivers/gpu/drm/panel/panel-sitronix-st7701.c The actual name of the display is Techstar ts8550b. And the display controller is st7701, so maybe we should actually name it sitronix,st770x.yaml if there are some sub-variants of st770x? > >properties: > > compatible: > >items: > > - const: xingbangda,xbd599 > > - const: ilitek,ili9342 > > > >Possibly use oneOf and add support for the himax,hx8363 > >already while you're at it. This should at least be: compatible: items: - enum: - xingbangda,xbd599 - himax,hx8363 - techstar,ts8550b - enum: - sitronix,st7701 - sitronix,st7703 So panel nodes using this panel become compatible = "xingbangda,sbd599", "sitronix,st7703" etc. This way it is straight-forward for drivers to identify the panel vendor and display controller. Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Plumbing explicit synchronization through the Linux ecosystem
On 2020-03-19 8:54 p.m., Marek Olšák wrote: > On Thu., Mar. 19, 2020, 06:51 Daniel Vetter, > wrote: >> >> Yeah, this is entirely about the programming model visible to >> userspace. There shouldn't be any impact on the driver's choice of >> a top vs. bottom of the gpu pipeline used for synchronization, >> that's entirely up to what you're hw/driver/scheduler can pull >> off. >> >> Doing a full gfx pipeline flush for shared buffers, when your hw >> can do be, sounds like an issue to me that's not related to this >> here at all. It might be intertwined with amdgpu's special >> interpretation of dma_resv fences though, no idea. We might need to >> revamp all that. But for a userspace client that does nothing fancy >> (no multiple render buffer targets in one bo, or vk style "I write >> to everything all the time, perhaps" stuff) there should be 0 perf >> difference between implicit sync through dma_resv and explicit sync >> through sync_file/syncobj/dma_fence directly. >> >> If there is I'd consider that a bit a driver bug. > > Last time I checked, there was no fence sync in gnome shell and > compiz after an app passes a buffer to it. They are not required (though encouraged) to do that. > So drivers have to invent hacks to work around it and decrease > performance. It's not a driver bug. > > Implicit sync really means that apps and compositors don't sync, so > the driver has to guess when it should sync. Making implicit sync work correctly is ultimately the kernel driver's responsibility. It sounds like radeonsi is having to work around the amdgpu/radeon kernel driver(s) not fully living up to this responsibility. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/2] drm: lima: devfreq and cooling device support
This is my attempt at adding devfreq (and cooling device) support to the lima driver. Test results from a Meson8m2 board: TEST #1: glmark2-es2-drm --off-screen in an infinite loop while cycling through all available frequencies using the userspace governor From : To : 182142857 31875 42500 51000 63750 time(ms) 182142857: 0 1274 1274 1273 1279 5399468 31875: 1274 0 1274 1273 1272 5114700 42500: 1276 1274 0 1272 1271 5122008 51000: 1909 1273 1273 0 636 5274292 * 63750: 640 1272 1272 1273 0 5186796 Total transition : 24834 TEST #2: glmark2-es2-drm --off-screen in an infinite loop with the simple_ondemand governor From : To : 182142857 31875 42500 51000 63750 time(ms) 182142857: 0 0 0 0 203318328 31875:53 0 0 021 56044 42500:2718 0 0 2 34172 51000:27 614 0 1 41348 * 63750:95503348 0 2085312 Changes since RFC v3 at [2]: - fix devfreq init error handling and allow lima_devfreq_fini to be called multiple times (thanks Qiang) - switch from atomic counter to a simple int which is only accessed under the devfreq spinlock (thanks Qiang) - union lock areas in same function (thanks Qiang) - select DEVFREQ_GOV_SIMPLE_ONDEMAND like panfrost does (thanks Qiang) - move lima_devfreq struct to lima_devfreq.h (thanks Qiang) - fix duplicate variable in lima_sched_pipe_task_done - only call dev_pm_opp_of_remove_table if dev_pm_opp_of_add_table succeeded previously - update copyright year to 2020 - rebased on top of drm-misc-next - dropped RFC status Changes since RFC v2 at [1]: - added #cooling-cells to the dt-bindings (new patch #1) - skip devfreq initialization when the operating-points-v2 property is absent - call dev_pm_opp_set_regulators() so devfreq will actually manage the mali-supply regulator - rebased on top of drm-misc-next-2020-02-21 Changes since RFC v1 at [0]: - added lock to protect the statistics as these can be written concurrently for example when the GP and PP IRQ are firing at the same time. Thanks to Qiang Yu for the suggestion! - updated the copyright notice of lima_devfreq.c to indicate that the code is derived from panfrost_devfreq.c. Thanks to Chen-Yu Tsai for the suggestion! - I did not unify the code with panfrost yet because I don't know where to put the result. any suggestion is welcome though! [0] https://patchwork.freedesktop.org/series/70967/ [1] https://patchwork.kernel.org/cover/11311293/ [2] https://patchwork.kernel.org/cover/11398365/ Martin Blumenstingl (2): dt-bindings: gpu: mali-utgard: Add the #cooling-cells property drm/lima: Add optional devfreq and cooling device support .../bindings/gpu/arm,mali-utgard.yaml | 4 + drivers/gpu/drm/lima/Kconfig | 2 + drivers/gpu/drm/lima/Makefile | 3 +- drivers/gpu/drm/lima/lima_devfreq.c | 234 ++ drivers/gpu/drm/lima/lima_devfreq.h | 41 +++ drivers/gpu/drm/lima/lima_device.c| 4 + drivers/gpu/drm/lima/lima_device.h| 3 + drivers/gpu/drm/lima/lima_drv.c | 14 +- drivers/gpu/drm/lima/lima_sched.c | 7 + drivers/gpu/drm/lima/lima_sched.h | 3 + 10 files changed, 312 insertions(+), 3 deletions(-) create mode 100644 drivers/gpu/drm/lima/lima_devfreq.c create mode 100644 drivers/gpu/drm/lima/lima_devfreq.h -- 2.25.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/8] iommu/vt-d: Remove IOVA handling code from non-dma_ops path
On 2020/3/20 14:30, Tom Murphy wrote: Could we merge patch 1-3 from this series? it just cleans up weird code and merging these patches will cover some of the work needed to move the intel iommu driver to the dma-iommu api in the future. Can you please take a look at this patch series? https://lkml.org/lkml/2020/3/13/1162 It probably makes this series easier. Best regards, baolu On Sat, 21 Dec 2019 at 07:04, Tom Murphy wrote: Remove all IOVA handling code from the non-dma_ops path in the intel iommu driver. There's no need for the non-dma_ops path to keep track of IOVAs. The whole point of the non-dma_ops path is that it allows the IOVAs to be handled separately. The IOVA handling code removed in this patch is pointless. Signed-off-by: Tom Murphy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v11 01/12] drm/i915: Use 64-bit division macro
Since the PWM framework is switching struct pwm_state.duty_cycle's datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL to handle a 64-bit dividend. Cc: Jani Nikula Cc: Joonas Lahtinen Cc: David Airlie Cc: Daniel Vetter Cc: Chris Wilson Cc: "Ville Syrjälä" Cc: intel-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Reviewed-by: Jani Nikula Signed-off-by: Guru Das Srinagesh --- drivers/gpu/drm/i915/display/intel_panel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_panel.c b/drivers/gpu/drm/i915/display/intel_panel.c index bc14e9c..843cac1 100644 --- a/drivers/gpu/drm/i915/display/intel_panel.c +++ b/drivers/gpu/drm/i915/display/intel_panel.c @@ -1868,7 +1868,7 @@ static int pwm_setup_backlight(struct intel_connector *connector, panel->backlight.min = 0; /* 0% */ panel->backlight.max = 100; /* 100% */ - panel->backlight.level = DIV_ROUND_UP( + panel->backlight.level = DIV_ROUND_UP_ULL( pwm_get_duty_cycle(panel->backlight.pwm) * 100, CRC_PMIC_PWM_PERIOD_NS); panel->backlight.enabled = panel->backlight.level != 0; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 02/13] mailbox: cmdq: variablize address shift in platform
On Sun, Mar 8, 2020 at 5:53 AM Dennis YC Hsieh wrote: > > Some gce hardware shift pc and end address in register to support > large dram addressing. > Implement gce address shift when write or read pc and end register. > And add shift bit in platform definition. > > Signed-off-by: Dennis YC Hsieh > Reviewed-by: CK Hu > --- > drivers/mailbox/mtk-cmdq-mailbox.c | 61 ++-- > drivers/soc/mediatek/mtk-cmdq-helper.c | 3 +- > include/linux/mailbox/mtk-cmdq-mailbox.h | 2 + > Please segregate this patch, and any other if, into mailbox and platform specific patchsets. Ideally soc/client specific changes later on top of mailbox/provider changes. Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/client: Dual licence the header in GPL-2 and MIT
Source file was dual licenced but the header was omitted, fix that. Contributors for this file are: Daniel Vetter Matt Roper Maxime Ripard Noralf Trønnes Thomas Zimmermann Signed-off-by: Emmanuel Vadot --- include/drm/drm_client.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/drm_client.h b/include/drm/drm_client.h index 3ed5dee899fd..94c9c72c206d 100644 --- a/include/drm/drm_client.h +++ b/include/drm/drm_client.h @@ -1,4 +1,4 @@ -/* SPDX-License-Identifier: GPL-2.0 */ +/* SPDX-License-Identifier: GPL-2.0 or MIT */ #ifndef _DRM_CLIENT_H_ #define _DRM_CLIENT_H_ -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 00/12] Convert PWM period and duty cycle to u64
Because period and duty cycle are defined in the PWM framework structs as ints with units of nanoseconds, the maximum time duration that can be set is limited to ~2.147 seconds. Consequently, applications desiring to set greater time periods via the PWM framework are not be able to do so - like, for instance, causing an LED to blink at an interval of 5 seconds. Redefining the period and duty cycle struct members in the core PWM framework structs as u64 values will enable larger time durations to be set and solve this problem. Such a change to the framework mandates that drivers using these struct members (and corresponding helper functions) also be modified correctly in order to prevent compilation errors. This patch series introduces the changes to all the drivers first, followed by the framework change at the very end so that when the latter is applied, all the drivers are in good shape and there are no compilation errors. Changes from v9: - Gathered the received "Reviewed-by: " tag - Added back the clk-pwm.c patch because kbuild test robot complained [3] and addressed received review comments. - clps711x: Addressed review comments. Changes from v8: - Gathered all received "Acked-by: " and "Reviewed-by: " tags - Dropped patch to clk-pwm.c for reasons mentiond in [2] - Expanded audience of unreviewed patches Changes from v7: - Changed commit messages of all patches to be brief and to the point. - Added explanation of change in cover letter. - Dropped change to pwm-sti.c as upon review it was unnecessary as struct pwm_capture is not being modified in the PWM core. Changes from v6: - Split out the driver changes out into separate patches, one patch per file for ease of reviewing. Changes from v5: - Dropped the conversion of struct pwm_capture to u64 for reasons mentioned in https://www.spinics.net/lists/linux-pwm/msg11541.html Changes from v4: - Split the patch into two: one for changes to the drivers, and the actual switch to u64 for ease of reverting should the need arise. - Re-examined the patch and made the following corrections: * intel_panel.c: DIV64_U64_ROUND_UP -> DIV_ROUND_UP_ULL (as only the numerator would be 64-bit in this case). * pwm-sti.c: do_div -> div_u64 (do_div is optimized only for x86 architectures, and div_u64's comment block suggests to use this as much as possible). Changes from v3: - Rebased to current tip of for-next. Changes from v2: - Fixed %u -> %llu in a dev_dbg in pwm-stm32-lp.c, thanks to kbuild test robot - Added a couple of fixes to pwm-imx-tpm.c and pwm-sifive.c Changes from v1: - Fixed compilation errors seen when compiling for different archs. v1: - Reworked the change pushed upstream earlier [1] so as to not add an extension to an obsolete API. With this change, pwm_ops->apply() can be used to set pwm_state parameters as usual. [1] https://lore.kernel.org/lkml/20190916140048.GB7488@ulmo/ [2] https://lore.kernel.org/lkml/20200312190859.ga19...@codeaurora.org/ [3] https://www.spinics.net/lists/linux-pwm/msg11906.html Guru Das Srinagesh (12): drm/i915: Use 64-bit division macro hwmon: pwm-fan: Use 64-bit division macro ir-rx51: Use 64-bit division macro pwm: clps711x: Cast period to u32 before use as divisor pwm: pwm-imx-tpm: Use 64-bit division macro pwm: imx27: Use 64-bit division macro and function pwm: sifive: Use 64-bit division macro pwm: stm32-lp: Use %llu format specifier for period pwm: sun4i: Use 64-bit division function backlight: pwm_bl: Use 64-bit division function clk: pwm: Assign u64 divisor to unsigned int before use pwm: core: Convert period and duty cycle to u64 drivers/clk/clk-pwm.c | 4 +++- drivers/gpu/drm/i915/display/intel_panel.c | 2 +- drivers/hwmon/pwm-fan.c| 2 +- drivers/media/rc/ir-rx51.c | 3 ++- drivers/pwm/core.c | 4 ++-- drivers/pwm/pwm-clps711x.c | 5 - drivers/pwm/pwm-imx-tpm.c | 2 +- drivers/pwm/pwm-imx27.c| 5 ++--- drivers/pwm/pwm-sifive.c | 2 +- drivers/pwm/pwm-stm32-lp.c | 2 +- drivers/pwm/pwm-sun4i.c| 2 +- drivers/pwm/sysfs.c| 8 drivers/video/backlight/pwm_bl.c | 3 ++- include/linux/pwm.h| 12 ++-- 14 files changed, 31 insertions(+), 25 deletions(-) Cc: Lee Jones Cc: Daniel Thompson Cc: Jingoo Han Cc: Bartlomiej Zolnierkiewicz Cc: linux-fb...@vger.kernel.org Cc: Maxime Ripard Cc: Chen-Yu Tsai Cc: Philipp Zabel Cc: Fabrice Gasnier Cc: Maxime Coquelin Cc: Alexandre Torgue Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: linux-ri...@lists.infradead.org Cc: Yash Shah Cc: Atish Patra Cc: Shawn Guo Cc: Sascha Hauer Cc: Pengutronix Kernel Team Cc: Fabio Estevam Cc: NXP Linux Team Cc: Sascha Hauer
Re: general protection fault in sctp_ulpevent_nofity_peer_addr_change
On Thu, Mar 19, 2020 at 05:48:02PM -0700, syzbot wrote: > syzbot has bisected this bug to: > > commit da2648390ce3d409218b6bbbf2386d8ddeec2265 > Author: Lubomir Rintel > Date: Thu Dec 20 18:13:09 2018 + > > pxa168fb: trivial typo fix Certainly not ;-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: Don't attempt to attach HDMI bridge twice
On Thu 19 Mar 11:19 PDT 2020, Rob Clark wrote:
> On Wed, Mar 18, 2020 at 9:39 PM Bjorn Andersson
> wrote:
> >
> > With the introduction of '3ef2f119bd3e ("drm/msm: Use
> > drm_attach_bridge() to attach a bridge to an encoder")' the HDMI bridge
> > is attached both in msm_hdmi_bridge_init() and later in
> > msm_hdmi_modeset_init().
> >
> > The second attempt fails as the bridge is already attached to the
> > encoder and the whole process is aborted.
> >
> > So instead make msm_hdmi_bridge_init() just initialize the hdmi_bridge
> > object and let msm_hdmi_modeset_init() attach it later.
> >
> > Fixes: 3ef2f119bd3e ("drm/msm: Use drm_attach_bridge() to attach a bridge
> > to an encoder")
> > Signed-off-by: Bjorn Andersson
>
> Thanks, I think this should also be solved by:
>
> https://patchwork.freedesktop.org/patch/357331/?series=74611=1
Yes, didn't find that when looking yesterday. T-b and R-b.
Thanks,
Bjorn
>
> BR,
> -R
>
> > ---
> > drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 19 +++
> > 1 file changed, 3 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
> > b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
> > index 6e380db9287b..0e103ee1b730 100644
> > --- a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
> > +++ b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
> > @@ -271,31 +271,18 @@ static const struct drm_bridge_funcs
> > msm_hdmi_bridge_funcs = {
> > /* initialize bridge */
> > struct drm_bridge *msm_hdmi_bridge_init(struct hdmi *hdmi)
> > {
> > - struct drm_bridge *bridge = NULL;
> > struct hdmi_bridge *hdmi_bridge;
> > - int ret;
> > + struct drm_bridge *bridge;
> >
> > hdmi_bridge = devm_kzalloc(hdmi->dev->dev,
> > sizeof(*hdmi_bridge), GFP_KERNEL);
> > - if (!hdmi_bridge) {
> > - ret = -ENOMEM;
> > - goto fail;
> > - }
> > + if (!hdmi_bridge)
> > + return ERR_PTR(-ENOMEM);
> >
> > hdmi_bridge->hdmi = hdmi;
> >
> > bridge = _bridge->base;
> > bridge->funcs = _hdmi_bridge_funcs;
> >
> > - ret = drm_bridge_attach(hdmi->encoder, bridge, NULL, 0);
> > - if (ret)
> > - goto fail;
> > -
> > return bridge;
> > -
> > -fail:
> > - if (bridge)
> > - msm_hdmi_bridge_destroy(bridge);
> > -
> > - return ERR_PTR(ret);
> > }
> > --
> > 2.24.0
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 1/2] dt-bindings: display: add visionox rm69299 panel variant
Add bindings for visionox rm69299 panel.
Signed-off-by: Harigovindan P
---
Changes in v2:
- Removed unwanted properties from description.
- Creating source files without execute permissions(Rob Herring).
Changes in v3:
- Changing txt file into yaml
Changes in v4:
- Updating license identifier.
- Moving yaml file inside panel directory.
- Removing pinctrl entries.
- Adding documentation for reset-gpios.
Changes in v5:
- No changes. Updated 2/2 Patch.
Changes in v6:
- Removing patternProperties.
- Added " |" after description.
- Setting port and reset-gpios to true.
- Removing @ae94000 for dsi node.
Changes in v7:
- Added reg property.
Changes in v8:
- Rearranged additionalProperties.
- Dropping improper reg property.
.../display/panel/visionox,rm69299.yaml | 73 +++
1 file changed, 73 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml
b/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml
new file mode 100644
index ..5fd277602a66
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/visionox,rm69299.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Visionox model RM69299 Panels Device Tree Bindings.
+
+maintainers:
+ - Harigovindan P
+
+description: |
+ This binding is for display panels using a Visionox RM692999 panel.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: visionox,rm69299-1080p-display
+
+ reg:
+maxItems: 1
+
+ vdda-supply:
+description: |
+ Phandle of the regulator that provides the vdda supply voltage.
+
+ vdd3p3-supply:
+description: |
+ Phandle of the regulator that provides the vdd3p3 supply voltage.
+
+ ports:
+type: object
+description: |
+ A node containing DSI input & output port nodes with endpoint
+ definitions as documented in
+ Documentation/devicetree/bindings/media/video-interfaces.txt
+ Documentation/devicetree/bindings/graph.txt
+ properties:
+port: true
+
+ reset-gpios: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - vdda-supply
+ - vdd3p3-supply
+ - reset-gpios
+
+examples:
+ - |
+panel {
+compatible = "visionox,rm69299-1080p-display";
+
+vdda-supply = <_pp1800_l8c>;
+vdd3p3-supply = <_pp2800_l18a>;
+
+reset-gpios = <_gpio 3 0>;
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+port@0 {
+reg = <0>;
+panel0_in: endpoint {
+remote-endpoint = <_out>;
+};
+};
+};
+};
+...
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] drm/sun4i: sun6i_mipi_dsi: fix horizontal timing calculation
Hi, On Mon, Mar 16, 2020 at 09:35:02PM +0800, Icenowy Zheng wrote: > The max() function call in horizontal timing calculation shouldn't pad a > length already subtracted with overhead to overhead, instead it should > only prevent the set timing to underflow. Some explanation on why it shouldn't do that would be appreciated. Also, with the changes you have below, the comments above each max call don't match anymore and should be updated. Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: ensure device private pages have an owner v2
On Thu, Mar 19, 2020 at 08:16:33AM +0100, Christoph Hellwig wrote: > On Wed, Mar 18, 2020 at 09:28:49PM -0300, Jason Gunthorpe wrote: > > > Changes since v1: > > > - split out the pgmap->owner addition into a separate patch > > > - check pgmap->owner is set for device private mappings > > > - rename the dev_private_owner field in struct migrate_vma to src_owner > > > - refuse to migrate private pages if src_owner is not set > > > - keep the non-fault device private handling in hmm_range_fault > > > > I'm happy enough to take this, did you have plans for a v3? > > I think the only open question is if merging 3 and 4 might make sense. > It's up to you if you want it resent that way or not. Okay, I kept it as is and elaborated the commit messages a bit based on the discussion It doesn't seem like the changes outside hmm are significant enough to need more acks Thanks, Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/3] dt-bindings: display: drop data-mapping from panel-dpi
On Tue, Mar 17, 2020 at 12:22:31PM +0100, Sam Ravnborg wrote: > Hi Maxime. > > On Tue, Mar 17, 2020 at 09:49:59AM +0100, Maxime Ripard wrote: > > Hi Sam, > > > > On Sat, Mar 14, 2020 at 04:30:45PM +0100, Sam Ravnborg wrote: > > > data-mapping may not be the best way to describe the > > > data format used between panels and display interface. > > > > > > Drop it from the panel-dpi binding so we do not start to rely on it. > > > We can then work out how to best describe this mapping and when > > > we know it, we can add it to this binding. > > > > > > Signed-off-by: Sam Ravnborg > > > Cc: Laurent Pinchart > > > Cc: Maxime Ripard > > > Cc: Rob Herring > > > > I can't say whether it's the right decision or not, but if you want to > > go forward with this, you should maintain the backward compatibility, > > so leave the code to deal with this as a fallback solution... > > This was all introduced very recently and is for now only present in > drm-misc-next. > The idea was to revert is *before* people started to rely on this new > mapping. So we avoid all the backward compatibility fun. > I had hoped the revert could land before the 5.7 pull, alas that was not > the case. My bad, it works for me then :) Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 01/12] drm/i915: Use 64-bit division macro
Since the PWM framework is switching struct pwm_state.duty_cycle's datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL to handle a 64-bit dividend. Cc: Jani Nikula Cc: Joonas Lahtinen Cc: David Airlie Cc: Daniel Vetter Cc: Chris Wilson Cc: "Ville Syrjälä" Cc: intel-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Reviewed-by: Jani Nikula Signed-off-by: Guru Das Srinagesh --- drivers/gpu/drm/i915/display/intel_panel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_panel.c b/drivers/gpu/drm/i915/display/intel_panel.c index bc14e9c..843cac1 100644 --- a/drivers/gpu/drm/i915/display/intel_panel.c +++ b/drivers/gpu/drm/i915/display/intel_panel.c @@ -1868,7 +1868,7 @@ static int pwm_setup_backlight(struct intel_connector *connector, panel->backlight.min = 0; /* 0% */ panel->backlight.max = 100; /* 100% */ - panel->backlight.level = DIV_ROUND_UP( + panel->backlight.level = DIV_ROUND_UP_ULL( pwm_get_duty_cycle(panel->backlight.pwm) * 100, CRC_PMIC_PWM_PERIOD_NS); panel->backlight.enabled = panel->backlight.level != 0; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 10/17] drm/vram-helper: make drm_vram_mm_debugfs_init() return 0
On Thu, 19 Mar 2020, Daniel Vetter wrote:
On Thu, Mar 19, 2020 at 08:55:24AM +0100, Greg KH wrote:
On Wed, Mar 18, 2020 at 08:10:43PM +0100, Daniel Vetter wrote:
On Wed, Mar 18, 2020 at 5:58 PM Greg KH wrote:
On Wed, Mar 18, 2020 at 05:31:47PM +0100, Daniel Vetter wrote:
On Wed, Mar 18, 2020 at 5:03 PM Wambui Karuga wrote:
On Wed, 18 Mar 2020, Daniel Vetter wrote:
On Tue, Mar 10, 2020 at 04:31:14PM +0300, Wambui Karuga wrote:
Since 987d65d01356 (drm: debugfs: make
drm_debugfs_create_files() never fail), drm_debugfs_create_files() never
fails and should return void. Therefore, remove its use as the
return value of drm_vram_mm_debugfs_init(), and have the function
return 0 directly.
v2: have drm_vram_mm_debugfs_init() return 0 instead of void to avoid
introducing build issues and build breakage.
References:
https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.html
Signed-off-by: Wambui Karuga
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 92a11bb42365..c8bcc8609650 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -1048,14 +1048,12 @@ static const struct drm_info_list
drm_vram_mm_debugfs_list[] = {
*/
int drm_vram_mm_debugfs_init(struct drm_minor *minor)
{
-int ret = 0;
-
#if defined(CONFIG_DEBUG_FS)
Just noticed that this #if here is not needed, we already have a dummy
function for that case. Care to write a quick patch to remove it? On top
of this patch series here ofc, I'm in the processing of merging the entire
pile.
Thanks, Daniel
Hi Daniel,
Without this check here, and compiling without CONFIG_DEBUG_FS, this
function is run and the drm_debugfs_create_files() does not have access to
the parameters also protected by an #if above this function. So the change
throws an error for me. Is that correct?
Hm right. Other drivers don't #ifdef out their debugfs file functions
... kinda a bit disappointing that we can't do this in the neatest way
possible.
Greg, has anyone ever suggested to convert the debugfs_create_file
function (and similar things) to macros that don't use any of the
arguments, and then also annotating all the static functions/tables as
__maybe_unused and let the compiler garbage collect everything?
Instead of explicit #ifdef in all the drivers ...
No, no one has suggested that, having the functions be static inline
should make it all "just work" properly if debugfs is not enabled. The
variables will not be used, so the compiler should just optimize them
away properly.
No checks for CONFIG_DEBUG_FS should be needed anywhere in .c code.
So the trouble with this one is that the static inline functions for
the debugfs file are wrapped in a #if too, and hence if we drop the
#if around the function call stuff won't compile. Should we drop all
the #if in the .c file and assume the compiler will remove all the
dead code and dead functions?
Yes you should :)
there should not be any need for #if in a .c file for debugfs stuff.
Wambui, can you pls try that out? I.e. removing all the #if for
CONFIG_DEBUG_FS from that file.
Removing them works with CONFIG_DEBUG_FS enabled or disabled.
I can send a patch for that.
wambui karuga
-Daniel
--
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/msm: avoid double-attaching hdmi/edp bridges
On Wed 11 Mar 20:51 PDT 2020, Ilia Mirkin wrote: > Each of hdmi and edp are already attached in msm_*_bridge_init. A second > attachment returns -EBUSY, failing the driver load. > > Tested with HDMI on IFC6410 (APQ8064 / MDP4), but eDP case should be > analogous. > > Fixes: 3ef2f119bd3ed (drm/msm: Use drm_attach_bridge() to attach a bridge to > an encoder) > Cc: Boris Brezillon > Signed-off-by: Ilia Mirkin Had to manually apply this, as the drm_bridge_attach() prototype changed since this patch was written - but this was trivial. This is needed on db820c as well. Tested-by: Bjorn Andersson (hdmi part) Reviewed-by: Bjorn Andersson Regards, Bjorn > --- > drivers/gpu/drm/msm/edp/edp.c | 4 > drivers/gpu/drm/msm/hdmi/hdmi.c | 4 > 2 files changed, 8 deletions(-) > > diff --git a/drivers/gpu/drm/msm/edp/edp.c b/drivers/gpu/drm/msm/edp/edp.c > index ad4e963ccd9b..106a67473af5 100644 > --- a/drivers/gpu/drm/msm/edp/edp.c > +++ b/drivers/gpu/drm/msm/edp/edp.c > @@ -178,10 +178,6 @@ int msm_edp_modeset_init(struct msm_edp *edp, struct > drm_device *dev, > goto fail; > } > > - ret = drm_bridge_attach(encoder, edp->bridge, NULL); > - if (ret) > - goto fail; > - > priv->bridges[priv->num_bridges++] = edp->bridge; > priv->connectors[priv->num_connectors++] = edp->connector; > > diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c > index 1a9b6289637d..737453b6e596 100644 > --- a/drivers/gpu/drm/msm/hdmi/hdmi.c > +++ b/drivers/gpu/drm/msm/hdmi/hdmi.c > @@ -327,10 +327,6 @@ int msm_hdmi_modeset_init(struct hdmi *hdmi, > goto fail; > } > > - ret = drm_bridge_attach(encoder, hdmi->bridge, NULL); > - if (ret) > - goto fail; > - > priv->bridges[priv->num_bridges++] = hdmi->bridge; > priv->connectors[priv->num_connectors++] = hdmi->connector; > > -- > 2.24.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm: Align a comment block
Fix a checkpatch warning caused by a misaligned comment block.
Signed-off-by: Igor Matheus Andrade Torrente
---
Changes in v2:
- Change subject text
Changes in V3
- Fix a typo in the commit message
drivers/gpu/drm/drm_gem.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index a9e4a610445a..564acc1f4030 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -222,10 +222,10 @@ drm_gem_object_handle_put_unlocked(struct drm_gem_object
*obj)
return;
/*
- * Must bump handle count first as this may be the last
- * ref, in which case the object would disappear before we
- * checked for a name
- */
+* Must bump handle count first as this may be the last
+* ref, in which case the object would disappear before we
+* checked for a name
+*/
mutex_lock(>object_name_lock);
if (--obj->handle_count == 0) {
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 01/11] drm/i915: Use 64-bit division macro
On Wed, Mar 18, 2020 at 09:08:45PM +0200, Jani Nikula wrote: > On Tue, 17 Mar 2020, Guru Das Srinagesh wrote: > > Since the PWM framework is switching struct pwm_state.duty_cycle's > > datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL > > to handle a 64-bit dividend. > > > > Cc: Jani Nikula > > Cc: Joonas Lahtinen > > Cc: David Airlie > > Cc: Daniel Vetter > > Cc: Chris Wilson > > Cc: "Ville Syrjälä" > > Cc: intel-...@lists.freedesktop.org > > Cc: dri-devel@lists.freedesktop.org > > Cc: Rodrigo Vivi > > Cc: Maarten Lankhorst > > > > Signed-off-by: Guru Das Srinagesh > > Reviewed-by: Jani Nikula Thanks! > Also ack for merging this via whichever tree you prefer; please let me > know if you want me to take this via drm-intel. I'm not sure if this patch can be taken via drm-intel in isolation as it is part of a series... Will let you know if I need to make such a request. Thank you. Guru Das. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/8] Convert the intel iommu driver to the dma-iommu api
Any news on this? Is there anyone who wants to try and fix this possible bug? On Mon, 23 Dec 2019 at 03:41, Jani Nikula wrote: > > On Mon, 23 Dec 2019, Robin Murphy wrote: > > On 2019-12-23 10:37 am, Jani Nikula wrote: > >> On Sat, 21 Dec 2019, Tom Murphy wrote: > >>> This patchset converts the intel iommu driver to the dma-iommu api. > >>> > >>> While converting the driver I exposed a bug in the intel i915 driver > >>> which causes a huge amount of artifacts on the screen of my > >>> laptop. You can see a picture of it here: > >>> https://github.com/pippy360/kernelPatches/blob/master/IMG_20191219_225922.jpg > >>> > >>> This issue is most likely in the i915 driver and is most likely caused > >>> by the driver not respecting the return value of the > >>> dma_map_ops::map_sg function. You can see the driver ignoring the > >>> return value here: > >>> https://github.com/torvalds/linux/blob/7e0165b2f1a912a06e381e91f0f4e495f4ac3736/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c#L51 > >>> > >>> Previously this didn’t cause issues because the intel map_sg always > >>> returned the same number of elements as the input scatter gather list > >>> but with the change to this dma-iommu api this is no longer the > >>> case. I wasn’t able to track the bug down to a specific line of code > >>> unfortunately. > >>> > >>> Could someone from the intel team look at this? > >> > >> Let me get this straight. There is current API that on success always > >> returns the same number of elements as the input scatter gather > >> list. You propose to change the API so that this is no longer the case? > > > > No, the API for dma_map_sg() has always been that it may return fewer > > DMA segments than nents - see Documentation/DMA-API.txt (and otherwise, > > the return value would surely be a simple success/fail condition). > > Relying on a particular implementation behaviour has never been strictly > > correct, even if it does happen to be a very common behaviour. > > > >> A quick check of various dma_map_sg() calls in the kernel seems to > >> indicate checking for 0 for errors and then ignoring the non-zero return > >> is a common pattern. Are you sure it's okay to make the change you're > >> proposing? > > > > Various code uses tricks like just iterating the mapped list until the > > first segment with zero sg_dma_len(). Others may well simply have bugs. > > Thanks for the clarification. > > BR, > Jani. > > > > > Robin. > > > >> Anyway, due to the time of year and all, I'd like to ask you to file a > >> bug against i915 at [1] so this is not forgotten, and please let's not > >> merge the changes before this is resolved. > >> > >> > >> Thanks, > >> Jani. > >> > >> > >> [1] https://gitlab.freedesktop.org/drm/intel/issues/new > >> > >> > > -- > 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 v4 2/2] drm/lima: Add optional devfreq and cooling device support
Most platforms with a Mali-400 or Mali-450 GPU also have support for
changing the GPU clock frequency. Add devfreq support so the GPU clock
rate is updated based on the actual GPU usage when the
"operating-points-v2" property is present in the board.dts.
The actual devfreq code is taken from panfrost_devfreq.c and modified so
it matches what the lima hardware needs:
- a call to dev_pm_opp_set_clkname() during initialization because there
are two clocks on Mali-4x0 IPs. "core" is the one that actually clocks
the GPU so we need to control it using devfreq.
- locking when reading or writing the devfreq statistics because (unlike
than panfrost) we have multiple PP and GP IRQs which may finish jobs
concurrently.
Signed-off-by: Martin Blumenstingl
---
drivers/gpu/drm/lima/Kconfig| 2 +
drivers/gpu/drm/lima/Makefile | 3 +-
drivers/gpu/drm/lima/lima_devfreq.c | 234
drivers/gpu/drm/lima/lima_devfreq.h | 41 +
drivers/gpu/drm/lima/lima_device.c | 4 +
drivers/gpu/drm/lima/lima_device.h | 3 +
drivers/gpu/drm/lima/lima_drv.c | 14 +-
drivers/gpu/drm/lima/lima_sched.c | 7 +
drivers/gpu/drm/lima/lima_sched.h | 3 +
9 files changed, 308 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/lima/lima_devfreq.c
create mode 100644 drivers/gpu/drm/lima/lima_devfreq.h
diff --git a/drivers/gpu/drm/lima/Kconfig b/drivers/gpu/drm/lima/Kconfig
index d589f09d04d9..fa1d4f5df31e 100644
--- a/drivers/gpu/drm/lima/Kconfig
+++ b/drivers/gpu/drm/lima/Kconfig
@@ -10,5 +10,7 @@ config DRM_LIMA
depends on OF
select DRM_SCHED
select DRM_GEM_SHMEM_HELPER
+ select PM_DEVFREQ
+ select DEVFREQ_GOV_SIMPLE_ONDEMAND
help
DRM driver for ARM Mali 400/450 GPUs.
diff --git a/drivers/gpu/drm/lima/Makefile b/drivers/gpu/drm/lima/Makefile
index a85444b0a1d4..5e5c29875e9c 100644
--- a/drivers/gpu/drm/lima/Makefile
+++ b/drivers/gpu/drm/lima/Makefile
@@ -14,6 +14,7 @@ lima-y := \
lima_sched.o \
lima_ctx.o \
lima_dlbu.o \
- lima_bcast.o
+ lima_bcast.o \
+ lima_devfreq.o
obj-$(CONFIG_DRM_LIMA) += lima.o
diff --git a/drivers/gpu/drm/lima/lima_devfreq.c
b/drivers/gpu/drm/lima/lima_devfreq.c
new file mode 100644
index ..8c4d21d07529
--- /dev/null
+++ b/drivers/gpu/drm/lima/lima_devfreq.c
@@ -0,0 +1,234 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2020 Martin Blumenstingl
+ *
+ * Based on panfrost_devfreq.c:
+ * Copyright 2019 Collabora ltd.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "lima_device.h"
+#include "lima_devfreq.h"
+
+static void lima_devfreq_update_utilization(struct lima_devfreq *devfreq)
+{
+ ktime_t now, last;
+
+ now = ktime_get();
+ last = devfreq->time_last_update;
+
+ if (devfreq->busy_count > 0)
+ devfreq->busy_time += ktime_sub(now, last);
+ else
+ devfreq->idle_time += ktime_sub(now, last);
+
+ devfreq->time_last_update = now;
+}
+
+static int lima_devfreq_target(struct device *dev, unsigned long *freq,
+ u32 flags)
+{
+ struct dev_pm_opp *opp;
+ int err;
+
+ opp = devfreq_recommended_opp(dev, freq, flags);
+ if (IS_ERR(opp))
+ return PTR_ERR(opp);
+ dev_pm_opp_put(opp);
+
+ err = dev_pm_opp_set_rate(dev, *freq);
+ if (err)
+ return err;
+
+ return 0;
+}
+
+static void lima_devfreq_reset(struct lima_devfreq *devfreq)
+{
+ devfreq->busy_time = 0;
+ devfreq->idle_time = 0;
+ devfreq->time_last_update = ktime_get();
+}
+
+static int lima_devfreq_get_dev_status(struct device *dev,
+ struct devfreq_dev_status *status)
+{
+ struct lima_device *ldev = dev_get_drvdata(dev);
+ struct lima_devfreq *devfreq = >devfreq;
+ unsigned long irqflags;
+
+ status->current_frequency = clk_get_rate(ldev->clk_gpu);
+
+ spin_lock_irqsave(>lock, irqflags);
+
+ lima_devfreq_update_utilization(devfreq);
+
+ status->total_time = ktime_to_ns(ktime_add(devfreq->busy_time,
+ devfreq->idle_time));
+ status->busy_time = ktime_to_ns(devfreq->busy_time);
+
+ lima_devfreq_reset(devfreq);
+
+ spin_unlock_irqrestore(>lock, irqflags);
+
+ dev_dbg(ldev->dev, "busy %lu total %lu %lu %% freq %lu MHz\n",
+ status->busy_time, status->total_time,
+ status->busy_time / (status->total_time / 100),
+ status->current_frequency / 1000 / 1000);
+
+ return 0;
+}
+
+static struct devfreq_dev_profile lima_devfreq_profile = {
+ .polling_ms = 50, /* ~3 frames */
+ .target = lima_devfreq_target,
+ .get_dev_status = lima_devfreq_get_dev_status,
+};
+
+void lima_devfreq_fini(struct lima_device *ldev)
+{
+ struct
Re: [PATCH 3/4] mm: simplify device private page handling in hmm_range_fault
On Tue, Mar 17, 2020 at 04:14:31PM -0700, Ralph Campbell wrote:
> +static int dmirror_fault(struct dmirror *dmirror, unsigned long start,
> + unsigned long end, bool write)
> +{
> + struct mm_struct *mm = dmirror->mm;
> + unsigned long addr;
> + uint64_t pfns[64];
> + struct hmm_range range = {
> + .notifier = >notifier,
> + .pfns = pfns,
> + .flags = dmirror_hmm_flags,
> + .values = dmirror_hmm_values,
> + .pfn_shift = DPT_SHIFT,
> + .pfn_flags_mask = ~(dmirror_hmm_flags[HMM_PFN_VALID] |
> + dmirror_hmm_flags[HMM_PFN_WRITE]),
Since pfns is not initialized pfn_flags_mask should be 0.
> + .default_flags = dmirror_hmm_flags[HMM_PFN_VALID] |
> + (write ? dmirror_hmm_flags[HMM_PFN_WRITE] : 0),
> + .dev_private_owner = dmirror->mdevice,
> + };
> + int ret = 0;
> +static int dmirror_snapshot(struct dmirror *dmirror,
> + struct hmm_dmirror_cmd *cmd)
> +{
> + struct mm_struct *mm = dmirror->mm;
> + unsigned long start, end;
> + unsigned long size = cmd->npages << PAGE_SHIFT;
> + unsigned long addr;
> + unsigned long next;
> + uint64_t pfns[64];
> + unsigned char perm[64];
> + char __user *uptr;
> + struct hmm_range range = {
> + .pfns = pfns,
> + .flags = dmirror_hmm_flags,
> + .values = dmirror_hmm_values,
> + .pfn_shift = DPT_SHIFT,
> + .pfn_flags_mask = ~0ULL,
Same here, especially since this is snapshot
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] mm: simplify device private page handling in hmm_range_fault
On Thu, Mar 19, 2020 at 03:56:50PM -0700, Ralph Campbell wrote:
> Adding linux-kselft...@vger.kernel.org for the test config question.
>
> On 3/19/20 11:17 AM, Jason Gunthorpe wrote:
> > On Tue, Mar 17, 2020 at 04:14:31PM -0700, Ralph Campbell wrote:
> > >
> > > On 3/17/20 5:59 AM, Christoph Hellwig wrote:
> > > > On Tue, Mar 17, 2020 at 09:47:55AM -0300, Jason Gunthorpe wrote:
> > > > > I've been using v7 of Ralph's tester and it is working well - it has
> > > > > DEVICE_PRIVATE support so I think it can test this flow too. Ralph are
> > > > > you able?
> > > > >
> > > > > This hunk seems trivial enough to me, can we include it now?
> > > >
> > > > I can send a separate patch for it once the tester covers it. I don't
> > > > want to add it to the original patch as it is a significant behavior
> > > > change compared to the existing code.
> > > >
> > >
> > > Attached is an updated version of my HMM tests based on linux-5.6.0-rc6.
> > > I ran this OK with Jason's 8+1 HMM patches, Christoph's 1-5 misc HMM
> > > clean ups,
> > > and Christoph's 1-4 device private page changes applied.
> >
> > I'd like to get this to mergable, it looks pretty good now, but I have
> > no idea about selftests - and I'm struggling to even compile the tools
> > dir
> >
> > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> > > index 69def4a9df00..4d22ce7879a7 100644
> > > +++ b/lib/Kconfig.debug
> > > @@ -2162,6 +2162,18 @@ config TEST_MEMINIT
> > > If unsure, say N.
> > > +config TEST_HMM
> > > + tristate "Test HMM (Heterogeneous Memory Management)"
> > > + depends on DEVICE_PRIVATE
> > > + select HMM_MIRROR
> > > +select MMU_NOTIFIER
> >
> > extra spaces
>
> Will fix in v8.
>
> > In general I wonder if it even makes sense that DEVICE_PRIVATE is user
> > selectable?
>
> Should tests enable the feature or the feature enable the test?
> IMHO, if the feature is being compiled into the kernel, that should
> enable the menu item for the test. If the feature isn't selected,
> no need to test it :-)
I ment if DEVICE_PRIVATE should be a user selectable option at all, or
should it be turned on when a driver like nouveau is selected.
Is there some downside to enabling DEVICE_PRIVATE?
> > The notifier holds a mmgrab, no need for another one
>
> OK. I'll replace dmirror->mm with dmirror->notifier.mm.
Right that is good too
> > > + filp->private_data = dmirror;
> >
> > Not sure what this comment means
>
> I'll change the comment to:
> /*
> * The first open of the device character file registers the address
> * space of the process doing the open() system call with the device.
> * Subsequent file opens by other processes will have access to the
> * first process' address space.
> */
How does this happen? The function looks like it always does the same thing
> > > +static bool dmirror_interval_invalidate(struct mmu_interval_notifier
> > > *mni,
> > > + const struct mmu_notifier_range *range,
> > > + unsigned long cur_seq)
> > > +{
> > > + struct dmirror *dmirror = container_of(mni, struct dmirror, notifier);
> > > + struct mm_struct *mm = dmirror->mm;
> > > +
> > > + /*
> > > + * If the process doesn't exist, we don't need to invalidate the
> > > + * device page table since the address space will be torn down.
> > > + */
> > > + if (!mmget_not_zero(mm))
> > > + return true;
> >
> > Why? Don't the notifiers provide for this already.
> >
> > mmget_not_zero() is required before calling hmm_range_fault() though
Oh... This is the invalidate_all path during invalidation
IMHO you should test the invalidation reason in the range to exclude
this.
But xa_erase looks totally safe so there should be no reason to do
that.
> This is a workaround for a problem I don't quite understand.
> If you change tools/testing/selftests/vm/hmm-tests.c line 868 to
> ASSERT_EQ(ret, -1);
> Then the test will abort, core dump, and cause two problems,
> 1) the migrated page will be faulted back to system memory in order to write
>it to the core dump. This triggers lockdep_assert_held(>mmap_sem)
>in walk_page_range().
Has the migration stuff become entangled with the xarray?
> [ 137.980718] Code: 80 2f 1a 83 c6 05 e9 8d 7b 01 01 e8 3e b1 b1 fe e9 05 ff
> ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 41 56 41 55 41 54 55 <48> 89
> fd 53 4c 8d 6d 10 e8 3c fc ff ff 49 89 c4 4c 89 e0 83 e0 03
> [ 137.999461] RSP: 0018:c900015e77c8 EFLAGS: 0246 ORIG_RAX:
> ff13
> [ 138.007028] RAX: 8886e508c408 RBX: RCX:
> 82626c89
> [ 138.014159] RDX: dc00 RSI: RDI:
> c900015e78a0
> [ 138.021293] RBP: c900015e78a0 R08: 811461c4 R09:
> f520002bcf17
> [ 138.028426] R10: f520002bcf16 R11: 0003 R12:
> 02606d10
> [ 138.035557] R13: 8886e508c448 R14: 0031 R15:
>
[PATCH v8 0/2] Add support for rm69299 Visionox panel driver and add devicetree bindings for visionox panel
Adding support for visionox rm69299 panel driver and adding bindings for the same panel. Harigovindan P (2): dt-bindings: display: add visionox rm69299 panel variant drm/panel: add support for rm69299 visionox panel driver .../display/panel/visionox,rm69299.yaml | 73 + drivers/gpu/drm/panel/Kconfig | 8 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-visionox-rm69299.c| 295 ++ 4 files changed, 377 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml create mode 100644 drivers/gpu/drm/panel/panel-visionox-rm69299.c -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH v2 5/5] arm64: allwinner: dts: a64: add LCD-related device nodes for PinePhone
在 2020-03-16星期一的 21:35 +0800，Icenowy Zheng写道：
> PinePhone uses PWM backlight and a XBD599 LCD panel over DSI for
> display.
>
> Add its device nodes.
>
> Signed-off-by: Icenowy Zheng
> ---
> No changes in v2.
>
> .../dts/allwinner/sun50i-a64-pinephone.dtsi | 37
> +++
> 1 file changed, 37 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> index cefda145c3c9..96d9150423e0 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> @@ -16,6 +16,15 @@ aliases {
> serial0 =
> };
>
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = <_pwm 0 5 PWM_POLARITY_INVERTED>;
> + brightness-levels = <0 16 18 20 22 24 26 29 32 35 38 42
> 46 51 56 62 68 75 83 91 100>;
Should I drop the 0 here and replace it with 14?
I have heard community complaining about setting 0 to brightness make
the screen black.
(I think in this situation bl_power or blank the DSI panel can still
totally shut down the backlight).
> + default-brightness-level = <15>;
> + enable-gpios = < 7 10 GPIO_ACTIVE_HIGH>; /* PH10 */
> + power-supply = <_ldo_io0>;
> + };
> +
> chosen {
> stdout-path = "serial0:115200n8";
> };
> @@ -84,6 +93,30 @@ {
> status = "okay";
> };
>
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + vcc-dsi-supply = <_dldo1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "okay";
> +
> + panel@0 {
> + compatible = "xingbangda,xbd599";
> + reg = <0>;
> + reset-gpios = < 3 23 GPIO_ACTIVE_LOW>; /* PD23 */
> + iovcc-supply = <_dldo2>;
> + vcc-supply = <_ldo_io0>;
> + backlight = <>;
> + };
> +};
> +
> {
> status = "okay";
> };
> @@ -188,6 +221,10 @@ _pio {
>*/
> };
>
> +_pwm {
> + status = "okay";
> +};
> +
> _rsb {
> status = "okay";
>
> --
> 2.24.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/8] iommu/vt-d: Remove IOVA handling code from non-dma_ops path
Could we merge patch 1-3 from this series? it just cleans up weird
code and merging these patches will cover some of the work needed to
move the intel iommu driver to the dma-iommu api in the future.
On Sat, 21 Dec 2019 at 07:04, Tom Murphy wrote:
>
> Remove all IOVA handling code from the non-dma_ops path in the intel
> iommu driver.
>
> There's no need for the non-dma_ops path to keep track of IOVAs. The
> whole point of the non-dma_ops path is that it allows the IOVAs to be
> handled separately. The IOVA handling code removed in this patch is
> pointless.
>
> Signed-off-by: Tom Murphy
> ---
> drivers/iommu/intel-iommu.c | 89 ++---
> 1 file changed, 33 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index 64b1a9793daa..8d72ea0fb843 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -1908,7 +1908,8 @@ static void domain_exit(struct dmar_domain *domain)
> domain_remove_dev_info(domain);
>
> /* destroy iovas */
> - put_iova_domain(>iovad);
> + if (domain->domain.type == IOMMU_DOMAIN_DMA)
> + put_iova_domain(>iovad);
>
> if (domain->pgd) {
> struct page *freelist;
> @@ -2671,19 +2672,9 @@ static struct dmar_domain *set_domain_for_dev(struct
> device *dev,
> }
>
> static int iommu_domain_identity_map(struct dmar_domain *domain,
> -unsigned long long start,
> -unsigned long long end)
> +unsigned long first_vpfn,
> +unsigned long last_vpfn)
> {
> - unsigned long first_vpfn = start >> VTD_PAGE_SHIFT;
> - unsigned long last_vpfn = end >> VTD_PAGE_SHIFT;
> -
> - if (!reserve_iova(>iovad, dma_to_mm_pfn(first_vpfn),
> - dma_to_mm_pfn(last_vpfn))) {
> - pr_err("Reserving iova failed\n");
> - return -ENOMEM;
> - }
> -
> - pr_debug("Mapping reserved region %llx-%llx\n", start, end);
> /*
> * RMRR range might have overlap with physical memory range,
> * clear it first
> @@ -2760,7 +2751,8 @@ static int __init si_domain_init(int hw)
>
> for_each_mem_pfn_range(i, nid, _pfn, _pfn, NULL) {
> ret = iommu_domain_identity_map(si_domain,
> - PFN_PHYS(start_pfn),
> PFN_PHYS(end_pfn));
> + mm_to_dma_pfn(start_pfn),
> + mm_to_dma_pfn(end_pfn));
> if (ret)
> return ret;
> }
> @@ -4593,58 +4585,37 @@ static int intel_iommu_memory_notifier(struct
> notifier_block *nb,
>unsigned long val, void *v)
> {
> struct memory_notify *mhp = v;
> - unsigned long long start, end;
> - unsigned long start_vpfn, last_vpfn;
> + unsigned long start_vpfn = mm_to_dma_pfn(mhp->start_pfn);
> + unsigned long last_vpfn = mm_to_dma_pfn(mhp->start_pfn +
> + mhp->nr_pages - 1);
>
> switch (val) {
> case MEM_GOING_ONLINE:
> - start = mhp->start_pfn << PAGE_SHIFT;
> - end = ((mhp->start_pfn + mhp->nr_pages) << PAGE_SHIFT) - 1;
> - if (iommu_domain_identity_map(si_domain, start, end)) {
> - pr_warn("Failed to build identity map for
> [%llx-%llx]\n",
> - start, end);
> + if (iommu_domain_identity_map(si_domain, start_vpfn,
> + last_vpfn)) {
> + pr_warn("Failed to build identity map for
> [%lx-%lx]\n",
> + start_vpfn, last_vpfn);
> return NOTIFY_BAD;
> }
> break;
>
> case MEM_OFFLINE:
> case MEM_CANCEL_ONLINE:
> - start_vpfn = mm_to_dma_pfn(mhp->start_pfn);
> - last_vpfn = mm_to_dma_pfn(mhp->start_pfn + mhp->nr_pages - 1);
> - while (start_vpfn <= last_vpfn) {
> - struct iova *iova;
> + {
> struct dmar_drhd_unit *drhd;
> struct intel_iommu *iommu;
> struct page *freelist;
>
> - iova = find_iova(_domain->iovad, start_vpfn);
> - if (iova == NULL) {
> - pr_debug("Failed get IOVA for PFN %lx\n",
> -start_vpfn);
> - break;
> - }
> -
> - iova = split_and_remove_iova(_domain->iovad, iova,
> -start_vpfn, last_vpfn);
> - if
[PATCH v11 00/12] Convert PWM period and duty cycle to u64
Because period and duty cycle are defined in the PWM framework structs as ints with units of nanoseconds, the maximum time duration that can be set is limited to ~2.147 seconds. Consequently, applications desiring to set greater time periods via the PWM framework are not be able to do so - like, for instance, causing an LED to blink at an interval of 5 seconds. Redefining the period and duty cycle struct members in the core PWM framework structs as u64 values will enable larger time durations to be set and solve this problem. Such a change to the framework mandates that drivers using these struct members (and corresponding helper functions) also be modified correctly in order to prevent compilation errors. This patch series introduces the changes to all the drivers first, followed by the framework change at the very end so that when the latter is applied, all the drivers are in good shape and there are no compilation errors. Changes from v10: - Carefully added back all the "Reviewed-by: " and "Acked-by: " tags received so far that had gotten missed in v9. No other changes. Changes from v9: - Gathered the received "Reviewed-by: " tag - Added back the clk-pwm.c patch because kbuild test robot complained [3] and addressed received review comments. - clps711x: Addressed review comments. Changes from v8: - Gathered all received "Acked-by: " and "Reviewed-by: " tags - Dropped patch to clk-pwm.c for reasons mentiond in [2] - Expanded audience of unreviewed patches Changes from v7: - Changed commit messages of all patches to be brief and to the point. - Added explanation of change in cover letter. - Dropped change to pwm-sti.c as upon review it was unnecessary as struct pwm_capture is not being modified in the PWM core. Changes from v6: - Split out the driver changes out into separate patches, one patch per file for ease of reviewing. Changes from v5: - Dropped the conversion of struct pwm_capture to u64 for reasons mentioned in https://www.spinics.net/lists/linux-pwm/msg11541.html Changes from v4: - Split the patch into two: one for changes to the drivers, and the actual switch to u64 for ease of reverting should the need arise. - Re-examined the patch and made the following corrections: * intel_panel.c: DIV64_U64_ROUND_UP -> DIV_ROUND_UP_ULL (as only the numerator would be 64-bit in this case). * pwm-sti.c: do_div -> div_u64 (do_div is optimized only for x86 architectures, and div_u64's comment block suggests to use this as much as possible). Changes from v3: - Rebased to current tip of for-next. Changes from v2: - Fixed %u -> %llu in a dev_dbg in pwm-stm32-lp.c, thanks to kbuild test robot - Added a couple of fixes to pwm-imx-tpm.c and pwm-sifive.c Changes from v1: - Fixed compilation errors seen when compiling for different archs. v1: - Reworked the change pushed upstream earlier [1] so as to not add an extension to an obsolete API. With this change, pwm_ops->apply() can be used to set pwm_state parameters as usual. [1] https://lore.kernel.org/lkml/20190916140048.GB7488@ulmo/ [2] https://lore.kernel.org/lkml/20200312190859.ga19...@codeaurora.org/ [3] https://www.spinics.net/lists/linux-pwm/msg11906.html Guru Das Srinagesh (12): drm/i915: Use 64-bit division macro hwmon: pwm-fan: Use 64-bit division macro ir-rx51: Use 64-bit division macro pwm: clps711x: Cast period to u32 before use as divisor pwm: pwm-imx-tpm: Use 64-bit division macro pwm: imx27: Use 64-bit division macro and function pwm: sifive: Use 64-bit division macro pwm: stm32-lp: Use %llu format specifier for period pwm: sun4i: Use 64-bit division function backlight: pwm_bl: Use 64-bit division function clk: pwm: Assign u64 divisor to unsigned int before use pwm: core: Convert period and duty cycle to u64 drivers/clk/clk-pwm.c | 4 +++- drivers/gpu/drm/i915/display/intel_panel.c | 2 +- drivers/hwmon/pwm-fan.c| 2 +- drivers/media/rc/ir-rx51.c | 3 ++- drivers/pwm/core.c | 4 ++-- drivers/pwm/pwm-clps711x.c | 5 - drivers/pwm/pwm-imx-tpm.c | 2 +- drivers/pwm/pwm-imx27.c| 5 ++--- drivers/pwm/pwm-sifive.c | 2 +- drivers/pwm/pwm-stm32-lp.c | 2 +- drivers/pwm/pwm-sun4i.c| 2 +- drivers/pwm/sysfs.c| 8 drivers/video/backlight/pwm_bl.c | 3 ++- include/linux/pwm.h| 12 ++-- 14 files changed, 31 insertions(+), 25 deletions(-) Cc: Lee Jones Cc: Daniel Thompson Cc: Jingoo Han Cc: Bartlomiej Zolnierkiewicz Cc: linux-fb...@vger.kernel.org Cc: Maxime Ripard Cc: Chen-Yu Tsai Cc: Philipp Zabel Cc: Fabrice Gasnier Cc: Maxime Coquelin Cc: Alexandre Torgue Cc: Palmer Dabbelt Cc: Paul Walmsley Cc:
[PATCH v2] drm: Alligne a comment block
Fix a checkpatch warning caused by a misaligned comment block.
Changes in v2:
- Change subject text
Signed-off-by: Igor Matheus Andrade Torrente
---
drivers/gpu/drm/drm_gem.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index a9e4a610445a..564acc1f4030 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -222,10 +222,10 @@ drm_gem_object_handle_put_unlocked(struct drm_gem_object
*obj)
return;
/*
- * Must bump handle count first as this may be the last
- * ref, in which case the object would disappear before we
- * checked for a name
- */
+* Must bump handle count first as this may be the last
+* ref, in which case the object would disappear before we
+* checked for a name
+*/
mutex_lock(>object_name_lock);
if (--obj->handle_count == 0) {
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/2] dt-bindings: gpu: mali-utgard: Add the #cooling-cells property
The GPU can be one of the big heat sources on a SoC. Allow the "#cooling-cells" property to be specified for ARM Mali Utgard GPUs so the GPU clock speeds (and voltages) can be reduced to prevent a SoC from overheating. Signed-off-by: Martin Blumenstingl --- Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml index afde81be3c29..33548ca2a759 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml @@ -107,6 +107,9 @@ properties: operating-points-v2: true + "#cooling-cells": +const: 2 + required: - compatible - reg @@ -162,6 +165,7 @@ examples: clocks = < 1>, < 2>; clock-names = "bus", "core"; resets = < 1>; + #cooling-cells = <2>; }; ... -- 2.25.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: general protection fault in sctp_ulpevent_nofity_peer_addr_change
syzbot has bisected this bug to:
commit da2648390ce3d409218b6bbbf2386d8ddeec2265
Author: Lubomir Rintel
Date: Thu Dec 20 18:13:09 2018 +
pxa168fb: trivial typo fix
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1361e139e0
start commit: 5076190d mm: slub: be more careful about the double cmpxch..
git tree: upstream
final crash:https://syzkaller.appspot.com/x/report.txt?x=10e1e139e0
console output: https://syzkaller.appspot.com/x/log.txt?x=1761e139e0
kernel config: https://syzkaller.appspot.com/x/.config?x=9f894bd92023de02
dashboard link: https://syzkaller.appspot.com/bug?extid=3950016bd95c2ca0377b
userspace arch: i386
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1162bbe3e0
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13c93b45e0
Reported-by: syzbot+3950016bd95c2ca03...@syzkaller.appspotmail.com
Fixes: da2648390ce3 ("pxa168fb: trivial typo fix")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: ensure device private pages have an owner v2
On Thu, Mar 19, 2020 at 08:16:33AM +0100, Christoph Hellwig wrote: > On Wed, Mar 18, 2020 at 09:28:49PM -0300, Jason Gunthorpe wrote: > > > Changes since v1: > > > - split out the pgmap->owner addition into a separate patch > > > - check pgmap->owner is set for device private mappings > > > - rename the dev_private_owner field in struct migrate_vma to src_owner > > > - refuse to migrate private pages if src_owner is not set > > > - keep the non-fault device private handling in hmm_range_fault > > > > I'm happy enough to take this, did you have plans for a v3? > > I think the only open question is if merging 3 and 4 might make sense. > It's up to you if you want it resent that way or not. Now that I understand that amdgpu doesn't set the 'do not return device_private pages' flag, I think the split is fine, I'll grab it as is then today Thanks, Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH v2 5/5] arm64: allwinner: dts: a64: add LCD-related device nodes for PinePhone
On Thu, Mar 19, 2020 at 10:51:36PM +0800, Icenowy Zheng wrote:
> 在 2020-03-16星期一的 21:35 +0800，Icenowy Zheng写道：
> > PinePhone uses PWM backlight and a XBD599 LCD panel over DSI for
> > display.
> >
> > Add its device nodes.
> >
> > Signed-off-by: Icenowy Zheng
> > ---
> > No changes in v2.
> >
> > .../dts/allwinner/sun50i-a64-pinephone.dtsi | 37
> > +++
> > 1 file changed, 37 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> > b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> > index cefda145c3c9..96d9150423e0 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> > @@ -16,6 +16,15 @@ aliases {
> > serial0 =
> > };
> >
> > + backlight: backlight {
> > + compatible = "pwm-backlight";
> > + pwms = <_pwm 0 5 PWM_POLARITY_INVERTED>;
> > + brightness-levels = <0 16 18 20 22 24 26 29 32 35 38 42
> > 46 51 56 62 68 75 83 91 100>;
>
> Should I drop the 0 here and replace it with 14?
Almost all boards in arm/boot/dts start at 0.
> I have heard community complaining about setting 0 to brightness make
> the screen black.
Level 0 (first value in the list) is special, and turns off the backlight:
123 if (brightness > 0) {
124 pwm_get_state(pb->pwm, );
125 state.duty_cycle = compute_duty_cycle(pb, brightness);
126 pwm_apply_state(pb->pwm, );
127 pwm_backlight_power_on(pb);
128 } else {
129 pwm_backlight_power_off(pb);
130 }
o.
> (I think in this situation bl_power or blank the DSI panel can still
> totally shut down the backlight).
>
> > + default-brightness-level = <15>;
> > + enable-gpios = < 7 10 GPIO_ACTIVE_HIGH>; /* PH10 */
> > + power-supply = <_ldo_io0>;
> > + };
> > +
> > chosen {
> > stdout-path = "serial0:115200n8";
> > };
> > @@ -84,6 +93,30 @@ {
> > status = "okay";
> > };
> >
> > + {
> > + status = "okay";
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > +
> > + {
> > + vcc-dsi-supply = <_dldo1>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + status = "okay";
> > +
> > + panel@0 {
> > + compatible = "xingbangda,xbd599";
> > + reg = <0>;
> > + reset-gpios = < 3 23 GPIO_ACTIVE_LOW>; /* PD23 */
> > + iovcc-supply = <_dldo2>;
> > + vcc-supply = <_ldo_io0>;
> > + backlight = <>;
> > + };
> > +};
> > +
> > {
> > status = "okay";
> > };
> > @@ -188,6 +221,10 @@ _pio {
> > */
> > };
> >
> > +_pwm {
> > + status = "okay";
> > +};
> > +
> > _rsb {
> > status = "okay";
> >
> > --
> > 2.24.1
> >
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v2] arm64: dts: sc7180: modify assigned clocks for sc7180 target
Subject could be "sc7180: update DPU assigned clocks" Quoting Krishna Manikandan (2020-03-16 04:02:42) > Add DISP_CC_MDSS_ROT_CLK and DISP_CC_MDSS_AHB_CLK > in the assigned clocks list for sc7180 target. Why? > > Signed-off-by: Krishna Manikandan Does this need a Fixes: tag? > --- > arch/arm64/boot/dts/qcom/sc7180.dtsi | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi > b/arch/arm64/boot/dts/qcom/sc7180.dtsi > index 998f101..e3b60f1 100644 > --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi > +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi > @@ -1544,8 +1544,12 @@ > clock-names = "iface", "rot", "lut", "core", > "vsync"; > assigned-clocks = < > DISP_CC_MDSS_MDP_CLK>, > - < > DISP_CC_MDSS_VSYNC_CLK>; > + < > DISP_CC_MDSS_VSYNC_CLK>, > + < > DISP_CC_MDSS_ROT_CLK>, > + < > DISP_CC_MDSS_AHB_CLK>; > assigned-clock-rates = <3>, > + <1920>, > + <1920>, ><1920>; > > interrupt-parent = <>; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] mm: simplify device private page handling in hmm_range_fault
On Tue, Mar 17, 2020 at 04:14:31PM -0700, Ralph Campbell wrote:
>
> On 3/17/20 5:59 AM, Christoph Hellwig wrote:
> > On Tue, Mar 17, 2020 at 09:47:55AM -0300, Jason Gunthorpe wrote:
> > > I've been using v7 of Ralph's tester and it is working well - it has
> > > DEVICE_PRIVATE support so I think it can test this flow too. Ralph are
> > > you able?
> > >
> > > This hunk seems trivial enough to me, can we include it now?
> >
> > I can send a separate patch for it once the tester covers it. I don't
> > want to add it to the original patch as it is a significant behavior
> > change compared to the existing code.
> >
>
> Attached is an updated version of my HMM tests based on linux-5.6.0-rc6.
> I ran this OK with Jason's 8+1 HMM patches, Christoph's 1-5 misc HMM clean
> ups,
> and Christoph's 1-4 device private page changes applied.
I'd like to get this to mergable, it looks pretty good now, but I have
no idea about selftests - and I'm struggling to even compile the tools
dir
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 69def4a9df00..4d22ce7879a7 100644
> +++ b/lib/Kconfig.debug
> @@ -2162,6 +2162,18 @@ config TEST_MEMINIT
>
> If unsure, say N.
>
> +config TEST_HMM
> + tristate "Test HMM (Heterogeneous Memory Management)"
> + depends on DEVICE_PRIVATE
> + select HMM_MIRROR
> +select MMU_NOTIFIER
extra spaces
In general I wonder if it even makes sense that DEVICE_PRIVATE is user
selectable?
> +static int dmirror_fops_open(struct inode *inode, struct file *filp)
> +{
> + struct cdev *cdev = inode->i_cdev;
> + struct dmirror *dmirror;
> + int ret;
> +
> + /* Mirror this process address space */
> + dmirror = kzalloc(sizeof(*dmirror), GFP_KERNEL);
> + if (dmirror == NULL)
> + return -ENOMEM;
> +
> + dmirror->mdevice = container_of(cdev, struct dmirror_device, cdevice);
> + mutex_init(>mutex);
> + xa_init(>pt);
> +
> + ret = mmu_interval_notifier_insert(>notifier, current->mm,
> + 0, ULONG_MAX & PAGE_MASK, _min_ops);
> + if (ret) {
> + kfree(dmirror);
> + return ret;
> + }
> +
> + /* Pairs with the mmdrop() in dmirror_fops_release(). */
> + mmgrab(current->mm);
> + dmirror->mm = current->mm;
The notifier holds a mmgrab, no need for another one
> + /* Only the first open registers the address space. */
> + filp->private_data = dmirror;
Not sure what this comment means
> +static inline struct dmirror_device *dmirror_page_to_device(struct page
> *page)
> +
> +{
> + struct dmirror_chunk *devmem;
> +
> + devmem = container_of(page->pgmap, struct dmirror_chunk, pagemap);
> + return devmem->mdevice;
> +}
extra devmem var is not really needed
> +
> +static bool dmirror_device_is_mine(struct dmirror_device *mdevice,
> +struct page *page)
> +{
> + if (!is_zone_device_page(page))
> + return false;
> + return page->pgmap->ops == _devmem_ops &&
> + dmirror_page_to_device(page) == mdevice;
> +}
Use new owner stuff, right? Actually this is redunant now, the check
should be just WARN_ON pageowner != self owner
> +static int dmirror_do_fault(struct dmirror *dmirror, struct hmm_range *range)
> +{
> + uint64_t *pfns = range->pfns;
> + unsigned long pfn;
> +
> + for (pfn = (range->start >> PAGE_SHIFT);
> + pfn < (range->end >> PAGE_SHIFT);
> + pfn++, pfns++) {
> + struct page *page;
> + void *entry;
> +
> + /*
> + * HMM_PFN_ERROR is returned if it is accessing invalid memory
> + * either because of memory error (hardware detected memory
> + * corruption) or more likely because of truncate on mmap
> + * file.
> + */
> + if (*pfns == range->values[HMM_PFN_ERROR])
> + return -EFAULT;
Unless that snapshot is use hmm_range_fault() never returns success
and sets PFN_ERROR, so this should be a WARN_ON
> + if (!(*pfns & range->flags[HMM_PFN_VALID]))
> + return -EFAULT;
Same with valid.
> + page = hmm_device_entry_to_page(range, *pfns);
> + /* We asked for pages to be populated but check anyway. */
> + if (!page)
> + return -EFAULT;
WARN_ON
> + if (is_zone_device_page(page)) {
> + /*
> + * TODO: need a way to ask HMM to fault foreign zone
> + * device private pages.
> + */
> + if (!dmirror_device_is_mine(dmirror->mdevice, page))
> + continue;
Actually re
> +static bool dmirror_interval_invalidate(struct mmu_interval_notifier *mni,
> + const struct mmu_notifier_range *range,
> + unsigned long cur_seq)
> +{
> + struct
[PATCH v10 10/12] backlight: pwm_bl: Use 64-bit division function
Since the PWM framework is switching struct pwm_state.period's datatype to u64, prepare for this transition by using div_u64 to handle a 64-bit dividend instead of a straight division operation. Cc: Lee Jones Cc: Daniel Thompson Cc: Jingoo Han Cc: Bartlomiej Zolnierkiewicz Cc: linux-...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linux-fb...@vger.kernel.org Signed-off-by: Guru Das Srinagesh --- drivers/video/backlight/pwm_bl.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c index efb4efc..3e5dbcf 100644 --- a/drivers/video/backlight/pwm_bl.c +++ b/drivers/video/backlight/pwm_bl.c @@ -625,7 +625,8 @@ static int pwm_backlight_probe(struct platform_device *pdev) pb->scale = data->max_brightness; } - pb->lth_brightness = data->lth_brightness * (state.period / pb->scale); + pb->lth_brightness = data->lth_brightness * (div_u64(state.period, + pb->scale)); props.type = BACKLIGHT_RAW; props.max_brightness = data->max_brightness; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v11 10/12] backlight: pwm_bl: Use 64-bit division function
Since the PWM framework is switching struct pwm_state.period's datatype to u64, prepare for this transition by using div_u64 to handle a 64-bit dividend instead of a straight division operation. Cc: Lee Jones Cc: Daniel Thompson Cc: Jingoo Han Cc: Bartlomiej Zolnierkiewicz Cc: linux-...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linux-fb...@vger.kernel.org Signed-off-by: Guru Das Srinagesh Reviewed-by: Daniel Thompson --- drivers/video/backlight/pwm_bl.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c index efb4efc..3e5dbcf 100644 --- a/drivers/video/backlight/pwm_bl.c +++ b/drivers/video/backlight/pwm_bl.c @@ -625,7 +625,8 @@ static int pwm_backlight_probe(struct platform_device *pdev) pb->scale = data->max_brightness; } - pb->lth_brightness = data->lth_brightness * (state.period / pb->scale); + pb->lth_brightness = data->lth_brightness * (div_u64(state.period, + pb->scale)); props.type = BACKLIGHT_RAW; props.max_brightness = data->max_brightness; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/format_helper: Dual licence the header in GPL-2 and MIT
Source file was dual licenced but the header was omitted, fix that. Contributors for this file are: Noralf Trønnes Gerd Hoffmann Thomas Gleixner Signed-off-by: Emmanuel Vadot --- include/drm/drm_format_helper.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h index ac220aa1a245..7c5d4ffb2af2 100644 --- a/include/drm/drm_format_helper.h +++ b/include/drm/drm_format_helper.h @@ -1,4 +1,4 @@ -/* SPDX-License-Identifier: GPL-2.0-or-later */ +/* SPDX-License-Identifier: GPL-2.0 or MIT */ /* * Copyright (C) 2016 Noralf Trønnes */ -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/4] Support virtio cross-device resources
On Wed, Mar 11, 2020 at 08:20:00PM +0900, David Stevens wrote: > This patchset implements the current proposal for virtio cross-device > resource sharing [1], with minor changes based on recent comments. It > is expected that this will be used to import virtio resources into the > virtio-video driver currently under discussion [2]. > > This patchset adds a new hook to dma-buf, for querying the dma-buf's > underlying virtio UUID. This hook is then plumbed through DRM PRIME > buffers, and finally implemented in virtgpu. Looks all fine to me. We should wait for the virtio protocol update (patch 3/4) being accepted into the virtio specification. When this is done I'll go commit this to drm-misc-next. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
