[PATCH] cadence_qspi: Refactor the flash reset functionality

Michal Simek michal.simek at amd.com
Thu Nov 7 13:53:54 CET 2024



On 11/7/24 05:57, Abbarapu, Venkatesh wrote:
> Hi Michal,
> 
>> -----Original Message-----
>> From: Simek, Michal <michal.simek at amd.com>
>> Sent: Wednesday, November 6, 2024 5:17 PM
>> To: Abbarapu, Venkatesh <venkatesh.abbarapu at amd.com>; u-boot at lists.denx.de
>> Cc: jagan at amarulasolutions.com; vigneshr at ti.com; u-kumar1 at ti.com;
>> trini at konsulko.com; seanga2 at gmail.com; caleb.connolly at linaro.org;
>> sjg at chromium.org; william.zhang at broadcom.com; stefan_b at posteo.net; git (AMD-
>> Xilinx) <git at amd.com>
>> Subject: Re: [PATCH] cadence_qspi: Refactor the flash reset functionality
>>
>>
>>
>> On 10/28/24 10:24, Venkatesh Yadav Abbarapu wrote:
>>> As the flash reset is handled in spi nor core, removing the flash
>>> reset functionality. As the configuration like tristate and hysterisis
>>> need to be enabled by the cdo. Handle the flash reset only for mini
>>> u-boot case.
>>>
>>> Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu at amd.com>
>>> ---
>>>    drivers/spi/cadence_ospi_versal.c | 43 -------------------------------
>>>    drivers/spi/cadence_qspi.c        |  7 +++--
>>>    2 files changed, 5 insertions(+), 45 deletions(-)
>>>
>>> diff --git a/drivers/spi/cadence_ospi_versal.c
>>> b/drivers/spi/cadence_ospi_versal.c
>>> index 222f828f54..de51e4c37f 100644
>>> --- a/drivers/spi/cadence_ospi_versal.c
>>> +++ b/drivers/spi/cadence_ospi_versal.c
>>> @@ -125,48 +125,6 @@ int cadence_qspi_apb_wait_for_dma_cmplt(struct
>> cadence_spi_priv *priv)
>>>    	return 0;
>>>    }
>>>
>>> -#if defined(CONFIG_DM_GPIO)
>>> -int cadence_qspi_versal_flash_reset(struct udevice *dev) -{
>>> -	struct gpio_desc gpio;
>>> -	u32 reset_gpio;
>>> -	int ret;
>>> -
>>> -	/* request gpio and set direction as output set to 1 */
>>> -	ret = gpio_request_by_name(dev, "reset-gpios", 0, &gpio,
>>> -				   GPIOD_IS_OUT | GPIOD_IS_OUT_ACTIVE);
>>> -	if (ret) {
>>> -		printf("%s: unable to reset ospi flash device", __func__);
>>> -		return ret;
>>> -	}
>>> -
>>> -	reset_gpio = PMIO_NODE_ID_BASE + gpio.offset;
>>> -
>>> -	/* Request for pin */
>>> -	xilinx_pm_request(PM_PINCTRL_REQUEST, reset_gpio, 0, 0, 0, NULL);
>>> -
>>> -	/* Enable hysteresis in cmos receiver */
>>> -	xilinx_pm_request(PM_PINCTRL_CONFIG_PARAM_SET, reset_gpio,
>>> -			  PM_PINCTRL_CONFIG_SCHMITT_CMOS,
>>> -			  PM_PINCTRL_INPUT_TYPE_SCHMITT, 0, NULL);
>>> -
>>> -	/* Disable Tri-state */
>>> -	xilinx_pm_request(PM_PINCTRL_CONFIG_PARAM_SET, reset_gpio,
>>> -			  PM_PINCTRL_CONFIG_TRI_STATE,
>>> -			  PM_PINCTRL_TRI_STATE_DISABLE, 0, NULL);
>>> -	udelay(1);
>>> -
>>> -	/* Set value 0 to pin */
>>> -	dm_gpio_set_value(&gpio, 0);
>>> -	udelay(1);
>>> -
>>> -	/* Set value 1 to pin */
>>> -	dm_gpio_set_value(&gpio, 1);
>>> -	udelay(1);
>>> -
>>> -	return 0;
>>> -}
>>> -#else
>>>    int cadence_qspi_versal_flash_reset(struct udevice *dev)
>>>    {
>>>    	/* CRP WPROT */
>>> @@ -209,7 +167,6 @@ int cadence_qspi_versal_flash_reset(struct udevice
>>> *dev)
>>>
>>>    	return 0;
>>>    }
>>> -#endif
>>>
>>>    void cadence_qspi_apb_enable_linear_mode(bool enable)
>>>    {
>>> diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
>>> index 9c466f8695..f8c3fe8428 100644
>>> --- a/drivers/spi/cadence_qspi.c
>>> +++ b/drivers/spi/cadence_qspi.c
>>> @@ -258,8 +258,11 @@ static int cadence_spi_probe(struct udevice *bus)
>>>    		if (priv->read_delay >= 0)
>>>    			priv->read_delay = -1;
>>>
>>> -	/* Reset ospi flash device */
>>> -	return cadence_qspi_versal_flash_reset(bus);
>>> +	if (!CONFIG_IS_ENABLED(DM_GPIO))
>>
>> I think this is not the right thing to do here.
>> Because there could be boards which requires to do some other GPIO handling out
>> of spi core. I think this patch is introducing limitation for nothing.
>>
>> I would keep origin code and just move this condition to
>> drivers/spi/cadence_ospi_versal.c
> 
> This function cadence_qspi_versal_flash_reset() is specific to AMD only.

yes I know and we shouldn't really bother generic code about it.
I think that function name should be more generic that other platforms can hook 
it up. But logic when versal requires this only when DM_GPIO is not enabled 
should be in vendor specific file.

M


More information about the U-Boot mailing list