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 E6332C2BD09 for ; Fri, 28 Jun 2024 18:06:10 +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=h9jhg57fS7Sxej2hwQNHjqF+6s4+CeCZMfG+JMi6knk=; b=Y5CW9QOFlPUdlS6HUkzqmiagAX eyc+vBbnkvPwwjoHHimUAITfRBiNW7t81601Ow8+eK/vNHFQrhk6Z8TyumXJY2DCjzKN6cZAkKNYL 3qN6AamczHs8h+QxPzfrIuh4ZqVmkJBFgPYqI0A46VKU5GHqX4xg+xw+RwoPGmgKB73O2O1tbiWL+ OVFm+sGhcgkzr3Y9Tp6aga82fZtgTux7OMc4bEKk+edHjbwX02PBn+m3g1Ggp4EH8QUbXs3ZSU/UW eefbPLsKXxGfJ8iReIu/9P2641wh18U4wIhAWehWuG7VMmtgk9UOgMGxwex83nK0ygnIDoFofawBw +HaZO92Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sNFyy-0000000EZq7-0auj; Fri, 28 Jun 2024 18:06:00 +0000 Received: from mail-pl1-x62d.google.com ([2607:f8b0:4864:20::62d]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sNFyo-0000000EZp4-3bMn for linux-arm-kernel@lists.infradead.org; Fri, 28 Jun 2024 18:05:52 +0000 Received: by mail-pl1-x62d.google.com with SMTP id d9443c01a7336-1f9c2640730so321895ad.3 for ; Fri, 28 Jun 2024 11:05:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=beagleboard-org.20230601.gappssmtp.com; s=20230601; t=1719597950; x=1720202750; darn=lists.infradead.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=h9jhg57fS7Sxej2hwQNHjqF+6s4+CeCZMfG+JMi6knk=; b=nJFFv0tgz7aFfpahDQXLyCIsj1x37oVApvp7MxnPNfnpOO2luTIK5QoGbAp+mAqOXs E9ah7vbK3otNSpZRne5jw6RRTf/b2L+cM+jgwuy2MpNv6VkXiqTtgsrcnImif8MkyU2d e6hwaRPMn8LvxdybZ8t7w1ts9sblNZf73Ubt2bUGpQl9E4RwgMDl8PoCUnkuwcxrXMoD ELNOZvAdr5Y4sHn4dIlL9dZkzky7rw2OdoKOTGC+Q6x0XgpsFOY0A44M4Ak5EH4Vus8u ABGk0ENL0wM2mqmmfqt3VF7gdhgboCfJ6qD6EOOUxvVowZRSY6fc2aMffSYdDexlH/wv n2EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719597950; x=1720202750; h=content-transfer-encoding:in-reply-to:from:content-language :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=h9jhg57fS7Sxej2hwQNHjqF+6s4+CeCZMfG+JMi6knk=; b=nFUnXLdTN5P5WYYSXWeWfMaN1R5WbBnjrkwuojpmbSSArdU7R85tFCEkQ6sdxnHF2J QTCo8jT6bjM1l9O/rMfF71qRvZFngPXSNsF4ycOLnvqPl+kjjYMHiWpd0og8F5qSFZRK zKI/TFpFdg9epoQHeMlLFENDk4h+RKs5Thshu592sDkvp65NDRxwqbX44LCQKj1K7tmx 8n3bLdeKIewervZ62sXzun1c1SgJD3y88L8T7li+0XFwWxHBt6P6C0kcW0HhyRjxftrU nw83KY0KldMz5F7/6pvkBHzFnU0E2hp+X3FdDhzCmn9cC9IiETbri/hrMAIRx1ZJ96lu dlgg== X-Forwarded-Encrypted: i=1; AJvYcCUN8zHJ0nKWXt+dn83z5jgoIRf6H4tZ7A5RJJFFQQLXnyPbFSA6vVWEbsTKVxouAdS+emPiUll9mA1NkfpJAwlDQInB2zM4TkPsihLoXo1EwC3fIsY= X-Gm-Message-State: AOJu0YxO40bhWw3nS+1997HmWCMTzfXIg8faK/ZrXNtbnFvEObrVPuG2 Td6D7r2zfECrEpUFxhEOioBBCbzNMccM1yaAMb7WEiXKswSUGh/77XxxMMN41w== X-Google-Smtp-Source: AGHT+IFrcpDIZ5c0lQMNUo+kKfK13yz1cfUtbJGi3wyM2dDPIT1iw2gy5owixpW50M/NCoZMRJi9Pw== X-Received: by 2002:a17:903:234a:b0:1f9:b35f:65dc with SMTP id d9443c01a7336-1fa0d832226mr208517705ad.6.1719597949507; Fri, 28 Jun 2024 11:05:49 -0700 (PDT) Received: from ?IPV6:2401:4900:1f3e:18b0:e4e6:ed1:4c03:dcec? ([2401:4900:1f3e:18b0:e4e6:ed1:4c03:dcec]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1fad207514csm8267095ad.110.2024.06.28.11.05.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Jun 2024 11:05:49 -0700 (PDT) Message-ID: Date: Fri, 28 Jun 2024 23:35:35 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 0/7] misc: Add mikroBUS driver To: Andrew Lunn Cc: 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 , Michael Walle , jkridner@beagleboard.org, robertcnelson@beagleboard.org, linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Ayush Singh References: <20240627-mikrobus-scratch-spi-v5-0-9e6c148bf5f0@beagleboard.org> <1edcfd98-e73c-477e-a4ce-98cb41e66ab6@beagleboard.org> <54c18009-40c6-4c92-852e-6b7117e706a2@lunn.ch> Content-Language: en-US From: Ayush Singh In-Reply-To: <54c18009-40c6-4c92-852e-6b7117e706a2@lunn.ch> 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-20240628_110551_081117_C565982A X-CRM114-Status: GOOD ( 29.84 ) 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/28/24 19:22, Andrew Lunn wrote: >> 3. Allowing creation of sysfs entries `new_device` and `delete_device` >> similar to what already exists for I2C, etc. > On the I2C bus, these operate at the device level, you instantiate a > new I2C device. I assume here you are actually talking about board > level operations? So they would be 'new_board', and 'delete_board' > files in sysfs? > >> 4. Allow using 1-wire-eeprom in a fashion that allows automatic board >> discovery. >> >> >> Let me now introduce the 2 architectures we will be discussing: >> >> 1. mikrobus-connector has phandle to mikrobus-board: >> >> ``` >> >> \ { >> >>     connector1 { >> >>         board = <&board1>; >> >>     }; >> >> >>     mikrobus_boards { >> >>         board1 { >> >>             ... >> >>         }; >> >>     }; >> >> }; >> >> ``` >> >> >> 2. mikrobus board is a child node of mikrobus-connector: >> >> ``` >> >> \ { >> >>     connector1 { >> >>         ... >> >>         spi { > So there would actually be multiple child nodes, one per bus, and then > maybe a simple-bus for nodes which do not correspond to a bus, > e.g. gpio-key, gpio-leds, etc., > >>             board1 { >> >>                 ... >> >>             }; >> >>         }; >> >>     }; >> >> }; >> >> ``` >> >> >> I will now go over how each of these goals might look like in both of the >> architecture. >> >> 1. Keeping the device tree properties upstream in a system independent way: >> >> a. mikrobus-connector has phandle to mikrobus-board >> >> It is possible to create an overlay as follows which will work with any >> system that defines the `mikrobus_boards` node. This node is completely >> independent of mikroBUS connector and thus does not need to be rewritten (or >> generated) for each board. There are no problems for system with more than 1 >> mikrobus connector. >> >> ``` >> >> &mikrobus_boards { >> >>     board2 { >> >>         ... >> >>     }; >> >> >>     board3 { >> >>         ... >> >>     }; >> >> }; > So by default, you have an empty mikrobus_boards node? You then use DT > overlay to load the needed board into this node, and then update the > phandle in the connection node to point to the newly loaded node? > >> b. mikrobus board is a child node of mikrobus-connector: >> >> Not sure how to do something similar here. The overlay needs to be rewritten >> (or generated) for each board. > It would be good to explain why... > >> Systems with multiple mikrobus connectors >> will need multiple overlays adding the boards as child node of each >> connector (with status = "disabled"). > Why? Just load the one overlay actually required. > >> &connector1 { >> >>     spi = { >> >>         board 2 { >> >>             ... >> >>         }; >> >>         board 3 { >> >>             ... >> >>         }; >> >>     }; >> >> }; > I don't actually understand this description. I was expecting more > like: > > connector1: { > > spi = { > /* Optional TI TSC2046 touchscreen controller */ > opt_touch: touchscreen@0 { > compatible = "ti,tsc2046"; > spi-max-frequency = <2500000>; > reg = <0>; > pinctrl-0 = <&pmx_gpio_13>; > pinctrl-names = "default"; > interrupts-extended = <&gpio0 13 IRQ_TYPE_EDGE_FALLING>; > }; > }; > > i2c = { > opt_audio: audio@1a { > compatible = "ti,tlv320aic23"; > reg = <0x1a>; > }; > > the_rest = { > gpio_keys { > compatible = "gpio-keys"; > #address-cells = <1>; > #size-cells = <0>; > pinctrl-0 = <&pmx_reset_button &pmx_USB_copy_button>; > pinctrl-names = "default"; > > copy { > label = "USB Copy"; > linux,code = ; > gpios = <&gpio0 15 GPIO_ACTIVE_LOW>; > }; > reset { > label = "Reset"; > linux,code = ; > gpios = <&gpio0 16 GPIO_ACTIVE_LOW>; > }; > }; > > This is completely made up. You probably should use an example of a > real complex board using multiple busses. > > So for each actual bus on Mikrobus, you have a bus node, and then a > node for everything which is not bus orientated, like gpio-keys. > > So the overlay would simply populate these child nodes. I think I had a fundamental misunderstanding of what dt overlays can do. My understanding was that to say add thermo click in the above style with child nodes, the overlay needs to look as follows &connector1 {     spi {         thermo_click: {             compatible = "maxim,max31855k", "mikrobus-spi";             spi-max-frequency = <1000000>;             pinctrl-apply = "spi_default";         };     }; }; However, after going through the drm PR pointed by Rob and your description, it seems it is possible to create an overlay as follows: &spi {     thermo_click: {         compatible = "maxim,max31855k";         spi-max-frequency = <1000000>;         pinctrl-apply = "spi_default";     }; }; and apply it to the particular connector node (say connector1), at least from the driver. If that is the case, then yes, all of my reasons for not wanting to use child nodes become irrelevant. DRM PR: https://lore.kernel.org/all/20240510-hotplug-drm-bridge-v2-0-ec32f2c66d56@bootlin.com/ Ayush Singh