From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-182.mta0.migadu.com (out-182.mta0.migadu.com [91.218.175.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EF3BB2E63B for ; Tue, 23 Apr 2024 23:05:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713913508; cv=none; b=NB1gWArCQBxl6G7uZ275o9lS66CUrGtJhsfOXQqPvwJsZULRG90f28vNr94Kjpx/T2oGlNkwvAqVlWw844mArKbivZLPmCOSrEIb0d+v9eK3L5n1clWAdiH3DkzAd6LlCDlSJpGjHpmQvCjz2hkzspyk2XspDkCfz0FGnoOzo9A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713913508; c=relaxed/simple; bh=W5rtmWZn+gzmSPYDajf5hzHjrrARRPwmvtUOsrkg4+4=; h=Message-ID:Date:MIME-Version:To:Cc:From:Subject:Content-Type; b=MloSnZe4P8CTOequkvHTjMGEaXeM5YnExiN4VoIQAh/ornJE+gN1FsS7iMsWMkl4YWEwscwih2FnpPMGTdCoK9GM8UBAbVy3GBmKdtdq0bWFyQYjbO3IfUv35QHKBlvTpNDJCs2WV4NzjxvR/5RyBdSlnvxOmstrH3kYpli5BJ8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=iIWWrZ6T; arc=none smtp.client-ip=91.218.175.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="iIWWrZ6T" Message-ID: <5bb0dc7e-4c89-4f3d-abc6-41ae9ded5ae9@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1713913503; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=MSoV0N+Bh0IcWueNazIcpLY5jxZX12Cx6M7J1n6K4tQ=; b=iIWWrZ6TYv1Vkk9lzS5cmCbBhaLuYOk6Y3nM7tg9EQHaECQ4PwjLBPtijt3JPsXmwxwUs8 G0aNxaaEd1AFs9bPfZnlFuXSArh1+4m56fH2DQ1ULb8FjeIrWj53YB0naS/20bX503DvbS 7YtZjJWLmJxpyDE2ScYFTkwSzguYsdQ= Date: Tue, 23 Apr 2024 19:04:59 -0400 Precedence: bulk X-Mailing-List: linux-gpio@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Language: en-US To: Michal Simek , "linux-gpio@vger.kernel.org" Cc: Linus Walleij , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Sean Anderson Subject: pinctrl: zynqmp: Valid pin muxings cannot be configured Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT Hi Michal, I was looking to upstream one of our ZynqMP boards, and I ran into an issue with the pinmuxing. We use almost all of the I/Os, so everything is tightly packed into the MIO. For example, we have the QSPI on MIO0 to MIO5, and MIO6 to MIO11 are used for SPI1. However, I cannot select this configuration using the pinmux driver. I am using the following configuration: pinctrl_qspi_default: qspi-default { mux { groups = "qspi0_0_grp"; function = "qspi0"; }; mux-cs { groups = "qspi_ss_0_grp"; function = "qspi_ss"; }; }; pinctrl_spi1_default: spi1-default { mux { groups = "spi1_0_grp"; function = "spi1"; }; mux-cs { groups = "spi1_ss_0_grp", "spi1_ss_1_grp"; function = "spi1_ss"; }; }; But I get the following errors on boot: [ 4.261739] zynqmp-pinctrl firmware:zynqmp-firmware:pinctrl: pin MIO8 already requested by ff050000.spi; cannot claim for ff0f0000.spi [ 4.274506] zynqmp-pinctrl firmware:zynqmp-firmware:pinctrl: error -EINVAL: pin-8 (ff0f0000.spi) [ 4.283789] zynqmp-pinctrl firmware:zynqmp-firmware:pinctrl: error -EINVAL: could not request pin 8 (MIO8) from group qspi0_0_grp on device zynqmp_pinctrl This is because the qspi0_0_grp and spi1_0_grp groups overlap: group: qspi0_0_grp pin 0 (MIO0) pin 1 (MIO1) pin 2 (MIO2) pin 3 (MIO3) pin 4 (MIO4) pin 8 (MIO8) pin 9 (MIO9) pin 10 (MIO10) pin 11 (MIO11) pin 12 (MIO12) group: qspi_ss_0_grp pin 5 (MIO5) pin 7 (MIO7) group: qspi_fbclk_0_grp pin 6 (MIO6) group: spi1_0_grp pin 6 (MIO6) pin 10 (MIO10) pin 11 (MIO11) group: spi1_ss_0_grp pin 9 (MIO9) group: spi1_ss_1_grp pin 8 (MIO8) group: spi1_ss_2_grp pin 7 (MIO7) However, we are not using the "upper" pins of the QSPI device. Therefore, these pins should not be included in the qspi0_0_grp. This stems from the driver placing all possible pins into a function's group, even though each pin can be muxed individially and it is not necessary to mux all pins for full functionality. I think it would be better to have a single group for each pin: pinctrl_qspi_default: qspi-default { mux { groups = "mio0", "mio1", "mio2", "mio3", "mio4"; function = "qspi0"; }; mux-cs { groups = "mio5"; function = "qspi_ss"; }; }; pinctrl_spi1_default: spi1-default { mux { groups = "mio6", "mio10", "mio11"; function = "spi1"; }; mux-cs { groups = "mio8", "mio9"; function = "spi1_ss"; }; }; This allows the full functionality of this chip to be configured. Does that sound good? I can send a patch to this effect if you agree. --Sean 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 79783C4345F for ; Tue, 23 Apr 2024 23:15:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Subject:From:Cc:To:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=ch/MKM4GtEAKUXSLhYyLHXCBiwkYeZ0wm5yHaoHhzHM=; b=lm+DecV4N7tjut NERcAq47UoCT4JTB4o/mx24s/EX/p/igFcBcGcR16BiB32i7XdOrbZPdzVALXBMGS6vHG8ASC9F1L Opm/4sN4rSJxq7yasD8URvThDsO5gh81ujZOt2StfHVXGyXM8SMpqdsmHMuoFzbzQNORSXx8ss/jl DMLZ90W9OtXRenKsvJ1enLorq2yW3xuiScuZGvo8LRhruyGtQ8nmadCT7gqKnMExKavGtkt3ylZka UODRpF5bfLH+fa6Rd4PQ4JLyLE/zDSBJsAw6sLsuJ9nF0RW8Fg9p4aOmbc0++mMMSpPUjUXzKquw4 x65UwPKkjbSMPnzQDQQQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rzPMS-00000001oGt-3ct8; Tue, 23 Apr 2024 23:15:40 +0000 Received: from out-175.mta0.migadu.com ([2001:41d0:1004:224b::af]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rzPMQ-00000001oFl-0Qx9 for linux-arm-kernel@lists.infradead.org; Tue, 23 Apr 2024 23:15:39 +0000 Message-ID: <5bb0dc7e-4c89-4f3d-abc6-41ae9ded5ae9@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1713913503; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=MSoV0N+Bh0IcWueNazIcpLY5jxZX12Cx6M7J1n6K4tQ=; b=iIWWrZ6TYv1Vkk9lzS5cmCbBhaLuYOk6Y3nM7tg9EQHaECQ4PwjLBPtijt3JPsXmwxwUs8 G0aNxaaEd1AFs9bPfZnlFuXSArh1+4m56fH2DQ1ULb8FjeIrWj53YB0naS/20bX503DvbS 7YtZjJWLmJxpyDE2ScYFTkwSzguYsdQ= Date: Tue, 23 Apr 2024 19:04:59 -0400 MIME-Version: 1.0 Content-Language: en-US To: Michal Simek , "linux-gpio@vger.kernel.org" Cc: Linus Walleij , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Sean Anderson Subject: pinctrl: zynqmp: Valid pin muxings cannot be configured X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240423_161538_385296_A17513A7 X-CRM114-Status: GOOD ( 13.12 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Michal, I was looking to upstream one of our ZynqMP boards, and I ran into an issue with the pinmuxing. We use almost all of the I/Os, so everything is tightly packed into the MIO. For example, we have the QSPI on MIO0 to MIO5, and MIO6 to MIO11 are used for SPI1. However, I cannot select this configuration using the pinmux driver. I am using the following configuration: pinctrl_qspi_default: qspi-default { mux { groups = "qspi0_0_grp"; function = "qspi0"; }; mux-cs { groups = "qspi_ss_0_grp"; function = "qspi_ss"; }; }; pinctrl_spi1_default: spi1-default { mux { groups = "spi1_0_grp"; function = "spi1"; }; mux-cs { groups = "spi1_ss_0_grp", "spi1_ss_1_grp"; function = "spi1_ss"; }; }; But I get the following errors on boot: [ 4.261739] zynqmp-pinctrl firmware:zynqmp-firmware:pinctrl: pin MIO8 already requested by ff050000.spi; cannot claim for ff0f0000.spi [ 4.274506] zynqmp-pinctrl firmware:zynqmp-firmware:pinctrl: error -EINVAL: pin-8 (ff0f0000.spi) [ 4.283789] zynqmp-pinctrl firmware:zynqmp-firmware:pinctrl: error -EINVAL: could not request pin 8 (MIO8) from group qspi0_0_grp on device zynqmp_pinctrl This is because the qspi0_0_grp and spi1_0_grp groups overlap: group: qspi0_0_grp pin 0 (MIO0) pin 1 (MIO1) pin 2 (MIO2) pin 3 (MIO3) pin 4 (MIO4) pin 8 (MIO8) pin 9 (MIO9) pin 10 (MIO10) pin 11 (MIO11) pin 12 (MIO12) group: qspi_ss_0_grp pin 5 (MIO5) pin 7 (MIO7) group: qspi_fbclk_0_grp pin 6 (MIO6) group: spi1_0_grp pin 6 (MIO6) pin 10 (MIO10) pin 11 (MIO11) group: spi1_ss_0_grp pin 9 (MIO9) group: spi1_ss_1_grp pin 8 (MIO8) group: spi1_ss_2_grp pin 7 (MIO7) However, we are not using the "upper" pins of the QSPI device. Therefore, these pins should not be included in the qspi0_0_grp. This stems from the driver placing all possible pins into a function's group, even though each pin can be muxed individially and it is not necessary to mux all pins for full functionality. I think it would be better to have a single group for each pin: pinctrl_qspi_default: qspi-default { mux { groups = "mio0", "mio1", "mio2", "mio3", "mio4"; function = "qspi0"; }; mux-cs { groups = "mio5"; function = "qspi_ss"; }; }; pinctrl_spi1_default: spi1-default { mux { groups = "mio6", "mio10", "mio11"; function = "spi1"; }; mux-cs { groups = "mio8", "mio9"; function = "spi1_ss"; }; }; This allows the full functionality of this chip to be configured. Does that sound good? I can send a patch to this effect if you agree. --Sean _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel