Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932843AbdDEQCX (ORCPT ); Wed, 5 Apr 2017 12:02:23 -0400 Received: from mx08-00178001.pphosted.com ([91.207.212.93]:50906 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933029AbdDEQCK (ORCPT ); Wed, 5 Apr 2017 12:02:10 -0400 Subject: Re: [PATCH v2 1/2] dt-bindings: Document the STM32 QSPI bindings To: Rob Herring References: <1490979724-10905-1-git-send-email-ludovic.Barre@st.com> <1490979724-10905-2-git-send-email-ludovic.Barre@st.com> <20170403165735.sopfhlxzefkzrbfh@rob-hp-laptop> CC: Cyrille Pitchen , Marek Vasut , David Woodhouse , Brian Norris , Boris Brezillon , Richard Weinberger , Alexandre Torgue , "linux-mtd@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" From: Ludovic BARRE Message-ID: <87299c6e-a107-c833-a102-a33a7b517291@st.com> Date: Wed, 5 Apr 2017 18:00:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.75.127.48] X-ClientProxiedBy: SFHDAG4NODE1.st.com (10.75.127.10) To SFHDAG6NODE1.st.com (10.75.127.16) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-04-05_12:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2441 Lines: 60 On 04/04/2017 02:20 PM, Rob Herring wrote: > On Tue, Apr 4, 2017 at 2:28 AM, Ludovic BARRE wrote: >> Hi Rob >> >> thanks for review >> my comments below >> >> br >> Ludo >> >> On 04/03/2017 06:57 PM, Rob Herring wrote: >>> On Fri, Mar 31, 2017 at 07:02:03PM +0200, Ludovic Barre wrote: >>>> From: Ludovic Barre >>>> >>>> This patch adds documentation of device tree bindings for the STM32 >>>> QSPI controller. >>>> >>>> Signed-off-by: Ludovic Barre >>>> --- >>>> .../devicetree/bindings/mtd/stm32-quadspi.txt | 45 >>>> ++++++++++++++++++++++ >>>> 1 file changed, 45 insertions(+) >>>> create mode 100644 >>>> Documentation/devicetree/bindings/mtd/stm32-quadspi.txt >>>> >>>> diff --git a/Documentation/devicetree/bindings/mtd/stm32-quadspi.txt >>>> b/Documentation/devicetree/bindings/mtd/stm32-quadspi.txt >>>> new file mode 100644 >>>> index 0000000..95a8ebd >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/mtd/stm32-quadspi.txt >>>> @@ -0,0 +1,45 @@ >>>> +* STMicroelectronics Quad Serial Peripheral Interface(QuadSPI) >>>> + >>>> +Required properties: >>>> +- compatible: should be "st,stm32f469-qspi" >>>> +- reg: contains the register location and length. >>>> + (optional) the memory mapping address and length >>> Why optional? Either the h/w has it or doesn't. If some chips don't, >>> they should have a different compatible string. >> in fact, the stm32 qspi controller can operate in any of the following >> modes: >> -indirect mode: all the operations are performed using the qspi registers >> with read/write. >> -read memory-mapped mode: the external Flash memory is mapped to the >> microcontroller address space and is seen by the system as if it was >> an internal memory (use memcpy_fromio). this mode improve read throughput >> >> if qspi_mm is defined the qspi controller use read memory-mapped mode >> else the controller transfers in indirect mode. > You should always have the memory region defined because that's what > the h/w has. If you want another property to select the mode, then > perhaps that's fine. But why? Can't the OS figure out which to use? > Why would you ever not use memory mapped mode unless the driver > doesn't yet support it? ok, I always map the memory region (qspi_mm is now required). if the nor-flash is more bigger than "qspi memory region", I force to use the indirect mode. > Rob