Re: [PATCH] arm: omap: RX-51: ARM errata 430973 workaround
Hi! You can do without ret variable... Also more detailed changelog would be nice... like what exact problem this works around. Sure i can, but I don't see a reason to ignore SM's return value. Changelog of what? I guess if you read the thread over the ML you'll have your questions already answered. Or google for ARM errata 430973 workaround :). I did my googling. But I should not have had to. Just put the explanatory link in commit log. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/28] OMAP: DSS related board file changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/28/13 18:48, Tomi Valkeinen wrote: On 2013-03-28 17:31, Igor Grinberg wrote: On 03/28/13 14:48, Tomi Valkeinen wrote: So here are the DSS related board file changes for 3.10. First there are a bunch of patches adding the Kconfig options so that only one display device is created for a single video bus. Only Overo had more than two displays on the same bus, but unfortunately there were multiple boards with a setup that puts an LCD and DVI output on the same video bus. Hmmm, so basically, if one could switch the display at runtime... This cannot be done anymore... This sounds like feature removal, no? I know several of our clients who used this feature (at least for evaluation purposes). At some point in time it was possible to have multiple displays for the same bus, and switch them at runtime. Sometime later it was changed so that the board file adds all the displays, but only one (per bus) is actually added to the list of panels, but you could still set the default display in the kernel args, and thus you could select which display gets added. Yeah, I remember we had to hack this to have the functionality back... The reason why the multiple-displays-per-bus is problematic is that the video bus cannot be shared, and if we have multiple devices on the same bus, the drivers need extra trickery, delaying initializations, etc, to handle this. And it still doesn't work right, as it's easy to get two displays enabled at the same time, configuring the same video bus, creating a mess. Yep, looks like additional display manager framework is needed. Which will manage the displays on per bus basis? Quite often the case is that the other displays are not even present physically. But it is true that some boards have gpio switches that can be used to change the display during runtime. I don't think the runtime switch requirement will ever go away, so we'd better prepare for it wisely. Is there any strong pros you obtain while removing this feature? For an user, only indirectly. The change will make things sane on the display side, and will thus make it much easier to proceed towards DT adaptation, and Common Display Framework. While I can't say it's a strict must to remove this feature, I can say that it's been a constant headache for me for, well, ever. And I presume CDF would not have this feature anyway, as it's rather bad design. Well, I don't know about the CDF, but the runtime switch was there for ages... Think of a DVI or an HDMI... they have the EDID stuff to make the switch work as expected and it really brings multiple displays to the same video bus. I see this is only a meter of how we represent things. Instead of real EDID (or in addition), that comes with the display, currently we have the panel info already in the kernel and panel driver with board specific callbacks to make it work. So abstracting the above (in the long run) to CDF or some other framework, should suit everybody's needs. Probably, we will need board specific drivers, but that never was a problem... So the ifdeffery is not very nice. But, as discussed, this is the best way forward, and should be seen as a temporary solution until we get full DT support. I've missed this discussion, can you please point to it? Well, not so much discussion, but a few mails under Display related board specific boot args subject on l-o. I proposed a board specific kernel argument to select the displays present, Tony was less than enthusiastic about that. Yes, I can understand that ;-) And what will change with full DT support? Will we be able to define several displays through DT and select and active one during runtime? No, not as such. DT will let the bootloader pass the DT data, thus telling which displays are present. So we can have single kernel binary, which will work for all the cases. IMO, single kernel binary is a must. Dynamic switching during runtime will still be missing. This is not good, as it removes a functionality that worked before... For that I think we need board specific drivers. That driver should know about board specific restrictions etc (which are rather missing currently), remove the old display device, and create the new one. Well, yes we need a board specific drivers, but we need even more... Board specific driver should not poke with devices... I think for that we will need some kind of generic display manager (may be a part of CDF) that will deal with the device registration/removal and board specific drivers should implement some kind of API of the generic display manger. Well, actually, if there was a way to add a device while somehow marking it so that no driver will be bound to it... Then the user could use the standard sysfs interface to bind a driver to the device. I wonder if that could be done... I don't think this can fit current platform device framework. But may
Re: [PATCH 00/28] OMAP: DSS related board file changes
On 03/28/13 18:57, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [130328 09:53]: On 2013-03-28 17:31, Igor Grinberg wrote: On 03/28/13 14:48, Tomi Valkeinen wrote: I've missed this discussion, can you please point to it? Well, not so much discussion, but a few mails under Display related board specific boot args subject on l-o. I proposed a board specific kernel argument to select the displays present, Tony was less than enthusiastic about that. If we can come up with a Linux generic command line option to select the panel that can be supported also in the long run, I have no objections to that naturally. What I'm against is a temporary custom cmdline option until the board-*.c files go away as we don't want to support it in the long run. Agreed totally, the panel select option does not have to be board specific (and it better not be...). -- Regards, Igor. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/28] ARM: OMAP: CM-T35: Kconfig option for the display options
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/28/13 19:02, Tomi Valkeinen wrote: On 2013-03-28 18:09, Igor Grinberg wrote: On 03/28/13 14:49, Tomi Valkeinen wrote: Boards with multiple display options for the same video bus have all the possible linux display devices present at the same time. Only one of those devices should be used at a time, as the video bus cannot be shared. Yes, only one can be used at a time, but you can switch at runtime... Yep. But the panel drivers need to know about this, and they cannot do more or less anything in the driver probe function, which I think should be the place to reserve resources and do initialization. With the current model that would lead to multiple drivers trying to acquire the same resources. Yep, this is a problem, but it only means that probably the platform device framework is not suitable for this. What about having some kind of display manager which will have a private list of registered devices and will instantiate only those that are marked active? This also might be useful with DT. This model is hacky, and will be changed in the forthcoming DSS patches to a model where only one display device can be present on a single video bus. What do you mean by present? Is it active? or registered? or compiled in? I mean that only one device can be registered. Well, nothing strictly prevents having multiple devices registered, but if the devices have matching drivers, the drivers would acquire the same resources. Possibly the same gpios, but at least the same video bus. Well, I think, we should follow/extend the already existing EDID concept... Instantiate a display device only when one has been plugged in. By plugged in I mean enabled - made active. This patch creates Kconfig options to select which of the display devices is present on the board. While this model is also somewhat hacky, and prevents us from using a single kernel image for all the display options, it allows us to make the DSS driver changes for DT adaptation. And with DT, the information about display devices can be passed from the bootloader, solving the mess. Hmmm, the fact that we cannot use the same binary for multiple displays... This does not sound right and good at all... While we try to move to support multiple platforms in the same binary, we cannot support multiple displays? I agree that the multiplatform stuff is not really related, but you know what I mean... Yes, I quite agree that this sucks =). There are a few reasons I chose to try this approach: - The whole multi-display feature is hacky - DT support for DSS has been in development too long time. We really need it, preferably yesterday. This change helps getting DT support ready. Yes, but I don't think this should involve removing the existing functionality.. Let me exaggerate a bit: this is like removing ARM support from mainline, so it will make less noise and headache to Linus... - Common Display Framework won't (most likely) support this kind of feature, as the feature itself is rather hacky, so this would anyway disappear. Hmmm, I don't think it will disappear, but instead you will keep receiving hacky patches to bring that support in... So, IMO, it would be better designed to support this or at least keep it in mind, so there will no necessity for hacky patches... - DT support should solve this (except for runtime switching), and the board files are on the way out (as far as I understand). So in that sense this is temporary. But not the runtime switching... The runtime switching should be done in the framework. - Keeping this feature functional consumes considerable amount of man-hours, which are in short supply. This is where you should request some help from the interested sides... And mailing lists are quite handy. I still feel quite bad about this, though. Any ideas how to manage this better are appreciated. I bet there must be a much better solution for DT support. Yes, I think I covered that in the last email. DT will solve the issue, except for runtime switching, which is still open. I'm not sure how these board specific drivers would be implemented. Well, at least the generic kernel display parameter will do more than half of the job. We can discuss the runtime switch stuff, but it is really a non-sense to compile a kernel for specific display... - -- Regards, Igor. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRV/8gAAoJEBDE8YO64EfaGOQQAIEnXwrHiZFlsMkCo5n8uUok qBBvEoFh5s1h2aaDNna3Q7tvKF42UlaGtZPqwl5bDUHimcEaLnNPy14MQJ/w/dHN AvDaI2ZoqGCYDVjVa0KUCWqL6Chm7ZpAoU9NeY3T3+U8S7kIeizz0oBJKoZ4bfpk g6Kq5vnbi36pCWFMqQe+7fEn5CHJNHTp+miPpq3Dsed2zkVgIg9re0nTxpQjlDHO +kLwJjrHbCqZoBMzE0MacaibROiHhccQ9Xtf25iVemyHQ6CP6g+ibJduFF7S4pOk kOwH1NY2QiFGDyA0Tj+kuYsbUYe3E1ds7FCu0/9g2KpiGRqSAqrFDghJzj1PojL+
Re: [PATCH] OMAP3 ROM Random Number Generator support
On Thursday 28 March 2013 22:44:11 Tony Lindgren wrote:
* Pali Rohár pali.ro...@gmail.com [130328 10:58]:
Here is new version of patch:
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -486,6 +486,23 @@ static void omap_init_mcspi(void)
static inline void omap_init_mcspi(void) {}
#endif
+extern u32 *omap3_rom_rng_call(u32 id, u32 proc, u32 flags,
u32 va_ptr); +
+static struct platform_device omap3_rom_rng_device = {
+ .name = omap3-rom-rng,
+ .id = -1,
+ .dev= {
+ .platform_data = omap3_rom_rng_call,
+ },
+};
+
+static void omap_init_rom_rng(void)
+{
+ if (!cpu_is_omap34xx() || omap_type() ==
OMAP2_DEVICE_TYPE_GP) + return;
+ platform_device_register(omap3_rom_rng_device);
+}
+
/**
* omap_init_rng - bind the RNG hwmod to the RNG
omap_device *
This driver probably only works on Nokia boards because of the
different SMC call numbering. Until it's been verified on some
other HS omap34xx, I'd probably register this only from the
Nokia board-*.c file.
Freemangordon, can you look at this smc and errara 430973 code if
they could be merged? Really omap3_rom_rng_call function looks
like n900 specific.
Link: https://lkml.org/lkml/2013/3/28/398
--- /dev/null
+++ b/drivers/char/hw_random/omap3-rom-rng.c
+static int omap3_rom_rng_probe(struct platform_device
*pdev) +{
+ printk(KERN_INFO %s: initializing\n,
omap3_rom_rng_name); +
+ omap3_rom_rng_call = pdev-dev.platform_data;
+ if (!omap3_rom_rng_call) {
+ printk(KERN_ERR %s: omap3_rom_rng_call is NULL\n,
+ omap3_rom_rng_name);
+ return -EINVAL;
+ }
+
+ setup_timer(idle_timer, omap3_rom_idle_rng, 0);
+ rng_clk = clk_get_sys(omap_rng, ick);
+ if (IS_ERR(rng_clk)) {
+ printk(KERN_ERR %s: unable to get RNG clock\n,
+ omap3_rom_rng_name);
+ return IS_ERR(rng_clk);
+ }
You can use regular clk_get if you add the alias to
struct omap_clk omap3xxx_clks table.
Regards,
Tony
Tony, can you show me how?
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
[PATCH] RX-51: Fix probe order of SPI devices
From: Joni Lapilainen joni.lapilai...@gmail.com
Without this patch LCD panel on Nokia RX-51 is still black
Signed-off-by: Joni Lapilainen joni.lapilai...@gmail.com
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index b09b5da..03290b9 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -91,8 +91,8 @@
/* list all spi devices here */
enum {
RX51_SPI_WL1251,
- RX51_SPI_MIPID, /* LCD panel */
RX51_SPI_TSC2005, /* Touch Controller */
+ RX51_SPI_MIPID, /* LCD panel */
};
static struct wl12xx_platform_data wl1251_pdata;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] RX-51: Fix probe order of SPI devices
On Sunday 31 March 2013 12:52:23 Sebastian Reichel wrote: On Sun, Mar 31, 2013 at 12:09:21PM +0200, Pali Rohár wrote: From: Joni Lapilainen joni.lapilai...@gmail.com Without this patch LCD panel on Nokia RX-51 is still black Signed-off-by: Joni Lapilainen joni.lapilai...@gmail.com Signed-off-by: Pali Rohár pali.ro...@gmail.com Tested-by: Sebastian Reichel s...@debian.org Please note, that this patch has actually been proposed by Aaro Koskinen aaro.koski...@iki.fi quite some time ago [0]. [0] http://permalink.gmane.org/gmane.linux.ports.arm.omap/81729 -- Sebastian CCing Aaro. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH] OMAP3 ROM Random Number Generator support
Hi Pali,
Yep, the code looks almost identical, I guess with some tweaks all SMC code
from that patch could be removed and instead used the one from SMC PPA API.
What I don't get, is why one needs to disable/enable fiqs/irqs:
+static int call_sec_rom(u32 appl_id, u32 proc_id, u32 flag, ...)
+{
+ va_list ap;
+ u32 ret;
+ u32 val;
+
+ va_start(ap, flag);
+ val = *(u32 *) ap;
+ local_irq_disable();
+ local_fiq_disable();
+ ret = omap3_rom_rng_call(appl_id, proc_id, flag,
+(u32) virt_to_phys((void *) val));
+ local_fiq_enable();
+ local_irq_enable();
+ va_end(ap);
+
+ return ret;
+}
Do you have any idea why is that needed? Any other code I've ever seen to call
SM, does not disable fiqs/irqs, is RNG SMC somehow special? I know this is
Nokia's code, but still, if we can get some understanding...
Regards,
Ivo
Оригинално писмо
От: Pali Rohár
Относно: Re: [PATCH] OMAP3 ROM Random Number Generator support
До: Tony Lindgren
Изпратено на: Неделя, 2013, Март 31 12:28:12 EEST
On Thursday 28 March 2013 22:44:11 Tony Lindgren wrote:
* Pali Rohár [130328 10:58]:
Here is new version of patch:
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -486,6 +486,23 @@ static void omap_init_mcspi(void)
static inline void omap_init_mcspi(void) {}
#endif
+extern u32 *omap3_rom_rng_call(u32 id, u32 proc, u32 flags,
u32 va_ptr); +
+static struct platform_device omap3_rom_rng_device = {
+ .name = quot;omap3-rom-rngquot;,
+ .id = -1,
+ .dev= {
+ .platform_data = omap3_rom_rng_call,
+ },
+};
+
+static void omap_init_rom_rng(void)
+{
+ if (!cpu_is_omap34xx() || omap_type() ==
OMAP2_DEVICE_TYPE_GP) + return;
+ platform_device_register(amp;omap3_rom_rng_device);
+}
+
/**
* omap_init_rng - bind the RNG hwmod to the RNG
omap_device *
This driver probably only works on Nokia boards because of the
different SMC call numbering. Until it's been verified on some
other HS omap34xx, I'd probably register this only from the
Nokia board-*.c file.
Freemangordon, can you look at this smc and errara 430973 code if
they could be merged? Really omap3_rom_rng_call function looks
like n900 specific.
Link: https://lkml.org/lkml/2013/3/28/398
--- /dev/null
+++ b/drivers/char/hw_random/omap3-rom-rng.c
+static int omap3_rom_rng_probe(struct platform_device
*pdev) +{
+ printk(KERN_INFO quot;%s: initializing#92;nquot;,
omap3_rom_rng_name); +
+ omap3_rom_rng_call = pdev-dev.platform_data;
+ if (!omap3_rom_rng_call) {
+ printk(KERN_ERR quot;%s: omap3_rom_rng_call is
NULL#92;nquot;,
+omap3_rom_rng_name);
+ return -EINVAL;
+ }
+
+ setup_timer(amp;idle_timer, omap3_rom_idle_rng, 0);
+ rng_clk = clk_get_sys(quot;omap_rngquot;, quot;ickquot;);
+ if (IS_ERR(rng_clk)) {
+ printk(KERN_ERR quot;%s: unable to get RNG clock#92;nquot;,
+omap3_rom_rng_name);
+ return IS_ERR(rng_clk);
+ }
You can use regular clk_get if you add the alias to
struct omap_clk omap3xxx_clks table.
Regards,
Tony
Tony, can you show me how?
--
Pali Rohár
pali.ro...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3 ROM Random Number Generator support
On Sunday 31 March 2013 14:05:42 Ивайло Димитров wrote:
Hi Pali,
Yep, the code looks almost identical, I guess with some tweaks
all SMC code from that patch could be removed and instead
used the one from SMC PPA API.
What I don't get, is why one needs to disable/enable
fiqs/irqs:
+static int call_sec_rom(u32 appl_id, u32 proc_id, u32 flag,
...) +{
+ va_list ap;
+ u32 ret;
+ u32 val;
+
+ va_start(ap, flag);
+ val = *(u32 *) ap;
+ local_irq_disable();
+ local_fiq_disable();
+ ret = omap3_rom_rng_call(appl_id, proc_id, flag,
+ (u32) virt_to_phys((void *) val));
+ local_fiq_enable();
+ local_irq_enable();
+ va_end(ap);
+
+ return ret;
+}
Do you have any idea why is that needed? Any other code I've
ever seen to call SM, does not disable fiqs/irqs, is RNG SMC
somehow special? I know this is Nokia's code, but still, if
we can get some understanding...
Regards,
Ivo
This driver is written by Juha Yrjola and is part of maemo 2.6.28 kernel.
Juha Yrjola, are you still around?
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH] Revert lockdep: check that no locks held at freeze time
On Sun, Mar 31, 2013 at 12:04:40AM +, Paul Walmsley wrote:
This reverts commit 6aa9707099c4b25700940eb3d016f16c4434360d.
Commit 6aa970 causes problems with NFS root filesystems. The failures
were noticed on OMAP2 and 3 boards during kernel init:
[5.508148] [ BUG: swapper/0/1 still has locks held! ]
[5.513610] 3.9.0-rc3-00344-ga937536 #1 Not tainted
[5.518798] -
[5.523773] 1 lock held by swapper/0/1:
[5.527893] #0: (type-s_umount_key#13/1){+.+.+.}, at: [c011e84c]
sget+0x248/0x574
[5.536437]
[5.536437] stack backtrace:
[5.541107] [c001bba8] (unwind_backtrace+0x0/0xf0) from [c05304bc]
(rpc_wait_bit_killable+0x98/0xcc)
[5.551208] [c05304bc] (rpc_wait_bit_killable+0x98/0xcc) from
[c0551600] (__wait_on_bit+0x74/0xb8)
[5.561096] [c0551600] (__wait_on_bit+0x74/0xb8) from [c05516b0]
(out_of_line_wait_on_bit+0x6c/0x78)
[5.571166] [c05516b0] (out_of_line_wait_on_bit+0x6c/0x78) from
[c0530a0c] (__rpc_execute+0xf0/0x360)
[5.581329] [c0530a0c] (__rpc_execute+0xf0/0x360) from [c052a254]
(rpc_run_task+0x98/0xa4)
[5.590515] [c052a254] (rpc_run_task+0x98/0xa4) from [c052a374]
(rpc_call_sync+0x48/0xb4)
[5.599578] [c052a374] (rpc_call_sync+0x48/0xb4) from [c0234964]
(nfs_proc_get_root+0x48/0x124)
[5.609191] [c0234964] (nfs_proc_get_root+0x48/0x124) from [c0227300]
(nfs_get_root+0x58/0x190)
[5.618804] [c0227300] (nfs_get_root+0x58/0x190) from [c022abbc]
(nfs_fs_mount_common+0x98/0x158)
[5.628601] [c022abbc] (nfs_fs_mount_common+0x98/0x158) from
[c022b440] (nfs_try_mount+0x144/0x214)
[5.638580] [c022b440] (nfs_try_mount+0x144/0x214) from [c022c4e0]
(nfs_fs_mount+0x178/0x850)
[5.648010] [c022c4e0] (nfs_fs_mount+0x178/0x850) from [c011f6e8]
(mount_fs+0x44/0x184)
[5.656860] [c011f6e8] (mount_fs+0x44/0x184) from [c01384c4]
(vfs_kern_mount+0x4c/0xc0)
[5.665740] [c01384c4] (vfs_kern_mount+0x4c/0xc0) from [c013a6d4]
(do_mount+0x6d0/0x858)
[5.674682] [c013a6d4] (do_mount+0x6d0/0x858) from [c013a8e0]
(sys_mount+0x84/0xb8)
[5.683197] [c013a8e0] (sys_mount+0x84/0xb8) from [c075faf0]
(do_mount_root+0x24/0xb0)
[5.691986] [c075faf0] (do_mount_root+0x24/0xb0) from [c075fee4]
(mount_root+0x50/0xf8)
[5.700866] [c075fee4] (mount_root+0x50/0xf8) from [c07600ec]
(prepare_namespace+0x160/0x1c4)
[5.710296] [c07600ec] (prepare_namespace+0x160/0x1c4) from [c075f978]
(kernel_init_freeable+0x17c/0x1c4)
[5.720825] [c075f978] (kernel_init_freeable+0x17c/0x1c4) from
[c054b6c4] (kernel_init+0x8/0xe4)
[5.730529] [c054b6c4] (kernel_init+0x8/0xe4) from [c0013d90]
(ret_from_fork+0x14/0x24)
Although the rootfs mounts, the system is unstable. Here's a transcript from
a PM test:
http://www.pwsan.com/omap/testlogs/test_v3.9-rc3/20130317194234/pm/37xxevm/37xxevm_log.txt
Here's what the test log should look like:
http://www.pwsan.com/omap/testlogs/test_v3.8/20130218214403/pm/37xxevm/37xxevm_log.txt
Mailing list discussion is here:
http://lkml.org/lkml/2013/3/4/221
Deal with this for v3.9 by reverting the problem commit, until folks can
figure out the right long-term course of action.
Signed-off-by: Paul Walmsley p...@pwsan.com
...
Cc: Shawn Guo shawn@linaro.org
The same BUG was observed on IMX/MXS systems, so
Acked-by: Shawn Guo shawn@linaro.org
--
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] RX-51: ARM errata 430973 workaround
Closed and signed Nokia X-Loader bootloader stored in RX-51 nand does not set
IBE bit in ACTLR and starting kernel in non-secure mode. So direct write to
ACTLR by our kernel does not working and the code for ARM errata 430973 in
commit 7ce236fcd6fd45b0441a2d49acb2ceb2de2e8a47 that sets IBE bit is a noop.
In order to have workaround for ARM errata 430973 from non-secure world on
RX-51 we needs Secure Monitor Call to set IBE BIT in ACTLR.
This patch adds RX-51 specific SMC support and sets IBE bit in ACTLR during
board init code for ARM errata 430973 workaround.
Because all the setup and what arguments are required for SMC are completely
different from SoC to SoC it is not possible to create generic SMC handling.
Code in omap-smc.S looks identical but it is not. So RX-51 needs another code.
ARM errata 430973 workaround is needed for thumb-2 ISA compiled userspace
binaries. Without this workaround thumb-2 binaries crashing. So with this
patch it is possible to recompile and run applications/binaries with thumb-2
ISA on RX-51.
Signed-off-by: Ivaylo Dimitrov freemangor...@abv.bg
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
arch/arm/mach-omap2/Makefile|1 +
arch/arm/mach-omap2/board-rx51-secure.c | 66 +++
arch/arm/mach-omap2/board-rx51-secure.h | 36 +
arch/arm/mach-omap2/board-rx51-smc.S| 34
arch/arm/mach-omap2/board-rx51.c|7
5 files changed, 144 insertions(+)
create mode 100644 arch/arm/mach-omap2/board-rx51-secure.c
create mode 100644 arch/arm/mach-omap2/board-rx51-secure.h
create mode 100644 arch/arm/mach-omap2/board-rx51-smc.S
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 37c4e09..cc4665d 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -244,6 +244,7 @@ obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o
sdram-nokia.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51-peripherals.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51-video.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51-camera.o
+obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51-smc.o board-rx51-secure.o
obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom.o board-zoom-peripherals.o
obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom-display.o
obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom-debugboard.o
diff --git a/arch/arm/mach-omap2/board-rx51-secure.c
b/arch/arm/mach-omap2/board-rx51-secure.c
new file mode 100644
index 000..361dc78
--- /dev/null
+++ b/arch/arm/mach-omap2/board-rx51-secure.c
@@ -0,0 +1,66 @@
+/*
+ * RX51 Secure PPA API.
+ *
+ * Copyright (C) 2012 Ivaylo Dimitrov freemangor...@abv.bg
+ *
+ *
+ * This program is free software,you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include asm/cacheflush.h
+
+#include board-rx51-secure.h
+
+/**
+ * rx51_secure_dispatcher: Routine to dispatch secure PPA API calls
+ * @idx: The PPA API index
+ * @flag: The flag indicating criticality of operation
+ * @nargs: Number of valid arguments out of four.
+ * @arg1, arg2, arg3 args4: Parameters passed to secure API
+ *
+ * Return the non-zero error value on failure.
+ */
+u32 rx51_secure_dispatcher(u32 idx, u32 flag, u32 nargs, u32 arg1, u32 arg2,
+ u32 arg3, u32 arg4)
+{
+ u32 ret;
+ u32 param[5];
+
+ param[0] = nargs+1;
+ param[1] = arg1;
+ param[2] = arg2;
+ param[3] = arg3;
+ param[4] = arg4;
+
+ /*
+* Secure API needs physical address
+* pointer for the parameters
+*/
+ flush_cache_all();
+ outer_clean_range(__pa(param), __pa(param + 5));
+ ret = rx51_ppa_smc(idx, flag, __pa(param));
+
+ return ret;
+}
+
+/**
+ * rx51_secure_update_aux_cr: Routine to modify the contents of Auxiliary
Control Register
+ * @set_bits: bits to set in ACR
+ * @clr_bits: bits to clear in ACR
+ *
+ * Return the non-zero error value on failure.
+*/
+u32 rx51_secure_update_aux_cr(u32 set_bits, u32 clear_bits)
+{
+ u32 acr;
+
+ /* Read ACR */
+ asm volatile (mrc p15, 0, %0, c1, c0, 1 : =r (acr));
+ acr = ~clear_bits;
+ acr |= set_bits;
+
+ return rx51_secure_dispatcher(RX51_PPA_WRITE_ACR,
+ FLAG_START_CRITICAL,
+ 1,acr,0,0,0);
+}
diff --git a/arch/arm/mach-omap2/board-rx51-secure.h
b/arch/arm/mach-omap2/board-rx51-secure.h
new file mode 100644
index 000..61c760b
--- /dev/null
+++ b/arch/arm/mach-omap2/board-rx51-secure.h
@@ -0,0 +1,36 @@
+/*
+ * board-rx51-secure.h: OMAP Secure infrastructure header.
+ *
+ * Copyright (C) 2012 Ivaylo Dimitrov freemangor...@abv.bg
+ *
+ * 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
+ *
Re: [PATCH 00/28] OMAP: DSS related board file changes
On Sun, Mar 31, 2013 at 11:39:01AM +0300, Igor Grinberg wrote: Well, actually, if there was a way to add a device while somehow marking it so that no driver will be bound to it... Then the user could use the standard sysfs interface to bind a driver to the device. I wonder if that could be done... I don't think this can fit current platform device framework. But may be I'm missing something... May be Greg can comment on this? Greg? I have no idea what you all are talking about, sorry. greg k-h -- 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] Revert OMAP/serial: Fix incorrect Rx FIFO threshold setting, LSR validation on Tx, and Tx FIFO IRQ generation
This reverts commit 1776fd059c40907297d6c26c51876575d63fd9e2.
Commit 1776fd059c40 causes UART sluggishness on the OMAP37xx EVM.
This can be demonstrated by pasting in a ten-character string, like
ff, at the serial console. The string will be echoed back
two to three characters at a time, with about a one-second pause
between groups. This causes one of the OMAP PM validation tests to
time out:
http://www.pwsan.com/omap/testlogs/test_v3.9-rc5/20130331205513/pm/37xxevm/37xxevm_log.txt
With commit 1776fd059c40 reverted, the test succeeds:
http://www.pwsan.com/omap/testlogs/serial_fix_37xx_v3.9-rc/20130331230517/pm/37xxevm/37xxevm_log.txt
This problem has been present since v3.9-rc1, but was incorrectly
suspected to be due to commit 6aa9707099c4b25700940eb3d016f16c4434360d
(lockdep: check that no locks held at freeze time), due to limitations
in my local testbed.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Alexey Pelykh alexey.pel...@gmail.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
---
Alexey, care to make another attempt for 3.11 at fixing the issue you were
originally debugging, but one that also works on OMAP37xx EVM? It would
be good to cc the linux-omap@vger.kernel.org on your OMAP work. If you
don't have a 37xx EVM, someone there might be able to help you test.
drivers/tty/serial/omap-serial.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 4dc4140..9915e4d 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -59,7 +59,6 @@
/* SCR register bitmasks */
#define OMAP_UART_SCR_RX_TRIG_GRANU1_MASK (1 7)
-#define OMAP_UART_SCR_TX_TRIG_GRANU1_MASK (1 6)
#define OMAP_UART_SCR_TX_EMPTY (1 3)
/* FCR register bitmasks */
@@ -321,6 +320,9 @@ static void transmit_chars(struct uart_omap_port *up,
unsigned int lsr)
struct circ_buf *xmit = up-port.state-xmit;
int count;
+ if (!(lsr UART_LSR_THRE))
+ return;
+
if (up-port.x_char) {
serial_out(up, UART_TX, up-port.x_char);
up-port.icount.tx++;
@@ -862,7 +864,7 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
serial_out(up, UART_IER, up-ier);
serial_out(up, UART_LCR, cval); /* reset DLAB */
up-lcr = cval;
- up-scr = 0;
+ up-scr = OMAP_UART_SCR_TX_EMPTY;
/* FIFOs and DMA Settings */
@@ -886,6 +888,8 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
serial_out(up, UART_MCR, up-mcr | UART_MCR_TCRTLR);
/* FIFO ENABLE, DMA MODE */
+ up-scr |= OMAP_UART_SCR_RX_TRIG_GRANU1_MASK;
+
/* Set receive FIFO threshold to 16 characters and
* transmit FIFO threshold to 16 spaces
*/
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP baseline test results for v3.9-rc5
Here are some basic OMAP test results for Linux v3.9-rc5.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.9-rc5/20130331205513/
Test summary
Build:
FAIL ( 2/16): am33xx_only, omap2plus_defconfig_2430sdp_only
Pass (14/16): n800_multi_omap2xxx, n800_only_a, omap1_defconfig,
omap1_defconfig_1510innovator_only,
omap1_defconfig_5912osk_only,
omap2plus_defconfig, omap2plus_defconfig_cpupm,
omap2plus_defconfig_no_pm,
omap2plus_defconfig_omap2_4_only,
omap2plus_defconfig_omap3_4_only,
rmk_omap3430_ldp_allnoconfig,
rmk_omap3430_ldp_oldconfig,
rmk_omap4430_sdp_allnoconfig
rmk_omap4430_sdp_oldconfig
Boot to userspace:
FAIL ( 1/11): am335xbone
Pass (10/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes,
5912osk, cmt3517
PM ret, suspend:
FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes
Pass ( 2/ 6): 3530es3beagle, 3730beaglexm
PM ret, dynamic idle:
FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes
Pass ( 2/ 6): 3530es3beagle, 3730beaglexm
PM off, suspend:
FAIL ( 3/ 5): 37xxevm, 4430es2panda, 4460pandaes
Pass ( 2/ 5): 3530es3beagle, 3730beaglexm
PM off, dynamic idle:
FAIL ( 3/ 5): 37xxevm, 4430es2panda, 4460pandaes
Pass ( 2/ 5): 3530es3beagle, 3730beaglexm
Failing tests: fixed by posted patches
--
Build:
* am33xx_only, omap2plus_defconfig_2430sdp_only: omap-{smp,hotplug}.c link
errors
- Discussion RFC patch:
http://www.spinics.net/lists/arm-kernel/msg230017.html
PM:
* 37xx EVM: UART sluggishness causes timeouts
- Caused by commit 1776fd059c40907297d6c26c51876575d63fd9e2
- http://marc.info/?l=linux-omapm=136479391601254w=2
* 4460pandaes: CORE, L3INIT didn't enter target state
- Caused by 17b7e7d33530e2bbd3bdc90f4db09b91cfdde2bb
(ARM: OMAP4: clock/hwmod data: start to remove some IP block control
clocks)
- Fixed by ARM: OMAP4: PM: fix PM regression introduced by recent clock
cleanup
- http://www.spinics.net/lists/arm-kernel/msg224419.html
Failing tests: needing investigation
Boot tests:
* 3517EVM CM-T3517: boot hangs with NFS root
- Likely some Kconfig, board file, and PM issues with EMAC
- Longstanding bug
- Not currently part of the automated test suite
Boot warnings:
* CM-T3517: L3 in-band error with IPSS during boot
- Cause unknown but see http://marc.info/?l=linux-omapm=134833869730129w=2
- Longstanding issue; does not occur on the 3517EVM
PM tests:
* 2430sdp: pwrdm state mismatch(dsp_pwrdm) 0 != 3
- need to doublecheck wakeup dependencies
- (am assuming it's still there; userspace problems prevent the test
from running, probably due to the lock warning)
* 2430sdp: power domains not entering retention
- Cause unknown
- (am assuming it's still there; userspace problems prevent the test
from running, probably due to the lock warning)
* 4430es2panda, 4460pandaes: pwrdm state mismatch on CAM, DSS, ABE
* 4460pandaes: pwrdm state mismatch on IVAHD, TESLA
* 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state
- Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB
per discussion with Tero Kristo
- Likely dependent on the bootloader version
- fails with 2012.07-00136-g755de79
- http://marc.info/?l=linux-arm-kernelm=136432340618226w=2
* 4460pandaes: chip not entering retention in dynamic idle
- Presumably 4430es2panda also fails this
- Suspend-to-RAM enters full chip retention
* 3730 Beagle XM: does not serial wake from off-idle suspend when console
UART doesn't clock-gate (debug ignore_loglevel)
- Cause unknown
- Not yet part of the automated test suite
- Re-tested at v3.7; still failing:
http://www.pwsan.com/omap/transcripts/20121211-3730beaglexm-3.7-pm-offmode-fail-debug.txt
Other:
* 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
- Unknown cause; could be due to the lack of hierarchical enable/disable
in hwmod code
- Jon Hunter and Santosh Shilimkar report this does not appear with
the same X-loader/bootloader on his 4430ES2.3 Panda, so could be
ES-level dependent
vmlinux object size
(delta in bytes from test_v3.9-rc4 (8bb9660418e05bb1845ac1a2428444d78e322cc7)):
text data bsstotal kernel
+71100 +711 n800_multi_omap2xxx
+69500 +695 n800_only_a
+80900 +809 omap1_defconfig
+81300 +813 omap1_defconfig_1510innovator_only
+5583029 +312636 +117376 +6013041 omap1_defconfig_5912osk_only
+4419 -160+4403 omap2plus_defconfig
+323 -80 +315 omap2plus_defconfig_cpupm
Re: [PATCH 6/8] SERIAL: OMAP: Remove the slave idle handling from the driver
On Sunday 31 March 2013 07:10 AM, Paul Walmsley wrote: (and also please add Greg's ack when this is reposted) Yes. His ack is already picked up in the pull request I sent. Will add a note about DMA support in the commit. Regards, Santosh -- 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
