On Tuesday 13 November 2012 10:55 PM, Stephen Warren wrote:
> On 11/12/2012 10:00 PM, Laxman Dewangan wrote:
>
>> +static int tegra_sflash_resume(struct device *dev)
>> +{
>> + struct spi_master *master = dev_get_drvdata(dev);
>> + struct tegra_sflash_data *tsd = spi_master_get_devdata(master);
>> + int ret;
>> +
>> + ret = pm_runtime_get_sync(dev);
>> + if (ret< 0) {
>> + dev_err(dev, "pm runtime failed, e = %d\n", ret);
>> + return ret;
>> + }
>> + tegra_sflash_writel(tsd, tsd->command_reg, SPI_COMMAND);
>> + pm_runtime_put(dev);
> Can we avoid this whole function simply by programming SPI_COMMAND at
> the start of each transaction? That seems simpler. I assume that
> shouldn't e.g. leave any chip-selects in some bad state, or at least if
> it does, that shouldn't be a problem, because before the driver probes()
> at kernel boot, SPI_COMMAND won't have been programmed either.
>
> Aside from that,
I am not sure about the side effect of moving this to transfer but I can
suspect:
When client driver is active, it need the proper state of CS. If we move
this to transfer then probbaly CS is not in proper state until client
calls the transfer function and this is not correct. The CS should be
inactive state for all devices in non-transfer states.
> Acked-by: Stephen Warren<[email protected]>
> Tested-by: Stephen Warren<[email protected]>
Thanks for testing. I will respin patch V2 for taking care of above
comments.
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
spi-devel-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
