[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c7fd841b2244cbe60e174be3babb1607@walle.cc>
Date: Tue, 30 Aug 2022 09:09:58 +0200
From: Michael Walle <michael@...le.cc>
To: "Potthuri, Sai Krishna" <sai.krishna.potthuri@....com>
Cc: Tudor Ambarus <tudor.ambarus@...rochip.com>,
Pratyush Yadav <pratyush@...nel.org>,
Miquel Raynal <miquel.raynal@...tlin.com>,
Richard Weinberger <richard@....at>,
Vignesh Raghavendra <vigneshr@...com>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
devicetree@...r.kernel.org, linux-mtd@...ts.infradead.org,
linux-kernel@...r.kernel.org, saikrishna12468@...il.com,
"git (AMD-Xilinx)" <git@....com>
Subject: Re: [PATCH 2/2] mtd: spi-nor: Add support for flash reset
Hi,
Am 2022-08-30 08:32, schrieb Potthuri, Sai Krishna:
>> > + if (ret)
>> > + return ret;
>> > +
>> > + /*
>> > + * Experimental Minimum Chip select high to Reset delay value
>> > + * based on the flash device spec.
>> > + */
>>
>> Which flash device spec?
> I referred some of the qspi, ospi flash vendors datasheets like Micron,
> Macronix, ISSI, gigadevice, spansion.
Please mention here that you've looked at datasheets of different
vendors.
And maybe instead of doing three comments, just one and then the reset
sequence.
>>
>> > + usleep_range(1, 5);
>> > + gpiod_set_value(reset, 0);
>>
>> Mh, is your logic inverted here? If I read the code correctly,
>> you should use a value of 1 to take the device into reset. The
>> device tree should then have a flag "active low", which will
> Reset Sequence which I implemented here is high(1)->low(0)->high(1).
> By doing this sequence (active low), flash device is getting reset,
> this sequence
> is tested using Octal SPI flash device.
How does the device tree property for your look like?
Has it the GPIO_ACTIVE_LOW flag set?
-michael
Powered by blists - more mailing lists