From: Kishon Vijay Abraham I <kishon@ti.com>
To: <merez@codeaurora.org>
Cc: <noag@codeaurora.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Specific PHYs operation for phy-core
Date: Wed, 2 Jul 2014 21:08:35 +0530 [thread overview]
Message-ID: <53B4277B.9070707@ti.com> (raw)
In-Reply-To: <7e6c972220e74f67cedd3aa55d61113c.squirrel@www.codeaurora.org>
Hi,
On Friday 20 June 2014 02:38 AM, merez@codeaurora.org wrote:
> Hi,
>
> We would like to use the phy-core framework for the UFS PHY implementation
> and we would appreciate your help with the following questions:
> 1. Our initialization sequence includes going back and forth operations
> between the core and the PHY. Due to that, the "init" function alone
> cannot hold the complete initialization sequence.
> The options we could think of are either add pre_init and post_init
> functions or add PHY specific functions.
pre-init and post-init seems to be too generic to be used. Would like 'ops'
that is more clearly defined (like 'reset' ops or 'calibrate' ops apart from
other existing ones where you know what should be done in the callback). If you
can explain what exact operations you are talking about we can see if it can be
fit in any existing or new generic ops.
> How do you recommend to resolve such a case?
> Have you thought about a way to expose PHY specific functions?
Exposing PHY specific functions are not recommended (since it is like ioctl)
and can be abused easily.
>
> 2. Our core needs to check if the PCS (Physical Coding Sublayer) is ready
> as part of its flow. As this is a term that is present in almost all the
> serial PHYs, can we add is_pcs_ready() API to the generic PHY ops?
> If not, how do you recommend to resolve this?
yeah, was thinking about adding states to PHY since it looks to have other uses
apart from your use case. Something like PHY_STATE_DEFAULT, PHY_STATE_INIT,
PHY_STATE_POWERED, PHY_STATE_READY etc.. Then we can have phy_get_state to see
if the PHY is ready or not.
>
> I would appreciate your prompt response as we would like to close the
> design by Monday.
ah.. sorry.
Cheers
Kishon
parent reply other threads:[~2014-07-02 15:38 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <7e6c972220e74f67cedd3aa55d61113c.squirrel@www.codeaurora.org>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53B4277B.9070707@ti.com \
--to=kishon@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=merez@codeaurora.org \
--cc=noag@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox