All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dilip Kota <eswara.kota@linux.intel.com>
To: Vinod Koul <vkoul@kernel.org>
Cc: linux-kernel@vger.kernel.org, kishon@ti.com,
	devicetree@vger.kernel.org, lee.jones@linaro.org, arnd@arndb.de,
	robh@kernel.org, andriy.shevchenko@intel.com,
	cheol.yong.kim@intel.com, chuanhua.lei@linux.intel.com,
	qi-ming.wu@intel.com, yixin.zhu@intel.com
Subject: Re: [PATCH v7 3/3] phy: intel: Add driver support for ComboPhy
Date: Tue, 5 May 2020 15:54:40 +0800	[thread overview]
Message-ID: <dd259c37-d273-44d3-c095-8618264e3a19@linux.intel.com> (raw)
In-Reply-To: <20200505052122.GW1375924@vkoul-mobl>


On 5/5/2020 1:21 PM, Vinod Koul wrote:
> On 04-05-20, 17:32, Dilip Kota wrote:
>> On 5/4/2020 5:20 PM, Vinod Koul wrote:
>>> On 04-05-20, 16:26, Dilip Kota wrote:
>>>> On 5/4/2020 3:29 PM, Vinod Koul wrote:
>>>>> On 30-04-20, 15:15, Dilip Kota wrote:
>>>>>
>>>>>> +					  u32 mask, u32 val)
>>>>>> +{
>>>>>> +	u32 reg_val;
>>>>>> +
>>>>>> +	reg_val = readl(base + reg);
>>>>>> +	reg_val &= ~mask;
>>>>>> +	reg_val |= FIELD_PREP(mask, val);
>>>>>> +	writel(reg_val, base + reg);
>>>>> bypassing regmap here... why?
>>>> It is not regmap address, one of the below two addresses are passed to this
>>>> function.
>>> okay, perhaps add a comment somewhere that regmap is not used for this
>>> base?
>> I dont see a need of adding a comment, describing don't do regmap here.
> Driver uses regmap except here, which seems odd hence explanation
> required for this.
During the driver Probe, the register phandles are stored in regmap 
datatype variables and PHY core addresses are stored in iomem datatype.
Since then, regmap access is performed for the regmap datatype variables 
and readl/writel access is performed on the iomem datatype variables. 
And nowhere in the driver iomem datatype address are converted to regmap 
address and performed regmap access.

Driver is not doing any 'regmap_init' on any physical address. Driver is 
getting the register address phandle from the device tree node and 
performing the regmap access.
ret = fwnode_property_get_reference_args(fwnode, "intel,syscfg", NULL, 
1, 0, &ref);
[...]
cbphy->syscfg = device_node_to_regmap(to_of_node(ref.fwnode));

[...]
ret = fwnode_property_get_reference_args(fwnode, "intel,hsio", NULL, 1, 
0, &ref);
[...]

cbphy->hsiocfg = device_node_to_regmap(to_of_node(ref.fwnode));

[...]
cbphy->app_base = devm_platform_ioremap_resource_byname(pdev, "app");
  [...]
cbphy->cr_base = devm_platform_ioremap_resource_byname(pdev, "core");

The DT parsing logic in the driver is explaining why the PHY driver 
should do regmap access and to whom should be done. For this reason i am 
a bit puzzled to what more is needed to explain in the comments and 
where to add it.
Please let me know your view.

Regards,
Dilip

  reply	other threads:[~2020-05-05  7:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-30  7:15 [PATCH v7 0/3] Add Intel ComboPhy driver Dilip Kota
2020-04-30  7:15 ` [PATCH v7 1/3] dt-bindings: phy: Add PHY_TYPE_XPCS definition Dilip Kota
2020-04-30  7:15 ` [PATCH v7 2/3] dt-bindings: phy: Add YAML schemas for Intel ComboPhy Dilip Kota
2020-04-30  7:15 ` [PATCH v7 3/3] phy: intel: Add driver support for ComboPhy Dilip Kota
2020-05-04  7:29   ` Vinod Koul
2020-05-04  8:26     ` Dilip Kota
2020-05-04  9:20       ` Vinod Koul
2020-05-04  9:32         ` Dilip Kota
2020-05-05  5:21           ` Vinod Koul
2020-05-05  7:54             ` Dilip Kota [this message]
2020-05-11 10:06               ` Dilip Kota
2020-04-30  8:25 ` [PATCH v7 0/3] Add Intel ComboPhy driver Lee Jones
2020-04-30  9:43   ` Dilip Kota
2020-04-30 10:09     ` Lee Jones

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=dd259c37-d273-44d3-c095-8618264e3a19@linux.intel.com \
    --to=eswara.kota@linux.intel.com \
    --cc=andriy.shevchenko@intel.com \
    --cc=arnd@arndb.de \
    --cc=cheol.yong.kim@intel.com \
    --cc=chuanhua.lei@linux.intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=kishon@ti.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=qi-ming.wu@intel.com \
    --cc=robh@kernel.org \
    --cc=vkoul@kernel.org \
    --cc=yixin.zhu@intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.