Re: [PATCH v3 4/7] ARM: dts: omap3-overo: Add HSUSB PHY
On 03/03/2014 02:07 PM, Roger Quadros wrote:
On 03/03/2014 02:48 PM, Florian Vaussard wrote:
Hi Roger,
On 03/03/2014 12:03 PM, Roger Quadros wrote:
Hi Florian,
On 03/03/2014 11:34 AM, Florian Vaussard wrote:
Add the High-Speed USB PHY.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/boot/dts/omap3-overo-storm-tobi.dts | 16 ++
arch/arm/boot/dts/omap3-overo-tobi.dts | 16 ++
arch/arm/boot/dts/omap3-overo.dtsi | 44
3 files changed, 76 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-overo-storm-tobi.dts
b/arch/arm/boot/dts/omap3-overo-storm-tobi.dts
index 2033b52..eb93e3a 100644
--- a/arch/arm/boot/dts/omap3-overo-storm-tobi.dts
+++ b/arch/arm/boot/dts/omap3-overo-storm-tobi.dts
@@ -21,6 +21,22 @@
};
omap3_pmx_core2 {
+ pinctrl-names = default;
+ pinctrl-0 =
+ hsusb2_2_pins
+ ;
+
+ hsusb2_2_pins: pinmux_hsusb2_2_pins {
+ pinctrl-single,pins =
+ OMAP3630_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3)
/* etk_d10.hsusb2_clk */
+ OMAP3630_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3)
/* etk_d11.hsusb2_stp */
+ OMAP3630_CORE2_IOPAD(0x25f4, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d12.hsusb2_dir */
+ OMAP3630_CORE2_IOPAD(0x25f6, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d13.hsusb2_nxt */
+ OMAP3630_CORE2_IOPAD(0x25f8, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d14.hsusb2_data0 */
+ OMAP3630_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d15.hsusb2_data1 */
+ ;
+ };
+
w3cbw003c_2_pins: pinmux_w3cbw003c_2_pins {
pinctrl-single,pins =
OMAP3630_CORE2_IOPAD(0x25e0, PIN_OUTPUT | MUX_MODE4)
/* etk_d2.gpio_16 */
diff --git a/arch/arm/boot/dts/omap3-overo-tobi.dts
b/arch/arm/boot/dts/omap3-overo-tobi.dts
index 21de31d..e77be26 100644
--- a/arch/arm/boot/dts/omap3-overo-tobi.dts
+++ b/arch/arm/boot/dts/omap3-overo-tobi.dts
@@ -21,6 +21,22 @@
};
omap3_pmx_core2 {
+ pinctrl-names = default;
+ pinctrl-0 =
+ hsusb2_2_pins
+ ;
+
+ hsusb2_2_pins: pinmux_hsusb2_2_pins {
+ pinctrl-single,pins =
+ OMAP3430_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3)
/* etk_d10.hsusb2_clk */
+ OMAP3430_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3)
/* etk_d11.hsusb2_stp */
+ OMAP3430_CORE2_IOPAD(0x25f4, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d12.hsusb2_dir */
+ OMAP3430_CORE2_IOPAD(0x25f6, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d13.hsusb2_nxt */
+ OMAP3430_CORE2_IOPAD(0x25f8, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d14.hsusb2_data0 */
+ OMAP3430_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d15.hsusb2_data1 */
+ ;
+ };
+
w3cbw003c_2_pins: pinmux_w3cbw003c_2_pins {
pinctrl-single,pins =
OMAP3430_CORE2_IOPAD(0x25e0, PIN_OUTPUT | MUX_MODE4)
/* etk_d2.gpio_16 */
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi
b/arch/arm/boot/dts/omap3-overo.dtsi
index 07467cc..8f810db 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -30,6 +30,24 @@
ti,codec = twl_audio;
};
+ /* HS USB Port 2 Power */
+ hsusb2_power: hsusb2_power_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb2_vbus;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = gpio6 8 0;/* gpio_168:
vbus enable */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
+
+ /* HS USB Host PHY on PORT 2 */
+ hsusb2_phy: hsusb2_phy {
+ compatible = usb-nop-xceiv;
+ reset-gpios = gpio6 23 GPIO_ACTIVE_LOW; /* gpio_183 */
+ vcc-supply = hsusb2_power;
+ };
+
/* Regulator to trigger the nPoweron signal of the Wifi module */
w3cbw003c_npoweron: regulator-w3cbw003c-npoweron {
compatible = regulator-fixed;
@@ -64,6 +82,11 @@
};
omap3_pmx_core {
+ pinctrl-names = default;
+ pinctrl-0 =
+ hsusb2_pins
+ ;
+
uart3_pins: pinmux_uart3_pins {
pinctrl-single,pins =
OMAP3_CORE1_IOPAD(0x219e, PIN_INPUT |
PIN_OFF_WAKEUPENABLE | MUX_MODE0) /* uart3_rx_irrx.uart3_rx_irrx */
@@ -107,6 +130,19 @@
OMAP3_CORE1_IOPAD(0x219c, PIN_OUTPUT | MUX_MODE4)
/* uart3_rts_sd.gpio_164 */
;
};
+
+ hsusb2_pins: pinmux_hsusb2_pins {
+ pinctrl-single,pins =
+ OMAP3_CORE1_IOPAD(0x21d4, PIN_INPUT_PULLDOWN |
MUX_MODE3) /* mcspi1_cs3.hsusb2_data2 */
+
Re: [PATCHv2 13/14] ARM: OMAP24xx: clock: remove legacy clock data
On 03/04/2014 11:28 PM, Tony Lindgren wrote:
* Tero Kristo t-kri...@ti.com [140304 10:58]:
On 03/04/2014 07:32 PM, Tony Lindgren wrote:
* Tero Kristo t-kri...@ti.com [140304 01:22]:
This is no longer needed as clock data is provided through DT.
Looks like there's a new error even before applying this patch in
the series as I'm now getting the following oops on n8x0. So cannot
test this patch yet.
Is this with OMAP2 only boot?
Yeah that's with omap2 only.
That explains it, as previous series was never boot tested in omap2 only
config (due to build issues.)
I just force pushed the branch with the below additional patch, can you
check if it works now?
-Tero
From b8be115c8bba8088f7b25922ed81c1d5867af974 Mon Sep 17 00:00:00 2001
From: Tero Kristo t-kri...@ti.com
Date: Wed, 5 Mar 2014 10:03:38 +0200
Subject: [PATCH 12/15] CLK: TI: gate: add composite interface clock to OMAP2
only build
Composite interface clock is needed by OMAP2, but it was only built
in for OMAP3. Fixed the conditional build flag checks for this.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
drivers/clk/ti/gate.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/ti/gate.c b/drivers/clk/ti/gate.c
index 3e2999d..474c171 100644
--- a/drivers/clk/ti/gate.c
+++ b/drivers/clk/ti/gate.c
@@ -185,7 +185,7 @@ of_ti_composite_no_wait_gate_clk_setup(struct
device_node *node)
CLK_OF_DECLARE(ti_composite_no_wait_gate_clk,
ti,composite-no-wait-gate-clock,
of_ti_composite_no_wait_gate_clk_setup);
-#ifdef CONFIG_ARCH_OMAP3
+#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
static void __init of_ti_composite_interface_clk_setup(struct
device_node *node)
{
_of_ti_composite_gate_clk_setup(node, clkhwops_iclk_wait);
--
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 v7 1/4] mmc: omap_hsmmc: Enable SDIO IRQ.
Hi, 2014-02-27 22:33 GMT+01:00 Tony Lindgren t...@atomide.com: Thanks for updating this, I finally got around to spend some time with it again. I've folded in your fixes and quirk support into my earlier patch from [0] as that had a better changelog describing the earlier work. thanks, always struggled with that And I've also now made the SDIO support to depend on properly configured wake-up irq from device tree as otherwise wake from idle states won't work properly. I've also cleaned up the the wake-up irq initialization a bit. Looks much better now. Mind that the sdio irq is level triggered. So we have to disable the IRQ in the handler otherwise we enter an infinite loop. The wake-irq is needed for omaps with wake-up path and also when doing GPIO remuxing. So the wake-up handling is pretty much the same for both cases. I added this comment to the patch, since I was puzzled that you need a wake_irq even whithout remuxing. I've kept your Signed-off-by, can you please check if the patch below works for you with the second patch I'll post shortly? Will send out another patch soon. Left your Signed-off as well, not in the sense of your agreement, but didn't dare to remove it because of your contributions. Regards, Tony [0] https://www.mail-archive.com/linux-mmc@vger.kernel.org/msg22290.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 v7 1/4] mmc: omap_hsmmc: Enable SDIO IRQ.
Hi,
2014-02-28 18:04 GMT+01:00 Balaji T K balaj...@ti.com:
On Tuesday 25 February 2014 06:07 PM, Andreas Fenkart wrote:
For now, only support SDIO interrupt if we are booted with
DT. This is because some platforms need special quirks. And
we don't want to add new legacy mux platform init code
callbacks any longer as we are moving to DT based booting
anyways.
Signed-off-by: Andreas Fenkart afenk...@gmail.com
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index a5a38cc..bd3bb0c 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
snip
@@ -1705,7 +1757,18 @@ static void omap_hsmmc_debugfs(struct mmc_host
*mmc)
#endif
#ifdef CONFIG_OF
-static u16 omap4_reg_offset = 0x100;
+struct of_data {
+ u16 offset;
+ int flags;
+};
+
Hi Andreas,
struct of_data declaration needs to be moved out of #ifdef CONFIG_OF
for !CONFIG_OF build.
should be fixed with new version
I tried testing this patch series on am335x, I see throughput in the
range of KBs. Will give another try with Tony's version.
KB sounds really bad, even with polling I have 5MBytes/s.
Could you pls paste
# cat /sys/kernel/debug/mmc0/regs
Thanks for testing.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 2/3] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x
The am335x can't detect pending cirq in PM runtime suspend.
This patch reconfigures dat1 as a GPIO before going to suspend.
SDIO interrupts are detected with the GPIO, the GPIO will only wake
the module from suspend, SDIO irq detection will still happen through the
IP block.
Idea of remuxing the pins and some minor changes by Tony Lindgren.
Signed-off-by: Andreas Fenkart afenk...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 8c8908a..8e1195e 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -55,3 +55,53 @@ Examples:
edma 25;
dma-names = tx, rx;
};
+
+[workaround for missing swakeup on am33xx]
+
+This SOC is missing the swakeup line, it will not detect SDIO irq
+while in suspend.
+
+ --
+ | PRCM |
+ --
+ ^ |
+ swakeup | | fclk
+ | v
+ ----- -
+ | card | -- CIRQ -- | hsmmc | -- IRQ -- | CPU |
+ ----- -
+
+In suspend the fclk is off and the module is disfunctional. Even
+register reads will fail. A small logic in the host will request
+fclk restore, when an external event is detected. Once the clock
+is restored, the host detects the event normally. Since am33xx
+doesn't have this line it never wakes from suspend.
+
+The workaround is to reconfigure the dat1 line as a GPIO upon
+suspend. To make this work, we need to set 1) the named pinctrl
+states default, active and idle, 2) the gpio detecting
+sdio irq in suspend and 3) compatibe section, see example below.
+The MMC driver will then toggle between active and idle during
+the runtime. If configuration is incomplete, a warning message is
+emitted falling back to polling. Mind not every application
+needs SDIO irq, e.g. MMC cards Affected chips are am335x,
+probably others
+
+
+ mmc1: mmc@48060100 {
+ compatible = ti,am33xx-hsmmc;
+ ...
+ interrupts-extended = intc 64 gpio2 28 0;
+ ...
+ pinctrl-names = default, active, idle
+ pinctrl-0 = mmc1_pins;
+ pinctrl-1 = mmc1_pins;
+ pinctrl-2 = mmc1_cirq_pin;
+ ...
+ };
+
+ mmc1_cirq_pin: pinmux_cirq_pin {
+ pinctrl-single,pins =
+ 0x0f8 0x3f /* GPIO2_28 */
+ ;
+ };
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 47206c0..16985da 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -224,6 +224,8 @@ struct omap_hsmmc_host {
#define HSMMC_SDIO_IRQ_ENABLED (1 0)/* SDIO irq enabled */
#define HSMMC_SWAKEUP_QUIRK(1 1)
struct omap_hsmmc_next next_data;
+ struct pinctrl *pinctrl;
+ struct pinctrl_state*fixed, *active, *idle;
struct omap_mmc_platform_data *pdata;
};
@@ -480,6 +482,70 @@ static void omap_hsmmc_gpio_free(struct
omap_mmc_platform_data *pdata)
gpio_free(pdata-slots[0].switch_pin);
}
+static int omap_hsmmc_pin_init(struct omap_hsmmc_host *host)
+{
+ struct pinctrl *_pinctrl;
+ int ret;
+
+ _pinctrl = devm_pinctrl_get(host-dev);
+ if (IS_ERR(_pinctrl)) {
+ /* okay, if the bootloader set it up right */
+ dev_warn(host-dev, no pinctrl handle\n);
+ return 0;
+ }
+
+ host-fixed = pinctrl_lookup_state(_pinctrl,
+ PINCTRL_STATE_DEFAULT);
+ if (IS_ERR(host-fixed)) {
+ dev_info(host-dev,
+pins are not configured from the driver\n);
+ host-fixed = NULL;
+ devm_pinctrl_put(_pinctrl);
+ return 0;
+ }
+
+ ret = pinctrl_select_state(_pinctrl, host-fixed);
+ if (ret 0) {
+ dev_warn(host-dev, fixed pinctrl state failed %d\n, ret);
+ goto err;
+ }
+
+ /* For most cases we don't have wake-ups, and exit after this */
+ host-active = pinctrl_lookup_state(_pinctrl, active);
+ if (IS_ERR(host-active)) {
+ ret = PTR_ERR(host-active);
+ host-active = NULL;
+ goto done;
+ }
+
+ host-idle = pinctrl_lookup_state(_pinctrl, PINCTRL_STATE_IDLE);
+ if (IS_ERR(host-idle)) {
+ ret = PTR_ERR(host-idle);
+ host-idle = NULL;
+ goto err;
+ }
+
+ /* Let's make sure the active and idle states work */
+ ret = pinctrl_select_state(_pinctrl, host-idle);
+ if (ret
[PATCH v8 1/3] mmc: omap_hsmmc: Enable SDIO interrupt
There have been various patches floating around for enabling
the SDIO IRQ for hsmmc, but none of them ever got merged.
Probably the reason for not merging the SDIO interrupt patches
has been the lack of wake-up path for SDIO on some omaps that
has also needed remuxing the SDIO DAT1 line to a GPIO making
the patches complex.
This patch adds the minimal SDIO IRQ support to hsmmc for
omaps that do have the wake-up path. For those omaps, the
DAT1 line need to have the wake-up enable bit set, and the
wake-up interrupt is the same as for the MMC controller.
This patch has been tested on am3730 es1.2 with mwifiex
connected to MMC3 with mwifiex waking to Ethernet traffic
from off-idle mode. Note that for omaps that do not have
the SDIO wake-up path, this patch will not work for idle
modes and further patches for remuxing DAT1 to GPIO are
needed.
Based on earlier patches [1][2] by David Vrabel
david.vra...@csr.com, Steve Sakoman st...@sakoman.com
and Andreas Fenkart afenk...@gmail.com with the SDIO IRQ
handing improved following how sdhci.c is doing it.
For now, only support SDIO interrupt if we are booted with
a separate wake-irq configued via device tree. This is
because omaps need the wake-irq for idle states, and some
omaps need special quirks. And we don't want to add new
legacy mux platform init code callbacks any longer as we
are moving to DT based booting anyways.
To use it, you need to specify the wake-irq using the
interrupts-extended property.
[1]
http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux.git;a=commitdiff_plain;h=010810d22f6f49ac03da4ba384969432e0320453
[2] http://comments.gmane.org/gmane.linux.kernel.mmc/20446
Cc: Balaji T K balaj...@ti.com
Signed-off-by: Andreas Fenkart afenk...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index f8b9c3b..47206c0 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -29,6 +29,7 @@
#include linux/timer.h
#include linux/clk.h
#include linux/of.h
+#include linux/of_irq.h
#include linux/of_gpio.h
#include linux/of_device.h
#include linux/omap-dma.h
@@ -36,6 +37,7 @@
#include linux/mmc/core.h
#include linux/mmc/mmc.h
#include linux/io.h
+#include linux/irq.h
#include linux/gpio.h
#include linux/regulator/consumer.h
#include linux/pinctrl/consumer.h
@@ -131,6 +133,7 @@ static void apply_clk_hack(struct device *dev)
#define TC_EN (1 1)
#define BWR_EN (1 4)
#define BRR_EN (1 5)
+#define CIRQ_EN(1 8)
#define ERR_EN (1 15)
#define CTO_EN (1 16)
#define CCRC_EN(1 17)
@@ -205,6 +208,8 @@ struct omap_hsmmc_host {
u32 sysctl;
u32 capa;
int irq;
+ int wake_irq;
+ int wake_irq_en;
int use_dma, dma_ch;
struct dma_chan *tx_chan;
struct dma_chan *rx_chan;
@@ -215,6 +220,9 @@ struct omap_hsmmc_host {
int reqs_blocked;
int use_reg;
int req_in_progress;
+ int flags;
+#define HSMMC_SDIO_IRQ_ENABLED (1 0)/* SDIO irq enabled */
+#define HSMMC_SWAKEUP_QUIRK(1 1)
struct omap_hsmmc_next next_data;
struct omap_mmc_platform_data *pdata;
};
@@ -495,27 +503,40 @@ static void omap_hsmmc_stop_clock(struct omap_hsmmc_host
*host)
static void omap_hsmmc_enable_irq(struct omap_hsmmc_host *host,
struct mmc_command *cmd)
{
- unsigned int irq_mask;
+ u32 irq_mask = INT_EN_MASK;
+ unsigned long flags;
if (host-use_dma)
- irq_mask = INT_EN_MASK ~(BRR_EN | BWR_EN);
- else
- irq_mask = INT_EN_MASK;
+ irq_mask = ~(BRR_EN | BWR_EN);
/* Disable timeout for erases */
if (cmd-opcode == MMC_ERASE)
irq_mask = ~DTO_EN;
+ spin_lock_irqsave(host-irq_lock, flags);
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
+
+ /* latch pending CIRQ, but don't signal MMC core */
+ if (host-flags HSMMC_SDIO_IRQ_ENABLED)
+ irq_mask |= CIRQ_EN;
OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
+ spin_unlock_irqrestore(host-irq_lock, flags);
}
static void omap_hsmmc_disable_irq(struct omap_hsmmc_host *host)
{
- OMAP_HSMMC_WRITE(host-base, ISE, 0);
- OMAP_HSMMC_WRITE(host-base, IE, 0);
+ u32 irq_mask = 0;
+ unsigned long flags;
+
+ spin_lock_irqsave(host-irq_lock, flags);
+ /* no transfer running but need to keep cirq if enabled */
+ if (host-flags HSMMC_SDIO_IRQ_ENABLED)
+ irq_mask |= CIRQ_EN;
+
[PATCH v8 0/3] mmc: omap_hsmmc: Enable SDIO IRQ.
Hi Tony, I had an infinite loop in hsmmc_disable_wake_irq. Since the SDIO irq is level triggered, I have to disable the IRQ in the handler otherwise it is called infinitely. Did some other minor changes see below. v8 - rebased on top of Tony Lindgrent...@atomide.com changes - improved changelog describing the earlier work - improved wakeup irq setup - works on am3730 es platform now - my changes on top: - compile tested with #undef CONFIG_OF - disable wake_irq in handler to prevent infinite loop - fixed typo and added comment about wake-irq v7 - rebase on 3.14.0-rc3-49726-g77e15ec - split omap_hsmmc_pin_init due to regression on omap-3730 platform v6 - rebase on Linux 3.13-rc3 - reformatting debugfs v5 - fix compile error introduced by last minute one line fix v4: - switch to interrupts-extended format - drop ti,swakeup-missing flag convert to comaptible section v3: - removed gpio_irq from platform_data v2: - incorparated changes as suggested by reviewers - simplified workaround for am335x, gpio will now only wake the module from runtime suspend, not handle the sdio irq itself Andreas Fenkart (3): mmc: omap_hsmmc: Enable SDIO interrupt mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x mmc: omap_hsmmc: Extend debugfs for SDIO IRQ, GPIO and pinmux. .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 50 +++ drivers/mmc/host/omap_hsmmc.c | 337 ++-- include/linux/platform_data/mmc-omap.h |1 + 3 files changed, 363 insertions(+), 25 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 3/3] mmc: omap_hsmmc: Extend debugfs for SDIO IRQ, GPIO and pinmux.
Add SDIO IRQ entries to debugfs entry. Note that PSTATE shows current
state of data lines, incl. SDIO IRQ pending
Signed-off-by: Andreas Fenkart afenk...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 16985da..94b2e81 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -82,6 +82,7 @@ static void apply_clk_hack(struct device *dev)
#define OMAP_HSMMC_RSP54 0x0118
#define OMAP_HSMMC_RSP76 0x011C
#define OMAP_HSMMC_DATA0x0120
+#define OMAP_HSMMC_PSTATE 0x0124
#define OMAP_HSMMC_HCTL0x0128
#define OMAP_HSMMC_SYSCTL 0x012C
#define OMAP_HSMMC_STAT0x0130
@@ -1852,14 +1853,30 @@ static int omap_hsmmc_regs_show(struct seq_file *s,
void *data)
{
struct mmc_host *mmc = s-private;
struct omap_hsmmc_host *host = mmc_priv(mmc);
+ const char *cirq_state;
+ bool suspended;
- seq_printf(s, mmc%d:\n ctx_loss:\t%d\n\nregs:\n,
- mmc-index, host-context_loss);
+ seq_printf(s, mmc%d:\n, mmc-index);
+ if (mmc-caps MMC_CAP_SDIO_IRQ)
+ cirq_state = (host-flags HSMMC_SDIO_IRQ_ENABLED) ?
+ enabled : disabled;
+ else
+ cirq_state = polling;
+ seq_printf(s, sdio irq\t%s\n, cirq_state);
- pm_runtime_get_sync(host-dev);
+ if (host-flags HSMMC_SWAKEUP_QUIRK) {
+ suspended = host-dev-power.runtime_status != RPM_ACTIVE;
+ seq_printf(s, pinmux config\t%s\n, (suspended ?
+ gpio : sdio));
+ }
+ seq_printf(s, ctx_loss:\t%d\n, host-context_loss);
+ pm_runtime_get_sync(host-dev);
+ seq_puts(s, \nregs:\n);
seq_printf(s, CON:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, CON));
+ seq_printf(s, PSTATE:\t\t0x%08x\n,
+ OMAP_HSMMC_READ(host-base, PSTATE));
seq_printf(s, HCTL:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, HCTL));
seq_printf(s, SYSCTL:\t\t0x%08x\n,
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] OMAP: OMAP3 DSS related clock patches
Hi Tero, What about the dts fixes in this series? DSS DT depends on those fixes. I'd like the dts fixes to be either merged for v3.14, or I can add them to my DSS DT series (with acks). Tomi On 13/02/14 12:03, Tomi Valkeinen wrote: Hi, I've been debugging OMAP3 related issues with DSS clocks, and I hopefully have them all fixed with this series. This fixes the problems for both non-DT boot, but also for DT boot with DSS DT support (which is not merged yet). The non-DT boot related fixes should be merged for 3.14, but I'd like the DT boot related fixes to be merged for 3.14 also, as that'll make handling the DSS DT support easier. This is based on v3.14-rc2. Tomi Tomi Valkeinen (8): clk: divider: fix rate calculation for fractional rates clk: ti/divider: fix rate calculation for fractional rates ARM: OMAP2+: clock: fix clkoutx2 with CLK_SET_RATE_PARENT ARM: dts: fix omap3 dss clock handle names ARM: dts: fix DPLL4 x2 clkouts on 3630 ARM: dts: use ti,fixed-factor-clock for dpll4_m4x2_mul_ck ARM: dts: set 'ti,set-rate-parent' for dpll4_m4 path OMAPDSS: fix rounding when calculating fclk rate arch/arm/boot/dts/omap3430es1-clocks.dtsi | 6 +-- .../omap36xx-am35xx-omap3430es2plus-clocks.dtsi| 6 +-- arch/arm/boot/dts/omap36xx-clocks.dtsi | 20 +++ arch/arm/boot/dts/omap36xx.dtsi| 2 +- arch/arm/boot/dts/omap3xxx-clocks.dtsi | 8 +-- arch/arm/mach-omap2/cclock3xxx_data.c | 2 + arch/arm/mach-omap2/dpll3xxx.c | 62 ++ drivers/clk/clk-divider.c | 10 ++-- drivers/clk/ti/divider.c | 8 +-- drivers/video/omap2/dss/dss.c | 4 +- include/linux/clk/ti.h | 4 ++ 11 files changed, 111 insertions(+), 21 deletions(-) signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/8] OMAP: OMAP3 DSS related clock patches
On 03/05/2014 10:35 AM, Tomi Valkeinen wrote: Hi Tero, What about the dts fixes in this series? DSS DT depends on those fixes. I'd like the dts fixes to be either merged for v3.14, or I can add them to my DSS DT series (with acks). Well, I am not a maintainer of any sort, so you are asking wrong person here. I am just tossing my acks around as my approval for the patches in case someone cares. :) You need to ask Benoit here (or maybe Tony.) -Tero Tomi On 13/02/14 12:03, Tomi Valkeinen wrote: Hi, I've been debugging OMAP3 related issues with DSS clocks, and I hopefully have them all fixed with this series. This fixes the problems for both non-DT boot, but also for DT boot with DSS DT support (which is not merged yet). The non-DT boot related fixes should be merged for 3.14, but I'd like the DT boot related fixes to be merged for 3.14 also, as that'll make handling the DSS DT support easier. This is based on v3.14-rc2. Tomi Tomi Valkeinen (8): clk: divider: fix rate calculation for fractional rates clk: ti/divider: fix rate calculation for fractional rates ARM: OMAP2+: clock: fix clkoutx2 with CLK_SET_RATE_PARENT ARM: dts: fix omap3 dss clock handle names ARM: dts: fix DPLL4 x2 clkouts on 3630 ARM: dts: use ti,fixed-factor-clock for dpll4_m4x2_mul_ck ARM: dts: set 'ti,set-rate-parent' for dpll4_m4 path OMAPDSS: fix rounding when calculating fclk rate arch/arm/boot/dts/omap3430es1-clocks.dtsi | 6 +-- .../omap36xx-am35xx-omap3430es2plus-clocks.dtsi| 6 +-- arch/arm/boot/dts/omap36xx-clocks.dtsi | 20 +++ arch/arm/boot/dts/omap36xx.dtsi| 2 +- arch/arm/boot/dts/omap3xxx-clocks.dtsi | 8 +-- arch/arm/mach-omap2/cclock3xxx_data.c | 2 + arch/arm/mach-omap2/dpll3xxx.c | 62 ++ drivers/clk/clk-divider.c | 10 ++-- drivers/clk/ti/divider.c | 8 +-- drivers/video/omap2/dss/dss.c | 4 +- include/linux/clk/ti.h | 4 ++ 11 files changed, 111 insertions(+), 21 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 02/12] phy: omap-control: Update DT binding information
On 03/04/2014 06:28 PM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [140304 01:17]: Hi Tony, On 03/03/2014 09:02 PM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [140303 07:10]: Move omap-control binding information to the right location. Signed-off-by: Roger Quadros rog...@ti.com --- Documentation/devicetree/bindings/phy/ti-phy.txt | 25 ++ Documentation/devicetree/bindings/usb/omap-usb.txt | 24 - 2 files changed, 25 insertions(+), 24 deletions(-) diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt b/Documentation/devicetree/bindings/phy/ti-phy.txt index 207e14c..41dc132 100644 --- a/Documentation/devicetree/bindings/phy/ti-phy.txt +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt @@ -1,5 +1,30 @@ TI PHY: DT DOCUMENTATION FOR PHYs in TI PLATFORMs +OMAP CONTROL PHY + +Required properties: + - compatible: Should be one of + ti,control-phy-otghs - if it has otghs_control mailbox register as on OMAP4. + ti,control-phy-usb2 - if it has Power down bit in control_dev_conf register +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-dra7usb2 - if it has power down register like USB2 PHY on +DRA7 platform. + ti,control-phy-am437usb2 - if it has power down register like USB2 PHY on +AM437 platform. To me it seems that you can leave out all the above. You can set these falgs flags directly in the driver based on the compatible flag. Then just initialize the .data in the driver based on the compatible flag. I'm not sure if I got you. A single platform can have different type of phys. e.g. OMAP5 has both usb2 and pipe3 PHYs, DRA7 has both pipe3 and usb2 PHYs, but this usb2 PHY is not compatible with OMAP5 one so we need a new compatible id for that. To add to the woes, the designers were creative enough to make another mutation to the USB2 PHY for AM437x, :( Oh OK, in that case the compatible flag may not be enough for configuring the various instances. What do you suggest the compatible ids should look like for these 5 types of PHY control? OTGHS(OMAP4 5) USB2 (OMAP5) PIPE3(OMAP5 DRA7) USB2x(DRA7) USB2y(AM437) I think in that case having the various instances fully configurable from device tree is OK if you prefer that. But if you wanted to use the compatible flag, then you could do something like this: I'll stick to the compatible flag. ti,control-phy-omap4-otghs(assuming same on omap4 5) ti,control-phy-omap5-usb2 ti,control-phy-omap5-pipe3(assuming same on omap5 dra7) ti,control-phy-dra7-usb2x ti,control-phy-am437-usb2y OK. The last 2 can just be ti,control-phy-dra7-usb2 ti,control-phy-am437-usb2 cheers, -roger -- 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/8] OMAP: OMAP3 DSS related clock patches
On 05/03/14 12:12, Tero Kristo wrote: On 03/05/2014 10:35 AM, Tomi Valkeinen wrote: Hi Tero, What about the dts fixes in this series? DSS DT depends on those fixes. I'd like the dts fixes to be either merged for v3.14, or I can add them to my DSS DT series (with acks). Well, I am not a maintainer of any sort, so you are asking wrong person here. I am just tossing my acks around as my approval for the patches in case someone cares. :) You need to ask Benoit here (or maybe Tony.) Ok. Benoit, Tony, can we get the dts fixes in this series to v3.14, or is it ok if I merge them via DSS DT branch for 3.15? Tomi signature.asc Description: OpenPGP digital signature
Loan Application
Loan Application at a low rate of 0.5% send your Name,Amount,Phone and country to standar...@56788.com Note: $5,000.00 USD minimum and $100,000,000 Maximum. -- 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 02/12] phy: omap-control: Update DT binding information
+ George Tony, On 03/04/2014 06:28 PM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [140304 01:17]: Hi Tony, On 03/03/2014 09:02 PM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [140303 07:10]: Move omap-control binding information to the right location. Signed-off-by: Roger Quadros rog...@ti.com --- Documentation/devicetree/bindings/phy/ti-phy.txt | 25 ++ Documentation/devicetree/bindings/usb/omap-usb.txt | 24 - 2 files changed, 25 insertions(+), 24 deletions(-) diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt b/Documentation/devicetree/bindings/phy/ti-phy.txt index 207e14c..41dc132 100644 --- a/Documentation/devicetree/bindings/phy/ti-phy.txt +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt @@ -1,5 +1,30 @@ TI PHY: DT DOCUMENTATION FOR PHYs in TI PLATFORMs +OMAP CONTROL PHY + +Required properties: + - compatible: Should be one of + ti,control-phy-otghs - if it has otghs_control mailbox register as on OMAP4. + ti,control-phy-usb2 - if it has Power down bit in control_dev_conf register +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-dra7usb2 - if it has power down register like USB2 PHY on +DRA7 platform. + ti,control-phy-am437usb2 - if it has power down register like USB2 PHY on +AM437 platform. To me it seems that you can leave out all the above. You can set these falgs flags directly in the driver based on the compatible flag. Then just initialize the .data in the driver based on the compatible flag. I'm not sure if I got you. A single platform can have different type of phys. e.g. OMAP5 has both usb2 and pipe3 PHYs, DRA7 has both pipe3 and usb2 PHYs, but this usb2 PHY is not compatible with OMAP5 one so we need a new compatible id for that. To add to the woes, the designers were creative enough to make another mutation to the USB2 PHY for AM437x, :( Oh OK, in that case the compatible flag may not be enough for configuring the various instances. What do you suggest the compatible ids should look like for these 5 types of PHY control? OTGHS(OMAP4 5) USB2 (OMAP5) PIPE3(OMAP5 DRA7) USB2x(DRA7) USB2y(AM437) I think in that case having the various instances fully configurable from device tree is OK if you prefer that. But if you wanted to use the compatible flag, then you could do something like this: ti,control-phy-omap4-otghs(assuming same on omap4 5) ti,control-phy-omap5-usb2 ti,control-phy-omap5-pipe3(assuming same on omap5 dra7) ti,control-phy-dra7-usb2x ti,control-phy-am437-usb2y ... Please note that the original bindings were added in v3.13 and I'm just moving the documentation to the right location. So I don't think we should change the bindings now. ti,control-phy-dra7usb2 and ti,control-phy-am437usb2 have no users still so we could probably change those to ti,control-phy-dra7-usb2 and ti,control-phy-am437-usb2. What do you say? cheers, -roger -- 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 6/6] arm/dts: added dt properties to adapt to the new phy framwork
Tony/Benoit,
On Monday 03 March 2014 05:08 PM, Kishon Vijay Abraham I wrote:
Added device tree bindings for dwc3, usb2 and usb3 PHYs. The documentation
of these can be found at Documentation/devicetree/bindings/phy/phy-bindings.txt
and Documentation/devicetree/bindings/phy/ti-phy.txt.
Can this patch be queued for 3.15 merge window?
Thanks
Kishon
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap5.dtsi |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index a72813a..1c68558 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -732,7 +732,8 @@
compatible = snps,dwc3;
reg = 0x4a03 0x1;
interrupts = GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH;
- usb-phy = usb2_phy, usb3_phy;
+ phys = usb2_phy, usb3_phy;
+ phy-names = usb2-phy, usb3-phy;
dr_mode = peripheral;
tx-fifo-resize;
};
@@ -749,6 +750,7 @@
compatible = ti,omap-usb2;
reg = 0x4a084000 0x7c;
ctrl-module = omap_control_usb2phy;
+ #phy-cells = 0;
};
usb3_phy: usb3phy@4a084400 {
@@ -758,6 +760,7 @@
0x4a084c00 0x40;
reg-names = phy_rx, phy_tx, pll_ctrl;
ctrl-module = omap_control_usb3phy;
+ #phy-cells = 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
Re: [PATCH v4 4/4] ARM: OMAP2+: Add pdata quirk for sys_clkout2 for omap3 DBB056
On 03/01/2014 12:37 AM, Tony Lindgren wrote:
* Christoph Fritz chf.fr...@googlemail.com [140214 06:24]:
Full device tree support for clock control, especially to set frequencies,
is not yet accomplished. Until then, configure the 24Mhz of sys_clkout2 to
feed an USB-Hub here.
Hmm would like to see Tero's comments on this, I wonder if we should
wait on this to avoid extra churn?
Well, the set I posted that adds default clock parenting / default rate
support to DT hasn't actually moved forward, so you might want to take
this in as is now if it should be rushed. The clk-enable part isn't done
currently by anything anyway. Just wondering though, should you create
some sort of driver for your usb-hub which would control these clocks?
-Tero
Regards,
Tony
Signed-off-by: Christoph Fritz chf.fr...@googlemail.com
---
arch/arm/mach-omap2/pdata-quirks.c | 37
1 file changed, 37 insertions(+)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index 435a823..e36ac3f 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -172,6 +172,43 @@ static void __init am3517_evm_legacy_init(void)
static void __init omap3_dbb056_legacy_init(void)
{
+ struct clk *clkout2;
+ struct clk *cm96fck;
+
+ /* Reparent clkout2 to 96M_FCK */
+ pr_info(%s: Late Reparent clkout2 to 96M_FCK\n, __func__);
+ clkout2 = clk_get(NULL, clkout2_src_ck);
+ if (clkout2 0) {
+ pr_err(a83x-quirk: couldn't get clkout2_src_ck\n);
+ return;
+ }
+ cm96fck = clk_get(NULL, cm_96m_fck);
+ if (cm96fck 0) {
+ pr_err(a83x-quirk: couldn't get cm_96m_fck\n);
+ return;
+ }
+ if (clk_set_parent(clkout2, cm96fck) 0) {
+ pr_err(a83x-quirk: couldn't reparent clkout2_src_ck\n);
+ return;
+ }
+
+ /* Set clkout2 to 24MHz for internal usb hub*/
+ pr_info(%s: Set clkout2 to 24MHz for internal usb hub\n, __func__);
+ clkout2 = clk_get(NULL, sys_clkout2);
+ if (clkout2 0) {
+ pr_err(%s: couldn't get sys_clkout2\n, __func__);
+ return;
+ }
+ if (clk_set_rate(clkout2, 2400) 0) {
+ pr_err(%s: couldn't set sys_clkout2 rate\n, __func__);
+ return;
+ }
+ if (clk_prepare_enable(clkout2) 0) {
+ pr_err(%s: couldn't enable sys_clkout2\n, __func__);
+ return;
+ }
+
+ /* Initialize display */
omap3_dbb056_display_init_of();
}
#endif /* CONFIG_ARCH_OMAP3 */
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] clk: dt: add support for default rate/parent
Ping. Mike, any feedback on this? -Tero On 02/13/2014 11:00 AM, Tero Kristo wrote: Hi, This set is a mix-match of new DT properties for generic and TI specific clock drivers. Basically provided for commenting purposes. The patches provide a way to configure clock parents / rates during boot through DT. default-rate : sets rate of a clock during boot, supported for any DT clock type (through generic clock driver) ti,default-parent : selects a default parent for a multiplexer clock, only supported for TI specific mux clock for now, as generic mux clock does not support DT clocks Patch #4 provided as a reference how to move the default rates / parents from kernel code to DT. Default-rate logic in patch #2 looks somewhat complicated, as the clocks need to be sorted based on their parents to avoid cases where a child clock would set its rate first, just to be overridden by its parent changing rate later and resulting in incorrect rate for the child clock. If the default-rate generic property is not going to fly, it can be moved to TI only drivers also. -Tero ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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 4/4] ARM: OMAP2+: Add pdata quirk for sys_clkout2 for omap3 DBB056
On Wed, 2014-03-05 at 15:07 +0200, Tero Kristo wrote: On 03/01/2014 12:37 AM, Tony Lindgren wrote: * Christoph Fritz chf.fr...@googlemail.com [140214 06:24]: Full device tree support for clock control, especially to set frequencies, is not yet accomplished. Until then, configure the 24Mhz of sys_clkout2 to feed an USB-Hub here. Hmm would like to see Tero's comments on this, I wonder if we should wait on this to avoid extra churn? Well, the set I posted that adds default clock parenting / default rate support to DT hasn't actually moved forward, so you might want to take this in as is now if it should be rushed. The clk-enable part isn't done currently by anything anyway. Just wondering though, should you create some sort of driver for your usb-hub which would control these clocks? The USB-Hub, a USB2512 is wired as non-configurable. Its pin 'XTAL1/CLKIN' can be connected to either a crystal or an external clock input. To economise the crystal, the clock-out of the omap is wired here. So in my view, a driver is unnecessary. Thanks -- Christoph -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: OMAP2+: fix dpll round_rate() to actually round
On 20/02/14 21:30, Paul Walmsley wrote:
On Wed, 19 Feb 2014, Paul Walmsley wrote:
On Fri, 17 Jan 2014, Tomi Valkeinen wrote:
This patch adds a simple method of rounding: during the iteration, the
code keeps track of the closest rate match. If no exact match is found,
the closest is returned.
So that's one possible rounding policy; maybe it works fine for a display
interface PLL, at least for some values of closest rate. But another
might be only allow a selection from a set of pre-determined rates
characterized by the silicon validation team. Or another rounding
function might need to select a more distant rate that minimizes jitter,
EMI, or power consumption.
Thought about this some more. Do you only need this for the DSS PLL, or
do you need it for one of the core OMAP PLLs?
If the former, then how about modifying your patch to create a separate
round_rate function that's only used for the DSS PLL that implements the
behavior that you want?
That would eliminate any risk of impacting other users on the system. And
would also allow this change to get into the codebase much faster, since
there's no need for clk API changes, etc.
How about this one:
From f5a78303411e9192899a6a681acac37f09f4cc3b Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen tomi.valkei...@ti.com
Date: Wed, 15 Jan 2014 11:45:07 +0200
Subject: [PATCH] ARM: OMAP2+: fix dpll round_rate() to actually round
omap2_dpll_round_rate() doesn't actually round the given rate, even if
the name and the description so hints. Instead it only tries to find an
exact rate match, or if that fails, return ~0 as an error.
What this basically means is that the user of the clock needs to know
what rates the dpll can support, which obviously isn't right.
This patch adds a simple method of rounding: during the iteration, the
code keeps track of the closest rate match. If no exact match is found,
the closest is returned.
However, as it is unclear whether current drivers rely on the current
behavior, the rounding functionality not enabled by default, but by
setting DPLL_USE_ROUNDED_RATE for the DPLL.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/clkt_dpll.c | 23 ++-
drivers/clk/ti/dpll.c | 3 +++
include/linux/clk/ti.h | 1 +
3 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt_dpll.c b/arch/arm/mach-omap2/clkt_dpll.c
index 2649ce445845..fed7538e1eed 100644
--- a/arch/arm/mach-omap2/clkt_dpll.c
+++ b/arch/arm/mach-omap2/clkt_dpll.c
@@ -298,6 +298,8 @@ long omap2_dpll_round_rate(struct clk_hw *hw, unsigned long
target_rate,
struct dpll_data *dd;
unsigned long ref_rate;
const char *clk_name;
+ unsigned long diff, closest_diff = ~0;
+ bool use_rounding = clk-flags DPLL_USE_ROUNDED_RATE;
if (!clk || !clk-dpll_data)
return ~0;
@@ -345,20 +347,31 @@ long omap2_dpll_round_rate(struct clk_hw *hw, unsigned
long target_rate,
pr_debug(clock: %s: m = %d: n = %d: new_rate = %lu\n,
clk_name, m, n, new_rate);
- if (target_rate == new_rate) {
+ diff = max(target_rate, new_rate) - min(target_rate, new_rate);
+
+ if ((use_rounding diff closest_diff) ||
+ (!use_rounding diff == 0)) {
+ closest_diff = diff;
+
dd-last_rounded_m = m;
dd-last_rounded_n = n;
- dd-last_rounded_rate = target_rate;
- break;
+ dd-last_rounded_rate = new_rate;
+
+ if (diff == 0)
+ break;
}
}
- if (target_rate != new_rate) {
+ if (closest_diff == ~0) {
pr_debug(clock: %s: cannot round to rate %lu\n,
clk_name, target_rate);
return ~0;
}
- return target_rate;
+ if (closest_diff 0)
+ pr_debug(clock: %s: rounded rate %lu to %lu\n,
+clk_name, target_rate, dd-last_rounded_rate);
+
+ return dd-last_rounded_rate;
}
diff --git a/drivers/clk/ti/dpll.c b/drivers/clk/ti/dpll.c
index 7e498a44f97d..c5858c46b58c 100644
--- a/drivers/clk/ti/dpll.c
+++ b/drivers/clk/ti/dpll.c
@@ -265,6 +265,9 @@ static void __init of_ti_dpll_setup(struct device_node
*node,
if (dpll_mode)
dd-modes = dpll_mode;
+ if (of_property_read_bool(node, ti,round-rate))
+ clk_hw-flags |= DPLL_USE_ROUNDED_RATE;
+
ti_clk_register_dpll(clk_hw-hw, node);
return;
diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h
index 092b64168d7f..c9ed8b6b8513 100644
--- a/include/linux/clk/ti.h
+++ b/include/linux/clk/ti.h
@@ -155,6 +155,7 @@ struct clk_hw_omap {
#define INVERT_ENABLE (1 4)/* 0 enables, 1
Re: [PATCH v5 2/6] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
On 03/05/2014 04:47 PM, Kishon Vijay Abraham I wrote:
Roger,
On Wednesday 05 March 2014 08:13 PM, Roger Quadros wrote:
Hi Kishon,
On 03/03/2014 01:38 PM, Kishon Vijay Abraham I wrote:
Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
power_on and power_off the following APIs are used phy_init(), phy_exit(),
phy_power_on() and phy_power_off().
However using the old USB phy library wont be removed till the PHYs of all
other SoC's using dwc3 core is adapted to the Generic PHY Framework.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/dwc3.txt |6 +-
drivers/usb/dwc3/core.c| 86
+---
drivers/usb/dwc3/core.h|7 ++
3 files changed, 89 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index e807635..471366d 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -6,11 +6,13 @@ Required properties:
- compatible: must be snps,dwc3
- reg : Address and length of the register set for the device
- interrupts: Interrupts used by the dwc3 controller.
+
+Optional properties:
- usb-phy : array of phandle for the PHY device. The first element
in the array is expected to be a handle to the USB2/HS PHY and
the second element is expected to be a handle to the USB3/SS PHY
-
-Optional properties:
+ - phys: from the *Generic PHY* bindings
+ - phy-names: from the *Generic PHY* bindings
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
This is usually a subnode to DWC3 glue to which it is connected.
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 225a4d6..497234a 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -61,9 +61,10 @@ void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
* dwc3_core_soft_reset - Issues core soft reset and PHY reset
* @dwc: pointer to our context structure
*/
-static void dwc3_core_soft_reset(struct dwc3 *dwc)
+static int dwc3_core_soft_reset(struct dwc3 *dwc)
{
u32reg;
+intret;
/* Before Resetting PHY, put Core in Reset */
reg = dwc3_readl(dwc-regs, DWC3_GCTL);
@@ -82,6 +83,15 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
usb_phy_init(dwc-usb2_phy);
usb_phy_init(dwc-usb3_phy);
+ret = phy_init(dwc-usb2_generic_phy);
you need to check if dwc-usb?_generic_phy is not NULL before using any of
the PHY APIs
throughout this patch.
Recently a patch to allow NULL in phy APIs was added to support optional PHYs.
commit 04c2facad8fee66c981a51852806d8923336f362
Author: Andrew Lunn and...@lunn.ch
Date: Tue Feb 4 18:33:11 2014 +0100
drivers: phy: Make NULL a valid phy reference
Oh OK, then it is fine. Thanks for the clarification.
cheers,
-roger
--
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] crypto: omap-sham: kmap SG pages before appending
On 03/05/2014 01:11 AM, Herbert Xu wrote:
On Wed, Mar 05, 2014 at 04:18:12AM +, Fernandes, Joel wrote:
On Mar 4, 2014, at 8:00 PM, Herbert Xu herb...@gondor.apana.org.au
wrote:
On Tue, Mar 04, 2014 at 12:30:54PM -0600, Joel Fernandes wrote:
HIGHMEM pages may not be mapped so we must kmap them before accessing.
This resolves a random OOPs error that was showing up during OpenSSL SHA
tests.
Signed-off-by: Joel Fernandes jo...@ti.com
Cc: Herbert Xu herb...@gondor.apana.org.au
---
v2 changes:
- don't check for HIGHMEM, kmap/kunmap do them anyway (Thanks Herbert).
drivers/crypto/omap-sham.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index e45aaaf..207eac1 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -636,11 +636,17 @@ static size_t omap_sham_append_buffer(struct
omap_sham_reqctx *ctx,
static size_t omap_sham_append_sg(struct omap_sham_reqctx *ctx)
{
size_t count;
+const u8 *vaddr;
while (ctx-sg) {
+vaddr = kmap(sg_page(ctx-sg));
Are you sure you can safely use kmap here as opposed to kmap_atomic?
Yes I made sure it is not called in interrupt context and also tested the
patch.
What about omap_sham_update = omap_sham_append_sg? As the former
can be called in softirq context what is preventing it from calling
kmap?
In my testing it wasn't called from softirq, I'm using cryptodev which is
called from openssl through ioctl, here is a traceback (sorry about wrap):
[bf8010bb] (cryptodev_ioctl+0x282/0x59c [cryptodev])
[ 220.015390] [bf8010bb] (cryptodev_ioctl+0x282/0x59c [cryptodev]) from
[c00cdaa5] (do_vfs_ioctl+0x61/0x41c)
[ 220.025909] [c00cdaa5] (do_vfs_ioctl+0x61/0x41c) from [c00cdeab]
(SyS_ioctl+0x4b/0x50)
[ 220.034602] [c00cdeab] (SyS_ioctl+0x4b/0x50) from [c000cf01]
(ret_fast_syscall+0x1/0x46)
[ 220.045254] CPU: 0 PID: 1798 Comm: openssl Tainted: G O
3.12.9-00581-g5fa084c-dirty #32
[ 220.054636] [c0012d05] (unwind_backtrace+0x1/0x9c) from [c000fa6d]
(show_stack+0x11/0x14)
[ 220.063619] [c000fa6d] (show_stack+0x11/0x14) from [c0342edb]
(dump_stack+0x4b/0x60)
[ 220.072144] [c0342edb] (dump_stack+0x4b/0x60) from [c02a1b3f]
(omap_sham_update+0x1f/0xa4)
[ 220.081214] [c02a1b3f] (omap_sham_update+0x1f/0xa4) from [bf801f67]
(cryptodev_hash_update+0x26/0x80 [cryptodev])
Could you suggest, what other place is update() called in softirq context?
I may be missing something.
Thanks,
-Joel
Cheers,
--
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 02/12] phy: omap-control: Update DT binding information
* Roger Quadros rog...@ti.com [140305 04:26]: + George Tony, On 03/04/2014 06:28 PM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [140304 01:17]: Hi Tony, On 03/03/2014 09:02 PM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [140303 07:10]: Move omap-control binding information to the right location. Signed-off-by: Roger Quadros rog...@ti.com --- Documentation/devicetree/bindings/phy/ti-phy.txt | 25 ++ Documentation/devicetree/bindings/usb/omap-usb.txt | 24 - 2 files changed, 25 insertions(+), 24 deletions(-) diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt b/Documentation/devicetree/bindings/phy/ti-phy.txt index 207e14c..41dc132 100644 --- a/Documentation/devicetree/bindings/phy/ti-phy.txt +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt @@ -1,5 +1,30 @@ TI PHY: DT DOCUMENTATION FOR PHYs in TI PLATFORMs +OMAP CONTROL PHY + +Required properties: + - compatible: Should be one of + ti,control-phy-otghs - if it has otghs_control mailbox register as on OMAP4. + ti,control-phy-usb2 - if it has Power down bit in control_dev_conf register +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-dra7usb2 - if it has power down register like USB2 PHY on +DRA7 platform. + ti,control-phy-am437usb2 - if it has power down register like USB2 PHY on +AM437 platform. To me it seems that you can leave out all the above. You can set these falgs flags directly in the driver based on the compatible flag. Then just initialize the .data in the driver based on the compatible flag. I'm not sure if I got you. A single platform can have different type of phys. e.g. OMAP5 has both usb2 and pipe3 PHYs, DRA7 has both pipe3 and usb2 PHYs, but this usb2 PHY is not compatible with OMAP5 one so we need a new compatible id for that. To add to the woes, the designers were creative enough to make another mutation to the USB2 PHY for AM437x, :( Oh OK, in that case the compatible flag may not be enough for configuring the various instances. What do you suggest the compatible ids should look like for these 5 types of PHY control? OTGHS (OMAP4 5) USB2 (OMAP5) PIPE3 (OMAP5 DRA7) USB2x (DRA7) USB2y (AM437) I think in that case having the various instances fully configurable from device tree is OK if you prefer that. But if you wanted to use the compatible flag, then you could do something like this: ti,control-phy-omap4-otghs (assuming same on omap4 5) ti,control-phy-omap5-usb2 ti,control-phy-omap5-pipe3 (assuming same on omap5 dra7) ti,control-phy-dra7-usb2x ti,control-phy-am437-usb2y ... Please note that the original bindings were added in v3.13 and I'm just moving the documentation to the right location. So I don't think we should change the bindings now. OK yeah if the bindings are established you should keep them around. ti,control-phy-dra7usb2 and ti,control-phy-am437usb2 have no users still so we could probably change those to ti,control-phy-dra7-usb2 and ti,control-phy-am437-usb2. What do you say? Makes sense to me. 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: [PATCHv2 14/14] ARM: OMAP3: clock: remove legacy clock data
* Tero Kristo t-kri...@ti.com [140304 23:35]: On 03/04/2014 07:32 PM, Tony Lindgren wrote: * Tero Kristo t-kri...@ti.com [140304 01:22]: This is no longer needed as clock data is provided through DT. And this one we cannot apply yet until omap3 is booting in device tree only mode. What is missing to achieve this? Some boards are not booting in DT mode yet or? It seems that the last missing pieces are the DSS bindings and .dts file for the pandora. At least I can't think of anything else that's missing or could not be done using pdata-quirks.c. 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 v7 1/4] mmc: omap_hsmmc: Enable SDIO IRQ.
* Andreas Fenkart afenk...@gmail.com [140305 00:30]: Hi, 2014-02-27 22:33 GMT+01:00 Tony Lindgren t...@atomide.com: Thanks for updating this, I finally got around to spend some time with it again. I've folded in your fixes and quirk support into my earlier patch from [0] as that had a better changelog describing the earlier work. thanks, always struggled with that And I've also now made the SDIO support to depend on properly configured wake-up irq from device tree as otherwise wake from idle states won't work properly. I've also cleaned up the the wake-up irq initialization a bit. Looks much better now. Mind that the sdio irq is level triggered. So we have to disable the IRQ in the handler otherwise we enter an infinite loop. Oh OK, I was trying to get rid of all the extra flags. But it seem we may still need the wake_irq enabled status bit then. The wake-irq is needed for omaps with wake-up path and also when doing GPIO remuxing. So the wake-up handling is pretty much the same for both cases. I added this comment to the patch, since I was puzzled that you need a wake_irq even whithout remuxing. Yeah we need it because omap_hsmmc is already doing runtime PM, so there's nothing stopping from shutting it down. And there's really no need to block runtime PM for it as it's working. I've kept your Signed-off-by, can you please check if the patch below works for you with the second patch I'll post shortly? Will send out another patch soon. Left your Signed-off as well, not in the sense of your agreement, but didn't dare to remove it because of your contributions. Yeah thanks will try to test it today :) Regards, Tony [0] https://www.mail-archive.com/linux-mmc@vger.kernel.org/msg22290.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: [PATCHv2 13/14] ARM: OMAP24xx: clock: remove legacy clock data
* Tero Kristo t-kri...@ti.com [140305 00:17]: On 03/04/2014 11:28 PM, Tony Lindgren wrote: * Tero Kristo t-kri...@ti.com [140304 10:58]: On 03/04/2014 07:32 PM, Tony Lindgren wrote: * Tero Kristo t-kri...@ti.com [140304 01:22]: This is no longer needed as clock data is provided through DT. Looks like there's a new error even before applying this patch in the series as I'm now getting the following oops on n8x0. So cannot test this patch yet. Is this with OMAP2 only boot? Yeah that's with omap2 only. That explains it, as previous series was never boot tested in omap2 only config (due to build issues.) I just force pushed the branch with the below additional patch, can you check if it works now? Yes seems to work with that thanks. And with the omap2 legacy clock data removed too, it boots fine on n8x0 and 2430sdp. I suggest you drop the omap3 legacy data patch from this branch as it's not omap2 related and cannot be done yet. Then try to get acks from Paul. And if there are no issues, it seems Mike could take the whole branch as it seems to merge just fine with what I have queued. So for all the patches except for the omap3 legacy data removal, feel free to add: Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] OMAP: OMAP3 DSS related clock patches
* Tomi Valkeinen tomi.valkei...@ti.com [140305 03:28]: On 05/03/14 12:12, Tero Kristo wrote: On 03/05/2014 10:35 AM, Tomi Valkeinen wrote: Hi Tero, What about the dts fixes in this series? DSS DT depends on those fixes. I'd like the dts fixes to be either merged for v3.14, or I can add them to my DSS DT series (with acks). Well, I am not a maintainer of any sort, so you are asking wrong person here. I am just tossing my acks around as my approval for the patches in case someone cares. :) You need to ask Benoit here (or maybe Tony.) Ok. Benoit, Tony, can we get the dts fixes in this series to v3.14, or is it ok if I merge them via DSS DT branch for 3.15? It's best that you take those four dts changes into your DSS branch. They don't seem to conflict with anything I have queued, so: Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/4] ARM: OMAP2+: Add pdata quirk for sys_clkout2 for omap3 DBB056
* Christoph Fritz chf.fr...@googlemail.com [140305 05:28]: On Wed, 2014-03-05 at 15:07 +0200, Tero Kristo wrote: On 03/01/2014 12:37 AM, Tony Lindgren wrote: * Christoph Fritz chf.fr...@googlemail.com [140214 06:24]: Full device tree support for clock control, especially to set frequencies, is not yet accomplished. Until then, configure the 24Mhz of sys_clkout2 to feed an USB-Hub here. Hmm would like to see Tero's comments on this, I wonder if we should wait on this to avoid extra churn? Well, the set I posted that adds default clock parenting / default rate support to DT hasn't actually moved forward, so you might want to take this in as is now if it should be rushed. The clk-enable part isn't done currently by anything anyway. Just wondering though, should you create some sort of driver for your usb-hub which would control these clocks? The USB-Hub, a USB2512 is wired as non-configurable. Its pin 'XTAL1/CLKIN' can be connected to either a crystal or an external clock input. To economise the crystal, the clock-out of the omap is wired here. So in my view, a driver is unnecessary. Yeah that makes sense. Let's try not to rely on pdata-quirks.c for the new boards. 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
[RFC] CPSW: dual standalone emac mode / bonding
Has anybody successfuly setup ethernet bonding on a TI AM335x based system using the CPSW in dual standalone emac mode? I am running an active-backup test setup - momentarily still running Linux 3.2 - and experience repeated loss of ethernet connectivity. That happens eg. after the board is idle and receives an own ARP request on the backup slave interface. It seems that the corresponding reply does not reach the CPU and I can see via SysFs that the host's address entry got associated with the external backup port. index 2, raw: 1018 31e00669, type: addr(1), addr: 00:18:31:e0:06:69, uctype: persistant(0), port: 0 -- uctype: persistant(0), port: 2 As expected, triggering a unicast from the board or bypassing the ALE recovers the situation. Regards, Christian -- 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 00/18] ARM: OMAP2+: CM/PRM cleanup set
* Tero Kristo t-kri...@ti.com [140304 08:22]: Hi, This set cleans up the CM/PRM codebase a bit, removing the need for direct CM/PRM register access macros outside CM/PRM drivers. This is done in preparation to isolate these drivers into its own driver directory. Currently my plan is to create a single PRCM driver, which will contain both, and as such, CM/PRM inter-access is not removed in this set. This set is built on top of the OMAP2 DT clock conversion set, but most of the patches can also be standalone if need be. Testing done: - omap2 : none (any feedback welcome) Seems to boot just fine on n8x0 and 2430sdp. - omap3-beagle : boot, suspend-resume (RET), suspend-resume (OFF) Also tested that off-idle keeps working. - omap4-panda-es : boot, suspend-resume (RET) Branch also available here: tree: https://github.com/t-kristo/linux-pm.git branch: 3.14-rc4-cm-prm-cleanup It seems that it's probably best that Paul queues or acks these once the dependencies are out of the way. 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: [PATCHv2 13/14] ARM: OMAP24xx: clock: remove legacy clock data
* Tony Lindgren t...@atomide.com [140305 09:12]: * Tero Kristo t-kri...@ti.com [140305 00:17]: On 03/04/2014 11:28 PM, Tony Lindgren wrote: * Tero Kristo t-kri...@ti.com [140304 10:58]: On 03/04/2014 07:32 PM, Tony Lindgren wrote: * Tero Kristo t-kri...@ti.com [140304 01:22]: This is no longer needed as clock data is provided through DT. Looks like there's a new error even before applying this patch in the series as I'm now getting the following oops on n8x0. So cannot test this patch yet. Is this with OMAP2 only boot? Yeah that's with omap2 only. That explains it, as previous series was never boot tested in omap2 only config (due to build issues.) I just force pushed the branch with the below additional patch, can you check if it works now? Yes seems to work with that thanks. And with the omap2 legacy clock data removed too, it boots fine on n8x0 and 2430sdp. I suggest you drop the omap3 legacy data patch from this branch as it's not omap2 related and cannot be done yet. Then try to get acks from Paul. And if there are no issues, it seems Mike could take the whole branch as it seems to merge just fine with what I have queued. So for all the patches except for the omap3 legacy data removal, feel free to add: Acked-by: Tony Lindgren t...@atomide.com Found one randconfig error with this series when CONFIG_ARCH_OMAP2 is not set: /drivers/clk/ti/dpll.c:273: undefined reference to `omap2xxx_clkt_dpllcore_init' drivers/clk/ti/dpll.c:311: undefined reference to `clkhwops_omap2xxx_dpll' It's also possible the error is the PRM clean up series, but probably in this series based drivers/clk/ti/dpll.c path. 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 v8 0/3] mmc: omap_hsmmc: Enable SDIO IRQ.
* Andreas Fenkart afenk...@gmail.com [140305 00:39]: Hi Tony, I had an infinite loop in hsmmc_disable_wake_irq. Since the SDIO irq is level triggered, I have to disable the IRQ in the handler otherwise it is called infinitely. Did some other minor changes see below. v8 - rebased on top of Tony Lindgrent...@atomide.com changes - improved changelog describing the earlier work - improved wakeup irq setup - works on am3730 es platform now - my changes on top: - compile tested with #undef CONFIG_OF - disable wake_irq in handler to prevent infinite loop - fixed typo and added comment about wake-irq Great, tested here and things work for me for waking omap3 from off-idle based on the SDIO interrupt. Maybe leave out the trailing period from the Subject line for the last patch? If you look at git log --pretty=oneline the trailing period is rarely used :) Balaji, care to queue or ack these for Chris? Looks like Chris has a wrong email address (corrected in this mail), so maybe one more repost of the series is needed. 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: [PATCHv3 00/13] OMAP IOMMU DT adaptation for 3.15
* Suman Anna s-a...@ti.com [140304 09:03]: On 03/04/2014 10:04 AM, Joerg Roedel wrote: Applied patches 1-7 to my arm/omap branch. Tony, you can pull that branch into your tree if needed (when I pushed it, which will happen today or tomorrow). OK thanks, looks like remaining patches compile just fine even without it which is nice. Tony, Can you also pull in the corresponding DTS node patches as well that go along with this series. http://marc.info/?l=linux-omapm=139362062805816w=2 They look OK to me, but looks like Benoit and Paul are not Cc:ed on the hwmod changes. I suggest you resend just patches 8 - 13 and the .dts changes as a new series with Benoit and Paul on Cc for them so they have a chance to review and ack them. 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 4/7] ARM: dts: omap3-overo: Add HSUSB PHY
* Florian Vaussard florian.vauss...@epfl.ch [140305 00:04]: On 03/03/2014 02:07 PM, Roger Quadros wrote: Putting usb host pins in omap3-overo.dtsi implies that all Overo expansion boards will use it but that is not always the case. Any expansion board vendor can decide not to use USB host feature. I do agree that this can be the case. So it makes sense to push the USB host down to expansion boards. Now how to do it? The omap3_pmx_core part can be put in omap3-overo-tobi-common.dtsi. But unfortunately, the omap3_pmx_core2 part cannot be factorized between the two variants, as one has to use a different macro for each case (OMAP3430_CORE2_IOPAD vs. OMAP3630_CORE2_IOPAD). Including the right .dtsi file is not enough. FYI, it's best to have the mux registers board specific and separate because the mux settings can depend on the SoC revision or even packaging. As it can be seen from include/dt-bindings/pinctrl/omap.h, even if the padconf register physical address is identical for both SoCs, the offset inside omap3_pmx_core2 will be different (as the start of omap3_pmx_core2 is 0x480025d8 for omap34xx and 0x480025a0 for omap36xx). Thus the pins belonging to omap3_pmx_core2 must be in a SoC-dependent .dtsi file. It seems we need a top level .dts file incuding the right SoC and pinconf settings. I will post a v4 with a new proposition. Thanks for your inputs. OK as that might change the other patches too let's wait for that. 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 6/6] arm/dts: added dt properties to adapt to the new phy framwork
* Kishon Vijay Abraham I kis...@ti.com [140305 04:46]: Tony/Benoit, On Monday 03 March 2014 05:08 PM, Kishon Vijay Abraham I wrote: Added device tree bindings for dwc3, usb2 and usb3 PHYs. The documentation of these can be found at Documentation/devicetree/bindings/phy/phy-bindings.txt and Documentation/devicetree/bindings/phy/ti-phy.txt. Can this patch be queued for 3.15 merge window? Thanks applying this patch into omap-for-v3.15/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 0/5] Add USB nodes for am43xx epos and gp evm
* George Cherian george.cher...@ti.com [140303 05:58]: The patch series adds USB dt nodes for am43xx epos and gp evm Boot tested with Benoit's for_3.15 + following patches https://patchwork.kernel.org/patch/3600821/ https://patchwork.kernel.org/patch/3600831/ https://patchwork.kernel.org/patch/3600851/ https://patchwork.kernel.org/patch/3600841/ Roger, care to look through these and ack if OK? Regards, Tony George Cherian (5): ARM: dts: am43xx clock data ARM: dts: AM4372: Add USB nodes ARM: dts: am437x-gp-evm: Enable USB ARM: dts: am43x-epos-evm: Enable USB doc: Add ti,am437x-dwc3 comaptible for dwc3 glue Documentation/devicetree/bindings/usb/omap-usb.txt | 4 +- arch/arm/boot/dts/am4372.dtsi | 99 ++ arch/arm/boot/dts/am437x-gp-evm.dts| 44 ++ arch/arm/boot/dts/am43x-epos-evm.dts | 44 ++ arch/arm/boot/dts/am43xx-clocks.dtsi | 17 5 files changed, 207 insertions(+), 1 deletion(-) -- 1.8.3.1 -- 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/4] ARM: dts: OMAP3630+: Add ABB device nodes
* Nishanth Menon n...@ti.com [140129 15:48]: Now that clock nodes have been merged to master, refresh of the series meant for all TI platforms using ABB. Originally posted [1], I will restart with v1. Thanks applying all except for the crossbar ones into omap-for-v3.15/dt. Please resend the last three patches once the dependencies are merged to mainline kernel as otherwise the interrupt nubers are all wrong without the crossbar driver related code. 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 0/4] ARM: dts: OMAP3630+: Add ABB device nodes
* Tony Lindgren t...@atomide.com [140305 11:51]: * Nishanth Menon n...@ti.com [140129 15:48]: Now that clock nodes have been merged to master, refresh of the series meant for all TI platforms using ABB. Originally posted [1], I will restart with v1. Thanks applying all except for the crossbar ones into omap-for-v3.15/dt. Please resend the last three patches once the dependencies are merged to mainline kernel as otherwise the interrupt nubers are all wrong without the crossbar driver related code. Oops, should have replied this to the pending patches thread instead, please ignore. 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 0/9] dts pending patches for TI omap
* Mugunthan V N mugunthan...@ti.com [140303 06:53]: Benoit/Tony Here I am send all the pending dt patches that can go into 3.15 merge window, all the patches were already posted to mailing list and has beed reviewed. I have rebased the patches on top of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git omap-for-v3.15/dt and fixed all the merge conflicts. Pasting the mail archive for the patches series * Add ABB device nodes http://linux-kernel.2935.n7.nabble.com/PATCH-0-4-ARM-dts-OMAP3630-Add-ABB-device-nodes-td794852.html * MMC hot plug support http://mail.blameitonlove.com/lists/linux-omap/msg101933.html Dropped [PATCH 2/3] ARM: dts: am335x-evmsk: add SD card hotplug support as this is already merged with commit id 29ea5efb0bb612d352aa360de26e2095cb230e4a * DRA7 Cross bar DTS patches Cross bar driver has been pulled for next merge, so the dts patches can also be pulled for next merge window. Here is the pull request for the same patch series. The following changes since commit f777ba1780584b100ab9664cc06d04f3bb273a84: Merge tag 'for_3.15/dts_signed' of git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt into omap-for-v3.15/dt (2014-03-02 14:22:03 -0800) are available in the git repository at: git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git omapdt-for-3.15 for you to fetch changes up to 5f78b45aa45c5b2c4de895c3b0740fda4684dae4: ARM: DTS: DRA7: Add routable-irqs property for gic node (2014-03-03 19:53:25 +0530) Thanks applying all except for the crossbar ones into omap-for-v3.15/dt. Please resend the last three patches once the dependencies are merged to mainline kernel as otherwise the interrupt nubers are all wrong without the crossbar driver related code. 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] ARM: dts: am335x-evmsk: enable dual_emac mode
* yegorsli...@googlemail.com yegorsli...@googlemail.com [140304 23:32]: From: Yegor Yefremov yegorsli...@googlemail.com EVM board provides two Ethernet ports, this patch sets them into dual_emac mode to provide two independent network interfaces. Thanks applying into omap-for-v3.15/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: [PATCHv3 00/13] OMAP IOMMU DT adaptation for 3.15
Tony, On 03/05/2014 01:33 PM, Tony Lindgren wrote: * Suman Anna s-a...@ti.com [140304 09:03]: On 03/04/2014 10:04 AM, Joerg Roedel wrote: Applied patches 1-7 to my arm/omap branch. Tony, you can pull that branch into your tree if needed (when I pushed it, which will happen today or tomorrow). OK thanks, looks like remaining patches compile just fine even without it which is nice. Yes, I did test the boot specifically for this both with and without the corresponding DTS nodes. Tony, Can you also pull in the corresponding DTS node patches as well that go along with this series. http://marc.info/?l=linux-omapm=139362062805816w=2 They look OK to me, but looks like Benoit and Paul are not Cc:ed on the hwmod changes. I suggest you resend just patches 8 - 13 and the .dts changes as a new series with Benoit and Paul on Cc for them so they have a chance to review and ack them. OK, will do. Thanks Suman -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Help needed USB hub disconnected at resume
-Original Message-
From: Felipe Balbi [mailto:ba...@ti.com]
Sent: 04 March 2014 23:43
To: Marc Murphy
Cc: 'ba...@ti.com'; 'Igor Grinberg'; Roger Quadros; linux-
o...@vger.kernel.org
Subject: Re: Help needed USB hub disconnected at resume
On Tue, Mar 04, 2014 at 11:05:58PM +, Marc Murphy wrote:
-Original Message-
From: Felipe Balbi [mailto:ba...@ti.com]
Sent: 04 March 2014 22:44
To: Marc Murphy
Cc: 'Igor Grinberg'; Roger Quadros; linux-omap@vger.kernel.org
Subject: Re: Help needed USB hub disconnected at resume
Hi,
On Tue, Mar 04, 2014 at 10:34:56PM +, Marc Murphy wrote:
static __init void tam3517_ehci_init(void) {
/* Configure GPIO for EHCI port */
omap_mux_init_gpio(TAM3517_EHCI_RESET, OMAP_PIN_OUTPUT);
gpio_request(TAM3517_EHCI_RESET, USB_RESET);
gpio_direction_output(TAM3517_EHCI_RESET, 1);
gpio_export(TAM3517_EHCI_RESET, 0);
why are you exporting this gpio ?
It makes no difference whether I configure the GPIO or not.
gpio_export() is only to expose the gpio to sysfs. Check if that pin is active
high or active low. Then what you need, most likely, is something like below:
gpio_direction_output(RESET, HIGH);
usleep_range(5, 200);
gpio_set_value(RESET, LOW);
(assuming active high here)
Thanks, the export was for sysfs so that I could toggle the state myself to
debug. The reference has now been removed and the toggling left to the driver
(ehci)
Igor, I have been looking at the ehci driver and the reset pin of the 3320 is
toggled at initialisation but there is no resetting when resuming from sleep.
I have created a resume function;
static void ehci_hcd_omap_resume(struct platform_device *pdev)
{
struct device *dev = pdev-dev;
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct ehci_hcd_omap_platform_data *pdata = dev-platform_data;
if (pdata-phy_reset) {
if (gpio_is_valid(pdata-reset_gpio_port[0]))
gpio_set_value(pdata-reset_gpio_port[0], 0);
if (gpio_is_valid(pdata-reset_gpio_port[1]))
gpio_set_value(pdata-reset_gpio_port[1], 0);
/* Hold the PHY in RESET for enough time till DIR is high */
udelay(100);
}
if (pdata-phy_reset) {
/* Hold the PHY in RESET for enough time till
* PHY is settled and ready
*/
udelay(10);
if (gpio_is_valid(pdata-reset_gpio_port[0]))
gpio_set_value(pdata-reset_gpio_port[0], 1);
if (gpio_is_valid(pdata-reset_gpio_port[1]))
gpio_set_value(pdata-reset_gpio_port[1], 1);
}
}
And linked in the static struct platform_driver ehci_hcd_omap_driver = {
.resume = ehci_hcd_omap_resume,
It calls the function at resume and I can see the line toggle on the scope but
still the same response from the driver of disconnecting the hub.
I have even stepped through ehci_bus_resume (struct usb_hcd *hcd) and it all
seems to be OK with the bringup.
Is there any way to enable more debug so that I can see the path through the pm
and hci code ?
I have enabled dynamic debug in the kernel but when I pass the dyndbg modules
on the command line I don't seem to get any additional output... e.g.
rootfstype=nfs ip=dhcp nohlt no_console_suspend=1 dyndbg= module ehci_hcd +p ;
module uhci_hcd +p ; module ohci_hcd +p rw
Marc
--
balbi
--
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] crypto: omap-sham: kmap SG pages before appending
On Wed, Mar 05, 2014 at 09:42:38AM -0600, Joel Fernandes wrote: In my testing it wasn't called from softirq, I'm using cryptodev which is called from openssl through ioctl, here is a traceback (sorry about wrap): [bf8010bb] (cryptodev_ioctl+0x282/0x59c [cryptodev]) [ 220.015390] [bf8010bb] (cryptodev_ioctl+0x282/0x59c [cryptodev]) from [c00cdaa5] (do_vfs_ioctl+0x61/0x41c) [ 220.025909] [c00cdaa5] (do_vfs_ioctl+0x61/0x41c) from [c00cdeab] (SyS_ioctl+0x4b/0x50) [ 220.034602] [c00cdeab] (SyS_ioctl+0x4b/0x50) from [c000cf01] (ret_fast_syscall+0x1/0x46) [ 220.045254] CPU: 0 PID: 1798 Comm: openssl Tainted: G O 3.12.9-00581-g5fa084c-dirty #32 [ 220.054636] [c0012d05] (unwind_backtrace+0x1/0x9c) from [c000fa6d] (show_stack+0x11/0x14) [ 220.063619] [c000fa6d] (show_stack+0x11/0x14) from [c0342edb] (dump_stack+0x4b/0x60) [ 220.072144] [c0342edb] (dump_stack+0x4b/0x60) from [c02a1b3f] (omap_sham_update+0x1f/0xa4) [ 220.081214] [c02a1b3f] (omap_sham_update+0x1f/0xa4) from [bf801f67] (cryptodev_hash_update+0x26/0x80 [cryptodev]) Could you suggest, what other place is update() called in softirq context? I may be missing something. IPsec may call this from softirq context. Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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/10] ARM: dts: OMAP3: Add IVA IOMMU node
From: Florian Vaussard florian.vauss...@epfl.ch
Add the DT node for the IOMMU within the DSP subsystem. The entry
is disabled to keep in line with the hwmod usage as intended by
the deprecated CONFIG_OMAP_IOMMU_IVA2 flag.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
[s-a...@ti.com: split the entry and disable the node]
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/omap3.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index f7a47e3..9574a9e 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -418,6 +418,14 @@
ti,#tlb-entries = 8;
};
+ mmu_iva: mmu@5d00 {
+ compatible = ti,omap2-iommu;
+ reg = 0x5d00 0x80;
+ interrupts = 28;
+ ti,hwmods = mmu_iva;
+ status = disabled;
+ };
+
wdt2: wdt@48314000 {
compatible = ti,omap3-wdt;
reg = 0x48314000 0x80;
--
1.9.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 07/10] ARM: dts: OMAP3: Update ISP IOMMU node
From: Florian Vaussard florian.vauss...@epfl.ch
Update the IOMMU node for the camera subsystem as per the
OMAP IOMMU bindings.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
[s-a...@ti.com: corrected interrupt number]
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/omap3.dtsi | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index a5fc83b..f7a47e3 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -411,10 +411,11 @@
};
mmu_isp: mmu@480bd400 {
- compatible = ti,omap3-mmu-isp;
- ti,hwmods = mmu_isp;
+ compatible = ti,omap2-iommu;
reg = 0x480bd400 0x80;
- interrupts = 8;
+ interrupts = 24;
+ ti,hwmods = mmu_isp;
+ ti,#tlb-entries = 8;
};
wdt2: wdt@48314000 {
--
1.9.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 04/10] ARM: OMAP2+: use pdata quirks for iommu reset lines
The OMAP iommu driver performs the reset management for the
iommu instances in processor sub-systems using the omap_device
API which are currently supplied as platform data ops. Use pdata
quirks to maintain the functionality as the OMAP iommu driver
gets converted to use DT nodes, until the reset portions are
decoupled from omap_hwmod/omap_device into a separate reset
driver.
This patch adds the pdata quirks for the reset management of
iommus within the DSP (OMAP3 OMAP4) and IPU subsystems (OMAP4).
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/pdata-quirks.c | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index 3d5b24d..74e094a 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -16,12 +16,14 @@
#include linux/wl12xx.h
#include linux/platform_data/pinctrl-single.h
+#include linux/platform_data/iommu-omap.h
#include am35xx.h
#include common.h
#include common-board-devices.h
#include dss-common.h
#include control.h
+#include omap_device.h
struct pdata_init {
const char *compatible;
@@ -92,6 +94,12 @@ static void __init hsmmc2_internal_input_clk(void)
omap_ctrl_writel(reg, OMAP343X_CONTROL_DEVCONF1);
}
+static struct iommu_platform_data omap3_iommu_pdata = {
+ .reset_name = mmu,
+ .assert_reset = omap_device_assert_hardreset,
+ .deassert_reset = omap_device_deassert_hardreset,
+};
+
static int omap3_sbc_t3730_twl_callback(struct device *dev,
unsigned gpio,
unsigned ngpio)
@@ -185,6 +193,12 @@ static void __init omap4_panda_legacy_init(void)
legacy_init_ehci_clk(auxclk3_ck);
legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 53);
}
+
+static struct iommu_platform_data omap4_iommu_pdata = {
+ .reset_name = mmu_cache,
+ .assert_reset = omap_device_assert_hardreset,
+ .deassert_reset = omap_device_deassert_hardreset,
+};
#endif
#ifdef CONFIG_SOC_OMAP5
@@ -240,6 +254,8 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
#ifdef CONFIG_ARCH_OMAP3
OF_DEV_AUXDATA(ti,omap3-padconf, 0x48002030, 48002030.pinmux,
pcs_pdata),
OF_DEV_AUXDATA(ti,omap3-padconf, 0x48002a00, 48002a00.pinmux,
pcs_pdata),
+ OF_DEV_AUXDATA(ti,omap2-iommu, 0x5d00, 5d00.mmu,
+ omap3_iommu_pdata),
/* Only on am3517 */
OF_DEV_AUXDATA(ti,davinci_mdio, 0x5c03, davinci_mdio.0, NULL),
OF_DEV_AUXDATA(ti,am3517-emac, 0x5c00, davinci_emac.0,
@@ -248,6 +264,10 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
#ifdef CONFIG_ARCH_OMAP4
OF_DEV_AUXDATA(ti,omap4-padconf, 0x4a100040, 4a100040.pinmux,
pcs_pdata),
OF_DEV_AUXDATA(ti,omap4-padconf, 0x4a31e040, 4a31e040.pinmux,
pcs_pdata),
+ OF_DEV_AUXDATA(ti,omap4-iommu, 0x4a066000, 4a066000.mmu,
+ omap4_iommu_pdata),
+ OF_DEV_AUXDATA(ti,omap4-iommu, 0x55082000, 55082000.mmu,
+ omap4_iommu_pdata),
#endif
{ /* sentinel */ },
};
--
1.9.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 09/10] ARM: dts: OMAP4: Add IOMMU nodes
From: Florian Vaussard florian.vauss...@epfl.ch
Add the IOMMU nodes for the DSP and IPU subsystems. The MMU
within the IPU sub-system also supports a bus error back
capability, not available on the DSP MMU.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
[s-a...@ti.com: IPU bus error back addition]
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index d3f8a6e..2b88d97 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -461,6 +461,21 @@
dma-names = tx, rx;
};
+ mmu_dsp: mmu@4a066000 {
+ compatible = ti,omap4-iommu;
+ reg = 0x4a066000 0x100;
+ interrupts = GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = mmu_dsp;
+ };
+
+ mmu_ipu: mmu@55082000 {
+ compatible = ti,omap4-iommu;
+ reg = 0x55082000 0x100;
+ interrupts = GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = mmu_ipu;
+ ti,iommu-bus-err-back;
+ };
+
wdt2: wdt@4a314000 {
compatible = ti,omap4-wdt, ti,omap3-wdt;
reg = 0x4a314000 0x80;
--
1.9.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 10/10] ARM: dts: OMAP5: Add IOMMU nodes
The IOMMU DT nodes have been added for the DSP and IPU
subsystems. The MMUs in OMAP5 are identical to those in
OMAP4, including the bus error back capability on IPU.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index a72813a..4c16255 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -513,6 +513,21 @@
dma-names = tx, rx;
};
+ mmu_dsp: mmu@4a066000 {
+ compatible = ti,omap4-iommu;
+ reg = 0x4a066000 0x100;
+ interrupts = GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = mmu_dsp;
+ };
+
+ mmu_ipu: mmu@55082000 {
+ compatible = ti,omap4-iommu;
+ reg = 0x55082000 0x100;
+ interrupts = GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = mmu_ipu;
+ ti,iommu-bus-err-back;
+ };
+
keypad: keypad@4ae1c000 {
compatible = ti,omap4-keypad;
reg = 0x4ae1c000 0x400;
--
1.9.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 02/10] ARM: OMAP3: fix iva mmu programming issues
The IVA MMU is not functional when used through the hwmod and
omap_device layers. Add fixes to clockdomain and hwmod data
to have it functional. The hwmod changes are needed to enable
the clock, and the SWSUP change is needed to wakeup the domain
because the power domain is programmed to be in RET, and there
is no automatic power domain switching to ON.
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/clockdomains3xxx_data.c | 2 +-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 4
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/clockdomains3xxx_data.c
b/arch/arm/mach-omap2/clockdomains3xxx_data.c
index e6b91e5..f03dc97 100644
--- a/arch/arm/mach-omap2/clockdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/clockdomains3xxx_data.c
@@ -247,7 +247,7 @@ static struct clockdomain neon_clkdm = {
static struct clockdomain iva2_clkdm = {
.name = iva2_clkdm,
.pwrdm = { .name = iva2_pwrdm },
- .flags = CLKDM_CAN_HWSUP_SWSUP,
+ .flags = CLKDM_CAN_SWSUP,
.dep_bit= OMAP3430_PM_WKDEP_MPU_EN_IVA2_SHIFT,
.wkdep_srcs = iva2_wkdeps,
.clktrctrl_mask = OMAP3430_CLKTRCTRL_IVA2_MASK,
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 81dd071..9c7e23a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3068,12 +3068,16 @@ static struct omap_hwmod omap3xxx_mmu_iva_hwmod = {
.name = mmu_iva,
.class = omap3xxx_mmu_hwmod_class,
.mpu_irqs = omap3xxx_mmu_iva_irqs,
+ .clkdm_name = iva2_clkdm,
.rst_lines = omap3xxx_mmu_iva_resets,
.rst_lines_cnt = ARRAY_SIZE(omap3xxx_mmu_iva_resets),
.main_clk = iva2_ck,
.prcm = {
.omap2 = {
.module_offs = OMAP3430_IVA2_MOD,
+ .module_bit = OMAP3430_CM_FCLKEN_IVA2_EN_IVA2_SHIFT,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP3430_ST_IVA2_SHIFT,
},
},
.dev_attr = mmu_iva_dev_attr,
--
1.9.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 01/10] ARM: OMAP3: remove deprecated CONFIG_OMAP_IOMMU_IVA2
From: Florian Vaussard florian.vauss...@epfl.ch
CONFIG_OMAP_IOMMU_IVA2 was defined originally to avoid conflicting
usage by tidspbridge and other iommu users. The same can be achieved
by marking the DT node disabled, so remove this obsolete flag and
the corresponding hwmod data can be enabled.
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
[s-a...@ti.com: revise commit log]
Signed-off-by: Suman Anna s-a...@ti.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Tony Lindgren t...@atomide.com
Acked-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 8
arch/arm/plat-omap/Kconfig | 3 ---
2 files changed, 11 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 4c3b1e6..81dd071 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3029,8 +3029,6 @@ static struct omap_hwmod omap3xxx_mmu_isp_hwmod = {
.flags = HWMOD_NO_IDLEST,
};
-#ifdef CONFIG_OMAP_IOMMU_IVA2
-
/* mmu iva */
static struct omap_mmu_dev_attr mmu_iva_dev_attr = {
@@ -3082,8 +3080,6 @@ static struct omap_hwmod omap3xxx_mmu_iva_hwmod = {
.flags = HWMOD_NO_IDLEST,
};
-#endif
-
/* l4_per - gpio4 */
static struct omap_hwmod_addr_space omap3xxx_gpio4_addrs[] = {
{
@@ -3855,9 +3851,7 @@ static struct omap_hwmod_ocp_if *omap34xx_hwmod_ocp_ifs[]
__initdata = {
omap3xxx_l4_core__hdq1w,
omap3xxx_sad2d__l3,
omap3xxx_l4_core__mmu_isp,
-#ifdef CONFIG_OMAP_IOMMU_IVA2
omap3xxx_l3_main__mmu_iva,
-#endif
omap34xx_l4_core__ssi,
NULL
};
@@ -3881,9 +3875,7 @@ static struct omap_hwmod_ocp_if *omap36xx_hwmod_ocp_ifs[]
__initdata = {
omap3xxx_l4_core__hdq1w,
omap3xxx_sad2d__l3,
omap3xxx_l4_core__mmu_isp,
-#ifdef CONFIG_OMAP_IOMMU_IVA2
omap3xxx_l3_main__mmu_iva,
-#endif
NULL
};
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 436ea97..02fc10d 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -86,9 +86,6 @@ config OMAP_MUX_WARNINGS
to change the pin multiplexing setup. When there are no warnings
printed, it's safe to deselect OMAP_MUX for your product.
-config OMAP_IOMMU_IVA2
- bool
-
config OMAP_MPU_TIMER
bool Use mpu timer
depends on ARCH_OMAP1
--
1.9.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 00/10] arch/arm OMAP IOMMU patches for 3.15
Hi Paul, Benoit, This is a repost as per Tony's request [3] of all the OMAP IOMMU DT support patches that are under arch/arm. The series just assimilates patches 8 through 13 from the v3 OMAP IOMMU DT adaptation for 3.15 series [1], and all the v2 patches from the OMAP IOMMU DTS nodes [2]. The only change made with respect to the patches above is in the OMAP4 and OMAP5 DTS nodes - I have adjusted the reg sizes from 0xff to 0x100. Can you please provide your acks on the hwmod patches and DTS patches? regards Suman [1] http://marc.info/?l=linux-omapm=139362022805667w=2 [2] http://marc.info/?l=linux-omapm=139362062805816w=2 [3] http://marc.info/?l=linux-omapm=139404802021252w=2 Florian Vaussard (4): ARM: OMAP3: remove deprecated CONFIG_OMAP_IOMMU_IVA2 ARM: dts: OMAP3: Update ISP IOMMU node ARM: dts: OMAP3: Add IVA IOMMU node ARM: dts: OMAP4: Add IOMMU nodes Suman Anna (6): ARM: OMAP3: fix iva mmu programming issues ARM: OMAP2+: change the ISP device archdata MMU name for DT ARM: OMAP2+: use pdata quirks for iommu reset lines ARM: OMAP5: hwmod data: add mmu data for ipu dsp ARM: OMAP2+: extend iommu pdata-quirks to OMAP5 ARM: dts: OMAP5: Add IOMMU nodes arch/arm/boot/dts/omap3.dtsi| 15 -- arch/arm/boot/dts/omap4.dtsi| 15 ++ arch/arm/boot/dts/omap5.dtsi| 15 ++ arch/arm/mach-omap2/clockdomains3xxx_data.c | 2 +- arch/arm/mach-omap2/devices.c | 3 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 12 ++--- arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 83 + arch/arm/mach-omap2/pdata-quirks.c | 24 + arch/arm/plat-omap/Kconfig | 3 -- 9 files changed, 157 insertions(+), 15 deletions(-) -- 1.9.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 05/10] ARM: OMAP5: hwmod data: add mmu data for ipu dsp
A new MMU hwmod class and data structures are created
to represent the MMUs within the IPU and DSP processor
subsystems in OMAP5. The MMUs in OMAP5 are identical to
those in OMAP4.
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson bcous...@baylibre.com
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 83 ++
1 file changed, 83 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index e297d62..8923172 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -1122,6 +1122,71 @@ static struct omap_hwmod omap54xx_mmc5_hwmod = {
};
/*
+ * 'mmu' class
+ * The memory management unit performs virtual to physical address translation
+ * for its requestors.
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_mmu_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap54xx_mmu_hwmod_class = {
+ .name = mmu,
+ .sysc = omap54xx_mmu_sysc,
+};
+
+static struct omap_hwmod_rst_info omap54xx_mmu_dsp_resets[] = {
+ { .name = mmu_cache, .rst_shift = 1 },
+};
+
+static struct omap_hwmod omap54xx_mmu_dsp_hwmod = {
+ .name = mmu_dsp,
+ .class = omap54xx_mmu_hwmod_class,
+ .clkdm_name = dsp_clkdm,
+ .rst_lines = omap54xx_mmu_dsp_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap54xx_mmu_dsp_resets),
+ .main_clk = dpll_iva_h11x2_ck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP54XX_CM_DSP_DSP_CLKCTRL_OFFSET,
+ .rstctrl_offs = OMAP54XX_RM_DSP_RSTCTRL_OFFSET,
+ .context_offs = OMAP54XX_RM_DSP_DSP_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+};
+
+/* mmu ipu */
+static struct omap_hwmod_rst_info omap54xx_mmu_ipu_resets[] = {
+ { .name = mmu_cache, .rst_shift = 2 },
+};
+
+static struct omap_hwmod omap54xx_mmu_ipu_hwmod = {
+ .name = mmu_ipu,
+ .class = omap54xx_mmu_hwmod_class,
+ .clkdm_name = ipu_clkdm,
+ .rst_lines = omap54xx_mmu_ipu_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap54xx_mmu_ipu_resets),
+ .main_clk = dpll_core_h22x2_ck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP54XX_CM_IPU_IPU_CLKCTRL_OFFSET,
+ .rstctrl_offs = OMAP54XX_RM_IPU_RSTCTRL_OFFSET,
+ .context_offs = OMAP54XX_RM_IPU_IPU_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+};
+
+/*
* 'mpu' class
* mpu sub-system
*/
@@ -1763,6 +1828,14 @@ static struct omap_hwmod_ocp_if
omap54xx_l4_cfg__l3_main_1 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_cfg - mmu_dsp */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__mmu_dsp = {
+ .master = omap54xx_l4_cfg_hwmod,
+ .slave = omap54xx_mmu_dsp_hwmod,
+ .clk= l4_root_clk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* mpu - l3_main_1 */
static struct omap_hwmod_ocp_if omap54xx_mpu__l3_main_1 = {
.master = omap54xx_mpu_hwmod,
@@ -1787,6 +1860,14 @@ static struct omap_hwmod_ocp_if
omap54xx_l4_cfg__l3_main_2 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l3_main_2 - mmu_ipu */
+static struct omap_hwmod_ocp_if omap54xx_l3_main_2__mmu_ipu = {
+ .master = omap54xx_l3_main_2_hwmod,
+ .slave = omap54xx_mmu_ipu_hwmod,
+ .clk= l3_iclk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* l3_main_1 - l3_main_3 */
static struct omap_hwmod_ocp_if omap54xx_l3_main_1__l3_main_3 = {
.master = omap54xx_l3_main_1_hwmod,
@@ -2345,6 +2426,7 @@ static struct omap_hwmod_ocp_if *omap54xx_hwmod_ocp_ifs[]
__initdata = {
omap54xx_l4_wkup__counter_32k,
omap54xx_l4_cfg__dma_system,
omap54xx_l4_abe__dmic,
+ omap54xx_l4_cfg__mmu_dsp,
omap54xx_mpu__emif1,
omap54xx_mpu__emif2,
omap54xx_l4_wkup__gpio1,
@@ -2360,6 +2442,7 @@ static struct omap_hwmod_ocp_if *omap54xx_hwmod_ocp_ifs[]
__initdata = {
omap54xx_l4_per__i2c3,
omap54xx_l4_per__i2c4,
omap54xx_l4_per__i2c5,
+ omap54xx_l3_main_2__mmu_ipu,
omap54xx_l4_wkup__kbd,
omap54xx_l4_cfg__mailbox,
omap54xx_l4_abe__mcbsp1,
--
1.9.0
--
To unsubscribe from
[PATCH 03/10] ARM: OMAP2+: change the ISP device archdata MMU name for DT
The IOMMU DT adaptation support uses the device name instead
of an iommu object name. Fixup the ISP device archdata MMU
name at runtime if using DT-boot. This allows the OMAP3 camera
to be functional in both legacy and DT boots. The iommu object
names should eventually vanish when all the IOMMU users have
been converted to DT nodes.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/devices.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 0dd6398..e58609b 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -229,6 +229,9 @@ static struct omap_iommu_arch_data omap3_isp_iommu = {
int omap3_init_camera(struct isp_platform_data *pdata)
{
+ if (of_have_populated_dt())
+ omap3_isp_iommu.name = 480bd400.mmu;
+
omap3isp_device.dev.platform_data = pdata;
omap3isp_device.dev.archdata.iommu = omap3_isp_iommu;
--
1.9.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 06/10] ARM: OMAP2+: extend iommu pdata-quirks to OMAP5
OMAP5 has the same iommus as OMAP4, so extend the OMAP4
iommu pdata quirks for OMAP5 as well.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/pdata-quirks.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index 74e094a..551877f 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -193,7 +193,9 @@ static void __init omap4_panda_legacy_init(void)
legacy_init_ehci_clk(auxclk3_ck);
legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 53);
}
+#endif
+#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
static struct iommu_platform_data omap4_iommu_pdata = {
.reset_name = mmu_cache,
.assert_reset = omap_device_assert_hardreset,
@@ -264,6 +266,8 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
#ifdef CONFIG_ARCH_OMAP4
OF_DEV_AUXDATA(ti,omap4-padconf, 0x4a100040, 4a100040.pinmux,
pcs_pdata),
OF_DEV_AUXDATA(ti,omap4-padconf, 0x4a31e040, 4a31e040.pinmux,
pcs_pdata),
+#endif
+#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
OF_DEV_AUXDATA(ti,omap4-iommu, 0x4a066000, 4a066000.mmu,
omap4_iommu_pdata),
OF_DEV_AUXDATA(ti,omap4-iommu, 0x55082000, 55082000.mmu,
--
1.9.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
Re: [RESEND Patch 0/9] dts pending patches for TI omap
On Thursday 06 March 2014 01:20 AM, Tony Lindgren wrote: * Mugunthan V N mugunthan...@ti.com [140303 06:53]: Benoit/Tony Here I am send all the pending dt patches that can go into 3.15 merge window, all the patches were already posted to mailing list and has beed reviewed. I have rebased the patches on top of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git omap-for-v3.15/dt and fixed all the merge conflicts. Pasting the mail archive for the patches series * Add ABB device nodes http://linux-kernel.2935.n7.nabble.com/PATCH-0-4-ARM-dts-OMAP3630-Add-ABB-device-nodes-td794852.html * MMC hot plug support http://mail.blameitonlove.com/lists/linux-omap/msg101933.html Dropped [PATCH 2/3] ARM: dts: am335x-evmsk: add SD card hotplug support as this is already merged with commit id 29ea5efb0bb612d352aa360de26e2095cb230e4a * DRA7 Cross bar DTS patches Cross bar driver has been pulled for next merge, so the dts patches can also be pulled for next merge window. Here is the pull request for the same patch series. The following changes since commit f777ba1780584b100ab9664cc06d04f3bb273a84: Merge tag 'for_3.15/dts_signed' of git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt into omap-for-v3.15/dt (2014-03-02 14:22:03 -0800) are available in the git repository at: git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git omapdt-for-3.15 for you to fetch changes up to 5f78b45aa45c5b2c4de895c3b0740fda4684dae4: ARM: DTS: DRA7: Add routable-irqs property for gic node (2014-03-03 19:53:25 +0530) Thanks applying all except for the crossbar ones into omap-for-v3.15/dt. Please resend the last three patches once the dependencies are merged to mainline kernel as otherwise the interrupt nubers are all wrong without the crossbar driver related code. Ok, i will resend when the dependencies are merged 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
Re: [PATCHv3 00/41] OMAPDSS: DT support v3
Hi Tony, On 21/01/14 12:56, Tomi Valkeinen wrote: Hi, Here's version 3 of the DSS DT series. Can you have a look at the arch/arm/ parts in the series and ack if they're ok, i.e, patches 1, 2, 32. Then there are the .dts patches, 22-30, for which I haven't been able to get any acks. I'm not sure who I should get acks from for those, but I don't mind adding yours if you want to give it. The .dts patches have had minor changes compared to the ones posted here, according to the DT bindings review comments, but nothing much has changed. Tomi signature.asc Description: OpenPGP digital signature
