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

Groups > linux.kernel > #1591478 > unrolled thread

Re: [PATCH] clk: tegra: mark TEGRA210_CLK_DBGAPB as always on

Started byJon Hunter <jonathanh@nvidia.com>
First post2017-03-02 22:30 +0100
Last post2017-03-13 11:50 +0100
Articles 15 — 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] clk: tegra: mark TEGRA210_CLK_DBGAPB as always on Jon Hunter <jonathanh@nvidia.com> - 2017-03-02 22:30 +0100
    Re: [PATCH] clk: tegra: mark TEGRA210_CLK_DBGAPB as always on Peter De Schrijver <pdeschrijver@nvidia.com> - 2017-03-06 09:40 +0100
      Re: [PATCH] clk: tegra: mark TEGRA210_CLK_DBGAPB as always on Jon Hunter <jonathanh@nvidia.com> - 2017-03-06 11:10 +0100
        Re: [PATCH] clk: tegra: mark TEGRA210_CLK_DBGAPB as always on Peter De Schrijver <pdeschrijver@nvidia.com> - 2017-03-06 15:40 +0100
          Re: [PATCH] clk: tegra: mark TEGRA210_CLK_DBGAPB as always on Jon Hunter <jonathanh@nvidia.com> - 2017-03-06 17:00 +0100
          Re: [PATCH] clk: tegra: mark TEGRA210_CLK_DBGAPB as always on Geert Uytterhoeven <geert@linux-m68k.org> - 2017-03-06 18:00 +0100
            Re: [PATCH] clk: tegra: mark TEGRA210_CLK_DBGAPB as always on Jon Hunter <jonathanh@nvidia.com> - 2017-03-07 21:30 +0100
              Re: [PATCH] clk: tegra: mark TEGRA210_CLK_DBGAPB as always on Geert Uytterhoeven <geert@linux-m68k.org> - 2017-03-08 11:20 +0100
            Re: [PATCH] clk: tegra: mark TEGRA210_CLK_DBGAPB as always on Jon Hunter <jonathanh@nvidia.com> - 2017-03-08 12:30 +0100
              Re: [PATCH] clk: tegra: mark TEGRA210_CLK_DBGAPB as always on Geert Uytterhoeven <geert@linux-m68k.org> - 2017-03-08 12:50 +0100
                Re: [PATCH] clk: tegra: mark TEGRA210_CLK_DBGAPB as always on Jon Hunter <jonathanh@nvidia.com> - 2017-03-08 13:20 +0100
                  Re: [PATCH] clk: tegra: mark TEGRA210_CLK_DBGAPB as always on Peter De Schrijver <pdeschrijver@nvidia.com> - 2017-03-13 11:50 +0100
                    Re: [PATCH] clk: tegra: mark TEGRA210_CLK_DBGAPB as always on Jon Hunter <jonathanh@nvidia.com> - 2017-03-13 12:10 +0100
                      Re: [PATCH] clk: tegra: mark TEGRA210_CLK_DBGAPB as always on Peter De Schrijver <pdeschrijver@nvidia.com> - 2017-03-13 15:20 +0100
            Re: [PATCH] clk: tegra: mark TEGRA210_CLK_DBGAPB as always on Peter De Schrijver <pdeschrijver@nvidia.com> - 2017-03-13 11:50 +0100

#1591478 — Re: [PATCH] clk: tegra: mark TEGRA210_CLK_DBGAPB as always on

FromJon Hunter <jonathanh@nvidia.com>
Date2017-03-02 22:30 +0100
SubjectRe: [PATCH] clk: tegra: mark TEGRA210_CLK_DBGAPB as always on
Message-ID<tgGsq-852-23@gated-at.bofh.it>
On 28/02/17 15:19, Peter De Schrijver wrote:
> This is needed to make the JTAG debugging interface work.
> 
> Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
> ---
>  drivers/clk/tegra/clk-tegra210.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/clk/tegra/clk-tegra210.c b/drivers/clk/tegra/clk-tegra210.c
> index 9a2512a..708f5f1 100644
> --- a/drivers/clk/tegra/clk-tegra210.c
> +++ b/drivers/clk/tegra/clk-tegra210.c
> @@ -2680,6 +2680,7 @@ static void tegra210_cpu_clock_resume(void)
>  	{ TEGRA210_CLK_EMC, TEGRA210_CLK_CLK_MAX, 0, 1 },
>  	{ TEGRA210_CLK_MSELECT, TEGRA210_CLK_CLK_MAX, 0, 1 },
>  	{ TEGRA210_CLK_CSITE, TEGRA210_CLK_CLK_MAX, 0, 1 },
> +	{ TEGRA210_CLK_DBGAPB, TEGRA210_CLK_CLK_MAX, 0, 1 },
>  	{ TEGRA210_CLK_TSENSOR, TEGRA210_CLK_CLK_M, 400000, 0 },
>  	{ TEGRA210_CLK_I2C1, TEGRA210_CLK_PLL_P, 0, 0 },
>  	{ TEGRA210_CLK_I2C2, TEGRA210_CLK_PLL_P, 0, 0 },

Should there be some dependency on say CONFIG_DEBUG_KERNEL? I am not
sure we always want this on for all cases.

Cheers
Jon

-- 
nvpublic

[toc] | [next] | [standalone]

#1592991

FromPeter De Schrijver <pdeschrijver@nvidia.com>
Date2017-03-06 09:40 +0100
Message-ID<thWls-5tJ-17@gated-at.bofh.it>
In reply to#1591478
On Thu, Mar 02, 2017 at 05:56:49PM +0000, Jon Hunter wrote:
> 
> On 28/02/17 15:19, Peter De Schrijver wrote:
> > This is needed to make the JTAG debugging interface work.
> > 
> > Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
> > ---
> >  drivers/clk/tegra/clk-tegra210.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/clk/tegra/clk-tegra210.c b/drivers/clk/tegra/clk-tegra210.c
> > index 9a2512a..708f5f1 100644
> > --- a/drivers/clk/tegra/clk-tegra210.c
> > +++ b/drivers/clk/tegra/clk-tegra210.c
> > @@ -2680,6 +2680,7 @@ static void tegra210_cpu_clock_resume(void)
> >  	{ TEGRA210_CLK_EMC, TEGRA210_CLK_CLK_MAX, 0, 1 },
> >  	{ TEGRA210_CLK_MSELECT, TEGRA210_CLK_CLK_MAX, 0, 1 },
> >  	{ TEGRA210_CLK_CSITE, TEGRA210_CLK_CLK_MAX, 0, 1 },
> > +	{ TEGRA210_CLK_DBGAPB, TEGRA210_CLK_CLK_MAX, 0, 1 },
> >  	{ TEGRA210_CLK_TSENSOR, TEGRA210_CLK_CLK_M, 400000, 0 },
> >  	{ TEGRA210_CLK_I2C1, TEGRA210_CLK_PLL_P, 0, 0 },
> >  	{ TEGRA210_CLK_I2C2, TEGRA210_CLK_PLL_P, 0, 0 },
> 
> Should there be some dependency on say CONFIG_DEBUG_KERNEL? I am not
> sure we always want this on for all cases.

Why would you not want it to be always on?

Cheers,

Peter.

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

#1593142

FromJon Hunter <jonathanh@nvidia.com>
Date2017-03-06 11:10 +0100
Message-ID<thXKy-6FK-19@gated-at.bofh.it>
In reply to#1592991
On 06/03/17 08:38, Peter De Schrijver wrote:
> On Thu, Mar 02, 2017 at 05:56:49PM +0000, Jon Hunter wrote:
>>
>> On 28/02/17 15:19, Peter De Schrijver wrote:
>>> This is needed to make the JTAG debugging interface work.
>>>
>>> Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
>>> ---
>>>  drivers/clk/tegra/clk-tegra210.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/clk/tegra/clk-tegra210.c b/drivers/clk/tegra/clk-tegra210.c
>>> index 9a2512a..708f5f1 100644
>>> --- a/drivers/clk/tegra/clk-tegra210.c
>>> +++ b/drivers/clk/tegra/clk-tegra210.c
>>> @@ -2680,6 +2680,7 @@ static void tegra210_cpu_clock_resume(void)
>>>  	{ TEGRA210_CLK_EMC, TEGRA210_CLK_CLK_MAX, 0, 1 },
>>>  	{ TEGRA210_CLK_MSELECT, TEGRA210_CLK_CLK_MAX, 0, 1 },
>>>  	{ TEGRA210_CLK_CSITE, TEGRA210_CLK_CLK_MAX, 0, 1 },
>>> +	{ TEGRA210_CLK_DBGAPB, TEGRA210_CLK_CLK_MAX, 0, 1 },
>>>  	{ TEGRA210_CLK_TSENSOR, TEGRA210_CLK_CLK_M, 400000, 0 },
>>>  	{ TEGRA210_CLK_I2C1, TEGRA210_CLK_PLL_P, 0, 0 },
>>>  	{ TEGRA210_CLK_I2C2, TEGRA210_CLK_PLL_P, 0, 0 },
>>
>> Should there be some dependency on say CONFIG_DEBUG_KERNEL? I am not
>> sure we always want this on for all cases.
> 
> Why would you not want it to be always on?

Purely for power reasons. I do not know how much power keeping this
clock running consumes, but I don't like the idea of clocks running all
the time when they are not needed.

Jon

-- 
nvpublic

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

#1593436

FromPeter De Schrijver <pdeschrijver@nvidia.com>
Date2017-03-06 15:40 +0100
Message-ID<ti1XQ-146-39@gated-at.bofh.it>
In reply to#1593142
On Mon, Mar 06, 2017 at 09:58:29AM +0000, Jon Hunter wrote:
> 
> On 06/03/17 08:38, Peter De Schrijver wrote:
> > On Thu, Mar 02, 2017 at 05:56:49PM +0000, Jon Hunter wrote:
> >>
> >> On 28/02/17 15:19, Peter De Schrijver wrote:
> >>> This is needed to make the JTAG debugging interface work.
> >>>
> >>> Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
> >>> ---
> >>>  drivers/clk/tegra/clk-tegra210.c | 1 +
> >>>  1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/drivers/clk/tegra/clk-tegra210.c b/drivers/clk/tegra/clk-tegra210.c
> >>> index 9a2512a..708f5f1 100644
> >>> --- a/drivers/clk/tegra/clk-tegra210.c
> >>> +++ b/drivers/clk/tegra/clk-tegra210.c
> >>> @@ -2680,6 +2680,7 @@ static void tegra210_cpu_clock_resume(void)
> >>>  	{ TEGRA210_CLK_EMC, TEGRA210_CLK_CLK_MAX, 0, 1 },
> >>>  	{ TEGRA210_CLK_MSELECT, TEGRA210_CLK_CLK_MAX, 0, 1 },
> >>>  	{ TEGRA210_CLK_CSITE, TEGRA210_CLK_CLK_MAX, 0, 1 },
> >>> +	{ TEGRA210_CLK_DBGAPB, TEGRA210_CLK_CLK_MAX, 0, 1 },
> >>>  	{ TEGRA210_CLK_TSENSOR, TEGRA210_CLK_CLK_M, 400000, 0 },
> >>>  	{ TEGRA210_CLK_I2C1, TEGRA210_CLK_PLL_P, 0, 0 },
> >>>  	{ TEGRA210_CLK_I2C2, TEGRA210_CLK_PLL_P, 0, 0 },
> >>
> >> Should there be some dependency on say CONFIG_DEBUG_KERNEL? I am not
> >> sure we always want this on for all cases.
> > 
> > Why would you not want it to be always on?
> 
> Purely for power reasons. I do not know how much power keeping this

I don't expect it to be significant but I don't have any numbers.

> clock running consumes, but I don't like the idea of clocks running all
> the time when they are not needed.
> 

Problem is that in this case there is no easy way to determine if the clock
needs to be on.

Peter.

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

#1593487

FromJon Hunter <jonathanh@nvidia.com>
Date2017-03-06 17:00 +0100
Message-ID<ti3df-1Ug-1@gated-at.bofh.it>
In reply to#1593436
On 06/03/17 14:28, Peter De Schrijver wrote:
> On Mon, Mar 06, 2017 at 09:58:29AM +0000, Jon Hunter wrote:
>>
>> On 06/03/17 08:38, Peter De Schrijver wrote:
>>> On Thu, Mar 02, 2017 at 05:56:49PM +0000, Jon Hunter wrote:
>>>>
>>>> On 28/02/17 15:19, Peter De Schrijver wrote:
>>>>> This is needed to make the JTAG debugging interface work.
>>>>>
>>>>> Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
>>>>> ---
>>>>>  drivers/clk/tegra/clk-tegra210.c | 1 +
>>>>>  1 file changed, 1 insertion(+)
>>>>>
>>>>> diff --git a/drivers/clk/tegra/clk-tegra210.c b/drivers/clk/tegra/clk-tegra210.c
>>>>> index 9a2512a..708f5f1 100644
>>>>> --- a/drivers/clk/tegra/clk-tegra210.c
>>>>> +++ b/drivers/clk/tegra/clk-tegra210.c
>>>>> @@ -2680,6 +2680,7 @@ static void tegra210_cpu_clock_resume(void)
>>>>>  	{ TEGRA210_CLK_EMC, TEGRA210_CLK_CLK_MAX, 0, 1 },
>>>>>  	{ TEGRA210_CLK_MSELECT, TEGRA210_CLK_CLK_MAX, 0, 1 },
>>>>>  	{ TEGRA210_CLK_CSITE, TEGRA210_CLK_CLK_MAX, 0, 1 },
>>>>> +	{ TEGRA210_CLK_DBGAPB, TEGRA210_CLK_CLK_MAX, 0, 1 },
>>>>>  	{ TEGRA210_CLK_TSENSOR, TEGRA210_CLK_CLK_M, 400000, 0 },
>>>>>  	{ TEGRA210_CLK_I2C1, TEGRA210_CLK_PLL_P, 0, 0 },
>>>>>  	{ TEGRA210_CLK_I2C2, TEGRA210_CLK_PLL_P, 0, 0 },
>>>>
>>>> Should there be some dependency on say CONFIG_DEBUG_KERNEL? I am not
>>>> sure we always want this on for all cases.
>>>
>>> Why would you not want it to be always on?
>>
>> Purely for power reasons. I do not know how much power keeping this
> 
> I don't expect it to be significant but I don't have any numbers.
> 
>> clock running consumes, but I don't like the idea of clocks running all
>> the time when they are not needed.
>>
> 
> Problem is that in this case there is no easy way to determine if the clock
> needs to be on.

Yes I understand, but if we just enable it, people may assume that this
clock always needs to be on without knowing that it is optional and it
is safe to disable if you are not using JTAG.

So at a minimum we should have a comment about this. What about adding a
CONFIG_TEGRA_ENABLE_JTAG option? I would be ok with the default being
enabled.

Cheers
Jon

-- 
nvpublic

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

#1593537

FromGeert Uytterhoeven <geert@linux-m68k.org>
Date2017-03-06 18:00 +0100
Message-ID<ti49j-2x3-11@gated-at.bofh.it>
In reply to#1593436
Hi Peter,

On Mon, Mar 6, 2017 at 3:28 PM, Peter De Schrijver
<pdeschrijver@nvidia.com> wrote:
> On Mon, Mar 06, 2017 at 09:58:29AM +0000, Jon Hunter wrote:
>> On 06/03/17 08:38, Peter De Schrijver wrote:
>> > On Thu, Mar 02, 2017 at 05:56:49PM +0000, Jon Hunter wrote:
>> >> On 28/02/17 15:19, Peter De Schrijver wrote:
>> >>> This is needed to make the JTAG debugging interface work.
>> >>>
>> >>> Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
>> >>> ---
>> >>>  drivers/clk/tegra/clk-tegra210.c | 1 +
>> >>>  1 file changed, 1 insertion(+)
>> >>>
>> >>> diff --git a/drivers/clk/tegra/clk-tegra210.c b/drivers/clk/tegra/clk-tegra210.c
>> >>> index 9a2512a..708f5f1 100644
>> >>> --- a/drivers/clk/tegra/clk-tegra210.c
>> >>> +++ b/drivers/clk/tegra/clk-tegra210.c
>> >>> @@ -2680,6 +2680,7 @@ static void tegra210_cpu_clock_resume(void)
>> >>>   { TEGRA210_CLK_EMC, TEGRA210_CLK_CLK_MAX, 0, 1 },
>> >>>   { TEGRA210_CLK_MSELECT, TEGRA210_CLK_CLK_MAX, 0, 1 },
>> >>>   { TEGRA210_CLK_CSITE, TEGRA210_CLK_CLK_MAX, 0, 1 },
>> >>> + { TEGRA210_CLK_DBGAPB, TEGRA210_CLK_CLK_MAX, 0, 1 },
>> >>>   { TEGRA210_CLK_TSENSOR, TEGRA210_CLK_CLK_M, 400000, 0 },
>> >>>   { TEGRA210_CLK_I2C1, TEGRA210_CLK_PLL_P, 0, 0 },
>> >>>   { TEGRA210_CLK_I2C2, TEGRA210_CLK_PLL_P, 0, 0 },
>> >>
>> >> Should there be some dependency on say CONFIG_DEBUG_KERNEL? I am not
>> >> sure we always want this on for all cases.
>> >
>> > Why would you not want it to be always on?
>>
>> Purely for power reasons. I do not know how much power keeping this
>
> I don't expect it to be significant but I don't have any numbers.
>
>> clock running consumes, but I don't like the idea of clocks running all
>> the time when they are not needed.
>
> Problem is that in this case there is no easy way to determine if the clock
> needs to be on.

I had a similar issue with SH-Mobile AG5, where the power domain containing
the JTAG interface is powered down.

[DEBUG] ARM: dts: sh73a0: Add minimal device node for Coresight-ETM
https://patchwork.kernel.org/patch/8151511/

Want to debug? Apply patch. I know it's not ideal...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

#1594615

FromJon Hunter <jonathanh@nvidia.com>
Date2017-03-07 21:30 +0100
Message-ID<titU6-4iQ-23@gated-at.bofh.it>
In reply to#1593537
Hi Geert,

On 06/03/17 15:53, Geert Uytterhoeven wrote:
> Hi Peter,
> 
> On Mon, Mar 6, 2017 at 3:28 PM, Peter De Schrijver
> <pdeschrijver@nvidia.com> wrote:
>> On Mon, Mar 06, 2017 at 09:58:29AM +0000, Jon Hunter wrote:
>>> On 06/03/17 08:38, Peter De Schrijver wrote:
>>>> On Thu, Mar 02, 2017 at 05:56:49PM +0000, Jon Hunter wrote:
>>>>> On 28/02/17 15:19, Peter De Schrijver wrote:
>>>>>> This is needed to make the JTAG debugging interface work.
>>>>>>
>>>>>> Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
>>>>>> ---
>>>>>>  drivers/clk/tegra/clk-tegra210.c | 1 +
>>>>>>  1 file changed, 1 insertion(+)
>>>>>>
>>>>>> diff --git a/drivers/clk/tegra/clk-tegra210.c b/drivers/clk/tegra/clk-tegra210.c
>>>>>> index 9a2512a..708f5f1 100644
>>>>>> --- a/drivers/clk/tegra/clk-tegra210.c
>>>>>> +++ b/drivers/clk/tegra/clk-tegra210.c
>>>>>> @@ -2680,6 +2680,7 @@ static void tegra210_cpu_clock_resume(void)
>>>>>>   { TEGRA210_CLK_EMC, TEGRA210_CLK_CLK_MAX, 0, 1 },
>>>>>>   { TEGRA210_CLK_MSELECT, TEGRA210_CLK_CLK_MAX, 0, 1 },
>>>>>>   { TEGRA210_CLK_CSITE, TEGRA210_CLK_CLK_MAX, 0, 1 },
>>>>>> + { TEGRA210_CLK_DBGAPB, TEGRA210_CLK_CLK_MAX, 0, 1 },
>>>>>>   { TEGRA210_CLK_TSENSOR, TEGRA210_CLK_CLK_M, 400000, 0 },
>>>>>>   { TEGRA210_CLK_I2C1, TEGRA210_CLK_PLL_P, 0, 0 },
>>>>>>   { TEGRA210_CLK_I2C2, TEGRA210_CLK_PLL_P, 0, 0 },
>>>>>
>>>>> Should there be some dependency on say CONFIG_DEBUG_KERNEL? I am not
>>>>> sure we always want this on for all cases.
>>>>
>>>> Why would you not want it to be always on?
>>>
>>> Purely for power reasons. I do not know how much power keeping this
>>
>> I don't expect it to be significant but I don't have any numbers.
>>
>>> clock running consumes, but I don't like the idea of clocks running all
>>> the time when they are not needed.
>>
>> Problem is that in this case there is no easy way to determine if the clock
>> needs to be on.
> 
> I had a similar issue with SH-Mobile AG5, where the power domain containing
> the JTAG interface is powered down.
> 
> [DEBUG] ARM: dts: sh73a0: Add minimal device node for Coresight-ETM
> https://patchwork.kernel.org/patch/8151511/
> 
> Want to debug? Apply patch. I know it's not ideal...

Why don't you apply the patch and just keep the node disabled by default?

Cheers
Jon

-- 
nvpublic

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

#1595013

FromGeert Uytterhoeven <geert@linux-m68k.org>
Date2017-03-08 11:20 +0100
Message-ID<tiGRk-5aS-13@gated-at.bofh.it>
In reply to#1594615
Hi Jon,

On Tue, Mar 7, 2017 at 9:27 PM, Jon Hunter <jonathanh@nvidia.com> wrote:
> On 06/03/17 15:53, Geert Uytterhoeven wrote:
>> On Mon, Mar 6, 2017 at 3:28 PM, Peter De Schrijver
>> <pdeschrijver@nvidia.com> wrote:
>>> On Mon, Mar 06, 2017 at 09:58:29AM +0000, Jon Hunter wrote:
>>>> On 06/03/17 08:38, Peter De Schrijver wrote:
>>>>> On Thu, Mar 02, 2017 at 05:56:49PM +0000, Jon Hunter wrote:
>>>>>> On 28/02/17 15:19, Peter De Schrijver wrote:
>>>>>>> This is needed to make the JTAG debugging interface work.
>>>>>>>
>>>>>>> Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
>>>>>>> ---
>>>>>>>  drivers/clk/tegra/clk-tegra210.c | 1 +
>>>>>>>  1 file changed, 1 insertion(+)
>>>>>>>
>>>>>>> diff --git a/drivers/clk/tegra/clk-tegra210.c b/drivers/clk/tegra/clk-tegra210.c
>>>>>>> index 9a2512a..708f5f1 100644
>>>>>>> --- a/drivers/clk/tegra/clk-tegra210.c
>>>>>>> +++ b/drivers/clk/tegra/clk-tegra210.c
>>>>>>> @@ -2680,6 +2680,7 @@ static void tegra210_cpu_clock_resume(void)
>>>>>>>   { TEGRA210_CLK_EMC, TEGRA210_CLK_CLK_MAX, 0, 1 },
>>>>>>>   { TEGRA210_CLK_MSELECT, TEGRA210_CLK_CLK_MAX, 0, 1 },
>>>>>>>   { TEGRA210_CLK_CSITE, TEGRA210_CLK_CLK_MAX, 0, 1 },
>>>>>>> + { TEGRA210_CLK_DBGAPB, TEGRA210_CLK_CLK_MAX, 0, 1 },
>>>>>>>   { TEGRA210_CLK_TSENSOR, TEGRA210_CLK_CLK_M, 400000, 0 },
>>>>>>>   { TEGRA210_CLK_I2C1, TEGRA210_CLK_PLL_P, 0, 0 },
>>>>>>>   { TEGRA210_CLK_I2C2, TEGRA210_CLK_PLL_P, 0, 0 },
>>>>>>
>>>>>> Should there be some dependency on say CONFIG_DEBUG_KERNEL? I am not
>>>>>> sure we always want this on for all cases.
>>>>>
>>>>> Why would you not want it to be always on?
>>>>
>>>> Purely for power reasons. I do not know how much power keeping this
>>>
>>> I don't expect it to be significant but I don't have any numbers.
>>>
>>>> clock running consumes, but I don't like the idea of clocks running all
>>>> the time when they are not needed.
>>>
>>> Problem is that in this case there is no easy way to determine if the clock
>>> needs to be on.
>>
>> I had a similar issue with SH-Mobile AG5, where the power domain containing
>> the JTAG interface is powered down.
>>
>> [DEBUG] ARM: dts: sh73a0: Add minimal device node for Coresight-ETM
>> https://patchwork.kernel.org/patch/8151511/
>>
>> Want to debug? Apply patch. I know it's not ideal...
>
> Why don't you apply the patch and just keep the node disabled by default?

Thanks, good idea!

Then I first have to make get_special_pds() skip disabled nodes...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

#1595073

FromJon Hunter <jonathanh@nvidia.com>
Date2017-03-08 12:30 +0100
Message-ID<tiHX4-5QO-9@gated-at.bofh.it>
In reply to#1593537
Hi Peter,

On 06/03/17 15:53, Geert Uytterhoeven wrote:
> Hi Peter,
> 
> On Mon, Mar 6, 2017 at 3:28 PM, Peter De Schrijver
> <pdeschrijver@nvidia.com> wrote:
>> On Mon, Mar 06, 2017 at 09:58:29AM +0000, Jon Hunter wrote:
>>> On 06/03/17 08:38, Peter De Schrijver wrote:
>>>> On Thu, Mar 02, 2017 at 05:56:49PM +0000, Jon Hunter wrote:
>>>>> On 28/02/17 15:19, Peter De Schrijver wrote:
>>>>>> This is needed to make the JTAG debugging interface work.
>>>>>>
>>>>>> Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
>>>>>> ---
>>>>>>  drivers/clk/tegra/clk-tegra210.c | 1 +
>>>>>>  1 file changed, 1 insertion(+)
>>>>>>
>>>>>> diff --git a/drivers/clk/tegra/clk-tegra210.c b/drivers/clk/tegra/clk-tegra210.c
>>>>>> index 9a2512a..708f5f1 100644
>>>>>> --- a/drivers/clk/tegra/clk-tegra210.c
>>>>>> +++ b/drivers/clk/tegra/clk-tegra210.c
>>>>>> @@ -2680,6 +2680,7 @@ static void tegra210_cpu_clock_resume(void)
>>>>>>   { TEGRA210_CLK_EMC, TEGRA210_CLK_CLK_MAX, 0, 1 },
>>>>>>   { TEGRA210_CLK_MSELECT, TEGRA210_CLK_CLK_MAX, 0, 1 },
>>>>>>   { TEGRA210_CLK_CSITE, TEGRA210_CLK_CLK_MAX, 0, 1 },
>>>>>> + { TEGRA210_CLK_DBGAPB, TEGRA210_CLK_CLK_MAX, 0, 1 },
>>>>>>   { TEGRA210_CLK_TSENSOR, TEGRA210_CLK_CLK_M, 400000, 0 },
>>>>>>   { TEGRA210_CLK_I2C1, TEGRA210_CLK_PLL_P, 0, 0 },
>>>>>>   { TEGRA210_CLK_I2C2, TEGRA210_CLK_PLL_P, 0, 0 },
>>>>>
>>>>> Should there be some dependency on say CONFIG_DEBUG_KERNEL? I am not
>>>>> sure we always want this on for all cases.
>>>>
>>>> Why would you not want it to be always on?
>>>
>>> Purely for power reasons. I do not know how much power keeping this
>>
>> I don't expect it to be significant but I don't have any numbers.
>>
>>> clock running consumes, but I don't like the idea of clocks running all
>>> the time when they are not needed.
>>
>> Problem is that in this case there is no easy way to determine if the clock
>> needs to be on.
> 
> I had a similar issue with SH-Mobile AG5, where the power domain containing
> the JTAG interface is powered down.

This reminds me, does your patch assume that the DFD power domain is
enabled? I am guessing that it needs to be for JTAG to work.

Cheers
Jon

-- 
nvpublic

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

#1595086

FromGeert Uytterhoeven <geert@linux-m68k.org>
Date2017-03-08 12:50 +0100
Message-ID<tiIgq-5ZP-13@gated-at.bofh.it>
In reply to#1595073
Hi Jon,

On Wed, Mar 8, 2017 at 11:13 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
>> I had a similar issue with SH-Mobile AG5, where the power domain containing
>> the JTAG interface is powered down.
>
> This reminds me, does your patch assume that the DFD power domain is
> enabled? I am guessing that it needs to be for JTAG to work.

Yes. The pm-rmobile driver looks for "arm,coresight-etm3x" devices, and
marks the corresponding PM Domain as always-on, as long as the
Coresight code doesn't handle runtime PM.

For R-Mobile A1 and APE6 I already have added such device nodes, as any access
to a debug register hangs when the debug power domain is powered down.
For SH-Mobile AG5, I hadn't, as the debug power domain needs to be powered
for JTAG functionality only.

For the latter, perhaps we also need a command line parameter to change
a device status from "disabled" to "enabled"?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

#1595097

FromJon Hunter <jonathanh@nvidia.com>
Date2017-03-08 13:20 +0100
Message-ID<tiIJr-6r7-3@gated-at.bofh.it>
In reply to#1595086
On 08/03/17 11:38, Geert Uytterhoeven wrote:
> Hi Jon,
> 
> On Wed, Mar 8, 2017 at 11:13 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
>>> I had a similar issue with SH-Mobile AG5, where the power domain containing
>>> the JTAG interface is powered down.
>>
>> This reminds me, does your patch assume that the DFD power domain is
>> enabled? I am guessing that it needs to be for JTAG to work.
> 
> Yes. The pm-rmobile driver looks for "arm,coresight-etm3x" devices, and
> marks the corresponding PM Domain as always-on, as long as the
> Coresight code doesn't handle runtime PM.

Sorry Geert, but I was asking Peter specifically about the power-domain
on Tegra as I have a feeling we may have the same scenario ;-)

Jon

-- 
nvpublic

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

#1599190

FromPeter De Schrijver <pdeschrijver@nvidia.com>
Date2017-03-13 11:50 +0100
Message-ID<tkvI6-7IV-9@gated-at.bofh.it>
In reply to#1595097
On Wed, Mar 08, 2017 at 11:48:21AM +0000, Jon Hunter wrote:
> 
> On 08/03/17 11:38, Geert Uytterhoeven wrote:
> > Hi Jon,
> > 
> > On Wed, Mar 8, 2017 at 11:13 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
> >>> I had a similar issue with SH-Mobile AG5, where the power domain containing
> >>> the JTAG interface is powered down.
> >>
> >> This reminds me, does your patch assume that the DFD power domain is
> >> enabled? I am guessing that it needs to be for JTAG to work.
> > 
> > Yes. The pm-rmobile driver looks for "arm,coresight-etm3x" devices, and
> > marks the corresponding PM Domain as always-on, as long as the
> > Coresight code doesn't handle runtime PM.
> 
> Sorry Geert, but I was asking Peter specifically about the power-domain
> on Tegra as I have a feeling we may have the same scenario ;-)

We don't have a specific power domain for DFD on Tegra210. It's part of the
non-powergateable core domain.

Cheers,

Peter.

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

#1599213

FromJon Hunter <jonathanh@nvidia.com>
Date2017-03-13 12:10 +0100
Message-ID<tkw1s-852-13@gated-at.bofh.it>
In reply to#1599190
On 13/03/17 10:45, Peter De Schrijver wrote:
> On Wed, Mar 08, 2017 at 11:48:21AM +0000, Jon Hunter wrote:
>>
>> On 08/03/17 11:38, Geert Uytterhoeven wrote:
>>> Hi Jon,
>>>
>>> On Wed, Mar 8, 2017 at 11:13 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
>>>>> I had a similar issue with SH-Mobile AG5, where the power domain containing
>>>>> the JTAG interface is powered down.
>>>>
>>>> This reminds me, does your patch assume that the DFD power domain is
>>>> enabled? I am guessing that it needs to be for JTAG to work.
>>>
>>> Yes. The pm-rmobile driver looks for "arm,coresight-etm3x" devices, and
>>> marks the corresponding PM Domain as always-on, as long as the
>>> Coresight code doesn't handle runtime PM.
>>
>> Sorry Geert, but I was asking Peter specifically about the power-domain
>> on Tegra as I have a feeling we may have the same scenario ;-)
> 
> We don't have a specific power domain for DFD on Tegra210. It's part of the
> non-powergateable core domain.

Either we are getting our wires crossed or the TRM is wrong :-(

 static const char * const tegra210_powergates[] = {
         [TEGRA_POWERGATE_CPU] = "crail",
         [TEGRA_POWERGATE_3D] = "3d",
         [TEGRA_POWERGATE_VENC] = "venc",
         [TEGRA_POWERGATE_PCIE] = "pcie",
         [TEGRA_POWERGATE_MPE] = "mpe",
         [TEGRA_POWERGATE_SATA] = "sata",
         [TEGRA_POWERGATE_CPU1] = "cpu1",
         [TEGRA_POWERGATE_CPU2] = "cpu2",
         [TEGRA_POWERGATE_CPU3] = "cpu3",
         [TEGRA_POWERGATE_CPU0] = "cpu0",
         [TEGRA_POWERGATE_C0NC] = "c0nc",
         [TEGRA_POWERGATE_SOR] = "sor",
         [TEGRA_POWERGATE_DIS] = "dis",
         [TEGRA_POWERGATE_DISB] = "disb",
         [TEGRA_POWERGATE_XUSBA] = "xusba",
         [TEGRA_POWERGATE_XUSBB] = "xusbb",
         [TEGRA_POWERGATE_XUSBC] = "xusbc",
         [TEGRA_POWERGATE_VIC] = "vic",
         [TEGRA_POWERGATE_IRAM] = "iram",
         [TEGRA_POWERGATE_NVDEC] = "nvdec",
         [TEGRA_POWERGATE_NVJPG] = "nvjpg",
         [TEGRA_POWERGATE_AUD] = "aud",
         [TEGRA_POWERGATE_DFD] = "dfd",
         [TEGRA_POWERGATE_VE2] = "ve2",
 };


Jon

-- 
nvpublic

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

#1599420

FromPeter De Schrijver <pdeschrijver@nvidia.com>
Date2017-03-13 15:20 +0100
Message-ID<tkyZk-1HR-25@gated-at.bofh.it>
In reply to#1599213
On Mon, Mar 13, 2017 at 11:03:27AM +0000, Jon Hunter wrote:
> 
> On 13/03/17 10:45, Peter De Schrijver wrote:
> > On Wed, Mar 08, 2017 at 11:48:21AM +0000, Jon Hunter wrote:
> >>
> >> On 08/03/17 11:38, Geert Uytterhoeven wrote:
> >>> Hi Jon,
> >>>
> >>> On Wed, Mar 8, 2017 at 11:13 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
> >>>>> I had a similar issue with SH-Mobile AG5, where the power domain containing
> >>>>> the JTAG interface is powered down.
> >>>>
> >>>> This reminds me, does your patch assume that the DFD power domain is
> >>>> enabled? I am guessing that it needs to be for JTAG to work.
> >>>
> >>> Yes. The pm-rmobile driver looks for "arm,coresight-etm3x" devices, and
> >>> marks the corresponding PM Domain as always-on, as long as the
> >>> Coresight code doesn't handle runtime PM.
> >>
> >> Sorry Geert, but I was asking Peter specifically about the power-domain
> >> on Tegra as I have a feeling we may have the same scenario ;-)
> > 
> > We don't have a specific power domain for DFD on Tegra210. It's part of the
> > non-powergateable core domain.
> 
> Either we are getting our wires crossed or the TRM is wrong :-(
> 
>  static const char * const tegra210_powergates[] = {
>          [TEGRA_POWERGATE_CPU] = "crail",
>          [TEGRA_POWERGATE_3D] = "3d",
>          [TEGRA_POWERGATE_VENC] = "venc",
>          [TEGRA_POWERGATE_PCIE] = "pcie",
>          [TEGRA_POWERGATE_MPE] = "mpe",
>          [TEGRA_POWERGATE_SATA] = "sata",
>          [TEGRA_POWERGATE_CPU1] = "cpu1",
>          [TEGRA_POWERGATE_CPU2] = "cpu2",
>          [TEGRA_POWERGATE_CPU3] = "cpu3",
>          [TEGRA_POWERGATE_CPU0] = "cpu0",
>          [TEGRA_POWERGATE_C0NC] = "c0nc",
>          [TEGRA_POWERGATE_SOR] = "sor",
>          [TEGRA_POWERGATE_DIS] = "dis",
>          [TEGRA_POWERGATE_DISB] = "disb",
>          [TEGRA_POWERGATE_XUSBA] = "xusba",
>          [TEGRA_POWERGATE_XUSBB] = "xusbb",
>          [TEGRA_POWERGATE_XUSBC] = "xusbc",
>          [TEGRA_POWERGATE_VIC] = "vic",
>          [TEGRA_POWERGATE_IRAM] = "iram",
>          [TEGRA_POWERGATE_NVDEC] = "nvdec",
>          [TEGRA_POWERGATE_NVJPG] = "nvjpg",
>          [TEGRA_POWERGATE_AUD] = "aud",
>          [TEGRA_POWERGATE_DFD] = "dfd",
>          [TEGRA_POWERGATE_VE2] = "ve2",
>  };
> 

This seems to exist indeed. However downstream has never used it, so I wonder
how well powergating this domain has been tested.

Peter.

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

#1599195

FromPeter De Schrijver <pdeschrijver@nvidia.com>
Date2017-03-13 11:50 +0100
Message-ID<tkvI6-7IV-21@gated-at.bofh.it>
In reply to#1593537
On Mon, Mar 06, 2017 at 04:53:48PM +0100, Geert Uytterhoeven wrote:
> Hi Peter,
> 
> On Mon, Mar 6, 2017 at 3:28 PM, Peter De Schrijver
> <pdeschrijver@nvidia.com> wrote:
> > On Mon, Mar 06, 2017 at 09:58:29AM +0000, Jon Hunter wrote:
> >> On 06/03/17 08:38, Peter De Schrijver wrote:
> >> > On Thu, Mar 02, 2017 at 05:56:49PM +0000, Jon Hunter wrote:
> >> >> On 28/02/17 15:19, Peter De Schrijver wrote:
> >> >>> This is needed to make the JTAG debugging interface work.
> >> >>>
> >> >>> Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
> >> >>> ---
> >> >>>  drivers/clk/tegra/clk-tegra210.c | 1 +
> >> >>>  1 file changed, 1 insertion(+)
> >> >>>
> >> >>> diff --git a/drivers/clk/tegra/clk-tegra210.c b/drivers/clk/tegra/clk-tegra210.c
> >> >>> index 9a2512a..708f5f1 100644
> >> >>> --- a/drivers/clk/tegra/clk-tegra210.c
> >> >>> +++ b/drivers/clk/tegra/clk-tegra210.c
> >> >>> @@ -2680,6 +2680,7 @@ static void tegra210_cpu_clock_resume(void)
> >> >>>   { TEGRA210_CLK_EMC, TEGRA210_CLK_CLK_MAX, 0, 1 },
> >> >>>   { TEGRA210_CLK_MSELECT, TEGRA210_CLK_CLK_MAX, 0, 1 },
> >> >>>   { TEGRA210_CLK_CSITE, TEGRA210_CLK_CLK_MAX, 0, 1 },
> >> >>> + { TEGRA210_CLK_DBGAPB, TEGRA210_CLK_CLK_MAX, 0, 1 },
> >> >>>   { TEGRA210_CLK_TSENSOR, TEGRA210_CLK_CLK_M, 400000, 0 },
> >> >>>   { TEGRA210_CLK_I2C1, TEGRA210_CLK_PLL_P, 0, 0 },
> >> >>>   { TEGRA210_CLK_I2C2, TEGRA210_CLK_PLL_P, 0, 0 },
> >> >>
> >> >> Should there be some dependency on say CONFIG_DEBUG_KERNEL? I am not
> >> >> sure we always want this on for all cases.
> >> >
> >> > Why would you not want it to be always on?
> >>
> >> Purely for power reasons. I do not know how much power keeping this
> >
> > I don't expect it to be significant but I don't have any numbers.
> >
> >> clock running consumes, but I don't like the idea of clocks running all
> >> the time when they are not needed.
> >
> > Problem is that in this case there is no easy way to determine if the clock
> > needs to be on.
> 
> I had a similar issue with SH-Mobile AG5, where the power domain containing
> the JTAG interface is powered down.
> 
> [DEBUG] ARM: dts: sh73a0: Add minimal device node for Coresight-ETM
> https://patchwork.kernel.org/patch/8151511/
> 
> Want to debug? Apply patch. I know it's not ideal...
> 

Don't you always want to debug? :-)

Peter.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web