Messages in this thread | | | Date | Wed, 20 Feb 2013 13:11:12 +0000 | From | Mark Brown <> | Subject | Re: [PATCH] spi: tegra114: add spi driver |
| |
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. [unhandled content-type:application/pgp-signature] | |