From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_2 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BFCB1C432C0 for ; Wed, 20 Nov 2019 08:11:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7D043223B0 for ; Wed, 20 Nov 2019 08:11:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="dBCv593J" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726358AbfKTILB (ORCPT ); Wed, 20 Nov 2019 03:11:01 -0500 Received: from mailgw01.mediatek.com ([210.61.82.183]:21271 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726038AbfKTILA (ORCPT ); Wed, 20 Nov 2019 03:11:00 -0500 X-UUID: 4e2e83daeb2b4a48b4c32685c2e62189-20191120 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References:In-Reply-To:Date:CC:To:From:Subject:Message-ID; bh=Vm5saM+GW0YUbJUNwRCvnRKSP+TQW5BbAxj4dw2J4dY=; b=dBCv593JHT5q6x8wGg9cEEFnlPEW6vdoHgV08dotVzQ4nd+dGQhbKXq+bh8LRvcCUmRmT1iRwwumlbL6OWAGyjks5pxOdQlLuqvUzTyi4NmFlxelzYE7pKulu7SfnxtJdI7H1H86ze4OY/C5IANY+796kSPemvTdflQ7lVW0nX4=; X-UUID: 4e2e83daeb2b4a48b4c32685c2e62189-20191120 Received: from mtkcas06.mediatek.inc [(172.21.101.30)] by mailgw01.mediatek.com (envelope-from ) (Cellopoint E-mail Firewall v4.1.10 Build 0809 with TLS) with ESMTP id 1204473334; Wed, 20 Nov 2019 16:10:51 +0800 Received: from mtkcas08.mediatek.inc (172.21.101.126) by mtkmbs08n1.mediatek.inc (172.21.101.55) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 20 Nov 2019 16:10:34 +0800 Received: from [172.21.84.99] (172.21.84.99) by mtkcas08.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Wed, 20 Nov 2019 16:10:49 +0800 Message-ID: <1574237450.20087.17.camel@mtksdccf07> Subject: Re: [RFC PATCH V3 3/3] platform: mtk-isp: Add Mediatek FD driver From: Jerry-ch Chen To: Tomasz Figa CC: "matthias.bgg@gmail.com" , "mchehab@kernel.org" , "lkml@metux.net" , CK Hu =?UTF-8?Q?=28=E8=83=A1=E4=BF=8A=E5=85=89=29?= , "yuzhao@chromium.org" , "zwisler@chromium.org" , "linux-mediatek@lists.infradead.org" , "linux-arm-kernel@lists.infradead.org" , Sean Cheng =?UTF-8?Q?=28=E9=84=AD=E6=98=87=E5=BC=98=29?= , "Sj Huang =?UTF-8?Q?=28=E9=BB=83=E4=BF=A1=E7=92=8B=29?=" , Christie Yu =?UTF-8?Q?=28=E6=B8=B8=E9=9B=85=E6=83=A0=29?= , Frederic Chen =?UTF-8?Q?=28=E9=99=B3=E4=BF=8A=E5=85=83=29?= , Jungo Lin =?UTF-8?Q?=28=E6=9E=97=E6=98=8E=E4=BF=8A=29?= , Po-Yang Huang =?UTF-8?Q?=28=E9=BB=83=E6=9F=8F=E9=99=BD=29?= , Rynn Wu =?UTF-8?Q?=28=E5=90=B3=E8=82=B2=E6=81=A9=29?= , "linux-media@vger.kernel.org" , srv_heupstream , "devicetree@vger.kernel.org" , "laurent.pinchart+renesas@ideasonboard.com" , "hans.verkuil@cisco.com" Date: Wed, 20 Nov 2019 16:10:50 +0800 In-Reply-To: <20191025035211.GA67000@chromium.org> References: <20190906101125.3784-1-Jerry-Ch.chen@mediatek.com> <20190906101125.3784-4-Jerry-Ch.chen@mediatek.com> <1571109375.3706.40.camel@mtksdccf07> <20191025035211.GA67000@chromium.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 MIME-Version: 1.0 X-MTK: N Content-Transfer-Encoding: base64 Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org SGkgVG9tYXN6LA0KDQpPbiBGcmksIDIwMTktMTAtMjUgYXQgMTE6NTIgKzA4MDAsIFRvbWFzeiBG aWdhIHdyb3RlOg0KPiBPbiBUdWUsIE9jdCAxNSwgMjAxOSBhdCAxMToxNjoxNUFNICswODAwLCBK ZXJyeS1jaCBDaGVuIHdyb3RlOg0KPiA+IEhpIFRvbWFzeiwNCj4gPiANCj4gPiBPbiBGcmksIDIw MTktMDktMDYgYXQgMTg6MTEgKzA4MDAsIEplcnJ5LWNoIENoZW4gd3JvdGU6DQo+ID4gPiBGcm9t OiBKZXJyeS1jaCBDaGVuIDxqZXJyeS1jaC5jaGVuQG1lZGlhdGVrLmNvbT4NCj4gPiA+IA0KPiA+ ID4gVGhpcyBwYXRjaCBhZGRzIHRoZSBkcml2ZXIgb2YgRmFjZSBEZXRlY3Rpb24gKEZEKSB1bml0 IGluDQo+ID4gPiBNZWRpYXRlayBjYW1lcmEgc3lzdGVtLCBwcm92aWRpbmcgZmFjZSBkZXRlY3Rp b24gZnVuY3Rpb24uDQo+ID4gPiANCj4gPiA+IFRoZSBtdGstaXNwIGRpcmVjdG9yeSB3aWxsIGNv bnRhaW4gZHJpdmVycyBmb3IgbXVsdGlwbGUgSVANCj4gPiA+IGJsb2NrcyBmb3VuZCBpbiBNZWRp YXRlayBJU1Agc3lzdGVtLiBJdCB3aWxsIGluY2x1ZGUgSVNQIFBhc3MgMQ0KPiA+ID4gZHJpdmVy IChDQU0pLCBzZW5zb3IgaW50ZXJmYWNlIGRyaXZlciwgRElQIGRyaXZlciBhbmQgZmFjZQ0KPiA+ ID4gZGV0ZWN0aW9uIGRyaXZlci4NCj4gPiA+IA0KPiA+ID4gU2lnbmVkLW9mZi1ieTogSmVycnkt Y2ggQ2hlbiA8amVycnktY2guY2hlbkBtZWRpYXRlay5jb20+DQo+ID4gPiAtLS0NCj4gPiA+ICBk cml2ZXJzL21lZGlhL3BsYXRmb3JtL0tjb25maWcgICAgICAgICAgICAgICAgfCAgICAyICsNCj4g PiA+ICBkcml2ZXJzL21lZGlhL3BsYXRmb3JtL01ha2VmaWxlICAgICAgICAgICAgICAgfCAgICAy ICsNCj4gPiA+ICBkcml2ZXJzL21lZGlhL3BsYXRmb3JtL210ay1pc3AvZmQvS2NvbmZpZyAgICAg fCAgIDE5ICsNCj4gPiA+ICBkcml2ZXJzL21lZGlhL3BsYXRmb3JtL210ay1pc3AvZmQvTWFrZWZp bGUgICAgfCAgICA1ICsNCj4gPiA+ICBkcml2ZXJzL21lZGlhL3BsYXRmb3JtL210ay1pc3AvZmQv bXRrX2ZkLmggICAgfCAgMTQ4ICsrDQo+ID4gPiAgZHJpdmVycy9tZWRpYS9wbGF0Zm9ybS9tdGst aXNwL2ZkL210a19mZF80MC5jIHwgMTIxOSArKysrKysrKysrKysrKysrKw0KPiA+ID4gIGluY2x1 ZGUvdWFwaS9saW51eC9tdGstZmQtdjRsMi1jb250cm9scy5oICAgICB8ICAgNjkgKw0KPiA+ID4g IGluY2x1ZGUvdWFwaS9saW51eC92NGwyLWNvbnRyb2xzLmggICAgICAgICAgICB8ICAgIDQgKw0K PiA+ID4gIDggZmlsZXMgY2hhbmdlZCwgMTQ2OCBpbnNlcnRpb25zKCspDQo+ID4gPiAgY3JlYXRl IG1vZGUgMTAwNjQ0IGRyaXZlcnMvbWVkaWEvcGxhdGZvcm0vbXRrLWlzcC9mZC9LY29uZmlnDQo+ ID4gPiAgY3JlYXRlIG1vZGUgMTAwNjQ0IGRyaXZlcnMvbWVkaWEvcGxhdGZvcm0vbXRrLWlzcC9m ZC9NYWtlZmlsZQ0KPiA+ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCBkcml2ZXJzL21lZGlhL3BsYXRm b3JtL210ay1pc3AvZmQvbXRrX2ZkLmgNCj4gPiA+ICBjcmVhdGUgbW9kZSAxMDA2NDQgZHJpdmVy cy9tZWRpYS9wbGF0Zm9ybS9tdGstaXNwL2ZkL210a19mZF80MC5jDQo+ID4gPiAgY3JlYXRlIG1v ZGUgMTAwNjQ0IGluY2x1ZGUvdWFwaS9saW51eC9tdGstZmQtdjRsMi1jb250cm9scy5oDQo+ID4g PiANCj4gDQo+IFtzbmlwXQ0KPiANCj4gPiA+ICtzdGF0aWMgaW50IG10a19mZF9qb2JfYWJvcnQo c3RydWN0IG10a19mZF9kZXYgKmZkKQ0KPiA+ID4gK3sNCj4gPiA+ICsJdTMyIHJldDsNCj4gPiA+ ICsNCj4gPiA+ICsJcmV0ID0gd2FpdF9mb3JfY29tcGxldGlvbl90aW1lb3V0KCZmZC0+ZmRfaXJx X2RvbmUsDQo+ID4gPiArCQkJCQkgIG1zZWNzX3RvX2ppZmZpZXMoTVRLX0ZEX0hXX1RJTUVPVVQp KTsNCj4gPiA+ICsJLyogUmVzZXQgRkQgSFcgKi8NCj4gPiA+ICsJaWYgKCFyZXQpIHsNCj4gPiA+ ICsJCXN0cnVjdCBpcGlfbWVzc2FnZSBmZF9pcGlfbXNnOw0KPiA+ID4gKw0KPiA+ID4gKwkJZmRf aXBpX21zZy5jbWRfaWQgPSBNVEtfRkRfSVBJX0NNRF9SRVNFVDsNCj4gPiA+ICsJCWlmIChzY3Bf aXBpX3NlbmQoZmQtPnNjcF9wZGV2LCBTQ1BfSVBJX0ZEX0NNRCwgJmZkX2lwaV9tc2csDQo+ID4g PiArCQkJCSBzaXplb2YoZmRfaXBpX21zZyksIE1US19GRF9JUElfU0VORF9USU1FT1VUKSkNCj4g PiA+ICsJCQlkZXZfZXJyKGZkLT5kZXYsICJGRCBSZXNldCBIVyBlcnJvclxuIik7DQo+ID4gPiAr CQlyZXR1cm4gLUVUSU1FRE9VVDsNCj4gPiA+ICsJfQ0KPiA+ID4gKwlyZXR1cm4gMDsNCj4gPiA+ ICt9DQo+ID4gPiArDQo+ID4gDQo+ID4gQ29udGludWUgdGhlIGRpc2N1c3Npb24gYWJvdXQgam9i IGFib3J0IGluIFJGQyB2MiwNCj4gPiANCj4gPiBJIHRoaW5rIHRoZSBqb2JfYWJvcnQgY2FsbGJh Y2sgaW4gdjRsMl9tMm1fb3BzKCkgbWlnaHQgYmUgdXNlZnVsLg0KPiA+IA0KPiA+IHJlZjoNCj4g PiBodHRwczovL2VsaXhpci5ib290bGluLmNvbS9saW51eC92NS40LXJjMi9zb3VyY2UvZHJpdmVy cy9tZWRpYS92NGwyLWNvcmUvdjRsMi1tZW0ybWVtLmMjTDM5OA0KPiA+IGh0dHBzOi8vZWxpeGly LmJvb3RsaW4uY29tL2xpbnV4L3Y1LjQtcmMyL3NvdXJjZS9pbmNsdWRlL21lZGlhL3Y0bDItbWVt Mm1lbS5oI0w0Mw0KPiA+IA0KPiA+IGluIGRyaXZlcnMvbWVkaWEvdjRsMi1jb3JlL3Y0bDItbWVt Mm1lbS5jICMzOTggdjRsMl9tMm1fY2FuY2VsX2pvYigpDQo+ID4gLi4uDQo+ID4gaWYgKG0ybV9j dHgtPmpvYl9mbGFncyAmIFRSQU5TX1JVTk5JTkcpIHsNCj4gPiAJc3Bpbl91bmxvY2tfaXJxcmVz dG9yZSgmbTJtX2Rldi0+am9iX3NwaW5sb2NrLCBmbGFncyk7DQo+ID4gCWlmIChtMm1fZGV2LT5t Mm1fb3BzLT5qb2JfYWJvcnQpDQo+ID4gCQltMm1fZGV2LT5tMm1fb3BzLT5qb2JfYWJvcnQobTJt X2N0eC0+cHJpdik7DQo+ID4gCWRwcmludGsoIm0ybV9jdHggJXAgcnVubmluZywgd2lsbCB3YWl0 IHRvIGNvbXBsZXRlXG4iLCBtMm1fY3R4KTsNCj4gPiAJd2FpdF9ldmVudChtMm1fY3R4LT5maW5p c2hlZCwNCj4gPiAJCQkhKG0ybV9jdHgtPmpvYl9mbGFncyAmIFRSQU5TX1JVTk5JTkcpKTsNCj4g PiB9IC4uLg0KPiA+IA0KPiA+IElmIHRoaXMgb3BlcmF0aW9uIGlzIHNldCwgd2UgbWlnaHQgdXNl IHRoZSB2NGwyX20ybV9jYW5jZWxfam9iKCkgd2hlbg0KPiA+IHN1c3BlbmQsIGFuZCBpdCB3aWxs IGRvIG10a19mZF9qb2JfYWJvcnQoKSBoZXJlLg0KPiA+DQo+IA0KPiBUaGUgZXhwZWN0YXRpb24g Zm9yIC5qb2JfYWJvcnQoKSBpcyB0aGF0IHNpZ25hbHMgdGhlIGhhcmR3YXJlIHRvDQo+IGluc3Rh bnRseSBhYmFuZG9uIHRoZSBjdXJyZW50IGpvYi4gRG8gd2UgaGF2ZSBhIHdheSB0byB0ZWxsIHRo ZQ0KPiBmaXJtd2FyZS9oYXJkd2FyZSB0byBkbyBzbz8NCj4gDQo+IEFsc28sIHN1c3BlbmQgbXVz dCBub3QgYWJvcnQgdGhlIGN1cnJlbnQgam9iLiBBbnl0aGluZyB0aGF0IHdhcyBhbHJlYWR5DQo+ IHJ1bm5pbmcgaXMgZXhwZWN0ZWQgdG8gY29tcGxldGUgc3VjY2Vzc2Z1bHkgYW5kIGZ1cnRoZXIg am9icyBzaG91bGQNCj4gY29udGludWUgZXhlY3V0aW5nIG9uY2UgdGhlIHN5c3RlbSByZXN1bWVz Lg0KPiANCkkgYXBwcmVjaWF0ZSB5b3VyIGNvbW1lbnRzIGFuZCBQaS1Ic3VuJ3MgcGF0Y2gsDQoN Ck9rLCBJIHNlZS4NCkZvciBGRDQwLCB3ZSBjYW4ndCB0ZWxsIHRoZSBmaXJtd2FyZS9oYXJkd2Fy ZSB0byBpbnN0YW50bHkgYWJhbmRvbiB0aGUNCmN1cnJlbnQgam9iLg0KVGhlcmVmb3JlLCBmb3Ig c3VzcGVuZCwgd2Ugc3RvcCBzZW5kaW5nIGZ1cnRoZXIgam9icyB0byBoYXJkd2FyZSBhbmQNCndh aXQgZm9yIHRoZSBjb21wbGV0aW9uIG9mIHRoZSBydW5uaW5nIGpvYi4NCkZvciByZXN1bWUsIHdl IGNvbnRpbnVlIHNlbmRpbmcgam9icyB0byBoYXJkd2FyZS4NCg0KPiBbc25pcF0NCj4gDQo+ID4g PiArDQo+ID4gPiArc3RhdGljIGludCBtdGtfZmRfc3VzcGVuZChzdHJ1Y3QgZGV2aWNlICpkZXYp DQo+ID4gPiArew0KPiA+ID4gKwlzdHJ1Y3QgbXRrX2ZkX2RldiAqZmQgPSBkZXZfZ2V0X2RydmRh dGEoZGV2KTsNCj4gPiA+ICsNCj4gPiA+ICsJaWYgKHBtX3J1bnRpbWVfc3VzcGVuZGVkKGRldikp DQo+ID4gPiArCQlyZXR1cm4gMDsNCj4gPiA+ICsNCj4gPiA+ICsJaWYgKGZkLT5mZF9zdHJlYW1f Y291bnQpDQo+ID4gPiArCQlpZiAobXRrX2ZkX2pvYl9hYm9ydChmZCkpDQo+ID4gPiArCQkJbXRr X2ZkX2h3X2pvYl9maW5pc2goZmQsIFZCMl9CVUZfU1RBVEVfRVJST1IpOw0KPiA+ID4gKw0KPiA+ IA0KPiA+IFRvIGF2b2lkIG10a19mZF9od19qb2JfZmluaXNoKCkgdHJpZ2dlciB0aGUgbmV4dCBq b2IsDQo+ID4gSSBzdXBwb3NlIHRoYXQgd2UgY291bGQgdXNlIHY0bDJfbTJtX2NhbmNlbF9qb2Ig aW5zdGVhZCBvZiBqb2JfYWJvcnQgYW5kDQo+ID4gam9iX2ZpbmlzaCBoZXJlLg0KPiA+IA0KPiA+ IC8qKg0KPiA+ICAqIHY0bDJfbTJtX2NhbmNlbF9qb2IoKSAtIGNhbmNlbCBwZW5kaW5nIGpvYnMg Zm9yIHRoZSBjb250ZXh0DQo+ID4gICogQG0ybV9jdHg6IG0ybSBjb250ZXh0IHdpdGggam9icyB0 byBiZSBjYW5jZWxlZA0KPiA+ICAqDQo+ID4gICogSW4gY2FzZSBvZiBzdHJlYW1vZmYgb3IgcmVs ZWFzZSBjYWxsZWQgb24gYW55IGNvbnRleHQsDQo+ID4gICogMV0gSWYgdGhlIGNvbnRleHQgaXMg Y3VycmVudGx5IHJ1bm5pbmcsIHRoZW4gYWJvcnQgam9iIHdpbGwgYmUgY2FsbGVkDQo+ID4gICog Ml0gSWYgdGhlIGNvbnRleHQgaXMgcXVldWVkLCB0aGVuIHRoZSBjb250ZXh0IHdpbGwgYmUgcmVt b3ZlZCBmcm9tDQo+ID4gICogICAgdGhlIGpvYl9xdWV1ZQ0KPiA+ICAqLw0KPiA+IA0KPiA+IG9y IGFub3RoZXIgd2F5LA0KPiA+IHdlIG1heSBhZGQgYSBmbGFnIGFuZCBpbXBsZW1lbnQgbXRrX2Zk X2pvYl9yZWFkeSgpIHRoYXQgcmVhZHMgdGhlIGZsYWcNCj4gPiBpZiB3ZSBzdXNwZW5kLCB3ZSBz ZXQgdGhlIGZsYWcgYW5kIGRvIGpvYl9hYm9ydCBhbmQgam9iX2ZpbmlzaCwgZXZlbiBpZg0KPiA+ IGl0IHRyeSBlbnF1ZXVlLCBpdCB3aWxsIHN0aWxsIG5vdCByZWFsbHkgcXVldWUgdGhlIGpvYiwg dW50aWwgd2UgcmVzZXQNCj4gPiB0aGUgZmxhZyBpbiBtdGtfZmRfcmVzdW1lKCkuDQo+ID4gDQo+ ID4gaG93IGRvIHlvdSB0aGluaz8NCj4gPg0KPiANCj4gQXMgcGVyIG15IGNvbW1lbnQgYWJvdmUs IHN1c3BlbmQgbXVzdCBqdXN0IHBhdXNlIHRoZSBleGVjdXRpb24gb2YgdGhlDQo+IGpvYnMuIEl0 IG11c3Qgbm90IGNhdXNlIGFueSBqb2JzIHRvIGJlIHNraXBwZWQuDQo+IA0KPiBBZnRlciBhbmFs eXppbmcgdGhlIG0ybSBmcmFtZXdvcmsgYW5kIGV4aXN0aW5nIG0ybSBkcml2ZXJzIEkgcmVhbGl6 ZWQNCj4gdGhhdCB0aGV5IGN1cnJlbnRseSBwcm92aWRlIG5vIHdheSB0byBjb3JyZWN0bHkgaGFu ZGxlIHN1c3BlbmQvcmVzdW1lLg0KPiBQaS1Ic3VuIGhhcyBiZWVuIGxvb2tpbmcgaW50byBmaXhp bmcgdGhpcyBpbiBjcnJldi5jb20vYy8xODc4MTEyIGFuZA0KPiB3ZSdsbCBzZW5kIGl0IHVwc3Ry ZWFtIGFzIHNvb24gYXMgd2UgZ2V0IHNvbWV0aGluZyB0aGF0IHNob3VsZCBoYW5kbGUNCj4gYWxs IHRoZSBjYXNlcyBjb3JyZWN0bHkuDQo+IA0KT2ssIHRoYW5rcyBmb3IgdGhlIHBhdGNoZXMuDQoN Cj4gPiA+ICsJLyogc3VzcGVuZCBGRCBIVyAqLw0KPiA+ID4gKwl3cml0ZWwoMHgwLCBmZC0+ZmRf YmFzZSArIE1US19GRF9SRUdfT0ZGU0VUX0lOVF9FTik7DQo+ID4gPiArCXdyaXRlbCgweDAsIGZk LT5mZF9iYXNlICsgTVRLX0ZEX1JFR19PRkZTRVRfSFdfRU5BQkxFKTsNCj4gPiA+ICsJY2xrX2Rp c2FibGVfdW5wcmVwYXJlKGZkLT5mZF9jbGspOw0KPiA+ID4gKwlkZXZfZGJnKGRldiwgIiVzOmRp c2FibGUgY2xvY2tcbiIsIF9fZnVuY19fKTsNCj4gPiA+ICsNCj4gPiA+ICsJcmV0dXJuIDA7DQo+ ID4gPiArfQ0KPiA+ID4gKw0KPiA+ID4gK3N0YXRpYyBpbnQgbXRrX2ZkX3Jlc3VtZShzdHJ1Y3Qg ZGV2aWNlICpkZXYpDQo+ID4gPiArew0KPiA+ID4gKwlzdHJ1Y3QgbXRrX2ZkX2RldiAqZmQgPSBk ZXZfZ2V0X2RydmRhdGEoZGV2KTsNCj4gPiA+ICsJaW50IHJldDsNCj4gPiA+ICsNCj4gPiA+ICsJ aWYgKHBtX3J1bnRpbWVfc3VzcGVuZGVkKGRldikpDQo+ID4gPiArCQlyZXR1cm4gMDsNCj4gPiA+ ICsNCj4gPiA+ICsJcmV0ID0gY2xrX3ByZXBhcmVfZW5hYmxlKGZkLT5mZF9jbGspOw0KPiA+ID4g KwlpZiAocmV0IDwgMCkgew0KPiA+ID4gKwkJZGV2X2RiZyhkZXYsICJGYWlsZWQgdG8gb3BlbiBm ZCBjbGs6JWRcbiIsIHJldCk7DQo+ID4gPiArCQlyZXR1cm4gcmV0Ow0KPiA+ID4gKwl9DQo+ID4g PiArDQo+ID4gPiArCS8qIHJlc3VtZSBGRCBIVyAqLw0KPiA+ID4gKwl3cml0ZWwoTVRLX0ZEX1NF VF9IV19FTkFCTEUsIGZkLT5mZF9iYXNlICsgTVRLX0ZEX1JFR19PRkZTRVRfSFdfRU5BQkxFKTsN Cj4gPiA+ICsJd3JpdGVsKDB4MSwgZmQtPmZkX2Jhc2UgKyBNVEtfRkRfUkVHX09GRlNFVF9JTlRf RU4pOw0KPiA+ID4gKwlkZXZfZGJnKGRldiwgIiVzOmVuYWJsZSBjbG9ja1xuIiwgX19mdW5jX18p Ow0KPiANCj4gQnkgdGhlIHdheSwgd2UgbmVlZCB0byBraWNrIHRoZSBtMm0gZnJhbWV3b3JrIGhl cmUgdG8gc2NoZWR1bGUgZnVydGhlcg0KPiBqb2JzLiBQaS1Ic3VuJ3MgcGF0Y2ggd2lsbCBhbHNv IHRha2UgY2FyZSBvZiB0aGlzLg0KPiANCk9rLCBJIHNlZS4NCkkgd291bGQgbGlrZSB0byB1c2Ug UGktSHN1bidzIHBhdGNoLCBvdGhlcndpc2UgSSB3b3VsZCBuZWVkIHRvIGNhbGwNCnY0bDJfbTJt X3RyeV9ydW4oKSBoZXJlLg0KDQo+IFtzbmlwXQ0KPiANCj4gPiA+ICsvKiBTZXQgdGhlIGZhY2Ug YW5nbGUgYW5kIGRpcmVjdGlvbnMgdG8gYmUgZGV0ZWN0ZWQgKi8NCj4gPiA+ICsjZGVmaW5lIFY0 TDJfQ0lEX01US19GRF9ERVRFQ1RfUE9TRQkJKFY0TDJfQ0lEX1VTRVJfTVRLX0ZEX0JBU0UgKyAx KQ0KPiA+ID4gKw0KPiA+ID4gKy8qIFNldCBpbWFnZSB3aWR0aHMgZm9yIGFuIGlucHV0IGltYWdl IHRvIGJlIHNjYWxlZCBkb3duIGZvciBmYWNlIGRldGVjdGlvbiAqLw0KPiA+ID4gKyNkZWZpbmUg VjRMMl9DSURfTVRLX0ZEX1NDQUxFX0RPV05fSU1HX1dJRFRICShWNEwyX0NJRF9VU0VSX01US19G RF9CQVNFICsgMikNCj4gPiA+ICsNCj4gPiA+ICsvKiBTZXQgaW1hZ2UgaGVpZ2h0cyBmb3IgYW4g aW5wdXQgaW1hZ2UgdG8gYmUgc2NhbGVkIGRvd24gZm9yIGZhY2UgZGV0ZWN0aW9uICovDQo+ID4g PiArI2RlZmluZSBWNEwyX0NJRF9NVEtfRkRfU0NBTEVfRE9XTl9JTUdfSEVJR0hUCShWNEwyX0NJ RF9VU0VSX01US19GRF9CQVNFICsgMykNCj4gPiA+ICsNCj4gPiA+ICsvKiBTZXQgdGhlIGxlbmd0 aCBvZiBzY2FsZSBkb3duIHNpemUgYXJyYXkgKi8NCj4gPiA+ICsjZGVmaW5lIFY0TDJfQ0lEX01U S19GRF9TQ0FMRV9JTUdfTlVNCQkoVjRMMl9DSURfVVNFUl9NVEtfRkRfQkFTRSArIDQpDQo+ID4g PiArDQo+ID4gPiArLyogU2V0IHRoZSBkZXRlY3Rpb24gc3BlZWQsIHVzdWFsbHkgcmVkdWNpbmcg YWNjdXJhY3kuICovDQo+ID4gPiArI2RlZmluZSBWNEwyX0NJRF9NVEtfRkRfREVURUNUX1NQRUVE CQkoVjRMMl9DSURfVVNFUl9NVEtfRkRfQkFTRSArIDUpDQo+ID4gPiArDQo+ID4gPiArLyogU2Vs ZWN0IHRoZSBkZXRlY3Rpb24gbW9kZWwgb3IgYWxnb3JpdGhtIHRvIGJlIHVzZWQuICovDQo+ID4g PiArI2RlZmluZSBWNEwyX0NJRF9NVEtfRkRfREVURUNUSU9OX01PREVMCQkoVjRMMl9DSURfVVNF Ul9NVEtfRkRfQkFTRSArIDYpDQo+ID4gPiArDQo+ID4gPiArLyogV2UgcmVzZXJ2ZSAxNiBjb250 cm9scyBmb3IgdGhpcyBkcml2ZXIuICovDQo+ID4gPiArI2RlZmluZSBWNEwyX0NJRF9NVEtfRkRf TUFYCQkJMTYNCj4gPiA+ICsNCj4gPiANCj4gPiBGb3IgdGhlc2UgY29udHJvbCBJRHMsIEkgdGhp bmsgdGhlIGZvbGxvd2luZyBzaG91bGQgYmUgcmVtYWluZWQgYXMgY2hpcA0KPiA+IHNwZWNpZmlj IGNvbnRyb2xzLg0KPiA+IFY0TDJfQ0lEX01US19GRF9TQ0FMRV9ET1dOX0lNR19XSURUSCwNCj4g PiBWNEwyX0NJRF9NVEtfRkRfU0NBTEVfRE9XTl9JTUdfSEVJR0hUIGFuZCBWNEwyX0NJRF9NVEtf RkRfU0NBTEVfSU1HX05VTSANCj4gPiANCj4gPiBIb3BlIHRoZXJlIHdvdWxkIGJlIHN0YW5kYXJk aXppbmcgZmFjZSBkZXRlY3Rpb24gYXBpIHRoYXQgY292ZXIgdGhlIHJlc3QNCj4gPiBjb250cm9s czogVjRMMl9DSURfTVRLX0ZEX0RFVEVDVF9QT1NFLCBWNEwyX0NJRF9NVEtfRkRfREVURUNUX1NQ RUVEIGFuZA0KPiA+IFY0TDJfQ0lEX01US19GRF9ERVRFQ1RJT05fTU9ERUwNCj4gPiANCj4gPiBX b3VsZCB5b3UgaGF2ZSBhbnkgc3VnZ2VzdGlvbnMgb24gaG93IHRvIHByb3Bvc2UgdGhlIHN0YW5k YXJkIGZhY2UNCj4gPiBkZXRlY3Rpb24gYXBpcz8NCj4gPiANCj4gDQo+IEdpdmVuIG5vIGZvbGxv dyB1cCBmZWVkYmFjayBmcm9tIHRoZSBjb21tdW5pdHksIEkgdGhpbmsgd2UgY2FuIGtlZXAgdGhl bQ0KPiBhcyBkcml2ZXItc3BlY2lmaWMsIGJ1dCBzaG91bGQgbWFrZSBzdXJlIHRoYXQgdGhleSBo YXZlIHNvbWUgcmVhc29uYWJsZQ0KPiBkZWZhdWx0IHZhbHVlcyBpbiBjYXNlIGFuIGFwcGxpY2F0 aW9uIGRvZXNuJ3QgcmVjb2duaXplIHRoZW0uDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IFRvbWFz eg0KPiANClNob3VsZCBJIGtlZXAgdGhlIGZpbGUgIm10ay1mZC12NGwyLWNvbnRyb2xzLmgiIHdo aWNoIGRlZmluZXMgdGhlDQpjb250cm9sIGlkcyB1bmRlciB0aGUgZm9sZGVyICIvaW5jbHVkZS91 YXBpL2xpbnV4Ij8NCg0KDQpUaGFua3MgYW5kIEJlc3QgcmVnYXJkcywNCkplcnJ5DQo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_2 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D5545C432C0 for ; Wed, 20 Nov 2019 08:21:16 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8C4172231D for ; Wed, 20 Nov 2019 08:21:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="UmRL7ZuQ"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="dBCv593J" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8C4172231D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=8/zaPqlNPF3W0Xbyt2oy9NY+/tMGRmtd8PaMiLQkYVo=; b=UmRL7ZuQDBlCax 3sNCPuvE7y1pYqdMG+O6t4SragFKFc79obidkQnytpZN2lm9PfrQW6es77EmIv31WVfqByVhtYrHP xTtFsiqTjSoIPqqJng3EFWhSnAhRGB+KXokyiqMYUrV1Xm6Z69aI7L8GOC75QBbh2PB1EjOty+Hl8 Tv3LcaTIG68sNIra8RjiotIzweIlnZhrFL8JgHmUevSnO7Id3AkdOtupP5fe/qg47dfGakrRkTamT aF2aN+CUtkR0J7zYvEuKzapqQ1UfvNWoZuODA9n3oifWsEiF/2EBS01IVpoFHrRhHl4aVx4SLhAiS dXu2Q/ULoZDKCsVsluLw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iXLEh-0008HN-Mi; Wed, 20 Nov 2019 08:21:15 +0000 Received: from mailgw02.mediatek.com ([216.200.240.185]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1iXLEW-00089h-Gn; Wed, 20 Nov 2019 08:21:06 +0000 X-UUID: a0a99c6b69b84e028239cfce7db7ddf1-20191120 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References:In-Reply-To:Date:CC:To:From:Subject:Message-ID; bh=Vm5saM+GW0YUbJUNwRCvnRKSP+TQW5BbAxj4dw2J4dY=; b=dBCv593JHT5q6x8wGg9cEEFnlPEW6vdoHgV08dotVzQ4nd+dGQhbKXq+bh8LRvcCUmRmT1iRwwumlbL6OWAGyjks5pxOdQlLuqvUzTyi4NmFlxelzYE7pKulu7SfnxtJdI7H1H86ze4OY/C5IANY+796kSPemvTdflQ7lVW0nX4=; X-UUID: a0a99c6b69b84e028239cfce7db7ddf1-20191120 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw02.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLS) with ESMTP id 1633443104; Wed, 20 Nov 2019 00:21:01 -0800 Received: from mtkmbs08n1.mediatek.inc (172.21.101.55) by MTKMBS62N1.mediatek.inc (172.29.193.41) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 20 Nov 2019 00:11:15 -0800 Received: from mtkcas08.mediatek.inc (172.21.101.126) by mtkmbs08n1.mediatek.inc (172.21.101.55) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 20 Nov 2019 16:10:34 +0800 Received: from [172.21.84.99] (172.21.84.99) by mtkcas08.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Wed, 20 Nov 2019 16:10:49 +0800 Message-ID: <1574237450.20087.17.camel@mtksdccf07> Subject: Re: [RFC PATCH V3 3/3] platform: mtk-isp: Add Mediatek FD driver From: Jerry-ch Chen To: Tomasz Figa Date: Wed, 20 Nov 2019 16:10:50 +0800 In-Reply-To: <20191025035211.GA67000@chromium.org> References: <20190906101125.3784-1-Jerry-Ch.chen@mediatek.com> <20190906101125.3784-4-Jerry-Ch.chen@mediatek.com> <1571109375.3706.40.camel@mtksdccf07> <20191025035211.GA67000@chromium.org> X-Mailer: Evolution 3.2.3-0ubuntu6 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191120_002104_574123_876462CE X-CRM114-Status: GOOD ( 36.38 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "devicetree@vger.kernel.org" , Sean Cheng =?UTF-8?Q?=28=E9=84=AD=E6=98=87=E5=BC=98=29?= , Frederic Chen =?UTF-8?Q?=28=E9=99=B3=E4=BF=8A=E5=85=83=29?= , Rynn Wu =?UTF-8?Q?=28=E5=90=B3=E8=82=B2=E6=81=A9=29?= , Christie Yu =?UTF-8?Q?=28=E6=B8=B8=E9=9B=85=E6=83=A0=29?= , srv_heupstream , Jungo Lin =?UTF-8?Q?=28=E6=9E=97=E6=98=8E=E4=BF=8A=29?= , Po-Yang Huang =?UTF-8?Q?=28=E9=BB=83=E6=9F=8F=E9=99=BD=29?= , CK Hu =?UTF-8?Q?=28=E8=83=A1=E4=BF=8A=E5=85=89=29?= , Sj Huang =?UTF-8?Q?=28=E9=BB=83=E4=BF=A1=E7=92=8B=29?= , "yuzhao@chromium.org" , "lkml@metux.net" , "zwisler@chromium.org" , "hans.verkuil@cisco.com" , "matthias.bgg@gmail.com" , "linux-mediatek@lists.infradead.org" , "mchehab@kernel.org" , "laurent.pinchart+renesas@ideasonboard.com" , "linux-arm-kernel@lists.infradead.org" , "linux-media@vger.kernel.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org Hi Tomasz, On Fri, 2019-10-25 at 11:52 +0800, Tomasz Figa wrote: > On Tue, Oct 15, 2019 at 11:16:15AM +0800, Jerry-ch Chen wrote: > > Hi Tomasz, > > > > On Fri, 2019-09-06 at 18:11 +0800, Jerry-ch Chen wrote: > > > From: Jerry-ch Chen > > > > > > This patch adds the driver of Face Detection (FD) unit in > > > Mediatek camera system, providing face detection function. > > > > > > The mtk-isp directory will contain drivers for multiple IP > > > blocks found in Mediatek ISP system. It will include ISP Pass 1 > > > driver (CAM), sensor interface driver, DIP driver and face > > > detection driver. > > > > > > Signed-off-by: Jerry-ch Chen > > > --- > > > drivers/media/platform/Kconfig | 2 + > > > drivers/media/platform/Makefile | 2 + > > > drivers/media/platform/mtk-isp/fd/Kconfig | 19 + > > > drivers/media/platform/mtk-isp/fd/Makefile | 5 + > > > drivers/media/platform/mtk-isp/fd/mtk_fd.h | 148 ++ > > > drivers/media/platform/mtk-isp/fd/mtk_fd_40.c | 1219 +++++++++++++++++ > > > include/uapi/linux/mtk-fd-v4l2-controls.h | 69 + > > > include/uapi/linux/v4l2-controls.h | 4 + > > > 8 files changed, 1468 insertions(+) > > > create mode 100644 drivers/media/platform/mtk-isp/fd/Kconfig > > > create mode 100644 drivers/media/platform/mtk-isp/fd/Makefile > > > create mode 100644 drivers/media/platform/mtk-isp/fd/mtk_fd.h > > > create mode 100644 drivers/media/platform/mtk-isp/fd/mtk_fd_40.c > > > create mode 100644 include/uapi/linux/mtk-fd-v4l2-controls.h > > > > > [snip] > > > > +static int mtk_fd_job_abort(struct mtk_fd_dev *fd) > > > +{ > > > + u32 ret; > > > + > > > + ret = wait_for_completion_timeout(&fd->fd_irq_done, > > > + msecs_to_jiffies(MTK_FD_HW_TIMEOUT)); > > > + /* Reset FD HW */ > > > + if (!ret) { > > > + struct ipi_message fd_ipi_msg; > > > + > > > + fd_ipi_msg.cmd_id = MTK_FD_IPI_CMD_RESET; > > > + if (scp_ipi_send(fd->scp_pdev, SCP_IPI_FD_CMD, &fd_ipi_msg, > > > + sizeof(fd_ipi_msg), MTK_FD_IPI_SEND_TIMEOUT)) > > > + dev_err(fd->dev, "FD Reset HW error\n"); > > > + return -ETIMEDOUT; > > > + } > > > + return 0; > > > +} > > > + > > > > Continue the discussion about job abort in RFC v2, > > > > I think the job_abort callback in v4l2_m2m_ops() might be useful. > > > > ref: > > https://elixir.bootlin.com/linux/v5.4-rc2/source/drivers/media/v4l2-core/v4l2-mem2mem.c#L398 > > https://elixir.bootlin.com/linux/v5.4-rc2/source/include/media/v4l2-mem2mem.h#L43 > > > > in drivers/media/v4l2-core/v4l2-mem2mem.c #398 v4l2_m2m_cancel_job() > > ... > > if (m2m_ctx->job_flags & TRANS_RUNNING) { > > spin_unlock_irqrestore(&m2m_dev->job_spinlock, flags); > > if (m2m_dev->m2m_ops->job_abort) > > m2m_dev->m2m_ops->job_abort(m2m_ctx->priv); > > dprintk("m2m_ctx %p running, will wait to complete\n", m2m_ctx); > > wait_event(m2m_ctx->finished, > > !(m2m_ctx->job_flags & TRANS_RUNNING)); > > } ... > > > > If this operation is set, we might use the v4l2_m2m_cancel_job() when > > suspend, and it will do mtk_fd_job_abort() here. > > > > The expectation for .job_abort() is that signals the hardware to > instantly abandon the current job. Do we have a way to tell the > firmware/hardware to do so? > > Also, suspend must not abort the current job. Anything that was already > running is expected to complete successfuly and further jobs should > continue executing once the system resumes. > I appreciate your comments and Pi-Hsun's patch, Ok, I see. For FD40, we can't tell the firmware/hardware to instantly abandon the current job. Therefore, for suspend, we stop sending further jobs to hardware and wait for the completion of the running job. For resume, we continue sending jobs to hardware. > [snip] > > > > + > > > +static int mtk_fd_suspend(struct device *dev) > > > +{ > > > + struct mtk_fd_dev *fd = dev_get_drvdata(dev); > > > + > > > + if (pm_runtime_suspended(dev)) > > > + return 0; > > > + > > > + if (fd->fd_stream_count) > > > + if (mtk_fd_job_abort(fd)) > > > + mtk_fd_hw_job_finish(fd, VB2_BUF_STATE_ERROR); > > > + > > > > To avoid mtk_fd_hw_job_finish() trigger the next job, > > I suppose that we could use v4l2_m2m_cancel_job instead of job_abort and > > job_finish here. > > > > /** > > * v4l2_m2m_cancel_job() - cancel pending jobs for the context > > * @m2m_ctx: m2m context with jobs to be canceled > > * > > * In case of streamoff or release called on any context, > > * 1] If the context is currently running, then abort job will be called > > * 2] If the context is queued, then the context will be removed from > > * the job_queue > > */ > > > > or another way, > > we may add a flag and implement mtk_fd_job_ready() that reads the flag > > if we suspend, we set the flag and do job_abort and job_finish, even if > > it try enqueue, it will still not really queue the job, until we reset > > the flag in mtk_fd_resume(). > > > > how do you think? > > > > As per my comment above, suspend must just pause the execution of the > jobs. It must not cause any jobs to be skipped. > > After analyzing the m2m framework and existing m2m drivers I realized > that they currently provide no way to correctly handle suspend/resume. > Pi-Hsun has been looking into fixing this in crrev.com/c/1878112 and > we'll send it upstream as soon as we get something that should handle > all the cases correctly. > Ok, thanks for the patches. > > > + /* suspend FD HW */ > > > + writel(0x0, fd->fd_base + MTK_FD_REG_OFFSET_INT_EN); > > > + writel(0x0, fd->fd_base + MTK_FD_REG_OFFSET_HW_ENABLE); > > > + clk_disable_unprepare(fd->fd_clk); > > > + dev_dbg(dev, "%s:disable clock\n", __func__); > > > + > > > + return 0; > > > +} > > > + > > > +static int mtk_fd_resume(struct device *dev) > > > +{ > > > + struct mtk_fd_dev *fd = dev_get_drvdata(dev); > > > + int ret; > > > + > > > + if (pm_runtime_suspended(dev)) > > > + return 0; > > > + > > > + ret = clk_prepare_enable(fd->fd_clk); > > > + if (ret < 0) { > > > + dev_dbg(dev, "Failed to open fd clk:%d\n", ret); > > > + return ret; > > > + } > > > + > > > + /* resume FD HW */ > > > + writel(MTK_FD_SET_HW_ENABLE, fd->fd_base + MTK_FD_REG_OFFSET_HW_ENABLE); > > > + writel(0x1, fd->fd_base + MTK_FD_REG_OFFSET_INT_EN); > > > + dev_dbg(dev, "%s:enable clock\n", __func__); > > By the way, we need to kick the m2m framework here to schedule further > jobs. Pi-Hsun's patch will also take care of this. > Ok, I see. I would like to use Pi-Hsun's patch, otherwise I would need to call v4l2_m2m_try_run() here. > [snip] > > > > +/* Set the face angle and directions to be detected */ > > > +#define V4L2_CID_MTK_FD_DETECT_POSE (V4L2_CID_USER_MTK_FD_BASE + 1) > > > + > > > +/* Set image widths for an input image to be scaled down for face detection */ > > > +#define V4L2_CID_MTK_FD_SCALE_DOWN_IMG_WIDTH (V4L2_CID_USER_MTK_FD_BASE + 2) > > > + > > > +/* Set image heights for an input image to be scaled down for face detection */ > > > +#define V4L2_CID_MTK_FD_SCALE_DOWN_IMG_HEIGHT (V4L2_CID_USER_MTK_FD_BASE + 3) > > > + > > > +/* Set the length of scale down size array */ > > > +#define V4L2_CID_MTK_FD_SCALE_IMG_NUM (V4L2_CID_USER_MTK_FD_BASE + 4) > > > + > > > +/* Set the detection speed, usually reducing accuracy. */ > > > +#define V4L2_CID_MTK_FD_DETECT_SPEED (V4L2_CID_USER_MTK_FD_BASE + 5) > > > + > > > +/* Select the detection model or algorithm to be used. */ > > > +#define V4L2_CID_MTK_FD_DETECTION_MODEL (V4L2_CID_USER_MTK_FD_BASE + 6) > > > + > > > +/* We reserve 16 controls for this driver. */ > > > +#define V4L2_CID_MTK_FD_MAX 16 > > > + > > > > For these control IDs, I think the following should be remained as chip > > specific controls. > > V4L2_CID_MTK_FD_SCALE_DOWN_IMG_WIDTH, > > V4L2_CID_MTK_FD_SCALE_DOWN_IMG_HEIGHT and V4L2_CID_MTK_FD_SCALE_IMG_NUM > > > > Hope there would be standardizing face detection api that cover the rest > > controls: V4L2_CID_MTK_FD_DETECT_POSE, V4L2_CID_MTK_FD_DETECT_SPEED and > > V4L2_CID_MTK_FD_DETECTION_MODEL > > > > Would you have any suggestions on how to propose the standard face > > detection apis? > > > > Given no follow up feedback from the community, I think we can keep them > as driver-specific, but should make sure that they have some reasonable > default values in case an application doesn't recognize them. > > Best regards, > Tomasz > Should I keep the file "mtk-fd-v4l2-controls.h" which defines the control ids under the folder "/include/uapi/linux"? Thanks and Best regards, Jerry _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_2 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CBEDBC432C0 for ; Wed, 20 Nov 2019 08:21:10 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 923002231D for ; Wed, 20 Nov 2019 08:21:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="jrvL3Hv/"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="dBCv593J" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 923002231D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=WHUhHfuwFsRlBr+JZGrDMFFOlkRvnv3A3wvddg2KtAQ=; b=jrvL3Hv/4keLZR IV33UFCiLzmYG+SzMGSFag1LqPOuNTIuK5VXuhBk7mOHXsPWXXRpoGgCLjRDsVT67pHU81O/vc1uH nOiuzIEdPkt6nYZRc7ny4/Y+Sc7krLcM/IjnMIjNGRIbmxKBVPxokoV6Ca6J38iAenZ3lfM8X8Ybs ron3IbvWUe4XMXbpL/W43His2yTV7twcwsPkn1wpDPuhAaN4u366xr/jxFP3umuT0QjbtHiR9qgu1 mIKzGzaDLNPo/T6gKIPzDEb4rRITAlp7GMS8/4jDsNDuoqHIKHi3/w7D+WpGEuXzByu0DgCUFGJfF U9kq19guD8wDzlc+P3vA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iXLEb-0008AX-An; Wed, 20 Nov 2019 08:21:09 +0000 Received: from mailgw02.mediatek.com ([216.200.240.185]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1iXLEW-00089h-Gn; Wed, 20 Nov 2019 08:21:06 +0000 X-UUID: a0a99c6b69b84e028239cfce7db7ddf1-20191120 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References:In-Reply-To:Date:CC:To:From:Subject:Message-ID; bh=Vm5saM+GW0YUbJUNwRCvnRKSP+TQW5BbAxj4dw2J4dY=; b=dBCv593JHT5q6x8wGg9cEEFnlPEW6vdoHgV08dotVzQ4nd+dGQhbKXq+bh8LRvcCUmRmT1iRwwumlbL6OWAGyjks5pxOdQlLuqvUzTyi4NmFlxelzYE7pKulu7SfnxtJdI7H1H86ze4OY/C5IANY+796kSPemvTdflQ7lVW0nX4=; X-UUID: a0a99c6b69b84e028239cfce7db7ddf1-20191120 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw02.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLS) with ESMTP id 1633443104; Wed, 20 Nov 2019 00:21:01 -0800 Received: from mtkmbs08n1.mediatek.inc (172.21.101.55) by MTKMBS62N1.mediatek.inc (172.29.193.41) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 20 Nov 2019 00:11:15 -0800 Received: from mtkcas08.mediatek.inc (172.21.101.126) by mtkmbs08n1.mediatek.inc (172.21.101.55) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 20 Nov 2019 16:10:34 +0800 Received: from [172.21.84.99] (172.21.84.99) by mtkcas08.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Wed, 20 Nov 2019 16:10:49 +0800 Message-ID: <1574237450.20087.17.camel@mtksdccf07> Subject: Re: [RFC PATCH V3 3/3] platform: mtk-isp: Add Mediatek FD driver From: Jerry-ch Chen To: Tomasz Figa Date: Wed, 20 Nov 2019 16:10:50 +0800 In-Reply-To: <20191025035211.GA67000@chromium.org> References: <20190906101125.3784-1-Jerry-Ch.chen@mediatek.com> <20190906101125.3784-4-Jerry-Ch.chen@mediatek.com> <1571109375.3706.40.camel@mtksdccf07> <20191025035211.GA67000@chromium.org> X-Mailer: Evolution 3.2.3-0ubuntu6 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191120_002104_574123_876462CE X-CRM114-Status: GOOD ( 36.38 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "devicetree@vger.kernel.org" , Sean Cheng =?UTF-8?Q?=28=E9=84=AD=E6=98=87=E5=BC=98=29?= , Frederic Chen =?UTF-8?Q?=28=E9=99=B3=E4=BF=8A=E5=85=83=29?= , Rynn Wu =?UTF-8?Q?=28=E5=90=B3=E8=82=B2=E6=81=A9=29?= , Christie Yu =?UTF-8?Q?=28=E6=B8=B8=E9=9B=85=E6=83=A0=29?= , srv_heupstream , Jungo Lin =?UTF-8?Q?=28=E6=9E=97=E6=98=8E=E4=BF=8A=29?= , Po-Yang Huang =?UTF-8?Q?=28=E9=BB=83=E6=9F=8F=E9=99=BD=29?= , CK Hu =?UTF-8?Q?=28=E8=83=A1=E4=BF=8A=E5=85=89=29?= , Sj Huang =?UTF-8?Q?=28=E9=BB=83=E4=BF=A1=E7=92=8B=29?= , "yuzhao@chromium.org" , "lkml@metux.net" , "zwisler@chromium.org" , "hans.verkuil@cisco.com" , "matthias.bgg@gmail.com" , "linux-mediatek@lists.infradead.org" , "mchehab@kernel.org" , "laurent.pinchart+renesas@ideasonboard.com" , "linux-arm-kernel@lists.infradead.org" , "linux-media@vger.kernel.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Tomasz, On Fri, 2019-10-25 at 11:52 +0800, Tomasz Figa wrote: > On Tue, Oct 15, 2019 at 11:16:15AM +0800, Jerry-ch Chen wrote: > > Hi Tomasz, > > > > On Fri, 2019-09-06 at 18:11 +0800, Jerry-ch Chen wrote: > > > From: Jerry-ch Chen > > > > > > This patch adds the driver of Face Detection (FD) unit in > > > Mediatek camera system, providing face detection function. > > > > > > The mtk-isp directory will contain drivers for multiple IP > > > blocks found in Mediatek ISP system. It will include ISP Pass 1 > > > driver (CAM), sensor interface driver, DIP driver and face > > > detection driver. > > > > > > Signed-off-by: Jerry-ch Chen > > > --- > > > drivers/media/platform/Kconfig | 2 + > > > drivers/media/platform/Makefile | 2 + > > > drivers/media/platform/mtk-isp/fd/Kconfig | 19 + > > > drivers/media/platform/mtk-isp/fd/Makefile | 5 + > > > drivers/media/platform/mtk-isp/fd/mtk_fd.h | 148 ++ > > > drivers/media/platform/mtk-isp/fd/mtk_fd_40.c | 1219 +++++++++++++++++ > > > include/uapi/linux/mtk-fd-v4l2-controls.h | 69 + > > > include/uapi/linux/v4l2-controls.h | 4 + > > > 8 files changed, 1468 insertions(+) > > > create mode 100644 drivers/media/platform/mtk-isp/fd/Kconfig > > > create mode 100644 drivers/media/platform/mtk-isp/fd/Makefile > > > create mode 100644 drivers/media/platform/mtk-isp/fd/mtk_fd.h > > > create mode 100644 drivers/media/platform/mtk-isp/fd/mtk_fd_40.c > > > create mode 100644 include/uapi/linux/mtk-fd-v4l2-controls.h > > > > > [snip] > > > > +static int mtk_fd_job_abort(struct mtk_fd_dev *fd) > > > +{ > > > + u32 ret; > > > + > > > + ret = wait_for_completion_timeout(&fd->fd_irq_done, > > > + msecs_to_jiffies(MTK_FD_HW_TIMEOUT)); > > > + /* Reset FD HW */ > > > + if (!ret) { > > > + struct ipi_message fd_ipi_msg; > > > + > > > + fd_ipi_msg.cmd_id = MTK_FD_IPI_CMD_RESET; > > > + if (scp_ipi_send(fd->scp_pdev, SCP_IPI_FD_CMD, &fd_ipi_msg, > > > + sizeof(fd_ipi_msg), MTK_FD_IPI_SEND_TIMEOUT)) > > > + dev_err(fd->dev, "FD Reset HW error\n"); > > > + return -ETIMEDOUT; > > > + } > > > + return 0; > > > +} > > > + > > > > Continue the discussion about job abort in RFC v2, > > > > I think the job_abort callback in v4l2_m2m_ops() might be useful. > > > > ref: > > https://elixir.bootlin.com/linux/v5.4-rc2/source/drivers/media/v4l2-core/v4l2-mem2mem.c#L398 > > https://elixir.bootlin.com/linux/v5.4-rc2/source/include/media/v4l2-mem2mem.h#L43 > > > > in drivers/media/v4l2-core/v4l2-mem2mem.c #398 v4l2_m2m_cancel_job() > > ... > > if (m2m_ctx->job_flags & TRANS_RUNNING) { > > spin_unlock_irqrestore(&m2m_dev->job_spinlock, flags); > > if (m2m_dev->m2m_ops->job_abort) > > m2m_dev->m2m_ops->job_abort(m2m_ctx->priv); > > dprintk("m2m_ctx %p running, will wait to complete\n", m2m_ctx); > > wait_event(m2m_ctx->finished, > > !(m2m_ctx->job_flags & TRANS_RUNNING)); > > } ... > > > > If this operation is set, we might use the v4l2_m2m_cancel_job() when > > suspend, and it will do mtk_fd_job_abort() here. > > > > The expectation for .job_abort() is that signals the hardware to > instantly abandon the current job. Do we have a way to tell the > firmware/hardware to do so? > > Also, suspend must not abort the current job. Anything that was already > running is expected to complete successfuly and further jobs should > continue executing once the system resumes. > I appreciate your comments and Pi-Hsun's patch, Ok, I see. For FD40, we can't tell the firmware/hardware to instantly abandon the current job. Therefore, for suspend, we stop sending further jobs to hardware and wait for the completion of the running job. For resume, we continue sending jobs to hardware. > [snip] > > > > + > > > +static int mtk_fd_suspend(struct device *dev) > > > +{ > > > + struct mtk_fd_dev *fd = dev_get_drvdata(dev); > > > + > > > + if (pm_runtime_suspended(dev)) > > > + return 0; > > > + > > > + if (fd->fd_stream_count) > > > + if (mtk_fd_job_abort(fd)) > > > + mtk_fd_hw_job_finish(fd, VB2_BUF_STATE_ERROR); > > > + > > > > To avoid mtk_fd_hw_job_finish() trigger the next job, > > I suppose that we could use v4l2_m2m_cancel_job instead of job_abort and > > job_finish here. > > > > /** > > * v4l2_m2m_cancel_job() - cancel pending jobs for the context > > * @m2m_ctx: m2m context with jobs to be canceled > > * > > * In case of streamoff or release called on any context, > > * 1] If the context is currently running, then abort job will be called > > * 2] If the context is queued, then the context will be removed from > > * the job_queue > > */ > > > > or another way, > > we may add a flag and implement mtk_fd_job_ready() that reads the flag > > if we suspend, we set the flag and do job_abort and job_finish, even if > > it try enqueue, it will still not really queue the job, until we reset > > the flag in mtk_fd_resume(). > > > > how do you think? > > > > As per my comment above, suspend must just pause the execution of the > jobs. It must not cause any jobs to be skipped. > > After analyzing the m2m framework and existing m2m drivers I realized > that they currently provide no way to correctly handle suspend/resume. > Pi-Hsun has been looking into fixing this in crrev.com/c/1878112 and > we'll send it upstream as soon as we get something that should handle > all the cases correctly. > Ok, thanks for the patches. > > > + /* suspend FD HW */ > > > + writel(0x0, fd->fd_base + MTK_FD_REG_OFFSET_INT_EN); > > > + writel(0x0, fd->fd_base + MTK_FD_REG_OFFSET_HW_ENABLE); > > > + clk_disable_unprepare(fd->fd_clk); > > > + dev_dbg(dev, "%s:disable clock\n", __func__); > > > + > > > + return 0; > > > +} > > > + > > > +static int mtk_fd_resume(struct device *dev) > > > +{ > > > + struct mtk_fd_dev *fd = dev_get_drvdata(dev); > > > + int ret; > > > + > > > + if (pm_runtime_suspended(dev)) > > > + return 0; > > > + > > > + ret = clk_prepare_enable(fd->fd_clk); > > > + if (ret < 0) { > > > + dev_dbg(dev, "Failed to open fd clk:%d\n", ret); > > > + return ret; > > > + } > > > + > > > + /* resume FD HW */ > > > + writel(MTK_FD_SET_HW_ENABLE, fd->fd_base + MTK_FD_REG_OFFSET_HW_ENABLE); > > > + writel(0x1, fd->fd_base + MTK_FD_REG_OFFSET_INT_EN); > > > + dev_dbg(dev, "%s:enable clock\n", __func__); > > By the way, we need to kick the m2m framework here to schedule further > jobs. Pi-Hsun's patch will also take care of this. > Ok, I see. I would like to use Pi-Hsun's patch, otherwise I would need to call v4l2_m2m_try_run() here. > [snip] > > > > +/* Set the face angle and directions to be detected */ > > > +#define V4L2_CID_MTK_FD_DETECT_POSE (V4L2_CID_USER_MTK_FD_BASE + 1) > > > + > > > +/* Set image widths for an input image to be scaled down for face detection */ > > > +#define V4L2_CID_MTK_FD_SCALE_DOWN_IMG_WIDTH (V4L2_CID_USER_MTK_FD_BASE + 2) > > > + > > > +/* Set image heights for an input image to be scaled down for face detection */ > > > +#define V4L2_CID_MTK_FD_SCALE_DOWN_IMG_HEIGHT (V4L2_CID_USER_MTK_FD_BASE + 3) > > > + > > > +/* Set the length of scale down size array */ > > > +#define V4L2_CID_MTK_FD_SCALE_IMG_NUM (V4L2_CID_USER_MTK_FD_BASE + 4) > > > + > > > +/* Set the detection speed, usually reducing accuracy. */ > > > +#define V4L2_CID_MTK_FD_DETECT_SPEED (V4L2_CID_USER_MTK_FD_BASE + 5) > > > + > > > +/* Select the detection model or algorithm to be used. */ > > > +#define V4L2_CID_MTK_FD_DETECTION_MODEL (V4L2_CID_USER_MTK_FD_BASE + 6) > > > + > > > +/* We reserve 16 controls for this driver. */ > > > +#define V4L2_CID_MTK_FD_MAX 16 > > > + > > > > For these control IDs, I think the following should be remained as chip > > specific controls. > > V4L2_CID_MTK_FD_SCALE_DOWN_IMG_WIDTH, > > V4L2_CID_MTK_FD_SCALE_DOWN_IMG_HEIGHT and V4L2_CID_MTK_FD_SCALE_IMG_NUM > > > > Hope there would be standardizing face detection api that cover the rest > > controls: V4L2_CID_MTK_FD_DETECT_POSE, V4L2_CID_MTK_FD_DETECT_SPEED and > > V4L2_CID_MTK_FD_DETECTION_MODEL > > > > Would you have any suggestions on how to propose the standard face > > detection apis? > > > > Given no follow up feedback from the community, I think we can keep them > as driver-specific, but should make sure that they have some reasonable > default values in case an application doesn't recognize them. > > Best regards, > Tomasz > Should I keep the file "mtk-fd-v4l2-controls.h" which defines the control ids under the folder "/include/uapi/linux"? Thanks and Best regards, Jerry _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel