Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp221126iob; Mon, 2 May 2022 17:38:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw6czUUPRrWcawFeZxQ/lPHfdtd7xpeRvtvsTyXe3M7z/h6g9Zu/cV9l7v4vR6gHknqtoRZ X-Received: by 2002:a65:6aa3:0:b0:3ab:23fb:adae with SMTP id x3-20020a656aa3000000b003ab23fbadaemr11762266pgu.278.1651538281543; Mon, 02 May 2022 17:38:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651538281; cv=none; d=google.com; s=arc-20160816; b=DtRlldBnF30/aWDfmlp9QKIRZYonleF9F4cpI9X9JEX+m9bwEnyEDCTGcHNarfFEoy IOjpVUXKHc1p0IatPwX62DaYm69gV9HWG9vA0V6fnz8Ww33PZb1qz5gap21rbNK+qjkj vpmSXuVoPoOEK/9u9DnwOXqLE9jPPrzTB4FnXenOnwnrmSS/RBhK9x5w6LbLbygYfS9L 2hVsilFi1euweB0JsnMmK6c+pTo79QqGRsdWDmlWWJ7CXk2PyGp7Z8EcSDQJ7VOrSAEJ Jiu8N9BIexrOkxbaE+aQmYgOEhh4N1tyf1O+X9u707ol8Noe/zkRCaWw/t5nnjCSlqTT b+qA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:content-disposition :content-transfer-encoding:mime-version:in-reply-to:references:cc :user-agent:date:subject:to:from:dkim-signature; bh=8E2PpTS7n9xW37sbOCeIa2pfel4R8e9bbsE/XDKa1ac=; b=NAPgh2dUcTNu1Bjl6TbQ5TA0to30y1H2Tg8GUtHuty9+qJL7GPYZuD5RN1ZnAVaeys a3ZCYoQy/c7fkhXLeOZOm87s8Sg1WtCM/LKkODG1dpprlu3qK4htW+fGumw+UfBQxvAY 3cU5ADET4PdSyZ/C7DN4t/I1g/VS9V0/6I+Z4Q8bGXWQfX3Xb0iKo+y3hsa0cxigfv9C +8kr9CGNlO/ZnuYnueG1TmlLCBvz52ACyT7+kEpGliZj0ENo6UxkkoFEXF92aPK/p+/2 U53V7CCBJ+6j1FiKW9+GZ/2Kiwx1huUZSqPTxe+loxFmdcLgWVnx+qmPASyiv3Ovi+SW 7jJQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cmp.felk.cvut.cz header.s=felkmail header.b=ATYNItrS; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=cmp.felk.cvut.cz Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id pv9-20020a17090b3c8900b001bd14e030b0si674500pjb.136.2022.05.02.17.38.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 May 2022 17:38:01 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@cmp.felk.cvut.cz header.s=felkmail header.b=ATYNItrS; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=cmp.felk.cvut.cz Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id BEF9536E04; Mon, 2 May 2022 17:29:37 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238478AbiD2Vf1 (ORCPT + 99 others); Fri, 29 Apr 2022 17:35:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53406 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232254AbiD2VfZ (ORCPT ); Fri, 29 Apr 2022 17:35:25 -0400 Received: from mailgw.felk.cvut.cz (mailgw.felk.cvut.cz [147.32.82.15]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 75A93CD31A; Fri, 29 Apr 2022 14:32:04 -0700 (PDT) Received: from mailgw.felk.cvut.cz (localhost.localdomain [127.0.0.1]) by mailgw.felk.cvut.cz (Proxmox) with ESMTP id C194830B2973; Fri, 29 Apr 2022 23:31:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= cmp.felk.cvut.cz; h=cc:cc:content-transfer-encoding:content-type :content-type:date:from:from:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=felkmail; bh=8E2Pp TS7n9xW37sbOCeIa2pfel4R8e9bbsE/XDKa1ac=; b=ATYNItrSv5swcys+qHwYw uBBkhjSC8WJzE8jBRqNPntvy1YAaqnfaN6nWEYyfhwiNyHRJbVvz9GI06RwiOEC7 evg5CzzWCXfNrizYv2CrMIcnJRgB7igDADqFqnXjhcaSUnBR2How+bGYOdyZKhyg HpWp/etxJ/um6qXP6NfZ2y0ECBFy/RydBRHY89SQvCbs2MxOjMNr4f3aw4ThSgPD J6fgW4hPM40Qkbh3QDNDLT58BCprpMzl4ViZjRYiqY1uGTRot1sW6FH9QrBHDblq k4y0VboDk0DmrU1AeApHQEhMz3sGvIkLcaxSANRdbhHNa3V/6ylXkjPegGqFrkr7 Q== Received: from cmp.felk.cvut.cz (haar.felk.cvut.cz [147.32.84.19]) by mailgw.felk.cvut.cz (Proxmox) with ESMTPS id 01C7030B2942; Fri, 29 Apr 2022 23:31:31 +0200 (CEST) Received: from haar.felk.cvut.cz (localhost [127.0.0.1]) by cmp.felk.cvut.cz (8.14.0/8.12.3/SuSE Linux 0.6) with ESMTP id 23TLVUGH005586; Fri, 29 Apr 2022 23:31:30 +0200 Received: (from pisa@localhost) by haar.felk.cvut.cz (8.14.0/8.13.7/Submit) id 23TLVTna005582; Fri, 29 Apr 2022 23:31:29 +0200 X-Authentication-Warning: haar.felk.cvut.cz: pisa set sender to pisa@cmp.felk.cvut.cz using -f From: Pavel Pisa To: "Marc Kleine-Budde" Subject: Re: [PATCH v1 0/4] can: ctucanfd: clenup acoording to the actual rules and documentation linking Date: Fri, 29 Apr 2022 23:31:28 +0200 User-Agent: KMail/1.9.10 Cc: linux-can@vger.kernel.org, Oliver Hartkopp , Wolfgang Grandegger , David Miller , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Marin Jerabek , Ondrej Ille , Jiri Novak , Jaroslav Beran , Petr Porazil , Pavel Machek , Carsten Emde , Drew Fustini , Matej Vasilevski , Andrew Dennison References: <20220428072239.kfgtu2bfcud6tetc@pengutronix.de> In-Reply-To: <20220428072239.kfgtu2bfcud6tetc@pengutronix.de> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <202204292331.28980.pisa@cmp.felk.cvut.cz> X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Marc, On Thursday 28 of April 2022 09:22:39 Marc Kleine-Budde wrote: > > Jiapeng Chong (2): > > can: ctucanfd: Remove unnecessary print function dev_err() > > can: ctucanfd: Remove unused including > > I had these already applied. > > > Pavel Pisa (2): > > can: ctucanfd: remove PCI module debug parameters and core debug > > statements. > > docs: networking: device drivers: can: add ctucanfd and its author > > e-mail update > > Split into separate patches and applied. Excuse me for late reply and thanks much for split to preferred form. Matej Vasilevski has tested updated linux-can-next testing on Xilinx Zynq 7000 based MZ_APO board and used it with his patches to do proceed next round of testing of Jan Charvat's NuttX TWAI (CAN) driver on ESP32C3. We plan that CTU CAN FD timestamping will be send for RFC/discussion soon. I would like to thank to Andrew Dennison who implemented, tested and shares integration with LiteX and RISC-V https://github.com/litex-hub/linux-on-litex-vexriscv He uses development version of the CTU CAN FD IP core with configurable number of Tx buffers (2 to 8) for which will be required automatic setup logic in the driver. I need to discuss with Ondrej Ille actual state and his plans. But basically ntxbufs in the ctucan_probe_common() has to be assigned from TXTB_INFO TXT_BUFFER_COUNT field. For older core version the TXT_BUFFER_COUNT field bits should be equal to zero so when value is zero, the original version with fixed 4 buffers will be recognized. When value is configurable then for (uncommon) number of buffers which is not power of two, there will be likely a problem with way how buffers queue is implemented txtb_id = priv->txb_head % priv->ntxbufs; ... priv->txb_head++; ... priv->txb_tail++; When I have provided example for this type of queue many years ago I have probably shown example with power of 2 masking, but modulo by arbitrary number does not work with sequence overflow. Which means to add there two "if"s unfortunately if (++priv->txb_tail == 2 * priv->ntxbufs) priv->txb_tail = 0; We need 2 * priv->ntxbufs range to distinguish empty and full queue... But modulo is not nice either so I probably come with some other solution in a longer term. In the long term, I want to implement virtual queues to allow multiqueue to use dynamic Tx priority of up to 8 the buffers... Best wishes, Pavel Pisa phone: +420 603531357 e-mail: pisa@cmp.felk.cvut.cz Department of Control Engineering FEE CVUT Karlovo namesti 13, 121 35, Prague 2 university: http://control.fel.cvut.cz/ personal: http://cmp.felk.cvut.cz/~pisa projects: https://www.openhub.net/accounts/ppisa CAN related:http://canbus.pages.fel.cvut.cz/ Open Technologies Research Education and Exchange Services https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home