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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id B0086CF9C6F for ; Mon, 23 Sep 2024 15:31:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=dD7hHYsS283GSbCBplOCkRMwjoDufwPExNMfzIl92yU=; b=UcNCjJbMuqbbQPYtJUHujIkR+Z 3ByBNtLC5dRm6q+6271lmFP9H/D/QOMvsBLJg27/YLqXG6L1NqUfH6DifvqNhvndCX+yde6ieMRhM z5BPtS7FearolCJENr019tpeggoFDq0b9wKGd/G6agjNtYwCg4BOyHB9A2DQwCfAWGkcrMNxnqmtp ZPpf73MlsoQMmtG8+68GgMa0jNszXsaTUnEyhqE8bxvaujvAmJQRm+QtfY5X/dRPSHUWoHNjP00Ks kafg4Vq7VAs+/m78upOEaTat2QowbiNPt+UlafqLvAdYO6wr7kxqRT81ztesNQlXQE9+jfBEHSWz0 0QfdY1ww==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1ssl1k-0000000HVXO-0vXr; Mon, 23 Sep 2024 15:31:04 +0000 Received: from mail-wm1-x32a.google.com ([2a00:1450:4864:20::32a]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1ssl0a-0000000HVLH-0etb for linux-arm-kernel@lists.infradead.org; Mon, 23 Sep 2024 15:29:53 +0000 Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-42cdefe9ae8so6591015e9.1 for ; Mon, 23 Sep 2024 08:29:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1727105390; x=1727710190; darn=lists.infradead.org; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :from:references:cc:to:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=dD7hHYsS283GSbCBplOCkRMwjoDufwPExNMfzIl92yU=; b=D3lWDaO+xher51SjGT0VWLVLEhX28ly7CoZ0KW2VZz8XHAuAds6MdmqEmbYtui7Dxa BTGatGB21q6XFejjWmlcGLwgxPbyzaauzlQ9FA1y7QFNrJpM/CB49qesz/YMxLCzrZE/ XgeOcExTBMsuDj6c/+AJJmI0wtohaWGAKWzj/4DT7S7kF8eIHA2nNXom/xcXXUunc5nM N6OzMM+T7Noy2rjOF6loQa+UoV7YnVJRbLzd+ejY5Ey30/ZBqgo7XMN3E+fsXffTRKJ8 NkKsGB1i6ZkbeIRYm8sUIs+E4C1FSpctWYe4Nc2KU5HSUyWUKtM+b8vfPAjrDoiLL8W0 TUbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727105390; x=1727710190; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :from:references:cc:to:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dD7hHYsS283GSbCBplOCkRMwjoDufwPExNMfzIl92yU=; b=XxiOkACuhLTWcYgsImMikP9217FpPAycnRxu0E0+z27/NWO344xhqAa2rDTMy0zdJ5 0NdDW5pepAAaGjOtt65EyllbxDRolx60BVqVf7VPseGgULTlFwgjRL/sCA5KidnyeqO1 z48XBziUbvmYZHgAOf+MwUKW/cMZLBSj3vr8Pbzp6YN4SGRE0EHoGUOIpxWi9kU+XWS7 fA/CzT6NVuWRVpd6lnYntplUXsmZL3GDUK9yvXBpzHTeSmj8AbRbfZj3VpE52YDJ/To0 tBjOWbuOAiCBTruZryIE0pX21ZnU1sQRmWrV96SYaR3PuoQNqhEN1DFifeogajCasxI8 9ZuA== X-Forwarded-Encrypted: i=1; AJvYcCUtMEcYpQgkw8MYCkD8s7JmRH+ATz6NDKURjTgxfYqk03SjejjK/L3TL2xCWKdQDDAeGYO6e8WpRW914480fkMj@lists.infradead.org X-Gm-Message-State: AOJu0YwanKZP0/nz/aRmz6qj1zKhQFjhQTc46CdYyVIXCuXk8SE1VKfE 4xCw1kU3eM/7EHkX1f3pg4My1x4c3Wq8nDjCXe81D2jUkx5S6jeSbClXAT0giKk= X-Google-Smtp-Source: AGHT+IHeKCUyjohUfTv2OwDb/BfCJQqRrE8zYdgpcY9fKRGlVv5KGJ083aHsTcr2nBQkM9ny6+e7JQ== X-Received: by 2002:a05:600c:1c1e:b0:42c:aeee:d8ed with SMTP id 5b1f17b1804b1-42e7adc7ed0mr34954475e9.7.1727105389915; Mon, 23 Sep 2024 08:29:49 -0700 (PDT) Received: from [192.168.1.20] ([178.197.211.167]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42e7afdda8esm103464185e9.31.2024.09.23.08.29.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Sep 2024 08:29:49 -0700 (PDT) Message-ID: Date: Mon, 23 Sep 2024 17:29:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/5] dt-bindings: remoteproc: sse710: Add the External Systems remote processors To: Abdellatif El Khlifi , Krzysztof Kozlowski Cc: mathieu.poirier@linaro.org, Adam.Johnston@arm.com, Hugues.KambaMpiana@arm.com, Drew.Reed@arm.com, andersson@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org, krzysztof.kozlowski+dt@linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-remoteproc@vger.kernel.org, liviu.dudau@arm.com, lpieralisi@kernel.org, robh@kernel.org, sudeep.holla@arm.com, robin.murphy@arm.com References: <20240822170951.339492-2-abdellatif.elkhlifi@arm.com> <20240919093517.GA43740@e130802.arm.com> <222b3b11-151a-4ad0-91ea-54ae8f280bcb@kernel.org> <20240919145741.GA7940@e130802.arm.com> <85a223e9-05a4-4034-87a5-57d3eb9409b7@kernel.org> <20240920141958.GA288724@e130802.arm.com> <7784248d-4372-4cf1-a01a-5b731b3f6b96@kernel.org> <20240920163851.GA385919@e130802.arm.com> <20240923114945.GA133670@e130802.arm.com> From: Krzysztof Kozlowski Content-Language: en-US Autocrypt: addr=krzysztof.kozlowski@linaro.org; keydata= xsFNBFVDQq4BEAC6KeLOfFsAvFMBsrCrJ2bCalhPv5+KQF2PS2+iwZI8BpRZoV+Bd5kWvN79 cFgcqTTuNHjAvxtUG8pQgGTHAObYs6xeYJtjUH0ZX6ndJ33FJYf5V3yXqqjcZ30FgHzJCFUu JMp7PSyMPzpUXfU12yfcRYVEMQrmplNZssmYhiTeVicuOOypWugZKVLGNm0IweVCaZ/DJDIH gNbpvVwjcKYrx85m9cBVEBUGaQP6AT7qlVCkrf50v8bofSIyVa2xmubbAwwFA1oxoOusjPIE J3iadrwpFvsZjF5uHAKS+7wHLoW9hVzOnLbX6ajk5Hf8Pb1m+VH/E8bPBNNYKkfTtypTDUCj NYcd27tjnXfG+SDs/EXNUAIRefCyvaRG7oRYF3Ec+2RgQDRnmmjCjoQNbFrJvJkFHlPeHaeS BosGY+XWKydnmsfY7SSnjAzLUGAFhLd/XDVpb1Een2XucPpKvt9ORF+48gy12FA5GduRLhQU vK4tU7ojoem/G23PcowM1CwPurC8sAVsQb9KmwTGh7rVz3ks3w/zfGBy3+WmLg++C2Wct6nM Pd8/6CBVjEWqD06/RjI2AnjIq5fSEH/BIfXXfC68nMp9BZoy3So4ZsbOlBmtAPvMYX6U8VwD TNeBxJu5Ex0Izf1NV9CzC3nNaFUYOY8KfN01X5SExAoVTr09ewARAQABzTRLcnp5c3p0b2Yg S296bG93c2tpIDxrcnp5c3p0b2Yua296bG93c2tpQGxpbmFyby5vcmc+wsGUBBMBCgA+FiEE m9B+DgxR+NWWd7dUG5NDfTtBYpsFAmI+BxMCGwMFCRRfreEFCwkIBwIGFQoJCAsCBBYCAwEC HgECF4AACgkQG5NDfTtBYptgbhAAjAGunRoOTduBeC7V6GGOQMYIT5n3OuDSzG1oZyM4kyvO XeodvvYv49/ng473E8ZFhXfrre+c1olbr1A8pnz9vKVQs9JGVa6wwr/6ddH7/yvcaCQnHRPK mnXyP2BViBlyDWQ71UC3N12YCoHE2cVmfrn4JeyK/gHCvcW3hUW4i5rMd5M5WZAeiJj3rvYh v8WMKDJOtZFXxwaYGbvFJNDdvdTHc2x2fGaWwmXMJn2xs1ZyFAeHQvrp49mS6PBQZzcx0XL5 cU9ZjhzOZDn6Apv45/C/lUJvPc3lo/pr5cmlOvPq1AsP6/xRXsEFX/SdvdxJ8w9KtGaxdJuf rpzLQ8Ht+H0lY2On1duYhmro8WglOypHy+TusYrDEry2qDNlc/bApQKtd9uqyDZ+rx8bGxyY qBP6bvsQx5YACI4p8R0J43tSqWwJTP/R5oPRQW2O1Ye1DEcdeyzZfifrQz58aoZrVQq+innR aDwu8qDB5UgmMQ7cjDSeAQABdghq7pqrA4P8lkA7qTG+aw8Z21OoAyZdUNm8NWJoQy8m4nUP gmeeQPRc0vjp5JkYPgTqwf08cluqO6vQuYL2YmwVBIbO7cE7LNGkPDA3RYMu+zPY9UUi/ln5 dcKuEStFZ5eqVyqVoZ9eu3RTCGIXAHe1NcfcMT9HT0DPp3+ieTxFx6RjY3kYTGLOwU0EVUNc NAEQAM2StBhJERQvgPcbCzjokShn0cRA4q2SvCOvOXD+0KapXMRFE+/PZeDyfv4dEKuCqeh0 hihSHlaxTzg3TcqUu54w2xYskG8Fq5tg3gm4kh1Gvh1LijIXX99ABA8eHxOGmLPRIBkXHqJY oHtCvPc6sYKNM9xbp6I4yF56xVLmHGJ61KaWKf5KKWYgA9kfHufbja7qR0c6H79LIsiYqf92 H1HNq1WlQpu/fh4/XAAaV1axHFt/dY/2kU05tLMj8GjeQDz1fHas7augL4argt4e+jum3Nwt yupodQBxncKAUbzwKcDrPqUFmfRbJ7ARw8491xQHZDsP82JRj4cOJX32sBg8nO2N5OsFJOcd 5IE9v6qfllkZDAh1Rb1h6DFYq9dcdPAHl4zOj9EHq99/CpyccOh7SrtWDNFFknCmLpowhct9 5ZnlavBrDbOV0W47gO33WkXMFI4il4y1+Bv89979rVYn8aBohEgET41SpyQz7fMkcaZU+ok/ +HYjC/qfDxT7tjKXqBQEscVODaFicsUkjheOD4BfWEcVUqa+XdUEciwG/SgNyxBZepj41oVq FPSVE+Ni2tNrW/e16b8mgXNngHSnbsr6pAIXZH3qFW+4TKPMGZ2rZ6zITrMip+12jgw4mGjy 5y06JZvA02rZT2k9aa7i9dUUFggaanI09jNGbRA/ABEBAAHCwXwEGAEKACYCGwwWIQSb0H4O DFH41ZZ3t1Qbk0N9O0FimwUCYDzvagUJFF+UtgAKCRAbk0N9O0Fim9JzD/0auoGtUu4mgnna oEEpQEOjgT7l9TVuO3Qa/SeH+E0m55y5Fjpp6ZToc481za3xAcxK/BtIX5Wn1mQ6+szfrJQ6 59y2io437BeuWIRjQniSxHz1kgtFECiV30yHRgOoQlzUea7FgsnuWdstgfWi6LxstswEzxLZ Sj1EqpXYZE4uLjh6dW292sO+j4LEqPYr53hyV4I2LPmptPE9Rb9yCTAbSUlzgjiyyjuXhcwM qf3lzsm02y7Ooq+ERVKiJzlvLd9tSe4jRx6Z6LMXhB21fa5DGs/tHAcUF35hSJrvMJzPT/+u /oVmYDFZkbLlqs2XpWaVCo2jv8+iHxZZ9FL7F6AHFzqEFdqGnJQqmEApiRqH6b4jRBOgJ+cY qc+rJggwMQcJL9F+oDm3wX47nr6jIsEB5ZftdybIzpMZ5V9v45lUwmdnMrSzZVgC4jRGXzsU EViBQt2CopXtHtYfPAO5nAkIvKSNp3jmGxZw4aTc5xoAZBLo0OV+Ezo71pg3AYvq0a3/oGRG KQ06ztUMRrj8eVtpImjsWCd0bDWRaaR4vqhCHvAG9iWXZu4qh3ipie2Y0oSJygcZT7H3UZxq fyYKiqEmRuqsvv6dcbblD8ZLkz1EVZL6djImH5zc5x8qpVxlA0A0i23v5QvN00m6G9NFF0Le D2GYIS41Kv4Isx2dEFh+/Q== In-Reply-To: <20240923114945.GA133670@e130802.arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240923_082952_275413_CC05AFF8 X-CRM114-Status: GOOD ( 44.57 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 23/09/2024 13:49, Abdellatif El Khlifi wrote: > Hi Krzysztof, > >>>>>>>>>>> + '#extsys-id': >>>>>>>>>> >>>>>>>>>> '#' is not correct for sure, that's not a cell specifier. >>>>>>>>>> >>>>>>>>>> But anyway, we do not accept in general instance IDs. >>>>>>>>> >>>>>>>>> I'm happy to replace the instance ID with another solution. >>>>>>>>> In our case the remoteproc instance does not have a base address >>>>>>>>> to use. So, we can't put remoteproc@address >>>>>>>>> >>>>>>>>> What do you recommend in this case please ? >>>>>>>> >>>>>>>> Waiting one month to respond is a great way to drop all context from my >>>>>>>> memory. The emails are not even available for me - gone from inbox. >>>>>>>> >>>>>>>> Bus addressing could note it. Or you have different devices, so >>>>>>>> different compatibles. Tricky to say, because you did not describe the >>>>>>>> hardware really and it's one month later... >>>>>>>> >>>>>>> >>>>>>> Sorry for waiting. I was in holidays. >>>>>>> >>>>>>> I'll add more documentation about the external system for more clarity [1]. >>>>>>> >>>>>>> Basically, Linux runs on the Cortex-A35. The External system is a >>>>>>> Cortex-M core. The Cortex-A35 can not access the memory of the Cortex-M. >>>>>>> It can only control Cortex-M core using the reset control and status registers mapped >>>>>>> in the memory space of the Cortex-A35. >>>>>> >>>>>> That's pretty standard. >>>>>> >>>>>> It does not explain me why bus addressing or different compatible are >>>>>> not sufficient here. >>>>> >>>>> Using an instance ID was a design choice. >>>>> I'm happy to replace it with the use of compatible and match data (WIP). >>>>> >>>>> The match data will be pointing to a data structure containing the right offsets >>>>> to be used with regmap APIs. >>>>> >>>>> syscon node is used to represent the Host Base System Control register area [1] >>>>> where the external system reset registers are mapped (EXT_SYS*). >>>>> >>>>> The nodes will look like this: >>>>> >>>>> syscon@1a010000 { >>>>> compatible = "arm,sse710-host-base-sysctrl", "simple-mfd", "syscon"; >>>>> reg = <0x1a010000 0x1000>; >>>>> >>>>> #address-cells = <1>; >>>>> #size-cells = <1>; >>>>> >>>>> remoteproc@310 { >>>>> compatible = "arm,sse710-extsys0"; >>>>> reg = <0x310 4>; >>>> >>>> Uh, why do you create device nodes for one word? This really suggests it >>>> is part of parent device and your split is artificial. >>> >>> The external system registers (described by the remoteproc node) are part >>> of the parent device (the Host Base System Control register area) described >>> by syscon. >>> >>> In case of the external system 0 , its registers are located at offset 0x310 >>> (physical address: 0x1a010310) >>> >>> When instantiating the devices without @address, the DTC compiler >>> detects 2 nodes with the same name (remoteproc). >> >> There should be no children at all. DT is not for instantiating your >> drivers. I claim you have only one device and that's >> arm,sse710-host-base-sysctrl. If you create child node for one word, >> that's not a device. > > The Host Base System Control [3] is the big block containing various functionalities (MMIO registers). > Among the functionalities, the two remote cores registers (aka External system 0 and 1). > The remote cores have two registers each. > > 1/ In the v1 patchset, a valid point was made by the community: > > Right now it seems somewhat tenuous to describe two consecutive > 32-bit registers as separate "reg" entries, but *maybe* it's OK if that's ARM is not special, neither this hardware is. Therefore: 1. Each register as reg: nope, for obvious reasons. 2. One device for entire syscon: quite common, why do you think it is somehow odd? 3. If you quote other person, please provide the lore link, so I won't spend useless 5 minutes to find who said that or if it was even said... > all there ever is. However if it's actually going to end up needing several > more additional MMIO and/or memory regions for other functionality, then > describing each register and location individually is liable to get > unmanageable really fast, and a higher-level functional grouping (e.g. these > reset-related registers together as a single 8-byte region) would likely be > a better design. > > The Exernal system registers are part of a bigger block with other functionality in place. > MFD/syscon might be better way to use these registers. You never know in > future you might want to use another set of 2-4 registers with a different > functionality in another driver. > > I would see if it makes sense to put together a single binding for > this "Host Base System Control" register (not sure what exactly that means). > Use MFD/regmap you access parts of this block. The remoteproc driver can > then be semi-generic (meaning applicable to group of similar platforms) > based on the platform compatible and use this regmap to provide the > functionality needed. I don't understand how this lengthy semi-quote answers my concerns. Please write concise points as arguments to my questions. For example, I don't care what your remote proc driver does and it should not matter in the terms of this binding. > > 2/ There are many examples in the kernel that use syscon as a parent node of > child nodes for devices located at an offset from the syscon base address. > Please see these two examples [1][2]. I'm trying to follow a similar design if that > makes sense. Yeah, for separate devices. If you have two words without any resources, I claim you might not have here any separate devices or "not separate enough", because all this is somehow fluid. Remote core sounds like separate device, but all your arguments about need of extid which cannot be used in reg does not support this case. The example in the binding is also not complete - missing rest of devices - which does not help. > > 3/ Since there are two registers for each remote core. I'm suggesting to set the > size in the reg property to 8. How is this related? > The driver will read the match data to get the right > offset to be used with regmap APIs. Sorry, no talks about driver. Don't care, at least in this context. You can completely omit address space from children in DT and everything will work fine and look fine from bindings point of view. > > Suggested nodes: > > > syscon@1a010000 { > compatible = "arm,sse710-host-base-sysctrl", "simple-mfd", "syscon"; > reg = <0x1a010000 0x1000>; > > #address-cells = <1>; > #size-cells = <1>; > > remoteproc@310 { > compatible = "arm,sse710-extsys0"; > reg = <0x310 8>; > firmware-name = "es_flashfw.elf"; > mboxes = <&mhu0_hes0 0 1>, <&mhu0_es0h 0 1>; > mbox-names = "txes0", "rxes0"; > memory-region = <&extsys0_vring0>, <&extsys0_vring1>; > }; > > remoteproc@318 { > compatible = "arm,sse710-extsys1"; > reg = <0x318 8>; > firmware-name = "es_flashfw.elf"; Same firmware? Always or only depends? > mboxes = <&mhu0_hes1 0 1>, <&mhu0_es1h 0 1>; > mbox-names = "txes0", "rxes0"; > memory-region = <&extsys1_vring0>, <&extsys1_vring1>; The rest of resources support the idea of two children but I still have doubts about need of identifying remote instances. Looking at your driver it is totally not needed. Your driver just duplicates the regs here, so it's a proof that you are not using DT correctly. > }; > }; > > > [1]: Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml > > syscon@20e00000 { > compatible = "sprd,sc9863a-glbregs", "syscon", "simple-mfd"; > reg = <0x20e00000 0x4000>; > #address-cells = <1>; > #size-cells = <1>; > ranges = <0 0x20e00000 0x4000>; > > apahb_gate: apahb-gate@0 { > compatible = "sprd,sc9863a-apahb-gate"; > reg = <0x0 0x1020>; Well, size 1020, but please never use sprd as an example. You can as well point to a buggy code and say that "I can implement bugs as well, because there are bugs already". Same for few other almost abandoned, poorly maintained platforms. > #clock-cells = <1>; > }; > }; > > > [2]: Documentation/devicetree/bindings/arm/arm,juno-fpga-apb-regs.yaml: > > syscon@10000 { > compatible = "arm,juno-fpga-apb-regs", "syscon", "simple-mfd"; > reg = <0x010000 0x1000>; > ranges = <0x0 0x10000 0x1000>; > #address-cells = <1>; > #size-cells = <1>; > > led@8,0 { > compatible = "register-bit-led"; register-bit-led... what do you want to prove? You will find clocks-per-reg and try to implement them? That's known no-go. Best regards, Krzysztof