From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-171.mta0.migadu.com (out-171.mta0.migadu.com [91.218.175.171]) (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 EC24E1F1505 for ; Tue, 21 Jan 2025 15:54:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737474844; cv=none; b=D/4wTUsEAXgMpwi49B9shSvuFi7HpmjR0Gl3PtDFT1/98fzgm3VbffeDilnLr6gltQz3bJTsntoO5jOrwQuiSjwKTEkeXs65cPyPMtvImC9FVDQhZHv4pRI96+xhdvRp9epRw+j9cShxRUGmMflYVndq5jIrGVIaL5O+T0zd5So= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737474844; c=relaxed/simple; bh=wBQC14Rt/PgkQysycXVr1cBMxuDlIaZjTmrTbSFTbzk=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ngjtX+p9IpLX4gZjbdn6SxE7UaGBzWRA2ygn3DMlE/p/RaSYmvYv11zxzW7wqTSdu8N9H/tOND2COqb1EKx5BWDy73gs8TWBh9/qfvN7ehC84ft6ofCm50PfJzFaZOI6n+DjOXRHLMWMNGFqA9Ni8z4aud8C+Kztr23fj/T0JeM= 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=ltTGjO+N; arc=none smtp.client-ip=91.218.175.171 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="ltTGjO+N" Message-ID: <1f7cb52d-31a4-458c-9b81-b46bf56fd8a8@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1737474836; 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: in-reply-to:in-reply-to:references:references; bh=qZokMrKPeHOXql6MRfjxfjyRJSF/rWwkzlkixJHlCYg=; b=ltTGjO+NrkTZGtg6DDswxPOrt10T//WbFgRH7INoiGNS2JmVu/erqpzFMmavJFLS/1mbim 3jk5NqepV0m767M+qKoffQOtGu4lzfGqM+Zjfp9i35l+HchGxpX9LXKAhtxnPajDBkPiyx 2LClPhSaD2LptmXdKGcVazYE2C1MUXQ= Date: Tue, 21 Jan 2025 10:53:53 -0500 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH 5/7] spi: zynqmp-gqspi: Split the bus To: "Mahapatra, Amit Kumar" , Mark Brown , "Simek, Michal" , "linux-spi@vger.kernel.org" Cc: Jinjie Ruan , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Miquel Raynal , "amitrkcian2002@gmail.com" , "git (AMD-Xilinx)" References: <20250116232118.2694169-1-sean.anderson@linux.dev> <20250116232118.2694169-6-sean.anderson@linux.dev> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Sean Anderson In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 1/21/25 08:19, Mahapatra, Amit Kumar wrote: > Hello Andreson, > >> -----Original Message----- >> From: Sean Anderson >> Sent: Friday, January 17, 2025 4:51 AM >> To: Mark Brown ; Simek, Michal ; >> linux-spi@vger.kernel.org >> Cc: Jinjie Ruan ; linux-arm-kernel@lists.infradead.org; >> Mahapatra, Amit Kumar ; linux- >> kernel@vger.kernel.org; Miquel Raynal ; Sean >> Anderson >> Subject: [PATCH 5/7] spi: zynqmp-gqspi: Split the bus >> >> This device supports two separate SPI busses: "lower" (SPI0) and "upper" >> (SPI1). Each SPI bus has separate clock and data lines, as well as a hardware- >> controlled chip select. The busses may be driven independently, with only one bus >> active at a time, or in concert, with both busses active. If both busses are driven at >> once, data may either be duplicated on each bus or striped (bitwise) across both >> busses. >> >> The current driver does not model this situation. It exposes one bus, where CS 0 >> uses the lower bus and the lower chip select, and CS 1 uses the upper bus and the >> upper chip select. It is not possible to use the upper chip select with the lower bus >> (or vice versa). GPIO chip selects are unsupported, and there would be no way to >> specify which bus to use if they were. >> >> To conserve pins, designers may wish to place multiple devices on a single SPI bus. >> Add support for this by splitting the "merged" bus into an upper and lower bus. Each >> bus uses a separate devicetree node and has a single native chipselect 0. If "lower" > > IMHO, restricting users to fixed names is not ideal. A better approach would be to > introduce a Device Tree (DT) property for the bus number and select the bus > accordingly. Why? It's not an artificial restriction; it reflects the hardware. And this is how SPI busses are typically represented. If you have two SPI busses, there should be two devicetree nodes. --Sean