devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pratyush Anand <pratyush.anand@st.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Mohit KUMAR DCG <Mohit.KUMAR@st.com>,
	spear-devel <spear-devel@list.st.com>,
	Kishon Vijay Abraham I <kishon@ti.com>,
	"linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>,
	Viresh Kumar <viresh.linux@gmail.com>, Tejun Heo <tj@kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH V3 6/8] SPEAr13xx: Fixup: Move SPEAr1340 SATA platform code to phy driver
Date: Fri, 31 Jan 2014 09:42:04 +0530	[thread overview]
Message-ID: <20140131041204.GC2618@pratyush-vbox> (raw)
In-Reply-To: <201401301421.00990.arnd@arndb.de>

On Thu, Jan 30, 2014 at 09:21:00PM +0800, Arnd Bergmann wrote:
> On Thursday 30 January 2014, Mohit Kumar wrote:
> > 
> > diff --git a/Documentation/devicetree/bindings/phy/spear13xx-miphy.txt b/Documentation/devicetree/bindings/phy/spear13xx-miphy.txt
> > new file mode 100644
> > index 0000000..208b37d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/spear13xx-miphy.txt
> > @@ -0,0 +1,8 @@
> > +Required properties:
> > +- compatible : should be "st,spear1340-sata-pcie-phy".
> 
> Just for confirmation: This phy is by design only capable of driving
> sata or pcie, but nothing else if reused in a different SoC, right?
> 
> If the phy is actually more generic than that, I'd suggest changing
> the name, otherwise it's ok.

OK, we will give a generic name as it can be used for sata/pcie/usb3.0.
Although, phy register definition may vary from version to version,
but that can be managed,as and when support of new soc is added. 

> 
> > +- reg : offset and length of the PHY register set.
> > +- misc: phandle for the syscon node to access misc registers
> > +- #phy-cells : from the generic PHY bindings, must be 2.
> > +	- 1st arg: phandle to the phy node.
> > +	- 2nd arg: 0 if phy (in 1st arg) is to be used for sata else 1.
> > +	- 3rd arg: Instance id of the phy (in 1st arg).
> 
> I would count "arg" differently: There are three cells, and the first
> cell is the phandle, while the second and third cells contain the first
> and second argument.

Ok..will modify accordingly.

> 
> The third cell seems redundant, more on that below.
> 
> > +		ahci0: ahci@b1000000 {
> >  			compatible = "snps,spear-ahci";
> >  			reg = <0xb1000000 0x10000>;
> >  			interrupts = <0 68 0x4>;
> > +			phys = <&miphy0 0 0>;
> > +			phy-names = "ahci-phy";
> >  			status = "disabled";
> >  		};
> >  
> > -		ahci@b1800000 {
> > +		ahci1: ahci@b1800000 {
> >  			compatible = "snps,spear-ahci";
> >  			reg = <0xb1800000 0x10000>;
> >  			interrupts = <0 69 0x4>;
> > +			phys = <&miphy1 0 1>;
> > +			phy-names = "ahci-phy";
> >  			status = "disabled";
> >  		};
> >  
> > -		ahci@b4000000 {
> > +		ahci2: ahci@b4000000 {
> >  			compatible = "snps,spear-ahci";
> >  			reg = <0xb4000000 0x10000>;
> >  			interrupts = <0 70 0x4>;
> > +			phys = <&miphy2 0 2>;
> > +			phy-names = "ahci-phy";
> >  			status = "disabled";
> >  		};
> 
> In each case, the number of the phy 'miphyX' is identical to the
> third cell, and I suspect this is by design. In the driver, the
> 'id' field is set in the xlate function, but I could not find any
> place where it actually gets used, so unless you know that it's
> needed, I'd suggest simply removing it.

It has not been used in this patch, as SATA support is currently only
for SPEAr1340, where we have only one instance.

Will be using it in PCIe for SPEAr1310 where 3 instances are present.

> 
> Even if you need it, it may be better to have the instance encoded
> in the phy node itself, since it's a property of the phy hardware
> (e.g. if you have to pass the number into a generic register that
> is global to all phys.

Ok..ll do that.

> 
> Alternatively, you could have a different representation, where you
> have a single DT device node representing all three PHYs, with
> "reg = <0xeb800000 0xc000>;" In that case, all sata devices would
> point to the same phy node and pass the instance id so the phy
> driver can operated the correct register set.

Instance ID is mainly needed to manipulate wrapper register present
within SPEAr13xx misc space. We have a single register in misc space
having bit fields controlling all 3 phys, and there we need this id.

> 
> > +static int spear1340_sata_miphy_init(struct spear13xx_phy_priv *phypriv)
> > +{
> > +	regmap_update_bits(phypriv->misc, SPEAR1340_PCIE_SATA_CFG,
> > +			SPEAR1340_PCIE_SATA_CFG_MASK, SPEAR1340_SATA_CFG_VAL);
> > +	regmap_update_bits(phypriv->misc, SPEAR1340_PCIE_MIPHY_CFG,
> > +			SPEAR1340_PCIE_MIPHY_CFG_MASK,
> > +			SPEAR1340_PCIE_SATA_MIPHY_CFG_SATA_25M_CRYSTAL_CLK);
> > +	/* Switch on sata power domain */
> > +	regmap_update_bits(phypriv->misc, SPEAR1340_PCM_CFG,
> > +			SPEAR1340_PCM_CFG_SATA_POWER_EN,
> > +			SPEAR1340_PCM_CFG_SATA_POWER_EN);
> > +	msleep(20);
> > +	/* Disable PCIE SATA Controller reset */
> > +	regmap_update_bits(phypriv->misc, SPEAR1340_PERIP1_SW_RST,
> > +			SPEAR1340_PERIP1_SW_RST_SATA, 0);
> > +	msleep(20);
> > +
> > +	return 0;
> > +}
> 
> I guess some of the parts above can eventually get moved into other
> drivers (reset controller, power domains) that get called directly
> by the SATA driver (e.g. though reset_device()). Since that won't
> impact the PHY binding, it seems fine to leave it here for now.

thanks :)

Regards
Pratyush
> 
> 	Arnd

  reply	other threads:[~2014-01-31  4:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-30 10:48 [PATCH V3 0/8] PCI:Add SPEAr13xx PCie support Mohit Kumar
     [not found] ` <cover.1391077731.git.mohit.kumar-qxv4g6HH51o@public.gmane.org>
2014-01-30 10:48   ` [PATCH V3 6/8] SPEAr13xx: Fixup: Move SPEAr1340 SATA platform code to phy driver Mohit Kumar
2014-01-30 13:21     ` Arnd Bergmann
2014-01-31  4:12       ` Pratyush Anand [this message]
2014-01-31 15:27         ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140131041204.GC2618@pratyush-vbox \
    --to=pratyush.anand@st.com \
    --cc=Mohit.KUMAR@st.com \
    --cc=arnd@arndb.de \
    --cc=devicetree@vger.kernel.org \
    --cc=kishon@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=spear-devel@list.st.com \
    --cc=tj@kernel.org \
    --cc=viresh.linux@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).