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:
signature.asc
Description: Digital signature
