From: Tomasz Figa <tomasz.figa@gmail.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH 1/5] phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs
Date: Sun, 16 Jun 2013 21:11:48 +0000 [thread overview]
Message-ID: <3575249.Vg82ll65tN@flatron> (raw)
In-Reply-To: <1371231951-1969-2-git-send-email-s.nawrocki@samsung.com>
Hi Sylwester,
Looks good, but I added some nitpicks inline.
On Friday 14 of June 2013 19:45:47 Sylwester Nawrocki wrote:
> Add a PHY provider driver for the Samsung S5P/Exynos SoC MIPI CSI-2
> receiver and MIPI DSI transmitter DPHYs.
>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
> .../bindings/phy/exynos-video-mipi-phy.txt | 16 ++
> drivers/phy/Kconfig | 10 ++
> drivers/phy/Makefile | 3 +-
> drivers/phy/exynos_video_mipi_phy.c | 166
> ++++++++++++++++++++ 4 files changed, 194 insertions(+), 1 deletion(-)
> create mode 100644
> Documentation/devicetree/bindings/phy/exynos-video-mipi-phy.txt create
> mode 100644 drivers/phy/exynos_video_mipi_phy.c
>
> diff --git
> a/Documentation/devicetree/bindings/phy/exynos-video-mipi-phy.txt
> b/Documentation/devicetree/bindings/phy/exynos-video-mipi-phy.txt new
> file mode 100644
> index 0000000..32311c89
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/exynos-video-mipi-phy.txt
> @@ -0,0 +1,16 @@
> +Samsung S5P/EXYNOS SoC series MIPI CSIS/DSIM DPHY
> +-------------------------------------------------
> +
> +Required properties:
> +- compatible : "samsung,<soc_name>-video-phy", currently most SoCs can
I don't like this <soc_name> here. It sounds like any SoC name can be put
here. IMHO just listing all supported compatible values should be enough.
> claim + compatibility with the S5PV210 MIPI CSIS/DSIM PHY and thus
> should use + "samsung,s5pv210-video-phy";
> +- reg : offset and length of the MIPI DPHY register set;
> +- #phy-cells : from the generic phy bindings, must be 1;
> +
> +For "samsung,s5pv210-video-phy" compatible DPHYs the second cell in the
> PHY +specifier identifies the DPHY and its meaning is as follows:
> + 0 - MIPI CSIS 0,
> + 1 - MIPI DSIM 0,
> + 2 - MIPI CSIS 1,
> + 3 - MIPI DSIM 1.
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 0764a54..d234e99 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -11,3 +11,13 @@ menuconfig GENERIC_PHY
> devices present in the kernel. This layer will have the generic
> API by which phy drivers can create PHY using the phy framework
and
> phy users can obtain reference to the PHY.
> +
> +if GENERIC_PHY
> +
> +config EXYNOS_VIDEO_MIPI_PHY
> + bool "S5P/EXYNOS MIPI CSI-2/DSI PHY driver"
> + depends on OF
Hmm. Is this driver designed only for OF-enabled boards?
> + help
> + Support for MIPI CSI-2 and MIPI DSI DPHY found on Samsung
> + S5P and EXYNOS SoCs.
> +endif
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 9e9560f..b16f2c1 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -2,4 +2,5 @@
> # Makefile for the phy drivers.
> #
>
> -obj-$(CONFIG_GENERIC_PHY) += phy-core.o
> +obj-$(CONFIG_GENERIC_PHY) += phy-core.o
> +obj-$(CONFIG_EXYNOS_VIDEO_MIPI_PHY) += exynos_video_mipi_phy.o
> diff --git a/drivers/phy/exynos_video_mipi_phy.c
> b/drivers/phy/exynos_video_mipi_phy.c new file mode 100644
> index 0000000..8d4976f
> --- /dev/null
> +++ b/drivers/phy/exynos_video_mipi_phy.c
> @@ -0,0 +1,166 @@
> +/*
> + * Samsung S5P/EXYNOS SoC series MIPI CSIS/DSIM DPHY driver
> + *
> + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
> + * Author: Sylwester Nawrocki <s.nawrocki@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.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/phy/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/spinlock.h>
> +
> +/* MIPI_PHYn_CONTROL register bit definitions */
> +#define EXYNOS_MIPI_PHY_ENABLE (1 << 0)
> +#define EXYNOS_MIPI_PHY_SRESETN (1 << 1)
> +#define EXYNOS_MIPI_PHY_MRESETN (1 << 2)
> +#define EXYNOS_MIPI_PHY_RESET_MASK (3 << 1)
> +
> +#define EXYNOS_MAX_VIDEO_PHYS 4
> +
> +struct exynos_video_phy {
> + spinlock_t slock;
> + struct phy *phys[EXYNOS_MAX_VIDEO_PHYS];
> + void __iomem *regs;
> +};
> +
> +/*
> + * The @id argument specifies MIPI CSIS or DSIM PHY as follows:
> + * 0 - MIPI CSIS 0
> + * 1 - MIPI DSIM 0
> + * 2 - MIPI CSIS 1
> + * 3 - MIPI DSIM 1
> + */
> +static int set_phy_state(struct exynos_video_phy *state,
> + unsigned int id, int on)
> +{
> + void __iomem *addr = id < 2 ? state->regs : state->regs + 4;
I don't find this statement too readable. What about:
void __iomem *addr = state->regs;
and below:
/* CSIS 1 and DSIM 1 PHYs have separate register */
if (id >= 2)
addr += 4;
> + unsigned long flags;
> + u32 reg, reset;
> +
> + pr_debug("%s(): id: %d, on: %d, addr: %#x, base: %#x\n",
> + __func__, id, on, (u32)addr, (u32)state->regs);
> +
> + if (WARN_ON(id > EXYNOS_MAX_VIDEO_PHYS))
> + return -EINVAL;
> +
> + if (id & 1)
Nice trick ;), but not very readable. What about creating an enum of PHYs
and using those defined values here:
if (id = PHY_DSI0 || id = PHY_DSI1)
> + reset = EXYNOS_MIPI_PHY_MRESETN;
> + else
> + reset = EXYNOS_MIPI_PHY_SRESETN;
> +
> + spin_lock_irqsave(&state->slock, flags);
> +
> + reg = readl(addr);
> + if (on)
> + reg |= reset;
> + else
> + reg &= ~reset;
> + writel(reg, addr);
> +
> + if (on)
> + reg |= EXYNOS_MIPI_PHY_ENABLE;
I believe this is a kind of reference counting, but a comment here would
be nice.
> + else if (!(reg & EXYNOS_MIPI_PHY_RESET_MASK))
> + reg &= ~EXYNOS_MIPI_PHY_ENABLE;
> +
> + writel(reg, addr);
> +
> + spin_unlock_irqrestore(&state->slock, flags);
> + return 0;
> +}
> +
> +static int exynos_video_phy_power_on(struct phy *phy)
> +{
> + struct exynos_video_phy *state = dev_get_drvdata(&phy->dev);
> + return set_phy_state(state, phy->id, 1);
> +}
> +
> +static int exynos_video_phy_power_off(struct phy *phy)
> +{
> + struct exynos_video_phy *state = dev_get_drvdata(&phy->dev);
> + return set_phy_state(state, phy->id, 0);
> +}
> +
> +static struct phy *exynos_video_phy_xlate(struct device *dev,
> + struct of_phandle_args *args)
> +{
> + struct exynos_video_phy *state = dev_get_drvdata(dev);
> +
> + if (WARN_ON(args->args[0] > EXYNOS_MAX_VIDEO_PHYS))
> + return NULL;
> +
> + return state->phys[args->args[0]];
> +}
> +
> +static struct phy_ops exynos_video_phy_ops = {
> + .power_on = exynos_video_phy_power_on,
> + .power_off = exynos_video_phy_power_off,
> + .owner = THIS_MODULE,
> +};
> +
> +static int exynos_video_phy_probe(struct platform_device *pdev)
> +{
> + struct exynos_video_phy *state;
> + struct device *dev = &pdev->dev;
> + struct resource res;
> + struct phy_provider *phy_provider;
> + int ret, i;
> +
> + state = devm_kzalloc(dev, sizeof(*state), GFP_KERNEL);
> + if (!state)
> + return -ENOMEM;
> +
> + ret = of_address_to_resource(dev->of_node, 0, &res);
> + if (ret < 0)
> + return ret;
You can use platform_get_resource() here to get a resource generated for
you by of_platform_populate().
In addition you don't need to check the pointer returned by
platform_get_resource() because it is checked in devm_ioremap_resource().
> +
> + state->regs = devm_ioremap_resource(dev, &res);
> + if (IS_ERR(state->regs))
> + return PTR_ERR(state->regs);
> +
> + dev_set_drvdata(dev, state);
> +
> + phy_provider = devm_of_phy_provider_register(dev, THIS_MODULE,
> + exynos_video_phy_xlate);
> + if (IS_ERR(phy_provider))
> + return PTR_ERR(phy_provider);
> +
> + for (i = 0; i < EXYNOS_MAX_VIDEO_PHYS; i++) {
> + state->phys[i] = devm_phy_create(dev, i,
&exynos_video_phy_ops,
> +
state);
> + if (IS_ERR(state->phys[i])) {
> + dev_err(dev, "failed to create PHY %d\n", i);
> + return PTR_ERR(state->phys[i]);
> + }
> + }
> +
> + return 0;
> +}
> +
> +static const struct of_device_id exynos_video_phy_of_match[] = {
> + { .compatible = "samsung,s5pv210-video-phy" },
> + { },
> +};
IMHO a MODULE_DEVICE_TABLE should be added here.
Best regards,
Tomasz
> +
> +static struct platform_driver exynos_video_phy_driver = {
> + .probe = exynos_video_phy_probe,
> + .driver = {
> + .of_match_table = exynos_video_phy_of_match,
> + .name = "exynos-video-phy",
> + .owner = THIS_MODULE,
> + }
> +};
> +module_platform_driver(exynos_video_phy_driver);
> +
> +MODULE_DESCRIPTION("Samsung S5P/EXYNOS SoC MIPI CSI-2/DSI DPHY
> driver"); +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Sylwester Nawrocki <s.nawrocki@samsung.com>");
WARNING: multiple messages have this Message-ID (diff)
From: Tomasz Figa <tomasz.figa@gmail.com>
To: Sylwester Nawrocki <s.nawrocki@samsung.com>
Cc: kishon@ti.com, linux-arm-kernel@lists.infradead.org,
linux-media@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
kyungmin.park@samsung.com, sw0312.kim@samsung.com,
devicetree-discuss@lists.ozlabs.org, kgene.kim@samsung.com,
dh09.lee@samsung.com, jg1.han@samsung.com,
linux-fbdev@vger.kernel.org
Subject: Re: [RFC PATCH 1/5] phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs
Date: Sun, 16 Jun 2013 23:11:48 +0200 [thread overview]
Message-ID: <3575249.Vg82ll65tN@flatron> (raw)
In-Reply-To: <1371231951-1969-2-git-send-email-s.nawrocki@samsung.com>
Hi Sylwester,
Looks good, but I added some nitpicks inline.
On Friday 14 of June 2013 19:45:47 Sylwester Nawrocki wrote:
> Add a PHY provider driver for the Samsung S5P/Exynos SoC MIPI CSI-2
> receiver and MIPI DSI transmitter DPHYs.
>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
> .../bindings/phy/exynos-video-mipi-phy.txt | 16 ++
> drivers/phy/Kconfig | 10 ++
> drivers/phy/Makefile | 3 +-
> drivers/phy/exynos_video_mipi_phy.c | 166
> ++++++++++++++++++++ 4 files changed, 194 insertions(+), 1 deletion(-)
> create mode 100644
> Documentation/devicetree/bindings/phy/exynos-video-mipi-phy.txt create
> mode 100644 drivers/phy/exynos_video_mipi_phy.c
>
> diff --git
> a/Documentation/devicetree/bindings/phy/exynos-video-mipi-phy.txt
> b/Documentation/devicetree/bindings/phy/exynos-video-mipi-phy.txt new
> file mode 100644
> index 0000000..32311c89
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/exynos-video-mipi-phy.txt
> @@ -0,0 +1,16 @@
> +Samsung S5P/EXYNOS SoC series MIPI CSIS/DSIM DPHY
> +-------------------------------------------------
> +
> +Required properties:
> +- compatible : "samsung,<soc_name>-video-phy", currently most SoCs can
I don't like this <soc_name> here. It sounds like any SoC name can be put
here. IMHO just listing all supported compatible values should be enough.
> claim + compatibility with the S5PV210 MIPI CSIS/DSIM PHY and thus
> should use + "samsung,s5pv210-video-phy";
> +- reg : offset and length of the MIPI DPHY register set;
> +- #phy-cells : from the generic phy bindings, must be 1;
> +
> +For "samsung,s5pv210-video-phy" compatible DPHYs the second cell in the
> PHY +specifier identifies the DPHY and its meaning is as follows:
> + 0 - MIPI CSIS 0,
> + 1 - MIPI DSIM 0,
> + 2 - MIPI CSIS 1,
> + 3 - MIPI DSIM 1.
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 0764a54..d234e99 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -11,3 +11,13 @@ menuconfig GENERIC_PHY
> devices present in the kernel. This layer will have the generic
> API by which phy drivers can create PHY using the phy framework
and
> phy users can obtain reference to the PHY.
> +
> +if GENERIC_PHY
> +
> +config EXYNOS_VIDEO_MIPI_PHY
> + bool "S5P/EXYNOS MIPI CSI-2/DSI PHY driver"
> + depends on OF
Hmm. Is this driver designed only for OF-enabled boards?
> + help
> + Support for MIPI CSI-2 and MIPI DSI DPHY found on Samsung
> + S5P and EXYNOS SoCs.
> +endif
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 9e9560f..b16f2c1 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -2,4 +2,5 @@
> # Makefile for the phy drivers.
> #
>
> -obj-$(CONFIG_GENERIC_PHY) += phy-core.o
> +obj-$(CONFIG_GENERIC_PHY) += phy-core.o
> +obj-$(CONFIG_EXYNOS_VIDEO_MIPI_PHY) += exynos_video_mipi_phy.o
> diff --git a/drivers/phy/exynos_video_mipi_phy.c
> b/drivers/phy/exynos_video_mipi_phy.c new file mode 100644
> index 0000000..8d4976f
> --- /dev/null
> +++ b/drivers/phy/exynos_video_mipi_phy.c
> @@ -0,0 +1,166 @@
> +/*
> + * Samsung S5P/EXYNOS SoC series MIPI CSIS/DSIM DPHY driver
> + *
> + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
> + * Author: Sylwester Nawrocki <s.nawrocki@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.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/phy/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/spinlock.h>
> +
> +/* MIPI_PHYn_CONTROL register bit definitions */
> +#define EXYNOS_MIPI_PHY_ENABLE (1 << 0)
> +#define EXYNOS_MIPI_PHY_SRESETN (1 << 1)
> +#define EXYNOS_MIPI_PHY_MRESETN (1 << 2)
> +#define EXYNOS_MIPI_PHY_RESET_MASK (3 << 1)
> +
> +#define EXYNOS_MAX_VIDEO_PHYS 4
> +
> +struct exynos_video_phy {
> + spinlock_t slock;
> + struct phy *phys[EXYNOS_MAX_VIDEO_PHYS];
> + void __iomem *regs;
> +};
> +
> +/*
> + * The @id argument specifies MIPI CSIS or DSIM PHY as follows:
> + * 0 - MIPI CSIS 0
> + * 1 - MIPI DSIM 0
> + * 2 - MIPI CSIS 1
> + * 3 - MIPI DSIM 1
> + */
> +static int set_phy_state(struct exynos_video_phy *state,
> + unsigned int id, int on)
> +{
> + void __iomem *addr = id < 2 ? state->regs : state->regs + 4;
I don't find this statement too readable. What about:
void __iomem *addr = state->regs;
and below:
/* CSIS 1 and DSIM 1 PHYs have separate register */
if (id >= 2)
addr += 4;
> + unsigned long flags;
> + u32 reg, reset;
> +
> + pr_debug("%s(): id: %d, on: %d, addr: %#x, base: %#x\n",
> + __func__, id, on, (u32)addr, (u32)state->regs);
> +
> + if (WARN_ON(id > EXYNOS_MAX_VIDEO_PHYS))
> + return -EINVAL;
> +
> + if (id & 1)
Nice trick ;), but not very readable. What about creating an enum of PHYs
and using those defined values here:
if (id == PHY_DSI0 || id == PHY_DSI1)
> + reset = EXYNOS_MIPI_PHY_MRESETN;
> + else
> + reset = EXYNOS_MIPI_PHY_SRESETN;
> +
> + spin_lock_irqsave(&state->slock, flags);
> +
> + reg = readl(addr);
> + if (on)
> + reg |= reset;
> + else
> + reg &= ~reset;
> + writel(reg, addr);
> +
> + if (on)
> + reg |= EXYNOS_MIPI_PHY_ENABLE;
I believe this is a kind of reference counting, but a comment here would
be nice.
> + else if (!(reg & EXYNOS_MIPI_PHY_RESET_MASK))
> + reg &= ~EXYNOS_MIPI_PHY_ENABLE;
> +
> + writel(reg, addr);
> +
> + spin_unlock_irqrestore(&state->slock, flags);
> + return 0;
> +}
> +
> +static int exynos_video_phy_power_on(struct phy *phy)
> +{
> + struct exynos_video_phy *state = dev_get_drvdata(&phy->dev);
> + return set_phy_state(state, phy->id, 1);
> +}
> +
> +static int exynos_video_phy_power_off(struct phy *phy)
> +{
> + struct exynos_video_phy *state = dev_get_drvdata(&phy->dev);
> + return set_phy_state(state, phy->id, 0);
> +}
> +
> +static struct phy *exynos_video_phy_xlate(struct device *dev,
> + struct of_phandle_args *args)
> +{
> + struct exynos_video_phy *state = dev_get_drvdata(dev);
> +
> + if (WARN_ON(args->args[0] > EXYNOS_MAX_VIDEO_PHYS))
> + return NULL;
> +
> + return state->phys[args->args[0]];
> +}
> +
> +static struct phy_ops exynos_video_phy_ops = {
> + .power_on = exynos_video_phy_power_on,
> + .power_off = exynos_video_phy_power_off,
> + .owner = THIS_MODULE,
> +};
> +
> +static int exynos_video_phy_probe(struct platform_device *pdev)
> +{
> + struct exynos_video_phy *state;
> + struct device *dev = &pdev->dev;
> + struct resource res;
> + struct phy_provider *phy_provider;
> + int ret, i;
> +
> + state = devm_kzalloc(dev, sizeof(*state), GFP_KERNEL);
> + if (!state)
> + return -ENOMEM;
> +
> + ret = of_address_to_resource(dev->of_node, 0, &res);
> + if (ret < 0)
> + return ret;
You can use platform_get_resource() here to get a resource generated for
you by of_platform_populate().
In addition you don't need to check the pointer returned by
platform_get_resource() because it is checked in devm_ioremap_resource().
> +
> + state->regs = devm_ioremap_resource(dev, &res);
> + if (IS_ERR(state->regs))
> + return PTR_ERR(state->regs);
> +
> + dev_set_drvdata(dev, state);
> +
> + phy_provider = devm_of_phy_provider_register(dev, THIS_MODULE,
> + exynos_video_phy_xlate);
> + if (IS_ERR(phy_provider))
> + return PTR_ERR(phy_provider);
> +
> + for (i = 0; i < EXYNOS_MAX_VIDEO_PHYS; i++) {
> + state->phys[i] = devm_phy_create(dev, i,
&exynos_video_phy_ops,
> +
state);
> + if (IS_ERR(state->phys[i])) {
> + dev_err(dev, "failed to create PHY %d\n", i);
> + return PTR_ERR(state->phys[i]);
> + }
> + }
> +
> + return 0;
> +}
> +
> +static const struct of_device_id exynos_video_phy_of_match[] = {
> + { .compatible = "samsung,s5pv210-video-phy" },
> + { },
> +};
IMHO a MODULE_DEVICE_TABLE should be added here.
Best regards,
Tomasz
> +
> +static struct platform_driver exynos_video_phy_driver = {
> + .probe = exynos_video_phy_probe,
> + .driver = {
> + .of_match_table = exynos_video_phy_of_match,
> + .name = "exynos-video-phy",
> + .owner = THIS_MODULE,
> + }
> +};
> +module_platform_driver(exynos_video_phy_driver);
> +
> +MODULE_DESCRIPTION("Samsung S5P/EXYNOS SoC MIPI CSI-2/DSI DPHY
> driver"); +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Sylwester Nawrocki <s.nawrocki@samsung.com>");
WARNING: multiple messages have this Message-ID (diff)
From: tomasz.figa@gmail.com (Tomasz Figa)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 1/5] phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs
Date: Sun, 16 Jun 2013 23:11:48 +0200 [thread overview]
Message-ID: <3575249.Vg82ll65tN@flatron> (raw)
In-Reply-To: <1371231951-1969-2-git-send-email-s.nawrocki@samsung.com>
Hi Sylwester,
Looks good, but I added some nitpicks inline.
On Friday 14 of June 2013 19:45:47 Sylwester Nawrocki wrote:
> Add a PHY provider driver for the Samsung S5P/Exynos SoC MIPI CSI-2
> receiver and MIPI DSI transmitter DPHYs.
>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
> .../bindings/phy/exynos-video-mipi-phy.txt | 16 ++
> drivers/phy/Kconfig | 10 ++
> drivers/phy/Makefile | 3 +-
> drivers/phy/exynos_video_mipi_phy.c | 166
> ++++++++++++++++++++ 4 files changed, 194 insertions(+), 1 deletion(-)
> create mode 100644
> Documentation/devicetree/bindings/phy/exynos-video-mipi-phy.txt create
> mode 100644 drivers/phy/exynos_video_mipi_phy.c
>
> diff --git
> a/Documentation/devicetree/bindings/phy/exynos-video-mipi-phy.txt
> b/Documentation/devicetree/bindings/phy/exynos-video-mipi-phy.txt new
> file mode 100644
> index 0000000..32311c89
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/exynos-video-mipi-phy.txt
> @@ -0,0 +1,16 @@
> +Samsung S5P/EXYNOS SoC series MIPI CSIS/DSIM DPHY
> +-------------------------------------------------
> +
> +Required properties:
> +- compatible : "samsung,<soc_name>-video-phy", currently most SoCs can
I don't like this <soc_name> here. It sounds like any SoC name can be put
here. IMHO just listing all supported compatible values should be enough.
> claim + compatibility with the S5PV210 MIPI CSIS/DSIM PHY and thus
> should use + "samsung,s5pv210-video-phy";
> +- reg : offset and length of the MIPI DPHY register set;
> +- #phy-cells : from the generic phy bindings, must be 1;
> +
> +For "samsung,s5pv210-video-phy" compatible DPHYs the second cell in the
> PHY +specifier identifies the DPHY and its meaning is as follows:
> + 0 - MIPI CSIS 0,
> + 1 - MIPI DSIM 0,
> + 2 - MIPI CSIS 1,
> + 3 - MIPI DSIM 1.
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 0764a54..d234e99 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -11,3 +11,13 @@ menuconfig GENERIC_PHY
> devices present in the kernel. This layer will have the generic
> API by which phy drivers can create PHY using the phy framework
and
> phy users can obtain reference to the PHY.
> +
> +if GENERIC_PHY
> +
> +config EXYNOS_VIDEO_MIPI_PHY
> + bool "S5P/EXYNOS MIPI CSI-2/DSI PHY driver"
> + depends on OF
Hmm. Is this driver designed only for OF-enabled boards?
> + help
> + Support for MIPI CSI-2 and MIPI DSI DPHY found on Samsung
> + S5P and EXYNOS SoCs.
> +endif
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 9e9560f..b16f2c1 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -2,4 +2,5 @@
> # Makefile for the phy drivers.
> #
>
> -obj-$(CONFIG_GENERIC_PHY) += phy-core.o
> +obj-$(CONFIG_GENERIC_PHY) += phy-core.o
> +obj-$(CONFIG_EXYNOS_VIDEO_MIPI_PHY) += exynos_video_mipi_phy.o
> diff --git a/drivers/phy/exynos_video_mipi_phy.c
> b/drivers/phy/exynos_video_mipi_phy.c new file mode 100644
> index 0000000..8d4976f
> --- /dev/null
> +++ b/drivers/phy/exynos_video_mipi_phy.c
> @@ -0,0 +1,166 @@
> +/*
> + * Samsung S5P/EXYNOS SoC series MIPI CSIS/DSIM DPHY driver
> + *
> + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
> + * Author: Sylwester Nawrocki <s.nawrocki@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.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/phy/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/spinlock.h>
> +
> +/* MIPI_PHYn_CONTROL register bit definitions */
> +#define EXYNOS_MIPI_PHY_ENABLE (1 << 0)
> +#define EXYNOS_MIPI_PHY_SRESETN (1 << 1)
> +#define EXYNOS_MIPI_PHY_MRESETN (1 << 2)
> +#define EXYNOS_MIPI_PHY_RESET_MASK (3 << 1)
> +
> +#define EXYNOS_MAX_VIDEO_PHYS 4
> +
> +struct exynos_video_phy {
> + spinlock_t slock;
> + struct phy *phys[EXYNOS_MAX_VIDEO_PHYS];
> + void __iomem *regs;
> +};
> +
> +/*
> + * The @id argument specifies MIPI CSIS or DSIM PHY as follows:
> + * 0 - MIPI CSIS 0
> + * 1 - MIPI DSIM 0
> + * 2 - MIPI CSIS 1
> + * 3 - MIPI DSIM 1
> + */
> +static int set_phy_state(struct exynos_video_phy *state,
> + unsigned int id, int on)
> +{
> + void __iomem *addr = id < 2 ? state->regs : state->regs + 4;
I don't find this statement too readable. What about:
void __iomem *addr = state->regs;
and below:
/* CSIS 1 and DSIM 1 PHYs have separate register */
if (id >= 2)
addr += 4;
> + unsigned long flags;
> + u32 reg, reset;
> +
> + pr_debug("%s(): id: %d, on: %d, addr: %#x, base: %#x\n",
> + __func__, id, on, (u32)addr, (u32)state->regs);
> +
> + if (WARN_ON(id > EXYNOS_MAX_VIDEO_PHYS))
> + return -EINVAL;
> +
> + if (id & 1)
Nice trick ;), but not very readable. What about creating an enum of PHYs
and using those defined values here:
if (id == PHY_DSI0 || id == PHY_DSI1)
> + reset = EXYNOS_MIPI_PHY_MRESETN;
> + else
> + reset = EXYNOS_MIPI_PHY_SRESETN;
> +
> + spin_lock_irqsave(&state->slock, flags);
> +
> + reg = readl(addr);
> + if (on)
> + reg |= reset;
> + else
> + reg &= ~reset;
> + writel(reg, addr);
> +
> + if (on)
> + reg |= EXYNOS_MIPI_PHY_ENABLE;
I believe this is a kind of reference counting, but a comment here would
be nice.
> + else if (!(reg & EXYNOS_MIPI_PHY_RESET_MASK))
> + reg &= ~EXYNOS_MIPI_PHY_ENABLE;
> +
> + writel(reg, addr);
> +
> + spin_unlock_irqrestore(&state->slock, flags);
> + return 0;
> +}
> +
> +static int exynos_video_phy_power_on(struct phy *phy)
> +{
> + struct exynos_video_phy *state = dev_get_drvdata(&phy->dev);
> + return set_phy_state(state, phy->id, 1);
> +}
> +
> +static int exynos_video_phy_power_off(struct phy *phy)
> +{
> + struct exynos_video_phy *state = dev_get_drvdata(&phy->dev);
> + return set_phy_state(state, phy->id, 0);
> +}
> +
> +static struct phy *exynos_video_phy_xlate(struct device *dev,
> + struct of_phandle_args *args)
> +{
> + struct exynos_video_phy *state = dev_get_drvdata(dev);
> +
> + if (WARN_ON(args->args[0] > EXYNOS_MAX_VIDEO_PHYS))
> + return NULL;
> +
> + return state->phys[args->args[0]];
> +}
> +
> +static struct phy_ops exynos_video_phy_ops = {
> + .power_on = exynos_video_phy_power_on,
> + .power_off = exynos_video_phy_power_off,
> + .owner = THIS_MODULE,
> +};
> +
> +static int exynos_video_phy_probe(struct platform_device *pdev)
> +{
> + struct exynos_video_phy *state;
> + struct device *dev = &pdev->dev;
> + struct resource res;
> + struct phy_provider *phy_provider;
> + int ret, i;
> +
> + state = devm_kzalloc(dev, sizeof(*state), GFP_KERNEL);
> + if (!state)
> + return -ENOMEM;
> +
> + ret = of_address_to_resource(dev->of_node, 0, &res);
> + if (ret < 0)
> + return ret;
You can use platform_get_resource() here to get a resource generated for
you by of_platform_populate().
In addition you don't need to check the pointer returned by
platform_get_resource() because it is checked in devm_ioremap_resource().
> +
> + state->regs = devm_ioremap_resource(dev, &res);
> + if (IS_ERR(state->regs))
> + return PTR_ERR(state->regs);
> +
> + dev_set_drvdata(dev, state);
> +
> + phy_provider = devm_of_phy_provider_register(dev, THIS_MODULE,
> + exynos_video_phy_xlate);
> + if (IS_ERR(phy_provider))
> + return PTR_ERR(phy_provider);
> +
> + for (i = 0; i < EXYNOS_MAX_VIDEO_PHYS; i++) {
> + state->phys[i] = devm_phy_create(dev, i,
&exynos_video_phy_ops,
> +
state);
> + if (IS_ERR(state->phys[i])) {
> + dev_err(dev, "failed to create PHY %d\n", i);
> + return PTR_ERR(state->phys[i]);
> + }
> + }
> +
> + return 0;
> +}
> +
> +static const struct of_device_id exynos_video_phy_of_match[] = {
> + { .compatible = "samsung,s5pv210-video-phy" },
> + { },
> +};
IMHO a MODULE_DEVICE_TABLE should be added here.
Best regards,
Tomasz
> +
> +static struct platform_driver exynos_video_phy_driver = {
> + .probe = exynos_video_phy_probe,
> + .driver = {
> + .of_match_table = exynos_video_phy_of_match,
> + .name = "exynos-video-phy",
> + .owner = THIS_MODULE,
> + }
> +};
> +module_platform_driver(exynos_video_phy_driver);
> +
> +MODULE_DESCRIPTION("Samsung S5P/EXYNOS SoC MIPI CSI-2/DSI DPHY
> driver"); +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Sylwester Nawrocki <s.nawrocki@samsung.com>");
next prev parent reply other threads:[~2013-06-16 21:11 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-14 17:45 [RFC PATCH 0/5] Generic PHY driver for Exynos SoCs MIPI CSI-2/DSIM DPHYs Sylwester Nawrocki
2013-06-14 17:45 ` Sylwester Nawrocki
2013-06-14 17:45 ` Sylwester Nawrocki
2013-06-14 17:45 ` [RFC PATCH 1/5] phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs Sylwester Nawrocki
2013-06-14 17:45 ` Sylwester Nawrocki
2013-06-14 17:45 ` Sylwester Nawrocki
2013-06-16 21:11 ` Tomasz Figa [this message]
2013-06-16 21:11 ` Tomasz Figa
2013-06-16 21:11 ` Tomasz Figa
2013-06-19 16:32 ` Sylwester Nawrocki
2013-06-19 16:32 ` Sylwester Nawrocki
2013-06-19 16:32 ` Sylwester Nawrocki
2013-06-14 17:45 ` [RFC PATCH 2/5] ARM: dts: Add MIPI PHY node to exynos4.dtsi Sylwester Nawrocki
2013-06-14 17:45 ` Sylwester Nawrocki
2013-06-14 17:45 ` Sylwester Nawrocki
2013-06-16 21:12 ` Tomasz Figa
2013-06-16 21:12 ` Tomasz Figa
2013-06-16 21:12 ` Tomasz Figa
2013-06-14 17:45 ` [RFC PATCH 3/5] video: exynos_dsi: Use generic PHY driver Sylwester Nawrocki
2013-06-14 17:45 ` Sylwester Nawrocki
2013-06-14 17:45 ` Sylwester Nawrocki
2013-06-16 21:15 ` Tomasz Figa
2013-06-16 21:15 ` Tomasz Figa
2013-06-16 21:15 ` Tomasz Figa
2013-06-19 17:10 ` Sylwester Nawrocki
2013-06-19 17:10 ` Sylwester Nawrocki
2013-06-19 17:10 ` Sylwester Nawrocki
2013-06-19 17:20 ` Tomasz Figa
2013-06-19 17:20 ` Tomasz Figa
2013-06-19 17:20 ` Tomasz Figa
2013-06-14 17:45 ` [RFC PATCH 4/5] exynos4-is: Use generic MIPI CSIS " Sylwester Nawrocki
2013-06-14 17:45 ` Sylwester Nawrocki
2013-06-14 17:45 ` Sylwester Nawrocki
2013-06-14 17:45 ` [RFC PATCH 5/5] ARM: Samsung: Remove MIPI PHY setup code Sylwester Nawrocki
2013-06-14 17:45 ` Sylwester Nawrocki
2013-06-14 17:45 ` Sylwester Nawrocki
2013-06-16 20:52 ` Kukjin Kim
2013-06-16 20:52 ` Kukjin Kim
2013-06-16 20:52 ` Kukjin Kim
2013-06-19 17:24 ` Sylwester Nawrocki
2013-06-19 17:24 ` Sylwester Nawrocki
2013-06-19 17:24 ` Sylwester Nawrocki
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=3575249.Vg82ll65tN@flatron \
--to=tomasz.figa@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.