* [PATCH 1/2] ARM: dts: imx6qdl-sabreauto: Add sensors
From: Leonard Crestez @ 2018-06-14 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5Czf1bO7vJZ1UG46DyVhzApqS82GFw+NFm_HN5tjD=xoQ@mail.gmail.com>
On Thu, 2018-06-07 at 14:07 -0300, Fabio Estevam wrote:
> Hi Leonard,
>
> On Thu, Jun 7, 2018 at 2:00 PM, Leonard Crestez <leonard.crestez@nxp.com> wrote:
>
> > +
> > + isl29023 at 44 {
>
> According to Devicetree Specification v0.2 document:
>
> "The name of a node should be somewhat generic, reflecting the function
> of the device and not its precise programming model."
>
> So you could write:
>
> light-sensor at 44
Ok, will fix in v2.
Should I also assign a label, like "isl29023: light-sensor at 44"? I
couldn't find any recommendation on this.
There are no immediate uses for a label but this practice is very
common. Having labels allows creating minor board variants with reduced
churn in the base dts so it seems good.
--
Regards,
Leonard
^ permalink raw reply
* [PATCH v4 0/7] add virt-dma support for imx-sdma
From: Robin Gong @ 2018-06-14 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528966400.21021.26.camel@pengutronix.de>
Hi Lucas,
Could you double check again? Still can reproduce lockdep
warning on UART if change
spin_lock_lockirqsave/spinlock_unlock_irqrestore to
spin_lock/spin_unlock in sdma_int_handler as you said without patch7/7.
Would you please ask below two more questions?
1. Does your uart case pass now with my v4 patchset?
2. Do you make some code change in your local('I just gave this series
a spin')to reproduce your below issue? If yes, could you post your
change?
On ?, 2018-06-14 at 10:53 +0200, Lucas Stach wrote:
> Hi Robin,
>
> I just gave this series a spin and it seems there is even more
> locking
> fun, see the lockdep output below. After taking a short look it seems
> this is caused by using the wrong spinlock variants in
> sdma_int_handler(), those should also use the _irqsave ones. When
> fixing this you might want to reconsider patch 7/7, as it's probably
> not needed at all.
>
> Regards,
> Lucas
>
> [???20.479401]
> ========================================================
> [???20.485769] WARNING: possible irq lock inversion dependency
> detected
> [???20.492140] 4.17.0+ #1538 Not tainted
> [???20.495814] ------------------------------------------------------
> --
> [???20.502181] systemd/1 just changed the state of lock:
> [???20.507247] c0abdafc (&(&substream->self_group.lock)->rlock){-
> ...}, at: snd_pcm_stream_lock+0x54/0x60
> [???20.516523] but this lock took another, HARDIRQ-unsafe lock in the
> past:
> [???20.523234]??(fs_reclaim){+.+.}
> [???20.523253]?
> [???20.523253]?
> [???20.523253] and interrupts could create inverse lock ordering
> between them.
> [???20.523253]?
> [???20.537804]?
> [???20.537804] other info that might help us debug this:
> [???20.544344]??Possible interrupt unsafe locking scenario:
> [???20.544344]?
> [???20.551144]????????CPU0????????????????????CPU1
> [???20.555686]????????----????????????????????----
> [???20.560224]???lock(fs_reclaim);
> [???20.563386]????????????????????????????????local_irq_disable();
> [???20.569315]????????????????????????????????lock(&(&substream-
> >self_group.lock)->rlock);
> [???20.577337]????????????????????????????????lock(fs_reclaim);
> [???20.583014]???<Interrupt>
> [???20.585643]?????lock(&(&substream->self_group.lock)->rlock);
> [???20.591322]?
> [???20.591322]??*** DEADLOCK ***
> [???20.591322]?
> [???20.597260] 1 lock held by systemd/1:
> [???20.607806]??#0: ab23d11c (snd_pcm_link_rwlock){.-..}, at:
> snd_pcm_stream_lock+0x4c/0x60
> [???20.615951]?
> [???20.615951] the shortest dependencies between 2nd lock and 1st
> lock:
> [???20.623799]??-> (fs_reclaim){+.+.} ops: 248474 {
> [???20.628456]?????HARDIRQ-ON-W at:
> [???20.631716]???????????????????????lock_acquire+0x260/0x29c
> [???20.637223]???????????????????????fs_reclaim_acquire+0x48/0x58
> [???20.643075]???????????????????????kmem_cache_alloc_trace+0x3c/0x36
> 4
> [???20.649366]???????????????????????alloc_worker.constprop.15+0x28/0
> x64
> [???20.655824]???????????????????????init_rescuer.part.5+0x20/0xa4
> [???20.661764]???????????????????????workqueue_init+0x124/0x1f8
> [???20.667446]???????????????????????kernel_init_freeable+0x60/0x550
> [???20.673561]???????????????????????kernel_init+0x18/0x120
> [???20.678890]???????????????????????ret_from_fork+0x14/0x20
> [???20.684299]?????????????????????????(null)
> [???20.688408]?????SOFTIRQ-ON-W at:
> [???20.691659]???????????????????????lock_acquire+0x260/0x29c
> [???20.697158]???????????????????????fs_reclaim_acquire+0x48/0x58
> [???20.703006]???????????????????????kmem_cache_alloc_trace+0x3c/0x36
> 4
> [???20.709288]???????????????????????alloc_worker.constprop.15+0x28/0
> x64
> [???20.709301]???????????????????????init_rescuer.part.5+0x20/0xa4
> [???20.720717]???????????????????????workqueue_init+0x124/0x1f8
> [???20.720729]???????????????????????kernel_init_freeable+0x60/0x550
> [???20.720738]???????????????????????kernel_init+0x18/0x120
> [???20.720746]???????????????????????ret_from_fork+0x14/0x20
> [???20.720751]?????????????????????????(null)
> [???20.720756]?????INITIAL USE at:
> [???20.720770]??????????????????????lock_acquire+0x260/0x29c
> [???20.720782]??????????????????????fs_reclaim_acquire+0x48/0x58
> [???20.774374]??????????????????????kmem_cache_alloc_trace+0x3c/0x364
> [???20.780574]??????????????????????alloc_worker.constprop.15+0x28/0x
> 64
> [???20.786945]??????????????????????init_rescuer.part.5+0x20/0xa4
> [???20.792794]??????????????????????workqueue_init+0x124/0x1f8
> [???20.798384]??????????????????????kernel_init_freeable+0x60/0x550
> [???20.804406]??????????????????????kernel_init+0x18/0x120
> [???20.809648]??????????????????????ret_from_fork+0x14/0x20
> [???20.814971]????????????????????????(null)
> [???20.818992]???}
> [???20.820768]???... key??????at: [<80e22074>]
> __fs_reclaim_map+0x0/0x10
> [???20.827220]???... acquired at:
> [???20.830289]????fs_reclaim_acquire+0x48/0x58
> [???20.834487]????kmem_cache_alloc_trace+0x3c/0x364
> [???20.839123]????sdma_transfer_init+0x44/0x130
> [???20.843409]????sdma_prep_dma_cyclic+0x78/0x21c
> [???20.847869]????snd_dmaengine_pcm_trigger+0xdc/0x184
> [???20.852764]????soc_pcm_trigger+0x164/0x190
> [???20.856876]????snd_pcm_do_start+0x34/0x40
> [???20.860902]????snd_pcm_action_single+0x48/0x74
> [???20.865360]????snd_pcm_action+0x34/0xfc
> [???20.869213]????snd_pcm_ioctl+0x910/0x10ec
> [???20.873241]????vfs_ioctl+0x30/0x44
> [???20.876657]????do_vfs_ioctl+0xac/0x974
> [???20.880421]????ksys_ioctl+0x48/0x64
> [???20.883923]????sys_ioctl+0x18/0x1c
> [???20.887340]????ret_fast_syscall+0x0/0x28
> [???20.891277]????0x7289bcbc
> [???20.893909]?
> [???20.895410] -> (&(&substream->self_group.lock)->rlock){-...} ops:
> 59 {
> [???20.901977]????IN-HARDIRQ-W at:
> [???20.905143]?????????????????????lock_acquire+0x260/0x29c
> [???20.910473]?????????????????????_raw_spin_lock+0x48/0x58
> [???20.915801]?????????????????????snd_pcm_stream_lock+0x54/0x60
> [???20.921561]?????????????????????_snd_pcm_stream_lock_irqsave+0x40/
> 0x48
> [???20.928107]?????????????????????snd_pcm_period_elapsed+0x2c/0xa4
> [???20.934127]?????????????????????dmaengine_pcm_dma_complete+0x54/0x
> 58
> [???20.940498]?????????????????????sdma_int_handler+0x1dc/0x2a8
> [???20.946179]?????????????????????__handle_irq_event_percpu+0x1fc/0x
> 498
> [???20.952635]?????????????????????handle_irq_event_percpu+0x38/0x8c
> [???20.958742]?????????????????????handle_irq_event+0x48/0x6c
> [???20.964242]?????????????????????handle_fasteoi_irq+0xc4/0x138
> [???20.970006]?????????????????????generic_handle_irq+0x28/0x38
> [???20.975681]?????????????????????__handle_domain_irq+0xb0/0xc4
> [???20.981443]?????????????????????gic_handle_irq+0x68/0xa0
> [???20.986769]?????????????????????__irq_svc+0x70/0xb0
> [???20.991662]?????????????????????_raw_spin_unlock_irq+0x38/0x6c
> [???20.997511]?????????????????????task_work_run+0x90/0xb8
> [???21.002751]?????????????????????do_work_pending+0xc8/0xd0
> [???21.008164]?????????????????????slow_work_pending+0xc/0x20
> [???21.013661]?????????????????????0x76c77e86
> [???21.017768]????INITIAL USE at:
> [???21.020844]????????????????????lock_acquire+0x260/0x29c
> [???21.026086]????????????????????_raw_spin_lock+0x48/0x58
> [???21.031328]????????????????????snd_pcm_stream_lock+0x54/0x60
> [???21.037002]????????????????????snd_pcm_stream_lock_irq+0x38/0x3c
> [???21.043023]????????????????????snd_pcm_sync_ptr+0x214/0x260
> [???21.048609]????????????????????snd_pcm_ioctl+0xbe0/0x10ec
> [???21.054027]????????????????????vfs_ioctl+0x30/0x44
> [???21.058832]????????????????????do_vfs_ioctl+0xac/0x974
> [???21.063984]????????????????????ksys_ioctl+0x48/0x64
> [???21.068875]????????????????????sys_ioctl+0x18/0x1c
> [???21.073679]????????????????????ret_fast_syscall+0x0/0x28
> [???21.079004]????????????????????0x7e9026dc
> [???21.083023]??}
> [???21.084710]??... key??????at: [<8162a6e4>] __key.31798+0x0/0x8
> [???21.090552]??... acquired at:
> [???21.093537]????mark_lock+0x3a4/0x69c
> [???21.097128]????__lock_acquire+0x420/0x16d4
> [???21.101239]????lock_acquire+0x260/0x29c
> [???21.105091]????_raw_spin_lock+0x48/0x58
> [???21.108940]????snd_pcm_stream_lock+0x54/0x60
> [???21.113226]????_snd_pcm_stream_lock_irqsave+0x40/0x48
> [???21.118296]????snd_pcm_period_elapsed+0x2c/0xa4
> [???21.122841]????dmaengine_pcm_dma_complete+0x54/0x58
> [???21.127735]????sdma_int_handler+0x1dc/0x2a8
> [???21.131937]????__handle_irq_event_percpu+0x1fc/0x498
> [???21.136915]????handle_irq_event_percpu+0x38/0x8c
> [???21.141547]????handle_irq_event+0x48/0x6c
> [???21.145570]????handle_fasteoi_irq+0xc4/0x138
> [???21.149854]????generic_handle_irq+0x28/0x38
> [???21.154052]????__handle_domain_irq+0xb0/0xc4
> [???21.158335]????gic_handle_irq+0x68/0xa0
> [???21.162184]????__irq_svc+0x70/0xb0
> [???21.165601]????_raw_spin_unlock_irq+0x38/0x6c
> [???21.169973]????task_work_run+0x90/0xb8
> [???21.173735]????do_work_pending+0xc8/0xd0
> [???21.177670]????slow_work_pending+0xc/0x20
> [???21.181691]????0x76c77e86
> [???21.184320]?
> [???21.185821]?
> [???21.185821] stack backtrace:
> [???21.190198] CPU: 0 PID: 1 Comm: systemd Not tainted 4.17.0+ #1538
> [???21.196303] Hardware name: Freescale i.MX6 Quad/DualLite (Device
> Tree)
> [???21.202841] Backtrace:?
> [???21.205314] [<8010e318>] (dump_backtrace) from [<8010e604>]
> (show_stack+0x20/0x24)
> [???21.212900]??r7:80e9f3d0 r6:00000000 r5:60070193 r4:80e9f3d0
> [???21.218581] [<8010e5e4>] (show_stack) from [<8099b660>]
> (dump_stack+0xa4/0xd8)
> [???21.225825] [<8099b5bc>] (dump_stack) from [<8017b52c>]
> (print_irq_inversion_bug+0x15c/0x1fc)
> [???21.234368]??r9:814da818 r8:00000001 r7:ee926c00 r6:00000000
> r5:ee915bb0 r4:814da818
> [???21.242133] [<8017b3d0>] (print_irq_inversion_bug) from
> [<8017b6dc>] (check_usage_forwards+0x110/0x13c)
> [???21.251544]??r9:00000002 r8:80bfd3e2 r7:ee926c00 r6:ee927148
> r5:80e08488 r4:00000001
> [???21.259306] [<8017b5cc>] (check_usage_forwards) from [<8017c2a4>]
> (mark_lock+0x3a4/0x69c)
> [???21.267500]??r9:ee926c00 r8:80a03cd8 r7:00000101 r6:00000002
> r5:00000000 r4:ee927148
> [???21.275263] [<8017bf00>] (mark_lock) from [<8017cf68>]
> (__lock_acquire+0x420/0x16d4)
> [???21.283023]??r10:ee927148 r9:ed4620e4 r8:ee926c00 r7:00000000
> r6:00000001 r5:00000001
> [???21.290863]??r4:00000490
> [???21.293416] [<8017cb48>] (__lock_acquire) from [<8017ed58>]
> (lock_acquire+0x260/0x29c)
> [???21.301350]??r10:00000001 r9:80e084a4 r8:00000000 r7:00000000
> r6:00000000 r5:ed4620e4
> [???21.309189]??r4:00000000
> [???21.311746] [<8017eaf8>] (lock_acquire) from [<809b74f0>]
> (_raw_spin_lock+0x48/0x58)
> [???21.319506]??r10:ee0a4714 r9:ed457100 r8:ee0a46c8 r7:ee0a4714
> r6:ee0a4010 r5:807847b0
> [???21.327346]??r4:ed4620d4
> [???21.329902] [<809b74a8>] (_raw_spin_lock) from [<807847b0>]
> (snd_pcm_stream_lock+0x54/0x60)
> [???21.338265]??r5:ed462000 r4:ed462000
> [???21.341863] [<8078475c>] (snd_pcm_stream_lock) from [<80784838>]
> (_snd_pcm_stream_lock_irqsave+0x40/0x48)
> [???21.351440]??r5:ed462000 r4:60070193
> [???21.355042] [<807847f8>] (_snd_pcm_stream_lock_irqsave) from
> [<8078b044>] (snd_pcm_period_elapsed+0x2c/0xa4)
> [???21.364881]??r5:ee3ef000 r4:ed462000
> [???21.368478] [<8078b018>] (snd_pcm_period_elapsed) from
> [<8078d7b4>] (dmaengine_pcm_dma_complete+0x54/0x58)
> [???21.378148]??r7:ee0a4714 r6:ee0a4010 r5:00000007 r4:ee0a46bc
> [???21.383827] [<8078d760>] (dmaengine_pcm_dma_complete) from
> [<80504c0c>] (sdma_int_handler+0x1dc/0x2a8)
> [???21.393157] [<80504a30>] (sdma_int_handler) from [<8018cd28>]
> (__handle_irq_event_percpu+0x1fc/0x498)
> [???21.402393]??r10:00000000 r9:eeafd400 r8:80e084a4 r7:00000038
> r6:00000038 r5:80ea3c12
> [???21.410233]??r4:ee2b5d40
> [???21.412787] [<8018cb2c>] (__handle_irq_event_percpu) from
> [<8018cffc>] (handle_irq_event_percpu+0x38/0x8c)
> [???21.422457]??r10:00000000 r9:ee914000 r8:ee81d400 r7:00000038
> r6:eeafd400 r5:eeafd464
> [???21.430296]??r4:80e08488
> [???21.432852] [<8018cfc4>] (handle_irq_event_percpu) from
> [<8018d098>] (handle_irq_event+0x48/0x6c)
> [???21.441736]??r6:eeafd464 r5:eeafd464 r4:eeafd400
> [???21.446374] [<8018d050>] (handle_irq_event) from [<8019146c>]
> (handle_fasteoi_irq+0xc4/0x138)
> [???21.454912]??r7:00000038 r6:eeafd464 r5:80e10a60 r4:eeafd400
> [???21.460589] [<801913a8>] (handle_fasteoi_irq) from [<8018bd9c>]
> (generic_handle_irq+0x28/0x38)
> [???21.469214]??r7:00000038 r6:80d92ae4 r5:00000000 r4:00000000
> [???21.474893] [<8018bd74>] (generic_handle_irq) from [<8018c48c>]
> (__handle_domain_irq+0xb0/0xc4)
> [???21.483611] [<8018c3dc>] (__handle_domain_irq) from [<80102330>]
> (gic_handle_irq+0x68/0xa0)
> [???21.491978]??r9:ee914000 r8:f4001100 r7:80e5c6bc r6:ee915f00
> r5:80e08c3c r4:f4000100
> [???21.499738] [<801022c8>] (gic_handle_irq) from [<801019f0>]
> (__irq_svc+0x70/0xb0)
> [???21.507233] Exception stack(0xee915f00 to 0xee915f48)
> [???21.512303] 5f00: 00000001 00000004 00000000 ee926c00 ee9270a8
> ee926c00 ecc45e00 ee9270a8
> [???21.520498] 5f20: 80ec23b0 ee914000 00000000 ee915f64 ee915f20
> ee915f50 8017c7c0 809b78ac
> [???21.528687] 5f40: 20070013 ffffffff
> [???21.532193]??r9:ee914000 r8:80ec23b0 r7:ee915f34 r6:ffffffff
> r5:20070013 r4:809b78ac
> [???21.539959] [<809b7874>] (_raw_spin_unlock_irq) from [<8014e98c>]
> (task_work_run+0x90/0xb8)
> [???21.548321]??r5:ee926c00 r4:ecc45e00
> [???21.551913] [<8014e8fc>] (task_work_run) from [<8010da3c>]
> (do_work_pending+0xc8/0xd0)
> [???21.559848]??r9:ee914000 r8:801011c4 r7:ee915fb0 r6:ffffe000
> r5:00000004 r4:801011c4
> [???21.567608] [<8010d974>] (do_work_pending) from [<80101034>]
> (slow_work_pending+0xc/0x20)
> [???21.575797] Exception stack(0xee915fb0 to 0xee915ff8)
> [???21.580864] 5fa0:?????????????????????????????????????00000000
> 020c34e8 46059f00 00000000
> [???21.589059] 5fc0: 00000002 76f133a4 020df680 00000006 76e6e168
> 00000035 7ef81778 00000035
> [???21.597253] 5fe0: 00000006 7ef816a0 76c75d67 76c77e86 20070030
> 00000039
> [???21.603883]??r7:00000006 r6:020df680 r5:76f133a4 r4:00000002
>
> Am Donnerstag, den 14.06.2018, 22:02 +0800 schrieb Robin Gong:
> >
> > The legacy sdma driver has below limitations or drawbacks:
> > ? 1. Hardcode the max BDs number as "PAGE_SIZE / sizeof(*)", and
> > alloc
> > ?????one page size for one channel regardless of only few BDs
> > needed
> > ?????most time. But in few cases, the max PAGE_SIZE maybe not
> > enough.
> > ? 2. One SDMA channel can't stop immediatley once channel disabled
> > which
> > ?????means SDMA interrupt may come in after this channel
> > terminated.There
> > ?????are some patches for this corner case such as commit
> > "2746e2c389f9",
> > ?????but not cover non-cyclic.
> >
> > The common virt-dma overcomes the above limitations. It can alloc
> > bd
> > dynamically and free bd once this tx transfer done. No memory
> > wasted or
> > maximum limititation here, only depends on how many memory can be
> > requested
> > from kernel. For No.2, such issue can be workaround by checking if
> > there
> > is available descript("sdmac->desc") now once the unwanted
> > interrupt
> > coming. At last the common virt-dma is easier for sdma driver
> > maintain.
> >
> > Change from v3:
> > ? 1. add two uart patches which impacted by this patchset.
> > ? 2. unlock 'vc.lock' before cyclic dma callback and lock again
> > after
> > ?????it because some driver such as uart will call
> > dmaengine_tx_status
> > ?????which will acquire 'vc.lock' again and dead lock comes out.
> > ? 3. remove 'Revert commit' stuff since that patch is not wrong and
> > ?????combine two patch into one patch as Sascha's comment.
> >
> > Change from v2:
> > ? 1. include Sascha's patch to make the main patch easier to
> > review.
> > ?????Thanks Sacha.
> > ? 2. remove useless 'desc'/'chan' in struct sdma_channe.
> >
> > Change from v1:
> > ? 1. split v1 patch into 5 patches.
> > ? 2. remove some unnecessary condition check.
> > ? 3. remove unnecessary 'pending' list.
> >
> > Robin Gong (6):
> > ? tty: serial: imx: correct dma cookie status
> > ? dmaengine: imx-sdma: add virt-dma support
> > ? dmaengine: imx-sdma: remove useless 'lock' and 'enabled' in
> > 'struct
> > ????sdma_channel'
> > ? dmaengine: imx-sdma: remove the maximum limitation for bd numbers
> > ? dmaengine: imx-sdma: add sdma_transfer_init to decrease code
> > overlap
> > ? tty: serial: imx: split all dma setup operations out of
> > 'port.lock'
> > ????protector
> >
> > Sascha Hauer (1):
> > ? dmaengine: imx-sdma: factor out a struct sdma_desc from struct
> > ????sdma_channel
> >
> > ?drivers/dma/Kconfig??????|???1 +
> > ?drivers/dma/imx-sdma.c???| 394 +++++++++++++++++++++++++++------
> > --------------
> > ?drivers/tty/serial/imx.c |??99 ++++++------
> > ?3 files changed, 282 insertions(+), 212 deletions(-)
> >
^ permalink raw reply
* Patch "serial: sh-sci: Stop using printk format %pCr" has been added to the 4.9-stable tree
From: gregkh at linuxfoundation.org @ 2018-06-14 9:50 UTC (permalink / raw)
To: linux-arm-kernel
This is a note to let you know that I've just added the patch titled
serial: sh-sci: Stop using printk format %pCr
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
serial-sh-sci-stop-using-printk-format-pcr.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From d63c16f8e1ab761775275adcf54f4bef7c330295 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Fri, 1 Jun 2018 11:28:21 +0200
Subject: serial: sh-sci: Stop using printk format %pCr
From: Geert Uytterhoeven <geert+renesas@glider.be>
commit d63c16f8e1ab761775275adcf54f4bef7c330295 upstream.
Printk format "%pCr" will be removed soon, as clk_get_rate() must not be
called in atomic context.
Replace it by open-coding the operation. This is safe here, as the code
runs in task context.
Link: http://lkml.kernel.org/r/1527845302-12159-4-git-send-email-geert+renesas at glider.be
To: Jia-Ju Bai <baijiaju1990@gmail.com>
To: Jonathan Corbet <corbet@lwn.net>
To: Michael Turquette <mturquette@baylibre.com>
To: Stephen Boyd <sboyd@kernel.org>
To: Zhang Rui <rui.zhang@intel.com>
To: Eduardo Valentin <edubezval@gmail.com>
To: Eric Anholt <eric@anholt.net>
To: Stefan Wahren <stefan.wahren@i2se.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-doc at vger.kernel.org
Cc: linux-clk at vger.kernel.org
Cc: linux-pm at vger.kernel.org
Cc: linux-serial at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-renesas-soc at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: stable at vger.kernel.org # 4.5+
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/serial/sh-sci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2626,8 +2626,8 @@ found:
dev_dbg(dev, "failed to get %s (%ld)\n", clk_names[i],
PTR_ERR(clk));
else
- dev_dbg(dev, "clk %s is %pC rate %pCr\n", clk_names[i],
- clk, clk);
+ dev_dbg(dev, "clk %s is %pC rate %lu\n", clk_names[i],
+ clk, clk_get_rate(clk));
sci_port->clks[i] = IS_ERR(clk) ? NULL : clk;
}
return 0;
Patches currently in stable-queue which might be from geert+renesas at glider.be are
queue-4.9/serial-sh-sci-stop-using-printk-format-pcr.patch
^ permalink raw reply
* [PATCH 2/4] arm: dts: add support for Laird WB50N cpu module and DVK
From: Alexandre Belloni @ 2018-06-14 9:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528966340-23216-2-git-send-email-ben.whitten@lairdtech.com>
On 14/06/2018 09:51:55+0100, Ben Whitten wrote:
> Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
> ---
> arch/arm/boot/dts/Makefile | 3 +-
> arch/arm/boot/dts/at91-wb50n.dts | 116 ++++++++++++++++++++++
> arch/arm/boot/dts/at91-wb50n.dtsi | 202 ++++++++++++++++++++++++++++++++++++++
> 3 files changed, 320 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/at91-wb50n.dts
> create mode 100644 arch/arm/boot/dts/at91-wb50n.dtsi
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 1ee94ee..fd5f8a6 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -61,7 +61,8 @@ dtb-$(CONFIG_SOC_SAM_V7) += \
> at91-sama5d4_ma5d4evk.dtb \
> at91-sama5d4_xplained.dtb \
> at91-sama5d4ek.dtb \
> - at91-vinco.dtb
> + at91-vinco.dtb \
> + at91-wb50n.dtb
I know we have been bad at this but this should be
at91-<soc>-<board>.dtb so at91-sama5d31-wb50n.dtb
> dtb-$(CONFIG_ARCH_ATLAS6) += \
> atlas6-evb.dtb
> dtb-$(CONFIG_ARCH_ATLAS7) += \
> diff --git a/arch/arm/boot/dts/at91-wb50n.dts b/arch/arm/boot/dts/at91-wb50n.dts
> new file mode 100644
> index 0000000..ee4f823
> --- /dev/null
> +++ b/arch/arm/boot/dts/at91-wb50n.dts
> @@ -0,0 +1,116 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * at91-wb50n.dts - Device Tree file for wb50n evaluation board
> + *
> + * Copyright (C) 2018 Laird
> + *
> + */
> +
> +/dts-v1/;
> +#include "at91-wb50n.dtsi"
> +
> +/ {
> + model = "Laird Workgroup Bridge 50N - Atmel SAMA5D";
> + compatible = "laird,wb50n", "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
> +
> + ahb {
> + apb {
> + watchdog at fffffe40 {
I don't mind if you want to have a preparation patch adding the
necessary labels in the soc dtsi so you don't have to reproduce the
ahb/apb hierarchy here.
> + ahb {
> + apb {
> + pinctrl at fffff200 {
Ditto
> + board {
> + pinctrl_mmc0_cd: mmc0_cd {
> + atmel,pins = <AT91_PIOC 26 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>; /* PC26 GPIO with pullup deglitch */
> + };
> +
> + pinctrl_usba_vbus: usba_vbus {
> + atmel,pins = <AT91_PIOB 13 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* PB13 GPIO with deglitch */
> + };
> + };
> + };
> + };
> + };
> +};
> +
> +&slow_osc {
> + atmel,osc-bypass;
> +};
After the clock binding rework, this will have to be moved to the pmc
node (the rework is not posted, this is just to remind me that this will
have to be done).
> +
> +&usart1_clk {
> + atmel,clk-output-range = <0 132000000>;
> +};
The datasheet explicitly states that 66 MHz is the maximum allowed
frequency for the USART. Note that the new binding will not allow you to
do that.
However, I see the table disappeared from the latest datasheet. Maybe
Nicolas can comment on that?
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Patch "serial: sh-sci: Stop using printk format %pCr" has been added to the 4.17-stable tree
From: gregkh at linuxfoundation.org @ 2018-06-14 9:50 UTC (permalink / raw)
To: linux-arm-kernel
This is a note to let you know that I've just added the patch titled
serial: sh-sci: Stop using printk format %pCr
to the 4.17-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
serial-sh-sci-stop-using-printk-format-pcr.patch
and it can be found in the queue-4.17 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From d63c16f8e1ab761775275adcf54f4bef7c330295 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Fri, 1 Jun 2018 11:28:21 +0200
Subject: serial: sh-sci: Stop using printk format %pCr
From: Geert Uytterhoeven <geert+renesas@glider.be>
commit d63c16f8e1ab761775275adcf54f4bef7c330295 upstream.
Printk format "%pCr" will be removed soon, as clk_get_rate() must not be
called in atomic context.
Replace it by open-coding the operation. This is safe here, as the code
runs in task context.
Link: http://lkml.kernel.org/r/1527845302-12159-4-git-send-email-geert+renesas at glider.be
To: Jia-Ju Bai <baijiaju1990@gmail.com>
To: Jonathan Corbet <corbet@lwn.net>
To: Michael Turquette <mturquette@baylibre.com>
To: Stephen Boyd <sboyd@kernel.org>
To: Zhang Rui <rui.zhang@intel.com>
To: Eduardo Valentin <edubezval@gmail.com>
To: Eric Anholt <eric@anholt.net>
To: Stefan Wahren <stefan.wahren@i2se.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-doc at vger.kernel.org
Cc: linux-clk at vger.kernel.org
Cc: linux-pm at vger.kernel.org
Cc: linux-serial at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-renesas-soc at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: stable at vger.kernel.org # 4.5+
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/serial/sh-sci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2704,8 +2704,8 @@ found:
dev_dbg(dev, "failed to get %s (%ld)\n", clk_names[i],
PTR_ERR(clk));
else
- dev_dbg(dev, "clk %s is %pC rate %pCr\n", clk_names[i],
- clk, clk);
+ dev_dbg(dev, "clk %s is %pC rate %lu\n", clk_names[i],
+ clk, clk_get_rate(clk));
sci_port->clks[i] = IS_ERR(clk) ? NULL : clk;
}
return 0;
Patches currently in stable-queue which might be from geert+renesas at glider.be are
queue-4.17/serial-sh-sci-stop-using-printk-format-pcr.patch
^ permalink raw reply
* Patch "serial: sh-sci: Stop using printk format %pCr" has been added to the 4.16-stable tree
From: gregkh at linuxfoundation.org @ 2018-06-14 9:49 UTC (permalink / raw)
To: linux-arm-kernel
This is a note to let you know that I've just added the patch titled
serial: sh-sci: Stop using printk format %pCr
to the 4.16-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
serial-sh-sci-stop-using-printk-format-pcr.patch
and it can be found in the queue-4.16 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From d63c16f8e1ab761775275adcf54f4bef7c330295 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Fri, 1 Jun 2018 11:28:21 +0200
Subject: serial: sh-sci: Stop using printk format %pCr
From: Geert Uytterhoeven <geert+renesas@glider.be>
commit d63c16f8e1ab761775275adcf54f4bef7c330295 upstream.
Printk format "%pCr" will be removed soon, as clk_get_rate() must not be
called in atomic context.
Replace it by open-coding the operation. This is safe here, as the code
runs in task context.
Link: http://lkml.kernel.org/r/1527845302-12159-4-git-send-email-geert+renesas at glider.be
To: Jia-Ju Bai <baijiaju1990@gmail.com>
To: Jonathan Corbet <corbet@lwn.net>
To: Michael Turquette <mturquette@baylibre.com>
To: Stephen Boyd <sboyd@kernel.org>
To: Zhang Rui <rui.zhang@intel.com>
To: Eduardo Valentin <edubezval@gmail.com>
To: Eric Anholt <eric@anholt.net>
To: Stefan Wahren <stefan.wahren@i2se.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-doc at vger.kernel.org
Cc: linux-clk at vger.kernel.org
Cc: linux-pm at vger.kernel.org
Cc: linux-serial at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-renesas-soc at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: stable at vger.kernel.org # 4.5+
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/serial/sh-sci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2691,8 +2691,8 @@ found:
dev_dbg(dev, "failed to get %s (%ld)\n", clk_names[i],
PTR_ERR(clk));
else
- dev_dbg(dev, "clk %s is %pC rate %pCr\n", clk_names[i],
- clk, clk);
+ dev_dbg(dev, "clk %s is %pC rate %lu\n", clk_names[i],
+ clk, clk_get_rate(clk));
sci_port->clks[i] = IS_ERR(clk) ? NULL : clk;
}
return 0;
Patches currently in stable-queue which might be from geert+renesas at glider.be are
queue-4.16/serial-sh-sci-stop-using-printk-format-pcr.patch
^ permalink raw reply
* Patch "serial: sh-sci: Stop using printk format %pCr" has been added to the 4.14-stable tree
From: gregkh at linuxfoundation.org @ 2018-06-14 9:49 UTC (permalink / raw)
To: linux-arm-kernel
This is a note to let you know that I've just added the patch titled
serial: sh-sci: Stop using printk format %pCr
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
serial-sh-sci-stop-using-printk-format-pcr.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From d63c16f8e1ab761775275adcf54f4bef7c330295 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Fri, 1 Jun 2018 11:28:21 +0200
Subject: serial: sh-sci: Stop using printk format %pCr
From: Geert Uytterhoeven <geert+renesas@glider.be>
commit d63c16f8e1ab761775275adcf54f4bef7c330295 upstream.
Printk format "%pCr" will be removed soon, as clk_get_rate() must not be
called in atomic context.
Replace it by open-coding the operation. This is safe here, as the code
runs in task context.
Link: http://lkml.kernel.org/r/1527845302-12159-4-git-send-email-geert+renesas at glider.be
To: Jia-Ju Bai <baijiaju1990@gmail.com>
To: Jonathan Corbet <corbet@lwn.net>
To: Michael Turquette <mturquette@baylibre.com>
To: Stephen Boyd <sboyd@kernel.org>
To: Zhang Rui <rui.zhang@intel.com>
To: Eduardo Valentin <edubezval@gmail.com>
To: Eric Anholt <eric@anholt.net>
To: Stefan Wahren <stefan.wahren@i2se.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-doc at vger.kernel.org
Cc: linux-clk at vger.kernel.org
Cc: linux-pm at vger.kernel.org
Cc: linux-serial at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-renesas-soc at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: stable at vger.kernel.org # 4.5+
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/serial/sh-sci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2669,8 +2669,8 @@ found:
dev_dbg(dev, "failed to get %s (%ld)\n", clk_names[i],
PTR_ERR(clk));
else
- dev_dbg(dev, "clk %s is %pC rate %pCr\n", clk_names[i],
- clk, clk);
+ dev_dbg(dev, "clk %s is %pC rate %lu\n", clk_names[i],
+ clk, clk_get_rate(clk));
sci_port->clks[i] = IS_ERR(clk) ? NULL : clk;
}
return 0;
Patches currently in stable-queue which might be from geert+renesas at glider.be are
queue-4.14/serial-sh-sci-stop-using-printk-format-pcr.patch
^ permalink raw reply
* [PATCH v1] ARM: dts: imx6sx: fix irq for pcie bridge
From: Oleksij Rempel @ 2018-06-14 9:45 UTC (permalink / raw)
To: linux-arm-kernel
Without this patch MSI interrupts are not routed from Intel
i350 PCIe adapter.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
arch/arm/boot/dts/imx6sx.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 49c7205b8db8..77fdad65e2bb 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -1351,7 +1351,7 @@
ranges = <0x81000000 0 0 0x08f80000 0 0x00010000 /* downstream I/O */
0x82000000 0 0x08000000 0x08000000 0 0x00f00000>; /* non-prefetchable memory */
num-lanes = <1>;
- interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "msi";
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0x7>;
--
2.17.1
^ permalink raw reply related
* [PATCH v3 2/3] media: v4l2-ctrl: Add control for VP9 profile
From: Keiichi Watanabe @ 2018-06-14 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9cb304df-c600-918a-1c73-8daa9644f9c3@linaro.org>
Hi Stanimir,
On Thu, Jun 14, 2018 at 5:06 PM, Stanimir Varbanov
<stanimir.varbanov@linaro.org> wrote:
> Hi Keiichi,
>
> On 06/14/2018 10:46 AM, Keiichi Watanabe wrote:
>> Add a new control V4L2_CID_MPEG_VIDEO_VP9_PROFILE for VP9
>> profiles. This control allows to select a desired profile for VP9
>> encoder and query for supported profiles by VP9 encoder/decoder.
>>
>> Though this control is similar to V4L2_CID_MPEG_VIDEO_VP8_PROFILE, we need to
>> separate this control from it because supported profiles usually differ between
>> VP8 and VP9.
>>
>> Signed-off-by: Keiichi Watanabe <keiichiw@chromium.org>
>> ---
>> .../media/uapi/v4l/extended-controls.rst | 25 +++++++++++++++++++
>> drivers/media/v4l2-core/v4l2-ctrls.c | 11 ++++++++
>> include/uapi/linux/v4l2-controls.h | 7 ++++++
>> 3 files changed, 43 insertions(+)
>>
>> diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst
>> index de99eafb0872..095b42e9d6fe 100644
>> --- a/Documentation/media/uapi/v4l/extended-controls.rst
>> +++ b/Documentation/media/uapi/v4l/extended-controls.rst
>> @@ -1980,6 +1980,31 @@ enum v4l2_mpeg_video_vp8_profile -
>> * - ``V4L2_MPEG_VIDEO_VP8_PROFILE_3``
>> - Profile 3
>>
>> +.. _v4l2-mpeg-video-vp9-profile:
>> +
>> +``V4L2_CID_MPEG_VIDEO_VP9_PROFILE``
>> + (enum)
>> +
>> +enum v4l2_mpeg_video_vp9_profile -
>
> what about vp9 levels, shouldn't we add them too? Or we will add it when
> there is a user.
>
It sounds good, but I don't think we should include them in this
series of patches now.
As you said, we can add them when someone wants to use them.
Best regards,
Keiichi
>
> --
> regards,
> Stan
^ permalink raw reply
* [PATCH 1/4] arm: dts: add support for Laird WB45N cpu module and DVK
From: Alexandre Belloni @ 2018-06-14 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528966340-23216-1-git-send-email-ben.whitten@lairdtech.com>
Hi,
On 14/06/2018 09:51:54+0100, Ben Whitten wrote:
This need a proper commit message. Maybe you can also add a link to the
technical brief for the platform?
> Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
> ---
> arch/arm/boot/dts/Makefile | 3 +-
> arch/arm/boot/dts/at91-wb45n.dts | 66 +++++++++++++++
> arch/arm/boot/dts/at91-wb45n.dtsi | 169 ++++++++++++++++++++++++++++++++++++++
> 3 files changed, 237 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/at91-wb45n.dts
> create mode 100644 arch/arm/boot/dts/at91-wb45n.dtsi
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 7e24249..1ee94ee 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -42,7 +42,8 @@ dtb-$(CONFIG_SOC_AT91SAM9) += \
> at91sam9g25ek.dtb \
> at91sam9g35ek.dtb \
> at91sam9x25ek.dtb \
> - at91sam9x35ek.dtb
> + at91sam9x35ek.dtb \
> + at91-wb45n.dtb
The proper name for the file is <soc>-board.dtb so this should be
at91sam9g25-wb45n.dtb.
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH] PCI: xilinx-nwl: add missing of_node_put()
From: Nicholas Mc Guire @ 2018-06-14 9:04 UTC (permalink / raw)
To: linux-arm-kernel
The call to of_get_next_child() returns a node pointer with
refcount incremented thus it must be explicitly decremented
here after the last usage.
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Fixes: commit ab597d35ef11 ("PCI: xilinx-nwl: Add support for Xilinx NWL PCIe Host Controller")
---
Problem found by an experimental cocinelle script
Patch was compile tested with: multi_v7_defconfig + ARCH_ZYNQ=y,
COMPILE_TEST=y, PCIE_XILINX_NWL=y
(one sparse warning though not related to the change proposed though)
Patch is against 4.17.0 (localversion-next is next-20180613)
drivers/pci/controller/pcie-xilinx-nwl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/controller/pcie-xilinx-nwl.c b/drivers/pci/controller/pcie-xilinx-nwl.c
index 6a4bbb5..fb32840 100644
--- a/drivers/pci/controller/pcie-xilinx-nwl.c
+++ b/drivers/pci/controller/pcie-xilinx-nwl.c
@@ -559,7 +559,7 @@ static int nwl_pcie_init_irq_domain(struct nwl_pcie *pcie)
PCI_NUM_INTX,
&legacy_domain_ops,
pcie);
-
+ of_node_put(legacy_intc_node);
if (!pcie->legacy_irq_domain) {
dev_err(dev, "failed to create IRQ domain\n");
return -ENOMEM;
--
2.1.4
^ permalink raw reply related
* [PATCH 2/4] ARM: dts: Modernize the Vexpress PL111 integration
From: Liviu Dudau @ 2018-06-14 9:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f371ef92-1876-5fa2-a62a-14a7f4e19ded@arm.com>
On Wed, Jun 13, 2018 at 11:57:25AM +0100, Sudeep Holla wrote:
> Hi Linus,
>
> I was planning to apply this and observed few things.
>
> On 28/05/18 13:26, Linus Walleij wrote:
> > The Versatile Express was submitted with the actual display
> > bridges unconnected (but defined in the device tree) and
> > mock "panels" encoded in the device tree node of the PL111
> > controller.
> >
> > This doesn't even remotely describe the actual Versatile
> > Express hardware. Exploit the SiI9022 bridge by connecting
> > the PL111 pads to it, making it use EDID or fallback values
> > to drive the monitor.
> >
> > The also has to use the reserved memory through the
> > CMA pool rather than by open coding a memory region and
> > remapping it explicitly in the driver. To achieve this,
> > a reserved-memory node must exist in the root of the
> > device tree, so we need to pull that out of the
> > motherboard .dtsi include files, and push it into each
> > top-level device tree instead.
> >
> > We do the same manouver for all the Versatile Express
> > boards, taking into account the different location of the
> > video RAM depending on which chip select is used on
> > each platform.
> >
> > This plays nicely with the new PL111 DRM driver and
> > follows the standard ways of assigning bridges and
> > memory pools for graphics.
> >
> > Cc: Sudeep Holla <sudeep.holla@arm.com>
> > Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Cc: Liviu Dudau <liviu.dudau@arm.com>
> > Cc: Mali DP Maintainers <malidp@foss.arm.com>
> > Cc: Robin Murphy <robin.murphy@arm.com>
> > Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> > ---
> > ChangeLog v1->v2:
> > - Fix up the memory address for the -rs1 tiles to 0x18000000
> > - Drop a bunch of extraneous reg props from the DVI adapter
> > ---
> > arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 44 ++++++------------
> > arch/arm/boot/dts/vexpress-v2m.dtsi | 45 ++++++-------------
> > arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 14 ++++++
> > arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 14 ++++++
> > arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 14 ++++++
> > arch/arm/boot/dts/vexpress-v2p-ca9.dts | 41 +++++++----------
> > arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts | 14 ++++++
> > .../boot/dts/arm/rtsm_ve-motherboard.dtsi | 37 +++------------
> > 8 files changed, 105 insertions(+), 118 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> > index 7b8ff5b3b912..69f6a9436325 100644
> > --- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> > +++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> > @@ -43,11 +43,6 @@
> > bank-width = <4>;
> > };
> >
> > - v2m_video_ram: vram at 2,00000000 {
> > - compatible = "arm,vexpress-vram";
> > - reg = <2 0x00000000 0x00800000>;
> > - };
> > -
> > ethernet at 2,02000000 {
> > compatible = "smsc,lan9118", "smsc,lan9115";
> > reg = <2 0x02000000 0x10000>;
> > @@ -224,6 +219,14 @@
> > dvi-transmitter at 39 {
> > compatible = "sil,sii9022-tpi", "sil,sii9022";
> > reg = <0x39>;
> > +
> > + ports {
> > + port at 0 {
>
>
> May need reg=<0> here, otherwise DTC might complain ?
> [...]
>
> > diff --git a/arch/arm/boot/dts/vexpress-v2m.dtsi b/arch/arm/boot/dts/vexpress-v2m.dtsi
> > index 9cd5e146abd5..067d84bc61c0 100644
> > --- a/arch/arm/boot/dts/vexpress-v2m.dtsi
> > +++ b/arch/arm/boot/dts/vexpress-v2m.dtsi
> > @@ -43,11 +43,6 @@
> > bank-width = <4>;
> > };
> >
> > - v2m_video_ram: vram at 3,00000000 {
> > - compatible = "arm,vexpress-vram";
> > - reg = <3 0x00000000 0x00800000>;
> > - };
> > -
> > ethernet at 3,02000000 {
> > compatible = "smsc,lan9118", "smsc,lan9115";
> > reg = <3 0x02000000 0x10000>;
> > @@ -224,6 +219,14 @@
> > dvi-transmitter at 39 {
> > compatible = "sil,sii9022-tpi", "sil,sii9022";
> > reg = <0x39>;
> > +
> > + ports {
> > + port at 0 {
>
> Ditto
>
> > + dvi_bridge_in: endpoint {
> > + remote-endpoint = <&clcd_pads>;
> > + };
> > + };
> > + };
> > };
> >
> > dvi-transmitter at 60 {
>
> [...]
>
> > diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
> > index 3971427a105b..0dc4277d5f8b 100644
> > --- a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
> > +++ b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
> > @@ -53,6 +53,20 @@
> > reg = <0 0x80000000 0 0x40000000>;
> > };
> >
> > + reserved-memory {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
> > +
> > + /* Chipselect 2 is physically at 0x18000000 */
> > + vram: vram at 18000000 {
> > + /* 8 MB of designated video RAM */
> > + compatible = "shared-dma-pool";
> > + reg = <0 0x18000000 0 0x00800000>;
> > + no-map;
> > + };
> > + };
> > +
>
> I need to think hard yet, but was hoping to keep these in the
> motherboard files itself if possible. I don't like the way we need
> to specify the absolute address here.
>
> > hdlcd at 2b000000 {
> > compatible = "arm,hdlcd";
> > reg = <0 0x2b000000 0 0x1000>;
>
>
> [...]
>
> > diff --git a/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi b/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
> > index 1134e5d8df18..737d0a0c0854 100644
> > --- a/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
> > +++ b/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
> > @@ -23,11 +23,6 @@
> > bank-width = <4>;
> > };
> >
> > - v2m_video_ram: vram at 2,00000000 {
> > - compatible = "arm,vexpress-vram";
> > - reg = <2 0x00000000 0x00800000>;
> > - };
> > -
> > ethernet at 2,02000000 {
> > compatible = "smsc,lan91c111";
> > reg = <2 0x02000000 0x10000>;
> > @@ -186,38 +181,16 @@
> > interrupts = <14>;
> > clocks = <&v2m_oscclk1>, <&v2m_clk24mhz>;
> > clock-names = "clcdclk", "apb_pclk";
> > - arm,pl11x,framebuffer = <0x18000000 0x00180000>;
> > - memory-region = <&v2m_video_ram>;
> > - max-memory-bandwidth = <130000000>; /* 16bpp @ 63.5MHz */
> > + /* 800x600 16bpp @36MHz works fine */
> > + max-memory-bandwidth = <54000000>;
> > + memory-region = <&vram>;
> >
> > port {
> > - v2m_clcd_pads: endpoint {
> > - remote-endpoint = <&v2m_clcd_panel>;
> > + clcd_pads: endpoint {
> > + remote-endpoint = <&dvi_bridge_in>;
>
> I can't find dvi_bridge_in for this RTSM/FVP model, also not sure if I2C
> or DVI transmitter is supported on them.
>
> Liviu, any idea ?
Models don't have any bridges or DVI transmitters, they use the
framebuffer address that gets programmed into the PL111 registers as the
address where they read from in order to render to screen. At least that
is what happens for HDLCD, I'm afraid I have limited knowledge about the
PL111 implementation in the model.
Best regards,
Liviu
>
> Also you my need to fix arm64 express-v2f-1xv7-ca53x2.dts as it includes
> vexpress-v2m-rs1.dtsi
>
> --
> Regards,
> Sudeep
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
?\_(?)_/?
^ permalink raw reply
* [PATCH v3 2/7] serdev: add dev_pm_domain_attach|detach()
From: Ulf Hansson @ 2018-06-14 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e338118bb6b9f560560887eb974eb250a6c89984.1528960095.git.sean.wang@mediatek.com>
On Thu, 14 Jun 2018 at 09:14, <sean.wang@mediatek.com> wrote:
>
> From: Sean Wang <sean.wang@mediatek.com>
>
> In order to open up the required power gate before any operation can be
> effectively performed over the serial bus between CPU and serdev, it's
> clearly essential to add common attach functions for PM domains to serdev
> at the probe phase.
>
> Similarly, the relevant dettach function for the PM domains should be
> properly and reversely added at the remove phase.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Jiri Slaby <jslaby@suse.com>
> Cc: linux-serial at vger.kernel.org
> ---
> drivers/tty/serdev/core.c | 14 +++++++++++++-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
> index df93b72..c93d8ee 100644
> --- a/drivers/tty/serdev/core.c
> +++ b/drivers/tty/serdev/core.c
> @@ -13,6 +13,7 @@
> #include <linux/module.h>
> #include <linux/of.h>
> #include <linux/of_device.h>
> +#include <linux/pm_domain.h>
> #include <linux/serdev.h>
> #include <linux/slab.h>
>
> @@ -330,8 +331,16 @@ EXPORT_SYMBOL_GPL(serdev_device_set_tiocm);
> static int serdev_drv_probe(struct device *dev)
> {
> const struct serdev_device_driver *sdrv = to_serdev_device_driver(dev->driver);
> + int ret;
> +
> + ret = dev_pm_domain_attach(dev, true);
> + if (ret != -EPROBE_DEFER) {
>From 4.18 rc1 via commit 919b7308fcc4, dev_pm_domain_attach() will
return better error codes.
I suggest to change the above error path to:
if (ret)
return ret;
Then continue with the probing below.
> + ret = sdrv->probe(to_serdev_device(dev));
> + if (ret)
> + dev_pm_domain_detach(dev, true);
> + }
>
> - return sdrv->probe(to_serdev_device(dev));
> + return ret;
> }
>
> static int serdev_drv_remove(struct device *dev)
> @@ -339,6 +348,9 @@ static int serdev_drv_remove(struct device *dev)
> const struct serdev_device_driver *sdrv = to_serdev_device_driver(dev->driver);
> if (sdrv->remove)
> sdrv->remove(to_serdev_device(dev));
> +
> + dev_pm_domain_detach(dev, true);
> +
> return 0;
> }
>
> --
> 2.7.4
>
Otherwise, this makes sense to me!
Kind regards
Uffe
^ permalink raw reply
* [PATCH] pinctrl: mt7622: fix a kernel panic when pio don't work as EINT controller
From: sean.wang at mediatek.com @ 2018-06-14 8:55 UTC (permalink / raw)
To: linux-arm-kernel
From: Sean Wang <sean.wang@mediatek.com>
The function, external interrupt controller, is made as an optional to
mt7622 pinctrl. But if we don't want pio behaves as an external interrupt
controller, it would lead to hw->eint not be created properly and then
will cause 'kernel NULL pointer' issue when gpiochip try to call .to_irq
or .set_config. To fix it, check hw->eint before accessing the member.
[ 1.339494] Unable to handle kernel NULL pointer dereference at virtual
address 00000010
[ 1.347857] Mem abort info:
[ 1.350742] ESR = 0x96000005
[ 1.353905] Exception class = DABT (current EL), IL = 32 bits
[ 1.360024] SET = 0, FnV = 0
[ 1.363185] EA = 0, S1PTW = 0
[ 1.366431] Data abort info:
[ 1.369405] ISV = 0, ISS = 0x00000005
[ 1.373363] CM = 0, WnR = 0
[ 1.376437] [0000000000000010] user address but active_mm is swapper
[ 1.383005] Internal error: Oops: 96000005 [#1] PREEMPT SMP
[ 1.388748] Modules linked in:
[ 1.391897] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.16.0-rc1+ #344
[ 1.398625] Hardware name: MediaTek MT7622 RFB1 board (DT)
[ 1.404279] pstate: 80000005 (Nzcv daif -PAN -UAO)
[ 1.409221] pc : mtk_eint_find_irq+0x8/0x24
[ 1.413532] lr : mtk_gpio_to_irq+0x20/0x28
[ 1.417749] sp : ffffff800801baf0
[ 1.421161] x29: ffffff800801baf0 x28: ffffff8008792f40
[ 1.426637] x27: ffffff800886b000 x26: ffffff8008615620
[ 1.432113] x25: ffffffc00e4dbdc8 x24: ffffff80087b8000
[ 1.437589] x23: ffffffc00325a000 x22: ffffffc00325a010
[ 1.443066] x21: ffffffc0033dec18 x20: 00000000ffffffea
[ 1.448542] x19: ffffffc00e4db800 x18: 0000000000000130
[ 1.454018] x17: 000000000000000e x16: 0000000000000007
[ 1.459494] x15: ffffff80085ee000 x14: 0000000000000001
[ 1.464970] x13: 0000000000000001 x12: 0000000000000010
[ 1.470446] x11: 0101010101010101 x10: 0000000000000880
[ 1.475922] x9 : ffffff800801b990 x8 : ffffffc0030688e0
[ 1.481399] x7 : ffffff80080c0660 x6 : ffffffc00e4dbbb0
[ 1.486875] x5 : 0000000000000000 x4 : 0000000000000000
[ 1.492351] x3 : ffffff80082a92f4 x2 : 00000000fffffffa
[ 1.497826] x1 : 0000000000000051 x0 : 0000000000000000
[ 1.503305] Process swapper/0 (pid: 1, stack limit = 0x0000000054e053bd)
[ 1.510210] Call trace:
[ 1.512727] mtk_eint_find_irq+0x8/0x24
[ 1.516677] mtk_gpio_to_irq+0x20/0x28
[ 1.520539] gpiod_to_irq+0x48/0x60
[ 1.524135] mmc_gpiod_request_cd_irq+0x3c/0xc4
[ 1.528804] mmc_start_host+0x6c/0x8c
[ 1.532575] mmc_add_host+0x58/0x7c
[ 1.536168] msdc_drv_probe+0x4fc/0x67c
[ 1.540121] platform_drv_probe+0x58/0xa4
[ 1.544251] driver_probe_device+0x204/0x44c
[ 1.548649] __driver_attach+0x84/0xf8
[ 1.552512] bus_for_each_dev+0x68/0xa0
[ 1.556461] driver_attach+0x20/0x28
[ 1.560142] bus_add_driver+0xec/0x240
[ 1.564002] driver_register+0x98/0xe4
[ 1.567863] __platform_driver_register+0x48/0x50
[ 1.572711] mt_msdc_driver_init+0x18/0x20
[ 1.576932] do_one_initcall+0x98/0x130
[ 1.580886] kernel_init_freeable+0x13c/0x1d4
[ 1.585375] kernel_init+0x10/0xf8
[ 1.588879] ret_from_fork+0x10/0x18
[ 1.592564] Code: a8c67bfd d65f03c0 a9bf7bfd 910003fd (f9400800)
[ 1.598849] ---[ end trace 4bbcb7bc30e98492 ]---
[ 1.603677] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
[ 1.603677]
cc: Kevin Hilman <khilman@baylibre.com>
Cc: stable at vger.kernel.org
Fixes: e6dabd38d8e7 ("pinctrl: mediatek: add EINT support to MT7622 SoC")
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
drivers/pinctrl/mediatek/pinctrl-mt7622.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt7622.c b/drivers/pinctrl/mediatek/pinctrl-mt7622.c
index ad6da11..e3f1ab2 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt7622.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt7622.c
@@ -1459,6 +1459,9 @@ static int mtk_gpio_to_irq(struct gpio_chip *chip, unsigned int offset)
struct mtk_pinctrl *hw = gpiochip_get_data(chip);
unsigned long eint_n;
+ if (!hw->eint)
+ return -ENOTSUPP;
+
eint_n = offset;
return mtk_eint_find_irq(hw->eint, eint_n);
@@ -1471,7 +1474,8 @@ static int mtk_gpio_set_config(struct gpio_chip *chip, unsigned int offset,
unsigned long eint_n;
u32 debounce;
- if (pinconf_to_config_param(config) != PIN_CONFIG_INPUT_DEBOUNCE)
+ if (!hw->eint ||
+ pinconf_to_config_param(config) != PIN_CONFIG_INPUT_DEBOUNCE)
return -ENOTSUPP;
debounce = pinconf_to_config_argument(config);
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 6/8] dts: coresight: Clean up the device tree graph bindings
From: Suzuki K Poulose @ 2018-06-14 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <HE1PR0802MB24121F0EEF8D7D643BC391A1EE7E0@HE1PR0802MB2412.eurprd08.prod.outlook.com>
On 13/06/18 22:07, Matt Sealey wrote:
>
>
>> -----Original Message-----
>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>>
>>> So, if the suggestion is to use an existing property "unit", I am fine
>>> with it, if people agree to it.
>>
>> If we're going to have something sharply different than ACPI I prefer
>> Rob's idea.
No, the above comment is about using "unit" ( if it is a standard property
for specifying something specific to hardware) instead of "coresight,hwid".
I would prefer to stick to the DT graph bindings, because :
1) The connections are bi-directional => Well, not necessarily bi-directional
in terms of the data flow. But the connection information is critical. i.e,
we need information about both the end-points of a connection, which the DT
graph bindings solves.
All we are missing is a way for specifying the "hardware port" number and the
direction of flow. I don't see why do we need to create something new just for
these two properties for something that exists today and works reasonably well
for the usecase.
>
> What are you trying to say about being sharply different than ACPI?
The proposed Coresight ACPI draft bindings are based on the ACPI Graph bindings
(just like the DT graph bindings and is compatible with it, in terms of the APIs.
i.e, fwnode_graph_* operations work for both ACPI and DT alike).
So, what Mathieu, in turn means is, if we depart from the DT Graph bindings, which
I personally don't see any benefit in.
Suzuki
^ permalink raw reply
* [PATCH v4 0/7] add virt-dma support for imx-sdma
From: Lucas Stach @ 2018-06-14 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528984982-5074-1-git-send-email-yibin.gong@nxp.com>
Hi Robin,
I just gave this series a spin and it seems there is even more locking
fun, see the lockdep output below. After taking a short look it seems
this is caused by using the wrong spinlock variants in
sdma_int_handler(), those should also use the _irqsave ones. When
fixing this you might want to reconsider patch 7/7, as it's probably
not needed at all.
Regards,
Lucas
[ 20.479401] ========================================================
[ 20.485769] WARNING: possible irq lock inversion dependency detected
[ 20.492140] 4.17.0+ #1538 Not tainted
[ 20.495814] --------------------------------------------------------
[ 20.502181] systemd/1 just changed the state of lock:
[ 20.507247] c0abdafc (&(&substream->self_group.lock)->rlock){-...}, at: snd_pcm_stream_lock+0x54/0x60
[ 20.516523] but this lock took another, HARDIRQ-unsafe lock in the past:
[ 20.523234] (fs_reclaim){+.+.}
[ 20.523253]
[ 20.523253]
[ 20.523253] and interrupts could create inverse lock ordering between them.
[ 20.523253]
[ 20.537804]
[ 20.537804] other info that might help us debug this:
[ 20.544344] Possible interrupt unsafe locking scenario:
[ 20.544344]
[ 20.551144] CPU0 CPU1
[ 20.555686] ---- ----
[ 20.560224] lock(fs_reclaim);
[ 20.563386] local_irq_disable();
[ 20.569315] lock(&(&substream->self_group.lock)->rlock);
[ 20.577337] lock(fs_reclaim);
[ 20.583014] <Interrupt>
[ 20.585643] lock(&(&substream->self_group.lock)->rlock);
[ 20.591322]
[ 20.591322] *** DEADLOCK ***
[ 20.591322]
[ 20.597260] 1 lock held by systemd/1:
[ 20.607806] #0: ab23d11c (snd_pcm_link_rwlock){.-..}, at: snd_pcm_stream_lock+0x4c/0x60
[ 20.615951]
[ 20.615951] the shortest dependencies between 2nd lock and 1st lock:
[ 20.623799] -> (fs_reclaim){+.+.} ops: 248474 {
[ 20.628456] HARDIRQ-ON-W at:
[ 20.631716] lock_acquire+0x260/0x29c
[ 20.637223] fs_reclaim_acquire+0x48/0x58
[ 20.643075] kmem_cache_alloc_trace+0x3c/0x364
[ 20.649366] alloc_worker.constprop.15+0x28/0x64
[ 20.655824] init_rescuer.part.5+0x20/0xa4
[ 20.661764] workqueue_init+0x124/0x1f8
[ 20.667446] kernel_init_freeable+0x60/0x550
[ 20.673561] kernel_init+0x18/0x120
[ 20.678890] ret_from_fork+0x14/0x20
[ 20.684299] (null)
[ 20.688408] SOFTIRQ-ON-W at:
[ 20.691659] lock_acquire+0x260/0x29c
[ 20.697158] fs_reclaim_acquire+0x48/0x58
[ 20.703006] kmem_cache_alloc_trace+0x3c/0x364
[ 20.709288] alloc_worker.constprop.15+0x28/0x64
[ 20.709301] init_rescuer.part.5+0x20/0xa4
[ 20.720717] workqueue_init+0x124/0x1f8
[ 20.720729] kernel_init_freeable+0x60/0x550
[ 20.720738] kernel_init+0x18/0x120
[ 20.720746] ret_from_fork+0x14/0x20
[ 20.720751] (null)
[ 20.720756] INITIAL USE at:
[ 20.720770] lock_acquire+0x260/0x29c
[ 20.720782] fs_reclaim_acquire+0x48/0x58
[ 20.774374] kmem_cache_alloc_trace+0x3c/0x364
[ 20.780574] alloc_worker.constprop.15+0x28/0x64
[ 20.786945] init_rescuer.part.5+0x20/0xa4
[ 20.792794] workqueue_init+0x124/0x1f8
[ 20.798384] kernel_init_freeable+0x60/0x550
[ 20.804406] kernel_init+0x18/0x120
[ 20.809648] ret_from_fork+0x14/0x20
[ 20.814971] (null)
[ 20.818992] }
[ 20.820768] ... key at: [<80e22074>] __fs_reclaim_map+0x0/0x10
[ 20.827220] ... acquired at:
[ 20.830289] fs_reclaim_acquire+0x48/0x58
[ 20.834487] kmem_cache_alloc_trace+0x3c/0x364
[ 20.839123] sdma_transfer_init+0x44/0x130
[ 20.843409] sdma_prep_dma_cyclic+0x78/0x21c
[ 20.847869] snd_dmaengine_pcm_trigger+0xdc/0x184
[ 20.852764] soc_pcm_trigger+0x164/0x190
[ 20.856876] snd_pcm_do_start+0x34/0x40
[ 20.860902] snd_pcm_action_single+0x48/0x74
[ 20.865360] snd_pcm_action+0x34/0xfc
[ 20.869213] snd_pcm_ioctl+0x910/0x10ec
[ 20.873241] vfs_ioctl+0x30/0x44
[ 20.876657] do_vfs_ioctl+0xac/0x974
[ 20.880421] ksys_ioctl+0x48/0x64
[ 20.883923] sys_ioctl+0x18/0x1c
[ 20.887340] ret_fast_syscall+0x0/0x28
[ 20.891277] 0x7289bcbc
[ 20.893909]
[ 20.895410] -> (&(&substream->self_group.lock)->rlock){-...} ops: 59 {
[ 20.901977] IN-HARDIRQ-W at:
[ 20.905143] lock_acquire+0x260/0x29c
[ 20.910473] _raw_spin_lock+0x48/0x58
[ 20.915801] snd_pcm_stream_lock+0x54/0x60
[ 20.921561] _snd_pcm_stream_lock_irqsave+0x40/0x48
[ 20.928107] snd_pcm_period_elapsed+0x2c/0xa4
[ 20.934127] dmaengine_pcm_dma_complete+0x54/0x58
[ 20.940498] sdma_int_handler+0x1dc/0x2a8
[ 20.946179] __handle_irq_event_percpu+0x1fc/0x498
[ 20.952635] handle_irq_event_percpu+0x38/0x8c
[ 20.958742] handle_irq_event+0x48/0x6c
[ 20.964242] handle_fasteoi_irq+0xc4/0x138
[ 20.970006] generic_handle_irq+0x28/0x38
[ 20.975681] __handle_domain_irq+0xb0/0xc4
[ 20.981443] gic_handle_irq+0x68/0xa0
[ 20.986769] __irq_svc+0x70/0xb0
[ 20.991662] _raw_spin_unlock_irq+0x38/0x6c
[ 20.997511] task_work_run+0x90/0xb8
[ 21.002751] do_work_pending+0xc8/0xd0
[ 21.008164] slow_work_pending+0xc/0x20
[ 21.013661] 0x76c77e86
[ 21.017768] INITIAL USE at:
[ 21.020844] lock_acquire+0x260/0x29c
[ 21.026086] _raw_spin_lock+0x48/0x58
[ 21.031328] snd_pcm_stream_lock+0x54/0x60
[ 21.037002] snd_pcm_stream_lock_irq+0x38/0x3c
[ 21.043023] snd_pcm_sync_ptr+0x214/0x260
[ 21.048609] snd_pcm_ioctl+0xbe0/0x10ec
[ 21.054027] vfs_ioctl+0x30/0x44
[ 21.058832] do_vfs_ioctl+0xac/0x974
[ 21.063984] ksys_ioctl+0x48/0x64
[ 21.068875] sys_ioctl+0x18/0x1c
[ 21.073679] ret_fast_syscall+0x0/0x28
[ 21.079004] 0x7e9026dc
[ 21.083023] }
[ 21.084710] ... key at: [<8162a6e4>] __key.31798+0x0/0x8
[ 21.090552] ... acquired at:
[ 21.093537] mark_lock+0x3a4/0x69c
[ 21.097128] __lock_acquire+0x420/0x16d4
[ 21.101239] lock_acquire+0x260/0x29c
[ 21.105091] _raw_spin_lock+0x48/0x58
[ 21.108940] snd_pcm_stream_lock+0x54/0x60
[ 21.113226] _snd_pcm_stream_lock_irqsave+0x40/0x48
[ 21.118296] snd_pcm_period_elapsed+0x2c/0xa4
[ 21.122841] dmaengine_pcm_dma_complete+0x54/0x58
[ 21.127735] sdma_int_handler+0x1dc/0x2a8
[ 21.131937] __handle_irq_event_percpu+0x1fc/0x498
[ 21.136915] handle_irq_event_percpu+0x38/0x8c
[ 21.141547] handle_irq_event+0x48/0x6c
[ 21.145570] handle_fasteoi_irq+0xc4/0x138
[ 21.149854] generic_handle_irq+0x28/0x38
[ 21.154052] __handle_domain_irq+0xb0/0xc4
[ 21.158335] gic_handle_irq+0x68/0xa0
[ 21.162184] __irq_svc+0x70/0xb0
[ 21.165601] _raw_spin_unlock_irq+0x38/0x6c
[ 21.169973] task_work_run+0x90/0xb8
[ 21.173735] do_work_pending+0xc8/0xd0
[ 21.177670] slow_work_pending+0xc/0x20
[ 21.181691] 0x76c77e86
[ 21.184320]
[ 21.185821]
[ 21.185821] stack backtrace:
[ 21.190198] CPU: 0 PID: 1 Comm: systemd Not tainted 4.17.0+ #1538
[ 21.196303] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 21.202841] Backtrace:
[ 21.205314] [<8010e318>] (dump_backtrace) from [<8010e604>] (show_stack+0x20/0x24)
[ 21.212900] r7:80e9f3d0 r6:00000000 r5:60070193 r4:80e9f3d0
[ 21.218581] [<8010e5e4>] (show_stack) from [<8099b660>] (dump_stack+0xa4/0xd8)
[ 21.225825] [<8099b5bc>] (dump_stack) from [<8017b52c>] (print_irq_inversion_bug+0x15c/0x1fc)
[ 21.234368] r9:814da818 r8:00000001 r7:ee926c00 r6:00000000 r5:ee915bb0 r4:814da818
[ 21.242133] [<8017b3d0>] (print_irq_inversion_bug) from [<8017b6dc>] (check_usage_forwards+0x110/0x13c)
[ 21.251544] r9:00000002 r8:80bfd3e2 r7:ee926c00 r6:ee927148 r5:80e08488 r4:00000001
[ 21.259306] [<8017b5cc>] (check_usage_forwards) from [<8017c2a4>] (mark_lock+0x3a4/0x69c)
[ 21.267500] r9:ee926c00 r8:80a03cd8 r7:00000101 r6:00000002 r5:00000000 r4:ee927148
[ 21.275263] [<8017bf00>] (mark_lock) from [<8017cf68>] (__lock_acquire+0x420/0x16d4)
[ 21.283023] r10:ee927148 r9:ed4620e4 r8:ee926c00 r7:00000000 r6:00000001 r5:00000001
[ 21.290863] r4:00000490
[ 21.293416] [<8017cb48>] (__lock_acquire) from [<8017ed58>] (lock_acquire+0x260/0x29c)
[ 21.301350] r10:00000001 r9:80e084a4 r8:00000000 r7:00000000 r6:00000000 r5:ed4620e4
[ 21.309189] r4:00000000
[ 21.311746] [<8017eaf8>] (lock_acquire) from [<809b74f0>] (_raw_spin_lock+0x48/0x58)
[ 21.319506] r10:ee0a4714 r9:ed457100 r8:ee0a46c8 r7:ee0a4714 r6:ee0a4010 r5:807847b0
[ 21.327346] r4:ed4620d4
[ 21.329902] [<809b74a8>] (_raw_spin_lock) from [<807847b0>] (snd_pcm_stream_lock+0x54/0x60)
[ 21.338265] r5:ed462000 r4:ed462000
[ 21.341863] [<8078475c>] (snd_pcm_stream_lock) from [<80784838>] (_snd_pcm_stream_lock_irqsave+0x40/0x48)
[ 21.351440] r5:ed462000 r4:60070193
[ 21.355042] [<807847f8>] (_snd_pcm_stream_lock_irqsave) from [<8078b044>] (snd_pcm_period_elapsed+0x2c/0xa4)
[ 21.364881] r5:ee3ef000 r4:ed462000
[ 21.368478] [<8078b018>] (snd_pcm_period_elapsed) from [<8078d7b4>] (dmaengine_pcm_dma_complete+0x54/0x58)
[ 21.378148] r7:ee0a4714 r6:ee0a4010 r5:00000007 r4:ee0a46bc
[ 21.383827] [<8078d760>] (dmaengine_pcm_dma_complete) from [<80504c0c>] (sdma_int_handler+0x1dc/0x2a8)
[ 21.393157] [<80504a30>] (sdma_int_handler) from [<8018cd28>] (__handle_irq_event_percpu+0x1fc/0x498)
[ 21.402393] r10:00000000 r9:eeafd400 r8:80e084a4 r7:00000038 r6:00000038 r5:80ea3c12
[ 21.410233] r4:ee2b5d40
[ 21.412787] [<8018cb2c>] (__handle_irq_event_percpu) from [<8018cffc>] (handle_irq_event_percpu+0x38/0x8c)
[ 21.422457] r10:00000000 r9:ee914000 r8:ee81d400 r7:00000038 r6:eeafd400 r5:eeafd464
[ 21.430296] r4:80e08488
[ 21.432852] [<8018cfc4>] (handle_irq_event_percpu) from [<8018d098>] (handle_irq_event+0x48/0x6c)
[ 21.441736] r6:eeafd464 r5:eeafd464 r4:eeafd400
[ 21.446374] [<8018d050>] (handle_irq_event) from [<8019146c>] (handle_fasteoi_irq+0xc4/0x138)
[ 21.454912] r7:00000038 r6:eeafd464 r5:80e10a60 r4:eeafd400
[ 21.460589] [<801913a8>] (handle_fasteoi_irq) from [<8018bd9c>] (generic_handle_irq+0x28/0x38)
[ 21.469214] r7:00000038 r6:80d92ae4 r5:00000000 r4:00000000
[ 21.474893] [<8018bd74>] (generic_handle_irq) from [<8018c48c>] (__handle_domain_irq+0xb0/0xc4)
[ 21.483611] [<8018c3dc>] (__handle_domain_irq) from [<80102330>] (gic_handle_irq+0x68/0xa0)
[ 21.491978] r9:ee914000 r8:f4001100 r7:80e5c6bc r6:ee915f00 r5:80e08c3c r4:f4000100
[ 21.499738] [<801022c8>] (gic_handle_irq) from [<801019f0>] (__irq_svc+0x70/0xb0)
[ 21.507233] Exception stack(0xee915f00 to 0xee915f48)
[ 21.512303] 5f00: 00000001 00000004 00000000 ee926c00 ee9270a8 ee926c00 ecc45e00 ee9270a8
[ 21.520498] 5f20: 80ec23b0 ee914000 00000000 ee915f64 ee915f20 ee915f50 8017c7c0 809b78ac
[ 21.528687] 5f40: 20070013 ffffffff
[ 21.532193] r9:ee914000 r8:80ec23b0 r7:ee915f34 r6:ffffffff r5:20070013 r4:809b78ac
[ 21.539959] [<809b7874>] (_raw_spin_unlock_irq) from [<8014e98c>] (task_work_run+0x90/0xb8)
[ 21.548321] r5:ee926c00 r4:ecc45e00
[ 21.551913] [<8014e8fc>] (task_work_run) from [<8010da3c>] (do_work_pending+0xc8/0xd0)
[ 21.559848] r9:ee914000 r8:801011c4 r7:ee915fb0 r6:ffffe000 r5:00000004 r4:801011c4
[ 21.567608] [<8010d974>] (do_work_pending) from [<80101034>] (slow_work_pending+0xc/0x20)
[ 21.575797] Exception stack(0xee915fb0 to 0xee915ff8)
[ 21.580864] 5fa0: 00000000 020c34e8 46059f00 00000000
[ 21.589059] 5fc0: 00000002 76f133a4 020df680 00000006 76e6e168 00000035 7ef81778 00000035
[ 21.597253] 5fe0: 00000006 7ef816a0 76c75d67 76c77e86 20070030 00000039
[ 21.603883] r7:00000006 r6:020df680 r5:76f133a4 r4:00000002
Am Donnerstag, den 14.06.2018, 22:02 +0800 schrieb Robin Gong:
> The legacy sdma driver has below limitations or drawbacks:
> ? 1. Hardcode the max BDs number as "PAGE_SIZE / sizeof(*)", and alloc
> ?????one page size for one channel regardless of only few BDs needed
> ?????most time. But in few cases, the max PAGE_SIZE maybe not enough.
> ? 2. One SDMA channel can't stop immediatley once channel disabled which
> ?????means SDMA interrupt may come in after this channel terminated.There
> ?????are some patches for this corner case such as commit "2746e2c389f9",
> ?????but not cover non-cyclic.
>
> The common virt-dma overcomes the above limitations. It can alloc bd
> dynamically and free bd once this tx transfer done. No memory wasted or
> maximum limititation here, only depends on how many memory can be requested
> from kernel. For No.2, such issue can be workaround by checking if there
> is available descript("sdmac->desc") now once the unwanted interrupt
> coming. At last the common virt-dma is easier for sdma driver maintain.
>
> Change from v3:
> ? 1. add two uart patches which impacted by this patchset.
> ? 2. unlock 'vc.lock' before cyclic dma callback and lock again after
> ?????it because some driver such as uart will call dmaengine_tx_status
> ?????which will acquire 'vc.lock' again and dead lock comes out.
> ? 3. remove 'Revert commit' stuff since that patch is not wrong and
> ?????combine two patch into one patch as Sascha's comment.
>
> Change from v2:
> ? 1. include Sascha's patch to make the main patch easier to review.
> ?????Thanks Sacha.
> ? 2. remove useless 'desc'/'chan' in struct sdma_channe.
>
> Change from v1:
> ? 1. split v1 patch into 5 patches.
> ? 2. remove some unnecessary condition check.
> ? 3. remove unnecessary 'pending' list.
>
> Robin Gong (6):
> ? tty: serial: imx: correct dma cookie status
> ? dmaengine: imx-sdma: add virt-dma support
> ? dmaengine: imx-sdma: remove useless 'lock' and 'enabled' in 'struct
> ????sdma_channel'
> ? dmaengine: imx-sdma: remove the maximum limitation for bd numbers
> ? dmaengine: imx-sdma: add sdma_transfer_init to decrease code overlap
> ? tty: serial: imx: split all dma setup operations out of 'port.lock'
> ????protector
>
> Sascha Hauer (1):
> ? dmaengine: imx-sdma: factor out a struct sdma_desc from struct
> ????sdma_channel
>
> ?drivers/dma/Kconfig??????|???1 +
> ?drivers/dma/imx-sdma.c???| 394 +++++++++++++++++++++++++++--------------------
> ?drivers/tty/serial/imx.c |??99 ++++++------
> ?3 files changed, 282 insertions(+), 212 deletions(-)
>
^ permalink raw reply
* [PATCH 4/4] arm: dts: add support for Laird SOM60 module and DVK boards
From: Ben Whitten @ 2018-06-14 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528966340-23216-1-git-send-email-ben.whitten@lairdtech.com>
Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/at91-dvk_som60.dts | 95 +++++++++++
arch/arm/boot/dts/at91-dvk_su60_somc.dtsi | 159 ++++++++++++++++++
arch/arm/boot/dts/at91-dvk_su60_somc_lcm.dtsi | 96 +++++++++++
arch/arm/boot/dts/at91-som60.dtsi | 229 ++++++++++++++++++++++++++
5 files changed, 581 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/at91-dvk_som60.dts
create mode 100644 arch/arm/boot/dts/at91-dvk_su60_somc.dtsi
create mode 100644 arch/arm/boot/dts/at91-dvk_su60_somc_lcm.dtsi
create mode 100644 arch/arm/boot/dts/at91-som60.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 486ab59..4d3d9ca 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -63,7 +63,8 @@ dtb-$(CONFIG_SOC_SAM_V7) += \
at91-sama5d4ek.dtb \
at91-vinco.dtb \
at91-wb50n.dtb \
- at91-gatwick.dtb
+ at91-gatwick.dtb \
+ at91-dvk_som60.dtb
dtb-$(CONFIG_ARCH_ATLAS6) += \
atlas6-evb.dtb
dtb-$(CONFIG_ARCH_ATLAS7) += \
diff --git a/arch/arm/boot/dts/at91-dvk_som60.dts b/arch/arm/boot/dts/at91-dvk_som60.dts
new file mode 100644
index 0000000..ededd5b
--- /dev/null
+++ b/arch/arm/boot/dts/at91-dvk_som60.dts
@@ -0,0 +1,95 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * at91-dvk_som60.dts - Device Tree file for the DVK SOM60 board
+ *
+ * Copyright (C) 2018 Laird,
+ * 2018 Ben Whitten <ben.whitten@lairdtech.com>
+ *
+ */
+/dts-v1/;
+#include "at91-som60.dtsi"
+#include "at91-dvk_su60_somc.dtsi"
+#include "at91-dvk_su60_somc_lcm.dtsi"
+
+/ {
+ model = "Laird DVK SOM60";
+ compatible = "laird,dvk-som60", "laird,som60", "atmel,sama5d36", "atmel,sama5d3", "atmel,sama5";
+
+ chosen {
+ stdout-path = &dbgu;
+ tick-timer = &pit;
+ };
+};
+
+&mmc0 {
+ status = "okay";
+};
+
+&spi0 {
+ status = "okay";
+};
+
+&ssc0 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+};
+
+&i2c1 {
+ status = "okay";
+};
+
+&usart1 {
+ status = "okay";
+};
+
+&usart2 {
+ status = "okay";
+};
+
+&usart3 {
+ status = "okay";
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&dbgu {
+ status = "okay";
+};
+
+&pit {
+ status = "okay";
+};
+
+&adc0 {
+ status = "okay";
+};
+
+&can1 {
+ status = "okay";
+};
+
+&macb0 {
+ status = "okay";
+};
+
+&macb1 {
+ status = "okay";
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+};
+
+&usb2 {
+ status = "okay";
+};
+
diff --git a/arch/arm/boot/dts/at91-dvk_su60_somc.dtsi b/arch/arm/boot/dts/at91-dvk_su60_somc.dtsi
new file mode 100644
index 0000000..6031c2f
--- /dev/null
+++ b/arch/arm/boot/dts/at91-dvk_su60_somc.dtsi
@@ -0,0 +1,159 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * at91-dvk_su60_somc.dtsi - Device Tree file for the DVK SOM60 base board
+ *
+ * Copyright (C) 2018 Laird,
+ * 2018 Ben Whitten <ben.whitten@lairdtech.com>
+ *
+ */
+
+/ {
+ sound {
+ compatible = "atmel,asoc-wm8904";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pck2_as_audio_mck>;
+
+ atmel,model = "wm8904 @ DVK-SOM60";
+ atmel,audio-routing =
+ "Headphone Jack", "HPOUTL",
+ "Headphone Jack", "HPOUTR",
+ "IN2L", "Line In Jack",
+ "IN2R", "Line In Jack",
+ "Mic", "MICBIAS",
+ "IN1L", "Mic";
+
+ atmel,ssc-controller = <&ssc0>;
+ atmel,audio-codec = <&wm8904>;
+
+ status = "okay";
+ };
+};
+
+&mmc0 {
+ status = "okay";
+
+ pinctrl-0 = <&pinctrl_mmc0_clk_cmd_dat0 &pinctrl_mmc0_dat1_3 &pinctrl_mmc0_cd>;
+ slot at 0 {
+ bus-width = <4>;
+ cd-gpios = <&pioE 31 GPIO_ACTIVE_HIGH>;
+ cd-inverted;
+ };
+};
+
+&spi0 {
+ status = "okay";
+
+ /* spi0.0: 4M Flash Macronix MX25R4035FM1IL0 */
+ spi-flash at 0 {
+ compatible = "mxicy,mx25u4035", "jedec,spi-nor";
+ spi-max-frequency = <33000000>;
+ reg = <0>;
+ };
+};
+
+&ssc0 {
+ atmel,clk-from-rk-pin;
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+
+ wm8904: wm8904 at 1a {
+ compatible = "wlf,wm8904";
+ reg = <0x1a>;
+ clocks = <&pck2>;
+ clock-names = "mclk";
+ };
+};
+
+&i2c1 {
+ status = "okay";
+
+ eeprom at 87 {
+ compatible = "giantec,24c32";
+ reg = <87>;
+ pagesize = <32>;
+ };
+};
+
+&usart1 {
+ status = "okay";
+};
+
+&usart2 {
+ status = "okay";
+};
+
+&usart3 {
+ status = "okay";
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&dbgu {
+ status = "okay";
+};
+
+&pit {
+ status = "okay";
+};
+
+&adc0 {
+ status = "okay";
+};
+
+&can1 {
+ status = "okay";
+};
+
+&macb0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ ethernet-phy at 7 {
+ reg = <7>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_geth_int>;
+ interrupt-parent = <&pioB>;
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ txen-skew-ps = <800>;
+ txc-skew-ps = <3000>;
+ rxdv-skew-ps = <400>;
+ rxc-skew-ps = <3000>;
+ rxd0-skew-ps = <400>;
+ rxd1-skew-ps = <400>;
+ rxd2-skew-ps = <400>;
+ rxd3-skew-ps = <400>;
+ };
+};
+
+&macb1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ ethernet-phy at 1 {
+ reg = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_eth_int>;
+ interrupt-parent = <&pioC>;
+ interrupts = <10 IRQ_TYPE_EDGE_FALLING>;
+ };
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+};
+
+&usb2 {
+ status = "okay";
+};
+
diff --git a/arch/arm/boot/dts/at91-dvk_su60_somc_lcm.dtsi b/arch/arm/boot/dts/at91-dvk_su60_somc_lcm.dtsi
new file mode 100644
index 0000000..d98c644
--- /dev/null
+++ b/arch/arm/boot/dts/at91-dvk_su60_somc_lcm.dtsi
@@ -0,0 +1,96 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * at91-dvk_su60_somc_lcm.dtsi - Device Tree file for the DVK SOM60 LCD board
+ *
+ * Copyright (C) 2018 Laird,
+ * 2018 Ben Whitten <ben.whitten@lairdtech.com>
+ *
+ */
+
+/ {
+ ahb {
+ apb {
+ pinctrl at fffff200 {
+ board {
+ pinctrl_lcd_ctp_int: lcd_ctp_int {
+ atmel,pins =
+ <AT91_PIOC 28 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>;
+ };
+ };
+ };
+ };
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&hlcdc_pwm 0 50000 0>;
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <6>;
+ status = "okay";
+ };
+
+ panel: panel {
+ /* Actually Winstar WF70GTIAGDNG0 */
+ compatible = "innolux,at070tn92", "simple-panel";
+ backlight = <&backlight>;
+ power-supply = <&vcc_lcd_reg>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ port at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ panel_input: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&hlcdc_panel_output>;
+ };
+ };
+ };
+
+ vcc_lcd_reg: fixedregulator_lcd {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC LCM";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ status = "okay";
+ };
+};
+
+&i2c1 {
+ status = "okay";
+
+ ft5426 at 56 {
+ /* Actually FT5426 */
+ compatible = "edt,edt-ft5406";
+ reg = <56>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcd_ctp_int>;
+
+ interrupt-parent = <&pioC>;
+ interrupts = <28 IRQ_TYPE_EDGE_FALLING>;
+
+ touchscreen-size-x = <800>;
+ touchscreen-size-y = <480>;
+ };
+};
+
+&hlcdc {
+ status = "okay";
+
+ hlcdc-display-controller {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcd_base &pinctrl_lcd_rgb888>;
+
+ port at 0 {
+ hlcdc_panel_output: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&panel_input>;
+ };
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/at91-som60.dtsi b/arch/arm/boot/dts/at91-som60.dtsi
new file mode 100644
index 0000000..1843284
--- /dev/null
+++ b/arch/arm/boot/dts/at91-som60.dtsi
@@ -0,0 +1,229 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * at91-som60.dtsi - Device Tree file for the SOM60 module
+ *
+ * Copyright (C) 2018 Laird,
+ * 2018 Ben Whitten <ben.whitten@lairdtech.com>
+ *
+ */
+#include "sama5d36.dtsi"
+
+/ {
+ model = "Laird SOM60";
+ compatible = "laird,som60", "atmel,sama5d36", "atmel,sama5d3", "atmel,sama5";
+
+ chosen {
+ stdout-path = &dbgu;
+ };
+
+ memory {
+ reg = <0x20000000 0x8000000>;
+ };
+
+ clocks {
+ slow_xtal {
+ clock-frequency = <32768>;
+ };
+
+ main_xtal {
+ clock-frequency = <12000000>;
+ };
+ };
+
+ ahb {
+ apb {
+ pinctrl at fffff200 {
+ board {
+ pinctrl_mmc0_cd: mmc0_cd {
+ atmel,pins =
+ <AT91_PIOE 31 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>;
+ };
+
+ pinctrl_mmc0_en: mmc0_en {
+ atmel,pins =
+ <AT91_PIOE 30 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>;
+ };
+
+ pinctrl_nand0_wp: nand0_wp {
+ atmel,pins =
+ <AT91_PIOE 14 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>;
+ };
+
+ pinctrl_usb_vbus: usb_vbus {
+ atmel,pins =
+ <AT91_PIOE 20 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>; /* Conflicts with USART2_SCK */
+ };
+
+ pinctrl_usart2_sck: usart2_sck {
+ atmel,pins =
+ <AT91_PIOE 20 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* Conflicts with USB_VBUS */
+ };
+
+ pinctrl_usb_oc: usb_oc {
+ atmel,pins =
+ <AT91_PIOE 15 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* Conflicts with USART3_SCK */
+ };
+
+ pinctrl_usart3_sck: usart3_sck {
+ atmel,pins =
+ <AT91_PIOE 15 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* Conflicts with USB_OC */
+ };
+
+ pinctrl_usba_vbus: usba_vbus {
+ atmel,pins =
+ <AT91_PIOC 14 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>;
+ };
+
+ pinctrl_geth_int: geth_int {
+ atmel,pins =
+ <AT91_PIOB 25 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* Conflicts with USART1_SCK */
+ };
+
+ pinctrl_usart1_sck: usart1_sck {
+ atmel,pins =
+ <AT91_PIOB 25 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* Conflicts with GETH_INT */
+ };
+
+ pinctrl_eth_int: eth_int {
+ atmel,pins =
+ <AT91_PIOC 10 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>;
+ };
+
+ pinctrl_pck2_as_audio_mck: pck2_as_audio_mck {
+ atmel,pins =
+ <AT91_PIOC 15 AT91_PERIPH_B AT91_PINCTRL_NONE>;
+ };
+ };
+ };
+ };
+ };
+};
+
+&mmc0 {
+ slot at 0 {
+ reg = <0>;
+ bus-width = <8>;
+ };
+};
+
+&mmc1 {
+ status = "okay";
+ slot at 0 {
+ reg = <0>;
+ bus-width = <4>;
+ };
+};
+
+&spi0 {
+ cs-gpios = <&pioD 13 0>, <0>, <0>, <0>;
+};
+
+&usart0 {
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ status = "okay";
+ pinctrl-0 = <&pinctrl_usart0 &pinctrl_usart0_rts_cts>;
+};
+
+&usart1 {
+ pinctrl-0 = <&pinctrl_usart1 &pinctrl_usart1_rts_cts>;
+};
+
+&usart2 {
+ pinctrl-0 = <&pinctrl_usart2 &pinctrl_usart2_rts_cts>;
+};
+
+&usart3 {
+ pinctrl-0 = <&pinctrl_usart3 &pinctrl_usart3_rts_cts>;
+};
+
+&adc0 {
+ pinctrl-0 = <
+ &pinctrl_adc0_adtrg
+ &pinctrl_adc0_ad0
+ &pinctrl_adc0_ad1
+ &pinctrl_adc0_ad2
+ &pinctrl_adc0_ad3
+ &pinctrl_adc0_ad4
+ &pinctrl_adc0_ad5
+ >;
+};
+
+&macb0 {
+ phy-mode = "rgmii";
+};
+
+&macb1 {
+ phy-mode = "rmii";
+};
+
+
+&ebi {
+ pinctrl-0 = <&pinctrl_ebi_nand_addr>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&nand_controller {
+ status = "okay";
+
+ nand: nand at 3 {
+ reg = <0x3 0x0 0x2>;
+ atmel,rb = <0>;
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <8>;
+ nand-ecc-step-size = <512>;
+ nand-on-flash-bbt;
+ label = "atmel_nand";
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ ubootspl at 0 {
+ label = "u-boot-spl";
+ reg = <0x0 0x20000>;
+ };
+
+ uboot at 20000 {
+ label = "u-boot";
+ reg = <0x20000 0x80000>;
+ };
+
+ ubootenv at a0000 {
+ label = "u-boot-env";
+ reg = <0xa0000 0x20000>;
+ };
+
+ ubootenv at c0000 {
+ label = "u-boot-env";
+ reg = <0xc0000 0x20000>;
+ };
+
+ ubi at e0000 {
+ label = "ubi";
+ reg = <0xe0000 0xfe00000>;
+ };
+ };
+ };
+};
+
+&usb0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usba_vbus>;
+ atmel,vbus-gpio = <&pioC 14 GPIO_ACTIVE_HIGH>;
+};
+
+&usb1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb_vbus &pinctrl_usb_oc>;
+ num-ports = <3>;
+ atmel,vbus-gpio = <0
+ &pioE 20 GPIO_ACTIVE_HIGH
+ 0>;
+ atmel,oc-gpio = <0
+ &pioE 15 GPIO_ACTIVE_LOW
+ 0>;
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 3/4] arm: dts: add support for Gatwick board based on WB50N
From: Ben Whitten @ 2018-06-14 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528966340-23216-1-git-send-email-ben.whitten@lairdtech.com>
Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/at91-gatwick.dts | 125 +++++++++++++++++++++++++++++++++++++
2 files changed, 127 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/at91-gatwick.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index fd5f8a6..486ab59 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -62,7 +62,8 @@ dtb-$(CONFIG_SOC_SAM_V7) += \
at91-sama5d4_xplained.dtb \
at91-sama5d4ek.dtb \
at91-vinco.dtb \
- at91-wb50n.dtb
+ at91-wb50n.dtb \
+ at91-gatwick.dtb
dtb-$(CONFIG_ARCH_ATLAS6) += \
atlas6-evb.dtb
dtb-$(CONFIG_ARCH_ATLAS7) += \
diff --git a/arch/arm/boot/dts/at91-gatwick.dts b/arch/arm/boot/dts/at91-gatwick.dts
new file mode 100644
index 0000000..1350c08
--- /dev/null
+++ b/arch/arm/boot/dts/at91-gatwick.dts
@@ -0,0 +1,125 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * at91-gatwick.dts - Device Tree file for the Gatwick board
+ *
+ * Copyright (C) 2018 Laird
+ *
+ */
+/dts-v1/;
+#include "at91-wb50n.dtsi"
+#include <dt-bindings/input/input.h>
+
+/ {
+ model = "Laird Workgroup Bridge 50N - Project Gatwick";
+ compatible = "laird,gatwick", "laird,wb50n", "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+
+ ahb {
+ apb {
+ pinctrl at fffff200 {
+ board {
+ pinctrl_key_gpio: key_gpio_0 {
+ atmel,pins =
+ <AT91_PIOE 31 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>; /* PE31 GPIO with pullup deglitch */
+ };
+ };
+ };
+ };
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ autorepeat;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_key_gpio>;
+
+ reset-button {
+ label = "Reset Button";
+ linux,code = <KEY_SETUP>;
+ gpios = <&pioE 31 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ ethernet {
+ label = "gatwick:yellow:ethernet";
+ gpios = <&pioA 10 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ wifi {
+ label = "gatwick:green:wifi";
+ gpios = <&pioA 28 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ ble {
+ label = "gatwick:blue:ble";
+ gpios = <&pioA 22 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ lora {
+ label = "gatwick:orange:lora";
+ gpios = <&pioA 26 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ blank {
+ label = "gatwick:green:blank";
+ gpios = <&pioA 24 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ user {
+ label = "gatwick:yellow:user";
+ gpios = <&pioA 12 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+ };
+};
+
+&mmc0 {
+ status = "okay";
+};
+
+&macb1 {
+ status = "okay";
+};
+
+&dbgu {
+ status = "okay";
+};
+
+/* FTDI USART */
+&usart0 {
+ status = "okay";
+};
+
+/* GPS USART */
+&usart1 {
+ pinctrl-0 = <&pinctrl_usart1>;
+ status = "okay";
+};
+
+&spi1 {
+ status = "okay";
+
+ spidev at 0 {
+ compatible = "semtech,sx1301";
+ reg = <0>;
+ spi-max-frequency = <8000000>;
+ };
+};
+
+&usb1 {
+ status = "okay";
+ /delete-property/atmel,oc-gpio;
+};
+
+&usb2 {
+ status = "okay";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 2/4] arm: dts: add support for Laird WB50N cpu module and DVK
From: Ben Whitten @ 2018-06-14 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528966340-23216-1-git-send-email-ben.whitten@lairdtech.com>
Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/at91-wb50n.dts | 116 ++++++++++++++++++++++
arch/arm/boot/dts/at91-wb50n.dtsi | 202 ++++++++++++++++++++++++++++++++++++++
3 files changed, 320 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/at91-wb50n.dts
create mode 100644 arch/arm/boot/dts/at91-wb50n.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 1ee94ee..fd5f8a6 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -61,7 +61,8 @@ dtb-$(CONFIG_SOC_SAM_V7) += \
at91-sama5d4_ma5d4evk.dtb \
at91-sama5d4_xplained.dtb \
at91-sama5d4ek.dtb \
- at91-vinco.dtb
+ at91-vinco.dtb \
+ at91-wb50n.dtb
dtb-$(CONFIG_ARCH_ATLAS6) += \
atlas6-evb.dtb
dtb-$(CONFIG_ARCH_ATLAS7) += \
diff --git a/arch/arm/boot/dts/at91-wb50n.dts b/arch/arm/boot/dts/at91-wb50n.dts
new file mode 100644
index 0000000..ee4f823
--- /dev/null
+++ b/arch/arm/boot/dts/at91-wb50n.dts
@@ -0,0 +1,116 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * at91-wb50n.dts - Device Tree file for wb50n evaluation board
+ *
+ * Copyright (C) 2018 Laird
+ *
+ */
+
+/dts-v1/;
+#include "at91-wb50n.dtsi"
+
+/ {
+ model = "Laird Workgroup Bridge 50N - Atmel SAMA5D";
+ compatible = "laird,wb50n", "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+
+ ahb {
+ apb {
+ watchdog at fffffe40 {
+ compatible = "atmel,at91sam9260-wdt";
+ reg = <0xfffffe40 0x10>;
+ clocks = <&clk32k>;
+ status = "okay";
+ };
+ };
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ btn0 at pa10 {
+ label = "BTNESC";
+ linux,code = <1>; /* ESC button */
+ gpios = <&pioA 10 GPIO_ACTIVE_LOW>;
+ gpio-key,wakeup = <1>;
+ };
+
+ irqbtn at pe31 {
+ label = "IRQBTN";
+ linux,code = <99>; /* SysReq button */
+ gpios = <&pioE 31 GPIO_ACTIVE_LOW>;
+ gpio-key,wakeup = <1>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led0 {
+ label = "wb50n:blue:led0";
+ gpios = <&pioA 12 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ led1 {
+ label = "wb50n:green:led1";
+ gpios = <&pioA 24 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ led2 {
+ label = "wb50n:red:led2";
+ gpios = <&pioA 26 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+ };
+};
+
+&mmc0 {
+ status = "okay";
+};
+
+&macb1 {
+ status = "okay";
+};
+
+&dbgu {
+ status = "okay";
+};
+
+/* On BB40 this port is labeled UART1 */
+&usart0 {
+ status = "okay";
+};
+
+/* On BB40 this port is labeled UART0 */
+&usart1 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+};
+
+&spi1 {
+ status = "okay";
+
+ spidev at 0 {
+ compatible = "spidev";
+ reg = <0>;
+ spi-max-frequency = <8000000>;
+ };
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+};
+
+&usb2 {
+ status = "okay";
+};
+
diff --git a/arch/arm/boot/dts/at91-wb50n.dtsi b/arch/arm/boot/dts/at91-wb50n.dtsi
new file mode 100644
index 0000000..11d8cc1
--- /dev/null
+++ b/arch/arm/boot/dts/at91-wb50n.dtsi
@@ -0,0 +1,202 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * at91-wb50n.dtsi - Device Tree include file for wb50n cpu module
+ *
+ * Copyright (C) 2018 Laird
+ *
+ */
+
+#include "sama5d31.dtsi"
+
+/ {
+ model = "Laird Workgroup Bridge 50N - Atmel SAMA5D";
+ compatible = "laird,wb50n", "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+
+ chosen {
+ bootargs = "ubi.mtd=6 root=ubi0:rootfs rootfstype=ubifs rw";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ reg = <0x20000000 0x4000000>;
+ };
+
+ ahb {
+ apb {
+ pinctrl at fffff200 {
+ board {
+ pinctrl_mmc0_cd: mmc0_cd {
+ atmel,pins = <AT91_PIOC 26 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>; /* PC26 GPIO with pullup deglitch */
+ };
+
+ pinctrl_usba_vbus: usba_vbus {
+ atmel,pins = <AT91_PIOB 13 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* PB13 GPIO with deglitch */
+ };
+ };
+ };
+ };
+ };
+};
+
+&slow_xtal {
+ clock-frequency = <32768>;
+};
+
+&main_xtal {
+ clock-frequency = <12000000>;
+};
+
+&slow_osc {
+ atmel,osc-bypass;
+};
+
+&usart1_clk {
+ atmel,clk-output-range = <0 132000000>;
+};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mmc0_clk_cmd_dat0 &pinctrl_mmc0_dat1_3 &pinctrl_mmc0_cd>;
+ cd-gpios = <&pioC 26 GPIO_ACTIVE_LOW>;
+ slot at 0 {
+ reg = <0>;
+ bus-width = <4>;
+ };
+};
+
+&mmc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mmc1_clk_cmd_dat0 &pinctrl_mmc1_dat1_3>;
+ status = "okay";
+ atheros at 0 {
+ compatible = "atheros,ath6kl";
+ atheros,board-id = "SD32";
+ reg = <0>;
+ bus-width = <4>;
+ };
+};
+
+&macb1 {
+ phy-mode = "rmii";
+};
+
+&dbgu {
+ dmas = <0>, <0>; /* Do not use DMA for dbgu */
+};
+
+/* On BB40 this port is labeled UART1 */
+&usart0 {
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usart0 &pinctrl_usart0_rts_cts>;
+};
+
+/* On BB40 this port is labeled UART0 */
+&usart1 {
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usart1 &pinctrl_usart1_rts_cts>;
+ dtr-gpios = <&pioD 13 GPIO_ACTIVE_LOW>;
+ dsr-gpios = <&pioD 11 GPIO_ACTIVE_LOW>;
+ dcd-gpios = <&pioD 7 GPIO_ACTIVE_LOW>;
+ rng-gpios = <&pioD 8 GPIO_ACTIVE_LOW>;
+};
+
+/* USART3 is direct-connect to the Bluetooth UART on the radio SIP */
+&usart3 {
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usart3 &pinctrl_usart3_rts_cts>;
+ status = "okay";
+};
+
+&spi1 {
+ cs-gpios = <&pioC 25 0>, <0>, <0>, <0>;
+};
+
+&ebi {
+ pinctrl-0 = <&pinctrl_ebi_nand_addr>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&nand_controller {
+ status = "okay";
+
+ nand: nand at 3 {
+ reg = <0x3 0x0 0x2>;
+ atmel,rb = <0>;
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <8>;
+ nand-ecc-step-size = <512>;
+ nand-on-flash-bbt;
+ label = "atmel_nand";
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ at91bootstrap at 0 {
+ label = "at91bs";
+ reg = <0x0 0x20000>;
+ };
+
+ uboot at 20000 {
+ label = "u-boot";
+ reg = <0x20000 0x80000>;
+ };
+
+ ubootenv at a0000 {
+ label = "u-boot-env";
+ reg = <0xa0000 0x20000>;
+ };
+
+ ubootenv at c0000 {
+ label = "u-boot-env";
+ reg = <0xc0000 0x20000>;
+ };
+
+ kernel-a at e0000 {
+ label = "kernel-a";
+ reg = <0xe0000 0x500000>;
+ };
+
+ kernel-b at 5e0000 {
+ label = "kernel-b";
+ reg = <0x5e0000 0x500000>;
+ };
+
+ rootfs-a at ae0000 {
+ label = "rootfs-a";
+ reg = <0xae0000 0x3000000>;
+ };
+
+ rootfs-b at 3ae0000 {
+ label = "rootfs-b";
+ reg = <0x3ae0000 0x3000000>;
+ };
+
+ user at 6ae0000 {
+ label = "user";
+ reg = <0x6ae0000 0x14e0000>;
+ };
+ };
+ };
+};
+
+&usb0 {
+ atmel,vbus-gpio = <&pioB 13 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usba_vbus>;
+};
+
+&usb1 {
+ num-ports = <3>;
+ atmel,vbus-gpio = <&pioA 2 GPIO_ACTIVE_LOW>;
+ atmel,oc-gpio = <&pioA 4 GPIO_ACTIVE_LOW>;
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 1/4] arm: dts: add support for Laird WB45N cpu module and DVK
From: Ben Whitten @ 2018-06-14 8:51 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/at91-wb45n.dts | 66 +++++++++++++++
arch/arm/boot/dts/at91-wb45n.dtsi | 169 ++++++++++++++++++++++++++++++++++++++
3 files changed, 237 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/at91-wb45n.dts
create mode 100644 arch/arm/boot/dts/at91-wb45n.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7e24249..1ee94ee 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -42,7 +42,8 @@ dtb-$(CONFIG_SOC_AT91SAM9) += \
at91sam9g25ek.dtb \
at91sam9g35ek.dtb \
at91sam9x25ek.dtb \
- at91sam9x35ek.dtb
+ at91sam9x35ek.dtb \
+ at91-wb45n.dtb
dtb-$(CONFIG_SOC_SAM_V7) += \
at91-kizbox2.dtb \
at91-nattis-2-natte-2.dtb \
diff --git a/arch/arm/boot/dts/at91-wb45n.dts b/arch/arm/boot/dts/at91-wb45n.dts
new file mode 100644
index 0000000..4e88815
--- /dev/null
+++ b/arch/arm/boot/dts/at91-wb45n.dts
@@ -0,0 +1,66 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * at91-wb45n.dts - Device Tree file for WB45NBT board
+ *
+ * Copyright (C) 2018 Laird
+ *
+*/
+/dts-v1/;
+#include "at91-wb45n.dtsi"
+
+/ {
+ model = "Laird Workgroup Bridge 45N - Atmel AT91SAM (dt)";
+ compatible = "laird,wb45n", "laird,wbxx", "atmel,at91sam9x5", "atmel,at91sam9";
+
+ ahb {
+ apb {
+ watchdog at fffffe40 {
+ status = "okay";
+ };
+ };
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ irqbtn at pb18 {
+ label = "IRQBTN";
+ linux,code = <99>;
+ gpios = <&pioB 18 GPIO_ACTIVE_LOW>;
+ gpio-key,wakeup = <1>;
+ };
+ };
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&mmc0 {
+ status = "okay";
+};
+
+&spi0 {
+ status = "okay";
+};
+
+&macb0 {
+ status = "okay";
+};
+
+&dbgu {
+ status = "okay";
+};
+
+&usart0 {
+ status = "okay";
+};
+
+&usart3 {
+ status = "okay";
+};
+
+&i2c1 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/at91-wb45n.dtsi b/arch/arm/boot/dts/at91-wb45n.dtsi
new file mode 100644
index 0000000..2fa58e2
--- /dev/null
+++ b/arch/arm/boot/dts/at91-wb45n.dtsi
@@ -0,0 +1,169 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * at91-wb45n.dtsi - Device Tree file for WB45NBT board
+ *
+ * Copyright (C) 2018 Laird
+ *
+ */
+
+#include "at91sam9g25.dtsi"
+
+/ {
+ model = "Laird Workgroup Bridge 45N - Atmel AT91SAM (dt)";
+ compatible = "laird,wb45n", "laird,wbxx", "atmel,at91sam9x5", "atmel,at91sam9";
+
+ chosen {
+ bootargs = "ubi.mtd=6 root=ubi0:rootfs rootfstype=ubifs rw";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ reg = <0x20000000 0x4000000>;
+ };
+
+ ahb {
+ apb {
+ shdwc at fffffe10 {
+ atmel,wakeup-mode = "low";
+ };
+
+ pinctrl at fffff400 {
+ usb2 {
+ pinctrl_board_usb2: usb2-board {
+ atmel,pins =
+ <AT91_PIOB 11 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* PB11 gpio vbus sense, deglitch */
+ };
+ };
+ };
+
+ rstc at fffffe00 {
+ compatible = "atmel,sama5d3-rstc";
+ };
+
+ };
+ };
+
+ atheros {
+ compatible = "atheros,ath6kl";
+ atheros,board-id = "SD32";
+ };
+};
+
+&slow_xtal {
+ clock-frequency = <32768>;
+};
+
+&main_xtal {
+ clock-frequency = <12000000>;
+};
+
+&ebi {
+ status = "okay";
+ nand_controller: nand-controller {
+ pinctrl-0 = <&pinctrl_nand_cs &pinctrl_nand_rb &pinctrl_nand_oe_we>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ nand at 3 {
+ reg = <0x3 0x0 0x800000>;
+ rb-gpios = <&pioD 5 GPIO_ACTIVE_HIGH>;
+ cs-gpios = <&pioD 4 GPIO_ACTIVE_HIGH>;
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <4>;
+ nand-ecc-step-size = <512>;
+ nand-on-flash-bbt;
+ label = "atmel_nand";
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ at91bootstrap at 0 {
+ label = "at91bs";
+ reg = <0x0 0x20000>;
+ };
+
+ uboot at 20000 {
+ label = "u-boot";
+ reg = <0x20000 0x80000>;
+ };
+
+ ubootenv at a0000 {
+ label = "u-boot-env";
+ reg = <0xa0000 0x20000>;
+ };
+
+ ubootenv at c0000 {
+ label = "redund-env";
+ reg = <0xc0000 0x20000>;
+ };
+
+ kernel-a at e0000 {
+ label = "kernel-a";
+ reg = <0xe0000 0x280000>;
+ };
+
+ kernel-b at 360000 {
+ label = "kernel-b";
+ reg = <0x360000 0x280000>;
+ };
+
+ rootfs-a at 5e0000 {
+ label = "rootfs-a";
+ reg = <0x5e0000 0x2600000>;
+ };
+
+ rootfs-b at 2be0000 {
+ label = "rootfs-b";
+ reg = <0x2be0000 0x2600000>;
+ };
+
+ user at 51e0000 {
+ label = "user";
+ reg = <0x51e0000 0x2dc0000>;
+ };
+
+ logs at 7fa0000 {
+ label = "logs";
+ reg = <0x7fa0000 0x60000>;
+ };
+
+ };
+ };
+ };
+};
+
+&usb0 {
+ num-ports = <2>;
+ atmel,vbus-gpio = <
+ &pioB 12 GPIO_ACTIVE_HIGH
+ &pioA 31 GPIO_ACTIVE_HIGH
+ >;
+ atmel,oc-gpio = <&pioB 13 GPIO_ACTIVE_LOW>;
+};
+
+&macb0 {
+ phy-mode = "rmii";
+};
+
+&spi0 {
+ cs-gpios = <&pioA 14 0>, <&pioA 7 0>, <0>, <0>;
+};
+
+&usb2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_board_usb2>;
+ atmel,vbus-gpio = <&pioB 11 GPIO_ACTIVE_HIGH>;
+};
+
+&mmc0 {
+ pinctrl-0 = <
+ &pinctrl_mmc0_slot0_clk_cmd_dat0
+ &pinctrl_mmc0_slot0_dat1_3>;
+ slot at 0 {
+ reg = <0>;
+ bus-width = <4>;
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 06/10] ARM: OMAP1: ams-delta FIQ: don't use static GPIO numbers
From: Linus Walleij @ 2018-06-14 8:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180609140224.32606-6-jmkrzyszt@gmail.com>
On Sat, Jun 9, 2018 at 4:02 PM, Janusz Krzysztofik <jmkrzyszt@gmail.com> wrote:
> With introduction of GPIO lookup tables to Amstrad Delta board init
> file, semantics of symbols representing OMAP GPIO pins defined in
> <mach/board-ams-delta.h> changed from statically assigned global GPIO
> numbers to hardware pin numbers local to OMAP "gpio-0-15" chip.
>
> This patch modifies deferred FIQ interrupt handler so it no longer uses
> static GPIO numbers in favour of IRQ data descriptors obtained at FIQ
> initialization time from descriptor of the GPIO chip with use of its
> hardware pin numbers. The chip descriptor is passed from the board
> init file.
>
> As a benefit, the deferred FIQ handler should work faster.
>
> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
Making the kernel a better place, so:
Acked-by: Linus Walleij <linus.walleij@linaro.org>
> +/*
> + * Some drivers may not use GPIO lookup tables but need to be provided
> + * with GPIO numbers. The same applies to GPIO based IRQ lines - some
> + * drivers may even not use GPIO layer but expect just IRQ numbers.
> + * We could either define GPIO lookup tables then use them on behalf
> + * of those devices, or we can use GPIO driver level methods for
> + * identification of GPIO and IRQ numbers. For the purpose of the latter,
> + * defina a helper function which identifies GPIO chips by their labels.
> + */
> +static int gpiochip_match_by_label(struct gpio_chip *chip, void *data)
> +{
> + char *label = data;
> +
> + return !strcmp(label, chip->label);
> +}
> +
> +/*
> + * The purpose of this function is to take care of proper initialization of
> + * devices and data structures which depend on GPIO lines provided by OMAP GPIO
> + * banks but their drivers don't use GPIO lookup tables or GPIO layer at all.
> + * The function may be called as soon as OMAP GPIO devices are probed.
> + * Since that happens at postcore_initcall, it can be called successfully
> + * from init_machine or later.
> + * Dependent devices may be registered from within this function or later.
> + */
> +static void __init omap_gpio_deps_init(void)
> +{
> + struct gpio_chip *chip;
> +
> + chip = gpiochip_find(OMAP_GPIO_LABEL, gpiochip_match_by_label);
> + if (!chip) {
> + pr_err("%s: OMAP GPIO chip not found\n", __func__);
> + return;
> + }
> +
> + ams_delta_init_fiq(chip);
> +}
This is some real stunt work isn't it.
We should really think about ways to get gpiolib more helpful for board
setups like this, but it seems complex.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] pinctrl: actions: Fix uninitialized error in owl_pin_config_set()
From: Linus Walleij @ 2018-06-14 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528452347-23986-1-git-send-email-geert@linux-m68k.org>
On Fri, Jun 8, 2018 at 12:05 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> With gcc 4.1.2:
>
> drivers/pinctrl/actions/pinctrl-owl.c: In function ?owl_pin_config_set?:
> drivers/pinctrl/actions/pinctrl-owl.c:336: warning: ?ret? may be used uninitialized in this function
>
> Indeed, if num_configs is zero, the uninitialized value will be returned
> as an error code.
>
> Fix this by preinitializing it to zero.
>
> Fixes: 2242ddfbf4d699b5 ("pinctrl: actions: Add Actions S900 pinctrl driver")
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Patch applied with Manivannan's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] pinctrl: pinctrl-single: Avoid divisions in context save/restore
From: Linus Walleij @ 2018-06-14 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528374274-26385-1-git-send-email-geert+renesas@glider.be>
On Thu, Jun 7, 2018 at 2:24 PM, Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> The divisions (and multiplications) can be avoided by changing the loops
> to use increments of mux_bytes instead of 1.
> While at it, remove the unneeded casts when assigning void pointers.
>
> This saves +100 bytes of kernel size on arm32/arm64.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Patch applied for v4.19.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v7 3/6] mfd: at91-usart: added mfd driver for usart
From: Alexandre Belloni @ 2018-06-14 8:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1086330e-40e4-8d9b-50aa-1ae9bf48aa22@microchip.com>
On 14/06/2018 11:22:25+0300, Radu Pirea wrote:
> On 06/14/2018 10:58 AM, Ludovic Desroches wrote:
> > > +static int at91_usart_mode_probe(struct platform_device *pdev)
> > > +{
> > > + struct mfd_cell cell;
> > > + u32 opmode = AT91_USART_MODE_SERIAL;
> > > +
> > > + device_property_read_u32(&pdev->dev, "atmel,usart-mode", &opmode);
> > > +
> > > + switch (opmode) {
> > > + case AT91_USART_MODE_SPI:
> > > + cell = at91_usart_spi_subdev;
> > > + break;
> > > + case AT91_USART_MODE_SERIAL:
> > > + cell = at91_usart_serial_subdev;
> > > + break;
> > > + default:
> > > + break;
> >
> > If there is an invalid opmode from the DT, you will pass a non initialized cell
> > to mfd_add_device().
> >
> > Regards
> >
> > Ludovic
>
> Hi Ludovic,
>
> Tnx. That's true. How is better to do if atmel,usart-mode has an invalid
> value? To initialize cell with at91_usart_serial_subdev or to print an error
> message and return -EINVAL?
>
Returning an error is probably the correct choice because it means the
DT has an invalid value (something was done and is wrong).
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH][next] pinctrl: pinctrl-single: add allocation failure checking of saved_vals
From: Linus Walleij @ 2018-06-14 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180606134338.4645-1-colin.king@canonical.com>
On Wed, Jun 6, 2018 at 3:43 PM, Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Currently saved_vals is being allocated and there is no check for
> failed allocation (which is more likely than normal when using
> GFP_ATOMIC). Fix this by checking for a failed allocation and
> propagating this error return down the the caller chain.
>
> Detected by CoverityScan, CID#1469841 ("Dereference null return value")
>
> Fixes: 88a1dbdec682 ("pinctrl: pinctrl-single: Add functions to save and restore pinctrl context")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Patch applied with Johan's and Tony's ACKs.
Yours,
Linus Walleij
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox