RE: [RFC PATCH] drivers: ata: Read Rx water mark value from device-tree

[Anurag Kumar Vulisha]

Hi Arnd,

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@xxxxxxxx]
> Sent: Monday, February 22, 2016 8:50 PM
> To: Anurag Kumar Vulisha
> Cc: robh+dt@xxxxxxxxxx; pawel.moll@xxxxxxx; mark.rutland@xxxxxxx;
> ijc+devicetree@xxxxxxxxxxxxxx; galak@xxxxxxxxxxxxxx; tj@xxxxxxxxxx;
> devicetree@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; linux-
> ide@xxxxxxxxxxxxxxx; Anirudha Sarangi; Srikanth Vemula; Punnaiah Choudary
> Kalluri
> Subject: Re: [RFC PATCH] drivers: ata: Read Rx water mark value from device-
> tree
>
> On Monday 22 February 2016 10:53:11 Anurag Kumar Vulisha wrote:
> > > >
> > >
> > > How would a hardware integrator know which value is right for a
> > > particular SoC?
> > >
> > > Could it be keyed off the hardware ID? Could the bootloader perhaps
> > > set an appropriate value in the AHCI_VEND_PTC register at boot time
> > > and the driver read the initial value from it?
> > >
> > > From the description, it sounds like this is a policy decision
> > > rather than hardware description, and shouldn't really be in here.
> > >
> >
> > Thanks for reviewing the patch. Can I use module_param() for this
> > watermark instead of reading it from devicetree or doing it in
> > bootloader. In bootloader we are initializing serdes controller for
> > high speed devices. As a part of this initialization we will be reseting all the
> high speed pheripherals which are using serdes, so SATA will also get
> resetted. Because of this reason, can I use module_param() for Rxwatermark
> value  instead?
> >
>
> I don't know what is appropriate because I have no idea what Rxwatermark is
> good for. Can you try describing why we can't just set it to the correct value
> for everyone automatically?
>

This RX watermark level sets the minimum number of free locations within the RX FIFO .When the rx fifo level crosses the programmed watermark level ,sata controller  will transmit HOLDS to the device asking it to wait. This happens when dma
reads the rx fifo data slower than the device is sending the data. Note that it can take some time for the HOLDs to get to
the other end and in the time there must be enough room in the FIFO to absorb all data that could arrive from the device.
Currently we are using 0x40 for this value, which works fine with all hardware designs  we are currently having. But hoping
that this value may vary for future silicon versions, I wanted to make this as a configurable value. So for this reason I thought
of moving it either to device-tree or making it as a module_param() property.

Thanks,
Anurag Kumar V

>       Arnd


This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.