Re: [PATCH v4 4/4] pinctrl: add rsel setting on MT8195
On Mon, Apr 12, 2021 at 10:57 PM Zhiyong Tao wrote: > @@ -176,6 +180,12 @@ static int mtk_pinconf_get(struct pinctrl_dev *pctldev, > else > err = -ENOTSUPP; > break; > + case MTK_PIN_CONFIG_RSEL: > + if (hw->soc->rsel_get) > + err = hw->soc->rsel_get(hw, desc, ); > + else > + err = -EOPNOTSUPP; I think that should want to be -ENOTSUPP to align other occurrences. > + break; > default: > err = -ENOTSUPP; > } > @@ -295,6 +305,12 @@ static int mtk_pinconf_set(struct pinctrl_dev *pctldev, > unsigned int pin, > else > err = -ENOTSUPP; > break; > + case MTK_PIN_CONFIG_RSEL: > + if (hw->soc->rsel_set) > + err = hw->soc->rsel_set(hw, desc, arg); > + else > + err = -EOPNOTSUPP; Ditto > + break; > default: > err = -ENOTSUPP; > } > -- > 2.18.0 >
Re: [PATCH v4 3/4] pinctrl: add drive for I2C related pins on MT8195
On Mon, Apr 12, 2021 at 10:57 PM Zhiyong Tao wrote:
>
> This patch provides the advanced drive raw data setting version
> for I2C used pins on MT8195.
>
> Signed-off-by: Zhiyong Tao
Acked-by: Sean Wang
> ---
> drivers/pinctrl/mediatek/pinctrl-mt8195.c | 22 +++
> .../pinctrl/mediatek/pinctrl-mtk-common-v2.c | 14
> .../pinctrl/mediatek/pinctrl-mtk-common-v2.h | 5 +
> 3 files changed, 41 insertions(+)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8195.c
> b/drivers/pinctrl/mediatek/pinctrl-mt8195.c
> index 063f164d7c9b..a7500e18bb1d 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mt8195.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mt8195.c
> @@ -760,6 +760,25 @@ static const struct mtk_pin_field_calc
> mt8195_pin_drv_range[] = {
> PIN_FIELD_BASE(143, 143, 1, 0x020, 0x10, 24, 3),
> };
>
> +static const struct mtk_pin_field_calc mt8195_pin_drv_adv_range[] = {
> + PIN_FIELD_BASE(8, 8, 4, 0x020, 0x10, 15, 3),
> + PIN_FIELD_BASE(9, 9, 4, 0x020, 0x10, 0, 3),
> + PIN_FIELD_BASE(10, 10, 4, 0x020, 0x10, 18, 3),
> + PIN_FIELD_BASE(11, 11, 4, 0x020, 0x10, 3, 3),
> + PIN_FIELD_BASE(12, 12, 4, 0x020, 0x10, 21, 3),
> + PIN_FIELD_BASE(13, 13, 4, 0x020, 0x10, 6, 3),
> + PIN_FIELD_BASE(14, 14, 4, 0x020, 0x10, 24, 3),
> + PIN_FIELD_BASE(15, 15, 4, 0x020, 0x10, 9, 3),
> + PIN_FIELD_BASE(16, 16, 4, 0x020, 0x10, 27, 3),
> + PIN_FIELD_BASE(17, 17, 4, 0x020, 0x10, 12, 3),
> + PIN_FIELD_BASE(29, 29, 2, 0x020, 0x10, 0, 3),
> + PIN_FIELD_BASE(30, 30, 2, 0x020, 0x10, 3, 3),
> + PIN_FIELD_BASE(34, 34, 1, 0x040, 0x10, 0, 3),
> + PIN_FIELD_BASE(35, 35, 1, 0x040, 0x10, 3, 3),
> + PIN_FIELD_BASE(44, 44, 1, 0x040, 0x10, 6, 3),
> + PIN_FIELD_BASE(45, 45, 1, 0x040, 0x10, 9, 3),
> +};
> +
> static const struct mtk_pin_reg_calc mt8195_reg_cals[PINCTRL_PIN_REG_MAX] = {
> [PINCTRL_PIN_REG_MODE] = MTK_RANGE(mt8195_pin_mode_range),
> [PINCTRL_PIN_REG_DIR] = MTK_RANGE(mt8195_pin_dir_range),
> @@ -773,6 +792,7 @@ static const struct mtk_pin_reg_calc
> mt8195_reg_cals[PINCTRL_PIN_REG_MAX] = {
> [PINCTRL_PIN_REG_PUPD] = MTK_RANGE(mt8195_pin_pupd_range),
> [PINCTRL_PIN_REG_R0] = MTK_RANGE(mt8195_pin_r0_range),
> [PINCTRL_PIN_REG_R1] = MTK_RANGE(mt8195_pin_r1_range),
> + [PINCTRL_PIN_REG_DRV_ADV] = MTK_RANGE(mt8195_pin_drv_adv_range),
> };
>
> static const char * const mt8195_pinctrl_register_base_names[] = {
> @@ -801,6 +821,8 @@ static const struct mtk_pin_soc mt8195_data = {
> .bias_get_combo = mtk_pinconf_bias_get_combo,
> .drive_set = mtk_pinconf_drive_set_rev1,
> .drive_get = mtk_pinconf_drive_get_rev1,
> + .adv_drive_get = mtk_pinconf_adv_drive_get_raw,
> + .adv_drive_set = mtk_pinconf_adv_drive_set_raw,
> };
>
> static const struct of_device_id mt8195_pinctrl_of_match[] = {
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> index 72f17f26acd8..2b51f4a9b860 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> @@ -1027,6 +1027,20 @@ int mtk_pinconf_adv_drive_get(struct mtk_pinctrl *hw,
> }
> EXPORT_SYMBOL_GPL(mtk_pinconf_adv_drive_get);
>
> +int mtk_pinconf_adv_drive_set_raw(struct mtk_pinctrl *hw,
> + const struct mtk_pin_desc *desc, u32 arg)
> +{
> + return mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_DRV_ADV, arg);
> +}
> +EXPORT_SYMBOL_GPL(mtk_pinconf_adv_drive_set_raw);
> +
> +int mtk_pinconf_adv_drive_get_raw(struct mtk_pinctrl *hw,
> + const struct mtk_pin_desc *desc, u32 *val)
> +{
> + return mtk_hw_get_value(hw, desc, PINCTRL_PIN_REG_DRV_ADV, val);
> +}
> +EXPORT_SYMBOL_GPL(mtk_pinconf_adv_drive_get_raw);
> +
> MODULE_LICENSE("GPL v2");
> MODULE_AUTHOR("Sean Wang ");
> MODULE_DESCRIPTION("Pin configuration library module for mediatek SoCs");
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
> b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
> index e2aae285b5fc..fd5ce9c5dcbd 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
> @@ -66,6 +66,7 @@ enum {
> PINCTRL_PIN_REG_DRV_EN,
> PINCTRL_PIN_REG_DRV_E0,
> PINCTRL_PIN_REG_DRV_E1,
> + PINCTRL_PIN_REG_DRV_ADV,
> PINCTRL_PIN_REG_MAX,
> };
>
> @@ -314,6 +315,10 @@ int mtk_pinconf_adv_drive_set(struct mtk_pinctrl *hw,
> const struct mtk_pin_desc *desc, u3
Re: [PATCH v4 2/4] pinctrl: add pinctrl driver on mt8195
On Mon, Apr 12, 2021 at 10:57 PM Zhiyong Tao wrote:
>
> This commit includes pinctrl driver for mt8195.
>
> Signed-off-by: Zhiyong Tao
Acked-by: Sean Wang
> ---
> drivers/pinctrl/mediatek/Kconfig |6 +
> drivers/pinctrl/mediatek/Makefile |1 +
> drivers/pinctrl/mediatek/pinctrl-mt8195.c | 828
> drivers/pinctrl/mediatek/pinctrl-mtk-mt8195.h | 1669 +
> 4 files changed, 2504 insertions(+)
> create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt8195.c
> create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt8195.h
>
> diff --git a/drivers/pinctrl/mediatek/Kconfig
> b/drivers/pinctrl/mediatek/Kconfig
> index eef17f228669..90f0c8255eaf 100644
> --- a/drivers/pinctrl/mediatek/Kconfig
> +++ b/drivers/pinctrl/mediatek/Kconfig
> @@ -147,6 +147,12 @@ config PINCTRL_MT8192
> default ARM64 && ARCH_MEDIATEK
> select PINCTRL_MTK_PARIS
>
> +config PINCTRL_MT8195
> + bool "Mediatek MT8195 pin control"
> + depends on OF
> + depends on ARM64 || COMPILE_TEST
> + select PINCTRL_MTK_PARIS
> +
> config PINCTRL_MT8516
> bool "Mediatek MT8516 pin control"
> depends on OF
> diff --git a/drivers/pinctrl/mediatek/Makefile
> b/drivers/pinctrl/mediatek/Makefile
> index 01218bf4dc30..06fde993ace2 100644
> --- a/drivers/pinctrl/mediatek/Makefile
> +++ b/drivers/pinctrl/mediatek/Makefile
> @@ -21,5 +21,6 @@ obj-$(CONFIG_PINCTRL_MT8167) += pinctrl-mt8167.o
> obj-$(CONFIG_PINCTRL_MT8173) += pinctrl-mt8173.o
> obj-$(CONFIG_PINCTRL_MT8183) += pinctrl-mt8183.o
> obj-$(CONFIG_PINCTRL_MT8192) += pinctrl-mt8192.o
> +obj-$(CONFIG_PINCTRL_MT8195)+= pinctrl-mt8195.o
> obj-$(CONFIG_PINCTRL_MT8516) += pinctrl-mt8516.o
> obj-$(CONFIG_PINCTRL_MT6397) += pinctrl-mt6397.o
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8195.c
> b/drivers/pinctrl/mediatek/pinctrl-mt8195.c
> new file mode 100644
> index ..063f164d7c9b
> --- /dev/null
> +++ b/drivers/pinctrl/mediatek/pinctrl-mt8195.c
> @@ -0,0 +1,828 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2020 MediaTek Inc.
> + *
> + * Author: Zhiyong Tao
> + *
> + */
> +
> +#include "pinctrl-mtk-mt8195.h"
> +#include "pinctrl-paris.h"
> +
> +/* MT8195 have multiple bases to program pin configuration listed as the
> below:
> + * iocfg[0]:0x10005000, iocfg[1]:0x11d1, iocfg[2]:0x11d3,
> + * iocfg[3]:0x11d4, iocfg[4]:0x11e2, iocfg[5]:0x11eb,
> + * iocfg[6]:0x11f4.
> + * _i_based could be used to indicate what base the pin should be mapped
> into.
> + */
> +
> +#define PIN_FIELD_BASE(s_pin, e_pin, i_base, s_addr, x_addrs, s_bit, x_bits)
> \
> + PIN_FIELD_CALC(s_pin, e_pin, i_base, s_addr, x_addrs, s_bit, x_bits, \
> + 32, 0)
> +
> +#define PINS_FIELD_BASE(s_pin, e_pin, i_base, s_addr, x_addrs, s_bit,
> x_bits) \
> + PIN_FIELD_CALC(s_pin, e_pin, i_base, s_addr, x_addrs, s_bit, x_bits,
> \
> + 32, 1)
> +
> +static const struct mtk_pin_field_calc mt8195_pin_mode_range[] = {
> + PIN_FIELD(0, 144, 0x300, 0x10, 0, 4),
> +};
> +
> +static const struct mtk_pin_field_calc mt8195_pin_dir_range[] = {
> + PIN_FIELD(0, 144, 0x0, 0x10, 0, 1),
> +};
> +
> +static const struct mtk_pin_field_calc mt8195_pin_di_range[] = {
> + PIN_FIELD(0, 144, 0x200, 0x10, 0, 1),
> +};
> +
> +static const struct mtk_pin_field_calc mt8195_pin_do_range[] = {
> + PIN_FIELD(0, 144, 0x100, 0x10, 0, 1),
> +};
> +
> +static const struct mtk_pin_field_calc mt8195_pin_ies_range[] = {
> + PIN_FIELD_BASE(0, 0, 4, 0x040, 0x10, 0, 1),
> + PIN_FIELD_BASE(1, 1, 4, 0x040, 0x10, 1, 1),
> + PIN_FIELD_BASE(2, 2, 4, 0x040, 0x10, 2, 1),
> + PIN_FIELD_BASE(3, 3, 4, 0x040, 0x10, 3, 1),
> + PIN_FIELD_BASE(4, 4, 4, 0x040, 0x10, 4, 1),
> + PIN_FIELD_BASE(5, 5, 4, 0x040, 0x10, 5, 1),
> + PIN_FIELD_BASE(6, 6, 4, 0x040, 0x10, 6, 1),
> + PIN_FIELD_BASE(7, 7, 4, 0x040, 0x10, 7, 1),
> + PIN_FIELD_BASE(8, 8, 4, 0x040, 0x10, 13, 1),
> + PIN_FIELD_BASE(9, 9, 4, 0x040, 0x10, 8, 1),
> + PIN_FIELD_BASE(10, 10, 4, 0x040, 0x10, 14, 1),
> + PIN_FIELD_BASE(11, 11, 4, 0x040, 0x10, 9, 1),
> + PIN_FIELD_BASE(12, 12, 4, 0x040, 0x10, 15, 1),
> + PIN_FIELD_BASE(13, 13, 4, 0x040, 0x10, 10, 1),
> + PIN_FIELD_BASE(14, 14, 4, 0x040, 0x10, 16, 1),
> + PIN_FIELD_BASE(15, 15, 4, 0x040, 0x10, 11, 1),
> + PIN_FIELD_BASE(16, 16, 4, 0x040, 0x10, 17, 1),
> + PIN_FIELD_BASE(17, 17, 4, 0x040, 0x10, 12,
Re: [PATCH] pinctrl: add lock in mtk_rmw function.
Hi Zhiyong,
On Fri, Mar 12, 2021 at 2:35 PM Zhiyong Tao wrote:
>
> When multiple threads operate on the same register resource
> which include multiple pin, It will make the register resource
> wrong to control. So we add lock to avoid the case.
>
> Signed-off-by: Zhiyong Tao
> ---
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 4
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h | 2 ++
> drivers/pinctrl/mediatek/pinctrl-paris.c | 2 ++
> 3 files changed, 8 insertions(+)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> index 72f17f26acd8..fcf7c34a 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> @@ -58,10 +58,14 @@ void mtk_rmw(struct mtk_pinctrl *pctl, u8 i, u32 reg, u32
> mask, u32 set)
> {
> u32 val;
>
> + mutex_lock(>lock);
> +
> val = mtk_r32(pctl, i, reg);
> val &= ~mask;
> val |= set;
> mtk_w32(pctl, i, reg, val);
> +
> + mutex_unlock(>lock);
> }
>
> static int mtk_hw_pin_field_lookup(struct mtk_pinctrl *hw,
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
> b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
> index e2aae285b5fc..65eac708a3b3 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
> @@ -251,6 +251,8 @@ struct mtk_pinctrl {
> struct mtk_eint *eint;
> struct mtk_pinctrl_group*groups;
> const char **grp_names;
> + /* lock pin's register resource to avoid multiple threads issue*/
> + struct mutex lock;
> };
>
> void mtk_rmw(struct mtk_pinctrl *pctl, u8 i, u32 reg, u32 mask, u32 set);
> diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c
> b/drivers/pinctrl/mediatek/pinctrl-paris.c
> index da1f19288aa6..48e823f6d293 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-paris.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-paris.c
> @@ -970,6 +970,8 @@ int mtk_paris_pinctrl_probe(struct platform_device *pdev,
>
> hw->nbase = hw->soc->nbase_names;
>
> + mutex_init(>lock);
> +
Could you help add the mutex initialization into pinctrl-moore.c too?
and then the patch would look good to me.
> err = mtk_pctrl_build_state(pdev);
> if (err) {
> dev_err(>dev, "build state failed: %d\n", err);
> --
> 2.18.0
>
Re: [PATCH] pinctrl: mediatek: Fix fallback call path
On Mon, Dec 28, 2020 at 5:04 PM Hsin-Yi Wang wrote:
>
> Some SoCs, eg. mt8183, are using a pinconfig operation bias_set_combo.
> The fallback path in mtk_pinconf_adv_pull_set() should also try this
> operation.
>
> Fixes: cafe19db7751 ("pinctrl: mediatek: Backward compatible to previous
> Mediatek's bias-pull usage")
> Signed-off-by: Hsin-Yi Wang
Acked-by: Sean Wang
> ---
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> index 7aeb552d16ce9..72f17f26acd80 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> @@ -920,6 +920,10 @@ int mtk_pinconf_adv_pull_set(struct mtk_pinctrl *hw,
> err = hw->soc->bias_set(hw, desc, pullup);
> if (err)
> return err;
> + } else if (hw->soc->bias_set_combo) {
> + err = hw->soc->bias_set_combo(hw, desc, pullup, arg);
> + if (err)
> + return err;
> } else {
> return -ENOTSUPP;
> }
> --
> 2.29.2.729.g45daf8777d-goog
>
Re: [RFC 3/3] pinctl: mt7622: drop pwm ch7 as mt7622 only has 6 channels
> > mt7622 is reported by mediatek to have only 6 pwm channels > > so drop pindefines for 7th channel > > > > Signed-off-by: Frank Wunderlich > > I can merge this patch to the pinctrl tree if I get some kind of > review response from one of the Mediatek maintainers. > After confirming with the internal team, MT7622 actually does not have the 7th channel. Thanks for Frank's catchup and patch. Acked-by: Sean Wang > The rest should probably go through ARM SoC. > > Yours, > Linus Walleij
Re: [PATCH v3] pinctrl: mediatek: Free eint data on failure
On Thu, Oct 1, 2020 at 7:25 AM Enric Balletbo i Serra
wrote:
>
> The pinctrl driver can work without the EINT resource, but, if it is
> expected to have this resource but the mtk_build_eint() function fails
> after allocating their data (because can't get the resource or can't map
> the irq), the data is not freed and you end with a NULL pointer
> dereference. Fix this by freeing the data if mtk_build_eint() fails, so
> pinctrl still works and doesn't hang.
>
> This is noticeable after commit f97dbf48ca43 ("irqchip/mtk-sysirq: Convert
> to a platform driver") on MT8183 because, due this commit, the pinctrl driver
> fails to map the irq and spots the following bug:
>
> [1.947597] Unable to handle kernel NULL pointer dereference at virtual
> address 0004
> [1.956404] Mem abort info:
> [1.959203] ESR = 0x9604
> [1.962259] EC = 0x25: DABT (current EL), IL = 32 bits
> [1.967565] SET = 0, FnV = 0
> [1.970613] EA = 0, S1PTW = 0
> [1.973747] Data abort info:
> [1.976619] ISV = 0, ISS = 0x0004
> [1.980447] CM = 0, WnR = 0
> [1.983410] [0004] user address but active_mm is swapper
> [1.989759] Internal error: Oops: 9604 [#1] PREEMPT SMP
> [1.995322] Modules linked in:
> [1.998371] CPU: 7 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc1+ #44
> [2.004715] Hardware name: MediaTek krane sku176 board (DT)
> [2.010280] pstate: 6005 (nZCv daif -PAN -UAO BTYPE=--)
> [2.015850] pc : mtk_eint_set_debounce+0x48/0x1b8
> [2.020546] lr : mtk_eint_set_debounce+0x34/0x1b8
> [2.025239] sp : 80001008baa0
> [2.028544] x29: 80001008baa0 x28: ff7ff790
> [2.033847] x27: f9ec34b0 x26: f9ec3480
> [2.039150] x25: fa576410 x24: fa502800
> [2.044453] x23: 1388 x22: fa635f80
> [2.049755] x21: 0008 x20:
> [2.055058] x19: 0071 x18: 0001
> [2.060360] x17: x16:
> [2.065662] x15: facc8470 x14:
> [2.070965] x13: 0001 x12: 00c0
> [2.076267] x11: 0040 x10: 0070
> [2.081569] x9 : aec0063d24d8 x8 : fa800270
> [2.086872] x7 : x6 : 0011
> [2.092174] x5 : fa800248 x4 : fa800270
> [2.097476] x3 : 8000100c5000 x2 :
> [2.102778] x1 : x0 :
> [2.108081] Call trace:
> [2.110520] mtk_eint_set_debounce+0x48/0x1b8
> [2.114870] mtk_gpio_set_config+0x5c/0x78
> [2.118958] gpiod_set_config+0x5c/0x78
> [2.122786] gpiod_set_debounce+0x18/0x28
> [2.126789] gpio_keys_probe+0x50c/0x910
> [2.130705] platform_drv_probe+0x54/0xa8
> [2.134705] really_probe+0xe4/0x3b0
> [2.138271] driver_probe_device+0x58/0xb8
> [2.142358] device_driver_attach+0x74/0x80
> [2.146532] __driver_attach+0x58/0xe0
> [2.150274] bus_for_each_dev+0x70/0xc0
> [2.154100] driver_attach+0x24/0x30
> [2.157666] bus_add_driver+0x14c/0x1f0
> [2.161493] driver_register+0x64/0x120
> [2.165319] __platform_driver_register+0x48/0x58
> [2.170017] gpio_keys_init+0x1c/0x28
> [2.173672] do_one_initcall+0x54/0x1b4
> [2.177499] kernel_init_freeable+0x1d0/0x238
> [2.181848] kernel_init+0x14/0x118
> [2.185328] ret_from_fork+0x10/0x34
> [2.188899] Code: a9438ac1 12001266 f94006c3 121e766a (b9400421)
> [2.194991] ---[ end trace 168cf7b3324b6570 ]---
> [2.199611] Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x000b
> [2.207260] SMP: stopping secondary CPUs
> [2.211294] Kernel Offset: 0x2ebff480 from 0x80001000
> [2.217377] PHYS_OFFSET: 0xb505
> [2.221551] CPU features: 0x0240002,2188200c
> [2.225811] Memory Limit: none
> [2.228860] ---[ end Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x000b ]---
>
> Fixes: 89132dd8ffd2 ("pinctrl: mediatek: extend eint build to
> pinctrl-mtk-common-v2.c")
> Signed-off-by: Enric Balletbo i Serra
Acked-by: Sean Wang
> ---
>
> Changes in v3:
> - Really release the resource when needed. For some reason the change
> was not reflected in patch v2.
>
> Changes in v2:
> - Free the resource when needed (Sean Wang)
>
> .../pinctrl/mediatek/pinctrl-mtk-common-v2.c | 29 ++-
> 1 file changed, 22 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
>
Re: [PATCH v2] pinctrl: mediatek: Free eint data on failure
On Wed, Sep 30, 2020 at 1:47 AM Linus Walleij wrote: > > On Sun, Sep 27, 2020 at 7:57 PM Sean Wang wrote: > > > v2 seems the same with v1 or I was missing something. > > > > I just thought we call devm_ioremap_release to explicitly to free > > resource when a certain failure occurs after > > devm_ioremap_resource? > > What is the semantics around mtk_build_eint()? > mtk_build_eint is to add external interrupt function to the corresponding bound pins. mtk pinctrl driver still can work (than means probe() successfully) to keep pinctrl functional even with there is an error in mtk_build_eint. So the patch is used to explicitly free those data on failure in mtk_build_eint to let unused data is being free:ed immediately. thanks, Sean > If it is called on the probe path no explicit free:ing is > necessary: anytime probe() exits with an error code, > any devm* resources will be free:ed. > > Yours, > Linus Walleij
Re: [PATCH -next] pinctrl: mediatek: simplify the return expression of mtk_pinconf_bias_disable_set_rev1()
On Mon, Sep 21, 2020 at 6:10 AM Qinglang Miao wrote:
>
> Simplify the return expression.
>
> Signed-off-by: Qinglang Miao
Acked-by: Sean Wang
> ---
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 10 ++
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> index 2f3dfb56c..16bb15226 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> @@ -479,14 +479,8 @@ EXPORT_SYMBOL_GPL(mtk_pinconf_bias_get);
> int mtk_pinconf_bias_disable_set_rev1(struct mtk_pinctrl *hw,
> const struct mtk_pin_desc *desc)
> {
> - int err;
> -
> - err = mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_PULLEN,
> - MTK_DISABLE);
> - if (err)
> - return err;
> -
> - return 0;
> + return mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_PULLEN,
> + MTK_DISABLE);
> }
> EXPORT_SYMBOL_GPL(mtk_pinconf_bias_disable_set_rev1);
>
> --
> 2.23.0
>
Re: [PATCH v2] pinctrl: mediatek: check mtk_is_virt_gpio input parameter
On Fri, Sep 25, 2020 at 5:51 AM Hanks Chen wrote:
>
> Hi Sean & Linux & Matthias,
>
> Please kindly let me know your comments about this fixes patch.
> Thanks
>
Acked-by: Sean Wang
> Regards,
> Hanks
>
>
> On Thu, 2020-08-20 at 19:22 +0800, Hanks Chen wrote:
> > check mtk_is_virt_gpio input parameter,
> > virtual gpio need to support eint mode.
> >
> > add error handler for the ko case
> > to fix this boot fail:
> > pc : mtk_is_virt_gpio+0x20/0x38 [pinctrl_mtk_common_v2]
> > lr : mtk_gpio_get_direction+0x44/0xb0 [pinctrl_paris]
> >
> > Fixes: edd546465002 ("pinctrl: mediatek: avoid virtual gpio trying to set
> > reg")
> > Singed-off-by: Jie Yang
> > Signed-off-by: Hanks Chen
> >
> > ---
> > Changes since v1:
> > - update Singed-off-by
> > - align with pinctrl/mediatek/pinctrl-mtk-mt*.h
> >
> > ---
> > drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> > b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> > index c53e2c391e32..a485d79f51a1 100644
> > --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> > +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> > @@ -259,6 +259,10 @@ bool mtk_is_virt_gpio(struct mtk_pinctrl *hw, unsigned
> > int gpio_n)
> >
> > desc = (const struct mtk_pin_desc *)>soc->pins[gpio_n];
> >
> > + /* if the GPIO is not supported for eint mode */
> > + if (desc->eint.eint_m == NO_EINT_SUPPORT)
> > + return virt_gpio;
> > +
> > if (desc->funcs && !desc->funcs[desc->eint.eint_m].name)
> > virt_gpio = true;
> >
>
Re: [PATCH v2] pinctrl: mediatek: Free eint data on failure
Hi, Enric
v2 seems the same with v1 or I was missing something.
I just thought we call devm_ioremap_release to explicitly to free
resource when a certain failure occurs after
devm_ioremap_resource?
thanks,
Sean
On Tue, Sep 15, 2020 at 5:38 AM Enric Balletbo i Serra
wrote:
>
> Hi Linus,
>
> On 21/8/20 9:54, Enric Balletbo i Serra wrote:
> > The pinctrl driver can work without the EINT resource, but, if it is
> > expected to have this resource but the mtk_build_eint() function fails
> > after allocating their data (because can't get the resource or can't map
> > the irq), the data is not freed and you end with a NULL pointer
> > dereference. Fix this by freeing the data if mtk_build_eint() fails, so
> > pinctrl still works and doesn't hang.
> >
> > This is noticeable after commit f97dbf48ca43 ("irqchip/mtk-sysirq: Convert
> > to a platform driver") on MT8183 because, due this commit, the pinctrl
> > driver
> > fails to map the irq and spots the following bug:
> >
> > [1.947597] Unable to handle kernel NULL pointer dereference at virtual
> > address 0004
> > [1.956404] Mem abort info:
> > [1.959203] ESR = 0x9604
> > [1.962259] EC = 0x25: DABT (current EL), IL = 32 bits
> > [1.967565] SET = 0, FnV = 0
> > [1.970613] EA = 0, S1PTW = 0
> > [1.973747] Data abort info:
> > [1.976619] ISV = 0, ISS = 0x0004
> > [1.980447] CM = 0, WnR = 0
> > [1.983410] [0004] user address but active_mm is swapper
> > [1.989759] Internal error: Oops: 9604 [#1] PREEMPT SMP
> > [1.995322] Modules linked in:
> > [1.998371] CPU: 7 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc1+ #44
> > [2.004715] Hardware name: MediaTek krane sku176 board (DT)
> > [2.010280] pstate: 6005 (nZCv daif -PAN -UAO BTYPE=--)
> > [2.015850] pc : mtk_eint_set_debounce+0x48/0x1b8
> > [2.020546] lr : mtk_eint_set_debounce+0x34/0x1b8
> > [2.025239] sp : 80001008baa0
> > [2.028544] x29: 80001008baa0 x28: ff7ff790
> > [2.033847] x27: f9ec34b0 x26: f9ec3480
> > [2.039150] x25: fa576410 x24: fa502800
> > [2.044453] x23: 1388 x22: fa635f80
> > [2.049755] x21: 0008 x20:
> > [2.055058] x19: 0071 x18: 0001
> > [2.060360] x17: x16:
> > [2.065662] x15: facc8470 x14:
> > [2.070965] x13: 0001 x12: 00c0
> > [2.076267] x11: 0040 x10: 0070
> > [2.081569] x9 : aec0063d24d8 x8 : fa800270
> > [2.086872] x7 : x6 : 0011
> > [2.092174] x5 : fa800248 x4 : fa800270
> > [2.097476] x3 : 8000100c5000 x2 :
> > [2.102778] x1 : x0 :
> > [2.108081] Call trace:
> > [2.110520] mtk_eint_set_debounce+0x48/0x1b8
> > [2.114870] mtk_gpio_set_config+0x5c/0x78
> > [2.118958] gpiod_set_config+0x5c/0x78
> > [2.122786] gpiod_set_debounce+0x18/0x28
> > [2.126789] gpio_keys_probe+0x50c/0x910
> > [2.130705] platform_drv_probe+0x54/0xa8
> > [2.134705] really_probe+0xe4/0x3b0
> > [2.138271] driver_probe_device+0x58/0xb8
> > [2.142358] device_driver_attach+0x74/0x80
> > [2.146532] __driver_attach+0x58/0xe0
> > [2.150274] bus_for_each_dev+0x70/0xc0
> > [2.154100] driver_attach+0x24/0x30
> > [2.157666] bus_add_driver+0x14c/0x1f0
> > [2.161493] driver_register+0x64/0x120
> > [2.165319] __platform_driver_register+0x48/0x58
> > [2.170017] gpio_keys_init+0x1c/0x28
> > [2.173672] do_one_initcall+0x54/0x1b4
> > [2.177499] kernel_init_freeable+0x1d0/0x238
> > [2.181848] kernel_init+0x14/0x118
> > [2.185328] ret_from_fork+0x10/0x34
> > [2.188899] Code: a9438ac1 12001266 f94006c3 121e766a (b9400421)
> > [2.194991] ---[ end trace 168cf7b3324b6570 ]---
> > [2.199611] Kernel panic - not syncing: Attempted to kill init!
> > exitcode=0x000b
> > [2.207260] SMP: stopping secondary CPUs
> > [2.211294] Kernel Offset: 0x2ebff480 from 0x80001000
> > [2.217377] PHYS_OFFSET: 0xb505
> > [2.221551] CPU features: 0x0240002,2188200c
> > [2.225811] Memory Limit: none
> > [2.228860] ---[ end Kernel panic - not syncing: Attempted to kill init!
> > exitcode=0x000b ]---
Re: [PATCH v1 1/2] pinctrl: mediatek: support access registers without race-condition
Hi Light, On Thu, Aug 20, 2020 at 9:47 PM Light Hsieh wrote: > > On Wed, 2020-08-19 at 16:11 -0700, Sean Wang wrote: > > Hi Light, > > > > On Tue, Aug 18, 2020 at 1:36 AM wrote: > > > > > > From: Light Hsieh > > > > > > Some MediaTek SOC provide more control registers other than value > > > register. > > > > s/MT6765/Some MediaTek SoC/ > > > > > Generanll, a value register need read-modify-write is at offset > > > 0x0. > > > > s/Generally/Generanll/ > > > > > A corresponding SET register is at offset 0xXXX4. Write 1s' to some > > > bits > > > of SET register will set same bits in value register. > > > A corresponding CLR register is at offset 0xXXX8. Write 1s' to some > > > bits > > > of CLR register will clear same bits in value register. > > > For GPIO mode selection, MWR register is provided at offset 0xXXXC. > > > With MWR, the MSBit of GPIO mode selection field is for > > > modification-enable, > > > not for GPIO mode selection, and the remaining LSBits are for mode > > > selection. > > > Take mode selection field with 4-bits as example, to select mode 0~7 via > > > MWR register, 8~15 (instead of 0~7) shall be written to corresponding > > > mode > > > selection field. > > > When using SET/CLR/MWR registers, read-modify-write of value register is > > > not > > > necessary. This can prevent from race condition when multiple bus > > > masters > > > concurrently read-modify-write the same value register for setting > > > different > > > fields of the same value register. > > > > > > Signed-off-by: Light Hsieh > > > --- > > > drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 69 > > > ++-- > > > drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h | 2 + > > > 2 files changed, 67 insertions(+), 4 deletions(-) > > > > > > diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c > > > b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c > > > index b77b18f..51f0b53 100644 > > > --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c > > > +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c > > > @@ -18,6 +18,29 @@ > > > #include "mtk-eint.h" > > > #include "pinctrl-mtk-common-v2.h" > > > > > > +/* Some MediaTek SOC provide more control registers other than value > > > register. > > > > s/MT6765/Some MediaTek SoC/ > > Not only MT6765 provides such control registers. > Actually, many (but not all) MediaTek SoC support. > Other MediaTek SoC can enable such control according to its HW support. > > > > > > + * Generanll, a value register need read-modify-write is at offset > > > 0x0. > > > > s/Generally/Generanll/ > > > > > + * A corresponding SET register is at offset 0xXXX4. Write 1s' to > > > some bits > > > + * of SET register will set same bits in value register. > > > + * A corresponding CLR register is at offset 0xXXX8. Write 1s' to > > > some bits > > > + * of CLR register will clear same bits in value register. > > > + * For GPIO mode selection, MWR register is provided at offset > > > 0xXXXC. > > > + * With MWR, the MSBit of GPIO mode selection field is for > > > modification-enable, > > > + * not for GPIO mode selection, and the remaining LSBits are for mode > > > + * selection. > > > + * Take mode selection field with 4-bits as example, to select mode 0~7 > > > via > > > + * MWR register, 8~15 (instead of 0~7) shall be written to > > > corresponding mode > > > + * selection field. > > > + * When using SET/CLR/MWR registers, read-modify-write of value register > > > is not > > > + * necessary. This can prevent from race condition when multiple bus > > > masters > > > + * concurrently read-modify-write the same value register for setting > > > different > > > + * fields of the same value register. > > > + */ > > > + > > > +#define SET_OFFSET 0x4 > > > +#define CLR_OFFSET 0x8 > > > > can set/clr offset work for mode register? > > Yes. However, use set/clr to change mode require 2 register access when > target mode is not all 0's or all 1's. DRV/TDSEL and RDSEL register might have value not all 0's or all 1's. That s
Re: [PATCH] pinctrl: mediatek: Free eint data on failure
On Wed, Aug 19, 2020 at 9:19 AM Enric Balletbo i Serra
wrote:
>
> The pinctrl driver can work without the EINT resource, but, if it is
> expected to have this resource but the mtk_build_eint() function fails
> after allocating their data (because can't get the resource or can't map
> the irq), the data is not freed and you end with a NULL pointer
> dereference. Fix this by freeing the data if mtk_build_eint() fails, so
> pinctrl still works and doesn't hang.
>
> This is noticeable after commit f97dbf48ca43 ("irqchip/mtk-sysirq: Convert
> to a platform driver") on MT8183 because, due this commit, the pinctrl driver
> fails to map the irq and spots the following bug:
>
> [1.947597] Unable to handle kernel NULL pointer dereference at virtual
> address 0004
> [1.956404] Mem abort info:
> [1.959203] ESR = 0x9604
> [1.962259] EC = 0x25: DABT (current EL), IL = 32 bits
> [1.967565] SET = 0, FnV = 0
> [1.970613] EA = 0, S1PTW = 0
> [1.973747] Data abort info:
> [1.976619] ISV = 0, ISS = 0x0004
> [1.980447] CM = 0, WnR = 0
> [1.983410] [0004] user address but active_mm is swapper
> [1.989759] Internal error: Oops: 9604 [#1] PREEMPT SMP
> [1.995322] Modules linked in:
> [1.998371] CPU: 7 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc1+ #44
> [2.004715] Hardware name: MediaTek krane sku176 board (DT)
> [2.010280] pstate: 6005 (nZCv daif -PAN -UAO BTYPE=--)
> [2.015850] pc : mtk_eint_set_debounce+0x48/0x1b8
> [2.020546] lr : mtk_eint_set_debounce+0x34/0x1b8
> [2.025239] sp : 80001008baa0
> [2.028544] x29: 80001008baa0 x28: ff7ff790
> [2.033847] x27: f9ec34b0 x26: f9ec3480
> [2.039150] x25: fa576410 x24: fa502800
> [2.044453] x23: 1388 x22: fa635f80
> [2.049755] x21: 0008 x20:
> [2.055058] x19: 0071 x18: 0001
> [2.060360] x17: x16:
> [2.065662] x15: facc8470 x14:
> [2.070965] x13: 0001 x12: 00c0
> [2.076267] x11: 0040 x10: 0070
> [2.081569] x9 : aec0063d24d8 x8 : fa800270
> [2.086872] x7 : x6 : 0011
> [2.092174] x5 : fa800248 x4 : fa800270
> [2.097476] x3 : 8000100c5000 x2 :
> [2.102778] x1 : x0 :
> [2.108081] Call trace:
> [2.110520] mtk_eint_set_debounce+0x48/0x1b8
> [2.114870] mtk_gpio_set_config+0x5c/0x78
> [2.118958] gpiod_set_config+0x5c/0x78
> [2.122786] gpiod_set_debounce+0x18/0x28
> [2.126789] gpio_keys_probe+0x50c/0x910
> [2.130705] platform_drv_probe+0x54/0xa8
> [2.134705] really_probe+0xe4/0x3b0
> [2.138271] driver_probe_device+0x58/0xb8
> [2.142358] device_driver_attach+0x74/0x80
> [2.146532] __driver_attach+0x58/0xe0
> [2.150274] bus_for_each_dev+0x70/0xc0
> [2.154100] driver_attach+0x24/0x30
> [2.157666] bus_add_driver+0x14c/0x1f0
> [2.161493] driver_register+0x64/0x120
> [2.165319] __platform_driver_register+0x48/0x58
> [2.170017] gpio_keys_init+0x1c/0x28
> [2.173672] do_one_initcall+0x54/0x1b4
> [2.177499] kernel_init_freeable+0x1d0/0x238
> [2.181848] kernel_init+0x14/0x118
> [2.185328] ret_from_fork+0x10/0x34
> [2.188899] Code: a9438ac1 12001266 f94006c3 121e766a (b9400421)
> [2.194991] ---[ end trace 168cf7b3324b6570 ]---
> [2.199611] Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x000b
> [2.207260] SMP: stopping secondary CPUs
> [2.211294] Kernel Offset: 0x2ebff480 from 0x80001000
> [2.217377] PHYS_OFFSET: 0xb505
> [2.221551] CPU features: 0x0240002,2188200c
> [2.225811] Memory Limit: none
> [2.228860] ---[ end Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x000b ]---
>
> Fixes: 89132dd8ffd2 ("pinctrl: mediatek: extend eint build to
> pinctrl-mtk-common-v2.c")
> Signed-off-by: Enric Balletbo i Serra
> ---
>
> .../pinctrl/mediatek/pinctrl-mtk-common-v2.c | 27 ++-
> 1 file changed, 20 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> index 2f3dfb56c3fa..4b532e6b9038 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> @@ -355,6 +355,7 @@ int mtk_build_eint(struct mtk_pinctrl *hw, struct
> platform_device *pdev)
> {
> struct device_node *np = pdev->dev.of_node;
> struct resource *res;
> + int ret;
>
> if (!IS_ENABLED(CONFIG_EINT_MTK))
> return 0;
> @@ -369,19 +370,26 @@ int mtk_build_eint(struct mtk_pinctrl *hw, struct
> platform_device *pdev)
>
Re: [PATCH] pinctrl: mediatek: check mtk_is_virt_gpio input parameter
Hi Hanks,
On Thu, Aug 13, 2020 at 4:14 AM Hanks Chen wrote:
>
> check mtk_is_virt_gpio input parameter,
> virtual gpio need to support eint mode.
>
> add error handler for the ko case
> to fix this boot fail:
> pc : mtk_is_virt_gpio+0x20/0x38 [pinctrl_mtk_common_v2]
> lr : mtk_gpio_get_direction+0x44/0xb0 [pinctrl_paris]
it is better we post the complete call stack when the failure occurs
>
> Fixes: edd546465002 ("pinctrl: mediatek: avoid virtual gpio trying to set
> reg")
> Singed-off-by: sin_jieyang
signed-off-by with the full name
> Signed-off-by: Hanks Chen
> ---
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> index c53e2c391e32..27ab9c512ae1 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> @@ -259,6 +259,10 @@ bool mtk_is_virt_gpio(struct mtk_pinctrl *hw, unsigned
> int gpio_n)
>
> desc = (const struct mtk_pin_desc *)>soc->pins[gpio_n];
>
> + /* if the GPIO is not supported for eint mode */
> + if (desc->eint.eint_m == EINT_NA)
s/NO_EINT_SUPPORT/EINT_NA/ to align with pinctrl/mediatek/pinctrl-mtk-mt*.h uses
> + return virt_gpio;
> +
> if (desc->funcs && !desc->funcs[desc->eint.eint_m].name)
> virt_gpio = true;
>
> --
> 2.18.0
Re: [PATCH v1 1/2] pinctrl: mediatek: support access registers without race-condition
Hi Light,
On Tue, Aug 18, 2020 at 1:36 AM wrote:
>
> From: Light Hsieh
>
> Some MediaTek SOC provide more control registers other than value register.
s/MT6765/Some MediaTek SoC/
> Generanll, a value register need read-modify-write is at offset 0x0.
s/Generally/Generanll/
> A corresponding SET register is at offset 0xXXX4. Write 1s' to some bits
> of SET register will set same bits in value register.
> A corresponding CLR register is at offset 0xXXX8. Write 1s' to some bits
> of CLR register will clear same bits in value register.
> For GPIO mode selection, MWR register is provided at offset 0xXXXC.
> With MWR, the MSBit of GPIO mode selection field is for modification-enable,
> not for GPIO mode selection, and the remaining LSBits are for mode
> selection.
> Take mode selection field with 4-bits as example, to select mode 0~7 via
> MWR register, 8~15 (instead of 0~7) shall be written to corresponding mode
> selection field.
> When using SET/CLR/MWR registers, read-modify-write of value register is not
> necessary. This can prevent from race condition when multiple bus masters
> concurrently read-modify-write the same value register for setting different
> fields of the same value register.
>
> Signed-off-by: Light Hsieh
> ---
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 69
> ++--
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h | 2 +
> 2 files changed, 67 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> index b77b18f..51f0b53 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> @@ -18,6 +18,29 @@
> #include "mtk-eint.h"
> #include "pinctrl-mtk-common-v2.h"
>
> +/* Some MediaTek SOC provide more control registers other than value
> register.
s/MT6765/Some MediaTek SoC/
> + * Generanll, a value register need read-modify-write is at offset
> 0x0.
s/Generally/Generanll/
> + * A corresponding SET register is at offset 0xXXX4. Write 1s' to some
> bits
> + * of SET register will set same bits in value register.
> + * A corresponding CLR register is at offset 0xXXX8. Write 1s' to some
> bits
> + * of CLR register will clear same bits in value register.
> + * For GPIO mode selection, MWR register is provided at offset 0xXXXC.
> + * With MWR, the MSBit of GPIO mode selection field is for
> modification-enable,
> + * not for GPIO mode selection, and the remaining LSBits are for mode
> + * selection.
> + * Take mode selection field with 4-bits as example, to select mode 0~7 via
> + * MWR register, 8~15 (instead of 0~7) shall be written to corresponding
> mode
> + * selection field.
> + * When using SET/CLR/MWR registers, read-modify-write of value register is
> not
> + * necessary. This can prevent from race condition when multiple bus masters
> + * concurrently read-modify-write the same value register for setting
> different
> + * fields of the same value register.
> + */
> +
> +#define SET_OFFSET 0x4
> +#define CLR_OFFSET 0x8
can set/clr offset work for mode register?
> +#define MWR_OFFSET 0xC
> +
> /**
> * struct mtk_drive_desc - the structure that holds the information
> * of the driving current
> @@ -64,6 +87,38 @@ void mtk_rmw(struct mtk_pinctrl *pctl, u8 i, u32 reg, u32
> mask, u32 set)
> mtk_w32(pctl, i, reg, val);
> }
>
> +
> +static void mtk_hw_set_value_race_free(struct mtk_pinctrl *pctl,
> + struct mtk_pin_field *pf, u32 value)
s/mtk_hw_set_value_race_free/mtk_hw_w1sc/ to explictly indicate
write-one ethier set or clear operation supported by hw
> +{
> + unsigned int set, clr;
> +
> + set = value & pf->mask;
> + clr = (~set) & pf->mask;
> +
> + if (set)
> + mtk_w32(pctl, pf->index, pf->offset + SET_OFFSET,
> + set << pf->bitpos);
> + if (clr)
> + mtk_w32(pctl, pf->index, pf->offset + CLR_OFFSET,
> + clr << pf->bitpos);
> +}
> +
> +static void mtk_hw_set_mode_race_free(struct mtk_pinctrl *pctl,
> + struct mtk_pin_field *pf, u32 value)
s/mtk_hw_set_mode_race_free/mtk_hw_mwr/
> +{
> + unsigned int value_new;
> +
> + /* MSB of mask is modification-enable bit, set this bit */
> + value_new = (1 << (pctl->soc->mwr_field_width - 1)) | value;
it seems to be we can use fls(pf->mask) to replace ctl->soc->mwr_field_width
> + if (value_new == value)
> + dev_notice(pctl->dev,
> + "invalid mode 0x%x, use it by ignoring MSBit!\n",
> + value);
> + mtk_w32(pctl, pf->index, pf->offset + MWR_OFFSET,
> + value_new << pf->bitpos);
> +}
> +
> static int mtk_hw_pin_field_lookup(struct mtk_pinctrl *hw,
>const struct
Re: [PATCH 10/25] pinctrl: mediatek: pinctrl-mtk-common-v2: Mark 'mtk_default_register_base_names' as __maybe_unused
On Mon, Jul 13, 2020 at 7:49 AM Lee Jones wrote:
>
> Not all sourcefiles which end up including pinctrl-mtk-common-v2.h make use
> of 'mtk_default_register_base_names' and there is nowhere we can place the
> definition to void the need for __maybe_unused except its own headerfile,
> which seems like overkill. So instead we tell the compiler that it's okay
> for it to be unused by some of the consumers.
>
> Fixes the following W=1 kernel build warning(s):
>
> In file included from drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c:19:
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h:83:27: warning:
> ‘mtk_default_register_base_names’ defined but not used
> [-Wunused-const-variable=]
> 83 | static const char const mtk_default_register_base_names[] = {
> | ^~~
> In file included from drivers/pinctrl/mediatek/pinctrl-moore.h:25,
> from drivers/pinctrl/mediatek/pinctrl-moore.c:12:
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h:83:27: warning:
> ‘mtk_default_register_base_names’ defined but not used
> [-Wunused-const-variable=]
> 83 | static const char const mtk_default_register_base_names[] = {
> | ^~~
> In file included from drivers/pinctrl/mediatek/pinctrl-paris.h:27,
> from drivers/pinctrl/mediatek/pinctrl-paris.c:15:
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h:83:27: warning:
> ‘mtk_default_register_base_names’ defined but not used
> [-Wunused-const-variable=]
> 83 | static const char const mtk_default_register_base_names[] = {
> | ^~~
> In file included from drivers/pinctrl/mediatek/pinctrl-paris.h:27,
> from drivers/pinctrl/mediatek/pinctrl-mtk-mt6797.h:15,
> from drivers/pinctrl/mediatek/pinctrl-mt6797.c:13:
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h:83:27: warning:
> ‘mtk_default_register_base_names’ defined but not used
> [-Wunused-const-variable=]
> 83 | static const char const mtk_default_register_base_names[] = {
> | ^~~
> In file included from drivers/pinctrl/mediatek/pinctrl-paris.h:27,
> from drivers/pinctrl/mediatek/pinctrl-mtk-mt8183.h:12,
> from drivers/pinctrl/mediatek/pinctrl-mt8183.c:9:
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h:83:27: warning:
> ‘mtk_default_register_base_names’ defined but not used
> [-Wunused-const-variable=]
> 83 | static const char const mtk_default_register_base_names[] = {
> | ^~~
> In file included from drivers/pinctrl/mediatek/pinctrl-paris.h:27,
> from drivers/pinctrl/mediatek/pinctrl-mtk-mt6765.h:12,
> from drivers/pinctrl/mediatek/pinctrl-mt6765.c:10:
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h:83:27: warning:
> ‘mtk_default_register_base_names’ defined but not used
> [-Wunused-const-variable=]
> 83 | static const char const mtk_default_register_base_names[] = {
> | ^~~
>
> Cc: Sean Wang
> Cc: Matthias Brugger
> Cc: linux-media...@lists.infradead.org
> Signed-off-by: Lee Jones
Those MediaTek SoCs with multiple register bases wouldn't refer to the array
Acked-by: Sean Wang
> ---
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h | 2 +-
Re: [PATCH 3/3] pinctrl: add pinctrl driver on mt8192
On Fri, Jul 10, 2020 at 12:28 AM Zhiyong Tao wrote: > > This commit includes pinctrl driver for mt8192. > > Signed-off-by: Zhiyong Tao It is good to see the clean driver with mtk-common-v2. Acked-by: Sean Wang > --- > drivers/pinctrl/mediatek/Kconfig |7 + > drivers/pinctrl/mediatek/Makefile |1 + > drivers/pinctrl/mediatek/pinctrl-mt8192.c | 1453 +++ > drivers/pinctrl/mediatek/pinctrl-mtk-mt8192.h | 2228 + > 4 files changed, 3689 insertions(+) > create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt8192.c > create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt8192.h > > diff --git a/drivers/pinctrl/mediatek/Kconfig > b/drivers/pinctrl/mediatek/Kconfig > index f32d3644c509..8d5ffc6aa8dc 100644 > --- a/drivers/pinctrl/mediatek/Kconfig > +++ b/drivers/pinctrl/mediatek/Kconfig > @@ -121,6 +121,13 @@ config PINCTRL_MT8183 > default ARM64 && ARCH_MEDIATEK > select PINCTRL_MTK_PARIS > > +config PINCTRL_MT8192 > + bool "Mediatek MT8192 pin control" > + depends on OF > + depends on ARM64 || COMPILE_TEST > + default ARM64 && ARCH_MEDIATEK > + select PINCTRL_MTK_PARIS > +
Re: [PATCH v8 3/7] pinctrl: mediatek: avoid virtual gpio trying to set reg
On Tue, Jul 14, 2020 at 2:20 AM Hanks Chen wrote: > > for virtual gpios, they should not do reg setting and > should behave as expected for eint function. > > Signed-off-by: Mars Cheng > Signed-off-by: Hanks Chen Acked-by: Sean Wang > --- > .../pinctrl/mediatek/pinctrl-mtk-common-v2.c | 25 +++ > .../pinctrl/mediatek/pinctrl-mtk-common-v2.h | 1 + > drivers/pinctrl/mediatek/pinctrl-paris.c | 7 ++ > 3 files changed, 33 insertions(+)
Re: [PATCH v6 3/7] pinctrl: mediatek: avoid virtual gpio trying to set reg
> > Sean if you're OK with this patch I can just apply it separately. > > Ah nevermind since the next patch has your ACK I just applied this > too since it's a dependency. Yell if this is wrong. The patch looks good to me too. By the way, I didn't see those applied patches in for-next branch yet I just think Hanks should send those patch based on the top if he has the next version > > Yours, > Linus Walleij
Re: [PATCH v6 5/5] pinctrl: mediatek: Add support for pin configuration dump via debugfs.
Hi,
On Thu, Sep 26, 2019 at 10:02 PM Light Hsieh wrote:
>
> Add support for pin configuration dump via catting
> /sys/kernel/debug/pinctrl/$platform_dependent_path/pinconf-pins.
> pinctrl framework had already support such dump. This patch implement the
> operation function pointer to fullfill this dump.
>
Here are missing tags too.
> ---
> drivers/pinctrl/mediatek/pinctrl-paris.c | 88
>
> drivers/pinctrl/mediatek/pinctrl-paris.h | 30 +++
> 2 files changed, 118 insertions(+)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c
> b/drivers/pinctrl/mediatek/pinctrl-paris.c
> index 2a47c45..f531908 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-paris.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-paris.c
> @@ -538,12 +538,99 @@ static int mtk_pctrl_get_group_pins(struct pinctrl_dev
> *pctldev,
> return 0;
> }
>
> +int mtk_hw_get_value_wrap(struct mtk_pinctrl *hw, unsigned int gpio, int
> field)
> +{
> + const struct mtk_pin_desc *desc;
> + int value, err;
> +
> + if (gpio > hw->soc->npins)
> + return -EINVAL;
> +
> + desc = (const struct mtk_pin_desc *)>soc->pins[gpio];
> +
> + err = mtk_hw_get_value(hw, desc, field, );
> + if (err)
> + return err;
> +
> + return value;
> +}
> +
> +ssize_t mtk_pctrl_show_one_pin(struct mtk_pinctrl *hw,
> + unsigned int gpio, char *buf, unsigned int bufLen)
> +{
> + const struct mtk_pin_desc *desc;
> + int pinmux, pullup, pullen, r1 = -1, r0 = -1, len = 0;
Sort the variable declarations in reverse xmas tree order.
> +
> + if (gpio > hw->soc->npins)
> + return -EINVAL;
> +
> + desc = (const struct mtk_pin_desc *)>soc->pins[gpio];
> + pinmux = mtk_pctrl_get_pinmux(hw, gpio);
> + if (pinmux >= hw->soc->nfuncs)
> + pinmux -= hw->soc->nfuncs;
> +
> + mtk_pinconf_bias_get_combo(hw, desc, , );
> + if (pullen == MTK_PUPD_SET_R1R0_00) {
> + pullen = 0;
> + r1 = 0;
> + r0 = 0;
> + } else if (pullen == MTK_PUPD_SET_R1R0_01) {
> + pullen = 1;
> + r1 = 0;
> + r0 = 1;
> + } else if (pullen == MTK_PUPD_SET_R1R0_10) {
> + pullen = 1;
> + r1 = 1;
> + r0 = 0;
> + } else if (pullen == MTK_PUPD_SET_R1R0_11) {
> + pullen = 1;
> + r1 = 1;
> + r0 = 1;
> + } else if (pullen != MTK_DISABLE && pullen != MTK_ENABLE) {
> + pullen = 0;
> + }
> + len += snprintf(buf + len, bufLen - len,
> + "%03d: %1d%1d%1d%1d%02d%1d%1d%1d%1d",
> + gpio,
> + pinmux,
> + mtk_pctrl_get_direction(hw, gpio),
> + mtk_pctrl_get_out(hw, gpio),
> + mtk_pctrl_get_in(hw, gpio),
> + mtk_pctrl_get_driving(hw, gpio),
> + mtk_pctrl_get_smt(hw, gpio),
> + mtk_pctrl_get_ies(hw, gpio),
> + pullen,
> + pullup);
> +
> + if (r1 != -1) {
> + len += snprintf(buf + len, bufLen - len, " (%1d %1d)\n",
> + r1, r0);
> + } else {
> + len += snprintf(buf + len, bufLen - len, "\n");
> + }
> +
> + return len;
> +}
> +
> +#define PIN_DBG_BUF_SZ 96
> +static void mtk_pctrl_dbg_show(struct pinctrl_dev *pctldev, struct seq_file
> *s,
> + unsigned int gpio)
> +{
> + struct mtk_pinctrl *hw = pinctrl_dev_get_drvdata(pctldev);
> + char buf[PIN_DBG_BUF_SZ];
> +
> + (void)mtk_pctrl_show_one_pin(hw, gpio, buf, PIN_DBG_BUF_SZ);
> +
> + seq_printf(s, "%s", buf);
> +}
> +
> static const struct pinctrl_ops mtk_pctlops = {
> .dt_node_to_map = mtk_pctrl_dt_node_to_map,
> .dt_free_map= pinctrl_utils_free_map,
> .get_groups_count = mtk_pctrl_get_groups_count,
> .get_group_name = mtk_pctrl_get_group_name,
> .get_group_pins = mtk_pctrl_get_group_pins,
> + .pin_dbg_show = mtk_pctrl_dbg_show,
> };
>
> static int mtk_pmx_get_funcs_cnt(struct pinctrl_dev *pctldev)
> @@ -640,6 +727,7 @@ static int mtk_pconf_group_set(struct pinctrl_dev
> *pctldev, unsigned group,
> .pin_config_get = mtk_pinconf_get,
> .pin_config_group_get = mtk_pconf_group_get,
> .pin_config_group_set = mtk_pconf_group_set,
> + .is_generic = true,
> };
>
> static struct pinctrl_desc mtk_desc = {
> diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.h
> b/drivers/pinctrl/mediatek/pinctrl-paris.h
> index 3d43771..d73f4b6 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-paris.h
> +++ b/drivers/pinctrl/mediatek/pinctrl-paris.h
> @@ -60,6 +60,36 @@
> int mtk_paris_pinctrl_probe(struct
Re: [PATCH v6 4/5] pinctrl: mediatek: Backward compatible to previous Mediatek's bias-pull usage
Hi,
On Thu, Sep 26, 2019 at 10:02 PM Light Hsieh wrote:
>
> Refine mtk_pinconf_set()/mtk_pinconf_get() for backward compatibility to
> previous Mediatek's bias-pull usage.
MediaTek
> In PINCTRL_MTK that use pinctrl-mtk-common.c, bias-pull setting for pins
> with 2 pull resistors can be specified as value for bias-pull-up and
> bias-pull-down. For example:
> bias-pull-up = ;
> bias-pull-up = ;
> bias-pull-up = ;
> bias-pull-up = ;
> bias-pull-down = ;
> bias-pull-down = ;
> bias-pull-down = ;
> bias-pull-down = ;
>
> On the other hand, PINCTRL_MTK_PARIS use customized properties
> "mediatek,pull-up-adv" and "mediatek,pull-down-adv" to specify bias-pull
> setting for pins with 2 pull resistors.
> This introduce in-compatibility in device tree and increatse porting
s/increatse/inscrease/
> effort to Mediatek's customer that had already used PINCTRL_MTK version.
s/Mediatek/MediaTek/
> Besides, if customers are not awared of this change and still write devicetree
s/awared/aware/
> for PINCTRL_MTK version, they may encounter runtime failure with pinctrl and
> spent time to debug.
>
> This patch add backward compatible to previous Mediatek's bias-pull usage
s/add/adds
> so that Mediatek's customer need not use a new devicetree property name.
s/Mediatek/MediaTek/
> The rationale is that: changing driver implemenation had better leave
s/implemenation/implementation/
> interface unchanged.
>
There are many tags missing here too.
> ---
> drivers/pinctrl/mediatek/pinctrl-mt6765.c| 6 +-
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 285
> +++
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h | 11 +
> drivers/pinctrl/mediatek/pinctrl-paris.c | 49 ++--
> 4 files changed, 327 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mt6765.c
> b/drivers/pinctrl/mediatek/pinctrl-mt6765.c
> index bada37f..ae85fdc 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mt6765.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mt6765.c
> @@ -1072,10 +1072,8 @@
> .gpio_m = 0,
> .base_names = mt6765_pinctrl_register_base_names,
> .nbase_names = ARRAY_SIZE(mt6765_pinctrl_register_base_names),
> - .bias_disable_set = mtk_pinconf_bias_disable_set,
> - .bias_disable_get = mtk_pinconf_bias_disable_get,
> - .bias_set = mtk_pinconf_bias_set,
> - .bias_get = mtk_pinconf_bias_get,
> + .bias_set_combo = mtk_pinconf_bias_set_combo,
> + .bias_get_combo = mtk_pinconf_bias_get_combo,
> .drive_set = mtk_pinconf_drive_set_direct_val,
> .drive_get = mtk_pinconf_drive_get_direct_val,
> .adv_pull_get = mtk_pinconf_adv_pull_get,
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> index acfddf9..6d9972f 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> @@ -13,6 +13,8 @@
> #include
> #include
>
> +#include
> +
List the header declarations in alphabetic order.
> #include "mtk-eint.h"
> #include "pinctrl-mtk-common-v2.h"
>
> @@ -206,6 +208,20 @@ int mtk_hw_set_value(struct mtk_pinctrl *hw, const
> struct mtk_pin_desc *desc,
> return 0;
> }
>
> +void mtk_hw_set_value_no_lookup(struct mtk_pinctrl *hw,
> + const struct mtk_pin_desc *desc,
> + int value, struct mtk_pin_field *pf)
> +{
> + if (value < 0 || value > pf->mask)
> + return;
> +
> + if (!pf->next)
> + mtk_rmw(hw, pf->index, pf->offset, pf->mask << pf->bitpos,
> + (value & pf->mask) << pf->bitpos);
> + else
> + mtk_hw_write_cross_field(hw, pf, value);
> +}
> +
> int mtk_hw_get_value(struct mtk_pinctrl *hw, const struct mtk_pin_desc *desc,
> int field, int *value)
> {
> @@ -225,6 +241,17 @@ int mtk_hw_get_value(struct mtk_pinctrl *hw, const
> struct mtk_pin_desc *desc,
> return 0;
> }
>
> +void mtk_hw_get_value_no_lookup(struct mtk_pinctrl *hw,
> + const struct mtk_pin_desc *desc,
> + int *value, struct mtk_pin_field *pf)
> +{
> + if (!pf->next)
> + *value = (mtk_r32(hw, pf->index, pf->offset)
> + >> pf->bitpos) & pf->mask;
> + else
> + mtk_hw_read_cross_field(hw, pf, value);
> +}
> +
We are able to improve mtk_hw_[set,get]_value with a cache for the
recently visited pin_desc to speed up the subsequent access to the
same register for all clients, rather than creating a specific one
with no_lookup just for a few clients. Generally, all clients should
be able to just apply the mtk_hw_[set,get]_value to compose what they
actually need.
And the changes related to the improvement on mtk_hw_[set,get]_value
with a cache is needed to put to a separate patch
Re: [PATCH v6 3/5] pinctrl: mediatek: Refine mtk_pinconf_get() and mtk_pinconf_set()
Hi,
On Thu, Sep 26, 2019 at 10:02 PM Light Hsieh wrote:
>
> 1.Refine mtk_pinconf_get():
> 1.1 Use only one occurrence of return at end of this function.
> 1.2 Correct cases for PIN_CONFIG_SLEW_RATE, PIN_CONFIG_INPUT_SCHMITT_ENABLE,
If you want to fix it a bug, you should submit a separate patch for
that and don't mix fixups and improvements in one.
> and PIN_CONFIG_OUTPUT_ENABLE -
> Use variable ret to receive value in mtk_hw_get_value() (instead of
> variable val) since pinconf_to_config_packed() at end of this function
> use variable ret to pack config value.
Is that a fixup or an improvement?
>
> 2.Refine mtk_pinconf_set():
> 2.1 Use only one occurrence of return at end of this function.
> 2.2 Modify case of PIN_CONFIG_INPUT_ENABLE -
> Remove check of ies_present flag and always invoke mtk_hw_set_value()
> since mtk_hw_pin_field_lookup() invoked inside mtk_hw_set_value() has
> the same effect of checking if ies control is supported.
> [The rationale is that: available of a control is always checked
> in mtk_hw_pin_field_lookup() and no need to add ies_present flag
> specially for ies control.]
> 2.3 Simply code logic for case of PIN_CONFIG_INPUT_SCHMITT.
> 2.4 Add case for PIN_CONFIG_INPUT_SCHMITT_ENABLE and process it with the
> same code for case of PIN_CONFIG_INPUT_SCHMITT.
Remember that one patch only does one thing so that please split the
patch you proposed here to smaller patches in the appropriate group
which are pointed out by that is either a fixup and an improvement.
>
There are many missing tags
> ---
> drivers/pinctrl/mediatek/pinctrl-mt6765.c | 1 -
> drivers/pinctrl/mediatek/pinctrl-paris.c | 211
> +++---
> 2 files changed, 79 insertions(+), 133 deletions(-)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mt6765.c
> b/drivers/pinctrl/mediatek/pinctrl-mt6765.c
> index e024ebc..bada37f 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mt6765.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mt6765.c
> @@ -1070,7 +1070,6 @@
> .ngrps = ARRAY_SIZE(mtk_pins_mt6765),
> .eint_hw = _eint_hw,
> .gpio_m = 0,
> - .ies_present = true,
> .base_names = mt6765_pinctrl_register_base_names,
> .nbase_names = ARRAY_SIZE(mt6765_pinctrl_register_base_names),
> .bias_disable_set = mtk_pinconf_bias_disable_set,
> diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c
> b/drivers/pinctrl/mediatek/pinctrl-paris.c
> index 5217f76..54f069b 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-paris.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-paris.c
> @@ -78,95 +78,79 @@ static int mtk_pinconf_get(struct pinctrl_dev *pctldev,
> {
> struct mtk_pinctrl *hw = pinctrl_dev_get_drvdata(pctldev);
> u32 param = pinconf_to_config_param(*config);
> - int val, val2, err, reg, ret = 1;
> + int err, reg, ret = 1;
> const struct mtk_pin_desc *desc;
>
> - if (pin >= hw->soc->npins)
> - return -EINVAL;
> + if (pin >= hw->soc->npins) {
> + err = -EINVAL;
> + goto out;
> + }
> desc = (const struct mtk_pin_desc *)>soc->pins[pin];
>
> switch (param) {
> case PIN_CONFIG_BIAS_DISABLE:
> - if (hw->soc->bias_disable_get) {
> + if (hw->soc->bias_disable_get)
> err = hw->soc->bias_disable_get(hw, desc, );
> - if (err)
> - return err;
> - } else {
> - return -ENOTSUPP;
> - }
> + else
> + err = -ENOTSUPP;
> break;
> case PIN_CONFIG_BIAS_PULL_UP:
> - if (hw->soc->bias_get) {
> + if (hw->soc->bias_get)
> err = hw->soc->bias_get(hw, desc, 1, );
> - if (err)
> - return err;
> - } else {
> - return -ENOTSUPP;
> - }
> + else
> + err = -ENOTSUPP;
> break;
> case PIN_CONFIG_BIAS_PULL_DOWN:
> - if (hw->soc->bias_get) {
> + if (hw->soc->bias_get)
> err = hw->soc->bias_get(hw, desc, 0, );
> - if (err)
> - return err;
> - } else {
> - return -ENOTSUPP;
> - }
> + else
> + err = -ENOTSUPP;
> break;
> case PIN_CONFIG_SLEW_RATE:
> - err = mtk_hw_get_value(hw, desc, PINCTRL_PIN_REG_SR, );
> - if (err)
> - return err;
> -
> - if (!val)
> - return -EINVAL;
> -
> + err = mtk_hw_get_value(hw, desc, PINCTRL_PIN_REG_SR, );
> break;
> case PIN_CONFIG_INPUT_ENABLE:
>
Re: [PATCH v6 2/5] pinctrl: mediatek: Supporting driving setting without mapping current to register value
Hi,
On Thu, Sep 26, 2019 at 10:02 PM Light Hsieh wrote:
>
> Mediatek's smarphone project actual usage does need to know current value
MediaTek
> (in mA) in procedure of finding the best driving setting.
> The steps in the procedure is like as follow:
>
> 1. set driving setting field in setting register as 0, measure waveform,
>perform test, and etc.
> 2. set driving setting field in setting register as 1, measure waveform,
>perform test, and etc.
> ...
> n. set driving setting field in setting register as n-1, measure
>waveform, perform test, and etc.
> Check the results of steps 1~n and adopt the setting that get best result.
>
> This procedure does need to know the mapping between current to register
> value.
you seem to use a hardware raw value instead of a human-readable value
to adjust driving current, right?
> Therefore, setting driving without mapping current is more pratical for
s/pratical/practical/
> Mediatek's smartphone usage.
>
MediaTek
> ---
> drivers/pinctrl/mediatek/pinctrl-mt6765.c| 4 ++--
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 21 +
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h | 5 +
> drivers/pinctrl/mediatek/pinctrl-paris.c | 1 +
> 4 files changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mt6765.c
> b/drivers/pinctrl/mediatek/pinctrl-mt6765.c
> index 32451e8..e024ebc 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mt6765.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mt6765.c
> @@ -1077,8 +1077,8 @@
> .bias_disable_get = mtk_pinconf_bias_disable_get,
> .bias_set = mtk_pinconf_bias_set,
> .bias_get = mtk_pinconf_bias_get,
> - .drive_set = mtk_pinconf_drive_set_rev1,
> - .drive_get = mtk_pinconf_drive_get_rev1,
> + .drive_set = mtk_pinconf_drive_set_direct_val,
> + .drive_get = mtk_pinconf_drive_get_direct_val,
I'm preferred to name it to mtk_pinconf_drive_[get,set]_raw.
> .adv_pull_get = mtk_pinconf_adv_pull_get,
> .adv_pull_set = mtk_pinconf_adv_pull_set,
> };
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> index 8077855..acfddf9 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> @@ -608,6 +608,27 @@ int mtk_pinconf_drive_get_rev1(struct mtk_pinctrl *hw,
> return 0;
> }
>
> +/* Revision direct value */
Remove the comment since that is straightforward.
> +int mtk_pinconf_drive_set_direct_val(struct mtk_pinctrl *hw,
> + const struct mtk_pin_desc *desc, u32 arg)
> +{
> + int err;
> +
> + err = mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_DRV, arg);
We can dot it simply by "return mtk_hw_set_value(hw, desc,
PINCTRL_PIN_REG_DRV, arg);".
> +
> + return err;
> +}
> +
> +int mtk_pinconf_drive_get_direct_val(struct mtk_pinctrl *hw,
> + const struct mtk_pin_desc *desc, int *val)
> +{
> + int err;
> +
> + err = mtk_hw_get_value(hw, desc, PINCTRL_PIN_REG_DRV, val);
> +
Ditto as the above.
> + return err;
> +}
> +
> int mtk_pinconf_adv_pull_set(struct mtk_pinctrl *hw,
> const struct mtk_pin_desc *desc, bool pullup,
> u32 arg)
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
> b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
> index 1b7da42..b3bada0 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
> @@ -288,6 +288,11 @@ int mtk_pinconf_drive_set_rev1(struct mtk_pinctrl *hw,
> int mtk_pinconf_drive_get_rev1(struct mtk_pinctrl *hw,
>const struct mtk_pin_desc *desc, int *val);
>
> +int mtk_pinconf_drive_set_direct_val(struct mtk_pinctrl *hw,
> + const struct mtk_pin_desc *desc, u32 arg);
> +int mtk_pinconf_drive_get_direct_val(struct mtk_pinctrl *hw,
> + const struct mtk_pin_desc *desc, int *val);
> +
> int mtk_pinconf_adv_pull_set(struct mtk_pinctrl *hw,
> const struct mtk_pin_desc *desc, bool pullup,
> u32 arg);
> diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c
> b/drivers/pinctrl/mediatek/pinctrl-paris.c
> index 3e13ae7..5217f76 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-paris.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-paris.c
> @@ -970,3 +970,4 @@ static int mtk_paris_pinctrl_resume(struct device *device)
> .suspend_noirq = mtk_paris_pinctrl_suspend,
> .resume_noirq = mtk_paris_pinctrl_resume,
> };
> +
Remove the unnecessary the change
> --
> 1.8.1.1.dirty
>
Re: [PATCH v6 1/5] pinctrl: mediatek: Check gpio pin number and use binary search in mtk_hw_pin_field_lookup()
On Thu, Sep 26, 2019 at 10:14 PM Light Hsieh wrote:
>
> Dear reviewers:
>
> Patch v6 improves v5 by:
>
> 1.in mtk_pinconf_get() and mtk_pinconf_set() @pinctrl-paris.c:
> * check if pin is in range before using pin as array index of
> hw->soc->pins[]
> 2.in mtk_pin_field_lookup() @pinctrl-mtk-common-v2.c:
> * declear start, end, check as signed integer instead of unsigned
> integer. Otherwise, kernel fault will occur when s_pin field of
> first entry of a mtk_pin_field_calc[] array is not 0.
>
And for review these patches easily, you should put the changes
history to the cover letter.
> On Fri, 2019-09-27 at 13:02 +0800, Light Hsieh wrote:
> > 1. Check if gpio pin number is in valid range to prevent from get invalid
> >pointer 'desc' in the following code:
> > desc = (const struct mtk_pin_desc *)>soc->pins[gpio];
> >
> > 2. Use binary search in mtk_hw_pin_field_lookup()
> >Modify mtk_hw_pin_field_lookup() to use binary search for accelerating
> >search.
> >
You almost forgot to add the tags from you and the reviewers' feedback.
> > ---
> > drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 25
> > +++-
> > drivers/pinctrl/mediatek/pinctrl-paris.c | 25
> >
> > 2 files changed, 45 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> > b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> > index 20e1c89..8077855 100644
> > --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> > +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> > @@ -68,7 +68,8 @@ static int mtk_hw_pin_field_lookup(struct mtk_pinctrl *hw,
> > {
> > const struct mtk_pin_field_calc *c, *e;
> > const struct mtk_pin_reg_calc *rc;
> > - u32 bits;
> > + u32 bits, found = 0;
the type of found seems to be a bool
> > + int start = 0, end, check;
> >
> > if (hw->soc->reg_cal && hw->soc->reg_cal[field].range) {
> > rc = >soc->reg_cal[field];
> > @@ -79,21 +80,32 @@ static int mtk_hw_pin_field_lookup(struct mtk_pinctrl
> > *hw,
> > return -ENOTSUPP;
> > }
> >
> > + end = rc->nranges - 1;
> > c = rc->range;
> > e = c + rc->nranges;
> >
> > - while (c < e) {
> > - if (desc->number >= c->s_pin && desc->number <= c->e_pin)
> > + while (start <= end) {
> > + check = (start + end) >> 1;
> > + if (desc->number >= rc->range[check].s_pin
> > + && desc->number <= rc->range[check].e_pin) {
> > + found = 1;
> > break;
> > - c++;
> > + } else if (start == end)
> > + break;
> > + else if (desc->number < rc->range[check].s_pin)
> > + end = check - 1;
> > + else
> > + start = check + 1;
> > }
> >
yuh, it is good to do do a binary search here
> > - if (c >= e) {
> > + if (!found) {
> > dev_dbg(hw->dev, "Not support field %d for pin = %d (%s)\n",
> > field, desc->number, desc->name);
> > return -ENOTSUPP;
> > }
> >
> > + c = rc->range + check;
> > +
> > if (c->i_base > hw->nbase - 1) {
> > dev_err(hw->dev,
> > "Invalid base for field %d for pin = %d (%s)\n",
> > @@ -182,6 +194,9 @@ int mtk_hw_set_value(struct mtk_pinctrl *hw, const
> > struct mtk_pin_desc *desc,
> > if (err)
> > return err;
> >
> > + if (value < 0 || value > pf.mask)
> > + return -EINVAL;
> > +
> > if (!pf.next)
> > mtk_rmw(hw, pf.index, pf.offset, pf.mask << pf.bitpos,
> > (value & pf.mask) << pf.bitpos);
> > diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c
> > b/drivers/pinctrl/mediatek/pinctrl-paris.c
> > index 923264d..3e13ae7 100644
> > --- a/drivers/pinctrl/mediatek/pinctrl-paris.c
> > +++ b/drivers/pinctrl/mediatek/pinctrl-paris.c
> > @@ -81,6 +81,8 @@ static int mtk_pinconf_get(struct pinctrl_dev *pctldev,
> > int val, val2, err, reg, ret = 1;
> > const struct mtk_pin_desc *desc;
> >
> > + if (pin >= hw->soc->npins)
> > + return -EINVAL;
> > desc = (const struct mtk_pin_desc *)>soc->pins[pin];
> >
> > switch (param) {
> > @@ -206,6 +208,10 @@ static int mtk_pinconf_set(struct pinctrl_dev
> > *pctldev, unsigned int pin,
> > int err = 0;
> > u32 reg;
> >
> > + if (pin >= hw->soc->npins) {
> > + err = -EINVAL;
> > + goto err;
> > + }
> > desc = (const struct mtk_pin_desc *)>soc->pins[pin];
> >
> > switch ((u32)param) {
> > @@ -693,6 +699,9 @@ static int mtk_gpio_get_direction(struct gpio_chip
> > *chip, unsigned int gpio)
> > const struct mtk_pin_desc *desc;
> > int value, err;
> >
> > + if (gpio > hw->soc->npins)
> > + return -EINVAL;
> >
Re: [PATCH v7 5/7] power: reset: add driver for mt6323 poweroff
Hi, Frank
On Tue, 2019-09-10 at 09:04 +0200, Frank Wunderlich wrote:
> From: Josef Friedl
>
> add poweroff driver for mt6323 and make Makefile and Kconfig-Entries
>
> Suggested-by: Frank Wunderlich
> Signed-off-by: Josef Friedl
> Signed-off-by: Frank Wunderlich
> Acked-by: Sebastian Reichel
Thanks for your help keep the unfinished driver to upstream
Acked-by: Sean Wang
> ---
> changes since v6: none
> changes since v5: split out mfd/mt6397/core.h
> changes since v4: none
> changes since v3: none
> changes since v2: none (=v2 part 5)
> ---
> drivers/power/reset/Kconfig | 10 +++
> drivers/power/reset/Makefile | 1 +
> drivers/power/reset/mt6323-poweroff.c | 97 +++
> 3 files changed, 108 insertions(+)
> create mode 100644 drivers/power/reset/mt6323-poweroff.c
>
> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> index a564237278ff..c721939767eb 100644
> --- a/drivers/power/reset/Kconfig
> +++ b/drivers/power/reset/Kconfig
> @@ -140,6 +140,16 @@ config POWER_RESET_LTC2952
> This driver supports an external powerdown trigger and board power
> down via the LTC2952. Bindings are made in the device tree.
>
> +config POWER_RESET_MT6323
> + bool "MediaTek MT6323 power-off driver"
> + depends on MFD_MT6397
> + help
> + The power-off driver is responsible for externally shutdown down
> + the power of a remote MediaTek SoC MT6323 is connected to through
> + controlling a tiny circuit BBPU inside MT6323 RTC.
> +
> + Say Y if you have a board where MT6323 could be found.
> +
> config POWER_RESET_QNAP
> bool "QNAP power-off driver"
> depends on OF_GPIO && PLAT_ORION
> diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
> index 85da3198e4e0..da37f8b851dc 100644
> --- a/drivers/power/reset/Makefile
> +++ b/drivers/power/reset/Makefile
> @@ -11,6 +11,7 @@ obj-$(CONFIG_POWER_RESET_GPIO) += gpio-poweroff.o
> obj-$(CONFIG_POWER_RESET_GPIO_RESTART) += gpio-restart.o
> obj-$(CONFIG_POWER_RESET_HISI) += hisi-reboot.o
> obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
> +obj-$(CONFIG_POWER_RESET_MT6323) += mt6323-poweroff.o
> obj-$(CONFIG_POWER_RESET_QCOM_PON) += qcom-pon.o
> obj-$(CONFIG_POWER_RESET_OCELOT_RESET) += ocelot-reset.o
> obj-$(CONFIG_POWER_RESET_PIIX4_POWEROFF) += piix4-poweroff.o
> diff --git a/drivers/power/reset/mt6323-poweroff.c
> b/drivers/power/reset/mt6323-poweroff.c
> new file mode 100644
> index ..1caf43d9e46d
> --- /dev/null
> +++ b/drivers/power/reset/mt6323-poweroff.c
> @@ -0,0 +1,97 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Power off through MediaTek PMIC
> + *
> + * Copyright (C) 2018 MediaTek Inc.
> + *
> + * Author: Sean Wang
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct mt6323_pwrc {
> + struct device *dev;
> + struct regmap *regmap;
> + u32 base;
> +};
> +
> +static struct mt6323_pwrc *mt_pwrc;
> +
> +static void mt6323_do_pwroff(void)
> +{
> + struct mt6323_pwrc *pwrc = mt_pwrc;
> + unsigned int val;
> + int ret;
> +
> + regmap_write(pwrc->regmap, pwrc->base + RTC_BBPU, RTC_BBPU_KEY);
> + regmap_write(pwrc->regmap, pwrc->base + RTC_WRTGR, 1);
> +
> + ret = regmap_read_poll_timeout(pwrc->regmap,
> + pwrc->base + RTC_BBPU, val,
> + !(val & RTC_BBPU_CBUSY),
> + MTK_RTC_POLL_DELAY_US,
> + MTK_RTC_POLL_TIMEOUT);
> + if (ret)
> + dev_err(pwrc->dev, "failed to write BBPU: %d\n", ret);
> +
> + /* Wait some time until system down, otherwise, notice with a warn */
> + mdelay(1000);
> +
> + WARN_ONCE(1, "Unable to power off system\n");
> +}
> +
> +static int mt6323_pwrc_probe(struct platform_device *pdev)
> +{
> + struct mt6397_chip *mt6397_chip = dev_get_drvdata(pdev->dev.parent);
> + struct mt6323_pwrc *pwrc;
> + struct resource *res;
> +
> + pwrc = devm_kzalloc(>dev, sizeof(*pwrc), GFP_KERNEL);
> + if (!pwrc)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + pwrc->base = res->start;
> + pwrc->regmap = mt6397_chip->regmap;
> + pwrc->dev = >dev;
> + mt_pwrc = pwrc;
> +
> + pm_power_off = _do_pwroff;
> +
> + return 0;
> +}
> +
> +static int mt
Re: [PATCH v2 1/5] pinctrl: mediatek: Check gpio pin number and use binary search in mtk_hw_pin_field_lookup()
Hi Linus, That looks OK to me too Acked-by: Sean Wang On Wed, Sep 11, 2019 at 2:29 AM Linus Walleij wrote: > > On Thu, Sep 5, 2019 at 7:00 AM Light Hsieh wrote: > > > v2 is the same as v1 except that commit message is corrected according > > to Linus' comment for v1: > > > > 1. remove Change-Id lines > > 2. correct sysfs as debugfs > > Looks OK to me, but i need Sean's review on this, Sean? > > Yours, > Linus Walleij
Re: [PATCH v2 07/11] pinctrl: mediatek: add mt6779 eint support
On Mon, Aug 19, 2019 at 2:22 AM Mars Cheng wrote:
>
> add driver setting to support mt6779 eint
>
> Signed-off-by: Mars Cheng
Acked-by: Sean Wang
> ---
> drivers/pinctrl/mediatek/pinctrl-mt6779.c |8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mt6779.c
> b/drivers/pinctrl/mediatek/pinctrl-mt6779.c
> index 145bf22..49ff3cc 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mt6779.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mt6779.c
> @@ -731,11 +731,19 @@
> "iocfg_rt", "iocfg_lt", "iocfg_tl",
> };
>
> +static const struct mtk_eint_hw mt6779_eint_hw = {
> + .port_mask = 7,
> + .ports = 6,
> + .ap_num= 209,
> + .db_cnt= 16,
> +};
> +
> static const struct mtk_pin_soc mt6779_data = {
> .reg_cal = mt6779_reg_cals,
> .pins = mtk_pins_mt6779,
> .npins = ARRAY_SIZE(mtk_pins_mt6779),
> .ngrps = ARRAY_SIZE(mtk_pins_mt6779),
> + .eint_hw = _eint_hw,
> .gpio_m = 0,
> .ies_present = true,
> .base_names = mt6779_pinctrl_register_base_names,
> --
> 1.7.9.5
>
Re: [PATCH v2 06/11] pinctrl: mediatek: add pinctrl support for MT6779 SoC
On Mon, Aug 19, 2019 at 2:22 AM Mars Cheng wrote:
>
> This adds MT6779 pinctrl driver based on MediaTek pinctrl-paris core.
>
> Signed-off-by: Mars Cheng
> Signed-off-by: Andy Teng
Acked-by: Sean Wang
> ---
> drivers/pinctrl/mediatek/Kconfig |7 +
> drivers/pinctrl/mediatek/Makefile |1 +
> drivers/pinctrl/mediatek/pinctrl-mt6779.c | 775 +
> drivers/pinctrl/mediatek/pinctrl-mtk-mt6779.h | 2085
> +
> 4 files changed, 2868 insertions(+)
> create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt6779.c
> create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt6779.h
>
> diff --git a/drivers/pinctrl/mediatek/Kconfig
> b/drivers/pinctrl/mediatek/Kconfig
> index 701f9af..f628d01 100644
> --- a/drivers/pinctrl/mediatek/Kconfig
> +++ b/drivers/pinctrl/mediatek/Kconfig
> @@ -86,6 +86,13 @@ config PINCTRL_MT6765
> default ARM64 && ARCH_MEDIATEK
> select PINCTRL_MTK_PARIS
>
> +config PINCTRL_MT6779
> + bool "Mediatek MT6779 pin control"
> + depends on OF
> + depends on ARM64 || COMPILE_TEST
> + default ARM64 && ARCH_MEDIATEK
> + select PINCTRL_MTK_PARIS
> +
> config PINCTRL_MT6797
> bool "Mediatek MT6797 pin control"
> depends on OF
> diff --git a/drivers/pinctrl/mediatek/Makefile
> b/drivers/pinctrl/mediatek/Makefile
> index a74325a..59c1c60 100644
> --- a/drivers/pinctrl/mediatek/Makefile
> +++ b/drivers/pinctrl/mediatek/Makefile
> @@ -11,6 +11,7 @@ obj-$(CONFIG_PINCTRL_MT2712) += pinctrl-mt2712.o
> obj-$(CONFIG_PINCTRL_MT8135) += pinctrl-mt8135.o
> obj-$(CONFIG_PINCTRL_MT8127) += pinctrl-mt8127.o
> obj-$(CONFIG_PINCTRL_MT6765) += pinctrl-mt6765.o
> +obj-$(CONFIG_PINCTRL_MT6779) += pinctrl-mt6779.o
> obj-$(CONFIG_PINCTRL_MT6797) += pinctrl-mt6797.o
> obj-$(CONFIG_PINCTRL_MT7622) += pinctrl-mt7622.o
> obj-$(CONFIG_PINCTRL_MT7623) += pinctrl-mt7623.o
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mt6779.c
> b/drivers/pinctrl/mediatek/pinctrl-mt6779.c
> new file mode 100644
> index 000..145bf22
> --- /dev/null
> +++ b/drivers/pinctrl/mediatek/pinctrl-mt6779.c
> @@ -0,0 +1,775 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2019 MediaTek Inc.
> + * Author: Andy Teng
> + *
> + */
> +
> +#include "pinctrl-mtk-mt6779.h"
> +#include "pinctrl-paris.h"
> +
> +/* MT6779 have multiple bases to program pin configuration listed as the
> below:
> + * gpio:0x10005000, iocfg_rm:0x11C2, iocfg_br:0x11D1,
> + * iocfg_lm:0x11E2, iocfg_lb:0x11E7, iocfg_rt:0x11EA,
> + * iocfg_lt:0x11F2, iocfg_tl:0x11F3
> + * _i_based could be used to indicate what base the pin should be mapped
> into.
> + */
> +
> +#define PIN_FIELD_BASE(s_pin, e_pin, i_base, s_addr, x_addrs, s_bit, x_bits)
> \
> + PIN_FIELD_CALC(s_pin, e_pin, i_base, s_addr, x_addrs, s_bit, x_bits, \
> + 32, 0)
> +
> +#define PINS_FIELD_BASE(s_pin, e_pin, i_base, s_addr, x_addrs, s_bit,
> x_bits) \
> + PIN_FIELD_CALC(s_pin, e_pin, i_base, s_addr, x_addrs, s_bit, x_bits,
> \
> + 32, 1)
> +
> +static const struct mtk_pin_field_calc mt6779_pin_mode_range[] = {
> + PIN_FIELD_BASE(0, 7, 0, 0x0300, 0x10, 0, 4),
> + PIN_FIELD_BASE(8, 15, 0, 0x0310, 0x10, 0, 4),
> + PIN_FIELD_BASE(16, 23, 0, 0x0320, 0x10, 0, 4),
> + PIN_FIELD_BASE(24, 31, 0, 0x0330, 0x10, 0, 4),
> + PIN_FIELD_BASE(32, 39, 0, 0x0340, 0x10, 0, 4),
> + PIN_FIELD_BASE(40, 47, 0, 0x0350, 0x10, 0, 4),
> + PIN_FIELD_BASE(48, 55, 0, 0x0360, 0x10, 0, 4),
> + PIN_FIELD_BASE(56, 63, 0, 0x0370, 0x10, 0, 4),
> + PIN_FIELD_BASE(64, 71, 0, 0x0380, 0x10, 0, 4),
> + PIN_FIELD_BASE(72, 79, 0, 0x0390, 0x10, 0, 4),
> + PIN_FIELD_BASE(80, 87, 0, 0x03A0, 0x10, 0, 4),
> + PIN_FIELD_BASE(88, 95, 0, 0x03B0, 0x10, 0, 4),
> + PIN_FIELD_BASE(96, 103, 0, 0x03C0, 0x10, 0, 4),
> + PIN_FIELD_BASE(104, 111, 0, 0x03D0, 0x10, 0, 4),
> + PIN_FIELD_BASE(112, 119, 0, 0x03E0, 0x10, 0, 4),
> + PIN_FIELD_BASE(120, 127, 0, 0x03F0, 0x10, 0, 4),
> + PIN_FIELD_BASE(128, 135, 0, 0x0400, 0x10, 0, 4),
> + PIN_FIELD_BASE(136, 143, 0, 0x0410, 0x10, 0, 4),
> + PIN_FIELD_BASE(144, 151, 0, 0x0420, 0x10, 0, 4),
> + PIN_FIELD_BASE(152, 159, 0, 0x0430, 0x10, 0, 4),
> + PIN_FIELD_BASE(160, 167, 0, 0x0440, 0x10, 0, 4),
> + PIN_FIELD_BASE(168, 175, 0, 0x0450, 0x10, 0, 4),
> + PIN_FIELD_BASE(176, 183, 0, 0x0460, 0x10, 0, 4),
> + PIN_FIELD_BASE(184, 191, 0, 0x0470, 0x10, 0, 4),
> +
Re: [PATCH v1 2/5] pinctrl: mediatek: Supporting driving setting without mapping current to register value
Hi, Light
a few nitpicks, but the overall changes look good to me
On Tue, Aug 13, 2019 at 1:53 AM Light Hsieh wrote:
>
> From: Light Hsieh
>
> Mediatek's smarphone project actual usage does need to know current value
> (in mA) in procedure of finding the best driving setting.
> The steps in the procedure is like as follow:
>
> 1. set driving setting field in setting register as 0, measure waveform,
>perform test, and etc.
> 2. set driving setting field in setting register as 1, measure waveform,
>perform test, and etc.
> ...
> n. set driving setting field in setting register as n-1, measure
>waveform, perform test, and etc.
> Check the results of steps 1~n and adopt the setting that get best result.
>
> This procedure does need to know the mapping between current to register
> value.
> Therefore, setting driving without mapping current is more pratical for
> Mediatek's smartphone usage.
>
> Change-Id: Iacdabf0cada230fc5acad96673810c12a6c4556d
remove change-id
> ---
> drivers/pinctrl/mediatek/pinctrl-mt6765.c| 4 ++--
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 21 +
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h | 5 +
> drivers/pinctrl/mediatek/pinctrl-paris.c | 1 +
> 4 files changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mt6765.c
> b/drivers/pinctrl/mediatek/pinctrl-mt6765.c
> index 32451e8..e024ebc 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mt6765.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mt6765.c
> @@ -1077,8 +1077,8 @@
> .bias_disable_get = mtk_pinconf_bias_disable_get,
> .bias_set = mtk_pinconf_bias_set,
> .bias_get = mtk_pinconf_bias_get,
> - .drive_set = mtk_pinconf_drive_set_rev1,
> - .drive_get = mtk_pinconf_drive_get_rev1,
> + .drive_set = mtk_pinconf_drive_set_direct_val,
> + .drive_get = mtk_pinconf_drive_get_direct_val,
I prefer to mtk_pinconf_drive_[get,set]_raw_val that would be better
to understand.
> .adv_pull_get = mtk_pinconf_adv_pull_get,
> .adv_pull_set = mtk_pinconf_adv_pull_set,
> };
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> index 4687f63..23a9529 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> @@ -607,6 +607,27 @@ int mtk_pinconf_drive_get_rev1(struct mtk_pinctrl *hw,
> return 0;
> }
>
> +/* Revision direct value */
> +int mtk_pinconf_drive_set_direct_val(struct mtk_pinctrl *hw,
> + const struct mtk_pin_desc *desc, u32 arg)
> +{
> + int err;
> +
> + err = mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_DRV, arg);
> +
> + return err;
> +}
> +
> +int mtk_pinconf_drive_get_direct_val(struct mtk_pinctrl *hw,
> + const struct mtk_pin_desc *desc, int *val)
> +{
> + int err;
> +
> + err = mtk_hw_get_value(hw, desc, PINCTRL_PIN_REG_DRV, val);
> +
> + return err;
> +}
> +
> int mtk_pinconf_adv_pull_set(struct mtk_pinctrl *hw,
> const struct mtk_pin_desc *desc, bool pullup,
> u32 arg)
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
> b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
> index 1b7da42..b3bada0 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
> @@ -288,6 +288,11 @@ int mtk_pinconf_drive_set_rev1(struct mtk_pinctrl *hw,
> int mtk_pinconf_drive_get_rev1(struct mtk_pinctrl *hw,
>const struct mtk_pin_desc *desc, int *val);
>
> +int mtk_pinconf_drive_set_direct_val(struct mtk_pinctrl *hw,
> + const struct mtk_pin_desc *desc, u32 arg);
> +int mtk_pinconf_drive_get_direct_val(struct mtk_pinctrl *hw,
> + const struct mtk_pin_desc *desc, int *val);
> +
> int mtk_pinconf_adv_pull_set(struct mtk_pinctrl *hw,
> const struct mtk_pin_desc *desc, bool pullup,
> u32 arg);
> diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c
> b/drivers/pinctrl/mediatek/pinctrl-paris.c
> index 28b4951..71c94b2 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-paris.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-paris.c
> @@ -964,3 +964,4 @@ static int mtk_paris_pinctrl_resume(struct device *device)
> .suspend_noirq = mtk_paris_pinctrl_suspend,
> .resume_noirq = mtk_paris_pinctrl_resume,
> };
> +
remove unnecessary the empty line
> --
> 1.8.1.1.dirty
>
Re: [PATCH v1 4/5] pinctrl: mediatek: Backward compatible to previous Mediatek's bias-pull usage
Hi, Light
On Tue, Aug 13, 2019 at 1:53 AM Light Hsieh wrote:
>
> From: Light Hsieh
>
> Refine mtk_pinconf_set()/mtk_pinconf_get() for backward compatibility to
> previous Mediatek's bias-pull usage.
> In PINCTRL_MTK that use pinctrl-mtk-common.c, bias-pull setting for pins
> with 2 pull resistors can be specified as value for bias-pull-up and
> bias-pull-down. For example:
> bias-pull-up = ;
> bias-pull-up = ;
> bias-pull-up = ;
> bias-pull-up = ;
> bias-pull-down = ;
> bias-pull-down = ;
> bias-pull-down = ;
> bias-pull-down = ;
>
> On the other hand, PINCTRL_MTK_PARIS use customized properties
> "mediatek,pull-up-adv" and "mediatek,pull-down-adv" to specify bias-pull
> setting for pins with 2 pull resistors.
> This introduce in-compatibility in device tree and increatse porting
> effort to Mediatek's customer that had already used PINCTRL_MTK version.
> Besides, if customers are not awared of this change and still write devicetree
> for PINCTRL_MTK version, they may encounter runtime failure with pinctrl and
> spent time to debug.
>
> This patch add backward compatible to previous Mediatek's bias-pull usage
> so that Mediatek's customer need not use a new devicetree property name.
> The rationale is that: changing driver implemenation had better leave
> interface unchanged.
>
> Change-Id: I8ea8f09278acc492ba04771826eaadb70224cd51
remove Change-Id
> ---
> drivers/pinctrl/mediatek/pinctrl-mt6765.c| 4 +-
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 285
> +++
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h | 11 +
> drivers/pinctrl/mediatek/pinctrl-paris.c | 49 ++--
> 4 files changed, 327 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mt6765.c
> b/drivers/pinctrl/mediatek/pinctrl-mt6765.c
> index bada37f..315aebd 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mt6765.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mt6765.c
> @@ -1074,8 +1074,8 @@
> .nbase_names = ARRAY_SIZE(mt6765_pinctrl_register_base_names),
> .bias_disable_set = mtk_pinconf_bias_disable_set,
> .bias_disable_get = mtk_pinconf_bias_disable_get,
> - .bias_set = mtk_pinconf_bias_set,
> - .bias_get = mtk_pinconf_bias_get,
> + .bias_set = mtk_pinconf_bias_set_combo,
> + .bias_get = mtk_pinconf_bias_get_combo,
base on the below context, I guess you should mean .bias_set_combo =
mtk_pinconf_bias_set_combo and .bias_get_combo =
mtk_pinconf_bias_get_combo.
> .drive_set = mtk_pinconf_drive_set_direct_val,
> .drive_get = mtk_pinconf_drive_get_direct_val,
> .adv_pull_get = mtk_pinconf_adv_pull_get,
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> index 23a9529..dab8418 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> @@ -13,6 +13,8 @@
> #include
> #include
>
> +#include
include #include in pinctrl-paris.c,
common-v2.c is supposed dt-binding and chip independence.
> +
> #include "mtk-eint.h"
> #include "pinctrl-mtk-common-v2.h"
>
> @@ -205,6 +207,20 @@ int mtk_hw_set_value(struct mtk_pinctrl *hw, const
> struct mtk_pin_desc *desc,
> return 0;
> }
>
> +void mtk_hw_set_value_no_lookup(struct mtk_pinctrl *hw,
> + const struct mtk_pin_desc *desc,
> + int value, struct mtk_pin_field *pf)
> +{
> + if (value < 0 || value > pf->mask)
> + return;
> +
> + if (!pf->next)
> + mtk_rmw(hw, pf->index, pf->offset, pf->mask << pf->bitpos,
> + (value & pf->mask) << pf->bitpos);
> + else
> + mtk_hw_write_cross_field(hw, pf, value);
> +}
> +
> int mtk_hw_get_value(struct mtk_pinctrl *hw, const struct mtk_pin_desc *desc,
> int field, int *value)
> {
> @@ -224,6 +240,17 @@ int mtk_hw_get_value(struct mtk_pinctrl *hw, const
> struct mtk_pin_desc *desc,
> return 0;
> }
>
> +void mtk_hw_get_value_no_lookup(struct mtk_pinctrl *hw,
> + const struct mtk_pin_desc *desc,
> + int *value, struct mtk_pin_field *pf)
> +{
> + if (!pf->next)
> + *value = (mtk_r32(hw, pf->index, pf->offset)
> + >> pf->bitpos) & pf->mask;
> + else
> + mtk_hw_read_cross_field(hw, pf, value);
> +}
> +
> static int mtk_xt_find_eint_num(struct mtk_pinctrl *hw, unsigned long eint_n)
> {
> const struct mtk_pin_desc *desc;
> @@ -516,6 +543,264 @@ int mtk_pinconf_bias_get_rev1(struct mtk_pinctrl *hw,
> return 0;
> }
>
> +/* Combo for the following pull register type:
> + * 1. PU + PD
> + * 2. PULLSEL + PULLEN
> + * 3. PUPD + R0 + R1
> + */
> +int mtk_pinconf_bias_set_pu_pd(struct mtk_pinctrl *hw,
> + const struct
Re: [PATCH v1 1/5] pinctrl: mediatek: Check gpio pin number and use binary search in mtk_hw_pin_field_lookup()
On Tue, Aug 13, 2019 at 1:53 AM Light Hsieh wrote:
>
> From: Light Hsieh
>
> 1. Check if gpio pin number is in valid range to prevent from get invalid
>pointer 'desc' in the following code:
> desc = (const struct mtk_pin_desc *)>soc->pins[gpio];
>
> 2. Use binary search in mtk_hw_pin_field_lookup()
>Modify mtk_hw_pin_field_lookup() to use binary search for accelerating
>search.
>
> Change-Id: I22b4644ec216b90dd9dd5e223cc41d43761701b0
remove all of Change-Id in all the patches in the series
> ---
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 24
> +++-
> drivers/pinctrl/mediatek/pinctrl-paris.c | 19 +++
> 2 files changed, 38 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> index 20e1c89..4687f63 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> @@ -68,7 +68,7 @@ static int mtk_hw_pin_field_lookup(struct mtk_pinctrl *hw,
> {
> const struct mtk_pin_field_calc *c, *e;
> const struct mtk_pin_reg_calc *rc;
> - u32 bits;
> + u32 bits, start = 0, end, found = 0, check;
variable found should be bool type, and the declaration should be
listed in reverse Xmas tree order
>
> if (hw->soc->reg_cal && hw->soc->reg_cal[field].range) {
> rc = >soc->reg_cal[field];
> @@ -79,21 +79,32 @@ static int mtk_hw_pin_field_lookup(struct mtk_pinctrl *hw,
> return -ENOTSUPP;
> }
>
> + end = rc->nranges - 1;
> c = rc->range;
> e = c + rc->nranges;
>
> - while (c < e) {
> - if (desc->number >= c->s_pin && desc->number <= c->e_pin)
> + while (start <= end) {
> + check = (start + end) >> 1;
> + if (desc->number >= rc->range[check].s_pin
> +&& desc->number <= rc->range[check].e_pin) {
> + found = 1;
found = true;
> break;
> - c++;
> + } else if (start == end)
> + break;
> + else if (desc->number < rc->range[check].s_pin)
> + end = check - 1;
> + else
> + start = check + 1;
> }
>
> - if (c >= e) {
> + if (!found) {
> dev_dbg(hw->dev, "Not support field %d for pin = %d (%s)\n",
> field, desc->number, desc->name);
> return -ENOTSUPP;
> }
>
> + c = rc->range + check;
> +
> if (c->i_base > hw->nbase - 1) {
> dev_err(hw->dev,
> "Invalid base for field %d for pin = %d (%s)\n",
> @@ -182,6 +193,9 @@ int mtk_hw_set_value(struct mtk_pinctrl *hw, const struct
> mtk_pin_desc *desc,
> if (err)
> return err;
>
> + if (value < 0 || value > pf.mask)
> + return -EINVAL;
> +
> if (!pf.next)
> mtk_rmw(hw, pf.index, pf.offset, pf.mask << pf.bitpos,
> (value & pf.mask) << pf.bitpos);
> diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c
> b/drivers/pinctrl/mediatek/pinctrl-paris.c
> index 923264d..28b4951 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-paris.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-paris.c
> @@ -693,6 +693,9 @@ static int mtk_gpio_get_direction(struct gpio_chip *chip,
> unsigned int gpio)
> const struct mtk_pin_desc *desc;
> int value, err;
>
> + if (gpio > hw->soc->npins)
> + return -EINVAL;
> +
> desc = (const struct mtk_pin_desc *)>soc->pins[gpio];
>
> err = mtk_hw_get_value(hw, desc, PINCTRL_PIN_REG_DIR, );
> @@ -708,6 +711,9 @@ static int mtk_gpio_get(struct gpio_chip *chip, unsigned
> int gpio)
> const struct mtk_pin_desc *desc;
> int value, err;
>
> + if (gpio > hw->soc->npins)
> + return -EINVAL;
> +
> desc = (const struct mtk_pin_desc *)>soc->pins[gpio];
>
> err = mtk_hw_get_value(hw, desc, PINCTRL_PIN_REG_DI, );
> @@ -722,6 +728,9 @@ static void mtk_gpio_set(struct gpio_chip *chip, unsigned
> int gpio, int value)
> struct mtk_pinctrl *hw = gpiochip_get_data(chip);
> const struct mtk_pin_desc *desc;
>
> + if (gpio > hw->soc->npins)
> + return;
> +
> desc = (const struct mtk_pin_desc *)>soc->pins[gpio];
>
> mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_DO, !!value);
> @@ -729,12 +738,22 @@ static void mtk_gpio_set(struct gpio_chip *chip,
> unsigned int gpio, int value)
>
> static int mtk_gpio_direction_input(struct gpio_chip *chip, unsigned int
> gpio)
> {
> + struct mtk_pinctrl *hw = gpiochip_get_data(chip);
> +
> + if (gpio > hw->soc->npins)
> + return -EINVAL;
> +
> return pinctrl_gpio_direction_input(chip->base + gpio);
> }
Re: [PATCH 1/2] pinctrl: mediatek: Ignore interrupts that are wake only during resume
Hi Nicolas,
On Sun, Apr 28, 2019 at 8:55 PM Nicolas Boichat wrote:
>
> Before suspending, mtk-eint would set the interrupt mask to the
> one in wake_mask. However, some of these interrupts may not have a
> corresponding interrupt handler, or the interrupt may be disabled.
>
> On resume, the eint irq handler would trigger nevertheless,
> and irq/pm.c:irq_pm_check_wakeup would be called, which would
> try to call irq_disable. However, if the interrupt is not enabled
> (irqd_irq_disabled(>irq_data) is true), the call does nothing,
> and the interrupt is left enabled in the eint driver.
>
> Especially for level-sensitive interrupts, this will lead to an
> interrupt storm on resume.
>
> If we detect that an interrupt is only in wake_mask, but not in
> cur_mask, we can just mask it out immediately (as mtk_eint_resume
> would do anyway at a later stage in the resume sequence, when
> restoring cur_mask).
>
> Fixes: bf22ff45bed ("genirq: Avoid unnecessary low level irq function calls")
> Signed-off-by: Nicolas Boichat
Acked-by: Sean Wang
> ---
> drivers/pinctrl/mediatek/mtk-eint.c | 16 +++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/mediatek/mtk-eint.c
> b/drivers/pinctrl/mediatek/mtk-eint.c
> index f464f8cd274b75c..737385e86beb807 100644
> --- a/drivers/pinctrl/mediatek/mtk-eint.c
> +++ b/drivers/pinctrl/mediatek/mtk-eint.c
> @@ -318,7 +318,7 @@ static void mtk_eint_irq_handler(struct irq_desc *desc)
> struct irq_chip *chip = irq_desc_get_chip(desc);
> struct mtk_eint *eint = irq_desc_get_handler_data(desc);
> unsigned int status, eint_num;
> - int offset, index, virq;
> + int offset, mask_offset, index, virq;
> void __iomem *reg = mtk_eint_get_offset(eint, 0, eint->regs->stat);
> int dual_edge, start_level, curr_level;
>
> @@ -328,10 +328,24 @@ static void mtk_eint_irq_handler(struct irq_desc *desc)
> status = readl(reg);
> while (status) {
> offset = __ffs(status);
> + mask_offset = eint_num >> 5;
> index = eint_num + offset;
> virq = irq_find_mapping(eint->domain, index);
> status &= ~BIT(offset);
>
> + /*
> +* If we get an interrupt on pin that was only
> required
> +* for wake (but no real interrupt requested), mask
> the
> +* interrupt (as would mtk_eint_resume do anyway later
> +* in the resume sequence).
> +*/
> + if (eint->wake_mask[mask_offset] & BIT(offset) &&
> + !(eint->cur_mask[mask_offset] & BIT(offset))) {
> + writel_relaxed(BIT(offset), reg -
> + eint->regs->stat +
> + eint->regs->mask_set);
> + }
> +
> dual_edge = eint->dual_edge[index];
> if (dual_edge) {
> /*
> --
> 2.21.0.593.g511ec345e18-goog
>
Re: [PATCH 2/2] pinctrl: mediatek: Update cur_mask in mask/mask ops
Hi, Nicolas
On Sun, Apr 28, 2019 at 8:55 PM Nicolas Boichat wrote:
>
> During suspend/resume, mtk_eint_mask may be called while
> wake_mask is active. For example, this happens if a wake-source
> with an active interrupt handler wakes the system:
> irq/pm.c:irq_pm_check_wakeup would disable the interrupt, so
> that it can be handled later on in the resume flow.
>
> However, this may happen before mtk_eint_do_resume is called:
> in this case, wake_mask is loaded, and cur_mask is restored
> from an older copy, re-enabling the interrupt, and causing
> an interrupt storm (especially for level interrupts).
>
> Instead, we just record mask/unmask changes in cur_mask. This
> also avoids the need to read the current mask in eint_do_suspend,
> and we can remove mtk_eint_chip_read_mask function.
>
The change is worth rewording the commit message you added above as an instance
and adding Fixes tag as a fixup to mean you're fixing the existing
problem in the driver.
And then Acked-by: Sean Wang
> Signed-off-by: Nicolas Boichat
> ---
> drivers/pinctrl/mediatek/mtk-eint.c | 18 --
> 1 file changed, 4 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/pinctrl/mediatek/mtk-eint.c
> b/drivers/pinctrl/mediatek/mtk-eint.c
> index 737385e86beb807..7e526bcf5e0b55c 100644
> --- a/drivers/pinctrl/mediatek/mtk-eint.c
> +++ b/drivers/pinctrl/mediatek/mtk-eint.c
> @@ -113,6 +113,8 @@ static void mtk_eint_mask(struct irq_data *d)
> void __iomem *reg = mtk_eint_get_offset(eint, d->hwirq,
> eint->regs->mask_set);
>
> + eint->cur_mask[d->hwirq >> 5] &= ~mask;
> +
> writel(mask, reg);
> }
>
> @@ -123,6 +125,8 @@ static void mtk_eint_unmask(struct irq_data *d)
> void __iomem *reg = mtk_eint_get_offset(eint, d->hwirq,
> eint->regs->mask_clr);
>
> + eint->cur_mask[d->hwirq >> 5] |= mask;
> +
> writel(mask, reg);
>
> if (eint->dual_edge[d->hwirq])
> @@ -217,19 +221,6 @@ static void mtk_eint_chip_write_mask(const struct
> mtk_eint *eint,
> }
> }
>
> -static void mtk_eint_chip_read_mask(const struct mtk_eint *eint,
> - void __iomem *base, u32 *buf)
> -{
> - int port;
> - void __iomem *reg;
> -
> - for (port = 0; port < eint->hw->ports; port++) {
> - reg = base + eint->regs->mask + (port << 2);
> - buf[port] = ~readl_relaxed(reg);
> - /* Mask is 0 when irq is enabled, and 1 when disabled. */
> - }
> -}
> -
> static int mtk_eint_irq_request_resources(struct irq_data *d)
> {
> struct mtk_eint *eint = irq_data_get_irq_chip_data(d);
> @@ -384,7 +375,6 @@ static void mtk_eint_irq_handler(struct irq_desc *desc)
>
> int mtk_eint_do_suspend(struct mtk_eint *eint)
> {
> - mtk_eint_chip_read_mask(eint, eint->base, eint->cur_mask);
> mtk_eint_chip_write_mask(eint, eint->base, eint->wake_mask);
>
> return 0;
> --
> 2.21.0.593.g511ec345e18-goog
>
Re: [PATCH -next] net: ethernet: mediatek: fix mtk_eth_soc build errors & warnings
Hi Randy, Thanks for your help. But it seems I've already made the same fixup for the problem in http://lists.infradead.org/pipermail/linux-mediatek/2019-June/020301.html as soon as the kbuild test robot reported this. Sean On Tue, 2019-06-04 at 22:52 -0700, Randy Dunlap wrote: > From: Randy Dunlap > > Fix build errors in Mediatek mtk_eth_soc driver. > > It looks like these 3 source files were meant to be linked together > since 2 of them are library-like functions, > but they are currently being built as 3 loadable modules. > > Fixes these build errors: > > WARNING: modpost: missing MODULE_LICENSE() in > drivers/net/ethernet/mediatek/mtk_eth_path.o > WARNING: modpost: missing MODULE_LICENSE() in > drivers/net/ethernet/mediatek/mtk_sgmii.o > ERROR: "mtk_sgmii_init" [drivers/net/ethernet/mediatek/mtk_eth_soc.ko] > undefined! > ERROR: "mtk_setup_hw_path" [drivers/net/ethernet/mediatek/mtk_eth_soc.ko] > undefined! > ERROR: "mtk_sgmii_setup_mode_force" > [drivers/net/ethernet/mediatek/mtk_eth_soc.ko] undefined! > ERROR: "mtk_sgmii_setup_mode_an" > [drivers/net/ethernet/mediatek/mtk_eth_soc.ko] undefined! > ERROR: "mtk_w32" [drivers/net/ethernet/mediatek/mtk_eth_path.ko] undefined! > ERROR: "mtk_r32" [drivers/net/ethernet/mediatek/mtk_eth_path.ko] undefined! > > This changes the loadable module name from mtk_eth_soc to mtk_eth. > I didn't see a way to leave it as mtk_eth_soc. > > Reported-by: kbuild test robot > Signed-off-by: Randy Dunlap > Cc: Sean Wang > Cc: John Crispin > Cc: Felix Fietkau > Cc: Nelson Chang > --- > drivers/net/ethernet/mediatek/Makefile |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > --- linux-next-20190604.orig/drivers/net/ethernet/mediatek/Makefile > +++ linux-next-20190604/drivers/net/ethernet/mediatek/Makefile > @@ -3,5 +3,5 @@ > # Makefile for the Mediatek SoCs built-in ethernet macs > # > > -obj-$(CONFIG_NET_MEDIATEK_SOC) += mtk_eth_soc.o mtk_sgmii.o \ > - mtk_eth_path.o > +obj-$(CONFIG_NET_MEDIATEK_SOC) += mtk_eth.o > +mtk_eth-y := mtk_eth_soc.o mtk_sgmii.o mtk_eth_path.o > >
Re: [PATCH v2 0/2] pinctrl: mediatek: mt8183: Add support for wake sources
On Thu, May 16, 2019 at 4:56 AM Linus Walleij wrote: > > On Wed, May 8, 2019 at 9:33 AM Nicolas Boichat wrote: > > > This adds support for wake sources in pinctrl-mtk-common-v2, and > > pinctrl-mt8183. Without this patch, all interrupts that are left > > enabled on suspend act as wake sources (and wake sources without > > interrupt enabled do not). > > > > Changes since v1: > > - Move changes from mtk-common-v2 to mtk-pinctrl-paris, as > >recommended by Sean, to keep better separation between eint > >and pinctrl-common features. > > > > Nicolas Boichat (2): > > pinctrl: mediatek: Add pm_ops to pinctrl-paris > > pinctrl: mediatek: mt8183: Add mtk_pinctrl_paris_pm_ops > > All seems to look fair to me, but I need some official ACK from > Sean on these. > sure, it looks good to me and thanks for Nicolas' help Acked-by: Sean Wang > I see there is some discussion on a related patch set which > also has two patches so I am a but confused how mature the > two patch sets are? Are they at all related? > > Yours, > Linus Walleij
Re: [PATCH 1/2] pinctrl: mediatek: Add mtk_eint_pm_ops to common-v2
Hi, Nicolas
On Thu, May 2, 2019 at 5:53 PM Nicolas Boichat wrote:
>
> On Thu, May 2, 2019 at 9:48 PM Yingjoe Chen wrote:
> >
> > On Mon, 2019-04-29 at 11:25 +0800, Nicolas Boichat wrote:
> > > pinctrl variants that include pinctrl-mtk-common-v2.h (and not
> > > pinctrl-mtk-common.h) also need to use mtk_eint_pm_ops to setup
> > > wake mask properly, so copy over the pm_ops to v2.
> > >
> > > It is not easy to merge the 2 copies (or move
> > > mtk_eint_suspend/resume to mtk-eint.c), as we need to
> > > dereference pctrl->eint, and struct mtk_pinctrl *pctl has a
> > > different structure definition for v1 and v2.
> > >
> > > Signed-off-by: Nicolas Boichat
> > > Reviewed-by: Chuanjia Liu
> > > ---
> > > .../pinctrl/mediatek/pinctrl-mtk-common-v2.c | 19 +++
> > > .../pinctrl/mediatek/pinctrl-mtk-common-v2.h | 1 +
> > > 2 files changed, 20 insertions(+)
> > >
> > > diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> > > b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> > > index 20e1c890e73b30c..7e19b5a4748eafe 100644
> > > --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> > > +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> > > @@ -723,3 +723,22 @@ int mtk_pinconf_adv_drive_get(struct mtk_pinctrl *hw,
> > >
> > > return 0;
> > > }
> > > +
> > > +static int mtk_eint_suspend(struct device *device)
> > > +{
> > > + struct mtk_pinctrl *pctl = dev_get_drvdata(device);
> > > +
> > > + return mtk_eint_do_suspend(pctl->eint);
> > > +}
> > > +
> > > +static int mtk_eint_resume(struct device *device)
> > > +{
> > > + struct mtk_pinctrl *pctl = dev_get_drvdata(device);
> > > +
> > > + return mtk_eint_do_resume(pctl->eint);
> > > +}
> > > +
> > > +const struct dev_pm_ops mtk_eint_pm_ops = {
> > > + .suspend_noirq = mtk_eint_suspend,
> > > + .resume_noirq = mtk_eint_resume,
> > > +};
> >
> > This is identical to the one in pinctrl-mtk-common.c and will have name
> > clash if both pinctrl-mtk-common.c and pinctrl-mtk-common-v2.c are
> > built.
> >
> > It would be better if we try to merge both version into mtk-eint.c, this
> > way we could also remove some global functions.
>
> Argh, I didn't think about the name clash, you're right. I guess the
> easy way is to rename this one mtk_eint_pm_ops_v2 ...
>
> As highlighted in the commit message, it's tricky to merge the 2 sets
> of functions, they look identical, but they actually work on struct
> mtk_pinctrl that are defined differently (in
> pinctrl-mtk-common[-v2].h), so the ->eint member is at different
> addresses...
>
> I don't really see a way around this... Unless we want to change
> platform_set_drvdata(pdev, pctl); to pass another type of structure
> that could be shared (but I think that'll make the code fairly
> verbose, with another layer of indirection). Or just assign struct
> mtk_eint to that, since that contains pctl so we could get back the
> struct mtk_pinctrl from that, but that feels ugly as well...
>
I agree on renaming would make the thing simple. but I wouldn't like
to rename to mtk_eint_pm_ops_v2 since this would make people
misunderstand that is mtk_eint_v2.
How about renaming to mtk_paris_pinctrl_pm_ops and then place related
logic you added into pinctrl-paris.c? Because I prefer to keep pure
pinctrl hardware operations in pinctrl-mtk-common-v2.c, and for
relevant to other modules (mtk eint) or others subsystem (device tree
binding, GPIO subsytem, PM something like that) they should be moved
to pinctrl-paris.c or pinctrl-moore.c
Sean
> >
> > Joe.C
> >
> >
> >
> > ___
> > Linux-mediatek mailing list
> > linux-media...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH 1/2] serial: 8250-mtk: add follow control
Hi, Long
I guess you should mean "flow control", not "follow control".
And the commit subject should be swapped between 1/2 and 2/2,
otherwise, the subject is inconsistent with its own content.
Sean
On Thu, Apr 25, 2019 at 1:41 AM Long Cheng wrote:
>
> Add SW and HW follow control function.
>
> Signed-off-by: Long Cheng
> ---
> drivers/tty/serial/8250/8250_mtk.c | 60
> ++--
> 1 file changed, 37 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/tty/serial/8250/8250_mtk.c
> b/drivers/tty/serial/8250/8250_mtk.c
> index c1fdbc0..959fd85 100644
> --- a/drivers/tty/serial/8250/8250_mtk.c
> +++ b/drivers/tty/serial/8250/8250_mtk.c
> @@ -21,12 +21,14 @@
>
> #include "8250.h"
>
> -#define UART_MTK_HIGHS 0x09/* Highspeed register */
> -#define UART_MTK_SAMPLE_COUNT 0x0a/* Sample count register */
> -#define UART_MTK_SAMPLE_POINT 0x0b/* Sample point register */
> +#define MTK_UART_HIGHS 0x09/* Highspeed register */
> +#define MTK_UART_SAMPLE_COUNT 0x0a/* Sample count register */
> +#define MTK_UART_SAMPLE_POINT 0x0b/* Sample point register */
> #define MTK_UART_RATE_FIX 0x0d/* UART Rate Fix Register */
> -
> #define MTK_UART_DMA_EN0x13/* DMA Enable register */
> +#define MTK_UART_RXTRI_AD 0x14/* RX Trigger address */
> +#define MTK_UART_FRACDIV_L 0x15/* Fractional divider LSB address */
> +#define MTK_UART_FRACDIV_M 0x16/* Fractional divider MSB address */
> #define MTK_UART_DMA_EN_TX 0x2
> #define MTK_UART_DMA_EN_RX 0x5
>
> @@ -46,6 +48,7 @@ enum dma_rx_status {
> struct mtk8250_data {
> int line;
> unsigned intrx_pos;
> + unsigned intclk_count;
> struct clk *uart_clk;
> struct clk *bus_clk;
> struct uart_8250_dma*dma;
> @@ -196,9 +199,15 @@ static void mtk8250_shutdown(struct uart_port *port)
> mtk8250_set_termios(struct uart_port *port, struct ktermios *termios,
> struct ktermios *old)
> {
> + unsigned short fraction_L_mapping[] = {
> + 0, 1, 0x5, 0x15, 0x55, 0x57, 0x57, 0x77, 0x7F, 0xFF, 0xFF
> + };
> + unsigned short fraction_M_mapping[] = {
> + 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 3
> + };
> struct uart_8250_port *up = up_to_u8250p(port);
> + unsigned int baud, quot, fraction;
> unsigned long flags;
> - unsigned int baud, quot;
>
> #ifdef CONFIG_SERIAL_8250_DMA
> if (up->dma) {
> @@ -214,7 +223,7 @@ static void mtk8250_shutdown(struct uart_port *port)
> serial8250_do_set_termios(port, termios, old);
>
> /*
> -* Mediatek UARTs use an extra highspeed register (UART_MTK_HIGHS)
> +* Mediatek UARTs use an extra highspeed register (MTK_UART_HIGHS)
> *
> * We need to recalcualte the quot register, as the claculation
> depends
> * on the vaule in the highspeed register.
> @@ -230,18 +239,11 @@ static void mtk8250_shutdown(struct uart_port *port)
> port->uartclk / 16 / UART_DIV_MAX,
> port->uartclk);
>
> - if (baud <= 115200) {
> - serial_port_out(port, UART_MTK_HIGHS, 0x0);
> + if (baud < 115200) {
> + serial_port_out(port, MTK_UART_HIGHS, 0x0);
> quot = uart_get_divisor(port, baud);
> - } else if (baud <= 576000) {
> - serial_port_out(port, UART_MTK_HIGHS, 0x2);
> -
> - /* Set to next lower baudrate supported */
> - if ((baud == 50) || (baud == 576000))
> - baud = 460800;
> - quot = DIV_ROUND_UP(port->uartclk, 4 * baud);
> } else {
> - serial_port_out(port, UART_MTK_HIGHS, 0x3);
> + serial_port_out(port, MTK_UART_HIGHS, 0x3);
> quot = DIV_ROUND_UP(port->uartclk, 256 * baud);
> }
>
> @@ -258,17 +260,29 @@ static void mtk8250_shutdown(struct uart_port *port)
> /* reset DLAB */
> serial_port_out(port, UART_LCR, up->lcr);
>
> - if (baud > 460800) {
> + if (baud >= 115200) {
> unsigned int tmp;
>
> - tmp = DIV_ROUND_CLOSEST(port->uartclk, quot * baud);
> - serial_port_out(port, UART_MTK_SAMPLE_COUNT, tmp - 1);
> - serial_port_out(port, UART_MTK_SAMPLE_POINT,
> - (tmp - 2) >> 1);
> + tmp = (port->uartclk / (baud * quot)) - 1;
> + serial_port_out(port, MTK_UART_SAMPLE_COUNT, tmp);
> + serial_port_out(port, MTK_UART_SAMPLE_POINT,
> + (tmp >> 1) - 1);
> +
> + /*count fraction to set fractoin register */
> + fraction = ((port->uartclk * 100) / baud / quot) % 100;
> +
Re: [PATCH 1/1] pinctrl: Add alternative way for specifying register bases
Hi, Light
I knew your idea, but the patch really depends on a separate patch
about the update of the corresponding dt-binding document for your
newly added properties. You can find out dt-binding document
pinctrl-mt8183.txt in linux-pinctrl.git branch for-next that is just
being merged two weeks ago and can be reused for all drivers using the
same base.
So, to keep the work moving on, we need a v2 including the change on
dt-binding document and the patch and then see some inputs from Rob
and Matthias.
Sean
On Mon, Apr 15, 2019 at 11:40 PM Light Hsieh wrote:
>
> Hi, Sean:
>
> On Sun, 2019-04-14 at 16:01 -0700, Sean Wang wrote:
> > Hi, Light
> >
> > On Thu, Apr 11, 2019 at 8:15 PM Light Hsieh
> > wrote:
> > >
> > > The orginal PINCTRL_MTK_PARIS/PINCTRL_MTK_MOORE need more effort for
> > > specifying register bases when porting platform driver:
> > > 1. Write mt_pinctrl_register_base_name[] array in pinctrl-mt.c
> > >to specify names of register bases, for exmaple:
> > >
> > > static const char * const mt6765_pinctrl_register_base_names[] = {
> > > "iocfg0", "iocfg1", "iocfg2", "iocfg3", "iocfg4",
> > > "iocfg5",
> > > "iocfg6", "iocfg7",
> > > };
> > > 2. Write reg = <...>, ..., <...>; in mt.dts to specify register
> > >bases. Each member of reg contain address range cloned from
> > >pre-generated devicetree node.
> > > 3. Write reg-names = "...", ..., "..."; in mt.dts to specify
> > >names of register bases. The sequence of names in reg-names shall match
> > >sequence of names that specified in pinctrl-mt.c.
> > >Besides, the seqeunce of names in reg-names shall also match sequence
> > > of
> > >address range in reg, for exmaple:
> > >
> > > pio: pinctrl {
> > > compatible = "mediatek,mt6765-pinctrl";
> > > reg = <0 0x10005000 0 0x1000>,
> > > <0 0x10002C00 0 0x200>,
> > > <0 0x10002800 0 0x200>,
> > > <0 0x10002A00 0 0x200>,
> > > <0 0x10002000 0 0x200>,
> > > <0 0x10002200 0 0x200>,
> > > <0 0x10002400 0 0x200>,
> > > <0 0x10002600 0 0x200>,
> > > <0 0x1000b000 0 0x1000>;
> > > reg-names = "iocfg0", "iocfg1", "iocfg2", "iocfg3",
> > > "iocfg4", "iocfg5", "iocfg6", "iocfg7",
> > > "eint";
> > >
> > > To reduce porting effort, this patch add an alternative way for specifying
> > > register bases:
> > > 1. Write reg_bases = <...>, ..., <...>; and reg_base_eint = <>;
> > >in mt.dtsi where members in reg_bases and are labels for
> > >pre-generated devicetree nodes, for example:
> > > pio: pinctrl {
> > > compatible = "mediatek,mt6765-pinctrl";
> > > reg_bases = <>,
> > > <>,
> > > <>,
> > > <>,
> > > <>,
> > > <>,
> > > <>,
> > > <>,
> > > <>;
> > > reg_base_eint = <>;
> >
> > reg and reg-names both are generic properties used in all of DT-based
> > device and driver, described in
> > Documentation/devicetree/bindings/resource-names.txt, but reg_based
> > and reg_base_eint aren't.
> >
> > If these properties are not hardware specific related, I personally
> > will encourage reusing those generic properties and relevant helpers
> > because those generic properties handling in the base driver are
> > almost bug-free, well maintained and even keep be extended in the
> > future. This way can help driver people put more concentration on
> > hardware specific stuff in the driver.
> >
>
> This modification is somewhat like mtk pinctrl driver V1. In V1,
> you may have the following devicetree (refer
Re: [PATCH] pinctrl: mediatek: Add MT8516 Pinctrl driver
Hi, Fabien
After reusing the eint_regs common, the result looks good to me
On Tue, Apr 16, 2019 at 1:33 AM Fabien Parent wrote:
>
> This commit adds the pinctrl driver for the MediaTek's MT8516 SoC.
>
> Signed-off-by: Fabien Parent
Acked-by: Sean Wang
> ---
>
> v2:
> * Don't assign anything to eint_regs since the registers are similar
> to the default provided by the common pinctrl driver.
>
> ---
> drivers/pinctrl/mediatek/Kconfig |7 +
> drivers/pinctrl/mediatek/Makefile |1 +
> drivers/pinctrl/mediatek/pinctrl-mt8516.c | 362 +
> drivers/pinctrl/mediatek/pinctrl-mtk-mt8516.h | 1182 +
> 4 files changed, 1552 insertions(+)
> create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt8516.c
> create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt8516.h
>
> diff --git a/drivers/pinctrl/mediatek/Kconfig
> b/drivers/pinctrl/mediatek/Kconfig
> index a005cbccb4f7..26ed5dca1460 100644
> --- a/drivers/pinctrl/mediatek/Kconfig
> +++ b/drivers/pinctrl/mediatek/Kconfig
> @@ -113,6 +113,13 @@ config PINCTRL_MT8183
> default ARM64 && ARCH_MEDIATEK
> select PINCTRL_MTK_PARIS
>
> +config PINCTRL_MT8516
> + bool "Mediatek MT8516 pin control"
> + depends on OF
> + depends on ARM64 || COMPILE_TEST
> + default ARM64 && ARCH_MEDIATEK
> + select PINCTRL_MTK
> +
> # For PMIC
> config PINCTRL_MT6397
> bool "Mediatek MT6397 pin control"
> diff --git a/drivers/pinctrl/mediatek/Makefile
> b/drivers/pinctrl/mediatek/Makefile
> index 4b4e2eaf6f2d..a74325abd877 100644
> --- a/drivers/pinctrl/mediatek/Makefile
> +++ b/drivers/pinctrl/mediatek/Makefile
> @@ -17,4 +17,5 @@ obj-$(CONFIG_PINCTRL_MT7623) += pinctrl-mt7623.o
> obj-$(CONFIG_PINCTRL_MT7629) += pinctrl-mt7629.o
> obj-$(CONFIG_PINCTRL_MT8173) += pinctrl-mt8173.o
> obj-$(CONFIG_PINCTRL_MT8183) += pinctrl-mt8183.o
> +obj-$(CONFIG_PINCTRL_MT8516) += pinctrl-mt8516.o
> obj-$(CONFIG_PINCTRL_MT6397) += pinctrl-mt6397.o
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8516.c
> b/drivers/pinctrl/mediatek/pinctrl-mt8516.c
> new file mode 100644
> index ..b375426aa61e
> --- /dev/null
> +++ b/drivers/pinctrl/mediatek/pinctrl-mt8516.c
> @@ -0,0 +1,362 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019 MediaTek Inc.
> + * Author: Min.Guo
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "pinctrl-mtk-common.h"
> +#include "pinctrl-mtk-mt8516.h"
> +
> +static const struct mtk_drv_group_desc mt8516_drv_grp[] = {
> + /* 0E4E8SR 4/8/12/16 */
> + MTK_DRV_GRP(4, 16, 1, 2, 4),
> + /* 0E2E4SR 2/4/6/8 */
> + MTK_DRV_GRP(2, 8, 1, 2, 2),
> + /* E8E4E2 2/4/6/8/10/12/14/16 */
> + MTK_DRV_GRP(2, 16, 0, 2, 2)
> +};
> +
> +static const struct mtk_pin_drv_grp mt8516_pin_drv[] = {
> + MTK_PIN_DRV_GRP(0, 0xd00, 0, 0),
> + MTK_PIN_DRV_GRP(1, 0xd00, 0, 0),
> + MTK_PIN_DRV_GRP(2, 0xd00, 0, 0),
> + MTK_PIN_DRV_GRP(3, 0xd00, 0, 0),
> + MTK_PIN_DRV_GRP(4, 0xd00, 0, 0),
> +
> + MTK_PIN_DRV_GRP(5, 0xd00, 4, 0),
> + MTK_PIN_DRV_GRP(6, 0xd00, 4, 0),
> + MTK_PIN_DRV_GRP(7, 0xd00, 4, 0),
> + MTK_PIN_DRV_GRP(8, 0xd00, 4, 0),
> + MTK_PIN_DRV_GRP(9, 0xd00, 4, 0),
> + MTK_PIN_DRV_GRP(10, 0xd00, 4, 0),
> +
> + MTK_PIN_DRV_GRP(11, 0xd00, 8, 0),
> + MTK_PIN_DRV_GRP(12, 0xd00, 8, 0),
> + MTK_PIN_DRV_GRP(13, 0xd00, 8, 0),
> +
> + MTK_PIN_DRV_GRP(14, 0xd00, 12, 2),
> + MTK_PIN_DRV_GRP(15, 0xd00, 12, 2),
> + MTK_PIN_DRV_GRP(16, 0xd00, 12, 2),
> + MTK_PIN_DRV_GRP(17, 0xd00, 12, 2),
> +
> + MTK_PIN_DRV_GRP(18, 0xd10, 0, 0),
> + MTK_PIN_DRV_GRP(19, 0xd10, 0, 0),
> + MTK_PIN_DRV_GRP(20, 0xd10, 0, 0),
> +
> + MTK_PIN_DRV_GRP(21, 0xd00, 12, 2),
> + MTK_PIN_DRV_GRP(22, 0xd00, 12, 2),
> + MTK_PIN_DRV_GRP(23, 0xd00, 12, 2),
> +
> + MTK_PIN_DRV_GRP(24, 0xd00, 8, 0),
> + MTK_PIN_DRV_GRP(25, 0xd00, 8, 0),
> +
> + MTK_PIN_DRV_GRP(26, 0xd10, 4, 1),
> + MTK_PIN_DRV_GRP(27, 0xd10, 4, 1),
> + MTK_PIN_DRV_GRP(28, 0xd10, 4, 1),
> + MTK_PIN_DRV_GRP(29, 0xd10, 4, 1),
> + MTK_PIN_DRV_GRP(30, 0xd10, 4, 1),
> +
> + MTK_PIN_DRV_GRP(31, 0xd10, 8, 1),
> + MTK_PIN_DRV_GRP(32, 0xd10, 8, 1),
> + MTK_PIN_DRV_GRP(33, 0xd10, 8, 1),
> +
> + MTK_PIN_DRV_GRP(34, 0xd10, 12, 0),
> + MTK_PIN_DRV_GRP(35, 0xd10, 12, 0),
> +
>
Re: [PATCH 1/1] pinctrl: Add alternative way for specifying register bases
Hi, Light
On Thu, Apr 11, 2019 at 8:15 PM Light Hsieh wrote:
>
> The orginal PINCTRL_MTK_PARIS/PINCTRL_MTK_MOORE need more effort for
> specifying register bases when porting platform driver:
> 1. Write mt_pinctrl_register_base_name[] array in pinctrl-mt.c
>to specify names of register bases, for exmaple:
>
> static const char * const mt6765_pinctrl_register_base_names[] = {
> "iocfg0", "iocfg1", "iocfg2", "iocfg3", "iocfg4", "iocfg5",
> "iocfg6", "iocfg7",
> };
> 2. Write reg = <...>, ..., <...>; in mt.dts to specify register
>bases. Each member of reg contain address range cloned from
>pre-generated devicetree node.
> 3. Write reg-names = "...", ..., "..."; in mt.dts to specify
>names of register bases. The sequence of names in reg-names shall match
>sequence of names that specified in pinctrl-mt.c.
>Besides, the seqeunce of names in reg-names shall also match sequence of
>address range in reg, for exmaple:
>
> pio: pinctrl {
> compatible = "mediatek,mt6765-pinctrl";
> reg = <0 0x10005000 0 0x1000>,
> <0 0x10002C00 0 0x200>,
> <0 0x10002800 0 0x200>,
> <0 0x10002A00 0 0x200>,
> <0 0x10002000 0 0x200>,
> <0 0x10002200 0 0x200>,
> <0 0x10002400 0 0x200>,
> <0 0x10002600 0 0x200>,
> <0 0x1000b000 0 0x1000>;
> reg-names = "iocfg0", "iocfg1", "iocfg2", "iocfg3",
> "iocfg4", "iocfg5", "iocfg6", "iocfg7",
> "eint";
>
> To reduce porting effort, this patch add an alternative way for specifying
> register bases:
> 1. Write reg_bases = <...>, ..., <...>; and reg_base_eint = <>;
>in mt.dtsi where members in reg_bases and are labels for
>pre-generated devicetree nodes, for example:
> pio: pinctrl {
> compatible = "mediatek,mt6765-pinctrl";
> reg_bases = <>,
> <>,
> <>,
> <>,
> <>,
> <>,
> <>,
> <>,
> <>;
> reg_base_eint = <>;
reg and reg-names both are generic properties used in all of DT-based
device and driver, described in
Documentation/devicetree/bindings/resource-names.txt, but reg_based
and reg_base_eint aren't.
If these properties are not hardware specific related, I personally
will encourage reusing those generic properties and relevant helpers
because those generic properties handling in the base driver are
almost bug-free, well maintained and even keep be extended in the
future. This way can help driver people put more concentration on
hardware specific stuff in the driver.
>
>Since this pre-generated nodes had already specify address range,
>it is not necessary to specify address range again in pinctrl node.
>
> Using this way, porting effort is reduced and therefore typo can occur with
> less chance.
>
> Change-Id: I55f5e328919f4f736ca4b9f8d1593e069f179637
> ---
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 19 +---
> drivers/pinctrl/mediatek/pinctrl-paris.c | 62
>
> 2 files changed, 54 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> index b1c3684..16b4863 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
>
> #include "mtk-eint.h"
> #include "pinctrl-mtk-common-v2.h"
> @@ -310,7 +311,7 @@ static int mtk_xt_set_gpio_as_eint(void *data, unsigned
> long eint_n)
>
> int mtk_build_eint(struct mtk_pinctrl *hw, struct platform_device *pdev)
> {
> - struct device_node *np = pdev->dev.of_node;
> + struct device_node *np = pdev->dev.of_node, *node;
> struct resource *res;
>
> if (!IS_ENABLED(CONFIG_EINT_MTK))
> @@ -323,13 +324,19 @@ int mtk_build_eint(struct mtk_pinctrl *hw, struct
> platform_device *pdev)
> if (!hw->eint)
> return -ENOMEM;
>
> - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "eint");
> - if (!res) {
> - dev_err(>dev, "Unable to get eint resource\n");
> - return -ENODEV;
> + node = of_parse_phandle(np, "reg_base_eint", 0);
> + if (node) {
> + hw->eint->base = of_iomap(node, 0);
> + } else {
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> + "eint");
> + if (!res) {
> + dev_err(>dev, "Unable to get eint
Re: [PATCH] pinctrl: Add kernel config PINCTRL_MTK_V2
Hi, Light On Thu, Apr 11, 2019 at 2:32 AM Light Hsieh wrote: > > Since no single Mediatek chip use code for PINCTRL_MTK and code for > PINCTRL_MTK_MOORE/PINCTRL_MTK_PARIS simultaneously, it is better to use > different config to determine if related code will be built or not on > building non-generic kernel. > > Add kernel config PINCTRL_MTK_V2 selected by either PINCTRL_MTK_MOORE > or PINCTRL_MTK_PARIS. > Use PINCTRL_MTK and PINCTRL_MTK_V2 to control building of > drivers/pinctrl/medaitek/. > Remove selection of EINT_MTK from PINCTRL_MTK since code for EINT_MTK is > only related to PINCTRL_MTK_MOORE/PINCTRL_MTK_PARIS, i.e. PINCTL_MTK_V2. > PINCTRL_MTK also depends on EINT_MTK such as the symbol mtk_eint_do_init, it is a common library for the two kinds of the pinctrl core. > --- > drivers/pinctrl/Makefile | 3 ++- > drivers/pinctrl/mediatek/Kconfig | 15 --- > 2 files changed, 14 insertions(+), 4 deletions(-) > > diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile > index 712184b..fcee0e0 100644 > --- a/drivers/pinctrl/Makefile > +++ b/drivers/pinctrl/Makefile > @@ -65,6 +65,7 @@ obj-$(CONFIG_PINCTRL_SUNXI) += sunxi/ > obj-y += ti/ > obj-$(CONFIG_PINCTRL_UNIPHIER) += uniphier/ > obj-$(CONFIG_ARCH_VT8500) += vt8500/ > -obj-y += mediatek/ > +obj-$(CONFIG_PINCTRL_MTK) += mediatek/ > +obj-$(CONFIG_PINCTRL_MTK_V2) += mediatek/ I would think it is good if deciding V1 or not should be done inside the vendor directory and the change also would cause COMPILE_TEST not be applied to > obj-$(CONFIG_PINCTRL_ZX) += zte/ > obj-y += cirrus/ > diff --git a/drivers/pinctrl/mediatek/Kconfig > b/drivers/pinctrl/mediatek/Kconfig > index a005cbc..5e26462 100644 > --- a/drivers/pinctrl/mediatek/Kconfig > +++ b/drivers/pinctrl/mediatek/Kconfig > @@ -2,10 +2,15 @@ menu "MediaTek pinctrl drivers" > depends on ARCH_MEDIATEK || COMPILE_TEST > > config EINT_MTK > - bool "MediaTek External Interrupt Support" > - depends on PINCTRL_MTK || PINCTRL_MTK_MOORE || PINCTRL_MTK_PARIS || > COMPILE_TEST > + bool "MediaTek External Interrupt driver that is based on > PINCTRL_MTK_V2" > + depends on PINCTRL_MTK_MOORE || PINCTRL_MTK_PARIS || COMPILE_TEST > select GPIOLIB > select IRQ_DOMAIN > + help > + Say yes here to enable support for MediaTek External Interrupt > + (EINT) driver based on PINCTRL_MTK version 2. > + This driver is combined with MediaTek Pinctrl driver version 2 > + so PINCTRL_MTK_V2 shall be set first. > > config PINCTRL_MTK > bool > @@ -13,9 +18,11 @@ config PINCTRL_MTK > select PINMUX > select GENERIC_PINCONF > select GPIOLIB > - select EINT_MTK > select OF_GPIO > > +config PINCTRL_MTK_V2 > + bool "MediaTek Pinctrl Support V2" > + > config PINCTRL_MTK_MOORE > bool > depends on OF > @@ -24,6 +31,7 @@ config PINCTRL_MTK_MOORE > select GENERIC_PINMUX_FUNCTIONS > select GPIOLIB > select OF_GPIO > + select PINCTRL_MTK_V2 > > config PINCTRL_MTK_PARIS > bool > @@ -33,6 +41,7 @@ config PINCTRL_MTK_PARIS > select GPIOLIB > select EINT_MTK > select OF_GPIO > + select PINCTRL_MTK_V2 > > # For ARMv7 SoCs > config PINCTRL_MT2701 > -- > 1.8.1.1.dirty >
Re: [PATCH 16/24] pinctrl: mediatek: Add MT8516 Pinctrl driver
Hi, Fabien
On Sat, Mar 23, 2019 at 2:17 PM Fabien Parent wrote:
>
> Signed-off-by: Fabien Parent
> ---
> drivers/pinctrl/mediatek/Kconfig |7 +
> drivers/pinctrl/mediatek/Makefile |1 +
> drivers/pinctrl/mediatek/pinctrl-mt8516.c | 384 ++
> drivers/pinctrl/mediatek/pinctrl-mtk-mt8516.h | 1182 +
> 4 files changed, 1574 insertions(+)
> create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt8516.c
> create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt8516.h
>
> diff --git a/drivers/pinctrl/mediatek/Kconfig
> b/drivers/pinctrl/mediatek/Kconfig
> index a005cbccb4f7..26ed5dca1460 100644
> --- a/drivers/pinctrl/mediatek/Kconfig
> +++ b/drivers/pinctrl/mediatek/Kconfig
> @@ -113,6 +113,13 @@ config PINCTRL_MT8183
> default ARM64 && ARCH_MEDIATEK
> select PINCTRL_MTK_PARIS
>
> +config PINCTRL_MT8516
> + bool "Mediatek MT8516 pin control"
> + depends on OF
> + depends on ARM64 || COMPILE_TEST
> + default ARM64 && ARCH_MEDIATEK
> + select PINCTRL_MTK
> +
> # For PMIC
> config PINCTRL_MT6397
> bool "Mediatek MT6397 pin control"
> diff --git a/drivers/pinctrl/mediatek/Makefile
> b/drivers/pinctrl/mediatek/Makefile
> index 4b4e2eaf6f2d..a74325abd877 100644
> --- a/drivers/pinctrl/mediatek/Makefile
> +++ b/drivers/pinctrl/mediatek/Makefile
> @@ -17,4 +17,5 @@ obj-$(CONFIG_PINCTRL_MT7623) += pinctrl-mt7623.o
> obj-$(CONFIG_PINCTRL_MT7629) += pinctrl-mt7629.o
> obj-$(CONFIG_PINCTRL_MT8173) += pinctrl-mt8173.o
> obj-$(CONFIG_PINCTRL_MT8183) += pinctrl-mt8183.o
> +obj-$(CONFIG_PINCTRL_MT8516) += pinctrl-mt8516.o
> obj-$(CONFIG_PINCTRL_MT6397) += pinctrl-mt6397.o
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8516.c
> b/drivers/pinctrl/mediatek/pinctrl-mt8516.c
> new file mode 100644
> index ..1e965f119eca
> --- /dev/null
> +++ b/drivers/pinctrl/mediatek/pinctrl-mt8516.c
> @@ -0,0 +1,384 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019 MediaTek Inc.
> + * Author: Min.Guo
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "pinctrl-mtk-common.h"
> +#include "pinctrl-mtk-mt8516.h"
> +
> +static const struct mtk_drv_group_desc mt8516_drv_grp[] = {
> + /* 0E4E8SR 4/8/12/16 */
> + MTK_DRV_GRP(4, 16, 1, 2, 4),
> + /* 0E2E4SR 2/4/6/8 */
> + MTK_DRV_GRP(2, 8, 1, 2, 2),
> + /* E8E4E2 2/4/6/8/10/12/14/16 */
> + MTK_DRV_GRP(2, 16, 0, 2, 2)
> +};
> +
> +static const struct mtk_pin_drv_grp mt8516_pin_drv[] = {
> + MTK_PIN_DRV_GRP(0, 0xd00, 0, 0),
> + MTK_PIN_DRV_GRP(1, 0xd00, 0, 0),
> + MTK_PIN_DRV_GRP(2, 0xd00, 0, 0),
> + MTK_PIN_DRV_GRP(3, 0xd00, 0, 0),
> + MTK_PIN_DRV_GRP(4, 0xd00, 0, 0),
> +
> + MTK_PIN_DRV_GRP(5, 0xd00, 4, 0),
> + MTK_PIN_DRV_GRP(6, 0xd00, 4, 0),
> + MTK_PIN_DRV_GRP(7, 0xd00, 4, 0),
> + MTK_PIN_DRV_GRP(8, 0xd00, 4, 0),
> + MTK_PIN_DRV_GRP(9, 0xd00, 4, 0),
> + MTK_PIN_DRV_GRP(10, 0xd00, 4, 0),
> +
> + MTK_PIN_DRV_GRP(11, 0xd00, 8, 0),
> + MTK_PIN_DRV_GRP(12, 0xd00, 8, 0),
> + MTK_PIN_DRV_GRP(13, 0xd00, 8, 0),
> +
> + MTK_PIN_DRV_GRP(14, 0xd00, 12, 2),
> + MTK_PIN_DRV_GRP(15, 0xd00, 12, 2),
> + MTK_PIN_DRV_GRP(16, 0xd00, 12, 2),
> + MTK_PIN_DRV_GRP(17, 0xd00, 12, 2),
> +
> + MTK_PIN_DRV_GRP(18, 0xd10, 0, 0),
> + MTK_PIN_DRV_GRP(19, 0xd10, 0, 0),
> + MTK_PIN_DRV_GRP(20, 0xd10, 0, 0),
> +
> + MTK_PIN_DRV_GRP(21, 0xd00, 12, 2),
> + MTK_PIN_DRV_GRP(22, 0xd00, 12, 2),
> + MTK_PIN_DRV_GRP(23, 0xd00, 12, 2),
> +
> + MTK_PIN_DRV_GRP(24, 0xd00, 8, 0),
> + MTK_PIN_DRV_GRP(25, 0xd00, 8, 0),
> +
> + MTK_PIN_DRV_GRP(26, 0xd10, 4, 1),
> + MTK_PIN_DRV_GRP(27, 0xd10, 4, 1),
> + MTK_PIN_DRV_GRP(28, 0xd10, 4, 1),
> + MTK_PIN_DRV_GRP(29, 0xd10, 4, 1),
> + MTK_PIN_DRV_GRP(30, 0xd10, 4, 1),
> +
> + MTK_PIN_DRV_GRP(31, 0xd10, 8, 1),
> + MTK_PIN_DRV_GRP(32, 0xd10, 8, 1),
> + MTK_PIN_DRV_GRP(33, 0xd10, 8, 1),
> +
> + MTK_PIN_DRV_GRP(34, 0xd10, 12, 0),
> + MTK_PIN_DRV_GRP(35, 0xd10, 12, 0),
> +
> + MTK_PIN_DRV_GRP(36, 0xd20, 0, 0),
> + MTK_PIN_DRV_GRP(37, 0xd20, 0, 0),
> + MTK_PIN_DRV_GRP(38, 0xd20, 0, 0),
> + MTK_PIN_DRV_GRP(39, 0xd20, 0, 0),
> +
> + MTK_PIN_DRV_GRP(40, 0xd20, 4, 1),
> +
> + MTK_PIN_DRV_GRP(41, 0xd20, 8, 1),
> + MTK_PIN_DRV_GRP(42, 0xd20, 8, 1),
> + MTK_PIN_DRV_GRP(43, 0xd20, 8, 1),
> +
> + MTK_PIN_DRV_GRP(44, 0xd20, 12, 1),
> + MTK_PIN_DRV_GRP(45, 0xd20, 12, 1),
> + MTK_PIN_DRV_GRP(46, 0xd20, 12, 1),
> + MTK_PIN_DRV_GRP(47, 0xd20, 12, 1),
> +
> + MTK_PIN_DRV_GRP(48, 0xd30, 0, 1),
> + MTK_PIN_DRV_GRP(49, 0xd30, 0, 1),
> + MTK_PIN_DRV_GRP(50, 0xd30, 0, 1),
> + MTK_PIN_DRV_GRP(51, 0xd30, 0, 1),
> +
> + MTK_PIN_DRV_GRP(54, 0xd30, 8,
Re: [PATCH v6 0/2] Bluetooth: btusb: Add protocol support for MediaTek USB devices
This is just a gentle ping of the series On Fri, 2019-01-25 at 07:26 +0800, sean.w...@mediatek.com wrote: > From: Sean Wang > > v6: > * fix drivers/bluetooth/btusb.c:2683:2-3: Unneeded semicolon based reported > by [1] > * update power-on sequence with adding neccesary tci sleep comand to set up > low-power environmnet and a delay to wait the device to be stable. > * sort variables declarations in reverse xmas order. > > [1] > http://lists.infradead.org/pipermail/linux-mediatek/2019-January/017017.html > > v5: > * rebase to latest code base. > * change the subject prefix. > * change the place the firmware located at. > > v4: > * use new BTUSB_TX_WAIT_VND_EVT instead of BTMTKUSB_TX_WAIT_VND_EVT > to avoid definition conflict and to fix bulk data transfer fails. > * use the bluetooth-next as the base > > v3: > add fixes and enhancements based on [1] > * reuse flags and evt_skb btusb already had > * add ctrl_anchor and the corresponding handling > * apply mtk specific recv function > * add more comments explaining wmt ctrl urbs behavior. > > [1] > http://lists.infradead.org/pipermail/linux-mediatek/2018-August/014724.html > > v2: > > add fixes and enhancements based on [1] > * include /sys/kernel/debug/usb/devices portion in the commit message. > * turn default into n for config BT_HCIBTUSB_MTK in Kconfig > * only add MediaTek support to btusb.c > * drop cmd_sync callback usage > * use __hci_cmd_send to send WMT commands > * add wait event handling similar to what is being done in btmtkuart.c > * submit a control IN URB similar to interrupt IN URB on demand for the WMT > commands during setup > * add cosmetic changes > > [1] > http://lists.infradead.org/pipermail/linux-mediatek/2018-August/014650.html > http://lists.infradead.org/pipermail/linux-mediatek/2018-August/014656.html > > v1: > > This adds the support of enabling MT7668U and MT7663U Bluetooth > function running on the top of btusb driver. The patch also adds > a newly created file mtkbt.c able to be reused independently from > the transport type such as UART, USB and SDIO. > > Sean Wang (2): > Bluetooth: btusb: Add protocol support for MediaTek MT7668U USB > devices > Bluetooth: btusb: Add protocol support for MediaTek MT7663U USB > devices > > drivers/bluetooth/Kconfig | 11 + > drivers/bluetooth/btusb.c | 581 ++ > 2 files changed, 592 insertions(+) >
Re: [PATCH] Bluetooth: mediatek: Fixed incorrect type in assignment
this is just a gentle ping
On Tue, 2019-03-05 at 08:14 +0800, sean.w...@mediatek.com wrote:
> From: Sean Wang
>
> Fixed warning: incorrect type in assignment reported by kbuild test robot.
> The detailed warning is shown as below.
>
> make ARCH=x86_64 allmodconfig
> make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
>
> All warnings (new ones prefixed by >>):
>
> btmtkuart.c:671:18: sparse:warning: incorrect type in assignment
> (different base types)
> btmtkuart.c:671:18: sparse:expected unsigned int [usertype] baudrate
> btmtkuart.c:671:18: sparse:got restricted __le32 [usertype]
>
> sparse warnings: (new ones prefixed by >>)
> btmtkuart.c:671:18: sparse: warning: incorrect type in assignment
> (different base types)
> btmtkuart.c:671:18: sparse:expected unsigned int [usertype] baudrate
> btmtkuart.c:671:18: sparse:got restricted __le32 [usertype]
>
> vim +671 drivers/bluetooth/btmtkuart.c
>
>659
>660static int btmtkuart_change_baudrate(struct hci_dev *hdev)
>661{
>662struct btmtkuart_dev *bdev = hci_get_drvdata(hdev);
>663struct btmtk_hci_wmt_params wmt_params;
>664u32 baudrate;
>665u8 param;
>666int err;
>667
>668/* Indicate the device to enter the probe state the
> host is
>669 * ready to change a new baudrate.
>670 */
> > 671baudrate = cpu_to_le32(bdev->desired_speed);
>672wmt_params.op = MTK_WMT_HIF;
>
> Fixes: 22eaf6c9946a ("Bluetooth: mediatek: add support for MediaTek MT7663U
> and MT7668U UART devices")
> Reported-by: kernel test robot
> Signed-off-by: Sean Wang
> ---
> drivers/bluetooth/btmtkuart.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/bluetooth/btmtkuart.c b/drivers/bluetooth/btmtkuart.c
> index b0b680dd69f4..f5dbeec8e274 100644
> --- a/drivers/bluetooth/btmtkuart.c
> +++ b/drivers/bluetooth/btmtkuart.c
> @@ -661,7 +661,7 @@ static int btmtkuart_change_baudrate(struct hci_dev *hdev)
> {
> struct btmtkuart_dev *bdev = hci_get_drvdata(hdev);
> struct btmtk_hci_wmt_params wmt_params;
> - u32 baudrate;
> + __le32 baudrate;
> u8 param;
> int err;
>
Re: [PATCH] Bluetooth: mediatek: fix uninitialized symbol errors in btmtksdio_rx_packet
On Mon, 2019-03-18 at 17:55 +0100, Marcel Holtmann wrote:
> Hi Sean,
>
> > Fixed all the below warnings. They would probably cause the following
> > error handling path would use the uninitialized value and then produce
> > unexpected behavior.
> >
> > drivers/bluetooth/btmtksdio.c:470:2: warning: ‘old_len’ may be used
> > uninitialized in this function [-Wmaybe-uninitialized]
> > print_hex_dump(KERN_ERR, "err sdio rx: ", DUMP_PREFIX_NONE, 4, 1,
> > ^
> > old_data, old_len, true);
> >
> > drivers/bluetooth/btmtksdio.c:376:15: note: ‘old_len’ was declared here
> > unsigned int old_len;
> > ^~~
> > drivers/bluetooth/btmtksdio.c:470:2: warning: ‘old_data’ may be used
> > uninitialized in this function [-Wmaybe-uninitialized]
> > print_hex_dump(KERN_ERR, "err sdio rx: ", DUMP_PREFIX_NONE, 4, 1,
> > ^
> > old_data, old_len, true);
> >
> > drivers/bluetooth/btmtksdio.c:375:17: note: ‘old_data’ was declared here
> > unsigned char *old_data;
> > ^~~~
> >
> > Fixes: d74eef2834b5 ("Bluetooth: mediatek: add support for MediaTek MT7663S
> > and MT7668S SDIO devices")
> > Reported-by: Dan Carpenter
> > Reported-by: Marcel Holtmann
> > Signed-off-by: Sean Wang
> > ---
> > drivers/bluetooth/btmtksdio.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/bluetooth/btmtksdio.c b/drivers/bluetooth/btmtksdio.c
> > index b4b8320f279e..23cf63888bac 100644
> > --- a/drivers/bluetooth/btmtksdio.c
> > +++ b/drivers/bluetooth/btmtksdio.c
> > @@ -372,8 +372,8 @@ static int btmtksdio_rx_packet(struct btmtksdio_dev
> > *bdev, u16 rx_size)
> > const struct h4_recv_pkt *pkts = mtk_recv_pkts;
> > int pkts_count = ARRAY_SIZE(mtk_recv_pkts);
> > struct mtkbtsdio_hdr *sdio_hdr;
> > - unsigned char *old_data;
> > - unsigned int old_len;
> > + unsigned char *old_data = NULL;
> > + unsigned int old_len = 0;
> > int err, i, pad_size;
> > struct sk_buff *skb;
> > u16 dlen;
>
> or instead just remove this whole old_len + old_data stuff anyway since it is
> rather pointless. Or at least introduce a proper error path for sdio_readsb
> since you know when it fails, there is no point in writing the SKB.
>
> Regards
>
I will remove the old_len and old_data in the next version for the issue
because the error path for sdio_readsb seems wrong.
My initial purpose is that I would like to add a error path for these
packets which are successful at sdio_readsb but fail at packet format
parsing. I will update the error path for packet format error in
a separate patch.
> Marcel
>
Re: [PATCH] dma: mediatek: addres minor style issues flagged by clang-format.
On Sun, Mar 17, 2019 at 1:45 AM Armando Miraglia wrote:
>
> Running clang-format on mtk-hsdma.c I noticed that few lines would not
> need to be wrapped, since they fit 80 columns. This change changes such
> lines to better fit the style-guide.
>
> Signed-off-by: Armando Miraglia
> ---
> drivers/staging/mt7621-dma/mtk-hsdma.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/mt7621-dma/mtk-hsdma.c
> b/drivers/staging/mt7621-dma/mtk-hsdma.c
> index 97571f1d697b..74c374f7bef4 100644
> --- a/drivers/staging/mt7621-dma/mtk-hsdma.c
> +++ b/drivers/staging/mt7621-dma/mtk-hsdma.c
> @@ -264,8 +264,7 @@ static void mtk_hsdma_reset(struct mtk_hsdam_engine
> *hsdma,
> /* init desc value */
> for (i = 0; i < HSDMA_DESCS_NUM; i++) {
> chan->tx_ring[i].addr0 = 0;
> - chan->tx_ring[i].flags = HSDMA_DESC_LS0 |
> - HSDMA_DESC_DONE;
> + chan->tx_ring[i].flags = HSDMA_DESC_LS0 | HSDMA_DESC_DONE;
> }
> for (i = 0; i < HSDMA_DESCS_NUM; i++) {
> chan->rx_ring[i].addr0 = 0;
> @@ -435,8 +434,7 @@ static irqreturn_t mtk_hsdma_irq(int irq, void *devid)
> if (likely(status & HSDMA_INT_RX_Q0))
> tasklet_schedule(>task);
> else
> - dev_dbg(hsdma->ddev.dev, "unhandle irq status %08x\n",
> - status);
> + dev_dbg(hsdma->ddev.dev, "unhandle irq status %08x\n",
> status);
> /* clean intr bits */
> mtk_hsdma_write(hsdma, HSDMA_REG_INT_STATUS, status);
>
Acked-by: Sean Wang
> --
> 2.21.0.360.g471c308f928-goog
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH v2 3/9] dt-bindings: mfd: Add compatible for the MediaTek MT6358 PMIC
On Mon, Mar 11, 2019 at 3:06 PM Rob Herring wrote: > > On Mon, Mar 11, 2019 at 12:19:32PM -0700, Sean Wang wrote: > > Hi, > > > > Always put the patches about dt-binding changes at the head of the > > series to let the related maintainer more easily find them. > > > > On Sun, Mar 10, 2019 at 8:48 PM Hsin-Hsiung Wang > > wrote: > > > > > > This adds compatible for the MediaTek MT6358 PMIC. > > > > > > Signed-off-by: Hsin-Hsiung Wang > > > --- > > > Documentation/devicetree/bindings/mfd/mt6397.txt | 11 --- > > > 1 file changed, 8 insertions(+), 3 deletions(-) > > > > > > diff --git a/Documentation/devicetree/bindings/mfd/mt6397.txt > > > b/Documentation/devicetree/bindings/mfd/mt6397.txt > > > index 0ebd08a..62f1c17 100644 > > > --- a/Documentation/devicetree/bindings/mfd/mt6397.txt > > > +++ b/Documentation/devicetree/bindings/mfd/mt6397.txt > > > @@ -17,22 +17,27 @@ > > > Documentation/devicetree/bindings/soc/mediatek/pwrap.txt > > > This document describes the binding for MFD device and its sub module. > > > > > > Required properties: > > > -compatible: "mediatek,mt6397" or "mediatek,mt6323" > > > +compatible: > > > + "mediatek,mt6323" for PMIC MT6323 > > > + "mediatek,mt6358" for PMIC MT6358 > > > + "mediatek,mt6397" for PMIC MT6397 > > > > don't change anything not related MT6358 > > Reformatting like this is preferred. > Sure, it's fine to me for the purpose. > Rob
Re: [PATCH v1 1/2] mmc: add SDIO identifiers for MediaTek Bluetooth devices
On Mon, 2019-03-11 at 17:38 +0100, Marcel Holtmann wrote: > Hi Sean, > > > The SDIO identifier for MediaTek Bluetooth devices were defined in the > > MediaTek Bluetooth driver. Moving the definitions in MMC header file > > seems common sense. > > > > Signed-off-by: Sean Wang > > --- > > include/linux/mmc/sdio_ids.h | 2 ++ > > 1 file changed, 2 insertions(+) > > patch has been applied to bluetooth-next tree. > > Can we also update the sdio.ids database inside systemd. > > https://github.com/systemd/systemd/blob/master/hwdb/sdio.ids > Sure, thanks for showing me the information and I'll update the database for the card. > Regards > > Marcel > > > ___ > Linux-mediatek mailing list > linux-media...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH v1 2/2] Bluetooth: mediatek: add support for MediaTek MT7663S and MT7668S SDIO devices
On Mon, 2019-03-11 at 17:38 +0100, Marcel Holtmann wrote: > Hi Sean, > > > This adds the support of enabling MT7663S and MT7668S SDIO-based > > Bluetooth function. > > > > There are quite many differences between MT766[3,8]S and standard > > Bluetooth SDIO devices such as Type-A and Type-B devices. For example, > > MT766[3,8]S have its own SDIO registers layout, definition, SDIO packet > > format, and the specific flow should be programmed on them to complete > > the device initialization and low power control and so on. > > > > Currently, there are many independent programming sequences from the > > transport which are exactly the same as the ones in btusb.c about MediaTek > > support [1] and btmtkuart.c. We can try to split the transport independent > > Bluetooth setups on the advance, place them into the common files and allow > > varous transport drivers to reuse them in the future. > > > > [1] > > http://lists.infradead.org/pipermail/linux-mediatek/2019-January/017074.html > > > > Signed-off-by: Sean Wang > > --- > > drivers/bluetooth/Kconfig | 11 + > > drivers/bluetooth/Makefile| 1 + > > drivers/bluetooth/btmtksdio.c | 979 ++ > > 3 files changed, 991 insertions(+) > > create mode 100644 drivers/bluetooth/btmtksdio.c > > patch has been applied to bluetooth-next tree. > > You also need to send an extra patch providing a fix for this: > Thanks for the reporting. I'll fix it up soon. > CC drivers/bluetooth/btmtksdio.o > drivers/bluetooth/btmtksdio.c: In function ‘btmtksdio_interrupt’: > drivers/bluetooth/btmtksdio.c:470:2: warning: ‘old_len’ may be used > uninitialized in this function [-Wmaybe-uninitialized] > print_hex_dump(KERN_ERR, "err sdio rx: ", DUMP_PREFIX_NONE, 4, 1, > ^ > old_data, old_len, true); > > drivers/bluetooth/btmtksdio.c:376:15: note: ‘old_len’ was declared here > unsigned int old_len; >^~~ > drivers/bluetooth/btmtksdio.c:470:2: warning: ‘old_data’ may be used > uninitialized in this function [-Wmaybe-uninitialized] > print_hex_dump(KERN_ERR, "err sdio rx: ", DUMP_PREFIX_NONE, 4, 1, > ^ > old_data, old_len, true); > > drivers/bluetooth/btmtksdio.c:375:17: note: ‘old_data’ was declared here > unsigned char *old_data; > ^~~~ > > And can we actually introduce module_sdio_driver similar to module_usb_driver. > Sure, I can add and apply module_sdio_driver on the driver and then see if Ulf like it. > Regards > > Marcel >
Re: [PATCH v2 8/9] rtc: mt6397: fix alarm register overwrite
Hi,
On Sun, Mar 10, 2019 at 8:49 PM Hsin-Hsiung Wang
wrote:
>
> From: Ran Bi
>
> Alarm registers high byte was reserved for other functions.
> This add mask in alarm registers operation functions.
> This also fix error condition in interrupt handler.
>
> Fixes: fc2979118f3f ("rtc: mediatek: Add MT6397 RTC driver")
>
add a Cc: sta...@vger.kernel.org here to apply to all stable kernels
for the critical fixup patch.
> Signed-off-by: Ran Bi
> ---
> drivers/rtc/rtc-mt6397.c | 47 +--
> 1 file changed, 33 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c
> index e9a25ec..f85f1fc 100644
> --- a/drivers/rtc/rtc-mt6397.c
> +++ b/drivers/rtc/rtc-mt6397.c
> @@ -55,6 +55,14 @@
>
> #define RTC_AL_SEC 0x0018
>
> +#define RTC_AL_SEC_MASK0x003f
> +#define RTC_AL_MIN_MASK0x003f
> +#define RTC_AL_HOU_MASK0x001f
> +#define RTC_AL_DOM_MASK0x001f
> +#define RTC_AL_DOW_MASK0x0007
> +#define RTC_AL_MTH_MASK0x000f
> +#define RTC_AL_YEA_MASK0x007f
> +
> #define RTC_PDN2 0x002e
> #define RTC_PDN2_PWRON_ALARM BIT(4)
>
> @@ -111,7 +119,7 @@ static irqreturn_t mtk_rtc_irq_handler_thread(int irq,
> void *data)
> irqen = irqsta & ~RTC_IRQ_EN_AL;
> mutex_lock(>lock);
> if (regmap_write(rtc->regmap, rtc->addr_base + RTC_IRQ_EN,
> -irqen) < 0)
> +irqen) == 0)
> mtk_rtc_write_trigger(rtc);
> mutex_unlock(>lock);
>
> @@ -233,12 +241,12 @@ static int mtk_rtc_read_alarm(struct device *dev,
> struct rtc_wkalrm *alm)
> alm->pending = !!(pdn2 & RTC_PDN2_PWRON_ALARM);
> mutex_unlock(>lock);
>
> - tm->tm_sec = data[RTC_OFFSET_SEC];
> - tm->tm_min = data[RTC_OFFSET_MIN];
> - tm->tm_hour = data[RTC_OFFSET_HOUR];
> - tm->tm_mday = data[RTC_OFFSET_DOM];
> - tm->tm_mon = data[RTC_OFFSET_MTH];
> - tm->tm_year = data[RTC_OFFSET_YEAR];
> + tm->tm_sec = data[RTC_OFFSET_SEC] & RTC_AL_SEC_MASK;
> + tm->tm_min = data[RTC_OFFSET_MIN] & RTC_AL_MIN_MASK;
> + tm->tm_hour = data[RTC_OFFSET_HOUR] & RTC_AL_HOU_MASK;
> + tm->tm_mday = data[RTC_OFFSET_DOM] & RTC_AL_DOM_MASK;
> + tm->tm_mon = data[RTC_OFFSET_MTH] & RTC_AL_MTH_MASK;
> + tm->tm_year = data[RTC_OFFSET_YEAR] & RTC_AL_YEA_MASK;
>
> tm->tm_year += RTC_MIN_YEAR_OFFSET;
> tm->tm_mon--;
> @@ -259,14 +267,25 @@ static int mtk_rtc_set_alarm(struct device *dev, struct
> rtc_wkalrm *alm)
> tm->tm_year -= RTC_MIN_YEAR_OFFSET;
> tm->tm_mon++;
>
> - data[RTC_OFFSET_SEC] = tm->tm_sec;
> - data[RTC_OFFSET_MIN] = tm->tm_min;
> - data[RTC_OFFSET_HOUR] = tm->tm_hour;
> - data[RTC_OFFSET_DOM] = tm->tm_mday;
> - data[RTC_OFFSET_MTH] = tm->tm_mon;
> - data[RTC_OFFSET_YEAR] = tm->tm_year;
> -
> mutex_lock(>lock);
> + ret = regmap_bulk_read(rtc->regmap, rtc->addr_base + RTC_AL_SEC,
> + data, RTC_OFFSET_COUNT);
> + if (ret < 0)
> + goto exit;
> +
Why did we need an additional regmap_bulk_read here? I would suppose
data[RTC_OFFSET_*] & ~(RTC_AL_*_MASK) is always equal to 0.
It might be another fixup since change is not being mentioned in the
git message.
> + data[RTC_OFFSET_SEC] = ((data[RTC_OFFSET_SEC] & ~(RTC_AL_SEC_MASK)) |
> + (tm->tm_sec & RTC_AL_SEC_MASK));
> + data[RTC_OFFSET_MIN] = ((data[RTC_OFFSET_MIN] & ~(RTC_AL_MIN_MASK)) |
> + (tm->tm_min & RTC_AL_MIN_MASK));
> + data[RTC_OFFSET_HOUR] = ((data[RTC_OFFSET_HOUR] & ~(RTC_AL_HOU_MASK))
> |
> + (tm->tm_hour & RTC_AL_HOU_MASK));
> + data[RTC_OFFSET_DOM] = ((data[RTC_OFFSET_DOM] & ~(RTC_AL_DOM_MASK)) |
> + (tm->tm_mday & RTC_AL_DOM_MASK));
> + data[RTC_OFFSET_MTH] = ((data[RTC_OFFSET_MTH] & ~(RTC_AL_MTH_MASK)) |
> + (tm->tm_mon & RTC_AL_MTH_MASK));
> + data[RTC_OFFSET_YEAR] = ((data[RTC_OFFSET_YEAR] & ~(RTC_AL_YEA_MASK))
> |
> + (tm->tm_year & RTC_AL_YEA_MASK));
> +
> if (alm->enabled) {
> ret = regmap_bulk_write(rtc->regmap,
> rtc->addr_base + RTC_AL_SEC,
> --
> 1.9.1
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH v2 7/9] arm64: dts: mt6358: add PMIC MT6358 related nodes
Hi,
On Sun, Mar 10, 2019 at 8:49 PM Hsin-Hsiung Wang
wrote:
>
> add PMIC MT6358 related nodes which is for mt8183 platform
>
s/MT8183/mt8183/
> Signed-off-by: Hsin-Hsiung Wang
> ---
> arch/arm64/boot/dts/mediatek/mt6358.dtsi | 318
> +++
> 1 file changed, 318 insertions(+)
> create mode 100644 arch/arm64/boot/dts/mediatek/mt6358.dtsi
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt6358.dtsi
> b/arch/arm64/boot/dts/mediatek/mt6358.dtsi
> new file mode 100644
> index 000..a7c02ab
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt6358.dtsi
> @@ -0,0 +1,318 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright (c) 2019 MediaTek Inc.
> + */
> +
> + {
> + pmic: mt6358 {
use a generic name
pmic {
> + compatible = "mediatek,mt6358";
> + interrupt-controller;
> + interrupt-parent = <>;
> + interrupts = <182 IRQ_TYPE_LEVEL_HIGH 190 0>;
> + #interrupt-cells = <2>;
> +
> + mt6358codec: mt6358codec {
use a generic name
audio-codec {
> + compatible = "mediatek,mt6358-sound";
> + };
> +
> + mt6358regulator: mt6358regulator {
use a generic name
regulators {
> + compatible = "mediatek,mt6358-regulator";
> +
> + mt6358_vdram1_reg: buck_vdram1 {
> + regulator-compatible = "buck_vdram1";
> + regulator-name = "vdram1";
> + regulator-min-microvolt = <50>;
> + regulator-max-microvolt = <2087500>;
> + regulator-ramp-delay = <12500>;
> + regulator-enable-ramp-delay = <0>;
> + regulator-always-on;
> + regulator-allowed-modes = <0 1>;
> + };
add a blank line here and for all below occurrences
> + mt6358_vcore_reg: buck_vcore {
> + regulator-name = "vcore";
> + regulator-min-microvolt = <50>;
> + regulator-max-microvolt = <1293750>;
> + regulator-ramp-delay = <6250>;
> + regulator-enable-ramp-delay = <200>;
> + regulator-always-on;
> + regulator-allowed-modes = <0 1>;
> + };
> + mt6358_vpa_reg: buck_vpa {
> + regulator-name = "vpa";
> + regulator-min-microvolt = <50>;
> + regulator-max-microvolt = <365>;
> + regulator-ramp-delay = <5>;
> + regulator-enable-ramp-delay = <250>;
> + regulator-allowed-modes = <0 1>;
> + };
> + mt6358_vproc11_reg: buck_vproc11 {
> + regulator-name = "vproc11";
> + regulator-min-microvolt = <50>;
> + regulator-max-microvolt = <1293750>;
> + regulator-ramp-delay = <6250>;
> + regulator-enable-ramp-delay = <200>;
> + regulator-always-on;
> + regulator-allowed-modes = <0 1>;
> + };
> + mt6358_vproc12_reg: buck_vproc12 {
> + regulator-name = "vproc12";
> + regulator-min-microvolt = <50>;
> + regulator-max-microvolt = <1293750>;
> + regulator-ramp-delay = <6250>;
> + regulator-enable-ramp-delay = <200>;
> + regulator-always-on;
> + regulator-allowed-modes = <0 1>;
> + };
> + mt6358_vgpu_reg: buck_vgpu {
> + regulator-name = "vgpu";
> + regulator-min-microvolt = <50>;
> + regulator-max-microvolt = <1293750>;
> + regulator-ramp-delay = <6250>;
> + regulator-enable-ramp-delay = <200>;
> + regulator-allowed-modes = <0 1>;
> + };
> + mt6358_vs2_reg: buck_vs2 {
> + regulator-name = "vs2";
> + regulator-min-microvolt = <50>;
> + regulator-max-microvolt = <2087500>;
> + regulator-ramp-delay = <12500>;
> +
Re: [PATCH v2 5/9] mfd: Add support for the MediaTek MT6358 PMIC
Hi,
On Sun, Mar 10, 2019 at 8:50 PM Hsin-Hsiung Wang
wrote:
>
> This adds support for the MediaTek MT6358 PMIC. This is a
> multifunction device with the following sub modules:
>
> - Regulator
> - RTC
> - Codec
> - Interrupt
>
> It is interfaced to the host controller using SPI interface
> by a proprietary hardware called PMIC wrapper or pwrap.
> MT6358 MFD is a child device of the pwrap.
>
> Signed-off-by: Hsin-Hsiung Wang
> ---
> drivers/mfd/Makefile |2 +-
> drivers/mfd/mt6358-irq.c | 236 +
> drivers/mfd/mt6397-core.c| 63 +-
> include/linux/mfd/mt6358/core.h | 158 +++
> include/linux/mfd/mt6358/registers.h | 1926
> ++
Shrink the core.h and register.h as much as possible, please.
Otherwise, we probably leave too many not useful and even dead things
in the kernel source. We can add those required definitions once the
related new driver is being introduced.
Sean
> include/linux/mfd/mt6397/core.h |3 +
> 6 files changed, 2386 insertions(+), 2 deletions(-)
> create mode 100644 drivers/mfd/mt6358-irq.c
> create mode 100644 include/linux/mfd/mt6358/core.h
> create mode 100644 include/linux/mfd/mt6358/registers.h
>
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 088e249..50be021 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -230,7 +230,7 @@ obj-$(CONFIG_INTEL_SOC_PMIC)+= intel-soc-pmic.o
> obj-$(CONFIG_INTEL_SOC_PMIC_BXTWC) += intel_soc_pmic_bxtwc.o
> obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC) += intel_soc_pmic_chtwc.o
> obj-$(CONFIG_INTEL_SOC_PMIC_CHTDC_TI) += intel_soc_pmic_chtdc_ti.o
> -obj-$(CONFIG_MFD_MT6397) += mt6397-core.o mt6397-irq.o
> +obj-$(CONFIG_MFD_MT6397) += mt6397-core.o mt6397-irq.o mt6358-irq.o
>
> obj-$(CONFIG_MFD_ALTERA_A10SR) += altera-a10sr.o
> obj-$(CONFIG_MFD_SUN4I_GPADC) += sun4i-gpadc.o
> diff --git a/drivers/mfd/mt6358-irq.c b/drivers/mfd/mt6358-irq.c
> new file mode 100644
> index 000..2941d87
> --- /dev/null
> +++ b/drivers/mfd/mt6358-irq.c
> @@ -0,0 +1,236 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright (c) 2019 MediaTek Inc.
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static struct irq_top_t mt6358_ints[] = {
> + MT6358_TOP_GEN(BUCK),
> + MT6358_TOP_GEN(LDO),
> + MT6358_TOP_GEN(PSC),
> + MT6358_TOP_GEN(SCK),
> + MT6358_TOP_GEN(BM),
> + MT6358_TOP_GEN(HK),
> + MT6358_TOP_GEN(AUD),
> + MT6358_TOP_GEN(MISC),
> +};
> +
> +static int parsing_hwirq_to_top_group(unsigned int hwirq)
> +{
> + int top_group;
> +
> + for (top_group = 1; top_group < ARRAY_SIZE(mt6358_ints); top_group++)
> {
> + if (mt6358_ints[top_group].hwirq_base > hwirq) {
> + top_group--;
> + break;
> + }
> + }
> + return top_group;
> +}
> +
> +static void pmic_irq_enable(struct irq_data *data)
> +{
> + unsigned int hwirq = irqd_to_hwirq(data);
> + struct mt6397_chip *chip = irq_data_get_irq_chip_data(data);
> + struct pmic_irq_data *irqd = chip->irq_data;
> +
> + irqd->enable_hwirq[hwirq] = true;
> +}
> +
> +static void pmic_irq_disable(struct irq_data *data)
> +{
> + unsigned int hwirq = irqd_to_hwirq(data);
> + struct mt6397_chip *chip = irq_data_get_irq_chip_data(data);
> + struct pmic_irq_data *irqd = chip->irq_data;
> +
> + irqd->enable_hwirq[hwirq] = false;
> +}
> +
> +static void pmic_irq_lock(struct irq_data *data)
> +{
> + struct mt6397_chip *chip = irq_data_get_irq_chip_data(data);
> +
> + mutex_lock(>irqlock);
> +}
> +
> +static void pmic_irq_sync_unlock(struct irq_data *data)
> +{
> + unsigned int i, top_gp, en_reg, int_regs, shift;
> + struct mt6397_chip *chip = irq_data_get_irq_chip_data(data);
> + struct pmic_irq_data *irqd = chip->irq_data;
> +
> + for (i = 0; i < irqd->num_pmic_irqs; i++) {
> + if (irqd->enable_hwirq[i] ==
> + irqd->cache_hwirq[i])
> + continue;
> +
> + top_gp = parsing_hwirq_to_top_group(i);
> + int_regs = mt6358_ints[top_gp].num_int_bits /
> MT6358_REG_WIDTH;
> + en_reg = mt6358_ints[top_gp].en_reg +
> + mt6358_ints[top_gp].en_reg_shift * int_regs;
> + shift = (i - mt6358_ints[top_gp].hwirq_base) %
> MT6358_REG_WIDTH;
> + regmap_update_bits(chip->regmap, en_reg, BIT(shift),
> + irqd->enable_hwirq[i] << shift);
> + irqd->cache_hwirq[i] = irqd->enable_hwirq[i];
> + }
> + mutex_unlock(>irqlock);
> +}
> +
> +static int pmic_irq_set_type(struct irq_data *data, unsigned int type)
> +{
> + return 0;
> +}
> +
> +static struct irq_chip
Re: [PATCH v2 4/9] regulator: Add document for MT6358 regulator
Hi,
add a dt-bindings prefix and move the patch to the first order in the series.
On Sun, Mar 10, 2019 at 9:03 PM Hsin-Hsiung Wang
wrote:
>
> add dt-binding document for MediaTek MT6358 PMIC
>
> Signed-off-by: Hsin-Hsiung Wang
> ---
> .../bindings/regulator/mt6358-regulator.txt| 318
> +
> 1 file changed, 318 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/regulator/mt6358-regulator.txt
>
> diff --git a/Documentation/devicetree/bindings/regulator/mt6358-regulator.txt
> b/Documentation/devicetree/bindings/regulator/mt6358-regulator.txt
> new file mode 100644
> index 000..3ea8073
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/mt6358-regulator.txt
> @@ -0,0 +1,318 @@
> +Mediatek MT6358 Regulator
MediaTek
> +
> +Required properties:
> +- compatible: "mediatek,mt6358-regulator"
> +- mt6358regulator: List of regulators provided by this controller. It is
> named
mt6358regulator is not a required property, it is just a node alias.
> + according to its regulator type, buck_ and ldo_.
> + The definition for each of these nodes is defined using the standard
> binding
> + for regulators at
> Documentation/devicetree/bindings/regulator/regulator.txt.
> +
> +The valid names for regulators are::
> +BUCK:
> + buck_vdram1, buck_vcore, buck_vpa, buck_vproc11, buck_vproc12, buck_vgpu,
> + buck_vs2, buck_vmodem, buck_vs1
> +LDO:
> + ldo_vdram2, ldo_vsim1, ldo_vibr, ldo_vrf12, ldo_vio18, ldo_vusb,
> ldo_vcamio,
> + ldo_vcamd, ldo_vcn18, ldo_vfe28, ldo_vsram_proc11, ldo_vcn28,
> ldo_vsram_others,
> + ldo_vsram_gpu, ldo_vxo22, ldo_vefuse, ldo_vaux18, ldo_vmch, ldo_vbif28,
> + ldo_vsram_proc12, ldo_vcama1, ldo_vemc, ldo_vio28, ldo_va12, ldo_vrf18,
> + ldo_vcn33_bt, ldo_vcn33_wifi, ldo_vcama2, ldo_vmc, ldo_vldo28, ldo_vaud28,
> + ldo_vsim2
> +
> +Example:
> + pmic {
> + compatible = "mediatek,mt6358";
it is not necessary to document the PMIC part in the regulator binding
and you can refer to mt6380-regulator.txt or mt6323-regulator.txt
first to make the
style about the PMIC description and example be more consistent.
> +
> + mt6358regulator: mt6358regulator {
> + compatible = "mediatek,mt6358-regulator";
use a generic node, regulators, something like
regulators {
compatible = "mediatek,mt6358-regulator";
> +
> + mt6358_vdram1_reg: buck_vdram1 {
> + regulator-compatible = "buck_vdram1";
> + regulator-name = "vdram1";
> + regulator-min-microvolt = <50>;
> + regulator-max-microvolt = <2087500>;
> + regulator-ramp-delay = <12500>;
> + regulator-enable-ramp-delay = <0>;
> + regulator-always-on;
> + };
add a blank line between subnodes which includes all below occurrences
> + mt6358_vcore_reg: buck_vcore {
> + regulator-name = "vcore";
> + regulator-min-microvolt = <50>;
> + regulator-max-microvolt = <1293750>;
> + regulator-ramp-delay = <6250>;
> + regulator-enable-ramp-delay = <200>;
> + regulator-always-on;
> + };
> + mt6358_vpa_reg: buck_vpa {
> + regulator-name = "vpa";
> + regulator-min-microvolt = <50>;
> + regulator-max-microvolt = <365>;
> + regulator-ramp-delay = <5>;
> + regulator-enable-ramp-delay = <250>;
> + };
> + mt6358_vproc11_reg: buck_vproc11 {
> + regulator-name = "vproc11";
> + regulator-min-microvolt = <50>;
> + regulator-max-microvolt = <1293750>;
> + regulator-ramp-delay = <6250>;
> + regulator-enable-ramp-delay = <200>;
> + regulator-always-on;
> + };
> + mt6358_vproc12_reg: buck_vproc12 {
> + regulator-name = "vproc12";
> + regulator-min-microvolt = <50>;
> + regulator-max-microvolt = <1293750>;
> + regulator-ramp-delay = <6250>;
> + regulator-enable-ramp-delay = <200>;
> + regulator-always-on;
> + };
> + mt6358_vgpu_reg: buck_vgpu {
> +
Re: [PATCH v2 3/9] dt-bindings: mfd: Add compatible for the MediaTek MT6358 PMIC
Hi, Always put the patches about dt-binding changes at the head of the series to let the related maintainer more easily find them. On Sun, Mar 10, 2019 at 8:48 PM Hsin-Hsiung Wang wrote: > > This adds compatible for the MediaTek MT6358 PMIC. > > Signed-off-by: Hsin-Hsiung Wang > --- > Documentation/devicetree/bindings/mfd/mt6397.txt | 11 --- > 1 file changed, 8 insertions(+), 3 deletions(-) > > diff --git a/Documentation/devicetree/bindings/mfd/mt6397.txt > b/Documentation/devicetree/bindings/mfd/mt6397.txt > index 0ebd08a..62f1c17 100644 > --- a/Documentation/devicetree/bindings/mfd/mt6397.txt > +++ b/Documentation/devicetree/bindings/mfd/mt6397.txt > @@ -17,22 +17,27 @@ Documentation/devicetree/bindings/soc/mediatek/pwrap.txt > This document describes the binding for MFD device and its sub module. > > Required properties: > -compatible: "mediatek,mt6397" or "mediatek,mt6323" > +compatible: > + "mediatek,mt6323" for PMIC MT6323 > + "mediatek,mt6358" for PMIC MT6358 > + "mediatek,mt6397" for PMIC MT6397 don't change anything not related MT6358 > > Optional subnodes: > > - rtc > Required properties: > - - compatible: "mediatek,mt6397-rtc" > + - compatible: "mediatek,mt6397-rtc" or "mediatek,mt6358-rtc" > - regulators > Required properties: > - compatible: "mediatek,mt6397-regulator" > see Documentation/devicetree/bindings/regulator/mt6397-regulator.txt > + - compatible: "mediatek,mt6358-regulator" > + see Documentation/devicetree/bindings/regulator/mt6358-regulator.txt > - compatible: "mediatek,mt6323-regulator" > see Documentation/devicetree/bindings/regulator/mt6323-regulator.txt > - codec > Required properties: > - - compatible: "mediatek,mt6397-codec" > + - compatible: "mediatek,mt6397-codec" or > "mediatek,mt6358-sound" why didn't we use a more consistent naming as mt6358-codec? > - clk > Required properties: > - compatible: "mediatek,mt6397-clk" > -- > 1.9.1 > > > ___ > Linux-mediatek mailing list > linux-media...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH v2 2/9] mfd: mt6397: extract irq related code from core driver
Hi,
I would expect the patch just a migration patch that just moves the
code and should not add something changed or something new in the
patch.
but a new mt6397_irq_pm_notifier is being added into mt6397-irq.c so I
guessed the patch is needed to be refined and split into several
patches on advance if required.
Sean
On Sun, Mar 10, 2019 at 8:49 PM Hsin-Hsiung Wang
wrote:
>
> In order to support different types of irq design, we decide to add
> separate irq drivers for different design and keep mt6397 mfd core
> simple and reusable to all generations of PMICs so far.
>
> Signed-off-by: Hsin-Hsiung Wang
> ---
> drivers/mfd/Makefile| 2 +-
> drivers/mfd/mt6397-core.c | 228
> ++--
> drivers/mfd/mt6397-irq.c| 214 +
> include/linux/mfd/mt6397/core.h | 12 +++
> 4 files changed, 259 insertions(+), 197 deletions(-)
> create mode 100644 drivers/mfd/mt6397-irq.c
>
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 12980a4..088e249 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -230,7 +230,7 @@ obj-$(CONFIG_INTEL_SOC_PMIC)+= intel-soc-pmic.o
> obj-$(CONFIG_INTEL_SOC_PMIC_BXTWC) += intel_soc_pmic_bxtwc.o
> obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC) += intel_soc_pmic_chtwc.o
> obj-$(CONFIG_INTEL_SOC_PMIC_CHTDC_TI) += intel_soc_pmic_chtdc_ti.o
> -obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
> +obj-$(CONFIG_MFD_MT6397) += mt6397-core.o mt6397-irq.o
>
> obj-$(CONFIG_MFD_ALTERA_A10SR) += altera-a10sr.o
> obj-$(CONFIG_MFD_SUN4I_GPADC) += sun4i-gpadc.o
> diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
> index acb9812..53f1edc 100644
> --- a/drivers/mfd/mt6397-core.c
> +++ b/drivers/mfd/mt6397-core.c
> @@ -12,7 +12,6 @@
> * GNU General Public License for more details.
> */
>
> -#include
> #include
> #include
> #include
> @@ -26,10 +25,6 @@
> #define MT6397_RTC_BASE0xe000
> #define MT6397_RTC_SIZE0x3e
>
> -#define MT6323_CHIP_ID 0x23
> -#define MT6391_CHIP_ID 0x91
> -#define MT6397_CHIP_ID 0x97
> -
> static const struct resource mt6397_rtc_resources[] = {
> {
> .start = MT6397_RTC_BASE,
> @@ -94,182 +89,24 @@
> }
> };
>
> -static void mt6397_irq_lock(struct irq_data *data)
> -{
> - struct mt6397_chip *mt6397 = irq_data_get_irq_chip_data(data);
> -
> - mutex_lock(>irqlock);
> -}
> -
> -static void mt6397_irq_sync_unlock(struct irq_data *data)
> -{
> - struct mt6397_chip *mt6397 = irq_data_get_irq_chip_data(data);
> -
> - regmap_write(mt6397->regmap, mt6397->int_con[0],
> -mt6397->irq_masks_cur[0]);
> - regmap_write(mt6397->regmap, mt6397->int_con[1],
> -mt6397->irq_masks_cur[1]);
> -
> - mutex_unlock(>irqlock);
> -}
> -
> -static void mt6397_irq_disable(struct irq_data *data)
> -{
> - struct mt6397_chip *mt6397 = irq_data_get_irq_chip_data(data);
> - int shift = data->hwirq & 0xf;
> - int reg = data->hwirq >> 4;
> -
> - mt6397->irq_masks_cur[reg] &= ~BIT(shift);
> -}
> -
> -static void mt6397_irq_enable(struct irq_data *data)
> -{
> - struct mt6397_chip *mt6397 = irq_data_get_irq_chip_data(data);
> - int shift = data->hwirq & 0xf;
> - int reg = data->hwirq >> 4;
> -
> - mt6397->irq_masks_cur[reg] |= BIT(shift);
> -}
> -
> -#ifdef CONFIG_PM_SLEEP
> -static int mt6397_irq_set_wake(struct irq_data *irq_data, unsigned int on)
> -{
> - struct mt6397_chip *mt6397 = irq_data_get_irq_chip_data(irq_data);
> - int shift = irq_data->hwirq & 0xf;
> - int reg = irq_data->hwirq >> 4;
> -
> - if (on)
> - mt6397->wake_mask[reg] |= BIT(shift);
> - else
> - mt6397->wake_mask[reg] &= ~BIT(shift);
> -
> - return 0;
> -}
> -#else
> -#define mt6397_irq_set_wake NULL
> -#endif
> -
> -static struct irq_chip mt6397_irq_chip = {
> - .name = "mt6397-irq",
> - .irq_bus_lock = mt6397_irq_lock,
> - .irq_bus_sync_unlock = mt6397_irq_sync_unlock,
> - .irq_enable = mt6397_irq_enable,
> - .irq_disable = mt6397_irq_disable,
> - .irq_set_wake = mt6397_irq_set_wake,
> +struct chip_data {
> + u32 cid_addr;
> };
>
> -static void mt6397_irq_handle_reg(struct mt6397_chip *mt6397, int reg,
> - int irqbase)
> -{
> - unsigned int status;
> - int i, irq, ret;
> -
> - ret = regmap_read(mt6397->regmap, reg, );
> - if (ret) {
> - dev_err(mt6397->dev, "Failed to read irq status: %d\n", ret);
> - return;
> - }
> -
> - for (i = 0; i < 16; i++) {
> - if (status & BIT(i)) {
> - irq = irq_find_mapping(mt6397->irq_domain, irqbase +
> i);
> - if (irq)
> - handle_nested_irq(irq);
> -
Re: [PATCH v2 1/9] mfd: mt6397: clean up code
Hi,
On Sun, Mar 10, 2019 at 8:48 PM Hsin-Hsiung Wang
wrote:
>
> clean up code
>
> Signed-off-by: Hsin-Hsiung Wang
> ---
> drivers/mfd/mt6397-core.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
> index 77b64bd..acb9812 100644
> --- a/drivers/mfd/mt6397-core.c
> +++ b/drivers/mfd/mt6397-core.c
> @@ -18,17 +18,17 @@
> #include
> #include
> #include
> -#include
> #include
> -#include
> +#include
> #include
> +#include
>
> #define MT6397_RTC_BASE0xe000
> #define MT6397_RTC_SIZE0x3e
>
> -#define MT6323_CID_CODE0x23
> -#define MT6391_CID_CODE0x91
> -#define MT6397_CID_CODE0x97
> +#define MT6323_CHIP_ID 0x23
> +#define MT6391_CHIP_ID 0x91
> +#define MT6397_CHIP_ID 0x97
>
It would be not necessary to simply rename the definition or do you
have a strong reason to do that?
> static const struct resource mt6397_rtc_resources[] = {
> {
> @@ -298,7 +298,7 @@ static int mt6397_probe(struct platform_device *pdev)
> return pmic->irq;
>
> switch (id & 0xff) {
> - case MT6323_CID_CODE:
> + case MT6323_CHIP_ID:
> pmic->int_con[0] = MT6323_INT_CON0;
> pmic->int_con[1] = MT6323_INT_CON1;
> pmic->int_status[0] = MT6323_INT_STATUS0;
> @@ -312,8 +312,8 @@ static int mt6397_probe(struct platform_device *pdev)
>0, pmic->irq_domain);
> break;
>
> - case MT6397_CID_CODE:
> - case MT6391_CID_CODE:
> + case MT6391_CHIP_ID:
> + case MT6397_CHIP_ID:
> pmic->int_con[0] = MT6397_INT_CON0;
> pmic->int_con[1] = MT6397_INT_CON1;
> pmic->int_status[0] = MT6397_INT_STATUS0;
> --
> 1.9.1
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH v11 1/4] dmaengine: 8250_mtk_dma: add MediaTek uart DMA support
Hi, Long
List some comments as the below and this week I will find a board to
test and then improve the driver.
Sean
On Wed, Mar 6, 2019 at 5:45 PM Long Cheng wrote:
>
> In DMA engine framework, add 8250 uart dma to support MediaTek uart.
> If MediaTek uart enabled(SERIAL_8250_MT6577), and want to improve
> the performance, can enable the function.
>
> Signed-off-by: Long Cheng
> ---
> drivers/dma/mediatek/Kconfig | 11 +
> drivers/dma/mediatek/Makefile |1 +
> drivers/dma/mediatek/mtk-uart-apdma.c | 660
> +
> 3 files changed, 672 insertions(+)
> create mode 100644 drivers/dma/mediatek/mtk-uart-apdma.c
>
> diff --git a/drivers/dma/mediatek/Kconfig b/drivers/dma/mediatek/Kconfig
> index 680fc05..ac49eb6 100644
> --- a/drivers/dma/mediatek/Kconfig
> +++ b/drivers/dma/mediatek/Kconfig
> @@ -24,3 +24,14 @@ config MTK_CQDMA
>
> This controller provides the channels which is dedicated to
> memory-to-memory transfer to offload from CPU.
> +
> +config MTK_UART_APDMA
> + tristate "MediaTek SoCs APDMA support for UART"
> + depends on OF && SERIAL_8250_MT6577
> + select DMA_ENGINE
> + select DMA_VIRTUAL_CHANNELS
> + help
> + Support for the UART DMA engine found on MediaTek MTK SoCs.
> + When SERIAL_8250_MT6577 is enabled, and if you want to use DMA,
> + you can enable the config. The DMA engine can only be used
> + with MediaTek SoCs.
> diff --git a/drivers/dma/mediatek/Makefile b/drivers/dma/mediatek/Makefile
> index 41bb381..61a6d29 100644
> --- a/drivers/dma/mediatek/Makefile
> +++ b/drivers/dma/mediatek/Makefile
> @@ -1,2 +1,3 @@
> +obj-$(CONFIG_MTK_UART_APDMA) += mtk-uart-apdma.o
> obj-$(CONFIG_MTK_HSDMA) += mtk-hsdma.o
> obj-$(CONFIG_MTK_CQDMA) += mtk-cqdma.o
> diff --git a/drivers/dma/mediatek/mtk-uart-apdma.c
> b/drivers/dma/mediatek/mtk-uart-apdma.c
> new file mode 100644
> index 000..9ed7a49
> --- /dev/null
> +++ b/drivers/dma/mediatek/mtk-uart-apdma.c
> @@ -0,0 +1,660 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * MediaTek Uart APDMA driver.
> + *
> + * Copyright (c) 2018 MediaTek Inc.
> + * Author: Long Cheng
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "../virt-dma.h"
> +
> +/* The default number of virtual channel */
> +#define MTK_UART_APDMA_NR_VCHANS 8
> +
> +#define VFF_EN_B BIT(0)
> +#define VFF_STOP_B BIT(0)
> +#define VFF_FLUSH_BBIT(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_BBIT(0) /* tx left size >= vff thre */
> +#define VFF_WARM_RST_B BIT(0)
> +#define VFF_RX_INT_CLR_B (BIT(0) | BIT(1))
> +#define VFF_TX_INT_CLR_B 0
> +#define VFF_STOP_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 VFF_RING_SIZE 0xU
> +/* invert this bit when wrap ring head again */
> +#define VFF_RING_WRAP 0x1U
> +
> +#define VFF_INT_FLAG 0x00
> +#define VFF_INT_EN 0x04
> +#define VFF_EN 0x08
> +#define VFF_RST0x0c
> +#define VFF_STOP 0x10
> +#define VFF_FLUSH 0x14
> +#define VFF_ADDR 0x1c
> +#define VFF_LEN0x24
> +#define VFF_THRE 0x28
> +#define VFF_WPT0x2c
> +#define VFF_RPT0x30
> +/* 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_uart_apdmadev {
> + struct dma_device ddev;
> + struct clk *clk;
> + bool support_33bits;
> + unsigned int dma_requests;
> + unsigned int *dma_irq;
> +};
> +
> +struct mtk_uart_apdma_desc {
> + struct virt_dma_desc vd;
> +
> + unsigned int avail_len;
> +};
> +
> +struct mtk_chan {
> + struct virt_dma_chan vc;
> + struct dma_slave_config cfg;
> + void __iomem *base;
> + struct mtk_uart_apdma_desc *desc;
> +
> + enum dma_transfer_direction dir;
> +
> + bool requested;
> +
> + unsigned int rx_status;
> +};
> +
> +static inline struct mtk_uart_apdmadev *
> +to_mtk_uart_apdma_dev(struct dma_device *d)
> +{
> + return container_of(d, struct
Re: [PATCH] pinctrl: add drive for I2C related pins on MT8183
On Sat, Mar 2, 2019 at 5:53 PM Zhiyong Tao wrote:
>
> This patch provides the advanced drive for I2C used pins on MT8183.
> The detail strength specification description of the I2C pin is as follows.
> When E1=0/E0=0, the strength is 0.125mA.
> When E1=0/E0=1, the strength is 0.25mA.
> When E1=1/E0=0, the strength is 0.5mA.
> When E1=1/E0=1, the strength is 1mA.
Three things are needed to be added
The first is we need to add more words in the git message about what
relationship between the specific driving setup and existing generic
driving setup.
The second is stating why we need to add extra vendor driving property
in the patch is, instead of using the generic driving property.
The third is we need to add the dt-binding document prior to the change.
>
> Signed-off-by: Zhiyong Tao
> ---
> drivers/pinctrl/mediatek/pinctrl-mt8183.c| 50
>
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 45 +
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h | 13 ++
> drivers/pinctrl/mediatek/pinctrl-paris.c | 20 ++
> 4 files changed, 128 insertions(+)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> b/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> index 6262fd3678ea..f034574fc593 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> @@ -472,6 +472,51 @@ static const struct mtk_pin_field_calc
> mt8183_pin_r1_range[] = {
> PIN_FIELD_BASE(133, 133, 8, 0x0D0, 0x10, 13, 1),
> };
>
> +static const struct mtk_pin_field_calc mt8183_pin_e1e0en_range[] = {
> + PIN_FIELD_BASE(48, 48, 3, 0x0F0, 0x10, 20, 1),
> + PIN_FIELD_BASE(49, 49, 3, 0x0F0, 0x10, 15, 1),
> + PIN_FIELD_BASE(50, 50, 4, 0x0F0, 0x10, 12, 1),
> + PIN_FIELD_BASE(51, 51, 4, 0x0F0, 0x10, 7, 1),
> + PIN_FIELD_BASE(81, 81, 5, 0x0F0, 0x10, 12, 1),
> + PIN_FIELD_BASE(82, 82, 5, 0x0F0, 0x10, 9, 1),
> + PIN_FIELD_BASE(83, 83, 5, 0x0F0, 0x10, 19, 1),
> + PIN_FIELD_BASE(84, 84, 5, 0x0F0, 0x10, 22, 1),
> + PIN_FIELD_BASE(103, 103, 6, 0x0F0, 0x10, 24, 1),
> + PIN_FIELD_BASE(104, 104, 6, 0x0F0, 0x10, 14, 1),
> + PIN_FIELD_BASE(105, 105, 6, 0x0F0, 0x10, 27, 1),
> + PIN_FIELD_BASE(106, 106, 6, 0x0F0, 0x10, 17, 1),
> +};
> +
> +static const struct mtk_pin_field_calc mt8183_pin_e0_range[] = {
> + PIN_FIELD_BASE(48, 48, 3, 0x0F0, 0x10, 21, 1),
> + PIN_FIELD_BASE(49, 49, 3, 0x0F0, 0x10, 16, 1),
> + PIN_FIELD_BASE(50, 50, 4, 0x0F0, 0x10, 13, 1),
> + PIN_FIELD_BASE(51, 51, 4, 0x0F0, 0x10, 8, 1),
> + PIN_FIELD_BASE(81, 81, 5, 0x0F0, 0x10, 13, 1),
> + PIN_FIELD_BASE(82, 82, 5, 0x0F0, 0x10, 10, 1),
> + PIN_FIELD_BASE(83, 83, 5, 0x0F0, 0x10, 20, 1),
> + PIN_FIELD_BASE(84, 84, 5, 0x0F0, 0x10, 23, 1),
> + PIN_FIELD_BASE(103, 103, 6, 0x0F0, 0x10, 25, 1),
> + PIN_FIELD_BASE(104, 104, 6, 0x0F0, 0x10, 15, 1),
> + PIN_FIELD_BASE(105, 105, 6, 0x0F0, 0x10, 28, 1),
> + PIN_FIELD_BASE(106, 106, 6, 0x0F0, 0x10, 18, 1),
> +};
> +
> +static const struct mtk_pin_field_calc mt8183_pin_e1_range[] = {
> + PIN_FIELD_BASE(48, 48, 3, 0x0F0, 0x10, 22, 1),
> + PIN_FIELD_BASE(49, 49, 3, 0x0F0, 0x10, 17, 1),
> + PIN_FIELD_BASE(50, 50, 4, 0x0F0, 0x10, 14, 1),
> + PIN_FIELD_BASE(51, 51, 4, 0x0F0, 0x10, 9, 1),
> + PIN_FIELD_BASE(81, 81, 5, 0x0F0, 0x10, 14, 1),
> + PIN_FIELD_BASE(82, 82, 5, 0x0F0, 0x10, 11, 1),
> + PIN_FIELD_BASE(83, 83, 5, 0x0F0, 0x10, 21, 1),
> + PIN_FIELD_BASE(84, 84, 5, 0x0F0, 0x10, 24, 1),
> + PIN_FIELD_BASE(103, 103, 6, 0x0F0, 0x10, 26, 1),
> + PIN_FIELD_BASE(104, 104, 6, 0x0F0, 0x10, 16, 1),
> + PIN_FIELD_BASE(105, 105, 6, 0x0F0, 0x10, 29, 1),
> + PIN_FIELD_BASE(106, 106, 6, 0x0F0, 0x10, 19, 1),
> +};
> +
> static const struct mtk_pin_reg_calc mt8183_reg_cals[PINCTRL_PIN_REG_MAX] = {
> [PINCTRL_PIN_REG_MODE] = MTK_RANGE(mt8183_pin_mode_range),
> [PINCTRL_PIN_REG_DIR] = MTK_RANGE(mt8183_pin_dir_range),
> @@ -485,6 +530,9 @@ static const struct mtk_pin_reg_calc
> mt8183_reg_cals[PINCTRL_PIN_REG_MAX] = {
> [PINCTRL_PIN_REG_PUPD] = MTK_RANGE(mt8183_pin_pupd_range),
> [PINCTRL_PIN_REG_R0] = MTK_RANGE(mt8183_pin_r0_range),
> [PINCTRL_PIN_REG_R1] = MTK_RANGE(mt8183_pin_r1_range),
> + [PINCTRL_PIN_REG_DRV_EN_DIS] = MTK_RANGE(mt8183_pin_e1e0en_range),
> + [PINCTRL_PIN_REG_DRV_E0] = MTK_RANGE(mt8183_pin_e0_range),
> + [PINCTRL_PIN_REG_DRV_E1] = MTK_RANGE(mt8183_pin_e1_range),
> };
>
> static const char * const mt8183_pinctrl_register_base_names[] = {
> @@ -517,6 +565,8 @@ static const struct mtk_pin_soc mt8183_data = {
> .drive_get = mtk_pinconf_drive_get_rev1,
> .adv_pull_get = mtk_pinconf_adv_pull_get,
> .adv_pull_set = mtk_pinconf_adv_pull_set,
> + .adv_drive_get = mtk_pinconf_adv_drive_get,
> + .adv_drive_set =
Re: [PATCH net-next] drivers: net: Remove unnecessary semicolon
On Fri, 2019-03-01 at 16:09 +0800, Yue Haibing wrote:
> From: YueHaibing
>
> drivers/net/dsa/mt7530.c:649:3-4: Unneeded semicolon
> drivers/net/ethernet/cisco/enic/enic_clsf.c:35:2-3: Unneeded semicolon
> drivers/net/ethernet/faraday/ftgmac100.c:1640:2-3: Unneeded semicolon
> drivers/net/ethernet/mediatek/mtk_eth_soc.c:229:2-3: Unneeded semicolon
> drivers/net/usb/sr9700.c:437:2-3: Unneeded semicolon
>
> Remove unneeded semicolon.
>
> Generated by: scripts/coccinelle/misc/semicolon.cocci
>
Acked-by: Sean Wang for mt7530 and mtk_eth_soc
thanks!
> Signed-off-by: YueHaibing
> ---
> drivers/net/dsa/mt7530.c| 2 +-
> drivers/net/ethernet/cisco/enic/enic_clsf.c | 3 ++-
> drivers/net/ethernet/faraday/ftgmac100.c| 2 +-
> drivers/net/ethernet/mediatek/mtk_eth_soc.c | 2 +-
> drivers/net/usb/sr9700.c| 2 +-
> 5 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
> index 0390c5e..7357b4f 100644
> --- a/drivers/net/dsa/mt7530.c
> +++ b/drivers/net/dsa/mt7530.c
> @@ -646,7 +646,7 @@ static void mt7530_adjust_link(struct dsa_switch *ds, int
> port,
> case SPEED_100:
> mcr |= PMCR_FORCE_SPEED_100;
> break;
> - };
> + }
>
> if (phydev->link)
> mcr |= PMCR_FORCE_LNK;
> diff --git a/drivers/net/ethernet/cisco/enic/enic_clsf.c
> b/drivers/net/ethernet/cisco/enic/enic_clsf.c
> index 99038df..9900993 100644
> --- a/drivers/net/ethernet/cisco/enic/enic_clsf.c
> +++ b/drivers/net/ethernet/cisco/enic/enic_clsf.c
> @@ -32,7 +32,8 @@ int enic_addfltr_5t(struct enic *enic, struct flow_keys
> *keys, u16 rq)
> break;
> default:
> return -EPROTONOSUPPORT;
> - };
> + }
> +
> data.type = FILTER_IPV4_5TUPLE;
> data.u.ipv4.src_addr = ntohl(keys->addrs.v4addrs.src);
> data.u.ipv4.dst_addr = ntohl(keys->addrs.v4addrs.dst);
> diff --git a/drivers/net/ethernet/faraday/ftgmac100.c
> b/drivers/net/ethernet/faraday/ftgmac100.c
> index 3e5e971..b17b79e 100644
> --- a/drivers/net/ethernet/faraday/ftgmac100.c
> +++ b/drivers/net/ethernet/faraday/ftgmac100.c
> @@ -1637,7 +1637,7 @@ static int ftgmac100_setup_mdio(struct net_device
> *netdev)
> reg = ioread32(priv->base + FTGMAC100_OFFSET_REVR);
> reg &= ~FTGMAC100_REVR_NEW_MDIO_INTERFACE;
> iowrite32(reg, priv->base + FTGMAC100_OFFSET_REVR);
> - };
> + }
>
> /* Get PHY mode from device-tree */
> if (np) {
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> index 94d4663..549d364 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> @@ -226,7 +226,7 @@ static void mtk_phy_link_adjust(struct net_device *dev)
> case SPEED_100:
> mcr |= MAC_MCR_SPEED_100;
> break;
> - };
> + }
>
> if (MTK_HAS_CAPS(mac->hw->soc->caps, MTK_GMAC1_TRGMII) &&
> !mac->id && !mac->trgmii)
> diff --git a/drivers/net/usb/sr9700.c b/drivers/net/usb/sr9700.c
> index 6ac232e..e04c8054 100644
> --- a/drivers/net/usb/sr9700.c
> +++ b/drivers/net/usb/sr9700.c
> @@ -434,7 +434,7 @@ static int sr9700_rx_fixup(struct usbnet *dev, struct
> sk_buff *skb)
> usbnet_skb_return(dev, sr_skb);
>
> skb_pull(skb, len + SR_RX_OVERHEAD);
> - };
> + }
>
> return 0;
> }
Re: [PATCH 0/6]Bluetooth: mediatek: add support for MediaTek MT7663U and MT7668U UART devices
Hi Marcel, I will follow it up. Thank for your help! Sean On Mon, 2019-02-18 at 14:10 +0100, Marcel Holtmann wrote: > Hi Sean, > > > This adds the support of enabling MT7668U and MT7663U UART based Bluetooth > > function running on the top of btmtkuart driver. > > > > We are through several patches to reach the goal and also wish applied > > the same flow in MediaTek btusb [1] for the transport independence. > > Once [1] and the series is being merged and then in next step I will > > consider to add a btmtk.c to hold these independent operations among > > various transport reused by MediaTek UART, USB and SDIO-based Bluetooth. > > > > Firstly, > > in patch 1/6 to update the dt-binding document for the kind of devices. > > in patch 2/6, 3/6 to fix the common error issues in the current code. > > in Patch 4/6, 5/6 to add the general flow which MT7622 and even MT7663U and > > MT7668U USB devices also utilize. > > > > Finally, in patch 6/6 to add the specific setups for MediaTek UART-based > > Bluetooth and enable MT7663U and MT7668U device. > > > > [1] > > http://lists.infradead.org/pipermail/linux-mediatek/2019-January/017074.html > > > > > > Sean Wang (6): > > dt-bindings: net: bluetooth: add support for MediaTek MT7663U and > >MT7668U UART devices > > Bluetooth: mediatek: trivial typo fix > > Bluetooth: mediatek: fix up an error path to restore bdev->tx_state > > Bluetooth: mediatek: pass a pointer to mtk_hci_wmt_sync > > Bluetooth: mediatek: update the common setup between MT7622 and other > >devices > > Bluetooth: mediatek: add support for MediaTek MT7663U and MT7668U UART > >devices > > > > .../bindings/net/mediatek-bluetooth.txt | 64 +++ > > drivers/bluetooth/btmtkuart.c | 538 -- > > 2 files changed, 569 insertions(+), 33 deletions(-) > > please re-send 1/6 and 6/6 when the DT changes are ACKed by Rob. > > Regards > > Marcel >
Re: [PATCH] pinctrl: mediatek: fix dependencies for PINCTRL_MT76XX
On Mon, Jan 28, 2019 at 2:35 PM Dmitry Voytik wrote: > > How to reproduce the problem: > $ make tinyconfig > $ make menuconfig > then enable: > CONFIG_COMPILE_TEST=y > CONFIG_PINCTRL=y > and any of these: > CONFIG_PINCTRL_MT7622=y > CONFIG_PINCTRL_MT7629=y > CONFIG_PINCTRL_MT7623=y > > This combination causes build failure. > > Fix the problem by making PINCTRL_MT76XX to depend on CONFIG_OF=y. > > Signed-off-by: Dmitry Voytik > --- > drivers/pinctrl/mediatek/Kconfig | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/pinctrl/mediatek/Kconfig > b/drivers/pinctrl/mediatek/Kconfig > index 1817786ab6aa..a005cbccb4f7 100644 > --- a/drivers/pinctrl/mediatek/Kconfig > +++ b/drivers/pinctrl/mediatek/Kconfig > @@ -45,12 +45,14 @@ config PINCTRL_MT2701 > config PINCTRL_MT7623 > bool "Mediatek MT7623 pin control with generic binding" > depends on MACH_MT7623 || COMPILE_TEST > + depends on OF > default MACH_MT7623 > select PINCTRL_MTK_MOORE > > config PINCTRL_MT7629 > bool "Mediatek MT7629 pin control" > depends on MACH_MT7629 || COMPILE_TEST > + depends on OF > default MACH_MT7629 > select PINCTRL_MTK_MOORE > > @@ -92,6 +94,7 @@ config PINCTRL_MT6797 > > config PINCTRL_MT7622 > bool "MediaTek MT7622 pin control" > + depends on OF > depends on ARM64 || COMPILE_TEST > default ARM64 && ARCH_MEDIATEK > select PINCTRL_MTK_MOORE > -- > 2.20.1 > It seems the commit 2d2d478576d71000b29c52668c5712c825ee9af8 already fixed the problem or is there something I'm missing?
Re: [PATCH 2/2] dmaengine: mediatek-cqdma: remove redundant queue structure
On Thu, Jan 24, 2019 at 2:46 AM wrote:
>
> From: Shun-Chih Yu
>
> This patch introduces active_vdec to indicate the virtual descriptor
> under processing by the CQDMA dmaengine, and simplify the control logic
> by removing redundant queue structure, tasklets, and completion
> management.
>
> Also, wrong residue assignment in mtk_cqdma_tx_status and typos are
> fixed.
overall changes are good and let code become clear, but it's better to
do one thing at a patch instead of mixing all stuff together.
>
> Signed-off-by: Shun-Chih Yu
> ---
> drivers/dma/mediatek/mtk-cqdma.c | 399
> ++
> 1 file changed, 98 insertions(+), 301 deletions(-)
>
> diff --git a/drivers/dma/mediatek/mtk-cqdma.c
> b/drivers/dma/mediatek/mtk-cqdma.c
> index 131f397..387781b 100644
> --- a/drivers/dma/mediatek/mtk-cqdma.c
> +++ b/drivers/dma/mediatek/mtk-cqdma.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -47,7 +48,6 @@
> #define MTK_CQDMA_SRC 0x1c
> #define MTK_CQDMA_DST 0x20
> #define MTK_CQDMA_LEN1 0x24
> -#define MTK_CQDMA_LEN2 0x28
> #define MTK_CQDMA_SRC2 0x60
> #define MTK_CQDMA_DST2 0x64
>
> @@ -69,45 +69,32 @@
> * descriptor (CVD)
> * @vd:An instance for struct virt_dma_desc
> * @len: The total data size device wants to move
> - * @residue: The remaining data size device will move
> * @dest: The destination address device wants to move to
> * @src: The source address device wants to move from
> * @ch:The pointer to the corresponding dma channel
> - * @node: The lise_head struct to build link-list for VDs
> - * @parent:The pointer to the parent CVD
> */
> struct mtk_cqdma_vdesc {
> struct virt_dma_desc vd;
> size_t len;
> - size_t residue;
> dma_addr_t dest;
> dma_addr_t src;
> struct dma_chan *ch;
> -
> - struct list_head node;
> - struct mtk_cqdma_vdesc *parent;
> };
>
> /**
> * struct mtk_cqdma_pchan - The struct holding info describing physical
> * channel (PC)
> - * @queue: Queue for the PDs issued to this PC
> + * @active_vdesc: The pointer to the CVD which is under processing
> * @base: The mapped register I/O base of this PC
> * @irq: The IRQ that this PC are using
> * @refcnt:Track how many VCs are using this PC
> - * @tasklet: Tasklet for this PC
> * @lock: Lock protect agaisting multiple VCs access PC
> */
> struct mtk_cqdma_pchan {
> - struct list_head queue;
> + struct mtk_cqdma_vdesc *active_vdesc;
> void __iomem *base;
> u32 irq;
> -
> refcount_t refcnt;
> -
> - struct tasklet_struct tasklet;
> -
> - /* lock to protect PC */
> spinlock_t lock;
> };
>
> @@ -116,14 +103,10 @@ struct mtk_cqdma_pchan {
> * channel (VC)
> * @vc:An instance for struct virt_dma_chan
> * @pc:The pointer to the underlying PC
> - * @issue_completion: The wait for all issued descriptors completited
> - * @issue_synchronize:Bool indicating channel synchronization starts
> */
> struct mtk_cqdma_vchan {
> struct virt_dma_chan vc;
> struct mtk_cqdma_pchan *pc;
> - struct completion issue_completion;
> - bool issue_synchronize;
> };
>
> /**
> @@ -168,7 +151,7 @@ static struct device *cqdma2dev(struct mtk_cqdma_device
> *cqdma)
>
> static u32 mtk_dma_read(struct mtk_cqdma_pchan *pc, u32 reg)
> {
> - return readl(pc->base + reg);
> + return readl_relaxed(pc->base + reg);
that can be moved to separate patch and explains why
> }
>
> static void mtk_dma_write(struct mtk_cqdma_pchan *pc, u32 reg, u32 val)
> @@ -202,22 +185,22 @@ static void mtk_cqdma_vdesc_free(struct virt_dma_desc
> *vd)
> kfree(to_cqdma_vdesc(vd));
> }
>
> -static int mtk_cqdma_poll_engine_done(struct mtk_cqdma_pchan *pc, bool
> atomic)
> +static int mtk_cqdma_poll_engine_done(struct mtk_cqdma_pchan *pc)
> {
> u32 status = 0;
>
> - if (!atomic)
> + if (!in_task())
if (in_task())
> return readl_poll_timeout(pc->base + MTK_CQDMA_EN,
> status,
> !(status & MTK_CQDMA_EN_BIT),
> MTK_CQDMA_USEC_POLL,
> MTK_CQDMA_TIMEOUT_POLL);
> -
> - return readl_poll_timeout_atomic(pc->base + MTK_CQDMA_EN,
> -status,
> -!(status &
Re: [PATCH 1/2] dt-bindings: dmaengine: Add MediaTek Command-Queue DMA controller bindings
You dropped the version tag that doesn't reflect that is a newer one
and that would be easily ignored by other people
On Thu, Jan 24, 2019 at 2:46 AM wrote:
>
> From: Shun-Chih Yu
>
> Document the devicetree bindings for MediaTek Command-Queue DMA controller
> which could be found on MT6765 SoC or other similar Mediatek SoCs.
>
> Signed-off-by: Shun-Chih Yu
> Reviewed-by: Rob Herring
otherwise, Acked-by: Sean Wang
> ---
> .../devicetree/bindings/dma/mtk-cqdma.txt | 31
>
> 1 file changed, 31 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/dma/mtk-cqdma.txt
>
> diff --git a/Documentation/devicetree/bindings/dma/mtk-cqdma.txt
> b/Documentation/devicetree/bindings/dma/mtk-cqdma.txt
> new file mode 100644
> index 000..fb12927
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/mtk-cqdma.txt
> @@ -0,0 +1,31 @@
> +MediaTek Command-Queue DMA Controller
> +==
> +
> +Required properties:
> +
> +- compatible: Must be "mediatek,mt6765-cqdma" for MT6765.
> +- reg: Should contain the base address and length for each channel.
> +- interrupts: Should contain references to the interrupts for each channel.
> +- clocks: Should be the clock specifiers corresponding to the entry in
> + clock-names property.
> +- clock-names: Should contain "cqdma" entries.
> +- dma-channels: The number of DMA channels supported by the controller.
> +- dma-requests: The number of DMA request supported by the controller.
> +- #dma-cells: The length of the DMA specifier, must be <1>. This one cell
> + in dmas property of a client device represents the channel
> + number.
> +Example:
> +
> +cqdma: dma-controller@10212000 {
> + compatible = "mediatek,mt6765-cqdma";
> + reg = <0 0x10212000 0 0x1000>;
> + interrupts = ,
> + ;
> + clocks = < CLK_IFR_CQ_DMA>;
> + clock-names = "cqdma";
> + dma-channels = <2>;
> + dma-requests = <32>;
> + #dma-cells = <1>;
> + };
> +
> +DMA clients must use the format described in dma/dma.txt file.
> --
> 1.7.9.5
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH v5] add support for Mediatek Command-Queue DMA controller on MT6765 SoC
Hi Shun-Chih, the driver seems already be applied since v5.0-rc1 I suggest these improvements you made in the recent version can be split into several patches and then be applied on the top of the base driver. On Wed, Jan 23, 2019 at 11:15 PM wrote: > > This patchset introduces support for MediaTek Command-Queue DMA controller. > > MediaTek Command-Queue DMA controller (CQDMA) on MT6765 SoC is dedicated to > memory-to-memory transfer through queue-based descriptor management. > > There are only 3 physical channels inside CQDMA, while the driver is extended > to support 32 virtual channels for multiple dma users to issue dma requests > onto the CQDMA simultaneously. > > dmatest result: > dmatest: dma0chan0-copy2: summary 5000 tests, 0 failures 3500 iops 28037 KB/s > (0) > dmatest: dma0chan0-copy4: summary 5000 tests, 0 failures 3494 iops 27612 KB/s > (0) > dmatest: dma0chan0-copy1: summary 5000 tests, 0 failures 3491 iops 27749 KB/s > (0) > dmatest: dma0chan0-copy7: summary 5000 tests, 0 failures 3673 iops 29092 KB/s > (0) > dmatest: dma0chan0-copy6: summary 5000 tests, 0 failures 3763 iops 30237 KB/s > (0) > dmatest: dma0chan0-copy0: summary 5000 tests, 0 failures 3730 iops 30131 KB/s > (0) > dmatest: dma0chan0-copy3: summary 5000 tests, 0 failures 3717 iops 29569 KB/s > (0) > dmatest: dma0chan0-copy5: summary 5000 tests, 0 failures 3699 iops 29302 KB/s > (0) > > Changes since v4: > - remove redundant queue structure in mtk_cqdma_pchan > - remove redundant completion management > - fix wrong residue assignment in mtk_cqdma_tx_status > - fix typos > > Changes since v3: > - simplify the ISR and management on descriptors by removing tasklet and > ASYNC_TX_ENABLE_CHANNEL_SWITCH > - remove useless field in mtk_cqdma_vdesc structure > - change dev_info to dev_dbg > - fix typos > > Changes since v2: > - fix build warning for kernel with DMA address in 32-bit > > Changes since v1: > - remove unused macros, typos > - leverage ASYNC_TX_ENABLE_CHANNEL_SWITCH to maintain DMA descriptor list > > Shun-Chih Yu (2): > dt-bindings: dmaengine: Add MediaTek Command-Queue DMA controller > bindings > dmaengine: mediatek: Add MediaTek Command-Queue DMA controller for > MT6765 SoC > > .../devicetree/bindings/dma/mtk-cqdma.txt | 31 + > drivers/dma/mediatek/Kconfig | 12 + > drivers/dma/mediatek/Makefile |1 + > drivers/dma/mediatek/mtk-cqdma.c | 748 > > 4 files changed, 792 insertions(+) > create mode 100644 Documentation/devicetree/bindings/dma/mtk-cqdma.txt > create mode 100644 drivers/dma/mediatek/mtk-cqdma.c > > > ___ > Linux-mediatek mailing list > linux-media...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH v2 2/4] dt-bindings: gnss: add mediatek binding
On Tue, 2019-01-22 at 09:47 +0100, Loys Ollivier wrote: > On Mon 21 Jan 2019 at 18:44, Sean Wang wrote: > > > On Mon, Jan 21, 2019 at 9:29 AM Loys Ollivier > > wrote: > >> > >> > >> On Mon 21 Jan 2019 at 17:10, Rob Herring wrote: > >> > >> > On Thu, 17 Jan 2019 17:54:32 +0100, Loys Ollivier wrote: > >> >> Add binding for Mediatek-based GNSS receivers. > >> >> > >> >> Signed-off-by: Loys Ollivier > >> >> --- > >> >> > >> >> v2: > >> >> Renamed bindings from Globaltop/gtop to Mediatek/mtk. > >> >> Moved current-speed as an optional propertie. > >> >> Removed the status line in the example. > >> >> Added "mediatek,mt3339" compatible. > >> >> > >> >> .../devicetree/bindings/gnss/mediatek.txt | 39 > >> >> ++ > >> >> 1 file changed, 39 insertions(+) > >> >> create mode 100644 Documentation/devicetree/bindings/gnss/mediatek.txt > >> >> > >> > > >> > Reviewed-by: Rob Herring > >> > >> Thanks Rob, > >> If there are no objections by others, I'll stop sending these two patch > >> (1/4 and 2/4) and reference any new patch serie for 3 and 4 as depending > >> on those two. > >> > > > > Hi Loys, > > > > Thanks for adding the first GPS device driver. It's really nice to see > > more device drivers added to upstream support. > > > Hi Sean, > > Glad to know you're supporting this initiative. > > > Do you mind send the series again with Cc > > linux-media...@lists.infradead.org > > ? > > > The series already has linux-media...@lists.infradead.org in Cc. Does it > need a resend ? > It doesn't need a resend, it's my mistake. thanks for clarifying soon. > > Sean > > > >> -- > >> -L > >> > >> ___ > >> Linux-mediatek mailing list > >> linux-media...@lists.infradead.org > >> http://lists.infradead.org/mailman/listinfo/linux-mediatek > >
Re: [PATCH v2 2/4] dt-bindings: gnss: add mediatek binding
On Mon, Jan 21, 2019 at 9:29 AM Loys Ollivier wrote: > > > On Mon 21 Jan 2019 at 17:10, Rob Herring wrote: > > > On Thu, 17 Jan 2019 17:54:32 +0100, Loys Ollivier wrote: > >> Add binding for Mediatek-based GNSS receivers. > >> > >> Signed-off-by: Loys Ollivier > >> --- > >> > >> v2: > >> Renamed bindings from Globaltop/gtop to Mediatek/mtk. > >> Moved current-speed as an optional propertie. > >> Removed the status line in the example. > >> Added "mediatek,mt3339" compatible. > >> > >> .../devicetree/bindings/gnss/mediatek.txt | 39 > >> ++ > >> 1 file changed, 39 insertions(+) > >> create mode 100644 Documentation/devicetree/bindings/gnss/mediatek.txt > >> > > > > Reviewed-by: Rob Herring > > Thanks Rob, > If there are no objections by others, I'll stop sending these two patch > (1/4 and 2/4) and reference any new patch serie for 3 and 4 as depending > on those two. > Hi Loys, Thanks for adding the first GPS device driver. It's really nice to see more device drivers added to upstream support. Do you mind send the series again with Cc linux-media...@lists.infradead.org ? Sean > -- > -L > > ___ > Linux-mediatek mailing list > linux-media...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH v2] net: ethernet: mediatek: fix warning in phy_start_aneg
On Wed, Jan 9, 2019 at 10:31 AM Heiner Kallweit wrote: > > On 09.01.2019 08:20, Frank Wunderlich wrote: > > From: Heiner Kallweit > > > > linux 5.0-rc1 shows following warning on bpi-r2/mt7623 bootup: > > > > [ 5.170597] WARNING: CPU: 3 PID: 1 at drivers/net/phy/phy.c:548 > > phy_start_aneg+0x110/0x144 > > [ 5.178826] called from state READY > > > > [ 5.264111] [] (phy_start_aneg) from [] > > (mtk_init+0x414/0x47c) > > [ 5.271630] r7:df5f5eec r6:c0f08c48 r5: r4:dea67800 > > [ 5.277256] [] (mtk_init) from [] > > (register_netdevice+0x98/0x51c) > > [ 5.285035] r8: r7: r6:c0f97080 r5:c0f08c48 r4:dea67800 > > [ 5.291693] [] (register_netdevice) from [] > > (register_netdev+0x2c/0x44) > > [ 5.299989] r8: r7:dea2e608 r6:deacea00 r5:dea2e604 r4:dea67800 > > [ 5.306646] [] (register_netdev) from [] > > (mtk_probe+0x668/0x7ac) > > [ 5.314336] r5:dea2e604 r4:dea2e040 > > [ 5.317890] [] (mtk_probe) from [] > > (platform_drv_probe+0x58/0xa8) > > [ 5.325670] r10:c0f86bac r9: r8:c0fbe578 r7: r6:c0f86bac > > r5: > > [ 5.333445] r4:deacea10 > > [ 5.335963] [] (platform_drv_probe) from [] > > (really_probe+0x2d8/0x424) > > > > maybe other boards using this generic driver are affected > > > > v2: > > optimization: > > > > - phy_set_max_speed() is only needed if you want to reduce the > > max speed, typically if the PHY supports 1Gbps but the MAC > > supports 100Mbps only. > > > > - The pause parameters are autonegotiated. Except you have a specific > > need you normally don't need to manually fiddle with this. > > > > - phy_start_aneg() is called implicitly by the phylib state machine, > > you shouldn't call it manually except you have a good excuse. > > > > - netif_carrier_on/netif_carrier_off in mtk_phy_link_adjust() isn't > > needed. It's done by phy_link_change() in phylib. > > > > Signed-off-by: Frank Wunderlich > > --- > > drivers/net/ethernet/mediatek/mtk_eth_soc.c | 16 > > 1 file changed, 16 deletions(-) > > > Reviewed-by: Heiner Kallweit Thanks for your help to have the driver more fit in phylib. Acked-by: Sean Wang
Re: [PATCH] pinctrl: mediatek: fix build errors for moore core when CONFIG_OF is not enabled
^
> In file included from ../include/linux/kernel.h:15:0,
> from ../include/linux/list.h:9,
> from ../include/linux/kobject.h:19,
> from ../include/linux/device.h:16,
> from ../include/linux/gpio/driver.h:5,
> from ../drivers/pinctrl/mediatek/pinctrl-moore.c:11:
> ../drivers/pinctrl/mediatek/pinctrl-moore.c: In function
> 'mtk_moore_pinctrl_probe':
> ../include/linux/build_bug.h:16:45: error: bit-field '' width not
> an integer constant
> #define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:(-!!(e)); }))
> ^
> ../include/linux/compiler.h:349:28: note: in expansion of macro
> 'BUILD_BUG_ON_ZERO'
> #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
> ^
> ../include/linux/kernel.h:72:59: note: in expansion of macro '__must_be_array'
> #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
> __must_be_array(arr))
>^
> ../drivers/pinctrl/mediatek/pinctrl-moore.c:643:31: note: in expansion of
> macro 'ARRAY_SIZE'
> mtk_desc.num_custom_params = ARRAY_SIZE(mtk_custom_bindings);
>^
> ../drivers/pinctrl/mediatek/pinctrl-moore.c: At top level:
> ../drivers/pinctrl/mediatek/pinctrl-moore.c:22:44: warning:
> 'mtk_custom_bindings' defined but not used [-Wunused-variable]
> static const struct pinconf_generic_params mtk_custom_bindings[] = {
> ^
> cc1: some warnings being treated as errors
> ../scripts/Makefile.build:276: recipe for target
> 'drivers/pinctrl/mediatek/pinctrl-moore.o' failed
> make[4]: *** [drivers/pinctrl/mediatek/pinctrl-moore.o] Error 1
>
> Fixes: b5af33df50e9 ("pinctrl: mediatek: improve Kconfig dependencies")
> Cc: sta...@vger.kernel.org
> Reported-by: Randy Dunlap
> Signed-off-by: Ryder Lee
The content looks good to me
Acked-by: Sean Wang
Hi Linus,
If you don't like such a long message, you can feel free trim it to a
short one when you merge.
Sean
> ---
> drivers/pinctrl/mediatek/Kconfig | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/pinctrl/mediatek/Kconfig
> b/drivers/pinctrl/mediatek/Kconfig
> index 1817786..a005cbc 100644
> --- a/drivers/pinctrl/mediatek/Kconfig
> +++ b/drivers/pinctrl/mediatek/Kconfig
> @@ -45,12 +45,14 @@ config PINCTRL_MT2701
> config PINCTRL_MT7623
> bool "Mediatek MT7623 pin control with generic binding"
> depends on MACH_MT7623 || COMPILE_TEST
> + depends on OF
> default MACH_MT7623
> select PINCTRL_MTK_MOORE
>
> config PINCTRL_MT7629
> bool "Mediatek MT7629 pin control"
> depends on MACH_MT7629 || COMPILE_TEST
> + depends on OF
> default MACH_MT7629
> select PINCTRL_MTK_MOORE
>
> @@ -92,6 +94,7 @@ config PINCTRL_MT6797
>
> config PINCTRL_MT7622
> bool "MediaTek MT7622 pin control"
> + depends on OF
> depends on ARM64 || COMPILE_TEST
> default ARM64 && ARCH_MEDIATEK
> select PINCTRL_MTK_MOORE
> --
> 1.9.1
>
Re: Re: [PATCH] net: ethernet: mediatek: fix warning in phy_start_aneg
On Tue, Jan 8, 2019 at 11:07 AM Frank Wunderlich wrote: > > > > In mtk_phy_connect() I would say this complete block can be removed. > > All this is handled internally by phylib. > > > > dev->phydev->autoneg = AUTONEG_ENABLE; > > dev->phydev->speed = 0; > > dev->phydev->duplex = 0; > > > > phy_set_max_speed(dev->phydev, SPEED_1000); > > phy_support_asym_pause(dev->phydev); > > linkmode_copy(dev->phydev->advertising, dev->phydev->supported); > > linkmode_set_bit(ETHTOOL_LINK_MODE_Autoneg_BIT, > >dev->phydev->advertising); > > phy_start_aneg(dev->phydev); > > > > Could you please test this? > > seems to work well, no warning in dmesg > > traffic 940Mbit sending, 900 receive > The change to phy initialized valve determined by phylib looks good to me and simplify the mac driver a lot. You could have it in v2. > > And a further proposal: > > Instead of the open-coded dev_info() in mtk_phy_connect_node() > > you could use phy_attached_info(). > > have not tried this yet...because it's only an info-message and needs > different parameters...have to look how i can convert it I think it can be done in a separate patch > > > Calling phy_start() in the ndo_open callback is fine, you can leave > > it there. > > have it re-added > > pushed to my repo: https://github.com/frank-w/BPI-R2-4.14/commits/5.0-rc > > regards Frank
Re: [PATCH v5] pinctrl: mediatek: add EINT support to virtual GPIOs
On Wed, Jan 2, 2019 at 7:38 PM wrote: > > From: "chuanjia.liu" > > Virtual gpio only used inside SOC and not being exported to outside SOC. > Some modules use virtual gpio as eint and doesn't need SMT. > So this patch add EINT support to virtual GPIOs. > > Signed-off-by: chuanjia.liu Acked-by: Sean Wang BTW, if you were worried about a patch is lost, you could use RESEND in the tag is fine. > --- > change note: > v5: This patch is the same as v4,re-upload due to > mail permissions issues > --- > drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c > b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c > index 4a9e0d4c2bbc..b1c368455d30 100644 > --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c > +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c > @@ -290,7 +290,13 @@ static int mtk_xt_set_gpio_as_eint(void *data, unsigned > long eint_n) > return err; > > err = mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_SMT, MTK_ENABLE); > - if (err) > + /* SMT is supposed to be supported by every real GPIO and doesn't > +* support virtual GPIOs, so the extra condition err != -ENOTSUPP > +* is just for adding EINT support to these virtual GPIOs. It should > +* add an extra flag in the pin descriptor when more pins with > +* distinctive characteristic come out. > +*/ > + if (err && err != -ENOTSUPP) > return err; > > return 0; > -- > 2.19.1 >
Re: [PATCH] pinctrl: add drive for I2C related pins on MT8183
On Fri, Jan 4, 2019 at 12:48 AM Zhiyong Tao wrote:
>
> On Wed, 2018-12-12 at 04:51 +0800, Sean Wang wrote:
> > The subject should be refined to be close to the content
> >
> > On Tue, Dec 11, 2018 at 12:02 AM Zhiyong Tao
> > wrote:
> > >
> > > This patch provides the advanced drive for I2C used pins on MT8183.
> > >
> >
> > Additionally, you should state more how much strength in mA given on
> > each step E1, E0 move forward. This way would help to reuse the scheme
> > on the similar SoCs.
>
> ==>
> Hi sean,
> Thanks for your suggestion.
> when E1=0/E0=0, the strength is 0.125mA;
> when E1=0/E0=1, the strength is 0.25mA;
> when E1=1/E0=0, the strength is 0.5mA;
> when E1=1/E0=1, the strength is 1mA;
> we will add it in the commit message in the next version.
>
Does the extra fine-tuned strength always plus on regular drive
strength? or the device can be minus from regular drive strength.
Because the generic property drive-strength seems not able to accept a
floating point as the argument, so it should probably be fine to use
additional vendor property to indicate the extra fine-tuned strength.
I'd prefer to add only one vendor property
"mediatek,drive-strength-extra" in a human-readable way which only
accepts an integer in mA to reach your goal and where the "extra" in
the naming is that I am supposed the property can't work
independently, it has to work together with general driving strength
to determine the final driving strength.
For example:
mediatek,drive-strenth-extra=<125>;
mediatek,drive-strenth-extra=<250>;
mediatek,drive-strenth-extra=<500>;
mediatek,drive-strenth-extra=<1000>;
mediatek,drive-strenth-extra=<-250>; /* if a minus can supported */
About the driver implementation, the driver can round down or up to
the closest value the user expects to (that can be done easily with
macro DIV_ROUND_CLOSEST) and we have to state clearly what range can
be supported for the SoC and the relationship with generic property
drive-strength in both the dt-binding and the driver with proper
comments.
> Thanks.
> >
> > > Signed-off-by: Zhiyong Tao
> > > ---
> > > drivers/pinctrl/mediatek/pinctrl-mt8183.c| 50
> > >
> > > drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 45
> > > +
> > > drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h | 13 ++
> > > drivers/pinctrl/mediatek/pinctrl-paris.c | 20 ++
> > > 4 files changed, 128 insertions(+)
> > >
> > > diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> > > b/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> > > index 6262fd3678ea..5244e1b27b1d 100644
> > > --- a/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> > > +++ b/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> > > @@ -472,6 +472,51 @@ static const struct mtk_pin_field_calc
> > > mt8183_pin_r1_range[] = {
> > > PIN_FIELD_BASE(133, 133, 8, 0x0D0, 0x10, 13, 1),
> > > };
> > >
> > > +static const struct mtk_pin_field_calc mt8183_pin_drv_en_dis_range[] = {
> >
> > I'd prefer using the word mt8183_pin_e1e0en_range to keep people away from
> > be confused the relationship with the existing mt8183_pin_drv_range.
> >
> > > + PIN_FIELD_BASE(48, 48, 3, 0x0F0, 0x10, 20, 1),
> > > + PIN_FIELD_BASE(49, 49, 3, 0x0F0, 0x10, 15, 1),
> > > + PIN_FIELD_BASE(50, 50, 4, 0x0F0, 0x10, 12, 1),
> > > + PIN_FIELD_BASE(51, 51, 4, 0x0F0, 0x10, 7, 1),
> > > + PIN_FIELD_BASE(81, 81, 5, 0x0F0, 0x10, 12, 1),
> > > + PIN_FIELD_BASE(82, 82, 5, 0x0F0, 0x10, 9, 1),
> > > + PIN_FIELD_BASE(83, 83, 5, 0x0F0, 0x10, 19, 1),
> > > + PIN_FIELD_BASE(84, 84, 5, 0x0F0, 0x10, 22, 1),
> > > + PIN_FIELD_BASE(103, 103, 6, 0x0F0, 0x10, 24, 1),
> > > + PIN_FIELD_BASE(104, 104, 6, 0x0F0, 0x10, 14, 1),
> > > + PIN_FIELD_BASE(105, 105, 6, 0x0F0, 0x10, 27, 1),
> > > + PIN_FIELD_BASE(106, 106, 6, 0x0F0, 0x10, 17, 1),
> > > +};
> > > +
> > > +static const struct mtk_pin_field_calc mt8183_pin_drv_e0_range[] = {
> >
> > Ditto, I'd prefer using the word mt8183_pin_e0_range
> >
> > > + PIN_FIELD_BASE(48, 48, 3, 0x0F0, 0x10, 21, 1),
> > > + PIN_FIELD_BASE(49, 49, 3, 0x0F0, 0x10, 16, 1),
> > > + PIN_FIELD_BASE(50, 50, 4, 0x0F0, 0x10, 13, 1),
> > > + PIN_FIELD_BASE(51, 51, 4, 0x0F0, 0x10, 8, 1),
> > > + PIN_FIELD_BASE(81, 81, 5, 0x0F0, 0x10, 13, 1),
> > > + PIN_FIELD_BASE(82, 82, 5, 0x0F0,
Re: [PATCH v5 5/6] dt-bindings: pinctrl: mt8183: add binding document
On Fri, Jan 4, 2019 at 1:40 AM Zhiyong Tao wrote: > > On Fri, 2019-01-04 at 01:14 -0800, Sean Wang wrote: > > On Thu, Jan 3, 2019 at 11:09 PM Zhiyong Tao > > wrote: > > > > > > On Sat, 2018-12-29 at 06:04 +0800, Rob Herring wrote: > > > > On Fri, Dec 28, 2018 at 04:09:40PM +0800, Erin Lo wrote: > > > > > From: Zhiyong Tao > > > > > > > > > > The commit adds mt8183 compatible node in binding document. > > > > > > > > > > Signed-off-by: Zhiyong Tao > > > > > Signed-off-by: Erin Lo > > > > > --- > > > > > .../devicetree/bindings/pinctrl/pinctrl-mt8183.txt | 110 > > > > > + > > > > > 1 file changed, 110 insertions(+) > > > > > create mode 100644 > > > > > Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt > > > > > > > > > > diff --git > > > > > a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt > > > > > b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt > > > > > new file mode 100644 > > > > > index 000..7b5285e > > > > > --- /dev/null > > > > > +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt > > > > > @@ -0,0 +1,110 @@ > > > > > +* Mediatek MT8183 Pin Controller > > > > > + > > > > > +The Mediatek's Pin controller is used to control SoC pins. > > > > > + > > > > > +Required properties: > > > > > +- compatible: value should be one of the following. > > > > > + "mediatek,mt8183-pinctrl", compatible with mt8183 pinctrl. > > > > > +- gpio-controller : Marks the device node as a gpio controller. > > > > > +- #gpio-cells: number of cells in GPIO specifier. Since the generic > > > > > GPIO > > > > > + binding is used, the amount of cells must be specified as 2. See > > > > > the below > > > > > + mentioned gpio binding representation for description of > > > > > particular cells. > > > > > +- gpio-ranges : gpio valid number range. > > > > > + > > > > > + Eg: < 6 0> > > > > > + <[phandle of the gpio controller node] > > > > > + [line number within the gpio controller] > > > > > + [flags]> > > > > > + > > > > > + Values for gpio specifier: > > > > > + - Line number: is a value between 0 to 202. > > > > > + - Flags: bit field of flags, as defined in > > > > > . > > > > > +Only the following flags are supported: > > > > > +0 - GPIO_ACTIVE_HIGH > > > > > +1 - GPIO_ACTIVE_LOW > > > > > + > > > > > +Optional properties: > > > > > +- reg: physicall address base for gpio base registers. > > > > > > > > s/physicall/physical/ > > > > > > > > reg should never be optional. > > > > > > > > Need to say how many reg entries. > > > > > > ==> Thanks for your suggestion. We will change 'reg' to Required > > > properties and add the reg entries in next version. > > > > > > > > > +- reg-names: gpio base registers name. > > > > > > > > Need to say what are the names. However, I don't find the names in the > > > > example all that useful, so I'd just drop it. > > > > > > ==> we will add the reg-names in next version. > > > They are used in the sample code, such as: > > > > + reg-names = "iocfg0", "iocfg1", "iocfg2", > > > > > + "iocfg3", "iocfg4", "iocfg5", > > > > > + "iocfg6", "iocfg7", "iocfg8"; > > > > > > > > > > > > +- interrupt-controller: Marks the device node as an interrupt > > > > > controller > > > > > +- #interrupt-cells: Should be two. > > > > > +- interrupts : The interrupt outputs from the controller. > > > > > + > > > > > +Please refer to pinctrl-bindings.txt in this directory for details > > > > > of the > > > > > +common pinctrl bindings used by client devices. > > > > > + > > > > > +Subnode
Re: [PATCH v5 5/6] dt-bindings: pinctrl: mt8183: add binding document
On Thu, Jan 3, 2019 at 11:09 PM Zhiyong Tao wrote:
>
> On Sat, 2018-12-29 at 06:04 +0800, Rob Herring wrote:
> > On Fri, Dec 28, 2018 at 04:09:40PM +0800, Erin Lo wrote:
> > > From: Zhiyong Tao
> > >
> > > The commit adds mt8183 compatible node in binding document.
> > >
> > > Signed-off-by: Zhiyong Tao
> > > Signed-off-by: Erin Lo
> > > ---
> > > .../devicetree/bindings/pinctrl/pinctrl-mt8183.txt | 110
> > > +
> > > 1 file changed, 110 insertions(+)
> > > create mode 100644
> > > Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt
> > > b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt
> > > new file mode 100644
> > > index 000..7b5285e
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt
> > > @@ -0,0 +1,110 @@
> > > +* Mediatek MT8183 Pin Controller
> > > +
> > > +The Mediatek's Pin controller is used to control SoC pins.
> > > +
> > > +Required properties:
> > > +- compatible: value should be one of the following.
> > > + "mediatek,mt8183-pinctrl", compatible with mt8183 pinctrl.
> > > +- gpio-controller : Marks the device node as a gpio controller.
> > > +- #gpio-cells: number of cells in GPIO specifier. Since the generic GPIO
> > > + binding is used, the amount of cells must be specified as 2. See the
> > > below
> > > + mentioned gpio binding representation for description of particular
> > > cells.
> > > +- gpio-ranges : gpio valid number range.
> > > +
> > > + Eg: < 6 0>
> > > + <[phandle of the gpio controller node]
> > > + [line number within the gpio controller]
> > > + [flags]>
> > > +
> > > + Values for gpio specifier:
> > > + - Line number: is a value between 0 to 202.
> > > + - Flags: bit field of flags, as defined in .
> > > +Only the following flags are supported:
> > > +0 - GPIO_ACTIVE_HIGH
> > > +1 - GPIO_ACTIVE_LOW
> > > +
> > > +Optional properties:
> > > +- reg: physicall address base for gpio base registers.
> >
> > s/physicall/physical/
> >
> > reg should never be optional.
> >
> > Need to say how many reg entries.
>
> ==> Thanks for your suggestion. We will change 'reg' to Required
> properties and add the reg entries in next version.
> >
> > > +- reg-names: gpio base registers name.
> >
> > Need to say what are the names. However, I don't find the names in the
> > example all that useful, so I'd just drop it.
>
> ==> we will add the reg-names in next version.
> They are used in the sample code, such as:
> > + reg-names = "iocfg0", "iocfg1", "iocfg2",
> > > + "iocfg3", "iocfg4", "iocfg5",
> > > + "iocfg6", "iocfg7", "iocfg8";
>
> >
> > > +- interrupt-controller: Marks the device node as an interrupt controller
> > > +- #interrupt-cells: Should be two.
> > > +- interrupts : The interrupt outputs from the controller.
> > > +
> > > +Please refer to pinctrl-bindings.txt in this directory for details of the
> > > +common pinctrl bindings used by client devices.
> > > +
> > > +Subnode format
> > > +A pinctrl node should contain at least one subnodes representing the
> > > +pinctrl groups available on the machine. Each subnode will list the
> > > +pins it needs, and how they should be configured, with regard to muxer
> > > +configuration, pullups, drive strength, input enable/disable and input
> > > schmitt.
> > > +
> > > +node {
> > > + pinmux = ;
> > > + GENERIC_PINCONFIG;
> > > +};
> > > +
> > > +Required properties:
> > > +- pinmux: integer array, represents gpio pin number and mux setting.
> > > +Supported pin number and mux varies for different SoCs, and are
> > > defined
> > > +as macros in boot/dts/-pinfunc.h directly.
> > > +
> > > +Optional properties:
> > > +- GENERIC_PINCONFIG: is the generic pinconfig options to use,
> > > bias-disable,
> > > +bias-pull-down, bias-pull-up, input-enable, input-disable,
> > > output-low, output-high,
> > > +input-schmitt-enable, input-schmitt-disable and drive-strength are
> > > valid.
> > > +
> > > +Some special pins have extra pull up strength, there are R0 and R1
> > > pull-up
> > > +resistors available, but for user, it's only need to set R1R0 as 00,
> > > 01, 10 or 11.
> > > +So when config mediatek,pull-up-adv or mediatek,pull-down-adv,
> > > +it support arguments for those special pins.
> > > +
> > > +When config drive-strength, it can support some arguments, such as
> > > +MTK_DRIVE_4mA, MTK_DRIVE_6mA, etc. See dt-bindings/pinctrl/mt65xx.h.
> > > +
One point we can fix more is the drive-strength already is supported
as the generic one, not need to depend on a dedicated header file.
> > > +Examples:
> > > +
> > > +#include "mt8183-pinfunc.h"
> > > +
> > > +...
> > > +{
> > > + pio: pinctrl@10005000 {
> > > + compatible = "mediatek,mt8183-pinctrl";
> > > + reg = <0
Re: [PATCH 2/2] dmaengine: mediatek: Add MediaTek Command-Queue DMA controller for MT6765 SoC
go on other parts not finished review at the last time On Sat, Dec 29, 2018 at 3:03 AM Sean Wang wrote: > > The version looks like better than the earlier version, but there are > still a few nitpicks I post at the inline. > > On Thu, Dec 27, 2018 at 5:11 AM wrote: > > > > From: Shun-Chih Yu > > > > MediaTek Command-Queue DMA controller (CQDMA) on MT6765 SoC is dedicated > > to memory-to-memory transfer through queue based descriptor management. > > > > There are only 3 physical channels inside CQDMA, while the driver is > > extended to support 32 virtual channels for multiple dma users to issue > > dma requests onto the CQDMA simultaneously. > > > > Change-Id: I1e8d116c5ecbbc49190ffc925cb59a0d035d886b > > should be more careful drop the change-id every time > > > Signed-off-by: Shun-Chih Yu > > Reviewed-by: Vinod Koul > > > > --- > > drivers/dma/mediatek/Kconfig | 12 + > > drivers/dma/mediatek/Makefile|1 + > > drivers/dma/mediatek/mtk-cqdma.c | 867 > > ++ > > 3 files changed, 880 insertions(+) > > create mode 100644 drivers/dma/mediatek/mtk-cqdma.c > > > > diff --git a/drivers/dma/mediatek/Kconfig b/drivers/dma/mediatek/Kconfig > > index 27bac0b..4a1582d 100644 > > --- a/drivers/dma/mediatek/Kconfig > > +++ b/drivers/dma/mediatek/Kconfig > > @@ -11,3 +11,15 @@ config MTK_HSDMA > > This controller provides the channels which is dedicated to > > memory-to-memory transfer to offload from CPU through ring- > > based descriptor management. > > + > > +config MTK_CQDMA > > + tristate "MediaTek Command-Queue DMA controller support" > > + depends on ARCH_MEDIATEK || COMPILE_TEST > > + select DMA_ENGINE > > + select DMA_VIRTUAL_CHANNELS > > + help > > + Enable support for Command-Queue DMA controller on MediaTek > > + SoCs. > > + > > + This controller provides the channels which is dedicated to > > + memory-to-memory transfer to offload from CPU. > > diff --git a/drivers/dma/mediatek/Makefile b/drivers/dma/mediatek/Makefile > > index 6e778f8..41bb381 100644 > > --- a/drivers/dma/mediatek/Makefile > > +++ b/drivers/dma/mediatek/Makefile > > @@ -1 +1,2 @@ > > obj-$(CONFIG_MTK_HSDMA) += mtk-hsdma.o > > +obj-$(CONFIG_MTK_CQDMA) += mtk-cqdma.o > > diff --git a/drivers/dma/mediatek/mtk-cqdma.c > > b/drivers/dma/mediatek/mtk-cqdma.c > > new file mode 100644 > > index 000..304eb0a > > --- /dev/null > > +++ b/drivers/dma/mediatek/mtk-cqdma.c > > @@ -0,0 +1,867 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +// Copyright (c) 2018-2019 MediaTek Inc. > > + > > +/* > > + * Driver for MediaTek Command-Queue DMA Controller > > + * > > + * Author: Shun-Chih Yu > > + * > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include "../virt-dma.h" > > + > > +#define MTK_CQDMA_USEC_POLL10 > > +#define MTK_CQDMA_TIMEOUT_POLL 1000 > > +#define MTK_CQDMA_DMA_BUSWIDTHS > > BIT(DMA_SLAVE_BUSWIDTH_4_BYTES) > > +#define MTK_CQDMA_ALIGN_SIZE 1 > > + > > +/* The default number of virtual channel */ > > +#define MTK_CQDMA_NR_VCHANS32 > > + > > +/* The default number of physical channel */ > > +#define MTK_CQDMA_NR_PCHANS3 > > + > > +/* Registers for underlying dma manipulation */ > > +#define MTK_CQDMA_INT_FLAG 0x0 > > +#define MTK_CQDMA_INT_EN 0x4 > > +#define MTK_CQDMA_EN 0x8 > > +#define MTK_CQDMA_RESET0xc > > +#define MTK_CQDMA_FLUSH0x14 > > +#define MTK_CQDMA_SRC 0x1c > > +#define MTK_CQDMA_DST 0x20 > > +#define MTK_CQDMA_LEN1 0x24 > > +#define MTK_CQDMA_LEN2 0x28 > > drop unused macro and check if it happens at other places > > > +#define MTK_CQDMA_SRC2 0x60 > > +#define MTK_CQDMA_DST2 0x64 > > + > > +/* Registers setting */ > > +#define MTK_CQDMA_EN_BIT BIT(0) >
Re: [PATCH v3] pinctrl:mediatek:add EINT support to virtual GPIOs
On Mon, Dec 24, 2018 at 8:25 PM wrote: > > From: Chuanjia Liu > there are still some nitpicks an empty char should follow the ':' char > Virtual gpio only used inside SOC and not being exported to outside SOC. > Some modules use virtual gpio as eint and doesn't nedd SMT. s/nedd/need/ > So this patch add EINT support to virtual GPIOs. > > Signed-off-by: Chuanjia Liu > --- > change note: > v3 : 1. modify subject and description > 2. modify comments > --- > drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 10 +- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c > b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c > index 4a9e0d4c2bbc..a0db145f798d 100644 > --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c > +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c > @@ -290,7 +290,15 @@ static int mtk_xt_set_gpio_as_eint(void *data, unsigned > long eint_n) > return err; > > err = mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_SMT, MTK_ENABLE); > - if (err) > + /* merge the second line to be consistent with the other comment blocks > +*SMT is supposed to be supported by every real GPIO and doesn't an empty char should follow '*' char to be consistent with the other comment blocks and also in the other lines starting with '*' > +*support virtual GPIOs, so the extra condition err != -ENOTSUPP > +*is just for adding EINT support to these virtual GPIOs. It should > +*add an extra flag in the pin descriptor when more pins with > +*distinctive characteristic come out. > +*/ > + remove the blank line > + if (err && err != -ENOTSUPP) > return err; > > return 0; > -- > 2.19.1 >
Re: [PATCH v2] pinctrl:mediatek:add judgment conditions
On Mon, Dec 17, 2018 at 6:32 PM wrote: > I thought the subject still is much general, it should be further improved with something like "add EINT support to virtual GPIOs" and should say more about what virtual GPIOs means by MTKers in the patch description because "virtual" is a usual term used throughout the kernel and that would easily cause others to fail to interpret correctly. > From: Chuanjia Liu > > This patch avoid return err when virtual gpio set SMT. > > Signed-off-by: Chuanjia Liu > --- > change note: > v2 : 1. delete virtual gpio number > 2. add judgment conditions > --- > drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c > b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c > index 4a9e0d4c2bbc..a576e417744a 100644 > --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c > +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c > @@ -290,7 +290,11 @@ static int mtk_xt_set_gpio_as_eint(void *data, unsigned > long eint_n) > return err; > > err = mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_SMT, MTK_ENABLE); > - if (err) > + > + /* SMT doesn't support virtual GPIO, add err != -ENOTSUPP is used for > +* avoid return err when virtual gpio set SMT. > +*/ I'd prefer to the comments as the below /* SMT is supposed to be supported by every real GPIO and doesn't support virtual GPIOs, so the extra condition err != -ENOTSUPP is just for adding EINT support to these virtual GPIOs. It should add an extra flag in the pin descriptor when more pins with distinctive characteristic come out. */ > + if (err && err != -ENOTSUPP) > return err; > > return 0; > -- > 2.19.1 >
Re: [PATCH 2/2] net-next: stmmac: dwmac-mediatek: remove fine-tune property
On Mon, Dec 17, 2018 at 6:43 PM Biao Huang wrote:
>
> 1. remove fine-tune property and related setting to simplify
> the timing adjustment flow.
> 2. set timing value according to the value from device tree,
> and will not care whether PHY insert internal delay.
>
> Signed-off-by: Biao Huang
> ---
> .../net/ethernet/stmicro/stmmac/dwmac-mediatek.c | 71
> +++-
> 1 file changed, 24 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c
> b/drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c
> index e400cbd..801c797 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c
> @@ -44,7 +44,6 @@ struct mac_delay_struct {
> u32 rx_delay;
> bool tx_inv;
> bool rx_inv;
> - bool fine_tune;
> };
>
> struct mediatek_dwmac_plat_data {
> @@ -105,16 +104,28 @@ static int mt2712_set_interface(struct
> mediatek_dwmac_plat_data *plat)
> return 0;
> }
>
> -static void mt2712_delay_ps2stage(struct mac_delay_struct *mac_delay)
> +static void mt2712_delay_ps2stage(struct mediatek_dwmac_plat_data *plat)
> {
> - if (mac_delay->fine_tune) {
> - /* 170ps per stage for fine tune delay macro circuit*/
> - mac_delay->tx_delay /= 170;
> - mac_delay->rx_delay /= 170;
> - } else {
> - /* 550ps per stage for coarse tune delay macro circuit*/
> + struct mac_delay_struct *mac_delay = >mac_delay;
> +
> + switch (plat->phy_mode) {
> + case PHY_INTERFACE_MODE_MII:
> + case PHY_INTERFACE_MODE_RMII:
> + /* 550ps per stage for mii/rmii*/
> mac_delay->tx_delay /= 550;
> mac_delay->rx_delay /= 550;
> + break;
> + case PHY_INTERFACE_MODE_RGMII:
> + case PHY_INTERFACE_MODE_RGMII_TXID:
> + case PHY_INTERFACE_MODE_RGMII_RXID:
> + case PHY_INTERFACE_MODE_RGMII_ID:
> + /* 170ps per stage for mii/rmii*/
mii/rmii appear to be a typo here.
Additionally, I'd suggest using the capital letters for these abbreviations.
> + mac_delay->tx_delay /= 170;
> + mac_delay->rx_delay /= 170;
> + break;
> + default:
> + dev_err(plat->dev, "phy interface not supported\n");
> + break;
> }
> }
>
> @@ -123,7 +134,7 @@ static int mt2712_set_delay(struct
> mediatek_dwmac_plat_data *plat)
> struct mac_delay_struct *mac_delay = >mac_delay;
> u32 delay_val = 0, fine_val = 0;
>
> - mt2712_delay_ps2stage(mac_delay);
> + mt2712_delay_ps2stage(plat);
>
> switch (plat->phy_mode) {
> case PHY_INTERFACE_MODE_MII:
> @@ -167,13 +178,10 @@ static int mt2712_set_delay(struct
> mediatek_dwmac_plat_data *plat)
> fine_val = ETH_RMII_DLY_TX_INV;
> break;
> case PHY_INTERFACE_MODE_RGMII:
> - /* the PHY is not responsible for inserting any internal
> -* delay by itself in PHY_INTERFACE_MODE_RGMII case,
> -* so Ethernet MAC will insert delays for both transmit
> -* and receive path here.
> -*/
> - if (mac_delay->fine_tune)
> - fine_val = ETH_FINE_DLY_GTXC | ETH_FINE_DLY_RXC;
> + case PHY_INTERFACE_MODE_RGMII_TXID:
> + case PHY_INTERFACE_MODE_RGMII_RXID:
> + case PHY_INTERFACE_MODE_RGMII_ID:
> + fine_val = ETH_FINE_DLY_GTXC | ETH_FINE_DLY_RXC;
>
> delay_val |= FIELD_PREP(ETH_DLY_GTXC_ENABLE,
> !!mac_delay->tx_delay);
> delay_val |= FIELD_PREP(ETH_DLY_GTXC_STAGES,
> mac_delay->tx_delay);
> @@ -183,36 +191,6 @@ static int mt2712_set_delay(struct
> mediatek_dwmac_plat_data *plat)
> delay_val |= FIELD_PREP(ETH_DLY_RXC_STAGES,
> mac_delay->rx_delay);
> delay_val |= FIELD_PREP(ETH_DLY_RXC_INV, mac_delay->rx_inv);
> break;
> - case PHY_INTERFACE_MODE_RGMII_TXID:
> - /* the PHY should insert an internal delay for the transmit
> -* path in PHY_INTERFACE_MODE_RGMII_TXID case,
> -* so Ethernet MAC will insert the delay for receive path
> here.
> -*/
> - if (mac_delay->fine_tune)
> - fine_val = ETH_FINE_DLY_RXC;
> -
> - delay_val |= FIELD_PREP(ETH_DLY_RXC_ENABLE,
> !!mac_delay->rx_delay);
> - delay_val |= FIELD_PREP(ETH_DLY_RXC_STAGES,
> mac_delay->rx_delay);
> - delay_val |= FIELD_PREP(ETH_DLY_RXC_INV, mac_delay->rx_inv);
> - break;
> - case PHY_INTERFACE_MODE_RGMII_RXID:
> - /* the PHY should insert an internal delay for the receive
> -* path in PHY_INTERFACE_MODE_RGMII_RXID case,
> -* so Ethernet MAC will insert the delay
Re: [PATCH v5 1/2] dmaengine: 8250_mtk_dma: add Mediatek uart DMA support
On Mon, Dec 17, 2018 at 12:40 AM Long Cheng wrote:
>
> On Fri, 2018-12-14 at 12:09 -0800, Sean Wang wrote:
< ... >
> > > > > +
> > > > > + 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);
> > > >
> > > > I'd prefer to move those channel interrupt enablement to
> > > > .device_alloc_chan_resources
> > > > and related disablement to .device_free_chan_resources
> > > >
> > >
> > > i think that, first need set the config to HW, and the enable the DMA.
> > >
> >
> > I've read through the client driver and the dmaengine, I probably know
> > how interaction they work and find out there is something you seem
> > completely make a wrong.
> >
> > You can't do enable DMA with enabling VFF here. That causes a big
> > problem, DMA would self decide to move data and not managed and issued
> > by the dmaengine framework. For instance in DMA Tx path, because you
> > enable the DMA and DMA buffer (VFF) and UART Tx ring uses the same
> > memory area, DMA would self start to move data once data from
> > userland go in Tx ring even without being issued by dmaengine.
> >
> > Instead, you should ensure all descriptors are being batched by
> > .device_prep_slave_sg and DMA does not start moving data until
> > .device_issue_pending done and once descriptors are issued, DMA
> > hardware or software have to do it as fast as possible.
> >
>
> the VFF enable just enable the DMA function. DMA can't move data here.
> Now, the code get length of the data in '.device_prep_slave_sg'.
> And let DMA move data in '.device_issue_pending function'. in here, just
> enable the function.
>
My all curiosity are all from the descriptor programmed in
.device_issue_pending in the other drivers at least includes
information such data length, target address, and hardware control
code, but in the driver only includes data length and even the target
address is set up at device_config, that seems unusual.
And, It does too for DMA_DEV_TO_MEM? What I see is there is almost no
any code be programmed for kick off the hardware for the direction but
DMA still can move. That is another point I got confused.
> > > > > +
> > > > > + if (!c->requested) {
> > > > > + c->requested = true;
> > > > > + ret =
> > > > > request_irq(mtkd->dma_irq[chan->chan_id],
> > > > > + mtk_dma_rx_interrupt,
> > > > > + IRQF_TRIGGER_NONE,
> > > > > + KBUILD_MODNAME, chan);
> > > >
> > > > ISR registration usually happens as the driver got probe, it can give
> > > > the system more flexibility to manage such IRQ affinity on the fly.
> > > >
> > >
> > > i will move the request irq to alloc channel.
> > >
> >
> > why don't let it done in driver probe?
> >
> there are many uart ports, like UART[0-5]. in probe, just get the all
> irq of ports. which port is using, who request irq. example, UART1 is
> using. we just request irq of uart1. uart0, uart[2-5] don't need request
> irq.
>
> > > > > + 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;
> > > >
> > > > Ditto as above, it seems you should use cfg->dst_port_window_size
> > > >
> > > > > +
> > > > > + mtk_dma_chan_write(c, VFF_ADDR, cfg->dst_addr);
> > > >
Re: [PATCH] eint: add gpio vritual number select
On Sun, Dec 16, 2018 at 7:15 PM Chuanjia Liu wrote:
>
> On Thu, 2018-12-13 at 11:33 -0800, Sean Wang wrote:
> > On Thu, Dec 13, 2018 at 1:36 AM wrote:
> > >
> > > From: Chuanjia Liu
> > >
> > > This patch add gpio vritual number select,avoid virtual gpio set SMT.
> >
> > s/gpio/GPIO/
> > s/vritual/virtual/
> >
> > Virtual GPIOs you said here that means these pins only used inside SoC
> > and not being exported to outside SoC, right? It seems this kind of
> > pins doesn't need SMT.
> >
> Yes,virtual gpio only used inside SOC and these pins doesn't need set
> SMT
> > >
> > > Signed-off-by: Chuanjia Liu
> > > ---
> > > drivers/pinctrl/mediatek/mtk-eint.h |1 +
> > > drivers/pinctrl/mediatek/pinctrl-mt8183.c|1 +
> > > drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c |9 ++---
> > > 3 files changed, 8 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/pinctrl/mediatek/mtk-eint.h
> > > b/drivers/pinctrl/mediatek/mtk-eint.h
> > > index 48468d0..c16beaf 100644
> > > --- a/drivers/pinctrl/mediatek/mtk-eint.h
> > > +++ b/drivers/pinctrl/mediatek/mtk-eint.h
> > > @@ -37,6 +37,7 @@ struct mtk_eint_hw {
> > > u8 ports;
> > > unsigned intap_num;
> > > unsigned intdb_cnt;
> > > + unsigned intvir_start;
> > > };
> > >
> > > struct mtk_eint;
> > > diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> > > b/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> > > index 6262fd3..bbeafd3 100644
> > > --- a/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> > > +++ b/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> > > @@ -497,6 +497,7 @@
> > > .ports = 6,
> > > .ap_num= 212,
> > > .db_cnt= 13,
> > > + .vir_start = 180,
> > > };
> > >
> > > static const struct mtk_pin_soc mt8183_data = {
> > > diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> > > b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> > > index 4a9e0d4..ca3bae1 100644
> > > --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> > > +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> > > @@ -289,9 +289,12 @@ static int mtk_xt_set_gpio_as_eint(void *data,
> > > unsigned long eint_n)
> > > if (err)
> > > return err;
> > >
> > > - err = mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_SMT, MTK_ENABLE);
> > > - if (err)
> > > - return err;
> > > + if (gpio_n < hw->eint->hw->vir_start) {
> > > + err = mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_SMT,
> > > + MTK_ENABLE);
> > > + if (err)
> > > + return err;
> > > + }
> >
> > The changes will break these SoCs without a properly configured vir_start.
> >
> > If SMT seems unnecessary for these kinds of virtual GPIOs pin in the
> > path, we can do it as
> >
> > err = mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_SMT,
> > MTK_ENABLE);
> > /* please add comments for the exclusion condition */
> > if (err && err != -ENOTSUPP)
> > return err;
> >
> > If there is getting much special on certain pins between SoCs, and
> > then we can consider creating a desc->flag to split logic.
>
> Yes,SMT unnecessary for these kinds of virtual GPIOS pin in the path,if
> do it as
> err = mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_SMT,
> MTK_ENABLE);
> if (err && err != -ENOTSUPP)
> return err;
> I wonder if system will lose -ENOTSUPP information when smt was not
> successfully set by real gpio?
-ENOTSUPP shouldn't happen in a real pin as SMT is supposed to be
supported by every real pin.
If it is not true or there are more special on certain pins, and then
we consider to add a flag to struct mtk_pin_desc to group these pins
with their characteristics and to split and reuse the common code flow
with the extra flag.
So for now, I thought it's enough to handle your case with adding a
few well self-explained comments for the exclusion condition. These
words help us remember we should add adding an extra flag to pin
description as one of TODO if more needs like you come out.
> >
> > >
> > > return 0;
> > > }
> > > --
> > > 1.7.9.5
>
>
Re: [PATCH v5 1/2] dmaengine: 8250_mtk_dma: add Mediatek uart DMA support
On Thu, Dec 13, 2018 at 3:36 AM Long Cheng wrote:
Hope those comments did not get a response that means they're fine with you.
< ... >
> > > +struct mtk_dmadev {
> > > + struct dma_device ddev;
> > > + void __iomem *mem_base[MTK_APDMA_CHANNELS];
> > > + spinlock_t lock; /* dma dev lock */
> > > + struct tasklet_struct task;
> >
> > we can drop tasklet and instead allows descriptors to be handled as
> > fast as possible.
> > similar suggestions have been made in the other dmaengine [1] and
> > mtk-hsdma.c
> >
>
> OK, i will remove these, and improve it.
>
Thanks, that would be great.
> > [1] https://lkml.org/lkml/2018/11/11/146
> >
> > > + 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];
> > > +};
> > > +
< ... >
> > > +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 = >sg[i];
> > > + size += sg->en * sg->fn;
> > > + }
> > > + d->len = size;
> > > + }
> > > +
> >
> > The driver always only handles data move for the single contiguous
> > area, but it seems the callback must provide the scatter-gather
> > function to the dmaegine. otherwise, why is the callback be called
> > device_prep_slave_sg?
> >
>
> because in 8250 UART native code, call the device_prep_slave_sg. we just
> use one ring buffer.
>
If it really did specifically for UART, you should show the function
only can handle only one entry in sg for the DMA in a few comments and
a sanity check for these invalid requests (more one entries in sg).
Otherwise, the hardware will get a failure and even function doesn't
complain or warn anything if more one entries in sg requested in.
Additionally, the code can be simplified much if it's just for the
specific use case.
> > > + return vchan_tx_prep(>vc, >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;
> > > + unsigned long flags;
> > > +
> > > + spin_lock_irqsave(>vc.lock, flags);
> > > + if (c->cfg.direction == DMA_DEV_TO_MEM) {
> > > + mtkd = to_mtk_dma_dev(chan->device);
> >
> > mtkd can be dropped as it seems no users
> >
< ... >
> > > +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;
> >
> > it seems you should use cfg->src_port_window_size as the comments explains
> >
> > * @src_port_window_size: The length of the register area in words the data
> > need
> > * to be accessed on the device side. It is only used for devices which is
> > using
> > * an area instead of a single register to receive the data. Typically the
> > DMA
> > * loops in this area in order to transfer the data.
> > * @dst_port_window_size: same as src_port_window_size but for the
> > destination
> > * port.
> >
>
> in 8250 UART native code, will set the parameter. if want to modify
> this, i think that maybe at next kernel release, we can modify it. i
Re: [PATCH] eint: add gpio vritual number select
And the subject should be also corrected with prefix starting with
"pinctrl: mediatek:", typo fixup, and having a better subject close to
the content.
On Thu, Dec 13, 2018 at 1:36 AM wrote:
>
> From: Chuanjia Liu
>
> This patch add gpio vritual number select,avoid virtual gpio set SMT.
>
> Signed-off-by: Chuanjia Liu
> ---
> drivers/pinctrl/mediatek/mtk-eint.h |1 +
> drivers/pinctrl/mediatek/pinctrl-mt8183.c|1 +
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c |9 ++---
> 3 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pinctrl/mediatek/mtk-eint.h
> b/drivers/pinctrl/mediatek/mtk-eint.h
> index 48468d0..c16beaf 100644
> --- a/drivers/pinctrl/mediatek/mtk-eint.h
> +++ b/drivers/pinctrl/mediatek/mtk-eint.h
> @@ -37,6 +37,7 @@ struct mtk_eint_hw {
> u8 ports;
> unsigned intap_num;
> unsigned intdb_cnt;
> + unsigned intvir_start;
> };
>
> struct mtk_eint;
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> b/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> index 6262fd3..bbeafd3 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> @@ -497,6 +497,7 @@
> .ports = 6,
> .ap_num= 212,
> .db_cnt= 13,
> + .vir_start = 180,
> };
>
> static const struct mtk_pin_soc mt8183_data = {
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> index 4a9e0d4..ca3bae1 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> @@ -289,9 +289,12 @@ static int mtk_xt_set_gpio_as_eint(void *data, unsigned
> long eint_n)
> if (err)
> return err;
>
> - err = mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_SMT, MTK_ENABLE);
> - if (err)
> - return err;
> + if (gpio_n < hw->eint->hw->vir_start) {
> + err = mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_SMT,
> + MTK_ENABLE);
> + if (err)
> + return err;
> + }
>
> return 0;
> }
> --
> 1.7.9.5
Re: [PATCH] eint: add gpio vritual number select
On Thu, Dec 13, 2018 at 1:36 AM wrote:
>
> From: Chuanjia Liu
>
> This patch add gpio vritual number select,avoid virtual gpio set SMT.
s/gpio/GPIO/
s/vritual/virtual/
Virtual GPIOs you said here that means these pins only used inside SoC
and not being exported to outside SoC, right? It seems this kind of
pins doesn't need SMT.
>
> Signed-off-by: Chuanjia Liu
> ---
> drivers/pinctrl/mediatek/mtk-eint.h |1 +
> drivers/pinctrl/mediatek/pinctrl-mt8183.c|1 +
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c |9 ++---
> 3 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pinctrl/mediatek/mtk-eint.h
> b/drivers/pinctrl/mediatek/mtk-eint.h
> index 48468d0..c16beaf 100644
> --- a/drivers/pinctrl/mediatek/mtk-eint.h
> +++ b/drivers/pinctrl/mediatek/mtk-eint.h
> @@ -37,6 +37,7 @@ struct mtk_eint_hw {
> u8 ports;
> unsigned intap_num;
> unsigned intdb_cnt;
> + unsigned intvir_start;
> };
>
> struct mtk_eint;
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> b/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> index 6262fd3..bbeafd3 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> @@ -497,6 +497,7 @@
> .ports = 6,
> .ap_num= 212,
> .db_cnt= 13,
> + .vir_start = 180,
> };
>
> static const struct mtk_pin_soc mt8183_data = {
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> index 4a9e0d4..ca3bae1 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> @@ -289,9 +289,12 @@ static int mtk_xt_set_gpio_as_eint(void *data, unsigned
> long eint_n)
> if (err)
> return err;
>
> - err = mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_SMT, MTK_ENABLE);
> - if (err)
> - return err;
> + if (gpio_n < hw->eint->hw->vir_start) {
> + err = mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_SMT,
> + MTK_ENABLE);
> + if (err)
> + return err;
> + }
The changes will break these SoCs without a properly configured vir_start.
If SMT seems unnecessary for these kinds of virtual GPIOs pin in the
path, we can do it as
err = mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_SMT,
MTK_ENABLE);
/* please add comments for the exclusion condition */
if (err && err != -ENOTSUPP)
return err;
If there is getting much special on certain pins between SoCs, and
then we can consider creating a desc->flag to split logic.
>
> return 0;
> }
> --
> 1.7.9.5
Re: [PATCH v1] pinctrl: mediatek: improve Kconfig dependencies
It looks good to me. Thanks for bringing the improved version soon. Acked-by: Sean Wang On Wed, Dec 12, 2018 at 6:28 PM Ryder Lee wrote: > > Remove prompts to make all pinctrl cores to non-visible symbols and > make sure the target SoCs would be coupled with the corresponding > cores. > > Signed-off-by: Ryder Lee > --- > Changes since v1: > - Revise commit message > - Change all pinctrl cores to non-visible symbols > - Drop EINT_MTK in PINCTRL_MTK_MOORE > --- > drivers/pinctrl/mediatek/Kconfig | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git a/drivers/pinctrl/mediatek/Kconfig > b/drivers/pinctrl/mediatek/Kconfig > index d8cb584..1817786 100644 > --- a/drivers/pinctrl/mediatek/Kconfig > +++ b/drivers/pinctrl/mediatek/Kconfig > @@ -17,7 +17,7 @@ config PINCTRL_MTK > select OF_GPIO > > config PINCTRL_MTK_MOORE > - bool "MediaTek Moore Core that implements generic binding" > + bool > depends on OF > select GENERIC_PINCONF > select GENERIC_PINCTRL_GROUPS > @@ -26,7 +26,7 @@ config PINCTRL_MTK_MOORE > select OF_GPIO > > config PINCTRL_MTK_PARIS > - bool "MediaTek Paris Core that implements vendor binding" > + bool > depends on OF > select PINMUX > select GENERIC_PINCONF > @@ -45,14 +45,14 @@ config PINCTRL_MT2701 > config PINCTRL_MT7623 > bool "Mediatek MT7623 pin control with generic binding" > depends on MACH_MT7623 || COMPILE_TEST > - depends on PINCTRL_MTK_MOORE > - default y > + default MACH_MT7623 > + select PINCTRL_MTK_MOORE > > config PINCTRL_MT7629 > bool "Mediatek MT7629 pin control" > depends on MACH_MT7629 || COMPILE_TEST > - depends on PINCTRL_MTK_MOORE > - default y > + default MACH_MT7629 > + select PINCTRL_MTK_MOORE > > config PINCTRL_MT8135 > bool "Mediatek MT8135 pin control" > @@ -93,8 +93,8 @@ config PINCTRL_MT6797 > config PINCTRL_MT7622 > bool "MediaTek MT7622 pin control" > depends on ARM64 || COMPILE_TEST > - depends on PINCTRL_MTK_MOORE > - default y > + default ARM64 && ARCH_MEDIATEK > + select PINCTRL_MTK_MOORE > > config PINCTRL_MT8173 > bool "Mediatek MT8173 pin control" > -- > 1.9.1 >
Re: [PATCH] pinctrl: mediatek: improve dependencies for PINCTRL_MTK_MOORE
On Wed, Dec 12, 2018 at 1:59 AM Ryder Lee wrote: > > Improve dependencies for the pinctrl drivers which select > PINCTRL_MTK_MOORE as its core layer. > --- > drivers/pinctrl/mediatek/Kconfig | 13 +++-- > 1 file changed, 7 insertions(+), 6 deletions(-) > > diff --git a/drivers/pinctrl/mediatek/Kconfig > b/drivers/pinctrl/mediatek/Kconfig > index d8cb584..3a41dc8 100644 > --- a/drivers/pinctrl/mediatek/Kconfig > +++ b/drivers/pinctrl/mediatek/Kconfig > @@ -23,6 +23,7 @@ config PINCTRL_MTK_MOORE > select GENERIC_PINCTRL_GROUPS > select GENERIC_PINMUX_FUNCTIONS > select GPIOLIB > + select EINT_MTK The change can be taken away from the patch as the patch EINT_MTK is optional to the moore core. > select OF_GPIO > > config PINCTRL_MTK_PARIS > @@ -45,14 +46,14 @@ config PINCTRL_MT2701 > config PINCTRL_MT7623 > bool "Mediatek MT7623 pin control with generic binding" > depends on MACH_MT7623 || COMPILE_TEST > - depends on PINCTRL_MTK_MOORE > - default y > + default MACH_MT7623 > + select PINCTRL_MTK_MOORE > > config PINCTRL_MT7629 > bool "Mediatek MT7629 pin control" > depends on MACH_MT7629 || COMPILE_TEST > - depends on PINCTRL_MTK_MOORE > - default y > + default MACH_MT7629 > + select PINCTRL_MTK_MOORE > > config PINCTRL_MT8135 > bool "Mediatek MT8135 pin control" > @@ -93,8 +94,8 @@ config PINCTRL_MT6797 > config PINCTRL_MT7622 > bool "MediaTek MT7622 pin control" > depends on ARM64 || COMPILE_TEST > - depends on PINCTRL_MTK_MOORE > - default y > + default ARM64 && ARCH_MEDIATEK > + select PINCTRL_MTK_MOORE > We can add a change allowing PINCTRL_MTK_MOORE to be a non-visible symbol in the same patch according to the general rules kconfig-language.txt defines. And also turn PINCTRL_MTK_PARIS to non-visible in another patch would be good. Apart from that, the above three changes are fine with me, it helps to be more consistent with other driver and the target SoC would be coupled with the corresponding essential pinctrl driver. > config PINCTRL_MT8173 > bool "Mediatek MT8173 pin control" > -- > 1.9.1 >
Re: [PATCH v5 1/2] dmaengine: 8250_mtk_dma: add Mediatek uart DMA support
Sorry for that I didn't have a full review at one time in the earlier version
On Mon, Dec 10, 2018 at 9:37 PM Long Cheng
wrote:
>
> In DMA engine framework, add 8250 mtk dma to support it.
It looks like there are still many rooms to improve the description,
especially it's a totally new driver.
>
> Signed-off-by: Long Cheng
> ---
> drivers/dma/mediatek/8250_mtk_dma.c | 830
> +++
> drivers/dma/mediatek/Kconfig| 11 +
> drivers/dma/mediatek/Makefile |1 +
> 3 files changed, 842 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 000..f79d180
> --- /dev/null
> +++ b/drivers/dma/mediatek/8250_mtk_dma.c
> @@ -0,0 +1,830 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Mediatek 8250 DMA driver.
MediaTek
> + *
> + * Copyright (c) 2018 MediaTek Inc.
> + * Author: Long Cheng
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#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_BBIT(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_BBIT(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_B0
> +#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 0xU
> +/* invert this bit when wrap ring head again*/
> +#define MTK_DMA_RING_WRAP 0x1U
> +
> +#define VFF_INT_FLAG 0x00
> +#define VFF_INT_EN 0x04
> +#define VFF_EN 0x08
> +#define VFF_RST0x0c
> +#define VFF_STOP 0x10
> +#define VFF_FLUSH 0x14
> +#define VFF_ADDR 0x1c
> +#define VFF_LEN0x24
> +#define VFF_THRE 0x28
> +#define VFF_WPT0x2c
> +#define VFF_RPT0x30
> +/*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;
we can drop tasklet and instead allows descriptors to be handled as
fast as possible.
similar suggestions have been made in the other dmaengine [1] and mtk-hsdma.c
[1] https://lkml.org/lkml/2018/11/11/146
> + 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 rx_status;
> +};
> +
> +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];
> +
> + unsigned int len;
> +};
> +
> +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,
Re: [PATCH] pinctrl: add drive for I2C related pins on MT8183
The subject should be refined to be close to the content
On Tue, Dec 11, 2018 at 12:02 AM Zhiyong Tao wrote:
>
> This patch provides the advanced drive for I2C used pins on MT8183.
>
Additionally, you should state more how much strength in mA given on
each step E1, E0 move forward. This way would help to reuse the scheme
on the similar SoCs.
> Signed-off-by: Zhiyong Tao
> ---
> drivers/pinctrl/mediatek/pinctrl-mt8183.c| 50
>
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 45 +
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h | 13 ++
> drivers/pinctrl/mediatek/pinctrl-paris.c | 20 ++
> 4 files changed, 128 insertions(+)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> b/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> index 6262fd3678ea..5244e1b27b1d 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> @@ -472,6 +472,51 @@ static const struct mtk_pin_field_calc
> mt8183_pin_r1_range[] = {
> PIN_FIELD_BASE(133, 133, 8, 0x0D0, 0x10, 13, 1),
> };
>
> +static const struct mtk_pin_field_calc mt8183_pin_drv_en_dis_range[] = {
I'd prefer using the word mt8183_pin_e1e0en_range to keep people away from
be confused the relationship with the existing mt8183_pin_drv_range.
> + PIN_FIELD_BASE(48, 48, 3, 0x0F0, 0x10, 20, 1),
> + PIN_FIELD_BASE(49, 49, 3, 0x0F0, 0x10, 15, 1),
> + PIN_FIELD_BASE(50, 50, 4, 0x0F0, 0x10, 12, 1),
> + PIN_FIELD_BASE(51, 51, 4, 0x0F0, 0x10, 7, 1),
> + PIN_FIELD_BASE(81, 81, 5, 0x0F0, 0x10, 12, 1),
> + PIN_FIELD_BASE(82, 82, 5, 0x0F0, 0x10, 9, 1),
> + PIN_FIELD_BASE(83, 83, 5, 0x0F0, 0x10, 19, 1),
> + PIN_FIELD_BASE(84, 84, 5, 0x0F0, 0x10, 22, 1),
> + PIN_FIELD_BASE(103, 103, 6, 0x0F0, 0x10, 24, 1),
> + PIN_FIELD_BASE(104, 104, 6, 0x0F0, 0x10, 14, 1),
> + PIN_FIELD_BASE(105, 105, 6, 0x0F0, 0x10, 27, 1),
> + PIN_FIELD_BASE(106, 106, 6, 0x0F0, 0x10, 17, 1),
> +};
> +
> +static const struct mtk_pin_field_calc mt8183_pin_drv_e0_range[] = {
Ditto, I'd prefer using the word mt8183_pin_e0_range
> + PIN_FIELD_BASE(48, 48, 3, 0x0F0, 0x10, 21, 1),
> + PIN_FIELD_BASE(49, 49, 3, 0x0F0, 0x10, 16, 1),
> + PIN_FIELD_BASE(50, 50, 4, 0x0F0, 0x10, 13, 1),
> + PIN_FIELD_BASE(51, 51, 4, 0x0F0, 0x10, 8, 1),
> + PIN_FIELD_BASE(81, 81, 5, 0x0F0, 0x10, 13, 1),
> + PIN_FIELD_BASE(82, 82, 5, 0x0F0, 0x10, 10, 1),
> + PIN_FIELD_BASE(83, 83, 5, 0x0F0, 0x10, 20, 1),
> + PIN_FIELD_BASE(84, 84, 5, 0x0F0, 0x10, 23, 1),
> + PIN_FIELD_BASE(103, 103, 6, 0x0F0, 0x10, 25, 1),
> + PIN_FIELD_BASE(104, 104, 6, 0x0F0, 0x10, 15, 1),
> + PIN_FIELD_BASE(105, 105, 6, 0x0F0, 0x10, 28, 1),
> + PIN_FIELD_BASE(106, 106, 6, 0x0F0, 0x10, 18, 1),
> +};
> +
> +static const struct mtk_pin_field_calc mt8183_pin_drv_e1_range[] = {
Ditto, I'd prefer using the word mt8183_pin_e1_range
> + PIN_FIELD_BASE(48, 48, 3, 0x0F0, 0x10, 22, 1),
> + PIN_FIELD_BASE(49, 49, 3, 0x0F0, 0x10, 17, 1),
> + PIN_FIELD_BASE(50, 50, 4, 0x0F0, 0x10, 14, 1),
> + PIN_FIELD_BASE(51, 51, 4, 0x0F0, 0x10, 9, 1),
> + PIN_FIELD_BASE(81, 81, 5, 0x0F0, 0x10, 14, 1),
> + PIN_FIELD_BASE(82, 82, 5, 0x0F0, 0x10, 11, 1),
> + PIN_FIELD_BASE(83, 83, 5, 0x0F0, 0x10, 21, 1),
> + PIN_FIELD_BASE(84, 84, 5, 0x0F0, 0x10, 24, 1),
> + PIN_FIELD_BASE(103, 103, 6, 0x0F0, 0x10, 26, 1),
> + PIN_FIELD_BASE(104, 104, 6, 0x0F0, 0x10, 16, 1),
> + PIN_FIELD_BASE(105, 105, 6, 0x0F0, 0x10, 29, 1),
> + PIN_FIELD_BASE(106, 106, 6, 0x0F0, 0x10, 19, 1),
> +};
> +
> static const struct mtk_pin_reg_calc mt8183_reg_cals[PINCTRL_PIN_REG_MAX] = {
> [PINCTRL_PIN_REG_MODE] = MTK_RANGE(mt8183_pin_mode_range),
> [PINCTRL_PIN_REG_DIR] = MTK_RANGE(mt8183_pin_dir_range),
> @@ -485,6 +530,9 @@ static const struct mtk_pin_reg_calc
> mt8183_reg_cals[PINCTRL_PIN_REG_MAX] = {
> [PINCTRL_PIN_REG_PUPD] = MTK_RANGE(mt8183_pin_pupd_range),
> [PINCTRL_PIN_REG_R0] = MTK_RANGE(mt8183_pin_r0_range),
> [PINCTRL_PIN_REG_R1] = MTK_RANGE(mt8183_pin_r1_range),
> + [PINCTRL_PIN_REG_DRV_EN_DIS] = MTK_RANGE(mt8183_pin_drv_en_dis_range),
> + [PINCTRL_PIN_REG_DRV_E0] = MTK_RANGE(mt8183_pin_drv_e0_range),
> + [PINCTRL_PIN_REG_DRV_E1] = MTK_RANGE(mt8183_pin_drv_e1_range),
> };
>
> static const char * const mt8183_pinctrl_register_base_names[] = {
> @@ -517,6 +565,8 @@ static const struct mtk_pin_soc mt8183_data = {
> .drive_get = mtk_pinconf_drive_get_rev1,
> .adv_pull_get = mtk_pinconf_adv_pull_get,
> .adv_pull_set = mtk_pinconf_adv_pull_set,
> + .adv_drive_get = mtk_pinconf_adv_drive_get,
> + .adv_drive_set = mtk_pinconf_adv_drive_set,
DT property drive-strength is generic enough to all SoCs so we don't
need to create extra callbacks to serve the extra property about the
Re: [PATCH v3 1/4] dt-bindings: pinctrl: Add devicetree bindings for MT6797 SoC Pinctrl
Hi Olof, I'm a guy from MediaTek. Thanks for your input and we will get these bad things to be better. On Fri, Dec 7, 2018 at 10:42 AM Olof Johansson wrote: > > On Wed, Dec 5, 2018 at 4:01 AM Linus Walleij wrote: > > > > On Mon, Dec 3, 2018 at 2:08 AM Matthias Brugger > > wrote: > > > On 15/11/2018 11:04, Linus Walleij wrote: > > > > On Wed, Nov 7, 2018 at 6:49 PM Manivannan Sadhasivam > > > > wrote: > > > > > > > >> Add devicetree bindings for Mediatek MT6797 SoC Pin Controller. > > > >> > > > >> Signed-off-by: Manivannan Sadhasivam > > > > > > > > Patch applied. > > > > > > > > > > Could you provide a stable tree for me, so that I can take the dts parts? > > > I just realized that my build is broken because of the missing dt-bindings > > > header file. > > > > Since I pulled other changes on top it is too late for me to put that > > in an immutable branch and merge into my tree separately, > > you would have to pull in the whole "devel" branch from the > > pin control tree. > > > > What we sometimes do is simply apply the *EXACT* same patch > > to two git trees. Git will cope with that as long as they are > > absolutely *IDENTICAL*. (The patch will appear twice in the > > git log with different hashes but they will merge without > > problems, a bit unelegant but it works.) > > > > So in your situation I would extract this patch from the pinctrl > > tree: > > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=devel=95d2f00657ad4c2c3eacd8a871a7aa022c3fe7d9 > > and apply it with some notice to the maintainers about > > the situation. > > > > ARM SoC folks: agreed? > > So, applying the patches in parallel is fine, but this made me look at > the actual patches and file contents, and they seem to be a bit messy. > I've also noticed the messy thing so we've changed these doable SoCs to using generic pinctrl bindings like MT7622 and MT7629 to get rid of the big header. And for the other SoCs, they still tend to keep vendor binding because of historical reasons, the related board makers preferences and it is indeed a little hard to change what these people used to. > This feedback is more to the MT maintainers/developers than you, Linus > (obviously): > > These header files are huge, and they're inconsistent in the way they > define these constants: > > include/dt-bindings/pinctrl/mt7623-pinfunc.h: > #define MT7623_PIN_21_PCM_TX_FUNC_GPIO21 (MTK_PIN_NO(21) | 0) > #define MT7623_PIN_21_PCM_TX_FUNC_PCM_TX (MTK_PIN_NO(21) | 1) > #define MT7623_PIN_21_PCM_TX_FUNC_MRG_TX (MTK_PIN_NO(21) | 2) > #define MT7623_PIN_21_PCM_TX_FUNC_MRG_RX (MTK_PIN_NO(21) | 3) > #define MT7623_PIN_21_PCM_TX_FUNC_PCM_RX (MTK_PIN_NO(21) | 4) > #define MT7623_PIN_21_PCM_TX_FUNC_CONN_DSP_JMS (MTK_PIN_NO(21) | 5) > #define MT7623_PIN_21_PCM_TX_FUNC_AP_PCM_TX (MTK_PIN_NO(21) | 6) > > include/dt-bindings/pinctrl/mt6397-pinfunc.h: > #define MT6397_PIN_24_ROW4__FUNC_GPIO24 (MTK_PIN_NO(24) | 0) > #define MT6397_PIN_24_ROW4__FUNC_ROW4 (MTK_PIN_NO(24) | 1) > #define MT6397_PIN_24_ROW4__FUNC_EINT22_1X (MTK_PIN_NO(24) | 2) > #define MT6397_PIN_24_ROW4__FUNC_SCL2_3X (MTK_PIN_NO(24) | 3) > #define MT6397_PIN_24_ROW4__FUNC_TEST_IN15 (MTK_PIN_NO(24) | 6) > #define MT6397_PIN_24_ROW4__FUNC_TEST_OUT15 (MTK_PIN_NO(24) | 7) > > include/dt-bindings/pinctrl/mt6797-pinfunc.h: > #define MT6797_GPIO34__FUNC_GPIO34 (MTK_PIN_NO(34) | 0) > #define MT6797_GPIO34__FUNC_CMFLASH (MTK_PIN_NO(34) | 1) > #define MT6797_GPIO34__FUNC_CLKM0 (MTK_PIN_NO(34) | 2) > #define MT6797_GPIO34__FUNC_UDI_NTRST (MTK_PIN_NO(34) | 3) > #define MT6797_GPIO34__FUNC_SCP_JTAG_TRSTN (MTK_PIN_NO(34) | 4) > #define MT6797_GPIO34__FUNC_CONN_MCU_TRST_B (MTK_PIN_NO(34) | 5) > #define MT6797_GPIO34__FUNC_MD_UTXD0 (MTK_PIN_NO(34) | 6) > #define MT6797_GPIO34__FUNC_C2K_DM_JTINTP (MTK_PIN_NO(34) | 7) > > So, is it a pin or a GPIO and why does 6797 use different naming > scheme? They all stand for the pin and list all the functions which the pin can be switched to. MT6797 is the first mtk pinctrl driver not contributed by mediatek people, we will try to fix these confusing things and should be careful keeping the naming be uniform in the future. > Why do some of them have __FUNC and some _FUNC?Why do some > have the non-gpio function as part of the name and some do not? > ditto, we will try to fix and keep the naming be uniform > Also, "pin 24 row 4 func row4"? Seems to have very limited value to > describe it in that manner, it's just overly verbose without adding > information. All the function names for a pin totally are same (copied) with hardware document describes. That means it's default function of the pin the hardware provides. > > Some other SoCs tend to use a pinctrl specifier that is two-cell function> instead of trying to pack them into one integer. I'm not the initial developer for the vendor binding. but I guessed the initial thought trying to pack them into one integer can decrease the risk of inconsistency between pin and function,
Re: [PATCH v3 1/4] dt-bindings: pinctrl: Add devicetree bindings for MT6797 SoC Pinctrl
Hi Olof, I'm a guy from MediaTek. Thanks for your input and we will get these bad things to be better. On Fri, Dec 7, 2018 at 10:42 AM Olof Johansson wrote: > > On Wed, Dec 5, 2018 at 4:01 AM Linus Walleij wrote: > > > > On Mon, Dec 3, 2018 at 2:08 AM Matthias Brugger > > wrote: > > > On 15/11/2018 11:04, Linus Walleij wrote: > > > > On Wed, Nov 7, 2018 at 6:49 PM Manivannan Sadhasivam > > > > wrote: > > > > > > > >> Add devicetree bindings for Mediatek MT6797 SoC Pin Controller. > > > >> > > > >> Signed-off-by: Manivannan Sadhasivam > > > > > > > > Patch applied. > > > > > > > > > > Could you provide a stable tree for me, so that I can take the dts parts? > > > I just realized that my build is broken because of the missing dt-bindings > > > header file. > > > > Since I pulled other changes on top it is too late for me to put that > > in an immutable branch and merge into my tree separately, > > you would have to pull in the whole "devel" branch from the > > pin control tree. > > > > What we sometimes do is simply apply the *EXACT* same patch > > to two git trees. Git will cope with that as long as they are > > absolutely *IDENTICAL*. (The patch will appear twice in the > > git log with different hashes but they will merge without > > problems, a bit unelegant but it works.) > > > > So in your situation I would extract this patch from the pinctrl > > tree: > > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=devel=95d2f00657ad4c2c3eacd8a871a7aa022c3fe7d9 > > and apply it with some notice to the maintainers about > > the situation. > > > > ARM SoC folks: agreed? > > So, applying the patches in parallel is fine, but this made me look at > the actual patches and file contents, and they seem to be a bit messy. > I've also noticed the messy thing so we've changed these doable SoCs to using generic pinctrl bindings like MT7622 and MT7629 to get rid of the big header. And for the other SoCs, they still tend to keep vendor binding because of historical reasons, the related board makers preferences and it is indeed a little hard to change what these people used to. > This feedback is more to the MT maintainers/developers than you, Linus > (obviously): > > These header files are huge, and they're inconsistent in the way they > define these constants: > > include/dt-bindings/pinctrl/mt7623-pinfunc.h: > #define MT7623_PIN_21_PCM_TX_FUNC_GPIO21 (MTK_PIN_NO(21) | 0) > #define MT7623_PIN_21_PCM_TX_FUNC_PCM_TX (MTK_PIN_NO(21) | 1) > #define MT7623_PIN_21_PCM_TX_FUNC_MRG_TX (MTK_PIN_NO(21) | 2) > #define MT7623_PIN_21_PCM_TX_FUNC_MRG_RX (MTK_PIN_NO(21) | 3) > #define MT7623_PIN_21_PCM_TX_FUNC_PCM_RX (MTK_PIN_NO(21) | 4) > #define MT7623_PIN_21_PCM_TX_FUNC_CONN_DSP_JMS (MTK_PIN_NO(21) | 5) > #define MT7623_PIN_21_PCM_TX_FUNC_AP_PCM_TX (MTK_PIN_NO(21) | 6) > > include/dt-bindings/pinctrl/mt6397-pinfunc.h: > #define MT6397_PIN_24_ROW4__FUNC_GPIO24 (MTK_PIN_NO(24) | 0) > #define MT6397_PIN_24_ROW4__FUNC_ROW4 (MTK_PIN_NO(24) | 1) > #define MT6397_PIN_24_ROW4__FUNC_EINT22_1X (MTK_PIN_NO(24) | 2) > #define MT6397_PIN_24_ROW4__FUNC_SCL2_3X (MTK_PIN_NO(24) | 3) > #define MT6397_PIN_24_ROW4__FUNC_TEST_IN15 (MTK_PIN_NO(24) | 6) > #define MT6397_PIN_24_ROW4__FUNC_TEST_OUT15 (MTK_PIN_NO(24) | 7) > > include/dt-bindings/pinctrl/mt6797-pinfunc.h: > #define MT6797_GPIO34__FUNC_GPIO34 (MTK_PIN_NO(34) | 0) > #define MT6797_GPIO34__FUNC_CMFLASH (MTK_PIN_NO(34) | 1) > #define MT6797_GPIO34__FUNC_CLKM0 (MTK_PIN_NO(34) | 2) > #define MT6797_GPIO34__FUNC_UDI_NTRST (MTK_PIN_NO(34) | 3) > #define MT6797_GPIO34__FUNC_SCP_JTAG_TRSTN (MTK_PIN_NO(34) | 4) > #define MT6797_GPIO34__FUNC_CONN_MCU_TRST_B (MTK_PIN_NO(34) | 5) > #define MT6797_GPIO34__FUNC_MD_UTXD0 (MTK_PIN_NO(34) | 6) > #define MT6797_GPIO34__FUNC_C2K_DM_JTINTP (MTK_PIN_NO(34) | 7) > > So, is it a pin or a GPIO and why does 6797 use different naming > scheme? They all stand for the pin and list all the functions which the pin can be switched to. MT6797 is the first mtk pinctrl driver not contributed by mediatek people, we will try to fix these confusing things and should be careful keeping the naming be uniform in the future. > Why do some of them have __FUNC and some _FUNC?Why do some > have the non-gpio function as part of the name and some do not? > ditto, we will try to fix and keep the naming be uniform > Also, "pin 24 row 4 func row4"? Seems to have very limited value to > describe it in that manner, it's just overly verbose without adding > information. All the function names for a pin totally are same (copied) with hardware document describes. That means it's default function of the pin the hardware provides. > > Some other SoCs tend to use a pinctrl specifier that is two-cell function> instead of trying to pack them into one integer. I'm not the initial developer for the vendor binding. but I guessed the initial thought trying to pack them into one integer can decrease the risk of inconsistency between pin and function,
Re: [PATCH v2 2/4] dmaengine: mtk_uart_dma: add Mediatek uart DMA support
On Thu, Dec 6, 2018 at 1:55 AM Long Cheng wrote:
>
> On Wed, 2018-12-05 at 13:07 -0800, Sean Wang wrote:
> > .
> > On Wed, Dec 5, 2018 at 1:31 AM Long Cheng wrote:
> > >
> > > In DMA engine framework, add 8250 mtk dma to support it.
> > >
> > > Signed-off-by: Long Cheng
> > > ---
> > > 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 000..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
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#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_BBIT(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_BBIT(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_B0
> > > +#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 0xU
> > > +/* invert this bit when wrap ring head again*/
> > > +#define MTK_DMA_RING_WRAP 0x1U
> > > +
> > > +#define VFF_INT_FLAG 0x00
> > > +#define VFF_INT_EN 0x04
> > > +#define VFF_EN 0x08
> > > +#define VFF_RST0x0c
> > > +#define VFF_STOP 0x10
> > > +#define VFF_FLUSH 0x14
> > > +#define VFF_ADDR 0x1c
> > > +#define VFF_LEN0x24
> > > +#define VFF_THRE 0x28
> > > +#define VFF_WPT0x2c
> > > +#define VFF_RPT0x30
> > > +/*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;
> > > +
Re: [PATCH v2 2/4] dmaengine: mtk_uart_dma: add Mediatek uart DMA support
On Thu, Dec 6, 2018 at 1:55 AM Long Cheng wrote:
>
> On Wed, 2018-12-05 at 13:07 -0800, Sean Wang wrote:
> > .
> > On Wed, Dec 5, 2018 at 1:31 AM Long Cheng wrote:
> > >
> > > In DMA engine framework, add 8250 mtk dma to support it.
> > >
> > > Signed-off-by: Long Cheng
> > > ---
> > > 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 000..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
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#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_BBIT(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_BBIT(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_B0
> > > +#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 0xU
> > > +/* invert this bit when wrap ring head again*/
> > > +#define MTK_DMA_RING_WRAP 0x1U
> > > +
> > > +#define VFF_INT_FLAG 0x00
> > > +#define VFF_INT_EN 0x04
> > > +#define VFF_EN 0x08
> > > +#define VFF_RST0x0c
> > > +#define VFF_STOP 0x10
> > > +#define VFF_FLUSH 0x14
> > > +#define VFF_ADDR 0x1c
> > > +#define VFF_LEN0x24
> > > +#define VFF_THRE 0x28
> > > +#define VFF_WPT0x2c
> > > +#define VFF_RPT0x30
> > > +/*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;
> > > +
Re: [PATCH v2 2/4] dmaengine: mtk_uart_dma: add Mediatek uart DMA support
.
On Wed, Dec 5, 2018 at 1:31 AM Long Cheng wrote:
>
> In DMA engine framework, add 8250 mtk dma to support it.
>
> Signed-off-by: Long Cheng
> ---
> 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 000..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
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#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_BBIT(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_BBIT(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_B0
> +#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 0xU
> +/* invert this bit when wrap ring head again*/
> +#define MTK_DMA_RING_WRAP 0x1U
> +
> +#define VFF_INT_FLAG 0x00
> +#define VFF_INT_EN 0x04
> +#define VFF_EN 0x08
> +#define VFF_RST0x0c
> +#define VFF_STOP 0x10
> +#define VFF_FLUSH 0x14
> +#define VFF_ADDR 0x1c
> +#define VFF_LEN0x24
> +#define VFF_THRE 0x28
> +#define VFF_WPT0x2c
> +#define VFF_RPT0x30
> +/*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
> + unsigned int dma_ch;
a chan_id is already included in struct dma_chan, we can reuse it
> + unsigned int sgidx;
the member also can be removed as no real user would refer to it
> + 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.
> + 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
Re: [PATCH v2 2/4] dmaengine: mtk_uart_dma: add Mediatek uart DMA support
.
On Wed, Dec 5, 2018 at 1:31 AM Long Cheng wrote:
>
> In DMA engine framework, add 8250 mtk dma to support it.
>
> Signed-off-by: Long Cheng
> ---
> 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 000..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
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#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_BBIT(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_BBIT(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_B0
> +#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 0xU
> +/* invert this bit when wrap ring head again*/
> +#define MTK_DMA_RING_WRAP 0x1U
> +
> +#define VFF_INT_FLAG 0x00
> +#define VFF_INT_EN 0x04
> +#define VFF_EN 0x08
> +#define VFF_RST0x0c
> +#define VFF_STOP 0x10
> +#define VFF_FLUSH 0x14
> +#define VFF_ADDR 0x1c
> +#define VFF_LEN0x24
> +#define VFF_THRE 0x28
> +#define VFF_WPT0x2c
> +#define VFF_RPT0x30
> +/*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
> + unsigned int dma_ch;
a chan_id is already included in struct dma_chan, we can reuse it
> + unsigned int sgidx;
the member also can be removed as no real user would refer to it
> + 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.
> + 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
Re: [PATCH 4/5] dt-bindings: i2c: Add Mediatek MT8183 i2c binding
On Mon, Dec 3, 2018 at 5:34 AM wrote: > > From: qii wang > > Add MT8183 i2c binding to binding file. Compare to 2712 i2c > controller, MT8183 has different registers, offsets, clock, > and multi-user function. > > Signed-off-by: qii wang > --- > Documentation/devicetree/bindings/i2c/i2c-mtk.txt |7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt > b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt > index 7729e57..dfde624 100644 > --- a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt > +++ b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt > @@ -12,14 +12,15 @@ Required properties: >"mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for MediaTek MT7623 >"mediatek,mt7629-i2c", "mediatek,mt2712-i2c": for MediaTek mt7629 >"mediatek,mt8173-i2c": for MediaTek MT8173 > + "mediatek,mt8183-i2c": for MediaTek MT8183 >- reg: physical base address of the controller and dma base, length of > memory > mapped region. >- interrupts: interrupt number to the cpu. >- clock-div: the fixed value for frequency divider of clock source in i2c > module. Each IC may be different. >- clocks: clock name from clock manager > - - clock-names: Must include "main" and "dma", if enable have-pmic need > include > -"pmic" extra. > + - clock-names: Must include "main" and "dma", "arb" is optional, if enable if arb is optional, the multi-user function still can work? arb seems like the clock fed to arbitrating bus when multiple users are accessing at the same time. > +have-pmic need include "pmic" extra. > > Optional properties: >- clock-frequency: Frequency in Hz of the bus when transfer, the default > value > @@ -27,6 +28,8 @@ Optional properties: >- mediatek,have-pmic: platform can control i2c form special pmic side. > Only mt6589 and mt8135 support this feature. >- mediatek,use-push-pull: IO config use push-pull mode. > + - ch-offset: base reg offset for multi-user. add a vendor prefix if the property is vendor-specific one. > + - mediatek,share-i3c: i3c controller can share i2c function. > > Example: > > -- > 1.7.9.5 > > > ___ > Linux-mediatek mailing list > linux-media...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH 4/5] dt-bindings: i2c: Add Mediatek MT8183 i2c binding
On Mon, Dec 3, 2018 at 5:34 AM wrote: > > From: qii wang > > Add MT8183 i2c binding to binding file. Compare to 2712 i2c > controller, MT8183 has different registers, offsets, clock, > and multi-user function. > > Signed-off-by: qii wang > --- > Documentation/devicetree/bindings/i2c/i2c-mtk.txt |7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt > b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt > index 7729e57..dfde624 100644 > --- a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt > +++ b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt > @@ -12,14 +12,15 @@ Required properties: >"mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for MediaTek MT7623 >"mediatek,mt7629-i2c", "mediatek,mt2712-i2c": for MediaTek mt7629 >"mediatek,mt8173-i2c": for MediaTek MT8173 > + "mediatek,mt8183-i2c": for MediaTek MT8183 >- reg: physical base address of the controller and dma base, length of > memory > mapped region. >- interrupts: interrupt number to the cpu. >- clock-div: the fixed value for frequency divider of clock source in i2c > module. Each IC may be different. >- clocks: clock name from clock manager > - - clock-names: Must include "main" and "dma", if enable have-pmic need > include > -"pmic" extra. > + - clock-names: Must include "main" and "dma", "arb" is optional, if enable if arb is optional, the multi-user function still can work? arb seems like the clock fed to arbitrating bus when multiple users are accessing at the same time. > +have-pmic need include "pmic" extra. > > Optional properties: >- clock-frequency: Frequency in Hz of the bus when transfer, the default > value > @@ -27,6 +28,8 @@ Optional properties: >- mediatek,have-pmic: platform can control i2c form special pmic side. > Only mt6589 and mt8135 support this feature. >- mediatek,use-push-pull: IO config use push-pull mode. > + - ch-offset: base reg offset for multi-user. add a vendor prefix if the property is vendor-specific one. > + - mediatek,share-i3c: i3c controller can share i2c function. > > Example: > > -- > 1.7.9.5 > > > ___ > Linux-mediatek mailing list > linux-media...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH 3/5] i2c: mediatek: Add offsets array for new i2c registers
於 2018年12月3日 週一 上午5:35寫道：
>
> From: qii wang
>
> New i2c registers would have different offsets, so we use different
> offsets array to distinguish different i2c registers version.
>
> Signed-off-by: qii wang
They are almost 1 to 1 function translation being taken here, so
Reviewed-by: Sean Wang
> ---
> drivers/i2c/busses/i2c-mt65xx.c | 163
> +--
> 1 file changed, 104 insertions(+), 59 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
> index 660de1e..428ac99 100644
> --- a/drivers/i2c/busses/i2c-mt65xx.c
> +++ b/drivers/i2c/busses/i2c-mt65xx.c
> @@ -106,34 +106,62 @@ enum mtk_trans_op {
> };
>
> enum I2C_REGS_OFFSET {
> - OFFSET_DATA_PORT = 0x0,
> - OFFSET_SLAVE_ADDR = 0x04,
> - OFFSET_INTR_MASK = 0x08,
> - OFFSET_INTR_STAT = 0x0c,
> - OFFSET_CONTROL = 0x10,
> - OFFSET_TRANSFER_LEN = 0x14,
> - OFFSET_TRANSAC_LEN = 0x18,
> - OFFSET_DELAY_LEN = 0x1c,
> - OFFSET_TIMING = 0x20,
> - OFFSET_START = 0x24,
> - OFFSET_EXT_CONF = 0x28,
> - OFFSET_FIFO_STAT = 0x30,
> - OFFSET_FIFO_THRESH = 0x34,
> - OFFSET_FIFO_ADDR_CLR = 0x38,
> - OFFSET_IO_CONFIG = 0x40,
> - OFFSET_RSV_DEBUG = 0x44,
> - OFFSET_HS = 0x48,
> - OFFSET_SOFTRESET = 0x50,
> - OFFSET_DCM_EN = 0x54,
> - OFFSET_PATH_DIR = 0x60,
> - OFFSET_DEBUGSTAT = 0x64,
> - OFFSET_DEBUGCTRL = 0x68,
> - OFFSET_TRANSFER_LEN_AUX = 0x6c,
> - OFFSET_CLOCK_DIV = 0x70,
> + OFFSET_DATA_PORT,
> + OFFSET_SLAVE_ADDR,
> + OFFSET_INTR_MASK,
> + OFFSET_INTR_STAT,
> + OFFSET_CONTROL,
> + OFFSET_TRANSFER_LEN,
> + OFFSET_TRANSAC_LEN,
> + OFFSET_DELAY_LEN,
> + OFFSET_TIMING,
> + OFFSET_START,
> + OFFSET_EXT_CONF,
> + OFFSET_FIFO_STAT,
> + OFFSET_FIFO_THRESH,
> + OFFSET_FIFO_ADDR_CLR,
> + OFFSET_IO_CONFIG,
> + OFFSET_RSV_DEBUG,
> + OFFSET_HS,
> + OFFSET_SOFTRESET,
> + OFFSET_DCM_EN,
> + OFFSET_PATH_DIR,
> + OFFSET_DEBUGSTAT,
> + OFFSET_DEBUGCTRL,
> + OFFSET_TRANSFER_LEN_AUX,
> + OFFSET_CLOCK_DIV,
> +};
> +
> +static const u16 mt_i2c_regs_v1[] = {
> + [OFFSET_DATA_PORT] = 0x0,
> + [OFFSET_SLAVE_ADDR] = 0x4,
> + [OFFSET_INTR_MASK] = 0x8,
> + [OFFSET_INTR_STAT] = 0xc,
> + [OFFSET_CONTROL] = 0x10,
> + [OFFSET_TRANSFER_LEN] = 0x14,
> + [OFFSET_TRANSAC_LEN] = 0x18,
> + [OFFSET_DELAY_LEN] = 0x1c,
> + [OFFSET_TIMING] = 0x20,
> + [OFFSET_START] = 0x24,
> + [OFFSET_EXT_CONF] = 0x28,
> + [OFFSET_FIFO_STAT] = 0x30,
> + [OFFSET_FIFO_THRESH] = 0x34,
> + [OFFSET_FIFO_ADDR_CLR] = 0x38,
> + [OFFSET_IO_CONFIG] = 0x40,
> + [OFFSET_RSV_DEBUG] = 0x44,
> + [OFFSET_HS] = 0x48,
> + [OFFSET_SOFTRESET] = 0x50,
> + [OFFSET_DCM_EN] = 0x54,
> + [OFFSET_PATH_DIR] = 0x60,
> + [OFFSET_DEBUGSTAT] = 0x64,
> + [OFFSET_DEBUGCTRL] = 0x68,
> + [OFFSET_TRANSFER_LEN_AUX] = 0x6c,
> + [OFFSET_CLOCK_DIV] = 0x70,
> };
>
> struct mtk_i2c_compatible {
> const struct i2c_adapter_quirks *quirks;
> + const u16 *regs;
> unsigned char pmic_i2c: 1;
> unsigned char dcm: 1;
> unsigned char auto_restart: 1;
> @@ -181,6 +209,7 @@ struct mtk_i2c {
> };
>
> static const struct mtk_i2c_compatible mt2712_compat = {
> + .regs = mt_i2c_regs_v1,
> .pmic_i2c = 0,
> .dcm = 1,
> .auto_restart = 1,
> @@ -191,6 +220,7 @@ struct mtk_i2c {
>
> static const struct mtk_i2c_compatible mt6577_compat = {
> .quirks = _i2c_quirks,
> + .regs = mt_i2c_regs_v1,
> .pmic_i2c = 0,
> .dcm = 1,
> .auto_restart = 0,
> @@ -201,6 +231,7 @@ struct mtk_i2c {
>
> static const struct mtk_i2c_compatible mt6589_compat = {
> .quirks = _i2c_quirks,
> + .regs = mt_i2c_regs_v1,
> .pmic_i2c = 1,
> .dcm = 0,
> .auto_restart = 0,
> @@ -211,6 +242,7 @@ struct mtk_i2c {
>
> static const struct mtk_i2c_compatible mt7622_compat = {
> .quirks = _i2c_quirks,
> + .regs = mt_i2c_regs_v1,
> .pmic_i2c = 0,
> .dcm = 1,
> .auto_restart = 1,
> @@ -220,6 +252,7 @@ struct mtk_i2c {
> };
>
> static const struct mtk_i2c_compatible mt8173_compat = {
> + .regs = mt_i2c_regs_v1,
> .pmic_i2c = 0,
> .dcm = 1,
> .auto_restart = 1,
> @@ -238,6 +271
Re: [PATCH 3/5] i2c: mediatek: Add offsets array for new i2c registers
於 2018年12月3日 週一 上午5:35寫道：
>
> From: qii wang
>
> New i2c registers would have different offsets, so we use different
> offsets array to distinguish different i2c registers version.
>
> Signed-off-by: qii wang
They are almost 1 to 1 function translation being taken here, so
Reviewed-by: Sean Wang
> ---
> drivers/i2c/busses/i2c-mt65xx.c | 163
> +--
> 1 file changed, 104 insertions(+), 59 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
> index 660de1e..428ac99 100644
> --- a/drivers/i2c/busses/i2c-mt65xx.c
> +++ b/drivers/i2c/busses/i2c-mt65xx.c
> @@ -106,34 +106,62 @@ enum mtk_trans_op {
> };
>
> enum I2C_REGS_OFFSET {
> - OFFSET_DATA_PORT = 0x0,
> - OFFSET_SLAVE_ADDR = 0x04,
> - OFFSET_INTR_MASK = 0x08,
> - OFFSET_INTR_STAT = 0x0c,
> - OFFSET_CONTROL = 0x10,
> - OFFSET_TRANSFER_LEN = 0x14,
> - OFFSET_TRANSAC_LEN = 0x18,
> - OFFSET_DELAY_LEN = 0x1c,
> - OFFSET_TIMING = 0x20,
> - OFFSET_START = 0x24,
> - OFFSET_EXT_CONF = 0x28,
> - OFFSET_FIFO_STAT = 0x30,
> - OFFSET_FIFO_THRESH = 0x34,
> - OFFSET_FIFO_ADDR_CLR = 0x38,
> - OFFSET_IO_CONFIG = 0x40,
> - OFFSET_RSV_DEBUG = 0x44,
> - OFFSET_HS = 0x48,
> - OFFSET_SOFTRESET = 0x50,
> - OFFSET_DCM_EN = 0x54,
> - OFFSET_PATH_DIR = 0x60,
> - OFFSET_DEBUGSTAT = 0x64,
> - OFFSET_DEBUGCTRL = 0x68,
> - OFFSET_TRANSFER_LEN_AUX = 0x6c,
> - OFFSET_CLOCK_DIV = 0x70,
> + OFFSET_DATA_PORT,
> + OFFSET_SLAVE_ADDR,
> + OFFSET_INTR_MASK,
> + OFFSET_INTR_STAT,
> + OFFSET_CONTROL,
> + OFFSET_TRANSFER_LEN,
> + OFFSET_TRANSAC_LEN,
> + OFFSET_DELAY_LEN,
> + OFFSET_TIMING,
> + OFFSET_START,
> + OFFSET_EXT_CONF,
> + OFFSET_FIFO_STAT,
> + OFFSET_FIFO_THRESH,
> + OFFSET_FIFO_ADDR_CLR,
> + OFFSET_IO_CONFIG,
> + OFFSET_RSV_DEBUG,
> + OFFSET_HS,
> + OFFSET_SOFTRESET,
> + OFFSET_DCM_EN,
> + OFFSET_PATH_DIR,
> + OFFSET_DEBUGSTAT,
> + OFFSET_DEBUGCTRL,
> + OFFSET_TRANSFER_LEN_AUX,
> + OFFSET_CLOCK_DIV,
> +};
> +
> +static const u16 mt_i2c_regs_v1[] = {
> + [OFFSET_DATA_PORT] = 0x0,
> + [OFFSET_SLAVE_ADDR] = 0x4,
> + [OFFSET_INTR_MASK] = 0x8,
> + [OFFSET_INTR_STAT] = 0xc,
> + [OFFSET_CONTROL] = 0x10,
> + [OFFSET_TRANSFER_LEN] = 0x14,
> + [OFFSET_TRANSAC_LEN] = 0x18,
> + [OFFSET_DELAY_LEN] = 0x1c,
> + [OFFSET_TIMING] = 0x20,
> + [OFFSET_START] = 0x24,
> + [OFFSET_EXT_CONF] = 0x28,
> + [OFFSET_FIFO_STAT] = 0x30,
> + [OFFSET_FIFO_THRESH] = 0x34,
> + [OFFSET_FIFO_ADDR_CLR] = 0x38,
> + [OFFSET_IO_CONFIG] = 0x40,
> + [OFFSET_RSV_DEBUG] = 0x44,
> + [OFFSET_HS] = 0x48,
> + [OFFSET_SOFTRESET] = 0x50,
> + [OFFSET_DCM_EN] = 0x54,
> + [OFFSET_PATH_DIR] = 0x60,
> + [OFFSET_DEBUGSTAT] = 0x64,
> + [OFFSET_DEBUGCTRL] = 0x68,
> + [OFFSET_TRANSFER_LEN_AUX] = 0x6c,
> + [OFFSET_CLOCK_DIV] = 0x70,
> };
>
> struct mtk_i2c_compatible {
> const struct i2c_adapter_quirks *quirks;
> + const u16 *regs;
> unsigned char pmic_i2c: 1;
> unsigned char dcm: 1;
> unsigned char auto_restart: 1;
> @@ -181,6 +209,7 @@ struct mtk_i2c {
> };
>
> static const struct mtk_i2c_compatible mt2712_compat = {
> + .regs = mt_i2c_regs_v1,
> .pmic_i2c = 0,
> .dcm = 1,
> .auto_restart = 1,
> @@ -191,6 +220,7 @@ struct mtk_i2c {
>
> static const struct mtk_i2c_compatible mt6577_compat = {
> .quirks = _i2c_quirks,
> + .regs = mt_i2c_regs_v1,
> .pmic_i2c = 0,
> .dcm = 1,
> .auto_restart = 0,
> @@ -201,6 +231,7 @@ struct mtk_i2c {
>
> static const struct mtk_i2c_compatible mt6589_compat = {
> .quirks = _i2c_quirks,
> + .regs = mt_i2c_regs_v1,
> .pmic_i2c = 1,
> .dcm = 0,
> .auto_restart = 0,
> @@ -211,6 +242,7 @@ struct mtk_i2c {
>
> static const struct mtk_i2c_compatible mt7622_compat = {
> .quirks = _i2c_quirks,
> + .regs = mt_i2c_regs_v1,
> .pmic_i2c = 0,
> .dcm = 1,
> .auto_restart = 1,
> @@ -220,6 +252,7 @@ struct mtk_i2c {
> };
>
> static const struct mtk_i2c_compatible mt8173_compat = {
> + .regs = mt_i2c_regs_v1,
> .pmic_i2c = 0,
> .dcm = 1,
> .auto_restart = 1,
> @@ -238,6 +271
Re: [PATCH 2/5] i2c: mediatek: remove useless code and replace definitions
於 2018年12月3日 週一 上午5:40寫道：
>
> From: qii wang
>
> Completion_done is useless when we don't use its return value,
> so we remove it. Different speeds have been defined by macros,
> so we use macros definitions.
>
> Signed-off-by: qii wang
Reviewed-by: Sean Wang
> ---
> drivers/i2c/busses/i2c-mt65xx.c |6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
> index a74ef76..660de1e 100644
> --- a/drivers/i2c/busses/i2c-mt65xx.c
> +++ b/drivers/i2c/busses/i2c-mt65xx.c
> @@ -456,7 +456,7 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c,
> struct i2c_msg *msgs,
>
> control_reg = readw(i2c->base + OFFSET_CONTROL) &
> ~(I2C_CONTROL_DIR_CHANGE | I2C_CONTROL_RS);
> - if ((i2c->speed_hz > 40) || (left_num >= 1))
> + if ((i2c->speed_hz > MAX_FS_MODE_SPEED) || (left_num >= 1))
> control_reg |= I2C_CONTROL_RS;
>
> if (i2c->op == I2C_MASTER_WRRD)
> @@ -465,7 +465,7 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c,
> struct i2c_msg *msgs,
> writew(control_reg, i2c->base + OFFSET_CONTROL);
>
> /* set start condition */
> - if (i2c->speed_hz <= 10)
> + if (i2c->speed_hz <= I2C_DEFAULT_SPEED)
> writew(I2C_ST_START_CON, i2c->base + OFFSET_EXT_CONF);
> else
> writew(I2C_FS_START_CON, i2c->base + OFFSET_EXT_CONF);
> @@ -642,8 +642,6 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c,
> struct i2c_msg *msgs,
> return -ETIMEDOUT;
> }
>
> - completion_done(>msg_complete);
> -
> if (i2c->irq_stat & (I2C_HS_NACKERR | I2C_ACKERR)) {
> dev_dbg(i2c->dev, "addr: %x, transfer ACK error\n",
> msgs->addr);
> mtk_i2c_init_hw(i2c);
> --
> 1.7.9.5
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH 2/5] i2c: mediatek: remove useless code and replace definitions
於 2018年12月3日 週一 上午5:40寫道：
>
> From: qii wang
>
> Completion_done is useless when we don't use its return value,
> so we remove it. Different speeds have been defined by macros,
> so we use macros definitions.
>
> Signed-off-by: qii wang
Reviewed-by: Sean Wang
> ---
> drivers/i2c/busses/i2c-mt65xx.c |6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
> index a74ef76..660de1e 100644
> --- a/drivers/i2c/busses/i2c-mt65xx.c
> +++ b/drivers/i2c/busses/i2c-mt65xx.c
> @@ -456,7 +456,7 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c,
> struct i2c_msg *msgs,
>
> control_reg = readw(i2c->base + OFFSET_CONTROL) &
> ~(I2C_CONTROL_DIR_CHANGE | I2C_CONTROL_RS);
> - if ((i2c->speed_hz > 40) || (left_num >= 1))
> + if ((i2c->speed_hz > MAX_FS_MODE_SPEED) || (left_num >= 1))
> control_reg |= I2C_CONTROL_RS;
>
> if (i2c->op == I2C_MASTER_WRRD)
> @@ -465,7 +465,7 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c,
> struct i2c_msg *msgs,
> writew(control_reg, i2c->base + OFFSET_CONTROL);
>
> /* set start condition */
> - if (i2c->speed_hz <= 10)
> + if (i2c->speed_hz <= I2C_DEFAULT_SPEED)
> writew(I2C_ST_START_CON, i2c->base + OFFSET_EXT_CONF);
> else
> writew(I2C_FS_START_CON, i2c->base + OFFSET_EXT_CONF);
> @@ -642,8 +642,6 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c,
> struct i2c_msg *msgs,
> return -ETIMEDOUT;
> }
>
> - completion_done(>msg_complete);
> -
> if (i2c->irq_stat & (I2C_HS_NACKERR | I2C_ACKERR)) {
> dev_dbg(i2c->dev, "addr: %x, transfer ACK error\n",
> msgs->addr);
> mtk_i2c_init_hw(i2c);
> --
> 1.7.9.5
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH 1/5] dt-bindings: i2c: Add Mediatek MT7629 i2c binding
於 2018年12月3日 週一 上午5:34寫道： > > From: qii wang > > Add MT7629 i2c binding to i2c-mt2712.txt and there is no need to where's i2c-mt2712.txt mentioned here? > modify i2c driver. suggest not to mention driver in any dt-binding, dt-binding self should be os-agnostic > > Signed-off-by: qii wang > --- > Documentation/devicetree/bindings/i2c/i2c-mtk.txt |1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt > b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt > index e199695..7729e57 100644 > --- a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt > +++ b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt > @@ -10,6 +10,7 @@ Required properties: >"mediatek,mt6589-i2c": for MediaTek MT6589 >"mediatek,mt7622-i2c": for MediaTek MT7622 >"mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for MediaTek MT7623 > + "mediatek,mt7629-i2c", "mediatek,mt2712-i2c": for MediaTek mt7629 change mt7629 to MT7629 to align to the others >"mediatek,mt8173-i2c": for MediaTek MT8173 >- reg: physical base address of the controller and dma base, length of > memory > mapped region. > -- > 1.7.9.5 > > > ___ > Linux-mediatek mailing list > linux-media...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH 1/5] dt-bindings: i2c: Add Mediatek MT7629 i2c binding
於 2018年12月3日 週一 上午5:34寫道： > > From: qii wang > > Add MT7629 i2c binding to i2c-mt2712.txt and there is no need to where's i2c-mt2712.txt mentioned here? > modify i2c driver. suggest not to mention driver in any dt-binding, dt-binding self should be os-agnostic > > Signed-off-by: qii wang > --- > Documentation/devicetree/bindings/i2c/i2c-mtk.txt |1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt > b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt > index e199695..7729e57 100644 > --- a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt > +++ b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt > @@ -10,6 +10,7 @@ Required properties: >"mediatek,mt6589-i2c": for MediaTek MT6589 >"mediatek,mt7622-i2c": for MediaTek MT7622 >"mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for MediaTek MT7623 > + "mediatek,mt7629-i2c", "mediatek,mt2712-i2c": for MediaTek mt7629 change mt7629 to MT7629 to align to the others >"mediatek,mt8173-i2c": for MediaTek MT8173 >- reg: physical base address of the controller and dma base, length of > memory > mapped region. > -- > 1.7.9.5 > > > ___ > Linux-mediatek mailing list > linux-media...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek
