Re: OMAP baseline test results for v3.16-rc4
* Paul Walmsley p...@pwsan.com [140714 10:32]: On Mon, 7 Jul 2014, Tony Lindgren wrote: With v3.16-rc4 the PM features for omap3 should be working finally for device tree based booting. At lest beaglexm and 3xxevm should work. Maybe you are using legacy booting path to idle the UARTs still? FYI, I'm doing this to find the UART entries: uarts=$(find /sys/class/tty/ttyO*/device/power/ -type d) for uart in $uarts; do echo 3000 $uart/autosuspend_delay_ms done uarts=$(find /sys/class/tty/ttyO*/power/ -type d) for uart in $uarts; do echo enabled $uart/wakeup echo auto $uart/control done echo 1 /sys/kernel/debug/pm_debug/enable_off_mode OK thanks, I'll take a close look at it. It's not using the legacy paths, but based on a glance at the 37xxevm logs, it looks like the bus address of the UART isn't right. Hmm for which UART? I'm using ttyO2 on my 37xxevm FYI, it can be selected on the board based on some switch settings. I may have patched my u-boot for that too but don't remember for sure. 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 v4 02/11] memory: emif: Move EMIF register defines to include/linux/
* Dave Gerlach d-gerl...@ti.com [140714 10:44]: On 07/14/2014 06:12 AM, Tony Lindgren wrote: * Dave Gerlach d-gerl...@ti.com [140710 19:59]: OMAP4 and AM33XX share the same EMIF controller IP. Although there are significant differences in the IP integration due to which AM33XX can't reuse the EMIF driver DVFS similar to OMAP4, it can definitely benefit by reusing the EMIF related macros defined in drivers/memory/emif.h. In the current OMAP PM framework the PM code resides under arch/arm/mach-omap2/. To enable reuse of the register defines move the register defines in the emif header file to include/linux so that both the EMIF driver and the AM33XX PM code can benefit. Signed-off-by: Dave Gerlach d-gerl...@ti.com Reviewed-by: Russ Dill russ.d...@ti.com Acked-by: Santosh Shililmar santosh.shilim...@ti.com Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org --- v3-v4: patch unchanged from original: http://www.spinics.net/lists/linux-omap/msg95314.html drivers/memory/emif.h | 543 +- include/linux/ti_emif.h | 558 So far we've seen that exposing hardware registers like this will lead into various drivers misusing them. I think a better solution is to implement few targeted functions that allow sharing code between the platform idle code and memory driver. Maybe you can have the shared functions in in something like drivers/memory/ti-emif.c that's always built in? The idle code won't need any of that early on. Well the reason it was done this way was to utilize all of the addresses of EMIF register in the ASM sleep code to do relative addressing from the EMIF base address. The ASM sleep code (patch 9) needs to save and restore emif context and set and unset self refresh in emif. The issues will come from the ASM being copied to and running from SRAM without the ability to access code in DDR (because we are shutting the EMIF off), so we would need to copy these functions as well and have to worry about any issues we introduce by relocating c code. Is it worth the added maintenance burden? Ah right it needs to run in SRAM. There were some relocatable c code patches posted a while back, so it might be worth revisiting that. I think it can also be done with assembly with something like this: 1. Make am335x idle code depends on TI_EMIF WKUP_M3_RPROC 2. Add the memory save and restore assembly functions into drivers/memory/ti-emif-sram.S 3. Allocate the SRAM preferrably with drivers/misc/sram.c instead of the legacy mach-omap2/sram.c 4. Map the idle assembly code and EMIF save and restore functions into SRAM 5. Call the EMIF save and restore functions from the idle assembly code at the SRAM locations and pass the save and restore area in a register So basically we need to figure out a generic way to do driver hooks in the PM idle code even very late and early in the assembly code so we can keep most of the code in drivers. Eventually also the idle assembly code should be in the drivers too.. 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 v4 03/11] ARM: OMAP2+: timer: Add suspend-resume callbacks for clkevent device
* Dave Gerlach d-gerl...@ti.com [140714 10:44]:
Santosh, Tony,
On 07/14/2014 09:37 AM, Santosh Shilimkar wrote:
On Monday 14 July 2014 07:15 AM, Tony Lindgren wrote:
* Dave Gerlach d-gerl...@ti.com [140710 19:59]:
From: Vaibhav Bedia vaibhav.be...@ti.com
OMAP timer code registers two timers - one as clocksource
and one as clockevent. Since AM33XX has only one usable timer
in the WKUP domain one of the timers needs suspend-resume
support to restore the configuration to pre-suspend state.
commit adc78e6 (timekeeping: Add suspend and resume
of clock event devices) introduced .suspend and .resume
callbacks for clock event devices. Leverages these
callbacks to have AM33XX clockevent timer which is
in not in WKUP domain to behave properly across system
suspend.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
v3-v4:
Only use for am33xx soc now.
arch/arm/mach-omap2/timer.c | 28
1 file changed, 28 insertions(+)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 43d03fb..6fc1748 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -128,6 +128,29 @@ static void omap2_gp_timer_set_mode(enum
clock_event_mode mode,
}
}
+static void omap_clkevt_suspend(struct clock_event_device *unused)
+{
+ struct omap_hwmod *oh;
+
+ oh = omap_hwmod_lookup(clockevent_gpt.name);
+ if (!oh)
+ return;
+
+ omap_hwmod_idle(oh);
+}
+
+static void omap_clkevt_resume(struct clock_event_device *unused)
+{
+ struct omap_hwmod *oh;
+
+ oh = omap_hwmod_lookup(clockevent_gpt.name);
+ if (!oh)
+ return;
+
+ omap_hwmod_enable(oh);
+ __omap_dm_timer_int_enable(clkev, OMAP_TIMER_INT_OVERFLOW);
+}
+
This is going to make moving the timer code into drivers one step
tougher to do. And you don't need to look up the hwmod entry every
time, just initialize it during the init.
Yes you are right about looking up only at init I need to change that. I
agree that this makes moving the timers harder but I'm not sure there's any
way around this. I attempted to use the omap_device layer here but there is
no device at all created here, it does not hook into the normal PM layer
through omap_device. This clock must be shut off as it sits in the
peripheral power domain and any active clock within the domain will prevent
suspend from happening, so we end up with a platform specific issue here. It
seems that the only way I can get to the clock is through the hwmod.
It's best to register these kind of functions as platform_data
in pdata-quirks.c auxdata. That way when this moves to live
in drivers/clocksource the driver does not need to know anything
about the interconnect specific registers.
Also, please don't use Linux generic names here.. Maybe use
omap_clkevt_idle/unidle? The linux suspend and resume hooks
and runtime PM could all use these functions then.
+ if (soc_is_am33xx()) {
+ clockevent_gpt.suspend = omap_clkevt_suspend;
+ clockevent_gpt.resume = omap_clkevt_resume;
+ }
+
Maybe try to set up things so we initialize the SoC specific
timer suspend and resume functions in mach-omap2/timer.c
in a way where eventually the device driver can easily use
them?
+1. I had similar comments on the previous version too.
This was my attempt to make things specific to only am335x based on
Santosh's previous comments as last time they were populated for every
device even when unneeded. These are not standard suspend/resume handlers,
they are specific to clock event. I know there will always need to be at
least some code here for the early timer init based on previous timer
cleanup series I've seen, so perhaps I could hook it in there when the time
comes?
Well just adding a minimal include/linux/platform_data/timer-omap.h
to pass those function pointers to the driver should do the trick.
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 V2 2/2] ARM: dts: DRA7: Add node for RTC
* Lokesh Vutla lokeshvu...@ti.com [140714 21:09]: On Monday 14 July 2014 09:53 PM, Tony Lindgren wrote: * Lokesh Vutla lokeshvu...@ti.com [140714 07:47]: In my experiments I observed that when RTC regulator is switched off and switched on, there is an abort while accessing RTC registers. Right, then you know you have the right regulator :) Once we switch it off it is expected, but then if it is *switched on* it is expected that we should be able to access registers. Here there is an abort accessing these registers. Most likely you need to also reconfigure the registers or re-enable the clock or reset it at the interconnect too. After discussing with hardware team, it is confirmed that this LDO9 regulator powering RTC cannot be turned off when SoC is active and expected to be always on. Hmm but sounds like you already proved it can be idled? So the regulator really should be managed by the driver? Actually I adapted the driver to support a power regulator. Then I observed that if rtc is loaded as a module there is an abort( which is happening because the regulator is disabled once and re-enabled). So when we checked with the hardware team, they confirmed that ldo9 should not be disabled. Hmm so how is it enabled initially then? To me it sounds like very standard stuff to reinitialize a driver for any omap device when waking from suspend or returning from off-idle. If the RTC device cannot be reset, idled and re-initialized properly, there's something wrong with the RTC driver, clocks, regulators, or hwmod data for that device. 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: [RESEND PATCH 0/8] arm: dts: dra7: Add PCIe data and PCIe PHY data
* Kishon Vijay Abraham I kis...@ti.com [140714 03:44]: [1] is split into separate series in order for individual subsystem Maintainers to pick up the patches. This series handles the PCIe dt data for DRA7. This series has better commit logs than the previous one modified as suggested by Tero. [1] - https://lkml.org/lkml/2014/5/29/258 Keerthy (2): ARM: dts: dra7xx-clocks: Add divider table to optfclk_pciephy_div clock ARM: dts: dra7xx-clocks: Change the parent of apll_pcie_in_clk_mux to dpll_pcie_ref_m2ldo_ck Kishon Vijay Abraham I (6): ARM: dts: dra7xx-clocks: Add missing 32KHz clocks used for PHY ARM: dts: dra7xx-clocks: rename pcie clocks to accommodate second PHY instance ARM: dts: dra7xx-clocks: Add missing clocks for second PCIe PHY instance ARM: dts: dra7: Add dt data for PCIe PHY control module ARM: dts: dra7: Add dt data for PCIe PHY ARM: dts: dra7: Add dt data for PCIe controller arch/arm/boot/dts/dra7.dtsi | 127 ++ arch/arm/boot/dts/dra7xx-clocks.dtsi | 39 ++- 2 files changed, 163 insertions(+), 3 deletions(-) Applying this series into omap-for-v3.17/dt thanks. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] ARM: DTS: omap5-uevm: Enable audio (for 3.17)
* Peter Ujfalusi peter.ujfal...@ti.com [140710 04:26]: Hi, This set is to enable audio (finally) on the omap5-uevm. We have been waiting for the palmas 32K clock driver to make it to upstream, which it did and it is already in linux-next. With the three patch we can have audio working on omap5-uevm with linux-next. Regards, Peter --- Peter Ujfalusi (3): ARM: DTS: omap5-uevm: Enable palmas clk32kgaudio clock ARM: DTS: omap5-uevm: Add node for twl6040 audio codec ARM: DTS: omap5-uevm: Enable basic audio (McPDM - twl6040) arch/arm/boot/dts/omap5-uevm.dts | 68 1 file changed, 62 insertions(+), 6 deletions(-) Applying into omap-for-v3.17/dt thanks. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: omap2+: gpmc-nand: Use dynamic platform_device_alloc()
* Roger Quadros rog...@ti.com [140711 06:47]: On 06/04/2014 05:24 PM, Rostislav Lisovy wrote: GPMC controller supports up to 8 memory devices connected to it. Since there is one statically allocated struct platform_device gpmc_nand_device it is not possible to configure the system to use more than one NAND device connected to the GPMC. This modification makes it possible to use up to 8 NAND devices connected to the GPMC controller. Signed-off-by: Rostislav Lisovy lis...@merica.cz pushed to g...@github.com:rogerq/linux.gitfor-v3.17/gpmc-omap Tony, You can please pull all omap-gpmc patches for 3.17 from there. Thanks. OK so just this one fix, merging into omap-for-v3.17/fixes-not-urgent. 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: [RFT/RFC/PATCH 00/31] arm: omap: irq: cleanup INTC driver
* Felipe Balbi ba...@ti.com [140103 08:43]:
On Fri, Jan 03, 2014 at 05:42:41PM +0530, Rajendra Nayak wrote:
[]..
so a bit more work is needed. Maybe also rebase these against
omap-for-v3.14/dt too?
Will do.
Rebased on top of omap-for-v3.14/omap3-board-removal. Patches are on my
k.org tree:
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
wip/omap-fix-intc
It needs a minor build fix though..
diff --git a/drivers/irqchip/irq-omap-intc.c
b/drivers/irqchip/irq-omap-intc.c
index b58c5d5..d03b5a3 100644
--- a/drivers/irqchip/irq-omap-intc.c
+++ b/drivers/irqchip/irq-omap-intc.c
@@ -151,7 +151,7 @@ static void omap_mask_ack_irq(struct irq_data *d)
static void omap_suspend_irq(struct irq_data *d)
{
omap_intc_save_context();
- omap3_intc_prepare_idle();
+ omap_intc_prepare_idle();
fixed now, thanks. Wonder how come I didn't see that, I was building
every commit with omap2plus_defconfig :-( Oh well...
Felipe, care to refresh this series against v3.16-rc4 and
repost? We now finally have the DT based booting working for
PM for omap3 the same way as legacy booting so I can test
this easily for regressions. But I don't seem to have the
patches in my mailbox any longer.
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
[PATCH] ARM: dts: set 'ti,set-rate-parent' for dpll4_m5x2 clock
Set 'ti,set-rate-parent' property for the dpll4_m5x2_ck clock, which
is used for the ISP functional clock. This fixes the OMAP3 ISP driver's
clock rate configuration on OMAP34xx, which needs the rate to be
propagated properly to the divider node (dpll4_m5_ck).
Signed-off-by: Stefan Herbrechtsmeier ste...@herbrechtsmeier.net
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Tony Lindgren t...@atomide.com
Cc: Tero Kristo t-kri...@ti.com
Cc: linux-me...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
---
arch/arm/boot/dts/omap3xxx-clocks.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/omap3xxx-clocks.dtsi
b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
index e47ff69..5c37500 100644
--- a/arch/arm/boot/dts/omap3xxx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
@@ -467,6 +467,7 @@
ti,bit-shift = 0x1e;
reg = 0x0d00;
ti,set-bit-to-disable;
+ ti,set-rate-parent;
};
dpll4_m6_ck: dpll4_m6_ck {
--
2.0.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/5] Add gta04 board variants
* Marek Belisko ma...@goldelico.com [140714 13:22]: This patch series completes the GTA04 device tree to describe all hardware components that are on the different variants of the GTA04 boards. Marek Belisko (5): arm: dts: omap3-gta04: Add missing nodes to fully describe gta04 board arm: dts: omap3-gta04: Rename gta04.dts to gta04.dtsi and add a4 model arm: dts: Add gta04a3 model arm: dts: Add gta04+b2 model bindings arm: dts: Add gta04+b3 model bindings Hmm at least the first patch won't apply: Hunk #4 FAILED at 143. Hunk #5 succeeded at 142 with fuzz 2 (offset -26 lines). Hunk #6 succeeded at 287 (offset -26 lines). Hunk #7 succeeded at 364 (offset -26 lines). Hunk #8 succeeded at 433 (offset -26 lines). Hunk #9 succeeded at 472 (offset -26 lines). Hunk #10 succeeded at 485 (offset -26 lines). Hunk #11 succeeded at 556 (offset -26 lines). Hunk #12 FAILED at 720. 2 out of 12 hunks FAILED -- rejects in file arch/arm/boot/dts/omap3-gta04.dts Can you please repost against let's say v3.16-rc1? Maybe also check they apply cleanly against omap-for-v3.17/dt branch that I just pushed out to: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap omap-for-v3.17/dt Thanks, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] arm: dts: omap3-gta04: Add missing nodes to fully describe gta04 board
Hi Marek,
You seem to add some DT nodes for hw that doesn't have drivers in
mainline. I think you should leave those out until the driver itself
is upstream and the bindings for it is documented.
On 14 July 2014 22:20, Marek Belisko ma...@goldelico.com wrote:
Signed-off-by: Marek Belisko ma...@goldelico.com
Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
---
arch/arm/boot/dts/omap3-gta04.dts | 443
+++---
1 file changed, 412 insertions(+), 31 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-gta04.dts
b/arch/arm/boot/dts/omap3-gta04.dts
index 215513b..bd6a71d 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -12,7 +12,7 @@
#include omap36xx.dtsi
/ {
- model = OMAP3 GTA04;
+ model = Goldelico GTA04;
compatible = ti,omap3-gta04, ti,omap36xx, ti,omap3;
cpus {
@@ -26,6 +26,11 @@
reg = 0x8000 0x2000; /* 512 MB */
};
+ aliases {
+ display0 = lcd;
+ display1 = tv0;
+ };
+
gpio-keys {
compatible = gpio-keys;
@@ -37,15 +42,78 @@
};
};
+ gpio-keys-wwan-wakeup {
+ compatible = gpio-keys;
+
+ wwan_wakeup_button: wwan-wakeup-button {
+ label = 3G_WOE;
+ linux,code = 240;
+ gpios = gpio1 10 GPIO_ACTIVE_HIGH;
+ gpio-key,wakeup;
+ };
+ };
+
+ hsusb2_phy: hsusb2_phy {
+ compatible = usb-nop-xceiv;
+ reset-gpios = gpio6 14 GPIO_ACTIVE_LOW; /* gpio_174 =
reset for USB3322 */
+ };
+
+ antenna-detect {
+ compatible = linux,extcon-gpio;
+ label = gps_antenna;
+ gpios = gpio5 16 0; /* gpio_144 */
+ debounce-delay-ms = 10;
+ irq-flags = IRQ_TYPE_EDGE_BOTH;
+ state-on = external;
+ state-off = internal;
+ };
+
sound {
compatible = ti,omap-twl4030;
ti,model = gta04;
ti,mcbsp = mcbsp2;
ti,codec = twl_audio;
+
+ ti,mcbsp-voice = mcbsp4;
+ };
+
+ sound_card {
+ compatible = goldelico,gta04-audio;
+ gta04,cpu-dai = mcbsp2;
+ };
+
+ gtm601_codec: voice_codec {
+ compatible = gtm601-codec;
+ };
+
+ sound_voice {
+ compatible = goldelico,gta04-voice;
+ gta04,cpu-dai = mcbsp4;
+ gta04,codec = gtm601_codec;
};
- spi_lcd {
+ w2cbw003_codec: headset_codec {
+ compatible = w2cbw003-codec;
+ };
+
+ sound_headset {
+ compatible = goldelico,gta04-headset;
+ gta04,cpu-dai = mcbsp3;
+ gta04,codec = w2cbw003_codec;
+ };
+
+ sound_fm {
+ compatible = goldelico,gta04-fm;
+ gta04,cpu-dai = mcbsp1;
+ gta04,codec = si4721_codec;
+ };
+
+ madc-hwmon {
+ compatible = ti,twl4030-madc-hwmon;
+ };
+
+ spi_lcd: spi_lcd {
compatible = spi-gpio;
#address-cells = 0x1;
#size-cells = 0x0;
@@ -75,7 +143,7 @@
};
};
- battery {
+ madc_battery: battery {
compatible = ti,twl4030-madc-battery;
capacity = 120;
charging-calibration-data = 4200 100
@@ -100,6 +168,83 @@
ichg,
vbat;
};
+
+ backlight {
+ compatible = pwm-backlight;
+ pwms = pwm 0 200;
+ brightness-levels = 0 11 20 30 40 50 60 70 80 90 100;
+ default-brightness-level = 10;
+ pinctrl-names = default;
+ pintcrl-0 = backlight_pins;
+ power-supply = power;
+ };
+
+ pwm: omap_pwm {
+ compatible = ti,omap-pwm;
+ timers = timer11;
+ #pwm-cells = 2;
+ };
The omap-pwm driver is not yet upstream and thus the bindings are not final.
+ /* should be a PWM */
+ power: fixed_regulator@0 {
+ compatible = regulator-fixed;
+ regulator-name = bl-enable;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 100;
+ gpio = gpio2 25 0;/* GPT11/PWM */
+ enable-active-high;
+ };
+
+ tv0: connector@1 {
+ compatible = svideo-connector;
+ label = tv;
+
+ port {
+
Re: gpio-omap: wakeup mask
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09.07.2014 17:24, Tony Lindgren wrote:
* Pascal Huerst pascal.hue...@gmail.com [140709 05:47]:
On 09.07.2014 12:41, Tony Lindgren wrote:
If you just comment out the _gpio_rmw part above do things work
as expected?
Yes. It only wakes up on gpio 6 not on gpio 11 anymore.
Then if that works as expected, maybe write only some unused
bits into wkup_en register and see if it still wakes to all
events while it should not?
If I use the following testcode, everything works as expected:
//WARN(true, WARN: bank-base = %08X\n, bank-base);
if (likely(!(bank-non_wakeup_gpios gpio_bit))) {
//_gpio_rmw(base, bank-regs-wkup_en, gpio_bit, trigger != 0);
writel(0xABC0, base + bank-regs-wkup_en);
bank-context.wake_en = readl_relaxed(bank-base +
bank-regs-wkup_en); printk(bank-base = %08X gpio = %i
bank-context-wake_en = %08X\n, bank-base, gpio,
bank-context.wake_en); }
Hmm weird. It sounds like something like the following is
happening:
1. The first GPIO bank is always powered, and does not need to set
wake-up events
I dont think so. If I apply my hack (commenting the _gpio_rmw() call)
and don't have a wakeup source in the dt, I have to reboot the system,
sonce im not able to wake it up anymore. Or did I miss something?
2. When setting the GPIO wake-up events it seems that enabling any
wake-up event for the first (16?) bits wakes up the system
You might want to check this with some spare GPIOs not in the first
bank and see if you need the wake-up events and if enabling some
bits enables more than one GPIO for wake-up events.
Im not sure if this makes sense, since only the first gpio bank can
act as a wakeup source. So it should not be possible.
thanks!
pascal
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlPFLEYACgkQo7eFcXQQ8U1NcACbBzQiKoU5MO/MLSdrjeg5CaAc
YJcAn3bSthD4ByFOQ31jjOFI1F/HP4Lr
=o4r2
-END PGP SIGNATURE-
--
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 06/10] ARM: DRA7: hwmod_data: Add mailbox hwmod data
* Suman Anna s-a...@ti.com [140711 14:47]:
Add the hwmod data for the 13 instances of the system mailbox
IP in DRA7 SoC. The patch is needed for performing a soft-reset
while configuring the respective mailbox instance, otherwise is
a non-essential change for functionality. The modules are smart
idled on reset, and the IP module mode is hardware controlled.
Cc: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 305
++
1 file changed, 305 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 20b4398..e35f5b1 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -939,6 +939,194 @@ static struct omap_hwmod dra7xx_i2c5_hwmod = {
};
/*
+ * 'mailbox' class
+ *
+ */
+
+static struct omap_hwmod_class_sysconfig dra7xx_mailbox_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .sysc_flags = (SYSC_HAS_RESET_STATUS | SYSC_HAS_SIDLEMODE |
+SYSC_HAS_SOFTRESET),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class dra7xx_mailbox_hwmod_class = {
+ .name = mailbox,
+ .sysc = dra7xx_mailbox_sysc,
+};
Hmm I'm seeing just the following MAILBOX_SYSCONFIG in at least
am57xx TRM:
31:4RESERVED
3:2 SIDLEMODE 0 = force-idle 1 = no-idle, 2 = smart-idle, 3 = reserved
1 RESERVED
0 SOFTRESET
So it seems that SYSC_HAS_RESET_STATUS above is wrong? Can you guys
please check.
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: gpio-omap: wakeup mask
* Pascal Huerst pascal.hue...@gmail.com [140715 06:29]:
On 09.07.2014 17:24, Tony Lindgren wrote:
* Pascal Huerst pascal.hue...@gmail.com [140709 05:47]:
On 09.07.2014 12:41, Tony Lindgren wrote:
If you just comment out the _gpio_rmw part above do things work
as expected?
Yes. It only wakes up on gpio 6 not on gpio 11 anymore.
Then if that works as expected, maybe write only some unused
bits into wkup_en register and see if it still wakes to all
events while it should not?
If I use the following testcode, everything works as expected:
//WARN(true, WARN: bank-base = %08X\n, bank-base);
if (likely(!(bank-non_wakeup_gpios gpio_bit))) {
//_gpio_rmw(base, bank-regs-wkup_en, gpio_bit, trigger != 0);
writel(0xABC0, base + bank-regs-wkup_en);
bank-context.wake_en = readl_relaxed(bank-base +
bank-regs-wkup_en); printk(bank-base = %08X gpio = %i
bank-context-wake_en = %08X\n, bank-base, gpio,
bank-context.wake_en); }
Hmm weird. It sounds like something like the following is
happening:
1. The first GPIO bank is always powered, and does not need to set
wake-up events
I dont think so. If I apply my hack (commenting the _gpio_rmw() call)
and don't have a wakeup source in the dt, I have to reboot the system,
sonce im not able to wake it up anymore. Or did I miss something?
Well this just from my head without looking at the code, so please
check..
When you comment out the _gpio_rmw() call you are not configuring
any GPIO bank wake-up events.
And the .dts entry just manages the keypad wake-up event for
suspend and resume and does not affect the GPIO bank after you
commented out the _gpio_rmw().
2. When setting the GPIO wake-up events it seems that enabling any
wake-up event for the first (16?) bits wakes up the system
You might want to check this with some spare GPIOs not in the first
bank and see if you need the wake-up events and if enabling some
bits enables more than one GPIO for wake-up events.
Im not sure if this makes sense, since only the first gpio bank can
act as a wakeup source. So it should not be possible.
Usually on omaps the first GPIO bank is always powered but also
the other banks can provide wake-up events for most GPIOs
via the IO chain path. I think on am335x, there is no IO chain
path, maybe because of the support for dual voltage IO? So yeah
it could be that only the first GPIO bank can wake up the system
on am335x.
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 06/10] ARM: DRA7: hwmod_data: Add mailbox hwmod data
Hi Tony,
On 07/15/2014 08:30 AM, Tony Lindgren wrote:
* Suman Anna s-a...@ti.com [140711 14:47]:
Add the hwmod data for the 13 instances of the system mailbox
IP in DRA7 SoC. The patch is needed for performing a soft-reset
while configuring the respective mailbox instance, otherwise is
a non-essential change for functionality. The modules are smart
idled on reset, and the IP module mode is hardware controlled.
Cc: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 305
++
1 file changed, 305 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 20b4398..e35f5b1 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -939,6 +939,194 @@ static struct omap_hwmod dra7xx_i2c5_hwmod = {
};
/*
+ * 'mailbox' class
+ *
+ */
+
+static struct omap_hwmod_class_sysconfig dra7xx_mailbox_sysc = {
+.rev_offs = 0x,
+.sysc_offs = 0x0010,
+.sysc_flags = (SYSC_HAS_RESET_STATUS | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET),
+.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+.sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class dra7xx_mailbox_hwmod_class = {
+.name = mailbox,
+.sysc = dra7xx_mailbox_sysc,
+};
Hmm I'm seeing just the following MAILBOX_SYSCONFIG in at least
am57xx TRM:
31:4 RESERVED
3:2 SIDLEMODE 0 = force-idle 1 = no-idle, 2 = smart-idle, 3 = reserved
1 RESERVED
0 SOFTRESET
So it seems that SYSC_HAS_RESET_STATUS above is wrong? Can you guys
please check.
The same SOFTRESET bit is used for both triggering the softreset and
reading the reset done status. Once you write a 1 to trigger a reset,
the bit will be cleared once the reset is done. This is no different
from OMAP4. The logic in _wait_softreset_complete in omap_hwmod.c was
already designed to work with this properly.
regards
Suman
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH 5/5] ARM: dts: am437x-sk-evm: add vpfe support and ov2659 sensor
From: Darren Etheridge detheri...@ti.com
Adding necessary dts nodes to enable vpfe and ov2659 sensor on the correct i2c
bus and correct vpfe instance.
Signed-off-by: Darren Etheridge detheri...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/boot/dts/am437x-sk-evm.dts | 63 +
1 file changed, 63 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts
b/arch/arm/boot/dts/am437x-sk-evm.dts
index 859ff3d..ca6b4fe 100644
--- a/arch/arm/boot/dts/am437x-sk-evm.dts
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -184,6 +184,46 @@
;
};
+ vpfe0_pins_default: vpfe0_pins_default {
+ pinctrl-single,pins =
+ 0x1b0 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_hd mode
0*/
+ 0x1b4 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_vd mode
0*/
+ 0x1b8 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_field
mode 0*/
+ 0x1bc (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_wen mode
0*/
+ 0x1c0 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_pclk mode
0*/
+ 0x1c4 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_data8
mode 0*/
+ 0x1c8 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_data9
mode 0*/
+ 0x208 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_data0
mode 0*/
+ 0x20c (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_data1
mode 0*/
+ 0x210 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_data2
mode 0*/
+ 0x214 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_data3
mode 0*/
+ 0x218 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_data4
mode 0*/
+ 0x21c (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_data5
mode 0*/
+ 0x220 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_data6
mode 0*/
+ 0x224 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_data7
mode 0*/
+ ;
+ };
+
+ vpfe0_pins_sleep: vpfe0_pins_sleep {
+ pinctrl-single,pins =
+ 0x1b0 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7)
+ 0x1b4 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7)
+ 0x1b8 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7)
+ 0x1bc (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7)
+ 0x1c0 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7)
+ 0x1c4 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7)
+ 0x1c8 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7)
+ 0x208 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7)
+ 0x20c (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7)
+ 0x210 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7)
+ 0x214 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7)
+ 0x218 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7)
+ 0x21c (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7)
+ 0x220 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7)
+ 0x224 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7)
+ ;
+ };
+
cpsw_default: cpsw_default {
pinctrl-single,pins =
/* Slave 1 */
@@ -611,3 +655,22 @@
wdt {
status = okay;
};
+
+
+vpfe0 {
+ status = okay;
+ pinctrl-names = default, sleep;
+ pinctrl-0 = vpfe0_pins_default;
+ pinctrl-1 = vpfe0_pins_sleep;
+
+ /* Camera port */
+ port {
+ vpfe0_ep: endpoint {
+ /* remote-endpoint = sensor; add once we have it */
+ if_type = 2;
+ bus_width = 8;
+ hdpol = 0;
+ vdpol = 0;
+ };
+ };
+};
--
2.0.0.390.gcb682f8
--
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/PATCH 2/5] arm: omap: hwmod: add hwmod entries for AM437x VPFE
From: Benoit Parrot bpar...@ti.com
HWMOD entries support for TI Dual Video Processing Front
End (VPFE) (aka Dual cam) of AM43xx platform.
Signed-off-by: Benoit Parrot bpar...@ti.com
Signed-off-by: Darren Etheridge detheri...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 56 ++
arch/arm/mach-omap2/prcm43xx.h | 3 +-
2 files changed, 58 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index fea01aa..bd9067e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -483,6 +483,44 @@ static struct omap_hwmod am43xx_dss_rfbi_hwmod = {
},
};
+static struct omap_hwmod_class_sysconfig am43xx_vpfe_sysc = {
+ .rev_offs = 0x0,
+ .sysc_offs = 0x104,
+ .sysc_flags = SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE,
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_SMART | MSTANDBY_NO),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class am43xx_vpfe_hwmod_class = {
+ .name = vpfe,
+ .sysc = am43xx_vpfe_sysc,
+};
+
+static struct omap_hwmod am43xx_vpfe0_hwmod = {
+ .name = vpfe0,
+ .class = am43xx_vpfe_hwmod_class,
+ .clkdm_name = l3s_clkdm,
+ .prcm = {
+ .omap4 = {
+ .modulemode = MODULEMODE_SWCTRL,
+ .clkctrl_offs = AM43XX_CM_PER_VPFE0_CLKCTRL_OFFSET,
+ },
+ },
+};
+
+static struct omap_hwmod am43xx_vpfe1_hwmod = {
+ .name = vpfe1,
+ .class = am43xx_vpfe_hwmod_class,
+ .clkdm_name = l3s_clkdm,
+ .prcm = {
+ .omap4 = {
+ .modulemode = MODULEMODE_SWCTRL,
+ .clkctrl_offs = AM43XX_CM_PER_VPFE1_CLKCTRL_OFFSET,
+ },
+ },
+};
+
/* Interfaces */
static struct omap_hwmod_ocp_if am43xx_l3_main__l4_hs = {
.master = am33xx_l3_main_hwmod,
@@ -750,6 +788,22 @@ static struct omap_hwmod_ocp_if am43xx_l4_ls__dss_rfbi = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_ocp_if am43xx_l3__vpfe0 = {
+ .master = am33xx_l3_main_hwmod,
+ .slave = am43xx_vpfe0_hwmod,
+ .clk= l3_gclk,
+ .flags = OCPIF_SWSUP_IDLE,
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l3__vpfe1 = {
+ .master = am33xx_l3_main_hwmod,
+ .slave = am43xx_vpfe1_hwmod,
+ .clk= l3_gclk,
+ .flags = OCPIF_SWSUP_IDLE,
+ .user = OCP_USER_MPU,
+};
+
static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = {
am33xx_l4_wkup__synctimer,
am43xx_l4_ls__timer8,
@@ -848,6 +902,8 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[]
__initdata = {
am43xx_l4_ls__dss,
am43xx_l4_ls__dss_dispc,
am43xx_l4_ls__dss_rfbi,
+ am43xx_l3__vpfe0,
+ am43xx_l3__vpfe1,
NULL,
};
diff --git a/arch/arm/mach-omap2/prcm43xx.h b/arch/arm/mach-omap2/prcm43xx.h
index ad7b3e9..8aa4c2c 100644
--- a/arch/arm/mach-omap2/prcm43xx.h
+++ b/arch/arm/mach-omap2/prcm43xx.h
@@ -143,5 +143,6 @@
#define AM43XX_CM_PER_USB_OTG_SS1_CLKCTRL_OFFSET0x0268
#define AM43XX_CM_PER_USBPHYOCP2SCP1_CLKCTRL_OFFSET0x05C0
#define AM43XX_CM_PER_DSS_CLKCTRL_OFFSET 0x0a20
-
+#define AM43XX_CM_PER_VPFE0_CLKCTRL_OFFSET 0x0068
+#define AM43XX_CM_PER_VPFE1_CLKCTRL_OFFSET 0x0070
#endif
--
2.0.0.390.gcb682f8
--
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/PATCH 0/5] Add Video Processing Front End Support
Hi all, the following patches add suport for AM43xx's Video Processing Front End (VPFE). Full documentation is available at [1] chapter 14. This driver has been tested with linux-next from yesterday, plus my (already queued) am437x starter kit patches, plus these patches, plus the sensor driver which, saddly enough, we're not allowed to release :-( This driver has almost full v4l2-compliance with only 2 failures (I'll take hints on how to properly fix them) as below: fail: v4l2-compliance.cpp(419): !doioctl(node2, VIDIOC_S_PRIORITY, prio) test VIDIOC_G/S_PRIORITY: FAIL fail: v4l2-test-formats.cpp(319): pixelformat != V4L2_PIX_FMT_JPEG colorspace == V4L2_COLORSPACE_JPEG fail: v4l2-test-formats.cpp(418): testColorspace(pix.pixelformat, pix.colorspace) test VIDIOC_G_FMT: FAIL I have also tested with gst-launch using fbdevsink and I can see my ugly mug just fine. Please give this a thorough review and let me know of any problems which need to be sorted out and I'll try to help out as time allows. cheers [1] http://www.ti.com/lit/pdf/spruhl7 Benoit Parrot (4): Media: platform: Add ti-vpfe driver for AM437x device arm: omap: hwmod: add hwmod entries for AM437x VPFE arm: boot: dts: am4372: add vpfe DTS entries arm: dts: am43x-epos: Add VPFE DTS entries Darren Etheridge (1): ARM: dts: am437x-sk-evm: add vpfe support and ov2659 sensor arch/arm/boot/dts/am4372.dtsi | 16 + arch/arm/boot/dts/am437x-sk-evm.dts | 63 + arch/arm/boot/dts/am43x-epos-evm.dts | 54 + arch/arm/mach-omap2/omap_hwmod_43xx_data.c| 56 + arch/arm/mach-omap2/prcm43xx.h|3 +- drivers/media/platform/Kconfig|1 + drivers/media/platform/Makefile |2 + drivers/media/platform/ti-vpfe/Kconfig| 12 + drivers/media/platform/ti-vpfe/Makefile |2 + drivers/media/platform/ti-vpfe/am437x_isif.c | 1053 + drivers/media/platform/ti-vpfe/am437x_isif.h | 355 +++ drivers/media/platform/ti-vpfe/am437x_isif_regs.h | 144 ++ drivers/media/platform/ti-vpfe/vpfe_capture.c | 2478 + drivers/media/platform/ti-vpfe/vpfe_capture.h | 263 +++ 14 files changed, 4501 insertions(+), 1 deletion(-) create mode 100644 drivers/media/platform/ti-vpfe/Kconfig create mode 100644 drivers/media/platform/ti-vpfe/Makefile create mode 100644 drivers/media/platform/ti-vpfe/am437x_isif.c create mode 100644 drivers/media/platform/ti-vpfe/am437x_isif.h create mode 100644 drivers/media/platform/ti-vpfe/am437x_isif_regs.h create mode 100644 drivers/media/platform/ti-vpfe/vpfe_capture.c create mode 100644 drivers/media/platform/ti-vpfe/vpfe_capture.h -- 2.0.0.390.gcb682f8 -- 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/PATCH 3/5] arm: boot: dts: am4372: add vpfe DTS entries
From: Benoit Parrot bpar...@ti.com
Add Video Processing Front End (VPFE) device tree
nodes for AM34xx family of devices.
Signed-off-by: Benoit Parrot bpar...@ti.com
Signed-off-by: Darren Etheridge detheri...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 8d3c163..b25ae13 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -888,6 +888,22 @@
clock-names = fck;
};
};
+
+ vpfe0: vpfe@48326000 {
+ compatible = ti,am437x-vpfe;
+ reg = 0x48326000 0x2000;
+ interrupts = GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = vpfe0;
+ status = disabled;
+ };
+
+ vpfe1: vpfe@48328000 {
+ compatible = ti,am437x-vpfe;
+ reg = 0x48328000 0x2000;
+ interrupts = GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = vpfe1;
+ status = disabled;
+ };
};
};
--
2.0.0.390.gcb682f8
--
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/PATCH 4/5] arm: dts: am43x-epos: Add VPFE DTS entries
From: Benoit Parrot bpar...@ti.com
Add Video Processing Front End (VPFE) device tree nodes for AM43x-epos.
Signed-off-by: Benoit Parrot bpar...@ti.com
Signed-off-by: Darren Etheridge detheri...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/boot/dts/am43x-epos-evm.dts | 54
1 file changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
index 90098f9..ac9a4cc 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -243,6 +243,42 @@
0x08C (PIN_OUTPUT_PULLUP | MUX_MODE7)
;
};
+
+ vpfe1_pins_default: vpfe1_pins_default {
+ pinctrl-single,pins =
+ 0x1cc (PIN_INPUT_PULLUP | MUX_MODE0) /*
cam1_data9 mode 0 */
+ 0x1d0 (PIN_INPUT_PULLUP | MUX_MODE0) /*
cam1_data8 mode 0 */
+ 0x1d4 (PIN_INPUT_PULLUP | MUX_MODE0) /*
cam1_hd mode 0 */
+ 0x1d8 (PIN_INPUT_PULLUP | MUX_MODE0) /*
cam1_vd mode 0 */
+ 0x1dc (PIN_INPUT_PULLUP | MUX_MODE0) /*
cam1_pclk mode 0 */
+ 0x1e8 (PIN_INPUT_PULLUP | MUX_MODE0) /*
cam1_data0 mode 0 */
+ 0x1ec (PIN_INPUT_PULLUP | MUX_MODE0) /*
cam1_data1 mode 0 */
+ 0x1f0 (PIN_INPUT_PULLUP | MUX_MODE0) /*
cam1_data2 mode 0 */
+ 0x1f4 (PIN_INPUT_PULLUP | MUX_MODE0) /*
cam1_data3 mode 0 */
+ 0x1f8 (PIN_INPUT_PULLUP | MUX_MODE0) /*
cam1_data4 mode 0 */
+ 0x1fc (PIN_INPUT_PULLUP | MUX_MODE0) /*
cam1_data5 mode 0 */
+ 0x200 (PIN_INPUT_PULLUP | MUX_MODE0) /*
cam1_data6 mode 0 */
+ 0x204 (PIN_INPUT_PULLUP | MUX_MODE0) /*
cam1_data7 mode 0 */
+ ;
+ };
+
+ vpfe1_pins_sleep: vpfe1_pins_sleep {
+ pinctrl-single,pins =
+ 0x1cc (DS0_PULL_UP_DOWN_EN | INPUT_EN |
MUX_MODE7)
+ 0x1d0 (DS0_PULL_UP_DOWN_EN | INPUT_EN |
MUX_MODE7)
+ 0x1d4 (DS0_PULL_UP_DOWN_EN | INPUT_EN |
MUX_MODE7)
+ 0x1d8 (DS0_PULL_UP_DOWN_EN | INPUT_EN |
MUX_MODE7)
+ 0x1dc (DS0_PULL_UP_DOWN_EN | INPUT_EN |
MUX_MODE7)
+ 0x1e8 (DS0_PULL_UP_DOWN_EN | INPUT_EN |
MUX_MODE7)
+ 0x1ec (DS0_PULL_UP_DOWN_EN | INPUT_EN |
MUX_MODE7)
+ 0x1f0 (DS0_PULL_UP_DOWN_EN | INPUT_EN |
MUX_MODE7)
+ 0x1f4 (DS0_PULL_UP_DOWN_EN | INPUT_EN |
MUX_MODE7)
+ 0x1f8 (DS0_PULL_UP_DOWN_EN | INPUT_EN |
MUX_MODE7)
+ 0x1fc (DS0_PULL_UP_DOWN_EN | INPUT_EN |
MUX_MODE7)
+ 0x200 (DS0_PULL_UP_DOWN_EN | INPUT_EN |
MUX_MODE7)
+ 0x204 (DS0_PULL_UP_DOWN_EN | INPUT_EN |
MUX_MODE7)
+ ;
+ };
};
matrix_keypad: matrix_keypad@0 {
@@ -568,3 +604,21 @@
};
};
};
+
+vpfe1 {
+ status = okay;
+ pinctrl-names = default, sleep;
+ pinctrl-0 = vpfe1_pins_default;
+ pinctrl-1 = vpfe1_pins_sleep;
+
+ /* Camera port */
+ port {
+ vpfe1_ep: endpoint {
+ /* remote-endpoint = sensor; add once we have it */
+ if_type = 2;
+ bus_width = 8;
+ hdpol = 0;
+ vdpol = 0;
+ };
+ };
+};
--
2.0.0.390.gcb682f8
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 5/5] ARM: dts: am437x-sk-evm: add vpfe support and ov2659 sensor
Hi, On Tue, Jul 15, 2014 at 12:56:52PM -0500, Felipe Balbi wrote: From: Darren Etheridge detheri...@ti.com Adding necessary dts nodes to enable vpfe and ov2659 sensor on the correct i2c clearly this doesn't add ov2659 sensor support because we can't release the driver for it. I'll fix the patch subject and commit log locally. -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 03/11] ARM: OMAP2+: timer: Add suspend-resume callbacks for clkevent device
On 07/15/2014 01:48 AM, Tony Lindgren wrote:
* Dave Gerlach d-gerl...@ti.com [140714 10:44]:
Santosh, Tony,
On 07/14/2014 09:37 AM, Santosh Shilimkar wrote:
On Monday 14 July 2014 07:15 AM, Tony Lindgren wrote:
* Dave Gerlach d-gerl...@ti.com [140710 19:59]:
From: Vaibhav Bedia vaibhav.be...@ti.com
OMAP timer code registers two timers - one as clocksource
and one as clockevent. Since AM33XX has only one usable timer
in the WKUP domain one of the timers needs suspend-resume
support to restore the configuration to pre-suspend state.
commit adc78e6 (timekeeping: Add suspend and resume
of clock event devices) introduced .suspend and .resume
callbacks for clock event devices. Leverages these
callbacks to have AM33XX clockevent timer which is
in not in WKUP domain to behave properly across system
suspend.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
v3-v4:
Only use for am33xx soc now.
arch/arm/mach-omap2/timer.c | 28
1 file changed, 28 insertions(+)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 43d03fb..6fc1748 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -128,6 +128,29 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode
mode,
}
}
+static void omap_clkevt_suspend(struct clock_event_device *unused)
+{
+ struct omap_hwmod *oh;
+
+ oh = omap_hwmod_lookup(clockevent_gpt.name);
+ if (!oh)
+ return;
+
+ omap_hwmod_idle(oh);
+}
+
+static void omap_clkevt_resume(struct clock_event_device *unused)
+{
+ struct omap_hwmod *oh;
+
+ oh = omap_hwmod_lookup(clockevent_gpt.name);
+ if (!oh)
+ return;
+
+ omap_hwmod_enable(oh);
+ __omap_dm_timer_int_enable(clkev, OMAP_TIMER_INT_OVERFLOW);
+}
+
This is going to make moving the timer code into drivers one step
tougher to do. And you don't need to look up the hwmod entry every
time, just initialize it during the init.
Yes you are right about looking up only at init I need to change that. I
agree that this makes moving the timers harder but I'm not sure there's any
way around this. I attempted to use the omap_device layer here but there is
no device at all created here, it does not hook into the normal PM layer
through omap_device. This clock must be shut off as it sits in the
peripheral power domain and any active clock within the domain will prevent
suspend from happening, so we end up with a platform specific issue here. It
seems that the only way I can get to the clock is through the hwmod.
It's best to register these kind of functions as platform_data
in pdata-quirks.c auxdata. That way when this moves to live
in drivers/clocksource the driver does not need to know anything
about the interconnect specific registers.
Also, please don't use Linux generic names here.. Maybe use
omap_clkevt_idle/unidle? The linux suspend and resume hooks
and runtime PM could all use these functions then.
Ok to both of the above, I definitely like your suggestion better.
Regards,
Dave
+ if (soc_is_am33xx()) {
+ clockevent_gpt.suspend = omap_clkevt_suspend;
+ clockevent_gpt.resume = omap_clkevt_resume;
+ }
+
Maybe try to set up things so we initialize the SoC specific
timer suspend and resume functions in mach-omap2/timer.c
in a way where eventually the device driver can easily use
them?
+1. I had similar comments on the previous version too.
This was my attempt to make things specific to only am335x based on
Santosh's previous comments as last time they were populated for every
device even when unneeded. These are not standard suspend/resume handlers,
they are specific to clock event. I know there will always need to be at
least some code here for the early timer init based on previous timer
cleanup series I've seen, so perhaps I could hook it in there when the time
comes?
Well just adding a minimal include/linux/platform_data/timer-omap.h
to pass those function pointers to the driver should do the trick.
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 01/12] ARM: OMAP2+: Remove non working OMAP HDMI audio initialization
On 07/08/2014 11:09 AM, Tony Lindgren wrote: * Peter Ujfalusi peter.ujfal...@ti.com [140708 00:32]: Hi Tony, On 07/07/2014 02:46 PM, Tony Lindgren wrote: * Jyri Sarha jsa...@ti.com [140626 12:26]: This code is not working currently and it can be removed. There is a conflict in sharing resources with the actual HDMI driver and with the ASoC HDMI audio DAI driver. Is this OK to queue for v3.17 or do we need this for v3.16-rc series? Jyri is away currently, but I think it would be great if this patch goes in for 3.16. The patch does not introduce regression since the OMAP4/5 HDMI is in non working state in the kernel so removing the platform device right now will ease up the merger of the new and working code. OK, will apply it into omap-for-v3.16/fixes as it just removes broken code. Thanks Tony and Peter! -- 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: [RFT/RFC/PATCH 00/31] arm: omap: irq: cleanup INTC driver
On Tue, Jul 15, 2014 at 02:14:35AM -0700, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [140103 08:43]:
On Fri, Jan 03, 2014 at 05:42:41PM +0530, Rajendra Nayak wrote:
[]..
so a bit more work is needed. Maybe also rebase these against
omap-for-v3.14/dt too?
Will do.
Rebased on top of omap-for-v3.14/omap3-board-removal. Patches are on my
k.org tree:
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
wip/omap-fix-intc
It needs a minor build fix though..
diff --git a/drivers/irqchip/irq-omap-intc.c
b/drivers/irqchip/irq-omap-intc.c
index b58c5d5..d03b5a3 100644
--- a/drivers/irqchip/irq-omap-intc.c
+++ b/drivers/irqchip/irq-omap-intc.c
@@ -151,7 +151,7 @@ static void omap_mask_ack_irq(struct irq_data *d)
static void omap_suspend_irq(struct irq_data *d)
{
omap_intc_save_context();
- omap3_intc_prepare_idle();
+ omap_intc_prepare_idle();
fixed now, thanks. Wonder how come I didn't see that, I was building
every commit with omap2plus_defconfig :-( Oh well...
Felipe, care to refresh this series against v3.16-rc4 and
repost? We now finally have the DT based booting working for
PM for omap3 the same way as legacy booting so I can test
this easily for regressions. But I don't seem to have the
patches in my mailbox any longer.
not sure when I'll have time to work on this again, but I'll add it to
my TODO list.
--
balbi
signature.asc
Description: Digital signature
Re: OMAP baseline test results for v3.16-rc4
On Mon, 14 Jul 2014, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [140714 10:32]: On Mon, 7 Jul 2014, Tony Lindgren wrote: With v3.16-rc4 the PM features for omap3 should be working finally for device tree based booting. At lest beaglexm and 3xxevm should work. Maybe you are using legacy booting path to idle the UARTs still? FYI, I'm doing this to find the UART entries: uarts=$(find /sys/class/tty/ttyO*/device/power/ -type d) for uart in $uarts; do echo 3000 $uart/autosuspend_delay_ms done uarts=$(find /sys/class/tty/ttyO*/power/ -type d) for uart in $uarts; do echo enabled $uart/wakeup echo auto $uart/control done echo 1 /sys/kernel/debug/pm_debug/enable_off_mode OK thanks, I'll take a close look at it. It's not using the legacy paths, but based on a glance at the 37xxevm logs, it looks like the bus address of the UART isn't right. Hmm for which UART? I'm using ttyO2 on my 37xxevm FYI, it can be selected on the board based on some switch settings. I may have patched my u-boot for that too but don't remember for sure. Sorry, I should have been more specific. The path name that the script here was using to write to the 'wakeup' file contained the base address. It's probably just best to set them via /sys/class/tty as you do. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/13] ARM: OMAP2+: clock cleanup series for 3.17
On Sun, 13 Jul 2014, Mike Turquette wrote: Quoting Tero Kristo (2014-07-02 01:47:34) Hi, This sets cleans up some of the omap specific clock drivers still residing under arch/arm/mach-omap2. This set is done in preparation to migrate these drivers eventually under drivers/clk/ti, where we don't have access to certain board specific functionality. The basic idea of this set is to introduce clk_features struct which contains any SoC specific data / flags within it, and this is used runtime instead of the current cpu_is_? checks. Reviewed-by: Mike Turquette mturque...@linaro.org Thanks, queued for 3.17 with the exception of patch 1 which was previously queued. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] arm: dra7xx: Add hwmod data for pcie1 and pcie2 subsystems
On Mon, 14 Jul 2014, Kishon Vijay Abraham I wrote: On Wednesday 09 July 2014 04:32 PM, Rajendra Nayak wrote: On Wednesday 09 July 2014 02:32 PM, Kishon Vijay Abraham I wrote: Added hwmod data for pcie1 and pcie2 subsystem present in DRA7xx SOC. Cc: Tony Lindgren t...@atomide.com Cc: Russell King li...@arm.linux.org.uk Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Tested-by: Kishon Vijay Abraham I kis...@ti.com --- Changes from v1: * changed the clock domain to pcie_clkdm * Added PCIe as a slave port for l3_main. Looks good to me, Reviewed-by: Rajendra Nayak rna...@ti.com Paul, Can you pick this one? Yep, queued for 3.17. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: omap: hwmod: drop unnecessary list initialization
ml-node and sl-node are currently initialized by means of INIT_LIST_HEAD(). That initialiation is followed by a list_add() call. Looking at what both these functions do we will have: ml-node.next = ml-node; ml-node.prev = ml-node; oi-master-master_ports.next.prev = ml-node; ml-node.next = oi-master-master_ports.next; ml-node.prev = oi-master-master_ports; oi-master-master_ports.next = ml-node; from this, it's clear that both INIT_LIST_HEAD() calls are unnecessary and can be safely removed. Signed-off-by: Felipe Balbi ba...@ti.com --- found by code inspection, boot tested on am437x SK on today's linux-next + pending patches. arch/arm/mach-omap2/omap_hwmod.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 6c074f3..8194990 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -2828,12 +2828,10 @@ static int __init _add_link(struct omap_hwmod_ocp_if *oi) _alloc_links(ml, sl); ml-ocp_if = oi; - INIT_LIST_HEAD(ml-node); list_add(ml-node, oi-master-master_ports); oi-master-masters_cnt++; sl-ocp_if = oi; - INIT_LIST_HEAD(sl-node); list_add(sl-node, oi-slave-slave_ports); oi-slave-slaves_cnt++; -- 2.0.1.563.g66f467c -- 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: [Re-send PATCH 1/1] arm: dra7xx: Add hwmod data for MDIO and CPSW
Hi Sebastian, On Wed, 9 Jul 2014, Sebastian Andrzej Siewior wrote: On 2014-07-09 11:55:52 [+0200], Sebastian Andrzej Siewior wrote: On 2014-07-08 18:46:39 [+0530], Mugunthan V N wrote: Adding hwmod data for CPSW and MDIO which is present in DRA7xx SoC I reverted my patch, applied this one and after boot I got: Oh me dum dum. I had --dry-run… Acked-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc This is basically what Tony hasked me to do: No IRQ numbers iomem. Sorry - I'm a bit confused - Sebastian, did you test this one? If so, is it okay to add a Tested-by from you? Mugunthan, could you please get a Reviewed-by: from one of the folks on the DRA7xx SoC integration reviewers list that I sent earlier? - Paul
[PATCH 2/2] ARM: OMAP2+: remove DSP platform device
It was added to support DSP Bridge. Since DSP Bridge was removed, and
nothing else is using the platform device, remove it too.
Signed-off-by: Kristina Martšenko kristina.martse...@gmail.com
Cc: Omar Ramirez Luna omar.rami...@copitl.com
Cc: Suman Anna s-a...@ti.com
Cc: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/mach-omap2/Makefile | 4 -
arch/arm/mach-omap2/common.c | 2 -
arch/arm/mach-omap2/dsp.c | 134 -
include/linux/platform_data/dsp-omap.h | 34 -
4 files changed, 174 deletions(-)
delete mode 100644 arch/arm/mach-omap2/dsp.c
delete mode 100644 include/linux/platform_data/dsp-omap.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 8ca99e9..fa78000 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -232,10 +232,6 @@ obj-$(CONFIG_HW_PERF_EVENTS) += pmu.o
iommu-$(CONFIG_OMAP_IOMMU) := omap-iommu.o
obj-y += $(iommu-m) $(iommu-y)
-ifneq ($(CONFIG_TIDSPBRIDGE),)
-obj-y += dsp.o
-endif
-
# OMAP2420 MSDI controller integration support (MMC)
obj-$(CONFIG_SOC_OMAP2420) += msdi.o
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 2dabb9e..484cdad 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -14,7 +14,6 @@
*/
#include linux/kernel.h
#include linux/init.h
-#include linux/platform_data/dsp-omap.h
#include common.h
#include omap-secure.h
@@ -30,7 +29,6 @@ int __weak omap_secure_ram_reserve_memblock(void)
void __init omap_reserve(void)
{
- omap_dsp_reserve_sdram_memblock();
omap_secure_ram_reserve_memblock();
omap_barrier_reserve_memblock();
}
diff --git a/arch/arm/mach-omap2/dsp.c b/arch/arm/mach-omap2/dsp.c
deleted file mode 100644
index f7492df..000
--- a/arch/arm/mach-omap2/dsp.c
+++ /dev/null
@@ -1,134 +0,0 @@
-/*
- * TI's OMAP DSP platform device registration
- *
- * Copyright (C) 2005-2006 Texas Instruments, Inc.
- * Copyright (C) 2009 Nokia Corporation
- *
- * Written by Hiroshi DOYU hiroshi.d...@nokia.com
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-/*
- * XXX The function pointers to the PRM/CM functions are incorrect and
- * should be removed. No device driver should be changing PRM/CM bits
- * directly; that's a layering violation -- those bits are the responsibility
- * of the OMAP PM core code.
- */
-
-#include linux/module.h
-#include linux/platform_device.h
-
-#include asm/memblock.h
-
-#include control.h
-#include cm2xxx_3xxx.h
-#include prm2xxx_3xxx.h
-#ifdef CONFIG_TIDSPBRIDGE_DVFS
-#include omap-pm.h
-#endif
-#include soc.h
-
-#include linux/platform_data/dsp-omap.h
-
-static struct platform_device *omap_dsp_pdev;
-
-static struct omap_dsp_platform_data omap_dsp_pdata __initdata = {
-#ifdef CONFIG_TIDSPBRIDGE_DVFS
- .dsp_set_min_opp = omap_pm_dsp_set_min_opp,
- .dsp_get_opp = omap_pm_dsp_get_opp,
- .cpu_set_freq = omap_pm_cpu_set_freq,
- .cpu_get_freq = omap_pm_cpu_get_freq,
-#endif
- .dsp_prm_read = omap2_prm_read_mod_reg,
- .dsp_prm_write = omap2_prm_write_mod_reg,
- .dsp_prm_rmw_bits = omap2_prm_rmw_mod_reg_bits,
- .dsp_cm_read = omap2_cm_read_mod_reg,
- .dsp_cm_write = omap2_cm_write_mod_reg,
- .dsp_cm_rmw_bits = omap2_cm_rmw_mod_reg_bits,
-
- .set_bootaddr = omap_ctrl_write_dsp_boot_addr,
- .set_bootmode = omap_ctrl_write_dsp_boot_mode,
-};
-
-static phys_addr_t omap_dsp_phys_mempool_base;
-
-void __init omap_dsp_reserve_sdram_memblock(void)
-{
- phys_addr_t size = CONFIG_TIDSPBRIDGE_MEMPOOL_SIZE;
- phys_addr_t paddr;
-
- if (!cpu_is_omap34xx())
- return;
-
- if (!size)
- return;
-
- paddr = arm_memblock_steal(size, SZ_1M);
- if (!paddr) {
- pr_err(%s: failed to reserve %llx bytes\n,
- __func__, (unsigned long long)size);
- return;
- }
-
- omap_dsp_phys_mempool_base = paddr;
-}
-
-static phys_addr_t omap_dsp_get_mempool_base(void)
-{
- return omap_dsp_phys_mempool_base;
-}
-
-static int __init omap_dsp_init(void)
-{
- struct platform_device *pdev;
- int err = -ENOMEM;
- struct omap_dsp_platform_data *pdata = omap_dsp_pdata;
-
- if (!cpu_is_omap34xx())
- return 0;
-
- pdata-phys_mempool_base = omap_dsp_get_mempool_base();
-
- if (pdata-phys_mempool_base) {
- pdata-phys_mempool_size = CONFIG_TIDSPBRIDGE_MEMPOOL_SIZE;
- pr_info(%s: %llx bytes @ %llx\n, __func__,
- (unsigned long long)pdata-phys_mempool_size,
- (unsigned long
Re: [PATCH] ARM: dts: set 'ti,set-rate-parent' for dpll4_m5x2 clock
Hi Stefan,
Thank you for the patch.
On Tuesday 15 July 2014 12:02:35 Stefan Herbrechtsmeier wrote:
Set 'ti,set-rate-parent' property for the dpll4_m5x2_ck clock, which
is used for the ISP functional clock. This fixes the OMAP3 ISP driver's
clock rate configuration on OMAP34xx, which needs the rate to be
propagated properly to the divider node (dpll4_m5_ck).
Signed-off-by: Stefan Herbrechtsmeier ste...@herbrechtsmeier.net
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Tony Lindgren t...@atomide.com
Cc: Tero Kristo t-kri...@ti.com
Cc: linux-me...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Tero, could you please process it for v3.17 if time still permits ?
---
arch/arm/boot/dts/omap3xxx-clocks.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/omap3xxx-clocks.dtsi
b/arch/arm/boot/dts/omap3xxx-clocks.dtsi index e47ff69..5c37500 100644
--- a/arch/arm/boot/dts/omap3xxx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
@@ -467,6 +467,7 @@
ti,bit-shift = 0x1e;
reg = 0x0d00;
ti,set-bit-to-disable;
+ ti,set-rate-parent;
};
dpll4_m6_ck: dpll4_m6_ck {
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 02/11] memory: emif: Move EMIF register defines to include/linux/
Tony, On 07/15/2014 01:38 AM, Tony Lindgren wrote: * Dave Gerlach d-gerl...@ti.com [140714 10:44]: On 07/14/2014 06:12 AM, Tony Lindgren wrote: * Dave Gerlach d-gerl...@ti.com [140710 19:59]: OMAP4 and AM33XX share the same EMIF controller IP. Although there are significant differences in the IP integration due to which AM33XX can't reuse the EMIF driver DVFS similar to OMAP4, it can definitely benefit by reusing the EMIF related macros defined in drivers/memory/emif.h. In the current OMAP PM framework the PM code resides under arch/arm/mach-omap2/. To enable reuse of the register defines move the register defines in the emif header file to include/linux so that both the EMIF driver and the AM33XX PM code can benefit. Signed-off-by: Dave Gerlach d-gerl...@ti.com Reviewed-by: Russ Dill russ.d...@ti.com Acked-by: Santosh Shililmar santosh.shilim...@ti.com Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org --- v3-v4: patch unchanged from original: http://www.spinics.net/lists/linux-omap/msg95314.html drivers/memory/emif.h | 543 +- include/linux/ti_emif.h | 558 So far we've seen that exposing hardware registers like this will lead into various drivers misusing them. I think a better solution is to implement few targeted functions that allow sharing code between the platform idle code and memory driver. Maybe you can have the shared functions in in something like drivers/memory/ti-emif.c that's always built in? The idle code won't need any of that early on. Well the reason it was done this way was to utilize all of the addresses of EMIF register in the ASM sleep code to do relative addressing from the EMIF base address. The ASM sleep code (patch 9) needs to save and restore emif context and set and unset self refresh in emif. The issues will come from the ASM being copied to and running from SRAM without the ability to access code in DDR (because we are shutting the EMIF off), so we would need to copy these functions as well and have to worry about any issues we introduce by relocating c code. Is it worth the added maintenance burden? Ah right it needs to run in SRAM. There were some relocatable c code patches posted a while back, so it might be worth revisiting that. I think it can also be done with assembly with something like this: 1. Make am335x idle code depends on TI_EMIF WKUP_M3_RPROC 2. Add the memory save and restore assembly functions into drivers/memory/ti-emif-sram.S 3. Allocate the SRAM preferrably with drivers/misc/sram.c instead of the legacy mach-omap2/sram.c This I can do, I will just need to make a change somewhere to make generic sram driver provide sram allocations marked for exec. 4. Map the idle assembly code and EMIF save and restore functions into SRAM 5. Call the EMIF save and restore functions from the idle assembly code at the SRAM locations and pass the save and restore area in a register So basically we need to figure out a generic way to do driver hooks in the PM idle code even very late and early in the assembly code so we can keep most of the code in drivers. Eventually also the idle assembly code should be in the drivers too.. I did not consider this earlier but the cpuidle code will use the same path in the assembly code. The cpuidle configures the suspend path to make the emif actions optional (save and restore with shut off, and self refresh), so a generic solution probably isn't possible here as we (will) need a certain level of granularity of control over the emif actions, and that will be difficult to maintain while keeping the pm functionality out of the EMIF code. Regards, Dave 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 v2] arm: dra7xx: Add hwmod data for pcie1 and pcie2 subsystems
On Wednesday 16 July 2014 01:43 AM, Paul Walmsley wrote: On Mon, 14 Jul 2014, Kishon Vijay Abraham I wrote: On Wednesday 09 July 2014 04:32 PM, Rajendra Nayak wrote: On Wednesday 09 July 2014 02:32 PM, Kishon Vijay Abraham I wrote: Added hwmod data for pcie1 and pcie2 subsystem present in DRA7xx SOC. Cc: Tony Lindgren t...@atomide.com Cc: Russell King li...@arm.linux.org.uk Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Tested-by: Kishon Vijay Abraham I kis...@ti.com --- Changes from v1: * changed the clock domain to pcie_clkdm * Added PCIe as a slave port for l3_main. Looks good to me, Reviewed-by: Rajendra Nayak rna...@ti.com Paul, Can you pick this one? Yep, queued for 3.17. Thanks :-) -Kishon - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 0/8] arm: dts: dra7: Add PCIe data and PCIe PHY data
On Tuesday 15 July 2014 12:48 PM, Tony Lindgren wrote: * Kishon Vijay Abraham I kis...@ti.com [140714 03:44]: [1] is split into separate series in order for individual subsystem Maintainers to pick up the patches. This series handles the PCIe dt data for DRA7. This series has better commit logs than the previous one modified as suggested by Tero. [1] - https://lkml.org/lkml/2014/5/29/258 Keerthy (2): ARM: dts: dra7xx-clocks: Add divider table to optfclk_pciephy_div clock ARM: dts: dra7xx-clocks: Change the parent of apll_pcie_in_clk_mux to dpll_pcie_ref_m2ldo_ck Kishon Vijay Abraham I (6): ARM: dts: dra7xx-clocks: Add missing 32KHz clocks used for PHY ARM: dts: dra7xx-clocks: rename pcie clocks to accommodate second PHY instance ARM: dts: dra7xx-clocks: Add missing clocks for second PCIe PHY instance ARM: dts: dra7: Add dt data for PCIe PHY control module ARM: dts: dra7: Add dt data for PCIe PHY ARM: dts: dra7: Add dt data for PCIe controller arch/arm/boot/dts/dra7.dtsi | 127 ++ arch/arm/boot/dts/dra7xx-clocks.dtsi | 39 ++- 2 files changed, 163 insertions(+), 3 deletions(-) Applying this series into omap-for-v3.17/dt thanks. Thanks :-) -Kishon 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
