Re: SD card timeout problems on Nokia N900 (omap_hsmmc on OMAP3)
On Wednesday 26 February 2014 12:25 PM, Stefan Roese wrote: Hi Sebastian, On 26.02.2014 07:02, Michael Trimarchi wrote: Hi Sebastian On Wed, Feb 26, 2014 at 12:47 AM, Sebastian Reichel s...@ring0.de wrote: Hi, I have problems with the SD-card initialization on my Nokia N900 using a 3.14-rc1 based kernel in DT boot mode. The bug is can be circumvented by changing the kernel slightly (e.g. remove some DT nodes or mark them as disabled). So the SD card's timeout problems seem to derive from kernel timing problems. I'm pretty sure, that the problems are not originating from a broken SD card, since Can you provide removed/Disabled dt nodes, it might give some clue ? 1. The SD card worked quite good before and still does depending on unrelated DTS changes (= loading less drivers). 2. The SD card works flawlessly on my notebook using a USB adapter 3. Another SD card showed the same problem I tried to git bisect the problem, but I just get shown some unrelated driver additions. Anyways, this is the error I get during boot: [3.896820] mmc0: mmc_rescan_try_freq: trying to init card at 40 Hz ... [5.956237] mmc0: error -110 whilst initialising SD card Are you sure that some subsystem that you deactivate don't change pin muxing setting? Can you check in the broken system if the pins of the sdcard are correctly muxed? Does it happen even if you change the sdcard? Did you try to add this patch series: http://www.spinics.net/lists/linux-omap/msg103264.html Without it I'm also having problems with MMC detection on some OMAP3 based boards. Balaji, what is the status of this patch series? Are there any chances that it will be included in v3.14? Due to dependencies between regulator, mmc, omap def config, devicetree changes, I am hoping either Chris or Tony pick the whole series for 3.15 Couple of tested-by will surely help. Thanks and Regards, Balaji T K -- 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 RESEND v10 0/7] mmc: omap_hsmmc: pbias dt and cleanup
On 19.02.2014 15:56, Balaji T K wrote: Few cleanups to reduce code indent, Add pbias_regulator support and adapt omap_hsmmc to use pbias regulator to configure required voltage on mmc1 pad(SD card) i/o rails on OMAP SoCs. Balaji T K (7): mmc: omap_hsmmc: use devm_regulator API mmc: omap_hsmmc: handle vcc and vcc_aux independently regulator: add pbias regulator support mmc: omap_hsmmc: adapt hsmmc to use pbias regulator ARM: dts: add pbias dt node ARM: OMAP: enable SYSCON and REGULATOR_PBIAS in omap2plus_defconfig mmc: omap_hsmmc: remove pbias workaround .../bindings/regulator/pbias-regulator.txt | 27 ++ arch/arm/boot/dts/dra7.dtsi| 17 ++ arch/arm/boot/dts/omap2430.dtsi| 17 ++ arch/arm/boot/dts/omap3.dtsi | 17 ++ arch/arm/boot/dts/omap4.dtsi | 17 ++ arch/arm/boot/dts/omap5.dtsi | 17 ++ arch/arm/configs/omap2plus_defconfig |2 + drivers/mmc/host/omap_hsmmc.c | 111 + drivers/regulator/Kconfig |9 + drivers/regulator/Makefile |1 + drivers/regulator/pbias-regulator.c| 255 11 files changed, 441 insertions(+), 49 deletions(-) create mode 100644 Documentation/devicetree/bindings/regulator/pbias-regulator.txt create mode 100644 drivers/regulator/pbias-regulator.c This patch series (its v11 even though this mail has the subject v10) fixes problems I'm experiencing with MMC detection on some OMAP3 based boards. So: Tested-by: Stefan Roese s...@denx.de Thanks, Stefan -- 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 RFC 3/5] ASoC: tlv320aic31xx: Add DT binding document
Initial version of tlv320aic31xx device tree bindings document.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
.../devicetree/bindings/sound/tlv320aic31xx.txt| 57
1 file changed, 57 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/tlv320aic31xx.txt
diff --git a/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt
b/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt
new file mode 100644
index 000..a512b4e
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt
@@ -0,0 +1,57 @@
+Texas Instruments - tlv320aic31xx Codec module
+
+The tlv320aic31xx serial control bus communicates through I2C protocols
+
+Required properties:
+
+- compatible - string - One of:
+ti,tlv320aic310x - Generic TLV320AIC31xx with mono speaker amp
+ti,tlv320aic311x - Generic TLV320AIC31xx with stereo speaker amp
+ti,tlv320aic3100 - TLV320AIC3100 (mono speaker amp, no MiniDSP)
+ti,tlv320aic3110 - TLV320AIC3110 (stereo speaker amp, no MiniDSP)
+ti,tlv320aic3120 - TLV320AIC3120 (mono speaker amp, MiniDSP)
+ti,tlv320aic3111 - TLV320AIC3111 (stereo speaker amp, MiniDSP)
+
+- reg - int - I2C slave address
+
+
+Optional properties:
+
+- gpio-reset - gpio pin number used for codec reset
+- ai31xx-micbias-vg - MicBias Voltage required.
+ 1 - MICBIAS output is powered to 2.0V,
+ 2 - MICBIAS output is powered to 2.5V,
+ 3 - MICBIAS output is connected to AVDD,
+ If this node is not mentioned or if the value is incorrect, then MicBias
+ is powered down.
+- HPVDD-supply, SPRVDD-supply, SPLVDD-supply, AVDD-supply, IOVDD-supply,
+ DVDD-supply : power supplies for the device as covered in
+ Documentation/devicetree/bindings/regulator/regulator.txt
+
+CODEC output pins:
+ * HPL
+ * HPR
+ * SPL, devices with stereo speaker amp
+ * SPR, devices with stereo speaker amp
+ * SPK, devices with mono speaker amp
+
+CODEC input pins:
+ * MIC1LP
+ * MIC1RP
+ * MIC1LM
+
+The pins can be used in referring sound node's audio-routing property.
+
+Example:
+
+tlv320aic31xx: tlv320aic31xx@18 {
+ compatible = ti,tlv320aic311x;
+ reg = 0x18;
+
+ HPVDD-supply = regulator;
+ SPRVDD-supply = regulator;
+ SPLVDD-supply = regulator;
+ AVDD-supply = regulator;
+ IOVDD-supply = regulator;
+ DVDD-supply = regulator;
+};
--
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
[PATCH RFC 0/5] AM43xx-ePOS-EVM audio support with TLV320AIC31XX driver
This patch set adds audio support for AM43xx-ePOS-EVM. I'll mail the dts and defconfig changes once these have been merged. Jyri Sarha (5): ASoC: tlv320aic31xx: Add basic codec driver implementation ASoC: tlv320aic31xx: Add codec driver to Makefile and Kconfig ASoC: tlv320aic31xx: Add DT binding document ASoC: davinci-evm: Add AM43xx-EPOS-EVM audio support ASoC: davinci: Add SND_AM43XX_SOC_EPOS_EVM build option .../bindings/sound/davinci-evm-audio.txt |9 +- .../devicetree/bindings/sound/tlv320aic31xx.txt| 57 + sound/soc/codecs/Kconfig |4 + sound/soc/codecs/Makefile |2 + sound/soc/codecs/tlv320aic31xx.c | 1360 sound/soc/codecs/tlv320aic31xx.h | 265 sound/soc/davinci/Kconfig | 12 + sound/soc/davinci/Makefile |1 + sound/soc/davinci/davinci-evm.c| 41 + 9 files changed, 1748 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/tlv320aic31xx.txt create mode 100644 sound/soc/codecs/tlv320aic31xx.c create mode 100644 sound/soc/codecs/tlv320aic31xx.h -- 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
[PATCH RFC 4/5] ASoC: davinci-evm: Add AM43xx-EPOS-EVM audio support
Add machine driver support for AM43xx-ePOS-EVM and update associated
device tree binding document.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
.../bindings/sound/davinci-evm-audio.txt |9 +++--
sound/soc/davinci/davinci-evm.c| 41
2 files changed, 47 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..356cba1 100644
--- a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
+++ b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
@@ -2,8 +2,10 @@
Required properties:
- compatible : ti,da830-evm-audio : forDM365/DA8xx/OMAPL1x/AM33xx
+: ti,am43xx-epos-evm-audio : for am43xx-epos-evm
- ti,model : The user-visible name of this sound complex.
-- ti,audio-codec : The phandle of the TLV320AIC3x audio codec
+- ti,audio-codec : The phandle of the TLV320AIC3x audio codec,
+ or the TLV320AIC31xx 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.
@@ -14,9 +16,10 @@ Required properties:
Board connectors:
* Headphone Jack
- * Line Out
+ * Line Out - ti,da830-evm-audio only
* Mic Jack
- * Line In
+ * Line In - ti,da830-evm-audio only
+ * Speaker - ti,am43xx-epos-evm-audio only
Example:
diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
index 5e3bc3c..d4d965e 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -128,6 +128,33 @@ static int evm_aic3x_init(struct snd_soc_pcm_runtime *rtd)
return 0;
}
+static const struct snd_soc_dapm_widget aic31xx_dapm_widgets[] = {
+ SND_SOC_DAPM_HP(Headphone Jack, NULL),
+ SND_SOC_DAPM_SPK(Speaker, NULL),
+ SND_SOC_DAPM_MIC(Mic Jack, NULL),
+};
+
+/* Logic for EVMs with an aic31xx */
+static int evm_aic31xx_init(struct snd_soc_pcm_runtime *rtd)
+{
+ struct snd_soc_codec *codec = rtd-codec;
+ struct snd_soc_dapm_context *dapm = codec-dapm;
+ struct device_node *np = codec-card-dev-of_node;
+ int ret;
+
+ snd_soc_dapm_new_controls(dapm, aic31xx_dapm_widgets,
+ ARRAY_SIZE(aic31xx_dapm_widgets));
+
+ if (np) {
+ ret = snd_soc_of_parse_audio_routing(codec-card,
+ti,audio-routing);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
/* davinci-evm digital audio interface glue - connects codec -- CPU */
static struct snd_soc_dai_link dm6446_evm_dai = {
.name = TLV320AIC3X,
@@ -326,11 +353,25 @@ static struct snd_soc_dai_link evm_dai_tlv320aic3x = {
SND_SOC_DAIFMT_IB_NF,
};
+static struct snd_soc_dai_link evm_dai_tlv320aic3111 = {
+ .name = TLV320AIC3111,
+ .stream_name= AIC3111,
+ .codec_dai_name = tlv320aic31xx-hifi,
+ .ops= evm_ops,
+ .init = evm_aic31xx_init,
+ .dai_fmt= (SND_SOC_DAIFMT_CBM_CFM | SND_SOC_DAIFMT_DSP_B |
+ SND_SOC_DAIFMT_IB_NF),
+};
+
static const struct of_device_id davinci_evm_dt_ids[] = {
{
.compatible = ti,da830-evm-audio,
.data = (void *) evm_dai_tlv320aic3x,
},
+ {
+ .compatible = ti,am43xx-epos-evm-audio,
+ .data = evm_dai_tlv320aic3111,
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, davinci_evm_dt_ids);
--
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
[PATCH RFC 2/5] ASoC: tlv320aic31xx: Add codec driver to Makefile and Kconfig
Signed-off-by: Jyri Sarha jsa...@ti.com --- sound/soc/codecs/Kconfig |4 sound/soc/codecs/Makefile |2 ++ 2 files changed, 6 insertions(+) diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index 983d087a..ead9dc5 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -74,6 +74,7 @@ config SND_SOC_ALL_CODECS select SND_SOC_TLV320AIC23 if I2C select SND_SOC_TLV320AIC26 if SPI_MASTER select SND_SOC_TLV320AIC32X4 if I2C + select SND_SOC_TLV320AIC31XX if I2C select SND_SOC_TLV320AIC3X if I2C select SND_SOC_TPA6130A2 if I2C select SND_SOC_TLV320DAC33 if I2C @@ -364,6 +365,9 @@ config SND_SOC_TLV320AIC26 config SND_SOC_TLV320AIC32X4 tristate +config SND_SOC_TLV320AIC31XX +tristate + config SND_SOC_TLV320AIC3X tristate diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile index bc12676..23f8042 100644 --- a/sound/soc/codecs/Makefile +++ b/sound/soc/codecs/Makefile @@ -64,6 +64,7 @@ snd-soc-stac9766-objs := stac9766.o snd-soc-tas5086-objs := tas5086.o snd-soc-tlv320aic23-objs := tlv320aic23.o snd-soc-tlv320aic26-objs := tlv320aic26.o +snd-soc-tlv320aic31xx-objs := tlv320aic31xx.o snd-soc-tlv320aic3x-objs := tlv320aic3x.o snd-soc-tlv320aic32x4-objs := tlv320aic32x4.o snd-soc-tlv320dac33-objs := tlv320dac33.o @@ -194,6 +195,7 @@ obj-$(CONFIG_SND_SOC_STAC9766) += snd-soc-stac9766.o obj-$(CONFIG_SND_SOC_TAS5086) += snd-soc-tas5086.o obj-$(CONFIG_SND_SOC_TLV320AIC23) += snd-soc-tlv320aic23.o obj-$(CONFIG_SND_SOC_TLV320AIC26) += snd-soc-tlv320aic26.o +obj-$(CONFIG_SND_SOC_TLV320AIC31XX) += snd-soc-tlv320aic31xx.o obj-$(CONFIG_SND_SOC_TLV320AIC3X) += snd-soc-tlv320aic3x.o obj-$(CONFIG_SND_SOC_TLV320AIC32X4) += snd-soc-tlv320aic32x4.o obj-$(CONFIG_SND_SOC_TLV320DAC33) += snd-soc-tlv320dac33.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
[PATCH RFC 5/5] ASoC: davinci: Add SND_AM43XX_SOC_EPOS_EVM build option
Add support for am335x and am43x based boards with tlv320aic31xx compatible codec connected to McASP. 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..e1e3663 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_AM43XX_SOC_EPOS_EVM + tristate SoC Audio for the AM33XX/AM43XX and TLV320AIC31XX based board + depends on SND_DAVINCI_SOC + depends on SOC_AM33XX || SOC_AM43XX + select SND_SOC_TLV320AIC31XX + select SND_DAVINCI_SOC_MCASP + help + Say Y or M if you want to add support for SoC audio on + AM335X/AM43XX boards using McASP to connect to a codec of + TLV320AIC31XX series. For example AM43XX-EPOS-EVM has such a + setup. + 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..d61998f 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_AM43XX_SOC_EPOS_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
[PATCH RFC 1/5] ASoC: tlv320aic31xx: Add basic codec driver implementation
This commit adds a bare bones driver support for TLV320AIC31XX family
audio codecs. The driver adds basic stereo playback trough headphone
and speaker outputs and mono capture trough microphone inputs.
The driver is currently missing support at least for mini DSP features
and jack detection. I have tested the driver only on TLV320AIC3111,
but based on the data sheets TLV320AIC3100, TLV320AIC3110, and
TLV320AIC3120 should work Ok too.
The base for the implementation was taken from:
g...@gitorious.org:ti-codecs/ti-codecs.git ajitk/topics/k3.10.1-aic31xx
-branch at commit 77504eba0294764e9e63b4a0c696b44db187cd13.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
sound/soc/codecs/tlv320aic31xx.c | 1360 ++
sound/soc/codecs/tlv320aic31xx.h | 265
2 files changed, 1625 insertions(+)
create mode 100644 sound/soc/codecs/tlv320aic31xx.c
create mode 100644 sound/soc/codecs/tlv320aic31xx.h
diff --git a/sound/soc/codecs/tlv320aic31xx.c b/sound/soc/codecs/tlv320aic31xx.c
new file mode 100644
index 000..1f83779
--- /dev/null
+++ b/sound/soc/codecs/tlv320aic31xx.c
@@ -0,0 +1,1360 @@
+/*
+ * ALSA SoC TLV320AIC31XX codec driver
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Author: Jyri Sarha jsa...@ti.com
+ *
+ * Based on ground work by: Ajit Kulkarni x0175...@ti.com
+ *
+ * This package 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.
+ *
+ * THIS PACKAGE IS PROVIDED AS IS AND WITHOUT ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
+ * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
+ *
+ * The TLV320AIC31xx series of audio codec is a low-power, highly integrated
+ * high performance codec which provides a stereo DAC, a mono ADC,
+ * and mono/stereo Class-D speaker driver.
+ */
+
+#include linux/module.h
+#include linux/moduleparam.h
+#include linux/init.h
+#include linux/delay.h
+#include linux/pm.h
+#include linux/i2c.h
+#include linux/gpio.h
+#include linux/regulator/consumer.h
+#include linux/of_gpio.h
+#include linux/slab.h
+#include sound/core.h
+#include sound/pcm.h
+#include sound/pcm_params.h
+#include sound/soc.h
+#include sound/initval.h
+#include sound/tlv.h
+
+#include tlv320aic31xx.h
+
+static const struct reg_default aic31xx_reg_defaults[] = {
+ { AIC31XX_CLKMUX, 0x00 },
+ { AIC31XX_PLLPR, 0x11 },
+ { AIC31XX_PLLJ, 0x04 },
+ { AIC31XX_PLLDMSB, 0x00 },
+ { AIC31XX_PLLDLSB, 0x00 },
+ { AIC31XX_NDAC, 0x01 },
+ { AIC31XX_MDAC, 0x01 },
+ { AIC31XX_DOSRMSB, 0x00 },
+ { AIC31XX_DOSRLSB, 0x80 },
+ { AIC31XX_NADC, 0x01 },
+ { AIC31XX_MADC, 0x01 },
+ { AIC31XX_AOSR, 0x80 },
+ { AIC31XX_IFACE1, 0x00 },
+ { AIC31XX_DATA_OFFSET, 0x00 },
+ { AIC31XX_IFACE2, 0x00 },
+ { AIC31XX_BCLKN, 0x01 },
+ { AIC31XX_DACSETUP, 0x14 },
+ { AIC31XX_DACMUTE, 0x0c },
+ { AIC31XX_LDACVOL, 0x00 },
+ { AIC31XX_RDACVOL, 0x00 },
+ { AIC31XX_ADCSETUP, 0x00 },
+ { AIC31XX_ADCFGA, 0x80 },
+ { AIC31XX_ADCVOL, 0x00 },
+ { AIC31XX_HPDRIVER, 0x04 },
+ { AIC31XX_SPKAMP, 0x06 },
+ { AIC31XX_DACMIXERROUTE, 0x00 },
+ { AIC31XX_LANALOGHPL, 0x7f },
+ { AIC31XX_RANALOGHPR, 0x7f },
+ { AIC31XX_LANALOGSPL, 0x7f },
+ { AIC31XX_RANALOGSPR, 0x7f },
+ { AIC31XX_HPLGAIN, 0x02 },
+ { AIC31XX_HPRGAIN, 0x02 },
+ { AIC31XX_SPLGAIN, 0x00 },
+ { AIC31XX_SPRGAIN, 0x00 },
+ { AIC31XX_MICBIAS, 0x00 },
+ { AIC31XX_MICPGA, 0x80 },
+ { AIC31XX_MICPGAPI, 0x00 },
+ { AIC31XX_MICPGAMI, 0x00 },
+};
+
+static bool aic31xx_precious(struct device *dev, unsigned int reg)
+{
+ switch (reg) {
+ case AIC31XX_OFFLAG:
+ case AIC31XX_INTRDACFLAG:
+ case AIC31XX_INTRADCFLAG:
+ return true;
+ }
+ return false;
+}
+
+static bool aic31xx_real_volatile(struct device *dev, unsigned int reg)
+{
+ switch (reg) {
+ case AIC31XX_OT_FLAG:
+ case AIC31XX_ADCFLAG:
+ case AIC31XX_DACFLAG1:
+ case AIC31XX_DACFLAG2:
+ case AIC31XX_INTRDACFLAG2:
+ case AIC31XX_INTRADCFLAG2:
+ return true;
+ }
+ return false;
+}
+
+static bool aic31xx_volatile(struct device *dev, unsigned int reg)
+{
+ if (aic31xx_precious(dev, reg) || aic31xx_real_volatile(dev, reg))
+ return true;
+
+ switch (reg) {
+ case AIC31XX_PAGECTL: /* regmap implementation requires this */
+ case AIC31XX_RESET: /* always clears after write */
+ return true;
+ }
+ return false;
+}
+
+static bool aic31xx_writeable(struct device *dev, unsigned int reg)
+{
+ if (aic31xx_precious(dev, reg) || aic31xx_real_volatile(dev, reg))
+ return false;
+
+ return true;
+}
+
+static const struct
Re: TWL6040 fails to initialize
Hi, First, thanks for your help. On 02/26/2014 08:26 AM, Peter Ujfalusi wrote: On 02/25/2014 05:41 PM, Florian Vaussard wrote: If the power was not enabled at all, I would be unable to read the revision register, no? And delaying the probe by one millisecond would be of no help in this case IMHO. One thing which might cause this is that if the audpwron GPIO is set high before the twl6040 module is probing. When I request the GPIO I ask it to be set to low. If the line was high before this means we initiate the power off sequence. Can you try something like this: I statistically checked that the sleep should be placed after the GPIO request, so indeed this seems to be the problem, and your explanation is plausible. Can you send a proper patch? Now, related to this, I managed to found a part of the datasheet on the Great Internet. Looking at the Power-Up Sequence section, it is written: - NRESPWRON goes high - plug detect and GPO are available - V2V1 goes high - hook-detect available by I2C programming (sleep mode) - AUDPWRON goes high READYINT - ready to communicate through I2C and PDM So, although there seems to be some contradictions on when it is possible to access the I2C, shouldn't we enable the AUDPWRON GPIO _before_ making any I2C access? For the twl6040_probe, the following path would seem more correct to me: 1) enable regulators 2) request AUDPWRON 3) twl6040_power(ON) regcache_cache_only(false) 4) wait for READYINT (or sleep if deterministic) 5) perform all required I2C accesses (read revision, etc.) 6) twl6040_power(OFF) regcache_cache_only(true) What do you think? Thanks, Florian diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c index 75316fb33448..d2a0bd1539ae 100644 --- a/drivers/mfd/twl6040.c +++ b/drivers/mfd/twl6040.c @@ -674,6 +674,9 @@ static int twl6040_probe(struct i2c_client *client, GPIOF_OUT_INIT_LOW, audpwron); if (ret) goto gpio_err; + + /* power-down sequence latency */ + usleep_range(500, 700); } ret = regmap_add_irq_chip(twl6040-regmap, twl6040-irq, IRQF_ONESHOT, -- 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: TWL6040 fails to initialize
On 02/26/2014 11:53 AM, Florian Vaussard wrote: On 02/26/2014 08:26 AM, Peter Ujfalusi wrote: On 02/25/2014 05:41 PM, Florian Vaussard wrote: If the power was not enabled at all, I would be unable to read the revision register, no? And delaying the probe by one millisecond would be of no help in this case IMHO. One thing which might cause this is that if the audpwron GPIO is set high before the twl6040 module is probing. When I request the GPIO I ask it to be set to low. If the line was high before this means we initiate the power off sequence. Can you try something like this: I statistically checked that the sleep should be placed after the GPIO request, so indeed this seems to be the problem, and your explanation is plausible. Can you send a proper patch? Now, related to this, I managed to found a part of the datasheet on the Great Internet. Looking at the Power-Up Sequence section, it is written: - NRESPWRON goes high - plug detect and GPO are available - V2V1 goes high - hook-detect available by I2C programming (sleep mode) - AUDPWRON goes high READYINT - ready to communicate through I2C and PDM So, although there seems to be some contradictions on when it is possible to access the I2C, shouldn't we enable the AUDPWRON GPIO _before_ making any I2C access? For the twl6040_probe, the following path would seem more correct to me: 1) enable regulators 2) request AUDPWRON 3) twl6040_power(ON) regcache_cache_only(false) 4) wait for READYINT (or sleep if deterministic) 5) perform all required I2C accesses (read revision, etc.) 6) twl6040_power(OFF) regcache_cache_only(true) What do you think? Even when the AUDPWRON signal is low we can access to registers in VIO domain, plug detect and GPO functions. So there's no need to power on the codec just to power it down later. Thanks, Florian diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c index 75316fb33448..d2a0bd1539ae 100644 --- a/drivers/mfd/twl6040.c +++ b/drivers/mfd/twl6040.c @@ -674,6 +674,9 @@ static int twl6040_probe(struct i2c_client *client, GPIOF_OUT_INIT_LOW, audpwron); if (ret) goto gpio_err; + + /* power-down sequence latency */ + usleep_range(500, 700); } ret = regmap_add_irq_chip(twl6040-regmap, twl6040-irq, IRQF_ONESHOT, -- Péter -- 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: TWL6040 fails to initialize
On 02/26/2014 11:28 AM, Peter Ujfalusi wrote: On 02/26/2014 11:53 AM, Florian Vaussard wrote: On 02/26/2014 08:26 AM, Peter Ujfalusi wrote: On 02/25/2014 05:41 PM, Florian Vaussard wrote: If the power was not enabled at all, I would be unable to read the revision register, no? And delaying the probe by one millisecond would be of no help in this case IMHO. One thing which might cause this is that if the audpwron GPIO is set high before the twl6040 module is probing. When I request the GPIO I ask it to be set to low. If the line was high before this means we initiate the power off sequence. Can you try something like this: I statistically checked that the sleep should be placed after the GPIO request, so indeed this seems to be the problem, and your explanation is plausible. Can you send a proper patch? Now, related to this, I managed to found a part of the datasheet on the Great Internet. Looking at the Power-Up Sequence section, it is written: - NRESPWRON goes high - plug detect and GPO are available - V2V1 goes high - hook-detect available by I2C programming (sleep mode) - AUDPWRON goes high READYINT - ready to communicate through I2C and PDM So, although there seems to be some contradictions on when it is possible to access the I2C, shouldn't we enable the AUDPWRON GPIO _before_ making any I2C access? For the twl6040_probe, the following path would seem more correct to me: 1) enable regulators 2) request AUDPWRON 3) twl6040_power(ON) regcache_cache_only(false) 4) wait for READYINT (or sleep if deterministic) 5) perform all required I2C accesses (read revision, etc.) 6) twl6040_power(OFF) regcache_cache_only(true) What do you think? Even when the AUDPWRON signal is low we can access to registers in VIO domain, plug detect and GPO functions. So there's no need to power on the codec just to power it down later. Ok, if it is safe to do so, I am fine with the current probe. I let you post a patch to add a delay after requesting the GPIO. Regards, Florian Thanks, Florian diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c index 75316fb33448..d2a0bd1539ae 100644 --- a/drivers/mfd/twl6040.c +++ b/drivers/mfd/twl6040.c @@ -674,6 +674,9 @@ static int twl6040_probe(struct i2c_client *client, GPIOF_OUT_INIT_LOW, audpwron); if (ret) goto gpio_err; + + /* power-down sequence latency */ + usleep_range(500, 700); } ret = regmap_add_irq_chip(twl6040-regmap, twl6040-irq, IRQF_ONESHOT, -- 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 v3 2/2] ARM: DTS: OMAP4/5: Use l3_ick for the gpmc node
The GPMC clock is derived from l3_ick. The simplest solution is
to reference directly l3_ick to provide the GPMC fck in order to
get correct timings. The real management of the clock is left to
hwmod.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/boot/dts/omap4.dtsi | 2 ++
arch/arm/boot/dts/omap5.dtsi | 2 ++
2 files changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 756cd34..381c0cc 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -275,6 +275,8 @@
gpmc,num-waitpins = 4;
ti,hwmods = gpmc;
ti,no-idle-on-init;
+ clocks = l3_div_ck;
+ clock-names = fck;
};
uart1: serial@4806a000 {
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index a72813a..7a16647 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -302,6 +302,8 @@
gpmc,num-cs = 8;
gpmc,num-waitpins = 4;
ti,hwmods = gpmc;
+ clocks = l3_iclk_div;
+ clock-names = fck;
};
i2c1: i2c@4807 {
--
1.8.1.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
[PATCH v3 0/2] ARM: OMAP4+: Fix gpmc_fck clock
Hello, Trying to get my SMSC9221 working on OMAP4 with DT, I faced a misconfigured gpmc_fck (dummy clock set to 0) resulting in serveral division-by-zero, misconfigured timings and driver lost in the La La Land. To solve this, patch 1 removes gpmc_fck from the dummy clocks, and patch 2 adds the gpmc_fck DT node and reference it from the gpmc node. *Note*: For DRA7, there is no DTS node for the GPMC, so I was unable to set the corresponding clock. And without a public TRM, I cannot do much more. Tested on DuoVero/Parlor (OMAP4430) with SMSC9221 (DTS was posted on the OMAP ML [1]). Regards, Florian [1] http://thread.gmane.org/gmane.linux.ports.arm.omap/110801 --- Since v2: - Added OMAP5 and DRA7 Since v1: - Removed the gpmc_fck clock node, and reference directly l3_ick Florian Vaussard (2): CLK: TI: OMAP4/5/DRA7: Remove gpmc_fck from dummy clocks ARM: DTS: OMAP4/5: Use l3_ick for the gpmc node arch/arm/boot/dts/omap4.dtsi | 2 ++ arch/arm/boot/dts/omap5.dtsi | 2 ++ drivers/clk/ti/clk-44xx.c| 1 - drivers/clk/ti/clk-54xx.c| 1 - drivers/clk/ti/clk-7xx.c | 1 - 5 files changed, 4 insertions(+), 3 deletions(-) -- 1.8.1.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
[PATCH v3 1/2] CLK: TI: OMAP4/5/DRA7: Remove gpmc_fck from dummy clocks
When arch/arm/mach-omap2/gpmc.c calls clk_get(..., fck), it will
get a dummy clock and try to use it. As the rate is configured to zero,
this will result in several divisions by zero, and misconfigured
timings, with devices on the bus being lost in the La La Land.
It is better to remove gpmc_fck from the dummy clocks, so that gpmc.c
can fail gracefully.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
drivers/clk/ti/clk-44xx.c | 1 -
drivers/clk/ti/clk-54xx.c | 1 -
drivers/clk/ti/clk-7xx.c | 1 -
3 files changed, 3 deletions(-)
diff --git a/drivers/clk/ti/clk-44xx.c b/drivers/clk/ti/clk-44xx.c
index ae00218..02517a8 100644
--- a/drivers/clk/ti/clk-44xx.c
+++ b/drivers/clk/ti/clk-44xx.c
@@ -222,7 +222,6 @@ static struct ti_dt_clk omap44xx_clks[] = {
DT_CLK(NULL, auxclk5_src_ck, auxclk5_src_ck),
DT_CLK(NULL, auxclk5_ck, auxclk5_ck),
DT_CLK(NULL, auxclkreq5_ck, auxclkreq5_ck),
- DT_CLK(5000.gpmc, fck, dummy_ck),
DT_CLK(omap_i2c.1, ick, dummy_ck),
DT_CLK(omap_i2c.2, ick, dummy_ck),
DT_CLK(omap_i2c.3, ick, dummy_ck),
diff --git a/drivers/clk/ti/clk-54xx.c b/drivers/clk/ti/clk-54xx.c
index 0ef9f58..08f3d1b 100644
--- a/drivers/clk/ti/clk-54xx.c
+++ b/drivers/clk/ti/clk-54xx.c
@@ -182,7 +182,6 @@ static struct ti_dt_clk omap54xx_clks[] = {
DT_CLK(NULL, auxclk3_src_ck, auxclk3_src_ck),
DT_CLK(NULL, auxclk3_ck, auxclk3_ck),
DT_CLK(NULL, auxclkreq3_ck, auxclkreq3_ck),
- DT_CLK(NULL, gpmc_ck, dummy_ck),
DT_CLK(omap_i2c.1, ick, dummy_ck),
DT_CLK(omap_i2c.2, ick, dummy_ck),
DT_CLK(omap_i2c.3, ick, dummy_ck),
diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index 9977653..f7e4073 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -262,7 +262,6 @@ static struct ti_dt_clk dra7xx_clks[] = {
DT_CLK(NULL, vip1_gclk_mux, vip1_gclk_mux),
DT_CLK(NULL, vip2_gclk_mux, vip2_gclk_mux),
DT_CLK(NULL, vip3_gclk_mux, vip3_gclk_mux),
- DT_CLK(NULL, gpmc_ck, dummy_ck),
DT_CLK(omap_i2c.1, ick, dummy_ck),
DT_CLK(omap_i2c.2, ick, dummy_ck),
DT_CLK(omap_i2c.3, ick, dummy_ck),
--
1.8.1.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/2] ARM: dts: duovero-parlor: Add HDMI output
Hi, On 25/02/14 22:56, Russell King - ARM Linux wrote: On Tue, Feb 25, 2014 at 05:51:21PM +0100, Laurent Pinchart wrote: First I want to summarize the omapdss DT bindings, even if it was already more or less covered earlier: We have a bunch of panels and encoders used on OMAP boards, and we have separate, omapdss specific, drivers for those. My plan is to continue improving those drivers until they can be platform independent. This would be the Common Display Framework that's been discussed (or a precursor to it). We need DT bindings for OMAP display, and one option would've been adding a compatible string of ti,xxx for every panel and encoder. That would obviously be wrong DT representation. So I wanted to do proper DT bindings, with proper compatible string. This creates the problem that we don't have generic drivers for those components yet. For this, I created a hack that, on OMAP, appends omapdss, to the display components at boot time. This way we can have OMAP specific drivers for the time being, but others could still use the same bindings for their platform and platform specific drivers with similar trick. Note that the above is not merged yet, but I'd really want to get it in for the next merge window, so if that general concept is bad, please nack it asap. And preferably give ideas for an alternative =). I don't think all physical connectors require a DT binding per-se, but they need to be represented in DT as they're part of the hardware. We could push connector-related information to the nodes of all chips that have interfaces wired directly to connectors, but that would result in more complex DT bindings and core. I believe modeling connectors using separate DT nodes is be best, and would allow easier support for more complex connectors that carry multiple streams/signals in parallel (video, audio, DDC, ...). There are things we need to represent for the connectors. For example, a +5V going to the connector is not managed by any IP. In some cases neither is a hotplug detect GPIO. The i2c lines for the DDC need to be managed by someone (with DVI. HDMI DDC on OMAP is managed by by the HDMI IP). I guess one could argue that those are standard properties of HDMI or DVI, and thus could well be managed by the HDMI or DVI encoder, even if the encoder IP itself doesn't have anything to do with those. Maybe they could, but I think modeling the connector separately is more correct, and allows more freedom. Say, the HDMI could as well be directly wired to a panel, without any connector, although this is perhaps more common with eDP. In that case the connector related things can be just left out. Additionally, but perhaps not strictly needed, the connector represents a termination for the display pipeline, so there's a distinct display element at the end of the chain, sometimes a panel, sometimes a connector, which marks the end. This makes the pipeline consistent in the case where you've got an encoder, output of which goes on some boards to a connector and on some boards to a panel (compared to some boards having a panel after the encoder, and some having nothing). There is some sanity to representing physical connectors in DT, but it's not for the reason you mention above. If you consider that it's possible on PCs to find out what connectors are on the motherboard and where they are located, this is very useful information to be stored and presented. However, the idea that you combine streams at connectors is not a universal truth, and is certainly false for HDMI. HDMI combines video and audio at the encoder stage, not at the connector stage, and many HDMI encoders will provide everything required for driving the connector. However, my major objection here is not really that: my major objection is using something as generic as hdmi-connector as a compatible string. The reason is that we have to remember that DT is not just a Linux thing. It's /supposed/ to be an OS independent representation of the hardware. If we invent something generic called a hdmi-connector then we had better first do a thorough search to make sure we're not trampling on anything which is standardized or becoming a standard - if there is, we should work with them - and if that's not possible, then we need to distingush ourselves from them. Yes, I agree that the connectors (DVI, analog-tv, and HDMI) are in a sense much more generic than bindings for a single IP, and thus more important to get right. What we can't do is go around inventing generic stuff without having our eyes wide open. So, here's a good question to probe how far this has been thought through already: what has been done to discuss the creation of this generic hdmi-connector thing with the various parties who are interested in HDMI outputs under DRM using device tree? They have been discussed, in the context of Common Display Framework proposals, and in the context of OMAP DSS DT bindings. They've
Re: [PATCH 2/2] ARM: OMAP2+: fix dpll round_rate() to actually round
On 19/02/14 21:49, Paul Walmsley wrote: On Fri, 17 Jan 2014, Tomi Valkeinen wrote: omap2_dpll_round_rate() doesn't actually round the given rate, even if the name and the description so hints. Instead it only tries to find an exact rate match, or if that fails, return ~0 as an error. In the past, we had rate tolerance code, which allowed the clock code to return an approximate rate within some margin. See for example commit 241d3a8dca239610d3d991bf58d4fe38c2d86fd5 (OMAP2+: clock: remove the DPLL rate tolerance code). The rate tolerance was set at compile-time, but it was set on a per-PLL basis, which in theory allowed PLLs responsible for audio, etc. to have a very low rate tolerance, but PLLs that only drove internal functional blocks to have a high rate tolerance. Part of the reason why this was removed is because some of the TI hardware guys didn't want any PLL rates used that were not explicitly characterized. Ok. What this basically means is that the user of the clock needs to know what rates the dpll can support, which obviously isn't right. In principle I agree with you, but I'm not sure that this rate rounding function is the solution. This patch adds a simple method of rounding: during the iteration, the code keeps track of the closest rate match. If no exact match is found, the closest is returned. So that's one possible rounding policy; maybe it works fine for a display interface PLL, at least for some values of closest rate. But another might be only allow a selection from a set of pre-determined rates characterized by the silicon validation team. Or another rounding function might need to select a more distant rate that minimizes jitter, EMI, or power consumption. Seems to me that there needs to be some way for a clock user to communicate its requirements along these lines to the clock framework for use by the rate rounding code. At the very least, some kind of [min, max] interval seems appropriate. Also I've often thought that it would be useful for your purposes to be able to query a clock to return a list or some other parametric description of the rates that it can provide. I fully agree with all you said above. However, I'm not trying to fix the omap clock framework here =). I just want the displays to work properly in mainline kernel. So, presuming this was merged, and gets display working, how would it affect other users compared to the current state? The patched version returns the same rate than before, if an exact match is found. Rounded rate is only returned as a last option, instead of an error. Do we have drivers that handle that error somehow, and then do something (what?) to get some other rate? If the clock path in question also has a divider component after the pll, using clk-divider.c (which I guess is used in all/most of the DPLLs?), things would go badly wrong if there's an error, as clk-divider.c doesn't handle it. So I can make no guarantees, but I have a hunch that all current users ask for an exact clock, in which case this patch doesn't change their behavior, except for display which it fixes. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/2] ARM: OMAP2+: fix dpll round_rate() to actually round
On 20/02/14 21:30, Paul Walmsley wrote: On Wed, 19 Feb 2014, Paul Walmsley wrote: On Fri, 17 Jan 2014, Tomi Valkeinen wrote: This patch adds a simple method of rounding: during the iteration, the code keeps track of the closest rate match. If no exact match is found, the closest is returned. So that's one possible rounding policy; maybe it works fine for a display interface PLL, at least for some values of closest rate. But another might be only allow a selection from a set of pre-determined rates characterized by the silicon validation team. Or another rounding function might need to select a more distant rate that minimizes jitter, EMI, or power consumption. Thought about this some more. Do you only need this for the DSS PLL, or do you need it for one of the core OMAP PLLs? If the former, then how about modifying your patch to create a separate round_rate function that's only used for the DSS PLL that implements the behavior that you want? That would eliminate any risk of impacting other users on the system. And would also allow this change to get into the codebase much faster, since there's no need for clk API changes, etc. The DSS internal PLLs are handled by the DSS driver, which does all kinds of iteration to find good clocks. This patch is for a dedicated display PLL, present on, for example, BeagleBoneBlack. If you think that's better approach, I can take a look how it can be done (I'm not too familiar with the clock framework). Or maybe there's a possibility to have a flag of some kind, which allows rounded values to be returned? That sounds like an easy addition too. Note that the same change is needed for DT and non-DT boots. Having separate round function would mean create a new clock driver (i.e. compatibility string), wouldn't it? Adding a flag sounds easier. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output
On Wed, Feb 26, 2014 at 01:14:18PM +0200, Tomi Valkeinen wrote: We have a bunch of panels and encoders used on OMAP boards, and we have separate, omapdss specific, drivers for those. My plan is to continue improving those drivers until they can be platform independent. This would be the Common Display Framework that's been discussed (or a precursor to it). I believe CDF has been knocked on the head. Also - DRM is not going to ever support hotplugging components - this was discussed at kernel summit last year and David Airlie was quite adamant about that. So, any framework which forces hotplugging of components on subsystems isn't going to fly. This is why we now have the component helpers in the driver model - to allow devices to be collected together into one logical subsystem group, and bound/unbound as a group. Remember that hotplugging in this context does not mean that the user can physically do something with the hardware. It means that they're separate devices which can be probed/removed at will. Every device in Linux can be bound and unbound from its driver at any time by userspace, and that is something which is expected to be handled gracefully. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- 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/2] ARM: dts: duovero-parlor: Add HDMI output
On 26/02/14 14:03, Russell King - ARM Linux wrote: On Wed, Feb 26, 2014 at 01:14:18PM +0200, Tomi Valkeinen wrote: We have a bunch of panels and encoders used on OMAP boards, and we have separate, omapdss specific, drivers for those. My plan is to continue improving those drivers until they can be platform independent. This would be the Common Display Framework that's been discussed (or a precursor to it). I believe CDF has been knocked on the head. I refuse to believe that we can't have common drivers for display components. Maybe CDF as it's been proposed in its current form is not good (although I haven't seen any explanation why), we need something like it. So the CDF I speak of is not any particular set of patches already sent, but a framework that would allow us to have generic display drivers. I'd be very glad if someone can point me to the discussions where CDF has been knocked on the head. Also - DRM is not going to ever support hotplugging components - this was discussed at kernel summit last year and David Airlie was quite Ok. Very odd stance. Maybe there's a reason for it that I just don't see. adamant about that. So, any framework which forces hotplugging of components on subsystems isn't going to fly. CDF doesn't force hotplugging. Although without hotplugging (hot-unplug not needed), or at least some minimal form of it, the system is a bit crippled. Leave one kernel module out, or have one driver probe fail, the whole display subsystem fails, even if some display pipelines would work fine. On OMAP4 SDP board, for example, this would mean that if the user doesn't compile PicoDLP driver, or the driver fails to probe, the two LCDs and the analog TV out would also fail. Many of the boards don't even have a PicoDLP module installed, so a fail there somewhere is guaranteed. This is why we now have the component helpers in the driver model - to allow devices to be collected together into one logical subsystem group, and bound/unbound as a group. Yep, it's a good start. The component helpers could well be used with CDF. But if I'm not mistaken, it suffers from the problems above, when there are multiple independent pipelines (simultaneous or non-simultaneous) handled by the same IPs. And, while I may be mistaken, it sounds that the component helpers leave mostly everything up to the display drivers. Everyone devising their own way to describe the hardware in DT, and the connections between the components. Of course, the core component system shouldn't define anything DT related, as it doesn't. But that part is still needed, which is where CDF comes in. In my opinion, the component helpers or similar would be used with CDF in the beginning, because DRM doesn't support hotplug. Eventually we should get some kind of basic hotplug support, so that we could add display pipelines when they are ready. I need to ask Dave why he is so strongly opposed to hotplugging components. Remember that hotplugging in this context does not mean that the user can physically do something with the hardware. It means that they're separate devices which can be probed/removed at will. Every device in Linux can be bound and unbound from its driver at any time by userspace, and that is something which is expected to be handled gracefully. Hmm, sorry, can you rephrase? My use of hotplug in this context means roughly add a new display, and whatever is related to that, when the drivers required have been probed. So with hotplug, a new fbdev or a combination of drm crtcs, encoders, etc, could appear even after the initial probe of the display controller. But all this is, I think, a bit aside the original point. The original point was about DT bindings. What kind of framework we have in the kernel side to handle the bindings is an interesting and very important topic, but they are not strictly tied together. Even if CDF is the worst thing ever, and needs to die quickly, I think the proposed DT bindings are still valid. They describe the hardware as precisely and as future-proofly as we've been able to come up with. People can use component helpers with them if they see that's a good approach. Or if on some beautiful day we get an agreement on CDF or something similar, and we can support hotplugging components, we already have proper DT bindings for it. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output
On Wed, Feb 26, 2014 at 02:44:02PM +0200, Tomi Valkeinen wrote:
Also - DRM is not going to ever support hotplugging components - this
was discussed at kernel summit last year and David Airlie was quite
Ok. Very odd stance. Maybe there's a reason for it that I just don't see.
DRM is like ALSA - it's a card level subsystem. All components have
to be present before the card level is brought up for the subsystem to
function correctly.
adamant about that. So, any framework which forces hotplugging of
components on subsystems isn't going to fly.
CDF doesn't force hotplugging.
Although without hotplugging (hot-unplug not needed), or at least some
minimal form of it, the system is a bit crippled. Leave one kernel
module out, or have one driver probe fail, the whole display subsystem
fails, even if some display pipelines would work fine.
That is, unfortunately, one of the side effects of the policy - but that's
not a policy that's going to change any time soon. As I said, that was
made very clear at the last kernel summit - we had a /specific/ session
on the issues around multi-device DRM chaired by David.
There are some DRM drivers which have tried to do this, but they're all
buggy in some regard, whether that be to the point of oopsing the kernel
if things don't quite go to plan, or whether it's races between different
parts.
This is why we now have the component helpers in the driver model -
to allow devices to be collected together into one logical subsystem
group, and bound/unbound as a group.
Yep, it's a good start. The component helpers could well be used with CDF.
But if I'm not mistaken, it suffers from the problems above, when there
are multiple independent pipelines (simultaneous or non-simultaneous)
handled by the same IPs.
It may suffer from the problems above that you've raised, but that's
by explicit design of it - because that's what subsystems like DRM and
ALSA require, and this is _precisely_ the problem it's solving.
It's solving the subsystem requires a stable view of hardware components,
but we have multiple devices and drivers which need probing problem.
And, while I may be mistaken, it sounds that the component helpers leave
mostly everything up to the display drivers. Everyone devising their own
way to describe the hardware in DT, and the connections between the
components. Of course, the core component system shouldn't define
anything DT related, as it doesn't. But that part is still needed, which
is where CDF comes in.
Sigh. It's very easy for people to get the wrong end of the stick.
What the component helpers do is provide a _subsystem_ _independent_
method of collecting a set of devices together and binding them to the
drivers at an appropriate time, in a way that is _completely_ independent
of whether you're using platform data, DT, ACPI, or whatever other
hardware description language comes along.
It's up to the users of this to define how components are grouped
together, whether that be at the subsystem level or at the driver
level - whatever is appropriate.
If a subsystem (eg, a display subsystem) wants to define this is how
you define in DT the bindings between all components and provide its
own hook for the add_components callback which does this, then it's
at liberty to do that.
If we can come up with a generic way to describe how all the components
in a display subsystem should be connected together, then great - but
that needs to happen very quickly. Philipp Zabel is working on replacing
the imx-drm binding method right now for 3.15, and is probably completely
unaware of anything that's been talked about here. I need to sort out
Armada DRM at some point to use the component stuff, which includes
sorting out TDA998x for DT - which again needs to be done in such a way
that it follows a common theme.
I need to ask Dave why he is so strongly opposed to hotplugging components.
I suspect one reason for it is because it means rewriting the XF86
backend to Xorg to cope with it...
Remember that hotplugging in this context does not mean that the
user can physically do something with the hardware. It means that
they're separate devices which can be probed/removed at will. Every
device in Linux can be bound and unbound from its driver at any time
by userspace, and that is something which is expected to be handled
gracefully.
Hmm, sorry, can you rephrase?
I'll do better than that. Try running this script with the
/sys/bus/.../drivers/whatever for the drivers you wish to test:
#!/bin/sh
for driver in $@; do
if [ -f ${driver}/unbind ]; then
for device in ${driver}/*; do
if [ -d ${device} ]; then
devname=$(basename ${device})
echo $devname ${driver}/unbind
echo $devname ${driver}/bind
fi
done
fi
done
The system should survive that.
So with hotplug, a new fbdev or a combination of drm crtcs, encoders,
etc, could appear even after the
Re: [PATCH RESEND v10 0/7] mmc: omap_hsmmc: pbias dt and cleanup
Hi, On 02/19/2014 03:56 PM, Balaji T K wrote: Few cleanups to reduce code indent, Add pbias_regulator support and adapt omap_hsmmc to use pbias regulator to configure required voltage on mmc1 pad(SD card) i/o rails on OMAP SoCs. I tested on both OMAP3630 (Overo Storm) and OMAP4430 (DuoVero). The rootfs is mounted on mmc1 and works as usual. Here is what I can see: - pbias-supply is parsed from DT - VMMC1 is set to 3V - According to the debugfs entry, we are working at 3V signaling - By dumping CONTROL_PBIASLITE, bit MMC1_PBIASLITE_VMODE (PBIASLITEVMODE0 on OMAP3) is set to 1 (- 3V) Do you see any other tests that I could run to validate your patches? Otherwise: Tested-by: Florian Vaussard florian.vauss...@epfl.ch Balaji T K (7): mmc: omap_hsmmc: use devm_regulator API mmc: omap_hsmmc: handle vcc and vcc_aux independently regulator: add pbias regulator support mmc: omap_hsmmc: adapt hsmmc to use pbias regulator ARM: dts: add pbias dt node ARM: OMAP: enable SYSCON and REGULATOR_PBIAS in omap2plus_defconfig mmc: omap_hsmmc: remove pbias workaround .../bindings/regulator/pbias-regulator.txt | 27 ++ arch/arm/boot/dts/dra7.dtsi| 17 ++ arch/arm/boot/dts/omap2430.dtsi| 17 ++ arch/arm/boot/dts/omap3.dtsi | 17 ++ arch/arm/boot/dts/omap4.dtsi | 17 ++ arch/arm/boot/dts/omap5.dtsi | 17 ++ arch/arm/configs/omap2plus_defconfig |2 + drivers/mmc/host/omap_hsmmc.c | 111 + drivers/regulator/Kconfig |9 + drivers/regulator/Makefile |1 + drivers/regulator/pbias-regulator.c| 255 11 files changed, 441 insertions(+), 49 deletions(-) create mode 100644 Documentation/devicetree/bindings/regulator/pbias-regulator.txt create mode 100644 drivers/regulator/pbias-regulator.c -- 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 5/6] pwm: enable TI PWMSS if the IIO tiecap driver is selected
On Wed, Feb 05, 2014 at 02:01:40PM -0500, Matt Porter wrote: The IIO TI ECAP driver depends on the TI PWMSS management driver in this subsystem. Enable PWMSS when the IIO TI ECAP driver is selected. Signed-off-by: Matt Porter mpor...@linaro.org --- drivers/pwm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig index 22f2f28..bd3cc65 100644 --- a/drivers/pwm/Kconfig +++ b/drivers/pwm/Kconfig @@ -219,7 +219,7 @@ config PWM_TIEHRPWM config PWM_TIPWMSS bool - default y if SOC_AM33XX (PWM_TIECAP || PWM_TIEHRPWM) + default y if SOC_AM33XX (IIO_TIECAP || PWM_TIECAP || PWM_TIEHRPWM) help PWM Subsystem driver support for AM33xx SOC. Perhaps this module should move out of drivers/pwm if it's no longer a PWM specific module. Thierry pgpdSQvc3sF6U.pgp Description: PGP signature
Re: [PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output
On 26/02/14 15:28, Russell King - ARM Linux wrote:
On Wed, Feb 26, 2014 at 02:44:02PM +0200, Tomi Valkeinen wrote:
Also - DRM is not going to ever support hotplugging components - this
was discussed at kernel summit last year and David Airlie was quite
Ok. Very odd stance. Maybe there's a reason for it that I just don't see.
DRM is like ALSA - it's a card level subsystem. All components have
to be present before the card level is brought up for the subsystem to
function correctly.
Well, yes, at the moment. I don't know what his message was, but if it
was DRM won't get hotplug, even if someone would do it properly, that
sounds just silly.
But if I'm not mistaken, it suffers from the problems above, when there
are multiple independent pipelines (simultaneous or non-simultaneous)
handled by the same IPs.
It may suffer from the problems above that you've raised, but that's
by explicit design of it - because that's what subsystems like DRM and
ALSA require, and this is _precisely_ the problem it's solving.
It's solving the subsystem requires a stable view of hardware components,
but we have multiple devices and drivers which need probing problem.
And that's good. What I'd like to avoid is developers using the
component helpers, and designing the DT just for that use case,
preventing the use of a possible future framework.
The example in your component helper commit:
imx-drm {
compatible = fsl,drm;
crtcs = ipu1;
connectors = hdmi;
};
How would that be extended if one imx board has an external HDMI
encoder? Or maybe the board has an external HDMI encoder, and also a
separate level-shifter/ESD chip like some OMAP boards have. Or maybe a
board has two displays connected to one imx LCD output, and a GPIO is
used to switch between the used display.
Rephrasing: How would those DT bindings be extended to allow arbitrarily
long or complex display pipelines?
The proposed OMAP DSS and CDF DT bindings try to allow all the above cases.
So in my opinion, using component helpers is good, but it'd be important
to make sure the DT bindings for all platforms are future proof, and
also compatible so that we can share encoder/panel drivers.
And, while I may be mistaken, it sounds that the component helpers leave
mostly everything up to the display drivers. Everyone devising their own
way to describe the hardware in DT, and the connections between the
components. Of course, the core component system shouldn't define
anything DT related, as it doesn't. But that part is still needed, which
is where CDF comes in.
Sigh. It's very easy for people to get the wrong end of the stick.
What the component helpers do is provide a _subsystem_ _independent_
method of collecting a set of devices together and binding them to the
drivers at an appropriate time, in a way that is _completely_ independent
of whether you're using platform data, DT, ACPI, or whatever other
hardware description language comes along.
Yep, that's what I meant with Of course, the core component system
shouldn't define anything DT related, as it doesn't.. Maybe that's not
even English, so my bad =).
It's up to the users of this to define how components are grouped
together, whether that be at the subsystem level or at the driver
level - whatever is appropriate.
If a subsystem (eg, a display subsystem) wants to define this is how
you define in DT the bindings between all components and provide its
own hook for the add_components callback which does this, then it's
at liberty to do that.
If we can come up with a generic way to describe how all the components
in a display subsystem should be connected together, then great - but
that needs to happen very quickly. Philipp Zabel is working on replacing
the imx-drm binding method right now for 3.15, and is probably completely
unaware of anything that's been talked about here. I need to sort out
Yes, I just pinged him a few hours ago about this. I've been ill for a
few weeks, so I'm catching up on emails, but I want to sync with him
asap to see if the OMAP DSS side and his imx series have things in common.
Armada DRM at some point to use the component stuff, which includes
sorting out TDA998x for DT - which again needs to be done in such a way
that it follows a common theme.
BeagleBoneBlack has TDA998x, so I'm also very interested in that.
So with hotplug, a new fbdev or a combination of drm crtcs, encoders,
etc, could appear even after the initial probe of the display controller.
This is the exact situation that David is opposed to. DRM, like ALSA,
whats to have a stable view of hardware - once the drm_device has been
created and probed, no further changes to it are allowed.
Certainly no changes to the CRTCs will _ever_ be permitted, because it
completely destroys the user API for referecing which encoders can be
associated with which CRTCs - not only at the kernel level, but
Re: [PATCH RESEND v10 0/7] mmc: omap_hsmmc: pbias dt and cleanup
On Wednesday 26 February 2014 07:34 PM, Florian Vaussard wrote: Hi, On 02/19/2014 03:56 PM, Balaji T K wrote: Few cleanups to reduce code indent, Add pbias_regulator support and adapt omap_hsmmc to use pbias regulator to configure required voltage on mmc1 pad(SD card) i/o rails on OMAP SoCs. I tested on both OMAP3630 (Overo Storm) and OMAP4430 (DuoVero). The rootfs is mounted on mmc1 and works as usual. Here is what I can see: - pbias-supply is parsed from DT - VMMC1 is set to 3V - According to the debugfs entry, we are working at 3V signaling - By dumping CONTROL_PBIASLITE, bit MMC1_PBIASLITE_VMODE (PBIASLITEVMODE0 on OMAP3) is set to 1 (- 3V) Do you see any other tests that I could run to validate your patches? Nope, Stefan has tested the other use case of detecting sd card at kernel without any sd card/pbias activity at u-boot. Otherwise: Tested-by: Florian Vaussard florian.vauss...@epfl.ch Thanks Florian, Stefan for Testing. -- 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: [PATCHv2 02/16] iommu/omap: omap_iommu_attach() should return ENODEV, not NULL
Hi Laurent,
On Tuesday 25 February 2014 16:32:03 Suman Anna wrote:
On 02/25/2014 03:13 PM, Laurent Pinchart wrote:
On Thursday 13 February 2014 12:15:33 Suman Anna wrote:
From: Florian Vaussard florian.vauss...@epfl.ch
omap_iommu_attach() returns NULL or ERR_PTR in case of error, but
omap_iommu_attach_dev() only checks for IS_ERR. Thus a NULL return value
(in case driver_find_device fails) will cause the kernel to panic when
omap_iommu_attach_dev() dereferences the pointer.
In such case, omap_iommu_attach() should return ENODEV, not NULL.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
Acked-by: Suman Anna s-a...@ti.com
---
drivers/iommu/omap-iommu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index fff2ffd..6272c36 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -863,7 +863,7 @@ static int device_match_by_alias(struct device *dev,
void *data) **/
static struct omap_iommu *omap_iommu_attach(const char *name, u32
*iopgd)
{
- int err = -ENOMEM;
+ int err = -ENODEV;
struct device *dev;
struct omap_iommu *obj;
@@ -871,7 +871,7 @@ static struct omap_iommu *omap_iommu_attach(const
char *name, u32 *iopgd)
(void *)name,
device_match_by_alias);
if (!dev)
- return NULL;
+ return ERR_PTR(err);
I would return ERR_PTR(-ENODEV) here, and remove the initialization at
declaration of err above.
The initialization at the beginning is also serving one another exit
path (a check for try_module_get), where err is not being set. If the
initialization is removed, then the err has to be set explicitly at the
other place. Let me know if you still want this changed.
The return value of iommu_enable() is unconditionally stored in err before the
try_module_get() call, so that code patch is buggy anyway and should be fixed.
I would still remove the initialization at declaration and assign -ENODEV to
err explicitly when try_module_get() fails before the goto err_module.
OK, I will fix this up.
regards
Suman
--
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 RESEND v11 6/7] ARM: OMAP: enable SYSCON and REGULATOR_PBIAS in omap2plus_defconfig
* Balaji T K balaj...@ti.com [140219 07:00]: Enable REGULATOR_PBIAS needed for SD card on most OMAPs. Signed-off-by: Balaji T K balaj...@ti.com I belive this is the only one missing my ack: Acked-by: Tony Lindgren t...@atomide.com Probably best that this all gets queued along with other MMC related patches by Balaji and Chris. --- arch/arm/configs/omap2plus_defconfig |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 3a0b53d..e4fec1c 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -169,6 +169,7 @@ CONFIG_DRA752_THERMAL=y CONFIG_WATCHDOG=y CONFIG_OMAP_WATCHDOG=y CONFIG_TWL4030_WATCHDOG=y +CONFIG_MFD_SYSCON=y CONFIG_MFD_PALMAS=y CONFIG_MFD_TPS65217=y CONFIG_MFD_TPS65910=y @@ -180,6 +181,7 @@ CONFIG_REGULATOR_TPS6507X=y CONFIG_REGULATOR_TPS65217=y CONFIG_REGULATOR_TPS65910=y CONFIG_REGULATOR_TWL4030=y +CONFIG_REGULATOR_PBIAS=y CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_MODE_HELPERS=y -- 1.7.5.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 -- 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: SD card timeout problems on Nokia N900 (omap_hsmmc on OMAP3)
* Balaji T K balaj...@ti.com [140226 00:48]: On Wednesday 26 February 2014 12:25 PM, Stefan Roese wrote: Hi Sebastian, On 26.02.2014 07:02, Michael Trimarchi wrote: Hi Sebastian On Wed, Feb 26, 2014 at 12:47 AM, Sebastian Reichel s...@ring0.de wrote: Hi, I have problems with the SD-card initialization on my Nokia N900 using a 3.14-rc1 based kernel in DT boot mode. The bug is can be circumvented by changing the kernel slightly (e.g. remove some DT nodes or mark them as disabled). So the SD card's timeout problems seem to derive from kernel timing problems. I'm pretty sure, that the problems are not originating from a broken SD card, since Can you provide removed/Disabled dt nodes, it might give some clue ? 1. The SD card worked quite good before and still does depending on unrelated DTS changes (= loading less drivers). 2. The SD card works flawlessly on my notebook using a USB adapter 3. Another SD card showed the same problem I tried to git bisect the problem, but I just get shown some unrelated driver additions. Anyways, this is the error I get during boot: [3.896820] mmc0: mmc_rescan_try_freq: trying to init card at 40 Hz ... [5.956237] mmc0: error -110 whilst initialising SD card Are you sure that some subsystem that you deactivate don't change pin muxing setting? Can you check in the broken system if the pins of the sdcard are correctly muxed? Does it happen even if you change the sdcard? Did you try to add this patch series: http://www.spinics.net/lists/linux-omap/msg103264.html Without it I'm also having problems with MMC detection on some OMAP3 based boards. Balaji, what is the status of this patch series? Are there any chances that it will be included in v3.14? Due to dependencies between regulator, mmc, omap def config, devicetree changes, I am hoping either Chris or Tony pick the whole series for 3.15 Best that Chris takes it all, I just acked the only patch that did not have my ack yet. Couple of tested-by will surely help. Yeah please ack in the thread above if you did not already. 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 08/26] arm: Replace various irq_desc accesses
* Shawn Guo shawn@linaro.org [140223 18:58]: On Sun, Feb 23, 2014 at 09:40:12PM -, Thomas Gleixner wrote: Use the proper functions. There is no need to fiddle with irq_desc. Signed-off-by: Thomas Gleixner t...@linutronix.de Cc: Shawn Guo shawn@linaro.org ... arch/arm/mach-imx/pm-imx6q.c|7 +++ Acked-by: Shawn Guo shawn@linaro.org Acked-by: Tony Lindgren t...@atomide.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
Re: [PATCHv2 04/16] iommu/omap: add devicetree support
* Suman Anna s-a...@ti.com [140213 10:19]:
From: Florian Vaussard florian.vauss...@epfl.ch
As OMAP2+ is moving to a full DT boot for all SoC families, commit
7ce93f3 ARM: OMAP2+: Fix more missing data for omap3.dtsi file
adds basic DT bits for OMAP3. But the driver is not yet converted,
so this will not work and driver will not be probed. Convert it!
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
[s-a...@ti.com: dev_name adaptation and improved error checking]
Signed-off-by: Suman Anna s-a...@ti.com
Best that this gets merged along with the other iommu patches, so
for the arch/arm/*omap* parts:
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/omap-iommu.c | 5 +
drivers/iommu/omap-iommu.c | 41
2 files changed, 42 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-iommu.c
b/arch/arm/mach-omap2/omap-iommu.c
index f6daae8..f1fab56 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -10,6 +10,7 @@
* published by the Free Software Foundation.
*/
+#include linux/of.h
#include linux/module.h
#include linux/platform_device.h
#include linux/err.h
@@ -58,6 +59,10 @@ static int __init omap_iommu_dev_init(struct omap_hwmod
*oh, void *unused)
static int __init omap_iommu_init(void)
{
+ /* If dtb is there, the devices will be created dynamically */
+ if (of_have_populated_dt())
+ return -ENODEV;
+
return omap_hwmod_for_each_by_class(mmu, omap_iommu_dev_init, NULL);
}
/* must be ready before omap3isp is probed */
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 6272c36..4329ab1 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -23,6 +23,9 @@
#include linux/spinlock.h
#include linux/io.h
#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_iommu.h
+#include linux/of_irq.h
#include asm/cacheflush.h
@@ -937,20 +940,41 @@ static int omap_iommu_probe(struct platform_device
*pdev)
{
int err = -ENODEV;
int irq;
+ size_t len;
struct omap_iommu *obj;
struct resource *res;
struct iommu_platform_data *pdata = pdev-dev.platform_data;
+ struct device_node *of = pdev-dev.of_node;
obj = devm_kzalloc(pdev-dev, sizeof(*obj) + MMU_REG_SIZE, GFP_KERNEL);
if (!obj)
return -ENOMEM;
- obj-nr_tlb_entries = pdata-nr_tlb_entries;
- obj-name = pdata-name;
+ if (of) {
+ obj-name = dev_name(pdev-dev);
+ obj-nr_tlb_entries = 32;
+ err = of_property_read_u32(of, ti,#tlb-entries,
+obj-nr_tlb_entries);
+ if (err err != -EINVAL)
+ return err;
+ if (obj-nr_tlb_entries != 32 obj-nr_tlb_entries != 8)
+ return -EINVAL;
+ err = of_get_dma_window(of, NULL, 0, NULL, obj-da_start,
+ len);
+ if (err != 0)
+ return err;
+ obj-da_end = obj-da_start + len;
+ } else {
+ obj-nr_tlb_entries = pdata-nr_tlb_entries;
+ obj-name = pdata-name;
+ obj-da_start = pdata-da_start;
+ obj-da_end = pdata-da_end;
+ }
+ if (obj-da_end = obj-da_start)
+ return -EINVAL;
+
obj-dev = pdev-dev;
obj-ctx = (void *)obj + sizeof(*obj);
- obj-da_start = pdata-da_start;
- obj-da_end = pdata-da_end;
spin_lock_init(obj-iommu_lock);
mutex_init(obj-mmap_lock);
@@ -991,11 +1015,20 @@ static int omap_iommu_remove(struct platform_device
*pdev)
return 0;
}
+static struct of_device_id omap_iommu_of_match[] = {
+ { .compatible = ti,omap2-iommu },
+ { .compatible = ti,omap4-iommu },
+ { .compatible = ti,dra7-iommu },
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap_iommu_of_match);
+
static struct platform_driver omap_iommu_driver = {
.probe = omap_iommu_probe,
.remove = omap_iommu_remove,
.driver = {
.name = omap-iommu,
+ .of_match_table = of_match_ptr(omap_iommu_of_match),
},
};
--
1.8.5.3
--
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: [PATCHv2 08/16] ARM: OMAP3: remove deprecated CONFIG_OMAP_IOMMU_IVA2
* Laurent Pinchart laurent.pinch...@ideasonboard.com [140225 13:18]: On Thursday 13 February 2014 12:15:39 Suman Anna wrote: From: Florian Vaussard florian.vauss...@epfl.ch CONFIG_OMAP_IOMMU_IVA2 was defined originally to avoid conflicting usage by tidspbridge and other iommu users. The same can be achieved by marking the DT node disabled, so remove this obsolete flag and the corresponding hwmod data can be enabled. Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch [s-a...@ti.com: revise commit log] Signed-off-by: Suman Anna s-a...@ti.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Tony Lindgren t...@atomide.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
Re: [PATCHv2 03/16] Documentation: dt: add OMAP iommu bindings
Hi Laurent,
On 02/25/2014 08:13 PM, Laurent Pinchart wrote:
Hi Suman,
On Tuesday 25 February 2014 17:02:35 Suman Anna wrote:
On 02/25/2014 03:26 PM, Laurent Pinchart wrote:
On Thursday 13 February 2014 12:15:34 Suman Anna wrote:
From: Florian Vaussard florian.vauss...@epfl.ch
This patch adds the iommu bindings for all OMAP2+ SoCs. Apart from
the standard bindings used by OMAP peripherals, this patch uses a
'dma-window' (already used by Tegra SMMU) and adds two OMAP custom
bindings - 'ti,#tlb-entries' and 'ti,iommu-bus-err-back'.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
[s-a...@ti.com: split bindings document, add dra7 and bus error back]
Signed-off-by: Suman Anna s-a...@ti.com
---
.../devicetree/bindings/iommu/ti,omap-iommu.txt| 28
+++
1 file changed, 28 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
diff --git a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt new file mode
100644
index 000..116492d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
@@ -0,0 +1,28 @@
+OMAP2+ IOMMU
+
+Required properties:
+- compatible : Should be one of,
+ ti,omap2-iommu for OMAP2/OMAP3 IOMMU instances
+ ti,omap4-iommu for OMAP4/OMAP5 IOMMU instances
+ ti,dra7-iommu for DRA7xx IOMMU instances
+- ti,hwmods : Name of the hwmod associated with the IOMMU instance
+- reg: Address space for the configuration registers
+- interrupts : Interrupt specifier for the IOMMU instance
+- dma-window : IOVA start address and length
Isn't the dma window more of a system configuration property than a
hardware property ? How do you expect it to be set?
We are setting it based on the addressable range for the MMU.
A quick look at the ISP and IVA IOMMUs in the OMAP3 shows that both support
the full 4GB VA space. Why do you need to restrict it ?
I should have rephrased it better when I said addressable range. While
the MMUs are capable of programming the full 4GB space, there are some
address ranges that are private from the processor view. This window is
currently used to set the range for the omap-iovmm driver (which only
OMAP3 ISP is using atm), and there is no point in allowing the
omap-iovmm driver the full range when the processor could never
reach/access those addresses.
We are reusing the existing defined property and it allows us to get rid of
the IOVA start and end addresses defined in the pre-DT OMAP iommu platform
data.
+Optional properties:
+- ti,#tlb-entries : Number of entries in the translation look-aside
buffer. +Should be either 8 or 32 (default: 32)
+- ti,iommu-bus-err-back : Indicates the IOMMU instance supports throwing
+ back a bus error response on MMU faults.
Do these features vary per IOMMU instance or per IOMMU model ? In the
latter case they could be inferred from the compatible string by the
driver without requiring them to be explicit in DT (whether you want to
do so is left to you though).
Well, these are fixed features given an IOMMU instance, like the OMAP3
ISP is the only one that has 8 TLB entries, all the remaining ones have
32, and the IPU iommu instances are the only ones that support the bus
error response back. I have no preference to any particular way, and
sure the driver can infer these easily based on unique compatible
strings per subsystem per SoC. I just happened to go with defining
compatible strings per SoC, with the optional properties differentiating
the fixed behavior between different IOMMU instances on that SoC. This
is where I was looking for some inputs/guidance from the DT bindings
maintainers on what is the preferred method.
I think you've made the right choice. I wasn't sure whether those parameters
varied across IOMMU instances of compatible devices (from a compatible string
point of view) or were constant. As they vary they should be expressed in DT.
Yeah, I wasn't sure if these qualify as features (as per
Documentation/devicetree/bindings/ABI.txt section II.2).
regards
Suman
+Example:
+ /* OMAP3 ISP MMU */
+ mmu_isp: mmu@480bd400 {
+ compatible = ti,omap2-iommu;
+ reg = 0x480bd400 0x80;
+ interrupts = 24;
+ ti,hwmods = mmu_isp;
+ ti,#tlb-entries = 8;
+ dma-window = 0 0xf000;
+ };
--
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: [PATCHv2 08/16] ARM: OMAP3: remove deprecated CONFIG_OMAP_IOMMU_IVA2
* Laurent Pinchart laurent.pinch...@ideasonboard.com [140225 13:18]: On Thursday 13 February 2014 12:15:39 Suman Anna wrote: From: Florian Vaussard florian.vauss...@epfl.ch CONFIG_OMAP_IOMMU_IVA2 was defined originally to avoid conflicting usage by tidspbridge and other iommu users. The same can be achieved by marking the DT node disabled, so remove this obsolete flag and the corresponding hwmod data can be enabled. Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch [s-a...@ti.com: revise commit log] Signed-off-by: Suman Anna s-a...@ti.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Tony Lindgren t...@atomide.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
Re: [PATCHv2 10/16] ARM: OMAP2+: use pdata quirks for iommu reset lines
* Suman Anna s-a...@ti.com [140213 10:19]:
The OMAP iommu driver performs the reset management for the
iommu instances in processor sub-systems using the omap_device
API which are currently supplied as platform data ops. Use pdata
quirks to maintain the functionality as the OMAP iommu driver
gets converted to use DT nodes, until the reset portions are
decoupled from omap_hwmod/omap_device into a separate reset
driver.
This patch adds the pdata quirks for the reset management of
iommus within the DSP (OMAP3 OMAP4) and IPU subsystems (OMAP4).
Signed-off-by: Suman Anna s-a...@ti.com
Looks OK, but I suggest you separate out the remaining patches in
this series into another clean-up series. Then the clean-up series
can be merged later on as these have a good chance of conflicting
with other stuff.
Tony
---
arch/arm/mach-omap2/pdata-quirks.c | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index 3d5b24d..74e094a 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -16,12 +16,14 @@
#include linux/wl12xx.h
#include linux/platform_data/pinctrl-single.h
+#include linux/platform_data/iommu-omap.h
#include am35xx.h
#include common.h
#include common-board-devices.h
#include dss-common.h
#include control.h
+#include omap_device.h
struct pdata_init {
const char *compatible;
@@ -92,6 +94,12 @@ static void __init hsmmc2_internal_input_clk(void)
omap_ctrl_writel(reg, OMAP343X_CONTROL_DEVCONF1);
}
+static struct iommu_platform_data omap3_iommu_pdata = {
+ .reset_name = mmu,
+ .assert_reset = omap_device_assert_hardreset,
+ .deassert_reset = omap_device_deassert_hardreset,
+};
+
static int omap3_sbc_t3730_twl_callback(struct device *dev,
unsigned gpio,
unsigned ngpio)
@@ -185,6 +193,12 @@ static void __init omap4_panda_legacy_init(void)
legacy_init_ehci_clk(auxclk3_ck);
legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 53);
}
+
+static struct iommu_platform_data omap4_iommu_pdata = {
+ .reset_name = mmu_cache,
+ .assert_reset = omap_device_assert_hardreset,
+ .deassert_reset = omap_device_deassert_hardreset,
+};
#endif
#ifdef CONFIG_SOC_OMAP5
@@ -240,6 +254,8 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
#ifdef CONFIG_ARCH_OMAP3
OF_DEV_AUXDATA(ti,omap3-padconf, 0x48002030, 48002030.pinmux,
pcs_pdata),
OF_DEV_AUXDATA(ti,omap3-padconf, 0x48002a00, 48002a00.pinmux,
pcs_pdata),
+ OF_DEV_AUXDATA(ti,omap2-iommu, 0x5d00, 5d00.mmu,
+omap3_iommu_pdata),
/* Only on am3517 */
OF_DEV_AUXDATA(ti,davinci_mdio, 0x5c03, davinci_mdio.0, NULL),
OF_DEV_AUXDATA(ti,am3517-emac, 0x5c00, davinci_emac.0,
@@ -248,6 +264,10 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata =
{
#ifdef CONFIG_ARCH_OMAP4
OF_DEV_AUXDATA(ti,omap4-padconf, 0x4a100040, 4a100040.pinmux,
pcs_pdata),
OF_DEV_AUXDATA(ti,omap4-padconf, 0x4a31e040, 4a31e040.pinmux,
pcs_pdata),
+ OF_DEV_AUXDATA(ti,omap4-iommu, 0x4a066000, 4a066000.mmu,
+omap4_iommu_pdata),
+ OF_DEV_AUXDATA(ti,omap4-iommu, 0x55082000, 55082000.mmu,
+omap4_iommu_pdata),
#endif
{ /* sentinel */ },
};
--
1.8.5.3
--
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: [PATCHv2 14/16] ARM: OMAP3: hwmod data: cleanup data for IOMMUs
* Suman Anna s-a...@ti.com [140213 10:19]:
From: Florian Vaussard florian.vauss...@epfl.ch
The irq numbers, ocp address space and device attribute data
have all been cleaned up for OMAP3 IOMMUs. All this data is
populated via the corresponding dt node.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
Signed-off-by: Suman Anna s-a...@ti.com
This will need to wait until we've made omap3 to be DT only
as this will break idling of things for the legacy booting.
Regards,
Tony
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 46
--
1 file changed, 46 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 9c7e23a..d68c131 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -24,7 +24,6 @@
#include l4_3xxx.h
#include linux/platform_data/asoc-ti-mcbsp.h
#include linux/platform_data/spi-omap2-mcspi.h
-#include linux/platform_data/iommu-omap.h
#include linux/platform_data/mailbox-omap.h
#include plat/dmtimer.h
@@ -2991,83 +2990,39 @@ static struct omap_hwmod_class
omap3xxx_mmu_hwmod_class = {
/* mmu isp */
-static struct omap_mmu_dev_attr mmu_isp_dev_attr = {
- .da_start = 0x0,
- .da_end = 0xf000,
- .nr_tlb_entries = 8,
-};
-
static struct omap_hwmod omap3xxx_mmu_isp_hwmod;
-static struct omap_hwmod_irq_info omap3xxx_mmu_isp_irqs[] = {
- { .irq = 24 + OMAP_INTC_START, },
- { .irq = -1 }
-};
-
-static struct omap_hwmod_addr_space omap3xxx_mmu_isp_addrs[] = {
- {
- .pa_start = 0x480bd400,
- .pa_end = 0x480bd47f,
- .flags = ADDR_TYPE_RT,
- },
- { }
-};
/* l4_core - mmu isp */
static struct omap_hwmod_ocp_if omap3xxx_l4_core__mmu_isp = {
.master = omap3xxx_l4_core_hwmod,
.slave = omap3xxx_mmu_isp_hwmod,
- .addr = omap3xxx_mmu_isp_addrs,
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
static struct omap_hwmod omap3xxx_mmu_isp_hwmod = {
.name = mmu_isp,
.class = omap3xxx_mmu_hwmod_class,
- .mpu_irqs = omap3xxx_mmu_isp_irqs,
.main_clk = cam_ick,
- .dev_attr = mmu_isp_dev_attr,
.flags = HWMOD_NO_IDLEST,
};
/* mmu iva */
-static struct omap_mmu_dev_attr mmu_iva_dev_attr = {
- .da_start = 0x1100,
- .da_end = 0xf000,
- .nr_tlb_entries = 32,
-};
-
static struct omap_hwmod omap3xxx_mmu_iva_hwmod;
-static struct omap_hwmod_irq_info omap3xxx_mmu_iva_irqs[] = {
- { .irq = 28 + OMAP_INTC_START, },
- { .irq = -1 }
-};
-
static struct omap_hwmod_rst_info omap3xxx_mmu_iva_resets[] = {
{ .name = mmu, .rst_shift = 1, .st_shift = 9 },
};
-static struct omap_hwmod_addr_space omap3xxx_mmu_iva_addrs[] = {
- {
- .pa_start = 0x5d00,
- .pa_end = 0x5d7f,
- .flags = ADDR_TYPE_RT,
- },
- { }
-};
-
/* l3_main - iva mmu */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__mmu_iva = {
.master = omap3xxx_l3_main_hwmod,
.slave = omap3xxx_mmu_iva_hwmod,
- .addr = omap3xxx_mmu_iva_addrs,
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
static struct omap_hwmod omap3xxx_mmu_iva_hwmod = {
.name = mmu_iva,
.class = omap3xxx_mmu_hwmod_class,
- .mpu_irqs = omap3xxx_mmu_iva_irqs,
.clkdm_name = iva2_clkdm,
.rst_lines = omap3xxx_mmu_iva_resets,
.rst_lines_cnt = ARRAY_SIZE(omap3xxx_mmu_iva_resets),
@@ -3080,7 +3035,6 @@ static struct omap_hwmod omap3xxx_mmu_iva_hwmod = {
.idlest_idle_bit = OMAP3430_ST_IVA2_SHIFT,
},
},
- .dev_attr = mmu_iva_dev_attr,
.flags = HWMOD_NO_IDLEST,
};
--
1.8.5.3
--
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: [PATCHv2 14/16] ARM: OMAP3: hwmod data: cleanup data for IOMMUs
Tony,
On 02/26/2014 11:18 AM, Tony Lindgren wrote:
* Suman Anna s-a...@ti.com [140213 10:19]:
From: Florian Vaussard florian.vauss...@epfl.ch
The irq numbers, ocp address space and device attribute data
have all been cleaned up for OMAP3 IOMMUs. All this data is
populated via the corresponding dt node.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
Signed-off-by: Suman Anna s-a...@ti.com
This will need to wait until we've made omap3 to be DT only
as this will break idling of things for the legacy booting.
OK, will drop this and I will adjust Patch 9 to support the legacy boot
for OMAP3 ISP.
regards
Suman
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 46 --
1 file changed, 46 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 9c7e23a..d68c131 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -24,7 +24,6 @@
#include l4_3xxx.h
#include linux/platform_data/asoc-ti-mcbsp.h
#include linux/platform_data/spi-omap2-mcspi.h
-#include linux/platform_data/iommu-omap.h
#include linux/platform_data/mailbox-omap.h
#include plat/dmtimer.h
@@ -2991,83 +2990,39 @@ static struct omap_hwmod_class omap3xxx_mmu_hwmod_class
= {
/* mmu isp */
-static struct omap_mmu_dev_attr mmu_isp_dev_attr = {
- .da_start = 0x0,
- .da_end = 0xf000,
- .nr_tlb_entries = 8,
-};
-
static struct omap_hwmod omap3xxx_mmu_isp_hwmod;
-static struct omap_hwmod_irq_info omap3xxx_mmu_isp_irqs[] = {
- { .irq = 24 + OMAP_INTC_START, },
- { .irq = -1 }
-};
-
-static struct omap_hwmod_addr_space omap3xxx_mmu_isp_addrs[] = {
- {
- .pa_start = 0x480bd400,
- .pa_end = 0x480bd47f,
- .flags = ADDR_TYPE_RT,
- },
- { }
-};
/* l4_core - mmu isp */
static struct omap_hwmod_ocp_if omap3xxx_l4_core__mmu_isp = {
.master = omap3xxx_l4_core_hwmod,
.slave = omap3xxx_mmu_isp_hwmod,
- .addr = omap3xxx_mmu_isp_addrs,
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
static struct omap_hwmod omap3xxx_mmu_isp_hwmod = {
.name = mmu_isp,
.class = omap3xxx_mmu_hwmod_class,
- .mpu_irqs = omap3xxx_mmu_isp_irqs,
.main_clk = cam_ick,
- .dev_attr = mmu_isp_dev_attr,
.flags = HWMOD_NO_IDLEST,
};
/* mmu iva */
-static struct omap_mmu_dev_attr mmu_iva_dev_attr = {
- .da_start = 0x1100,
- .da_end = 0xf000,
- .nr_tlb_entries = 32,
-};
-
static struct omap_hwmod omap3xxx_mmu_iva_hwmod;
-static struct omap_hwmod_irq_info omap3xxx_mmu_iva_irqs[] = {
- { .irq = 28 + OMAP_INTC_START, },
- { .irq = -1 }
-};
-
static struct omap_hwmod_rst_info omap3xxx_mmu_iva_resets[] = {
{ .name = mmu, .rst_shift = 1, .st_shift = 9 },
};
-static struct omap_hwmod_addr_space omap3xxx_mmu_iva_addrs[] = {
- {
- .pa_start = 0x5d00,
- .pa_end = 0x5d7f,
- .flags = ADDR_TYPE_RT,
- },
- { }
-};
-
/* l3_main - iva mmu */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__mmu_iva = {
.master = omap3xxx_l3_main_hwmod,
.slave = omap3xxx_mmu_iva_hwmod,
- .addr = omap3xxx_mmu_iva_addrs,
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
static struct omap_hwmod omap3xxx_mmu_iva_hwmod = {
.name = mmu_iva,
.class = omap3xxx_mmu_hwmod_class,
- .mpu_irqs = omap3xxx_mmu_iva_irqs,
.clkdm_name = iva2_clkdm,
.rst_lines = omap3xxx_mmu_iva_resets,
.rst_lines_cnt = ARRAY_SIZE(omap3xxx_mmu_iva_resets),
@@ -3080,7 +3035,6 @@ static struct omap_hwmod omap3xxx_mmu_iva_hwmod = {
.idlest_idle_bit = OMAP3430_ST_IVA2_SHIFT,
},
},
- .dev_attr = mmu_iva_dev_attr,
.flags = HWMOD_NO_IDLEST,
};
--
1.8.5.3
--
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: [PATCHv2 10/16] ARM: OMAP2+: use pdata quirks for iommu reset lines
Hi Tony,
On 02/26/2014 11:17 AM, Tony Lindgren wrote:
* Suman Anna s-a...@ti.com [140213 10:19]:
The OMAP iommu driver performs the reset management for the
iommu instances in processor sub-systems using the omap_device
API which are currently supplied as platform data ops. Use pdata
quirks to maintain the functionality as the OMAP iommu driver
gets converted to use DT nodes, until the reset portions are
decoupled from omap_hwmod/omap_device into a separate reset
driver.
This patch adds the pdata quirks for the reset management of
iommus within the DSP (OMAP3 OMAP4) and IPU subsystems (OMAP4).
Signed-off-by: Suman Anna s-a...@ti.com
Looks OK, but I suggest you separate out the remaining patches in
this series into another clean-up series. Then the clean-up series
can be merged later on as these have a good chance of conflicting
with other stuff.
Only patches 14 through 16 are cleanup patches. Patches 12 and 13 are
adding OMAP5 functionality, and Patch11 is fixing up OMAP3 IVA. I would
have to drop Patch14 and Patch16 until OMAP3 is completely DT, so will
drop them for now. Let me know if you want me to split out the remaining
applicable patches that are in arch/arm/ into a separate series.
regards
Suman
Tony
---
arch/arm/mach-omap2/pdata-quirks.c | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index 3d5b24d..74e094a 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -16,12 +16,14 @@
#include linux/wl12xx.h
#include linux/platform_data/pinctrl-single.h
+#include linux/platform_data/iommu-omap.h
#include am35xx.h
#include common.h
#include common-board-devices.h
#include dss-common.h
#include control.h
+#include omap_device.h
struct pdata_init {
const char *compatible;
@@ -92,6 +94,12 @@ static void __init hsmmc2_internal_input_clk(void)
omap_ctrl_writel(reg, OMAP343X_CONTROL_DEVCONF1);
}
+static struct iommu_platform_data omap3_iommu_pdata = {
+ .reset_name = mmu,
+ .assert_reset = omap_device_assert_hardreset,
+ .deassert_reset = omap_device_deassert_hardreset,
+};
+
static int omap3_sbc_t3730_twl_callback(struct device *dev,
unsigned gpio,
unsigned ngpio)
@@ -185,6 +193,12 @@ static void __init omap4_panda_legacy_init(void)
legacy_init_ehci_clk(auxclk3_ck);
legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 53);
}
+
+static struct iommu_platform_data omap4_iommu_pdata = {
+ .reset_name = mmu_cache,
+ .assert_reset = omap_device_assert_hardreset,
+ .deassert_reset = omap_device_deassert_hardreset,
+};
#endif
#ifdef CONFIG_SOC_OMAP5
@@ -240,6 +254,8 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
#ifdef CONFIG_ARCH_OMAP3
OF_DEV_AUXDATA(ti,omap3-padconf, 0x48002030, 48002030.pinmux,
pcs_pdata),
OF_DEV_AUXDATA(ti,omap3-padconf, 0x48002a00, 48002a00.pinmux,
pcs_pdata),
+ OF_DEV_AUXDATA(ti,omap2-iommu, 0x5d00, 5d00.mmu,
+ omap3_iommu_pdata),
/* Only on am3517 */
OF_DEV_AUXDATA(ti,davinci_mdio, 0x5c03, davinci_mdio.0, NULL),
OF_DEV_AUXDATA(ti,am3517-emac, 0x5c00, davinci_emac.0,
@@ -248,6 +264,10 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
#ifdef CONFIG_ARCH_OMAP4
OF_DEV_AUXDATA(ti,omap4-padconf, 0x4a100040, 4a100040.pinmux,
pcs_pdata),
OF_DEV_AUXDATA(ti,omap4-padconf, 0x4a31e040, 4a31e040.pinmux,
pcs_pdata),
+ OF_DEV_AUXDATA(ti,omap4-iommu, 0x4a066000, 4a066000.mmu,
+ omap4_iommu_pdata),
+ OF_DEV_AUXDATA(ti,omap4-iommu, 0x55082000, 55082000.mmu,
+ omap4_iommu_pdata),
#endif
{ /* sentinel */ },
};
--
1.8.5.3
--
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: Help running latest linux-omap kernel on Nokia N810
Hi, On Wed, Feb 26, 2014 at 06:24:36PM +, Leigh Brown wrote: I have built the latest linux-omap git tree for my N810 but when I boot it I get a black screen with the backlight on. Does anyone have a working .config that they could share with me? During my investigations I have discovered that the kernel configuration has changed enormously in the last couple of years. I was worried that the N810 was no longer supported at allm especially when I saw that a few of the old drivers (blizzard) had been removed. I was pleasantly surprised when I discovered that a lot of the old drivers had been replaced by new ones. I will document the latest state of play with the N810 once I have got things going. All I really want is a text console with working keyboard and wifi, initially. Any help will be gratefully received. I can't help much, because I do not own any N8x0 device, but you should probably visit [0] (and update it once you get stuff working :)) The omap platform is currently moving over to Device Tree [1] based booting, so you come at the right time to test DT based booting on your N810. Building a DT kernel for your N810 works like this: enable the following config entries: CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y CONFIG_PINCTRL=y CONFIG_PINCTRL_SINGLE=y and build zImage like this: $ export ARCH=arm $ export CROSS_COMPILE=arm-linux-gnueabi- $ make zImage $ make omap2420-n810.dtb $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap3-n900.dtb zImage Be aware, that the DTS file seems to lack display keyboard support at the moment, so you may want to start building a serial adapter first. See [2] for details on this. This may seem like lots of work, but it really makes things much easier. [0] http://elinux.org/N800 [1] http://devicetree.org/ [2] http://bues.ch/cms/hacking/n810-serial.html -- Sebastian signature.asc Description: Digital signature
Re: [PATCHv2 03/16] Documentation: dt: add OMAP iommu bindings
Hi Suman,
On Wednesday 26 February 2014 11:02:24 Suman Anna wrote:
On 02/25/2014 08:13 PM, Laurent Pinchart wrote:
On Tuesday 25 February 2014 17:02:35 Suman Anna wrote:
On 02/25/2014 03:26 PM, Laurent Pinchart wrote:
On Thursday 13 February 2014 12:15:34 Suman Anna wrote:
From: Florian Vaussard florian.vauss...@epfl.ch
This patch adds the iommu bindings for all OMAP2+ SoCs. Apart from
the standard bindings used by OMAP peripherals, this patch uses a
'dma-window' (already used by Tegra SMMU) and adds two OMAP custom
bindings - 'ti,#tlb-entries' and 'ti,iommu-bus-err-back'.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
[s-a...@ti.com: split bindings document, add dra7 and bus error back]
Signed-off-by: Suman Anna s-a...@ti.com
---
.../devicetree/bindings/iommu/ti,omap-iommu.txt| 28 ++
1 file changed, 28 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
diff --git a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt new file
mode 100644
index 000..116492d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
@@ -0,0 +1,28 @@
+OMAP2+ IOMMU
+
+Required properties:
+- compatible : Should be one of,
+ti,omap2-iommu for OMAP2/OMAP3 IOMMU instances
+ti,omap4-iommu for OMAP4/OMAP5 IOMMU instances
+ti,dra7-iommu for DRA7xx IOMMU instances
+- ti,hwmods : Name of the hwmod associated with the IOMMU instance
+- reg: Address space for the configuration registers
+- interrupts : Interrupt specifier for the IOMMU instance
+- dma-window : IOVA start address and length
Isn't the dma window more of a system configuration property than a
hardware property ? How do you expect it to be set?
We are setting it based on the addressable range for the MMU.
A quick look at the ISP and IVA IOMMUs in the OMAP3 shows that both
support the full 4GB VA space. Why do you need to restrict it ?
I should have rephrased it better when I said addressable range. While
the MMUs are capable of programming the full 4GB space, there are some
address ranges that are private from the processor view. This window is
currently used to set the range for the omap-iovmm driver (which only
OMAP3 ISP is using atm), and there is no point in allowing the
omap-iovmm driver the full range when the processor could never
reach/access those addresses.
But the IOMMU VA space is from a device point of view, not from a CPU point of
view. Could you point me to where those private ranges are documented, in
order to understand the problem correctly ?
We are reusing the existing defined property and it allows us to get rid
of the IOVA start and end addresses defined in the pre-DT OMAP iommu
platform data.
+Optional properties:
+- ti,#tlb-entries : Number of entries in the translation look-aside
buffer. +Should be either 8 or 32 (default: 32)
+- ti,iommu-bus-err-back : Indicates the IOMMU instance supports
throwing
+ back a bus error response on MMU faults.
Do these features vary per IOMMU instance or per IOMMU model ? In the
latter case they could be inferred from the compatible string by the
driver without requiring them to be explicit in DT (whether you want to
do so is left to you though).
Well, these are fixed features given an IOMMU instance, like the OMAP3
ISP is the only one that has 8 TLB entries, all the remaining ones have
32, and the IPU iommu instances are the only ones that support the bus
error response back. I have no preference to any particular way, and
sure the driver can infer these easily based on unique compatible
strings per subsystem per SoC. I just happened to go with defining
compatible strings per SoC, with the optional properties differentiating
the fixed behavior between different IOMMU instances on that SoC. This
is where I was looking for some inputs/guidance from the DT bindings
maintainers on what is the preferred method.
I think you've made the right choice. I wasn't sure whether those
parameters varied across IOMMU instances of compatible devices (from a
compatible string point of view) or were constant. As they vary they
should be expressed in DT.
Yeah, I wasn't sure if these qualify as features (as per
Documentation/devicetree/bindings/ABI.txt section II.2).
regards
Suman
+Example:
+/* OMAP3 ISP MMU */
+mmu_isp: mmu@480bd400 {
+compatible = ti,omap2-iommu;
+reg = 0x480bd400 0x80;
+interrupts = 24;
+ti,hwmods = mmu_isp;
+ti,#tlb-entries = 8;
+dma-window = 0 0xf000;
+};
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the
Re: [PATCHv2 03/16] Documentation: dt: add OMAP iommu bindings
Hi Laurent,
On Wednesday 26 February 2014 11:02:24 Suman Anna wrote:
On 02/25/2014 08:13 PM, Laurent Pinchart wrote:
On Tuesday 25 February 2014 17:02:35 Suman Anna wrote:
On 02/25/2014 03:26 PM, Laurent Pinchart wrote:
On Thursday 13 February 2014 12:15:34 Suman Anna wrote:
From: Florian Vaussard florian.vauss...@epfl.ch
This patch adds the iommu bindings for all OMAP2+ SoCs. Apart from
the standard bindings used by OMAP peripherals, this patch uses a
'dma-window' (already used by Tegra SMMU) and adds two OMAP custom
bindings - 'ti,#tlb-entries' and 'ti,iommu-bus-err-back'.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
[s-a...@ti.com: split bindings document, add dra7 and bus error back]
Signed-off-by: Suman Anna s-a...@ti.com
---
.../devicetree/bindings/iommu/ti,omap-iommu.txt| 28 ++
1 file changed, 28 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
diff --git a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt new file
mode 100644
index 000..116492d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
@@ -0,0 +1,28 @@
+OMAP2+ IOMMU
+
+Required properties:
+- compatible : Should be one of,
+ ti,omap2-iommu for OMAP2/OMAP3 IOMMU instances
+ ti,omap4-iommu for OMAP4/OMAP5 IOMMU instances
+ ti,dra7-iommu for DRA7xx IOMMU instances
+- ti,hwmods : Name of the hwmod associated with the IOMMU instance
+- reg: Address space for the configuration registers
+- interrupts : Interrupt specifier for the IOMMU instance
+- dma-window : IOVA start address and length
Isn't the dma window more of a system configuration property than a
hardware property ? How do you expect it to be set?
We are setting it based on the addressable range for the MMU.
A quick look at the ISP and IVA IOMMUs in the OMAP3 shows that both
support the full 4GB VA space. Why do you need to restrict it ?
I should have rephrased it better when I said addressable range. While
the MMUs are capable of programming the full 4GB space, there are some
address ranges that are private from the processor view. This window is
currently used to set the range for the omap-iovmm driver (which only
OMAP3 ISP is using atm), and there is no point in allowing the
omap-iovmm driver the full range when the processor could never
reach/access those addresses.
But the IOMMU VA space is from a device point of view, not from a CPU point of
view. Could you point me to where those private ranges are documented, in
order to understand the problem correctly ?
Yes, they are indeed from the device perspective. I meant DSP and/or IPU
by processor.
For example on OMAP3, you can refer to Table 2-9 in section 2.4.5 DSP
Subsystem Memory Space Mapping of the OMAP36xx TRM, and the external
addressable range starts from 0x1100.
regards
Suman
We are reusing the existing defined property and it allows us to get rid
of the IOVA start and end addresses defined in the pre-DT OMAP iommu
platform data.
+Optional properties:
+- ti,#tlb-entries : Number of entries in the translation look-aside
buffer. +Should be either 8 or 32 (default: 32)
+- ti,iommu-bus-err-back : Indicates the IOMMU instance supports
throwing
+ back a bus error response on MMU faults.
Do these features vary per IOMMU instance or per IOMMU model ? In the
latter case they could be inferred from the compatible string by the
driver without requiring them to be explicit in DT (whether you want to
do so is left to you though).
Well, these are fixed features given an IOMMU instance, like the OMAP3
ISP is the only one that has 8 TLB entries, all the remaining ones have
32, and the IPU iommu instances are the only ones that support the bus
error response back. I have no preference to any particular way, and
sure the driver can infer these easily based on unique compatible
strings per subsystem per SoC. I just happened to go with defining
compatible strings per SoC, with the optional properties differentiating
the fixed behavior between different IOMMU instances on that SoC. This
is where I was looking for some inputs/guidance from the DT bindings
maintainers on what is the preferred method.
I think you've made the right choice. I wasn't sure whether those
parameters varied across IOMMU instances of compatible devices (from a
compatible string point of view) or were constant. As they vary they
should be expressed in DT.
Yeah, I wasn't sure if these qualify as features (as per
Documentation/devicetree/bindings/ABI.txt section II.2).
regards
Suman
+Example:
+ /* OMAP3 ISP MMU */
+ mmu_isp: mmu@480bd400 {
+ compatible = ti,omap2-iommu;
+ reg = 0x480bd400 0x80;
+ interrupts = 24;
+ ti,hwmods = mmu_isp;
+ ti,#tlb-entries = 8;
+
Re: [PATCHv2 03/16] Documentation: dt: add OMAP iommu bindings
Hi Suman, On Wednesday 26 February 2014 14:23:03 Suman Anna wrote: On Wednesday 26 February 2014 11:02:24 Suman Anna wrote: On 02/25/2014 08:13 PM, Laurent Pinchart wrote: On Tuesday 25 February 2014 17:02:35 Suman Anna wrote: On 02/25/2014 03:26 PM, Laurent Pinchart wrote: On Thursday 13 February 2014 12:15:34 Suman Anna wrote: From: Florian Vaussard florian.vauss...@epfl.ch This patch adds the iommu bindings for all OMAP2+ SoCs. Apart from the standard bindings used by OMAP peripherals, this patch uses a 'dma-window' (already used by Tegra SMMU) and adds two OMAP custom bindings - 'ti,#tlb-entries' and 'ti,iommu-bus-err-back'. Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch [s-a...@ti.com: split bindings document, add dra7 and bus error back] Signed-off-by: Suman Anna s-a...@ti.com --- .../devicetree/bindings/iommu/ti,omap-iommu.txt| 28 1 file changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt diff --git a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt new file mode 100644 index 000..116492d --- /dev/null +++ b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt @@ -0,0 +1,28 @@ +OMAP2+ IOMMU + +Required properties: +- compatible : Should be one of, + ti,omap2-iommu for OMAP2/OMAP3 IOMMU instances + ti,omap4-iommu for OMAP4/OMAP5 IOMMU instances + ti,dra7-iommu for DRA7xx IOMMU instances +- ti,hwmods : Name of the hwmod associated with the IOMMU instance +- reg: Address space for the configuration registers +- interrupts : Interrupt specifier for the IOMMU instance +- dma-window : IOVA start address and length Isn't the dma window more of a system configuration property than a hardware property ? How do you expect it to be set? We are setting it based on the addressable range for the MMU. A quick look at the ISP and IVA IOMMUs in the OMAP3 shows that both support the full 4GB VA space. Why do you need to restrict it ? I should have rephrased it better when I said addressable range. While the MMUs are capable of programming the full 4GB space, there are some address ranges that are private from the processor view. This window is currently used to set the range for the omap-iovmm driver (which only OMAP3 ISP is using atm), and there is no point in allowing the omap-iovmm driver the full range when the processor could never reach/access those addresses. But the IOMMU VA space is from a device point of view, not from a CPU point of view. Could you point me to where those private ranges are documented, in order to understand the problem correctly ? Yes, they are indeed from the device perspective. I meant DSP and/or IPU by processor. For example on OMAP3, you can refer to Table 2-9 in section 2.4.5 DSP Subsystem Memory Space Mapping of the OMAP36xx TRM, and the external addressable range starts from 0x1100. OK, so it looks more like a property of the IOMMU master than a property of the IOMMU itself. It would be better to express it as such, but I wonder how that could be done, and if it would be worth it in this case. As not all masters (the OMAP3 ISP doesn't for instance) have restrictions regarding the VA range they can address, should this property be at least made optional ? We are reusing the existing defined property and it allows us to get rid of the IOVA start and end addresses defined in the pre-DT OMAP iommu platform data. +Optional properties: +- ti,#tlb-entries : Number of entries in the translation look-aside buffer. +Should be either 8 or 32 (default: 32) +- ti,iommu-bus-err-back : Indicates the IOMMU instance supports throwing +back a bus error response on MMU faults. Do these features vary per IOMMU instance or per IOMMU model ? In the latter case they could be inferred from the compatible string by the driver without requiring them to be explicit in DT (whether you want to do so is left to you though). Well, these are fixed features given an IOMMU instance, like the OMAP3 ISP is the only one that has 8 TLB entries, all the remaining ones have 32, and the IPU iommu instances are the only ones that support the bus error response back. I have no preference to any particular way, and sure the driver can infer these easily based on unique compatible strings per subsystem per SoC. I just happened to go with defining compatible strings per SoC, with the optional properties differentiating the fixed behavior between different IOMMU instances on that SoC. This is where I was looking for some inputs/guidance from the DT bindings maintainers on what is the preferred method. I think you've made the right choice. I wasn't sure whether those
Re: [PATCH v3 1/2] CLK: TI: OMAP4/5/DRA7: Remove gpmc_fck from dummy clocks
Quoting Florian Vaussard (2014-02-26 02:38:08)
When arch/arm/mach-omap2/gpmc.c calls clk_get(..., fck), it will
get a dummy clock and try to use it. As the rate is configured to zero,
this will result in several divisions by zero, and misconfigured
timings, with devices on the bus being lost in the La La Land.
It is better to remove gpmc_fck from the dummy clocks, so that gpmc.c
can fail gracefully.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
Looks good to me.
Regards,
Mike
---
drivers/clk/ti/clk-44xx.c | 1 -
drivers/clk/ti/clk-54xx.c | 1 -
drivers/clk/ti/clk-7xx.c | 1 -
3 files changed, 3 deletions(-)
diff --git a/drivers/clk/ti/clk-44xx.c b/drivers/clk/ti/clk-44xx.c
index ae00218..02517a8 100644
--- a/drivers/clk/ti/clk-44xx.c
+++ b/drivers/clk/ti/clk-44xx.c
@@ -222,7 +222,6 @@ static struct ti_dt_clk omap44xx_clks[] = {
DT_CLK(NULL, auxclk5_src_ck, auxclk5_src_ck),
DT_CLK(NULL, auxclk5_ck, auxclk5_ck),
DT_CLK(NULL, auxclkreq5_ck, auxclkreq5_ck),
- DT_CLK(5000.gpmc, fck, dummy_ck),
DT_CLK(omap_i2c.1, ick, dummy_ck),
DT_CLK(omap_i2c.2, ick, dummy_ck),
DT_CLK(omap_i2c.3, ick, dummy_ck),
diff --git a/drivers/clk/ti/clk-54xx.c b/drivers/clk/ti/clk-54xx.c
index 0ef9f58..08f3d1b 100644
--- a/drivers/clk/ti/clk-54xx.c
+++ b/drivers/clk/ti/clk-54xx.c
@@ -182,7 +182,6 @@ static struct ti_dt_clk omap54xx_clks[] = {
DT_CLK(NULL, auxclk3_src_ck, auxclk3_src_ck),
DT_CLK(NULL, auxclk3_ck, auxclk3_ck),
DT_CLK(NULL, auxclkreq3_ck, auxclkreq3_ck),
- DT_CLK(NULL, gpmc_ck, dummy_ck),
DT_CLK(omap_i2c.1, ick, dummy_ck),
DT_CLK(omap_i2c.2, ick, dummy_ck),
DT_CLK(omap_i2c.3, ick, dummy_ck),
diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index 9977653..f7e4073 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -262,7 +262,6 @@ static struct ti_dt_clk dra7xx_clks[] = {
DT_CLK(NULL, vip1_gclk_mux, vip1_gclk_mux),
DT_CLK(NULL, vip2_gclk_mux, vip2_gclk_mux),
DT_CLK(NULL, vip3_gclk_mux, vip3_gclk_mux),
- DT_CLK(NULL, gpmc_ck, dummy_ck),
DT_CLK(omap_i2c.1, ick, dummy_ck),
DT_CLK(omap_i2c.2, ick, dummy_ck),
DT_CLK(omap_i2c.3, ick, dummy_ck),
--
1.8.1.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 v8 06/14] CLK: TI: OMAP3: Get rid of unused USB Host dummy clocks
Quoting Roger Quadros (2014-02-25 01:32:19)
Hi Mike,
On 02/25/2014 10:43 AM, Mike Turquette wrote:
Quoting Roger Quadros (2014-02-20 03:40:01)
The OMAP USB Host MFD driver no longer expects these non-existing
clocks from the OMAP3 platform, so get rid of them.
Looks good to me.
Is it OK if I squash this patch with [1] and take it through the MFD tree?
Keeping them separate could break functionality if both don't go in together.
Acked-by: Mike Turquette mturque...@linaro.org
[1] - http://article.gmane.org/gmane.linux.ports.arm.kernel/303266
cheers,
-roger
CC: Tero Kristo t-kri...@ti.com
CC: Mike Turquette mturque...@linaro.org
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/cclock3xxx_data.c | 4
drivers/clk/ti/clk-3xxx.c | 4
2 files changed, 8 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 3b05aea..4299a55 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -3495,10 +3495,6 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, dss_tv_fck, dss_tv_fck),
CLK(NULL, dss_96m_fck, dss_96m_fck),
CLK(NULL, dss2_alwon_fck, dss2_alwon_fck),
- CLK(NULL, utmi_p1_gfclk,dummy_ck),
- CLK(NULL, utmi_p2_gfclk,dummy_ck),
- CLK(NULL, xclk60mhsp1_ck, dummy_ck),
- CLK(NULL, xclk60mhsp2_ck, dummy_ck),
CLK(NULL, init_60m_fclk,dummy_ck),
CLK(NULL, gpt1_fck, gpt1_fck),
CLK(NULL, aes2_ick, aes2_ick),
diff --git a/drivers/clk/ti/clk-3xxx.c b/drivers/clk/ti/clk-3xxx.c
index d323023..0d1750a 100644
--- a/drivers/clk/ti/clk-3xxx.c
+++ b/drivers/clk/ti/clk-3xxx.c
@@ -130,10 +130,6 @@ static struct ti_dt_clk omap3xxx_clks[] = {
DT_CLK(NULL, dss_tv_fck, dss_tv_fck),
DT_CLK(NULL, dss_96m_fck, dss_96m_fck),
DT_CLK(NULL, dss2_alwon_fck, dss2_alwon_fck),
- DT_CLK(NULL, utmi_p1_gfclk, dummy_ck),
- DT_CLK(NULL, utmi_p2_gfclk, dummy_ck),
- DT_CLK(NULL, xclk60mhsp1_ck, dummy_ck),
- DT_CLK(NULL, xclk60mhsp2_ck, dummy_ck),
DT_CLK(NULL, init_60m_fclk, dummy_ck),
DT_CLK(NULL, gpt1_fck, gpt1_fck),
DT_CLK(NULL, aes2_ick, aes2_ick),
--
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 3/4] ARM: dts: OMAP4: Add IOMMU nodes
Hi Suman,
Thank you for the patch.
On Thursday 13 February 2014 12:22:55 Suman Anna wrote:
From: Florian Vaussard florian.vauss...@epfl.ch
Add the IOMMU nodes for the DSP and IPU subsystems. The external
address space for DSP starts at 0x2000 in OMAP4 compared to
0x1100 in OMAP3, and the addresses beyond 0xE000 are
private address space for the Cortex-M3 cores in the IPU subsystem.
The MMU within the IPU sub-system also supports a bus error back
capability, not available on the DSP MMU.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
[s-a...@ti.com: dma-window updates and bus error back addition]
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index d3f8a6e..1885f90 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -461,6 +461,23 @@
dma-names = tx, rx;
};
+ mmu_dsp: mmu@4a066000 {
+ compatible = ti,omap4-iommu;
+ reg = 0x4a066000 0xff;
+ interrupts = GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = mmu_dsp;
+ dma-window = 0x2000 0xd000;
+ };
+
+ mmu_ipu: mmu@55082000 {
+ compatible = ti,omap4-iommu;
+ reg = 0x55082000 0xff;
+ interrupts = GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = mmu_ipu;
+ dma-window = 0 0xd000;
I'm not too familiar with the M3 MPU in the OMAP4, but doesn't its memory map
also include other reserved regions, such as 0x5504- 0x5505 to access
the ISS ?
+ ti,iommu-bus-err-back;
+ };
+
wdt2: wdt@4a314000 {
compatible = ti,omap4-wdt, ti,omap3-wdt;
reg = 0x4a314000 0x80;
--
Regards,
Laurent Pinchart
--
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: Help running latest linux-omap kernel on Nokia N810
* Sebastian Reichel s...@ring0.de [140226 10:56]: Hi, On Wed, Feb 26, 2014 at 06:24:36PM +, Leigh Brown wrote: I have built the latest linux-omap git tree for my N810 but when I boot it I get a black screen with the backlight on. Does anyone have a working .config that they could share with me? Attached is what I've been using for my boot testing. If it does not fit into the memory, you need to cut down on the options. During my investigations I have discovered that the kernel configuration has changed enormously in the last couple of years. I was worried that the N810 was no longer supported at allm especially when I saw that a few of the old drivers (blizzard) had been removed. I was pleasantly surprised when I discovered that a lot of the old drivers had been replaced by new ones. I will document the latest state of play with the N810 once I have got things going. All I really want is a text console with working keyboard and wifi, initially. Any help will be gratefully received. I can't help much, because I do not own any N8x0 device, but you should probably visit [0] (and update it once you get stuff working :)) The omap platform is currently moving over to Device Tree [1] based booting, so you come at the right time to test DT based booting on your N810. Building a DT kernel for your N810 works like this: enable the following config entries: CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y CONFIG_PINCTRL=y CONFIG_PINCTRL_SINGLE=y and build zImage like this: $ export ARCH=arm $ export CROSS_COMPILE=arm-linux-gnueabi- $ make zImage $ make omap2420-n810.dtb $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap3-n900.dtb zImage Be aware, that the DTS file seems to lack display keyboard support at the moment, so you may want to start building a serial adapter first. See [2] for details on this. This may seem like lots of work, but it really makes things much easier. Yeah the above should pretty much do it for booting it :) Regards, Tony [0] http://elinux.org/N800 [1] http://devicetree.org/ [2] http://bues.ch/cms/hacking/n810-serial.html CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=16 CONFIG_BLK_DEV_INITRD=y CONFIG_EXPERT=y CONFIG_SLAB=y CONFIG_PROFILING=y CONFIG_OPROFILE=y CONFIG_KPROBES=y CONFIG_MODULES=y CONFIG_MODULE_FORCE_LOAD=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y # CONFIG_BLK_DEV_BSG is not set CONFIG_PARTITION_ADVANCED=y # CONFIG_EFI_PARTITION is not set CONFIG_ARCH_MULTI_V6=y CONFIG_OMAP_RESET_CLOCKS=y CONFIG_OMAP_MUX_DEBUG=y CONFIG_ARCH_OMAP2=y # CONFIG_SOC_OMAP2430 is not set CONFIG_ARM_THUMBEE=y CONFIG_ARM_ERRATA_411920=y CONFIG_ARM_ERRATA_720789=y CONFIG_ARM_ERRATA_754322=y CONFIG_ARM_ERRATA_775420=y # CONFIG_COMPACTION is not set CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_CMDLINE=root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 earlyprintk ignore_loglevel CONFIG_KEXEC=y CONFIG_FPE_NWFPE=y CONFIG_BINFMT_MISC=y CONFIG_PM_DEBUG=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_XFRM_USER=y CONFIG_NET_KEY=y CONFIG_NET_KEY_MIGRATE=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_PNP=y CONFIG_IP_PNP_DHCP=y CONFIG_IP_PNP_BOOTP=y CONFIG_IP_PNP_RARP=y # CONFIG_INET_LRO is not set # CONFIG_IPV6 is not set CONFIG_NETFILTER=y CONFIG_BT=m CONFIG_BT_HCIUART=m CONFIG_BT_HCIUART_H4=y CONFIG_BT_HCIUART_BCSP=y CONFIG_BT_HCIUART_LL=y CONFIG_BT_HCIBCM203X=m CONFIG_BT_HCIBPA10X=m CONFIG_CFG80211=m CONFIG_CFG80211_WEXT=y CONFIG_MAC80211=m CONFIG_MAC80211_RC_PID=y CONFIG_MAC80211_RC_DEFAULT_PID=y CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug CONFIG_OMAP_INTERCONNECT=y CONFIG_CONNECTOR=y CONFIG_MTD=y CONFIG_MTD_CMDLINE_PARTS=y CONFIG_MTD_BLOCK=y CONFIG_MTD_OOPS=y CONFIG_MTD_CFI=y CONFIG_MTD_CFI_INTELEXT=y CONFIG_MTD_NAND=y CONFIG_MTD_NAND_OMAP2=y CONFIG_MTD_ONENAND=y CONFIG_MTD_ONENAND_VERIFY_WRITE=y CONFIG_MTD_ONENAND_OMAP2=y CONFIG_MTD_UBI=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=16384 CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_SCAN_ASYNC=y CONFIG_MD=y CONFIG_NETDEVICES=y CONFIG_KS8851=y CONFIG_KS8851_MLL=y CONFIG_SMC91X=y CONFIG_SMSC911X=y CONFIG_SMSC_PHY=y CONFIG_USB_USBNET=y CONFIG_USB_NET_SMSC95XX=y CONFIG_USB_ALI_M5632=y CONFIG_USB_AN2720=y CONFIG_USB_EPSON2888=y CONFIG_USB_KC2190=y CONFIG_LIBERTAS=m CONFIG_LIBERTAS_USB=m CONFIG_LIBERTAS_SDIO=m CONFIG_LIBERTAS_DEBUG=y CONFIG_INPUT_JOYDEV=y CONFIG_INPUT_EVDEV=y CONFIG_KEYBOARD_GPIO=y CONFIG_KEYBOARD_TWL4030=y CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_ADS7846=y CONFIG_INPUT_MISC=y CONFIG_INPUT_RETU_PWRBUTTON=y CONFIG_INPUT_TWL4030_PWRBUTTON=y # CONFIG_LEGACY_PTYS is not set CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_NR_UARTS=32
Re: Help running latest linux-omap kernel on Nokia N810
Hi, On Wed, Feb 26, 2014 at 07:53:32PM +0100, Sebastian Reichel wrote: On Wed, Feb 26, 2014 at 06:24:36PM +, Leigh Brown wrote: Does anyone have a working .config that they could share with me? Yes. During my investigations I have discovered that the kernel configuration has changed enormously in the last couple of years. I was worried that the N810 was no longer supported at allm especially when I saw that a few of the old drivers (blizzard) had been removed. I was pleasantly surprised when I discovered that a lot of the old drivers had been replaced by new ones. I will document the latest state of play with the N810 once I have got things going. All I really want is a text console with working keyboard and wifi, initially. First the bad news: display support is not in the mainline kernel. Also since linux-omap tree follows the mainline, it's not there either anymore. Tomi removed the n8x0 panel driver some time ago (I don't know why), but even then it wasn't working as the platform data failed to set up some needed things properly. I was trying to get it working at but failed before the driver got removed. Anyway, this is still on my backlog and at some point I will try to reintroduce the display support. Meanwhile, the OMAP2 has been converted to DT so this is not going to be trivial so any help in this effort is appreciated. (Read: please send patches :)) Good news: it's still possible to run current mainline Linux on N8x0. But only basic functionality is there. You can interact with the device at least over UART and USB (e.g. ssh connection with USB networking). MMC and flash should work too. I haven't yet tested the WIFI. I'm booting test kernels with 0x - the N8x0 has 2MB limitation for the kernel, so I'm using kexec (tiny kernel) to boot a full-featured kernel from MMC. My kernel configs for 3.13 are available here: http://www.iki.fi/aaro/comp/linux/v3.13/arm-testresults.html. Building a serial adapter to develop Linux on N8x0 isn't strictly necessary as long as you get the USB is working. However it will ease things alot. 770/N800 are more friendly in this regard, as you can access the serial pins without removing the battery. 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: [PATCH 3/4] ARM: dts: OMAP4: Add IOMMU nodes
Hi Laurent,
On 02/26/2014 03:05 PM, Laurent Pinchart wrote:
Hi Suman,
Thank you for the patch.
On Thursday 13 February 2014 12:22:55 Suman Anna wrote:
From: Florian Vaussard florian.vauss...@epfl.ch
Add the IOMMU nodes for the DSP and IPU subsystems. The external
address space for DSP starts at 0x2000 in OMAP4 compared to
0x1100 in OMAP3, and the addresses beyond 0xE000 are
private address space for the Cortex-M3 cores in the IPU subsystem.
The MMU within the IPU sub-system also supports a bus error back
capability, not available on the DSP MMU.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
[s-a...@ti.com: dma-window updates and bus error back addition]
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index d3f8a6e..1885f90 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -461,6 +461,23 @@
dma-names = tx, rx;
};
+ mmu_dsp: mmu@4a066000 {
+ compatible = ti,omap4-iommu;
+ reg = 0x4a066000 0xff;
+ interrupts = GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = mmu_dsp;
+ dma-window = 0x2000 0xd000;
+ };
+
+ mmu_ipu: mmu@55082000 {
+ compatible = ti,omap4-iommu;
+ reg = 0x55082000 0xff;
+ interrupts = GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = mmu_ipu;
+ dma-window = 0 0xd000;
I'm not too familiar with the M3 MPU in the OMAP4, but doesn't its memory map
also include other reserved regions, such as 0x5504- 0x5505 to access
the ISS ?
The MMU integration into the M3 MPU subsystem is actually slightly
different to that seen on DSP in OMAP3. The M3 MPU subsystem actually
has one additional type of MMU, called the Attribute MMU/Unicache MMU
immediately after the M3 processor. It is programmed completely from the
M3, and is used mainly for setting the cache attributes and valid
address ranges and translations for accessing address ranges like the
ISS space. The L2 MMU interprets the remaining addresses, so yes, there
are certain other address ranges that never go through the L2MMU. The
dma-window values are used by omap-iovmm, but OMAP4 does not make use of
omap-iovmm.
regards
Suman
+ ti,iommu-bus-err-back;
+ };
+
wdt2: wdt@4a314000 {
compatible = ti,omap4-wdt, ti,omap3-wdt;
reg = 0x4a314000 0x80;
--
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: [PATCHv2 03/16] Documentation: dt: add OMAP iommu bindings
Hi Laurent, On 02/26/2014 02:36 PM, Laurent Pinchart wrote: Hi Suman, On Wednesday 26 February 2014 14:23:03 Suman Anna wrote: On Wednesday 26 February 2014 11:02:24 Suman Anna wrote: On 02/25/2014 08:13 PM, Laurent Pinchart wrote: On Tuesday 25 February 2014 17:02:35 Suman Anna wrote: On 02/25/2014 03:26 PM, Laurent Pinchart wrote: On Thursday 13 February 2014 12:15:34 Suman Anna wrote: From: Florian Vaussard florian.vauss...@epfl.ch This patch adds the iommu bindings for all OMAP2+ SoCs. Apart from the standard bindings used by OMAP peripherals, this patch uses a 'dma-window' (already used by Tegra SMMU) and adds two OMAP custom bindings - 'ti,#tlb-entries' and 'ti,iommu-bus-err-back'. Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch [s-a...@ti.com: split bindings document, add dra7 and bus error back] Signed-off-by: Suman Anna s-a...@ti.com --- .../devicetree/bindings/iommu/ti,omap-iommu.txt| 28 1 file changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt diff --git a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt new file mode 100644 index 000..116492d --- /dev/null +++ b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt @@ -0,0 +1,28 @@ +OMAP2+ IOMMU + +Required properties: +- compatible : Should be one of, + ti,omap2-iommu for OMAP2/OMAP3 IOMMU instances + ti,omap4-iommu for OMAP4/OMAP5 IOMMU instances + ti,dra7-iommu for DRA7xx IOMMU instances +- ti,hwmods : Name of the hwmod associated with the IOMMU instance +- reg: Address space for the configuration registers +- interrupts : Interrupt specifier for the IOMMU instance +- dma-window : IOVA start address and length Isn't the dma window more of a system configuration property than a hardware property ? How do you expect it to be set? We are setting it based on the addressable range for the MMU. A quick look at the ISP and IVA IOMMUs in the OMAP3 shows that both support the full 4GB VA space. Why do you need to restrict it ? I should have rephrased it better when I said addressable range. While the MMUs are capable of programming the full 4GB space, there are some address ranges that are private from the processor view. This window is currently used to set the range for the omap-iovmm driver (which only OMAP3 ISP is using atm), and there is no point in allowing the omap-iovmm driver the full range when the processor could never reach/access those addresses. But the IOMMU VA space is from a device point of view, not from a CPU point of view. Could you point me to where those private ranges are documented, in order to understand the problem correctly ? Yes, they are indeed from the device perspective. I meant DSP and/or IPU by processor. For example on OMAP3, you can refer to Table 2-9 in section 2.4.5 DSP Subsystem Memory Space Mapping of the OMAP36xx TRM, and the external addressable range starts from 0x1100. OK, so it looks more like a property of the IOMMU master than a property of the IOMMU itself. It would be better to express it as such, but I wonder how that could be done, and if it would be worth it in this case. This property is currently solely used to configure the range for the omap-iovmm module, which were supplied through platform data in the non-DT case. I am wondering if the way to go here is to use iommu_domain_set_attr() and use the domain geometry values. regards Suman As not all masters (the OMAP3 ISP doesn't for instance) have restrictions regarding the VA range they can address, should this property be at least made optional ? We are reusing the existing defined property and it allows us to get rid of the IOVA start and end addresses defined in the pre-DT OMAP iommu platform data. +Optional properties: +- ti,#tlb-entries : Number of entries in the translation look-aside buffer. +Should be either 8 or 32 (default: 32) +- ti,iommu-bus-err-back : Indicates the IOMMU instance supports throwing + back a bus error response on MMU faults. Do these features vary per IOMMU instance or per IOMMU model ? In the latter case they could be inferred from the compatible string by the driver without requiring them to be explicit in DT (whether you want to do so is left to you though). Well, these are fixed features given an IOMMU instance, like the OMAP3 ISP is the only one that has 8 TLB entries, all the remaining ones have 32, and the IPU iommu instances are the only ones that support the bus error response back. I have no preference to any particular way, and sure the driver can infer these easily based on unique compatible strings per subsystem per SoC. I just happened to go with defining compatible strings per SoC, with the optional properties differentiating the fixed behavior between different IOMMU instances on that SoC. This is
Re: [PATCHv2 03/16] Documentation: dt: add OMAP iommu bindings
Hi Suman, On Wednesday 26 February 2014 16:28:08 Suman Anna wrote: On 02/26/2014 04:18 PM, Suman Anna wrote: On 02/26/2014 02:36 PM, Laurent Pinchart wrote: On Wednesday 26 February 2014 14:23:03 Suman Anna wrote: On Wednesday 26 February 2014 11:02:24 Suman Anna wrote: On 02/25/2014 08:13 PM, Laurent Pinchart wrote: On Tuesday 25 February 2014 17:02:35 Suman Anna wrote: On 02/25/2014 03:26 PM, Laurent Pinchart wrote: On Thursday 13 February 2014 12:15:34 Suman Anna wrote: From: Florian Vaussard florian.vauss...@epfl.ch This patch adds the iommu bindings for all OMAP2+ SoCs. Apart from the standard bindings used by OMAP peripherals, this patch uses a 'dma-window' (already used by Tegra SMMU) and adds two OMAP custom bindings - 'ti,#tlb-entries' and 'ti,iommu-bus-err-back'. Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch [s-a...@ti.com: split bindings document, add dra7 and bus error back] Signed-off-by: Suman Anna s-a...@ti.com --- .../devicetree/bindings/iommu/ti,omap-iommu.txt| 28 + 1 file changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt diff --git a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt new file mode 100644 index 000..116492d --- /dev/null +++ b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt @@ -0,0 +1,28 @@ +OMAP2+ IOMMU + +Required properties: +- compatible : Should be one of, +ti,omap2-iommu for OMAP2/OMAP3 IOMMU instances +ti,omap4-iommu for OMAP4/OMAP5 IOMMU instances +ti,dra7-iommu for DRA7xx IOMMU instances +- ti,hwmods : Name of the hwmod associated with the IOMMU instance +- reg: Address space for the configuration registers +- interrupts : Interrupt specifier for the IOMMU instance +- dma-window : IOVA start address and length Isn't the dma window more of a system configuration property than a hardware property ? How do you expect it to be set? We are setting it based on the addressable range for the MMU. A quick look at the ISP and IVA IOMMUs in the OMAP3 shows that both support the full 4GB VA space. Why do you need to restrict it ? I should have rephrased it better when I said addressable range. While the MMUs are capable of programming the full 4GB space, there are some address ranges that are private from the processor view. This window is currently used to set the range for the omap-iovmm driver (which only OMAP3 ISP is using atm), and there is no point in allowing the omap-iovmm driver the full range when the processor could never reach/access those addresses. But the IOMMU VA space is from a device point of view, not from a CPU point of view. Could you point me to where those private ranges are documented, in order to understand the problem correctly ? Yes, they are indeed from the device perspective. I meant DSP and/or IPU by processor. For example on OMAP3, you can refer to Table 2-9 in section 2.4.5 DSP Subsystem Memory Space Mapping of the OMAP36xx TRM, and the external addressable range starts from 0x1100. OK, so it looks more like a property of the IOMMU master than a property of the IOMMU itself. It would be better to express it as such, but I wonder how that could be done, and if it would be worth it in this case. This property is currently solely used to configure the range for the omap-iovmm module, which were supplied through platform data in the non-DT case. If I'm not mistaken omap-iovmm is something we want to get rid of. I know that the OMAP3 ISP driver is the only user of that module, and I've started working on fixing that, but I'm currently lacking time to complete the work. Now, if we get rid of omap-iovmm, does that mean that the dma-window property won't need to be specified anymore ? If so, given that the only omap-iovmm user is the OMAP3 ISP driver, I would propose to drop the property and just hardcode the value. Please let me know if there's something I've missed. I am wondering if the way to go here is to use iommu_domain_set_attr() and use the domain geometry values. The other option is to supply these as driver match data, and switching the compatible strings to identify the MMU instance precisely. regards Suman As not all masters (the OMAP3 ISP doesn't for instance) have restrictions regarding the VA range they can address, should this property be at least made optional ? We are reusing the existing defined property and it allows us to get rid of the IOVA start and end addresses defined in the pre-DT OMAP iommu platform data. [snip] -- Regards, Laurent Pinchart -- 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
Re: [PATCHv1 5/6] HSI: Introduce OMAP SSI driver
Hi Mark,
On Mon, Feb 24, 2014 at 03:51:32PM +, Mark Rutland wrote:
+ irq = platform_get_resource_byname(pd, IORESOURCE_IRQ, gdd_mpu);
+ if (!irq) {
+ dev_err(pd-dev, GDD IRQ resource missing\n);
+ err = -ENXIO;
+ goto out_err;
+ }
+ omap_ssi-gdd_irq = irq-start;
You can use platform_get_irq_byname here.
Right. Will be changed in PATCHv2.
+static inline int ssi_of_get_available_child_count(const struct
device_node *np)
+{
+ struct device_node *child;
+ int num = 0;
+
+ for_each_child_of_node(np, child)
+ if (of_device_is_available(child))
+ num++;
+
+ return num;
+}
You can find of_get_available_child_count in linux/of.h.
That did not exist when I started with the DT conversion of the
driver.
That said, this seems to be trying to count the number of ports,
which should all be compatible with ti,omap3-ssi-port, no?
So maybe you should count all available child nodes compatible with
that.
I updated the function to check the compatible string
and use for_each_available_child_of_node(), which has
also been added after I wrote this function.
+static int __init ssi_probe(struct platform_device *pd)
+{
+ struct device_node *np = pd-dev.of_node;
+ struct hsi_controller *ssi;
+ int err;
+ int num_ports;
+
+ if (!np) {
+ dev_err(pd-dev, missing device tree data\n);
+ return -EINVAL;
+ }
+
+ num_ports = ssi_of_get_available_child_count(np);
+
+ ssi = hsi_alloc_controller(num_ports, GFP_KERNEL);
+ if (!ssi) {
+ dev_err(pd-dev, No memory for controller\n);
+ return -ENOMEM;
+ }
+
+ platform_set_drvdata(pd, ssi);
+
+ err = ssi_add_controller(ssi, pd);
+ if (err 0)
+ goto out1;
+
+ pm_runtime_irq_safe(pd-dev);
+ pm_runtime_enable(pd-dev);
+
+ err = ssi_hw_init(ssi);
+ if (err 0)
+ goto out2;
+#ifdef CONFIG_DEBUG_FS
+ err = ssi_debug_add_ctrl(ssi);
+ if (err 0)
+ goto out2;
+#endif
+
+ err = of_platform_populate(pd-dev.of_node, NULL, NULL, pd-dev);
I'm not keen on doing this because it allows arbitrary devices which are
not ssi ports to be placed in the ssi host controller node that will be
probed, which is nonsensical and something I'd like to avoid by
construction.
Is there any reason the ports have to be platform devices at all?
not strictly, but I get system resources via platform_get_resource_byname.
If so, is there no way we can register them directly and skip any other
devices?
I set the second parameter (matches) of the of_platform_populate()
call to a table containing the ssi-port compatible value.
+static int __exit ssi_remove(struct platform_device *pd)
+{
+ struct hsi_controller *ssi = platform_get_drvdata(pd);
+
+#ifdef CONFIG_DEBUG_FS
+ ssi_debug_remove_ctrl(ssi);
+#endif
+ ssi_remove_controller(ssi);
+ platform_set_drvdata(pd, NULL);
+
+ pm_runtime_disable(pd-dev);
+
+ /* cleanup of of_platform_populate() call */
+ device_for_each_child(pd-dev, NULL, ssi_remove_ports);
This would certainly be broken for a non ssi port device.
I never intended to support other subdevices, but this only
unregisters each subdevice, so its probably safe...
+static int omap_ssi_port_runtime_suspend(struct device *dev)
+{
+ struct hsi_port *port = dev_get_drvdata(dev);
+ struct omap_ssi_port *omap_port = hsi_port_drvdata(port);
+ struct hsi_controller *ssi = to_hsi_controller(port-device.parent);
+ struct omap_ssi_controller *omap_ssi = hsi_controller_drvdata(ssi);
+
+ dev_dbg(dev, port runtime suspend!\n);
+
+ ssi_set_port_mode(omap_port, SSI_MODE_SLEEP);
+ if (omap_ssi-get_loss)
+ omap_port-loss_count =
+ (*omap_ssi-get_loss)(ssi-device.parent);
You don't need to do (*struct-func)(args) when invoking a function
pointer. You can jsut have struct-func(args) as we do elsewhere. This
can be:
omap_ssi-get_loss(ssi-device.parent)
This should be fixed up in the other sites too.
Thanks, fixed everywhere.
-- Sebastian
signature.asc
Description: Digital signature
Re: [PATCHv2 03/16] Documentation: dt: add OMAP iommu bindings
On 02/26/2014 04:18 PM, Suman Anna wrote: Hi Laurent, On 02/26/2014 02:36 PM, Laurent Pinchart wrote: Hi Suman, On Wednesday 26 February 2014 14:23:03 Suman Anna wrote: On Wednesday 26 February 2014 11:02:24 Suman Anna wrote: On 02/25/2014 08:13 PM, Laurent Pinchart wrote: On Tuesday 25 February 2014 17:02:35 Suman Anna wrote: On 02/25/2014 03:26 PM, Laurent Pinchart wrote: On Thursday 13 February 2014 12:15:34 Suman Anna wrote: From: Florian Vaussard florian.vauss...@epfl.ch This patch adds the iommu bindings for all OMAP2+ SoCs. Apart from the standard bindings used by OMAP peripherals, this patch uses a 'dma-window' (already used by Tegra SMMU) and adds two OMAP custom bindings - 'ti,#tlb-entries' and 'ti,iommu-bus-err-back'. Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch [s-a...@ti.com: split bindings document, add dra7 and bus error back] Signed-off-by: Suman Anna s-a...@ti.com --- .../devicetree/bindings/iommu/ti,omap-iommu.txt| 28 1 file changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt diff --git a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt new file mode 100644 index 000..116492d --- /dev/null +++ b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt @@ -0,0 +1,28 @@ +OMAP2+ IOMMU + +Required properties: +- compatible : Should be one of, +ti,omap2-iommu for OMAP2/OMAP3 IOMMU instances +ti,omap4-iommu for OMAP4/OMAP5 IOMMU instances +ti,dra7-iommu for DRA7xx IOMMU instances +- ti,hwmods : Name of the hwmod associated with the IOMMU instance +- reg: Address space for the configuration registers +- interrupts : Interrupt specifier for the IOMMU instance +- dma-window : IOVA start address and length Isn't the dma window more of a system configuration property than a hardware property ? How do you expect it to be set? We are setting it based on the addressable range for the MMU. A quick look at the ISP and IVA IOMMUs in the OMAP3 shows that both support the full 4GB VA space. Why do you need to restrict it ? I should have rephrased it better when I said addressable range. While the MMUs are capable of programming the full 4GB space, there are some address ranges that are private from the processor view. This window is currently used to set the range for the omap-iovmm driver (which only OMAP3 ISP is using atm), and there is no point in allowing the omap-iovmm driver the full range when the processor could never reach/access those addresses. But the IOMMU VA space is from a device point of view, not from a CPU point of view. Could you point me to where those private ranges are documented, in order to understand the problem correctly ? Yes, they are indeed from the device perspective. I meant DSP and/or IPU by processor. For example on OMAP3, you can refer to Table 2-9 in section 2.4.5 DSP Subsystem Memory Space Mapping of the OMAP36xx TRM, and the external addressable range starts from 0x1100. OK, so it looks more like a property of the IOMMU master than a property of the IOMMU itself. It would be better to express it as such, but I wonder how that could be done, and if it would be worth it in this case. This property is currently solely used to configure the range for the omap-iovmm module, which were supplied through platform data in the non-DT case. I am wondering if the way to go here is to use iommu_domain_set_attr() and use the domain geometry values. The other option is to supply these as driver match data, and switching the compatible strings to identify the MMU instance precisely. regards Suman As not all masters (the OMAP3 ISP doesn't for instance) have restrictions regarding the VA range they can address, should this property be at least made optional ? We are reusing the existing defined property and it allows us to get rid of the IOVA start and end addresses defined in the pre-DT OMAP iommu platform data. +Optional properties: +- ti,#tlb-entries : Number of entries in the translation look-aside buffer. +Should be either 8 or 32 (default: 32) +- ti,iommu-bus-err-back : Indicates the IOMMU instance supports throwing + back a bus error response on MMU faults. Do these features vary per IOMMU instance or per IOMMU model ? In the latter case they could be inferred from the compatible string by the driver without requiring them to be explicit in DT (whether you want to do so is left to you though). Well, these are fixed features given an IOMMU instance, like the OMAP3 ISP is the only one that has 8 TLB entries, all the remaining ones have 32, and the IPU iommu instances are the only ones that support the bus error response back. I have no preference to any particular way, and sure the driver can infer these easily based on unique compatible strings per subsystem per SoC. I just happened to go with defining
Re: [PATCHv2 03/16] Documentation: dt: add OMAP iommu bindings
Hi Laurent, On Wednesday 26 February 2014 16:28:08 Suman Anna wrote: On 02/26/2014 04:18 PM, Suman Anna wrote: On 02/26/2014 02:36 PM, Laurent Pinchart wrote: On Wednesday 26 February 2014 14:23:03 Suman Anna wrote: On Wednesday 26 February 2014 11:02:24 Suman Anna wrote: On 02/25/2014 08:13 PM, Laurent Pinchart wrote: On Tuesday 25 February 2014 17:02:35 Suman Anna wrote: On 02/25/2014 03:26 PM, Laurent Pinchart wrote: On Thursday 13 February 2014 12:15:34 Suman Anna wrote: From: Florian Vaussard florian.vauss...@epfl.ch This patch adds the iommu bindings for all OMAP2+ SoCs. Apart from the standard bindings used by OMAP peripherals, this patch uses a 'dma-window' (already used by Tegra SMMU) and adds two OMAP custom bindings - 'ti,#tlb-entries' and 'ti,iommu-bus-err-back'. Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch [s-a...@ti.com: split bindings document, add dra7 and bus error back] Signed-off-by: Suman Anna s-a...@ti.com --- .../devicetree/bindings/iommu/ti,omap-iommu.txt| 28 + 1 file changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt diff --git a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt new file mode 100644 index 000..116492d --- /dev/null +++ b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt @@ -0,0 +1,28 @@ +OMAP2+ IOMMU + +Required properties: +- compatible : Should be one of, +ti,omap2-iommu for OMAP2/OMAP3 IOMMU instances +ti,omap4-iommu for OMAP4/OMAP5 IOMMU instances +ti,dra7-iommu for DRA7xx IOMMU instances +- ti,hwmods : Name of the hwmod associated with the IOMMU instance +- reg: Address space for the configuration registers +- interrupts : Interrupt specifier for the IOMMU instance +- dma-window : IOVA start address and length Isn't the dma window more of a system configuration property than a hardware property ? How do you expect it to be set? We are setting it based on the addressable range for the MMU. A quick look at the ISP and IVA IOMMUs in the OMAP3 shows that both support the full 4GB VA space. Why do you need to restrict it ? I should have rephrased it better when I said addressable range. While the MMUs are capable of programming the full 4GB space, there are some address ranges that are private from the processor view. This window is currently used to set the range for the omap-iovmm driver (which only OMAP3 ISP is using atm), and there is no point in allowing the omap-iovmm driver the full range when the processor could never reach/access those addresses. But the IOMMU VA space is from a device point of view, not from a CPU point of view. Could you point me to where those private ranges are documented, in order to understand the problem correctly ? Yes, they are indeed from the device perspective. I meant DSP and/or IPU by processor. For example on OMAP3, you can refer to Table 2-9 in section 2.4.5 DSP Subsystem Memory Space Mapping of the OMAP36xx TRM, and the external addressable range starts from 0x1100. OK, so it looks more like a property of the IOMMU master than a property of the IOMMU itself. It would be better to express it as such, but I wonder how that could be done, and if it would be worth it in this case. This property is currently solely used to configure the range for the omap-iovmm module, which were supplied through platform data in the non-DT case. If I'm not mistaken omap-iovmm is something we want to get rid of. I know that the OMAP3 ISP driver is the only user of that module, and I've started working on fixing that, but I'm currently lacking time to complete the work. Now, if we get rid of omap-iovmm, does that mean that the dma-window property won't need to be specified anymore ? If so, given that the only omap-iovmm user is the OMAP3 ISP driver, I would propose to drop the property and just hardcode the value. Yeah, none of our OMAP4+ stacks use omap-iovmm, or similar dynamic reservation scheme at the moment. I am perfectly fine with dropping the property and hard-coding it in the driver with a note. DSP/Bridge has a similar usage (in dmm.c), but that code is localized within the driver. Thanks for all the comments. regards Suman Please let me know if there's something I've missed. I am wondering if the way to go here is to use iommu_domain_set_attr() and use the domain geometry values. The other option is to supply these as driver match data, and switching the compatible strings to identify the MMU instance precisely. regards Suman As not all masters (the OMAP3 ISP doesn't for instance) have restrictions regarding the VA range they can address, should this property be at least made optional ? We are reusing the existing defined property and it allows us to get rid of the IOVA start and end addresses defined in the pre-DT OMAP iommu platform data. [snip] -- To unsubscribe from
Re: [PATCHv1 3/6] HSI: hsi-char: add Device Tree support
On Mon, Feb 24, 2014 at 03:13:01PM +, Mark Rutland wrote:
On Sun, Feb 23, 2014 at 11:49:58PM +, Sebastian Reichel wrote:
Add of_match_table to hsi_char driver, so that it can
be referenced from Device Tree.
Signed-off-by: Sebastian Reichel s...@debian.org
---
drivers/hsi/clients/hsi_char.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/hsi/clients/hsi_char.c b/drivers/hsi/clients/hsi_char.c
index e61e5f9..7f64bed 100644
--- a/drivers/hsi/clients/hsi_char.c
+++ b/drivers/hsi/clients/hsi_char.c
@@ -42,6 +42,7 @@
#include linux/stat.h
#include linux/hsi/hsi.h
#include linux/hsi/hsi_char.h
+#include linux/of_device.h
#define HSC_DEVS 16 /* Num of channels */
#define HSC_MSGS 4
@@ -758,12 +759,22 @@ static int hsc_remove(struct device *dev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id hsi_char_of_match[] = {
+ { .compatible = ssi-char, },
This string is undocumented.
+ { .compatible = hsi-char, },
I'm not sure either string makes sense though; this feels like a binding
for the sake of the driver rather than describing the device and
allowing the driver to pick it up if it makes sense to do so.
What exactly is a ssi-char device or a hsi-char device?
mh. I guess I will update the hsi framework, so that it simply loads
the client driver for each registered port. This is indeed only a
binding to load the driver.
-- Sebastian
signature.asc
Description: Digital signature
Re: [PATCH 1/8] clk: divider: fix rate calculation for fractional rates
Quoting Tero Kristo (2014-02-14 05:45:22)
On 02/13/2014 12:03 PM, Tomi Valkeinen wrote:
clk-divider.c does not calculate the rates consistently at the moment.
As an example, on OMAP3 we have a clock divider with a source clock of
86400 Hz. With dividers 6, 7 and 8 the theoretical rates are:
6: 14400
7: 123428571.428571...
8: 10800
Calling clk_round_rate() with the rate in the first column will give the
rate in the second column:
14400 - 14400
14399 - 123428571
123428572 - 123428571
123428571 - 10800
Note how clk_round_rate() returns 123428571 for rates from 123428572 to
14399, which is mathematically correct, but when clk_round_rate() is
called with 123428571, the returned value is surprisingly 10800.
This means that the following code works a bit oddly:
rate = clk_round_rate(clk, 123428572);
clk_set_rate(clk, rate);
As clk_set_rate() also does clock rate rounding, the result is that the
clock is set to the rate of 10800, not 123428571 returned by the
clk_round_rate.
This patch changes the clk-divider.c to use DIV_ROUND_UP when
calculating the rate. This gives the following behavior which fixes the
inconsistency:
14400 - 14400
14399 - 123428572
123428572 - 123428572
123428571 - 10800
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Mike Turquette mturque...@linaro.org
---
drivers/clk/clk-divider.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 5543b7df8e16..ec22112e569f 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -24,7 +24,7 @@
* Traits of this clock:
* prepare - clk_prepare only ensures that parents are prepared
* enable - clk_enable only ensures that parents are enabled
- * rate - rate is adjustable. clk-rate = parent-rate / divisor
+ * rate - rate is adjustable. clk-rate = DIV_ROUND_UP(parent-rate /
divisor)
* parent - fixed parent. No clk_set_parent support
*/
@@ -115,7 +115,7 @@ static unsigned long clk_divider_recalc_rate(struct
clk_hw *hw,
return parent_rate;
}
- return parent_rate / div;
+ return DIV_ROUND_UP(parent_rate, div);
}
/*
@@ -185,7 +185,7 @@ static int clk_divider_bestdiv(struct clk_hw *hw,
unsigned long rate,
}
parent_rate = __clk_round_rate(__clk_get_parent(hw-clk),
MULT_ROUND_UP(rate, i));
- now = parent_rate / i;
+ now = DIV_ROUND_UP(parent_rate, i);
if (now = rate now best) {
bestdiv = i;
best = now;
@@ -207,7 +207,7 @@ static long clk_divider_round_rate(struct clk_hw *hw,
unsigned long rate,
int div;
div = clk_divider_bestdiv(hw, rate, prate);
- return *prate / div;
+ return DIV_ROUND_UP(*prate, div);
}
static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,
@@ -218,7 +218,7 @@ static int clk_divider_set_rate(struct clk_hw *hw,
unsigned long rate,
unsigned long flags = 0;
u32 val;
- div = parent_rate / rate;
+ div = DIV_ROUND_UP(parent_rate, rate);
value = _get_val(divider, div);
if (value div_mask(divider))
Basically the patch looks good to me, but it might be good to have a
testing round of sort with this. It can potentially cause regressions on
multiple boards if the drivers happen to rely on the broken clock
rates. Same for patch #2 which is a copy paste of this one, but only
impacts TI boards.
Agreed. I've taken patches #1 #2 into clk-next. Let's let them stew in
-next for a while and see if anyone's board catches on fire.
Regards,
Mike
-Tero
--
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: [RFC PATCH 1/6] PM / Voltagedomain: Add generic clk notifier handler for regulator based dynamic voltage scaling
On 14:56-20140225, Nishanth Menon wrote: On 02/24/2014 11:51 PM, Mike Turquette wrote: Quoting Nishanth Menon (2014-02-18 12:32:18) [...] I'm not sure about trying to capture the voltdm as a core concept. It feels a bit unwieldy to me. Considering it is a simple collation of regulators and SoC specific magic which have to be operated in tandem to clock operation, Why does it seem unwieldy? Usage of multiple voltage planes in a single voltage domain concept does not seem unique to TI processors either: For example, imx6q-cpufreq.c uses 3 regulators (arm, pu, soc), s5pv210-cpufreq.c uses two regulators (vddarm, vddint), ideally OMAP implementation would use two (vdd_mpu, vbb_mpu). I have wondered about making an abstract performance domain which is the dvfs analogue to generic power domains. This a reasonable split since gpd are good for idle power savings (e.g. clock gate, power gate, sleep state, etc) and perf domains would be good for active power savings (dvfs). Having a generic container for performance domains might make a good place to stuff all of this glue logic that we keep running into (e.g. CPU and GPU max frequencies that are related), and it might make another nice knob for the thermal folks to use. This sounds like one level higher abstraction that we are speaking of here? I was'nt intending to solve the bigger picture problem here - just an abstraction level that might allow reusablity for multiple SoCs. In fact, having an abstraction away for voltage domain(which may consist of multiple regulators and any SoC specific magic) purely allows us to move towards a direction you mention here. For the case of the OMAP voltage domains, it would be a place to stuff all of the VC/VP - ABB - Smart Reflex AVS stuff. Unfortunately, I dont completely comprehend objection we have to this approach (other than an higher level abstraction is needed) and if we do have an objection, what is the alternate approach should be for representing hardware which this series attempts to present. I think the following is around the lines of your thought direction - if Rafael or others have comments on the following approach, it'd be a good starting point for me to progress. --8-- From 62e50b9f920495db88e5594aa6bceb52e83a443d Mon Sep 17 00:00:00 2001 From: Nishanth Menon n...@ti.com Date: Wed, 26 Feb 2014 10:59:59 -0600 Subject: [PATCH] PM / Runtime: introduce active power management callbacks for pm_domain dev_pm_domain currently handles just device idle power management using the generic pm_runtime_get|put and related family of functions. Logically with appropriate pm_domain hooks this can translate to hardware specific clock and related operations. Given that pm_domains may contain this information, this provides an opportunity to extend current pm_runtime do dynamic power operations as well. What this means for drivers is as follows: Today, drivers(with some level of complexity) do: pm_runtime_get_sync(dev); clk = clk_get(dev, name); old_rate = clk_get_rate(clk); ... clk_set_rate(clk, new_rate); ... clk_put(clk); pm_runtime_get_sync(dev); Instead, on pm_domains that can handle this as part of pm_domain-active_ops functions, They can now do the following: pm_runtime_get_sync(dev); old_rate = pm_runtime_get_rate(dev); ... pm_runtime_set_rate(dev, new_rate); ... pm_runtime_put_sync(dev); Obviously, this'd work for devices that handle a single main functional clock, but this could reduce complexity of drivers having to deal with power management details to have pm_runtime as the main point of interface. CAVEAT: For power domains that are capable of handling multiple clocks (example on OMAP, where there are the concepts of interface, functional and optional clocks per block), appropriate handling will be necessary from pm_domain callbacks. So, the question about which clock rate is being controlled or returned to is entirely upto the pm_domain implementation. On the otherhand, we can debate about defining and querying ACPI style Performance state instead of frequencies and wrap P-states inside or the other way around.. but given that majority of drivers using pm_runtime would rather be interested in frequencies and my naieve belief that we can index P-states with frequencies, kind of influenced my choice here of proposing frequencies as base query parameter.. ofcourse, debate is still open here. Yes, we can still debate if providing yet another wrapper on top of clock APIs makes sense at all as well. Nyet-signed-off-by: Nishanth Menon n...@ti.com --- drivers/base/power/runtime.c | 101 ++ include/linux/pm.h | 25 +-- include/linux/pm_runtime.h | 21 + 3 files changed, 143 insertions(+), 4 deletions(-) diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c index 72e00e6..ef230b4 100644 --- a/drivers/base/power/runtime.c +++ b/drivers/base/power/runtime.c
Re: [RFC PATCH 1/6] PM / Voltagedomain: Add generic clk notifier handler for regulator based dynamic voltage scaling
Quoting Nishanth Menon (2014-02-26 18:34:55)
+/**
+ * pm_runtime_get_rate() - Returns the device operational frequency
+ * @dev: Device to handle
+ * @rate: Returns rate in Hz.
+ *
+ * Returns appropriate error value in case of error conditions, else
+ * returns 0 and rate is updated. The pm_domain logic does all the necessary
+ * operation (which may consider magic hardware stuff) to provide the rate.
+ *
+ * NOTE: the rate returned is a snapshot and in many cases just a bypass
+ * to clk api to set the rate.
+ */
+int pm_runtime_get_rate(struct device *dev, unsigned long *rate)
Instead of rate, how about we use level and leave it undefined as to
what that means? It would be equally valid for level to represent a
clock rate, or an opp from a table of opp's, or a p-state, or some value
passed to a PM microcontroller.
Code that is tightly coupled to the hardware would simply know what
value to use with no extra sugar.
Generic code would need to get the various supported levels populated
at run time, but a DT binding could do that, or a query to the ACPI
tables, or whatever.
+{
+ unsigned long flags;
+ int error = -ENOSYS;
+
+ if (!rate || !dev)
+ return -EINVAL;
+
+ spin_lock_irqsave(dev-power.lock, flags);
+ if (!pm_runtime_active(dev)) {
+ error = -EINVAL;
+ goto out;
+ }
+
+ if (dev-pm_domain dev-pm_domain-active_ops.get_rate)
+ error = dev-pm_domain-active_ops.get_rate(dev, rate);
+out:
+ spin_unlock_irqrestore(dev-power.lock, flags);
+
+ return error;
+}
+
+/**
+ * pm_runtime_set_rate() - Set a specific rate for the device operation
+ * @dev: Device to handle
+ * @rate: Rate to set in Hz
+ *
+ * Returns appropriate error value in case of error conditions, else
+ * returns 0. The pm_domain logic does all the necessary operation (which
+ * may include voltage scale operations or other magic hardware stuff) to
+ * achieve the operation. It is guarenteed that the requested rate is
achieved
+ * on returning from this function if return value is 0.
+ */
+int pm_runtime_set_rate(struct device *dev, unsigned long rate)
Additionally I wonder if the function signature should include a way to
specify the sub-unit of a device that we are operating on? This is a way
to tackle the issues you raised regarding multiple clocks per device,
etc. Two approaches come to mind:
int pm_runtime_set_rate(struct device *dev, int index,
unsigned long rate);
Where index is a sub-unit of struct device *dev. The second approach is
to create a publicly declared structure representing the sub-unit. Some
variations on that theme:
int pm_runtime_set_rate(struct perf_domain *perfdm, unsigned long rate);
or,
int pm_runtime_set_rate(struct generic_power_domain *gpd,
unsigned long rate);
or whatever that sub-unit looks like. The gpd thing might be a total
layering violation, I don't know. Or perhaps it's a decent idea but it
shouldn't be as a PM runtime call. Again, I dunno.
Regards,
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
Re: Help running latest linux-omap kernel on Nokia N810
On 26/02/14 23:29, Aaro Koskinen wrote: First the bad news: display support is not in the mainline kernel. Also since linux-omap tree follows the mainline, it's not there either anymore. Tomi removed the n8x0 panel driver some time ago (I don't know why), but even then it wasn't working as the platform data failed to set up some It would've been a big effort to keep the panel driver compiling, as we moved to a new display driver architecture. And, as it wasn't working anyway, I deemed it simpler to just remove it. I have no objections to add it back, but it needs to be split into two separate drivers, blizzard encoder driver and the panel driver. The RFBI driver also probably needs some love. And, of course, DT support for all those. In theory, RFBI is relatively simple. If I recall right, the panel is also quite simple, although it still needs to be controlled via SPI. Blizzard was a bit more complex one, but perhaps most of its features can be just left out. But getting all those three working fine without being able to make any measurements between the components, well, one might needs some luck there =). I do have N800 and N810 (no serial mods), so I might be able to give some help there at some point, if I'm able to boot the board with usb gadget ethernet (which hasn't been working for me for omap3 for some time). Tomi signature.asc Description: OpenPGP digital signature
