Re: am335x: system doesn't reboot after flashing NAND
On 06/04/2014 10:45 PM, Yegor Yefremov wrote: On Wed, Jun 4, 2014 at 12:52 PM, Sekhar Nori nsek...@ti.com wrote: On Wednesday 04 June 2014 04:00 PM, Yegor Yefremov wrote: On Wed, Jun 4, 2014 at 12:20 PM, Sekhar Nori nsek...@ti.com wrote: On Wednesday 04 June 2014 03:11 PM, Yegor Yefremov wrote: On Wed, Jun 4, 2014 at 10:48 AM, Roger Quadros rog...@ti.com wrote: Hi, On 06/04/2014 11:25 AM, Yegor Yefremov wrote: On Wed, Jun 4, 2014 at 8:40 AM, Sekhar Nori nsek...@ti.com wrote: On Tuesday 03 June 2014 04:18 PM, Yegor Yefremov wrote: On Tue, Jun 3, 2014 at 9:57 AM, Yegor Yefremov yegorsli...@googlemail.com wrote: Kernel: 3.14, 3.15 (I haven't tried another kernels) As soon as I write something to my NAND flash (via cat image /dev/mtdblockx or ubiupdatevol) and make reboot or press a reset button, I see only C and nothing happens before I make a power cycle. Any idea? Just forgot to mention, that I was actually booting from MMC (mmc1). The boot sequence is UART0...XIP...MMC0...NAND. Can you try to get XIP out of the boot sequence and see if it works? Maybe try to boot from mmc directly? This would prove that NAND/GPMC driver is leaving some state that doesn't go well with the bootROM XIP. This configuration is soldered. It won't be easy to change. Most likely XIP is the issue if sysboot has not changed. The way ROM works for XIP boot is: 1) Set chip select 0 base address to 0x0800' 2) Read memory at 0x0800' 3) If something else other than 0x0 or ~0x0 is found, jump to 0x0800' and start executing. Can you check to see the contents of 0x0800' before and after nand write using mtdblock? Before writing: # devmem 0x0800 32 0x After writing: # devmem 0x0800 32 0xE0E0E0E0 Okay, so this is the cause of failure to boot. I am not sure what operation by NAND driver causes this value to change. Perhaps you could bisect a bit by dumping this address at various points during the write operation? If you have a debugger it will become easy to do this. The 0x8000 address seems to be the beginning of NAND region: ranges = 0 0 0x0800 0x1000; /* CS0: NAND */ I've taken this example from am335x_evm.dts. I have tried to change the mapping to 0x9000, but kernel still uses 0x8000, Where in the kernel will ranges be evaluated? I'm digging thorugh arch/arm/mach-omap2/gpmc.c and gpmc-nand.c, but didn't really found the place. Well it doesn't. It just uses whatever was setup by the bootloader or randomly allocated by gpmc_cs_request(). I'm working on fixing this up. I should be posting v2 of the GPMC refactor series by this week and you should be able to map the CS region as specified in the DT. Till then, maybe you can pre-configure CS0 in the bootloader to wherever you want or alternatively call gpmc_cs_remap() after the gpmc_cs_request() in gpmc_nand_init(); 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: am335x: system doesn't reboot after flashing NAND
On Thu, Jun 5, 2014 at 12:02 PM, Roger Quadros rog...@ti.com wrote: On 06/04/2014 10:45 PM, Yegor Yefremov wrote: On Wed, Jun 4, 2014 at 12:52 PM, Sekhar Nori nsek...@ti.com wrote: On Wednesday 04 June 2014 04:00 PM, Yegor Yefremov wrote: On Wed, Jun 4, 2014 at 12:20 PM, Sekhar Nori nsek...@ti.com wrote: On Wednesday 04 June 2014 03:11 PM, Yegor Yefremov wrote: On Wed, Jun 4, 2014 at 10:48 AM, Roger Quadros rog...@ti.com wrote: Hi, On 06/04/2014 11:25 AM, Yegor Yefremov wrote: On Wed, Jun 4, 2014 at 8:40 AM, Sekhar Nori nsek...@ti.com wrote: On Tuesday 03 June 2014 04:18 PM, Yegor Yefremov wrote: On Tue, Jun 3, 2014 at 9:57 AM, Yegor Yefremov yegorsli...@googlemail.com wrote: Kernel: 3.14, 3.15 (I haven't tried another kernels) As soon as I write something to my NAND flash (via cat image /dev/mtdblockx or ubiupdatevol) and make reboot or press a reset button, I see only C and nothing happens before I make a power cycle. Any idea? Just forgot to mention, that I was actually booting from MMC (mmc1). The boot sequence is UART0...XIP...MMC0...NAND. Can you try to get XIP out of the boot sequence and see if it works? Maybe try to boot from mmc directly? This would prove that NAND/GPMC driver is leaving some state that doesn't go well with the bootROM XIP. This configuration is soldered. It won't be easy to change. Most likely XIP is the issue if sysboot has not changed. The way ROM works for XIP boot is: 1) Set chip select 0 base address to 0x0800' 2) Read memory at 0x0800' 3) If something else other than 0x0 or ~0x0 is found, jump to 0x0800' and start executing. Can you check to see the contents of 0x0800' before and after nand write using mtdblock? Before writing: # devmem 0x0800 32 0x After writing: # devmem 0x0800 32 0xE0E0E0E0 Okay, so this is the cause of failure to boot. I am not sure what operation by NAND driver causes this value to change. Perhaps you could bisect a bit by dumping this address at various points during the write operation? If you have a debugger it will become easy to do this. The 0x8000 address seems to be the beginning of NAND region: ranges = 0 0 0x0800 0x1000; /* CS0: NAND */ I've taken this example from am335x_evm.dts. I have tried to change the mapping to 0x9000, but kernel still uses 0x8000, Where in the kernel will ranges be evaluated? I'm digging thorugh arch/arm/mach-omap2/gpmc.c and gpmc-nand.c, but didn't really found the place. Well it doesn't. It just uses whatever was setup by the bootloader or randomly allocated by gpmc_cs_request(). I'm working on fixing this up. I should be posting v2 of the GPMC refactor series by this week and you should be able to map the CS region as specified in the DT. Till then, maybe you can pre-configure CS0 in the bootloader to wherever you want or alternatively call gpmc_cs_remap() after the gpmc_cs_request() in gpmc_nand_init(); I've found the stuff in bootloader and mapped NAND to 0x0900, but it didn't help. Yegor -- 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: am335x: system doesn't reboot after flashing NAND
Hi Roger, Yegor,
From: Quadros, Roger
On 06/04/2014 10:45 PM, Yegor Yefremov wrote:
[...]
The 0x8000 address seems to be the beginning of NAND region:
ranges = 0 0 0x0800 0x1000; /* CS0: NAND */
I've taken this example from am335x_evm.dts. I have tried to change
the mapping to 0x9000, but kernel still uses 0x8000, Where in
the kernel will ranges be evaluated? I'm digging thorugh
arch/arm/mach-omap2/gpmc.c and gpmc-nand.c, but didn't really found
the place.
Well it doesn't. It just uses whatever was setup by the bootloader or
randomly allocated by gpmc_cs_request().
I'm working on fixing this up. I should be posting v2 of the GPMC refactor
series by this week and you should be able to map the CS region as specified
in the DT.
Till then, maybe you can pre-configure CS0 in the bootloader to wherever you
want
or alternatively call gpmc_cs_remap() after the gpmc_cs_request() in
gpmc_nand_init();
cheers,
-roger
I had a fix for this gpmc_cs_remap issue, it worked for beaglebone NOR,
but havn't checked on other devices. So please see if it works for you.
However, I don't suspect XIP boot here because even if CPU is detecting
garbage data while reading from 0x8000 it won't find a valid image
header there, and so XIP boot should have failed, and boot sequence
should fall back to MMC. It shouldn't have hung.
Still you can try below patch for gpmc_cs_remap().
---
From: Pekon Gupta pe...@ti.com
Date: Fri, 9 May 2014 15:17:32 +0530
Subject: [PATCH 12/14] ARM: OMAP2+: fix gpmc_cs_remap: re-allocating
chip-select address space based on DT
Each GPMC chip-select needs to be configured for (base-address,CS-size) so that
GPMC understands the address-space allocated to device connected externally.
These chip-select configurations (base-address, CS-size) follow some basic
mapping rules like:
- The CS size is programmable from 256 MBytes to 16 MBytes (must be a power of
2)
and is defined by the mask field. Attached memory smaller than the programmed
CS region size is accessed through the entire CS region (aliasing).
- The programmed 'base-address' must be aligned to the 'CS-size' boundary and
be a power of 2.
- Valid CS-size values are {256MB(max), 128MB, 64MB, 32MB and 16MB (min)}
Any intermediate values creates holes in the chip-select memory-map.
This patch adds above checks in gpmc_cs_remap() so that any invalid value
passed by DT reg property can be filtered before actually allocating the
address space.
Signed-off-by: Pekon Gupta pe...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 42 +-
1 file changed, 29 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 4fc4963..224550e 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -521,26 +521,42 @@ static int gpmc_cs_delete_mem(int cs)
* base. Returns 0 on success and appropriate negative error code
* on failure.
*/
-static int gpmc_cs_remap(int cs, u32 base)
+static int gpmc_cs_remap(int cs, u32 base, u32 size)
{
int ret;
- u32 old_base, size;
if (cs gpmc_cs_num) {
pr_err(%s: requested chip-select is disabled\n, __func__);
return -ENODEV;
}
- /*
-* Make sure we ignore any device offsets from the GPMC partition
-* allocated for the chip select and that the new base confirms
-* to the GPMC 16MB minimum granularity.
-*/
- base = ~(SZ_16M - 1);
-
- gpmc_cs_get_memconf(cs, old_base, size);
- if (base == old_base)
- return 0;
+ /* allocate enough address-space under GPMC chip-select to device */
+ if (size SZ_256M) {
+ pr_err(%s: memory device 256MB not supported\n, __func__);
+ return -ENODEV;
+ } else if (size SZ_128M) {
+ WARN((size != SZ_256M), cs=%d: allocating 256MB\n, cs);
+ size = SZ_256M;
+ } else if (size SZ_64M) {
+ WARN((size != SZ_128M), cs=%d: allocating 128MB\n, cs);
+ size = SZ_128M;
+ } else if (size SZ_32M) {
+ WARN((size != SZ_64M), cs=%d: allocating 64MB\n, cs);
+ size = SZ_64M;
+ } else if (size SZ_16M) {
+ WARN((size != SZ_32M), cs=%d: allocating 64MB\n, cs);
+ size = SZ_32M;
+ } else {
+ WARN((size != SZ_16M), cs=%d: allocating 64MB\n, cs);
+ size = SZ_16M;
+ }
+
+ /* base address should be aligned with address-space size */
+ if (base (size - 1)) {
+ pr_err(base-addr=%x should be aligned to size=%x, base, size);
+ return -EINVAL;
+ }
+
gpmc_cs_disable_mem(cs);
ret = gpmc_cs_delete_mem(cs);
if (ret 0)
@@ -1551,7 +1567,7 @@ static int gpmc_probe_generic_child(struct
platform_device *pdev,
* CS to this location. Once DT migration is
RE: am335x: system doesn't reboot after flashing NAND
Hi Yegor,
From: Gupta, Pekon
However, I don't suspect XIP boot here because even if CPU is detecting
garbage data while reading from 0x8000 it won't find a valid image
header there, and so XIP boot should have failed, and boot sequence
should fall back to MMC. It shouldn't have hung.
I checked with Sekhar on this, and my understanding was incorrect here.
There is no image verification (or marker) check done for XIP boot.
As mentioned by Sekhar earlier, XIP boot just checks for non-0x0 and
non-0xFF data on 0x8000. And it treats any value as valid code image
and starts executing it.
So, please ignore my above statement.
with regards, pekon
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
Re: [PATCH] regulator: core: print error value when constraints are not applied
On Wed, Jun 04, 2014 at 02:53:25PM -0500, Nishanth Menon wrote: With commit 064d5cd110f94ce41ca5681dcda8b77fa63d5b95 (regulator: core: Fix the init of DT defined fixed regulators) We ensure that regulator must be capable of providing it's current voltage when constraints are used, however adding the return value in the print is a little more informative to explain the nature of the failure involved. Applied, thanks. signature.asc Description: Digital signature
Re: mainline boot: 37 passed 4 failed (mainline/v3.15-rc8-4569-g3de0ef8) (palmas regression uEVM)
On Wed, Jun 04, 2014 at 02:34:31PM -0500, Nishanth Menon wrote: Seems to help my OMAP5uevm. If this makes sense, I will repost it as a formal patch. Actually I just went ahead and applied this - thanks! signature.asc Description: Digital signature
video_omap4 and control module access (was ... from opensuse-arm list)
Full thread in opensuse mailing list: http://lists.opensuse.org/archive/opensuse-arm/2014-06/msg4.html Moving this thread out of opensuse to kernel public lists +CC of maintainers relevant to the control module/clk. On 06/05/2014 11:17 AM, Nishanth Menon wrote: On 06/05/2014 10:56 AM, Laurent Pinchart wrote: Hi Nishanth, On Thursday 05 June 2014 08:37:27 Nishanth Menon wrote: On 06/05/2014 08:29 AM, Takashi Iwai wrote: Alexander Graf wrote: On 04.06.14 09:28, Matwey V. Kornilov wrote: On 19.05.2014 14:02, Alexander Graf wrote: note: expected 'uint32_t *' but argument is of type 'dma_addr_t *' I've fixed that one, but can not figure out what is wrong now: https://build.opensuse.org/package/live_build_log/home:matwey:pcm051:13. 2/kernel-default/standard/armv7l If I had to guess I'd say someone forgot to put a few EXPORT_SYMBOLs into the code and never tested whether compiling his v4l / video driver actually works when it's compiled as a module. The problem is CONFIG_VIDEO_OMAP4=y while the whole V4L stuff is built as modules. You have to build V4L into kernel, too. That said, it's a Kconfig dependency issue. Looking at the code, though, omap4-iss driver itself is written to be built also as a module. But its Kconfig is bool, so the problem happens. Maybe a patch like below works? Takashi --- diff --git a/drivers/staging/media/omap4iss/Kconfig b/drivers/staging/media/omap4iss/Kconfig index 78b0fba7047e..0c3e3c1acd4f 100644 --- a/drivers/staging/media/omap4iss/Kconfig +++ b/drivers/staging/media/omap4iss/Kconfig @@ -1,5 +1,5 @@ config VIDEO_OMAP4 - bool OMAP 4 Camera support + tristate OMAP 4 Camera support depends on VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API I2C ARCH_OMAP4 select VIDEOBUF2_DMA_CONTIG ---help--- +Sakari and Laurent. Full thread: http://lists.opensuse.org/archive/opensuse-arm/2014-06/msg4.html I agree, I see no reason for these to be bool. There's no good reason for the option to be a boolean, but there's a bad reason :-/ The OMAP4 ISS driver calls the omap4_ctrl_pad_readl() and omap4_ctrl_pad_writel() functions, which are not exported. The right way to fix this would be to implement a control module driver for the OMAP4, but that's not a straightforward task, and I don't have time to do so at the moment. a) control module: from: drivers/staging/media/omap4iss/iss_csiphy.c /* * SCM.CONTROL_CAMERA_RX * - bit [31] : CSIPHY2 lane 2 enable (4460+ only) * - bit [30:29] : CSIPHY2 per-lane enable (1 to 0) * - bit [28:24] : CSIPHY1 per-lane enable (4 to 0) * - bit [21] : CSIPHY2 CTRLCLK enable * - bit [20:19] : CSIPHY2 config: 00 d-phy, 01/10 ccp2 * - bit [18] : CSIPHY1 CTRLCLK enable * - bit [17:16] : CSIPHY1 config: 00 d-phy, 01/10 ccp2 */ cam_rx_ctrl = omap4_ctrl_pad_readl( OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_CAMERA_RX); Is'nt that what pinctrl does? And should be rather trivial to do, no? c) if there is something else that these bits do that I cant figure out, example: for specific stuff like control module bit for clock (which the above code kinda sounds similar to), like how we had for display recently - model it with dts clock[1] b) if you cannot use existing frameworks OR use pinctrl, last ditch way to do it in pdata-quirks in mach-omap2 with fops being send over. We did debate putting entire control module as a syscon_driver, the current split (prior to syscon) just makes it impractical to switch over to it at this point in time, maybe once all dt-fication is done, it might be possible to switch over to that. [1] http://marc.info/?l=linux-omapm=140127434229399w=2 -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 2/2] power: twl4030_charger: attempt to power off in case of critical events
On 01:30-20140605, Grazvydas Ignotas wrote:
On Wed, Jun 4, 2014 at 4:01 PM, Nishanth Menon n...@ti.com wrote:
On 06/04/2014 05:04 AM, Grazvydas Ignotas wrote:
On Thu, May 29, 2014 at 12:46 AM, Nishanth Menon n...@ti.com wrote:
Attempt to power off in case of critical events such as battery removal,
over voltage events.
There is no guarentee that we'd be in a safe scenario here, but the very
least we can try to do is to power off the device to prevent damage to
the system instead of just printing a message and hoping for the best.
At least battery temperature out of range does seem to happen quite
often while charging on hot summer day. I'd prefer my pandora to not
shutdown in such case, it could just stop charging instead.
Yeah, We could call
twl4030_charger_enable_ac(false);
twl4030_charger_enable_usb(bci, false);
But then, is that sufficient?
From the TRM:
7.5.8 Battery Temperature Out-of-Range Detection
Battery temperature out-of-range detection detects whether the battery
temperature is within a specific
range. Detection is possible for two temperature ranges. When the
battery temperature is not in the
2–50°C range or is in the 3–43°C range, the TBATOR1 and TBATOR2 status
bits rise and an interrupt is
generated.
This MADC monitoring function can be enabled by writing to the
TBATOR1EN (BCIMFEN2[3]) and
TBATOR2EN (BCIMFEN2[1]) fields.
Battery pack at high temperature is a risk, no? and it may not be just
charger that might be causing such a condition. Is'nt it safer to shut
the device down in such a case?
I don't know, so far nobody has complained about the battery exploding
and anybody getting hurt, but it would make the device unusable for
Yeah - but this is not something we'd like to see, ever! Out side of
2-50C+ range, I'd think cold climates too and wonder about[1] style
experiences.. there are too many PR stories on the net which does not
let me do anything else in case of error notifications like this. As
you can guess, I'd want to be the last person responsible for a patch
that does not react to hardware event telling me unsafe temperature
and not taking drastic action that kernel lets me(not interested in
appearing in some court).
people in hot climates. From what I remember the automatic charge is
stopped automatically on this condition, as some people complained
they couldn't charge their device and saw these messages in dmesg. I
guess mainline could choose the safer option and shutdown, no strong
opinion about this.
OK. Then, lets just stick to reasonable temperature ranges here and go
a little more conservative[shut down the chargers as well] as in the
following patch. Do ack if you are ok with the following.
[1] http://en.wikipedia.org/wiki/Lithium-ion_battery#Safety
8--
From daeac775473061c5f59d307a9500c688d9b6e87f Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Wed, 28 May 2014 16:01:16 -0500
Subject: [PATCH V2] power: twl4030_charger: attempt to power off in case of
critical events
Attempt to power off in case of critical events such as battery removal,
over voltage events.
There is no guarentee that we'd be in a safe scenario here, but the
very least we can try to do is to shut down the chargers and power off
the device to prevent damage to the system instead of just printing a
message and hoping for the best.
NOTE: twl4030 should attempt some form of recovery, but just depending
on that is never a safe alternative.
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/power/twl4030_charger.c | 30 +-
1 file changed, 25 insertions(+), 5 deletions(-)
diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
index 2598c58..6d92893 100644
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
@@ -22,6 +22,7 @@
#include linux/power_supply.h
#include linux/notifier.h
#include linux/usb/otg.h
+#include linux/reboot.h
#include linux/regulator/machine.h
#define TWL4030_BCIMSTATEC 0x02
@@ -332,6 +333,7 @@ static irqreturn_t twl4030_bci_interrupt(int irq, void *arg)
struct twl4030_bci *bci = arg;
u8 irqs1, irqs2;
int ret;
+ bool power_off = false;
ret = twl_i2c_read_u8(TWL4030_MODULE_INTERRUPTS, irqs1,
TWL4030_INTERRUPTS_BCIISR1A);
@@ -352,20 +354,38 @@ static irqreturn_t twl4030_bci_interrupt(int irq, void
*arg)
}
/* various monitoring events, for now we just log them here */
- if (irqs1 (TWL4030_TBATOR2 | TWL4030_TBATOR1))
+ if (irqs1 (TWL4030_TBATOR2 | TWL4030_TBATOR1)) {
dev_warn(bci-dev, battery temperature out of range\n);
+ power_off = true;
+ }
- if (irqs1 TWL4030_BATSTS)
+ if (irqs1 TWL4030_BATSTS) {
dev_crit(bci-dev, battery disconnected\n);
+ power_off = true;
+ }
- if (irqs2
Re: video_omap4 and control module access (was ... from opensuse-arm list)
2014-06-05 20:47 GMT+04:00 Nishanth Menon n...@ti.com: Full thread in opensuse mailing list: http://lists.opensuse.org/archive/opensuse-arm/2014-06/msg4.html Moving this thread out of opensuse to kernel public lists +CC of maintainers relevant to the control module/clk. Full build log (600KB) and config are available here: http://yadi.sk/d/sVEkp5CjSQDF8 http://yadi.sk/d/c-9N18f8SQDEs -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp:0x2...@jabber.ru -- 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: video_omap4 and control module access (was ... from opensuse-arm list)
Hi Nishanth, On Thursday 05 June 2014 11:47:19 Nishanth Menon wrote: Full thread in opensuse mailing list: http://lists.opensuse.org/archive/opensuse-arm/2014-06/msg4.html Moving this thread out of opensuse to kernel public lists +CC of maintainers relevant to the control module/clk. On 06/05/2014 11:17 AM, Nishanth Menon wrote: On 06/05/2014 10:56 AM, Laurent Pinchart wrote: On Thursday 05 June 2014 08:37:27 Nishanth Menon wrote: On 06/05/2014 08:29 AM, Takashi Iwai wrote: Alexander Graf wrote: On 04.06.14 09:28, Matwey V. Kornilov wrote: On 19.05.2014 14:02, Alexander Graf wrote: note: expected 'uint32_t *' but argument is of type 'dma_addr_t *' I've fixed that one, but can not figure out what is wrong now: https://build.opensuse.org/package/live_build_log/home:matwey:pcm051: 13.2/kernel-default/standard/armv7l If I had to guess I'd say someone forgot to put a few EXPORT_SYMBOLs into the code and never tested whether compiling his v4l / video driver actually works when it's compiled as a module. The problem is CONFIG_VIDEO_OMAP4=y while the whole V4L stuff is built as modules. You have to build V4L into kernel, too. That said, it's a Kconfig dependency issue. Looking at the code, though, omap4-iss driver itself is written to be built also as a module. But its Kconfig is bool, so the problem happens. Maybe a patch like below works? Takashi --- diff --git a/drivers/staging/media/omap4iss/Kconfig b/drivers/staging/media/omap4iss/Kconfig index 78b0fba7047e..0c3e3c1acd4f 100644 --- a/drivers/staging/media/omap4iss/Kconfig +++ b/drivers/staging/media/omap4iss/Kconfig @@ -1,5 +1,5 @@ config VIDEO_OMAP4 -bool OMAP 4 Camera support +tristate OMAP 4 Camera support depends on VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API I2C ARCH_OMAP4 select VIDEOBUF2_DMA_CONTIG ---help--- +Sakari and Laurent. Full thread: http://lists.opensuse.org/archive/opensuse-arm/2014-06/msg4.html I agree, I see no reason for these to be bool. There's no good reason for the option to be a boolean, but there's a bad reason :-/ The OMAP4 ISS driver calls the omap4_ctrl_pad_readl() and omap4_ctrl_pad_writel() functions, which are not exported. The right way to fix this would be to implement a control module driver for the OMAP4, but that's not a straightforward task, and I don't have time to do so at the moment. a) control module: from: drivers/staging/media/omap4iss/iss_csiphy.c /* * SCM.CONTROL_CAMERA_RX * - bit [31] : CSIPHY2 lane 2 enable (4460+ only) * - bit [30:29] : CSIPHY2 per-lane enable (1 to 0) * - bit [28:24] : CSIPHY1 per-lane enable (4 to 0) * - bit [21] : CSIPHY2 CTRLCLK enable * - bit [20:19] : CSIPHY2 config: 00 d-phy, 01/10 ccp2 * - bit [18] : CSIPHY1 CTRLCLK enable * - bit [17:16] : CSIPHY1 config: 00 d-phy, 01/10 ccp2 */ cam_rx_ctrl = omap4_ctrl_pad_readl( OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_CAMERA_RX); Is'nt that what pinctrl does? And should be rather trivial to do, no? It's a bit of a grey area. While enabling/disabling CSI lanes could be considered as falling into the scope of pinctrl (but even there I have some doubts, as this is one level beyond pin muxing in my opinion), pushing clock enabling/disabling to pinctrl would require a really big shoehorn :-) The register also controls the CSI2 PHY mode of operation (CCP2, CSI1 or CSI2), which doesn't really look like pinctrl territory to me. Let's also keep in mind that the configuration currently hardcoded by the driver is a shortcut. We want to be able to control each field in the register dynamically and independently. We can't apply partial pinctrl configurations today, so we would need to declare one configuration for every field combination, which really doesn't scale. c) if there is something else that these bits do that I cant figure out, example: for specific stuff like control module bit for clock (which the above code kinda sounds similar to), like how we had for display recently - model it with dts clock[1] The TRM ISS section states that (vii) A dedicated internal clock gate control is present for each PHY. Enable or disable the internal CTRLCLK from the CAMERARX_CSI22_CTRLCLKE[21] CAMERARX_CSI22_CTRLCLKE bit or the [18] CAMERARX_CSI21_CTRLCLKE bit. Those two of the bits could probably be exposed through CCF, and [1] seems to go in the right direction for that. We will still need a solution for the other bits though, as we will need to handle all accesses to the register from a single driver in order to implement proper locking (although we could consider that the caller should handle access serialization, but that's a bit messy I believe). b) if you cannot use existing frameworks OR use pinctrl, last ditch way to do it in pdata-quirks in mach-omap2 with fops being
[PATCH 3/4] mmc: omap: don't select TPS65010
The MMC host driver should not select the pmic driver, since that may have other dependencies, notably i2c in this case. It's not clear what the exact requirement of the driver is, but to preserve the behavior, this patch changes the 'select' into 'depends on', meaning you now have to turn on TPS65010 explicitly and then MMC_OMAP. Found during randconfig build testing. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: linux-omap@vger.kernel.org Cc: Jarkko Nikula jarkko.nik...@bitmer.com --- drivers/mmc/host/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig index cdf21cc..adffe0e 100644 --- a/drivers/mmc/host/Kconfig +++ b/drivers/mmc/host/Kconfig @@ -295,7 +295,7 @@ config MMC_MOXART config MMC_OMAP tristate TI OMAP Multimedia Card Interface support depends on ARCH_OMAP - select TPS65010 if MACH_OMAP_H2 + depends on TPS65010 || !MACH_OMAP_H2 help This selects the TI OMAP Multimedia card Interface. If you have an OMAP board with a Multimedia Card slot, -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] randconfig fixes for mmc
Hi Chris, Ulf, These are small fixes from my randconfig testing, almost all for older bugs, please apply to a tree you see appropriate. Arnd Arnd Bergmann (4): mmc: atmel-mci: incude asm/cacheclush.h mmc: mvsdio: avoid compiler warning mmc: omap: don't select TPS65010 mmc: simplify SDHCI Kconfig dependencies drivers/mmc/host/Kconfig | 10 -- drivers/mmc/host/atmel-mci.c | 1 + drivers/mmc/host/mvsdio.c| 2 +- 3 files changed, 6 insertions(+), 7 deletions(-) -- 1.8.3.2 Cc: Ludovic Desroches ludovic.desroc...@atmel.com Cc: Nicolas Pitre n...@fluxnic.net Cc: Chris Ball ch...@printf.net Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com Cc: Jason Cooper ja...@lakedaemon.net Cc: Andrew Lunn and...@lunn.ch Cc: linux-...@vger.kernel.org Cc: linux-omap@vger.kernel.org Cc: Jarkko Nikula jarkko.nik...@bitmer.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
[PATCH] ARM: dts: OMAP5: Update CPU OPP table as per final production Manual
As per the Final production Data Manual for OMAP5432, SWPS050F(APRIL 2014) There are only two OPPs - 1GHz and 1.5GHz. the older OPP_LOW has been completely descoped. The Nominal voltages are still correct though. However, expectation for final production configuration is operation with Adaptive Body Bias (ABB) and Adaptive Voltage Scaling Class 0 operation. There are no IDcode or version change information encoded to programmatically detect this and software is supposed to NOT use OPP_LOW(500MHz) anymore for all devices (legacy and production samples). Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/boot/dts/omap5.dtsi |1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index 3bfda16..a4ed549 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -45,7 +45,6 @@ operating-points = /* kHzuV */ - 50 88 100 106 150 125 ; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2] ARM: dts: OMAP5: Add device nodes for ABB
From: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
Add ABB device nodes for OMAP5 family of devices. Data is based on
final production OMAP543x Technical Reference Manual revision Z (April 2013).
Final production Data Manual for OMAP5432 SWPS050F(APRIL 2014).
[n...@ti.com: co-developer and updates to latest documentation]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
---
Original patch (v1): https://patchwork.kernel.org/patch/3555191/
Rest of the series was accepted, however, I had to drop this
previously to ensure that the data we introduce is compatible with
production samples and existing pre-production samples on various
OMAP5uEVMs already in circulation.
arch/arm/boot/dts/omap5.dtsi | 60 ++
1 file changed, 60 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index a4ed549..8eee6fb 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -985,6 +985,66 @@
dma-names = audio_tx;
};
};
+
+ abb_mpu: regulator-abb-mpu {
+ compatible = ti,abb-v2;
+ regulator-name = abb_mpu;
+ #address-cells = 0;
+ #size-cells = 0;
+ clocks = sys_clkin;
+ ti,settling-time = 50;
+ ti,clock-cycles = 16;
+
+ reg = 0x4ae07cdc 0x8, 0x4ae06014 0x4,
+ 0x4a0021c4 0x8, 0x4ae0c318 0x4;
+ reg-names = base-address, int-address,
+ efuse-address, ldo-address;
+ ti,tranxdone-status-mask = 0x80;
+ /* LDOVBBMPU_MUX_CTRL */
+ ti,ldovbb-override-mask = 0x400;
+ /* LDOVBBMPU_VSET_OUT */
+ ti,ldovbb-vset-mask = 0x1F;
+
+ /*
+* NOTE: only FBB mode used but actual vset will
+* determine final biasing
+*/
+ ti,abb_info =
+ /*uVABB efuse rbb_m fbb_m vset_m*/
+ 106 0 0x0 0 0x0200 0x01F0
+ 125 0 0x4 0 0x0200 0x01F0
+ ;
+ };
+
+ abb_mm: regulator-abb-mm {
+ compatible = ti,abb-v2;
+ regulator-name = abb_mm;
+ #address-cells = 0;
+ #size-cells = 0;
+ clocks = sys_clkin;
+ ti,settling-time = 50;
+ ti,clock-cycles = 16;
+
+ reg = 0x4ae07ce4 0x8, 0x4ae06010 0x4,
+ 0x4a0021a4 0x8, 0x4ae0c314 0x4;
+ reg-names = base-address, int-address,
+ efuse-address, ldo-address;
+ ti,tranxdone-status-mask = 0x8000;
+ /* LDOVBBMM_MUX_CTRL */
+ ti,ldovbb-override-mask = 0x400;
+ /* LDOVBBMM_VSET_OUT */
+ ti,ldovbb-vset-mask = 0x1F;
+
+ /*
+* NOTE: only FBB mode used but actual vset will
+* determine final biasing
+*/
+ ti,abb_info =
+ /*uVABB efuse rbb_m fbb_m vset_m*/
+ 1025000 0 0x0 0 0x0200 0x01F0
+ 112 0 0x4 0 0x0200 0x01F0
+ ;
+ };
};
};
--
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
[RFC PATCH 5/7] ARM: dts: OMAP4: Add PRM interrupt
Provide OMAP4 interrupt number for PRM
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 7e26d22..6d2827f 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -129,6 +129,7 @@
prm: prm@4a306000 {
compatible = ti,omap4-prm;
reg = 0x4a306000 0x3000;
+ interrupts = GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH;
prm_clocks: clocks {
#address-cells = 1;
--
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
[RFC PATCH 2/7] ARM: OMAP4: prm use the generic prm_inst to allow logic to be abstracted
use the generic function to pick up the prm_instance for a generic logic
which can be reused from OMAP4+
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/prm44xx.c | 47 +
1 file changed, 38 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index a7f6ea2..d4d745e 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -154,21 +154,36 @@ void omap4_prm_vp_clear_txdone(u8 vp_id)
u32 omap4_prm_vcvp_read(u8 offset)
{
+ s32 inst = omap4_prmst_get_prm_dev_inst();
+
+ if (inst == PRM_INSTANCE_UNKNOWN)
+ return 0;
+
return omap4_prminst_read_inst_reg(OMAP4430_PRM_PARTITION,
- OMAP4430_PRM_DEVICE_INST, offset);
+ inst, offset);
}
void omap4_prm_vcvp_write(u32 val, u8 offset)
{
+ s32 inst = omap4_prmst_get_prm_dev_inst();
+
+ if (inst == PRM_INSTANCE_UNKNOWN)
+ return;
+
omap4_prminst_write_inst_reg(val, OMAP4430_PRM_PARTITION,
-OMAP4430_PRM_DEVICE_INST, offset);
+inst, offset);
}
u32 omap4_prm_vcvp_rmw(u32 mask, u32 bits, u8 offset)
{
+ s32 inst = omap4_prmst_get_prm_dev_inst();
+
+ if (inst == PRM_INSTANCE_UNKNOWN)
+ return 0;
+
return omap4_prminst_rmw_inst_reg_bits(mask, bits,
OMAP4430_PRM_PARTITION,
- OMAP4430_PRM_DEVICE_INST,
+ inst,
offset);
}
@@ -275,14 +290,18 @@ void omap44xx_prm_restore_irqen(u32 *saved_mask)
void omap44xx_prm_reconfigure_io_chain(void)
{
int i = 0;
+ s32 inst = omap4_prmst_get_prm_dev_inst();
+
+ if (inst == PRM_INSTANCE_UNKNOWN)
+ return;
/* Trigger WUCLKIN enable */
omap4_prm_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK,
OMAP4430_WUCLK_CTRL_MASK,
- OMAP4430_PRM_DEVICE_INST,
+ inst,
OMAP4_PRM_IO_PMCTRL_OFFSET);
omap_test_timeout(
- (((omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+ (((omap4_prm_read_inst_reg(inst,
OMAP4_PRM_IO_PMCTRL_OFFSET)
OMAP4430_WUCLK_STATUS_MASK)
OMAP4430_WUCLK_STATUS_SHIFT) == 1),
@@ -292,10 +311,10 @@ void omap44xx_prm_reconfigure_io_chain(void)
/* Trigger WUCLKIN disable */
omap4_prm_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK, 0x0,
- OMAP4430_PRM_DEVICE_INST,
+ inst,
OMAP4_PRM_IO_PMCTRL_OFFSET);
omap_test_timeout(
- (((omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+ (((omap4_prm_read_inst_reg(inst,
OMAP4_PRM_IO_PMCTRL_OFFSET)
OMAP4430_WUCLK_STATUS_MASK)
OMAP4430_WUCLK_STATUS_SHIFT) == 0),
@@ -316,9 +335,14 @@ void omap44xx_prm_reconfigure_io_chain(void)
*/
static void __init omap44xx_prm_enable_io_wakeup(void)
{
+ s32 inst = omap4_prmst_get_prm_dev_inst();
+
+ if (inst == PRM_INSTANCE_UNKNOWN)
+ return;
+
omap4_prm_rmw_inst_reg_bits(OMAP4430_GLOBAL_WUEN_MASK,
OMAP4430_GLOBAL_WUEN_MASK,
- OMAP4430_PRM_DEVICE_INST,
+ inst,
OMAP4_PRM_IO_PMCTRL_OFFSET);
}
@@ -333,8 +357,13 @@ static u32 omap44xx_prm_read_reset_sources(void)
struct prm_reset_src_map *p;
u32 r = 0;
u32 v;
+ s32 inst = omap4_prmst_get_prm_dev_inst();
+
+ if (inst == PRM_INSTANCE_UNKNOWN)
+ return 0;
+
- v = omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+ v = omap4_prm_read_inst_reg(inst,
OMAP4_RM_RSTST);
p = omap44xx_prm_reset_src_map;
--
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
[RFC PATCH 0/7] ARM: OMAP4+: PRM: minor cleanups and dt support of interrupts
Hi, The following series is a minimal set of cleanups and generalization in the direction of supporting daisychain wakeup on all OMAP4+ platforms. We cannot still add IO_WAKEUP ability for OMAP5/DRA7/AM437x yet pending further pinctrl patches. These do have a few cosmetic issues, but hope is to get a view about the approach. Also note that documentation of bindings for ti,dra7-prm etc are still pending. Nishanth Menon (7): ARM: OMAP4+: prminst: provide function to find prm_dev instance offset ARM: OMAP4: prm use the generic prm_inst to allow logic to be abstracted ARM: OMAP4+: PRM: remove wkup event ARM: OMAP4+: PRM: register interrupt information from DT ARM: dts: OMAP4: Add PRM interrupt ARM: dts: OMAP5: add PRM interrupt ARM: dts: DRA7: add PRM interrupt arch/arm/boot/dts/dra7.dtsi |1 + arch/arm/boot/dts/omap4.dtsi |1 + arch/arm/boot/dts/omap5.dtsi |1 + arch/arm/mach-omap2/prm44xx.c | 89 - arch/arm/mach-omap2/prminst44xx.c | 41 ++--- arch/arm/mach-omap2/prminst44xx.h |3 ++ 6 files changed, 111 insertions(+), 25 deletions(-) -- 1.7.9.5 Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 4/7] ARM: OMAP4+: PRM: register interrupt information from DT
Allow the PRM interrupt information to be picked up from device tree.
the only exception is for OMAP4 which uses values pre-populated and allows
compatibility with older dtb.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/prm44xx.c | 41 +
1 file changed, 41 insertions(+)
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 1ecf244..784b3e1 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -17,6 +17,7 @@
#include linux/errno.h
#include linux/err.h
#include linux/io.h
+#include linux/of_irq.h
#include soc.h
@@ -698,11 +699,51 @@ int __init omap44xx_prm_init(void)
return prm_register(omap44xx_prm_ll_data);
}
+static struct of_device_id omap_prm_dt_match_table[] = {
+ { .compatible = ti,omap4-prm },
+ { .compatible = ti,omap5-prm },
+ { .compatible = ti,dra7-prm },
+ { }
+};
+
static int omap44xx_prm_late_init(void)
{
+ struct device_node *np;
+ int irq_num;
+
+ /* OMAP4+ is DT only now */
+ if (!of_have_populated_dt())
+ return 0;
+
if (!(prm_features PRM_HAS_IO_WAKEUP))
return 0;
+ np = of_find_matching_node(NULL, omap_prm_dt_match_table);
+
+ if (!np) {
+ /* Default loaded up with OMAP4 values - older dtb compatible?
*/
+ if (!cpu_is_omap44xx())
+ return 0;
+ } else {
+ irq_num = of_irq_get(np, 0);
+ /*
+* Already have OMAP4 IRQ num. For all other platforms, we need
+* IRQ numbers from DT - old dtb compatible?
+*/
+ if (irq_num 0 !cpu_is_omap44xx()) {
+
+ if (irq_num == -EPROBE_DEFER)
+ return irq_num;
+
+ /* Have nothing to do */
+ return 0;
+ }
+
+ /* Once OMAP4 DT is filled as well */
+ if (irq_num = 0)
+ omap4_prcm_irq_setup.irq = irq_num;
+ }
+
omap44xx_prm_enable_io_wakeup();
return omap_prcm_register_chain_handler(omap4_prcm_irq_setup);
--
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
[RFC PATCH 1/7] ARM: OMAP4+: prminst: provide function to find prm_dev instance offset
PRM device instance can vary depending on SoC. We already handle the
same during reset of the device, However, this is also needed
for other logic instances. So, first abstract this out to a generic
function.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/prminst44xx.c | 41 +++--
arch/arm/mach-omap2/prminst44xx.h |3 +++
2 files changed, 29 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/prminst44xx.c
b/arch/arm/mach-omap2/prminst44xx.c
index 69f0dd0..fd2549d 100644
--- a/arch/arm/mach-omap2/prminst44xx.c
+++ b/arch/arm/mach-omap2/prminst44xx.c
@@ -31,6 +31,8 @@
static void __iomem *_prm_bases[OMAP4_MAX_PRCM_PARTITIONS];
+static s32 prm_dev_inst = PRM_INSTANCE_UNKNOWN;
+
/**
* omap_prm_base_init - Populates the prm partitions
*
@@ -41,6 +43,25 @@ void omap_prm_base_init(void)
{
_prm_bases[OMAP4430_PRM_PARTITION] = prm_base;
_prm_bases[OMAP4430_PRCM_MPU_PARTITION] = prcm_mpu_base;
+
+}
+
+s32 omap4_prmst_get_prm_dev_inst(void)
+{
+ if (prm_dev_inst != PRM_INSTANCE_UNKNOWN)
+ return prm_dev_inst;
+
+ /* This cannot be done way early at boot.. as things are not setup */
+ if (cpu_is_omap44xx())
+ prm_dev_inst = OMAP4430_PRM_DEVICE_INST;
+ else if (soc_is_omap54xx())
+ prm_dev_inst = OMAP54XX_PRM_DEVICE_INST;
+ else if (soc_is_dra7xx())
+ prm_dev_inst = DRA7XX_PRM_DEVICE_INST;
+ else if (soc_is_am43xx())
+ prm_dev_inst = AM43XX_PRM_DEVICE_INST;
+
+ return prm_dev_inst;
}
/* Read a register in a PRM instance */
@@ -169,28 +190,18 @@ int omap4_prminst_deassert_hardreset(u8 shift, u8 part,
s16 inst,
void omap4_prminst_global_warm_sw_reset(void)
{
u32 v;
- s16 dev_inst;
+ s32 inst = omap4_prmst_get_prm_dev_inst();
- if (cpu_is_omap44xx())
- dev_inst = OMAP4430_PRM_DEVICE_INST;
- else if (soc_is_omap54xx())
- dev_inst = OMAP54XX_PRM_DEVICE_INST;
- else if (soc_is_dra7xx())
- dev_inst = DRA7XX_PRM_DEVICE_INST;
- else if (soc_is_am43xx())
- dev_inst = AM43XX_PRM_DEVICE_INST;
- else
+ if (inst == PRM_INSTANCE_UNKNOWN)
return;
- v = omap4_prminst_read_inst_reg(OMAP4430_PRM_PARTITION, dev_inst,
+ v = omap4_prminst_read_inst_reg(OMAP4430_PRM_PARTITION, inst,
OMAP4_PRM_RSTCTRL_OFFSET);
v |= OMAP4430_RST_GLOBAL_WARM_SW_MASK;
omap4_prminst_write_inst_reg(v, OMAP4430_PRM_PARTITION,
-dev_inst,
-OMAP4_PRM_RSTCTRL_OFFSET);
+inst, OMAP4_PRM_RSTCTRL_OFFSET);
/* OCP barrier */
v = omap4_prminst_read_inst_reg(OMAP4430_PRM_PARTITION,
- dev_inst,
- OMAP4_PRM_RSTCTRL_OFFSET);
+ inst, OMAP4_PRM_RSTCTRL_OFFSET);
}
diff --git a/arch/arm/mach-omap2/prminst44xx.h
b/arch/arm/mach-omap2/prminst44xx.h
index a2ede2d..583aa37 100644
--- a/arch/arm/mach-omap2/prminst44xx.h
+++ b/arch/arm/mach-omap2/prminst44xx.h
@@ -12,6 +12,9 @@
#ifndef __ARCH_ASM_MACH_OMAP2_PRMINST44XX_H
#define __ARCH_ASM_MACH_OMAP2_PRMINST44XX_H
+#define PRM_INSTANCE_UNKNOWN -1
+extern s32 omap4_prmst_get_prm_dev_inst(void);
+
/*
* In an ideal world, we would not export these low-level functions,
* but this will probably take some time to fix properly
--
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
[RFC PATCH 6/7] ARM: dts: OMAP5: add PRM interrupt
Provide OMAP5 interrupt number for PRM
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap5.dtsi |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 3bfda16..ccced95 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -132,6 +132,7 @@
prm: prm@4ae06000 {
compatible = ti,omap5-prm;
reg = 0x4ae06000 0x3000;
+ interrupts = GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH;
prm_clocks: clocks {
#address-cells = 1;
--
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
[RFC PATCH 7/7] ARM: dts: DRA7: add PRM interrupt
Provide default DRA7 crossbar mapped interrupt for prm interrupt
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/dra7.dtsi |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index c29945e..38e8097 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -85,6 +85,7 @@
prm: prm@4ae06000 {
compatible = ti,dra7-prm;
reg = 0x4ae06000 0x3000;
+ interrupts = GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH;
prm_clocks: clocks {
#address-cells = 1;
--
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
[RFC PATCH 3/7] ARM: OMAP4+: PRM: remove wkup event
wkup event at bit offset 0 exists only on OMAP3.
OMAP4430/60 PRM_IRQSTATUS_A9, OMAP5/DRA7 PRM_IRQSTATUS_MPU
register bit 0 is DPLL_CORE_RECAL_ST not wakeup event like OMAP3.
The same applies to AM437x as well.
Remove the wrong definition.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/prm44xx.c |1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index d4d745e..1ecf244 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -32,7 +32,6 @@
/* Static data */
static const struct omap_prcm_irq omap4_prcm_irqs[] = {
- OMAP_PRCM_IRQ(wkup, 0, 0),
OMAP_PRCM_IRQ(io, 9, 1),
};
--
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
