From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934077AbdDSLX5 (ORCPT ); Wed, 19 Apr 2017 07:23:57 -0400 Received: from mail-eopbgr20110.outbound.protection.outlook.com ([40.107.2.110]:38735 "EHLO EUR02-VE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933948AbdDSLXw (ORCPT ); Wed, 19 Apr 2017 07:23:52 -0400 Authentication-Results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=axentia.se; Subject: Re: [PATCH v13 02/10] dt-bindings: document devicetree bindings for mux-controllers and gpio-mux To: Philipp Zabel References: <1492101794-13444-1-git-send-email-peda@axentia.se> <1492101794-13444-3-git-send-email-peda@axentia.se> <1492509996.2432.63.camel@pengutronix.de> <17135062-e58a-b50e-ac85-5f0f0b73d958@axentia.se> <1492593449.2970.24.camel@pengutronix.de> <0cf0254e-0e43-37c3-f14d-eeffa7d7b9ba@axentia.se> <1492599958.2970.84.camel@pengutronix.de> CC: , Greg Kroah-Hartman , Mark Rutland , , Lars-Peter Clausen , Wolfram Sang , , Jonathan Corbet , , , Paul Gortmaker , Rob Herring , , Peter Meerwald-Stadler , Hartmut Knaack , Colin Ian King , Andrew Morton , Jonathan Cameron From: Peter Rosin Organization: Axentia Technologies AB Message-ID: <687b26d7-7d80-e8e1-5aa8-a4e8bc070e42@axentia.se> Date: Wed, 19 Apr 2017 13:23:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1492599958.2970.84.camel@pengutronix.de> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [81.224.171.159] X-ClientProxiedBy: AM4PR05CA0024.eurprd05.prod.outlook.com (10.171.184.165) To VI1PR0202MB2557.eurprd02.prod.outlook.com (10.173.79.136) X-MS-Office365-Filtering-Correlation-Id: ebb6a991-bca0-46eb-1cb1-08d487168c05 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(201703131423075);SRVR:VI1PR0202MB2557; X-Microsoft-Exchange-Diagnostics: 1;VI1PR0202MB2557;3:ks6JaJYh+G5Mu1uywO3AHI239CnkRtP7Sxz6uvT/5vmnwaWiex7aLFz0kfDbTU5gpIQi6XRjvu4230MseFRFtTmFnqiUA7bdfa1j/qcwYMbbevrNDusPRZ8wtX7Io579jnz7fLx/24t96jiBUKddpcxD6k4GzXUG0309lpjtSseKSQugK79MqfOnHu12pWGKi2Dpp04MBMhUyjcFz8DKLECarawdAMNo7MOJALxDprf/rXK30cuXrQ9dAfISHFgmXQ/4dNUJBopvEQzDhjlgOl2ZQgdWJWJxrWyHplfOW7btqVrFJWcyZkMNC812CODm;25:ixOLEhYyoTe5rwa8llhkwYi3ZcK4v+gGku19XwjV8P0af/6hYC6G5o7KtVm95TccNVJpajqJNajY1RCyr5sDF327OXdv5qNcExykaK9OPt2tF+EiyT+0iybgrjqQrNpn6wnpBWo7eQvnDnOWC4mRSoC+K37VgBgw4DathvPFIV5z+flLubYc5RXPjAShTyMMa2/Cou0fl+mM1lhrzHqYXzeAfBjnoHvywqhqRHR71y2gZdp4hdbTthiTzmfk4D46L/7jS03C/vjh0+zcjR5y1knqfTpvZppHyqKzq+6VLr81kieWZbJDm1kUsc7ER3pUYQoTOvqg03tudouHmV5Gm31DpAl4u+iL6MlN/0jXI9A/PHxFxZptDCSS9QIiPdcGvY96LGnqsKrpg2r3RIAPLUYyvEo/lKLAgNBcxcvDKWT2+/tqJZbaNnx6bhVNLxGUBLi/vDxbYcCpYf1+yq3c0A== X-Microsoft-Exchange-Diagnostics: 1;VI1PR0202MB2557;31:N5ZKdZgg7pQ0niltun5bmnflNTxAgVum08Uw5QLxvtvoEbmJvFbQJ60qG5jiko+WRPJoC9ndc3mB3u4R0E4JBk7f6bbxmV+x1kBygjfVnsN9B2Y2HEFo4oNfWGc241nfLF0YEJ4axWNn6/qHL52ykx802/YTg5Gt9EA3A2EuzVliM4DYgMGaeg22H9Japvp2dGO5fzIAP7vIjmi+9SACrNuuubsV5XYBMoDVc3ibsVjZhBZ8+hEcB2PoxhBz8D7yXVljk0f+nBJBTAa2/SQ4ZQ== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(788757137089); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123562025)(20161123560025)(2016111802025)(20161123555025)(20161123564025)(6072148)(6043046);SRVR:VI1PR0202MB2557;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0202MB2557; X-Microsoft-Exchange-Diagnostics: 1;VI1PR0202MB2557;4:bkL1iwfuw8iZ7wjGsLIxftwxHolJ5as9ULCHMVG/2mLRt9zVW7db+K6ISFdvZ8uYgR2URPZ/RrVBd+zOPSupcoAzKzKFGSajoEUOMFUMiXGVu76VFzbPGDJapc/oH6ga/TdiKDOqRUERvfSdkylndf3MFO/Fzkkyyst16uk+Dp2B0p3qbrXewYqslZVR+YQEd2G/2N66YsxmQ8NFEi7t51rx3QurqBLMlV/rmnXfUF/r6cq95jKBjPjlwlfFxFFJz/dO0EmFi6wWbFHYiiTBr0ncCI3kfmJQqrK2WIn+X59eC9kc3taOdSWvPMjP8E2DvEerbazKRIe++uY72NcDbmXBBasLROLlG4Quxd+GTtD/tg5maGOUzqck+NgKvn43hGMPYKfQgDsyKmYyuxkwbSY1MFnXss/SRZucFSrIQf9aRn5OXc6twBk1E/3xoUXKL1QpKXgbjB78kGrI1+2KIQucvgEgrl8knp+iDe+PxkXQff7mCP53EatNaGfqw+xP1FFaKX6iDx9KhD/1gmOCLcumGSkgkaZpijjl+ESyDInf1XyH+gN+K9pvpMObUu/fGLyXp88RXg83rgOZNF5U93+y/gNxcocCqBXf0CtrxwPWH7Ufj1HvncunN0fGjyyh8pl657gS5gy3g5XTuOShtyLdqcZk5rGa7W7eYLF9MgsD0HlcCanB0/drooJtljFGo+LCj9ottnOsF2XsseXrN9l9FxpDa4/RDeuOZdV5qGjzWaEDYGjILb9yt17Bmhwa6HjHSkTCOqIF2mj6yPClvJORVeTaCjFV11EtWCAC9odMBKHMyMFaY+0CKk/k/JKW X-Forefront-PRVS: 028256169F X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6049001)(6009001)(39450400003)(39400400002)(39410400002)(39830400002)(24454002)(377424004)(25786009)(229853002)(53546009)(2906002)(36756003)(7416002)(50986999)(3260700006)(4001350100001)(54356999)(76176999)(31686004)(42186005)(66066001)(117156002)(2950100002)(6666003)(8666007)(74482002)(86362001)(7736002)(5660300001)(47776003)(33646002)(110136004)(54906002)(305945005)(53936002)(4326008)(31696002)(90366009)(50466002)(38730400002)(8676002)(189998001)(6916009)(6486002)(23676002)(6116002)(3846002)(93886004)(83506001)(77096006)(64126003)(230700001)(81166006)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:VI1PR0202MB2557;H:[192.168.0.125];FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjAyMDJNQjI1NTc7MjM6RU9DTTZNUUFLM25WSWRpT3owUFhFdFhM?= =?utf-8?B?WHYyZGp5SHBsNVp4ZVFVanZxSWVhaXJac1VHTDNKQ1paQlZYT2tzOEpFREZE?= =?utf-8?B?VUNzWHcrSTlYZktwV3R4VTgzU1dySGl4aVRHbFdsYUZWSTlJUUJFN2JLQk9Z?= =?utf-8?B?TEpXYUxzVnhFblozeCt1aUpGMWtlUFhmNmtCdllMTWMvZjRnVFVNYTkzRDNO?= =?utf-8?B?VjRGcHZrWlZ3bXhmMDJsODF4dGZJb0RNVVBWTXgyNUJUUzFNcDZqMm5QVGhQ?= =?utf-8?B?NktBQ0F5NVRRc01pQlNWTUpIalpURUEwSnJ0UVY5K2tkeGJibkFPVnNobzVN?= =?utf-8?B?NVJNMi9pMmJ2YUlwUTVrS2NWR3IxWnhvOVM5TXo0Ui8yajRDU043ZGZnLzRa?= =?utf-8?B?dHVZdE1hMGcrYnZoNWpMSlJJYTZUd1RvbE1HK05lOW5vTlhPd3JLSGNRSEFt?= =?utf-8?B?UHAzYlUwNzZmM3U4UG9VSHJsTTZHaVNHTSt5TC9vSEFEUWk3TjJrNnhUYWt4?= =?utf-8?B?dTY2QXJ5VXVNVENwQmRwSWdVMzcvaU9oMnJUMzRMRS9iNlQ0ejljRklTL3Yy?= =?utf-8?B?Y1RpWHliRUJTUzBPOEZxTHJPbmVnRHFnQ0pRUnhiekMreitMalRQRnlVcEd3?= =?utf-8?B?OXJxL2YyVklTNkREdmd3d2tTZGVEQ2FSNEs3ZjljTWRJSnRnaTlXeGo3aVV6?= =?utf-8?B?M0tsOGRiVGlDbng0Tm0yYzBNaDNvM1BJMktSRTJvQ3VXc2JEV3lleHJuc3lv?= =?utf-8?B?Q0JIS3MzeTFlRzNQZjV3enpRMDRMcEt1QmVLVVBRbG5YN1J1WEtFYkJrTGY5?= =?utf-8?B?bkFxMllyVFYzcytiNEJIaWQ0S0lGSy9SUkJTRElPVjFLQkZ6dGczR09kTlk0?= =?utf-8?B?Ukp0cUlzOCtnWitDRXVBVmxsdlA0aGdmM091NkJRTDVvS3pDOVIvR1lCOU9w?= =?utf-8?B?aTkzbkh6R0drbXZEU1NSRm9HK25VamJZaGM0cVZqTFByOXdrSkxTZ0tISGdE?= =?utf-8?B?em1nQ3dlRmVEQUFzUmRpdEtlWlpyUEdsSkZGQWhtWDdEM1pvM3FFZnVmR3l5?= =?utf-8?B?V3VGbDllQURaZ081WHI3SGhIZTFwOElEcHZNR3B0OTEwZ3JlRmlTeC9RNHlQ?= =?utf-8?B?Sk9iSGxtcytGZXc2QkZsMjRpWDN6b1JyNmJDZi9uRERiSVhObmtiYUpYTDho?= =?utf-8?B?MmdocXZlQ2ZpQXE0MnprUW9xUktWaFIrV1VzSkhtcEdRMXJ5T3hKN2Q5MGhF?= =?utf-8?B?WmZ3MmtrbWlhb2t1YTlnU0oyaVFoZm1TMUpVeEpTVlowRGVTM2JlSnl6WnBJ?= =?utf-8?B?VVhEYThQd2F1a0NMd0cyeGtxYnRncXhrb3h0N281UnR4bEY1WUMraTRRWkJN?= =?utf-8?B?NkRLT25qVCtuR2o5a2ZSbXdGamJTMFM0VGVqblNuUjdBWE5hT0E2MnV6cFdm?= =?utf-8?B?U29RR2RaMkNaSFJsY1JmVXkzSjh0dDRTNW5pTndwUW1FVGFrQ05mdVhhazVx?= =?utf-8?B?YW1yTnVycng1MHZmTGk2RVd2VCtZa3ZlbkhEME82eElpd09uMlRMdW44VFUw?= =?utf-8?B?cjJNMHVuWmt2bDVLek5FWTNTR1hyRmY3cmw1dHR5OGZhTStQOTVYbjM0ZnJ6?= =?utf-8?B?WUhjN2NQNjZWem43enRsUHdRci9MWFFMYzU4dnc0RnFCRUVTWk0zbGQ4M29Z?= =?utf-8?B?dkN0T1FwQUpZdXpuWTNJcDlvcnNET0lrS1FTNEp1YkQ0S2xOSEozV05jRlpK?= =?utf-8?B?QlhRNG54dU1RbEduNzRmem4yOUV2QkhrQk02V3hPQVFHS1FTVjh5a3IzSEV4?= =?utf-8?B?Z1ltcTFySzNsMHJSQWpuMDhUMFk1Uzh0VGdhRUN2NldaaVh0QT09?= X-Microsoft-Exchange-Diagnostics: 1;VI1PR0202MB2557;6:uMni2wXuI+xuOmokejn4DUzqnmfYOnoNrHGV3iCWDPhmz1fFAzjeEbFBUDfogiN5bAQwp6K/LeQUOYEG6bKUh2Gibjd0fNXxZGVwbBRnu/5kZQiPR9kTsevLdgT0BskawWla+kVBY3vFqhdUPEmQ4emUulI7BVTe6Vjk+j9TGhQhrLgxkjwM3SRUbiXBS8+zW8PU12cmR/aRIGoRPDfe3nwTVH6UHGh2P25sDaDLDJnNPx9CK1pU1lSWl7CYsUNoZvvI/fatAiJ6TWts4qgRw/8EnP6iepfeOKgqe5UU2oZfg3ITxOpPNAwYkI961CjW6w2u0W7/vS+svBTnzauWQXxH9tzHQU96t195VF4EgBSsuDsadm1B2debRiFzz69TSFS5CC34qkL8BCKToWEtwmlQT8PAQeyAVcQSPieNtFZW2Q2CvWQXNCwqce4RNtMUMekNMV3hJNUobDwHX0EitQ==;5:4ohepc0gZgl9lSDx8ZWY3+mMOzT5wRZD659zy7IXIjLrYqVYgUAzEEYzdQwiEAM8RkhMPN6u8yhTd9JhXx/kUGAaBa9viJJROpvn58kAJBXMe54AqPUABmOSHjHzi1Ycw0n38IYHgv38lw4oPitkGQ==;24:WaG7cdeDf5kFQrBqTghU8ZLRDBbBacn103o4DIQadvCrMV78A1LrUuIzv4ZF4IgiT5Ld1SMhvQ+8zgDoWnSZHAXIpBUo7wshii1xurG4Fmc= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;VI1PR0202MB2557;7:9dxRv5rpXZ9wMdoubLcGuKx0zQN511+aIrdg3CRBmQE95s3cv5t10UyjzHnlLEBWIOkanECmzapL1gCpNvu7cmsGXFdXc+Jx7oU3kEzScaFaB+9q16GZYch1MRpsFwG9QfJMqH1XWTdIcIOjqM1ZPzSzDE2gyFsgKHxu2R7FqUTv2PIDvQnOxA2Uft7nWAw67MufhRJ76nH1K0jXXCfUm0JvC06AKV5G2QAq+/Gi7Ca0wFllE22sl3jj9qugYxBRwoIza7GNsp9DZvK4SAMo7RIURCVbWzXR/XtMdV/oiCzHh/GmgZWCqBkFr3XxuvdSN2AhDR1TcKEr4UpiH+ttvw== X-OriginatorOrg: axentia.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Apr 2017 11:23:45.6663 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0202MB2557 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2017-04-19 13:05, Philipp Zabel wrote: > On Wed, 2017-04-19 at 12:41 +0200, Peter Rosin wrote: >> On 2017-04-19 11:17, Philipp Zabel wrote: >>> On Tue, 2017-04-18 at 15:36 +0200, Peter Rosin wrote: >>>> If I got things wrong when I skimmed whatever I came across, and if the >>>> mmio register is the only mux control option in the stars, it becomes >>>> less obvious... It's of course still possible to hook into the mux >>>> subsystem, but the benefit is questionable. And you do get the extra >>>> device tree node. You could of course also implement a mux driver >>>> outside of drivers/mux and thus make use of the mux api, but it's tiny >>>> and any benefit is truly small. >>> >>> What I wondered mostly is whether it would be a good idea to move the >>> OF-graph ports into the mux controller node, and let the video capture >>> device be the consumer of the mux. >>> But this wouldn't fit well with the clear split between the mux >>> controller and the actual mux hardware in the mux DT bindings. >> >> I have tried to do something similar. I think. The current >> drivers/i2c/muxes/i2c-mux-gpio.c is a good candidate for the same thing >> IIUC. >> >> That dedicated driver and the general purpose i2c mux driver does pretty >> much the same thing with these two DT snippets: >> >> Dedicated i2c-mux-gpio DT snippet: >> >> i2c-mux { >> compatible = "i2c-mux-gpio"; >> i2c-parent = <&i2c1>; >> >> mux-gpios = <&gpio1 22 0 &gpio1 23 0>; >> >> #address-cells = <1>; >> #size-cells = <0>; >> >> i2c@1 { >> ... >> }; >> >> i2c@3 { >> ... >> }; >> }; >> >> General purpose mux DT snippet: >> >> mux: mux-controller { >> compatible = "gpio-mux"; >> #mux-control-cells = <0>; >> >> mux-gpios = <&gpio1 22 0 &gpio1 23 0>; >> }; >> >> i2c-mux { >> compatible = "i2c-mux"; >> i2c-parent = <&i2c1>; >> >> mux-controls = <&mux>; >> >> #address-cells = <1>; >> #size-cells = <0>; >> >> i2c@1 { >> ... >> }; >> >> i2c@3 { >> ... >> }; >> }; > > Yes, replace i2c-mux with video-mux and the i2c@x nodes with port@x > nodes, and this is very close to what I am thinking about. > >> I would love to find a way to cleanly get the mux framework to handle >> the first DT as well, and thus being able to obsolete the dedicated >> i2c-mux-gpio driver. I have not figured out how to accomplish that >> without abusing the driver-model to a point that it's not working. >> Help with that task is dearly appreciated. >> >> What I have stumbled on, I think, is that two drivers needs to be >> instantiated from the same DT node. At the same time, I need the >> mux framework to handle the current out-of-node thing with a >> phandle as well, so that several mux consumers can share a common >> mux controller. My understanding of these matters are apparently not >> deep enough... > > Not necessarily, if the framework could export a function to create a > gpio/mmio mux_chip on a given device and the gpio-mux and *-mux-gpio > drivers just reuse that. I've been up that creek. Why should the gpio mux be special cased? That's not clean, the implication is that all mux consumers need to handle the gpio case and have a special compatible for that case etc. Then someone thinks the DT should look equally "clean" for some i2c based mux, and the weeds start piling up. This is exactly what we don't want. We want the mux consumer drivers to be totally agnostic about the fact that they happen to use a gpio mux. Cheers, peda From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Rosin Subject: Re: [PATCH v13 02/10] dt-bindings: document devicetree bindings for mux-controllers and gpio-mux Date: Wed, 19 Apr 2017 13:23:42 +0200 Message-ID: <687b26d7-7d80-e8e1-5aa8-a4e8bc070e42@axentia.se> References: <1492101794-13444-1-git-send-email-peda@axentia.se> <1492101794-13444-3-git-send-email-peda@axentia.se> <1492509996.2432.63.camel@pengutronix.de> <17135062-e58a-b50e-ac85-5f0f0b73d958@axentia.se> <1492593449.2970.24.camel@pengutronix.de> <0cf0254e-0e43-37c3-f14d-eeffa7d7b9ba@axentia.se> <1492599958.2970.84.camel@pengutronix.de> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1492599958.2970.84.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> Sender: linux-iio-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Philipp Zabel Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Greg Kroah-Hartman , Mark Rutland , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Lars-Peter Clausen , Wolfram Sang , linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jonathan Corbet , linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org, Paul Gortmaker , Rob Herring , linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Peter Meerwald-Stadler , Hartmut Knaack , Colin Ian King , Andrew Morton , Jonathan Cameron List-Id: devicetree@vger.kernel.org On 2017-04-19 13:05, Philipp Zabel wrote: > On Wed, 2017-04-19 at 12:41 +0200, Peter Rosin wrote: >> On 2017-04-19 11:17, Philipp Zabel wrote: >>> On Tue, 2017-04-18 at 15:36 +0200, Peter Rosin wrote: >>>> If I got things wrong when I skimmed whatever I came across, and if the >>>> mmio register is the only mux control option in the stars, it becomes >>>> less obvious... It's of course still possible to hook into the mux >>>> subsystem, but the benefit is questionable. And you do get the extra >>>> device tree node. You could of course also implement a mux driver >>>> outside of drivers/mux and thus make use of the mux api, but it's tiny >>>> and any benefit is truly small. >>> >>> What I wondered mostly is whether it would be a good idea to move the >>> OF-graph ports into the mux controller node, and let the video capture >>> device be the consumer of the mux. >>> But this wouldn't fit well with the clear split between the mux >>> controller and the actual mux hardware in the mux DT bindings. >> >> I have tried to do something similar. I think. The current >> drivers/i2c/muxes/i2c-mux-gpio.c is a good candidate for the same thing >> IIUC. >> >> That dedicated driver and the general purpose i2c mux driver does pretty >> much the same thing with these two DT snippets: >> >> Dedicated i2c-mux-gpio DT snippet: >> >> i2c-mux { >> compatible = "i2c-mux-gpio"; >> i2c-parent = <&i2c1>; >> >> mux-gpios = <&gpio1 22 0 &gpio1 23 0>; >> >> #address-cells = <1>; >> #size-cells = <0>; >> >> i2c@1 { >> ... >> }; >> >> i2c@3 { >> ... >> }; >> }; >> >> General purpose mux DT snippet: >> >> mux: mux-controller { >> compatible = "gpio-mux"; >> #mux-control-cells = <0>; >> >> mux-gpios = <&gpio1 22 0 &gpio1 23 0>; >> }; >> >> i2c-mux { >> compatible = "i2c-mux"; >> i2c-parent = <&i2c1>; >> >> mux-controls = <&mux>; >> >> #address-cells = <1>; >> #size-cells = <0>; >> >> i2c@1 { >> ... >> }; >> >> i2c@3 { >> ... >> }; >> }; > > Yes, replace i2c-mux with video-mux and the i2c@x nodes with port@x > nodes, and this is very close to what I am thinking about. > >> I would love to find a way to cleanly get the mux framework to handle >> the first DT as well, and thus being able to obsolete the dedicated >> i2c-mux-gpio driver. I have not figured out how to accomplish that >> without abusing the driver-model to a point that it's not working. >> Help with that task is dearly appreciated. >> >> What I have stumbled on, I think, is that two drivers needs to be >> instantiated from the same DT node. At the same time, I need the >> mux framework to handle the current out-of-node thing with a >> phandle as well, so that several mux consumers can share a common >> mux controller. My understanding of these matters are apparently not >> deep enough... > > Not necessarily, if the framework could export a function to create a > gpio/mmio mux_chip on a given device and the gpio-mux and *-mux-gpio > drivers just reuse that. I've been up that creek. Why should the gpio mux be special cased? That's not clean, the implication is that all mux consumers need to handle the gpio case and have a special compatible for that case etc. Then someone thinks the DT should look equally "clean" for some i2c based mux, and the weeds start piling up. This is exactly what we don't want. We want the mux consumer drivers to be totally agnostic about the fact that they happen to use a gpio mux. Cheers, peda