Re: [PATCH] iommu/qcom: add optional clock for TLB invalidate

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu 14 May 07:39 PDT 2020, Shawn Guo wrote:

> Hi Bjorn,
> 
> On Mon, May 11, 2020 at 10:52:42PM -0700, Bjorn Andersson wrote:
> > On Sat 09 May 06:08 PDT 2020, Shawn Guo wrote:
> > 
> > > On some SoCs like MSM8939 with A405 adreno, there is a gfx_tbu clock
> > > needs to be on while doing TLB invalidate. Otherwise, TLBSYNC status
> > > will not be correctly reflected, causing the system to go into a bad
> > > state.  Add it as an optional clock, so that platforms that have this
> > > clock can pass it over DT.
> > > 
> > > Signed-off-by: Shawn Guo <shawn.guo@xxxxxxxxxx>
> > > ---
> > >  drivers/iommu/qcom_iommu.c | 16 ++++++++++++++++
> > >  1 file changed, 16 insertions(+)
> > > 
> > > diff --git a/drivers/iommu/qcom_iommu.c b/drivers/iommu/qcom_iommu.c
> > > index 0e2a96467767..2f6c6da7d540 100644
> > > --- a/drivers/iommu/qcom_iommu.c
> > > +++ b/drivers/iommu/qcom_iommu.c
> > > @@ -45,6 +45,7 @@ struct qcom_iommu_dev {
> > >  	struct device		*dev;
> > >  	struct clk		*iface_clk;
> > >  	struct clk		*bus_clk;
> > > +	struct clk		*tlb_clk;
> > >  	void __iomem		*local_base;
> > >  	u32			 sec_id;
> > >  	u8			 num_ctxs;
> > > @@ -643,11 +644,20 @@ static int qcom_iommu_enable_clocks(struct qcom_iommu_dev *qcom_iommu)
> > >  		return ret;
> > >  	}
> > >  
> > > +	ret = clk_prepare_enable(qcom_iommu->tlb_clk);
> > > +	if (ret) {
> > > +		dev_err(qcom_iommu->dev, "Couldn't enable tlb_clk\n");
> > > +		clk_disable_unprepare(qcom_iommu->bus_clk);
> > > +		clk_disable_unprepare(qcom_iommu->iface_clk);
> > > +		return ret;
> > > +	}
> > 
> > Seems this is an excellent opportunity to replace
> > qcom_iommu_enable_clocks() to clk_bulk_prepare_enable() and disable,
> > respectively.
> 
> So we have two required and one optional clocks.  I guess we don't want
> to use clk_bulk_get_optional() to get all of them as optional.  So we
> will end up with getting clock with individual call and enabling/disabling
> with bulk version.  I'm personally not fond of this mixed style.  But if
> you really like this, I can change.
> 

I share your dislike for mixing them, but I do prefer it over the nasty
error handling we end up with in qcom_iommu_enable_clocks().

Regards,
Bjorn

> > 
> > > +
> > >  	return 0;
> > >  }
> > >  
> > >  static void qcom_iommu_disable_clocks(struct qcom_iommu_dev *qcom_iommu)
> > >  {
> > > +	clk_disable_unprepare(qcom_iommu->tlb_clk);
> > >  	clk_disable_unprepare(qcom_iommu->bus_clk);
> > >  	clk_disable_unprepare(qcom_iommu->iface_clk);
> > >  }
> > > @@ -839,6 +849,12 @@ static int qcom_iommu_device_probe(struct platform_device *pdev)
> > >  		return PTR_ERR(qcom_iommu->bus_clk);
> > >  	}
> > >  
> > > +	qcom_iommu->tlb_clk = devm_clk_get(dev, "tlb");
> > 
> > Wouldn't "tbu" be a better name for this clock? Given that seems the
> > actually be the hardware block you're clocking.
> 
> I was trying to emphasize the function of this clock.  But I agree that
> 'tbu' is a better name now.  I will change it in v2.
> 
> Thanks for the comments.
> 
> Shawn



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux