* Patch "drm/meson: Fix OOB memory accesses in meson_viu_set_osd_lut()" has been added to the 4.14-stable tree
From: gregkh @ 2018-12-06 9:29 UTC (permalink / raw)
To: 20181125012117.31915-1-lyude, carlo, dri-devel, gregkh, khilman,
linux-amlogic, linux-arm-kernel, lyude, maxime.ripard, narmstrong,
seanpaul
Cc: stable-commits
This is a note to let you know that I've just added the patch titled
drm/meson: Fix OOB memory accesses in meson_viu_set_osd_lut()
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:
drm-meson-fix-oob-memory-accesses-in-meson_viu_set_osd_lut.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 97b2a3180a559a33852ac0cd77904166069484fd Mon Sep 17 00:00:00 2001
From: Lyude Paul <lyude@redhat.com>
Date: Sat, 24 Nov 2018 20:21:17 -0500
Subject: drm/meson: Fix OOB memory accesses in meson_viu_set_osd_lut()
From: Lyude Paul <lyude@redhat.com>
commit 97b2a3180a559a33852ac0cd77904166069484fd upstream.
Currently on driver bringup with KASAN enabled, meson triggers an OOB
memory access as shown below:
[ 117.904528] ==================================================================
[ 117.904560] BUG: KASAN: global-out-of-bounds in meson_viu_set_osd_lut+0x7a0/0x890
[ 117.904588] Read of size 4 at addr ffff20000a63ce24 by task systemd-udevd/498
[ 117.904601]
[ 118.083372] CPU: 4 PID: 498 Comm: systemd-udevd Not tainted 4.20.0-rc3Lyude-Test+ #20
[ 118.091143] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018
[ 118.099768] Call trace:
[ 118.102181] dump_backtrace+0x0/0x3e8
[ 118.105796] show_stack+0x14/0x20
[ 118.109083] dump_stack+0x130/0x1c4
[ 118.112539] print_address_description+0x60/0x25c
[ 118.117214] kasan_report+0x1b4/0x368
[ 118.120851] __asan_report_load4_noabort+0x18/0x20
[ 118.125566] meson_viu_set_osd_lut+0x7a0/0x890
[ 118.129953] meson_viu_init+0x10c/0x290
[ 118.133741] meson_drv_bind_master+0x474/0x748
[ 118.138141] meson_drv_bind+0x10/0x18
[ 118.141760] try_to_bring_up_master+0x3d8/0x768
[ 118.146249] component_add+0x214/0x570
[ 118.149978] meson_dw_hdmi_probe+0x18/0x20 [meson_dw_hdmi]
[ 118.155404] platform_drv_probe+0x98/0x138
[ 118.159455] really_probe+0x2a0/0xa70
[ 118.163070] driver_probe_device+0x1b4/0x2d8
[ 118.167299] __driver_attach+0x200/0x280
[ 118.171189] bus_for_each_dev+0x10c/0x1a8
[ 118.175144] driver_attach+0x38/0x50
[ 118.178681] bus_add_driver+0x330/0x608
[ 118.182471] driver_register+0x140/0x388
[ 118.186361] __platform_driver_register+0xc8/0x108
[ 118.191117] meson_dw_hdmi_platform_driver_init+0x1c/0x1000 [meson_dw_hdmi]
[ 118.198022] do_one_initcall+0x12c/0x3bc
[ 118.201883] do_init_module+0x1fc/0x638
[ 118.205673] load_module+0x4b4c/0x6808
[ 118.209387] __se_sys_init_module+0x2e8/0x3c0
[ 118.213699] __arm64_sys_init_module+0x68/0x98
[ 118.218100] el0_svc_common+0x104/0x210
[ 118.221893] el0_svc_handler+0x48/0xb8
[ 118.225594] el0_svc+0x8/0xc
[ 118.228429]
[ 118.229887] The buggy address belongs to the variable:
[ 118.235007] eotf_33_linear_mapping+0x84/0xc0
[ 118.239301]
[ 118.240752] Memory state around the buggy address:
[ 118.245522] ffff20000a63cd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 118.252695] ffff20000a63cd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 118.259850] >ffff20000a63ce00: 00 00 00 00 04 fa fa fa fa fa fa fa 00 00 00 00
[ 118.267000] ^
[ 118.271222] ffff20000a63ce80: 00 fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
[ 118.278393] ffff20000a63cf00: 00 00 00 00 00 00 00 00 00 00 00 00 04 fa fa fa
[ 118.285542] ==================================================================
[ 118.292699] Disabling lock debugging due to kernel taint
It seems that when looping through the OSD EOTF LUT maps, we use the
same max iterator for OETF: 20. This is wrong though, since 20*2 is 40,
which means that we'll stop out of bounds on the EOTF maps.
But, this whole thing is already confusing enough to read through as-is,
so let's just replace all of the hardcoded sizes with
OSD_(OETF/EOTF)_LUT_SIZE / 2.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Carlo Caione <carlo@caione.org>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-amlogic@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: <stable@vger.kernel.org> # v4.10+
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181125012117.31915-1-lyude@redhat.com
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/meson/meson_viu.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/drivers/gpu/drm/meson/meson_viu.c
+++ b/drivers/gpu/drm/meson/meson_viu.c
@@ -184,18 +184,18 @@ void meson_viu_set_osd_lut(struct meson_
if (lut_sel == VIU_LUT_OSD_OETF) {
writel(0, priv->io_base + _REG(addr_port));
- for (i = 0; i < 20; i++)
+ for (i = 0; i < (OSD_OETF_LUT_SIZE / 2); i++)
writel(r_map[i * 2] | (r_map[i * 2 + 1] << 16),
priv->io_base + _REG(data_port));
writel(r_map[OSD_OETF_LUT_SIZE - 1] | (g_map[0] << 16),
priv->io_base + _REG(data_port));
- for (i = 0; i < 20; i++)
+ for (i = 0; i < (OSD_OETF_LUT_SIZE / 2); i++)
writel(g_map[i * 2 + 1] | (g_map[i * 2 + 2] << 16),
priv->io_base + _REG(data_port));
- for (i = 0; i < 20; i++)
+ for (i = 0; i < (OSD_OETF_LUT_SIZE / 2); i++)
writel(b_map[i * 2] | (b_map[i * 2 + 1] << 16),
priv->io_base + _REG(data_port));
@@ -211,18 +211,18 @@ void meson_viu_set_osd_lut(struct meson_
} else if (lut_sel == VIU_LUT_OSD_EOTF) {
writel(0, priv->io_base + _REG(addr_port));
- for (i = 0; i < 20; i++)
+ for (i = 0; i < (OSD_EOTF_LUT_SIZE / 2); i++)
writel(r_map[i * 2] | (r_map[i * 2 + 1] << 16),
priv->io_base + _REG(data_port));
writel(r_map[OSD_EOTF_LUT_SIZE - 1] | (g_map[0] << 16),
priv->io_base + _REG(data_port));
- for (i = 0; i < 20; i++)
+ for (i = 0; i < (OSD_EOTF_LUT_SIZE / 2); i++)
writel(g_map[i * 2 + 1] | (g_map[i * 2 + 2] << 16),
priv->io_base + _REG(data_port));
- for (i = 0; i < 20; i++)
+ for (i = 0; i < (OSD_EOTF_LUT_SIZE / 2); i++)
writel(b_map[i * 2] | (b_map[i * 2 + 1] << 16),
priv->io_base + _REG(data_port));
Patches currently in stable-queue which might be from lyude@redhat.com are
queue-4.14/drm-meson-enable-fast_io-in-meson_dw_hdmi_regmap_config.patch
queue-4.14/drm-meson-fix-oob-memory-accesses-in-meson_viu_set_osd_lut.patch
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Patch "drm/meson: Enable fast_io in meson_dw_hdmi_regmap_config" has been added to the 4.14-stable tree
From: gregkh @ 2018-12-06 9:29 UTC (permalink / raw)
To: 20181124191238.28276-1-lyude, carlo, daniel.vetter, dri-devel,
gregkh, khilman, linux-amlogic, linux-arm-kernel, lyude,
narmstrong, seanpaul
Cc: stable-commits
This is a note to let you know that I've just added the patch titled
drm/meson: Enable fast_io in meson_dw_hdmi_regmap_config
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:
drm-meson-enable-fast_io-in-meson_dw_hdmi_regmap_config.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 995b278e4723b26f8ebf0e7c119286d16c712747 Mon Sep 17 00:00:00 2001
From: Lyude Paul <lyude@redhat.com>
Date: Sat, 24 Nov 2018 14:12:38 -0500
Subject: drm/meson: Enable fast_io in meson_dw_hdmi_regmap_config
From: Lyude Paul <lyude@redhat.com>
commit 995b278e4723b26f8ebf0e7c119286d16c712747 upstream.
Seeing as we use this registermap in the context of our IRQ handlers, we
need to be using spinlocks for reading/writing registers so that we can
still read them from IRQ handlers without having to grab any mutexes and
accidentally sleep. We don't currently do this, as pointed out by
lockdep:
[ 18.403770] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:908
[ 18.406744] in_atomic(): 1, irqs_disabled(): 128, pid: 68, name: kworker/u17:0
[ 18.413864] INFO: lockdep is turned off.
[ 18.417675] irq event stamp: 12
[ 18.420778] hardirqs last enabled at (11): [<ffff000008a4f57c>] _raw_spin_unlock_irq+0x2c/0x60
[ 18.429510] hardirqs last disabled at (12): [<ffff000008a48914>] __schedule+0xc4/0xa60
[ 18.437345] softirqs last enabled at (0): [<ffff0000080b55e0>] copy_process.isra.4.part.5+0x4d8/0x1c50
[ 18.446684] softirqs last disabled at (0): [<0000000000000000>] (null)
[ 18.453979] CPU: 0 PID: 68 Comm: kworker/u17:0 Tainted: G W O 4.20.0-rc3Lyude-Test+ #9
[ 18.469839] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018
[ 18.480037] Workqueue: hci0 hci_power_on [bluetooth]
[ 18.487138] Call trace:
[ 18.494192] dump_backtrace+0x0/0x1b8
[ 18.501280] show_stack+0x14/0x20
[ 18.508361] dump_stack+0xbc/0xf4
[ 18.515427] ___might_sleep+0x140/0x1d8
[ 18.522515] __might_sleep+0x50/0x88
[ 18.529582] __mutex_lock+0x60/0x870
[ 18.536621] mutex_lock_nested+0x1c/0x28
[ 18.543660] regmap_lock_mutex+0x10/0x18
[ 18.550696] regmap_read+0x38/0x70
[ 18.557727] dw_hdmi_hardirq+0x58/0x138 [dw_hdmi]
[ 18.564804] __handle_irq_event_percpu+0xac/0x410
[ 18.571891] handle_irq_event_percpu+0x34/0x88
[ 18.578982] handle_irq_event+0x48/0x78
[ 18.586051] handle_fasteoi_irq+0xac/0x160
[ 18.593061] generic_handle_irq+0x24/0x38
[ 18.599989] __handle_domain_irq+0x60/0xb8
[ 18.606857] gic_handle_irq+0x50/0xa0
[ 18.613659] el1_irq+0xb4/0x130
[ 18.620394] debug_lockdep_rcu_enabled+0x2c/0x30
[ 18.627111] schedule+0x38/0xa0
[ 18.633781] schedule_timeout+0x3a8/0x510
[ 18.640389] wait_for_common+0x15c/0x180
[ 18.646905] wait_for_completion+0x14/0x20
[ 18.653319] mmc_wait_for_req_done+0x28/0x168
[ 18.659693] mmc_wait_for_req+0xa8/0xe8
[ 18.665978] mmc_wait_for_cmd+0x64/0x98
[ 18.672180] mmc_io_rw_direct_host+0x94/0x130
[ 18.678385] mmc_io_rw_direct+0x10/0x18
[ 18.684516] sdio_enable_func+0xe8/0x1d0
[ 18.690627] btsdio_open+0x24/0xc0 [btsdio]
[ 18.696821] hci_dev_do_open+0x64/0x598 [bluetooth]
[ 18.703025] hci_power_on+0x50/0x270 [bluetooth]
[ 18.709163] process_one_work+0x2a0/0x6e0
[ 18.715252] worker_thread+0x40/0x448
[ 18.721310] kthread+0x12c/0x130
[ 18.727326] ret_from_fork+0x10/0x1c
[ 18.735555] ------------[ cut here ]------------
[ 18.741430] do not call blocking ops when !TASK_RUNNING; state=2 set at [<000000006265ec59>] wait_for_common+0x140/0x180
[ 18.752417] WARNING: CPU: 0 PID: 68 at kernel/sched/core.c:6096 __might_sleep+0x7c/0x88
[ 18.760553] Modules linked in: dm_mirror dm_region_hash dm_log dm_mod
btsdio bluetooth snd_soc_hdmi_codec dw_hdmi_i2s_audio ecdh_generic
brcmfmac brcmutil cfg80211 rfkill ir_nec_decoder meson_dw_hdmi(O)
dw_hdmi rc_geekbox meson_rng meson_ir ao_cec rng_core rc_core cec
leds_pwm efivars nfsd ip_tables x_tables crc32_generic f2fs uas
meson_gxbb_wdt pwm_meson efivarfs ipv6
[ 18.799469] CPU: 0 PID: 68 Comm: kworker/u17:0 Tainted: G W O 4.20.0-rc3Lyude-Test+ #9
[ 18.808858] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018
[ 18.818045] Workqueue: hci0 hci_power_on [bluetooth]
[ 18.824088] pstate: 80000085 (Nzcv daIf -PAN -UAO)
[ 18.829891] pc : __might_sleep+0x7c/0x88
[ 18.835722] lr : __might_sleep+0x7c/0x88
[ 18.841256] sp : ffff000008003cb0
[ 18.846751] x29: ffff000008003cb0 x28: 0000000000000000
[ 18.852269] x27: ffff00000938e000 x26: ffff800010283000
[ 18.857726] x25: ffff800010353280 x24: ffff00000868ef50
[ 18.863166] x23: 0000000000000000 x22: 0000000000000000
[ 18.868551] x21: 0000000000000000 x20: 000000000000038c
[ 18.873850] x19: ffff000008cd08c0 x18: 0000000000000010
[ 18.879081] x17: ffff000008a68cb0 x16: 0000000000000000
[ 18.884197] x15: 0000000000aaaaaa x14: 0e200e200e200e20
[ 18.889239] x13: 0000000000000001 x12: 00000000ffffffff
[ 18.894261] x11: ffff000008adfa48 x10: 0000000000000001
[ 18.899517] x9 : ffff0000092a0158 x8 : 0000000000000000
[ 18.904674] x7 : ffff00000812136c x6 : 0000000000000000
[ 18.909895] x5 : 0000000000000000 x4 : 0000000000000001
[ 18.915080] x3 : 0000000000000007 x2 : 0000000000000007
[ 18.920269] x1 : 99ab8e9ebb6c8500 x0 : 0000000000000000
[ 18.925443] Call trace:
[ 18.929904] __might_sleep+0x7c/0x88
[ 18.934311] __mutex_lock+0x60/0x870
[ 18.938687] mutex_lock_nested+0x1c/0x28
[ 18.943076] regmap_lock_mutex+0x10/0x18
[ 18.947453] regmap_read+0x38/0x70
[ 18.951842] dw_hdmi_hardirq+0x58/0x138 [dw_hdmi]
[ 18.956269] __handle_irq_event_percpu+0xac/0x410
[ 18.960712] handle_irq_event_percpu+0x34/0x88
[ 18.965176] handle_irq_event+0x48/0x78
[ 18.969612] handle_fasteoi_irq+0xac/0x160
[ 18.974058] generic_handle_irq+0x24/0x38
[ 18.978501] __handle_domain_irq+0x60/0xb8
[ 18.982938] gic_handle_irq+0x50/0xa0
[ 18.987351] el1_irq+0xb4/0x130
[ 18.991734] debug_lockdep_rcu_enabled+0x2c/0x30
[ 18.996180] schedule+0x38/0xa0
[ 19.000609] schedule_timeout+0x3a8/0x510
[ 19.005064] wait_for_common+0x15c/0x180
[ 19.009513] wait_for_completion+0x14/0x20
[ 19.013951] mmc_wait_for_req_done+0x28/0x168
[ 19.018402] mmc_wait_for_req+0xa8/0xe8
[ 19.022809] mmc_wait_for_cmd+0x64/0x98
[ 19.027177] mmc_io_rw_direct_host+0x94/0x130
[ 19.031563] mmc_io_rw_direct+0x10/0x18
[ 19.035922] sdio_enable_func+0xe8/0x1d0
[ 19.040294] btsdio_open+0x24/0xc0 [btsdio]
[ 19.044742] hci_dev_do_open+0x64/0x598 [bluetooth]
[ 19.049228] hci_power_on+0x50/0x270 [bluetooth]
[ 19.053687] process_one_work+0x2a0/0x6e0
[ 19.058143] worker_thread+0x40/0x448
[ 19.062608] kthread+0x12c/0x130
[ 19.067064] ret_from_fork+0x10/0x1c
[ 19.071513] irq event stamp: 12
[ 19.075937] hardirqs last enabled at (11): [<ffff000008a4f57c>] _raw_spin_unlock_irq+0x2c/0x60
[ 19.083560] hardirqs last disabled at (12): [<ffff000008a48914>] __schedule+0xc4/0xa60
[ 19.091401] softirqs last enabled at (0): [<ffff0000080b55e0>] copy_process.isra.4.part.5+0x4d8/0x1c50
[ 19.100801] softirqs last disabled at (0): [<0000000000000000>] (null)
[ 19.108135] ---[ end trace 38c4920787b88c75 ]---
So, fix this by enabling the fast_io option in our regmap config so that
regmap uses spinlocks for locking instead of mutexes.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 3f68be7d8e96 ("drm/meson: Add support for HDMI encoder and DW-HDMI bridge + PHY")
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Carlo Caione <carlo@caione.org>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-amlogic@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: <stable@vger.kernel.org> # v4.12+
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181124191238.28276-1-lyude@redhat.com
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -697,6 +697,7 @@ static const struct regmap_config meson_
.reg_read = meson_dw_hdmi_reg_read,
.reg_write = meson_dw_hdmi_reg_write,
.max_register = 0x10000,
+ .fast_io = true,
};
static bool meson_hdmi_connector_is_available(struct device *dev)
Patches currently in stable-queue which might be from lyude@redhat.com are
queue-4.14/drm-meson-enable-fast_io-in-meson_dw_hdmi_regmap_config.patch
queue-4.14/drm-meson-fix-oob-memory-accesses-in-meson_viu_set_osd_lut.patch
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 5/5] ARM: spectre-v2: per-CPU vtables to work around big.Little systems
From: Marek Szyprowski @ 2018-12-06 9:32 UTC (permalink / raw)
To: Russell King, linux-arm-kernel
Cc: Mark Rutland, Julien Thierry, Marc Zyngier, Will Deacon,
Krzysztof Kozlowski, Morten Rasmussen, Dietmar Eggemann,
Qais Yousef
In-Reply-To: <E1gK0dU-0007Mp-4h@rmk-PC.armlinux.org.uk>
Hi All,
On 2018-11-06 13:39, Russell King wrote:
> In big.Little systems, some CPUs require the Spectre workarounds in
> paths such as the context switch, but other CPUs do not. In order
> to handle these differences, we need per-CPU vtables.
>
> We are unable to use the kernel's per-CPU variables to support this
> as per-CPU is not initialised at times when we need access to the
> vtables, so we have to use an array indexed by logical CPU number.
>
> We use an array-of-pointers to avoid having function pointers in
> the kernel's read/write .data section.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Today I've noticed that this patch (which has landed in v4.20-rc3 as
commit 383fb3ee8024) causes regression in CPU hotplug and suspend/resume
handling on Samsung Exynos4412 SoC (4*CortexA9 SMP). After putting any
non-zero CPU offline, it is no longer possible to get it online again.
Same in system suspend/resume - after s2r cycle, only CPU0 is online.
The regression can be observed on Hardkernel's Odroid U3 and Samsung
Trats2 boards.
Any idea how to fix this issue?
> ---
> arch/arm/include/asm/proc-fns.h | 20 ++++++++++++++++++++
> arch/arm/kernel/setup.c | 5 +++++
> arch/arm/kernel/smp.c | 31 +++++++++++++++++++++++++++++++
> arch/arm/mm/proc-v7-bugs.c | 17 ++---------------
> 4 files changed, 58 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm/include/asm/proc-fns.h b/arch/arm/include/asm/proc-fns.h
> index c259cc49c641..fe58fb3c4b4e 100644
> --- a/arch/arm/include/asm/proc-fns.h
> +++ b/arch/arm/include/asm/proc-fns.h
> @@ -104,12 +104,32 @@ extern void cpu_do_resume(void *);
> #else
>
> extern struct processor processor;
> +#if defined(CONFIG_BIG_LITTLE) && defined(CONFIG_HARDEN_BRANCH_PREDICTOR)
> +#include <linux/smp.h>
> +/*
> + * This can't be a per-cpu variable because we need to access it before
> + * per-cpu has been initialised.
> + */
> +extern struct processor *cpu_vtable[];
> +#define PROC_VTABLE(f) cpu_vtable[smp_processor_id()]->f
> +#define PROC_TABLE(f) cpu_vtable[0]->f
> +static inline void init_proc_vtable(const struct processor *p)
> +{
> + unsigned int cpu = smp_processor_id();
> + *cpu_vtable[cpu] = *p;
> + WARN_ON_ONCE(cpu_vtable[cpu]->dcache_clean_area !=
> + cpu_vtable[0]->dcache_clean_area);
> + WARN_ON_ONCE(cpu_vtable[cpu]->set_pte_ext !=
> + cpu_vtable[0]->set_pte_ext);
> +}
> +#else
> #define PROC_VTABLE(f) processor.f
> #define PROC_TABLE(f) processor.f
> static inline void init_proc_vtable(const struct processor *p)
> {
> processor = *p;
> }
> +#endif
>
> #define cpu_proc_init PROC_VTABLE(_proc_init)
> #define cpu_check_bugs PROC_VTABLE(check_bugs)
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index c214bd14a1fe..cd46a595422c 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -115,6 +115,11 @@ EXPORT_SYMBOL(elf_hwcap2);
>
> #ifdef MULTI_CPU
> struct processor processor __ro_after_init;
> +#if defined(CONFIG_BIG_LITTLE) && defined(CONFIG_HARDEN_BRANCH_PREDICTOR)
> +struct processor *cpu_vtable[NR_CPUS] = {
> + [0] = &processor,
> +};
> +#endif
> #endif
> #ifdef MULTI_TLB
> struct cpu_tlb_fns cpu_tlb __ro_after_init;
> diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
> index 5ad0b67b9e33..82b879db32ee 100644
> --- a/arch/arm/kernel/smp.c
> +++ b/arch/arm/kernel/smp.c
> @@ -42,6 +42,7 @@
> #include <asm/mmu_context.h>
> #include <asm/pgtable.h>
> #include <asm/pgalloc.h>
> +#include <asm/procinfo.h>
> #include <asm/processor.h>
> #include <asm/sections.h>
> #include <asm/tlbflush.h>
> @@ -102,6 +103,30 @@ static unsigned long get_arch_pgd(pgd_t *pgd)
> #endif
> }
>
> +#if defined(CONFIG_BIG_LITTLE) && defined(CONFIG_HARDEN_BRANCH_PREDICTOR)
> +static int secondary_biglittle_prepare(unsigned int cpu)
> +{
> + if (!cpu_vtable[cpu])
> + cpu_vtable[cpu] = kzalloc(sizeof(*cpu_vtable[cpu]), GFP_KERNEL);
> +
> + return cpu_vtable[cpu] ? 0 : -ENOMEM;
> +}
> +
> +static void secondary_biglittle_init(void)
> +{
> + init_proc_vtable(lookup_processor(read_cpuid_id())->proc);
> +}
> +#else
> +static int secondary_biglittle_prepare(unsigned int cpu)
> +{
> + return 0;
> +}
> +
> +static void secondary_biglittle_init(void)
> +{
> +}
> +#endif
> +
> int __cpu_up(unsigned int cpu, struct task_struct *idle)
> {
> int ret;
> @@ -109,6 +134,10 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
> if (!smp_ops.smp_boot_secondary)
> return -ENOSYS;
>
> + ret = secondary_biglittle_prepare(cpu);
> + if (ret)
> + return ret;
> +
> /*
> * We need to tell the secondary core where to find
> * its stack and the page tables.
> @@ -360,6 +389,8 @@ asmlinkage void secondary_start_kernel(void)
> struct mm_struct *mm = &init_mm;
> unsigned int cpu;
>
> + secondary_biglittle_init();
> +
> /*
> * The identity mapping is uncached (strongly ordered), so
> * switch away from it before attempting any exclusive accesses.
> diff --git a/arch/arm/mm/proc-v7-bugs.c b/arch/arm/mm/proc-v7-bugs.c
> index 5544b82a2e7a..9a07916af8dd 100644
> --- a/arch/arm/mm/proc-v7-bugs.c
> +++ b/arch/arm/mm/proc-v7-bugs.c
> @@ -52,8 +52,6 @@ static void cpu_v7_spectre_init(void)
> case ARM_CPU_PART_CORTEX_A17:
> case ARM_CPU_PART_CORTEX_A73:
> case ARM_CPU_PART_CORTEX_A75:
> - if (processor.switch_mm != cpu_v7_bpiall_switch_mm)
> - goto bl_error;
> per_cpu(harden_branch_predictor_fn, cpu) =
> harden_branch_predictor_bpiall;
> spectre_v2_method = "BPIALL";
> @@ -61,8 +59,6 @@ static void cpu_v7_spectre_init(void)
>
> case ARM_CPU_PART_CORTEX_A15:
> case ARM_CPU_PART_BRAHMA_B15:
> - if (processor.switch_mm != cpu_v7_iciallu_switch_mm)
> - goto bl_error;
> per_cpu(harden_branch_predictor_fn, cpu) =
> harden_branch_predictor_iciallu;
> spectre_v2_method = "ICIALLU";
> @@ -88,11 +84,9 @@ static void cpu_v7_spectre_init(void)
> ARM_SMCCC_ARCH_WORKAROUND_1, &res);
> if ((int)res.a0 != 0)
> break;
> - if (processor.switch_mm != cpu_v7_hvc_switch_mm && cpu)
> - goto bl_error;
> per_cpu(harden_branch_predictor_fn, cpu) =
> call_hvc_arch_workaround_1;
> - processor.switch_mm = cpu_v7_hvc_switch_mm;
> + cpu_do_switch_mm = cpu_v7_hvc_switch_mm;
> spectre_v2_method = "hypervisor";
> break;
>
> @@ -101,11 +95,9 @@ static void cpu_v7_spectre_init(void)
> ARM_SMCCC_ARCH_WORKAROUND_1, &res);
> if ((int)res.a0 != 0)
> break;
> - if (processor.switch_mm != cpu_v7_smc_switch_mm && cpu)
> - goto bl_error;
> per_cpu(harden_branch_predictor_fn, cpu) =
> call_smc_arch_workaround_1;
> - processor.switch_mm = cpu_v7_smc_switch_mm;
> + cpu_do_switch_mm = cpu_v7_smc_switch_mm;
> spectre_v2_method = "firmware";
> break;
>
> @@ -119,11 +111,6 @@ static void cpu_v7_spectre_init(void)
> if (spectre_v2_method)
> pr_info("CPU%u: Spectre v2: using %s workaround\n",
> smp_processor_id(), spectre_v2_method);
> - return;
> -
> -bl_error:
> - pr_err("CPU%u: Spectre v2: incorrect context switching function, system vulnerable\n",
> - cpu);
> }
> #else
> static void cpu_v7_spectre_init(void)
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 2/3] mm: Add support for kmem caches in DMA32 zone
From: Vlastimil Babka @ 2018-12-06 9:34 UTC (permalink / raw)
To: Nicolas Boichat
Cc: Michal Hocko, Will Deacon, Levin Alexander, linux-mm,
Christoph Lameter, Huaisheng Ye, Joerg Roedel, Matthew Wilcox,
hch, linux-arm Mailing List, David Rientjes, yingjoe.chen,
Tomasz Figa, Mike Rapoport, Matthias Brugger, Joonsoo Kim,
Yong Wu, Robin Murphy, lkml, Pekka Enberg, iommu, Andrew Morton,
Mel Gorman
In-Reply-To: <CANMq1KAL7TcVa4xF8=NdK2cs0VakEq5i6MyCvfmYTGCmJ78-ag@mail.gmail.com>
On 12/6/18 4:49 AM, Nicolas Boichat wrote:
>> So it would be fine even unchanged. The check would anyway need some
>> more love to catch the same with __GFP_DMA to be consistent and cover
>> all corner cases.
> Yes, the test is not complete. If we really wanted this to be
> accurate, we'd need to check that GFP_* exactly matches SLAB_CACHE_*.
>
> The only problem with dropping this is test that we should restore
> GFP_DMA32 warning/errors somewhere else (as Christopher pointed out
> here: https://lkml.org/lkml/2018/11/22/430), especially for kmalloc
> case.
I meant just dropping that patch hunk, not the whole test. Then the test
stays as it is and will keep warning anyone calling kmalloc(GFP_DMA32).
It would also warn anyone calling kmem_cache_alloc(GFP_DMA32) on
SLAB_CACHE_DMA32 cache, but since the gfp can be just dropped, and you
as the only user of this so far will do that, it's fine?
> Maybe this can be done in kmalloc_slab.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 3/4] ARM: shmobile: Enable NXP pcf85363 rtc in shmobile_defconfig
From: Geert Uytterhoeven @ 2018-12-06 9:41 UTC (permalink / raw)
To: Biju Das
Cc: linux-rtc, Fabrizio Castro, Alexandre Belloni, Geert Uytterhoeven,
Magnus Damm, Russell King, Linux-Renesas, Simon Horman,
Chris Paterson, Linux ARM
In-Reply-To: <1544086559-47141-4-git-send-email-biju.das@bp.renesas.com>
On Thu, Dec 6, 2018 at 10:04 AM Biju Das <biju.das@bp.renesas.com> wrote:
>
> The iWave RZ/G1C SBC supports RTC (NXP pcf85263). To increase hardware
> support enable the driver in the shmobile_defconfig multiplatform
> configuration.
>
> Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/3] PCI: imx: No-op imx6_setup_phy_mpll() on i.MX7D
From: Lucas Stach @ 2018-12-06 9:41 UTC (permalink / raw)
To: Andrey Smirnov, linux-pci
Cc: A.s. Dong, Richard Zhu, linux-kernel, Fabio Estevam, linux-imx,
bhelgaas, Leonard Crestez, cphealy, linux-arm-kernel
In-Reply-To: <20181206073545.10967-2-andrew.smirnov@gmail.com>
Am Mittwoch, den 05.12.2018, 23:35 -0800 schrieb Andrey Smirnov:
> PCIE PHY IP block on i.MX7D differs from the one used on i.MX6
> family,
> so none of the code in current implementation of
> imx6_setup_phy_mpll()
> is applicable.
>
> Cc: bhelgaas@google.com
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: cphealy@gmail.com
> Cc: l.stach@pengutronix.de
> Cc: Leonard Crestez <leonard.crestez@nxp.com>
> Cc: "A.s. Dong" <aisheng.dong@nxp.com>
> Cc: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: linux-imx@nxp.com
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-pci@vger.kernel.org
> Tested-by: Trent Piepho <tpiepho@impinj.com>
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> drivers/pci/controller/dwc/pci-imx6.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> b/drivers/pci/controller/dwc/pci-imx6.c
> index 2cbef2d7c207..c140f7987598 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -525,6 +525,9 @@ static int imx6_setup_phy_mpll(struct imx6_pcie
> *imx6_pcie)
> int mult, div;
> u32 val;
>
> + if (imx6_pcie->variant == IMX7D)
> + return 0;
> +
> switch (phy_rate) {
> case 125000000:
> /*
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/3] PCI: imx: No-op imx6_pcie_reset_phy() on i.MX7D
From: Lucas Stach @ 2018-12-06 9:41 UTC (permalink / raw)
To: Andrey Smirnov, linux-pci
Cc: A.s. Dong, Richard Zhu, linux-kernel, Fabio Estevam, linux-imx,
bhelgaas, Leonard Crestez, cphealy, linux-arm-kernel
In-Reply-To: <20181206073545.10967-3-andrew.smirnov@gmail.com>
Am Mittwoch, den 05.12.2018, 23:35 -0800 schrieb Andrey Smirnov:
> PCIE PHY IP block on i.MX7D differs from the one used on i.MX6 family,
> so none of the code in current implementation of imx6_pcie_reset_phy()
> is applicable.
>
> Cc: bhelgaas@google.com
> > Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: cphealy@gmail.com
> Cc: l.stach@pengutronix.de
> > Cc: Leonard Crestez <leonard.crestez@nxp.com>
> > Cc: "A.s. Dong" <aisheng.dong@nxp.com>
> > Cc: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: linux-imx@nxp.com
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-pci@vger.kernel.org
> > Tested-by: Trent Piepho <tpiepho@impinj.com>
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> drivers/pci/controller/dwc/pci-imx6.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> index c140f7987598..3c3002861d25 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -245,6 +245,9 @@ static void imx6_pcie_reset_phy(struct imx6_pcie *imx6_pcie)
> {
> > u32 tmp;
>
> > + if (imx6_pcie->variant == IMX7D)
> > + return;
> +
> > pcie_phy_read(imx6_pcie, PHY_RX_OVRD_IN_LO, &tmp);
> > tmp |= (PHY_RX_OVRD_IN_LO_RX_DATA_EN |
> > PHY_RX_OVRD_IN_LO_RX_PLL_EN);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] thermal: stm32: read factory settings properly
From: Daniel Lezcano @ 2018-12-06 9:43 UTC (permalink / raw)
To: David HERNANDEZ SANCHEZ, Zhang Rui, Eduardo Valentin, Rob Herring,
Mark Rutland, Maxime Coquelin, Alexandre TORGUE
Cc: devicetree@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org
In-Reply-To: <1544087575-22242-1-git-send-email-david.hernandezsanchez@st.com>
Hi David,
On 06/12/2018 10:12, David HERNANDEZ SANCHEZ wrote:
> Call stm_thermal_read_factory_settings once
> internal peripheral is properly clocked.
>
> To avoid wrong initialization of fmt0
> (stm_thermal_sensor struct) member add
> brackets properly.
>
> Change-Id: I150d00fd50e382df04bfad12f0653b1ed6a1db1b
Please do a cleanup of the log:
- line wrap at 72 characters
- No Change-Id
State the problem and then tell what you do to fix it.
For example, it is unclear what happens if the factory settings are read
before the clock is set.
The bracket change is not directly related to the clock ordering and it
should go in another patch.
In addition each patch is fixing something, in this case it is the
initial import, so each fixes should contain the tag:
Fixes: 1d693155 (thermal: add stm32 thermal driver)
> Signed-off-by: David Hernandez Sanchez <david.hernandezsanchez@st.com>
>
> diff --git a/drivers/thermal/st/stm_thermal.c b/drivers/thermal/st/stm_thermal.c
> index 47623da..bbd73c5 100644
> --- a/drivers/thermal/st/stm_thermal.c
> +++ b/drivers/thermal/st/stm_thermal.c
> @@ -241,8 +241,8 @@ static int stm_thermal_read_factory_settings(struct stm_thermal_sensor *sensor)
> sensor->t0 = TS1_T0_VAL1;
>
> /* Retrieve fmt0 and put it on Hz */
> - sensor->fmt0 = ADJUST * readl_relaxed(sensor->base + DTS_T0VALR1_OFFSET)
> - & TS1_FMT0_MASK;
> + sensor->fmt0 = ADJUST * (readl_relaxed(sensor->base +
> + DTS_T0VALR1_OFFSET) & TS1_FMT0_MASK);
>
> /* Retrieve ramp coefficient */
> sensor->ramp_coeff = readl_relaxed(sensor->base + DTS_RAMPVALR_OFFSET) &
> @@ -532,6 +532,10 @@ static int stm_thermal_prepare(struct stm_thermal_sensor *sensor)
> if (ret)
> return ret;
>
> + ret = stm_thermal_read_factory_settings(sensor);
> + if (ret)
> + goto thermal_unprepare;
> +
> ret = stm_thermal_calibration(sensor);
> if (ret)
> goto thermal_unprepare;
> @@ -636,10 +640,6 @@ static int stm_thermal_probe(struct platform_device *pdev)
> /* Populate sensor */
> sensor->base = base;
>
> - ret = stm_thermal_read_factory_settings(sensor);
> - if (ret)
> - return ret;
> -
> sensor->clk = devm_clk_get(&pdev->dev, "pclk");
> if (IS_ERR(sensor->clk)) {
> dev_err(&pdev->dev, "%s: failed to fetch PCLK clock\n",
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 1/2] module: Overwrite st_size instead of st_info
From: Miroslav Benes @ 2018-12-06 9:45 UTC (permalink / raw)
To: Vincent Whitchurch
Cc: Vincent Whitchurch, linux-kernel, linux, jeyu, dave.martin,
linux-arm-kernel
In-Reply-To: <20181204141415.969-1-vincent.whitchurch@axis.com>
On Tue, 4 Dec 2018, Vincent Whitchurch wrote:
> st_info is currently overwritten after relocation and used to store the
> elf_type(). However, we're going to need it fix kallsyms on ARM's
> Thumb-2 kernels, so preserve st_info and overwrite the st_size field
> instead. st_size is neither used by the module core nor by any
> architecture.
>
> Reviewed-by: Dave Martin <Dave.Martin@arm.com>
> Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Reviewed-by: Miroslav Benes <mbenes@suse.cz>
M
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/4] power: reset: at91-poweroff: move shdwc related data to one structure
From: Claudiu.Beznea @ 2018-12-06 9:48 UTC (permalink / raw)
To: sebastian.reichel, alexandre.belloni
Cc: linux-kernel, linux-arm-kernel, linux-pm
In-Reply-To: <20181205224052.34o3cmh3y3htchcj@earth.universe>
Hi Sebastian,
On 06.12.2018 00:40, Sebastian Reichel wrote:
> Hi,
>
> On Wed, Nov 07, 2018 at 06:23:40PM +0100, Alexandre Belloni wrote:
>> On 07/11/2018 14:54:17+0000, Claudiu.Beznea@microchip.com wrote:
>>> Hi Alexandre,
>>>
>>> On 06.11.2018 23:09, Alexandre Belloni wrote:
>>>> Hi Claudiu,
>>>>
>>>> On 05/11/2018 11:14:26+0000, Claudiu.Beznea@microchip.com wrote:
>>>>> static int __init at91_poweroff_probe(struct platform_device *pdev)
>>>>> @@ -154,16 +160,22 @@ static int __init at91_poweroff_probe(struct platform_device *pdev)
>>>>> u32 ddr_type;
>>>>> int ret;
>>>>>
>>>>> + at91_shdwc = devm_kzalloc(&pdev->dev, sizeof(*at91_shdwc), GFP_KERNEL);
>>>>> + if (!at91_shdwc)
>>>>> + return -ENOMEM;
>>>>> +
>>>>
>>>> Is there any real benefit that will offset the time lost for that
>>>> allocation at boot time?
>>>
>>> No, I haven't run benchmarks on this. I only wanted to have them grouped in
>>> one structure. Please let me know if you have some tests in mind.
>>>
>>
>> Well, it is probably not much but small things adds up. Having it as a
>> global structure is probably good enough.
>
> I suppose I will get a new patch with this change?
Yes, I will send a new version for this one.
Thank you,
Claudiu Beznea
>
> -- Sebastian
>
>>
>>>>
>>>> I understand you are then testing at91_shdwc to know whether the driver
>>>> already probed once. But, the driver will never probe twice as there is
>>>> only one shutdown controller on the SoC and anyway, If it was to probe
>>>> twice, it will still work as expected.
>>>
>>> I had in mind the scenario where the driver would be compiled as module. I
>>> know insmod already does this checking. I'm ok to remove this checking. I
>>> will do it in next version. With this I will also remove devm_kzalloc() of
>>> at91_shdwc.
>>>
>>
>> Thanks,
>>
>> --
>> Alexandre Belloni, Bootlin
>> Embedded Linux and Kernel engineering
>> https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 10/24] arm64: irqflags: Use ICC_PMR_EL1 for interrupt masking
From: Julien Thierry @ 2018-12-06 9:50 UTC (permalink / raw)
To: Catalin Marinas
Cc: daniel.thompson, Ard Biesheuvel, marc.zyngier, will.deacon,
christoffer.dall, linux-kernel, james.morse, Oleg Nesterov, joel,
linux-arm-kernel
In-Reply-To: <20181205182616.GE27881@arrakis.emea.arm.com>
On 05/12/18 18:26, Catalin Marinas wrote:
> On Wed, Dec 05, 2018 at 04:55:54PM +0000, Julien Thierry wrote:
>> On 04/12/18 17:36, Catalin Marinas wrote:
>>> On Mon, Nov 12, 2018 at 11:57:01AM +0000, Julien Thierry wrote:
>>>> diff --git a/arch/arm64/include/asm/irqflags.h b/arch/arm64/include/asm/irqflags.h
>>>> index 24692ed..e0a32e4 100644
>>>> --- a/arch/arm64/include/asm/irqflags.h
>>>> +++ b/arch/arm64/include/asm/irqflags.h
>>>> @@ -18,7 +18,27 @@
>>>>
>>>> #ifdef __KERNEL__
>>>>
>>>> +#include <asm/alternative.h>
>>>> +#include <asm/cpufeature.h>
>>>> #include <asm/ptrace.h>
>>>> +#include <asm/sysreg.h>
>>>> +
>>>> +
>>>> +/*
>>>> + * When ICC_PMR_EL1 is used for interrupt masking, only the bit indicating
>>>> + * whether the normal interrupts are masked is kept along with the daif
>>>> + * flags.
>>>> + */
>>>> +#define ARCH_FLAG_PMR_EN 0x1
>>>> +
>>>> +#define MAKE_ARCH_FLAGS(daif, pmr) \
>>>> + ((daif) | (((pmr) >> GIC_PRIO_STATUS_SHIFT) & ARCH_FLAG_PMR_EN))
>>>> +
>>>> +#define ARCH_FLAGS_GET_PMR(flags) \
>>>> + ((((flags) & ARCH_FLAG_PMR_EN) << GIC_PRIO_STATUS_SHIFT) \
>>>> + | GIC_PRIO_IRQOFF)
>>>> +
>>>> +#define ARCH_FLAGS_GET_DAIF(flags) ((flags) & ~ARCH_FLAG_PMR_EN)
>>>
>>> I wonder whether we could just use the PSR_I_BIT here to decide whether
>>> to set the GIC_PRIO_IRQ{ON,OFF}. We could clear the PSR_I_BIT in
>>> _restore_daif() with an alternative.
>>
>> So, the issue with it is that some contexts might be using PSR.I to
>> disable interrupts (any contexts with async errors or debug exceptions
>> disabled, kvm guest entry paths, pseudo-NMIs, ...).
>>
>> If any of these contexts calls local_irq_save()/local_irq_restore() or
>> local_daif_save()/local_daif_restore(), by only relying on PSR_I_BIT to
>> represent the PMR status, we might end up clearing PSR.I when we shouldn't.
>>
>> I'm not sure whether there are no callers of these functions in those
>> context. But if that is the case, we could simplify things, yes.
>
> There are callers of local_daif_save() (3) and local_daif_mask() (7) but
> do they all need to disable the pseudo-NMIs?
>
Hmmm, I really think that both of those should be disabling NMIs.
Otherwise, if we take an NMI, the first thing the el1_irq handler is
going to do is "enable_da_f()" which could lead to potential issues.
One thing that could be done is:
- local_daif_save() and local_daif_mask() both mask all daif bits
(taking care to represent PMR value in the I bit of the saved flags)
- local_daif_restore() restores da_f as expected and decides values to
put for PMR and PSR.I as follows:
* do the da_f restore
* if PSR.A bit is cleared in the saved flags, then we also do a start_nmi()
However, this would not work with a local_daif_save()/restore() on the
return path of an NMI because I think it is the only context with NMIs
"stopped" that can take aborts. I can add a WARN_ON(in_nmi()) for
local_daif_restore() if that doesn't affect performance too much.
Does that sound alright?
> At a brief look at x86, it seems that they have something like
> stop_nmi() and restart_nmi(). These don't have save/restore semantics,
> so we could do something similar on arm64 that only deals with the
> PSTATE.I bit directly and keep the software (flags) PSR.I as the PMR
> bit. But we'd have to go through the 10 local_daif_* cases above to see
> which actually need the stop_nmi() semantics.
>
Yes, having those could be useful to deal with the above and maybe some
other places.
Thanks,
--
Julien Thierry
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/4] dmaengine: mtk_uart_dma: add Mediatek uart DMA support
From: Long Cheng @ 2018-12-06 9:55 UTC (permalink / raw)
To: Sean Wang
Cc: mark.rutland, devicetree, yt.shen, srv_heupstream, gregkh,
Sean Wang (王志亘), linux-kernel,
Matthias Brugger, vkoul, robh+dt, linux-mediatek, linux-serial,
jslaby, dmaengine, yingjoe.chen, dan.j.williams, linux-arm-kernel
In-Reply-To: <CAGp9LzqkOHPqVmAOR+YRotOb511BEDOpUWHc-YSjphF3Gpar=w@mail.gmail.com>
On Wed, 2018-12-05 at 13:07 -0800, Sean Wang wrote:
> .
> On Wed, Dec 5, 2018 at 1:31 AM Long Cheng <long.cheng@mediatek.com> wrote:
> >
> > In DMA engine framework, add 8250 mtk dma to support it.
> >
> > Signed-off-by: Long Cheng <long.cheng@mediatek.com>
> > ---
> > drivers/dma/mediatek/8250_mtk_dma.c | 894 +++++++++++++++++++++++++++++++++++
> > drivers/dma/mediatek/Kconfig | 11 +
> > drivers/dma/mediatek/Makefile | 1 +
> > 3 files changed, 906 insertions(+)
> > create mode 100644 drivers/dma/mediatek/8250_mtk_dma.c
> >
> > diff --git a/drivers/dma/mediatek/8250_mtk_dma.c b/drivers/dma/mediatek/8250_mtk_dma.c
> > new file mode 100644
> > index 0000000..3454679
> > --- /dev/null
> > +++ b/drivers/dma/mediatek/8250_mtk_dma.c
> > @@ -0,0 +1,894 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Mediatek 8250 DMA driver.
> > + *
> > + * Copyright (c) 2018 MediaTek Inc.
> > + * Author: Long Cheng <long.cheng@mediatek.com>
> > + */
> > +
> > +#include <linux/clk.h>
> > +#include <linux/dmaengine.h>
> > +#include <linux/dma-mapping.h>
> > +#include <linux/err.h>
> > +#include <linux/init.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/list.h>
> > +#include <linux/module.h>
> > +#include <linux/of_dma.h>
> > +#include <linux/of_device.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/slab.h>
> > +#include <linux/spinlock.h>
> > +#include <linux/pm_runtime.h>
> > +#include <linux/iopoll.h>
> > +
> > +#include "../virt-dma.h"
> > +
> > +#define MTK_APDMA_DEFAULT_REQUESTS 127
> > +#define MTK_APDMA_CHANNELS (CONFIG_SERIAL_8250_NR_UARTS * 2)
> > +
> > +#define VFF_EN_B BIT(0)
> > +#define VFF_STOP_B BIT(0)
> > +#define VFF_FLUSH_B BIT(0)
> > +#define VFF_4G_SUPPORT_B BIT(0)
> > +#define VFF_RX_INT_EN0_B BIT(0) /*rx valid size >= vff thre*/
> > +#define VFF_RX_INT_EN1_B BIT(1)
> > +#define VFF_TX_INT_EN_B BIT(0) /*tx left size >= vff thre*/
> > +#define VFF_WARM_RST_B BIT(0)
> > +#define VFF_RX_INT_FLAG_CLR_B (BIT(0) | BIT(1))
> > +#define VFF_TX_INT_FLAG_CLR_B 0
> > +#define VFF_STOP_CLR_B 0
> > +#define VFF_FLUSH_CLR_B 0
> > +#define VFF_INT_EN_CLR_B 0
> > +#define VFF_4G_SUPPORT_CLR_B 0
> > +
> > +/* interrupt trigger level for tx */
> > +#define VFF_TX_THRE(n) ((n) * 7 / 8)
> > +/* interrupt trigger level for rx */
> > +#define VFF_RX_THRE(n) ((n) * 3 / 4)
> > +
> > +#define MTK_DMA_RING_SIZE 0xffffU
> > +/* invert this bit when wrap ring head again*/
> > +#define MTK_DMA_RING_WRAP 0x10000U
> > +
> > +#define VFF_INT_FLAG 0x00
> > +#define VFF_INT_EN 0x04
> > +#define VFF_EN 0x08
> > +#define VFF_RST 0x0c
> > +#define VFF_STOP 0x10
> > +#define VFF_FLUSH 0x14
> > +#define VFF_ADDR 0x1c
> > +#define VFF_LEN 0x24
> > +#define VFF_THRE 0x28
> > +#define VFF_WPT 0x2c
> > +#define VFF_RPT 0x30
> > +/*TX: the buffer size HW can read. RX: the buffer size SW can read.*/
> > +#define VFF_VALID_SIZE 0x3c
> > +/*TX: the buffer size SW can write. RX: the buffer size HW can write.*/
> > +#define VFF_LEFT_SIZE 0x40
> > +#define VFF_DEBUG_STATUS 0x50
> > +#define VFF_4G_SUPPORT 0x54
> > +
> > +struct mtk_dmadev {
> > + struct dma_device ddev;
> > + void __iomem *mem_base[MTK_APDMA_CHANNELS];
> > + spinlock_t lock; /* dma dev lock */
> > + struct tasklet_struct task;
> > + struct list_head pending;
> > + struct clk *clk;
> > + unsigned int dma_requests;
> > + bool support_33bits;
> > + unsigned int dma_irq[MTK_APDMA_CHANNELS];
> > + struct mtk_chan *ch[MTK_APDMA_CHANNELS];
> > +};
> > +
> > +struct mtk_chan {
> > + struct virt_dma_chan vc;
> > + struct list_head node;
> > + struct dma_slave_config cfg;
> > + void __iomem *base;
> > + struct mtk_dma_desc *desc;
> > +
> > + bool stop;
> > + bool requested;
> > +
> > + unsigned int dma_sig;
>
> the member can be removed as no real user would refer to it
>
Ok, i will remove it at next patch
> > + unsigned int dma_ch;
>
> a chan_id is already included in struct dma_chan, we can reuse it
>
chan_id is start from 0. but in this driver, dma info is stored to list.
if use port1, in filter_fn function, will set dma_ch to 2, 3(tx, rx). So
can't using chan_id
> > + unsigned int sgidx;
>
> the member also can be removed as no real user would refer to it
>
Ok, i will remove it at next patch
> > + unsigned int remain_size;
>
> The member remain_size seems unnecessary data to maintain a channel.
> The virtual channel struct virt_dma_chan already provide the way to
> manage all descriptors you're operating on, you should reuse related
> functions to virt_dma_chan first.
>
> Or if you mean remain_size is about the remaining size of current
> descriptor, and then putting into struct mtk_dma_desc would be better.
>
i will move it to mtk_dma_desc
> > + unsigned int rx_ptr;
> > +};
> > +
> > +struct mtk_dma_sg {
> > + dma_addr_t addr;
> > + unsigned int en; /* number of elements (24-bit) */
> > + unsigned int fn; /* number of frames (16-bit) */
> > +};
> > +
> > +struct mtk_dma_desc {
> > + struct virt_dma_desc vd;
> > + enum dma_transfer_direction dir;
> > +
> > + unsigned int sglen;
> > + struct mtk_dma_sg sg[0];
> > +};
> > +
> > +static bool mtk_dma_filter_fn(struct dma_chan *chan, void *param);
> > +static struct of_dma_filter_info mtk_dma_info = {
> > + .filter_fn = mtk_dma_filter_fn,
> > +};
> > +
> > +static inline struct mtk_dmadev *to_mtk_dma_dev(struct dma_device *d)
> > +{
> > + return container_of(d, struct mtk_dmadev, ddev);
> > +}
> > +
> > +static inline struct mtk_chan *to_mtk_dma_chan(struct dma_chan *c)
> > +{
> > + return container_of(c, struct mtk_chan, vc.chan);
> > +}
> > +
> > +static inline struct mtk_dma_desc *to_mtk_dma_desc
> > + (struct dma_async_tx_descriptor *t)
> > +{
> > + return container_of(t, struct mtk_dma_desc, vd.tx);
> > +}
> > +
> > +static void mtk_dma_chan_write(struct mtk_chan *c,
> > + unsigned int reg, unsigned int val)
> > +{
> > + writel(val, c->base + reg);
> > +}
> > +
> > +static unsigned int mtk_dma_chan_read(struct mtk_chan *c, unsigned int reg)
> > +{
> > + return readl(c->base + reg);
> > +}
> > +
> > +static void mtk_dma_desc_free(struct virt_dma_desc *vd)
> > +{
> > + struct dma_chan *chan = vd->tx.chan;
> > + struct mtk_chan *c = to_mtk_dma_chan(chan);
> > +
> > + kfree(c->desc);
> > + c->desc = NULL;
> > +}
> > +
> > +static int mtk_dma_clk_enable(struct mtk_dmadev *mtkd)
> > +{
> > + int ret;
> > +
> > + ret = clk_prepare_enable(mtkd->clk);
> > + if (ret) {
> > + dev_err(mtkd->ddev.dev, "Couldn't enable the clock\n");
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static void mtk_dma_clk_disable(struct mtk_dmadev *mtkd)
> > +{
> > + clk_disable_unprepare(mtkd->clk);
> > +}
> > +
> > +static void mtk_dma_remove_virt_list(dma_cookie_t cookie,
> > + struct virt_dma_chan *vc)
> > +{
> > + struct virt_dma_desc *vd;
> > +
> > + if (list_empty(&vc->desc_issued) == 0) {
> > + list_for_each_entry(vd, &vc->desc_issued, node) {
> > + if (cookie == vd->tx.cookie) {
> > + INIT_LIST_HEAD(&vc->desc_issued);
>
> generally, we don't force initialze the list desc_issued. Instead,
> when each descriptor is completed, we need to move each descriptor
> from the list desc_issued to the list desc_completed.
>
ok, i will modify it at next patch
> > + break;
> > + }
> > + }
> > + }
> > +}
> > +
> > +static void mtk_dma_tx_flush(struct dma_chan *chan)
> > +{
> > + struct mtk_chan *c = to_mtk_dma_chan(chan);
> > +
> > + if (mtk_dma_chan_read(c, VFF_FLUSH) == 0U)
> > + mtk_dma_chan_write(c, VFF_FLUSH, VFF_FLUSH_B);
> > +}
> > +
> > +static void mtk_dma_tx_write(struct dma_chan *chan)
> > +{
> > + struct mtk_chan *c = to_mtk_dma_chan(chan);
> > + unsigned int txcount = c->remain_size;
> > + unsigned int len, send, left, wpt, wrap;
> > +
> > + len = mtk_dma_chan_read(c, VFF_LEN);
> > +
> > + while ((left = mtk_dma_chan_read(c, VFF_LEFT_SIZE)) > 0U) {
> > + if (c->remain_size == 0U)
> > + break;
> > + send = min(left, c->remain_size);
>
> min_t
>
ok, i will modify it at next patch
> > + wpt = mtk_dma_chan_read(c, VFF_WPT);
> > + wrap = wpt & MTK_DMA_RING_WRAP ? 0U : MTK_DMA_RING_WRAP;
> > +
> > + if ((wpt & (len - 1U)) + send < len)
> > + mtk_dma_chan_write(c, VFF_WPT, wpt + send);
> > + else
> > + mtk_dma_chan_write(c, VFF_WPT,
> > + ((wpt + send) & (len - 1U))
> > + | wrap);
> > +
> > + c->remain_size -= send;
>
> I'm curious why you don't need to set up the hardware from the
> descriptor information
>
mtk_dma_chan_write is update the hardware. remain_size is length of TX
data.
> > + }
> > +
> > + if (txcount != c->remain_size) {
> > + mtk_dma_chan_write(c, VFF_INT_EN, VFF_TX_INT_EN_B);
> > + mtk_dma_tx_flush(chan);
> > + }
> > +}
> > +
> > +static void mtk_dma_start_tx(struct mtk_chan *c)
> > +{
> > + if (mtk_dma_chan_read(c, VFF_LEFT_SIZE) == 0U)
> > + mtk_dma_chan_write(c, VFF_INT_EN, VFF_TX_INT_EN_B);
> > + else
> > + mtk_dma_tx_write(&c->vc.chan);
> > +
> > + c->stop = false;
> > +}
> > +
> > +static void mtk_dma_get_rx_size(struct mtk_chan *c)
> > +{
> > + unsigned int rx_size = mtk_dma_chan_read(c, VFF_LEN);
> > + unsigned int rdptr, wrptr, wrreg, rdreg, count;
> > +
> > + rdreg = mtk_dma_chan_read(c, VFF_RPT);
> > + wrreg = mtk_dma_chan_read(c, VFF_WPT);
> > + rdptr = rdreg & MTK_DMA_RING_SIZE;
> > + wrptr = wrreg & MTK_DMA_RING_SIZE;
> > + count = ((rdreg ^ wrreg) & MTK_DMA_RING_WRAP) ?
> > + (wrptr + rx_size - rdptr) : (wrptr - rdptr);
> > +
> > + c->remain_size = count;
> > + c->rx_ptr = rdptr;
> > +
> > + mtk_dma_chan_write(c, VFF_RPT, wrreg);
> > +}
> > +
> > +static void mtk_dma_start_rx(struct mtk_chan *c)
> > +{
> > + struct dma_chan *chan = &c->vc.chan;
> > + struct mtk_dmadev *mtkd = to_mtk_dma_dev(chan->device);
> > + struct mtk_dma_desc *d = c->desc;
> > +
> > + if (mtk_dma_chan_read(c, VFF_VALID_SIZE) == 0U)
> > + return;
> > +
> > + if (d && d->vd.tx.cookie != 0) {
>
> the driver benefits from virtual_channel so you can manage the life
> cycle of each descriptor by the virtual channel related functions
> without handling details about the cookie.
>
ok, i will modify it at next patch
> > + mtk_dma_get_rx_size(c);
> > + mtk_dma_remove_virt_list(d->vd.tx.cookie, &c->vc);
> > + vchan_cookie_complete(&d->vd);
> > + } else {
> > + spin_lock(&mtkd->lock);
> > + if (list_empty(&mtkd->pending))
> > + list_add_tail(&c->node, &mtkd->pending);
> > + spin_unlock(&mtkd->lock);
> > + tasklet_schedule(&mtkd->task);
> > + }
> > +}
> > +
> > +static void mtk_dma_reset(struct mtk_chan *c)
> > +{
> > + struct mtk_dmadev *mtkd = to_mtk_dma_dev(c->vc.chan.device);
> > + u32 status;
> > + int ret;
> > +
> > + mtk_dma_chan_write(c, VFF_ADDR, 0);
> > + mtk_dma_chan_write(c, VFF_THRE, 0);
> > + mtk_dma_chan_write(c, VFF_LEN, 0);
> > + mtk_dma_chan_write(c, VFF_RST, VFF_WARM_RST_B);
> > +
> > + ret = readx_poll_timeout(readl,
> > + c->base + VFF_EN,
> > + status, status == 0, 10, 100);
> > + if (ret) {
> > + dev_err(c->vc.chan.device->dev,
> > + "dma reset: fail, timeout\n");
> > + return;
> > + }
> > +
> > + if (c->cfg.direction == DMA_DEV_TO_MEM)
> > + mtk_dma_chan_write(c, VFF_RPT, 0);
> > + else if (c->cfg.direction == DMA_MEM_TO_DEV)
> > + mtk_dma_chan_write(c, VFF_WPT, 0);
> > +
> > + if (mtkd->support_33bits)
> > + mtk_dma_chan_write(c, VFF_4G_SUPPORT, VFF_4G_SUPPORT_CLR_B);
> > +}
> > +
> > +static void mtk_dma_stop(struct mtk_chan *c)
> > +{
> > + u32 status;
> > + int ret;
> > +
> > + mtk_dma_chan_write(c, VFF_FLUSH, VFF_FLUSH_CLR_B);
> > + /* Wait for flush */
> > + ret = readx_poll_timeout(readl,
> > + c->base + VFF_FLUSH,
> > + status,
> > + (status & VFF_FLUSH_B) != VFF_FLUSH_B,
> > + 10, 100);
> > + if (ret)
> > + dev_err(c->vc.chan.device->dev,
> > + "dma stop: polling FLUSH fail, DEBUG=0x%x\n",
> > + mtk_dma_chan_read(c, VFF_DEBUG_STATUS));
> > +
> > + /*set stop as 1 -> wait until en is 0 -> set stop as 0*/
> > + mtk_dma_chan_write(c, VFF_STOP, VFF_STOP_B);
> > + ret = readx_poll_timeout(readl,
> > + c->base + VFF_EN,
> > + status, status == 0, 10, 100);
> > + if (ret)
> > + dev_err(c->vc.chan.device->dev,
> > + "dma stop: polling VFF_EN fail, DEBUG=0x%x\n",
> > + mtk_dma_chan_read(c, VFF_DEBUG_STATUS));
> > +
> > + mtk_dma_chan_write(c, VFF_STOP, VFF_STOP_CLR_B);
> > + mtk_dma_chan_write(c, VFF_INT_EN, VFF_INT_EN_CLR_B);
> > +
> > + if (c->cfg.direction == DMA_DEV_TO_MEM)
> > + mtk_dma_chan_write(c, VFF_INT_FLAG, VFF_RX_INT_FLAG_CLR_B);
> > + else
> > + mtk_dma_chan_write(c, VFF_INT_FLAG, VFF_TX_INT_FLAG_CLR_B);
> > +
> > + c->stop = true;
> > +}
> > +
> > +/*
> > + * This callback schedules all pending channels. We could be more
> > + * clever here by postponing allocation of the real DMA channels to
> > + * this point, and freeing them when our virtual channel becomes idle.
> > + *
> > + * We would then need to deal with 'all channels in-use'
> > + */
> > +static void mtk_dma_sched(unsigned long data)
> > +{
> > + struct mtk_dmadev *mtkd = (struct mtk_dmadev *)data;
> > + struct virt_dma_desc *vd;
> > + struct mtk_chan *c;
> > + dma_cookie_t cookie;
> > + unsigned long flags;
> > + LIST_HEAD(head);
> > +
> > + spin_lock_irq(&mtkd->lock);
> > + list_splice_tail_init(&mtkd->pending, &head);
> > + spin_unlock_irq(&mtkd->lock);
> > +
> > + if (!list_empty(&head)) {
> > + c = list_first_entry(&head, struct mtk_chan, node);
> > + cookie = c->vc.chan.cookie;
> > +
> > + spin_lock_irqsave(&c->vc.lock, flags);
> > + if (c->cfg.direction == DMA_DEV_TO_MEM) {
> > + list_del_init(&c->node);
> > + mtk_dma_start_rx(c);
> > + } else if (c->cfg.direction == DMA_MEM_TO_DEV) {
> > + vd = vchan_find_desc(&c->vc, cookie);
> > + c->desc = to_mtk_dma_desc(&vd->tx);
> > + list_del_init(&c->node);
> > + mtk_dma_start_tx(c);
> > + }
> > + spin_unlock_irqrestore(&c->vc.lock, flags);
> > + }
> > +}
> > +
> > +static int mtk_dma_alloc_chan_resources(struct dma_chan *chan)
> > +{
> > + struct mtk_dmadev *mtkd = to_mtk_dma_dev(chan->device);
> > + struct mtk_chan *c = to_mtk_dma_chan(chan);
> > + int ret = -EBUSY;
> > +
> > + pm_runtime_get_sync(mtkd->ddev.dev);
> > +
> > + if (!mtkd->ch[c->dma_ch]) {
> > + c->base = mtkd->mem_base[c->dma_ch];
> > + mtkd->ch[c->dma_ch] = c;
> > + ret = 1;
> > + }
> > + c->requested = false;
> > + mtk_dma_reset(c);
> > +
> > + return ret;
> > +}
> > +
> > +static void mtk_dma_free_chan_resources(struct dma_chan *chan)
> > +{
> > + struct mtk_dmadev *mtkd = to_mtk_dma_dev(chan->device);
> > + struct mtk_chan *c = to_mtk_dma_chan(chan);
> > +
> > + if (c->requested) {
> > + c->requested = false;
> > + free_irq(mtkd->dma_irq[c->dma_ch], chan);
> > + }
> > +
> > + tasklet_kill(&mtkd->task);
> > + tasklet_kill(&c->vc.task);
> > +
> > + c->base = NULL;
> > + mtkd->ch[c->dma_ch] = NULL;
> > + vchan_free_chan_resources(&c->vc);
> > +
> > + dev_dbg(mtkd->ddev.dev, "freeing channel for %u\n", c->dma_sig);
> > + c->dma_sig = 0;
> > +
> > + pm_runtime_put_sync(mtkd->ddev.dev);
> > +}
> > +
> > +static enum dma_status mtk_dma_tx_status(struct dma_chan *chan,
> > + dma_cookie_t cookie,
> > + struct dma_tx_state *txstate)
> > +{
> > + struct mtk_chan *c = to_mtk_dma_chan(chan);
> > + enum dma_status ret;
> > + unsigned long flags;
> > +
> > + if (!txstate)
> > + return DMA_ERROR;
> > +
> > + ret = dma_cookie_status(chan, cookie, txstate);
> > + spin_lock_irqsave(&c->vc.lock, flags);
> > + if (ret == DMA_IN_PROGRESS) {
> > + c->rx_ptr = mtk_dma_chan_read(c, VFF_RPT) & MTK_DMA_RING_SIZE;
> > + dma_set_residue(txstate, c->rx_ptr);
> > + } else if (ret == DMA_COMPLETE && c->cfg.direction == DMA_DEV_TO_MEM) {
> > + dma_set_residue(txstate, c->remain_size);
> > + } else {
> > + dma_set_residue(txstate, 0);
> > + }
> > + spin_unlock_irqrestore(&c->vc.lock, flags);
> > +
> > + return ret;
> > +}
> > +
> > +static struct dma_async_tx_descriptor *mtk_dma_prep_slave_sg
> > + (struct dma_chan *chan, struct scatterlist *sgl,
> > + unsigned int sglen, enum dma_transfer_direction dir,
> > + unsigned long tx_flags, void *context)
> > +{
> > + struct mtk_chan *c = to_mtk_dma_chan(chan);
> > + struct scatterlist *sgent;
> > + struct mtk_dma_desc *d;
> > + struct mtk_dma_sg *sg;
> > + unsigned int size, i, j, en;
> > +
> > + en = 1;
> > +
> > + if ((dir != DMA_DEV_TO_MEM) &&
> > + (dir != DMA_MEM_TO_DEV)) {
> > + dev_err(chan->device->dev, "bad direction\n");
> > + return NULL;
> > + }
> > +
> > + /* Now allocate and setup the descriptor. */
> > + d = kzalloc(sizeof(*d) + sglen * sizeof(d->sg[0]), GFP_ATOMIC);
> > + if (!d)
> > + return NULL;
> > +
> > + d->dir = dir;
> > +
> > + j = 0;
> > + for_each_sg(sgl, sgent, sglen, i) {
> > + d->sg[j].addr = sg_dma_address(sgent);
> > + d->sg[j].en = en;
> > + d->sg[j].fn = sg_dma_len(sgent) / en;
> > + j++;
> > + }
> > +
> > + d->sglen = j;
> > +
> > + if (dir == DMA_MEM_TO_DEV) {
> > + for (size = i = 0; i < d->sglen; i++) {
> > + sg = &d->sg[i];
> > + size += sg->en * sg->fn;
> > + }
> > + c->remain_size = size;
> > + }
> > +
> > + return vchan_tx_prep(&c->vc, &d->vd, tx_flags);
> > +}
> > +
> > +static void mtk_dma_issue_pending(struct dma_chan *chan)
> > +{
> > + struct mtk_chan *c = to_mtk_dma_chan(chan);
> > + struct virt_dma_desc *vd;
> > + struct mtk_dmadev *mtkd;
> > + dma_cookie_t cookie;
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&c->vc.lock, flags);
> > + if (c->cfg.direction == DMA_DEV_TO_MEM) {
> > + cookie = c->vc.chan.cookie;
> > + mtkd = to_mtk_dma_dev(chan->device);
> > + if (vchan_issue_pending(&c->vc) && !c->desc) {
>
> vchan_issue_pending means putting all the descriptors to list
> desc_issued, I'm supposed somewhere would iterate the list by
> vchan_next_desc and program each desc. into hardware. but I don't see
> the similar code.
ok, i will modify it at next patch
>
> > + vd = vchan_find_desc(&c->vc, cookie);
> > + c->desc = to_mtk_dma_desc(&vd->tx);
> > + }
> > + } else if (c->cfg.direction == DMA_MEM_TO_DEV) {
> > + cookie = c->vc.chan.cookie;
> > + if (vchan_issue_pending(&c->vc) && !c->desc) {
>
> ditto as the above
>
ok, i will modify it at next patch
> > + vd = vchan_find_desc(&c->vc, cookie);
> > + c->desc = to_mtk_dma_desc(&vd->tx);
> > + mtk_dma_start_tx(c);
> > + }
> > + }
> > + spin_unlock_irqrestore(&c->vc.lock, flags);
> > +}
> > +
> > +static irqreturn_t mtk_dma_rx_interrupt(int irq, void *dev_id)
> > +{
> > + struct dma_chan *chan = (struct dma_chan *)dev_id;
> > + struct mtk_chan *c = to_mtk_dma_chan(chan);
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&c->vc.lock, flags);
> > + mtk_dma_chan_write(c, VFF_INT_FLAG, VFF_RX_INT_FLAG_CLR_B);
> > +
> > + mtk_dma_start_rx(c);
> > +
> > + spin_unlock_irqrestore(&c->vc.lock, flags);
> > +
> > + return IRQ_HANDLED;
> > +}
> > +
> > +static irqreturn_t mtk_dma_tx_interrupt(int irq, void *dev_id)
> > +{
> > + struct dma_chan *chan = (struct dma_chan *)dev_id;
> > + struct mtk_dmadev *mtkd = to_mtk_dma_dev(chan->device);
> > + struct mtk_chan *c = to_mtk_dma_chan(chan);
> > + struct mtk_dma_desc *d = c->desc;
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&c->vc.lock, flags);
> > + if (c->remain_size != 0U) {
> > + list_add_tail(&c->node, &mtkd->pending);
> > + tasklet_schedule(&mtkd->task);
> > + } else {
> > + mtk_dma_remove_virt_list(d->vd.tx.cookie, &c->vc);
> > + vchan_cookie_complete(&d->vd);
> > + }
> > + spin_unlock_irqrestore(&c->vc.lock, flags);
> > +
> > + mtk_dma_chan_write(c, VFF_INT_FLAG, VFF_TX_INT_FLAG_CLR_B);
> > +
> > + return IRQ_HANDLED;
> > +}
> > +
> > +static int mtk_dma_slave_config(struct dma_chan *chan,
> > + struct dma_slave_config *cfg)
> > +{
> > + struct mtk_chan *c = to_mtk_dma_chan(chan);
> > + struct mtk_dmadev *mtkd = to_mtk_dma_dev(c->vc.chan.device);
> > + int ret;
> > +
> > + c->cfg = *cfg;
> > +
> > + if (cfg->direction == DMA_DEV_TO_MEM) {
> > + unsigned int rx_len = cfg->src_addr_width * 1024;
> > +
> > + mtk_dma_chan_write(c, VFF_ADDR, cfg->src_addr);
> > + mtk_dma_chan_write(c, VFF_LEN, rx_len);
> > + mtk_dma_chan_write(c, VFF_THRE, VFF_RX_THRE(rx_len));
> > + mtk_dma_chan_write(c,
> > + VFF_INT_EN, VFF_RX_INT_EN0_B
> > + | VFF_RX_INT_EN1_B);
> > + mtk_dma_chan_write(c, VFF_INT_FLAG, VFF_RX_INT_FLAG_CLR_B);
> > + mtk_dma_chan_write(c, VFF_EN, VFF_EN_B);
> > +
> > + if (!c->requested) {
> > + c->requested = true;
> > + ret = request_irq(mtkd->dma_irq[c->dma_ch],
> > + mtk_dma_rx_interrupt,
> > + IRQF_TRIGGER_NONE,
> > + KBUILD_MODNAME, chan);
> > + if (ret < 0) {
> > + dev_err(chan->device->dev, "Can't request rx dma IRQ\n");
> > + return -EINVAL;
> > + }
> > + }
> > + } else if (cfg->direction == DMA_MEM_TO_DEV) {
> > + unsigned int tx_len = cfg->dst_addr_width * 1024;
> > +
> > + mtk_dma_chan_write(c, VFF_ADDR, cfg->dst_addr);
> > + mtk_dma_chan_write(c, VFF_LEN, tx_len);
> > + mtk_dma_chan_write(c, VFF_THRE, VFF_TX_THRE(tx_len));
> > + mtk_dma_chan_write(c, VFF_INT_FLAG, VFF_TX_INT_FLAG_CLR_B);
> > + mtk_dma_chan_write(c, VFF_EN, VFF_EN_B);
> > +
> > + if (!c->requested) {
> > + c->requested = true;
> > + ret = request_irq(mtkd->dma_irq[c->dma_ch],
> > + mtk_dma_tx_interrupt,
> > + IRQF_TRIGGER_NONE,
> > + KBUILD_MODNAME, chan);
> > + if (ret < 0) {
> > + dev_err(chan->device->dev, "Can't request tx dma IRQ\n");
> > + return -EINVAL;
> > + }
> > + }
> > + }
> > +
> > + if (mtkd->support_33bits)
> > + mtk_dma_chan_write(c, VFF_4G_SUPPORT, VFF_4G_SUPPORT_B);
> > +
> > + if (mtk_dma_chan_read(c, VFF_EN) != VFF_EN_B) {
> > + dev_err(chan->device->dev,
> > + "config dma dir[%d] fail\n", cfg->direction);
> > + return -EINVAL;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int mtk_dma_terminate_all(struct dma_chan *chan)
> > +{
> > + struct mtk_chan *c = to_mtk_dma_chan(chan);
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&c->vc.lock, flags);
> > + list_del_init(&c->node);
> > + mtk_dma_stop(c);
> > + spin_unlock_irqrestore(&c->vc.lock, flags);
> > +
> > + return 0;
> > +}
> > +
> > +static int mtk_dma_device_pause(struct dma_chan *chan)
> > +{
> > + /* just for check caps pass */
> > + return -EINVAL;
> > +}
>
> it it possible not to register the function to the core if the
> hardware doesn't support it?
>
can't support. the function will set to cmd_pause. in 8250 serial code,
will check cmd_pause. if no the function, will can't get DMA channel.
So
the function just for this.
> > +
> > +static int mtk_dma_device_resume(struct dma_chan *chan)
> > +{
> > + /* just for check caps pass */
> > + return -EINVAL;
> > +}
>
> ditto as the above
>
> > +
> > +static void mtk_dma_free(struct mtk_dmadev *mtkd)
> > +{
> > + tasklet_kill(&mtkd->task);
> > + while (list_empty(&mtkd->ddev.channels) == 0) {
> > + struct mtk_chan *c = list_first_entry(&mtkd->ddev.channels,
> > + struct mtk_chan, vc.chan.device_node);
> > +
> > + list_del(&c->vc.chan.device_node);
> > + tasklet_kill(&c->vc.task);
> > + devm_kfree(mtkd->ddev.dev, c);
> > + }
> > +}
> > +
> > +static const struct of_device_id mtk_uart_dma_match[] = {
> > + { .compatible = "mediatek,mt6577-uart-dma", },
> > + { /* sentinel */ },
> > +};
> > +MODULE_DEVICE_TABLE(of, mtk_uart_dma_match);
> > +
> > +static int mtk_apdma_probe(struct platform_device *pdev)
> > +{
> > + struct mtk_dmadev *mtkd;
> > + struct resource *res;
> > + struct mtk_chan *c;
> > + unsigned int i;
> > + int rc;
> > +
> > + mtkd = devm_kzalloc(&pdev->dev, sizeof(*mtkd), GFP_KERNEL);
> > + if (!mtkd)
> > + return -ENOMEM;
> > +
> > + for (i = 0; i < MTK_APDMA_CHANNELS; i++) {
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, i);
> > + if (!res)
> > + return -ENODEV;
> > + mtkd->mem_base[i] = devm_ioremap_resource(&pdev->dev, res);
> > + if (IS_ERR(mtkd->mem_base[i]))
> > + return PTR_ERR(mtkd->mem_base[i]);
> > + }
> > +
> > + for (i = 0; i < MTK_APDMA_CHANNELS; i++) {
> > + mtkd->dma_irq[i] = platform_get_irq(pdev, i);
> > + if ((int)mtkd->dma_irq[i] < 0) {
> > + dev_err(&pdev->dev, "failed to get IRQ[%d]\n", i);
> > + return -EINVAL;
> > + }
> > + }
> > +
> > + mtkd->clk = devm_clk_get(&pdev->dev, NULL);
> > + if (IS_ERR(mtkd->clk)) {
> > + dev_err(&pdev->dev, "No clock specified\n");
> > + return PTR_ERR(mtkd->clk);
> > + }
> > +
> > + if (of_property_read_bool(pdev->dev.of_node, "dma-33bits")) {
> > + dev_info(&pdev->dev, "Support dma 33bits\n");
> > + mtkd->support_33bits = true;
> > + }
> > +
> > + if (mtkd->support_33bits)
> > + rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(33));
> > + else
> > + rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
> > + if (rc)
> > + return rc;
> > +
> > + dma_cap_set(DMA_SLAVE, mtkd->ddev.cap_mask);
> > + mtkd->ddev.device_alloc_chan_resources = mtk_dma_alloc_chan_resources;
> > + mtkd->ddev.device_free_chan_resources = mtk_dma_free_chan_resources;
> > + mtkd->ddev.device_tx_status = mtk_dma_tx_status;
> > + mtkd->ddev.device_issue_pending = mtk_dma_issue_pending;
> > + mtkd->ddev.device_prep_slave_sg = mtk_dma_prep_slave_sg;
> > + mtkd->ddev.device_config = mtk_dma_slave_config;
> > + mtkd->ddev.device_pause = mtk_dma_device_pause;
> > + mtkd->ddev.device_resume = mtk_dma_device_resume;
> > + mtkd->ddev.device_terminate_all = mtk_dma_terminate_all;
> > + mtkd->ddev.src_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE);
> > + mtkd->ddev.dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE);
> > + mtkd->ddev.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
> > + mtkd->ddev.residue_granularity = DMA_RESIDUE_GRANULARITY_SEGMENT;
> > + mtkd->ddev.dev = &pdev->dev;
> > + INIT_LIST_HEAD(&mtkd->ddev.channels);
> > + INIT_LIST_HEAD(&mtkd->pending);
> > +
> > + spin_lock_init(&mtkd->lock);
> > + tasklet_init(&mtkd->task, mtk_dma_sched, (unsigned long)mtkd);
> > +
> > + mtkd->dma_requests = MTK_APDMA_DEFAULT_REQUESTS;
> > + if (of_property_read_u32(pdev->dev.of_node,
> > + "dma-requests", &mtkd->dma_requests)) {
> > + dev_info(&pdev->dev,
> > + "Missing dma-requests property, using %u.\n",
> > + MTK_APDMA_DEFAULT_REQUESTS);
> > + }
> > +
> > + for (i = 0; i < MTK_APDMA_CHANNELS; i++) {
> > + c = devm_kzalloc(mtkd->ddev.dev, sizeof(*c), GFP_KERNEL);
> > + if (!c)
> > + goto err_no_dma;
> > +
> > + c->vc.desc_free = mtk_dma_desc_free;
> > + vchan_init(&c->vc, &mtkd->ddev);
> > + INIT_LIST_HEAD(&c->node);
> > + }
> > +
> > + pm_runtime_enable(&pdev->dev);
> > + pm_runtime_set_active(&pdev->dev);
> > +
> > + rc = dma_async_device_register(&mtkd->ddev);
> > + if (rc)
> > + goto rpm_disable;
> > +
> > + platform_set_drvdata(pdev, mtkd);
> > +
> > + if (pdev->dev.of_node) {
> > + mtk_dma_info.dma_cap = mtkd->ddev.cap_mask;
> > +
> > + /* Device-tree DMA controller registration */
> > + rc = of_dma_controller_register(pdev->dev.of_node,
> > + of_dma_simple_xlate,
> > + &mtk_dma_info);
>
> reusing of_dma_xlate_by_chan_id seem that also work for you.
in filter_fn function, neeg get number of dma.
>
> > + if (rc)
> > + goto dma_remove;
> > + }
> > +
> > + return rc;
> > +
> > +dma_remove:
> > + dma_async_device_unregister(&mtkd->ddev);
> > +rpm_disable:
> > + pm_runtime_disable(&pdev->dev);
> > +err_no_dma:
> > + mtk_dma_free(mtkd);
> > + return rc;
> > +}
> > +
> > +static int mtk_apdma_remove(struct platform_device *pdev)
> > +{
> > + struct mtk_dmadev *mtkd = platform_get_drvdata(pdev);
> > +
> > + if (pdev->dev.of_node)
> > + of_dma_controller_free(pdev->dev.of_node);
> > +
> > + pm_runtime_disable(&pdev->dev);
> > + pm_runtime_put_noidle(&pdev->dev);
> > +
> > + dma_async_device_unregister(&mtkd->ddev);
> > +
> > + mtk_dma_free(mtkd);
> > +
> > + return 0;
> > +}
> > +
> > +#ifdef CONFIG_PM_SLEEP
> > +static int mtk_dma_suspend(struct device *dev)
> > +{
> > + struct mtk_dmadev *mtkd = dev_get_drvdata(dev);
> > +
> > + if (!pm_runtime_suspended(dev))
> > + mtk_dma_clk_disable(mtkd);
> > +
> > + return 0;
> > +}
> > +
> > +static int mtk_dma_resume(struct device *dev)
> > +{
> > + int ret;
> > + struct mtk_dmadev *mtkd = dev_get_drvdata(dev);
> > +
> > + if (!pm_runtime_suspended(dev)) {
> > + ret = mtk_dma_clk_enable(mtkd);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int mtk_dma_runtime_suspend(struct device *dev)
> > +{
> > + struct mtk_dmadev *mtkd = dev_get_drvdata(dev);
> > +
> > + mtk_dma_clk_disable(mtkd);
> > +
> > + return 0;
> > +}
> > +
> > +static int mtk_dma_runtime_resume(struct device *dev)
> > +{
> > + int ret;
> > + struct mtk_dmadev *mtkd = dev_get_drvdata(dev);
> > +
> > + ret = mtk_dma_clk_enable(mtkd);
> > + if (ret)
> > + return ret;
> > +
> > + return 0;
> > +}
> > +
> > +#endif /* CONFIG_PM_SLEEP */
> > +
> > +static const struct dev_pm_ops mtk_dma_pm_ops = {
> > + SET_SYSTEM_SLEEP_PM_OPS(mtk_dma_suspend, mtk_dma_resume)
> > + SET_RUNTIME_PM_OPS(mtk_dma_runtime_suspend,
> > + mtk_dma_runtime_resume, NULL)
> > +};
> > +
> > +static struct platform_driver mtk_dma_driver = {
> > + .probe = mtk_apdma_probe,
> > + .remove = mtk_apdma_remove,
> > + .driver = {
> > + .name = KBUILD_MODNAME,
> > + .pm = &mtk_dma_pm_ops,
> > + .of_match_table = of_match_ptr(mtk_uart_dma_match),
> > + },
> > +};
> > +
> > +static bool mtk_dma_filter_fn(struct dma_chan *chan, void *param)
> > +{
> > + if (chan->device->dev->driver == &mtk_dma_driver.driver) {
> > + struct mtk_dmadev *mtkd = to_mtk_dma_dev(chan->device);
> > + struct mtk_chan *c = to_mtk_dma_chan(chan);
> > + unsigned int req = *(unsigned int *)param;
> > +
> > + if (req <= mtkd->dma_requests) {
> > + c->dma_sig = req;
> > + c->dma_ch = req;
> > + return true;
> > + }
> > + }
> > + return false;
> > +}
> > +
> > +module_platform_driver(mtk_dma_driver);
> > +
> > +MODULE_DESCRIPTION("MediaTek UART APDMA Controller Driver");
> > +MODULE_AUTHOR("Long Cheng <long.cheng@mediatek.com>");
> > +MODULE_LICENSE("GPL v2");
> > +
> > diff --git a/drivers/dma/mediatek/Kconfig b/drivers/dma/mediatek/Kconfig
> > index 27bac0b..bef436e 100644
> > --- a/drivers/dma/mediatek/Kconfig
> > +++ b/drivers/dma/mediatek/Kconfig
> > @@ -1,4 +1,15 @@
> >
> > +config DMA_MTK_UART
> > + tristate "MediaTek SoCs APDMA support for UART"
> > + depends on OF
> > + select DMA_ENGINE
> > + select DMA_VIRTUAL_CHANNELS
> > + help
> > + Support for the UART DMA engine found on MediaTek MTK SoCs.
> > + when 8250 mtk uart is enabled, and if you want to using DMA,
> > + you can enable the config. the DMA engine just only be used
> > + with MediaTek Socs.
> > +
> > config MTK_HSDMA
> > tristate "MediaTek High-Speed DMA controller support"
> > depends on ARCH_MEDIATEK || COMPILE_TEST
> > diff --git a/drivers/dma/mediatek/Makefile b/drivers/dma/mediatek/Makefile
> > index 6e778f8..2f2efd9 100644
> > --- a/drivers/dma/mediatek/Makefile
> > +++ b/drivers/dma/mediatek/Makefile
> > @@ -1 +1,2 @@
> > +obj-$(CONFIG_DMA_MTK_UART) += 8250_mtk_dma.o
> > obj-$(CONFIG_MTK_HSDMA) += mtk-hsdma.o
> > --
> > 1.7.9.5
> >
> >
> > _______________________________________________
> > Linux-mediatek mailing list
> > Linux-mediatek@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-mediatek
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/7] arm64: capabilities: Merge entries for ARM64_WORKAROUND_CLEAN_CACHE
From: Will Deacon @ 2018-12-06 9:58 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: mark.rutland, vladimir.murzin, catalin.marinas, linux-kernel,
Andre Przywara, dave.martin, linux-arm-kernel
In-Reply-To: <b61f749d-9d65-fb76-74b5-b999fecad42b@arm.com>
On Wed, Dec 05, 2018 at 05:14:53PM +0000, Suzuki K Poulose wrote:
> On 05/12/2018 15:02, Will Deacon wrote:
> >On Fri, Nov 30, 2018 at 05:18:00PM +0000, Suzuki K Poulose wrote:
> >>diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
> >>index 12f93e4d..2e26375 100644
> >>--- a/arch/arm64/include/asm/cputype.h
> >>+++ b/arch/arm64/include/asm/cputype.h
> >>@@ -151,6 +151,7 @@ struct midr_range {
> >> .rv_max = MIDR_CPU_VAR_REV(v_max, r_max), \
> >> }
> >>+#define MIDR_REV_RANGE(m, v, r_min, r_max) MIDR_RANGE(m, v, r_min, v, r_max)
> >
> >What's the point of this macro?
>
> That can be used to specify a set of MIDRs which has the same "variant" but a
> range of "revisions". This is used for the A53 errata and also for the Cavium
> errata in the following patch.
Gah, I read this at least 10 times and I /still/ failed to spot the extra
'v' argument to MIDR_RANGE!
Ignore my silly comment; I'll queue this up today. Thanks.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: dts: stm32: Add hwspinlock node for stm32mp157 SoC
From: Benjamin Gaignard @ 2018-12-06 9:57 UTC (permalink / raw)
To: alexandre.torgue, robh+dt, mark.rutland
Cc: devicetree, Benjamin Gaignard, linux-kernel, Benjamin Gaignard,
linux-stm32, linux-arm-kernel
From: Benjamin Gaignard <benjamin.gaignard@st.com>
Declare hwspinlock device for stm32mp157 SoC
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
---
arch/arm/boot/dts/stm32mp157c.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi b/arch/arm/boot/dts/stm32mp157c.dtsi
index f8bbfff5950b..2bd4394fd791 100644
--- a/arch/arm/boot/dts/stm32mp157c.dtsi
+++ b/arch/arm/boot/dts/stm32mp157c.dtsi
@@ -886,6 +886,14 @@
status = "disabled";
};
+ hsem: hwspinlock@4c000000 {
+ compatible = "st,stm32-hwspinlock";
+ #hwlock-cells = <1>;
+ reg = <0x4c000000 0x400>;
+ clocks = <&rcc HSEM>;
+ clock-names = "hwsem";
+ };
+
rcc: rcc@50000000 {
compatible = "st,stm32mp1-rcc", "syscon";
reg = <0x50000000 0x1000>;
--
2.15.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v4 3/4] ARM: dts: stm32: Add hwspinlock node for stm32mp157 SoC
From: Benjamin Gaignard @ 2018-12-06 9:59 UTC (permalink / raw)
To: Ohad Ben Cohen, Bjorn Andersson, Rob Herring, Mark Rutland,
Alexandre Torgue
Cc: devicetree, Benjamin GAIGNARD, linux-remoteproc,
Linux Kernel Mailing List, linux-stm32, Linux ARM
In-Reply-To: <20181114090027.7580-4-benjamin.gaignard@linaro.org>
Le mer. 14 nov. 2018 à 10:00, Benjamin Gaignard
<benjamin.gaignard@linaro.org> a écrit :
>
> From: Benjamin Gaignard <benjamin.gaignard@st.com>
>
> Declare hwspinlock device for stm32mp157 SoC
I abandon this patch and I will send a one that fixes the issues.
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
> ---
> arch/arm/boot/dts/stm32mp157c.dtsi | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi b/arch/arm/boot/dts/stm32mp157c.dtsi
> index 185541a5b69f..98f824d8b0f0 100644
> --- a/arch/arm/boot/dts/stm32mp157c.dtsi
> +++ b/arch/arm/boot/dts/stm32mp157c.dtsi
> @@ -803,6 +803,15 @@
> status = "disabled";
> };
>
> + hsem: hwspinlock@4c000000 {
> + compatible = "st,stm32-hwspinlock";
> + #hwlock-cells = <1>;
> + reg = <0x4c000000 0x400>;
> + clocks = <&rcc HSEM>;
> + clock-names = "hwsem";
> + status = "disabled";
> + };
> +
> rcc: rcc@50000000 {
> compatible = "st,stm32mp1-rcc", "syscon";
> reg = <0x50000000 0x1000>;
> --
> 2.15.0
>
--
Benjamin Gaignard
Graphic Study Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 5/5] ARM: spectre-v2: per-CPU vtables to work around big.Little systems
From: Russell King - ARM Linux @ 2018-12-06 10:00 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Mark Rutland, Julien Thierry, Marc Zyngier, Will Deacon,
Krzysztof Kozlowski, Morten Rasmussen, Dietmar Eggemann,
linux-arm-kernel, Qais Yousef
In-Reply-To: <dda0be26-5ac8-a158-3210-4bc6861bede2@samsung.com>
On Thu, Dec 06, 2018 at 10:32:56AM +0100, Marek Szyprowski wrote:
> Hi All,
>
> On 2018-11-06 13:39, Russell King wrote:
> > In big.Little systems, some CPUs require the Spectre workarounds in
> > paths such as the context switch, but other CPUs do not. In order
> > to handle these differences, we need per-CPU vtables.
> >
> > We are unable to use the kernel's per-CPU variables to support this
> > as per-CPU is not initialised at times when we need access to the
> > vtables, so we have to use an array indexed by logical CPU number.
> >
> > We use an array-of-pointers to avoid having function pointers in
> > the kernel's read/write .data section.
> >
> > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
>
> Today I've noticed that this patch (which has landed in v4.20-rc3 as
> commit 383fb3ee8024) causes regression in CPU hotplug and suspend/resume
> handling on Samsung Exynos4412 SoC (4*CortexA9 SMP). After putting any
> non-zero CPU offline, it is no longer possible to get it online again.
> Same in system suspend/resume - after s2r cycle, only CPU0 is online.
> The regression can be observed on Hardkernel's Odroid U3 and Samsung
> Trats2 boards.
>
> Any idea how to fix this issue?
This is getting _really_ annoying. I send the patches out, I ask for
people to test, they seem to ignore the patches, and then they later
report problems. This is the _second_ time that this has happened,
both times with Exynos, the first time it caused the patches to miss
the merge window. Given that Spectre has to deal with every kernel
entry path, wouldn't it be logical to test every form of entry - boot,
CPU hotplug, suspend/resume etc?
Sorry, but at this point I have little sympathy.
I've no idea based on what you've supplied given that the SoC
maintainers are responsible for writing the code to deal with hotplug
etc, and Exynos's code there is something of a maze. It's not clear
which bits are being used. I think you at the very least need to debug
to find out whether the problem is at CPU down or CPU up.
From the ARM architecture point of view, for Cortex A9, all the
processor function instances should be identical. The only difference
as a result of the patch is that we'll be calling smp_processor_id()
early (which should be fine), and indirecting through the cpu_vtable[]
array rather than merely dereferencing the processor struct.
What about checking dmesg - messages from offline CPUs do not appear
on the console(s) but are still logged in the kernel log.
You could try making PROC_VTABLE() the same as PROC_TABLE() (iow,
always access cpu_vtable[0]) to see whether it's the smp_processor_id()
that's causing your problem or not. If it is, then try and work out
which of the processor functions is causing it by restoring
PROC_VTABLE() and then switching each from PROC_VTABLE() to
PROC_TABLE() until it does work.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 0/9] Improvements for i.MX7D PICO SoM and its baseboards
From: Otavio Salvador @ 2018-12-06 10:08 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, devicetree, Otavio Salvador, Sascha Hauer,
linux-kernel, Rob Herring, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam, Shawn Guo
This patchset rework the imx7d-pico SoM, its Pi baseboard
and add the Hobbit baseboard support as well.
Changes in v2:
- replace fsl,uart-has-rtscts with uart-has-rtscts
Fabio Estevam (8):
ARM: dts: imx7d-pico: Do not harcode the memory size
ARM: dts: imx7d-pico: Switch to SPDX identifier
ARM: dts: imx7d-pico-pi: Move SoM related part to imx7d-pico.dtsi
ARM: dts: imx7d-pico: Pass the USBOTG1_PWR pinctrl
ARM: dts: imx7d-pico: Pass the Ethernet PHY reset GPIO
ARM: dts: imx7d-pico: Extend peripherals support
ARM: dts: imx7d-pico-pi: Extend peripherals support
ARM: dts: imx7d-pico: Add the imx7d-pico-hobbit variant
Otavio Salvador (1):
ARM: dts: imx7d-pico: Improve WiFi regulator name
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx7d-pico-hobbit.dts | 105 +++++++
arch/arm/boot/dts/imx7d-pico-pi.dts | 180 +++---------
arch/arm/boot/dts/imx7d-pico.dtsi | 355 ++++++++++++++++++++----
4 files changed, 457 insertions(+), 184 deletions(-)
create mode 100644 arch/arm/boot/dts/imx7d-pico-hobbit.dts
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 1/9] ARM: dts: imx7d-pico: Do not harcode the memory size
From: Otavio Salvador @ 2018-12-06 10:08 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, devicetree, Otavio Salvador, Shawn Guo,
Sascha Hauer, linux-kernel, Rob Herring, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam, Fabio Estevam
In-Reply-To: <20181206100905.15053-1-otavio@ossystems.com.br>
From: Fabio Estevam <festevam@gmail.com>
Currently the memory size described in dts is 2GB, which is incorrect.
There are 512MB and 1GB versions of imx7d-pico boards, so remove
the hardcoded memory size and let the bootloader pass the correct
value to the kernel.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
Changes in v2: None
arch/arm/boot/dts/imx7d-pico.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx7d-pico.dtsi b/arch/arm/boot/dts/imx7d-pico.dtsi
index 934a019f341e..0df68e53e9fa 100644
--- a/arch/arm/boot/dts/imx7d-pico.dtsi
+++ b/arch/arm/boot/dts/imx7d-pico.dtsi
@@ -48,9 +48,10 @@
model = "Technexion Pico i.MX7D Board";
compatible = "technexion,imx7d-pico", "fsl,imx7d";
+ /* Will be filled by the bootloader */
memory@80000000 {
device_type = "memory";
- reg = <0x80000000 0x80000000>;
+ reg = <0x80000000 0>;
};
reg_ap6212: regulator-ap6212 {
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 2/9] ARM: dts: imx7d-pico: Switch to SPDX identifier
From: Otavio Salvador @ 2018-12-06 10:08 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, devicetree, Otavio Salvador, Shawn Guo,
Sascha Hauer, linux-kernel, Rob Herring, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam, Fabio Estevam
In-Reply-To: <20181206100905.15053-1-otavio@ossystems.com.br>
From: Fabio Estevam <festevam@gmail.com>
Adopt the SPDX license identifier headers to ease license compliance
management.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
Changes in v2: None
arch/arm/boot/dts/imx7d-pico-pi.dts | 44 ++---------------------------
arch/arm/boot/dts/imx7d-pico.dtsi | 44 ++---------------------------
2 files changed, 6 insertions(+), 82 deletions(-)
diff --git a/arch/arm/boot/dts/imx7d-pico-pi.dts b/arch/arm/boot/dts/imx7d-pico-pi.dts
index ee02d931cf49..33951f4c7f41 100644
--- a/arch/arm/boot/dts/imx7d-pico-pi.dts
+++ b/arch/arm/boot/dts/imx7d-pico-pi.dts
@@ -1,44 +1,6 @@
-/*
- * Copyright 2017 NXP
- *
- * This file is dual-licensed: you can use it either under the terms
- * of the GPL or the X11 license, at your option. Note that this dual
- * licensing only applies to this file, and not this project as a
- * whole.
- *
- * a) This file is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License, or (at your option) any later version.
- *
- * This file is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * Or, alternatively,
- *
- * b) Permission is hereby granted, free of charge, to any person
- * obtaining a copy of this software and associated documentation
- * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use,
- * copy, modify, merge, publish, distribute, sublicense, and/or
- * sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following
- * conditions:
- *
- * The above copyright notice and this permission notice shall be
- * included in all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
- * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
- * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
- */
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+//
+// Copyright 2017 NXP
#include "imx7d-pico.dtsi"
diff --git a/arch/arm/boot/dts/imx7d-pico.dtsi b/arch/arm/boot/dts/imx7d-pico.dtsi
index 0df68e53e9fa..d957454ce16b 100644
--- a/arch/arm/boot/dts/imx7d-pico.dtsi
+++ b/arch/arm/boot/dts/imx7d-pico.dtsi
@@ -1,44 +1,6 @@
-/*
- * Copyright 2017 NXP
- *
- * This file is dual-licensed: you can use it either under the terms
- * of the GPL or the X11 license, at your option. Note that this dual
- * licensing only applies to this file, and not this project as a
- * whole.
- *
- * a) This file is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License, or (at your option) any later version.
- *
- * This file is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * Or, alternatively,
- *
- * b) Permission is hereby granted, free of charge, to any person
- * obtaining a copy of this software and associated documentation
- * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use,
- * copy, modify, merge, publish, distribute, sublicense, and/or
- * sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following
- * conditions:
- *
- * The above copyright notice and this permission notice shall be
- * included in all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
- * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
- * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
- */
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+//
+// Copyright 2017 NXP
/dts-v1/;
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 3/9] ARM: dts: imx7d-pico-pi: Move SoM related part to imx7d-pico.dtsi
From: Otavio Salvador @ 2018-12-06 10:08 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, devicetree, Otavio Salvador, Shawn Guo,
Sascha Hauer, linux-kernel, Rob Herring, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam, Fabio Estevam
In-Reply-To: <20181206100905.15053-1-otavio@ossystems.com.br>
From: Fabio Estevam <festevam@gmail.com>
imx7d-pico-pi board contains:
- One SoM board (imx7d pico)
- One base board (pi).
In order to make it easier for adding support for other board variants,
move the commom SoM part to the imx7d-pico.dtsi file.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
Changes in v2: None
arch/arm/boot/dts/imx7d-pico-pi.dts | 116 ++--------------------------
arch/arm/boot/dts/imx7d-pico.dtsi | 111 +++++++++++++++++++++++++-
2 files changed, 113 insertions(+), 114 deletions(-)
diff --git a/arch/arm/boot/dts/imx7d-pico-pi.dts b/arch/arm/boot/dts/imx7d-pico-pi.dts
index 33951f4c7f41..039c17066fe0 100644
--- a/arch/arm/boot/dts/imx7d-pico-pi.dts
+++ b/arch/arm/boot/dts/imx7d-pico-pi.dts
@@ -5,6 +5,9 @@
#include "imx7d-pico.dtsi"
/ {
+ model = "TechNexion PICO-IMX7D Board and PI baseboard";
+ compatible = "technexion,imx7d-pico-pi", "fsl,imx7d";
+
sound {
compatible = "simple-audio-card";
simple-audio-card,name = "imx7-sgtl5000";
@@ -16,43 +19,14 @@
};
dailink_master: simple-audio-card,codec {
- sound-dai = <&codec>;
+ sound-dai = <&sgtl5000>;
clocks = <&clks IMX7D_AUDIO_MCLK_ROOT_CLK>;
};
};
};
-&fec1 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_enet1>;
- assigned-clocks = <&clks IMX7D_ENET1_TIME_ROOT_SRC>,
- <&clks IMX7D_ENET1_TIME_ROOT_CLK>;
- assigned-clock-parents = <&clks IMX7D_PLL_ENET_MAIN_100M_CLK>;
- assigned-clock-rates = <0>, <100000000>;
- phy-mode = "rgmii";
- phy-handle = <ðphy0>;
- fsl,magic-packet;
- status = "okay";
-
- mdio {
- #address-cells = <1>;
- #size-cells = <0>;
-
- ethphy0: ethernet-phy@1 {
- compatible = "ethernet-phy-ieee802.3-c22";
- reg = <1>;
- status = "okay";
- };
- };
-};
-
&i2c1 {
- clock-frequency = <100000>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c1>;
- status = "okay";
-
- codec: sgtl5000@a {
+ sgtl5000: codec@a {
#sound-dai-cells = <0>;
reg = <0x0a>;
compatible = "fsl,sgtl5000";
@@ -61,83 +35,3 @@
VDDIO-supply = <®_vref_1v8>;
};
};
-
-
-&sai1 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_sai1>;
- assigned-clocks = <&clks IMX7D_SAI1_ROOT_SRC>,
- <&clks IMX7D_SAI1_ROOT_CLK>;
- assigned-clock-parents = <&clks IMX7D_PLL_AUDIO_POST_DIV>;
- assigned-clock-rates = <0>, <24576000>;
- status = "okay";
-};
-
-&uart5 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_uart5>;
- assigned-clocks = <&clks IMX7D_UART5_ROOT_SRC>;
- assigned-clock-parents = <&clks IMX7D_PLL_SYS_MAIN_240M_CLK>;
- status = "okay";
-};
-
-&usbotg1 {
- vbus-supply = <®_usb_otg1_vbus>;
- status = "okay";
-};
-
-&usbotg2 {
- vbus-supply = <®_usb_otg2_vbus>;
- dr_mode = "host";
- status = "okay";
-};
-
-&iomuxc {
- pinctrl_enet1: enet1grp {
- fsl,pins = <
- MX7D_PAD_SD2_CD_B__ENET1_MDIO 0x3
- MX7D_PAD_SD2_WP__ENET1_MDC 0x3
- MX7D_PAD_ENET1_RGMII_TXC__ENET1_RGMII_TXC 0x1
- MX7D_PAD_ENET1_RGMII_TD0__ENET1_RGMII_TD0 0x1
- MX7D_PAD_ENET1_RGMII_TD1__ENET1_RGMII_TD1 0x1
- MX7D_PAD_ENET1_RGMII_TD2__ENET1_RGMII_TD2 0x1
- MX7D_PAD_ENET1_RGMII_TD3__ENET1_RGMII_TD3 0x1
- MX7D_PAD_ENET1_RGMII_TX_CTL__ENET1_RGMII_TX_CTL 0x1
- MX7D_PAD_ENET1_RGMII_RXC__ENET1_RGMII_RXC 0x1
- MX7D_PAD_ENET1_RGMII_RD0__ENET1_RGMII_RD0 0x1
- MX7D_PAD_ENET1_RGMII_RD1__ENET1_RGMII_RD1 0x1
- MX7D_PAD_ENET1_RGMII_RD2__ENET1_RGMII_RD2 0x1
- MX7D_PAD_ENET1_RGMII_RD3__ENET1_RGMII_RD3 0x1
- MX7D_PAD_ENET1_RGMII_RX_CTL__ENET1_RGMII_RX_CTL 0x1
- >;
- };
-
- pinctrl_i2c1: i2c1grp {
- fsl,pins = <
- MX7D_PAD_UART1_TX_DATA__I2C1_SDA 0x4000007f
- MX7D_PAD_UART1_RX_DATA__I2C1_SCL 0x4000007f
- >;
- };
-
- pinctrl_sai1: sai1grp {
- fsl,pins = <
- MX7D_PAD_ENET1_RX_CLK__SAI1_TX_BCLK 0x1f
- MX7D_PAD_ENET1_CRS__SAI1_TX_SYNC 0x1f
- MX7D_PAD_ENET1_COL__SAI1_TX_DATA0 0x30
- MX7D_PAD_ENET1_TX_CLK__SAI1_RX_DATA0 0x1f
- >;
- };
-
- pinctrl_uart5: uart5grp {
- fsl,pins = <
- MX7D_PAD_I2C4_SDA__UART5_DCE_TX 0x79
- MX7D_PAD_I2C4_SCL__UART5_DCE_RX 0x79
- >;
- };
-
- pinctrl_usbotg1_pwr: usbotg_pwr {
- fsl,pins = <
- MX7D_PAD_UART3_TX_DATA__GPIO4_IO5 0x14
- >;
- };
-};
diff --git a/arch/arm/boot/dts/imx7d-pico.dtsi b/arch/arm/boot/dts/imx7d-pico.dtsi
index d957454ce16b..7319e2ecec5c 100644
--- a/arch/arm/boot/dts/imx7d-pico.dtsi
+++ b/arch/arm/boot/dts/imx7d-pico.dtsi
@@ -7,9 +7,6 @@
#include "imx7d.dtsi"
/ {
- model = "Technexion Pico i.MX7D Board";
- compatible = "technexion,imx7d-pico", "fsl,imx7d";
-
/* Will be filled by the bootloader */
memory@80000000 {
device_type = "memory";
@@ -79,6 +76,37 @@
assigned-clock-rates = <0>, <32768>;
};
+&fec1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet1>;
+ assigned-clocks = <&clks IMX7D_ENET1_TIME_ROOT_SRC>,
+ <&clks IMX7D_ENET1_TIME_ROOT_CLK>;
+ assigned-clock-parents = <&clks IMX7D_PLL_ENET_MAIN_100M_CLK>;
+ assigned-clock-rates = <0>, <100000000>;
+ phy-mode = "rgmii";
+ phy-handle = <ðphy0>;
+ fsl,magic-packet;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ status = "okay";
+ };
+ };
+};
+
+&i2c1 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ status = "okay";
+};
+
&i2c4 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c4>;
@@ -174,6 +202,35 @@
};
};
+&sai1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sai1>;
+ assigned-clocks = <&clks IMX7D_SAI1_ROOT_SRC>,
+ <&clks IMX7D_SAI1_ROOT_CLK>;
+ assigned-clock-parents = <&clks IMX7D_PLL_AUDIO_POST_DIV>;
+ assigned-clock-rates = <0>, <24576000>;
+ status = "okay";
+};
+
+&uart5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart5>;
+ assigned-clocks = <&clks IMX7D_UART5_ROOT_SRC>;
+ assigned-clock-parents = <&clks IMX7D_PLL_SYS_MAIN_240M_CLK>;
+ status = "okay";
+};
+
+&usbotg1 {
+ vbus-supply = <®_usb_otg1_vbus>;
+ status = "okay";
+};
+
+&usbotg2 {
+ vbus-supply = <®_usb_otg2_vbus>;
+ dr_mode = "host";
+ status = "okay";
+};
+
&usdhc2 { /* Wifi SDIO */
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usdhc2 &pinctrl_wifi_clk>;
@@ -208,6 +265,32 @@
};
&iomuxc {
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX7D_PAD_UART1_TX_DATA__I2C1_SDA 0x4000007f
+ MX7D_PAD_UART1_RX_DATA__I2C1_SCL 0x4000007f
+ >;
+ };
+
+ pinctrl_enet1: enet1grp {
+ fsl,pins = <
+ MX7D_PAD_SD2_CD_B__ENET1_MDIO 0x3
+ MX7D_PAD_SD2_WP__ENET1_MDC 0x3
+ MX7D_PAD_ENET1_RGMII_TXC__ENET1_RGMII_TXC 0x1
+ MX7D_PAD_ENET1_RGMII_TD0__ENET1_RGMII_TD0 0x1
+ MX7D_PAD_ENET1_RGMII_TD1__ENET1_RGMII_TD1 0x1
+ MX7D_PAD_ENET1_RGMII_TD2__ENET1_RGMII_TD2 0x1
+ MX7D_PAD_ENET1_RGMII_TD3__ENET1_RGMII_TD3 0x1
+ MX7D_PAD_ENET1_RGMII_TX_CTL__ENET1_RGMII_TX_CTL 0x1
+ MX7D_PAD_ENET1_RGMII_RXC__ENET1_RGMII_RXC 0x1
+ MX7D_PAD_ENET1_RGMII_RD0__ENET1_RGMII_RD0 0x1
+ MX7D_PAD_ENET1_RGMII_RD1__ENET1_RGMII_RD1 0x1
+ MX7D_PAD_ENET1_RGMII_RD2__ENET1_RGMII_RD2 0x1
+ MX7D_PAD_ENET1_RGMII_RD3__ENET1_RGMII_RD3 0x1
+ MX7D_PAD_ENET1_RGMII_RX_CTL__ENET1_RGMII_RX_CTL 0x1
+ >;
+ };
+
pinctrl_i2c4: i2c4grp {
fsl,pins = <
MX7D_PAD_SAI1_RX_BCLK__I2C4_SDA 0x4000007f
@@ -221,6 +304,28 @@
>;
};
+ pinctrl_sai1: sai1grp {
+ fsl,pins = <
+ MX7D_PAD_ENET1_RX_CLK__SAI1_TX_BCLK 0x1f
+ MX7D_PAD_ENET1_CRS__SAI1_TX_SYNC 0x1f
+ MX7D_PAD_ENET1_COL__SAI1_TX_DATA0 0x30
+ MX7D_PAD_ENET1_TX_CLK__SAI1_RX_DATA0 0x1f
+ >;
+ };
+
+ pinctrl_uart5: uart5grp {
+ fsl,pins = <
+ MX7D_PAD_I2C4_SDA__UART5_DCE_TX 0x79
+ MX7D_PAD_I2C4_SCL__UART5_DCE_RX 0x79
+ >;
+ };
+
+ pinctrl_usbotg1_pwr: usbotg_pwr {
+ fsl,pins = <
+ MX7D_PAD_UART3_TX_DATA__GPIO4_IO5 0x14
+ >;
+ };
+
pinctrl_usdhc2: usdhc2grp {
fsl,pins = <
MX7D_PAD_SD2_CMD__SD2_CMD 0x59
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 4/9] ARM: dts: imx7d-pico: Pass the USBOTG1_PWR pinctrl
From: Otavio Salvador @ 2018-12-06 10:09 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, devicetree, Otavio Salvador, Shawn Guo,
Sascha Hauer, linux-kernel, Rob Herring, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam, Fabio Estevam
In-Reply-To: <20181206100905.15053-1-otavio@ossystems.com.br>
From: Fabio Estevam <festevam@gmail.com>
Pass the USBOTG1_PWR pinctrl description in the USBOTG GPIO
controlled regulator.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
Changes in v2: None
arch/arm/boot/dts/imx7d-pico.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/imx7d-pico.dtsi b/arch/arm/boot/dts/imx7d-pico.dtsi
index 7319e2ecec5c..cb30bded1e4a 100644
--- a/arch/arm/boot/dts/imx7d-pico.dtsi
+++ b/arch/arm/boot/dts/imx7d-pico.dtsi
@@ -41,6 +41,8 @@
};
reg_usb_otg1_vbus: regulator-usb-otg1-vbus {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg1_pwr>;
compatible = "regulator-fixed";
regulator-name = "usb_otg1_vbus";
regulator-min-microvolt = <5000000>;
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v4 2/3] mm: Add support for kmem caches in DMA32 zone
From: Nicolas Boichat @ 2018-12-06 10:09 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Michal Hocko, Will Deacon, Levin Alexander, linux-mm,
Christoph Lameter, Huaisheng Ye, Joerg Roedel, Matthew Wilcox,
hch, linux-arm Mailing List, David Rientjes, yingjoe.chen,
Tomasz Figa, Mike Rapoport, Matthias Brugger, Joonsoo Kim,
Yong Wu, Robin Murphy, lkml, Pekka Enberg, iommu, Andrew Morton,
Mel Gorman
In-Reply-To: <09f56edb-2dab-c023-2164-dd7b5cef6afb@suse.cz>
On Thu, Dec 6, 2018 at 5:37 PM Vlastimil Babka <vbabka@suse.cz> wrote:
>
> On 12/6/18 4:49 AM, Nicolas Boichat wrote:
> >> So it would be fine even unchanged. The check would anyway need some
> >> more love to catch the same with __GFP_DMA to be consistent and cover
> >> all corner cases.
> > Yes, the test is not complete. If we really wanted this to be
> > accurate, we'd need to check that GFP_* exactly matches SLAB_CACHE_*.
> >
> > The only problem with dropping this is test that we should restore
> > GFP_DMA32 warning/errors somewhere else (as Christopher pointed out
> > here: https://lkml.org/lkml/2018/11/22/430), especially for kmalloc
> > case.
>
> I meant just dropping that patch hunk, not the whole test. Then the test
> stays as it is and will keep warning anyone calling kmalloc(GFP_DMA32).
> It would also warn anyone calling kmem_cache_alloc(GFP_DMA32) on
> SLAB_CACHE_DMA32 cache, but since the gfp can be just dropped, and you
> as the only user of this so far will do that, it's fine?
I missed your point, this would work fine indeed.
Thanks.
> > Maybe this can be done in kmalloc_slab.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 5/9] ARM: dts: imx7d-pico: Pass the Ethernet PHY reset GPIO
From: Otavio Salvador @ 2018-12-06 10:09 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, devicetree, Otavio Salvador, Shawn Guo,
Sascha Hauer, linux-kernel, Rob Herring, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam, Fabio Estevam
In-Reply-To: <20181206100905.15053-1-otavio@ossystems.com.br>
From: Fabio Estevam <festevam@gmail.com>
Pass the "phy-reset-gpios" property in order to describe the GPIO
that performs the Ethernet PHY reset.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
Changes in v2: None
arch/arm/boot/dts/imx7d-pico.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/imx7d-pico.dtsi b/arch/arm/boot/dts/imx7d-pico.dtsi
index cb30bded1e4a..35791a1adabf 100644
--- a/arch/arm/boot/dts/imx7d-pico.dtsi
+++ b/arch/arm/boot/dts/imx7d-pico.dtsi
@@ -88,6 +88,7 @@
phy-mode = "rgmii";
phy-handle = <ðphy0>;
fsl,magic-packet;
+ phy-reset-gpios = <&gpio6 11 GPIO_ACTIVE_LOW>;
status = "okay";
mdio {
@@ -290,6 +291,7 @@
MX7D_PAD_ENET1_RGMII_RD2__ENET1_RGMII_RD2 0x1
MX7D_PAD_ENET1_RGMII_RD3__ENET1_RGMII_RD3 0x1
MX7D_PAD_ENET1_RGMII_RX_CTL__ENET1_RGMII_RX_CTL 0x1
+ MX7D_PAD_SD3_RESET_B__GPIO6_IO11 0x1 /* Ethernet reset */
>;
};
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 6/9] ARM: dts: imx7d-pico: Improve WiFi regulator name
From: Otavio Salvador @ 2018-12-06 10:09 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, devicetree, Otavio Salvador, Sascha Hauer,
linux-kernel, Rob Herring, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam, Shawn Guo
In-Reply-To: <20181206100905.15053-1-otavio@ossystems.com.br>
There are different models of WiFi being used in the SoM and the
handle name was too restrictive. This reworks it to a more generic and
meaningful name.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
Changes in v2: None
arch/arm/boot/dts/imx7d-pico.dtsi | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/imx7d-pico.dtsi b/arch/arm/boot/dts/imx7d-pico.dtsi
index 35791a1adabf..417f034fb354 100644
--- a/arch/arm/boot/dts/imx7d-pico.dtsi
+++ b/arch/arm/boot/dts/imx7d-pico.dtsi
@@ -13,11 +13,11 @@
reg = <0x80000000 0>;
};
- reg_ap6212: regulator-ap6212 {
+ reg_wlreg_on: regulator-wlreg_on {
compatible = "regulator-fixed";
pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_reg_ap6212>;
- regulator-name = "AP6212";
+ pinctrl-0 = <&pinctrl_reg_wlreg_on>;
+ regulator-name = "wlreg_on";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
gpio = <&gpio4 16 GPIO_ACTIVE_HIGH>;
@@ -241,7 +241,7 @@
non-removable;
keep-power-in-suspend;
wakeup-source;
- vmmc-supply = <®_ap6212>;
+ vmmc-supply = <®_wlreg_on>;
mmc-pwrseq = <&usdhc2_pwrseq>;
status = "okay";
};
@@ -302,7 +302,7 @@
>;
};
- pinctrl_reg_ap6212: regap6212grp {
+ pinctrl_reg_wlreg_on: regregongrp {
fsl,pins = <
MX7D_PAD_ECSPI1_SCLK__GPIO4_IO16 0x59
>;
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 7/9] ARM: dts: imx7d-pico: Extend peripherals support
From: Otavio Salvador @ 2018-12-06 10:09 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, devicetree, Otavio Salvador, Shawn Guo,
Sascha Hauer, linux-kernel, Rob Herring, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam, Fabio Estevam
In-Reply-To: <20181206100905.15053-1-otavio@ossystems.com.br>
From: Fabio Estevam <festevam@gmail.com>
This extends the peripherals supported by the imx7d-pico.dtsi. It
adds:
- I2C2
- Flexcan (flexcan1 and flexcan2 ports)
- USDHC1
- UART (6 and 7 ports)
- PWM (4 ports)
- eCSPI3
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
Changes in v2:
- replace fsl,uart-has-rtscts with uart-has-rtscts
arch/arm/boot/dts/imx7d-pico.dtsi | 183 ++++++++++++++++++++++++++++++
1 file changed, 183 insertions(+)
diff --git a/arch/arm/boot/dts/imx7d-pico.dtsi b/arch/arm/boot/dts/imx7d-pico.dtsi
index 417f034fb354..3fd595a71202 100644
--- a/arch/arm/boot/dts/imx7d-pico.dtsi
+++ b/arch/arm/boot/dts/imx7d-pico.dtsi
@@ -78,6 +78,13 @@
assigned-clock-rates = <0>, <32768>;
};
+&ecspi3 {
+ cs-gpios = <&gpio4 11 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi3>;
+ status = "okay";
+};
+
&fec1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet1>;
@@ -103,6 +110,18 @@
};
};
+&flexcan1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can1>;
+ status = "okay";
+};
+
+&flexcan2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can2>;
+ status = "okay";
+};
+
&i2c1 {
clock-frequency = <100000>;
pinctrl-names = "default";
@@ -110,6 +129,12 @@
status = "okay";
};
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+};
+
&i2c4 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c4>;
@@ -215,6 +240,29 @@
status = "okay";
};
+
+&pwm1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm1>;
+ status = "okay";
+};
+
+&pwm2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm2>;
+ status = "okay";
+};
+
+&pwm3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm3>;
+ status = "okay";
+};
+
+&pwm4 { /* Backlight */
+ status = "okay";
+};
+
&uart5 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart5>;
@@ -223,6 +271,24 @@
status = "okay";
};
+&uart6 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart6>;
+ assigned-clocks = <&clks IMX7D_UART6_ROOT_SRC>;
+ assigned-clock-parents = <&clks IMX7D_OSC_24M_CLK>;
+ uart-has-rtscts;
+ status = "okay";
+};
+
+&uart7 { /* Bluetooth */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart7>;
+ assigned-clocks = <&clks IMX7D_UART7_ROOT_SRC>;
+ assigned-clock-parents = <&clks IMX7D_PLL_SYS_MAIN_240M_CLK>;
+ uart-has-rtscts;
+ status = "okay";
+};
+
&usbotg1 {
vbus-supply = <®_usb_otg1_vbus>;
status = "okay";
@@ -234,6 +300,21 @@
status = "okay";
};
+&usdhc1 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+ cd-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
+ bus-width = <4>;
+ tuning-step = <2>;
+ vmmc-supply = <®_3p3v>;
+ wakeup-source;
+ no-1-8-v;
+ keep-power-in-suspend;
+ status = "okay";
+};
+
&usdhc2 { /* Wifi SDIO */
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usdhc2 &pinctrl_wifi_clk>;
@@ -268,6 +349,15 @@
};
&iomuxc {
+ pinctrl_ecspi3: ecspi3grp {
+ fsl,pins = <
+ MX7D_PAD_I2C1_SCL__ECSPI3_MISO 0x2
+ MX7D_PAD_I2C1_SDA__ECSPI3_MOSI 0x2
+ MX7D_PAD_I2C2_SCL__ECSPI3_SCLK 0x2
+ MX7D_PAD_I2C2_SDA__GPIO4_IO11 0x14
+ >;
+ };
+
pinctrl_i2c1: i2c1grp {
fsl,pins = <
MX7D_PAD_UART1_TX_DATA__I2C1_SDA 0x4000007f
@@ -275,6 +365,13 @@
>;
};
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX7D_PAD_UART2_TX_DATA__I2C2_SDA 0x4000007f
+ MX7D_PAD_UART2_RX_DATA__I2C2_SCL 0x4000007f
+ >;
+ };
+
pinctrl_enet1: enet1grp {
fsl,pins = <
MX7D_PAD_SD2_CD_B__ENET1_MDIO 0x3
@@ -295,6 +392,20 @@
>;
};
+ pinctrl_can1: can1frp {
+ fsl,pins = <
+ MX7D_PAD_SAI1_RX_DATA__FLEXCAN1_RX 0x59
+ MX7D_PAD_SAI1_TX_BCLK__FLEXCAN1_TX 0x59
+ >;
+ };
+
+ pinctrl_can2: can2frp {
+ fsl,pins = <
+ MX7D_PAD_SAI1_TX_SYNC__FLEXCAN2_RX 0x59
+ MX7D_PAD_SAI1_TX_DATA__FLEXCAN2_TX 0x59
+ >;
+ };
+
pinctrl_i2c4: i2c4grp {
fsl,pins = <
MX7D_PAD_SAI1_RX_BCLK__I2C4_SDA 0x4000007f
@@ -302,6 +413,24 @@
>;
};
+ pinctrl_pwm1: pwm1 {
+ fsl,pins = <
+ MX7D_PAD_GPIO1_IO08__PWM1_OUT 0x7f
+ >;
+ };
+
+ pinctrl_pwm2: pwm2 {
+ fsl,pins = <
+ MX7D_PAD_GPIO1_IO09__PWM2_OUT 0x7f
+ >;
+ };
+
+ pinctrl_pwm3: pwm3 {
+ fsl,pins = <
+ MX7D_PAD_GPIO1_IO10__PWM3_OUT 0x7f
+ >;
+ };
+
pinctrl_reg_wlreg_on: regregongrp {
fsl,pins = <
MX7D_PAD_ECSPI1_SCLK__GPIO4_IO16 0x59
@@ -324,12 +453,66 @@
>;
};
+ pinctrl_uart6: uart6grp {
+ fsl,pins = <
+ MX7D_PAD_EPDC_DATA08__UART6_DCE_RX 0x79
+ MX7D_PAD_EPDC_DATA09__UART6_DCE_TX 0x79
+ MX7D_PAD_EPDC_DATA10__UART6_DCE_RTS 0x79
+ MX7D_PAD_EPDC_DATA11__UART6_DCE_CTS 0x79
+ >;
+ };
+
+ pinctrl_uart7: uart7grp {
+ fsl,pins = <
+ MX7D_PAD_ECSPI2_MOSI__UART7_DCE_TX 0x79
+ MX7D_PAD_ECSPI2_SCLK__UART7_DCE_RX 0x79
+ MX7D_PAD_ECSPI2_SS0__UART7_DCE_CTS 0x79
+ MX7D_PAD_ECSPI2_MISO__UART7_DCE_RTS 0x79
+ >;
+ };
+
pinctrl_usbotg1_pwr: usbotg_pwr {
fsl,pins = <
MX7D_PAD_UART3_TX_DATA__GPIO4_IO5 0x14
>;
};
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX7D_PAD_SD1_CMD__SD1_CMD 0x59
+ MX7D_PAD_SD1_CLK__SD1_CLK 0x19
+ MX7D_PAD_SD1_DATA0__SD1_DATA0 0x59
+ MX7D_PAD_SD1_DATA1__SD1_DATA1 0x59
+ MX7D_PAD_SD1_DATA2__SD1_DATA2 0x59
+ MX7D_PAD_SD1_DATA3__SD1_DATA3 0x59
+ MX7D_PAD_SD1_CD_B__GPIO5_IO0 0x15
+ >;
+ };
+
+ pinctrl_usdhc1_100mhz: usdhc1grp_100mhz {
+ fsl,pins = <
+ MX7D_PAD_SD1_CMD__SD1_CMD 0x5a
+ MX7D_PAD_SD1_CLK__SD1_CLK 0x1a
+ MX7D_PAD_SD1_DATA0__SD1_DATA0 0x5a
+ MX7D_PAD_SD1_DATA1__SD1_DATA1 0x5a
+ MX7D_PAD_SD1_DATA2__SD1_DATA2 0x5a
+ MX7D_PAD_SD1_DATA3__SD1_DATA3 0x5a
+ MX7D_PAD_SD1_CD_B__GPIO5_IO0 0x15
+ >;
+ };
+
+ pinctrl_usdhc1_200mhz: usdhc1grp_200mhz {
+ fsl,pins = <
+ MX7D_PAD_SD1_CMD__SD1_CMD 0x5b
+ MX7D_PAD_SD1_CLK__SD1_CLK 0x1b
+ MX7D_PAD_SD1_DATA0__SD1_DATA0 0x5b
+ MX7D_PAD_SD1_DATA1__SD1_DATA1 0x5b
+ MX7D_PAD_SD1_DATA2__SD1_DATA2 0x5b
+ MX7D_PAD_SD1_DATA3__SD1_DATA3 0x5b
+ MX7D_PAD_SD1_CD_B__GPIO5_IO0 0x15
+ >;
+ };
+
pinctrl_usdhc2: usdhc2grp {
fsl,pins = <
MX7D_PAD_SD2_CMD__SD2_CMD 0x59
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
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