[PATCH] drm/i915: Before pageflip, also wait for shared dmabuf fences.
On 21/09/16 09:56 PM, Daniel Vetter wrote: > On Wed, Sep 21, 2016 at 1:19 PM, Christian König > wrote: >> Am 21.09.2016 um 13:04 schrieb Daniel Vetter: >>> On Wed, Sep 21, 2016 at 12:30 PM, Christian König >>> wrote: Am 21.09.2016 um 11:56 schrieb Michel Dänzer: > > > Looks like there are different interpretations of the semantics of > exclusive vs. shared fences. Where are these semantics documented? Yeah, I think as well that this is the primary question here. IIRC the fences were explicitly called exclusive/shared instead of writing/reading on purpose. I absolutely don't mind switching to them to writing/reading semantics, but amdgpu really needs multiple writers at the same time. So in this case the writing side of a reservation object needs to be a collection of fences as well. >>> >>> You can't have multiple writers with implicit syncing. That confusion >>> is exactly why we called them shared/exclusive. Multiple writers >>> generally means that you do some form of fencing in userspace >>> (unsync'ed gl buffer access is the common one). What you do for >>> private buffers doesn't matter, but when you render into a >>> shared/winsys buffer you really need to set the exclusive fence (and >>> there can only ever be one). So probably needs some userspace >>> adjustments to make sure you don't accidentally set an exclusive write >>> hazard when you don't really want that implicit sync. >> >> >> Nope, that isn't true. >> >> We use multiple writers without implicit syncing between processes in the >> amdgpu stack perfectly fine. >> >> See amdgpu_sync.c for the implementation. What we do there is taking a look >> at all the fences associated with a reservation object and only sync to >> those who are from another process. >> >> Then we use implicit syncing for command submissions in the form of >> "dependencies". E.g. for each CS we report back an identifier of that >> submission to user space and on the next submission you can give this >> identifier as dependency which needs to be satisfied before the command >> submission can start running. > > This is called explicit fencing. Implemented with a driver-private > primitive (and not sync_file fds like on android), but still > conceptually explicit fencing. Implicit fencing really only can handle > one writer, at least as currently implemented by struct > reservation_object. > >> This was done to allow multiple engines (3D, DMA, Compute) to compose a >> buffer while still allow compatibility with protocols like DRI2/DRI3. > > Instead of the current solution you need to stop attaching exclusive > fences to non-shared buffers (which are coordinated using the > driver-private explicit fencing you're describing), Err, the current issue is actually that amdgpu never sets an exclusive fence, only ever shared ones. :) > and only attach exclusive fences to shared buffers (DRI2/3, PRIME, > whatever). Still, it occurred to me in the meantime that amdgpu setting the exclusive fence for buffers shared via PRIME (no matter if it's a write or read operation) might be a solution. Christian, what do you think? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[PATCH] drm/i915: Before pageflip, also wait for shared dmabuf fences.
On 21/09/16 07:30 PM, Christian König wrote: > Am 21.09.2016 um 11:56 schrieb Michel Dänzer: >> >> FWIW, we seem to have the same issue with radeon vs. amdgpu: radeon only >> seems to wait for exclusive fences, so e.g. running Xorg on amdgpu and >> using PRIME slave scanout on radeon leaves artifacts. > > Yeah, I know. See radeon_display.c radeon_flip_work_func(). > > We pretty much need the same patch here I've done for amdgpu as well. Actually, the PRIME slave can't scan out from the shared BOs directly (recall the recent discussion we had about that with Mario), but has to copy from the shared BO to a dedicated scanout BO. These copies need to be synchronized with the primary GPU's copies to the shared BO. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[PATCH] drm/i915: Before pageflip, also wait for shared dmabuf fences.
On 22/09/16 12:21 AM, Christian König wrote: > Am 21.09.2016 um 17:13 schrieb Michel Dänzer: >> On 21/09/16 07:30 PM, Christian König wrote: >>> Am 21.09.2016 um 11:56 schrieb Michel Dänzer: FWIW, we seem to have the same issue with radeon vs. amdgpu: radeon only seems to wait for exclusive fences, so e.g. running Xorg on amdgpu and using PRIME slave scanout on radeon leaves artifacts. >>> Yeah, I know. See radeon_display.c radeon_flip_work_func(). >>> >>> We pretty much need the same patch here I've done for amdgpu as well. >> Actually, the PRIME slave can't scan out from the shared BOs directly >> (recall the recent discussion we had about that with Mario), but has to >> copy from the shared BO to a dedicated scanout BO. These copies need to >> be synchronized with the primary GPU's copies to the shared BO. > > Yeah, that thought came to my mind before as well. > > Buffer migrations by the kernel caused by a prime export actually set > the exclusive fence. > > So this shouldn't be an issue in practice when the displaying GPU needs > to copy from the BO again anyway. > > The only case I can see when this can happen is when the BO is composed > directly in system memory by the engines and not migrated there. There is no migration going on in the steady state, just the primary GPU writing to the shared BO and the slave GPU reading from it. If those operations aren't properly synchronized, there is at least intermittent tearing, but there can even be artifacts which stay until that area is updated again. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[PATCH] drm/i915: Before pageflip, also wait for shared dmabuf fences.
On 22/09/16 12:15 AM, Christian König wrote: > Am 21.09.2016 um 17:07 schrieb Michel Dänzer: >> On 21/09/16 09:56 PM, Daniel Vetter wrote: >>> On Wed, Sep 21, 2016 at 1:19 PM, Christian König >>> wrote: We use multiple writers without implicit syncing between processes in the amdgpu stack perfectly fine. See amdgpu_sync.c for the implementation. What we do there is taking a look at all the fences associated with a reservation object and only sync to those who are from another process. Then we use implicit syncing for command submissions in the form of "dependencies". E.g. for each CS we report back an identifier of that submission to user space and on the next submission you can give this identifier as dependency which needs to be satisfied before the command submission can start running. >>> This is called explicit fencing. Implemented with a driver-private >>> primitive (and not sync_file fds like on android), but still >>> conceptually explicit fencing. Implicit fencing really only can handle >>> one writer, at least as currently implemented by struct >>> reservation_object. >>> This was done to allow multiple engines (3D, DMA, Compute) to compose a buffer while still allow compatibility with protocols like DRI2/DRI3. >>> Instead of the current solution you need to stop attaching exclusive >>> fences to non-shared buffers (which are coordinated using the >>> driver-private explicit fencing you're describing), >> Err, the current issue is actually that amdgpu never sets an exclusive >> fence, only ever shared ones. :) > > Actually amdgpu does set the exclusive fence for buffer migrations, > cause that is an operation user space doesn't know about and so it needs > to be "exclusive" access to the buffer. > > >>> and only attach exclusive fences to shared buffers (DRI2/3, PRIME, >>> whatever). >> Still, it occurred to me in the meantime that amdgpu setting the >> exclusive fence for buffers shared via PRIME (no matter if it's a write >> or read operation) might be a solution. Christian, what do you think? > > The problem is that we don't have one fence, but many. > > E.g. there can be many operation on a buffer at the same time and we > need to wait for all of them to complete before it can be displayed. Maybe in theory, but with the problem we have in practice right now, the amdgpu GPU should only ever access the shared BO with the same engine. Anyway, this should be solvable by setting some kind of meta-fence as the exclusive fence, which can internally be mapped to multiple fences, maybe up to one for each ring which can access the BO? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[PATCH] drm/sun4i: rgb: Enable panel after controller
Hi, On Wed, Sep 21, 2016 at 11:03:04PM +1000, Jonathan Liu wrote: > The panel should be enabled after the controller so that the panel > prepare/enable delays are properly taken into account. Similarly, the > panel should be disabled before the controller so that the panel > unprepare/disable delays are properly taken into account. > > This is useful for avoiding visual glitches. This is not really taking any delays into account, especially since drm_panel_enable and prepare are suppose to block until their operation is complete. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160922/2c9d582c/attachment.sig>
[Bug 97894] Crash in u_transfer_unmap_vtbl when unmapping a buffer mapped in different context
https://bugs.freedesktop.org/show_bug.cgi?id=97894 Bug ID: 97894 Summary: Crash in u_transfer_unmap_vtbl when unmapping a buffer mapped in different context Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: jlegg at feralinteractive.com QA Contact: dri-devel at lists.freedesktop.org Created attachment 126724 --> https://bugs.freedesktop.org/attachment.cgi?id=126724&action=edit Apitrace reproducing issue The following sequence of events cause a crash on radeonsi: 1. Create two contexts in the same share group 2. In one of the contexts, create and map a buffer. Then delete that context. 3. Create another context in the share group 4. Cause the buffer to be unmapped in the new context (either explicitly with glUnmapBuffer/glUnmapNamedBuffer or implicitly via glDeleteBuffers). The attached apitrace reproduces the issue when using an AMD R9 270, unless environment variable LIBGL_ALWAYS_SOFTWARE is set to 1. I reproduced this using Mesa git 36f0f0318275f65f8744ec6f9471702e2f58e6d5 and the 12.0.3 release on x86_64 Fedora 24. My OpenGL renderer string is Gallium 0.4 on AMD PITCAIRN (DRM 2.45.0 / 4.7.2-201.fc24.x86_64, LLVM 3.9.0). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160922/4ac90695/attachment.html>
[Bug 97894] Crash in u_transfer_unmap_vtbl when unmapping a buffer mapped in different context
https://bugs.freedesktop.org/show_bug.cgi?id=97894 --- Comment #1 from James Legg --- Created attachment 126725 --> https://bugs.freedesktop.org/attachment.cgi?id=126725&action=edit Valgrind output when replaying trace Valgrind reports a use after free error when the unmap occurs. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160922/30ee4a0c/attachment.html>
[Bug 94984] XCom2 crashes with SIGSEGV on radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=94984 --- Comment #13 from Ernst Sjöstrand --- Could "radeon/winsyses: sub-allocation for small buffers" help with this? https://patchwork.freedesktop.org/series/12382/ -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160922/c58593bb/attachment.html>
[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)
https://bugs.freedesktop.org/show_bug.cgi?id=97879 --- Comment #10 from Silvan Jegen --- (In reply to Michel Dänzer from comment #3) > (In reply to Silvan Jegen from comment #2) > > Just to clarify: the trace also includes loading of the game itself (which > > takes a long time too) as well as in-game menu navigation. > > Right, replaying the trace crashes for me after the shader compilations on > startup, so my CPU profile only covered that. Maybe you can try getting a > CPU profile of one of the other stalls. I tried to replay the trace and it crashed on my machine as well... > Otherwise, maybe try setting the environment variable > GALLIUM_HUD=.dfps,requested-VRAM+VRAM-usage,requested-GTT+GTT-usage, > cpu+temperature+GPU-load,.dnum-bytes-moved,.dbuffer-wait-time,.dnum- > compilations+num-shaders-created for either running the game itself or > replaying the trace, and taking a screenshot within one minute after one of > the other stalls. That should allow at least confirming or ruling out that > the other stalls are due to shader compilation as well. Do you still need such a screenshot now that other people in the thread have posted a few? If so, I will upload one early next week (I will be away over the weekend). -- You are receiving this mail because: You are on the CC list for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160922/cc2625bf/attachment.html>
[PATCH 2/2] drm: Don't swallow error codes in drm_dev_alloc()
Hey
On Wed, Sep 21, 2016 at 4:59 PM, Tom Gundersen wrote:
> There are many reasons other than ENOMEM that drm_dev_init() can
> fail. Return ERR_PTR rather than NULL to be able to distinguish
> these in the caller.
>
> Signed-off-by: Tom Gundersen
> ---
Reviewed-by: David Herrmann
Thanks
David
> drivers/gpu/drm/arc/arcpgu_drv.c| 4 ++--
> drivers/gpu/drm/arm/hdlcd_drv.c | 4 ++--
> drivers/gpu/drm/arm/malidp_drv.c| 4 ++--
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 4 ++--
> drivers/gpu/drm/drm_drv.c | 6 +++---
> drivers/gpu/drm/drm_pci.c | 4 ++--
> drivers/gpu/drm/drm_platform.c | 4 ++--
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 4 ++--
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 4 ++--
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 4 ++--
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 ++--
> drivers/gpu/drm/msm/msm_drv.c | 4 ++--
> drivers/gpu/drm/nouveau/nouveau_drm.c | 4 ++--
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 4 ++--
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 4 ++--
> drivers/gpu/drm/sti/sti_drv.c | 4 ++--
> drivers/gpu/drm/sun4i/sun4i_drv.c | 4 ++--
> drivers/gpu/drm/tegra/drm.c | 4 ++--
> drivers/gpu/drm/udl/udl_drv.c | 4 ++--
> drivers/gpu/drm/vc4/vc4_drv.c | 4 ++--
> drivers/gpu/drm/vgem/vgem_drv.c | 4 ++--
> drivers/gpu/drm/virtio/virtgpu_drm_bus.c| 4 ++--
> 22 files changed, 45 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c
> b/drivers/gpu/drm/arc/arcpgu_drv.c
> index 6d4ff34..28e6471 100644
> --- a/drivers/gpu/drm/arc/arcpgu_drv.c
> +++ b/drivers/gpu/drm/arc/arcpgu_drv.c
> @@ -198,8 +198,8 @@ static int arcpgu_probe(struct platform_device *pdev)
> int ret;
>
> drm = drm_dev_alloc(&arcpgu_drm_driver, &pdev->dev);
> - if (!drm)
> - return -ENOMEM;
> + if (IS_ERR(drm))
> + return PTR_ERR(drm);
>
> ret = arcpgu_load(drm);
> if (ret)
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index d83b46a..fb6a418 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -326,8 +326,8 @@ static int hdlcd_drm_bind(struct device *dev)
> return -ENOMEM;
>
> drm = drm_dev_alloc(&hdlcd_driver, dev);
> - if (!drm)
> - return -ENOMEM;
> + if (IS_ERR(drm))
> + return PTR_ERR(drm);
>
> drm->dev_private = hdlcd;
> dev_set_drvdata(dev, drm);
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> b/drivers/gpu/drm/arm/malidp_drv.c
> index c383d72..9280358 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -311,8 +311,8 @@ static int malidp_bind(struct device *dev)
> return ret;
>
> drm = drm_dev_alloc(&malidp_driver, dev);
> - if (!drm) {
> - ret = -ENOMEM;
> + if (IS_ERR(drm)) {
> + ret = PTR_ERR(drm);
> goto alloc_fail;
> }
>
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index 8e7483d..5f48431 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -797,8 +797,8 @@ static int atmel_hlcdc_dc_drm_probe(struct
> platform_device *pdev)
> int ret;
>
> ddev = drm_dev_alloc(&atmel_hlcdc_dc_driver, &pdev->dev);
> - if (!ddev)
> - return -ENOMEM;
> + if (IS_ERR(ddev))
> + return PTR_ERR(ddev);
>
> ret = atmel_hlcdc_dc_load(ddev);
> if (ret)
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 99e6751..80c7f25 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -591,7 +591,7 @@ EXPORT_SYMBOL(drm_dev_init);
> * own struct should look at using drm_dev_init() instead.
> *
> * RETURNS:
> - * Pointer to new DRM device, or NULL if out of memory.
> + * Pointer to new DRM device, or ERR_PTR on failure.
> */
> struct drm_device *drm_dev_alloc(struct drm_driver *driver,
> struct device *parent)
> @@ -601,12 +601,12 @@ struct drm_device *drm_dev_alloc(struct drm_driver
> *driver,
>
> dev = kzalloc(sizeof(*dev), GFP_KERNEL);
> if (!dev)
> - return NULL;
> + return ERR_PTR(-ENOMEM);
>
> ret = drm_dev_init(dev, driver, parent);
> if (ret) {
> kfree(dev);
> - return NULL;
> + return ERR_PTR(ret);
> }
>
> return dev;
> diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
> index d86362f..3ceea9c 100644
> --- a/drivers
[PATCH] drm/i2c: tda998x: don't register the connector
On Thu, Sep 22, 2016 at 1:22 PM, Sean Paul wrote: > On Thu, Sep 22, 2016 at 3:51 AM, Russell King - ARM Linux > wrote: >> On Thu, Sep 22, 2016 at 11:39:18AM +0100, Brian Starkey wrote: >>> Actually, could you please hold off picking this up? We need to make >>> changes in mali-dp and hdlcd or this will mess up their registration. >>> I will send those patches later today, but better if this all goes in >>> together (whenever that ends up being). >> >> Sorry, but I'm annoyed with this - the impression being given was that >> I was holding up this patch by not testing it on Armada, and I brought >> up the issue about registration at the beginning of this. >> >> Now we're _just_ finding out that there are drivers where removing the >> connector registration in tda998x causes them to break? It's a bit >> late to be checking your own drivers when you've been chasing me... >> >> Sorry, but it sounds like we're not ready to make this change - and as >> it's the very last day that changes will appear in linux-next prior to >> the merge window (assuming Linus releases 4.8 on Sunday), I'd suggest >> holding off until after the merge window is over, so we can get some >> testing with these other two drivers with this change in place. >> > > sigh. I just pushed my queue to drm-misc, which included this patch. > Sounds like I should revert? I thought I looked at the entire situation and since we register (since recently) all connectors in drm_dev_register() there shouldn't be an issue for any other driver. Imo no need to revert anything here - until someone complains with a bug report and proves me wrong ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[GIT PULL] Allwinner sun4i DRM fixes for 4.9
Hi David, Here is a bunch of fixes for the previous pull request I sent. Thanks! Maxime The following changes since commit 0c3ff44cc23cbede56aa1ca5916b126e681ca69b: drm/sun4i: add missing header dependencies (2016-09-08 14:55:48 +0200) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git tags/sunxi-drm-fixes-for-4.9 for you to fetch changes up to f0188ef8301ccbb128bbfd10751a9aeca8c9172e: drm/sun4i: Fix the high buffer address mask (2016-09-22 10:13:22 +0300) Allwinner sun4i DRM fixes for 4.9 A few fixes for the sun4i drm driver that range, including some fixes that might prevent multiple planes from working depending on the sequence where they are enabled. Chen-Yu Tsai (3): drm/sun4i: dotclock: Fix clock rate read back calcation drm/sun4i: dotclock: Allow divider = 127 drm/sun4i: dotclock: Round to closest clock rate Maxime Ripard (3): drm/sun4i: Fix formats usable by the primary plane drm/sun4i: tv: Check mode pointer drm/sun4i: Fix the high buffer address mask Ville Syrjälä (1): drm/sun4i: Fix sparse warnings Wei Yongjun (1): drm/sun4i: backend: remove redundant dev_err call in sun4i_backend_bind() drivers/gpu/drm/sun4i/sun4i_backend.c | 13 +--- drivers/gpu/drm/sun4i/sun4i_backend.h | 4 +-- drivers/gpu/drm/sun4i/sun4i_dotclock.c | 7 +++-- drivers/gpu/drm/sun4i/sun4i_layer.c| 56 +++--- drivers/gpu/drm/sun4i/sun4i_tv.c | 46 5 files changed, 79 insertions(+), 47 deletions(-) -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160922/42771ce4/attachment-0001.sig>
GPU-DRM-QXL: Move three assignments in qxl_device_init()
> Guys, please stop accepting patches from Markus! I would appreciate a bit more explanation for this request. > Markus, you always introduce bugs. I find the wording "always" exaggerated. It can also happen that I make another programming mistake occasionally. > I have asked you over and over to stop sending "cleanup patches" > because you are not careful. Why would my update suggestion be inappropriate here? > If you restricted yourself to fixing bugs only then you would maybe fix more > bugs than you introduce but as it you are making the kernel worse. Would you like to discuss the statistics for my failure (or success) rate a bit more so that involved issues can be clarified in a constructive way? Regards, Markus
[Bug 97896] RADEON DisplayPort - Monitor shows out of range in some modes
https://bugs.freedesktop.org/show_bug.cgi?id=97896 Bug ID: 97896 Summary: RADEON DisplayPort - Monitor shows out of range in some modes Product: DRI Version: unspecified Hardware: x86 (IA32) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel at lists.freedesktop.org Reporter: jan.burgmeier at unicon-software.com Created attachment 126733 --> https://bugs.freedesktop.org/attachment.cgi?id=126733&action=edit dmesg output with drm.debug=0x1e log_buf_len=1M Hi, I have two monitors connected to my PC one via DVI and one via DP. The monitor connected via DP shows "frequency out of range" when some modes including the preferred one are used. This happens in X and in the KMS framebuffer. For example on the attached logs the preferred mode of 1680x1050 does not work where as 1680x945 works perfectly fine. Kernel: 4.4.11 Xorg: 1.18.2 xf86-video-radeon: 7.7.0 Last working kernel: 3.19 First broken kernel: 4.0 Here is the bisect info, the 4.0 release segfaulted in the radeon driver but the change which broke this was before so I hope the bisect is right: # first bad commit: [e55bca26188e45f209597abf986c87cc5a49894a] radeon/audio: enable DP audio After finding the bad commit I tried booting with radeon.audio=0 this made the display work for 3.19 kernel with that commit but did not work for the 4.4.11 kernel. Attached log files: - dmesg output with drm.debug=0x1e log_buf_len=1M - lspci -vv output - video card bios - Xorg.0.log - xrander --verbose output -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160922/3161331e/attachment.html>
[PATCH] drm/i915: Before pageflip, also wait for shared dmabuf fences.
On Thu, Sep 22, 2016 at 2:44 PM, Christian König wrote: >> - explicit fencing: Userspace passes around distinct fence objects for >> any work going on on the gpu. The kernel doesn't insert any stall of >> it's own (except for moving buffer objects around ofc). This is what >> Android. This also seems to be what amdgpu is doing within one >> process/owner. > > > No, that is clearly not my understanding of explicit fencing. > > Userspace doesn't necessarily need to pass around distinct fence objects > with all of it's protocols and the kernel is still responsible for inserting > stalls whenever an userspace protocol or application requires this > semantics. > > Otherwise you will never be able to use explicit fencing on the Linux > desktop with protocols like DRI2/DRI3. This is about mixing them. Explicit fencing still means userspace has an explicit piece, separate from buffers, (either sync_file fd, or a driver-specific cookie, or similar). > I would expect that every driver in the system waits for all fences of a > reservation object as long as it isn't told otherwise by providing a > distinct fence object with the IOCTL in question. Yup agreed. This way if your explicitly-fencing driver reads a shared buffer passed over a protocol that does implicit fencing (like DRI2/3), then it will work. The other interop direction is explicitly-fencing driver passes a buffer to a consumer which expects implicit fencing. In that case you must attach the right fence to the exclusive slot, but _only_ in that case. Otherwise you end up stalling your explicitly-fencing userspace, since implicit fencing doesn't allow more than 1 writer. For amdgpu one possible way to implement this might be to count how many users a dma-buf has, and if it's more than just the current context set the exclusive fence. Or do an uabi revision and let userspace decide (or at least overwrite it). But the current approach in amdgpu_sync.c of declaring a fence as exclusive after the fact (if owners don't match) just isn't how reservation_object works. You can of course change that, but that means you must change all drivers implementing support for implicit fencing of dma-buf. Fixing amdgpu will be easier ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm/i915: Before pageflip, also wait for shared dmabuf fences.
On Thu, Sep 22, 2016 at 12:55 PM, Christian König wrote: > Am 22.09.2016 um 08:36 schrieb Daniel Vetter: >> >> On Wed, Sep 21, 2016 at 06:23:35PM +0200, Christian König wrote: >>> >>> For a quick workaround I suggest to just serialize all accesses to BO >>> shared >>> with different drivers, but essentially I think it is a perfectly valid >>> requirement to have multiple writers to one BO. >> >> It is, but it's not possible with implicit sync. If you want parallel >> write access to the same shared buffer, you _must_ carry around some >> explicit fences. Within amdgpu you can use driver-specific cookies, for >> shared buffer we now have sync_file. But multiple writers with implicit >> sync simply fundamentally doesn't work. Because you have no idea with >> which >> writer, touching the same subrange you want to touch. > > > You don't need to separate the BO into subranges which are touched by > different engines for allowing multiple writers. > > AMD hardware and I'm pretty sure others as well are perfectly capable of > writing to the same memory from multiple engines and even multiple GPUs at > the same time. > > For a good hint of what is possible see the public AMD ISA documentation > about atomic operations, but that is only the start of it. > > > The crux here is that we need to assume that we will have implicit and > explicit sync mixed for backward compatibility. > > This implies that we need some mechanism like amdgpu uses in it's sync > implementation where every fence is associated with an owner which denotes > the domain in which implicit sync happens. If you leave this domain you will > automatically run into explicit sync. > > Currently we define the borders of this domain in amdgpu on process boundary > to keep things like DRI2/DRI3 working as expected. > > I really don't see how you want to solve this with a single explicit fence > for each reservation object. As long as you have multiple concurrently > running operations accessing the same buffer you need to keep one fence for > each operation no matter what. I can't make sense of what you're saying, and I suspect we put different meaning to different words. So let me define here: - implicit fencing: Userspace does not track read/writes to buffers, but only the kernel does that. This is the assumption DRI2/3 has. Since synchronization is by necessity on a per-buffer level you can only have 1 writer. In the kernel the cross-driver interface for this is struct reservation_object attached to dma-bufs. If you don't fill out/wait for the exclusive fence in there, you're driver is _not_ doing (cross-device) implicit fencing. - explicit fencing: Userspace passes around distinct fence objects for any work going on on the gpu. The kernel doesn't insert any stall of it's own (except for moving buffer objects around ofc). This is what Android. This also seems to be what amdgpu is doing within one process/owner. Given that I'm not sure what you mean with "one explicit fence per reservation_object", since explicit fencing should not attach anything (at least not any exclusive fences) to a reservation_object. It does sound a bit like you have the meaning the other way round (as in explicit fencing = the kernel explicitly takes care of fencing, but it's explicit as in explicit fences visible to userspace). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 97896] RADEON DisplayPort - Monitor shows out of range in some modes
https://bugs.freedesktop.org/show_bug.cgi?id=97896 --- Comment #1 from Jan Burgmeier --- Created attachment 126734 --> https://bugs.freedesktop.org/attachment.cgi?id=126734&action=edit lspci -vv -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160922/139d1073/attachment.html>
[Bug 97896] RADEON DisplayPort - Monitor shows out of range in some modes
https://bugs.freedesktop.org/show_bug.cgi?id=97896 --- Comment #2 from Jan Burgmeier --- Created attachment 126735 --> https://bugs.freedesktop.org/attachment.cgi?id=126735&action=edit video card bios rom -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160922/64d40334/attachment-0001.html>
[Bug 97896] RADEON DisplayPort - Monitor shows out of range in some modes
https://bugs.freedesktop.org/show_bug.cgi?id=97896 --- Comment #3 from Jan Burgmeier --- Created attachment 126736 --> https://bugs.freedesktop.org/attachment.cgi?id=126736&action=edit Xorg log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160922/e179e6fd/attachment.html>
[Bug 97896] RADEON DisplayPort - Monitor shows out of range in some modes
https://bugs.freedesktop.org/show_bug.cgi?id=97896 --- Comment #4 from Jan Burgmeier --- Created attachment 126737 --> https://bugs.freedesktop.org/attachment.cgi?id=126737&action=edit xrandr --verbose output -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160922/216afa6d/attachment.html>
[PATCH] dma-buf/fence-array: get signaled state when signaling is disabled
2016-09-22 Christian König : > Am 22.09.2016 um 09:44 schrieb Gustavo Padovan: > > Hi Christian, > > > > 2016-09-21 Christian König : > > > > > Am 21.09.2016 um 13:36 schrieb Gustavo Padovan: > > > > From: Gustavo Padovan > > > > > > > > If the fences in the fence_array signal on the fence_array does not have > > > > signalling enabled num_pending will not be updated accordingly. > > > > > > > > So when signaling is disabled check the signal of every fence with > > > > fence_is_signaled() and then compare with num_pending to learn if the > > > > fence_array was signalled or not. > > > > > > > > If we want to keep the poll_does_not_wait optimization I think we need > > > > something like this. It keeps the same behaviour if signalling is > > > > enabled > > > > but tries to calculated the state otherwise. > > > > > > > > Signed-off-by: Gustavo Padovan > > > > Reviewed-by: Chris Wilson > > > First of all the patch is horrible wrong because fence_array_signaled() is > > > called without any locks held. So you can run into a race condition > > > between > > > checking the fences here and enable signaling. > > Yes. it can, but I don't think the race condition is actually a problem. > > Maybe you have some use case that we are not seeing? > > I'm not sure if that can really race, but if it does the check would return > true while not all necessary fences are signaled yet. How? If signaling is disabled num_pending is equal to the number of fences (or 1 if signal_on_any) then we just check all fences. If all of them are signaled then num_pending will be zero. > > That would be really really bad for things like TTM where we just do a quick > check in the page fault handler for example. > > I need to double check if that really could be a problem. > > > > Additional to that I'm not sure if that is such a good idea or not, cause > > > fence_array_signaled() should be light weight and without calling > > > enable_signaling there is not guarantee that fences will ever signal. > > It is still lightweight for the case when signaling is enabled and > > fences can signal with signaling enabled or disabled > Nope that's not correct. The signaled callback is only optional. > > See the comment on the fence_is_signaled function: > > * Returns true if the fence was already signaled, false if not. Since > > this > > * function doesn't enable signaling, it is not guaranteed to ever return > > * true if fence_add_callback, fence_wait or fence_enable_sw_signaling > > * haven't been called before. Right, I was with explicit fencing in mind, we only enable signaling there if userspace polls. > E.g. for example it is illegal to do something like > "while(!fence_is_signaled(f)) sleep();" without enabling signaling before > doing this. > > Could just be a misunderstanding, but the comments on your patch actually > sounds a bit like somebody is trying to do exactly that. I think the usecase in mind here is poll(fd, timeout=0) Gustavo
[Bug 172421] radeon: allow to set the TMDS frequency by a special kernel parameter
https://bugzilla.kernel.org/show_bug.cgi?id=172421 --- Comment #11 from Elmar Stellnberger --- For the R5 230 long time experience is already available. I am successfully using this card at least since February 2016 at a TMDS of 297Mhz and these cards are doing very well on basis of everyday use as well as occasional full throttle. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm/i915: Before pageflip, also wait for shared dmabuf fences.
Am 22.09.2016 um 15:05 schrieb Daniel Vetter: > On Thu, Sep 22, 2016 at 2:44 PM, Christian König > wrote: >>> - explicit fencing: Userspace passes around distinct fence objects for >>> any work going on on the gpu. The kernel doesn't insert any stall of >>> it's own (except for moving buffer objects around ofc). This is what >>> Android. This also seems to be what amdgpu is doing within one >>> process/owner. >> >> No, that is clearly not my understanding of explicit fencing. >> >> Userspace doesn't necessarily need to pass around distinct fence objects >> with all of it's protocols and the kernel is still responsible for inserting >> stalls whenever an userspace protocol or application requires this >> semantics. >> >> Otherwise you will never be able to use explicit fencing on the Linux >> desktop with protocols like DRI2/DRI3. > This is about mixing them. Explicit fencing still means userspace has > an explicit piece, separate from buffers, (either sync_file fd, or a > driver-specific cookie, or similar). > >> I would expect that every driver in the system waits for all fences of a >> reservation object as long as it isn't told otherwise by providing a >> distinct fence object with the IOCTL in question. > Yup agreed. This way if your explicitly-fencing driver reads a shared > buffer passed over a protocol that does implicit fencing (like > DRI2/3), then it will work. > > The other interop direction is explicitly-fencing driver passes a > buffer to a consumer which expects implicit fencing. In that case you > must attach the right fence to the exclusive slot, but _only_ in that > case. Ok well sounds like you are close to understand why I can't do exactly this: There simply is no right fence I could attach. When amdgpu makes the command submissions it doesn't necessarily know that the buffer will be exported and shared with another device later on. So when the buffer is exported and given to the other device you might have a whole bunch of fences which run concurrently and not in any serial order. > Otherwise you end up stalling your explicitly-fencing userspace, > since implicit fencing doesn't allow more than 1 writer. For amdgpu > one possible way to implement this might be to count how many users a > dma-buf has, and if it's more than just the current context set the > exclusive fence. Or do an uabi revision and let userspace decide (or > at least overwrite it). I mean I can pick one fence and wait for the rest to finish manually, but that would certainly defeat the whole effort, doesn't it? I completely agree that you have only 1 writer with implicit fencing, but when you switch from explicit fencing back to implicit fencing you can have multiple ones. > But the current approach in amdgpu_sync.c of declaring a fence as > exclusive after the fact (if owners don't match) just isn't how > reservation_object works. You can of course change that, but that > means you must change all drivers implementing support for implicit > fencing of dma-buf. Fixing amdgpu will be easier ;-) Well as far as I can see there is no way I can fix amdgpu in this case. The handling clearly needs to be changed on the receiving side of the reservation objects if I don't completely want to disable concurrent access to BOs in amdgpu. Regards, Christian. > -Daniel
[PATCH] drm/i915: Before pageflip, also wait for shared dmabuf fences.
Am 22.09.2016 um 08:36 schrieb Daniel Vetter: > On Wed, Sep 21, 2016 at 06:23:35PM +0200, Christian König wrote: >> For a quick workaround I suggest to just serialize all accesses to BO shared >> with different drivers, but essentially I think it is a perfectly valid >> requirement to have multiple writers to one BO. > It is, but it's not possible with implicit sync. If you want parallel > write access to the same shared buffer, you _must_ carry around some > explicit fences. Within amdgpu you can use driver-specific cookies, for > shared buffer we now have sync_file. But multiple writers with implicit > sync simply fundamentally doesn't work. Because you have no idea with which > writer, touching the same subrange you want to touch. You don't need to separate the BO into subranges which are touched by different engines for allowing multiple writers. AMD hardware and I'm pretty sure others as well are perfectly capable of writing to the same memory from multiple engines and even multiple GPUs at the same time. For a good hint of what is possible see the public AMD ISA documentation about atomic operations, but that is only the start of it. The crux here is that we need to assume that we will have implicit and explicit sync mixed for backward compatibility. This implies that we need some mechanism like amdgpu uses in it's sync implementation where every fence is associated with an owner which denotes the domain in which implicit sync happens. If you leave this domain you will automatically run into explicit sync. Currently we define the borders of this domain in amdgpu on process boundary to keep things like DRI2/DRI3 working as expected. I really don't see how you want to solve this with a single explicit fence for each reservation object. As long as you have multiple concurrently running operations accessing the same buffer you need to keep one fence for each operation no matter what. Regards, Christian. > -Daniel
[PATCH] drm/i915: Before pageflip, also wait for shared dmabuf fences.
Am 22.09.2016 um 14:26 schrieb Daniel Vetter: > On Thu, Sep 22, 2016 at 12:55 PM, Christian König > wrote: >> Am 22.09.2016 um 08:36 schrieb Daniel Vetter: >>> On Wed, Sep 21, 2016 at 06:23:35PM +0200, Christian König wrote: For a quick workaround I suggest to just serialize all accesses to BO shared with different drivers, but essentially I think it is a perfectly valid requirement to have multiple writers to one BO. >>> It is, but it's not possible with implicit sync. If you want parallel >>> write access to the same shared buffer, you _must_ carry around some >>> explicit fences. Within amdgpu you can use driver-specific cookies, for >>> shared buffer we now have sync_file. But multiple writers with implicit >>> sync simply fundamentally doesn't work. Because you have no idea with >>> which >>> writer, touching the same subrange you want to touch. >> >> You don't need to separate the BO into subranges which are touched by >> different engines for allowing multiple writers. >> >> AMD hardware and I'm pretty sure others as well are perfectly capable of >> writing to the same memory from multiple engines and even multiple GPUs at >> the same time. >> >> For a good hint of what is possible see the public AMD ISA documentation >> about atomic operations, but that is only the start of it. >> >> >> The crux here is that we need to assume that we will have implicit and >> explicit sync mixed for backward compatibility. >> >> This implies that we need some mechanism like amdgpu uses in it's sync >> implementation where every fence is associated with an owner which denotes >> the domain in which implicit sync happens. If you leave this domain you will >> automatically run into explicit sync. >> >> Currently we define the borders of this domain in amdgpu on process boundary >> to keep things like DRI2/DRI3 working as expected. >> >> I really don't see how you want to solve this with a single explicit fence >> for each reservation object. As long as you have multiple concurrently >> running operations accessing the same buffer you need to keep one fence for >> each operation no matter what. > I can't make sense of what you're saying, and I suspect we put > different meaning to different words. So let me define here: > > - implicit fencing: Userspace does not track read/writes to buffers, > but only the kernel does that. This is the assumption DRI2/3 has. > Since synchronization is by necessity on a per-buffer level you can > only have 1 writer. In the kernel the cross-driver interface for this > is struct reservation_object attached to dma-bufs. If you don't fill > out/wait for the exclusive fence in there, you're driver is _not_ > doing (cross-device) implicit fencing. I can confirm that my understanding of implicit fencing is exactly the same as yours. > - explicit fencing: Userspace passes around distinct fence objects for > any work going on on the gpu. The kernel doesn't insert any stall of > it's own (except for moving buffer objects around ofc). This is what > Android. This also seems to be what amdgpu is doing within one > process/owner. No, that is clearly not my understanding of explicit fencing. Userspace doesn't necessarily need to pass around distinct fence objects with all of it's protocols and the kernel is still responsible for inserting stalls whenever an userspace protocol or application requires this semantics. Otherwise you will never be able to use explicit fencing on the Linux desktop with protocols like DRI2/DRI3. I would expect that every driver in the system waits for all fences of a reservation object as long as it isn't told otherwise by providing a distinct fence object with the IOCTL in question. Regards, Christian.
[PATCH 7/7] drm: Remove dirty property from docs
On Wed, Sep 21, 2016 at 1:59 AM, Daniel Vetter
wrote:
> We removed it in
>
> commit 6ab10b76ff6252bd9be0849c40f5865e39a29961
> Author: Daniel Vetter
> Date: Fri Aug 12 22:48:45 2016 +0200
>
> drm/kms: Nuke dirty_info property
>
> Reviewed-by: Sean Paul
> Signed-off-by: Daniel Vetter
Didn't see a cover letter offhand, so arbitrarily picking this one
Applied to -misc (with some amount of effort & consternation).
Sean
> ---
> Documentation/gpu/kms-properties.csv | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/Documentation/gpu/kms-properties.csv
> b/Documentation/gpu/kms-properties.csv
> index 1a5729c4af65..981873a05d14 100644
> --- a/Documentation/gpu/kms-properties.csv
> +++ b/Documentation/gpu/kms-properties.csv
> @@ -23,7 +23,6 @@ Owner Module/Drivers,Group,Property Name,Type,Property
> Values,Object attached,De
> ,Virtual GPU,âsuggested Xâ,RANGE,"Min=0,
> Max=0x",Connector,property to suggest an X offset for a connector
> ,,âsuggested Yâ,RANGE,"Min=0, Max=0x",Connector,property to
> suggest an Y offset for a connector
> ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9""
> }",Connector,TDB
> -,,âdirtyâ,ENUM | IMMUTABLE,"{ ""Off"", ""On"", ""Annotate""
> }",Connector,TBD
> i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited
> 16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is
> set, the hardware will be programmed with the result of the multiplication of
> CTM by the limited range matrix to ensure the pixels normaly in the range
> 0..1.0 are remapped to the range 16/255..235/255."
> ,,âaudioâ,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on""
> }",Connector,TBD
> ,SDVO-TV,âmodeâ,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B""
> } etc.",Connector,TBD
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/udl: Fix for the X server screen update v2
On 19.09.2016 23:12, Daniel Vetter wrote:
> On Mon, Sep 19, 2016 at 8:27 PM, poma wrote:
>> @@ -122,14 +126,14 @@ int udl_handle_damage(struct udl_framebuffer *fb, int
>> x, int y,
>> return 0;
>> cmd = urb->transfer_buffer;
>>
>> - for (i = y; i < height ; i++) {
>> + for (i = y; i <= y2 ; i++) {
>
> I think a simpler fix (which retains Noralf's nice cleanup would be to
> change the loop condition to i < y + height. At least that seems to be
> the underlying bug. Can you pls test that and then submit either that
> one-liner (if it works) or your original patch (it's missing the
> signed-off-by right now, so can't be merged as-is)? Either one has my
> r-b (preemptive since I'm travelling).
>
> Thanks, Daniel
>
Feel free to (re)send patch v3, whenever you can.
After all, the idea is yours.
Respect
[PATCH] dma-buf/fence-array: get signaled state when signaling is disabled
Dropping the rest of the patch, cause that really doesn't make sense any more. Am 22.09.2016 um 12:40 schrieb Gustavo Padovan: >> E.g. for example it is illegal to do something like >> >"while(!fence_is_signaled(f)) sleep();" without enabling signaling before >> >doing this. >> > >> >Could just be a misunderstanding, but the comments on your patch actually >> >sounds a bit like somebody is trying to do exactly that. > I think the usecase in mind here is poll(fd, timeout=0) Exactly as I feared. Even if userspace polls with timeout=0 you still need to call enable_signaling(). Otherwise you can run into a situation where userspace only uses timeout=0 and so never activates the signaling check in the driver. This would in turn result in an endless loop on implementations where the driver never signals fences on their own. Regards, Christian. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160922/3a486b47/attachment-0001.html>
[PATCH 2/2] drm: Don't swallow error codes in drm_dev_alloc()
On Wed, Sep 21, 2016 at 04:59:19PM +0200, Tom Gundersen wrote:
> There are many reasons other than ENOMEM that drm_dev_init() can
> fail. Return ERR_PTR rather than NULL to be able to distinguish
> these in the caller.
>
> Signed-off-by: Tom Gundersen
Looks good to me :)
Assuming you fixed all the drm_dev_alloc() calls, which a quick grep
seems to confirm, this series is:
Reviewed-by: Eric Engestrom
BTW, this looks like a task for coccinelle; is that what you used?
If so, you could include your .cocci patch in the commit msg?
Cheers,
Eric
> ---
> drivers/gpu/drm/arc/arcpgu_drv.c| 4 ++--
> drivers/gpu/drm/arm/hdlcd_drv.c | 4 ++--
> drivers/gpu/drm/arm/malidp_drv.c| 4 ++--
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 4 ++--
> drivers/gpu/drm/drm_drv.c | 6 +++---
> drivers/gpu/drm/drm_pci.c | 4 ++--
> drivers/gpu/drm/drm_platform.c | 4 ++--
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 4 ++--
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 4 ++--
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 4 ++--
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 ++--
> drivers/gpu/drm/msm/msm_drv.c | 4 ++--
> drivers/gpu/drm/nouveau/nouveau_drm.c | 4 ++--
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 4 ++--
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 4 ++--
> drivers/gpu/drm/sti/sti_drv.c | 4 ++--
> drivers/gpu/drm/sun4i/sun4i_drv.c | 4 ++--
> drivers/gpu/drm/tegra/drm.c | 4 ++--
> drivers/gpu/drm/udl/udl_drv.c | 4 ++--
> drivers/gpu/drm/vc4/vc4_drv.c | 4 ++--
> drivers/gpu/drm/vgem/vgem_drv.c | 4 ++--
> drivers/gpu/drm/virtio/virtgpu_drm_bus.c| 4 ++--
> 22 files changed, 45 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c
> b/drivers/gpu/drm/arc/arcpgu_drv.c
> index 6d4ff34..28e6471 100644
> --- a/drivers/gpu/drm/arc/arcpgu_drv.c
> +++ b/drivers/gpu/drm/arc/arcpgu_drv.c
> @@ -198,8 +198,8 @@ static int arcpgu_probe(struct platform_device *pdev)
> int ret;
>
> drm = drm_dev_alloc(&arcpgu_drm_driver, &pdev->dev);
> - if (!drm)
> - return -ENOMEM;
> + if (IS_ERR(drm))
> + return PTR_ERR(drm);
>
> ret = arcpgu_load(drm);
> if (ret)
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index d83b46a..fb6a418 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -326,8 +326,8 @@ static int hdlcd_drm_bind(struct device *dev)
> return -ENOMEM;
>
> drm = drm_dev_alloc(&hdlcd_driver, dev);
> - if (!drm)
> - return -ENOMEM;
> + if (IS_ERR(drm))
> + return PTR_ERR(drm);
>
> drm->dev_private = hdlcd;
> dev_set_drvdata(dev, drm);
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> b/drivers/gpu/drm/arm/malidp_drv.c
> index c383d72..9280358 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -311,8 +311,8 @@ static int malidp_bind(struct device *dev)
> return ret;
>
> drm = drm_dev_alloc(&malidp_driver, dev);
> - if (!drm) {
> - ret = -ENOMEM;
> + if (IS_ERR(drm)) {
> + ret = PTR_ERR(drm);
> goto alloc_fail;
> }
>
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index 8e7483d..5f48431 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -797,8 +797,8 @@ static int atmel_hlcdc_dc_drm_probe(struct
> platform_device *pdev)
> int ret;
>
> ddev = drm_dev_alloc(&atmel_hlcdc_dc_driver, &pdev->dev);
> - if (!ddev)
> - return -ENOMEM;
> + if (IS_ERR(ddev))
> + return PTR_ERR(ddev);
>
> ret = atmel_hlcdc_dc_load(ddev);
> if (ret)
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 99e6751..80c7f25 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -591,7 +591,7 @@ EXPORT_SYMBOL(drm_dev_init);
> * own struct should look at using drm_dev_init() instead.
> *
> * RETURNS:
> - * Pointer to new DRM device, or NULL if out of memory.
> + * Pointer to new DRM device, or ERR_PTR on failure.
> */
> struct drm_device *drm_dev_alloc(struct drm_driver *driver,
>struct device *parent)
> @@ -601,12 +601,12 @@ struct drm_device *drm_dev_alloc(struct drm_driver
> *driver,
>
> dev = kzalloc(sizeof(*dev), GFP_KERNEL);
> if (!dev)
> - return NULL;
> + return ERR_PTR(-ENOMEM);
>
> ret = drm_dev_init(dev, driver, parent);
> if (ret) {
> kfree(dev);
> - return
[PATCH] drm/i2c: tda998x: don't register the connector
On Thu, Sep 22, 2016 at 5:09 AM, Russell King - ARM Linux wrote: > On Thu, Sep 22, 2016 at 04:22:40AM -0700, Sean Paul wrote: >> On Thu, Sep 22, 2016 at 3:51 AM, Russell King - ARM Linux >> wrote: >> > On Thu, Sep 22, 2016 at 11:39:18AM +0100, Brian Starkey wrote: >> >> Actually, could you please hold off picking this up? We need to make >> >> changes in mali-dp and hdlcd or this will mess up their registration. >> >> I will send those patches later today, but better if this all goes in >> >> together (whenever that ends up being). >> > >> > Sorry, but I'm annoyed with this - the impression being given was that >> > I was holding up this patch by not testing it on Armada, and I brought >> > up the issue about registration at the beginning of this. >> > >> > Now we're _just_ finding out that there are drivers where removing the >> > connector registration in tda998x causes them to break? It's a bit >> > late to be checking your own drivers when you've been chasing me... >> > >> > Sorry, but it sounds like we're not ready to make this change - and as >> > it's the very last day that changes will appear in linux-next prior to >> > the merge window (assuming Linus releases 4.8 on Sunday), I'd suggest >> > holding off until after the merge window is over, so we can get some >> > testing with these other two drivers with this change in place. >> > >> >> sigh. I just pushed my queue to drm-misc, which included this patch. >> Sounds like I should revert? > > Why did you do push it _without_ an ack from the maintainer of the > driver when the comments on the list were clearly indicating that it > was waiting for testing and such an ack? > Daniel Acked it on the list on 7/25, and you acked it yesterday asking it to be merged to -misc. What am I missing? Sean > There's something horribly wrong with the process here. > > -- > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up > according to speedtest.net.
[PATCH] drm/i2c: tda998x: don't register the connector
On Thu, Sep 22, 2016 at 01:28:37PM +0200, Daniel Vetter wrote: >On Thu, Sep 22, 2016 at 1:22 PM, Sean Paul wrote: >> On Thu, Sep 22, 2016 at 3:51 AM, Russell King - ARM Linux >> wrote: >>> On Thu, Sep 22, 2016 at 11:39:18AM +0100, Brian Starkey wrote: Actually, could you please hold off picking this up? We need to make changes in mali-dp and hdlcd or this will mess up their registration. I will send those patches later today, but better if this all goes in together (whenever that ends up being). >>> >>> Sorry, but I'm annoyed with this - the impression being given was that >>> I was holding up this patch by not testing it on Armada, and I brought >>> up the issue about registration at the beginning of this. >>> Sorry, this was poor on my part. There's no-one who will care about Mali-DP, but I had forgotten that this would also break HDLCD. >>> Now we're _just_ finding out that there are drivers where removing the >>> connector registration in tda998x causes them to break? It's a bit >>> late to be checking your own drivers when you've been chasing me... >>> It's not like I didn't check our drivers, more that I should have sent a full series for all three drivers together in the first place. However, without patching all three drivers in the same commit, there would always be some breakage. HDLCD and Mali-DP call drm_dev_register() before binding the components - this was needed to work with tda998x, which needed the device to be already registered before its bind callback runs. It's more proper to call drm_dev_register() as the very last thing (i.e. after component_bind_all()) to avoid races with userspace - but I couldn't do that without this change in tda998x first. >>> Sorry, but it sounds like we're not ready to make this change - and as >>> it's the very last day that changes will appear in linux-next prior to >>> the merge window (assuming Linus releases 4.8 on Sunday), I'd suggest >>> holding off until after the merge window is over, so we can get some >>> testing with these other two drivers with this change in place. >>> >> >> sigh. I just pushed my queue to drm-misc, which included this patch. >> Sounds like I should revert? > >I thought I looked at the entire situation and since we register >(since recently) all connectors in drm_dev_register() there shouldn't >be an issue for any other driver. Imo no need to revert anything here >- until someone complains with a bug report and proves me wrong ;-) Yeah... this does indeed break HDLCD and Mali-DP. They register the device, then bind tda998x which init's its connector. The connector ends up in the connector_list, but not the idr. I don't know how widely HDLCD on Juno is used (for anyone to notice). -Brian >-Daniel >-- >Daniel Vetter >Software Engineer, Intel Corporation >+41 (0) 79 365 57 48 - http://blog.ffwll.ch >
GPU-DRM-OMAP: Fine-tuning for several function implementations
>> For the next pile of driver patches _please_ talk with driver maintainers >> before starting to create&submit patches. Did the software development discussion start a bit here? Would you like to support an other "talking style" on a conference like in Berlin next month? >> Like I said I won't take them, It's a pity. >> and many of your changes are not clear-cut at all, I know that specific update suggestions could be interpreted as controversial. >> so I expect many driver maintaines also won't take them. I am curious on useful responses. >> Again, your contributions are welcome, Thanks for another bit of constructive feedback. >> but blindly following suggestions from code checkers in drivers I propose to dare another look at corresponding information sources. >> you cant test isn't really all that useful. I have got an other impression. How many improvements can still be achieved by usual (advanced) collaboration techniques for free software development? >> At the scale you're doing it, I think it's mostly wasting everyone's time I hope not. > :( I'd like to avoid that. I am going to point more update opportunities out also for various Linux software. > I second that. Thanks for your opinion on this issue. > After a very quick review, I see that the series splits related changes > in multiple patches. I chose a specific patch granularity for this proposal. > I've already commented in reply to another series submitted by Markus > that patches should then be combined. Will such a combination depend on any more agreements between the involved contributors? > I will thus ignore this series completely for the time being. I hope that you can give similar ideas a second chance somehow. Regards, Markus
[PATCH v4 10/14] drm: amdgpu: Replace drm_fb_get_bpp_depth() with drm_format_plane_cpp()
Hi Daniel,
On Thursday 22 Sep 2016 07:31:24 Daniel Vetter wrote:
> On Wed, Sep 21, 2016 at 3:59 PM, Laurent Pinchart wrote:
> > On Wednesday 21 Sep 2016 14:46:07 Daniel Vetter wrote:
> >> On Wed, Sep 21, 2016 at 2:39 PM, Laurent Pinchart wrote:
> > @@ -82,7 +82,7 @@ int amdgpu_align_pitch(struct amdgpu_device *adev,
> > int width, int bpp, bool tile
> >
> > aligned += pitch_mask;
> > aligned &= ~pitch_mask;
> >
> > - return aligned;
> > + return aligned * cpp;
>
> Now you multiply by cpp after the rounding.
> >>>
> >>> That's right, but I don't think that's a problem, as all bpp values
> >>> returned by drm_fb_get_bpp_depth() are multiple of 8 bits.
> >>
> >> Before we have ALIGN(width * cpp, pitch_mask + 1). With your patch we
> >> have ALIGN(width, pitch_mask + 1) * cpp. In short we overalign, and
> >> instead of e.g. aligning to 256bytes we now align to 256*4 (for
> >> xrgb).
> >
> > The current code is
> >
> > mode_cmd->pitches[0] = amdgpu_align_pitch(adev, mode_cmd->width,
> > bpp,
> > fb_tiled) * ((bpp + 1) /
> > 8);
> >
> > As bpp is a multiple of 8, this is equivalent to
> >
> > mode_cmd->pitches[0] = amdgpu_align_pitch(adev, mode_cmd->width,
> > bpp,
> > fb_tiled) * (bpp / 8);
> >
> > The patch replaces the code with
> >
> > mode_cmd->pitches[0] = amdgpu_align_pitch(adev, mode_cmd->width,
> > cpp,
> > fb_tiled);
> >
> > with cpp = bpp / 8, and amdgpu_align_pitch() now returns
> >
> > - return aligned;
> > + return aligned * cpp;
> >
> > So the patch just moves * (bpp / 8) inside the amdgpu_align_pitch()
> > function.
> >
> > The other code path is changed as follows:
> >
> > - args->pitch = amdgpu_align_pitch(adev, args->width, args->bpp, 0)
> > *
> > ((args->bpp + 1) / 8);
> > + args->pitch = amdgpu_align_pitch(adev, args->width,
> > +DIV_ROUND_UP(args->bpp, 8), 0);
> >
> > DIV_ROUND_UP(args->bpp, 8) is equal to ((args->bpp + 1) / 8) for all
> > supported bpp values, so this also moves the multiplication inside the
> > function, without changing the result as far as I can see.
> >
> > Note that amdgpu_align_width() is also changed as follows
> >
> > - switch (bpp / 8) {
> > + switch (cpp) {
> > case 1:
> > pitch_mask = 255;
> > break;
> > case 2:
> > pitch_mask = 127;
> > break;
> > case 3:
> > case 4:
> > pitch_mask = 63;
> > break;
> > }
> >
> > This will change the pitch mask if the bpp value isn't a multiple of 8.
> > However, all the formats we support use multiples of 8 as bpp values, so I
> > don't see a problem here.
>
> All correct. The trouble is that you move the * cpp over the following code:
>
> aligned += pitch_mask;
> aligned &= ~pitch_mask;
>
> Multiplying by 4 (for xrgb) before or after aligning to pitch_mask
> does make a difference.
It would, but the multiplication is done *after* that block of code, isn't it
?
aligned += pitch_mask;
aligned &= ~pitch_mask;
- return aligned;
+ return aligned * cpp
--
Regards,
Laurent Pinchart
[PATCH] dma-buf/fence-array: get signaled state when signaling is disabled
Am 22.09.2016 um 09:44 schrieb Gustavo Padovan: > Hi Christian, > > 2016-09-21 Christian König : > >> Am 21.09.2016 um 13:36 schrieb Gustavo Padovan: >>> From: Gustavo Padovan >>> >>> If the fences in the fence_array signal on the fence_array does not have >>> signalling enabled num_pending will not be updated accordingly. >>> >>> So when signaling is disabled check the signal of every fence with >>> fence_is_signaled() and then compare with num_pending to learn if the >>> fence_array was signalled or not. >>> >>> If we want to keep the poll_does_not_wait optimization I think we need >>> something like this. It keeps the same behaviour if signalling is enabled >>> but tries to calculated the state otherwise. >>> >>> Signed-off-by: Gustavo Padovan >>> Reviewed-by: Chris Wilson >> First of all the patch is horrible wrong because fence_array_signaled() is >> called without any locks held. So you can run into a race condition between >> checking the fences here and enable signaling. > Yes. it can, but I don't think the race condition is actually a problem. > Maybe you have some use case that we are not seeing? I'm not sure if that can really race, but if it does the check would return true while not all necessary fences are signaled yet. That would be really really bad for things like TTM where we just do a quick check in the page fault handler for example. I need to double check if that really could be a problem. >> Additional to that I'm not sure if that is such a good idea or not, cause >> fence_array_signaled() should be light weight and without calling >> enable_signaling there is not guarantee that fences will ever signal. > It is still lightweight for the case when signaling is enabled and > fences can signal with signaling enabled or disabled Nope that's not correct. The signaled callback is only optional. See the comment on the fence_is_signaled function: > * Returns true if the fence was already signaled, false if not. Since > this > * function doesn't enable signaling, it is not guaranteed to ever return > * true if fence_add_callback, fence_wait or fence_enable_sw_signaling > * haven't been called before. E.g. for example it is illegal to do something like "while(!fence_is_signaled(f)) sleep();" without enabling signaling before doing this. Could just be a misunderstanding, but the comments on your patch actually sounds a bit like somebody is trying to do exactly that. Regards, Christian. > so I don't see that > as problem too. > > Gustavo >
[PATCH] dma-buf/sync_file: free fences array in num_fences is 1
On Wed, Sep 21, 2016 at 4:12 AM, Chris Wilson
wrote:
> On Wed, Sep 21, 2016 at 10:20:19AM +0300, Gustavo Padovan wrote:
>> From: Gustavo Padovan
>>
>> When merging sync_files there is a case when we can end up with only one
>> fence in the merged sync_file: when all fences belong to the same
>> timeline.
>>
>> So for this case a fence_array is not created instead we just assigned the
>> fence to sync_file->fence. Then we do not use the fences array anymore nor
>> does free it.
>>
>> This patch frees the array.
>>
>> Signed-off-by: Gustavo Padovan
>> Reported-by: Chris Wilson
>> ---
>> drivers/dma-buf/sync_file.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
>> index 706eea9..9ed4f9f 100644
>> --- a/drivers/dma-buf/sync_file.c
>> +++ b/drivers/dma-buf/sync_file.c
>> @@ -150,6 +150,7 @@ static int sync_file_set_fence(struct sync_file
>> *sync_file,
>>*/
>> if (num_fences == 1) {
>> sync_file->fence = fences[0];
>> + kfree(fences);
>
> Ok, that makes sense wrt the code. I don't see any particular advantage
> in a warning comment, so
> Reviewed-by: Chris Wilson
Thanks, applied to -misc
Sean
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm: Distinguish no name from ENOMEM in set_unique()
On Wed, Sep 21, 2016 at 7:59 AM, Tom Gundersen wrote:
> If passing name == NULL to drm_drv_set_unique() we now get -ENOMEM
> as kstrdup() returns NULL. Instead check for this explicitly and
> return -EINVAL if no name is provided.
>
> Signed-off-by: Tom Gundersen
Thanks, applied to -misc
Sean
> ---
> drivers/gpu/drm/drm_drv.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index f2f6429..99e6751 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -338,6 +338,9 @@ void drm_minor_release(struct drm_minor *minor)
>
> static int drm_dev_set_unique(struct drm_device *dev, const char *name)
> {
> + if (!name)
> + return -EINVAL;
> +
> kfree(dev->unique);
> dev->unique = kstrdup(name, GFP_KERNEL);
>
> --
> 2.9.3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] GPU-DRM-QXL: Fine-tuning for three function implementations
From: Markus Elfring Date: Thu, 22 Sep 2016 08:08:08 +0200 A few update suggestions were taken into account from static source code analysis. Markus Elfring (4): Use kmalloc_array() in qxl_device_init() Move three assignments in qxl_device_init() Improve a size determination in qxl_driver_load() Adjust checks for null pointers in three functions drivers/gpu/drm/qxl/qxl_kms.c | 26 +- 1 file changed, 13 insertions(+), 13 deletions(-) -- 2.10.0
drm/exynos: probe deferral for sub drivers
On 21.09.2016 00:07, Tobias Jakobi wrote: > Hello, > > I'm currently facing the following problem. > > I want to use a devfreq device in one of the Exynos sub drivers, namely > the G2D sub driver. My current approach is to use > devfreq_get_devfreq_by_phandle() in g2d_probe(). But at the G2D probing > time the devfreq subsystem isn't initialized yet, and I get EPROBE_DEFER > back. > > Now I simply let g2d_probe() fail with EPROBE_DEFER in that case. > Eventually devfreq is online and g2d_probe() runs successfully. > > So far, so good. However some debugging shows that g2d_subdrv_probe(), > which does IOMMU setup and allocates the cmdlist, never happens in that > case. > > I've looked at exynos_drm_load() which issues > exynos_drm_device_subdrv_probe() at some point, which apparantly only > probes those devices which are registered at that time. Hence, if the > G2D probe hasn't happened until then, the Exynos DRM won't ever see it. > > That made me wonder how the driver makes sure that the sub drivers are > all readily probed in that situation. I see that a component_bind_all() > is issued prior to subdrv probing, but both the G2D and the IPP subdrv > don't have bind/unbind calls. I guess subdrv != subdrv, eh? > > At present it appears that it's merely luck that the G2D is probed when > sub drivers are probed? > > Anyway, probe deferral seems to work correctly with Exynos HDMI, so I > was wondering if there is some way to also make it work with the G2D? HDMI is componentized, G2D no, so it does not work with deferred probe. The best solution at the moment is to componentize G2D, it should not be difficult. Regards Andrzej > > Thanks in advance! > > With best wishes, > Tobias > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 172421] radeon: allow to set the TMDS frequency by a special kernel parameter
https://bugzilla.kernel.org/show_bug.cgi?id=172421 --- Comment #12 from Elmar Stellnberger --- Today I approached to try out the dual-link feature of the DVI-port. First I had verified with AOC that my u2868pqu monitor in deed supports dual-link over DVI. Then I connected the DVI output of my R5 230 (comment #6) with the u2868pqu monitor over DVI. Trying to boot with a vanilla/hdmimhz=0 I just ended up with a black screen. Finally I did succeed to get a picture by setting hdmimhz=165. Firstly amazed I then noticed that hdmimhz does also disable the duallink feature which was obviously the cause why it worked with hdmimhz. My explanation for this is that the radeon driver detected both the display and the card to support dual-link DVI. However the cable does not. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 00/14] GPU-DRM-OMAP: Fine-tuning for several function implementations
On Thursday 22 Sep 2016 08:45:01 Daniel Vetter wrote: > On Wed, Sep 21, 2016 at 06:35:59PM +0200, SF Markus Elfring wrote: > > From: Markus Elfring > > Date: Wed, 21 Sep 2016 18:28:38 +0200 > > > > Several update suggestions were taken into account > > from static source code analysis. > > For the next pile of driver patches _please_ talk with driver maintainers > before starting to create&submit patches. Like I said I won't take them, > and many of your changes are not clear-cut at all, so I expect many driver > maintaines also won't take them. Again, your contributions are welcome, > but blindly following suggestions from code checkers in drivers you cant > test isn't really all that useful. At the scale you're doing it, I think > it's mostly wasting everyone's time :( I'd like to avoid that. I second that. After a very quick review, I see that the series splits related changes in multiple patches. I've already commented in reply to another series submitted by Markus that patches should then be combined. I will thus ignore this series completely for the time being. > > Markus Elfring (14): > > Use kmalloc_array() in tiler_map_show() > > Replace another kmalloc() call by kmalloc_array() in tiler_map_show() > > Less function calls in tiler_map_show() after error detection > > Delete an unnecessary variable initialisation in tiler_map_show() > > Improve a size determination in dmm_txn_append() > > Improve a size determination in omap_dmm_probe() > > Rename a jump label in omap_dmm_probe() > > Rename a jump label in dmm_txn_commit() > > Delete an unnecessary variable initialisation in dmm_txn_commit() > > Use kmalloc_array() in omap_gem_attach_pages() > > Replace a kzalloc() call by kcalloc() in omap_gem_attach_pages() > > Move a variable assignment in omap_gem_attach_pages() > > Rename a jump label in omap_gem_new_dmabuf() > > Rename a jump label in four functions > > > > drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 58 +-- > > drivers/gpu/drm/omapdrm/omap_gem.c | 44 +++- > > 2 files changed, 49 insertions(+), 53 deletions(-) -- Regards, Laurent Pinchart
[PATCH 2/2] drm: Don't swallow error codes in drm_dev_alloc()
On Wed, Sep 21, 2016 at 7:59 AM, Tom Gundersen wrote:
> There are many reasons other than ENOMEM that drm_dev_init() can
> fail. Return ERR_PTR rather than NULL to be able to distinguish
> these in the caller.
>
> Signed-off-by: Tom Gundersen
Thanks, applied to -misc
Sean
> ---
> drivers/gpu/drm/arc/arcpgu_drv.c| 4 ++--
> drivers/gpu/drm/arm/hdlcd_drv.c | 4 ++--
> drivers/gpu/drm/arm/malidp_drv.c| 4 ++--
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 4 ++--
> drivers/gpu/drm/drm_drv.c | 6 +++---
> drivers/gpu/drm/drm_pci.c | 4 ++--
> drivers/gpu/drm/drm_platform.c | 4 ++--
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 4 ++--
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 4 ++--
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 4 ++--
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 ++--
> drivers/gpu/drm/msm/msm_drv.c | 4 ++--
> drivers/gpu/drm/nouveau/nouveau_drm.c | 4 ++--
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 4 ++--
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 4 ++--
> drivers/gpu/drm/sti/sti_drv.c | 4 ++--
> drivers/gpu/drm/sun4i/sun4i_drv.c | 4 ++--
> drivers/gpu/drm/tegra/drm.c | 4 ++--
> drivers/gpu/drm/udl/udl_drv.c | 4 ++--
> drivers/gpu/drm/vc4/vc4_drv.c | 4 ++--
> drivers/gpu/drm/vgem/vgem_drv.c | 4 ++--
> drivers/gpu/drm/virtio/virtgpu_drm_bus.c| 4 ++--
> 22 files changed, 45 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c
> b/drivers/gpu/drm/arc/arcpgu_drv.c
> index 6d4ff34..28e6471 100644
> --- a/drivers/gpu/drm/arc/arcpgu_drv.c
> +++ b/drivers/gpu/drm/arc/arcpgu_drv.c
> @@ -198,8 +198,8 @@ static int arcpgu_probe(struct platform_device *pdev)
> int ret;
>
> drm = drm_dev_alloc(&arcpgu_drm_driver, &pdev->dev);
> - if (!drm)
> - return -ENOMEM;
> + if (IS_ERR(drm))
> + return PTR_ERR(drm);
>
> ret = arcpgu_load(drm);
> if (ret)
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index d83b46a..fb6a418 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -326,8 +326,8 @@ static int hdlcd_drm_bind(struct device *dev)
> return -ENOMEM;
>
> drm = drm_dev_alloc(&hdlcd_driver, dev);
> - if (!drm)
> - return -ENOMEM;
> + if (IS_ERR(drm))
> + return PTR_ERR(drm);
>
> drm->dev_private = hdlcd;
> dev_set_drvdata(dev, drm);
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> b/drivers/gpu/drm/arm/malidp_drv.c
> index c383d72..9280358 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -311,8 +311,8 @@ static int malidp_bind(struct device *dev)
> return ret;
>
> drm = drm_dev_alloc(&malidp_driver, dev);
> - if (!drm) {
> - ret = -ENOMEM;
> + if (IS_ERR(drm)) {
> + ret = PTR_ERR(drm);
> goto alloc_fail;
> }
>
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index 8e7483d..5f48431 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -797,8 +797,8 @@ static int atmel_hlcdc_dc_drm_probe(struct
> platform_device *pdev)
> int ret;
>
> ddev = drm_dev_alloc(&atmel_hlcdc_dc_driver, &pdev->dev);
> - if (!ddev)
> - return -ENOMEM;
> + if (IS_ERR(ddev))
> + return PTR_ERR(ddev);
>
> ret = atmel_hlcdc_dc_load(ddev);
> if (ret)
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 99e6751..80c7f25 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -591,7 +591,7 @@ EXPORT_SYMBOL(drm_dev_init);
> * own struct should look at using drm_dev_init() instead.
> *
> * RETURNS:
> - * Pointer to new DRM device, or NULL if out of memory.
> + * Pointer to new DRM device, or ERR_PTR on failure.
> */
> struct drm_device *drm_dev_alloc(struct drm_driver *driver,
> struct device *parent)
> @@ -601,12 +601,12 @@ struct drm_device *drm_dev_alloc(struct drm_driver
> *driver,
>
> dev = kzalloc(sizeof(*dev), GFP_KERNEL);
> if (!dev)
> - return NULL;
> + return ERR_PTR(-ENOMEM);
>
> ret = drm_dev_init(dev, driver, parent);
> if (ret) {
> kfree(dev);
> - return NULL;
> + return ERR_PTR(ret);
> }
>
> return dev;
> diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
> index d86362f..3ceea9c 100644
> --- a/drivers/gpu/drm/drm_pci
[PATCH] drm/imx: hide an unused label
The imx_drm_bind function causes a warning in linux-next when
CONFIG_DRM_FBDEV_EMULATION is not set:
drivers/gpu/drm/imx/imx-drm-core.c: In function 'imx_drm_bind':
drivers/gpu/drm/imx/imx-drm-core.c:441:1: error: label 'err_unbind' defined but
not used [-Werror=unused-label]
I don't understand why the warning only showed up now, as the
code has not been modified recently, but there is an obvious
fix in adding another #if for the symbol.
Signed-off-by: Arnd Bergmann
Fixes: c1ff5a7aa3c3 ("drm/imx: Remove local fbdev emulation Kconfig option")
---
drivers/gpu/drm/imx/imx-drm-core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
b/drivers/gpu/drm/imx/imx-drm-core.c
index 98df09c2b388..b084c571b23f 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -436,9 +436,11 @@ static int imx_drm_bind(struct device *dev)
err_fbhelper:
drm_kms_helper_poll_fini(drm);
+#if IS_ENABLED(CONFIG_DRM_FBDEV_EMULATION)
if (imxdrm->fbhelper)
drm_fbdev_cma_fini(imxdrm->fbhelper);
err_unbind:
+#endif
component_unbind_all(drm->dev, drm);
err_vblank:
drm_vblank_cleanup(drm);
--
2.9.0
[PATCH] dma-buf/sw_sync: mark sync_timeline_create() static
On Tue, Sep 20, 2016 at 06:23:33PM +0530, Sumit Semwal wrote: > Hi Baoyou, > > On 20 September 2016 at 16:43, Gustavo Padovan wrote: > > 2016-09-18 Baoyou Xie : > > > >> We get 1 warning when building kernel with W=1: > >> drivers/dma-buf/sw_sync.c:87:23: warning: no previous prototype for > >> 'sync_timeline_create' [-Wmissing-prototypes] > >> > >> In fact, this function is only used in the file in which it is > >> declared and don't need a declaration, but can be made static. > >> So this patch marks it 'static'. > >> > >> Signed-off-by: Baoyou Xie > >> --- > >> drivers/dma-buf/sw_sync.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > > > > Thanks for finding this. > > Thanks for the patch; this doesn't apply to mainline yet, since the > de-staging of sw_sync code is queued for 4.9 via Greg-KH's tree. > CC'ing him. > > Greg, would it be possible to please take this via your tree? If someone resends it to me with the needed acks and reviewed-by, I will. thanks, greg k-h
drm/exynos: probe deferral for sub drivers
Hey Andrzej, Andrzej Hajda wrote: > On 21.09.2016 00:07, Tobias Jakobi wrote: >> Hello, >> >> I'm currently facing the following problem. >> >> I want to use a devfreq device in one of the Exynos sub drivers, namely >> the G2D sub driver. My current approach is to use >> devfreq_get_devfreq_by_phandle() in g2d_probe(). But at the G2D probing >> time the devfreq subsystem isn't initialized yet, and I get EPROBE_DEFER >> back. >> >> Now I simply let g2d_probe() fail with EPROBE_DEFER in that case. >> Eventually devfreq is online and g2d_probe() runs successfully. >> >> So far, so good. However some debugging shows that g2d_subdrv_probe(), >> which does IOMMU setup and allocates the cmdlist, never happens in that >> case. >> >> I've looked at exynos_drm_load() which issues >> exynos_drm_device_subdrv_probe() at some point, which apparantly only >> probes those devices which are registered at that time. Hence, if the >> G2D probe hasn't happened until then, the Exynos DRM won't ever see it. >> >> That made me wonder how the driver makes sure that the sub drivers are >> all readily probed in that situation. I see that a component_bind_all() >> is issued prior to subdrv probing, but both the G2D and the IPP subdrv >> don't have bind/unbind calls. I guess subdrv != subdrv, eh? >> >> At present it appears that it's merely luck that the G2D is probed when >> sub drivers are probed? >> >> Anyway, probe deferral seems to work correctly with Exynos HDMI, so I >> was wondering if there is some way to also make it work with the G2D? > > HDMI is componentized, G2D no, so it does not work with deferred probe. > The best solution at the moment is to componentize G2D, it should > not be difficult. I see! I try to look into this, but probably I'm going to ask for help again. If that's OK with you? ;-) With best wishes, Tobias > > Regards > Andrzej > >> >> Thanks in advance! >> >> With best wishes, >> Tobias >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > >
[PATCH v4 10/14] drm: amdgpu: Replace drm_fb_get_bpp_depth() with drm_format_plane_cpp()
On Wed, Sep 21, 2016 at 3:59 PM, Laurent Pinchart
wrote:
> Hi Daniel,
>
> On Wednesday 21 Sep 2016 14:46:07 Daniel Vetter wrote:
>> On Wed, Sep 21, 2016 at 2:39 PM, Laurent Pinchart wrote:
>> >> > @@ -82,7 +82,7 @@ int amdgpu_align_pitch(struct amdgpu_device *adev,
>> >> > int width, int bpp, bool tile
>> >> >
>> >> > aligned += pitch_mask;
>> >> > aligned &= ~pitch_mask;
>> >> >
>> >> > - return aligned;
>> >> > + return aligned * cpp;
>> >>
>> >> Now you multiply by cpp after the rounding.
>> >
>> > That's right, but I don't think that's a problem, as all bpp values
>> > returned by drm_fb_get_bpp_depth() are multiple of 8 bits.
>>
>> Before we have ALIGN(width * cpp, pitch_mask + 1). With your patch we
>> have ALIGN(width, pitch_mask + 1) * cpp. In short we overalign, and
>> instead of e.g. aligning to 256bytes we now align to 256*4 (for
>> xrgb).
>
> The current code is
>
> mode_cmd->pitches[0] = amdgpu_align_pitch(adev, mode_cmd->width, bpp,
> fb_tiled) * ((bpp + 1) / 8);
>
> As bpp is a multiple of 8, this is equivalent to
>
> mode_cmd->pitches[0] = amdgpu_align_pitch(adev, mode_cmd->width, bpp,
> fb_tiled) * (bpp / 8);
>
> The patch replaces the code with
>
> mode_cmd->pitches[0] = amdgpu_align_pitch(adev, mode_cmd->width, cpp,
> fb_tiled);
>
> with cpp = bpp / 8, and amdgpu_align_pitch() now returns
>
> - return aligned;
> + return aligned * cpp;
>
> So the patch just moves * (bpp / 8) inside the amdgpu_align_pitch() function.
>
> The other code path is changed as follows:
>
> - args->pitch = amdgpu_align_pitch(adev, args->width, args->bpp, 0) *
> ((args->bpp + 1) / 8);
> + args->pitch = amdgpu_align_pitch(adev, args->width,
> +DIV_ROUND_UP(args->bpp, 8), 0);
>
> DIV_ROUND_UP(args->bpp, 8) is equal to ((args->bpp + 1) / 8) for all supported
> bpp values, so this also moves the multiplication inside the function, without
> changing the result as far as I can see.
>
> Note that amdgpu_align_width() is also changed as follows
>
> - switch (bpp / 8) {
> + switch (cpp) {
> case 1:
> pitch_mask = 255;
> break;
> case 2:
> pitch_mask = 127;
> break;
> case 3:
> case 4:
> pitch_mask = 63;
> break;
> }
>
> This will change the pitch mask if the bpp value isn't a multiple of 8.
> However, all the formats we support use multiples of 8 as bpp values, so I
> don't see a problem here.
All correct. The trouble is that you move the * cpp over the following code:
aligned += pitch_mask;
aligned &= ~pitch_mask;
Multiplying by 4 (for xrgb) before or after aligning to pitch_mask
does make a difference.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] dma-buf/fence-array: get signaled state when signaling is disabled
Am 22.09.2016 um 13:16 schrieb Gustavo Padovan: > 2016-09-22 Christian König : > >> Dropping the rest of the patch, cause that really doesn't make sense any >> more. >> >> Am 22.09.2016 um 12:40 schrieb Gustavo Padovan: E.g. for example it is illegal to do something like > "while(!fence_is_signaled(f)) sleep();" without enabling signaling before > doing this. > > Could just be a misunderstanding, but the comments on your patch actually > sounds a bit like somebody is trying to do exactly that. >>> I think the usecase in mind here is poll(fd, timeout=0) >> Exactly as I feared. Even if userspace polls with timeout=0 you still need >> to call enable_signaling(). >> >> Otherwise you can run into a situation where userspace only uses timeout=0 >> and so never activates the signaling check in the driver. >> >> This would in turn result in an endless loop on implementations where the >> driver never signals fences on their own. > Polling is optional, userspace may never call it. And DRM/KMS or GPU > drivers will be doing fence_wait() themselves so signaling is enabled at > some point. No they won't. We have an use case where we clearly want to avoid that as much as possible because and so the driver never calls enable_signaling() on it's own. Exposing this poll function to userspace without enabling signaling is a clear NAK from my side. Christian. > > Gustavo >
[PATCH] dma-buf/fence-array: get signaled state when signaling is disabled
Am 22.09.2016 um 16:11 schrieb Christian König: > Am 22.09.2016 um 13:16 schrieb Gustavo Padovan: >> 2016-09-22 Christian König : >> >>> Dropping the rest of the patch, cause that really doesn't make sense >>> any >>> more. >>> >>> Am 22.09.2016 um 12:40 schrieb Gustavo Padovan: > E.g. for example it is illegal to do something like >> "while(!fence_is_signaled(f)) sleep();" without enabling >> signaling before >> doing this. >> >> Could just be a misunderstanding, but the comments on your patch >> actually >> sounds a bit like somebody is trying to do exactly that. I think the usecase in mind here is poll(fd, timeout=0) >>> Exactly as I feared. Even if userspace polls with timeout=0 you >>> still need >>> to call enable_signaling(). >>> >>> Otherwise you can run into a situation where userspace only uses >>> timeout=0 >>> and so never activates the signaling check in the driver. >>> >>> This would in turn result in an endless loop on implementations >>> where the >>> driver never signals fences on their own. >> Polling is optional, userspace may never call it. And DRM/KMS or GPU >> drivers will be doing fence_wait() themselves so signaling is enabled at >> some point. > > No they won't. We have an use case where we clearly want to avoid that > as much as possible because and so the driver never calls > enable_signaling() on it's own. Sorry hitting send to soon. That should read "because of the extreme overhead". Christian. > > Exposing this poll function to userspace without enabling signaling is > a clear NAK from my side. > > Christian. > >> >> Gustavo >> >
[PATCH] drm/i2c: tda998x: don't register the connector
Hi Sean, On Thu, Sep 22, 2016 at 04:22:40AM -0700, Sean Paul wrote: >On Thu, Sep 22, 2016 at 3:51 AM, Russell King - ARM Linux > wrote: >> On Thu, Sep 22, 2016 at 11:39:18AM +0100, Brian Starkey wrote: >>> Actually, could you please hold off picking this up? We need to make >>> changes in mali-dp and hdlcd or this will mess up their registration. >>> I will send those patches later today, but better if this all goes in >>> together (whenever that ends up being). >> >> Sorry, but I'm annoyed with this - the impression being given was that >> I was holding up this patch by not testing it on Armada, and I brought >> up the issue about registration at the beginning of this. >> >> Now we're _just_ finding out that there are drivers where removing the >> connector registration in tda998x causes them to break? It's a bit >> late to be checking your own drivers when you've been chasing me... >> >> Sorry, but it sounds like we're not ready to make this change - and as >> it's the very last day that changes will appear in linux-next prior to >> the merge window (assuming Linus releases 4.8 on Sunday), I'd suggest >> holding off until after the merge window is over, so we can get some >> testing with these other two drivers with this change in place. >> > >sigh. I just pushed my queue to drm-misc, which included this patch. >Sounds like I should revert? > Yes, please revert this. There's a problem in the fbdev helper code which stops me fixing this quickly, so better to revert it. Very sorry for the mess. -Brian >Sean > > >> -- >> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ >> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up >> according to speedtest.net. >
[PATCH] drm/i2c: tda998x: don't register the connector
Thanks Russell, it's most appreciated. On Wed, Sep 21, 2016 at 05:28:03PM +0100, Russell King - ARM Linux wrote: >On Wed, Sep 21, 2016 at 09:57:38AM +0100, Brian Starkey wrote: >> Hi Russell, >> >> Are you in a position to be able to test this now? > >Normally, I'd say no, because I'd normally wait for 4.8 to be out before >moving the cubox tree up. However, as we're close to 4.8, I've merged >4.8-rc7 in (and fixed the multitude of conflicts), and manually made the >changes in your patch. Nothing seems to have broken, so I think we're >good. > >Acked-by: Russell King > >Daniel, please take this change through the drm-misc tree as I'm unlikely >to have a branch which I can apply it to until after the merge window >opens. > Actually, could you please hold off picking this up? We need to make changes in mali-dp and hdlcd or this will mess up their registration. I will send those patches later today, but better if this all goes in together (whenever that ends up being). Thanks, Brian >-- >RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ >FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up >according to speedtest.net. >
[PATCH] dma-buf/fence-array: get signaled state when signaling is disabled
2016-09-22 Christian König : > Dropping the rest of the patch, cause that really doesn't make sense any > more. > > Am 22.09.2016 um 12:40 schrieb Gustavo Padovan: > > > E.g. for example it is illegal to do something like > > > >"while(!fence_is_signaled(f)) sleep();" without enabling signaling before > > > >doing this. > > > > > > > >Could just be a misunderstanding, but the comments on your patch actually > > > >sounds a bit like somebody is trying to do exactly that. > > I think the usecase in mind here is poll(fd, timeout=0) > > Exactly as I feared. Even if userspace polls with timeout=0 you still need > to call enable_signaling(). > > Otherwise you can run into a situation where userspace only uses timeout=0 > and so never activates the signaling check in the driver. > > This would in turn result in an endless loop on implementations where the > driver never signals fences on their own. Polling is optional, userspace may never call it. And DRM/KMS or GPU drivers will be doing fence_wait() themselves so signaling is enabled at some point. Gustavo
[Bug 172421] radeon: allow to set the TMDS frequency by a special kernel parameter
https://bugzilla.kernel.org/show_bug.cgi?id=172421 Christian König changed: What|Removed |Added CC||deathsimple at vodafone.de --- Comment #10 from Christian König --- Driving the PLL and transmitter way over it's limit is clearly not a good idea and can potentially cause hardware failure in the long term. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 2/4] GPU-DRM-TILCDC: Return directly after a failed kfree_table_init() in tilcdc_convert_slave_node()
This one is actually a bug fix... But finding bug fixes in this series is like looking for kernels of edible corn in piles of monkey poop. Also, classic "One Err" bug. regards, dan carpenter
[PATCH 2/2] drm: Don't swallow error codes in drm_dev_alloc()
On Thu, Sep 22, 2016 at 11:47 AM, Eric Engestrom
wrote:
> On Wed, Sep 21, 2016 at 04:59:19PM +0200, Tom Gundersen wrote:
>> There are many reasons other than ENOMEM that drm_dev_init() can
>> fail. Return ERR_PTR rather than NULL to be able to distinguish
>> these in the caller.
>>
>> Signed-off-by: Tom Gundersen
>
> Looks good to me :)
> Assuming you fixed all the drm_dev_alloc() calls, which a quick grep
> seems to confirm, this series is:
> Reviewed-by: Eric Engestrom
Thanks.
> BTW, this looks like a task for coccinelle; is that what you used?
> If so, you could include your .cocci patch in the commit msg?
Probably could have used coccinelle, though I just did git grep and
fixed it up manually.
Cheers,
Tom
> Cheers,
> Eric
>
>> ---
>> drivers/gpu/drm/arc/arcpgu_drv.c| 4 ++--
>> drivers/gpu/drm/arm/hdlcd_drv.c | 4 ++--
>> drivers/gpu/drm/arm/malidp_drv.c| 4 ++--
>> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 4 ++--
>> drivers/gpu/drm/drm_drv.c | 6 +++---
>> drivers/gpu/drm/drm_pci.c | 4 ++--
>> drivers/gpu/drm/drm_platform.c | 4 ++--
>> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 4 ++--
>> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 4 ++--
>> drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 4 ++--
>> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 ++--
>> drivers/gpu/drm/msm/msm_drv.c | 4 ++--
>> drivers/gpu/drm/nouveau/nouveau_drm.c | 4 ++--
>> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 4 ++--
>> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 4 ++--
>> drivers/gpu/drm/sti/sti_drv.c | 4 ++--
>> drivers/gpu/drm/sun4i/sun4i_drv.c | 4 ++--
>> drivers/gpu/drm/tegra/drm.c | 4 ++--
>> drivers/gpu/drm/udl/udl_drv.c | 4 ++--
>> drivers/gpu/drm/vc4/vc4_drv.c | 4 ++--
>> drivers/gpu/drm/vgem/vgem_drv.c | 4 ++--
>> drivers/gpu/drm/virtio/virtgpu_drm_bus.c| 4 ++--
>> 22 files changed, 45 insertions(+), 45 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c
>> b/drivers/gpu/drm/arc/arcpgu_drv.c
>> index 6d4ff34..28e6471 100644
>> --- a/drivers/gpu/drm/arc/arcpgu_drv.c
>> +++ b/drivers/gpu/drm/arc/arcpgu_drv.c
>> @@ -198,8 +198,8 @@ static int arcpgu_probe(struct platform_device *pdev)
>> int ret;
>>
>> drm = drm_dev_alloc(&arcpgu_drm_driver, &pdev->dev);
>> - if (!drm)
>> - return -ENOMEM;
>> + if (IS_ERR(drm))
>> + return PTR_ERR(drm);
>>
>> ret = arcpgu_load(drm);
>> if (ret)
>> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c
>> b/drivers/gpu/drm/arm/hdlcd_drv.c
>> index d83b46a..fb6a418 100644
>> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
>> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
>> @@ -326,8 +326,8 @@ static int hdlcd_drm_bind(struct device *dev)
>> return -ENOMEM;
>>
>> drm = drm_dev_alloc(&hdlcd_driver, dev);
>> - if (!drm)
>> - return -ENOMEM;
>> + if (IS_ERR(drm))
>> + return PTR_ERR(drm);
>>
>> drm->dev_private = hdlcd;
>> dev_set_drvdata(dev, drm);
>> diff --git a/drivers/gpu/drm/arm/malidp_drv.c
>> b/drivers/gpu/drm/arm/malidp_drv.c
>> index c383d72..9280358 100644
>> --- a/drivers/gpu/drm/arm/malidp_drv.c
>> +++ b/drivers/gpu/drm/arm/malidp_drv.c
>> @@ -311,8 +311,8 @@ static int malidp_bind(struct device *dev)
>> return ret;
>>
>> drm = drm_dev_alloc(&malidp_driver, dev);
>> - if (!drm) {
>> - ret = -ENOMEM;
>> + if (IS_ERR(drm)) {
>> + ret = PTR_ERR(drm);
>> goto alloc_fail;
>> }
>>
>> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> index 8e7483d..5f48431 100644
>> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> @@ -797,8 +797,8 @@ static int atmel_hlcdc_dc_drm_probe(struct
>> platform_device *pdev)
>> int ret;
>>
>> ddev = drm_dev_alloc(&atmel_hlcdc_dc_driver, &pdev->dev);
>> - if (!ddev)
>> - return -ENOMEM;
>> + if (IS_ERR(ddev))
>> + return PTR_ERR(ddev);
>>
>> ret = atmel_hlcdc_dc_load(ddev);
>> if (ret)
>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>> index 99e6751..80c7f25 100644
>> --- a/drivers/gpu/drm/drm_drv.c
>> +++ b/drivers/gpu/drm/drm_drv.c
>> @@ -591,7 +591,7 @@ EXPORT_SYMBOL(drm_dev_init);
>> * own struct should look at using drm_dev_init() instead.
>> *
>> * RETURNS:
>> - * Pointer to new DRM device, or NULL if out of memory.
>> + * Pointer to new DRM device, or ERR_PTR on failure.
>> */
>> struct drm_device *drm_dev_alloc(struct drm_driver *driver,
>>struct device *parent)
>> @@ -601,12 +601,12 @@ struct drm_device *drm_dev_alloc(struct d
[PATCH] drm/i2c: tda998x: don't register the connector
On Thu, Sep 22, 2016 at 3:51 AM, Russell King - ARM Linux wrote: > On Thu, Sep 22, 2016 at 11:39:18AM +0100, Brian Starkey wrote: >> Actually, could you please hold off picking this up? We need to make >> changes in mali-dp and hdlcd or this will mess up their registration. >> I will send those patches later today, but better if this all goes in >> together (whenever that ends up being). > > Sorry, but I'm annoyed with this - the impression being given was that > I was holding up this patch by not testing it on Armada, and I brought > up the issue about registration at the beginning of this. > > Now we're _just_ finding out that there are drivers where removing the > connector registration in tda998x causes them to break? It's a bit > late to be checking your own drivers when you've been chasing me... > > Sorry, but it sounds like we're not ready to make this change - and as > it's the very last day that changes will appear in linux-next prior to > the merge window (assuming Linus releases 4.8 on Sunday), I'd suggest > holding off until after the merge window is over, so we can get some > testing with these other two drivers with this change in place. > sigh. I just pushed my queue to drm-misc, which included this patch. Sounds like I should revert? Sean > -- > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up > according to speedtest.net.
[PATCH 1/2] drm: Distinguish no name from ENOMEM in set_unique()
On Thu, Sep 22, 2016 at 8:28 AM, Emil Velikov
wrote:
> On 21 September 2016 at 15:59, Tom Gundersen wrote:
>> If passing name == NULL to drm_drv_set_unique() we now get -ENOMEM
>> as kstrdup() returns NULL. Instead check for this explicitly and
>> return -EINVAL if no name is provided.
>>
>> Signed-off-by: Tom Gundersen
>> ---
>> drivers/gpu/drm/drm_drv.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>> index f2f6429..99e6751 100644
>> --- a/drivers/gpu/drm/drm_drv.c
>> +++ b/drivers/gpu/drm/drm_drv.c
>> @@ -338,6 +338,9 @@ void drm_minor_release(struct drm_minor *minor)
>>
>> static int drm_dev_set_unique(struct drm_device *dev, const char *name)
>> {
>> + if (!name)
>> + return -EINVAL;
>> +
> From memory there should be no open-source drivers where this happens
> today. Either way, having a big WARN/OOPS would be better, imho, since
> it will point to the driver bug/issue (?).
Yeah, I only hit this during development, should not happen with any
upstream drivers afaik. Feel free to drop this patch for now.
Cheers,
Tom
[PATCH] dma-buf/fence-array: get signaled state when signaling is disabled
Hi Christian, 2016-09-21 Christian König : > Am 21.09.2016 um 13:36 schrieb Gustavo Padovan: > > From: Gustavo Padovan > > > > If the fences in the fence_array signal on the fence_array does not have > > signalling enabled num_pending will not be updated accordingly. > > > > So when signaling is disabled check the signal of every fence with > > fence_is_signaled() and then compare with num_pending to learn if the > > fence_array was signalled or not. > > > > If we want to keep the poll_does_not_wait optimization I think we need > > something like this. It keeps the same behaviour if signalling is enabled > > but tries to calculated the state otherwise. > > > > Signed-off-by: Gustavo Padovan > > Reviewed-by: Chris Wilson > > First of all the patch is horrible wrong because fence_array_signaled() is > called without any locks held. So you can run into a race condition between > checking the fences here and enable signaling. Yes. it can, but I don't think the race condition is actually a problem. Maybe you have some use case that we are not seeing? > Additional to that I'm not sure if that is such a good idea or not, cause > fence_array_signaled() should be light weight and without calling > enable_signaling there is not guarantee that fences will ever signal. It is still lightweight for the case when signaling is enabled and fences can signal with signaling enabled or disabled so I don't see that as problem too. Gustavo
[PATCH 1/2] drm: Distinguish no name from ENOMEM in set_unique()
On Wed, Sep 21, 2016 at 04:59:18PM +0200, Tom Gundersen wrote:
> If passing name == NULL to drm_drv_set_unique() we now get -ENOMEM
> as kstrdup() returns NULL. Instead check for this explicitly and
> return -EINVAL if no name is provided.
>
> Signed-off-by: Tom Gundersen
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_drv.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index f2f6429..99e6751 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -338,6 +338,9 @@ void drm_minor_release(struct drm_minor *minor)
>
> static int drm_dev_set_unique(struct drm_device *dev, const char *name)
> {
> + if (!name)
> + return -EINVAL;
> +
> kfree(dev->unique);
> dev->unique = kstrdup(name, GFP_KERNEL);
>
> --
> 2.9.3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH] dma-buf/fence-array: get signaled state when signaling is disabled
On 2016å¹´09æ21æ¥ 19:36, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> If the fences in the fence_array signal on the fence_array does not have
> signalling enabled num_pending will not be updated accordingly.
>
> So when signaling is disabled check the signal of every fence with
> fence_is_signaled() and then compare with num_pending to learn if the
> fence_array was signalled or not.
>
> If we want to keep the poll_does_not_wait optimization I think we need
> something like this. It keeps the same behaviour if signalling is enabled
> but tries to calculated the state otherwise.
>
> Signed-off-by: Gustavo Padovan
> Reviewed-by: Chris Wilson
Reviewed-by: Chunming Zhou
Regards,
David Zhou
> ---
> drivers/dma-buf/fence-array.c | 19 ++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma-buf/fence-array.c b/drivers/dma-buf/fence-array.c
> index f1989fc..1eec271 100644
> --- a/drivers/dma-buf/fence-array.c
> +++ b/drivers/dma-buf/fence-array.c
> @@ -75,8 +75,25 @@ static bool fence_array_enable_signaling(struct fence
> *fence)
> static bool fence_array_signaled(struct fence *fence)
> {
> struct fence_array *array = to_fence_array(fence);
> + int i, num_pending;
> +
> + num_pending = atomic_read(&array->num_pending);
> +
> + /*
> + * Before signaling is enabled, num_pending is static (set during array
> + * construction as a count of all fences or set to 1 if signal_on_any
> + * flag is passed. To ensure forward progress, i.e. a while
> + * (!fence_is_signaled()) ; busy-loop eventually proceeds, we need to
> + * check the current status of our fences.
> + */
> + if (!test_bit(FENCE_FLAG_ENABLE_SIGNAL_BIT, &fence->flags)) {
> + for (i = 0 ; i < array->num_fences; ++i) {
> + if (fence_is_signaled(array->fences[i]))
> + num_pending--;
> + }
> + }
>
> - return atomic_read(&array->num_pending) <= 0;
> + return num_pending <= 0;
> }
>
> static void fence_array_release(struct fence *fence)
[PATCH 2/4] GPU-DRM-QXL: Move three assignments in qxl_device_init()
Guys, please stop accepting patches from Markus! Markus, you always introduce bugs. I have asked you over and over to stop sending "cleanup patches" because you are not careful. If you restricted yourself to fixing bugs only then you would maybe fix more bugs than you introduce but as it you are making the kernel worse. regards dan carepnter
[PATCH] drm: Convert prime dma-buf <-> handle to rhashtable
Currently we use a linear walk to lookup a handle and return a dma-buf,
and vice versa. A long overdue TODO task is to convert that to a
hashtable. Since the initial implementation of dma-buf/prime, we now
have resizeable hashtables we can use (and now a future task is to RCU
enable the lookup!).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94631
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_prime.c | 94 +++--
include/drm/drmP.h | 5 ++-
2 files changed, 77 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 780589b420a4..ad077def660d 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -28,6 +28,7 @@
#include
#include
+#include
#include
#include
@@ -61,9 +62,11 @@
*/
struct drm_prime_member {
- struct list_head entry;
struct dma_buf *dma_buf;
uint32_t handle;
+
+ struct rhash_head dma_buf_rht;
+ struct rhash_head handle_rht;
};
struct drm_prime_attachment {
@@ -71,10 +74,31 @@ struct drm_prime_attachment {
enum dma_data_direction dir;
};
+static const struct rhashtable_params dma_buf_params = {
+ .head_offset = offsetof(struct drm_prime_member, dma_buf_rht),
+ .key_len = sizeof(struct dma_buf *),
+ .key_offset = offsetof(struct drm_prime_member, dma_buf),
+ .hashfn = jhash,
+ .nulls_base = 1u << RHT_BASE_SHIFT,
+ .automatic_shrinking = true,
+ .nelem_hint = 2,
+};
+
+static const struct rhashtable_params handle_params = {
+ .head_offset = offsetof(struct drm_prime_member, handle_rht),
+ .key_len = sizeof(uint32_t),
+ .key_offset = offsetof(struct drm_prime_member, handle),
+ .hashfn = jhash,
+ .nulls_base = 1u << RHT_BASE_SHIFT,
+ .automatic_shrinking = true,
+ .nelem_hint = 2,
+};
+
static int drm_prime_add_buf_handle(struct drm_prime_file_private *prime_fpriv,
struct dma_buf *dma_buf, uint32_t handle)
{
struct drm_prime_member *member;
+ int err;
member = kmalloc(sizeof(*member), GFP_KERNEL);
if (!member)
@@ -83,8 +107,28 @@ static int drm_prime_add_buf_handle(struct
drm_prime_file_private *prime_fpriv,
get_dma_buf(dma_buf);
member->dma_buf = dma_buf;
member->handle = handle;
- list_add(&member->entry, &prime_fpriv->head);
+
+ err = rhashtable_insert_fast(&prime_fpriv->dma_bufs,
+&member->dma_buf_rht,
+dma_buf_params);
+ if (err)
+ goto err_dma_buf;
+
+ err = rhashtable_insert_fast(&prime_fpriv->handles,
+&member->handle_rht,
+handle_params);
+ if (err)
+ goto err_dma_rht;
+
return 0;
+
+err_dma_rht:
+ rhashtable_remove_fast(&prime_fpriv->dma_bufs,
+ &member->dma_buf_rht,
+ dma_buf_params);
+err_dma_buf:
+ dma_buf_put(dma_buf);
+ return err;
}
static struct dma_buf *drm_prime_lookup_buf_by_handle(struct
drm_prime_file_private *prime_fpriv,
@@ -92,10 +136,10 @@ static struct dma_buf
*drm_prime_lookup_buf_by_handle(struct drm_prime_file_priv
{
struct drm_prime_member *member;
- list_for_each_entry(member, &prime_fpriv->head, entry) {
- if (member->handle == handle)
- return member->dma_buf;
- }
+ member = rhashtable_lookup_fast(&prime_fpriv->handles,
+ &handle, handle_params);
+ if (member)
+ return member->dma_buf;
return NULL;
}
@@ -106,12 +150,13 @@ static int drm_prime_lookup_buf_handle(struct
drm_prime_file_private *prime_fpri
{
struct drm_prime_member *member;
- list_for_each_entry(member, &prime_fpriv->head, entry) {
- if (member->dma_buf == dma_buf) {
- *handle = member->handle;
- return 0;
- }
+ member = rhashtable_lookup_fast(&prime_fpriv->dma_bufs,
+ &dma_buf, dma_buf_params);
+ if (member) {
+ *handle = member->handle;
+ return 0;
}
+
return -ENOENT;
}
@@ -166,14 +211,21 @@ static void drm_gem_map_detach(struct dma_buf *dma_buf,
void drm_prime_remove_buf_handle_locked(struct drm_prime_file_private
*prime_fpriv,
struct dma_buf *dma_buf)
{
- struct drm_prime_member *member, *safe;
+ struct drm_prime_member *member;
- list_for_each_entry_safe(member, safe, &prime_fpriv->head, entry) {
- if (member->dma_buf == dma_buf) {
- dma_buf_put(dma_buf);
- list_del(&member->entry);
- kfr
[PATCH 3/4] GPU-DRM-TILCDC: Less function calls in tilcdc_convert_slave_node() after error detection
From: Markus Elfring
Date: Thu, 22 Sep 2016 10:06:50 +0200
The of_node_put() function was called in some cases
by the tilcdc_convert_slave_node() function during error handling
even if the passed variable contained a null pointer.
* Adjust jump targets according to the Linux coding style convention.
* Split a condition check for resource detection failures so that
each pointer from these function calls will be checked immediately.
See also background information:
Topic "CWE-754: Improper check for unusual or exceptional conditions"
Link: https://cwe.mitre.org/data/definitions/754.html
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
index 6204405..6ee5865 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
@@ -209,25 +209,27 @@ void __init tilcdc_convert_slave_node(void)
return;
lcdc = of_find_matching_node(NULL, tilcdc_of_match);
- slave = of_find_matching_node(NULL, tilcdc_slave_of_match);
+ if (!of_device_is_available(lcdc))
+ goto free_table;
- if (!slave || !of_device_is_available(lcdc))
- goto out;
+ slave = of_find_matching_node(NULL, tilcdc_slave_of_match);
+ if (!slave)
+ goto put_node_lcdc;
i2c = of_parse_phandle(slave, "i2c", 0);
if (!i2c) {
pr_err("%s: Can't find i2c node trough phandle\n", __func__);
- goto out;
+ goto put_node_slave;
}
overlay = tilcdc_get_overlay(&kft);
if (!overlay)
- goto out;
+ goto put_node_i2c;
encoder = of_find_matching_node(overlay, tilcdc_tda998x_of_match);
if (!encoder) {
pr_err("%s: Failed to find tda998x node\n", __func__);
- goto out;
+ goto put_node_i2c;
}
tilcdc_copy_props(slave, encoder, tilcdc_slave_props, &kft);
@@ -238,10 +240,10 @@ void __init tilcdc_convert_slave_node(void)
continue;
if (!strncmp("i2c", (char *)prop->value, prop->length))
if (tilcdc_prop_str_update(prop, i2c->full_name, &kft))
- goto out;
+ goto put_node_fragment;
if (!strncmp("lcdc", (char *)prop->value, prop->length))
if (tilcdc_prop_str_update(prop, lcdc->full_name, &kft))
- goto out;
+ goto put_node_fragment;
}
tilcdc_node_disable(slave);
@@ -252,12 +254,16 @@ void __init tilcdc_convert_slave_node(void)
else
pr_info("%s: ti,tilcdc,slave node successfully converted\n",
__func__);
-out:
- kfree_table_free(&kft);
+ put_node_fragment:
+ of_node_put(fragment);
+ put_node_i2c:
of_node_put(i2c);
+ put_node_slave:
of_node_put(slave);
+ put_node_lcdc:
of_node_put(lcdc);
- of_node_put(fragment);
+ free_table:
+ kfree_table_free(&kft);
}
int __init tilcdc_slave_compat_init(void)
--
2.10.0
[PATCH 1/4] GPU-DRM-TILCDC: Use kmalloc_array() in kfree_table_init()
From: Markus Elfring
Date: Thu, 22 Sep 2016 09:05:14 +0200
A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus use the corresponding function "kmalloc_array".
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
index f9c79da..8faa28f 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
@@ -32,8 +32,7 @@ static int __init kfree_table_init(struct kfree_table *kft)
{
kft->total = 32;
kft->num = 0;
- kft->table = kmalloc(kft->total * sizeof(*kft->table),
-GFP_KERNEL);
+ kft->table = kmalloc_array(kft->total, sizeof(*kft->table), GFP_KERNEL);
if (!kft->table)
return -ENOMEM;
--
2.10.0
[PATCH 0/4] GPU-DRM-TILCDC: Fine-tuning for two function implementations
From: Markus Elfring Date: Thu, 22 Sep 2016 10:25:43 +0200 A few update suggestions were taken into account from static source code analysis. Markus Elfring (4): Use kmalloc_array() Return directly after a failed kfree_table_init() in tilcdc_convert_slave_node() Less function calls in tilcdc_convert_slave_node() after error detection Delete unnecessary variable initialisations drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c | 36 +++- 1 file changed, 20 insertions(+), 16 deletions(-) -- 2.10.0
[PATCH] drm/i915: Before pageflip, also wait for shared dmabuf fences.
On Wed, Sep 21, 2016 at 06:23:35PM +0200, Christian König wrote: > For a quick workaround I suggest to just serialize all accesses to BO shared > with different drivers, but essentially I think it is a perfectly valid > requirement to have multiple writers to one BO. It is, but it's not possible with implicit sync. If you want parallel write access to the same shared buffer, you _must_ carry around some explicit fences. Within amdgpu you can use driver-specific cookies, for shared buffer we now have sync_file. But multiple writers with implicit sync simply fundamentally doesn't work. Because you have no idea with which writer, touching the same subrange you want to touch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH 2/4] GPU-DRM-TILCDC: Return directly after a failed kfree_table_init() in tilcdc_convert_slave_node()
From: Markus Elfring Date: Thu, 22 Sep 2016 09:29:23 +0200 Return directly after a memory allocation failed in this function at the beginning. Signed-off-by: Markus Elfring --- drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c index 8faa28f..6204405 100644 --- a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c +++ b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c @@ -206,7 +206,7 @@ void __init tilcdc_convert_slave_node(void) int ret; if (kfree_table_init(&kft)) - goto out; + return; lcdc = of_find_matching_node(NULL, tilcdc_of_match); slave = of_find_matching_node(NULL, tilcdc_slave_of_match); -- 2.10.0
[PATCH 4/4] GPU-DRM-TILCDC: Delete unnecessary variable initialisations in tilcdc_convert_slave_node()
From: Markus Elfring
Date: Thu, 22 Sep 2016 10:15:36 +0200
Four local variables will be set to an appropriate pointer a bit later.
Thus omit the explicit initialisation which became unnecessary with
a previous update step.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
index 6ee5865..ae90728 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
@@ -196,8 +196,7 @@ static const char * const tilcdc_slave_props[] __initconst
= {
void __init tilcdc_convert_slave_node(void)
{
- struct device_node *slave = NULL, *lcdc = NULL;
- struct device_node *i2c = NULL, *fragment = NULL;
+ struct device_node *slave, *lcdc, *i2c, *fragment;
struct device_node *overlay, *encoder;
struct property *prop;
/* For all memory needed for the overlay tree. This memory can
--
2.10.0
[PATCH v2 0/4] drm/exynos: mixer: small optimisations
Hello, here's v2 of this patchset. I've added two other 'cosmetic' patches as well. Anyway, I have fixed up the second patch and integrated Andrzej's suggestions. First patch is unmodified except for the Reviewed-By tag. With best wishes, Tobias Tobias Jakobi (4): drm/exynos: mixer: convert booleans to flags in mixer context drm/exynos: mixer: configure layers once in mixer_atomic_flush() drm/exynos: mixer: simplify loop in vp_win_reset() drm/exynos: g2d: beautify probing message drivers/gpu/drm/exynos/exynos_drm_g2d.c | 2 +- drivers/gpu/drm/exynos/exynos_mixer.c | 187 drivers/gpu/drm/exynos/regs-mixer.h | 2 + 3 files changed, 120 insertions(+), 71 deletions(-) -- 2.7.3
[PATCH v2 1/4] drm/exynos: mixer: convert booleans to flags in mixer context
The mixer context struct already has a 'flags' field, so
we can use it to store the 'interlace', 'vp_enabled' and
'has_sclk' booleans.
We use the non-atomic helper functions to access these bits.
Reviewed-by: Andrzej Hajda
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 54 +++
1 file changed, 29 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 9a48aa1..1e78d57 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -73,6 +73,9 @@ enum mixer_version_id {
enum mixer_flag_bits {
MXR_BIT_POWERED,
MXR_BIT_VSYNC,
+ MXR_BIT_INTERLACE,
+ MXR_BIT_VP_ENABLED,
+ MXR_BIT_HAS_SCLK,
};
static const uint32_t mixer_formats[] = {
@@ -98,9 +101,6 @@ struct mixer_context {
struct exynos_drm_plane planes[MIXER_WIN_NR];
int pipe;
unsigned long flags;
- boolinterlace;
- boolvp_enabled;
- boolhas_sclk;
struct mixer_resources mixer_res;
enum mixer_version_id mxr_ver;
@@ -346,7 +346,7 @@ static void mixer_vsync_set_update(struct mixer_context
*ctx, bool enable)
mixer_reg_writemask(res, MXR_STATUS, enable ?
MXR_STATUS_SYNC_ENABLE : 0, MXR_STATUS_SYNC_ENABLE);
- if (ctx->vp_enabled)
+ if (test_bit(MXR_BIT_VP_ENABLED, &ctx->flags))
vp_reg_write(res, VP_SHADOW_UPDATE, enable ?
VP_SHADOW_UPDATE_ENABLE : 0);
}
@@ -357,8 +357,8 @@ static void mixer_cfg_scan(struct mixer_context *ctx,
unsigned int height)
u32 val;
/* choosing between interlace and progressive mode */
- val = (ctx->interlace ? MXR_CFG_SCAN_INTERLACE :
- MXR_CFG_SCAN_PROGRESSIVE);
+ val = test_bit(MXR_BIT_INTERLACE, &ctx->flags) ?
+ MXR_CFG_SCAN_INTERLACE : MXR_CFG_SCAN_PROGRESSIVE;
if (ctx->mxr_ver != MXR_VER_128_0_0_184) {
/* choosing between proper HD and SD mode */
@@ -436,9 +436,10 @@ static void mixer_cfg_layer(struct mixer_context *ctx,
unsigned int win,
mixer_reg_writemask(res, MXR_LAYER_CFG,
MXR_LAYER_CFG_GRP1_VAL(priority),
MXR_LAYER_CFG_GRP1_MASK);
+
break;
case VP_DEFAULT_WIN:
- if (ctx->vp_enabled) {
+ if (test_bit(MXR_BIT_VP_ENABLED, &ctx->flags)) {
vp_reg_writemask(res, VP_ENABLE, val, VP_ENABLE_ON);
mixer_reg_writemask(res, MXR_CFG, val,
MXR_CFG_VP_ENABLE);
@@ -501,7 +502,7 @@ static void vp_video_buffer(struct mixer_context *ctx,
chroma_addr[0] = exynos_drm_fb_dma_addr(fb, 1);
if (mode->flags & DRM_MODE_FLAG_INTERLACE) {
- ctx->interlace = true;
+ __set_bit(MXR_BIT_INTERLACE, &ctx->flags);
if (tiled_mode) {
luma_addr[1] = luma_addr[0] + 0x40;
chroma_addr[1] = chroma_addr[0] + 0x40;
@@ -510,7 +511,7 @@ static void vp_video_buffer(struct mixer_context *ctx,
chroma_addr[1] = chroma_addr[0] + fb->pitches[0];
}
} else {
- ctx->interlace = false;
+ __clear_bit(MXR_BIT_INTERLACE, &ctx->flags);
luma_addr[1] = 0;
chroma_addr[1] = 0;
}
@@ -518,7 +519,7 @@ static void vp_video_buffer(struct mixer_context *ctx,
spin_lock_irqsave(&res->reg_slock, flags);
/* interlace or progressive scan mode */
- val = (ctx->interlace ? ~0 : 0);
+ val = (test_bit(MXR_BIT_INTERLACE, &ctx->flags) ? ~0 : 0);
vp_reg_writemask(res, VP_MODE, val, VP_MODE_LINE_SKIP);
/* setup format */
@@ -541,7 +542,7 @@ static void vp_video_buffer(struct mixer_context *ctx,
vp_reg_write(res, VP_DST_WIDTH, state->crtc.w);
vp_reg_write(res, VP_DST_H_POSITION, state->crtc.x);
- if (ctx->interlace) {
+ if (test_bit(MXR_BIT_INTERLACE, &ctx->flags)) {
vp_reg_write(res, VP_DST_HEIGHT, state->crtc.h / 2);
vp_reg_write(res, VP_DST_V_POSITION, state->crtc.y / 2);
} else {
@@ -636,9 +637,9 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
src_y_offset = 0;
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
- ctx->interlace = true;
+ __set_bit(MXR_BIT_INTERLACE, &ctx->flags);
else
- ctx->interlace = false;
+ __clear_bit(MXR_BIT_INTERLACE, &ctx->flags);
spin_lock_irqsave(&res->reg_slock, flags);
@@ -733,7 +734,7 @@ static void mixer_win_reset(struct mixer_context *ctx)
mixer_reg_write(res, MXR_BG_COLOR1, 0x008080);
[PATCH v2 2/4] drm/exynos: mixer: configure layers once in mixer_atomic_flush()
Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
in mixer_cfg_layer().
Trigger this via atomic flush.
Changes in v2:
- issue mixer_cfg_layer() in mixer_disable()
- rename fields as suggested by Andrzej
- added docu to mixer context struct
- simplify mixer_win_reset() as well
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 133 ++
drivers/gpu/drm/exynos/regs-mixer.h | 2 +
2 files changed, 90 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 1e78d57..c3dad66 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -93,12 +93,25 @@ static const uint32_t vp_formats[] = {
DRM_FORMAT_NV21,
};
+/*
+ * Mixer context structure.
+ *
+ * @crtc: The HDMI CRTC attached to the mixer.
+ * @planes: Array of plane objects for each of the mixer windows.
+ * @active_windows: Cache of the mixer's hardware state.
+ * Tracks which mixer windows are active/inactive.
+ * @pipe: The CRTC index.
+ * @flags: Bitfield build from the mixer_flag_bits enumerator.
+ * @mixer_resources: A struct containing registers, clocks, etc.
+ * @mxr_ver: The hardware revision/version of the mixer.
+ */
struct mixer_context {
struct platform_device *pdev;
struct device *dev;
struct drm_device *drm_dev;
struct exynos_drm_crtc *crtc;
struct exynos_drm_plane planes[MIXER_WIN_NR];
+ unsigned long active_windows;
int pipe;
unsigned long flags;
@@ -418,37 +431,68 @@ static void mixer_cfg_rgb_fmt(struct mixer_context *ctx,
unsigned int height)
mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_RGB_FMT_MASK);
}
-static void mixer_cfg_layer(struct mixer_context *ctx, unsigned int win,
- unsigned int priority, bool enable)
+static void mixer_cfg_layer(struct mixer_context *ctx)
{
struct mixer_resources *res = &ctx->mixer_res;
- u32 val = enable ? ~0 : 0;
-
- switch (win) {
- case 0:
- mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP0_ENABLE);
- mixer_reg_writemask(res, MXR_LAYER_CFG,
- MXR_LAYER_CFG_GRP0_VAL(priority),
- MXR_LAYER_CFG_GRP0_MASK);
- break;
- case 1:
- mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP1_ENABLE);
- mixer_reg_writemask(res, MXR_LAYER_CFG,
- MXR_LAYER_CFG_GRP1_VAL(priority),
- MXR_LAYER_CFG_GRP1_MASK);
+ unsigned int win;
- break;
- case VP_DEFAULT_WIN:
- if (test_bit(MXR_BIT_VP_ENABLED, &ctx->flags)) {
- vp_reg_writemask(res, VP_ENABLE, val, VP_ENABLE_ON);
- mixer_reg_writemask(res, MXR_CFG, val,
- MXR_CFG_VP_ENABLE);
- mixer_reg_writemask(res, MXR_LAYER_CFG,
- MXR_LAYER_CFG_VP_VAL(priority),
- MXR_LAYER_CFG_VP_MASK);
+ struct exynos_drm_plane_state *state;
+ struct drm_framebuffer *fb;
+ unsigned int priority;
+ u32 mxr_cfg = 0, mxr_layer_cfg = 0, vp_enable = 0;
+ bool enable;
+
+ for (win = 0; win < MIXER_WIN_NR; ++win) {
+ state = to_exynos_plane_state(ctx->planes[win].base.state);
+ fb = state->fb;
+
+ priority = state->base.normalized_zpos + 1;
+ enable = test_bit(win, &ctx->active_windows);
+
+ if (!enable)
+ continue;
+
+ switch (win) {
+ case 0:
+ mxr_cfg |= MXR_CFG_GRP0_ENABLE;
+ mxr_layer_cfg |= MXR_LAYER_CFG_GRP0_VAL(priority);
+ break;
+
+ case 1:
+ mxr_cfg |= MXR_CFG_GRP1_ENABLE;
+ mxr_layer_cfg |= MXR_LAYER_CFG_GRP1_VAL(priority);
+ break;
+
+ case VP_DEFAULT_WIN:
+ vp_enable = VP_ENABLE_ON;
+ mxr_cfg |= MXR_CFG_VP_ENABLE;
+ mxr_layer_cfg |= MXR_LAYER_CFG_VP_VAL(priority);
+ break;
+ }
+
+ if (!fb)
+ continue;
+
+ /*
+* TODO: Don't enable alpha blending for the bottom window.
+*/
+ switch (win) {
+ case 0:
+ case 1:
+ mixer_cfg_gfx_blend(ctx, win,
is_alpha_format(fb->pixel_format));
+ break;
+
+ case VP_DEFAULT_WIN:
+ mixer_cfg_vp_blend(ctx);
+ break;
[Bug 94900] HD6950 GPU lockup loop with various steam games (octodad[always], saints row 4[always], dead island[always], grid autosport[sometimes])
https://bugs.freedesktop.org/show_bug.cgi?id=94900 --- Comment #26 from Gregor Münch --- (In reply to Marek Olšák from comment #24) > How about we make R600_DEBUG=sbsafemath be the default? If there are no resources inside AMD to fix those bugs, this will be the best option. Those stalls are way more annoying than loosing some fps. At least this should be the default in stable releases. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160922/b11f88f8/attachment.html>
[PATCH v2 3/4] drm/exynos: mixer: simplify loop in vp_win_reset()
A simple while loop should do the same here.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index c3dad66..4f39d6b 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -736,10 +736,10 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
static void vp_win_reset(struct mixer_context *ctx)
{
struct mixer_resources *res = &ctx->mixer_res;
- int tries = 100;
+ unsigned int tries = 100;
vp_reg_write(res, VP_SRESET, VP_SRESET_PROCESSING);
- for (tries = 100; tries; --tries) {
+ while (tries--) {
/* waiting until VP_SRESET_PROCESSING is 0 */
if (~vp_reg_read(res, VP_SRESET) & VP_SRESET_PROCESSING)
break;
--
2.7.3
[PATCH v2 4/4] drm/exynos: g2d: beautify probing message
Apply some 'make-up' in g2d_probe(). Signed-off-by: Tobias Jakobi --- drivers/gpu/drm/exynos/exynos_drm_g2d.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c b/drivers/gpu/drm/exynos/exynos_drm_g2d.c index 73cd83f..410d170 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c @@ -2423,7 +2423,7 @@ static int g2d_probe(struct platform_device *pdev) goto err_put_clk; } - dev_info(dev, "The exynos g2d(ver %d.%d) successfully probed\n", + dev_info(dev, "The Exynos G2D (ver %d.%d) successfully probed.\n", G2D_HW_MAJOR_VER, G2D_HW_MINOR_VER); return 0; -- 2.7.3
[PATCH 2/2] drm: Don't swallow error codes in drm_dev_alloc()
On Wed, Sep 21, 2016 at 04:59:19PM +0200, Tom Gundersen wrote:
> There are many reasons other than ENOMEM that drm_dev_init() can
> fail. Return ERR_PTR rather than NULL to be able to distinguish
> these in the caller.
>
> Signed-off-by: Tom Gundersen
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/arc/arcpgu_drv.c| 4 ++--
> drivers/gpu/drm/arm/hdlcd_drv.c | 4 ++--
> drivers/gpu/drm/arm/malidp_drv.c| 4 ++--
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 4 ++--
> drivers/gpu/drm/drm_drv.c | 6 +++---
> drivers/gpu/drm/drm_pci.c | 4 ++--
> drivers/gpu/drm/drm_platform.c | 4 ++--
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 4 ++--
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 4 ++--
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 4 ++--
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 ++--
> drivers/gpu/drm/msm/msm_drv.c | 4 ++--
> drivers/gpu/drm/nouveau/nouveau_drm.c | 4 ++--
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 4 ++--
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 4 ++--
> drivers/gpu/drm/sti/sti_drv.c | 4 ++--
> drivers/gpu/drm/sun4i/sun4i_drv.c | 4 ++--
> drivers/gpu/drm/tegra/drm.c | 4 ++--
> drivers/gpu/drm/udl/udl_drv.c | 4 ++--
> drivers/gpu/drm/vc4/vc4_drv.c | 4 ++--
> drivers/gpu/drm/vgem/vgem_drv.c | 4 ++--
> drivers/gpu/drm/virtio/virtgpu_drm_bus.c| 4 ++--
> 22 files changed, 45 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c
> b/drivers/gpu/drm/arc/arcpgu_drv.c
> index 6d4ff34..28e6471 100644
> --- a/drivers/gpu/drm/arc/arcpgu_drv.c
> +++ b/drivers/gpu/drm/arc/arcpgu_drv.c
> @@ -198,8 +198,8 @@ static int arcpgu_probe(struct platform_device *pdev)
> int ret;
>
> drm = drm_dev_alloc(&arcpgu_drm_driver, &pdev->dev);
> - if (!drm)
> - return -ENOMEM;
> + if (IS_ERR(drm))
> + return PTR_ERR(drm);
>
> ret = arcpgu_load(drm);
> if (ret)
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index d83b46a..fb6a418 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -326,8 +326,8 @@ static int hdlcd_drm_bind(struct device *dev)
> return -ENOMEM;
>
> drm = drm_dev_alloc(&hdlcd_driver, dev);
> - if (!drm)
> - return -ENOMEM;
> + if (IS_ERR(drm))
> + return PTR_ERR(drm);
>
> drm->dev_private = hdlcd;
> dev_set_drvdata(dev, drm);
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> b/drivers/gpu/drm/arm/malidp_drv.c
> index c383d72..9280358 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -311,8 +311,8 @@ static int malidp_bind(struct device *dev)
> return ret;
>
> drm = drm_dev_alloc(&malidp_driver, dev);
> - if (!drm) {
> - ret = -ENOMEM;
> + if (IS_ERR(drm)) {
> + ret = PTR_ERR(drm);
> goto alloc_fail;
> }
>
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index 8e7483d..5f48431 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -797,8 +797,8 @@ static int atmel_hlcdc_dc_drm_probe(struct
> platform_device *pdev)
> int ret;
>
> ddev = drm_dev_alloc(&atmel_hlcdc_dc_driver, &pdev->dev);
> - if (!ddev)
> - return -ENOMEM;
> + if (IS_ERR(ddev))
> + return PTR_ERR(ddev);
>
> ret = atmel_hlcdc_dc_load(ddev);
> if (ret)
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 99e6751..80c7f25 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -591,7 +591,7 @@ EXPORT_SYMBOL(drm_dev_init);
> * own struct should look at using drm_dev_init() instead.
> *
> * RETURNS:
> - * Pointer to new DRM device, or NULL if out of memory.
> + * Pointer to new DRM device, or ERR_PTR on failure.
> */
> struct drm_device *drm_dev_alloc(struct drm_driver *driver,
>struct device *parent)
> @@ -601,12 +601,12 @@ struct drm_device *drm_dev_alloc(struct drm_driver
> *driver,
>
> dev = kzalloc(sizeof(*dev), GFP_KERNEL);
> if (!dev)
> - return NULL;
> + return ERR_PTR(-ENOMEM);
>
> ret = drm_dev_init(dev, driver, parent);
> if (ret) {
> kfree(dev);
> - return NULL;
> + return ERR_PTR(ret);
> }
>
> return dev;
> diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
> index d86362f..3ceea9c 100644
> --- a/drivers/gpu/drm/drm_pci.c
> +++ b/drivers/gpu/drm/drm_pci.c
> @@ -236,8 +236,8 @@ i
[PATCH 1/2] drm: Distinguish no name from ENOMEM in set_unique()
On 21 September 2016 at 15:59, Tom Gundersen wrote:
> If passing name == NULL to drm_drv_set_unique() we now get -ENOMEM
> as kstrdup() returns NULL. Instead check for this explicitly and
> return -EINVAL if no name is provided.
>
> Signed-off-by: Tom Gundersen
> ---
> drivers/gpu/drm/drm_drv.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index f2f6429..99e6751 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -338,6 +338,9 @@ void drm_minor_release(struct drm_minor *minor)
>
> static int drm_dev_set_unique(struct drm_device *dev, const char *name)
> {
> + if (!name)
> + return -EINVAL;
> +
>From memory there should be no open-source drivers where this happens
today. Either way, having a big WARN/OOPS would be better, imho, since
it will point to the driver bug/issue (?).
Regards,
Emil
[PATCH v2 0/3] video: of: Drive edge selection for sync
Hi, Changes since v1: - separated the code changes from the omap/drm videomode conversion patches - the DT bindings document is now explicitly states that the drive edge is referring to the pixel clock Since we have several panels under omapdrm/displays/ where the data drive edge is set to be different then the sync drive edge, the first three patch will add support to select the sync drive edge via DT. I was not able to locate the datasheet for all the panels and because the different edge was used in omapdrm and omapfb for a long time without complains from users - and they were written this way - I think it is a valid that we can have panels requiring different edge for data and sync to be driven. This series will add support for the sync drive edge setting and the omapdrm's videmode conversion series depends on this change. It is also planned that the omapdrm is going to move to use the drm/panel in the future and to be able to convert the panel drivers we will need this feature. Regards, Peter --- Peter Ujfalusi (3): dt-bindings: display: display-timing: Add property to configure sync drive edge video: display_timing: Add flags to select the edge when the sync is driven video: of: display_timing: Add support for syncclk-active property .../devicetree/bindings/display/panel/display-timing.txt | 8 drivers/video/of_display_timing.c| 9 + include/video/display_timing.h | 4 3 files changed, 21 insertions(+) -- 2.10.0
[PATCH v2 22/23] drm/omap: panel-sharp-ls037v7dw01: Add note for incorrect data drive edge
According to the datasheet of the panel, both data, DEN and sync signals
are expected to be driven on the falling edge of the DOTCLK.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
b/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
index fd33156bc34c..04fe235b7cac 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
@@ -52,6 +52,10 @@ static const struct videomode sharp_ls_vm = {
.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 panel documentation:
+* DATA needs to be driven on the FALLING edge
+*/
};
#define to_panel_data(p) container_of(p, struct panel_drv_data, dssdev)
--
2.10.0
[PATCH v2 1/3] dt-bindings: display: display-timing: Add property to configure sync drive edge
There are display panels which demands that the sync signal is driven on different edge than the pixel data. With the syncclk-active property we can specify the clk edge to be used to drive the sync signal. When the property is missing it indicates that the sync is driven on the same edge as the pixel data. Signed-off-by: Peter Ujfalusi CC: Rob Herring CC: Mark Rutland CC: devicetree at vger.kernel.org --- .../devicetree/bindings/display/panel/display-timing.txt | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/display-timing.txt b/Documentation/devicetree/bindings/display/panel/display-timing.txt index e1d4a0b59612..81a75893d1b8 100644 --- a/Documentation/devicetree/bindings/display/panel/display-timing.txt +++ b/Documentation/devicetree/bindings/display/panel/display-timing.txt @@ -32,6 +32,14 @@ optional properties: - active low = drive pixel data on falling edge/ sample data on rising edge - ignored = ignored + - syncclk-active: with + - active high = drive sync on rising edge/ + sample sync on falling edge of pixel + clock + - active low = drive sync on falling edge/ + sample sync on rising edge of pixel + clock + - omitted = same configuration as pixelclk-active - interlaced (bool): boolean to enable interlaced mode - doublescan (bool): boolean to enable doublescan mode - doubleclk (bool): boolean to enable doubleclock mode -- 2.10.0
[PATCH] drm/i2c: tda998x: don't register the connector
On Thu, Sep 22, 2016 at 04:22:40AM -0700, Sean Paul wrote: > On Thu, Sep 22, 2016 at 3:51 AM, Russell King - ARM Linux > wrote: > > On Thu, Sep 22, 2016 at 11:39:18AM +0100, Brian Starkey wrote: > >> Actually, could you please hold off picking this up? We need to make > >> changes in mali-dp and hdlcd or this will mess up their registration. > >> I will send those patches later today, but better if this all goes in > >> together (whenever that ends up being). > > > > Sorry, but I'm annoyed with this - the impression being given was that > > I was holding up this patch by not testing it on Armada, and I brought > > up the issue about registration at the beginning of this. > > > > Now we're _just_ finding out that there are drivers where removing the > > connector registration in tda998x causes them to break? It's a bit > > late to be checking your own drivers when you've been chasing me... > > > > Sorry, but it sounds like we're not ready to make this change - and as > > it's the very last day that changes will appear in linux-next prior to > > the merge window (assuming Linus releases 4.8 on Sunday), I'd suggest > > holding off until after the merge window is over, so we can get some > > testing with these other two drivers with this change in place. > > > > sigh. I just pushed my queue to drm-misc, which included this patch. > Sounds like I should revert? Why did you do push it _without_ an ack from the maintainer of the driver when the comments on the list were clearly indicating that it was waiting for testing and such an ack? There's something horribly wrong with the process here. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[PATCH v2 19/23] drm/omap: Use consistent name for struct videomode
Use 'vm' to refer to a struct videomode instead of 'p', 't', 'timings' or
something else.
The code will be easier to follow if we use consistent names.
Signed-off-by: Peter Ujfalusi
---
.../gpu/drm/omapdrm/displays/connector-analog-tv.c | 26 ++---
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 26 ++---
drivers/gpu/drm/omapdrm/displays/connector-hdmi.c | 26 ++---
drivers/gpu/drm/omapdrm/displays/encoder-opa362.c | 20 ++--
drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c | 31 +++---
.../gpu/drm/omapdrm/displays/encoder-tpd12s015.c | 20 ++--
drivers/gpu/drm/omapdrm/displays/panel-dpi.c | 26 ++---
drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c| 23 ++---
.../omapdrm/displays/panel-lgphilips-lb035q02.c| 26 ++---
.../drm/omapdrm/displays/panel-nec-nl8048hl11.c| 26 ++---
.../drm/omapdrm/displays/panel-sharp-ls037v7dw01.c | 26 ++---
.../drm/omapdrm/displays/panel-sony-acx565akm.c| 26 ++---
.../drm/omapdrm/displays/panel-tpo-td028ttec1.c| 26 ++---
.../drm/omapdrm/displays/panel-tpo-td043mtea1.c| 26 ++---
drivers/gpu/drm/omapdrm/dss/dispc.c| 114 ++---
drivers/gpu/drm/omapdrm/dss/display.c | 8 +-
drivers/gpu/drm/omapdrm/dss/dpi.c | 38 +++
drivers/gpu/drm/omapdrm/dss/dsi.c | 108 +--
drivers/gpu/drm/omapdrm/dss/dss.h | 5 +-
drivers/gpu/drm/omapdrm/dss/hdmi.h | 8 +-
drivers/gpu/drm/omapdrm/dss/hdmi4.c| 32 +++---
drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 8 +-
drivers/gpu/drm/omapdrm/dss/hdmi5.c| 32 +++---
drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 68 ++--
drivers/gpu/drm/omapdrm/dss/hdmi_wp.c | 58 +--
drivers/gpu/drm/omapdrm/dss/omapdss.h | 57 +--
drivers/gpu/drm/omapdrm/dss/output.c | 5 +-
drivers/gpu/drm/omapdrm/dss/rfbi.c | 52 +-
drivers/gpu/drm/omapdrm/dss/sdi.c | 30 +++---
drivers/gpu/drm/omapdrm/dss/venc.c | 39 ---
drivers/gpu/drm/omapdrm/omap_connector.c | 20 ++--
drivers/gpu/drm/omapdrm/omap_crtc.c| 18 ++--
drivers/gpu/drm/omapdrm/omap_encoder.c | 8 +-
33 files changed, 527 insertions(+), 535 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
index 53a4e6942616..aaa8a58390f1 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
@@ -24,12 +24,12 @@ struct panel_drv_data {
struct device *dev;
- struct videomode timings;
+ struct videomode vm;
bool invert_polarity;
};
-static const struct videomode tvc_pal_timings = {
+static const struct videomode tvc_pal_vm = {
.hactive= 720,
.vactive= 574,
.pixelclock = 1350,
@@ -93,7 +93,7 @@ static int tvc_enable(struct omap_dss_device *dssdev)
if (omapdss_device_is_enabled(dssdev))
return 0;
- in->ops.atv->set_timings(in, &ddata->timings);
+ in->ops.atv->set_timings(in, &ddata->vm);
if (!ddata->dev->of_node) {
in->ops.atv->set_type(in, OMAP_DSS_VENC_TYPE_COMPOSITE);
@@ -127,32 +127,32 @@ static void tvc_disable(struct omap_dss_device *dssdev)
}
static void tvc_set_timings(struct omap_dss_device *dssdev,
- struct videomode *timings)
+ struct videomode *vm)
{
struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *in = ddata->in;
- ddata->timings = *timings;
- dssdev->panel.timings = *timings;
+ ddata->vm = *vm;
+ dssdev->panel.vm = *vm;
- in->ops.atv->set_timings(in, timings);
+ in->ops.atv->set_timings(in, vm);
}
static void tvc_get_timings(struct omap_dss_device *dssdev,
- struct videomode *timings)
+ struct videomode *vm)
{
struct panel_drv_data *ddata = to_panel_data(dssdev);
- *timings = ddata->timings;
+ *vm = ddata->vm;
}
static int tvc_check_timings(struct omap_dss_device *dssdev,
- struct videomode *timings)
+struct videomode *vm)
{
struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *in = ddata->in;
- return in->ops.atv->check_timings(in, timings);
+ return in->ops.atv->check_timings(in, vm);
}
static u32 tvc_get_wss(struct omap_dss_device *dssdev)
@@ -254,14 +254,14 @@ static int tvc_probe(struct platform_device *pdev)
return -ENODEV;
}
- ddata->timings = tvc_pal_timings;
+ ddata->vm = tvc_pal_vm;
dssdev = &ddata->dssdev;
dssdev->driver = &tvc_driver;
dssdev->dev = &p
[PATCH v2 04/23] drm/omap: omap_display_timings: rename hfp to hfront_porch
In preparation to move the stack to use the generic videmode struct for
display timing information rename the hfp member to hfront_porch.
Signed-off-by: Peter Ujfalusi
---
.../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 +-
.../omapdrm/displays/panel-lgphilips-lb035q02.c| 2 +-
.../drm/omapdrm/displays/panel-nec-nl8048hl11.c| 2 +-
.../drm/omapdrm/displays/panel-sharp-ls037v7dw01.c | 2 +-
.../drm/omapdrm/displays/panel-sony-acx565akm.c| 2 +-
.../drm/omapdrm/displays/panel-tpo-td028ttec1.c| 2 +-
.../drm/omapdrm/displays/panel-tpo-td043mtea1.c| 2 +-
drivers/gpu/drm/omapdrm/dss/dispc.c| 22 --
drivers/gpu/drm/omapdrm/dss/display.c | 4 ++--
drivers/gpu/drm/omapdrm/dss/dsi.c | 22 +++---
drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 8
drivers/gpu/drm/omapdrm/dss/hdmi_wp.c | 6 +++---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 2 +-
drivers/gpu/drm/omapdrm/dss/rfbi.c | 2 +-
drivers/gpu/drm/omapdrm/dss/venc.c | 4 ++--
drivers/gpu/drm/omapdrm/omap_connector.c | 4 ++--
18 files changed, 47 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
index 5205a8ef6038..6d089b337bcb 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
@@ -34,7 +34,7 @@ static const struct omap_video_timings tvc_pal_timings = {
.vactive= 574,
.pixelclock = 1350,
.hsync_len = 64,
- .hfp= 12,
+ .hfront_porch = 12,
.hbp= 68,
.vsw= 5,
.vfp= 5,
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
index e9a8ea5043e6..cf893866aca0 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
@@ -25,7 +25,7 @@ static const struct omap_video_timings dvic_default_timings =
{
.pixelclock = 2350,
- .hfp= 48,
+ .hfront_porch = 48,
.hsync_len = 32,
.hbp= 80,
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
index 707fd62cb99c..fd1178b57f79 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
@@ -26,7 +26,7 @@ static const struct omap_video_timings hdmic_default_timings
= {
.vactive= 480,
.pixelclock = 25175000,
.hsync_len = 96,
- .hfp= 16,
+ .hfront_porch = 16,
.hbp= 48,
.vsw= 2,
.vfp= 11,
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
index 6fbf07048df0..677db7b22a02 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
@@ -26,7 +26,7 @@ static struct omap_video_timings lb035q02_timings = {
.pixelclock = 650,
.hsync_len = 2,
- .hfp= 20,
+ .hfront_porch = 20,
.hbp= 68,
.vsw= 2,
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
b/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
index 734ca68f56e4..8b2601010671 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
@@ -70,7 +70,7 @@ static const struct omap_video_timings nec_8048_panel_timings
= {
.hactive= LCD_XRES,
.vactive= LCD_YRES,
.pixelclock = LCD_PIXEL_CLOCK,
- .hfp= 6,
+ .hfront_porch = 6,
.hsync_len = 1,
.hbp= 4,
.vfp= 3,
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
b/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
index 5e96edebdd5c..c8348090e745 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
@@ -42,7 +42,7 @@ static const struct omap_video_timings sharp_ls_timings = {
.pixelclock = 1920,
.hsync_len = 2,
- .hfp= 1,
+ .hfront_porch = 1,
.hbp= 28,
.vsw= 1,
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c
b/drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c
index 32d3c908304e..e2698
[PATCH v2 01/23] drm/omap: omap_display_timings: rename x_res to hactive
In preparation to move the stack to use the generic videmode struct for
display timing information rename the x_res member to hactive.
Signed-off-by: Peter Ujfalusi
---
.../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/panel-dsi-cm.c | 8
.../drm/omapdrm/displays/panel-lgphilips-lb035q02.c | 2 +-
.../gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c | 2 +-
.../drm/omapdrm/displays/panel-sharp-ls037v7dw01.c | 2 +-
.../gpu/drm/omapdrm/displays/panel-sony-acx565akm.c | 2 +-
.../gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c | 2 +-
.../gpu/drm/omapdrm/displays/panel-tpo-td043mtea1.c | 2 +-
drivers/gpu/drm/omapdrm/dss/dispc.c | 16
drivers/gpu/drm/omapdrm/dss/display.c| 6 +++---
drivers/gpu/drm/omapdrm/dss/dpi.c| 2 +-
drivers/gpu/drm/omapdrm/dss/dsi.c| 20 ++--
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| 2 +-
drivers/gpu/drm/omapdrm/dss/omapdss.h| 2 +-
drivers/gpu/drm/omapdrm/dss/rfbi.c | 6 +++---
drivers/gpu/drm/omapdrm/dss/venc.c | 4 ++--
drivers/gpu/drm/omapdrm/omap_connector.c | 4 ++--
22 files changed, 49 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
index 3485d1ecd655..190a03672181 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
@@ -30,7 +30,7 @@ struct panel_drv_data {
};
static const struct omap_video_timings tvc_pal_timings = {
- .x_res = 720,
+ .hactive= 720,
.y_res = 574,
.pixelclock = 1350,
.hsw= 64,
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
index 684b7aeda411..c6e02e1a3799 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
@@ -20,7 +20,7 @@
#include "../dss/omapdss.h"
static const struct omap_video_timings dvic_default_timings = {
- .x_res = 640,
+ .hactive= 640,
.y_res = 480,
.pixelclock = 2350,
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
index 7bdf83af9797..ef5ae08b362b 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
@@ -22,7 +22,7 @@
#include "../dss/omapdss.h"
static const struct omap_video_timings hdmic_default_timings = {
- .x_res = 640,
+ .hactive= 640,
.y_res = 480,
.pixelclock = 25175000,
.hsw= 96,
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
index 0eae8afaed90..d6c63d57a274 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
@@ -383,7 +383,7 @@ static const struct backlight_ops dsicm_bl_ops = {
static void dsicm_get_resolution(struct omap_dss_device *dssdev,
u16 *xres, u16 *yres)
{
- *xres = dssdev->panel.timings.x_res;
+ *xres = dssdev->panel.timings.hactive;
*yres = dssdev->panel.timings.y_res;
}
@@ -893,7 +893,7 @@ static int dsicm_update(struct omap_dss_device *dssdev,
/* XXX no need to send this every frame, but dsi break if not done */
r = dsicm_set_update_window(ddata, 0, 0,
- dssdev->panel.timings.x_res,
+ dssdev->panel.timings.hactive,
dssdev->panel.timings.y_res);
if (r)
goto err;
@@ -1025,7 +1025,7 @@ static int dsicm_memory_read(struct omap_dss_device
*dssdev,
}
size = min(w * h * 3,
- dssdev->panel.timings.x_res *
+ dssdev->panel.timings.hactive *
dssdev->panel.timings.y_res * 3);
in->ops.dsi->bus_lock(in);
@@ -1187,7 +1187,7 @@ static int dsicm_probe(struct platform_device *pdev)
if (r)
return r;
- ddata->timings.x_res = 864;
+ ddata->timings.hactive = 864;
ddata->timings.y_res = 480;
ddata->timings.pixelclock = 864 * 480 * 60;
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
index 6dfb96cea293..c8b
[PATCH v2 10/23] drm/omap: omap_display_timings: Use display_flags for interlace mode
Remove the interlace member and add display_flags to omap_video_timings to
configure the interlace mode.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c | 2 +-
drivers/gpu/drm/omapdrm/displays/connector-hdmi.c | 2 --
drivers/gpu/drm/omapdrm/dss/dispc.c| 7 +++
drivers/gpu/drm/omapdrm/dss/dsi.c | 2 +-
drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 4 ++--
drivers/gpu/drm/omapdrm/dss/hdmi_wp.c | 6 +++---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 4 ++--
drivers/gpu/drm/omapdrm/dss/rfbi.c | 2 +-
drivers/gpu/drm/omapdrm/dss/venc.c | 8
drivers/gpu/drm/omapdrm/omap_connector.c | 6 --
10 files changed, 21 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
index d14cc2e3b8e2..0a7491427832 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
@@ -40,7 +40,7 @@ static const struct omap_video_timings tvc_pal_timings = {
.vfront_porch = 5,
.vback_porch= 41,
- .interlace = true,
+ .flags = DISPLAY_FLAGS_INTERLACED,
};
static const struct of_device_id tvc_of_match[];
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
index 00e3aa212202..8e246b9142d7 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
@@ -34,8 +34,6 @@ static const struct omap_video_timings hdmic_default_timings
= {
.vsync_level= OMAPDSS_SIG_ACTIVE_LOW,
.hsync_level= OMAPDSS_SIG_ACTIVE_LOW,
-
- .interlace = false,
};
struct panel_drv_data {
diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index f21b7dd0f492..858d87dd7fe8 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -2607,7 +2607,7 @@ static int dispc_ovl_setup_common(enum omap_plane plane,
u16 in_height = height;
u16 in_width = width;
int x_predecim = 1, y_predecim = 1;
- bool ilace = mgr_timings->interlace;
+ bool ilace = !!(mgr_timings->flags & DISPLAY_FLAGS_INTERLACED);
unsigned long pclk = dispc_plane_pclk_rate(plane);
unsigned long lclk = dispc_plane_lclk_rate(plane);
@@ -3128,7 +3128,7 @@ bool dispc_mgr_timings_ok(enum omap_channel channel,
if (dss_mgr_is_lcd(channel)) {
/* TODO: OMAP4+ supports interlace for LCD outputs */
- if (timings->interlace)
+ if (timings->flags & DISPLAY_FLAGS_INTERLACED)
return false;
if (!_dispc_lcd_timings_ok(timings->hsync_len,
@@ -3292,7 +3292,7 @@ void dispc_mgr_set_timings(enum omap_channel channel,
DSSDBG("hsync %luHz, vsync %luHz\n", ht, vt);
} else {
- if (t.interlace)
+ if (t.flags & DISPLAY_FLAGS_INTERLACED)
t.vactive /= 2;
if (dispc.feat->supports_double_pixel)
@@ -4232,7 +4232,6 @@ static const struct dispc_errata_i734_data {
.vsync_len = 1, .vfront_porch = 1, .vback_porch = 1,
.vsync_level = OMAPDSS_SIG_ACTIVE_LOW,
.hsync_level = OMAPDSS_SIG_ACTIVE_LOW,
- .interlace = false,
.data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
.de_level = OMAPDSS_SIG_ACTIVE_HIGH,
.sync_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
b/drivers/gpu/drm/omapdrm/dss/dsi.c
index 9ed17dba2849..0d05ac9931a2 100644
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -4122,7 +4122,7 @@ static int dsi_display_init_dispc(struct platform_device
*dsidev,
* override interlace, logic level and edge related parameters in
* omap_video_timings with default values
*/
- dsi->timings.interlace = false;
+ dsi->timings.flags &= ~DISPLAY_FLAGS_INTERLACED;
dsi->timings.hsync_level = OMAPDSS_SIG_ACTIVE_HIGH;
dsi->timings.vsync_level = OMAPDSS_SIG_ACTIVE_HIGH;
dsi->timings.data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE;
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
b/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
index 2baef4f7714b..62268f8d62c6 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
@@ -303,7 +303,7 @@ static void hdmi_core_init(struct hdmi_core_vid_config
*video_cfg,
cfg->timings.vback_porch;
video_cfg->v_fc_config.hdmi_dvi_mode = cfg->hdmi_dvi_mode;
- if (cfg->timings.interlace) {
+ if (cfg->timings.flags & DISPLAY_FLAG
[PATCH v2 12/23] drm/omap: omap_display_timings: Use display_flags for h/vsync level
In preparation to move the stack to use the generic videmode struct for
display timing information use display_flags for h/vsync level.
Signed-off-by: Peter Ujfalusi
---
.../gpu/drm/omapdrm/displays/connector-analog-tv.c | 3 +-
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 4 +--
drivers/gpu/drm/omapdrm/displays/connector-hdmi.c | 3 +-
.../omapdrm/displays/panel-lgphilips-lb035q02.c| 4 +--
.../drm/omapdrm/displays/panel-nec-nl8048hl11.c| 4 +--
.../drm/omapdrm/displays/panel-sharp-ls037v7dw01.c | 4 +--
.../drm/omapdrm/displays/panel-sony-acx565akm.c| 5 ++--
.../drm/omapdrm/displays/panel-tpo-td028ttec1.c| 5 ++--
.../drm/omapdrm/displays/panel-tpo-td043mtea1.c| 4 +--
drivers/gpu/drm/omapdrm/dss/dispc.c| 33 --
drivers/gpu/drm/omapdrm/dss/display.c | 18 ++--
drivers/gpu/drm/omapdrm/dss/dsi.c | 6 ++--
drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 4 +--
drivers/gpu/drm/omapdrm/dss/hdmi_wp.c | 6 ++--
drivers/gpu/drm/omapdrm/dss/omapdss.h | 4 ---
drivers/gpu/drm/omapdrm/dss/rfbi.c | 6 ++--
drivers/gpu/drm/omapdrm/dss/venc.c | 10 +++
drivers/gpu/drm/omapdrm/omap_connector.c | 12
18 files changed, 52 insertions(+), 83 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
index 0a7491427832..264182f97194 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
@@ -40,7 +40,8 @@ static const struct omap_video_timings tvc_pal_timings = {
.vfront_porch = 5,
.vback_porch= 41,
- .flags = DISPLAY_FLAGS_INTERLACED,
+ .flags = DISPLAY_FLAGS_INTERLACED | DISPLAY_FLAGS_HSYNC_LOW |
+ DISPLAY_FLAGS_VSYNC_LOW,
};
static const struct of_device_id tvc_of_match[];
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
index adbcd566a7ec..b81c366ba63a 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
@@ -33,11 +33,11 @@ static const struct omap_video_timings dvic_default_timings
= {
.vsync_len = 4,
.vback_porch= 7,
- .vsync_level= OMAPDSS_SIG_ACTIVE_HIGH,
- .hsync_level= OMAPDSS_SIG_ACTIVE_HIGH,
.data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
.de_level = OMAPDSS_SIG_ACTIVE_HIGH,
.sync_pclk_edge = OMAPDSS_DRIVE_SIG_FALLING_EDGE,
+
+ .flags = DISPLAY_FLAGS_HSYNC_HIGH | DISPLAY_FLAGS_VSYNC_HIGH,
};
struct panel_drv_data {
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
index 8e246b9142d7..f9809f4eb390 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
@@ -32,8 +32,7 @@ static const struct omap_video_timings hdmic_default_timings
= {
.vfront_porch = 11,
.vback_porch= 31,
- .vsync_level= OMAPDSS_SIG_ACTIVE_LOW,
- .hsync_level= OMAPDSS_SIG_ACTIVE_LOW,
+ .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW,
};
struct panel_drv_data {
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
index 9c114da37a6b..999dec6c2cff 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
@@ -33,11 +33,11 @@ static struct omap_video_timings lb035q02_timings = {
.vfront_porch = 4,
.vback_porch= 18,
- .vsync_level= OMAPDSS_SIG_ACTIVE_LOW,
- .hsync_level= OMAPDSS_SIG_ACTIVE_LOW,
.data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
.de_level = OMAPDSS_SIG_ACTIVE_HIGH,
.sync_pclk_edge = OMAPDSS_DRIVE_SIG_FALLING_EDGE,
+
+ .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW,
};
struct panel_drv_data {
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
b/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
index b05ffd41244d..a3cb5c20ce9e 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
@@ -77,11 +77,11 @@ static const struct omap_video_timings
nec_8048_panel_timings = {
.vsync_len = 1,
.vback_porch= 4,
- .vsync_level= OMAPDSS_SIG_ACTIVE_LOW,
- .hsync_level= OMAPDSS_SIG_ACTIVE_LOW,
.data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
.de_level = OMAPDSS_SIG_ACTIVE_HIGH,
.sync_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
+
+ .flags = DISPLAY_FLAGS_HSYN
[PATCH v2 06/23] drm/omap: omap_display_timings: rename vsw to vsync_len
In preparation to move the stack to use the generic videmode struct for
display timing information rename the vsw member to vsync_len.
Signed-off-by: Peter Ujfalusi
---
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/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/dispc.c | 12 ++--
drivers/gpu/drm/omapdrm/dss/display.c | 4 ++--
drivers/gpu/drm/omapdrm/dss/dsi.c | 4 ++--
drivers/gpu/drm/omapdrm/dss/hdmi5_core.c| 6 +++---
drivers/gpu/drm/omapdrm/dss/hdmi_wp.c | 6 +++---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 2 +-
drivers/gpu/drm/omapdrm/dss/rfbi.c | 2 +-
drivers/gpu/drm/omapdrm/dss/venc.c | 4 ++--
drivers/gpu/drm/omapdrm/omap_connector.c| 4 ++--
18 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
index 2dbc6a42fb32..ce33f47f4eea 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
@@ -36,7 +36,7 @@ static const struct omap_video_timings tvc_pal_timings = {
.hsync_len = 64,
.hfront_porch = 12,
.hback_porch= 68,
- .vsw= 5,
+ .vsync_len = 5,
.vfp= 5,
.vbp= 41,
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
index 6cf541cb9933..91516fbc711b 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
@@ -30,7 +30,7 @@ static const struct omap_video_timings dvic_default_timings =
{
.hback_porch= 80,
.vfp= 3,
- .vsw= 4,
+ .vsync_len = 4,
.vbp= 7,
.vsync_level= OMAPDSS_SIG_ACTIVE_HIGH,
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
index 24d047844b7c..6e75da30dc9d 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
@@ -28,7 +28,7 @@ static const struct omap_video_timings hdmic_default_timings
= {
.hsync_len = 96,
.hfront_porch = 16,
.hback_porch= 48,
- .vsw= 2,
+ .vsync_len = 2,
.vfp= 11,
.vbp= 31,
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
index 295904a5f28d..5b2dd1e48705 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
@@ -29,7 +29,7 @@ static struct omap_video_timings lb035q02_timings = {
.hfront_porch = 20,
.hback_porch= 68,
- .vsw= 2,
+ .vsync_len = 2,
.vfp= 4,
.vbp= 18,
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
b/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
index 2eaa290a..c15afc0b28ac 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
@@ -74,7 +74,7 @@ static const struct omap_video_timings nec_8048_panel_timings
= {
.hsync_len = 1,
.hback_porch= 4,
.vfp= 3,
- .vsw= 1,
+ .vsync_len = 1,
.vbp= 4,
.vsync_level= OMAPDSS_SIG_ACTIVE_LOW,
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
b/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
index b36df2c66db1..917f145e8d88 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
@@ -45,7 +45,7 @@ static const struct omap_video_timings sharp_ls_timings = {
.hfront_porch = 1,
.hback_porch= 28,
- .vsw= 1,
+ .vsync_len = 1,
.vfp= 1,
.vbp= 1,
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c
b/drivers/gpu/drm/omapdrm/displays/p
[PATCH v2 00/23] drm/omap: Convert to use videomode from omap_video_timings
Hi, Changes since v1: - separated the patches from the sync drive edge selection series [1] - commit messages updated as per Tomi's comments - other comments from Tomi for patch 10 (was 13) and 11 (was 14) addressed also The following series will convert the omapdrm stack to use the generic videmode instead of the private omap_video_timings struct for the panel information. It depends on the 'video: of: Drive edge selection for sync' series [1] as it is using the flags introduced by the sync drive edge selection support. The patches are most mechanical ones. I have decided to split it up to small chunks and did one change at the time to finally remove the omap_video_timings from omapdrm. generated on top of 4.8-rc7 + [1] Regards, Peter [1] http://marc.info/?l=linux-fbdev&m=147454058512738&w=2 --- Peter Ujfalusi (23): drm/omap: omap_display_timings: rename x_res to hactive drm/omap: omap_display_timings: rename y_res to vactive drm/omap: omap_display_timings: rename hsw to hsync_len drm/omap: omap_display_timings: rename hfp to hfront_porch drm/omap: omap_display_timings: rename hbp to hback_porch drm/omap: omap_display_timings: rename vsw to vsync_len drm/omap: omap_display_timings: rename vfp to vfront_porch drm/omap: omap_display_timings: rename vbp to vback_porch drm/omap: HDMI5: Use pointer to cfg->v_fc_config.timings in hdmi_core_video_config drm/omap: omap_display_timings: Use display_flags for interlace mode drm/omap: dispc: Simplify _dispc_mgr_set_lcd_timings() parameters drm/omap: omap_display_timings: Use display_flags for h/vsync level drm/omap: omap_display_timings: Use display_flags for DE level drm/omap: omap_display_timings: Use display_flags for double_pixel mode drm/omap: omap_display_timings: Use display_flags for pixel data edge drm/omap: omap_display_timings: Use display_flags for sync edge drm/omap: Change the types of struct omap_video_timings members drm/omap: Replace struct omap_video_timings with videomode drm/omap: Use consistent name for struct videomode drm/omap: panel-tpo-td043mtea1: Add note for incorrect sync drive edge drm/omap: panel-tpo-td028ttec1: Add note for incorrect sync drive edge drm/omap: panel-sharp-ls037v7dw01: Add note for incorrect data drive edge drm/omap: panel-lgphilips-lb035q02: Add note for incorrect data drive edge and DE level .../gpu/drm/omapdrm/displays/connector-analog-tv.c | 47 ++--- drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 50 +++-- drivers/gpu/drm/omapdrm/displays/connector-hdmi.c | 49 +++-- drivers/gpu/drm/omapdrm/displays/encoder-opa362.c | 20 +- drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c | 31 ++- .../gpu/drm/omapdrm/displays/encoder-tpd12s015.c | 20 +- drivers/gpu/drm/omapdrm/displays/panel-dpi.c | 30 ++- drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c| 25 ++- .../omapdrm/displays/panel-lgphilips-lb035q02.c| 59 +++--- .../drm/omapdrm/displays/panel-nec-nl8048hl11.c| 52 +++-- .../drm/omapdrm/displays/panel-sharp-ls037v7dw01.c | 58 +++--- .../drm/omapdrm/displays/panel-sony-acx565akm.c| 53 +++-- .../drm/omapdrm/displays/panel-tpo-td028ttec1.c| 57 +++--- .../drm/omapdrm/displays/panel-tpo-td043mtea1.c| 54 ++--- drivers/gpu/drm/omapdrm/dss/dispc.c| 222 + drivers/gpu/drm/omapdrm/dss/display.c | 78 +--- drivers/gpu/drm/omapdrm/dss/dpi.c | 40 ++-- drivers/gpu/drm/omapdrm/dss/dsi.c | 156 --- drivers/gpu/drm/omapdrm/dss/dss.h | 5 +- drivers/gpu/drm/omapdrm/dss/hdmi.h | 8 +- drivers/gpu/drm/omapdrm/dss/hdmi4.c| 31 +-- drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 8 +- drivers/gpu/drm/omapdrm/dss/hdmi5.c| 31 +-- drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 85 drivers/gpu/drm/omapdrm/dss/hdmi_wp.c | 73 --- drivers/gpu/drm/omapdrm/dss/omapdss.h | 98 +++-- drivers/gpu/drm/omapdrm/dss/output.c | 5 +- drivers/gpu/drm/omapdrm/dss/rfbi.c | 49 +++-- drivers/gpu/drm/omapdrm/dss/sdi.c | 33 ++- drivers/gpu/drm/omapdrm/dss/venc.c | 97 + drivers/gpu/drm/omapdrm/omap_connector.c | 87 +--- drivers/gpu/drm/omapdrm/omap_crtc.c| 17 +- drivers/gpu/drm/omapdrm/omap_drv.h | 7 +- drivers/gpu/drm/omapdrm/omap_encoder.c | 10 +- 34 files changed, 759 insertions(+), 986 deletions(-) -- 2.10.0
[PATCH v2 17/23] drm/omap: Change the types of struct omap_video_timings members
omap_video_timings struct have the same members as struct videomode, but
their types are different. As first step change the types of the
omap_video_timings struct members to match their counterpart in
struct videomode to catch any type cast related issues.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 2 +-
drivers/gpu/drm/omapdrm/dss/dispc.c | 5 +++--
drivers/gpu/drm/omapdrm/dss/dpi.c | 2 +-
drivers/gpu/drm/omapdrm/dss/omapdss.h | 18 +-
drivers/gpu/drm/omapdrm/dss/sdi.c | 2 +-
5 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
index 1493671c6e2f..94e897d90172 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
@@ -1024,7 +1024,7 @@ static int dsicm_memory_read(struct omap_dss_device
*dssdev,
goto err1;
}
- size = min(w * h * 3,
+ size = min((u32)w * h * 3,
dssdev->panel.timings.hactive *
dssdev->panel.timings.vactive * 3);
diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 4a4cd743fe2f..498838e74d08 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -2870,7 +2870,8 @@ int dispc_wb_setup(const struct omap_dss_writeback_info
*wi,
int wbdelay;
wbdelay = min(mgr_timings->vfront_porch +
- mgr_timings->vsync_len +
mgr_timings->vback_porch, 255);
+ mgr_timings->vsync_len + mgr_timings->vback_porch,
+ (u32)255);
/* WBDELAYCOUNT */
REG_FLD_MOD(DISPC_OVL_ATTRIBUTES2(plane), wbdelay, 7, 0);
@@ -3242,7 +3243,7 @@ void dispc_mgr_set_timings(enum omap_channel channel,
ht = timings->pixelclock / xtot;
vt = timings->pixelclock / xtot / ytot;
- DSSDBG("pck %u\n", timings->pixelclock);
+ DSSDBG("pck %lu\n", timings->pixelclock);
DSSDBG("hsync_len %d hfp %d hbp %d vsw %d vfp %d vbp %d\n",
t.hsync_len, t.hfront_porch, t.hback_porch,
t.vsync_len, t.vfront_porch, t.vback_porch);
diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c
b/drivers/gpu/drm/omapdrm/dss/dpi.c
index d653f492cbfd..8fb40efa65af 100644
--- a/drivers/gpu/drm/omapdrm/dss/dpi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
@@ -351,7 +351,7 @@ static int dpi_set_mode(struct dpi_data *dpi)
pck = fck / lck_div / pck_div;
if (pck != t->pixelclock) {
- DSSWARN("Could not find exact pixel clock. Requested %d Hz, got
%lu Hz\n",
+ DSSWARN("Could not find exact pixel clock. Requested %lu Hz,
got %lu Hz\n",
t->pixelclock, pck);
t->pixelclock = pck;
diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h
b/drivers/gpu/drm/omapdrm/dss/omapdss.h
index 84d34242d5a4..bd38da3af01f 100644
--- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
+++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
@@ -301,23 +301,23 @@ struct omap_dss_dsi_config {
struct omap_video_timings {
/* Unit: pixels */
- u16 hactive;
+ u32 hactive;
/* Unit: pixels */
- u16 vactive;
+ u32 vactive;
/* Unit: Hz */
- u32 pixelclock;
+ unsigned long pixelclock;
/* Unit: pixel clocks */
- u16 hsync_len; /* Horizontal synchronization pulse width */
+ u32 hsync_len; /* Horizontal synchronization pulse width */
/* Unit: pixel clocks */
- u16 hfront_porch; /* Horizontal front porch */
+ u32 hfront_porch; /* Horizontal front porch */
/* Unit: pixel clocks */
- u16 hback_porch;/* Horizontal back porch */
+ u32 hback_porch;/* Horizontal back porch */
/* Unit: line clocks */
- u16 vsync_len; /* Vertical synchronization pulse width */
+ u32 vsync_len; /* Vertical synchronization pulse width */
/* Unit: line clocks */
- u16 vfront_porch; /* Vertical front porch */
+ u32 vfront_porch; /* Vertical front porch */
/* Unit: line clocks */
- u16 vback_porch;/* Vertical back porch */
+ u32 vback_porch;/* Vertical back porch */
enum display_flags flags;
};
diff --git a/drivers/gpu/drm/omapdrm/dss/sdi.c
b/drivers/gpu/drm/omapdrm/dss/sdi.c
index 3b076329a3ac..c8658f97ab7d 100644
--- a/drivers/gpu/drm/omapdrm/dss/sdi.c
+++ b/drivers/gpu/drm/omapdrm/dss/sdi.c
@@ -162,7 +162,7 @@ static int sdi_display_enable(struct omap_dss_device
*dssdev)
pck = fck / dispc_cinfo.lck_div / dispc_cinfo.pck_div;
if (pck != t->pixelclock) {
- DSSWARN("Could not
[PATCH v2 20/23] drm/omap: panel-tpo-td043mtea1: Add note for incorrect sync drive edge
According to the datasheet of the panel, both data, DEN and sync signals
are expected to be driven on the falling edge of the DOTCLK.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/panel-tpo-td043mtea1.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td043mtea1.c
b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td043mtea1.c
index f78102aab2e6..0787dba44faa 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td043mtea1.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td043mtea1.c
@@ -89,6 +89,10 @@ static const struct videomode tpo_td043_vm = {
.flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_SYNC_POSEDGE |
DISPLAY_FLAGS_PIXDATA_NEGEDGE,
+ /*
+* Note: According to the panel documentation:
+* SYNC needs to be driven on the FALLING edge
+*/
};
#define to_panel_data(p) container_of(p, struct panel_drv_data, dssdev)
--
2.10.0
[PATCH v2 13/23] drm/omap: omap_display_timings: Use display_flags for DE level
In preparation to move the stack to use the generic videmode struct for
display timing information use display_flags for DE level.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 4 ++--
drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c | 2 +-
.../drm/omapdrm/displays/panel-lgphilips-lb035q02.c | 4 ++--
.../gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c | 4 ++--
.../drm/omapdrm/displays/panel-sharp-ls037v7dw01.c| 4 ++--
.../gpu/drm/omapdrm/displays/panel-sony-acx565akm.c | 4 ++--
.../gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c | 4 ++--
.../gpu/drm/omapdrm/displays/panel-tpo-td043mtea1.c | 4 ++--
drivers/gpu/drm/omapdrm/dss/dispc.c | 19 +++
drivers/gpu/drm/omapdrm/dss/display.c | 8
drivers/gpu/drm/omapdrm/dss/dsi.c | 3 ++-
drivers/gpu/drm/omapdrm/dss/omapdss.h | 2 --
drivers/gpu/drm/omapdrm/dss/rfbi.c| 3 ++-
drivers/gpu/drm/omapdrm/dss/venc.c| 6 ++
drivers/gpu/drm/omapdrm/omap_connector.c | 2 +-
15 files changed, 29 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
index b81c366ba63a..b94bfca0ecae 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
@@ -34,10 +34,10 @@ static const struct omap_video_timings dvic_default_timings
= {
.vback_porch= 7,
.data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
- .de_level = OMAPDSS_SIG_ACTIVE_HIGH,
.sync_pclk_edge = OMAPDSS_DRIVE_SIG_FALLING_EDGE,
- .flags = DISPLAY_FLAGS_HSYNC_HIGH | DISPLAY_FLAGS_VSYNC_HIGH,
+ .flags = DISPLAY_FLAGS_HSYNC_HIGH | DISPLAY_FLAGS_VSYNC_HIGH |
+ DISPLAY_FLAGS_DE_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 d768217cefe0..e3b8dddc90bd 100644
--- a/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
+++ b/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
@@ -117,7 +117,7 @@ static void tfp410_fix_timings(struct omap_video_timings
*timings)
{
timings->data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE;
timings->sync_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE;
- timings->de_level = OMAPDSS_SIG_ACTIVE_HIGH;
+ timings->flags |= DISPLAY_FLAGS_DE_HIGH;
}
static void tfp410_set_timings(struct omap_dss_device *dssdev,
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
index 999dec6c2cff..7d4c59bf1950 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
@@ -34,10 +34,10 @@ static struct omap_video_timings lb035q02_timings = {
.vback_porch= 18,
.data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
- .de_level = OMAPDSS_SIG_ACTIVE_HIGH,
.sync_pclk_edge = OMAPDSS_DRIVE_SIG_FALLING_EDGE,
- .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW,
+ .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
+ DISPLAY_FLAGS_DE_HIGH,
};
struct panel_drv_data {
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
b/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
index a3cb5c20ce9e..f0edb4ece16d 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
@@ -78,10 +78,10 @@ static const struct omap_video_timings
nec_8048_panel_timings = {
.vback_porch= 4,
.data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
- .de_level = OMAPDSS_SIG_ACTIVE_HIGH,
.sync_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
- .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW,
+ .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
+ DISPLAY_FLAGS_DE_HIGH,
};
#define to_panel_data(p) container_of(p, struct panel_drv_data, dssdev)
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
b/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
index a83e6a1b894b..a18dd7160df0 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
@@ -50,10 +50,10 @@ static const struct omap_video_timings sharp_ls_timings = {
.vback_porch= 1,
.data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
- .de_level = OMAPDSS_SIG_ACTIVE_HIGH,
.sync_pclk_edge = OMAPDSS_DRIVE_SIG_FALLING_EDGE,
- .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW,
+ .flags
[PATCH v2 11/23] drm/omap: dispc: Simplify _dispc_mgr_set_lcd_timings() parameters
Instead of passing the omap_video_timings structure's members individually,
use the pointer to the struct.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 38 ++---
1 file changed, 14 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 858d87dd7fe8..e29f33fd19cd 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -3141,29 +3141,23 @@ bool dispc_mgr_timings_ok(enum omap_channel channel,
return true;
}
-static void _dispc_mgr_set_lcd_timings(enum omap_channel channel, int
hsync_len,
- int hfp, int hbp, int vsw, int vfp, int vbp,
- enum omap_dss_signal_level vsync_level,
- enum omap_dss_signal_level hsync_level,
- enum omap_dss_signal_edge data_pclk_edge,
- enum omap_dss_signal_level de_level,
- enum omap_dss_signal_edge sync_pclk_edge)
-
+static void _dispc_mgr_set_lcd_timings(enum omap_channel channel,
+ const struct omap_video_timings *ovt)
{
u32 timing_h, timing_v, l;
bool onoff, rf, ipc, vs, hs, de;
- timing_h = FLD_VAL(hsync_len-1, dispc.feat->sw_start, 0) |
- FLD_VAL(hfp-1, dispc.feat->fp_start, 8) |
- FLD_VAL(hbp-1, dispc.feat->bp_start, 20);
- timing_v = FLD_VAL(vsw-1, dispc.feat->sw_start, 0) |
- FLD_VAL(vfp, dispc.feat->fp_start, 8) |
- FLD_VAL(vbp, dispc.feat->bp_start, 20);
+ timing_h = FLD_VAL(ovt->hsync_len - 1, dispc.feat->sw_start, 0) |
+ FLD_VAL(ovt->hfront_porch - 1, dispc.feat->fp_start, 8) |
+ FLD_VAL(ovt->hback_porch - 1, dispc.feat->bp_start, 20);
+ timing_v = FLD_VAL(ovt->vsync_len - 1, dispc.feat->sw_start, 0) |
+ FLD_VAL(ovt->vfront_porch, dispc.feat->fp_start, 8) |
+ FLD_VAL(ovt->vback_porch, dispc.feat->bp_start, 20);
dispc_write_reg(DISPC_TIMING_H(channel), timing_h);
dispc_write_reg(DISPC_TIMING_V(channel), timing_v);
- switch (vsync_level) {
+ switch (ovt->vsync_level) {
case OMAPDSS_SIG_ACTIVE_LOW:
vs = true;
break;
@@ -3174,7 +3168,7 @@ static void _dispc_mgr_set_lcd_timings(enum omap_channel
channel, int hsync_len,
BUG();
}
- switch (hsync_level) {
+ switch (ovt->hsync_level) {
case OMAPDSS_SIG_ACTIVE_LOW:
hs = true;
break;
@@ -3185,7 +3179,7 @@ static void _dispc_mgr_set_lcd_timings(enum omap_channel
channel, int hsync_len,
BUG();
}
- switch (de_level) {
+ switch (ovt->de_level) {
case OMAPDSS_SIG_ACTIVE_LOW:
de = true;
break;
@@ -3196,7 +3190,7 @@ static void _dispc_mgr_set_lcd_timings(enum omap_channel
channel, int hsync_len,
BUG();
}
- switch (data_pclk_edge) {
+ switch (ovt->data_pclk_edge) {
case OMAPDSS_DRIVE_SIG_RISING_EDGE:
ipc = false;
break;
@@ -3210,7 +3204,7 @@ static void _dispc_mgr_set_lcd_timings(enum omap_channel
channel, int hsync_len,
/* always use the 'rf' setting */
onoff = true;
- switch (sync_pclk_edge) {
+ switch (ovt->sync_pclk_edge) {
case OMAPDSS_DRIVE_SIG_FALLING_EDGE:
rf = false;
break;
@@ -3270,11 +3264,7 @@ void dispc_mgr_set_timings(enum omap_channel channel,
}
if (dss_mgr_is_lcd(channel)) {
- _dispc_mgr_set_lcd_timings(channel,
- t.hsync_len, t.hfront_porch, t.hback_porch,
- t.vsync_len, t.vfront_porch, t.vback_porch,
- t.vsync_level, t.hsync_level, t.data_pclk_edge,
- t.de_level, t.sync_pclk_edge);
+ _dispc_mgr_set_lcd_timings(channel, &t);
xtot = t.hactive + t.hfront_porch + t.hsync_len + t.hback_porch;
ytot = t.vactive + t.vfront_porch + t.vsync_len + t.vback_porch;
--
2.10.0
[PATCH] drm/i2c: tda998x: don't register the connector
On Thu, Sep 22, 2016 at 11:39:18AM +0100, Brian Starkey wrote: > Actually, could you please hold off picking this up? We need to make > changes in mali-dp and hdlcd or this will mess up their registration. > I will send those patches later today, but better if this all goes in > together (whenever that ends up being). Sorry, but I'm annoyed with this - the impression being given was that I was holding up this patch by not testing it on Armada, and I brought up the issue about registration at the beginning of this. Now we're _just_ finding out that there are drivers where removing the connector registration in tda998x causes them to break? It's a bit late to be checking your own drivers when you've been chasing me... Sorry, but it sounds like we're not ready to make this change - and as it's the very last day that changes will appear in linux-next prior to the merge window (assuming Linus releases 4.8 on Sunday), I'd suggest holding off until after the merge window is over, so we can get some testing with these other two drivers with this change in place. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[PATCH v2 21/23] drm/omap: panel-tpo-td028ttec1: Add note for incorrect sync drive edge
According to the datasheet of the panel, both data, DEN and sync signals
are expected to be driven on the falling edge of the DOTCLK.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
index c003f4dd2a18..f313dbfcbacb 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
@@ -56,6 +56,10 @@ static struct videomode td028ttec1_panel_vm = {
.flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_SYNC_POSEDGE |
DISPLAY_FLAGS_PIXDATA_NEGEDGE,
+ /*
+* Note: According to the panel documentation:
+* SYNC needs to be driven on the FALLING edge
+*/
};
#define JBT_COMMAND0x000
--
2.10.0
[PATCH] drm/i2c: tda998x: don't register the connector
On Thu, Sep 22, 2016 at 05:32:35AM -0700, Sean Paul wrote: > On Thu, Sep 22, 2016 at 5:09 AM, Russell King - ARM Linux > wrote: > > On Thu, Sep 22, 2016 at 04:22:40AM -0700, Sean Paul wrote: > >> On Thu, Sep 22, 2016 at 3:51 AM, Russell King - ARM Linux > >> wrote: > >> > On Thu, Sep 22, 2016 at 11:39:18AM +0100, Brian Starkey wrote: > >> >> Actually, could you please hold off picking this up? We need to make > >> >> changes in mali-dp and hdlcd or this will mess up their registration. > >> >> I will send those patches later today, but better if this all goes in > >> >> together (whenever that ends up being). > >> > > >> > Sorry, but I'm annoyed with this - the impression being given was that > >> > I was holding up this patch by not testing it on Armada, and I brought > >> > up the issue about registration at the beginning of this. > >> > > >> > Now we're _just_ finding out that there are drivers where removing the > >> > connector registration in tda998x causes them to break? It's a bit > >> > late to be checking your own drivers when you've been chasing me... > >> > > >> > Sorry, but it sounds like we're not ready to make this change - and as > >> > it's the very last day that changes will appear in linux-next prior to > >> > the merge window (assuming Linus releases 4.8 on Sunday), I'd suggest > >> > holding off until after the merge window is over, so we can get some > >> > testing with these other two drivers with this change in place. > >> > > >> > >> sigh. I just pushed my queue to drm-misc, which included this patch. > >> Sounds like I should revert? > > > > Why did you do push it _without_ an ack from the maintainer of the > > driver when the comments on the list were clearly indicating that it > > was waiting for testing and such an ack? > > > > Daniel Acked it on the list on 7/25, and you acked it yesterday asking > it to be merged to -misc. What am I missing? Sorry, I thought you were some random person maintaining some random tree who'd submitted a pull request to be merged into drm-misc. If you are in fact the drm-misc maintainer, please add yourself to the MAINTAINERS file so that everyone knows who you are. Thanks. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[PATCH v2 08/23] drm/omap: omap_display_timings: rename vbp to vback_porch
In preparation to move the stack to use the generic videmode struct for
display timing information rename the vbp member to vback_porch.
Signed-off-by: Peter Ujfalusi
---
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 +-
.../gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c | 2 +-
drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c | 2 +-
.../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/dispc.c | 15 ---
drivers/gpu/drm/omapdrm/dss/display.c | 4 ++--
drivers/gpu/drm/omapdrm/dss/dsi.c | 4 ++--
drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 6 +++---
drivers/gpu/drm/omapdrm/dss/hdmi_wp.c | 6 +++---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 2 +-
drivers/gpu/drm/omapdrm/dss/rfbi.c| 2 +-
drivers/gpu/drm/omapdrm/dss/venc.c| 4 ++--
drivers/gpu/drm/omapdrm/omap_connector.c | 4 ++--
18 files changed, 33 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
index 51d0d45a6675..d14cc2e3b8e2 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
@@ -38,7 +38,7 @@ static const struct omap_video_timings tvc_pal_timings = {
.hback_porch= 68,
.vsync_len = 5,
.vfront_porch = 5,
- .vbp= 41,
+ .vback_porch= 41,
.interlace = true,
};
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
index efd122760833..adbcd566a7ec 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
@@ -31,7 +31,7 @@ static const struct omap_video_timings dvic_default_timings =
{
.vfront_porch = 3,
.vsync_len = 4,
- .vbp= 7,
+ .vback_porch= 7,
.vsync_level= OMAPDSS_SIG_ACTIVE_HIGH,
.hsync_level= OMAPDSS_SIG_ACTIVE_HIGH,
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
index 7d60e465d354..00e3aa212202 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
@@ -30,7 +30,7 @@ static const struct omap_video_timings hdmic_default_timings
= {
.hback_porch= 48,
.vsync_len = 2,
.vfront_porch = 11,
- .vbp= 31,
+ .vback_porch= 31,
.vsync_level= OMAPDSS_SIG_ACTIVE_LOW,
.hsync_level= OMAPDSS_SIG_ACTIVE_LOW,
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
index 66d30ba7db81..9c114da37a6b 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
@@ -31,7 +31,7 @@ static struct omap_video_timings lb035q02_timings = {
.vsync_len = 2,
.vfront_porch = 4,
- .vbp= 18,
+ .vback_porch= 18,
.vsync_level= OMAPDSS_SIG_ACTIVE_LOW,
.hsync_level= OMAPDSS_SIG_ACTIVE_LOW,
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
b/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
index 60fc1d31eec0..b05ffd41244d 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
@@ -75,7 +75,7 @@ static const struct omap_video_timings nec_8048_panel_timings
= {
.hback_porch= 4,
.vfront_porch = 3,
.vsync_len = 1,
- .vbp= 4,
+ .vback_porch= 4,
.vsync_level= OMAPDSS_SIG_ACTIVE_LOW,
.hsync_level= OMAPDSS_SIG_ACTIVE_LOW,
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
b/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
index 3b23aaf2676d..79cb8bde1cca 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
@@ -47,7 +47,7 @@ static const struct omap_video_timings sharp_ls_timings = {
.vsync_len = 1,
.vfront_porch = 1,
- .vbp= 1,
+ .vback_porch= 1,
.vsync_level= OMAPDSS_SIG_ACTIVE_LOW,
.hsync_level= OMAPDSS_SIG_ACTIVE_
[PATCH v2 02/23] drm/omap: omap_display_timings: rename y_res to vactive
In preparation to move the stack to use the generic videmode struct for
display timing information rename the y_res member to vactive.
Signed-off-by: Peter Ujfalusi
---
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/panel-dsi-cm.c| 8
.../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/dispc.c| 14 +++---
drivers/gpu/drm/omapdrm/dss/display.c | 6 +++---
drivers/gpu/drm/omapdrm/dss/dsi.c | 12 ++--
drivers/gpu/drm/omapdrm/dss/hdmi4.c| 3 ++-
drivers/gpu/drm/omapdrm/dss/hdmi5.c| 3 ++-
drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 6 +++---
drivers/gpu/drm/omapdrm/dss/hdmi_wp.c | 2 +-
drivers/gpu/drm/omapdrm/dss/omapdss.h | 2 +-
drivers/gpu/drm/omapdrm/dss/rfbi.c | 6 +++---
drivers/gpu/drm/omapdrm/dss/venc.c | 4 ++--
drivers/gpu/drm/omapdrm/omap_connector.c | 4 ++--
21 files changed, 45 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
index 190a03672181..a57e1efb12ac 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
@@ -31,7 +31,7 @@ struct panel_drv_data {
static const struct omap_video_timings tvc_pal_timings = {
.hactive= 720,
- .y_res = 574,
+ .vactive= 574,
.pixelclock = 1350,
.hsw= 64,
.hfp= 12,
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
index c6e02e1a3799..b25c05c27c80 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
@@ -21,7 +21,7 @@
static const struct omap_video_timings dvic_default_timings = {
.hactive= 640,
- .y_res = 480,
+ .vactive= 480,
.pixelclock = 2350,
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
index ef5ae08b362b..33bc41c5cf71 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
@@ -23,7 +23,7 @@
static const struct omap_video_timings hdmic_default_timings = {
.hactive= 640,
- .y_res = 480,
+ .vactive= 480,
.pixelclock = 25175000,
.hsw= 96,
.hfp= 16,
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
index d6c63d57a274..1493671c6e2f 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
@@ -384,7 +384,7 @@ static void dsicm_get_resolution(struct omap_dss_device
*dssdev,
u16 *xres, u16 *yres)
{
*xres = dssdev->panel.timings.hactive;
- *yres = dssdev->panel.timings.y_res;
+ *yres = dssdev->panel.timings.vactive;
}
static ssize_t dsicm_num_errors_show(struct device *dev,
@@ -894,7 +894,7 @@ static int dsicm_update(struct omap_dss_device *dssdev,
/* XXX no need to send this every frame, but dsi break if not done */
r = dsicm_set_update_window(ddata, 0, 0,
dssdev->panel.timings.hactive,
- dssdev->panel.timings.y_res);
+ dssdev->panel.timings.vactive);
if (r)
goto err;
@@ -1026,7 +1026,7 @@ static int dsicm_memory_read(struct omap_dss_device
*dssdev,
size = min(w * h * 3,
dssdev->panel.timings.hactive *
- dssdev->panel.timings.y_res * 3);
+ dssdev->panel.timings.vactive * 3);
in->ops.dsi->bus_lock(in);
@@ -1188,7 +1188,7 @@ static int dsicm_probe(struct platform_device *pdev)
return r;
ddata->timings.hactive = 864;
- ddata->timings.y_res = 480;
+ ddata->timings.vactive = 480;
ddata->timings.pixelclock = 864 * 480 * 60;
dssdev = &ddata->dssdev;
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
b
[PATCH v2 05/23] drm/omap: omap_display_timings: rename hbp to hback_porch
In preparation to move the stack to use the generic videmode struct for
display timing information rename the hbp member to hback_porch.
Signed-off-by: Peter Ujfalusi
---
.../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 +-
.../drm/omapdrm/displays/panel-lgphilips-lb035q02.c | 2 +-
.../gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c | 2 +-
.../drm/omapdrm/displays/panel-sharp-ls037v7dw01.c| 2 +-
.../gpu/drm/omapdrm/displays/panel-sony-acx565akm.c | 2 +-
.../gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c | 2 +-
.../gpu/drm/omapdrm/displays/panel-tpo-td043mtea1.c | 2 +-
drivers/gpu/drm/omapdrm/dss/dispc.c | 19 ++-
drivers/gpu/drm/omapdrm/dss/display.c | 4 ++--
drivers/gpu/drm/omapdrm/dss/dsi.c | 11 ++-
drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 4 ++--
drivers/gpu/drm/omapdrm/dss/hdmi_wp.c | 6 +++---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 2 +-
drivers/gpu/drm/omapdrm/dss/rfbi.c| 2 +-
drivers/gpu/drm/omapdrm/dss/venc.c| 4 ++--
drivers/gpu/drm/omapdrm/omap_connector.c | 4 ++--
18 files changed, 38 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
index 6d089b337bcb..2dbc6a42fb32 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
@@ -35,7 +35,7 @@ static const struct omap_video_timings tvc_pal_timings = {
.pixelclock = 1350,
.hsync_len = 64,
.hfront_porch = 12,
- .hbp= 68,
+ .hback_porch= 68,
.vsw= 5,
.vfp= 5,
.vbp= 41,
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
index cf893866aca0..6cf541cb9933 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
@@ -27,7 +27,7 @@ static const struct omap_video_timings dvic_default_timings =
{
.hfront_porch = 48,
.hsync_len = 32,
- .hbp= 80,
+ .hback_porch= 80,
.vfp= 3,
.vsw= 4,
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
index fd1178b57f79..24d047844b7c 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
@@ -27,7 +27,7 @@ static const struct omap_video_timings hdmic_default_timings
= {
.pixelclock = 25175000,
.hsync_len = 96,
.hfront_porch = 16,
- .hbp= 48,
+ .hback_porch= 48,
.vsw= 2,
.vfp= 11,
.vbp= 31,
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
index 677db7b22a02..295904a5f28d 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
@@ -27,7 +27,7 @@ static struct omap_video_timings lb035q02_timings = {
.hsync_len = 2,
.hfront_porch = 20,
- .hbp= 68,
+ .hback_porch= 68,
.vsw= 2,
.vfp= 4,
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
b/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
index 8b2601010671..2eaa290a 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
@@ -72,7 +72,7 @@ static const struct omap_video_timings nec_8048_panel_timings
= {
.pixelclock = LCD_PIXEL_CLOCK,
.hfront_porch = 6,
.hsync_len = 1,
- .hbp= 4,
+ .hback_porch= 4,
.vfp= 3,
.vsw= 1,
.vbp= 4,
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
b/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
index c8348090e745..b36df2c66db1 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
@@ -43,7 +43,7 @@ static const struct omap_video_timings sharp_ls_timings = {
.hsync_len = 2,
.hfront_porch = 1,
- .hbp= 28,
+ .hback_porch= 28,
.vsw= 1,
.vfp= 1,
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c
b/drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm
[PATCH v2 15/23] drm/omap: omap_display_timings: Use display_flags for pixel data edge
In preparation to move the stack to use the generic videmode struct for
display timing information use display_flags for pixel data edge.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 3 +--
drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c| 3 +--
.../gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c | 3 +--
drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c | 3 +--
.../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 +--
drivers/gpu/drm/omapdrm/dss/dispc.c | 16 +---
drivers/gpu/drm/omapdrm/dss/display.c| 9 +
drivers/gpu/drm/omapdrm/dss/dsi.c| 3 ++-
drivers/gpu/drm/omapdrm/dss/omapdss.h| 2 --
drivers/gpu/drm/omapdrm/dss/rfbi.c | 3 ++-
drivers/gpu/drm/omapdrm/dss/sdi.c| 2 +-
drivers/gpu/drm/omapdrm/dss/venc.c | 8
drivers/gpu/drm/omapdrm/omap_connector.c | 3 +--
16 files changed, 24 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
index b94bfca0ecae..6f130862db8a 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
@@ -33,11 +33,10 @@ static const struct omap_video_timings dvic_default_timings
= {
.vsync_len = 4,
.vback_porch= 7,
- .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
.sync_pclk_edge = OMAPDSS_DRIVE_SIG_FALLING_EDGE,
.flags = DISPLAY_FLAGS_HSYNC_HIGH | DISPLAY_FLAGS_VSYNC_HIGH |
- DISPLAY_FLAGS_DE_HIGH,
+ DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE,
};
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 e3b8dddc90bd..eec079e017f0 100644
--- a/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
+++ b/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
@@ -115,9 +115,8 @@ static void tfp410_disable(struct omap_dss_device *dssdev)
static void tfp410_fix_timings(struct omap_video_timings *timings)
{
- timings->data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE;
timings->sync_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE;
- timings->flags |= DISPLAY_FLAGS_DE_HIGH;
+ timings->flags |= DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE;
}
static void tfp410_set_timings(struct omap_dss_device *dssdev,
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
index 7d4c59bf1950..33cdc107ed21 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
@@ -33,11 +33,10 @@ static struct omap_video_timings lb035q02_timings = {
.vfront_porch = 4,
.vback_porch= 18,
- .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
.sync_pclk_edge = OMAPDSS_DRIVE_SIG_FALLING_EDGE,
.flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
- DISPLAY_FLAGS_DE_HIGH,
+ DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE,
};
struct panel_drv_data {
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
b/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
index f0edb4ece16d..475420239b40 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
@@ -77,11 +77,10 @@ static const struct omap_video_timings
nec_8048_panel_timings = {
.vsync_len = 1,
.vback_porch= 4,
- .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
.sync_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
.flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
- DISPLAY_FLAGS_DE_HIGH,
+ DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE,
};
#define to_panel_data(p) container_of(p, struct panel_drv_data, dssdev)
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
b/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
index a18dd7160df0..fb7e032209bd 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
@@ -49,11 +49,10 @@ static const struct omap_video_timings sharp_ls_timings = {
.vfront_porch = 1,
.vback_porch= 1,
- .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
.sync_pclk_edge = OMAPD
[ADV7393] DRM Encoder Slave or DRM Bridge
Hi Tomi,
Now with the adv7393 driver in place, I was getting following error.
After debugging found out that this is due to the â.interlace= trueâ
in display timings
âdrivers\gpu\drm\omapdrm\displays\connector-analog-tv.câ.
[ 14.564872] [drm:drm_helper_probe_single_connector_modes_merge_bits]
[CONNECTOR:32:Unknown-1]
[ 14.564882] [drm:omap_connector_get_modes] cvbs_out
[ 14.564898] -->adv7393_check_timings: start
[ 14.569646] [drm:omap_connector_mode_valid] connector: mode
invalid: 45:"720x480i" 120 27000 720 739 801 858 480 490 493 527 0x48
0x2a15
[ 14.569659] [drm:drm_mode_debug_printmodeline] Modeline
45:"720x480i" 120 27000 720 739 801 858 480 490 493 527 0x48
0x2a15
[ 14.569668] [drm:drm_mode_prune_invalid] Not using 720x480i mode: BAD
After setting â.interlace= falseâ in display timings
â\displays\connector-analog-tv.câ mode seems to be valid but still
nothing on display probably because connector still doesnât seem to be
enabled from the below drm log.
[ 14.787200] [drm:drm_setup_crtcs]
[ 14.787211] [drm:drm_enable_connectors] connector 32 enabled? no
[ 14.787220] [drm:drm_enable_connectors] connector 36 enabled? Yes
Could you help me to understand if I could use âinterlace=falseâ?
ADV7393 seems to be supporting non-interlaced mode. From datasheet:
âThe ADV7390/ADV7391/ADV7392/ADV7393 support an SD noninterlaced mode.
Using this mode, progressive inputs at twice the frame rate of NTSC
and PAL (240p/59.94 Hz and 288p/50 Hz, respectively) can be input into
the ADV7390/ ADV7391/ADV7392/ADV7393. The SD noninterlaced mode can be
enabled using Subaddress 0x88, Bit 1.â
What/Where should I need to look for enabling the above connector and
attached to the correct encoder/crtc?
Also looking at function dispc_mgr_timings_ok () in
drivers/gpu/drm/omapdrm/dss/dispc.c, it seems driver of DSS doesnât
support interlace out as comment suggests below. Would this be a
problem for me for driving ADV7393? What does this means?
if (dss_mgr_is_lcd(channel)) {
/* TODO: OMAP4+ supports interlace for LCD outputs */
if (timings->interlace)
{
DSSWARN("vikas->: interlace failed\n");
return false;
}
if (!_dispc_lcd_timings_ok(timings->hsw, timings->hfp,
timings->hbp, timings->vsw, timings->vfp,
timings->vbp))
{
return false;
}
}
Thanks & Regards,
Vikash
On Thu, Sep 15, 2016 at 3:23 PM, Tomi Valkeinen
wrote:
>
>
> On 15/09/16 12:44, Vikas Patil wrote:
>> On Wed, Sep 14, 2016 at 3:04 PM, Tomi Valkeinen
>> wrote:
>>>
>>>
>>> On 13/09/16 16:13, Vikas Patil wrote:
Thanks Tomi for quick comment.
I am thinking to base adv7393 driver on
"drivers\gpu\drm\omapdrm\displays\encoder-tc358768.c" as I don't think
any similar to adv7393 chip driver available. Could you please comment
if this will help to get adv chip running?
>>>
>>> I presume you're not using mainline kernel, as that driver is not there.
>>> I'm not familiar with adv7393, but yes, I think you can use that as an
>>> example.
>>>
>>
>> Thanks a lot for your comments. I am using latest (i.e. 3.00.00.03 )
>> Processor SDK Linux Automotive which is based on linux 4.4.14.
>>
>> As my display panel is connected as follows. I am little confused over
>> the values I need to set for following properties in probe function.
>>
>> DPI1/VOUT1 -16bit DRGB---> ADV7393 (Digital to Analog video
>> encoder) --> CVBS Out --> Display Panel
>>
>>
>> dssdev->ops.dpi = &adv7393_dpi_ops; (atv?)
>> dssdev->type = OMAP_DISPLAY_TYPE_DPI;
>> dssdev->output_type = OMAP_DISPLAY_TYPE_DPI; (Do I need to use
>> OMAP_DISPLAY_TYPE_VENC, but DRA74x do not have VENC Encoder I think)
>> dssdev->phy.dpi.data_lines = ddata->dpi_ndl;
>> dssdev->port_num = 1;
>>
>>
>> As adv7393 takes 16-bit DRGB as input and gives composite as output,
>> does above configuration looks correct? or Do I need to change to
>> something else (e.g. dpi,sdi,dvi, hdmi, atv, dsi)?
>
> The API is quite messy (full of legacy)...
>
> But the "ops" there are for the "downstream" direction, i.e. towards the
> connector. So here you should have atv ops. You should then have
> connector-analog-tv as a device after adv7393, and that connector driver
> will be calling those atv ops.
>
> adv7393 itself will be calling dpi ops, offered by the DSS.
>
> You should set dssdev->type to DPI (that's the input).
> dssdev->output_type to OMAP_DISPLAY_TYPE_VENC (output, although "venc"
> is not quite correct here, but closest match we have). DRA74x doesn't
> have VENC, but this is what the adv7393 outputs.
>
> Tomi
>
[PATCH v2 2/3] video: display_timing: Add flags to select the edge when the sync is driven
The sync can be - and for some panels it must be - driven on different edge
then the data.
Signed-off-by: Peter Ujfalusi
CC: Rob Herring
CC: Mark Rutland
CC: devicetree at vger.kernel.org
---
include/video/display_timing.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/video/display_timing.h b/include/video/display_timing.h
index 28d9d0d566ca..3d289e990aca 100644
--- a/include/video/display_timing.h
+++ b/include/video/display_timing.h
@@ -28,6 +28,10 @@ enum display_flags {
DISPLAY_FLAGS_INTERLACED= BIT(8),
DISPLAY_FLAGS_DOUBLESCAN= BIT(9),
DISPLAY_FLAGS_DOUBLECLK = BIT(10),
+ /* drive sync on pos. edge */
+ DISPLAY_FLAGS_SYNC_POSEDGE = BIT(11),
+ /* drive sync on neg. edge */
+ DISPLAY_FLAGS_SYNC_NEGEDGE = BIT(12),
};
/*
--
2.10.0
[PATCH v2 3/3] video: of: display_timing: Add support for syncclk-active property
Configure the DISPLAY_FLAGS_SYNC_POSEDGE/NEGEDGE flags according to the binding document. If the syncclk-active is present in DT, configure the flags accordingly, if it is omitted it means that the SYNC edge is following the pixdata configuration. Signed-off-by: Peter Ujfalusi CC: Rob Herring CC: Mark Rutland CC: devicetree at vger.kernel.org --- drivers/video/of_display_timing.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/video/of_display_timing.c b/drivers/video/of_display_timing.c index 8a1076beecd3..db992c684f09 100644 --- a/drivers/video/of_display_timing.c +++ b/drivers/video/of_display_timing.c @@ -88,6 +88,15 @@ static int of_parse_display_timing(const struct device_node *np, dt->flags |= val ? DISPLAY_FLAGS_PIXDATA_POSEDGE : DISPLAY_FLAGS_PIXDATA_NEGEDGE; + if (!of_property_read_u32(np, "syncclk-active", &val)) + dt->flags |= val ? DISPLAY_FLAGS_SYNC_POSEDGE : + DISPLAY_FLAGS_SYNC_NEGEDGE; + else if (dt->flags & (DISPLAY_FLAGS_PIXDATA_POSEDGE | + DISPLAY_FLAGS_PIXDATA_NEGEDGE)) + dt->flags |= dt->flags & DISPLAY_FLAGS_PIXDATA_POSEDGE ? + DISPLAY_FLAGS_SYNC_POSEDGE : + DISPLAY_FLAGS_SYNC_NEGEDGE; + if (of_property_read_bool(np, "interlaced")) dt->flags |= DISPLAY_FLAGS_INTERLACED; if (of_property_read_bool(np, "doublescan")) -- 2.10.0
[PATCH] drm/sun4i: rgb: Enable panel after controller
Hi Maxime, On Thursday, 22 September 2016, Maxime Ripard wrote: > On Wed, Sep 21, 2016 at 11:03:04PM +1000, Jonathan Liu wrote: > > The panel should be enabled after the controller so that the panel > > prepare/enable delays are properly taken into account. Similarly, the > > panel should be disabled before the controller so that the panel > > unprepare/disable delays are properly taken into account. > > > > This is useful for avoiding visual glitches. > > This is not really taking any delays into account, especially since > drm_panel_enable and prepare are suppose to block until their > operation is complete. drm_panel_prepare turns on power to the LCD using enable-gpios property of the panel and then blocks for prepare delay. The prepare delay for panel can be set to how long it takes between the time the panel is powered to when it is ready to receive images. If backlight property is specified the backlight will be off while the panel is powered on. drm_panel_enable blocks for enable delay and then turns on the backlight. The enable delay can be set to how long it takes for panel to start making the image visible after receiving the first valid frame. For example if the panel starts off as white and the TFT takes some time to initialize to black before it shows the image being received. Refer to drivers/gpu/drm/panel-panel.simple.c for details. Regards, Jonathan -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160922/28e3d06f/attachment.html>
