Hi Laurent,
On Fri, Feb 19, 2016 at 1:07 AM, Laurent Pinchart
<laurent.pinchart@xxxxxxxxxxxxxxxx> wrote:
> Hi Magnus,
>
> On Friday 19 February 2016 01:02:18 Magnus Damm wrote:
>> On Fri, Feb 19, 2016 at 12:33 AM, Laurent Pinchart wrote:
>> > On Thursday 18 February 2016 10:17:16 Geert Uytterhoeven wrote:
>> >> On Thu, Feb 18, 2016 at 10:01 AM, Kuninori Morimoto wrote:
>> >> >>>> I tried this patch, but It didn't use this printk().
>> >> >>>> Am I wrong ?
>> >> >>>>
>> >> >>>> -------------
>> >> >>>> diff --git a/drivers/regulator/da9210-regulator.c
>> >> >>>> b/drivers/regulator/da9210-regulator.c index 01c0e37..85c1166 100644
>> >> >>>> --- a/drivers/regulator/da9210-regulator.c
>> >> >>>> +++ b/drivers/regulator/da9210-regulator.c
>> >> >>>> @@ -167,6 +167,8 @@ static irqreturn_t da9210_irq_handler(int irq,
>> >> >>>> void *data)
>> >> >>>>
>> >> >>>> goto error_i2c;
>> >> >>>>
>> >> >>>> ret = IRQ_HANDLED;
>> >> >>>>
>> >> >>>> + } else if (val != handled) {
>> >> >>>> + printk("---val %x : %x\n", val, handled);
>> >> >>>>
>> >> >>>> }
>> >> >>>
>> >> >>> That's what I meant.
>> >> >>> Do you still see the "irq 311: nobody cared"?
>> >> >>> Do you have the DA9210 driver enabled?
>> >> >
>> >> > You can reproduce it by
>> >> >
>> >> > > git checkout git checkout renesas-drivers-2016-02-09-v4.5-rc3
>> >> > > cp ${Laurent's .config} ${LINUX}
>> >>
>> >> I don't have Laurent's config, and only remote access to Lager.
>> >>
>> >> > and boot, and wait few second
>> >>
>> >> Da9210 and da9063 share the same interrupt. Perhaps da9063 is keeping
>> >> the interrupt line asserted?
>> >>
>> >> Do you have the DA9063 driver enabled?
>> >
>> > I had CONFIG_REGULATOR_DA9210 enabled but CONFIG_REGULATOR_DA9063
>> > disabled.
>> > After enabling CONFIG_REGULATOR_DA9063 the unhandled interrupt problem
>> > goes
>> > away.
>> >
>> > I however got the following different (and totally unrelated as far as I
>> > can see) warning once:
>> >
>> > [ 310.252577] ------------[ cut here ]------------
>> > [ 310.257226] WARNING: CPU: 3 PID: 608 at
>> > /home/laurent/src/iob/renesas/linux/net/ipv4/af_inet.c:155
>> > inet_sock_destruct+0x188/0x1d8()
>> > [ 310.269088] Modules linked in: mmc_block rcar_jpu v4l2_mem2mem
>> > sata_rcar
>> > libata rcar_vin scsi_mod sh_mobile_sdhi soc_camera sh_mmcif tmio_mmc_core
>> > soc_mediabus mmc_core videobuf_core soc_scale_crop(Pa
>> > [ 310.294680] CPU: 3 PID: 608 Comm: kworker/3:1H Tainted: P
>> > 4.5.0-rc3-00463-gd57d2d31ebee #581
>> > [ 310.304431] Hardware name: Generic R8A7790 (Flattened Device Tree)
>> > [ 310.310625] Workqueue: rpciod xprt_autoclose
>> > [ 310.314908] Backtrace:
>> > [ 310.317380] [<c0014c38>] (dump_backtrace) from [<c0014f50>]
>> > (show_stack+0x20/0x24)
>> > [ 310.324959] r6:c05be48c r5:00000000 r4:60000013 r3:e9a62000
>> > [ 310.330669] [<c0014f30>] (show_stack) from [<c01ed99c>]
>> > (dump_stack+0x8c/0xac)
>> > [ 310.337906] [<c01ed910>] (dump_stack) from [<c002aab0>]
>> > (warn_slowpath_common+0x88/0xc4)
>> > [ 310.346006] r5:0000009b r4:00000000
>> > [ 310.349606] [<c002aa28>] (warn_slowpath_common) from [<c002ab18>]
>> > (warn_slowpath_null+0x2c/0x34)
>> > [ 310.358400] r8:e9a248d8 r7:ea375364 r6:e9a248c4 r5:e9a248d8
>> > r4:e9a247c0
>> > [ 310.365156] [<c002aaec>] (warn_slowpath_null) from [<c0405d24>]
>> > (inet_sock_destruct+0x188/0x1d8)
>> > [ 310.373958] [<c0405b9c>] (inet_sock_destruct) from [<c038a2e8>]
>> > (sk_destruct+0x28/0x118)
>> > [ 310.382057] r6:e9d593c0 r5:e9a248d8 r4:e9a247c0 r3:c0405b9c
>> > [ 310.387763] [<c038a2c0>] (sk_destruct) from [<c038a40c>]
>> > (__sk_free+0x34/0xc0)
>> > [ 310.394994] r5:e9a248d8 r4:e9a247c0
>> > [ 310.398595] [<c038a3d8>] (__sk_free) from [<c038a56c>]
>> > (sk_free+0x44/0x48) [ 310.405474] r4:e9a247c0 r3:e9a2486c
>> > [ 310.409074] [<c038a528>] (sk_free) from [<c038a6ac>]
>> > (sk_common_release+0xf0/0xfc)
>> > [ 310.416662] [<c038a5bc>] (sk_common_release) from [<c03f79d8>]
>> > (udp_lib_close+0x10/0x14)
>> > [ 310.424761] r5:e9d593c0 r4:e9a247c0
>> > [ 310.428367] [<c03f79c8>] (udp_lib_close) from [<c0405a6c>]
>> > (inet_release+0x54/0x80)
>> > [ 310.436041] [<c0405a18>] (inet_release) from [<c0384914>]
>> > (sock_release+0x30/0xac)
>> > [ 310.443620] r5:00000000 r4:e9d593c0
>> > [ 310.447224] [<c03848e4>] (sock_release) from [<c0428960>]
>> > (xs_reset_transport+0xc4/0x138)
>> > [ 310.455411] r5:e9a247c0 r4:ea375000
>> > [ 310.459012] [<c042889c>] (xs_reset_transport) from [<c04289f0>]
>> > (xs_close+0x1c/0x30)
>> > [ 310.466764] r8:ff7c4300 r7:ea375228 r6:ea375000 r5:ea375278
>> > r4:ea375000
>> > r3:c04289d4
>> > [ 310.474568] [<c04289d4>] (xs_close) from [<c0425de8>]
>> > (xprt_autoclose+0x40/0x74)
>> > [ 310.481972] r4:ea375244 r3:c04289d4
>> > [ 310.485579] [<c0425da8>] (xprt_autoclose) from [<c004256c>]
>> > (process_one_work+0x170/0x430)
>> > [ 310.493853] r7:c06a4878 r6:e876da00 r5:ea282880 r4:ea375244
>> > [ 310.499558] [<c00423fc>] (process_one_work) from [<c00428b0>]
>> > (worker_thread+0x3c/0x55c)
>> > [ 310.507658] r10:e876da00 r9:c0660100 r8:00000008 r7:ea282898
>> > r6:e876da18 r5:e876da00
>> > [ 310.515544] r4:ea282880
>> > [ 310.518096] [<c0042874>] (worker_thread) from [<c004893c>]
>> > (kthread+0xf4/0x114)
>> > [ 310.525414] r10:00000000 r9:00000000 r8:00000000 r7:c0042874
>> > r6:ea282880 r5:00000000
>> > [ 310.533301] r4:e9948d80
>> > [ 310.535850] [<c0048848>] (kthread) from [<c00119e8>]
>> > (ret_from_fork+0x14/0x2c)
>> > [ 310.543081] r7:00000000 r6:00000000 r5:c0048848 r4:e9948d80
>> > [ 310.548803] ---[ end trace 02711a72b6e0a70c ]---
>>
>> I'm guessing that you enabled LPAE in your kernel configuration but
>> the ethernet driver only does 32-bit bus mastering?
>
> You're always on top of LPAE, DMA mastering and IOMMU issues :-) Yes, that's
> the case. Do we have a fix planned ?
Well, not to sound too grumpy, but I recall asking the ethernet driver
developers assigned to do this years and years ago. That request must
have been lost in the mountain of white space and header sorting
fixes. And now with current state I guess focus is on the
new-and-improved device driver for the ethernet driver included in the
latest generation SoCs.
One way to check if it is related to LPAE is comment out the high
memory banks in the board DTS and only keep the first memory bank
enabled (which sits in 32-bit space). That way you can have LPAE
enabled in the kernel config but limit the addresses to 32-bit.
The proper fix is to update all the drivers to support 40-bit access
in case the hardware supports it. If not then we either need to use
IPMMU or restrict memory allocations to DMA zone somehow. DMA zone is
not very fun if we want to do zero copy buffer passing, so I guess
multimedia stuff needs to use IPMMU.
Good news (as you know) is that SYS-DMAC supports 40-bit addresses and
so does the rcar-dmac.c driver. It's just "the rest"...
Cheers,
/ magnus
