* [PATCH v1 3/7] drm/mediatek: add dpi driver for mt2701 and mt7623
From: CK Hu @ 2018-05-28 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514075243.5442-4-bibby.hsieh@mediatek.com>
Hi, Bibby:
On Mon, 2018-05-14 at 15:52 +0800, Bibby Hsieh wrote:
> From: chunhui dai <chunhui.dai@mediatek.com>
>
> This patch adds dpi driver suppot for both mt2701 and mt7623.
> And also support other (existing or future) chips that use
> the same binding and driver.
>
> Signed-off-by: chunhui dai <chunhui.dai@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c | 24 ++++++++++++++++++++++--
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 +
> 2 files changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index 2b8b34c72697..e1af1d0d213d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -640,8 +640,7 @@ static int mtk_dpi_bind(struct device *dev, struct device *master, void *data)
> }
> drm_encoder_helper_add(&dpi->encoder, &mtk_dpi_encoder_helper_funcs);
>
> - /* Currently DPI0 is fixed to be driven by OVL1 */
> - dpi->encoder.possible_crtcs = BIT(1);
> + dpi->encoder.possible_crtcs = BIT(0) | BIT(1);
This modification influence not only mt2701, but also mt8173. So move
this to an independent patch.
Regards,
CK
> dpi->encoder.bridge->encoder = &dpi->encoder;
> ret = drm_bridge_attach(&dpi->encoder, dpi->encoder.bridge, NULL);
> if (ret) {
> @@ -690,12 +689,33 @@ static unsigned int mt8173_calculate_factor(int clock)
> return 2 * 3;
> }
>
> +static unsigned int mt2701_calculate_factor(int clock)
> +{
> + if (clock <= 64000)
> + return 16;
> + else if (clock <= 128000)
> + return 8;
> + else if (clock <= 256000)
> + return 4;
> + else
> + return 2;
> +}
> +
> static const struct mtk_dpi_conf mt8173_conf = {
> .cal_factor = mt8173_calculate_factor,
> .reg_h_fre_con = 0xe0,
> };
>
> +static const struct mtk_dpi_conf mt2701_conf = {
> + .cal_factor = mt2701_calculate_factor,
> + .reg_h_fre_con = 0xb0,
> + .edge_sel_en = true,
> +};
> +
> static const struct of_device_id mtk_dpi_of_ids[] = {
> + { .compatible = "mediatek,mt2701-dpi",
> + .data = &mt2701_conf,
> + },
> { .compatible = "mediatek,mt8173-dpi",
> .data = &mt8173_conf,
> },
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index a2ca90fc403c..f4fb86ab7b8d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -372,6 +372,7 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
> { .compatible = "mediatek,mt8173-disp-ufoe", .data = (void *)MTK_DISP_UFOE },
> { .compatible = "mediatek,mt2701-dsi", .data = (void *)MTK_DSI },
> { .compatible = "mediatek,mt8173-dsi", .data = (void *)MTK_DSI },
> + { .compatible = "mediatek,mt2701-dpi", .data = (void *)MTK_DPI },
> { .compatible = "mediatek,mt8173-dpi", .data = (void *)MTK_DPI },
> { .compatible = "mediatek,mt2701-disp-mutex", .data = (void *)MTK_DISP_MUTEX },
> { .compatible = "mediatek,mt8173-disp-mutex", .data = (void *)MTK_DISP_MUTEX },
^ permalink raw reply
* [PATCH 5/5] MAINTAINERS: imx: add NXP linux team upstream maillist as reviewer
From: A.s. Dong @ 2018-05-28 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180528080037.GC3143@dragon>
Hi Shawn,
> -----Original Message-----
> From: Shawn Guo [mailto:shawnguo at kernel.org]
> Sent: Monday, May 28, 2018 4:01 PM
> To: A.s. Dong <aisheng.dong@nxp.com>
> Cc: dongas86 at gmail.com; catalin.marinas at arm.com; will.deacon at arm.com;
> robh+dt at kernel.org; dl-linux-imx <linux-imx@nxp.com>;
> kernel at pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>; linux-
> arm-kernel at lists.infradead.org
> Subject: Re: [PATCH 5/5] MAINTAINERS: imx: add NXP linux team upstream
> maillist as reviewer
>
> On Fri, May 25, 2018 at 02:14:07AM +0000, A.s. Dong wrote:
> > Hi Shawn,
> >
> > > -----Original Message-----
> > > From: A.s. Dong
> > > Sent: Saturday, April 28, 2018 3:06 AM
> > > To: linux-arm-kernel at lists.infradead.org
> > > Cc: dongas86 at gmail.com; kernel at pengutronix.de;
> shawnguo at kernel.org;
> > > Fabio Estevam <fabio.estevam@nxp.com>; robh+dt at kernel.org;
> > > catalin.marinas at arm.com; will.deacon at arm.com; dl-linux-imx <linux-
> > > imx at nxp.com>; A.s. Dong <aisheng.dong@nxp.com>
> > > Subject: [PATCH 5/5] MAINTAINERS: imx: add NXP linux team upstream
> > > maillist as reviewer
> > >
> > > Add NXP linux team upstream maillist as reviewer
> > >
> > > Cc: Shawn Guo <shawnguo@kernel.org>
> > > Cc: Sascha Hauer <kernel@pengutronix.de>
> > > Cc: Fabio Estevam <fabio.estevam@nxp.com>
> > > Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
> >
> > Would you pick this one first?
>
> Okay. I changed patch subject a bit as below and applied the patch, since
> usually we do not have subsystem prefix for MAINTAINERS change.
>
> MAINTAINERS: add NXP linux team maillist as i.MX reviewer
>
Great. Thanks.
Regards
Dong Aisheng
> Shawn
^ permalink raw reply
* [PATCH v1 6/7] drm/mediatek: add a error return value when clock driver has been prepared
From: CK Hu @ 2018-05-28 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514075243.5442-7-bibby.hsieh@mediatek.com>
Hi, Bibby:
On Mon, 2018-05-14 at 15:52 +0800, Bibby Hsieh wrote:
> DRM driver get the comp->clk by of_clk_get(), we only
> assign NULL to comp->clk when error happened, but do
> not return the error number.
>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 4672317e3ad1..d38a5303f8fc 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -283,7 +283,7 @@ int mtk_ddp_comp_init(struct device *dev, struct device_node *node,
> comp->irq = of_irq_get(node, 0);
> comp->clk = of_clk_get(node, 0);
> if (IS_ERR(comp->clk))
> - comp->clk = NULL;
> + return PTR_ERR(comp->clk);
>
> /* Only DMA capable components need the LARB property */
> comp->larb_dev = NULL;
^ permalink raw reply
* [PATCH 1/8] drm/sun4i: mark PM functions as __maybe_unused
From: Maxime Ripard @ 2018-05-28 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525155030.3667352-1-arnd@arndb.de>
On Fri, May 25, 2018 at 05:50:08PM +0200, Arnd Bergmann wrote:
> Disabling CONFIG_PM produces a compile time warning when these
> functions are not referenced:
>
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:1072:12: error: 'sun6i_dsi_runtime_suspend' defined but not used [-Werror=unused-function]
> static int sun6i_dsi_runtime_suspend(struct device *dev)
> ^~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:1043:12: error: 'sun6i_dsi_runtime_resume' defined but not used [-Werror=unused-function]
> static int sun6i_dsi_runtime_resume(struct device *dev)
> ^~~~~~~~~~~~~~~~~~~~~~~~
>
> Fixes: 133add5b5ad4 ("drm/sun4i: Add Allwinner A31 MIPI-DSI controller support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied, thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180528/a89240b5/attachment.sig>
^ permalink raw reply
* [PATCH 4/4] soc: imx: add SC firmware IPC and APIs
From: A.s. Dong @ 2018-05-28 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AM0PR04MB421169E44830A17D8A52D3F4806A0@AM0PR04MB4211.eurprd04.prod.outlook.com>
Hi Sascha,
> -----Original Message-----
> From: A.s. Dong
> Sent: Thursday, May 24, 2018 4:56 PM
> To: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: linux-arm-kernel at lists.infradead.org; dongas86 at gmail.com; dl-linux-imx
> <linux-imx@nxp.com>; kernel at pengutronix.de; Fabio Estevam
> <fabio.estevam@nxp.com>; shawnguo at kernel.org
> Subject: RE: [PATCH 4/4] soc: imx: add SC firmware IPC and APIs
>
> Hi Sascha,
>
> > -----Original Message-----
> > From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> > Sent: Thursday, May 3, 2018 8:41 PM
> > To: A.s. Dong <aisheng.dong@nxp.com>
> > Cc: linux-arm-kernel at lists.infradead.org; dongas86 at gmail.com;
> > dl-linux-imx <linux-imx@nxp.com>; kernel at pengutronix.de; Fabio
> Estevam
> > <fabio.estevam@nxp.com>; shawnguo at kernel.org
> > Subject: Re: [PATCH 4/4] soc: imx: add SC firmware IPC and APIs
> >
> > On Thu, May 03, 2018 at 12:29:40PM +0000, A.s. Dong wrote:
> > > > -----Original Message-----
> > > > From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> > > > Sent: Thursday, May 3, 2018 7:06 PM
> > > > To: A.s. Dong <aisheng.dong@nxp.com>
> > > > Cc: linux-arm-kernel at lists.infradead.org; dongas86 at gmail.com;
> > > > dl-linux-imx <linux-imx@nxp.com>; kernel at pengutronix.de; Fabio
> > > > Estevam <fabio.estevam@nxp.com>; shawnguo at kernel.org
> > > > Subject: Re: [PATCH 4/4] soc: imx: add SC firmware IPC and APIs
> > > >
> > > > On Wed, May 02, 2018 at 06:40:03PM +0000, A.s. Dong wrote:
> > > > > > -----Original Message-----
> > > > > > From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> > > > > > Sent: Wednesday, May 2, 2018 6:04 PM
> > > > > > To: A.s. Dong <aisheng.dong@nxp.com>
> > > > > > Cc: linux-arm-kernel at lists.infradead.org; dongas86 at gmail.com;
> > > > > > dl-linux-imx <linux-imx@nxp.com>; kernel at pengutronix.de; Fabio
> > > > > > Estevam <fabio.estevam@nxp.com>; shawnguo at kernel.org
> > > > > > Subject: Re: [PATCH 4/4] soc: imx: add SC firmware IPC and
> > > > > > APIs
> > > > > >
> > > > > > On Sat, Apr 28, 2018 at 02:46:16AM +0800, Dong Aisheng wrote:
> > > > > > > +/* Initialization of the MU code. */ int __init
> > > > > > > +imx8_scu_init(void) {
> > > > > > > + struct device_node *np, *mu_np;
> > > > > > > + struct resource mu_res;
> > > > > > > + sc_err_t sci_err;
> > > > > > > + int ret;
> > > > > > > +
> > > > > > > + if (!of_machine_is_compatible("fsl,imx8qxp"))
> > > > > > > + return 0;
> > > > > > > +
> > > > > > > + np = of_find_compatible_node(NULL, NULL, "nxp,imx8qxp-
> > scu");
> > > > > > > + if (!np)
> > > > > > > + return -ENODEV;
> > > > > > > +
> > > > > > > + mu_np = of_parse_phandle(np, "fsl,mu", 0);
> > > > > > > + if (WARN_ON(!mu_np))
> > > > > > > + return -EINVAL;
> > > > > > > +
> > > > > > > + ret = of_address_to_resource(mu_np, 0, &mu_res);
> > > > > > > + if (WARN_ON(ret))
> > > > > > > + return -EINVAL;
> > > > > > > +
> > > > > > > + /* we use mu physical address as IPC communication channel
> > ID */
> > > > > > > + sci_err = sc_ipc_open(&scu_ipc_handle,
> > (sc_ipc_id_t)(mu_res.start));
> > > > > > > + if (sci_err != SC_ERR_NONE) {
> > > > > > > + pr_err("Cannot open MU channel to SCU\n");
> > > > > > > + return sci_err;
> > > > > > > + };
> > > > > >
> > > > > > Introducing private error codes always has the risk of just
> > > > > > forwarding them as errno codes as done here.
> > > > > >
> > > > >
> > > > > Yes, you're right.
> > > > > We probably could do the same as scpi_to_linux_errno in
> > > > > drivers/firmware/arm_scpi.c.
> > > > > However, may can't fix the issue permanently.
> > > > >
> > > > > > > +
> > > > > > > + of_node_put(mu_np);
> > > > > > > +
> > > > > > > + pr_info("NXP i.MX SCU Initialized (scu_ipc %u)\n",
> > > > > > > +scu_ipc_handle);
> > > > > > > +
> > > > > > > + return 0;
> > > > > > > +}
> > > > > > > +early_initcall(imx8_scu_init);
> > > > > >
> > > > > > This code shows that the separate 'scu' device node shouldn't exist.
> > > > > > It is only used as a stepping stone to find the 'mu' node.
> > > > > > Instead of providing a proper driver for the 'mu' node the scu
> > > > > > code registers it
> > > > with its physical address.
> > > > > > I don't think it makes sense to separate mu and scu code in this way.
> > > > > >
> > > > >
> > > > > I agree that may not look quite well.
> > > > > It mainly because we want to use the MU physical address as a MU ID.
> > > > > (can't use virtual address as sc_ipc_id_t is u32 defined by SCU
> firmware.
> > > > >
> > > > > If you have any better suggestion please let me know.
> > > >
> > > > What I'm suggesting is a single node:
> > > >
> > > > scu at 5d1b0000 {
> > > > compatible = "fsl,imx8qxp-scu";
> > > > reg = <0x0 0x5d1b0000 0x0 0x10000>;
> > > > };
> > > >
> > > > Attach your code to this one, without any further separation
> > > > between mu and scu code.
> > > >
> > >
> > > A bit confused. You're suggesting a single node here without mu or
> > > mailbox node phandle in it? Then how SCU use MU?
> >
> > ioremap the address and mu_receive_msg()/mu_send_msg() on it, just
> > like you do already.
> >
> > >
> > > > We discussed this internally and came to the conclusion that the
> > > > SCU is not a generic user of a MU. The MU is designed to work
> > > > together with a piece of SRAM to form a mailbox system. Instead of
> > > > working as designed the SCU morses the messages through the
> > > > doorbell (what the MU really is). For anything that uses the MU in
> > > > the way it is designed I would suggest using the mailbox interface
> > > > from drivers/mailbox/ along with the binding from
> > Documentation/devicetree/bindings/mailbox/mailbox.txt.
> > > >
> > > > In the way I suggest there is no need for any MU ID.
> > > >
> > >
> > > So you're suggesting switch to use mailbox instead of private MU
> > > library function calls?
> > > Something like:
> > > scu {
> > > compatible = "nxp,imx8qxp-scu", "simple-bus";
> > > mboxes = <&mailbox 0>;
> > > }
> > > Then IPC is implemented based on mailbox?
> > >
> > > As I replied Oleksij Rempel in another mail in this thread, we've
> > > tried mailbox but got performance regression issue and need more
> > > time to investigate whether it's really quite suitable for i.MX SCU
> > > firmware as SCU handling message quite fast in micro seconds.
> > > (Mailbox polling method has much more latency than current MU sample
> > > polling we
> > > used) and we want to avoid the SCU firmware API changes.
> >
> > I am not suggesting to do mailboxing (using shared memory) for the SCU.
> > I am also not suggesting any API update for the SCU communication.
> > I am just mentioning that doing mailboxing is the way the MU was
> > originally designed for. Looking at the reference manual I see many MUs on
> the i.MX8.
> > I guess most of them are for communication between the different cores
> > on the system. For these it's probably worth writing some generic MU
> driver.
> > The way the MU is used for communication with the SCU though is so
> > special that it's not worth writing a generic driver, so just
> > integrate the MU access functions in the SCU code.
> >
>
> I understand it.
>
> One problem of the way you suggested may be that:
> If we doing like below, we may lose flexibility to change the MU used for SCU
> firmware communication.
> scu at 5d1b0000 {
> compatible = "fsl,imx8qxp-scu";
> reg = <0x0 0x5d1b0000 0x0 0x10000>;
> };
>
> And current design is that the system supports multiple MU channels used
> by various users at the same time, e.g. SCU, Power Domain, Clock and others.
> User can flexibly change it under their nodes: And each MU channel is
> protected by their private lock and not affect each others.
>
> e.g.
> scu {
> compatible = "nxp,imx8qxp-scu", "simple-bus";
> fsl,mu = <&lsio_mu0>;
>
> clk: clk {
> compatible = "fsl,imx8qxp-clk";
> #clock-cells = <1>;
> };
>
> iomuxc: iomuxc {
> compatible = "fsl,imx8qxp-iomuxc";
> fsl,mu = <&lsio_mu3>;
> };
>
> imx8qx-pm {
> #address-cells = <1>;
> #size-cells = <0>;
> fsl,mu = <&lsio_mu4>;
> .............
> }
>
> The default code only uses MU0 which is used by SCU.
>
> The change may affect this design. Any ideas?
> Do you think we can keep the current way?
>
Any comments about this?
Regards
Dong Aisheng
> Regards
> Dong Aisheng
>
> > Sascha
> >
> > --
> > Pengutronix e.K. | |
> > Industrial Linux Solutions |
> >
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww
> >
> w.pengutronix.de%2F&data=02%7C01%7Caisheng.dong%40nxp.com%7C266
> > 24a5c38e5488a80b708d5b0f3107b%7C686ea1d3bc2b4c6fa92cd99c5c301635%
> >
> 7C0%7C0%7C636609480354404338&sdata=XP%2BYdt9I7zURrQun2jRbempLhC
> > XrYtMVMb3dEWrZuro%3D&reserved=0 |
> > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH 6/9] ARM: dts: wheat: Drop MTD partitioning from DT
From: Simon Horman @ 2018-05-28 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdXYyN=XY6nb9RVEE+t0NeoSPhTh6fUk-9YWdFzAE1FfPA@mail.gmail.com>
On Mon, May 28, 2018 at 10:54:57AM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Mon, May 28, 2018 at 10:41 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Thu, May 24, 2018 at 04:52:59PM +0200, Marek Vasut wrote:
> >> On 05/23/2018 08:25 AM, Geert Uytterhoeven wrote:
> >> > On Wed, May 23, 2018 at 12:01 AM, Marek Vasut <marek.vasut@gmail.com> wrote:
> >> >> On 05/22/2018 04:43 PM, Geert Uytterhoeven wrote:
> >> >>> On Tue, May 22, 2018 at 2:02 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> >> >>>> Drop the MTD partitioning from DT, since it does not describe HW
> >> >>>> and to give way to a more flexible kernel command line partition
> >> >>>> passing.
> >> >>>>
> >> >>>> To retain the original partitioning, assure you have enabled
> >> >>>> CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
> >> >>>> following to your kernel command line:
> >> >>>>
> >> >>>> mtdparts=spi0.0:256k at 0(loader),4096k(user),-(flash)
> >> >>>
> >> >>> I think the "@0" can be dropped, as it's optional?
> >> >>> 4m?
> >> >>
> >> >> My take on this is that the loader is actually at offset 0x0 of the MTD
> >> >> device and we explicitly state that in the mtdparts to anchor the first
> >> >> partition within the MTD device and all the other partitions are at
> >> >> offset +(sum of the sizes of all partitions listed before the current
> >> >> one) relative to that first partition.
> >> >
> >> > Where is this explicitly states for the first partition?
> >> >
> >> >> Removing the @0 feels fragile at best and it seems to depend on the
> >> >> current behavior of the code.
> >> >
> >> > Better, it also depends on the documented behavior:
> >> >
> >> > Documentation/admin-guide/kernel-parameters.txt refers to
> >> > drivers/mtd/cmdlinepart.c, which states:
> >> >
> >> > * <offset> := standard linux memsize
> >> > * if omitted the part will immediately follow the previous part
> >> > * or 0 if the first part
> >> >
> >> > None of the examples listed there or under the MTD_CMDLINE_PARTS Kconfig
> >> > help text, or in a defconfig bundled with the kernel, use @0 for the first
> >> > partition.
> >>
> >> I think this is exceptionally fragile and dangerous to depend on this,
> >> but so be it.
> >
> > Could you respin with this change?
> >
> > I would also like to ask for another change, in light of recent
> > feedback from Olof Johansson ("Re: [GIT PULL] Renesas ARM64 Based SoC DT
> > Updates for v4.18").
> >
> > Please consolidate the dts patches into a single patch?
>
> I think it's better to keep them split, as each commit description mentions
> what needs to be passed on the kernel command line for the corresponding
> board.
>
> Combining it in a single patch makes it much harder to extract this information.
> Unless you're fine with a list:
>
> koelsch: ...
> wheat: mtdparts=spi0.0:256k at 0(loader),4096k(user),-(flash)
Lets try a list.
^ permalink raw reply
* [PATCH 00/12] Add TOSHIBA TC358764 DSI/LVDS bridge driver
From: Maciej Purski @ 2018-05-28 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CGME20180528094721eucas1p22b90fd838ce00f029fec7f5241cc06b5@eucas1p2.samsung.com>
Hi all,
this patchset is a next attempt to add the tc358764 driver.
The previous one can be found here:
https://lists.freedesktop.org/archives/dri-devel/2014-February/053705.html
Back then, TC358764 was added as a panel driver.
The bridge is supposed to be a DSI peripheral. Currently exynos_dsi accepts only panels
as its peripherals. Therefore, some logic in exynos_dsi had to be ammended. That is implemented
in first 4 patches.
Apart from the driver this patchset adds support for BOE HV070WSA-100 panel, which is used by
TC358764 and dts nodes to exynos5250.dtsi and exynos5250-arndale.dtsi.
Best regards,
Maciej Purski
Maciej Purski (12):
drm/exynos: rename "bridge_node" to "mic_bridge_node"
drm/exynos: move pm_runtime_get_sync() to exynos_dsi_init()
drm/exynos: move connector creation to attach callback
drm/exynos: add non-panel path to exynos_dsi_enable()
panel/hv070wsa-100: add DT bindings
drm/panel: add support for BOE HV070WSA-100 panel to simple-panel
dt-bindings: tc358754: add DT bindings
drm/bridge: tc358764: Add DSI to LVDS bridge driver
ARM: dts: exynos5250: add mipi-phy node
ARM: dts: exynos5250: add DSI node
ARM: dts: exynos5250-arndale: add display regulators
ARM: dts: exynos5250-arndale: add dsi and panel nodes
.../bindings/display/bridge/toshiba,tc358764.txt | 42 ++
.../bindings/display/panel/boe,hv070wsa-100.txt | 7 +
arch/arm/boot/dts/exynos5250-arndale.dts | 63 +++
arch/arm/boot/dts/exynos5250.dtsi | 20 +
drivers/gpu/drm/bridge/Kconfig | 7 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/tc358764.c | 547 +++++++++++++++++++++
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 84 ++--
drivers/gpu/drm/panel/panel-simple.c | 25 +
9 files changed, 756 insertions(+), 40 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
create mode 100644 Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt
create mode 100644 drivers/gpu/drm/bridge/tc358764.c
--
2.7.4
^ permalink raw reply
* [PATCH 01/12] drm/exynos: rename "bridge_node" to "mic_bridge_node"
From: Maciej Purski @ 2018-05-28 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527500833-16005-1-git-send-email-m.purski@samsung.com>
When adding support for peripheral out bridges, the "bridge" name
becomes imprecise as it refers to a different device than the
"out_bridge".
Signed-off-by: Maciej Purski <m.purski@samsung.com>
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index eae44fd..9599e6b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -279,7 +279,7 @@ struct exynos_dsi {
struct list_head transfer_list;
const struct exynos_dsi_driver_data *driver_data;
- struct device_node *bridge_node;
+ struct device_node *mic_bridge_node;
};
#define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
@@ -1631,7 +1631,7 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
if (ret < 0)
return ret;
- dsi->bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);
+ dsi->mic_bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);
return 0;
}
@@ -1642,7 +1642,7 @@ static int exynos_dsi_bind(struct device *dev, struct device *master,
struct drm_encoder *encoder = dev_get_drvdata(dev);
struct exynos_dsi *dsi = encoder_to_dsi(encoder);
struct drm_device *drm_dev = data;
- struct drm_bridge *bridge;
+ struct drm_bridge *mic_bridge;
int ret;
drm_encoder_init(drm_dev, encoder, &exynos_dsi_encoder_funcs,
@@ -1661,10 +1661,10 @@ static int exynos_dsi_bind(struct device *dev, struct device *master,
return ret;
}
- if (dsi->bridge_node) {
- bridge = of_drm_find_bridge(dsi->bridge_node);
- if (bridge)
- drm_bridge_attach(encoder, bridge, NULL);
+ if (dsi->mic_bridge_node) {
+ mic_bridge = of_drm_find_bridge(dsi->mic_bridge_node);
+ if (mic_bridge)
+ drm_bridge_attach(encoder, mic_bridge, NULL);
}
return mipi_dsi_host_register(&dsi->dsi_host);
@@ -1783,7 +1783,7 @@ static int exynos_dsi_remove(struct platform_device *pdev)
{
struct exynos_dsi *dsi = platform_get_drvdata(pdev);
- of_node_put(dsi->bridge_node);
+ of_node_put(dsi->mic_bridge_node);
pm_runtime_disable(&pdev->dev);
--
2.7.4
^ permalink raw reply related
* [PATCH 02/12] drm/exynos: move pm_runtime_get_sync() to exynos_dsi_init()
From: Maciej Purski @ 2018-05-28 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527500833-16005-1-git-send-email-m.purski@samsung.com>
In order to allow bridge drivers to use DSI transfers in their
pre_enable callbacks, pm_runtime_get_sync() should be performed before
exynos_dsi_enable(). DSIM_STATE_ENABLED flag now should not guard
from calling dsi_host_transfer() before enabling.
Signed-off-by: Maciej Purski <m.purski@samsung.com>
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 9599e6b..94460b0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1312,6 +1312,7 @@ static int exynos_dsi_init(struct exynos_dsi *dsi)
{
const struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
+ pm_runtime_get_sync(dsi->dev);
exynos_dsi_reset(dsi);
exynos_dsi_enable_irq(dsi);
@@ -1388,7 +1389,6 @@ static void exynos_dsi_enable(struct drm_encoder *encoder)
ret = drm_panel_prepare(dsi->panel);
if (ret < 0) {
dsi->state &= ~DSIM_STATE_ENABLED;
- pm_runtime_put_sync(dsi->dev);
return;
}
@@ -1400,7 +1400,6 @@ static void exynos_dsi_enable(struct drm_encoder *encoder)
dsi->state &= ~DSIM_STATE_ENABLED;
exynos_dsi_set_display_enable(dsi, false);
drm_panel_unprepare(dsi->panel);
- pm_runtime_put_sync(dsi->dev);
return;
}
@@ -1566,9 +1565,6 @@ static ssize_t exynos_dsi_host_transfer(struct mipi_dsi_host *host,
struct exynos_dsi_transfer xfer;
int ret;
- if (!(dsi->state & DSIM_STATE_ENABLED))
- return -EINVAL;
-
if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
ret = exynos_dsi_init(dsi);
if (ret)
--
2.7.4
^ permalink raw reply related
* [PATCH 03/12] drm/exynos: move connector creation to attach callback
From: Maciej Purski @ 2018-05-28 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527500833-16005-1-git-send-email-m.purski@samsung.com>
The current implementation assumes that the only possible peripheral
device for DSIM is a panel. Using an output bridge should also be
possible.
If an output bridge in available, don't create a new connector.
Instead add bridge to DSIM encdoer in dsi_host_attach().
Signed-off-by: Maciej Purski <m.purski@samsung.com>
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 35 +++++++++++++++++++++------------
1 file changed, 22 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 94460b0..8957faf 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1498,7 +1498,28 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
struct mipi_dsi_device *device)
{
struct exynos_dsi *dsi = host_to_dsi(host);
- struct drm_device *drm = dsi->connector.dev;
+ struct drm_encoder *encoder = &dsi->encoder;
+ struct drm_device *drm = encoder->dev;
+ struct drm_bridge *out_bridge;
+
+ out_bridge = of_drm_find_bridge(device->dev.of_node);
+ if (out_bridge) {
+ drm_bridge_attach(encoder, out_bridge, NULL);
+ } else {
+ int ret = exynos_dsi_create_connector(encoder);
+
+ if (ret) {
+ DRM_ERROR("failed to create connector ret = %d\n", ret);
+ drm_encoder_cleanup(encoder);
+ return ret;
+ }
+
+ dsi->panel = of_drm_find_panel(device->dev.of_node);
+ if (dsi->panel) {
+ drm_panel_attach(dsi->panel, &dsi->connector);
+ dsi->connector.status = connector_status_connected;
+ }
+ }
/*
* This is a temporary solution and should be made by more generic way.
@@ -1517,11 +1538,6 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
dsi->lanes = device->lanes;
dsi->format = device->format;
dsi->mode_flags = device->mode_flags;
- dsi->panel = of_drm_find_panel(device->dev.of_node);
- if (dsi->panel) {
- drm_panel_attach(dsi->panel, &dsi->connector);
- dsi->connector.status = connector_status_connected;
- }
exynos_drm_crtc_get_by_type(drm, EXYNOS_DISPLAY_TYPE_LCD)->i80_mode =
!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO);
@@ -1650,13 +1666,6 @@ static int exynos_dsi_bind(struct device *dev, struct device *master,
if (ret < 0)
return ret;
- ret = exynos_dsi_create_connector(encoder);
- if (ret) {
- DRM_ERROR("failed to create connector ret = %d\n", ret);
- drm_encoder_cleanup(encoder);
- return ret;
- }
-
if (dsi->mic_bridge_node) {
mic_bridge = of_drm_find_bridge(dsi->mic_bridge_node);
if (mic_bridge)
--
2.7.4
^ permalink raw reply related
* [PATCH 04/12] drm/exynos: add non-panel path to exynos_dsi_enable()
From: Maciej Purski @ 2018-05-28 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527500833-16005-1-git-send-email-m.purski@samsung.com>
As DSIM can now have a bridge connected as a peripheral, it should be
possible to successfully enable exynos_dsi, when there is no panel
provided.
Signed-off-by: Maciej Purski <m.purski@samsung.com>
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 27 +++++++++++++--------------
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 8957faf..7d92e50 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1382,27 +1382,26 @@ static void exynos_dsi_enable(struct drm_encoder *encoder)
if (dsi->state & DSIM_STATE_ENABLED)
return;
- pm_runtime_get_sync(dsi->dev);
-
- dsi->state |= DSIM_STATE_ENABLED;
-
- ret = drm_panel_prepare(dsi->panel);
- if (ret < 0) {
- dsi->state &= ~DSIM_STATE_ENABLED;
- return;
+ if (dsi->panel) {
+ ret = drm_panel_prepare(dsi->panel);
+ if (ret < 0) {
+ return;
+ }
}
exynos_dsi_set_display_mode(dsi);
exynos_dsi_set_display_enable(dsi, true);
- ret = drm_panel_enable(dsi->panel);
- if (ret < 0) {
- dsi->state &= ~DSIM_STATE_ENABLED;
- exynos_dsi_set_display_enable(dsi, false);
- drm_panel_unprepare(dsi->panel);
- return;
+ if (dsi->panel) {
+ ret = drm_panel_enable(dsi->panel);
+ if (ret < 0) {
+ exynos_dsi_set_display_enable(dsi, false);
+ drm_panel_unprepare(dsi->panel);
+ return;
+ }
}
+ dsi->state |= DSIM_STATE_ENABLED;
dsi->state |= DSIM_STATE_VIDOUT_AVAILABLE;
}
--
2.7.4
^ permalink raw reply related
* [PATCH 05/12] panel/hv070wsa-100: add DT bindings
From: Maciej Purski @ 2018-05-28 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527500833-16005-1-git-send-email-m.purski@samsung.com>
The patch adds bindings to BOE HV070-WSA WSVGA panel.
Bindings are compatible with simple panel bindings.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Maciej Purski <m.purski@samsung.com>
---
.../devicetree/bindings/display/panel/boe,hv070wsa-100.txt | 7 +++++++
1 file changed, 7 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt
diff --git a/Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt b/Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt
new file mode 100644
index 0000000..bfc20ac
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt
@@ -0,0 +1,7 @@
+BOE HV070WSA-100 7.01" WSVGA TFT LCD panel
+
+Required properties:
+- compatible: should be "boe,hv070wsa-100"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
--
2.7.4
^ permalink raw reply related
* [PATCH 06/12] drm/panel: add support for BOE HV070WSA-100 panel to simple-panel
From: Maciej Purski @ 2018-05-28 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527500833-16005-1-git-send-email-m.purski@samsung.com>
The patch adds support for BOE HV070WSA-100 WSVGA 7.01 inch panel
in panel-simple driver. The panel is used in Exynos5250-arndale boards.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Maciej Purski <m.purski@samsung.com>
---
drivers/gpu/drm/panel/panel-simple.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index cbf1ab4..d5da58d 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -745,6 +745,28 @@ static const struct panel_desc avic_tm070ddh03 = {
},
};
+static const struct drm_display_mode boe_hv070wsa_mode = {
+ .clock = 40800,
+ .hdisplay = 1024,
+ .hsync_start = 1024 + 90,
+ .hsync_end = 1024 + 90 + 90,
+ .htotal = 1024 + 90 + 90 + 90,
+ .vdisplay = 600,
+ .vsync_start = 600 + 3,
+ .vsync_end = 600 + 3 + 4,
+ .vtotal = 600 + 3 + 4 + 3,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc boe_hv070wsa = {
+ .modes = &boe_hv070wsa_mode,
+ .num_modes = 1,
+ .size = {
+ .width = 154,
+ .height = 90,
+ },
+};
+
static const struct drm_display_mode boe_nv101wxmn51_modes[] = {
{
.clock = 71900,
@@ -2113,6 +2135,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "avic,tm070ddh03",
.data = &avic_tm070ddh03,
}, {
+ .compatible = "boe,hv070wsa-100",
+ .data = &boe_hv070wsa
+ }, {
.compatible = "boe,nv101wxmn51",
.data = &boe_nv101wxmn51,
}, {
--
2.7.4
^ permalink raw reply related
* [PATCH 07/12] dt-bindings: tc358754: add DT bindings
From: Maciej Purski @ 2018-05-28 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527500833-16005-1-git-send-email-m.purski@samsung.com>
The patch adds bindings to Toshiba DSI/LVDS bridge TC358764.
Bindings describe power supplies, reset gpio and video interfaces.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Maciej Purski <m.purski@samsung.com>
---
.../bindings/display/bridge/toshiba,tc358764.txt | 42 ++++++++++++++++++++++
1 file changed, 42 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
new file mode 100644
index 0000000..d09bdc2
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
@@ -0,0 +1,42 @@
+TC358764 MIPI-DSI to LVDS panel bridge
+
+Required properties:
+ - compatible: "toshiba,tc358764"
+ - reg: the virtual channel number of a DSI peripheral
+ - vddc-supply: core voltage supply
+ - vddio-supply: I/O voltage supply
+ - vddmipi-supply: MIPI voltage supply
+ - vddlvds133-supply: LVDS1 3.3V voltage supply
+ - vddlvds112-supply: LVDS1 1.2V voltage supply
+ - reset-gpios: a GPIO spec for the reset pin
+
+The device node can contain zero to two 'port' child nodes, each with one
+child
+'endpoint' node, according to the bindings defined in [1].
+The following are properties specific to those nodes.
+
+port:
+ - reg: (required) can be 0 for DSI port or 1 for LVDS port;
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+ bridge at 0 {
+ reg = <0>;
+ compatible = "toshiba,tc358764";
+ vddc-supply = <&vcc_1v2_reg>;
+ vddio-supply = <&vcc_1v8_reg>;
+ vddmipi-supply = <&vcc_1v2_reg>;
+ vddlvds133-supply = <&vcc_3v3_reg>;
+ vddlvds112-supply = <&vcc_1v2_reg>;
+ reset-gpios = <&gpd1 6 GPIO_ACTIVE_LOW>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port at 1 {
+ reg = <1>;
+ lvds_ep: endpoint {
+ remote-endpoint = <&panel_ep>;
+ };
+ };
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH 08/12] drm/bridge: tc358764: Add DSI to LVDS bridge driver
From: Maciej Purski @ 2018-05-28 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527500833-16005-1-git-send-email-m.purski@samsung.com>
Add a drm_bridge driver for the Toshiba TC358764 DSI to LVDS bridge.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Maciej Purski <m.purski@samsung.com>
---
drivers/gpu/drm/bridge/Kconfig | 7 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/tc358764.c | 547 ++++++++++++++++++++++++++++++++++++++
3 files changed, 555 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/tc358764.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index fa2c799..58e19af 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -110,6 +110,13 @@ config DRM_THINE_THC63LVD1024
---help---
Thine THC63LVD1024 LVDS/parallel converter driver.
+config DRM_TOSHIBA_TC358764
+ tristate "TC358764 DSI/LVDS bridge"
+ depends on DRM && DRM_PANEL
+ depends on OF
+ select DRM_MIPI_DSI
+ select VIDEOMODE_HELPERS
+
config DRM_TOSHIBA_TC358767
tristate "Toshiba TC358767 eDP bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 35f88d4..bf7c0ce 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
obj-$(CONFIG_DRM_SII902X) += sii902x.o
obj-$(CONFIG_DRM_SII9234) += sii9234.o
obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
+obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o
obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
diff --git a/drivers/gpu/drm/bridge/tc358764.c b/drivers/gpu/drm/bridge/tc358764.c
new file mode 100644
index 0000000..0bd520a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/tc358764.c
@@ -0,0 +1,547 @@
+/*
+ * Copyright (C) 2018 Samsung Electronics Co., Ltd
+ *
+ * Authors:
+ * Andrzej Hajda <a.hajda@samsung.com>
+ * Maciej Purski <m.purski@samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.
+ *
+ */
+
+#include <drm/drm_atomic_helper.h>
+
+#include <drm/drmP.h>
+#include <drm/drm_mipi_dsi.h>
+#include <drm/drm_panel.h>
+
+#include <drm/drm_crtc.h>
+#include <drm/drm_crtc_helper.h>
+
+#include <linux/gpio/consumer.h>
+#include <linux/of_graph.h>
+#include <linux/regulator/consumer.h>
+
+#include <video/mipi_display.h>
+#include <video/of_videomode.h>
+#include <video/videomode.h>
+
+#define FLD_MASK(start, end) (((1 << ((start) - (end) + 1)) - 1) << (end))
+#define FLD_VAL(val, start, end) (((val) << (end)) & FLD_MASK(start, end))
+
+/* PPI layer registers */
+#define PPI_STARTPPI 0x0104 /* START control bit */
+#define PPI_LPTXTIMECNT 0x0114 /* LPTX timing signal */
+#define PPI_LANEENABLE 0x0134 /* Enables each lane */
+#define PPI_TX_RX_TA 0x013C /* BTA timing parameters */
+#define PPI_D0S_CLRSIPOCOUNT 0x0164 /* Assertion timer for Lane 0 */
+#define PPI_D1S_CLRSIPOCOUNT 0x0168 /* Assertion timer for Lane 1 */
+#define PPI_D2S_CLRSIPOCOUNT 0x016C /* Assertion timer for Lane 2 */
+#define PPI_D3S_CLRSIPOCOUNT 0x0170 /* Assertion timer for Lane 3 */
+#define PPI_START_FUNCTION 1
+
+/* DSI layer registers */
+#define DSI_STARTDSI 0x0204 /* START control bit of DSI-TX */
+#define DSI_LANEENABLE 0x0210 /* Enables each lane */
+#define DSI_RX_START 1
+
+/* Video path registers */
+#define VP_CTRL 0x0450 /* Video Path Control */
+#define VP_CTRL_MSF(v) FLD_VAL(v, 0, 0) /* Magic square in RGB666 */
+#define VP_CTRL_VTGEN(v) FLD_VAL(v, 4, 4) /* Use chip clock for timing */
+#define VP_CTRL_EVTMODE(v) FLD_VAL(v, 5, 5) /* Event mode */
+#define VP_CTRL_RGB888(v) FLD_VAL(v, 8, 8) /* RGB888 mode */
+#define VP_CTRL_VSDELAY(v) FLD_VAL(v, 31, 20) /* VSYNC delay */
+#define VP_CTRL_HSPOL BIT(17) /* Polarity of HSYNC signal */
+#define VP_CTRL_DEPOL BIT(18) /* Polarity of DE signal */
+#define VP_CTRL_VSPOL BIT(19) /* Polarity of VSYNC signal */
+#define VP_HTIM1 0x0454 /* Horizontal Timing Control 1 */
+#define VP_HTIM1_HBP(v) FLD_VAL(v, 24, 16)
+#define VP_HTIM1_HSYNC(v) FLD_VAL(v, 8, 0)
+#define VP_HTIM2 0x0458 /* Horizontal Timing Control 2 */
+#define VP_HTIM2_HFP(v) FLD_VAL(v, 24, 16)
+#define VP_HTIM2_HACT(v) FLD_VAL(v, 10, 0)
+#define VP_VTIM1 0x045C /* Vertical Timing Control 1 */
+#define VP_VTIM1_VBP(v) FLD_VAL(v, 23, 16)
+#define VP_VTIM1_VSYNC(v) FLD_VAL(v, 7, 0)
+#define VP_VTIM2 0x0460 /* Vertical Timing Control 2 */
+#define VP_VTIM2_VFP(v) FLD_VAL(v, 23, 16)
+#define VP_VTIM2_VACT(v) FLD_VAL(v, 10, 0)
+#define VP_VFUEN 0x0464 /* Video Frame Timing Update Enable */
+
+/* LVDS registers */
+#define LV_MX0003 0x0480 /* Mux input bit 0 to 3 */
+#define LV_MX0407 0x0484 /* Mux input bit 4 to 7 */
+#define LV_MX0811 0x0488 /* Mux input bit 8 to 11 */
+#define LV_MX1215 0x048C /* Mux input bit 12 to 15 */
+#define LV_MX1619 0x0490 /* Mux input bit 16 to 19 */
+#define LV_MX2023 0x0494 /* Mux input bit 20 to 23 */
+#define LV_MX2427 0x0498 /* Mux input bit 24 to 27 */
+#define LV_MX(b0, b1, b2, b3) (FLD_VAL(b0, 4, 0) | FLD_VAL(b1, 12, 8) | \
+ FLD_VAL(b2, 20, 16) | FLD_VAL(b3, 28, 24))
+
+/* Input bit numbers used in mux registers */
+enum {
+ LVI_R0,
+ LVI_R1,
+ LVI_R2,
+ LVI_R3,
+ LVI_R4,
+ LVI_R5,
+ LVI_R6,
+ LVI_R7,
+ LVI_G0,
+ LVI_G1,
+ LVI_G2,
+ LVI_G3,
+ LVI_G4,
+ LVI_G5,
+ LVI_G6,
+ LVI_G7,
+ LVI_B0,
+ LVI_B1,
+ LVI_B2,
+ LVI_B3,
+ LVI_B4,
+ LVI_B5,
+ LVI_B6,
+ LVI_B7,
+ LVI_HS,
+ LVI_VS,
+ LVI_DE,
+ LVI_L0
+};
+
+#define LV_CFG 0x049C /* LVDS Configuration */
+#define LV_PHY0 0x04A0 /* LVDS PHY 0 */
+#define LV_PHY0_RST(v) FLD_VAL(v, 22, 22) /* PHY reset */
+#define LV_PHY0_IS(v) FLD_VAL(v, 15, 14)
+#define LV_PHY0_ND(v) FLD_VAL(v, 4, 0) /* Frequency range select */
+#define LV_PHY0_PRBS_ON(v) FLD_VAL(v, 20, 16) /* Clock/Data Flag pins */
+
+/* System registers */
+#define SYS_RST 0x0504 /* System Reset */
+#define SYS_ID 0x0580 /* System ID */
+
+#define SYS_RST_I2CS BIT(0) /* Reset I2C-Slave controller */
+#define SYS_RST_I2CM BIT(1) /* Reset I2C-Master controller */
+#define SYS_RST_LCD BIT(2) /* Reset LCD controller */
+#define SYS_RST_BM BIT(3) /* Reset Bus Management controller */
+#define SYS_RST_DSIRX BIT(4) /* Reset DSI-RX and App controller */
+#define SYS_RST_REG BIT(5) /* Reset Register module */
+
+#define LPX_PERIOD 2
+#define TTA_SURE 3
+#define TTA_GET 0x20000
+
+/* Lane enable PPI and DSI register bits */
+#define LANEENABLE_CLEN BIT(0)
+#define LANEENABLE_L0EN BIT(1)
+#define LANEENABLE_L1EN BIT(2)
+#define LANEENABLE_L2EN BIT(3)
+#define LANEENABLE_L3EN BIT(4)
+
+/* LVCFG fields */
+#define LV_CFG_LVEN BIT(0)
+#define LV_CFG_LVDLINK BIT(1)
+#define LV_CFG_CLKPOL1 BIT(2)
+#define LV_CFG_CLKPOL2 BIT(3)
+
+
+static const char * const tc358764_supplies[] = {
+ "vddc", "vddio", "vddmipi", "vddlvds133", "vddlvds112"
+};
+
+struct tc358764 {
+ struct device *dev;
+ struct drm_bridge bridge;
+ struct drm_connector connector;
+ struct regulator_bulk_data supplies[ARRAY_SIZE(tc358764_supplies)];
+ struct gpio_desc *gpio_reset;
+
+ struct drm_panel *panel;
+};
+
+int tc358764_read(struct tc358764 *ctx, u16 addr, u32 *val)
+{
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+ const struct mipi_dsi_host_ops *ops = dsi->host->ops;
+ struct mipi_dsi_msg msg = {
+ .type = MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM,
+ .channel = dsi->channel,
+ .flags = MIPI_DSI_MSG_USE_LPM,
+ .tx_buf = &addr,
+ .tx_len = 2,
+ .rx_buf = val,
+ .rx_len = 4
+ };
+ ssize_t ret;
+
+ if (!ops || !ops->transfer)
+ return -EINVAL;
+
+ addr = cpu_to_le16(addr);
+
+ ret = ops->transfer(dsi->host, &msg);
+ if (ret >= 0)
+ *val = le32_to_cpu(*val);
+
+ dev_dbg(ctx->dev, "read: %d, addr: %d\n", addr, *val);
+
+ return ret;
+}
+
+int tc358764_write(struct tc358764 *ctx, u16 addr, u32 val)
+{
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+ const struct mipi_dsi_host_ops *ops = dsi->host->ops;
+ u8 data[6];
+ int ret;
+ struct mipi_dsi_msg msg = {
+ .type = MIPI_DSI_GENERIC_LONG_WRITE,
+ .channel = dsi->channel,
+ .flags = MIPI_DSI_MSG_USE_LPM | MIPI_DSI_MSG_REQ_ACK,
+ .tx_buf = data,
+ .tx_len = 6
+ };
+
+ if (!ops || !ops->transfer)
+ return -EINVAL;
+
+ data[0] = addr;
+ data[1] = addr >> 8;
+ data[2] = val;
+ data[3] = val >> 8;
+ data[4] = val >> 16;
+ data[5] = val >> 24;
+
+ ret = ops->transfer(dsi->host, &msg);
+
+ return ret;
+}
+
+static inline struct tc358764 *bridge_to_tc358764(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct tc358764, bridge);
+}
+
+static inline
+struct tc358764 *connector_to_tc358764(struct drm_connector *connector)
+{
+ return container_of(connector, struct tc358764, connector);
+}
+
+static int tc358764_init(struct tc358764 *ctx)
+{
+ u32 v = 0;
+
+ tc358764_read(ctx, SYS_ID, &v);
+ dev_info(ctx->dev, "ID: %#x\n", v);
+
+ /* configure PPI counters */
+ tc358764_write(ctx, PPI_TX_RX_TA, TTA_GET | TTA_SURE);
+ tc358764_write(ctx, PPI_LPTXTIMECNT, LPX_PERIOD);
+ tc358764_write(ctx, PPI_D0S_CLRSIPOCOUNT, 5);
+ tc358764_write(ctx, PPI_D1S_CLRSIPOCOUNT, 5);
+ tc358764_write(ctx, PPI_D2S_CLRSIPOCOUNT, 5);
+ tc358764_write(ctx, PPI_D3S_CLRSIPOCOUNT, 5);
+
+ /* enable four data lanes and clock lane */
+ tc358764_write(ctx, PPI_LANEENABLE, LANEENABLE_L3EN | LANEENABLE_L2EN |
+ LANEENABLE_L1EN | LANEENABLE_L0EN | LANEENABLE_CLEN);
+ tc358764_write(ctx, DSI_LANEENABLE, LANEENABLE_L3EN | LANEENABLE_L2EN |
+ LANEENABLE_L1EN | LANEENABLE_L0EN | LANEENABLE_CLEN);
+
+ /* start */
+ tc358764_write(ctx, PPI_STARTPPI, PPI_START_FUNCTION);
+ tc358764_write(ctx, DSI_STARTDSI, DSI_RX_START);
+
+ /* configure video path */
+ tc358764_write(ctx, VP_CTRL, VP_CTRL_VSDELAY(15) | VP_CTRL_RGB888(1) |
+ VP_CTRL_EVTMODE(1) | VP_CTRL_HSPOL | VP_CTRL_VSPOL);
+
+ /* reset PHY */
+ tc358764_write(ctx, LV_PHY0, LV_PHY0_RST(1) |
+ LV_PHY0_PRBS_ON(4) | LV_PHY0_IS(2) | LV_PHY0_ND(6));
+ tc358764_write(ctx, LV_PHY0, LV_PHY0_PRBS_ON(4) | LV_PHY0_IS(2) | LV_PHY0_ND(6));
+
+ /* reset bridge */
+ tc358764_write(ctx, SYS_RST, SYS_RST_LCD);
+
+ /* set bit order */
+ tc358764_write(ctx, LV_MX0003, LV_MX(LVI_R0, LVI_R1, LVI_R2, LVI_R3));
+ tc358764_write(ctx, LV_MX0407, LV_MX(LVI_R4, LVI_R7, LVI_R5, LVI_G0));
+ tc358764_write(ctx, LV_MX0811, LV_MX(LVI_G1, LVI_G2, LVI_G6, LVI_G7));
+ tc358764_write(ctx, LV_MX1215, LV_MX(LVI_G3, LVI_G4, LVI_G5, LVI_B0));
+ tc358764_write(ctx, LV_MX1619, LV_MX(LVI_B6, LVI_B7, LVI_B1, LVI_B2));
+ tc358764_write(ctx, LV_MX2023, LV_MX(LVI_B3, LVI_B4, LVI_B5, LVI_L0));
+ tc358764_write(ctx, LV_MX2427, LV_MX(LVI_HS, LVI_VS, LVI_DE, LVI_R6));
+ tc358764_write(ctx, LV_CFG, LV_CFG_CLKPOL2 | LV_CFG_CLKPOL1 |
+ LV_CFG_LVEN);
+
+ return 0;
+}
+
+static void tc358764_reset(struct tc358764 *ctx)
+{
+ msleep(20);
+ gpiod_set_value(ctx->gpio_reset, 0);
+ msleep(20);
+ gpiod_set_value(ctx->gpio_reset, 1);
+ msleep(40);
+}
+
+static void tc358764_poweroff(struct tc358764 *ctx)
+{
+ int ret;
+
+ tc358764_reset(ctx);
+
+ drm_panel_disable(ctx->panel);
+ msleep(40);
+
+ ret = regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
+ if (ret < 0)
+ dev_err(ctx->dev, "error disabling regulators (%d)\n", ret);
+}
+
+static int tc358764_get_modes(struct drm_connector *connector)
+{
+ struct tc358764 *ctx = connector_to_tc358764(connector);
+
+ if (ctx->panel && ctx->panel->funcs && ctx->panel->funcs->get_modes)
+ return ctx->panel->funcs->get_modes(ctx->panel);
+
+ return 0;
+}
+
+static const
+struct drm_connector_helper_funcs tc358764_connector_helper_funcs = {
+ .get_modes = tc358764_get_modes,
+};
+
+static const struct drm_connector_funcs tc358764_connector_funcs = {
+ .fill_modes = drm_helper_probe_single_connector_modes,
+ .destroy = drm_connector_cleanup,
+ .reset = drm_atomic_helper_connector_reset,
+ .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+static void tc358764_disable(struct drm_bridge *bridge)
+{
+ struct tc358764 *ctx = bridge_to_tc358764(bridge);
+
+ tc358764_poweroff(ctx);
+}
+
+static void tc358764_pre_enable(struct drm_bridge *bridge)
+{
+ struct tc358764 *ctx = bridge_to_tc358764(bridge);
+ int ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies),
+ ctx->supplies);
+ if (ret < 0)
+ dev_err(ctx->dev, "error enabling regulators (%d)\n", ret);
+
+ tc358764_reset(ctx);
+ tc358764_init(ctx);
+}
+
+static void tc358764_enable(struct drm_bridge *bridge)
+{
+ struct tc358764 *ctx = bridge_to_tc358764(bridge);
+ int ret;
+
+ drm_panel_prepare(ctx->panel);
+
+ ret = drm_panel_enable(ctx->panel);
+ if (ret < 0)
+ pr_err("panel enable failed\n");
+
+ msleep(40);
+}
+
+static int tc358764_attach(struct drm_bridge *bridge)
+{
+ struct tc358764 *ctx = bridge_to_tc358764(bridge);
+ struct drm_device *drm = bridge->dev;
+ int ret;
+
+ if (!bridge->encoder) {
+ DRM_ERROR("Encoder not found\n");
+ return -ENODEV;
+ }
+
+ ctx->connector.polled = DRM_CONNECTOR_POLL_HPD;
+ ret = drm_connector_init(drm, &ctx->connector,
+ &tc358764_connector_funcs,
+ DRM_MODE_CONNECTOR_LVDS);
+ if (ret) {
+ DRM_ERROR("Failed to initialize connector\n");
+ return ret;
+ }
+
+ drm_connector_helper_add(&ctx->connector,
+ &tc358764_connector_helper_funcs);
+
+ drm_mode_connector_attach_encoder(&ctx->connector, bridge->encoder);
+
+ if (ctx->panel)
+ drm_panel_attach(ctx->panel, &ctx->connector);
+
+ drm_atomic_helper_connector_reset(&ctx->connector);
+ drm_connector_register(&ctx->connector);
+
+ return 0;
+}
+
+static const struct drm_bridge_funcs tc358764_bridge_funcs = {
+ .disable = tc358764_disable,
+ .enable = tc358764_enable,
+ .pre_enable = tc358764_pre_enable,
+ .attach = tc358764_attach,
+};
+
+static struct device_node *tc358764_of_find_panel_node(struct device *dev)
+{
+ struct device_node *np, *ep;
+
+ ep = of_graph_get_endpoint_by_regs(dev->of_node, 1, 0);
+ if (!ep) {
+ pr_err("faile to get endpoint\n");
+ return NULL;
+ }
+
+ np = of_graph_get_remote_port_parent(ep);
+
+ return np;
+}
+
+static int tc358764_parse_dt(struct tc358764 *ctx)
+{
+ struct device *dev = ctx->dev;
+ struct device_node *np = dev->of_node;
+ struct device_node *lvds;
+
+ ctx->gpio_reset = devm_gpiod_get_from_of_node(dev, np, "reset", 0,
+ GPIOD_OUT_LOW,
+ "tc358764-reset");
+ if (IS_ERR(ctx->gpio_reset)) {
+ dev_err(dev, "no reset GPIO pin provided\n");
+ return PTR_ERR(ctx->gpio_reset);
+ }
+
+ lvds = tc358764_of_find_panel_node(ctx->dev);
+ if (!lvds) {
+ dev_err(dev, "cannot find panel node\n");
+ return -EINVAL;
+ }
+
+ ctx->panel = of_drm_find_panel(lvds);
+ if (!ctx->panel) {
+ dev_err(dev, "panel not registered\n");
+ return -EPROBE_DEFER;
+ }
+
+ return 0;
+}
+
+static int tc358764_configure_regulators(struct tc358764 *ctx)
+{
+ int i, ret;
+
+ for (i = 0; i < ARRAY_SIZE(ctx->supplies); ++i)
+ ctx->supplies[i].supply = tc358764_supplies[i];
+
+ ret = devm_regulator_bulk_get(ctx->dev, ARRAY_SIZE(ctx->supplies),
+ ctx->supplies);
+ if (ret < 0)
+ dev_err(ctx->dev, "failed to get regulators: %d\n", ret);
+
+ return ret;
+}
+
+static int tc358764_probe(struct mipi_dsi_device *dsi)
+{
+ struct device *dev = &dsi->dev;
+ struct tc358764 *ctx;
+ int ret;
+
+ ctx = devm_kzalloc(dev, sizeof(struct tc358764), GFP_KERNEL);
+ if (!ctx)
+ return -ENOMEM;
+
+ mipi_dsi_set_drvdata(dsi, ctx);
+
+ ctx->dev = dev;
+
+ dsi->lanes = 4;
+ dsi->format = MIPI_DSI_FMT_RGB888;
+ dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST
+ | MIPI_DSI_MODE_VIDEO_AUTO_VERT;
+
+ ret = tc358764_parse_dt(ctx);
+ if (ret < 0)
+ return ret;
+
+ ret = tc358764_configure_regulators(ctx);
+ if (ret < 0)
+ return ret;
+
+ ctx->bridge.funcs = &tc358764_bridge_funcs;
+ ctx->bridge.of_node = dev->of_node;
+
+ drm_bridge_add(&ctx->bridge);
+
+ ret = mipi_dsi_attach(dsi);
+ if (ret < 0) {
+ drm_bridge_remove(&ctx->bridge);
+ dev_err(dev, "failed to attach dsi\n");
+ }
+
+ return ret;
+}
+
+static int tc358764_remove(struct mipi_dsi_device *dsi)
+{
+ struct tc358764 *ctx = mipi_dsi_get_drvdata(dsi);
+
+ tc358764_poweroff(ctx);
+
+ mipi_dsi_detach(dsi);
+ drm_bridge_remove(&ctx->bridge);
+
+ return 0;
+}
+
+static const struct of_device_id tc358764_of_match[] = {
+ { .compatible = "toshiba,tc358764" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, tc358764_of_match);
+
+static struct mipi_dsi_driver tc358764_driver = {
+ .probe = tc358764_probe,
+ .remove = tc358764_remove,
+ .driver = {
+ .name = "tc358764",
+ .owner = THIS_MODULE,
+ .of_match_table = tc358764_of_match,
+ },
+};
+module_mipi_dsi_driver(tc358764_driver);
+
+MODULE_AUTHOR("Andrzej Hajda <a.hajda@samsung.com>");
+MODULE_AUTHOR("Maciej Purski <m.purski@samsung.com>");
+MODULE_DESCRIPTION("MIPI-DSI based Driver for TC358764 DSI/LVDS Bridge");
+MODULE_LICENSE("GPL v2");
--
2.7.4
^ permalink raw reply related
* [PATCH 09/12] ARM: dts: exynos5250: add mipi-phy node
From: Maciej Purski @ 2018-05-28 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527500833-16005-1-git-send-email-m.purski@samsung.com>
The patch adds phy node, required by MIPI devices.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Maciej Purski <m.purski@samsung.com>
---
arch/arm/boot/dts/exynos5250.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index 2daf505..a63b655 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -733,6 +733,12 @@
#phy-cells = <0>;
};
+ mipi_phy: video-phy at 10040710 {
+ compatible = "samsung,s5pv210-mipi-video-phy";
+ #phy-cells = <1>;
+ syscon = <&pmu_system_controller>;
+ };
+
adc: adc at 12d10000 {
compatible = "samsung,exynos-adc-v1";
reg = <0x12D10000 0x100>;
--
2.7.4
^ permalink raw reply related
* [GIT PULL] Allwinner core changes for 4.18
From: Marc Zyngier @ 2018-05-28 9:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v64JD+xdLptx2O1JZUw3n1wzyHtwS6BQTznXBZ78w3tMzg@mail.gmail.com>
On Sun, 27 May 2018 06:31:17 +0100,
Chen-Yu Tsai wrote:
>
> On Sat, May 26, 2018 at 11:21 AM, Olof Johansson <olof@lixom.net> wrote:
> > On Sat, May 26, 2018 at 6:22 PM, Chen-Yu Tsai <wens@csie.org> wrote:
> >> On Fri, May 25, 2018 at 2:02 PM, Olof Johansson <olof@lixom.net> wrote:
> >>> On Mon, May 21, 2018 at 01:41:56PM +0200, Maxime Ripard wrote:
> >>>> Hi,
> >>>>
> >>>> Here is our mach-sunxi changes for the next merge window, thanks!
> >>>> Maxime
> >>>>
> >>>> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
> >>>>
> >>>> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
> >>>>
> >>>> are available in the Git repository at:
> >>>>
> >>>> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-core-for-4.18
> >>>>
> >>>> for you to fetch changes up to 6961275e72a8c15cc4ebf108a81eee758480a6a2:
> >>>>
> >>>> ARM: sun8i: smp: Add support for A83T (2018-05-08 15:00:20 +0200)
> >>>>
> >>>> ----------------------------------------------------------------
> >>>> Allwinner core changes for 4.18
> >>>>
> >>>> The A83t, unlike the other Allwinner SoCs, cannot use PSCI because of a
> >>>> silicon bug. As such, we needed to have some smp_ops in order to bringup
> >>>> the various cores (and clusters) found on this SoC.
> >>>
> >>> Hrm. that's unfortunate. Is there any public documentation of what the bug is?
> >>
> >> The security extensions in the A80 and A83T is not entirely enabled.
> >> The security bit is not forwarded on to the bus, so all accesses from
> >> non-secure become secure. This is not documented, but was the result
> >> of some tests I did.
> >>
> >> See https://lists.denx.de/pipermail/u-boot/2017-June/294672.html
> >> for a summary (in the quotes) of what we think is the issue.
> >>
> >> Marc's suggestion is that if virtualization doesn't work on it, then
> >> there's no point in running it non-secure. [1]
> >
> > So it sounds like you can still use PSCI even if there's nothing that
> > stops the kernel from also doing the same operations. It doesn't buy
> > you any security benefits, but you can use the same standard
> > interfaces as everybody else does. I think there's still value in
> > that. Or am I missing some aspect of the errata implications?
>
> IIRC the GIC does not work correctly. Interrupts are configured to be
> non-secure by the PSCI implementation, prior to entering the kernel.
> The GIC driver uses the standard registers to program or ack interrupts.
> But since non-secure accesses appear to be secure outside the ARM
> cores, it ends up touching the wrong set of registers. The driver
> needs to be taught to use the NS alias registers. But then, how does
> one confer the need for such a workaround? I actually did some patches
> that work for the A80, just to test things out.
>
> I asked Marc (CC-ed) for some input, and basically he said it's probably
> not worth the headache and trouble.
I think it is worth splitting the two issues:
- Yes, trying to use non-secure interrupts on a GIC that doesn't know
about non-secure accesses is pretty terrible (the HW should never
have made it into production). I"m definitely not entertaining the
idea of taking patches for that.
- I'm not sure that completely kills the idea of using PSCI. I don't
think that PSCI, on its own, mandates that the OS runs in
non-secure, and an implementation could probably be convinced to
boot the kernel in secure mode. PSCI also doesn't say anything about
the GIC, and it is just an implementation convenience to configure
interrupts to be Group-1 NS as part of the PSCI implementation.
At the end of the day, it is a matter of defining where we want the
crap to be put (either in the firmware or in the kernel), and whether
you can easily update the firmware to do PSCI and yet not mess with
the GIC.
Thanks,
M.
--
Jazz is not dead, it just smell funny.
^ permalink raw reply
* [PATCH 10/12] ARM: dts: exynos5250: add DSI node
From: Maciej Purski @ 2018-05-28 9:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527500833-16005-1-git-send-email-m.purski@samsung.com>
The patch adds common part of DSI node for Exynos5250 platforms.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Maciej Purski <m.purski@samsung.com>
---
arch/arm/boot/dts/exynos5250.dtsi | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index a63b655..7403b96 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -739,6 +739,20 @@
syscon = <&pmu_system_controller>;
};
+ dsi_0: dsi at 14500000 {
+ compatible = "samsung,exynos4210-mipi-dsi";
+ reg = <0x14500000 0x10000>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ samsung,power-domain = <&pd_disp1>;
+ phys = <&mipi_phy 3>;
+ phy-names = "dsim";
+ clocks = <&clock CLK_DSIM0>, <&clock CLK_SCLK_MIPI1>;
+ clock-names = "bus_clk", "sclk_mipi";
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
adc: adc at 12d10000 {
compatible = "samsung,exynos-adc-v1";
reg = <0x12D10000 0x100>;
--
2.7.4
^ permalink raw reply related
* [PATCH 11/12] ARM: dts: exynos5250-arndale: add display regulators
From: Maciej Purski @ 2018-05-28 9:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527500833-16005-1-git-send-email-m.purski@samsung.com>
The patch adds fixed regulators used by DSI/LVDS bridge
and panel. Regulators are named according to schematics.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Maciej Purski <m.purski@samsung.com>
---
arch/arm/boot/dts/exynos5250-arndale.dts | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts
index 7a8a5c5..80221fa 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -97,6 +97,30 @@
reg = <2>;
regulator-name = "hdmi-en";
};
+
+ vcc_1v2_reg: regulator at 3 {
+ compatible = "regulator-fixed";
+ reg = <3>;
+ regulator-name = "VCC_1V2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+
+ vcc_1v8_reg: regulator at 4 {
+ compatible = "regulator-fixed";
+ reg = <4>;
+ regulator-name = "VCC_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ vcc_3v3_reg: regulator at 5 {
+ compatible = "regulator-fixed";
+ reg = <5>;
+ regulator-name = "VCC_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
};
fixed-rate-clocks {
--
2.7.4
^ permalink raw reply related
* [PATCH 12/12] ARM: dts: exynos5250-arndale: add dsi and panel nodes
From: Maciej Purski @ 2018-05-28 9:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527500833-16005-1-git-send-email-m.purski@samsung.com>
The patch adds bridge and panel nodes.
It adds also DSI properties specific for arndale board.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Maciej Purski <m.purski@samsung.com>
---
arch/arm/boot/dts/exynos5250-arndale.dts | 39 ++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts
index 80221fa..6f0b1c4 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -71,6 +71,17 @@
};
};
+ panel: panel {
+ compatible = "boe,hv070wsa-100";
+ power-supply = <&vcc_3v3_reg>;
+ enable-gpios = <&gpd1 3 GPIO_ACTIVE_HIGH>;
+ port {
+ panel_ep: endpoint {
+ remote-endpoint = <&bridge_out_ep>;
+ };
+ };
+ };
+
regulators {
compatible = "simple-bus";
#address-cells = <1>;
@@ -476,6 +487,34 @@
};
};
+&dsi_0 {
+ vddcore-supply = <&ldo8_reg>;
+ vddio-supply = <&ldo10_reg>;
+ samsung,pll-clock-frequency = <24000000>;
+ samsung,burst-clock-frequency = <320000000>;
+ samsung,esc-clock-frequency = <10000000>;
+ status = "okay";
+
+ bridge at 0 {
+ reg = <0>;
+ compatible = "toshiba,tc358764";
+ vddc-supply = <&vcc_1v2_reg>;
+ vddio-supply = <&vcc_1v8_reg>;
+ vddmipi-supply = <&vcc_1v2_reg>;
+ vddlvds133-supply = <&vcc_3v3_reg>;
+ vddlvds112-supply = <&vcc_1v2_reg>;
+ reset-gpios = <&gpd1 6 GPIO_ACTIVE_LOW>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port at 1 {
+ reg = <1>;
+ bridge_out_ep: endpoint {
+ remote-endpoint = <&panel_ep>;
+ };
+ };
+ };
+};
+
&i2c_2 {
status = "okay";
/* used by HDMI DDC */
--
2.7.4
^ permalink raw reply related
* [PATCH v4 4/8] PCI: Replace dev_node parameter of of_pci_get_host_bridge_resources with device
From: Vladimir Zapolskiy @ 2018-05-28 10:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5f2226585c6af9920b266d0503e32042d4c9e440.1526375226.git.jan.kiszka@siemens.com>
Hi Jan, Bjorn,
On 05/15/2018 12:07 PM, Jan Kiszka wrote:
> From: Jan Kiszka <jan.kiszka@siemens.com>
>
> Another step towards a managed version of
> of_pci_get_host_bridge_resources(): Feed in the underlying device,
> rather than just the OF node. This will allow to use managed resource
> allocation internally later on.
>
> CC: Jingoo Han <jingoohan1@gmail.com>
> CC: Joao Pinto <Joao.Pinto@synopsys.com>
> CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
[snip]
> diff --git a/drivers/pci/host/pcie-altera.c b/drivers/pci/host/pcie-altera.c
> index a6af62e0256d..61802e55a00c 100644
> --- a/drivers/pci/host/pcie-altera.c
> +++ b/drivers/pci/host/pcie-altera.c
> @@ -488,11 +488,10 @@ static int altera_pcie_parse_request_of_pci_ranges(struct altera_pcie *pcie)
> {
> int err, res_valid = 0;
> struct device *dev = &pcie->pdev->dev;
> - struct device_node *np = dev->of_node;
> struct resource_entry *win;
>
> - err = of_pci_get_host_bridge_resources(np, 0, 0xff, &pcie->resources,
> - NULL);
> + err = of_pci_get_host_bridge_resources(dev, 0, 0xff
> + &pcie->resources, NULL);
> if (err)
> return err;
>
In case if it is an undiscovered issue, a comma was mistakenly removed,
which will result it compilation error.
The problem is also found in pci/next , see commit 88e3909aa125.
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH v4 6/6] tty/serial: atmel: changed the driver to work under at91-usart mfd
From: Richard Genoud @ 2018-05-28 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525171941.26766-7-radu.pirea@microchip.com>
On 25/05/2018 19:19, Radu Pirea wrote:
> This patch modifies the place where resources and device tree properties
> are searched.
>
> Signed-off-by: Radu Pirea <radu.pirea@microchip.com>
> ---
> drivers/tty/serial/Kconfig | 1 +
> drivers/tty/serial/atmel_serial.c | 40 +++++++++++++++++--------------
> 2 files changed, 23 insertions(+), 18 deletions(-)
the stdout-path property of the chosen node is still broken in this verion.
if :
stdout-path = "serial0:115200n8";
is set in the DTS, the console output should go on serial0 (aka dbgu)
cf Documentation/devicetree/bindings/chosen.txt
With this patch applied, this is not the case anymore.
Adding console=ttyS0,115200 in the chosen node is not the solution here.
regards,
Richard.
^ permalink raw reply
* [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma
From: Peter Rosin @ 2018-05-28 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9c496531-f7b6-4b9d-dd51-0bfb68ead303@axentia.se>
On 2018-05-28 00:11, Peter Rosin wrote:
> On 2018-05-27 11:18, Peter Rosin wrote:
>> On 2018-05-25 16:51, Tudor Ambarus wrote:
>>> We think the best way is to keep LCD on DDR Ports 2 and 3 (8th and 9th
>>> slaves), to have maximum bandwidth and to use DMA on DDR port 1 for NAND
>>> (7th slave).
>>
>> Exactly how do I accomplish that?
>>
>> I can see how I can move the LCD between slave DDR port 2 and 3 by
>> selecting LCDC DMA master 8 or 9 (but according to the above it should
>> not matter). The big question is how I control what slave the NAND flash
>> is going to use? I find nothing in the datasheet, and the code is also
>> non-transparent enough for me to figure it out by myself without
>> throwing out this question first...
>
> I added this:
>
> diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c b/drivers/mtd/nand/raw/atmel/nand-controller.c
> index e686fe73159e..3b33c63d2ed4 100644
> --- a/drivers/mtd/nand/raw/atmel/nand-controller.c
> +++ b/drivers/mtd/nand/raw/atmel/nand-controller.c
> @@ -1991,6 +1991,9 @@ static int atmel_nand_controller_init(struct atmel_nand_controller *nc,
> nc->dmac = dma_request_channel(mask, NULL, NULL);
> if (!nc->dmac)
> dev_err(nc->dev, "Failed to request DMA channel\n");
> +
> + dev_info(nc->dev, "using %s for DMA transfers\n",
> + dma_chan_name(nc->dmac));
> }
>
> /* We do not retrieve the SMC syscon when parsing old DTs. */
>
>
>
> and the output is
>
> atmel-nand-controller 10000000.ebi:nand-controller: using dma0chan5 for DMA transfers
>
> So, DMA controller 0 is in use. I still don't know if IF0, IF1 or IF2 is used
> or how to find out. I guess IF2 is not in use since that does not allow any
> DDR2 port as slave...
>
> From the datasheet, DMAC0/IF0 uses DDR2 Port 2, and DMAC0/IF1 uses DDR2 Port 1.
> But, by the looks of the register content in my other mail, it seems as if
> DMA0/IF1 can also use DDR2 Port 3.
>
> So, I think I want either
>
> A) the NAND controller to use DMAC0/IF0 (i.e. DDR2 port 1, and possibly 3) and
> the LCDC to use master 9 (i.e. DDR2 Port 2)
>
> or
>
> B) the NAND controller to use DMAC1/IF1 (i.e. DDR2 port 2) and the LCDC to use
> master 8 (i.e. DDR2 Port 3)
Crap, that was not what I meant to express. Sorry for the confusion. This is
better.
So, I think I want either
A) the NAND controller to use master 1 DMAC0/IF0 (i.e. slave 8 DDR2 port 2) and
the LCDC to use master 9 (i.e. slave 9 DDR2 Port 3)
or
B) the NAND controller to use master 2 DMAC0/IF1 (i.e. slave 7 DDR2 port 1, and
possibly slave 9 DDR2 port 3 (if my previous findings are relevant) and the
LCDC to use master 8 (i.e. slave 8 DDR2 Port 2)
> But, again, how do I limit DMAC0 to either of IF0 or IF1 for NAND accesses?
So, I added a horrid patch (attached), which mainly adds printk lines, but
additionally does one more thing in atc_prep_dma_memcpy. It changes the DSCR_IF
field (from 0) to 1 for DMA-memcpy for dma0chan5 (i.e. the NAND). At least I
think it does that?
Running with that patch gets me this:
# dmesg | grep -i dma
at_hdmac ffffe600.dma-controller: Atmel AHB DMA Controller ( cpy set slave ), 8 channels
at_hdmac ffffe800.dma-controller: Atmel AHB DMA Controller ( cpy set slave ), 8 channels
dma dma0chan0: xlate 0 2
dma dma0chan1: xlate 0 2
at91_i2c f0014000.i2c: using dma0chan0 (tx) and dma0chan1 (rx) for DMA transfers
dma dma1chan0: xlate 0 2
dma dma1chan1: xlate 0 2
at91_i2c f801c000.i2c: using dma1chan0 (tx) and dma1chan1 (rx) for DMA transfers
dma dma0chan2: xlate 0 2
dma dma0chan3: xlate 0 2
dma dma0chan4: xlate 0 2
atmel_mci f0000000.mmc: using dma0chan4 for DMA transfers
dma dma1chan2: xlate 0 2
dma dma1chan3: xlate 0 2
atmel_aes f8038000.aes: Atmel AES - Using dma1chan2, dma1chan3 for DMA transfers
dma dma1chan4: xlate 0 2
atmel_sha f8034000.sha: using dma1chan4 for DMA transfers
dma dma1chan5: xlate 0 2
dma dma1chan6: xlate 0 2
atmel_tdes f803c000.tdes: using dma1chan5, dma1chan6 for DMA transfers
atmel-nand-controller 10000000.ebi:nand-controller: using dma0chan5 for DMA transfers
dma dma0chan5: memcpy: 0
dma dma0chan5: DSCR_IF: 1
dma dma0chan5: memcpy: 1
So, output is as expected and I believe that the patch makes the NAND DMA
accesses use master 2 DMAC0/IF1 and are thus forced to use slave 7 DDR2 Port 1
(and possibly 9). The LCDC is using slave 8 DDR2 Port 2. So there should be no
slave conflict?
But the on-screen crap remains during NAND accesses.
But pressing on.
I then changed the priorities for all accesses to 0 in the PRxSy registers, except
the ones for masters 8/9 LCDC (slaves 8/9) which I left at priority 3.
But the on-screen crap remains during NAND accesses.
My guess is that the NAND DMA is doing too long bursts and that the LCDC therefore
has to wait too long and simply fails to keep the pipeline from running short?
So I tried to reduce the maximum SLOT_CYCLE for slaves 7 and 9 in the SCFGx
registers. No noticeable effect either.
I then tried to split bursts from master 2 (DMAC0/IF1) with small values in the
MCFG2 register. No effect.
I'm getting nowhere.
Cheers,
Peter
-------------- next part --------------
diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index 75f38d19fcbe..6cb58197bd29 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -243,6 +243,18 @@ static void atc_dostart(struct at_dma_chan *atchan, struct at_desc *first)
vdbg_dump_regs(atchan);
+ if (atchan->chan_common.chan_id == 5 &&
+ atchan->chan_common.device->dev_id == 0)
+ {
+ static u32 last_if = 4;
+ u32 this_if = first->txd.phys & 3;
+ if (this_if != last_if) {
+ dev_info(chan2dev(&atchan->chan_common),
+ "DSCR_IF: %u\n", this_if);
+ last_if = this_if;
+ }
+ }
+
channel_writel(atchan, SADDR, 0);
channel_writel(atchan, DADDR, 0);
channel_writel(atchan, CTRLA, 0);
@@ -854,6 +866,19 @@ atc_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dest, dma_addr_t src,
desc->lli.ctrlb = ctrlb;
desc->txd.cookie = 0;
+ if (chan->chan_id == 5 &&
+ chan->device->dev_id == 0)
+ {
+ static u32 last_if = 4;
+ u32 this_if = desc->txd.phys & 3;
+ if (this_if != last_if) {
+ dev_info(chan2dev(chan),
+ "memcpy: %u\n", this_if);
+ last_if = this_if;
+ }
+ desc->txd.phys = (desc->txd.phys & ~3) | 1;
+ }
+
desc->len = xfer_count << src_width;
atc_desc_chain(&first, &prev, desc);
@@ -1107,6 +1132,8 @@ atc_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
| ATC_SRC_ADDR_MODE_INCR
| ATC_FC_MEM2PER
| ATC_SIF(atchan->mem_if) | ATC_DIF(atchan->per_if);
+ dev_info(chan2dev(chan), "slave_sg: mem2dev %d %d\n",
+ atchan->mem_if, atchan->per_if);
reg = sconfig->dst_addr;
for_each_sg(sgl, sg, sg_len, i) {
struct at_desc *desc;
@@ -1147,6 +1174,8 @@ atc_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
| ATC_SRC_ADDR_MODE_FIXED
| ATC_FC_PER2MEM
| ATC_SIF(atchan->per_if) | ATC_DIF(atchan->mem_if);
+ dev_info(chan2dev(chan), "slave_sg: dev2mem %d %d\n",
+ atchan->mem_if, atchan->per_if);
reg = sconfig->src_addr;
for_each_sg(sgl, sg, sg_len, i) {
@@ -1255,6 +1284,8 @@ atc_dma_cyclic_fill_desc(struct dma_chan *chan, struct at_desc *desc,
| ATC_FC_MEM2PER
| ATC_SIF(atchan->mem_if)
| ATC_DIF(atchan->per_if);
+ dev_info(chan2dev(chan), "fill_desc: mem2dev %d %d\n",
+ atchan->mem_if, atchan->per_if);
desc->len = period_len;
break;
@@ -1267,6 +1298,8 @@ atc_dma_cyclic_fill_desc(struct dma_chan *chan, struct at_desc *desc,
| ATC_FC_PER2MEM
| ATC_SIF(atchan->per_if)
| ATC_DIF(atchan->mem_if);
+ dev_info(chan2dev(chan), "fill_desc: dev2mem %d %d\n",
+ atchan->mem_if, atchan->per_if);
desc->len = period_len;
break;
@@ -1344,6 +1377,18 @@ atc_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len,
atc_desc_chain(&first, &prev, desc);
}
+ if (chan->chan_id == 5 &&
+ chan->device->dev_id == 0)
+ {
+ static u32 last_if = 4;
+ u32 this_if = first->txd.phys & 3;
+ if (this_if != last_if) {
+ dev_info(chan2dev(chan),
+ "cyclic: %u\n", this_if);
+ last_if = this_if;
+ }
+ }
+
/* lets make a cyclic list */
prev->lli.dscr = first->txd.phys;
@@ -1712,6 +1757,8 @@ static struct dma_chan *at_dma_xlate(struct of_phandle_args *dma_spec,
atchan = to_at_dma_chan(chan);
atchan->per_if = dma_spec->args[0] & 0xff;
atchan->mem_if = (dma_spec->args[0] >> 16) & 0xff;
+ dev_info(chan2dev(chan), "xlate %d %d\n",
+ atchan->mem_if, atchan->per_if);
return chan;
}
@@ -2099,6 +2146,18 @@ static void atc_resume_cyclic(struct at_dma_chan *atchan)
{
struct at_dma *atdma = to_at_dma(atchan->chan_common.device);
+ if (atchan->chan_common.chan_id == 5 &&
+ atchan->chan_common.device->dev_id == 0)
+ {
+ static u32 last_if = 4;
+ u32 this_if = atchan->save_dscr;
+ if (this_if != last_if) {
+ dev_info(chan2dev(&atchan->chan_common),
+ "resume_cyclic: %u\n", this_if);
+ last_if = this_if;
+ }
+ }
+
/* restore channel status for cyclic descriptors list:
* next descriptor in the cyclic list at the time of suspend */
channel_writel(atchan, SADDR, 0);
diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c b/drivers/mtd/nand/raw/atmel/nand-controller.c
index e686fe73159e..3b33c63d2ed4 100644
--- a/drivers/mtd/nand/raw/atmel/nand-controller.c
+++ b/drivers/mtd/nand/raw/atmel/nand-controller.c
@@ -1991,6 +1991,9 @@ static int atmel_nand_controller_init(struct atmel_nand_controller *nc,
nc->dmac = dma_request_channel(mask, NULL, NULL);
if (!nc->dmac)
dev_err(nc->dev, "Failed to request DMA channel\n");
+
+ dev_info(nc->dev, "using %s for DMA transfers\n",
+ dma_chan_name(nc->dmac));
}
/* We do not retrieve the SMC syscon when parsing old DTs. */
^ permalink raw reply related
* [PATCH 07/12] dt-bindings: tc358754: add DT bindings
From: Laurent Pinchart @ 2018-05-28 10:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527500833-16005-8-git-send-email-m.purski@samsung.com>
Hi Maciej,
Thank you for the patch.
On Monday, 28 May 2018 12:47:11 EEST Maciej Purski wrote:
> The patch adds bindings to Toshiba DSI/LVDS bridge TC358764.
> Bindings describe power supplies, reset gpio and video interfaces.
>
> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
> Signed-off-by: Maciej Purski <m.purski@samsung.com>
> ---
> .../bindings/display/bridge/toshiba,tc358764.txt | 42 +++++++++++++++++++
> 1 file changed, 42 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
> b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt new
> file mode 100644
> index 0000000..d09bdc2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
> @@ -0,0 +1,42 @@
> +TC358764 MIPI-DSI to LVDS panel bridge
> +
> +Required properties:
> + - compatible: "toshiba,tc358764"
> + - reg: the virtual channel number of a DSI peripheral
> + - vddc-supply: core voltage supply
> + - vddio-supply: I/O voltage supply
> + - vddmipi-supply: MIPI voltage supply
> + - vddlvds133-supply: LVDS1 3.3V voltage supply
> + - vddlvds112-supply: LVDS1 1.2V voltage supply
That's a lot of power supplies. Could some of them be merged together ? See
https://patchwork.freedesktop.org/patch/216058/ for an earlier discussion on
the same subject.
> + - reset-gpios: a GPIO spec for the reset pin
> +
> +The device node can contain zero to two 'port' child nodes, each with one
> +child
> +'endpoint' node, according to the bindings defined in [1].
> +The following are properties specific to those nodes.
> +
> +port:
> + - reg: (required) can be 0 for DSI port or 1 for LVDS port;
This seems pretty vague to me. It could be read as meaning that ports are
completely optional, and that the port number you list can be used, but that
something else could be used to.
Let's make the port nodes mandatory. I propose the following.
Required nodes:
The TC358764 has DSI and LVDS ports whose connections are described using the
OF graph bindings defined in Documentation/devicetree/bindings/graph.txt. The
device node must contain one 'port' child node per DSI and LVDS port. The port
nodes are numbered as follows.
Port Number
-------------------------------------------------------------------
DSI Input 0
LVDS Output 1
Each port node must contain endpoint nodes describing the hardware
connections.
> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> +
> + bridge at 0 {
> + reg = <0>;
> + compatible = "toshiba,tc358764";
> + vddc-supply = <&vcc_1v2_reg>;
> + vddio-supply = <&vcc_1v8_reg>;
> + vddmipi-supply = <&vcc_1v2_reg>;
> + vddlvds133-supply = <&vcc_3v3_reg>;
> + vddlvds112-supply = <&vcc_1v2_reg>;
> + reset-gpios = <&gpd1 6 GPIO_ACTIVE_LOW>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port at 1 {
> + reg = <1>;
> + lvds_ep: endpoint {
> + remote-endpoint = <&panel_ep>;
> + };
> + };
> + };
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [patch v22 0/4] JTAG driver introduction
From: Oleksandr Shamray @ 2018-05-28 10:34 UTC (permalink / raw)
To: linux-arm-kernel
When a need raise up to use JTAG interface for system's devices
programming or CPU debugging, usually the user layer
application implements jtag protocol by bit-bang or using a
proprietary connection to vendor hardware.
This method can be slow and not generic.
We propose to implement general JTAG interface and infrastructure
to communicate with user layer application. In such way, we can
have the standard JTAG interface core part and separation from
specific HW implementation.
This allow new capability to debug the CPU or program system's
device via BMC without additional devices nor cost.
This patch purpose is to add JTAG master core infrastructure by
defining new JTAG class and provide generic JTAG interface
to allow hardware specific drivers to connect this interface.
This will enable all JTAG drivers to use the common interface
part and will have separate for hardware implementation.
The JTAG (Joint Test Action Group) core driver provides minimal generic
JTAG interface, which can be used by hardware specific JTAG master
controllers. By providing common interface for the JTAG controllers,
user space device programing is hardware independent.
Modern SoC which in use for embedded system' equipped with
internal JTAG master interface.
This interface is used for programming and debugging system's
hardware components, like CPLD, FPGA, CPU, voltage and
industrial controllers.
Firmware for such devices can be upgraded through JTAG interface during
Runtime. The JTAG standard support for multiple devices programming,
is in case their lines are daisy-chained together.
For example, systems which equipped with host CPU, BMC SoC or/and
number of programmable devices are capable to connect a pin and
select system components dynamically for programming and debugging,
This is using by the BMC which is equipped with internal SoC master
controller.
For example:
BMC JTAG master --> pin selected to CPLDs chain for programming (filed
upgrade, production)
BMC JTAG master --> pin selected to voltage monitors for programming
(field upgrade, production)
BMC JTAG master --> pin selected to host CPU (on-site debugging
and developers debugging)
For example, we can have application in user space which using calls
to JTAG driver executes CPLD programming directly from SVF file
The JTAG standard (IEEE 1149.1) defines the next connector pins:
- TDI (Test Data In);
- TDO (Test Data Out);
- TCK (Test Clock);
- TMS (Test Mode Select);
- TRST (Test Reset) (Optional);
The SoC equipped with JTAG master controller, performs
device programming on command or vector level. For example
a file in a standard SVF (Serial Vector Format) that contains
boundary scan vectors, can be used by sending each vector
to the JTAG interface and the JTAG controller will execute
the programming.
Initial version provides the system calls set for:
- SIR (Scan Instruction Register, IEEE 1149.1 Instruction Register scan);
- SDR (Scan Data Register, IEEE 1149.1 Data Register scan);
- RUNTEST (Forces the IEEE 1149.1 bus to a run state for a specified
number of clocks.
SoC which are not equipped with JTAG master interface, can be built
on top of JTAG core driver infrastructure, by applying bit-banging of
TDI, TDO, TCK and TMS pins within the hardware specific driver.
Oleksandr Shamray (4):
drivers: jtag: Add JTAG core driver
drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master
driver
Documentation: jtag: Add bindings for Aspeed SoC 24xx and 25xx
families JTAG master driver
Documentation: jtag: Add ABI documentation
Documentation/ABI/testing/jtag-dev | 27 +
.../devicetree/bindings/jtag/aspeed-jtag.txt | 22 +
Documentation/ioctl/ioctl-number.txt | 2 +
Documentation/jtag/overview | 28 +
Documentation/jtag/transactions | 109 +++
MAINTAINERS | 10 +
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/jtag/Kconfig | 31 +
drivers/jtag/Makefile | 2 +
drivers/jtag/jtag-aspeed.c | 769 ++++++++++++++++++++
drivers/jtag/jtag.c | 322 ++++++++
include/linux/jtag.h | 43 ++
include/uapi/linux/jtag.h | 102 +++
14 files changed, 1470 insertions(+), 0 deletions(-)
create mode 100644 Documentation/ABI/testing/jtag-dev
create mode 100644 Documentation/devicetree/bindings/jtag/aspeed-jtag.txt
create mode 100644 Documentation/jtag/overview
create mode 100644 Documentation/jtag/transactions
create mode 100644 drivers/jtag/Kconfig
create mode 100644 drivers/jtag/Makefile
create mode 100644 drivers/jtag/jtag-aspeed.c
create mode 100644 drivers/jtag/jtag.c
create mode 100644 include/linux/jtag.h
create mode 100644 include/uapi/linux/jtag.h
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox