linux-kernel.vger.kernel.org archive mirror
 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 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).