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 2EA87C2BD09 for ; Thu, 27 Jun 2024 17:44:24 +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=Vv3RkHj5qVyzhhNw70UviSSMsgyw+mXFjS3DERvERac=; b=zXcdE8ANnR+kfj9X/7rgswJoB4 xwcffqgrbaYx1o95VTxwtShT4PO3UYo/wEjjznHFRMIEIVt8X0COmuTNxQ86O6gl0RSYvuqSSn4+K XiMeliVb+vRPtV+ln7IRsnuEDhsmrVC+uZCoUJtDsQOl2Y0Klb5BifYoGz3Fk4Qsyptf6dS4Rz0ja hY5K54qr4bFuycekJ9Mlb12YxGmNMv81V4hx1m1y/RajT7ecBtUzKepvgVNXr018lXroKWs9iebWs F+eIAFO6XU9npXBBIC3KxQF4PiWVG4w4LW1hD4egtBE3MPcNBgipGzdmx7bMoNBxeW6tmPJ/XZN9M T66+wv+Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sMtAL-0000000BHDy-0GID; Thu, 27 Jun 2024 17:44:13 +0000 Received: from mail-pf1-x42c.google.com ([2607:f8b0:4864:20::42c]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sMtAC-0000000BHAp-3T7e for linux-arm-kernel@lists.infradead.org; Thu, 27 Jun 2024 17:44:06 +0000 Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-706638d392cso490251b3a.1 for ; Thu, 27 Jun 2024 10:44:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=beagleboard-org.20230601.gappssmtp.com; s=20230601; t=1719510244; x=1720115044; darn=lists.infradead.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Vv3RkHj5qVyzhhNw70UviSSMsgyw+mXFjS3DERvERac=; b=cArUDcUDl21iKpmSIEelyjrf769ggkeUSix83stRdHpMDOW2UGKcHrvHKZG4dTRxKG 6FqU6fNQjKM4pN73dQr/0g+UXrYJyP0AaPAQ7U5fSWf3SPybCjD2Fh2rdJPp/hjzxx4I N3ieuwjJbBW2C+KkdFUQRq7VCzKsj0teNzwB99BwVFrC2m9l2ueIEH6vhW9lPyXsf3/5 yQtZK3Pc9XPDjBAmkd8N5y2ZbC7UMkKd08sr2x/0Acyuo0uRrun6AZGvw2u78AnhBOAu /mVBkxw5bCQ2cfJDygkQVFza+JpA/kwSTyvVn3pVlK0XEEBt9FmHOcILLJ4bmKsGtyrK kFLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719510244; x=1720115044; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Vv3RkHj5qVyzhhNw70UviSSMsgyw+mXFjS3DERvERac=; b=E+jGGG4EGr+2I19/tdKsm1dnLwpOFeeYbaxb+wT6TslhHWxmEx8Eoo3nD6rNuCR2DW oE19wJBFqWt3pXZ0BOyoHlCUcdcITp1ybcqxkrPvMMjTO6pn29r2JIJYuDveL46N1J43 3GLv9GDDZ4noi+xRICIrefWI0LbM6XrWzBVmeaeAhwZOvKt6HSc48QI8hrrLO67ZU4+4 GPhHBMGNWw/80p36xwmSgaqfv/Ac4GNoqh9Vytp4ddLpD7xvHnJjVWT793P9DQqwvBrc 5lsbk9/XlCxlRhxI+uqBNyHm+dOSvIGW9L1yAjvCnui8fFPAAZjabUNHQni5GoC6Ieru Zr4A== X-Forwarded-Encrypted: i=1; AJvYcCXLwL/9KScoMFDHBejKaJJI5WBAL3S22B8c3eaUu7Z05oRgY6Mmmkz+rQnlTQXFhwjmPDpX0lCLhXUP/CLaDnfRre8qbG1qiN2XF7Xi5oZZ3blJAzw= X-Gm-Message-State: AOJu0YxZkmCVg3xJ5sYiaGtL+DKPWoTo3L0bM/dzQs5AglFG9A6ouZj3 ObeOiJSst5dWZIPI2BgyNssf59KRUa9qbUQo3VENPPgUrXb2IM0O0YfUq1Vz0w== X-Google-Smtp-Source: AGHT+IFWsmGs19cCV3TdLReK8RcFiPpPZrw4wi58uIgJm5x5o0oe1yH8EQjLmPECs5E+1GtaCvH4KQ== X-Received: by 2002:a17:902:e888:b0:1f8:6e3f:9e7 with SMTP id d9443c01a7336-1fa09d94a65mr172005795ad.1.1719510243687; Thu, 27 Jun 2024 10:44:03 -0700 (PDT) Received: from ?IPV6:2401:4900:1f3e:18b0:f314:9f76:9f94:eb43? ([2401:4900:1f3e:18b0:f314:9f76:9f94:eb43]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1fac1535cc8sm191425ad.122.2024.06.27.10.43.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 27 Jun 2024 10:44:03 -0700 (PDT) Message-ID: <583334ad-2f87-479c-a4c6-bd4da11bae31@beagleboard.org> Date: Thu, 27 Jun 2024 23:13:54 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 7/7] dts: ti: k3-am625-beagleplay: Add mikroBUS Content-Language: en-US To: Michael Walle , Andrew Davis , Mark Brown , Vaishnav M A , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Derek Kiernan , Dragan Cvetic , Arnd Bergmann , Greg Kroah-Hartman , Nishanth Menon , Vignesh Raghavendra , Tero Kristo , Andrew Lunn , jkridner@beagleboard.org, robertcnelson@beagleboard.org Cc: linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org References: <20240627-mikrobus-scratch-spi-v5-0-9e6c148bf5f0@beagleboard.org> <20240627-mikrobus-scratch-spi-v5-7-9e6c148bf5f0@beagleboard.org> <4e23ec81-b278-4f2b-815d-64ed9390ca55@ti.com> From: Ayush Singh In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240627_104404_890840_D6217266 X-CRM114-Status: GOOD ( 27.06 ) 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 6/27/24 22:51, Michael Walle wrote: > On Thu Jun 27, 2024 at 7:07 PM CEST, Andrew Davis wrote: >>> + mikrobus_boards { >>> + thermo_click: thermo-click { >>> + compatible = "maxim,max31855k", "mikrobus-spi"; >> I might be missing something, but your solution cannot possibly be >> to list every click board that could be connected (all 1500+ of them) >> to every mikroBUS connector on every device's DT file.. >> >> Each click board should have a single DTSO overlay file to describe the >> click board, one per click board total. And then that overlay should >> apply cleanly to any device that has a mikroBUS interface. >> >> Which means you have not completely solved the fundamental problem of >> abstracting the mikroBUS connector in DT. Each of these click device child >> nodes has to be under the parent connector node. Which means a phandle >> to the parent node, which is not generically named. For instance >> if my board has 2 connectors, I would have mikrobus0 and mikrobus1, >> the click board's overlay would look like this: >> >> /dts-v1/; >> /plugin/; >> >> &mikrobus0 { >> status = "okay"; >> >> mikrobus_board { >> thermo-click { >> compatible = "maxim,max31855k", "mikrobus-spi"; >> spi-max-frequency = <1000000>; >> pinctrl-apply = "spi_default"; >> }; >> }; >> }; > If there should only be one DT overlay per click board, how would > you apply that to to different connectors? See my other two replies for more context: https://lore.kernel.org/linux-arm-kernel/cef08d49-a462-4167-8b9d-bf09e8aac92f@beagleboard.org/ https://lore.kernel.org/linux-arm-kernel/e0f9754e-4d84-4ab4-82a4-34cb12800927@beagleboard.org/ My ideal design is that most mikroBUS board configs will be defined in a `dtsi` file which can be included by any system with mikroBUS support. This file might look as follows: ``` /dts-v1/; /plugin/; / { mikrobus_boards { thermo_click: thermo-click { compatible = "maxim,max31855k", "mikrobus-spi"; spi-max-frequency = <1000000>; pinctrl-apply = "spi_default"; }; lsm6dsl_click: lsm6dsl-click { compatible = "st,lsm6ds3", "mikrobus-spi"; spi-max-frequency = <1000000>; pinctrl-apply = "spi_default"; }; }; }; ``` And the board overlay will look as follows: ``` &conector {     board = <&lsm6dsl_click>; }; ``` I do have an experimental configfs entry that passes the mikroBUS board id(s) and creates and applies the dt changeset to the connector dynamically. > >> I think this solution is almost there, but once you solve the above >> issue, we could just apply the right overlay for our attached click >> board ahead of time and not need the mikroBUS bus driver at all. > The bus driver would still be needed to do the enumeration of the > children, no? And it could make the chip select translations etc. So > you can use the normal bindings of these devices. > > -michael If static dt was the only method to detect the board, then it would be fine. But boards with 1-wire-eeprom can allow for for dynamic detection if the overlay can be system agnostic. To make the dt system agnostic, it should be possible for the board to specify the following information: 1. If a pin is supposed to perform its normal function (UART TX should actually do UART TX), or if it should work as say GPIO (Eg, using RST pin as SPI chipselect). 2. Which pin(s) are the SPI chipselect. 3. If a particular pin needs to be pulled high or low for the board to function, etc. So while most of the normal properties of SPI devices can be reused, there is a need to introduce new properties for additional information. In the previous patches, MikroBUS manifest was being used for this purpose, but for a full dt driver, the device tree needs to be extended to specify these extra properties that are not relevant to the non-mikrobus variant of the device. Ayush Singh