Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp428706pxb; Fri, 15 Oct 2021 08:20:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxcVk+pQ/MyUIV4cL9cK+HFL4hGu2sjgN5jA6/WHdhTmw2vQ84oskJz03wlnNaR1YkXhy+G X-Received: by 2002:a63:7010:: with SMTP id l16mr9603353pgc.32.1634311225510; Fri, 15 Oct 2021 08:20:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634311225; cv=none; d=google.com; s=arc-20160816; b=d2nJK9YLihZHEnEDjsPTKVU+JqNuVv+cMHTLsjHl8EfP0I98Ig8vtNuR6KVbdeQBqP /sLNXfcC30jxrCUIKM5aKESG63XeYgkeY96tzov2n6jFOdnTyMjzxokXLtXTJksqwY9s OsR3OOmHRsiyLBUAyAwZU5SCJ00fR/QT9ggF4elvOiMpbp4e6dCwLzGPR6BV/PWpDxem 2JroFIw/f5uQrEEWurVfi6VxqwCvE5q72vZDDJynZtaLS9af12iIQWB2FedJ0MPeUA4n Kj7nePTZaSd3F6bZmfBLeda9e7BxLYN51KbCPFuYT1WMXIkyRaKyJDYkSdu1v7dzCnux +I4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature; bh=UxXz4sft9pDoC7FKPbbdUX+rZ2vTPhxrZcu16q7gW9o=; b=Y27ma0/TnIfU7Luurk94+p30vC1CuZQP8wdshiRG5PnZLGrrULPHT5yyejnKdooBkz 5U4j1/+87A6/eo3uk08r7VRzViqJH17+ZRz+LMTET0Qqz2L9Pw6E4gfr/Hn+lupGDa1P e7sMkOpmvyCEehDwzVfm9Lm4ejlSpWFsFot/DKqpOLMDdv066+XUOAW5YgYZLL1ELiyf /rXtNMC92Z8WApJuHknybUPU1C5YHcikRypvej0RJWxlpl+BbWZfW6UVdL1s4u/DOsAl nJC6xKqKGCnXmrWcHBHmSsATHDAM2QVIv/yEqqqjyeU75aVoRgV6xsUFtnMXpU8zFbVx reJQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=l6xJIVZQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b7si764999pgm.415.2021.10.15.08.20.12; Fri, 15 Oct 2021 08:20:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=l6xJIVZQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236950AbhJOIWe (ORCPT + 99 others); Fri, 15 Oct 2021 04:22:34 -0400 Received: from mail.kernel.org ([198.145.29.99]:46192 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233121AbhJOIV2 (ORCPT ); Fri, 15 Oct 2021 04:21:28 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 6028760249; Fri, 15 Oct 2021 08:19:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1634285959; bh=ZtB79vn0N+nDpFFIfpwm8g6mWwuaDQm7mVlJLNDK7nY=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=l6xJIVZQLzDcy+1R0WUSiieiyp674YTinwCtDARIUvlSRKlLeFA68sOGYLhHIUPFw W/9jgsQTsh1xELW5qOnSpfBDer61gUVrp3Mzazvypls8lIfab1INUyODnezZfshRwZ RkxucAwgtUbUjEEzJekRkQzB+Q8ek2+bOyjt/fmwXkkDugGOFAzpJH1xoVCq8ydund xb2rQD/gpPUl8DQDB+U2v5Y3+ndi3FoE7m8FwTpN7gIAWEdjYmUEucGYR3klRhKXti gw5KYdg3+Icx3SAbJdskGoILaYcCIB2o2CdGXwNv2VX/VMQxPLuNt39FdVcwu4GJ4r 728cxCySUaypA== Message-ID: <747ce6bf4b3511fd13408a52a301f63e37210883.camel@kernel.org> Subject: Re: [PATCH] staging: vchiq_arm: Add 36-bit address support From: nicolas saenz julienne To: Mwesigwa Guma , linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , Stefan Wahren , Ojaswin Mujoo , Dan Carpenter , Amarjargal Gundjalam , Phil Elwell , bcm-kernel-feedback-list@broadcom.com, linux-rpi-kernel@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-staging@lists.linux.dev, fedora-rpi@googlegroups.com, Joel Savitz , Chukpozohn Toe , Clark Williams Date: Fri, 15 Oct 2021 10:19:13 +0200 In-Reply-To: <20211014223230.451659-1-mguma@redhat.com> References: <20211014223230.451659-1-mguma@redhat.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.4 (3.40.4-2.fc34) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Mwesigwa, On Thu, 2021-10-14 at 18:32 -0400, Mwesigwa Guma wrote: > Cc: Nicolas Saenz Julienne > Cc: Greg Kroah-Hartman > Cc: Stefan Wahren > Cc: Ojaswin Mujoo > Cc: Dan Carpenter > Cc: Amarjargal Gundjalam > Cc: Phil Elwell > Cc: bcm-kernel-feedback-list@broadcom.com > Cc: linux-rpi-kernel@lists.infradead.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-staging@lists.linux.dev > Cc: fedora-rpi@googlegroups.com > Cc: Joel Savitz > Cc: Chukpozohn Toe > Cc: Clark Williams > > This is a forward port of Phil Elwell's commit from the Raspberry Pi > Linux fork described as follows [1]: > > Conditional on a new compatible string, change the pagelist encoding > such that the top 24 bits are the pfn, leaving 8 bits for run length > (-1), giving a 36-bit address range. > > Manage the split between addresses for the VPU and addresses for the > 40-bit DMA controller with a dedicated DMA device pointer that on non- > BCM2711 platforms is the same as the main VCHIQ device. This allows > the VCHIQ node to stay in the usual place in the DT. > > This commit enables VCHIQ device access on a Raspberry Pi 4B running the > mainline Linux kernel. > > Tested on Fedora Linux running on a Raspberry Pi 4B. > > [1]: https://github.com/raspberrypi/linux/commit/97268fd23eb8d08dc74eac5e3fd697303de26610 > > Signed-off-by: Mwesigwa Guma I see a lot happening on this patch. You're: - Registering a number of child devices that don't seem to exist upstream ('vcsm-cma', 'bcm2835-codec', and 'bcm2825-isp'). - Updating vchiq_register_child(). - Adding brcm,bcm2711-vchiq's compatible string (no dt bindings? see Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-vchiq.txt). - Looking for 'brcm,bcm2711-dma' in the devicetree. - Using 'brcm,bcm2711-dma's' device node to re-generate the page lists. Each one of these should at least be a separate patch, which proper justification[1]. You can't just take downstream fixes, rebase them and send them upstream. You really have to own them, undestand what's happening and repurpose everything so it's up to standard even if it means diverging from what downstream is doing. Regards, Nicolas [1] Have a look at Documentation/process/submitting-patches.rst.