[Bug 199959] amdgpu, regression?: system freezes after resume
https://bugzilla.kernel.org/show_bug.cgi?id=199959 --- Comment #12 from Alexander Mezin (mezin.alexan...@gmail.com) --- Created attachment 276415 --> https://bugzilla.kernel.org/attachment.cgi?id=276415=edit dmesg: resume with device_resize_fb_bar() in gmc_v?_?_resume() -- 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 199959] amdgpu, regression?: system freezes after resume
https://bugzilla.kernel.org/show_bug.cgi?id=199959 --- Comment #11 from Alexander Mezin (mezin.alexan...@gmail.com) --- I literally have no idea what I'm doing, but adding 'amdgpu_device_resize_fb_bar(adev);' line to all 'gmc_v?_?_resume()' (because I don't know which version is used for my card) "fixed" it somehow. Resume works, but there are some artifacts on screen during resume (they flash only once and then disappear). Before 'amdgpu_device_resize_fb_bar' was introduced, there were no artifacts at all. -- 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
[drm-intel:topic/core-for-CI 7/8] backtracetest.c:undefined reference to `save_stack_trace'
tree: git://anongit.freedesktop.org/drm-intel topic/core-for-CI head: e2ea2db1734a0e38b89e4d706b5f9ad9f73b1543 commit: 72041f9847abb05b9d4d7dea17631b579191ca99 [7/8] RFC: debugobjects: capture stack traces at _init() time config: m68k-allyesconfig (attached as .config) compiler: m68k-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 72041f9847abb05b9d4d7dea17631b579191ca99 # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=m68k All errors (new ones prefixed by >>): kernel/backtracetest.o: In function `backtrace_regression_test': >> backtracetest.c:(.text+0xd8): undefined reference to `save_stack_trace' mm/slub.o: In function `set_track': slub.c:(.text+0x12d2): undefined reference to `save_stack_trace' fs/btrfs/ref-verify.o: In function `btrfs_ref_tree_mod': >> ref-verify.c:(.text+0x92e): undefined reference to `save_stack_trace' lib/debugobjects.o: In function `save_stack.isra.0': debugobjects.c:(.text+0x9f2): undefined reference to `save_stack_trace' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199959] amdgpu, regression?: system freezes after resume
https://bugzilla.kernel.org/show_bug.cgi?id=199959 --- Comment #10 from Alexander Mezin (mezin.alexan...@gmail.com) --- Actually, sometimes mouse pointer moves, and only freezes after I press a few keys/click a few times. Also, sometimes it's just colored pattern instead of the lock screen on the background. With Gnome on Wayland it takes a bit more time to break: after resume I see the desktop, but after a few clicks/key presses I see artifacts and then eventually everything freezes. And just in case: - The problem also occurs with only one monitor connected. - On Windows on the same machine suspend and resume works without any problems. -- 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 199959] amdgpu, regression?: system freezes after resume
https://bugzilla.kernel.org/show_bug.cgi?id=199959 --- Comment #9 from Alexander Mezin (mezin.alexan...@gmail.com) --- It seems that only GPU is hung, I can even SSH to the machine. But things like restarting gdm/Xorg/unplugging the monitor didn't "fix" it. "shutdown -h now" didn't work. -- 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 106446] Stutter at higher refresh rates ( 75 Hz) and artifacts on desktop
https://bugs.freedesktop.org/show_bug.cgi?id=106446 --- Comment #6 from Justin Mitzel --- Have you tried using the amdgpu.dpm=1 kernel command? It's worked for me with my 390X. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105083] Random blinking display
https://bugs.freedesktop.org/show_bug.cgi?id=105083 --- Comment #20 from Öyvind Saether --- Since this bug remains open for some reason I'll report the following: redshift appears to work just fine with both RX 560 & RX 470 and: - kernel 4.17.0-1 (rx 580) / 4.18.0-0.rc0.git2 (rx 470) - X.Org 1.19.6 - mesa 18.0.2 - xfce xfwm4 4.12.4 - compton-0.1-0.1.beta3 kernel commmand line has amdgpu.dc=1 for some reason (default now anyway). I assume both kernels would work fine on both cards, that's just what happens to be running right now. I suspect this bug can be closed but it's probably fair to wait for them russians to confirm. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Xen-devel] [PATCH v2 5/9] xen/gntdev: Allow mappings for DMA buffers
On Fri, 8 Jun 2018, Oleksandr Andrushchenko wrote:
> On 06/08/2018 12:46 AM, Boris Ostrovsky wrote:
> > (Stefano, question for you at the end)
> >
> > On 06/07/2018 02:39 AM, Oleksandr Andrushchenko wrote:
> > > On 06/07/2018 12:19 AM, Boris Ostrovsky wrote:
> > > > On 06/06/2018 04:14 AM, Oleksandr Andrushchenko wrote:
> > > > > On 06/04/2018 11:12 PM, Boris Ostrovsky wrote:
> > > > > > On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
> > > > > > @@ -121,8 +146,27 @@ static void gntdev_free_map(struct grant_map
> > > > > > *map)
> > > > > > if (map == NULL)
> > > > > > return;
> > > > > > +#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
> > > *Option 1: kfree(map->frames);*
> > > > > > + if (map->dma_vaddr) {
> > > > > > + struct gnttab_dma_alloc_args args;
> > > > > > +
> > > > > > + args.dev = map->dma_dev;
> > > > > > + args.coherent = map->dma_flags & GNTDEV_DMA_FLAG_COHERENT;
> > > > > > + args.nr_pages = map->count;
> > > > > > + args.pages = map->pages;
> > > > > > + args.frames = map->frames;
> > > > > > + args.vaddr = map->dma_vaddr;
> > > > > > + args.dev_bus_addr = map->dma_bus_addr;
> > > > > > +
> > > > > > + gnttab_dma_free_pages();
> > > *Option 2: kfree(map->frames);*
> > > > > > + } else
> > > > > > +#endif
> > > > > > if (map->pages)
> > > > > > gnttab_free_pages(map->count, map->pages);
> > > > > > +
> > > > > > +#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
> > > > > > + kfree(map->frames);
> > > > > > +#endif
> > > > > >
> > > > > > Can this be done under if (map->dma_vaddr) ?
> > > > > > In other words, is it
> > > > > > possible for dma_vaddr to be NULL and still have unallocated frames
> > > > > > pointer?
> > > > > It is possible to have vaddr == NULL and frames != NULL as we
> > > > > allocate frames outside of gnttab_dma_alloc_pages which
> > > > > may fail. Calling kfree on NULL pointer is safe,
> > > > I am not questioning safety of the code, I would like avoid another
> > > > ifdef.
> > > Ah, I now understand, so you are asking if we can have
> > > that kfree(map->frames); in the place *Option 2* I marked above.
> > > Unfortunately no: map->frames is allocated before we try to
> > > allocate DMA memory, e.g. before dma_vaddr is set:
> > > [...]
> > > add->frames = kcalloc(count, sizeof(add->frames[0]),
> > > GFP_KERNEL);
> > > if (!add->frames)
> > > goto err;
> > >
> > > [...]
> > > if (gnttab_dma_alloc_pages())
> > > goto err;
> > >
> > > add->dma_vaddr = args.vaddr;
> > > [...]
> > > err:
> > > gntdev_free_map(add);
> > >
> > > So, it is possible to enter gntdev_free_map with
> > > frames != NULL and dma_vaddr == NULL. Option 1 above cannot be used
> > > as map->frames is needed for gnttab_dma_free_pages();
> > > and Option 2 cannot be used as frames != NULL and dma_vaddr == NULL.
> > > Thus, I think that unfortunately we need that #ifdef.
> > > Option 3 below can also be considered, but that seems to be not good
> > > as we free resources in different places which looks inconsistent.
> >
> > I was only thinking of option 2. But if it is possible to have frames !=
> > NULL and dma_vaddr == NULL then perhaps we indeed will have to live with
> > the extra ifdef.
> ok
> >
> > > Sorry if I'm still missing your point.
> > > > > so
> > > > > I see no reason to change this code.
> > > > > > > kfree(map->pages);
> > > > > > > kfree(map->grants);
> > > > > > > kfree(map->map_ops);
> > > > > > > @@ -132,7 +176,8 @@ static void gntdev_free_map(struct grant_map
> > > > > > > *map)
> > > > > > > kfree(map);
> > > > > > > }
> > > > > > > -static struct grant_map *gntdev_alloc_map(struct gntdev_priv
> > > > > > > *priv, int count)
> > > > > > > +static struct grant_map *gntdev_alloc_map(struct gntdev_priv
> > > > > > > *priv,
> > > > > > > int count,
> > > > > > > + int dma_flags)
> > > > > > > {
> > > > > > > struct grant_map *add;
> > > > > > > int i;
> > > > > > > @@ -155,6 +200,37 @@ static struct grant_map
> > > > > > > *gntdev_alloc_map(struct gntdev_priv *priv, int count)
> > > > > > > NULL == add->pages)
> > > > > > > goto err;
> > > > > > > +#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
> > > > > > > + add->dma_flags = dma_flags;
> > > > > > > +
> > > > > > > + /*
> > > > > > > + * Check if this mapping is requested to be backed
> > > > > > > + * by a DMA buffer.
> > > > > > > + */
> > > > > > > + if (dma_flags & (GNTDEV_DMA_FLAG_WC |
> > > > > > > GNTDEV_DMA_FLAG_COHERENT)) {
> > > > > > > + struct gnttab_dma_alloc_args args;
> > > > > > > +
> > > > > > > + add->frames = kcalloc(count, sizeof(add->frames[0]),
> > > > > > > + GFP_KERNEL);
> > > > > > > + if (!add->frames)
> > > > > > > + goto err;
> > > > > > > +
> >
[Bug 199619] screen stays dark for long on bootup since kernel 4.17.0-rc2+
https://bugzilla.kernel.org/show_bug.cgi?id=199619 --- Comment #6 from Elmar Stellnberger (estel...@elstel.org) --- This applies to the nouveau driver. -- 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 3/3] drm/v3d: Add a note about locking of v3d_fence_create().
Lucas Stach writes: > Am Dienstag, den 05.06.2018, 12:03 -0700 schrieb Eric Anholt: >> This isn't the first time I've had to argue to myself why the '++' was >> safe. > > And now you need to do the same thing with me... > >> Signed-off-by: Eric Anholt >> --- >> drivers/gpu/drm/v3d/v3d_fence.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/gpu/drm/v3d/v3d_fence.c >> b/drivers/gpu/drm/v3d/v3d_fence.c >> index bfe31a89668b..6265e9ab4a13 100644 >> --- a/drivers/gpu/drm/v3d/v3d_fence.c >> +++ b/drivers/gpu/drm/v3d/v3d_fence.c >> @@ -3,6 +3,9 @@ >> >> #include "v3d_drv.h" >> >> +/* Note that V3D fences are created during v3d_job_run(), so we're >> + * already implictly locked. >> + */ > I don't see where you would be locked in the job_run path. I think what > you mean is that this path needs no locks, as it is driven by a single > scheduler thread, right? Yeah, it's only called from run_job, and run_job can't reenter. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199619] screen stays dark for long on bootup since kernel 4.17.0-rc2+
https://bugzilla.kernel.org/show_bug.cgi?id=199619 --- Comment #5 from Elmar Stellnberger (estel...@elstel.org) --- The issue persists with kernel 4.17.0+. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 23/23] drm/omap: Don't call .set_timings() operation recursively
Instead of calling the .set_timings() operation recursively from the
display device backwards, iterate over the devices manually in the DRM
encoder code. This moves the complexity to a single central location and
simplifies the logic in omap_dss_device drivers.
Signed-off-by: Laurent Pinchart
---
.../gpu/drm/omapdrm/displays/connector-analog-tv.c | 10 --
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 10 --
drivers/gpu/drm/omapdrm/displays/connector-hdmi.c| 10 --
drivers/gpu/drm/omapdrm/displays/encoder-opa362.c| 11 ---
drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c| 9 -
drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c | 9 -
drivers/gpu/drm/omapdrm/displays/panel-dpi.c | 9 -
.../drm/omapdrm/displays/panel-lgphilips-lb035q02.c | 9 -
.../gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c | 9 -
.../drm/omapdrm/displays/panel-sharp-ls037v7dw01.c | 9 -
.../gpu/drm/omapdrm/displays/panel-sony-acx565akm.c | 9 -
.../gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c | 9 -
.../gpu/drm/omapdrm/displays/panel-tpo-td043mtea1.c | 9 -
drivers/gpu/drm/omapdrm/dss/dpi.c| 2 --
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 2 --
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 2 --
drivers/gpu/drm/omapdrm/dss/sdi.c| 2 --
drivers/gpu/drm/omapdrm/dss/venc.c | 2 --
drivers/gpu/drm/omapdrm/omap_encoder.c | 20
19 files changed, 8 insertions(+), 144 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
index 4866bf8ed524..28a3ce8f88d2 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
@@ -73,22 +73,12 @@ static void tvc_disable(struct omap_dss_device *dssdev)
dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
}
-static void tvc_set_timings(struct omap_dss_device *dssdev,
- const struct videomode *vm)
-{
- struct omap_dss_device *src = dssdev->src;
-
- src->ops->set_timings(src, vm);
-}
-
static const struct omap_dss_device_ops tvc_ops = {
.connect= tvc_connect,
.disconnect = tvc_disconnect,
.enable = tvc_enable,
.disable= tvc_disable,
-
- .set_timings= tvc_set_timings,
};
static int tvc_probe(struct platform_device *pdev)
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
index 818a4dc452e0..24b14f44248e 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
@@ -78,14 +78,6 @@ static void dvic_disable(struct omap_dss_device *dssdev)
dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
}
-static void dvic_set_timings(struct omap_dss_device *dssdev,
-const struct videomode *vm)
-{
- struct omap_dss_device *src = dssdev->src;
-
- src->ops->set_timings(src, vm);
-}
-
static int dvic_ddc_read(struct i2c_adapter *adapter,
unsigned char *buf, u16 count, u8 offset)
{
@@ -192,8 +184,6 @@ static const struct omap_dss_device_ops dvic_ops = {
.enable = dvic_enable,
.disable= dvic_disable,
- .set_timings= dvic_set_timings,
-
.read_edid = dvic_read_edid,
.detect = dvic_detect,
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
index a32e4159242d..e602fa4a50a4 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
@@ -79,14 +79,6 @@ static void hdmic_disable(struct omap_dss_device *dssdev)
dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
}
-static void hdmic_set_timings(struct omap_dss_device *dssdev,
- const struct videomode *vm)
-{
- struct omap_dss_device *src = dssdev->src;
-
- src->ops->set_timings(src, vm);
-}
-
static bool hdmic_detect(struct omap_dss_device *dssdev)
{
struct panel_drv_data *ddata = to_panel_data(dssdev);
@@ -124,8 +116,6 @@ static const struct omap_dss_device_ops hdmic_ops = {
.enable = hdmic_enable,
.disable= hdmic_disable,
- .set_timings= hdmic_set_timings,
-
.detect = hdmic_detect,
.register_hpd_cb= hdmic_register_hpd_cb,
.unregister_hpd_cb = hdmic_unregister_hpd_cb,
diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c
b/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c
index 0604169d8951..e535db6bc574 100644
---
[PATCH 21/23] drm/omap: venc: Fixup video mode in .check_timings() operation
The VENC encoder modifies the requested video mode to match the NTSC or
PAL timings (or reject the video mode completely) in the .set_timings()
operation. This should be performed in the .check_timings() operation
instead. Move the fixup.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/venc.c | 23 ---
1 file changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/venc.c
b/drivers/gpu/drm/omapdrm/dss/venc.c
index 310cf4251788..ebe80d92ecf7 100644
--- a/drivers/gpu/drm/omapdrm/dss/venc.c
+++ b/drivers/gpu/drm/omapdrm/dss/venc.c
@@ -452,7 +452,7 @@ static void venc_runtime_put(struct venc_device *venc)
WARN_ON(r < 0 && r != -ENOSYS);
}
-static const struct venc_config *venc_timings_to_config(struct videomode *vm)
+static const struct venc_config *venc_timings_to_config(const struct videomode
*vm)
{
switch (venc_get_videomode(vm)) {
default:
@@ -582,28 +582,16 @@ static void venc_set_timings(struct omap_dss_device
*dssdev,
const struct videomode *vm)
{
struct venc_device *venc = dssdev_to_venc(dssdev);
- struct videomode actual_vm;
DSSDBG("venc_set_timings\n");
mutex_lock(>venc_lock);
- switch (venc_get_videomode(vm)) {
- default:
- WARN_ON_ONCE(1);
- case VENC_MODE_PAL:
- actual_vm = omap_dss_pal_vm;
- break;
- case VENC_MODE_NTSC:
- actual_vm = omap_dss_ntsc_vm;
- break;
- }
-
/* Reset WSS data when the TV standard changes. */
- if (memcmp(>vm, _vm, sizeof(actual_vm)))
+ if (memcmp(>vm, vm, sizeof(*vm)))
venc->wss_data = 0;
- venc->vm = actual_vm;
+ venc->vm = *vm;
dispc_set_tv_pclk(venc->dss->dispc, 1350);
@@ -617,8 +605,13 @@ static int venc_check_timings(struct omap_dss_device
*dssdev,
switch (venc_get_videomode(vm)) {
case VENC_MODE_PAL:
+ *vm = omap_dss_pal_vm;
+ return 0;
+
case VENC_MODE_NTSC:
+ *vm = omap_dss_ntsc_vm;
return 0;
+
default:
return -EINVAL;
}
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 22/23] drm/omap: Store CRTC timings in .set_timings() operation
The video timings are stored in the CRTC structure by the
omap_crtc_dss_set_timings() function, called by dss_mgr_set_timings()
from the .enable() operation of the internal encoders. This instead
belongs to the .set_timings() code paths. Move the
omap_crtc_dss_set_timings() calls accordingly.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/dpi.c | 4 ++--
drivers/gpu/drm/omapdrm/dss/dsi.c | 6 ++
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 5 ++---
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 5 ++---
drivers/gpu/drm/omapdrm/dss/sdi.c | 4 ++--
drivers/gpu/drm/omapdrm/dss/venc.c | 4 ++--
6 files changed, 12 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c
b/drivers/gpu/drm/omapdrm/dss/dpi.c
index e6628ba267de..40bb7dc6e36d 100644
--- a/drivers/gpu/drm/omapdrm/dss/dpi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
@@ -361,8 +361,6 @@ static int dpi_set_mode(struct dpi_data *dpi)
if (r)
return r;
- dss_mgr_set_timings(>output, vm);
-
return 0;
}
@@ -479,6 +477,8 @@ static void dpi_set_timings(struct omap_dss_device *dssdev,
dpi->vm = *vm;
+ dss_mgr_set_timings(>output, vm);
+
mutex_unlock(>lock);
}
diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
b/drivers/gpu/drm/omapdrm/dss/dsi.c
index 3a954f7237d7..f58453310a48 100644
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -3901,8 +3901,6 @@ static void dsi_update_screen_dispc(struct dsi_data *dsi)
msecs_to_jiffies(250));
BUG_ON(r == 0);
- dss_mgr_set_timings(>output, >vm);
-
dss_mgr_start_update(>output);
if (dsi->te_enabled) {
@@ -4044,8 +4042,6 @@ static int dsi_display_init_dispc(struct dsi_data *dsi)
dsi->mgr_config.fifohandcheck = false;
}
- dss_mgr_set_timings(>output, >vm);
-
r = dsi_configure_dispc_clocks(dsi);
if (r)
goto err1;
@@ -4756,6 +4752,8 @@ static int dsi_set_config(struct omap_dss_device *dssdev,
dsi->vm.flags &= ~DISPLAY_FLAGS_VSYNC_LOW;
dsi->vm.flags |= DISPLAY_FLAGS_VSYNC_HIGH;
+ dss_mgr_set_timings(>output, >vm);
+
dsi->vm_timings = ctx.dsi_vm;
mutex_unlock(>lock);
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
index 7ad173098c22..df7cfb3e2b12 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
@@ -207,9 +207,6 @@ static int hdmi_power_on_full(struct omap_hdmi *hdmi)
hdmi4_configure(>core, >wp, >cfg);
- /* tv size */
- dss_mgr_set_timings(>output, vm);
-
r = dss_mgr_enable(>output);
if (r)
goto err_mgr_enable;
@@ -262,6 +259,8 @@ static void hdmi_display_set_timings(struct omap_dss_device
*dssdev,
dispc_set_tv_pclk(hdmi->dss->dispc, vm->pixelclock);
+ dss_mgr_set_timings(>output, vm);
+
mutex_unlock(>lock);
}
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
index 147c3550df51..cb212e5e790f 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
@@ -206,9 +206,6 @@ static int hdmi_power_on_full(struct omap_hdmi *hdmi)
hdmi5_configure(>core, >wp, >cfg);
- /* tv size */
- dss_mgr_set_timings(>output, vm);
-
r = dss_mgr_enable(>output);
if (r)
goto err_mgr_enable;
@@ -261,6 +258,8 @@ static void hdmi_display_set_timings(struct omap_dss_device
*dssdev,
dispc_set_tv_pclk(hdmi->dss->dispc, vm->pixelclock);
+ dss_mgr_set_timings(>output, vm);
+
mutex_unlock(>lock);
}
diff --git a/drivers/gpu/drm/omapdrm/dss/sdi.c
b/drivers/gpu/drm/omapdrm/dss/sdi.c
index 9dd686ae63c1..1009b217113a 100644
--- a/drivers/gpu/drm/omapdrm/dss/sdi.c
+++ b/drivers/gpu/drm/omapdrm/dss/sdi.c
@@ -152,8 +152,6 @@ static int sdi_display_enable(struct omap_dss_device
*dssdev)
sdi->mgr_config.clock_info = dispc_cinfo;
- dss_mgr_set_timings(>output, >vm);
-
r = dss_set_fck_rate(sdi->dss, fck);
if (r)
goto err_set_dss_clock_div;
@@ -217,6 +215,8 @@ static void sdi_set_timings(struct omap_dss_device *dssdev,
struct sdi_device *sdi = dssdev_to_sdi(dssdev);
sdi->vm = *vm;
+
+ dss_mgr_set_timings(>output, vm);
}
static int sdi_check_timings(struct omap_dss_device *dssdev,
diff --git a/drivers/gpu/drm/omapdrm/dss/venc.c
b/drivers/gpu/drm/omapdrm/dss/venc.c
index ebe80d92ecf7..9373fda0cce8 100644
--- a/drivers/gpu/drm/omapdrm/dss/venc.c
+++ b/drivers/gpu/drm/omapdrm/dss/venc.c
@@ -491,8 +491,6 @@ static int venc_power_on(struct venc_device *venc)
venc_write_reg(venc, VENC_OUTPUT_CONTROL, l);
- dss_mgr_set_timings(>output, >vm);
-
r = regulator_enable(venc->vdda_dac_reg);
if (r)
goto err1;
@@ -595,6 +593,8 @@ static void
[PATCH 16/23] drm/omap: Call dispc timings check operation directly
Instead of call the dispc timings check function dispc_mgr_timings_ok()
from the internal encoders .check_timings() operation, expose it through
the dispc ops (after renaming it to check_timings) and call it directly
from omapdrm. This allows removal of now empty omap_dss_device
.check_timings() operations.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 18 ++
drivers/gpu/drm/omapdrm/dss/dpi.c| 4
drivers/gpu/drm/omapdrm/dss/dss.h| 3 ---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 12
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 12
drivers/gpu/drm/omapdrm/dss/omapdss.h| 3 +++
drivers/gpu/drm/omapdrm/dss/sdi.c| 6 --
drivers/gpu/drm/omapdrm/omap_connector.c | 6 ++
drivers/gpu/drm/omapdrm/omap_encoder.c | 18 +-
9 files changed, 32 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index bc207f2fb200..02532cde26ce 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -3113,28 +3113,29 @@ static bool _dispc_mgr_pclk_ok(struct dispc_device
*dispc,
return pclk <= dispc->feat->max_tv_pclk;
}
-bool dispc_mgr_timings_ok(struct dispc_device *dispc, enum omap_channel
channel,
- const struct videomode *vm)
+static int dispc_mgr_check_timings(struct dispc_device *dispc,
+ enum omap_channel channel,
+ const struct videomode *vm)
{
if (!_dispc_mgr_size_ok(dispc, vm->hactive, vm->vactive))
- return false;
+ return MODE_BAD;
if (!_dispc_mgr_pclk_ok(dispc, channel, vm->pixelclock))
- return false;
+ return MODE_BAD;
if (dss_mgr_is_lcd(channel)) {
/* TODO: OMAP4+ supports interlace for LCD outputs */
if (vm->flags & DISPLAY_FLAGS_INTERLACED)
- return false;
+ return MODE_BAD;
if (!_dispc_lcd_timings_ok(dispc, vm->hsync_len,
vm->hfront_porch, vm->hback_porch,
vm->vsync_len, vm->vfront_porch,
vm->vback_porch))
- return false;
+ return MODE_BAD;
}
- return true;
+ return MODE_OK;
}
static void _dispc_mgr_set_lcd_timings(struct dispc_device *dispc,
@@ -3236,7 +3237,7 @@ static void dispc_mgr_set_timings(struct dispc_device
*dispc,
DSSDBG("channel %d xres %u yres %u\n", channel, t.hactive, t.vactive);
- if (!dispc_mgr_timings_ok(dispc, channel, )) {
+ if (dispc_mgr_check_timings(dispc, channel, )) {
BUG();
return;
}
@@ -4733,6 +4734,7 @@ static const struct dispc_ops dispc_ops = {
.mgr_go_busy = dispc_mgr_go_busy,
.mgr_go = dispc_mgr_go,
.mgr_set_lcd_config = dispc_mgr_set_lcd_config,
+ .mgr_check_timings = dispc_mgr_check_timings,
.mgr_set_timings = dispc_mgr_set_timings,
.mgr_setup = dispc_mgr_setup,
.mgr_gamma_size = dispc_mgr_gamma_size,
diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c
b/drivers/gpu/drm/omapdrm/dss/dpi.c
index 36493a0c580b..1fb864c294e8 100644
--- a/drivers/gpu/drm/omapdrm/dss/dpi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
@@ -496,7 +496,6 @@ static int dpi_check_timings(struct omap_dss_device *dssdev,
struct videomode *vm)
{
struct dpi_data *dpi = dpi_get_data_from_dssdev(dssdev);
- enum omap_channel channel = dpi->output.dispc_channel;
int lck_div, pck_div;
unsigned long fck;
unsigned long pck;
@@ -506,9 +505,6 @@ static int dpi_check_timings(struct omap_dss_device *dssdev,
if (vm->hactive % 8 != 0)
return -EINVAL;
- if (!dispc_mgr_timings_ok(dpi->dss->dispc, channel, vm))
- return -EINVAL;
-
if (vm->pixelclock == 0)
return -EINVAL;
diff --git a/drivers/gpu/drm/omapdrm/dss/dss.h
b/drivers/gpu/drm/omapdrm/dss/dss.h
index 81dd0c910ea1..c7cf69ff9e79 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.h
+++ b/drivers/gpu/drm/omapdrm/dss/dss.h
@@ -414,9 +414,6 @@ bool dispc_div_calc(struct dispc_device *dispc, unsigned
long dispc_freq,
unsigned long pck_min, unsigned long pck_max,
dispc_div_calc_func func, void *data);
-bool dispc_mgr_timings_ok(struct dispc_device *dispc,
- enum omap_channel channel,
- const struct videomode *vm);
int dispc_calc_clock_rates(struct dispc_device *dispc,
unsigned long dispc_fclk_rate,
struct dispc_clock_info *cinfo);
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
[PATCH 14/23] drm/omap: Move bus flag hack to encoder implementation
The bus flags stored in omap_dss_device instances are used to fixup the
video mode before setting it, to honour constraints that can't be
expressed through drm_display_mode. The fixup occurs in the CRTC mode
set operation and the resulting video mode is stored internally in the
CRTC. It is then used next by omap_encoder_enable() to apply mode fixups
for the omap_dss_device instances in omap_encoder_update().
Move the hack to the omap_encoder_update() function right before
applying the omap_dss_device fixups, in order to group all fixups
together.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_crtc.c| 42 +
drivers/gpu/drm/omapdrm/omap_encoder.c | 48 +-
2 files changed, 43 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 39693dfe54af..62928ec0e7db 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -420,8 +420,6 @@ static void omap_crtc_mode_set_nofb(struct drm_crtc *crtc)
{
struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
struct drm_display_mode *mode = >state->adjusted_mode;
- struct videomode *vm = _crtc->vm;
- struct omap_dss_device *dssdev;
DBG("%s: set mode: %d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
omap_crtc->name, mode->base.id, mode->name,
@@ -430,45 +428,7 @@ static void omap_crtc_mode_set_nofb(struct drm_crtc *crtc)
mode->vdisplay, mode->vsync_start, mode->vsync_end, mode->vtotal,
mode->type, mode->flags);
- drm_display_mode_to_videomode(mode, vm);
-
- /*
-* HACK: This fixes the vm flags.
-* struct drm_display_mode does not contain the VSYNC/HSYNC/DE flags
-* and they get lost when converting back and forth between
-* struct drm_display_mode and struct videomode. The hack below
-* goes and fetches the missing flags from the panel drivers.
-*
-* A better solution is to use DRM's bus-flags through the whole driver.
-*/
-
- for (dssdev = omap_crtc->pipe->output; dssdev; dssdev = dssdev->next) {
- unsigned long bus_flags = dssdev->bus_flags;
-
- if (!(vm->flags & (DISPLAY_FLAGS_DE_LOW |
- DISPLAY_FLAGS_DE_HIGH))) {
- if (bus_flags & DRM_BUS_FLAG_DE_LOW)
- vm->flags |= DISPLAY_FLAGS_DE_LOW;
- else if (bus_flags & DRM_BUS_FLAG_DE_HIGH)
- vm->flags |= DISPLAY_FLAGS_DE_HIGH;
- }
-
- if (!(vm->flags & (DISPLAY_FLAGS_PIXDATA_POSEDGE |
- DISPLAY_FLAGS_PIXDATA_NEGEDGE))) {
- if (bus_flags & DRM_BUS_FLAG_PIXDATA_POSEDGE)
- vm->flags |= DISPLAY_FLAGS_PIXDATA_POSEDGE;
- else if (bus_flags & DRM_BUS_FLAG_PIXDATA_NEGEDGE)
- vm->flags |= DISPLAY_FLAGS_PIXDATA_NEGEDGE;
- }
-
- if (!(vm->flags & (DISPLAY_FLAGS_SYNC_POSEDGE |
- DISPLAY_FLAGS_SYNC_NEGEDGE))) {
- if (bus_flags & DRM_BUS_FLAG_SYNC_POSEDGE)
- vm->flags |= DISPLAY_FLAGS_SYNC_POSEDGE;
- else if (bus_flags & DRM_BUS_FLAG_SYNC_NEGEDGE)
- vm->flags |= DISPLAY_FLAGS_SYNC_NEGEDGE;
- }
- }
+ drm_display_mode_to_videomode(mode, _crtc->vm);
}
static int omap_crtc_atomic_check(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/omapdrm/omap_encoder.c
b/drivers/gpu/drm/omapdrm/omap_encoder.c
index bb010c20d8b8..82cdcba961a8 100644
--- a/drivers/gpu/drm/omapdrm/omap_encoder.c
+++ b/drivers/gpu/drm/omapdrm/omap_encoder.c
@@ -103,13 +103,49 @@ static int omap_encoder_update(struct drm_encoder
*encoder,
int ret;
for (dssdev = omap_encoder->output; dssdev; dssdev = dssdev->next) {
- if (!dssdev->ops->check_timings)
- continue;
+ unsigned long bus_flags = dssdev->bus_flags;
+
+ if (dssdev->ops->check_timings) {
+ ret = dssdev->ops->check_timings(dssdev, vm);
+ if (ret) {
+ dev_err(dev->dev, "invalid timings: %d\n", ret);
+ return ret;
+ }
+ }
+
+ /*
+* HACK: This fixes the vm flags.
+* struct drm_display_mode does not contain the VSYNC/HSYNC/DE
+* flags and they get lost when converting back and forth
+* between struct drm_display_mode and struct videomode. The
+* hack below goes and fetches the missing flags.
+*
+* A better solution is to use
[PATCH 19/23] drm/omap: hdmi: Constify video mode and related pointers
Constify many pointers to struct videomode, as well as pointers to
container structures, to ensure the video mode isn't modified after
the .check_timings() operation.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/hdmi.h | 8
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 2 +-
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 2 +-
drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 6 +++---
drivers/gpu/drm/omapdrm/dss/hdmi_wp.c| 8
5 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi.h
b/drivers/gpu/drm/omapdrm/dss/hdmi.h
index 3aeb4cabd59f..7f0dc490a31d 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi.h
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi.h
@@ -313,13 +313,13 @@ void hdmi_wp_clear_irqenable(struct hdmi_wp_data *wp, u32
mask);
int hdmi_wp_set_phy_pwr(struct hdmi_wp_data *wp, enum hdmi_phy_pwr val);
int hdmi_wp_set_pll_pwr(struct hdmi_wp_data *wp, enum hdmi_pll_pwr val);
void hdmi_wp_video_config_format(struct hdmi_wp_data *wp,
- struct hdmi_video_format *video_fmt);
+ const struct hdmi_video_format *video_fmt);
void hdmi_wp_video_config_interface(struct hdmi_wp_data *wp,
- struct videomode *vm);
+ const struct videomode *vm);
void hdmi_wp_video_config_timing(struct hdmi_wp_data *wp,
- struct videomode *vm);
+ const struct videomode *vm);
void hdmi_wp_init_vid_fmt_timings(struct hdmi_video_format *video_fmt,
- struct videomode *vm, struct hdmi_config *param);
+ struct videomode *vm, const struct hdmi_config *param);
int hdmi_wp_init(struct platform_device *pdev, struct hdmi_wp_data *wp,
unsigned int version);
phys_addr_t hdmi_wp_get_audio_dma_addr(struct hdmi_wp_data *wp);
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
index 3e2bc85ef538..7ad173098c22 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
@@ -154,7 +154,7 @@ static void hdmi_power_off_core(struct omap_hdmi *hdmi)
static int hdmi_power_on_full(struct omap_hdmi *hdmi)
{
int r;
- struct videomode *vm;
+ const struct videomode *vm;
struct hdmi_wp_data *wp = >wp;
struct dss_pll_clock_info hdmi_cinfo = { 0 };
unsigned int pc;
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
index c02e08299155..147c3550df51 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
@@ -153,7 +153,7 @@ static void hdmi_power_off_core(struct omap_hdmi *hdmi)
static int hdmi_power_on_full(struct omap_hdmi *hdmi)
{
int r;
- struct videomode *vm;
+ const struct videomode *vm;
struct dss_pll_clock_info hdmi_cinfo = { 0 };
unsigned int pc;
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
b/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
index 2282e48574c6..02efabc7ed76 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
@@ -287,7 +287,7 @@ void hdmi5_core_dump(struct hdmi_core_data *core, struct
seq_file *s)
}
static void hdmi_core_init(struct hdmi_core_vid_config *video_cfg,
- struct hdmi_config *cfg)
+ const struct hdmi_config *cfg)
{
DSSDBG("hdmi_core_init\n");
@@ -325,10 +325,10 @@ static void hdmi_core_init(struct hdmi_core_vid_config
*video_cfg,
/* DSS_HDMI_CORE_VIDEO_CONFIG */
static void hdmi_core_video_config(struct hdmi_core_data *core,
- struct hdmi_core_vid_config *cfg)
+ const struct hdmi_core_vid_config *cfg)
{
void __iomem *base = core->base;
- struct videomode *vm = >v_fc_config.vm;
+ const struct videomode *vm = >v_fc_config.vm;
unsigned char r = 0;
bool vsync_pol, hsync_pol;
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi_wp.c
b/drivers/gpu/drm/omapdrm/dss/hdmi_wp.c
index 53bc5f78050c..100efb9f08c6 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi_wp.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi_wp.c
@@ -131,7 +131,7 @@ void hdmi_wp_video_stop(struct hdmi_wp_data *wp)
}
void hdmi_wp_video_config_format(struct hdmi_wp_data *wp,
- struct hdmi_video_format *video_fmt)
+ const struct hdmi_video_format *video_fmt)
{
u32 l = 0;
@@ -144,7 +144,7 @@ void hdmi_wp_video_config_format(struct hdmi_wp_data *wp,
}
void hdmi_wp_video_config_interface(struct hdmi_wp_data *wp,
- struct videomode *vm)
+ const struct videomode *vm)
{
u32 r;
bool vsync_inv, hsync_inv;
@@ -164,7 +164,7 @@ void hdmi_wp_video_config_interface(struct hdmi_wp_data *wp,
}
void hdmi_wp_video_config_timing(struct hdmi_wp_data *wp,
-struct videomode *vm)
+const struct
[PATCH 15/23] drm/omap: Split mode fixup and mode set from encoder enable
The encoder enable operation currently performs mode fixup and mode
setting for all omap_dss_device instances in the display pipeline. There
are dedicated encoder operations for those operations (respectively
.atomic_check() and .mode_set()), but they are not used for this
purpose.
Move the mode fixup code to .atomic_check() and the mode set code
.mode_set() to better fit the KMS model. The bus flags fixup has to
happen at .mode_set() time as there is no place to store the bus flags
in the atomic state structures. This could be solved by extending one of
the state structures, but as the goal is to replace the fixup by direct
usage of bus flags through the driver, that would be pointless.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_encoder.c | 148 ++---
1 file changed, 79 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_encoder.c
b/drivers/gpu/drm/omapdrm/omap_encoder.c
index 82cdcba961a8..0177a2c4b77a 100644
--- a/drivers/gpu/drm/omapdrm/omap_encoder.c
+++ b/drivers/gpu/drm/omapdrm/omap_encoder.c
@@ -53,16 +53,69 @@ static const struct drm_encoder_funcs omap_encoder_funcs = {
};
static void omap_encoder_mode_set(struct drm_encoder *encoder,
- struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
+ struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
{
struct drm_device *dev = encoder->dev;
struct omap_encoder *omap_encoder = to_omap_encoder(encoder);
- struct omap_dss_device *dssdev = omap_encoder->output;
+ struct omap_dss_device *display = omap_encoder->display;
struct drm_connector *connector;
+ struct omap_dss_device *dssdev;
+ struct videomode vm = { 0 };
bool hdmi_mode;
int r;
+ drm_display_mode_to_videomode(adjusted_mode, );
+
+ /*
+* HACK: This fixes the vm flags.
+* struct drm_display_mode does not contain the VSYNC/HSYNC/DE flags and
+* they get lost when converting back and forth between struct
+* drm_display_mode and struct videomode. The hack below goes and
+* fetches the missing flags.
+*
+* A better solution is to use DRM's bus-flags through the whole driver.
+*/
+ for (dssdev = omap_encoder->output; dssdev; dssdev = dssdev->next) {
+ unsigned long bus_flags = dssdev->bus_flags;
+
+ if (!(vm.flags & (DISPLAY_FLAGS_DE_LOW |
+ DISPLAY_FLAGS_DE_HIGH))) {
+ if (bus_flags & DRM_BUS_FLAG_DE_LOW)
+ vm.flags |= DISPLAY_FLAGS_DE_LOW;
+ else if (bus_flags & DRM_BUS_FLAG_DE_HIGH)
+ vm.flags |= DISPLAY_FLAGS_DE_HIGH;
+ }
+
+ if (!(vm.flags & (DISPLAY_FLAGS_PIXDATA_POSEDGE |
+ DISPLAY_FLAGS_PIXDATA_NEGEDGE))) {
+ if (bus_flags & DRM_BUS_FLAG_PIXDATA_POSEDGE)
+ vm.flags |= DISPLAY_FLAGS_PIXDATA_POSEDGE;
+ else if (bus_flags & DRM_BUS_FLAG_PIXDATA_NEGEDGE)
+ vm.flags |= DISPLAY_FLAGS_PIXDATA_NEGEDGE;
+ }
+
+ if (!(vm.flags & (DISPLAY_FLAGS_SYNC_POSEDGE |
+ DISPLAY_FLAGS_SYNC_NEGEDGE))) {
+ if (bus_flags & DRM_BUS_FLAG_SYNC_POSEDGE)
+ vm.flags |= DISPLAY_FLAGS_SYNC_POSEDGE;
+ else if (bus_flags & DRM_BUS_FLAG_SYNC_NEGEDGE)
+ vm.flags |= DISPLAY_FLAGS_SYNC_NEGEDGE;
+ }
+ }
+
+ /*
+* HACK: Call the .set_timings() operation if available, this will
+* eventually store timings in the CRTC. Otherwise (for DSI outputs)
+* store the timings directly.
+*
+* All outputs should be brought in sync to operate similarly.
+*/
+ if (display->ops->set_timings)
+ display->ops->set_timings(display, );
+ else
+ *omap_crtc_timings(encoder->crtc) = vm;
+
hdmi_mode = false;
list_for_each_entry(connector, >mode_config.connector_list, head) {
if (connector->encoder == encoder) {
@@ -71,6 +124,8 @@ static void omap_encoder_mode_set(struct drm_encoder
*encoder,
}
}
+ dssdev = omap_encoder->output;
+
if (dssdev->ops->hdmi.set_hdmi_mode)
dssdev->ops->hdmi.set_hdmi_mode(dssdev, hdmi_mode);
@@ -92,78 +147,12 @@ static void omap_encoder_disable(struct drm_encoder
*encoder)
dssdev->ops->disable(dssdev);
}
-static int omap_encoder_update(struct drm_encoder *encoder,
- enum omap_channel channel,
-
[PATCH 20/23] drm/omap: sdi: Fixup video mode in .check_timings() operation
The SDI encoder modifies the pixel clock of the requested video mode to
take the limitations of the PLL into account in the .enable() operation.
This should be performed in the .check_timings() operation instead. Move
the fixup.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/sdi.c | 37 ++---
1 file changed, 22 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/sdi.c
b/drivers/gpu/drm/omapdrm/dss/sdi.c
index 3e464b015884..9dd686ae63c1 100644
--- a/drivers/gpu/drm/omapdrm/dss/sdi.c
+++ b/drivers/gpu/drm/omapdrm/dss/sdi.c
@@ -129,10 +129,8 @@ static void sdi_config_lcd_manager(struct sdi_device *sdi)
static int sdi_display_enable(struct omap_dss_device *dssdev)
{
struct sdi_device *sdi = dssdev_to_sdi(dssdev);
- struct videomode *vm = >vm;
- unsigned long fck;
struct dispc_clock_info dispc_cinfo;
- unsigned long pck;
+ unsigned long fck;
int r;
if (!sdi->output.dispc_channel_connected) {
@@ -148,23 +146,13 @@ static int sdi_display_enable(struct omap_dss_device
*dssdev)
if (r)
goto err_get_dispc;
- r = sdi_calc_clock_div(sdi, vm->pixelclock, , _cinfo);
+ r = sdi_calc_clock_div(sdi, sdi->vm.pixelclock, , _cinfo);
if (r)
goto err_calc_clock_div;
sdi->mgr_config.clock_info = dispc_cinfo;
- pck = fck / dispc_cinfo.lck_div / dispc_cinfo.pck_div;
-
- if (pck != vm->pixelclock) {
- DSSWARN("Could not find exact pixel clock. Requested %lu Hz,
got %lu Hz\n",
- vm->pixelclock, pck);
-
- vm->pixelclock = pck;
- }
-
-
- dss_mgr_set_timings(>output, vm);
+ dss_mgr_set_timings(>output, >vm);
r = dss_set_fck_rate(sdi->dss, fck);
if (r)
@@ -234,9 +222,28 @@ static void sdi_set_timings(struct omap_dss_device *dssdev,
static int sdi_check_timings(struct omap_dss_device *dssdev,
struct videomode *vm)
{
+ struct sdi_device *sdi = dssdev_to_sdi(dssdev);
+ struct dispc_clock_info dispc_cinfo;
+ unsigned long fck;
+ unsigned long pck;
+ int r;
+
if (vm->pixelclock == 0)
return -EINVAL;
+ r = sdi_calc_clock_div(sdi, vm->pixelclock, , _cinfo);
+ if (r)
+ return r;
+
+ pck = fck / dispc_cinfo.lck_div / dispc_cinfo.pck_div;
+
+ if (pck != vm->pixelclock) {
+ DSSWARN("Pixel clock adjusted from %lu Hz to %lu Hz\n",
+ vm->pixelclock, pck);
+
+ vm->pixelclock = pck;
+ }
+
return 0;
}
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 17/23] drm/omap: dpi: Don't fixup video mode in dpi_set_mode()
The video mode is aleady fixed up by the .check_timings() operation,
there's no need to repeat that when enabling the DPI output.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/dpi.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c
b/drivers/gpu/drm/omapdrm/dss/dpi.c
index 1fb864c294e8..e6628ba267de 100644
--- a/drivers/gpu/drm/omapdrm/dss/dpi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
@@ -347,10 +347,9 @@ static int dpi_set_dispc_clk(struct dpi_data *dpi,
unsigned long pck_req,
static int dpi_set_mode(struct dpi_data *dpi)
{
- struct videomode *vm = >vm;
+ const struct videomode *vm = >vm;
int lck_div = 0, pck_div = 0;
unsigned long fck = 0;
- unsigned long pck;
int r = 0;
if (dpi->pll)
@@ -362,15 +361,6 @@ static int dpi_set_mode(struct dpi_data *dpi)
if (r)
return r;
- pck = fck / lck_div / pck_div;
-
- if (pck != vm->pixelclock) {
- DSSWARN("Could not find exact pixel clock. Requested %lu Hz,
got %lu Hz\n",
- vm->pixelclock, pck);
-
- vm->pixelclock = pck;
- }
-
dss_mgr_set_timings(>output, vm);
return 0;
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 13/23] drm/omap: panels: Don't modify fixed timings
Panels drivers store their timings in a device data structure field that
is initialized at probe time, either from hardcoded values or from
firmware-supplied values. Those timings are then reported through the
.get_timings() operation to construct the panel display mode.
The panel timings are further modified by the .set_timings() operation,
which is called with the timings retrieved by .get_timings(), and
mangled by .check_timings(). The latter potentially adjusts the pixel
clock only.
Conceptually, modifying the panel timings is wrong, as the timings are
an intrinsic property of the panel and should thus be fixed.
Furthermore, modifying them this way at runtime can result in display
modes reported to userspace varying between calls, which is also wrong.
There's no actual need to store the mangled pixel clock value in the
timings. Don't modify the panel timings in the .set_timings() operation,
just forward it to the previous device in the display pipeline.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/displays/panel-dpi.c| 3 ---
drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c | 3 ---
drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c | 3 ---
drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c | 3 ---
drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c | 3 ---
drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c | 3 ---
drivers/gpu/drm/omapdrm/displays/panel-tpo-td043mtea1.c | 3 ---
7 files changed, 21 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
index e75600a33c37..95cdfde174aa 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
@@ -96,11 +96,8 @@ static void panel_dpi_disable(struct omap_dss_device *dssdev)
static void panel_dpi_set_timings(struct omap_dss_device *dssdev,
const struct videomode *vm)
{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *src = dssdev->src;
- ddata->vm = *vm;
-
src->ops->set_timings(src, vm);
}
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
index 3c221f7f0598..4e21de0e010d 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
@@ -166,11 +166,8 @@ static void lb035q02_disable(struct omap_dss_device
*dssdev)
static void lb035q02_set_timings(struct omap_dss_device *dssdev,
const struct videomode *vm)
{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *src = dssdev->src;
- ddata->vm = *vm;
-
src->ops->set_timings(src, vm);
}
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
b/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
index 78ff18c4eb46..f6fc7b8e639b 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
@@ -159,11 +159,8 @@ static void nec_8048_disable(struct omap_dss_device
*dssdev)
static void nec_8048_set_timings(struct omap_dss_device *dssdev,
const struct videomode *vm)
{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *src = dssdev->src;
- ddata->vm = *vm;
-
src->ops->set_timings(src, vm);
}
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
b/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
index 47e97dbffc07..51ca92c82e2a 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
@@ -129,11 +129,8 @@ static void sharp_ls_disable(struct omap_dss_device
*dssdev)
static void sharp_ls_set_timings(struct omap_dss_device *dssdev,
const struct videomode *vm)
{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *src = dssdev->src;
- ddata->vm = *vm;
-
src->ops->set_timings(src, vm);
}
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c
b/drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c
index 82317376b229..c8bcf11de4c7 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c
@@ -632,11 +632,8 @@ static void acx565akm_disable(struct omap_dss_device
*dssdev)
static void acx565akm_set_timings(struct omap_dss_device *dssdev,
const struct videomode *vm)
{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *src = dssdev->src;
- ddata->vm = *vm;
-
src->ops->set_timings(src, vm);
}
diff --git
[PATCH 11/23] drm/omap: Query timing information from analog TV encoder
Timings for the TV output are currently reported by the analog TV
connector. This has the disadvantage of having to handle timing-related
operations in a connector omap_dss_device that has, at the hardware
level, no knowledge of any timing information.
Implement the .get_timings() operation in the venc driver, and get
timings from the first component in the pipeline that implements the
operatation. This switches the duty of reporting analog TV timings from
the connector to the encoder.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/venc.c | 12 +++
drivers/gpu/drm/omapdrm/omap_connector.c | 34 +++-
2 files changed, 37 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/venc.c
b/drivers/gpu/drm/omapdrm/dss/venc.c
index f071d2a82f8f..310cf4251788 100644
--- a/drivers/gpu/drm/omapdrm/dss/venc.c
+++ b/drivers/gpu/drm/omapdrm/dss/venc.c
@@ -568,6 +568,16 @@ static void venc_display_disable(struct omap_dss_device
*dssdev)
mutex_unlock(>venc_lock);
}
+static void venc_get_timings(struct omap_dss_device *dssdev,
+struct videomode *vm)
+{
+ struct venc_device *venc = dssdev_to_venc(dssdev);
+
+ mutex_lock(>venc_lock);
+ *vm = venc->vm;
+ mutex_unlock(>venc_lock);
+}
+
static void venc_set_timings(struct omap_dss_device *dssdev,
const struct videomode *vm)
{
@@ -720,6 +730,7 @@ static const struct omap_dss_device_ops venc_ops = {
.disable = venc_display_disable,
.check_timings = venc_check_timings,
+ .get_timings = venc_get_timings,
.set_timings = venc_set_timings,
};
@@ -877,6 +888,7 @@ static int venc_probe(struct platform_device *pdev)
mutex_init(>venc_lock);
venc->wss_data = 0;
+ venc->vm = omap_dss_pal_vm;
venc_mem = platform_get_resource(venc->pdev, IORESOURCE_MEM, 0);
venc->base = devm_ioremap_resource(>dev, venc_mem);
diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c
b/drivers/gpu/drm/omapdrm/omap_connector.c
index f4e75a546393..c8101bb37d05 100644
--- a/drivers/gpu/drm/omapdrm/omap_connector.c
+++ b/drivers/gpu/drm/omapdrm/omap_connector.c
@@ -218,20 +218,41 @@ static int omap_connector_get_modes(struct drm_connector
*connector)
/*
* If display exposes EDID, then we parse that in the normal way to
-* build table of supported modes. Otherwise (ie. fixed resolution
-* LCD panels) we just return a single mode corresponding to the
-* currently configured timings.
+* build table of supported modes.
*/
dssdev = omap_connector_find_device(connector,
OMAP_DSS_DEVICE_OP_EDID);
if (dssdev)
return omap_connector_get_modes_edid(connector, dssdev);
+ /*
+* Otherwise we have either a fixed resolution panel or an output that
+* doesn't support modes discovery (e.g. DVI or VGA with the DDC bus
+* unconnected, or analog TV). Start by querying the size.
+*/
+ dssdev = omap_connector->display;
+ if (dssdev->driver && dssdev->driver->get_size)
+ dssdev->driver->get_size(dssdev,
+>display_info.width_mm,
+>display_info.height_mm);
+
+ /*
+* Iterate over the pipeline to find the first device that can provide
+* timing information. If we can't find any, we just let the KMS core
+* add the default modes.
+*/
+ for (dssdev = omap_connector->display; dssdev; dssdev = dssdev->src) {
+ if (dssdev->ops->get_timings)
+ break;
+ }
+ if (!dssdev)
+ return 0;
+
+ /* Add a single mode corresponding to the fixed panel timings. */
mode = drm_mode_create(connector->dev);
if (!mode)
return 0;
- dssdev = omap_connector->display;
dssdev->ops->get_timings(dssdev, );
drm_display_mode_from_videomode(, mode);
@@ -240,11 +261,6 @@ static int omap_connector_get_modes(struct drm_connector
*connector)
drm_mode_set_name(mode);
drm_mode_probed_add(connector, mode);
- if (dssdev->driver && dssdev->driver->get_size)
- dssdev->driver->get_size(dssdev,
->display_info.width_mm,
->display_info.height_mm);
-
return 1;
}
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 18/23] drm/omap: dsi: Fixup video mode in .set_config() operation
The DSI encoder modifies the passed videomode to take the requirements
of the internal DISPC-DSI bus into account in the .enable_video_output()
operation. This should be performed in the .check_timings() operation
instead. There is however no .check_timings() operation as the DSI
encoder uses a custom API, so move it to the closest match which is the
.set_config() operation.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/dsi.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
b/drivers/gpu/drm/omapdrm/dss/dsi.c
index cc1f8a8b2a00..3a954f7237d7 100644
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -3265,7 +3265,7 @@ static void dsi_config_vp_num_line_buffers(struct
dsi_data *dsi)
if (dsi->mode == OMAP_DSS_DSI_VIDEO_MODE) {
int bpp = dsi_get_pixel_size(dsi->pix_fmt);
- struct videomode *vm = >vm;
+ const struct videomode *vm = >vm;
/*
* Don't use line buffers if width is greater than the video
* port's line buffer size
@@ -3394,7 +3394,7 @@ static void dsi_config_cmd_mode_interleaving(struct
dsi_data *dsi)
int ddr_clk_pre, ddr_clk_post, enter_hs_mode_lat, exit_hs_mode_lat;
int tclk_trail, ths_exit, exiths_clk;
bool ddr_alwon;
- struct videomode *vm = >vm;
+ const struct videomode *vm = >vm;
int bpp = dsi_get_pixel_size(dsi->pix_fmt);
int ndl = dsi->num_lanes_used - 1;
int dsi_fclk_hsdiv = dsi->user_dsi_cinfo.mX[HSDIV_DSI] + 1;
@@ -3644,7 +3644,7 @@ static void dsi_proto_timings(struct dsi_data *dsi)
int vbp = dsi->vm_timings.vbp;
int window_sync = dsi->vm_timings.window_sync;
bool hsync_end;
- struct videomode *vm = >vm;
+ const struct videomode *vm = >vm;
int bpp = dsi_get_pixel_size(dsi->pix_fmt);
int tl, t_he, width_bytes;
@@ -4044,16 +4044,6 @@ static int dsi_display_init_dispc(struct dsi_data *dsi)
dsi->mgr_config.fifohandcheck = false;
}
- /*
-* override interlace, logic level and edge related parameters in
-* videomode with default values
-*/
- dsi->vm.flags &= ~DISPLAY_FLAGS_INTERLACED;
- dsi->vm.flags &= ~DISPLAY_FLAGS_HSYNC_LOW;
- dsi->vm.flags |= DISPLAY_FLAGS_HSYNC_HIGH;
- dsi->vm.flags &= ~DISPLAY_FLAGS_VSYNC_LOW;
- dsi->vm.flags |= DISPLAY_FLAGS_VSYNC_HIGH;
-
dss_mgr_set_timings(>output, >vm);
r = dsi_configure_dispc_clocks(dsi);
@@ -4755,6 +4745,17 @@ static int dsi_set_config(struct omap_dss_device *dssdev,
dsi->user_dispc_cinfo = ctx.dispc_cinfo;
dsi->vm = ctx.vm;
+
+ /*
+* override interlace, logic level and edge related parameters in
+* videomode with default values
+*/
+ dsi->vm.flags &= ~DISPLAY_FLAGS_INTERLACED;
+ dsi->vm.flags &= ~DISPLAY_FLAGS_HSYNC_LOW;
+ dsi->vm.flags |= DISPLAY_FLAGS_HSYNC_HIGH;
+ dsi->vm.flags &= ~DISPLAY_FLAGS_VSYNC_LOW;
+ dsi->vm.flags |= DISPLAY_FLAGS_VSYNC_HIGH;
+
dsi->vm_timings = ctx.dsi_vm;
mutex_unlock(>lock);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 12/23] drm/omap: Remove .get_timings() operation from display connectors
The analog TV, DVI and HDMI connectors all report timing information
through the .get_timings() information.
For analog TV outputs the information is queried from the encoder, so
the operation is unused. Remove it.
For HDMI outputs the display pipeline provides EDID capability, so the
operation is unused as well. Remove it.
For DVI outputs the operation is also unused if the pipeline provides
EDID capability. Otherwise (when the DDC bus is not connected) we
shouldn't hardcode a single mode, but instead report no mode and let the
KMS core add default modes. This is achieved by removing the operation.
Signed-off-by: Laurent Pinchart
---
.../gpu/drm/omapdrm/displays/connector-analog-tv.c | 31
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 33 --
drivers/gpu/drm/omapdrm/displays/connector-hdmi.c | 30
3 files changed, 94 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
index a9e2a366a851..4866bf8ed524 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
@@ -20,23 +20,6 @@ struct panel_drv_data {
struct omap_dss_device dssdev;
struct device *dev;
-
- struct videomode vm;
-};
-
-static const struct videomode tvc_pal_vm = {
- .hactive= 720,
- .vactive= 574,
- .pixelclock = 1350,
- .hsync_len = 64,
- .hfront_porch = 12,
- .hback_porch= 68,
- .vsync_len = 5,
- .vfront_porch = 5,
- .vback_porch= 41,
-
- .flags = DISPLAY_FLAGS_INTERLACED | DISPLAY_FLAGS_HSYNC_LOW |
- DISPLAY_FLAGS_VSYNC_LOW,
};
#define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
@@ -93,22 +76,11 @@ static void tvc_disable(struct omap_dss_device *dssdev)
static void tvc_set_timings(struct omap_dss_device *dssdev,
const struct videomode *vm)
{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *src = dssdev->src;
- ddata->vm = *vm;
-
src->ops->set_timings(src, vm);
}
-static void tvc_get_timings(struct omap_dss_device *dssdev,
- struct videomode *vm)
-{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
-
- *vm = ddata->vm;
-}
-
static const struct omap_dss_device_ops tvc_ops = {
.connect= tvc_connect,
.disconnect = tvc_disconnect,
@@ -117,7 +89,6 @@ static const struct omap_dss_device_ops tvc_ops = {
.disable= tvc_disable,
.set_timings= tvc_set_timings,
- .get_timings= tvc_get_timings,
};
static int tvc_probe(struct platform_device *pdev)
@@ -132,8 +103,6 @@ static int tvc_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ddata);
ddata->dev = >dev;
- ddata->vm = tvc_pal_vm;
-
dssdev = >dssdev;
dssdev->ops = _ops;
dssdev->dev = >dev;
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
index a9e2f1181987..818a4dc452e0 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
@@ -19,28 +19,9 @@
#include "../dss/omapdss.h"
-static const struct videomode dvic_default_vm = {
- .hactive= 640,
- .vactive= 480,
-
- .pixelclock = 2350,
-
- .hfront_porch = 48,
- .hsync_len = 32,
- .hback_porch= 80,
-
- .vfront_porch = 3,
- .vsync_len = 4,
- .vback_porch= 7,
-
- .flags = DISPLAY_FLAGS_HSYNC_HIGH | DISPLAY_FLAGS_VSYNC_HIGH,
-};
-
struct panel_drv_data {
struct omap_dss_device dssdev;
- struct videomode vm;
-
struct i2c_adapter *i2c_adapter;
struct gpio_desc *hpd_gpio;
@@ -100,22 +81,11 @@ static void dvic_disable(struct omap_dss_device *dssdev)
static void dvic_set_timings(struct omap_dss_device *dssdev,
const struct videomode *vm)
{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *src = dssdev->src;
- ddata->vm = *vm;
-
src->ops->set_timings(src, vm);
}
-static void dvic_get_timings(struct omap_dss_device *dssdev,
-struct videomode *vm)
-{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
-
- *vm = ddata->vm;
-}
-
static int dvic_ddc_read(struct i2c_adapter *adapter,
unsigned char *buf, u16 count, u8 offset)
{
@@ -223,7 +193,6 @@ static const struct omap_dss_device_ops dvic_ops = {
.disable= dvic_disable,
.set_timings= dvic_set_timings,
- .get_timings= dvic_get_timings,
[PATCH 10/23] drm/omap: Don't call .check_timings() operation recursively
The .check_timings() operation is called recursively from the display
device back to the output device. Most components just forward the
operation to the previous component in the chain, resulting in lots of
duplicated pass-through functions. To avoid that, iterate over the
components manually.
Signed-off-by: Laurent Pinchart
---
.../gpu/drm/omapdrm/displays/connector-analog-tv.c | 9 --
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 9 --
drivers/gpu/drm/omapdrm/displays/connector-hdmi.c | 9 --
drivers/gpu/drm/omapdrm/displays/encoder-opa362.c | 11
drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c | 9 --
.../gpu/drm/omapdrm/displays/encoder-tpd12s015.c | 9 --
drivers/gpu/drm/omapdrm/displays/panel-dpi.c | 9 --
.../omapdrm/displays/panel-lgphilips-lb035q02.c| 9 --
.../drm/omapdrm/displays/panel-nec-nl8048hl11.c| 9 --
.../drm/omapdrm/displays/panel-sharp-ls037v7dw01.c | 9 --
.../drm/omapdrm/displays/panel-sony-acx565akm.c| 9 --
.../drm/omapdrm/displays/panel-tpo-td028ttec1.c| 9 --
.../drm/omapdrm/displays/panel-tpo-td043mtea1.c| 9 --
drivers/gpu/drm/omapdrm/omap_connector.c | 32 +-
drivers/gpu/drm/omapdrm/omap_encoder.c | 20 +-
15 files changed, 32 insertions(+), 139 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
index fb6d4fce1853..a9e2a366a851 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
@@ -109,14 +109,6 @@ static void tvc_get_timings(struct omap_dss_device *dssdev,
*vm = ddata->vm;
}
-static int tvc_check_timings(struct omap_dss_device *dssdev,
-struct videomode *vm)
-{
- struct omap_dss_device *src = dssdev->src;
-
- return src->ops->check_timings(src, vm);
-}
-
static const struct omap_dss_device_ops tvc_ops = {
.connect= tvc_connect,
.disconnect = tvc_disconnect,
@@ -126,7 +118,6 @@ static const struct omap_dss_device_ops tvc_ops = {
.set_timings= tvc_set_timings,
.get_timings= tvc_get_timings,
- .check_timings = tvc_check_timings,
};
static int tvc_probe(struct platform_device *pdev)
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
index 5871872ae19b..a9e2f1181987 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
@@ -116,14 +116,6 @@ static void dvic_get_timings(struct omap_dss_device
*dssdev,
*vm = ddata->vm;
}
-static int dvic_check_timings(struct omap_dss_device *dssdev,
- struct videomode *vm)
-{
- struct omap_dss_device *src = dssdev->src;
-
- return src->ops->check_timings(src, vm);
-}
-
static int dvic_ddc_read(struct i2c_adapter *adapter,
unsigned char *buf, u16 count, u8 offset)
{
@@ -232,7 +224,6 @@ static const struct omap_dss_device_ops dvic_ops = {
.set_timings= dvic_set_timings,
.get_timings= dvic_get_timings,
- .check_timings = dvic_check_timings,
.read_edid = dvic_read_edid,
.detect = dvic_detect,
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
index 898eb583688f..7e449f8a9b5d 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
@@ -114,14 +114,6 @@ static void hdmic_get_timings(struct omap_dss_device
*dssdev,
*vm = ddata->vm;
}
-static int hdmic_check_timings(struct omap_dss_device *dssdev,
- struct videomode *vm)
-{
- struct omap_dss_device *src = dssdev->src;
-
- return src->ops->check_timings(src, vm);
-}
-
static bool hdmic_detect(struct omap_dss_device *dssdev)
{
struct panel_drv_data *ddata = to_panel_data(dssdev);
@@ -161,7 +153,6 @@ static const struct omap_dss_device_ops hdmic_ops = {
.set_timings= hdmic_set_timings,
.get_timings= hdmic_get_timings,
- .check_timings = hdmic_check_timings,
.detect = hdmic_detect,
.register_hpd_cb= hdmic_register_hpd_cb,
diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c
b/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c
index db5763782199..0604169d8951 100644
--- a/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c
+++ b/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c
@@ -95,22 +95,11 @@ static void opa362_set_timings(struct omap_dss_device
*dssdev,
src->ops->set_timings(src, vm);
}
-static int opa362_check_timings(struct omap_dss_device *dssdev,
-
[PATCH 08/23] drm: Add display info bus flags to specify sync signals clock edges
The drm_display_info structure contains bus flags that specify on which
pixel clock edge the data are driven and sampled. Add a set of flags to
specify the pixel clock edge for sync signals, as they can be driven and
sampled on the opposite clock edge of the data signals.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_modes.c | 10 --
include/drm/drm_connector.h | 4
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index c78ca0e84ffd..2daa19e0b4c1 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -661,8 +661,9 @@ EXPORT_SYMBOL_GPL(drm_display_mode_to_videomode);
* @vm: videomode structure to use
* @bus_flags: information about pixelclk and DE polarity will be stored here
*
- * Sets DRM_BUS_FLAG_DE_(LOW|HIGH) and DRM_BUS_FLAG_PIXDATA_(POS|NEG)EDGE
- * in @bus_flags according to DISPLAY_FLAGS found in @vm
+ * Sets DRM_BUS_FLAG_DE_(LOW|HIGH), DRM_BUS_FLAG_PIXDATA_(POS|NEG)EDGE and
+ * DRM_BUS_FLAG_SYNC_(POS|NEG)EDGE in @bus_flags according to DISPLAY_FLAGS
+ * found in @vm
*/
void drm_bus_flags_from_videomode(const struct videomode *vm, u32 *bus_flags)
{
@@ -676,6 +677,11 @@ void drm_bus_flags_from_videomode(const struct videomode
*vm, u32 *bus_flags)
*bus_flags |= DRM_BUS_FLAG_DE_LOW;
if (vm->flags & DISPLAY_FLAGS_DE_HIGH)
*bus_flags |= DRM_BUS_FLAG_DE_HIGH;
+
+ if (vm->flags & DISPLAY_FLAGS_SYNC_POSEDGE)
+ *bus_flags |= DRM_BUS_FLAG_SYNC_POSEDGE;
+ if (vm->flags & DISPLAY_FLAGS_SYNC_NEGEDGE)
+ *bus_flags |= DRM_BUS_FLAG_SYNC_NEGEDGE;
}
EXPORT_SYMBOL_GPL(drm_bus_flags_from_videomode);
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 675cc3f8cf85..ad8f87c77390 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -290,6 +290,10 @@ struct drm_display_info {
#define DRM_BUS_FLAG_DATA_MSB_TO_LSB (1<<4)
/* data is transmitted LSB to MSB on the bus */
#define DRM_BUS_FLAG_DATA_LSB_TO_MSB (1<<5)
+/* drive [hv]sync on pos. edge */
+#define DRM_BUS_FLAG_SYNC_POSEDGE (1<<6)
+/* drive [hv]sync on neg. edge */
+#define DRM_BUS_FLAG_SYNC_NEGEDGE (1<<7)
/**
* @bus_flags: Additional information (like pixel signal polarity) for
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/23] drm/omap: Store bus flags in the omap_dss_device structure
Source components in the display pipeline need to configure their output
signals polarities and clock driving edge based on the requirements of
the sink component.
Those requirements are currently shared across the whole pipeline in the
flags of a videomode structure, instead of being local to each bus. This
both prevents multiple buses from having different configurations (when
the hardware supports it), and makes it difficult to move from videomode
to drm_display_mode as the latter doesn't contain bus polarities and
clock edge flags.
Add a bus_flags field to the omap_dss_device structure and move the
DISPLAY_FLAGS_DE_(LOW|HIGH), DISPLAY_FLAGS_PIXDATA_(POS|NEG)EDGE and
DISPLAY_FLAGS_SYNC_(POS|NEG)EDGE videomode flags to bus_flags in all
external encoders, connectors and panels. The videomode flags are still
used internally for internal encoders, this will be addressed in a
second step.
The related videomode flags in the default mode of the DVI connector can
simply be dropped, as they are always overridden by the TFP410 driver.
Note that this results in both the DISPLAY_FLAGS_SYNC_POSEDGE and
DISPLAY_FLAGS_SYNC_NEGEDGE flags being set, which is invalid, but only
the former is tested for when programming the DISPC, so the DVI
connector flags are effectively overridden by the TFP410 flags.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 4 +--
drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c | 10 ++
.../omapdrm/displays/panel-lgphilips-lb035q02.c| 17 -
.../drm/omapdrm/displays/panel-nec-nl8048hl11.c| 6 ++--
.../drm/omapdrm/displays/panel-sharp-ls037v7dw01.c | 15
.../drm/omapdrm/displays/panel-sony-acx565akm.c| 6 ++--
.../drm/omapdrm/displays/panel-tpo-td028ttec1.c| 15
.../drm/omapdrm/displays/panel-tpo-td043mtea1.c| 15
drivers/gpu/drm/omapdrm/dss/dsi.c | 9 ++---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 1 +
drivers/gpu/drm/omapdrm/dss/sdi.c | 5 ++-
drivers/gpu/drm/omapdrm/omap_crtc.c| 42 --
12 files changed, 79 insertions(+), 66 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
index b89555ed53a0..5871872ae19b 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
@@ -33,9 +33,7 @@ static const struct videomode dvic_default_vm = {
.vsync_len = 4,
.vback_porch= 7,
- .flags = DISPLAY_FLAGS_HSYNC_HIGH | DISPLAY_FLAGS_VSYNC_HIGH |
- DISPLAY_FLAGS_SYNC_NEGEDGE | DISPLAY_FLAGS_DE_HIGH |
- DISPLAY_FLAGS_PIXDATA_POSEDGE,
+ .flags = DISPLAY_FLAGS_HSYNC_HIGH | DISPLAY_FLAGS_VSYNC_HIGH,
};
struct panel_drv_data {
diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
b/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
index 4df990afb734..1317080ec5e6 100644
--- a/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
+++ b/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
@@ -76,12 +76,6 @@ static void tfp410_disable(struct omap_dss_device *dssdev)
dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
}
-static void tfp410_fix_timings(struct videomode *vm)
-{
- vm->flags |= DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE |
-DISPLAY_FLAGS_SYNC_POSEDGE;
-}
-
static void tfp410_set_timings(struct omap_dss_device *dssdev,
const struct videomode *vm)
{
@@ -95,8 +89,6 @@ static int tfp410_check_timings(struct omap_dss_device
*dssdev,
{
struct omap_dss_device *src = dssdev->src;
- tfp410_fix_timings(vm);
-
return src->ops->check_timings(src, vm);
}
@@ -137,6 +129,8 @@ static int tfp410_probe(struct platform_device *pdev)
dssdev->output_type = OMAP_DISPLAY_TYPE_DVI;
dssdev->owner = THIS_MODULE;
dssdev->of_ports = BIT(1) | BIT(0);
+ dssdev->bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_SYNC_POSEDGE
+ | DRM_BUS_FLAG_PIXDATA_POSEDGE;
dssdev->next = omapdss_of_find_connected_device(pdev->dev.of_node, 1);
if (IS_ERR(dssdev->next)) {
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
index ffa69fd44d87..a211506506c0 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
@@ -33,14 +33,7 @@ static const struct videomode lb035q02_vm = {
.vfront_porch = 4,
.vback_porch= 18,
- .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
- DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_SYNC_NEGEDGE |
- DISPLAY_FLAGS_PIXDATA_POSEDGE,
- /*
-* Note: According to the
[PATCH 07/23] drm/omap: Don't store video mode internally for external encoders
The omap_dss_device .set_timings() operation for external encoders
stores the video mode in the device data structure. That mode is then
never used again. Drop it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/displays/encoder-opa362.c| 5 -
drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c| 5 -
drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c | 5 -
3 files changed, 15 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c
b/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c
index a0e54634beeb..db5763782199 100644
--- a/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c
+++ b/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c
@@ -25,8 +25,6 @@ struct panel_drv_data {
struct omap_dss_device dssdev;
struct gpio_desc *enable_gpio;
-
- struct videomode vm;
};
#define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
@@ -90,13 +88,10 @@ static void opa362_disable(struct omap_dss_device *dssdev)
static void opa362_set_timings(struct omap_dss_device *dssdev,
const struct videomode *vm)
{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *src = dssdev->src;
dev_dbg(dssdev->dev, "set_timings\n");
- ddata->vm = *vm;
-
src->ops->set_timings(src, vm);
}
diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
b/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
index bcbd1a65b55c..4df990afb734 100644
--- a/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
+++ b/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
@@ -20,8 +20,6 @@ struct panel_drv_data {
struct omap_dss_device dssdev;
struct gpio_desc *pd_gpio;
-
- struct videomode vm;
};
#define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
@@ -87,11 +85,8 @@ static void tfp410_fix_timings(struct videomode *vm)
static void tfp410_set_timings(struct omap_dss_device *dssdev,
const struct videomode *vm)
{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *src = dssdev->src;
- ddata->vm = *vm;
-
src->ops->set_timings(src, vm);
}
diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
index 131adfaad4d5..9c4eef73e4a0 100644
--- a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
+++ b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
@@ -28,8 +28,6 @@ struct panel_drv_data {
struct gpio_desc *ct_cp_hpd_gpio;
struct gpio_desc *ls_oe_gpio;
struct gpio_desc *hpd_gpio;
-
- struct videomode vm;
};
#define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
@@ -96,11 +94,8 @@ static void tpd_disable(struct omap_dss_device *dssdev)
static void tpd_set_timings(struct omap_dss_device *dssdev,
const struct videomode *vm)
{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *src = dssdev->src;
- ddata->vm = *vm;
-
src->ops->set_timings(src, vm);
}
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/23] omapdrm: Rework the timing-related operations
Hello, This patch series reworks all the timing-related operations (.get_timings(), .set_timings() and .check_timings()) as a step toward moving from omap_dss_device to drm_bridge. All timing-related operations are called by the omapdrm driver on the omap_dss_device at the end of display pipeline, and the operations are then handled directly or forwarded to the previous omap_dss_device in the pipeline. This causes an issue in our quest to move to drm_bridge: the drm_bridge equivalent to the timing operations, .mode_valid(), .mode_fixup() and .mode_set(), are called in the source to sink direction. Furthermore, timing handling in the omapdrm driver is very complicated, with timings getting mangled, stored in random places, retrieved back by unrelated code, mangled again, stored in different places, and modified across objects. Simplifying that is crucial to move to drm_bridge. This patch series simplifies the timings operation and reverse the direction in which they're called. The driver still uses the videomode structure instead of the drm_display_mode structure to store timing information, this will be fixed in a second step. The series is really a succession of cleanups interleaved with the real changes, with a total of 406 lines of code removed overall. It starts with small changes, cleanups and code removal in patches 01/23 to 07/23, and then introduces new DRM bus flags to specify sync signal clock edges using the DRM bus_flags mechanism in patch 08/23. This is the only extension to the DRM core. Patches 09/23 and 10/23 start reworking the .check_timings() operation by making use of the bus flags. Patches 11/23 to 13/23 rework the .get_timings() operation, and patches 14/23 to 21/23 complete the .check_timings() rework. Patches 22/23 and 23/23 finally rework the .set_timings() operation. The series is based on top of the previously submitted "[PATCH 00/21] omapdrm: Rework the HPD-related operations" patch series. For convenience I've pushed it to my tree at git://linuxtv.org/pinchartl/media.git omapdrm/bridge/timings Laurent Pinchart (23): drm/omap: Pass both output and display omap_dss_device to connector init drm/omap: Determine connector type directly in omap_connector.c drm/omap: dss: hdmi: Rename hdmi_display_(set|check)_timing() functions drm/omap: Make the video_mode pointer to .set_timings() const drm/omap: Remove duplicate calls to .set_timings() operation drm/omap: Remove unneeded fallback for missing .check_timings() drm/omap: Don't store video mode internally for external encoders drm: Add display info bus flags to specify sync signals clock edges drm/omap: Store bus flags in the omap_dss_device structure drm/omap: Don't call .check_timings() operation recursively drm/omap: Query timing information from analog TV encoder drm/omap: Remove .get_timings() operation from display connectors drm/omap: panels: Don't modify fixed timings drm/omap: Move bus flag hack to encoder implementation drm/omap: Split mode fixup and mode set from encoder enable drm/omap: Call dispc timings check operation directly drm/omap: dpi: Don't fixup video mode in dpi_set_mode() drm/omap: dsi: Fixup video mode in .set_config() operation drm/omap: hdmi: Constify video mode and related pointers drm/omap: sdi: Fixup video mode in .check_timings() operation drm/omap: venc: Fixup video mode in .check_timings() operation drm/omap: Store CRTC timings in .set_timings() operation drm/omap: Don't call .set_timings() operation recursively drivers/gpu/drm/drm_modes.c| 10 +- .../gpu/drm/omapdrm/displays/connector-analog-tv.c | 52 drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 57 - drivers/gpu/drm/omapdrm/displays/connector-hdmi.c | 51 drivers/gpu/drm/omapdrm/displays/encoder-opa362.c | 29 - drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c | 37 +- .../gpu/drm/omapdrm/displays/encoder-tpd12s015.c | 26 drivers/gpu/drm/omapdrm/displays/panel-dpi.c | 23 .../omapdrm/displays/panel-lgphilips-lb035q02.c| 40 ++ .../drm/omapdrm/displays/panel-nec-nl8048hl11.c| 29 + .../drm/omapdrm/displays/panel-sharp-ls037v7dw01.c | 38 ++ .../drm/omapdrm/displays/panel-sony-acx565akm.c| 29 + .../drm/omapdrm/displays/panel-tpo-td028ttec1.c| 38 ++ .../drm/omapdrm/displays/panel-tpo-td043mtea1.c| 38 ++ drivers/gpu/drm/omapdrm/dss/dispc.c| 18 +-- drivers/gpu/drm/omapdrm/dss/dpi.c | 20 +-- drivers/gpu/drm/omapdrm/dss/dsi.c | 42 +++ drivers/gpu/drm/omapdrm/dss/dss.h | 3 - drivers/gpu/drm/omapdrm/dss/hdmi.h | 8 +- drivers/gpu/drm/omapdrm/dss/hdmi4.c| 23 +--- drivers/gpu/drm/omapdrm/dss/hdmi5.c| 23 +--- drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 6 +- drivers/gpu/drm/omapdrm/dss/hdmi_wp.c
[PATCH 04/23] drm/omap: Make the video_mode pointer to .set_timings() const
The .set_timings() operations of the omap_dss_device instances don't
need to modify the passed timings. Make the pointer const.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c | 2 +-
drivers/gpu/drm/omapdrm/displays/connector-dvi.c| 2 +-
drivers/gpu/drm/omapdrm/displays/connector-hdmi.c | 2 +-
drivers/gpu/drm/omapdrm/displays/encoder-opa362.c | 2 +-
drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c | 2 +-
drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c| 2 +-
drivers/gpu/drm/omapdrm/displays/panel-dpi.c| 2 +-
drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c | 2 +-
drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c | 2 +-
drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c | 2 +-
drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c | 2 +-
drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c | 2 +-
drivers/gpu/drm/omapdrm/displays/panel-tpo-td043mtea1.c | 2 +-
drivers/gpu/drm/omapdrm/dss/dpi.c | 2 +-
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 2 +-
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 2 +-
drivers/gpu/drm/omapdrm/dss/omapdss.h | 2 +-
drivers/gpu/drm/omapdrm/dss/sdi.c | 2 +-
drivers/gpu/drm/omapdrm/dss/venc.c | 2 +-
19 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
index 563fc7e618b3..22bc2e734b0b 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
@@ -93,7 +93,7 @@ static void tvc_disable(struct omap_dss_device *dssdev)
}
static void tvc_set_timings(struct omap_dss_device *dssdev,
- struct videomode *vm)
+ const struct videomode *vm)
{
struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *src = dssdev->src;
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
index eae4108330f1..8f953303ece6 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
@@ -103,7 +103,7 @@ static void dvic_disable(struct omap_dss_device *dssdev)
}
static void dvic_set_timings(struct omap_dss_device *dssdev,
-struct videomode *vm)
+const struct videomode *vm)
{
struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *src = dssdev->src;
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
index fe6d2923ed81..1cbc593c79ff 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
@@ -98,7 +98,7 @@ static void hdmic_disable(struct omap_dss_device *dssdev)
}
static void hdmic_set_timings(struct omap_dss_device *dssdev,
- struct videomode *vm)
+ const struct videomode *vm)
{
struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *src = dssdev->src;
diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c
b/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c
index 176b3238e286..5a406ffcc836 100644
--- a/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c
+++ b/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c
@@ -90,7 +90,7 @@ static void opa362_disable(struct omap_dss_device *dssdev)
}
static void opa362_set_timings(struct omap_dss_device *dssdev,
- struct videomode *vm)
+ const struct videomode *vm)
{
struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *src = dssdev->src;
diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
b/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
index 517ca40c741e..7df138094321 100644
--- a/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
+++ b/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
@@ -87,7 +87,7 @@ static void tfp410_fix_timings(struct videomode *vm)
}
static void tfp410_set_timings(struct omap_dss_device *dssdev,
- struct videomode *vm)
+ const struct videomode *vm)
{
struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *src = dssdev->src;
diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
index 3ad60f4b331e..759d95faa4b4 100644
--- a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
+++ b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
@@ -97,7
[PATCH 03/23] drm/omap: dss: hdmi: Rename hdmi_display_(set|check)_timing() functions
The two functions implement the .set_timings() and .check_timings()
operations. Rename them to hdmi_disply_set_timings() and
hdmi_display_check_timings() respectively to match the operations names
and make searching the source code easier.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c | 2 --
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 12 ++--
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 12 ++--
3 files changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
b/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
index b91e45c0bfdd..517ca40c741e 100644
--- a/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
+++ b/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
@@ -92,8 +92,6 @@ static void tfp410_set_timings(struct omap_dss_device *dssdev,
struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *src = dssdev->src;
- tfp410_fix_timings(vm);
-
ddata->vm = *vm;
src->ops->set_timings(src, vm);
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
index c92564300446..73ca79471ce4 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
@@ -251,8 +251,8 @@ static void hdmi_power_off_full(struct omap_hdmi *hdmi)
hdmi_power_off_core(hdmi);
}
-static int hdmi_display_check_timing(struct omap_dss_device *dssdev,
-struct videomode *vm)
+static int hdmi_display_check_timings(struct omap_dss_device *dssdev,
+ struct videomode *vm)
{
struct omap_hdmi *hdmi = dssdev_to_hdmi(dssdev);
@@ -262,8 +262,8 @@ static int hdmi_display_check_timing(struct omap_dss_device
*dssdev,
return 0;
}
-static void hdmi_display_set_timing(struct omap_dss_device *dssdev,
- struct videomode *vm)
+static void hdmi_display_set_timings(struct omap_dss_device *dssdev,
+struct videomode *vm)
{
struct omap_hdmi *hdmi = dssdev_to_hdmi(dssdev);
@@ -508,8 +508,8 @@ static const struct omap_dss_device_ops hdmi_ops = {
.enable = hdmi_display_enable,
.disable= hdmi_display_disable,
- .check_timings = hdmi_display_check_timing,
- .set_timings= hdmi_display_set_timing,
+ .check_timings = hdmi_display_check_timings,
+ .set_timings= hdmi_display_set_timings,
.read_edid = hdmi_read_edid,
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
index 2aaa8ee61662..259cd39d0c1d 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
@@ -250,8 +250,8 @@ static void hdmi_power_off_full(struct omap_hdmi *hdmi)
hdmi_power_off_core(hdmi);
}
-static int hdmi_display_check_timing(struct omap_dss_device *dssdev,
-struct videomode *vm)
+static int hdmi_display_check_timings(struct omap_dss_device *dssdev,
+ struct videomode *vm)
{
struct omap_hdmi *hdmi = dssdev_to_hdmi(dssdev);
@@ -261,8 +261,8 @@ static int hdmi_display_check_timing(struct omap_dss_device
*dssdev,
return 0;
}
-static void hdmi_display_set_timing(struct omap_dss_device *dssdev,
- struct videomode *vm)
+static void hdmi_display_set_timings(struct omap_dss_device *dssdev,
+struct videomode *vm)
{
struct omap_hdmi *hdmi = dssdev_to_hdmi(dssdev);
@@ -502,8 +502,8 @@ static const struct omap_dss_device_ops hdmi_ops = {
.enable = hdmi_display_enable,
.disable= hdmi_display_disable,
- .check_timings = hdmi_display_check_timing,
- .set_timings= hdmi_display_set_timing,
+ .check_timings = hdmi_display_check_timings,
+ .set_timings= hdmi_display_set_timings,
.read_edid = hdmi_read_edid,
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/23] drm/omap: Remove unneeded fallback for missing .check_timings()
The .check_timings() operation is present in all panels and connectors.
The fallback that uses .get_timings() in the absence of .check_timings()
is thus unneeded.
While it could be argued that the fallback implements a useful check
that should be extended to cover all fixed-resolution panels, the code
is currently unused and gets in the way of the ongoing refactoring.
Remove it, a similar feature can always be added later.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_connector.c | 25 +
drivers/gpu/drm/omapdrm/omap_encoder.c | 16 ++--
2 files changed, 3 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c
b/drivers/gpu/drm/omapdrm/omap_connector.c
index e5ea027357c6..4b155a500a5d 100644
--- a/drivers/gpu/drm/omapdrm/omap_connector.c
+++ b/drivers/gpu/drm/omapdrm/omap_connector.c
@@ -262,30 +262,7 @@ static int omap_connector_mode_valid(struct drm_connector
*connector,
drm_display_mode_to_videomode(mode, );
vrefresh = drm_mode_vrefresh(mode);
- /*
-* if the panel driver doesn't have a check_timings, it's most likely
-* a fixed resolution panel, check if the timings match with the
-* panel's timings
-*/
- if (dssdev->ops->check_timings) {
- r = dssdev->ops->check_timings(dssdev, );
- } else {
- struct videomode t = {0};
-
- dssdev->ops->get_timings(dssdev, );
-
- /*
-* Ignore the flags, as we don't get them from
-* drm_display_mode_to_videomode.
-*/
- t.flags = 0;
-
- if (memcmp(, , sizeof(vm)))
- r = -EINVAL;
- else
- r = 0;
- }
-
+ r = dssdev->ops->check_timings(dssdev, );
if (!r) {
/* check if vrefresh is still valid */
new_mode = drm_mode_duplicate(dev, mode);
diff --git a/drivers/gpu/drm/omapdrm/omap_encoder.c
b/drivers/gpu/drm/omapdrm/omap_encoder.c
index 94b75d018e71..a6dce480b2cf 100644
--- a/drivers/gpu/drm/omapdrm/omap_encoder.c
+++ b/drivers/gpu/drm/omapdrm/omap_encoder.c
@@ -101,21 +101,9 @@ static int omap_encoder_update(struct drm_encoder *encoder,
struct omap_dss_device *dssdev = omap_encoder->display;
int ret;
- if (dssdev->ops->check_timings) {
- ret = dssdev->ops->check_timings(dssdev, vm);
- } else {
- struct videomode t = {0};
-
- dssdev->ops->get_timings(dssdev, );
-
- if (memcmp(vm, , sizeof(*vm)))
- ret = -EINVAL;
- else
- ret = 0;
- }
-
+ ret = dssdev->ops->check_timings(dssdev, vm);
if (ret) {
- dev_err(dev->dev, "could not set timings: %d\n", ret);
+ dev_err(dev->dev, "invalid timings: %d\n", ret);
return ret;
}
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/23] drm/omap: Determine connector type directly in omap_connector.c
Instead of determining the connector type from the type of the display's
omap_dss_device and passing it to the omap_connector_init() function,
move the type determination code to omap_connector.c and remove the type
argument to the connector init function. This moves code to a more
natural location, making the driver easier to read.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_connector.c | 29 ++---
drivers/gpu/drm/omapdrm/omap_connector.h | 5 +++--
drivers/gpu/drm/omapdrm/omap_drv.c | 27 ++-
3 files changed, 31 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c
b/drivers/gpu/drm/omapdrm/omap_connector.c
index 77b044b778d6..e5ea027357c6 100644
--- a/drivers/gpu/drm/omapdrm/omap_connector.c
+++ b/drivers/gpu/drm/omapdrm/omap_connector.c
@@ -326,10 +326,33 @@ static const struct drm_connector_helper_funcs
omap_connector_helper_funcs = {
.mode_valid = omap_connector_mode_valid,
};
+static int omap_connector_get_type(struct omap_dss_device *display)
+{
+ switch (display->type) {
+ case OMAP_DISPLAY_TYPE_HDMI:
+ return DRM_MODE_CONNECTOR_HDMIA;
+ case OMAP_DISPLAY_TYPE_DVI:
+ return DRM_MODE_CONNECTOR_DVID;
+ case OMAP_DISPLAY_TYPE_DSI:
+ return DRM_MODE_CONNECTOR_DSI;
+ case OMAP_DISPLAY_TYPE_DPI:
+ case OMAP_DISPLAY_TYPE_DBI:
+ return DRM_MODE_CONNECTOR_DPI;
+ case OMAP_DISPLAY_TYPE_VENC:
+ /* TODO: This could also be composite */
+ return DRM_MODE_CONNECTOR_SVIDEO;
+ case OMAP_DISPLAY_TYPE_SDI:
+ return DRM_MODE_CONNECTOR_LVDS;
+ default:
+ return DRM_MODE_CONNECTOR_Unknown;
+ }
+}
+
/* initialize connector */
struct drm_connector *omap_connector_init(struct drm_device *dev,
- int connector_type, struct omap_dss_device *output,
- struct omap_dss_device *display, struct drm_encoder *encoder)
+ struct omap_dss_device *output,
+ struct omap_dss_device *display,
+ struct drm_encoder *encoder)
{
struct drm_connector *connector = NULL;
struct omap_connector *omap_connector;
@@ -349,7 +372,7 @@ struct drm_connector *omap_connector_init(struct drm_device
*dev,
connector->doublescan_allowed = 0;
drm_connector_init(dev, connector, _connector_funcs,
- connector_type);
+ omap_connector_get_type(display));
drm_connector_helper_add(connector, _connector_helper_funcs);
/*
diff --git a/drivers/gpu/drm/omapdrm/omap_connector.h
b/drivers/gpu/drm/omapdrm/omap_connector.h
index 42ff0a106179..854099801649 100644
--- a/drivers/gpu/drm/omapdrm/omap_connector.h
+++ b/drivers/gpu/drm/omapdrm/omap_connector.h
@@ -28,8 +28,9 @@ struct drm_encoder;
struct omap_dss_device;
struct drm_connector *omap_connector_init(struct drm_device *dev,
- int connector_type, struct omap_dss_device *output,
- struct omap_dss_device *display, struct drm_encoder *encoder);
+ struct omap_dss_device *output,
+ struct omap_dss_device *display,
+ struct drm_encoder *encoder);
struct drm_encoder *omap_connector_attached_encoder(
struct drm_connector *connector);
bool omap_connector_get_hdmi_mode(struct drm_connector *connector);
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index fd2d869304e7..abf199b677bb 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -129,28 +129,6 @@ static const struct drm_mode_config_funcs
omap_mode_config_funcs = {
.atomic_commit = drm_atomic_helper_commit,
};
-static int get_connector_type(struct omap_dss_device *display)
-{
- switch (display->type) {
- case OMAP_DISPLAY_TYPE_HDMI:
- return DRM_MODE_CONNECTOR_HDMIA;
- case OMAP_DISPLAY_TYPE_DVI:
- return DRM_MODE_CONNECTOR_DVID;
- case OMAP_DISPLAY_TYPE_DSI:
- return DRM_MODE_CONNECTOR_DSI;
- case OMAP_DISPLAY_TYPE_DPI:
- case OMAP_DISPLAY_TYPE_DBI:
- return DRM_MODE_CONNECTOR_DPI;
- case OMAP_DISPLAY_TYPE_VENC:
- /* TODO: This could also be composite */
- return DRM_MODE_CONNECTOR_SVIDEO;
- case OMAP_DISPLAY_TYPE_SDI:
- return DRM_MODE_CONNECTOR_LVDS;
- default:
- return DRM_MODE_CONNECTOR_Unknown;
- }
-}
-
static void omap_disconnect_pipelines(struct drm_device *ddev)
{
struct omap_drm_private *priv = ddev->dev_private;
@@ -322,9 +300,8 @@ static int omap_modeset_init(struct drm_device *dev)
[PATCH 01/23] drm/omap: Pass both output and display omap_dss_device to connector init
The drm_connector implementation requires access to the omap_dss_device
corresponding to the display, which is passed to its initialization
function and stored internally. Refactoring of the timings operations
will require access to the output omap_dss_device. To prepare for that,
pass it to the connector initialization function and store it internally
as well.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_connector.c | 30 +-
drivers/gpu/drm/omapdrm/omap_connector.h | 4 ++--
drivers/gpu/drm/omapdrm/omap_drv.c | 3 ++-
3 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c
b/drivers/gpu/drm/omapdrm/omap_connector.c
index a1d379816732..77b044b778d6 100644
--- a/drivers/gpu/drm/omapdrm/omap_connector.c
+++ b/drivers/gpu/drm/omapdrm/omap_connector.c
@@ -29,7 +29,8 @@
struct omap_connector {
struct drm_connector base;
- struct omap_dss_device *dssdev;
+ struct omap_dss_device *output;
+ struct omap_dss_device *display;
struct omap_dss_device *hpd;
bool hdmi_mode;
};
@@ -104,7 +105,7 @@ omap_connector_find_device(struct drm_connector *connector,
struct omap_connector *omap_connector = to_omap_connector(connector);
struct omap_dss_device *dssdev;
- for (dssdev = omap_connector->dssdev; dssdev; dssdev = dssdev->src) {
+ for (dssdev = omap_connector->display; dssdev; dssdev = dssdev->src) {
if (dssdev->ops_flags & op)
return dssdev;
}
@@ -129,7 +130,7 @@ static enum drm_connector_status omap_connector_detect(
omap_connector_hpd_notify(connector, dssdev->src, status);
} else {
- switch (omap_connector->dssdev->type) {
+ switch (omap_connector->display->type) {
case OMAP_DISPLAY_TYPE_DPI:
case OMAP_DISPLAY_TYPE_DBI:
case OMAP_DISPLAY_TYPE_SDI:
@@ -142,7 +143,7 @@ static enum drm_connector_status omap_connector_detect(
}
}
- VERB("%s: %d (force=%d)", omap_connector->dssdev->name, status, force);
+ VERB("%s: %d (force=%d)", omap_connector->display->name, status, force);
return status;
}
@@ -151,7 +152,7 @@ static void omap_connector_destroy(struct drm_connector
*connector)
{
struct omap_connector *omap_connector = to_omap_connector(connector);
- DBG("%s", omap_connector->dssdev->name);
+ DBG("%s", omap_connector->display->name);
if (omap_connector->hpd) {
struct omap_dss_device *hpd = omap_connector->hpd;
@@ -165,7 +166,8 @@ static void omap_connector_destroy(struct drm_connector
*connector)
drm_connector_cleanup(connector);
kfree(omap_connector);
- omapdss_device_put(omap_connector->dssdev);
+ omapdss_device_put(omap_connector->output);
+ omapdss_device_put(omap_connector->display);
}
#define MAX_EDID 512
@@ -212,7 +214,7 @@ static int omap_connector_get_modes(struct drm_connector
*connector)
struct drm_display_mode *mode;
struct videomode vm = {0};
- DBG("%s", omap_connector->dssdev->name);
+ DBG("%s", omap_connector->display->name);
/*
* If display exposes EDID, then we parse that in the normal way to
@@ -229,7 +231,7 @@ static int omap_connector_get_modes(struct drm_connector
*connector)
if (!mode)
return 0;
- dssdev = omap_connector->dssdev;
+ dssdev = omap_connector->display;
dssdev->ops->get_timings(dssdev, );
drm_display_mode_from_videomode(, mode);
@@ -250,7 +252,7 @@ static int omap_connector_mode_valid(struct drm_connector
*connector,
const struct drm_display_mode *mode)
{
struct omap_connector *omap_connector = to_omap_connector(connector);
- struct omap_dss_device *dssdev = omap_connector->dssdev;
+ struct omap_dss_device *dssdev = omap_connector->display;
struct videomode vm = {0};
struct drm_device *dev = connector->dev;
struct drm_display_mode *new_mode;
@@ -326,19 +328,21 @@ static const struct drm_connector_helper_funcs
omap_connector_helper_funcs = {
/* initialize connector */
struct drm_connector *omap_connector_init(struct drm_device *dev,
- int connector_type, struct omap_dss_device *dssdev,
- struct drm_encoder *encoder)
+ int connector_type, struct omap_dss_device *output,
+ struct omap_dss_device *display, struct drm_encoder *encoder)
{
struct drm_connector *connector = NULL;
struct omap_connector *omap_connector;
+ struct omap_dss_device *dssdev;
- DBG("%s", dssdev->name);
+ DBG("%s", display->name);
omap_connector = kzalloc(sizeof(*omap_connector), GFP_KERNEL);
if (!omap_connector)
goto fail;
-
[PATCH 05/23] drm/omap: Remove duplicate calls to .set_timings() operation
The omap_dss_device .set_timings() operations are called directly from
omap_encoder_update(), and indirectly from the omap_dss_device .enable()
operation. The latter is called from omap_encoder_enable(), right after
calling omap_encoder_update(). The .set_timings() operation it thus
called twice in a row. Fix it by removing the indirect call.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c | 2 --
drivers/gpu/drm/omapdrm/displays/connector-dvi.c| 3 ---
drivers/gpu/drm/omapdrm/displays/connector-hdmi.c | 2 --
drivers/gpu/drm/omapdrm/displays/encoder-opa362.c | 2 --
drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c | 2 --
drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c| 3 ---
drivers/gpu/drm/omapdrm/displays/panel-dpi.c| 2 --
drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c | 2 --
drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c | 2 --
drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c | 2 --
drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c | 2 --
drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c | 2 --
drivers/gpu/drm/omapdrm/displays/panel-tpo-td043mtea1.c | 2 --
13 files changed, 28 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
index 22bc2e734b0b..fb6d4fce1853 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
@@ -66,8 +66,6 @@ static int tvc_enable(struct omap_dss_device *dssdev)
if (omapdss_device_is_enabled(dssdev))
return 0;
- src->ops->set_timings(src, >vm);
-
r = src->ops->enable(src);
if (r)
return r;
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
index 8f953303ece6..b89555ed53a0 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
@@ -69,7 +69,6 @@ static void dvic_disconnect(struct omap_dss_device *src,
static int dvic_enable(struct omap_dss_device *dssdev)
{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *src = dssdev->src;
int r;
@@ -79,8 +78,6 @@ static int dvic_enable(struct omap_dss_device *dssdev)
if (omapdss_device_is_enabled(dssdev))
return 0;
- src->ops->set_timings(src, >vm);
-
r = src->ops->enable(src);
if (r)
return r;
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
index 1cbc593c79ff..898eb583688f 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
@@ -71,8 +71,6 @@ static int hdmic_enable(struct omap_dss_device *dssdev)
if (omapdss_device_is_enabled(dssdev))
return 0;
- src->ops->set_timings(src, >vm);
-
r = src->ops->enable(src);
if (r)
return r;
diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c
b/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c
index 5a406ffcc836..a0e54634beeb 100644
--- a/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c
+++ b/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c
@@ -57,8 +57,6 @@ static int opa362_enable(struct omap_dss_device *dssdev)
if (omapdss_device_is_enabled(dssdev))
return 0;
- src->ops->set_timings(src, >vm);
-
r = src->ops->enable(src);
if (r)
return r;
diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
b/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
index 7df138094321..bcbd1a65b55c 100644
--- a/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
+++ b/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
@@ -50,8 +50,6 @@ static int tfp410_enable(struct omap_dss_device *dssdev)
if (omapdss_device_is_enabled(dssdev))
return 0;
- src->ops->set_timings(src, >vm);
-
r = src->ops->enable(src);
if (r)
return r;
diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
index 759d95faa4b4..131adfaad4d5 100644
--- a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
+++ b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
@@ -66,15 +66,12 @@ static void tpd_disconnect(struct omap_dss_device *src,
static int tpd_enable(struct omap_dss_device *dssdev)
{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *src = dssdev->src;
int r;
if (dssdev->state == OMAP_DSS_DISPLAY_ACTIVE)
return 0;
- src->ops->set_timings(src, >vm);
-
r = src->ops->enable(src);
if (r)
Re: [PATCH 3/3] ANDROID: goldfish_fb: Set pixclock = 0
[ + linux-fbdev ML ] On Thursday, May 31, 2018 03:02:52 PM r...@google.com wrote: > From: Christoffer Dall > > User space Android code identifies pixclock == 0 as a sign for emulation > and will set the frame rate to 60 fps when reading this value, which is > the desired outcome. > > Change-Id: I759bf518bf6683446bc786bf1be3cafa02dd8d42 please drop your local Change-Id from the upstream kernel submissions > Signed-off-by: Christoffer Dall > Signed-off-by: Peter Maydell your S-o-b line is also needed Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] goldfish: Enable ACPI-based enumeration for goldfish framebuffer
[ + linux-fbdev ML ]
Hi,
On Thursday, May 31, 2018 03:02:51 PM r...@google.com wrote:
> From: Yu Ning
>
> Follow the same way in which ACPI was enabled for goldfish battery. See
> commit d3be10e for details.
No commit d3be10e in upstream and -next kernels?
> Note that this patch also depends on commit af33cac.
ditto for commit af33ac
also commits should be described with the following format:
tag with the first 12 characters of the SHA-1 ID, and the one line summary,
i.e.:
e21d2170f366 ("video: remove unnecessary platform_set_drvdata()")
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105880] [dc] No support for LVDS or VGA connectors (Cannot find any crtc or sizes)
https://bugs.freedesktop.org/show_bug.cgi?id=105880 --- Comment #22 from Przemek --- Just to supplement the list above. Netbook Lenovo g50-45, a6-6310 R4 Beema/Mullins. Has HDMI and VGA output. HDMI is working without a hitch, while VGA output is dead.(eDP plus only one extra monitor connected at a time) Thanks, Przemek. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fb_omap: add gpiolib dependency
On Wednesday, May 30, 2018 11:49:22 PM Arnd Bergmann wrote: > Building the omap sub-drivers when CONFIG_GPIOLIB is disabled causes > lots of build failures, either from using gpiolib interfaces, or from > including the wrong headers: > > drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c: In function > 'opa362_enable': > drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:101:3: error: > implicit declaration of function 'gpiod_set_value_cansleep'; did you mean > 'gpio_set_value_cansleep'? [-Werror=implicit-function-declaration] > drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c: In function > 'panel_dpi_enable': > drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c:86:2: error: implicit > declaration of function 'gpiod_set_value_cansleep'; did you mean > 'gpio_set_value_cansleep'? [-Werror=implicit-function-declaration] > drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c: In function > 'panel_dpi_probe_pdata': > drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c:189:23: error: implicit > declaration of function 'gpio_to_desc'; did you mean 'irq_to_desc'? > [-Werror=implicit-function-declaration] > drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c: In function > 'panel_dpi_probe_of': > drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c:210:9: error: implicit > declaration of function 'devm_gpiod_get_optional'; did you mean > 'devm_gpio_request_one'? [-Werror=implicit-function-declaration] > drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c: In > function 'sharp_ls_enable': > drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c:120:3: > error: implicit declaration of function 'gpiod_set_value_cansleep'; did you > mean 'gpio_set_value_cansleep'? [-Werror=implicit-function-declaration] > drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c: In > function 'lb035q02_enable': > drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c:170:3: > error: implicit declaration of function 'gpiod_set_value_cansleep'; did you > mean 'gpio_set_value_cansleep'? [-Werror=implicit-function-declaration] > drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c: In function 'hdmi_probe_of': > drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c:584:2: error: implicit > declaration of function 'of_node_put'; did you mean 'node_set'? > [-Werror=implicit-function-declaration] > drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c: In function 'hdmi_probe_of': > drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c:554:2: error: implicit > declaration of function 'of_node_put'; did you mean 'node_set'? > [-Werror=implicit-function-declaration] > > Rather than fixing up each one individually, this just marks all of it > as depending on GPIOLIB. > > Signed-off-by: Arnd Bergmann Patch queued for 4.18 (w/ fb_omap->fb_omap2 fixed in the patch title), thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video/omap: add module license tags
On Monday, May 28, 2018 05:46:19 PM Arnd Bergmann wrote:
> I got a bunch of warnings in a randconfig build:
>
> WARNING: modpost: missing MODULE_LICENSE() in
> drivers/video/fbdev/omap/lcd_ams_delta.o
> WARNING: modpost: missing MODULE_LICENSE() in
> drivers/video/fbdev/omap/lcd_inn1510.o
> WARNING: modpost: missing MODULE_LICENSE() in
> drivers/video/fbdev/omap/lcd_palmte.o
> WARNING: modpost: missing MODULE_LICENSE() in
> drivers/video/fbdev/omap/lcd_palmtt.o
>
> These come from an earlier patch of mine that turned all display drivers
> into separate modules. The fix is to add a MODULE_LICENSE tag. Since I'm
> doing that, adding a description and author field also makes sense. I
> went by the authors listed in the comment at the top of each file, but
> removed Imre's Nokia email address that I assume is not valid any more,
> since Imre is working at Intel these days.
>
> Fixes: 81c44c2b2ce3 ("video/omap: fix modular build")
> Cc: Imre Deak
> Signed-off-by: Arnd Bergmann
Patch queued for 4.18 (with minor fixups, interdiff below), thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
diff -u b/drivers/video/fbdev/omap/lcd_ams_delta.c
b/drivers/video/fbdev/omap/lcd_ams_delta.c
--- b/drivers/video/fbdev/omap/lcd_ams_delta.c
+++ b/drivers/video/fbdev/omap/lcd_ams_delta.c 2018-06-08 17:39:29.739986550
+0200
@@ -197,6 +197,7 @@
};
module_platform_driver(ams_delta_panel_driver);
+
MODULE_AUTHOR("Jonathan McDowell ");
MODULE_DESCRIPTION("LCD panel support for the Amstrad E3 (Delta) videophone");
MODULE_LICENSE("GPL");
diff -u b/drivers/video/fbdev/omap/lcd_h3.c b/drivers/video/fbdev/omap/lcd_h3.c
--- b/drivers/video/fbdev/omap/lcd_h3.c
+++ b/drivers/video/fbdev/omap/lcd_h3.c 2018-06-08 17:39:41.323986842 +0200
@@ -89,6 +89,7 @@
};
module_platform_driver(h3_panel_driver);
+
MODULE_AUTHOR("Imre Deak");
MODULE_DESCRIPTION("LCD panel support for the TI OMAP H3 board");
MODULE_LICENSE("GPL");
diff -u b/drivers/video/fbdev/omap/lcd_inn1510.c
b/drivers/video/fbdev/omap/lcd_inn1510.c
--- b/drivers/video/fbdev/omap/lcd_inn1510.c
+++ b/drivers/video/fbdev/omap/lcd_inn1510.c2018-06-08 17:40:29.055988044
+0200
@@ -73,6 +73,7 @@
};
module_platform_driver(innovator1510_panel_driver);
+
MODULE_AUTHOR("Imre Deak");
MODULE_DESCRIPTION("LCD panel support for the TI OMAP1510 Innovator board");
MODULE_LICENSE("GPL");
diff -u b/drivers/video/fbdev/omap/lcd_inn1610.c
b/drivers/video/fbdev/omap/lcd_inn1610.c
--- b/drivers/video/fbdev/omap/lcd_inn1610.c
+++ b/drivers/video/fbdev/omap/lcd_inn1610.c2018-06-08 17:40:40.851988341
+0200
@@ -106,6 +106,7 @@
};
module_platform_driver(innovator1610_panel_driver);
+
MODULE_AUTHOR("Imre Deak");
MODULE_DESCRIPTION("LCD panel support for the TI OMAP1610 Innovator board");
MODULE_LICENSE("GPL");
diff -u b/drivers/video/fbdev/omap/lcd_osk.c
b/drivers/video/fbdev/omap/lcd_osk.c
--- b/drivers/video/fbdev/omap/lcd_osk.c
+++ b/drivers/video/fbdev/omap/lcd_osk.c2018-06-08 17:40:55.163988701
+0200
@@ -97,3 +97,3 @@
-MODULE_LICENSE("GPL");
MODULE_AUTHOR("Imre Deak");
MODULE_DESCRIPTION("LCD panel support for the TI OMAP OSK board");
+MODULE_LICENSE("GPL");
diff -u b/drivers/video/fbdev/omap/lcd_palmte.c
b/drivers/video/fbdev/omap/lcd_palmte.c
--- b/drivers/video/fbdev/omap/lcd_palmte.c
+++ b/drivers/video/fbdev/omap/lcd_palmte.c 2018-06-08 17:41:13.839989172
+0200
@@ -60,5 +60,5 @@
module_platform_driver(palmte_panel_driver);
-MODULE_AUTHOR("Romain Goyet ");
+MODULE_AUTHOR("Romain Goyet , Laurent Gonzalez
");
MODULE_DESCRIPTION("LCD panel support for the Palm Tungsten E");
MODULE_LICENSE("GPL");
diff -u b/drivers/video/fbdev/omap/lcd_palmtt.c
b/drivers/video/fbdev/omap/lcd_palmtt.c
--- b/drivers/video/fbdev/omap/lcd_palmtt.c
+++ b/drivers/video/fbdev/omap/lcd_palmtt.c 2018-06-08 17:42:30.85599
+0200
@@ -72,6 +72,7 @@
};
module_platform_driver(palmtt_panel_driver);
+
MODULE_AUTHOR("Marek Vasut ");
MODULE_DESCRIPTION("LCD panel support for Palm Tungsten|T");
MODULE_LICENSE("GPL");
diff -u b/drivers/video/fbdev/omap/lcd_palmz71.c
b/drivers/video/fbdev/omap/lcd_palmz71.c
--- b/drivers/video/fbdev/omap/lcd_palmz71.c
+++ b/drivers/video/fbdev/omap/lcd_palmz71.c2018-06-08 17:43:16.543992262
+0200
@@ -67,5 +67,5 @@
module_platform_driver(palmz71_panel_driver);
-MODULE_AUTHOR("Marek Vasut");
+MODULE_AUTHOR("Romain Goyet, Laurent Gonzalez, Marek Vasut");
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("LCD panel support for the Palm Zire71");
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] MAINTAINERS: make omapfb orphan
On Monday, May 07, 2018 03:15:22 PM Tomi Valkeinen wrote: > omapfb is not maintained by me anymore, so drop my name from the > maintainers, and mark omapfb as orphan. > > At some point in the future we should mark omapfb as obsolete, but there > are still some features supported by omapfb which are not supported by > omapdrm, so we're not there yet. > > Signed-off-by: Tomi Valkeinen Thank you for your work on omapfb, patch queued for 4.18. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-next-fixes for drm-next/v4.18
Hi Dave, these missed the main drm-next pull request. drm-intel-next-fixes-2018-06-08-2: First batch of i915 fixes for v4.18: - gvt fixes that missed v4.17, potentially need to be backported - eDP resolution regression revert - remove broken nv12 special casing - remove stale asserts from find active requests BR, Jani. The following changes since commit 315852b422972e6ebb1dfddaadada09e46a2681a: drm: rcar-du: Fix build failure (2018-05-17 15:03:40 +1000) are available in the git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2018-06-08-2 for you to fetch changes up to 807cba6559cf333a74df1fbd74f0597e8e7fa020: Merge tag 'gvt-fixes-2018-04-19' of https://github.com/intel/gvt-linux into drm-intel-next-fixes (2018-06-07 12:06:07 +0300) First batch of i915 fixes for v4.18: - gvt fixes that missed v4.17, potentially need to be backported - eDP resolution regression revert - remove broken nv12 special casing - remove stale asserts from find active requests Changbin Du (2): drm/i915/gvt: Fix the validation on size field of dp aux header drm/i915/kvmgt: Check the pfn got from vfio_pin_pages Chris Wilson (2): drm/i915: Nul-terminate legacy debug string drm/i915: Remove stale asserts from i915_gem_find_active_request() Colin Ian King (1): drm/i915/gvt: fix memory leak of a cmd_entry struct on error exit path Jani Nikula (2): Revert "drm/i915/edp: Allow alternate fixed mode for eDP if available." Merge tag 'gvt-fixes-2018-04-19' of https://github.com/intel/gvt-linux into drm-intel-next-fixes Mahesh Kumar (2): drm/i915/icl: fix icl_unmap/map_plls_to_ports drm/i915/icl: Don't update enabled dbuf slices struct until updated in hw Ville Syrjälä (1): drm/i915: Remove bogus NV12 PLANE_COLOR_CTL setup Xiong Zhang (1): drm/i915/gvt: Dereference msi eventfd_ctx when it isn't used anymore Zhenyu Wang (1): Back merge 'drm-intel-fixes' into gvt-fixes drivers/gpu/drm/i915/gvt/cmd_parser.c | 1 + drivers/gpu/drm/i915/gvt/display.h | 2 +- drivers/gpu/drm/i915/gvt/handlers.c| 13 drivers/gpu/drm/i915/gvt/kvmgt.c | 34 +- drivers/gpu/drm/i915/i915_gem.c| 17 +++ drivers/gpu/drm/i915/intel_ddi.c | 6 -- drivers/gpu/drm/i915/intel_display.c | 7 +-- drivers/gpu/drm/i915/intel_dp.c| 38 +- drivers/gpu/drm/i915/intel_drv.h | 2 -- drivers/gpu/drm/i915/intel_dsi.c | 2 +- drivers/gpu/drm/i915/intel_dvo.c | 2 +- drivers/gpu/drm/i915/intel_engine_cs.c | 2 +- drivers/gpu/drm/i915/intel_lvds.c | 3 +-- drivers/gpu/drm/i915/intel_panel.c | 6 -- drivers/gpu/drm/i915/intel_pm.c| 1 - 15 files changed, 66 insertions(+), 70 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199959] amdgpu, regression?: system freezes after resume
https://bugzilla.kernel.org/show_bug.cgi?id=199959 --- Comment #8 from Christian König (christian.koe...@amd.com) --- Mhm, I've tried the same ASIC (Polaris 10 8gb) in an AMD Threadripper and here it is working quite fine with suspend/resume. So the only explanation I have is that this is some strange issue with PCI BAR resizing and Intel hardware. Is the system completely unresponsive after resume, or can you at least ping it over the network? -- 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 6/9] xen/gntdev: Add initial support for dma-buf UAPI
On 06/08/2018 01:26 AM, Boris Ostrovsky wrote: On 06/07/2018 03:17 AM, Oleksandr Andrushchenko wrote: On 06/07/2018 12:32 AM, Boris Ostrovsky wrote: On 06/06/2018 05:06 AM, Oleksandr Andrushchenko wrote: On 06/04/2018 11:49 PM, Boris Ostrovsky wrote: diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c index 9813fc440c70..7d58dfb3e5e8 100644 --- a/drivers/xen/gntdev.c +++ b/drivers/xen/gntdev.c ... +#ifdef CONFIG_XEN_GNTDEV_DMABUF This code belongs in gntdev-dmabuf.c. The reason I have this code here is that it is heavily tied to gntdev's internal functionality, e.g. map/unmap. I do not want to extend gntdev's API, so gntdev-dmabuf can access these. What is more dma-buf doesn't need to know about maps done by gntdev as there is no use of that information in gntdev-dmabuf. So, it seems more naturally to have dma-buf's related map/unmap code where it is: in gntdev. Sorry, I don't follow. Why would this require extending the API? It's just moving routines to a different file that is linked to the same module. I do understand your intention here and tried to avoid dma-buf related code in gntdev.c as much as possible. So, let me explain my decision in more detail. There are 2 use-cases we have: dma-buf import and export. While importing a dma-buf all the dma-buf related functionality can easily be kept inside gntdev-dmabuf.c w/o any issue as all we need from gntdev.c is dev, dma_buf_fd, count and domid for that. But in case of dma-buf export we need to: 1. struct grant_map *map = gntdev_alloc_map(priv, count, dmabuf_flags); 2. gntdev_add_map(priv, map); 3. Set map->flags 4. ret = map_grant_pages(map); 5. And only now we are all set to export the new dma-buf from *map->pages* So, until 5) we use private gtndev.c's API not exported to outside world: a. struct grant_map b. static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count, int dma_flags) c. static void gntdev_add_map(struct gntdev_priv *priv, struct grant_map *add) d. static int map_grant_pages(struct grant_map *map) Thus, all the above cannot be accessed from gntdev-dmabuf.c This is why I say that gntdev.c's API will need to be extended to provide the above a-d if we want all dma-buf export code to leave in gntdev-dmabuf.c. I still don't understand why you feel this would be extending the API. These routines and the struct can be declared in local header file and this header file will not be visible to anyone but gntdev.c and gntdev-dmabuf.c. Ok, this is what I meant: I will need to move private structures and some function prototypes from gntdev.c into a header file, thus extending its API: before the header nothing were exposed. Sorry for not being clear here. You can, for example, put this into gntdev-dmabuf.h (and then rename it to something else, like gntdev-common.h). Sure, I will move all I need into that shared header But that doesn't seem good to me and what is more a-d are really gntdev.c's functionality, not dma-buf's which only needs pages and doesn't really care from where those come. That was the reason I partitioned export into 2 chunks: gntdev + gntdev-dmabuf. You might also ask why importing side does Xen related things (granting references+) in gntdev-dmabuf, not gntdev so it is consistent with the dma-buf exporter? This is because importer uses grant-table's API which seems to be not natural for gntdev.c, so it can leave in gntdev-dmabuf.c which has a use-case for that, while gntdev remains the same. Yet another reason why this code should be moved: importing and exporting functionalities logically belong together. The fat that they are implemented using different methods is not relevant IMO. If you have code which is under ifdef CONFIG_GNTDEV_DMABUF and you have file called gntdev-dmabuf.c it sort of implies that this code should live in that file (unless that code is intertwined with other code, which is not the case here). Ok, will move as discussed above -boris Thank you, Oleksandr Since this is under CONFIG_XEN_GNTDEV_DMABUF then why shouldn't it be in gntdev-dmabuf.c? In my view that's the file where all dma-related "stuff" lives. Agree, but IMO grant_map stuff for dma-buf importer is right in its place in gntdev.c and all the rest of dma-buf specifics live in gntdev-dmabuf.c as they should -boris -boris Thank you, Oleksandr ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 7/9] xen/gntdev: Implement dma-buf export functionality
On 06/08/2018 01:30 AM, Boris Ostrovsky wrote:
On 06/07/2018 04:44 AM, Oleksandr Andrushchenko wrote:
On 06/07/2018 12:48 AM, Boris Ostrovsky wrote:
On 06/06/2018 08:10 AM, Oleksandr Andrushchenko wrote:
On 06/05/2018 01:07 AM, Boris Ostrovsky wrote:
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
+
+static struct sg_table *
+dmabuf_exp_ops_map_dma_buf(struct dma_buf_attachment *attach,
+ enum dma_data_direction dir)
+{
+ struct gntdev_dmabuf_attachment *gntdev_dmabuf_attach =
attach->priv;
+ struct gntdev_dmabuf *gntdev_dmabuf = attach->dmabuf->priv;
+ struct sg_table *sgt;
+
+ pr_debug("Mapping %d pages for dev %p\n",
gntdev_dmabuf->nr_pages,
+ attach->dev);
+
+ if (WARN_ON(dir == DMA_NONE || !gntdev_dmabuf_attach))
WARN_ON_ONCE. Here and elsewhere.
Why? The UAPI may be used by different applications, thus we might
lose warnings for some of them. Having WARN_ON will show problems
for multiple users, not for the first one.
Does this make sense to still use WARN_ON?
Just as with pr_err call somewhere else the concern here is that
userland (which I think is where this is eventually called from?) may
intentionally trigger the error, flooding the log.
And even this is not directly called from userland there is still a
possibility of triggering this error multiple times.
Ok, will use WARN_ON_ONCE
In fact, is there a reason to use WARN at all? Does this condition
indicate some sort of internal inconsistency/error?
Well, the corresponding errors are anyways handled, so I will remove WARN
-boris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Xen-devel] [PATCH v2 5/9] xen/gntdev: Allow mappings for DMA buffers
On 06/08/2018 12:46 AM, Boris Ostrovsky wrote:
(Stefano, question for you at the end)
On 06/07/2018 02:39 AM, Oleksandr Andrushchenko wrote:
On 06/07/2018 12:19 AM, Boris Ostrovsky wrote:
On 06/06/2018 04:14 AM, Oleksandr Andrushchenko wrote:
On 06/04/2018 11:12 PM, Boris Ostrovsky wrote:
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
@@ -121,8 +146,27 @@ static void gntdev_free_map(struct grant_map
*map)
if (map == NULL)
return;
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
*Option 1: kfree(map->frames);*
+ if (map->dma_vaddr) {
+ struct gnttab_dma_alloc_args args;
+
+ args.dev = map->dma_dev;
+ args.coherent = map->dma_flags & GNTDEV_DMA_FLAG_COHERENT;
+ args.nr_pages = map->count;
+ args.pages = map->pages;
+ args.frames = map->frames;
+ args.vaddr = map->dma_vaddr;
+ args.dev_bus_addr = map->dma_bus_addr;
+
+ gnttab_dma_free_pages();
*Option 2: kfree(map->frames);*
+ } else
+#endif
if (map->pages)
gnttab_free_pages(map->count, map->pages);
+
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+ kfree(map->frames);
+#endif
Can this be done under if (map->dma_vaddr) ?
In other words, is it
possible for dma_vaddr to be NULL and still have unallocated frames
pointer?
It is possible to have vaddr == NULL and frames != NULL as we
allocate frames outside of gnttab_dma_alloc_pages which
may fail. Calling kfree on NULL pointer is safe,
I am not questioning safety of the code, I would like avoid another
ifdef.
Ah, I now understand, so you are asking if we can have
that kfree(map->frames); in the place *Option 2* I marked above.
Unfortunately no: map->frames is allocated before we try to
allocate DMA memory, e.g. before dma_vaddr is set:
[...]
add->frames = kcalloc(count, sizeof(add->frames[0]),
GFP_KERNEL);
if (!add->frames)
goto err;
[...]
if (gnttab_dma_alloc_pages())
goto err;
add->dma_vaddr = args.vaddr;
[...]
err:
gntdev_free_map(add);
So, it is possible to enter gntdev_free_map with
frames != NULL and dma_vaddr == NULL. Option 1 above cannot be used
as map->frames is needed for gnttab_dma_free_pages();
and Option 2 cannot be used as frames != NULL and dma_vaddr == NULL.
Thus, I think that unfortunately we need that #ifdef.
Option 3 below can also be considered, but that seems to be not good
as we free resources in different places which looks inconsistent.
I was only thinking of option 2. But if it is possible to have frames !=
NULL and dma_vaddr == NULL then perhaps we indeed will have to live with
the extra ifdef.
ok
Sorry if I'm still missing your point.
so
I see no reason to change this code.
kfree(map->pages);
kfree(map->grants);
kfree(map->map_ops);
@@ -132,7 +176,8 @@ static void gntdev_free_map(struct grant_map
*map)
kfree(map);
}
-static struct grant_map *gntdev_alloc_map(struct gntdev_priv
*priv, int count)
+static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv,
int count,
+ int dma_flags)
{
struct grant_map *add;
int i;
@@ -155,6 +200,37 @@ static struct grant_map
*gntdev_alloc_map(struct gntdev_priv *priv, int count)
NULL == add->pages)
goto err;
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+ add->dma_flags = dma_flags;
+
+ /*
+ * Check if this mapping is requested to be backed
+ * by a DMA buffer.
+ */
+ if (dma_flags & (GNTDEV_DMA_FLAG_WC |
GNTDEV_DMA_FLAG_COHERENT)) {
+ struct gnttab_dma_alloc_args args;
+
+ add->frames = kcalloc(count, sizeof(add->frames[0]),
+ GFP_KERNEL);
+ if (!add->frames)
+ goto err;
+
+ /* Remember the device, so we can free DMA memory. */
+ add->dma_dev = priv->dma_dev;
+
+ args.dev = priv->dma_dev;
+ args.coherent = dma_flags & GNTDEV_DMA_FLAG_COHERENT;
+ args.nr_pages = count;
+ args.pages = add->pages;
+ args.frames = add->frames;
+
+ if (gnttab_dma_alloc_pages())
*Option 3: kfree(map->frames);*
+ goto err;
+
+ add->dma_vaddr = args.vaddr;
+ add->dma_bus_addr = args.dev_bus_addr;
+ } else
+#endif
if (gnttab_alloc_pages(count, add->pages))
goto err;
@@ -325,6 +401,14 @@ static int map_grant_pages(struct grant_map
*map)
map->unmap_ops[i].handle = map->map_ops[i].handle;
if (use_ptemod)
map->kunmap_ops[i].handle = map->kmap_ops[i].handle;
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+ else if (map->dma_vaddr) {
+ unsigned long mfn;
+
+ mfn = __pfn_to_mfn(page_to_pfn(map->pages[i]));
Not pfn_to_mfn()?
I'd love to, but pfn_to_mfn is only defined for x86, not ARM: [1]
and [2]
Thus,
drivers/xen/gntdev.c:408:10: error: implicit declaration of function
‘pfn_to_mfn’ [-Werror=implicit-function-declaration]
[Bug 199959] amdgpu, regression?: system freezes after resume
https://bugzilla.kernel.org/show_bug.cgi?id=199959 --- Comment #7 from Alexander Mezin (mezin.alexan...@gmail.com) --- Created attachment 276393 --> https://bugzilla.kernel.org/attachment.cgi?id=276393=edit /proc/iomem -- 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 199959] amdgpu, regression?: system freezes after resume
https://bugzilla.kernel.org/show_bug.cgi?id=199959 --- Comment #6 from Alexander Mezin (mezin.alexan...@gmail.com) --- Created attachment 276391 --> https://bugzilla.kernel.org/attachment.cgi?id=276391=edit lspci -t -v -nn -- 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 73931] rmmod radeon and kernel crash
https://bugzilla.kernel.org/show_bug.cgi?id=73931 Mateusz Lenik (m...@mlen.pl) changed: What|Removed |Added CC||m...@mlen.pl --- Comment #11 from Mateusz Lenik (m...@mlen.pl) --- Same issue for amdgpu after unbind (not sure if this should be a separate bug): rook ~ ➤ ls -l /sys/class/hwmon/hwmon1/device lrwxrwxrwx 1 root root 0 cze 8 12:32 /sys/class/hwmon/hwmon1/device -> ../../../:03:00.0 rook ~ ➤ cat /sys/class/hwmon/hwmon1/fan1_input [1]9145 killed cat /sys/class/hwmon/hwmon1/fan1_input Reading fan1_input causes an OOPS: [ 590.507564] BUG: unable to handle kernel NULL pointer dereference at 00b8 [ 590.507584] IP: amdgpu_hwmon_get_fan1_input+0x33/0x84 [ 590.507587] PGD 0 P4D 0 [ 590.507593] Oops: [#4] PREEMPT SMP PTI [ 590.507597] Modules linked in: [ 590.507610] CPU: 39 PID: 9222 Comm: cat Tainted: G D 4.16.14-gentoo #3 [ 590.507613] Hardware name: ASUSTeK COMPUTER INC. Z10PE-D16 WS/Z10PE-D16 WS, BIOS 3407 03/10/2017 [ 590.507617] RIP: 0010:amdgpu_hwmon_get_fan1_input+0x33/0x84 [ 590.507620] RSP: 0018:97790d2dfd68 EFLAGS: 00010246 [ 590.507624] RAX: RBX: 9147b5cd3000 RCX: 9137b5428ac8 [ 590.507627] RDX: 9137b5aa RSI: bbb3e1c0 RDI: 9137b55f7008 [ 590.507630] RBP: fffb R08: 0001 R09: [ 590.507633] R10: 9137af38d400 R11: R12: bb30d000 [ 590.507636] R13: 9147b590d400 R14: 91476a16db00 R15: 0001 [ 590.507639] FS: 7f3838cbe540() GS:9147bf40() knlGS: [ 590.507641] CS: 0010 DS: ES: CR0: 80050033 [ 590.507643] CR2: 00b8 CR3: 002023776005 CR4: 003606e0 [ 590.507645] DR0: DR1: DR2: [ 590.507647] DR3: DR6: fffe0ff0 DR7: 0400 [ 590.507649] Call Trace: [ 590.507660] dev_attr_show+0x23/0x44 [ 590.507668] sysfs_kf_seq_show+0x7f/0xce [ 590.507676] seq_read+0x1c1/0x3d1 [ 590.507687] __vfs_read+0x33/0xcc [ 590.507693] vfs_read+0x9a/0xcf [ 590.507696] SyS_read+0x5f/0xa3 [ 590.507703] do_syscall_64+0x79/0x88 [ 590.507711] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 [ 590.507715] RIP: 0033:0x7f38387f8b75 [ 590.507718] RSP: 002b:72570970 EFLAGS: 0246 ORIG_RAX: [ 590.507721] RAX: ffda RBX: 0002 RCX: 7f38387f8b75 [ 590.507723] RDX: 0002 RSI: 7f3838cd RDI: 0003 [ 590.507725] RBP: 0002 R08: R09: [ 590.507727] R10: 039b R11: 0246 R12: 7f3838cd [ 590.507729] R13: 0003 R14: 7f3838cd000f R15: 0002 [ 590.507738] Code: d3 48 83 ec 10 48 8b 97 18 01 00 00 65 48 8b 04 25 28 00 00 00 48 89 44 24 08 31 c0 c7 44 24 04 00 00 00 00 48 8b 82 08 49 00 00 <48> 8b 80 b8 00 00 00 48 85 c0 74 15 48 8b ba f8 48 00 00 48 8d [ 590.507821] RIP: amdgpu_hwmon_get_fan1_input+0x33/0x84 RSP: 97790d2dfd68 [ 590.507824] CR2: 00b8 [ 590.507830] ---[ end trace eaed7563e433ab4e ]--- -- 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 3/3] drm/v3d: Add a note about locking of v3d_fence_create().
Am Dienstag, den 05.06.2018, 12:03 -0700 schrieb Eric Anholt: > This isn't the first time I've had to argue to myself why the '++' was > safe. And now you need to do the same thing with me... > Signed-off-by: Eric Anholt > --- > drivers/gpu/drm/v3d/v3d_fence.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/v3d/v3d_fence.c b/drivers/gpu/drm/v3d/v3d_fence.c > index bfe31a89668b..6265e9ab4a13 100644 > --- a/drivers/gpu/drm/v3d/v3d_fence.c > +++ b/drivers/gpu/drm/v3d/v3d_fence.c > @@ -3,6 +3,9 @@ > > #include "v3d_drv.h" > > +/* Note that V3D fences are created during v3d_job_run(), so we're > + * already implictly locked. > + */ I don't see where you would be locked in the job_run path. I think what you mean is that this path needs no locks, as it is driven by a single scheduler thread, right? Regards, Lucas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/v3d: Remove the bad signaled() implementation.
Am Dienstag, den 05.06.2018, 12:03 -0700 schrieb Eric Anholt:
> Since our seqno value comes from a counter associated with the GPU
> ring, not the entity (aka client), they'll be completed out of order.
> There's actually no need for this code at all, since we don't have
> enable_signaling() and thus DMA_FENCE_SIGNALED_BIT will be set before
> we could be called.
>
> Signed-off-by: Eric Anholt
Reviewed-by: Lucas Stach
> ---
> drivers/gpu/drm/v3d/v3d_drv.h | 1 -
> drivers/gpu/drm/v3d/v3d_fence.c | 13 -
> drivers/gpu/drm/v3d/v3d_gem.c | 7 ++-
> drivers/gpu/drm/v3d/v3d_irq.c | 3 ---
> 4 files changed, 6 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/v3d/v3d_drv.h
> b/drivers/gpu/drm/v3d/v3d_drv.h
> index 26005abd9c5d..f32ac8c98f37 100644
> --- a/drivers/gpu/drm/v3d/v3d_drv.h
> +++ b/drivers/gpu/drm/v3d/v3d_drv.h
> @@ -25,7 +25,6 @@ struct v3d_queue_state {
>
> u64 fence_context;
> u64 emit_seqno;
> - u64 finished_seqno;
> };
>
> struct v3d_dev {
> diff --git a/drivers/gpu/drm/v3d/v3d_fence.c
> b/drivers/gpu/drm/v3d/v3d_fence.c
> index 087d49c8cb12..bfe31a89668b 100644
> --- a/drivers/gpu/drm/v3d/v3d_fence.c
> +++ b/drivers/gpu/drm/v3d/v3d_fence.c
> @@ -40,19 +40,14 @@ static bool v3d_fence_enable_signaling(struct
> dma_fence *fence)
> return true;
> }
>
> -static bool v3d_fence_signaled(struct dma_fence *fence)
> -{
> - struct v3d_fence *f = to_v3d_fence(fence);
> - struct v3d_dev *v3d = to_v3d_dev(f->dev);
> -
> - return v3d->queue[f->queue].finished_seqno >= f->seqno;
> -}
> -
> const struct dma_fence_ops v3d_fence_ops = {
> .get_driver_name = v3d_fence_get_driver_name,
> .get_timeline_name = v3d_fence_get_timeline_name,
> .enable_signaling = v3d_fence_enable_signaling,
> - .signaled = v3d_fence_signaled,
> + /* Each of our fences gets signaled as complete by the IRQ
> + * handler, so we rely on the core's tracking of signaling.
> + */
> + .signaled = NULL,
> .wait = dma_fence_default_wait,
> .release = dma_fence_free,
> };
> diff --git a/drivers/gpu/drm/v3d/v3d_gem.c
> b/drivers/gpu/drm/v3d/v3d_gem.c
> index 9ea83bdb9a30..d06d6697e089 100644
> --- a/drivers/gpu/drm/v3d/v3d_gem.c
> +++ b/drivers/gpu/drm/v3d/v3d_gem.c
> @@ -657,17 +657,14 @@ void
> v3d_gem_destroy(struct drm_device *dev)
> {
> struct v3d_dev *v3d = to_v3d_dev(dev);
> - enum v3d_queue q;
>
> v3d_sched_fini(v3d);
>
> /* Waiting for exec to finish would need to be done before
> * unregistering V3D.
> */
> - for (q = 0; q < V3D_MAX_QUEUES; q++) {
> - WARN_ON(v3d->queue[q].emit_seqno !=
> - v3d->queue[q].finished_seqno);
> - }
> + WARN_ON(v3d->bin_job);
> + WARN_ON(v3d->render_job);
>
> drm_mm_takedown(>mm);
>
> diff --git a/drivers/gpu/drm/v3d/v3d_irq.c
> b/drivers/gpu/drm/v3d/v3d_irq.c
> index 77e1fa046c10..e07514eb11b5 100644
> --- a/drivers/gpu/drm/v3d/v3d_irq.c
> +++ b/drivers/gpu/drm/v3d/v3d_irq.c
> @@ -87,15 +87,12 @@ v3d_irq(int irq, void *arg)
> }
>
> if (intsts & V3D_INT_FLDONE) {
> - v3d->queue[V3D_BIN].finished_seqno++;
> dma_fence_signal(v3d->bin_job->bin.done_fence);
> status = IRQ_HANDLED;
> }
>
> if (intsts & V3D_INT_FRDONE) {
> - v3d->queue[V3D_RENDER].finished_seqno++;
> dma_fence_signal(v3d->render_job-
> >render.done_fence);
> -
> status = IRQ_HANDLED;
> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106856] amdgpu kernel warning playing vdpau videos
https://bugs.freedesktop.org/show_bug.cgi?id=106856 jorg...@cirsa.com changed: What|Removed |Added Resolution|WONTFIX |FIXED --- Comment #2 from jorg...@cirsa.com --- Thanks Christian for the info! I'll try it... This issues are fixed backporting changes to a LTS kernel version? I ask in order to check in a more recent 4.14 version instead of change to a new version... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105532] Broken map generation in Northgard game
https://bugs.freedesktop.org/show_bug.cgi?id=105532 --- Comment #2 from Nicolas Cannasse --- Hi, I'm Northgard technical director. We are creating buffers to draw various 2D shapes into textures for map generation. Then we download the textures from GPU to CPU for additional processing. These textures are then used to generate the landscape. For some reason unknown to us the textures generated in some case appears to be corrupted, resulting in these weird height maps. We haven't been able to investigate the issue in details atm. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106856] amdgpu kernel warning playing vdpau videos
https://bugs.freedesktop.org/show_bug.cgi?id=106856 Christian König changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #1 from Christian König --- Sounds like a known issue in kernel 4.14 to me. Please test with some newer kernel as well, probably best to test with Alex amd-staging-drm-next branch. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info
On 08.06.2018 00:50, Heiko Stuebner wrote: > Am Donnerstag, 7. Juni 2018, 23:10:20 CEST schrieb Brian Norris: >> Hi, >> >> I only have a little bit to add, but Heiko did solicit my opinion. > yep ... and I realized that I am/was way to attached to my (working) > endpoint-based thingy to really appreciate the other arguments ;-) > > And your DSI-related writings below, did provide some new thought- > directions for me, so thanks for that. > >> On Thu, Jun 07, 2018 at 03:25:18PM +0200, Heiko Stuebner wrote: >>> Am Donnerstag, 7. Juni 2018, 12:39:03 CEST schrieb Andrzej Hajda: On 07.06.2018 01:08, Heiko Stuebner wrote: > Am Mittwoch, 6. Juni 2018, 18:07:46 CEST schrieb Archit Taneja: >> On Wednesday 06 June 2018 04:16 PM, Heiko Stübner wrote: >>> Am Mittwoch, 6. Juni 2018, 12:21:16 CEST schrieb Archit Taneja: On Wednesday 06 June 2018 02:00 PM, Heiko Stübner wrote: > Am Mittwoch, 6. Juni 2018, 07:59:29 CEST schrieb Archit Taneja: >> On Monday 04 June 2018 05:47 PM, Heiko Stuebner wrote: >>> Am Donnerstag, 18. Januar 2018, 05:53:55 CEST schrieb Archit Taneja: Add binding info for peripherals that support dual-channel DSI. Add corresponding optional bindings for DSI host controllers that may be configured in this mode. Add an example of an I2C controlled device operating in dual-channel DSI mode. Signed-off-by: Archit Taneja >>> Looks like a great solution for that problem, so >>> Reviewed-by: Heiko Stuebner >>> >>> As I'm looking into that for my rk3399-scarlet device right now and >>> couldn't find this patchset in the kernel yet, is it planned to >>> merge or refresh these binding changes or were problems encountered. >>> >>> At least an Ack/Review from Rob seems to be missing. >> I forgot about these patches. Rob had reviewed the first one in >> the set the second one still needed an Ack. I'll post a v3 >> that adds the Reviewed-bys and fixes a small typo. > very nice ... because it looks like yesterday I managed to make the > Rockchip dsi work in dual mode following this. > > But one question came up, do you really want two input ports on the > panel > side? I.e. hardware-wise, I guess the panel will have one 8-lane or so > input thatonly gets split up on the soc side onto 2 dsi controllers? I think all dual DSI panels actually have 2 DSI controllers/parsers within them, one on each port. The MIPI DSI spec doesn't support 8 lanes. Also, the pixels coming out of the host are distributed among the lanes differently than what would have been the case with a 'theoretical' 8 lane receiver. Other than that, some dual DSI panels only accept DSI commands on the 'master' port, where as others expect the same command to be sent across both the ports. Therefore, I think it's better to represent dual DSI panels having 2 DSI input ports. Your DT looks good to me. >>> Hmm, that doesn't match up then ;-) ... as my dt uses 2 endpoints >>> in one port for the dsi-links. >> Sorry, I didn't notice you'd created two endpoints within a single port. >> >> I don't think I'm particular about 2 ports vs 1 port with 2 endpoints. >> They both seem okay to me as long as we follow it consistently. I'm >> myself not 100% sure of how to figure where one should prefer endpoints >> over ports. Maybe someone more familiar with the of graph bindings >> could comment here. Port should describe physical port, endpoint are used to describe multiple links to the same port. If the panel has two physical DSI interfaces it should use two ports. >>> That again leaves a bit of space for interpretation ;-) . >> Does it really? DSI maxes out at 4 lanes, so more than 4 lanes is >> clearly not a single standard port. Additionally, the code we're >> currently using in Chrome OS actually sends the same commands to each >> DSI separately (I'm not sure if it's actually required by the panels >> were using), so again, they are to some extent logically independent. >> >>> A dual-dsi display is probably pretty useless with only one controller >>> connected to it, as its 4 lanes cannot satisfy the required 8 lanes >>> of the panel. >> Probably, although technically you can usually display on half the >> screen, if you have only have 1 working DSI. >> >>> See [0] for current WIP panel addition. >>> [Was already on the lists but needs cleanup] >>> >>> >>> >>> [0] >>> https://github.com/mmind/linux-rockchip/commit/459bc1a1599377c2c5408724e82619a4602a953d#diff-5d6d6ddab4fd282102d23d2c02e835f8R381 >>> >>> >>> The issue I see with using ports and not endpoints for dual-dsi links >>> is with distinguishing
[Bug 106856] amdgpu kernel warning playing vdpau videos
https://bugs.freedesktop.org/show_bug.cgi?id=106856 Bug ID: 106856 Summary: amdgpu kernel warning playing vdpau videos Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: jorg...@cirsa.com QA Contact: dri-devel@lists.freedesktop.org Hi, I get the next dmesg trace playing an h264 video with a custom player using libmpv-0.28.0. I'm using a debian8 with a vanilla 4.14.24 kernel with the next packages built from a padoka ppa: mesa 18.1~git1803060730.237c9c~oibaf~x xserver-xorg-video-amdgpu 1.4.99+git1803011934.7854ac~oibaf~x The video is played ok, maybe be some slow downs, but this trace is generated [ 2865.187435] [ cut here ] [ 2865.187520] WARNING: CPU: 0 PID: 2284 at drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:1029 amdgpu_bo_gpu_offset+0x7e/0x90 [amdgpu] [ 2865.187521] Modules linked in: cfg80211 rfkill binfmt_misc nfsd auth_rpcgss oid_registry nfs_acl nfs lockd grace fscache sunrpc edac_mce_amd kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc evdev cdc_acm aesni_intel aes_x86_64 crypto_simd glue_helper cryptd amdgpu pcspkr snd_hda_codec_cirrus fam15h_power k10temp snd_hda_codec_hdmi snd_hda_codec_generic ttm snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep drm_kms_helper snd_pcm snd_timer video snd soundcore sp5100_tco drm i2c_piix4 shpchp acpi_cpufreq button fuse autofs4 ext4 crc16 mbcache jbd2 sg sd_mod hid_generic usbhid hid crc32c_intel ehci_pci ahci ehci_hcd sdhci_pci xhci_pci sdhci libahci xhci_hcd igb libata mmc_core i2c_algo_bit i2c_core usbcore scsi_mod dca ptp usb_common pps_core [ 2865.187577] CPU: 0 PID: 2284 Comm: amdgpu_cs:0 Not tainted 4.14.24 #1 [ 2865.187578] Hardware name: Default string Default string/GCM-B610-CS, BIOS R1.00.E1 08/01/2017 [ 2865.187579] task: 8803e6b2f180 task.stack: c9000be94000 [ 2865.187599] RIP: 0010:amdgpu_bo_gpu_offset+0x7e/0x90 [amdgpu] [ 2865.187600] RSP: 0018:c9000be97a68 EFLAGS: 00010246 [ 2865.187602] RAX: 8803eb4c3200 RBX: 8803eb797000 RCX: 8803eb797000 [ 2865.187603] RDX: c9000be97a80 RSI: 001053a0 RDI: 8803eb4c32e8 [ 2865.187604] RBP: 0001053a R08: 8803e9840b90 R09: 8803e9840ab8 [ 2865.187604] R10: 81f26b00 R11: 03f41000 R12: 880388445d80 [ 2865.187606] R13: 8803ba9e2ee0 R14: a06079e0 R15: 8803ba9f2460 [ 2865.187608] FS: 7fc14bc5b700() GS:8803fec0() knlGS: [ 2865.187609] CS: 0010 DS: ES: CR0: 80050033 [ 2865.187610] CR2: 019c4000 CR3: 000398f56000 CR4: 001406f0 [ 2865.187611] Call Trace: [ 2865.187640] amdgpu_uvd_cs_pass2+0x44/0x7d0 [amdgpu] [ 2865.187664] ? amdgpu_uvd_cs_pass1+0xf0/0xf0 [amdgpu] [ 2865.187685] amdgpu_uvd_cs_packets+0x153/0x170 [amdgpu] [ 2865.187706] amdgpu_uvd_ring_parse_cs+0xc9/0x140 [amdgpu] [ 2865.187726] amdgpu_cs_ioctl+0x106e/0x1a60 [amdgpu] [ 2865.187749] ? amdgpu_cs_find_mapping+0xa0/0xa0 [amdgpu] [ 2865.187764] drm_ioctl_kernel+0x65/0xb0 [drm] [ 2865.187773] drm_ioctl+0x2ce/0x380 [drm] [ 2865.187792] ? amdgpu_cs_find_mapping+0xa0/0xa0 [amdgpu] [ 2865.187797] ? update_curr+0xd8/0x130 [ 2865.187799] ? update_curr+0x5c/0x130 [ 2865.187815] amdgpu_drm_ioctl+0x46/0x80 [amdgpu] [ 2865.187826] do_vfs_ioctl+0x8b/0x5c0 [ 2865.187829] ? SyS_futex+0x71/0x170 [ 2865.187831] SyS_ioctl+0x76/0x90 [ 2865.187834] do_syscall_64+0x6c/0x1f0 [ 2865.187837] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 [ 2865.187839] RIP: 0033:0x7fc15e47abe7 [ 2865.187840] RSP: 002b:7fc14bc5abf8 EFLAGS: 0246 ORIG_RAX: 0010 [ 2865.187842] RAX: ffda RBX: 7fc14bc5ad18 RCX: 7fc15e47abe7 [ 2865.187843] RDX: 7fc14bc5ac60 RSI: c0186444 RDI: 0007 [ 2865.187844] RBP: 7fc14bc5ac60 R08: 7fc14bc5ad40 R09: 7fc14bc5ad18 [ 2865.187845] R10: 7fc14bc5ac40 R11: 0246 R12: c0186444 [ 2865.187845] R13: 0007 R14: 0002 R15: 0002 [ 2865.187847] Code: 75 ee 0f 0b 48 8b 83 08 02 00 00 5b c3 8b 93 b8 02 00 00 85 d2 75 c1 0f 0b eb bd 48 8b bf f8 00 00 00 e8 c6 d0 ff ff 84 c0 75 02 <0f> 0b 8b 83 b4 00 00 00 eb 90 0f 0b eb 8c 0f 0b eb ae 0f 1f 44 [ 2865.187874] ---[ end trace 0b523768a49ad76c ]--- [ 2865.187921] [ cut here ] [ 2865.187941] WARNING: CPU: 0 PID: 2284 at drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:1032 amdgpu_bo_gpu_offset+0x8c/0x90 [amdgpu] [ 2865.187946] Modules linked in: cfg80211 rfkill binfmt_misc nfsd auth_rpcgss oid_registry nfs_acl nfs lockd grace fscache sunrpc edac_mce_amd kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc evdev cdc_acm aesni_intel aes_x86_64 crypto_simd glue_helper
Re: [PATCH v4 9/9] drm/mediatek: Add support for mediatek SOC MT2712
Hi, CK:
On Mon, 2018-05-28 at 15:53 +0800, CK Hu wrote:
> Hi, Stu:
>
> Two inline comment.
>
> On Mon, 2018-05-28 at 14:38 +0800, Stu Hsieh wrote:
> > This patch add support for the Mediatek MT2712 DISP subsystem.
> > There are two OVL engine and three disp output in MT2712.
> >
> > Signed-off-by: Stu Hsieh
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 39
> > ++
> > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 38
> > +
> > 2 files changed, 77 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > index 8bfc0debd2c2..3b22b48a6022 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > @@ -61,6 +61,24 @@
> > #define MT8173_MUTEX_MOD_DISP_PWM1 24
> > #define MT8173_MUTEX_MOD_DISP_OD 25
> >
> > +#define MT2712_MUTEX_MOD_DISP_PWM2 10
> > +#define MT2712_MUTEX_MOD_DISP_OVL0 11
> > +#define MT2712_MUTEX_MOD_DISP_OVL1 12
> > +#define MT2712_MUTEX_MOD_DISP_RDMA013
> > +#define MT2712_MUTEX_MOD_DISP_RDMA114
> > +#define MT2712_MUTEX_MOD_DISP_RDMA215
> > +#define MT2712_MUTEX_MOD_DISP_WDMA016
> > +#define MT2712_MUTEX_MOD_DISP_WDMA117
> > +#define MT2712_MUTEX_MOD_DISP_COLOR0 18
> > +#define MT2712_MUTEX_MOD_DISP_COLOR1 19
> > +#define MT2712_MUTEX_MOD_DISP_AAL0 20
> > +#define MT2712_MUTEX_MOD_DISP_UFOE 22
> > +#define MT2712_MUTEX_MOD_DISP_PWM0 23
> > +#define MT2712_MUTEX_MOD_DISP_PWM1 24
> > +#define MT2712_MUTEX_MOD_DISP_OD0 25
> > +#define MT2712_MUTEX_MOD2_DISP_AAL133
> > +#define MT2712_MUTEX_MOD2_DISP_OD1 34
> > +
> > #define MT2701_MUTEX_MOD_DISP_OVL 3
> > #define MT2701_MUTEX_MOD_DISP_WDMA 6
> > #define MT2701_MUTEX_MOD_DISP_COLOR7
> > @@ -110,6 +128,26 @@ static const unsigned int
> > mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> > [DDP_COMPONENT_WDMA0] = MT2701_MUTEX_MOD_DISP_WDMA,
> > };
> >
> > +static const unsigned int mt2712_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> > + [DDP_COMPONENT_AAL0] = MT2712_MUTEX_MOD_DISP_AAL0,
> > + [DDP_COMPONENT_AAL1] = MT2712_MUTEX_MOD2_DISP_AAL1,
> > + [DDP_COMPONENT_COLOR0] = MT2712_MUTEX_MOD_DISP_COLOR0,
> > + [DDP_COMPONENT_COLOR1] = MT2712_MUTEX_MOD_DISP_COLOR1,
> > + [DDP_COMPONENT_OD0] = MT2712_MUTEX_MOD_DISP_OD0,
> > + [DDP_COMPONENT_OD1] = MT2712_MUTEX_MOD2_DISP_OD1,
> > + [DDP_COMPONENT_OVL0] = MT2712_MUTEX_MOD_DISP_OVL0,
> > + [DDP_COMPONENT_OVL1] = MT2712_MUTEX_MOD_DISP_OVL1,
> > + [DDP_COMPONENT_PWM0] = MT2712_MUTEX_MOD_DISP_PWM0,
> > + [DDP_COMPONENT_PWM1] = MT2712_MUTEX_MOD_DISP_PWM1,
> > + [DDP_COMPONENT_PWM2] = MT2712_MUTEX_MOD_DISP_PWM2,
> > + [DDP_COMPONENT_RDMA0] = MT2712_MUTEX_MOD_DISP_RDMA0,
> > + [DDP_COMPONENT_RDMA1] = MT2712_MUTEX_MOD_DISP_RDMA1,
> > + [DDP_COMPONENT_RDMA2] = MT2712_MUTEX_MOD_DISP_RDMA2,
> > + [DDP_COMPONENT_UFOE] = MT2712_MUTEX_MOD_DISP_UFOE,
> > + [DDP_COMPONENT_WDMA0] = MT2712_MUTEX_MOD_DISP_WDMA0,
> > + [DDP_COMPONENT_WDMA1] = MT2712_MUTEX_MOD_DISP_WDMA1,
> > +};
> > +
> > static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> > [DDP_COMPONENT_AAL0] = MT8173_MUTEX_MOD_DISP_AAL,
> > [DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
> > @@ -430,6 +468,7 @@ static int mtk_ddp_remove(struct platform_device *pdev)
> >
> > static const struct of_device_id ddp_driver_dt_match[] = {
> > { .compatible = "mediatek,mt2701-disp-mutex", .data = mt2701_mutex_mod},
> > + { .compatible = "mediatek,mt2712-disp-mutex", .data = mt2712_mutex_mod},
> > { .compatible = "mediatek,mt8173-disp-mutex", .data = mt8173_mutex_mod},
> > {},
> > };
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > index 3d279a299383..3a866e1d6af4 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > @@ -146,6 +146,32 @@ static const enum mtk_ddp_comp_id mt2701_mtk_ddp_ext[]
> > = {
> > DDP_COMPONENT_DPI0,
> > };
> >
> > +static const enum mtk_ddp_comp_id mt2712_mtk_ddp_main[] = {
> > + DDP_COMPONENT_OVL0,
> > + DDP_COMPONENT_COLOR0,
> > + DDP_COMPONENT_AAL0,
> > + DDP_COMPONENT_OD0,
> > + DDP_COMPONENT_RDMA0,
> > + DDP_COMPONENT_DPI0,
> > + DDP_COMPONENT_PWM0,
> > +};
> > +
> > +static const enum mtk_ddp_comp_id mt2712_mtk_ddp_ext[] = {
> > + DDP_COMPONENT_OVL1,
> > + DDP_COMPONENT_COLOR1,
> > + DDP_COMPONENT_AAL1,
> > + DDP_COMPONENT_OD1,
> > + DDP_COMPONENT_RDMA1,
> > + DDP_COMPONENT_DPI1,
>
> Where do you define DDP_COMPONENT_DPI1?
>
> > + DDP_COMPONENT_PWM1,
> > +};
> > +
> > +static const enum mtk_ddp_comp_id mt2712_mtk_ddp_third[] = {
> > + DDP_COMPONENT_RDMA2,
> > +
Re: [PATCH v4 8/9] drm/mediatek: add third ddp path
On Mon, 2018-05-28 at 15:47 +0800, CK Hu wrote:
> Hi, Stu:
>
> One inline comment.
>
> On Mon, 2018-05-28 at 14:38 +0800, Stu Hsieh wrote:
> > This patch create third crtc by third ddp path
> >
> > Signed-off-by: Stu Hsieh
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 3 +++
> > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 +
> > drivers/gpu/drm/mediatek/mtk_drm_drv.h | 7 +--
> > 3 files changed, 13 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > index 658b8dd45b83..2d6aa150a9ff 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > @@ -539,6 +539,9 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
> > int ret;
> > int i;
> >
> > + if (!path)
> > + return 0;
> > +
> > for (i = 0; i < path_len; i++) {
> > enum mtk_ddp_comp_id comp_id = path[i];
> > struct device_node *node;
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > index 08d5d0b47bfe..3d279a299383 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > @@ -232,6 +232,11 @@ static int mtk_drm_kms_init(struct drm_device *drm)
> > if (ret < 0)
> > goto err_component_unbind;
> >
> > + ret = mtk_drm_crtc_create(drm, private->data->third_path,
> > + private->data->third_len);
> > + if (ret < 0)
> > + goto err_component_unbind;
> > +
> > /* Use OVL device for all DMA memory allocations */
> > np = private->comp_node[private->data->main_path[0]] ?:
> > private->comp_node[private->data->ext_path[0]];
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> > b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> > index c3378c452c0a..d867e2683923 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> > @@ -17,8 +17,8 @@
> > #include
> > #include "mtk_drm_ddp_comp.h"
> >
> > -#define MAX_CRTC 2
> > -#define MAX_CONNECTOR 2
> > +#define MAX_CRTC 3
> > +#define MAX_CONNECTOR 3
>
> MAX_CONNECTOR is useless, maybe we just need to remove it in a clean up
> patch. Or you could keep its value.
ok
For this patch, I would keep its value.
Regards,
Stu
>
> Regards,
> CK
>
> >
> > struct device;
> > struct device_node;
> > @@ -33,6 +33,9 @@ struct mtk_mmsys_driver_data {
> > unsigned int main_len;
> > const enum mtk_ddp_comp_id *ext_path;
> > unsigned int ext_len;
> > + const enum mtk_ddp_comp_id *third_path;
> > + unsigned int third_len;
> > +
> > bool shadow_register;
> > };
> >
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 0/6] Add ChromeOS EC CEC Support
On 08/06/18 10:17, Neil Armstrong wrote: > Hi Hans, > > On 08/06/2018 09:53, Hans Verkuil wrote: >> On 06/01/2018 10:19 AM, Neil Armstrong wrote: >>> Hi All, >>> >>> The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support >>> through it's Embedded Controller, to enable the Linux CEC Core to >>> communicate >>> with it and get the CEC Physical Address from the correct HDMI Connector, >>> the >>> following must be added/changed: >>> - Add the CEC sub-device registration in the ChromeOS EC MFD Driver >>> - Add the CEC related commands and events definitions into the EC MFD driver >>> - Add a way to get a CEC notifier with it's (optional) connector name >>> - Add the CEC notifier to the i915 HDMI driver >>> - Add the proper ChromeOS EC CEC Driver >>> >>> The CEC notifier with the connector name is the tricky point, since even on >>> Device-Tree platforms, there is no way to distinguish between multiple HDMI >>> connectors from the same DRM driver. The solution I implemented is pretty >>> simple and only adds an optional connector name to eventually distinguish >>> an HDMI connector notifier from another if they share the same device. >> >> This looks good to me, which brings me to the next question: how to merge >> this? >> >> It touches on three subsystems (media, drm, mfd), so that makes this >> tricky. >> >> I think there are two options: either the whole series goes through the >> media tree, or patches 1+2 go through drm and 3-6 through media. If there >> is a high chance of conflicts in the mfd code, then it is also an option to >> have patches 3-6 go through the mfd subsystem. > > I think patches 3-6 should go in the mfd tree, Lee is used to handle this, > then I think the rest could go in the media tree. > > Lee, do you think it would be possible to have an immutable branch with > patches 3-6 ? > > Could we have an immutable branch from media tree with patch 1 to be merged in > the i915 tree for patch 2 ? > > Or patch 1+2 could me merged into the i915 tree and generate an immutable > branch I think patches 1+2 can just go to the i915 tree. The i915 driver changes often, so going through that tree makes sense. The cec-notifier code is unlikely to change, and I am fine with that patch going through i915. > for media to merge the mfd branch + patch 7 ? Patch 7? I only count 6? If 1+2 go through drm and 3-6 go through mfd, then media isn't affected at all. There is chance of a conflict when this is eventually pushed to mainline for the media Kconfig, but that's all. Regards, Hans > > Neil > >> >> Any opinions? >> >> Regards, >> >> Hans >> >>> >>> Feel free to comment this patchset ! >>> >>> Changes since v6: >>> - Added stable identifier comment in intel_display.h >>> - Renamed to cec_notifier in intel_hdmi.c/intel_drv.h >>> - Added Acked-by/Reviewed-By tags >>> >>> Changes since v5: >>> - Small fixups on include/linux/mfd/cros_ec_commands.h >>> - Fixed on cros-ec-cec driver accordingly >>> - Added Reviewed-By tags >>> >>> Changes since v4: >>> - Split patch 3 to move the mkbp event size change into a separate patch >>> >>> Changes since v3 (incorrectly reported as v2): >>> - Renamed "Chrome OS" to "ChromeOS" >>> - Updated cros_ec_commands.h new structs definitions to kernel doc format >>> - Added Reviewed-By tags >>> >>> Changes since v2: >>> - Add i915 port_identifier() and use this stable name as cec_notifier conn >>> name >>> - Fixed and cleaned up the CEC commands and events handling >>> - Rebased the CEC sub-device registration on top of Enric's serie >>> - Fixed comments typo on cec driver >>> - Protected the DMI match only with PCI and DMI Kconfigs >>> >>> Changes since v1: >>> - Added cec_notifier_put to intel_hdmi >>> - Fixed all small reported issues on the EC CEC driver >>> - Moved the cec_notifier_get out of the #if .. #else .. #endif >>> >>> Changes since RFC: >>> - Moved CEC sub-device registration after CEC commands and events >>> definitions patch >>> - Removed get_notifier_get_byname >>> - Added CEC_CORE select into i915 Kconfig >>> - Removed CEC driver fallback if notifier is not configured on HW, added >>> explicit warn >>> - Fixed CEC core return type on error >>> - Moved to cros-ec-cec media platform directory >>> - Use bus_find_device() to find the pci i915 device instead of >>> get_notifier_get_byname() >>> - Fix Logical Address setup >>> - Added comment about HW support >>> - Removed memset of msg structures >>> >>> Neil Armstrong (6): >>> media: cec-notifier: Get notifier by device and connector name >>> drm/i915: hdmi: add CEC notifier to intel_hdmi >>> mfd: cros-ec: Increase maximum mkbp event size >>> mfd: cros-ec: Introduce CEC commands and events definitions. >>> mfd: cros_ec_dev: Add CEC sub-device registration >>> media: platform: Add ChromeOS EC CEC driver >>> >>> drivers/gpu/drm/i915/Kconfig | 1 + >>> drivers/gpu/drm/i915/intel_display.h | 24 ++
Re: [PATCH v7 0/6] Add ChromeOS EC CEC Support
Hi Hans, On 08/06/2018 09:53, Hans Verkuil wrote: > On 06/01/2018 10:19 AM, Neil Armstrong wrote: >> Hi All, >> >> The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support >> through it's Embedded Controller, to enable the Linux CEC Core to communicate >> with it and get the CEC Physical Address from the correct HDMI Connector, the >> following must be added/changed: >> - Add the CEC sub-device registration in the ChromeOS EC MFD Driver >> - Add the CEC related commands and events definitions into the EC MFD driver >> - Add a way to get a CEC notifier with it's (optional) connector name >> - Add the CEC notifier to the i915 HDMI driver >> - Add the proper ChromeOS EC CEC Driver >> >> The CEC notifier with the connector name is the tricky point, since even on >> Device-Tree platforms, there is no way to distinguish between multiple HDMI >> connectors from the same DRM driver. The solution I implemented is pretty >> simple and only adds an optional connector name to eventually distinguish >> an HDMI connector notifier from another if they share the same device. > > This looks good to me, which brings me to the next question: how to merge > this? > > It touches on three subsystems (media, drm, mfd), so that makes this > tricky. > > I think there are two options: either the whole series goes through the > media tree, or patches 1+2 go through drm and 3-6 through media. If there > is a high chance of conflicts in the mfd code, then it is also an option to > have patches 3-6 go through the mfd subsystem. I think patches 3-6 should go in the mfd tree, Lee is used to handle this, then I think the rest could go in the media tree. Lee, do you think it would be possible to have an immutable branch with patches 3-6 ? Could we have an immutable branch from media tree with patch 1 to be merged in the i915 tree for patch 2 ? Or patch 1+2 could me merged into the i915 tree and generate an immutable branch for media to merge the mfd branch + patch 7 ? Neil > > Any opinions? > > Regards, > > Hans > >> >> Feel free to comment this patchset ! >> >> Changes since v6: >> - Added stable identifier comment in intel_display.h >> - Renamed to cec_notifier in intel_hdmi.c/intel_drv.h >> - Added Acked-by/Reviewed-By tags >> >> Changes since v5: >> - Small fixups on include/linux/mfd/cros_ec_commands.h >> - Fixed on cros-ec-cec driver accordingly >> - Added Reviewed-By tags >> >> Changes since v4: >> - Split patch 3 to move the mkbp event size change into a separate patch >> >> Changes since v3 (incorrectly reported as v2): >> - Renamed "Chrome OS" to "ChromeOS" >> - Updated cros_ec_commands.h new structs definitions to kernel doc format >> - Added Reviewed-By tags >> >> Changes since v2: >> - Add i915 port_identifier() and use this stable name as cec_notifier conn >> name >> - Fixed and cleaned up the CEC commands and events handling >> - Rebased the CEC sub-device registration on top of Enric's serie >> - Fixed comments typo on cec driver >> - Protected the DMI match only with PCI and DMI Kconfigs >> >> Changes since v1: >> - Added cec_notifier_put to intel_hdmi >> - Fixed all small reported issues on the EC CEC driver >> - Moved the cec_notifier_get out of the #if .. #else .. #endif >> >> Changes since RFC: >> - Moved CEC sub-device registration after CEC commands and events >> definitions patch >> - Removed get_notifier_get_byname >> - Added CEC_CORE select into i915 Kconfig >> - Removed CEC driver fallback if notifier is not configured on HW, added >> explicit warn >> - Fixed CEC core return type on error >> - Moved to cros-ec-cec media platform directory >> - Use bus_find_device() to find the pci i915 device instead of >> get_notifier_get_byname() >> - Fix Logical Address setup >> - Added comment about HW support >> - Removed memset of msg structures >> >> Neil Armstrong (6): >> media: cec-notifier: Get notifier by device and connector name >> drm/i915: hdmi: add CEC notifier to intel_hdmi >> mfd: cros-ec: Increase maximum mkbp event size >> mfd: cros-ec: Introduce CEC commands and events definitions. >> mfd: cros_ec_dev: Add CEC sub-device registration >> media: platform: Add ChromeOS EC CEC driver >> >> drivers/gpu/drm/i915/Kconfig | 1 + >> drivers/gpu/drm/i915/intel_display.h | 24 ++ >> drivers/gpu/drm/i915/intel_drv.h | 2 + >> drivers/gpu/drm/i915/intel_hdmi.c| 13 + >> drivers/media/cec/cec-notifier.c | 11 +- >> drivers/media/platform/Kconfig | 11 + >> drivers/media/platform/Makefile | 2 + >> drivers/media/platform/cros-ec-cec/Makefile | 1 + >> drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 347 >> +++ >> drivers/mfd/cros_ec_dev.c| 16 ++ >> drivers/platform/chrome/cros_ec_proto.c | 40 ++- >> include/linux/mfd/cros_ec.h | 2 +-
Re: [PATCH v7 0/6] Add ChromeOS EC CEC Support
On 06/01/2018 10:19 AM, Neil Armstrong wrote: > Hi All, > > The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support > through it's Embedded Controller, to enable the Linux CEC Core to communicate > with it and get the CEC Physical Address from the correct HDMI Connector, the > following must be added/changed: > - Add the CEC sub-device registration in the ChromeOS EC MFD Driver > - Add the CEC related commands and events definitions into the EC MFD driver > - Add a way to get a CEC notifier with it's (optional) connector name > - Add the CEC notifier to the i915 HDMI driver > - Add the proper ChromeOS EC CEC Driver > > The CEC notifier with the connector name is the tricky point, since even on > Device-Tree platforms, there is no way to distinguish between multiple HDMI > connectors from the same DRM driver. The solution I implemented is pretty > simple and only adds an optional connector name to eventually distinguish > an HDMI connector notifier from another if they share the same device. This looks good to me, which brings me to the next question: how to merge this? It touches on three subsystems (media, drm, mfd), so that makes this tricky. I think there are two options: either the whole series goes through the media tree, or patches 1+2 go through drm and 3-6 through media. If there is a high chance of conflicts in the mfd code, then it is also an option to have patches 3-6 go through the mfd subsystem. Any opinions? Regards, Hans > > Feel free to comment this patchset ! > > Changes since v6: > - Added stable identifier comment in intel_display.h > - Renamed to cec_notifier in intel_hdmi.c/intel_drv.h > - Added Acked-by/Reviewed-By tags > > Changes since v5: > - Small fixups on include/linux/mfd/cros_ec_commands.h > - Fixed on cros-ec-cec driver accordingly > - Added Reviewed-By tags > > Changes since v4: > - Split patch 3 to move the mkbp event size change into a separate patch > > Changes since v3 (incorrectly reported as v2): > - Renamed "Chrome OS" to "ChromeOS" > - Updated cros_ec_commands.h new structs definitions to kernel doc format > - Added Reviewed-By tags > > Changes since v2: > - Add i915 port_identifier() and use this stable name as cec_notifier conn > name > - Fixed and cleaned up the CEC commands and events handling > - Rebased the CEC sub-device registration on top of Enric's serie > - Fixed comments typo on cec driver > - Protected the DMI match only with PCI and DMI Kconfigs > > Changes since v1: > - Added cec_notifier_put to intel_hdmi > - Fixed all small reported issues on the EC CEC driver > - Moved the cec_notifier_get out of the #if .. #else .. #endif > > Changes since RFC: > - Moved CEC sub-device registration after CEC commands and events > definitions patch > - Removed get_notifier_get_byname > - Added CEC_CORE select into i915 Kconfig > - Removed CEC driver fallback if notifier is not configured on HW, added > explicit warn > - Fixed CEC core return type on error > - Moved to cros-ec-cec media platform directory > - Use bus_find_device() to find the pci i915 device instead of > get_notifier_get_byname() > - Fix Logical Address setup > - Added comment about HW support > - Removed memset of msg structures > > Neil Armstrong (6): > media: cec-notifier: Get notifier by device and connector name > drm/i915: hdmi: add CEC notifier to intel_hdmi > mfd: cros-ec: Increase maximum mkbp event size > mfd: cros-ec: Introduce CEC commands and events definitions. > mfd: cros_ec_dev: Add CEC sub-device registration > media: platform: Add ChromeOS EC CEC driver > > drivers/gpu/drm/i915/Kconfig | 1 + > drivers/gpu/drm/i915/intel_display.h | 24 ++ > drivers/gpu/drm/i915/intel_drv.h | 2 + > drivers/gpu/drm/i915/intel_hdmi.c| 13 + > drivers/media/cec/cec-notifier.c | 11 +- > drivers/media/platform/Kconfig | 11 + > drivers/media/platform/Makefile | 2 + > drivers/media/platform/cros-ec-cec/Makefile | 1 + > drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 347 > +++ > drivers/mfd/cros_ec_dev.c| 16 ++ > drivers/platform/chrome/cros_ec_proto.c | 40 ++- > include/linux/mfd/cros_ec.h | 2 +- > include/linux/mfd/cros_ec_commands.h | 100 +++ > include/media/cec-notifier.h | 27 +- > 14 files changed, 581 insertions(+), 16 deletions(-) > create mode 100644 drivers/media/platform/cros-ec-cec/Makefile > create mode 100644 drivers/media/platform/cros-ec-cec/cros-ec-cec.c > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199959] amdgpu, regression?: system freezes after resume
https://bugzilla.kernel.org/show_bug.cgi?id=199959 --- Comment #5 from Christian König (christian.koe...@amd.com) --- Ok, well that is interesting. Please provide the output of "sudo cat /proc/iomem" and "lspci -t -v -nn". In the meantime I will try to reproduce the issue here. -- 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 3/3] drm/bridge/sii8620: fix loops in EDID fetch logic
Hi Andrzej,
On 2018-01-15 18:33, Andrzej Hajda wrote:
> Function should constantly check if cable is connected and finish
> in finite time.
>
> Signed-off-by: Andrzej Hajda
Tested-by: Marek Szyprowski
> ---
> drivers/gpu/drm/bridge/sil-sii8620.c | 31 ---
> 1 file changed, 20 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
> b/drivers/gpu/drm/bridge/sil-sii8620.c
> index 7c46847fef18..f65e14836c0e 100644
> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
> @@ -801,6 +801,7 @@ static void sii8620_burst_rx_all(struct sii8620 *ctx)
> static void sii8620_fetch_edid(struct sii8620 *ctx)
> {
> u8 lm_ddc, ddc_cmd, int3, cbus;
> + unsigned long timeout;
> int fetched, i;
> int edid_len = EDID_LENGTH;
> u8 *edid;
> @@ -850,23 +851,31 @@ static void sii8620_fetch_edid(struct sii8620 *ctx)
> REG_DDC_CMD, ddc_cmd | VAL_DDC_CMD_ENH_DDC_READ_NO_ACK
> );
>
> - do {
> - int3 = sii8620_readb(ctx, REG_INTR3);
> + int3 = 0;
> + timeout = jiffies + msecs_to_jiffies(200);
> + for (;;) {
> cbus = sii8620_readb(ctx, REG_CBUS_STATUS);
> -
> - if (int3 & BIT_DDC_CMD_DONE)
> - break;
> -
> - if (!(cbus & BIT_CBUS_STATUS_CBUS_CONNECTED)) {
> + if (~cbus & BIT_CBUS_STATUS_CBUS_CONNECTED) {
> + kfree(edid);
> + edid = NULL;
> + goto end;
> + }
> + if (int3 & BIT_DDC_CMD_DONE) {
> + if (sii8620_readb(ctx, REG_DDC_DOUT_CNT)
> + >= FETCH_SIZE)
> + break;
> + } else {
> + int3 = sii8620_readb(ctx, REG_INTR3);
> + }
> + if (time_is_before_jiffies(timeout)) {
> + ctx->error = -ETIMEDOUT;
> + dev_err(ctx->dev, "timeout during EDID read\n");
> kfree(edid);
> edid = NULL;
> goto end;
> }
> - } while (1);
> -
> - sii8620_readb(ctx, REG_DDC_STATUS);
> - while (sii8620_readb(ctx, REG_DDC_DOUT_CNT) < FETCH_SIZE)
> usleep_range(10, 20);
> + }
>
> sii8620_read_buf(ctx, REG_DDC_DATA, edid + fetched, FETCH_SIZE);
> if (fetched + FETCH_SIZE == EDID_LENGTH) {
Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/bridge/sii8620: simplify hardware reset procedure
Hi Andrzej,
On 2018-06-08 08:04, Andrzej Hajda wrote:
> There is no need to flip reset pin twice. Also delays can be changed to
> values present in vendor's code.
>
> Signed-off-by: Andrzej Hajda
Tested-by: Marek Szyprowski
> ---
> Hi,
>
> This is v2 of forgotten patch, awaiting reviewers, any volunteers.
> Also "drm/bridge/sii8620: fix loops in EDID fetch logic" waits for reviewers.
>
> In this version I have completely removed reset function, and moved its body
> to sii8620_hw_on.
>
> Regards
> Andrzej
> ---
> drivers/gpu/drm/bridge/sil-sii8620.c | 23 ++-
> 1 file changed, 10 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
> b/drivers/gpu/drm/bridge/sil-sii8620.c
> index 7ab36042a822..d1e780fba4b6 100644
> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
> @@ -971,8 +971,17 @@ static int sii8620_hw_on(struct sii8620 *ctx)
> ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
> if (ret)
> return ret;
> +
> usleep_range(1, 2);
> - return clk_prepare_enable(ctx->clk_xtal);
> + ret = clk_prepare_enable(ctx->clk_xtal);
> + if (ret)
> + return ret;
> +
> + msleep(100);
> + gpiod_set_value(ctx->gpio_reset, 0);
> + msleep(100);
> +
> + return 0;
> }
>
> static int sii8620_hw_off(struct sii8620 *ctx)
> @@ -982,17 +991,6 @@ static int sii8620_hw_off(struct sii8620 *ctx)
> return regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
> }
>
> -static void sii8620_hw_reset(struct sii8620 *ctx)
> -{
> - usleep_range(1, 2);
> - gpiod_set_value(ctx->gpio_reset, 0);
> - usleep_range(5000, 2);
> - gpiod_set_value(ctx->gpio_reset, 1);
> - usleep_range(1, 2);
> - gpiod_set_value(ctx->gpio_reset, 0);
> - msleep(300);
> -}
> -
> static void sii8620_cbus_reset(struct sii8620 *ctx)
> {
> sii8620_write(ctx, REG_PWD_SRST, BIT_PWD_SRST_CBUS_RST
> @@ -2112,7 +2110,6 @@ static void sii8620_cable_in(struct sii8620 *ctx)
> dev_err(dev, "Error powering on, %d.\n", ret);
> return;
> }
> - sii8620_hw_reset(ctx);
>
> sii8620_read_buf(ctx, REG_VND_IDL, ver, ARRAY_SIZE(ver));
> ret = sii8620_clear_error(ctx);
Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] gpu: drm: omapdrm: Adding new typedef vm_fault_t
On Fri, Jun 1, 2018 at 11:11 AM, Souptick Joarder wrote:
> On Tue, May 22, 2018 at 11:43 PM, Souptick Joarder
> wrote:
>> Use new return type vm_fault_t for fault handler. For
>> now, this is just documenting that the function returns
>> a VM_FAULT value rather than an errno. Once all instances
>> are converted, vm_fault_t will become a distinct type.
>>
>> Ref-> commit 1c8f422059ae ("mm: change return type to vm_fault_t")
>>
>> Previously vm_insert_mixed() returns err which driver
>> mapped into VM_FAULT_* type. Also return value of
>> vm_insert_mixed() not handled correctly and 0 was
>> returned inside fault_2d() as default. The new function
>> vmf_insert_mixed() will replace this inefficiency by
>> returning correct VM_FAULT_* type.
>>
>> vmf_error() is the newly introduce inline function
>> in 4.17-rc6.
>>
>> Signed-off-by: Souptick Joarder
>> Reviewed-by: Matthew Wilcox
>> ---
>> v2: Fixed kbuild error by initialized ret
>> in fault_2d().
>>
>> drivers/gpu/drm/omapdrm/omap_gem.c | 51
>> +-
>> drivers/gpu/drm/omapdrm/omap_gem.h | 3 ++-
>> 2 files changed, 25 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
>> b/drivers/gpu/drm/omapdrm/omap_gem.c
>> index 0faf042..99e4300 100644
>> --- a/drivers/gpu/drm/omapdrm/omap_gem.c
>> +++ b/drivers/gpu/drm/omapdrm/omap_gem.c
>> @@ -371,7 +371,7 @@ size_t omap_gem_mmap_size(struct drm_gem_object *obj)
>> */
>>
>> /* Normal handling for the case of faulting in non-tiled buffers */
>> -static int fault_1d(struct drm_gem_object *obj,
>> +static vm_fault_t fault_1d(struct drm_gem_object *obj,
>> struct vm_area_struct *vma, struct vm_fault *vmf)
>> {
>> struct omap_gem_object *omap_obj = to_omap_bo(obj);
>> @@ -392,11 +392,12 @@ static int fault_1d(struct drm_gem_object *obj,
>> VERB("Inserting %p pfn %lx, pa %lx", (void *)vmf->address,
>> pfn, pfn << PAGE_SHIFT);
>>
>> - return vm_insert_mixed(vma, vmf->address, __pfn_to_pfn_t(pfn,
>> PFN_DEV));
>> + return vmf_insert_mixed(vma, vmf->address,
>> + __pfn_to_pfn_t(pfn, PFN_DEV));
>> }
>>
>> /* Special handling for the case of faulting in 2d tiled buffers */
>> -static int fault_2d(struct drm_gem_object *obj,
>> +static vm_fault_t fault_2d(struct drm_gem_object *obj,
>> struct vm_area_struct *vma, struct vm_fault *vmf)
>> {
>> struct omap_gem_object *omap_obj = to_omap_bo(obj);
>> @@ -407,7 +408,8 @@ static int fault_2d(struct drm_gem_object *obj,
>> unsigned long pfn;
>> pgoff_t pgoff, base_pgoff;
>> unsigned long vaddr;
>> - int i, ret, slots;
>> + int i, err, slots;
>> + vm_fault_t ret = VM_FAULT_NOPAGE;
>>
>> /*
>> * Note the height of the slot is also equal to the number of pages
>> @@ -473,9 +475,10 @@ static int fault_2d(struct drm_gem_object *obj,
>> memset(pages + slots, 0,
>> sizeof(struct page *) * (n - slots));
>>
>> - ret = tiler_pin(entry->block, pages, ARRAY_SIZE(pages), 0, true);
>> - if (ret) {
>> - dev_err(obj->dev->dev, "failed to pin: %d\n", ret);
>> + err = tiler_pin(entry->block, pages, ARRAY_SIZE(pages), 0, true);
>> + if (err) {
>> + ret = vmf_error(err);
>> + dev_err(obj->dev->dev, "failed to pin: %d\n", err);
>> return ret;
>> }
>>
>> @@ -485,7 +488,10 @@ static int fault_2d(struct drm_gem_object *obj,
>> pfn, pfn << PAGE_SHIFT);
>>
>> for (i = n; i > 0; i--) {
>> - vm_insert_mixed(vma, vaddr, __pfn_to_pfn_t(pfn, PFN_DEV));
>> + ret = vmf_insert_mixed(vma,
>> + vaddr, __pfn_to_pfn_t(pfn, PFN_DEV));
>> + if (ret & VM_FAULT_ERROR)
>> + break;
>> pfn += priv->usergart[fmt].stride_pfn;
>> vaddr += PAGE_SIZE * m;
>> }
>> @@ -494,7 +500,7 @@ static int fault_2d(struct drm_gem_object *obj,
>> priv->usergart[fmt].last = (priv->usergart[fmt].last + 1)
>> % NUM_USERGART_ENTRIES;
>>
>> - return 0;
>> + return ret;
>> }
>>
>> /**
>> @@ -509,14 +515,15 @@ static int fault_2d(struct drm_gem_object *obj,
>> * vma->vm_private_data points to the GEM object that is backing this
>> * mapping.
>> */
>> -int omap_gem_fault(struct vm_fault *vmf)
>> +vm_fault_t omap_gem_fault(struct vm_fault *vmf)
>> {
>> struct vm_area_struct *vma = vmf->vma;
>> struct drm_gem_object *obj = vma->vm_private_data;
>> struct omap_gem_object *omap_obj = to_omap_bo(obj);
>> struct drm_device *dev = obj->dev;
>> struct page **pages;
>> - int ret;
>> + int err;
>> + vm_fault_t ret;
>>
>> /* Make sure we don't parallel update on a fault, nor move or remove
>> *
Re: [Xen-devel] [PATCH v2 5/9] xen/gntdev: Allow mappings for DMA buffers
(Stefano, question for you at the end)
On 06/07/2018 02:39 AM, Oleksandr Andrushchenko wrote:
> On 06/07/2018 12:19 AM, Boris Ostrovsky wrote:
>> On 06/06/2018 04:14 AM, Oleksandr Andrushchenko wrote:
>>> On 06/04/2018 11:12 PM, Boris Ostrovsky wrote:
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
@@ -121,8 +146,27 @@ static void gntdev_free_map(struct grant_map
*map)
if (map == NULL)
return;
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
> *Option 1: kfree(map->frames);*
+ if (map->dma_vaddr) {
+ struct gnttab_dma_alloc_args args;
+
+ args.dev = map->dma_dev;
+ args.coherent = map->dma_flags & GNTDEV_DMA_FLAG_COHERENT;
+ args.nr_pages = map->count;
+ args.pages = map->pages;
+ args.frames = map->frames;
+ args.vaddr = map->dma_vaddr;
+ args.dev_bus_addr = map->dma_bus_addr;
+
+ gnttab_dma_free_pages();
> *Option 2: kfree(map->frames);*
+ } else
+#endif
if (map->pages)
gnttab_free_pages(map->count, map->pages);
+
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+ kfree(map->frames);
+#endif
Can this be done under if (map->dma_vaddr) ?
In other words, is it
possible for dma_vaddr to be NULL and still have unallocated frames
pointer?
>>> It is possible to have vaddr == NULL and frames != NULL as we
>>> allocate frames outside of gnttab_dma_alloc_pages which
>>> may fail. Calling kfree on NULL pointer is safe,
>>
>> I am not questioning safety of the code, I would like avoid another
>> ifdef.
> Ah, I now understand, so you are asking if we can have
> that kfree(map->frames); in the place *Option 2* I marked above.
> Unfortunately no: map->frames is allocated before we try to
> allocate DMA memory, e.g. before dma_vaddr is set:
> [...]
> add->frames = kcalloc(count, sizeof(add->frames[0]),
> GFP_KERNEL);
> if (!add->frames)
> goto err;
>
> [...]
> if (gnttab_dma_alloc_pages())
> goto err;
>
> add->dma_vaddr = args.vaddr;
> [...]
> err:
> gntdev_free_map(add);
>
> So, it is possible to enter gntdev_free_map with
> frames != NULL and dma_vaddr == NULL. Option 1 above cannot be used
> as map->frames is needed for gnttab_dma_free_pages();
> and Option 2 cannot be used as frames != NULL and dma_vaddr == NULL.
> Thus, I think that unfortunately we need that #ifdef.
> Option 3 below can also be considered, but that seems to be not good
> as we free resources in different places which looks inconsistent.
I was only thinking of option 2. But if it is possible to have frames !=
NULL and dma_vaddr == NULL then perhaps we indeed will have to live with
the extra ifdef.
>
> Sorry if I'm still missing your point.
>>
>>> so
>>> I see no reason to change this code.
> kfree(map->pages);
> kfree(map->grants);
> kfree(map->map_ops);
> @@ -132,7 +176,8 @@ static void gntdev_free_map(struct grant_map
> *map)
> kfree(map);
> }
> -static struct grant_map *gntdev_alloc_map(struct gntdev_priv
> *priv, int count)
> +static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv,
> int count,
> + int dma_flags)
> {
> struct grant_map *add;
> int i;
> @@ -155,6 +200,37 @@ static struct grant_map
> *gntdev_alloc_map(struct gntdev_priv *priv, int count)
> NULL == add->pages)
> goto err;
> +#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
> + add->dma_flags = dma_flags;
> +
> + /*
> + * Check if this mapping is requested to be backed
> + * by a DMA buffer.
> + */
> + if (dma_flags & (GNTDEV_DMA_FLAG_WC |
> GNTDEV_DMA_FLAG_COHERENT)) {
> + struct gnttab_dma_alloc_args args;
> +
> + add->frames = kcalloc(count, sizeof(add->frames[0]),
> + GFP_KERNEL);
> + if (!add->frames)
> + goto err;
> +
> + /* Remember the device, so we can free DMA memory. */
> + add->dma_dev = priv->dma_dev;
> +
> + args.dev = priv->dma_dev;
> + args.coherent = dma_flags & GNTDEV_DMA_FLAG_COHERENT;
> + args.nr_pages = count;
> + args.pages = add->pages;
> + args.frames = add->frames;
> +
> + if (gnttab_dma_alloc_pages())
> *Option 3: kfree(map->frames);*
> + goto err;
> +
> + add->dma_vaddr = args.vaddr;
> + add->dma_bus_addr = args.dev_bus_addr;
> + } else
> +#endif
> if (gnttab_alloc_pages(count, add->pages))
> goto err;
> @@ -325,6 +401,14 @@ static int map_grant_pages(struct grant_map
> *map)
> map->unmap_ops[i].handle = map->map_ops[i].handle;
Re: [PATCH v2] gpu: drm: ttm: Adding new return type vm_fault_t
On Sat, Jun 2, 2018 at 12:57 AM, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler. For
> now, this is just documenting that the function returns
> a VM_FAULT value rather than an errno. Once all instances
> are converted, vm_fault_t will become a distinct type.
>
> Ref-> commit 1c8f422059ae ("mm: change return type to vm_fault_t")
>
> Previously vm_insert_{mixed,pfn} returns err which driver
> mapped into VM_FAULT_* type. The new function
> vmf_insert_{mixed,pfn} will replace this inefficiency by
> returning VM_FAULT_* type.
>
> Signed-off-by: Souptick Joarder
> ---
> v2: Address christian's comment. Put reverse
> xmas tree order for variable declarations.
>
> drivers/gpu/drm/ttm/ttm_bo_vm.c | 45
> -
> 1 file changed, 22 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> index 8eba95b..9de8b4f 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> @@ -43,10 +43,11 @@
>
> #define TTM_BO_VM_NUM_PREFAULT 16
>
> -static int ttm_bo_vm_fault_idle(struct ttm_buffer_object *bo,
> +static vm_fault_t ttm_bo_vm_fault_idle(struct ttm_buffer_object *bo,
> struct vm_fault *vmf)
> {
> - int ret = 0;
> + vm_fault_t ret = 0;
> + int err = 0;
>
> if (likely(!bo->moving))
> goto out_unlock;
> @@ -77,9 +78,9 @@ static int ttm_bo_vm_fault_idle(struct ttm_buffer_object
> *bo,
> /*
> * Ordinary wait.
> */
> - ret = dma_fence_wait(bo->moving, true);
> - if (unlikely(ret != 0)) {
> - ret = (ret != -ERESTARTSYS) ? VM_FAULT_SIGBUS :
> + err = dma_fence_wait(bo->moving, true);
> + if (unlikely(err != 0)) {
> + ret = (err != -ERESTARTSYS) ? VM_FAULT_SIGBUS :
> VM_FAULT_NOPAGE;
> goto out_unlock;
> }
> @@ -104,7 +105,7 @@ static unsigned long ttm_bo_io_mem_pfn(struct
> ttm_buffer_object *bo,
> + page_offset;
> }
>
> -static int ttm_bo_vm_fault(struct vm_fault *vmf)
> +static vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
> {
> struct vm_area_struct *vma = vmf->vma;
> struct ttm_buffer_object *bo = (struct ttm_buffer_object *)
> @@ -115,8 +116,9 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
> unsigned long pfn;
> struct ttm_tt *ttm = NULL;
> struct page *page;
> - int ret;
> + int err;
> int i;
> + vm_fault_t ret = VM_FAULT_NOPAGE;
> unsigned long address = vmf->address;
> struct ttm_mem_type_manager *man =
> >man[bo->mem.mem_type];
> @@ -128,9 +130,9 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
> * for reserve, and if it fails, retry the fault after waiting
> * for the buffer to become unreserved.
> */
> - ret = ttm_bo_reserve(bo, true, true, NULL);
> - if (unlikely(ret != 0)) {
> - if (ret != -EBUSY)
> + err = ttm_bo_reserve(bo, true, true, NULL);
> + if (unlikely(err != 0)) {
> + if (err != -EBUSY)
> return VM_FAULT_NOPAGE;
>
> if (vmf->flags & FAULT_FLAG_ALLOW_RETRY) {
> @@ -162,8 +164,8 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
> }
>
> if (bdev->driver->fault_reserve_notify) {
> - ret = bdev->driver->fault_reserve_notify(bo);
> - switch (ret) {
> + err = bdev->driver->fault_reserve_notify(bo);
> + switch (err) {
> case 0:
> break;
> case -EBUSY:
> @@ -191,13 +193,13 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
> goto out_unlock;
> }
>
> - ret = ttm_mem_io_lock(man, true);
> - if (unlikely(ret != 0)) {
> + err = ttm_mem_io_lock(man, true);
> + if (unlikely(err != 0)) {
> ret = VM_FAULT_NOPAGE;
> goto out_unlock;
> }
> - ret = ttm_mem_io_reserve_vm(bo);
> - if (unlikely(ret != 0)) {
> + err = ttm_mem_io_reserve_vm(bo);
> + if (unlikely(err != 0)) {
> ret = VM_FAULT_SIGBUS;
> goto out_io_unlock;
> }
> @@ -265,23 +267,20 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
> }
>
> if (vma->vm_flags & VM_MIXEDMAP)
> - ret = vm_insert_mixed(, address,
> + ret = vmf_insert_mixed(, address,
> __pfn_to_pfn_t(pfn, PFN_DEV));
> else
> - ret = vm_insert_pfn(, address, pfn);
> + ret = vmf_insert_pfn(, address, pfn);
>
> /*
> * Somebody beat us to this PTE or prefaulting to
> * an already populated PTE, or
Re: Kernel and ADM hardware roulette ( was AMD graphics performance regression in 4.15 and later )
2018-06-07 9:07 GMT+02:00 Christian König :
> Am 06.06.2018 um 17:44 schrieb Gabriel C:
>>
>> 2018-06-06 17:03 GMT+02:00 Michel Dänzer :
>>>
>>> On 2018-06-06 04:44 PM, Christian König wrote:
Am 06.06.2018 um 16:12 schrieb Michel Dänzer:
[SNIP]
At least in theory it should work when we use the coherent DMA
allocator.
When that really worked before, so the most likely commit which broke
this is:
commit fd5fd480dd8fe4910546e7b080b3ae345e57fe9f
Author: Chunming Zhou
Date: Fri Feb 9 10:44:09 2018 +0800
drm/amdgpu: only enable swiotlb alloc when need v2
get the max io mapping address of system memory to see if it is
over
our card accessing range.
v2: move checking later
Signed-off-by: Chunming Zhou
Reviewed-by: Monk Liu
Reviewed-by: Christian König
Signed-off-by: Alex Deucher
Currently looking into how we could somehow improve this detection.
>>>
>>> I guess this could fit for Gabriel, but e.g.
>>> https://bugs.freedesktop.org/104437 says amdgpu was already broken with
>>> SME in 4.15, if not 4.14 (I suspect there was simply no SME support
>>> earlier).
>
>
> And what I totally missed is that Gabriel is using radeon and not amdgpu.
>
> So Gabriel you need to revert this one for testing:
> commit 1bc3d3cce8c3b44c2b5ac6cee98c830bb40e6b0f
> Author: Chunming Zhou
> Date: Fri Feb 9 10:44:10 2018 +0800
>
> drm/radeon: only enable swiotlb path when need v2
>
> swiotlb expands our card accessing range, but its path always is slower
> than ttm pool allocation.
> So add condition to use it.
> v2: move a bit later
>
> Signed-off-by: Chunming Zhou
> Reviewed-by: Monk Liu
> Reviewed-by: Christian König
> Signed-off-by: Alex Deucher
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20180209024410.1469-3-david1.z...@amd.com
>
>> I got strange performance issue with 4.15 and 4.16 .. but SME was ON
>> on that setup ( even before it hit mainline ) and never broke the GPU like
>> this.
>
>
> Well that is very interesting, you are the first one who reports that SME +
> GFX works in some way. So far we only got negative reports for that.
>
>> There is a 4.16.13 boot dmesg which has no such issue:
>>
>>
>> http://ftp.frugalware.org/pub/other/people/crazy/radeon/dmesg-radeon-SME-ON-kernel-4.16.txt
>>
>> With the setup as is booting 4.16.x works , while 4.17 trows the errors.
>
>
> Please do the bisect if the patch I've mentioned above doesn't help.
Ok done.. bisect points to:
b468620f2a1dfdcfddfd6fa54367b8bcc1b51248 is the first bad commit
commit b468620f2a1dfdcfddfd6fa54367b8bcc1b51248
Author: Christoph Hellwig
Date: Mon Mar 19 11:38:19 2018 +0100
iommu/amd_iommu: Use CONFIG_DMA_DIRECT_OPS=y and dma_direct_{alloc,free}()
This cleans up the code a lot by removing duplicate logic.
Tested-by: Tom Lendacky
Tested-by: Joerg Roedel
Signed-off-by: Christoph Hellwig
Reviewed-by: Thomas Gleixner
Acked-by: Joerg Roedel
Cc: David Woodhouse
Cc: Joerg Roedel
Cc: Jon Mason
Cc: Konrad Rzeszutek Wilk
Cc: Linus Torvalds
Cc: Muli Ben-Yehuda
Cc: Peter Zijlstra
Cc: io...@lists.linux-foundation.org
Link: http://lkml.kernel.org/r/20180319103826.12853-8-...@lst.de
Signed-off-by: Ingo Molnar
I'll try to revert this once I'm home.
BR
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Problem with VIV_FE_DRAW_2D_HEADER_DATA_COUNT
Hi Lucas, Here you can find the test I used (actually pretty the same as your) : https://github.com/julbouln/test_omap5_drm/blob/master/test_viv2d.c#L472 And my fix that make it works : https://github.com/julbouln/etnaviv_x15/blob/master/etnaviv_cmd_parser.c#L182 (sorry it is kernel 4.9) As a side question, did you ever managed to get multi source working by any chance ? I tried without success. Regards 2018-06-04 12:32 GMT+02:00 Julien Boulnois : > Hi Lucas, > > Not yet, I was looking the possibility of using it when I found this > limitation. > > Regards > > 2018-06-04 11:19 GMT+02:00 Lucas Stach : > >> Hi Julien, >> >> Am Freitag, den 01.06.2018, 09:00 +0200 schrieb Julien Boulnois: >> > Hi Lucas, >> > >> > I think I found an issue in etnaviv kernel driver regarding >> > VIV_FE_DRAW_2D_HEADER_DATA_COUNT >> > >> > In your old test >> > https://github.com/etnaviv/etna_viv/blob/master/attic/test2d/bitblt2d >> > _from_stream.c you append streamed data at the end of draw command >> > buffer, but driver gives an error : >> > etnaviv_cmd_validate_one: op 21 not permitted at offset 50 >> > >> > After looking closer, I think that FE_OPCODE_DRAW_2D check in >> > etnaviv_cmd_parser.c#etnaviv_cmd_validate_one should take account of >> > these extra data : >> > >> > case FE_OPCODE_DRAW_2D: >> > n = EXTRACT(cmd, VIV_FE_DRAW_2D_HEADER_COUNT) * 2 + >> > EXTRACT(cmd, VIV_FE_DRAW_2D_HEADER_DATA_COUNT); >> > if (n == 0) >> > n = 256; >> > len = 2 + n; >> > break; >> >> Yes, the kernel command parser is a bit too conservative here. Are you >> using the streamed data feature in your driver? >> >> Regards, >> Lucas >> > > > > -- > Julien Boulnois > -- Julien Boulnois ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 7/9] xen/gntdev: Implement dma-buf export functionality
On 06/07/2018 04:44 AM, Oleksandr Andrushchenko wrote:
> On 06/07/2018 12:48 AM, Boris Ostrovsky wrote:
>> On 06/06/2018 08:10 AM, Oleksandr Andrushchenko wrote:
>>> On 06/05/2018 01:07 AM, Boris Ostrovsky wrote:
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
>>
+
+static struct sg_table *
+dmabuf_exp_ops_map_dma_buf(struct dma_buf_attachment *attach,
+ enum dma_data_direction dir)
+{
+ struct gntdev_dmabuf_attachment *gntdev_dmabuf_attach =
attach->priv;
+ struct gntdev_dmabuf *gntdev_dmabuf = attach->dmabuf->priv;
+ struct sg_table *sgt;
+
+ pr_debug("Mapping %d pages for dev %p\n",
gntdev_dmabuf->nr_pages,
+ attach->dev);
+
+ if (WARN_ON(dir == DMA_NONE || !gntdev_dmabuf_attach))
WARN_ON_ONCE. Here and elsewhere.
>>> Why? The UAPI may be used by different applications, thus we might
>>> lose warnings for some of them. Having WARN_ON will show problems
>>> for multiple users, not for the first one.
>>> Does this make sense to still use WARN_ON?
>>
>> Just as with pr_err call somewhere else the concern here is that
>> userland (which I think is where this is eventually called from?) may
>> intentionally trigger the error, flooding the log.
>>
>> And even this is not directly called from userland there is still a
>> possibility of triggering this error multiple times.
> Ok, will use WARN_ON_ONCE
In fact, is there a reason to use WARN at all? Does this condition
indicate some sort of internal inconsistency/error?
-boris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: [PATCH 06/15] drm/sun4i: tcon: Add support for tcon-top
Dne četrtek, 07. junij 2018 ob 00:30:24 CEST je Jernej Škrabec napisal(a):
> Dne ponedeljek, 04. junij 2018 ob 18:23:57 CEST je Maxime Ripard napisal(a):
> > On Mon, Jun 04, 2018 at 05:09:56PM +0200, Jernej Škrabec wrote:
> > > Dne ponedeljek, 04. junij 2018 ob 13:50:34 CEST je Maxime Ripard
>
> napisal(a):
> > > > On Fri, Jun 01, 2018 at 09:19:43AM -0700, Chen-Yu Tsai wrote:
> > > > > On Fri, Jun 1, 2018 at 8:29 AM, Maxime Ripard
> > > > >
> > >
> > > wrote:
> > > > > > On Thu, May 31, 2018 at 07:54:08PM +0200, Jernej Škrabec wrote:
> > > > > >> Dne četrtek, 31. maj 2018 ob 11:21:33 CEST je Maxime Ripard
>
> napisal(a):
> > > > > >> > On Thu, May 24, 2018 at 03:01:09PM -0700, Chen-Yu Tsai wrote:
> > > > > >> > > >> > > + if (tcon->quirks->needs_tcon_top) {
> > > > > >> > > >> > > + struct device_node *np;
> > > > > >> > > >> > > +
> > > > > >> > > >> > > + np = of_parse_phandle(dev->of_node,
> > > > > >> > > >> > > "allwinner,tcon-top",
> > > > > >> > > >> > > 0);
> > > > > >> > > >> > > + if (np) {
> > > > > >> > > >> > > + struct platform_device *pdev;
> > > > > >> > > >> > > +
> > > > > >> > > >> > > + pdev = of_find_device_by_node(np);
> > > > > >> > > >> > > + if (pdev)
> > > > > >> > > >> > > + tcon->tcon_top =
> > > > > >> > > >> > > platform_get_drvdata(pdev);
> > > > > >> > > >> > > + of_node_put(np);
> > > > > >> > > >> > > +
> > > > > >> > > >> > > + if (!tcon->tcon_top)
> > > > > >> > > >> > > + return -EPROBE_DEFER;
> > > > > >> > > >> > > + }
> > > > > >> > > >> > > + }
> > > > > >> > > >> > > +
> > > > > >> > > >> >
> > > > > >> > > >> > I might have missed it, but I've not seen the bindings
> > > > > >> > > >> > additions for
> > > > > >> > > >> > that property. This shouldn't really be done that way
> > > > > >> > > >> > anyway,
> > > > > >> > > >> > instead
> > > > > >> > > >> > of using a direct phandle, you should be using the
> > > > > >> > > >> > of-graph,
> > > > > >> > > >> > with the
> > > > > >> > > >> > TCON-top sitting where it belongs in the flow of data.
> > > > > >> > > >>
> > > > > >> > > >> Just to answer to the first question, it did describe it
> > > > > >> > > >> in
> > > > > >> > > >> "[PATCH
> > > > > >> > > >> 07/15] dt- bindings: display: sun4i-drm: Add R40 HDMI
> > > > > >> > > >> pipeline".
> > > > > >> > > >>
> > > > > >> > > >> As why I designed it that way - HW representation could be
> > > > > >> > > >> described
> > > > > >> > > >> that way> >>
> > > > > >> > > >>
> > > > > >> > > >> (ASCII art makes sense when fixed width font is used to
> > > > > >> > > >> view
> > >
> > > it):
> > > > > >> > > >> / LCD0/LVDS0
> > > > > >> > > >>
> > > > > >> > > >> / TCON-LCD0
> > > > > >> > > >>
> > > > > >> > > >> | \ MIPI DSI
> > > > > >> > > >>
> > > > > >> > > >> mixer0 |
> > > > > >> > > >>
> > > > > >> > > >>\/ TCON-LCD1 - LCD1/LVDS1
> > > > > >> > > >>
> > > > > >> > > >> TCON-TOP
> > > > > >> > > >>
> > > > > >> > > >>/\ TCON-TV0 - TVE0/RGB
> > > > > >> > > >>
> > > > > >> > > >> mixer1 | \
> > > > > >> > > >>
> > > > > >> > > >> | TCON-TOP - HDMI
> > > > > >> > > >> |
> > > > > >> > > >> | /
> > > > > >> > > >>
> > > > > >> > > >> \ TCON-TV1 - TVE1/RGB
> > > > > >> > > >>
> > > > > >> > > >> This is a bit simplified, since there is also TVE-TOP,
> > > > > >> > > >> which
> > > > > >> > > >> is
> > > > > >> > > >> responsible
> > > > > >> > > >> for sharing 4 DACs between both TVE encoders. You can have
> > > > > >> > > >> two
> > > > > >> > > >> TV outs
> > > > > >> > > >> (PAL/ NTSC) or TVE0 as TV out and TVE1 as RGB or vice
> > > > > >> > > >> versa.
> > > > > >> > > >> It
> > > > > >> > > >> even
> > > > > >> > > >> seems that you can arbitrarly choose which DAC is
> > > > > >> > > >> responsible
> > > > > >> > > >> for
> > > > > >> > > >> which signal, so there is a ton of possible end
> > > > > >> > > >> combinations,
> > > > > >> > > >> but I'm
> > > > > >> > > >> not 100% sure.
> > > > > >> > > >>
> > > > > >> > > >> Even though I wrote TCON-TOP twice, this is same unit in
> > > > > >> > > >> HW.
> > > > > >> > > >> R40
> > > > > >> > > >> manual
> > > > > >> > > >> suggest more possibilities, although some of them seem
> > > > > >> > > >> wrong,
> > > > > >> > > >> like RGB
> > > > > >> > > >> feeding from LCD TCON. That is confirmed to be wrong when
> > > > > >> > > >> checking BSP
> > > > > >> > > >> code.
> > > > > >> > > >>
> > > > > >> > > >> Additionally, TCON-TOP comes in the middle of TVE0 and
> > > > > >> > > >> LCD0,
> > > > > >> > > >> TVE1 and
> > > > > >> > > >> LCD1 for pin
[PATCH v2 1/4] drm/panel: simple: Add support for Rocktech RK070ER9427 LCD panel
This adds support for the Rocktech Display Ltd. RK070ER9427
800(RGB)x480 TFT LCD panel, which can be supported by the
simple panel driver.
Signed-off-by: Jagan Teki
Reviewed-by: Rob Herring
---
Changes for v2:
- collect Rob r-w-b tag
.../display/panel/rocktech,rk070er9427.txt | 25
drivers/gpu/drm/panel/panel-simple.c | 33 ++
2 files changed, 58 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/rocktech,rk070er9427.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/rocktech,rk070er9427.txt
b/Documentation/devicetree/bindings/display/panel/rocktech,rk070er9427.txt
new file mode 100644
index ..eb1fb9f8d1f4
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/rocktech,rk070er9427.txt
@@ -0,0 +1,25 @@
+Rocktech Display Ltd. RK070ER9427 800(RGB)x480 TFT LCD panel
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
+
+Required properties:
+- compatible: should be "rocktech,rk070er9427"
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+
+Optional nodes:
+- Video port for LCD panel input.
+
+Example:
+ panel {
+ compatible = "rocktech,rk070er9427";
+ backlight = <_lcd>;
+
+ port {
+ lcd_panel_in: endpoint {
+ remote-endpoint = <_display_out>;
+ };
+ };
+ };
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index cbf1ab404ee7..a6c633fd0559 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -745,6 +745,36 @@ static const struct panel_desc avic_tm070ddh03 = {
},
};
+static const struct display_timing rocktech_rk070er9427_timing = {
+ .pixelclock = { 2640, 3330, 4680 },
+ .hactive = { 800, 800, 800 },
+ .hfront_porch = { 16, 210, 354 },
+ .hback_porch = { 46, 46, 46 },
+ .hsync_len = { 1, 1, 1 },
+ .vactive = { 480, 480, 480 },
+ .vfront_porch = { 7, 22, 147 },
+ .vback_porch = { 23, 23, 23 },
+ .vsync_len = { 1, 1, 1 },
+ .flags = DISPLAY_FLAGS_DE_HIGH,
+};
+
+static const struct panel_desc rocktech_rk070er9427 = {
+ .timings = _rk070er9427_timing,
+ .num_timings = 1,
+ .bpc = 6,
+ .size = {
+ .width = 154,
+ .height = 86,
+ },
+ .delay = {
+ .prepare = 41,
+ .enable = 50,
+ .unprepare = 41,
+ .disable = 50,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+};
+
static const struct drm_display_mode boe_nv101wxmn51_modes[] = {
{
.clock = 71900,
@@ -2226,6 +2256,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "qiaodian,qd43003c0-40",
.data = _40,
+ }, {
+ .compatible = "rocktech,rk070er9427",
+ .data = _rk070er9427,
}, {
.compatible = "samsung,lsn122dl01-c01",
.data = _lsn122dl01_c01,
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/9] xen/gntdev: Add initial support for dma-buf UAPI
On 06/07/2018 03:17 AM, Oleksandr Andrushchenko wrote: > On 06/07/2018 12:32 AM, Boris Ostrovsky wrote: >> On 06/06/2018 05:06 AM, Oleksandr Andrushchenko wrote: >>> On 06/04/2018 11:49 PM, Boris Ostrovsky wrote: > diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c > index 9813fc440c70..7d58dfb3e5e8 100644 > --- a/drivers/xen/gntdev.c > +++ b/drivers/xen/gntdev.c ... > +#ifdef CONFIG_XEN_GNTDEV_DMABUF This code belongs in gntdev-dmabuf.c. >>> The reason I have this code here is that it is heavily >>> tied to gntdev's internal functionality, e.g. map/unmap. >>> I do not want to extend gntdev's API, so gntdev-dmabuf can >>> access these. What is more dma-buf doesn't need to know about >>> maps done by gntdev as there is no use of that information >>> in gntdev-dmabuf. So, it seems more naturally to have >>> dma-buf's related map/unmap code where it is: in gntdev. >> Sorry, I don't follow. Why would this require extending the API? It's >> just moving routines to a different file that is linked to the same >> module. > I do understand your intention here and tried to avoid dma-buf > related code in gntdev.c as much as possible. So, let me explain > my decision in more detail. > > There are 2 use-cases we have: dma-buf import and export. > > While importing a dma-buf all the dma-buf related functionality can > easily be kept inside gntdev-dmabuf.c w/o any issue as all we need > from gntdev.c is dev, dma_buf_fd, count and domid for that. > > But in case of dma-buf export we need to: > 1. struct grant_map *map = gntdev_alloc_map(priv, count, dmabuf_flags); > 2. gntdev_add_map(priv, map); > 3. Set map->flags > 4. ret = map_grant_pages(map); > 5. And only now we are all set to export the new dma-buf from > *map->pages* > > So, until 5) we use private gtndev.c's API not exported to outside world: > a. struct grant_map > b. static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, > int count, > int dma_flags) > c. static void gntdev_add_map(struct gntdev_priv *priv, struct > grant_map *add) > d. static int map_grant_pages(struct grant_map *map) > > Thus, all the above cannot be accessed from gntdev-dmabuf.c > This is why I say that gntdev.c's API will need to be extended to > provide the above > a-d if we want all dma-buf export code to leave in gntdev-dmabuf.c. I still don't understand why you feel this would be extending the API. These routines and the struct can be declared in local header file and this header file will not be visible to anyone but gntdev.c and gntdev-dmabuf.c. You can, for example, put this into gntdev-dmabuf.h (and then rename it to something else, like gntdev-common.h). > But that doesn't seem good to me and what is more a-d are really > gntdev.c's > functionality, not dma-buf's which only needs pages and doesn't really > care from > where those come. > That was the reason I partitioned export into 2 chunks: gntdev + > gntdev-dmabuf. > > You might also ask why importing side does Xen related things > (granting references+) > in gntdev-dmabuf, not gntdev so it is consistent with the dma-buf > exporter? > This is because importer uses grant-table's API which seems to be not > natural for gntdev.c, > so it can leave in gntdev-dmabuf.c which has a use-case for that, > while gntdev > remains the same. Yet another reason why this code should be moved: importing and exporting functionalities logically belong together. The fat that they are implemented using different methods is not relevant IMO. If you have code which is under ifdef CONFIG_GNTDEV_DMABUF and you have file called gntdev-dmabuf.c it sort of implies that this code should live in that file (unless that code is intertwined with other code, which is not the case here). -boris >> Since this is under CONFIG_XEN_GNTDEV_DMABUF then why shouldn't it be in >> gntdev-dmabuf.c? In my view that's the file where all dma-related >> "stuff" lives. > Agree, but IMO grant_map stuff for dma-buf importer is right in its > place in gntdev.c > and all the rest of dma-buf specifics live in gntdev-dmabuf.c as they > should >> >> -boris >> >> >> -boris >> > Thank you, > Oleksandr ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Kernel and ADM hardware roulette ( was AMD graphics performance regression in 4.15 and later )
>> Well that is very interesting, you are the first one who reports that SME +
>> GFX works in some way. So far we only got negative reports for that.
>>
>>> There is a 4.16.13 boot dmesg which has no such issue:
>>>
>>>
>>> http://ftp.frugalware.org/pub/other/people/crazy/radeon/dmesg-radeon-SME-ON-kernel-4.16.txt
>>>
>>> With the setup as is booting 4.16.x works , while 4.17 trows the errors.
>>
>>
>> Please do the bisect if the patch I've mentioned above doesn't help.
>
> Ok done.. bisect points to:
>
> b468620f2a1dfdcfddfd6fa54367b8bcc1b51248 is the first bad commit
> commit b468620f2a1dfdcfddfd6fa54367b8bcc1b51248
> Author: Christoph Hellwig
> Date: Mon Mar 19 11:38:19 2018 +0100
>
>iommu/amd_iommu: Use CONFIG_DMA_DIRECT_OPS=y and dma_direct_{alloc,free}()
>
>This cleans up the code a lot by removing duplicate logic.
>
>Tested-by: Tom Lendacky
>Tested-by: Joerg Roedel
>Signed-off-by: Christoph Hellwig
>Reviewed-by: Thomas Gleixner
>Acked-by: Joerg Roedel
>Cc: David Woodhouse
>Cc: Joerg Roedel
>Cc: Jon Mason
>Cc: Konrad Rzeszutek Wilk
>Cc: Linus Torvalds
>Cc: Muli Ben-Yehuda
>Cc: Peter Zijlstra
>Cc: io...@lists.linux-foundation.org
>Link: http://lkml.kernel.org/r/20180319103826.12853-8-...@lst.de
>Signed-off-by: Ingo Molnar
>
>
> I'll try to revert this once I'm home.
I can confirm reverting b468620f2a1dfdcfddfd6fa54367b8bcc1b51248
fixes that issue for me.
The GPU is working fine with SME enabled.
Now with working GPU :) I can also confirm performance is back to normal
without doing any other workarounds.
The only app still acting up a bit is Firefox , just minor frame drops,
but nothing to bad. ( probably an Firefox bug too )
crhomium/chrome is fine .. even with 10 tabs open , each one playing
an video on youtube no glitches at all.
Desktop is also fine now, could not find anything wrong.
BR
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Kernel and ADM hardware roulette ( was AMD graphics performance regression in 4.15 and later )
Am 08.06.2018 um 08:02 schrieb Christoph Hellwig: On Thu, Jun 07, 2018 at 02:32:46PM +0200, Gabriel C wrote: Ok done.. bisect points to: What is the failure mode you are seeing? Can't find anything in the mail unfortunately. As far as I analyzed it we now get an -ENOMEM from dma_alloc_attrs() in drivers/gpu/drm/ttm/ttm_page_alloc_dma.c when IOMMU is enabled. Still need to figure out which parameters we want to use for the allocation, but I think it is only 4k or 8k. Regards, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Kernel and ADM hardware roulette ( was AMD graphics performance regression in 4.15 and later )
Hi Christoph, Am 08.06.2018 um 08:01 schrieb Christoph Hellwig: On Thu, Jun 07, 2018 at 07:20:37PM +0200, Christian König wrote: Hi Christopher, I don't see a Christopher on the Cc list.. Sorry, auto-uncorrection. I indeed meant you :) Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] gpu: drm: ttm: Adding new return type vm_fault_t
Am 08.06.2018 um 06:36 schrieb Souptick Joarder:
On Sat, Jun 2, 2018 at 12:57 AM, Souptick Joarder wrote:
Use new return type vm_fault_t for fault handler. For
now, this is just documenting that the function returns
a VM_FAULT value rather than an errno. Once all instances
are converted, vm_fault_t will become a distinct type.
Ref-> commit 1c8f422059ae ("mm: change return type to vm_fault_t")
Previously vm_insert_{mixed,pfn} returns err which driver
mapped into VM_FAULT_* type. The new function
vmf_insert_{mixed,pfn} will replace this inefficiency by
returning VM_FAULT_* type.
Signed-off-by: Souptick Joarder
---
v2: Address christian's comment. Put reverse
xmas tree order for variable declarations.
drivers/gpu/drm/ttm/ttm_bo_vm.c | 45 -
1 file changed, 22 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 8eba95b..9de8b4f 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -43,10 +43,11 @@
#define TTM_BO_VM_NUM_PREFAULT 16
-static int ttm_bo_vm_fault_idle(struct ttm_buffer_object *bo,
+static vm_fault_t ttm_bo_vm_fault_idle(struct ttm_buffer_object *bo,
struct vm_fault *vmf)
{
- int ret = 0;
+ vm_fault_t ret = 0;
+ int err = 0;
if (likely(!bo->moving))
goto out_unlock;
@@ -77,9 +78,9 @@ static int ttm_bo_vm_fault_idle(struct ttm_buffer_object *bo,
/*
* Ordinary wait.
*/
- ret = dma_fence_wait(bo->moving, true);
- if (unlikely(ret != 0)) {
- ret = (ret != -ERESTARTSYS) ? VM_FAULT_SIGBUS :
+ err = dma_fence_wait(bo->moving, true);
+ if (unlikely(err != 0)) {
+ ret = (err != -ERESTARTSYS) ? VM_FAULT_SIGBUS :
VM_FAULT_NOPAGE;
goto out_unlock;
}
@@ -104,7 +105,7 @@ static unsigned long ttm_bo_io_mem_pfn(struct
ttm_buffer_object *bo,
+ page_offset;
}
-static int ttm_bo_vm_fault(struct vm_fault *vmf)
+static vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
{
struct vm_area_struct *vma = vmf->vma;
struct ttm_buffer_object *bo = (struct ttm_buffer_object *)
@@ -115,8 +116,9 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
unsigned long pfn;
struct ttm_tt *ttm = NULL;
struct page *page;
- int ret;
+ int err;
int i;
+ vm_fault_t ret = VM_FAULT_NOPAGE;
unsigned long address = vmf->address;
struct ttm_mem_type_manager *man =
>man[bo->mem.mem_type];
@@ -128,9 +130,9 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
* for reserve, and if it fails, retry the fault after waiting
* for the buffer to become unreserved.
*/
- ret = ttm_bo_reserve(bo, true, true, NULL);
- if (unlikely(ret != 0)) {
- if (ret != -EBUSY)
+ err = ttm_bo_reserve(bo, true, true, NULL);
+ if (unlikely(err != 0)) {
+ if (err != -EBUSY)
return VM_FAULT_NOPAGE;
if (vmf->flags & FAULT_FLAG_ALLOW_RETRY) {
@@ -162,8 +164,8 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
}
if (bdev->driver->fault_reserve_notify) {
- ret = bdev->driver->fault_reserve_notify(bo);
- switch (ret) {
+ err = bdev->driver->fault_reserve_notify(bo);
+ switch (err) {
case 0:
break;
case -EBUSY:
@@ -191,13 +193,13 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
goto out_unlock;
}
- ret = ttm_mem_io_lock(man, true);
- if (unlikely(ret != 0)) {
+ err = ttm_mem_io_lock(man, true);
+ if (unlikely(err != 0)) {
ret = VM_FAULT_NOPAGE;
goto out_unlock;
}
- ret = ttm_mem_io_reserve_vm(bo);
- if (unlikely(ret != 0)) {
+ err = ttm_mem_io_reserve_vm(bo);
+ if (unlikely(err != 0)) {
ret = VM_FAULT_SIGBUS;
goto out_io_unlock;
}
@@ -265,23 +267,20 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
}
if (vma->vm_flags & VM_MIXEDMAP)
- ret = vm_insert_mixed(, address,
+ ret = vmf_insert_mixed(, address,
__pfn_to_pfn_t(pfn, PFN_DEV));
else
- ret = vm_insert_pfn(, address, pfn);
+ ret = vmf_insert_pfn(, address, pfn);
/*
* Somebody beat us to this PTE or prefaulting to
* an already populated PTE, or prefaulting error.
*/
- if (unlikely((ret == -EBUSY) || (ret != 0 && i > 0)))
+ if (unlikely((ret ==
[PATCH v4 3/3] drm/msm: unregister devfreq upon clean up
Call the devfreq_remove_device() API to remove the GPU devfreq instance
during GPU driver cleanup.
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/msm_gpu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index ffa5b77..c9d5fdf 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -889,6 +889,8 @@ void msm_gpu_cleanup(struct msm_gpu *gpu)
WARN_ON(!list_empty(>active_list));
+ devfreq_remove_device(gpu->devfreq.devfreq);
+
for (i = 0; i < ARRAY_SIZE(gpu->rb); i++) {
msm_ringbuffer_destroy(gpu->rb[i]);
gpu->rb[i] = NULL;
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/3] re-factor devfreq common code
This series re-factors the devfreq code a bit in preparation for the upcoming A6x related devfreq changes. The code applies cleanly on 4.17 and has been verified on DB820C. V2: Addressed code review comments from Jordan Crouse. V3: Added a new patch for devfreq cleanup. V4: removed "drm/msm: move suspend/resume devfreq to their own functions"(for now) Sharat Masetty (3): drm/msm: suspend devfreq on init drm/msm: re-factor devfreq code drm/msm: unregister devfreq upon clean up drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 16 drivers/gpu/drm/msm/msm_gpu.c | 27 ++- drivers/gpu/drm/msm/msm_gpu.h | 4 +++- 3 files changed, 33 insertions(+), 14 deletions(-) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/3] drm/msm: suspend devfreq on init
Devfreq turns on and starts recommending power level as soon as it is initialized. The GPU is still not powered on by the time the devfreq init happens and this leads to problems on GPU's where register access is needed to get/set power levels. So we start suspended and only restart devfreq when GPU is powered on. Signed-off-by: Sharat Masetty --- drivers/gpu/drm/msm/msm_gpu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c index 1c09acf..d7586f2 100644 --- a/drivers/gpu/drm/msm/msm_gpu.c +++ b/drivers/gpu/drm/msm/msm_gpu.c @@ -104,6 +104,8 @@ static void msm_devfreq_init(struct msm_gpu *gpu) dev_err(>pdev->dev, "Couldn't initialize GPU devfreq\n"); gpu->devfreq.devfreq = NULL; } + + devfreq_suspend_device(gpu->devfreq.devfreq); } static int enable_pwrrail(struct msm_gpu *gpu) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/3] drm/msm: re-factor devfreq code
devfreq framework requires the drivers to provide busy time estimations.
The GPU driver relies on the hardware performance counters for the busy time
estimations, but different hardware revisions have counters which can be
sourced from different clocks. So the busy time estimation will be target
dependent. Additionally on targets where the clocks are completely controlled
by the on chip microcontroller, fetching and setting the current GPU frequency
will be different. This patch aims to embrace these differences by re-factoring
the devfreq code a bit.
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 16
drivers/gpu/drm/msm/msm_gpu.c | 23 ++-
drivers/gpu/drm/msm/msm_gpu.h | 4 +++-
3 files changed, 29 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index d39400e..5cdf104 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1219,12 +1219,20 @@ static struct msm_ringbuffer *a5xx_active_ring(struct
msm_gpu *gpu)
return a5xx_gpu->cur_ring;
}
-static int a5xx_gpu_busy(struct msm_gpu *gpu, uint64_t *value)
+static unsigned long a5xx_gpu_busy(struct msm_gpu *gpu)
{
- *value = gpu_read64(gpu, REG_A5XX_RBBM_PERFCTR_RBBM_0_LO,
- REG_A5XX_RBBM_PERFCTR_RBBM_0_HI);
+ u64 busy_cycles;
+ unsigned long busy_time;
- return 0;
+ busy_cycles = gpu_read64(gpu, REG_A5XX_RBBM_PERFCTR_RBBM_0_LO,
+ REG_A5XX_RBBM_PERFCTR_RBBM_0_HI);
+
+ busy_time = (busy_cycles - gpu->devfreq.busy_cycles) /
+ (clk_get_rate(gpu->core_clk) / 100);
+
+ gpu->devfreq.busy_cycles = busy_cycles;
+
+ return busy_time;
}
static const struct adreno_gpu_funcs funcs = {
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index d7586f2..ffa5b77 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -40,7 +40,11 @@ static int msm_devfreq_target(struct device *dev, unsigned
long *freq,
if (IS_ERR(opp))
return PTR_ERR(opp);
- clk_set_rate(gpu->core_clk, *freq);
+ if (gpu->funcs->gpu_set_freq)
+ gpu->funcs->gpu_set_freq(gpu, *freq);
+ else
+ clk_set_rate(gpu->core_clk, *freq);
+
dev_pm_opp_put(opp);
return 0;
@@ -50,16 +54,14 @@ static int msm_devfreq_get_dev_status(struct device *dev,
struct devfreq_dev_status *status)
{
struct msm_gpu *gpu = platform_get_drvdata(to_platform_device(dev));
- u64 cycles;
- u32 freq = ((u32) status->current_frequency) / 100;
ktime_t time;
- status->current_frequency = (unsigned long) clk_get_rate(gpu->core_clk);
- gpu->funcs->gpu_busy(gpu, );
-
- status->busy_time = ((u32) (cycles - gpu->devfreq.busy_cycles)) / freq;
+ if (gpu->funcs->gpu_get_freq)
+ status->current_frequency = gpu->funcs->gpu_get_freq(gpu);
+ else
+ status->current_frequency = clk_get_rate(gpu->core_clk);
- gpu->devfreq.busy_cycles = cycles;
+ status->busy_time = gpu->funcs->gpu_busy(gpu);
time = ktime_get();
status->total_time = ktime_us_delta(time, gpu->devfreq.time);
@@ -72,7 +74,10 @@ static int msm_devfreq_get_cur_freq(struct device *dev,
unsigned long *freq)
{
struct msm_gpu *gpu = platform_get_drvdata(to_platform_device(dev));
- *freq = (unsigned long) clk_get_rate(gpu->core_clk);
+ if (gpu->funcs->gpu_get_freq)
+ *freq = gpu->funcs->gpu_get_freq(gpu);
+ else
+ *freq = clk_get_rate(gpu->core_clk);
return 0;
}
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index b824117..4863e4e 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -68,7 +68,9 @@ struct msm_gpu_funcs {
/* for generation specific debugfs: */
int (*debugfs_init)(struct msm_gpu *gpu, struct drm_minor *minor);
#endif
- int (*gpu_busy)(struct msm_gpu *gpu, uint64_t *value);
+ unsigned long (*gpu_busy)(struct msm_gpu *gpu);
+ unsigned long (*gpu_get_freq)(struct msm_gpu *gpu);
+ int (*gpu_set_freq)(struct msm_gpu *gpu, unsigned long freq);
};
struct msm_gpu {
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] gpu: drm: omapdrm: Adding new typedef vm_fault_t
Hi,
On 22/05/18 21:13, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler. For
> now, this is just documenting that the function returns
> a VM_FAULT value rather than an errno. Once all instances
> are converted, vm_fault_t will become a distinct type.
>
> Ref-> commit 1c8f422059ae ("mm: change return type to vm_fault_t")
>
> Previously vm_insert_mixed() returns err which driver
> mapped into VM_FAULT_* type. Also return value of
> vm_insert_mixed() not handled correctly and 0 was
> returned inside fault_2d() as default. The new function
> vmf_insert_mixed() will replace this inefficiency by
> returning correct VM_FAULT_* type.
>
> vmf_error() is the newly introduce inline function
> in 4.17-rc6.
>
> Signed-off-by: Souptick Joarder
> Reviewed-by: Matthew Wilcox
> ---
> v2: Fixed kbuild error by initialized ret
> in fault_2d().
>
> drivers/gpu/drm/omapdrm/omap_gem.c | 51
> +-
> drivers/gpu/drm/omapdrm/omap_gem.h | 3 ++-
> 2 files changed, 25 insertions(+), 29 deletions(-)
Reviewed-by: Tomi Valkeinen
It's too late to get this to 4.18 via my normal routes. If you have
other similar patches queued and Linus/maintainers are ok to merge this
late, feel free to queue this that way.
Otherwise I can pick this up for my 4.19 patches.
Laurent, this will conflict omap_gem cleanups you did, but I don't think
there's anything problematic there.
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199979] New: amdgpu: changing pwm1_enable from 1 to 2 does not resume automatic fan control
https://bugzilla.kernel.org/show_bug.cgi?id=199979 Bug ID: 199979 Summary: amdgpu: changing pwm1_enable from 1 to 2 does not resume automatic fan control Product: Drivers Version: 2.5 Kernel Version: 4.17.0 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: cwid...@umbrox.de Regression: No When using the hardware monitoring interface to change pwm1_enable to 2 (automatic) from 1 (manual), the automatic fan control does not work as expected. Instead, the pwm1 value keeps jumping around between at least two values and a continuous, persisting, and unpleasantly high-pitched sound can be heard from inside the computer case. The only way to stop those things is writing some valid value to pwm1, which in turn also switches pwm1_enable back to 1. If the system is booted without ever manually changing the pwm1_enable value, which then defaults to 2, automatic fan control does work as intended. I am using a custom RX 580 (Sapphire Nitro+ Radeon RX 580 8GD5 Special Edition) on a Gentoo x86_64 system and was able to reproduce the issue with the 4.17.0 kernel with Gentoo patches, the Ubuntu kernel on the 18.04 image (should be a 4.15 one) and also with amd-staging-drm-next. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/bridge/sii8620: simplify hardware reset procedure
There is no need to flip reset pin twice. Also delays can be changed to
values present in vendor's code.
Signed-off-by: Andrzej Hajda
---
Hi,
This is v2 of forgotten patch, awaiting reviewers, any volunteers.
Also "drm/bridge/sii8620: fix loops in EDID fetch logic" waits for reviewers.
In this version I have completely removed reset function, and moved its body
to sii8620_hw_on.
Regards
Andrzej
---
drivers/gpu/drm/bridge/sil-sii8620.c | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 7ab36042a822..d1e780fba4b6 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -971,8 +971,17 @@ static int sii8620_hw_on(struct sii8620 *ctx)
ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
if (ret)
return ret;
+
usleep_range(1, 2);
- return clk_prepare_enable(ctx->clk_xtal);
+ ret = clk_prepare_enable(ctx->clk_xtal);
+ if (ret)
+ return ret;
+
+ msleep(100);
+ gpiod_set_value(ctx->gpio_reset, 0);
+ msleep(100);
+
+ return 0;
}
static int sii8620_hw_off(struct sii8620 *ctx)
@@ -982,17 +991,6 @@ static int sii8620_hw_off(struct sii8620 *ctx)
return regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
}
-static void sii8620_hw_reset(struct sii8620 *ctx)
-{
- usleep_range(1, 2);
- gpiod_set_value(ctx->gpio_reset, 0);
- usleep_range(5000, 2);
- gpiod_set_value(ctx->gpio_reset, 1);
- usleep_range(1, 2);
- gpiod_set_value(ctx->gpio_reset, 0);
- msleep(300);
-}
-
static void sii8620_cbus_reset(struct sii8620 *ctx)
{
sii8620_write(ctx, REG_PWD_SRST, BIT_PWD_SRST_CBUS_RST
@@ -2112,7 +2110,6 @@ static void sii8620_cable_in(struct sii8620 *ctx)
dev_err(dev, "Error powering on, %d.\n", ret);
return;
}
- sii8620_hw_reset(ctx);
sii8620_read_buf(ctx, REG_VND_IDL, ver, ARRAY_SIZE(ver));
ret = sii8620_clear_error(ctx);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
