Re: [PATCH v2 02/11] drivercore: Bind/unbind power domain on probe/remove
On 3 March 2014 17:02, Tomasz Figa wrote: > On a number of platforms, devices are part of controllable power > domains, which need to be enabled before such devices can be accessed > and may be powered down when the device is idle to save some power. > This means that on systems that support power domain control using > generic power domains subsystem, it is necessary to add device to its > power domain before binding a driver to it and remove it from its power > domain after its driver is unbound to make sure that an unused device > does not affect power domain state. > > Since this is not limited to particular busses and specific > archs/platforms, it is more convenient to do the above directly in > driver core, just as done with pinctrl default configuration. This patch > adds necessary code to really_probe() and __device_release_driver() to > achieve this and maintain consistent stack-like ordering of operations > happening when binding and unbinding a driver. > > Signed-off-by: Tomasz Figa This definitely makes sense to me! Reviewed-by: Ulf Hansson > --- > drivers/base/dd.c | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/drivers/base/dd.c b/drivers/base/dd.c > index 0605176..78e5b36 100644 > --- a/drivers/base/dd.c > +++ b/drivers/base/dd.c > @@ -23,6 +23,7 @@ > #include > #include > #include > +#include > #include > #include > > @@ -273,6 +274,11 @@ static int really_probe(struct device *dev, struct > device_driver *drv) > > dev->driver = drv; > > + /* If using genpd, bind power domain now before probing */ > + ret = genpd_bind_domain(dev); > + if (ret) > + goto probe_failed; > + > /* If using pinctrl, bind pins now before probing */ > ret = pinctrl_bind_pins(dev); > if (ret) > @@ -303,6 +309,7 @@ static int really_probe(struct device *dev, struct > device_driver *drv) > probe_failed: > devres_release_all(dev); > driver_sysfs_remove(dev); > + genpd_unbind_domain(dev); > dev->driver = NULL; > dev_set_drvdata(dev, NULL); > > @@ -513,7 +520,7 @@ static void __device_release_driver(struct device *dev) > > blocking_notifier_call_chain(&dev->bus->p->bus_notifier, > > BUS_NOTIFY_UNBOUND_DRIVER, > dev); > - > + genpd_unbind_domain(dev); > } > } > > -- > 1.9.0 > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/11] base: power: Add generic OF-based power domain look-up
On 3 March 2014 17:02, Tomasz Figa wrote:
> This patch introduces generic code to perform power domain look-up using
> device tree and automatically bind devices to their power domains.
> Generic device tree binding is introduced to specify power domains of
> devices in their device tree nodes.
>
> Backwards compatibility with legacy Samsung-specific power domain
> bindings is provided, but for now the new code is not compiled when
> CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This
> will change as soon as Exynos power domain code gets converted to use
> the generic framework in further patch.
>
> Signed-off-by: Tomasz Figa
> ---
> .../devicetree/bindings/power/power_domain.txt | 51
> drivers/base/power/domain.c| 298
> +
> include/linux/pm_domain.h | 46
> kernel/power/Kconfig | 4 +
> 4 files changed, 399 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt
>
> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt
> b/Documentation/devicetree/bindings/power/power_domain.txt
> new file mode 100644
> index 000..93be5d9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> @@ -0,0 +1,51 @@
> +* Generic power domains
> +
> +System on chip designs are often divided into multiple power domains that
> +can be used for power gating of selected IP blocks for power saving by
> +reduced leakage current.
> +
> +This device tree binding can be used to bind power domain consumer devices
> +with their power domains provided by power domain providers. A power domain
> +provider can be represented by any node in the device tree and can provide
> +one or more power domains. A consumer node can refer to the provider by
> +a phandle and a set of phandle arguments (so called power domain specifier)
> +of length specified by #power-domain-cells property in the power domain
> +provider node.
> +
> +==Power domain providers==
> +
> +Required properties:
> + - #power-domain-cells : Number of cells in a power domain specifier;
> + Typically 0 for nodes representing a single power domain and 1 for nodes
> + providing multiple power domains (e.g. power controllers), but can be
> + any value as specified by device tree binding documentation of particular
> + provider.
> +
> +Example:
> +
> + power: power-controller@1234 {
> + compatible = "foo,power-controller";
> + reg = <0x1234 0x1000>;
> + #power-domain-cells = <1>;
> + };
> +
> +The node above defines a power controller that is a power domain provider
> +and expects one cell as its phandle argument.
> +
> +==Power domain consumers==
> +
> +Required properties:
> + - power-domain : A phandle and power domain specifier as defined by bindings
> + of power controller specified by phandle.
> +
> +Example:
> +
> + leaky-device@1235 {
> + compatible = "foo,i-leak-current";
> + reg = <0x1235 0x1000>;
> + power-domain = <&power 0>;
> + };
> +
> +The node above defines a typical power domain consumer device, which is
> located
> +inside power domain with index 0 of power controller represented by node with
> +label "power".
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index dc127e5..006b455 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -3,12 +3,16 @@
> *
> * Copyright (C) 2011 Rafael J. Wysocki , Renesas Electronics
> Corp.
> *
> + * Support for Device Tree based power domain providers:
> + * Copyright (C) 2014 Tomasz Figa
> + *
> * This file is released under the GPLv2.
> */
>
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -2177,3 +2181,297 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
> list_add(&genpd->gpd_list_node, &gpd_list);
> mutex_unlock(&gpd_list_lock);
> }
> +
> +#ifdef CONFIG_PM_GENERIC_DOMAINS_OF
Do we need a new config for this? Can't we just use CONFIG_OF?
> +/*
> + * DEVICE TREE BASED POWER DOMAIN PROVIDERS
> + *
> + * The code below implements generic device tree based power domain providers
> + * that bind device tree nodes with generic power domains registered in the
> + * system.
> + *
> + * Any driver that registers generic power domains and need to support
> binding
> + * of devices to these domains is supposed to register a power domain
> provider,
> + * which maps a power domain specifier retrieved from device tree to a power
> + * domain.
> + *
> + * Two simple mapping functions have been provided for convenience:
> + * - of_genpd_xlate_simple() for 1:1 device tree node to domain mapping,
> + * - of_genpd_xlate_onecell() for mapping of multiple domains per node
> + *by index.
> + */
> +
> +/**
> + * struct of_genpd_provider
[RFT][PATCH 1/2] spi: s3c24xx: Add missing spi_master_{resume,suspend} calls to PM callbacks
This is required since commit 2025172e3280 "spi/bitbang: Use core message pump".
spi-bitbang now uses core message pump, so it needs to call spi_master_suspend/
spi_master_resume to start/stop the queue while suspend/resume.
Signed-off-by: Axel Lin
---
drivers/spi/spi-s3c24xx.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-s3c24xx.c b/drivers/spi/spi-s3c24xx.c
index a275445..bed2338 100644
--- a/drivers/spi/spi-s3c24xx.c
+++ b/drivers/spi/spi-s3c24xx.c
@@ -633,6 +633,11 @@ static int s3c24xx_spi_remove(struct platform_device *dev)
static int s3c24xx_spi_suspend(struct device *dev)
{
struct s3c24xx_spi *hw = dev_get_drvdata(dev);
+ int ret;
+
+ ret = spi_master_suspend(hw->master);
+ if (ret)
+ return ret;
if (hw->pdata && hw->pdata->gpio_setup)
hw->pdata->gpio_setup(hw->pdata, 0);
@@ -646,7 +651,7 @@ static int s3c24xx_spi_resume(struct device *dev)
struct s3c24xx_spi *hw = dev_get_drvdata(dev);
s3c24xx_spi_initialsetup(hw);
- return 0;
+ return spi_master_resume(hw->master);
}
static const struct dev_pm_ops s3c24xx_spi_pmops = {
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 08/21] drm/panel: add TC358764 driver
2014-02-12 20:31 GMT+09:00 Andrzej Hajda :
> The patch adds driver for Toshiba DSI/LVDS TC358764 bridge.
> Driver registers itself as mipi_dsi_driver. It is exposed to the
> system via drm_panel interface, it uses also drm_panel framework
> to interact with LVDS panel connected to it.
> Driver supports only DT bindings.
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/panel/Kconfig | 7 +
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-tc358764.c | 505
> +
> 3 files changed, 513 insertions(+)
> create mode 100644 drivers/gpu/drm/panel/panel-tc358764.c
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 7527557..b98a485 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -23,4 +23,11 @@ config DRM_PANEL_S6E8AA0
> select DRM_MIPI_DSI
> select VIDEOMODE_HELPERS
>
> +config DRM_PANEL_TC358764
> + tristate "TC358764 DSI/LVDS bridge"
> + depends on DRM && DRM_PANEL
> + depends on OF
> + select DRM_MIPI_DSI
> + select VIDEOMODE_HELPERS
> +
> endmenu
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 181265b..7cbb0cf 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -1,2 +1,3 @@
> obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
> obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
> +obj-$(CONFIG_DRM_PANEL_TC358764) += panel-tc358764.o
> diff --git a/drivers/gpu/drm/panel/panel-tc358764.c
> b/drivers/gpu/drm/panel/panel-tc358764.c
> new file mode 100644
> index 000..f9c1289
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-tc358764.c
> @@ -0,0 +1,505 @@
> +/*
> + * TC358764 MIPI-DSI to LVDS bridge panel driver.
> + *
> + * Copyright (c) 2013 Samsung Electronics Co., Ltd
> + *
> + * Andrzej Hajda
> + *
> + * 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
> +#include
> +#include
...
> +/* of_* functions will be removed after acceptance of of_graph patches */
> +static struct device_node *
> +of_get_child_by_name_reg(struct device_node *parent, const char *name, u32
> reg)
> +{
> + struct device_node *np;
> +
> + for_each_child_of_node(parent, np) {
> + u32 r;
> +
> + if (!np->name || of_node_cmp(np->name, name))
> + continue;
> +
> + if (of_property_read_u32(np, "reg", &r) < 0)
> + r = 0;
> +
> + if (reg == r)
> + break;
> + }
> +
> + return np;
> +}
> +
> +static struct device_node *of_graph_get_port_by_reg(struct device_node
> *parent,
> + u32 reg)
> +{
> + struct device_node *ports, *port;
> +
> + ports = of_get_child_by_name(parent, "ports");
> + if (ports) {
> + port = of_get_child_by_name_reg(ports, "port", reg);
> + of_node_put(ports);
> + } else {
> + port = of_get_child_by_name_reg(parent, "port", reg);
> + }
> + return port;
> +}
> +
> +static struct device_node *
> +of_graph_get_endpoint_by_reg(struct device_node *port, u32 reg)
> +{
> + return of_get_child_by_name_reg(port, "endpoint", reg);
> +}
> +
> +static struct device_node *
> +of_graph_get_remote_port_parent(const struct device_node *node)
> +{
> + struct device_node *np;
> + unsigned int depth;
> +
> + /* Get remote endpoint node. */
> + np = of_parse_phandle(node, "remote-endpoint", 0);
> +
> + /* Walk 3 levels up only if there is 'ports' node. */
> + for (depth = 3; depth && np; depth--) {
> + np = of_get_next_parent(np);
> + if (depth == 2 && of_node_cmp(np->name, "ports"))
> + break;
> + }
> + return np;
> +}
> +
> +static struct device_node *tc358764_of_find_panel_node(struct device *dev)
> +{
> + struct device_node *np, *ep;
> +
> + np = of_graph_get_port_by_reg(dev->of_node, 1);
> + if (!np)
> + return NULL;
> +
> + ep = of_graph_get_endpoint_by_reg(np, 0);
> + of_node_put(np);
> + if (!ep)
> + return NULL;
> +
> + np = of_graph_get_remote_port_parent(ep);
> + of_node_put(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->reset_gpio = of_get_named_gpio(np, "reset-gpio", 0);
> + if (ctx->reset_gpio < 0) {
> + dev_err(dev, "no reset GPIO pin provided\n");
> + //return ctx->reset_gpio;
Seem like your mistake.
> + }
Re: [RFC PATCH v2 03/21] exynos/dsim: add DT bindings
2014-02-12 20:31 GMT+09:00 Andrzej Hajda :
> The patch adds DT bindings for Exynos DSI Master. DSIM follows rules
> for DSI bus host bindings [1].
> Properties describes its resources: memory, interrupt, clocks,
> phy, regulators and frequencies of clocks.
>
> [1]: Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
>
> Signed-off-by: Andrzej Hajda
> ---
> v2
> - added burst and esc clock frequency properties
> - add samsung prefix to all frequency props
> ---
> .../devicetree/bindings/video/exynos_dsim.txt | 53
> ++
> 1 file changed, 53 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/exynos_dsim.txt
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_dsim.txt
> b/Documentation/devicetree/bindings/video/exynos_dsim.txt
> new file mode 100644
> index 000..2a49704
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/exynos_dsim.txt
> @@ -0,0 +1,53 @@
> +Exynos MIPI DSI Master
> +
> +Required properties:
> + - compatible: "samsung,exynos4210-mipi-dsi"
> + - reg: physical base address and length of the registers set for the device
> + - interrupts: should contain DSI interrupt
> + - clocks: list of clock specifiers, must contain an entry for each required
> +entry in clock-names
> + - clock-names: should include "bus_clk"and "pll_clk" entries
> + - phys: list of phy specifiers, must contain an entry for each required
> +entry in phy-names
> + - phy-names: should include "dsim" entry
> + - vddcore-supply: MIPI DSIM Core voltage supply (e.g. 1.1V)
> + - vddio-supply: MIPI DSIM I/O and PLL voltage supply (e.g. 1.8V)
> + - samsung,pll-clock-frequency: specifies frequency of the "pll_clk" clock
> + - samsung,burst-clock-frequency: specifies DSI frequency in high-speed
> burst
> +mode
> + - samsung,esc-clock-frequency: specifies DSI frequency in escape mode
> + - #address-cells, #size-cells: should be set respectively to <1> and <0>
> +according to DSI host bindings (see MIPI DSI bindings [1])
> +
> +Optional properties:
> + - samsung,power-domain: a phandle to DSIM power domain node
> +
> +Child nodes:
> + Should contain DSI peripheral nodes (see DSI bindings [1])
> +
> +[1]: Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
> +
> +Example:
> +
> + dsi@11C8 {
> + compatible = "samsung,exynos4210-mipi-dsi";
> + reg = <0x11C8 0x1>;
> + interrupts = <0 79 0>;
> + clocks = <&clock 286>, <&clock 143>;
> + clock-names = "bus_clk", "pll_clk";
> + phys = <&mipi_phy 1>;
> + phy-names = "dsim";
> + vddcore-supply = <&vusb_reg>;
> + vddio-supply = <&vmipi_reg>;
> + samsung,power-domain = <&pd_lcd0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + samsung,pll-clock-frequency = <2400>;
> + samsung,burst-clock-frequency = <5>;
> + samsung,esc-clock-frequency = <2000>;
Isn't a property indicating cpu or video mode needed for the future
even though now DSI driver doesn't support CPU interface yet? Which
mode is used would depend on machine.
> +
> + panel@0 {
> + reg = <0>;
> + ...
> + };
> + };
> --
> 1.8.3.2
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] ARM: dts: imx6: add PCIe interrupt mapping properties
On Fri, Feb 28, 2014 at 06:28:41PM +0100, Lucas Stach wrote:
> As defined by the common PCI bindings.
>
> Signed-off-by: Lucas Stach
> ---
> arch/arm/boot/dts/imx6qdl.dtsi | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
> index fb28b2ecb1db..db3339e7d3a2 100644
> --- a/arch/arm/boot/dts/imx6qdl.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> @@ -10,6 +10,8 @@
> * http://www.gnu.org/copyleft/gpl.html
> */
>
> +#include
> +
> #include "skeleton.dtsi"
>
> / {
> @@ -126,7 +128,16 @@
> 0x8100 0 0 0x01f8 0
> 0x0001 /* downstream I/O */
> 0x8200 0 0x0100 0x0100 0
> 0x00f0>; /* non-prefetchable memory */
> num-lanes = <1>;
> +
Please drop these blank lines between properties.
Shawn
> interrupts = <0 123 0x04>;
> +
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 0x7>;
> + interrupt-map = <0 0 0 1 &intc GIC_SPI 123
> IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 2 &intc GIC_SPI 122
> IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 3 &intc GIC_SPI 121
> IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 4 &intc GIC_SPI 120
> IRQ_TYPE_LEVEL_HIGH>;
> +
> clocks = <&clks 189>, <&clks 187>, <&clks 206>, <&clks
> 144>;
> clock-names = "pcie_ref_125m", "sata_ref_100m",
> "lvds_gate", "pcie_axi";
> status = "disabled";
> --
> 1.8.5.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 08/11] ARM: s3c64xx: dt: Enable SoC-level power management
On Mon, Mar 03, 2014 at 05:02:13PM +0100, Tomasz Figa wrote: > This patch adds call to s3c64xx_pm_init() from init_machine() callback > of mach-s3c64xx-dt to enable SoC-level power management features, such > as power domain management and sleep support. Reviewed-by: Mark Brown signature.asc Description: Digital signature
Re: [PATCH v2 07/11] ARM: s3c64xx: pm: Add device tree based power domain instantiation
On Mon, Mar 03, 2014 at 05:02:12PM +0100, Tomasz Figa wrote: > This patch adds support for registering power domains of S3C64xx SoCs > and binding devices to them using device tree. Reviwed-by: Mark Brown signature.asc Description: Digital signature
Re: [PATCH v2 09/11] ARM: dts: s3c64xx: Add nodes for power domains
On Mon, Mar 03, 2014 at 05:02:14PM +0100, Tomasz Figa wrote: > This patch adds device tree nodes for power domains available on S3C64xx > SoCs. Reviwed-by: Mark Brown signature.asc Description: Digital signature
Re: [PATCH v2 06/11] ARM: s3c64xx: pm: Add pwr_stat bit for domain G
On Mon, Mar 03, 2014 at 05:02:11PM +0100, Tomasz Figa wrote: > There is a status bit for domain G present in BLK_PWR_STAT register, but > it is currently not specified in the driver. > > This patch adds the status bit of domain G to structure describing it. Reviwed-by: Mark Brown signature.asc Description: Digital signature
Re: [PATCH v2 04/11] ARM: s3c64xx: pm: Use name field of generic_pm_domain
On Mon, Mar 03, 2014 at 05:02:09PM +0100, Tomasz Figa wrote: > This patch removes name field from private s3c64xx_pm_domain struct and > moves domain name to dedicated field of generic_pm_domain struct. Reviwed-by: Mark Brown signature.asc Description: Digital signature
Re: [PATCH v2 05/11] ARM: s3c64xx: pm: Add always_on field to s3c64xx_pm_domain struct
On Mon, Mar 03, 2014 at 05:02:10PM +0100, Tomasz Figa wrote: > This patch adds always_on field to s3c64xx_pm_domain struct to allow > handling registration of all domains in the same way, without the need > to have separate arrays for normal and always on domains. Reviwed-by: Mark Brown signature.asc Description: Digital signature
Re: [PATCH v2 02/11] drivercore: Bind/unbind power domain on probe/remove
On Mon, Mar 03, 2014 at 05:02:07PM +0100, Tomasz Figa wrote: > On a number of platforms, devices are part of controllable power > domains, which need to be enabled before such devices can be accessed > and may be powered down when the device is idle to save some power. > This means that on systems that support power domain control using > generic power domains subsystem, it is necessary to add device to its > power domain before binding a driver to it and remove it from its power > domain after its driver is unbound to make sure that an unused device > does not affect power domain state. Reviewed-by: Mark Brown signature.asc Description: Digital signature
Re: [PATCH v2 01/11] base: power: Add generic OF-based power domain look-up
On Mon, Mar 03, 2014 at 05:02:06PM +0100, Tomasz Figa wrote: > This patch introduces generic code to perform power domain look-up using > device tree and automatically bind devices to their power domains. > Generic device tree binding is introduced to specify power domains of > devices in their device tree nodes. > > Backwards compatibility with legacy Samsung-specific power domain > bindings is provided, but for now the new code is not compiled when > CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This > will change as soon as Exynos power domain code gets converted to use > the generic framework in further patch. Reviwed-by: Mark Brown (mainly the binding) signature.asc Description: Digital signature
Re: [RFC PATCH v2 00/21] Add DSI display support for Exynos based boards
Hi Andrzej, Thanks for your contributions. 2014-02-12 20:31 GMT+09:00 Andrzej Hajda : > Hi, > > This patchset adds drivers and bindings to the following devices: > - Exynos DSI master, > - S6E8AA0 DSI panel, > - TC358764 DSI/LVDS bridge, > - HV070WSA-100 LVDS panel. > > It adds also display support in DTS files for the following boards: > - Exynos4210/Trats, > - Exynos4412/Trats2, > - Exynos5250/Arndale. > > Things worth mentioning: > > 1. I have implemented DSI/LVDS bridge using drm_panel framework, ie. > the driver exposes drm_panel interface on DSI side, and interact with > panels on LVDS side using drm_panel framework. This approach seems to > me simpler and more natural than using drm_bridge. Can you give me more details about why you think better to use panel framework than using drm_bridge? "Simpler" and "more natural" are ambiguous to me. Using same drm_panel framework for LDVS bridge and real panel drivers isn't reasonable to me as now because drm_panel framework would be for real panel device even if the use of drm_panel framework looks like suitable to LVDS bridge driver. I thought Sean's way, ptn3460 driver using drm_bride stuff, is good enough, and that would be why drm_bridge exists and why drm_encoder has drm_bridge. And I'm finding more generic way, how to handle LVDS bridge using super node so that LVDS bridge driver isn't embedded to connector drivers such as eDP and MIPI-DSI, and dt binding of LVDS bridge can be done at top level of Exynos drm. Once the binding is done, encoder of display bus driver will have drm_bridge object of LVDS bridge driver so that display bus driver can handle LVDS bridge driver. Will review your patch series soon. Thanks, Inki Dae > > 2. I have used video interface bindings to make link between bridge and LVDS > panel. > Other places where such links can be created are: > a) link between DSI master and slave, I wonder if it is always neccessary, >DSI bus is also video bus, > b) link between FIMD(display controller) and DSI Master, currently Exynos DRM >framework uses driver's hardcoded links, converting it to video interface >bindings should be done (if required) by separate patches. > > The patchset is based on Sean's Paul Exynos refactor patches v4 [1]. > To work properly porch calculation should be fixed according to my comment > [2]. > > It is the 2nd iteration of the patches, main changes: > - based on v4 refactor patches, > - added arndale related stuff. > Other changes are described in individual patches. > > [1] http://permalink.gmane.org/gmane.comp.video.dri.devel/99264 > [2] http://permalink.gmane.org/gmane.comp.video.dri.devel/99826 > > Regards > Andrzej > > > Andrzej Hajda (21): > drm_mipi_dsi: add flags to DSI messages > drm/exynos: delay fbdev initialization until an output is connected > exynos/dsim: add DT bindings > drm/exynos: add DSIM driver > panel/s6e8aa0: add DT bindings > drm/panel: add S6E8AA0 driver > panel/tc358764: add DT bindings > drm/panel: add TC358764 driver > panel/simple: add video interface DT bindings > panel/hv070wsa-100: add DT bindings > drm/panel: add support for BOE HV070WSA-100 panel to simple-panel > ARM: dts: exynos4: add MIPI DSI Master node > ARM: dts: exynos4210-trats: add panel node > ARM: dts: exynos4412-trats2: add panel node > ARM: dts: exynos5250: add mipi-phy node > ARM: dts: exynos5250: add display power domain node > ARM: dts: exynos5250: add DSI node > ARM: dts: exynos5250-arndale: add display regulators > ARM: dts: exynos5250-arndale: add dsi and panel nodes > ARM: dts: exynos4210-trats: enable exynos/fimd node > ARM: dts: exynos4412-trats2: enable exynos/fimd node > > .../devicetree/bindings/panel/boe,hv070wsa-100.txt |7 + > .../devicetree/bindings/panel/samsung,s6e8aa0.txt | 51 + > .../devicetree/bindings/panel/simple-panel.txt |6 + > .../devicetree/bindings/panel/toshiba,tc358764.txt | 41 + > .../devicetree/bindings/video/exynos_dsim.txt | 53 + > arch/arm/boot/dts/exynos4.dtsi | 14 + > arch/arm/boot/dts/exynos4210-trats.dts | 42 + > arch/arm/boot/dts/exynos4412-trats2.dts| 51 + > arch/arm/boot/dts/exynos5250-arndale.dts | 63 + > arch/arm/boot/dts/exynos5250.dtsi | 25 + > drivers/gpu/drm/exynos/Kconfig |9 + > drivers/gpu/drm/exynos/Makefile|1 + > drivers/gpu/drm/exynos/exynos_drm_drv.c| 26 +- > drivers/gpu/drm/exynos/exynos_drm_drv.h|1 + > drivers/gpu/drm/exynos/exynos_drm_dsi.c| 1402 > > drivers/gpu/drm/exynos/exynos_drm_fb.c |3 + > drivers/gpu/drm/exynos/exynos_drm_fbdev.c |4 +- > drivers/gpu/drm/panel/Kconfig | 14 + > drivers/gpu/drm/panel/Makefile |2 + > drivers/gpu/drm/panel/panel-s6e8aa0.c | 1064 +++
Re: [PATCH 1/2] of/irq: Fix irq-mapping in of_irq_parse_raw()
On Tue, Mar 4, 2014 at 6:54 AM, Tim Harvey wrote: > When an interrupt-map contains multiple entries an imap pointer arithmetic > bug can cause only the first entry to be properly evaluated and causes > the out_irq parameters to be incorrect depending on the #interrupt-cells > and #address-cells of the parent interrupt controller. > > Specifically, the imap pointer into the interrupt-map table should be > adjusted by the parent interrupt controller #interrupt-cells size only > as at this point the only the parent unit interrupt specifier needs to be > stepped over. > > This resolves an issue encountered when using the of_irq_parse_and_map_pci() > for the imx6 pcie host controller driver map_irq function where a P2P bridge > is on the bus and legacy PCI interrupts are to be used. > Note the subject of my patch was incorrect - its a single patch, not a series. The subject should read: [PATCH] of/irq: Fix irq-mapping in of_irq_parse_raw() Sorry for the confusion, Tim -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 02/11] drivercore: Bind/unbind power domain on probe/remove
Hi Tomasz, On Mon, Mar 3, 2014 at 5:02 PM, Tomasz Figa wrote: > On a number of platforms, devices are part of controllable power > domains, which need to be enabled before such devices can be accessed > and may be powered down when the device is idle to save some power. > This means that on systems that support power domain control using > generic power domains subsystem, it is necessary to add device to its > power domain before binding a driver to it and remove it from its power > domain after its driver is unbound to make sure that an unused device > does not affect power domain state. > > Since this is not limited to particular busses and specific > archs/platforms, it is more convenient to do the above directly in > driver core, just as done with pinctrl default configuration. This patch > adds necessary code to really_probe() and __device_release_driver() to > achieve this and maintain consistent stack-like ordering of operations > happening when binding and unbinding a driver. > > Signed-off-by: Tomasz Figa patches 01 and 02 Reviewed-by: Philipp Zabel Tested-by: Philipp Zabel on i.MX6 GK802. regards Philipp -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 02/11] drivercore: Bind/unbind power domain on probe/remove
On 03/03, Tomasz Figa wrote: > On a number of platforms, devices are part of controllable power > domains, which need to be enabled before such devices can be accessed > and may be powered down when the device is idle to save some power. > This means that on systems that support power domain control using > generic power domains subsystem, it is necessary to add device to its > power domain before binding a driver to it and remove it from its power > domain after its driver is unbound to make sure that an unused device > does not affect power domain state. > > Since this is not limited to particular busses and specific > archs/platforms, it is more convenient to do the above directly in > driver core, just as done with pinctrl default configuration. This patch > adds necessary code to really_probe() and __device_release_driver() to > achieve this and maintain consistent stack-like ordering of operations > happening when binding and unbinding a driver. > > Signed-off-by: Tomasz Figa Reviewed-by: Stephen Boyd -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/11] base: power: Add generic OF-based power domain look-up
On 03/03, Tomasz Figa wrote: > diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c > index dc127e5..006b455 100644 > --- a/drivers/base/power/domain.c > +++ b/drivers/base/power/domain.c > @@ -3,12 +3,16 @@ > * > * Copyright (C) 2011 Rafael J. Wysocki , Renesas Electronics > Corp. > * > + * Support for Device Tree based power domain providers: > + * Copyright (C) 2014 Tomasz Figa > + * > * This file is released under the GPLv2. > */ > > #include > #include > #include > +#include Is this still needed? > #include > #include > #include [...] > + > +/* > + * DEVICE<->DOMAIN BINDING USING DEVICE TREE LOOK-UP > + * > + * The code below registers a notifier for platform bus devices' > + * BUS_NOTIFY_BIND_DRIVER events and tries to attach devices to their power > + * domains by looking them up using Device Tree. > + * > + * Similarly in BUS_NOTIFY_UNBOUND_DRIVER the device is detached from its > + * domain, since it no longer supports runtime PM without any driver bound > + * to it. This looks outdated. > + * > + * Both generic and legacy Samsung-specific DT bindings are supported to > + * keep backwards compatibility with existing DTBs. > + */ -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Adding set_blob ioctl to DRM
On Tue, 4 Mar 2014 09:35:57 +0100 Daniel Vetter wrote: > On Thu, Feb 20, 2014 at 11:24:40AM +1000, Dave Airlie wrote: > > > I am working on enabling a Color Enhancement block for primary display > > > for Exynos SoC. I need to > > > set a bunch of parameters like Color Conversion matrix, Contrast > > > Improvement parameters etc ~ 30 parameters from User Space. > > > > > > I am planning to use KDS blob property to receive these parameters. > > > Currently drivers are not allowed to create a blob property inside > > > drm. Neither, user space can set the blob. There is no ioctl provided > > > for same. > > > > I don't really like the idea of sticking unstructured data into an > > ioctl, for the driver to interpret, > > > > it opens the door to all kinds of ugly driver hacks, so I think we > > should have writable blobs, > > but with well defined structures inside them, not per-driver ones. > > > > Per-driver structures will lead to binary userspace drivers that start > > sticking a pll timings blob on the end and require it to set a mode, > > because I know driver developers will abuse any interface in the worst > > way possible. > > > > Currently the only blob we really have is EDID and its well defined, > > so if we are going to add writable blobs, they need to be well defined > > and as little as possible driver specific, just to avoid driver > > writings doing what driver writers do. > > tbh I don't see a use for structured blobs at all and would much more > prefer a pile of properties. With the atomic modeset ioctl proposals > floating around we could then pass in an entire sets of properties, which > is essentially what the blob prop would be doing. > > The upshot of going all-in with explicitly named properties is that we can > shovel kms configuration descriptions into different formats. I'm thinking > of shovelling an initial config into DT or something similar as an > example. For i915 we have some experimental patches which load a DT blob > as a firmware file and use the property values to set things up. I have most of this working with i915 now. Using a DT configuration I can set module parameters, select which crtc's to enable, which connectors to enable, set connector properties at init time. I'm working on some plane property code now. It's close to being ready for initial review/feedback but there's one problem, you can't currently build an x86_64 (32 bit is fine) kernel with DT enabled because of an unresolved symbol in the apic code. > > So imo a blob property needs some _really_ good justification. My default > stance is to oppose it ;-) > > Cheers, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] PCI: designware: split samsung and fsl bindings
Am Dienstag, den 04.03.2014, 15:53 +0100 schrieb Arnd Bergmann: > On Tuesday 04 March 2014, Lucas Stach wrote: > > Right, we should be able to reuse the clock names. Though I'm not really > > sure how the Samsung clocks maps to those used on i.MX, as the names are > > a bit generic. Maybe someone from Samsung could shed a bit of light on > > this. > > > > On i.MX6 the clock names (which I have to agree are pretty bad) map as > > follows: > > pcie_axi: host controller main register/bus access clock > > pcie_ref_125m: pcie phy reference clock > > > > sata_ref_100m: pcie bus 100MHz reference clock > > That doesn't explain why it's called "sata_ref_100m". > I agree this is bad naming. It's called this way because someone decided to name it like the internal clock it is sourced from on most boards. This really should be pcie_ref, or something. I suspect this corresponds to the pcie_bus clock in the Exynos binding in which case we should just name it this way. > > lvds_gate: bad abstraction. Decides if the reference clock is sourced > > internal (i.e. the 100MHz ref clock above) or from an SoC external > > source. We should really find a better way of representing this in the > > clock tree. > > I don't understand this description at all. Can you try to explain that > with different words? > On i.MX6 the PCIe reference clock is routed through a generic clock pad, which can be configured either as input or output. When the i.MX is the PCI master we source the clock from sata_ref_100m and configure this pad as clock output. Somebody decided to abstract the input/output switch as a gate, which is arguably wrong, this should be a mux deciding between internal or external clock source. The PCIe host driver should really only need the clk pad clock, activation of the sata_ref_100m clock should be handled through parent<->child relationship of those clocks in the clock tree, which isn't properly handled right now. I'll try to fix this up, but it won't be backward compatible in any way. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 4/4] phy: Add Exynos 5250 support to the Exynos USB 2.0 PHY driver
Add support for Exynos 5250. This driver is to replace the old USB 2.0 PHY driver. Signed-off-by: Kamil Debski --- .../devicetree/bindings/phy/samsung-phy.txt|1 + drivers/phy/Kconfig| 11 + drivers/phy/Makefile |1 + drivers/phy/phy-exynos5250-usb2.c | 405 drivers/phy/phy-samsung-usb2.c |6 + drivers/phy/phy-samsung-usb2.h |1 + 6 files changed, 425 insertions(+) create mode 100644 drivers/phy/phy-exynos5250-usb2.c diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt index bf955ab..28f9edb 100644 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt @@ -28,6 +28,7 @@ Required properties: - compatible : should be one of the listed compatibles: - "samsung,exynos4210-usb2-phy" - "samsung,exynos4x12-usb2-phy" + - "samsung,exynos5250-usb2-phy" - reg : a list of registers used by phy driver - first and obligatory is the location of phy modules registers - samsung,sysreg-phandle - handle to syscon used to control the system registers diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index 1890351..fe2663c 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -94,4 +94,15 @@ config PHY_EXYNOS4X12_USB2 Samsung USB 2.0 PHY driver is enabled and means that support for this particular SoC is compiled in the driver. In case of Exynos 4x12 four phys are available - device, host, HSIC0 and HSIC1. + +config PHY_EXYNOS5250_USB2 + bool "Support for Exynos 5250" + depends on PHY_SAMSUNG_USB2 + depends on SOC_EXYNOS5250 + help + Enable USB PHY support for Exynos 5250. This option requires that + Samsung USB 2.0 PHY driver is enabled and means that support for this + particular SoC is compiled in the driver. In case of Exynos 5250 four + phys are available - device, host, HSIC0 and HSIC. + endmenu diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index 69d0b3f2..4dcd389 100644 --- a/drivers/phy/Makefile +++ b/drivers/phy/Makefile @@ -12,3 +12,4 @@ obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o obj-$(CONFIG_PHY_SAMSUNG_USB2) += phy-samsung-usb2.o obj-$(CONFIG_PHY_EXYNOS4210_USB2) += phy-exynos4210-usb2.o obj-$(CONFIG_PHY_EXYNOS4X12_USB2) += phy-exynos4x12-usb2.o +obj-$(CONFIG_PHY_EXYNOS5250_USB2) += phy-exynos5250-usb2.o diff --git a/drivers/phy/phy-exynos5250-usb2.c b/drivers/phy/phy-exynos5250-usb2.c new file mode 100644 index 000..1ba0bb30 --- /dev/null +++ b/drivers/phy/phy-exynos5250-usb2.c @@ -0,0 +1,405 @@ +/* + * Samsung SoC USB 1.1/2.0 PHY driver - Exynos 5250 support + * + * Copyright (C) 2013 Samsung Electronics Co., Ltd. + * Author: Kamil Debski + * + * 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 +#include +#include +#include +#include "phy-samsung-usb2.h" + +/* Exynos USB PHY registers */ +#define EXYNOS_5250_REFCLKSEL_CRYSTAL 0x0 +#define EXYNOS_5250_REFCLKSEL_XO 0x1 +#define EXYNOS_5250_REFCLKSEL_CLKCORE 0x2 + +#define EXYNOS_5250_FSEL_9MHZ6 0x0 +#define EXYNOS_5250_FSEL_10MHZ 0x1 +#define EXYNOS_5250_FSEL_12MHZ 0x2 +#define EXYNOS_5250_FSEL_19MHZ20x3 +#define EXYNOS_5250_FSEL_20MHZ 0x4 +#define EXYNOS_5250_FSEL_24MHZ 0x5 +#define EXYNOS_5250_FSEL_50MHZ 0x7 + +/* Normal host */ +#define EXYNOS_5250_HOSTPHYCTRL0 0x0 + +#define EXYNOS_5250_HOSTPHYCTRL0_PHYSWRSTALL BIT(31) +#define EXYNOS_5250_HOSTPHYCTRL0_REFCLKSEL_SHIFT 19 +#define EXYNOS_5250_HOSTPHYCTRL0_REFCLKSEL_MASK\ + (0x3 << EXYNOS_5250_HOSTPHYCTRL0_REFCLKSEL_SHIFT) +#define EXYNOS_5250_HOSTPHYCTRL0_FSEL_SHIFT16 +#define EXYNOS_5250_HOSTPHYCTRL0_FSEL_MASK \ + (0x7 << EXYNOS_5250_HOSTPHYCTRL0_FSEL_SHIFT) +#define EXYNOS_5250_HOSTPHYCTRL0_TESTBURNINBIT(11) +#define EXYNOS_5250_HOSTPHYCTRL0_RETENABLE BIT(10) +#define EXYNOS_5250_HOSTPHYCTRL0_COMMON_ON_N BIT(9) +#define EXYNOS_5250_HOSTPHYCTRL0_VATESTENB_MASK(0x3 << 7) +#define EXYNOS_5250_HOSTPHYCTRL0_VATESTENB_DUAL(0x0 << 7) +#define EXYNOS_5250_HOSTPHYCTRL0_VATESTENB_ID0 (0x1 << 7) +#define EXYNOS_5250_HOSTPHYCTRL0_VATESTENB_ANALOGTEST (0x2 << 7) +#define EXYNOS_5250_HOSTPHYCTRL0_SIDDQ BIT(6) +#define EXYNOS_5250_HOSTPHYCTRL0_FORCESLEEPBIT(5) +#define EXYNOS_5250_HOSTPHYCTRL0_FORCESUSPEND BIT(4) +#define EXYNOS_5250_HOSTPHYCTRL0_WORDINTERFACE BIT(3) +#define EXYNOS_5250_HOSTPHYCTRL0_UTMISW
[PATCH v7 3/4] phy: Add new Exynos USB 2.0 PHY driver
Add a new driver for the Exynos USB 2.0 PHY. The new driver uses the generic
PHY framework. The driver includes support for the Exynos 4210 and 4x12
SoC families.
Signed-off-by: Kamil Debski
---
.../devicetree/bindings/phy/samsung-phy.txt| 53
Documentation/phy/samsung-usb2.txt | 134
drivers/phy/Kconfig| 29 ++
drivers/phy/Makefile |3 +
drivers/phy/phy-exynos4210-usb2.c | 262
drivers/phy/phy-exynos4x12-usb2.c | 330
drivers/phy/phy-samsung-usb2.c | 223 +
drivers/phy/phy-samsung-usb2.h | 67
8 files changed, 1101 insertions(+)
create mode 100644 Documentation/phy/samsung-usb2.txt
create mode 100644 drivers/phy/phy-exynos4210-usb2.c
create mode 100644 drivers/phy/phy-exynos4x12-usb2.c
create mode 100644 drivers/phy/phy-samsung-usb2.c
create mode 100644 drivers/phy/phy-samsung-usb2.h
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index c0fccaa..bf955ab 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -20,3 +20,56 @@ Required properties:
- compatible : should be "samsung,exynos5250-dp-video-phy";
- reg : offset and length of the Display Port PHY register set;
- #phy-cells : from the generic PHY bindings, must be 0;
+
+Samsung S5P/EXYNOS SoC series USB PHY
+-
+
+Required properties:
+- compatible : should be one of the listed compatibles:
+ - "samsung,exynos4210-usb2-phy"
+ - "samsung,exynos4x12-usb2-phy"
+- reg : a list of registers used by phy driver
+ - first and obligatory is the location of phy modules registers
+- samsung,sysreg-phandle - handle to syscon used to control the system
registers
+- samsung,pmureg-phandle - handle to syscon used to control PMU registers
+- #phy-cells : from the generic phy bindings, must be 1;
+- clocks and clock-names:
+ - the "phy" clock is required by the phy module, used as a gate
+ - the "ref" clock is used to get the rate of the clock provided to the
+ PHY module
+
+The first phandle argument in the PHY specifier identifies the PHY, its
+meaning is compatible dependent. For the currently supported SoCs (Exynos 4210
+and Exynos 4212) it is as follows:
+ 0 - USB device ("device"),
+ 1 - USB host ("host"),
+ 2 - HSIC0 ("hsic0"),
+ 3 - HSIC1 ("hsic1"),
+
+Exynos 4210 and Exynos 4212 use mode switching and require that mode switch
+register is supplied.
+
+Example:
+
+For Exynos 4412 (compatible with Exynos 4212):
+
+usbphy: phy@125b {
+ compatible = "samsung,exynos4x12-usb2-phy";
+ reg = <0x125b 0x100>;
+ clocks = <&clock 305>, <&clock 2>;
+ clock-names = "phy", "ref";
+ status = "okay";
+ #phy-cells = <1>;
+ samsung,sysreg-phandle = <&sys_reg>;
+ samsung,pmureg-phandle = <&pmu_reg>;
+};
+
+Then the PHY can be used in other nodes such as:
+
+phy-consumer@1234 {
+ phys = <&usbphy 2>;
+ phy-names = "phy";
+};
+
+Refer to DT bindings documentation of particular PHY consumer devices for more
+information about required PHYs and the way of specification.
diff --git a/Documentation/phy/samsung-usb2.txt
b/Documentation/phy/samsung-usb2.txt
new file mode 100644
index 000..0c8e260
--- /dev/null
+++ b/Documentation/phy/samsung-usb2.txt
@@ -0,0 +1,134 @@
+.--+
+| Samsung USB 2.0 PHY adaptation layer |
++-+'
+
+| 1. Description
++
+
+The architecture of the USB 2.0 PHY module in Samsung SoCs is similar
+among many SoCs. In spite of the similarities it proved difficult to
+create a one driver that would fit all these PHY controllers. Often
+the differences were minor and were found in particular bits of the
+registers of the PHY. In some rare cases the order of register writes or
+the PHY powering up process had to be altered. This adaptation layer is
+a compromise between having separate drivers and having a single driver
+with added support for many special cases.
+
+| 2. Files description
++--
+
+- phy-samsung-usb2.c
+ This is the main file of the adaptation layer. This file contains
+ the probe function and provides two callbacks to the Generic PHY
+ Framework. This two callbacks are used to power on and power off the
+ phy. They carry out the common work that has to be done on all version
+ of the PHY module. Depending on which SoC was chosen they execute SoC
+ specific callbacks. The specific SoC version is selected by choosing
+ the appropriate compatible string. In addi
[PATCH v7 2/4] phy: core: Add devm_of_phy_get to phy-core
Adding devm_of_phy_get will allow to get phys by supplying a
pointer to the struct device_node instead of struct device.
Signed-off-by: Kamil Debski
---
drivers/phy/phy-core.c | 31 +++
include/linux/phy/phy.h |8
2 files changed, 39 insertions(+)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 7c1b0e1..623b71c 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -526,6 +526,37 @@ struct phy *devm_phy_optional_get(struct device *dev,
const char *string)
EXPORT_SYMBOL_GPL(devm_phy_optional_get);
/**
+ * devm_of_phy_get() - lookup and obtain a reference to a phy.
+ * @dev: device that requests this phy
+ * @np: node containing the phy
+ * @con_id: name of the phy from device's point of view
+ *
+ * Gets the phy using of_phy_get(), and associates a device with it using
+ * devres. On driver detach, release function is invoked on the devres data,
+ * then, devres data is freed.
+ */
+struct phy *devm_of_phy_get(struct device *dev, struct device_node *np,
+ const char *con_id)
+{
+ struct phy **ptr, *phy;
+
+ ptr = devres_alloc(devm_phy_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return ERR_PTR(-ENOMEM);
+
+ phy = of_phy_get(np, con_id);
+ if (!IS_ERR(phy)) {
+ *ptr = phy;
+ devres_add(dev, ptr);
+ } else {
+ devres_free(ptr);
+ }
+
+ return phy;
+}
+EXPORT_SYMBOL_GPL(devm_of_phy_get);
+
+/**
* phy_create() - create a new phy
* @dev: device that is creating the new phy
* @ops: function pointers for performing phy operations
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 2fe3194..bcbf96c 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -149,6 +149,8 @@ struct phy *phy_get(struct device *dev, const char *string);
struct phy *phy_optional_get(struct device *dev, const char *string);
struct phy *devm_phy_get(struct device *dev, const char *string);
struct phy *devm_phy_optional_get(struct device *dev, const char *string);
+struct phy *devm_of_phy_get(struct device *dev, struct device_node *np,
+ const char *con_id);
void phy_put(struct phy *phy);
void devm_phy_put(struct device *dev, struct phy *phy);
struct phy *of_phy_get(struct device_node *np, const char *con_id);
@@ -252,6 +254,12 @@ static inline struct phy *devm_phy_optional_get(struct
device *dev,
return ERR_PTR(-ENOSYS);
}
+struct phy *devm_of_phy_get(struct device *dev, struct device_node *np,
+ const char *con_id)
+{
+ return ERR_PTR(-ENOSYS);
+}
+
static inline void phy_put(struct phy *phy)
{
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 1/4] phy: core: Add an exported of_phy_get function
Previously the of_phy_get function took a struct device * and
was declared static. It was impossible to call it from
another driver and thus it was impossible to get phy defined
for a given node. The old function was renamed to _of_phy_get
and was left for internal use. of_phy_get function was added
and it was exported. The function enables to get a phy for
a given device tree node.
Signed-off-by: Kamil Debski
---
drivers/phy/phy-core.c | 45 -
include/linux/phy/phy.h |6 ++
2 files changed, 42 insertions(+), 9 deletions(-)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 6c73837..7c1b0e1 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -274,8 +274,8 @@ int phy_power_off(struct phy *phy)
EXPORT_SYMBOL_GPL(phy_power_off);
/**
- * of_phy_get() - lookup and obtain a reference to a phy by phandle
- * @dev: device that requests this phy
+ * _of_phy_get() - lookup and obtain a reference to a phy by phandle
+ * @np: device_node for which to get the phy
* @index: the index of the phy
*
* Returns the phy associated with the given phandle value,
@@ -284,20 +284,17 @@ EXPORT_SYMBOL_GPL(phy_power_off);
* not yet loaded. This function uses of_xlate call back function provided
* while registering the phy_provider to find the phy instance.
*/
-static struct phy *of_phy_get(struct device *dev, int index)
+static struct phy *_of_phy_get(struct device_node *np, int index)
{
int ret;
struct phy_provider *phy_provider;
struct phy *phy = NULL;
struct of_phandle_args args;
- ret = of_parse_phandle_with_args(dev->of_node, "phys", "#phy-cells",
+ ret = of_parse_phandle_with_args(np, "phys", "#phy-cells",
index, &args);
- if (ret) {
- dev_dbg(dev, "failed to get phy in %s node\n",
- dev->of_node->full_name);
+ if (ret)
return ERR_PTR(-ENODEV);
- }
mutex_lock(&phy_provider_mutex);
phy_provider = of_phy_provider_lookup(args.np);
@@ -317,6 +314,36 @@ err0:
}
/**
+ * of_phy_get() - lookup and obtain a reference to a phy using a device_node.
+ * @np: device_node for which to get the phy
+ * @con_id: name of the phy from device's point of view
+ *
+ * Returns the phy driver, after getting a refcount to it; or
+ * -ENODEV if there is no such phy. The caller is responsible for
+ * calling phy_put() to release that count.
+ */
+struct phy *of_phy_get(struct device_node *np, const char *con_id)
+{
+ struct phy *phy = NULL;
+ int index = 0;
+
+ if (con_id)
+ index = of_property_match_string(np, "phy-names", con_id);
+
+ phy = _of_phy_get(np, index);
+ if (IS_ERR(phy))
+ return phy;
+
+ if (!try_module_get(phy->ops->owner))
+ return ERR_PTR(-EPROBE_DEFER);
+
+ get_device(&phy->dev);
+
+ return phy;
+}
+EXPORT_SYMBOL_GPL(of_phy_get);
+
+/**
* phy_put() - release the PHY
* @phy: the phy returned by phy_get()
*
@@ -407,7 +434,7 @@ struct phy *phy_get(struct device *dev, const char *string)
if (dev->of_node) {
index = of_property_match_string(dev->of_node, "phy-names",
string);
- phy = of_phy_get(dev, index);
+ phy = _of_phy_get(dev->of_node, index);
} else {
phy = phy_lookup(dev, string);
}
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 3f83459..2fe3194 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -151,6 +151,7 @@ struct phy *devm_phy_get(struct device *dev, const char
*string);
struct phy *devm_phy_optional_get(struct device *dev, const char *string);
void phy_put(struct phy *phy);
void devm_phy_put(struct device *dev, struct phy *phy);
+struct phy *of_phy_get(struct device_node *np, const char *con_id);
struct phy *of_phy_simple_xlate(struct device *dev,
struct of_phandle_args *args);
struct phy *phy_create(struct device *dev, const struct phy_ops *ops,
@@ -259,6 +260,11 @@ static inline void devm_phy_put(struct device *dev, struct
phy *phy)
{
}
+struct phy *of_phy_get(struct device_node *np, const char *con_id)
+{
+ return ERR_PTR(-ENOSYS);
+}
+
static inline struct phy *of_phy_simple_xlate(struct device *dev,
struct of_phandle_args *args)
{
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 0/4] phy: Add new Exynos USB 2.0 PHY driver
Hi, This is the seventh version of this patchset. First and most significant change is that this patchset includes only patches touching the Generic PHY Framework. Patches to the USB controllers were stripped as they require additional work. S5PV210 support is also omitted - it requires more testing. Thank you to everyone who joined the discussion, reviewed the patched and contributed to making the code and consequently the Linux Kernel better. Best wishes, Kamil Debski -- Changes from v6: (not including the change that controller patches were removed form this patchset, also this patchset excludes S5PV210 support - it needs more testing) 1) phy: core: Add an exported of_phy_get function - No changes since v6. 2) phy: core: Add devm_of_phy_get to phy-core - No changes since v6. 3) phy: Add new Exynos USB 2.0 PHY driver - Changed the way clocks are supplied to the driver. Prior to version v7 there were reference clocks for every phy instance, now a single "ref" clock was introduced. - Updated documentation to match the aforementioned change. - Add offset EXYNOS_*_UPHYCLK_PHYFSEL_OFFSET to the clock register content defines. - Corrected way clock register is modified. Instead of a simple write, a proper read, modify, write sequence was introduced. - Important stability fix - added udelay after PHY reset. This fixes a bug causing instability in USB LAN adapters. Without the delay the DMA burst mode was could not be enabled. 4) phy: Add Exynos 5250 support to the Exynos USB 2.0 PHY - Changed handling of clocks to use a single "ref" clock. Changes from v5: 1) phy: core: Add an exported of_phy_get function - corrected behaviour of the modification when GENERIC_PHY is not enabled by adding a stub of the of_phy_get function 2) phy: core: Add devm_of_phy_get to phy-core - corrected behaviour of the modification when GENERIC_PHY is not enabled by adding a stub of the devm_of_phy_get function 3) dts: Add usb2phy to Exynos 4 - no change 4) dts: Add usb2phy to Exynos 5250 - in the previous version, this patch included some phy-exynos5250-usb2.c code by mistake, the code has been remove and added to the proper patch 5) phy: Add new Exynos USB PHY driver - changed strings from Exynos 4212 to Exynos 4x12, as the Exynos 4212 driver is actually a driver for the whole Exynos 4x12 family - added documentation to the Exynos USB 2.0 PHY driver adaptaion layer - corrected strings HSCI -> HSIC - fixed a problem introduced by previous change - on Exynos 4x12 the HSIC did not work on its own - mode switch support was added to Exynos 4x12 (same io pins are used by host and device) - support for phy_set_bus_width introduced by Matt Porter was added 6) phy: Add support for S5PV210 to the Exynos USB PHY - setting of clk register was fixed 7) phy: Add Exynos 5250 support to the Exynos USB 2.0 PHY - supoprt was added for HSIC and device 8) usb: ehci-exynos: Change to use phy provided by the generic phy framework - DT documentation was moved from usb-ehci.txt to exynos-usb.txt Changes from v4: 1) phy: core: Add an exported of_phy_get function - the new exported function of_phy_get was changed to take the phy's name as a parameter instead of the index 2) phy: core: Add devm_of_phy_get to phy-core - fixes made in the comments to devm_of_phy_get 3) phy: Add new Exynos USB PHY driver - move the documentation from a new to an existing file - samsung-phy.txt - fix typos and uppercase hex addresses - add more explanations to Kconfig (checkpatch still complains, but I find it hard to think what else could I add) - add selects MFD_SYSCON as the driver needs it (Thank you, Tobias!) - cleanup included headers in both *.c and .h files - use BIT(x) macro instead of (1 << x) - replaced HOST and DEV with PHY0 and PHY1 in phy-exynos4212-usb2.c, the registers are described as PHYx in the documentation hence the decision to leave the PHYx naming - fixed typo in exynos4210_rate_to_clk reg -> *reg - change hax_mode_switch and enabled type to bool 4) usb: ehci-s5p: Change to use phy provided by the generic phy framework - Put the issue of phy->otg in order - since the new phy driver does not provide this field. With the new driver the switch between host and device is done in power_on of the respective host and device phys. 5) usb: s3c-hsotg: Use the new Exynos USB phy driver with the generic phy framework - fixed the example in the documentation 6) phy: Add support for S5PV210 to the Exynos USB PHY driver - include files cleanup - use BIT(x) macro instead of (1 << x) 7) phy: Add Exynos 5250 support to the Exynos USB 2.0 PHY driver - include files cleanup - use BIT(x) macro instead of (1 << x) 8) dts: Add usb2phy to Exynos 4 - no changes 9) dts: Add usb2phy to Exynos 5250 - no changes Changes from v3: - using PMU and system registers indirectly via syscon - change labelling - change Kconfig name - fixed typos/s
Re: [PATCH 6/7] PCI: designware: use new OF interrupt mapping when possible
On Fri, Feb 28, 2014 at 9:28 AM, Lucas Stach wrote:
> This is the recommended method of doing the IRQ
> mapping. For old devicetrees we fall back to the
> previous practice.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/pci/host/pcie-designware.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/host/pcie-designware.c
> b/drivers/pci/host/pcie-designware.c
> index 17ce88f79d2b..3e0c2af11528 100644
> --- a/drivers/pci/host/pcie-designware.c
> +++ b/drivers/pci/host/pcie-designware.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -738,8 +739,13 @@ static struct pci_bus *dw_pcie_scan_bus(int nr, struct
> pci_sys_data *sys)
> static int dw_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
> {
> struct pcie_port *pp = sys_to_pcie(dev->bus->sysdata);
> + int irq;
>
> - return pp->irq;
> + irq = of_irq_parse_and_map_pci(dev, slot, pin);
> + if (!irq)
> + irq = pp->irq;
> +
> + return irq;
> }
>
> static void dw_pcie_add_bus(struct pci_bus *bus)
> --
> 1.8.5.3
>
Lucas,
Please add the following which are required (at least the second one
is required) for of_irq_parse_and_map_pci() to work properly for P2P
bridges. With the changes below as well as my of/irq fix
(https://patchwork.kernel.org/patch/3762591/) I can now use devices
behind a properly connected P2P bridge.
+++ b/drivers/pci/host/pcie-designware.c
@@ -493,7 +493,7 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
dw_pci.nr_controllers = 1;
dw_pci.private_data = (void **)&pp;
- pci_common_init(&dw_pci);
+ pci_common_init_dev(pp->dev, &dw_pci);
pci_assign_unassigned_resources();
#ifdef CONFIG_PCI_DOMAINS
dw_pci.domain++;
@@ -726,7 +726,7 @@ static struct pci_bus *dw_pcie_scan_bus(int nr, struct pci_s
if (pp) {
pp->root_bus_nr = sys->busnr;
- bus = pci_scan_root_bus(NULL, sys->busnr, &dw_pcie_ops,
+ bus = pci_scan_root_bus(pp->dev, sys->busnr, &dw_pcie_ops,
sys, &sys->resources);
} else {
bus = NULL;
Thanks,
Tim
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] PCI: designware: split samsung and fsl bindings
On Tuesday 04 March 2014, Lucas Stach wrote: > Right, we should be able to reuse the clock names. Though I'm not really > sure how the Samsung clocks maps to those used on i.MX, as the names are > a bit generic. Maybe someone from Samsung could shed a bit of light on > this. > > On i.MX6 the clock names (which I have to agree are pretty bad) map as > follows: > pcie_axi: host controller main register/bus access clock > pcie_ref_125m: pcie phy reference clock > > sata_ref_100m: pcie bus 100MHz reference clock That doesn't explain why it's called "sata_ref_100m". > lvds_gate: bad abstraction. Decides if the reference clock is sourced > internal (i.e. the 100MHz ref clock above) or from an SoC external > source. We should really find a better way of representing this in the > clock tree. I don't understand this description at all. Can you try to explain that with different words? Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] of/irq: Fix irq-mapping in of_irq_parse_raw()
When an interrupt-map contains multiple entries an imap pointer arithmetic
bug can cause only the first entry to be properly evaluated and causes
the out_irq parameters to be incorrect depending on the #interrupt-cells
and #address-cells of the parent interrupt controller.
Specifically, the imap pointer into the interrupt-map table should be
adjusted by the parent interrupt controller #interrupt-cells size only
as at this point the only the parent unit interrupt specifier needs to be
stepped over.
This resolves an issue encountered when using the of_irq_parse_and_map_pci()
for the imx6 pcie host controller driver map_irq function where a P2P bridge
is on the bus and legacy PCI interrupts are to be used.
Signed-off-by: Tim Harvey
Cc: Jason Gunthorpe
Cc: Jingoo Han
Cc: Lucas Stach
Cc: Mark Rutland
Cc: linux-samsung-soc
Cc: Richard Zhu
Cc: Sascha Hauer
Cc: Arnd Bergmann
Cc: Stephen Warren
Cc: Bjorn Helgaas
Cc: Simon Horman
Cc: Thierry Reding
Cc: Ben Dooks
Cc: linux-tegra
Cc: Kukjin Kim
Cc: Shawn Guo
Cc: Grant Likely
---
drivers/of/irq.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 9bcf2cf..8829197 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -237,11 +237,11 @@ int of_irq_parse_raw(const __be32 *addr, struct
of_phandle_args *out_irq)
/* Check for malformed properties */
if (WARN_ON(newaddrsize + newintsize >
MAX_PHANDLE_ARGS))
goto fail;
- if (imaplen < (newaddrsize + newintsize))
+ if (imaplen < newintsize)
goto fail;
- imap += newaddrsize + newintsize;
- imaplen -= newaddrsize + newintsize;
+ imap += newintsize;
+ imaplen -= newintsize;
pr_debug(" -> imaplen=%d\n", imaplen);
}
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REGRESSION] Arndale Octa panics when booting 3.14-rc1
Hi Tushar,
On Tue, Mar 04, 2014 at 12:01:26PM +, Tushar Behera wrote:
> On 4 March 2014 16:09, Javi Merino wrote:
> > On Tue, Mar 04, 2014 at 10:30:19AM +, Sylwester Nawrocki wrote:
> >> On 04/03/14 11:16, Javi Merino wrote:
> >> > Yes, with [1] applied I don't get a kernel panic but the kernel fails
> >> > to boot later on with an Imprecise external abort. Removing the mdma
> >> > nodes from the dts gets rid of that. I guess what's missing is what
> >> > you said: clocks for the mdma devices.
> >>
> >> Is removing mdm0 node enough to fix the boot failure, or both have to be
> >> removed ?
> >
> > Actually, you it's only mdma1. Just removing the mdma1 node from the
> > dt fixes the imprecise external abort.
> >
>
> MDMA1 can support both secure and non-secure AXI transactions, the
> actual behaviour is controlled by trustzone software. It may be the
> case that MDMA1 is configured to be used in secure mode only, hence
> accessing it in non-secure mode is causing the oops.
>
> Right now, the only solution looks like disabling this node in
> Arndale-Octa dts file.
>
> --- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> +++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> @@ -354,4 +354,16 @@
> samsung,i2s-controller = <&i2s0>;
> samsung,audio-codec = <&i2s_stub>;
> };
> +
> + amba {
> + mdma1: mdma@11C1 {
> + /*
> +* MDMA1 can support both secure and non-secure
> +* AXI transactions. When this is enabled in the
> kernel
> +* for boards that run in secure mode, we are getting
> +* imprecise external aborts causing the kernel to
> oops.
> +*/
> + status = "disabled";
> + };
> + };
>
> If it works, I will submit this patch.
It works. Please submit it. Cheers,
Javi
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] PCI: designware: split samsung and fsl bindings
Am Freitag, den 28.02.2014, 21:03 +0100 schrieb Arnd Bergmann: > On Friday 28 February 2014, Lucas Stach wrote: > > +Required properties: > > +- compatible: "fsl,imx6q-pcie" > > +- reg: base addresse and length of the pcie controller > > +- interrupts: First entry must contain interrupt handle for controller > > + INTA output. > > I think this should be documented as "optional" and only for > backwards compatibility with old kernels. > > > +- clocks: Must contain an entry for each entry in clock-names. > > + See ../clocks/clock-bindings.txt for details. > > +- clock-names: Must include the following entries: > > + - "pcie_ref_125m" > > + - "sata_ref_100m" > > + - "lvds_gate" > > + - "pcie_axi" > > I don't understand why you have completely different clocks here > from the exynos documentation. The clock names should really be > the same. Also, why do you have a "sata_ref_100m" clock? > Is this just driving a device that happens to be on-board > for a specific machine? Same for the "lvds_gate". > Right, we should be able to reuse the clock names. Though I'm not really sure how the Samsung clocks maps to those used on i.MX, as the names are a bit generic. Maybe someone from Samsung could shed a bit of light on this. On i.MX6 the clock names (which I have to agree are pretty bad) map as follows: pcie_axi: host controller main register/bus access clock pcie_ref_125m: pcie phy reference clock sata_ref_100m: pcie bus 100MHz reference clock lvds_gate: bad abstraction. Decides if the reference clock is sourced internal (i.e. the 100MHz ref clock above) or from an SoC external source. We should really find a better way of representing this in the clock tree. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 19/21] ARM: dts: exynos5250-arndale: add dsi and panel nodes
On 04/03/14 14:00, Andrzej Hajda wrote:
> I have made video path binding optional, in case of video bus
> if the specific video path is not present driver uses the bus it is
> connected to.
> In case DSI panel is controlled via different bus the path should be
> specified
> explicitly.
>
> I have no strong feelings against making this binding required but as
> you have
> stated above "in this case it's obvious" and for me quite redundant.
Yes, it's a good point. I didn't realize they were optional, I thought
they were not defined at all. I hadn't even thought that they could be
optional, I guess because in my uses there's always a reason to have
them. Even for a simple DSI command mode panel, I have information in
the DSI master's endpoint:
dsi {
...
dsi1_out_ep: endpoint {
remote-endpoint = <&lcd0_in>;
lanes = <0 1 2 3 4 5>;
};
};
which forces to use an endpoint in the panel also.
And, actually, I think in your case also you would need an endpoint for
the dsi master, if you wanted to support multiple endpoints. You
currently have, for example, PLL clock freq as the DSI master's
property, but it should really be a property of the DSI master's endpoint.
I.e. if you have two DSI panels connected to the same DSI master, in a
way that only one can be enabled at a time (there would probably be a
mux to select where the DSI lanes go, we have that on some development
boards), you could well need different clock frequencies for the panels.
> What is the gain in specifying explicitly video paths in such cases?
- Until we (everyone interested in this) have thought about it fully and
agreed that video paths in cases like this are optional, you would be
safer to specify them explicitly. That way your bindings are valid in
either case.
- Uniformity. If in most cases we need to specify the video paths,
either because the control path is different than the data path, or
because there is need for endpoint specific information, having video
paths as optional for some specific cases may needlessly complicate the
code.
Tomi
signature.asc
Description: OpenPGP digital signature
[PATCH 1/1] ARM: exynos_defconfig: Enable HS-I2C
High speed I2C is used on Exynos5 based SoCs. Enable it. Signed-off-by: Sachin Kamat --- arch/arm/configs/exynos_defconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 4ce7b70ea901..e07a227ec0db 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -65,6 +65,7 @@ CONFIG_TCG_TIS_I2C_INFINEON=y CONFIG_I2C=y CONFIG_I2C_MUX=y CONFIG_I2C_ARB_GPIO_CHALLENGE=y +CONFIG_I2C_EXYNOS5=y CONFIG_I2C_S3C2410=y CONFIG_DEBUG_GPIO=y # CONFIG_HWMON is not set -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ARM: exynos_defconfig: Fix a config option
On 24 February 2014 05:51, Kukjin Kim wrote: > On 12/27/13 19:38, Sachin Kamat wrote: >> >> CONFIG_MACH_EXYNOS4_DT does not exist. Use ARCH_EXYNOS4 instead. >> >> Signed-off-by: Sachin Kamat >> --- >> arch/arm/configs/exynos_defconfig |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/arm/configs/exynos_defconfig >> b/arch/arm/configs/exynos_defconfig >> index dbe1f1c47bb0..dff01ecf78cc 100644 >> --- a/arch/arm/configs/exynos_defconfig >> +++ b/arch/arm/configs/exynos_defconfig >> @@ -10,8 +10,8 @@ CONFIG_PARTITION_ADVANCED=y >> CONFIG_ARCH_EXYNOS=y >> CONFIG_S3C_LOWLEVEL_UART_PORT=3 >> CONFIG_S3C24XX_PWM=y >> +CONFIG_ARCH_EXYNOS4=y >> CONFIG_ARCH_EXYNOS5=y >> -CONFIG_MACH_EXYNOS4_DT=y >> CONFIG_SMP=y >> CONFIG_NR_CPUS=8 >> CONFIG_PREEMPT=y > > > Well, this is not required because it should be fine without this change. > ARCH_EXYNOS4 will be selected when ARCH_EXYNOS is enabled and non-exist > CONFIG (MACH_EXYNOS4_DT) will be ignored. Functionally this might not be needed as Exynos4 is selected by default. However, I don't see any point in retaining non-existent symbols. -- With warm regards, Sachin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/5] clk/exynos5260: add clock file for exynos5260
On 04.03.2014 13:10, Tomasz Figa wrote: On 04.03.2014 05:14, Rahul Sharma wrote: On 23 February 2014 07:49, Tomasz Figa wrote: On 18.02.2014 12:56, Rahul Sharma wrote: + FRATE(ID_NONE, "phyclk_hdmi_link_o_tmds_clkhi", NULL, + CLK_IS_ROOT, 12500), + FRATE(ID_NONE, "phyclk_mipi_dphy_4l_m_txbyteclkhs", NULL, + CLK_IS_ROOT, 18750), + FRATE(ID_NONE, "phyclk_dptx_phy_o_ref_clk_24m", NULL, + CLK_IS_ROOT, 2400), + FRATE(ID_NONE, "phyclk_dptx_phy_clk_div2", NULL, + CLK_IS_ROOT, 13500), + FRATE(ID_NONE, "phyclk_mipi_dphy_4l_m_rxclkesc0", NULL, + CLK_IS_ROOT, 2000), + FRATE(ID_NONE, "phyclk_usbhost20_phy_phyclock", NULL, + CLK_IS_ROOT, 6000), + FRATE(ID_NONE, "phyclk_usbhost20_phy_freeclk", NULL, + CLK_IS_ROOT, 6000), + FRATE(ID_NONE, "phyclk_usbhost20_phy_clk48mohci", NULL, + CLK_IS_ROOT, 4800), + FRATE(ID_NONE, "phyclk_usbdrd30_udrd30_pipe_pclk", NULL, + CLK_IS_ROOT, 12500), + FRATE(ID_NONE, "phyclk_usbdrd30_udrd30_phyclock", NULL, + CLK_IS_ROOT, 6000), Are these really fixed rate clocks? It looks strange, because it's a bit unlike previous Samsung SoCs, which used to have up 5 fixed rate clocks in average. These are outputs of various phys. If these are removed we will be left with many orphan clocks. OK. Just wanted to make sure that they are real clocks found in the SoC, as I don't have access to Exynos 5420 datasheet yet. Exynos 5260 of course. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/5] clk/exynos5260: add clock file for exynos5260
Hi Rahul,
On 04.03.2014 05:14, Rahul Sharma wrote:
On 23 February 2014 07:49, Tomasz Figa wrote:
On 18.02.2014 12:56, Rahul Sharma wrote:
+/*
+ * List of parent clocks for muses in CMU_DISP
+*/
+PNAME(mout_phyclk_dptx_phy_ch3_txd_clk_user_p) = {"fin_pll",
+ "phyclk_dptx_phy_ch3_txd_clk"};
+PNAME(mout_phyclk_dptx_phy_ch2_txd_clk_user_p) = {"fin_pll",
+ "phyclk_dptx_phy_ch2_txd_clk"};
+PNAME(mout_phyclk_dptx_phy_ch1_txd_clk_user_p) = {"fin_pll",
+ "phyclk_dptx_phy_ch1_txd_clk"};
+PNAME(mout_phyclk_dptx_phy_ch0_txd_clk_user_p) = {"fin_pll",
+ "phyclk_dptx_phy_ch0_txd_clk"};
Whoa, these clock names are incredibly long. Are they real names from SoC
User's Manual?
Yea, these are same in manual. I kept the name similar, otherwise not easy to
search them in UM.
OK.
+
+PNAME(mout_aclk_disp_222_user_p) = {"fin_pll", "dout_aclk_disp_222"};
+PNAME(mout_sclk_disp_pixel_user_p) = {"fin_pll", "dout_sclk_disp_pixel"};
[snip]
+/* fixed rate clocks generated outside the soc */
Huh? If they are generated outside the SoC, they shouldn't be registered by
this driver, but rather by respective fixed rate clock nodes in DT.
I tried but system doesn't boot if fin_plll is registered from DT as
"fixed-clock".
of_fixed_clk_setup hits after the registration of other CMUs. System asserts
in many places due to div by zero error. It is exactly same for Exynos5420.
So I took 5420 as example and defined fin_pll as osc clock of compatible type
"samsung,exynos5260-oscclk". Rest of the ext clocks are registered as
"fixed-clock". What you say on this ?
Hmm, the common clock framework is designed to account for late
registration of parent clocks. Fixed rate clocks defined from DT seem to
work fine for S3C64xx and Exynos5410 (patches posted some time ago by
Tarek Dakhran). I'm not sure why it doesn't work for you.
+ FRATE(ID_NONE, "phyclk_hdmi_link_o_tmds_clkhi", NULL,
+ CLK_IS_ROOT, 12500),
+ FRATE(ID_NONE, "phyclk_mipi_dphy_4l_m_txbyteclkhs", NULL,
+ CLK_IS_ROOT, 18750),
+ FRATE(ID_NONE, "phyclk_dptx_phy_o_ref_clk_24m", NULL,
+ CLK_IS_ROOT, 2400),
+ FRATE(ID_NONE, "phyclk_dptx_phy_clk_div2", NULL,
+ CLK_IS_ROOT, 13500),
+ FRATE(ID_NONE, "phyclk_mipi_dphy_4l_m_rxclkesc0", NULL,
+ CLK_IS_ROOT, 2000),
+ FRATE(ID_NONE, "phyclk_usbhost20_phy_phyclock", NULL,
+ CLK_IS_ROOT, 6000),
+ FRATE(ID_NONE, "phyclk_usbhost20_phy_freeclk", NULL,
+ CLK_IS_ROOT, 6000),
+ FRATE(ID_NONE, "phyclk_usbhost20_phy_clk48mohci", NULL,
+ CLK_IS_ROOT, 4800),
+ FRATE(ID_NONE, "phyclk_usbdrd30_udrd30_pipe_pclk", NULL,
+ CLK_IS_ROOT, 12500),
+ FRATE(ID_NONE, "phyclk_usbdrd30_udrd30_phyclock", NULL,
+ CLK_IS_ROOT, 6000),
Are these really fixed rate clocks? It looks strange, because it's a bit
unlike previous Samsung SoCs, which used to have up 5 fixed rate clocks in
average.
These are outputs of various phys. If these are removed we will be left with
many orphan clocks.
OK. Just wanted to make sure that they are real clocks found in the SoC,
as I don't have access to Exynos 5420 datasheet yet.
+};
+
+/*
+ * List of Gate clocks for CMU_DISP
+*/
+struct samsung_gate_clock exynos5260_disp_gate_clks[] __initdata = {
+ GATE(DISP_CLK_SMMU_TV, "clk_smmu3_tv", "mout_aclk_disp_222_user",
+ EN_IP_DISP, 25, 0, 0),
+ GATE(DISP_CLK_SMMU_FIMD1M1, "clk_smmu3_fimd1m1",
+ "mout_aclk_disp_222_user",
+ EN_IP_DISP, 23, 0, 0),
+ GATE(DISP_CLK_SMMU_FIMD1M0, "clk_smmu3_fimd1m0",
+ "mout_aclk_disp_222_user",
+ EN_IP_DISP, 22, 0, 0),
+ GATE(ID_NONE, "clk_pixel_mixer", "mout_aclk_disp_222_user",
+ EN_IP_DISP, 13, CLK_IGNORE_UNUSED, 0),
+ GATE(ID_NONE, "clk_pixel_disp", "mout_aclk_disp_222_user",
+ EN_IP_DISP, 12, CLK_IGNORE_UNUSED, 0),
Why CLK_IGNORE_UNUSED?
these clocks are required for correct representation of clock tree but they are
not enabled by the drivers. like sclk_uart clock is only used for set rate and
never enable by the driver. Second category is clock like lpddr which will be
used by mif dvfs for lpddr only. These needs to left ingnored for Non lpddr
boards. I treid to kept them to minimum.
It's OK for core system peripherals, such as lpddr, monocnt, mif, drex,
intmem, etc. I'm not sure about the two display clocks. Respective
drivers should be fixed to gate them correctly, but for now maybe it's
OK to keep them enabled. However I believe it's wrong for sclk_uart's.
Looking at the code, Samsung serial driver enables selected baud clock
properl
Re: [REGRESSION] Arndale Octa panics when booting 3.14-rc1
On 4 March 2014 17:33, Tomasz Figa wrote:
> On 04.03.2014 13:01, Tushar Behera wrote:
>>
>> On 4 March 2014 16:09, Javi Merino wrote:
>>>
>>> On Tue, Mar 04, 2014 at 10:30:19AM +, Sylwester Nawrocki wrote:
On 04/03/14 11:16, Javi Merino wrote:
>
> Yes, with [1] applied I don't get a kernel panic but the kernel fails
> to boot later on with an Imprecise external abort. Removing the mdma
> nodes from the dts gets rid of that. I guess what's missing is what
> you said: clocks for the mdma devices.
Is removing mdm0 node enough to fix the boot failure, or both have to be
removed ?
>>>
>>>
>>> Actually, you it's only mdma1. Just removing the mdma1 node from the
>>> dt fixes the imprecise external abort.
>>>
>>
>> MDMA1 can support both secure and non-secure AXI transactions, the
>> actual behaviour is controlled by trustzone software. It may be the
>> case that MDMA1 is configured to be used in secure mode only, hence
>> accessing it in non-secure mode is causing the oops.
>>
>> Right now, the only solution looks like disabling this node in
>> Arndale-Octa dts file.
>>
>> --- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
>> +++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
>> @@ -354,4 +354,16 @@
>> samsung,i2s-controller = <&i2s0>;
>> samsung,audio-codec = <&i2s_stub>;
>> };
>> +
>> + amba {
>> + mdma1: mdma@11C1 {
>> + /*
>> +* MDMA1 can support both secure and non-secure
>> +* AXI transactions. When this is enabled in the
>> kernel
>> +* for boards that run in secure mode, we are
>> getting
>> +* imprecise external aborts causing the kernel to
>> oops.
>> +*/
>> + status = "disabled";
>> + };
>> + };
>>
>> If it works, I will submit this patch.
>
>
> On Exynos 4 SoCs there were two instances of MDMA1, one secure and one
> non-secure. Isn't it the case for Exynos5420 as well? If yes, the common
> DTSI could be changed to always use the non-secure one.
>
AFAICS, there is only one MDMA1 controller in Exynos5420.
> Best regards,
> Tomasz
--
Tushar Behera
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 14/21] ARM: dts: exynos4412-trats2: add panel node
On 02/28/2014 02:33 PM, Tomi Valkeinen wrote: > I have the same comment here as for the bridge chip: I would specify the > video ports/endpoints between DSI master and the panel, even if you > don't use them at the moment. > > Tomi > > I have sent my answer in bridge chip subthread. Regards Andrzej -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REGRESSION] Arndale Octa panics when booting 3.14-rc1
On 04.03.2014 13:01, Tushar Behera wrote:
On 4 March 2014 16:09, Javi Merino wrote:
On Tue, Mar 04, 2014 at 10:30:19AM +, Sylwester Nawrocki wrote:
On 04/03/14 11:16, Javi Merino wrote:
Yes, with [1] applied I don't get a kernel panic but the kernel fails
to boot later on with an Imprecise external abort. Removing the mdma
nodes from the dts gets rid of that. I guess what's missing is what
you said: clocks for the mdma devices.
Is removing mdm0 node enough to fix the boot failure, or both have to be
removed ?
Actually, you it's only mdma1. Just removing the mdma1 node from the
dt fixes the imprecise external abort.
MDMA1 can support both secure and non-secure AXI transactions, the
actual behaviour is controlled by trustzone software. It may be the
case that MDMA1 is configured to be used in secure mode only, hence
accessing it in non-secure mode is causing the oops.
Right now, the only solution looks like disabling this node in
Arndale-Octa dts file.
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -354,4 +354,16 @@
samsung,i2s-controller = <&i2s0>;
samsung,audio-codec = <&i2s_stub>;
};
+
+ amba {
+ mdma1: mdma@11C1 {
+ /*
+* MDMA1 can support both secure and non-secure
+* AXI transactions. When this is enabled in the kernel
+* for boards that run in secure mode, we are getting
+* imprecise external aborts causing the kernel to oops.
+*/
+ status = "disabled";
+ };
+ };
If it works, I will submit this patch.
On Exynos 4 SoCs there were two instances of MDMA1, one secure and one
non-secure. Isn't it the case for Exynos5420 as well? If yes, the common
DTSI could be changed to always use the non-secure one.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REGRESSION] Arndale Octa panics when booting 3.14-rc1
On 4 March 2014 16:09, Javi Merino wrote:
> On Tue, Mar 04, 2014 at 10:30:19AM +, Sylwester Nawrocki wrote:
>> On 04/03/14 11:16, Javi Merino wrote:
>> > Yes, with [1] applied I don't get a kernel panic but the kernel fails
>> > to boot later on with an Imprecise external abort. Removing the mdma
>> > nodes from the dts gets rid of that. I guess what's missing is what
>> > you said: clocks for the mdma devices.
>>
>> Is removing mdm0 node enough to fix the boot failure, or both have to be
>> removed ?
>
> Actually, you it's only mdma1. Just removing the mdma1 node from the
> dt fixes the imprecise external abort.
>
MDMA1 can support both secure and non-secure AXI transactions, the
actual behaviour is controlled by trustzone software. It may be the
case that MDMA1 is configured to be used in secure mode only, hence
accessing it in non-secure mode is causing the oops.
Right now, the only solution looks like disabling this node in
Arndale-Octa dts file.
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -354,4 +354,16 @@
samsung,i2s-controller = <&i2s0>;
samsung,audio-codec = <&i2s_stub>;
};
+
+ amba {
+ mdma1: mdma@11C1 {
+ /*
+* MDMA1 can support both secure and non-secure
+* AXI transactions. When this is enabled in the kernel
+* for boards that run in secure mode, we are getting
+* imprecise external aborts causing the kernel to oops.
+*/
+ status = "disabled";
+ };
+ };
If it works, I will submit this patch.
>> Unfortunately I don't access to exynos5420 datasheet at the moment, I've
>> added guys from Samsung Linaro Landing Team at cc, hopefully they can
>> provide a patch for the clocks driver to fix this.
>
> Thanks,
> Javi
>
>> > 8<---
>> > [8.06] mmc_host mmc0: Bus speed (slot 0) = 5000Hz (slot req
>> > 5200Hz, actual 5000HZ d)
>> > [8.07] Registering SWP/SWPB emulation handler
>> > [8.075000] s3c-rtc 101e.rtc: setting system clock to 2000-01-01
>> > 00:00:00 UTC (946684800)
>> > [8.08] mmc_host mmc0: Bus speed (slot 0) = 1Hz (slot req
>> > 5200Hz, actual 5000HZ )
>> > [8.09] Freeing unused kernel memory: 220K (c04c1000 - c04f8000)
>> > [8.10] Unhandled fault: imprecise external abort (0x1406) at
>> > 0x
>> > [8.105000] mmc0: new high speed DDR MMC card at address 0001
>> > [8.11] mmcblk0: mmc0:0001 M4G1FB 3.64 GiB
>> > [8.115000] mmcblk0boot0: mmc0:0001 M4G1FB partition 1 1.00 MiB
>> > [8.12] mmcblk0boot1: mmc0:0001 M4G1FB partition 2 1.00 MiB
>> > [8.125000] mmcblk0rpmb: mmc0:0001 M4G1FB partition 3 128 KiB
>> > [8.135000] mmcblk0: p1 p2 p3 p4
>> > [8.14] Kernel panic - not syncing: Attempted to kill init!
>> > exitcode=0x0007
>> > [8.14]
>> > [8.14] CPU: 0 PID: 1 Comm: init Not tainted
>> > 3.14.0-rc5-2-g691b10f #189
>> > [8.14] [] (unwind_backtrace) from []
>> > (show_stack+0x10/0x14)
>> > [8.14] [] (show_stack) from []
>> > (dump_stack+0x64/0xb4)
>> > [8.14] [] (dump_stack) from []
>> > (panic+0x8c/0x1dc)
>> > [8.14] [] (panic) from [] (do_exit+0x80c/0x8b8)
>> > [8.14] [] (do_exit) from []
>> > (do_group_exit+0x3c/0xb0)
>> > [8.14] [] (do_group_exit) from []
>> > (get_signal_to_deliver+0x278/0x500)
>> > [8.14] [] (get_signal_to_deliver) from []
>> > (do_signal+0x78/0x398)
>> > [8.14] [] (do_signal) from []
>> > (do_work_pending+0x64/0xac)
>> > [8.14] [] (do_work_pending) from []
>> > (work_pending+0xc/0x20)
>> > 8<---
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Tushar Behera
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 19/21] ARM: dts: exynos5250-arndale: add dsi and panel nodes
On 02/28/2014 02:39 PM, Tomi Valkeinen wrote: > On 28/02/14 15:31, Tomi Valkeinen wrote: > >> Compared to what I've done on OMAP, you don't seem to specify the video >> inputs for the tc358764 at all. In this case it's obvious, as the chip >> is a child of the DSI master. But the chip could as well be controlled >> via i2c, and so be placed as a child of the i2c nodes. >> >> So even if the driver doesn't use it, maybe it would be more future >> proof to have both input and output endpoints for the tc358764? > Oh, and one addition: how me and Laurent see the DSI case (and other > similar ones), the child/parent relationship gives the control bus path, > and the video ports give the video data path. > > So both are always needed. A DSI panel may be controlled via DSI, i2c, > spi, but the video path will always go from DSI master to the panel. I have made video path binding optional, in case of video bus if the specific video path is not present driver uses the bus it is connected to. In case DSI panel is controlled via different bus the path should be specified explicitly. I have no strong feelings against making this binding required but as you have stated above "in this case it's obvious" and for me quite redundant. What is the gain in specifying explicitly video paths in such cases? > Or, as a theoretical panel, you could have a DSI controlled panel, being > a child of the DSI master, but the video data would come via, say, > parallel RGB. You can actually do that with some panels/encoders, even > if the concept is silly. In this case explicit binding will work also. Regards Andrzej -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/5] clk/samsung: add support for pll2550xx
From: Pankaj Dubey
exynos5260 use pll2550xx and it has different bit fields
for P,M,S values as compared to pll2550. Support for
pll2550xx is added here.
Signed-off-by: Pankaj Dubey
Signed-off-by: Rahul Sharma
Signed-off-by: Arun Kumar K
---
drivers/clk/samsung/clk-pll.c | 107 +
drivers/clk/samsung/clk-pll.h |1 +
2 files changed, 108 insertions(+)
diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
index 1f310be..3eb2788 100644
--- a/drivers/clk/samsung/clk-pll.c
+++ b/drivers/clk/samsung/clk-pll.c
@@ -947,6 +947,108 @@ struct clk * __init samsung_clk_register_pll2550x(const
char *name,
return clk;
}
+/*
+ * PLL2550xx Clock Type
+ */
+
+/* Maximum lock time can be 270 * PDIV cycles */
+#define PLL2550XX_LOCK_FACTOR 270
+
+#define PLL2550XX_M_MASK 0x3FF
+#define PLL2550XX_P_MASK 0x3F
+#define PLL2550XX_S_MASK 0x7
+#define PLL2550XX_LOCK_STAT_MASK 0x1
+#define PLL2550XX_M_SHIFT 9
+#define PLL2550XX_P_SHIFT 3
+#define PLL2550XX_S_SHIFT 0
+#define PLL2550XX_LOCK_STAT_SHIFT 21
+
+static unsigned long samsung_pll2550xx_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct samsung_clk_pll *pll = to_clk_pll(hw);
+ u32 mdiv, pdiv, sdiv, pll_con;
+ u64 fvco = parent_rate;
+
+ pll_con = __raw_readl(pll->con_reg);
+ mdiv = (pll_con >> PLL2550XX_M_SHIFT) & PLL2550XX_M_MASK;
+ pdiv = (pll_con >> PLL2550XX_P_SHIFT) & PLL2550XX_P_MASK;
+ sdiv = (pll_con >> PLL2550XX_S_SHIFT) & PLL2550XX_S_MASK;
+
+ fvco *= mdiv;
+ do_div(fvco, (pdiv << sdiv));
+
+ return (unsigned long)fvco;
+}
+
+static inline bool samsung_pll2550xx_mp_change(u32 mdiv, u32 pdiv, u32 pll_con)
+{
+ u32 old_mdiv, old_pdiv;
+
+ old_mdiv = (pll_con >> PLL2550XX_M_SHIFT) & PLL2550XX_M_MASK;
+ old_pdiv = (pll_con >> PLL2550XX_P_SHIFT) & PLL2550XX_P_MASK;
+
+ return mdiv != old_mdiv || pdiv != old_pdiv;
+}
+
+static int samsung_pll2550xx_set_rate(struct clk_hw *hw, unsigned long drate,
+ unsigned long prate)
+{
+ struct samsung_clk_pll *pll = to_clk_pll(hw);
+ const struct samsung_pll_rate_table *rate;
+ u32 tmp;
+
+ /* Get required rate settings from table */
+ rate = samsung_get_pll_settings(pll, drate);
+ if (!rate) {
+ pr_err("%s: Invalid rate : %lu for pll clk %s\n", __func__,
+ drate, __clk_get_name(hw->clk));
+ return -EINVAL;
+ }
+
+ tmp = __raw_readl(pll->con_reg);
+
+ if (!(samsung_pll2550xx_mp_change(rate->mdiv, rate->pdiv, tmp))) {
+ /* If only s change, change just s value only*/
+ tmp &= ~(PLL2550XX_S_MASK << PLL2550XX_S_SHIFT);
+ tmp |= rate->sdiv << PLL2550XX_S_SHIFT;
+ __raw_writel(tmp, pll->con_reg);
+
+ return 0;
+ }
+
+ /* Set PLL lock time. */
+ __raw_writel(rate->pdiv * PLL2550XX_LOCK_FACTOR, pll->lock_reg);
+
+ /* Change PLL PMS values */
+ tmp &= ~((PLL2550XX_M_MASK << PLL2550XX_M_SHIFT) |
+ (PLL2550XX_P_MASK << PLL2550XX_P_SHIFT) |
+ (PLL2550XX_S_MASK << PLL2550XX_S_SHIFT));
+ tmp |= (rate->mdiv << PLL2550XX_M_SHIFT) |
+ (rate->pdiv << PLL2550XX_P_SHIFT) |
+ (rate->sdiv << PLL2550XX_S_SHIFT);
+ __raw_writel(tmp, pll->con_reg);
+
+ /* wait_lock_time */
+ do {
+ cpu_relax();
+ tmp = __raw_readl(pll->con_reg);
+ } while (!(tmp & (PLL2550XX_LOCK_STAT_MASK
+ << PLL2550XX_LOCK_STAT_SHIFT)));
+
+ return 0;
+}
+
+static const struct clk_ops samsung_pll2550xx_clk_ops = {
+ .recalc_rate = samsung_pll2550xx_recalc_rate,
+ .round_rate = samsung_pll_round_rate,
+ .set_rate = samsung_pll2550xx_set_rate,
+};
+
+static const struct clk_ops samsung_pll2550xx_clk_min_ops = {
+ .recalc_rate = samsung_pll2550xx_recalc_rate,
+};
+
static void __init _samsung_clk_register_pll(struct samsung_clk_provider *ctx,
struct samsung_pll_clock *pll_clk,
void __iomem *base)
@@ -1048,6 +1150,11 @@ static void __init _samsung_clk_register_pll(struct
samsung_clk_provider *ctx,
init.ops = &samsung_s3c2440_mpll_clk_min_ops;
else
init.ops = &samsung_s3c2440_mpll_clk_ops;
+ case pll_2550xx:
+ if (!pll->rate_table)
+ init.ops = &samsung_pll2550xx_clk_min_ops;
+ else
+ init.ops = &samsung_pll2550xx_clk_ops;
break;
default:
pr_warn("%s: Unknown pll type for pll clk %s\n",
diff --git a/drivers/clk/
[PATCH v4 3/5] clk/samsung: add support for pll2650xx
Add support for pll2650xx in samsung pll file. This pll variant
is close to pll36xx but uses CON2 registers instead of CON1.
Aud_pll in Exynos5260 is pll2650xx and uses this code.
Signed-off-by: Rahul Sharma
---
drivers/clk/samsung/clk-pll.c | 101 +
drivers/clk/samsung/clk-pll.h |1 +
2 files changed, 102 insertions(+)
diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
index 3eb2788..e251605 100644
--- a/drivers/clk/samsung/clk-pll.c
+++ b/drivers/clk/samsung/clk-pll.c
@@ -1049,6 +1049,101 @@ static const struct clk_ops
samsung_pll2550xx_clk_min_ops = {
.recalc_rate = samsung_pll2550xx_recalc_rate,
};
+/*
+ * PLL2650XX Clock Type
+ */
+
+/* Maximum lock time can be 3000 * PDIV cycles */
+#define PLL2650XX_LOCK_FACTOR 3000
+
+#define PLL2650XX_MDIV_SHIFT 9
+#define PLL2650XX_PDIV_SHIFT 3
+#define PLL2650XX_SDIV_SHIFT 0
+#define PLL2650XX_KDIV_SHIFT 0
+#define PLL2650XX_MDIV_MASK0x1ff
+#define PLL2650XX_PDIV_MASK0x3f
+#define PLL2650XX_SDIV_MASK0x7
+#define PLL2650XX_KDIV_MASK0x
+#define PLL2650XX_PLL_ENABLE_SHIFT 23
+#define PLL2650XX_PLL_LOCKTIME_SHIFT 21
+#define PLL2650XX_PLL_FOUTMASK_SHIFT 31
+
+static unsigned long samsung_pll2650xx_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct samsung_clk_pll *pll = to_clk_pll(hw);
+ u32 mdiv, pdiv, sdiv, pll_con0, pll_con2;
+ s16 kdiv;
+ u64 fvco = parent_rate;
+
+ pll_con0 = __raw_readl(pll->con_reg);
+ pll_con2 = __raw_readl(pll->con_reg + 8);
+ mdiv = (pll_con0 >> PLL2650XX_MDIV_SHIFT) & PLL2650XX_MDIV_MASK;
+ pdiv = (pll_con0 >> PLL2650XX_PDIV_SHIFT) & PLL2650XX_PDIV_MASK;
+ sdiv = (pll_con0 >> PLL2650XX_SDIV_SHIFT) & PLL2650XX_SDIV_MASK;
+ kdiv = (s16)(pll_con2 & PLL2650XX_KDIV_MASK);
+
+ fvco *= (mdiv << 16) + kdiv;
+ do_div(fvco, (pdiv << sdiv));
+ fvco >>= 16;
+
+ return (unsigned long)fvco;
+}
+
+static int samsung_pll2650xx_set_rate(struct clk_hw *hw, unsigned long drate,
+ unsigned long parent_rate)
+{
+ struct samsung_clk_pll *pll = to_clk_pll(hw);
+ u32 tmp, pll_con0, pll_con2;
+ const struct samsung_pll_rate_table *rate;
+
+ rate = samsung_get_pll_settings(pll, drate);
+ if (!rate) {
+ pr_err("%s: Invalid rate : %lu for pll clk %s\n", __func__,
+ drate, __clk_get_name(hw->clk));
+ return -EINVAL;
+ }
+
+ pll_con0 = __raw_readl(pll->con_reg);
+ pll_con2 = __raw_readl(pll->con_reg + 8);
+
+/* Change PLL PMS values */
+ pll_con0 &= ~(PLL2650XX_MDIV_MASK << PLL2650XX_MDIV_SHIFT |
+ PLL2650XX_PDIV_MASK << PLL2650XX_PDIV_SHIFT |
+ PLL2650XX_SDIV_MASK << PLL2650XX_SDIV_SHIFT);
+ pll_con0 |= rate->mdiv << PLL2650XX_MDIV_SHIFT;
+ pll_con0 |= rate->pdiv << PLL2650XX_PDIV_SHIFT;
+ pll_con0 |= rate->sdiv << PLL2650XX_SDIV_SHIFT;
+ pll_con0 |= 1 << PLL2650XX_PLL_ENABLE_SHIFT;
+ pll_con0 |= 1 << PLL2650XX_PLL_FOUTMASK_SHIFT;
+
+ pll_con2 &= ~(PLL2650XX_KDIV_MASK << PLL2650XX_KDIV_SHIFT);
+ pll_con2 |= ((~(rate->kdiv) + 1) & PLL2650XX_KDIV_MASK)
+ << PLL2650XX_KDIV_SHIFT;
+
+ /* Set PLL lock time. */
+ __raw_writel(PLL2650XX_LOCK_FACTOR * rate->pdiv, pll->lock_reg);
+
+ __raw_writel(pll_con0, pll->con_reg);
+ __raw_writel(pll_con2, pll->con_reg + 8);
+
+ do {
+ tmp = __raw_readl(pll->con_reg);
+ } while (!(tmp & (0x1 << PLL2650XX_PLL_LOCKTIME_SHIFT)));
+
+ return 0;
+}
+
+static const struct clk_ops samsung_pll2650xx_clk_ops = {
+ .recalc_rate = samsung_pll2650xx_recalc_rate,
+ .set_rate = samsung_pll2650xx_set_rate,
+ .round_rate = samsung_pll_round_rate,
+};
+
+static const struct clk_ops samsung_pll2650xx_clk_min_ops = {
+ .recalc_rate = samsung_pll2650xx_recalc_rate,
+};
+
static void __init _samsung_clk_register_pll(struct samsung_clk_provider *ctx,
struct samsung_pll_clock *pll_clk,
void __iomem *base)
@@ -1156,6 +1251,12 @@ static void __init _samsung_clk_register_pll(struct
samsung_clk_provider *ctx,
else
init.ops = &samsung_pll2550xx_clk_ops;
break;
+ case pll_2650xx:
+ if (!pll->rate_table)
+ init.ops = &samsung_pll2650xx_clk_min_ops;
+ else
+ init.ops = &samsung_pll2650xx_clk_ops;
+ break;
default:
pr_warn("%s: Unknown pll type for pll clk %s\n",
__func__, pll_clk->name);
diff --git a/drivers/clk/samsung/clk-pll.h b/drivers/clk/samsung/clk-pll.h
in
[PATCH v4 4/5] clk/exynos5260: add macros and documentation for exynos5260
Add macros which are used as Clock IDs in DT and clock file.
It also adds the documentation for the exynos5260 clocks.
Signed-off-by: Rahul Sharma
---
.../devicetree/bindings/clock/exynos5260-clock.txt | 55 +
include/dt-bindings/clk/exynos5260-clk.h | 233
2 files changed, 288 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/exynos5260-clock.txt
create mode 100644 include/dt-bindings/clk/exynos5260-clk.h
diff --git a/Documentation/devicetree/bindings/clock/exynos5260-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5260-clock.txt
new file mode 100644
index 000..4128892
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/exynos5260-clock.txt
@@ -0,0 +1,55 @@
+* Samsung Exynos5260 Clock Controller
+
+The Exynos5260 clock controller encapsulate all CMUs which are
+instantiaited independently from the device-tree. As a whole, these
+CMUs generates and supplies clocks to various controllers within
+the Exynos5260 SoC.
+
+Required Properties:
+
+- compatible: should be one of the following.
+ "exynos5260-clock-top"
+ "exynos5260-clock-peri"
+ "exynos5260-clock-egl"
+ "exynos5260-clock-kfc"
+ "exynos5260-clock-g2d"
+ "exynos5260-clock-mif"
+ "exynos5260-clock-mfc"
+ "exynos5260-clock-g3d"
+ "exynos5260-clock-fsys"
+ "exynos5260-clock-aud"
+ "exynos5260-clock-isp"
+ "exynos5260-clock-gscl"
+ "exynos5260-clock-disp"
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- #clock-cells: should be 1.
+
+The following is the list of clocks generated by the each controller. Each
+clock is assigned a MACRO constant. These constants are defined in
+"dt-bindings/clk/exynos5260-clk.h". DT client nodes use this MACRO to
+specify the clock which they consume.
+
+Example 1: An example of a clock controller node is listed below.
+
+ cmu_disp: clock-controller@0x1455 {
+ compatible = "exynos5260-clock-disp";
+ reg = <0x1455 0x1>;
+ #clock-cells = <1>;
+ };
+
+Example 2: UART controller node that consumes the clock generated by the
+ peri clock controller. Refer to the standard clock bindings for
+ information about 'clocks' and 'clock-names' property.
+
+ serial@12C0 {
+ compatible = "samsung,exynos4210-uart";
+ reg = <0x12C0 0x100>;
+ interrupts = <0 146 0>;
+ clocks = <&clock_peri PERI_PCLK_UART0>, <&clock_peri
PERI_SCLK_UART0>;
+ clock-names = "uart", "clk_uart_baud0";
+ status = "disabled";
+ };
+
diff --git a/include/dt-bindings/clk/exynos5260-clk.h
b/include/dt-bindings/clk/exynos5260-clk.h
new file mode 100644
index 000..4dc20a8
--- /dev/null
+++ b/include/dt-bindings/clk/exynos5260-clk.h
@@ -0,0 +1,233 @@
+/*
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ *
+ * 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.
+ *
+ * Provides Constants for Exynos5260 clocks.
+*/
+
+#ifndef _DT_BINDINGS_CLK_EXYNOS5260_H
+#define _DT_BINDINGS_CLK_EXYNOS5260_H
+
+/*
+ * Clock names: XX_Y_Z
+ *|--| || ||
+ * cmu type IP
+*/
+
+/* list of clocks for CMU_TOP */
+#defineFIN_PLL 1
+#defineTOP_FOUT_DISP_PLL 2
+#defineTOP_FOUT_AUD_PLL3
+#defineTOP_SCLK_MMC0 4
+#defineTOP_SCLK_MMC1 5
+#defineTOP_SCLK_MMC2 6
+#defineTOP_SCLK_HDMIPHY7
+#defineTOP_SCLK_FIMD1 8
+#defineTOP_MOUT_FIMD1 9
+#defineTOP_MOUT_DISP_PLL 10
+#defineTOP_HDMI_PHY_PIXEL_CLKO 11
+#defineTOP_NR_CLK 12
+
+/* list of clocks for CMU_EGL */
+#defineEGL_FOUT_EGL_PLL1
+#defineEGL_FOUT_EGL_DPLL 2
+#defineEGL_NR_CLK 3
+
+/* list of clocks for CMU_KFC */
+#defineKFC_FOUT_KFC_PLL1
+#defineKFC_NR_CLK 2
+
+/* list of clocks for CMU_MIF */
+#defineMIF_FOUT_MEM_PLL1
+#defineMIF_FOUT_BUS_PLL2
+#defineMIF_FOUT_MEDIA_PLL 3
+#defineMIF_NR_CLK 4
+
+/* list of clocks for CMU_G3D */
+#defineG3D_FOUT_G3D_PLL1
+#defineG3D_CLK_G3D_HPM 2
+#defineG3D_CLK_G3D 3
+#defineG3D_NR_CLK 4
+
+/* list of clocks for CMU_AUD */
+#defineAUD_CLK_AUD_UART1
+#defineAUD_CLK_PCM 2
+#defineAUD_CLK_I2S 3
+#defineAUD_CLK_DMAC4
+#defineAUD_SCLK_AUD_UART 5
+#defineAUD_SCLK_PCM6
+#def
[PATCH v4 1/5] clk/samsung: add support for multiple clock providers
Samsung CCF helper functions do not provide support to
register multiple Clock Providers for a given SoC. Due to
this limitation SoC platforms are not able to use these
helpers for registering multiple clock providers and are
forced to bypass this layer.
This layer is modified accordingly to enable the support.
Clock file for exynos4, exynos5250, exynos5420, exynos5440
and S3c64xx are also modified as per changed helper functions.
Signed-off-by: Rahul Sharma
---
drivers/clk/samsung/clk-exynos4.c| 47 +++---
drivers/clk/samsung/clk-exynos5250.c | 25 +---
drivers/clk/samsung/clk-exynos5420.c | 24 ---
drivers/clk/samsung/clk-exynos5440.c | 18 +++---
drivers/clk/samsung/clk-pll.c| 14 +++--
drivers/clk/samsung/clk-s3c64xx.c| 44 +++--
drivers/clk/samsung/clk.c| 115 +++---
drivers/clk/samsung/clk.h| 72 ++---
8 files changed, 210 insertions(+), 149 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos4.c
b/drivers/clk/samsung/clk-exynos4.c
index b4f9672..57ed5a8 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -1043,7 +1043,7 @@ static unsigned long exynos4_get_xom(void)
return xom;
}
-static void __init exynos4_clk_register_finpll(void)
+static void __init exynos4_clk_register_finpll(struct samsung_clk_provider
*ctx)
{
struct samsung_fixed_rate_clock fclk;
struct clk *clk;
@@ -1066,7 +1066,7 @@ static void __init exynos4_clk_register_finpll(void)
fclk.parent_name = NULL;
fclk.flags = CLK_IS_ROOT;
fclk.fixed_rate = finpll_f;
- samsung_clk_register_fixed_rate(&fclk, 1);
+ samsung_clk_register_fixed_rate(ctx, &fclk, 1);
}
@@ -1176,22 +1176,25 @@ static struct samsung_pll_clock
exynos4x12_plls[nr_plls] __initdata = {
static void __init exynos4_clk_init(struct device_node *np,
enum exynos4_soc soc)
{
+ struct samsung_clk_provider *ctx;
exynos4_soc = soc;
reg_base = of_iomap(np, 0);
if (!reg_base)
panic("%s: failed to map registers\n", __func__);
- samsung_clk_init(np, reg_base, CLK_NR_CLKS);
+ ctx = samsung_clk_init(np, reg_base, CLK_NR_CLKS);
+ if (!ctx)
+ panic("%s: unable to allocate context.\n", __func__);
- samsung_clk_of_register_fixed_ext(exynos4_fixed_rate_ext_clks,
+ samsung_clk_of_register_fixed_ext(ctx, exynos4_fixed_rate_ext_clks,
ARRAY_SIZE(exynos4_fixed_rate_ext_clks),
ext_clk_match);
- exynos4_clk_register_finpll();
+ exynos4_clk_register_finpll(ctx);
if (exynos4_soc == EXYNOS4210) {
- samsung_clk_register_mux(exynos4210_mux_early,
+ samsung_clk_register_mux(ctx, exynos4210_mux_early,
ARRAY_SIZE(exynos4210_mux_early));
if (_get_rate("fin_pll") == 2400) {
@@ -1205,7 +1208,7 @@ static void __init exynos4_clk_init(struct device_node
*np,
exynos4210_plls[vpll].rate_table =
exynos4210_vpll_rates;
- samsung_clk_register_pll(exynos4210_plls,
+ samsung_clk_register_pll(ctx, exynos4210_plls,
ARRAY_SIZE(exynos4210_plls), reg_base);
} else {
if (_get_rate("fin_pll") == 2400) {
@@ -1217,42 +1220,42 @@ static void __init exynos4_clk_init(struct device_node
*np,
exynos4x12_vpll_rates;
}
- samsung_clk_register_pll(exynos4x12_plls,
+ samsung_clk_register_pll(ctx, exynos4x12_plls,
ARRAY_SIZE(exynos4x12_plls), reg_base);
}
- samsung_clk_register_fixed_rate(exynos4_fixed_rate_clks,
+ samsung_clk_register_fixed_rate(ctx, exynos4_fixed_rate_clks,
ARRAY_SIZE(exynos4_fixed_rate_clks));
- samsung_clk_register_mux(exynos4_mux_clks,
+ samsung_clk_register_mux(ctx, exynos4_mux_clks,
ARRAY_SIZE(exynos4_mux_clks));
- samsung_clk_register_div(exynos4_div_clks,
+ samsung_clk_register_div(ctx, exynos4_div_clks,
ARRAY_SIZE(exynos4_div_clks));
- samsung_clk_register_gate(exynos4_gate_clks,
+ samsung_clk_register_gate(ctx, exynos4_gate_clks,
ARRAY_SIZE(exynos4_gate_clks));
if (exynos4_soc == EXYNOS4210) {
- samsung_clk_register_fixed_rate(exynos4210_fixed_rate_clks,
+ samsung_clk_register_fixed_rate(ctx, exynos4210_fixed_rate_clks,
ARRAY_SIZE(exynos4210_fixed_rate_clks));
- samsung_clk_register_mux(exynos4210_mux_clks,
+ samsung_clk_register_mux
[PATCH v4 0/5] clk: exynos: add support for exynos5260 SoC
From: Rahul Sharma
Add clock support for exynos5260 SoC.
This series is based on Kukjin's for-next and
Mike's clk-next branches.
V4:
1) Rework clock file as per Tomasz review comments at
http://www.spinics.net/lists/arm-kernel/msg310116.html.
V3:
1) Removed "samsung,exynos5260-clock" property from clock files.
2) Replaced "__SPIN_LOCK_UNLOCKED(lock)" with spin_lock_init.
3) Removed '(' and ')' around numeric constants in macros.
V2:
1) Move suspend resume handling to Exynos5410 Clock file.
2) Removed Unused Macros and Condition checks for Exynos5260.
3) Add spin lock to clock provider context.
4) Add clock provider context for Exynos5410.
5) Uniform implementation for callbacks for PLL2550xx.
6) Split Exynos5260 clock file patch to bring it under 100 Kb limit.
7) Replace aclk/pclk/hclk gates with combined gates.
8) Remove CLK_IGNORE_UNUSED flag for gate clocks.
Pankaj Dubey (1):
clk/samsung: add support for pll2550xx
Rahul Sharma (4):
clk/samsung: add support for multiple clock providers
clk/samsung: add support for pll2650xx
clk/exynos5260: add macros and documentation for exynos5260
clk/exynos5260: add clock file for exynos5260
.../devicetree/bindings/clock/exynos5260-clock.txt | 55 +
drivers/clk/samsung/Makefile |1 +
drivers/clk/samsung/clk-exynos4.c | 47 +-
drivers/clk/samsung/clk-exynos5250.c | 25 +-
drivers/clk/samsung/clk-exynos5260.c | 1933
drivers/clk/samsung/clk-exynos5260.h | 448 +
drivers/clk/samsung/clk-exynos5420.c | 24 +-
drivers/clk/samsung/clk-exynos5440.c | 18 +-
drivers/clk/samsung/clk-pll.c | 222 ++-
drivers/clk/samsung/clk-pll.h |2 +
drivers/clk/samsung/clk-s3c64xx.c | 44 +-
drivers/clk/samsung/clk.c | 115 +-
drivers/clk/samsung/clk.h | 72 +-
include/dt-bindings/clk/exynos5260-clk.h | 233 +++
14 files changed, 3090 insertions(+), 149 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/exynos5260-clock.txt
create mode 100644 drivers/clk/samsung/clk-exynos5260.c
create mode 100644 drivers/clk/samsung/clk-exynos5260.h
create mode 100644 include/dt-bindings/clk/exynos5260-clk.h
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REGRESSION] Arndale Octa panics when booting 3.14-rc1
On Tue, Mar 04, 2014 at 10:30:19AM +, Sylwester Nawrocki wrote: > On 04/03/14 11:16, Javi Merino wrote: > > Yes, with [1] applied I don't get a kernel panic but the kernel fails > > to boot later on with an Imprecise external abort. Removing the mdma > > nodes from the dts gets rid of that. I guess what's missing is what > > you said: clocks for the mdma devices. > > Is removing mdm0 node enough to fix the boot failure, or both have to be > removed ? Actually, you it's only mdma1. Just removing the mdma1 node from the dt fixes the imprecise external abort. > Unfortunately I don't access to exynos5420 datasheet at the moment, I've > added guys from Samsung Linaro Landing Team at cc, hopefully they can > provide a patch for the clocks driver to fix this. Thanks, Javi > > 8<--- > > [8.06] mmc_host mmc0: Bus speed (slot 0) = 5000Hz (slot req > > 5200Hz, actual 5000HZ d) > > [8.07] Registering SWP/SWPB emulation handler > > [8.075000] s3c-rtc 101e.rtc: setting system clock to 2000-01-01 > > 00:00:00 UTC (946684800) > > [8.08] mmc_host mmc0: Bus speed (slot 0) = 1Hz (slot req > > 5200Hz, actual 5000HZ ) > > [8.09] Freeing unused kernel memory: 220K (c04c1000 - c04f8000) > > [8.10] Unhandled fault: imprecise external abort (0x1406) at > > 0x > > [8.105000] mmc0: new high speed DDR MMC card at address 0001 > > [8.11] mmcblk0: mmc0:0001 M4G1FB 3.64 GiB > > [8.115000] mmcblk0boot0: mmc0:0001 M4G1FB partition 1 1.00 MiB > > [8.12] mmcblk0boot1: mmc0:0001 M4G1FB partition 2 1.00 MiB > > [8.125000] mmcblk0rpmb: mmc0:0001 M4G1FB partition 3 128 KiB > > [8.135000] mmcblk0: p1 p2 p3 p4 > > [8.14] Kernel panic - not syncing: Attempted to kill init! > > exitcode=0x0007 > > [8.14] > > [8.14] CPU: 0 PID: 1 Comm: init Not tainted > > 3.14.0-rc5-2-g691b10f #189 > > [8.14] [] (unwind_backtrace) from [] > > (show_stack+0x10/0x14) > > [8.14] [] (show_stack) from [] > > (dump_stack+0x64/0xb4) > > [8.14] [] (dump_stack) from [] > > (panic+0x8c/0x1dc) > > [8.14] [] (panic) from [] (do_exit+0x80c/0x8b8) > > [8.14] [] (do_exit) from [] > > (do_group_exit+0x3c/0xb0) > > [8.14] [] (do_group_exit) from [] > > (get_signal_to_deliver+0x278/0x500) > > [8.14] [] (get_signal_to_deliver) from [] > > (do_signal+0x78/0x398) > > [8.14] [] (do_signal) from [] > > (do_work_pending+0x64/0xac) > > [8.14] [] (do_work_pending) from [] > > (work_pending+0xc/0x20) > > 8<--- -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REGRESSION] Arndale Octa panics when booting 3.14-rc1
On 04/03/14 11:16, Javi Merino wrote: > Yes, with [1] applied I don't get a kernel panic but the kernel fails > to boot later on with an Imprecise external abort. Removing the mdma > nodes from the dts gets rid of that. I guess what's missing is what > you said: clocks for the mdma devices. Is removing mdm0 node enough to fix the boot failure, or both have to be removed ? Unfortunately I don't access to exynos5420 datasheet at the moment, I've added guys from Samsung Linaro Landing Team at cc, hopefully they can provide a patch for the clocks driver to fix this. > 8<--- > [8.06] mmc_host mmc0: Bus speed (slot 0) = 5000Hz (slot req > 5200Hz, actual 5000HZ d) > [8.07] Registering SWP/SWPB emulation handler > [8.075000] s3c-rtc 101e.rtc: setting system clock to 2000-01-01 > 00:00:00 UTC (946684800) > [8.08] mmc_host mmc0: Bus speed (slot 0) = 1Hz (slot req > 5200Hz, actual 5000HZ ) > [8.09] Freeing unused kernel memory: 220K (c04c1000 - c04f8000) > [8.10] Unhandled fault: imprecise external abort (0x1406) at > 0x > [8.105000] mmc0: new high speed DDR MMC card at address 0001 > [8.11] mmcblk0: mmc0:0001 M4G1FB 3.64 GiB > [8.115000] mmcblk0boot0: mmc0:0001 M4G1FB partition 1 1.00 MiB > [8.12] mmcblk0boot1: mmc0:0001 M4G1FB partition 2 1.00 MiB > [8.125000] mmcblk0rpmb: mmc0:0001 M4G1FB partition 3 128 KiB > [8.135000] mmcblk0: p1 p2 p3 p4 > [8.14] Kernel panic - not syncing: Attempted to kill init! > exitcode=0x0007 > [8.14] > [8.14] CPU: 0 PID: 1 Comm: init Not tainted 3.14.0-rc5-2-g691b10f > #189 > [8.14] [] (unwind_backtrace) from [] > (show_stack+0x10/0x14) > [8.14] [] (show_stack) from [] > (dump_stack+0x64/0xb4) > [8.14] [] (dump_stack) from [] (panic+0x8c/0x1dc) > [8.14] [] (panic) from [] (do_exit+0x80c/0x8b8) > [8.14] [] (do_exit) from [] > (do_group_exit+0x3c/0xb0) > [8.14] [] (do_group_exit) from [] > (get_signal_to_deliver+0x278/0x500) > [8.14] [] (get_signal_to_deliver) from [] > (do_signal+0x78/0x398) > [8.14] [] (do_signal) from [] > (do_work_pending+0x64/0xac) > [8.14] [] (do_work_pending) from [] > (work_pending+0xc/0x20) > 8<--- > > [1] > https://git.linaro.org/people/mike.turquette/linux.git/commit/00efcb1c8e1c3c5e5d3ce6f0682d66402911a84f -- Regards, Sylwester -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v3 2/5] cpufreq:LAB:cpufreq_governor Adjust cpufreq_governor.[h|c] to support LAB
Some minor adjustments were needed to support LAB operation in the
cpufreq_governor.[h|c] files.
Most notably, code for proper estimation of the idle time for each CPU is
added here.
Signed-off-by: Lukasz Majewski
Signed-off-by: MyungJoo Ham
---
drivers/cpufreq/cpufreq_governor.c |7 +++
drivers/cpufreq/cpufreq_governor.h |2 ++
2 files changed, 9 insertions(+)
diff --git a/drivers/cpufreq/cpufreq_governor.c
b/drivers/cpufreq/cpufreq_governor.c
index ba43991..99fc3e8 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -98,6 +98,13 @@ void dbs_check_cpu(struct dbs_data *dbs_data, int cpu)
load = 100 * (wall_time - idle_time) / wall_time;
+ if (dbs_data->cdata->governor == GOV_LAB) {
+ struct od_cpu_dbs_info_s *od_dbs_info =
+ dbs_data->cdata->get_cpu_dbs_info_s(j);
+
+ od_dbs_info->idle_time = (100 * idle_time) / wall_time;
+ }
+
if (load > max_load)
max_load = load;
}
diff --git a/drivers/cpufreq/cpufreq_governor.h
b/drivers/cpufreq/cpufreq_governor.h
index 34b1cf2..82a519f 100644
--- a/drivers/cpufreq/cpufreq_governor.h
+++ b/drivers/cpufreq/cpufreq_governor.h
@@ -152,6 +152,7 @@ struct od_cpu_dbs_info_s {
unsigned int freq_lo_jiffies;
unsigned int freq_hi_jiffies;
unsigned int rate_mult;
+ unsigned int idle_time;
unsigned int sample_type:1;
};
@@ -187,6 +188,7 @@ struct common_dbs_data {
/* Common across governors */
#define GOV_ONDEMAND0
#define GOV_CONSERVATIVE1
+ #define GOV_LAB 2
int governor;
struct attribute_group *attr_group_gov_sys; /* one governor - system */
struct attribute_group *attr_group_gov_pol; /* one governor - policy */
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v3 5/5] cpufreq:LAB:dts:trats2: Add DTS nodes for LAB governor
Adds LAB attributes to proper CPU0 node.
The lab-num-of-states attribute shows how many compartments will be used.
The LAB code is prepared to be more fine grained.
The lab-ctrl-freq defines how the LAB governor will be controlled:
- 0xFFFE- use the minimal frequency
- 0x- enable boost
- non zero - set the frequency specified
- zero - use ondemand to specify output frequency
Signed-off-by: Lukasz Majewski
Signed-off-by: MyungJoo Ham
---
arch/arm/boot/dts/exynos4412-trats2.dts | 29 +
1 file changed, 29 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 4f851cc..9eeeb38 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -511,6 +511,35 @@
};
};
+ cpus {
+ cpu@0 {
+ compatible = "arm,cortex-a9";
+ device_type = "cpu";
+ lab-num-of-states = <5>;
+ lab-ctrl-freq = < 0 0 0
130120
+ 0 0 0 0
130
+ 0 0 0 0
0x
+ 0 0 0
0x 0x
+ 0xFFFE 0xFFFE 0xFFFE
0xFFFE 0xFFFE
+ >;
+ };
+
+ cpu@1 {
+ compatible = "arm,cortex-a9";
+ device_type = "cpu";
+ };
+
+ cpu@2 {
+ compatible = "arm,cortex-a9";
+ device_type = "cpu";
+ };
+
+ cpu@3 {
+ compatible = "arm,cortex-a9";
+ device_type = "cpu";
+ };
+ };
+
camera {
pinctrl-0 = <&cam_port_b_clk_active>;
pinctrl-names = "default";
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v3 3/5] cpufreq:LAB:lab Add LAB governor code
This patch adds code for LAB governor. It shall be noted, that it reuses
a lot of ondemand code.
The main difference is that it works on top of ondemand, and this code is
able to "call" ondemand when needed. This means that all ondemand "backing"
data are properly updated.
Such approach has one major advantage - with LAB we can focus on saving
energy and leave the "normal" cpufreq management to well tested ondemand.
Signed-off-by: Lukasz Majewski
Signed-off-by: MyungJoo Ham
---
drivers/cpufreq/Makefile |1 +
drivers/cpufreq/cpufreq_lab.c | 457 +
2 files changed, 458 insertions(+)
create mode 100644 drivers/cpufreq/cpufreq_lab.c
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 7494565..64bff8dc 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_CPU_FREQ_GOV_POWERSAVE)+= cpufreq_powersave.o
obj-$(CONFIG_CPU_FREQ_GOV_USERSPACE) += cpufreq_userspace.o
obj-$(CONFIG_CPU_FREQ_GOV_ONDEMAND)+= cpufreq_ondemand.o
obj-$(CONFIG_CPU_FREQ_GOV_CONSERVATIVE)+= cpufreq_conservative.o
+obj-$(CONFIG_CPU_FREQ_GOV_LAB) += cpufreq_lab.o
obj-$(CONFIG_CPU_FREQ_GOV_COMMON) += cpufreq_governor.o
obj-$(CONFIG_GENERIC_CPUFREQ_CPU0) += cpufreq-cpu0.o
diff --git a/drivers/cpufreq/cpufreq_lab.c b/drivers/cpufreq/cpufreq_lab.c
new file mode 100644
index 000..153c06b
--- /dev/null
+++ b/drivers/cpufreq/cpufreq_lab.c
@@ -0,0 +1,457 @@
+/*
+ * Copyright (c) 2013-2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ * Jonghwa Lee
+ * Lukasz Majewski
+ *
+ * LAB (Legacy Application Boost) cpufreq governor
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "cpufreq_governor.h"
+
+#define MAX_HIST 5
+
+#define LB_BOOST_ENABLE~0UL
+#define LB_MIN_FREQ~1UL
+#define LB_ONDEMAND 0
+
+/*
+ * Pre-calculated summation of weight, 0.5
+ * 1
+ * 1 + 0.5^1 = 1.5
+ * 1 + 0.5^1 + 0.5^2 = 1.75
+ * 1 + 0.5^1 + 0.5^2 + 0.5^3 = 1.87
+ * 1 + 0.5^1 + 0.5^2 + 0.5^3 + 0.5^4 = 1.93
+ */
+static int history_weight_sum[] = { 100, 150, 175, 187, 193 };
+
+static unsigned int *idle_avg;
+static unsigned int *idle_hist;
+static int idle_cpus, lb_threshold = 90;
+static unsigned int *lb_ctrl_table, lb_load;
+static int lb_ctrl_table_size, lb_num_of_states;
+static bool boost_init_state;
+
+static DECLARE_BITMAP(boost_hist, MAX_HIST);
+DECLARE_PER_CPU(struct od_cpu_dbs_info_s, od_cpu_dbs_info);
+
+struct cpufreq_governor cpufreq_gov_lab;
+
+
+static struct lb_wq_boost_data {
+ bool state;
+ struct work_struct work;
+} lb_boost_data;
+
+/*
+ * Calculate average of idle time with weighting 50% less to older one.
+ * With weight, average can be affected by current phase more rapidly than
+ * normal average. And it also has tolerance for temporary fluctuation of
+ * idle time as normal average has.
+ *
+ * Weigted average = sum(ai * wi) / sum(wi)
+ */
+static inline int cpu_idle_calc_avg(unsigned int *p, int size)
+{
+ int i, sum;
+
+ for (i = 0, sum = 0; i < size; p++, i++) {
+ sum += *p;
+ *p >>= 1;
+ }
+ sum *= 100;
+
+ return (int) (sum / history_weight_sum[size - 1]);
+}
+
+static unsigned int lb_chose_freq(unsigned int load, int idle_cpus)
+{
+ unsigned int p, q = 100 / lb_num_of_states;
+ int idx;
+
+ for (idx = 0, p = q; idx < lb_num_of_states; idx++, p += q)
+ if (load <= p)
+ break;
+
+ return *(lb_ctrl_table + (lb_num_of_states * idle_cpus) + idx);
+}
+
+static void lb_cpufreq_boost_work(struct work_struct *work)
+{
+ struct lb_wq_boost_data *d = container_of(work,
+ struct lb_wq_boost_data,
+ work);
+ cpufreq_boost_trigger_state(d->state);
+}
+
+static struct common_dbs_data lb_dbs_cdata;
+/*
+ * LAB governor policy adjustement
+ */
+static void lb_check_cpu(int cpu, unsigned int load)
+{
+ struct od_cpu_dbs_info_s *dbs_info = &per_cpu(od_cpu_dbs_info, cpu);
+ struct cpufreq_policy *policy = dbs_info->cdbs.cur_policy;
+ unsigned int freq = 0, op;
+ static int cnt;
+ int i, idx, bs;
+
+ idle_cpus = 0;
+ lb_load = load;
+ idx = cnt++ % MAX_HIST;
+
+ for_each_possible_cpu(i) {
+ struct od_cpu_dbs_info_s *dbs_cpu_info =
+ &per_cpu(od_cpu_dbs_info, i);
+
+ idle_hist[i * MAX_HIST + idx] = dbs_cpu_info->idle_time;
+ idle_avg[i] = cpu_idle_cal
[RFC v3 1/5] cpufreq:LAB:ondemand Adjust ondemand to be able to reuse its methods
Ondemand code needed to be slightly adjusted to allow its reusage.
Mostly one needed to remove static qualifiers and provide some hacks to
allow its working with LAB.
Signed-off-by: Lukasz Majewski
Signed-off-by: MyungJoo Ham
---
drivers/cpufreq/cpufreq_governor.h | 10 ++
drivers/cpufreq/cpufreq_ondemand.c | 24
2 files changed, 26 insertions(+), 8 deletions(-)
diff --git a/drivers/cpufreq/cpufreq_governor.h
b/drivers/cpufreq/cpufreq_governor.h
index bfb9ae1..34b1cf2 100644
--- a/drivers/cpufreq/cpufreq_governor.h
+++ b/drivers/cpufreq/cpufreq_governor.h
@@ -270,4 +270,14 @@ void od_register_powersave_bias_handler(unsigned int (*f)
(struct cpufreq_policy *, unsigned int, unsigned int),
unsigned int powersave_bias);
void od_unregister_powersave_bias_handler(void);
+
+/* COMMON CODE FOR DEMAND BASED SWITCHING */
+void od_dbs_timer(struct work_struct *work);
+int od_init(struct dbs_data *dbs_data);
+void od_exit(struct dbs_data *dbs_data);
+void od_check_cpu(int cpu, unsigned int load_freq);
+void update_sampling_rate(struct dbs_data *dbs_data,
+ unsigned int new_rate);
+
+extern struct od_ops od_ops;
#endif /* _CPUFREQ_GOVERNOR_H */
diff --git a/drivers/cpufreq/cpufreq_ondemand.c
b/drivers/cpufreq/cpufreq_ondemand.c
index 18d4091..a27326d 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -27,9 +27,9 @@
#define MIN_FREQUENCY_UP_THRESHOLD (11)
#define MAX_FREQUENCY_UP_THRESHOLD (100)
-static DEFINE_PER_CPU(struct od_cpu_dbs_info_s, od_cpu_dbs_info);
+DEFINE_PER_CPU(struct od_cpu_dbs_info_s, od_cpu_dbs_info);
-static struct od_ops od_ops;
+struct od_ops od_ops;
#ifndef CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND
static struct cpufreq_governor cpufreq_gov_ondemand;
@@ -152,7 +152,7 @@ static void dbs_freq_increase(struct cpufreq_policy
*policy, unsigned int freq)
* (default), then we try to increase frequency. Else, we adjust the frequency
* proportional to load.
*/
-static void od_check_cpu(int cpu, unsigned int load)
+void od_check_cpu(int cpu, unsigned int load)
{
struct od_cpu_dbs_info_s *dbs_info = &per_cpu(od_cpu_dbs_info, cpu);
struct cpufreq_policy *policy = dbs_info->cdbs.cur_policy;
@@ -188,7 +188,7 @@ static void od_check_cpu(int cpu, unsigned int load)
}
}
-static void od_dbs_timer(struct work_struct *work)
+void od_dbs_timer(struct work_struct *work)
{
struct od_cpu_dbs_info_s *dbs_info =
container_of(work, struct od_cpu_dbs_info_s, cdbs.work.work);
@@ -233,6 +233,9 @@ max_delay:
/** sysfs interface /
static struct common_dbs_data od_dbs_cdata;
+#ifdef CONFIG_CPU_FREQ_GOV_LAB
+extern struct cpufreq_governor cpufreq_gov_lab;
+#endif
/**
* update_sampling_rate - update sampling rate effective immediately if needed.
* @new_rate: new sampling rate
@@ -246,7 +249,7 @@ static struct common_dbs_data od_dbs_cdata;
* reducing the sampling rate, we need to make the new value effective
* immediately.
*/
-static void update_sampling_rate(struct dbs_data *dbs_data,
+void update_sampling_rate(struct dbs_data *dbs_data,
unsigned int new_rate)
{
struct od_dbs_tuners *od_tuners = dbs_data->tuners;
@@ -263,7 +266,12 @@ static void update_sampling_rate(struct dbs_data *dbs_data,
policy = cpufreq_cpu_get(cpu);
if (!policy)
continue;
+#ifdef CONFIG_CPU_FREQ_GOV_LAB
+ if (policy->governor != &cpufreq_gov_ondemand &&
+ policy->governor != &cpufreq_gov_lab) {
+#else
if (policy->governor != &cpufreq_gov_ondemand) {
+#endif
cpufreq_cpu_put(policy);
continue;
}
@@ -472,7 +480,7 @@ static struct attribute_group od_attr_group_gov_pol = {
/** sysfs end /
-static int od_init(struct dbs_data *dbs_data)
+int od_init(struct dbs_data *dbs_data)
{
struct od_dbs_tuners *tuners;
u64 idle_time;
@@ -514,14 +522,14 @@ static int od_init(struct dbs_data *dbs_data)
return 0;
}
-static void od_exit(struct dbs_data *dbs_data)
+void od_exit(struct dbs_data *dbs_data)
{
kfree(dbs_data->tuners);
}
define_get_cpu_dbs_routines(od_cpu_dbs_info);
-static struct od_ops od_ops = {
+struct od_ops od_ops = {
.powersave_bias_init_cpu = ondemand_powersave_bias_init_cpu,
.powersave_bias_target = generic_powersave_bias_target,
.freq_increase = dbs_freq_increase,
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v3 4/5] cpufreq:LAB:Kconfig Add LAB definitions to Kconfig
Provide support for LAB governor for the Kbuild. It is important to note, that LAB is not possible to be compiled in as a module since we cannot assure (in the kernel) that backing ondemand module will not be removed without notice to LAB. For this reason the LAB can be only compiled into the kernel without possibility to be compiled as a module. Signed-off-by: Lukasz Majewski Signed-off-by: MyungJoo Ham --- drivers/cpufreq/Kconfig | 28 1 file changed, 28 insertions(+) diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig index 4b029c0..3a870ea 100644 --- a/drivers/cpufreq/Kconfig +++ b/drivers/cpufreq/Kconfig @@ -102,6 +102,18 @@ config CPU_FREQ_DEFAULT_GOV_CONSERVATIVE Be aware that not all cpufreq drivers support the conservative governor. If unsure have a look at the help section of the driver. Fallback governor will be the performance governor. + +config CPU_FREQ_DEFAULT_GOV_LAB + bool "lab" + select CPU_FREQ_GOV_LAB + select CPU_FREQ_GOV_PERFORMANCE + help + Use the CPUFreq governor 'lab' as default. This allows + you to get a full dynamic frequency capable system by simply + loading your cpufreq low-level hardware driver. + Be aware that not all cpufreq drivers support the lab governor. + If unsure have a look at the help section of the driver. + Fallback governor will be the performance governor. endchoice config CPU_FREQ_GOV_PERFORMANCE @@ -183,6 +195,22 @@ config CPU_FREQ_GOV_CONSERVATIVE If in doubt, say N. +config CPU_FREQ_GOV_LAB + bool "'lab' cpufreq policy governor - ONDEMAND extension" + select CPU_FREQ_TABLE + select CPU_FREQ_GOV_COMMON + select CPU_FREQ_GOV_ONDEMAND + help + 'lab' - This driver adds a dynamic cpufreq policy governor. + + LAB governor shall be regarded as an extension of the ONDEMAND on + platforms with very weak HW support for power management. + + LAB governor can be either compiled in or not. It is not possible to + compile it as module because of explicit ONDEMAND dependency. + + If in doubt, say N. + config GENERIC_CPUFREQ_CPU0 tristate "Generic CPU0 cpufreq driver" depends on HAVE_CLK && REGULATOR && OF && THERMAL && CPU_THERMAL -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v3 0/5] cpufreq:LAB: Support for LAB governor.
Despite this patch set is working and applicable on top of 3.14-rc5, please regard it solely as a pure RFC. This patch provides support for LAB governor build on top of ondemand. Previous version of LAB can be found here: http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq LAB short reminder: LAB uses information about how many cores are in "idle" state (the core idleness is represented as the value between 0 and 100) and the overall load of the system (from 0 to 100) to decide about frequency to be set. It is extremely useful with SoCs like Exynos4412, which can set only one frequency for all cores. Important design decisions: - Reuse well established ondemand governor's internal code. To do this I had to expose some previously static internal ondemand code. This allowed smaller LAB code when compared to previous version. - LAB works on top of ondemand, which means that one via device tree attributes can specify if and when e.g. BOOST shall be enabled or if any particular frequency shall be imposed. For situation NOT important from the power consumption reduction viewpoint the ondemand is used to set proper frequency. - It is only possible to either compile in or not the LAB into the kernel. There is no "M" option for Kconfig. It is done on purpose, since ondemand itself can be also compiled as a module and then it would be possible to remove ondemand when LAB is working on top of it. - The LAB operation is specified (and thereof extendable) via device tree lab-ctrl-freq attribute defined at /cpus/cpu0. Problems: - How the governor will work for big.LITTLE systems (especially Global Task Scheduling). - Will there be agreement to expose internal ondemand code to be reused for more specialized governors. Test HW: Exynos4412 - Trats2 board. Above patches were posted on top of Linux 3.14-rc5 (SHA1: 3f9590c281c66162bf8ae9b7b2d987f0a89043c6) Lukasz Majewski (5): cpufreq:LAB:ondemand Adjust ondemand to be able to reuse its methods cpufreq:LAB:cpufreq_governor Adjust cpufreq_governor.[h|c] to support LAB cpufreq:LAB:lab Add LAB governor code cpufreq:LAB:Kconfig Add LAB definitions to Kconfig cpufreq:LAB:dts:trats2: Add DTS nodes for LAB governor arch/arm/boot/dts/exynos4412-trats2.dts | 29 ++ drivers/cpufreq/Kconfig | 28 ++ drivers/cpufreq/Makefile|1 + drivers/cpufreq/cpufreq_governor.c |7 + drivers/cpufreq/cpufreq_governor.h | 12 + drivers/cpufreq/cpufreq_lab.c | 457 +++ drivers/cpufreq/cpufreq_ondemand.c | 24 +- 7 files changed, 550 insertions(+), 8 deletions(-) create mode 100644 drivers/cpufreq/cpufreq_lab.c -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REGRESSION] Arndale Octa panics when booting 3.14-rc1
On Mon, Mar 03, 2014 at 08:53:31PM +, Sylwester Nawrocki wrote:
> Hi,
>
> On 03/03/2014 08:04 PM, Tomasz Figa wrote:
> > On 03.03.2014 19:57, Javi Merino wrote:
> >> Hi,
> >>
> >> Commit fcb0ee6a3d (clk: Implement clk_unregister) added calls to
> >> kref_get() and kref_put() to __clk_get() and __clk_put() without
> >> checking if clk is not NULL:
> >>
> >>> @@ -1987,6 +2097,7 @@ int __clk_get(struct clk *clk)
> >>> if (clk && !try_module_get(clk->owner))
> >>> return 0;
> >>>
> >>> + kref_get(&clk->ref);
> >>> return 1;
> >>> }
> >>>
> >>> @@ -1995,6 +2106,10 @@ void __clk_put(struct clk *clk)
> >>> if (WARN_ON_ONCE(IS_ERR(clk)))
> >>> return;
> >>>
> >>> + clk_prepare_lock();
> >>> + kref_put(&clk->ref, __clk_release);
> >>> + clk_prepare_unlock();
> >>> +
> >>> if (clk)
> >>> module_put(clk->owner);
> >>> }
> >>
> >> Before this commit, these functions allowed clk to be NULL. In
> >> particular, the "if (clk)" in __clk_put() is now useless, as clk has
> >> been dereferenced by the time you reach it.
> >>
> >> This causes Arndale Octa to panic on boot:
> >>
> >> 8<---
> >> [7.43] Creating amba device /amba/pdma@121B
> >> [7.435000]create child: /amba/mdma@1080
> >> [7.44] Creating amba device /amba/mdma@1080
> >> [7.445000] Unable to handle kernel NULL pointer dereference at
> >> virtual address 0050
> >>
> >> [7.45] pgd = c0004000
> >> [7.45] [0050] *pgd=
> >> [7.455000] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
> >> [7.455000] Modules linked in:
> >> [7.455000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> >> 3.14.0-rc3-3-gb6026fe-dirty #23
> >>
> >> [7.455000] task: ee0a8000 ti: ee0a6000 task.ti: ee0a6000
> >> [7.455000] PC is at __clk_get+0x24/0x84
> >> [7.455000] LR is at of_clk_get+0x5c/0x74
> [...]
> >>
> >> [7.455000] [] (__clk_get) from []
> >> (of_clk_get+0x5c/0x74)
> >>
> >> [7.455000] [] (of_clk_get) from []
> >> (of_clk_get_by_name+0x3c/0xb0)
> >>
> >> [7.455000] [] (of_clk_get_by_name) from []
> >> (clk_get+0x24/0x44)
> >>
> >> [7.455000] [] (clk_get) from []
> >> (amba_get_enable_pclk+0x10/0x60)
> >>
> >> [7.455000] [] (amba_get_enable_pclk) from []
> >> (amba_device_add+0xa0/0x1e0)
> >>
> >> [7.455000] [] (amba_device_add) from []
> >> (of_platform_bus_create+0x190/0x308)
> >>
> >> [7.455000] [] (of_platform_bus_create) from
> >> [] (of_platform_bus_create+0x238
> >>
> >> [7.455000] [] (of_platform_bus_create) from
> >> [] (of_platform_populate+0x60/0x
> >>
> >> [7.455000] [] (of_platform_populate) from []
> >> (customize_machine+0x1c/0x40)
> >>
> >> [7.455000] [] (customize_machine) from []
> >> (do_one_initcall+0xe4/0x140)
> >>
> >> [7.455000] [] (do_one_initcall) from []
> >> (kernel_init_freeable+0xfc/0x1c8)
> >>
> >> [7.455000] [] (kernel_init_freeable) from []
> >> (kernel_init+0x8/0xe4)
> >>
> >> [7.455000] [] (kernel_init) from []
> >> (ret_from_fork+0x14/0x3c)
> >>
> >> [7.455000] Code: e350 08bd8010 e2843050 f57ff05b (e1932f9f)
> >> [7.46] ---[ end trace fe5cfa405506a77d ]---
> >> [7.46] Kernel panic - not syncing: Attempted to kill init!
> >> exitcode=0x000b
> >>
> >> 8<---
> >>
> >> I've tried putting "if (clk)" around the calls to kref_get() and
> >> kref_put(), but that makes the Octa fail to boot like 3.13 did: when
> >> tries to mount root.
> >>
> >> What works for me so far is to remove the offending nodes from the DT:
> >>
> >> 8<---
> >> diff --git a/arch/arm/boot/dts/exynos5420.dtsi
> >> b/arch/arm/boot/dts/exynos5420.dtsi
> >>
> >> index 8db792b..c4ab992 100644
> >> --- a/arch/arm/boot/dts/exynos5420.dtsi
> >> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> >> @@ -303,27 +303,6 @@
> >> #dma-requests = <32>;
> >> };
> >>
> >> - mdma0: mdma@1080 {
> >> - compatible = "arm,pl330", "arm,primecell";
> >> - reg = <0x1080 0x1000>;
> >> - interrupts = <0 33 0>;
> >> - clocks = <&clock 473>;
> >> - clock-names = "apb_pclk";
> >> - #dma-cells = <1>;
> >> - #dma-channels = <8>;
> >> - #dma-requests = <1>;
> >> - };
> >> -
> >> - mdma1: mdma@11C1 {
> >> - compatible = "arm,pl330", "arm,primecell";
> >> - reg = <0x11C1 0x1000>;
> >> - interrupts = <0 124 0>;
> >> - clocks = <&clock 442>;
> >> - clock-names = "apb_pclk";
> >> - #dma-cells
[PATCH 1/2] watchdog: s3c2410_wdt: Remove unneeded initialization
Initializing clk to NULL as a reset/error condition does not help as NULL is not an invalid condition w.r.t clk. Remove this initialization altogether as there is no state retention. Signed-off-by: Sachin Kamat --- drivers/watchdog/s3c2410_wdt.c |2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c index aba6cd46b45b..a0f8f771adec 100644 --- a/drivers/watchdog/s3c2410_wdt.c +++ b/drivers/watchdog/s3c2410_wdt.c @@ -607,7 +607,6 @@ static int s3c2410wdt_probe(struct platform_device *pdev) err_clk: clk_disable_unprepare(wdt->clock); - wdt->clock = NULL; err: return ret; @@ -627,7 +626,6 @@ static int s3c2410wdt_remove(struct platform_device *dev) s3c2410wdt_cpufreq_deregister(wdt); clk_disable_unprepare(wdt->clock); - wdt->clock = NULL; return 0; } -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] watchdog: s3c2410_wdt: Check return value of clk_prepare_enable
clk_prepare_enable can fail. Check its return value.
Signed-off-by: Sachin Kamat
---
drivers/watchdog/s3c2410_wdt.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
index a0f8f771adec..7c6ccd071baf 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -525,7 +525,11 @@ static int s3c2410wdt_probe(struct platform_device *pdev)
goto err;
}
- clk_prepare_enable(wdt->clock);
+ ret = clk_prepare_enable(wdt->clock);
+ if (ret < 0) {
+ dev_err(dev, "failed to enable clock\n");
+ return ret;
+ }
ret = s3c2410wdt_cpufreq_register(wdt);
if (ret < 0) {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Adding set_blob ioctl to DRM
On Thu, Feb 20, 2014 at 11:24:40AM +1000, Dave Airlie wrote: > > I am working on enabling a Color Enhancement block for primary display > > for Exynos SoC. I need to > > set a bunch of parameters like Color Conversion matrix, Contrast > > Improvement parameters etc ~ 30 parameters from User Space. > > > > I am planning to use KDS blob property to receive these parameters. > > Currently drivers are not allowed to create a blob property inside > > drm. Neither, user space can set the blob. There is no ioctl provided > > for same. > > I don't really like the idea of sticking unstructured data into an > ioctl, for the driver to interpret, > > it opens the door to all kinds of ugly driver hacks, so I think we > should have writable blobs, > but with well defined structures inside them, not per-driver ones. > > Per-driver structures will lead to binary userspace drivers that start > sticking a pll timings blob on the end and require it to set a mode, > because I know driver developers will abuse any interface in the worst > way possible. > > Currently the only blob we really have is EDID and its well defined, > so if we are going to add writable blobs, they need to be well defined > and as little as possible driver specific, just to avoid driver > writings doing what driver writers do. tbh I don't see a use for structured blobs at all and would much more prefer a pile of properties. With the atomic modeset ioctl proposals floating around we could then pass in an entire sets of properties, which is essentially what the blob prop would be doing. The upshot of going all-in with explicitly named properties is that we can shovel kms configuration descriptions into different formats. I'm thinking of shovelling an initial config into DT or something similar as an example. For i915 we have some experimental patches which load a DT blob as a firmware file and use the property values to set things up. So imo a blob property needs some _really_ good justification. My default stance is to oppose it ;-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
