All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
To: Anand Moon <linux.amoon@gmail.com>
Cc: Jerome Brunet <jbrunet@baylibre.com>,
	Kevin Hilman <khilman@baylibre.com>,
	Neil Armstrong <narmstrong@baylibre.com>,
	devicetree <devicetree@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	linux-amlogic@lists.infradead.org,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [RFCv1 5/5] arm64/ARM: configs: Change CONFIG_PWM_MESON from m to y
Date: Fri, 18 Oct 2019 20:10:43 +0200	[thread overview]
Message-ID: <CAFBinCBdwqxA2kLMAA9gtOcXevYK-J4x12odHwpQOAWakgWiEg@mail.gmail.com> (raw)
In-Reply-To: <CANAwSgSoK4X3_QbO3YpZRXNTpPJ+zVeid=w93f14Eyk8Dd32EQ@mail.gmail.com>

Hi Anand,

On Fri, Oct 18, 2019 at 4:04 PM Anand Moon <linux.amoon@gmail.com> wrote:
[...]
> > Next step it to try narrow down the clock causing the issue.
> > Remove clk_ignore_unused from the command line and add CLK_INGORE_UNUSED
> > to the flag of some clocks your clock controller (g12a I think) until
> >
> > The peripheral clock gates already have this flag (something we should
> > fix someday) so don't bother looking there.
> >
> > Most likely the source of the pwm is getting disabled between the
> > late_init call and the probe of the PWM module. Since the pwm is already
> > active (w/o a driver), gating the clock source shuts dowm the power to
> > the cores.
> >
> > Looking a the possible inputs in pwm driver, I'd bet on fdiv4.
> >
>
> I had give this above steps a try but with little success.
> I am still looking into this much close.
it's not clear to me if you have only tested with the PWM and/or
FCLK_DIV4 clocks. can you please describe what you have tested so far?

for reference - my way of debugging this in the past was:
1. add some printks to clk_disable_unused_subtree (right after the
clk_core_is_enabled check) to see which clocks are being disabled
2. add CLK_IGNORE_UNUSED or CLK_IS_CRITICAL to the clocks which are
being disabled based on the information from step #1
3. (at some point I had a working kernel with lots of clocks with
CLK_IGNORE_UNUSED/CLK_IS_CRITICAL)
4. start dropping the CLK_IGNORE_UNUSED/CLK_IS_CRITICAL flags again
until you have traced it down to the clocks that are the actual issue
(so far I always had only one clock which caused issues, but it may be
multiple)
5. investigate (and/or ask on the mailing list, Amlogic developers are
reading the mails here as well) for the few clocks from step #4

> Well I am not the expert in clk or bus configuration.
> but after looking into the datasheet of for clk configuration
> I found some bus are not configured correctly.
did you find any reason which indicates that the problem is related to a bus?
the issues I had were due to clocks not being assigned to their
consumers in .dts - that can be anything (from a bus to something
different).


Martin

WARNING: multiple messages have this Message-ID (diff)
From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
To: Anand Moon <linux.amoon@gmail.com>
Cc: devicetree <devicetree@vger.kernel.org>,
	Neil Armstrong <narmstrong@baylibre.com>,
	Kevin Hilman <khilman@baylibre.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	linux-amlogic@lists.infradead.org,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Jerome Brunet <jbrunet@baylibre.com>
Subject: Re: [RFCv1 5/5] arm64/ARM: configs: Change CONFIG_PWM_MESON from m to y
Date: Fri, 18 Oct 2019 20:10:43 +0200	[thread overview]
Message-ID: <CAFBinCBdwqxA2kLMAA9gtOcXevYK-J4x12odHwpQOAWakgWiEg@mail.gmail.com> (raw)
In-Reply-To: <CANAwSgSoK4X3_QbO3YpZRXNTpPJ+zVeid=w93f14Eyk8Dd32EQ@mail.gmail.com>

Hi Anand,

On Fri, Oct 18, 2019 at 4:04 PM Anand Moon <linux.amoon@gmail.com> wrote:
[...]
> > Next step it to try narrow down the clock causing the issue.
> > Remove clk_ignore_unused from the command line and add CLK_INGORE_UNUSED
> > to the flag of some clocks your clock controller (g12a I think) until
> >
> > The peripheral clock gates already have this flag (something we should
> > fix someday) so don't bother looking there.
> >
> > Most likely the source of the pwm is getting disabled between the
> > late_init call and the probe of the PWM module. Since the pwm is already
> > active (w/o a driver), gating the clock source shuts dowm the power to
> > the cores.
> >
> > Looking a the possible inputs in pwm driver, I'd bet on fdiv4.
> >
>
> I had give this above steps a try but with little success.
> I am still looking into this much close.
it's not clear to me if you have only tested with the PWM and/or
FCLK_DIV4 clocks. can you please describe what you have tested so far?

for reference - my way of debugging this in the past was:
1. add some printks to clk_disable_unused_subtree (right after the
clk_core_is_enabled check) to see which clocks are being disabled
2. add CLK_IGNORE_UNUSED or CLK_IS_CRITICAL to the clocks which are
being disabled based on the information from step #1
3. (at some point I had a working kernel with lots of clocks with
CLK_IGNORE_UNUSED/CLK_IS_CRITICAL)
4. start dropping the CLK_IGNORE_UNUSED/CLK_IS_CRITICAL flags again
until you have traced it down to the clocks that are the actual issue
(so far I always had only one clock which caused issues, but it may be
multiple)
5. investigate (and/or ask on the mailing list, Amlogic developers are
reading the mails here as well) for the few clocks from step #4

> Well I am not the expert in clk or bus configuration.
> but after looking into the datasheet of for clk configuration
> I found some bus are not configured correctly.
did you find any reason which indicates that the problem is related to a bus?
the issues I had were due to clocks not being assigned to their
consumers in .dts - that can be anything (from a bus to something
different).


Martin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
To: Anand Moon <linux.amoon@gmail.com>
Cc: devicetree <devicetree@vger.kernel.org>,
	Neil Armstrong <narmstrong@baylibre.com>,
	Kevin Hilman <khilman@baylibre.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	linux-amlogic@lists.infradead.org,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Jerome Brunet <jbrunet@baylibre.com>
Subject: Re: [RFCv1 5/5] arm64/ARM: configs: Change CONFIG_PWM_MESON from m to y
Date: Fri, 18 Oct 2019 20:10:43 +0200	[thread overview]
Message-ID: <CAFBinCBdwqxA2kLMAA9gtOcXevYK-J4x12odHwpQOAWakgWiEg@mail.gmail.com> (raw)
In-Reply-To: <CANAwSgSoK4X3_QbO3YpZRXNTpPJ+zVeid=w93f14Eyk8Dd32EQ@mail.gmail.com>

Hi Anand,

On Fri, Oct 18, 2019 at 4:04 PM Anand Moon <linux.amoon@gmail.com> wrote:
[...]
> > Next step it to try narrow down the clock causing the issue.
> > Remove clk_ignore_unused from the command line and add CLK_INGORE_UNUSED
> > to the flag of some clocks your clock controller (g12a I think) until
> >
> > The peripheral clock gates already have this flag (something we should
> > fix someday) so don't bother looking there.
> >
> > Most likely the source of the pwm is getting disabled between the
> > late_init call and the probe of the PWM module. Since the pwm is already
> > active (w/o a driver), gating the clock source shuts dowm the power to
> > the cores.
> >
> > Looking a the possible inputs in pwm driver, I'd bet on fdiv4.
> >
>
> I had give this above steps a try but with little success.
> I am still looking into this much close.
it's not clear to me if you have only tested with the PWM and/or
FCLK_DIV4 clocks. can you please describe what you have tested so far?

for reference - my way of debugging this in the past was:
1. add some printks to clk_disable_unused_subtree (right after the
clk_core_is_enabled check) to see which clocks are being disabled
2. add CLK_IGNORE_UNUSED or CLK_IS_CRITICAL to the clocks which are
being disabled based on the information from step #1
3. (at some point I had a working kernel with lots of clocks with
CLK_IGNORE_UNUSED/CLK_IS_CRITICAL)
4. start dropping the CLK_IGNORE_UNUSED/CLK_IS_CRITICAL flags again
until you have traced it down to the clocks that are the actual issue
(so far I always had only one clock which caused issues, but it may be
multiple)
5. investigate (and/or ask on the mailing list, Amlogic developers are
reading the mails here as well) for the few clocks from step #4

> Well I am not the expert in clk or bus configuration.
> but after looking into the datasheet of for clk configuration
> I found some bus are not configured correctly.
did you find any reason which indicates that the problem is related to a bus?
the issues I had were due to clocks not being assigned to their
consumers in .dts - that can be anything (from a bus to something
different).


Martin

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

  parent reply	other threads:[~2019-10-18 18:10 UTC|newest]

Thread overview: 102+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-07 13:16 [RFCv1 0/5] Odroid N2 failes to boot using upstream kernel & u-boot Anand Moon
2019-10-07 13:16 ` Anand Moon
2019-10-07 13:16 ` Anand Moon
2019-10-07 13:16 ` [RFCv1 1/5] arm64: dts: meson: Add missing 5V_EN gpio signal for VCC5V regulator Anand Moon
2019-10-07 13:16   ` Anand Moon
2019-10-07 13:16   ` Anand Moon
2019-10-07 14:19   ` Neil Armstrong
2019-10-07 14:19     ` Neil Armstrong
2019-10-07 14:19     ` Neil Armstrong
2019-10-07 15:28     ` Anand Moon
2019-10-07 15:28       ` Anand Moon
2019-10-07 15:28       ` Anand Moon
2019-10-07 13:16 ` [RFCv1 2/5] arm64: dts: meson: Add missing pwm control gpio signal for pwm-regulator Anand Moon
2019-10-07 13:16   ` Anand Moon
2019-10-07 13:16   ` Anand Moon
2019-10-07 14:20   ` Neil Armstrong
2019-10-07 14:20     ` Neil Armstrong
2019-10-07 14:20     ` Neil Armstrong
2019-10-07 14:20     ` Neil Armstrong
2019-10-07 15:30     ` Anand Moon
2019-10-07 15:30       ` Anand Moon
2019-10-07 15:30       ` Anand Moon
2019-10-07 13:16 ` [RFCv1 3/5] arm64: dts: meson: Add missing regulator linked to VDDAO_3V3 regulator to FLASH_VDD Anand Moon
2019-10-07 13:16   ` Anand Moon
2019-10-07 13:16   ` Anand Moon
2019-10-07 14:20   ` Neil Armstrong
2019-10-07 14:20     ` Neil Armstrong
2019-10-07 14:20     ` Neil Armstrong
2019-10-07 15:53     ` Anand Moon
2019-10-07 15:53       ` Anand Moon
2019-10-07 15:53       ` Anand Moon
2019-10-07 15:53       ` Anand Moon
2019-10-07 13:16 ` [RFCv1 4/5] arm64: dts: meson: Add missing regulator linked to VCCV5 regulator to VDDIO_C/TF_IO Anand Moon
2019-10-07 13:16   ` Anand Moon
2019-10-07 13:16   ` Anand Moon
2019-10-07 14:21   ` Neil Armstrong
2019-10-07 14:21     ` Neil Armstrong
2019-10-07 14:21     ` Neil Armstrong
2019-10-07 15:54     ` Anand Moon
2019-10-07 15:54       ` Anand Moon
2019-10-07 15:54       ` Anand Moon
2019-10-07 13:16 ` [RFCv1 5/5] arm64/ARM: configs: Change CONFIG_PWM_MESON from m to y Anand Moon
2019-10-07 13:16   ` Anand Moon
2019-10-07 13:16   ` Anand Moon
2019-10-07 14:25   ` Neil Armstrong
2019-10-07 14:25     ` Neil Armstrong
2019-10-07 14:25     ` Neil Armstrong
2019-10-07 15:52     ` Anand Moon
2019-10-07 15:52       ` Anand Moon
2019-10-07 15:52       ` Anand Moon
2019-10-07 20:10   ` Martin Blumenstingl
2019-10-07 20:10     ` Martin Blumenstingl
2019-10-07 20:10     ` Martin Blumenstingl
2019-10-07 22:57     ` Kevin Hilman
2019-10-07 22:57       ` Kevin Hilman
2019-10-07 22:57       ` Kevin Hilman
2019-10-08 14:38       ` Anand Moon
2019-10-08 14:38         ` Anand Moon
2019-10-08 14:38         ` Anand Moon
2019-10-08 17:40         ` Martin Blumenstingl
2019-10-08 17:40           ` Martin Blumenstingl
2019-10-08 17:40           ` Martin Blumenstingl
2019-10-08 17:40           ` Martin Blumenstingl
2019-10-09  8:48           ` Anand Moon
2019-10-09  8:48             ` Anand Moon
2019-10-09  8:48             ` Anand Moon
2019-10-09 12:04             ` Jerome Brunet
2019-10-09 12:04               ` Jerome Brunet
2019-10-09 12:04               ` Jerome Brunet
2019-10-18 14:04               ` Anand Moon
2019-10-18 14:04                 ` Anand Moon
2019-10-18 14:04                 ` Anand Moon
2019-10-18 14:13                 ` Neil Armstrong
2019-10-18 14:13                   ` Neil Armstrong
2019-10-18 14:13                   ` Neil Armstrong
2019-10-18 15:21                   ` Anand Moon
2019-10-18 15:21                     ` Anand Moon
2019-10-18 15:21                     ` Anand Moon
2019-10-18 18:10                 ` Martin Blumenstingl [this message]
2019-10-18 18:10                   ` Martin Blumenstingl
2019-10-18 18:10                   ` Martin Blumenstingl
2019-10-21 14:11                   ` Anand Moon
2019-10-21 14:11                     ` Anand Moon
2019-10-21 14:11                     ` Anand Moon
2019-10-21 14:25                     ` Neil Armstrong
2019-10-21 14:25                       ` Neil Armstrong
2019-10-21 14:25                       ` Neil Armstrong
2019-10-21 15:41                       ` Anand Moon
2019-10-21 15:41                         ` Anand Moon
2019-10-21 15:41                         ` Anand Moon
2019-10-26 18:56                         ` Anand Moon
2019-10-26 18:56                           ` Anand Moon
2019-10-26 18:56                           ` Anand Moon
2019-10-24 20:20                     ` Martin Blumenstingl
2019-10-24 20:20                       ` Martin Blumenstingl
2019-10-24 20:20                       ` Martin Blumenstingl
2019-10-09 17:05             ` Martin Blumenstingl
2019-10-09 17:05               ` Martin Blumenstingl
2019-10-09 17:05               ` Martin Blumenstingl
2019-10-08  7:19     ` Anand Moon
2019-10-08  7:19       ` Anand Moon
2019-10-08  7:19       ` Anand Moon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFBinCBdwqxA2kLMAA9gtOcXevYK-J4x12odHwpQOAWakgWiEg@mail.gmail.com \
    --to=martin.blumenstingl@googlemail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jbrunet@baylibre.com \
    --cc=khilman@baylibre.com \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux.amoon@gmail.com \
    --cc=narmstrong@baylibre.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.