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=-7.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no 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 80662C433E0 for ; Tue, 14 Jul 2020 17:17:46 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 51AFA22574 for ; Tue, 14 Jul 2020 17:17:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="EocvOkNL" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 51AFA22574 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+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=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=C6hqmekFBHmRx9SJNEKwt8EP0g0ZOygeJK7BBiad1uQ=; b=EocvOkNL7wr9WiVlnMc+MCZ9S iD/nyunRUJAMQjTfRA1x0h6Z/5D/l8ZXJmIHYlMt7FEXimGmHV77oPBYtO+UZHoUvH5NESTXvjMhM GbqxgEjzsqnnh4V0J+W6bVlJKRSGBP7w28NHAltu+54913P4sayDZYaduxyA7v0ubfuvv/mjP8od4 5ffcnZDg54zhEjTc5KlqVPC0TR9XZ98UULBfkoSiaBazR8A0aByI7z6gt3o6CMACpWc9NtG0qEOUl zkmoeLudjseq2Dd5hIcIJQ+JJHRP45s/WzNC/CO/lFCwxO71fMaIutjOT3zUahr1HW232XtztlTfb PBGapcwJg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jvOXB-00069I-TC; Tue, 14 Jul 2020 17:16:01 +0000 Received: from mail-io1-f65.google.com ([209.85.166.65]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jvOX9-00068g-7N for linux-arm-kernel@lists.infradead.org; Tue, 14 Jul 2020 17:15:59 +0000 Received: by mail-io1-f65.google.com with SMTP id v6so18115975iob.4 for ; Tue, 14 Jul 2020 10:15:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=anDElTHK8FTg74ug9cz0yo5gvG9pTxsEpYnEOXS2E10=; b=B8Q3HQH77utKrqKRq3sdTGmqMqLVChj4cM4/6rA4YuS6ZU+/mbqZONUm8CqV1nOi9g XkgrbzjHkSmmK0aM2cesPL/x1o7Ib9LaD8bHpo8KgUbwQ/M3GMxXNZh/O3dnv/ImhAQW ebY990bZXanEMccLx3cZxG4QGjl8ALPFlZ6JmI1jFAdlCATGs2jRDb9bGYAhGX0tOFF5 DO/XJHAavenya8DAyYQPadAAVPPHkL3id8lRJgqZAz1QtrL4nrfrTRRAkOqM7qQ+4X9x Um8JmwvqzOtYLU1vTcYpjN5blaPlHzU+NK+c+ijtuoBTSzh6xaAAmQBGl83DaUJK2nAZ 51ag== X-Gm-Message-State: AOAM5330IxPJ4Mjiok+bmo5or4qsFjfup0fHq+ltUJmBcGUcW7qTr2Ug zrL43UVKfOc5lHZCnrDCiA== X-Google-Smtp-Source: ABdhPJxg7GVfzF4j6Shx1sDsnZ5fsOOV6Zz3xfMPgpIhRO2lCTzggqQ1Gg8GirNOzqCU+9eZgyhk6A== X-Received: by 2002:a02:694c:: with SMTP id e73mr7033232jac.17.1594746955212; Tue, 14 Jul 2020 10:15:55 -0700 (PDT) Received: from xps15 ([64.188.179.252]) by smtp.gmail.com with ESMTPSA id m5sm10149810ilg.18.2020.07.14.10.15.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jul 2020 10:15:54 -0700 (PDT) Received: (nullmailer pid 2550226 invoked by uid 1000); Tue, 14 Jul 2020 17:15:53 -0000 Date: Tue, 14 Jul 2020 11:15:53 -0600 From: Rob Herring To: Suman Anna Subject: Re: [PATCH v2 1/4] dt-bindings: remoteproc: Add bindings for R5F subsystem on TI K3 SoCs Message-ID: <20200714171553.GA2522956@bogus> References: <20200630024922.32491-1-s-anna@ti.com> <20200630024922.32491-2-s-anna@ti.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200630024922.32491-2-s-anna@ti.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200714_131559_295963_31B0173D X-CRM114-Status: GOOD ( 18.21 ) 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, Mathieu Poirier , Lokesh Vutla , linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org, Bjorn Andersson , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Jun 29, 2020 at 09:49:19PM -0500, Suman Anna wrote: > The Texas Instruments K3 family of SoCs have one or more dual-core > Arm Cortex R5F processor subsystems/clusters (R5FSS). The clusters > can be split between multiple voltage domains as well. Add the device > tree bindings document for these R5F subsystem devices. These R5F > processors do not have an MMU, and so require fixed memory carveout > regions matching the firmware image addresses. The nodes require more > than one memory region, with the first memory region used for DMA > allocations at runtime. The remaining memory regions are reserved > and are used for the loading and running of the R5F remote processors. > The R5F processors can also optionally use any internal on-chip SRAM > memories either for executing code or using it as fast-access data. > > The added example illustrates the DT nodes for the single R5FSS device > present on K3 AM65x family of SoCs. > > Signed-off-by: Suman Anna > --- > v2: > - Renamed "lockstep-mode" property to "ti,cluster-mode" I don't think that's a move in the right direction given this is at least partially a standard feature. As I said before, I'm very hesistant to accept anything here given I know the desires and activity to define 'system Devicetrees' of which TI is participating. While maybe an rproc node is sufficient for a DSP, it seems multiple vendors have R cores and want to define them in system DT. Though the system DT effort has not yet given any thought to what is the view of one processor or instance to another instance (which is what this binding is). We'll still need something defined for that, but I'd expect that to be dependent on what is defined for system DT. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel