From: Anatolij Gustschin <agust@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH V3 07/32] misc: add i.MX8 misc driver
Date: Thu, 9 Aug 2018 18:18:56 +0200 [thread overview]
Message-ID: <20180809181856.35648547@crub> (raw)
In-Reply-To: <20180806025047.25320-8-peng.fan@nxp.com>
Hi Peng,
On Mon, 6 Aug 2018 10:50:22 +0800
Peng Fan peng.fan at nxp.com wrote:
> Add i.MX8 MISC driver to handle the communication between
> A35 Core and SCU.
Thanks for working on this! I think we should rename this driver to
imx-mu and unify it, so that it can be used on i.MX7 and i.MX6SX,
if needed.
...
> diff --git a/drivers/misc/imx8/scu.c b/drivers/misc/imx8/scu.c
> new file mode 100644
> index 0000000000..3cc6b719e3
> --- /dev/null
> +++ b/drivers/misc/imx8/scu.c
> @@ -0,0 +1,247 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2018 NXP
> + *
> + * Peng Fan <peng.fan@nxp.com>
> + */
> +
> +#include <common.h>
> +#include <asm/io.h>
> +#include <dm.h>
> +#include <dm/lists.h>
> +#include <dm/root.h>
> +#include <dm/device-internal.h>
> +#include <asm/arch/sci/sci.h>
> +#include <linux/iopoll.h>
> +#include <misc.h>
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +struct mu_type {
> + u32 tr[4];
> + u32 rr[4];
> + u32 sr;
> + u32 cr;
> +};
> +
> +struct imx8_scu {
> + struct mu_type *base;
> + struct udevice *clk;
> + struct udevice *pinclk;
> +};
> +
> +#define MU_CR_GIE_MASK 0xF0000000u
> +#define MU_CR_RIE_MASK 0xF000000u
> +#define MU_CR_GIR_MASK 0xF0000u
> +#define MU_CR_TIE_MASK 0xF00000u
> +#define MU_CR_F_MASK 0x7u
> +#define MU_SR_TE0_MASK BIT(23)
> +#define MU_SR_RF0_MASK BIT(27)
> +#define MU_TR_COUNT 4
> +#define MU_RR_COUNT 4
> +static inline void mu_hal_init(struct mu_type *base)
Please use empty line after macro definition.
...
> +static int mu_hal_receivemsg(struct mu_type *base, u32 reg_index, u32 *msg)
> +{
> + u32 mask = MU_SR_RF0_MASK >> reg_index;
> + u32 val;
> + int ret;
> +
> + assert(reg_index < MU_TR_COUNT);
> +
> + /* Wait RX register to be full. */
> + ret = readl_poll_timeout(&base->sr, val, val & mask, 10000);
> + if (ret < 0) {
> + printf("%s timeout\n", __func__);
> + return -ETIMEDOUT;
> + }
> +
> + *msg = readl(&base->rr[reg_index]);
> +
> + return 0;
> +}
> +
> +static void sc_ipc_read(struct mu_type *base, void *data)
> +{
> + struct sc_rpc_msg_s *msg = (struct sc_rpc_msg_s *)data;
> + u8 count = 0;
> +
> + /* Check parms */
> + if (!base || !msg)
Can base ever be NULL? If the driver is bound, base is always
initialized, so I think base check can be dropped.
...
> + /* Read first word */
> + mu_hal_receivemsg(base, 0, (u32 *)msg);
The return value is never checked. I don't know the internal
details of the message protocol, but does it make sense to read
more data if reading first word failed?
> + count++;
> +
> + /* Check size */
> + if (msg->size > SC_RPC_MAX_MSG) {
> + *((u32 *)msg) = 0;
> + return;
Should we return an error in this case to propagate it to the caller?
> + }
> +
> + /* Read remaining words */
> + while (count < msg->size) {
> + mu_hal_receivemsg(base, count % MU_RR_COUNT,
> + &msg->DATA.u32[count - 1]);
Return value check needed?
> + count++;
> + }
> +}
> +
> +static void sc_ipc_write(struct mu_type *base, void *data)
> +{
> + struct sc_rpc_msg_s *msg = (struct sc_rpc_msg_s *)data;
> + u8 count = 0;
> +
> + /* Check parms */
> + if (!base || !msg)
Drop base check?
> + return;
> +
> + /* Check size */
> + if (msg->size > SC_RPC_MAX_MSG)
> + return;
> +
> + /* Write first word */
> + mu_hal_sendmsg(base, 0, *((u32 *)msg));
Return value is not checked here. Does it make sense to send
remaining data if transmitting of the first word failed? Wouldn't
there be a protocol error at the receiver side when the message is
partially received? I think we should stop sending here and return
an error code to the caller.
> + count++;
> +
> + /* Write remaining words */
> + while (count < msg->size) {
> + mu_hal_sendmsg(base, count % MU_TR_COUNT,
> + msg->DATA.u32[count - 1]);
Return value check?
> + count++;
> + }
> +}
> +
> +/*
> + * Note the function prototype use msgid as the 2nd parameter, here
> + * we take it as no_resp.
> + */
> +static int imx8_scu_call(struct udevice *dev, int no_resp, void *tx_msg,
> + int tx_size, void *rx_msg, int rx_size)
> +{
> + struct imx8_scu *priv = dev_get_priv(dev);
> + sc_err_t result;
> +
> + /* Expect tx_msg, rx_msg are the same value */
> + if (rx_msg && tx_msg != rx_msg)
> + printf("tx_msg %p, rx_msg %p\n", tx_msg, rx_msg);
> +
> + sc_ipc_write(priv->base, tx_msg);
Check and propagate error code here?
> + if (!no_resp)
> + sc_ipc_read(priv->base, rx_msg);
> +
> + result = RPC_R8((struct sc_rpc_msg_s *)tx_msg);
> +
> + return sc_err_to_linux(result);
> +}
> +
> +static int imx8_scu_probe(struct udevice *dev)
> +{
> + struct imx8_scu *priv = dev_get_priv(dev);
> + fdt_addr_t addr;
> +
> + debug("%s(dev=%p) (priv=%p)\n", __func__, dev, priv);
> +
> + addr = devfdt_get_addr(dev);
> + if (addr == FDT_ADDR_T_NONE)
> + return -EINVAL;
> +
> + priv->base = (struct mu_type *)addr;
> +
> + /* U-Boot not enable interrupts, so need to enable RX interrupts */
> + mu_hal_init(priv->base);
> +
> + gd->arch.scu_dev = dev;
Can we avoid using the dev pointer in global data?
--
Anatolij
next prev parent reply other threads:[~2018-08-09 16:18 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-06 2:50 [U-Boot] [PATCH V3 00/32] i.MX: Add i.MX8QXP support Peng Fan
2018-08-06 2:50 ` [U-Boot] [PATCH V3 01/32] dt-bindings: pinctrl: add i.MX8QXP pads definition Peng Fan
2018-08-09 8:25 ` Anatolij Gustschin
2018-08-06 2:50 ` [U-Boot] [PATCH V3 02/32] dt-bindings: clock: dt-bindings: pinctrl: add i.MX8QXP clocks definition Peng Fan
2018-08-09 8:29 ` Anatolij Gustschin
2018-08-06 2:50 ` [U-Boot] [PATCH V3 03/32] dt-bindings: soc: add i.MX8QXP pm and rsrc definition Peng Fan
2018-08-09 8:31 ` Anatolij Gustschin
2018-08-06 2:50 ` [U-Boot] [PATCH V3 04/32] imx8: add scfw macro definition Peng Fan
2018-08-09 8:51 ` Anatolij Gustschin
2018-08-06 2:50 ` [U-Boot] [PATCH V3 05/32] imx: add Kconfig entry for i.MX8QXP Peng Fan
2018-08-09 9:45 ` Anatolij Gustschin
2018-08-06 2:50 ` [U-Boot] [PATCH V3 06/32] arm: build mach-imx for i.MX8 Peng Fan
2018-08-09 9:51 ` Anatolij Gustschin
2018-08-06 2:50 ` [U-Boot] [PATCH V3 07/32] misc: add i.MX8 misc driver Peng Fan
2018-08-09 16:18 ` Anatolij Gustschin [this message]
2018-08-10 2:30 ` Peng Fan
2018-08-10 14:15 ` Anatolij Gustschin
2018-08-06 2:50 ` [U-Boot] [PATCH V3 08/32] misc: imx8: add scfw api impementation Peng Fan
2018-08-10 14:19 ` Anatolij Gustschin
2018-08-06 2:50 ` [U-Boot] [PATCH V3 09/32] arm: global_data: add scu_dev for i.MX8 Peng Fan
2018-08-06 2:50 ` [U-Boot] [PATCH V3 10/32] imx: boot_mode: Add FLEXSPI boot entry Peng Fan
2018-08-06 2:50 ` [U-Boot] [PATCH V3 11/32] imx8: add imx-regs header file Peng Fan
2018-08-06 2:50 ` [U-Boot] [PATCH V3 12/32] imx8: pins: include i.MX8QXP pin header when CONFIG_IMX8QXP defined Peng Fan
2018-08-06 2:50 ` [U-Boot] [PATCH V3 13/32] imx: add i.MX8 cpu type Peng Fan
2018-08-06 2:50 ` [U-Boot] [PATCH V3 14/32] armv8: add cpu core helper functions Peng Fan
2018-08-06 2:50 ` [U-Boot] [PATCH V3 15/32] imx8: add basic cpu support Peng Fan
2018-08-06 2:50 ` [U-Boot] [PATCH V3 16/32] imx8: add boot device detection Peng Fan
2018-08-06 2:50 ` [U-Boot] [PATCH V3 17/32] imx8: implement mmc_get_env_dev Peng Fan
2018-08-06 2:50 ` [U-Boot] [PATCH V3 18/32] imx8: add mmu and dram related functiions Peng Fan
2018-08-06 2:50 ` [U-Boot] [PATCH V3 19/32] imx8: add arch_cpu_init arch_cpu_init_dm Peng Fan
2018-08-06 2:50 ` [U-Boot] [PATCH V3 20/32] imx8: add iomux configuration api Peng Fan
2018-08-06 2:50 ` [U-Boot] [PATCH V3 21/32] imx8: add dummy clock Peng Fan
2018-08-06 2:50 ` [U-Boot] [PATCH V3 22/32] gpio: mxc_gpio: add support for i.MX8 Peng Fan
2018-08-06 2:50 ` [U-Boot] [PATCH V3 23/32] pinctrl: Add pinctrl driver " Peng Fan
2018-08-06 2:50 ` [U-Boot] [PATCH V3 24/32] power: Add power domain " Peng Fan
2018-08-06 2:50 ` [U-Boot] [PATCH V3 25/32] clk: imx: add clk driver for i.MX8QXP Peng Fan
2018-08-06 2:50 ` [U-Boot] [PATCH V3 26/32] serial_lpuart: Update lpuart driver to support i.MX8 Peng Fan
2018-08-06 2:50 ` [U-Boot] [PATCH V3 27/32] serial: lpuart: Enable RX and TX FIFO Peng Fan
2018-08-06 2:50 ` [U-Boot] [PATCH V3 28/32] serial: lpuart: support uclass clk api Peng Fan
2018-08-06 2:50 ` [U-Boot] [PATCH V3 29/32] fsl_esdhc: Update usdhc driver to support i.MX8 Peng Fan
2018-08-06 2:50 ` [U-Boot] [PATCH V3 30/32] mmc: fsl_esdhc: add uclass clk support Peng Fan
2018-08-06 2:50 ` [U-Boot] [PATCH V3 31/32] arm: dts: introduce dtsi for i.MX8QXP Peng Fan
2018-08-06 2:50 ` [U-Boot] [PATCH V3 32/32] imx: add i.MX8QXP MEK board support Peng Fan
2018-08-22 17:23 ` Fabio Estevam
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180809181856.35648547@crub \
--to=agust@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox