From: Martin Blumenstingl <email@example.com> To: Anand Moon <firstname.lastname@example.org> Cc: devicetree <email@example.com>, Neil Armstrong <firstname.lastname@example.org>, Kevin Hilman <email@example.com>, Linux Kernel <firstname.lastname@example.org>, email@example.com, linux-arm-kernel <firstname.lastname@example.org>, Jerome Brunet <email@example.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 <firstname.lastname@example.org> 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 email@example.com http://lists.infradead.org/mailman/listinfo/linux-amlogic
next prev parent reply other threads:[~2019-10-18 18:12 UTC|newest] Thread overview: 33+ 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 ` [RFCv1 1/5] arm64: dts: meson: Add missing 5V_EN gpio signal for VCC5V regulator Anand Moon 2019-10-07 14:19 ` Neil Armstrong 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 14:20 ` Neil Armstrong 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 14:20 ` Neil Armstrong 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 14:21 ` Neil Armstrong 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 14:25 ` Neil Armstrong 2019-10-07 15:52 ` Anand Moon 2019-10-07 20:10 ` Martin Blumenstingl 2019-10-07 22:57 ` Kevin Hilman 2019-10-08 14:38 ` Anand Moon 2019-10-08 17:40 ` Martin Blumenstingl 2019-10-09 8:48 ` Anand Moon 2019-10-09 12:04 ` Jerome Brunet 2019-10-18 14:04 ` Anand Moon 2019-10-18 14:13 ` Neil Armstrong 2019-10-18 15:21 ` Anand Moon 2019-10-18 18:10 ` Martin Blumenstingl [this message] 2019-10-21 14:11 ` Anand Moon 2019-10-21 14:25 ` Neil Armstrong 2019-10-21 15:41 ` Anand Moon 2019-10-26 18:56 ` Anand Moon 2019-10-24 20:20 ` Martin Blumenstingl 2019-10-09 17:05 ` Martin Blumenstingl 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [RFCv1 5/5] arm64/ARM: configs: Change CONFIG_PWM_MESON from m to y' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).