[PATCH v3 6/6] ARM: dts: exynos5250-snow: Add cap-sdio-irq to wifi mmc node
Enabling SDIO IRQ signalling for the wifi MMC/SDIO slot doubles the transmission transfer rate. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Changes since v2: None. Changes since v1: None, new patch. --- arch/arm/boot/dts/exynos5250-snow.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts index b78712058903..909edc3448d3 100644 --- a/arch/arm/boot/dts/exynos5250-snow.dts +++ b/arch/arm/boot/dts/exynos5250-snow.dts @@ -539,6 +539,7 @@ status = okay; num-slots = 1; broken-cd; + cap-sdio-irq; card-detect-delay = 200; samsung,dw-mshc-ciu-div = 3; samsung,dw-mshc-sdr-timing = 2 3; -- 2.1.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
[PATCH v3 5/6] ARM: dts: exynos5250-snow: Enable wifi power-on
The Snow board has a MMC/SDIO wifi chip that is always powered but it
needs a power sequence involving a reset (active low) and an enable
(active high) pins. Both pins are marked as active low since the MMC
simple power sequence driver asserts the pins prior to the card power
up procedure and de-asserts the pins after the card has been powered.
So the reset line will be left de-asserted and the enable pin will be
left asserted.
The chip also needs an external 32kHz reference clock to be operational
that is by the MAX77686 PMIC clock.
Add a simple MMC power sequence provider for the wifi MMC/SDIO slot.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v2: None.
Changes since v1:
- Remove cap-sdio-irq from mmc3 dev node since is a separate change.
Suggested by Arend van Spriel.
---
arch/arm/boot/dts/exynos5250-snow.dts | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index b9aeec430527..b78712058903 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -229,6 +229,14 @@
power-supply = fet6;
backlight = backlight;
};
+
+ mmc3_pwrseq: mmc3_pwrseq {
+ compatible = mmc-pwrseq-simple;
+ reset-gpios = gpx0 2 GPIO_ACTIVE_LOW, /* WIFI_RSTn */
+ gpx0 1 GPIO_ACTIVE_LOW; /* WIFI_EN */
+ clocks = max77686 MAX77686_CLK_PMIC;
+ clock-names = ext_clock;
+ };
};
dp {
@@ -536,12 +544,27 @@
samsung,dw-mshc-sdr-timing = 2 3;
samsung,dw-mshc-ddr-timing = 1 2;
pinctrl-names = default;
- pinctrl-0 = sd3_clk sd3_cmd sd3_bus4;
+ pinctrl-0 = sd3_clk sd3_cmd sd3_bus4 wifi_en wifi_rst;
bus-width = 4;
cap-sd-highspeed;
+ mmc-pwrseq = mmc3_pwrseq;
};
pinctrl_0 {
+ wifi_en: wifi-en {
+ samsung,pins = gpx0-1;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ wifi_rst: wifi-rst {
+ samsung,pins = gpx0-2;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
power_key_irq: power-key-irq {
samsung,pins = gpx1-3;
samsung,pin-function = 0xf;
--
2.1.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
[PATCH v3 0/6] Add multiple GPIO and external clock to MMC pwrseq_simple
Hello Ulf, Many WLAN chips attached to an SDIO interface needs more than one GPIO for their reset sequence and also an external clock to be operational. Since this is very common, this series extend the simple MMC power sequence to support more than one reset GPIO and also an optional external clock. This is the third version of the series that addressed issues pointed out in the previous versions. The series depend on v4 mmc: core: Add support for MMC power sequences: http://comments.gmane.org/gmane.linux.kernel.mmc/30665 Javier Martinez Canillas (6): mmc: pwrseq: Document that simple sequence support more than one GPIO mmc: pwrseq_simple: Extend to support more pins mmc: pwrseq: Document optional clock for the simple power sequence mmc: pwrseq_simple: Add optional reference clock support ARM: dts: exynos5250-snow: Enable wifi power-on ARM: dts: exynos5250-snow: Add cap-sdio-irq to wifi mmc node .../devicetree/bindings/mmc/mmc-pwrseq-simple.txt | 11 ++- arch/arm/boot/dts/exynos5250-snow.dts | 26 ++- drivers/mmc/core/pwrseq_simple.c | 89 ++ 3 files changed, 107 insertions(+), 19 deletions(-) Patch #1 extends the simple MMC power sequence DT binding to support more than one GPIO and patch #2 adds the actual implementation. In the same way, patch #3 and #4 extend the simple MMC power sequence DT binding and pwrseq_simple driver to support an optional external clock. Finally as an example, patch #5 and patch #6 adds support for the wifi chip in the Exynos5250 Snow that needs all these resources. These two patches were added to the series only for completeness and should be picked by Kukjin through his linux-samsung tree. Best regards, Javier -- 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 v3 4/6] mmc: pwrseq_simple: Add optional reference clock support
Some WLAN chips attached to a SDIO interface, need a reference clock.
Since this is very common, extend the prseq_simple driver to support
an optional clock that is enabled prior the card power up procedure.
Note: the external clock is optional. Thus an error is not returned
if the clock is not found.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v2:
- Add a clk_enabled bool to struct mmc_pwrseq_simple to track clock
gate/ungate since .power_off can be called prior to .pre_power_on.
Suggested by Ulf Hansson.
- clk_get() does not return -ENOSYS so don't check for that.
Suggested by Ulf Hansson.
Changes since v1:
- Rebase on top of latest changes.
- Use IS_ERR() instead of checking for NULL to see if the clock exists.
---
drivers/mmc/core/pwrseq_simple.c | 38 --
1 file changed, 36 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/pwrseq_simple.c b/drivers/mmc/core/pwrseq_simple.c
index e53d3c7e059c..50d09d920430 100644
--- a/drivers/mmc/core/pwrseq_simple.c
+++ b/drivers/mmc/core/pwrseq_simple.c
@@ -7,6 +7,7 @@
*
* Simple MMC power sequence management
*/
+#include linux/clk.h
#include linux/kernel.h
#include linux/slab.h
#include linux/device.h
@@ -20,6 +21,8 @@
struct mmc_pwrseq_simple {
struct mmc_pwrseq pwrseq;
+ bool clk_enabled;
+ struct clk *ext_clk;
int nr_gpios;
struct gpio_desc *reset_gpios[0];
};
@@ -39,6 +42,11 @@ static void mmc_pwrseq_simple_pre_power_on(struct mmc_host
*host)
struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
struct mmc_pwrseq_simple, pwrseq);
+ if (!IS_ERR(pwrseq-ext_clk)) {
+ clk_prepare_enable(pwrseq-ext_clk);
+ pwrseq-clk_enabled = true;
+ }
+
mmc_pwrseq_simple_set_gpios_value(pwrseq, 1);
}
@@ -50,6 +58,19 @@ static void mmc_pwrseq_simple_post_power_on(struct mmc_host
*host)
mmc_pwrseq_simple_set_gpios_value(pwrseq, 0);
}
+static void mmc_pwrseq_simple_power_off(struct mmc_host *host)
+{
+ struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
+ struct mmc_pwrseq_simple, pwrseq);
+
+ mmc_pwrseq_simple_set_gpios_value(pwrseq, 1);
+
+ if (pwrseq-clk_enabled) {
+ clk_disable_unprepare(pwrseq-ext_clk);
+ pwrseq-clk_enabled = false;
+ }
+}
+
static void mmc_pwrseq_simple_free(struct mmc_host *host)
{
struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
@@ -60,6 +81,9 @@ static void mmc_pwrseq_simple_free(struct mmc_host *host)
if (!IS_ERR(pwrseq-reset_gpios[i]))
gpiod_put(pwrseq-reset_gpios[i]);
+ if (!IS_ERR(pwrseq-ext_clk))
+ clk_put(pwrseq-ext_clk);
+
kfree(pwrseq);
host-pwrseq = NULL;
}
@@ -67,7 +91,7 @@ static void mmc_pwrseq_simple_free(struct mmc_host *host)
static struct mmc_pwrseq_ops mmc_pwrseq_simple_ops = {
.pre_power_on = mmc_pwrseq_simple_pre_power_on,
.post_power_on = mmc_pwrseq_simple_post_power_on,
- .power_off = mmc_pwrseq_simple_pre_power_on,
+ .power_off = mmc_pwrseq_simple_power_off,
.free = mmc_pwrseq_simple_free,
};
@@ -85,6 +109,13 @@ int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct
device *dev)
if (!pwrseq)
return -ENOMEM;
+ pwrseq-ext_clk = clk_get(dev, ext_clock);
+ if (IS_ERR(pwrseq-ext_clk)
+ PTR_ERR(pwrseq-ext_clk) != -ENOENT) {
+ ret = PTR_ERR(pwrseq-ext_clk);
+ goto free;
+ }
+
for (i = 0; i nr_gpios; i++) {
pwrseq-reset_gpios[i] = gpiod_get_index(dev, reset, i,
GPIOD_OUT_HIGH);
@@ -96,7 +127,7 @@ int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct
device *dev)
while (--i)
gpiod_put(pwrseq-reset_gpios[i]);
- goto free;
+ goto clk_put;
}
}
@@ -105,6 +136,9 @@ int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct
device *dev)
host-pwrseq = pwrseq-pwrseq;
return 0;
+clk_put:
+ if (!IS_ERR(pwrseq-ext_clk))
+ clk_put(pwrseq-ext_clk);
free:
kfree(pwrseq);
return ret;
--
2.1.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 v4 2/2] thermal: exynos: Add TMU support for Exynos7 SoC
Hi Lukasz,
On Thu, Jan 29, 2015 at 1:56 PM, Lukasz Majewski l.majew...@samsung.com wrote:
Hi Abhilash,
Add registers, bit fields and compatible strings for Exynos7 TMU
(Thermal Management Unit). Following are a few of the differences
in the Exynos7 TMU from earlier SoCs:
- 8 trigger levels
- Different bit offsets and more registers for the rising
and falling thresholds.
- New power down detection bit in the TMU_CONTROL register
which does not update the CURRENT_TEMP0 when tmu power down
is detected.
- Change in bit offset for the NEXT_DATA field of EMUL_CON
register. EMUL_CON register address has also changed.
- INTSTAT and INTCLEAR registers present in earlier SoCs
have been combined into one INTPEND register. The register
address for INTCLEAR and INTPEND is also different.
- Since there are 8 rising/falling interrupts as against
at most 4 in earlier SoCs the INTEN bit offsets are different.
- Multiple probe support which is handled by a TMU_CONTROL1
register (No support for this in the current patch).
This patch adds special clock support required only for Exynos7. It
also updates the code_to_temp prototype as Exynos7 has 9 bit
code-temp mapping.
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
---
This patch set has been tested on linux next-20150123 with Eduardo's
thermal-next branch merged along with the arch-side exynos7 related
dts changes applied.
Changes since v3:
Addressed comments from Lukasz Majewski:
- Added more comments in the code setting the thresholds.
- Split the documentation out into another patch.
Changes since v2:
- Rebased on top of Lukasz' latest exynos tmu series (v4).
- Added new exynos7 soc_type.
Changes since v1:
- Rebased on top of Lukasz' latest exynos tmu series (v2).
- Added sclk support to patch adding Exynos7 tmu support.
Previously, it was a separate patch.
- Used the SOC type to decide if sclk is present.
drivers/thermal/samsung/exynos_tmu.c | 204
--
drivers/thermal/samsung/exynos_tmu.h |1 + 2 files changed, 197
insertions(+), 8 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c index 852e622..660ff69 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -119,6 +119,26 @@
#define EXYNOS5440_TMU_TH_RISE4_SHIFT24
#define EXYNOS5440_EFUSE_SWAP_OFFSET 8
+/* Exynos7 specific registers */
+#define EXYNOS7_THD_TEMP_RISE7_6 0x50
+#define EXYNOS7_THD_TEMP_FALL7_6 0x60
+#define EXYNOS7_TMU_REG_INTEN0x110
+#define EXYNOS7_TMU_REG_INTPEND 0x118
+#define EXYNOS7_TMU_REG_EMUL_CON 0x160
+
+#define EXYNOS7_TMU_TEMP_MASK0x1ff
+#define EXYNOS7_PD_DET_EN_SHIFT 23
+#define EXYNOS7_TMU_INTEN_RISE0_SHIFT0
+#define EXYNOS7_TMU_INTEN_RISE1_SHIFT1
+#define EXYNOS7_TMU_INTEN_RISE2_SHIFT2
+#define EXYNOS7_TMU_INTEN_RISE3_SHIFT3
+#define EXYNOS7_TMU_INTEN_RISE4_SHIFT4
+#define EXYNOS7_TMU_INTEN_RISE5_SHIFT5
+#define EXYNOS7_TMU_INTEN_RISE6_SHIFT6
+#define EXYNOS7_TMU_INTEN_RISE7_SHIFT7
+#define EXYNOS7_EMUL_DATA_SHIFT 7
+#define EXYNOS7_EMUL_DATA_MASK 0x1ff
+
#define MCELSIUS 1000
/**
* struct exynos_tmu_data : A structure to hold the private data of
the TMU @@ -133,6 +153,7 @@
* @lock: lock to implement synchronization.
* @clk: pointer to the clock structure.
* @clk_sec: pointer to the clock structure for accessing the
base_second.
+ * @sclk: pointer to the clock structure for accessing the tmu
special clk.
* @temp_error1: fused value of the first point trim.
* @temp_error2: fused value of the second point trim.
* @regulator: pointer to the TMU regulator structure.
@@ -152,8 +173,8 @@ struct exynos_tmu_data {
enum soc_type soc;
struct work_struct irq_work;
struct mutex lock;
- struct clk *clk, *clk_sec;
- u8 temp_error1, temp_error2;
+ struct clk *clk, *clk_sec, *sclk;
+ u16 temp_error1, temp_error2;
struct regulator *regulator;
struct thermal_zone_device *tzd;
@@ -223,7 +244,7 @@ static int temp_to_code(struct exynos_tmu_data
*data, u8 temp)
* Calculate a temperature value from a temperature code.
* The unit of the temperature is degree Celsius.
*/
-static int code_to_temp(struct exynos_tmu_data *data, u8 temp_code)
+static int code_to_temp(struct exynos_tmu_data *data, u16 temp_code)
{
struct exynos_tmu_platform_data *pdata = data-pdata;
int temp;
@@ -513,6 +534,84 @@ static int
[PATCH v3 3/6] mmc: pwrseq: Document optional clock for the simple power sequence
Some WLAN chips attached to a SDIO interface, need an external clock to be operational. Since this is very common, extend the simple MMC power sequence DT binding to support an optional clock. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Changes since v2: None. Changes since v1: None. --- Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt index eaae652213ae..a462c50f19a8 100644 --- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt @@ -12,6 +12,10 @@ Optional properties: at initialization and prior we start the power up procedure of the card. They will be de-asserted right after the power has been provided to the card. +- clocks : Must contain an entry for the entry in clock-names. + See ../clocks/clock-bindings.txt for details. +- clock-names : Must include the following entry: + ext_clock (External clock provided to the card). Example: -- 2.1.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
[PATCH v3 2/6] mmc: pwrseq_simple: Extend to support more pins
Many WLAN attached to a SDIO/MMC interface, needs more than one pin for
their reset sequence. For example, is very common for chips to have two
pins: one for reset and one for power enable.
This patch adds support for more reset pins to the pwrseq_simple driver
and instead hardcoding a fixed number, it uses the of_gpio_named_count()
since the MMC power sequence is only built when CONFIG_OF is enabled.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
Changes since v2: None.
Changes since v1:
- Many code cleanups suggested by Srinivas Kandagatla
* Rename reset_gpio array to reset_gpios.
* Use a zero length array for reset_gpios to avoid a kmalloc.
* Refactor GPIO assert and de-ssert logic into a common function.
* Simplify gpiod_put logic in case of gpiod_get error.
---
drivers/mmc/core/pwrseq_simple.c | 55 +---
1 file changed, 40 insertions(+), 15 deletions(-)
diff --git a/drivers/mmc/core/pwrseq_simple.c b/drivers/mmc/core/pwrseq_simple.c
index 0958c696137f..e53d3c7e059c 100644
--- a/drivers/mmc/core/pwrseq_simple.c
+++ b/drivers/mmc/core/pwrseq_simple.c
@@ -11,6 +11,7 @@
#include linux/slab.h
#include linux/device.h
#include linux/err.h
+#include linux/of_gpio.h
#include linux/gpio/consumer.h
#include linux/mmc/host.h
@@ -19,16 +20,26 @@
struct mmc_pwrseq_simple {
struct mmc_pwrseq pwrseq;
- struct gpio_desc *reset_gpio;
+ int nr_gpios;
+ struct gpio_desc *reset_gpios[0];
};
+static void mmc_pwrseq_simple_set_gpios_value(struct mmc_pwrseq_simple *pwrseq,
+ int value)
+{
+ int i;
+
+ for (i = 0; i pwrseq-nr_gpios; i++)
+ if (!IS_ERR(pwrseq-reset_gpios[i]))
+ gpiod_set_value_cansleep(pwrseq-reset_gpios[i], value);
+}
+
static void mmc_pwrseq_simple_pre_power_on(struct mmc_host *host)
{
struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
struct mmc_pwrseq_simple, pwrseq);
- if (!IS_ERR(pwrseq-reset_gpio))
- gpiod_set_value_cansleep(pwrseq-reset_gpio, 1);
+ mmc_pwrseq_simple_set_gpios_value(pwrseq, 1);
}
static void mmc_pwrseq_simple_post_power_on(struct mmc_host *host)
@@ -36,17 +47,18 @@ static void mmc_pwrseq_simple_post_power_on(struct mmc_host
*host)
struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
struct mmc_pwrseq_simple, pwrseq);
- if (!IS_ERR(pwrseq-reset_gpio))
- gpiod_set_value_cansleep(pwrseq-reset_gpio, 0);
+ mmc_pwrseq_simple_set_gpios_value(pwrseq, 0);
}
static void mmc_pwrseq_simple_free(struct mmc_host *host)
{
struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
struct mmc_pwrseq_simple, pwrseq);
+ int i;
- if (!IS_ERR(pwrseq-reset_gpio))
- gpiod_put(pwrseq-reset_gpio);
+ for (i = 0; i pwrseq-nr_gpios; i++)
+ if (!IS_ERR(pwrseq-reset_gpios[i]))
+ gpiod_put(pwrseq-reset_gpios[i]);
kfree(pwrseq);
host-pwrseq = NULL;
@@ -62,20 +74,33 @@ static struct mmc_pwrseq_ops mmc_pwrseq_simple_ops = {
int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct device *dev)
{
struct mmc_pwrseq_simple *pwrseq;
- int ret = 0;
+ int i, nr_gpios, ret = 0;
- pwrseq = kzalloc(sizeof(struct mmc_pwrseq_simple), GFP_KERNEL);
+ nr_gpios = of_gpio_named_count(dev-of_node, reset-gpios);
+ if (nr_gpios 0)
+ nr_gpios = 0;
+
+ pwrseq = kzalloc(sizeof(struct mmc_pwrseq_simple) + nr_gpios *
+sizeof(struct gpio_desc *), GFP_KERNEL);
if (!pwrseq)
return -ENOMEM;
- pwrseq-reset_gpio = gpiod_get_index(dev, reset, 0, GPIOD_OUT_HIGH);
- if (IS_ERR(pwrseq-reset_gpio)
- PTR_ERR(pwrseq-reset_gpio) != -ENOENT
- PTR_ERR(pwrseq-reset_gpio) != -ENOSYS) {
- ret = PTR_ERR(pwrseq-reset_gpio);
- goto free;
+ for (i = 0; i nr_gpios; i++) {
+ pwrseq-reset_gpios[i] = gpiod_get_index(dev, reset, i,
+GPIOD_OUT_HIGH);
+ if (IS_ERR(pwrseq-reset_gpios[i])
+ PTR_ERR(pwrseq-reset_gpios[i]) != -ENOENT
+ PTR_ERR(pwrseq-reset_gpios[i]) != -ENOSYS) {
+ ret = PTR_ERR(pwrseq-reset_gpios[i]);
+
+ while (--i)
+ gpiod_put(pwrseq-reset_gpios[i]);
+
+ goto free;
+ }
}
+ pwrseq-nr_gpios = nr_gpios;
pwrseq-pwrseq.ops = mmc_pwrseq_simple_ops;
host-pwrseq = pwrseq-pwrseq;
--
2.1.3
--
To unsubscribe from this
[PATCH v3 1/6] mmc: pwrseq: Document that simple sequence support more than one GPIO
Many SDIO/MMC attached WLAN chips need more than one ping for their reset sequence. Extend the pwrseq_simple binding to support more than one pin. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Changes since v2: None. Changes since v1: - Make the explanation clearer by adding an explicit they. Suggested by Srinivas Kandagatla. --- Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt index da333d9ed94c..eaae652213ae 100644 --- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt @@ -8,9 +8,10 @@ Required properties: - compatible : contains mmc-pwrseq-simple. Optional properties: -- reset-gpios : contains a GPIO specifier. The reset GPIO is asserted at - initialization and prior we start the power up procedure of the card. It - will be de-asserted right after the power has been provided to the card. +- reset-gpios : contains a list of GPIO specifiers. The reset GPIOs are asserted + at initialization and prior we start the power up procedure of the card. + They will be de-asserted right after the power has been provided to the + card. Example: -- 2.1.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
[PATCH -v2] drm/exynos: track vblank events on a per crtc basis
From: Mandeep Singh Baines m...@chromium.org
The goal of the change is to make sure we send the vblank event on the
current vblank. My hope is to fix any races that might be causing flicker.
After this change I only see a flicker in the transition plymouth and
X11.
Simplified the code by tracking vblank events on a per-crtc basis. This
allowed me to remove all error paths from the callback. It also allowed
me to remove the vblank wait from the callback.
Signed-off-by: Mandeep Singh Baines m...@chromium.org
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 29 +++--
drivers/gpu/drm/exynos/exynos_drm_drv.c | 19 ---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 ++
3 files changed, 9 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index a85c451..91c175b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -34,9 +34,8 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int
mode)
if (mode DRM_MODE_DPMS_ON) {
/* wait for the completion of page flip. */
if (!wait_event_timeout(exynos_crtc-pending_flip_queue,
- !atomic_read(exynos_crtc-pending_flip),
- HZ/20))
- atomic_set(exynos_crtc-pending_flip, 0);
+ (exynos_crtc-event == NULL), HZ/20))
+ exynos_crtc-event = NULL;
drm_crtc_vblank_off(crtc);
}
@@ -166,7 +165,6 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
uint32_t page_flip_flags)
{
struct drm_device *dev = crtc-dev;
- struct exynos_drm_private *dev_priv = dev-dev_private;
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
struct drm_framebuffer *old_fb = crtc-primary-fb;
unsigned int crtc_w, crtc_h;
@@ -195,9 +193,7 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
}
spin_lock_irq(dev-event_lock);
- list_add_tail(event-base.link,
- dev_priv-pageflip_event_list);
- atomic_set(exynos_crtc-pending_flip, 1);
+ exynos_crtc-event = event;
spin_unlock_irq(dev-event_lock);
crtc-primary-fb = fb;
@@ -209,11 +205,7 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
if (ret) {
crtc-primary-fb = old_fb;
- spin_lock_irq(dev-event_lock);
drm_vblank_put(dev, exynos_crtc-pipe);
- list_del(event-base.link);
- atomic_set(exynos_crtc-pending_flip, 0);
- spin_unlock_irq(dev-event_lock);
goto out;
}
@@ -315,7 +307,6 @@ struct exynos_drm_crtc *exynos_drm_crtc_create(struct
drm_device *drm_dev,
return ERR_PTR(-ENOMEM);
init_waitqueue_head(exynos_crtc-pending_flip_queue);
- atomic_set(exynos_crtc-pending_flip, 0);
exynos_crtc-dpms = DRM_MODE_DPMS_OFF;
exynos_crtc-pipe = pipe;
@@ -382,26 +373,20 @@ void exynos_drm_crtc_disable_vblank(struct drm_device
*dev, int pipe)
void exynos_drm_crtc_finish_pageflip(struct drm_device *dev, int pipe)
{
struct exynos_drm_private *dev_priv = dev-dev_private;
- struct drm_pending_vblank_event *e, *t;
struct drm_crtc *drm_crtc = dev_priv-crtc[pipe];
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(drm_crtc);
unsigned long flags;
spin_lock_irqsave(dev-event_lock, flags);
+ if (exynos_crtc-event) {
- list_for_each_entry_safe(e, t, dev_priv-pageflip_event_list,
- base.link) {
- /* if event's pipe isn't same as crtc then ignore it. */
- if (pipe != e-pipe)
- continue;
-
- list_del(e-base.link);
- drm_send_vblank_event(dev, -1, e);
+ drm_send_vblank_event(dev, -1, exynos_crtc-event);
drm_vblank_put(dev, pipe);
- atomic_set(exynos_crtc-pending_flip, 0);
wake_up(exynos_crtc-pending_flip_queue);
+
}
+ exynos_crtc-event = NULL;
spin_unlock_irqrestore(dev-event_lock, flags);
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index b60fd9b..731cdbc 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -61,7 +61,6 @@ static int exynos_drm_load(struct drm_device *dev, unsigned
long flags)
if (!private)
return -ENOMEM;
- INIT_LIST_HEAD(private-pageflip_event_list);
Re: [PATCH v4 2/2] thermal: exynos: Add TMU support for Exynos7 SoC
Hi Abhilash,
Add registers, bit fields and compatible strings for Exynos7 TMU
(Thermal Management Unit). Following are a few of the differences
in the Exynos7 TMU from earlier SoCs:
- 8 trigger levels
- Different bit offsets and more registers for the rising
and falling thresholds.
- New power down detection bit in the TMU_CONTROL register
which does not update the CURRENT_TEMP0 when tmu power down
is detected.
- Change in bit offset for the NEXT_DATA field of EMUL_CON
register. EMUL_CON register address has also changed.
- INTSTAT and INTCLEAR registers present in earlier SoCs
have been combined into one INTPEND register. The register
address for INTCLEAR and INTPEND is also different.
- Since there are 8 rising/falling interrupts as against
at most 4 in earlier SoCs the INTEN bit offsets are different.
- Multiple probe support which is handled by a TMU_CONTROL1
register (No support for this in the current patch).
This patch adds special clock support required only for Exynos7. It
also updates the code_to_temp prototype as Exynos7 has 9 bit
code-temp mapping.
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
---
This patch set has been tested on linux next-20150123 with Eduardo's
thermal-next branch merged along with the arch-side exynos7 related
dts changes applied.
Changes since v3:
Addressed comments from Lukasz Majewski:
- Added more comments in the code setting the thresholds.
- Split the documentation out into another patch.
Changes since v2:
- Rebased on top of Lukasz' latest exynos tmu series (v4).
- Added new exynos7 soc_type.
Changes since v1:
- Rebased on top of Lukasz' latest exynos tmu series (v2).
- Added sclk support to patch adding Exynos7 tmu support.
Previously, it was a separate patch.
- Used the SOC type to decide if sclk is present.
drivers/thermal/samsung/exynos_tmu.c | 204
--
drivers/thermal/samsung/exynos_tmu.h |1 + 2 files changed, 197
insertions(+), 8 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c index 852e622..660ff69 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -119,6 +119,26 @@
#define EXYNOS5440_TMU_TH_RISE4_SHIFT24
#define EXYNOS5440_EFUSE_SWAP_OFFSET 8
+/* Exynos7 specific registers */
+#define EXYNOS7_THD_TEMP_RISE7_6 0x50
+#define EXYNOS7_THD_TEMP_FALL7_6 0x60
+#define EXYNOS7_TMU_REG_INTEN0x110
+#define EXYNOS7_TMU_REG_INTPEND 0x118
+#define EXYNOS7_TMU_REG_EMUL_CON 0x160
+
+#define EXYNOS7_TMU_TEMP_MASK0x1ff
+#define EXYNOS7_PD_DET_EN_SHIFT 23
+#define EXYNOS7_TMU_INTEN_RISE0_SHIFT0
+#define EXYNOS7_TMU_INTEN_RISE1_SHIFT1
+#define EXYNOS7_TMU_INTEN_RISE2_SHIFT2
+#define EXYNOS7_TMU_INTEN_RISE3_SHIFT3
+#define EXYNOS7_TMU_INTEN_RISE4_SHIFT4
+#define EXYNOS7_TMU_INTEN_RISE5_SHIFT5
+#define EXYNOS7_TMU_INTEN_RISE6_SHIFT6
+#define EXYNOS7_TMU_INTEN_RISE7_SHIFT7
+#define EXYNOS7_EMUL_DATA_SHIFT 7
+#define EXYNOS7_EMUL_DATA_MASK 0x1ff
+
#define MCELSIUS 1000
/**
* struct exynos_tmu_data : A structure to hold the private data of
the TMU @@ -133,6 +153,7 @@
* @lock: lock to implement synchronization.
* @clk: pointer to the clock structure.
* @clk_sec: pointer to the clock structure for accessing the
base_second.
+ * @sclk: pointer to the clock structure for accessing the tmu
special clk.
* @temp_error1: fused value of the first point trim.
* @temp_error2: fused value of the second point trim.
* @regulator: pointer to the TMU regulator structure.
@@ -152,8 +173,8 @@ struct exynos_tmu_data {
enum soc_type soc;
struct work_struct irq_work;
struct mutex lock;
- struct clk *clk, *clk_sec;
- u8 temp_error1, temp_error2;
+ struct clk *clk, *clk_sec, *sclk;
+ u16 temp_error1, temp_error2;
struct regulator *regulator;
struct thermal_zone_device *tzd;
@@ -223,7 +244,7 @@ static int temp_to_code(struct exynos_tmu_data
*data, u8 temp)
* Calculate a temperature value from a temperature code.
* The unit of the temperature is degree Celsius.
*/
-static int code_to_temp(struct exynos_tmu_data *data, u8 temp_code)
+static int code_to_temp(struct exynos_tmu_data *data, u16 temp_code)
{
struct exynos_tmu_platform_data *pdata = data-pdata;
int temp;
@@ -513,6 +534,84 @@ static int exynos5440_tmu_initialize(struct
platform_device *pdev) return ret;
}
+static int
Re: [PATCH 1/4] mmc: core: add support for hardware reset gpio line
Hello, On 2015-01-28 15:24, Ulf Hansson wrote: On 28 January 2015 at 14:59, Marek Szyprowski m.szyprow...@samsung.com wrote: There are boards (like Hardkernel's Odroid boards) on which eMMC card's reset line is connected to GPIO line instead of the hardware reset logic. In case of such boards, if first stage of bootloader is loaded from such eMMC card, before performing system reboot, additional reset of eMMC card is required to properly boot the whole system again. This patch adds code for handling reset gpio lines defined in device tree. I don't follow the above sequence. Can you try to elaborate and describe for what exact scenario we require the hardware reset to be done? Odroid boards uses multi stage bootloaders. The very first stage is in SoC ROM. That code loads next stages (called bl1, bl2, tz) from either eMMC or SD card (depending on jumper configuration or some card detect pins). This ROM code is very simple and assumes that the mmc card has been reset to the default configuration. However, eMMC card is not being reset by the board 'reboot' logic. Instead the nreset line from emmc card is connected to gpio line of SoC. Thus to perform full system reboot procedure, before triggering reboot inside the SoC, one need to manually toggle nreset line of this emmc card to 'zero' for a while. Only then the card is put back to the default state, so ROM code is able to read bootloaders from it. My patch adds code for managing gpio line connected to nreset signal of emmc card. It registers reset handler, which is being triggered from Linux reboot code. This handler toggles such gpio line before the final reboot is triggered. My patch also provides a function for registering as a mmc host hw_reset callback, so it can be used to reset mmc card before initializing it with kernel driver (this is already implemented), which also might help to get it working if broken bootloader left the emmc card in some unknown/broken state (already observed such issue, but it has been fixed finally by patching bootloader). Also, I wonder whether we could extend the mmc-pwrseq to cover your case? Did you consider that as an option? I didn't consider mmc-pwrseq yet. For me it looked straightforward to implement it just like card detect or write-protection gpio pins. I already noticed that there is code for some mmc host driver, which perform mmc hardware reset. If you think that extending pwrseq is the better approach, I will try to update my patches. This will add reboot handler to mmc-pwrseq then. The only question is weather to use it always when mmc-pwrseq has been enabled or only if some additional property like 'reset-on-reboot' has been provided. Best regards -- Marek Szyprowski, PhD Samsung RD Institute Poland -- 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 3/3] cpufreq: exynos: allow modular build
On Thursday 29 January 2015 09:09:03 Viresh Kumar wrote: On 29 January 2015 at 01:31, Arnd Bergmann a...@arndb.de wrote: config ARM_EXYNOS_CPUFREQ - bool + tristate SAMSUNG EXYNOS CPUfreq Driver + depends on THERMAL + default y + help + This adds the CPUFreq driver for Samsung EXYNOS platforms + + If in doubt, say N. Now the option shows up on all systems that include Kconfig.arm, in particular non-exynos machines that might not even be able to build this. I am sure I am wrong here, but want to know what I am missing. What about: diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm index c3c3cf52d2d9..f3ee05067a69 100644 --- a/drivers/cpufreq/Kconfig.arm +++ b/drivers/cpufreq/Kconfig.arm @@ -27,7 +27,7 @@ config ARM_VEXPRESS_SPC_CPUFREQ config ARM_EXYNOS_CPUFREQ tristate SAMSUNG EXYNOS CPUfreq Driver - depends on THERMAL + depends on THERMAL ARCH_EXYNOS default y help This adds the CPUFreq driver for Samsung EXYNOS platforms That might be close enough to what we want. It would by default enable ARM_EXYNOS_CPUFREQ for exynos based machines that do not use this driver (e.g. 5440, which has a separate driver, or exynos3/exynos7), but that can probably just be dealt with by disabling it in the user's defconfig. If i'm reading exynos_cpufreq_probe right, it would actually compile into an almost-empty file in this case and only kzalloc a few bytes of memory and then print a warning message. 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
Re: [PATCH] ASoC: Samsung: add missing I2C/SPI dependencies
On Wed, Jan 28, 2015 at 10:28:55PM +0100, Arnd Bergmann wrote: The SND_SOC_ARNDALE_RT5631_ALC5631 selects the rt5631 codec that requires I2C to work, so we get a build error if I2C is disabled: You rather buried the lead about there being other drivers in this changelog, makes the code a bit surprising when you find it. config SND_SOC_SPEYSIDE tristate Audio support for Wolfson Speyside - depends on SND_SOC_SAMSUNG MACH_WLF_CRAGG_6410 + depends on SND_SOC_SAMSUNG MACH_WLF_CRAGG_6410 SPI_MASTER select SND_SAMSUNG_I2S select SND_SOC_WM8996 select SND_SOC_WM9081 Why only add a dependency on SPI here? signature.asc Description: Digital signature
Re: [PATCH] video: treat signal like timeout as failure
On Mon, 26 Jan 2015, Russell King - ARM Linux wrote:
On Tue, Jan 20, 2015 at 06:23:50AM +0100, Nicholas Mc Guire wrote:
if(!wait_for_completion_interruptible_timeout(...))
only handles the timeout case - this patch adds handling the
signal case the same as timeout and cleans up.
Signed-off-by: Nicholas Mc Guire der.h...@hofr.at
---
Only the timeout case was being handled, return of 0 in
wait_for_completion_interruptible_timeout, the signal case (-ERESTARTSYS)
was treated just like the case of successful completion, which is most
likely not reasonable.
Note that exynos_mipi_dsi_wr_data/exynos_mipi_dsi_rd_data return values
are not checked at the call sites in s6e8ax0.c (cmd_read/cmd_write)!
This patch simply treats the signal case the same way as the timeout case,
by releasing locks and returning 0 - which might not be the right thing to
do - this needs a review by someone knowing the details of this driver.
Patch is against 3.19.0-rc5 -next-20150119
Patch was only compile-tested with exynos_defconfig
drivers/video/fbdev/exynos/exynos_mipi_dsi_common.c | 17
+++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/exynos/exynos_mipi_dsi_common.c
b/drivers/video/fbdev/exynos/exynos_mipi_dsi_common.c
index 2358a2f..55a7a45 100644
--- a/drivers/video/fbdev/exynos/exynos_mipi_dsi_common.c
+++ b/drivers/video/fbdev/exynos/exynos_mipi_dsi_common.c
@@ -157,6 +157,7 @@ int exynos_mipi_dsi_wr_data(struct mipi_dsim_device
*dsim, unsigned int data_id,
const unsigned char *data0, unsigned int data_size)
{
unsigned int check_rx_ack = 0;
+ long timeout;
if (dsim-state == DSIM_STATE_ULPS) {
dev_err(dsim-dev, state is ULPS.\n);
@@ -244,9 +245,11 @@ int exynos_mipi_dsi_wr_data(struct mipi_dsim_device
*dsim, unsigned int data_id,
exynos_mipi_dsi_wr_tx_header(dsim, data_id, data_size 0xff,
(data_size 0xff00) 8);
- if (!wait_for_completion_interruptible_timeout(dsim_wr_comp,
- MIPI_FIFO_TIMEOUT)) {
- dev_warn(dsim-dev, command write timeout.\n);
+ timeout = wait_for_completion_interruptible_timeout(
+ dsim_wr_comp, MIPI_FIFO_TIMEOUT);
+ if (timeout = 0) {
+ dev_warn(dsim-dev,
+ command write timed-out/interrupted.\n);
This is really silly. Let's say that the program which results in
this function called is using signals (eg, alarm() with SIGALRM, or
asynchronous IO with SIGIO, etc).
Why should having a SIGALRM raised print a kernel message? If this
happens a lot, it will result in the kernel log being flooded with
these messages.
Signals should not be seen as exceptional conditions. For some programs,
they are merely asynchronous events which are a normal part of the
programs operation (eg, SIGIO, SIGALRM, etc.)
Please, if you are going to handle signals, then handle them properly.
If you're not going to handle them properly, don't use a wait that
caters for them - use wait_for_completion_killable_timeout() which
doesn't finish waiting on a signal unless the signal is going to result
in the death of the program.
the current code would treat the signal case identical with the
completion success case - and that hardly can be the intention
so while it might not be necessary to call printk in the signal
case it should in some way be handled - if there is not need to
handle signals then it might be more resonable to use
wait_for_completion_timeout which is not interruptible.
So the key issue here is not that a signal should necessarily print
a message but that it should not be treated as the success case. The
current code will only treat timeout as an error condition and a received
signal (implying that the condition being waited for is most likely not
satisfied) as a successful completion.
thx!
hofrat
--
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 0/8] PM / Domains: Re-structure code for adding/removing devices to genpd
On Tue, Jan 27, 2015 at 9:13 PM, Ulf Hansson ulf.hans...@linaro.org wrote:
While adding error handling of genpd's -attach_dev() callback, I realized
that
we also had a need to re-structure some of the code which deals with
adding/removing devices to genpd. Especially the APIs, __pm_genpd_add_device()
and pm_genpd_remove_device() deserved some attention.
Patch 1 - 4, can be considered as more simple cleanups and should not impact
the behavior for current clients using the APIs.
Patch 5, eliminates a mutex for generic_pm_domain_data by re-order the
initialization/cleanup of dev_pm_qos notifiers.
Patch 6, move some code around to fix a potenial memory leakage of a struct
pm_subsys_data.
Patch 7, code restructuring which impacts locking behavior while
adding/removing
devices. Should improve code readability and decrease critical regions of
holding locks.
Patch 8, Adds error handling of genpd's -attach_dev() callback
Ulf Hansson (8):
PM / Domains: Rename __pm_genpd_alloc|free_dev_data()
PM / Domains: Remove reference counting for the generic_pm_domain_data
PM / Domains: Don't allow an existing generic_pm_domain_data
PM / Domains: Don't check for an existing device when adding a new
PM / Domains: Eliminate the mutex for the generic_pm_domain_data
PM / Domains: Free pm_subsys_data in error path in
__pm_genpd_add_device()
PM / Domains: Re-order initialization of generic_pm_domain_data
PM / Domains: Handle errors from genpd's -attach_dev() callback
Looks OK, and tested on sh73a0/kzm9g-multiplatform with PM domains
Tested-by: Geert Uytterhoeven geert+rene...@glider.be
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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 3/3] cpufreq: exynos: allow modular build
On 29 January 2015 at 15:31, Arnd Bergmann a...@arndb.de wrote: That might be close enough to what we want. It would by default enable ARM_EXYNOS_CPUFREQ for exynos based machines that do not use this driver (e.g. 5440, which has a separate driver, or exynos3/exynos7), but that can probably just be dealt with by disabling it in the user's defconfig. If i'm reading exynos_cpufreq_probe right, it would actually compile into an almost-empty file in this case and only kzalloc a few bytes of memory and then print a warning message. I may be wrong this time around, but I will still try hard : diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile index b3ca7b0b2c33..91747c411d86 100644 --- a/drivers/cpufreq/Makefile +++ b/drivers/cpufreq/Makefile @@ -51,10 +51,9 @@ obj-$(CONFIG_ARM_DT_BL_CPUFREQ) += arm_big_little_dt.o obj-$(CONFIG_ARCH_DAVINCI) += davinci-cpufreq.o obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o -obj-$(CONFIG_ARM_EXYNOS_CPUFREQ) += exynos-cpufreq.o -obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos4210-cpufreq.o -obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) += exynos4x12-cpufreq.o -obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos5250-cpufreq.o +obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos-cpufreq.o exynos4210-cpufreq.o +obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) += exynos-cpufreq.o exynos4x12-cpufreq.o +obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos-cpufreq.o exynos5250-cpufreq.o obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) += exynos5440-cpufreq.o obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ) += highbank-cpufreq.o obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)+= imx6q-cpufreq.o -- 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] pinctrl: exynos: Add support for Exynos5433
On Wed, Jan 21, 2015 at 7:43 AM, Chanwoo Choi cw00.c...@samsung.com wrote: This patch adds driver data for Exynos5433 SoC. Exynos5433 includes 228 multi- functional input/output port pins and 135 memory port pins. There are 41 general port groups and 2 memory port groups. Cc: Tomasz Figa tomasz.f...@gmail.com Cc: Thomas Abraham thomas.abra...@linaro.org Cc: Linus Walleij linus.wall...@linaro.org Signed-off-by: Chanwoo Choi cw00.c...@samsung.com Acked-by: Inki Dae inki@samsung.com --- Changes from v2: - Rebase it on v3.19-rc5 Waiting for Tomasz to review this. Yours, Linus Walleij -- 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/4] mmc: core: add support for hardware reset gpio line
Hello, On 2015-01-29 11:56, Javier Martinez Canillas wrote: On Thu, Jan 29, 2015 at 10:15 AM, Marek Szyprowski m.szyprow...@samsung.com wrote: Also, I wonder whether we could extend the mmc-pwrseq to cover your case? Did you consider that as an option? I didn't consider mmc-pwrseq yet. For me it looked straightforward to I agree with Ulf that using mmc-pwrseq would be a good solution and in fact I think the pwrseq_simple [0] driver will fit your use case since it supports a reset GPIO pin which is what many WLAN chips attached to a SDIO interface use. implement it just like card detect or write-protection gpio pins. I already noticed that there is code for some mmc host driver, which perform mmc hardware reset. If you think that extending pwrseq is the better approach, I will try to update my patches. This will add reboot handler to mmc-pwrseq then. The only question is I don't think that adding a reboot handler to mmc-pwrseq is needed. AFAICT the call chain is: sys_reboot() - kernel_restart() - device_shutdown() - mmc_bus_shutdown() - _mmc_suspend() - mmc_power_off() - mmc_pwrseq_power_off() - struct mmc_pwrseq_ops .power_off So since the pwrseq_simple already asserts the reset GPIO in .power_off, it should be enough to ensure the eMMC will be reset to its default configuration for the iROM to work properly. I think that I had to add reset handler, because device_shutdown() was not called if reset was triggered from magic sysrq, but I will check it again. It also asserts the GPIO pin in .pre_power_on and de-asserts in .post_power_on which should be needed as well for the other case you mentioned when a broken bootloader left the emmc card in some unknown state. weather to use it always when mmc-pwrseq has been enabled or only if some additional property like 'reset-on-reboot' has been provided. Having a reset GPIO is optional AFAIK so I don't think there is a need for an additional reset-on-reboot propery. Best regards -- Marek Szyprowski, PhD Samsung RD Institute Poland Best regards, Javier [0]: FYI, these are the relevant commits in linux-next: fe1922d5d4d0 mmc: pwrseq_simple: Add support for a reset GPIO pin ec2017f2491f mmc: pwrseq: Initial support for the simple MMC power sequence provider fe1686658f9c mmc: pwrseq: Document DT bindings for the simple MMC power sequence 1b745e8a4627 mmc: core: Initial support for MMC power sequences Ok, I will check it. Best regards -- Marek Szyprowski, PhD Samsung RD Institute Poland -- 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 01/12] clk: samsung: exynos5433: Add clocks using common clock framework
Hi Chanwoo,
On 29/01/15 00:38, Chanwoo Choi wrote:
...
Right. current samsung clock drivers cannot show the hierarchy among clock
domains in DT.
IOW, there is currently
no way to ensure proper registration order of the CMUs (clock domains).
This may be important in some cases.
To address this we could either add clocks/clock-names properties in
respective CMU device nodes, pointing to any clocks in other CMU(s) or
make a single device node for the whole clock controller, with an
aggregated reg entry, e.g.
cmu: clock-controller@0x1003 {
compatible = samsung,exynos5433-cmu;
reg = 0x1003 0x0c04,
0x10fc 0x0c04,
0x105b 0x100c,
0x14c8 0x0b08,
0x1004 0x0b20,
0x156e 0x0b04,
...
reg-names = top, cpif, mif, peric, peris, fsys...
#clock-cells = 1;
};
If you make a single device node to support various clock domain,
How are you indicate the specific clock in some clock domain?
This might be an issue, we would need to make all the clk indexes a one
contiguous set.
Exynos5433 has a whole lot of clocks against Exynos4 series clocks.
So, if make all the clocks in the same set, I wonder making too huge set.
It may cause the complicated code to find the proper clock or to analyze
the clock driver.
I'm wondering if there is really any use of having such
information expressed explicitly in DT, or it would just make the DT
binding closer resembling the SoC's documentation ?
If we show the hierarchy or dependency between clock domains,
I think we should modify structure samsung_clk_provider
to include dependency information between clock domains.
(It is just my opinion, this opinion could be not proper solution.)
As your patches stand currently there is no need to do anything else
in the driver, since the clock dependencies are specified by static
clock names in each clk domain provider.
We could just leave the multiple nodes, one per each clk domain and if
we specified parent clocks to each clk domain the clk providers would
be registered in proper order, since clk core would take care of it.
Because when we use the common clk framework without adding
any dependency information between clock domains, it is well working.
Yes it works currently, but if you try to get/set rate of a clock supplied
by a clk domain A right after this domain is registered, and domain B which
provides clocks to domain A is not yet registered the clk rate will be
incorrect.
We are currently not seeing any issues only because our use cases are
limited.
Similarly, the clock controller is divided into subdomains in older SoCs,
like exynos4, yet we do not create separate device nodes for each domain.
Is reference to each individual clock domain required in any other SoC's
part in case of exynos5433 ?
There is a difference between exynos4 cmu and exynos5433 cmu.
exynos4. As I knew, Exynos4 series have the one more clock domain.
But, there are not any IPs between clock domains. We can check it as
following
read base address and scope.
The base address and range of Exynos4412 clock domain :
- 0x1003_ ~ 0x1003_CA08
- 0x1004_ ~ 0x1004_8B0C
But, the clock domain in base address map of exynos5433 is located
in non-continuous range. Also, there are un-related IPs to clocks.
(e.g., mct 101c_, gic 1100_1000, serial0 14c1_, pinctrl 1058_
...)
If we make the one dt node for clock domains like exynos4,
I think it may cause the possible issue that clock drivers may access
the un-related memory-mapped region.
The base address and range of Exynos5433 clock domain :
- top domain: 0x1003_ ~ 0x1003_0c04
- cpif domain : 0x10fc_ ~ 0x10fc_0x0c04
- mif domain: 0x105b_ ~ 0x105b_0x100c
- peric domain : 0x14c8_ ~ 0x14c8_0b08
- peris domain : 0x1004_ ~ 0x1004_0x0b20
- fsys domain : 0x156e_ ~ 0x156e_0b04
For reason Tomasz mentioned it may be indeed better to model each clk
domain as separate node. In order to, for example make it easier to
handle dependencies between clk domain and power domain.
The register region specified by reg property of course doesn't have to be
contiguous, each offset/size tuple from reg will be just mapped separately
in the driver. So there can be gaps (including regions of other IP blocks)
between the clock controller blocks registers memory regions.
For example,
The serial dt node in exynos7.dtsi. serial_0 dt node use the uart clocks
in 'clock_peric0' clock domain and serial_1 dt node use the uart clocks
in 'clock-peric1' clock domain.
When using the clock in specific clock domain,
we need to phandle(e.g., clock_peric0, clock_peric1) of clock domain.
serial_0: serial@1363 {
compatible = samsung,exynos4210-uart;
reg = 0x1363 0x100;
interrupts = 0 440 0;
clocks = clock_peric0
Re: [PATCH v2 4/6] mmc: pwrseq_simple: Add optional reference clock support
On 28 January 2015 at 19:15, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
Some WLAN chips attached to a SDIO interface, need a reference clock.
Since this is very common, extend the prseq_simple driver to support
an optional clock that is enabled prior the card power up procedure.
Note: the external clock is optional. Thus an error is not returned
if the clock is not found.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v1:
- Rebase on top of latest changes.
- Use IS_ERR() instead of checking for NULL to see if the clock exists.
---
drivers/mmc/core/pwrseq_simple.c | 34 --
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/pwrseq_simple.c
b/drivers/mmc/core/pwrseq_simple.c
index e53d3c7e059c..5e34c77efa5e 100644
--- a/drivers/mmc/core/pwrseq_simple.c
+++ b/drivers/mmc/core/pwrseq_simple.c
@@ -7,6 +7,7 @@
*
* Simple MMC power sequence management
*/
+#include linux/clk.h
#include linux/kernel.h
#include linux/slab.h
#include linux/device.h
@@ -20,6 +21,7 @@
struct mmc_pwrseq_simple {
struct mmc_pwrseq pwrseq;
+ struct clk *ext_clk;
You need to add a bool, maybe call it clk_enabled; See why below.
int nr_gpios;
struct gpio_desc *reset_gpios[0];
};
@@ -39,6 +41,9 @@ static void mmc_pwrseq_simple_pre_power_on(struct mmc_host
*host)
struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
struct mmc_pwrseq_simple, pwrseq);
+ if (!IS_ERR(pwrseq-ext_clk))
+ clk_prepare_enable(pwrseq-ext_clk);
+
There are no guarantee that the -mmc_pwrseq_simple_pre_power_on()
will be invoked prior -mmc_pwrseq_simple_power_off().
That means you need to keep track of if you have gated/ungated the
clock. In other words check pwrseq-clk_enabled. That will prevent
potential clk unbalance issues.
mmc_pwrseq_simple_set_gpios_value(pwrseq, 1);
}
@@ -50,6 +55,17 @@ static void mmc_pwrseq_simple_post_power_on(struct
mmc_host *host)
mmc_pwrseq_simple_set_gpios_value(pwrseq, 0);
}
+static void mmc_pwrseq_simple_power_off(struct mmc_host *host)
+{
+ struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
+ struct mmc_pwrseq_simple, pwrseq);
+
+ mmc_pwrseq_simple_set_gpios_value(pwrseq, 1);
+
+ if (!IS_ERR(pwrseq-ext_clk))
+ clk_disable_unprepare(pwrseq-ext_clk);
Same comment as above.
+}
+
static void mmc_pwrseq_simple_free(struct mmc_host *host)
{
struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
@@ -60,6 +76,9 @@ static void mmc_pwrseq_simple_free(struct mmc_host *host)
if (!IS_ERR(pwrseq-reset_gpios[i]))
gpiod_put(pwrseq-reset_gpios[i]);
+ if (!IS_ERR(pwrseq-ext_clk))
+ clk_put(pwrseq-ext_clk);
+
kfree(pwrseq);
host-pwrseq = NULL;
}
@@ -67,7 +86,7 @@ static void mmc_pwrseq_simple_free(struct mmc_host *host)
static struct mmc_pwrseq_ops mmc_pwrseq_simple_ops = {
.pre_power_on = mmc_pwrseq_simple_pre_power_on,
.post_power_on = mmc_pwrseq_simple_post_power_on,
- .power_off = mmc_pwrseq_simple_pre_power_on,
+ .power_off = mmc_pwrseq_simple_power_off,
.free = mmc_pwrseq_simple_free,
};
@@ -85,6 +104,14 @@ int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct
device *dev)
if (!pwrseq)
return -ENOMEM;
+ pwrseq-ext_clk = clk_get(dev, ext_clock);
+ if (IS_ERR(pwrseq-ext_clk)
+ PTR_ERR(pwrseq-ext_clk) != -ENOENT
+ PTR_ERR(pwrseq-ext_clk) != -ENOSYS) {
I don't think you can get -ENOSYS.
+ ret = PTR_ERR(pwrseq-ext_clk);
+ goto free;
+ }
+
for (i = 0; i nr_gpios; i++) {
pwrseq-reset_gpios[i] = gpiod_get_index(dev, reset, i,
GPIOD_OUT_HIGH);
@@ -96,7 +123,7 @@ int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct
device *dev)
while (--i)
gpiod_put(pwrseq-reset_gpios[i]);
- goto free;
+ goto clk_put;
}
}
@@ -105,6 +132,9 @@ int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct
device *dev)
host-pwrseq = pwrseq-pwrseq;
return 0;
+clk_put:
+ if (!IS_ERR(pwrseq-ext_clk))
+ clk_put(pwrseq-ext_clk);
free:
kfree(pwrseq);
return ret;
--
2.1.3
Kind regards
Uffe
--
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 01/12] clk: samsung: exynos5433: Add clocks using common clock framework
Hi Chanwoo,
On 23/01/15 21:54, Chanwoo Choi wrote:
On Sat, Jan 24, 2015 at 2:40 AM, Sylwester Nawrocki
s.nawro...@samsung.com wrote:
On 21/01/15 07:26, Chanwoo Choi wrote:
+/* list of all parent clock list */
+PNAME(mout_bus_pll_user_p) = { fin_pll, sclk_bus_pll, };
...
+
+static struct samsung_mux_clock top_mux_clks[] __initdata = {
+ MUX(CLK_MOUT_BUS_PLL_USER, mout_bus_pll_user, mout_bus_pll_user_p,
+ MUX_SEL_TOP1, 0, 1),
...
+};
+
+static struct samsung_div_clock top_div_clks[] __initdata = {
...
+ /* DIV_TOP3 */
+ DIV(CLK_DIV_ACLK_IMEM_SSSX_266, div_aclk_imem_sssx_266,
+ mout_bus_pll_user, DIV_TOP3, 24, 3),
Shouldn't fin_pll be renamed to oscclk ? In the documentation
the root clock (from XXTI input pin) seems to be referred as OSCCLK.
And I can't see fin_pll clock registered anywhere. Shouldn't there
be a fixed-rate-clock as a parent of at least CMU_TOP? e.g.
Right,
I added fin_pll fixed clock in DT as following:
When I registered fin_pll fixed clock, I could use fin_pll clock
for exynos5433 cmu without adding additional dt node.
fin_pll: xxti {
compatible = fixed-clock;
clock-output-names = fin_pll;
#clock-cells = 0;
};
I'll add the example of fin_pll dt node to documentation for exynos5433 cmu.
OK, thanks. But I think it needs to be named oscclk, FIN_PLL is almost
not existent in the SoC's documentation.
I'd suggest to define the root oscillator clock (XXTI/OSCCLK) as oscclk
in DT, rather than registering fin_pll fixed clock in the driver.
xxti: xxti {
compatible = fixed-clock;
#clock-cells = 0;
clock-output-names = oscclk;
clock-frequency = 2400;
};
cmu_top {
clocks = xxti;
};
--
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] drm/exynos: move hdmi clk disable out of pm ops
From: Prathyush K prathyus...@samsung.com When VPLL clock of less than 140 MHz was used and all the three clocks - hdmiphy, hdmi, sclk_hdmi are disabled, the system hangs during S2R when HDMI is connected. Since we want to use a vpll clock of 70.5 MHz, we cannot disable these 3 clocks before suspending. This patch moves the clk enable/disable of hdmi and sclk_hdmi outside of the pm ops. Now system suspends and resumes with HDMI connected with VPLL set at 70.5 MHz. Signed-off-by: Prathyush K prathyus...@samsung.com Signed-off-by: Andrew Bresticker abres...@chromium.org Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk --- This work depends on the HDMI support patches from Javier: https://lkml.org/lkml/2015/1/20/235 This patch comes from a downstream tree (Google chormeOS) and it is authored by a Samsung employee, but we still think this may not fix the real cause of the bug, there might be something else that we haven't found that could be the cause of this issue. Anyone has some comment to add here? --- drivers/gpu/drm/exynos/exynos_hdmi.c | 17 +++-- 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c index 6aa0d65..7a473cb 100644 --- a/drivers/gpu/drm/exynos/exynos_hdmi.c +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c @@ -2064,9 +2064,6 @@ static void hdmi_poweron(struct exynos_drm_display *display) regmap_update_bits(hdata-pmureg, PMU_HDMI_PHY_CONTROL, PMU_HDMI_PHY_ENABLE_BIT, 1); - clk_prepare_enable(res-hdmi); - clk_prepare_enable(res-sclk_hdmi); - hdmiphy_poweron(hdata); hdmi_commit(display); } @@ -2088,9 +2085,6 @@ static void hdmi_poweroff(struct exynos_drm_display *display) cancel_delayed_work(hdata-hotplug_work); - clk_disable_unprepare(res-sclk_hdmi); - clk_disable_unprepare(res-hdmi); - /* reset pmu hdmiphy control bit to disable hdmiphy */ regmap_update_bits(hdata-pmureg, PMU_HDMI_PHY_CONTROL, PMU_HDMI_PHY_ENABLE_BIT, 0); @@ -2254,6 +2248,14 @@ static int hdmi_resources_init(struct hdmi_context *hdata) } else res-reg_hdmi_en = NULL; + /* +* These two clocks are not moved into hdmi_poweron/off since system +* fails to suspend if VPLL clock of 70.5 MHz is used and these +* clocks are disabled before suspend. So enable them here. +*/ + clk_prepare_enable(res-sclk_hdmi); + clk_prepare_enable(res-hdmi); + return ret; fail: DRM_ERROR(HDMI resource init - failed\n); @@ -2516,6 +2518,9 @@ static int hdmi_remove(struct platform_device *pdev) if (hdata-res.reg_hdmi_en) regulator_disable(hdata-res.reg_hdmi_en); + clk_disable_unprepare(hdata-res.sclk_hdmi); + clk_disable_unprepare(hdata-res.hdmi); + if (hdata-hdmiphy_port) put_device(hdata-hdmiphy_port-dev); put_device(hdata-ddc_adpt-dev); -- 1.9.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
[PATCH v4 7/7] platform/chrome: Expose Chrome OS Lightbar to users
From: Bill Richardson wfric...@chromium.org
This adds some sysfs entries to provide userspace control of the
four-element LED lightbar on the Chromebook Pixel. This only instantiates
the lightbar controls if the device actually exists.
To prevent DoS attacks, this interface is limited to 20 accesses/second,
although that rate can be adjusted by a privileged user.
On Chromebooks without a lightbar, this should have no effect. On the
Chromebook Pixel, you should be able to do things like this:
$ cd /sys/devices/virtual/chromeos/cros_ec/lightbar
$ echo 0x80 brightness
$ echo 255 brightness
$
$ cat sequence
S0
$ echo konami sequence
$ cat sequence
KONAMI
$
$ cat sequence
S0
And
$ cd /sys/devices/virtual/chromeos/cros_ec/lightbar
$ echo stop sequence
$ echo 4 255 255 255 led_rgb
$ echo 0 255 0 0 1 0 255 0 2 0 0 255 3 255 255 0 led_rgb
$ echo run sequence
Test the DoS prevention with this:
$ cd /sys/devices/virtual/chromeos/cros_ec/lightbar
$ echo 500 interval_msec
$ time (cat version version version version version version version)
Signed-off-by: Bill Richardson wfric...@chromium.org
Reviewed-by: Olof Johansson ol...@chromium.org
Tested-by: Doug Anderson diand...@chromium.org
Reviewed-by: Benson Leung ble...@chromium.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v3: None.
Changes since v2: None.
Changes since v1:
- Moved from drivers/mfd to drivers/platform/chrome.
- Modify to use the fixed-size arrays for cros_ec_command in and out buffers.
---
drivers/platform/chrome/Makefile | 2 +-
drivers/platform/chrome/cros_ec_dev.c | 2 +
drivers/platform/chrome/cros_ec_dev.h | 3 +
drivers/platform/chrome/cros_ec_lightbar.c | 367 +
4 files changed, 373 insertions(+), 1 deletion(-)
create mode 100644 drivers/platform/chrome/cros_ec_lightbar.c
diff --git a/drivers/platform/chrome/Makefile b/drivers/platform/chrome/Makefile
index 3e7980b9bc86..cc5d2f294c40 100644
--- a/drivers/platform/chrome/Makefile
+++ b/drivers/platform/chrome/Makefile
@@ -1,5 +1,5 @@
obj-$(CONFIG_CHROMEOS_LAPTOP) += chromeos_laptop.o
obj-$(CONFIG_CHROMEOS_PSTORE) += chromeos_pstore.o
-cros_ec_devs-objs := cros_ec_dev.o cros_ec_sysfs.o
+cros_ec_devs-objs := cros_ec_dev.o cros_ec_sysfs.o
cros_ec_lightbar.o
obj-$(CONFIG_CROS_EC_CHARDEV) += cros_ec_devs.o
diff --git a/drivers/platform/chrome/cros_ec_dev.c
b/drivers/platform/chrome/cros_ec_dev.c
index 33f37ad36892..ce714317a59e 100644
--- a/drivers/platform/chrome/cros_ec_dev.c
+++ b/drivers/platform/chrome/cros_ec_dev.c
@@ -200,6 +200,7 @@ static int ec_device_probe(struct platform_device *pdev)
/* Initialize extra interfaces */
ec_dev_sysfs_init(ec);
+ ec_dev_lightbar_init(ec);
return 0;
}
@@ -208,6 +209,7 @@ static int ec_device_remove(struct platform_device *pdev)
{
struct cros_ec_device *ec = dev_get_drvdata(pdev-dev.parent);
+ ec_dev_lightbar_remove(ec);
ec_dev_sysfs_remove(ec);
device_destroy(cros_class, MKDEV(ec_major, 0));
cdev_del(ec-cdev);
diff --git a/drivers/platform/chrome/cros_ec_dev.h
b/drivers/platform/chrome/cros_ec_dev.h
index f03613290ecf..45d67f7e518c 100644
--- a/drivers/platform/chrome/cros_ec_dev.h
+++ b/drivers/platform/chrome/cros_ec_dev.h
@@ -47,4 +47,7 @@ struct cros_ec_readmem {
void ec_dev_sysfs_init(struct cros_ec_device *);
void ec_dev_sysfs_remove(struct cros_ec_device *);
+void ec_dev_lightbar_init(struct cros_ec_device *);
+void ec_dev_lightbar_remove(struct cros_ec_device *);
+
#endif /* _CROS_EC_DEV_H_ */
diff --git a/drivers/platform/chrome/cros_ec_lightbar.c
b/drivers/platform/chrome/cros_ec_lightbar.c
new file mode 100644
index ..35fc892e4c95
--- /dev/null
+++ b/drivers/platform/chrome/cros_ec_lightbar.c
@@ -0,0 +1,367 @@
+/*
+ * cros_ec_lightbar - expose the Chromebook Pixel lightbar to userspace
+ *
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#define pr_fmt(fmt) cros_ec_lightbar: fmt
+
+#include linux/ctype.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/fs.h
+#include linux/kobject.h
+#include linux/mfd/cros_ec.h
+#include linux/mfd/cros_ec_commands.h
+#include
[PATCH v4 6/7] platform/chrome: Create sysfs attributes for the ChromeOS EC
From: Bill Richardson wfric...@chromium.org
This adds the first few sysfs attributes for the Chrome OS EC. These
controls are made available under /sys/devices/virtual/chromeos/cros_ec
flashinfo - display current flash info
reboot - tell the EC to reboot in various ways
version - information about the EC software and hardware
Future changes will build on this to add additional controls.
From a root shell, you should be able to do things like this:
cd /sys/devices/virtual/chromeos/cros_ec
cat flashinfo
cat version
echo rw reboot
cat version
echo ro reboot
cat version
echo rw reboot
cat version
echo cold reboot
That last command will reboot the AP too.
Signed-off-by: Bill Richardson wfric...@chromium.org
Reviewed-by: Olof Johansson ol...@chromium.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v3: None.
Changes since v2: None.
Changes since v1:
- Moved from drivers/mfd to drivers/platform/chrome. Suggested by Lee Jones.
- Modify to use the fixed-size arrays for cros_ec_command in and out buffers.
---
drivers/platform/chrome/Makefile| 3 +-
drivers/platform/chrome/cros_ec_dev.c | 4 +
drivers/platform/chrome/cros_ec_dev.h | 3 +
drivers/platform/chrome/cros_ec_sysfs.c | 271
4 files changed, 280 insertions(+), 1 deletion(-)
create mode 100644 drivers/platform/chrome/cros_ec_sysfs.c
diff --git a/drivers/platform/chrome/Makefile b/drivers/platform/chrome/Makefile
index 10f1361a97b4..3e7980b9bc86 100644
--- a/drivers/platform/chrome/Makefile
+++ b/drivers/platform/chrome/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_CHROMEOS_LAPTOP) += chromeos_laptop.o
obj-$(CONFIG_CHROMEOS_PSTORE) += chromeos_pstore.o
-obj-$(CONFIG_CROS_EC_CHARDEV) += cros_ec_dev.o
+cros_ec_devs-objs := cros_ec_dev.o cros_ec_sysfs.o
+obj-$(CONFIG_CROS_EC_CHARDEV) += cros_ec_devs.o
diff --git a/drivers/platform/chrome/cros_ec_dev.c
b/drivers/platform/chrome/cros_ec_dev.c
index 94c1442d5104..33f37ad36892 100644
--- a/drivers/platform/chrome/cros_ec_dev.c
+++ b/drivers/platform/chrome/cros_ec_dev.c
@@ -198,6 +198,9 @@ static int ec_device_probe(struct platform_device *pdev)
return retval;
}
+ /* Initialize extra interfaces */
+ ec_dev_sysfs_init(ec);
+
return 0;
}
@@ -205,6 +208,7 @@ static int ec_device_remove(struct platform_device *pdev)
{
struct cros_ec_device *ec = dev_get_drvdata(pdev-dev.parent);
+ ec_dev_sysfs_remove(ec);
device_destroy(cros_class, MKDEV(ec_major, 0));
cdev_del(ec-cdev);
return 0;
diff --git a/drivers/platform/chrome/cros_ec_dev.h
b/drivers/platform/chrome/cros_ec_dev.h
index 15c54c4c5531..f03613290ecf 100644
--- a/drivers/platform/chrome/cros_ec_dev.h
+++ b/drivers/platform/chrome/cros_ec_dev.h
@@ -44,4 +44,7 @@ struct cros_ec_readmem {
#define CROS_EC_DEV_IOCXCMD _IOWR(CROS_EC_DEV_IOC, 0, struct cros_ec_command)
#define CROS_EC_DEV_IOCRDMEM _IOWR(CROS_EC_DEV_IOC, 1, struct cros_ec_readmem)
+void ec_dev_sysfs_init(struct cros_ec_device *);
+void ec_dev_sysfs_remove(struct cros_ec_device *);
+
#endif /* _CROS_EC_DEV_H_ */
diff --git a/drivers/platform/chrome/cros_ec_sysfs.c
b/drivers/platform/chrome/cros_ec_sysfs.c
new file mode 100644
index ..fb62ab6cc659
--- /dev/null
+++ b/drivers/platform/chrome/cros_ec_sysfs.c
@@ -0,0 +1,271 @@
+/*
+ * cros_ec_sysfs - expose the Chrome OS EC through sysfs
+ *
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#define pr_fmt(fmt) cros_ec_sysfs: fmt
+
+#include linux/ctype.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/fs.h
+#include linux/kobject.h
+#include linux/mfd/cros_ec.h
+#include linux/mfd/cros_ec_commands.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/printk.h
+#include linux/stat.h
+#include linux/types.h
+#include linux/uaccess.h
+
+#include cros_ec_dev.h
+
+/* Accessor functions */
+
+static ssize_t show_ec_reboot(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ int count = 0;
+
+ count += scnprintf(buf + count, PAGE_SIZE - count,
+ ro|rw|cancel|cold|disable-jump|hibernate);
+ count +=
[PATCH v4 4/7] platform/chrome: Add Chrome OS EC userspace device interface
From: Bill Richardson wfric...@chromium.org This patch adds a device interface to access the Chrome OS Embedded Controller from user-space. Signed-off-by: Bill Richardson wfric...@chromium.org Reviewed-by: Simon Glass s...@google.com Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Reviewed-by: Gwendal Grignou gwen...@chromium.org --- Changes since v3: None. Changes since v2: - Rename the devname to cros-ec-ctl. Suggested by Lee Jones. - Added Gwendal Grignou Reviewed-by tag. Changes since v1: None, new patch. --- Documentation/ioctl/ioctl-number.txt | 1 + drivers/platform/chrome/Kconfig | 14 +- drivers/platform/chrome/Makefile | 1 + drivers/platform/chrome/cros_ec_dev.c | 268 ++ drivers/platform/chrome/cros_ec_dev.h | 47 ++ 5 files changed, 328 insertions(+), 3 deletions(-) create mode 100644 drivers/platform/chrome/cros_ec_dev.c create mode 100644 drivers/platform/chrome/cros_ec_dev.h diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index 8136e1fd30fd..51f4221657bf 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -321,6 +321,7 @@ Code Seq#(hex) Include FileComments 0xDB 00-0F drivers/char/mwave/mwavepub.h 0xDD 00-3F ZFCP device driver see drivers/s390/scsi/ mailto:aherr...@de.ibm.com +0xEC 00-01 drivers/platform/chrome/cros_ec_dev.h ChromeOS EC driver 0xF3 00-3F drivers/usb/misc/sisusbvga/sisusb.h sisfb (in development) mailto:tho...@winischhofer.net 0xF4 00-1F video/mbxfb.h mbxfb diff --git a/drivers/platform/chrome/Kconfig b/drivers/platform/chrome/Kconfig index 440ed776efd4..75dc514915ff 100644 --- a/drivers/platform/chrome/Kconfig +++ b/drivers/platform/chrome/Kconfig @@ -4,7 +4,7 @@ menuconfig CHROME_PLATFORMS bool Platform support for Chrome hardware - depends on X86 + depends on X86 || ARM ---help--- Say Y here to get to see options for platform support for various Chromebooks and Chromeboxes. This option alone does @@ -16,8 +16,7 @@ if CHROME_PLATFORMS config CHROMEOS_LAPTOP tristate Chrome OS Laptop - depends on I2C - depends on DMI + depends on I2C DMI X86 ---help--- This driver instantiates i2c and smbus devices such as light sensors and touchpads. @@ -27,6 +26,7 @@ config CHROMEOS_LAPTOP config CHROMEOS_PSTORE tristate Chrome OS pstore support + depends on X86 ---help--- This module instantiates the persistent storage on x86 ChromeOS devices. It can be used to store away console logs and crash @@ -38,5 +38,13 @@ config CHROMEOS_PSTORE If you have a supported Chromebook, choose Y or M here. The module will be called chromeos_pstore. +config CROS_EC_CHARDEV +tristate Chrome OS Embedded Controller userspace device interface +depends on MFD_CROS_EC +---help--- + This driver adds support to talk with the ChromeOS EC from userspace. + + If you have a supported Chromebook, choose Y or M here. + The module will be called cros_ec_dev. endif # CHROMEOS_PLATFORMS diff --git a/drivers/platform/chrome/Makefile b/drivers/platform/chrome/Makefile index 2b860ca7450f..10f1361a97b4 100644 --- a/drivers/platform/chrome/Makefile +++ b/drivers/platform/chrome/Makefile @@ -1,3 +1,4 @@ obj-$(CONFIG_CHROMEOS_LAPTOP) += chromeos_laptop.o obj-$(CONFIG_CHROMEOS_PSTORE) += chromeos_pstore.o +obj-$(CONFIG_CROS_EC_CHARDEV) += cros_ec_dev.o diff --git a/drivers/platform/chrome/cros_ec_dev.c b/drivers/platform/chrome/cros_ec_dev.c new file mode 100644 index ..94c1442d5104 --- /dev/null +++ b/drivers/platform/chrome/cros_ec_dev.c @@ -0,0 +1,268 @@ +/* + * cros_ec_dev - expose the Chrome OS Embedded Controller to user-space + * + * Copyright (C) 2014 Google, Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. If not, see http://www.gnu.org/licenses/. + */ + +#include linux/fs.h +#include linux/module.h +#include linux/platform_device.h +#include linux/uaccess.h + +#include cros_ec_dev.h + +/* Device variables */ +#define CROS_MAX_DEV 128 +static struct class *cros_class; +static int ec_major; + +/* Basic
[PATCH v4 3/7] misc: Add cros_ec_lpc driver for x86 devices
From: Bill Richardson wfric...@chromium.org
Chromebooks have an Embedded Controller (EC) that is used to
implement various functions such as keyboard, power and battery.
The AP can communicate with the EC through different bus types
such as I2C, SPI or LPC.
The cros_ec mfd driver is then composed of a core driver that
register the sub-devices as mfd cells and provide a high level
communication interface that is used by the rest of the kernel
and bus specific interfaces modules.
Each connection method then has its own driver, which register
with the EC driver interface-agnostic interface.
Currently, there are drivers to communicate with the EC over
I2C and SPI and this driver adds support for LPC.
Signed-off-by: Bill Richardson wfric...@chromium.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v3:
- Rename MYNAME to DRV_NAME
- Use devm_request_region() instead of request_region.
Suggested by Varka Bhadram.
- Remove release_region from cleanup handle logic by using devres API.
Suggested by Varka Bhadram.
- Use {dev,pr}_err() instead of {dev,pr}_warn() to log errors.
Changes since v2:
- Move out from drivers/mfd to drivers/misc. Suggested by Lee Jones.
Changes since v1: None, new patch.
---
drivers/misc/Kconfig | 10 ++
drivers/misc/Makefile | 1 +
drivers/misc/cros_ec_lpc.c | 291 +
3 files changed, 302 insertions(+)
create mode 100644 drivers/misc/cros_ec_lpc.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 006242c8bca0..142393e84a43 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -515,6 +515,16 @@ config VEXPRESS_SYSCFG
bus. System Configuration interface is one of the possible means
of generating transactions on this bus.
+config CROS_EC_LPC
+ tristate ChromeOS Embedded Controller (LPC)
+ depends on MFD_CROS_EC
+
+ help
+ If you say Y here, you get support for talking to the ChromeOS EC
+ over an LPC bus. This uses a simple byte-level protocol with a
+ checksum. This is used for userspace access only. The kernel
+ typically has its own communication methods.
+
source drivers/misc/c2port/Kconfig
source drivers/misc/eeprom/Kconfig
source drivers/misc/cb710/Kconfig
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 7d5c4cd118c4..37a9647e7900 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -55,4 +55,5 @@ obj-y += mic/
obj-$(CONFIG_GENWQE) += genwqe/
obj-$(CONFIG_ECHO) += echo/
obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
+obj-$(CONFIG_CROS_EC_LPC) += cros_ec_lpc.o
obj-$(CONFIG_CXL_BASE) += cxl/
diff --git a/drivers/misc/cros_ec_lpc.c b/drivers/misc/cros_ec_lpc.c
new file mode 100644
index ..ff6ce5e489c4
--- /dev/null
+++ b/drivers/misc/cros_ec_lpc.c
@@ -0,0 +1,291 @@
+/*
+ * cros_ec_lpc - LPC access to the Chrome OS Embedded Controller
+ *
+ * Copyright (C) 2012-2015 Google, Inc
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * This driver uses the Chrome OS EC byte-level message-based protocol for
+ * communicating the keyboard state (which keys are pressed) from a keyboard EC
+ * to the AP over some bus (such as i2c, lpc, spi). The EC does debouncing,
+ * but everything else (including deghosting) is done here. The main
+ * motivation for this is to keep the EC firmware as simple as possible, since
+ * it cannot be easily upgraded and EC flash/IRAM space is relatively
+ * expensive.
+ */
+
+#include linux/delay.h
+#include linux/mfd/cros_ec.h
+#include linux/mfd/cros_ec_commands.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/printk.h
+
+#define DRV_NAME cros_ec_lpc
+
+static int ec_response_timed_out(void)
+{
+ unsigned long one_second = jiffies + HZ;
+
+ usleep_range(200, 300);
+ do {
+ if (!(inb(EC_LPC_ADDR_HOST_CMD) EC_LPC_STATUS_BUSY_MASK))
+ return 0;
+ usleep_range(100, 200);
+ } while (time_before(jiffies, one_second));
+
+ return 1;
+}
+
+static int cros_ec_cmd_xfer_lpc(struct cros_ec_device *ec,
+ struct cros_ec_command *msg)
+{
+ struct ec_lpc_host_args args;
+ int csum;
+ int i;
+ int ret = 0;
+
+ if (msg-outsize EC_PROTO2_MAX_PARAM_SIZE ||
+ msg-insize EC_PROTO2_MAX_PARAM_SIZE) {
+ dev_err(ec-dev,
+ invalid buffer sizes
[PATCH v4 2/7] mfd: cros_ec: Add char dev and virtual dev pointers
The ChromeOS Embedded Controller has to be accessed by applications.
A virtual character device is used as an interface with user-space.
Extend the struct cros_ec_device with the fields needed by the driver
of this virtual character device.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Lee Jones lee.jo...@linaro.org
---
Changes since v3: None.
Changes since v2: None, added Lee Jones Acked-by tag.
Changes since v1: None, new patch.
---
include/linux/mfd/cros_ec.h | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index 71675b14b5ca..324a34683971 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -16,6 +16,7 @@
#ifndef __LINUX_MFD_CROS_EC_H
#define __LINUX_MFD_CROS_EC_H
+#include linux/cdev.h
#include linux/notifier.h
#include linux/mfd/cros_ec_commands.h
#include linux/mutex.h
@@ -59,9 +60,17 @@ struct cros_ec_command {
*
* @ec_name: name of EC device (e.g. 'chromeos-ec')
* @phys_name: name of physical comms layer (e.g. 'i2c-4')
- * @dev: Device pointer
+ * @dev: Device pointer for physical comms device
+ * @vdev: Device pointer for virtual comms device
+ * @cdev: Character device structure for virtual comms device
* @was_wake_device: true if this device was set to wake the system from
* sleep at the last suspend
+ * @cmd_readmem: direct read of the EC memory-mapped region, if supported
+ * @offset is within EC_LPC_ADDR_MEMMAP region.
+ * @bytes: number of bytes to read. zero means read a string (including
+ * the trailing '\0'). At most only EC_MEMMAP_SIZE bytes can be read.
+ * Caller must ensure that the buffer is large enough for the result when
+ * reading a string.
*
* @priv: Private data
* @irq: Interrupt to use
@@ -90,8 +99,12 @@ struct cros_ec_device {
const char *ec_name;
const char *phys_name;
struct device *dev;
+ struct device *vdev;
+ struct cdev cdev;
bool was_wake_device;
struct class *cros_class;
+ int (*cmd_readmem)(struct cros_ec_device *ec, unsigned int offset,
+ unsigned int bytes, void *dest);
/* These are used to implement the platform-specific interface */
void *priv;
--
2.1.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
[PATCH v4 1/7] mfd: cros_ec: Use fixed size arrays to transfer data with the EC
The struct cros_ec_command will be used as an ioctl() argument for the
API to control the ChromeOS EC from user-space. So the data structure
has to be 64-bit safe to make it compatible between 32 and 64 avoiding
the need for a compat ioctl interface. Since pointers are self-aligned
to different byte boundaries, use fixed size arrays instead of pointers
for transferring ingoing and outgoing data with the Embedded Controller.
Also, re-arrange struct members by decreasing alignment requirements to
reduce the needing padding size.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Lee Jones lee.jo...@linaro.org
---
Hello,
I choose EC_PROTO2_MAX_PARAM_SIZE as the maximum length for the input and
output buffers since I see that is what is assumed in the cros_ec driver
that is the maximum lengths. But the downstream kernel has also suppport
for the EC host command protocol v3 even though there is currently no bus
specific code to handle v3 packets. So I wonder if this is a good max len
or if a different size should be used instead.
Best regards,
Javier
Changes since v3: None.
Changes since v2: None, added Lee Jones Acked-by tag.
Changes since v1: None, new patch
---
drivers/i2c/busses/i2c-cros-ec-tunnel.c | 51 +++--
drivers/input/keyboard/cros_ec_keyb.c | 13 +
drivers/mfd/cros_ec.c | 15 +-
include/linux/mfd/cros_ec.h | 8 +++---
4 files changed, 29 insertions(+), 58 deletions(-)
diff --git a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
index 875c22ae5400..fa8dedd8c3a2 100644
--- a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
+++ b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
@@ -182,72 +182,41 @@ static int ec_i2c_xfer(struct i2c_adapter *adap, struct
i2c_msg i2c_msgs[],
const u16 bus_num = bus-remote_bus;
int request_len;
int response_len;
- u8 *request = NULL;
- u8 *response = NULL;
int result;
- struct cros_ec_command msg;
+ struct cros_ec_command msg = { };
request_len = ec_i2c_count_message(i2c_msgs, num);
if (request_len 0) {
dev_warn(dev, Error constructing message %d\n, request_len);
- result = request_len;
- goto exit;
+ return request_len;
}
+
response_len = ec_i2c_count_response(i2c_msgs, num);
if (response_len 0) {
/* Unexpected; no errors should come when NULL response */
dev_warn(dev, Error preparing response %d\n, response_len);
- result = response_len;
- goto exit;
- }
-
- if (request_len = ARRAY_SIZE(bus-request_buf)) {
- request = bus-request_buf;
- } else {
- request = kzalloc(request_len, GFP_KERNEL);
- if (request == NULL) {
- result = -ENOMEM;
- goto exit;
- }
- }
- if (response_len = ARRAY_SIZE(bus-response_buf)) {
- response = bus-response_buf;
- } else {
- response = kzalloc(response_len, GFP_KERNEL);
- if (response == NULL) {
- result = -ENOMEM;
- goto exit;
- }
+ return response_len;
}
- result = ec_i2c_construct_message(request, i2c_msgs, num, bus_num);
+ result = ec_i2c_construct_message(msg.outdata, i2c_msgs, num, bus_num);
if (result)
- goto exit;
+ return result;
msg.version = 0;
msg.command = EC_CMD_I2C_PASSTHRU;
- msg.outdata = request;
msg.outsize = request_len;
- msg.indata = response;
msg.insize = response_len;
result = cros_ec_cmd_xfer(bus-ec, msg);
if (result 0)
- goto exit;
+ return result;
- result = ec_i2c_parse_response(response, i2c_msgs, num);
+ result = ec_i2c_parse_response(msg.indata, i2c_msgs, num);
if (result 0)
- goto exit;
+ return result;
/* Indicate success by saying how many messages were sent */
- result = num;
-exit:
- if (request != bus-request_buf)
- kfree(request);
- if (response != bus-response_buf)
- kfree(response);
-
- return result;
+ return num;
}
static u32 ec_i2c_functionality(struct i2c_adapter *adap)
diff --git a/drivers/input/keyboard/cros_ec_keyb.c
b/drivers/input/keyboard/cros_ec_keyb.c
index ffa989f2c785..769f8f7f62b7 100644
--- a/drivers/input/keyboard/cros_ec_keyb.c
+++ b/drivers/input/keyboard/cros_ec_keyb.c
@@ -148,16 +148,19 @@ static void cros_ec_keyb_process(struct cros_ec_keyb
*ckdev,
static int cros_ec_keyb_get_state(struct cros_ec_keyb *ckdev, uint8_t
*kb_state)
{
+ int ret;
struct cros_ec_command msg = {
- .version = 0,
Re: [PATCH 3/3] cpufreq: exynos: allow modular build
On Thursday 29 January 2015 15:40:15 Viresh Kumar wrote: obj-$(CONFIG_ARCH_DAVINCI) += davinci-cpufreq.o obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o -obj-$(CONFIG_ARM_EXYNOS_CPUFREQ) += exynos-cpufreq.o -obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos4210-cpufreq.o -obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) += exynos4x12-cpufreq.o -obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos5250-cpufreq.o +obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos-cpufreq.o exynos4210-cpufreq.o +obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) += exynos-cpufreq.o exynos4x12-cpufreq.o +obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos-cpufreq.o exynos5250-cpufreq.o I'd have to try it, but this might fail if one of the three drivers is built-in and another one is a module. 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 v4 5/7] mfd: cros_ec: Instantiate ChromeOS EC character device
The ChromeOS EC character device is an user-space interface to
allow applications to access the Embedded Controller.
Add a cell for this device so it's spawned from the mfd driver.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Lee Jones lee.jo...@linaro.org
---
Changes since v3: None, added Acked-by tag from Lee Jones.
Changes since v2:
- Rename the name to cros-ec-ctl. Suggested by Lee Jones.
Changes since v1: None, new patch.
---
drivers/mfd/cros_ec.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index c872e1b0eaf8..c4aecc6f8373 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -118,6 +118,10 @@ static const struct mfd_cell cros_devs[] = {
.id = 2,
.of_compatible = google,cros-ec-i2c-tunnel,
},
+ {
+ .name = cros-ec-ctl,
+ .id = 3,
+ },
};
int cros_ec_register(struct cros_ec_device *ec_dev)
--
2.1.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
[PATCH v4 0/7] platform/chrome: Add user-space dev inferface support
Hello, The mainline ChromeOS Embedded Controller (EC) driver is still missing some features that are present in the downstream ChromiumOS tree. These are: - Low Pin Count (LPC) interface - User-space device interface - Access to vboot context stored on a block device - Access to vboot context stored on EC's nvram - Power Delivery Device - Support for multiple EC in a system This is a fourth version of a series that adds support for the first two of the missing features: the EC LPC and EC character device interfaces that are used by user-space to access the ChromeOS EC. The support patches were taken from the downstream ChromiumOS 3.14 tree with the fixes and cleanups squashed to have a minimal patch-set. The version of the ChromeOS EC chardev driver in this series still does not reflect the latest one that is in the downstream ChromiumOS 3.14 kernel but makes the delta shorter. Following patches will add the remaining missing features until both trees are in sync. I preferred to first add the initial support and then adding the other features to both maintain the original patch history in the downstream kernel and so preserve the patch authorship and also make the diff to have a working cros user-space interface smaller. This version solves the issues pointed out in the earlier revision. A big difference between this series and the downstream ChromiumOS kernel is that the ioctl API is modified to make it 64-bit safe and compatible with both 64 and 32 bit user-space binaries. The data structures passed as arguments in the ChromiumOS ioctl interface commands has pointers fields and since these have different byte boundaries alignment requirement, the ChromiumOS driver has a compat ioctl interface. The feedback was that this had to be avoided since this was a new ioctl API so the pointers fields were replaced with a set of fixed-size arrays to be used instead. This has the drawback that more data could be used and copied between user and kernel space so feedback is welcomed if there is a better approach to solve this kind of issues. The patches were tested on an Exynos5420 Peach Pit Chromebook and (thanks to Bill Richardson) on an x86 Pixel Chromebook using a modified ectool [0] to use the new ioctl API. The LPC interface driver and the lightbar sysfs driver were also tested on the Pixel Chromebook. The series is composed of the following patches: Bill Richardson (4): misc: Add cros_ec_lpc driver for x86 devices platform/chrome: Add Chrome OS EC userspace device interface platform/chrome: Create sysfs attributes for the ChromeOS EC platform/chrome: Expose Chrome OS Lightbar to users Javier Martinez Canillas (3): mfd: cros_ec: Use fixed size arrays to transfer data with the EC mfd: cros_ec: Add char dev and virtual dev pointers mfd: cros_ec: Instantiate ChromeOS EC character device Documentation/ioctl/ioctl-number.txt | 1 + drivers/i2c/busses/i2c-cros-ec-tunnel.c| 51 +--- drivers/input/keyboard/cros_ec_keyb.c | 13 +- drivers/mfd/cros_ec.c | 19 +- drivers/misc/Kconfig | 10 + drivers/misc/Makefile | 1 + drivers/misc/cros_ec_lpc.c | 291 +++ drivers/platform/chrome/Kconfig| 14 +- drivers/platform/chrome/Makefile | 2 + drivers/platform/chrome/cros_ec_dev.c | 274 + drivers/platform/chrome/cros_ec_dev.h | 53 + drivers/platform/chrome/cros_ec_lightbar.c | 367 + drivers/platform/chrome/cros_ec_sysfs.c| 271 + include/linux/mfd/cros_ec.h| 23 +- 14 files changed, 1328 insertions(+), 62 deletions(-) create mode 100644 drivers/misc/cros_ec_lpc.c create mode 100644 drivers/platform/chrome/cros_ec_dev.c create mode 100644 drivers/platform/chrome/cros_ec_dev.h create mode 100644 drivers/platform/chrome/cros_ec_lightbar.c create mode 100644 drivers/platform/chrome/cros_ec_sysfs.c Patch #1 modified the struct cros_ec_command structure so it can be used as an ioctl argument and be 64 and 32 bit safe and patch #2 adds fields to the struct cros_ec_device that will be needed by the EC chardev driver. Patch #3 adds support for the EC LPC interface used on x86 Chromebooks. Patch #4 adds the ChromeOS chardev driver and patch #5 instantiates it from the mfd cros_ec driver. Patch #6 exposes sysfs attributes that can be used by user space programs to get information and control the ChromeOS EC. Patch #7 exposes sysfs attributes that are used to control the lightbar RGB LEDs found on the Pixel Chromebook. The patches must be applied together and in that order due dependencies. Lee Jones has already acked the MFD changes so I think this could go through the chrome-platform.git tree. Best regards, Javier [0]: git://git.collabora.co.uk/git/user/javier/ec.git mainline-ioctl -- To unsubscribe from this list: send the line
Re: [PATCH v4 3/7] misc: Add cros_ec_lpc driver for x86 devices
On Thu, Jan 29, 2015 at 7:07 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
From: Bill Richardson wfric...@chromium.org
Chromebooks have an Embedded Controller (EC) that is used to
implement various functions such as keyboard, power and battery.
The AP can communicate with the EC through different bus types
such as I2C, SPI or LPC.
The cros_ec mfd driver is then composed of a core driver that
register the sub-devices as mfd cells and provide a high level
communication interface that is used by the rest of the kernel
and bus specific interfaces modules.
Each connection method then has its own driver, which register
with the EC driver interface-agnostic interface.
Currently, there are drivers to communicate with the EC over
I2C and SPI and this driver adds support for LPC.
Signed-off-by: Bill Richardson wfric...@chromium.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v3:
- Rename MYNAME to DRV_NAME
- Use devm_request_region() instead of request_region.
Suggested by Varka Bhadram.
- Remove release_region from cleanup handle logic by using devres API.
Suggested by Varka Bhadram.
- Use {dev,pr}_err() instead of {dev,pr}_warn() to log errors.
Addressed all of my comments... Thanks
Reviewed-by: Varka Bhadram varkabhad...@gmail.com
--
Regards,
Varka Bhadram.
--
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 V9 04/14] drm/bridge: ptn3460: Convert to i2c driver model
Hi Ajay, 2015-01-20 Ajay Kumar ajaykumar...@samsung.com: Use drm_bridge helpers to modify the driver to support i2c driver model. Signed-off-by: Ajay Kumar ajaykumar...@samsung.com Acked-by: Inki Dae inki@samsung.com Tested-by: Rahul Sharma rahul.sha...@samsung.com Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Tested-by: Gustavo Padovan gustavo.pado...@collabora.co.uk Tested-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk --- drivers/gpu/drm/bridge/Kconfig |2 + drivers/gpu/drm/bridge/ptn3460.c| 124 +-- drivers/gpu/drm/exynos/exynos_dp_core.c | 22 -- 3 files changed, 86 insertions(+), 62 deletions(-) diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 884923f..4254c2b 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -1,5 +1,7 @@ config DRM_PTN3460 tristate PTN3460 DP/LVDS bridge depends on DRM + depends on OF I2C Adding I2C here is causing this circular dependency: scripts/kconfig/conf --silentoldconfig Kconfig drivers/video/fbdev/Kconfig:5:error: recursive dependency detected! drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by DRM_PTN3460 drivers/gpu/drm/bridge/Kconfig:1: symbol DRM_PTN3460 depends on I2C drivers/i2c/Kconfig:7: symbol I2C is selected by FB_DDC drivers/video/fbdev/Kconfig:59: symbol FB_DDC is selected by FB_CYBER2000_DDC drivers/video/fbdev/Kconfig:374:symbol FB_CYBER2000_DDC depends on FB_CYBER2000 drivers/video/fbdev/Kconfig:362:symbol FB_CYBER2000 depends on FB To solve this we just need to remove I2C from depends as DRM already selects I2C. This was already fixed by: commit 90bde571ad194adb039cb92a11a5b346f15eb610 Author: Arnd Bergmann a...@arndb.de Date: Tue Mar 25 12:06:46 2014 +0100 drm/bridge: PTN3460 needs DRM_KMS_HELPER The recently added PTN3460 device driver uses interfaces that are provided by the KMS helper infrastructure, so we should explicitly select that to avoid this linker error: ERROR: drm_helper_probe_single_connector_modes [drivers/gpu/drm/bridge/ptn3460.ko] undefined! ERROR: drm_helper_connector_dpms [drivers/gpu/drm/bridge/ptn3460.ko] undefined! We have to drop the I2C dependency to avoid a circular dependency chain, but that's ok because DRM already selects I2C. Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Dave Airlie airl...@redhat.com But you may have introduced it again on a rebase. The following patch fixes it: diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 990b4b2..946d1ef 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -1,7 +1,6 @@ config DRM_PTN3460 tristate PTN3460 DP/LVDS bridge - depends on DRM - depends on OF I2C + depends on DRM OF select DRM_KMS_HELPER select DRM_PANEL ---help--- Gustavo -- 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 V9 04/14] drm/bridge: ptn3460: Convert to i2c driver model
Hi Gustavo, I think Thierry already fixed it. Check this. http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/bridge/Kconfig Regards, Ajay On Thu, Jan 29, 2015 at 7:59 PM, Gustavo Padovan gust...@padovan.org wrote: Hi Ajay, 2015-01-20 Ajay Kumar ajaykumar...@samsung.com: Use drm_bridge helpers to modify the driver to support i2c driver model. Signed-off-by: Ajay Kumar ajaykumar...@samsung.com Acked-by: Inki Dae inki@samsung.com Tested-by: Rahul Sharma rahul.sha...@samsung.com Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Tested-by: Gustavo Padovan gustavo.pado...@collabora.co.uk Tested-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk --- drivers/gpu/drm/bridge/Kconfig |2 + drivers/gpu/drm/bridge/ptn3460.c| 124 +-- drivers/gpu/drm/exynos/exynos_dp_core.c | 22 -- 3 files changed, 86 insertions(+), 62 deletions(-) diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 884923f..4254c2b 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -1,5 +1,7 @@ config DRM_PTN3460 tristate PTN3460 DP/LVDS bridge depends on DRM + depends on OF I2C Adding I2C here is causing this circular dependency: scripts/kconfig/conf --silentoldconfig Kconfig drivers/video/fbdev/Kconfig:5:error: recursive dependency detected! drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by DRM_PTN3460 drivers/gpu/drm/bridge/Kconfig:1: symbol DRM_PTN3460 depends on I2C drivers/i2c/Kconfig:7: symbol I2C is selected by FB_DDC drivers/video/fbdev/Kconfig:59: symbol FB_DDC is selected by FB_CYBER2000_DDC drivers/video/fbdev/Kconfig:374:symbol FB_CYBER2000_DDC depends on FB_CYBER2000 drivers/video/fbdev/Kconfig:362:symbol FB_CYBER2000 depends on FB To solve this we just need to remove I2C from depends as DRM already selects I2C. This was already fixed by: commit 90bde571ad194adb039cb92a11a5b346f15eb610 Author: Arnd Bergmann a...@arndb.de Date: Tue Mar 25 12:06:46 2014 +0100 drm/bridge: PTN3460 needs DRM_KMS_HELPER The recently added PTN3460 device driver uses interfaces that are provided by the KMS helper infrastructure, so we should explicitly select that to avoid this linker error: ERROR: drm_helper_probe_single_connector_modes [drivers/gpu/drm/bridge/ptn3460.ko] undefined! ERROR: drm_helper_connector_dpms [drivers/gpu/drm/bridge/ptn3460.ko] undefined! We have to drop the I2C dependency to avoid a circular dependency chain, but that's ok because DRM already selects I2C. Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Dave Airlie airl...@redhat.com But you may have introduced it again on a rebase. The following patch fixes it: diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 990b4b2..946d1ef 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -1,7 +1,6 @@ config DRM_PTN3460 tristate PTN3460 DP/LVDS bridge - depends on DRM - depends on OF I2C + depends on DRM OF select DRM_KMS_HELPER select DRM_PANEL ---help--- Gustavo -- 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 V9 12/14] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge
Hi Thierry,
I think you forgot to take this patch!
Can you check this?
Regards,
Ajay Kumar
On Tue, Jan 20, 2015 at 10:08 PM, Ajay Kumar ajaykumar...@samsung.com wrote:
From: Vincent Palatin vpala...@chromium.org
This patch adds drm_bridge driver for parade DisplayPort
to LVDS bridge chip.
Signed-off-by: Vincent Palatin vpala...@chromium.org
Signed-off-by: Andrew Bresticker abres...@chromium.org
Signed-off-by: Sean Paul seanp...@chromium.org
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Acked-by: Inki Dae inki@samsung.com
Tested-by: Rahul Sharma rahul.sha...@samsung.com
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
Tested-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
drivers/gpu/drm/bridge/Kconfig |9 +
drivers/gpu/drm/bridge/Makefile |1 +
drivers/gpu/drm/bridge/ps8622.c | 684
+++
3 files changed, 694 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/ps8622.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 8b426e2..d06eda3 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -6,3 +6,12 @@ config DRM_PTN3460
select DRM_PANEL
---help---
ptn3460 eDP-LVDS bridge chip driver.
+
+config DRM_PS8622
+ tristate Parade eDP/LVDS bridge
+ depends on OF I2C
+ select DRM_PANEL
+ select BACKLIGHT_LCD_SUPPORT
+ select BACKLIGHT_CLASS_DEVICE
+ ---help---
+ parade eDP-LVDS bridge chip driver.
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index b4733e1..105da3e 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,3 +1,4 @@
ccflags-y := -Iinclude/drm
+obj-$(CONFIG_DRM_PS8622) += ps8622.o
obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
new file mode 100644
index 000..5474a39
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ps8622.c
@@ -0,0 +1,684 @@
+/*
+ * Parade PS8622 eDP/LVDS bridge driver
+ *
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/backlight.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/fb.h
+#include linux/gpio.h
+#include linux/i2c.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/of_graph.h
+#include linux/pm.h
+#include linux/regulator/consumer.h
+
+#include drm/drm_panel.h
+
+#include drmP.h
+#include drm_crtc.h
+#include drm_crtc_helper.h
+
+/* Brightness scale on the Parade chip */
+#define PS8622_MAX_BRIGHTNESS 0xff
+
+/* Timings taken from the version 1.7 datasheet for the PS8622/PS8625 */
+#define PS8622_POWER_RISE_T1_MIN_US 10
+#define PS8622_POWER_RISE_T1_MAX_US 1
+#define PS8622_RST_HIGH_T2_MIN_US 3000
+#define PS8622_RST_HIGH_T2_MAX_US 3
+#define PS8622_PWMO_END_T12_MS 200
+#define PS8622_POWER_FALL_T16_MAX_US 1
+#define PS8622_POWER_OFF_T17_MS 500
+
+#if ((PS8622_RST_HIGH_T2_MIN_US + PS8622_POWER_RISE_T1_MAX_US) \
+ (PS8622_RST_HIGH_T2_MAX_US + PS8622_POWER_RISE_T1_MIN_US))
+#error T2.min + T1.max must be less than T2.max + T1.min
+#endif
+
+struct ps8622_bridge {
+ struct drm_connector connector;
+ struct i2c_client *client;
+ struct drm_bridge bridge;
+ struct drm_panel *panel;
+ struct regulator *v12;
+ struct backlight_device *bl;
+
+ struct gpio_desc *gpio_slp;
+ struct gpio_desc *gpio_rst;
+
+ u32 max_lane_count;
+ u32 lane_count;
+
+ bool enabled;
+};
+
+static inline struct ps8622_bridge *
+ bridge_to_ps8622(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct ps8622_bridge, bridge);
+}
+
+static inline struct ps8622_bridge *
+ connector_to_ps8622(struct drm_connector *connector)
+{
+ return container_of(connector, struct ps8622_bridge, connector);
+}
+
+static int ps8622_set(struct i2c_client *client, u8 page, u8 reg, u8 val)
+{
+ int ret;
+ struct i2c_adapter *adap = client-adapter;
+ struct i2c_msg msg;
+ u8 data[] = {reg, val};
+
+ msg.addr = client-addr + page;
+ msg.flags = 0;
+ msg.len = sizeof(data);
+ msg.buf = data;
+
+ ret =
Re: [PATCH] ASoC: Samsung: add missing I2C/SPI dependencies
On Thursday 29 January 2015 11:41:34 Mark Brown wrote: On Wed, Jan 28, 2015 at 10:28:55PM +0100, Arnd Bergmann wrote: The SND_SOC_ARNDALE_RT5631_ALC5631 selects the rt5631 codec that requires I2C to work, so we get a build error if I2C is disabled: You rather buried the lead about there being other drivers in this changelog, makes the code a bit surprising when you find it. config SND_SOC_SPEYSIDE tristate Audio support for Wolfson Speyside - depends on SND_SOC_SAMSUNG MACH_WLF_CRAGG_6410 + depends on SND_SOC_SAMSUNG MACH_WLF_CRAGG_6410 SPI_MASTER select SND_SAMSUNG_I2S select SND_SOC_WM8996 select SND_SOC_WM9081 Why only add a dependency on SPI here? I don't know, definitely my mistake. I had squashed three older patches together here, which resulted in the slightly strange changelog (I picked the one that explained it best and then tried to modify it to cover all changes) as well as the missing I2C dependency. I'll re-check all other drivers in this directory too and then send a new patch. 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] [media] s5p-tv: hdmi needs I2C support
Building the s5p-tv HDMI support when CONFIG_I2C is disabled gives us this build error: s5p-tv/hdmi_drv.c: In function 'hdmi_probe': s5p-tv/hdmi_drv.c:947:2: error: implicit declaration of function 'i2c_get_adapter' [-Werror=implicit-function-declaration] adapter = i2c_get_adapter(pdata-hdmiphy_bus); ^ This patch changes the Kconfig description to include I2C as a dependency for this driver, so it cannot be configured incorrectly. Signed-off-by: Arnd Bergmann a...@arndb.de diff --git a/drivers/media/platform/s5p-tv/Kconfig b/drivers/media/platform/s5p-tv/Kconfig index 5a1835dd65e8..697aaed42486 100644 --- a/drivers/media/platform/s5p-tv/Kconfig +++ b/drivers/media/platform/s5p-tv/Kconfig @@ -20,6 +20,7 @@ if VIDEO_SAMSUNG_S5P_TV config VIDEO_SAMSUNG_S5P_HDMI tristate Samsung HDMI Driver depends on VIDEO_V4L2 + depends on I2C depends on VIDEO_SAMSUNG_S5P_TV select VIDEO_SAMSUNG_S5P_HDMIPHY help -- 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: [GIT PULL 4/4] Samsung 3rd DT updates for v3.20
On Thu, Jan 29, 2015 at 09:34:27AM +0900, Kukjin Kim wrote: Hi, This is another Samsung DT updates for v3.20. Since including a clock patch with Mike and Sylwester's acks so sending separate pull-request. Please pull and if any problems please let me know. Thanks, Kukjin The following changes since commit 6591a02e17e6d6587c3cf7588d523fa6f26b584a: ARM: dts: reduce total RAM by 22 MiB for exynos5422-odroidxu3 (2015-01-24 13:24:10 +0900) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/samsung-dt-3 for you to fetch changes up to ea08de16eb1ba2052ce2db4b58b62a2ec33357a3: ARM: dts: Add DISP1 power domain for exynos5420 (2015-01-29 08:52:23 +0900) Merged, thanks. -Olof -- 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: [GIT PULL 2/4] Samsung mach updates for v3.20
On Thu, Jan 29, 2015 at 09:33:52AM +0900, Kukjin Kim wrote: Hi, This is for updating of mach-exynos and plat-samsung. Please pull and if any problems, please let me know. Thanks, Kukjin The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672: Linux 3.19-rc1 (2014-12-20 17:08:50 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/samsung-update for you to fetch changes up to a4f582f5c5fe3e8eaef7ce637c894619bdee650e: ARM: EXYNOS: Add exynos3250 suspend-to-ram support (2015-01-15 00:24:26 +0900) Merged, thanks. -Olof -- 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: [GIT PULL 1/4] Samsung Cleanup for v3.20
On Thu, Jan 29, 2015 at 09:33:39AM +0900, Kukjin Kim wrote: Hi Arnd, Olof, Kevin Please pull Samsung cleanup for v3.20. This cleanup is very nice, Samsung SoCs no more use specific DMA and remove i2c sys from mach-exynos. Thanks to Arnd and all involved guys. - Kukjin The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672: Linux 3.19-rc1 (2014-12-20 17:08:50 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/samsung-cleanup Merged, thanks. -Olof -- 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 v4 3/7] misc: Add cros_ec_lpc driver for x86 devices
Javier, Trivial nits below. On Thu, 2015-01-29 at 14:37 +0100, Javier Martinez Canillas wrote: From: Bill Richardson wfric...@chromium.org Chromebooks have an Embedded Controller (EC) that is used to implement various functions such as keyboard, power and battery. The AP can communicate with the EC through different bus types such as I2C, SPI or LPC. The cros_ec mfd driver is then composed of a core driver that register the sub-devices as mfd cells and provide a high level communication interface that is used by the rest of the kernel and bus specific interfaces modules. Each connection method then has its own driver, which register with the EC driver interface-agnostic interface. Currently, there are drivers to communicate with the EC over I2C and SPI and this driver adds support for LPC. Signed-off-by: Bill Richardson wfric...@chromium.org Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk [...] drivers/misc/Kconfig | 10 ++ drivers/misc/Makefile | 1 + drivers/misc/cros_ec_lpc.c | 291 + 3 files changed, 302 insertions(+) create mode 100644 drivers/misc/cros_ec_lpc.c diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 006242c8bca0..142393e84a43 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -515,6 +515,16 @@ config VEXPRESS_SYSCFG bus. System Configuration interface is one of the possible means of generating transactions on this bus. +config CROS_EC_LPC + tristate ChromeOS Embedded Controller (LPC) + depends on MFD_CROS_EC + Please drop this empty line. + help + If you say Y here, you get support for talking to the ChromeOS EC + over an LPC bus. This uses a simple byte-level protocol with a + checksum. This is used for userspace access only. The kernel + typically has its own communication methods. + What happens when you say M? source drivers/misc/c2port/Kconfig source drivers/misc/eeprom/Kconfig source drivers/misc/cb710/Kconfig Paul Bolle -- 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: [GIT PULL 3/4] Samsung 2nd DT updates for v3.20
On Thu, Jan 29, 2015 at 09:34:14AM +0900, Kukjin Kim wrote: Hi, This is 2nd Samsung DT updates for v3.20, please pull. Thanks, Kukjin The following changes since commit 23c76dc666471dce5ce71b620839d2465723a7c9: ARM: dts: Configure regulators for suspend on exynos Peach boards (2015-01-15 00:30:49 +0900) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/samsung-dt-2 Merged, thanks. -Olof -- 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] exynos/drm: fix no hdmi output
The hdmi outputs black screen only even though under the hood Xorg and
framebuffer console are fine : devices found and initialized, but
not a pixel out.
Commit 93bca243ec96 (drm/exynos: remove struct exynos_drm_manager)
changed the call order of mixer_initialize with regards to
exynos_drm_crtc_create.
This changes breaks hdmi out on Odroid U2 (linux-next with added
Marek Szyprowski v4 hdmi patchset from linux-samsung-soc ML).
Restore the previous call ordering get hdmi to ouput proper pixels:
ie call mixer_initialize first then exynos_drm_crtc_create.
Fixes: 93bca243ec96 (drm/exynos: remove struct exynos_drm_manager)
Signed-off-by: Alban Browaeys pra...@yahoo.com
---
drivers/gpu/drm/exynos/exynos_mixer.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index d8fd8e1..188f90f 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1258,18 +1258,19 @@ static int mixer_bind(struct device *dev, struct device
*manager, void *data)
struct drm_device *drm_dev = data;
int ret;
+ ret = mixer_initialize(ctx, drm_dev);
+ if (ret)
+ return ret;
+
ctx-crtc = exynos_drm_crtc_create(drm_dev, ctx-pipe,
EXYNOS_DISPLAY_TYPE_HDMI,
mixer_crtc_ops, ctx);
if (IS_ERR(ctx-crtc)) {
+ mixer_ctx_remove(ctx);
ret = PTR_ERR(ctx-crtc);
goto free_ctx;
}
- ret = mixer_initialize(ctx, drm_dev);
- if (ret)
- goto free_ctx;
-
return 0;
free_ctx:
--
2.1.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: [PATCH 3/3] cpufreq: exynos: allow modular build
Hello Arnd and Viresh, On Thu, Jan 29, 2015 at 01:42:32PM +0100, Arnd Bergmann wrote: On Thursday 29 January 2015 15:40:15 Viresh Kumar wrote: obj-$(CONFIG_ARCH_DAVINCI) += davinci-cpufreq.o obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o -obj-$(CONFIG_ARM_EXYNOS_CPUFREQ) += exynos-cpufreq.o -obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos4210-cpufreq.o -obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) += exynos4x12-cpufreq.o -obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos5250-cpufreq.o +obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos-cpufreq.o exynos4210-cpufreq.o +obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) += exynos-cpufreq.o exynos4x12-cpufreq.o +obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos-cpufreq.o exynos5250-cpufreq.o I'd have to try it, but this might fail if one of the three drivers is built-in and another one is a module. Arnd Let me make one step back here. The original issue is, now this exynos cpufreq driver depends on of thermal; but of thermal can be built as module, while this cpufreq driver cannot. Original proposal is to allow module build in the exynos cpufreq driver. On the original proposal, my concern is that the driver code does not have separated modules, but one single module platform driver, which uses functions from other c files. On top of that, the patch originally allows four (independent) modules builds. Although the children drivers still selects the core part, we would still need to change the original patch to add module dependency too. So, my proposal was to, in order to allow module builds on this cpufreq driver, we also need to properly construct the driver into a single module, instead of several modules. The issue with my patch was the fact that it was allowing platforms that do not use that driver, to select it by default. And eventually this may cause a unusable module being loaded into those systems. Well, trying harder here in the same approach. The diff bellow is based on Arnd's original patch and on Viresh's amendment, except that the core part is now dependent on all the supported platforms, instead of ARCH_EXYNOS. This way, it wont load in platforms that are not supposed to be loaded. The user will be able to build the support for all platforms, or select which platforms he/she wants (as originally), except that now it can be a module, instead. I believe now by default it will still keep the driver only on those configs that expect it to be on. And it won't compile/load on platforms that it is not supposed to. It brings closer a config that is dependent on this driver, so it looks better in the menuconfig. Let me know if I missed something (feel free to amend to your patch): diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm index 0f9a2c3..c6e3a6e 100644 --- a/drivers/cpufreq/Kconfig.arm +++ b/drivers/cpufreq/Kconfig.arm @@ -26,13 +26,21 @@ config ARM_VEXPRESS_SPC_CPUFREQ config ARM_EXYNOS_CPUFREQ - bool + tristate SAMSUNG EXYNOS CPUfreq Driver + depends on CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412 || SOC_EXYNOS5250 + depends on THERMAL + help + This adds the CPUFreq driver for Samsung EXYNOS platforms. + Supported SoC versions are: +Exynos4210, Exynos4212, Exynos4412, and Exynos5250. + + If in doubt, say N. config ARM_EXYNOS4210_CPUFREQ bool SAMSUNG EXYNOS4210 depends on CPU_EXYNOS4210 + depends on ARM_EXYNOS_CPUFREQ default y - select ARM_EXYNOS_CPUFREQ help This adds the CPUFreq driver for Samsung EXYNOS4210 SoC (S5PV310 or S5PC210). @@ -42,8 +50,8 @@ config ARM_EXYNOS4210_CPUFREQ config ARM_EXYNOS4X12_CPUFREQ bool SAMSUNG EXYNOS4x12 depends on SOC_EXYNOS4212 || SOC_EXYNOS4412 + depends on ARM_EXYNOS_CPUFREQ default y - select ARM_EXYNOS_CPUFREQ help This adds the CPUFreq driver for Samsung EXYNOS4X12 SoC (EXYNOS4212 or EXYNOS4412). @@ -53,28 +61,14 @@ config ARM_EXYNOS4X12_CPUFREQ config ARM_EXYNOS5250_CPUFREQ bool SAMSUNG EXYNOS5250 depends on SOC_EXYNOS5250 + depends on ARM_EXYNOS_CPUFREQ default y - select ARM_EXYNOS_CPUFREQ help This adds the CPUFreq driver for Samsung EXYNOS5250 SoC. If in doubt, say N. -config ARM_EXYNOS5440_CPUFREQ - bool SAMSUNG EXYNOS5440 - depends on SOC_EXYNOS5440 - depends on HAVE_CLK OF - select PM_OPP - default y - help - This adds the CPUFreq driver for Samsung EXYNOS5440 - SoC. The nature of exynos5440 clock controller is - different than previous exynos controllers so not using - the common exynos framework. - - If in doubt, say N. - config ARM_EXYNOS_CPU_FREQ_BOOST_SW bool EXYNOS Frequency Overclocking - Software depends on ARM_EXYNOS_CPUFREQ
Re: [PATCH 1/3] exynos: config: Remove CONFIG_EXYNOS_THERMAL_CORE define (exynos_defconfig)
On Wed, Jan 28, 2015 at 04:28:38PM +0100, Lukasz Majewski wrote: After Exynos TMU rework to use device tree for configuration this flag can be removed. It is not used anymore. Signed-off-by: Lukasz Majewski l.majew...@samsung.com I dont see problems with this patch: Acked-by: Eduardo Valentin edubez...@gmail.com This should go, obviously, via the correct platform tree. --- arch/arm/configs/exynos_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 3d0c5d6..3691a68 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -88,7 +88,6 @@ CONFIG_HWMON=y CONFIG_SENSORS_LM90=y CONFIG_THERMAL=y CONFIG_EXYNOS_THERMAL=y -CONFIG_EXYNOS_THERMAL_CORE=y CONFIG_WATCHDOG=y CONFIG_S3C2410_WATCHDOG=y CONFIG_MFD_CROS_EC=y -- 2.0.0.rc2 -- 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 2/3] exynos: config: Enable thermal emulation for Exynos TMU (exynos_defconfig)
On Wed, Jan 28, 2015 at 04:28:39PM +0100, Lukasz Majewski wrote: Enabling thermal emulation on Exynos SoCs. New sysfs attribute - emul_temp is created. Signed-off-by: Lukasz Majewski l.majew...@samsung.com I dont see problems with this patch: Acked-by: Eduardo Valentin edubez...@gmail.com --- 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 3691a68..376dbf4 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -88,6 +88,7 @@ CONFIG_HWMON=y CONFIG_SENSORS_LM90=y CONFIG_THERMAL=y CONFIG_EXYNOS_THERMAL=y +CONFIG_THERMAL_EMULATION=y CONFIG_WATCHDOG=y CONFIG_S3C2410_WATCHDOG=y CONFIG_MFD_CROS_EC=y -- 2.0.0.rc2 -- 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 v10 0/7] devfreq: Add devfreq-event class to provide raw data for devfreq device
Dear Kukjin,
The patch(1-3) of this patchset is merged to linux-pm.git (Rafael J. Wysocki).
We can check it on following url:
-
https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=bleeding-edgeid=8bf997796bd9bc8e3f997f26cbac7dd2c6661a76
Could you please pick remaining patches(4-7) related to Exynos DT files?
Best Regards,
Chanwoo Choi
On 01/26/2015 01:16 PM, Chanwoo Choi wrote:
This patchset add new devfreq_event class to provide raw data to determine
current utilization of device which is used for devfreq governor.
The following description explains the feature of two kind of devfreq class:
- devfreq class (existing)
: devfreq consumer device use raw data from devfreq_event device for
determining proper current system state and change voltage/frequency
dynamically using various governors.
- devfreq_event class (new)
: Provide measured raw data to devfreq device for governor
Changelog:
Changes from v9:
(https://lkml.org/lkml/2015/1/20/68)
- Fix the operation of enable_count in devfreq_event_{enable|disable}_edev().
Changes from v8:
(https://lkml.org/lkml/2015/1/12/299)
- Fix issue of devfreq-event.c driver by Myunjoo's comment
: Merge patch2 (resource-managed function) with patch1
: Fix bug in devfreq_event_{enable|disable}_edev() about enable_count
operation
: Simplify error checking code in devfreq_event_get_event()
: Define devfreq_event_get_drvdata() as static inline function type
: Reduce the time of critical section scope in devfreq_event_remove_edev()
: Rename field name of devfreq_event_data structure
(total_event / event - total_count / load_count)
- Drop following patch[1] because Exynos5260 cannot be tested for
exynos-ppmu.c driver
[1] [PATCHv8 7/9] ARM: dts: Add PPMU dt node for Exynos5260 SoC
- https://lkml.org/lkml/2015/1/12/301
- Clean-up exynos-ppmu.c without update
Changes from v7:
(https://lkml.org/lkml/2015/1/7/795)
- Use EXPORT_SYMBOL_GPL macro instead of EXPORT_SYMBOL
- Fix the binding document of exynos-ppmu.c driver
- Drop the devfreq-event type patch because it isnt' clear
- Fix bug of devfreq_event_add_edev() when fail to execute device_register()
- Modify resource free operation on following functions:
: devfreq_event_remove_edev()
: devfreq_event_release_edev()
Changes from v6:
(https://lkml.org/lkml/2014/12/28/139)
- This patchset is based on v3.19-rc3.
1. devfreq-event class driver
- Fix build break if devfreq-event framework is off
- Add resource-managed function for devfreq-event device
: devm_devfreq_event_add_edev()
: devm_devfreq_event_remove_edev()
Changes from v5:
(https://lkml.org/lkml/2014/12/22/527)
- Rebase these patch-set on v3.19-rc1 and Test it.
1. exynos-ppmu.c
- Change the error value when of_iomap() fail to map the memory
- Remove owner setting of platform_driver
- Add exynos_ppmu_disable() function
2. exynos dts file
- Add PPMU node to Exynos3250-based Monk board
- Remove ppmu_cpu node on Exynos4412-based TRATS2 board and add
ppmu_leftbus/rightbus node
Changes from v4:
(https://lkml.org/lkml/2014/12/16/511)
1. devfreq-event class driver
- Add devfreq_event_get_edev_count() function
- Modify the simple description of devfreq-event framework in devfreq-event.c
- Minimize the usage range of global lock usage in devfreq_event_add_edev()
- Remove '_is_enabled()' function pointer in devfreq_event_ops structure
- Add separte CONFIG_PM_DEVFREQ_EVENT configuration
- Add new devfreq-event.h header file including devfreq-event helper functions
2. exynos dts file
- Add new patch to support PPMU with DEVFREQ-event on Exynos4412-based TRATS2
Changes from v3:
(https://lkml.org/lkml/2014/12/12/219)
1. devfreq-event class driver
- Fix return value of devfreq_event_get_event()
- Add new structure devfreq_event_data for devfreq_event_get_event()
- Modify the prototype of devfreq_event_get_event() function
- Call of_node_put after calling of_parse_phandle() to decrement refcount
2. exynos-ppmu driver
- Modify usage of devfreq_event_get_event() function
according to new prototype of this funciton
- Add the additional description to exynos-ppmu.txt how to add PPMU node
in board dts file
- Use 'PPMU_EVENT' macro to remove duplicate codes
- Add the support of PPMU for Exynos5260
3. exynos dts file
- Add missing PPMU_FSYS node to exynos3250.dtsi
- Fix 'ppmu_mfc_l' node name as 'ppmu_mfc' because exynos3250 has only one
MFC IP.
- Add missing PPMU_ACP/G3D to exynos4.dtsi
4. etc
- Fix wrong abbreviation of PPMU (PPMU :Platform Performance Monitoring Unit)
- Add new patch to support the PPMU of Exynos5260 SoC
Changes from v2:
(https://lkml.org/lkml/2014/12/9/304)
1. devfreq-event class driver
- Rename all the helper functions of devfreq-event device
- Add devfreq_event_remove_edev() instead of devfreq_put_event_dev()
- Add devfreq_event_release_edev() to initialize it before put device
- Add the
Re: [PATCH] exynos/drm: fix no hdmi output
+Cc dri-devel ML.
Hi Alban,
On 01/30/2015 06:18 AM, Alban Browaeys wrote:
The hdmi outputs black screen only even though under the hood Xorg and
framebuffer console are fine : devices found and initialized, but
not a pixel out.
Commit 93bca243ec96 (drm/exynos: remove struct exynos_drm_manager)
changed the call order of mixer_initialize with regards to
exynos_drm_crtc_create.
Right, there is no any reason to change order but i don't think it
causes problem because they don't any dependency.
This changes breaks hdmi out on Odroid U2 (linux-next with added
Marek Szyprowski v4 hdmi patchset from linux-samsung-soc ML).
I tested Odroid U3 but hdmi out is working well.
Thanks.
Restore the previous call ordering get hdmi to ouput proper pixels:
ie call mixer_initialize first then exynos_drm_crtc_create.
Fixes: 93bca243ec96 (drm/exynos: remove struct exynos_drm_manager)
Signed-off-by: Alban Browaeys pra...@yahoo.com
---
drivers/gpu/drm/exynos/exynos_mixer.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index d8fd8e1..188f90f 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1258,18 +1258,19 @@ static int mixer_bind(struct device *dev, struct
device *manager, void *data)
struct drm_device *drm_dev = data;
int ret;
+ ret = mixer_initialize(ctx, drm_dev);
+ if (ret)
+ return ret;
+
ctx-crtc = exynos_drm_crtc_create(drm_dev, ctx-pipe,
EXYNOS_DISPLAY_TYPE_HDMI,
mixer_crtc_ops, ctx);
if (IS_ERR(ctx-crtc)) {
+ mixer_ctx_remove(ctx);
ret = PTR_ERR(ctx-crtc);
goto free_ctx;
}
- ret = mixer_initialize(ctx, drm_dev);
- if (ret)
- goto free_ctx;
-
return 0;
free_ctx:
--
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 3/6] drm/exynos: Remove exynos_plane_dpms() call with no effect
+Cc Inki, Hi, On 01/23/2015 09:42 PM, Gustavo Padovan wrote: From: Gustavo Padovan gustavo.pado...@collabora.co.uk exynos_plane_dpms(DRM_MODE_DPMS_ON) calls the win_enable()'s callback from the underlying layer. However neither one of these layers implement win_enable() - FIMD, Mixer and VIDI. Thus the call to exynos_plane_dpms() is pointless. No, it needs for pair with DRM_MODE_DPMS_OFF case. Thanks. Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c index b1f1b25..d0f4e1b 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c @@ -65,8 +65,6 @@ static void exynos_drm_crtc_commit(struct drm_crtc *crtc) if (exynos_crtc-ops-commit) exynos_crtc-ops-commit(exynos_crtc); - - exynos_plane_dpms(crtc-primary, DRM_MODE_DPMS_ON); } static bool -- 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/6] drm/exynos: remove leftover code using event_list
+Cc Inki,
Hi,
On 01/23/2015 09:42 PM, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
The drm_file event_list hasn't been used anymore by exynos, so we don't
need any code to clean it.
No, it is used from drm core e.g. drm_irq.c file.
Thanks.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 25ba362..b60fd9b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -256,11 +256,6 @@ static void exynos_drm_postclose(struct drm_device *dev,
struct drm_file *file)
}
}
- /* Release all events handled by page flip handler but not freed. */
- list_for_each_entry_safe(e, et, file-event_list, link) {
- list_del(e-link);
- e-destroy(e);
- }
spin_unlock_irqrestore(dev-event_lock, flags);
kfree(file-driver_priv);
--
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 0/3] cpufreq: build fixes
On Wednesday, January 28, 2015 02:16:52 PM Arnd Bergmann wrote: These came out of running randconfig build tests on ARM. The three patches are completely independent, so please apply what looks good. The two s3c patches are for old bugs and should go through the cpufreq tree. The exynos bug only exists in the thermal-soc tree at the moment and should get picked up by Eduardo with an Ack from the cpufreq maintainers, or alternatively the bug should get fixed differently if someone can come up with a better solution. Arnd Bergmann (3): cpufreq: s3c: remove incorrect __init annotations cpufreq: s3c: remove last use of resume_clocks callback cpufreq: exynos: allow modular build drivers/cpufreq/Kconfig.arm | 14 +- drivers/cpufreq/exynos-cpufreq.h | 6 +++--- drivers/cpufreq/exynos4210-cpufreq.c | 1 + drivers/cpufreq/exynos4x12-cpufreq.c | 1 + drivers/cpufreq/exynos5250-cpufreq.c | 1 + drivers/cpufreq/s3c2416-cpufreq.c| 4 ++-- drivers/cpufreq/s3c24xx-cpufreq.c| 10 +- 7 files changed, 18 insertions(+), 19 deletions(-) I'm assuming that this series will go in through the Samsumg tree. -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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 01/12] clk: samsung: exynos5433: Add clocks using common clock framework
Hi Sylwester,
On 01/29/2015 09:53 PM, Sylwester Nawrocki wrote:
Hi Chanwoo,
On 23/01/15 21:54, Chanwoo Choi wrote:
On Sat, Jan 24, 2015 at 2:40 AM, Sylwester Nawrocki
s.nawro...@samsung.com wrote:
On 21/01/15 07:26, Chanwoo Choi wrote:
+/* list of all parent clock list */
+PNAME(mout_bus_pll_user_p) = { fin_pll, sclk_bus_pll, };
...
+
+static struct samsung_mux_clock top_mux_clks[] __initdata = {
+ MUX(CLK_MOUT_BUS_PLL_USER, mout_bus_pll_user, mout_bus_pll_user_p,
+ MUX_SEL_TOP1, 0, 1),
...
+};
+
+static struct samsung_div_clock top_div_clks[] __initdata = {
...
+ /* DIV_TOP3 */
+ DIV(CLK_DIV_ACLK_IMEM_SSSX_266, div_aclk_imem_sssx_266,
+ mout_bus_pll_user, DIV_TOP3, 24, 3),
Shouldn't fin_pll be renamed to oscclk ? In the documentation
the root clock (from XXTI input pin) seems to be referred as OSCCLK.
And I can't see fin_pll clock registered anywhere. Shouldn't there
be a fixed-rate-clock as a parent of at least CMU_TOP? e.g.
Right,
I added fin_pll fixed clock in DT as following:
When I registered fin_pll fixed clock, I could use fin_pll clock
for exynos5433 cmu without adding additional dt node.
fin_pll: xxti {
compatible = fixed-clock;
clock-output-names = fin_pll;
#clock-cells = 0;
};
I'll add the example of fin_pll dt node to documentation for exynos5433
cmu.
OK, thanks. But I think it needs to be named oscclk, FIN_PLL is almost
not existent in the SoC's documentation.
I'd suggest to define the root oscillator clock (XXTI/OSCCLK) as oscclk
in DT, rather than registering fin_pll fixed clock in the driver.
OK,
I'll fix it by using oscclk clock name instead of fin_pll.
xxti: xxti {
compatible = fixed-clock;
#clock-cells = 0;
clock-output-names = oscclk;
clock-frequency = 2400;
};
cmu_top {
clocks = xxti;
};
Best Regards,
Chanwoo Choi
--
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 2/2] cpuidle: exynos: add coupled cpuidle support for Exynos4210
On 01/26/15 20:53, Krzysztof Kozlowski wrote:
On pon, 2015-01-26 at 12:33 +0100, Bartlomiej Zolnierkiewicz wrote:
Hi,
On Monday, January 26, 2015 09:16:48 AM Krzysztof Kozlowski wrote:
On pią, 2015-01-23 at 17:24 +0100, Bartlomiej Zolnierkiewicz wrote:
The following patch adds coupled cpuidle support for Exynos4210 to
an existing cpuidle-exynos driver. As a result it enables AFTR mode
to be used by default on Exynos4210 without the need to hot unplug
CPU1 first.
The patch is heavily based on earlier cpuidle-exynos4210 driver from
Daniel Lezcano:
http://www.spinics.net/lists/linux-samsung-soc/msg28134.html
Changes from Daniel's code include:
- porting code to current kernels
- fixing it to work on my setup (by using S5P_INFORM register
instead of S5P_VA_SYSRAM one on Revison 1.1 and retrying poking
CPU1 out of the BOOT ROM if necessary)
- fixing rare lockup caused by waiting for CPU1 to get stuck in
the BOOT ROM (CPU hotplug code in arch/arm/mach-exynos/platsmp.c
doesn't require this and works fine)
- moving Exynos specific code to arch/arm/mach-exynos/pm.c
- using cpu_boot_reg_base() helper instead of BOOT_VECTOR macro
- using exynos_cpu_*() helpers instead of accessing registers
directly
- using arch_send_wakeup_ipi_mask() instead of dsb_sev()
(this matches CPU hotplug code in arch/arm/mach-exynos/platsmp.c)
- integrating separate exynos4210-cpuidle driver into existing
exynos-cpuidle one
Cc: Colin Cross ccr...@google.com
Cc: Kukjin Kim kgene@samsung.com
Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: Tomasz Figa tomasz.f...@gmail.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
I've seen the patch during internal review and now looks good... except
minor issues below.
---
arch/arm/mach-exynos/common.h| 4 +
arch/arm/mach-exynos/exynos.c| 4 +
arch/arm/mach-exynos/platsmp.c | 2 +-
arch/arm/mach-exynos/pm.c| 122
+++
drivers/cpuidle/Kconfig.arm | 1 +
drivers/cpuidle/cpuidle-exynos.c | 76 +++--
include/linux/platform_data/cpuidle-exynos.h | 20 +
7 files changed, 223 insertions(+), 6 deletions(-)
create mode 100644 include/linux/platform_data/cpuidle-exynos.h
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 865f878..f70eca7 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -13,6 +13,7 @@
#define __ARCH_ARM_MACH_EXYNOS_COMMON_H
#include linux/of.h
+#include linux/platform_data/cpuidle-exynos.h
#define EXYNOS3250_SOC_ID 0xE3472000
#define EXYNOS3_SOC_MASK 0xF000
@@ -150,8 +151,11 @@ extern void exynos_pm_central_suspend(void);
extern int exynos_pm_central_resume(void);
extern void exynos_enter_aftr(void);
+extern struct cpuidle_exynos_data cpuidle_coupled_exynos_data;
+
extern void s5p_init_cpu(void __iomem *cpuid_addr);
extern unsigned int samsung_rev(void);
+extern void __iomem *cpu_boot_reg_base(void);
static inline void pmu_raw_writel(u32 val, u32 offset)
{
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 78eca99b..2013f73 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -211,6 +211,10 @@ static void __init exynos_dt_machine_init(void)
if (!IS_ENABLED(CONFIG_SMP))
exynos_sysram_init();
+#ifdef CONFIG_ARM_EXYNOS_CPUIDLE
+ if (of_machine_is_compatible(samsung,exynos4210))
+ exynos_cpuidle.dev.platform_data = cpuidle_coupled_exynos_data;
+#endif
if (of_machine_is_compatible(samsung,exynos4210) ||
of_machine_is_compatible(samsung,exynos4212) ||
(of_machine_is_compatible(samsung,exynos4412)
diff --git a/arch/arm/mach-exynos/platsmp.c
b/arch/arm/mach-exynos/platsmp.c
index 7a1ebfe..3f32c47 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -194,7 +194,7 @@ int exynos_cluster_power_state(int cluster)
S5P_CORE_LOCAL_PWR_EN);
}
-static inline void __iomem *cpu_boot_reg_base(void)
+void __iomem *cpu_boot_reg_base(void)
{
if (soc_is_exynos4210() samsung_rev() == EXYNOS4210_REV_1_1)
return pmu_base_addr + S5P_INFORM5;
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 1a7454d..e6209da 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -180,3 +180,125 @@ void exynos_enter_aftr(void)
cpu_pm_exit();
}
+
+static atomic_t cpu1_wakeup = ATOMIC_INIT(0);
+
+static int exynos_cpu0_enter_aftr(void)
+{
+ int ret = -1;
+
+ /*
+ * If the other cpu is powered on, we have to power it off, because
+ * the AFTR state won't work otherwise
+ */
+ if (cpu_online(1)) {
+ /*
+ * We
Re: [PATCH 1/2] thermal: exynos: Reorder exynos_map_dt_data() function
On Thu, Jan 22, 2015 at 06:02:07PM +0530, Abhilash Kesavan wrote:
Hi Lukasz,
On Thu, Jan 22, 2015 at 2:31 PM, Lukasz Majewski l.majew...@samsung.com
wrote:
Hi Abhilash,
Hi Lukasz,
On Mon, Jan 19, 2015 at 5:14 PM, Lukasz Majewski
l.majew...@samsung.com wrote:
The exynos_map_dt_data() function must be called before
thermal_zone_of_sensor_register(), and hence provide tmu_read()
function, before it is needed.
This change is driven by adding support for enabling thermal_zoneX
when it is properly initialized.
One can read the mode of operation
at /sys/class/thermal/thermal_zone0/mode Such functionality was
missing in the of-thermal.c code.
Reported-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c index 9d2d685..5d946ab 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -975,15 +975,16 @@ static int exynos_tmu_probe(struct
platform_device *pdev) platform_set_drvdata(pdev, data);
mutex_init(data-lock);
+ ret = exynos_map_dt_data(pdev);
+ if (ret)
+ goto err_sensor;
+
data-tzd = thermal_zone_of_sensor_register(pdev-dev, 0,
data, exynos_sensor_ops);
if (IS_ERR(data-tzd)) {
pr_err(thermal: tz: %p ERROR\n, data-tzd);
return PTR_ERR(data-tzd);
}
- ret = exynos_map_dt_data(pdev);
- if (ret)
- goto err_sensor;
pdata = data-pdata;
I have been testing this along with your v5 patch set and am seeing
incorrect temperature being reported at boot-up on exynos7.
Does it show a maximal temperature value (0x1FF)?
I did not print the current temperature register, but I remember the
message showing ~105C. Will give you the register value when I test
with more debug prints tomorrow.
It looks
like exynos_tmu_read gets called from thermal_zone_of_device_update
during boot-up, now that we have it populated early. However, as the
tmu initialization function has not been called yet it returns a wrong
value. Does that sound correct ?
No, this is a mistake. However, I'm wondering why on Exynos4/5 this
error didn't show up...
I have been lowering the software trip point temperature in the
exynos7 dts file (to 55C) for testing purposes. Hence, when the
temperature is read incorrectly as ~105C the board trips at boot-up
itself. Maybe for exynos4/5 the incorrect value read during boot-up is
in the non-tripping range and once the tmu is initialized later it
continues to function properly thereafter ?
The reordering is needed to be able to call set_mode callback at
of-thermal.c to set the mode.
If this change causes problems, then another solution (probably not so
neat) must be found.
Please let me know if you need any further details.
What is the status of this patch? Is it still required?
Cheers,
Thanks,
Abhilash
--
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 v6 00/18] thermal: exynos: Thermal code rework to use device tree
On 01/25/15 06:49, Eduardo Valentin wrote: On Fri, Jan 23, 2015 at 01:09:53PM +0100, Lukasz Majewski wrote: 1. Introduction Following patches aim to clean up the current implementation of the thermal framework on Exynos devices. The main goal was to use a generic code for reading thermal configuration (of-thermal.c). Due to that redundant exynos_thermal_common.[h|c] files were removed. Around 400 lines of code (LOC) were removed directly by this patch, which is around 20% of the Exynos thermal code base. This work should NOT bring any functional changes to Exynos thermal subsystem. 2. Patch-set structure Then the cpu_cooling functionality has been preserved to allow cooling devices by reducing operating frequency. Definition of trip points and cpufreq's cooling properties were moved to device tree. Then the rework of the way in which configuration data is provided to the Exynos thermal subsystem was performed. Now device tree is used for configuration. 3. Dead code removal Thermal support for some SoCs, previously available in the exynos_tmu_data.c file, was removed since, as of (almost) 3.19-rc3, they didn't have TMU bindings. Moreover, support for cpu_cooling devices was preserved only on those SoCs which had available and working cpufreq driver. 4. Testing Test devices: - Exynos4210 - Trats (TMU zone + cpu_cooling) - Exynos4412 - Trats2/Odroid U3 (TMU zone + cpu_cooling) - Exynos5250 - Arndale (TMU zone + cpu_cooling) - Exynos5420 - Arndale-octa (only TMU zones) Unfortunately, I don't posses Exynos5440 for testing. Its functionality has been preserved in the code, but not tested on the hardware. I would be grateful for help in testing. 5. This work apply on the following tree: kernel.org: 'linux-soc-thermal/next' - Eduardo Velentin's tree SHA1: 1813d80874699145f04af6b05ebab0a6419001fb Lukasz Majewski (18): I have applied the following patches to my -fixes branch (for next rc cycle) thermal: exynos: cosmetic: Correct comment format thermal: exynos: Provide thermal_exynos.h file to be included in device tree files thermal: exynos: Modify exynos thermal code to use device tree for cpu cooling configuration cpufreq: exynos: Use device tree to determine if cpufreq cooling should be registered dts: Documentation: Extending documentation entry for exynos-thermal dts: Documentation: Update exynos-thermal.txt example for Exynos5440 thermal: samsung: core: Exynos TMU rework to use device tree for configuration thermal: exynos: Remove exynos_thermal_common.[c|h] files thermal: exynos: Remove exynos_tmu_data.c file The patches below should go via platform tree: arm: dts: trats: Enable TMU on the Exynos4210 trats device arm: dts: odroid: Add LDO10 regulator node necessary for TMU on Odroid arm: dts: odroid: Enable TMU at Exynos4412 based Odroid U3 device arm: dts: Adding CPU cooling binding for Exynos SoCs thermal: exynos: dts: Add default definition of the TMU sensor parameter thermal: dts: Default trip points definition for Exynos5420 SoCs thermal: exynos: dts: Define default thermal-zones for Exynos4 thermal: dts: exynos: Trip points and sensor configuration data for Exynos5440 thermal: exynos: dts: Provide device tree bindings identical to the one in exynos_tmu_data.c I've applied above patches with small subject changes. BTW unfortunately, since missing the include/dt-bindings/thermal/thermal_exynos.h in my tree, I couldn't merge it into for-next yet. Can you please provide a topic branch for it? If not, this cannot be handled in arm-soc tree in this time, I think. - Kukjin Thanks a lot. .../devicetree/bindings/thermal/exynos-thermal.txt | 17 + arch/arm/boot/dts/exynos3250.dtsi | 2 + arch/arm/boot/dts/exynos4-cpu-thermal.dtsi | 52 +++ arch/arm/boot/dts/exynos4.dtsi | 4 + arch/arm/boot/dts/exynos4210-trats.dts | 19 + arch/arm/boot/dts/exynos4210.dtsi | 30 +- arch/arm/boot/dts/exynos4212.dtsi | 5 +- arch/arm/boot/dts/exynos4412-odroid-common.dtsi| 27 ++ arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi | 24 ++ arch/arm/boot/dts/exynos4412-trats2.dts| 15 + arch/arm/boot/dts/exynos4412.dtsi | 5 +- arch/arm/boot/dts/exynos4x12.dtsi | 1 + arch/arm/boot/dts/exynos5250.dtsi | 29 +- arch/arm/boot/dts/exynos5420-trip-points.dtsi | 35 ++ arch/arm/boot/dts/exynos5420.dtsi | 28 ++ arch/arm/boot/dts/exynos5440-tmu-sensor-conf.dtsi | 24 ++ arch/arm/boot/dts/exynos5440-trip-points.dtsi | 25 ++ arch/arm/boot/dts/exynos5440.dtsi | 18 + drivers/cpufreq/exynos-cpufreq.c | 33 +- drivers/thermal/sam`sung/Makefile | 2 -
Re: [RFC] drm/exynos: move hdmi clk disable out of pm ops
+Cc Kukjin, Hi, On 01/29/2015 10:31 PM, Gustavo Padovan wrote: From: Prathyush K prathyus...@samsung.com When VPLL clock of less than 140 MHz was used and all the three clocks - hdmiphy, hdmi, sclk_hdmi are disabled, the system hangs during S2R when HDMI is connected. Since we want to use a vpll clock of 70.5 MHz, we cannot disable these 3 clocks before suspending. This patch moves the clk enable/disable of hdmi and sclk_hdmi outside of the pm ops. Now system suspends and resumes with HDMI connected with VPLL set at 70.5 MHz. Signed-off-by: Prathyush K prathyus...@samsung.com Signed-off-by: Andrew Bresticker abres...@chromium.org Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk --- This work depends on the HDMI support patches from Javier: https://lkml.org/lkml/2015/1/20/235 This patch comes from a downstream tree (Google chormeOS) and it is authored by a Samsung employee, but we still think this may not fix the real cause of the bug, there might be something else that we haven't found that could be the cause of this issue. Anyone has some comment to add here? Hmm, do you test from which exynos SoC? Kukjin, if it is hw issue, do you know hw experts of exynos hdmi and could we get any advice? --- drivers/gpu/drm/exynos/exynos_hdmi.c | 17 +++-- 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c index 6aa0d65..7a473cb 100644 --- a/drivers/gpu/drm/exynos/exynos_hdmi.c +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c @@ -2064,9 +2064,6 @@ static void hdmi_poweron(struct exynos_drm_display *display) regmap_update_bits(hdata-pmureg, PMU_HDMI_PHY_CONTROL, PMU_HDMI_PHY_ENABLE_BIT, 1); - clk_prepare_enable(res-hdmi); - clk_prepare_enable(res-sclk_hdmi); - hdmiphy_poweron(hdata); hdmi_commit(display); } @@ -2088,9 +2085,6 @@ static void hdmi_poweroff(struct exynos_drm_display *display) cancel_delayed_work(hdata-hotplug_work); - clk_disable_unprepare(res-sclk_hdmi); - clk_disable_unprepare(res-hdmi); - /* reset pmu hdmiphy control bit to disable hdmiphy */ regmap_update_bits(hdata-pmureg, PMU_HDMI_PHY_CONTROL, PMU_HDMI_PHY_ENABLE_BIT, 0); @@ -2254,6 +2248,14 @@ static int hdmi_resources_init(struct hdmi_context *hdata) } else res-reg_hdmi_en = NULL; + /* + * These two clocks are not moved into hdmi_poweron/off since system + * fails to suspend if VPLL clock of 70.5 MHz is used and these + * clocks are disabled before suspend. So enable them here. + */ + clk_prepare_enable(res-sclk_hdmi); + clk_prepare_enable(res-hdmi); + Then twe clocks are turned on always. I don't think it's reasonable. Thanks. return ret; fail: DRM_ERROR(HDMI resource init - failed\n); @@ -2516,6 +2518,9 @@ static int hdmi_remove(struct platform_device *pdev) if (hdata-res.reg_hdmi_en) regulator_disable(hdata-res.reg_hdmi_en); + clk_disable_unprepare(hdata-res.sclk_hdmi); + clk_disable_unprepare(hdata-res.hdmi); + if (hdata-hdmiphy_port) put_device(hdata-hdmiphy_port-dev); put_device(hdata-ddc_adpt-dev); -- 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 4/6] drm/exynos: remove leftover functions declarations
+Cc Inki, Hi, On 01/23/2015 09:42 PM, Gustavo Padovan wrote: From: Gustavo Padovan gustavo.pado...@collabora.co.uk These functions were already removed by previous cleanup work, but these ones were left behind. Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk --- drivers/gpu/drm/exynos/exynos_drm_crtc.h | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h b/drivers/gpu/drm/exynos/exynos_drm_crtc.h index 6258b80..628b787 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h @@ -27,12 +27,6 @@ void exynos_drm_crtc_disable_vblank(struct drm_device *dev, int pipe); void exynos_drm_crtc_finish_pageflip(struct drm_device *dev, int pipe); void exynos_drm_crtc_complete_scanout(struct drm_framebuffer *fb); -void exynos_drm_crtc_plane_mode_set(struct drm_crtc *crtc, - struct exynos_drm_plane *plane); -void exynos_drm_crtc_plane_commit(struct drm_crtc *crtc, int zpos); -void exynos_drm_crtc_plane_enable(struct drm_crtc *crtc, int zpos); -void exynos_drm_crtc_plane_disable(struct drm_crtc *crtc, int zpos); - /* This function gets pipe value to crtc device matched with out_type. */ int exynos_drm_crtc_get_pipe_from_type(struct drm_device *drm_dev, unsigned int out_type); Acked-by: Joonyoung Shim jy0922.s...@samsung.com Thanks. -- 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 6/6] drm/exynos: do not copy adjusted mode into mode during crtc mode_set
Hi, On 01/23/2015 09:43 PM, Gustavo Padovan wrote: From: Daniel Kurtz djku...@chromium.org The 'mode' is the modeline information which specifies the ideal mode requested by the mode set initiator (usually userspace). The 'adjusted_mode' is the actual hardware mode after all the crtcs and encoders have had a chance to fix it up. The adjusted_mode starts as a duplicate of the mode in drm_crtc_helper_set_mode(), and gets modified as required. There is no reason to touch the original requested mode. Agree, but is there any side effect after this commit? Should we save adjusted_mode to other variable and use it? Thanks. In fact, doing so will cause us to think a new mode is being requested whenever userspace tries to establish a new framebuffer with drmModeSetCrtc(), since userspace will still be using the ideal mode, but the crtc will be incorrectly comparing it against the adjusted_mode. Signed-off-by: Daniel Kurtz djku...@chromium.org Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c index 5cd6c1a..7fd6426 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c @@ -91,12 +91,6 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct drm_display_mode *mode, unsigned int crtc_h; int ret; - /* - * copy the mode data adjusted by mode_fixup() into crtc-mode - * so that hardware can be seet to proper mode. - */ - memcpy(crtc-mode, adjusted_mode, sizeof(*adjusted_mode)); - ret = exynos_check_plane(crtc-primary, fb); if (ret 0) return ret; -- 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] drm/exynos: track vblank events on a per crtc basis
+Cc Inki,
Hi,
On 01/30/2015 02:10 AM, Gustavo Padovan wrote:
From: Mandeep Singh Baines m...@chromium.org
The goal of the change is to make sure we send the vblank event on the
current vblank. My hope is to fix any races that might be causing flicker.
After this change I only see a flicker in the transition plymouth and
X11.
Simplified the code by tracking vblank events on a per-crtc basis. This
allowed me to remove all error paths from the callback. It also allowed
me to remove the vblank wait from the callback.
Signed-off-by: Mandeep Singh Baines m...@chromium.org
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 29 +++--
drivers/gpu/drm/exynos/exynos_drm_drv.c | 19 ---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 ++
3 files changed, 9 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index a85c451..91c175b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -34,9 +34,8 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int
mode)
if (mode DRM_MODE_DPMS_ON) {
/* wait for the completion of page flip. */
if (!wait_event_timeout(exynos_crtc-pending_flip_queue,
- !atomic_read(exynos_crtc-pending_flip),
- HZ/20))
- atomic_set(exynos_crtc-pending_flip, 0);
+ (exynos_crtc-event == NULL), HZ/20))
+ exynos_crtc-event = NULL;
drm_crtc_vblank_off(crtc);
}
@@ -166,7 +165,6 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc
*crtc,
uint32_t page_flip_flags)
{
struct drm_device *dev = crtc-dev;
- struct exynos_drm_private *dev_priv = dev-dev_private;
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
struct drm_framebuffer *old_fb = crtc-primary-fb;
unsigned int crtc_w, crtc_h;
@@ -195,9 +193,7 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc
*crtc,
}
spin_lock_irq(dev-event_lock);
- list_add_tail(event-base.link,
- dev_priv-pageflip_event_list);
- atomic_set(exynos_crtc-pending_flip, 1);
+ exynos_crtc-event = event;
We will lose unfinished prior events by this change. That's why we use
linked list.
Thanks.
spin_unlock_irq(dev-event_lock);
crtc-primary-fb = fb;
@@ -209,11 +205,7 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc
*crtc,
if (ret) {
crtc-primary-fb = old_fb;
- spin_lock_irq(dev-event_lock);
drm_vblank_put(dev, exynos_crtc-pipe);
- list_del(event-base.link);
- atomic_set(exynos_crtc-pending_flip, 0);
- spin_unlock_irq(dev-event_lock);
goto out;
}
@@ -315,7 +307,6 @@ struct exynos_drm_crtc *exynos_drm_crtc_create(struct
drm_device *drm_dev,
return ERR_PTR(-ENOMEM);
init_waitqueue_head(exynos_crtc-pending_flip_queue);
- atomic_set(exynos_crtc-pending_flip, 0);
exynos_crtc-dpms = DRM_MODE_DPMS_OFF;
exynos_crtc-pipe = pipe;
@@ -382,26 +373,20 @@ void exynos_drm_crtc_disable_vblank(struct drm_device
*dev, int pipe)
void exynos_drm_crtc_finish_pageflip(struct drm_device *dev, int pipe)
{
struct exynos_drm_private *dev_priv = dev-dev_private;
- struct drm_pending_vblank_event *e, *t;
struct drm_crtc *drm_crtc = dev_priv-crtc[pipe];
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(drm_crtc);
unsigned long flags;
spin_lock_irqsave(dev-event_lock, flags);
+ if (exynos_crtc-event) {
- list_for_each_entry_safe(e, t, dev_priv-pageflip_event_list,
- base.link) {
- /* if event's pipe isn't same as crtc then ignore it. */
- if (pipe != e-pipe)
- continue;
-
- list_del(e-base.link);
- drm_send_vblank_event(dev, -1, e);
+ drm_send_vblank_event(dev, -1, exynos_crtc-event);
drm_vblank_put(dev, pipe);
- atomic_set(exynos_crtc-pending_flip, 0);
wake_up(exynos_crtc-pending_flip_queue);
+
}
+ exynos_crtc-event = NULL;
spin_unlock_irqrestore(dev-event_lock, flags);
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index b60fd9b..731cdbc 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -61,7 +61,6 @@ static int exynos_drm_load(struct drm_device
Re: [PATCH 5/6] drm/exynos: remove struct *_win_data abstraction on planes
+Cc Inki,
Hi,
On 01/23/2015 09:42 PM, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
struct {fimd,mixer,vidi}_win_data was just keeping the same data
as struct exynos_drm_plane thus get ride of it and use exynos_drm_plane
directly.
It changes how planes are created and remove .win_mode_set() callback
that was only filling all *_win_data structs.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 9 +-
drivers/gpu/drm/exynos/exynos_drm_crtc.h | 1 +
drivers/gpu/drm/exynos/exynos_drm_drv.c | 14 --
drivers/gpu/drm/exynos/exynos_drm_drv.h | 5 +-
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 181 ++---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 20 +--
drivers/gpu/drm/exynos/exynos_drm_plane.h | 6 +-
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 123 -
drivers/gpu/drm/exynos/exynos_mixer.c | 212
+++---
9 files changed, 182 insertions(+), 389 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index d0f4e1b..5cd6c1a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -287,13 +287,13 @@ static void exynos_drm_crtc_attach_mode_property(struct
drm_crtc *crtc)
}
struct exynos_drm_crtc *exynos_drm_crtc_create(struct drm_device *drm_dev,
+struct drm_plane *plane,
int pipe,
enum exynos_drm_output_type type,
struct exynos_drm_crtc_ops *ops,
void *ctx)
{
struct exynos_drm_crtc *exynos_crtc;
- struct drm_plane *plane;
struct exynos_drm_private *private = drm_dev-dev_private;
struct drm_crtc *crtc;
int ret;
@@ -309,12 +309,6 @@ struct exynos_drm_crtc *exynos_drm_crtc_create(struct
drm_device *drm_dev,
exynos_crtc-type = type;
exynos_crtc-ops = ops;
exynos_crtc-ctx = ctx;
- plane = exynos_plane_init(drm_dev, 1 pipe,
- DRM_PLANE_TYPE_PRIMARY);
- if (IS_ERR(plane)) {
- ret = PTR_ERR(plane);
- goto err_plane;
- }
The crtc should have one primary plane, i think it is more reasonable
exynos_drm_crtc_create function creates primary plane.
Thanks.
--
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] exynos/drm: fix no hdmi output
Hi,
On 01/30/2015 09:24 AM, Joonyoung Shim wrote:
+Cc dri-devel ML.
Hi Alban,
On 01/30/2015 06:18 AM, Alban Browaeys wrote:
The hdmi outputs black screen only even though under the hood Xorg and
framebuffer console are fine : devices found and initialized, but
not a pixel out.
Commit 93bca243ec96 (drm/exynos: remove struct exynos_drm_manager)
changed the call order of mixer_initialize with regards to
exynos_drm_crtc_create.
Right, there is no any reason to change order but i don't think it
causes problem because they don't any dependency.
OK, i also get blank screen from hdmi after enable vidi.
This changes breaks hdmi out on Odroid U2 (linux-next with added
Marek Szyprowski v4 hdmi patchset from linux-samsung-soc ML).
I tested Odroid U3 but hdmi out is working well.
Thanks.
Restore the previous call ordering get hdmi to ouput proper pixels:
ie call mixer_initialize first then exynos_drm_crtc_create.
Fixes: 93bca243ec96 (drm/exynos: remove struct exynos_drm_manager)
Signed-off-by: Alban Browaeys pra...@yahoo.com
---
drivers/gpu/drm/exynos/exynos_mixer.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index d8fd8e1..188f90f 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1258,18 +1258,19 @@ static int mixer_bind(struct device *dev, struct
device *manager, void *data)
struct drm_device *drm_dev = data;
int ret;
+ret = mixer_initialize(ctx, drm_dev);
+if (ret)
+return ret;
+
The pipe value for crtc is increased in mixer_initialize so it should be
called before exynos_drm_crtc_create because the pipe value is used in
exynos_drm_crtc_create.
Acked-by: Joonyoung Shim jy0922.s...@samsung.com
Fimd and VIDI driver also have same issue. I will post the patch to fix
this for Fimd and VIDI driver.
Thanks.
ctx-crtc = exynos_drm_crtc_create(drm_dev, ctx-pipe,
EXYNOS_DISPLAY_TYPE_HDMI,
mixer_crtc_ops, ctx);
if (IS_ERR(ctx-crtc)) {
+mixer_ctx_remove(ctx);
ret = PTR_ERR(ctx-crtc);
goto free_ctx;
}
-ret = mixer_initialize(ctx, drm_dev);
-if (ret)
-goto free_ctx;
-
return 0;
free_ctx:
___
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 3/3] exynos: config: Enable support for cpufreq on Exynos SoCs (exynos_defconfig)
On Wed, Jan 28, 2015 at 04:28:40PM +0100, Lukasz Majewski wrote: This commit enables the cpufreq subsystem. Moreover, support for using CPU as a cooling device is provided. Signed-off-by: Lukasz Majewski l.majew...@samsung.com I dont see problems with this patch: Acked-by: Eduardo Valentin edubez...@gmail.com Again, it must go via the correct tree. --- arch/arm/configs/exynos_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 376dbf4..d6be7e8 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -86,6 +86,8 @@ CONFIG_BATTERY_SBS=y CONFIG_CHARGER_TPS65090=y CONFIG_HWMON=y CONFIG_SENSORS_LM90=y +CONFIG_CPU_FREQ=y +CONFIG_CPU_THERMAL=y CONFIG_THERMAL=y CONFIG_EXYNOS_THERMAL=y CONFIG_THERMAL_EMULATION=y -- 2.0.0.rc2 -- 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
