linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sylwester Nawrocki <s.nawrocki@samsung.com>
To: Vivek Gautam <gautam.vivek@samsung.com>
Cc: Linux USB Mailing List <linux-usb@vger.kernel.org>,
	"linux-samsung-soc@vger.kernel.org" 
	<linux-samsung-soc@vger.kernel.org>, kishon <kishon@ti.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-doc@vger.kernel.org,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	Greg KH <gregkh@linuxfoundation.org>, Felipe Balbi <balbi@ti.com>,
	Kukjin Kim <kgene.kim@samsung.com>,
	Tomasz Figa <t.figa@samsung.com>,
	Kamil Debski <k.debski@samsung.com>
Subject: Re: [PATCH v7 1/2] phy: Add new Exynos5 USB 3.0 PHY driver
Date: Fri, 09 May 2014 12:13:35 +0200	[thread overview]
Message-ID: <536CAA4F.8050404@samsung.com> (raw)
In-Reply-To: <CAFp+6iF=Z_dkd+YJm2-ODmvgZ6PCt+bUx+vSVm_5RtobVN0WfA@mail.gmail.com>

Hi Vivek,

On 08/05/14 11:03, Vivek Gautam wrote:
>>>> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>>> >>> index b422e38..51efe4c 100644
>>>> >>> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>>> >>> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>>> >>> @@ -114,3 +114,43 @@ Example:
>>>> >>>               compatible = "samsung,exynos-sataphy-i2c";
>>>> >>>               reg = <0x38>;
>>>> >>>       };
>>>> >>> +
>>>> >>> +Samsung Exynos5 SoC series USB DRD PHY controller
>>>> >>> +--------------------------------------------------
>>>> >>> +
>>>> >>> +Required properties:
>>>> >>> +- compatible : Should be set to one of the following supported values:
>>>> >>> +     - "samsung,exynos5250-usbdrd-phy" - for exynos5250 SoC,
>>>> >>> +     - "samsung,exynos5420-usbdrd-phy" - for exynos5420 SoC.
>>>> >>> +- reg : Register offset and length of USB DRD PHY register set;
>>>> >>> +- clocks: Clock IDs array as required by the controller
>>>> >>> +- clock-names: names of clocks correseponding to IDs in the clock property;
>>>> >>> +            Required clocks:
>>>> >>> +     - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock),
>>>> >>> +            used for register access.
>>>> >>> +     - ref: PHY's reference clock (usually crystal clock), used for
>>>> >>> +            PHY operations, associated by phy name. It is used to
>>>> >>> +            determine bit values for clock settings register.
>>>> >>> +            For Exynos5420 this is given as 'sclk_usbphy30' in CMU.
>>>> >>> +- samsung,pmu-syscon: phandle for PMU system controller interface, used to
>>>> >>> +                   control pmu registers for power isolation.
>>>> >>> +- samsung,pmu-offset: phy power control register offset to pmu-system-controller
>>>> >>> +                   base.
>>> >>
>>> >> It doesn't seem right to have register offset encoded in the device tree
>>> >> like this. I think it'd be more appropriate to associate such an offset
>>> >> with the compatible string's value in the driver.
>> >
>> > Ok, it makes more sense.
>> > Just out of curiosity, what difference would this make ?
>
> Moreover, in case of Exynos5420 (and may be in future SoCs), where we
> have 2 USB DRD PHY controllers,
> we will need to have a way around to deal with two separate offsets in
> the driver for one compatible string.

It could be handled by creating a list of offsets per compatible string and
then adding some way to identify the PHY device instance. So I believe that's
not a big issue. Now you'd be encoding a list of registers offsets in the
device tree, without encoding bit layout of each register. It's unlikely that
each instance would have different bits layout, but describing individual 
registers in DT I thought is something that we're not supposed to do.
 
> Getting the offsets from DT seems a cleaner way to handle this case of
> multi controllers.

I think it's easier from the driver POV, but isn't it violating the device
tree rules ?
Anyway. I'm just pointing this minor issue in the binding as it appears
to me. The final word of course belongs to a DT binding maintainer.

Regards,
-- 
Sylwester Nawrocki
Samsung R&D Institute Poland

  parent reply	other threads:[~2014-05-09 10:13 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-28  6:17 [PATCH v7 1/2] phy: Add new Exynos5 USB 3.0 PHY driver Vivek Gautam
2014-04-28  6:17 ` [PATCH v7 2/2] phy: exynos5-usbdrd: Add facility for VBUS supply Vivek Gautam
2014-04-30  3:24 ` [PATCH v7 1/2] phy: Add new Exynos5 USB 3.0 PHY driver Vivek Gautam
2014-05-06 13:49   ` Kishon Vijay Abraham I
2014-05-06 14:27 ` Sylwester Nawrocki
2014-05-08  6:05   ` Vivek Gautam
2014-05-08  9:03     ` Vivek Gautam
2014-05-09  9:36       ` Tomasz Figa
2014-05-09 10:13       ` Sylwester Nawrocki [this message]
2014-05-09 10:51         ` Vivek Gautam
2014-05-09 13:55           ` Vivek Gautam

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=536CAA4F.8050404@samsung.com \
    --to=s.nawrocki@samsung.com \
    --cc=balbi@ti.com \
    --cc=devicetree@vger.kernel.org \
    --cc=gautam.vivek@samsung.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=k.debski@samsung.com \
    --cc=kgene.kim@samsung.com \
    --cc=kishon@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=t.figa@samsung.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).