Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v1 2/2] phy: phy-cadence-torrent: Use PHY kernel APIs to
 set PHY attributes
To:     Maxime Ripard <maxime@cerno.tech>,
        Swapnil Kashinath Jakhade <sjakhade@cadence.com>
CC:     Yuti Suresh Amonkar <yamonkar@cadence.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "kishon@ti.com" <kishon@ti.com>,
        "mark.rutland@arm.com" <mark.rutland@arm.com>,
        "jsarha@ti.com" <jsarha@ti.com>,
        "praneeth@ti.com" <praneeth@ti.com>,
        Milind Parab <mparab@cadence.com>
References: <1588057804-29161-1-git-send-email-yamonkar@cadence.com>
 <1588057804-29161-3-git-send-email-yamonkar@cadence.com>
 <20200429122750.hup7vbmz3xnpfwa5@gilmour.lan>
 <BY5PR07MB69827A1E2136455BFDD6090BC5AA0@BY5PR07MB6982.namprd07.prod.outlook.com>
 <20200507171738.atzyfpueo6bjbwpb@gilmour.lan>
From:   Tomi Valkeinen <tomi.valkeinen@ti.com>
Message-ID: <f6e0566a-8e15-5c55-3167-6a1526c37be7@ti.com>
Date:   Fri, 8 May 2020 10:50:10 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200507171738.atzyfpueo6bjbwpb@gilmour.lan>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 07/05/2020 20:17, Maxime Ripard wrote:

>> Actually, for this particular case, consumer driver will be the Cadence MHDP
>> bridge driver for DisplayPort which is also under review process for
>> upstreaming [1]. So this DRM bridge driver will make use of the PHY APIs
>> phy_get_bus_width() and phy_get_max_link_rate() during execution of probe
>> function to get the number of lanes and maximum link rate supported by Cadence
>> Torrent PHY. This information is required to set the host capabilities in the
>> DRM bridge driver, based on which initial values for DisplayPort link training
>> will be determined.
>>
>> The changes in this PHY patch series are based on suggestions in the review
>> comments in [1] which asks to use kernel PHY APIs to read these properties
>> instead of directly accessing PHY device node. The complete driver and actual
>> use of these APIs can be found in [2]. This is how we are planning to use
>> these APIs.
> 
> I haven't really looked into the displayport spec, but I'd assume that there's a
> lot more parameters that would need to be negociated between the phy and the DP
> block? If so, then it would make more sense to follow the path we did for
> MIPI-DSI where the parameters can be negociated through the phy_configure /
> phy_validate interface.

I don't think this is negotiation, but just exposing the (max) capabilities of PHY, inside which the 
configure can work. Maybe all the capabilities could handled with a struct (struct phy_attrs), 
instead of adding separate functions for each, though.

  Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki