[PATCH] ata: sata_mv: setting PHY speed according to SControl speed

Lior Amsalem alior at marvell.com
Wed Jan 8 08:45:31 EST 2014


Hi Andrew,

> From: Andrew Lunn [mailto:andrew at lunn.ch]
> Sent: Tuesday, December 31, 2013 7:05 PM
> 
> On Tue, Dec 31, 2013 at 07:12:14AM -0500, Tejun Heo wrote:
> > On Mon, Dec 23, 2013 at 01:07:35PM +0100, Simon Guinot wrote:
> > > @@ -1358,6 +1359,7 @@ static int mv_scr_write(struct ata_link *link,
> > > unsigned int sc_reg_in, u32 val)
> > >
> > >  	if (ofs != 0xffffffffU) {
> > >  		void __iomem *addr = mv_ap_base(link->ap) + ofs;
> > > +		void __iomem *lp_phy_addr = mv_ap_base(link->ap) +
> LP_PHY_CTL;
> > >  		if (sc_reg_in == SCR_CONTROL) {
> > >  			/*
> > >  			 * Workaround for 88SX60x1 FEr SATA#26:
> > > @@ -1374,6 +1376,14 @@ static int mv_scr_write(struct ata_link *link,
> unsigned int sc_reg_in, u32 val)
> > >  			 */
> > >  			if ((val & 0xf) == 1 || (readl(addr) & 0xf) == 1)
> > >  				val |= 0xf000;
> > > +
> > > +			/*
> > > +			 * Setting PHY speed according to SControl speed
> > > +			 */
> > > +			if ((val & 0xf0) == 0x10)
> > > +				writelfl(0x7, lp_phy_addr);
> > > +			else
> > > +				writelfl(0x227, lp_phy_addr);
> >
> > Do we know that this is safe for all sata_mvs?  If other sata_mvs
> > haven't had the described issue, maybe this should be applied
> > selectively to the said soc?  I'd actually prefer to avoid such
> > conditionals but we need to confirm this is okay for other
> > implementations.
> 
> Hi Tejun
> 
> I've tested on Kirkwood, and not had problems. But i agree with you. We
> need somebody in Marvell to say this is safe with all sata_mv variants.
> 
> Lior, can you comment?

This register (0x58) was introduced in a370/axp (with a new SATA PHY version).
In other SoCs the register does not exist.

Writing/reading the registers on A300/A310 will not cause any harm (I haven't
tried A510).
But, I think it's better to check if we're running on A370/AXP. (maybe with a new
compatibility string in DT?)

> 
> Thanks
> 	Andrew


Regards,
Lior Amsalem




More information about the linux-arm-kernel mailing list