From: Benoit Cousson <b-cousson@ti.com>
To: "Bedia, Vaibhav" <vaibhav.bedia@ti.com>
Cc: "Philip, Avinash" <avinashphilip@ti.com>,
"thierry.reding@avionic-design.de"
<thierry.reding@avionic-design.de>,
"paul@pwsan.com" <paul@pwsan.com>,
"tony@atomide.com" <tony@atomide.com>,
"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
"Hiremath, Vaibhav" <hvaibhav@ti.com>,
"AnilKumar, Chimata" <anilkumar@ti.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"devicetree-discuss@lists.ozlabs.org"
<devicetree-discuss@lists.ozlabs.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"Nori, Sekhar" <nsekhar@ti.com>,
"Hebbar, Gururaja" <gururaja.hebbar@ti.com>
Subject: Re: [PATCH v3 03/10] ARM: OMAP: AM33xx hwmod: Add parent-child relationship for PWM subsystem
Date: Mon, 26 Nov 2012 10:02:59 +0100 [thread overview]
Message-ID: <50B33043.2020700@ti.com> (raw)
In-Reply-To: <B5906170F1614E41A8A28DE3B8D121433EC4C0FA@DBDE01.ent.ti.com>
Hi Vaibhav,
On 11/26/2012 06:19 AM, Bedia, Vaibhav wrote:
> On Fri, Nov 23, 2012 at 16:36:06, Philip, Avinash wrote:
>> On Tue, Nov 20, 2012 at 10:33:44, Philip, Avinash wrote:
>>> As part of PWM subsystem integration, PWM subsystem are sharing
>>> resources like clock across submodules (ECAP, EQEP & EHRPWM).
>>> To handle resource sharing & IP integration
>>> 1. Rework on parent child relation between PWMSS and
>>> ECAP, EQEP & EHRPWM child devices to support runtime PM.
>>> 2. Add support for opt_clks in EHRPWM HWMOD entry to handle additional
>>> clock gating from control module.
>>> 3. Add HWMOD entries for EQEP PWM submodule.
>>>
>>
>> Is there any review on this patch?
>> This patch depends on ECAP & EHRPWM to work in am335x.
>
> First of all, I think you should break up this patch as per the 3 points
> that you mentioned above.
>
> The usage of opt_clks for this does not look right to me. Based on your
> description this clock is necessary and not optional on AM335x and on
> Davinci platforms this clock does not exist.
>
> I think the custom activate/deactivate functions in the OMAP runtime PM
> implementation was a good fit for keeping this SoC integration detail out
> of the driver code. However, the current DT flow in omap_device.c seems to
> assign the default activate/deactivate ops. Is that approach deprecated?
The issue is that this approach is not doable anymore with DT, that's
why I had to provide a default set of functions.
Regards,
Benoit
WARNING: multiple messages have this Message-ID (diff)
From: b-cousson@ti.com (Benoit Cousson)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 03/10] ARM: OMAP: AM33xx hwmod: Add parent-child relationship for PWM subsystem
Date: Mon, 26 Nov 2012 10:02:59 +0100 [thread overview]
Message-ID: <50B33043.2020700@ti.com> (raw)
In-Reply-To: <B5906170F1614E41A8A28DE3B8D121433EC4C0FA@DBDE01.ent.ti.com>
Hi Vaibhav,
On 11/26/2012 06:19 AM, Bedia, Vaibhav wrote:
> On Fri, Nov 23, 2012 at 16:36:06, Philip, Avinash wrote:
>> On Tue, Nov 20, 2012 at 10:33:44, Philip, Avinash wrote:
>>> As part of PWM subsystem integration, PWM subsystem are sharing
>>> resources like clock across submodules (ECAP, EQEP & EHRPWM).
>>> To handle resource sharing & IP integration
>>> 1. Rework on parent child relation between PWMSS and
>>> ECAP, EQEP & EHRPWM child devices to support runtime PM.
>>> 2. Add support for opt_clks in EHRPWM HWMOD entry to handle additional
>>> clock gating from control module.
>>> 3. Add HWMOD entries for EQEP PWM submodule.
>>>
>>
>> Is there any review on this patch?
>> This patch depends on ECAP & EHRPWM to work in am335x.
>
> First of all, I think you should break up this patch as per the 3 points
> that you mentioned above.
>
> The usage of opt_clks for this does not look right to me. Based on your
> description this clock is necessary and not optional on AM335x and on
> Davinci platforms this clock does not exist.
>
> I think the custom activate/deactivate functions in the OMAP runtime PM
> implementation was a good fit for keeping this SoC integration detail out
> of the driver code. However, the current DT flow in omap_device.c seems to
> assign the default activate/deactivate ops. Is that approach deprecated?
The issue is that this approach is not doable anymore with DT, that's
why I had to provide a default set of functions.
Regards,
Benoit
next prev parent reply other threads:[~2012-11-26 9:03 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-20 5:03 [PATCH v3 00/10] Support for AM33xx PWM Subsystem Philip, Avinash
2012-11-20 5:03 ` Philip, Avinash
2012-11-20 5:03 ` Philip, Avinash
[not found] ` <1353387831-31538-1-git-send-email-avinashphilip-l0cyMroinI0@public.gmane.org>
2012-11-20 5:03 ` [PATCH v3 01/10] PWMSS: Add PWM Subsystem driver for parent<->child relationship Philip, Avinash
2012-11-20 5:03 ` Philip, Avinash
2012-11-20 5:03 ` Philip, Avinash
2012-11-20 5:03 ` [PATCH v3 02/10] ARM: am33xx: clk: Add optional clock for EHRPWM Philip, Avinash
2012-11-20 5:03 ` Philip, Avinash
2012-11-20 5:03 ` Philip, Avinash
2012-11-23 11:03 ` Philip, Avinash
2012-11-23 11:03 ` Philip, Avinash
2012-11-20 5:03 ` [PATCH v3 03/10] ARM: OMAP: AM33xx hwmod: Add parent-child relationship for PWM subsystem Philip, Avinash
2012-11-20 5:03 ` Philip, Avinash
2012-11-20 5:03 ` Philip, Avinash
2012-11-23 11:06 ` Philip, Avinash
2012-11-23 11:06 ` Philip, Avinash
2012-11-26 5:19 ` Bedia, Vaibhav
2012-11-26 5:19 ` Bedia, Vaibhav
2012-11-26 9:02 ` Benoit Cousson [this message]
2012-11-26 9:02 ` Benoit Cousson
2012-11-26 11:07 ` Bedia, Vaibhav
2012-11-26 11:07 ` Bedia, Vaibhav
[not found] ` <B5906170F1614E41A8A28DE3B8D121433EC4D5C7-Er742YJ7I/eIQmiDNMet8wC/G2K4zDHf@public.gmane.org>
2012-11-27 6:24 ` Philip, Avinash
2012-11-27 6:24 ` Philip, Avinash
2012-11-27 6:24 ` Philip, Avinash
2012-11-20 5:03 ` [PATCH v3 04/10] pwm: pwm-tiecap: Add device-tree binding support for APWM driver Philip, Avinash
2012-11-20 5:03 ` Philip, Avinash
2012-11-20 5:03 ` Philip, Avinash
2012-11-20 5:03 ` [PATCH v3 05/10] pwm: pwm-tiecap: pinctrl support Philip, Avinash
2012-11-20 5:03 ` Philip, Avinash
2012-11-20 5:03 ` Philip, Avinash
2012-11-20 5:03 ` [PATCH v3 06/10] pwm: pwm-tiehrpwm: Add device-tree binding support for EHRPWM driver Philip, Avinash
2012-11-20 5:03 ` Philip, Avinash
2012-11-20 5:03 ` Philip, Avinash
2012-11-20 5:03 ` [PATCH v3 07/10] pwm: pwm-tiehrpwm: pinctrl support Philip, Avinash
2012-11-20 5:03 ` Philip, Avinash
2012-11-20 5:03 ` Philip, Avinash
2012-11-20 5:03 ` [PATCH v3 08/10] pwm: pwm-tiehrpwm: Adding TBCLK gating support Philip, Avinash
2012-11-20 5:03 ` Philip, Avinash
2012-11-20 5:03 ` Philip, Avinash
2012-11-20 5:03 ` [PATCH v3 09/10] ARM: dts: AM33XX: Add PWMSS device tree nodes Philip, Avinash
2012-11-20 5:03 ` Philip, Avinash
2012-11-20 5:03 ` Philip, Avinash
2012-11-20 5:03 ` [PATCH v3 10/10] ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evm Philip, Avinash
2012-11-20 5:03 ` Philip, Avinash
2012-11-20 5:03 ` Philip, Avinash
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=50B33043.2020700@ti.com \
--to=b-cousson@ti.com \
--cc=anilkumar@ti.com \
--cc=avinashphilip@ti.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=gururaja.hebbar@ti.com \
--cc=hvaibhav@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=nsekhar@ti.com \
--cc=paul@pwsan.com \
--cc=thierry.reding@avionic-design.de \
--cc=tony@atomide.com \
--cc=vaibhav.bedia@ti.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.