Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1630181 > unrolled thread

Re: [PATCH V3 4/4] soc/tegra: pmc: Use the new reset APIs to manage reset controllers

Started byVivek Gautam <vivek.gautam@codeaurora.org>
First post2017-04-25 06:20 +0200
Last post2017-04-25 20:00 +0200
Articles 7 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH V3 4/4] soc/tegra: pmc: Use the new reset APIs to manage  reset controllers Vivek Gautam <vivek.gautam@codeaurora.org> - 2017-04-25 06:20 +0200
    Re: [PATCH V3 4/4] soc/tegra: pmc: Use the new reset APIs to manage  reset controllers Jon Hunter <jonathanh@nvidia.com> - 2017-04-25 12:10 +0200
      Re: [PATCH V3 4/4] soc/tegra: pmc: Use the new reset APIs to manage  reset controllers Philipp Zabel <p.zabel@pengutronix.de> - 2017-04-25 12:40 +0200
        Re: [PATCH V3 4/4] soc/tegra: pmc: Use the new reset APIs to manage  reset controllers Jon Hunter <jonathanh@nvidia.com> - 2017-04-25 13:00 +0200
          Re: [PATCH V3 4/4] soc/tegra: pmc: Use the new reset APIs to manage  reset controllers Vivek Gautam <vivek.gautam@codeaurora.org> - 2017-04-25 13:10 +0200
            Re: [PATCH V3 4/4] soc/tegra: pmc: Use the new reset APIs to manage  reset controllers Jon Hunter <jonathanh@nvidia.com> - 2017-04-25 13:20 +0200
              Re: [PATCH V3 4/4] soc/tegra: pmc: Use the new reset APIs to manage  reset controllers Vivek Gautam <vivek.gautam@codeaurora.org> - 2017-04-25 20:00 +0200

#1630181 — Re: [PATCH V3 4/4] soc/tegra: pmc: Use the new reset APIs to manage reset controllers

FromVivek Gautam <vivek.gautam@codeaurora.org>
Date2017-04-25 06:20 +0200
SubjectRe: [PATCH V3 4/4] soc/tegra: pmc: Use the new reset APIs to manage reset controllers
Message-ID<tA07g-87x-7@gated-at.bofh.it>

On 04/24/2017 06:15 PM, Jon Hunter wrote:
> On 18/04/17 12:21, Vivek Gautam wrote:
>> Make use of reset_control_array_*() set of APIs to manage
>> an array of reset controllers available with the device.
> Before we apply this patch, I need to check to see if the order of the
> resets managed by the PMC driver matter. Today the order of the resets
> is determined by the order they appear in the DT node and although the
> new APIs work in the same way they do not guarantee this. So let me
> check to see if we can any concerns about ordering here. Otherwise would
> be nice to use these APIs.

Right, that will be perfect.

Best regards
Vivek

>
> Cheers
> Jon
>

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[toc] | [next] | [standalone]

#1630355

FromJon Hunter <jonathanh@nvidia.com>
Date2017-04-25 12:10 +0200
Message-ID<tA5zX-3kk-1@gated-at.bofh.it>
In reply to#1630181
On 25/04/17 05:15, Vivek Gautam wrote:
> On 04/24/2017 06:15 PM, Jon Hunter wrote:
>> On 18/04/17 12:21, Vivek Gautam wrote:
>>> Make use of reset_control_array_*() set of APIs to manage
>>> an array of reset controllers available with the device.
>> Before we apply this patch, I need to check to see if the order of the
>> resets managed by the PMC driver matter. Today the order of the resets
>> is determined by the order they appear in the DT node and although the
>> new APIs work in the same way they do not guarantee this. So let me
>> check to see if we can any concerns about ordering here. Otherwise would
>> be nice to use these APIs.
> 
> Right, that will be perfect.

So I don't see any restrictions here and so I think this change is fine.

BTW, for the DT case, is there any reason why we don't just say the
order will be determine by the order the resets are list in the DT node?

Cheers
Jon

-- 
nvpublic

[toc] | [prev] | [next] | [standalone]

#1630392

FromPhilipp Zabel <p.zabel@pengutronix.de>
Date2017-04-25 12:40 +0200
Message-ID<tA631-3ve-29@gated-at.bofh.it>
In reply to#1630355
On Tue, 2017-04-25 at 11:05 +0100, Jon Hunter wrote:
> On 25/04/17 05:15, Vivek Gautam wrote:
> > On 04/24/2017 06:15 PM, Jon Hunter wrote:
> >> On 18/04/17 12:21, Vivek Gautam wrote:
> >>> Make use of reset_control_array_*() set of APIs to manage
> >>> an array of reset controllers available with the device.
> >> Before we apply this patch, I need to check to see if the order of the
> >> resets managed by the PMC driver matter. Today the order of the resets
> >> is determined by the order they appear in the DT node and although the
> >> new APIs work in the same way they do not guarantee this. So let me
> >> check to see if we can any concerns about ordering here. Otherwise would
> >> be nice to use these APIs.
> > 
> > Right, that will be perfect.
> 
> So I don't see any restrictions here and so I think this change is fine.

Thank you for checking.

> BTW, for the DT case, is there any reason why we don't just say the
> order will be determine by the order the resets are list in the DT node?

I'd rather not make any promises, so I don't have to care about keeping
them. This makes it easier to think about and allows for more freedom in
changing the core code if needed.

What if in the future there is a use case for enabling a bunch of resets
by flipping a number of bits in a single register at the same time? Or
if people accidentally depend on the ordering when in reality there is a
small delay necessary between assertions that just happens to be hidden
by the framework overhead?

If there is a use case for an array of reset controls that must be
(de)asserted in a fixed order and doesn't need any delay between the
steps and is not suitable to be described by named resets for some
reason, we can discuss this. Until then, I'm happy that tegra pmc can
handle arrays without any particular ordering.

regards
Philipp

[toc] | [prev] | [next] | [standalone]

#1630397

FromJon Hunter <jonathanh@nvidia.com>
Date2017-04-25 13:00 +0200
Message-ID<tA6mm-3Ce-13@gated-at.bofh.it>
In reply to#1630392
On 25/04/17 11:33, Philipp Zabel wrote:
> On Tue, 2017-04-25 at 11:05 +0100, Jon Hunter wrote:
>> On 25/04/17 05:15, Vivek Gautam wrote:
>>> On 04/24/2017 06:15 PM, Jon Hunter wrote:
>>>> On 18/04/17 12:21, Vivek Gautam wrote:
>>>>> Make use of reset_control_array_*() set of APIs to manage
>>>>> an array of reset controllers available with the device.
>>>> Before we apply this patch, I need to check to see if the order of the
>>>> resets managed by the PMC driver matter. Today the order of the resets
>>>> is determined by the order they appear in the DT node and although the
>>>> new APIs work in the same way they do not guarantee this. So let me
>>>> check to see if we can any concerns about ordering here. Otherwise would
>>>> be nice to use these APIs.
>>>
>>> Right, that will be perfect.
>>
>> So I don't see any restrictions here and so I think this change is fine.
> 
> Thank you for checking.
> 
>> BTW, for the DT case, is there any reason why we don't just say the
>> order will be determine by the order the resets are list in the DT node?
> 
> I'd rather not make any promises, so I don't have to care about keeping
> them. This makes it easier to think about and allows for more freedom in
> changing the core code if needed.
> 
> What if in the future there is a use case for enabling a bunch of resets
> by flipping a number of bits in a single register at the same time? Or
> if people accidentally depend on the ordering when in reality there is a
> small delay necessary between assertions that just happens to be hidden
> by the framework overhead?
> 
> If there is a use case for an array of reset controls that must be
> (de)asserted in a fixed order and doesn't need any delay between the
> steps and is not suitable to be described by named resets for some
> reason, we can discuss this. Until then, I'm happy that tegra pmc can
> handle arrays without any particular ordering.

OK, makes sense.

Thanks
Jon

-- 
nvpublic

[toc] | [prev] | [next] | [standalone]

#1630404

FromVivek Gautam <vivek.gautam@codeaurora.org>
Date2017-04-25 13:10 +0200
Message-ID<tA6w2-3UP-13@gated-at.bofh.it>
In reply to#1630397

On 04/25/2017 04:24 PM, Jon Hunter wrote:
> On 25/04/17 11:33, Philipp Zabel wrote:
>> On Tue, 2017-04-25 at 11:05 +0100, Jon Hunter wrote:
>>> On 25/04/17 05:15, Vivek Gautam wrote:
>>>> On 04/24/2017 06:15 PM, Jon Hunter wrote:
>>>>> On 18/04/17 12:21, Vivek Gautam wrote:
>>>>>> Make use of reset_control_array_*() set of APIs to manage
>>>>>> an array of reset controllers available with the device.
>>>>> Before we apply this patch, I need to check to see if the order of the
>>>>> resets managed by the PMC driver matter. Today the order of the resets
>>>>> is determined by the order they appear in the DT node and although the
>>>>> new APIs work in the same way they do not guarantee this. So let me
>>>>> check to see if we can any concerns about ordering here. Otherwise would
>>>>> be nice to use these APIs.
>>>> Right, that will be perfect.
>>> So I don't see any restrictions here and so I think this change is fine.
>> Thank you for checking.
>>
>>> BTW, for the DT case, is there any reason why we don't just say the
>>> order will be determine by the order the resets are list in the DT node?
>> I'd rather not make any promises, so I don't have to care about keeping
>> them. This makes it easier to think about and allows for more freedom in
>> changing the core code if needed.
>>
>> What if in the future there is a use case for enabling a bunch of resets
>> by flipping a number of bits in a single register at the same time? Or
>> if people accidentally depend on the ordering when in reality there is a
>> small delay necessary between assertions that just happens to be hidden
>> by the framework overhead?
>>
>> If there is a use case for an array of reset controls that must be
>> (de)asserted in a fixed order and doesn't need any delay between the
>> steps and is not suitable to be described by named resets for some
>> reason, we can discuss this. Until then, I'm happy that tegra pmc can
>> handle arrays without any particular ordering.
> OK, makes sense.

Thanks Jon for testing this.

Best Regards
Vivek
>
> Thanks
> Jon
>

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[toc] | [prev] | [next] | [standalone]

#1630410

FromJon Hunter <jonathanh@nvidia.com>
Date2017-04-25 13:20 +0200
Message-ID<tA6FI-3Yq-11@gated-at.bofh.it>
In reply to#1630404
On 25/04/17 12:06, Vivek Gautam wrote:
> On 04/25/2017 04:24 PM, Jon Hunter wrote:
>> On 25/04/17 11:33, Philipp Zabel wrote:
>>> On Tue, 2017-04-25 at 11:05 +0100, Jon Hunter wrote:
>>>> On 25/04/17 05:15, Vivek Gautam wrote:
>>>>> On 04/24/2017 06:15 PM, Jon Hunter wrote:
>>>>>> On 18/04/17 12:21, Vivek Gautam wrote:
>>>>>>> Make use of reset_control_array_*() set of APIs to manage
>>>>>>> an array of reset controllers available with the device.
>>>>>> Before we apply this patch, I need to check to see if the order of
>>>>>> the
>>>>>> resets managed by the PMC driver matter. Today the order of the
>>>>>> resets
>>>>>> is determined by the order they appear in the DT node and although
>>>>>> the
>>>>>> new APIs work in the same way they do not guarantee this. So let me
>>>>>> check to see if we can any concerns about ordering here. Otherwise
>>>>>> would
>>>>>> be nice to use these APIs.
>>>>> Right, that will be perfect.
>>>> So I don't see any restrictions here and so I think this change is
>>>> fine.
>>> Thank you for checking.
>>>
>>>> BTW, for the DT case, is there any reason why we don't just say the
>>>> order will be determine by the order the resets are list in the DT
>>>> node?
>>> I'd rather not make any promises, so I don't have to care about keeping
>>> them. This makes it easier to think about and allows for more freedom in
>>> changing the core code if needed.
>>>
>>> What if in the future there is a use case for enabling a bunch of resets
>>> by flipping a number of bits in a single register at the same time? Or
>>> if people accidentally depend on the ordering when in reality there is a
>>> small delay necessary between assertions that just happens to be hidden
>>> by the framework overhead?
>>>
>>> If there is a use case for an array of reset controls that must be
>>> (de)asserted in a fixed order and doesn't need any delay between the
>>> steps and is not suitable to be described by named resets for some
>>> reason, we can discuss this. Until then, I'm happy that tegra pmc can
>>> handle arrays without any particular ordering.
>> OK, makes sense.
> 
> Thanks Jon for testing this.

Not tested yet :-)

However, I will test this just to confirm. Are you planning on sending
out a v4 soon?

Jon

-- 
nvpublic

[toc] | [prev] | [next] | [standalone]

#1630838

FromVivek Gautam <vivek.gautam@codeaurora.org>
Date2017-04-25 20:00 +0200
Message-ID<tAcUO-7ME-21@gated-at.bofh.it>
In reply to#1630410
On Tue, Apr 25, 2017 at 4:41 PM, Jon Hunter <jonathanh@nvidia.com> wrote:
>
> On 25/04/17 12:06, Vivek Gautam wrote:
>> On 04/25/2017 04:24 PM, Jon Hunter wrote:
>>> On 25/04/17 11:33, Philipp Zabel wrote:
>>>> On Tue, 2017-04-25 at 11:05 +0100, Jon Hunter wrote:
>>>>> On 25/04/17 05:15, Vivek Gautam wrote:
>>>>>> On 04/24/2017 06:15 PM, Jon Hunter wrote:
>>>>>>> On 18/04/17 12:21, Vivek Gautam wrote:
>>>>>>>> Make use of reset_control_array_*() set of APIs to manage
>>>>>>>> an array of reset controllers available with the device.
>>>>>>> Before we apply this patch, I need to check to see if the order of
>>>>>>> the
>>>>>>> resets managed by the PMC driver matter. Today the order of the
>>>>>>> resets
>>>>>>> is determined by the order they appear in the DT node and although
>>>>>>> the
>>>>>>> new APIs work in the same way they do not guarantee this. So let me
>>>>>>> check to see if we can any concerns about ordering here. Otherwise
>>>>>>> would
>>>>>>> be nice to use these APIs.
>>>>>> Right, that will be perfect.
>>>>> So I don't see any restrictions here and so I think this change is
>>>>> fine.
>>>> Thank you for checking.
>>>>
>>>>> BTW, for the DT case, is there any reason why we don't just say the
>>>>> order will be determine by the order the resets are list in the DT
>>>>> node?
>>>> I'd rather not make any promises, so I don't have to care about keeping
>>>> them. This makes it easier to think about and allows for more freedom in
>>>> changing the core code if needed.
>>>>
>>>> What if in the future there is a use case for enabling a bunch of resets
>>>> by flipping a number of bits in a single register at the same time? Or
>>>> if people accidentally depend on the ordering when in reality there is a
>>>> small delay necessary between assertions that just happens to be hidden
>>>> by the framework overhead?
>>>>
>>>> If there is a use case for an array of reset controls that must be
>>>> (de)asserted in a fixed order and doesn't need any delay between the
>>>> steps and is not suitable to be described by named resets for some
>>>> reason, we can discuss this. Until then, I'm happy that tegra pmc can
>>>> handle arrays without any particular ordering.
>>> OK, makes sense.
>>
>> Thanks Jon for testing this.
>
> Not tested yet :-)
>
> However, I will test this just to confirm. Are you planning on sending
> out a v4 soon?

Yes, I will send a v4 soon this week.

Thanks
Vivek


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web