Re: [PATCH v3 0/7] USB support for DRA7-evm
Hi Kishon, Could you please pick the first 2 patches in this series for phy-next? They are independent of the rest. Thanks. cheers, -roger On 05/05/2014 12:54 PM, Roger Quadros wrote: Hi, This series enables the 2 USB ports on the DRA7-evm. NOTE: USB1 port is hard coded to work in peripheral mode and USB2 port in host mode. This is due to missing ID pin interrupt in pre ver.E boards. USB1 port doesn't in peripheral mode out of the box due to missing VBUS detection and mailbox write. To test this I had to do a manual write to enable VBUSVALID in the USB_UTMI_OTG_STATUS register. omapconf set bit 0x48880084 1 USB2 port works well in host mode. Patches are based on 3.15-rc3. cheers, -roger Changelog: v3: -Rearraged patches. PHY related stuff first. -Addressed backward compatibility issue for phy-omap-usb2. v2: -Rebased on v3.15-rc3 --- Roger Quadros (7): phy: omap-usb2: Use generic clock names wkupclk and refclk phy: omap-usb2: Add clock names to Documentation binding ARM: dts: omap4+: Add clocks to USB2 PHY node ARM: dts: dra7-clock: Add l3init_960m_gfclk clock gate ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss ARM: dts: dra7: Add USB related nodes dts: dra7-evm: add USB support Documentation/devicetree/bindings/phy/ti-phy.txt | 7 ++ arch/arm/boot/dts/dra7-evm.dts | 24 arch/arm/boot/dts/dra7.dtsi | 149 +++ arch/arm/boot/dts/dra7xx-clocks.dtsi | 12 +- arch/arm/boot/dts/omap4.dtsi | 2 + arch/arm/boot/dts/omap5.dtsi | 2 + arch/arm/mach-omap2/omap_hwmod_7xx_data.c| 22 ++-- drivers/phy/phy-omap-usb2.c | 30 +++-- 8 files changed, 229 insertions(+), 19 deletions(-) -- 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/RFC 3/4] of/clk: Register clocks suitable for Runtime PM with the PM core
On 2 May 2014 16:35, Geert Uytterhoeven ge...@linux-m68k.org wrote:
Hi Ulf,
On Fri, May 2, 2014 at 10:56 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
+static int of_clk_pm_runtime_suspend(struct device *dev)
+{
+ int ret;
+
+ ret = pm_generic_runtime_suspend(dev);
+ if (ret)
+ return ret;
+
+ ret = pm_clk_suspend(dev);
What about slow clocks? Those aren't handled with pm_clk_suspend().
How are slow clocks handled?
clk_prepare|unprepare - these functions may sleep.
Kind regards
Ulf Hansson
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like
that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-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/RFC 3/4] of/clk: Register clocks suitable for Runtime PM with the PM core
On 2 May 2014 16:58, Geert Uytterhoeven ge...@linux-m68k.org wrote:
Hi Ulf, Tomasz,
On Fri, May 2, 2014 at 10:13 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
+static int of_clk_register(struct device *dev, struct clk *clk)
+{
+ int error;
+
+ if (!dev-pm_domain) {
+ error = pm_clk_create(dev);
+ if (error)
+ return error;
+
+ dev-pm_domain = of_clk_pm_domain;
I am concerned about how this will work in conjunction with the
generic power domain.
A device can't reside in more than one pm_domain; thus I think it
would be better to always use the generic power domain and not have a
specific one for clocks. Typically the genpd should invoke
pm_clk_resume|suspend from it's runtime PM callbacks.
I'm not sure about this. A typical use case would be to gate clocks ASAP and
then wait until device is idle long enough to consider turning off the power
domain worthwhile. Also sometimes we may want to gate the clocks, but
prevent power domain from being powered off to retain hardware state (e.g.
because there is no way to read it and restore later).
So, in principle you prefer to have driver's handle clock gating to
save power from their runtime PM callbacks, instead of from the power
domain, right? Just to clarify, that's my view as well.
If there's both a gate clock and a power domain, and the driver's Runtime PM
callbacks handle clock gating, who's handling the power domain?
This is my view, not sure everybody agrees :-)
1. If you have a hardware power domain you need to implement a
pm_domain (preferably use the generic power domain).
2. If you don't have a hardware power domain, but still cares about
having a centralized solution for dev_pm_qos - you may use the generic
power domain, since it supports this.
3. If none of the above, you don't need a pm_domain at all.
Kind regards
Ulf Hansson
Gr{oetje,eeting}s,
Geert (still trying to fit all pieces of the
puzzle together)
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like
that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-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 v4 0/4] ARM: OMAP: SATA support for OMAP5 DRA7
Hi Tony, On 04/23/2014 08:30 PM, Roger Quadros wrote: Hi Tony, These are the pending HWMOD and DTS patches to get SATA working on OMAP5-uevm and DRA7-evm. Please queue them for -next. Thanks. gentle reminder. Thanks. cheers, -roger --- Balaji T K (2): ARM: dts: omap5: add sata node ARM: dts: dra7: add OCP2SCP3 and SATA nodes Keshava Munegowda (1): ARM: OMAP5: hwmod: Add ocp2scp3 and sata hwmods Nikhil Devshatwar (1): ARM: DRA7: hwmod: Add ocp2scp3 and sata hwmods arch/arm/boot/dts/dra7.dtsi| 39 arch/arm/boot/dts/omap5.dtsi | 40 arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 73 ++ arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 31 +++-- 4 files changed, 178 insertions(+), 5 deletions(-) -- 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] mfd: twl6040: Correct HPPLL configuration for 19.2 and 38.4 MHz mclk
When the MCLK is 19.2 or 38.4 MHz the HPPLL need to be enabled and can be put in bypass mode. This will fix HPPLL use on boards with 19.2MHz mclk. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- drivers/mfd/twl6040.c | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c index 12b314ea48dc..ae26d84b3a59 100644 --- a/drivers/mfd/twl6040.c +++ b/drivers/mfd/twl6040.c @@ -441,12 +441,9 @@ int twl6040_set_pll(struct twl6040 *twl6040, int pll_id, TWL6040_HPLLENA; break; case 1920: - /* - * PLL disabled - * (enable PLL if MCLK jitter quality - * doesn't meet specification) - */ - hppllctl |= TWL6040_MCLK_19200KHZ; + /* PLL enabled, bypass mode */ + hppllctl |= TWL6040_MCLK_19200KHZ | + TWL6040_HPLLBP | TWL6040_HPLLENA; break; case 2600: /* PLL enabled, active mode */ @@ -454,9 +451,9 @@ int twl6040_set_pll(struct twl6040 *twl6040, int pll_id, TWL6040_HPLLENA; break; case 3840: - /* PLL enabled, active mode */ + /* PLL enabled, bypass mode */ hppllctl |= TWL6040_MCLK_38400KHZ | - TWL6040_HPLLENA; + TWL6040_HPLLBP | TWL6040_HPLLENA; break; default: dev_err(twl6040-dev, -- 1.9.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 v3 4/7] ARM: dts: dra7-clock: Add l3init_960m_gfclk clock gate
On 05/05/2014 12:54 PM, Roger Quadros wrote:
This clock gate description is missing in the older Reference manuals.
It is present on the SoC to provide 960MHz reference clock to the
internal USB PHYs.
Reference: DRA75x_DRA74x_ES1.1_NDA_TRM_vO.pdf, pg. 900,
Table 3-812. CM_COREAON_L3INIT_60M_GFCLK_CLKCTRL
Use l3init_960m_gfclk as parent of usb_otg_ss1_refclk960m and
usb_otg_ss2_refclk960m.
CC: Benoît Cousson bcous...@baylibre.com
CC: Tero Kristo t-kri...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
Got myself to download the latest copy of the TRM, so this patch looks
valid.
Acked-by: Tero Kristo t-kri...@ti.com
---
arch/arm/boot/dts/dra7xx-clocks.dtsi | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index cfb8fc7..c767687 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -1386,6 +1386,14 @@
ti,dividers = 1, 8;
};
+ l3init_960m_gfclk: l3init_960m_gfclk {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = dpll_usb_clkdcoldo;
+ ti,bit-shift = 8;
+ reg = 0x06c0;
+ };
+
dss_32khz_clk: dss_32khz_clk {
#clock-cells = 0;
compatible = ti,gate-clock;
@@ -1533,7 +1541,7 @@
usb_otg_ss1_refclk960m: usb_otg_ss1_refclk960m {
#clock-cells = 0;
compatible = ti,gate-clock;
- clocks = dpll_usb_clkdcoldo;
+ clocks = l3init_960m_gfclk;
ti,bit-shift = 8;
reg = 0x13f0;
};
@@ -1541,7 +1549,7 @@
usb_otg_ss2_refclk960m: usb_otg_ss2_refclk960m {
#clock-cells = 0;
compatible = ti,gate-clock;
- clocks = dpll_usb_clkdcoldo;
+ clocks = l3init_960m_gfclk;
ti,bit-shift = 8;
reg = 0x1340;
};
--
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 1/2 v2] ASoC: Add HA (HEAD acoustics) DSP codec driver template
This codec driver template represents an I2C controlled multichannel audio
codec that has many typical ASoC codec driver features like volume controls,
mixer stages, mux selection, output power control, in-codec audio routings,
codec bias management and DAI link configuration.
This driver is based on an early version provided by Jarkko Nikula.
Signed-off-by: Jarkko Nikula jarkko.nik...@bitmer.com
Signed-off-by: Stefan Roese s...@denx.de
Cc: Thorsten Eisbein thorsten.eisb...@head-acoustics.de
Cc: Lars-Peter Clausen l...@metafoo.de
Cc: Mark Brown broo...@kernel.org
---
v2:
- Added/changed copyright line
- Changed authorship (as suggested by Jarkko the original author)
- Added Thorsten as maintainer
- Remove ha_dsp_hw_params() and ha_dsp_set_dai_fmt() as its not used
(only needed for CODEC as clock master which is currently not suported).
- Removed some unneeded include files
- const char *const foo used instead of const char *foo
- SOC_MIXER_ARRAY() helper macro used
- Removed ha_dsp_set_bias_level() and use default implementation
- Use codec-dev instead of codec-dev-parent in dev_get_regmap()
- Added CODEC reset to probe
- Remove ret in ha_dsp_i2c_probe()
sound/soc/codecs/Kconfig | 4 +
sound/soc/codecs/Makefile | 2 +
sound/soc/codecs/ha-dsp.c | 333 ++
sound/soc/codecs/ha-dsp.h | 50 +++
4 files changed, 389 insertions(+)
create mode 100644 sound/soc/codecs/ha-dsp.c
create mode 100644 sound/soc/codecs/ha-dsp.h
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index f0e8401..f357988 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -51,6 +51,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_DA732X if I2C
select SND_SOC_DA9055 if I2C
select SND_SOC_BT_SCO
+ select SND_SOC_HA_DSP if I2C
select SND_SOC_ISABELLE if I2C
select SND_SOC_JZ4740_CODEC
select SND_SOC_LM4857 if I2C
@@ -343,6 +344,9 @@ config SND_SOC_BT_SCO
config SND_SOC_DMIC
tristate
+config SND_SOC_HA_DSP
+ tristate
+
config SND_SOC_HDMI_CODEC
tristate HDMI stub CODEC
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 3c4d275..f296bec 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -39,6 +39,7 @@ snd-soc-da732x-objs := da732x.o
snd-soc-da9055-objs := da9055.o
snd-soc-bt-sco-objs := bt-sco.o
snd-soc-dmic-objs := dmic.o
+snd-soc-ha-dsp-objs := ha-dsp.o
snd-soc-isabelle-objs := isabelle.o
snd-soc-jz4740-codec-objs := jz4740.o
snd-soc-l3-objs := l3.o
@@ -190,6 +191,7 @@ obj-$(CONFIG_SND_SOC_DA732X)+= snd-soc-da732x.o
obj-$(CONFIG_SND_SOC_DA9055) += snd-soc-da9055.o
obj-$(CONFIG_SND_SOC_BT_SCO) += snd-soc-bt-sco.o
obj-$(CONFIG_SND_SOC_DMIC) += snd-soc-dmic.o
+obj-$(CONFIG_SND_SOC_HA_DSP) += snd-soc-ha-dsp.o
obj-$(CONFIG_SND_SOC_ISABELLE) += snd-soc-isabelle.o
obj-$(CONFIG_SND_SOC_JZ4740_CODEC) += snd-soc-jz4740-codec.o
obj-$(CONFIG_SND_SOC_L3) += snd-soc-l3.o
diff --git a/sound/soc/codecs/ha-dsp.c b/sound/soc/codecs/ha-dsp.c
new file mode 100644
index 000..5a3c7ef
--- /dev/null
+++ b/sound/soc/codecs/ha-dsp.c
@@ -0,0 +1,333 @@
+/*
+ * ha-dsp.c -- HA DSP ALSA SoC Audio driver
+ *
+ * Copyright 2011-2014 HEAD acoustics GmbH
+ *
+ * Authors:
+ * Jarkko Nikula jarkko.nik...@bitmer.com
+ * Stefan Roese s...@denx.de
+ * Thorsten Eisbein thorsten.eisb...@head-acoustics.de
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * Maintainer: Thorsten Eisbein thorsten.eisb...@head-acoustics.de
+ */
+
+#include linux/module.h
+#include linux/i2c.h
+#include linux/regmap.h
+#include sound/core.h
+#include sound/pcm.h
+#include sound/pcm_params.h
+#include sound/soc.h
+
+#include ha-dsp.h
+
+/* Reset default register values for soc-cache */
+static const struct reg_default ha_dsp_reg_defaults[] = {
+ { 0x00, 0x00 },
+ { 0x01, 0x55 },
+ { 0x02, 0x55 },
+ { 0x03, 0x00 },
+ { 0x04, 0x00 },
+ { 0x05, 0x00 },
+ { 0x06, 0x00 },
+ { 0x07, 0x00 },
+ { 0x08, 0x02 },
+ { 0x09, 0x02 },
+ { 0x0a, 0x02 },
+ { 0x0b, 0x02 },
+ { 0x0c, 0x02 },
+ { 0x0d, 0x02 },
+ { 0x0e, 0x02 },
+ { 0x0f, 0x02 },
+};
+
+/* DSP mode selection */
+static const char *const ha_dsp_mode_texts[] = {Mode 1, Mode 2};
+static SOC_ENUM_SINGLE_DECL(ha_dsp_mode_enum, HA_DSP_CTRL, 0,
+ ha_dsp_mode_texts);
+
+/* Monitor output mux selection */
+static const char *const ha_dsp_monitor_texts[] = {Off, ADC, DAC};
+static SOC_ENUM_SINGLE_DECL(ha_dsp_monitor_enum, HA_DSP_CTRL, 1,
+ ha_dsp_monitor_texts);
+
+static const struct snd_kcontrol_new ha_dsp_monitor_control =
+ SOC_DAPM_ENUM(Route, ha_dsp_monitor_enum);
+
+/* Output mixers */
+static const
[PATCH 2/2 v2] ASoC: omap: Add HA (HEAD acoustics) DSP add-on card audio driver for TAO3530
HA DSP card which features a HA DSP audio codec is intended to be connected
to TAO-3530 (or BeagleBoard) using McBSP3 for digital audio and I2C bus for
codec control. A GPIO signal from CPU to codec is used to request clock
signals active.
This machine driver has a special feature to support linked streams where
playback and capture can be triggered HW simultaneously. This is implemented
for linked streams by activating/deactivating the clock request signal to
codec only after both streams are ready to start/stop. For non-linked streams
the request signal is active whenever there is a stream active.
The GPIO used to synchronize the clock for playback and record
is now configured via the DT as well (no #define any more). When
this GPIO is not configured in the DT, the sync clock feature is
disabled.
Slave mode is not supported any more (was never really tested). So
this version has the slave mode removed.
Also the now recommended card registration via
devm_snd_soc_register_card() is used instead of platform_device_add().
This driver is based on an early version provided by Jarkko Nikula.
Signed-off-by: Jarkko Nikula jarkko.nik...@bitmer.com
Signed-off-by: Stefan Roese s...@denx.de
Cc: Thorsten Eisbein thorsten.eisb...@head-acoustics.de
Cc: Lars-Peter Clausen l...@metafoo.de
Cc: Mark Brown broo...@kernel.org
---
v2:
- Added/changed copyright line
- Changed authorship (as suggested by Jarkko the original author)
- Added Thorsten as maintainer
- Moved DT bindings documention into this patch
- ha_dsp_codec_slave removed as its currently not used
- devm_snd_soc_register_card() used
.../devicetree/bindings/sound/omap3-ha.txt | 27 +++
sound/soc/omap/Kconfig | 11 +
sound/soc/omap/Makefile| 2 +
sound/soc/omap/ha-dsp-card.c | 250 +
4 files changed, 290 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/omap3-ha.txt
create mode 100644 sound/soc/omap/ha-dsp-card.c
diff --git a/Documentation/devicetree/bindings/sound/omap3-ha.txt
b/Documentation/devicetree/bindings/sound/omap3-ha.txt
new file mode 100644
index 000..09eccda
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/omap3-ha.txt
@@ -0,0 +1,27 @@
+OMAP3 HA (HEAD acoustics) audio controller
+
+Required properties:
+- compatible: ha,ha-dsp-card for OMAP3-HA board (TAO3530 based)
+- ti,model: Name of the sound card (for example omap3-ha)
+- ti,mcbsp: phandle for the McBSP node
+- ti,codec: phandle for the twl4030 audio node
+- gpios: GPIO used to sync the clock for playback and record
+
+Example:
+sound2 {
+ compatible = ha,ha-dsp-card;
+ ti,model = omap3-ha;
+
+ /* McBSP3 is used for HA-DSP */
+ ti,mcbsp = mcbsp3;
+ ti,codec = soc_audio;
+
+ /* GPIO to sync the clock for playback and record */
+ gpios = gpio2 12 GPIO_ACTIVE_LOW;/* GPIO 44 */
+};
diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
index e006593..86cc869 100644
--- a/sound/soc/omap/Kconfig
+++ b/sound/soc/omap/Kconfig
@@ -117,3 +117,14 @@ config SND_OMAP_SOC_OMAP3_PANDORA
select SND_SOC_TWL4030
help
Say Y if you want to add support for SoC audio on the OMAP3 Pandora.
+
+config SND_OMAP_SOC_HA_DSP_CARD
+ tristate SoC Audio support for HA DSP add-on card
+ depends on TWL4030_CORE SND_OMAP_SOC
+ depends on SND_OMAP_SOC_OMAP_TWL4030
+ select SND_OMAP_SOC_MCBSP
+ select SND_SOC_TWL4030
+ select SND_SOC_HA_DSP
+ help
+ Say Y if you want to add support for Soc audio on HA DSP add-on card
+ for TAO-3530/Thunder or BeagleBoard
diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile
index a725905..02c0094 100644
--- a/sound/soc/omap/Makefile
+++ b/sound/soc/omap/Makefile
@@ -21,6 +21,7 @@ snd-soc-omap-abe-twl6040-objs := omap-abe-twl6040.o
snd-soc-omap-twl4030-objs := omap-twl4030.o
snd-soc-omap3pandora-objs := omap3pandora.o
snd-soc-omap-hdmi-card-objs := omap-hdmi-card.o
+snd-soc-ha-dsp-card-objs := ha-dsp-card.o
obj-$(CONFIG_SND_OMAP_SOC_N810) += snd-soc-n810.o
obj-$(CONFIG_SND_OMAP_SOC_RX51) += snd-soc-rx51.o
@@ -31,3 +32,4 @@ obj-$(CONFIG_SND_OMAP_SOC_OMAP_ABE_TWL6040) +=
snd-soc-omap-abe-twl6040.o
obj-$(CONFIG_SND_OMAP_SOC_OMAP_TWL4030) += snd-soc-omap-twl4030.o
obj-$(CONFIG_SND_OMAP_SOC_OMAP3_PANDORA) += snd-soc-omap3pandora.o
obj-$(CONFIG_SND_OMAP_SOC_OMAP_HDMI) += snd-soc-omap-hdmi-card.o
+obj-$(CONFIG_SND_OMAP_SOC_HA_DSP_CARD) += snd-soc-ha-dsp-card.o
diff --git a/sound/soc/omap/ha-dsp-card.c b/sound/soc/omap/ha-dsp-card.c
new file mode 100644
index 000..36821ca
--- /dev/null
+++ b/sound/soc/omap/ha-dsp-card.c
@@ -0,0 +1,250 @@
+/*
+ * ha-dsp-card.c -- SoC audio HA-DSP add-on card for TAO-3530
+ *
+ * Copyright 2011-2014 HEAD acoustics GmbH
+ *
+ * Authors:
+ * Jarkko Nikula jarkko.nik...@bitmer.com
+ * Stefan Roese s...@denx.de
+ * Thorsten Eisbein
RE: [PATCH v3 0/4] add parallel NAND support for TI's new OMAPx and AMxx platforms (Part-2)
Hello Tony, From: Gupta, Pekon *changes v2 - v3* rebased on git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap :master merged leftover patches (dra7-evm and am43x-epos-evm fix) from Part-1 series Can you please see if this series can be taken in for 3.16 ? As this series concludes GPMC-NAND support for all major OMAP boards and brings it to a stable point. with regards, pekon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Resend/PATCH] arm: dts: dra7: Add qspi device.
These add device tree entry for qspi controller driver on dra7-evm.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
Depends on sricharan's irq crossbar.
arch/arm/boot/dts/dra7-evm.dts | 80
arch/arm/boot/dts/dra7.dtsi| 14 +++
2 files changed, 94 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 5babba0..62f4256 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -93,6 +93,21 @@
0x24c (PIN_INPUT_SLEW | MUX_MODE0) /* uart3_txd */
;
};
+
+ qspi1_pins: pinmux_qspi1_pins {
+ pinctrl-single,pins =
+ 0x4c (PIN_INPUT | MUX_MODE1) /* gpmc_a3.qspi1_cs2 */
+ 0x50 (PIN_INPUT | MUX_MODE1) /* gpmc_a4.qspi1_cs3 */
+ 0x74 (PIN_INPUT | MUX_MODE1) /* gpmc_a13.qspi1_rtclk */
+ 0x78 (PIN_INPUT | MUX_MODE1) /* gpmc_a14.qspi1_d3 */
+ 0x7c (PIN_INPUT | MUX_MODE1) /* gpmc_a15.qspi1_d2 */
+ 0x80 (PIN_INPUT | MUX_MODE1) /* gpmc_a16.qspi1_d1 */
+ 0x84 (PIN_INPUT | MUX_MODE1) /* gpmc_a17.qspi1_d0 */
+ 0x88 (PIN_INPUT | MUX_MODE1) /* qpmc_a18.qspi1_sclk */
+ 0xb8 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_cs2.qspi1_cs0 */
+ 0xbc (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_cs3.qspi1_cs1 */
+ ;
+ };
};
i2c1 {
@@ -273,3 +288,68 @@
cpu0 {
cpu0-supply = smps123_reg;
};
+
+qspi {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = qspi1_pins;
+
+ spi-max-frequency = 4800;
+ m25p80@0 {
+ compatible = s25fl256s1;
+ spi-max-frequency = 4800;
+ reg = 0;
+ spi-tx-bus-width = 1;
+ spi-rx-bus-width = 4;
+ spi-cpol;
+ spi-cpha;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ /* MTD partition table.
+* The ROM checks the first four physical blocks
+* for a valid file to boot and the flash here is
+* 64KiB block size.
+*/
+ partition@0 {
+ label = QSPI.SPL;
+ reg = 0x 0x1;
+ };
+ partition@1 {
+ label = QSPI.SPL.backup1;
+ reg = 0x0001 0x0001;
+ };
+ partition@2 {
+ label = QSPI.SPL.backup2;
+ reg = 0x0002 0x0001;
+ };
+ partition@3 {
+ label = QSPI.SPL.backup3;
+ reg = 0x0003 0x0001;
+ };
+ partition@4 {
+ label = QSPI.u-boot;
+ reg = 0x0004 0x0010;
+ };
+ partition@5 {
+ label = QSPI.u-boot-spl-os;
+ reg = 0x0014 0x0001;
+ };
+ partition@6 {
+ label = QSPI.u-boot-env;
+ reg = 0x0015 0x0001;
+ };
+ partition@7 {
+ label = QSPI.u-boot-env.backup1;
+ reg = 0x0016 0x001;
+ };
+ partition@8 {
+ label = QSPI.kernel;
+ reg = 0x0017 0x080;
+ };
+ partition@9 {
+ label = QSPI.file-system;
+ reg = 0x0097 0x0169;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index d93311a..a4557b4 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -798,6 +798,20 @@
dma-names = tx0, rx0;
status = disabled;
};
+
+ qspi: qspi@4b30 {
+ compatible = ti,dra7xxx-qspi;
+ reg = 0x4b30 0x100;
+ reg-names = qspi_base;
+ #address-cells = 1;
+ #size-cells = 0;
+ ti,hwmods = qspi;
+ clocks = qspi_gfclk_div;
+ clock-names = fck;
+ num-cs = 4;
+ interrupts = 0 343 0x4;
+ status = disabled;
+ };
};
crossbar_mpu: crossbar@4a02 {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [v2 Patch 1/6] drivers: reset: TI: SoC reset controller support.
Felipe
Thanks for the comments
On 05/05/2014 04:33 PM, Felipe Balbi wrote:
Hi,
On Mon, May 05, 2014 at 03:09:22PM -0500, Dan Murphy wrote:
The TI SoC reset controller support utilizes the
reset controller framework to give device drivers or
function drivers a common set of APIs to call to reset
a module.
The reset-ti is a common interface to the reset framework.
The register data is retrieved during initialization
of the reset driver through the reset-ti-data
file. The array of data is associated with the compatible from the
respective DT entry.
Once the data is available then this is derefenced within the common
interface.
The device driver has the ability to assert, deassert or perform a
complete reset.
This code was derived from previous work by Rajendra Nayak and Afzal
Mohammed.
The code was changed to adopt to the reset core and abstract away the SoC
information.
you should break your commit log at around 72 characters at most.
Do you mean 72 characters per line?
Signed-off-by: Dan Murphy dmur...@ti.com
---
drivers/reset/Kconfig|1 +
drivers/reset/Makefile |1 +
drivers/reset/ti/Kconfig |8 ++
drivers/reset/ti/Makefile|1 +
drivers/reset/ti/reset-ti-data.h | 56
drivers/reset/ti/reset-ti.c | 267
++
6 files changed, 334 insertions(+)
create mode 100644 drivers/reset/ti/Kconfig
create mode 100644 drivers/reset/ti/Makefile
create mode 100644 drivers/reset/ti/reset-ti-data.h
create mode 100644 drivers/reset/ti/reset-ti.c
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 0615f50..a58d789 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -13,3 +13,4 @@ menuconfig RESET_CONTROLLER
If unsure, say no.
source drivers/reset/sti/Kconfig
+source drivers/reset/ti/Kconfig
this driver is so small that I'm not sure you need a directory for it.
Yeah. Carry over from v1 when we had the object data files which made
things bigger I will put them back.
diff --git a/drivers/reset/ti/Kconfig b/drivers/reset/ti/Kconfig
new file mode 100644
index 000..dcdce90
--- /dev/null
+++ b/drivers/reset/ti/Kconfig
@@ -0,0 +1,8 @@
+config RESET_TI
+depends on RESET_CONTROLLER
don't you want to depend on ARCH_OMAP || COMPILE_TEST ?
Yes
diff --git a/drivers/reset/ti/reset-ti-data.h
b/drivers/reset/ti/reset-ti-data.h
new file mode 100644
index 000..4d2a6d5
--- /dev/null
+++ b/drivers/reset/ti/reset-ti-data.h
@@ -0,0 +1,56 @@
+/*
+ * PRCM reset driver for TI SoC's
+ *
+ * Copyright 2014 Texas Instruments Inc.
this is not the TI aproved way for copyright notices. Yeah,
nit-picking...
Hmm. Will need to look at other TI files to correct then.
+ * Author: Dan Murphy dmur...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _RESET_TI_DATA_H_
+#define _RESET_TI_DATA_H_
+
+#include linux/kernel.h
+#include linux/reset-controller.h
+
+/**
+ * struct ti_reset_reg_data - Structure of the reset register information
+ * for a particular SoC.
+ * @rstctrl_offs: This is the reset control offset value from
+ * from the parent reset node.
+ * @rstst_offs: This is the reset status offset value from
+ * from the parent reset node.
+ * @rstctrl_bit: This is the reset control bit for the module.
+ * @rstst_bit: This is the reset status bit for the module.
+ *
+ * This structure describes the reset register control and status offsets.
+ * The bits are also defined for the same.
+ */
+struct ti_reset_reg_data {
+void __iomem *reg_base;
+u32 rstctrl_offs;
+u32 rstst_offs;
+u32 rstctrl_bit;
+u32 rstst_bit;
this structure can be folded into struct ti_reset_data and all of that
can be initialized during probe.
I could do that. It will simplify the de-referencing as well.
+};
+
+/**
+ * struct ti_reset_data - Structure that contains the reset register data
+ * as well as the total number of resets for a particular SoC.
+ * @reg_data: Pointer to the register data structure.
+ * @nr_resets: Total number of resets for the SoC in the reset array.
+ *
+ * This structure contains a pointer to the register data and the modules
+ * register base. The number of resets and reset controller device data is
+ * stored within this structure.
+ *
+ */
+struct ti_reset_data {
+struct ti_reset_reg_data *reg_data;
+struct reset_controller_dev rcdev;
+};
+
+#endif
this entire file can be moved into the .c file. It's too small and the
only user for these new types is the .c driver anyway.
This was another carry over from v1 when I had other data within.
So I can collapse this now.
diff --git a/drivers/reset/ti/reset-ti.c
[PATCH] DTS: ARM: OMAP3-N900: use MATRIX_KEY for keymap
Use MATRIX_KEY macro from dt-bindings/input/input.h
to make the keyboard matrix human readable.
Signed-off-by: Sebastian Reichel s...@kernel.org
---
arch/arm/boot/dts/omap3-n900.dts | 103 ---
1 file changed, 52 insertions(+), 51 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 9ba1f08..288a8b9 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -10,6 +10,7 @@
/dts-v1/;
#include omap34xx-hs.dtsi
+#include dt-bindings/input/input.h
/ {
model = Nokia N900;
@@ -325,57 +326,57 @@
};
twl_keypad {
- linux,keymap = 0x0010 /* KEY_Q */
-0x00010018 /* KEY_O */
-0x00020019 /* KEY_P */
-0x00030033 /* KEY_COMMA */
-0x0004000e /* KEY_BACKSPACE */
-0x0006001e /* KEY_A */
-0x0007001f /* KEY_S */
-
-0x0111 /* KEY_W */
-0x01010020 /* KEY_D */
-0x01020021 /* KEY_F */
-0x01030022 /* KEY_G */
-0x01040023 /* KEY_H */
-0x01050024 /* KEY_J */
-0x01060025 /* KEY_K */
-0x01070026 /* KEY_L */
-
-0x0212 /* KEY_E */
-0x02010034 /* KEY_DOT */
-0x02020067 /* KEY_UP */
-0x0203001c /* KEY_ENTER */
-0x0205002c /* KEY_Z */
-0x0206002d /* KEY_X */
-0x0207002e /* KEY_C */
-0x02080043 /* KEY_F9 */
-
-0x0313 /* KEY_R */
-0x0301002f /* KEY_V */
-0x03020030 /* KEY_B */
-0x03030031 /* KEY_N */
-0x03040032 /* KEY_M */
-0x03050039 /* KEY_SPACE */
-0x03060039 /* KEY_SPACE */
-0x03070069 /* KEY_LEFT */
-
-0x0414 /* KEY_T */
-0x0401006c /* KEY_DOWN */
-0x0402006a /* KEY_RIGHT */
-0x0404001d /* KEY_LEFTCTRL */
-0x04050064 /* KEY_RIGHTALT */
-0x0406002a /* KEY_LEFTSHIFT */
-0x04080044 /* KEY_F10 */
-
-0x0515 /* KEY_Y */
-0x05080057 /* KEY_F11 */
-
-0x0616 /* KEY_U */
-
-0x0717 /* KEY_I */
-0x07010041 /* KEY_F7 */
-0x07020042 /* KEY_F8 */
+ linux,keymap = MATRIX_KEY(0x00, 0x00, KEY_Q)
+MATRIX_KEY(0x00, 0x01, KEY_O)
+MATRIX_KEY(0x00, 0x02, KEY_P)
+MATRIX_KEY(0x00, 0x03, KEY_COMMA)
+MATRIX_KEY(0x00, 0x04, KEY_BACKSPACE)
+MATRIX_KEY(0x00, 0x06, KEY_A)
+MATRIX_KEY(0x00, 0x07, KEY_S)
+
+MATRIX_KEY(0x01, 0x00, KEY_W)
+MATRIX_KEY(0x01, 0x01, KEY_D)
+MATRIX_KEY(0x01, 0x02, KEY_F)
+MATRIX_KEY(0x01, 0x03, KEY_G)
+MATRIX_KEY(0x01, 0x04, KEY_H)
+MATRIX_KEY(0x01, 0x05, KEY_J)
+MATRIX_KEY(0x01, 0x06, KEY_K)
+MATRIX_KEY(0x01, 0x07, KEY_L)
+
+MATRIX_KEY(0x02, 0x00, KEY_E)
+MATRIX_KEY(0x02, 0x01, KEY_DOT)
+MATRIX_KEY(0x02, 0x02, KEY_UP)
+MATRIX_KEY(0x02, 0x03, KEY_ENTER)
+MATRIX_KEY(0x02, 0x05, KEY_Z)
+MATRIX_KEY(0x02, 0x06, KEY_X)
+MATRIX_KEY(0x02, 0x07, KEY_C)
+MATRIX_KEY(0x02, 0x08, KEY_F9)
+
+MATRIX_KEY(0x03, 0x00, KEY_R)
+MATRIX_KEY(0x03, 0x01, KEY_V)
+MATRIX_KEY(0x03, 0x02, KEY_B)
+MATRIX_KEY(0x03, 0x03, KEY_N)
+MATRIX_KEY(0x03, 0x04, KEY_M)
+MATRIX_KEY(0x03, 0x05, KEY_SPACE)
+MATRIX_KEY(0x03, 0x06, KEY_SPACE)
+MATRIX_KEY(0x03, 0x07, KEY_LEFT)
+
+MATRIX_KEY(0x04, 0x00, KEY_T)
+MATRIX_KEY(0x04, 0x01, KEY_DOWN)
+MATRIX_KEY(0x04, 0x02, KEY_RIGHT)
+MATRIX_KEY(0x04, 0x04, KEY_LEFTCTRL)
+MATRIX_KEY(0x04, 0x05, KEY_RIGHTALT)
+MATRIX_KEY(0x04, 0x06, KEY_LEFTSHIFT)
+MATRIX_KEY(0x04, 0x08, KEY_F10)
+
+
Re: [RFC] [v2 Patch 2/6] ARM: TI: Describe the ti reset DT entries
Tony
Thanks for the comments
On 05/05/2014 05:01 PM, Tony Lindgren wrote:
* Dan Murphy dmur...@ti.com [140505 13:10]:
+
+Required parent properties:
+- compatible : Should be one of,
+ti,omap4-prm for OMAP4 PRM instances
+ti,omap5-prm for OMAP5 PRM instances
+ti,dra7-prm for DRA7xx PRM instances
+ti,am4-prcm for AM43xx PRCM instances
+ti,am3-prcm for AM33xx PRCM instances
+
+Required child reset property:
+- compatible : Should be
+resets for All TI SoCs
+
+example:
+prm: prm@4ae06000 {
+compatible = ti,omap5-prm;
+reg = 0x4ae06000 0x3000;
+
+prm_resets: resets {
+#address-cells = 1;
+#size-cells = 1;
+#reset-cells = 1;
+};
+};
The reg entries you have in the example below has different format
compared to this?
This is the parent to the resets. The reg entries below are for
the child reset signals.
+Reset node declaration
+==
+The reset node is declared in a parent child relationship. The main parent
+is the PRCM module which contains the base address. The first child within
+the reset parent declares the target modules reset name. This is followed
by
+the control and status offsets.
+
+Within the first reset child node is a secondary child node which declares
the
+reset signal of interest. Under this node the control and status bits
+are declared. These bits declare the bit mask for the target reset.
+
+
+Required properties:
+reg - This is the register offset from the PRCM parent.
+This must be declared as:
+
+reg = control register offset,
+ status register offset;
+
+control-bit - This is the bit within the register which controls the reset
+of the target module. This is declared as a bit mask for the register.
+status-bit - This is the bit within the register which contains the status
of
+the reset of the target module.
+This is declared as a bit mask for the register.
+
+example:
+prm_resets {
+dsp_rstctrl {
+reg = 0x1c00,
+ 0x1c04;
Shouldn't this be start and size instead of start and end here?
I could do start and size. But the size will be the same for each register.
AM33xx really hurts the consistency model here as the other patches in the
series
it appears that the control and status are consistent but AM33xx the registers
are all over
the place.
I have not looked at OMAP2-4 yet for control and status register offsets.
+dsp_reset: dsp_reset {
+control-bit = 0x01;
+status-bit = 0x01;
+};
+};
+};
Are the control-bit and status-bit always the same? If so, you can
keep that knowlede private to the the driver.
No there is a case in the am33xx resets file where the status and control bits
are not the same.
And maybe you can have the bit offset in a reg property here to
avoid adding any custom properties? Something like:
dsp_reset: reset@1 {
reg = 1;
};
If reg is not suitable for that, it seems that some generic property
to describe the bit offset is needed by quite a few drivers
anyways, for things like clocks and regulators.
I will have to look into this. Maybe a generic entry called bit-offset
that defines the bit or a mask for the registers. It can mimic the reg
entry.
+Client Node Declaration
+==
+This is the consumer of the parent node to declare what resets this
+particular module is interested in.
+
+example:
+src: src@55082000 {
+resets = reset_src phandle;
+reset-names = reset_name;
+};
+
+Required Properties:
+reset_src - This is the parent DT entry for the reset controller
+phandle - This is the phandle of the specific reset to be used by the clien
+driver.
+reset-names - This is the reset name of module that the device driver
+needs to be able to reset. This value must correspond to a value within
+the reset controller array.
+
+example:
+resets = prm_resets dsp_mmu_reset;
+reset-names = dsp_mmu_reset;
This part looks OK to me, not sure if we need the reset-names property
if we have one already why not.
reset-names are part of the reset.txt file. I could probably drop the resets
and reset-name information here
and point to the reset.txt file for further explanation.
Regards,
Tony
--
--
Dan Murphy
--
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 v2 0/2] clk: Support for Palmas clk32kg and clk32kgaudio clocks
Hi, Changes since v1: - binding documentation and driver has been separated based on Nishanth Menon's comment v1 of the driver can be found: https://lkml.org/lkml/2014/4/3/104 Palmas class of devices can provide 32K clock(s) to be used by other devices on the board. Depending on the actual device the provided clocks can be: CLK32K_KG and CLK32K_KGAUDIO or only one: CLK32K_KG (TPS659039 for example) Use separate compatible flags for the two 32K clock. A system which needs or have only one of the 32k clock from Palmas will need to add node(s) for each clock as separate section in the dts file. The two compatible property is: ti,palmas-clk32kg for clk32kg clock ti,palmas-clk32kgaudio for clk32kgaudio clock Apart from the register control of the clocks - which is done via the clock API there is a posibility to enable the external sleep control. In this way the clock can be enabled/disabled on demand by the user of the clock. Regards, Peter --- Peter Ujfalusi (2): dt/bindings: Binding documentation for Palmas clk32kg and clk32kgaudio clocks clk: Add driver for Palmas clk32kg and clk32kgaudio clocks .../bindings/clock/clk-palmas-clk32kg-clocks.txt | 35 +++ drivers/clk/Kconfig| 7 + drivers/clk/Makefile | 1 + drivers/clk/clk-palmas.c | 307 + include/dt-bindings/mfd/palmas.h | 18 ++ 5 files changed, 368 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/clk-palmas-clk32kg-clocks.txt create mode 100644 drivers/clk/clk-palmas.c create mode 100644 include/dt-bindings/mfd/palmas.h -- 1.9.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 v2 2/2] clk: Add driver for Palmas clk32kg and clk32kgaudio clocks
Palmas class of devices can provide 32K clock(s) to be used by other devices
on the board. Depending on the actual device the provided clocks can be:
CLK32K_KG and CLK32K_KGAUDIO
or only one:
CLK32K_KG (TPS659039 for example)
Use separate compatible flags for the two 32K clock.
A system which needs or have only one of the 32k clock from
Palmas will need to add node(s) for each clock as separate section
in the dts file.
The two compatible property is:
ti,palmas-clk32kg for clk32kg clock
ti,palmas-clk32kgaudio for clk32kgaudio clock
Apart from the register control of the clocks - which is done via
the clock API there is a posibility to enable the external sleep
control. In this way the clock can be enabled/disabled on demand by the
user of the clock.
See the documentation for more details.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/clk/Kconfig | 7 ++
drivers/clk/Makefile | 1 +
drivers/clk/clk-palmas.c | 307 +++
3 files changed, 315 insertions(+)
create mode 100644 drivers/clk/clk-palmas.c
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 6f56d3a4f010..a070b77a1e17 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -109,6 +109,13 @@ config COMMON_CLK_KEYSTONE
Supports clock drivers for Keystone based SOCs. These SOCs have local
a power sleep control module that gate the clock to the IPs and PLLs.
+config COMMON_CLK_PALMAS
+ tristate Clock driver for TI Palmas devices
+ depends on MFD_PALMAS
+ ---help---
+ This driver supports TI Palmas devices 32KHz output KG and KG_AUDIO
+ using common clock framework.
+
source drivers/clk/qcom/Kconfig
endmenu
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 5f8a28735c96..d67214debc12 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
obj-$(CONFIG_ARCH_MOXART) += clk-moxart.o
obj-$(CONFIG_ARCH_NOMADIK) += clk-nomadik.o
obj-$(CONFIG_ARCH_NSPIRE) += clk-nspire.o
+obj-$(CONFIG_COMMON_CLK_PALMAS)+= clk-palmas.o
obj-$(CONFIG_CLK_PPC_CORENET) += clk-ppc-corenet.o
obj-$(CONFIG_COMMON_CLK_S2MPS11) += clk-s2mps11.o
obj-$(CONFIG_COMMON_CLK_SI5351)+= clk-si5351.o
diff --git a/drivers/clk/clk-palmas.c b/drivers/clk/clk-palmas.c
new file mode 100644
index ..781630e1372b
--- /dev/null
+++ b/drivers/clk/clk-palmas.c
@@ -0,0 +1,307 @@
+/*
+ * Clock driver for Palmas device.
+ *
+ * Copyright (c) 2013, NVIDIA Corporation.
+ * Copyright (c) 2013-2014 Texas Instruments, Inc.
+ *
+ * Author: Laxman Dewangan ldewan...@nvidia.com
+ * Peter Ujfalusi peter.ujfal...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any kind,
+ * whether express or implied; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include linux/clk.h
+#include linux/clkdev.h
+#include linux/clk-provider.h
+#include linux/mfd/palmas.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/platform_device.h
+#include linux/slab.h
+
+#define PALMAS_CLOCK_DT_EXT_CONTROL_ENABLE11
+#define PALMAS_CLOCK_DT_EXT_CONTROL_ENABLE22
+#define PALMAS_CLOCK_DT_EXT_CONTROL_NSLEEP 3
+
+struct palmas_clk32k_desc {
+ const char *clk_name;
+ unsigned int control_reg;
+ unsigned int enable_mask;
+ unsigned int sleep_mask;
+ unsigned int sleep_reqstr_id;
+ int delay;
+};
+
+struct palmas_clock_info {
+ struct device *dev;
+ struct clk *clk;
+ struct clk_hw hw;
+ struct palmas *palmas;
+ struct palmas_clk32k_desc *clk_desc;
+ int ext_control_pin;
+};
+
+static inline struct palmas_clock_info *to_palmas_clks_info(struct clk_hw *hw)
+{
+ return container_of(hw, struct palmas_clock_info, hw);
+}
+
+static unsigned long palmas_clks_recalc_rate(struct clk_hw *hw,
+unsigned long parent_rate)
+{
+ return 32768;
+}
+
+static int palmas_clks_prepare(struct clk_hw *hw)
+{
+ struct palmas_clock_info *cinfo = to_palmas_clks_info(hw);
+ int ret;
+
+ ret = palmas_update_bits(cinfo-palmas, PALMAS_RESOURCE_BASE,
+cinfo-clk_desc-control_reg,
+cinfo-clk_desc-enable_mask,
+cinfo-clk_desc-enable_mask);
+ if (ret 0)
+ dev_err(cinfo-dev, Reg 0x%02x update failed, %d\n,
+ cinfo-clk_desc-control_reg, ret);
+ else if (cinfo-clk_desc-delay)
[PATCH v2 1/2] dt/bindings: Binding documentation for Palmas clk32kg and clk32kgaudio clocks
Palmas class of devices can provide 32K clock(s) to be used by other devices
on the board. Depending on the actual device the provided clocks can be:
CLK32K_KG and CLK32K_KGAUDIO
or only one:
CLK32K_KG (TPS659039 for example)
Use separate compatible flags for the two 32K clock.
A system which needs or have only one of the 32k clock from
Palmas will need to add node(s) for each clock as separate section
in the dts file.
The two compatible property is:
ti,palmas-clk32kg for clk32kg clock
ti,palmas-clk32kgaudio for clk32kgaudio clock
Apart from the register control of the clocks - which is done via
the clock API there is a posibility to enable the external sleep
control. In this way the clock can be enabled/disabled on demand by the
user of the clock.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
.../bindings/clock/clk-palmas-clk32kg-clocks.txt | 35 ++
include/dt-bindings/mfd/palmas.h | 18 +++
2 files changed, 53 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/clk-palmas-clk32kg-clocks.txt
create mode 100644 include/dt-bindings/mfd/palmas.h
diff --git
a/Documentation/devicetree/bindings/clock/clk-palmas-clk32kg-clocks.txt
b/Documentation/devicetree/bindings/clock/clk-palmas-clk32kg-clocks.txt
new file mode 100644
index ..4208886d834a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/clk-palmas-clk32kg-clocks.txt
@@ -0,0 +1,35 @@
+* Palmas 32KHz clocks *
+
+Palmas device has two clock output pins for 32KHz, KG and KG_AUDIO.
+
+This binding uses the common clock binding ./clock-bindings.txt.
+
+Required properties:
+- compatible : ti,palmas-clk32kg for clk32kg clock
+ ti,palmas-clk32kgaudio for clk32kgaudio clock
+- #clock-cells : shall be set to 0.
+
+Optional property:
+- ti,external-sleep-control: The external enable input pins controlled the
+ enable/disable of clocks. The external enable input pins ENABLE1,
+ ENABLE2 and NSLEEP. The valid values for the external pins are:
+ PALMAS_EXT_CONTROL_PIN_ENABLE1 for ENABLE1 pin
+ PALMAS_EXT_CONTROL_PIN_ENABLE2 for ENABLE2 pin
+ PALMAS_EXT_CONTROL_PIN_NSLEEP for NSLEEP pin
+ Option 0 or missing this property means the clock is enabled/disabled
+ via register access and these pins do not have any control.
+ The macros of external control pins for DTS is defined at
+ dt-bindings/mfd/palmas.h
+
+Example:
+ #include dt-bindings/mfd/palmas.h
+ ...
+ palmas: tps65913@58 {
+ ...
+ clk32kg: palmas_clk32k@0 {
+ compatible = ti,palmas-clk32kg;
+ #clock-cells = 0;
+ ti,external-sleep-control =
PALMAS_EXT_CONTROL_PIN_NSLEEP;
+ };
+ ...
+ };
diff --git a/include/dt-bindings/mfd/palmas.h b/include/dt-bindings/mfd/palmas.h
new file mode 100644
index ..2c8ac4841385
--- /dev/null
+++ b/include/dt-bindings/mfd/palmas.h
@@ -0,0 +1,18 @@
+/*
+ * This header provides macros for Palmas device bindings.
+ *
+ * Copyright (c) 2013, NVIDIA Corporation.
+ *
+ * Author: Laxman Dewangan ldewan...@nvidia.com
+ *
+ */
+
+#ifndef __DT_BINDINGS_PALMAS_H__
+#define __DT_BINDINGS_PALMAS_H
+
+/* External control pins */
+#define PALMAS_EXT_CONTROL_PIN_ENABLE1 1
+#define PALMAS_EXT_CONTROL_PIN_ENABLE2 2
+#define PALMAS_EXT_CONTROL_PIN_NSLEEP 3
+
+#endif /* __DT_BINDINGS_PALMAS_H */
--
1.9.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 v2 0/2] clk: Support for Palmas clk32kg and clk32kgaudio clocks
On 16:24-20140506, Peter Ujfalusi wrote: Hi, Changes since v1: - binding documentation and driver has been separated based on Nishanth Menon's comment v1 of the driver can be found: https://lkml.org/lkml/2014/4/3/104 Palmas class of devices can provide 32K clock(s) to be used by other devices on the board. Depending on the actual device the provided clocks can be: CLK32K_KG and CLK32K_KGAUDIO or only one: CLK32K_KG (TPS659039 for example) Use separate compatible flags for the two 32K clock. A system which needs or have only one of the 32k clock from Palmas will need to add node(s) for each clock as separate section in the dts file. The two compatible property is: ti,palmas-clk32kg for clk32kg clock ti,palmas-clk32kgaudio for clk32kgaudio clock Apart from the register control of the clocks - which is done via the clock API there is a posibility to enable the external sleep control. In this way the clock can be enabled/disabled on demand by the user of the clock. Regards, Peter --- Peter Ujfalusi (2): dt/bindings: Binding documentation for Palmas clk32kg and clk32kgaudio clocks clk: Add driver for Palmas clk32kg and clk32kgaudio clocks .../bindings/clock/clk-palmas-clk32kg-clocks.txt | 35 +++ drivers/clk/Kconfig| 7 + drivers/clk/Makefile | 1 + drivers/clk/clk-palmas.c | 307 + include/dt-bindings/mfd/palmas.h | 18 ++ 5 files changed, 368 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/clk-palmas-clk32kg-clocks.txt create mode 100644 drivers/clk/clk-palmas.c create mode 100644 include/dt-bindings/mfd/palmas.h -- 1.9.2 Series: Reviewed-by: Nishanth Menon n...@ti.com -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/17] ARM: dts: DRA7: Add divider table to optfclk_pciephy_div clock
From: Keerthy j-keer...@ti.com Add divider table to optfclk_pciephy_div clock. The Documentation for divider clock can be found at ../clock/ti/divider.txt Cc: Rajendra Nayak rna...@ti.com Cc: Tero Kristo t-kri...@ti.com Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Keerthy j-keer...@ti.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- arch/arm/boot/dts/dra7xx-clocks.dtsi |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi b/arch/arm/boot/dts/dra7xx-clocks.dtsi index c767687..55e95c5 100644 --- a/arch/arm/boot/dts/dra7xx-clocks.dtsi +++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi @@ -1170,6 +1170,7 @@ clocks = apll_pcie_ck; #clock-cells = 0; reg = 0x021c; + ti,dividers = 2, 1; ti,bit-shift = 8; ti,max-div = 2; }; -- 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 15/17] ARM: OMAP: Enable PCI for DRA7
Now that we have added PCIe driver for DRA7 SOCs, enable PCI on DRA7 SOCs. Cc: Tony Lindgren t...@atomide.com Cc: Rob Herring robh...@kernel.org Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- arch/arm/mach-omap2/Kconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index cb31d43..b179e80 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -75,6 +75,8 @@ config SOC_DRA7XX select ARM_GIC select HAVE_ARM_ARCH_TIMER select IRQ_CROSSBAR + select MIGHT_HAVE_PCI + select ARCH_SUPPORTS_MSI config ARCH_OMAP2PLUS bool -- 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
[TEMP PATCH 17/17] ARM: dts: dra7: Add *resets* property for PCIe dt node
Added *resets* and *reset-names* properies for PCIe dt node.
The documention for this node can be found @ ../bindings/pci/ti-pci.txt.
Cc: Dan Murphy dmur...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/dra7.dtsi |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 20b1a09..7bc0555 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1031,6 +1031,8 @@
ti,hwmods = pcie1;
phys = pcie1_phy;
phy-names = pcie-phy;
+ resets = prm_resets device_reset;
+ reset-names = reset;
};
sata: sata@4a141100 {
--
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 13/17] ARM: dts: dra7: Add dt data for PCIe PHY
Added dt data for PCIe PHY as a child node of ocp2scp3.
The documention for this node can be found @ ../bindings/phy/ti-phy.txt.
Cc: Tony Lindgren t...@atomide.com
Cc: Rob Herring robh...@kernel.org
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 0d3c8c0..653b5f6 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -903,6 +903,29 @@
clock-names = sysclk;
#phy-cells = 0;
};
+
+ pcie1_phy: pciephy@4a094000 {
+ compatible = ti,phy-pipe3-pcie;
+ reg = 0x4A094000 0x80, /* phy_rx */
+ 0x4A094400 0x64; /* phy_tx */
+ reg-names = phy_rx, phy_tx;
+ ctrl-module = omap_control_pcie1phy;
+ clocks = dpll_pcie_ref_ck,
+dpll_pcie_ref_m2ldo_ck,
+optfclk_pciephy_32khz,
+optfclk_pciephy_clk,
+optfclk_pciephy_div_clk,
+optfclk_pciephy_div,
+apll_pcie_in_clk_mux,
+pciesref_acs_clk_ck;
+ clock-names = dpll_ref, dpll_ref_m2,
+ wkupclk, refclk,
+ div-clk, phy-div,
+ apll_mux, refclk_ext;
+ #phy-cells = 0;
+ ti,hwmods = pcie1-phy;
+ ti,ext-clk;
+ };
};
omap_dwc3_1@4888 {
--
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
[TEMP PATCH 16/17] pci: host: pcie-dra7xx: use reset framework APIs to reset PCIe
Get reset nodes from dt and use reset framework APIs to reset PCIe.
This is needed since reset is handled by the SoC.
Cc: Dan Murphy dmur...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/pci/ti-pci.txt |2 ++
drivers/pci/host/pci-dra7xx.c| 10 ++
2 files changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt
b/Documentation/devicetree/bindings/pci/ti-pci.txt
index 6cb6f09..cfb95c0 100644
--- a/Documentation/devicetree/bindings/pci/ti-pci.txt
+++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
@@ -9,6 +9,8 @@ This node should have the properties described in
designware-pcie.txt.
- phys : the phandle for the PHY device (used by generic PHY framework)
- phy-names : the names of the PHY corresponding to the PHYs present in the
*phy* phandle.
+ - resets: phandle used if reset is handled be soc
+ - reset-names: name given to the phandle
Example:
pcie@5100 {
diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index a37c25c..17d64ee 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -20,6 +20,7 @@
#include linux/platform_device.h
#include linux/pm_runtime.h
#include linux/resource.h
+#include linux/reset.h
#include linux/types.h
#include pcie-designware.h
@@ -281,6 +282,7 @@ static int __init dra7xx_pcie_probe(struct platform_device
*pdev)
struct resource *res;
struct dra7xx_pcie *dra7xx;
struct device *dev = pdev-dev;
+ struct reset_control *rstc;
dra7xx = devm_kzalloc(pdev-dev, sizeof(*dra7xx), GFP_KERNEL);
if (!dra7xx)
@@ -304,6 +306,14 @@ static int __init dra7xx_pcie_probe(struct platform_device
*pdev)
if (!base)
return -ENOMEM;
+ rstc = devm_reset_control_get(dev, reset);
+ if (IS_ERR(rstc))
+ return PTR_ERR(rstc);
+
+ ret = reset_control_deassert(rstc);
+ if (ret)
+ return ret;
+
phy = devm_phy_get(dev, pcie-phy);
if (IS_ERR(phy))
return PTR_ERR(phy);
--
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 14/17] ARM: dts: dra7: Add dt data for PCIe controller
Added dt data for PCIe controller. This node contains dt data for
both the DRA7 part of designware controller and for the designware core.
The documention for this node can be found @ ../bindings/pci/ti-pci.txt.
Cc: Tony Lindgren t...@atomide.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Jingoo Han jg1@samsung.com
Cc: Rob Herring robh...@kernel.org
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 653b5f6..20b1a09 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1011,6 +1011,28 @@
};
};
+ pcie@5100 {
+ compatible = ti,dra7xx-pcie;
+ reg = 0x51002000 0x14c, 0x5100 0x2000;
+ reg-names = ti_conf, rc_dbics;
+ interrupts = 0 232 0x4, 0 233 0x4;
+ #address-cells = 3;
+ #size-cells = 2;
+ device_type = pci;
+ ti,device_type = 3;
+ ranges = 0x0800 0 0x20001000 0x20001000 0
0x2000
+ 0x8100 0 0 0x20003000 0
0x0001
+ 0x8200 0 0x20013000 0x20013000 0
0xffed000;
+ #interrupt-cells = 1;
+ base-mask = 0x 0x0fff;
+ num-lanes = 1;
+ interrupt-map-mask = 0 0 0 0;
+ interrupt-map = 0x0 0 gic 233;
+ ti,hwmods = pcie1;
+ phys = pcie1_phy;
+ phy-names = pcie-phy;
+ };
+
sata: sata@4a141100 {
compatible = snps,dwc-ahci;
reg = 0x4a14 0x1100, 0x4a141100 0x7;
--
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 11/17] ARM: dts: dra7xx-clocks: Add missing 32khz clocks used for PHY
Added missing 32khz clock used by PCIe PHY.
The documention for this node can be found @ ../bindings/clock/ti/gate.txt.
Cc: Tony Lindgren t...@atomide.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rob Herring robh...@kernel.org
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/dra7xx-clocks.dtsi |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index 44993ec..e1bd052 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -1165,6 +1165,14 @@
reg = 0x021c, 0x0220;
};
+ optfclk_pciephy_32khz: optfclk_pciephy_32khz@4a0093b0 {
+ compatible = ti,gate-clock;
+ clocks = sys_32k_ck;
+ #clock-cells = 0;
+ reg = 0x13b0;
+ ti,bit-shift = 8;
+ };
+
optfclk_pciephy_div: optfclk_pciephy_div@4a00821c {
compatible = ti,divider-clock;
clocks = apll_pcie_ck;
--
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 10/17] arm: dra7xx: Add hwmod data for pcie1 and pcie2 subsystems
Added hwmod data for pcie1 and pcie2 subsystem present in DRA7xx SOC.
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 55 +
1 file changed, 55 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 1282a42..a51fa7f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1231,6 +1231,43 @@ static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
};
/*
+ * 'PCIE' class
+ *
+ */
+
+static struct omap_hwmod_class dra7xx_pcie_hwmod_class = {
+ .name = pcie,
+};
+
+/* pcie1 */
+static struct omap_hwmod dra7xx_pcie1_hwmod = {
+ .name = pcie1,
+ .class = dra7xx_pcie_hwmod_class,
+ .clkdm_name = l3init_clkdm,
+ .main_clk = l4_root_clk_div,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_PCIE_CLKSTCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/* pcie2 */
+static struct omap_hwmod dra7xx_pcie2_hwmod = {
+ .name = pcie2,
+ .class = dra7xx_pcie_hwmod_class,
+ .clkdm_name = l3init_clkdm,
+ .main_clk = l4_root_clk_div,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_PCIE_CLKSTCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/*
* 'PCIE PHY' class
*
*/
@@ -2388,6 +2425,22 @@ static struct omap_hwmod_ocp_if dra7xx_l4_cfg__ocp2scp1
= {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_cfg - pcie1 */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pcie1 = {
+ .master = dra7xx_l4_cfg_hwmod,
+ .slave = dra7xx_pcie1_hwmod,
+ .clk= l4_root_clk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_cfg - pcie2 */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pcie2 = {
+ .master = dra7xx_l4_cfg_hwmod,
+ .slave = dra7xx_pcie2_hwmod,
+ .clk= l4_root_clk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* l4_cfg - pcie1 phy */
static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pcie1_phy = {
.master = dra7xx_l4_cfg_hwmod,
@@ -2751,6 +2804,8 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
__initdata = {
dra7xx_l4_cfg__mpu,
dra7xx_l4_cfg__ocp2scp1,
dra7xx_l4_cfg__ocp2scp3,
+ dra7xx_l4_cfg__pcie1,
+ dra7xx_l4_cfg__pcie2,
dra7xx_l4_cfg__pcie1_phy,
dra7xx_l4_cfg__pcie2_phy,
dra7xx_l3_main_1__qspi,
--
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 12/17] ARM: dts: dra7: Add dt data for PCIe PHY control module
Added dt data for PCIe PHY control module used by PCIe PHY.
The documention for this node can be found @ ../bindings/phy/ti-phy.txt
Cc: Tony Lindgren t...@atomide.com
Cc: Rob Herring robh...@kernel.org
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/dra7.dtsi |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index f0ca46d..0d3c8c0 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -876,6 +876,14 @@
};
};
+ omap_control_pcie1phy: omap-control-pciephy@0x4a003c40 {
+ compatible = ti,control-phy-pcie;
+ reg = 0x4a003c40 0x4, 0x4a003c14 0x4, 0x4a003c34
0x4;
+ reg-names = power, control_sma, pcie_pcs;
+ clocks = sys_clkin1;
+ clock-names = sysclk;
+ };
+
/* OCP2SCP3 */
ocp2scp@4a09 {
compatible = ti,omap-ocp2scp;
--
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 09/17] arm: dra7xx: Add hwmod data for pcie1 phy and pcie2 phy
Added hwmod data for pcie1 and pcie2 phy present in DRA7xx SOC.
Also added the missing CLKCTRL OFFSET macro and CONTEXT OFFSET macro
for pcie1 phy and pcie2 phy.
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/cm2_7xx.h |4 ++
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 57 +
arch/arm/mach-omap2/prm7xx.h |4 ++
3 files changed, 65 insertions(+)
diff --git a/arch/arm/mach-omap2/cm2_7xx.h b/arch/arm/mach-omap2/cm2_7xx.h
index 9ad7594..e966e3a 100644
--- a/arch/arm/mach-omap2/cm2_7xx.h
+++ b/arch/arm/mach-omap2/cm2_7xx.h
@@ -357,6 +357,10 @@
#define DRA7XX_CM_L3INIT_SATA_CLKCTRL
DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L3INIT_INST, 0x0088)
#define DRA7XX_CM_PCIE_CLKSTCTRL_OFFSET0x00a0
#define DRA7XX_CM_PCIE_STATICDEP_OFFSET0x00a4
+#define DRA7XX_CM_L3INIT_PCIESS1_CLKCTRL_OFFSET0x00b0
+#define DRA7XX_CM_L3INIT_PCIESS1_CLKCTRL
DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L3INIT_INST, 0x00b0)
+#define DRA7XX_CM_L3INIT_PCIESS2_CLKCTRL_OFFSET0x00b8
+#define DRA7XX_CM_L3INIT_PCIESS2_CLKCTRL
DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L3INIT_INST, 0x00b8)
#define DRA7XX_CM_GMAC_CLKSTCTRL_OFFSET0x00c0
#define DRA7XX_CM_GMAC_STATICDEP_OFFSET0x00c4
#define DRA7XX_CM_GMAC_DYNAMICDEP_OFFSET 0x00c8
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index b9bb476..1282a42 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1231,6 +1231,45 @@ static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
};
/*
+ * 'PCIE PHY' class
+ *
+ */
+
+static struct omap_hwmod_class dra7xx_pcie_phy_hwmod_class = {
+ .name = pcie-phy,
+};
+
+/* pcie1 phy */
+static struct omap_hwmod dra7xx_pcie1_phy_hwmod = {
+ .name = pcie1-phy,
+ .class = dra7xx_pcie_phy_hwmod_class,
+ .clkdm_name = l3init_clkdm,
+ .main_clk = l4_root_clk_div,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_L3INIT_PCIESS1_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_L3INIT_PCIESS1_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/* pcie2 phy */
+static struct omap_hwmod dra7xx_pcie2_phy_hwmod = {
+ .name = pcie2-phy,
+ .class = dra7xx_pcie_phy_hwmod_class,
+ .clkdm_name = l3init_clkdm,
+ .main_clk = l4_root_clk_div,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_L3INIT_PCIESS2_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_L3INIT_PCIESS2_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/*
* 'qspi' class
*
*/
@@ -2349,6 +2388,22 @@ static struct omap_hwmod_ocp_if dra7xx_l4_cfg__ocp2scp1
= {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_cfg - pcie1 phy */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pcie1_phy = {
+ .master = dra7xx_l4_cfg_hwmod,
+ .slave = dra7xx_pcie1_phy_hwmod,
+ .clk= l4_root_clk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_cfg - pcie2 phy */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pcie2_phy = {
+ .master = dra7xx_l4_cfg_hwmod,
+ .slave = dra7xx_pcie2_phy_hwmod,
+ .clk= l4_root_clk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_addr_space dra7xx_qspi_addrs[] = {
{
.pa_start = 0x4b30,
@@ -2696,6 +2751,8 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
__initdata = {
dra7xx_l4_cfg__mpu,
dra7xx_l4_cfg__ocp2scp1,
dra7xx_l4_cfg__ocp2scp3,
+ dra7xx_l4_cfg__pcie1_phy,
+ dra7xx_l4_cfg__pcie2_phy,
dra7xx_l3_main_1__qspi,
dra7xx_l4_cfg__sata,
dra7xx_l4_cfg__smartreflex_core,
diff --git a/arch/arm/mach-omap2/prm7xx.h b/arch/arm/mach-omap2/prm7xx.h
index d92a840..4bb50fbf 100644
--- a/arch/arm/mach-omap2/prm7xx.h
+++ b/arch/arm/mach-omap2/prm7xx.h
@@ -374,6 +374,10 @@
#define DRA7XX_RM_L3INIT_IEEE1500_2_OCP_CONTEXT_OFFSET 0x007c
#define DRA7XX_PM_L3INIT_SATA_WKDEP_OFFSET 0x0088
#define DRA7XX_RM_L3INIT_SATA_CONTEXT_OFFSET 0x008c
+#define DRA7XX_PM_L3INIT_PCIESS1_WKDEP_OFFSET 0x00b0
+#define DRA7XX_RM_L3INIT_PCIESS1_CONTEXT_OFFSET0x00b4
+#define DRA7XX_PM_L3INIT_PCIESS2_WKDEP_OFFSET
[PATCH 05/17] pci: host: pcie-dra7xx: add support for pcie-dra7xx controller
Added support for pcie controller in dra7xx. This driver re-uses
the designware core code that is already present in kernel.
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Mohit Kumar mohit.ku...@st.com
Cc: Jingoo Han jg1@samsung.com
Cc: Marek Vasut ma...@denx.de
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/pci/ti-pci.txt | 33 ++
drivers/pci/host/Kconfig | 10 +
drivers/pci/host/Makefile|1 +
drivers/pci/host/pci-dra7xx.c| 385 ++
4 files changed, 429 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/ti-pci.txt
create mode 100644 drivers/pci/host/pci-dra7xx.c
diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt
b/Documentation/devicetree/bindings/pci/ti-pci.txt
new file mode 100644
index 000..6cb6f09
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
@@ -0,0 +1,33 @@
+TI PCI Controllers
+
+PCIe Designware Controller
+This node should have the properties described in designware-pcie.txt.
+ - compatible: Should be ti,dra7xx-pcie
+ - reg : Address and length of the register set for the device.
+ - reg-names : ti_conf for the TI specific registers and rc_dbics for the
+ designware registers.
+ - phys : the phandle for the PHY device (used by generic PHY framework)
+ - phy-names : the names of the PHY corresponding to the PHYs present in the
+ *phy* phandle.
+
+Example:
+pcie@5100 {
+ compatible = ti,dra7xx-pcie;
+ reg = 0x51002000 0x14c, 0x5100 0x2000;
+ reg-names = ti_conf, rc_dbics;
+ interrupts = 0 232 0x4, 0 233 0x4;
+ #address-cells = 3;
+ #size-cells = 2;
+ device_type = pci;
+ ti,device_type = 3;
+ ranges = 0x0800 0 0x20001000 0x20001000 0 0x2000 /*
Configuration Space */
+ 0x8100 0 0 0x20003000 0 0x0001 /* IO Space
*/
+ 0x8200 0 0x20013000 0x20013000 0 0xffed000; /* MEM Space
*/
+ #interrupt-cells = 1;
+ num-lanes = 1;
+ interrupt-map-mask = 0 0 0 0;
+ interrupt-map = 0x0 0 gic 134;
+ ti,hwmods = pcie1;
+ phys = pcie1_phy;
+ phy-names = pcie-phy;
+};
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index a6f67ec..7be6393 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -1,6 +1,16 @@
menu PCI host controller drivers
depends on PCI
+config PCI_DRA7XX
+ bool TI DRA7xx PCIe controller
+ select PCIE_DW
+ depends on OF || HAS_IOMEM || TI_PIPE3
+ help
+Enables support for the PCIE controller present in DRA7xx SoC. There
+are two instances of PCIE controller in DRA7xx. This controller can
+act both as EP and RC. This reuses the same Designware core as used
+by other SoCs.
+
config PCI_MVEBU
bool Marvell EBU PCIe controller
depends on ARCH_MVEBU || ARCH_DOVE || ARCH_KIRKWOOD
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 13fb333..5216f55 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_PCIE_DW) += pcie-designware.o
+obj-$(CONFIG_PCI_DRA7XX) += pci-dra7xx.o
obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o
obj-$(CONFIG_PCI_IMX6) += pci-imx6.o
obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
new file mode 100644
index 000..a37c25c
--- /dev/null
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -0,0 +1,385 @@
+/*
+ * pcie-dra7xx - PCIe controller driver for TI DRA7xx SoCs
+ *
+ * Copyright (C) 2013-2014 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Authors: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/err.h
+#include linux/interrupt.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/pci.h
+#include linux/phy/phy.h
+#include linux/platform_device.h
+#include linux/pm_runtime.h
+#include linux/resource.h
+#include linux/types.h
+
+#include pcie-designware.h
+
+/* PCIe controller wrapper DRA7XX configuration registers */
+
+#definePCIECTRL_DRA7XX_CONF_IRQSTATUS_MAIN 0x0024
+#definePCIECTRL_DRA7XX_CONF_IRQENABLE_SET_MAIN 0x0028
+#defineERR_SYS BIT(0)
+#defineERR_FATAL BIT(1)
+#defineERR_NONFATALBIT(2)
+#defineERR_COR BIT(3)
+#defineERR_AXI BIT(4)
+#defineERR_ECRCBIT(5)
+#definePME_TURN_OFF
Re: [PATCH] clk: ti: clk-7xx: Correct ABE DPLL configuration
Mike, On 04/24/2014 06:03 PM, Tero Kristo wrote: On 04/24/2014 12:11 PM, Peter Ujfalusi wrote: Mike, Tero, On 04/03/2014 09:29 AM, Peter Ujfalusi wrote: On 04/02/2014 05:12 PM, Tero Kristo wrote: On 04/02/2014 04:48 PM, Peter Ujfalusi wrote: ABE DPLL frequency need to be lowered from 361267200 to 180633600 to facilitate the ATL requironments. The dpll_abe_m2x2_ck clock need to be set to double of ABE DPLL rate in order to have correct clocks for audio. Do you have some sort of TRM reference for this? The ATL's max divider is 32. For audio purpose the clock coming out from the ATL instance should be 128 * fs. It is only possible to have 44.1KHz sampling rate with ABE DPLL set to 361267200 or 180633600. Which means: The atl generated clock should be 128 * 44100 = 5644800 From ABE_DPLL 361267200 we would need to have 64 as divider (ATL can't do this). From the suggested ABE_DPLL of 180633600 we can use ATL divider of 32, which is the maximum it can do. So the reason for the change is to have ATLPCLK clock which can be used for audio in the future, the 361267200 is just too high. Tero: can I have your ack for this patch or do you have further concerns? Yea looks good to me, except for the fact that there is some work on getting default rate/parent support through DT. I would like a comment from Mike about the estimate when this can get in, and whether we should merge intermediate solutions still like this. Anyway, you can consider this patch acked by me, I'll let Mike to decide what to do with it though. Do you have anything against this patch? Since right now there is no other ways to fix the ABE DPLL for dra7 it would be great if we could have this in till we have the final solution. Also I'd like to point out that the original frequency the ABE DPLL was not correct and renders the audio to be not usable on the platform. Thanks, Péter -Tero Mike: do you want me to resend this patch? Thanks, Péter -Tero Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- drivers/clk/ti/clk-7xx.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c index f7e40734c819..19a55bf407dd 100644 --- a/drivers/clk/ti/clk-7xx.c +++ b/drivers/clk/ti/clk-7xx.c @@ -16,7 +16,7 @@ #include linux/clkdev.h #include linux/clk/ti.h -#define DRA7_DPLL_ABE_DEFFREQ361267200 +#define DRA7_DPLL_ABE_DEFFREQ180633600 #define DRA7_DPLL_GMAC_DEFFREQ10 @@ -322,6 +322,11 @@ int __init dra7xx_dt_clk_init(void) if (rc) pr_err(%s: failed to configure ABE DPLL!\n, __func__); +dpll_ck = clk_get_sys(NULL, dpll_abe_m2x2_ck); +rc = clk_set_rate(dpll_ck, DRA7_DPLL_ABE_DEFFREQ * 2); +if (rc) +pr_err(%s: failed to configure ABE DPLL m2x2!\n, __func__); + dpll_ck = clk_get_sys(NULL, dpll_gmac_ck); rc = clk_set_rate(dpll_ck, DRA7_DPLL_GMAC_DEFFREQ); if (rc) -- 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: [TEMP PATCH 17/17] ARM: dts: dra7: Add *resets* property for PCIe dt node
On 05/06/2014 08:34 AM, Kishon Vijay Abraham I wrote:
Added *resets* and *reset-names* properies for PCIe dt node.
The documention for this node can be found @ ../bindings/pci/ti-pci.txt.
Cc: Dan Murphy dmur...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/dra7.dtsi |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 20b1a09..7bc0555 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1031,6 +1031,8 @@
ti,hwmods = pcie1;
phys = pcie1_phy;
phy-names = pcie-phy;
+ resets = prm_resets device_reset;
If you look @ v2 of the reset framework patchset your phandle should be
resets = prm_resets pcie1_reset;
If you call the device_reset phandle you will reset the SoC.
+ reset-names = reset;
This needs to be more descriptive.
};
sata: sata@4a141100 {
--
--
Dan Murphy
--
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 08/17] ARM: dts: DRA7: Change the parent of apll_pcie_in_clk_mux to dpll_pcie_ref_m2ldo_ck
From: Keerthy j-keer...@ti.com
Change the parent of apll_pcie_in_clk_mux to dpll_pcie_ref_m2ldo_ck
from dpll_pcie_ref_ck.
Cc: Rajendra Nayak rna...@ti.com
Cc: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Keerthy j-keer...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/dra7xx-clocks.dtsi |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index 55e95c5..44993ec 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -1152,7 +1152,7 @@
apll_pcie_in_clk_mux: apll_pcie_in_clk_mux@4ae06118 {
compatible = ti,mux-clock;
- clocks = dpll_pcie_ref_ck, pciesref_acs_clk_ck;
+ clocks = dpll_pcie_ref_m2ldo_ck, pciesref_acs_clk_ck;
#clock-cells = 0;
reg = 0x021c 0x4;
ti,bit-shift = 7;
--
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 03/17] phy: ti-pipe3: add external clock support for PCIe PHY
APLL used by PCIE phy can either use external clock as input or the clock
from DPLL. Added support for the APLL to use external clock as input here.
Cc: Rajendra Nayak rna...@ti.com
Cc: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/phy/ti-phy.txt |4 ++
drivers/phy/phy-ti-pipe3.c | 75 ++
2 files changed, 52 insertions(+), 27 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index bc9afb5..d50f8ee 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -76,6 +76,10 @@ Required properties:
* dpll_ref_m2 - external dpll ref clk
* phy-div - divider for apll
* div-clk - apll clock
+ * apll_mux - mux for pcie apll
+ * refclk_ext - external reference clock for pcie apll
+ - ti,ext-clk: To specifiy if PCIE apll should use external clock. Applicable
+ only to PCIE PHY.
Optional properties:
- ctrl-module : phandle of the control module used by PHY driver to power on
diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index d43019d..5513aa0 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -293,7 +293,7 @@ static int ti_pipe3_probe(struct platform_device *pdev)
struct device_node *control_node;
struct platform_device *control_pdev;
const struct of_device_id *match;
- struct clk *clk;
+ struct clk *clk, *pclk;
phy = devm_kzalloc(pdev-dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
@@ -302,6 +302,20 @@ static int ti_pipe3_probe(struct platform_device *pdev)
}
phy-dev= pdev-dev;
+ control_node = of_parse_phandle(node, ctrl-module, 0);
+ if (!control_node) {
+ dev_err(pdev-dev, Failed to get control device phandle\n);
+ return -EINVAL;
+ }
+
+ control_pdev = of_find_device_by_node(control_node);
+ if (!control_pdev) {
+ dev_err(pdev-dev, Failed to get control device\n);
+ return -EINVAL;
+ }
+
+ phy-control_dev = control_pdev-dev;
+
if (!of_device_is_compatible(node, ti,phy-pipe3-pcie)) {
match = of_match_device(of_match_ptr(ti_pipe3_id_table),
pdev-dev);
@@ -345,19 +359,40 @@ static int ti_pipe3_probe(struct platform_device *pdev)
}
if (of_device_is_compatible(node, ti,phy-pipe3-pcie)) {
- clk = devm_clk_get(phy-dev, dpll_ref);
- if (IS_ERR(clk)) {
- dev_err(pdev-dev, unable to get dpll ref clk\n);
- return PTR_ERR(clk);
+ if (!of_property_read_bool(node, ti,ext-clk)) {
+ clk = devm_clk_get(phy-dev, dpll_ref);
+ if (IS_ERR(clk)) {
+ dev_err(pdev-dev,
+ unable to get dpll ref clk\n);
+ return PTR_ERR(clk);
+ }
+ clk_set_rate(clk, 15);
+
+ clk = devm_clk_get(phy-dev, dpll_ref_m2);
+ if (IS_ERR(clk)) {
+ dev_err(pdev-dev,
+ unable to get dpll ref m2 clk\n);
+ return PTR_ERR(clk);
+ }
+ clk_set_rate(clk, 1);
+ } else {
+ omap_control_pcie_tx_rx_control(phy-control_dev,
+ OMAP_CTRL_PCIE_PHY_RX_ACSPCIE);
+
+ clk = clk_get(phy-dev, apll_mux);
+ if (IS_ERR(clk)) {
+ dev_err(pdev-dev, unable to get apll mux
clk\n);
+ return PTR_ERR(clk);
+ }
+
+ pclk = clk_get(phy-dev, refclk_ext);
+ if (IS_ERR(pclk)) {
+ dev_err(pdev-dev, unable to get ext ref clk
for apll\n);
+ return PTR_ERR(pclk);
+ }
+
+ clk_set_parent(clk, pclk);
}
- clk_set_rate(clk, 15);
-
- clk = devm_clk_get(phy-dev, dpll_ref_m2);
- if (IS_ERR(clk)) {
- dev_err(pdev-dev, unable to get dpll ref m2 clk\n);
- return PTR_ERR(clk);
- }
- clk_set_rate(clk, 1);
clk = devm_clk_get(phy-dev, phy-div);
if (IS_ERR(clk)) {
@@ -375,20 +410,6 @@ static int ti_pipe3_probe(struct platform_device *pdev)
phy-div_clk = ERR_PTR(-ENODEV);
}
-
[PATCH 04/17] phy: pipe3: insert delay to enumerate in GEN2 mode
8-bit delay value (0xF1) is required for GEN2 devices to be enumerated
consistently. Added an API to be called from PHY drivers to set this delay
value and called it from PIPE3 driver to set the delay value.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/phy/ti-phy.txt |4 +--
drivers/phy/phy-omap-control.c | 41 ++
drivers/phy/phy-ti-pipe3.c |4 ++-
include/linux/phy/omap_control_phy.h |9 +
4 files changed, 55 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index d50f8ee..5653dc4 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -18,9 +18,9 @@ Required properties:
AM437 platform.
- reg : Address and length of the register set for the device. It contains
the address of otghs_control for control-phy-otghs or power register
- for other types and control_sma for control-phy-pcie
+ for other types and control_sma, pcie_pcs for control-phy-pcie
- reg-names: should be otghs_control for control-phy-otghs,
- control_sma for control-phy-pcie and power for other types.
+ control_sma, pcie_pcs for control-phy-pcie and power for other types.
omap_control_usb: omap-control-usb@4a002300 {
compatible = ti,control-phy-otghs;
diff --git a/drivers/phy/phy-omap-control.c b/drivers/phy/phy-omap-control.c
index 47a1b6c..6ba551b 100644
--- a/drivers/phy/phy-omap-control.c
+++ b/drivers/phy/phy-omap-control.c
@@ -61,6 +61,41 @@ void omap_control_pcie_tx_rx_control(struct device *dev, u8
ctrl)
EXPORT_SYMBOL_GPL(omap_control_pcie_tx_rx_control);
/**
+ * omap_control_pcie_pcs - set the PCS delay count
+ * @dev: the control module device
+ * @id: index of the pcie PHY (should be 1 or 2)
+ * @delay: 8 bit delay value
+ */
+void omap_control_pcie_pcs(struct device *dev, u8 id, u8 delay)
+{
+ u32 val;
+ struct omap_control_phy *control_phy;
+
+ if (IS_ERR(dev) || !dev) {
+ pr_err(%s: invalid device\n, __func__);
+ return;
+ }
+
+ control_phy = dev_get_drvdata(dev);
+ if (!control_phy) {
+ dev_err(dev, %s: invalid control phy device\n, __func__);
+ return;
+ }
+
+ if (control_phy-type != OMAP_CTRL_TYPE_PCIE) {
+ dev_err(dev, %s: unsupported operation\n, __func__);
+ return;
+ }
+
+ val = readl(control_phy-pcie_pcs);
+ val = ~(OMAP_CTRL_PCIE_PCS_MASK
+ (id * OMAP_CTRL_PCIE_PCS_DELAY_COUNT_SHIFT));
+ val |= delay (id * OMAP_CTRL_PCIE_PCS_DELAY_COUNT_SHIFT);
+ writel(val, control_phy-pcie_pcs);
+}
+EXPORT_SYMBOL_GPL(omap_control_pcie_pcs);
+
+/**
* omap_control_phy_power - power on/off the phy using control module reg
* @dev: the control module device
* @on: 0 or 1, based on powering on or off the PHY
@@ -335,6 +370,12 @@ static int omap_control_phy_probe(struct platform_device
*pdev)
control_phy-ctrl_sma = devm_ioremap_resource(pdev-dev, res);
if (IS_ERR(control_phy-ctrl_sma))
return PTR_ERR(control_phy-ctrl_sma);
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+ pcie_pcs);
+ control_phy-pcie_pcs = devm_ioremap_resource(pdev-dev, res);
+ if (IS_ERR(control_phy-pcie_pcs))
+ return PTR_ERR(control_phy-pcie_pcs);
}
dev_set_drvdata(control_phy-dev, control_phy);
diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 5513aa0..a1a0e35 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -216,8 +216,10 @@ static int ti_pipe3_init(struct phy *x)
u32 val;
int ret = 0;
- if (of_device_is_compatible(phy-dev-of_node, ti,phy-pipe3-pcie))
+ if (of_device_is_compatible(phy-dev-of_node, ti,phy-pipe3-pcie)) {
+ omap_control_pcie_pcs(phy-control_dev, 0x1, 0xF1);
return 0;
+ }
/* Bring it out of IDLE if it is IDLE */
val = ti_pipe3_readl(phy-pll_ctrl_base, PLL_CONFIGURATION2);
diff --git a/include/linux/phy/omap_control_phy.h
b/include/linux/phy/omap_control_phy.h
index 15cfbfe..6127c04 100644
--- a/include/linux/phy/omap_control_phy.h
+++ b/include/linux/phy/omap_control_phy.h
@@ -35,6 +35,7 @@ struct omap_control_phy {
u32 __iomem *power;
u32 __iomem *power_aux;
u32 __iomem *ctrl_sma;
+ u32 __iomem *pcie_pcs;
struct clk *sys_clk;
@@ -68,6 +69,9 @@ enum omap_control_usb_mode {
#defineOMAP_CTRL_PCIE_TX_RX_CONTROL_SHIFT 0x10
#defineOMAP_CTRL_PCIE_TX_RX_CONTROL_MASK 0x3
+#defineOMAP_CTRL_PCIE_PCS_MASK 0xff
Re: [TEMP PATCH 16/17] pci: host: pcie-dra7xx: use reset framework APIs to reset PCIe
On 05/06/2014 08:34 AM, Kishon Vijay Abraham I wrote:
Get reset nodes from dt and use reset framework APIs to reset PCIe.
This is needed since reset is handled by the SoC.
Cc: Dan Murphy dmur...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/pci/ti-pci.txt |2 ++
drivers/pci/host/pci-dra7xx.c| 10 ++
2 files changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt
b/Documentation/devicetree/bindings/pci/ti-pci.txt
index 6cb6f09..cfb95c0 100644
--- a/Documentation/devicetree/bindings/pci/ti-pci.txt
+++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
@@ -9,6 +9,8 @@ This node should have the properties described in
designware-pcie.txt.
- phys : the phandle for the PHY device (used by generic PHY framework)
- phy-names : the names of the PHY corresponding to the PHYs present in the
*phy* phandle.
+ - resets: phandle used if reset is handled be soc
+ - reset-names: name given to the phandle
You should just refer to the ti,reset.txt document for this.
Example:
pcie@5100 {
diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index a37c25c..17d64ee 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -20,6 +20,7 @@
#include linux/platform_device.h
#include linux/pm_runtime.h
#include linux/resource.h
+#include linux/reset.h
#include linux/types.h
#include pcie-designware.h
@@ -281,6 +282,7 @@ static int __init dra7xx_pcie_probe(struct
platform_device *pdev)
struct resource *res;
struct dra7xx_pcie *dra7xx;
struct device *dev = pdev-dev;
+ struct reset_control *rstc;
dra7xx = devm_kzalloc(pdev-dev, sizeof(*dra7xx), GFP_KERNEL);
if (!dra7xx)
@@ -304,6 +306,14 @@ static int __init dra7xx_pcie_probe(struct
platform_device *pdev)
if (!base)
return -ENOMEM;
+ rstc = devm_reset_control_get(dev, reset);
+ if (IS_ERR(rstc))
+ return PTR_ERR(rstc);
+
+ ret = reset_control_deassert(rstc);
+ if (ret)
+ return ret;
+
phy = devm_phy_get(dev, pcie-phy);
if (IS_ERR(phy))
return PTR_ERR(phy);
--
--
Dan Murphy
--
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 01/17] phy: phy-omap-pipe3: Add support for PCIe PHY
PCIe PHY uses an external pll instead of the internal pll used by SATA
and USB3. So added support in pipe3 PHY to use external pll.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/phy/ti-phy.txt |8 +-
drivers/phy/phy-ti-pipe3.c | 99 +-
2 files changed, 84 insertions(+), 23 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index 9ce458f..cf3de7e 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -56,8 +56,8 @@ usb2phy@4a0ad080 {
TI PIPE3 PHY
Required properties:
- - compatible: Should be ti,phy-usb3 or ti,phy-pipe3-sata.
- ti,omap-usb3 is deprecated.
+ - compatible: Should be ti,phy-usb3, ti,phy-pipe3-sata or
+ ti,phy-pipe3-pcie. ti,omap-usb3 is deprecated.
- reg : Address and length of the register set for the device.
- reg-names: The names of the register addresses corresponding to the
registers
filled in reg.
@@ -69,6 +69,10 @@ Required properties:
* wkupclk - wakeup clock.
* sysclk - system clock.
* refclk - reference clock.
+ * dpll_ref - external dpll ref clk
+ * dpll_ref_m2 - external dpll ref clk
+ * phy-div - divider for apll
+ * div-clk - apll clock
Optional properties:
- ctrl-module : phandle of the control module used by PHY driver to power on
diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 5913676..d43019d 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -80,6 +80,7 @@ struct ti_pipe3 {
struct clk *wkupclk;
struct clk *sys_clk;
struct clk *refclk;
+ struct clk *div_clk;
struct pipe3_dpll_map *dpll_map;
};
@@ -215,6 +216,9 @@ static int ti_pipe3_init(struct phy *x)
u32 val;
int ret = 0;
+ if (of_device_is_compatible(phy-dev-of_node, ti,phy-pipe3-pcie))
+ return 0;
+
/* Bring it out of IDLE if it is IDLE */
val = ti_pipe3_readl(phy-pll_ctrl_base, PLL_CONFIGURATION2);
if (val PLL_IDLE) {
@@ -238,8 +242,11 @@ static int ti_pipe3_exit(struct phy *x)
u32 val;
unsigned long timeout;
- /* SATA DPLL can't be powered down due to Errata i783 */
- if (of_device_is_compatible(phy-dev-of_node, ti,phy-pipe3-sata))
+ /* SATA DPLL can't be powered down due to Errata i783 and PCIe
+* does not have internal DPLL
+*/
+ if (of_device_is_compatible(phy-dev-of_node, ti,phy-pipe3-sata) ||
+ of_device_is_compatible(phy-dev-of_node, ti,phy-pipe3-pcie))
return 0;
/* Put DPLL in IDLE mode */
@@ -286,32 +293,41 @@ static int ti_pipe3_probe(struct platform_device *pdev)
struct device_node *control_node;
struct platform_device *control_pdev;
const struct of_device_id *match;
-
- match = of_match_device(of_match_ptr(ti_pipe3_id_table), pdev-dev);
- if (!match)
- return -EINVAL;
+ struct clk *clk;
phy = devm_kzalloc(pdev-dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
dev_err(pdev-dev, unable to alloc mem for TI PIPE3 PHY\n);
return -ENOMEM;
}
+ phy-dev= pdev-dev;
- phy-dpll_map = (struct pipe3_dpll_map *)match-data;
- if (!phy-dpll_map) {
- dev_err(pdev-dev, no DPLL data\n);
- return -EINVAL;
- }
+ if (!of_device_is_compatible(node, ti,phy-pipe3-pcie)) {
+ match = of_match_device(of_match_ptr(ti_pipe3_id_table),
+ pdev-dev);
+ if (!match)
+ return -EINVAL;
- res = platform_get_resource_byname(pdev, IORESOURCE_MEM, pll_ctrl);
- phy-pll_ctrl_base = devm_ioremap_resource(pdev-dev, res);
- if (IS_ERR(phy-pll_ctrl_base))
- return PTR_ERR(phy-pll_ctrl_base);
+ phy-dpll_map = (struct pipe3_dpll_map *)match-data;
+ if (!phy-dpll_map) {
+ dev_err(pdev-dev, no DPLL data\n);
+ return -EINVAL;
+ }
- phy-dev= pdev-dev;
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+ pll_ctrl);
+ phy-pll_ctrl_base = devm_ioremap_resource(pdev-dev, res);
+ if (IS_ERR(phy-pll_ctrl_base))
+ return PTR_ERR(phy-pll_ctrl_base);
- if (!of_device_is_compatible(node, ti,phy-pipe3-sata)) {
+ phy-sys_clk = devm_clk_get(phy-dev, sysclk);
+ if (IS_ERR(phy-sys_clk)) {
+ dev_err(pdev-dev, unable to get sysclk\n);
+ return -EINVAL;
+ }
+ }
+ if
[PATCH 06/17] pci: host: pcie-designware: Use *base-mask* for configuring the iATU
In DRA7, the cpu sees 32bit address, but the pcie controller can see only 28bit
address. So whenever the cpu issues a read/write request, the 4 most
significant bits are used by L3 to determine the target controller.
For example, the cpu reserves 0x2000_ - 0x2FFF_ for PCIe controller but
the PCIe controller will see only (0x000_ - 0xFFF_FFF). So for programming
the outbound translation window the *base* should be programmed as 0x000_.
Whenever we try to write to say 0x2000_, it will be translated to whatever
we have programmed in the translation window with base as 0x000_.
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Marek Vasut ma...@denx.de
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Jingoo Han jg1@samsung.com
Acked-by: Mohit Kumar mohit.ku...@st.com
---
.../devicetree/bindings/pci/designware-pcie.txt|1 +
drivers/pci/host/pcie-designware.c | 39 ++--
drivers/pci/host/pcie-designware.h |1 +
3 files changed, 29 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt
b/Documentation/devicetree/bindings/pci/designware-pcie.txt
index d6fae13..c574dd3 100644
--- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
@@ -27,6 +27,7 @@ Optional properties for fsl,imx6q-pcie
- power-on-gpio: gpio pin number of power-enable signal
- wake-up-gpio: gpio pin number of incoming wakeup signal
- disable-gpio: gpio pin number of outgoing rfkill/endpoint disable signal
+- base-mask: address mask for the PCIe controller target port
Example:
diff --git a/drivers/pci/host/pcie-designware.c
b/drivers/pci/host/pcie-designware.c
index c4e3732..243f148 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -463,6 +463,9 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
return -EINVAL;
}
+ if (of_property_read_u64(np, base-mask, pp-base_mask))
+ pp-base_mask = ~0x0ULL;
+
if (IS_ENABLED(CONFIG_PCI_MSI)) {
pp-irq_domain = irq_domain_add_linear(pp-dev-of_node,
MAX_MSI_IRQS, msi_domain_ops,
@@ -502,12 +505,15 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
static void dw_pcie_prog_viewport_cfg0(struct pcie_port *pp, u32 busdev)
{
+ u64 cfg0_base;
+
+ cfg0_base = pp-cfg0_base pp-base_mask;
/* Program viewport 0 : OUTBOUND : CFG0 */
dw_pcie_writel_rc(pp, PCIE_ATU_REGION_OUTBOUND | PCIE_ATU_REGION_INDEX0,
PCIE_ATU_VIEWPORT);
- dw_pcie_writel_rc(pp, pp-cfg0_base, PCIE_ATU_LOWER_BASE);
- dw_pcie_writel_rc(pp, (pp-cfg0_base 32), PCIE_ATU_UPPER_BASE);
- dw_pcie_writel_rc(pp, pp-cfg0_base + pp-config.cfg0_size - 1,
+ dw_pcie_writel_rc(pp, cfg0_base, PCIE_ATU_LOWER_BASE);
+ dw_pcie_writel_rc(pp, (cfg0_base 32), PCIE_ATU_UPPER_BASE);
+ dw_pcie_writel_rc(pp, cfg0_base + pp-config.cfg0_size - 1,
PCIE_ATU_LIMIT);
dw_pcie_writel_rc(pp, busdev, PCIE_ATU_LOWER_TARGET);
dw_pcie_writel_rc(pp, 0, PCIE_ATU_UPPER_TARGET);
@@ -517,13 +523,16 @@ static void dw_pcie_prog_viewport_cfg0(struct pcie_port
*pp, u32 busdev)
static void dw_pcie_prog_viewport_cfg1(struct pcie_port *pp, u32 busdev)
{
+ u64 cfg1_base;
+
+ cfg1_base = pp-cfg1_base pp-base_mask;
/* Program viewport 1 : OUTBOUND : CFG1 */
dw_pcie_writel_rc(pp, PCIE_ATU_REGION_OUTBOUND | PCIE_ATU_REGION_INDEX1,
PCIE_ATU_VIEWPORT);
dw_pcie_writel_rc(pp, PCIE_ATU_TYPE_CFG1, PCIE_ATU_CR1);
- dw_pcie_writel_rc(pp, pp-cfg1_base, PCIE_ATU_LOWER_BASE);
- dw_pcie_writel_rc(pp, (pp-cfg1_base 32), PCIE_ATU_UPPER_BASE);
- dw_pcie_writel_rc(pp, pp-cfg1_base + pp-config.cfg1_size - 1,
+ dw_pcie_writel_rc(pp, cfg1_base, PCIE_ATU_LOWER_BASE);
+ dw_pcie_writel_rc(pp, (cfg1_base 32), PCIE_ATU_UPPER_BASE);
+ dw_pcie_writel_rc(pp, cfg1_base + pp-config.cfg1_size - 1,
PCIE_ATU_LIMIT);
dw_pcie_writel_rc(pp, busdev, PCIE_ATU_LOWER_TARGET);
dw_pcie_writel_rc(pp, 0, PCIE_ATU_UPPER_TARGET);
@@ -532,13 +541,16 @@ static void dw_pcie_prog_viewport_cfg1(struct pcie_port
*pp, u32 busdev)
static void dw_pcie_prog_viewport_mem_outbound(struct pcie_port *pp)
{
+ u64 mem_base;
+
+ mem_base = pp-mem_base pp-base_mask;
/* Program viewport 0 : OUTBOUND : MEM */
dw_pcie_writel_rc(pp, PCIE_ATU_REGION_OUTBOUND | PCIE_ATU_REGION_INDEX0,
PCIE_ATU_VIEWPORT);
dw_pcie_writel_rc(pp, PCIE_ATU_TYPE_MEM, PCIE_ATU_CR1);
- dw_pcie_writel_rc(pp, pp-mem_base, PCIE_ATU_LOWER_BASE);
- dw_pcie_writel_rc(pp, (pp-mem_base 32), PCIE_ATU_UPPER_BASE);
- dw_pcie_writel_rc(pp, pp-mem_base + pp-config.mem_size -
[PATCH 02/17] phy: omap-control: add external clock support for PCIe PHY
Export an API to be called by PIPE3 PHY to enable external clock for
PCIE PHY. Added a new compatible for PCIE in omap-control in order to
enable it.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/phy/ti-phy.txt |9 ++--
drivers/phy/phy-omap-control.c | 51 +-
include/linux/phy/omap_control_phy.h | 14 ++
3 files changed, 70 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index cf3de7e..bc9afb5 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -9,15 +9,18 @@ Required properties:
e.g. USB2_PHY on OMAP5.
ti,control-phy-pipe3 - if it has DPLL and individual Rx Tx power control
e.g. USB3 PHY and SATA PHY on OMAP5.
+ ti,control-phy-pcie - for pcie to support external clock for pcie and to
+ set PCS delay value.
+ e.g. PCIE PHY in DRA7x
ti,control-phy-usb2-dra7 - if it has power down register like USB2 PHY on
DRA7 platform.
ti,control-phy-usb2-am437 - if it has power down register like USB2 PHY on
AM437 platform.
- reg : Address and length of the register set for the device. It contains
the address of otghs_control for control-phy-otghs or power register
- for other types.
- - reg-names: should be otghs_control control-phy-otghs and power for
- other types.
+ for other types and control_sma for control-phy-pcie
+ - reg-names: should be otghs_control for control-phy-otghs,
+ control_sma for control-phy-pcie and power for other types.
omap_control_usb: omap-control-usb@4a002300 {
compatible = ti,control-phy-otghs;
diff --git a/drivers/phy/phy-omap-control.c b/drivers/phy/phy-omap-control.c
index 311b4f9..47a1b6c 100644
--- a/drivers/phy/phy-omap-control.c
+++ b/drivers/phy/phy-omap-control.c
@@ -27,6 +27,40 @@
#include linux/phy/omap_control_phy.h
/**
+ * omap_control_pcie_tx_rx_control - PCIe RX and TX control of ACSPCIe
+ * @dev: the control module device
+ * @ctrl: 1, 2 or 3 based on controlling either RX or TX or both of ACSPCIe
+ */
+void omap_control_pcie_tx_rx_control(struct device *dev, u8 ctrl)
+{
+ u32 val;
+ struct omap_control_phy *control_phy;
+
+ if (IS_ERR(dev) || !dev) {
+ pr_err(%s: invalid device\n, __func__);
+ return;
+ }
+
+ control_phy = dev_get_drvdata(dev);
+ if (!control_phy) {
+ dev_err(dev, %s: invalid control phy device\n, __func__);
+ return;
+ }
+
+ if (control_phy-type != OMAP_CTRL_TYPE_PCIE) {
+ dev_err(dev, %s: unsupported operation\n, __func__);
+ return;
+ }
+
+ val = readl(control_phy-ctrl_sma);
+ val = ~(OMAP_CTRL_PCIE_TX_RX_CONTROL_MASK
+ OMAP_CTRL_PCIE_TX_RX_CONTROL_SHIFT);
+ val |= ctrl OMAP_CTRL_PCIE_TX_RX_CONTROL_SHIFT;
+ writel(val, control_phy-ctrl_sma);
+}
+EXPORT_SYMBOL_GPL(omap_control_pcie_tx_rx_control);
+
+/**
* omap_control_phy_power - power on/off the phy using control module reg
* @dev: the control module device
* @on: 0 or 1, based on powering on or off the PHY
@@ -61,6 +95,7 @@ void omap_control_phy_power(struct device *dev, int on)
val |= OMAP_CTRL_DEV_PHY_PD;
break;
+ case OMAP_CTRL_TYPE_PCIE:
case OMAP_CTRL_TYPE_PIPE3:
rate = clk_get_rate(control_phy-sys_clk);
rate = rate/100;
@@ -211,6 +246,7 @@ EXPORT_SYMBOL_GPL(omap_control_usb_set_mode);
static const enum omap_control_phy_type otghs_data = OMAP_CTRL_TYPE_OTGHS;
static const enum omap_control_phy_type usb2_data = OMAP_CTRL_TYPE_USB2;
static const enum omap_control_phy_type pipe3_data = OMAP_CTRL_TYPE_PIPE3;
+static const enum omap_control_phy_type pcie_data = OMAP_CTRL_TYPE_PCIE;
static const enum omap_control_phy_type dra7usb2_data =
OMAP_CTRL_TYPE_DRA7USB2;
static const enum omap_control_phy_type am437usb2_data =
OMAP_CTRL_TYPE_AM437USB2;
@@ -228,6 +264,10 @@ static const struct of_device_id
omap_control_phy_id_table[] = {
.data = pipe3_data,
},
{
+ .compatible = ti,control-phy-pcie,
+ .data = pcie_data,
+ },
+ {
.compatible = ti,control-phy-usb2-dra7,
.data = dra7usb2_data,
},
@@ -279,7 +319,8 @@ static int omap_control_phy_probe(struct platform_device
*pdev)
}
}
- if (control_phy-type == OMAP_CTRL_TYPE_PIPE3) {
+ if (control_phy-type == OMAP_CTRL_TYPE_PIPE3 ||
+ control_phy-type == OMAP_CTRL_TYPE_PCIE) {
control_phy-sys_clk = devm_clk_get(control_phy-dev,
sys_clkin);
[PATCH 00/17] PCIe support for DRA7xx
This patch series adds support for PCIe in DRA7xx including drivers and dt data. PCIe in DRA7xx uses desingware IP and hence this re-uses the pcie desingware driver (pcie-designware.c) by Jingoo. The last couple of patches are marked as *TEMP* since the TI reset driver [1] is not yet merged and is in RFC. Tested broadcom PCIe card and XIO2000 bridge along with DGE530T ethernet card. Changes from RFC: * Added external clock support for PCIE APLL * Miscellaneous cleanups in Documentation, macro naming etc.. [1] - http://www.spinics.net/lists/linux-omap/msg106411.html Keerthy (2): ARM: dts: DRA7: Add divider table to optfclk_pciephy_div clock ARM: dts: DRA7: Change the parent of apll_pcie_in_clk_mux to dpll_pcie_ref_m2ldo_ck Kishon Vijay Abraham I (15): phy: phy-omap-pipe3: Add support for PCIe PHY phy: omap-control: add external clock support for PCIe PHY phy: ti-pipe3: add external clock support for PCIe PHY phy: pipe3: insert delay to enumerate in GEN2 mode pci: host: pcie-dra7xx: add support for pcie-dra7xx controller pci: host: pcie-designware: Use *base-mask* for configuring the iATU arm: dra7xx: Add hwmod data for pcie1 phy and pcie2 phy arm: dra7xx: Add hwmod data for pcie1 and pcie2 subsystems ARM: dts: dra7xx-clocks: Add missing 32khz clocks used for PHY ARM: dts: dra7: Add dt data for PCIe PHY control module ARM: dts: dra7: Add dt data for PCIe PHY ARM: dts: dra7: Add dt data for PCIe controller ARM: OMAP: Enable PCI for DRA7 pci: host: pcie-dra7xx: use reset framework APIs to reset PCIe ARM: dts: dra7: Add *resets* property for PCIe dt node .../devicetree/bindings/pci/designware-pcie.txt|1 + Documentation/devicetree/bindings/pci/ti-pci.txt | 35 ++ Documentation/devicetree/bindings/phy/ti-phy.txt | 21 +- arch/arm/boot/dts/dra7.dtsi| 55 +++ arch/arm/boot/dts/dra7xx-clocks.dtsi | 11 +- arch/arm/mach-omap2/Kconfig|2 + arch/arm/mach-omap2/cm2_7xx.h |4 + arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 112 ++ arch/arm/mach-omap2/prm7xx.h |4 + drivers/pci/host/Kconfig | 10 + drivers/pci/host/Makefile |1 + drivers/pci/host/pci-dra7xx.c | 395 drivers/pci/host/pcie-designware.c | 39 +- drivers/pci/host/pcie-designware.h |1 + drivers/phy/phy-omap-control.c | 92 - drivers/phy/phy-ti-pipe3.c | 142 +-- include/linux/phy/omap_control_phy.h | 23 ++ 17 files changed, 898 insertions(+), 50 deletions(-) create mode 100644 Documentation/devicetree/bindings/pci/ti-pci.txt create mode 100644 drivers/pci/host/pci-dra7xx.c -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/17] pci: host: pcie-dra7xx: add support for pcie-dra7xx controller
On Tuesday, May 06, 2014 at 03:33:51 PM, Kishon Vijay Abraham I wrote:
Added support for pcie controller in dra7xx. This driver re-uses
the designware core code that is already present in kernel.
[...]
+#define to_dra7xx_pcie(x)container_of((x), struct dra7xx_pcie, pp)
+
+static inline u32 dra7xx_pcie_readl(void __iomem *base, u32 offset)
Just pass struct dra7xx_pcie * instead of *base here , it will make the code
below shorter.
+{
+ return readl(base + offset);
+}
+
+static inline void dra7xx_pcie_writel(void __iomem *base, u32 offset, u32
value) +{
DTTO.
+ writel(value, base + offset);
+}
+
+static int dra7xx_pcie_link_up(struct pcie_port *pp)
+{
+ struct dra7xx_pcie *dra7xx = to_dra7xx_pcie(pp);
+ u32 reg = dra7xx_pcie_readl(dra7xx-base, PCIECTRL_DRA7XX_CONF_PHY_CS);
+
+ if (reg LINK_UP)
+ return true;
+ return false;
return reg LINK_UP;
+}
+
+static int dra7xx_pcie_establish_link(struct pcie_port *pp)
+{
+ u32 reg;
+ int retries = 1000;
+ struct dra7xx_pcie *dra7xx = to_dra7xx_pcie(pp);
+
+ if (dw_pcie_link_up(pp)) {
+ dev_err(pp-dev, link is already up\n);
This will spew, since the .link_up (and thus this function) can be called
repeatedly. The subsystem will query if the link is up via this function.
+ return 0;
+ }
+
+ reg = dra7xx_pcie_readl(dra7xx-base, PCIECTRL_DRA7XX_CONF_DEVICE_CMD);
+ reg |= LTSSM_EN;
+ dra7xx_pcie_writel(dra7xx-base, PCIECTRL_DRA7XX_CONF_DEVICE_CMD, reg);
+
+ while (--retries) {
Use retries--
+ reg = dra7xx_pcie_readl(dra7xx-base,
+ PCIECTRL_DRA7XX_CONF_PHY_CS);
+ if (reg LINK_UP)
+ break;
+ usleep_range(10, 20);
+ }
+
+ if (retries = 0) {
Then check if retries == 0 and retries can be unsigned int.
+ dev_err(pp-dev, link is not up\n);
+ return -ETIMEDOUT;
+ }
+
+ return 0;
+}
[...]
+static int __init dra7xx_pcie_probe(struct platform_device *pdev)
+{
+ u32 reg;
+ int ret;
+ int irq;
+ struct phy *phy;
+ void __iomem *base;
+ struct resource *res;
+ struct dra7xx_pcie *dra7xx;
+ struct device *dev = pdev-dev;
+
+ dra7xx = devm_kzalloc(pdev-dev, sizeof(*dra7xx), GFP_KERNEL);
+ if (!dra7xx)
+ return -ENOMEM;
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq 0) {
+ dev_err(dev, missing IRQ resource\n);
+ return -EINVAL;
+ }
+
+ ret = devm_request_irq(pdev-dev, irq, dra7xx_pcie_irq_handler,
+IRQF_SHARED, dra7xx-pcie-main, dra7xx);
+ if (ret) {
+ dev_err(pdev-dev, failed to request irq\n);
+ return ret;
+ }
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, ti_conf);
+ base = devm_ioremap_nocache(dev, res-start, resource_size(res));
+ if (!base)
+ return -ENOMEM;
+
+ phy = devm_phy_get(dev, pcie-phy);
+ if (IS_ERR(phy))
+ return PTR_ERR(phy);
+
+ ret = phy_init(phy);
+ if (ret 0)
+ return ret;
+
+ ret = phy_power_on(phy);
+ if (ret 0)
+ goto err_power_on;
+
+ dra7xx-base = base;
+ dra7xx-phy = phy;
+ dra7xx-dev = dev;
+
+ pm_runtime_enable(pdev-dev);
+ ret = pm_runtime_get_sync(pdev-dev);
+ if (IS_ERR_VALUE(ret)) {
+ dev_err(dev, pm_runtime_get_sync failed\n);
+ goto err_runtime_get;
+ }
+
+ reg = dra7xx_pcie_readl(dra7xx-base, PCIECTRL_DRA7XX_CONF_DEVICE_CMD);
+ reg = ~LTSSM_EN;
+ dra7xx_pcie_writel(dra7xx-base, PCIECTRL_DRA7XX_CONF_DEVICE_CMD, reg);
platform_set_drvdata() should be here, before you add the port.
+ ret = add_pcie_port(dra7xx, pdev);
+ if (ret 0)
+ goto err_add_port;
+
+ platform_set_drvdata(pdev, dra7xx);
+ return 0;
[...]
--
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 V5 0/3] arm: dts: dra7: Updates for adding crossbar device
Some socs have a large number of interrupts requests to service the needs of its many peripherals and subsystems. All of the interrupt requests lines from the subsystems are not needed at the same time, so they have to be muxed to the controllers appropriately. In such places a interrupt controllers are preceded by an IRQ CROSSBAR that provides flexibility in muxing the device interrupt requests to the controller inputs. The dts file update to support the crossbar device and convert peripheral irq numbers to crossbar number are added here. This is a rebase of V4 series on top of 3.15-rc4 This series depends on crossbar-driver-fixes sent below http://marc.info/?l=linux-omapm=139929963420299w=2 Sricharan R (3): arm: dts: dra7: Add crossbar device binding arm: dts: dra7: Replace peripheral interrupt numbers with crossbar inputs arm: dts: dra7: Add routable-irqs property for gic node arch/arm/boot/dts/dra7.dtsi | 109 +-- 1 file changed, 63 insertions(+), 46 deletions(-) -- 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 V5 1/3] arm: dts: dra7: Add crossbar device binding
This adds the irq crossbar device node.
There is a IRQ crossbar device in the soc, which
maps the irq requests from the peripherals to the
mpu interrupt controller's inputs. The Peripheral irq
requests are connected to only one crossbar
input and the output of the crossbar is connected to only one
controller's input line. The crossbar device is used to map
a peripheral input to a free mpu's interrupt controller line.
Cc: Benoit Cousson bcous...@baylibre.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
[V5] Rebased on top of 3.15-rc4 and corrected the
irqs-reserved list
arch/arm/boot/dts/dra7.dtsi |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 149b550..0274a86 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -790,6 +790,14 @@
status = disabled;
};
};
+
+ crossbar_mpu: crossbar@4a02 {
+ compatible = ti,irq-crossbar;
+ reg = 0x4a002a48 0x130;
+ ti,max-irqs = 160;
+ ti,reg-size = 2;
+ ti,irqs-reserved = 0 1 2 3 5 6 131 132;
+ };
};
/include/ dra7xx-clocks.dtsi
--
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 V5 2/3] arm: dts: dra7: Replace peripheral interrupt numbers with crossbar inputs
Now with the crossbar IP in picture, the peripherals do not have the
fixed interrupt lines. Instead they rely on the crossbar irqchip to
allocate and map a free interrupt line to its crossbar input. So replacing
all the peripheral interrupt numbers with its fixed crossbar input lines.
Cc: Benoit Cousson bcous...@baylibre.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
[V5] Rebased on 3.15-rc4 and replaced irqs numbers with crossbar
numbers for new peripherals.
arch/arm/boot/dts/dra7.dtsi | 100 +++
1 file changed, 54 insertions(+), 46 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 0274a86..52e4bd0 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -106,8 +106,8 @@
ti,hwmods = l3_main_1, l3_main_2;
reg = 0x4400 0x2000,
0x4480 0x3000;
- interrupts = GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH,
-GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH;
+ interrupts = GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH;
prm: prm@4ae06000 {
compatible = ti,dra7-prm;
@@ -182,10 +182,10 @@
sdma: dma-controller@4a056000 {
compatible = ti,omap4430-sdma;
reg = 0x4a056000 0x1000;
- interrupts = GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH,
-GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH,
-GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH,
-GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH;
+ interrupts = GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH;
#dma-cells = 1;
#dma-channels = 32;
#dma-requests = 127;
@@ -194,7 +194,7 @@
gpio1: gpio@4ae1 {
compatible = ti,omap4-gpio;
reg = 0x4ae1 0x200;
- interrupts = GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH;
+ interrupts = GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = gpio1;
gpio-controller;
#gpio-cells = 2;
@@ -205,7 +205,7 @@
gpio2: gpio@48055000 {
compatible = ti,omap4-gpio;
reg = 0x48055000 0x200;
- interrupts = GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH;
+ interrupts = GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = gpio2;
gpio-controller;
#gpio-cells = 2;
@@ -216,7 +216,7 @@
gpio3: gpio@48057000 {
compatible = ti,omap4-gpio;
reg = 0x48057000 0x200;
- interrupts = GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH;
+ interrupts = GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = gpio3;
gpio-controller;
#gpio-cells = 2;
@@ -227,7 +227,7 @@
gpio4: gpio@48059000 {
compatible = ti,omap4-gpio;
reg = 0x48059000 0x200;
- interrupts = GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH;
+ interrupts = GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = gpio4;
gpio-controller;
#gpio-cells = 2;
@@ -238,7 +238,7 @@
gpio5: gpio@4805b000 {
compatible = ti,omap4-gpio;
reg = 0x4805b000 0x200;
- interrupts = GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH;
+ interrupts = GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = gpio5;
gpio-controller;
#gpio-cells = 2;
@@ -249,7 +249,7 @@
gpio6: gpio@4805d000 {
compatible = ti,omap4-gpio;
reg = 0x4805d000 0x200;
- interrupts = GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH;
+ interrupts = GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = gpio6;
gpio-controller;
#gpio-cells = 2;
@@ -260,7 +260,7 @@
gpio7: gpio@48051000 {
compatible = ti,omap4-gpio;
reg = 0x48051000 0x200;
- interrupts =
[PATCH V5 3/3] arm: dts: dra7: Add routable-irqs property for gic node
There is a IRQ crossbar device in the soc, which maps the irq requests from the peripherals to the mpu interrupt controller's inputs. The gic provides the support for such IPs in the form of routable-irqs. So adding the property here to gic node. Cc: Benoit Cousson bcous...@baylibre.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Rajendra Nayak rna...@ti.com Cc: Tony Lindgren t...@atomide.com Signed-off-by: Sricharan R r.sricha...@ti.com Signed-off-by: Nishanth Menon n...@ti.com --- [V5] Rebased and corrected routable irqs from 160 to 192 arch/arm/boot/dts/dra7.dtsi |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi index 52e4bd0..cec826f 100644 --- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -72,6 +72,7 @@ compatible = arm,cortex-a15-gic; interrupt-controller; #interrupt-cells = 3; + arm,routable-irqs = 192; reg = 0x48211000 0x1000, 0x48212000 0x1000, 0x48214000 0x2000, -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/17] pci: host: pcie-designware: Use *base-mask* for configuring the iATU
On Tuesday 06 May 2014 19:03:52 Kishon Vijay Abraham I wrote: In DRA7, the cpu sees 32bit address, but the pcie controller can see only 28bit address. So whenever the cpu issues a read/write request, the 4 most significant bits are used by L3 to determine the target controller. For example, the cpu reserves 0x2000_ - 0x2FFF_ for PCIe controller but the PCIe controller will see only (0x000_ - 0xFFF_FFF). So for programming the outbound translation window the *base* should be programmed as 0x000_. Whenever we try to write to say 0x2000_, it will be translated to whatever we have programmed in the translation window with base as 0x000_. Cc: Bjorn Helgaas bhelg...@google.com Cc: Marek Vasut ma...@denx.de Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Acked-by: Jingoo Han jg1@samsung.com Acked-by: Mohit Kumar mohit.ku...@st.com Sorry, but NAK. We have a standard 'dma-ranges' property to handle this, so use it. See the x-gene PCIe driver patches for an example. Please also talk to Santosh about it, as he is implementing generic support for parsing dma-ranges in platform devices at the moment. I also suspect you will have to implement swiotlb support to make generic PCI devices work behind this bridge. Otherwise you end up with random physical addresses passed into DMA registers. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/17] pci: host: pcie-dra7xx: add support for pcie-dra7xx controller
On Tuesday 06 May 2014 19:03:51 Kishon Vijay Abraham I wrote:
Added support for pcie controller in dra7xx. This driver re-uses
the designware core code that is already present in kernel.
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Mohit Kumar mohit.ku...@st.com
Cc: Jingoo Han jg1@samsung.com
Cc: Marek Vasut ma...@denx.de
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Looks pretty good overall, just a few details I noticed:
diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt
b/Documentation/devicetree/bindings/pci/ti-pci.txt
new file mode 100644
index 000..6cb6f09
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
@@ -0,0 +1,33 @@
+TI PCI Controllers
+
+PCIe Designware Controller
+This node should have the properties described in designware-pcie.txt.
+ - compatible: Should be ti,dra7xx-pcie
No xx in compatible strings please. Just make name this after the first
chip to use this particular interface.
+ - reg : Address and length of the register set for the device.
+ - reg-names : ti_conf for the TI specific registers and rc_dbics for the
+ designware registers.
The description uses inconsistent quotation marks. You should also have
a fixed order in the binding, such as
- reg : Two register ranges as listed in the reg-names property
- reg-names : The first entry must be ti-conf for the TI specific registers
The second entry must be rc-dbics for the designware pcie
registers.
+ - phys : the phandle for the PHY device (used by generic PHY framework)
+ - phy-names : the names of the PHY corresponding to the PHYs present in the
+ *phy* phandle.
It's not just a phandle, it can be any phy specifier including additional
argument cells.
The second line should just read
- phy-names : must be pcie-phy
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index a6f67ec..7be6393 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -1,6 +1,16 @@
menu PCI host controller drivers
depends on PCI
+config PCI_DRA7XX
+ bool TI DRA7xx PCIe controller
+ select PCIE_DW
+ depends on OF || HAS_IOMEM || TI_PIPE3
I think you mean , not || here.
+static inline u32 x(void __iomem *base, u32 offset)
+{
+ return readl(base + offset);
+}
+
+static inline void dra7xx_pcie_writel(void __iomem *base, u32 offset, u32
value)
+{
+ writel(value, base + offset);
+}
These don't actually seem to add any value, you need more characters
to call the inline function than to open-code it.
+static void dra7xx_pcie_enable_interrupts(struct pcie_port *pp)
+{
+ struct dra7xx_pcie *dra7xx = to_dra7xx_pcie(pp);
+
+ dra7xx_pcie_writel(dra7xx-base, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MAIN,
+~INTERRUPTS);
+ dra7xx_pcie_writel(dra7xx-base,
+PCIECTRL_DRA7XX_CONF_IRQENABLE_SET_MAIN, INTERRUPTS);
+ dra7xx_pcie_writel(dra7xx-base, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI,
+~LEG_EP_INTERRUPTS ~MSI);
+
+ if (IS_ENABLED(CONFIG_PCI_MSI))
+ dra7xx_pcie_writel(dra7xx-base,
+PCIECTRL_DRA7XX_CONF_IRQENABLE_SET_MSI, MSI);
+ else
+ dra7xx_pcie_writel(dra7xx-base,
+PCIECTRL_DRA7XX_CONF_IRQENABLE_SET_MSI,
+LEG_EP_INTERRUPTS);
Doesn't this just enable one or the other? In general I'd assume you need
both INTx and MSI, at least if MSI is available.
It probably doesn't hurt to always turn them all on.
+static int add_pcie_port(struct dra7xx_pcie *dra7xx,
+ struct platform_device *pdev)
+{
+ int ret;
+ struct pcie_port *pp;
+ struct resource *res;
+ struct device *dev = pdev-dev;
+
+ pp = dra7xx-pp;
+ pp-dev = dev;
+ pp-ops = dra7xx_pcie_host_ops;
+
+ spin_lock_init(pp-conf_lock);
+
+ pp-irq = platform_get_irq(pdev, 1);
+ if (pp-irq 0) {
+ dev_err(dev, missing IRQ resource\n);
+ return -EINVAL;
+ }
The binding does not list a mandatory interrupts property, so
this should not be treated as an error.
+static int __init dra7xx_pcie_probe(struct platform_device *pdev)
+{
+ irq = platform_get_irq(pdev, 0);
+ if (irq 0) {
+ dev_err(dev, missing IRQ resource\n);
+ return -EINVAL;
+ }
+
+ ret = devm_request_irq(pdev-dev, irq, dra7xx_pcie_irq_handler,
+IRQF_SHARED, dra7xx-pcie-main, dra7xx);
+ if (ret) {
+ dev_err(pdev-dev, failed to request irq\n);
+ return ret;
+ }
Same here.
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, ti_conf);
+ base = devm_ioremap_nocache(dev, res-start, resource_size(res));
Just use devm_ioremap() instead of devm_ioremap_nocache(). The second
one is just there for historic reasons, and they always do the same
Re: [RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7
* Archit Taneja arc...@ti.com [140505 22:24]: Hi, On Monday 21 April 2014 08:40 PM, Tony Lindgren wrote: * Archit Taneja arc...@ti.com [140420 22:16]: Hi, On Friday 18 April 2014 10:48 PM, Tony Lindgren wrote: * Archit Taneja arc...@ti.com [140416 06:20]: Add DT node for the ctrl-core sub module of the DRA7 control module. We map the CTRL_MODULE_CORE address region up to 0x4a002d60, this region contains register fields which configure clocks. The remainder of the registers are related to pad configurations or cross-bar configurations, and therefore aren't mapped. Can you please check if this can just use the existing regmap syscon mapping: syscon = dra7_ctrl_general; See how the drivers/regulator/pbias-regulator.c is using the syscon to initialize a regulator and then omap_hsmmc.c just does the standard regulator calls. The thing is that this bit needs to be set before the the DSS hwmods are reset, and that happens very early. If we don't do this, DSS won't reset properly, and not get back to an idle state. I am not sure where I can configure the syscon register early enough that it happens before the hwmods are reset. With a syscon mapping, I guess we would access the register when the DSS driver is probed. But that's too late for us. Ideally, it would be much better to have a syscon mapping. Do you have any suggestions how this can be achieved very early in boot? It's best to move the reset and initialization of DSS happen later. I believe we already are resetting only some of the hwmods early on. I looked at this in some more detail. With the current hwmod flags(HWMOD_INIT_NO_RESET/NO_IDLE), we still try to enable the IP, it's just the reset part(ocp reset/custom reset and sysc register) or the disable part that is skipped. hwmod still tries to enable the IP. This again results in the same issue. One thing which wasn't clear was that why do we enable a hwmod in the first place, if we know that we are going to skip reset? Probably to configure the idle bits. In general, we should configure the modules lazily as the driver probes as requested, and then idle the unused modules with a late_initcall. 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 V5 2/3] arm: dts: dra7: Replace peripheral interrupt numbers with crossbar inputs
* Sricharan R r.sricha...@ti.com [140506 06:58]:
Now with the crossbar IP in picture, the peripherals do not have the
fixed interrupt lines. Instead they rely on the crossbar irqchip to
allocate and map a free interrupt line to its crossbar input. So replacing
all the peripheral interrupt numbers with its fixed crossbar input lines.
Presumably this depends on the crossbar fixes?
Are you guys sure this is OK to apply now? Has it really been tested
for the devices to work with the mainline kernel?
I do not want to see constant patching of things over and over again
with this stuff, so I'd like to see at least two Tested-by's for this
series before applying.
Regards,
Tony
Cc: Benoit Cousson bcous...@baylibre.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
[V5] Rebased on 3.15-rc4 and replaced irqs numbers with crossbar
numbers for new peripherals.
arch/arm/boot/dts/dra7.dtsi | 100
+++
1 file changed, 54 insertions(+), 46 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 0274a86..52e4bd0 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -106,8 +106,8 @@
ti,hwmods = l3_main_1, l3_main_2;
reg = 0x4400 0x2000,
0x4480 0x3000;
- interrupts = GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH,
- GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH;
+ interrupts = GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH,
+ GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH;
prm: prm@4ae06000 {
compatible = ti,dra7-prm;
@@ -182,10 +182,10 @@
sdma: dma-controller@4a056000 {
compatible = ti,omap4430-sdma;
reg = 0x4a056000 0x1000;
- interrupts = GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH,
- GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH,
- GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH,
- GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH;
+ interrupts = GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH,
+ GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH,
+ GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH,
+ GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH;
#dma-cells = 1;
#dma-channels = 32;
#dma-requests = 127;
@@ -194,7 +194,7 @@
gpio1: gpio@4ae1 {
compatible = ti,omap4-gpio;
reg = 0x4ae1 0x200;
- interrupts = GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH;
+ interrupts = GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = gpio1;
gpio-controller;
#gpio-cells = 2;
@@ -205,7 +205,7 @@
gpio2: gpio@48055000 {
compatible = ti,omap4-gpio;
reg = 0x48055000 0x200;
- interrupts = GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH;
+ interrupts = GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = gpio2;
gpio-controller;
#gpio-cells = 2;
@@ -216,7 +216,7 @@
gpio3: gpio@48057000 {
compatible = ti,omap4-gpio;
reg = 0x48057000 0x200;
- interrupts = GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH;
+ interrupts = GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = gpio3;
gpio-controller;
#gpio-cells = 2;
@@ -227,7 +227,7 @@
gpio4: gpio@48059000 {
compatible = ti,omap4-gpio;
reg = 0x48059000 0x200;
- interrupts = GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH;
+ interrupts = GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = gpio4;
gpio-controller;
#gpio-cells = 2;
@@ -238,7 +238,7 @@
gpio5: gpio@4805b000 {
compatible = ti,omap4-gpio;
reg = 0x4805b000 0x200;
- interrupts = GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH;
+ interrupts = GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = gpio5;
gpio-controller;
#gpio-cells = 2;
@@ -249,7 +249,7 @@
gpio6: gpio@4805d000 {
compatible = ti,omap4-gpio;
reg = 0x4805d000 0x200;
- interrupts = GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH;
+
Re: [PATCH 10/19] arm: dts: add cooling properties on omap4430 cpu node
* Alex Shi alex@linaro.org [140325 03:54]: From: Eduardo Valentin eduardo.valen...@ti.com OMAP4430 devices can reach high temperatures and thus needs to have cpufreq-cooling on systems running on it. This patch adds the required cooling device properties so that cpufreq-cpu0 driver loads the cooling device. Alex, what's the status of this series? I could not find the complete thread, so wondering what to do with patches 09 - 13? Regards, Tony Cc: Benoît Cousson bcous...@baylibre.com Cc: Tony Lindgren t...@atomide.com Cc: Russell King li...@arm.linux.org.uk Cc: linux-omap@vger.kernel.org Cc: devicetree-disc...@lists.ozlabs.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com (cherry picked from commit 72af5e6d0c3e01655c1c1fc7c7ca94a2b663611e) Signed-off-by: Alex Shi alex@linaro.org --- arch/arm/boot/dts/omap443x.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi index cccf39a..d2deba0 100644 --- a/arch/arm/boot/dts/omap443x.dtsi +++ b/arch/arm/boot/dts/omap443x.dtsi @@ -22,6 +22,11 @@ 1008000 1375000 ; clock-latency = 30; /* From legacy driver */ + + /* cooling options */ + cooling-min-level = 0; + cooling-max-level = 3; + #cooling-cells = 2; /* min followed by max */ }; }; }; -- 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: [RFC] [v2 Patch 1/6] drivers: reset: TI: SoC reset controller support.
Hi,
[ I had to manually rewrap your email which came with long lines, please
have a read on Documentation/email-clients.txt ]
On Tue, May 06, 2014 at 08:14:04AM -0500, Dan Murphy wrote:
The TI SoC reset controller support utilizes the
reset controller framework to give device drivers or
function drivers a common set of APIs to call to reset
a module.
The reset-ti is a common interface to the reset framework.
The register data is retrieved during initialization
of the reset driver through the reset-ti-data
file. The array of data is associated with the compatible from the
respective DT entry.
Once the data is available then this is derefenced within the common
interface.
The device driver has the ability to assert, deassert or perform a
complete reset.
This code was derived from previous work by Rajendra Nayak and Afzal
Mohammed.
The code was changed to adopt to the reset core and abstract away the SoC
information.
you should break your commit log at around 72 characters at most.
Do you mean 72 characters per line?
sartalics no, that's too much. The entire commit log /sartalics
Yes, per-line :-)
diff --git a/drivers/reset/ti/reset-ti-data.h
b/drivers/reset/ti/reset-ti-data.h
new file mode 100644
index 000..4d2a6d5
--- /dev/null
+++ b/drivers/reset/ti/reset-ti-data.h
@@ -0,0 +1,56 @@
+/*
+ * PRCM reset driver for TI SoC's
+ *
+ * Copyright 2014 Texas Instruments Inc.
this is not the TI aproved way for copyright notices. Yeah,
nit-picking...
Hmm. Will need to look at other TI files to correct then.
/**
* file.c - Short Description
*
* Copyright (C) 2010-2011 Texas Instruments Incorporated - http://www.ti.com
*
* Author: Dan Murphy dmur...@ti.com
*
* GPL text goes here
*/
+ * Author: Dan Murphy dmur...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _RESET_TI_DATA_H_
+#define _RESET_TI_DATA_H_
+
+#include linux/kernel.h
+#include linux/reset-controller.h
+
+/**
+ * struct ti_reset_reg_data - Structure of the reset register information
+ *for a particular SoC.
+ * @rstctrl_offs: This is the reset control offset value from
+ *from the parent reset node.
+ * @rstst_offs: This is the reset status offset value from
+ *from the parent reset node.
+ * @rstctrl_bit: This is the reset control bit for the module.
+ * @rstst_bit: This is the reset status bit for the module.
+ *
+ * This structure describes the reset register control and status offsets.
+ * The bits are also defined for the same.
+ */
+struct ti_reset_reg_data {
+ void __iomem *reg_base;
+ u32 rstctrl_offs;
+ u32 rstst_offs;
+ u32 rstctrl_bit;
+ u32 rstst_bit;
this structure can be folded into struct ti_reset_data and all of that
can be initialized during probe.
I could do that. It will simplify the de-referencing as well.
yeah, and it will prevent constant alloc/free of this structure
diff --git a/drivers/reset/ti/reset-ti.c b/drivers/reset/ti/reset-ti.c
new file mode 100644
index 000..349f4fb
--- /dev/null
+++ b/drivers/reset/ti/reset-ti.c
@@ -0,0 +1,267 @@
+/*
+ * PRCM reset driver for TI SoC's
+ *
+ * Copyright 2014 Texas Instruments Inc.
+ *
+ * Author: Dan Murphy dmur...@ti.com
fix copyright notice here too
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/device.h
+#include linux/err.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of_address.h
+#include linux/of_device.h
+#include linux/platform_device.h
+#include linux/reset.h
+#include linux/slab.h
+
+#include reset-ti-data.h
+
+#define DRIVER_NAME prcm_reset_ti
+
+static struct ti_reset_data *ti_data;
NAK, you *really* don't need and don't to have this global here. It only
don't _want_ to have, missed the verb
+ return ret;
+ }
+
+ /* node parent */
+ parent = of_get_parent(dev_node);
+ if (!parent) {
+ pr_err(%s: Cannot find parent reset node\n, __func__);
+ return ret;
+ }
+ /* prcm reset parent */
+ reset_parent = of_get_next_parent(parent);
+ if (!reset_parent) {
+ pr_err(%s: Cannot find parent reset node\n, __func__);
+ return ret;
+ }
+ /* PRCM Parent */
+ reset_parent = of_get_parent(reset_parent);
+ if (!prcm_parent) {
+ pr_err(%s: Cannot find parent reset node\n, __func__);
+ return ret;
+ }
+
+ reset_data-reg_base = of_iomap(reset_parent, 0);
please don't. of_iomap() is the
Re: [PATCH v3 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
* Pekon Gupta pe...@ti.com [140422 00:34]:
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -9,6 +9,7 @@
#include am33xx.dtsi
#include am335x-bone-common.dtsi
+#include am335x-bone-memory-cape.dts
ldo3_reg {
regulator-min-microvolt = 180;
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -9,6 +9,7 @@
#include am33xx.dtsi
#include am335x-bone-common.dtsi
+#include am335x-bone-memory-cape.dts
ldo3_reg {
regulator-min-microvolt = 180;
Have you checked that including the capes unconditionally for
non-integrated devices is safe? Maybe decompile the dtb using
dtc and see what is in the produced dts file?
I'm mostly worried about pinmux and GPMC as the pins can be used
by other capes and GPMC can have other devices.
Also, this should probably also wait until u-boot has been
confirmed of being able to enable these devices?
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 v3 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
* Pekon Gupta pe...@ti.com [140422 00:34]:
+gpmc {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = nand_flash_x8;
+ ranges = 0 0 0x0800 0x1000; /* CS0: NAND */
Please use the minimum size 16MB GPMC range here, NAND only
has few registers addressable unlike NOR that actually uses the
whole range.
+ nand@0,0 {
+ reg = 0 0 0; /* CS0, offset 0 */
Then here map the true size of the NAND device IO register area.
BTW, we should do the similar changes to other files so we can
unify the GPMC partitioning a bit. But that's unsafe to do until
we have fixed the issue of mapping GPMC devices to a different
location from the bootloader location.
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 v3 3/4] ARM: dts: dra7: add support for parallel NAND flash
* Pekon Gupta pe...@ti.com [140422 02:03]:
+
+gpmc {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = nand_flash_x16;
+ ranges = 0 0 0x0800 0x1000;
Here too please use the minimum 16MB GPMC partition for NAND.
+ nand@0,0 {
+ reg = 0 0 0;
And the true IO range size of the device registers here for reg.
Cheers,
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 v3 4/4] ARM: dts: am43xx: fix starting offset of NAND.filesystem MTD partition
* Pekon Gupta pe...@ti.com [140422 02:03]:
MTD NAND partition for file-system should start at offset=0xA0
Applying to omap-for-v3.16/fixes-not-urgent with hex changed to use
lower case like we tend to do.
Hmm, how come you did not fold this into the original patch to the
mainline kernel as it seems you had the fix in the vendor tree
earlier?
Regards,
Tony
Signed-off-by: Pekon Gupta pe...@ti.com
---
arch/arm/boot/dts/am43x-epos-evm.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
index 167dbc8..d09e6fb 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -341,7 +341,7 @@
};
partition@9 {
label = NAND.file-system;
- reg = 0x0080 0x1F60;
+ reg = 0x00A0 0x1F60;
};
};
};
--
1.8.5.1.163.gd7aced9
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm/dts: am335x-evmsk enable display and lcd panel support
* Darren Etheridge detheri...@ti.com [140422 13:39]:
Add the necessary nodes to enable the LCD controller and the
LCD panel that is attached to the Texas Instruments AM335x
EVMSK platform. Also setup the necessary pin mux within the
DT file to drive the LCD connector and add the correct
pinmux settings for the lcd pins to be configured to when
the SoC goes into sleep state for the minimum power
consumption.
For the sleep mode LCD pin settings, MUX_MODE7 is chosen as
this corresponds to switching the pins into input GPIO's with
an internal pulldown. Which has been determined to offer the
lowest power solution vs leaving the pins configured in LCD
mode.
Probably best that Tomi queues all the panel .dts changes into
a separate immutable branch that I can merge too.
Tony
Signed-off-by: Darren Etheridge detheri...@ti.com
---
arch/arm/boot/dts/am335x-evmsk.dts | 105
+
1 file changed, 105 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index ec08f6f..a5e1ab8 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -138,12 +138,113 @@
Headphone Jack, HPLOUT,
Headphone Jack, HPROUT;
};
+
+ panel {
+ compatible = ti,tilcdc,panel;
+ pinctrl-names = default, sleep;
+ pinctrl-0 = lcd_pins_default;
+ pinctrl-1 = lcd_pins_sleep;
+ status = okay;
+ panel-info {
+ ac-bias = 255;
+ ac-bias-intrpt= 0;
+ dma-burst-sz = 16;
+ bpp = 32;
+ fdd = 0x80;
+ sync-edge = 0;
+ sync-ctrl = 1;
+ raster-order = 0;
+ fifo-th = 0;
+ };
+ display-timings {
+ 480x272 {
+ hactive = 480;
+ vactive = 272;
+ hback-porch = 43;
+ hfront-porch= 8;
+ hsync-len = 4;
+ vback-porch = 12;
+ vfront-porch= 4;
+ vsync-len = 10;
+ clock-frequency = 900;
+ hsync-active= 0;
+ vsync-active= 0;
+ };
+ };
+ };
};
am33xx_pinmux {
pinctrl-names = default;
pinctrl-0 = gpio_keys_s0 clkout2_pin;
+ lcd_pins_default: lcd_pins_default {
+ pinctrl-single,pins =
+ 0x20 (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad8.lcd_data16
*/
+ 0x24 (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad9.lcd_data17
*/
+ 0x28 (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad10.lcd_data18
*/
+ 0x2c (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad11.lcd_data19
*/
+ 0x30 (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad12.lcd_data20
*/
+ 0x34 (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad13.lcd_data21
*/
+ 0x38 (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad14.lcd_data22
*/
+ 0x3c (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad15.lcd_data23
*/
+ 0xa0 (PIN_OUTPUT | MUX_MODE0) /* lcd_data0.lcd_data0
*/
+ 0xa4 (PIN_OUTPUT | MUX_MODE0) /* lcd_data1.lcd_data1
*/
+ 0xa8 (PIN_OUTPUT | MUX_MODE0) /* lcd_data2.lcd_data2
*/
+ 0xac (PIN_OUTPUT | MUX_MODE0) /* lcd_data3.lcd_data3
*/
+ 0xb0 (PIN_OUTPUT | MUX_MODE0) /* lcd_data4.lcd_data4
*/
+ 0xb4 (PIN_OUTPUT | MUX_MODE0) /* lcd_data5.lcd_data5
*/
+ 0xb8 (PIN_OUTPUT | MUX_MODE0) /* lcd_data6.lcd_data6
*/
+ 0xbc (PIN_OUTPUT | MUX_MODE0) /* lcd_data7.lcd_data7
*/
+ 0xc0 (PIN_OUTPUT | MUX_MODE0) /* lcd_data8.lcd_data8
*/
+ 0xc4 (PIN_OUTPUT | MUX_MODE0) /* lcd_data9.lcd_data9
*/
+ 0xc8 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data10.lcd_data10 */
+ 0xcc (PIN_OUTPUT | MUX_MODE0) /*
lcd_data11.lcd_data11 */
+ 0xd0 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data12.lcd_data12 */
+ 0xd4 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data13.lcd_data13 */
+ 0xd8 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data14.lcd_data14 */
+ 0xdc (PIN_OUTPUT | MUX_MODE0) /*
lcd_data15.lcd_data15 */
+ 0xe0 (PIN_OUTPUT | MUX_MODE0) /* lcd_vsync.lcd_vsync
*/
Re: [Resend/PATCH] arm: dts: am43x-epos: Add qspi device.
* sourav sourav.pod...@ti.com [140506 01:23]: Hi Tony, On Monday 28 April 2014 07:12 PM, Sourav Poddar wrote: This patch adds qspi nodes for am43xx SOC devices. Signed-off-by: Sourav Poddarsourav.pod...@ti.com This patch has been posted many times before. If this patch looks OK, can it be picked? Thanks applying into omap-for-v3.16/dt. 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 1/4] ARM: dts: am335x-bone-common: use phandles for USB and DMA refs
On Mon, Apr 28, 2014 at 10:58:29AM -0300, Guido Martínez wrote:
Use phandles instead of unit adresses to reference usb and dma nodes.
This makes the DT more robust and readable.
Signed-off-by: Guido Martínez gu...@vanguardiasur.com.ar
Acked-by: Felipe Balbi ba...@ti.com
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 2e7d932..b95bc9a 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -183,28 +183,28 @@
usb {
status = okay;
- control@44e10620 {
+ usb_ctrl_mod {
status = okay;
};
- usb-phy@47401300 {
+ usb0_phy {
status = okay;
};
- usb-phy@47401b00 {
+ usb1_phy {
status = okay;
};
- usb@47401000 {
+ usb0 {
status = okay;
};
- usb@47401800 {
+ usb1 {
status = okay;
dr_mode = host;
};
- dma-controller@47402000 {
+ cppi41dma {
status = okay;
};
};
--
1.9.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
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 4/4] ARM: dts: am335x-igep0033: use phandles for USB and DMA refs
On Mon, Apr 28, 2014 at 10:58:32AM -0300, Guido Martínez wrote:
Use phandles instead of unit adresses to reference usb and dma nodes.
This makes the DT more robust and readable.
Signed-off-by: Guido Martínez gu...@vanguardiasur.com.ar
Acked-by: Felipe Balbi ba...@ti.com
---
arch/arm/boot/dts/am335x-igep0033.dtsi | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-igep0033.dtsi
b/arch/arm/boot/dts/am335x-igep0033.dtsi
index 9f22c18..81cf68b 100644
--- a/arch/arm/boot/dts/am335x-igep0033.dtsi
+++ b/arch/arm/boot/dts/am335x-igep0033.dtsi
@@ -201,28 +201,28 @@
usb {
status = okay;
- control@44e10620 {
+ usb_ctrl_mod {
status = okay;
};
- usb-phy@47401300 {
+ usb0_phy {
status = okay;
};
- usb-phy@47401b00 {
+ usb1_phy {
status = okay;
};
- usb@47401000 {
+ usb0 {
status = okay;
};
- usb@47401800 {
+ usb1 {
status = okay;
dr_mode = host;
};
- dma-controller@47402000 {
+ cppi41dma {
status = okay;
};
};
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 2/4] ARM: dts: am335x-evm: use phandles for USB and DMA refs
On Mon, Apr 28, 2014 at 05:54:33PM -0300, Guido Martínez wrote:
Use phandles instead of unit adresses to reference usb and dma nodes.
This makes the DT more robust and readable.
Signed-off-by: Guido Martínez gu...@vanguardiasur.com.ar
Acked-by: Felipe Balbi ba...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index 6028217..33f7c57 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -330,31 +330,31 @@
usb {
status = okay;
+};
- control@44e10620 {
- status = okay;
- };
+usb_ctrl_mod {
+ status = okay;
+};
- usb-phy@47401300 {
- status = okay;
- };
+usb0_phy {
+ status = okay;
+};
- usb-phy@47401b00 {
- status = okay;
- };
+usb1_phy {
+ status = okay;
+};
- usb@47401000 {
- status = okay;
- };
+usb0 {
+ status = okay;
+};
- usb@47401800 {
- status = okay;
- dr_mode = host;
- };
+usb1 {
+ status = okay;
+ dr_mode = host;
+};
- dma-controller@47402000 {
- status = okay;
- };
+cppi41dma {
+ status = okay;
};
i2c1 {
--
1.9.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
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 3/4] ARM: dts: am335x-evmsk: use phandles for USB and DMA refs
On Mon, Apr 28, 2014 at 10:58:31AM -0300, Guido Martínez wrote:
Use phandles instead of unit adresses to reference usb and dma nodes.
This makes the DT more robust and readable.
Signed-off-by: Guido Martínez gu...@vanguardiasur.com.ar
Acked-by: Felipe Balbi ba...@ti.com
---
arch/arm/boot/dts/am335x-evmsk.dts | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index ab23885..44b8d75 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -364,28 +364,28 @@
usb {
status = okay;
- control@44e10620 {
+ usb_ctrl_mod {
status = okay;
};
- usb-phy@47401300 {
+ usb0_phy {
status = okay;
};
- usb-phy@47401b00 {
+ usb1_phy {
status = okay;
};
- usb@47401000 {
+ usb0 {
status = okay;
};
- usb@47401800 {
+ usb1 {
status = okay;
dr_mode = host;
};
- dma-controller@47402000 {
+ cppi41dma {
status = okay;
};
};
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 3/4] ARM: dts: am335x-evmsk: use phandles for USB and DMA refs
On Mon, Apr 28, 2014 at 05:54:34PM -0300, Guido Martínez wrote:
Use phandles instead of unit adresses to reference usb and dma nodes.
This makes the DT more robust and readable.
Signed-off-by: Guido Martínez gu...@vanguardiasur.com.ar
Acked-by: Felipe Balbi ba...@ti.com
---
arch/arm/boot/dts/am335x-evmsk.dts | 38
+++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index ab23885..a460c2e 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -363,31 +363,31 @@
usb {
status = okay;
+};
- control@44e10620 {
- status = okay;
- };
+usb_ctrl_mod {
+ status = okay;
+};
- usb-phy@47401300 {
- status = okay;
- };
+usb0_phy {
+ status = okay;
+};
- usb-phy@47401b00 {
- status = okay;
- };
+usb1_phy {
+ status = okay;
+};
- usb@47401000 {
- status = okay;
- };
+usb0 {
+ status = okay;
+};
- usb@47401800 {
- status = okay;
- dr_mode = host;
- };
+usb1 {
+ status = okay;
+ dr_mode = host;
+};
- dma-controller@47402000 {
- status = okay;
- };
+cppi41dma {
+ status = okay;
};
epwmss2 {
--
1.9.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
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 1/4] ARM: dts: am335x-bone-common: use phandles for USB and DMA refs
On Mon, Apr 28, 2014 at 05:54:32PM -0300, Guido Martínez wrote:
Use phandles instead of unit adresses to reference usb and dma nodes.
This makes the DT more robust and readable.
Signed-off-by: Guido Martínez gu...@vanguardiasur.com.ar
(acked wrong version previously, sorry)
Acked-by: Felipe Balbi ba...@ti.com
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 38
+++
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 2e7d932..ded1283 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -182,31 +182,31 @@
usb {
status = okay;
+};
- control@44e10620 {
- status = okay;
- };
+usb_ctrl_mod {
+ status = okay;
+};
- usb-phy@47401300 {
- status = okay;
- };
+usb0_phy {
+ status = okay;
+};
- usb-phy@47401b00 {
- status = okay;
- };
+usb1_phy {
+ status = okay;
+};
- usb@47401000 {
- status = okay;
- };
+usb0 {
+ status = okay;
+};
- usb@47401800 {
- status = okay;
- dr_mode = host;
- };
+usb1 {
+ status = okay;
+ dr_mode = host;
+};
- dma-controller@47402000 {
- status = okay;
- };
+cppi41dma {
+ status = okay;
};
i2c0 {
--
1.9.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
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 2/4] ARM: dts: am335x-evm: use phandles for USB and DMA refs
On Mon, Apr 28, 2014 at 10:58:30AM -0300, Guido Martínez wrote:
Use phandles instead of unit adresses to reference usb and dma nodes.
This makes the DT more robust and readable.
Signed-off-by: Guido Martínez gu...@vanguardiasur.com.ar
Acked-by: Felipe Balbi ba...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index 6028217..e802627 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -331,28 +331,28 @@
usb {
status = okay;
- control@44e10620 {
+ usb_ctrl_mod {
status = okay;
};
- usb-phy@47401300 {
+ usb0_phy {
status = okay;
};
- usb-phy@47401b00 {
+ usb1_phy {
status = okay;
};
- usb@47401000 {
+ usb0 {
status = okay;
};
- usb@47401800 {
+ usb1 {
status = okay;
dr_mode = host;
};
- dma-controller@47402000 {
+ cppi41dma {
status = okay;
};
};
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 4/4] ARM: dts: am335x-igep0033: use phandles for USB and DMA refs
On Mon, Apr 28, 2014 at 05:54:35PM -0300, Guido Martínez wrote:
Use phandles instead of unit adresses to reference usb and dma nodes.
This makes the DT more robust and readable.
Signed-off-by: Guido Martínez gu...@vanguardiasur.com.ar
Cc: Enric Balletbo i Serra eballe...@iseebcn.com
Acked-by: Felipe Balbi ba...@ti.com
---
arch/arm/boot/dts/am335x-igep0033.dtsi | 38
+-
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-igep0033.dtsi
b/arch/arm/boot/dts/am335x-igep0033.dtsi
index 9f22c18..9c53b50 100644
--- a/arch/arm/boot/dts/am335x-igep0033.dtsi
+++ b/arch/arm/boot/dts/am335x-igep0033.dtsi
@@ -200,31 +200,31 @@
usb {
status = okay;
+};
- control@44e10620 {
- status = okay;
- };
+usb_ctrl_mod {
+ status = okay;
+};
- usb-phy@47401300 {
- status = okay;
- };
+usb0_phy {
+ status = okay;
+};
- usb-phy@47401b00 {
- status = okay;
- };
+usb1_phy {
+ status = okay;
+};
- usb@47401000 {
- status = okay;
- };
+usb0 {
+ status = okay;
+};
- usb@47401800 {
- status = okay;
- dr_mode = host;
- };
+usb1 {
+ status = okay;
+ dr_mode = host;
+};
- dma-controller@47402000 {
- status = okay;
- };
+cppi41dma {
+ status = okay;
};
#include tps65910.dtsi
--
1.9.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
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v4 5/5] ARM: DRA7: Add support for soc_is_dra74x() and soc_is_dra72x() varients
* Rajendra Nayak rna...@ti.com [140429 04:22]: On Tuesday 29 April 2014 04:48 PM, Arnd Bergmann wrote: On Tuesday 29 April 2014 16:35:13 Rajendra Nayak wrote: @@ -393,7 +395,12 @@ IS_OMAP_TYPE(3430, 0x3430) #if defined(CONFIG_SOC_DRA7XX) #undef soc_is_dra7xx +#undef soc_is_dra74x +#undef soc_is_dra72x #define soc_is_dra7xx()(of_machine_is_compatible(ti,dra7)) +#define soc_is_dra74x()(of_machine_is_compatible(ti,dra74)) +#define soc_is_dra72x()(of_machine_is_compatible(ti,dra72)) + You shouldn't normally have to define these. Why are they needed? Maybe it's better to wait for a user to show up, and then we can decide whether we actually want to have them this way, or if there is a better solution for the particular use case. Normally, we'd want to make run-time decisions based on properties of the nodes a driver is working on, not the global machine compatible string. Yeah, actually this can be dropped. There is no user for it now. OK applying all but the last patch into omap-for-v3.16/dt branch, it seems there's no need to separate out the fixes in this case. 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 05/17] pci: host: pcie-dra7xx: add support for pcie-dra7xx controller
On Tue, May 06, 2014 at 07:03:51PM +0530, Kishon Vijay Abraham I wrote:
+Example:
+pcie@5100 {
+ compatible = ti,dra7xx-pcie;
+ reg = 0x51002000 0x14c, 0x5100 0x2000;
+ reg-names = ti_conf, rc_dbics;
+ interrupts = 0 232 0x4, 0 233 0x4;
+ #address-cells = 3;
+ #size-cells = 2;
+ device_type = pci;
+ ti,device_type = 3;
+ ranges = 0x0800 0 0x20001000 0x20001000 0 0x2000 /*
Configuration Space */
Configuration space should not show up in the ranges, please don't
copy that mistake from other drivers, put it in reg.
+ interrupt-map-mask = 0 0 0 0;
+ interrupt-map = 0x0 0 gic 134;
The HW cannot decode INTA/B/C/D?
+#define PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI 0x0034
+#define PCIECTRL_DRA7XX_CONF_IRQENABLE_SET_MSI 0x0038
+#define INTABIT(0)
+#define INTBBIT(1)
+#define INTCBIT(2)
+#define INTDBIT(3)
+#define MSI BIT(4)
+#define LEG_EP_INTERRUPTS (INTA | INTB | INTC | INTD)
Oh, it can, it would be wise to export this from the driver. Look at
the latest patches from Srikanth Thokala for the Xilinx PCI driver to
see how this should look
+static int dra7xx_pcie_establish_link(struct pcie_port *pp)
+{
+ u32 reg;
+ int retries = 1000;
+ struct dra7xx_pcie *dra7xx = to_dra7xx_pcie(pp);
+
+ if (dw_pcie_link_up(pp)) {
+ dev_err(pp-dev, link is already up\n);
+ return 0;
+ }
+
+ reg = dra7xx_pcie_readl(dra7xx-base, PCIECTRL_DRA7XX_CONF_DEVICE_CMD);
+ reg |= LTSSM_EN;
+ dra7xx_pcie_writel(dra7xx-base, PCIECTRL_DRA7XX_CONF_DEVICE_CMD, reg);
+
+ while (--retries) {
+ reg = dra7xx_pcie_readl(dra7xx-base,
+ PCIECTRL_DRA7XX_CONF_PHY_CS);
+ if (reg LINK_UP)
+ break;
+ usleep_range(10, 20);
+ }
+
+ if (retries = 0) {
+ dev_err(pp-dev, link is not up\n);
+ return -ETIMEDOUT;
+ }
+
+ return 0;
+}
It would be really nice to see the link bring up process live in the
PCI core, every driver seems to have its own take on this.
The PCI-E spec requires a 100ms delay after link bring up (aka hot
reset) before sending any configuration TLPs.
Jason
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] ARM: dts: am335x-bone-common: use phandles for USB and DMA refs
* Felipe Balbi ba...@ti.com [140506 09:19]: On Mon, Apr 28, 2014 at 05:54:32PM -0300, Guido Martínez wrote: Use phandles instead of unit adresses to reference usb and dma nodes. This makes the DT more robust and readable. Signed-off-by: Guido Martínez gu...@vanguardiasur.com.ar (acked wrong version previously, sorry) Acked-by: Felipe Balbi ba...@ti.com Applying all four from the v2 into omap-for-v3.16/dt thanks. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] ARM: dts: AM43xx: Touchscreen support
* Roger Quadros rog...@ti.com [140430 05:43]: Hi Benoit Tony, These patches add I2C touch screen support for am43x-epos-evm and am437x-gp-evm. Relevant driver side changes are here. http://thread.gmane.org/gmane.linux.kernel.input/35803 Please queue this for -next (3.16). Thanks. Applying both into omap-for-v3.16/dt thanks. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Add VTT regulators for DDR3 AMx3xx Boards
* Dave Gerlach d-gerl...@ti.com [140505 12:59]: The am335x-evmsk and am437x-gp-evm both have a gpio controlled regulator for DDR3 VTT voltage. This is configured by boot loader and previously just left at that but it is better to define a fixed regulator to control the gpio so that the kernel is aware of it. Previous discussion here [1]. Original am437x-gp-evm patch has been updated to reflect actual voltage supplied by VTT regulator. Thanks applying both into omap-for-v3.16/dt. 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: [Resend/PATCH] arm: dts: dra7: Add qspi device.
* Sourav Poddar sourav.pod...@ti.com [140506 04:08]: These add device tree entry for qspi controller driver on dra7-evm. Thanks applying into omap-for-v3.16/dt. 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] DTS: ARM: OMAP3-N900: use MATRIX_KEY for keymap
* Sebastian Reichel s...@kernel.org [140506 06:15]: Use MATRIX_KEY macro from dt-bindings/input/input.h to make the keyboard matrix human readable. Thanks applying into omap-for-v3.16/dt. 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] ARM: OMAP dts: Only build dtb if associated SoC is built
* Peter Robinson pbrobin...@gmail.com [140503 17:12]: With ARCH_OMAP2PLUS being separated out into OMAP2/3/4/5 etc all the TI device tree blobs are built no matter the combination of SoCs that are enabled. This often causes a bunch of irrelevant .dts to be built on a multi platform kernel, this enables the building of just the ones relevant to the SoCs that are actually enabled. It also orders the dts file alphabetically. Sure, makes sense and grouping + sorting also helps to avoid trivial merge conflicts. I've changed the ordering a bit as am335x is based on omap3, and omap43x based on omap4. And 3517 is an omap3 with the faster Ethernet and few other changes. I'll apply the following patch into omap-for-v3.16/dt. BTW, looks like you missed a Signed-off-by in your original patch. Regards, Tony From: Peter Robinson pbrobin...@gmail.com Date: Sun, 4 May 2014 01:11:37 +0100 Subject: [PATCH] ARM: OMAP dts: Only build dtb if associated SoC is built With ARCH_OMAP2PLUS being separated out into OMAP2/3/4/5 etc all the TI device tree blobs are built no matter the combination of SoCs that are enabled. This often causes a bunch of irrelevant .dts to be built on a multi platform kernel, this enables the building of just the ones relevant to the SoCs that are actually enabled. It also orders the dts file alphabetically. This also helps to avoid trivial merge conflicts when adding support for new boards. [t...@atomide.com: updated the order for am335x and am43x, moved am3517 to omap3] Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 377b7c3..6efdd3e 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -230,65 +230,65 @@ dtb-$(CONFIG_ARCH_NOMADIK) += ste-nomadik-s8815.dtb dtb-$(CONFIG_ARCH_NSPIRE) += nspire-cx.dtb \ nspire-tp.dtb \ nspire-clp.dtb -dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \ - omap2430-sdp.dtb \ +dtb-$(CONFIG_ARCH_OMAP2) += omap2420-h4.dtb \ omap2420-n800.dtb \ omap2420-n810.dtb \ omap2420-n810-wimax.dtb \ + omap2430-sdp.dtb +dtb-$(CONFIG_ARCH_OMAP3) += am3517-craneboard.dtb \ + am3517-evm.dtb \ + am3517_mt_ventoux.dtb \ omap3430-sdp.dtb \ omap3-beagle.dtb \ + omap3-beagle-xm.dtb \ + omap3-beagle-xm-ab.dtb \ omap3-cm-t3517.dtb \ - omap3-sbc-t3517.dtb \ omap3-cm-t3530.dtb \ - omap3-sbc-t3530.dtb \ omap3-cm-t3730.dtb \ - omap3-sbc-t3730.dtb \ omap3-devkit8000.dtb \ - omap3-beagle-xm.dtb \ - omap3-beagle-xm-ab.dtb \ omap3-evm.dtb \ omap3-evm-37xx.dtb \ + omap3-gta04.dtb \ + omap3-igep0020.dtb \ + omap3-igep0030.dtb \ omap3-ldp.dtb \ + omap3-lilly-dbb056.dtb \ omap3-n900.dtb \ omap3-n9.dtb \ omap3-n950.dtb \ omap3-overo-alto35.dtb \ - omap3-overo-storm-alto35.dtb \ omap3-overo-chestnut43.dtb \ - omap3-overo-storm-chestnut43.dtb \ omap3-overo-gallop43.dtb \ - omap3-overo-storm-gallop43.dtb \ omap3-overo-palo43.dtb \ + omap3-overo-storm-alto35.dtb \ + omap3-overo-storm-chestnut43.dtb \ + omap3-overo-storm-gallop43.dtb \ omap3-overo-storm-palo43.dtb \ - omap3-overo-summit.dtb \ omap3-overo-storm-summit.dtb \ - omap3-overo-tobi.dtb \ omap3-overo-storm-tobi.dtb \ - omap3-gta04.dtb \ - omap3-igep0020.dtb \ - omap3-igep0030.dtb \ - omap3-lilly-dbb056.dtb \ - omap3-zoom3.dtb \ - omap4-duovero-parlor.dtb \ + omap3-overo-summit.dtb \ + omap3-overo-tobi.dtb \ + omap3-sbc-t3517.dtb \ + omap3-sbc-t3530.dtb \ + omap3-sbc-t3730.dtb \ + omap3-zoom3.dtb +dtb-$(CONFIG_SOC_AM33XX) += am335x-base0033.dtb \ + am335x-bone.dtb \ + am335x-boneblack.dtb \ + am335x-evm.dtb \ + am335x-evmsk.dtb \ + am335x-nano.dtb +dtb-$(CONFIG_ARCH_OMAP4) += omap4-duovero-parlor.dtb \ omap4-panda.dtb \ omap4-panda-a4.dtb \ omap4-panda-es.dtb \ - omap4-var-som.dtb \ omap4-sdp.dtb \ omap4-sdp-es23plus.dtb \ - omap5-uevm.dtb \ - am335x-evm.dtb \ - am335x-evmsk.dtb \ - am335x-bone.dtb \ - am335x-boneblack.dtb \ - am335x-nano.dtb \ - am335x-base0033.dtb \ - am3517-craneboard.dtb \ - am3517-evm.dtb \ - am3517_mt_ventoux.dtb \ - am43x-epos-evm.dtb \ - am437x-gp-evm.dtb \ - dra7-evm.dtb + omap4-var-som.dtb +dtb-$(CONFIG_SOC_AM43XX) += am43x-epos-evm.dtb \ + am437x-gp-evm.dtb +dtb-$(CONFIG_SOC_OMAP5) += omap5-uevm.dtb +dtb-$(CONFIG_SOC_DRA7XX) += dra7-evm.dtb dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-ethernet-disk-mini-v2.dtb dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb dtb-$(CONFIG_ARCH_QCOM) += qcom-msm8660-surf.dtb \ -- To unsubscribe from this list: send the line
Re: [PATCH v2 0/4] Support for Variscite OM44 modules and boards
1On 6 May 2014 02:15, Tony Lindgren t...@atomide.com wrote: * Joachim Eastwood manab...@gmail.com [140501 12:08]: Hello, This patch set adds support for Variscite OM44 series of system on modules and boards. There weren't many comments on v1 of this patch set so I hope this can make it into 3.16. Changes since v2: * Use OMAP IOPAD macros Patch 1: Add support for the SoM itself and the reference carrier board. Together these make the VAR-STK-OM44 dev kit. Patch 2: Add support for VAR-DVK-OM44 which is just the STK with a LCD display. Patch 3: Nodes for WLAN/BT support. Patch 4: Add quirks so that WLAN can be used. Still waiting for proper DT bindings. Since this patch set now uses the IOPAD macros a fix from Tony is need. See: https://patchwork.kernel.org/patch/4025421/ Just noted that the macro won't work while was about to apply these, sorry. So we're back to either using the existing OMAP4_WKUP_IOPAD or raw offset from the padconf area unless you have some great macro ideas. I see. I'll take another look at the macro's and see what I can come up with. Note that patch 1 relies upon a patch from Tomi Valkeinen add hpd-gpio (hotplug detect) to the hdmi-connector. See: http://marc.info/?l=linux-omapm=139771947508021w=2 Patch 2 also relies upon a patch from Tomi that adds DT support to panel-dpi. See: http://marc.info/?l=devicetreem=139030201815380w=2 Maybe also leave out the DSS changes until Tomi has confirmed those? I can split the patch set and put a patch with the DSS DT nodes at the end. Maybe this last patch can go through Tomi if he has a DSS DT branch. I don't want to drop it entirely from the patch set because some other people has expressed interest in testing it with full display and hdmi support. I am traveling right now and don't have access to my development machine. So I won't be able to rework the patch set until early next week. regards Joachim Eastwood -- 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
dss_pwrdm core_pwrdm not entering sleep state correctly on am37xx
Hi, I'm trying to backport a display driver for an RFBI panel to 2.6.32, but the dss_pwrdm is complaining about not entering target state: root@02AA01AB381207S7# cat /sys/kernel/debug/pm_debug/count | grep dss dss_pwrdm (ON),OFF:0,RET:11,INA:0,ON:12 dss_clkdm-dss_pwrdm (0) root@02AA01AB381207S7# echo -n mem /sys/power/state PM: Syncing filesystems ... done. PM: Preparing system for mem sleep Freezing user space processes ... (elapsed 0.02 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.04 seconds) done. PM: Entering mem sleep spidev spi2.0: ... can't suspend WLAN: Suspend call WLAN_firmware Suspend Wake locks are active (count: 0) Shutting Down IF Clock Interface Powerdomain (core_pwrdm) didn't enter target state 0 Powerdomain (dss_pwrdm) didn't enter target state 0 Could not enter target state in pm_suspend snip #no change after attempted suspend. root@02AA01AB381207S7# cat /sys/kernel/debug/pm_debug/count | grep dss dss_pwrdm (ON),OFF:0,RET:11,INA:0,ON:12 dss_clkdm-dss_pwrdm (0) I was worried it might be the dss clocks not being disabled, but I instrumented dss_clk_(en|dis)able to print clock counts and it goes to 0 before suspending. I don't really understand what will prevent the dss power domain from entering retain state or not, so any pointers would be useful. I'm less worried about the core_pwrdm error because that isn't a regression from the old panel, and power numbers are low enough without it, but any tips there would be great as well. Thanks -Andrew -- 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 V5 1/3] arm: dts: dra7: Add crossbar device binding
On Tue, May 06, 2014 at 07:26:17PM +0530, Sricharan R wrote:
This adds the irq crossbar device node.
There is a IRQ crossbar device in the soc, which
maps the irq requests from the peripherals to the
mpu interrupt controller's inputs. The Peripheral irq
requests are connected to only one crossbar
input and the output of the crossbar is connected to only one
controller's input line. The crossbar device is used to map
a peripheral input to a free mpu's interrupt controller line.
Cc: Benoit Cousson bcous...@baylibre.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
[V5] Rebased on top of 3.15-rc4 and corrected the
irqs-reserved list
arch/arm/boot/dts/dra7.dtsi |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 149b550..0274a86 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -790,6 +790,14 @@
status = disabled;
};
};
+
+ crossbar_mpu: crossbar@4a02 {
shouldn't this be status = disabled; so that boards enable this
on-demand ??
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH V5 1/3] arm: dts: dra7: Add crossbar device binding
On 05/06/2014 02:40 PM, Felipe Balbi wrote:
On Tue, May 06, 2014 at 07:26:17PM +0530, Sricharan R wrote:
This adds the irq crossbar device node.
There is a IRQ crossbar device in the soc, which
maps the irq requests from the peripherals to the
mpu interrupt controller's inputs. The Peripheral irq
requests are connected to only one crossbar
input and the output of the crossbar is connected to only one
controller's input line. The crossbar device is used to map
a peripheral input to a free mpu's interrupt controller line.
Cc: Benoit Cousson bcous...@baylibre.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
[V5] Rebased on top of 3.15-rc4 and corrected the
irqs-reserved list
arch/arm/boot/dts/dra7.dtsi |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 149b550..0274a86 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -790,6 +790,14 @@
status = disabled;
};
};
+
+crossbar_mpu: crossbar@4a02 {
shouldn't this be status = disabled; so that boards enable this
on-demand ??
It cannot be and does not need to be. crossbar is an SoC feature. by
defining crossbar, the IRQ numbers we provide in DTS now becomes
crossbar numbers which get mapped to GIC interrupt numbers dynamically.
further crossbar is not a board feature. it is as ingrained in DRA7
behavior as GIC is. we are fortunate that we have some default mapping
of crossbar that allows the current peripherals to work, with this
support, we dont have to depend any longer on we are lucky that is
mapped.
That said, in hindsight, patch #1 and 2 should be squashed IMHO. else
we have a bisectability problem here.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dss_pwrdm core_pwrdm not entering sleep state correctly on am37xx
* Andrew LeCain alec...@google.com [140506 12:10]: Hi, I'm trying to backport a display driver for an RFBI panel to 2.6.32, but the dss_pwrdm is complaining about not entering target state: Backport from which kernel? The RFBI got removed recently because of the move of the panels. Probably should get patched back in once it's working again, so at least I would like to see this get fixed properly in the mainline kernel if you have patches somewhere. root@02AA01AB381207S7# cat /sys/kernel/debug/pm_debug/count | grep dss dss_pwrdm (ON),OFF:0,RET:11,INA:0,ON:12 dss_clkdm-dss_pwrdm (0) root@02AA01AB381207S7# echo -n mem /sys/power/state PM: Syncing filesystems ... done. PM: Preparing system for mem sleep Freezing user space processes ... (elapsed 0.02 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.04 seconds) done. PM: Entering mem sleep spidev spi2.0: ... can't suspend WLAN: Suspend call WLAN_firmware Suspend Wake locks are active (count: 0) Shutting Down IF Clock Interface Powerdomain (core_pwrdm) didn't enter target state 0 Powerdomain (dss_pwrdm) didn't enter target state 0 Could not enter target state in pm_suspend snip #no change after attempted suspend. root@02AA01AB381207S7# cat /sys/kernel/debug/pm_debug/count | grep dss dss_pwrdm (ON),OFF:0,RET:11,INA:0,ON:12 dss_clkdm-dss_pwrdm (0) I was worried it might be the dss clocks not being disabled, but I instrumented dss_clk_(en|dis)able to print clock counts and it goes to 0 before suspending. I don't really understand what will prevent the dss power domain from entering retain state or not, so any pointers would be useful. Maybe dump out the autoidle registers like CM_IDLEST_PER and CM_IDLEST*_CORE and that should show you what's still blocking idle transitions. I'm less worried about the core_pwrdm error because that isn't a regression from the old panel, and power numbers are low enough without it, but any tips there would be great as well. 2.6.32 is getting pretty old.. We do have pending patches to have mainline kernel hit core off for omap3 with twl4030 cutting off vdd_core. I did not yet test with a display as the panels have been still pending for device tree based booting. These should allow you to quite easily to test against v3.14-rc4: [PATCH 00/11] Fixes for omap PM for making omap3 DT only BTW, if your SoC is 3703 then you need to also idle IVA2: 2d403f7b1981 (ARM: OMAP3: Fix iva2_pwrdm settings for 3703) 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 V5 1/3] arm: dts: dra7: Add crossbar device binding
Nishanth Menon n...@ti.com wrote on Tue [2014-May-06 14:46:10 -0500]:
On 05/06/2014 02:40 PM, Felipe Balbi wrote:
On Tue, May 06, 2014 at 07:26:17PM +0530, Sricharan R wrote:
This adds the irq crossbar device node.
There is a IRQ crossbar device in the soc, which
maps the irq requests from the peripherals to the
mpu interrupt controller's inputs. The Peripheral irq
requests are connected to only one crossbar
input and the output of the crossbar is connected to only one
controller's input line. The crossbar device is used to map
a peripheral input to a free mpu's interrupt controller line.
Cc: Benoit Cousson bcous...@baylibre.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
[V5] Rebased on top of 3.15-rc4 and corrected the
irqs-reserved list
arch/arm/boot/dts/dra7.dtsi |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 149b550..0274a86 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -790,6 +790,14 @@
status = disabled;
};
};
+
+ crossbar_mpu: crossbar@4a02 {
shouldn't this be status = disabled; so that boards enable this
on-demand ??
It cannot be and does not need to be. crossbar is an SoC feature. by
defining crossbar, the IRQ numbers we provide in DTS now becomes
crossbar numbers which get mapped to GIC interrupt numbers dynamically.
further crossbar is not a board feature. it is as ingrained in DRA7
behavior as GIC is. we are fortunate that we have some default mapping
of crossbar that allows the current peripherals to work, with this
support, we dont have to depend any longer on we are lucky that is
mapped.
That said, in hindsight, patch #1 and 2 should be squashed IMHO. else
we have a bisectability problem here.
Yes the bisectability problem is completely true - I was just testing
that as your email came in. In fact I think all three patches need to
be squashed into one, I can't boot the dra7-EVM unless I have all three
patches applied.
With all three patches applied, basic boot is looking good. I will
reply with my tested-by once I have got VIP, etc up and running.
Darren
--
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 V5 1/3] arm: dts: dra7: Add crossbar device binding
Darren Etheridge detheri...@ti.com wrote on Tue [2014-May-06 14:58:04 -0500]:
Nishanth Menon n...@ti.com wrote on Tue [2014-May-06 14:46:10 -0500]:
On 05/06/2014 02:40 PM, Felipe Balbi wrote:
On Tue, May 06, 2014 at 07:26:17PM +0530, Sricharan R wrote:
This adds the irq crossbar device node.
There is a IRQ crossbar device in the soc, which
maps the irq requests from the peripherals to the
mpu interrupt controller's inputs. The Peripheral irq
requests are connected to only one crossbar
input and the output of the crossbar is connected to only one
controller's input line. The crossbar device is used to map
a peripheral input to a free mpu's interrupt controller line.
Cc: Benoit Cousson bcous...@baylibre.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
[V5] Rebased on top of 3.15-rc4 and corrected the
irqs-reserved list
arch/arm/boot/dts/dra7.dtsi |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 149b550..0274a86 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -790,6 +790,14 @@
status = disabled;
};
};
+
+crossbar_mpu: crossbar@4a02 {
shouldn't this be status = disabled; so that boards enable this
on-demand ??
It cannot be and does not need to be. crossbar is an SoC feature. by
defining crossbar, the IRQ numbers we provide in DTS now becomes
crossbar numbers which get mapped to GIC interrupt numbers dynamically.
further crossbar is not a board feature. it is as ingrained in DRA7
behavior as GIC is. we are fortunate that we have some default mapping
of crossbar that allows the current peripherals to work, with this
support, we dont have to depend any longer on we are lucky that is
mapped.
That said, in hindsight, patch #1 and 2 should be squashed IMHO. else
we have a bisectability problem here.
Yes the bisectability problem is completely true - I was just testing
that as your email came in. In fact I think all three patches need to
be squashed into one, I can't boot the dra7-EVM unless I have all three
patches applied.
Or I just tried reordering, so patch 3/3 becomes patch 1 and then squash
patch 1/3 and patch 2/3 together to form patch 2. That seems to at
least let the kernel boot to completion.
Darren
--
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 V5 0/3] arm: dts: dra7: Updates for adding crossbar device
Sricharan R r.sricha...@ti.com wrote on Tue [2014-May-06 19:26:16 +0530]: Some socs have a large number of interrupts requests to service the needs of its many peripherals and subsystems. All of the interrupt requests lines from the subsystems are not needed at the same time, so they have to be muxed to the controllers appropriately. In such places a interrupt controllers are preceded by an IRQ CROSSBAR that provides flexibility in muxing the device interrupt requests to the controller inputs. The dts file update to support the crossbar device and convert peripheral irq numbers to crossbar number are added here. This is a rebase of V4 series on top of 3.15-rc4 This series depends on crossbar-driver-fixes sent below http://marc.info/?l=linux-omapm=139929963420299w=2 Sricharan R (3): arm: dts: dra7: Add crossbar device binding arm: dts: dra7: Replace peripheral interrupt numbers with crossbar inputs arm: dts: dra7: Add routable-irqs property for gic node OK, assuming the bisectability issues discussed earlier on this thread are addressed. I have tested the earlier crossbar patch series in conjunction with this dts series with VIP capture and DSS display running together on DRA7. Looks good with this combination of devices. VIP is one of the modules that must have a crossbar mapping as there is no default interrupt mapping for it, therefore VIP makes a good test case. So please feel free to add: Tested-by: Darren Etheridge detheri...@ti.com arch/arm/boot/dts/dra7.dtsi | 109 +-- 1 file changed, 63 insertions(+), 46 deletions(-) -- 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 -- 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] power: twl4030_charger: clear IRQs after handling them
On 16:00-20140425, Felipe Balbi wrote: On Fri, Apr 25, 2014 at 03:58:10PM -0500, Nishanth Menon wrote: On 04/16/2014 11:35 AM, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [140416 08:18]: TRM says we *must* write 1 to each bit we're handling in order to clear the IRQ status and bring IRQ line low. This patch implements that. Signed-off-by: Felipe Balbi ba...@ti.com --- Russell, I don't have HW to test, but this should solve the problem you saw when not using battery with Zoom board. Let me know if it doesn't. BTW, looks like we're enabling BCI automatically in twl4030.dtsi while the legacy booting does not have TWL_COMMON_PDATA_BCI enabled for LDP. Anyways, for LDP BCI should be enabled for sure, that's the only way to power at least the earlier LDP revisions. I picked up https://patchwork.kernel.org/patch/4002371/ for testing. Unfortunately, it does not seem to work in my tests: alright, I'll have a look after I get this other issue out of the way. Probably not until next week. I dug a bit more into this earlier today. It makes a little sense considering that TWL4030 was created in a world where mobile devices did not consider battery was hot pluggable entity.. Long story short: a) the BCI interrupt status register is read-on-clear (see drivers/mfd/twl4030-irq.c set_cor is set to true for bci) - so the patch https://patchwork.kernel.org/patch/4002371/ is practically a NOP. b) BATSTS is a result of MADC monitoring the thermistor and is continually generated. I tried a bunch of tricks that I could come up with to try to do a hotplug support, but either we have infinite interrupts (due to regeneration of event) or I loose detection ability. So, to keep things simple I created the following patch that seems to handle: a) no battery connected, powered off charger - bci disabled b) battery connected, powered off charger - bci active c) battery connected, no charger - bci active note: if battery was connected, and booted and we hotplug battery out, we still have the spam of messages.. that is a seperate patch (basically do an orderly shutdown - I cant think of anything else we could possible do there) Let me know your views.. if this approach is fine, I can post out formal patches for the same. -8 From 9474c7f37990b97c57b72eed917b9153595133ff Mon Sep 17 00:00:00 2001 From: Nishanth Menon n...@ti.com Date: Tue, 6 May 2014 19:02:49 -0500 Subject: [PATCH] power: twl4030_charger: detect battery presence prior to enabling charger TWL4030's Battery Charger seems to be designed for non-hotpluggable batteries. If battery is not present in the system, BATSTS is always set with the expectation that software will take actions to move to a required safe state (could be power down or disable various charger paths). It does not seem possible even by manipulating the edge detection of the event (using BCIEDR2 register) to have a consistent hotplug handling. This seems to be the result of BATSTS interrupt generated when the thermistor of the battery pack is disconnected from the dedicated ADIN1 pin. Clearing the status just results in the status being regenerated by the monitoring ADC(MADC) and disabling the edges of event just makes hotplug no longer function. The only other option is to disable the detection of the MADC by disabling BCIMFEN4::BATSTSMCHGEN (battery presence detector) - but then, we can never again detect battery reconnection. So, detect battery presence based on precharge(which is hardware automatic state) or default main charger configuration at the time of probe and enable charger logic only if battery was present. Reported-by: Russell King li...@arm.linux.org.uk Signed-off-by: Nishanth Menon n...@ti.com --- drivers/power/twl4030_charger.c | 43 ++- 1 file changed, 42 insertions(+), 1 deletion(-) diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c index f141088..14ec220 100644 --- a/drivers/power/twl4030_charger.c +++ b/drivers/power/twl4030_charger.c @@ -28,10 +28,13 @@ #define TWL4030_BCIICHG0x08 #define TWL4030_BCIVAC 0x0a #define TWL4030_BCIVBUS0x0c +#define TWL4030_BCIMFSTS3 0x0F #define TWL4030_BCIMFSTS4 0x10 #define TWL4030_BCICTL10x23 #define TWL4030_BB_CFG 0x12 +#define TWL4030_BCIMFSTS1 0x01 + #define TWL4030_BCIAUTOWEN BIT(5) #define TWL4030_CONFIG_DONEBIT(4) #define TWL4030_BCIAUTOUSB BIT(1) @@ -52,6 +55,9 @@ #define TWL4030_BBISEL_500uA 0x02 #define TWL4030_BBISEL_1000uA 0x03 +#define TWL4030_BATSTSPCHG BIT(2) +#define TWL4030_BATSTSMCHG BIT(6) + /* BCI interrupts */ #define TWL4030_WOVF BIT(0) /* Watchdog overflow */ #define TWL4030_TMOVF BIT(1) /* Timer overflow */ @@ -145,6 +151,34 @@ static int twl4030bci_read_adc_val(u8 reg) } /* + * Check if Battery Pack was present + */ +static int
Re: [PATCH 07/16] i2c: omap: remove unnecessary OOM messages
On Wed, May 07, 2014 at 01:24:23PM +0900, Jingoo Han wrote:
The site-specific OOM messages are unnecessary, because they
duplicate the MM subsystem generic OOM message.
Signed-off-by: Jingoo Han jg1@samsung.com
Acked-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 85f8eac..b182793 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1114,10 +1114,8 @@ omap_i2c_probe(struct platform_device *pdev)
}
dev = devm_kzalloc(pdev-dev, sizeof(struct omap_i2c_dev), GFP_KERNEL);
- if (!dev) {
- dev_err(pdev-dev, Menory allocation failed\n);
+ if (!dev)
return -ENOMEM;
- }
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
dev-base = devm_ioremap_resource(pdev-dev, mem);
--
1.7.10.4
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v4 5/5] ARM: DRA7: Add support for soc_is_dra74x() and soc_is_dra72x() varients
On Tuesday 06 May 2014 09:58 PM, Tony Lindgren wrote: * Rajendra Nayak rna...@ti.com [140429 04:22]: On Tuesday 29 April 2014 04:48 PM, Arnd Bergmann wrote: On Tuesday 29 April 2014 16:35:13 Rajendra Nayak wrote: @@ -393,7 +395,12 @@ IS_OMAP_TYPE(3430, 0x3430) #if defined(CONFIG_SOC_DRA7XX) #undef soc_is_dra7xx +#undef soc_is_dra74x +#undef soc_is_dra72x #define soc_is_dra7xx()(of_machine_is_compatible(ti,dra7)) +#define soc_is_dra74x()(of_machine_is_compatible(ti,dra74)) +#define soc_is_dra72x()(of_machine_is_compatible(ti,dra72)) + You shouldn't normally have to define these. Why are they needed? Maybe it's better to wait for a user to show up, and then we can decide whether we actually want to have them this way, or if there is a better solution for the particular use case. Normally, we'd want to make run-time decisions based on properties of the nodes a driver is working on, not the global machine compatible string. Yeah, actually this can be dropped. There is no user for it now. OK applying all but the last patch into omap-for-v3.16/dt branch, it seems there's no need to separate out the fixes in this case. Thanks Tony. 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 V5 0/3] arm: dts: dra7: Updates for adding crossbar device
On Wednesday 07 May 2014 03:15 AM, Darren Etheridge wrote: Sricharan R r.sricha...@ti.com wrote on Tue [2014-May-06 19:26:16 +0530]: Some socs have a large number of interrupts requests to service the needs of its many peripherals and subsystems. All of the interrupt requests lines from the subsystems are not needed at the same time, so they have to be muxed to the controllers appropriately. In such places a interrupt controllers are preceded by an IRQ CROSSBAR that provides flexibility in muxing the device interrupt requests to the controller inputs. The dts file update to support the crossbar device and convert peripheral irq numbers to crossbar number are added here. This is a rebase of V4 series on top of 3.15-rc4 This series depends on crossbar-driver-fixes sent below http://marc.info/?l=linux-omapm=139929963420299w=2 Sricharan R (3): arm: dts: dra7: Add crossbar device binding arm: dts: dra7: Replace peripheral interrupt numbers with crossbar inputs arm: dts: dra7: Add routable-irqs property for gic node OK, assuming the bisectability issues discussed earlier on this thread are addressed. I have tested the earlier crossbar patch series in conjunction with this dts series with VIP capture and DSS display running together on DRA7. Looks good with this combination of devices. VIP is one of the modules that must have a crossbar mapping as there is no default interrupt mapping for it, therefore VIP makes a good test case. So please feel free to add: Tested-by: Darren Etheridge detheri...@ti.com Thanks for the testing. Will reorder and repost. Regards, Sricharan -- 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
