Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [03/12] bus: stm32-fmc2-ebi: add STM32 FMC2 EBI controller driver
To:     Christophe Kerello <christophe.kerello@st.com>,
        miquel.raynal@bootlin.com, richard@nod.at, vigneshr@ti.com,
        lee.jones@linaro.org, robh+dt@kernel.org, mark.rutland@arm.com,
        tony@atomide.com
Cc:     linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
        linux-stm32@st-md-mailman.stormreply.com
References: <1584975532-8038-1-git-send-email-christophe.kerello@st.com>
 <1584975532-8038-4-git-send-email-christophe.kerello@st.com>
 <f6a2c766-8ae5-fab7-e2f6-db23f39b5d91@denx.de>
 <93fce520-9269-123c-9523-173e75cdce2e@st.com>
From:   Marek Vasut <marex@denx.de>
Message-ID: <94845952-ae8d-dab1-7bbe-21830d05480b@denx.de>
Date:   Mon, 30 Mar 2020 11:30:44 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <93fce520-9269-123c-9523-173e75cdce2e@st.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 3/30/20 11:19 AM, Christophe Kerello wrote:
> 
> 
> On 3/30/20 3:24 AM, Marek Vasut wrote:
>> On 3/23/20 3:58 PM, Christophe Kerello wrote:
>>> The driver adds the support for the STMicroelectronics FMC2 EBI
>>> controller
>>> found on STM32MP SOCs.
>>>
>>
>> On DH STM32MP1 SoM in PDK2 carrier board,
>> Tested-by: Marek Vasut <marex@denx.de>
>>
>> btw. it seems this sets BTRx DATLAT and CLKDIV to 0xf , it's "Don't
>> care" in the datasheet for Muxed mode, but then it should probably be
>> set to 0.
> 
> Hi Marek,

Hi,

> Thanks for testing.

Sure

> These 2 bit fields (BTRx DATLAT and CLKDIV) are only needed for
> synchronous transactions. Based on your bindings, the transaction type
> is asynchronous.
> CLKDIV bit fields should not be set to 0x0, as this value is reserved
> for this bit field. The driver keeps the reset value when it is not
> needed to update a bit field.

Then I guess that's fine either way.