All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roger Quadros <rogerq@ti.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: devicetree@vger.kernel.org, Samuel Ortiz <sameo@linux.intel.com>,
	tony@atomide.com, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org, balbi@ti.com, "Kristo,
	Tero" <t-kristo@ti.com>,
	bcousson@baylibre.com, linux-omap@vger.kernel.org,
	Lee Jones <lee.jones@linaro.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 1/5] mfd: omap-usb-host: Update DT clock binding information
Date: Wed, 8 Jan 2014 15:57:19 +0530	[thread overview]
Message-ID: <52CD2807.9000200@ti.com> (raw)
In-Reply-To: <4812867.NuB3hNkV9d@wuerfel>

On 01/08/2014 03:49 PM, Arnd Bergmann wrote:
> On Wednesday 08 January 2014 15:39:36 Roger Quadros wrote:
>>> What about the other clocks acquired in drivers/mfd/omap-usb-host.c? Shouldn't
>>> all of those be provided by via the DT phandle?
>>>
>>
>> All those clocks are identically named across the OMAP SoCs and are unique for each
>> SoC, so providing DT phandle for all of them is not required.
>>
>> The init_60m_fclk was renamed to l3init_60m_fclk in OMAP5, and hence the need for
>> this binding.
> 
> What do you mean it was renamed? Is it a different version of the omap-usb-host
> device then?

I meant the clock gates name on the SoC was renamed. The omap-usb-host device version
is revised as well.

>>> Should the clk_get be changed to of_clk_get()/of_clk_get_by_name() in the
>>> driver? This would potentially remove the need of the init_60m_fclk name.
>>>
>>
>> If we use of_clk_xxx() then we'll need to update DT nodes for OMAP4 and OMAP3 as
>> well to explicitly provide the clock phandle. For now we make use of the fact that
>> SoC clock data names the clock rightly i.e. "init_60m_fclk".
> 
> I'm getting the feeling that init_60m_fclk is not the name of the clock input
> of the omap-usb-host device at all, but rather the name of a signal on the
> omap soc, which would not be an appropriate identifier for the binding.

It is a clock gate defined like so in the DT clock data

on OMAP4
        init_60m_fclk: init_60m_fclk {
                #clock-cells = <0>;
                compatible = "ti,divider-clock";
                clocks = <&dpll_usb_m2_ck>;
                reg = <0x0104>;
                ti,dividers = <1>, <8>;
        };

on OMAP5
        l3init_60m_fclk: l3init_60m_fclk {
                #clock-cells = <0>;
                compatible = "ti,divider-clock";
                clocks = <&dpll_usb_m2_ck>;
                reg = <0x0104>;
                ti,dividers = <1>, <8>;
        };

So you can see that it is the same thing with a different name.

cheers,
-roger

WARNING: multiple messages have this Message-ID (diff)
From: rogerq@ti.com (Roger Quadros)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 1/5] mfd: omap-usb-host: Update DT clock binding information
Date: Wed, 8 Jan 2014 15:57:19 +0530	[thread overview]
Message-ID: <52CD2807.9000200@ti.com> (raw)
In-Reply-To: <4812867.NuB3hNkV9d@wuerfel>

On 01/08/2014 03:49 PM, Arnd Bergmann wrote:
> On Wednesday 08 January 2014 15:39:36 Roger Quadros wrote:
>>> What about the other clocks acquired in drivers/mfd/omap-usb-host.c? Shouldn't
>>> all of those be provided by via the DT phandle?
>>>
>>
>> All those clocks are identically named across the OMAP SoCs and are unique for each
>> SoC, so providing DT phandle for all of them is not required.
>>
>> The init_60m_fclk was renamed to l3init_60m_fclk in OMAP5, and hence the need for
>> this binding.
> 
> What do you mean it was renamed? Is it a different version of the omap-usb-host
> device then?

I meant the clock gates name on the SoC was renamed. The omap-usb-host device version
is revised as well.

>>> Should the clk_get be changed to of_clk_get()/of_clk_get_by_name() in the
>>> driver? This would potentially remove the need of the init_60m_fclk name.
>>>
>>
>> If we use of_clk_xxx() then we'll need to update DT nodes for OMAP4 and OMAP3 as
>> well to explicitly provide the clock phandle. For now we make use of the fact that
>> SoC clock data names the clock rightly i.e. "init_60m_fclk".
> 
> I'm getting the feeling that init_60m_fclk is not the name of the clock input
> of the omap-usb-host device at all, but rather the name of a signal on the
> omap soc, which would not be an appropriate identifier for the binding.

It is a clock gate defined like so in the DT clock data

on OMAP4
        init_60m_fclk: init_60m_fclk {
                #clock-cells = <0>;
                compatible = "ti,divider-clock";
                clocks = <&dpll_usb_m2_ck>;
                reg = <0x0104>;
                ti,dividers = <1>, <8>;
        };

on OMAP5
        l3init_60m_fclk: l3init_60m_fclk {
                #clock-cells = <0>;
                compatible = "ti,divider-clock";
                clocks = <&dpll_usb_m2_ck>;
                reg = <0x0104>;
                ti,dividers = <1>, <8>;
        };

So you can see that it is the same thing with a different name.

cheers,
-roger

WARNING: multiple messages have this Message-ID (diff)
From: Roger Quadros <rogerq@ti.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: <bcousson@baylibre.com>, <tony@atomide.com>, <balbi@ti.com>,
	<linux-omap@vger.kernel.org>, <linux-usb@vger.kernel.org>,
	<devicetree@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, Lee Jones <lee.jones@linaro.org>,
	Samuel Ortiz <sameo@linux.intel.com>,
	"Kristo, Tero" <t-kristo@ti.com>
Subject: Re: [PATCH v4 1/5] mfd: omap-usb-host: Update DT clock binding information
Date: Wed, 8 Jan 2014 15:57:19 +0530	[thread overview]
Message-ID: <52CD2807.9000200@ti.com> (raw)
In-Reply-To: <4812867.NuB3hNkV9d@wuerfel>

On 01/08/2014 03:49 PM, Arnd Bergmann wrote:
> On Wednesday 08 January 2014 15:39:36 Roger Quadros wrote:
>>> What about the other clocks acquired in drivers/mfd/omap-usb-host.c? Shouldn't
>>> all of those be provided by via the DT phandle?
>>>
>>
>> All those clocks are identically named across the OMAP SoCs and are unique for each
>> SoC, so providing DT phandle for all of them is not required.
>>
>> The init_60m_fclk was renamed to l3init_60m_fclk in OMAP5, and hence the need for
>> this binding.
> 
> What do you mean it was renamed? Is it a different version of the omap-usb-host
> device then?

I meant the clock gates name on the SoC was renamed. The omap-usb-host device version
is revised as well.

>>> Should the clk_get be changed to of_clk_get()/of_clk_get_by_name() in the
>>> driver? This would potentially remove the need of the init_60m_fclk name.
>>>
>>
>> If we use of_clk_xxx() then we'll need to update DT nodes for OMAP4 and OMAP3 as
>> well to explicitly provide the clock phandle. For now we make use of the fact that
>> SoC clock data names the clock rightly i.e. "init_60m_fclk".
> 
> I'm getting the feeling that init_60m_fclk is not the name of the clock input
> of the omap-usb-host device at all, but rather the name of a signal on the
> omap soc, which would not be an appropriate identifier for the binding.

It is a clock gate defined like so in the DT clock data

on OMAP4
        init_60m_fclk: init_60m_fclk {
                #clock-cells = <0>;
                compatible = "ti,divider-clock";
                clocks = <&dpll_usb_m2_ck>;
                reg = <0x0104>;
                ti,dividers = <1>, <8>;
        };

on OMAP5
        l3init_60m_fclk: l3init_60m_fclk {
                #clock-cells = <0>;
                compatible = "ti,divider-clock";
                clocks = <&dpll_usb_m2_ck>;
                reg = <0x0104>;
                ti,dividers = <1>, <8>;
        };

So you can see that it is the same thing with a different name.

cheers,
-roger

  reply	other threads:[~2014-01-08 10:27 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-08  6:15 [PATCH v4 0/5] USB Host support for OMAP5 uEVM (for 3.14) Roger Quadros
2014-01-08  6:15 ` Roger Quadros
2014-01-08  6:15 ` Roger Quadros
2014-01-08  6:15 ` [PATCH v4 1/5] mfd: omap-usb-host: Update DT clock binding information Roger Quadros
2014-01-08  6:15   ` Roger Quadros
2014-01-08  6:15   ` Roger Quadros
2014-01-08  9:08   ` Sebastian Reichel
2014-01-08  9:08     ` Sebastian Reichel
     [not found]     ` <20140108090808.GB16313-SfvFxonMDyemK9LvCR3Hrw@public.gmane.org>
2014-01-08 10:09       ` Roger Quadros
2014-01-08 10:09         ` Roger Quadros
2014-01-08 10:09         ` Roger Quadros
2014-01-08 10:19         ` Arnd Bergmann
2014-01-08 10:19           ` Arnd Bergmann
2014-01-08 10:19           ` Arnd Bergmann
2014-01-08 10:27           ` Roger Quadros [this message]
2014-01-08 10:27             ` Roger Quadros
2014-01-08 10:27             ` Roger Quadros
2014-01-08 10:40             ` Arnd Bergmann
2014-01-08 10:40               ` Arnd Bergmann
2014-01-08 10:40               ` Arnd Bergmann
2014-01-08 11:04               ` Roger Quadros
2014-01-08 11:04                 ` Roger Quadros
2014-01-08 11:04                 ` Roger Quadros
2014-01-08 10:52         ` Sebastian Reichel
2014-01-08 10:52           ` Sebastian Reichel
2014-01-08 10:52           ` Sebastian Reichel
2014-01-08 10:55           ` Arnd Bergmann
2014-01-08 10:55             ` Arnd Bergmann
2014-01-08 10:55             ` Arnd Bergmann
2014-01-08 11:11             ` Roger Quadros
2014-01-08 11:11               ` Roger Quadros
2014-01-08 11:11               ` Roger Quadros
2014-01-08 11:35               ` Arnd Bergmann
2014-01-08 11:35                 ` Arnd Bergmann
     [not found]                 ` <201401081235.40927.arnd-r2nGTMty4D4@public.gmane.org>
2014-01-08 11:48                   ` Roger Quadros
2014-01-08 11:48                     ` Roger Quadros
2014-01-08 11:48                     ` Roger Quadros
2014-01-08  9:56   ` Mark Rutland
2014-01-08  9:56     ` Mark Rutland
2014-01-08  9:56     ` Mark Rutland
2014-01-08 10:12     ` Roger Quadros
2014-01-08 10:12       ` Roger Quadros
2014-01-08  6:15 ` [PATCH v4 3/5] ARM: dts: omap4-panda: Provide USB PHY clock Roger Quadros
2014-01-08  6:15   ` Roger Quadros
2014-01-08  6:15   ` Roger Quadros
     [not found] ` <1389161742-10533-1-git-send-email-rogerq-l0cyMroinI0@public.gmane.org>
2014-01-08  6:15   ` [PATCH v4 2/5] ARM: dts: OMAP5: Add 60MHz clock reference to USB Host module Roger Quadros
2014-01-08  6:15     ` Roger Quadros
2014-01-08  6:15     ` Roger Quadros
2014-01-08  6:15   ` [PATCH v4 4/5] ARM: dts: omap5-uevm: Provide USB PHY clock Roger Quadros
2014-01-08  6:15     ` Roger Quadros
2014-01-08  6:15     ` Roger Quadros
2014-01-08  6:15 ` [PATCH v4 5/5] ARM: OMAP2+: Remove legacy_init_ehci_clk() Roger Quadros
2014-01-08  6:15   ` Roger Quadros
2014-01-08  6:15   ` Roger Quadros
     [not found] ` <52CE824D.2090905@virtualopensystems.com>
     [not found]   ` <52CE824D.2090905-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
2014-01-09 11:08     ` [PATCH v4 0/5] USB Host support for OMAP5 uEVM (for 3.14) Roger Quadros
2014-01-09 11:08       ` Roger Quadros
2014-01-09 11:08       ` Roger Quadros
2014-01-09 11:22       ` Michele Paolino
2014-01-09 11:22         ` Michele Paolino

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=52CD2807.9000200@ti.com \
    --to=rogerq@ti.com \
    --cc=arnd@arndb.de \
    --cc=balbi@ti.com \
    --cc=bcousson@baylibre.com \
    --cc=devicetree@vger.kernel.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=sameo@linux.intel.com \
    --cc=t-kristo@ti.com \
    --cc=tony@atomide.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.