RE: [PATCH V2 0/6] PM / devfreq: a few small fixes and improvements
> From: Chanwoo Choi > Sent: Tuesday, March 23, 2021 12:11 PM > > Hi, > > On 3/23/21 12:25 PM, Dong Aisheng wrote: > > Hi Chanwoo, > > > > On Tue, Mar 23, 2021 at 11:13 AM Dong Aisheng > wrote: > >> > >> A few small fixes and improvements > >> > >> ChangeLog: > >> v1->v2: > >> * squash a few patches > >> * rebase to devfreq-testing > > > > I have to rebase to devfreq-testing instead of devfreq-next because > > below two patches only exist in devfreq-testing. > > 5cc75e9252e9 (devfreq/devfreq-testing) PM / devfreq: Add > > devfreq_transitions debugfs file > > dc9e557845c1 PM / devfreq: Add new up_threshold and down_differential > > sysfs attrs My patch 5 needs change based on it according to your > > suggestion. So i have to rebase to that branch. > > > > However, i found devfreq-testing can't build with GOV_PASSVIE enabled. > > Patch 1 fixed it. You can squash to the original one when apply. > > > > Please help take a look at this new series. > > Please rebase your patches either devfreq-next or linux-next.git Because > devfreq-testing branch is not official. Okay, then how about the patch 5 below? [PATCH V2 5/6] PM / devfreq: governor: optimize simpleondemand get_target_freq Should I also rebase it to devfreq-next or drop it first and then resend when your patch merged into mainline? https://patchwork.kernel.org/project/linux-arm-kernel/patch/1615294733-22761-10-git-send-email-aisheng.d...@nxp.com/ Regards Aisheng > > > Thanks > > > > Regards > > Aisheng > > > >> * drop two patches which are already in devfreq-next > >> > >> Dong Aisheng (6): > >> PM / devfreq: fix build error when DEVFREQ_GOV_PASSIVE enabled > >> PM / devfreq: Use more accurate returned new_freq as resume_freq > >> PM / devfreq: Remove the invalid description for get_target_freq > >> PM / devfreq: bail out early if no freq changes in devfreq_set_target > >> PM / devfreq: governor: optimize simpleondemand get_target_freq > >> PM / devfreq: imx8m-ddrc: remove imx8m_ddrc_get_dev_status > >> > >> Documentation/ABI/testing/sysfs-class-devfreq | 5 +-- > >> drivers/devfreq/devfreq.c | 37 +++ > >> drivers/devfreq/governor.h| 2 - > >> drivers/devfreq/governor_simpleondemand.c | 31 ++-- > >> drivers/devfreq/imx8m-ddrc.c | 14 --- > >> 5 files changed, 35 insertions(+), 54 deletions(-) > >> > >> -- > >> 2.25.1 > >> > > > > > > > -- > Best Regards, > Chanwoo Choi > Samsung Electronics
RE: [PATCH 02/11] i2c: imx-lpi2c: add runtime pm support
[...]
> > > > pm_runtime_set_autosuspend_delay(>dev,
> > > I2C_PM_TIMEOUT);
> > > > pm_runtime_use_autosuspend(>dev);
> > > > - pm_runtime_get_noresume(>dev);
> > > > - pm_runtime_set_active(>dev);
> > > > pm_runtime_enable(>dev);
> > > >
> > > > + ret = pm_runtime_get_sync(>dev);
> > > > + if (ret < 0) {
> > > > + pm_runtime_put_noidle(>dev);
> > > > + dev_err(>dev, "failed to enable clock\n");
> > > > + return ret;
> > > > + }
> > >
> > > Can't current clk control via rpm work well?
> > > Please describe why need change.
> >
> > I think the previous patch maker might want to use the return value of
> > pm_runtime_get_sync to check whether the clock has been turned on
> > correctly to
> > avoid the kernel panic.
> > Maybe I can change to the method like this.
> > pm_runtime_get_noresume(>dev);
> > ret = pm_runtime_set_active(>dev);
> > if (ret < 0)
> > goto out;
> > pm_runtime_enable(>dev);
> >
> > Best Regards,
> > Clark Wang
>
> Sorry, I missed the point before.
> If we use pm_runtime_get_noresume(>dev); and
> pm_runtime_set_active(>dev); here, the clk should be enabled by using
> clk_prepare_enable() in the probe function. However, the call of
> clk_prepare_enable() is already in lpi2c_runtime_resume().
> Using get_sync() here can help to reduce the repetitive code, especially ipg
> clk will be added later.
Let's not do for this negligible improvement unless there're any other good
benefits.
If really care, move clk operation into an inline function instead.
Another benefit if not doing that is the driver still can work even RPM not
enabled.
Regards
Aisheng
> Shall we change to use pm_runtime_get_sync() here?
>
> Regards,
> Clark Wang
>
RE: [PATCH 04/11] i2c: imx-lpi2c: manage irq resource request/release in runtime pm
> > > @@ -665,6 +659,14 @@ static int __maybe_unused
> > > lpi2c_runtime_resume(struct device *dev)
> > > dev_err(dev, "can't enable I2C ipg clock, ret=%d\n", ret);
> > > }
> > >
> > > + ret = devm_request_irq(dev, lpi2c_imx->irq, lpi2c_imx_isr,
> >
> > I guess unnecessary to use devm in rpm
>
> devm_request_irq() will use device resource management.
> Other resource like clk and struct space are all managed by devres.
> Maybe we can still use devm_ to let devres manage irq here?
>
devm_xxx is usually used to auto free resources when probe fail,
driver unbound / device unregister and etc. Not for runtime pm.
I may prefer using request_irq/free_irq directly in runtime.
BTW, current lpi2c_imx_remove seems didn't ensure the device is
In runtime suspend state after removing.
If framework can't guarantee, the driver has to do it.
Anyway, that's another issue and need a separate patch.
Regards
Aisheng
> Thanks.
>
> Best Regards,
> Clark Wang
>
>
> >
> > > +IRQF_NO_SUSPEND,
> > > +dev_name(dev), lpi2c_imx);
> > > + if (ret) {
> > > + dev_err(dev, "can't claim irq %d\n", lpi2c_imx->irq);
> > > + return ret;
> > > + }
> > > +
> > > return ret;
> > > }
> > >
> > > --
> > > 2.25.1
RE: [PATCH 03/11] i2c: imx-lpi2c: add ipg clk for lpi2c driver
> > > +
> > > + lpi2c_imx->clk_ipg = devm_clk_get(>dev, "ipg");
> > > + if (IS_ERR(lpi2c_imx->clk_ipg)) {
> > > + dev_err(>dev, "can't get I2C ipg clock\n");
> > > + return PTR_ERR(lpi2c_imx->clk_ipg);
> > > }
> >
> > Will this break exist dts?
>
> It will not break the build. But will break the lpi2c probe for imx7ulp and
> imx8qxp/qm.
> I will send two patches to update dts in V2.
>
Please don't break exist platforms.
Regards
Aisheng
> Best Regards,
> Clark Wang
>
> >
> > Regards
> > Aisheng
> >
> > >
> > > ret = of_property_read_u32(pdev->dev.of_node,
> > > @@ -633,7 +640,8 @@ static int __maybe_unused
> > > lpi2c_runtime_suspend(struct device *dev) {
> > > struct lpi2c_imx_struct *lpi2c_imx = dev_get_drvdata(dev);
> > >
> > > - clk_disable_unprepare(lpi2c_imx->clk);
> > > + clk_disable_unprepare(lpi2c_imx->clk_ipg);
> > > + clk_disable_unprepare(lpi2c_imx->clk_per);
> > > pinctrl_pm_select_idle_state(dev);
> > >
> > > return 0;
> > > @@ -645,12 +653,18 @@ static int __maybe_unused
> > > lpi2c_runtime_resume(struct device *dev)
> > > int ret;
> > >
> > > pinctrl_pm_select_default_state(dev);
> > > - ret = clk_prepare_enable(lpi2c_imx->clk);
> > > + ret = clk_prepare_enable(lpi2c_imx->clk_per);
> > > if (ret) {
> > > - dev_err(dev, "can't enable I2C clock, ret=%d\n", ret);
> > > + dev_err(dev, "can't enable I2C per clock, ret=%d\n", ret);
> > > return ret;
> > > }
> > >
> > > + ret = clk_prepare_enable(lpi2c_imx->clk_ipg);
> > > + if (ret) {
> > > + clk_disable_unprepare(lpi2c_imx->clk_per);
> > > + dev_err(dev, "can't enable I2C ipg clock, ret=%d\n", ret);
> > > + }
> > > +
> > > return ret;
> > > }
> > >
> > > --
> > > 2.25.1
RE: [PATCH 11/11] i2c: imx-lpi2c: add edma mode support
> From: Clark Wang
> Sent: Wednesday, March 17, 2021 2:54 PM
>
> Add eDMA receive and send mode support.
> Support to read and write data larger than 256 bytes in one frame.
>
> Signed-off-by: Clark Wang
> Reviewed-by: Li Jun
> ---
> drivers/i2c/busses/i2c-imx-lpi2c.c | 291 -
Pease update dt-binding first
> 1 file changed, 289 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c
> b/drivers/i2c/busses/i2c-imx-lpi2c.c
> index 1e26672d47bf..6d920bf0dbd4 100644
> --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> @@ -8,6 +8,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
> #include
> @@ -31,6 +33,7 @@
> #define LPI2C_MCR0x10/* i2c contrl register */
> #define LPI2C_MSR0x14/* i2c status register */
> #define LPI2C_MIER 0x18/* i2c interrupt enable */
> +#define LPI2C_MDER 0x1C/* i2c DMA enable */
> #define LPI2C_MCFGR0 0x20/* i2c master configuration */
> #define LPI2C_MCFGR1 0x24/* i2c master configuration */
> #define LPI2C_MCFGR2 0x28/* i2c master configuration */
> @@ -72,11 +75,15 @@
> #define MCFGR1_AUTOSTOP BIT(8)
> #define MCFGR1_IGNACKBIT(9)
> #define MRDR_RXEMPTY BIT(14)
> +#define MDER_TDDEBIT(0)
> +#define MDER_RDDEBIT(1)
>
> #define I2C_CLK_RATIO24 / 59
> #define CHUNK_DATA 256
>
> #define I2C_PM_TIMEOUT 1000 /* ms */
> +#define I2C_DMA_THRESHOLD16 /* bytes */
> +#define I2C_USE_PIO (-150)
Can you clarify a bit why need using this strange value?
>
> enum lpi2c_imx_mode {
> STANDARD, /* <=100Kbps */
> @@ -95,6 +102,7 @@ enum lpi2c_imx_pincfg {
>
> struct lpi2c_imx_struct {
> struct i2c_adapter adapter;
> + resource_size_t phy_addr;
> int irq;
> struct clk *clk_per;
> struct clk *clk_ipg;
> @@ -114,6 +122,17 @@ struct lpi2c_imx_struct {
> struct pinctrl *pinctrl;
> struct pinctrl_state *pinctrl_pins_default;
> struct pinctrl_state *pinctrl_pins_gpio;
> +
> + boolcan_use_dma;
> + boolusing_dma;
> + boolxferred;
> + struct i2c_msg *msg;
> + dma_addr_t dma_addr;
> + struct dma_chan *dma_tx;
> + struct dma_chan *dma_rx;
> + enum dma_data_direction dma_direction;
> + u8 *dma_buf;
> + unsigned intdma_len;
> };
>
> static void lpi2c_imx_intctrl(struct lpi2c_imx_struct *lpi2c_imx, @@ -289,6
> +308,9 @@ static int lpi2c_imx_master_enable(struct lpi2c_imx_struct
> *lpi2c_imx)
> if (ret)
> goto rpm_put;
>
> + if (lpi2c_imx->can_use_dma)
> + writel(MDER_TDDE | MDER_RDDE, lpi2c_imx->base + LPI2C_MDER);
> +
> temp = readl(lpi2c_imx->base + LPI2C_MCR);
> temp |= MCR_MEN;
> writel(temp, lpi2c_imx->base + LPI2C_MCR); @@ -462,6 +484,154 @@
> static void lpi2c_imx_read(struct lpi2c_imx_struct *lpi2c_imx,
> lpi2c_imx_intctrl(lpi2c_imx, MIER_RDIE | MIER_NDIE); }
>
> +static void lpi2c_dma_unmap(struct lpi2c_imx_struct *lpi2c_imx) {
> + struct dma_chan *chan = lpi2c_imx->dma_direction ==
> DMA_FROM_DEVICE
> + ? lpi2c_imx->dma_rx : lpi2c_imx->dma_tx;
> +
> + dma_unmap_single(chan->device->dev, lpi2c_imx->dma_addr,
> + lpi2c_imx->dma_len, lpi2c_imx->dma_direction);
> +
> + lpi2c_imx->dma_direction = DMA_NONE;
> +}
> +
> +static void lpi2c_cleanup_dma(struct lpi2c_imx_struct *lpi2c_imx) {
> + if (lpi2c_imx->dma_direction == DMA_NONE)
> + return;
> + else if (lpi2c_imx->dma_direction == DMA_FROM_DEVICE)
> + dmaengine_terminate_all(lpi2c_imx->dma_rx);
> + else if (lpi2c_imx->dma_direction == DMA_TO_DEVICE)
> + dmaengine_terminate_all(lpi2c_imx->dma_tx);
> +
> + lpi2c_dma_unmap(lpi2c_imx);
> +}
> +
> +static void lpi2c_dma_callback(void *data) {
> + struct lpi2c_imx_struct *lpi2c_imx = (struct lpi2c_imx_struct *)data;
> +
> + lpi2c_dma_unmap(lpi2c_imx);
> + writel(GEN_STOP << 8, lpi2c_imx->base + LPI2C_MTDR);
> + lpi2c_imx->xferred = true;
> +
> + complete(_imx->complete);
> +}
> +
> +static int lpi2c_dma_submit(struct lpi2c_imx_struct *lpi2c_imx,
> +struct i2c_msg *msg)
> +{
> + bool read = msg->flags & I2C_M_RD;
> + enum dma_data_direction dir = read ? DMA_FROM_DEVICE :
> DMA_TO_DEVICE;
> + struct dma_chan *chan = read ? lpi2c_imx->dma_rx : lpi2c_imx->dma_tx;
> + struct dma_async_tx_descriptor *txdesc;
> + dma_cookie_t cookie;
> +
> + lpi2c_imx->dma_len = read ? msg->len - 1 : msg->len;
> + lpi2c_imx->msg = msg;
> + lpi2c_imx->dma_direction = dir;
> +
> + if (IS_ERR(chan))
> + return PTR_ERR(chan);
> +
> +
RE: [PATCH 10/11] i2c: imx-lpi2c: fix type char overflow issue when calculating the clock cycle
> From: Clark Wang
> Sent: Wednesday, March 17, 2021 2:54 PM
>
> Claim clkhi and clklo as integer type to avoid possible calculation errors
> caused
> by data overflow.
>
> Reviewed-by: Fugang Duan
> Signed-off-by: Clark Wang
Reviewed-by: Dong Aisheng
Regards
Aisheng
> ---
> drivers/i2c/busses/i2c-imx-lpi2c.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c
> b/drivers/i2c/busses/i2c-imx-lpi2c.c
> index 5dbe85126f24..1e26672d47bf 100644
> --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> @@ -213,8 +213,8 @@ static void lpi2c_imx_stop(struct lpi2c_imx_struct
> *lpi2c_imx)
> CLKHI = I2C_CLK_RATIO * clk_cycle */ static int lpi2c_imx_config(struct
> lpi2c_imx_struct *lpi2c_imx) {
> - u8 prescale, filt, sethold, clkhi, clklo, datavd;
> - unsigned int clk_rate, clk_cycle;
> + u8 prescale, filt, sethold, datavd;
> + unsigned int clk_rate, clk_cycle, clkhi, clklo;
> enum lpi2c_imx_pincfg pincfg;
> unsigned int temp;
>
> --
> 2.25.1
RE: [PATCH 09/11] i2c: imx-lpi2c: fix i2c timing issue
> From: Clark Wang
> Sent: Wednesday, March 17, 2021 2:54 PM
>
> The clkhi and clklo ratio was not very precise before that can make the time
> of
> START/STOP/HIGH LEVEL out of specification.
>
> Therefore, the calculation of these times has been modified in this patch.
> At the same time, the mode rate definition of i2c is corrected.
>
> Reviewed-by: Fugang Duan
> Signed-off-by: Clark Wang
> ---
> drivers/i2c/busses/i2c-imx-lpi2c.c | 27 ++-
> 1 file changed, 14 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c
> b/drivers/i2c/busses/i2c-imx-lpi2c.c
> index 7216a393095d..5dbe85126f24 100644
> --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> @@ -73,17 +73,17 @@
> #define MCFGR1_IGNACKBIT(9)
> #define MRDR_RXEMPTY BIT(14)
>
> -#define I2C_CLK_RATIO2
> +#define I2C_CLK_RATIO24 / 59
Where is this ratio coming from?
Can you describe why use it in commit message?
Regards
Aisheng
> #define CHUNK_DATA 256
>
> #define I2C_PM_TIMEOUT 1000 /* ms */
>
> enum lpi2c_imx_mode {
> - STANDARD, /* 100+Kbps */
> - FAST, /* 400+Kbps */
> - FAST_PLUS, /* 1.0+Mbps */
> - HS, /* 3.4+Mbps */
> - ULTRA_FAST, /* 5.0+Mbps */
> + STANDARD, /* <=100Kbps */
> + FAST, /* <=400Kbps */
> + FAST_PLUS, /* <=1.0Mbps */
> + HS, /* <=3.4Mbps */
> + ULTRA_FAST, /* <=5.0Mbps */
> };
>
> enum lpi2c_imx_pincfg {
> @@ -156,13 +156,13 @@ static void lpi2c_imx_set_mode(struct
> lpi2c_imx_struct *lpi2c_imx)
> unsigned int bitrate = lpi2c_imx->bitrate;
> enum lpi2c_imx_mode mode;
>
> - if (bitrate < I2C_MAX_FAST_MODE_FREQ)
> + if (bitrate <= I2C_MAX_STANDARD_MODE_FREQ)
> mode = STANDARD;
> - else if (bitrate < I2C_MAX_FAST_MODE_PLUS_FREQ)
> + else if (bitrate <= I2C_MAX_FAST_MODE_FREQ)
> mode = FAST;
> - else if (bitrate < I2C_MAX_HIGH_SPEED_MODE_FREQ)
> + else if (bitrate <= I2C_MAX_FAST_MODE_PLUS_FREQ)
> mode = FAST_PLUS;
> - else if (bitrate < I2C_MAX_ULTRA_FAST_MODE_FREQ)
> + else if (bitrate <= I2C_MAX_HIGH_SPEED_MODE_FREQ)
> mode = HS;
> else
> mode = ULTRA_FAST;
> @@ -209,7 +209,8 @@ static void lpi2c_imx_stop(struct lpi2c_imx_struct
> *lpi2c_imx)
> } while (1);
> }
>
> -/* CLKLO = I2C_CLK_RATIO * CLKHI, SETHOLD = CLKHI, DATAVD = CLKHI/2 */
> +/* CLKLO = (1 - I2C_CLK_RATIO) * clk_cycle, SETHOLD = CLKHI, DATAVD =
> CLKHI/2
> + CLKHI = I2C_CLK_RATIO * clk_cycle */
> static int lpi2c_imx_config(struct lpi2c_imx_struct *lpi2c_imx) {
> u8 prescale, filt, sethold, clkhi, clklo, datavd; @@ -232,8 +233,8 @@
> static int lpi2c_imx_config(struct lpi2c_imx_struct *lpi2c_imx)
>
> for (prescale = 0; prescale <= 7; prescale++) {
> clk_cycle = clk_rate / ((1 << prescale) * lpi2c_imx->bitrate)
> - - 3 - (filt >> 1);
> - clkhi = (clk_cycle + I2C_CLK_RATIO) / (I2C_CLK_RATIO + 1);
> + - (2 + filt) / (1 << prescale);
> + clkhi = clk_cycle * I2C_CLK_RATIO;
> clklo = clk_cycle - clkhi;
> if (clklo < 64)
> break;
> --
> 2.25.1
RE: [PATCH 08/11] i2c: imx-lpi2c: add bus recovery feature
> From: Clark Wang
> Sent: Wednesday, March 17, 2021 2:54 PM
>
> Add bus recovery feature for LPI2C.
> Need add gpio pinctrl, scl-gpios and sda-gpios configuration in dts.
>
Pls also update dt-binding first
> Signed-off-by: Clark Wang
> ---
> drivers/i2c/busses/i2c-imx-lpi2c.c | 83 ++
> 1 file changed, 83 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c
> b/drivers/i2c/busses/i2c-imx-lpi2c.c
> index c0cb77c66090..7216a393095d 100644
> --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -108,6 +109,11 @@ struct lpi2c_imx_struct {
> unsigned inttxfifosize;
> unsigned intrxfifosize;
> enum lpi2c_imx_mode mode;
> +
> + struct i2c_bus_recovery_info rinfo;
> + struct pinctrl *pinctrl;
> + struct pinctrl_state *pinctrl_pins_default;
> + struct pinctrl_state *pinctrl_pins_gpio;
> };
>
> static void lpi2c_imx_intctrl(struct lpi2c_imx_struct *lpi2c_imx, @@ -135,6
> +141,8 @@ static int lpi2c_imx_bus_busy(struct lpi2c_imx_struct *lpi2c_imx)
>
> if (time_after(jiffies, orig_jiffies + msecs_to_jiffies(500))) {
> dev_dbg(_imx->adapter.dev, "bus not work\n");
> + if (lpi2c_imx->adapter.bus_recovery_info)
> + i2c_recover_bus(_imx->adapter);
> return -ETIMEDOUT;
> }
> schedule();
> @@ -192,6 +200,8 @@ static void lpi2c_imx_stop(struct lpi2c_imx_struct
> *lpi2c_imx)
>
> if (time_after(jiffies, orig_jiffies + msecs_to_jiffies(500))) {
> dev_dbg(_imx->adapter.dev, "stop timeout\n");
> + if (lpi2c_imx->adapter.bus_recovery_info)
> + i2c_recover_bus(_imx->adapter);
> break;
> }
> schedule();
> @@ -329,6 +339,8 @@ static int lpi2c_imx_txfifo_empty(struct
> lpi2c_imx_struct *lpi2c_imx)
>
> if (time_after(jiffies, orig_jiffies + msecs_to_jiffies(500))) {
> dev_dbg(_imx->adapter.dev, "txfifo empty
> timeout\n");
> + if (lpi2c_imx->adapter.bus_recovery_info)
> + i2c_recover_bus(_imx->adapter);
> return -ETIMEDOUT;
> }
> schedule();
> @@ -528,6 +540,71 @@ static irqreturn_t lpi2c_imx_isr(int irq, void *dev_id)
> return IRQ_HANDLED;
> }
>
> +static void lpi2c_imx_prepare_recovery(struct i2c_adapter *adap) {
> + struct lpi2c_imx_struct *lpi2c_imx;
> +
> + lpi2c_imx = container_of(adap, struct lpi2c_imx_struct, adapter);
> +
> + pinctrl_select_state(lpi2c_imx->pinctrl,
> +lpi2c_imx->pinctrl_pins_gpio); }
> +
> +static void lpi2c_imx_unprepare_recovery(struct i2c_adapter *adap) {
> + struct lpi2c_imx_struct *lpi2c_imx;
> +
> + lpi2c_imx = container_of(adap, struct lpi2c_imx_struct, adapter);
> +
> + pinctrl_select_state(lpi2c_imx->pinctrl,
> +lpi2c_imx->pinctrl_pins_default); }
> +
> +/*
> + * We switch SCL and SDA to their GPIO function and do some bitbanging
> + * for bus recovery. These alternative pinmux settings can be
> + * described in the device tree by a separate pinctrl state "gpio". If
> + * this is missing this is not a big problem, the only implication is
> + * that we can't do bus recovery.
> + */
> +static int lpi2c_imx_init_recovery_info(struct lpi2c_imx_struct *lpi2c_imx,
> + struct platform_device *pdev)
> +{
> + struct i2c_bus_recovery_info *rinfo = _imx->rinfo;
> +
> + lpi2c_imx->pinctrl = devm_pinctrl_get(>dev);
> + if (!lpi2c_imx->pinctrl || IS_ERR(lpi2c_imx->pinctrl)) {
> + dev_info(>dev, "can't get pinctrl, bus recovery not
> supported\n");
> + return PTR_ERR(lpi2c_imx->pinctrl);
> + }
> +
> + lpi2c_imx->pinctrl_pins_default =
> pinctrl_lookup_state(lpi2c_imx->pinctrl,
> + PINCTRL_STATE_DEFAULT);
> + lpi2c_imx->pinctrl_pins_gpio = pinctrl_lookup_state(lpi2c_imx->pinctrl,
> + "gpio");
> + rinfo->sda_gpiod = devm_gpiod_get(>dev, "sda", GPIOD_IN);
> + rinfo->scl_gpiod = devm_gpiod_get(>dev, "scl",
> +GPIOD_OUT_HIGH_OPEN_DRAIN);
> +
> + if (PTR_ERR(rinfo->sda_gpiod) == -EPROBE_DEFER ||
> + PTR_ERR(rinfo->scl_gpiod) == -EPROBE_DEFER) {
> + return -EPROBE_DEFER;
> + } else if (IS_ERR(rinfo->sda_gpiod) ||
> +IS_ERR(rinfo->scl_gpiod) ||
> +IS_ERR(lpi2c_imx->pinctrl_pins_default) ||
> +IS_ERR(lpi2c_imx->pinctrl_pins_gpio)) {
> + dev_dbg(>dev, "recovery information incomplete\n");
> + return 0;
> + }
> +
> + dev_info(>dev, "using scl%s for recovery\n",
> + rinfo->sda_gpiod ? ",sda" : "");
> +
> +
RE: [PATCH 07/11] i2c: imx-lpi2c: increase PM timeout to avoid operate clk frequently
> From: Clark Wang
> Sent: Wednesday, March 17, 2021 2:54 PM
>
> Switching the clock frequently will affect the data transmission efficiency,
> and
> prolong the timeout to reduce autosuspend times for lpi2c.
>
> Acked-by: Fugang Duan
> Signed-off-by: Clark Wang
Reviewed-by: Dong Aisheng
Regards
Aisheng
> ---
> drivers/i2c/busses/i2c-imx-lpi2c.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c
> b/drivers/i2c/busses/i2c-imx-lpi2c.c
> index 86b69852f7be..c0cb77c66090 100644
> --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> @@ -75,7 +75,7 @@
> #define I2C_CLK_RATIO2
> #define CHUNK_DATA 256
>
> -#define I2C_PM_TIMEOUT 10 /* ms */
> +#define I2C_PM_TIMEOUT 1000 /* ms */
>
> enum lpi2c_imx_mode {
> STANDARD, /* 100+Kbps */
> --
> 2.25.1
RE: [PATCH 06/11] i2c: imx-lpi2c: improve i2c driver probe priority
> From: Clark Wang
> Sent: Wednesday, March 17, 2021 2:54 PM
>
> use subsys_initcall for i2c driver to improve i2c driver probe priority
Will this affect DMA support which will be probed much later compared with
subsys_initcall?
>
> Signed-off-by: Gao Pan
Add your sign-off
> ---
> drivers/i2c/busses/i2c-imx-lpi2c.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c
> b/drivers/i2c/busses/i2c-imx-lpi2c.c
> index 8f9dd3dd2951..86b69852f7be 100644
> --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> @@ -710,7 +710,17 @@ static struct platform_driver lpi2c_imx_driver = {
> },
> };
>
> -module_platform_driver(lpi2c_imx_driver);
> +static int __init lpi2c_imx_init(void)
> +{
> + return platform_driver_register(_imx_driver);
> +}
> +subsys_initcall(lpi2c_imx_init);
> +
> +static void __exit lpi2c_imx_exit(void) {
> + platform_driver_unregister(_imx_driver);
> +}
> +module_exit(lpi2c_imx_exit);
>
> MODULE_AUTHOR("Gao Pan ");
> MODULE_DESCRIPTION("I2C adapter driver for LPI2C bus");
> --
> 2.25.1
RE: [PATCH 05/11] i2c: imx-lpi2c: add debug message when i2c peripheral clk doesn't work
> From: Clark Wang
> Sent: Wednesday, March 17, 2021 2:54 PM
>
> add debug message when i2c peripheral clk rate is 0, then directly return
> -EINVAL.
>
> Signed-off-by: Gao Pan
> Reviewed-by: Andy Duan
Drop old review when patch is changed
> ---
> drivers/i2c/busses/i2c-imx-lpi2c.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c
> b/drivers/i2c/busses/i2c-imx-lpi2c.c
> index e718bb6b2387..8f9dd3dd2951 100644
> --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> @@ -209,7 +209,12 @@ static int lpi2c_imx_config(struct lpi2c_imx_struct
> *lpi2c_imx)
>
> lpi2c_imx_set_mode(lpi2c_imx);
>
> - clk_rate = clk_get_rate(lpi2c_imx->clk);
I guess the kernel can't compile right before this patch because lpi2c_imx->clk
was
Removed In former patch
You need double check not break bisect
> + clk_rate = clk_get_rate(lpi2c_imx->clk_per);
> + if (!clk_rate) {
> + dev_dbg(_imx->adapter.dev, "clk_per rate is 0\n");
s/dev_dbg/dev_err
> + return -EINVAL;
> + }
> +
> if (lpi2c_imx->mode == HS || lpi2c_imx->mode == ULTRA_FAST)
> filt = 0;
> else
> --
> 2.25.1
RE: [PATCH 04/11] i2c: imx-lpi2c: manage irq resource request/release in runtime pm
> From: Clark Wang
> Sent: Wednesday, March 17, 2021 2:54 PM
>
> Manage irq resource request/release in runtime pm to save irq domain's
> power.
>
> Signed-off-by: Frank Li
> Signed-off-by: Fugang Duan
> Reviewed-by: Frank Li
> ---
> drivers/i2c/busses/i2c-imx-lpi2c.c | 26 ++
> 1 file changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c
> b/drivers/i2c/busses/i2c-imx-lpi2c.c
> index 664fcc0dba51..e718bb6b2387 100644
> --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> @@ -94,6 +94,7 @@ enum lpi2c_imx_pincfg {
>
> struct lpi2c_imx_struct {
> struct i2c_adapter adapter;
> + int irq;
> struct clk *clk_per;
> struct clk *clk_ipg;
> void __iomem*base;
> @@ -543,7 +544,7 @@ static int lpi2c_imx_probe(struct platform_device
> *pdev) {
> struct lpi2c_imx_struct *lpi2c_imx;
> unsigned int temp;
> - int irq, ret;
> + int ret;
>
> lpi2c_imx = devm_kzalloc(>dev, sizeof(*lpi2c_imx), GFP_KERNEL);
> if (!lpi2c_imx)
> @@ -553,9 +554,9 @@ static int lpi2c_imx_probe(struct platform_device
> *pdev)
> if (IS_ERR(lpi2c_imx->base))
> return PTR_ERR(lpi2c_imx->base);
>
> - irq = platform_get_irq(pdev, 0);
> - if (irq < 0)
> - return irq;
> + lpi2c_imx->irq = platform_get_irq(pdev, 0);
> + if (lpi2c_imx->irq < 0)
> + return lpi2c_imx->irq;
>
> lpi2c_imx->adapter.owner= THIS_MODULE;
> lpi2c_imx->adapter.algo = _imx_algo;
> @@ -581,14 +582,6 @@ static int lpi2c_imx_probe(struct platform_device
> *pdev)
> if (ret)
> lpi2c_imx->bitrate = I2C_MAX_STANDARD_MODE_FREQ;
>
> - ret = devm_request_irq(>dev, irq, lpi2c_imx_isr,
> -IRQF_NO_SUSPEND,
> -pdev->name, lpi2c_imx);
> - if (ret) {
> - dev_err(>dev, "can't claim irq %d\n", irq);
> - return ret;
> - }
> -
> i2c_set_adapdata(_imx->adapter, lpi2c_imx);
> platform_set_drvdata(pdev, lpi2c_imx);
>
> @@ -640,6 +633,7 @@ static int __maybe_unused
> lpi2c_runtime_suspend(struct device *dev) {
> struct lpi2c_imx_struct *lpi2c_imx = dev_get_drvdata(dev);
>
> + devm_free_irq(dev, lpi2c_imx->irq, lpi2c_imx);
> clk_disable_unprepare(lpi2c_imx->clk_ipg);
> clk_disable_unprepare(lpi2c_imx->clk_per);
> pinctrl_pm_select_idle_state(dev);
> @@ -665,6 +659,14 @@ static int __maybe_unused
> lpi2c_runtime_resume(struct device *dev)
> dev_err(dev, "can't enable I2C ipg clock, ret=%d\n", ret);
> }
>
> + ret = devm_request_irq(dev, lpi2c_imx->irq, lpi2c_imx_isr,
I guess unnecessary to use devm in rpm
> +IRQF_NO_SUSPEND,
> +dev_name(dev), lpi2c_imx);
> + if (ret) {
> + dev_err(dev, "can't claim irq %d\n", lpi2c_imx->irq);
> + return ret;
> + }
> +
> return ret;
> }
>
> --
> 2.25.1
RE: [PATCH 03/11] i2c: imx-lpi2c: add ipg clk for lpi2c driver
> From: Clark Wang
> Sent: Wednesday, March 17, 2021 2:54 PM
>
> The lpi2c IP needs two clks: ipg clk and per clk. The old lpi2c driver missed
> ipg
> clk. This patch adds ipg clk for lpi2c driver.
>
Pleas also update dt-binding and sent along with this patchset.(before this one)
> Signed-off-by: Gao Pan
> Signed-off-by: Clark Wang
> Acked-by: Fugang Duan
You can drop the Ack tag if the patch was changed
> ---
> drivers/i2c/busses/i2c-imx-lpi2c.c | 28 +---
> 1 file changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c
> b/drivers/i2c/busses/i2c-imx-lpi2c.c
> index 1e920e7ac7c1..664fcc0dba51 100644
> --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> @@ -94,7 +94,8 @@ enum lpi2c_imx_pincfg {
>
> struct lpi2c_imx_struct {
> struct i2c_adapter adapter;
> - struct clk *clk;
> + struct clk *clk_per;
> + struct clk *clk_ipg;
> void __iomem*base;
> __u8*rx_buf;
> __u8*tx_buf;
> @@ -563,10 +564,16 @@ static int lpi2c_imx_probe(struct platform_device
> *pdev)
> strlcpy(lpi2c_imx->adapter.name, pdev->name,
> sizeof(lpi2c_imx->adapter.name));
>
> - lpi2c_imx->clk = devm_clk_get(>dev, NULL);
> - if (IS_ERR(lpi2c_imx->clk)) {
> + lpi2c_imx->clk_per = devm_clk_get(>dev, "per");
> + if (IS_ERR(lpi2c_imx->clk_per)) {
> dev_err(>dev, "can't get I2C peripheral clock\n");
> - return PTR_ERR(lpi2c_imx->clk);
> + return PTR_ERR(lpi2c_imx->clk_per);
> + }
> +
> + lpi2c_imx->clk_ipg = devm_clk_get(>dev, "ipg");
> + if (IS_ERR(lpi2c_imx->clk_ipg)) {
> + dev_err(>dev, "can't get I2C ipg clock\n");
> + return PTR_ERR(lpi2c_imx->clk_ipg);
> }
Will this break exist dts?
Regards
Aisheng
>
> ret = of_property_read_u32(pdev->dev.of_node,
> @@ -633,7 +640,8 @@ static int __maybe_unused
> lpi2c_runtime_suspend(struct device *dev) {
> struct lpi2c_imx_struct *lpi2c_imx = dev_get_drvdata(dev);
>
> - clk_disable_unprepare(lpi2c_imx->clk);
> + clk_disable_unprepare(lpi2c_imx->clk_ipg);
> + clk_disable_unprepare(lpi2c_imx->clk_per);
> pinctrl_pm_select_idle_state(dev);
>
> return 0;
> @@ -645,12 +653,18 @@ static int __maybe_unused
> lpi2c_runtime_resume(struct device *dev)
> int ret;
>
> pinctrl_pm_select_default_state(dev);
> - ret = clk_prepare_enable(lpi2c_imx->clk);
> + ret = clk_prepare_enable(lpi2c_imx->clk_per);
> if (ret) {
> - dev_err(dev, "can't enable I2C clock, ret=%d\n", ret);
> + dev_err(dev, "can't enable I2C per clock, ret=%d\n", ret);
> return ret;
> }
>
> + ret = clk_prepare_enable(lpi2c_imx->clk_ipg);
> + if (ret) {
> + clk_disable_unprepare(lpi2c_imx->clk_per);
> + dev_err(dev, "can't enable I2C ipg clock, ret=%d\n", ret);
> + }
> +
> return ret;
> }
>
> --
> 2.25.1
RE: [PATCH 02/11] i2c: imx-lpi2c: add runtime pm support
> From: Clark Wang
> Sent: Wednesday, March 17, 2021 2:54 PM
> Subject: [PATCH 02/11] i2c: imx-lpi2c: add runtime pm support
>
> - Add runtime pm support to dynamicly manage the clock.
> - Put the suspend to suspend_noirq.
> - Call .pm_runtime_force_suspend() to force runtime pm suspended
> in .suspend_noirq().
>
The patch title needs to be improved as the driver already supports rpm.
And do one thing in one patch.
> Signed-off-by: Fugang Duan
> Signed-off-by: Gao Pan
> Reviewed-by: Anson Huang
Please add your sign-off.
> ---
> drivers/i2c/busses/i2c-imx-lpi2c.c | 50 --
> 1 file changed, 33 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c
> b/drivers/i2c/busses/i2c-imx-lpi2c.c
> index bbf44ac95021..1e920e7ac7c1 100644
> --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> @@ -574,7 +574,8 @@ static int lpi2c_imx_probe(struct platform_device
> *pdev)
> if (ret)
> lpi2c_imx->bitrate = I2C_MAX_STANDARD_MODE_FREQ;
>
> - ret = devm_request_irq(>dev, irq, lpi2c_imx_isr, 0,
> + ret = devm_request_irq(>dev, irq, lpi2c_imx_isr,
> +IRQF_NO_SUSPEND,
This belongs to a separate patch
> pdev->name, lpi2c_imx);
> if (ret) {
> dev_err(>dev, "can't claim irq %d\n", irq); @@ -584,35
> +585,32 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
> i2c_set_adapdata(_imx->adapter, lpi2c_imx);
> platform_set_drvdata(pdev, lpi2c_imx);
>
> - ret = clk_prepare_enable(lpi2c_imx->clk);
> - if (ret) {
> - dev_err(>dev, "clk enable failed %d\n", ret);
> - return ret;
> - }
> -
> pm_runtime_set_autosuspend_delay(>dev, I2C_PM_TIMEOUT);
> pm_runtime_use_autosuspend(>dev);
> - pm_runtime_get_noresume(>dev);
> - pm_runtime_set_active(>dev);
> pm_runtime_enable(>dev);
>
> + ret = pm_runtime_get_sync(>dev);
> + if (ret < 0) {
> + pm_runtime_put_noidle(>dev);
> + dev_err(>dev, "failed to enable clock\n");
> + return ret;
> + }
Can't current clk control via rpm work well?
Please describe why need change.
> +
> temp = readl(lpi2c_imx->base + LPI2C_PARAM);
> lpi2c_imx->txfifosize = 1 << (temp & 0x0f);
> lpi2c_imx->rxfifosize = 1 << ((temp >> 8) & 0x0f);
>
> + pm_runtime_put(>dev);
> +
> ret = i2c_add_adapter(_imx->adapter);
> if (ret)
> goto rpm_disable;
>
> - pm_runtime_mark_last_busy(>dev);
> - pm_runtime_put_autosuspend(>dev);
> -
> dev_info(_imx->adapter.dev, "LPI2C adapter registered\n");
>
> return 0;
>
> rpm_disable:
> - pm_runtime_put(>dev);
> pm_runtime_disable(>dev);
> pm_runtime_dont_use_autosuspend(>dev);
>
> @@ -636,7 +634,7 @@ static int __maybe_unused
> lpi2c_runtime_suspend(struct device *dev)
> struct lpi2c_imx_struct *lpi2c_imx = dev_get_drvdata(dev);
>
> clk_disable_unprepare(lpi2c_imx->clk);
> - pinctrl_pm_select_sleep_state(dev);
> + pinctrl_pm_select_idle_state(dev);
This belongs to a separate patch
>
> return 0;
> }
> @@ -649,16 +647,34 @@ static int __maybe_unused
> lpi2c_runtime_resume(struct device *dev)
> pinctrl_pm_select_default_state(dev);
> ret = clk_prepare_enable(lpi2c_imx->clk);
> if (ret) {
> - dev_err(dev, "failed to enable I2C clock, ret=%d\n", ret);
> + dev_err(dev, "can't enable I2C clock, ret=%d\n", ret);
Probably unnecessary change
> return ret;
> }
>
> + return ret;
> +}
> +
> +static int lpi2c_suspend_noirq(struct device *dev) {
> + int ret;
> +
> + ret = pm_runtime_force_suspend(dev);
> + if (ret)
> + return ret;
> +
> + pinctrl_pm_select_sleep_state(dev);
> +
> return 0;
> }
>
> +static int lpi2c_resume_noirq(struct device *dev) {
> + return pm_runtime_force_resume(dev);
> +}
> +
> static const struct dev_pm_ops lpi2c_pm_ops = {
> - SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
> - pm_runtime_force_resume)
> + SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(lpi2c_suspend_noirq,
> + lpi2c_resume_noirq)
Belongs to separate change and explain why need do this
> SET_RUNTIME_PM_OPS(lpi2c_runtime_suspend,
> lpi2c_runtime_resume, NULL)
> };
> --
> 2.25.1
RE: [PATCH 01/11] i2c: imx-lpi2c: directly retrun ISR when detect a NACK
> From: Clark Wang
> Sent: Wednesday, March 17, 2021 2:54 PM
>
> A NACK flag in ISR means i2c bus error. In such codition, there is no need to
> do
> read/write operation. It's better to return ISR directly and then stop i2c
> transfer.
>
> Signed-off-by: Gao Pan
> Signed-off-by: Clark Wang
Reviewed-by: Dong Aisheng
Regards
Aisheng
> ---
> drivers/i2c/busses/i2c-imx-lpi2c.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c
> b/drivers/i2c/busses/i2c-imx-lpi2c.c
> index 9db6ccded5e9..bbf44ac95021 100644
> --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> @@ -507,15 +507,17 @@ static irqreturn_t lpi2c_imx_isr(int irq, void *dev_id)
> lpi2c_imx_intctrl(lpi2c_imx, 0);
> temp = readl(lpi2c_imx->base + LPI2C_MSR);
>
> + if (temp & MSR_NDF) {
> + complete(_imx->complete);
> + goto ret;
> + }
> +
> if (temp & MSR_RDF)
> lpi2c_imx_read_rxfifo(lpi2c_imx);
> -
> - if (temp & MSR_TDF)
> + else if (temp & MSR_TDF)
> lpi2c_imx_write_txfifo(lpi2c_imx);
>
> - if (temp & MSR_NDF)
> - complete(_imx->complete);
> -
> +ret:
> return IRQ_HANDLED;
> }
>
> --
> 2.25.1
RE: [PATCH] firmware: imx: scu-pd: Update comments for single global power domain
Hi Ulf, > From: Ulf Hansson > Sent: Wednesday, March 17, 2021 5:31 PM > > Since the introduction of the PM domain support for the scu-pd, the genpd > framework has been continuously improved. More preciously, using a single > global power domain can quite easily be deployed for imx platforms. > > To avoid confusions, let's therefore make an update to the comments about > the missing pieces. > > Signed-off-by: Ulf Hansson Thanks for the update. Reviewed-by: Dong Aisheng BTW, I'm still uncertain if the new approach can finally work well for i.MX as SCU PD also supports multiple low power state. I could investigate it more when I adding multi low power states support. Regards Aisheng > --- > drivers/firmware/imx/scu-pd.c | 11 +-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/drivers/firmware/imx/scu-pd.c b/drivers/firmware/imx/scu-pd.c > index 08533ee67626..6e178a63442d 100644 > --- a/drivers/firmware/imx/scu-pd.c > +++ b/drivers/firmware/imx/scu-pd.c > @@ -29,6 +29,10 @@ > *The framework needs some proper extension to support multi power > *domain cases. > * > + *Update: Genpd assigns the ->of_node for the virtual device before it > + *invokes ->attach_dev() callback, hence parsing for device resources via > + *DT should work fine. > + * > * 2. It also breaks most of current drivers as the driver probe sequence > *behavior changed if removing ->power_on|off() callback and use > *->start() and ->stop() instead. genpd_dev_pm_attach will only power > @@ -39,8 +43,11 @@ > *domain enabled will trigger a HW access error. That means we need fix > *most drivers probe sequence with proper runtime pm. > * > - * In summary, we need fix above two issue before being able to switch to > - * the "single global power domain" way. > + *Update: Runtime PM support isn't necessary. Instead, this can easily be > + *fixed in drivers by adding a call to dev_pm_domain_start() during > probe. > + * > + * In summary, the second part needs to be addressed via minor updates > + to the > + * relevant drivers, before the "single global power domain" model can be > used. > * > */ > > -- > 2.25.1
RE: [PATCH v9 7/8] arm64: dts: imx8qxp: Add jpeg encoder/decoder nodes
> From: Mirela Rabulea (OSS)
> Sent: Thursday, March 11, 2021 8:29 AM
>
> Add jpeg decoder/encoder nodes, for now on imx8qxp only.
> The same should work on imx8qm, but it was not tested.
>
> Signed-off-by: Mirela Rabulea
Please rebase to latest shawn/for-next branch and add
the necessary clocks.
I can help review when resend.
Regards
Aisheng
> ---
> arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 35
> ++
> 1 file changed, 35 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> index 1d522de7b017..4f2b3edd7850 100644
> --- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> @@ -629,4 +629,39 @@
> };
> };
> };
> +
> + img_subsys: bus@5800 {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x5800 0x0 0x5800 0x100>;
> +
> + jpegdec: jpegdec@5840 {
> + compatible = "nxp,imx8qxp-jpgdec";
> + reg = <0x5840 0x0005 >;
> + interrupts = ,
> + ,
> + ,
> + ;
> + power-domains = < IMX_SC_R_MJPEG_DEC_MP>,
> + < IMX_SC_R_MJPEG_DEC_S0>,
> + < IMX_SC_R_MJPEG_DEC_S1>,
> + < IMX_SC_R_MJPEG_DEC_S2>,
> + < IMX_SC_R_MJPEG_DEC_S3>;
> + };
> +
> + jpegenc: jpegenc@5845 {
> + compatible = "nxp,imx8qxp-jpgenc";
> + reg = <0x5845 0x0005 >;
> + interrupts = ,
> + ,
> + ,
> + ;
> + power-domains = < IMX_SC_R_MJPEG_ENC_MP>,
> + < IMX_SC_R_MJPEG_ENC_S0>,
> + < IMX_SC_R_MJPEG_ENC_S1>,
> + < IMX_SC_R_MJPEG_ENC_S2>,
> + < IMX_SC_R_MJPEG_ENC_S3>;
> + };
> + };
> };
> --
> 2.17.1
RE: [PATCH V3 4/5] dt-bindings: mmc: fsl-imx-esdhc: add clock bindings
> From: Rob Herring > Sent: Friday, March 5, 2021 10:14 PM > > On Fri, Mar 5, 2021 at 8:09 AM Aisheng Dong > wrote: > > > > Hi Rob, > > > > > From: Peng Fan (OSS) > > > Sent: Thursday, February 25, 2021 11:10 AM > > > > > > From: Peng Fan > > > > > > Add clock bindings for fsl-imx-esdhc yaml > > > > > > Signed-off-by: Peng Fan > > > --- > > > .../devicetree/bindings/mmc/fsl-imx-esdhc.yaml| 11 > +++ > > > 1 file changed, 11 insertions(+) > > > > > > diff --git > > > a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml > > > b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml > > > index a7fbd8cc1e38..369471814496 100644 > > > --- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml > > > +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml > > > @@ -103,6 +103,17 @@ properties: > > >Only eMMC HS400 mode need to take care of this property. > > > default: 0 > > > > > > + clocks: > > > +maxItems: 3 > > > +description: > > > + Handle clocks for the sdhc controller. > > > + > > > + clock-names: > > > +items: > > > + - const: ipg > > > + - const: ahb > > > + - const: per > > > > One question: > > The side effect of this patch is that it imposes a forced order of clk > > names In DT which actually was not needed. > > > > Do we really have to do that? > > Yes. > > > Or any other better approach to allow a random order to match the DT > > usage better? > > Why do you need random order? > Thanks for the feedback. I thought the DT itself supports the random order of strings/names in a property and the OF API in kernel can also handle the random name order properly. That means DT binding don't enforce the order of names when people writing DTS. e.g. Order1: clock-names = "ipg", "per", "ahb" can function the same as: Order2: clock-names = "ipg", "ahb", "per"; However, the schema in this patch enforced the name order which caused dt binding check fail. https://lore.kernel.org/linux-arm-kernel/cal_jsqkaouknvlvu-vnedvg0shxpy56wxhcqv38+ro2k961...@mail.gmail.com/#t And this seems like a common issue in kernel DT because DT supports random name order before. If we have to fix it, should we need fix them all in kernel? And finally, If all the names property are fixed by dt schema definition, the driver may also work without it by using index. > We can not enforce the order, but we only do that when there's multiple > optional entries. Understood, probably this is the simplest way to do a accurate DT schema checking. Regards Aisheng > > Rob
RE: [PATCH V3 4/5] dt-bindings: mmc: fsl-imx-esdhc: add clock bindings
Hi Rob, > From: Peng Fan (OSS) > Sent: Thursday, February 25, 2021 11:10 AM > > From: Peng Fan > > Add clock bindings for fsl-imx-esdhc yaml > > Signed-off-by: Peng Fan > --- > .../devicetree/bindings/mmc/fsl-imx-esdhc.yaml| 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml > b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml > index a7fbd8cc1e38..369471814496 100644 > --- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml > +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml > @@ -103,6 +103,17 @@ properties: >Only eMMC HS400 mode need to take care of this property. > default: 0 > > + clocks: > +maxItems: 3 > +description: > + Handle clocks for the sdhc controller. > + > + clock-names: > +items: > + - const: ipg > + - const: ahb > + - const: per One question: The side effect of this patch is that it imposes a forced order of clk names In DT which actually was not needed. Do we really have to do that? Or any other better approach to allow a random order to match the DT usage better? Regards Aisheng > + >pinctrl-names: > minItems: 1 > maxItems: 4 > -- > 2.30.0
RE: [PATCH] imx: select SOC_BUS to fix firmware build
> From: Randy Dunlap
> Sent: Saturday, January 16, 2021 11:33 AM
> Subject: [PATCH] imx: select SOC_BUS to fix firmware build
Patch title probably is better to be:
firmware: imx: x
Otherwise:
Reviewed-by: Dong Aisheng
Regards
Aisheng
>
> Fix build error in firmware/imx/ selecting SOC_BUS.
>
> riscv32-linux-ld: drivers/firmware/imx/imx-scu-soc.o: in function `.L9':
> imx-scu-soc.c:(.text+0x1b0): undefined reference to `soc_device_register'
>
> Fixes: edbee095fafb ("firmware: imx: add SCU firmware driver support")
> Signed-off-by: Randy Dunlap
> Reported-by: kernel test robot
> Cc: Atish Patra
> Cc: Palmer Dabbelt
> Cc: Ard Biesheuvel
> Cc: Anson Huang
> Cc: Daniel Baluta
> Cc: Shawn Guo
> Cc: Dong Aisheng
> ---
> drivers/firmware/imx/Kconfig |1 +
> 1 file changed, 1 insertion(+)
>
> --- linux-next-20210115.orig/drivers/firmware/imx/Kconfig
> +++ linux-next-20210115/drivers/firmware/imx/Kconfig
> @@ -13,6 +13,7 @@ config IMX_DSP
> config IMX_SCU
> bool "IMX SCU Protocol driver"
> depends on IMX_MBOX
> + select SOC_BUS
> help
> The System Controller Firmware (SCFW) is a low-level system function
> which runs on a dedicated Cortex-M core to provide power, clock, and
RE: [PATCH 1/3] driver core: simply go out if the same device_link is added again
> From: Rafael J. Wysocki
> Sent: Thursday, November 19, 2020 8:12 PM
>
> On Thu, Nov 19, 2020 at 12:18 PM Dong Aisheng
> wrote:
> >
> > It's possible that the same device link may be added by parsing the
> > function dependecy in DT. e.g. clock/gpio/regulators.
> > Simply go out for this case.
>
> Why?
>
> > Cc: Greg Kroah-Hartman
> > Cc: "Rafael J. Wysocki"
> > Cc: Saravana Kannan
> > Signed-off-by: Dong Aisheng
> > ---
> > drivers/base/core.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/base/core.c b/drivers/base/core.c index
> > 4c03bdd3a268..7d91d4074136 100644
> > --- a/drivers/base/core.c
> > +++ b/drivers/base/core.c
> > @@ -567,6 +567,9 @@ struct device_link *device_link_add(struct device
> *consumer,
> > if (link->consumer != consumer)
> > continue;
> >
> > + if (flags == link->flags)
> > + goto out;
>
> But this prevents rpm_count from being incremented if DL_FLAG_RPM_ACTIVE
> is set in flags, which is necessary, because the supplier's PM-runtime usage
> counter has been incremented already.
>
> Moreover, every attempt to create a stateless link must cause a new reference
> on the existing link to be acquired, or the removal will not work correctly.
Yes, I see. Thanks for the explanation.
Regards
Aisheng
>
> > +
> > if (flags & DL_FLAG_PM_RUNTIME) {
> > if (!(link->flags & DL_FLAG_PM_RUNTIME)) {
> > pm_runtime_new_link(consumer);
> > --
RE: [PATCH RESEND] driver core: export device_is_bound() to fix build failure
> From: Greg Kroah-Hartman
> Sent: Thursday, November 19, 2020 10:26 PM
>
> On Thu, Nov 19, 2020 at 02:09:42PM +0000, Aisheng Dong wrote:
> > > From: Greg Kroah-Hartman
> > > Sent: Thursday, November 19, 2020 9:10 PM
> > >
> > > On Thu, Nov 19, 2020 at 04:13:34AM +, Aisheng Dong wrote:
> > > > > Long story short, either
> > > > >
> > > > > * Don't care about the power domain in your clock driver.
> > > > >
> > > > > Or,
> > > > >
> > > > > * List the power domain in the clock controller's DT node and
> > > > > then use the normal APIs to get the power domain. And defer like
> > > > > any other driver if you can't get the power domain.
> > > > >
> > > >
> > > > Yes, I understand those are for normal cases. But our case is a
> > > > bit different and we don't want
> > > > imx_clk_scu() API return PROBE_DEFER which is unnecessary for a
> > > > hundred of
> > > clocks.
> > > > Even we want to defer probe, we prefer to defer in
> > > > imx_clk_scu_init() rather
> > > than in imx_clk_scu().
> > >
> > > What is wrong with PROBE_DEFER, that is what it is there for.
> >
> > Yes, we can use PROBE_DEFER, just not want to defer in
> > imx_clk_scu_init() when creating sub clock devices. Instead, we want
> > to defer at the beginning of clock driver probe which can save tens of defer
> probes due to the same reasons that PD driver is not ready.
>
> There's nothing wrong with deferring that many times until your proper driver
> is
> loaded, what does it cost you to do so?
One problem is that current imx8qxp-clk driver allows sub clocks register
optionally fail.
That's also the reason we don't want defer probe during register sub clocks.
static int imx8qxp_clk_probe(struct platform_device *pdev)
{
clks[IMX_LSIO_PWM0_CLK] = imx_clk_scu("pwm0_clk",
IMX_SC_R_PWM_0, IMX_SC_PM_CLK_PER, clk_cells);
clks[IMX_LSIO_PWM1_CLK] = imx_clk_scu("pwm1_clk",
IMX_SC_R_PWM_1, IMX_SC_PM_CLK_PER, clk_cells)
return of_clk_add_hw_provider(ccm_node, imx_scu_of_clk_src_get,
imx_scu_clks);
}
>
> > > > Maybe the things can be simplified as a simple requirement:
> > > > How users can make Driver A (CLK) to be probed after Driver B (PD)
> > > > without explicit firmware function dependency description (e.g.
> > > > phandle in
> > > DT)?
> > > >
> > > > As kernel core does not want to support it, then the left way may
> > > > be change scu-pd driver Inicall level or provide a private
> > > > callback to query the
> > > readiness.
> > >
> > > No, do not mess with that, as it totally breaks when things are built as a
> module.
> > >
> >
> > Can't this be addressed by proper module dependency? E.g clock module
> > depends on power domain module. Then clock driver can only be loaded after
> power domain.
>
> Sure, if you can do that, make your modules load properly by symbol
> dependency and all should be fine. Have you done that?
Still no. I planned to do that in another separate patch
The rough idea may be:
In PD driver, export an API like:
Bool imx_scu_pd_is_initilized(void);
In SCU clock driver:
If (!imx_scu_pd_is_initialized())
return -EPROBE_DEFER;
BTW I've already sent out a patch to remove the calling of device_is_bound() in
order to fix
the build break first.
https://patchwork.kernel.org/project/linux-clk/patch/20201119114302.26263-1-aisheng.d...@nxp.com/
It's okay to remove it first as DT patch using this code still not merged in
mainline.
Regards
Aisheng
>
> thanks,
>
> greg k-h
RE: [PATCH RESEND] driver core: export device_is_bound() to fix build failure
> From: Greg Kroah-Hartman
> Sent: Thursday, November 19, 2020 9:10 PM
>
> On Thu, Nov 19, 2020 at 04:13:34AM +0000, Aisheng Dong wrote:
> > > Long story short, either
> > >
> > > * Don't care about the power domain in your clock driver.
> > >
> > > Or,
> > >
> > > * List the power domain in the clock controller's DT node and then
> > > use the normal APIs to get the power domain. And defer like any
> > > other driver if you can't get the power domain.
> > >
> >
> > Yes, I understand those are for normal cases. But our case is a bit
> > different and we don't want
> > imx_clk_scu() API return PROBE_DEFER which is unnecessary for a hundred of
> clocks.
> > Even we want to defer probe, we prefer to defer in imx_clk_scu_init() rather
> than in imx_clk_scu().
>
> What is wrong with PROBE_DEFER, that is what it is there for.
Yes, we can use PROBE_DEFER, just not want to defer in imx_clk_scu_init() when
creating
sub clock devices. Instead, we want to defer at the beginning of clock driver
probe which
can save tens of defer probes due to the same reasons that PD driver is not
ready.
>
> > Maybe the things can be simplified as a simple requirement:
> > How users can make Driver A (CLK) to be probed after Driver B (PD)
> > without explicit firmware function dependency description (e.g. phandle in
> DT)?
> >
> > As kernel core does not want to support it, then the left way may be
> > change scu-pd driver Inicall level or provide a private callback to query
> > the
> readiness.
>
> No, do not mess with that, as it totally breaks when things are built as a
> module.
>
Can't this be addressed by proper module dependency? E.g clock module depends
on power domain module. Then clock driver can only be loaded after power domain.
> Rely on the deferred probing, that is what it was designed for, and it should
> not
> take very long at all, and it keeps you from having to dig into the driver
> core in
> ways that no one else has to.
>
> Please just fix up your DT file (sorry I didn't know ordering wouldn't solve
> this),
> and you should be fine.
>
Never mind and thank you for bringing me to the new features of fw_devlink which
I believe is good and can help us a lot on boot optimization and driver probes.
We may enable it in the future by default.
For the current problem, the difficulty is i don't know how to do it in
standard way
as we can't add power domains property in clock-controller node.
The reason is described here that clock-controller (SCU clock protocol) itself
does not
Depends on power domain.
https://www.spinics.net/lists/kernel/msg3742050.html
scu {
compatible = "fsl,imx-scu";
...
clk: clock-controller {
compatible = "fsl,imx8qxp-clk";
#clock-cells = <2>;
clocks = < >;
clock-names = "xtal_32KHz", "xtal_24Mhz";
};
pd: imx8qx-pd {
compatible = "fsl,imx8qxp-scu-pd", "fsl,scu-pd";
#power-domain-cells = <1>;
};
...
}
Regards
Aisheng
> thanks,
>
> greg k-h
RE: [PATCH RESEND] driver core: export device_is_bound() to fix build failure
> From: Saravana Kannan
> Sent: Thursday, November 19, 2020 6:22 AM
>
> On Wed, Nov 18, 2020 at 7:40 AM Aisheng Dong
> wrote:
> >
> > > From: Greg Kroah-Hartman
> > > Sent: Wednesday, November 18, 2020 6:46 PM
> > >
> > > On Wed, Nov 18, 2020 at 10:23:42AM +, Aisheng Dong wrote:
> > > > Hi Greg,
> > > >
> > > > > From: Greg Kroah-Hartman
> > > > > Sent: Monday, November 9, 2020 8:48 PM
> > > > >
> > > > > On Mon, Nov 09, 2020 at 12:26:55PM +, Aisheng Dong wrote:
> > > > > > > From: Greg Kroah-Hartman
> > > > > > > Sent: Monday, November 9, 2020 8:05 PM
> > > > > > >
> > > > > > > On Mon, Nov 09, 2020 at 11:55:46AM +, Aisheng Dong wrote:
> > > > > > > > > From: Greg Kroah-Hartman
> > > > > > > > > Sent: Monday, November 9, 2020 7:41 PM
> > > > > > > > >
> > > > > > > > > On Mon, Nov 09, 2020 at 10:57:05AM +, Aisheng Dong
> wrote:
> > > > > > > > > > Hi Greg,
> > > > > > > > > >
> > > > > > > > > > > From: Greg Kroah-Hartman
> > > > > > > > > > >
> > > > > > > > > > > Sent: Monday, November 9, 2020 6:37 PM
> > > > > > > > > > > Subject: Re: [PATCH RESEND] driver core: export
> > > > > > > > > > > device_is_bound() to fix build failure
> > > > > > > > > > >
> > > > > > > > > > > On Mon, Nov 09, 2020 at 10:14:46AM +, Sudip
> > > > > > > > > > > Mukherjee
> > > > > wrote:
> > > > > > > > > > > > Hi Greg,
> > > > > > > > > > > >
> > > > > > > > > > > > On Sun, Nov 8, 2020 at 8:23 AM Greg Kroah-Hartman
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Sat, Nov 07, 2020 at 10:47:27PM +, Sudip
> > > > > > > > > > > > > Mukherjee
> > > > > wrote:
> > > > > > > > > > > > > > When CONFIG_MXC_CLK_SCU is configured as 'm'
> > > > > > > > > > > > > > the build fails as it is unable to find
> > > > > > > > > > > > > > device_is_bound(). The error
> > > being:
> > > > > > > > > > > > > > ERROR: modpost: "device_is_bound"
> > > > > > > [drivers/clk/imx/clk-imx-scu.ko]
> > > > > > > > > > > > > > undefined!
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Export the symbol so that the module finds it.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Fixes: 77d8f3068c63 ("clk: imx: scu: add two
> > > > > > > > > > > > > > cells binding
> > > > > > > > > > > > > > support")
> > > > > > > > > > > > > > Signed-off-by: Sudip Mukherjee
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > ---
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > resending with the Fixes: tag.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > drivers/base/dd.c | 1 +
> > > > > > > > > > > > > > 1 file changed, 1 insertion(+)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > diff --git a/drivers/base/dd.c
> > > > > > > > > > > > > > b/drivers/base/dd.c index
> > > > > > > > > > > > > > 148e81969e04..a796a57e5efb 100644
> > > > > > > > > > > > > > --- a/drivers/base/dd.c
> > > > > > > > > > > > > > +++ b/drivers/base/dd.c
> &
RE: [PATCH RESEND] driver core: export device_is_bound() to fix build failure
> From: Greg Kroah-Hartman
> Sent: Wednesday, November 18, 2020 6:46 PM
>
> On Wed, Nov 18, 2020 at 10:23:42AM +0000, Aisheng Dong wrote:
> > Hi Greg,
> >
> > > From: Greg Kroah-Hartman
> > > Sent: Monday, November 9, 2020 8:48 PM
> > >
> > > On Mon, Nov 09, 2020 at 12:26:55PM +, Aisheng Dong wrote:
> > > > > From: Greg Kroah-Hartman
> > > > > Sent: Monday, November 9, 2020 8:05 PM
> > > > >
> > > > > On Mon, Nov 09, 2020 at 11:55:46AM +, Aisheng Dong wrote:
> > > > > > > From: Greg Kroah-Hartman
> > > > > > > Sent: Monday, November 9, 2020 7:41 PM
> > > > > > >
> > > > > > > On Mon, Nov 09, 2020 at 10:57:05AM +, Aisheng Dong wrote:
> > > > > > > > Hi Greg,
> > > > > > > >
> > > > > > > > > From: Greg Kroah-Hartman
> > > > > > > > > Sent: Monday, November 9, 2020 6:37 PM
> > > > > > > > > Subject: Re: [PATCH RESEND] driver core: export
> > > > > > > > > device_is_bound() to fix build failure
> > > > > > > > >
> > > > > > > > > On Mon, Nov 09, 2020 at 10:14:46AM +, Sudip
> > > > > > > > > Mukherjee
> > > wrote:
> > > > > > > > > > Hi Greg,
> > > > > > > > > >
> > > > > > > > > > On Sun, Nov 8, 2020 at 8:23 AM Greg Kroah-Hartman
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Sat, Nov 07, 2020 at 10:47:27PM +, Sudip
> > > > > > > > > > > Mukherjee
> > > wrote:
> > > > > > > > > > > > When CONFIG_MXC_CLK_SCU is configured as 'm' the
> > > > > > > > > > > > build fails as it is unable to find device_is_bound().
> > > > > > > > > > > > The error
> being:
> > > > > > > > > > > > ERROR: modpost: "device_is_bound"
> > > > > [drivers/clk/imx/clk-imx-scu.ko]
> > > > > > > > > > > > undefined!
> > > > > > > > > > > >
> > > > > > > > > > > > Export the symbol so that the module finds it.
> > > > > > > > > > > >
> > > > > > > > > > > > Fixes: 77d8f3068c63 ("clk: imx: scu: add two cells
> > > > > > > > > > > > binding
> > > > > > > > > > > > support")
> > > > > > > > > > > > Signed-off-by: Sudip Mukherjee
> > > > > > > > > > > >
> > > > > > > > > > > > ---
> > > > > > > > > > > >
> > > > > > > > > > > > resending with the Fixes: tag.
> > > > > > > > > > > >
> > > > > > > > > > > > drivers/base/dd.c | 1 +
> > > > > > > > > > > > 1 file changed, 1 insertion(+)
> > > > > > > > > > > >
> > > > > > > > > > > > diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> > > > > > > > > > > > index 148e81969e04..a796a57e5efb 100644
> > > > > > > > > > > > --- a/drivers/base/dd.c
> > > > > > > > > > > > +++ b/drivers/base/dd.c
> > > > > > > > > > > > @@ -353,6 +353,7 @@ bool device_is_bound(struct
> > > > > > > > > > > > device
> > > > > > > > > > > > *dev)
> > > > > {
> > > > > > > > > > > > return dev->p &&
> > > > > > > > > > > > klist_node_attached(>p->knode_driver);
> > > > > > > > > > > > }
> > > > > > > > > > > > +EXPORT_SYMBOL(device_is_bound);
> > > > > > > > > > >
> > > > > > > > > > > EXPORT_SYMBOL_GPL() please, like all the other
> > > > > > > > > > > exports in this
> > > file.
> > > > > > > >
RE: [PATCH RESEND] driver core: export device_is_bound() to fix build failure
Hi Greg,
> From: Greg Kroah-Hartman
> Sent: Monday, November 9, 2020 8:48 PM
>
> On Mon, Nov 09, 2020 at 12:26:55PM +0000, Aisheng Dong wrote:
> > > From: Greg Kroah-Hartman
> > > Sent: Monday, November 9, 2020 8:05 PM
> > >
> > > On Mon, Nov 09, 2020 at 11:55:46AM +, Aisheng Dong wrote:
> > > > > From: Greg Kroah-Hartman
> > > > > Sent: Monday, November 9, 2020 7:41 PM
> > > > >
> > > > > On Mon, Nov 09, 2020 at 10:57:05AM +, Aisheng Dong wrote:
> > > > > > Hi Greg,
> > > > > >
> > > > > > > From: Greg Kroah-Hartman
> > > > > > > Sent: Monday, November 9, 2020 6:37 PM
> > > > > > > Subject: Re: [PATCH RESEND] driver core: export
> > > > > > > device_is_bound() to fix build failure
> > > > > > >
> > > > > > > On Mon, Nov 09, 2020 at 10:14:46AM +, Sudip Mukherjee
> wrote:
> > > > > > > > Hi Greg,
> > > > > > > >
> > > > > > > > On Sun, Nov 8, 2020 at 8:23 AM Greg Kroah-Hartman
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Sat, Nov 07, 2020 at 10:47:27PM +, Sudip Mukherjee
> wrote:
> > > > > > > > > > When CONFIG_MXC_CLK_SCU is configured as 'm' the build
> > > > > > > > > > fails as it is unable to find device_is_bound(). The error
> > > > > > > > > > being:
> > > > > > > > > > ERROR: modpost: "device_is_bound"
> > > [drivers/clk/imx/clk-imx-scu.ko]
> > > > > > > > > > undefined!
> > > > > > > > > >
> > > > > > > > > > Export the symbol so that the module finds it.
> > > > > > > > > >
> > > > > > > > > > Fixes: 77d8f3068c63 ("clk: imx: scu: add two cells
> > > > > > > > > > binding
> > > > > > > > > > support")
> > > > > > > > > > Signed-off-by: Sudip Mukherjee
> > > > > > > > > >
> > > > > > > > > > ---
> > > > > > > > > >
> > > > > > > > > > resending with the Fixes: tag.
> > > > > > > > > >
> > > > > > > > > > drivers/base/dd.c | 1 +
> > > > > > > > > > 1 file changed, 1 insertion(+)
> > > > > > > > > >
> > > > > > > > > > diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> > > > > > > > > > index 148e81969e04..a796a57e5efb 100644
> > > > > > > > > > --- a/drivers/base/dd.c
> > > > > > > > > > +++ b/drivers/base/dd.c
> > > > > > > > > > @@ -353,6 +353,7 @@ bool device_is_bound(struct device
> > > > > > > > > > *dev)
> > > {
> > > > > > > > > > return dev->p &&
> > > > > > > > > > klist_node_attached(>p->knode_driver);
> > > > > > > > > > }
> > > > > > > > > > +EXPORT_SYMBOL(device_is_bound);
> > > > > > > > >
> > > > > > > > > EXPORT_SYMBOL_GPL() please, like all the other exports in this
> file.
> > > > > > > > >
> > > > > > > > > Also, wait, no, don't call this, are you sure you are
> > > > > > > > > calling it in a race-free way? And what branch/tree is
> > > > > > > > > the above
> > > commit in?
> > > > > > > >
> > > > > > > > I have not checked fully but since it is being called from
> > > > > > > > probe() I assume the lock will be held at that time.
> > > > > > >
> > > > > > > probe() should never call this function as it makes no sense
> > > > > > > at all at that point in time. The driver should be fixed.
> > > > > >
> > > > > > Would you suggest if any other API we can use to allow the
> > > > > > driver to know whether another device has been probed?
> > > > >
> > > > > There is none, s
RE: [PATCH RESEND] driver core: export device_is_bound() to fix build failure
> From: Greg Kroah-Hartman
> Sent: Monday, November 9, 2020 8:05 PM
>
> On Mon, Nov 09, 2020 at 11:55:46AM +0000, Aisheng Dong wrote:
> > > From: Greg Kroah-Hartman
> > > Sent: Monday, November 9, 2020 7:41 PM
> > >
> > > On Mon, Nov 09, 2020 at 10:57:05AM +, Aisheng Dong wrote:
> > > > Hi Greg,
> > > >
> > > > > From: Greg Kroah-Hartman
> > > > > Sent: Monday, November 9, 2020 6:37 PM
> > > > > Subject: Re: [PATCH RESEND] driver core: export
> > > > > device_is_bound() to fix build failure
> > > > >
> > > > > On Mon, Nov 09, 2020 at 10:14:46AM +, Sudip Mukherjee wrote:
> > > > > > Hi Greg,
> > > > > >
> > > > > > On Sun, Nov 8, 2020 at 8:23 AM Greg Kroah-Hartman
> > > > > > wrote:
> > > > > > >
> > > > > > > On Sat, Nov 07, 2020 at 10:47:27PM +, Sudip Mukherjee wrote:
> > > > > > > > When CONFIG_MXC_CLK_SCU is configured as 'm' the build
> > > > > > > > fails as it is unable to find device_is_bound(). The error
> > > > > > > > being:
> > > > > > > > ERROR: modpost: "device_is_bound"
> [drivers/clk/imx/clk-imx-scu.ko]
> > > > > > > > undefined!
> > > > > > > >
> > > > > > > > Export the symbol so that the module finds it.
> > > > > > > >
> > > > > > > > Fixes: 77d8f3068c63 ("clk: imx: scu: add two cells binding
> > > > > > > > support")
> > > > > > > > Signed-off-by: Sudip Mukherjee
> > > > > > > >
> > > > > > > > ---
> > > > > > > >
> > > > > > > > resending with the Fixes: tag.
> > > > > > > >
> > > > > > > > drivers/base/dd.c | 1 +
> > > > > > > > 1 file changed, 1 insertion(+)
> > > > > > > >
> > > > > > > > diff --git a/drivers/base/dd.c b/drivers/base/dd.c index
> > > > > > > > 148e81969e04..a796a57e5efb 100644
> > > > > > > > --- a/drivers/base/dd.c
> > > > > > > > +++ b/drivers/base/dd.c
> > > > > > > > @@ -353,6 +353,7 @@ bool device_is_bound(struct device *dev)
> {
> > > > > > > > return dev->p &&
> > > > > > > > klist_node_attached(>p->knode_driver);
> > > > > > > > }
> > > > > > > > +EXPORT_SYMBOL(device_is_bound);
> > > > > > >
> > > > > > > EXPORT_SYMBOL_GPL() please, like all the other exports in this
> > > > > > > file.
> > > > > > >
> > > > > > > Also, wait, no, don't call this, are you sure you are
> > > > > > > calling it in a race-free way? And what branch/tree is the above
> commit in?
> > > > > >
> > > > > > I have not checked fully but since it is being called from
> > > > > > probe() I assume the lock will be held at that time.
> > > > >
> > > > > probe() should never call this function as it makes no sense at
> > > > > all at that point in time. The driver should be fixed.
> > > >
> > > > Would you suggest if any other API we can use to allow the driver
> > > > to know whether another device has been probed?
> > >
> > > There is none, sorry, as that just opens up way too many problems.
> > >
> > > > For imx scu driver in question, it has a special requirement that
> > > > it depends on scu power domain driver. However, there're a huge
> > > > number
> > > > (200+) of power domains for each device clock, we can't define
> > > > them all in DT
> > > for a single clock controller node.
> > > >
> > > > That's why we wanted to use device_is_bound() before to check if
> > > > scu power domain is ready or not to support defer probe.
> > >
> > > Use the device link functionality for this type of thing, that is
> > > what it was created for.
> > >
> >
> > Thanks for the suggestion. I will check it how to use.
> > BTW, I wonder if dev_driver_string() could be an optional solution
> > which seems a more simple way?
>
> Also, how do you really know you even have a valid pointer to that other
> device
> structure? How are you getting access to that?
>
The rough idea is as follows. Not sure if those APIs are safe enough as there're
many users In kernel.
pd_np = of_find_compatible_node(NULL, NULL, "fsl,scu-pd");
pd_dev = of_find_device_by_node(pd_np);
if (!pd_dev || !dev_driver_string(_dev->dev) ||
strcmp(dev_driver_string(_dev->dev), "imx-scu-pd")) {
of_node_put(pd_np);
return -EPROBE_DEFER;
}
const char *dev_driver_string(const struct device *dev)
{
struct device_driver *drv;
/* dev->driver can change to NULL underneath us because of unbinding,
* so be careful about accessing it. dev->bus and dev->class should
* never change once they are set, so they don't need special care.
*/
drv = READ_ONCE(dev->driver);
return drv ? drv->name :
(dev->bus ? dev->bus->name :
(dev->class ? dev->class->name : ""));
}
EXPORT_SYMBOL(dev_driver_string);
Anyway, I will continue to investigate device_link according to your
suggestions.
Regards
Aisheng
> thanks,
>
> greg k-h
RE: [PATCH RESEND] driver core: export device_is_bound() to fix build failure
> From: Greg Kroah-Hartman
> Sent: Monday, November 9, 2020 7:41 PM
>
> On Mon, Nov 09, 2020 at 10:57:05AM +0000, Aisheng Dong wrote:
> > Hi Greg,
> >
> > > From: Greg Kroah-Hartman
> > > Sent: Monday, November 9, 2020 6:37 PM
> > > Subject: Re: [PATCH RESEND] driver core: export device_is_bound() to
> > > fix build failure
> > >
> > > On Mon, Nov 09, 2020 at 10:14:46AM +, Sudip Mukherjee wrote:
> > > > Hi Greg,
> > > >
> > > > On Sun, Nov 8, 2020 at 8:23 AM Greg Kroah-Hartman
> > > > wrote:
> > > > >
> > > > > On Sat, Nov 07, 2020 at 10:47:27PM +, Sudip Mukherjee wrote:
> > > > > > When CONFIG_MXC_CLK_SCU is configured as 'm' the build fails
> > > > > > as it is unable to find device_is_bound(). The error being:
> > > > > > ERROR: modpost: "device_is_bound" [drivers/clk/imx/clk-imx-scu.ko]
> > > > > > undefined!
> > > > > >
> > > > > > Export the symbol so that the module finds it.
> > > > > >
> > > > > > Fixes: 77d8f3068c63 ("clk: imx: scu: add two cells binding
> > > > > > support")
> > > > > > Signed-off-by: Sudip Mukherjee
> > > > > > ---
> > > > > >
> > > > > > resending with the Fixes: tag.
> > > > > >
> > > > > > drivers/base/dd.c | 1 +
> > > > > > 1 file changed, 1 insertion(+)
> > > > > >
> > > > > > diff --git a/drivers/base/dd.c b/drivers/base/dd.c index
> > > > > > 148e81969e04..a796a57e5efb 100644
> > > > > > --- a/drivers/base/dd.c
> > > > > > +++ b/drivers/base/dd.c
> > > > > > @@ -353,6 +353,7 @@ bool device_is_bound(struct device *dev) {
> > > > > > return dev->p &&
> > > > > > klist_node_attached(>p->knode_driver);
> > > > > > }
> > > > > > +EXPORT_SYMBOL(device_is_bound);
> > > > >
> > > > > EXPORT_SYMBOL_GPL() please, like all the other exports in this file.
> > > > >
> > > > > Also, wait, no, don't call this, are you sure you are calling it
> > > > > in a race-free way? And what branch/tree is the above commit in?
> > > >
> > > > I have not checked fully but since it is being called from probe()
> > > > I assume the lock will be held at that time.
> > >
> > > probe() should never call this function as it makes no sense at all
> > > at that point in time. The driver should be fixed.
> >
> > Would you suggest if any other API we can use to allow the driver to
> > know whether another device has been probed?
>
> There is none, sorry, as that just opens up way too many problems.
>
> > For imx scu driver in question, it has a special requirement that it
> > depends on scu power domain driver. However, there're a huge number
> > (200+) of power domains for each device clock, we can't define them all in
> > DT
> for a single clock controller node.
> >
> > That's why we wanted to use device_is_bound() before to check if scu
> > power domain is ready or not to support defer probe.
>
> Use the device link functionality for this type of thing, that is what it was
> created
> for.
>
Thanks for the suggestion. I will check it how to use.
BTW, I wonder if dev_driver_string() could be an optional solution which seems
a more
simple way?
Regards
Aisheng
> thanks,
>
> greg k-h
RE: [PATCH RESEND] driver core: export device_is_bound() to fix build failure
> From: Sudip Mukherjee > Sent: Monday, November 9, 2020 7:19 PM > > Hi Aisheng, > > On Mon, Nov 9, 2020 at 10:57 AM Aisheng Dong > wrote: > > > > Hi Greg, > > > > > From: Greg Kroah-Hartman > > > Sent: Monday, November 9, 2020 6:37 PM > > > Subject: Re: [PATCH RESEND] driver core: export device_is_bound() to > > > fix build failure > > > > > > On Mon, Nov 09, 2020 at 10:14:46AM +, Sudip Mukherjee wrote: > > > > Hi Greg, > > > > > > > > On Sun, Nov 8, 2020 at 8:23 AM Greg Kroah-Hartman > > > > wrote: > > > > > > > > > > On Sat, Nov 07, 2020 at 10:47:27PM +, Sudip Mukherjee wrote: > > > > > > When CONFIG_MXC_CLK_SCU is configured as 'm' the build fails > > > > > > as it is unable to find device_is_bound(). The error being: > > > > > > ERROR: modpost: "device_is_bound" [drivers/clk/imx/clk-imx-scu.ko] > > > > > > undefined! > > > > > > > > > > > > Export the symbol so that the module finds it. > > > > > > > > > > > > > > > probe() should never call this function as it makes no sense at all > > > at that point in time. The driver should be fixed. > > > > Would you suggest if any other API we can use to allow the driver to > > know whether another device has been probed? > > > > For imx scu driver in question, it has a special requirement that it > > depends on scu power domain driver. However, there're a huge number > > (200+) of power domains for each device clock, we can't define them all in > > DT > for a single clock controller node. > > > > That's why we wanted to use device_is_bound() before to check if scu > > power domain is ready or not to support defer probe. > > iiuc, you are waiting for "fsl,scu-pd" to be registered. > I think you might be able to use bus_for_each_dev() to check if the device has > registered with the bus or not. It will be on the bus only after bind was > successful. The bus will be "platform_bus_type". > But I am sure Greg can give you better suggestion than this. :) > Thanks for the suggestion. Seems like a working tricky method. :-) For a possible easier way, I wonder if we can use dev_driver_string() which is already exported in kernel. Waiting for Greg's suggestions on which way to go. Regards Aisheng > > -- > Regards > Sudip
RE: [PATCH RESEND] driver core: export device_is_bound() to fix build failure
Hi Greg,
> From: Greg Kroah-Hartman
> Sent: Monday, November 9, 2020 6:37 PM
> Subject: Re: [PATCH RESEND] driver core: export device_is_bound() to fix build
> failure
>
> On Mon, Nov 09, 2020 at 10:14:46AM +, Sudip Mukherjee wrote:
> > Hi Greg,
> >
> > On Sun, Nov 8, 2020 at 8:23 AM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Sat, Nov 07, 2020 at 10:47:27PM +, Sudip Mukherjee wrote:
> > > > When CONFIG_MXC_CLK_SCU is configured as 'm' the build fails as it
> > > > is unable to find device_is_bound(). The error being:
> > > > ERROR: modpost: "device_is_bound" [drivers/clk/imx/clk-imx-scu.ko]
> > > > undefined!
> > > >
> > > > Export the symbol so that the module finds it.
> > > >
> > > > Fixes: 77d8f3068c63 ("clk: imx: scu: add two cells binding
> > > > support")
> > > > Signed-off-by: Sudip Mukherjee
> > > > ---
> > > >
> > > > resending with the Fixes: tag.
> > > >
> > > > drivers/base/dd.c | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/drivers/base/dd.c b/drivers/base/dd.c index
> > > > 148e81969e04..a796a57e5efb 100644
> > > > --- a/drivers/base/dd.c
> > > > +++ b/drivers/base/dd.c
> > > > @@ -353,6 +353,7 @@ bool device_is_bound(struct device *dev) {
> > > > return dev->p && klist_node_attached(>p->knode_driver);
> > > > }
> > > > +EXPORT_SYMBOL(device_is_bound);
> > >
> > > EXPORT_SYMBOL_GPL() please, like all the other exports in this file.
> > >
> > > Also, wait, no, don't call this, are you sure you are calling it in
> > > a race-free way? And what branch/tree is the above commit in?
> >
> > I have not checked fully but since it is being called from probe() I
> > assume the lock will be held at that time.
>
> probe() should never call this function as it makes no sense at all at that
> point in
> time. The driver should be fixed.
Would you suggest if any other API we can use to allow the driver to know
whether
another device has been probed?
For imx scu driver in question, it has a special requirement that it depends on
scu power domain
driver. However, there're a huge number (200+) of power domains for each device
clock, we can't define
them all in DT for a single clock controller node.
That's why we wanted to use device_is_bound() before to check if scu power
domain is ready or not to
support defer probe.
Regards
Aisheng
>
> This function should not be exported, sorry.
>
> thanks,
>
> greg k-h
RE: [PATCH] clk: imx: remove redundant assignment to pointer np
> From: Colin King
> Sent: Friday, October 30, 2020 6:40 AM
>
> Pointer np is being initialized with a value that is never read and it is
> being
> updated with a value later on. The initialization is redundant and can be
> removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King
Reviewed-by: Dong Aisheng
Regards
Aisheng
RE: [PATCH v2 5/5] soc: imx8: Add the SC SECVIO driver
> From: Shawn Guo
> Sent: Wednesday, August 19, 2020 9:32 PM
> >
> > The SNVS is a hardware component in the imx8 SoC. One of its function
> > is to detect hardware attacks, in which case it creates a SECurity
> > VIOlation.
> >
> > This patch adds the support for the reception of these secvio and
> > report it to the audit framework.
> >
> > It also gives the possibility to perform custom processing when a
> > secvio is detected.
> >
> > Signed-off-by: Franck LENORMAND
> > Reported-by: kernel test robot
> > ---
> > drivers/soc/imx/Kconfig | 10 +
> > drivers/soc/imx/Makefile| 1 +
> > drivers/soc/imx/secvio/Kconfig | 10 +
> > drivers/soc/imx/secvio/Makefile | 3 +
> > drivers/soc/imx/secvio/imx-secvio-audit.c | 39 ++
> > drivers/soc/imx/secvio/imx-secvio-debugfs.c | 379
> > drivers/soc/imx/secvio/imx-secvio-sc-int.h | 84 +++
> > drivers/soc/imx/secvio/imx-secvio-sc.c | 858
>
> > include/soc/imx/imx-secvio-sc.h | 177 ++
> > 9 files changed, 1561 insertions(+)
> > create mode 100644 drivers/soc/imx/secvio/Kconfig create mode 100644
> > drivers/soc/imx/secvio/Makefile create mode 100644
> > drivers/soc/imx/secvio/imx-secvio-audit.c
> > create mode 100644 drivers/soc/imx/secvio/imx-secvio-debugfs.c
> > create mode 100644 drivers/soc/imx/secvio/imx-secvio-sc-int.h
> > create mode 100644 drivers/soc/imx/secvio/imx-secvio-sc.c
> > create mode 100644 include/soc/imx/imx-secvio-sc.h
>
> Hi Arnd,
>
> Do we have any subsystem to accommodate this driver? Or 'soc' is just the
> right place for it?
>
Not sure if EDAC could be a better place.
e.g.
drivers/edac/sifive_edac.c
If not, maybe we can put in 'soc' first.
Regards
Aisheng
> Shawn
>
> >
> > diff --git a/drivers/soc/imx/Kconfig b/drivers/soc/imx/Kconfig index
> > a9370f4..6c1bc78 100644
> > --- a/drivers/soc/imx/Kconfig
> > +++ b/drivers/soc/imx/Kconfig
> > @@ -19,4 +19,14 @@ config SOC_IMX8M
> > support, it will provide the SoC info like SoC family,
> > ID and revision etc.
> >
> > +config SECVIO_SC
> > +tristate "NXP SC secvio support"
> > +depends on IMX_SCU
> > +help
> > + If you say yes here you get support for the NXP SNVS security
> > + violation module. It includes the possibility to read
> > information
> > + related to security violations and tampers. It also gives the
> > + possibility to register user callbacks when a security violation
> > + occurs.
> > +
> > endmenu
> > diff --git a/drivers/soc/imx/Makefile b/drivers/soc/imx/Makefile index
> > 078dc91..c91a499 100644
> > --- a/drivers/soc/imx/Makefile
> > +++ b/drivers/soc/imx/Makefile
> > @@ -5,3 +5,4 @@ endif
> > obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
> > obj-$(CONFIG_IMX_GPCV2_PM_DOMAINS) += gpcv2.o
> > obj-$(CONFIG_SOC_IMX8M) += soc-imx8m.o
> > +obj-${CONFIG_SECVIO_SC} += secvio/
> > diff --git a/drivers/soc/imx/secvio/Kconfig
> > b/drivers/soc/imx/secvio/Kconfig new file mode 100644 index
> > 000..dcfaea5
> > --- /dev/null
> > +++ b/drivers/soc/imx/secvio/Kconfig
> > @@ -0,0 +1,10 @@
> > +config SECVIO_SC
> > +tristate "NXP SC secvio support"
> > +depends on IMX_SCU
> > +help
> > + If you say yes here you get support for the NXP SNVS security
> > + violation module. It includes the possibility to read
> > information
> > + related to security violations and tampers. It also gives the
> > + possibility to register user callbacks when a security violation
> > + occurs.
> > +
> > diff --git a/drivers/soc/imx/secvio/Makefile
> > b/drivers/soc/imx/secvio/Makefile new file mode 100644 index
> > 000..d5a89ba
> > --- /dev/null
> > +++ b/drivers/soc/imx/secvio/Makefile
> > @@ -0,0 +1,3 @@
> > +obj-y += imx-secvio-sc.o
> > +obj-$(CONFIG_DEBUG_FS) += imx-secvio-debugfs.o
> > +obj-$(CONFIG_AUDIT) += imx-secvio-audit.o
> > diff --git a/drivers/soc/imx/secvio/imx-secvio-audit.c
> > b/drivers/soc/imx/secvio/imx-secvio-audit.c
> > new file mode 100644
> > index 000..dc96e16
> > --- /dev/null
> > +++ b/drivers/soc/imx/secvio/imx-secvio-audit.c
> > @@ -0,0 +1,39 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright 2019-2020 NXP
> > + */
> > +
> > +#include
> > +
> > +#include
> > +
> > +/**
> > + * report_to_audit_notify() - Report secvio and tamper status to
> > +audit FW
> > + *
> > + * This function can be chained in a notifier list
> > + *
> > + * @nb: notifier block
> > + * @status: error code
> > + * @notif_info: Pointer on secvio_sc_notifier_info structure
> > + *
> > + * Return:
> > + * 0 - OK
> > + * < 0 - error.
> > + */
> > +int report_to_audit_notify(struct notifier_block *nb, unsigned long status,
> > + void *notif_info)
> > +{
> > + struct audit_buffer *ab;
> > + struct secvio_sc_notifier_info *info = notif_info;
> > +
>
RE: [PATCH v2 4/5] dt-bindings: arm: imx: Documentation of the SC secvio driver
> From: Franck Lenormand (OSS) > Sent: Tuesday, July 21, 2020 11:21 PM > > This patch adds the documentation for the SECurity VIOlation driver using the > SCU on imx8x and imx8q. > > Signed-off-by: Franck LENORMAND > --- > .../bindings/arm/freescale/fsl,imx-sc-secvio.yaml | 34 > ++ > 1 file changed, 34 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/arm/freescale/fsl,imx-sc-secvio.yaml > > diff --git > a/Documentation/devicetree/bindings/arm/freescale/fsl,imx-sc-secvio.yaml > b/Documentation/devicetree/bindings/arm/freescale/fsl,imx-sc-secvio.yaml > new file mode 100644 > index 000..59b9a86 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,imx-sc-secvio. > +++ yaml > @@ -0,0 +1,34 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 > +--- > +$id: > +http://devicetree.org/schemas/arm/freescale/fsl,imx-sc-secvio.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: NXP i.MX Security Violation driver > + > +maintainers: > + - Franck LENORMAND > + > +description: | > + Receive security violation from the SNVS via the SCU firmware. Allow > +to > + register notifier for additional processing > + > +properties: > + compatible: > +enum: > + - fsl,imx-sc-secvio > + nvmem: Can we use standard nvmem-cells? Documentation/devicetree/bindings/nvmem/nvmem-consumer.yaml Regards Aisheng > +$ref: /schemas/types.yaml#/definitions/phandle > +description: > + Phandle to the nvmem provider. > + > +required: > + - compatible > + - nvmem > + > +examples: > + - | > +sc_secvio: sc-secvio > +compatible = "fsl,imx-sc-secvio"; > +nvmem = <> > +}; > -- > 2.7.4
RE: [PATCH v2 3/5] dt-bindings: firmware: imx-scu: Add SECVIO resource
> From: Franck Lenormand (OSS) > Sent: Tuesday, July 21, 2020 11:21 PM > > The SNVS can trigger interruption when detecting a SECurity VIOlation. > This patch adds the definition of the resource. > Not sure if the uppercase of 'SECurity VIOlation' is intended because it looks strange. Otherwise, I'm okay with this patch. Regards Aisheng > Signed-off-by: Franck LENORMAND > --- > include/dt-bindings/firmware/imx/rsrc.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/include/dt-bindings/firmware/imx/rsrc.h > b/include/dt-bindings/firmware/imx/rsrc.h > index 54278d5..fe5f25f 100644 > --- a/include/dt-bindings/firmware/imx/rsrc.h > +++ b/include/dt-bindings/firmware/imx/rsrc.h > @@ -1,7 +1,7 @@ > /* SPDX-License-Identifier: GPL-2.0+ */ > /* > * Copyright (C) 2016 Freescale Semiconductor, Inc. > - * Copyright 2017-2018 NXP > + * Copyright 2017-2018, 2020 NXP > */ > > #ifndef __DT_BINDINGS_RSCRC_IMX_H > @@ -50,6 +50,7 @@ > #define IMX_SC_R_DC_1_BLIT2 38 > #define IMX_SC_R_DC_1_BLIT_OUT 39 > #define IMX_SC_R_DC_1_WARP 42 > +#define IMX_SC_R_SECVIO 44 > #define IMX_SC_R_DC_1_VIDEO0 45 > #define IMX_SC_R_DC_1_VIDEO1 46 > #define IMX_SC_R_DC_1_FRAC0 47 > -- > 2.7.4
RE: [PATCH v2 2/5] firmware: imx: scu-irq: Add API to retrieve status of IRQ
> From: Franck Lenormand (OSS)
> Sent: Tuesday, July 21, 2020 11:21 PM
>
> This patch adds the API to retrieve the status of an IRQ.
>
> It also adds values used to process SECVIO IRQ from the SCU.
>
> Signed-off-by: Franck LENORMAND
> ---
> drivers/firmware/imx/imx-scu-irq.c | 37
> -
> include/linux/firmware/imx/sci.h | 4
> 2 files changed, 40 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/imx/imx-scu-irq.c
> b/drivers/firmware/imx/imx-scu-irq.c
> index d9dcc20..d31d600 100644
> --- a/drivers/firmware/imx/imx-scu-irq.c
> +++ b/drivers/firmware/imx/imx-scu-irq.c
> @@ -1,6 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0+
> /*
> - * Copyright 2019 NXP
> + * Copyright 2019-2020 NXP
> *
> * Implementation of the SCU IRQ functions using MU.
> *
> @@ -97,6 +97,41 @@ static void imx_scu_irq_work_handler(struct
> work_struct *work)
> }
> }
>
> +/**
> + * imx_scu_irq_get_status() - Get the status of the IRQs of a group
This API is a little duplicated with the exist imx_scu_irq_work_handler.
Can we refactor the exist code into this API?
Regards
Aisheng
> + *
> + * @group: The group of IRQ to retrieve status
> + * @irq_status: Status of the IRQs retrieved
> + *
> + * Return:
> + * 0 - OK
> + * < 0 - error.
> + */
> +int imx_scu_irq_get_status(u8 group, u32 *irq_status) {
> + struct imx_sc_msg_irq_get_status msg;
> + struct imx_sc_rpc_msg *hdr =
> + int ret;
> +
> + hdr->ver = IMX_SC_RPC_VERSION;
> + hdr->svc = IMX_SC_RPC_SVC_IRQ;
> + hdr->func = IMX_SC_IRQ_FUNC_STATUS;
> + hdr->size = 2;
> +
> + msg.data.req.resource = mu_resource_id;
> + msg.data.req.group = group;
> +
> + ret = imx_scu_call_rpc(imx_sc_irq_ipc_handle, , true);
> + if (ret)
> + return ret;
> +
> + if (irq_status)
> + *irq_status = msg.data.resp.status;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(imx_scu_irq_get_status);
> +
> int imx_scu_irq_group_enable(u8 group, u32 mask, u8 enable) {
> struct imx_sc_msg_irq_enable msg;
> diff --git a/include/linux/firmware/imx/sci.h
> b/include/linux/firmware/imx/sci.h
> index 914dce1..20a16a7 100644
> --- a/include/linux/firmware/imx/sci.h
> +++ b/include/linux/firmware/imx/sci.h
> @@ -17,9 +17,13 @@
> #include
> #include
>
> +#define IMX_SC_IRQ_GROUP_WAKE 3U /* Wakeup interrupts */
> +#define IMX_SC_IRQ_SECVIOBIT(6)/* Security violation */
> +
> int imx_scu_enable_general_irq_channel(struct device *dev); int
> imx_scu_irq_register_notifier(struct notifier_block *nb); int
> imx_scu_irq_unregister_notifier(struct notifier_block *nb); int
> imx_scu_irq_group_enable(u8 group, u32 mask, u8 enable); int
> imx_scu_soc_init(struct device *dev);
> +int imx_scu_irq_get_status(u8 group, u32 *irq_status);
> #endif /* _SC_SCI_H */
> --
> 2.7.4
RE: [PATCH v2 1/5] firmware: imx: scu-seco: Add SEcure Controller APIS
> From: Franck Lenormand (OSS)
> Sent: Tuesday, July 21, 2020 11:21 PM
> Subject: [PATCH v2 1/5] firmware: imx: scu-seco: Add SEcure Controller APIS
Is 'Secure' intended? Not 'Secure'?
>
> This patch adds the APIs:
> - imx_sc_seco_build_info: get commit and sha of SECO
> - imx_sc_seco_secvio_enable: enable SNVS IRQ handling
> - imx_sc_seco_secvio_config: configure SNVS register
> - imx_sc_seco_secvio_dgo_config: configure SNVS DGO register
>
> Signed-off-by: Franck LENORMAND
> ---
> drivers/firmware/imx/Makefile | 2 +-
> drivers/firmware/imx/imx-scu.c| 3 +
> drivers/firmware/imx/seco.c | 275
> ++
> include/linux/firmware/imx/ipc.h | 1 +
> include/linux/firmware/imx/sci.h | 1 +
> include/linux/firmware/imx/svc/seco.h | 73 +
> 6 files changed, 354 insertions(+), 1 deletion(-) create mode 100644
> drivers/firmware/imx/seco.c create mode 100644
> include/linux/firmware/imx/svc/seco.h
>
> diff --git a/drivers/firmware/imx/Makefile b/drivers/firmware/imx/Makefile
> index b76acba..f23e2b0 100644
> --- a/drivers/firmware/imx/Makefile
> +++ b/drivers/firmware/imx/Makefile
> @@ -1,4 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0
> obj-$(CONFIG_IMX_DSP)+= imx-dsp.o
> -obj-$(CONFIG_IMX_SCU)+= imx-scu.o misc.o imx-scu-irq.o rm.o
> imx-scu-soc.o
> +obj-$(CONFIG_IMX_SCU)+= imx-scu.o misc.o imx-scu-irq.o rm.o
> imx-scu-soc.o seco.o
> obj-$(CONFIG_IMX_SCU_PD) += scu-pd.o
> diff --git a/drivers/firmware/imx/imx-scu.c b/drivers/firmware/imx/imx-scu.c
> index dca79ca..ed7b87b 100644
> --- a/drivers/firmware/imx/imx-scu.c
> +++ b/drivers/firmware/imx/imx-scu.c
> @@ -245,6 +245,9 @@ int imx_scu_call_rpc(struct imx_sc_ipc *sc_ipc, void
> *msg, bool have_resp)
> (saved_func == IMX_SC_MISC_FUNC_UNIQUE_ID ||
>saved_func == IMX_SC_MISC_FUNC_GET_BUTTON_STATUS))
> ret = 0;
> + if (saved_svc == IMX_SC_RPC_SVC_SECO &&
> + saved_func == IMX_SC_SECO_FUNC_BUILD_INFO)
> + ret = 0;
> }
Pls combined into the previous if statement.
>
> out:
> diff --git a/drivers/firmware/imx/seco.c b/drivers/firmware/imx/seco.c new
> file
> mode 100644 index 000..9047a75
> --- /dev/null
> +++ b/drivers/firmware/imx/seco.c
> @@ -0,0 +1,275 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2020 NXP
> + *
> + * File containing client-side RPC functions for the SECO service.
> +These
> + * functions are ported to clients that communicate to the SC.
> + */
> +
> +#include
> +
> +struct imx_sc_msg_seco_get_build_id {
> + struct imx_sc_rpc_msg hdr;
> + u32 version;
> + u32 commit;
> +};
> +
> +/**
> + * imx_sc_seco_build_info() - Get version and coomit ID of the SECO
s/coomit/commit
> + *
> + * @ipc: IPC handle
> + * @version: Version of the SECO
> + * @commit: Commit ID of the SECO
> + *
> + * Return:
> + * 0 - OK
> + * < 0 - error.
Can we follow the exist style?
@return Returns 0 for success and < 0 for errors
> + */
> +int imx_sc_seco_build_info(struct imx_sc_ipc *ipc, uint32_t *version,
> +uint32_t *commit)
> +{
> + int ret;
> + struct imx_sc_msg_seco_get_build_id msg = {0};
Unnecessary default to 0
> + struct imx_sc_rpc_msg *hdr =
> +
> + hdr->ver = IMX_SC_RPC_VERSION;
> + hdr->svc = IMX_SC_RPC_SVC_SECO;
> + hdr->func = IMX_SC_SECO_FUNC_BUILD_INFO;
> + hdr->size = 1;
> +
> + ret = imx_scu_call_rpc(ipc, , true);
> + if (ret)
> + return ret;
> +
> + if (version)
> + *version = msg.version;
> + if (commit)
> + *commit = msg.commit;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(imx_sc_seco_build_info);
> +
> +struct imx_sc_msg_seco_sab_msg {
> + struct imx_sc_rpc_msg hdr;
> + u32 smsg_addr_hi;
> + u32 smsg_addr_lo;
> +};
This can be added when used
> +
> +/**
> + * imx_sc_seco_secvio_enable() - Enable the processing of secvio IRQ
> +from the
> + * SNVS by the SECO
> + *
> + * @ipc: IPC handle
> + *
> + * Return:
> + * 0 - OK
> + * < 0 - error.
Ditto
> + */
> +int imx_sc_seco_secvio_enable(struct imx_sc_ipc *ipc) {
> + struct imx_sc_rpc_msg msg;
> + struct imx_sc_rpc_msg *hdr =
Unnecessary
> + int ret;
> +
> + hdr->ver = IMX_SC_RPC_VERSION;
> + hdr->svc = IMX_SC_RPC_SVC_SECO;
> + hdr->func = IMX_SC_SECO_FUNC_SECVIO_ENABLE;
> + hdr->size = 1;
s/hdr->xxx/msg.xxx
> +
> + ret = imx_scu_call_rpc(ipc, , true);
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(imx_sc_seco_secvio_enable);
> +
> +struct imx_sc_msg_req_seco_config {
> + struct imx_sc_rpc_msg hdr;
> + u32 data0;
> + u32 data1;
> + u32 data2;
> + u32 data3;
> + u32 data4;
> + u8 id;
> + u8 access;
> + u8 size;
> +} __packed __aligned(4);
> +
> +struct
RE: [PATCH] opp: Don't always remove static OPPs in _of_add_opp_table_v1()
Hi Viresh
Thanks for the quick fix.
> From: Viresh Kumar
> Sent: Wednesday, October 14, 2020 12:26 PM
>
> The patch missed returning 0 early in case of success and hence the static
> OPPs
> got removed by mistake. Fix it.
>
> Fixes: 90d46d71cce2 ("opp: Handle multiple calls for same OPP table in
> _of_add_opp_table_v1()")
> Reported-by: Aisheng Dong
> Signed-off-by: Viresh Kumar
Tested-by: Dong Aisheng
Regards
Aisheng
> ---
> drivers/opp/of.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/opp/of.c b/drivers/opp/of.c index
> 874b58756220..9faeb83e4b32 100644
> --- a/drivers/opp/of.c
> +++ b/drivers/opp/of.c
> @@ -944,6 +944,8 @@ static int _of_add_opp_table_v1(struct device *dev,
> struct opp_table *opp_table)
> nr -= 2;
> }
>
> + return 0;
> +
> remove_static_opp:
> _opp_remove_all_static(opp_table);
>
> --
> 2.25.0.rc1.19.g042ed3e048af
RE: [PATCH V3 1/4] gpio: mxc: Support module build
Hi Shawn, > From: Anson Huang > Sent: Monday, October 12, 2020 7:36 PM > > Hi, Shawn > > > Subject: Re: [PATCH V3 1/4] gpio: mxc: Support module build > > > > On Thu, Sep 17, 2020 at 7:40 AM Anson Huang > > wrote: > > > > > Change config to tristate, add module device table, module author, > > > description and license to support module build for i.MX GPIO driver. > > > > > > As this is a SoC GPIO module, it provides common functions for most > > > of the peripheral devices, such as GPIO pins control, secondary > > > interrupt controller for GPIO pins IRQ etc., without GPIO driver, > > > most of the peripheral devices will NOT work properly, so GPIO > > > module is similar with clock, pinctrl driver that should be loaded > > > ONCE and never unloaded. > > > > > > Since MXC GPIO driver needs to have init function to register > > > syscore ops once, here still use subsys_initcall(), NOT > module_platform_driver(). > > > > > > Signed-off-by: Anson Huang > > > > This patch (1) applied to the GPIO tree. > > Please apply the rest through the ARM SoC tree! > > > > Could you please help pick the rest patch of this series? Otherwise, the i.MX > GPIO driver will NOT be enabled by default and it will block kernel boot. This blocked a huge number of i.MX boards booting with latest linux-next kernel. Would you help pick it ASAP? Regards Aisheng > > Thanks, > Anson
RE: [PATCH v3] dt-bindings: mailbox: fsl,mu: Add missing power-domains
> From: Krzysztof Kozlowski > Sent: Friday, September 18, 2020 3:42 AM > > Add quite common property - power-domains - to fix dtbs_check warnings > like: > > arch/arm64/boot/dts/freescale/imx8qxp-mek.dt.yaml: > mailbox@5d28: 'power-domains' does not match any of the regexes: > 'pinctrl-[0-9]+' > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Dong Aisheng Regards Aisheng
RE: [PATCH V2 4/4] ARM: imx: cpuidle-imx7ulp: Stop mode disallowed when HSRUN
> From: Peng Fan
> Sent: Wednesday, September 16, 2020 10:49 AM
>
> When cpu runs in HSRUN mode, cpuidle is not allowed to run into Stop mode.
> So add imx7ulp_get_mode to get thr cpu run mode, and use WAIT mode
> instead, when cpu in HSRUN mode.
>
> Signed-off-by: Peng Fan
> ---
> arch/arm/mach-imx/common.h | 1 +
> arch/arm/mach-imx/cpuidle-imx7ulp.c | 14 +++---
> arch/arm/mach-imx/pm-imx7ulp.c | 10 ++
> 3 files changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
> index 72c3fcc32910..707ac650f1c2 100644
> --- a/arch/arm/mach-imx/common.h
> +++ b/arch/arm/mach-imx/common.h
> @@ -103,6 +103,7 @@ void imx6_set_int_mem_clk_lpm(bool enable); void
> imx6sl_set_wait_clk(bool enter); int imx_mmdc_get_ddr_type(void); int
> imx7ulp_set_lpm(enum ulp_cpu_pwr_mode mode);
> +u32 imx7ulp_get_mode(void);
>
> void imx_cpu_die(unsigned int cpu);
> int imx_cpu_kill(unsigned int cpu);
> diff --git a/arch/arm/mach-imx/cpuidle-imx7ulp.c
> b/arch/arm/mach-imx/cpuidle-imx7ulp.c
> index ca86c967d19e..e7009d10b331 100644
> --- a/arch/arm/mach-imx/cpuidle-imx7ulp.c
> +++ b/arch/arm/mach-imx/cpuidle-imx7ulp.c
> @@ -15,10 +15,18 @@
> static int imx7ulp_enter_wait(struct cpuidle_device *dev,
> struct cpuidle_driver *drv, int index) {
> - if (index == 1)
> + u32 mode;
> +
> + if (index == 1) {
> imx7ulp_set_lpm(ULP_PM_WAIT);
> - else
> - imx7ulp_set_lpm(ULP_PM_STOP);
> + } else {
> + mode = imx7ulp_get_mode();
> +
> + if (mode == 3)
Can we also put a comment above to ease the code reading?
Otherwise:
Reviewed-by: Dong Aisheng
Regards
Aisheng
> + imx7ulp_set_lpm(ULP_PM_WAIT);
> + else
> + imx7ulp_set_lpm(ULP_PM_STOP);
> + }
>
> cpu_do_idle();
>
> diff --git a/arch/arm/mach-imx/pm-imx7ulp.c
> b/arch/arm/mach-imx/pm-imx7ulp.c index 393faf1e8382..1410ccfc71bd
> 100644
> --- a/arch/arm/mach-imx/pm-imx7ulp.c
> +++ b/arch/arm/mach-imx/pm-imx7ulp.c
> @@ -63,6 +63,16 @@ int imx7ulp_set_lpm(enum ulp_cpu_pwr_mode mode)
> return 0;
> }
>
> +u32 imx7ulp_get_mode(void)
> +{
> + u32 mode;
> +
> + mode = readl_relaxed(smc1_base + SMC_PMCTRL) & BM_PMCTRL_RUNM;
> + mode >>= BP_PMCTRL_RUNM;
> +
> + return mode;
> +}
> +
> void __init imx7ulp_pm_init(void)
> {
> struct device_node *np;
> --
> 2.28.0
RE: [PATCH V2 3/4] ARM: imx: imx7ulp: support HSRUN mode
> From: Peng Fan
> Sent: Wednesday, September 16, 2020 10:49 AM
>
> Configure PMPROT to let ARM core could run into HSRUN mode.
> In LDO-enabled mode, HSRUN mode is not allowed, so add a check before
> configure PMPROT.
>
> Signed-off-by: Peng Fan
> ---
> arch/arm/mach-imx/pm-imx7ulp.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/arm/mach-imx/pm-imx7ulp.c
> b/arch/arm/mach-imx/pm-imx7ulp.c index 2e756d8191fa..393faf1e8382
> 100644
> --- a/arch/arm/mach-imx/pm-imx7ulp.c
> +++ b/arch/arm/mach-imx/pm-imx7ulp.c
> @@ -11,6 +11,10 @@
>
> #include "common.h"
>
> +#define PMC0_CTRL0x28
> +#define BM_CTRL_LDOENBIT(31)
> +
> +#define SMC_PMPROT 0x8
> #define SMC_PMCTRL 0x10
> #define BP_PMCTRL_PSTOPO16
> #define PSTOPO_PSTOP30x3
> @@ -25,7 +29,10 @@
> #define BM_PMCTRL_RUNM (3 << BP_PMCTRL_RUNM)
> #define BM_PMCTRL_STOPM (7 << BP_PMCTRL_STOPM)
>
> +#define BM_PMPROT_AHSRUN BIT(7)
> +
> static void __iomem *smc1_base;
> +static void __iomem *pmc0_base;
>
> int imx7ulp_set_lpm(enum ulp_cpu_pwr_mode mode) { @@ -65,5 +72,13
> @@ void __init imx7ulp_pm_init(void)
> of_node_put(np);
> WARN_ON(!smc1_base);
>
> + np = of_find_compatible_node(NULL, NULL, "fsl,imx7ulp-pmc0");
> + pmc0_base = of_iomap(np, 0);
> + WARN_ON(!pmc0_base);
> + of_node_put(np);
> +
> + if (!(readl_relaxed(pmc0_base + PMC0_CTRL) & BM_CTRL_LDOEN))
> + writel_relaxed(BM_PMPROT_AHSRUN, smc1_base + SMC_PMPROT);
When will HSRUN mode be enabled? E.g. RUNM=HSRUN
It seems RUNM will be cleared in the following imx7ulp_set_lpm().
Regards
Aisheng
> +
> imx7ulp_set_lpm(ULP_PM_RUN);
> }
> --
> 2.28.0
RE: [PATCH V2 2/4] ARM: dts: imx7ulp: add pmc node
> From: Peng Fan
> Sent: Wednesday, September 16, 2020 10:49 AM
>
> Add i.MX7ULP pmc node for m4 and a7.
>
> Signed-off-by: Peng Fan
> ---
> arch/arm/boot/dts/imx7ulp.dtsi | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx7ulp.dtsi b/arch/arm/boot/dts/imx7ulp.dtsi
> index b7ea37ad4e55..b02dc4c97fb8 100644
> --- a/arch/arm/boot/dts/imx7ulp.dtsi
> +++ b/arch/arm/boot/dts/imx7ulp.dtsi
> @@ -286,6 +286,11 @@ pcc2: clock-controller@403f {
> assigned-clock-parents = <
> IMX7ULP_CLK_SOSC_BUS_CLK>;
> };
>
> + pmc1: pmc1@4040 {
s/pmc1/pmc
> + compatible = "fsl,imx7ulp-pmc1";
> + reg = <0x4040 0x1000>;
> + };
> +
> smc1: clock-controller@4041 {
> compatible = "fsl,imx7ulp-smc1";
> reg = <0x4041 0x1000>;
> @@ -447,6 +452,11 @@ m4aips1: bus@4108 {
> reg = <0x4108 0x8>;
> ranges;
>
> + pmc0: pmc0@410a1000 {
s/pmc0/pmc
> + compatible = "fsl,imx7ulp-pmc0";
> + reg = <0x410a1000 0x1000>;
> + };
> +
> sim: sim@410a3000 {
> compatible = "fsl,imx7ulp-sim", "syscon";
> reg = <0x410a3000 0x1000>;
> --
> 2.28.0
RE: [PATCH V2 1/4] dt-bindings: fsl: add i.MX7ULP PMC
> From: Peng Fan > Sent: Wednesday, September 16, 2020 10:49 AM > > Update fsl,imx7ulp-pm.yaml to include pmc > > Signed-off-by: Peng Fan > --- > .../devicetree/bindings/arm/freescale/fsl,imx7ulp-pm.yaml | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-pm.yaml > b/Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-pm.yaml > index 3b26040f8f18..28ebaa8b1d1e 100644 > --- a/Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-pm.yaml > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-pm.yaml > @@ -23,7 +23,11 @@ description: | > > properties: >compatible: > -const: fsl,imx7ulp-smc1 > +items: > + - enum: > + - fsl,imx7ulp-smc1 > + - fsl,imx7ulp-pmc0 > + - fsl,imx7ulp-pmc1 Could you add Description for each of them? Regards Aisheng > >reg: > maxItems: 1 > -- > 2.28.0
RE: [PATCH v2 0/5] Add support of SECVIO from SNVS on iMX8q/x
> From: Shawn Guo > Sent: Wednesday, August 19, 2020 9:23 PM > > On Tue, Aug 18, 2020 at 09:52:02AM +0200, Franck LENORMAND (OSS) wrote: > > Hello, > > > > Peng was able to do a firt pass of review on my patchset which led to > > this second version. I hope a maintainer will be able to take a look > > at this patchset once rested after all the work they did for 5.9. > > @Peng, are you okay with this version? > > @Aisheng, have a review on this? Sorry, just noticed this. Will find a time to review these two days. Regards Aisheng > > Shawn > > > > > On mar., 2020-07-21 at 17:20 +0200, franck.lenorm...@oss.nxp.com wrote: > > > From: Franck LENORMAND > > > > > > This patchset aims to add support for the SECurity VIOlation > > > (SECVIO) of the SNVS. A secvio is a signal emitted by the SNVS when > > > a hardware attack is detected. On imx8x and imx8q SoC, the SNVS is > > > controlled by the SECO and it is possible to interact with it using the > > > SCU > using the SC APIs. > > > > > > For the driver to communicate with the SNVS via the SCU and the SECO, I > had to: > > >  - Add support for exchange of big message with the SCU (needed for > > > imx_scu_irq_get_status) > > >  - Add API to check linux can control the SECVIO > > > (imx_sc_rm_is_resource_owned) > > >  - Add APIs for the driver to read the state of the SECVIO registers > > > of the SNVS and DGO (imx_sc_seco_secvio_enable and > imx_sc_seco_secvio_enable). > > > > > > To check the state of the SECVIO IRQ in the SCU, I added the > > > imx_scu_irq_get_status API. > > > > > > The secvio driver is designed to receive the IRQ produced by the > > > SNVS in case of hardware attack and notify the status to the audit > > > framework which can be used by the user. > > > > > > The goal of the driver is to be self suficient but can be extended > > > by the user to perform custom operations on values read > > > (imx_sc_seco_secvio_enable) > > > > > > v2: > > >  - Removed (firmware: imx: scu-rm: Add Resource Management APIs) > > > -> Code required is already present > > >  - Removed (firmware: imx: scu: Support reception of messages of any size) > > > -> The imx-scu is already working in fast-ipc mode > > >  - (soc: imx8: Add the SC SECVIO driver): > > > - Fixed the warnings reported by kernel test robot > > > > > > Franck LENORMAND (5): > > >  firmware: imx: scu-seco: Add SEcure Controller APIS > > >  firmware: imx: scu-irq: Add API to retrieve status of IRQ > > >  dt-bindings: firmware: imx-scu: Add SECVIO resource > > >  dt-bindings: arm: imx: Documentation of the SC secvio driver > > >  soc: imx8: Add the SC SECVIO driver > > > > > >  .../bindings/arm/freescale/fsl,imx-sc-secvio.yaml  |  34 + > > >  drivers/firmware/imx/Makefile  |   2 +- > > >  drivers/firmware/imx/imx-scu-irq.c |  37 +- > > >  drivers/firmware/imx/imx-scu.c |   3 + > > >  drivers/firmware/imx/seco.c| 275 > +++ > > >  drivers/soc/imx/Kconfig|  10 + > > >  drivers/soc/imx/Makefile   |   1 + > > >  drivers/soc/imx/secvio/Kconfig |  10 + > > >  drivers/soc/imx/secvio/Makefile|   3 + > > >  drivers/soc/imx/secvio/imx-secvio-audit.c  |  39 + > > >  drivers/soc/imx/secvio/imx-secvio-debugfs.c| 379 + > > >  drivers/soc/imx/secvio/imx-secvio-sc-int.h |  84 ++ > > >  drivers/soc/imx/secvio/imx-secvio-sc.c | 858 > > > + > > >  include/dt-bindings/firmware/imx/rsrc.h|   3 +- > > >  include/linux/firmware/imx/ipc.h   |   1 + > > >  include/linux/firmware/imx/sci.h   |   5 + > > >  include/linux/firmware/imx/svc/seco.h  |  73 ++ > > >  include/soc/imx/imx-secvio-sc.h| 177 + > > >  18 files changed, 1991 insertions(+), 3 deletions(-) > > >  create mode 100644 > > > Documentation/devicetree/bindings/arm/freescale/fsl,imx-sc- > > > secvio.yaml > > >  create mode 100644 drivers/firmware/imx/seco.c > > >  create mode 100644 drivers/soc/imx/secvio/Kconfig > > >  create mode 100644 drivers/soc/imx/secvio/Makefile > > >  create mode 100644 drivers/soc/imx/secvio/imx-secvio-audit.c > > >  create mode 100644 drivers/soc/imx/secvio/imx-secvio-debugfs.c > > >  create mode 100644 drivers/soc/imx/secvio/imx-secvio-sc-int.h > > >  create mode 100644 drivers/soc/imx/secvio/imx-secvio-sc.c > > >  create mode 100644 include/linux/firmware/imx/svc/seco.h > > >  create mode 100644 include/soc/imx/imx-secvio-sc.h > > > > >
RE: [PATCH 1/4] dt-bindings: fsl: add i.MX7ULP PMC binding doc
> From: Peng Fan
> Sent: Friday, September 11, 2020 3:45 PM
>
> > Subject: RE: [PATCH 1/4] dt-bindings: fsl: add i.MX7ULP PMC binding
> > doc
> >
> > > From: Peng Fan
> > > Sent: Friday, September 11, 2020 11:31 AM
> > >
> > > Add i.MX7ULP Power Management Controller binding doc
> > >
> > > Signed-off-by: Peng Fan
> > > ---
> > > .../bindings/arm/freescale/imx7ulp-pmc.yaml | 33
> > +++
> > > 1 file changed, 33 insertions(+)
> > > create mode 100644
> > > Documentation/devicetree/bindings/arm/freescale/imx7ulp-pmc.yaml
> >
> > I wonder if we can merge it into the exist imx7ulp pm binding doc.
> > Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-pm.yaml
>
> Not sure about this.
>
If not merge, we probably need change the name of existing pm binding doc to
avoid confusing.
e.g.
fsl,imx7ulp-pm.yaml -> fsl,imx7ulp-smc.yaml.
> >
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/arm/freescale/imx7ulp-pmc.yaml
> > > b/Documentation/devicetree/bindings/arm/freescale/imx7ulp-pmc.yaml
> > > new file mode 100644
> > > index ..33a31d87dd62
> > > --- /dev/null
> > > +++
> > b/Documentation/devicetree/bindings/arm/freescale/imx7ulp-pmc.yaml
> > > @@ -0,0 +1,33 @@
> > > +# SPDX-License-Identifier: GPL-2.0
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/arm/freescale/imx7ulp-pmc.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: i.MX7ULP Power Management Controller(PMC) Device Tree
> > > +Bindings
> > > +
> > > +maintainers:
> > > + - Peng Fan
> > > +
> > > +properties:
> > > + compatible:
> > > +items:
> > > + - enum:
> > > + - fsl,imx7ulp-pmc-m4
> > > + - fsl,imx7ulp-pmc-a7
> >
> > Can we change to the exist naming pattern which also align with HW
> > reference manual?
> > e.g.
> > fsl,imx7ulp-pmc0
> > fsl,imx7ulp-pmc1
>
> This was rejected by Shawn before.
> https://patchwork.kernel.org/patch/11390591/
I didn't see NACK from Shawn from above URL.
Shawn seemed to just ask for some clarifications why need number suffix.
Am I missed something?
Regards
Aisheng
>
> Thanks,
> Peng.
>
> >
> > Aligned with:
> > fsl,imx7ulp-smc1
> > fsl,imx7ulp-pcc2
> > fsl,imx7ulp-scg1
> >
> > Regards
> > Aisheng
> >
> > > +
> > > + reg:
> > > +maxItems: 1
> > > +
> > > +required:
> > > + - compatible
> > > + - reg
> > > +
> > > +additionalProperties: false
> > > +
> > > +examples:
> > > + - |
> > > +pmc0: pmc-m4@410a1000 {
> > > +compatible = "fsl,imx7ulp-pmc-m4";
> > > +reg = <0x410a1000 0x1000>;
> > > +};
> > > --
> > > 2.28.0
RE: [PATCH v3 03/14] dt-bindings: clock: imx8mp: Add ids for the audio shared gate
> From: Abel Vesa > Sent: Tuesday, September 8, 2020 6:25 PM > > All these IDs are for one single HW gate (CCGR101) that is shared between > these > root clocks. > > Signed-off-by: Abel Vesa > Acked-by: Rob Herring Seems missed my tag. So: Reviewed-by: Dong Aisheng Regards Aisheng > --- > include/dt-bindings/clock/imx8mp-clock.h | 12 +++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > diff --git a/include/dt-bindings/clock/imx8mp-clock.h > b/include/dt-bindings/clock/imx8mp-clock.h > index 89c67b7..5fc2c40 100644 > --- a/include/dt-bindings/clock/imx8mp-clock.h > +++ b/include/dt-bindings/clock/imx8mp-clock.h > @@ -322,7 +322,17 @@ > #define IMX8MP_CLK_HSIO_AXI 311 > #define IMX8MP_CLK_MEDIA_ISP 312 > > -#define IMX8MP_CLK_END 313 > +#define IMX8MP_CLK_AUDIO_AHB_ROOT313 > +#define IMX8MP_CLK_AUDIO_AXI_ROOT314 > +#define IMX8MP_CLK_SAI1_ROOT 315 > +#define IMX8MP_CLK_SAI2_ROOT 316 > +#define IMX8MP_CLK_SAI3_ROOT 317 > +#define IMX8MP_CLK_SAI5_ROOT 318 > +#define IMX8MP_CLK_SAI6_ROOT 319 > +#define IMX8MP_CLK_SAI7_ROOT 320 > +#define IMX8MP_CLK_PDM_ROOT 321 > + > +#define IMX8MP_CLK_END 322 > > #define IMX8MP_CLK_AUDIO_BLK_CTL_SAI1_IPG0 > #define IMX8MP_CLK_AUDIO_BLK_CTL_SAI1_MCLK1 1 > -- > 2.7.4
RE: [PATCH v3 06/14] dt-bindings: clock: imx8mp: Add hdmi blk_ctl clock IDs
> From: Abel Vesa > Sent: Tuesday, September 8, 2020 6:25 PM > > These will be used by the imx8mp for blk_ctl driver. > > Signed-off-by: Abel Vesa > Acked-by: Rob Herring Reviewed-by: Dong Aisheng Regards Aisheng > --- > include/dt-bindings/clock/imx8mp-clock.h | 40 > > 1 file changed, 40 insertions(+) > > diff --git a/include/dt-bindings/clock/imx8mp-clock.h > b/include/dt-bindings/clock/imx8mp-clock.h > index 12632fa..de7d522 100644 > --- a/include/dt-bindings/clock/imx8mp-clock.h > +++ b/include/dt-bindings/clock/imx8mp-clock.h > @@ -424,4 +424,44 @@ > > #define IMX8MP_CLK_MEDIA_BLK_CTL_END 25 > > +#define IMX8MP_CLK_HDMI_BLK_CTL_GLOBAL_APB_CLK 0 > +#define IMX8MP_CLK_HDMI_BLK_CTL_GLOBAL_B_CLK 1 > +#define IMX8MP_CLK_HDMI_BLK_CTL_GLOBAL_REF266M_CLK 2 > +#define IMX8MP_CLK_HDMI_BLK_CTL_GLOBAL_XTAL24M_CLK 3 > +#define IMX8MP_CLK_HDMI_BLK_CTL_GLOBAL_XTAL32K_CLK 4 > +#define IMX8MP_CLK_HDMI_BLK_CTL_GLOBAL_TX_PIX_CLK5 > +#define IMX8MP_CLK_HDMI_BLK_CTL_IRQS_STEER_CLK 6 > +#define IMX8MP_CLK_HDMI_BLK_CTL_NOC_HDMI_CLK 7 > +#define IMX8MP_CLK_HDMI_BLK_CTL_NOC_HDCP_CLK 8 > +#define IMX8MP_CLK_HDMI_BLK_CTL_LCDIF_APB_CLK9 > +#define IMX8MP_CLK_HDMI_BLK_CTL_LCDIF_B_CLK 10 > +#define IMX8MP_CLK_HDMI_BLK_CTL_LCDIF_PDI_CLK11 > +#define IMX8MP_CLK_HDMI_BLK_CTL_LCDIF_PIX_CLK12 > +#define IMX8MP_CLK_HDMI_BLK_CTL_LCDIF_SPU_CLK13 > +#define IMX8MP_CLK_HDMI_BLK_CTL_FDCC_REF_CLK 14 > +#define IMX8MP_CLK_HDMI_BLK_CTL_HRV_MWR_APB_CLK 15 > +#define IMX8MP_CLK_HDMI_BLK_CTL_HRV_MWR_B_CLK16 > +#define IMX8MP_CLK_HDMI_BLK_CTL_HRV_MWR_CEA_CLK 17 > +#define IMX8MP_CLK_HDMI_BLK_CTL_VSFD_CEA_CLK 18 > +#define IMX8MP_CLK_HDMI_BLK_CTL_TX_HPI_CLK 19 > +#define IMX8MP_CLK_HDMI_BLK_CTL_TX_APB_CLK 20 > +#define IMX8MP_CLK_HDMI_BLK_CTL_TX_CEC_CLK 21 > +#define IMX8MP_CLK_HDMI_BLK_CTL_TX_ESM_CLK 22 > +#define IMX8MP_CLK_HDMI_BLK_CTL_TX_GPA_CLK 23 > +#define IMX8MP_CLK_HDMI_BLK_CTL_TX_PIXEL_CLK 24 > +#define IMX8MP_CLK_HDMI_BLK_CTL_TX_SFR_CLK 25 > +#define IMX8MP_CLK_HDMI_BLK_CTL_TX_SKP_CLK 26 > +#define IMX8MP_CLK_HDMI_BLK_CTL_TX_PREP_CLK 27 > +#define IMX8MP_CLK_HDMI_BLK_CTL_TX_PHY_APB_CLK 28 > +#define IMX8MP_CLK_HDMI_BLK_CTL_TX_PHY_INT_CLK 29 > +#define IMX8MP_CLK_HDMI_BLK_CTL_TX_SEC_MEM_CLK 30 > +#define IMX8MP_CLK_HDMI_BLK_CTL_TX_TRNG_SKP_CLK 31 > +#define IMX8MP_CLK_HDMI_BLK_CTL_TX_VID_LINK_PIX_CLK 32 > +#define IMX8MP_CLK_HDMI_BLK_CTL_TX_TRNG_APB_CLK 33 > +#define IMX8MP_CLK_HDMI_BLK_CTL_HTXPHY_CLK_SEL 34 > +#define IMX8MP_CLK_HDMI_BLK_CTL_LCDIF_CLK_SEL35 > +#define IMX8MP_CLK_HDMI_BLK_CTL_TX_PIPE_CLK_SEL 36 > + > +#define IMX8MP_CLK_HDMI_BLK_CTL_END 37 > + > #endif > -- > 2.7.4
RE: [PATCH 1/4] dt-bindings: fsl: add i.MX7ULP PMC binding doc
> From: Peng Fan
> Sent: Friday, September 11, 2020 11:31 AM
>
> Add i.MX7ULP Power Management Controller binding doc
>
> Signed-off-by: Peng Fan
> ---
> .../bindings/arm/freescale/imx7ulp-pmc.yaml | 33 +++
> 1 file changed, 33 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/arm/freescale/imx7ulp-pmc.yaml
I wonder if we can merge it into the exist imx7ulp pm binding doc.
Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-pm.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/arm/freescale/imx7ulp-pmc.yaml
> b/Documentation/devicetree/bindings/arm/freescale/imx7ulp-pmc.yaml
> new file mode 100644
> index ..33a31d87dd62
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/freescale/imx7ulp-pmc.yaml
> @@ -0,0 +1,33 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/freescale/imx7ulp-pmc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: i.MX7ULP Power Management Controller(PMC) Device Tree Bindings
> +
> +maintainers:
> + - Peng Fan
> +
> +properties:
> + compatible:
> +items:
> + - enum:
> + - fsl,imx7ulp-pmc-m4
> + - fsl,imx7ulp-pmc-a7
Can we change to the exist naming pattern which also align with HW reference
manual?
e.g.
fsl,imx7ulp-pmc0
fsl,imx7ulp-pmc1
Aligned with:
fsl,imx7ulp-smc1
fsl,imx7ulp-pcc2
fsl,imx7ulp-scg1
Regards
Aisheng
> +
> + reg:
> +maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +pmc0: pmc-m4@410a1000 {
> +compatible = "fsl,imx7ulp-pmc-m4";
> +reg = <0x410a1000 0x1000>;
> +};
> --
> 2.28.0
RE: [PATCH] ARM: imx7ulp: enable cpufreq
> From: Peng Fan > Sent: Friday, September 11, 2020 11:32 AM > > > Enable cpufreq for i.MX7ULP when imx cpufreq dt driver enabled. > > Signed-off-by: Peng Fan Reviewed-by: Dong Aisheng Regards Aisheng
RE: [PATCH V4 2/3] pinctrl: imx: Support building SCU pinctrl core driver as module
> From: Anson Huang
> Sent: Tuesday, September 8, 2020 4:12 PM
>
> Change PINCTR_IMX_SCU to tristate, add module author, description and
> license to support building SCU pinctrl core driver as module.
>
> Signed-off-by: Anson Huang
> ---
> changes since V3:
> - remove the prompt for PINCTRL_IMX_SCU.
Good suggestion from Arnd.
Reviewed-by: Dong Aisheng
Regards
Aisheng
> ---
> drivers/pinctrl/freescale/Kconfig | 2 +-
> drivers/pinctrl/freescale/pinctrl-scu.c | 5 +
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/freescale/Kconfig
> b/drivers/pinctrl/freescale/Kconfig
> index 08fcf5c..7198916 100644
> --- a/drivers/pinctrl/freescale/Kconfig
> +++ b/drivers/pinctrl/freescale/Kconfig
> @@ -7,7 +7,7 @@ config PINCTRL_IMX
> select REGMAP
>
> config PINCTRL_IMX_SCU
> - bool
> + tristate
> depends on IMX_SCU
> select PINCTRL_IMX
>
> diff --git a/drivers/pinctrl/freescale/pinctrl-scu.c
> b/drivers/pinctrl/freescale/pinctrl-scu.c
> index 9df45d3..59b5f8a 100644
> --- a/drivers/pinctrl/freescale/pinctrl-scu.c
> +++ b/drivers/pinctrl/freescale/pinctrl-scu.c
> @@ -7,6 +7,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -123,3 +124,7 @@ void imx_pinctrl_parse_pin_scu(struct imx_pinctrl
> *ipctl,
> pin_scu->mux_mode, pin_scu->config);
> }
> EXPORT_SYMBOL_GPL(imx_pinctrl_parse_pin_scu);
> +
> +MODULE_AUTHOR("Dong Aisheng ");
> +MODULE_DESCRIPTION("NXP i.MX SCU common pinctrl driver");
> +MODULE_LICENSE("GPL v2");
> --
> 2.7.4
RE: [PATCH V4 1/3] pinctrl: imx: Use function callbacks for SCU related functions
> From: Anson Huang
> Sent: Tuesday, September 8, 2020 4:12 PM
>
> Use function callbacks for SCU related functions in pinctrl-imx.c in order to
> support the scenario of PINCTRL_IMX is built in while PINCTRL_IMX_SCU is built
> as module, all drivers using SCU pinctrl driver need to initialize the SCU
> related
> function callback, and no need to check CONFIG_PINCTRL_IMX_SCU anymore,
> hence stub functions also can be removed.
>
> Signed-off-by: Anson Huang
Reviewed-by: Dong Aisheng
Regards
Aisheng
> ---
> No change.
> ---
> drivers/pinctrl/freescale/pinctrl-imx.c | 8 ++--
> drivers/pinctrl/freescale/pinctrl-imx.h | 57
> +++--
> drivers/pinctrl/freescale/pinctrl-imx8dxl.c | 3 ++
> drivers/pinctrl/freescale/pinctrl-imx8qm.c | 3 ++
> drivers/pinctrl/freescale/pinctrl-imx8qxp.c | 3 ++
> 5 files changed, 35 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c
> b/drivers/pinctrl/freescale/pinctrl-imx.c
> index 507e4af..b80c450 100644
> --- a/drivers/pinctrl/freescale/pinctrl-imx.c
> +++ b/drivers/pinctrl/freescale/pinctrl-imx.c
> @@ -373,7 +373,7 @@ static int imx_pinconf_get(struct pinctrl_dev *pctldev,
> const struct imx_pinctrl_soc_info *info = ipctl->info;
>
> if (info->flags & IMX_USE_SCU)
> - return imx_pinconf_get_scu(pctldev, pin_id, config);
> + return info->imx_pinconf_get(pctldev, pin_id, config);
> else
> return imx_pinconf_get_mmio(pctldev, pin_id, config); } @@
> -423,7
> +423,7 @@ static int imx_pinconf_set(struct pinctrl_dev *pctldev,
> const struct imx_pinctrl_soc_info *info = ipctl->info;
>
> if (info->flags & IMX_USE_SCU)
> - return imx_pinconf_set_scu(pctldev, pin_id,
> + return info->imx_pinconf_set(pctldev, pin_id,
> configs, num_configs);
> else
> return imx_pinconf_set_mmio(pctldev, pin_id, @@ -440,7 +440,7
> @@ static void imx_pinconf_dbg_show(struct pinctrl_dev *pctldev,
> int ret;
>
> if (info->flags & IMX_USE_SCU) {
> - ret = imx_pinconf_get_scu(pctldev, pin_id, );
> + ret = info->imx_pinconf_get(pctldev, pin_id, );
> if (ret) {
> dev_err(ipctl->dev, "failed to get %s pinconf\n",
> pin_get_name(pctldev, pin_id));
> @@ -629,7 +629,7 @@ static int imx_pinctrl_parse_groups(struct device_node
> *np,
> for (i = 0; i < grp->num_pins; i++) {
> pin = &((struct imx_pin *)(grp->data))[i];
> if (info->flags & IMX_USE_SCU)
> - imx_pinctrl_parse_pin_scu(ipctl, >pins[i],
> + info->imx_pinctrl_parse_pin(ipctl, >pins[i],
> pin, );
> else
> imx_pinctrl_parse_pin_mmio(ipctl, >pins[i], diff
> --git
> a/drivers/pinctrl/freescale/pinctrl-imx.h
> b/drivers/pinctrl/freescale/pinctrl-imx.h
> index 333d32b..fd8c4b6 100644
> --- a/drivers/pinctrl/freescale/pinctrl-imx.h
> +++ b/drivers/pinctrl/freescale/pinctrl-imx.h
> @@ -75,6 +75,21 @@ struct imx_cfg_params_decode {
> bool invert;
> };
>
> +/**
> + * @dev: a pointer back to containing device
> + * @base: the offset to the controller in virtual memory */ struct
> +imx_pinctrl {
> + struct device *dev;
> + struct pinctrl_dev *pctl;
> + void __iomem *base;
> + void __iomem *input_sel_base;
> + const struct imx_pinctrl_soc_info *info;
> + struct imx_pin_reg *pin_regs;
> + unsigned int group_index;
> + struct mutex mutex;
> +};
> +
> struct imx_pinctrl_soc_info {
> const struct pinctrl_pin_desc *pins;
> unsigned int npins;
> @@ -98,21 +113,13 @@ struct imx_pinctrl_soc_info {
> struct pinctrl_gpio_range *range,
> unsigned offset,
> bool input);
> -};
> -
> -/**
> - * @dev: a pointer back to containing device
> - * @base: the offset to the controller in virtual memory
> - */
> -struct imx_pinctrl {
> - struct device *dev;
> - struct pinctrl_dev *pctl;
> - void __iomem *base;
> - void __iomem *input_sel_base;
> - const struct imx_pinctrl_soc_info *info;
> - struct imx_pin_reg *pin_regs;
> - unsigned int group_index;
> - struct mutex mutex;
> + int (*imx_pinconf_get)(struct pinctrl_dev *pctldev, unsigned int pin_id,
> +unsigned long *config);
> + int (*imx_pinconf_set)(struct pinctrl_dev *pctldev, unsigned int pin_id,
> +unsigned long *configs, unsigned int
> num_configs);
> + void (*imx_pinctrl_parse_pin)(struct imx_pinctrl *ipctl,
> + unsigned int *pin_id, struct imx_pin *pin,
> + const __be32 **list_p);
> };
>
> #define IMX_CFG_PARAMS_DECODE(p, m,
RE: [PATCH V2 3/3] pinctrl: imx: Support building i.MX pinctrl core driver as module
> From: Anson Huang > Sent: Monday, September 7, 2020 8:33 PM > > Change PINCTRL_IMX to tristate to support loadable module build. > > And i.MX common pinctrl driver should depend on CONFIG_OF to make sure no > build error when i.MX common pinctrl driver is enabled for different > architectures without CONFIG_OF. > > Also add module author, description and license. > > Signed-off-by: Anson Huang Reviewed-by: Dong Aisheng Regards Aisheng
RE: [PATCH V2 2/3] pinctrl: imx: Support building SCU pinctrl core driver as module
> From: Anson Huang
> Sent: Monday, September 7, 2020 8:33 PM
>
> Change PINCTR_IMX_SCU to tristate, remove unnecessary #ifdef and add
> module author, description and license to support building SCU pinctrl core
> driver as module.
>
> Signed-off-by: Anson Huang
> ---
> Changes since V1:
> - split V1 [1/2] patch to 2 patches, this patch supports building SCU
> pinctrl
> core
> driver as module;
> - remove unnecessary #ifdef check and #else block.
> ---
> drivers/pinctrl/freescale/Kconfig | 2 +-
> drivers/pinctrl/freescale/pinctrl-imx.h | 20
> drivers/pinctrl/freescale/pinctrl-scu.c | 5 +
> 3 files changed, 6 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/pinctrl/freescale/Kconfig
> b/drivers/pinctrl/freescale/Kconfig
> index 08fcf5c..452c499 100644
> --- a/drivers/pinctrl/freescale/Kconfig
> +++ b/drivers/pinctrl/freescale/Kconfig
> @@ -7,7 +7,7 @@ config PINCTRL_IMX
> select REGMAP
>
> config PINCTRL_IMX_SCU
> - bool
> + tristate "IMX SCU pinctrl core driver"
> depends on IMX_SCU
> select PINCTRL_IMX
>
[...]
> diff --git a/drivers/pinctrl/freescale/pinctrl-imx.h
> b/drivers/pinctrl/freescale/pinctrl-imx.h
> index 40927ca..fd8c4b6 100644
> --- a/drivers/pinctrl/freescale/pinctrl-imx.h
> +++ b/drivers/pinctrl/freescale/pinctrl-imx.h
> @@ -144,7 +144,6 @@ struct imx_pinctrl_soc_info { int
> imx_pinctrl_probe(struct platform_device *pdev,
> const struct imx_pinctrl_soc_info *info);
>
> -#ifdef CONFIG_PINCTRL_IMX_SCU
> #define BM_PAD_CTL_GP_ENABLE BIT(30)
> #define BM_PAD_CTL_IFMUX_ENABLE BIT(31)
> #define BP_PAD_CTL_IFMUX 27
> @@ -157,23 +156,4 @@ int imx_pinconf_set_scu(struct pinctrl_dev *pctldev,
> unsigned pin_id, void imx_pinctrl_parse_pin_scu(struct imx_pinctrl *ipctl,
> unsigned int *pin_id, struct imx_pin *pin,
> const __be32 **list_p);
> -#else
> -static inline int imx_pinconf_get_scu(struct pinctrl_dev *pctldev,
> - unsigned pin_id, unsigned long *config)
> -{
> - return -EINVAL;
> -}
> -static inline int imx_pinconf_set_scu(struct pinctrl_dev *pctldev,
> - unsigned pin_id, unsigned long *configs,
> - unsigned num_configs)
> -{
> - return -EINVAL;
> -}
> -static inline void imx_pinctrl_parse_pin_scu(struct imx_pinctrl *ipctl,
> - unsigned int *pin_id,
> - struct imx_pin *pin,
> - const __be32 **list_p)
> -{
> -}
> -#endif
> #endif /* __DRIVERS_PINCTRL_IMX_H */
Should this part of changes go to Patch 1?
> diff --git a/drivers/pinctrl/freescale/pinctrl-scu.c
> b/drivers/pinctrl/freescale/pinctrl-scu.c
> index 9df45d3..59b5f8a 100644
> --- a/drivers/pinctrl/freescale/pinctrl-scu.c
> +++ b/drivers/pinctrl/freescale/pinctrl-scu.c
> @@ -7,6 +7,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -123,3 +124,7 @@ void imx_pinctrl_parse_pin_scu(struct imx_pinctrl
> *ipctl,
> pin_scu->mux_mode, pin_scu->config);
> }
> EXPORT_SYMBOL_GPL(imx_pinctrl_parse_pin_scu);
> +
> +MODULE_AUTHOR("Dong Aisheng ");
> +MODULE_DESCRIPTION("NXP i.MX SCU common pinctrl driver");
> +MODULE_LICENSE("GPL v2");
> --
> 2.7.4
RE: [PATCH V2 1/3] pinctrl: imx: Use function callbacks for SCU related functions
> From: Anson Huang
> Sent: Monday, September 7, 2020 8:33 PM
>
> Use function callbacks for SCU related functions in pinctrl-imx.c in order to
> support the scenario of PINCTRL_IMX is built in while PINCTRL_IMX_SCU is built
> as module, all drivers using SCU pinctrl driver need to initialize the SCU
> related
> function callback.
>
> Signed-off-by: Anson Huang
> ---
> Changes since V1:
> - split V1 [1/2] patch to 2 patches, this patch does the change of using
> function
> callbacks for SCU related functions.
> ---
> drivers/pinctrl/freescale/pinctrl-imx.c | 8 +++
> drivers/pinctrl/freescale/pinctrl-imx.h | 37
> +
> drivers/pinctrl/freescale/pinctrl-imx8dxl.c | 3 +++
> drivers/pinctrl/freescale/pinctrl-imx8qm.c | 3 +++
> drivers/pinctrl/freescale/pinctrl-imx8qxp.c | 3 +++
> 5 files changed, 35 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c
> b/drivers/pinctrl/freescale/pinctrl-imx.c
> index 507e4af..b80c450 100644
> --- a/drivers/pinctrl/freescale/pinctrl-imx.c
> +++ b/drivers/pinctrl/freescale/pinctrl-imx.c
> @@ -373,7 +373,7 @@ static int imx_pinconf_get(struct pinctrl_dev *pctldev,
> const struct imx_pinctrl_soc_info *info = ipctl->info;
>
> if (info->flags & IMX_USE_SCU)
> - return imx_pinconf_get_scu(pctldev, pin_id, config);
> + return info->imx_pinconf_get(pctldev, pin_id, config);
> else
> return imx_pinconf_get_mmio(pctldev, pin_id, config); } @@
> -423,7
> +423,7 @@ static int imx_pinconf_set(struct pinctrl_dev *pctldev,
> const struct imx_pinctrl_soc_info *info = ipctl->info;
>
> if (info->flags & IMX_USE_SCU)
> - return imx_pinconf_set_scu(pctldev, pin_id,
> + return info->imx_pinconf_set(pctldev, pin_id,
> configs, num_configs);
> else
> return imx_pinconf_set_mmio(pctldev, pin_id, @@ -440,7 +440,7
> @@ static void imx_pinconf_dbg_show(struct pinctrl_dev *pctldev,
> int ret;
>
> if (info->flags & IMX_USE_SCU) {
> - ret = imx_pinconf_get_scu(pctldev, pin_id, );
> + ret = info->imx_pinconf_get(pctldev, pin_id, );
> if (ret) {
> dev_err(ipctl->dev, "failed to get %s pinconf\n",
> pin_get_name(pctldev, pin_id));
> @@ -629,7 +629,7 @@ static int imx_pinctrl_parse_groups(struct device_node
> *np,
> for (i = 0; i < grp->num_pins; i++) {
> pin = &((struct imx_pin *)(grp->data))[i];
> if (info->flags & IMX_USE_SCU)
> - imx_pinctrl_parse_pin_scu(ipctl, >pins[i],
> + info->imx_pinctrl_parse_pin(ipctl, >pins[i],
> pin, );
> else
> imx_pinctrl_parse_pin_mmio(ipctl, >pins[i], diff
> --git
> a/drivers/pinctrl/freescale/pinctrl-imx.h
> b/drivers/pinctrl/freescale/pinctrl-imx.h
> index 333d32b..40927ca 100644
> --- a/drivers/pinctrl/freescale/pinctrl-imx.h
> +++ b/drivers/pinctrl/freescale/pinctrl-imx.h
> @@ -75,6 +75,21 @@ struct imx_cfg_params_decode {
> bool invert;
> };
>
> +/**
> + * @dev: a pointer back to containing device
> + * @base: the offset to the controller in virtual memory */ struct
> +imx_pinctrl {
> + struct device *dev;
> + struct pinctrl_dev *pctl;
> + void __iomem *base;
> + void __iomem *input_sel_base;
> + const struct imx_pinctrl_soc_info *info;
> + struct imx_pin_reg *pin_regs;
> + unsigned int group_index;
> + struct mutex mutex;
> +};
> +
You seems missed my question in the former patch review.
Could you clarify a bit why need move this part code?
Regards
Aisheng
> struct imx_pinctrl_soc_info {
> const struct pinctrl_pin_desc *pins;
> unsigned int npins;
> @@ -98,21 +113,13 @@ struct imx_pinctrl_soc_info {
> struct pinctrl_gpio_range *range,
> unsigned offset,
> bool input);
> -};
> -
> -/**
> - * @dev: a pointer back to containing device
> - * @base: the offset to the controller in virtual memory
> - */
> -struct imx_pinctrl {
> - struct device *dev;
> - struct pinctrl_dev *pctl;
> - void __iomem *base;
> - void __iomem *input_sel_base;
> - const struct imx_pinctrl_soc_info *info;
> - struct imx_pin_reg *pin_regs;
> - unsigned int group_index;
> - struct mutex mutex;
> + int (*imx_pinconf_get)(struct pinctrl_dev *pctldev, unsigned int pin_id,
> +unsigned long *config);
> + int (*imx_pinconf_set)(struct pinctrl_dev *pctldev, unsigned int pin_id,
> +unsigned long *configs, unsigned int
> num_configs);
> + void (*imx_pinctrl_parse_pin)(struct imx_pinctrl *ipctl,
> + unsigned int
RE: [PATCH 2/2] pinctrl: imx: Support building i.MX pinctrl driver as module
> From: Anson Huang
> Sent: Thursday, July 16, 2020 11:07 PM
> Subject: [PATCH 2/2] pinctrl: imx: Support building i.MX pinctrl driver as
> module
>
S/pinctrl driver/pinctrl core driver
This also applies for Patch 1/2.
> Change PINCTRL_IMX to tristate to support loadable module build.
>
> And i.MX common pinctrl driver should depend on CONFIG_OF to make sure no
> build error when i.MX common pinctrl driver is enabled for different
> architectures without CONFIG_OF.
>
> Also add module author, description and license.
>
> Signed-off-by: Anson Huang
> ---
> drivers/pinctrl/freescale/Kconfig | 3 ++-
> drivers/pinctrl/freescale/pinctrl-imx.c | 5 +
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/freescale/Kconfig
> b/drivers/pinctrl/freescale/Kconfig
> index 570355c..922ae4b 100644
> --- a/drivers/pinctrl/freescale/Kconfig
> +++ b/drivers/pinctrl/freescale/Kconfig
> @@ -1,6 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0-only config PINCTRL_IMX
> - bool
> + tristate "IMX pinctrl driver"
IMX pinctrl core driver
> + depends on OF
> select GENERIC_PINCTRL_GROUPS
> select GENERIC_PINMUX_FUNCTIONS
> select GENERIC_PINCONF
> diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c
> b/drivers/pinctrl/freescale/pinctrl-imx.c
> index b80c450..3eaafb6 100644
> --- a/drivers/pinctrl/freescale/pinctrl-imx.c
> +++ b/drivers/pinctrl/freescale/pinctrl-imx.c
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -898,3 +899,7 @@ const struct dev_pm_ops imx_pinctrl_pm_ops = {
> imx_pinctrl_resume)
> };
> EXPORT_SYMBOL_GPL(imx_pinctrl_pm_ops);
> +
> +MODULE_AUTHOR("Linus Walleij ");
MODULE_AUTHOR("Dong Aisheng ");
Regards
Aisheng
> +MODULE_DESCRIPTION("NXP i.MX common pinctrl driver");
> +MODULE_LICENSE("GPL v2");
> --
> 2.7.4
RE: [PATCH 1/2] pinctrl: imx: Support building SCU pinctrl driver as module
> From: Anson Huang
> Sent: Thursday, July 16, 2020 11:07 PM
> Subject: [PATCH 1/2] pinctrl: imx: Support building SCU pinctrl driver as
> module
>
> To support building i.MX SCU pinctrl driver as module, below things need to be
> changed:
>
> - Export SCU related functions
This line seems not comply with the patch anymore
> and use "IS_ENABLED" instead of
> "ifdef" to support SCU pinctrl driver user and itself to be
> built as module;
> - Use function callbacks for SCU related functions in pinctrl-imx.c
> in order to support the scenario of PINCTRL_IMX is built in
> while PINCTRL_IMX_SCU is built as module;
> - All drivers using SCU pinctrl driver need to initialize the
> SCU related function callback;
> - Change PINCTR_IMX_SCU to tristate;
> - Add module author, description and license.
>
> With above changes, i.MX SCU pinctrl driver can be built as module.
>
> Signed-off-by: Anson Huang
> ---
> drivers/pinctrl/freescale/Kconfig | 2 +-
> drivers/pinctrl/freescale/pinctrl-imx.c | 8 ++--
> drivers/pinctrl/freescale/pinctrl-imx.h | 57
> -
> drivers/pinctrl/freescale/pinctrl-imx8dxl.c | 3 ++
> drivers/pinctrl/freescale/pinctrl-imx8qm.c | 3 ++
> drivers/pinctrl/freescale/pinctrl-imx8qxp.c | 3 ++
> drivers/pinctrl/freescale/pinctrl-scu.c | 5 +++
> 7 files changed, 42 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/pinctrl/freescale/Kconfig
> b/drivers/pinctrl/freescale/Kconfig
> index 08fcf5c..570355c 100644
> --- a/drivers/pinctrl/freescale/Kconfig
> +++ b/drivers/pinctrl/freescale/Kconfig
> @@ -7,7 +7,7 @@ config PINCTRL_IMX
> select REGMAP
>
> config PINCTRL_IMX_SCU
> - bool
> + tristate "IMX SCU pinctrl driver"
IMX SCU pinctrl core driver
> depends on IMX_SCU
> select PINCTRL_IMX
>
> diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c
> b/drivers/pinctrl/freescale/pinctrl-imx.c
> index 507e4af..b80c450 100644
> --- a/drivers/pinctrl/freescale/pinctrl-imx.c
> +++ b/drivers/pinctrl/freescale/pinctrl-imx.c
> @@ -373,7 +373,7 @@ static int imx_pinconf_get(struct pinctrl_dev *pctldev,
> const struct imx_pinctrl_soc_info *info = ipctl->info;
>
> if (info->flags & IMX_USE_SCU)
> - return imx_pinconf_get_scu(pctldev, pin_id, config);
> + return info->imx_pinconf_get(pctldev, pin_id, config);
> else
> return imx_pinconf_get_mmio(pctldev, pin_id, config); } @@
> -423,7
> +423,7 @@ static int imx_pinconf_set(struct pinctrl_dev *pctldev,
> const struct imx_pinctrl_soc_info *info = ipctl->info;
>
> if (info->flags & IMX_USE_SCU)
> - return imx_pinconf_set_scu(pctldev, pin_id,
> + return info->imx_pinconf_set(pctldev, pin_id,
> configs, num_configs);
> else
> return imx_pinconf_set_mmio(pctldev, pin_id, @@ -440,7 +440,7
> @@ static void imx_pinconf_dbg_show(struct pinctrl_dev *pctldev,
> int ret;
>
> if (info->flags & IMX_USE_SCU) {
> - ret = imx_pinconf_get_scu(pctldev, pin_id, );
> + ret = info->imx_pinconf_get(pctldev, pin_id, );
> if (ret) {
> dev_err(ipctl->dev, "failed to get %s pinconf\n",
> pin_get_name(pctldev, pin_id));
> @@ -629,7 +629,7 @@ static int imx_pinctrl_parse_groups(struct device_node
> *np,
> for (i = 0; i < grp->num_pins; i++) {
> pin = &((struct imx_pin *)(grp->data))[i];
> if (info->flags & IMX_USE_SCU)
> - imx_pinctrl_parse_pin_scu(ipctl, >pins[i],
> + info->imx_pinctrl_parse_pin(ipctl, >pins[i],
> pin, );
> else
> imx_pinctrl_parse_pin_mmio(ipctl, >pins[i], diff
> --git
> a/drivers/pinctrl/freescale/pinctrl-imx.h
> b/drivers/pinctrl/freescale/pinctrl-imx.h
> index 333d32b..bdb86c2 100644
> --- a/drivers/pinctrl/freescale/pinctrl-imx.h
> +++ b/drivers/pinctrl/freescale/pinctrl-imx.h
> @@ -75,6 +75,21 @@ struct imx_cfg_params_decode {
> bool invert;
> };
>
> +/**
> + * @dev: a pointer back to containing device
> + * @base: the offset to the controller in virtual memory */ struct
> +imx_pinctrl {
> + struct device *dev;
> + struct pinctrl_dev *pctl;
> + void __iomem *base;
> + void __iomem *input_sel_base;
> + const struct imx_pinctrl_soc_info *info;
> + struct imx_pin_reg *pin_regs;
> + unsigned int group_index;
> + struct mutex mutex;
> +};
Any reason to move this part of code?
Regards
Aisheng
> +
> struct imx_pinctrl_soc_info {
> const struct pinctrl_pin_desc *pins;
> unsigned int npins;
> @@ -98,21 +113,13 @@ struct imx_pinctrl_soc_info {
> struct pinctrl_gpio_range *range,
> unsigned offset,
>
RE: [PATCH 1/2] pinctrl: imx: Support building SCU pinctrl driver as module
> From: Anson Huang
> Sent: Friday, July 17, 2020 5:53 PM
>
> Hi, Arnd
>
> > Subject: Re: [PATCH 1/2] pinctrl: imx: Support building SCU pinctrl
> > driver as module
> >
> > On Fri, Jul 17, 2020 at 11:24 AM Anson Huang
> > wrote:
> > > > Subject: Re: [PATCH 1/2] pinctrl: imx: Support building SCU
> > > > pinctrl driver as module
> > > > +MODULE_AUTHOR("Dong Aisheng");
> > > > +MODULE_DESCRIPTION("NXP i.MX SCU common pinctrl driver");
> > > > +MODULE_LICENSE("GPL v2");
> > > >
> > > >
> > > > This can be in a separate patch.
> > >
> > > I don't understand, without adding module license, changing the SCU
> > > pinctrl driver to "tristate", when building with =M, the build will
> > > have warning as below, so I think it does NOT make sense to split it
> > > to 2
> > patches.
> > >
> > > CC [M] drivers/pinctrl/freescale/pinctrl-scu.o
> > > MODPOST Module.symvers
> > > WARNING: modpost: missing MODULE_LICENSE() in
> > drivers/pinctrl/freescale/pinctrl-scu.o
> > > LD [M] drivers/pinctrl/freescale/pinctrl-scu.ko
> >
> > I agree it would be clearer to do it as separate patches, but you then
> > have to be careful about the order to avoid the problem you mention.
> >
> > A clear indication that it may be sensible to split up the patch is
> > that your changelog has a list of five items in it, which are mostly doing
> different things.
> > The ideal way to split up a patch series is to have each patch with a
> > changelog that has to explain exactly one thing, and makes it obvious
> > how each changed line corresponds to the description, but never
> > explain the same thing in more than one patch (i.e. you combine
> > patches that do the same thing in multiple files).
> >
> > In this case, a good split may be:
> >
> > patch 1:
> >- Use function callbacks for SCU related functions in pinctrl-imx.c
> > in order to support the scenario of PINCTRL_IMX is built in
> > while PINCTRL_IMX_SCU is built as module;
> > - All drivers using SCU pinctrl driver need to initialize the
> > SCU related function callback;
> >
> > patch 2:
> > - Export SCU related functions and use "IS_ENABLED" instead of
> > "ifdef" to support SCU pinctrl driver user and itself to be
> > built as module;
> > - Change PINCTR_IMX_SCU to tristate;
> > - Add module author, description and license.
> >
> > and then rewrite the description to not have a bulleted list.
> >
> > That said, I don't think it is critical here, and I would not have
> > complained about the version you sent.
> >
> > If you end up changing the patch, I think you can actually drop the
> > "#if IS_ENABLED()" check entirely, as the functions are now always
> > assumed to be available, and we don't #ifdef declarations when there
> > is no #else path otherwise.
> >
>
> Thanks for the good suggestion, if there is other comment need a V2, or
> maintainer thinks it is better to split it following your guide, I will send
> V2
> following your guide.
>
Pls do as Arnd suggested.
Besides that, I have a few minor comments in separate replies.
Regards
Aisheng
> Thanks,
> Anson
RE: [PATCH 21/22] arm64: dts: imx8qxp: Remove i.MX7 compatible from USDHC
> From: Krzysztof Kozlowski
> Sent: Monday, August 24, 2020 12:16 AM
>
> The USDHC on i.MX 8QXP has its own compatible described in bindings and
> used in the driver (with its own quirks). Remove additional fsl,imx7d-usdhc
> compatible to fix dtbs_check warnings like:
>
> arch/arm64/boot/dts/freescale/imx8qxp-ai_ml.dt.yaml: mmc@5b01:
> compatible: ['fsl,imx8qxp-usdhc', 'fsl,imx7d-usdhc'] is too long
> From schema:
> /ocumentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
>
> arch/arm64/boot/dts/freescale/imx8qxp-ai_ml.dt.yaml: mmc@5b01:
> compatible: Additional items are not allowed ('fsl,imx7d-usdhc' was
> unexpected)
>
> Signed-off-by: Krzysztof Kozlowski
For Patch 19-22, I think we should fix dt binding doc.
Regards
Aisheng
> ---
> arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> index 61bccb69f09e..26c4fcdfe290 100644
> --- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> @@ -362,7 +362,7 @@
> };
>
> usdhc1: mmc@5b01 {
> - compatible = "fsl,imx8qxp-usdhc", "fsl,imx7d-usdhc";
> + compatible = "fsl,imx8qxp-usdhc";
> interrupts = ;
> reg = <0x5b01 0x1>;
> clocks = <_lpcg IMX_CONN_LPCG_SDHC0_IPG_CLK>, @@
> -374,7 +374,7 @@
> };
>
> usdhc2: mmc@5b02 {
> - compatible = "fsl,imx8qxp-usdhc", "fsl,imx7d-usdhc";
> + compatible = "fsl,imx8qxp-usdhc";
> interrupts = ;
> reg = <0x5b02 0x1>;
> clocks = <_lpcg IMX_CONN_LPCG_SDHC1_IPG_CLK>, @@
> -388,7 +388,7 @@
> };
>
> usdhc3: mmc@5b03 {
> - compatible = "fsl,imx8qxp-usdhc", "fsl,imx7d-usdhc";
> + compatible = "fsl,imx8qxp-usdhc";
> interrupts = ;
> reg = <0x5b03 0x1>;
> clocks = <_lpcg IMX_CONN_LPCG_SDHC2_IPG_CLK>,
> --
> 2.17.1
RE: Lockdep warning caused by "driver core: Fix sleeping in invalid context during device link deletion"
> From: Saravana Kannan > Sent: Saturday, August 22, 2020 2:28 AM > > On Thu, Aug 20, 2020 at 8:50 PM Dong Aisheng > wrote: > > > > Hi ALL, > > > > We met the below WARNING during system suspend on an iMX6Q SDB board > > with the latest linus/master branch (v5.9-rc1+) and next-20200820. > > v5.8 kernel is ok. So i did bisect and finally found it's caused by > > the patch below. > > Reverting it can get rid of the warning, but I wonder if there may be > > other potential issues. > > Any ideas? > > Thanks for the report. I'll look into this more closely after Linux Plumbers > (next > week). We can't just revert the patch you pointed out because it's fixing > another > locking issue. > Thanks. Pls have me CCed when you send out patches. I'd love to test it. Regards Aisheng
RE: [PATCH] drivers: soc: Fix mailbox suspend/resume no irq for IMX SCU
> From: Vincenzo Frascino
> Sent: Monday, July 6, 2020 11:00 PM
>
> imx_mu_suspend_noirq()/imx_mu_resume_noirq() are currently used only
> when CONFIG_PM_SLEEP configuration options is enabled. Having it disabled
> triggers the following warning at compile time:
>
> drivers/mailbox/imx-mailbox.c:611:12: warning: ‘imx_mu_resume_noirq’
> defined but not used [-Wunused-function]
> static int imx_mu_resume_noirq(struct device *dev)
>
> drivers/mailbox/imx-mailbox.c:601:12: warning: ‘imx_mu_suspend_noirq’
> defined but not used [-Wunused-function]
> static int imx_mu_suspend_noirq(struct device *dev)
>
> Make imx_mu_suspend_noirq()/imx_mu_resume_noirq() __maybe_unused to
> address the issue.
>
> Cc: Jassi Brar
> Cc: Shawn Guo
> Cc: Sascha Hauer
> Cc: Pengutronix Kernel Team
> Cc: Fabio Estevam
> Cc: NXP Linux Team
> Signed-off-by: Vincenzo Frascino
There's already a fix:
https://lkml.org/lkml/2020/6/22/1555
Regards
Aisheng
> ---
> drivers/mailbox/imx-mailbox.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
> index 7205b825c8b5..f54f36948414 100644
> --- a/drivers/mailbox/imx-mailbox.c
> +++ b/drivers/mailbox/imx-mailbox.c
> @@ -598,7 +598,7 @@ static const struct of_device_id imx_mu_dt_ids[] = { };
> MODULE_DEVICE_TABLE(of, imx_mu_dt_ids);
>
> -static int imx_mu_suspend_noirq(struct device *dev)
> +static int __maybe_unused imx_mu_suspend_noirq(struct device *dev)
> {
> struct imx_mu_priv *priv = dev_get_drvdata(dev);
>
> @@ -608,7 +608,7 @@ static int imx_mu_suspend_noirq(struct device *dev)
> return 0;
> }
>
> -static int imx_mu_resume_noirq(struct device *dev)
> +static int __maybe_unused imx_mu_resume_noirq(struct device *dev)
> {
> struct imx_mu_priv *priv = dev_get_drvdata(dev);
>
> --
> 2.27.0
RE: [PATCH V4 2/5] clk: imx: Add clock configuration for ARMv7 platforms
> From: Anson Huang > Sent: Thursday, July 2, 2020 10:15 AM > > Add CONFIG_CLK_xxx for i.MX ARMv7 platforms, and use it as build option > instead of CONFIG_SOC_xxx, the CONFIG_CLK_xxx will be selected by default > according to CONFIG_SOC_xxx. > > Signed-off-by: Anson Huang Reviewed-by: Dong Aisheng Regards Aisheng > --- > Changes since V3: > - Add clock configuration for each ARMv7. > --- > drivers/clk/imx/Kconfig | 90 > > drivers/clk/imx/Makefile | 30 > 2 files changed, 105 insertions(+), 15 deletions(-) > > diff --git a/drivers/clk/imx/Kconfig b/drivers/clk/imx/Kconfig index > db0253f..09fc8ad 100644 > --- a/drivers/clk/imx/Kconfig > +++ b/drivers/clk/imx/Kconfig > @@ -8,6 +8,96 @@ config MXC_CLK_SCU > bool > depends on IMX_SCU > > +config CLK_IMX1 > + bool "IMX1 CCM Clock Driver" > + depends on SOC_IMX1 || COMPILE_TEST > + default SOC_IMX1 > + select MXC_CLK > + > +config CLK_IMX21 > + bool "IMX21 CCM Clock Driver" > + depends on SOC_IMX21 || COMPILE_TEST > + default SOC_IMX21 > + select MXC_CLK > + > +config CLK_IMX25 > + bool "IMX25 CCM Clock Driver" > + depends on SOC_IMX25 || COMPILE_TEST > + default SOC_IMX25 > + select MXC_CLK > + > +config CLK_IMX27 > + bool "IMX27 CCM Clock Driver" > + depends on SOC_IMX27 || COMPILE_TEST > + default SOC_IMX27 > + select MXC_CLK > + > +config CLK_IMX31 > + bool "IMX31 CCM Clock Driver" > + depends on SOC_IMX31 || COMPILE_TEST > + default SOC_IMX31 > + select MXC_CLK > + > +config CLK_IMX35 > + bool "IMX35 CCM Clock Driver" > + depends on SOC_IMX35 || COMPILE_TEST > + default SOC_IMX35 > + select MXC_CLK > + > +config CLK_IMX5 > + bool "IMX5 CCM Clock Driver" > + depends on SOC_IMX5 || COMPILE_TEST > + default SOC_IMX5 > + select MXC_CLK > + > +config CLK_IMX6Q > + bool "IMX6Q CCM Clock Driver" > + depends on SOC_IMX6Q || COMPILE_TEST > + default SOC_IMX6Q > + select MXC_CLK > + > +config CLK_IMX6SL > + bool "IMX6SL CCM Clock Driver" > + depends on SOC_IMX6SL || COMPILE_TEST > + default SOC_IMX6SL > + select MXC_CLK > + > +config CLK_IMX6SLL > + bool "IMX6SLL CCM Clock Driver" > + depends on SOC_IMX6SLL || COMPILE_TEST > + default SOC_IMX6SLL > + select MXC_CLK > + > +config CLK_IMX6SX > + bool "IMX6SX CCM Clock Driver" > + depends on SOC_IMX6SX || COMPILE_TEST > + default SOC_IMX6SX > + select MXC_CLK > + > +config CLK_IMX6UL > + bool "IMX6UL CCM Clock Driver" > + depends on SOC_IMX6UL || COMPILE_TEST > + default SOC_IMX6UL > + select MXC_CLK > + > +config CLK_IMX7D > + bool "IMX7D CCM Clock Driver" > + depends on SOC_IMX7D || COMPILE_TEST > + default SOC_IMX7D > + select MXC_CLK > + > +config CLK_IMX7ULP > + bool "IMX7ULP Clock Driver" > + depends on SOC_IMX7ULP || COMPILE_TEST > + default SOC_IMX7ULP > + select MXC_CLK > + > +config CLK_VF610 > + bool "VF610 Clock Driver" > + depends on SOC_VF610 || COMPILE_TEST > + default SOC_VF610 > + select MXC_CLK > + > config CLK_IMX8MM > bool "IMX8MM CCM Clock Driver" > depends on ARCH_MXC > diff --git a/drivers/clk/imx/Makefile b/drivers/clk/imx/Makefile index > 928f874..394ade7 100644 > --- a/drivers/clk/imx/Makefile > +++ b/drivers/clk/imx/Makefile > @@ -31,18 +31,18 @@ obj-$(CONFIG_CLK_IMX8MP) += clk-imx8mp.o > obj-$(CONFIG_CLK_IMX8MQ) += clk-imx8mq.o > obj-$(CONFIG_CLK_IMX8QXP) += clk-imx8qxp.o clk-imx8qxp-lpcg.o > > -obj-$(CONFIG_SOC_IMX1) += clk-imx1.o > -obj-$(CONFIG_SOC_IMX21) += clk-imx21.o > -obj-$(CONFIG_SOC_IMX25) += clk-imx25.o > -obj-$(CONFIG_SOC_IMX27) += clk-imx27.o > -obj-$(CONFIG_SOC_IMX31) += clk-imx31.o > -obj-$(CONFIG_SOC_IMX35) += clk-imx35.o > -obj-$(CONFIG_SOC_IMX5) += clk-imx5.o > -obj-$(CONFIG_SOC_IMX6Q) += clk-imx6q.o > -obj-$(CONFIG_SOC_IMX6SL) += clk-imx6sl.o > -obj-$(CONFIG_SOC_IMX6SLL) += clk-imx6sll.o > -obj-$(CONFIG_SOC_IMX6SX) += clk-imx6sx.o > -obj-$(CONFIG_SOC_IMX6UL) += clk-imx6ul.o > -obj-$(CONFIG_SOC_IMX7D) += clk-imx7d.o > -obj-$(CONFIG_SOC_IMX7ULP) += clk-imx7ulp.o > -obj-$(CONFIG_SOC_VF610) += clk-vf610.o > +obj-$(CONFIG_CLK_IMX1) += clk-imx1.o > +obj-$(CONFIG_CLK_IMX21) += clk-imx21.o > +obj-$(CONFIG_CLK_IMX25) += clk-imx25.o > +obj-$(CONFIG_CLK_IMX27) += clk-imx27.o > +obj-$(CONFIG_CLK_IMX31) += clk-imx31.o > +obj-$(CONFIG_CLK_IMX35) += clk-imx35.o > +obj-$(CONFIG_CLK_IMX5) += clk-imx5.o > +obj-$(CONFIG_CLK_IMX6Q) += clk-imx6q.o > +obj-$(CONFIG_CLK_IMX6SL) += clk-imx6sl.o > +obj-$(CONFIG_CLK_IMX6SLL) += clk-imx6sll.o > +obj-$(CONFIG_CLK_IMX6SX) += clk-imx6sx.o >
RE: [PATCH V2 3/9] clk: imx: Support building SCU clock driver as module
> From: Arnd Bergmann > Sent: Monday, June 29, 2020 4:20 PM > > On Mon, Jun 29, 2020 at 9:18 AM Dong Aisheng > wrote: > > On Thu, Jun 25, 2020 at 6:43 AM Stephen Boyd wrote: > > > Quoting Aisheng Dong (2020-06-23 19:59:09) Why aren't there options > > > to enable clk-imx6q and clk-imx6sl in the clk/imx/Kconfig file? > > > Those can be bool or tristate depending on if the SoC drivers use > > > CLK_OF_DECLARE or not and depend on the mxc-clk library and SoC > > > config we have in the makefile today. > > > > Yes, we can do that in clk/imx/Kconfig as follows theoretically. > > config CLK_IMX6Q > > bool > > def_bool ARCH_MXC && ARM > > select MXC_CLK > > > > But we have totally 15 platforms that need to change. > > I would make that > > config CLK_IMX6Q > bool "Clock driver for NXP i.MX6Q" > depends on SOC_IMX6Q || COMPILE_TEST > default SOC_IMX6Q > select MXC_CLK > Yes, this seems better. Anson, pls follow this way. > > e.g. > > drivers/clk/imx/Makefile > > obj-$(CONFIG_SOC_IMX1) += clk-imx1.o > > obj-$(CONFIG_SOC_IMX21) += clk-imx21.o > > obj-$(CONFIG_SOC_IMX25) += clk-imx25.o > > obj-$(CONFIG_SOC_IMX27) += clk-imx27.o > > obj-$(CONFIG_SOC_IMX31) += clk-imx31.o > > obj-$(CONFIG_SOC_IMX35) += clk-imx35.o > > obj-$(CONFIG_SOC_IMX5) += clk-imx5.o > > obj-$(CONFIG_SOC_IMX6Q) += clk-imx6q.o > > obj-$(CONFIG_SOC_IMX6SL) += clk-imx6sl.o > > obj-$(CONFIG_SOC_IMX6SLL) += clk-imx6sll.o > > obj-$(CONFIG_SOC_IMX6SX) += clk-imx6sx.o > > obj-$(CONFIG_SOC_IMX6UL) += clk-imx6ul.o > > obj-$(CONFIG_SOC_IMX7D) += clk-imx7d.o > > obj-$(CONFIG_SOC_IMX7ULP) += clk-imx7ulp.o > > obj-$(CONFIG_SOC_VF610) += clk-vf610.o > > > > Not sure if it's really worth to do that. > > The easiest way to address this issue is just select it in > > arch/arm/mach-imx/Kconfig, > > Changing them can be a one or two patches, that's totally worth it IMHO. > > I really don't like the 'select' in arch/arm/mach-imx/Kconfig: if you've done > the > work to make the imx8 clk driver modular, I would expect to see the same at > least tried for the other ones. > Got it. > For the clk drivers that cannot yet be 'tristate' because of the > CLK_OF_DECLARE(), can you include a list of drivers that depend on the clocks > being available during early boot? > I guess we can find out them one by one for those 15 platforms when converting them to modules as well. Currently we're converting ARM64 clock drivers first. Regards Aisheng >Arnd
RE: [PATCH V3 03/10] ARM: imx: Select MXC_CLK for each SoC
> From: Anson Huang > Sent: Monday, June 29, 2020 1:54 PM > > i.MX common clock drivers may support module build, so it is NOT selected by > default, for ARCH_MXC ARMv7 platforms, need to select it manually in each SoC > to make build pass. > > Signed-off-by: Anson Huang > --- > Changes since V2: > - manually select the MXC_CLK in each SoC instead of selecting it > for ARCH_MXC. Any reason to do this? Regards Aisheng > --- > arch/arm/mach-imx/Kconfig | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index > e7d7b90..a465c0f 100644 > --- a/arch/arm/mach-imx/Kconfig > +++ b/arch/arm/mach-imx/Kconfig > @@ -58,6 +58,7 @@ config SOC_IMX21 > select CPU_ARM926T > select IMX_HAVE_IOMUX_V1 > select MXC_AVIC > + select MXC_CLK > > config SOC_IMX27 > bool > @@ -65,17 +66,20 @@ config SOC_IMX27 > select IMX_HAVE_IOMUX_V1 > select MXC_AVIC > select PINCTRL_IMX27 > + select MXC_CLK > > config SOC_IMX31 > bool > select CPU_V6 > select MXC_AVIC > + select MXC_CLK > > config SOC_IMX35 > bool > select ARCH_MXC_IOMUX_V3 > select MXC_AVIC > select PINCTRL_IMX35 > + select MXC_CLK > > if ARCH_MULTI_V5 > > @@ -419,6 +423,7 @@ config SOC_IMX1 > select CPU_ARM920T > select MXC_AVIC > select PINCTRL_IMX1 > + select MXC_CLK > help > This enables support for Freescale i.MX1 processor > > @@ -432,6 +437,7 @@ config SOC_IMX25 > select CPU_ARM926T > select MXC_AVIC > select PINCTRL_IMX25 > + select MXC_CLK > help > This enables support for Freescale i.MX25 processor endif @@ -444,6 > +450,7 @@ config SOC_IMX5 > bool > select HAVE_IMX_SRC > select MXC_TZIC > + select MXC_CLK > > config SOC_IMX50 > bool "i.MX50 support" > @@ -477,6 +484,7 @@ config SOC_IMX6 > select HAVE_IMX_MMDC > select HAVE_IMX_SRC > select MFD_SYSCON > + select MXC_CLK > select PL310_ERRATA_769419 if CACHE_L2X0 > > config SOC_IMX6Q > @@ -561,6 +569,7 @@ config SOC_IMX7D_CM4 config SOC_IMX7D > bool "i.MX7 Dual support" > select PINCTRL_IMX7D > + select MXC_CLK > select SOC_IMX7D_CA7 if ARCH_MULTI_V7 > select SOC_IMX7D_CM4 if ARM_SINGLE_ARMV7M > select ARM_ERRATA_814220 if ARCH_MULTI_V7 @@ -571,6 +580,7 @@ > config SOC_IMX7ULP > bool "i.MX7ULP support" > select CLKSRC_IMX_TPM > select PINCTRL_IMX7ULP > + select MXC_CLK > select SOC_IMX7D_CA7 if ARCH_MULTI_V7 > select SOC_IMX7D_CM4 if ARM_SINGLE_ARMV7M > help > @@ -580,6 +590,7 @@ config SOC_VF610 > bool "Vybrid Family VF610 support" > select ARM_GIC if ARCH_MULTI_V7 > select PINCTRL_VF610 > + select MXC_CLK > > help > This enables support for Freescale Vybrid VF610 processor. > -- > 2.7.4
RE: [PATCH V3] firmware: imx: Move i.MX SCU soc driver into imx firmware folder
> From: Anson Huang > Sent: Friday, June 26, 2020 5:14 AM > > The i.MX SCU soc driver depends on SCU firmware driver, so it has to use > platform driver model for proper defer probe operation, since it has no device > binding in DT file, a simple platform device is created together inside the > platform driver. To make it more clean, we can just move the entire SCU soc > driver into imx firmware folder and initialized by i.MX SCU firmware driver. > > Signed-off-by: Anson Huang Reviewed-by: Dong Aisheng Regards Aisheng
RE: [PATCH V2 3/9] clk: imx: Support building SCU clock driver as module
> From: Arnd Bergmann > Sent: Wednesday, June 24, 2020 3:47 PM > > On Wed, Jun 24, 2020 at 4:19 AM Aisheng Dong > wrote: > > > Isn't that what we want? > > > > No, if user set MXC_CLK to m, the build will break for i.MX6&7. > > > > > Why does ARCH_MXC being enabled mandate that it is builtin? Is some > > > architecture level code calling into the clk driver? > > > > > > It's mainly because there's no Kconfig options for i.MX6 &7 clock drivers. > > It just reuses ARCH config CONFIG_SOC_XXX which can only be y. > > e.g. > > obj-$(CONFIG_SOC_IMX6Q) += clk-imx6q.o > > obj-$(CONFIG_SOC_IMX6SL) += clk-imx6sl.o > > obj-$(CONFIG_SOC_IMX7ULP) += clk-imx7ulp.o > > obj-$(CONFIG_SOC_VF610) += clk-vf610.o .. > > > > If setting MXC_CLK to m, the platform clock drivers will fail to build > > due to miss to find symbols defined in the common clock library by > CONFIG_MXC_CLK. > > So we have to avoid users to be able to config MXC_CLK to m for i.MX6&7. > > Only depends on ARCH_MXC mean user still can set it to m. > > The link error can be easily avoided by building all the clk support into a > single > loadable module like below. > > Hower this only works if all drivers that have a runtime dependency on the clk > driver support deferred probing or are built as loadable modules as well and > get > loaded after the clk driver. > Thanks for the info. Currently all i.MX6&7/VF clocks driver are not loadable modules (they're using CLK_OF_DECLARE), so can't be built as m. If we really want to build i.MX common clock libraries into module, I guess the easiest way Is as what Patch [2/9] does, select it by ARCH_MXC. Then users have no chance to build it as module, so no build issues. Regards Aisheng > Arnd > > 8<--- > diff --git a/drivers/clk/imx/Makefile b/drivers/clk/imx/Makefile index > 928f874c73d2..638bc00f5731 100644 > --- a/drivers/clk/imx/Makefile > +++ b/drivers/clk/imx/Makefile > @@ -1,6 +1,8 @@ > # SPDX-License-Identifier: GPL-2.0 > > -obj-$(CONFIG_MXC_CLK) += \ > +obj-$(CONFIG_MXC_CLK) := clk-imx.ko > + > +clk-imx-y += \ > clk.o \ > clk-busy.o \ > clk-composite-8m.o \ > @@ -25,24 +27,24 @@ obj-$(CONFIG_MXC_CLK_SCU) += \ > clk-scu.o \ > clk-lpcg-scu.o > > -obj-$(CONFIG_CLK_IMX8MM) += clk-imx8mm.o > -obj-$(CONFIG_CLK_IMX8MN) += clk-imx8mn.o > -obj-$(CONFIG_CLK_IMX8MP) += clk-imx8mp.o > -obj-$(CONFIG_CLK_IMX8MQ) += clk-imx8mq.o > -obj-$(CONFIG_CLK_IMX8QXP) += clk-imx8qxp.o clk-imx8qxp-lpcg.o > +clk-imx-$(CONFIG_CLK_IMX8MM) += clk-imx8mm.o > +clk-imx-$(CONFIG_CLK_IMX8MN) += clk-imx8mn.o > +clk-imx-$(CONFIG_CLK_IMX8MP) += clk-imx8mp.o > +clk-imx-$(CONFIG_CLK_IMX8MQ) += clk-imx8mq.o > +clk-imx-$(CONFIG_CLK_IMX8QXP) += clk-imx8qxp.o clk-imx8qxp-lpcg.o > > -obj-$(CONFIG_SOC_IMX1) += clk-imx1.o > -obj-$(CONFIG_SOC_IMX21) += clk-imx21.o > -obj-$(CONFIG_SOC_IMX25) += clk-imx25.o > -obj-$(CONFIG_SOC_IMX27) += clk-imx27.o > -obj-$(CONFIG_SOC_IMX31) += clk-imx31.o > -obj-$(CONFIG_SOC_IMX35) += clk-imx35.o > -obj-$(CONFIG_SOC_IMX5) += clk-imx5.o > -obj-$(CONFIG_SOC_IMX6Q) += clk-imx6q.o > -obj-$(CONFIG_SOC_IMX6SL) += clk-imx6sl.o > -obj-$(CONFIG_SOC_IMX6SLL) += clk-imx6sll.o > -obj-$(CONFIG_SOC_IMX6SX) += clk-imx6sx.o > -obj-$(CONFIG_SOC_IMX6UL) += clk-imx6ul.o > -obj-$(CONFIG_SOC_IMX7D) += clk-imx7d.o > -obj-$(CONFIG_SOC_IMX7ULP) += clk-imx7ulp.o > -obj-$(CONFIG_SOC_VF610) += clk-vf610.o > +clk-imx-$(CONFIG_SOC_IMX1) += clk-imx1.o > +clk-imx-$(CONFIG_SOC_IMX21) += clk-imx21.o > +clk-imx-$(CONFIG_SOC_IMX25) += clk-imx25.o > +clk-imx-$(CONFIG_SOC_IMX27) += clk-imx27.o > +clk-imx-$(CONFIG_SOC_IMX31) += clk-imx31.o > +clk-imx-$(CONFIG_SOC_IMX35) += clk-imx35.o > +clk-imx-$(CONFIG_SOC_IMX5) += clk-imx5.o > +clk-imx-$(CONFIG_SOC_IMX6Q) += clk-imx6q.o > +clk-imx-$(CONFIG_SOC_IMX6SL) += clk-imx6sl.o > +clk-imx-$(CONFIG_SOC_IMX6SLL) += clk-imx6sll.o > +clk-imx-$(CONFIG_SOC_IMX6SX) += clk-imx6sx.o > +clk-imx-$(CONFIG_SOC_IMX6UL) += clk-imx6ul.o > +clk-imx-$(CONFIG_SOC_IMX7D) += clk-imx7d.o > +clk-imx-$(CONFIG_SOC_IMX7ULP) += clk-imx7ulp.o > +clk-imx-$(CONFIG_SOC_VF610) += clk-vf610.o
RE: [PATCH V6 0/9] Support i.MX8 SoCs pinctrl drivers built as module
> From: Anson Huang > Sent: Wednesday, June 24, 2020 2:24 PM > > There are more and mroe requirements that SoC specific modules should be > built as module in order to support generic kernel image, such as Android GKI > concept. > > This patch series supports i.MX8 SoCs pinctrl drivers to be built as module, > including i.MX8MQ/MM/MN/MP/QXP/QM/DXL SoCs, i.MX common pinctrl > driver and i.MX SCU common pinctrl driver as still built-in. > > Compared to V5, the changes are as below: > - Keep i.MX common pinctrl libary built in, ONLY i.MX SoC pinctrl > driver > support built as module. > > Anson Huang (9): > pinctrl: imx: Support i.MX8 SoCs pinctrl driver built as module > pinctrl: imx: scu: Support i.MX8 SCU SoCs pinctrl driver built as > module > pinctrl: imx8mm: Support building as module > pinctrl: imx8mn: Support building as module > pinctrl: imx8mq: Support building as module > pinctrl: imx8mp: Support building as module > pinctrl: imx8qxp: Support building as module > pinctrl: imx8qm: Support building as module > pinctrl: imx8dxl: Support building as module For this patch series: Reviewed-by: Dong Aisheng Regards Aisheng
RE: [PATCH V2 3/9] clk: imx: Support building SCU clock driver as module
> From: Anson Huang > Sent: Wednesday, June 24, 2020 10:36 AM > > > Subject: RE: [PATCH V2 3/9] clk: imx: Support building SCU clock > > driver as module > > > > > From: Stephen Boyd > > > Sent: Wednesday, June 24, 2020 8:58 AM > > > Subject: RE: [PATCH V2 3/9] clk: imx: Support building SCU clock > > > driver as module > > > > > > Quoting Aisheng Dong (2020-06-23 02:00:47) > > > > > From: Stephen Boyd > > > > > Sent: Tuesday, June 23, 2020 4:34 PM > > > > > Subject: RE: [PATCH V2 3/9] clk: imx: Support building SCU clock > > > > > driver as module > > > > > > > > > > Quoting Aisheng Dong (2020-06-22 20:42:19) > > > > > > > From: Stephen Boyd > > > > > > > Sent: Saturday, June 20, 2020 11:28 AM > > > > > > > Subject: RE: [PATCH V2 3/9] clk: imx: Support building SCU > > > > > > > clock driver as module > > > > > > > > > > > > > > Quoting Aisheng Dong (2020-06-17 18:58:51) > > > > > > > > > From: Anson Huang > > > > > > > > > > > +obj-$(CONFIG_MXC_CLK_SCU) += mxc-clk-scu.o > > > > > > > > > > > > > > > > > > > > Like i.MX pinctrl, I'm not sure if it's really > > > > > > > > > > necessary to build core libraries as modules. Probably > > > > > > > > > > the simplest way is only building platform drivers > > > > > > > > > > part as module. And leave those core libraries > > > > > > > built in kernel. > > > > > > > > > > This may make the code a bit cleaner. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Will discuss this with Linaro guys about it, previous > > > > > > > > > requirement I received is all SoC specific modules need > > > > > > > > > to be built as > > > > > module. > > > > > > > > > > > > > > > > > > > > > > > > > Okay. AFAIK it's not conflict. > > > > > > > > You still make drivers into modules. > > > > > > > > Only difference is for those common libraries part, we > > > > > > > > don't convert them into module Which is less meaningless. > > > > > > > > > > > > > > > > > > > > > > What is the benefit of making the core part of the SoC > > > > > > > driver not a > > > module? > > > > > > > > > > > > Usually we could try to build it as module if it's not hard. > > > > > > > > > > > > One question is sometimes those core part are shared with some > > > > > > platforms > > > > > which can't built as module. > > > > > > For i.MX case, it's mainly patch 4: > > > > > > [V2,4/9] clk: imx: Support building i.MX common clock driver > > > > > > as module > > > > > > > > > > > > > > > > > > Those libraries are also used by i.MX6&7 which can't build as > > > > > > module. > > > > > > So we need an extra workaround patch to forcely 'select' it > > > > > > under arch/arm/mach-imx/Kconfig [V2,2/9] ARM: imx: Select > > > > > > MXC_CLK for ARCH_MXC Then the users can't configure it as > > > > > > module in order to not break build. > > > > > > > > > > > > If build-in those common libraries, the implementation could > > > > > > be a bit easier > > > > > and cleaner. > > > > > > So I'm not sure if we still have to build them as module. > > > > > > How would you suggest for such case? > > > > > > > > > > Stop using 'select MXC_CLK' when requiring the core library code? > > > > > Instead, make it a 'depends' and then that will make depending > > > > > modules (i.e. the SoC files) that want to be builtin force the > > > > > core module to be builtin too. Other modular configs that depend > > > > > on the core will > > > still be modular. > > > > > > > > > > > > > It seems not work. > > > > Patch 4 already chan
RE: [PATCH V2 3/9] clk: imx: Support building SCU clock driver as module
> From: Stephen Boyd > Sent: Wednesday, June 24, 2020 8:58 AM > Subject: RE: [PATCH V2 3/9] clk: imx: Support building SCU clock driver as > module > > Quoting Aisheng Dong (2020-06-23 02:00:47) > > > From: Stephen Boyd > > > Sent: Tuesday, June 23, 2020 4:34 PM > > > Subject: RE: [PATCH V2 3/9] clk: imx: Support building SCU clock > > > driver as module > > > > > > Quoting Aisheng Dong (2020-06-22 20:42:19) > > > > > From: Stephen Boyd > > > > > Sent: Saturday, June 20, 2020 11:28 AM > > > > > Subject: RE: [PATCH V2 3/9] clk: imx: Support building SCU clock > > > > > driver as module > > > > > > > > > > Quoting Aisheng Dong (2020-06-17 18:58:51) > > > > > > > From: Anson Huang > > > > > > > > > +obj-$(CONFIG_MXC_CLK_SCU) += mxc-clk-scu.o > > > > > > > > > > > > > > > > Like i.MX pinctrl, I'm not sure if it's really necessary > > > > > > > > to build core libraries as modules. Probably the simplest > > > > > > > > way is only building platform drivers part as module. And > > > > > > > > leave those core libraries > > > > > built in kernel. > > > > > > > > This may make the code a bit cleaner. > > > > > > > > > > > > > > > > > > > > > > Will discuss this with Linaro guys about it, previous > > > > > > > requirement I received is all SoC specific modules need to > > > > > > > be built as > > > module. > > > > > > > > > > > > > > > > > > > Okay. AFAIK it's not conflict. > > > > > > You still make drivers into modules. > > > > > > Only difference is for those common libraries part, we don't > > > > > > convert them into module Which is less meaningless. > > > > > > > > > > > > > > > > What is the benefit of making the core part of the SoC driver not a > module? > > > > > > > > Usually we could try to build it as module if it's not hard. > > > > > > > > One question is sometimes those core part are shared with some > > > > platforms > > > which can't built as module. > > > > For i.MX case, it's mainly patch 4: > > > > [V2,4/9] clk: imx: Support building i.MX common clock driver as > > > > module > > > > > > > > > > > > Those libraries are also used by i.MX6&7 which can't build as module. > > > > So we need an extra workaround patch to forcely 'select' it under > > > > arch/arm/mach-imx/Kconfig [V2,2/9] ARM: imx: Select MXC_CLK for > > > > ARCH_MXC Then the users can't configure it as module in order to > > > > not break build. > > > > > > > > If build-in those common libraries, the implementation could be a > > > > bit easier > > > and cleaner. > > > > So I'm not sure if we still have to build them as module. > > > > How would you suggest for such case? > > > > > > Stop using 'select MXC_CLK' when requiring the core library code? > > > Instead, make it a 'depends' and then that will make depending > > > modules (i.e. the SoC files) that want to be builtin force the core > > > module to be builtin too. Other modular configs that depend on the core > > > will > still be modular. > > > > > > > It seems not work. > > Patch 4 already changes it to depend on ARCH_MXC which can only be 'Y'. > > [V2,4/9] clk: imx: Support building i.MX common clock driver as module > > diff --git a/drivers/clk/imx/Kconfig b/drivers/clk/imx/Kconfig index > > ded0643..678113b 100644 > > --- a/drivers/clk/imx/Kconfig > > +++ b/drivers/clk/imx/Kconfig > > @@ -1,8 +1,8 @@ > > # SPDX-License-Identifier: GPL-2.0 > > # common clock support for NXP i.MX SoC family. > > config MXC_CLK > > - bool > > - def_bool ARCH_MXC > > + tristate "IMX clock" > > + depends on ARCH_MXC > > > > But user can still set MXC_CLK to be m, either via make menuconfig or > defconfig. > > Isn't that what we want? No, if user set MXC_CLK to m, the build will break for i.MX6&7. > Why does ARCH_MXC being enabled mandate that it is > builtin? Is some architecture level code calling into the clk driver? It's mainly because there's no Kconfig options for i.MX6 &7 clock drivers. It just reuses ARCH config CONFIG_SOC_XXX which can only be y. e.g. obj-$(CONFIG_SOC_IMX6Q) += clk-imx6q.o obj-$(CONFIG_SOC_IMX6SL) += clk-imx6sl.o obj-$(CONFIG_SOC_IMX7ULP) += clk-imx7ulp.o obj-$(CONFIG_SOC_VF610) += clk-vf610.o .. If setting MXC_CLK to m, the platform clock drivers will fail to build due to miss to find symbols defined in the common clock library by CONFIG_MXC_CLK. So we have to avoid users to be able to config MXC_CLK to m for i.MX6&7. Only depends on ARCH_MXC mean user still can set it to m. Regards Aisheng
RE: [PATCH V2 3/9] clk: imx: Support building SCU clock driver as module
> From: Stephen Boyd > Sent: Tuesday, June 23, 2020 4:34 PM > Subject: RE: [PATCH V2 3/9] clk: imx: Support building SCU clock driver as > module > > Quoting Aisheng Dong (2020-06-22 20:42:19) > > > From: Stephen Boyd > > > Sent: Saturday, June 20, 2020 11:28 AM > > > Subject: RE: [PATCH V2 3/9] clk: imx: Support building SCU clock > > > driver as module > > > > > > Quoting Aisheng Dong (2020-06-17 18:58:51) > > > > > From: Anson Huang > > > > > > > +obj-$(CONFIG_MXC_CLK_SCU) += mxc-clk-scu.o > > > > > > > > > > > > Like i.MX pinctrl, I'm not sure if it's really necessary to > > > > > > build core libraries as modules. Probably the simplest way is > > > > > > only building platform drivers part as module. And leave those > > > > > > core libraries > > > built in kernel. > > > > > > This may make the code a bit cleaner. > > > > > > > > > > > > > > > > Will discuss this with Linaro guys about it, previous > > > > > requirement I received is all SoC specific modules need to be built as > module. > > > > > > > > > > > > > Okay. AFAIK it's not conflict. > > > > You still make drivers into modules. > > > > Only difference is for those common libraries part, we don't > > > > convert them into module Which is less meaningless. > > > > > > > > > > What is the benefit of making the core part of the SoC driver not a > > > module? > > > > Usually we could try to build it as module if it's not hard. > > > > One question is sometimes those core part are shared with some platforms > which can't built as module. > > For i.MX case, it's mainly patch 4: > > [V2,4/9] clk: imx: Support building i.MX common clock driver as module > > > > > > Those libraries are also used by i.MX6&7 which can't build as module. > > So we need an extra workaround patch to forcely 'select' it under > > arch/arm/mach-imx/Kconfig [V2,2/9] ARM: imx: Select MXC_CLK for > > ARCH_MXC > > Then the users can't configure it as module in order to not break build. > > > > If build-in those common libraries, the implementation could be a bit easier > and cleaner. > > So I'm not sure if we still have to build them as module. > > How would you suggest for such case? > > Stop using 'select MXC_CLK' when requiring the core library code? > Instead, make it a 'depends' and then that will make depending modules (i.e. > the > SoC files) that want to be builtin force the core module to be builtin too. > Other > modular configs that depend on the core will still be modular. > It seems not work. Patch 4 already changes it to depend on ARCH_MXC which can only be 'Y'. [V2,4/9] clk: imx: Support building i.MX common clock driver as module diff --git a/drivers/clk/imx/Kconfig b/drivers/clk/imx/Kconfig index ded0643..678113b 100644 --- a/drivers/clk/imx/Kconfig +++ b/drivers/clk/imx/Kconfig @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 # common clock support for NXP i.MX SoC family. config MXC_CLK - bool - def_bool ARCH_MXC + tristate "IMX clock" + depends on ARCH_MXC But user can still set MXC_CLK to be m, either via make menuconfig or defconfig. Looks like only select it in arch Kconfig in Patch 2, there will be no issue. diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index e7d7b90..47b10d2 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -4,6 +4,7 @@ menuconfig ARCH_MXC depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || ARM_SINGLE_ARMV7M select ARCH_SUPPORTS_BIG_ENDIAN select CLKSRC_IMX_GPT + select MXC_CLK select GENERIC_IRQ_CHIP select GPIOLIB select PINCTRL > I don't know why an architecture is selecting the clk code at all to be > honest. > That can be moved to the defconfig instead of in the architecture Kconfig and > then you don't get a working system unless you select the MXC_CLK config from > the configurator tool (menuconfig, nconfig, etc.) So ARCH_MXC shouldn't be in > this discussion and the core module should be selectable by the configurator > and that should be tristate and all SoC modules should depend on that core > library module and be selectable too and those Kconfigs can be tristate or > bool. I guess it is because we didn't have requirements to make minimum booting required drivers to be built as module before. Regards Aisheng
RE: [PATCH V2 3/9] clk: imx: Support building SCU clock driver as module
> From: Stephen Boyd > Sent: Saturday, June 20, 2020 11:28 AM > Subject: RE: [PATCH V2 3/9] clk: imx: Support building SCU clock driver as > module > > Quoting Aisheng Dong (2020-06-17 18:58:51) > > > From: Anson Huang > > > > > +obj-$(CONFIG_MXC_CLK_SCU) += mxc-clk-scu.o > > > > > > > > Like i.MX pinctrl, I'm not sure if it's really necessary to build > > > > core libraries as modules. Probably the simplest way is only > > > > building platform drivers part as module. And leave those core libraries > built in kernel. > > > > This may make the code a bit cleaner. > > > > > > > > > > Will discuss this with Linaro guys about it, previous requirement I > > > received is all SoC specific modules need to be built as module. > > > > > > > Okay. AFAIK it's not conflict. > > You still make drivers into modules. > > Only difference is for those common libraries part, we don't convert > > them into module Which is less meaningless. > > > > What is the benefit of making the core part of the SoC driver not a module? Usually we could try to build it as module if it's not hard. One question is sometimes those core part are shared with some platforms which can't built as module. For i.MX case, it's mainly patch 4: [V2,4/9] clk: imx: Support building i.MX common clock driver as module https://patchwork.kernel.org/patch/11594801/ Those libraries are also used by i.MX6&7 which can't build as module. So we need an extra workaround patch to forcely 'select' it under arch/arm/mach-imx/Kconfig [V2,2/9] ARM: imx: Select MXC_CLK for ARCH_MXC https://patchwork.kernel.org/patch/11594793/ Then the users can't configure it as module in order to not break build. If build-in those common libraries, the implementation could be a bit easier and cleaner. So I'm not sure if we still have to build them as module. How would you suggest for such case? > From the module perspective it should be perfectly fine to make it a module as > well, and then depmod will sort out loading modules in the right order. > > This is for android right? Yes, for Android GKI support. Regards Aisheng
RE: [PATCH] mailbox: imx: Mark PM functions as __maybe_unused
> From: Nathan Chancellor
> Sent: Tuesday, June 23, 2020 9:04 AM
>
> When CONFIG_PM and CONFIG_PM_SLEEP are unset, the following warnings
> occur:
>
> drivers/mailbox/imx-mailbox.c:638:12: warning: 'imx_mu_runtime_resume'
> defined but not used [-Wunused-function]
> 638 | static int imx_mu_runtime_resume(struct device *dev)
> |^
> drivers/mailbox/imx-mailbox.c:629:12: warning: 'imx_mu_runtime_suspend'
> defined but not used [-Wunused-function]
> 629 | static int imx_mu_runtime_suspend(struct device *dev)
> |^~
> drivers/mailbox/imx-mailbox.c:611:12: warning: 'imx_mu_resume_noirq'
> defined but not used [-Wunused-function]
> 611 | static int imx_mu_resume_noirq(struct device *dev)
> |^~~
> drivers/mailbox/imx-mailbox.c:601:12: warning: 'imx_mu_suspend_noirq'
> defined but not used [-Wunused-function]
> 601 | static int imx_mu_suspend_noirq(struct device *dev)
> |^~~~
>
> Mark these functions as __maybe_unused, which is the standard procedure for
> PM functions.
>
> Fixes: bb2b2624dbe2 ("mailbox: imx: Add runtime PM callback to handle MU
> clocks")
> Signed-off-by: Nathan Chancellor
Thanks for catching this.
Reviewed-by: Dong Aisheng
Regards
Aisheng
RE: [PATCH] soc: imx-scu: Support module build
> From: Arnd Bergmann
> Sent: Thursday, June 18, 2020 3:21 PM
>
> On Wed, Jun 17, 2020 at 11:41 AM Anson Huang
> wrote:
>
> > > >
> > > > I'm ok with the change. But I'm curious how can this module be
> > > > autoloaded without MODULE_DEVICE_TABLE.
> > > > Have you tested if it can work?
> > > >
> > >
> > > I ONLY tested the manual insmod, if want to support auto load, may
> > > need some more change, will try it later and send out a V2 if needed.
> >
> > The further check shows that, if want to support auto load, the
> > platform device register needs to be done in somewhere else which is
> > built-in (in my test, I move it to clk-imx8qxp.c's probe), and also
> > need to add below module alias in this driver, because it has no device
> > node in
> DT and no device table in driver.
> >
> > +MODULE_ALIAS("platform:imx-scu-soc");
> >
> > Since this driver has no device node in DT, and the target is to build
> > all SoC specific drivers as module, so the best way is to add a
> > virtual device node in DT in order to support auto load?
>
> I see that there is indeed a driver for the device node in
> drivers/firmware/imx/imx-scu.c, the only reason for this module using
> device_initcall() with a manual
> platform_device_register_simple() seems to be that we cannot have two
> platform drivers bind to the same device node.
>
> I think a cleaner way to handle this would be to just move the entire soc
> driver
> into the firmware driver and then remove the duplication.
>
Yes, sounds like a good idea to me.
Regards
Aisheng
>Arnd
RE: [PATCH V2 2/9] ARM: imx: Select MXC_CLK for ARCH_MXC
> From: Anson Huang > Sent: Thursday, June 18, 2020 11:18 AM > > > From: Aisheng Dong > > Sent: 2020年6月18日 11:09 > > > > > From: Anson Huang > > > Sent: Wednesday, June 17, 2020 8:36 PM > > > > > > > Subject: RE: [PATCH V2 2/9] ARM: imx: Select MXC_CLK for ARCH_MXC > > > > > > > > > From: Anson Huang > > > > > Sent: Tuesday, June 9, 2020 3:32 PM > > > > > > > > > > i.MX common clock drivers may support module build, so it is NOT > > > > > selected by default, for ARCH_MXC ARMv7 platforms, need to > > > > > select it manually to make build pass. > > > > > > > > > > Signed-off-by: Anson Huang > > > > > > > > Can't the original def_xxx work? > > > > > > > > config MXC_CLK > > > > tristate > > > > def_tristate ARCH_MXC > > > > > > Such change will make MXC_CLK=y even all i.MX8 SoCs clock drivers > > > are selected as module, so it does NOT meet the requirement of > > > module support. Below is from .config when all > > > i.MX8 SoCs clock drivers are configured to module. > > > > > > CONFIG_MXC_CLK=y > > > CONFIG_MXC_CLK_SCU=m > > > CONFIG_CLK_IMX8MM=m > > > CONFIG_CLK_IMX8MN=m > > > CONFIG_CLK_IMX8MP=m > > > CONFIG_CLK_IMX8MQ=m > > > CONFIG_CLK_IMX8QXP=m > > > > > > > It works at my side. > > Below is my changes based on your patchset: > > $ git diff > > diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig > > index > > 47b10d20f411..e7d7b90e2cf8 100644 > > --- a/arch/arm/mach-imx/Kconfig > > +++ b/arch/arm/mach-imx/Kconfig > > @@ -4,7 +4,6 @@ menuconfig ARCH_MXC > > depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || > > ARM_SINGLE_ARMV7M > > select ARCH_SUPPORTS_BIG_ENDIAN > > select CLKSRC_IMX_GPT > > - select MXC_CLK > > select GENERIC_IRQ_CHIP > > select GPIOLIB > > select PINCTRL > > diff --git a/drivers/clk/imx/Kconfig b/drivers/clk/imx/Kconfig index > > 26cedbfe386c..f7b3e3a2cb9f 100644 > > --- a/drivers/clk/imx/Kconfig > > +++ b/drivers/clk/imx/Kconfig > > @@ -3,6 +3,7 @@ > > config MXC_CLK > > tristate "IMX clock" > > depends on ARCH_MXC > > + def_tristate ARCH_MXC > > > > config MXC_CLK_SCU > > tristate "IMX SCU clock" > > > > I guess you tried imx_v6_v7_defconfig? It does NOT work for ARM64 defconfig > when we try to make CONFIG_MXC_CLK=m, Below are my change, you can see > in .config, even all i.MX8 SoCs clock drivers are configured to module, the > CONFIG_MXC_CLK is still =y, but the expected result is =m. > It works at my side because it can manually selected as m or add CONFIG_MXC_CLK=m In defconfig. But now I got your point you want CONFIG_MXC_CLK default to m once define CONFIG_CLK_IMX8X=m in defconfig. > BTW, all i.MX8 SoCs select MXC_CLK in their kconfig, this patch just does the > same thing for i.MX6/7 in common place. > I just noticed for MX6&7, actually CONFIG_MXC_CLK can't be m otherwise we will meet build break. That means CONFIG_MXC_CLK cannot be configurable by users for non-ARM64 platforms. Thus can't use def_tristate and we still need select it under ARCH_MXC. This lightly lose a bit meaning to make this core library as module. IMHO I'd still prefer to builtin those core libraries rather than convert to module. Regards Aisheng > diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index > 47b10d2..e7d7b90 100644 > --- a/arch/arm/mach-imx/Kconfig > +++ b/arch/arm/mach-imx/Kconfig > @@ -4,7 +4,6 @@ menuconfig ARCH_MXC > depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || > ARM_SINGLE_ARMV7M > select ARCH_SUPPORTS_BIG_ENDIAN > select CLKSRC_IMX_GPT > - select MXC_CLK > select GENERIC_IRQ_CHIP > select GPIOLIB > select PINCTRL > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index > 8222e4b..21e2dbb 100644 > --- a/arch/arm64/configs/defconfig > +++ b/arch/arm64/configs/defconfig > @@ -799,11 +799,11 @@ CONFIG_COMMON_CLK_S2MPS11=y > CONFIG_COMMON_CLK_PWM=y CONFIG_COMMON_CLK_VC5=y > CONFIG_CLK_RASPBERRYPI=m -CONFIG_CLK_IMX8MM=y > -CONFIG_CLK_IMX8MN=y -CONFIG_CLK_IMX8MP=y -CONFIG_CLK_IMX8MQ=y > -CONFIG_CLK_IMX8QXP=y > +CONFIG_CLK_IMX8MM=m > +CONFIG_CLK_IMX8MN=m > +CONFIG_CLK_IMX8MP=m > +CONFIG_CLK_IMX8MQ=m > +CONFIG_CLK_IMX8QXP=m > CONFIG_TI_SCI_CLK=y > CONFIG_COMMON_CLK_QCOM=y > CONFIG_QCOM_A53PLL=y > diff --git a/drivers/clk/imx/Kconfig b/drivers/clk/imx/Kconfig index > 26cedbf..f7b3e3a 100644 > --- a/drivers/clk/imx/Kconfig > +++ b/drivers/clk/imx/Kconfig > @@ -3,6 +3,7 @@ > config MXC_CLK > tristate "IMX clock" > depends on ARCH_MXC > + def_tristate ARCH_MXC > > config MXC_CLK_SCU > tristate "IMX SCU clock" > > .config: > CONFIG_MXC_CLK=y > CONFIG_MXC_CLK_SCU=m > CONFIG_CLK_IMX8MM=m > CONFIG_CLK_IMX8MN=m > CONFIG_CLK_IMX8MP=m > CONFIG_CLK_IMX8MQ=m > CONFIG_CLK_IMX8QXP=m > > Anson
RE: [PATCH V2 2/9] ARM: imx: Select MXC_CLK for ARCH_MXC
> From: Anson Huang > Sent: Wednesday, June 17, 2020 8:36 PM > > > Subject: RE: [PATCH V2 2/9] ARM: imx: Select MXC_CLK for ARCH_MXC > > > > > From: Anson Huang > > > Sent: Tuesday, June 9, 2020 3:32 PM > > > > > > i.MX common clock drivers may support module build, so it is NOT > > > selected by default, for ARCH_MXC ARMv7 platforms, need to select it > > > manually to make build pass. > > > > > > Signed-off-by: Anson Huang > > > > Can't the original def_xxx work? > > > > config MXC_CLK > > tristate > > def_tristate ARCH_MXC > > Such change will make MXC_CLK=y even all i.MX8 SoCs clock drivers are selected > as module, so it does NOT meet the requirement of module support. Below is > from .config when all > i.MX8 SoCs clock drivers are configured to module. > > CONFIG_MXC_CLK=y > CONFIG_MXC_CLK_SCU=m > CONFIG_CLK_IMX8MM=m > CONFIG_CLK_IMX8MN=m > CONFIG_CLK_IMX8MP=m > CONFIG_CLK_IMX8MQ=m > CONFIG_CLK_IMX8QXP=m > It works at my side. Below is my changes based on your patchset: $ git diff diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index 47b10d20f411..e7d7b90e2cf8 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -4,7 +4,6 @@ menuconfig ARCH_MXC depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || ARM_SINGLE_ARMV7M select ARCH_SUPPORTS_BIG_ENDIAN select CLKSRC_IMX_GPT - select MXC_CLK select GENERIC_IRQ_CHIP select GPIOLIB select PINCTRL diff --git a/drivers/clk/imx/Kconfig b/drivers/clk/imx/Kconfig index 26cedbfe386c..f7b3e3a2cb9f 100644 --- a/drivers/clk/imx/Kconfig +++ b/drivers/clk/imx/Kconfig @@ -3,6 +3,7 @@ config MXC_CLK tristate "IMX clock" depends on ARCH_MXC + def_tristate ARCH_MXC config MXC_CLK_SCU tristate "IMX SCU clock" Regards Aisheng > Anson
RE: [PATCH V2 1/9] clk: composite: Export clk_hw_register_composite()
> From: Anson Huang > Sent: Wednesday, June 17, 2020 8:32 PM > > > Subject: RE: [PATCH V2 1/9] clk: composite: Export > > clk_hw_register_composite() > > > > > From: Anson Huang > > > Sent: Tuesday, June 9, 2020 3:32 PM > > > > > > Export clk_hw_register_composite() to support user built as module. > > > > > > ERROR: modpost: "clk_hw_register_composite" > > > [drivers/clk/imx/mxc-clk.ko] undefined! > > > scripts/Makefile.modpost:111: recipe for target 'Module.symvers' > > > failed > > > make[1]: *** [Module.symvers] Error 1 > > > make[1]: *** Deleting file 'Module.symvers' > > > Makefile:1384: recipe for target 'modules' failed > > > make: *** [modules] Error 2 > > > > > > Signed-off-by: Anson Huang > > > --- > > > No change. > > > --- > > > drivers/clk/clk-composite.c | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/drivers/clk/clk-composite.c > > > b/drivers/clk/clk-composite.c index 7376f57..2ddb54f 100644 > > > --- a/drivers/clk/clk-composite.c > > > +++ b/drivers/clk/clk-composite.c > > > @@ -328,6 +328,7 @@ struct clk_hw *clk_hw_register_composite(struct > > > device *dev, const char *name, > > > rate_hw, rate_ops, gate_hw, > > > gate_ops, flags); > > > } > > > +EXPORT_SYMBOL_GPL(clk_hw_register_composite); > > > > > > struct clk_hw *clk_hw_register_composite_pdata(struct device *dev, > > > const char *name, > > > > I guess you'd better add this one as well. > > I did NOT see this is used in upstream i.MX clock driver, from my test, it is > not > necessary so far. > Normally we could export them together in case it will be used in the future assuming your patch is making clk-composite be able to be used by modules. Anyway, it depends on Stephen's preference. Regards Aisheng > Anson
RE: [PATCH V2 3/9] clk: imx: Support building SCU clock driver as module
> From: Anson Huang > Sent: Wednesday, June 17, 2020 8:27 PM > > > > Subject: RE: [PATCH V2 3/9] clk: imx: Support building SCU clock > > driver as module > > > > > From: Anson Huang > > > Sent: Tuesday, June 9, 2020 3:32 PM > > > > > > There are more and more requirements of building SoC specific > > > drivers as modules, add support for building SCU clock driver as > > > module to meet the requirement. > > > > > > Signed-off-by: Anson Huang > > > --- > > > Changes since V1: > > > - add ARCH_MXC to build dependency to avoid build fail on x86 arch; > > > - move clk-lpcg-scu.c change in to this patch. > > > --- > > > drivers/clk/imx/Kconfig| 4 ++-- > > > drivers/clk/imx/Makefile | 5 ++--- > > > drivers/clk/imx/clk-lpcg-scu.c | 1 + > > > drivers/clk/imx/clk-scu.c | 5 + > > > 4 files changed, 10 insertions(+), 5 deletions(-) > > > > > > diff --git a/drivers/clk/imx/Kconfig b/drivers/clk/imx/Kconfig index > > > db0253f..ded0643 100644 > > > --- a/drivers/clk/imx/Kconfig > > > +++ b/drivers/clk/imx/Kconfig > > > @@ -5,8 +5,8 @@ config MXC_CLK > > > def_bool ARCH_MXC > > > > > > config MXC_CLK_SCU > > > - bool > > > - depends on IMX_SCU > > > > Keep this line as it is > > > > > + tristate "IMX SCU clock" > > > > i.MX SCU Clock core driver > > > > > + depends on ARCH_MXC && IMX_SCU > > > > > > config CLK_IMX8MM > > > bool "IMX8MM CCM Clock Driver" > > > diff --git a/drivers/clk/imx/Makefile b/drivers/clk/imx/Makefile > > > index 928f874..1af8cff 100644 > > > --- a/drivers/clk/imx/Makefile > > > +++ b/drivers/clk/imx/Makefile > > > @@ -21,9 +21,8 @@ obj-$(CONFIG_MXC_CLK) += \ > > > clk-sscg-pll.o \ > > > clk-pll14xx.o > > > > > > -obj-$(CONFIG_MXC_CLK_SCU) += \ > > > - clk-scu.o \ > > > - clk-lpcg-scu.o > > > +mxc-clk-scu-objs += clk-scu.o clk-lpcg-scu.o > > > +obj-$(CONFIG_MXC_CLK_SCU) += mxc-clk-scu.o > > > > Like i.MX pinctrl, I'm not sure if it's really necessary to build core > > libraries as modules. Probably the simplest way is only building > > platform drivers part as module. And leave those core libraries built in > > kernel. > > This may make the code a bit cleaner. > > > > Will discuss this with Linaro guys about it, previous requirement I received > is all > SoC specific modules need to be built as module. > Okay. AFAIK it's not conflict. You still make drivers into modules. Only difference is for those common libraries part, we don't convert them into module Which is less meaningless. Regards Aisheng > Anson
RE: [PATCH V2 3/9] clk: imx: Support building SCU clock driver as module
> From: Anson Huang
> Sent: Tuesday, June 9, 2020 3:32 PM
>
> There are more and more requirements of building SoC specific drivers as
> modules, add support for building SCU clock driver as module to meet the
> requirement.
>
> Signed-off-by: Anson Huang
> ---
> Changes since V1:
> - add ARCH_MXC to build dependency to avoid build fail on x86 arch;
> - move clk-lpcg-scu.c change in to this patch.
> ---
> drivers/clk/imx/Kconfig| 4 ++--
> drivers/clk/imx/Makefile | 5 ++---
> drivers/clk/imx/clk-lpcg-scu.c | 1 +
> drivers/clk/imx/clk-scu.c | 5 +
> 4 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/clk/imx/Kconfig b/drivers/clk/imx/Kconfig index
> db0253f..ded0643 100644
> --- a/drivers/clk/imx/Kconfig
> +++ b/drivers/clk/imx/Kconfig
> @@ -5,8 +5,8 @@ config MXC_CLK
> def_bool ARCH_MXC
>
> config MXC_CLK_SCU
> - bool
> - depends on IMX_SCU
Keep this line as it is
> + tristate "IMX SCU clock"
i.MX SCU Clock core driver
> + depends on ARCH_MXC && IMX_SCU
>
> config CLK_IMX8MM
> bool "IMX8MM CCM Clock Driver"
> diff --git a/drivers/clk/imx/Makefile b/drivers/clk/imx/Makefile index
> 928f874..1af8cff 100644
> --- a/drivers/clk/imx/Makefile
> +++ b/drivers/clk/imx/Makefile
> @@ -21,9 +21,8 @@ obj-$(CONFIG_MXC_CLK) += \
> clk-sscg-pll.o \
> clk-pll14xx.o
>
> -obj-$(CONFIG_MXC_CLK_SCU) += \
> - clk-scu.o \
> - clk-lpcg-scu.o
> +mxc-clk-scu-objs += clk-scu.o clk-lpcg-scu.o
> +obj-$(CONFIG_MXC_CLK_SCU) += mxc-clk-scu.o
Like i.MX pinctrl, I'm not sure if it's really necessary to build core libraries
as modules. Probably the simplest way is only building platform drivers part
as module. And leave those core libraries built in kernel.
This may make the code a bit cleaner.
Regards
Aisheng
>
> obj-$(CONFIG_CLK_IMX8MM) += clk-imx8mm.o
> obj-$(CONFIG_CLK_IMX8MN) += clk-imx8mn.o diff --git
> a/drivers/clk/imx/clk-lpcg-scu.c b/drivers/clk/imx/clk-lpcg-scu.c index
> a73a799..8177f0e 100644
> --- a/drivers/clk/imx/clk-lpcg-scu.c
> +++ b/drivers/clk/imx/clk-lpcg-scu.c
> @@ -114,3 +114,4 @@ struct clk_hw *imx_clk_lpcg_scu(const char *name,
> const char *parent_name,
>
> return hw;
> }
> +EXPORT_SYMBOL_GPL(imx_clk_lpcg_scu);
> diff --git a/drivers/clk/imx/clk-scu.c b/drivers/clk/imx/clk-scu.c index
> b8b2072..9688981 100644
> --- a/drivers/clk/imx/clk-scu.c
> +++ b/drivers/clk/imx/clk-scu.c
> @@ -8,6 +8,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "clk-scu.h"
> @@ -132,6 +133,7 @@ int imx_clk_scu_init(void) {
> return imx_scu_get_handle(_ipc_handle);
> }
> +EXPORT_SYMBOL_GPL(imx_clk_scu_init);
>
> /*
> * clk_scu_recalc_rate - Get clock rate for a SCU clock @@ -387,3 +389,6 @@
> struct clk_hw *__imx_clk_scu(const char *name, const char * const *parents,
>
> return hw;
> }
> +EXPORT_SYMBOL_GPL(__imx_clk_scu);
> +
> +MODULE_LICENSE("GPL v2");
> --
> 2.7.4
RE: [PATCH V2 2/9] ARM: imx: Select MXC_CLK for ARCH_MXC
> From: Anson Huang > Sent: Tuesday, June 9, 2020 3:32 PM > > i.MX common clock drivers may support module build, so it is NOT selected by > default, for ARCH_MXC ARMv7 platforms, need to select it manually to make > build pass. > > Signed-off-by: Anson Huang Can't the original def_xxx work? config MXC_CLK tristate def_tristate ARCH_MXC Regards Aisheng > --- > No change. > --- > arch/arm/mach-imx/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index > e7d7b90..47b10d2 100644 > --- a/arch/arm/mach-imx/Kconfig > +++ b/arch/arm/mach-imx/Kconfig > @@ -4,6 +4,7 @@ menuconfig ARCH_MXC > depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || > ARM_SINGLE_ARMV7M > select ARCH_SUPPORTS_BIG_ENDIAN > select CLKSRC_IMX_GPT > + select MXC_CLK > select GENERIC_IRQ_CHIP > select GPIOLIB > select PINCTRL > -- > 2.7.4
RE: [PATCH V5 1/9] pinctrl: imx: Support building SCU pinctrl driver as module
[...]
> > > > > - * @dev: a pointer back to containing device
> > > > > - * @base: the offset to the controller in virtual memory
> > > > > - */
> > > > > -struct imx_pinctrl {
> > > > > - struct device *dev;
> > > > > - struct pinctrl_dev *pctl;
> > > > > - void __iomem *base;
> > > > > - void __iomem *input_sel_base;
> > > > > - const struct imx_pinctrl_soc_info *info;
> > > > > - struct imx_pin_reg *pin_regs;
> > > > > - unsigned int group_index;
> > > > > - struct mutex mutex;
> > > > > + int (*imx_pinconf_get)(struct pinctrl_dev *pctldev, unsigned
> > > > > +int
> > pin_id,
> > > > > +unsigned long *config);
> > > > > + int (*imx_pinconf_set)(struct pinctrl_dev *pctldev, unsigned
> > > > > +int
> > pin_id,
> > > > > +unsigned long *configs, unsigned int
> > > > > num_configs);
> > > > > + void (*imx_pinctrl_parse_pin)(struct imx_pinctrl *ipctl,
> > > > > + unsigned int *pin_id, struct
> > > > > imx_pin *pin,
> > > > > + const __be32 **list_p);
> > > >
> > > > Compared with V4, this new implementation seems a bit complicated.
> > > > I guess we don't have to support PINCTRL_IMX=y &&
> > > > PINCTRL_IMX_SCU=m case.
> > > > Will that make the support a bit easier?
> > >
> > > I am NOT sure if such scenario meets requirement, the fact is other
> > > non-i.MX SoC also selects the PINCTRL_IMX which will make
> > > PINCTRL_IMX=y, so in that case, even all i.MX PINCTRL drivers are
> > > set to module, it will still have PINCTRL_IMX=y and
> > > PINCTRL_IMX_SCU=m, then build will fail. And I believe the auto
> > > build test may also cover such case and build error will be
> > > reported, that is why this change is needed and with this change,
> > > function is NOT impacted,
> > >
> >
> > Is it possible to add some constrainst to make sure PINCTRL_IMX_SCU
> > value is the same as PINCTRL_IMX? Or combine them into one?
> > If we can do that, it may ease the implementation a lot and make the
> > code still clean.
>
> Combine PINCTRL_IMX_SCU and PINCTRL_IMX is NOT making sense, since for
> non-SCU platforms, PINCTRL_IMX_SCU is NOT necessary, to make
> PINCTRL_IMX_SCU same value as PINCTRL_IMX, unless make "select
> PINCTRL_IMX_SCU" in PINCTRL_IMX, but that is also NOT making sense,
> because, PINCTRL_IMX does NOT depends on PINCTRL_IMX_SCU at all.
>
PINCTRL_IMX_SCU could be conditionally compiled.
Something like follows:
obj-$(CONFIG_PINCTRL_IMX) += pinctrl-imx-core.o
pinctrl-imx-core-y := pinctrl-imx.o
pinctrl-imx-core-$(CONFIG_PINCTRL_IMX_SCU) += pinctrl-scu.o
Can you try if this way could work?
Regards
Aisheng
> The change is NOT that big IMO, and no better idea in my mind, have tried that
> in previous versions of patch series.
>
> Anson
RE: [PATCH V2 1/9] clk: composite: Export clk_hw_register_composite()
> From: Anson Huang > Sent: Tuesday, June 9, 2020 3:32 PM > > Export clk_hw_register_composite() to support user built as module. > > ERROR: modpost: "clk_hw_register_composite" [drivers/clk/imx/mxc-clk.ko] > undefined! > scripts/Makefile.modpost:111: recipe for target 'Module.symvers' failed > make[1]: *** [Module.symvers] Error 1 > make[1]: *** Deleting file 'Module.symvers' > Makefile:1384: recipe for target 'modules' failed > make: *** [modules] Error 2 > > Signed-off-by: Anson Huang > --- > No change. > --- > drivers/clk/clk-composite.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c index > 7376f57..2ddb54f 100644 > --- a/drivers/clk/clk-composite.c > +++ b/drivers/clk/clk-composite.c > @@ -328,6 +328,7 @@ struct clk_hw *clk_hw_register_composite(struct > device *dev, const char *name, > rate_hw, rate_ops, gate_hw, > gate_ops, flags); > } > +EXPORT_SYMBOL_GPL(clk_hw_register_composite); > > struct clk_hw *clk_hw_register_composite_pdata(struct device *dev, > const char *name, I guess you'd better add this one as well. Regards Aisheng > -- > 2.7.4
RE: [PATCH] thermal: imx8mm: Support module autoloading
> From: Anson Huang > Sent: Wednesday, June 17, 2020 3:48 PM > > Add a missing MODULE_DEVICE_TABLE entry to support module autoloading. > > Signed-off-by: Anson Huang Reviewed-by: Dong Aisheng Regards Aisheng
RE: [PATCH] soc: imx-scu: Support module build
> From: Anson Huang
> Sent: Wednesday, June 17, 2020 12:54 PM
>
> Change the configuration type to tristate, add module description, author and
> license to support module build.
>
> Signed-off-by: Anson Huang
> ---
> drivers/soc/imx/Kconfig | 2 +-
> drivers/soc/imx/soc-imx-scu.c | 5 +
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/imx/Kconfig b/drivers/soc/imx/Kconfig index
> d515d2c..c255acb 100644
> --- a/drivers/soc/imx/Kconfig
> +++ b/drivers/soc/imx/Kconfig
> @@ -9,7 +9,7 @@ config IMX_GPCV2_PM_DOMAINS
> default y if SOC_IMX7D
>
> config IMX_SCU_SOC
> - bool "i.MX System Controller Unit SoC info support"
> + tristate "i.MX System Controller Unit SoC info support"
> depends on IMX_SCU
> select SOC_BUS
> help
> diff --git a/drivers/soc/imx/soc-imx-scu.c b/drivers/soc/imx/soc-imx-scu.c
> index
> 20d37ea..bdd43ed 100644
> --- a/drivers/soc/imx/soc-imx-scu.c
> +++ b/drivers/soc/imx/soc-imx-scu.c
> @@ -5,6 +5,7 @@
>
> #include #include
>
> +#include
> #include
> #include
> #include
> @@ -185,3 +186,7 @@ static int __init imx_scu_soc_init(void)
> return PTR_ERR_OR_ZERO(pdev);
> }
> device_initcall(imx_scu_soc_init);
> +
> +MODULE_AUTHOR("Anson Huang ");
> +MODULE_DESCRIPTION("NXP i.MX SCU SoC driver"); MODULE_LICENSE("GPL
> +v2");
I'm ok with the change. But I'm curious how can this module be autoloaded
without MODULE_DEVICE_TABLE.
Have you tested if it can work?
Regards
Aisheng
> --
> 2.7.4
RE: [PATCH V5 1/9] pinctrl: imx: Support building SCU pinctrl driver as module
> From: Anson Huang
> Sent: Tuesday, June 16, 2020 6:44 PM
>
> > Subject: RE: [PATCH V5 1/9] pinctrl: imx: Support building SCU pinctrl
> > driver as module
> >
> > > From: Anson Huang
> > > Sent: Thursday, June 11, 2020 7:35 PM
> > >
> > > To support building i.MX SCU pinctrl driver as module, below things
> > > need to be
> > > changed:
> > >
> > > - Export SCU related functions and use "IS_ENABLED" instead of
> > > "ifdef" to support SCU pinctrl driver user and itself to be
> > > built as module;
> > > - Use function callbacks for SCU related functions in pinctrl-imx.c
> > > in order to support the scenario of PINCTRL_IMX is built in
> > > while PINCTRL_IMX_SCU is built as module;
> > > - All drivers using SCU pinctrl driver need to initialize the
> > > SCU related function callback;
> > > - Change PINCTR_IMX_SCU to tristate;
> > > - Add module author, description and license.
> > >
> > > With above changes, i.MX SCU pinctrl driver can be built as module.
> > >
> > > Signed-off-by: Anson Huang
> > > ---
> > > Changes since V4:
> > > - add module author and description.
> > > ---
> > > drivers/pinctrl/freescale/Kconfig | 2 +-
> > > drivers/pinctrl/freescale/pinctrl-imx.c | 18 -
> > > drivers/pinctrl/freescale/pinctrl-imx.h | 57
> -
> > > drivers/pinctrl/freescale/pinctrl-imx8dxl.c | 3 ++
> > > drivers/pinctrl/freescale/pinctrl-imx8qm.c | 3 ++
> > > drivers/pinctrl/freescale/pinctrl-imx8qxp.c | 3 ++
> > > drivers/pinctrl/freescale/pinctrl-scu.c | 9 +
> > > 7 files changed, 51 insertions(+), 44 deletions(-)
> > >
> > > diff --git a/drivers/pinctrl/freescale/Kconfig
> > > b/drivers/pinctrl/freescale/Kconfig
> > > index 4ca44dd..a3a30f1d 100644
> > > --- a/drivers/pinctrl/freescale/Kconfig
> > > +++ b/drivers/pinctrl/freescale/Kconfig
> > > @@ -7,7 +7,7 @@ config PINCTRL_IMX
> > > select REGMAP
> > >
> > > config PINCTRL_IMX_SCU
> > > - bool
> > > + tristate "IMX SCU pinctrl driver"
> > > depends on IMX_SCU
> > > select PINCTRL_IMX
> > >
> > > diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c
> > > b/drivers/pinctrl/freescale/pinctrl-imx.c
> > > index cb7e0f0..c1faae1 100644
> > > --- a/drivers/pinctrl/freescale/pinctrl-imx.c
> > > +++ b/drivers/pinctrl/freescale/pinctrl-imx.c
> > > @@ -372,8 +372,8 @@ static int imx_pinconf_get(struct pinctrl_dev
> > *pctldev,
> > > struct imx_pinctrl *ipctl = pinctrl_dev_get_drvdata(pctldev);
> > > const struct imx_pinctrl_soc_info *info = ipctl->info;
> > >
> > > - if (info->flags & IMX_USE_SCU)
> > > - return imx_pinconf_get_scu(pctldev, pin_id, config);
> > > + if ((info->flags & IMX_USE_SCU) && info->imx_pinconf_get)
> > > + return info->imx_pinconf_get(pctldev, pin_id, config);
> >
> > Pointer check here seems not be necessary
>
> I think it is NOT harmful and it is just in case the drivers using scu
> pinctrl do NOT
> initialize these functions callback and lead to NULL pointer dump.
>
It is a bit harmful to the code readability as we already use flag IMX_USE_SCU
to distinguish
the difference. Not need double check the pointer again because platforms
driver must have
defined it.
> >
> > > diff --git a/drivers/pinctrl/freescale/pinctrl-imx.h
> > > b/drivers/pinctrl/freescale/pinctrl-imx.h
> > > index 333d32b..bdb86c2 100644
> > > --- a/drivers/pinctrl/freescale/pinctrl-imx.h
> > > +++ b/drivers/pinctrl/freescale/pinctrl-imx.h
> > > @@ -75,6 +75,21 @@ struct imx_cfg_params_decode {
> > > bool invert;
> > > };
> > >
> > > +/**
> > > + * @dev: a pointer back to containing device
> > > + * @base: the offset to the controller in virtual memory */ struct
> > > +imx_pinctrl {
> > > + struct device *dev;
> > > + struct pinctrl_dev *pctl;
> > > + void __iomem *base;
> > > + void __iomem *input_sel_base;
> > > + const struct imx_pinctrl_soc_info *info;
> > > + struct imx_pin_reg *pin_regs;
> > > + unsigned int group_index;
> > > + struct mutex mutex;
> > > +};
> > > +
> > > struct imx_pinctrl_soc_info {
> > > const struct pinctrl_pin_desc *pins;
> > > unsigned int npins;
> > > @@ -98,21 +113,13 @@ struct imx_pinctrl_soc_info {
> > > struct pinctrl_gpio_range *range,
> > > unsigned offset,
> > > bool input);
> > > -};
> > > -
> > > -/**
> > > - * @dev: a pointer back to containing device
> > > - * @base: the offset to the controller in virtual memory
> > > - */
> > > -struct imx_pinctrl {
> > > - struct device *dev;
> > > - struct pinctrl_dev *pctl;
> > > - void __iomem *base;
> > > - void __iomem *input_sel_base;
> > > - const struct imx_pinctrl_soc_info *info;
> > > - struct imx_pin_reg *pin_regs;
> > > - unsigned int group_index;
> > > - struct mutex mutex;
> > > + int (*imx_pinconf_get)(struct pinctrl_dev *pctldev, unsigned int pin_id,
> > > +unsigned long *config);
> > > + int
RE: [PATCH V5 1/9] pinctrl: imx: Support building SCU pinctrl driver as module
> From: Anson Huang
> Sent: Thursday, June 11, 2020 7:35 PM
>
> To support building i.MX SCU pinctrl driver as module, below things need to be
> changed:
>
> - Export SCU related functions and use "IS_ENABLED" instead of
> "ifdef" to support SCU pinctrl driver user and itself to be
> built as module;
> - Use function callbacks for SCU related functions in pinctrl-imx.c
> in order to support the scenario of PINCTRL_IMX is built in
> while PINCTRL_IMX_SCU is built as module;
> - All drivers using SCU pinctrl driver need to initialize the
> SCU related function callback;
> - Change PINCTR_IMX_SCU to tristate;
> - Add module author, description and license.
>
> With above changes, i.MX SCU pinctrl driver can be built as module.
>
> Signed-off-by: Anson Huang
> ---
> Changes since V4:
> - add module author and description.
> ---
> drivers/pinctrl/freescale/Kconfig | 2 +-
> drivers/pinctrl/freescale/pinctrl-imx.c | 18 -
> drivers/pinctrl/freescale/pinctrl-imx.h | 57
> -
> drivers/pinctrl/freescale/pinctrl-imx8dxl.c | 3 ++
> drivers/pinctrl/freescale/pinctrl-imx8qm.c | 3 ++
> drivers/pinctrl/freescale/pinctrl-imx8qxp.c | 3 ++
> drivers/pinctrl/freescale/pinctrl-scu.c | 9 +
> 7 files changed, 51 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/pinctrl/freescale/Kconfig
> b/drivers/pinctrl/freescale/Kconfig
> index 4ca44dd..a3a30f1d 100644
> --- a/drivers/pinctrl/freescale/Kconfig
> +++ b/drivers/pinctrl/freescale/Kconfig
> @@ -7,7 +7,7 @@ config PINCTRL_IMX
> select REGMAP
>
> config PINCTRL_IMX_SCU
> - bool
> + tristate "IMX SCU pinctrl driver"
> depends on IMX_SCU
> select PINCTRL_IMX
>
> diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c
> b/drivers/pinctrl/freescale/pinctrl-imx.c
> index cb7e0f0..c1faae1 100644
> --- a/drivers/pinctrl/freescale/pinctrl-imx.c
> +++ b/drivers/pinctrl/freescale/pinctrl-imx.c
> @@ -372,8 +372,8 @@ static int imx_pinconf_get(struct pinctrl_dev *pctldev,
> struct imx_pinctrl *ipctl = pinctrl_dev_get_drvdata(pctldev);
> const struct imx_pinctrl_soc_info *info = ipctl->info;
>
> - if (info->flags & IMX_USE_SCU)
> - return imx_pinconf_get_scu(pctldev, pin_id, config);
> + if ((info->flags & IMX_USE_SCU) && info->imx_pinconf_get)
> + return info->imx_pinconf_get(pctldev, pin_id, config);
Pointer check here seems not be necessary
> diff --git a/drivers/pinctrl/freescale/pinctrl-imx.h
> b/drivers/pinctrl/freescale/pinctrl-imx.h
> index 333d32b..bdb86c2 100644
> --- a/drivers/pinctrl/freescale/pinctrl-imx.h
> +++ b/drivers/pinctrl/freescale/pinctrl-imx.h
> @@ -75,6 +75,21 @@ struct imx_cfg_params_decode {
> bool invert;
> };
>
> +/**
> + * @dev: a pointer back to containing device
> + * @base: the offset to the controller in virtual memory */ struct
> +imx_pinctrl {
> + struct device *dev;
> + struct pinctrl_dev *pctl;
> + void __iomem *base;
> + void __iomem *input_sel_base;
> + const struct imx_pinctrl_soc_info *info;
> + struct imx_pin_reg *pin_regs;
> + unsigned int group_index;
> + struct mutex mutex;
> +};
> +
> struct imx_pinctrl_soc_info {
> const struct pinctrl_pin_desc *pins;
> unsigned int npins;
> @@ -98,21 +113,13 @@ struct imx_pinctrl_soc_info {
> struct pinctrl_gpio_range *range,
> unsigned offset,
> bool input);
> -};
> -
> -/**
> - * @dev: a pointer back to containing device
> - * @base: the offset to the controller in virtual memory
> - */
> -struct imx_pinctrl {
> - struct device *dev;
> - struct pinctrl_dev *pctl;
> - void __iomem *base;
> - void __iomem *input_sel_base;
> - const struct imx_pinctrl_soc_info *info;
> - struct imx_pin_reg *pin_regs;
> - unsigned int group_index;
> - struct mutex mutex;
> + int (*imx_pinconf_get)(struct pinctrl_dev *pctldev, unsigned int pin_id,
> +unsigned long *config);
> + int (*imx_pinconf_set)(struct pinctrl_dev *pctldev, unsigned int pin_id,
> +unsigned long *configs, unsigned int
> num_configs);
> + void (*imx_pinctrl_parse_pin)(struct imx_pinctrl *ipctl,
> + unsigned int *pin_id, struct imx_pin *pin,
> + const __be32 **list_p);
Compared with V4, this new implementation seems a bit complicated.
I guess we don't have to support PINCTRL_IMX=y && PINCTRL_IMX_SCU=m case.
Will that make the support a bit easier?
Regards
Aisheng
> };
>
> #define IMX_CFG_PARAMS_DECODE(p, m, o) \ @@ -137,7 +144,7 @@ struct
> imx_pinctrl { int imx_pinctrl_probe(struct platform_device *pdev,
> const struct imx_pinctrl_soc_info *info);
>
> -#ifdef CONFIG_PINCTRL_IMX_SCU
> +#if
RE: [PATCH] i2c: imx: Fix external abort on early interrupt
> From: Wolfram Sang > Sent: Friday, June 12, 2020 9:00 PM > > On Fri, Jun 12, 2020 at 02:18:06PM +0200, Marc Kleine-Budde wrote: > > On 6/12/20 1:51 PM, Wolfram Sang wrote: > > > > > >> This basically kills the concept of devm for interrupts. Some other > > > > > > It only works when you can ensure you have all interrupts disabled > > > (and none pending) in remove() or the error paths of probe() etc. > > > > But when requesting the interrupt as shared the interrupt handler can > > get called any time, even if you have disabled the IRQ source in your > > IP coreThe shared IRQ debug code tests this. > > Yes, so you'd need something like > > if (clks_are_off) > return IRQ_NONE; > I understand this. But .. > or skip devm_ for interrupts and handle it manually. (IIRC the input subsystem > really frowns upon devm + irqs for such reasons) > > D'accord? Handle it manually looks to me can only address the issue for probe error path. But how can it handle the normal running cases that shared irq arrived when device is in runtime suspend state? Regards Aisheng
RE: [PATCH] [v3] i2c: imx-lpi2c: Fix runtime PM imbalance on error
> From: Wolfram Sang > Sent: Sunday, June 14, 2020 5:12 PM > > On Mon, Jun 01, 2020 at 02:16:40PM +0800, Dinghao Liu wrote: > > pm_runtime_get_sync() increments the runtime PM usage counter even the > > call returns an error code. Thus a corresponding decrement is needed > > on the error handling path to keep the counter balanced. > > Can you point me to a discussion where it was decided that this is a proper > fix? > I'd think we rather should fix pm_runtime_get_sync() but maybe there are > technical reasons against it. I had the same feeling. Copy pm guys to comments. Regards Aisheng
RE: [PATCH] i2c: busses: Fix a reference count leak.
> From: Andy Duan
> Sent: Monday, June 15, 2020 10:49 AM
>
> From: wu000...@umn.edu Sent: Sunday, June 14,
> 2020 6:12 AM
> > From: Qiushi Wu
> >
> > pm_runtime_get_sync() increments the runtime PM usage counter even
> > when it returns an error code. Thus call pm_runtime_put_noidle() if
> > pm_runtime_get_sync() fails.
> >
> > Fixes: 13d6eb20fc79 ("i2c: imx-lpi2c: add runtime pm support")
> > Signed-off-by: Qiushi Wu
>
> Again, which case can trigger the issue ?
It's just error handling improvement because pm_runtime_get_sync() will
increase the
reference count even it's failed.
I wonder if such de-reference can be better handled by pm runtime core code.
Copy pm guys to comment.
Regards
Aisheng
> > ---
> > drivers/i2c/busses/i2c-imx-lpi2c.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c
> > b/drivers/i2c/busses/i2c-imx-lpi2c.c
> > index 9db6ccded5e9..85b9c1fc7681 100644
> > --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> > +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> > @@ -260,8 +260,10 @@ static int lpi2c_imx_master_enable(struct
> > lpi2c_imx_struct *lpi2c_imx)
> > int ret;
> >
> > ret = pm_runtime_get_sync(lpi2c_imx->adapter.dev.parent);
> > - if (ret < 0)
> > + if (ret < 0) {
> > + pm_runtime_put_noidle(lpi2c_imx->adapter.dev.parent);
> > return ret;
> > + }
> >
> > temp = MCR_RST;
> > writel(temp, lpi2c_imx->base + LPI2C_MCR);
> > --
> > 2.17.1
RE: [PATCH V3 0/9] Support i.MX8 SoCs pinctrl drivers built as module
> From: Anson Huang > Sent: Tuesday, June 9, 2020 10:21 PM > > There are more and mroe requirements that SoC specific modules should be > built as module in order to support generic kernel image, such as Android GKI > concept. > > This patch series supports i.MX8 SoCs pinctrl drivers to be built as module, > including i.MX8MQ/MM/MN/MP/QXP/QM/DXL SoCs, and it also supports > building i.MX common pinctrl driver and i.MX SCU common pinctrl driver as > module. > This patch series also changed the driver initcall level from arch_initcall to module_init. Maybe you could provide some test information to help the reviewer to better understand the change impact. Regards Aisheng > Compared to V2, the changes are as below: > - add "depends on OF" to PINCTRL_IMX to fix build error using x86 > randconfig; > - change the config dependency of PINCTRL_IMX_SCU to support scenario > of > building in PINCTRL_IMX while building PINCTRL_IMX_SCU as module, > no other > good choice in my mind, if you have better idea without changing the > driver > code, please advise. > > Anson Huang (9): > pinctrl: imx: Support building SCU pinctrl driver as module > pinctrl: imx: Support building i.MX pinctrl driver as module > pinctrl: imx8mm: Support building as module > pinctrl: imx8mn: Support building as module > pinctrl: imx8mq: Support building as module > pinctrl: imx8mp: Support building as module > pinctrl: imx8qxp: Support building as module > pinctrl: imx8qm: Support building as module > pinctrl: imx8dxl: Support building as module > > drivers/pinctrl/freescale/Kconfig | 27 ++- > drivers/pinctrl/freescale/pinctrl-imx.c | 4 > drivers/pinctrl/freescale/pinctrl-imx.h | 2 +- > drivers/pinctrl/freescale/pinctrl-imx8dxl.c | 9 +++-- > drivers/pinctrl/freescale/pinctrl-imx8mm.c | 10 -- > drivers/pinctrl/freescale/pinctrl-imx8mn.c | 10 -- > drivers/pinctrl/freescale/pinctrl-imx8mp.c | 10 -- > drivers/pinctrl/freescale/pinctrl-imx8mq.c | 9 - > drivers/pinctrl/freescale/pinctrl-imx8qm.c | 9 +++-- > drivers/pinctrl/freescale/pinctrl-imx8qxp.c | 9 +++-- > drivers/pinctrl/freescale/pinctrl-scu.c | 6 ++ > 11 files changed, 50 insertions(+), 55 deletions(-) > > -- > 2.7.4
RE: [PATCH V2] soc: imx8m: Correct i.MX8MP UID fuse offset
> From: Anson Huang
> Sent: Wednesday, June 10, 2020 6:42 AM
>
> Correct i.MX8MP UID fuse offset according to fuse map:
>
> UID_LOW: 0x420
> UID_HIGH: 0x430
>
> Fixes: fc40200ebf82 ("soc: imx: increase build coverage for imx8m soc driver")
AFAIK "Fixes:" should point to the original patch which introduced the issue.
Not the one changing file name.
> Signed-off-by: Anson Huang
> ---
> Changes since V1:
> - add fix tag.
> ---
> drivers/soc/imx/soc-imx8m.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/soc/imx/soc-imx8m.c b/drivers/soc/imx/soc-imx8m.c index
> 7b0759a..0bc8314 100644
> --- a/drivers/soc/imx/soc-imx8m.c
> +++ b/drivers/soc/imx/soc-imx8m.c
> @@ -22,6 +22,8 @@
> #define OCOTP_UID_LOW0x410
> #define OCOTP_UID_HIGH 0x420
>
> +#define IMX8MP_OCOTP_UID_OFFSET 0x10
> +
> /* Same as ANADIG_DIGPROG_IMX7D */
> #define ANADIG_DIGPROG_IMX8MM0x800
>
> @@ -87,6 +89,8 @@ static void __init imx8mm_soc_uid(void) {
> void __iomem *ocotp_base;
> struct device_node *np;
> + u32 offset = of_machine_is_compatible("fsl,imx8mp") ?
> + IMX8MP_OCOTP_UID_OFFSET : 0;
>
If (of_machine_is_compatible("fsl,imx8mp"))
Octop_base += IMX8MP_OCOTP_UID_OFFSET;
Then you may not need the extra changes.
Regards
Aisheng
> np = of_find_compatible_node(NULL, NULL, "fsl,imx8mm-ocotp");
> if (!np)
> @@ -95,9 +99,9 @@ static void __init imx8mm_soc_uid(void)
> ocotp_base = of_iomap(np, 0);
> WARN_ON(!ocotp_base);
>
> - soc_uid = readl_relaxed(ocotp_base + OCOTP_UID_HIGH);
> + soc_uid = readl_relaxed(ocotp_base + OCOTP_UID_HIGH + offset);
> soc_uid <<= 32;
> - soc_uid |= readl_relaxed(ocotp_base + OCOTP_UID_LOW);
> + soc_uid |= readl_relaxed(ocotp_base + OCOTP_UID_LOW + offset);
>
> iounmap(ocotp_base);
> of_node_put(np);
> --
> 2.7.4
RE: [PATCH] soc: imx: scu: use devm_kasprintf
> From: Peng Fan > Sent: Wednesday, June 3, 2020 5:30 PM > > Use devm_kasprintf to simplify code > > Signed-off-by: Peng Fan Reviewed-by: Dong Aisheng Regards Aisheng
RE: [PATCH V2] dt-bindings: clock: Convert imx7ulp clock to json-schema
> From: Anson Huang > Sent: Thursday, June 4, 2020 9:33 AM > > Convert the i.MX7ULP clock binding to DT schema format using json-schema, > the original binding doc is actually for two clock modules(SCG and PCC), so > split > it to two binding docs, and the MPLL(mipi PLL) is NOT supposed to be in clock > module, so remove it from binding doc as well. > > Signed-off-by: Anson Huang Reviewed-by: Dong Aisheng Regards Aisheng
RE: [PATCH V2 2/3] firmware: imx: add resource management api
> From: Peng Fan
> Sent: Wednesday, June 3, 2020 11:32 AM
>
> Add resource management API, when we have multiple partition running
> together, resources not owned to current partition should not be used.
>
> Reviewed-by: Leonard Crestez
> Signed-off-by: Peng Fan
> ---
> drivers/firmware/imx/Makefile | 2 +-
> drivers/firmware/imx/rm.c | 45
> include/linux/firmware/imx/sci.h| 1 +
> include/linux/firmware/imx/svc/rm.h | 69
> +
> 4 files changed, 116 insertions(+), 1 deletion(-) create mode 100644
> drivers/firmware/imx/rm.c create mode 100644
> include/linux/firmware/imx/svc/rm.h
>
> diff --git a/drivers/firmware/imx/Makefile b/drivers/firmware/imx/Makefile
> index 08bc9ddfbdfb..17ea3613e142 100644
> --- a/drivers/firmware/imx/Makefile
> +++ b/drivers/firmware/imx/Makefile
> @@ -1,4 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0
> obj-$(CONFIG_IMX_DSP)+= imx-dsp.o
> -obj-$(CONFIG_IMX_SCU)+= imx-scu.o misc.o imx-scu-irq.o
> +obj-$(CONFIG_IMX_SCU)+= imx-scu.o misc.o imx-scu-irq.o rm.o
> obj-$(CONFIG_IMX_SCU_PD) += scu-pd.o
> diff --git a/drivers/firmware/imx/rm.c b/drivers/firmware/imx/rm.c new file
> mode 100644 index ..a12db6ff323b
> --- /dev/null
> +++ b/drivers/firmware/imx/rm.c
> @@ -0,0 +1,45 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2020 NXP
> + *
> + * File containing client-side RPC functions for the RM service. These
> + * function are ported to clients that communicate to the SC.
> + */
> +
> +#include
> +
> +struct imx_sc_msg_rm_rsrc_owned {
> + struct imx_sc_rpc_msg hdr;
> + u16 resource;
> +} __packed __aligned(4);
> +
> +/*
> + * This function check @resource is owned by current partition or not
> + *
> + * @param[in] ipc IPC handle
> + * @param[in] resourceresource the control is associated with
> + *
> + * @return Returns 0 for not owned and 1 for owned.
> + */
> +bool imx_sc_rm_is_resource_owned(struct imx_sc_ipc *ipc, u16 resource)
> +{
> + struct imx_sc_msg_rm_rsrc_owned msg;
> + struct imx_sc_rpc_msg *hdr =
> +
> + hdr->ver = IMX_SC_RPC_VERSION;
> + hdr->svc = IMX_SC_RPC_SVC_RM;
> + hdr->func = IMX_SC_RM_FUNC_IS_RESOURCE_OWNED;
> + hdr->size = 2;
> +
> + msg.resource = resource;
> +
> + /*
> + * SCU firmware only returns value 0 or 1
> + * for resource owned check which means not owned or owned.
> + * So it is always successful.
> + */
> + imx_scu_call_rpc(ipc, , true);
> +
> + return hdr->func;
> +}
> +EXPORT_SYMBOL(imx_sc_rm_is_resource_owned);
> diff --git a/include/linux/firmware/imx/sci.h
> b/include/linux/firmware/imx/sci.h
> index 3fa418a4ca67..3c459f54a88f 100644
> --- a/include/linux/firmware/imx/sci.h
> +++ b/include/linux/firmware/imx/sci.h
> @@ -14,6 +14,7 @@
>
> #include #include
>
> +#include
>
> int imx_scu_enable_general_irq_channel(struct device *dev); int
> imx_scu_irq_register_notifier(struct notifier_block *nb); diff --git
> a/include/linux/firmware/imx/svc/rm.h b/include/linux/firmware/imx/svc/rm.h
> new file mode 100644
> index ..9924216f3e45
> --- /dev/null
> +++ b/include/linux/firmware/imx/svc/rm.h
> @@ -0,0 +1,69 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + * Copyright 2017-2020 NXP
> + *
> + * Header file containing the public API for the System Controller (SC)
> + * Power Management (PM) function. This includes functions for power
> +state
> + * control, clock control, reset control, and wake-up event control.
Fix the code comments.
Otherwise:
Dong Aisheng
Regards
Aisheng
RE: [PATCH 2/4] firmware: imx: add resource management api
> From: Peng Fan > Sent: Tuesday, June 2, 2020 3:48 PM > > > > > From: Peng Fan > > > Sent: Tuesday, June 2, 2020 12:51 PM > > > > > > > > > From: Peng Fan > > > > > Sent: Monday, June 1, 2020 8:40 PM > > > > > > > > > > > > > From: Peng Fan > > > > > > > Sent: Friday, April 24, 2020 9:12 AM > > > > > > > > > > > > > > > > > From: Peng Fan > > > > > > > > > Sent: Thursday, April 23, 2020 6:57 PM > > > > > > > > > > > From: Peng Fan > > > > > > > > > > > Sent: Thursday, April 23, 2020 3:00 PM > > > > > > > > > > > > > > > > > > > > > > Add resource management API, when we have multiple > > > > > > > > > > > partition running together, resources not owned to > > > > > > > > > > > current partition should not be > > > > > > > > used. > > > > > > > > > > > > > > > > > > > > > > Reviewed-by: Leonard Crestez > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Peng Fan > > > > > > > > > > > > > > > > > > > > Right now I'm still not quite understand if we really need > > > > > > > > > > this. > > > > > > > > > > As current resource is bound to power domains, if it's > > > > > > > > > > not owned by one specific SW execution environment, > > > > > > > > > > power on will also > > > > > fail. > > > > > > > > > > Can you clarify if any exceptions? > > > > > > > > > > > > > > > > > > There will be lots of failures when boot Linux domu if no > > > > > > > > > check. > > > > > > > > > > > > > > > > > > > > > > > > > What kind of features did you mean? > > > > > > > > Could you clarify a bit more? I'd like to understand this > > > > > > > > issue > > better. > > > > > > > > > > > > > > When supporting hypervisor with dual Linux running, 1st > > > > > > > Linux and the 2nd Linux will have their own dedicated resources. > > > > > > > > > > > > > > If no resource check, that means 1st/2nd Linux will register > > > > > > > all the resources, then both will see fail logs when > > > > > > > register resources not owned to > > > > > > itself. > > > > > > > > > > > > > > Same to partitioned m4 case. > > > > > > > > > > > > > > Would it be better without the failure log? > > > > > > > > > > > > > > > > > > > Is it power up failure? > > > > > > If yes, it's expected because we actually use power up to > > > > > > check if resources are owned by this partition. It functions > > > > > > the same as calling resource check API. > > > > > > That's current design. > > > > > > > > > > > > Or it's other failures? Log? > > > > > Sorry for long late reply. > > > > > > > > > > Part of my XEN DomU log, there are lots of failure log. I think > > > > > better not have such logs by add a resource own check. > > > > > > > > Those error logs are intended. > > > > Resource owner check actually behaves the same as power up. > > > > > > If resource is not owned, it will not register the power domain. > > > > > > Without resource own check, it will continue register the power > > > domain and hook it into genpd list. > > > > > > > That's the intended behavior to save the resource owner checking as > > it's very time cost to send SCU cmd for each domain during booting > > which benefits nothing except not exposing them in genpd list. > > > > > I prefer we not expose the power domain not owned to current > > > partition and keep the err msg for people to easy see where it goes wrong. > > > > If we really want to to do, I wonder probably another better approach > > is trying to re-use the partition Information built by bootloader as > > uboot already did that one time, not necessary to re-do It again for kernel > > as > it's time cost. > > e.g. introduce a resource partition property in dt and initialized and > > passed by bootloarder to kernel to use later. > > This will not work for hypervisor based VM runtime partition create and > resource assignment. > For VM case, can't we define them in DT if it's statically defined? > > Then we can still save those huge number of resource owner check CMDs. > > So we have to live with them even I only need one SDHC for a VM? With so > many clk-scu entries and power domain entries there. No, clk-scu register will fail automatically if not owned by this partition. Regards Aisheng > > Thanks, > Peng. > > > > > Regards > > Aisheng > > > > > > > > Regards, > > > Peng. > > > > So not quite necessary to add a double check. > > > > If we're concerning about the error log, we can change it to dev_dbg(). > > > > > > > > BTW, as resource management will be needed by seco drivers later, > > > > So I will continue to review the patch. > > > > > > > > Regards > > > > Aisheng > > > > > > > > > > > > > > [2.034774] imx6q-pcie 5f00.pcie:IO > > 0x6ff8..0x6ff8 > > > -> > > > > > 0x > > > > > [2.034801] imx6q-pcie 5f00.pcie: MEM > > > 0x6000..0x6fef > > > > -> > > > > > 0x6000 > > > > > [2.035072] sdhc1: failed to power up resource 249 ret -13 > > > > > [2.035619] sdhc2: failed to power up resource 250 ret -13 > > > > > [2.036126] enet0:
RE: [PATCH 2/4] firmware: imx: add resource management api
> From: Peng Fan > Sent: Tuesday, June 2, 2020 12:51 PM > > > > > From: Peng Fan > > > Sent: Monday, June 1, 2020 8:40 PM > > > > > > > > > From: Peng Fan > > > > > Sent: Friday, April 24, 2020 9:12 AM > > > > > > > > > > > > > From: Peng Fan > > > > > > > Sent: Thursday, April 23, 2020 6:57 PM > > > > > > > > > From: Peng Fan > > > > > > > > > Sent: Thursday, April 23, 2020 3:00 PM > > > > > > > > > > > > > > > > > > Add resource management API, when we have multiple > > > > > > > > > partition running together, resources not owned to > > > > > > > > > current partition should not be > > > > > > used. > > > > > > > > > > > > > > > > > > Reviewed-by: Leonard Crestez > > > > > > > > > Signed-off-by: Peng Fan > > > > > > > > > > > > > > > > Right now I'm still not quite understand if we really need this. > > > > > > > > As current resource is bound to power domains, if it's not > > > > > > > > owned by one specific SW execution environment, power on > > > > > > > > will also > > > fail. > > > > > > > > Can you clarify if any exceptions? > > > > > > > > > > > > > > There will be lots of failures when boot Linux domu if no check. > > > > > > > > > > > > > > > > > > > What kind of features did you mean? > > > > > > Could you clarify a bit more? I'd like to understand this issue > > > > > > better. > > > > > > > > > > When supporting hypervisor with dual Linux running, 1st Linux > > > > > and the 2nd Linux will have their own dedicated resources. > > > > > > > > > > If no resource check, that means 1st/2nd Linux will register all > > > > > the resources, then both will see fail logs when register > > > > > resources not owned to > > > > itself. > > > > > > > > > > Same to partitioned m4 case. > > > > > > > > > > Would it be better without the failure log? > > > > > > > > > > > > > Is it power up failure? > > > > If yes, it's expected because we actually use power up to check if > > > > resources are owned by this partition. It functions the same as > > > > calling resource check API. > > > > That's current design. > > > > > > > > Or it's other failures? Log? > > > Sorry for long late reply. > > > > > > Part of my XEN DomU log, there are lots of failure log. I think > > > better not have such logs by add a resource own check. > > > > Those error logs are intended. > > Resource owner check actually behaves the same as power up. > > If resource is not owned, it will not register the power domain. > > Without resource own check, it will continue register the power domain and > hook it into genpd list. > That's the intended behavior to save the resource owner checking as it's very time cost to send SCU cmd for each domain during booting which benefits nothing except not exposing them in genpd list. > I prefer we not expose the power domain not owned to current partition and > keep the err msg for people to easy see where it goes wrong. If we really want to to do, I wonder probably another better approach is trying to re-use the partition Information built by bootloader as uboot already did that one time, not necessary to re-do It again for kernel as it's time cost. e.g. introduce a resource partition property in dt and initialized and passed by bootloarder to kernel to use later. Then we can still save those huge number of resource owner check CMDs. Regards Aisheng > > Regards, > Peng. > > So not quite necessary to add a double check. > > If we're concerning about the error log, we can change it to dev_dbg(). > > > > BTW, as resource management will be needed by seco drivers later, So I > > will continue to review the patch. > > > > Regards > > Aisheng > > > > > > > > [2.034774] imx6q-pcie 5f00.pcie:IO 0x6ff8..0x6ff8 > -> > > > 0x > > > [2.034801] imx6q-pcie 5f00.pcie: MEM > 0x6000..0x6fef > > -> > > > 0x6000 > > > [2.035072] sdhc1: failed to power up resource 249 ret -13 > > > [2.035619] sdhc2: failed to power up resource 250 ret -13 > > > [2.036126] enet0: failed to power up resource 251 ret -13 > > > [2.036584] enet1: failed to power up resource 252 ret -13 > > > [2.037040] mlb0: failed to power up resource 253 ret -13 > > > [2.037495] nand: failed to power up resource 265 ret -13 > > > [2.037951] nand: failed to power up resource 265 ret -13 > > > [2.038416] pwm0: failed to power up resource 191 ret -13 > > > [2.038868] pwm1: failed to power up resource 192 ret -13 > > > [2.039320] pwm2: failed to power up resource 193 ret -13 > > > [2.039786] pwm3: failed to power up resource 194 ret -13 > > > [2.040239] pwm4: failed to power up resource 195 ret -13 > > > [2.040692] pwm5: failed to power up resource 196 ret -13 > > > [2.041142] pwm6: failed to power up resource 197 ret -13 > > > [2.041596] pwm7: failed to power up resource 198 ret -13 > > > [2.042073] amix: failed to power up resource 458 ret -13 > > > [2.042558] lpspi0: failed to power up resource 53 ret
RE: [PATCH 2/4] firmware: imx: add resource management api
> From: Peng Fan
> Sent: Tuesday, June 2, 2020 1:24 PM
>
> > Subject: RE: [PATCH 2/4] firmware: imx: add resource management api
> >
> > > From: Peng Fan
> > > Sent: Thursday, April 23, 2020 3:00 PM
> > >
> > > Add resource management API, when we have multiple partition running
> > > together, resources not owned to current partition should not be used.
> > >
> > > Reviewed-by: Leonard Crestez
> > > Signed-off-by: Peng Fan
> > > ---
> > > drivers/firmware/imx/Makefile | 2 +-
> > > drivers/firmware/imx/rm.c | 40 +
> > > include/linux/firmware/imx/sci.h| 1 +
> > > include/linux/firmware/imx/svc/rm.h | 69
> > > +
> > > 4 files changed, 111 insertions(+), 1 deletion(-) create mode
> > > 100644 drivers/firmware/imx/rm.c create mode 100644
> > > include/linux/firmware/imx/svc/rm.h
> > >
> > > diff --git a/drivers/firmware/imx/Makefile
> > > b/drivers/firmware/imx/Makefile index 08bc9ddfbdfb..17ea3613e142
> > > 100644
> > > --- a/drivers/firmware/imx/Makefile
> > > +++ b/drivers/firmware/imx/Makefile
> > > @@ -1,4 +1,4 @@
> > > # SPDX-License-Identifier: GPL-2.0
> > > obj-$(CONFIG_IMX_DSP)+= imx-dsp.o
> > > -obj-$(CONFIG_IMX_SCU)+= imx-scu.o misc.o imx-scu-irq.o
> > > +obj-$(CONFIG_IMX_SCU)+= imx-scu.o misc.o imx-scu-irq.o rm.o
> > > obj-$(CONFIG_IMX_SCU_PD) += scu-pd.o
> > > diff --git a/drivers/firmware/imx/rm.c b/drivers/firmware/imx/rm.c
> > > new file mode 100644 index ..7b0334de5486
> > > --- /dev/null
> > > +++ b/drivers/firmware/imx/rm.c
> > > @@ -0,0 +1,40 @@
> > > +// SPDX-License-Identifier: GPL-2.0+
> > > +/*
> > > + * Copyright 2020 NXP
> > > + *
> > > + * File containing client-side RPC functions for the RM service.
> > > +These
> > > + * function are ported to clients that communicate to the SC.
> > > + */
> > > +
> > > +#include
> > > +
> > > +struct imx_sc_msg_rm_rsrc_owned {
> > > + struct imx_sc_rpc_msg hdr;
> > > + u16 resource;
> > > +} __packed __aligned(4);
> > > +
> > > +/*
> > > + * This function check @resource is owned by current partition or
> > > +not
> > > + *
> > > + * @param[in] ipc IPC handle
> > > + * @param[in] resourceresource the control is associated with
> > > + *
> > > + * @return Returns 0 for success and < 0 for errors.
> > > + */
> > > +bool imx_sc_rm_is_resource_owned(struct imx_sc_ipc *ipc, u16
> > > +resource) {
> > > + struct imx_sc_msg_rm_rsrc_owned msg;
> > > + struct imx_sc_rpc_msg *hdr =
> > > +
> > > + hdr->ver = IMX_SC_RPC_VERSION;
> > > + hdr->svc = IMX_SC_RPC_SVC_RM;
> > > + hdr->func = IMX_SC_RM_FUNC_IS_RESOURCE_OWNED;
> > > + hdr->size = 2;
> > > +
> > > + msg.resource = resource;
> > > +
> > > + imx_scu_call_rpc(ipc, , true);
> >
> > No need check err return?
>
> No. it use hdr->func as the resource owner bool.
> However imx_scu_call_rpc also use hdr->func to check error value or not.
>
> When hdr->func is 1, imx_sc_to_linux_errno will report it -EINVAL. However
> here 1 means not owned.
For this special case, pls add a code comment about it.
Refer to:
drivers/input/keyboard/imx_sc_pwrkey.c
Regards
Aisheng
>
> >
> > > +
> > > + return hdr->func;
> > > +}
> > > +EXPORT_SYMBOL(imx_sc_rm_is_resource_owned);
> > > diff --git a/include/linux/firmware/imx/sci.h
> > > b/include/linux/firmware/imx/sci.h
> > > index 17ba4e405129..b5c5a56f29be 100644
> > > --- a/include/linux/firmware/imx/sci.h
> > > +++ b/include/linux/firmware/imx/sci.h
> > > @@ -15,6 +15,7 @@
> > >
> > > #include #include
> > >
> > > +#include
> > >
> > > int imx_scu_enable_general_irq_channel(struct device *dev); int
> > > imx_scu_irq_register_notifier(struct notifier_block *nb); diff --git
> > > a/include/linux/firmware/imx/svc/rm.h
> > > b/include/linux/firmware/imx/svc/rm.h
> > > new file mode 100644
> > > index ..fc6ea62d9d0e
> > > --- /dev/null
> > > +++ b/include/linux/firmware/imx/svc/rm.h
> > > @@ -0,0 +1,69 @@
> > > +/* SPDX-License-Identifier: GPL-2.0+ */
> > > +/*
> > > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > > + * Copyright 2017-2019 NXP
> >
> > Update copyright
>
> ok
>
> >
> > > + *
> > > + * Header file containing the public API for the System Controller
> > > +(SC)
> > > + * Power Management (PM) function. This includes functions for
> > > +power state
> > > + * control, clock control, reset control, and wake-up event control.
> >
> > Fix the code comments
> >
> > Otherwise, I'm fine with this patch.
> Ok.
>
> Thanks,
> Peng.
>
> >
> > Regards
> > Aisheng
> >
> > > + *
> > > + * RM_SVC (SVC) Resource Management Service
> > > + *
> > > + * Module for the Resource Management (RM) service.
> > > + */
> > > +
> > > +#ifndef _SC_RM_API_H
> > > +#define _SC_RM_API_H
> > > +
> > > +#include
> > > +
> > > +/*
> > > + * This type is used to indicate RPC RM function calls.
> > > + */
> > > +enum imx_sc_rm_func {
> > > + IMX_SC_RM_FUNC_UNKNOWN = 0,
> > > +
RE: [PATCH 2/4] firmware: imx: add resource management api
> From: Peng Fan
> Sent: Thursday, April 23, 2020 3:00 PM
>
> Add resource management API, when we have multiple partition running
> together, resources not owned to current partition should not be used.
>
> Reviewed-by: Leonard Crestez
> Signed-off-by: Peng Fan
> ---
> drivers/firmware/imx/Makefile | 2 +-
> drivers/firmware/imx/rm.c | 40 +
> include/linux/firmware/imx/sci.h| 1 +
> include/linux/firmware/imx/svc/rm.h | 69
> +
> 4 files changed, 111 insertions(+), 1 deletion(-) create mode 100644
> drivers/firmware/imx/rm.c create mode 100644
> include/linux/firmware/imx/svc/rm.h
>
> diff --git a/drivers/firmware/imx/Makefile b/drivers/firmware/imx/Makefile
> index 08bc9ddfbdfb..17ea3613e142 100644
> --- a/drivers/firmware/imx/Makefile
> +++ b/drivers/firmware/imx/Makefile
> @@ -1,4 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0
> obj-$(CONFIG_IMX_DSP)+= imx-dsp.o
> -obj-$(CONFIG_IMX_SCU)+= imx-scu.o misc.o imx-scu-irq.o
> +obj-$(CONFIG_IMX_SCU)+= imx-scu.o misc.o imx-scu-irq.o rm.o
> obj-$(CONFIG_IMX_SCU_PD) += scu-pd.o
> diff --git a/drivers/firmware/imx/rm.c b/drivers/firmware/imx/rm.c new file
> mode 100644 index ..7b0334de5486
> --- /dev/null
> +++ b/drivers/firmware/imx/rm.c
> @@ -0,0 +1,40 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2020 NXP
> + *
> + * File containing client-side RPC functions for the RM service. These
> + * function are ported to clients that communicate to the SC.
> + */
> +
> +#include
> +
> +struct imx_sc_msg_rm_rsrc_owned {
> + struct imx_sc_rpc_msg hdr;
> + u16 resource;
> +} __packed __aligned(4);
> +
> +/*
> + * This function check @resource is owned by current partition or not
> + *
> + * @param[in] ipc IPC handle
> + * @param[in] resourceresource the control is associated with
> + *
> + * @return Returns 0 for success and < 0 for errors.
> + */
> +bool imx_sc_rm_is_resource_owned(struct imx_sc_ipc *ipc, u16 resource)
> +{
> + struct imx_sc_msg_rm_rsrc_owned msg;
> + struct imx_sc_rpc_msg *hdr =
> +
> + hdr->ver = IMX_SC_RPC_VERSION;
> + hdr->svc = IMX_SC_RPC_SVC_RM;
> + hdr->func = IMX_SC_RM_FUNC_IS_RESOURCE_OWNED;
> + hdr->size = 2;
> +
> + msg.resource = resource;
> +
> + imx_scu_call_rpc(ipc, , true);
No need check err return?
> +
> + return hdr->func;
> +}
> +EXPORT_SYMBOL(imx_sc_rm_is_resource_owned);
> diff --git a/include/linux/firmware/imx/sci.h
> b/include/linux/firmware/imx/sci.h
> index 17ba4e405129..b5c5a56f29be 100644
> --- a/include/linux/firmware/imx/sci.h
> +++ b/include/linux/firmware/imx/sci.h
> @@ -15,6 +15,7 @@
>
> #include #include
>
> +#include
>
> int imx_scu_enable_general_irq_channel(struct device *dev); int
> imx_scu_irq_register_notifier(struct notifier_block *nb); diff --git
> a/include/linux/firmware/imx/svc/rm.h b/include/linux/firmware/imx/svc/rm.h
> new file mode 100644
> index ..fc6ea62d9d0e
> --- /dev/null
> +++ b/include/linux/firmware/imx/svc/rm.h
> @@ -0,0 +1,69 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + * Copyright 2017-2019 NXP
Update copyright
> + *
> + * Header file containing the public API for the System Controller (SC)
> + * Power Management (PM) function. This includes functions for power
> +state
> + * control, clock control, reset control, and wake-up event control.
Fix the code comments
Otherwise, I'm fine with this patch.
Regards
Aisheng
> + *
> + * RM_SVC (SVC) Resource Management Service
> + *
> + * Module for the Resource Management (RM) service.
> + */
> +
> +#ifndef _SC_RM_API_H
> +#define _SC_RM_API_H
> +
> +#include
> +
> +/*
> + * This type is used to indicate RPC RM function calls.
> + */
> +enum imx_sc_rm_func {
> + IMX_SC_RM_FUNC_UNKNOWN = 0,
> + IMX_SC_RM_FUNC_PARTITION_ALLOC = 1,
> + IMX_SC_RM_FUNC_SET_CONFIDENTIAL = 31,
> + IMX_SC_RM_FUNC_PARTITION_FREE = 2,
> + IMX_SC_RM_FUNC_GET_DID = 26,
> + IMX_SC_RM_FUNC_PARTITION_STATIC = 3,
> + IMX_SC_RM_FUNC_PARTITION_LOCK = 4,
> + IMX_SC_RM_FUNC_GET_PARTITION = 5,
> + IMX_SC_RM_FUNC_SET_PARENT = 6,
> + IMX_SC_RM_FUNC_MOVE_ALL = 7,
> + IMX_SC_RM_FUNC_ASSIGN_RESOURCE = 8,
> + IMX_SC_RM_FUNC_SET_RESOURCE_MOVABLE = 9,
> + IMX_SC_RM_FUNC_SET_SUBSYS_RSRC_MOVABLE = 28,
> + IMX_SC_RM_FUNC_SET_MASTER_ATTRIBUTES = 10,
> + IMX_SC_RM_FUNC_SET_MASTER_SID = 11,
> + IMX_SC_RM_FUNC_SET_PERIPHERAL_PERMISSIONS = 12,
> + IMX_SC_RM_FUNC_IS_RESOURCE_OWNED = 13,
> + IMX_SC_RM_FUNC_GET_RESOURCE_OWNER = 33,
> + IMX_SC_RM_FUNC_IS_RESOURCE_MASTER = 14,
> + IMX_SC_RM_FUNC_IS_RESOURCE_PERIPHERAL = 15,
> + IMX_SC_RM_FUNC_GET_RESOURCE_INFO = 16,
> + IMX_SC_RM_FUNC_MEMREG_ALLOC = 17,
> + IMX_SC_RM_FUNC_MEMREG_SPLIT = 29,
> + IMX_SC_RM_FUNC_MEMREG_FRAG = 32,
> +
RE: [PATCH 2/4] firmware: imx: add resource management api
> From: Peng Fan > Sent: Monday, June 1, 2020 8:40 PM > > > > > From: Peng Fan > > > Sent: Friday, April 24, 2020 9:12 AM > > > > > > > > > From: Peng Fan > > > > > Sent: Thursday, April 23, 2020 6:57 PM > > > > > > > From: Peng Fan > > > > > > > Sent: Thursday, April 23, 2020 3:00 PM > > > > > > > > > > > > > > Add resource management API, when we have multiple partition > > > > > > > running together, resources not owned to current partition > > > > > > > should not be > > > > used. > > > > > > > > > > > > > > Reviewed-by: Leonard Crestez > > > > > > > Signed-off-by: Peng Fan > > > > > > > > > > > > Right now I'm still not quite understand if we really need this. > > > > > > As current resource is bound to power domains, if it's not > > > > > > owned by one specific SW execution environment, power on will also > fail. > > > > > > Can you clarify if any exceptions? > > > > > > > > > > There will be lots of failures when boot Linux domu if no check. > > > > > > > > > > > > > What kind of features did you mean? > > > > Could you clarify a bit more? I'd like to understand this issue better. > > > > > > When supporting hypervisor with dual Linux running, 1st Linux and > > > the 2nd Linux will have their own dedicated resources. > > > > > > If no resource check, that means 1st/2nd Linux will register all the > > > resources, then both will see fail logs when register resources not > > > owned to > > itself. > > > > > > Same to partitioned m4 case. > > > > > > Would it be better without the failure log? > > > > > > > Is it power up failure? > > If yes, it's expected because we actually use power up to check if > > resources are owned by this partition. It functions the same as > > calling resource check API. > > That's current design. > > > > Or it's other failures? Log? > Sorry for long late reply. > > Part of my XEN DomU log, there are lots of failure log. I think better not > have > such logs by add a resource own check. Those error logs are intended. Resource owner check actually behaves the same as power up. So not quite necessary to add a double check. If we're concerning about the error log, we can change it to dev_dbg(). BTW, as resource management will be needed by seco drivers later, So I will continue to review the patch. Regards Aisheng > > [2.034774] imx6q-pcie 5f00.pcie:IO 0x6ff8..0x6ff8 -> > 0x > [2.034801] imx6q-pcie 5f00.pcie: MEM 0x6000..0x6fef -> > 0x6000 > [2.035072] sdhc1: failed to power up resource 249 ret -13 > [2.035619] sdhc2: failed to power up resource 250 ret -13 > [2.036126] enet0: failed to power up resource 251 ret -13 > [2.036584] enet1: failed to power up resource 252 ret -13 > [2.037040] mlb0: failed to power up resource 253 ret -13 > [2.037495] nand: failed to power up resource 265 ret -13 > [2.037951] nand: failed to power up resource 265 ret -13 > [2.038416] pwm0: failed to power up resource 191 ret -13 > [2.038868] pwm1: failed to power up resource 192 ret -13 > [2.039320] pwm2: failed to power up resource 193 ret -13 > [2.039786] pwm3: failed to power up resource 194 ret -13 > [2.040239] pwm4: failed to power up resource 195 ret -13 > [2.040692] pwm5: failed to power up resource 196 ret -13 > [2.041142] pwm6: failed to power up resource 197 ret -13 > [2.041596] pwm7: failed to power up resource 198 ret -13 > [2.042073] amix: failed to power up resource 458 ret -13 > [2.042558] lpspi0: failed to power up resource 53 ret -13 > [2.043033] lpspi1: failed to power up resource 54 ret -13 > [2.043501] lpspi2: failed to power up resource 55 ret -13 > [2.043992] lpspi3: failed to power up resource 56 ret -13 > [2.044460] lpuart0: failed to power up resource 57 ret -13 > [2.044935] lpuart2: failed to power up resource 59 ret -13 > [2.045409] lpuart3: failed to power up resource 60 ret -13 > [2.055014] sim0: failed to power up resource 62 ret -13 > [2.055510] adc0: failed to power up resource 101 ret -13 > [2.056467] lpi2c0: failed to power up resource 96 ret -13 > [2.056946] lpi2c1: failed to power up resource 97 ret -13 > [2.057424] lpi2c2: failed to power up resource 98 ret -13 > [2.057898] lpi2c3: failed to power up resource 99 ret -13 > [2.058371] can0: failed to power up resource 105 ret -13 > [2.059289] can1: failed to power up resource 106 ret -13 > [2.059801] can2: failed to power up resource 107 ret -13 > [2.060281] nand: failed to power up resource 265 ret -13 > [2.062764] dpu-core 5618.dpu: driver probed > > Thanks, > Peng. > > > > > Regards > > Aisheng > > > > > Thanks, > > > Peng. > > > > > > > > > > > > > > Regards > > > > Aisheng > > > > > > > > > Thanks, > > > > > Peng. > > > > > > > > > > > > > > > > > Regards > > > > > > Aisheng > > > > > > > > > > > > > --- > > > > > > > drivers/firmware/imx/Makefile | 2 +- > > > > > > >
RE: [PATCH] pinctrl: freescale: imx: Fix an error handling path in 'imx_pinctrl_probe()'
> From: Christophe JAILLET
> Sent: Sunday, May 31, 2020 4:50 AM
>
> 'pinctrl_unregister()' should not be called to undo
> 'devm_pinctrl_register_and_init()', it is already handled by the framework.
>
> This simplifies the error handling paths of the probe function.
> The 'imx_free_resources()' can be removed as well.
>
> Fixes: a51c158bf0f7 ("pinctrl: imx: use radix trees for groups and functions")
> Signed-off-by: Christophe JAILLET
Reviewed-by: Dong Aisheng
Regards
Aisheng
RE: [PATCH V3 2/3] arm64: dts: imx8m: add mu node
> From: Peng Fan > Sent: Monday, June 1, 2020 4:20 PM > > Add mu node to let A53 could communicate with M Core. > > Signed-off-by: Peng Fan Reviewed-by: Dong Aisheng Regards Aisheng
RE: [PATCH V2 2/3] arm64: dts: imx8m: add mu node
> From: Peng Fan
> Sent: Monday, June 1, 2020 11:43 AM
>
> Add mu node to let A53 could communicate with M Core.
>
> Signed-off-by: Peng Fan
> ---
> arch/arm64/boot/dts/freescale/imx8mm.dtsi | 9 +
> arch/arm64/boot/dts/freescale/imx8mn.dtsi | 9 +
> arch/arm64/boot/dts/freescale/imx8mp.dtsi | 9 +
> arch/arm64/boot/dts/freescale/imx8mq.dtsi | 9 +
> 4 files changed, 36 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> index aaf6e71101a1..fc001fb971e9 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> @@ -775,6 +775,15 @@
> status = "disabled";
> };
>
> + mu: mailbox@30aa {
> + compatible = "fsl,imx8mm-mu", "fsl,imx6sx-mu";
> + reg = <0x30aa 0x1>;
> + interrupts = ;
> + clocks = < IMX8MM_CLK_MU_ROOT>;
> + clock-names = "mu";
You missed my comments about this unneeded line in the last round of review.
https://lore.kernel.org/patchwork/patch/1244752/
Regards
Aisheng
> + #mbox-cells = <2>;
> + };
> +
> usdhc1: mmc@30b4 {
> compatible = "fsl,imx8mm-usdhc",
> "fsl,imx7d-usdhc";
> reg = <0x30b4 0x1>;
> diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
> index 9a4b65a267d4..c8290d21ccc9 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
> @@ -675,6 +675,15 @@
> status = "disabled";
> };
>
> + mu: mailbox@30aa {
> + compatible = "fsl,imx8mn-mu", "fsl,imx6sx-mu";
> + reg = <0x30aa 0x1>;
> + interrupts = ;
> + clocks = < IMX8MN_CLK_MU_ROOT>;
> + clock-names = "mu";
> + #mbox-cells = <2>;
> + };
> +
> usdhc1: mmc@30b4 {
> compatible = "fsl,imx8mn-usdhc",
> "fsl,imx7d-usdhc";
> reg = <0x30b4 0x1>;
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> index 45e2c0a4e889..b530804f763e 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> @@ -621,6 +621,15 @@
> status = "disabled";
> };
>
> + mu: mailbox@30aa {
> + compatible = "fsl,imx8mp-mu", "fsl,imx6sx-mu";
> + reg = <0x30aa 0x1>;
> + interrupts = ;
> + clocks = < IMX8MP_CLK_MU_ROOT>;
> + clock-names = "mu";
> + #mbox-cells = <2>;
> + };
> +
> i2c5: i2c@30ad {
> compatible = "fsl,imx8mp-i2c", "fsl,imx21-i2c";
> #address-cells = <1>;
> diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> index 978f8122c0d2..66ba8da704f6 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> @@ -959,6 +959,15 @@
> status = "disabled";
> };
>
> + mu: mailbox@30aa {
> + compatible = "fsl,imx8mq-mu", "fsl,imx6sx-mu";
> + reg = <0x30aa 0x1>;
> + interrupts = ;
> + clocks = < IMX8MQ_CLK_MU_ROOT>;
> + clock-names = "mu";
> + #mbox-cells = <2>;
> + };
> +
> usdhc1: mmc@30b4 {
> compatible = "fsl,imx8mq-usdhc",
>"fsl,imx7d-usdhc";
> --
> 2.16.4
