Re: [PATCH] spi: tegra114: add spi driver

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

[-- Attachment #1: Type: text/plain, Size: 1296 bytes --]

On Wed, Feb 20, 2013 at 05:59:03PM +0530, Laxman Dewangan wrote:
> On Tuesday 19 February 2013 11:46 PM, Stephen Warren wrote:

> >In the older Tegra SPI drivers, the PM runtime logic was was of
> >master->{un,}prepare_transfer. I'm curious why it's implemented
> >differently here.

> The prepare  is called in atomic context and in this we are calling
> pm_runtime_get_sync() which is blocking and it can cause issue.

> I have already bug reported by you that sometimes you saw locking in
> tegra20 slink driver which we need to fix. When testing this, I ran
> into similar case and hence now moving this out or prepare.

> I will push the change for fixing this in tegra20_slink driver also.

As I think I've said before I keep thinking we ought to just have some
basic runtime PM code in the core - a substantial proportion of drivers
end up following the same pattern, it'd be surprising to see hardware
that needed a different pattern.

> >>+	tspi->clk = devm_clk_get(&pdev->dev, "spi");

> >Does this HW block use multiple clocks? If not, I think s/"spi"/NULL/
> >there, just like the Tegra20 driver.

> No, spi controller uses the only one clock. I will change to NULL.

I'm never convinced that NULL is a helpful clock name to pick, it's not
awesome if you ever acquire a second clock.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]