* Re: [PATCH] dmaengine: ti: omap-dma: Remove variable override in omap_dma_tx_status()
From: Vinod Koul @ 2019-09-04 4:41 UTC (permalink / raw)
To: Peter Ujfalusi; +Cc: dmaengine, dan.j.williams, linux-omap, linux-arm-kernel
In-Reply-To: <20190730132029.2971-1-peter.ujfalusi@ti.com>
On 30-07-19, 16:20, Peter Ujfalusi wrote:
> There is no need to fetch local omap_desc since the desc we have is the
> correct one already when we need to check the channel status.
Applied, thanks
--
~Vinod
^ permalink raw reply
* Re: [PATCH] dmaengine: ti: omap-dma: Remove 'Assignment in if condition'
From: Vinod Koul @ 2019-09-04 4:40 UTC (permalink / raw)
To: Peter Ujfalusi; +Cc: dmaengine, dan.j.williams, linux-omap, linux-arm-kernel
In-Reply-To: <20190730132015.2863-1-peter.ujfalusi@ti.com>
On 30-07-19, 16:20, Peter Ujfalusi wrote:
> While the compiler does not have problem with how it is implemented,
> checkpatch does give en ERROR for this arrangement.
Applied, thanks
--
~Vinod
^ permalink raw reply
* Re: [PATCH] dmaengine: ti: edma: Remove 'Assignment in if condition'
From: Vinod Koul @ 2019-09-04 4:36 UTC (permalink / raw)
To: Peter Ujfalusi; +Cc: dmaengine, dan.j.williams, linux-omap, linux-arm-kernel
In-Reply-To: <20190730132006.2790-1-peter.ujfalusi@ti.com>
On 30-07-19, 16:20, Peter Ujfalusi wrote:
> While the compiler does not have problem with how it is implemented,
> checkpatch does give en ERROR for this arrangement.
Applied, thanks
--
~Vinod
^ permalink raw reply
* Re: [GIT PULL 2/2] dts changes for omap variants for v5.4
From: Arnd Bergmann @ 2019-09-03 14:01 UTC (permalink / raw)
To: Tony Lindgren; +Cc: SoC Team, arm-soc, Linux ARM, linux-omap
In-Reply-To: <pull-1566599057-142651@atomide.com-2>
On Sat, Aug 24, 2019 at 12:24 AM Tony Lindgren <tony@atomide.com> wrote:
> ----------------------------------------------------------------
> dts changes for omap variants for v5.4
>
> Remove regulator-boot-off properties that we never had in the mainline
> kernel so they won't do anything. We add stdout-path for gta04, and
> make am335x-boneblue use am335x-osd335x-common.dtsi file.
Pulled into arm/dt, thanks!
Arnd
^ permalink raw reply
* Re: [PATCHv3 01/10] dt-bindings: omap: add new binding for PRM instances
From: Tero Kristo @ 2019-09-03 13:50 UTC (permalink / raw)
To: Adam Ford
Cc: Rob Herring, devicetree, Tony Lindgren, p.zabel,
Santosh Shilimkar, Linux-OMAP, arm-soc
In-Reply-To: <CAHCN7xKNSj_DW+Gcbpy4ehphBYCbJw9mSATOcWzT7ZcZR81r6g@mail.gmail.com>
On 03/09/2019 16:19, Adam Ford wrote:
> On Tue, Sep 3, 2019 at 2:26 AM Tero Kristo <t-kristo@ti.com> wrote:
>>
>> On 02/09/2019 16:39, Rob Herring wrote:
>>> On Fri, Aug 30, 2019 at 03:18:07PM +0300, Tero Kristo wrote:
>>>> Add new binding for OMAP PRM (Power and Reset Manager) instances. Each
>>>> of these will act as a power domain controller and potentially as a reset
>>>> provider.
>>>>
>>>
>>> Converting this to schema would be nice.
>>
>> Do you have documentation about schema somewhere? Basically what I need
>> to do to fix this.
>>
>>>
>>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>>> ---
>>>> .../devicetree/bindings/arm/omap/prm-inst.txt | 31 +++++++++++++++++++
>>>
>>> bindings/reset/
>>
>> I did not put this under reset, because this is basically a
>> multi-purpose function. Reset just happens to be the first functionality
>> it is going to provide. It will be followed by power domain support
>> later on.
>>
>> Any thoughts?
>>
>>>
>>>> 1 file changed, 31 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/arm/omap/prm-inst.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/omap/prm-inst.txt b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
>>>> new file mode 100644
>>>> index 000000000000..7c7527c37734
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
>>>> @@ -0,0 +1,31 @@
>>>> +OMAP PRM instance bindings
>>>> +
>>>> +Power and Reset Manager is an IP block on OMAP family of devices which
>>>> +handle the power domains and their current state, and provide reset
>>>> +handling for the domains and/or separate IP blocks under the power domain
>>>> +hierarchy.
>>>> +
>>>> +Required properties:
>>>> +- compatible: Must be one of:
>>>> + "ti,am3-prm-inst"
>
> Would it make sense to call it am33 instead of am3? The AM35xx is
> different than AM33.
Well, am35xx is effectively just a variant of omap3, they just named it
funnily. Same for dra7 vs. am57xx. Also, bindings of type "ti,am3-*"
exist for other am33xx functionality already.
-Tero
>
>>>> + "ti,am4-prm-inst"
>>>> + "ti,omap4-prm-inst"
>>>> + "ti,omap5-prm-inst"
>>>> + "ti,dra7-prm-inst"
>>>
>>> '-inst' seems a bit redundant.
>>
>> ti,xyz-prm is already reserved by the parent node of all these.
>>
>> The hierarchy is basically like this (omap4 as example):
>>
>> prm: prm@4a306000 {
>> compatible = "ti,omap4-prm";
>> ...
>>
>> prm_dsp: prm@400 {
>> compatible = "ti,omap4-prm-inst";
>> ...
>> };
>>
>> prm_device: prm@1b00 {
>> compatible = "ti,omap4-prm-inst";
>> ...
>> };
>>
>> ...
>> };
>>
>>
>>
>>>
>>>> +- reg: Contains PRM instance register address range
>>>> + (base address and length)
>>>> +
>>>> +Optional properties:
>>>> +- #reset-cells: Should be 1 if the PRM instance in question supports resets.
>>>> +- clocks: Associated clocks for the reset signals if any. Certain reset
>>>> + signals can't be toggled properly without functional clock
>>>> + being active for them.
>>>> +
>>>> +Example:
>>>> +
>>>> +prm_dsp2: prm@1b00 {
>>>
>>> reset-controller@...
>>
>> Well, as said, the same node is going to be also power domain provider
>> later on...
>>
>>>
>>>> + compatible = "ti,dra7-prm-inst";
>>>> + reg = <0x1b00 0x40>;
>>>> + #reset-cells = <1>;
>>>> + clocks = <&dsp2_clkctrl DRA7_DSP2_MMU0_DSP2_CLKCTRL 0>;
>>>> +};
>>>> --
>>>> 2.17.1
>>>>
>>>> --
>>>
>>
>
> adam
>> --
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply
* Re: [RFC 5/5] ARM: dts: omap3-beagle: make explicitly compatible to ti,omap34xx
From: Tony Lindgren @ 2019-09-03 13:40 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Benoît Cousson, Rob Herring, Adam Ford, André Roth,
Mark Rutland, Rafael J. Wysocki, Viresh Kumar, linux-omap,
devicetree, linux-kernel, linux-pm, letux-kernel, kernel
In-Reply-To: <150eb34a95b2e7ead8ac81a9ab275592ea31595b.1567421751.git.hns@goldelico.com>
* H. Nikolaus Schaller <hns@goldelico.com> [190902 10:56]:
> Matching the ti-cpufreq driver needs to specify explicitly if
> a board uses an omap34xx or omap36xx chip.
>
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> ---
> arch/arm/boot/dts/omap3-beagle.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
> index e3df3c166902..d47213c7a4d0 100644
> --- a/arch/arm/boot/dts/omap3-beagle.dts
> +++ b/arch/arm/boot/dts/omap3-beagle.dts
> @@ -8,7 +8,7 @@
>
> / {
> model = "TI OMAP3 BeagleBoard";
> - compatible = "ti,omap3-beagle", "ti,omap3";
> + compatible = "ti,omap3-beagle", "ti,omap34xx", "ti,omap3";
>
> cpus {
> cpu@0 {
For a clean-up patch, we should just use the following compatibles
in general for omap3:
ti,omap3 omap3
ti,omap34 omap34xx and omap35xx
ti,omap36 omap36xx and dm37xx
ti,am35 am35xx
So we should just leave out the "xx" part. But we still need parse
also the legacy binding with "xx" in drivers.
Regards,
Tony
^ permalink raw reply
* Re: [PATCHv3 01/10] dt-bindings: omap: add new binding for PRM instances
From: Philipp Zabel @ 2019-09-03 13:25 UTC (permalink / raw)
To: Tony Lindgren, Tero Kristo
Cc: Rob Herring, linux-omap, Santosh Shilimkar,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
devicetree
In-Reply-To: <20190903131632.GL52127@atomide.com>
Hi Tony,
On Tue, 2019-09-03 at 06:16 -0700, Tony Lindgren wrote:
> * Tero Kristo <t-kristo@ti.com> [190903 08:15]:
> > On 03/09/2019 11:10, Rob Herring wrote:
> > > I prefer that bindings be complete as possible even if driver support
> > > is not there yet. Adding power domain support may only mean adding
> > > '#power-domain-cells'.
> > >
> > > The location is fine then.
> >
> > Yeah, I assume just adding power-domain-cells should be enough. I am not too
> > sure before I start trying this out though so did not want to add it yet.
>
> Should we call the device tree node name power-controller instead of
> reset controller though? Most of the PRM instances do not have a
> separate rstctrl reset control functionality.
>
> Anybody got better any better naming in mind?
power-controller seems fine to me, that is their primary function.
regards
Philipp
^ permalink raw reply
* Re: [PATCHv3 01/10] dt-bindings: omap: add new binding for PRM instances
From: Adam Ford @ 2019-09-03 13:19 UTC (permalink / raw)
To: Tero Kristo
Cc: Rob Herring, devicetree, Tony Lindgren, p.zabel,
Santosh Shilimkar, Linux-OMAP, arm-soc
In-Reply-To: <e8d700cd-8f3c-5cea-a022-b20a595fc1e1@ti.com>
On Tue, Sep 3, 2019 at 2:26 AM Tero Kristo <t-kristo@ti.com> wrote:
>
> On 02/09/2019 16:39, Rob Herring wrote:
> > On Fri, Aug 30, 2019 at 03:18:07PM +0300, Tero Kristo wrote:
> >> Add new binding for OMAP PRM (Power and Reset Manager) instances. Each
> >> of these will act as a power domain controller and potentially as a reset
> >> provider.
> >>
> >
> > Converting this to schema would be nice.
>
> Do you have documentation about schema somewhere? Basically what I need
> to do to fix this.
>
> >
> >> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> >> ---
> >> .../devicetree/bindings/arm/omap/prm-inst.txt | 31 +++++++++++++++++++
> >
> > bindings/reset/
>
> I did not put this under reset, because this is basically a
> multi-purpose function. Reset just happens to be the first functionality
> it is going to provide. It will be followed by power domain support
> later on.
>
> Any thoughts?
>
> >
> >> 1 file changed, 31 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/arm/omap/prm-inst.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/arm/omap/prm-inst.txt b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
> >> new file mode 100644
> >> index 000000000000..7c7527c37734
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
> >> @@ -0,0 +1,31 @@
> >> +OMAP PRM instance bindings
> >> +
> >> +Power and Reset Manager is an IP block on OMAP family of devices which
> >> +handle the power domains and their current state, and provide reset
> >> +handling for the domains and/or separate IP blocks under the power domain
> >> +hierarchy.
> >> +
> >> +Required properties:
> >> +- compatible: Must be one of:
> >> + "ti,am3-prm-inst"
Would it make sense to call it am33 instead of am3? The AM35xx is
different than AM33.
> >> + "ti,am4-prm-inst"
> >> + "ti,omap4-prm-inst"
> >> + "ti,omap5-prm-inst"
> >> + "ti,dra7-prm-inst"
> >
> > '-inst' seems a bit redundant.
>
> ti,xyz-prm is already reserved by the parent node of all these.
>
> The hierarchy is basically like this (omap4 as example):
>
> prm: prm@4a306000 {
> compatible = "ti,omap4-prm";
> ...
>
> prm_dsp: prm@400 {
> compatible = "ti,omap4-prm-inst";
> ...
> };
>
> prm_device: prm@1b00 {
> compatible = "ti,omap4-prm-inst";
> ...
> };
>
> ...
> };
>
>
>
> >
> >> +- reg: Contains PRM instance register address range
> >> + (base address and length)
> >> +
> >> +Optional properties:
> >> +- #reset-cells: Should be 1 if the PRM instance in question supports resets.
> >> +- clocks: Associated clocks for the reset signals if any. Certain reset
> >> + signals can't be toggled properly without functional clock
> >> + being active for them.
> >> +
> >> +Example:
> >> +
> >> +prm_dsp2: prm@1b00 {
> >
> > reset-controller@...
>
> Well, as said, the same node is going to be also power domain provider
> later on...
>
> >
> >> + compatible = "ti,dra7-prm-inst";
> >> + reg = <0x1b00 0x40>;
> >> + #reset-cells = <1>;
> >> + clocks = <&dsp2_clkctrl DRA7_DSP2_MMU0_DSP2_CLKCTRL 0>;
> >> +};
> >> --
> >> 2.17.1
> >>
> >> --
> >
>
adam
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply
* Re: [PATCHv3 01/10] dt-bindings: omap: add new binding for PRM instances
From: Tony Lindgren @ 2019-09-03 13:16 UTC (permalink / raw)
To: Tero Kristo
Cc: Rob Herring, devicetree, Philipp Zabel, Santosh Shilimkar,
linux-omap,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <7c2c8a4d-d24e-ceec-afc1-04cdc4d5d952@ti.com>
* Tero Kristo <t-kristo@ti.com> [190903 08:15]:
> On 03/09/2019 11:10, Rob Herring wrote:
> > I prefer that bindings be complete as possible even if driver support
> > is not there yet. Adding power domain support may only mean adding
> > '#power-domain-cells'.
> >
> > The location is fine then.
>
> Yeah, I assume just adding power-domain-cells should be enough. I am not too
> sure before I start trying this out though so did not want to add it yet.
Should we call the device tree node name power-controller instead of
reset controller though? Most of the PRM instances do not have a
separate rstctrl reset control functionality.
Anybody got better any better naming in mind?
Regards,
Tony
^ permalink raw reply
* Re: [GIT PULL 1/4] soc changes for omap variants for v5.4
From: Arnd Bergmann @ 2019-09-03 12:25 UTC (permalink / raw)
To: Tony Lindgren; +Cc: SoC Team, arm-soc, Linux ARM, linux-omap
In-Reply-To: <pull-1567016893-318461@atomide.com>
On Wed, Aug 28, 2019 at 8:35 PM Tony Lindgren <tony@atomide.com> wrote:
>
> From: "Tony Lindgren" <tony@atomide.com>
>
> The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
>
> Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v5.4/soc-signed
>
> for you to fetch changes up to 50f57ef83d836d727902a6a7e70cca61b0d02655:
>
> ARM: OMAP2+: Delete an unnecessary kfree() call in omap_hsmmc_pdata_init() (2019-08-26 08:59:48 -0700)
>
> ----------------------------------------------------------------
> SoC changes for omap variants for v5.4
>
> The first change moves platform-specific asm-offsets.h to arch/arm/mach-omap2
> to fix iessu with parallel build with CONFIG_IKHEADERS, and the second change
> removes a useless kfree.
>
> Note that the first change causes a trivial merge conflict with the iommu
> changes for arch/arm/mach-omap2/Makefile.
Pulled into arm/soc, thanks!
Arnd
^ permalink raw reply
* Re: [PATCH 4/5] dt-bindings: dma: ti-edma: Add option for reserved channel ranges
From: Peter Ujfalusi @ 2019-09-03 10:19 UTC (permalink / raw)
To: Rob Herring
Cc: vkoul, dan.j.williams, dmaengine, linux-arm-kernel, devicetree,
linux-kernel, linux-omap
In-Reply-To: <a4c5688b-cbeb-5059-5351-11d9ae1b25d5@ti.com>
Hi Rob,
On 30/08/2019 8.37, Peter Ujfalusi wrote:
> Rob,
>
> On 30/08/2019 1.47, Rob Herring wrote:
>> On Fri, Aug 23, 2019 at 03:56:17PM +0300, Peter Ujfalusi wrote:
>>> Similarly to paRAM slots, channels can be used by other cores.
>>>
>>> Add optional property to configure the reserved channel ranges.
>>>
>>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
>>> ---
>>> Documentation/devicetree/bindings/dma/ti-edma.txt | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt
>>> index 4bbc94d829c8..1198682ada99 100644
>>> --- a/Documentation/devicetree/bindings/dma/ti-edma.txt
>>> +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
>>> @@ -42,6 +42,9 @@ Optional properties:
>>> - ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used by
>>> the driver, they are allocated to be used by for example the
>>> DSP. See example.
>>> +- ti,edma-reserved-chan-ranges: channel ranges which should not be used by
>>> + the driver, they are allocated to be used by for example the
>>> + DSP. See example.
>>
>> Based on the other thread, I think extending dma-channel-mask to a
>> uint32-array makes sense here.
>
> Yes, that is the reason I have asked on that and I'm in progress of
> converting the edma driver to use the dma-channel-mask.
> Just need to do some shuffling in the driver to get the mask in a form
> usable by the driver.
>
> I'll send an updated series early next week.
How should the dma-channel-mask uint31-array should be documented and used?
Basically some EDMA have 32, some 64 channels. This is fine.
Let's say I want to mask out channel 0-4 and 24-27
This would look like in case of EDMA with 32 channels:
&edma {
/* channel 0-4 and 24-27 is not to be used */
dma-channel-mask = <0xf0fffff0>;
};
How this should look like in case when I have 64 channels?
&edma {
/* channel 0-4 and 24-27 is not to be used */
dma-channel-mask = <0xf0fffff0>, <0xffffffff>;
};
When I read the u32s then
chan_mask[0] is for channel 0-31 (LSB is channel 0)
chan_maks[1] is for channel 32-63 (LSB is channel 32)
Or:
&edma {
/* channel 0-4 and 24-27 is not to be used */
dma-channel-mask = <0xffffffff>, <0xf0fffff0>;
};
chan_maks[0] is for channel 32-63 (LSB is channel 32)
chan_mask[1] is for channel 0-31 (LSB is channel 0)
Do you have pointer on already established notion on how to document and
handle this?
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply
* Re: [PATCHv3 01/10] dt-bindings: omap: add new binding for PRM instances
From: Tero Kristo @ 2019-09-03 8:14 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Tony Lindgren, Philipp Zabel, Santosh Shilimkar,
linux-omap,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_Jsq+AJj1bgOQYG=c86A5HC_g2UZph387oVEKZyP4M18kURw@mail.gmail.com>
On 03/09/2019 11:10, Rob Herring wrote:
> On Tue, Sep 3, 2019 at 8:26 AM Tero Kristo <t-kristo@ti.com> wrote:
>>
>> On 02/09/2019 16:39, Rob Herring wrote:
>>> On Fri, Aug 30, 2019 at 03:18:07PM +0300, Tero Kristo wrote:
>>>> Add new binding for OMAP PRM (Power and Reset Manager) instances. Each
>>>> of these will act as a power domain controller and potentially as a reset
>>>> provider.
>>>>
>>>
>>> Converting this to schema would be nice.
>>
>> Do you have documentation about schema somewhere? Basically what I need
>> to do to fix this.
>
> Documentation/devicetree/writing-schema.md (.rst in -next)
> Documentation/devicetree/bindings/example-schema.yaml
>
>>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>>> ---
>>>> .../devicetree/bindings/arm/omap/prm-inst.txt | 31 +++++++++++++++++++
>>>
>>> bindings/reset/
>>
>> I did not put this under reset, because this is basically a
>> multi-purpose function. Reset just happens to be the first functionality
>> it is going to provide. It will be followed by power domain support
>> later on.
>>
>> Any thoughts?
>
> I prefer that bindings be complete as possible even if driver support
> is not there yet. Adding power domain support may only mean adding
> '#power-domain-cells'.
>
> The location is fine then.
Yeah, I assume just adding power-domain-cells should be enough. I am not
too sure before I start trying this out though so did not want to add it
yet.
>
>>>> 1 file changed, 31 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/arm/omap/prm-inst.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/omap/prm-inst.txt b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
>>>> new file mode 100644
>>>> index 000000000000..7c7527c37734
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
>>>> @@ -0,0 +1,31 @@
>>>> +OMAP PRM instance bindings
>>>> +
>>>> +Power and Reset Manager is an IP block on OMAP family of devices which
>>>> +handle the power domains and their current state, and provide reset
>>>> +handling for the domains and/or separate IP blocks under the power domain
>>>> +hierarchy.
>>>> +
>>>> +Required properties:
>>>> +- compatible: Must be one of:
>>>> + "ti,am3-prm-inst"
>>>> + "ti,am4-prm-inst"
>>>> + "ti,omap4-prm-inst"
>>>> + "ti,omap5-prm-inst"
>>>> + "ti,dra7-prm-inst"
>>>
>>> '-inst' seems a bit redundant.
>>
>> ti,xyz-prm is already reserved by the parent node of all these.
>>
>> The hierarchy is basically like this (omap4 as example):
>>
>> prm: prm@4a306000 {
>> compatible = "ti,omap4-prm";
>> ...
>>
>> prm_dsp: prm@400 {
>> compatible = "ti,omap4-prm-inst";
>> ...
>> };
>>
>> prm_device: prm@1b00 {
>> compatible = "ti,omap4-prm-inst";
>> ...
>> };
>>
>> ...
>> };
>
> Okay. Then you need to state this binding must be a child of PRM. The
> schema would need to take this into account too, so probably best to
> not convert this yet.
>
Ok thanks, I'll make the necessary updates and post v4.
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply
* Re: [PATCHv3 01/10] dt-bindings: omap: add new binding for PRM instances
From: Rob Herring @ 2019-09-03 8:10 UTC (permalink / raw)
To: Tero Kristo
Cc: devicetree, Tony Lindgren, Philipp Zabel, Santosh Shilimkar,
linux-omap,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <e8d700cd-8f3c-5cea-a022-b20a595fc1e1@ti.com>
On Tue, Sep 3, 2019 at 8:26 AM Tero Kristo <t-kristo@ti.com> wrote:
>
> On 02/09/2019 16:39, Rob Herring wrote:
> > On Fri, Aug 30, 2019 at 03:18:07PM +0300, Tero Kristo wrote:
> >> Add new binding for OMAP PRM (Power and Reset Manager) instances. Each
> >> of these will act as a power domain controller and potentially as a reset
> >> provider.
> >>
> >
> > Converting this to schema would be nice.
>
> Do you have documentation about schema somewhere? Basically what I need
> to do to fix this.
Documentation/devicetree/writing-schema.md (.rst in -next)
Documentation/devicetree/bindings/example-schema.yaml
> >> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> >> ---
> >> .../devicetree/bindings/arm/omap/prm-inst.txt | 31 +++++++++++++++++++
> >
> > bindings/reset/
>
> I did not put this under reset, because this is basically a
> multi-purpose function. Reset just happens to be the first functionality
> it is going to provide. It will be followed by power domain support
> later on.
>
> Any thoughts?
I prefer that bindings be complete as possible even if driver support
is not there yet. Adding power domain support may only mean adding
'#power-domain-cells'.
The location is fine then.
> >> 1 file changed, 31 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/arm/omap/prm-inst.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/arm/omap/prm-inst.txt b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
> >> new file mode 100644
> >> index 000000000000..7c7527c37734
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
> >> @@ -0,0 +1,31 @@
> >> +OMAP PRM instance bindings
> >> +
> >> +Power and Reset Manager is an IP block on OMAP family of devices which
> >> +handle the power domains and their current state, and provide reset
> >> +handling for the domains and/or separate IP blocks under the power domain
> >> +hierarchy.
> >> +
> >> +Required properties:
> >> +- compatible: Must be one of:
> >> + "ti,am3-prm-inst"
> >> + "ti,am4-prm-inst"
> >> + "ti,omap4-prm-inst"
> >> + "ti,omap5-prm-inst"
> >> + "ti,dra7-prm-inst"
> >
> > '-inst' seems a bit redundant.
>
> ti,xyz-prm is already reserved by the parent node of all these.
>
> The hierarchy is basically like this (omap4 as example):
>
> prm: prm@4a306000 {
> compatible = "ti,omap4-prm";
> ...
>
> prm_dsp: prm@400 {
> compatible = "ti,omap4-prm-inst";
> ...
> };
>
> prm_device: prm@1b00 {
> compatible = "ti,omap4-prm-inst";
> ...
> };
>
> ...
> };
Okay. Then you need to state this binding must be a child of PRM. The
schema would need to take this into account too, so probably best to
not convert this yet.
Rob
^ permalink raw reply
* Re: [PATCHv3 01/10] dt-bindings: omap: add new binding for PRM instances
From: Tero Kristo @ 2019-09-03 7:25 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, tony, p.zabel, ssantosh, linux-omap, linux-arm-kernel
In-Reply-To: <20190902042631.GA22055@bogus>
On 02/09/2019 16:39, Rob Herring wrote:
> On Fri, Aug 30, 2019 at 03:18:07PM +0300, Tero Kristo wrote:
>> Add new binding for OMAP PRM (Power and Reset Manager) instances. Each
>> of these will act as a power domain controller and potentially as a reset
>> provider.
>>
>
> Converting this to schema would be nice.
Do you have documentation about schema somewhere? Basically what I need
to do to fix this.
>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> ---
>> .../devicetree/bindings/arm/omap/prm-inst.txt | 31 +++++++++++++++++++
>
> bindings/reset/
I did not put this under reset, because this is basically a
multi-purpose function. Reset just happens to be the first functionality
it is going to provide. It will be followed by power domain support
later on.
Any thoughts?
>
>> 1 file changed, 31 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/arm/omap/prm-inst.txt
>>
>> diff --git a/Documentation/devicetree/bindings/arm/omap/prm-inst.txt b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
>> new file mode 100644
>> index 000000000000..7c7527c37734
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
>> @@ -0,0 +1,31 @@
>> +OMAP PRM instance bindings
>> +
>> +Power and Reset Manager is an IP block on OMAP family of devices which
>> +handle the power domains and their current state, and provide reset
>> +handling for the domains and/or separate IP blocks under the power domain
>> +hierarchy.
>> +
>> +Required properties:
>> +- compatible: Must be one of:
>> + "ti,am3-prm-inst"
>> + "ti,am4-prm-inst"
>> + "ti,omap4-prm-inst"
>> + "ti,omap5-prm-inst"
>> + "ti,dra7-prm-inst"
>
> '-inst' seems a bit redundant.
ti,xyz-prm is already reserved by the parent node of all these.
The hierarchy is basically like this (omap4 as example):
prm: prm@4a306000 {
compatible = "ti,omap4-prm";
...
prm_dsp: prm@400 {
compatible = "ti,omap4-prm-inst";
...
};
prm_device: prm@1b00 {
compatible = "ti,omap4-prm-inst";
...
};
...
};
>
>> +- reg: Contains PRM instance register address range
>> + (base address and length)
>> +
>> +Optional properties:
>> +- #reset-cells: Should be 1 if the PRM instance in question supports resets.
>> +- clocks: Associated clocks for the reset signals if any. Certain reset
>> + signals can't be toggled properly without functional clock
>> + being active for them.
>> +
>> +Example:
>> +
>> +prm_dsp2: prm@1b00 {
>
> reset-controller@...
Well, as said, the same node is going to be also power domain provider
later on...
>
>> + compatible = "ti,dra7-prm-inst";
>> + reg = <0x1b00 0x40>;
>> + #reset-cells = <1>;
>> + clocks = <&dsp2_clkctrl DRA7_DSP2_MMU0_DSP2_CLKCTRL 0>;
>> +};
>> --
>> 2.17.1
>>
>> --
>
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply
* Re: [RFC 4/5] ARM: dts: omap3-n950-n9: remove opp-v1 table
From: H. Nikolaus Schaller @ 2019-09-03 6:34 UTC (permalink / raw)
To: Viresh Kumar
Cc: Benoît Cousson, Tony Lindgren, Rob Herring, Adam Ford,
André Roth, Mark Rutland, Rafael J. Wysocki, linux-omap,
devicetree, linux-kernel, linux-pm, letux-kernel, kernel
In-Reply-To: <20190903062808.p6jkgwylyqxcjs4z@vireshk-i7>
> Am 03.09.2019 um 08:28 schrieb Viresh Kumar <viresh.kumar@linaro.org>:
>
> On 03-09-19, 08:23, H. Nikolaus Schaller wrote:
>>
>>> Am 03.09.2019 um 08:14 schrieb Viresh Kumar <viresh.kumar@linaro.org>:
>>>
>>> On 03-09-19, 08:01, H. Nikolaus Schaller wrote:
>>>>
>>>>> Am 03.09.2019 um 04:36 schrieb Viresh Kumar <viresh.kumar@linaro.org>:
>>>>>
>>>>> On 02-09-19, 12:55, H. Nikolaus Schaller wrote:
>>>>>> With opp-v2 in omap36xx.dtsi and ti-cpufreq driver the
>>>>>> 1GHz capability is automatically detected.
>>>>>>
>>>>>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>>>>>> ---
>>>>>> arch/arm/boot/dts/omap3-n950-n9.dtsi | 7 -------
>>>>>> 1 file changed, 7 deletions(-)
>>>>>>
>>>>>> diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi b/arch/arm/boot/dts/omap3-n950-n9.dtsi
>>>>>> index 5441e9ffdbb4..e98b0c615f19 100644
>>>>>> --- a/arch/arm/boot/dts/omap3-n950-n9.dtsi
>>>>>> +++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
>>>>>> @@ -11,13 +11,6 @@
>>>>>> cpus {
>>>>>> cpu@0 {
>>>>>> cpu0-supply = <&vcc>;
>>>>>> - operating-points = <
>>>>>> - /* kHz uV */
>>>>>> - 300000 1012500
>>>>>> - 600000 1200000
>>>>>> - 800000 1325000
>>>>>> - 1000000 1375000
>>>>>> - >;
>>>>>> };
>>>>>> };
>>>>>
>>>>> This should be merged with 2/5 ?
>>>>
>>>> Well, it bloats 2/5.
>>>
>>> It is logically the right place to do this as that's where we are
>>> adding opp-v2.
>>
>> Well, sometimes the philosophy of patches is to add something new
>> first and remove the old in a second separate patch if the system
>> can live with both. This makes it easier to digest single patches
>> (because they are smaller) and might also better pinpoint an issue
>> by bisect.
>
> Right, but you already removed some of the opp-v1 stuff in patch 2/5.
> Why leave this one out ?
>
>>>
>>>> What I hope (I can't test) is that this opp-v1 table
>>>> is ignored if an opp-v2 table exists. So that it can be
>>>> removed by a separate follow-up patch.
>>>
>>> It should work as that's what we are doing in OPP core, but I still
>>> feel this better get merged with 2/5.
>>
>> Ok, I see. Noted for RFCv2.
>>
>> There will also be a big batch of changes for the compatible record
>> (omap3530->omap35xx, add omap34xx where needed) of ca. 10 board definition
>> DTS files. Should this then also become part of the new 2/5?
>
> Compatible thing should be separate patch anyway, I was just talking
> about replacing opp-v1 with v2.
Ok, understood.
BR and thanks,
Nikolaus
^ permalink raw reply
* Re: [RFC 4/5] ARM: dts: omap3-n950-n9: remove opp-v1 table
From: Viresh Kumar @ 2019-09-03 6:28 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Benoît Cousson, Tony Lindgren, Rob Herring, Adam Ford,
André Roth, Mark Rutland, Rafael J. Wysocki, linux-omap,
devicetree, linux-kernel, linux-pm, letux-kernel, kernel
In-Reply-To: <6B7B0EDB-8A60-48A0-AFAB-8A266358300C@goldelico.com>
On 03-09-19, 08:23, H. Nikolaus Schaller wrote:
>
> > Am 03.09.2019 um 08:14 schrieb Viresh Kumar <viresh.kumar@linaro.org>:
> >
> > On 03-09-19, 08:01, H. Nikolaus Schaller wrote:
> >>
> >>> Am 03.09.2019 um 04:36 schrieb Viresh Kumar <viresh.kumar@linaro.org>:
> >>>
> >>> On 02-09-19, 12:55, H. Nikolaus Schaller wrote:
> >>>> With opp-v2 in omap36xx.dtsi and ti-cpufreq driver the
> >>>> 1GHz capability is automatically detected.
> >>>>
> >>>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> >>>> ---
> >>>> arch/arm/boot/dts/omap3-n950-n9.dtsi | 7 -------
> >>>> 1 file changed, 7 deletions(-)
> >>>>
> >>>> diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi b/arch/arm/boot/dts/omap3-n950-n9.dtsi
> >>>> index 5441e9ffdbb4..e98b0c615f19 100644
> >>>> --- a/arch/arm/boot/dts/omap3-n950-n9.dtsi
> >>>> +++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
> >>>> @@ -11,13 +11,6 @@
> >>>> cpus {
> >>>> cpu@0 {
> >>>> cpu0-supply = <&vcc>;
> >>>> - operating-points = <
> >>>> - /* kHz uV */
> >>>> - 300000 1012500
> >>>> - 600000 1200000
> >>>> - 800000 1325000
> >>>> - 1000000 1375000
> >>>> - >;
> >>>> };
> >>>> };
> >>>
> >>> This should be merged with 2/5 ?
> >>
> >> Well, it bloats 2/5.
> >
> > It is logically the right place to do this as that's where we are
> > adding opp-v2.
>
> Well, sometimes the philosophy of patches is to add something new
> first and remove the old in a second separate patch if the system
> can live with both. This makes it easier to digest single patches
> (because they are smaller) and might also better pinpoint an issue
> by bisect.
Right, but you already removed some of the opp-v1 stuff in patch 2/5.
Why leave this one out ?
> >
> >> What I hope (I can't test) is that this opp-v1 table
> >> is ignored if an opp-v2 table exists. So that it can be
> >> removed by a separate follow-up patch.
> >
> > It should work as that's what we are doing in OPP core, but I still
> > feel this better get merged with 2/5.
>
> Ok, I see. Noted for RFCv2.
>
> There will also be a big batch of changes for the compatible record
> (omap3530->omap35xx, add omap34xx where needed) of ca. 10 board definition
> DTS files. Should this then also become part of the new 2/5?
Compatible thing should be separate patch anyway, I was just talking
about replacing opp-v1 with v2.
--
viresh
^ permalink raw reply
* Re: [RFC 4/5] ARM: dts: omap3-n950-n9: remove opp-v1 table
From: H. Nikolaus Schaller @ 2019-09-03 6:23 UTC (permalink / raw)
To: Viresh Kumar
Cc: Benoît Cousson, Tony Lindgren, Rob Herring, Adam Ford,
André Roth, Mark Rutland, Rafael J. Wysocki, linux-omap,
devicetree, linux-kernel, linux-pm, letux-kernel, kernel
In-Reply-To: <20190903061403.k3d333f54gj2kuxi@vireshk-i7>
> Am 03.09.2019 um 08:14 schrieb Viresh Kumar <viresh.kumar@linaro.org>:
>
> On 03-09-19, 08:01, H. Nikolaus Schaller wrote:
>>
>>> Am 03.09.2019 um 04:36 schrieb Viresh Kumar <viresh.kumar@linaro.org>:
>>>
>>> On 02-09-19, 12:55, H. Nikolaus Schaller wrote:
>>>> With opp-v2 in omap36xx.dtsi and ti-cpufreq driver the
>>>> 1GHz capability is automatically detected.
>>>>
>>>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>>>> ---
>>>> arch/arm/boot/dts/omap3-n950-n9.dtsi | 7 -------
>>>> 1 file changed, 7 deletions(-)
>>>>
>>>> diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi b/arch/arm/boot/dts/omap3-n950-n9.dtsi
>>>> index 5441e9ffdbb4..e98b0c615f19 100644
>>>> --- a/arch/arm/boot/dts/omap3-n950-n9.dtsi
>>>> +++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
>>>> @@ -11,13 +11,6 @@
>>>> cpus {
>>>> cpu@0 {
>>>> cpu0-supply = <&vcc>;
>>>> - operating-points = <
>>>> - /* kHz uV */
>>>> - 300000 1012500
>>>> - 600000 1200000
>>>> - 800000 1325000
>>>> - 1000000 1375000
>>>> - >;
>>>> };
>>>> };
>>>
>>> This should be merged with 2/5 ?
>>
>> Well, it bloats 2/5.
>
> It is logically the right place to do this as that's where we are
> adding opp-v2.
Well, sometimes the philosophy of patches is to add something new
first and remove the old in a second separate patch if the system
can live with both. This makes it easier to digest single patches
(because they are smaller) and might also better pinpoint an issue
by bisect.
>
>> What I hope (I can't test) is that this opp-v1 table
>> is ignored if an opp-v2 table exists. So that it can be
>> removed by a separate follow-up patch.
>
> It should work as that's what we are doing in OPP core, but I still
> feel this better get merged with 2/5.
Ok, I see. Noted for RFCv2.
There will also be a big batch of changes for the compatible record
(omap3530->omap35xx, add omap34xx where needed) of ca. 10 board definition
DTS files. Should this then also become part of the new 2/5?
BR and thanks,
Nikolaus
^ permalink raw reply
* Re: [RFC 4/5] ARM: dts: omap3-n950-n9: remove opp-v1 table
From: Viresh Kumar @ 2019-09-03 6:14 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Benoît Cousson, Tony Lindgren, Rob Herring, Adam Ford,
André Roth, Mark Rutland, Rafael J. Wysocki, linux-omap,
devicetree, linux-kernel, linux-pm, letux-kernel, kernel
In-Reply-To: <8BC1AEC9-7B24-4C07-8659-16741D018164@goldelico.com>
On 03-09-19, 08:01, H. Nikolaus Schaller wrote:
>
> > Am 03.09.2019 um 04:36 schrieb Viresh Kumar <viresh.kumar@linaro.org>:
> >
> > On 02-09-19, 12:55, H. Nikolaus Schaller wrote:
> >> With opp-v2 in omap36xx.dtsi and ti-cpufreq driver the
> >> 1GHz capability is automatically detected.
> >>
> >> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> >> ---
> >> arch/arm/boot/dts/omap3-n950-n9.dtsi | 7 -------
> >> 1 file changed, 7 deletions(-)
> >>
> >> diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi b/arch/arm/boot/dts/omap3-n950-n9.dtsi
> >> index 5441e9ffdbb4..e98b0c615f19 100644
> >> --- a/arch/arm/boot/dts/omap3-n950-n9.dtsi
> >> +++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
> >> @@ -11,13 +11,6 @@
> >> cpus {
> >> cpu@0 {
> >> cpu0-supply = <&vcc>;
> >> - operating-points = <
> >> - /* kHz uV */
> >> - 300000 1012500
> >> - 600000 1200000
> >> - 800000 1325000
> >> - 1000000 1375000
> >> - >;
> >> };
> >> };
> >
> > This should be merged with 2/5 ?
>
> Well, it bloats 2/5.
It is logically the right place to do this as that's where we are
adding opp-v2.
> What I hope (I can't test) is that this opp-v1 table
> is ignored if an opp-v2 table exists. So that it can be
> removed by a separate follow-up patch.
It should work as that's what we are doing in OPP core, but I still
feel this better get merged with 2/5.
--
viresh
^ permalink raw reply
* Re: [RFC 4/5] ARM: dts: omap3-n950-n9: remove opp-v1 table
From: H. Nikolaus Schaller @ 2019-09-03 6:01 UTC (permalink / raw)
To: Viresh Kumar
Cc: Benoît Cousson, Tony Lindgren, Rob Herring, Adam Ford,
André Roth, Mark Rutland, Rafael J. Wysocki, linux-omap,
devicetree, linux-kernel, linux-pm, letux-kernel, kernel
In-Reply-To: <20190903023635.44yf32jowpm3hgfp@vireshk-i7>
> Am 03.09.2019 um 04:36 schrieb Viresh Kumar <viresh.kumar@linaro.org>:
>
> On 02-09-19, 12:55, H. Nikolaus Schaller wrote:
>> With opp-v2 in omap36xx.dtsi and ti-cpufreq driver the
>> 1GHz capability is automatically detected.
>>
>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>> ---
>> arch/arm/boot/dts/omap3-n950-n9.dtsi | 7 -------
>> 1 file changed, 7 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi b/arch/arm/boot/dts/omap3-n950-n9.dtsi
>> index 5441e9ffdbb4..e98b0c615f19 100644
>> --- a/arch/arm/boot/dts/omap3-n950-n9.dtsi
>> +++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
>> @@ -11,13 +11,6 @@
>> cpus {
>> cpu@0 {
>> cpu0-supply = <&vcc>;
>> - operating-points = <
>> - /* kHz uV */
>> - 300000 1012500
>> - 600000 1200000
>> - 800000 1325000
>> - 1000000 1375000
>> - >;
>> };
>> };
>
> This should be merged with 2/5 ?
Well, it bloats 2/5.
What I hope (I can't test) is that this opp-v1 table
is ignored if an opp-v2 table exists. So that it can be
removed by a separate follow-up patch.
BR,
Nikolaus
^ permalink raw reply
* Re: [RFC 2/5] ARM: dts: add support for opp-v2 for omap34xx and omap36xx
From: H. Nikolaus Schaller @ 2019-09-03 5:58 UTC (permalink / raw)
To: Viresh Kumar
Cc: Benoît Cousson, Tony Lindgren, Rob Herring, Adam Ford,
André Roth, Mark Rutland, Rafael J. Wysocki, linux-omap,
devicetree, linux-kernel, linux-pm, letux-kernel, kernel
In-Reply-To: <20190903023805.qum23m7tge3zkb5a@vireshk-i7>
> Am 03.09.2019 um 04:38 schrieb Viresh Kumar <viresh.kumar@linaro.org>:
>
> On 02-09-19, 12:55, H. Nikolaus Schaller wrote:
>> + opp1-125000000 {
>> + opp-hz = /bits/ 64 <125000000>;
>> + // we currently only select the max voltage from table Table 3-3 of the omap3530 Data sheet (SPRS507F)
>> + // <target min max> could also be single <target>
>> + opp-microvolt = <975000 975000 975000>;
>> + // first value is silicon revision, second one 720MHz Device Identification
>
>> + opp-supported-hw = <0xffffffff 3>;
>
> I don't see the driver changes using this field, am I missing
> something ?
This is parsed by _opp_is_supported() which is called
indirectly by ti_cpufreq_probe().
BR,
Nikolaus
^ permalink raw reply
* Re: [RFC 2/5] ARM: dts: add support for opp-v2 for omap34xx and omap36xx
From: Viresh Kumar @ 2019-09-03 2:39 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Benoît Cousson, Tony Lindgren, Rob Herring, Adam Ford,
André Roth, Mark Rutland, Rafael J. Wysocki, linux-omap,
devicetree, linux-kernel, linux-pm, letux-kernel, kernel
In-Reply-To: <20190903023805.qum23m7tge3zkb5a@vireshk-i7>
On 03-09-19, 08:08, Viresh Kumar wrote:
> On 02-09-19, 12:55, H. Nikolaus Schaller wrote:
> > + opp1-125000000 {
> > + opp-hz = /bits/ 64 <125000000>;
> > + // we currently only select the max voltage from table Table 3-3 of the omap3530 Data sheet (SPRS507F)
> > + // <target min max> could also be single <target>
> > + opp-microvolt = <975000 975000 975000>;
> > + // first value is silicon revision, second one 720MHz Device Identification
>
> > + opp-supported-hw = <0xffffffff 3>;
>
> I don't see the driver changes using this field, am I missing
> something ?
The driver already had them it seems. Hmm..
--
viresh
^ permalink raw reply
* Re: [RFC 2/5] ARM: dts: add support for opp-v2 for omap34xx and omap36xx
From: Viresh Kumar @ 2019-09-03 2:38 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Benoît Cousson, Tony Lindgren, Rob Herring, Adam Ford,
André Roth, Mark Rutland, Rafael J. Wysocki, linux-omap,
devicetree, linux-kernel, linux-pm, letux-kernel, kernel
In-Reply-To: <d0dc1623ed6b1bd657f169dc2b4482b269bdba37.1567421751.git.hns@goldelico.com>
On 02-09-19, 12:55, H. Nikolaus Schaller wrote:
> + opp1-125000000 {
> + opp-hz = /bits/ 64 <125000000>;
> + // we currently only select the max voltage from table Table 3-3 of the omap3530 Data sheet (SPRS507F)
> + // <target min max> could also be single <target>
> + opp-microvolt = <975000 975000 975000>;
> + // first value is silicon revision, second one 720MHz Device Identification
> + opp-supported-hw = <0xffffffff 3>;
I don't see the driver changes using this field, am I missing
something ?
--
viresh
^ permalink raw reply
* Re: [RFC 4/5] ARM: dts: omap3-n950-n9: remove opp-v1 table
From: Viresh Kumar @ 2019-09-03 2:36 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Benoît Cousson, Tony Lindgren, Rob Herring, Adam Ford,
André Roth, Mark Rutland, Rafael J. Wysocki, linux-omap,
devicetree, linux-kernel, linux-pm, letux-kernel, kernel
In-Reply-To: <2f978667c1533e46e3a5df58871e9048f3eb74e9.1567421751.git.hns@goldelico.com>
On 02-09-19, 12:55, H. Nikolaus Schaller wrote:
> With opp-v2 in omap36xx.dtsi and ti-cpufreq driver the
> 1GHz capability is automatically detected.
>
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> ---
> arch/arm/boot/dts/omap3-n950-n9.dtsi | 7 -------
> 1 file changed, 7 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi b/arch/arm/boot/dts/omap3-n950-n9.dtsi
> index 5441e9ffdbb4..e98b0c615f19 100644
> --- a/arch/arm/boot/dts/omap3-n950-n9.dtsi
> +++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
> @@ -11,13 +11,6 @@
> cpus {
> cpu@0 {
> cpu0-supply = <&vcc>;
> - operating-points = <
> - /* kHz uV */
> - 300000 1012500
> - 600000 1200000
> - 800000 1325000
> - 1000000 1375000
> - >;
> };
> };
This should be merged with 2/5 ?
--
viresh
^ permalink raw reply
* Re: [PATCH v3 1/6] bus/ti-pwmss: move TI PWMSS driver from PWM to bus subsystem
From: Thierry Reding @ 2019-09-02 15:02 UTC (permalink / raw)
To: David Lechner
Cc: linux-iio, linux-omap, Rob Herring, Mark Rutland,
Benoît Cousson, Tony Lindgren, William Breathitt Gray,
devicetree, linux-kernel, linux-pwm
In-Reply-To: <20190901225827.12301-2-david@lechnology.com>
[-- Attachment #1: Type: text/plain, Size: 989 bytes --]
On Sun, Sep 01, 2019 at 05:58:22PM -0500, David Lechner wrote:
> The TI PWMSS driver is a simple bus driver for providing power
> power management for the PWM peripherals on TI AM33xx SoCs, namely
> eCAP, eHRPWM and eQEP. The eQEP is a counter rather than a PWM, so
> it does not make sense to have the bus driver in the PWM subsystem
> since the PWMSS is not exclusive to PWM devices.
>
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
>
> v3 changes:
> - none
> v2 changes:
> - new patch
>
> drivers/bus/Kconfig | 9 +++++++++
> drivers/bus/Makefile | 1 +
> drivers/{pwm/pwm-tipwmss.c => bus/ti-pwmss.c} | 0
> drivers/pwm/Kconfig | 9 ---------
> drivers/pwm/Makefile | 1 -
> 5 files changed, 10 insertions(+), 10 deletions(-)
> rename drivers/{pwm/pwm-tipwmss.c => bus/ti-pwmss.c} (100%)
Acked-by: Thierry Reding <thierry.reding@gmail.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/6] dt-bindings: counter: new bindings for TI eQEP
From: Rob Herring @ 2019-09-02 15:02 UTC (permalink / raw)
Cc: linux-iio, linux-omap, David Lechner, Mark Rutland,
Benoît Cousson, Tony Lindgren, William Breathitt Gray,
Thierry Reding, devicetree, linux-kernel, linux-pwm
In-Reply-To: <20190901225827.12301-3-david@lechnology.com>
On Sun, 1 Sep 2019 17:58:23 -0500, David Lechner wrote:
> This documents device tree binding for the Texas Instruments Enhanced
> Quadrature Encoder Pulse (eQEP) Module found in various TI SoCs.
>
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
>
> v3 changes:
> - fixed style issues
> - fixed generic node name
> - (was suggested to drop descriptions since there is only one interrupt and one
> clock, but I opted to keep them anyway)
> v2 changes:
> - convert to .yaml format
> - rename clock to "sysclkout"
>
> .../devicetree/bindings/counter/ti-eqep.yaml | 50 +++++++++++++++++++
> 1 file changed, 50 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/counter/ti-eqep.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox