Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Yuti Suresh Amonkar <yamonkar@cadence.com>
To:     Maxime Ripard <maxime@cerno.tech>
CC:     "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>,
        "praneeth@ti.com" <praneeth@ti.com>,
        "tomi.valkeinen@ti.com" <tomi.valkeinen@ti.com>,
        "jsarha@ti.com" <jsarha@ti.com>, Milind Parab <mparab@cadence.com>,
        Swapnil Kashinath Jakhade <sjakhade@cadence.com>,
        "kishon@ti.com" <kishon@ti.com>
Subject: RE: [PATCH v2] phy: Add DisplayPort configuration options
Thread-Topic: [PATCH v2] phy: Add DisplayPort configuration options
Thread-Index: AQHVuZarlyuLHgdLs0ymbXdtACZzt6fH9ueAgAE9e1A=
Date:   Tue, 24 Dec 2019 12:29:40 +0000
Message-ID: <BYAPR07MB51108A47A453B456F5F0D233D2290@BYAPR07MB5110.namprd07.prod.outlook.com>
References: <1577108473-29294-1-git-send-email-yamonkar@cadence.com>
 <20191223171849.yvofolswgvyfklry@hendrix.home>
In-Reply-To: <20191223171849.yvofolswgvyfklry@hendrix.home>
Accept-Language: en-IN, en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: cadence.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 57abde6d-9c1f-4172-ceb0-08d7886cf2a8
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Dec 2019 12:29:40.2520
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: d36035c5-6ce6-4662-a3dc-e762e61ae4c9
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: iL2d6qXZJ7X2Y0VAfpYDzwfAKNdpL5oLLKqBCJq86CmvDtoyVxisoS2SjT3UZ0oCc4HheX0z+lt6zwcpWfraYKKZM7/sJINX9l2aYaR84fk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR07MB4728
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572
 definitions=2019-12-24_03:2019-12-24,2019-12-24 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_check_notspam policy=outbound_check score=0 spamscore=0
 impostorscore=0 mlxscore=0 lowpriorityscore=0 malwarescore=0 bulkscore=0
 clxscore=1015 suspectscore=0 phishscore=0 mlxlogscore=999
 priorityscore=1501 adultscore=0 classifier=spam adjust=0 reason=mlx
 scancount=1 engine=8.12.0-1910280000 definitions=main-1912240110
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi,

> -----Original Message-----
> From: Maxime Ripard <maxime@cerno.tech>
> Sent: Monday, December 23, 2019 22:49
> To: Yuti Suresh Amonkar <yamonkar@cadence.com>
> Cc: linux-kernel@vger.kernel.org; dri-devel@lists.freedesktop.org;
> praneeth@ti.com; tomi.valkeinen@ti.com; jsarha@ti.com; Milind Parab
> <mparab@cadence.com>; Swapnil Kashinath Jakhade
> <sjakhade@cadence.com>
> Subject: Re: [PATCH v2] phy: Add DisplayPort configuration options
>=20
> EXTERNAL MAIL
>=20
>=20
> Hi,
>=20
> Please note that I don't have access to the displayPort spec, so I'll onl=
y
> comment on the content of that patch, not whether it's complete or not.
>=20
> On Mon, Dec 23, 2019 at 02:41:13PM +0100, Yuti Amonkar wrote:
> > Allow DisplayPort PHYs to be configured through the generic functions
> > through a custom structure added to the generic union.
> > The configuration structure is used for reconfiguration of DisplayPort
> > PHYs during link training operation.
> >
> > The parameters added here are the ones defined in the DisplayPort spec
> > 1.4 which include link rate, number of lanes, voltage swing and
> > pre-emphasis.
> >
> > Signed-off-by: Yuti Amonkar <yamonkar@cadence.com>
> > ---
> >
> > This patch was a part of [1] series earlier but we think that it needs
> > to have a separate attention of the reviewers. Also as both [1] & [2]
> > are dependent on this patch, our sincere request to reviewers to have
> > a faster review of this patch.
> >
> > [1]
> >
> > https://lkml.org/lkml/2019/12/11/455
> >
> > [2]
> >
> > https://patchwork.kernel.org/cover/11271191/
> >
> >  include/linux/phy/phy-dp.h | 95
> ++++++++++++++++++++++++++++++++++++++++++++++
> >  include/linux/phy/phy.h    |  4 ++
> >  2 files changed, 99 insertions(+)
> >  create mode 100644 include/linux/phy/phy-dp.h
> >
> > diff --git a/include/linux/phy/phy-dp.h b/include/linux/phy/phy-dp.h
> > new file mode 100644 index 0000000..18cad23
> > --- /dev/null
> > +++ b/include/linux/phy/phy-dp.h
> > @@ -0,0 +1,95 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Copyright (C) 2019 Cadence Design Systems Inc.
> > + */
> > +
> > +#ifndef __PHY_DP_H_
> > +#define __PHY_DP_H_
> > +
> > +#include <linux/types.h>
> > +
> > +/**
> > + * struct phy_configure_opts_dp - DisplayPort PHY configuration set
> > + *
> > + * This structure is used to represent the configuration state of a
> > + * DisplayPort phy.
> > + */
> > +struct phy_configure_opts_dp {
> > +	/**
> > +	 * @link_rate:
> > +	 *
> > +	 * Link Rate, in Mb/s, of the main link.
> > +	 *
> > +	 * Allowed values: 1620, 2160, 2430, 2700, 3240, 4320, 5400, 8100
> Mb/s
> > +	 */
> > +	unsigned int link_rate;
> > +
> > +	/**
> > +	 * @lanes:
> > +	 *
> > +	 * Number of active, consecutive, data lanes, starting from
> > +	 * lane 0, used for the transmissions on main link.
> > +	 *
> > +	 * Allowed values: 1, 2, 4
> > +	 */
> > +	unsigned int lanes;
> > +
> > +	/**
> > +	 * @voltage:
> > +	 *
> > +	 * Voltage swing levels, as specified by DisplayPort specification,
> > +	 * to be used by particular lanes. One value per lane.
> > +	 * voltage[0] is for lane 0, voltage[1] is for lane 1, etc.
> > +	 *
> > +	 * Maximum value: 3
> > +	 */
> > +	unsigned int voltage[4];
> > +
> > +	/**
> > +	 * @pre:
> > +	 *
> > +	 * Pre-emphasis levels, as specified by DisplayPort specification, to=
 be
> > +	 * used by particular lanes. One value per lane.
> > +	 *
> > +	 * Maximum value: 3
> > +	 */
> > +	unsigned int pre[4];
> > +
> > +	/**
> > +	 * @ssc:
> > +	 *
> > +	 * Flag indicating, whether or not to enable spread-spectrum
> clocking.
> > +	 *
> > +	 */
> > +	u8 ssc : 1;
> > +
> > +	/**
> > +	 * @set_rate:
> > +	 *
> > +	 * Flag indicating, whether or not reconfigure link rate and SSC to
> > +	 * requested values.
> > +	 *
> > +	 */
> > +	u8 set_rate : 1;
> > +
> > +	/**
> > +	 * @set_lanes:
> > +	 *
> > +	 * Flag indicating, whether or not reconfigure lane count to
> > +	 * requested value.
> > +	 *
> > +	 */
> > +	u8 set_lanes : 1;
> > +
> > +	/**
> > +	 * @set_voltages:
> > +	 *
> > +	 * Flag indicating, whether or not reconfigure voltage swing
> > +	 * and pre-emphasis to requested values. Only lanes specified
> > +	 * by "lanes" parameter will be affected.
> > +	 *
> > +	 */
> > +	u8 set_voltages : 1;
>=20
> I'm not quite sure what these flags are supposed to be doing, or what use=
-
> cases they cover. The current API is using validate to make sure that we =
can
> have a handshake between the caller and its PHY and must never apply the
> configuration, and configure must always apply the configuration. These
> flags look redundant.
>=20
> Maxime

These flags are used to reconfigure the link during the link training proce=
dure as described in DisplayPort spec. In this procedure , we may need to c=
onfigure only subset of parameters (VS, Pre-emphasis, link rate and num of =
lanes) depending on different phases. e.g. At one stage, we may need to con=
figure only Voltage swing and Pre-emphasis keeping number of lanes and link=
 rate intact(set_voltages=3Dtrue), while at other stage, we may need to con=
figure all parameters. We use the flags to determine which parameter is upd=
ated during link training. Using separate flags for this provides control t=
o upper layer.
I am not sure how to use validate to achieve this. As per my understanding =
validate is used to verify if set of parameters can be handled by PHY.

Thanks & Regards,
Yuti Amonkar