Re: [PATCH 1/3] pinctrl: bindings: Add OMAP pinctrl binding
On Mon, Aug 25, 2014 at 9:03 PM, Nishanth Menon n...@ti.com wrote: ---8--- From 74121c6a2524048eb02c3b33a25e13261edd2e99 Mon Sep 17 00:00:00 2001 From: Nishanth Menon n...@ti.com Date: Thu, 22 May 2014 23:32:09 -0500 Subject: [PATCH V2] pinctrl: bindings: Add OMAP pinctrl binding Add basic skeleton of OMAP pinctrl bindings. This is compatible with pinctrl,single bindings and is meant purely as a reference point. Acked-by: Tony Lindgren t...@atomide.com Signed-off-by: Nishanth Menon n...@ti.com Applied this inline v2 version. Yours, Linus Walleij -- 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] pinctrl: single: AM437x: Add pinctrl compatibility
On Fri, Aug 22, 2014 at 4:01 PM, Nishanth Menon n...@ti.com wrote: From: Keerthy j-keer...@ti.com AM437x pinctrl definitions now differ from traditional 16 bit OMAP pin ctrl definitions, in that all 32 bits are used to describe a single pin Also the location of wakeupenable and event bits have changed. Signed-off-by: Keerthy j-keer...@ti.com [n...@ti.com: minor updates] Signed-off-by: Nishanth Menon n...@ti.com Patch applied with Tony's ACK. Yours, Linus Walleij -- 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/3] pinctrl: single: Add DRA7 pinctrl compatibility
On Fri, Aug 22, 2014 at 4:01 PM, Nishanth Menon n...@ti.com wrote: DRA7 pinctrl definitions now differ from traditional 16 bit OMAP pin ctrl definitions, in that all 32 bits are used to describe a single pin Also the location of wakeupenable and event bits have changed. Signed-off-by: Nishanth Menon n...@ti.com Patch applied with Tony's ACK. Yours, Linus Walleij -- 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
[PATCH 3/4 v2] arm: omap3: Add Technexion Thunder support (TAO3530 SOM based)
This baseboard is equipped with the Technexion TAO35030 SOM. So
includes this dtsi. Some Thunder specific features are:
- LCD panel
Signed-off-by: Stefan Roese s...@denx.de
Cc: Thorsten Eisbein thorsten.eisb...@head-acoustics.de
Cc: Tapani Utriainen tap...@technexion.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/omap3-thunder.dts | 129
2 files changed, 130 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3-thunder.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b8c5cd3..e00c889 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -309,6 +309,7 @@ dtb-$(CONFIG_ARCH_OMAP3) += am3517-craneboard.dtb \
omap3-sbc-t3517.dtb \
omap3-sbc-t3530.dtb \
omap3-sbc-t3730.dtb \
+ omap3-thunder.dtb \
omap3-zoom3.dtb
dtb-$(CONFIG_SOC_AM33XX) += am335x-base0033.dtb \
am335x-bone.dtb \
diff --git a/arch/arm/boot/dts/omap3-thunder.dts
b/arch/arm/boot/dts/omap3-thunder.dts
new file mode 100644
index 000..d659515
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-thunder.dts
@@ -0,0 +1,129 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2014 Stefan Roese s...@denx.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include omap3-tao3530.dtsi
+
+/ {
+ model = TI OMAP3 Thunder baseboard with TAO3530 SOM;
+ compatible = technexion,omap3-thunder, technexion,omap3-tao3530,
ti,omap34xx, ti,omap3;
+};
+
+omap3_pmx_core {
+ dss_dpi_pins: pinmux_dss_dpi_pins {
+ pinctrl-single,pins =
+ OMAP3_CORE1_IOPAD(0x20d4, PIN_OUTPUT | MUX_MODE0)
/* dss_pclk.dss_pclk */
+ OMAP3_CORE1_IOPAD(0x20d6, PIN_OUTPUT | MUX_MODE0)
/* dss_hsync.dss_hsync */
+ OMAP3_CORE1_IOPAD(0x20d8, PIN_OUTPUT | MUX_MODE0)
/* dss_vsync.dss_vsync */
+ OMAP3_CORE1_IOPAD(0x20da, PIN_OUTPUT | MUX_MODE0)
/* dss_acbias.dss_acbias */
+ OMAP3_CORE1_IOPAD(0x20dc, PIN_OUTPUT | MUX_MODE0)
/* dss_data0.dss_data0 */
+ OMAP3_CORE1_IOPAD(0x20de, PIN_OUTPUT | MUX_MODE0)
/* dss_data1.dss_data1 */
+ OMAP3_CORE1_IOPAD(0x20e0, PIN_OUTPUT | MUX_MODE0)
/* dss_data2.dss_data2 */
+ OMAP3_CORE1_IOPAD(0x20e2, PIN_OUTPUT | MUX_MODE0)
/* dss_data3.dss_data3 */
+ OMAP3_CORE1_IOPAD(0x20e4, PIN_OUTPUT | MUX_MODE0)
/* dss_data4.dss_data4 */
+ OMAP3_CORE1_IOPAD(0x20e6, PIN_OUTPUT | MUX_MODE0)
/* dss_data5.dss_data5 */
+ OMAP3_CORE1_IOPAD(0x20e8, PIN_OUTPUT | MUX_MODE0)
/* dss_data6.dss_data6 */
+ OMAP3_CORE1_IOPAD(0x20ea, PIN_OUTPUT | MUX_MODE0)
/* dss_data7.dss_data7 */
+ OMAP3_CORE1_IOPAD(0x20ec, PIN_OUTPUT | MUX_MODE0)
/* dss_data8.dss_data8 */
+ OMAP3_CORE1_IOPAD(0x20ee, PIN_OUTPUT | MUX_MODE0)
/* dss_data9.dss_data9 */
+ OMAP3_CORE1_IOPAD(0x20f0, PIN_OUTPUT | MUX_MODE0)
/* dss_data10.dss_data10 */
+ OMAP3_CORE1_IOPAD(0x20f2, PIN_OUTPUT | MUX_MODE0)
/* dss_data11.dss_data11 */
+ OMAP3_CORE1_IOPAD(0x20f4, PIN_OUTPUT | MUX_MODE0)
/* dss_data12.dss_data12 */
+ OMAP3_CORE1_IOPAD(0x20f6, PIN_OUTPUT | MUX_MODE0)
/* dss_data13.dss_data13 */
+ OMAP3_CORE1_IOPAD(0x20f8, PIN_OUTPUT | MUX_MODE0)
/* dss_data14.dss_data14 */
+ OMAP3_CORE1_IOPAD(0x20fa, PIN_OUTPUT | MUX_MODE0)
/* dss_data15.dss_data15 */
+ OMAP3_CORE1_IOPAD(0x20fc, PIN_OUTPUT | MUX_MODE0)
/* dss_data16.dss_data16 */
+ OMAP3_CORE1_IOPAD(0x20fe, PIN_OUTPUT | MUX_MODE0)
/* dss_data17.dss_data17 */
+ OMAP3_CORE1_IOPAD(0x2100, PIN_OUTPUT | MUX_MODE0)
/* dss_data18.dss_data18 */
+ OMAP3_CORE1_IOPAD(0x2102, PIN_OUTPUT | MUX_MODE0)
/* dss_data19.dss_data19 */
+ OMAP3_CORE1_IOPAD(0x2104, PIN_OUTPUT | MUX_MODE0)
/* dss_data20.dss_data20 */
+ OMAP3_CORE1_IOPAD(0x2106, PIN_OUTPUT | MUX_MODE0)
/* dss_data21.dss_data21 */
+ OMAP3_CORE1_IOPAD(0x2108, PIN_OUTPUT | MUX_MODE0)
/* dss_data22.dss_data22 */
+ OMAP3_CORE1_IOPAD(0x210a, PIN_OUTPUT | MUX_MODE0)
/* dss_data23.dss_data23 */
+ ;
+ };
+
+ lte430_pins: pinmux_lte430_pins {
+ pinctrl-single,pins =
+
[PATCH 4/4 v2] arm: omap3: Add HEAD acoustics omap3-ha.dts and omap3-ha-lcd.dts (TAO3530 based)
These baseboards are equipped with the Technexion TAO35030 SOM. So
they include this dtsi. The common parts are extracted into an common
dtsi file. The main difference between both boards is, that the *lcd
has DSS support enabled for the LCD.
Some HEAD acoustics specific features are:
- LED handling
- Special FPGA/DSP audio driver (not included in this series)
- powerdown GPIO
Signed-off-by: Stefan Roese s...@denx.de
Cc: Thorsten Eisbein thorsten.eisb...@head-acoustics.de
Cc: Tapani Utriainen tap...@technexion.com
Cc: Tony Lindgren t...@atomide.com
---
v2:
- Used OMAP3_CORE1_IOPAD macros for all mux entries
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/omap3-ha-common.dtsi | 88 ++
arch/arm/boot/dts/omap3-ha-lcd.dts | 165 +
arch/arm/boot/dts/omap3-ha.dts | 28 ++
4 files changed, 283 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3-ha-common.dtsi
create mode 100644 arch/arm/boot/dts/omap3-ha-lcd.dts
create mode 100644 arch/arm/boot/dts/omap3-ha.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e00c889..892b7d2 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -287,6 +287,8 @@ dtb-$(CONFIG_ARCH_OMAP3) += am3517-craneboard.dtb \
omap3-evm.dtb \
omap3-evm-37xx.dtb \
omap3-gta04.dtb \
+ omap3-ha.dtb \
+ omap3-ha-lcd.dtb \
omap3-igep0020.dtb \
omap3-igep0030.dtb \
omap3-ldp.dtb \
diff --git a/arch/arm/boot/dts/omap3-ha-common.dtsi
b/arch/arm/boot/dts/omap3-ha-common.dtsi
new file mode 100644
index 000..bd66545
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-ha-common.dtsi
@@ -0,0 +1,88 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2014 Stefan Roese s...@denx.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include omap3-tao3530.dtsi
+
+/ {
+ gpio_poweroff {
+ pinctrl-names = default;
+ pinctrl-0 = poweroff_pins;
+
+ compatible = gpio-poweroff;
+ gpios = gpio6 8 GPIO_ACTIVE_LOW; /* GPIO 168 */
+ };
+};
+
+omap3_pmx_core {
+ sound2_pins: pinmux_sound2_pins {
+ pinctrl-single,pins =
+ OMAP3_CORE1_IOPAD(0x209e, PIN_OUTPUT | MUX_MODE4)
/* gpmc_d8 gpio_44 */
+ ;
+ };
+
+ led_blue_pins: pinmux_led_blue_pins {
+ pinctrl-single,pins =
+ OMAP3_CORE1_IOPAD(0x2110, PIN_OUTPUT | MUX_MODE4)
/* cam_xclka gpio_96, LED blue */
+ ;
+ };
+
+ led_green_pins: pinmux_led_green_pins {
+ pinctrl-single,pins =
+ OMAP3_CORE1_IOPAD(0x2126, PIN_OUTPUT | MUX_MODE4)
/* cam_d8 gpio_107, LED green */
+ ;
+ };
+
+ led_red_pins: pinmux_led_red_pins {
+ pinctrl-single,pins =
+ OMAP3_CORE1_IOPAD(0x212e, PIN_OUTPUT_PULLUP |
MUX_MODE4)/* cam_xclkb gpio_111, LED red */
+ ;
+ };
+
+ poweroff_pins: pinmux_poweroff_pins {
+ pinctrl-single,pins =
+ OMAP3_CORE1_IOPAD(0x21be, PIN_OUTPUT_PULLUP |
MUX_MODE4)/* i2c2_scl gpio_168 */
+ ;
+ };
+
+ powerdown_input_pins: pinmux_powerdown_input_pins {
+ pinctrl-single,pins =
+ OMAP3_CORE1_IOPAD(0x21c0, PIN_INPUT_PULLUP | MUX_MODE4)
/* i2c2_sda gpio_183 */
+ ;
+ };
+
+ fpga_boot0_pins: fpga_boot0_pins {
+ pinctrl-single,pins =
+ OMAP3_CORE1_IOPAD(0x211a, PIN_INPUT | MUX_MODE4)
/* cam_d2 gpio_101 */
+ OMAP3_CORE1_IOPAD(0x211c, PIN_OUTPUT | MUX_MODE4)
/* cam_d3 gpio_102 */
+ OMAP3_CORE1_IOPAD(0x211e, PIN_OUTPUT | MUX_MODE4)
/* cam_d4 gpio_103 */
+ OMAP3_CORE1_IOPAD(0x2120, PIN_INPUT_PULLUP | MUX_MODE4)
/* cam_d5 gpio_104 */
+ ;
+ };
+
+ fpga_boot1_pins: fpga_boot1_pins {
+ pinctrl-single,pins =
+ OMAP3_CORE1_IOPAD(0x20a2, PIN_INPUT | MUX_MODE4)
/* gpmc_d10 gpio_46 */
+ OMAP3_CORE1_IOPAD(0x20a4, PIN_OUTPUT | MUX_MODE4)
/* gpmc_d11 gpio_47 */
+ OMAP3_CORE1_IOPAD(0x20a6, PIN_OUTPUT | MUX_MODE4)
/* gpmc_d12 gpio_48 */
+ OMAP3_CORE1_IOPAD(0x20a8, PIN_INPUT_PULLUP | MUX_MODE4)
/* gpmc_d13 gpio_49 */
+ ;
+ };
+};
+
+/* I2C2: mux'ed with GPIO168 which is connected to nKILL_POWER */
+i2c2 {
+ status = disabled;
+};
+
+i2c3 {
+ clock-frequency = 10;
+
+ pinctrl-names = default;
+ pinctrl-0 =
Re: [PATCH] mfd: palmas: Add support for optional wakeup
On Tue, 19 Aug 2014, Nishanth Menon wrote:
With the recent pinctrl-single changes, omaps can treat wake-up events
from deeper idle states as interrupts.
Let's add support for the optional second interrupt for wake-up
events. And then SoC can wakeup and handle the event using it's
regular handler.
Finally, to pass the wake-up interrupt in the dts file,
interrupts-extended property needs to be passed.
This is similar in approach to commit 2a0b965cfb6e (serial: omap: Add
support for optional wake-up)
Signed-off-by: Nishanth Menon n...@ti.com
---
Documentation/devicetree/bindings/mfd/palmas.txt | 20
DT Ack please.
drivers/mfd/palmas.c | 59
++
include/linux/mfd/palmas.h |2 +
3 files changed, 81 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt
b/Documentation/devicetree/bindings/mfd/palmas.txt
index eda8989..2627842 100644
--- a/Documentation/devicetree/bindings/mfd/palmas.txt
+++ b/Documentation/devicetree/bindings/mfd/palmas.txt
@@ -51,3 +51,23 @@ palmas {
};
}
+
+Example: with interrupts extended
+ See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+ Use pinmux 0x418 as wakeup interrupt and gpio1_0 as interrupt source
+
+palmas {
Should this be 'palmas@40 {'?
+ compatible = ti,twl6035, ti,palmas;
+ reg = 0x48
+ interrupt-parent = intc;
+ interrupt-controller;
+ #interrupt-cells = 2;
+ #address-cells = 1;
+ #size-cells = 0;
+ interrupts-extended = gpio1 0 IRQ_TYPE_LEVEL_HIGH
+pinmux 0x418;
Can I get a DT Ack, that this is being used correctly? It doesn't
match the syntax given in:
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+ pmic {
+ compatible = ti,twl6035-pmic, ti,palmas-pmic;
+
+ };
+}
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index 28cb048..11186ab 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -24,6 +24,7 @@
#include linux/mfd/core.h
#include linux/mfd/palmas.h
#include linux/of_device.h
+#include linux/of_irq.h
static const struct regmap_config palmas_regmap_config[PALMAS_NUM_CLIENTS] =
{
{
@@ -326,6 +327,16 @@ static struct regmap_irq_chip tps65917_irq_chip = {
PALMAS_INT1_MASK),
};
+static irqreturn_t palmas_wake_irq(int irq, void *_palmas)
+{
+ /*
+ * Return Not handled so that interrupt is disabled.
+ * Level event ensures that the event is eventually handled
+ * by the appropriate chip handler already registered
+ */
This looks okay to me, but could do with a second opinion from someone
who is a little more familier with this kind of h/w.
How does this differ from threading IRQs?
+ return IRQ_NONE;
+}
+
int palmas_ext_control_req_config(struct palmas *palmas,
enum palmas_external_requestor_id id, int ext_ctrl, bool enable)
{
@@ -409,6 +420,7 @@ static void palmas_dt_to_pdata(struct i2c_client *i2c,
pdata-mux_from_pdata = 1;
pdata-pad2 = prop;
}
+ pdata-wakeirq = irq_of_parse_and_map(node, 1);
/* The default for this register is all masked */
ret = of_property_read_u32(node, ti,power-ctrl, prop);
@@ -521,6 +533,7 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
i2c_set_clientdata(i2c, palmas);
palmas-dev = i2c-dev;
palmas-irq = i2c-irq;
+ palmas-wakeirq = pdata-wakeirq;
match = of_match_device(of_palmas_match_tbl, i2c-dev);
@@ -587,6 +600,22 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
if (ret 0)
goto err_i2c;
+ if (!palmas-wakeirq)
+ goto no_wake_irq;
+
+ ret = devm_request_irq(palmas-dev, palmas-wakeirq,
+palmas_wake_irq,
+IRQF_ONESHOT | pdata-irq_flags,
+dev_name(palmas-dev),
+palmas);
+ if (ret 0)
+ goto err_i2c;
+
+ /* We use wakeirq only during suspend-resume path */
+ device_set_wakeup_capable(palmas-dev, true);
+ disable_irq_nosync(palmas-wakeirq);
+
+no_wake_irq:
no_irq:
slave = PALMAS_BASE_TO_SLAVE(PALMAS_PU_PD_OD_BASE);
addr = PALMAS_BASE_TO_REG(PALMAS_PU_PD_OD_BASE,
@@ -706,6 +735,34 @@ static int palmas_i2c_remove(struct i2c_client *i2c)
return 0;
}
+static int palmas_i2c_suspend(struct i2c_client *i2c, pm_message_t mesg)
+{
+ struct palmas *palmas = i2c_get_clientdata(i2c);
+ struct device *dev = i2c-dev;
+
+ if (!palmas-wakeirq)
+ return 0;
+
+ if (device_may_wakeup(dev))
+ enable_irq(palmas-wakeirq);
+
+ return 0;
+}
+
+static int palmas_i2c_resume(struct i2c_client *i2c)
+{
+ struct
Re: [PATCH v4 00/15] Rework OMAP4+ HDMI audio support
After discussing with Tomi we decided to turn the omap-hdmi-audio ASoC library into a platform device. So do not waste too much time in reviewing these patches. I'll mail a new series soon. Best regards, Jyri On 08/25/2014 10:04 PM, Jyri Sarha wrote: The patches are based on: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git for-next The base, the patches, and couple of additional not-to-be-merged omap2plus_defconfig patches can be found here: git://git.ti.com/~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree.git omap-hdmi-audio Changes since v3: - Move ASoC parts into library module under sound/soc/omap - Come up with API for the library - Some cleaning up The patch set fixes OMAP4+ HDMI audio. The structure of the implementation looks a bit different than before. Instead of creating a driver specific API for a separate ASoC component driver to connect to, these patches implement a single audio library module under sound/soc/omap for ASoC side implementation. The library exports omap_hdmi_audio_register() and omap_hdmi_audio_unregister() functions. With the functions OMAPDSS HDMI implementation registers and unregisters all ASoC components needed for OMAP HDMI audio. The library implements cpu-dai component using the callbacks provided by OMAPDSS. Omap-pcm is registered for platform component, dummy hdmi-audio-codec is registered for codec component, and asoc-simple-card is registered for machine driver. Big part of the HDMI audio code is still unchanged and there is a need for a cleanup there. Also there is still probably something wrong with speaker mapping of multi-channel streams. I will get back to cleaning up these issues later. Best regards, Jyri Jyri Sarha (15): OMAPDSS: hdmi.h: Add HDMI_AUDIO_LAYOUT_6CH enum value OMAPDSS: hdmi: Remove most of OMAP[45]_DSS_HDMI_AUDIO ifdefs OMAPDSS: hdmi4_core: Remove unused hdmi4_audio_get_dma_port() OMAPDSS: hdmi_wp: Add function for getting audio dma address OMAPDSS: hdmi: Make hdmi structure public OMAPDSS: hdmi: Add exported functions for storing HDMI audio data OMAPDSS: hdmi: Make hdmi_mode_has_audio() more user friedly ASoC: omap-hdmi-audio: Add OMAP HDMI audio support library OMAPDSS: Kconfig: Implement options for OMAP4 and OMAP5 HDMI audio support OMAPDSS: hdmi4: Register HDMI audio with omap_hdmi_audio_register() OMAPDSS: hdmi5: Register HDMI audio with omap_hdmi_audio_register() ASoC: omap: Remove obsolete HDMI audio code and Kconfig options OMAPDSS: hdmi4: Remove callbacks for an external ASoC DAI driver OMAPDSS: hdmi5: Remove callbacks for an external ASoC DAI driver OMAPDSS: Remove all references to obsolete HDMI audio callbacks .../fbdev/omap2/displays-new/connector-hdmi.c | 99 -- .../fbdev/omap2/displays-new/encoder-tpd12s015.c | 56 --- drivers/video/fbdev/omap2/dss/Kconfig | 28 +- drivers/video/fbdev/omap2/dss/hdmi.h | 35 +- drivers/video/fbdev/omap2/dss/hdmi4.c | 233 ++--- drivers/video/fbdev/omap2/dss/hdmi4_core.c | 14 - drivers/video/fbdev/omap2/dss/hdmi4_core.h |4 - drivers/video/fbdev/omap2/dss/hdmi5.c | 216 +--- drivers/video/fbdev/omap2/dss/hdmi5_core.c |6 - drivers/video/fbdev/omap2/dss/hdmi5_core.h |2 - drivers/video/fbdev/omap2/dss/hdmi_common.c| 18 +- drivers/video/fbdev/omap2/dss/hdmi_wp.c|8 +- include/sound/omap-hdmi-audio.h| 50 +++ include/video/omapdss.h| 34 +- sound/soc/omap/Kconfig | 15 +- sound/soc/omap/Makefile|6 +- sound/soc/omap/omap-hdmi-audio.c | 357 +++ sound/soc/omap/omap-hdmi-card.c| 87 - sound/soc/omap/omap-hdmi.c | 364 sound/soc/omap/omap-hdmi.h | 38 -- 20 files changed, 676 insertions(+), 994 deletions(-) create mode 100644 include/sound/omap-hdmi-audio.h create mode 100644 sound/soc/omap/omap-hdmi-audio.c delete mode 100644 sound/soc/omap/omap-hdmi-card.c delete mode 100644 sound/soc/omap/omap-hdmi.c delete mode 100644 sound/soc/omap/omap-hdmi.h -- 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] mfd: palmas: Add support for optional wakeup
On 08/29/2014 05:56 AM, Lee Jones wrote:
On Tue, 19 Aug 2014, Nishanth Menon wrote:
With the recent pinctrl-single changes, omaps can treat wake-up events
from deeper idle states as interrupts.
Let's add support for the optional second interrupt for wake-up
events. And then SoC can wakeup and handle the event using it's
regular handler.
Finally, to pass the wake-up interrupt in the dts file,
interrupts-extended property needs to be passed.
This is similar in approach to commit 2a0b965cfb6e (serial: omap: Add
support for optional wake-up)
Signed-off-by: Nishanth Menon n...@ti.com
---
Documentation/devicetree/bindings/mfd/palmas.txt | 20
DT Ack please.
drivers/mfd/palmas.c | 59
++
include/linux/mfd/palmas.h |2 +
3 files changed, 81 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt
b/Documentation/devicetree/bindings/mfd/palmas.txt
index eda8989..2627842 100644
--- a/Documentation/devicetree/bindings/mfd/palmas.txt
+++ b/Documentation/devicetree/bindings/mfd/palmas.txt
@@ -51,3 +51,23 @@ palmas {
};
}
+
+Example: with interrupts extended
+ See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+ Use pinmux 0x418 as wakeup interrupt and gpio1_0 as interrupt source
+
+palmas {
Should this be 'palmas@40 {'?
I might have preferred that as well.. I kept the existing style in the
documentation. Would you like me to change existing doc style too?
+compatible = ti,twl6035, ti,palmas;
+reg = 0x48
+interrupt-parent = intc;
+interrupt-controller;
+#interrupt-cells = 2;
+#address-cells = 1;
+#size-cells = 0;
+interrupts-extended = gpio1 0 IRQ_TYPE_LEVEL_HIGH
+ pinmux 0x418;
Can I get a DT Ack, that this is being used correctly? It doesn't
match the syntax given in:
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
Did you mean:
gpio1 0 IRQ_TYPE_LEVEL_HIGH, pinmux 0x418;
Yes, I can fix that - sorry, both usage seem to be functional.
+pmic {
+compatible = ti,twl6035-pmic, ti,palmas-pmic;
+
+};
+}
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index 28cb048..11186ab 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -24,6 +24,7 @@
#include linux/mfd/core.h
#include linux/mfd/palmas.h
#include linux/of_device.h
+#include linux/of_irq.h
static const struct regmap_config palmas_regmap_config[PALMAS_NUM_CLIENTS]
= {
{
@@ -326,6 +327,16 @@ static struct regmap_irq_chip tps65917_irq_chip = {
PALMAS_INT1_MASK),
};
+static irqreturn_t palmas_wake_irq(int irq, void *_palmas)
+{
+/*
+ * Return Not handled so that interrupt is disabled.
+ * Level event ensures that the event is eventually handled
+ * by the appropriate chip handler already registered
+ */
This looks okay to me, but could do with a second opinion from someone
who is a little more familier with this kind of h/w.
How does this differ from threading IRQs?
I could try with an example:
consider a GPIO block 7 gpio 4 connected to a pinctrl pin 234 as the
interrupt source for palmas.
When the system is active, the GPIO block 7, gpio 4 happily functions
as the interrupt source. However, the SoC might not capable of
achieving SoC wide deepsleep when GPIO block 7 is active, So we have
to power off GPIO block 7. However on achieving low power, the system
needs to be capable of waking backup, for this, SoC uses the hardware
at the pin itself(TI calls it control module, others have other names,
lets for the discussion, call it pinctrl), on going to sleep the
action of enabling the pinctrl irq - enables the wakeup capability of
the pin, and disabling it disabled the wakeup capability. when the
wakeup event does take place, in some cases, it might be a edge event,
where by the time we have recofigured GPIO block, the interrupt event
is long gone - to support this, pinctrl invokes the driver interrupt
handler to ensure this functions. in our case(palmas), we are level
event and can depend on GPIO block to handle it when it is configured.
Basically two interrupt sources when SoC is in deep sleep(1 to exit
from deepsleep, and other from the module handling the actual event) -
Example: powerbutton press OR palmas RTC wakeup OR Palmas GPIO
generated wakeup.
However, this is not the same as threading IRQ as the wakeup event is
involved only during suspend path.
commit 2a0b965cfb6e (serial: omap: Add support for optional wake-up)
is a good reference from serial port handling perspective.
--
Regards,
Nishanth Menon
--
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 05/15] tty: serial: Add 8250-core based omap driver
On 08/16/2014 12:44 AM, Tony Lindgren wrote: Oh and echo mem /sys/power/state and then hitting a key on the serial console won't wake the system. Does that need to be manually configured for device_may_wakeup()? This is what it looks like: /# echo enabled /sys/devices/6800.ocp/4902.serial/tty/ttyS2/power/wakeup / # date; echo mem /sys/power/state; date Sat Jan 1 07:01:41 UTC 2000 [ 249.916503] PM: Syncing filesystems ... done. [ 252.674652] Freezing user space processes ... (elapsed 0.001 seconds) done. [ 252.683563] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 252.693084] Suspending console(s) (use no_console_suspend to debug) [ 252.715820] PM: suspend of devices complete after 11.688 msecs [ 252.722015] PM: late suspend of devices complete after 6.195 msecs [ 252.729187] PM: noirq suspend of devices complete after 7.110 msecs [ 252.729278] Successfully put all powerdomains to target state [ 252.733306] PM: noirq resume of devices complete after 3.967 msecs [ 252.738708] PM: early resume of devices complete after 4.425 msecs [ 252.910400] PM: resume of devices complete after 171.569 msecs [ 252.957855] Restarting tasks ... done. Sat Jan 1 07:01:51 UTC 2000 Sebastian -- 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 07/15] tty: serial: 8250_dma: enqueue RX dma again on completion.
On 08/18/2014 12:52 PM, One Thousand Gnomes wrote: if (!up-dma || dma_err) status = serial8250_rx_chars(up, status); + +if (dma_err port-type == PORT_OMAP_16750) +serial8250_rx_dma(up, 0); Can we stick to a 'has dma' flag and port-rx_dma() type usages so that we don't have to rewrite it again to add them the next slightly odd DMA user we add 8) I hide this behind a bug flag, something like UART_NEEDS_DMA_RX_PENDING. Sebastian -- 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 15/15] tty: serial: 8250: omap: add dma support
On Fri, Aug 29, 2014 at 11:32:36AM +0200, Sebastian Andrzej Siewior wrote: On 08/29/2014 12:54 AM, Tony Lindgren wrote: * Sebastian Andrzej Siewior bige...@linutronix.de [140828 12:37]: On 08/28/2014 06:46 PM, Tony Lindgren wrote: Sounds like there should be some way to clear that state.. I wonder if omap-serial.c had something before it's DMA support was removed? Its DMA was removed? Like there was DMA support? Yeah see commit 494574304711a86e7dd5fd3ebbc3b7024994... Interesting. I've been browsing that file and checking other trees and never noticed that it was there at some point. I only saw the pieces which looked it was there. it was known to be broken and unused. There was no way to even enable that code. -- balbi signature.asc Description: Digital signature
Re: [PATCH 05/15] tty: serial: Add 8250-core based omap driver
* Sebastian Andrzej Siewior bige...@linutronix.de [140829 08:50]: On 08/16/2014 12:44 AM, Tony Lindgren wrote: Oh and echo mem /sys/power/state and then hitting a key on the serial console won't wake the system. Does that need to be manually configured for device_may_wakeup()? This is what it looks like: /# echo enabled /sys/devices/6800.ocp/4902.serial/tty/ttyS2/power/wakeup / # date; echo mem /sys/power/state; date Sat Jan 1 07:01:41 UTC 2000 [ 249.916503] PM: Syncing filesystems ... done. [ 252.674652] Freezing user space processes ... (elapsed 0.001 seconds) done. [ 252.683563] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 252.693084] Suspending console(s) (use no_console_suspend to debug) [ 252.715820] PM: suspend of devices complete after 11.688 msecs [ 252.722015] PM: late suspend of devices complete after 6.195 msecs [ 252.729187] PM: noirq suspend of devices complete after 7.110 msecs [ 252.729278] Successfully put all powerdomains to target state [ 252.733306] PM: noirq resume of devices complete after 3.967 msecs [ 252.738708] PM: early resume of devices complete after 4.425 msecs [ 252.910400] PM: resume of devices complete after 171.569 msecs [ 252.957855] Restarting tasks ... done. Sat Jan 1 07:01:51 UTC 2000 Yes works for me too now thanks. 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: [PATCH 15/15] tty: serial: 8250: omap: add dma support
* Sebastian Andrzej Siewior bige...@linutronix.de [140829 02:32]: On 08/29/2014 12:54 AM, Tony Lindgren wrote: OK thanks, I'm seeing the same issue as you. And the idlest registers don't show any blockers. Looking at the errata docs, seems like Usage Note 2.7 in sprz318f.pdf says: Details When configured for DMA operations using smartidle mode (SYSC[4:3].IDLEMODE = 0x2), the UART module will not acknowledge incoming idle requests. As a consequence, it can prevent L4 from going to idle. When there are additional expected transfers, the UART should be placed in force-idle mode. Ehm. So I haven't found an errata document for omap3630, there is nothing like that in that one I have for am335x or dra7. The document you mentioned is for AM3715. Interesting… Yes I would not be suprised if that same bug is in all of them though.. So I've added also Paul to Cc, he may have better suggestions for the hwmod flags to use. The experimental patch below seems to allow idling for me, care to give it a try? Yep, this one works. And I see DMA transfers (for RX side) after the core hit idle so it seems to look good :) OK great :) Looks like the paste bug is there for sure, doing off idle and pasting 240 characters to the console can hang the UART RX after few attempts, and pasting 16 charactes won't show up at all if the system is idling. So you may want to play with that too a bit :) 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: [PATCH 15/15] tty: serial: 8250: omap: add dma support
On 08/29/2014 06:12 PM, Tony Lindgren wrote: Looks like the paste bug is there for sure, doing off idle and pasting 240 characters to the console can hang the UART RX after few attempts, and pasting 16 charactes won't show up at all if the system is idling. So you may want to play with that too a bit :) Oh. perfect. Please note that we the threshold moved from 16 to 48. However I see that usually we lose a lot of characters before the uart wakes up and does its job. Usually I see a couple characters but sometimes is see broken characters which suggests that the clock was not (yet) perfect. And I managed not get get it woken once. So let me look at this once I am through with the review responses… Regards, Tony Sebastian -- 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
