On Thu, Dec 08, 2016 at 12:04:21AM +0200, Jani Nikula wrote:
> On Wed, 07 Dec 2016, Manasi Navare wrote:
> > Hi Jani,
> >
> > Actually this patch is no longer valid, I have included a differnt interface
> > change with the link training patch series for calculating the
> > max_sink_link_rate
> >
On Wed, 07 Dec 2016, Manasi Navare wrote:
> Hi Jani,
>
> Actually this patch is no longer valid, I have included a differnt interface
> change with the link training patch series for calculating the
> max_sink_link_rate
> and max_sink_lane_count in the long pulse handler and not recompute
> it ev
Hi Jani,
Actually this patch is no longer valid, I have included a differnt interface
change with the link training patch series for calculating the
max_sink_link_rate
and max_sink_lane_count in the long pulse handler and not recompute
it everytime when the caller needs common_rates and lane_coun
On Fri, 02 Dec 2016, Manasi Navare wrote:
> Supported link rate common to source and sink as well as the
> maximum supported lane count based on source and sink capabilities should
> be set only once on hotplug and then used anytime they are requested.
> This patch creates and array of common rate
Jani,
This patch is in response to your feedback previously on the fallback link rate
patch.
You had mentioned that we should in the long run move the common rates array and
max lane count to intel_dp so that it gets computed only once on hotplug and
then
gets used whenever it is requested.
This
Supported link rate common to source and sink as well as the
maximum supported lane count based on source and sink capabilities should
be set only once on hotplug and then used anytime they are requested.
This patch creates and array of common rates and max lane count as the
intel_dp member. It get
