All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Twiss <stwiss.opensource@diasemi.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>,
	Matti Vaittinen <mazziesaccount@gmail.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Support Opensource <Support.Opensource@diasemi.com>,
	Mark Brown <broonie@kernel.org>
Subject: RE: [PATCH] regmap: regmap-irq: silently ignore unsupported type settings
Date: Mon, 7 Jan 2019 18:52:25 +0000	[thread overview]
Message-ID: <6ED8E3B22081A4459DAC7699F3695FB7022179F018@SW-EX-MBX02.diasemi.com> (raw)
In-Reply-To: <CAMuHMdWbV2=LfSWz0rFTGRakZ=2iXKOYdM_Uwaov8-OsJpUgoA@mail.gmail.com>

Hi Geert,

On 04 January 2019 at 15:48, Geert Uytterhoeven wrote:
> To: Steve Twiss <stwiss.opensource@diasemi.com>
> Subject: Re: [PATCH] regmap: regmap-irq: silently ignore unsupported type settings
> 
> ()Hi Steve,
> 
> On Wed, Jan 2, 2019 at 4:31 PM Steve Twiss
> <stwiss.opensource@diasemi.com> wrote:
> > On 01 January 2019 @17:36, Geert Uytterhoeven wrote:
> > > Subject: Re: [PATCH] regmap: regmap-irq: silently ignore unsupported type settings
> > > On Mon, Dec 31, 2018 at 8:14 PM Mark Brown <broonie@kernel.org> wrote:
> > > > On Sat, Dec 29, 2018 at 12:13:32PM +0100, Geert Uytterhoeven wrote:
> > > > > > Geert, do you know if anyone vould to test this?
> > > > > Thanks, that seems to fix the issue with da9063-rtc.
> > > > > I don't know how to trigger an actual interrupt, though.
> > > > If it's a RTC does it have an alarm you can set?
> > > That's what I had expected, too, but there is no alarm file under
> > > /sys/class/rtc/.
> >
> > To communicate with the DA9063 RTC I am use ioctl function calls
> >
> >  - RTC_SET_TIME
> >  - RTC_RD_TIME
> >  - RTC_ALM_SET
> >  - RTC_ALM_READ
> >  - RTC_AIE_ON
> >  - RTC_AIE_OFF
> >
> > - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/rtc.txt
> > - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/rtc
> >
> > Although I don't use the test programs found in Linux, the ioctl calls I
> > make are shown in the Linux selftests. I believe that Alexandre Belloni
> > updated the RTC tests recently -- but I am not up to date with the latest.
> >
> > git show
> d8da8665e8e34c14f9b20fe3f21dff29b24cbf02:tools/testing/selftests/rtc/rtctest.c
 
Okay. So, I've got my own RTC tests which I wrote using the ioctl()
commands. I've not used the rtctest from the kernel before.
Also, I would need to look more closely to give you a better reply
for your results.

> root@koelsch:~# tools/testing/selftests/rtc/rtctest
> [==========] Running 5 tests from 2 test cases.
> [ RUN      ] rtc.date_read
> rtctest.c:49:rtc.date_read:Current RTC date/time is 04/01/2019 14:44:25.
> [       OK ] rtc.date_read
> [ RUN      ] rtc.uie_read
> [       OK ] rtc.uie_read
> [ RUN      ] rtc.uie_select
> rtctest.c:98:rtc.uie_select:Expected 0 (0) != rc (0)
> rtc.uie_select: Test terminated by assertion
> [     FAIL ] rtc.uie_select
> [ RUN      ] rtc.alarm_alm_set
> rtctest.c:137:rtc.alarm_alm_set:Alarm time now set to 14:47:23.
> rtctest.c:148:rtc.alarm_alm_set:Expected 0 (0) != rc (0)
> rtc.alarm_alm_set: Test failed at step #5
> [     FAIL ] rtc.alarm_alm_set
> [ RUN      ] rtc.alarm_wkalm_set
> rtctest.c:198:rtc.alarm_wkalm_set:Alarm time now set to 04/01/2019 14:47:28.
> rtctest.c:205:rtc.alarm_wkalm_set:Expected 0 (0) != rc (0)
> rtctest.c:214:rtc.alarm_wkalm_set:Expected new (1546613934) == secs
> (1546613248)
> rtc.alarm_wkalm_set: Test terminated by assertion
> [     FAIL ] rtc.alarm_wkalm_set
> [==========] 2 / 5 tests passed.
> [  FAILED  ]
> root@koelsch:~#
> 
> No interrupt fired, as witnessed by /proc/interrupts, and the pr_info()
> I had added to da9063_alarm_event().
>
> Note that rtctest behaves the same before the regmap irq breakage,
> so this is not a recent regression...

I've just incrementally rebased from v4.18 through to v4.20 and I see the
IRQ working for the DA9063 alarm on my test system. I've not applied any extra
patches and the results below are for the following vanilla kernels: v4.18,
v4.19, v4.20.

The next results are only for regressions in the RTC alarm for the DA9063. I
only ran one simple "TEST" to create an output for you (although I did it twice
to produce two IRQs):

--- 8< ---
v4.18
-----
> cat *.res
[PASS] Set RTC alarms functional test for TEST with DA9063-TEST
[PASS] Setting test type to use RTC alarm functional test for TEST with DA9063-TEST
[PASS] Running set alarm tests for RTC { 1 }
[PASS] Running test for test_rtc_prog_set_simple_alarm_seconds()
[PASS] Setting the current date and time from the da9063-rtc as 2000-01-01 00:00:00
[PASS] Setting the alarm date and time from the da9063-rtc as 2000-01-01 00:00:05 (+5 secs into the future)
[PASS] Setting the listener on da9063-rtc then waiting for elapsed timeout of 15 seconds...
[PASS] The alarm was triggered on da9063-rtc within the expected time and the alarm happened at 2000-01-01 00:00:05
[PASS] Running test for test_rtc_prog_set_simple_alarm_seconds()
[PASS] Setting the current date and time from the da9063-rtc as 2000-01-01 00:00:00
[PASS] Setting the alarm date and time from the da9063-rtc as 2000-01-01 00:00:15 (+15 secs into the future)
[PASS] Setting the listener on da9063-rtc then waiting for elapsed timeout of 25 seconds...
[PASS] The alarm was triggered on da9063-rtc within the expected time and the alarm happened at 2000-01-01 00:00:15
[PASS] Finished running DA9063 set alarm tests for RTC { 1 } on TEST
> cat /proc/interrupts | grep da9063
249:          2          0          0          0  gpio-mxc  11 Level     da9063-irq
302:          0          0          0          0  da9063-irq   0 Level     ONKEY
303:          0          0          2          0  da9063-irq   1 Level     ALARM
310:          0          0          0          0  da9063-irq   8 Level     LDO_LIM
> uname -a
Linux test 4.18.0 #1 SMP Mon Jan 7 16:25:37 GMT 2019 armv7l GNU/Linux

v4.19
-----
> cat *.res
[PASS] Set RTC alarms functional test for TEST with DA9063-TEST
[PASS] Setting test type to use RTC alarm functional test for TEST with DA9063-TEST
[PASS] Running set alarm tests for RTC { 1 }
[PASS] Running test for test_rtc_prog_set_simple_alarm_seconds()
[PASS] Setting the current date and time from the da9063-rtc as 2000-01-01 00:00:00
[PASS] Setting the alarm date and time from the da9063-rtc as 2000-01-01 00:00:05 (+5 secs into the future)
[PASS] Setting the listener on da9063-rtc then waiting for elapsed timeout of 15 seconds...
[PASS] The alarm was triggered on da9063-rtc within the expected time and the alarm happened at 2000-01-01 00:00:05
[PASS] Running test for test_rtc_prog_set_simple_alarm_seconds()
[PASS] Setting the current date and time from the da9063-rtc as 2000-01-01 00:00:00
[PASS] Setting the alarm date and time from the da9063-rtc as 2000-01-01 00:00:15 (+15 secs into the future)
[PASS] Setting the listener on da9063-rtc then waiting for elapsed timeout of 25 seconds...
[PASS] The alarm was triggered on da9063-rtc within the expected time and the alarm happened at 2000-01-01 00:00:15
[PASS] Finished running DA9063 set alarm tests for RTC { 1 } on TEST
> cat /proc/interrupts | grep da9063
249:          2          0          0          0  gpio-mxc  11 Level     da9063-irq
302:          0          0          0          0  da9063-irq   0 Level     ONKEY
303:          0          0          0          2  da9063-irq   1 Level     ALARM
310:          0          0          0          0  da9063-irq   8 Level     LDO_LIM
> uname -a
Linux test 4.19.0 #1 SMP Mon Jan 7 17:34:43 GMT 2019 armv7l GNU/Linux

v4.20
-----
> cat *.res
[PASS] Set RTC alarms functional test for TEST with DA9063-TEST
[PASS] Setting test type to use RTC alarm functional test for TEST with DA9063-TEST
[PASS] Running set alarm tests for RTC { 1 }
[PASS] Running test for test_rtc_prog_set_simple_alarm_seconds()
[PASS] Setting the current date and time from the da9063-rtc as 2000-01-01 00:00:00
[PASS] Setting the alarm date and time from the da9063-rtc as 2000-01-01 00:00:05 (+5 secs into the future)
[PASS] Setting the listener on da9063-rtc then waiting for elapsed timeout of 15 seconds...
[PASS] The alarm was triggered on da9063-rtc within the expected time and the alarm happened at 2000-01-01 00:00:05
[PASS] Running test for test_rtc_prog_set_simple_alarm_seconds()
[PASS] Setting the current date and time from the da9063-rtc as 2000-01-01 00:00:00
[PASS] Setting the alarm date and time from the da9063-rtc as 2000-01-01 00:00:15 (+15 secs into the future)
[PASS] Setting the listener on da9063-rtc then waiting for elapsed timeout of 25 seconds...
[PASS] The alarm was triggered on da9063-rtc within the expected time and the alarm happened at 2000-01-01 00:00:15
[PASS] Finished running DA9063 set alarm tests for RTC { 1 } on TEST
> cat /proc/interrupts | grep da9063
249:          2          0          0          0  gpio-mxc  11 Level     da9063-irq
302:          0          0          0          0  da9063-irq   0 Level     ONKEY
303:          0          0          2          0  da9063-irq   1 Level     ALARM
310:          0          0          0          0  da9063-irq   8 Level     LDO_LIM
> uname -a
Linux test 4.20.0 #1 SMP Mon Jan 7 17:46:59 GMT 2019 armv7l GNU/Linux
--- 8< ---

So, with these results, I don't think this is a regression going back very far.

But when I get to vanilla v5.0-rc1, there are lots of IRQ failures, so I can't
test because nothing gets loaded. All of the IRQs in each of the DA9063
MFD cells are failing, not just for the RTC. I get the following from the
console logs for v5.0-rc1 ...

da9063 1-0058: Device detected (chip-ID: 0x61, var-ID: 0x60)
genirq: Setting trigger mode 8 for irq 310 failed (regmap_irq_set_type+0x0/0x164)
da9063-regulators da9063-regulators: Failed to request LDO_LIM IRQ.
da9063-regulators: probe of da9063-regulators failed with error -524
[...]
da9063-onkey da9063-onkey: DMA mask not set
genirq: Setting trigger mode 8 for irq 302 failed (regmap_irq_set_type+0x0/0x164)
da9063-onkey da9063-onkey: Failed to request IRQ 302: -524
da9063-onkey: probe of da9063-onkey failed with error -524
da9063-rtc da9063-rtc: DMA mask not set
da9063-rtc da9063-rtc: registered as rtc0
genirq: Setting trigger mode 8 for irq 303 failed (regmap_irq_set_type+0x0/0x164)
da9063-rtc da9063-rtc: Failed to request ALARM IRQ 303: -524
da9063-rtc: probe of da9063-rtc failed with error -524
[...]
da9063-watchdog da9063-watchdog: DMA mask not set

I'll test the proposed fix tomorrow.

Regards,
Steve


  reply	other threads:[~2019-01-07 18:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-27  8:44 [PATCH] regmap: regmap-irq: silently ignore unsupported type settings Matti Vaittinen
2018-12-29 11:13 ` Geert Uytterhoeven
2018-12-31 19:14   ` Mark Brown
2019-01-01 17:36     ` Geert Uytterhoeven
2019-01-02 15:31       ` Steve Twiss
2019-01-04 15:47         ` Geert Uytterhoeven
2019-01-07 18:52           ` Steve Twiss [this message]
2019-01-08 10:21   ` Steve Twiss
2019-01-03 17:27 ` Charles Keepax

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=6ED8E3B22081A4459DAC7699F3695FB7022179F018@SW-EX-MBX02.diasemi.com \
    --to=stwiss.opensource@diasemi.com \
    --cc=Support.Opensource@diasemi.com \
    --cc=broonie@kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matti.vaittinen@fi.rohmeurope.com \
    --cc=mazziesaccount@gmail.com \
    --cc=rafael@kernel.org \
    /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.