All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiner Kallweit <hkallweit1@gmail.com>
To: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: "Jerome Brunet" <jbrunet@baylibre.com>,
	"Neil Armstrong" <narmstrong@baylibre.com>,
	"Kevin Hilman" <khilman@baylibre.com>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"thierry.reding@gmail.com" <thierry.reding@gmail.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"open list:ARM/Amlogic Meson..."
	<linux-amlogic@lists.infradead.org>,
	linux-pwm@vger.kernel.org
Subject: Re: [PATCH v4 4/4] pwm: meson: make full use of common clock framework
Date: Sat, 15 Apr 2023 08:39:19 +0200	[thread overview]
Message-ID: <4b328dab-5f96-e5d0-3181-ce059d11b04b@gmail.com> (raw)
In-Reply-To: <CAFBinCCzMdQZ4mDF7SEZKHc01MPSepxdzYa+j7G-qDXe5-kBVA@mail.gmail.com>

On 14.04.2023 21:39, Martin Blumenstingl wrote:
> Hello Heiner,
> 
> On Thu, Apr 13, 2023 at 7:55 AM Heiner Kallweit <hkallweit1@gmail.com> wrote:
> [...]
>> Tested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> Unfortunately I have some bad news and I need to take back my Tested-by :-(
> Previously my test was: cycle through all available CPU frequencies
> while stressing the CPU.
> My assumption was: if the system doesn't lock up everything's fine
> because we have a high enough voltage.
> 
> This evening however I got a memory corruption error while trying to
> log in via UART - which I thought was strange.
> So I connected my logic analyzer to my Odroid-C1 and did some experiments:
> 
> period = 30518, duty cycle = 15259 (typically used for the 32kHz
> output to the SDIO wifi chip)
> before your patches / after applying your patches:
> PWM: duty cycle: 50.000000% / 50.000000%
> PWM: period: 30.6 µs / 30.5 µs
> Timing: Time: 15.292 µs (65.395 kHz) / 15.250 µs (65.574 kHz)
> Timing: Average: 15.296 µs (65.377 kHz) / 15.264 µs (65.513 kHz)
> driver debug messages with your patches applied:
> fin_freq: 850000000 Hz
> period=30518 cnt=25940
> duty=15259 duty_cnt=12970
> 
> Then I tried period = 12218, duty cycle = 0 (typically used for the
> highest CPU voltage):
> before your patches / after applying your patches:
> PWM: duty cycle: 0.338983% / n/a (constant low output)
> PWM: period: 12.3 µs / n/a
> Timing: Time: 12.250 µs (81.633 kHz) / n/a
> Timing: Average: 6.148 µs (162.668 kHz) / n/a
> driver debug messages with your patches applied:
> fin_freq: 850000000 Hz
> period=12218 cnt=10385
> 
With a 850MHz input clock we should see a 0.01% duty cycle with 1.2ns
clock pulses. Can we rule out an issue with the measuring equipment?
Is your logic analyzer able to display such short clock pulses?

> Finally I tried period = 12218, duty cycle = 12218 (typically used for
> the lowest CPU voltage):
> before your patches / after applying your patches:
> PWM: duty cycle: 99.661017% / n/a (constant low output)
> PWM: period: 12.3 µs / n/a
> Timing: Time: 12.250 µs (81.633 kHz) / n/a
> Timing: Average: 6.148 µs (162.668 kHz) / n/a
> driver debug messages with your patches applied:
> fin_freq: 850000000 Hz
> period=12218 cnt=10385
> 
Here I have no idea yet.

> After seeing the constant low output with period 12218 I realized that
> my previous test was no good: the CPU was fed the highest possible
> voltage all the time.
> It's not clear to me why period 12218 would give no PWM output at all
> while period 30518 works fine.
> I did an experiment by removing CLK_SET_RATE_PARENT from the divider's
> init.flags -> now XTAL (24MHz) is the only possible clock (it's the
> hardware default). It does indeed bring back the exact same results as
> before (where the XTAL clock was also used; with the changes from this
> series FCLK_DIV3 is now chosen, which runs at 850MHz).
> 
> Do you have any idea what could cause this?
> The FCLK_DIV3 input seems to work as otherwise period 30518 would also not work.
> The calculated values also look sane, so it's not that we have some
> 32-bit overflow (as I'm testing on a 32-bit Meson8b SoC).
> 
At first I'd like to verify that the registers have the expected values.
Can you provide the values of PWM_A/B (depending on which channel is used in your
case) and PWM_MISC_AB at the end of meson_pwm_enable()? Thanks!

> 
> Best regards,
> Martin

Heiner


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

WARNING: multiple messages have this Message-ID (diff)
From: Heiner Kallweit <hkallweit1@gmail.com>
To: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: "Jerome Brunet" <jbrunet@baylibre.com>,
	"Neil Armstrong" <narmstrong@baylibre.com>,
	"Kevin Hilman" <khilman@baylibre.com>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"thierry.reding@gmail.com" <thierry.reding@gmail.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"open list:ARM/Amlogic Meson..."
	<linux-amlogic@lists.infradead.org>,
	linux-pwm@vger.kernel.org
Subject: Re: [PATCH v4 4/4] pwm: meson: make full use of common clock framework
Date: Sat, 15 Apr 2023 08:39:19 +0200	[thread overview]
Message-ID: <4b328dab-5f96-e5d0-3181-ce059d11b04b@gmail.com> (raw)
In-Reply-To: <CAFBinCCzMdQZ4mDF7SEZKHc01MPSepxdzYa+j7G-qDXe5-kBVA@mail.gmail.com>

On 14.04.2023 21:39, Martin Blumenstingl wrote:
> Hello Heiner,
> 
> On Thu, Apr 13, 2023 at 7:55 AM Heiner Kallweit <hkallweit1@gmail.com> wrote:
> [...]
>> Tested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> Unfortunately I have some bad news and I need to take back my Tested-by :-(
> Previously my test was: cycle through all available CPU frequencies
> while stressing the CPU.
> My assumption was: if the system doesn't lock up everything's fine
> because we have a high enough voltage.
> 
> This evening however I got a memory corruption error while trying to
> log in via UART - which I thought was strange.
> So I connected my logic analyzer to my Odroid-C1 and did some experiments:
> 
> period = 30518, duty cycle = 15259 (typically used for the 32kHz
> output to the SDIO wifi chip)
> before your patches / after applying your patches:
> PWM: duty cycle: 50.000000% / 50.000000%
> PWM: period: 30.6 µs / 30.5 µs
> Timing: Time: 15.292 µs (65.395 kHz) / 15.250 µs (65.574 kHz)
> Timing: Average: 15.296 µs (65.377 kHz) / 15.264 µs (65.513 kHz)
> driver debug messages with your patches applied:
> fin_freq: 850000000 Hz
> period=30518 cnt=25940
> duty=15259 duty_cnt=12970
> 
> Then I tried period = 12218, duty cycle = 0 (typically used for the
> highest CPU voltage):
> before your patches / after applying your patches:
> PWM: duty cycle: 0.338983% / n/a (constant low output)
> PWM: period: 12.3 µs / n/a
> Timing: Time: 12.250 µs (81.633 kHz) / n/a
> Timing: Average: 6.148 µs (162.668 kHz) / n/a
> driver debug messages with your patches applied:
> fin_freq: 850000000 Hz
> period=12218 cnt=10385
> 
With a 850MHz input clock we should see a 0.01% duty cycle with 1.2ns
clock pulses. Can we rule out an issue with the measuring equipment?
Is your logic analyzer able to display such short clock pulses?

> Finally I tried period = 12218, duty cycle = 12218 (typically used for
> the lowest CPU voltage):
> before your patches / after applying your patches:
> PWM: duty cycle: 99.661017% / n/a (constant low output)
> PWM: period: 12.3 µs / n/a
> Timing: Time: 12.250 µs (81.633 kHz) / n/a
> Timing: Average: 6.148 µs (162.668 kHz) / n/a
> driver debug messages with your patches applied:
> fin_freq: 850000000 Hz
> period=12218 cnt=10385
> 
Here I have no idea yet.

> After seeing the constant low output with period 12218 I realized that
> my previous test was no good: the CPU was fed the highest possible
> voltage all the time.
> It's not clear to me why period 12218 would give no PWM output at all
> while period 30518 works fine.
> I did an experiment by removing CLK_SET_RATE_PARENT from the divider's
> init.flags -> now XTAL (24MHz) is the only possible clock (it's the
> hardware default). It does indeed bring back the exact same results as
> before (where the XTAL clock was also used; with the changes from this
> series FCLK_DIV3 is now chosen, which runs at 850MHz).
> 
> Do you have any idea what could cause this?
> The FCLK_DIV3 input seems to work as otherwise period 30518 would also not work.
> The calculated values also look sane, so it's not that we have some
> 32-bit overflow (as I'm testing on a 32-bit Meson8b SoC).
> 
At first I'd like to verify that the registers have the expected values.
Can you provide the values of PWM_A/B (depending on which channel is used in your
case) and PWM_MISC_AB at the end of meson_pwm_enable()? Thanks!

> 
> Best regards,
> Martin

Heiner


WARNING: multiple messages have this Message-ID (diff)
From: Heiner Kallweit <hkallweit1@gmail.com>
To: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: "Jerome Brunet" <jbrunet@baylibre.com>,
	"Neil Armstrong" <narmstrong@baylibre.com>,
	"Kevin Hilman" <khilman@baylibre.com>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"thierry.reding@gmail.com" <thierry.reding@gmail.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"open list:ARM/Amlogic Meson..."
	<linux-amlogic@lists.infradead.org>,
	linux-pwm@vger.kernel.org
Subject: Re: [PATCH v4 4/4] pwm: meson: make full use of common clock framework
Date: Sat, 15 Apr 2023 08:39:19 +0200	[thread overview]
Message-ID: <4b328dab-5f96-e5d0-3181-ce059d11b04b@gmail.com> (raw)
In-Reply-To: <CAFBinCCzMdQZ4mDF7SEZKHc01MPSepxdzYa+j7G-qDXe5-kBVA@mail.gmail.com>

On 14.04.2023 21:39, Martin Blumenstingl wrote:
> Hello Heiner,
> 
> On Thu, Apr 13, 2023 at 7:55 AM Heiner Kallweit <hkallweit1@gmail.com> wrote:
> [...]
>> Tested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> Unfortunately I have some bad news and I need to take back my Tested-by :-(
> Previously my test was: cycle through all available CPU frequencies
> while stressing the CPU.
> My assumption was: if the system doesn't lock up everything's fine
> because we have a high enough voltage.
> 
> This evening however I got a memory corruption error while trying to
> log in via UART - which I thought was strange.
> So I connected my logic analyzer to my Odroid-C1 and did some experiments:
> 
> period = 30518, duty cycle = 15259 (typically used for the 32kHz
> output to the SDIO wifi chip)
> before your patches / after applying your patches:
> PWM: duty cycle: 50.000000% / 50.000000%
> PWM: period: 30.6 µs / 30.5 µs
> Timing: Time: 15.292 µs (65.395 kHz) / 15.250 µs (65.574 kHz)
> Timing: Average: 15.296 µs (65.377 kHz) / 15.264 µs (65.513 kHz)
> driver debug messages with your patches applied:
> fin_freq: 850000000 Hz
> period=30518 cnt=25940
> duty=15259 duty_cnt=12970
> 
> Then I tried period = 12218, duty cycle = 0 (typically used for the
> highest CPU voltage):
> before your patches / after applying your patches:
> PWM: duty cycle: 0.338983% / n/a (constant low output)
> PWM: period: 12.3 µs / n/a
> Timing: Time: 12.250 µs (81.633 kHz) / n/a
> Timing: Average: 6.148 µs (162.668 kHz) / n/a
> driver debug messages with your patches applied:
> fin_freq: 850000000 Hz
> period=12218 cnt=10385
> 
With a 850MHz input clock we should see a 0.01% duty cycle with 1.2ns
clock pulses. Can we rule out an issue with the measuring equipment?
Is your logic analyzer able to display such short clock pulses?

> Finally I tried period = 12218, duty cycle = 12218 (typically used for
> the lowest CPU voltage):
> before your patches / after applying your patches:
> PWM: duty cycle: 99.661017% / n/a (constant low output)
> PWM: period: 12.3 µs / n/a
> Timing: Time: 12.250 µs (81.633 kHz) / n/a
> Timing: Average: 6.148 µs (162.668 kHz) / n/a
> driver debug messages with your patches applied:
> fin_freq: 850000000 Hz
> period=12218 cnt=10385
> 
Here I have no idea yet.

> After seeing the constant low output with period 12218 I realized that
> my previous test was no good: the CPU was fed the highest possible
> voltage all the time.
> It's not clear to me why period 12218 would give no PWM output at all
> while period 30518 works fine.
> I did an experiment by removing CLK_SET_RATE_PARENT from the divider's
> init.flags -> now XTAL (24MHz) is the only possible clock (it's the
> hardware default). It does indeed bring back the exact same results as
> before (where the XTAL clock was also used; with the changes from this
> series FCLK_DIV3 is now chosen, which runs at 850MHz).
> 
> Do you have any idea what could cause this?
> The FCLK_DIV3 input seems to work as otherwise period 30518 would also not work.
> The calculated values also look sane, so it's not that we have some
> 32-bit overflow (as I'm testing on a 32-bit Meson8b SoC).
> 
At first I'd like to verify that the registers have the expected values.
Can you provide the values of PWM_A/B (depending on which channel is used in your
case) and PWM_MISC_AB at the end of meson_pwm_enable()? Thanks!

> 
> Best regards,
> Martin

Heiner


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

  reply	other threads:[~2023-04-15  6:39 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-13  5:48 [PATCH v4 0/4] pwm: meson: make full use of common clock framework Heiner Kallweit
2023-04-13  5:48 ` Heiner Kallweit
2023-04-13  5:48 ` Heiner Kallweit
2023-04-13  5:49 ` [PATCH v4 1/4] pwm: meson: switch to using struct clk_parent_data for mux parents Heiner Kallweit
2023-04-13  5:49   ` Heiner Kallweit
2023-04-13  5:49   ` Heiner Kallweit
2023-04-13  5:50 ` [PATCH v4 2/4] pwm: meson: don't use hdmi/video clock as mux parent Heiner Kallweit
2023-04-13  5:50   ` Heiner Kallweit
2023-04-13  5:50   ` Heiner Kallweit
2023-04-13  5:51 ` [PATCH v4 3/4] pwm: meson: change clk/pwm gate from mask to bit Heiner Kallweit
2023-04-13  5:51   ` Heiner Kallweit
2023-04-13  5:51   ` Heiner Kallweit
2023-04-13  5:54 ` [PATCH v4 4/4] pwm: meson: make full use of common clock framework Heiner Kallweit
2023-04-13  5:54   ` Heiner Kallweit
2023-04-13  5:54   ` Heiner Kallweit
2023-04-14 19:39   ` Martin Blumenstingl
2023-04-14 19:39     ` Martin Blumenstingl
2023-04-14 19:39     ` Martin Blumenstingl
2023-04-15  6:39     ` Heiner Kallweit [this message]
2023-04-15  6:39       ` Heiner Kallweit
2023-04-15  6:39       ` Heiner Kallweit
2023-04-16 19:26       ` Martin Blumenstingl
2023-04-16 19:26         ` Martin Blumenstingl
2023-04-16 19:26         ` Martin Blumenstingl
2023-04-16 21:34         ` Heiner Kallweit
2023-04-16 21:34           ` Heiner Kallweit
2023-04-16 21:34           ` Heiner Kallweit
2023-04-23 20:55           ` Martin Blumenstingl
2023-04-23 20:55             ` Martin Blumenstingl
2023-04-23 20:55             ` Martin Blumenstingl
2023-04-17  7:23   ` Neil Armstrong
2023-04-17  7:23     ` Neil Armstrong
2023-04-17  7:23     ` Neil Armstrong
2023-04-17  9:17     ` Thierry Reding
2023-04-17  9:17       ` Thierry Reding
2023-04-17  9:17       ` Thierry Reding
2023-04-17  9:53     ` Heiner Kallweit
2023-04-17  9:53       ` Heiner Kallweit
2023-04-17  9:53       ` Heiner Kallweit
2023-04-17  9:59       ` neil.armstrong
2023-04-17  9:59         ` neil.armstrong
2023-04-17  9:59         ` neil.armstrong
2023-04-17 10:36         ` Heiner Kallweit
2023-04-17 10:36           ` Heiner Kallweit
2023-04-17 10:36           ` Heiner Kallweit
2023-04-17 12:21           ` neil.armstrong
2023-04-17 12:21             ` neil.armstrong
2023-04-17 12:21             ` neil.armstrong
2023-04-19 19:58             ` Heiner Kallweit
2023-04-19 19:58               ` Heiner Kallweit
2023-04-19 19:58               ` Heiner Kallweit
2023-04-21  7:39               ` neil.armstrong
2023-04-21  7:39                 ` neil.armstrong
2023-04-21  7:39                 ` neil.armstrong
2023-04-23 20:58               ` Martin Blumenstingl
2023-04-23 20:58                 ` Martin Blumenstingl
2023-04-23 20:58                 ` Martin Blumenstingl
2023-05-01 13:39                 ` Heiner Kallweit
2023-05-01 13:39                   ` Heiner Kallweit
2023-05-01 13:39                   ` Heiner Kallweit
2023-05-19 15:30   ` Dmitry Rokosov
2023-05-19 15:30     ` Dmitry Rokosov
2023-05-19 15:30     ` Dmitry Rokosov
2023-05-19 16:53     ` Heiner Kallweit
2023-05-19 16:53       ` Heiner Kallweit
2023-05-19 16:53       ` Heiner Kallweit
2023-05-22 13:37       ` Dmitry Rokosov
2023-05-22 13:37         ` Dmitry Rokosov
2023-05-22 13:37         ` Dmitry Rokosov
2023-05-22 20:10         ` Heiner Kallweit
2023-05-22 20:10           ` Heiner Kallweit
2023-05-22 20:10           ` Heiner Kallweit
2023-05-23 10:28           ` Dmitry Rokosov
2023-05-23 10:28             ` Dmitry Rokosov
2023-05-23 10:28             ` Dmitry Rokosov
2023-05-23 19:22             ` Heiner Kallweit
2023-05-23 19:22               ` Heiner Kallweit
2023-05-23 19:22               ` Heiner Kallweit
2023-04-17  7:19 ` [PATCH v4 0/4] " Neil Armstrong

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=4b328dab-5f96-e5d0-3181-ce059d11b04b@gmail.com \
    --to=hkallweit1@gmail.com \
    --cc=jbrunet@baylibre.com \
    --cc=khilman@baylibre.com \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=martin.blumenstingl@googlemail.com \
    --cc=narmstrong@baylibre.com \
    --cc=thierry.reding@gmail.com \
    --cc=u.kleine-koenig@pengutronix.de \
    /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.