[RFC v2 8/8] ARM: OMAP2+: omap2plus_defconfig: Enable BeagleBone Black HDMI audio support
Select following: CONFIG_SND_DAVINCI_SOC=m CONFIG_SND_AM335X_SOC_NXPTDA_EVM=m Signed-off-by: Jyri Sarha jsa...@ti.com cc: t...@atomide.com --- arch/arm/configs/omap2plus_defconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 52b0d92..c1a9730 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -216,6 +216,8 @@ CONFIG_SND_OMAP_SOC=m CONFIG_SND_OMAP_SOC_OMAP_TWL4030=m CONFIG_SND_OMAP_SOC_OMAP_ABE_TWL6040=m CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m +CONFIG_SND_DAVINCI_SOC=m +CONFIG_SND_AM335X_SOC_NXPTDA_EVM=m CONFIG_USB=y CONFIG_USB_DEBUG=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v2 1/8] clk: add gpio controlled clock
The added clk-gpio is a basic clock that can be enabled and disabled
trough a gpio output. The DT binding document for the clock is also
added. For EPROBE_DEFER handling the registering of the clock has to
be delayed until of_clk_get() call time.
Signed-off-by: Jyri Sarha jsa...@ti.com
cc: mturque...@linaro.org
cc: bcous...@baylibre.com
---
.../devicetree/bindings/clock/gpio-clock.txt | 21 ++
drivers/clk/Makefile |1 +
drivers/clk/clk-gpio.c | 210
include/linux/clk-provider.h | 25 +++
4 files changed, 257 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/gpio-clock.txt
create mode 100644 drivers/clk/clk-gpio.c
diff --git a/Documentation/devicetree/bindings/clock/gpio-clock.txt
b/Documentation/devicetree/bindings/clock/gpio-clock.txt
new file mode 100644
index 000..54fea39
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/gpio-clock.txt
@@ -0,0 +1,21 @@
+Binding for simple gpio controlled clock.
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be gpio-clock.
+- #clock-cells : from common clock binding; shall be set to 0.
+- enable-gpios : GPIO reference for enabling and disabling the clock.
+
+Optional properties:
+- clocks: Maximum of one parent clock is supported.
+
+Example:
+ clock {
+ compatible = gpio-clock;
+ clocks = parentclk;
+ #clock-cells = 0;
+ enable-gpios = gpio 1 GPIO_ACTIVE_HIGH;
+ };
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 7b11106..568b7be 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_COMMON_CLK)+= clk-fixed-rate.o
obj-$(CONFIG_COMMON_CLK) += clk-gate.o
obj-$(CONFIG_COMMON_CLK) += clk-mux.o
obj-$(CONFIG_COMMON_CLK) += clk-composite.o
+obj-$(CONFIG_COMMON_CLK) += clk-gpio.o
# SoCs specific
obj-$(CONFIG_ARCH_BCM2835) += clk-bcm2835.o
diff --git a/drivers/clk/clk-gpio.c b/drivers/clk/clk-gpio.c
new file mode 100644
index 000..e04b0e1
--- /dev/null
+++ b/drivers/clk/clk-gpio.c
@@ -0,0 +1,210 @@
+/*
+ * Copyright (C) 2013 Texas Instruments
+ * Author: Jyri Sarha jsa...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Gpio controlled clock implementation
+ */
+
+#include linux/clk-provider.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/gpio.h
+#include linux/of_gpio.h
+#include linux/err.h
+#include linux/device.h
+
+/**
+ * DOC: basic gpio controlled clock which can be enabled and disabled
+ * with gpio output
+ * Traits of this clock:
+ * prepare - clk_(un)prepare only ensures parent is (un)prepared
+ * enable - clk_enable and clk_disable are functional control gpio
+ * rate - inherits rate from parent. No clk_set_rate support
+ * parent - fixed parent. No clk_set_parent support
+ */
+
+#define to_clk_gpio(_hw) container_of(_hw, struct clk_gpio, hw)
+
+static int clk_gpio_enable(struct clk_hw *hw)
+{
+ struct clk_gpio *gpio = to_clk_gpio(hw);
+ int value = gpio-active_low ? 0 : 1;
+
+ gpio_set_value(gpio-gpio, value);
+
+ return 0;
+}
+
+static void clk_gpio_disable(struct clk_hw *hw)
+{
+ struct clk_gpio *gpio = to_clk_gpio(hw);
+ int value = gpio-active_low ? 1 : 0;
+
+ gpio_set_value(gpio-gpio, value);
+}
+
+static int clk_gpio_is_enabled(struct clk_hw *hw)
+{
+ struct clk_gpio *gpio = to_clk_gpio(hw);
+ int value = gpio_get_value(gpio-gpio);
+
+ return gpio-active_low ? !value : value;
+}
+
+const struct clk_ops clk_gpio_ops = {
+ .enable = clk_gpio_enable,
+ .disable = clk_gpio_disable,
+ .is_enabled = clk_gpio_is_enabled,
+};
+EXPORT_SYMBOL_GPL(clk_gpio_ops);
+
+/**
+ * clk_register_gpio - register a gpip clock with the clock framework
+ * @dev: device that is registering this clock
+ * @name: name of this clock
+ * @parent_name: name of this clock's parent
+ * @flags: framework-specific flags for this clock
+ * @gpio: gpio to control this clock
+ * @active_low: gpio polarity
+ */
+struct clk *clk_register_gpio(struct device *dev, const char *name,
+ const char *parent_name, unsigned long flags,
+ unsigned int gpio, bool active_low)
+{
+ struct clk_gpio *clk_gpio;
+ struct clk *clk = ERR_PTR(-EINVAL);
+ struct clk_init_data init = { NULL };
+ unsigned long gpio_flags;
+ int err;
+
+ if (active_low)
+ gpio_flags = GPIOF_OUT_INIT_LOW;
+ else
+ gpio_flags = GPIOF_OUT_INIT_HIGH;
+
+ err = gpio_request_one(gpio, gpio_flags, name);
+
+ if (err) {
+ pr_err(%s: %s:
[RFC v2 2/8] ASoC: davinci-evm: Add named clock reference to DT bindings
The referenced clock is used to get codec clock rate and the clock is
disabled and enabled in startup and shutdown snd_soc_ops call
backs. The change is also documented in DT bindigs document.
Signed-off-by: Jyri Sarha jsa...@ti.com
cc: bcous...@baylibre.com
---
.../bindings/sound/davinci-evm-audio.txt |9 ++-
sound/soc/davinci/davinci-evm.c| 60 +++-
2 files changed, 66 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
index 865178d..4aa00f6 100644
--- a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
+++ b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
@@ -5,12 +5,19 @@ Required properties:
- ti,model : The user-visible name of this sound complex.
- ti,audio-codec : The phandle of the TLV320AIC3x audio codec
- ti,mcasp-controller : The phandle of the McASP controller
-- ti,codec-clock-rate : The Codec Clock rate (in Hz) applied to the Codec
- ti,audio-routing : A list of the connections between audio components.
Each entry is a pair of strings, the first being the connection's sink,
the second being the connection's source. Valid names for sources and
sinks are the codec's pins, and the jacks on the board:
+Optional properties:
+- ti,codec-clock-rate : The Codec Clock rate (in Hz) applied to the Codec.
+- clocks : Reference to the clock used as codec clock
+- clock-names : The codec clock should be named ti,codec-clock
+- Either codec-clock-rate or the codec-clock reference has to be defined. If
+ the both are defined the driver attempts to set referenced clock to the
+ defined rate and takes the rate from the clock reference.
+
Board connectors:
* Headphone Jack
diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
index 70ff377..b28c9fd 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -17,6 +17,7 @@
#include linux/platform_data/edma.h
#include linux/i2c.h
#include linux/of_platform.h
+#include linux/clk.h
#include sound/core.h
#include sound/pcm.h
#include sound/soc.h
@@ -30,9 +31,30 @@
#include davinci-i2s.h
struct snd_soc_card_drvdata_davinci {
+ struct clk *mclk;
unsigned sysclk;
};
+static int evm_startup(struct snd_pcm_substream *substream)
+{
+ struct snd_soc_pcm_runtime *rtd = substream-private_data;
+ struct snd_soc_card *soc_card = rtd-codec-card;
+ struct clk *mclk = ((struct snd_soc_card_drvdata_davinci *)
+ snd_soc_card_get_drvdata(soc_card))-mclk;
+
+ return clk_prepare_enable(mclk);
+}
+
+static void evm_shutdown(struct snd_pcm_substream *substream)
+{
+ struct snd_soc_pcm_runtime *rtd = substream-private_data;
+ struct snd_soc_card *soc_card = rtd-codec-card;
+ struct clk *mclk = ((struct snd_soc_card_drvdata_davinci *)
+ snd_soc_card_get_drvdata(soc_card))-mclk;
+
+ clk_disable_unprepare(mclk);
+}
+
static int evm_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params)
{
@@ -59,6 +81,8 @@ static int evm_hw_params(struct snd_pcm_substream *substream,
}
static struct snd_soc_ops evm_ops = {
+ .startup = evm_startup,
+ .shutdown = evm_shutdown,
.hw_params = evm_hw_params,
};
@@ -348,6 +372,7 @@ static int davinci_evm_probe(struct platform_device *pdev)
of_match_device(of_match_ptr(davinci_evm_dt_ids), pdev-dev);
struct snd_soc_dai_link *dai = (struct snd_soc_dai_link *) match-data;
struct snd_soc_card_drvdata_davinci *drvdata = NULL;
+ struct clk *mclk;
int ret = 0;
evm_soc_card.dai_link = dai;
@@ -367,13 +392,38 @@ static int davinci_evm_probe(struct platform_device *pdev)
if (ret)
return ret;
+ mclk = of_clk_get_by_name(np, ti,codec-clock);
+ if (PTR_ERR(mclk) == -EPROBE_DEFER) {
+ return -EPROBE_DEFER;
+ } else if (IS_ERR(mclk)) {
+ dev_dbg(pdev-dev, Codec clock not found.\n);
+ mclk = NULL;
+ }
+
drvdata = devm_kzalloc(pdev-dev, sizeof(*drvdata), GFP_KERNEL);
if (!drvdata)
return -ENOMEM;
+ drvdata-mclk = mclk;
+
ret = of_property_read_u32(np, ti,codec-clock-rate, drvdata-sysclk);
- if (ret 0)
- return -EINVAL;
+
+ if (ret 0) {
+ if (!drvdata-mclk) {
+ dev_err(pdev-dev,
+ No clock or clock rate defined.\n);
+ return -EINVAL;
+ }
+ drvdata-sysclk = clk_get_rate(drvdata-mclk);
+ } else if (drvdata-mclk) {
+ unsigned int requestd_rate = drvdata-sysclk;
+ clk_set_rate(drvdata-mclk, drvdata-sysclk);
+ drvdata-sysclk =
[RFC v2 5/8] ASoC: davinci: HDMI audio build for AM33XX and TDA998x
Adds configuration option for HDMI audio support for AM33XX based boards with NXP TDA998x HDMI transmitter. The audio is connected to NXP TDA998x trough McASP running in i2s mode. Signed-off-by: Jyri Sarha jsa...@ti.com --- sound/soc/davinci/Kconfig | 12 sound/soc/davinci/Makefile |1 + 2 files changed, 13 insertions(+) diff --git a/sound/soc/davinci/Kconfig b/sound/soc/davinci/Kconfig index a8ec1fc..40dd5d1 100644 --- a/sound/soc/davinci/Kconfig +++ b/sound/soc/davinci/Kconfig @@ -26,6 +26,18 @@ config SND_AM33XX_SOC_EVM AM335X-EVMSK, and BeagelBone with AudioCape boards have this setup. +config SND_AM335X_SOC_NXPTDA_EVM + tristate HDMI Audio for the AM33XX chip based boards with TDA998x + depends on SND_DAVINCI_SOC SOC_AM33XX + depends on DRM_TILCDC DRM_I2C_NXP_TDA998X + select SND_SOC_HDMI_CODEC + select SND_DAVINCI_SOC_MCASP + help + Say Y or M if you want to add support for HDMI SoC audio on + AM33XX boards with NXP TDA998x HDMI transmitter. For example + BeagleBoneBack. The audio is connected to NXP TDA998x trough + McASP running in i2s mode. + config SND_DAVINCI_SOC_EVM tristate SoC Audio support for DaVinci DM6446, DM355 or DM365 EVM depends on SND_DAVINCI_SOC diff --git a/sound/soc/davinci/Makefile b/sound/soc/davinci/Makefile index 744d4d9..7587a70 100644 --- a/sound/soc/davinci/Makefile +++ b/sound/soc/davinci/Makefile @@ -13,3 +13,4 @@ obj-$(CONFIG_SND_DAVINCI_SOC_VCIF) += snd-soc-davinci-vcif.o snd-soc-evm-objs := davinci-evm.o obj-$(CONFIG_SND_DAVINCI_SOC_GENERIC_EVM) += snd-soc-evm.o +obj-$(CONFIG_SND_AM335X_SOC_NXPTDA_EVM) += snd-soc-evm.o -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v2 6/8] drm/tilcdc: Add I2C HDMI audio config for tda998x
The configuration is needed for HDMI audio. The swap and mirr
parameters have to be correctly set in the configuration in order to
have proper colors in the HDMI picture.
Signed-off-by: Jyri Sarha jsa...@ti.com
cc: airl...@linux.ie
---
drivers/gpu/drm/tilcdc/tilcdc_slave.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
index 595068b..e43240a 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
@@ -19,6 +19,7 @@
#include linux/pinctrl/pinmux.h
#include linux/pinctrl/consumer.h
#include drm/drm_encoder_slave.h
+#include drm/i2c/tda998x.h
#include tilcdc_drv.h
@@ -111,8 +112,29 @@ static const struct drm_encoder_helper_funcs
slave_encoder_helper_funcs = {
.restore= drm_i2c_encoder_restore,
};
+static struct tda998x_encoder_params tda998x_pdata = {
+ .swap_b = 0x3,
+ .mirr_b = 0x0,
+ .swap_a = 0x2,
+ .mirr_a = 0x0,
+ .swap_d = 0x1,
+ .mirr_d = 0x0,
+ .swap_c = 0x0,
+ .mirr_c = 0x0,
+ .swap_f = 0x5,
+ .mirr_f = 0x0,
+ .swap_e = 0x4,
+ .mirr_e = 0x0,
+ .audio_cfg = 0x3, /* I2S mode */
+ .audio_clk_cfg = 1, /* select clock pin */
+ .audio_frame[1] = 1,/* channels - 1 */
+ .audio_format = AFMT_I2S,
+ .audio_sample_rate = 48000,
+};
+
static const struct i2c_board_info info = {
- I2C_BOARD_INFO(tda998x, 0x70)
+ I2C_BOARD_INFO(tda998x, 0x70),
+ .platform_data = tda998x_pdata,
};
static struct drm_encoder *slave_encoder_create(struct drm_device *dev,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v2 7/8] ARM: OMAP2+: omap2plus_defconfig: Enable tilcdc and TDA998X HDMI support
This enables HDMI video support on Beaglebone-Black. Signed-off-by: Jyri Sarha jsa...@ti.com cc: t...@atomide.com --- arch/arm/configs/omap2plus_defconfig |3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 254cf05..52b0d92 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -176,6 +176,9 @@ CONFIG_REGULATOR_TPS65023=y CONFIG_REGULATOR_TPS6507X=y CONFIG_REGULATOR_TPS65217=y CONFIG_REGULATOR_TPS65910=y +CONFIG_DRM=m +CONFIG_DRM_I2C_NXP_TDA998X=m +CONFIG_DRM_TILCDC=m CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_MODE_HELPERS=y -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v2 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
Add machine driver support for BeagleBone-Black and other boards with
tilcdc support and NXP TDA998X HDMI transmitter connected to McASP
port in I2S mode. The 44100 Hz sample-rate and it's multiples can not
be supported on Beaglebone-Black because of limited clock-rate
support. The only supported sample format is SNDRV_PCM_FORMAT_S32_LE.
The 8 least significant bits are ignored.
Signed-off-by: Jyri Sarha jsa...@ti.com
cc: bcous...@baylibre.com
---
.../bindings/sound/davinci-evm-audio.txt |4 +-
sound/soc/davinci/davinci-evm.c| 167 +++-
2 files changed, 168 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
index 4aa00f6..f1e1031 100644
--- a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
+++ b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
@@ -1,7 +1,9 @@
* Texas Instruments SoC audio setups with TLV320AIC3X Codec
Required properties:
-- compatible : ti,da830-evm-audio : forDM365/DA8xx/OMAPL1x/AM33xx
+- compatible :
+ ti,da830-evm-audio : for DM365/DA8xx/OMAPL1x/AM33xx
+ ti,am33xx-beaglebone-black-audio : for Beaglebone-black HDMI audio
- ti,model : The user-visible name of this sound complex.
- ti,audio-codec : The phandle of the TLV320AIC3x audio codec
- ti,mcasp-controller : The phandle of the McASP controller
diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
index b28c9fd..3d3138d 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -21,6 +21,7 @@
#include sound/core.h
#include sound/pcm.h
#include sound/soc.h
+#include sound/pcm_params.h
#include asm/dma.h
#include asm/mach-types.h
@@ -33,8 +34,13 @@
struct snd_soc_card_drvdata_davinci {
struct clk *mclk;
unsigned sysclk;
+ struct snd_pcm_hw_constraint_list *rate_constraint;
};
+/* If changing sample format the tda998x configuration (REG_CTS_N) needs
+ to be changed. */
+#define TDA998X_SAMPLE_FORMAT SNDRV_PCM_FORMAT_S32_LE
+
static int evm_startup(struct snd_pcm_substream *substream)
{
struct snd_soc_pcm_runtime *rtd = substream-private_data;
@@ -80,12 +86,80 @@ static int evm_hw_params(struct snd_pcm_substream
*substream,
return 0;
}
+static int evm_tda998x_startup(struct snd_pcm_substream *substream)
+{
+ struct snd_pcm_runtime *runtime = substream-runtime;
+ struct snd_soc_pcm_runtime *rtd = substream-private_data;
+ struct snd_soc_card *soc_card = rtd-codec-card;
+ struct snd_soc_card_drvdata_davinci *drvdata =
+ (struct snd_soc_card_drvdata_davinci *)
+ snd_soc_card_get_drvdata(soc_card);
+ struct snd_mask *fmt = constrs_mask(runtime-hw_constraints,
+ SNDRV_PCM_HW_PARAM_FORMAT);
+ snd_mask_none(fmt);
+ snd_mask_set(fmt, TDA998X_SAMPLE_FORMAT);
+
+ runtime-hw.rate_min = drvdata-rate_constraint-list[0];
+ runtime-hw.rate_max = drvdata-rate_constraint-list[
+ drvdata-rate_constraint-count - 1];
+ runtime-hw.rates = SNDRV_PCM_RATE_KNOT;
+
+ snd_pcm_hw_constraint_list(runtime, 0, SNDRV_PCM_HW_PARAM_RATE,
+ drvdata-rate_constraint);
+ snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_CHANNELS,
+2, 2);
+
+ return evm_startup(substream);
+}
+
+static unsigned int evm_get_bclk(struct snd_pcm_hw_params *params)
+{
+ int sample_size = snd_pcm_format_width(params_format(params));
+ int rate = params_rate(params);
+ int channels = params_channels(params);
+
+ return sample_size * channels * rate;
+}
+
+static int evm_tda998x_hw_params(struct snd_pcm_substream *substream,
+struct snd_pcm_hw_params *params)
+{
+ struct snd_soc_pcm_runtime *rtd = substream-private_data;
+ struct snd_soc_dai *cpu_dai = rtd-cpu_dai;
+ struct snd_soc_codec *codec = rtd-codec;
+ struct snd_soc_card *soc_card = codec-card;
+ struct platform_device *pdev = to_platform_device(soc_card-dev);
+ unsigned int bclk_freq = evm_get_bclk(params);
+ unsigned sysclk = ((struct snd_soc_card_drvdata_davinci *)
+ snd_soc_card_get_drvdata(soc_card))-sysclk;
+ int ret;
+
+ ret = snd_soc_dai_set_clkdiv(cpu_dai, 1, sysclk / bclk_freq);
+ if (ret 0) {
+ dev_err(pdev-dev, can't set CPU DAI clock divider %d\n,
+ ret);
+ return ret;
+ }
+
+ ret = snd_soc_dai_set_sysclk(cpu_dai, 0, sysclk, SND_SOC_CLOCK_IN);
+ if (ret 0)
+ return ret;
+
+ return ret;
+}
+
static struct snd_soc_ops evm_ops = {
.startup = evm_startup,
.shutdown = evm_shutdown,
.hw_params = evm_hw_params,
};
+static struct
[RFC v2 4/8] ASoC: hdmi-codec: Add devicetree binding with documentation
Signed-off-by: Jyri Sarha jsa...@ti.com
cc: bcous...@baylibre.com
---
Documentation/devicetree/bindings/sound/hdmi.txt | 17 +
sound/soc/codecs/hdmi.c | 10 ++
2 files changed, 27 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/hdmi.txt
diff --git a/Documentation/devicetree/bindings/sound/hdmi.txt
b/Documentation/devicetree/bindings/sound/hdmi.txt
new file mode 100644
index 000..31af7bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/hdmi.txt
@@ -0,0 +1,17 @@
+Device-Tree bindings for dummy HDMI codec
+
+Required properties:
+ - compatible: should be linux,hdmi-audio.
+
+CODEC output pins:
+ * TX
+
+CODEC input pins:
+ * RX
+
+Example node:
+
+ hdmi_audio: hdmi_audio@0 {
+ compatible = linux,hdmi-audio;
+ status = okay;
+ };
diff --git a/sound/soc/codecs/hdmi.c b/sound/soc/codecs/hdmi.c
index 32797a8..9cb1c7d 100644
--- a/sound/soc/codecs/hdmi.c
+++ b/sound/soc/codecs/hdmi.c
@@ -20,6 +20,7 @@
*/
#include linux/module.h
#include sound/soc.h
+#include linux/of_device.h
#define DRV_NAME hdmi-audio-codec
@@ -60,6 +61,14 @@ static struct snd_soc_dai_driver hdmi_codec_dai = {
};
+#ifdef CONFIG_OF
+static const struct of_device_id hdmi_audio_codec_ids[] = {
+ { .compatible = linux,hdmi-audio, },
+ { }
+};
+MODULE_DEVICE_TABLE(of, hdmi_audio_codec_ids);
+#endif
+
static struct snd_soc_codec_driver hdmi_codec = {
.dapm_widgets = hdmi_widgets,
.num_dapm_widgets = ARRAY_SIZE(hdmi_widgets),
@@ -83,6 +92,7 @@ static struct platform_driver hdmi_codec_driver = {
.driver = {
.name = DRV_NAME,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(hdmi_audio_codec_ids),
},
.probe = hdmi_codec_probe,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v2 0/8] Beaglebone-Black HDMI audio
Changes since the first RFC version of the patches: - Drop out already applied: ASoC: hdmi-codec: Add SNDRV_PCM_FMTBIT_32_LE playback format - Change sound node's compatible property form: ti,am33xx-beaglebone-black to ti,am33xx-beaglebone-black-audio - Some minor style issue fixes from TI internal review The patches have been rebased on top of: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound topic/davinci The associated dts changes will be sent shortly as a separate patch. Best regards, Jyri Jyri Sarha (8): clk: add gpio controlled clock ASoC: davinci-evm: Add named clock reference to DT bindings ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus ASoC: hdmi-codec: Add devicetree binding with documentation ASoC: davinci: HDMI audio build for AM33XX and TDA998x drm/tilcdc: Add I2C HDMI audio config for tda998x ARM: OMAP2+: omap2plus_defconfig: Enable tilcdc and TDA998X HDMI support ARM: OMAP2+: omap2plus_defconfig: Enable BeagleBone Black HDMI audio support .../devicetree/bindings/clock/gpio-clock.txt | 21 ++ .../bindings/sound/davinci-evm-audio.txt | 13 +- Documentation/devicetree/bindings/sound/hdmi.txt | 17 ++ arch/arm/configs/omap2plus_defconfig |5 + drivers/clk/Makefile |1 + drivers/clk/clk-gpio.c | 210 ++ drivers/gpu/drm/tilcdc/tilcdc_slave.c | 24 ++- include/linux/clk-provider.h | 25 +++ sound/soc/codecs/hdmi.c| 10 + sound/soc/davinci/Kconfig | 12 ++ sound/soc/davinci/Makefile |1 + sound/soc/davinci/davinci-evm.c| 227 +++- 12 files changed, 559 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/gpio-clock.txt create mode 100644 Documentation/devicetree/bindings/sound/hdmi.txt create mode 100644 drivers/clk/clk-gpio.c -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v2] ARM/dts: am335x-boneblack: Add HDMI audio support
Adds mcasp0_pins, clk_mcasp0_fixed, clk_mcasp0, mcasp0, hdmi_audio,
and sound nodes.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
arch/arm/boot/dts/am335x-boneblack.dts | 52
1 file changed, 52 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 6b71ad9..860ea98 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -60,12 +60,35 @@
0x1b0 0x03 /* xdma_event_intr0, OMAP_MUX_MODE3 |
AM33XX_PIN_OUTPUT */
;
};
+
+ mcasp0_pins: mcasp0_pins {
+ pinctrl-single,pins =
+ 0x1ac (PIN_INPUT_PULLUP | MUX_MODE0) /*
mcasp0_ahclkx.mcasp0_ahclkx */
+ 0x19c (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mcasp0_ahclkr.mcasp0_axr2 */
+ 0x194 (PIN_OUTPUT_PULLUP | MUX_MODE0) /*
mcasp0_fsx.mcasp0_fsx */
+ 0x190 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mcasp0_aclkx.mcasp0_aclkx */
+ 0x06c (PIN_OUTPUT_PULLUP | MUX_MODE7) /*
gpmc_a11.gpio1_27 */
+ ;
+ };
};
lcdc {
status = okay;
};
+mcasp0{
+ pinctrl-names = default;
+ pinctrl-0 = mcasp0_pins;
+ status = okay;
+ op-mode = 0; /* MCASP_IIS_MODE */
+ tdm-slots = 2;
+ serial-dir = /* 0: INACTIVE, 1: TX, 2: RX */
+ 0 0 1 0
+ ;
+ tx-num-evt = 1;
+ rx-num-evt = 1;
+};
+
/ {
hdmi {
compatible = ti,tilcdc,slave;
@@ -75,4 +98,33 @@
pinctrl-1 = nxp_hdmi_bonelt_off_pins;
status = okay;
};
+
+ clk_mcasp0_fixed: clk_mcasp0_fixed {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 24576000;
+ };
+
+ clk_mcasp0: clk_mcasp0 {
+ #clock-cells = 0;
+ compatible = gpio-clock;
+ clocks = clk_mcasp0_fixed;
+ enable-gpios = gpio1 27 GPIO_ACTIVE_HIGH; /* BeagleBone
Black Clk enable on GPIO1_27 */
+ };
+
+ hdmi_audio: hdmi_audio@0 {
+ compatible = linux,hdmi-audio;
+ status = okay;
+ };
+
+ sound {
+ compatible = ti,am33xx-beaglebone-black-audio;
+ ti,model = TI BeagleBone Black;
+ ti,audio-codec = hdmi_audio;
+ ti,mcasp-controller = mcasp0;
+ ti,audio-routing =
+ HDMI Out, TX;
+ clocks = clk_mcasp0;
+ clock-names = ti,codec-clock;
+ };
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v2] Beaglebone-Black HDMI audio
Changes since the first RFC version of the patch: - Change sound node's compatible property form: ti,am33xx-beaglebone-black to ti,am33xx-beaglebone-black-audio The patch has been rebased on top of: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.13/dts The associated code changes can be found here: http://mailman.alsa-project.org/pipermail/alsa-devel/2013-December/069897.html Best regards, Jyri Jyri Sarha (1): ARM/dts: am335x-boneblack: Add HDMI audio support arch/arm/boot/dts/am335x-boneblack.dts | 52 1 file changed, 52 insertions(+) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot
Hi,
On Fri, Dec 06, 2013 at 02:27:25PM -0800, Tony Lindgren wrote:
* Sebastian Reichel s...@debian.org [131206 13:37]:
Nokia N900 DT boot breaks for me using 3.13-rc3. You can see the
relevant kernel output below. Disabling the AES module in the
omap3-n900.dts with status = disabled fixed the boot for me.
OK thanks for letting me know. How about the following patch to
fix it?
Aaro, does this work for you on n9(50)? I'd assume n9(50) needs a
similar patch too.
Yes, also N9/N950 crashes and your patch fixes that.
Thanks,
A.
8 --
From: Tony Lindgren t...@atomide.com
Date: Fri, 6 Dec 2013 14:20:17 -0800
Subject: [PATCH] ARM: dts: Fix booting for secure omaps
Commit 7ce93f3 (ARM: OMAP2+: Fix more missing data for omap3.dtsi file)
fixed missing device tree data for omaps, but did not account for some of the
hardware modules being inaccessible for secure omaps. This causes the
following error on secure omaps:
Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa0c5048
SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW3.13.0-rc2+ #446
task: ce057b40 ti: ce058000 task.ti: ce058000
PC is at omap_aes_dma_stop+0x24/0x3c
LR is at omap_aes_probe+0x1cc/0x584
psr: 6113
sp : ce059e20 ip : ce0b4ee0 fp :
r10: c0573ae8 r9 : c0749508 r8 :
r7 : ce0b4e00 r6 : r5 : ce0b4e10 r4 : ce274890
r3 : fa0c5048 r2 : 0048 r1 : 002c r0 : ce274890
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c5387d Table: 80004019 DAC: 0015
Process swapper/0 (pid: 1, stack limit = 0xce058248)
Stack: (0xce059e20 to 0xce05a000)
9e20: c0749508 a1ff c016cd8c c06b5a06 ce2a45f0 ce2a4570 ce0b5fb0
9e40: 480c5000 480c504f c0abe4e4 0200
9e60: ce0b4e10 ce0b4e10 c082da3c c082da3c c02b8c70 c077c610 c0749508
9e80: c02b9e7c c02b9e64 ce0b4e10 c02b8b20 ce0b4e10 ce0b4e44
9ea0: c082da3c c02b8cd8 ce059eb8 c082da3c c02b7408 ce079edc ce0b1a34
9ec0: c082da3c c082da3c ce2a0280 c08158d8 c02b8358 c0663405 c0663405
9ee0: 0073 c082da3c c079e4e8 c07ab3bc c0844340 c02b9334 0006
9f00: c079e4e8 c0008920 c067f6bf c0ac7c6b c0712e28
9f20: c0712e38 ce059f38 0093 c0ac7c82 c0058994 c07130e8
9f40: c07127b8 0093 0006 0006 0001 0006 0006 c079e4e8
9f60: c07ab3bc c0844340 0093 c0749508 c079e4f4 c0749c64 0006 0006
9f80: c0749508 c0517e2c
9fa0: c0517e34 c000dfb8
9fc0:
9fe0: 0013
(omap_aes_probe+0x1cc/0x584)
(platform_drv_probe+0x18/0x48)
(driver_probe_device+0xb0/0x200)
(__driver_attach+0x68/0x8c)
(bus_for_each_dev+0x50/0x88)
(bus_add_driver+0xcc/0x1c8)
(driver_register+0x9c/0xe0)
(do_one_initcall+0x98/0x140)
(kernel_init_freeable+0x16c/0x23c)
(kernel_init+0x8/0x100)
(ret_from_fork+0x14/0x3c)
Code: e1811002 e5932020 e590300c e0833002 (e593c000)
Let's fix the issue by adding omap34xx-hs.dtsi and omap36xx-hs.dtsi and make
n900, n9 and n950 to use them.
Reported-by: Sebastian Reichel s...@debian.org
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -9,7 +9,7 @@
/dts-v1/;
-#include omap34xx.dtsi
+#include omap34xx-hs.dtsi
/ {
model = Nokia N900;
--- a/arch/arm/boot/dts/omap3-n950-n9.dtsi
+++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
@@ -8,7 +8,7 @@
* published by the Free Software Foundation.
*/
-#include omap36xx.dtsi
+#include omap36xx-hs.dtsi
/ {
cpus {
--- /dev/null
+++ b/arch/arm/boot/dts/omap34xx-hs.dtsi
@@ -0,0 +1,8 @@
+/* Disabled modules for secure omaps */
+
+#include omap34xx.dtsi
+
+/* Secure omaps have some devices inaccessible depending on the firmware */
+aes {
+ status = disabled;
+};
--- /dev/null
+++ b/arch/arm/boot/dts/omap36xx-hs.dtsi
@@ -0,0 +1,8 @@
+/* Disabled modules for secure omaps */
+
+#include omap36xx.dtsi
+
+/* Secure omaps have some devices inaccessible depending on the firmware */
+aes {
+ status = disabled;
+};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot
* Aaro Koskinen aaro.koski...@iki.fi [131208 06:15]: Hi, On Fri, Dec 06, 2013 at 02:27:25PM -0800, Tony Lindgren wrote: * Sebastian Reichel s...@debian.org [131206 13:37]: Nokia N900 DT boot breaks for me using 3.13-rc3. You can see the relevant kernel output below. Disabling the AES module in the omap3-n900.dts with status = disabled fixed the boot for me. OK thanks for letting me know. How about the following patch to fix it? Aaro, does this work for you on n9(50)? I'd assume n9(50) needs a similar patch too. Yes, also N9/N950 crashes and your patch fixes that. OK thanks, there's the updated version of this patch if you guys care to ack, I'd like to commit it today. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot
On Sun, Dec 08, 2013 at 08:40:29AM -0800, Tony Lindgren wrote: * Aaro Koskinen aaro.koski...@iki.fi [131208 06:15]: Hi, On Fri, Dec 06, 2013 at 02:27:25PM -0800, Tony Lindgren wrote: * Sebastian Reichel s...@debian.org [131206 13:37]: Nokia N900 DT boot breaks for me using 3.13-rc3. You can see the relevant kernel output below. Disabling the AES module in the omap3-n900.dts with status = disabled fixed the boot for me. OK thanks for letting me know. How about the following patch to fix it? Aaro, does this work for you on n9(50)? I'd assume n9(50) needs a similar patch too. Yes, also N9/N950 crashes and your patch fixes that. OK thanks, there's the updated version of this patch if you guys care to ack, I'd like to commit it today. Where is the updated version? I couldn't find it in this thread. -- Sebastian signature.asc Description: Digital signature
Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot
* Sebastian Reichel s...@debian.org [131208 09:11]: On Sun, Dec 08, 2013 at 08:40:29AM -0800, Tony Lindgren wrote: * Aaro Koskinen aaro.koski...@iki.fi [131208 06:15]: Hi, On Fri, Dec 06, 2013 at 02:27:25PM -0800, Tony Lindgren wrote: * Sebastian Reichel s...@debian.org [131206 13:37]: Nokia N900 DT boot breaks for me using 3.13-rc3. You can see the relevant kernel output below. Disabling the AES module in the omap3-n900.dts with status = disabled fixed the boot for me. OK thanks for letting me know. How about the following patch to fix it? Aaro, does this work for you on n9(50)? I'd assume n9(50) needs a similar patch too. Yes, also N9/N950 crashes and your patch fixes that. OK thanks, there's the updated version of this patch if you guys care to ack, I'd like to commit it today. Where is the updated version? I couldn't find it in this thread. It's Message-ID: 20131207003824.go26...@atomide.com in this thread, the version that disables aes, sham and timer12 like we currently do in the hwmod code for legacy booting: http://www.spinics.net/lists/linux-omap/msg101045.html Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot
On Sun, Dec 08, 2013 at 09:43:51AM -0800, Tony Lindgren wrote: * Sebastian Reichel s...@debian.org [131208 09:11]: On Sun, Dec 08, 2013 at 08:40:29AM -0800, Tony Lindgren wrote: * Aaro Koskinen aaro.koski...@iki.fi [131208 06:15]: Hi, On Fri, Dec 06, 2013 at 02:27:25PM -0800, Tony Lindgren wrote: * Sebastian Reichel s...@debian.org [131206 13:37]: Nokia N900 DT boot breaks for me using 3.13-rc3. You can see the relevant kernel output below. Disabling the AES module in the omap3-n900.dts with status = disabled fixed the boot for me. OK thanks for letting me know. How about the following patch to fix it? Aaro, does this work for you on n9(50)? I'd assume n9(50) needs a similar patch too. Yes, also N9/N950 crashes and your patch fixes that. OK thanks, there's the updated version of this patch if you guys care to ack, I'd like to commit it today. Where is the updated version? I couldn't find it in this thread. It's Message-ID: 20131207003824.go26...@atomide.com in this thread, the version that disables aes, sham and timer12 like we currently do in the hwmod code for legacy booting: http://www.spinics.net/lists/linux-omap/msg101045.html Tested-by: Aaro Koskinen aaro.koski...@iki.fi A. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot
On Sun, Dec 08, 2013 at 09:43:51AM -0800, Tony Lindgren wrote: * Sebastian Reichel s...@debian.org [131208 09:11]: On Sun, Dec 08, 2013 at 08:40:29AM -0800, Tony Lindgren wrote: * Aaro Koskinen aaro.koski...@iki.fi [131208 06:15]: Hi, On Fri, Dec 06, 2013 at 02:27:25PM -0800, Tony Lindgren wrote: * Sebastian Reichel s...@debian.org [131206 13:37]: Nokia N900 DT boot breaks for me using 3.13-rc3. You can see the relevant kernel output below. Disabling the AES module in the omap3-n900.dts with status = disabled fixed the boot for me. OK thanks for letting me know. How about the following patch to fix it? Aaro, does this work for you on n9(50)? I'd assume n9(50) needs a similar patch too. Yes, also N9/N950 crashes and your patch fixes that. OK thanks, there's the updated version of this patch if you guys care to ack, I'd like to commit it today. Where is the updated version? I couldn't find it in this thread. It's Message-ID: 20131207003824.go26...@atomide.com in this thread, the version that disables aes, sham and timer12 like we currently do in the hwmod code for legacy booting: http://www.spinics.net/lists/linux-omap/msg101045.html boots on my N900: Acked-By: Sebastian Reichel s...@debian.org -- Sebastian signature.asc Description: Digital signature
Re: [PATCH v2 01/15] mfd: menelaus: Drop __exit section annotation
On Tue, Dec 03, 2013 at 09:51:36AM +, Lee Jones wrote: The code looks mostly fine, but the implementation of the commit logs seems lazy. Please submit a v3 using coherent sentences with full explanations and correct punctuation. example ? -- balbi signature.asc Description: Digital signature
Re: OMAP3 NAND ECC selection
On 12/05/2013 11:38 AM, Tony Lindgren wrote: * Thomas Petazzoni thomas.petazz...@free-electrons.com [131205 11:33]: Dear Brian Norris, On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote: The long term benefits is simply to properly handle the hardware constraints. We have hardware platforms were parts of the NAND *MUST* use 1-bit ECC to be compatible with the ROM code, and other parts of the NAND *MUST* use stronger 4-bits or 8-bits ECC to comply with the NAND requirements. Using 1-bit ECC on NAND is not a long-term solution. Given that fact, I think your ROM code is what may need to change, not the entire MTD subsystem. As someone (Tom Rini maybe?) pointed out, today the shift is 1-bit ECC supported by ROM code vs. 4 or 8 bits required by NAND. But we can very well imagine that tomorrow ROM code will support BCH4 (and the NAND will ensure block 0 is OK for use with BCH4) but the rest of the NAND will require BCH16 or something like that. I'm not designing ROM code, and the fact that they today have this limitation, should be an indication that Linux should be capable of handling different ECC schemes to handle those hardware constraints. Yeah and it seems that for the bootloader partition we need to be able to specify the ECC scheme in the .dts file to avoid having people trash their system unless they really want to do it. /me at least has rebooted and reflashed way too many times unnecessarily while trying to update MLO or u-boot from the kernel. The M-Sys/Sandisk docg4 flash chip has a similiar issue, but is even more esoteric than merely a different ecc scheme for the SPL/u-boot partition. Not only is a different ecc scheme used for the SPL (actually it uses no ecc at all), but the flash controller must be placed into a special (proprietary) mode (reliable mode) before the SPL is written. Like the omap2 solution, the docg4 driver can be loaded with a special module parameter that enables writing the SPL partition in this mode. The docg4 is kind of a special case, though, because it is a nand flash wrapped inside a proprietary non-standard flash controller. Mike -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] two regression fixes and two more omap dt fixes against v3.13-rc2
The following changes since commit 374b105797c3d4f29c685f3be535c35f5689b30e: Linux 3.13-rc3 (2013-12-06 09:34:04 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.13/yet-more-dt-regressions-take2 for you to fetch changes up to f2e2c9d9b4087b74eb9e00d8dfac148354cb0b71: ARM: dts: Fix booting for secure omaps (2013-12-06 15:30:43 -0800) A rather big fix for a regression where we have dropped omap4 hwmod data earlier but are not initializing it from device tree. In addition to this fix we eventually also be fix the issues in the .dts files and drivers, but that's too intrusive for the -rc cycle and must be done later on. Also a fix for a regression where we now are wrongly trying to initialize devices on secure omaps like n900 and n9* when booted using device tree. We need to set aes, sham and timer12 to disabled mode for secure devices as they are claimed by the firmware running in the secure mode. And two more legacy booting vs device tree based booting fixes for am3517 that I did not notice earlier until Nishant Menon reported these to me few days ago. With these we're good to go having v3.13 working both for legacy booting and device tree based booting, and we can then go ahed and drop the legacy booting for mach-omap2 for v3.14. Nishanth Menon (1): ARM: OMAP2+: Fix the machine entry for am3517 Tony Lindgren (3): ARM: OMAP2+: Fix overwriting hwmod data with data from device tree ARM: dts: Fix missing entries for am3517 ARM: dts: Fix booting for secure omaps arch/arm/boot/dts/am3517-evm.dts | 6 +-- arch/arm/boot/dts/am3517.dtsi| 63 +++ arch/arm/boot/dts/omap3-n900.dts | 2 +- arch/arm/boot/dts/omap3-n950-n9.dtsi | 2 +- arch/arm/boot/dts/omap34xx-hs.dtsi | 16 ++ arch/arm/boot/dts/omap36xx-hs.dtsi | 16 ++ arch/arm/mach-omap2/board-generic.c | 18 +++ arch/arm/mach-omap2/omap_hwmod.c | 98 8 files changed, 196 insertions(+), 25 deletions(-) create mode 100644 arch/arm/boot/dts/am3517.dtsi create mode 100644 arch/arm/boot/dts/omap34xx-hs.dtsi create mode 100644 arch/arm/boot/dts/omap36xx-hs.dtsi -- To unsubscribe from this list: send the line unsubscribe linux-omap 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 5/6] Revert ARM: OMAP2+: Provide alias to USB PHY clock
* Roger Quadros rog...@ti.com [131023 03:14]:
On 10/22/2013 06:17 PM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [131010 02:23]:
On 10/09/2013 06:15 PM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [131009 00:19]:
Hi Tony,
On 10/08/2013 01:06 PM, Roger Quadros wrote:
This reverts commit 741532c4a995be11815cb72d4d7a48f442a22fea.
The proper clock reference is provided in device tree so we
no longer need this.
Could you please Ack this one? I think it is best if it goes through
Benoit's tree.
I could queue this into my board removal series that will be
based on Benoit's branch if that works for you. And this
also seems to depend on the omap-for-v3.13/quirk branch
that moves all the legacy pdata handling into pdata-quirks.c.
OK Tony. Thanks.
Actually, can you please update this patch against branch
omap-for-v3.13/board-removal-take2 and check the
omap5_uevm_legacy_init() part as well?
Updated patch is below. Note that this must go in only after Benoit has picked
up Tero's clock series and the dts patches in this series.
If needed, you can wait and I can send you a reminder when that happens.
Thanks.
FYI, I'll mark this as read for now, can you please resend one more
time when we can apply after Tero's patches. Otherwise I'll probably
mess up things and apply this by accident too soon..
Regards,
Tony
From ab81199d5b9c487c8493e6aa1d8b4bf17c0c5110 Mon Sep 17 00:00:00 2001
From: Roger Quadros rog...@ti.com
Date: Wed, 23 Oct 2013 12:58:59 +0300
Subject: [PATCH] ARM: OMAP2+: Get rid of legacy_init_ehci_clk()
The proper clock reference is provided in device tree so we
no longer need this.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/pdata-quirks.c | 25 -
1 file changed, 25 deletions(-)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index 10c7145..22537ed 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -26,20 +26,6 @@ struct pdata_init {
void (*fn)(void);
};
-/*
- * Create alias for USB host PHY clock.
- * Remove this when clock phandle can be provided via DT
- */
-static void __init __used legacy_init_ehci_clk(char *clkname)
-{
- int ret;
-
- ret = clk_add_alias(main_clk, NULL, clkname, NULL);
- if (ret)
- pr_err(%s:Failed to add main_clk alias to %s :%d\n,
-__func__, clkname, ret);
-}
-
#if IS_ENABLED(CONFIG_WL12XX)
static struct wl12xx_platform_data wl12xx __initdata;
@@ -105,18 +91,10 @@ static void __init omap4_sdp_legacy_init(void)
static void __init omap4_panda_legacy_init(void)
{
omap4_panda_display_init_of();
- legacy_init_ehci_clk(auxclk3_ck);
legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 53);
}
#endif
-#ifdef CONFIG_SOC_OMAP5
-static void __init omap5_uevm_legacy_init(void)
-{
- legacy_init_ehci_clk(auxclk1_ck);
-}
-#endif
-
static struct pcs_pdata pcs_pdata;
void omap_pcs_legacy_init(int irq, void (*rearm)(void))
@@ -149,9 +127,6 @@ static struct pdata_init pdata_quirks[] __initdata = {
{ ti,omap4-sdp, omap4_sdp_legacy_init, },
{ ti,omap4-panda, omap4_panda_legacy_init, },
#endif
-#ifdef CONFIG_SOC_OMAP5
- { ti,omap5-uevm, omap5_uevm_legacy_init, },
-#endif
{ /* sentinel */ },
};
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/4] ARM: AM43xx: fix dpll init in bypass mode
On Tue, 3 Dec 2013, Sathya Prakash M R wrote: From: Tomi Valkeinen tomi.valkei...@ti.com On AM43xx, if a PLL is in bypass at kernel init, the code in omap2_get_dpll_rate() will not realize this and will try to calculate the clock rate using the multiplier and the divider, resulting in errors. omap2_init_dpll_parent() has similar issue. Add the missing soc_is_am43xx() check to make the code work on AM43xx. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Did you intend to add your Signed-off-by: here, as is the upstream practice when you're part of the patch submission path? Please let me know ASAP so I can queue this for the -rc series. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap 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/3] ARM: OMAP4+: hwmod data: Don't prevent RESET of USB Host module
Hi Benoît,
On Tue, 3 Dec 2013, Roger Quadros wrote:
Without this, the USB devices are sometimes not detected on OMAP4 Panda
with u-boot v2013.10.
Unlike what the comment states, errata i660 does not state that we
can't RESET the USB host module. Instead it states that RESET is the
only way to recover from a deadlock situation.
RESET ensures that the module is in a known good state irrespective
of what bootloader does with the module, so it must be done at boot.
Reported-by: Tomi Valkeinen tomi.valkei...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Paul Walmsley p...@pwsan.com
Will you pick this up for the -rc series, or do you want me or Tony to?
Roger writes that this one's pretty important.
- Paul
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 12 ++--
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 13 +++--
2 files changed, 5 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 1e5b12c..3318cae9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2937,7 +2937,7 @@ static struct omap_hwmod_class_sysconfig
omap44xx_usb_host_hs_sysc = {
.sysc_offs = 0x0010,
.syss_offs = 0x0014,
.sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE |
-SYSC_HAS_SOFTRESET),
+SYSC_HAS_SOFTRESET | SYSC_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
@@ -3001,15 +3001,7 @@ static struct omap_hwmod omap44xx_usb_host_hs_hwmod = {
* hence HWMOD_SWSUP_MSTANDBY
*/
- /*
- * During system boot; If the hwmod framework resets the module
- * the module will have smart idle settings; which can lead to deadlock
- * (above Errata Id:i660); so, dont reset the module during boot;
- * Use HWMOD_INIT_NO_RESET.
- */
-
- .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
- HWMOD_INIT_NO_RESET,
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
};
/*
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index 9e08d69..e297d62 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -1544,7 +1544,8 @@ static struct omap_hwmod_class_sysconfig
omap54xx_usb_host_hs_sysc = {
.rev_offs = 0x,
.sysc_offs = 0x0010,
.sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_RESET_STATUS |
-SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
+SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+SYSC_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
@@ -1598,15 +1599,7 @@ static struct omap_hwmod omap54xx_usb_host_hs_hwmod = {
* hence HWMOD_SWSUP_MSTANDBY
*/
- /*
- * During system boot; If the hwmod framework resets the module
- * the module will have smart idle settings; which can lead to deadlock
- * (above Errata Id:i660); so, dont reset the module during boot;
- * Use HWMOD_INIT_NO_RESET.
- */
-
- .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
- HWMOD_INIT_NO_RESET,
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
.main_clk = l3init_60m_fclk,
.prcm = {
.omap4 = {
--
1.8.3.2
- Paul
Re: [PATCH 2/3] ARM: OMAP2+: hwmod: Fix RESET logic
Hi Roger,
On Tue, 3 Dec 2013, Roger Quadros wrote:
In _ocp_softreset(), after _set_softreset() + write_sysconfig(),
the hwmod's sysc_cache will always contain SOFTRESET bit set
so all further writes to sysconfig using this cache will initiate
a repeated SOFTRESET e.g. enable_sysc(). This is true for OMAP3 like
platforms that have RESET_DONE status in the SYSSTATUS register and
so the the SOFTRESET bit in SYSCONFIG is not automatically cleared.
It is not a problem for OMAP4 like platforms that indicate RESET
completion by clearing the SOFTRESET bit in the SYSCONFIG register.
This repeated SOFTRESET is undesired and was the root cause of
USB host issues on OMAP3 platforms when hwmod was allowed to do the
SOFTRESET for the USB Host module.
Doh :-(
Nice catch. Renamed _clr_softreset() to _clear_softreset() and queued
the following for v3.13-rc.
- Paul
From: Roger Quadros rog...@ti.com
ARM: OMAP2+: hwmod: Fix SOFTRESET logic
In _ocp_softreset(), after _set_softreset() + write_sysconfig(),
the hwmod's sysc_cache will always contain SOFTRESET bit set
so all further writes to sysconfig using this cache will initiate
a repeated SOFTRESET e.g. enable_sysc(). This is true for OMAP3 like
platforms that have RESET_DONE status in the SYSSTATUS register and
so the the SOFTRESET bit in SYSCONFIG is not automatically cleared.
It is not a problem for OMAP4 like platforms that indicate RESET
completion by clearing the SOFTRESET bit in the SYSCONFIG register.
This repeated SOFTRESET is undesired and was the root cause of
USB host issues on OMAP3 platforms when hwmod was allowed to do the
SOFTRESET for the USB Host module.
To fix this we clear the SOFTRESET bit and update the sysconfig
register + sysc_cache using write_sysconfig().
Signed-off-by: Roger Quadros rog...@ti.com
[p...@pwsan.com: renamed _clr_softreset() to _clear_softreset()]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod.c | 43 +++-
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index e3f0ecaf87dd..cacc0c7e8634 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -399,7 +399,7 @@ static int _set_clockactivity(struct omap_hwmod *oh, u8
clockact, u32 *v)
}
/**
- * _set_softreset: set OCP_SYSCONFIG.CLOCKACTIVITY bits in @v
+ * _set_softreset: set OCP_SYSCONFIG.SOFTRESET bit in @v
* @oh: struct omap_hwmod *
* @v: pointer to register contents to modify
*
@@ -427,6 +427,36 @@ static int _set_softreset(struct omap_hwmod *oh, u32 *v)
}
/**
+ * _clear_softreset: clear OCP_SYSCONFIG.SOFTRESET bit in @v
+ * @oh: struct omap_hwmod *
+ * @v: pointer to register contents to modify
+ *
+ * Clear the SOFTRESET bit in @v for hwmod @oh. Returns -EINVAL upon
+ * error or 0 upon success.
+ */
+static int _clear_softreset(struct omap_hwmod *oh, u32 *v)
+{
+ u32 softrst_mask;
+
+ if (!oh-class-sysc ||
+ !(oh-class-sysc-sysc_flags SYSC_HAS_SOFTRESET))
+ return -EINVAL;
+
+ if (!oh-class-sysc-sysc_fields) {
+ WARN(1,
+omap_hwmod: %s: sysc_fields absent for sysconfig class\n,
+oh-name);
+ return -EINVAL;
+ }
+
+ softrst_mask = (0x1 oh-class-sysc-sysc_fields-srst_shift);
+
+ *v = ~softrst_mask;
+
+ return 0;
+}
+
+/**
* _wait_softreset_complete - wait for an OCP softreset to complete
* @oh: struct omap_hwmod * to wait on
*
@@ -1911,6 +1941,12 @@ static int _ocp_softreset(struct omap_hwmod *oh)
ret = _set_softreset(oh, v);
if (ret)
goto dis_opt_clks;
+
+ _write_sysconfig(v, oh);
+ ret = _clear_softreset(oh, v);
+ if (ret)
+ goto dis_opt_clks;
+
_write_sysconfig(v, oh);
if (oh-class-sysc-srst_udelay)
@@ -3169,6 +3205,11 @@ int omap_hwmod_softreset(struct omap_hwmod *oh)
goto error;
_write_sysconfig(v, oh);
+ ret = _clear_softreset(oh, v);
+ if (ret)
+ goto error;
+ _write_sysconfig(v, oh);
+
error:
return ret;
}
--
1.8.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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] ARM: OMAP3: hwmod data: Don't prevent RESET of USB Host module
On Tue, 3 Dec 2013, Roger Quadros wrote: Unlike what the comment states, errata i660 does not state that we can't RESET the USB host module. Instead it states that RESET is the only way to recover from a deadlock situation. RESET ensures that the module is in a known good state irrespective of what bootloader does with the module, so it must be done at boot. Signed-off-by: Roger Quadros rog...@ti.com Thanks, queued for v3.13-rc. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap 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 0/3] ARM: OMAP2+: USB Host bug fixes for 3.13 rc
On Wed, 4 Dec 2013, Tomi Valkeinen wrote: Tested on Panda and Beagle xM. Works fine for me. Thanks, added your Tested-by's to both patches that I've queued. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: hwmod: Fix usage of invalid iclk / oclk when clock node is not present
Hi Nishanth, On Mon, 2 Dec 2013, Nishanth Menon wrote: commit dc75925d(OMAP: hwmod: Fix the missing braces) introduced missing braces, however, we just set return result if clk_get fail and we populate the error pointer in clk pointer and pass it along to clk_prepare. This is wrong. The intent seems to be retry remaining clocks if they are available and warn the ones we cant find clks for. With the current logic, we see the following crash: omap_hwmod: l3_main: cannot clk_get interface_clk emac_ick Unable to handle kernel NULL pointer dereference at virtual address 0032 pgd = c0004000 [0032] *pgd= Internal error: Oops: 5 [#1] SMP ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-00044-gcc9fd5a-dirty #19 task: ce0c3440 ti: ce0c4000 task.ti: ce0c4000 PC is at __clk_prepare+0x10/0x74 LR is at clk_prepare+0x14/0x24 snip [c044d59c] (__clk_prepare+0x10/0x74) from [c044d9b0] (clk_prepare+0x14/0x24) [c044d9b0] (clk_prepare+0x14/0x24) from [c077d8c4] (_init+0x24c/0x3bc) [c077d8c4] (_init+0x24c/0x3bc) from [c0027328] (omap_hwmod_for_each+0x34/0x5c) [c0027328] (omap_hwmod_for_each+0x34/0x5c) from [c077dfa0] (__omap_hwmod_setup_all+0x24/0x40) [c077dfa0] (__omap_hwmod_setup_all+0x24/0x40) from [c0008928] (do_one_initcall+0x38/0x168) [c0008928] (do_one_initcall+0x38/0x168) from [c0771be8] (kernel_init_freeable+0xfc/0x1cc) [c0771be8] (kernel_init_freeable+0xfc/0x1cc) from [c0521064] (kernel_init+0x8/0x110) [c0521064] (kernel_init+0x8/0x110) from [c000e568] (ret_from_fork+0x14/0x2c) Code: e92d4038 e2504000 01a05004 0a05 (e5943034) So, just warn and continue instead of proceeding and crashing, with missing clock nodes/bad data, we will eventually fail, however we should now have enough information to identify the culprit. Signed-off-by: Nishanth Menon n...@ti.com Thanks, queued for v3.13-rc. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap 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/3] ARM: OMAP4+: hwmod data: Don't prevent RESET of USB Host module
* Paul Walmsley p...@pwsan.com [131208 17:27]:
Hi Benoît,
On Tue, 3 Dec 2013, Roger Quadros wrote:
Without this, the USB devices are sometimes not detected on OMAP4 Panda
with u-boot v2013.10.
Unlike what the comment states, errata i660 does not state that we
can't RESET the USB host module. Instead it states that RESET is the
only way to recover from a deadlock situation.
RESET ensures that the module is in a known good state irrespective
of what bootloader does with the module, so it must be done at boot.
Reported-by: Tomi Valkeinen tomi.valkei...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Paul Walmsley p...@pwsan.com
Will you pick this up for the -rc series, or do you want me or Tony to?
Roger writes that this one's pretty important.
I suggest that you just queue this with your other fixes so we get
things working.
Regards,
Tony
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 12 ++--
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 13 +++--
2 files changed, 5 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 1e5b12c..3318cae9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2937,7 +2937,7 @@ static struct omap_hwmod_class_sysconfig
omap44xx_usb_host_hs_sysc = {
.sysc_offs = 0x0010,
.syss_offs = 0x0014,
.sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE |
- SYSC_HAS_SOFTRESET),
+ SYSC_HAS_SOFTRESET | SYSC_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
@@ -3001,15 +3001,7 @@ static struct omap_hwmod omap44xx_usb_host_hs_hwmod
= {
* hence HWMOD_SWSUP_MSTANDBY
*/
- /*
-* During system boot; If the hwmod framework resets the module
-* the module will have smart idle settings; which can lead to deadlock
-* (above Errata Id:i660); so, dont reset the module during boot;
-* Use HWMOD_INIT_NO_RESET.
-*/
-
- .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
- HWMOD_INIT_NO_RESET,
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
};
/*
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index 9e08d69..e297d62 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -1544,7 +1544,8 @@ static struct omap_hwmod_class_sysconfig
omap54xx_usb_host_hs_sysc = {
.rev_offs = 0x,
.sysc_offs = 0x0010,
.sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_RESET_STATUS |
- SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
@@ -1598,15 +1599,7 @@ static struct omap_hwmod omap54xx_usb_host_hs_hwmod
= {
* hence HWMOD_SWSUP_MSTANDBY
*/
- /*
-* During system boot; If the hwmod framework resets the module
-* the module will have smart idle settings; which can lead to deadlock
-* (above Errata Id:i660); so, dont reset the module during boot;
-* Use HWMOD_INIT_NO_RESET.
-*/
-
- .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
- HWMOD_INIT_NO_RESET,
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
.main_clk = l3init_60m_fclk,
.prcm = {
.omap4 = {
--
1.8.3.2
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/3] ARM: OMAP4+: hwmod data: Don't prevent RESET of USB Host module
On Sun, 8 Dec 2013, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [131208 17:27]: On Tue, 3 Dec 2013, Roger Quadros wrote: Without this, the USB devices are sometimes not detected on OMAP4 Panda with u-boot v2013.10. Unlike what the comment states, errata i660 does not state that we can't RESET the USB host module. Instead it states that RESET is the only way to recover from a deadlock situation. RESET ensures that the module is in a known good state irrespective of what bootloader does with the module, so it must be done at boot. Reported-by: Tomi Valkeinen tomi.valkei...@ti.com Signed-off-by: Roger Quadros rog...@ti.com Acked-by: Paul Walmsley p...@pwsan.com Will you pick this up for the -rc series, or do you want me or Tony to? Roger writes that this one's pretty important. I suggest that you just queue this with your other fixes so we get things working. I'm going to wait until tomorrow anyway to see if Sathya responds to my other E-mail, so maybe Benoît will let us know by then. - Paul
RE: OMAP3 NAND ECC selection
Hi, From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com] On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote: [...] Using 1-bit ECC on NAND is not a long-term solution. Given that fact, I think your ROM code is what may need to change, not the entire MTD subsystem. As someone (Tom Rini maybe?) pointed out, today the shift is 1-bit ECC supported by ROM code vs. 4 or 8 bits required by NAND. But we can very well imagine that tomorrow ROM code will support BCH4 (and the NAND will ensure block 0 is OK for use with BCH4) but the rest of the NAND will require BCH16 or something like that. I'm not designing ROM code, and the fact that they today have this limitation, should be an indication that Linux should be capable of handling different ECC schemes to handle those hardware constraints. Just to highlight few more points: (1) ROM code on newer OMAP platforms like AM33xx do have the ability to select ECC scheme by reading a specific location from EEPROM connected to I2C0. Reference: http://www.ti.com/product/am3359 http://www.ti.com/litv/pdf/spruh73i Chapter 26: Initialization Section: 26.1.7.4 Memory Booting NAND Table 26-17. NAND Geometry Information on I2C EEPROM (2) And going forward, ECC based NAND devices may be phased out, and BE-NAND (Built-in) NAND devices are becoming popular. As both cost and density wise they are same to SLC NANDs today. Thus issue of un-compatibility of ecc-scheme with ROM code, will not hold true. We already have some BE-NAND support in our generic driver. http://patchwork.ozlabs.org/patch/222186/ However, I also support user space tool approach rather than having this included in NAND driver. with regards, pekon -- To unsubscribe from this list: send the line unsubscribe linux-omap 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 2/2] arm: omap: remove *.auto* from device names given in usb_bind_phy
Hi, On Saturday 07 December 2013 02:38 AM, Felipe Balbi wrote: Hi, On Fri, Dec 06, 2013 at 01:14:38PM +0100, Javier Martinez Canillas wrote: On Fri, Dec 6, 2013 at 1:06 PM, Kishon Vijay Abraham I kis...@ti.com wrote: Previously MUSB wrapper (OMAP) device used PLATFORM_DEVID_AUTO while creating MUSB core device. So in usb_bind_phy (binds the controller with the PHY), the device name of the controller had *.auto* in it. Since with using PLATFORM_DEVID_AUTO, there is no way to know the exact device name in advance, the data given in usb_bind_phy became obsolete and usb_get_phy was failing. So MUSB wrapper was modified not to use PLATFORM_DEVID_AUTO. Corresponding change is done in board file here. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- arch/arm/mach-omap2/board-2430sdp.c|2 +- arch/arm/mach-omap2/board-3430sdp.c|2 +- arch/arm/mach-omap2/board-cm-t35.c |2 +- arch/arm/mach-omap2/board-devkit8000.c |2 +- arch/arm/mach-omap2/board-ldp.c|2 +- arch/arm/mach-omap2/board-omap3beagle.c|2 +- arch/arm/mach-omap2/board-omap3logic.c |2 +- arch/arm/mach-omap2/board-omap3pandora.c |2 +- arch/arm/mach-omap2/board-omap3stalker.c |2 +- arch/arm/mach-omap2/board-omap3touchbook.c |2 +- arch/arm/mach-omap2/board-overo.c |2 +- arch/arm/mach-omap2/board-rx51.c |2 +- 12 files changed, 12 insertions(+), 12 deletions(-) You can drop this patch since boards files are being removed for v3.14 if we can drop this patch, the whole series is invalid, since we'll be using DT phandles to find PHYs going forward, no ? yeah. But in one of the other threads, Tony seemed ok to take a patch that fixes the same issue in mach-omap2/twl-common.c. So it's better to confirm with Tony. Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-omap 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 04/10] usb: dwc3: use quirks to know if a particualr platform doesn't have PHY
Hi, On Thursday 05 December 2013 01:28 PM, Heikki Krogerus wrote: Hi, On Thu, Dec 05, 2013 at 12:04:46PM +0530, Kishon Vijay Abraham I wrote: On Wednesday 04 December 2013 08:10 PM, Heikki Krogerus wrote: On Mon, Nov 25, 2013 at 03:31:24PM +0530, Kishon Vijay Abraham I wrote: There can be systems which does not have an external phy, so get phy only if no quirks are added that indicates the PHY is not present. Introduced two quirk flags to indicate the *absence* of usb2 phy and usb3 phy. Also remove checking if return value is -ENXIO since it's now changed to always enable usb_phy layer. Can you guys explain why is something like this needed? Like with clocks and gpios, the device drivers shouldn't need to care any more if the platform has the phys or not. -ENODEV tells you your platform Shouldn't we report if a particular platform needs a PHY and not able to get it. How will a user know if a particular controller is not working because it's not able to get and initialize the PHYs? Don't you think in such cases it's better to fail (and return from probe) because the controller will not work anyway without the PHY? My point is that you do not need to separately tell this to the driver like you do with the quirks (if you did, then you would need to fix your framework and not hack the drivers). Like I said, ENODEV tells you that there is no phy on this platform for you, allowing you to safely continue. If your phy driver is not loaded, the framework already returns EPROBE_DEFER, right. Any other right. but that doesn't consider broken dt data. With quirks we'll able to tell if a controller in a particular platform has PHY or not without depending on the dt data. error when getting the phy you can consider critical. They are the errors telling you that you do need a phy on this platform, but something actually went wrong when getting it. Not on all scenarios though :-s Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: twl-common: Fix musb-hdrc device name.
Hi Tony, On Thu, Dec 5, 2013 at 7:43 PM, Tony Lindgren t...@atomide.com wrote: * Belisko Marek marek.beli...@gmail.com [131203 01:21]: On Tue, Dec 3, 2013 at 10:08 AM, Belisko Marek marek.beli...@gmail.com wrote: Hi, On Tue, Dec 3, 2013 at 9:58 AM, Kishon Vijay Abraham I kis...@ti.com wrote: Hi, On Tuesday 03 December 2013 02:03 PM, Marek Belisko wrote: Without this change when booting omap3 device (gta04) with board file leads to follwing errors: [1.203308] musb-hdrc musb-hdrc.0.auto: unable to find phy [1.209075] HS USB OTG: no transceiver configured [1.214019] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 and usb isn't working. This is probably regression caused by commit: 6c27f939 I think a better fix would be to have this merged.. https://lkml.org/lkml/2013/7/26/91 Yes I see but how this could help with current situation? Ho you then specify device number? I was too fast with reply sorry. I can see whole series and it is of course correct solution. But as I said can we except to be merged to 3.13. If not Tony can you pick my patch. If it's a regression, then let's get it merged for the -rc cycle. Yes it is regression and without that usb on most omap3 based boards without DT will not work. So please try to follow up on getting the proper fix merged, meanwhile I'll mark this thread as read. If you need this one merged for some reason, then please report to get it back to my radar. Regards, Tony BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
