From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tobias Jakobi Subject: Re: [PATCH 1/2] drm/exynos: g2d: Add support for old S5Pv210 type Date: Tue, 24 May 2016 18:05:46 +0200 Message-ID: <57447BDA.2000004@math.uni-bielefeld.de> References: <1464096493-13378-1-git-send-email-k.kozlowski@samsung.com> <57445BE5.7060702@math.uni-bielefeld.de> <57445E16.90301@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <57445E16.90301@samsung.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Krzysztof Kozlowski , Inki Dae , Joonyoung Shim , Seung-Woo Kim , Kyungmin Park , David Airlie , Kukjin Kim , Mauro Carvalho Chehab , Marek Szyprowski , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-media@vger.kernel.org Cc: Kamil Debski , Bartlomiej Zolnierkiewicz List-Id: linux-samsung-soc@vger.kernel.org SGVsbG8gS3J6eXN6dG9mLAoKCktyenlzenRvZiBLb3psb3dza2kgd3JvdGU6Cj4gT24gMDUvMjQv MjAxNiAwMzo0OSBQTSwgVG9iaWFzIEpha29iaSB3cm90ZToKPj4gSGVsbG8gS3J6eXN6dG9mLAo+ Pgo+PiBhcmUgeW91IHN1cmUgdGhhdCB0aGVzZSBhcmUgdGhlIG9ubHkgZGlmZmVyZW5jZXMuIEJl Y2F1c2UgQUZBSUsgdGhlcmUKPj4gYXJlIHF1aXRlIGEgZmV3IG1vcmU6Cj4+IC0gRE1BIHN1Ym1p c3Npb24gb2YgY29tbWFuZHMKPj4gLSBibGVuZCBtb2RlIC8gcm91bmRpbmcKPj4gLSBzb2xpZCBm aWxsCj4+IC0gWUNyQ2Igc3VwcG9ydAo+PiAtIGFuZCBwcm9iYWJseSBtb3JlCj4+Cj4+IE9uZSB3 b3VsZCBuZWVkIHRvIGFkZCBsZWFzdCBzcGxpdCB0aGUgY29tbWFuZCBsaXN0IHBhcnNlciBpbnRv IGEgdjMgYW5kCj4+IHY0MSB2ZXJzaW9uIHRvIGFjY29tb2RhdGUgZm9yIHRoZSBkaWZmZXJlbmNl cy4gSW4gZmFjdCB1c2Vyc3BhY2UvbGliZHJtCj4+IHdvdWxkIG5lZWQgdG8ga25vdyB3aGljaCBo dyB0eXBlIGl0IGN1cnJlbnRseSB1c2VzLCBidXQgeW91IGN1cnJlbnRseQo+PiBhbHdheXMgcmV0 dXJuIDQuMSBpbiB0aGUgY29ycmVzcG9uZGluZyBpb2N0bC4KPiAKPiBFaCwgc28gcHJvYmFibHkg bXkgcGF0Y2ggZG9lcyBub3QgY292ZXIgZnVsbHkgdGhlIHN1cHBvcnQgZm9yIHYzIEcyRC4gSQo+ IGxvb2tlZCBtb3N0bHkgYXQgdGhlIGRpZmZlcmVuY2VzIGJldHdlZW4gdjMgYW5kIHY0IGluIHRo ZSBzNXAtZzJkIGRyaXZlcgo+IGl0c2VsZi4gSG93ZXZlciB5b3UgYXJlIHJpZ2h0IHRoYXQgdGhp cyBtaWdodCBiZSBub3Qgc3VmZmljaWVudCBiZWNhdXNlCj4gZXh5bm9zLWcyZCBtb3ZlZCBmb3J3 YXJkIGFuZCBpcyBkaWZmZXJlbnQgdGhhbiBzNXAtZzJkLgo+IAo+PiBLcnp5c3p0b2YgS296bG93 c2tpIHdyb3RlOgo+Pj4gVGhlIG5vbi1EUk0gczVwLWcyZCBkcml2ZXIgc3VwcG9ydHMgdHdvIHZl cnNpb25zIG9mIEcyRDogdjMuMCBvbgo+Pj4gUzVQdjIxMCBhbmQgdjQueCBvbiBFeHlub3MgNHgx MiAob3IgbmV3ZXIpLiBUaGUgZHJpdmVyIGZvciAzLjAgZGV2aWNlCj4+PiB2ZXJzaW9uIGlzIGRv aW5nIHR3byB0aGluZ3MgZGlmZmVyZW50bHk6Cj4+PiAxLiBCZWZvcmUgc3RhcnRpbmcgdGhlIHJl bmRlciBwcm9jZXNzLCBpdCBpbnZhbGlkYXRlcyBjYWNoZXMgKHBhdHRlcm4sCj4+PiAgICBzb3Vy Y2UgYnVmZmVyIGFuZCBtYXNrIGJ1ZmZlcikuIENhY2hlIGNvbnRyb2wgaXMgbm90IHByZXNlbnQg b24gdjQueAo+Pj4gICAgZGV2aWNlLgo+Pj4gMi4gU2NhbGxpbmcgaXMgZG9uZSB0aHJvdWdoIFN0 cmV0Y2hFbiBjb21tYW5kIChpbiBCSVRCTFRfQ09NTUFORF9SRUcKPj4+ICAgIHJlZ2lzdGVyKSBp bnN0ZWFkIG9mIFNSQ19TQ0FMRV9DVFJMX1JFRyBhcyBpbiB2NC54LiBIb3dldmVyIHRoZQo+Pj4g ICAgZXh5bm9zX2RybV9nMmQgZHJpdmVyIGRvZXMgbm90IGltcGxlbWVudCB0aGUgc2NhbGxpbmcg c28gdGhpcwo+Pj4gICAgZGlmZmVyZW5jZSBjYW4gYmUgZWxpbWluYXRlZC4KPj4gSHVoPyBXaGVy ZSBkaWQgeW91IGdldCB0aGlzIGZyb20/IFNjYWxpbmcgd29ya3Mgd2l0aCB0aGUgRFJNIGRyaXZl ci4KPiAKPiBJIHdhcyBsb29raW5nIGZvciB0aGUgdXNhZ2Ugb2Ygc2NhbGluZyByZWcgKGFzIHRo ZXJlIGlzIG5vIHNjYWxpbmcKPiBjb21tYW5kKS4gSG93IHRoZSBzY2FsaW5nIGlzIGltcGxlbWVu dGVkIHRoZW4/Ckxpa2UgeW91IHNhaWQgYWJvdmUgdGhlIGRyaXZlcnMgd29yayBjb21wbGV0bHkg ZGlmZmVyZW50LiBUaGUgRFJNIG9uZQpyZWNlaXZlcyBhIGNvbW1hbmQgbGlzdCB0aGF0IGlzIGNv bnN0cnVjdGVkIGJ5IHVzZXJzcGFjZSAobGliZHJtCm1vc3RseSksIGNvcGllcyBpdCB0byBhIGNv bnRpZ3VvdXMgYnVmZmVyIGFuZCBwYXNzZXMgdGhlIG1lbW9yeSBhZGRyZXNzCm9mIHRoYXQgYnVm ZmVyIHRvIHRoZSBlbmdpbmUgd2hpY2ggdGhlbiB3b3JrcyBvbiBpdC4gT2YgY291cnNlCmV2ZXJ5 dGhpbmcgaXMgc2xpZ2h0bHkgbW9yZSBjb21wbGV4LgoKWW91IGRvbid0IHNlZSBhbnkgcmVmZXJl bmNlIHRvIHNjYWxpbmcgaW4gdGhlIGRyaXZlciBiZWNhdXNlIHRoZSBzY2FsaW5nCnJlZ3MgZG9u J3QgbmVlZCBhbnkga2luZCBvZiBzcGVjaWZpYyB2YWxpZGF0aW9uLgoKSWYgeW91IHdhbnQgdG8g a25vdyBob3cgdGhlIGNvbW1hbmQgbGlzdCBpcyBjb25zdHJ1Y3RlZCwgdGhlIGJlc3Qgd2F5IGlz CnRvIGxvb2sgaW50byBsaWJkcm0uIFRoZSBFeHlub3Mgc3BlY2lmaWMgdGVzdHMgYWN0dWFsbHkg Y292ZXIgc2NhbGluZy4KCgpXaXRoIGJlc3Qgd2lzaGVzLApUb2JpYXMKCgo+IFRoYW5rcyBmb3Ig ZmVlZGJhY2shCj4gCj4gQmVzdCByZWdhcmRzLAo+IEtyenlzenRvZgo+IAoKX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVsIG1haWxpbmcgbGlz dApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0 b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 From: tjakobi@math.uni-bielefeld.de (Tobias Jakobi) Date: Tue, 24 May 2016 18:05:46 +0200 Subject: [PATCH 1/2] drm/exynos: g2d: Add support for old S5Pv210 type In-Reply-To: <57445E16.90301@samsung.com> References: <1464096493-13378-1-git-send-email-k.kozlowski@samsung.com> <57445BE5.7060702@math.uni-bielefeld.de> <57445E16.90301@samsung.com> Message-ID: <57447BDA.2000004@math.uni-bielefeld.de> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hello Krzysztof, Krzysztof Kozlowski wrote: > On 05/24/2016 03:49 PM, Tobias Jakobi wrote: >> Hello Krzysztof, >> >> are you sure that these are the only differences. Because AFAIK there >> are quite a few more: >> - DMA submission of commands >> - blend mode / rounding >> - solid fill >> - YCrCb support >> - and probably more >> >> One would need to add least split the command list parser into a v3 and >> v41 version to accomodate for the differences. In fact userspace/libdrm >> would need to know which hw type it currently uses, but you currently >> always return 4.1 in the corresponding ioctl. > > Eh, so probably my patch does not cover fully the support for v3 G2D. I > looked mostly at the differences between v3 and v4 in the s5p-g2d driver > itself. However you are right that this might be not sufficient because > exynos-g2d moved forward and is different than s5p-g2d. > >> Krzysztof Kozlowski wrote: >>> The non-DRM s5p-g2d driver supports two versions of G2D: v3.0 on >>> S5Pv210 and v4.x on Exynos 4x12 (or newer). The driver for 3.0 device >>> version is doing two things differently: >>> 1. Before starting the render process, it invalidates caches (pattern, >>> source buffer and mask buffer). Cache control is not present on v4.x >>> device. >>> 2. Scalling is done through StretchEn command (in BITBLT_COMMAND_REG >>> register) instead of SRC_SCALE_CTRL_REG as in v4.x. However the >>> exynos_drm_g2d driver does not implement the scalling so this >>> difference can be eliminated. >> Huh? Where did you get this from? Scaling works with the DRM driver. > > I was looking for the usage of scaling reg (as there is no scaling > command). How the scaling is implemented then? Like you said above the drivers work completly different. The DRM one receives a command list that is constructed by userspace (libdrm mostly), copies it to a contiguous buffer and passes the memory address of that buffer to the engine which then works on it. Of course everything is slightly more complex. You don't see any reference to scaling in the driver because the scaling regs don't need any kind of specific validation. If you want to know how the command list is constructed, the best way is to look into libdrm. The Exynos specific tests actually cover scaling. With best wishes, Tobias > Thanks for feedback! > > Best regards, > Krzysztof > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from smtp.math.uni-bielefeld.de ([129.70.45.10]:39551 "EHLO smtp.math.uni-bielefeld.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751990AbcEXQFw (ORCPT ); Tue, 24 May 2016 12:05:52 -0400 Subject: Re: [PATCH 1/2] drm/exynos: g2d: Add support for old S5Pv210 type To: Krzysztof Kozlowski , Inki Dae , Joonyoung Shim , Seung-Woo Kim , Kyungmin Park , David Airlie , Kukjin Kim , Mauro Carvalho Chehab , Marek Szyprowski , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-media@vger.kernel.org Cc: Bartlomiej Zolnierkiewicz , Kamil Debski References: <1464096493-13378-1-git-send-email-k.kozlowski@samsung.com> <57445BE5.7060702@math.uni-bielefeld.de> <57445E16.90301@samsung.com> From: Tobias Jakobi Message-ID: <57447BDA.2000004@math.uni-bielefeld.de> Date: Tue, 24 May 2016 18:05:46 +0200 MIME-Version: 1.0 In-Reply-To: <57445E16.90301@samsung.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Sender: linux-media-owner@vger.kernel.org List-ID: Hello Krzysztof, Krzysztof Kozlowski wrote: > On 05/24/2016 03:49 PM, Tobias Jakobi wrote: >> Hello Krzysztof, >> >> are you sure that these are the only differences. Because AFAIK there >> are quite a few more: >> - DMA submission of commands >> - blend mode / rounding >> - solid fill >> - YCrCb support >> - and probably more >> >> One would need to add least split the command list parser into a v3 and >> v41 version to accomodate for the differences. In fact userspace/libdrm >> would need to know which hw type it currently uses, but you currently >> always return 4.1 in the corresponding ioctl. > > Eh, so probably my patch does not cover fully the support for v3 G2D. I > looked mostly at the differences between v3 and v4 in the s5p-g2d driver > itself. However you are right that this might be not sufficient because > exynos-g2d moved forward and is different than s5p-g2d. > >> Krzysztof Kozlowski wrote: >>> The non-DRM s5p-g2d driver supports two versions of G2D: v3.0 on >>> S5Pv210 and v4.x on Exynos 4x12 (or newer). The driver for 3.0 device >>> version is doing two things differently: >>> 1. Before starting the render process, it invalidates caches (pattern, >>> source buffer and mask buffer). Cache control is not present on v4.x >>> device. >>> 2. Scalling is done through StretchEn command (in BITBLT_COMMAND_REG >>> register) instead of SRC_SCALE_CTRL_REG as in v4.x. However the >>> exynos_drm_g2d driver does not implement the scalling so this >>> difference can be eliminated. >> Huh? Where did you get this from? Scaling works with the DRM driver. > > I was looking for the usage of scaling reg (as there is no scaling > command). How the scaling is implemented then? Like you said above the drivers work completly different. The DRM one receives a command list that is constructed by userspace (libdrm mostly), copies it to a contiguous buffer and passes the memory address of that buffer to the engine which then works on it. Of course everything is slightly more complex. You don't see any reference to scaling in the driver because the scaling regs don't need any kind of specific validation. If you want to know how the command list is constructed, the best way is to look into libdrm. The Exynos specific tests actually cover scaling. With best wishes, Tobias > Thanks for feedback! > > Best regards, > Krzysztof >