Received: by 10.223.185.111 with SMTP id b44csp340939wrg; Fri, 9 Mar 2018 05:59:31 -0800 (PST) X-Google-Smtp-Source: AG47ELuzR1KfcQs6de0CnKZUxqK5Wanb9Vh+3nPcZx50fmeXRSoG7uP93oUOz3wEiZgvxUm45k5l X-Received: by 10.98.200.80 with SMTP id z77mr29615628pff.85.1520603971805; Fri, 09 Mar 2018 05:59:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520603971; cv=none; d=google.com; s=arc-20160816; b=LXbO34ZCV8CyBYwh3nOYTgb2Gn3iUyQ6JiwjS6Dbd7nTVAplOp9O6yyBRfYUlwhIJb tW4lk+YWVML5wEAJfaE9/po25rJIFy7XHaB6sIgLBWk62RiPtYINV+A4SjEjnU8UJARl CWkaMjuYalN4OQF2jg6v10W7Psoy49MtJfvykj16IXoY26XFlt65B5oqH1wI9ZfmIxOe +PMgXTiFYRj4Z+7sGJxwFSP1cqE+uzwNFtPComAuxMVJIn7ejaeLiLz+Xm3bZBlzUKap gK9lmOeUFQ3b5zW1GqZIyGZ10Chn51B0C4fzqekJd8PfY0ZSCdLtCuNTQM5pbqH4axvc f0Hw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=32K6gpMutNdnyEduqbKBfdtRZcaJfmOZP5vP3etLrtE=; b=1I2BK+1EsDZApRd9Gr7bvX4hlNYczrCo66EbaNWn766Di0ETB0L8qrYMJOwh80u3P4 TwHES8YCi7hEGx2A3MDrIS3EfeGAF7rzzrOASLffAJb4fS3pKWih8tGbInOPUF3VSj0S thNzQr5H+XJ9nwJvYj3wAZm1xbZS5Qn2FRExZGQluNMFuS4q4ldXeneMQ8e9AWLV57tA nwpPbpNM90nWmpOXfC3lKg4gwADuoey43msPhWOhZGeG35SqfPIzGp71mZ+G+SxtGGth L3H+9iZR7Ql+4npNwfNy8UDrFyulqW1euz8fcF7RRF5/6ZbuwOICRbYa3Puj/outkm22 q4/g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 3-v6si927036plo.316.2018.03.09.05.59.17; Fri, 09 Mar 2018 05:59:31 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751188AbeCIN5S (ORCPT + 99 others); Fri, 9 Mar 2018 08:57:18 -0500 Received: from mail.bootlin.com ([62.4.15.54]:56368 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751056AbeCIN5Q (ORCPT ); Fri, 9 Mar 2018 08:57:16 -0500 Received: by mail.bootlin.com (Postfix, from userid 110) id 5D0DA20722; Fri, 9 Mar 2018 14:57:13 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.bootlin.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.4.0 Received: from localhost (unknown [185.94.189.190]) by mail.bootlin.com (Postfix) with ESMTPSA id B38F520379; Fri, 9 Mar 2018 14:57:02 +0100 (CET) Date: Fri, 9 Mar 2018 14:57:02 +0100 From: Maxime Ripard To: Paul Kocialkowski Cc: linux-media@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-sunxi@googlegroups.com, Icenowy Zheng , Florent Revest , Alexandre Courbot , Hans Verkuil , Laurent Pinchart , Sakari Ailus , Thomas van Kleef , "Signed-off-by : Bob Ham" , Thomas Petazzoni , Chen-Yu Tsai Subject: Re: [PATCH 5/9] media: platform: Add Sunxi Cedrus decoder driver Message-ID: <20180309135702.pk4webt7xnj7lrza@flea> References: <20180309100933.15922-3-paul.kocialkowski@bootlin.com> <20180309101445.16190-3-paul.kocialkowski@bootlin.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="k4r33uam73c6qikk" Content-Disposition: inline In-Reply-To: <20180309101445.16190-3-paul.kocialkowski@bootlin.com> User-Agent: NeoMutt/20180223 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --k4r33uam73c6qikk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Mar 09, 2018 at 11:14:41AM +0100, Paul Kocialkowski wrote: > +/* > + * mem2mem callbacks > + */ > + > +void job_abort(void *priv) > +{} Is that still needed? > +/* > + * device_run() - prepares and starts processing > + */ > +void device_run(void *priv) > +{ This function (and the one above) should probably made static. Or at least if you can't, they should have a much more specific name in order not to conflict with anything from the core. > + /* > + * The VPU is only able to handle bus addresses so we have to subtract > + * the RAM offset to the physcal addresses > + */ > + in_buf -=3D PHYS_OFFSET; > + out_luma -=3D PHYS_OFFSET; > + out_chroma -=3D PHYS_OFFSET; You should take care of that by putting it in the dma_pfn_offset field of the struct device (at least before we come up with something better). You'll then be able to use the dma_addr_t directly without modifying it. > + vpu->syscon =3D syscon_regmap_lookup_by_phandle(vpu->dev->of_node, > + "syscon"); > + if (IS_ERR(vpu->syscon)) { > + vpu->syscon =3D NULL; > + } else { > + regmap_write_bits(vpu->syscon, SYSCON_SRAM_CTRL_REG0, > + SYSCON_SRAM_C1_MAP_VE, > + SYSCON_SRAM_C1_MAP_VE); > + } This should be using our SRAM controller driver (and API), see Documentation/devicetree/bindings/sram/sunxi-sram.txt include/linux/soc/sunxi/sunxi_sram.h > + ret =3D clk_prepare_enable(vpu->ahb_clk); > + if (ret) { > + dev_err(vpu->dev, "could not enable ahb clock\n"); > + return -EFAULT; > + } > + ret =3D clk_prepare_enable(vpu->mod_clk); > + if (ret) { > + clk_disable_unprepare(vpu->ahb_clk); > + dev_err(vpu->dev, "could not enable mod clock\n"); > + return -EFAULT; > + } > + ret =3D clk_prepare_enable(vpu->ram_clk); > + if (ret) { > + clk_disable_unprepare(vpu->mod_clk); > + clk_disable_unprepare(vpu->ahb_clk); > + dev_err(vpu->dev, "could not enable ram clock\n"); > + return -EFAULT; > + } Ideally, this should be using runtime_pm to manage the device power state, and disable it when not used. > + reset_control_assert(vpu->rstc); > + reset_control_deassert(vpu->rstc); You can use reset_control_reset here > + return 0; > +} > + > +void sunxi_cedrus_hw_remove(struct sunxi_cedrus_dev *vpu) > +{ > + clk_disable_unprepare(vpu->ram_clk); > + clk_disable_unprepare(vpu->mod_clk); > + clk_disable_unprepare(vpu->ahb_clk); The device is not put back into reset here Thanks! Maxime --=20 Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com --k4r33uam73c6qikk Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE0VqZU19dR2zEVaqr0rTAlCFNr3QFAlqikq0ACgkQ0rTAlCFN r3QY/g//d+U9VlBGVJv8nFwjXL9Y7IaUfQYPSWlycsFTAp+aEexL1qKM2oFbZa4q hV6qWtOT8IJOfLN4poDlZ2+IV8XW2z7t5JDBjx0quTgjbwzQFnRRZ4JstvtRBmxX KDVwXnrin1YaACfyZ5Kz4t4IxOwFbnZ1S9MyYB7LRPBDKrvW0iLiMgGFauuKYpOR mvP+3Z5iiW6ThHrkt/2YDT4SQRYDWf9QU/UPY8vMc6uUOVcc9eZGIJVCE7hyQ4Ee nUbDwLgANobZypCjrrQkj7Ti+GTh2W9WDwor6VtAHQ7VGseQYhooL4tnLCRcQFee RW6+cHM7IhCBk59Nii40N6ahJu4AN7s3f1m/jFDJv/Akwhq1NzM9Y0MCcrsAwbmR ux0gEUfC9wvNDBLp0snB1wL+P7y0ucRJ7oOQLmw6vEog6pD55ziR/HRLkqvtF4wW 0zXobRIdMHdyebdMSCgfkobdmpXqO9AhrtAhumCHA0+aN5FPOt29YSmjdnNgMilh 9DFc8IXUf9aEMEf2YcbFWXQuKYOyIFbqF/WHKH22Dy0QM351JocI6qjf25WF7D88 hF1oDJLRHjR/WwvqhpExwDVDucgBKZoEvu52RMzuf9Pvg1mHsQX6XxaymNsW/PQF H257YObf3rAaJV5bSLFitmcH5DwyiYNxh34x8RWA12po5QzdnQg= =lOlZ -----END PGP SIGNATURE----- --k4r33uam73c6qikk--