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 <[email protected]>
> ---
> 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
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 <[email protected]>
> > ---
> > 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.
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 <[email protected]>
>>> ---
>>> 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
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 <[email protected]>
> >>> ---
> >>> 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.
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 <[email protected]>
>>>>> ---
>>>>> 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
Hi Peter,
On Mon, Mar 6, 2017 at 3:28 PM, Peter De Schrijver
<[email protected]> 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 <[email protected]>
>> >>> ---
>> >>> 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 -- [email protected]
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
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
> <[email protected]> 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 <[email protected]>
>>>>>> ---
>>>>>> 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
Hi Jon,
On Tue, Mar 7, 2017 at 9:27 PM, Jon Hunter <[email protected]> wrote:
> On 06/03/17 15:53, Geert Uytterhoeven wrote:
>> On Mon, Mar 6, 2017 at 3:28 PM, Peter De Schrijver
>> <[email protected]> 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 <[email protected]>
>>>>>>> ---
>>>>>>> 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 -- [email protected]
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
Hi Jon,
On Wed, Mar 8, 2017 at 11:13 AM, Jon Hunter <[email protected]> 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 -- [email protected]
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
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
> <[email protected]> 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 <[email protected]>
>>>>>> ---
>>>>>> 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
On 08/03/17 11:38, Geert Uytterhoeven wrote:
> Hi Jon,
>
> On Wed, Mar 8, 2017 at 11:13 AM, Jon Hunter <[email protected]> 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
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 <[email protected]> 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.
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
> <[email protected]> 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 <[email protected]>
> >> >>> ---
> >> >>> 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.
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 <[email protected]> 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
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 <[email protected]> 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.