Re: [PATCH V1 09/10] arch/kmap: Define kmap_atomic_prot() for all arch's

[Ira Weiny]

On Fri, May 01, 2020 at 04:20:20AM +0100, Al Viro wrote:
> On Fri, May 01, 2020 at 03:37:34AM +0100, Al Viro wrote:
> > On Thu, Apr 30, 2020 at 01:38:44PM -0700, ira.we...@intel.com wrote:
> > 
> > > -static inline void *kmap_atomic(struct page *page)
> > > +static inline void *kmap_atomic_prot(struct page *page, pgprot_t prot)
> > >  {
> > >   preempt_disable();
> > >   pagefault_disable();
> > >   if (!PageHighMem(page))
> > >   return page_address(page);
> > > - return kmap_atomic_high(page);
> > > + return kmap_atomic_high_prot(page, prot);
> > >  }
> > > +#define kmap_atomic(page)kmap_atomic_prot(page, kmap_prot)
> > 
> > OK, so it *was* just a bisect hazard - you return to original semantics
> > wrt preempt_disable()...
> 
> FWIW, how about doing the following: just before #5/10 have a patch
> that would touch only microblaze, ppc and x86 splitting their
> kmap_atomic_prot() into an inline helper + kmap_atomic_high_prot().
> Then your #5 would leave their kmap_atomic_prot() as-is (it would
> use kmap_atomic_prot_high() instead).  The rest of the series plays
> out pretty much the same way it does now, and wrappers on those
> 3 architectures would go away when an identical generic one is
> introduced in this commit (#9/10).
> 
> AFAICS, that would avoid the bisect hazard and might even end
> up with less noise in the patches...

This works.  V2 coming out shortly.

Thanks for catching this,
Ira

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 08/10] drm: Add Generic USB Display driver

[Noralf Trønnes]

Den 29.04.2020 14.48, skrev Noralf Trønnes:
> This adds a generic USB display driver with the intention that it can be
> used with future USB interfaced low end displays/adapters. The Linux
> gadget device driver will serve as the canonical device implementation.
> 
> The following DRM properties are supported:
> - Plane rotation
> - Connector TV properties
> 
> There is also support for backlight brightness exposed as a backlight
> device.
> 
> Display modes can be made available to the host driver either as DRM
> display modes or through EDID. If both are present, EDID is just passed
> on to userspace.
> 
> Performance is preferred over color depth, so if the device supports
> RGB565, DRM_CAP_DUMB_PREFERRED_DEPTH will return 16.
> 
> If the device transfer buffer can't fit an uncompressed framebuffer
> update, the update is split up into parts that do fit.
> 
> Optimal user experience is achieved by providing damage reports either by
> setting FB_DAMAGE_CLIPS on pageflips or calling DRM_IOCTL_MODE_DIRTYFB.
> 
> LZ4 compression is used if the device supports it.
> 
> The driver supports a one bit monochrome transfer format: R1. This is not
> implemented in the gadget driver. It is added in preparation for future
> monochrome e-ink displays.
> 
> The driver is MIT licensed to smooth the path for any BSD port of the
> driver.
> 
> Signed-off-by: Noralf Trønnes 
> ---

> diff --git a/drivers/gpu/drm/gud/gud_drm_drv.c 
> b/drivers/gpu/drm/gud/gud_drm_drv.c

> +static int gud_drm_probe(struct usb_interface *interface,
> +  const struct usb_device_id *id)
> +{



> + gdrm = kzalloc(sizeof(*gdrm), GFP_KERNEL);
> + if (!gdrm)
> + return -ENOMEM;
> +
> + gdrm->usb = usb;
> + gdrm->ifnum = interface->cur_altsetting->desc.bInterfaceNumber;
> + gdrm->compression = desc.bCompression & GUD_DRM_COMPRESSION_LZ4;
> +
> + drm = >drm;
> + ret = devm_drm_dev_init(dev, drm, _drm_driver);
> + if (ret) {
> + kfree(gdrm);
> + return ret;
> + }

I see that Daniel's series has landed now, so I will use
devm_drm_dev_alloc() and drmm_mode_config_init() in the next version.



> + drm_fbdev_generic_setup(drm, 16);

This should be:

drm_fbdev_generic_setup(drm, 0);

Noralf.

> +
> + return 0;
> +}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 207383] [Regression] 5.7-rc: amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=207383

--- Comment #9 from Duncan (1i5t5.dun...@cox.net) ---
I'm not there yet but it's starting to look like a possibly dud bisect:
everything showing good so far.  Maybe I didn't wait long enough for the bug to
trigger at some step and I'm running up the wrong side of the tree, or maybe
it's not drm after all (I thought I'd try something new and limit the paths to
drivers/gpu/drm/ and include/drm/, but that may have been a critical mistake). 
Right now there's only 3-4 even remotely reasonable candidates (out of 14 left
to test... the rest being mediatek or similar):

4064b9827
Peter Xu
mm: allow VM_FAULT_RETRY for multiple times

6bfef2f91
Jason Gunthorpe
mm/hmm: remove HMM_FAULT_SNAPSHOT

17ffdc482
Christoph Hellwig
mm: simplify device private page handling in hmm_range_fault

And maybe (but I'm neither EFI nor 32-bit)

72e0ef0e5
Mikel Rychliski
PCI: Use ioremap(), not phys_to_virt() for platform ROM


Meanwhile, user-side I've gotten vulkan/mesa/etc updates recently.  I'm
considering checking out linus-master/HEAD again, doing a pull, and seeing if
by chance either the last week's kernel updates or the user-side updates have
eliminated the problem.  If not I can come back and finish the bisect (or try
just reverting those four on current linus-master/HEAD), before starting a new
clean bisect if necessary.  Just saved the bisect log and current pointer.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 206987] [drm] [amdgpu] Whole system crashes when the driver is in mode_support_and_system_configuration

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=206987

--- Comment #12 from Cyrax (ev...@hotmail.com) ---
Created attachment 288873
  --> https://bugzilla.kernel.org/attachment.cgi?id=288873=edit
dmesg from 5.6.8

Additionally dmesg output shows this line : note: kworker/0:3[2251663] exited
with preempt_count 1

It seems that this bug occurs when the monitor is turned off and then on
repeatedly with short delay between.

-- 
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 v2 1/1] drm/mm: optimize rb_hole_addr rbtree search

[Das, Nirmoy]

On 5/2/2020 10:00 AM, Chris Wilson wrote:

Quoting Nirmoy (2020-04-30 11:30:43)

On 4/30/20 12:15 PM, Chris Wilson wrote:

Quoting Nirmoy Das (2020-04-30 10:58:39)

+void insert_hole_addr(struct rb_root *root, struct drm_mm_node *node)

^ static


Ah I forgot!


(sparse [make C=1] or make W=1 will spot this)


Thanks for the tip :)

Nirmoy


Looks good, I'll check more carefully later.

Reviewed-by: Chris Wilson 

If you do find some time to add some more tests, that would be great!

Even converting your example into a test-drm_mm benchmark [spending a
few seconds runtime max!] will be very useful.



Thanks Chris for reviewing this. I already started looking into adding 
some fragmentation tests :)



Regards,

Nirmoy



-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-develdata=02%7C01%7Cnirmoy.das%40amd.com%7Ce73eb7b87f8a4c4c180108d7ee77389c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637240068162932922sdata=%2FthV3slEerwVUYVwGzfiOb%2BtpboXQwYca%2BlAJ3L4Ad0%3Dreserved=0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drivers: drm: panel: Add TM5P5 NT35596 panel driver

[Sam Ravnborg]

Hi Konrad.

On Sat, May 02, 2020 at 12:09:45PM +0200, Konrad Dybcio wrote:
> Hi,
> 
> Thanks for your review. I'll send a v2 soon, however we need to solve the
> compat string issue first.
> 
> How should I document tm5p5? I think it's rather some kind of a model no.
> along with the nt35596 IC than a vendor name.. Or should we call it
> something like "unknown,tm5p5-nt35596",

> perhaps "asus,z00t-tm5p5-n35596"
This is the best choice I think.
It is mounted inside an asus phone and we have no bette clue what vendor
it is.
Include the info you already provided in these mails in the binding,
so if anyone tries to dig deeper or have better knowledge one day we
have the original findings documented.

Searching a little reveals the the zenphone 2 laser uses a TruVivid
display - so seems to be asus manufactured.
So that only confirms that your suggestion is good.

Sam


> [1]?
> 
> [1] Z00T is the model number of the smartphone that uses this panel
> 
> Konrad
> 
> On Sat, May 2, 2020, 09:05 Sam Ravnborg  wrote:
> 
> > Hi Konrad.
> >
> > On Fri, May 01, 2020 at 10:48:22PM +0200, Konrad Dybcio wrote:
> > > This adds support for TMP5P5 NT35596 1080x1920 video
> > > mode panel that can be found on some Asus Zenfone 2
> > > Laser (Z00T) devices.
> >
> > Very well-writen driver. Only a few small things in the following.
> >
> > Sam
> >
> > >
> > > Signed-off-by: Konrad Dybcio 
> > > ---
> > >  drivers/gpu/drm/panel/Kconfig   |   9 +
> > >  drivers/gpu/drm/panel/Makefile  |   1 +
> > >  drivers/gpu/drm/panel/panel-tm5p5-nt35596.c | 366 
> > >  3 files changed, 376 insertions(+)
> > >  create mode 100644 drivers/gpu/drm/panel/panel-tm5p5-nt35596.c
> > >
> > > diff --git a/drivers/gpu/drm/panel/Kconfig
> > b/drivers/gpu/drm/panel/Kconfig
> > > index a1723c1b5fbf8..6ff892334ac4b 100644
> > > --- a/drivers/gpu/drm/panel/Kconfig
> > > +++ b/drivers/gpu/drm/panel/Kconfig
> > > @@ -401,6 +401,15 @@ config DRM_PANEL_SONY_ACX565AKM
> > > Say Y here if you want to enable support for the Sony ACX565AKM
> > > 800x600 3.5" panel (found on the Nokia N900).
> > >
> > > +config DRM_PANEL_TM5P5_NT35596
> > > + tristate "TM5P5 NT35596 panel"
> > > + depends on GPIOLIB && OF
> > > + depends on DRM_MIPI_DSI
> > > + help
> > > +   Say Y here if you want to enable support for the TMP5P5
> > > +   NT35596 1080x1920 video mode panel as found in some Asus
> > > +   Zenfone 2 Laser Z00T devices.
> > > +
> > >  config DRM_PANEL_TPO_TD028TTEC1
> > >   tristate "Toppoly (TPO) TD028TTEC1 panel driver"
> > >   depends on OF && SPI
> > > diff --git a/drivers/gpu/drm/panel/Makefile
> > b/drivers/gpu/drm/panel/Makefile
> > > index 96a883cd66305..4fc7e00b18502 100644
> > > --- a/drivers/gpu/drm/panel/Makefile
> > > +++ b/drivers/gpu/drm/panel/Makefile
> > > @@ -42,6 +42,7 @@ obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) +=
> > panel-sitronix-st7701.o
> > >  obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
> > >  obj-$(CONFIG_DRM_PANEL_SONY_ACX424AKP) += panel-sony-acx424akp.o
> > >  obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
> > > +obj-$(CONFIG_DRM_PANEL_TM5P5_NT35596) += panel-tm5p5-nt35596.o
> > >  obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o
> > >  obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
> > >  obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
> > > diff --git a/drivers/gpu/drm/panel/panel-tm5p5-nt35596.c
> > b/drivers/gpu/drm/panel/panel-tm5p5-nt35596.c
> > > new file mode 100644
> > > index 0..c361ab76812b8
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/panel/panel-tm5p5-nt35596.c
> > > @@ -0,0 +1,366 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +struct tm5p5_nt35596 {
> > > + struct drm_panel panel;
> > > + struct mipi_dsi_device *dsi;
> > > + struct regulator_bulk_data supplies[2];
> > > + struct gpio_desc *reset_gpio;
> > > + bool prepared;
> > > +};
> > > +
> > > +static inline struct tm5p5_nt35596 *to_tm5p5_nt35596(struct drm_panel
> > *panel)
> > > +{
> > > + return container_of(panel, struct tm5p5_nt35596, panel);
> > > +}
> > > +
> > > +#define dsi_generic_write_seq(dsi, seq...) do {
> >   \
> > > + static const u8 d[] = { seq };  \
> > > + int ret;\
> > > + ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d));\
> > > + if (ret < 0)\
> > > + return ret; \
> > > + } while (0)
> > > +
> > > +#define dsi_dcs_write_seq(dsi, seq...) do {  \
> > > + static const 

Re: [PATCH v2 1/1] drm/mm: optimize rb_hole_addr rbtree search

[Chris Wilson]

Quoting Nirmoy (2020-04-30 11:30:43)
> 
> On 4/30/20 12:15 PM, Chris Wilson wrote:
> > Quoting Nirmoy Das (2020-04-30 10:58:39)
> >> +void insert_hole_addr(struct rb_root *root, struct drm_mm_node *node)
> > ^ static
> 
> 
> Ah I forgot!
> 
> >
> > (sparse [make C=1] or make W=1 will spot this)
> 
> 
> Thanks for the tip :)
> 
> Nirmoy
> 
> >
> > Looks good, I'll check more carefully later.

Reviewed-by: Chris Wilson 

If you do find some time to add some more tests, that would be great!

Even converting your example into a test-drm_mm benchmark [spending a
few seconds runtime max!] will be very useful.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH hmm v2 2/5] mm/hmm: make hmm_range_fault return 0 or -1

[Jason Gunthorpe]

From: Jason Gunthorpe 

hmm_vma_walk->last is supposed to be updated after every write to the
pfns, so that it can be returned by hmm_range_fault(). However, this is
not done consistently. Fortunately nothing checks the return code of
hmm_range_fault() for anything other than error.

More importantly last must be set before returning -EBUSY as it is used to
prevent reading an output pfn as an input flags when the loop restarts.

For clarity and simplicity make hmm_range_fault() return 0 or -ERRNO. Only
set last when returning -EBUSY.

Acked-by: Felix Kuehling 
Tested-by: Ralph Campbell 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Jason Gunthorpe 
---
 Documentation/vm/hmm.rst|  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |  4 ++--
 drivers/gpu/drm/nouveau/nouveau_svm.c   |  6 +++---
 include/linux/hmm.h |  2 +-
 mm/hmm.c| 25 +
 5 files changed, 16 insertions(+), 23 deletions(-)

diff --git a/Documentation/vm/hmm.rst b/Documentation/vm/hmm.rst
index 4e3e9362afeb10..9924f2caa0184c 100644
--- a/Documentation/vm/hmm.rst
+++ b/Documentation/vm/hmm.rst
@@ -161,7 +161,7 @@ device must complete the update before the driver callback 
returns.
 When the device driver wants to populate a range of virtual addresses, it can
 use::
 
-  long hmm_range_fault(struct hmm_range *range);
+  int hmm_range_fault(struct hmm_range *range);
 
 It will trigger a page fault on missing or read-only entries if write access is
 requested (see below). Page faults use the generic mm page fault code path just
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 6309ff72bd7876..7eb745b8acce0f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -852,12 +852,12 @@ int amdgpu_ttm_tt_get_user_pages(struct amdgpu_bo *bo, 
struct page **pages)
down_read(>mmap_sem);
r = hmm_range_fault(range);
up_read(>mmap_sem);
-   if (unlikely(r <= 0)) {
+   if (unlikely(r)) {
/*
 * FIXME: This timeout should encompass the retry from
 * mmu_interval_read_retry() as well.
 */
-   if ((r == 0 || r == -EBUSY) && !time_after(jiffies, timeout))
+   if (r == -EBUSY && !time_after(jiffies, timeout))
goto retry;
goto out_free_pfns;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c 
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index 645fedd77e21b4..c68e9317cf0740 100644
--- a/drivers/gpu/drm/nouveau/nouveau_svm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_svm.c
@@ -536,7 +536,7 @@ static int nouveau_range_fault(struct nouveau_svmm *svmm,
.pfn_shift = NVIF_VMM_PFNMAP_V0_ADDR_SHIFT,
};
struct mm_struct *mm = notifier->notifier.mm;
-   long ret;
+   int ret;
 
while (true) {
if (time_after(jiffies, timeout))
@@ -548,8 +548,8 @@ static int nouveau_range_fault(struct nouveau_svmm *svmm,
down_read(>mmap_sem);
ret = hmm_range_fault();
up_read(>mmap_sem);
-   if (ret <= 0) {
-   if (ret == 0 || ret == -EBUSY)
+   if (ret) {
+   if (ret == -EBUSY)
continue;
return ret;
}
diff --git a/include/linux/hmm.h b/include/linux/hmm.h
index 7475051100c782..0df27dd03d53d7 100644
--- a/include/linux/hmm.h
+++ b/include/linux/hmm.h
@@ -120,7 +120,7 @@ static inline struct page *hmm_device_entry_to_page(const 
struct hmm_range *rang
 /*
  * Please see Documentation/vm/hmm.rst for how to use the range API.
  */
-long hmm_range_fault(struct hmm_range *range);
+int hmm_range_fault(struct hmm_range *range);
 
 /*
  * HMM_RANGE_DEFAULT_TIMEOUT - default timeout (ms) when waiting for a range
diff --git a/mm/hmm.c b/mm/hmm.c
index 280585833adfc1..f06bcac948a79b 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -174,7 +174,6 @@ static int hmm_vma_walk_hole(unsigned long addr, unsigned 
long end,
}
if (required_fault)
return hmm_vma_fault(addr, end, required_fault, walk);
-   hmm_vma_walk->last = addr;
return hmm_pfns_fill(addr, end, range, HMM_PFN_NONE);
 }
 
@@ -207,7 +206,6 @@ static int hmm_vma_handle_pmd(struct mm_walk *walk, 
unsigned long addr,
pfn = pmd_pfn(pmd) + ((addr & ~PMD_MASK) >> PAGE_SHIFT);
for (i = 0; addr < end; addr += PAGE_SIZE, i++, pfn++)
pfns[i] = hmm_device_entry_from_pfn(range, pfn) | cpu_flags;
-   hmm_vma_walk->last = end;
return 0;
 }
 #else /* CONFIG_TRANSPARENT_HUGEPAGE */
@@ -386,13 +384,10 @@ static int hmm_vma_walk_pmd(pmd_t *pmdp,
r = hmm_vma_handle_pte(walk, addr, end, pmdp, ptep, pfns);
if (r) {
/* hmm_vma_handle_pte() did pte_unmap() */

[PATCH v4 0/7] Convert mtk-dsi to drm_bridge API and get EDID for ps8640 bridge

[Enric Balletbo i Serra]

The PS8640 dsi-to-eDP bridge driver is using the panel bridge API,
however, not all the components in the chain have been ported to the
drm_bridge API. Actually, when a panel is attached the default panel's mode
is used, but in some cases we can't get display up if mode getting from
eDP control EDID is not chosen.

This series address that problem, first implements the .get_edid()
callback in the PS8640 driver (which is not used until the conversion is
done) and then, converts the Mediatek DSI driver to use the drm_bridge
API.

As far as I know, we're the only users of the mediatek dsi driver in
mainline, so should be safe to switch to the new chain of drm_bridge API
unconditionally.

The patches has been tested on a Acer Chromebook R13 (Elm) running a
Chrome OS userspace and checking that the valid EDID mode reported by
the bridge is selected.

Enric Balletbo i Serra (7):
  drm/bridge: ps8640: Get the EDID from eDP control
  drm/bridge_connector: Set default status connected for eDP connectors
  drm/mediatek: mtk_dsi: Rename bridge to next_bridge
  drm/mediatek: mtk_dsi: Convert to bridge driver
  drm/mediatek: mtk_dsi: Use simple encoder
  drm/mediatek: mtk_dsi: Use the drm_panel_bridge API
  drm/mediatek: mtk_dsi: Create connector for bridges

 drivers/gpu/drm/bridge/parade-ps8640.c |  12 ++
 drivers/gpu/drm/drm_bridge_connector.c |   1 +
 drivers/gpu/drm/mediatek/mtk_dsi.c | 277 -
 3 files changed, 97 insertions(+), 193 deletions(-)

-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 7/7] drm/mediatek: mtk_dsi: Create connector for bridges

[Enric Balletbo i Serra]

Use the drm_bridge_connector helper to create a connector for pipelines
that use drm_bridge. This allows splitting connector operations across
multiple bridges when necessary, instead of having the last bridge in
the chain creating the connector and handling all connector operations
internally.

Signed-off-by: Enric Balletbo i Serra 
Acked-by: Sam Ravnborg 
---

Changes in v4: None
Changes in v3:
- Move the bridge.type line to the patch that adds drm_bridge support. (Laurent 
Pinchart)

Changes in v2: None

 drivers/gpu/drm/mediatek/mtk_dsi.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 4f3bd095c1ee..471fcafdf348 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -183,6 +184,7 @@ struct mtk_dsi {
struct drm_encoder encoder;
struct drm_bridge bridge;
struct drm_bridge *next_bridge;
+   struct drm_connector *connector;
struct phy *phy;
 
void __iomem *regs;
@@ -977,10 +979,19 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, 
struct mtk_dsi *dsi)
 */
dsi->encoder.possible_crtcs = 1;
 
-   ret = drm_bridge_attach(>encoder, >bridge, NULL, 0);
+   ret = drm_bridge_attach(>encoder, >bridge, NULL,
+   DRM_BRIDGE_ATTACH_NO_CONNECTOR);
if (ret)
goto err_cleanup_encoder;
 
+   dsi->connector = drm_bridge_connector_init(drm, >encoder);
+   if (IS_ERR(dsi->connector)) {
+   DRM_ERROR("Unable to create bridge connector\n");
+   ret = PTR_ERR(dsi->connector);
+   goto err_cleanup_encoder;
+   }
+   drm_connector_attach_encoder(dsi->connector, >encoder);
+
return 0;
 
 err_cleanup_encoder:
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 3/7] drm/mediatek: mtk_dsi: Rename bridge to next_bridge

[Enric Balletbo i Serra]

This is really a cosmetic change just to make a bit more readable the
code after convert the driver to drm_bridge. The bridge variable name
will be used by the encoder drm_bridge, and the chained bridge will be
named next_bridge.

Signed-off-by: Enric Balletbo i Serra 
Reviewed-by: Laurent Pinchart 
Acked-by: Sam Ravnborg 
---

Changes in v4: None
Changes in v3:
- Replace s/bridge/next bridge/ for comment. (Laurent Pinchart)

Changes in v2: None

 drivers/gpu/drm/mediatek/mtk_dsi.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index cfa45d6abd74..37b8d7ffd835 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -182,7 +182,7 @@ struct mtk_dsi {
struct drm_encoder encoder;
struct drm_connector conn;
struct drm_panel *panel;
-   struct drm_bridge *bridge;
+   struct drm_bridge *next_bridge;
struct phy *phy;
 
void __iomem *regs;
@@ -902,9 +902,10 @@ static int mtk_dsi_create_conn_enc(struct drm_device *drm, 
struct mtk_dsi *dsi)
 */
dsi->encoder.possible_crtcs = 1;
 
-   /* If there's a bridge, attach to it and let it create the connector */
-   if (dsi->bridge) {
-   ret = drm_bridge_attach(>encoder, dsi->bridge, NULL, 0);
+   /* If there's a next bridge, attach to it and let it create the 
connector */
+   if (dsi->next_bridge) {
+   ret = drm_bridge_attach(>encoder, dsi->next_bridge, NULL,
+   0);
if (ret) {
DRM_ERROR("Failed to attach bridge to drm\n");
goto err_encoder_cleanup;
@@ -1185,7 +1186,7 @@ static int mtk_dsi_probe(struct platform_device *pdev)
}
 
ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
- >panel, >bridge);
+ >panel, >next_bridge);
if (ret)
goto err_unregister_host;
 
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH hmm v2 0/5] Adjust hmm_range_fault() API

[Jason Gunthorpe]

From: Jason Gunthorpe 

The API is a bit complicated for the uses we actually have, and
disucssions for simplifying have come up a number of times.

This small series removes the customizable pfn format and simplifies the
return code of hmm_range_fault()

All the drivers are adjusted to process in the simplified format.
I would appreciated tested-by's for the two drivers, thanks!

v2:
 - Move call chain to commit message
 - Fix typo of HMM_PFN_REQ_FAULT
 - Move nouveau_hmm_convert_pfn() to nouveau_svm.c
 - Add acks and tested-bys
v1: 
https://lore.kernel.org/r/0-v1-4eb72686de3c+5062-hmm_no_flags_...@mellanox.com

Cc: Christoph Hellwig 
Cc: John Hubbard 
Cc: Jérôme Glisse 
Cc: Ben Skeggs 
To: Ralph Campbell 
Cc: nouv...@lists.freedesktop.org
Cc: Niranjana Vishwanathapura 
Cc: intel-...@lists.freedesktop.org
Cc: "Kuehling, Felix" 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: "David (ChunMing) Zhou" 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc: "Yang, Philip" 
To: linux...@kvack.org

Jason Gunthorpe (5):
  mm/hmm: make CONFIG_DEVICE_PRIVATE into a select
  mm/hmm: make hmm_range_fault return 0 or -1
  drm/amdgpu: remove dead code after hmm_range_fault()
  mm/hmm: remove HMM_PFN_SPECIAL
  mm/hmm: remove the customizable pfn format from hmm_range_fault

 Documentation/vm/hmm.rst|  28 ++--
 arch/powerpc/Kconfig|   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |  56 +++
 drivers/gpu/drm/nouveau/Kconfig |   2 +-
 drivers/gpu/drm/nouveau/nouveau_dmem.c  |  27 +---
 drivers/gpu/drm/nouveau/nouveau_dmem.h  |   3 +-
 drivers/gpu/drm/nouveau/nouveau_svm.c   |  94 
 include/linux/hmm.h | 109 +-
 mm/Kconfig  |   7 +-
 mm/hmm.c| 185 +++-
 10 files changed, 217 insertions(+), 296 deletions(-)

-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [RFC PATCH 3/4] drm/etnaviv: Change order of enabling clocks to fix boot on i.MX8MM

[Peng Fan]

> Subject: Re: [RFC PATCH 3/4] drm/etnaviv: Change order of enabling clocks to
> fix boot on i.MX8MM
> 
> On 30.04.20 16:35, Lucas Stach wrote:
> > Am Donnerstag, den 30.04.2020, 12:46 + schrieb Schrempf Frieder:
> >> From: Frieder Schrempf 
> >>
> >> On some i.MX8MM devices the boot hangs when enabling the GPU clocks.
> >> Changing the order of clock initalization to
> >>
> >> core -> shader -> bus -> reg
> >>
> >> fixes the issue. This is the same order used in the imx platform code
> >> of the downstream GPU driver in the NXP kernel [1]. For the sake of
> >> consistency we also adjust the order of disabling the clocks to the
> >> reverse.
> >>
> >> [1]
> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsou
> >>
> rce.codeaurora.org%2Fexternal%2Fimx%2Flinux-imx%2Ftree%2Fdrivers%2F
> mx
> >>
> c%2Fgpu-viv%2Fhal%2Fos%2Flinux%2Fkernel%2Fplatform%2Ffreescale%2Fgc
> _h
> >>
> al_kernel_platform_imx.c%3Fh%3Dimx_5.4.3_2.0.0%23n1538data=02
> %7C
> >>
> 01%7Cpeng.fan%40nxp.com%7Cdc7da53f665e4f567e3008d7ed1c27e0%7C6
> 86ea1d3
> >>
> bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637238577497969787sda
> ta=QRHzu
> >> C6gSKy%2F6y2FTRvlNF5t7DmJIvTgBESYKchI%2FDw%3Dreserved=0
> >
> > I don't see why the order of the clocks is important. Is this really a
> > GPU issue? As in: does a GPU access hang when enabling the clocks in
> > the wrong order? Or is this a clock driver issue with a clock access
> > hanging due to an upstream clock still being disabled?
> 
> Actually you might be right with this being a clock driver issue. The hanging
> happens while enabling the clocks (unrelated to any GPU register access). The
> strange thing is that most of the devices we have don't care and work as is
> and some devices reliably fail each time when enabling the clocks in the
> "wrong" order.
> 
> So I guess this could indeed be some clock being enabled with an upstream
> PLL not having locked yet or something.

https://patchwork.kernel.org/cover/11433775/

Will this pachset help?

The i.MX8M CCM root mux code in Linux needs a fix.

Regards,
Peng.

> 
> >
> > Regards,
> > Lucas
> >
> >> Signed-off-by: Frieder Schrempf 
> >> ---
> >>   drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 42
> +--
> >>   1 file changed, 21 insertions(+), 21 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> >> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> >> index 7b138d4dd068..424b2e5951f0 100644
> >> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> >> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> >> @@ -1487,55 +1487,55 @@ static int etnaviv_gpu_clk_enable(struct
> etnaviv_gpu *gpu)
> >>   {
> >>int ret;
> >>
> >> -  if (gpu->clk_reg) {
> >> -  ret = clk_prepare_enable(gpu->clk_reg);
> >> +  if (gpu->clk_core) {
> >> +  ret = clk_prepare_enable(gpu->clk_core);
> >>if (ret)
> >>return ret;
> >>}
> >>
> >> -  if (gpu->clk_bus) {
> >> -  ret = clk_prepare_enable(gpu->clk_bus);
> >> +  if (gpu->clk_shader) {
> >> +  ret = clk_prepare_enable(gpu->clk_shader);
> >>if (ret)
> >> -  goto disable_clk_reg;
> >> +  goto disable_clk_core;
> >>}
> >>
> >> -  if (gpu->clk_core) {
> >> -  ret = clk_prepare_enable(gpu->clk_core);
> >> +  if (gpu->clk_bus) {
> >> +  ret = clk_prepare_enable(gpu->clk_bus);
> >>if (ret)
> >> -  goto disable_clk_bus;
> >> +  goto disable_clk_shader;
> >>}
> >>
> >> -  if (gpu->clk_shader) {
> >> -  ret = clk_prepare_enable(gpu->clk_shader);
> >> +  if (gpu->clk_reg) {
> >> +  ret = clk_prepare_enable(gpu->clk_reg);
> >>if (ret)
> >> -  goto disable_clk_core;
> >> +  goto disable_clk_bus;
> >>}
> >>
> >>return 0;
> >>
> >> -disable_clk_core:
> >> -  if (gpu->clk_core)
> >> -  clk_disable_unprepare(gpu->clk_core);
> >>   disable_clk_bus:
> >>if (gpu->clk_bus)
> >>clk_disable_unprepare(gpu->clk_bus);
> >> -disable_clk_reg:
> >> -  if (gpu->clk_reg)
> >> -  clk_disable_unprepare(gpu->clk_reg);
> >> +disable_clk_shader:
> >> +  if (gpu->clk_shader)
> >> +  clk_disable_unprepare(gpu->clk_shader);
> >> +disable_clk_core:
> >> +  if (gpu->clk_core)
> >> +  clk_disable_unprepare(gpu->clk_core);
> >>
> >>return ret;
> >>   }
> >>
> >>   static int etnaviv_gpu_clk_disable(struct etnaviv_gpu *gpu)
> >>   {
> >> +  if (gpu->clk_reg)
> >> +  clk_disable_unprepare(gpu->clk_reg);
> >> +  if (gpu->clk_bus)
> >> +  clk_disable_unprepare(gpu->clk_bus);
> >>if (gpu->clk_shader)
> >>clk_disable_unprepare(gpu->clk_shader);
> >>if (gpu->clk_core)
> >>clk_disable_unprepare(gpu->clk_core);
> >> -  if (gpu->clk_bus)
> >> -  clk_disable_unprepare(gpu->clk_bus);
> >> -  if (gpu->clk_reg)
> >> -  clk_disable_unprepare(gpu->clk_reg);
> >>
> >>return 0;
> >> 

[PATCH] drivers: gpu: drm: Add MDP5 configuration for MSM8x36 and its derivatives, such as MSM8939.

[Konrad Dybcio]

Signed-off-by: Konrad Dybcio 
---
 drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 70 
 1 file changed, 70 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
index e3c4c250238b7..1c7de7d6870cf 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
@@ -342,6 +342,75 @@ static const struct mdp5_cfg_hw msm8x16_config = {
.max_clk = 32000,
 };
 
+static const struct mdp5_cfg_hw msm8x36_config = {
+   .name = "msm8x36",
+   .mdp = {
+   .count = 1,
+   .base = { 0x0 },
+   .caps = MDP_CAP_SMP |
+   0,
+   },
+   .smp = {
+   .mmb_count = 8,
+   .mmb_size = 10240,
+   .clients = {
+   [SSPP_VIG0] = 1, [SSPP_DMA0] = 4,
+   [SSPP_RGB0] = 7, [SSPP_RGB1] = 8,
+   },
+   },
+   .ctl = {
+   .count = 3,
+   .base = { 0x01000, 0x01200, 0x01400 },
+   .flush_hw_mask = 0x4003,
+   },
+   .pipe_vig = {
+   .count = 1,
+   .base = { 0x04000 },
+   .caps = MDP_PIPE_CAP_HFLIP | MDP_PIPE_CAP_VFLIP |
+   MDP_PIPE_CAP_SCALE | MDP_PIPE_CAP_CSC |
+   MDP_PIPE_CAP_DECIMATION,
+   },
+   .pipe_rgb = {
+   .count = 2,
+   .base = { 0x14000, 0x16000 },
+   .caps = MDP_PIPE_CAP_HFLIP | MDP_PIPE_CAP_VFLIP |
+   MDP_PIPE_CAP_DECIMATION,
+   },
+   .pipe_dma = {
+   .count = 1,
+   .base = { 0x24000 },
+   .caps = MDP_PIPE_CAP_HFLIP | MDP_PIPE_CAP_VFLIP,
+   },
+   .lm = {
+   .count = 1,
+   .base = { 0x44000 },
+   .instances = {
+   { .id = 0, .pp = 0, .dspp = 0,
+ .caps = MDP_LM_CAP_DISPLAY, },
+   },
+   .nb_stages = 8,
+   .max_width = 2048,
+   .max_height = 0x,
+   },
+   .pp = {
+   .count = 1,
+   .base = { 0x7 },
+   },
+
+   .dspp = {
+   .count = 1,
+   .base = { 0x54000 },
+   },
+   .intf = {
+   .base = { 0x0, 0x6a800, 0x6b000 },
+   .connect = {
+   [0] = INTF_DISABLED,
+   [1] = INTF_DSI,
+   [2] = INTF_DSI,
+   },
+   },
+   .max_clk = 36667,
+};
 static const struct mdp5_cfg_hw msm8x94_config = {
.name = "msm8x94",
.mdp = {
@@ -840,6 +909,7 @@ static const struct mdp5_cfg_handler cfg_handlers_v1[] = {
{ .revision = 2, .config = { .hw = _config } },
{ .revision = 3, .config = { .hw = _config } },
{ .revision = 6, .config = { .hw = _config } },
+   { .revision = 8, .config = { .hw = _config } },
{ .revision = 9, .config = { .hw = _config } },
{ .revision = 7, .config = { .hw = _config } },
{ .revision = 11, .config = { .hw = _config } },
-- 
2.26.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] add dts node for drm panel driver ili9341 add dts i2c3 for stmpe touch add dts spi5 for gyro & ili9341

[dillon min]

Hi Alexandre,

Alexandre Torgue  于2020年4月30日周四 下午7:45写道：

>
>
> On 4/30/20 12:26 PM, dillon min wrote:
> > Hi Alexandre,
> >
> > Alexandre Torgue  > > 于2020年4月30日周四 下午5:57写道：
> >
> > Hi
> >
> > On 4/30/20 11:43 AM, dillon.min...@gmail.com
> >  wrote:
> >  > From: dillon min  > >
> >  >
> >  > Signed-off-by: dillon min  > >
> >
> > Commit title should be ARM: dts: stm32: bla bla on stm32f429 and
> please
> > a commit message.
> >
> >
> > *okay, thanks for your quicky response, this is my first kernel pull
> > request, i will resubmit all patchsets following the history submits
> > style who was did.*
>
> ok no pb. In general way you have to execute ./scripts/checkpatch.pl to
> check some style errors before sending. Use ./scripts/get_maintainer.pl
> to see to who you have to send the patch. When you have several patches
> in a series, you need to have a cover-letter which explains the aim of
> your series. To have an idea of commit format just use git log on the
> file changed to see how previous accepted commi have been written.
>
> More details here: Documentation/process/submitting-patches.rst
>
> okay, thanks alexandre, i will go through these docs. currently i'm on may
day holiday,  will be back at  next wensday.
after go back to work. i will separate this patch to five part with 9
patchs , should be more clear

dts releated
1,  ARM: dts: stm32: Add i2c3 node for stm32f429
2,  ARM: dts: stm32: Add drm panel ili9341 nodes connect to ldtc
support for stm32f429-disco board
3,  ARM: dts: stm32: Add stmpe811 touch screen support for
stm32f429-disco board
4,  ARM: dts: stm32: Add l3gd20 gyroscope sensor support for
stm32f429-disco board

clk releated
1, clk: stm32: Fix ltdc loading hang in set clk rate, pll_hw set to
clks[PLL_VCO_SAI] but not clks[PLL_SAI]
2, clk: stm32: Add CLK_IGNORE_UNUSED flags for ltdc, make sure ltdc clk
not be released after system startup

spi releated
1, spi: stm32: Add transfer mode SPI_SIMPLE_RX, SPI_3WIRE_RX support
for stm32f4

drm releated
1, drm/panel: Add panel driver ilitek-ili9341

doc releated
 1, dt-bindings: display: panel: Add binding document for Ilitek Ili9341

TODO:
ltdc was verified by fbcon+logo, uname -a > /dev/tty0 , need more time to
write test code with libdrm to verify osd
stmpe811 need cross compile tslib to do touch screen calibration
l3gd20 was tested by read data from /sys/bus/iio, need cross compile libiio
to be verified by application with libiio
add dma2d to ltdc driver to speed up graphic render
dcmi camera with ov5640, the sdram might be not enough to support this.
currently after zImage load to sdram,
just leave less than 2M bytes for application.

>
> >  > ---
> >  >   .../bindings/display/panel/ilitek,ili9341.txt  | 42
> +++
> >  >   arch/arm/boot/dts/stm32f4-pinctrl.dtsi | 79
> > +++
> >  >   arch/arm/boot/dts/stm32f429-disco.dts  | 88
> > ++
> >  >   arch/arm/boot/dts/stm32f429.dtsi   | 12 +++
> >  >   4 files changed, 221 insertions(+)
> >  >   create mode 100644
> > Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
> >  >
> >  > diff --git
> > a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
> > b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
> >
> > This binding description should be in a separate patch and you have
> to
> > write in YAML format.
> >
> > *okay, will do it later. *
> >
> >
> >  > new file mode 100644
> >  > index 000..f5a4e55
> >  > --- /dev/null
> >  > +++
> > b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
> >  > @@ -0,0 +1,42 @@
> >  > +Ilitek ILI9341 TFT panel driver with SPI control bus
> >  > +
> >  > +This is a driver for 240x320 TFT panels, accepting a rgb input
> >  > +streams that get adapted and scaled to the panel.
> >  > +
> >  > +Required properties:
> >  > +  - compatible: "stm32f429-disco,ltdc-panel", "ilitek,ili9341"
> >  > +(full system-specific compatible is always required to look
> > up configuration)
> >  > +  - reg: address of the panel on the SPI bus
> >  > +
> >  > +Optional properties:
> >  > +  - reset-gpios: a GPIO spec for the reset pin, see gpio/gpio.txt
> >  > +  - dc-gpios: a GPIO spec for the dc pin, see gpio/gpio.txt
> >  > +
> >  > +  The following optional properties only apply to RGB input mode:
> >  > +
> >  > +  - pixelclk-active: see display/panel/display-timing.txt
> >  > +  - de-active: see display/panel/display-timing.txt
> >  > +  - hsync-active: see display/panel/display-timing.txt
> >  > +  - vsync-active: see 

[PATCH] drm/stm: Fix an error handling path in 'stm_drm_platform_probe()'

[Christophe JAILLET]

If 'drm_dev_register()' fails, a call to 'drv_load()' must be undone, as
already done in the remove function.

Fixes: b759012c5fa7 ("drm/stm: Add STM32 LTDC driver")
Signed-off-by: Christophe JAILLET 
---
 drivers/gpu/drm/stm/drv.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
index ea9fcbdc68b3..9a66e350abd5 100644
--- a/drivers/gpu/drm/stm/drv.c
+++ b/drivers/gpu/drm/stm/drv.c
@@ -206,12 +206,14 @@ static int stm_drm_platform_probe(struct platform_device 
*pdev)
 
ret = drm_dev_register(ddev, 0);
if (ret)
-   goto err_put;
+   goto err_unload;
 
drm_fbdev_generic_setup(ddev, 16);
 
return 0;
 
+err_unload:
+   drv_unload(ddev);
 err_put:
drm_dev_put(ddev);
 
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/msm/dpu: ensure device suspend happens during PM sleep

[Kalyan Thota]

"The PM core always increments the runtime usage counter
before calling the ->suspend() callback and decrements it
after calling the ->resume() callback"

DPU and DSI are managed as runtime devices. When
suspend is triggered, PM core adds a refcount on all the
devices and calls device suspend, since usage count is
already incremented, runtime suspend was not getting called
and it kept the clocks on which resulted in target not
entering into XO shutdown.

Add changes to force suspend on runtime devices during pm sleep.

Changes in v1:
 - Remove unnecessary checks in the function
_dpu_kms_disable_dpu (Rob Clark).

Changes in v2:
 - Avoid using suspend_late to reset the usagecount
   as suspend_late might not be called during suspend
   call failures (Doug).

Changes in v3:
 - Use force suspend instead of managing device usage_count
   via runtime put and get API's to trigger callbacks (Doug).

Changes in v4:
 - Check the return values of pm_runtime_force_suspend and
   pm_runtime_force_resume API's and pass appropriately (Doug).

Changes in v5:
 - With v4 patch, test cycle has uncovered issues in device resume.

   On bubs: cmd tx failures were seen as SW is sending panel off
   commands when the dsi resources are turned off.

   Upon suspend, DRM driver will issue a NULL composition to the
   dpu, followed by turning off all the HW blocks.

   v5 changes will serialize the NULL commit and resource unwinding
   by handling them under PM prepare and PM complete phases there by
   ensuring that clks are on when panel off commands are being
   processed.

Signed-off-by: Kalyan Thota 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c |  2 ++
 drivers/gpu/drm/msm/dsi/dsi.c   |  2 ++
 drivers/gpu/drm/msm/msm_drv.c   | 20 
 3 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index ce19f1d..b886d9d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1123,6 +1123,8 @@ static int __maybe_unused dpu_runtime_resume(struct 
device *dev)
 
 static const struct dev_pm_ops dpu_pm_ops = {
SET_RUNTIME_PM_OPS(dpu_runtime_suspend, dpu_runtime_resume, NULL)
+   SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+   pm_runtime_force_resume)
 };
 
 static const struct of_device_id dpu_dt_match[] = {
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index 55ea4bc2..62704885 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -161,6 +161,8 @@ static int dsi_dev_remove(struct platform_device *pdev)
 
 static const struct dev_pm_ops dsi_pm_ops = {
SET_RUNTIME_PM_OPS(msm_dsi_runtime_suspend, msm_dsi_runtime_resume, 
NULL)
+   SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+   pm_runtime_force_resume)
 };
 
 static struct platform_driver dsi_driver = {
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 7d985f8..47d492b 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1036,7 +1036,7 @@ static int msm_ioctl_submitqueue_close(struct drm_device 
*dev, void *data,
 };
 
 #ifdef CONFIG_PM_SLEEP
-static int msm_pm_suspend(struct device *dev)
+static int msm_pm_prepare(struct device *dev)
 {
struct drm_device *ddev = dev_get_drvdata(dev);
struct msm_drm_private *priv = ddev->dev_private;
@@ -1054,18 +1054,28 @@ static int msm_pm_suspend(struct device *dev)
return 0;
 }
 
-static int msm_pm_resume(struct device *dev)
+static void msm_pm_complete(struct device *dev)
 {
struct drm_device *ddev = dev_get_drvdata(dev);
struct msm_drm_private *priv = ddev->dev_private;
int ret;
 
if (WARN_ON(!priv->pm_state))
-   return -ENOENT;
+   return;
 
ret = drm_atomic_helper_resume(ddev, priv->pm_state);
if (!ret)
priv->pm_state = NULL;
+}
+
+static int msm_pm_resume(struct device *dev)
+{
+   int ret;
+
+   /* unwind runtime_disable called by force suspend */
+   pm_runtime_enable(dev);
+
+   ret = pm_runtime_resume(dev);
 
return ret;
 }
@@ -1102,8 +1112,10 @@ static int msm_runtime_resume(struct device *dev)
 #endif
 
 static const struct dev_pm_ops msm_pm_ops = {
-   SET_SYSTEM_SLEEP_PM_OPS(msm_pm_suspend, msm_pm_resume)
+   SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, msm_pm_resume)
SET_RUNTIME_PM_OPS(msm_runtime_suspend, msm_runtime_resume, NULL)
+   .prepare = msm_pm_prepare,
+   .complete = msm_pm_complete,
 };
 
 /*
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: check to see if SIMD registers are available before using SIMD

[Jason A. Donenfeld]

On Fri, May 1, 2020 at 4:42 AM Sebastian Andrzej Siewior
 wrote:
>Reviewed-by: Sebastian Andrzej Siewior 

Thanks.

>
> May I ask how large the memcpy can be? I'm asking in case it is large
> and an explicit rescheduling point might be needed.

Yea I was worried about that too. I'm not an i915 developer, but so
far as I can tell:

- The path from intel_engine_cmd_parser is  <= 256 KiB for "known
users", so that's rather large.
- The path from perf_memcpy is either 4k, 64k, or 4M, depending on the
type of object, so that seems gigantic, but I think that might be
selftest code.
- The path from compress_page appears to be PAGE_SIZE, so 4k, which
meshes with the limits we set agreed on few weeks ago for the crypto
stuff.
- The path from guc_read_update_log_buffer appears to be 8k, 32k, 2M,
or 8M, depending on the type of object, so that seems absurdly huge
and doesn't appear to be selftest code either like the other case.

I have no doubt the i915 developers will jump in here waving their
arms, but either way, it sure seems to me like you might have a point.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: check to see if SIMD registers are available before using SIMD

[Jason A. Donenfeld]

On Fri, May 1, 2020 at 12:07 PM Christoph Hellwig  wrote:
>
> On Thu, Apr 30, 2020 at 04:10:16PM -0600, Jason A. Donenfeld wrote:
> > Sometimes it's not okay to use SIMD registers, the conditions for which
> > have changed subtly from kernel release to kernel release. Usually the
> > pattern is to check for may_use_simd() and then fallback to using
> > something slower in the unlikely case SIMD registers aren't available.
> > So, this patch fixes up i915's accelerated memcpy routines to fallback
> > to boring memcpy if may_use_simd() is false.
>
> Err, why does i915 implements its own uncached memcpy instead of relying
> on core functionality to start with?

I was wondering the same. It sure does seem like this ought to be more
generalized functionality, with a name that represents the type of
transfer it's optimized for (wc or similar).
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 7/7] drm/mediatek: mtk_dsi: Create connector for bridges

[Enric Balletbo i Serra]

Hi Chun-Kuang,

Thank you for your review.

On 1/5/20 16:26, Chun-Kuang Hu wrote:
> Hi, Enric:
> 
> Enric Balletbo i Serra  於 2020年4月17日 週五 
> 下午11:06寫道：
>>
>> Use the drm_bridge_connector helper to create a connector for pipelines
>> that use drm_bridge. This allows splitting connector operations across
>> multiple bridges when necessary, instead of having the last bridge in
>> the chain creating the connector and handling all connector operations
>> internally.
>>
>> Signed-off-by: Enric Balletbo i Serra 
>> ---
>>
>> Changes in v3:
>> - Move the bridge.type line to the patch that adds drm_bridge support. 
>> (Laurent Pinchart)
>>
>> Changes in v2: None
>>
>>  drivers/gpu/drm/mediatek/mtk_dsi.c | 13 -
>>  1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
>> b/drivers/gpu/drm/mediatek/mtk_dsi.c
>> index 157097c63b23..85f76b01ae4d 100644
>> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
>> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
>> @@ -17,6 +17,7 @@
>>
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -183,6 +184,7 @@ struct mtk_dsi {
>> struct drm_encoder encoder;
>> struct drm_bridge bridge;
>> struct drm_bridge *next_bridge;
>> +   struct drm_connector *connector;
>> struct phy *phy;
>>
>> void __iomem *regs;
>> @@ -977,10 +979,19 @@ static int mtk_dsi_encoder_init(struct drm_device 
>> *drm, struct mtk_dsi *dsi)
>>  */
>> dsi->encoder.possible_crtcs = 1;
>>
>> -   ret = drm_bridge_attach(>encoder, >bridge, NULL, 0);
>> +   ret = drm_bridge_attach(>encoder, >bridge, NULL,
>> +   DRM_BRIDGE_ATTACH_NO_CONNECTOR);
>> if (ret)
>> goto err_cleanup_encoder;
>>
>> +   dsi->connector = drm_bridge_connector_init(drm, >encoder);
>> +   if (IS_ERR(dsi->connector)) {
>> +   DRM_ERROR("Unable to create bridge connector\n");
>> +   ret = PTR_ERR(dsi->connector);
>> +   goto err_cleanup_encoder;
>> +   }
>> +   drm_connector_attach_encoder(dsi->connector, >encoder);
>> +
> 
> I'm not very clear about how brige-connector works, but why connector
> does not attach to panel?
> 

Laurent or other drm maintainers might have more details than me, but, AFAIK the
drm_bridge_connector_init initializes a connector for a chain of bridges that
starts at the @encoder. At this point you don't know which bridge is connected
to the panel physically but doesn't really matter as what you know is that will
be only one connector in the  chain.

Thanks,
 Enric

> Regards,
> Chun-Kuang.
> 
>> return 0;
>>
>>  err_cleanup_encoder:
>> --
>> 2.25.1
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 00/14] Move the ReST files from Documentation/*.txt

[Mauro Carvalho Chehab]

The main goal of this series is to cleanup the Documentation/
directory.

Most of the files under Documentation/*.txt are already in ReST format.
They just need to be moved to some place. So, most of the work here is
to just move files for them to generate an output using the docs building
system.

After this change, the  Documentation/ dir will contain:

- the main ReST file:
- index.rst

- TUX and its copyright:
- logo.gif and COPYING-logo

- Files required to do ReST builds:
- .gitignore, Makefile,  conf.py,  docutils.conf,  Kconfig

- A pre-git file used to generate patches:
- dontdiff
  (I guess we should get rid of it, as I doubt this is useful those days).

-

Besides the above rightful files, the Documentation/ dir will also
contain some left-overs:

- two somewhat new ReST files that should be moved to somewhere:
- asm-annotations.rst and watch_queue.rst

- Two files that helps people looking for some well known documents
  that are referenced at the web, pointing to their new location inside
  the process/ dir:
- SubmittingPatches and CodingStyle

- Three .txt files that weren't converted to ReST:
- atomic_bitops.txt, memory-barriers.txt, atomic_t.txt

It should be noticed that I'm in doubt about the location of some files,
and some stuff may well belong to a trash can. So, this series create
a temporary place for orphaned documents in the form of a
Documentation/staging directory.

This series is also on my development git tree, at:

https://git.linuxtv.org/mchehab/experimental.git/log/?h=rename-main-docs

The built output documentation on html format is at:

https://www.infradead.org/~mchehab/kernel_docs/

(it contains also other documents I converted to ReST)


Mauro Carvalho Chehab (14):
  docs: move DMA kAPI to Documentation/core-api
  docs: add bus-virt-phys-mapping.txt to core-api
  docs: fix references for DMA*.txt files
  docs: move IPMI.txt to the driver API book
  docs: fix references for ipmi.rst file
  docs: debugging-via-ohci1394.txt: add it to the core-api book
  docs: add IRQ documentation at the core-api book
  docs: move kobject and kref docs into the core-api book
  docs: move digsig docs to the security book
  docs: move locking-specific documenta to locking/ directory
  docs: move other kAPI documents to core-api
  docs: move remaining stuff under Documentation/*.txt to
Documentation/staging
  docs: staging: don't use literalinclude
  docs: staging: use small font for literal includes

 Documentation/PCI/pci.rst |  6 +-
 Documentation/admin-guide/hw-vuln/l1tf.rst|  2 +-
 .../admin-guide/kernel-parameters.txt |  2 +-
 .../admin-guide/kernel-per-CPU-kthreads.rst   |  2 +-
 Documentation/admin-guide/sysctl/vm.rst   |  2 +-
 Documentation/block/biodoc.rst|  2 +-
 .../bus-virt-phys-mapping.rst}|  2 +-
 .../debugging-via-ohci1394.rst}   |  0
 .../dma-api-howto.rst}|  0
 .../{DMA-API.txt => core-api/dma-api.rst} |  6 +-
 .../dma-attributes.rst}   |  0
 .../dma-isa-lpc.rst}  |  2 +-
 Documentation/core-api/index.rst  | 14 +
 .../{IRQ.txt => core-api/irq/concepts.rst}|  0
 Documentation/core-api/irq/index.rst  | 11 
 .../irq/irq-affinity.rst} |  0
 .../irq/irq-domain.rst}   |  3 +-
 .../irq/irqflags-tracing.rst} |  0
 Documentation/core-api/kobject.rst|  2 +-
 Documentation/{kref.txt => core-api/kref.rst} |  0
 .../{mailbox.txt => core-api/mailbox.rst} |  0
 .../nommu-mmap.rst}   |  0
 .../this_cpu_ops.rst} |  0
 .../unaligned-memory-access.rst}  |  0
 Documentation/driver-api/index.rst|  1 +
 .../{IPMI.txt => driver-api/ipmi.rst} |  0
 Documentation/driver-api/usb/dma.rst  |  6 +-
 Documentation/gpu/drm-mm.rst  |  2 +-
 Documentation/ia64/irq-redir.rst  |  2 +-
 Documentation/index.rst   | 13 
 .../futex-requeue-pi.rst} |  0
 .../hwspinlock.rst}   |  0
 Documentation/locking/index.rst   |  7 +++
 .../percpu-rw-semaphore.rst}  |  0
 .../{pi-futex.txt => locking/pi-futex.rst}|  0
 .../preempt-locking.rst}  |  0
 .../robust-futex-ABI.rst} |  0
 .../robust-futexes.rst}   |  0
 Documentation/locking/rt-mutex.rst|  2 +-
 Documentation/memory-barriers.txt |  6 +-
 Documentation/networking/scaling.rst  |  4 +-
 .../{digsig.txt => security/digsig.rst}   |  0
 Documentation/security/index.rst  |  1 +
 .../{crc32.txt => staging/crc32.rst}  |  0
 Documentation/staging/index.rst   | 59 +++
 .../{kprobes.txt => 

[PATCH v4 1/7] drm/bridge: ps8640: Get the EDID from eDP control

[Enric Balletbo i Serra]

The PS8640 DSI-to-eDP bridge can retrieve the EDID, so implement the
.get_edid callback and set the flag to indicate the core to use it.

Signed-off-by: Enric Balletbo i Serra 
Reviewed-by: Laurent Pinchart 
Acked-by: Sam Ravnborg 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/parade-ps8640.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
index 4b099196afeb..13755d278db6 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -242,8 +242,18 @@ static int ps8640_bridge_attach(struct drm_bridge *bridge,
return ret;
 }
 
+static struct edid *ps8640_bridge_get_edid(struct drm_bridge *bridge,
+  struct drm_connector *connector)
+{
+   struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+
+   return drm_get_edid(connector,
+   ps_bridge->page[PAGE0_DP_CNTL]->adapter);
+}
+
 static const struct drm_bridge_funcs ps8640_bridge_funcs = {
.attach = ps8640_bridge_attach,
+   .get_edid = ps8640_bridge_get_edid,
.post_disable = ps8640_post_disable,
.pre_enable = ps8640_pre_enable,
 };
@@ -294,6 +304,8 @@ static int ps8640_probe(struct i2c_client *client)
 
ps_bridge->bridge.funcs = _bridge_funcs;
ps_bridge->bridge.of_node = dev->of_node;
+   ps_bridge->bridge.ops = DRM_BRIDGE_OP_EDID;
+   ps_bridge->bridge.type = DRM_MODE_CONNECTOR_eDP;
 
ps_bridge->page[PAGE0_DP_CNTL] = client;
 
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/2] Add support for TM5P5 NT35596 video mode panel

[Konrad Dybcio]

Very strange.. I just fetched drm-misc-next and had no issues building...

Thanks for your initial thoughts!

pt., 1 maj 2020 o 23:00 Sam Ravnborg  napisał(a):
>
> Hi Konrad.
>
> On Fri, May 01, 2020 at 10:48:21PM +0200, Konrad Dybcio wrote:
> > I am aware of the fact that this is probably not the correct
> > naming of this panel, yet I am unable to retrieve any additional
> > information about it, as it is used in a smartphone to which no
> > schematics are released.
> >
> > The driver has been generated with the help of
> > linux-mdss-dsi-panel-driver-generator [1] and works perfectly
> > on a Asus Zenfone 2 Laser Z00T smartphone, including brighness
> > control and switching on/off.
> >
> > [1] 
> > https://github.com/msm8916-mainline/linux-mdss-dsi-panel-driver-generator
>
> Panle driver looks good.
> Will take a closer look tomorrow.
>
> Any chance you can work on the TODO in the driver so we can have that
> resolved before we apply it?
>
> Also for a v2 it would be perfect if you could work on top of
> drm-misc-next.
> There is at least one small fix needed to build that I spotted.
>
> But wait until I get back on the driver patch before submitting a v2.
>
> Sam
>
> >
> > Konrad Dybcio (2):
> >   drivers: drm: panel: Add TM5P5 NT35596 panel driver
> >   dt-bindings: display: Document TM5P5 NT35596 panel compatible
> >
> >  .../bindings/display/panel/tm5p5,nt35596.txt  |   7 +
> >  drivers/gpu/drm/panel/Kconfig |   9 +
> >  drivers/gpu/drm/panel/Makefile|   1 +
> >  drivers/gpu/drm/panel/panel-tm5p5-nt35596.c   | 366 ++
> >  4 files changed, 383 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/display/panel/tm5p5,nt35596.txt
> >  create mode 100644 drivers/gpu/drm/panel/panel-tm5p5-nt35596.c
> >
> > --
> > 2.26.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH] drm/nouveau/dispnv04: Remove dead code

[Souptick Joarder]

On Fri, May 1, 2020 at 2:21 AM Ilia Mirkin  wrote:
>
> Interesting. I do remember seeing some snow on NV5's overlay at high
> resolutions. Wonder if it was because of this missing code...

What was the problem ? Does enabling this dead code will fix the problem ?

>
> On Thu, Apr 30, 2020 at 4:19 PM Souptick Joarder  wrote:
> >
> > These are dead code since 3.10. If there is no plan to use
> > it further, these can be removed forever.
> >
> > Signed-off-by: Souptick Joarder 
> > ---
> >  drivers/gpu/drm/nouveau/dispnv04/crtc.c | 28 
> >  1 file changed, 28 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c 
> > b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> > index 1f08de4..ad0ef7d 100644
> > --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> > +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> > @@ -269,31 +269,11 @@ static void nv_crtc_calc_state_ext(struct drm_crtc 
> > *crtc, struct drm_display_mod
> > horizStart = horizTotal - 5;
> > horizEnd = horizTotal - 2;
> > horizBlankEnd = horizTotal + 4;
> > -#if 0
> > -   if (dev->overlayAdaptor && drm->client.device.info.family 
> > >= NV_DEVICE_INFO_V0_CELSIUS)
> > -   /* This reportedly works around some video overlay 
> > bandwidth problems */
> > -   horizTotal += 2;
> > -#endif
> > }
> >
> > if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> > vertTotal |= 1;
> >
> > -#if 0
> > -   ErrorF("horizDisplay: 0x%X \n", horizDisplay);
> > -   ErrorF("horizStart: 0x%X \n", horizStart);
> > -   ErrorF("horizEnd: 0x%X \n", horizEnd);
> > -   ErrorF("horizTotal: 0x%X \n", horizTotal);
> > -   ErrorF("horizBlankStart: 0x%X \n", horizBlankStart);
> > -   ErrorF("horizBlankEnd: 0x%X \n", horizBlankEnd);
> > -   ErrorF("vertDisplay: 0x%X \n", vertDisplay);
> > -   ErrorF("vertStart: 0x%X \n", vertStart);
> > -   ErrorF("vertEnd: 0x%X \n", vertEnd);
> > -   ErrorF("vertTotal: 0x%X \n", vertTotal);
> > -   ErrorF("vertBlankStart: 0x%X \n", vertBlankStart);
> > -   ErrorF("vertBlankEnd: 0x%X \n", vertBlankEnd);
> > -#endif
> > -
> > /*
> > * compute correct Hsync & Vsync polarity
> > */
> > @@ -492,14 +472,6 @@ static void nv_crtc_calc_state_ext(struct drm_crtc 
> > *crtc, struct drm_display_mod
> > /* Except for rare conditions I2C is enabled on the primary crtc */
> > if (nv_crtc->index == 0)
> > regp->crtc_eng_ctrl |= NV_CRTC_FSEL_I2C;
> > -#if 0
> > -   /* Set overlay to desired crtc. */
> > -   if (dev->overlayAdaptor) {
> > -   NVPortPrivPtr pPriv = GET_OVERLAY_PRIVATE(dev);
> > -   if (pPriv->overlayCRTC == nv_crtc->index)
> > -   regp->crtc_eng_ctrl |= NV_CRTC_FSEL_OVERLAY;
> > -   }
> > -#endif
> >
> > /* ADDRESS_SPACE_PNVM is the same as setting HCUR_ASI */
> > regp->cursor_cfg = NV_PCRTC_CURSOR_CONFIG_CUR_LINES_64 |
> > --
> > 1.9.1
> >
> > ___
> > Nouveau mailing list
> > nouv...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH hmm v2 5/5] mm/hmm: remove the customizable pfn format from hmm_range_fault

[Jason Gunthorpe]

From: Jason Gunthorpe 

Presumably the intent here was that hmm_range_fault() could put the data
into some HW specific format and thus avoid some work. However, nothing
actually does that, and it isn't clear how anything actually could do that
as hmm_range_fault() provides CPU addresses which must be DMA mapped.

Perhaps there is some special HW that does not need DMA mapping, but we
don't have any examples of this, and the theoretical performance win of
avoiding an extra scan over the pfns array doesn't seem worth the
complexity. Plus pfns needs to be scanned anyhow to sort out any
DEVICE_PRIVATE pages.

This version replaces the uint64_t with an usigned long containing a pfn
and fixed flags. On input flags is filled with the HMM_PFN_REQ_* values,
on successful output it is filled with HMM_PFN_* values, describing the
state of the pages.

amdgpu is simple to convert, it doesn't use snapshot and doesn't use
per-page flags.

nouveau uses only 16 hmm_pte entries at most (ie fits in a few cache
lines), and it sweeps over its pfns array a couple of times anyhow. It
also has a nasty call chain before it reaches the dma map and hardware
suggesting performance isn't important:

   nouveau_svm_fault():
 args.i.m.method = NVIF_VMM_V0_PFNMAP
 nouveau_range_fault()
  nvif_object_ioctl()
   client->driver->ioctl()
  struct nvif_driver nvif_driver_nvkm:
.ioctl = nvkm_client_ioctl
   nvkm_ioctl()
nvkm_ioctl_path()
  nvkm_ioctl_v0[type].func(..)
  nvkm_ioctl_mthd()
   nvkm_object_mthd()
  struct nvkm_object_func nvkm_uvmm:
.mthd = nvkm_uvmm_mthd
   nvkm_uvmm_mthd()
nvkm_uvmm_mthd_pfnmap()
 nvkm_vmm_pfn_map()
  nvkm_vmm_ptes_get_map()
   func == gp100_vmm_pgt_pfn
struct nvkm_vmm_desc_func gp100_vmm_desc_spt:
  .pfn = gp100_vmm_pgt_pfn
 nvkm_vmm_iter()
  REF_PTES == func == gp100_vmm_pgt_pfn()
dma_map_page()

Acked-by: Felix Kuehling 
Tested-by: Ralph Campbell 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Christoph Hellwig 
---
 Documentation/vm/hmm.rst|  26 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |  35 ++
 drivers/gpu/drm/nouveau/nouveau_dmem.c  |  27 +---
 drivers/gpu/drm/nouveau/nouveau_dmem.h  |   3 +-
 drivers/gpu/drm/nouveau/nouveau_svm.c   |  87 -
 include/linux/hmm.h |  99 ++-
 mm/hmm.c| 160 +++-
 7 files changed, 192 insertions(+), 245 deletions(-)

diff --git a/Documentation/vm/hmm.rst b/Documentation/vm/hmm.rst
index 9924f2caa0184c..c9f2329113a47f 100644
--- a/Documentation/vm/hmm.rst
+++ b/Documentation/vm/hmm.rst
@@ -185,9 +185,6 @@ The usage pattern is::
   range.start = ...;
   range.end = ...;
   range.pfns = ...;
-  range.flags = ...;
-  range.values = ...;
-  range.pfn_shift = ...;
 
   if (!mmget_not_zero(interval_sub->notifier.mm))
   return -EFAULT;
@@ -229,15 +226,10 @@ The hmm_range struct has 2 fields, default_flags and 
pfn_flags_mask, that specif
 fault or snapshot policy for the whole range instead of having to set them
 for each entry in the pfns array.
 
-For instance, if the device flags for range.flags are::
+For instance if the device driver wants pages for a range with at least read
+permission, it sets::
 
-range.flags[HMM_PFN_VALID] = (1 << 63);
-range.flags[HMM_PFN_WRITE] = (1 << 62);
-
-and the device driver wants pages for a range with at least read permission,
-it sets::
-
-range->default_flags = (1 << 63);
+range->default_flags = HMM_PFN_REQ_FAULT;
 range->pfn_flags_mask = 0;
 
 and calls hmm_range_fault() as described above. This will fill fault all pages
@@ -246,18 +238,18 @@ in the range with at least read permission.
 Now let's say the driver wants to do the same except for one page in the range 
for
 which it wants to have write permission. Now driver set::
 
-range->default_flags = (1 << 63);
-range->pfn_flags_mask = (1 << 62);
-range->pfns[index_of_write] = (1 << 62);
+range->default_flags = HMM_PFN_REQ_FAULT;
+range->pfn_flags_mask = HMM_PFN_REQ_WRITE;
+range->pfns[index_of_write] = HMM_PFN_REQ_WRITE;
 
 With this, HMM will fault in all pages with at least read (i.e., valid) and 
for the
 address == range->start + (index_of_write << PAGE_SHIFT) it will fault with
 write permission i.e., if the CPU pte does not have write permission set then 
HMM
 will call handle_mm_fault().
 
-Note that HMM will populate the pfns array with write permission for any page
-that is mapped with CPU write permission no matter what values are set
-in default_flags or pfn_flags_mask.
+After hmm_range_fault completes the flag bits are set to the current 

[PATCH] video/fbdev/matroxfb: Remove dead code

[Souptick Joarder]

These are dead code since 3.15. If there is no plan to use it further
it can be removed forever.

Signed-off-by: Souptick Joarder 
---
 drivers/video/fbdev/matrox/matroxfb_DAC1064.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/drivers/video/fbdev/matrox/matroxfb_DAC1064.c 
b/drivers/video/fbdev/matrox/matroxfb_DAC1064.c
index 765e805..9c2a2c0 100644
--- a/drivers/video/fbdev/matrox/matroxfb_DAC1064.c
+++ b/drivers/video/fbdev/matrox/matroxfb_DAC1064.c
@@ -603,9 +603,6 @@ static void MGA1064_ramdac_init(struct matrox_fb_info 
*minfo)
 /* BIOS environ */
 static int x7AF4 = 0x10;   /* flags, maybe 0x10 = SDRAM, 0x00 = SGRAM??? */
/* G100 wants 0x10, G200 SGRAM does not care... 
*/
-#if 0
-static int def50 = 0;  /* reg50, & 0x0F, & 0x3000 (only 0x, 0x1000, 0x2000 
(0x3000 disallowed and treated as 0) */
-#endif
 
 static void MGAG100_progPixClock(const struct matrox_fb_info *minfo, int flags,
 int m, int n, int p)
@@ -843,9 +840,6 @@ static int MGAG100_preinit(struct matrox_fb_info *minfo)
struct matrox_hw_state *hw = >hw;
 
 u_int32_t reg50;
-#if 0
-   u_int32_t q;
-#endif
 
DBG(__func__)
 
@@ -927,11 +921,6 @@ static int MGAG100_preinit(struct matrox_fb_info *minfo)
mga_writeb(minfo->video.vbase, 0x, 0xAA);
mga_writeb(minfo->video.vbase, 0x0800, 0x55);
mga_writeb(minfo->video.vbase, 0x4000, 0x55);
-#if 0
-   if (mga_readb(minfo->video.vbase, 0x) != 0xAA) {
-   hw->MXoptionReg &= ~0x1000;
-   }
-#endif
hw->MXoptionReg |= 0x00078020;
} else if (minfo->devflags.accelerator == FB_ACCEL_MATROX_MGAG200) {
pci_read_config_dword(minfo->pcidev, PCI_OPTION2_REG, );
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/amdgpu: Avoid integer overflow in amdgpu_device_suspend_display_audio

[Nathan Chancellor]

When building with Clang:

drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4160:53: warning: overflow in
expression; result is -294967296 with type 'long' [-Winteger-overflow]
expires = ktime_get_mono_fast_ns() + NSEC_PER_SEC * 4L;
  ^
1 warning generated.

Multiplication happens first due to order of operations and both
NSEC_PER_SEC and 4 are long literals so the expression overflows. To
avoid this, make 4 an unsigned long long literal, which matches the
type of expires (u64).

Fixes: 3f12acc8d6d4 ("drm/amdgpu: put the audio codec into suspend state before 
gpu reset V3")
Link: https://github.com/ClangBuiltLinux/linux/issues/1017
Signed-off-by: Nathan Chancellor 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 6f93af972b0a..caa38e7d502e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4157,7 +4157,7 @@ static int amdgpu_device_suspend_display_audio(struct 
amdgpu_device *adev)
 * the audio controller default autosuspend delay setting.
 * 4S used here is guaranteed to cover that.
 */
-   expires = ktime_get_mono_fast_ns() + NSEC_PER_SEC * 4L;
+   expires = ktime_get_mono_fast_ns() + NSEC_PER_SEC * 4ULL;
 
while (!pm_runtime_status_suspended(&(p->dev))) {
if (!pm_runtime_suspend(&(p->dev)))

base-commit: fb9d670f57e3f6478602328bbbf71138be06ca4f
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 6/7] drm/mediatek: mtk_dsi: Use the drm_panel_bridge API

[Enric Balletbo i Serra]

Replace the manual panel handling code by a drm_panel_bridge. This
simplifies the driver and allows all components in the display pipeline
to be treated as bridges, paving the way to generic connector handling.

Signed-off-by: Enric Balletbo i Serra 
Reviewed-by: Laurent Pinchart 
Acked-by: Sam Ravnborg 
Reviewed-by: Chun-Kuang Hu 
---

Changes in v4: None
Changes in v3:
- Use next_bridge field to store the panel bridge. (Laurent Pinchart)
- Add the bridge.type field. (Laurent Pinchart)
- This patch requires https://lkml.org/lkml/2020/4/16/2080 to work
  properly.

Changes in v2:
- Do not set connector_type for panel here. (Sam Ravnborg)

 drivers/gpu/drm/mediatek/mtk_dsi.c | 173 +++--
 1 file changed, 14 insertions(+), 159 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index e02d16a086ac..4f3bd095c1ee 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -182,8 +182,6 @@ struct mtk_dsi {
struct mipi_dsi_host host;
struct drm_encoder encoder;
struct drm_bridge bridge;
-   struct drm_connector conn;
-   struct drm_panel *panel;
struct drm_bridge *next_bridge;
struct phy *phy;
 
@@ -212,11 +210,6 @@ static inline struct mtk_dsi *bridge_to_dsi(struct 
drm_bridge *b)
return container_of(b, struct mtk_dsi, bridge);
 }
 
-static inline struct mtk_dsi *connector_to_dsi(struct drm_connector *c)
-{
-   return container_of(c, struct mtk_dsi, conn);
-}
-
 static inline struct mtk_dsi *host_to_dsi(struct mipi_dsi_host *h)
 {
return container_of(h, struct mtk_dsi, host);
@@ -682,16 +675,7 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
mtk_dsi_lane0_ulp_mode_leave(dsi);
mtk_dsi_clk_hs_mode(dsi, 0);
 
-   if (dsi->panel) {
-   if (drm_panel_prepare(dsi->panel)) {
-   DRM_ERROR("failed to prepare the panel\n");
-   goto err_disable_digital_clk;
-   }
-   }
-
return 0;
-err_disable_digital_clk:
-   clk_disable_unprepare(dsi->digital_clk);
 err_disable_engine_clk:
clk_disable_unprepare(dsi->engine_clk);
 err_phy_power_off:
@@ -718,15 +702,7 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
 */
mtk_dsi_stop(dsi);
 
-   if (!mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500)) {
-   if (dsi->panel) {
-   if (drm_panel_unprepare(dsi->panel)) {
-   DRM_ERROR("failed to unprepare the panel\n");
-   return;
-   }
-   }
-   }
-
+   mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500);
mtk_dsi_reset_engine(dsi);
mtk_dsi_lane0_ulp_mode_enter(dsi);
mtk_dsi_clk_ulp_mode_enter(dsi);
@@ -757,19 +733,7 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
 
mtk_dsi_start(dsi);
 
-   if (dsi->panel) {
-   if (drm_panel_enable(dsi->panel)) {
-   DRM_ERROR("failed to enable the panel\n");
-   goto err_dsi_power_off;
-   }
-   }
-
dsi->enabled = true;
-
-   return;
-err_dsi_power_off:
-   mtk_dsi_stop(dsi);
-   mtk_dsi_poweroff(dsi);
 }
 
 static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
@@ -777,34 +741,19 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
if (!dsi->enabled)
return;
 
-   if (dsi->panel) {
-   if (drm_panel_disable(dsi->panel)) {
-   DRM_ERROR("failed to disable the panel\n");
-   return;
-   }
-   }
-
mtk_dsi_poweroff(dsi);
 
dsi->enabled = false;
 }
 
-static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi 
*dsi);
-static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
-
 static int mtk_dsi_bridge_attach(struct drm_bridge *bridge,
 enum drm_bridge_attach_flags flags)
 {
struct mtk_dsi *dsi = bridge_to_dsi(bridge);
 
-   return mtk_dsi_create_conn_enc(bridge->dev, dsi);
-}
-
-static void mtk_dsi_bridge_detach(struct drm_bridge *bridge)
-{
-   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
-
-   mtk_dsi_destroy_conn_enc(dsi);
+   /* Attach the panel or bridge to the dsi bridge */
+   return drm_bridge_attach(bridge->encoder, dsi->next_bridge,
+>bridge, flags);
 }
 
 static void mtk_dsi_bridge_mode_set(struct drm_bridge *bridge,
@@ -830,101 +779,13 @@ static void mtk_dsi_bridge_enable(struct drm_bridge 
*bridge)
mtk_output_dsi_enable(dsi);
 }
 
-static int mtk_dsi_connector_get_modes(struct drm_connector *connector)
-{
-   struct mtk_dsi *dsi = connector_to_dsi(connector);
-
-   return drm_panel_get_modes(dsi->panel, connector);
-}
-
 static const struct drm_bridge_funcs mtk_dsi_bridge_funcs = {

Re: [PATCH 11/14] docs: move other kAPI documents to core-api

[Mike Rapoport]

Hello Mauro,

On Fri, May 01, 2020 at 05:37:55PM +0200, Mauro Carvalho Chehab wrote:
> There are a number of random documents that seem to be
> describing some aspects of the core-api. Move them to such
> directory, adding them at the core-api/index.rst file.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  Documentation/admin-guide/sysctl/vm.rst | 2 +-
>  Documentation/core-api/index.rst| 6 ++
>  Documentation/{mailbox.txt => core-api/mailbox.rst} | 0
>  Documentation/{nommu-mmap.txt => core-api/nommu-mmap.rst}   | 0

The nommu-mmap mostly provides description of user visible behaviuour. I
think it's bettter to have it in admin-guide/mm/.

>  .../{this_cpu_ops.txt => core-api/this_cpu_ops.rst} | 0
>  .../unaligned-memory-access.rst}| 0
>  Documentation/gpu/drm-mm.rst| 2 +-
>  arch/Kconfig| 2 +-
>  init/Kconfig| 2 +-
>  mm/Kconfig  | 2 +-
>  mm/nommu.c  | 2 +-
>  11 files changed, 12 insertions(+), 6 deletions(-)
>  rename Documentation/{mailbox.txt => core-api/mailbox.rst} (100%)
>  rename Documentation/{nommu-mmap.txt => core-api/nommu-mmap.rst} (100%)
>  rename Documentation/{this_cpu_ops.txt => core-api/this_cpu_ops.rst} (100%)
>  rename Documentation/{unaligned-memory-access.txt => 
> core-api/unaligned-memory-access.rst} (100%)
> 
> diff --git a/Documentation/admin-guide/sysctl/vm.rst 
> b/Documentation/admin-guide/sysctl/vm.rst
> index 0329a4d3fa9e..0bf2f2a84a9f 100644
> --- a/Documentation/admin-guide/sysctl/vm.rst
> +++ b/Documentation/admin-guide/sysctl/vm.rst
> @@ -583,7 +583,7 @@ trimming of allocations is initiated.
>  
>  The default value is 1.
>  
> -See Documentation/nommu-mmap.txt for more information.
> +See Documentation/core-api/nommu-mmap.rst for more information.
>  
>  
>  numa_zonelist_order
> diff --git a/Documentation/core-api/index.rst 
> b/Documentation/core-api/index.rst
> index eeac63ba17c3..fe03a639a91a 100644
> --- a/Documentation/core-api/index.rst
> +++ b/Documentation/core-api/index.rst
> @@ -38,10 +38,14 @@ Library functionality that is used throughout the kernel.
> circular-buffers
> rbtree
> generic-radix-tree
> +   mailbox
> packing
> +   rbtree
> +   this_cpu_ops
> timekeeping
> errseq
>  
> +
>  Concurrency primitives
>  ==
>  
> @@ -82,11 +86,13 @@ more memory-management documentation in :doc:`/vm/index`.
> :maxdepth: 1
>  
> memory-allocation
> +   unaligned-memory-access
> dma-api
> dma-api-howto
> dma-attributes
> dma-isa-lpc
> bus-virt-phys-mapping
> +   nommu-mmap
> mm-api
> genalloc
> pin_user_pages
> diff --git a/Documentation/mailbox.txt b/Documentation/core-api/mailbox.rst
> similarity index 100%
> rename from Documentation/mailbox.txt
> rename to Documentation/core-api/mailbox.rst
> diff --git a/Documentation/nommu-mmap.txt 
> b/Documentation/core-api/nommu-mmap.rst
> similarity index 100%
> rename from Documentation/nommu-mmap.txt
> rename to Documentation/core-api/nommu-mmap.rst
> diff --git a/Documentation/this_cpu_ops.txt 
> b/Documentation/core-api/this_cpu_ops.rst
> similarity index 100%
> rename from Documentation/this_cpu_ops.txt
> rename to Documentation/core-api/this_cpu_ops.rst
> diff --git a/Documentation/unaligned-memory-access.txt 
> b/Documentation/core-api/unaligned-memory-access.rst
> similarity index 100%
> rename from Documentation/unaligned-memory-access.txt
> rename to Documentation/core-api/unaligned-memory-access.rst
> diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
> index 1839762044be..e0bbcbb6f512 100644
> --- a/Documentation/gpu/drm-mm.rst
> +++ b/Documentation/gpu/drm-mm.rst
> @@ -314,7 +314,7 @@ To use drm_gem_cma_get_unmapped_area(), drivers must fill 
> the struct
>  a pointer on drm_gem_cma_get_unmapped_area().
>  
>  More detailed information about get_unmapped_area can be found in
> -Documentation/nommu-mmap.txt
> +Documentation/core-api/nommu-mmap.rst
>  
>  Memory Coherency
>  
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 786a85d4ad40..b0b4046c9d13 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -147,7 +147,7 @@ config HAVE_EFFICIENT_UNALIGNED_ACCESS
> problems with received packets if doing so would not help
> much.
>  
> -   See Documentation/unaligned-memory-access.txt for more
> +   See Documentation/core-api/unaligned-memory-access.rst for more
> information on the topic of unaligned memory accesses.
>  
>  config ARCH_USE_BUILTIN_BSWAP
> diff --git a/init/Kconfig b/init/Kconfig
> index 492bb7000aa4..61ccfd9243e3 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1950,7 +1950,7 @@ config MMAP_ALLOW_UNINITIALIZED
> 

[PATCH hmm v2 1/5] mm/hmm: make CONFIG_DEVICE_PRIVATE into a select

[Jason Gunthorpe]

From: Jason Gunthorpe 

There is no reason for a user to select this or not directly - it should
be selected by drivers that are going to use the feature, similar to how
CONFIG_HMM_MIRROR works.

Currently all drivers provide a feature kconfig that will disable use of
DEVICE_PRIVATE in that driver, allowing users to avoid enabling this if
they don't want the overhead.

Acked-by: Felix Kuehling 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Jason Gunthorpe 
---
 arch/powerpc/Kconfig| 2 +-
 drivers/gpu/drm/nouveau/Kconfig | 2 +-
 mm/Kconfig  | 7 +--
 3 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 924c541a926008..8de52aefdc74cc 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -455,7 +455,7 @@ config PPC_TRANSACTIONAL_MEM
 config PPC_UV
bool "Ultravisor support"
depends on KVM_BOOK3S_HV_POSSIBLE
-   depends on DEVICE_PRIVATE
+   select DEVICE_PRIVATE
default n
help
  This option paravirtualizes the kernel to run in POWER platforms that
diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig
index d6e4ae1ef7053a..af5793f3e7c2cf 100644
--- a/drivers/gpu/drm/nouveau/Kconfig
+++ b/drivers/gpu/drm/nouveau/Kconfig
@@ -86,10 +86,10 @@ config DRM_NOUVEAU_BACKLIGHT
 
 config DRM_NOUVEAU_SVM
bool "(EXPERIMENTAL) Enable SVM (Shared Virtual Memory) support"
-   depends on DEVICE_PRIVATE
depends on DRM_NOUVEAU
depends on MMU
depends on STAGING
+   select DEVICE_PRIVATE
select HMM_MIRROR
select MMU_NOTIFIER
default n
diff --git a/mm/Kconfig b/mm/Kconfig
index c1acc34c1c358c..7ca36bf5f5058e 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -805,15 +805,10 @@ config HMM_MIRROR
depends on MMU
 
 config DEVICE_PRIVATE
-   bool "Unaddressable device memory (GPU memory, ...)"
+   bool
depends on ZONE_DEVICE
select DEV_PAGEMAP_OPS
 
-   help
- Allows creation of struct pages to represent unaddressable device
- memory; i.e., memory that is only accessible from the device (or
- group of devices). You likely also want to select HMM_MIRROR.
-
 config FRAME_VECTOR
bool
 
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH hmm v2 4/5] mm/hmm: remove HMM_PFN_SPECIAL

[Jason Gunthorpe]

From: Jason Gunthorpe 

This is just an alias for HMM_PFN_ERROR, nothing cares that the error was
because of a special page vs any other error case.

Acked-by: Felix Kuehling 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Jason Gunthorpe 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 1 -
 drivers/gpu/drm/nouveau/nouveau_svm.c   | 1 -
 include/linux/hmm.h | 8 
 mm/hmm.c| 2 +-
 4 files changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 41ae7f96f48194..76b4a4fa39ed04 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -775,7 +775,6 @@ static const uint64_t hmm_range_flags[HMM_PFN_FLAG_MAX] = {
 static const uint64_t hmm_range_values[HMM_PFN_VALUE_MAX] = {
0xfffeUL, /* HMM_PFN_ERROR */
0, /* HMM_PFN_NONE */
-   0xfffcUL /* HMM_PFN_SPECIAL */
 };
 
 /**
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c 
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index c68e9317cf0740..cf0d9bd61bebf9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_svm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_svm.c
@@ -379,7 +379,6 @@ static const u64
 nouveau_svm_pfn_values[HMM_PFN_VALUE_MAX] = {
[HMM_PFN_ERROR  ] = ~NVIF_VMM_PFNMAP_V0_V,
[HMM_PFN_NONE   ] =  NVIF_VMM_PFNMAP_V0_NONE,
-   [HMM_PFN_SPECIAL] = ~NVIF_VMM_PFNMAP_V0_V,
 };
 
 /* Issue fault replay for GPU to retry accesses that faulted previously. */
diff --git a/include/linux/hmm.h b/include/linux/hmm.h
index 0df27dd03d53d7..81c302c884c0e3 100644
--- a/include/linux/hmm.h
+++ b/include/linux/hmm.h
@@ -44,10 +44,6 @@ enum hmm_pfn_flag_e {
  * Flags:
  * HMM_PFN_ERROR: corresponding CPU page table entry points to poisoned memory
  * HMM_PFN_NONE: corresponding CPU page table entry is pte_none()
- * HMM_PFN_SPECIAL: corresponding CPU page table entry is special; i.e., the
- *  result of vmf_insert_pfn() or vm_insert_page(). Therefore, it should 
not
- *  be mirrored by a device, because the entry will never have 
HMM_PFN_VALID
- *  set and the pfn value is undefined.
  *
  * Driver provides values for none entry, error entry, and special entry.
  * Driver can alias (i.e., use same value) error and special, but
@@ -56,12 +52,10 @@ enum hmm_pfn_flag_e {
  * HMM pfn value returned by hmm_vma_get_pfns() or hmm_vma_fault() will be:
  * hmm_range.values[HMM_PFN_ERROR] if CPU page table entry is poisonous,
  * hmm_range.values[HMM_PFN_NONE] if there is no CPU page table entry,
- * hmm_range.values[HMM_PFN_SPECIAL] if CPU page table entry is a special one
  */
 enum hmm_pfn_value_e {
HMM_PFN_ERROR,
HMM_PFN_NONE,
-   HMM_PFN_SPECIAL,
HMM_PFN_VALUE_MAX
 };
 
@@ -110,8 +104,6 @@ static inline struct page *hmm_device_entry_to_page(const 
struct hmm_range *rang
return NULL;
if (entry == range->values[HMM_PFN_ERROR])
return NULL;
-   if (entry == range->values[HMM_PFN_SPECIAL])
-   return NULL;
if (!(entry & range->flags[HMM_PFN_VALID]))
return NULL;
return pfn_to_page(entry >> range->pfn_shift);
diff --git a/mm/hmm.c b/mm/hmm.c
index f06bcac948a79b..2e975eedb14f89 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -301,7 +301,7 @@ static int hmm_vma_handle_pte(struct mm_walk *walk, 
unsigned long addr,
pte_unmap(ptep);
return -EFAULT;
}
-   *pfn = range->values[HMM_PFN_SPECIAL];
+   *pfn = range->values[HMM_PFN_ERROR];
return 0;
}
 
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH v6 2/3] drm: bridge: Add support for Cadence MHDP DPI/DP bridge

[Yuti Suresh Amonkar]

Hi Laurent, 

Thank you so much for reviewing the patch and providing valuable comments. 
Apologies for the delayed response. We are working on your review comments and 
will send the next version of the driver for review soon. Please see the 
responses to comments inline below.

Thanks & Regards,
Yuti Amonkar

> -Original Message-
> From: Laurent Pinchart 
> Sent: Thursday, March 12, 2020 3:51
> To: Yuti Suresh Amonkar 
> Cc: linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org;
> devicet...@vger.kernel.org; robh...@kernel.org; max...@cerno.tech;
> airl...@linux.ie; dan...@ffwll.ch; mark.rutl...@arm.com;
> a.ha...@samsung.com; narmstr...@baylibre.com; jo...@kwiboo.se;
> jernej.skra...@siol.net; prane...@ti.com; jsa...@ti.com;
> tomi.valkei...@ti.com; Milind Parab ; Swapnil
> Kashinath Jakhade 
> Subject: Re: [PATCH v6 2/3] drm: bridge: Add support for Cadence MHDP
> DPI/DP bridge
> 
> EXTERNAL MAIL
> 
> 
> Hi Yuti,
> 
> Thank you for the patch.
> 
> On Wed, Feb 26, 2020 at 11:22:58AM +0100, Yuti Amonkar wrote:
> > This patch adds new DRM driver for Cadence MHDP DPTX IP used on J721e
> SoC.
> 
> s/DRM driver/DRM bridge driver.
> 
> > MHDP DPTX IP is the component that complies with VESA DisplayPort (DP)
> and
> > embedded Display Port (eDP) standards. It integrates uCPU running the
> > embedded Firmware(FW) interfaced over APB interface.
> > Basically, it takes a DPI stream as input and output it encoded in DP
> 
> s/output/outputs/
> 
> > format. Currently, it supports only SST mode.
> >
> > Signed-off-by: Yuti Amonkar 
> > Signed-off-by: Jyri Sarha 
> > Signed-off-by: Quentin Schulz 
> > Signed-off-by: Swapnil Jakhade 
> > Signed-off-by: Tomi Valkeinen 
> > ---
> >  drivers/gpu/drm/bridge/Kconfig  |   11 +
> >  drivers/gpu/drm/bridge/Makefile |2 +
> >  drivers/gpu/drm/bridge/cdns-mhdp-core.c | 2196
> +++
> >  drivers/gpu/drm/bridge/cdns-mhdp-core.h |  380 
> >  4 files changed, 2589 insertions(+)
> >  create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp-core.c
> >  create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp-core.h
> >
> > diff --git a/drivers/gpu/drm/bridge/Kconfig
> b/drivers/gpu/drm/bridge/Kconfig
> > index 20a439199cb8..3bfabb76f2bb 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -27,6 +27,17 @@ config DRM_CDNS_DSI
> >   Support Cadence DPI to DSI bridge. This is an internal
> >   bridge and is meant to be directly embedded in a SoC.
> >
> > +config DRM_CDNS_MHDP
> > +   tristate "Cadence DPI/DP bridge"
> > +   select DRM_KMS_HELPER
> > +   select DRM_PANEL_BRIDGE
> > +   depends on OF
> > +   help
> > + Support Cadence DPI to DP bridge. This is an internal
> > + bridge and is meant to be directly embedded in a SoC.
> > + It takes a DPI stream as input and output it encoded
> 
> s/output/outputs/
> 
> > + in DP format.
> > +
> >  config DRM_DUMB_VGA_DAC
> > tristate "Dumb VGA DAC Bridge support"
> > depends on OF
> > diff --git a/drivers/gpu/drm/bridge/Makefile
> b/drivers/gpu/drm/bridge/Makefile
> > index b0d5c3af0b5a..2e2c5be7c714 100644
> > --- a/drivers/gpu/drm/bridge/Makefile
> > +++ b/drivers/gpu/drm/bridge/Makefile
> > @@ -16,6 +16,8 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358768) +=
> tc358768.o
> >  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_CDNS_MHDP) += cdns-mhdp.o
> 
> Should this be kept alphabetically sorted ?
> 
> > +cdns-mhdp-objs := cdns-mhdp-core.o
> >
> >  obj-y += analogix/
> >  obj-y += synopsys/
> > diff --git a/drivers/gpu/drm/bridge/cdns-mhdp-core.c
> b/drivers/gpu/drm/bridge/cdns-mhdp-core.c
> > new file mode 100644
> > index ..cc642893baa8
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/cdns-mhdp-core.c
> > @@ -0,0 +1,2196 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Cadence MHDP DP bridge driver.
> > + *
> > + * Copyright: 2019 Cadence Design Systems, Inc.
> > + *
> > + * Author: Quentin Schulz 
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> 
> I think of_irq.h isn't needed.
> 
> > +#include 
> > +#include 
> > +#include 
> 
> phy comes before platform.
> 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +
> > +#include "cdns-mhdp-core.h"
> > +
> > +static const struct of_device_id mhdp_ids[] = {
> > +   { .compatible = "cdns,mhdp8546", },
> > +   { /* sentinel */ }
> > +};
> > +MODULE_DEVICE_TABLE(of, mhdp_ids);
> 
> Small detail, this is usually put at at or towards the end of the file.
> 
> > +
> > +static inline u32 get_unaligned_be24(const void *p)
> > +{
> > +   const u8 *_p = p;
> > +
> > +   return _p[0] << 16 | _p[1] << 8 | _p[2];

[PATCH v4 4/7] drm/mediatek: mtk_dsi: Convert to bridge driver

[Enric Balletbo i Serra]

Convert mtk_dsi to a bridge driver with built-in encoder support for
compatibility with existing component drivers.

Signed-off-by: Enric Balletbo i Serra 
Acked-by: Sam Ravnborg 
---

Changes in v4:
- Remove double call to drm_encoder_init(). (Chun-Kuang Hu)
- Cleanup the encoder in mtk_dsi_unbind(). (Chun-Kuang Hu)

Changes in v3:
- Add the bridge.type. (Laurent Pinchart)

Changes in v2: None

 drivers/gpu/drm/mediatek/mtk_dsi.c | 108 +++--
 1 file changed, 70 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 37b8d7ffd835..38cbdcb15fff 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -180,6 +180,7 @@ struct mtk_dsi {
struct device *dev;
struct mipi_dsi_host host;
struct drm_encoder encoder;
+   struct drm_bridge bridge;
struct drm_connector conn;
struct drm_panel *panel;
struct drm_bridge *next_bridge;
@@ -205,9 +206,9 @@ struct mtk_dsi {
const struct mtk_dsi_driver_data *driver_data;
 };
 
-static inline struct mtk_dsi *encoder_to_dsi(struct drm_encoder *e)
+static inline struct mtk_dsi *bridge_to_dsi(struct drm_bridge *b)
 {
-   return container_of(e, struct mtk_dsi, encoder);
+   return container_of(b, struct mtk_dsi, bridge);
 }
 
 static inline struct mtk_dsi *connector_to_dsi(struct drm_connector *c)
@@ -796,32 +797,43 @@ static const struct drm_encoder_funcs 
mtk_dsi_encoder_funcs = {
.destroy = mtk_dsi_encoder_destroy,
 };
 
-static bool mtk_dsi_encoder_mode_fixup(struct drm_encoder *encoder,
-  const struct drm_display_mode *mode,
-  struct drm_display_mode *adjusted_mode)
+static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi 
*dsi);
+static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
+
+static int mtk_dsi_bridge_attach(struct drm_bridge *bridge,
+enum drm_bridge_attach_flags flags)
 {
-   return true;
+   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
+
+   return mtk_dsi_create_conn_enc(bridge->dev, dsi);
+}
+
+static void mtk_dsi_bridge_detach(struct drm_bridge *bridge)
+{
+   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
+
+   mtk_dsi_destroy_conn_enc(dsi);
 }
 
-static void mtk_dsi_encoder_mode_set(struct drm_encoder *encoder,
-struct drm_display_mode *mode,
-struct drm_display_mode *adjusted)
+static void mtk_dsi_bridge_mode_set(struct drm_bridge *bridge,
+   const struct drm_display_mode *mode,
+   const struct drm_display_mode *adjusted)
 {
-   struct mtk_dsi *dsi = encoder_to_dsi(encoder);
+   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
 
drm_display_mode_to_videomode(adjusted, >vm);
 }
 
-static void mtk_dsi_encoder_disable(struct drm_encoder *encoder)
+static void mtk_dsi_bridge_disable(struct drm_bridge *bridge)
 {
-   struct mtk_dsi *dsi = encoder_to_dsi(encoder);
+   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
 
mtk_output_dsi_disable(dsi);
 }
 
-static void mtk_dsi_encoder_enable(struct drm_encoder *encoder)
+static void mtk_dsi_bridge_enable(struct drm_bridge *bridge)
 {
-   struct mtk_dsi *dsi = encoder_to_dsi(encoder);
+   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
 
mtk_output_dsi_enable(dsi);
 }
@@ -833,11 +845,12 @@ static int mtk_dsi_connector_get_modes(struct 
drm_connector *connector)
return drm_panel_get_modes(dsi->panel, connector);
 }
 
-static const struct drm_encoder_helper_funcs mtk_dsi_encoder_helper_funcs = {
-   .mode_fixup = mtk_dsi_encoder_mode_fixup,
-   .mode_set = mtk_dsi_encoder_mode_set,
-   .disable = mtk_dsi_encoder_disable,
-   .enable = mtk_dsi_encoder_enable,
+static const struct drm_bridge_funcs mtk_dsi_bridge_funcs = {
+   .attach = mtk_dsi_bridge_attach,
+   .detach = mtk_dsi_bridge_detach,
+   .disable = mtk_dsi_bridge_disable,
+   .enable = mtk_dsi_bridge_enable,
+   .mode_set = mtk_dsi_bridge_mode_set,
 };
 
 static const struct drm_connector_funcs mtk_dsi_connector_funcs = {
@@ -888,20 +901,6 @@ static int mtk_dsi_create_conn_enc(struct drm_device *drm, 
struct mtk_dsi *dsi)
 {
int ret;
 
-   ret = drm_encoder_init(drm, >encoder, _dsi_encoder_funcs,
-  DRM_MODE_ENCODER_DSI, NULL);
-   if (ret) {
-   DRM_ERROR("Failed to encoder init to drm\n");
-   return ret;
-   }
-   drm_encoder_helper_add(>encoder, _dsi_encoder_helper_funcs);
-
-   /*
-* Currently display data paths are statically assigned to a crtc each.
-* crtc 0 is OVL0 -> COLOR0 -> AAL -> OD -> RDMA0 -> UFOE -> DSI0
-*/
-   dsi->encoder.possible_crtcs = 1;
-
/* If there's a next 

[PATCH v4 5/7] drm/mediatek: mtk_dsi: Use simple encoder

[Enric Balletbo i Serra]

The mtk_dsi driver uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.

Signed-off-by: Enric Balletbo i Serra 
Reviewed-by: Laurent Pinchart 
Acked-by: Sam Ravnborg 
Reviewed-by: Chun-Kuang Hu 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/mediatek/mtk_dsi.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 38cbdcb15fff..e02d16a086ac 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "mtk_drm_ddp_comp.h"
 
@@ -788,15 +789,6 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
dsi->enabled = false;
 }
 
-static void mtk_dsi_encoder_destroy(struct drm_encoder *encoder)
-{
-   drm_encoder_cleanup(encoder);
-}
-
-static const struct drm_encoder_funcs mtk_dsi_encoder_funcs = {
-   .destroy = mtk_dsi_encoder_destroy,
-};
-
 static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi 
*dsi);
 static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
 
@@ -1126,8 +1118,8 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, 
struct mtk_dsi *dsi)
 {
int ret;
 
-   ret = drm_encoder_init(drm, >encoder, _dsi_encoder_funcs,
-  DRM_MODE_ENCODER_DSI, NULL);
+   ret = drm_simple_encoder_init(drm, >encoder,
+ DRM_MODE_ENCODER_DSI);
if (ret) {
DRM_ERROR("Failed to encoder init to drm\n");
return ret;
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 4/7] drm/mediatek: mtk_dsi: Convert to bridge driver

[Enric Balletbo i Serra]

Hi Chun-Kuang,

Thank you for the review.

On 1/5/20 15:21, Chun-Kuang Hu wrote:
> Hi, Enric:
> 
> Enric Balletbo i Serra  於 2020年4月17日 週五 
> 下午11:06寫道：
>>
>> Convert mtk_dsi to a bridge driver with built-in encoder support for
>> compatibility with existing component drivers.
>>
>> Signed-off-by: Enric Balletbo i Serra 
>> ---
>>
>> Changes in v3:
>> - Add the bridge.type. (Laurent Pinchart)
>>
>> Changes in v2: None
>>
>>  drivers/gpu/drm/mediatek/mtk_dsi.c | 93 ++
>>  1 file changed, 69 insertions(+), 24 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
>> b/drivers/gpu/drm/mediatek/mtk_dsi.c
>> index 37b8d7ffd835..869ae0a2e9f8 100644
>> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
>> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
>> @@ -180,6 +180,7 @@ struct mtk_dsi {
>> struct device *dev;
>> struct mipi_dsi_host host;
>> struct drm_encoder encoder;
>> +   struct drm_bridge bridge;
>> struct drm_connector conn;
>> struct drm_panel *panel;
>> struct drm_bridge *next_bridge;
>> @@ -205,9 +206,9 @@ struct mtk_dsi {
>> const struct mtk_dsi_driver_data *driver_data;
>>  };
>>
>> -static inline struct mtk_dsi *encoder_to_dsi(struct drm_encoder *e)
>> +static inline struct mtk_dsi *bridge_to_dsi(struct drm_bridge *b)
>>  {
>> -   return container_of(e, struct mtk_dsi, encoder);
>> +   return container_of(b, struct mtk_dsi, bridge);
>>  }
>>
>>  static inline struct mtk_dsi *connector_to_dsi(struct drm_connector *c)
>> @@ -796,32 +797,43 @@ static const struct drm_encoder_funcs 
>> mtk_dsi_encoder_funcs = {
>> .destroy = mtk_dsi_encoder_destroy,
>>  };
>>
>> -static bool mtk_dsi_encoder_mode_fixup(struct drm_encoder *encoder,
>> -  const struct drm_display_mode *mode,
>> -  struct drm_display_mode 
>> *adjusted_mode)
>> +static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi 
>> *dsi);
>> +static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
>> +
>> +static int mtk_dsi_bridge_attach(struct drm_bridge *bridge,
>> +enum drm_bridge_attach_flags flags)
>> +{
>> +   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
>> +
>> +   return mtk_dsi_create_conn_enc(bridge->dev, dsi);
>> +}
>> +
>> +static void mtk_dsi_bridge_detach(struct drm_bridge *bridge)
>>  {
>> -   return true;
>> +   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
>> +
>> +   mtk_dsi_destroy_conn_enc(dsi);
>>  }
>>
>> -static void mtk_dsi_encoder_mode_set(struct drm_encoder *encoder,
>> -struct drm_display_mode *mode,
>> -struct drm_display_mode *adjusted)
>> +static void mtk_dsi_bridge_mode_set(struct drm_bridge *bridge,
>> +   const struct drm_display_mode *mode,
>> +   const struct drm_display_mode *adjusted)
>>  {
>> -   struct mtk_dsi *dsi = encoder_to_dsi(encoder);
>> +   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
>>
>> drm_display_mode_to_videomode(adjusted, >vm);
>>  }
>>
>> -static void mtk_dsi_encoder_disable(struct drm_encoder *encoder)
>> +static void mtk_dsi_bridge_disable(struct drm_bridge *bridge)
>>  {
>> -   struct mtk_dsi *dsi = encoder_to_dsi(encoder);
>> +   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
>>
>> mtk_output_dsi_disable(dsi);
>>  }
>>
>> -static void mtk_dsi_encoder_enable(struct drm_encoder *encoder)
>> +static void mtk_dsi_bridge_enable(struct drm_bridge *bridge)
>>  {
>> -   struct mtk_dsi *dsi = encoder_to_dsi(encoder);
>> +   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
>>
>> mtk_output_dsi_enable(dsi);
>>  }
>> @@ -833,11 +845,12 @@ static int mtk_dsi_connector_get_modes(struct 
>> drm_connector *connector)
>> return drm_panel_get_modes(dsi->panel, connector);
>>  }
>>
>> -static const struct drm_encoder_helper_funcs mtk_dsi_encoder_helper_funcs = 
>> {
>> -   .mode_fixup = mtk_dsi_encoder_mode_fixup,
>> -   .mode_set = mtk_dsi_encoder_mode_set,
>> -   .disable = mtk_dsi_encoder_disable,
>> -   .enable = mtk_dsi_encoder_enable,
>> +static const struct drm_bridge_funcs mtk_dsi_bridge_funcs = {
>> +   .attach = mtk_dsi_bridge_attach,
>> +   .detach = mtk_dsi_bridge_detach,
>> +   .disable = mtk_dsi_bridge_disable,
>> +   .enable = mtk_dsi_bridge_enable,
>> +   .mode_set = mtk_dsi_bridge_mode_set,
>>  };
>>
>>  static const struct drm_connector_funcs mtk_dsi_connector_funcs = {
>> @@ -1123,6 +1136,34 @@ static const struct mipi_dsi_host_ops mtk_dsi_ops = {
>> .transfer = mtk_dsi_host_transfer,
>>  };
>>
>> +static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
>> +{
>> +   int ret;
>> +
>> +   ret = drm_encoder_init(drm, >encoder, _dsi_encoder_funcs,
>> +  

RE: [PATCH] drm/i915: check to see if SIMD registers are available before using SIMD

[David Laight]

From: Sebastian Andrzej Siewior
> Sent: 01 May 2020 11:42
> On 2020-04-30 16:10:16 [-0600], Jason A. Donenfeld wrote:
> > Sometimes it's not okay to use SIMD registers, the conditions for which
> > have changed subtly from kernel release to kernel release. Usually the
> > pattern is to check for may_use_simd() and then fallback to using
> > something slower in the unlikely case SIMD registers aren't available.
> > So, this patch fixes up i915's accelerated memcpy routines to fallback
> > to boring memcpy if may_use_simd() is false.
> 
> That would indicate that these functions are used from IRQ/softirq which
> break otherwise if the kernel is also using the registers. The crypto
> code uses it for that purpose.
> 
> So
>Reviewed-by: Sebastian Andrzej Siewior 
> 
> May I ask how large the memcpy can be? I'm asking in case it is large
> and an explicit rescheduling point might be needed.

It is also quite likely that a 'rep movs' copy will be at least just as
fast on modern hardware.

Clearly if you are copying to/from PCIe memory you need the largest
resisters possible - but I think the graphics buffers are mapped cached?
(Otherwise I wouldn't see 3ms 'spins' while it invalidates the
entire screen buffer cache.)

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH hmm v2 3/5] drm/amdgpu: remove dead code after hmm_range_fault()

[Jason Gunthorpe]

From: Jason Gunthorpe 

Since amdgpu does not use the snapshot mode of hmm_range_fault() a
successful return already proves that all entries in the pfns are
HMM_PFN_VALID, there is no need to check the return result of
hmm_device_entry_to_page().

Acked-by: Felix Kuehling 
Signed-off-by: Jason Gunthorpe 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 7eb745b8acce0f..41ae7f96f48194 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -862,17 +862,13 @@ int amdgpu_ttm_tt_get_user_pages(struct amdgpu_bo *bo, 
struct page **pages)
goto out_free_pfns;
}
 
-   for (i = 0; i < ttm->num_pages; i++) {
-   /* FIXME: The pages cannot be touched outside the notifier_lock 
*/
+   /*
+* Due to default_flags, all pages are HMM_PFN_VALID or
+* hmm_range_fault() fails. FIXME: The pages cannot be touched outside
+* the notifier_lock, and mmu_interval_read_retry() must be done first.
+*/
+   for (i = 0; i < ttm->num_pages; i++)
pages[i] = hmm_device_entry_to_page(range, range->pfns[i]);
-   if (unlikely(!pages[i])) {
-   pr_err("Page fault failed for pfn[%lu] = 0x%llx\n",
-  i, range->pfns[i]);
-   r = -ENOMEM;
-
-   goto out_free_pfns;
-   }
-   }
 
gtt->range = range;
mmput(mm);
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/2] Add support for TM5P5 NT35596 video mode panel

[Konrad Dybcio]

I am aware of the fact that this is probably not the correct
naming of this panel, yet I am unable to retrieve any additional
information about it, as it is used in a smartphone to which no
schematics are released.

The driver has been generated with the help of 
linux-mdss-dsi-panel-driver-generator [1] and works perfectly
on a Asus Zenfone 2 Laser Z00T smartphone, including brighness
control and switching on/off.

[1] https://github.com/msm8916-mainline/linux-mdss-dsi-panel-driver-generator

Konrad Dybcio (2):
  drivers: drm: panel: Add TM5P5 NT35596 panel driver
  dt-bindings: display: Document TM5P5 NT35596 panel compatible

 .../bindings/display/panel/tm5p5,nt35596.txt  |   7 +
 drivers/gpu/drm/panel/Kconfig |   9 +
 drivers/gpu/drm/panel/Makefile|   1 +
 drivers/gpu/drm/panel/panel-tm5p5-nt35596.c   | 366 ++
 4 files changed, 383 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/tm5p5,nt35596.txt
 create mode 100644 drivers/gpu/drm/panel/panel-tm5p5-nt35596.c

-- 
2.26.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] dt-bindings: display: Document TM5P5 NT35596 panel compatible

[Konrad Dybcio]

Signed-off-by: Konrad Dybcio 
---
 .../devicetree/bindings/display/panel/tm5p5,nt35596.txt| 7 +++
 1 file changed, 7 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/tm5p5,nt35596.txt

diff --git a/Documentation/devicetree/bindings/display/panel/tm5p5,nt35596.txt 
b/Documentation/devicetree/bindings/display/panel/tm5p5,nt35596.txt
new file mode 100644
index 0..6be56983482bf
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/tm5p5,nt35596.txt
@@ -0,0 +1,7 @@
+TM5P5 NT35596 5.5" 1080×1920 LCD Panel
+
+Required properties:
+  - compatible: "tm5p5,nt35596"
+  - reset-gpios: GPIO spec for reset pin
+  - vdd-supply: VDD regulator
+  - vddio-supply: VDDIO regulator
-- 
2.26.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 2/7] drm/bridge_connector: Set default status connected for eDP connectors

[Enric Balletbo i Serra]

In an eDP application, HPD is not required and on most bridge chips
useless. If HPD is not used, we need to set initial status as connected,
otherwise the connector created by the drm_bridge_connector API remains
in an unknown state.

Signed-off-by: Enric Balletbo i Serra 
Reviewed-by: Laurent Pinchart 
Acked-by: Sam Ravnborg 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/drm_bridge_connector.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_bridge_connector.c 
b/drivers/gpu/drm/drm_bridge_connector.c
index c6994fe673f3..a58cbde59c34 100644
--- a/drivers/gpu/drm/drm_bridge_connector.c
+++ b/drivers/gpu/drm/drm_bridge_connector.c
@@ -187,6 +187,7 @@ drm_bridge_connector_detect(struct drm_connector 
*connector, bool force)
case DRM_MODE_CONNECTOR_DPI:
case DRM_MODE_CONNECTOR_LVDS:
case DRM_MODE_CONNECTOR_DSI:
+   case DRM_MODE_CONNECTOR_eDP:
status = connector_status_connected;
break;
default:
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: check to see if SIMD registers are available before using SIMD

[Sebastian Andrzej Siewior]

On 2020-04-30 16:10:16 [-0600], Jason A. Donenfeld wrote:
> Sometimes it's not okay to use SIMD registers, the conditions for which
> have changed subtly from kernel release to kernel release. Usually the
> pattern is to check for may_use_simd() and then fallback to using
> something slower in the unlikely case SIMD registers aren't available.
> So, this patch fixes up i915's accelerated memcpy routines to fallback
> to boring memcpy if may_use_simd() is false.

That would indicate that these functions are used from IRQ/softirq which
break otherwise if the kernel is also using the registers. The crypto
code uses it for that purpose.

So
   Reviewed-by: Sebastian Andrzej Siewior 

May I ask how large the memcpy can be? I'm asking in case it is large
and an explicit rescheduling point might be needed.

> Cc: sta...@vger.kernel.org
> Signed-off-by: Jason A. Donenfeld 

Sebastian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drivers: drm: panel: Add TM5P5 NT35596 panel driver

[Konrad Dybcio]

This adds support for TMP5P5 NT35596 1080x1920 video
mode panel that can be found on some Asus Zenfone 2
Laser (Z00T) devices.

Signed-off-by: Konrad Dybcio 
---
 drivers/gpu/drm/panel/Kconfig   |   9 +
 drivers/gpu/drm/panel/Makefile  |   1 +
 drivers/gpu/drm/panel/panel-tm5p5-nt35596.c | 366 
 3 files changed, 376 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-tm5p5-nt35596.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index a1723c1b5fbf8..6ff892334ac4b 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -401,6 +401,15 @@ config DRM_PANEL_SONY_ACX565AKM
  Say Y here if you want to enable support for the Sony ACX565AKM
  800x600 3.5" panel (found on the Nokia N900).
 
+config DRM_PANEL_TM5P5_NT35596
+   tristate "TM5P5 NT35596 panel"
+   depends on GPIOLIB && OF
+   depends on DRM_MIPI_DSI
+   help
+ Say Y here if you want to enable support for the TMP5P5
+ NT35596 1080x1920 video mode panel as found in some Asus
+ Zenfone 2 Laser Z00T devices.
+
 config DRM_PANEL_TPO_TD028TTEC1
tristate "Toppoly (TPO) TD028TTEC1 panel driver"
depends on OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 96a883cd66305..4fc7e00b18502 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) += 
panel-sitronix-st7701.o
 obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
 obj-$(CONFIG_DRM_PANEL_SONY_ACX424AKP) += panel-sony-acx424akp.o
 obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
+obj-$(CONFIG_DRM_PANEL_TM5P5_NT35596) += panel-tm5p5-nt35596.o
 obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o
 obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
 obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
diff --git a/drivers/gpu/drm/panel/panel-tm5p5-nt35596.c 
b/drivers/gpu/drm/panel/panel-tm5p5-nt35596.c
new file mode 100644
index 0..c361ab76812b8
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-tm5p5-nt35596.c
@@ -0,0 +1,366 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+struct tm5p5_nt35596 {
+   struct drm_panel panel;
+   struct mipi_dsi_device *dsi;
+   struct regulator_bulk_data supplies[2];
+   struct gpio_desc *reset_gpio;
+   bool prepared;
+};
+
+static inline struct tm5p5_nt35596 *to_tm5p5_nt35596(struct drm_panel *panel)
+{
+   return container_of(panel, struct tm5p5_nt35596, panel);
+}
+
+#define dsi_generic_write_seq(dsi, seq...) do {
\
+   static const u8 d[] = { seq };  \
+   int ret;\
+   ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d));\
+   if (ret < 0)\
+   return ret; \
+   } while (0)
+
+#define dsi_dcs_write_seq(dsi, seq...) do {\
+   static const u8 d[] = { seq };  \
+   int ret;\
+   ret = mipi_dsi_dcs_write_buffer(dsi, d, ARRAY_SIZE(d)); \
+   if (ret < 0)\
+   return ret; \
+   } while (0)
+
+static void tm5p5_nt35596_reset(struct tm5p5_nt35596 *ctx)
+{
+   gpiod_set_value_cansleep(ctx->reset_gpio, 1);
+   usleep_range(1000, 2000);
+   gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+   usleep_range(1000, 2000);
+   gpiod_set_value_cansleep(ctx->reset_gpio, 1);
+   usleep_range(15000, 16000);
+}
+
+static int tm5p5_nt35596_on(struct tm5p5_nt35596 *ctx)
+{
+   struct mipi_dsi_device *dsi = ctx->dsi;
+
+   dsi_generic_write_seq(dsi, 0xff, 0x05);
+   dsi_generic_write_seq(dsi, 0xfb, 0x01);
+   dsi_generic_write_seq(dsi, 0xc5, 0x31);
+   dsi_generic_write_seq(dsi, 0xff, 0x04);
+   dsi_generic_write_seq(dsi, 0x01, 0x84);
+   dsi_generic_write_seq(dsi, 0x05, 0x25);
+   dsi_generic_write_seq(dsi, 0x06, 0x01);
+   dsi_generic_write_seq(dsi, 0x07, 0x20);
+   dsi_generic_write_seq(dsi, 0x08, 0x06);
+   dsi_generic_write_seq(dsi, 0x09, 0x08);
+   dsi_generic_write_seq(dsi, 0x0a, 0x10);
+   dsi_generic_write_seq(dsi, 0x0b, 0x10);
+   dsi_generic_write_seq(dsi, 0x0c, 0x10);
+   dsi_generic_write_seq(dsi, 0x0d, 0x14);
+   dsi_generic_write_seq(dsi, 0x0e, 0x14);
+   dsi_generic_write_seq(dsi, 0x0f, 0x14);
+   dsi_generic_write_seq(dsi, 0x10, 0x14);
+   dsi_generic_write_seq(dsi, 0x11, 0x14);
+   

Re: [PATCH v9 0/3] IT6505 cover letter

[Sam Ravnborg]

Hi Allen.

On Mon, Apr 27, 2020 at 05:16:51PM +0800, allen wrote:
> The IT6505 is a high-performance DisplayPort 1.1a transmitter, fully 
> compliant with DisplayPort 1.1a, HDCP 1.3 specifications. The IT6505 supports 
> color depth of up to 36 bits (12 bits/color) and ensures robust transmission 
> of high-quality uncompressed video content, along with uncompressed and 
> compressed digital audio content.
> 
> This series contains document bindings, revert commit, add vendor prefix, 
> Kconfig to control the function enable or not.

Applied the fix for ITE vendor prefix and the binding to drm-misc-next.
Did a few edits before pushing out.

Sam

> 
> Allen Chen (1):
>   WIP: drm/bridge: add it6505 driver
> 
> allen (2):
>   dt-bindings: Add vendor prefix for ITE Tech. Inc.
>   WIP: dt-bindings: Add binding for IT6505.
> 
>  .../bindings/display/bridge/ite,it6505.yaml|   91 +
>  .../devicetree/bindings/vendor-prefixes.yaml   |2 +-
>  drivers/gpu/drm/bridge/Kconfig |7 +
>  drivers/gpu/drm/bridge/Makefile|1 +
>  drivers/gpu/drm/bridge/ite-it6505.c| 3136 
> 
>  5 files changed, 3236 insertions(+), 1 deletion(-)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
>  create mode 100644 drivers/gpu/drm/bridge/ite-it6505.c
> 
> -- 
> 1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drivers: drm: panel: Add TM5P5 NT35596 panel driver

[Sam Ravnborg]

Hi Konrad.

On Fri, May 01, 2020 at 10:48:22PM +0200, Konrad Dybcio wrote:
> This adds support for TMP5P5 NT35596 1080x1920 video
> mode panel that can be found on some Asus Zenfone 2
> Laser (Z00T) devices.

Very well-writen driver. Only a few small things in the following.

Sam

> 
> Signed-off-by: Konrad Dybcio 
> ---
>  drivers/gpu/drm/panel/Kconfig   |   9 +
>  drivers/gpu/drm/panel/Makefile  |   1 +
>  drivers/gpu/drm/panel/panel-tm5p5-nt35596.c | 366 
>  3 files changed, 376 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-tm5p5-nt35596.c
> 
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index a1723c1b5fbf8..6ff892334ac4b 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -401,6 +401,15 @@ config DRM_PANEL_SONY_ACX565AKM
> Say Y here if you want to enable support for the Sony ACX565AKM
> 800x600 3.5" panel (found on the Nokia N900).
>  
> +config DRM_PANEL_TM5P5_NT35596
> + tristate "TM5P5 NT35596 panel"
> + depends on GPIOLIB && OF
> + depends on DRM_MIPI_DSI
> + help
> +   Say Y here if you want to enable support for the TMP5P5
> +   NT35596 1080x1920 video mode panel as found in some Asus
> +   Zenfone 2 Laser Z00T devices.
> +
>  config DRM_PANEL_TPO_TD028TTEC1
>   tristate "Toppoly (TPO) TD028TTEC1 panel driver"
>   depends on OF && SPI
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 96a883cd66305..4fc7e00b18502 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -42,6 +42,7 @@ obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) += 
> panel-sitronix-st7701.o
>  obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
>  obj-$(CONFIG_DRM_PANEL_SONY_ACX424AKP) += panel-sony-acx424akp.o
>  obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
> +obj-$(CONFIG_DRM_PANEL_TM5P5_NT35596) += panel-tm5p5-nt35596.o
>  obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o
>  obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
>  obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
> diff --git a/drivers/gpu/drm/panel/panel-tm5p5-nt35596.c 
> b/drivers/gpu/drm/panel/panel-tm5p5-nt35596.c
> new file mode 100644
> index 0..c361ab76812b8
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-tm5p5-nt35596.c
> @@ -0,0 +1,366 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +struct tm5p5_nt35596 {
> + struct drm_panel panel;
> + struct mipi_dsi_device *dsi;
> + struct regulator_bulk_data supplies[2];
> + struct gpio_desc *reset_gpio;
> + bool prepared;
> +};
> +
> +static inline struct tm5p5_nt35596 *to_tm5p5_nt35596(struct drm_panel *panel)
> +{
> + return container_of(panel, struct tm5p5_nt35596, panel);
> +}
> +
> +#define dsi_generic_write_seq(dsi, seq...) do {  
> \
> + static const u8 d[] = { seq };  \
> + int ret;\
> + ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d));\
> + if (ret < 0)\
> + return ret; \
> + } while (0)
> +
> +#define dsi_dcs_write_seq(dsi, seq...) do {  \
> + static const u8 d[] = { seq };  \
> + int ret;\
> + ret = mipi_dsi_dcs_write_buffer(dsi, d, ARRAY_SIZE(d)); \
> + if (ret < 0)\
> + return ret; \
> + } while (0)
> +
> +static void tm5p5_nt35596_reset(struct tm5p5_nt35596 *ctx)
> +{
> + gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> + usleep_range(1000, 2000);
> + gpiod_set_value_cansleep(ctx->reset_gpio, 0);
> + usleep_range(1000, 2000);
> + gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> + usleep_range(15000, 16000);
> +}
> +
> +static int tm5p5_nt35596_on(struct tm5p5_nt35596 *ctx)
> +{
> + struct mipi_dsi_device *dsi = ctx->dsi;

Do you have any idea of what happens in the following?
I recall 0xff is explained in a few other drivers for example.

If you get an idea it would be nice with a few headlines.
> +
> + dsi_generic_write_seq(dsi, 0xff, 0x05);
> + dsi_generic_write_seq(dsi, 0xfb, 0x01);
> + dsi_generic_write_seq(dsi, 0xc5, 0x31);
> + dsi_generic_write_seq(dsi, 0xff, 0x04);
> + dsi_generic_write_seq(dsi, 0x01, 0x84);
> + dsi_generic_write_seq(dsi, 0x05, 0x25);
> + dsi_generic_write_seq(dsi, 0x06, 0x01);
> + dsi_generic_write_seq(dsi, 0x07, 0x20);
> + 

Re: [PATCH 1/4] add dts node for drm panel driver ili9341 add dts i2c3 for stmpe touch add dts spi5 for gyro & ili9341

[Sam Ravnborg]

Hi dillon min

> > okay, thanks alexandre, i will go through these docs. currently i'm on may
> day holiday,  will be back at  next wensday.
> after go back to work. i will separate this patch to five part with 9
> patchs , should be more clear
> 
> dts releated
> 1,  ARM: dts: stm32: Add i2c3 node for stm32f429
> 2,  ARM: dts: stm32: Add drm panel ili9341 nodes connect to ldtc
> support for stm32f429-disco board
> 3,  ARM: dts: stm32: Add stmpe811 touch screen support for
> stm32f429-disco board
> 4,  ARM: dts: stm32: Add l3gd20 gyroscope sensor support for
> stm32f429-disco board
> 
> clk releated
> 1, clk: stm32: Fix ltdc loading hang in set clk rate, pll_hw set to
> clks[PLL_VCO_SAI] but not clks[PLL_SAI]
> 2, clk: stm32: Add CLK_IGNORE_UNUSED flags for ltdc, make sure ltdc clk
> not be released after system startup
> 
> spi releated
> 1, spi: stm32: Add transfer mode SPI_SIMPLE_RX, SPI_3WIRE_RX support
> for stm32f4
> 
> drm releated
> 1, drm/panel: Add panel driver ilitek-ili9341
> 
> doc releated
>  1, dt-bindings: display: panel: Add binding document for Ilitek Ili9341

Patch separation looks good.
Please cc: me on both the binding and the panel patches.
The binding must be in DT Schema format (.yaml).
See a lot of examples in drm-misc-next for inspiration.

Looks forward to see/review your submission.

Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel