| Message ID | 1373461145-9812-3-git-send-email-pali.rohar@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
* Pali Rohár <pali.rohar@gmail.com> [130710 06:06]: > --- a/arch/arm/mach-omap2/board-rx51.c > +++ b/arch/arm/mach-omap2/board-rx51.c This file will be gone as soon as we're moving to device tree based booting. So let's do this in more future proof way. > +/** > + * rx51_secure_dispatcher: Routine to dispatch secure PPA API calls > + * @idx: The PPA API index > + * @process: Process ID > + * @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. > + */ > +static u32 rx51_secure_dispatcher(u32 idx, u32 process, u32 flag, u32 nargs, > + u32 arg1, u32 arg2, u32 arg3, u32 arg4) > +{ > + u32 ret; > + u32 param[5]; > + > + param[0] = nargs+1; /* RX-51 needs number of arguments + 1 */ > + param[1] = arg1; > + param[2] = arg2; > + param[3] = arg3; > + param[4] = arg4; > + > + /* > + * Secure API needs physical address > + * pointer for the parameters > + */ > + local_irq_disable(); > + local_fiq_disable(); > + flush_cache_all(); > + outer_clean_range(__pa(param), __pa(param + 5)); > + ret = omap_smc3(idx, process, flag, __pa(param)); > + flush_cache_all(); > + local_fiq_enable(); > + local_irq_enable(); > + > + return ret; > +} I think this used to be in omap-secure.c, and then made rx51 specific.. But since board-rx51.c is going away, let's move this function to omap-secure.c. > + * 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. > +*/ > +static 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, > + 0, > + FLAG_START_CRITICAL, > + 1, acr, 0, 0, 0); > +} This too. > static void __init rx51_init(void) > { > struct omap_sdrc_params *sdrc_params; > @@ -105,6 +175,14 @@ static void __init rx51_init(void) > rx51_peripherals_init(); > rx51_camera_init(); > > + if (omap_type() == OMAP2_DEVICE_TYPE_SEC) { > +#ifdef CONFIG_ARM_ERRATA_430973 > + pr_info("RX-51: Enabling ARM errata 430973 workaround\n"); > + /* set IBE to 1 */ > + rx51_secure_update_aux_cr(BIT(6), 0); > +#endif > + } > + > /* Ensure SDRC pins are mux'd for self-refresh */ > omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT); > omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT); Then this can be called both from board-generic.c based on the compatible flag, and board-rx51.c for now. Regards, Tony
On Wednesday 18 September 2013 01:24:17 Tony Lindgren wrote: > * Pali Rohár <pali.rohar@gmail.com> [130710 06:06]: > > --- a/arch/arm/mach-omap2/board-rx51.c > > +++ b/arch/arm/mach-omap2/board-rx51.c > > This file will be gone as soon as we're moving to device > tree based booting. So let's do this in more future proof > way. > > > +/** > > + * rx51_secure_dispatcher: Routine to dispatch secure PPA > > API calls + * @idx: The PPA API index > > + * @process: Process ID > > + * @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. > > + */ > > +static u32 rx51_secure_dispatcher(u32 idx, u32 process, u32 > > flag, u32 nargs, + u32 arg1, u32 arg2, u32 arg3, u32 > > arg4) > > +{ > > + u32 ret; > > + u32 param[5]; > > + > > + param[0] = nargs+1; /* RX-51 needs number of arguments + 1 > > */ + param[1] = arg1; > > + param[2] = arg2; > > + param[3] = arg3; > > + param[4] = arg4; > > + > > + /* > > + * Secure API needs physical address > > + * pointer for the parameters > > + */ > > + local_irq_disable(); > > + local_fiq_disable(); > > + flush_cache_all(); > > + outer_clean_range(__pa(param), __pa(param + 5)); > > + ret = omap_smc3(idx, process, flag, __pa(param)); > > + flush_cache_all(); > > + local_fiq_enable(); > > + local_irq_enable(); > > + > > + return ret; > > +} > > I think this used to be in omap-secure.c, and then made rx51 > specific.. But since board-rx51.c is going away, let's move > this function to omap-secure.c. > > > + * 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. > > +*/ > > +static 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, > > + 0, > > + FLAG_START_CRITICAL, > > + 1, acr, 0, 0, 0); > > +} > > This too. > > > static void __init rx51_init(void) > > { > > > > struct omap_sdrc_params *sdrc_params; > > > > @@ -105,6 +175,14 @@ static void __init rx51_init(void) > > > > rx51_peripherals_init(); > > rx51_camera_init(); > > > > + if (omap_type() == OMAP2_DEVICE_TYPE_SEC) { > > +#ifdef CONFIG_ARM_ERRATA_430973 > > + pr_info("RX-51: Enabling ARM errata 430973 > > workaround\n"); + /* set IBE to 1 */ > > + rx51_secure_update_aux_cr(BIT(6), 0); > > +#endif > > + } > > + > > > > /* Ensure SDRC pins are mux'd for self-refresh */ > > omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT); > > omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT); > > Then this can be called both from board-generic.c based on the > compatible flag, and board-rx51.c for now. > > Regards, > > Tony Hi Tony, I'm not very happy. I sent this patch 6 months ago and only now you commented that needs rework again. This patch is needed because all thumb-2 userspace binaries crashing. I want to have working support for Nokia N900 and not always rebasing and changing patches. Also DT still not working on N900 (file contains only small subset of devices as in board files plus it is not in stable kernel) so I do not want to switch to DT. I need something which is working and not something new non-working. I belive that you and other kernel guys do not remove all n900 board files until every one line will be rewritten to DT and tested that everything working. And from this and other conversation it looks for me that you are going to do that. So please clarify what you want to do (and when) with board-rx51-* files. Aftethat I can decide what to do in future. For now I see this situation something like: I wrote patches, send them to ML and after half of year maintainer politely rejected them becuase my patches not using new uber cool technology with still not working and also was not available half year ago. What happen if I find another time to rework this patch and send it again in next 2 or 5 months? Tony, if you did not have time for review this patch months ago or you found it only today - no problem, I understand it. But what I need to know is what will happen with board-rx51-* files (and when?) You can see that DT does not have definitions of all n900 hw parts (plus it is not in last 3.11 kernel!) which means that DT is not usable for me and other n900 people. This also means that I cannot rewrite my patches for DT and test if they working.
* Pali Rohár <pali.rohar@gmail.com> [130918 01:41]: > > I'm not very happy. I sent this patch 6 months ago and only now > you commented that needs rework again. This patch is needed > because all thumb-2 userspace binaries crashing. I want to have > working support for Nokia N900 and not always rebasing and > changing patches. Also DT still not working on N900 (file contains > only small subset of devices as in board files plus it is not in > stable kernel) so I do not want to switch to DT. I need something > which is working and not something new non-working. I belive that > you and other kernel guys do not remove all n900 board files until > every one line will be rewritten to DT and tested that everything > working. And from this and other conversation it looks for me > that you are going to do that. So please clarify what you want to > do (and when) with board-rx51-* files. Aftethat I can decide what > to do in future. Sorry if there's been some going back and forth with the patches, I think pretty much everybody wants n900 support in the mainline. It's obvious that we're moving everything to be devicetree only as discussed on the mailing lists over past few years. For most drivers it's already working, and we can still initialize platform data too for the legacy devices until they have bindings, so it should not be too intrusive except for the configuration changes to use appended DTB or a chained bootloader with DTB support. > For now I see this situation something like: I wrote patches, > send them to ML and after half of year maintainer politely > rejected them becuase my patches not using new uber cool > technology with still not working and also was not available half > year ago. What happen if I find another time to rework this patch > and send it again in next 2 or 5 months? Hmm hasn't there been pending comments until recently on your patches? It seems that with the changes I suggested your patches should work for both legacy booting and DT based booting, so maybe just try to update them over next few weeks, let's say by -rc3 rather than wait 2 to 5 months? :) No need to test them currently on the DT based booting if you don't have that set up, just move the code out of the board-*.c file. > Tony, if you did not have time for review this patch months ago > or you found it only today - no problem, I understand it. But > what I need to know is what will happen with board-rx51-* files > (and when?) You can see that DT does not have definitions of all > n900 hw parts (plus it is not in last 3.11 kernel!) which means > that DT is not usable for me and other n900 people. This also > means that I cannot rewrite my patches for DT and test if they > working. I usually stop looking at new code around -rc4 and concentrate on fixes until -rc1 or so. So there can be easily one month delays on reviewing stuff depending on where we are with the current merge window or -rc cycle, sorry if that's annoying. The .dts files will be separate from the kernel soonish, so that's not be a show stopper. Just like all the board specific .config files are separate from the kernel already. Too bad our .dts changes did not get merged for v3.12 because of conflicts with other branches, but hey, they should be independent from the kernel anyways. The board files will be going away as soon as things are working with DT. We've been pretty much only applying fixes to them for quite some time now. For the timeline, the earliest we'll be able to remove the board-*.c files and platform data is for v3.13 assuming the PM dependencies get sorted out before that. Making omap3 DT only is going remove about 25k LOC, so that's a good reason for doing that. Cheers, Tony
Hello, On Wednesday 18 September 2013 19:18:17 Tony Lindgren wrote: > * Pali Rohár <pali.rohar@gmail.com> [130918 01:41]: > > I'm not very happy. I sent this patch 6 months ago and only > > now you commented that needs rework again. This patch is > > needed because all thumb-2 userspace binaries crashing. I > > want to have working support for Nokia N900 and not always > > rebasing and changing patches. Also DT still not working on > > N900 (file contains only small subset of devices as in > > board files plus it is not in stable kernel) so I do not > > want to switch to DT. I need something which is working and > > not something new non-working. I belive that you and other > > kernel guys do not remove all n900 board files until every > > one line will be rewritten to DT and tested that everything > > working. And from this and other conversation it looks for > > me that you are going to do that. So please clarify what > > you want to do (and when) with board-rx51-* files. Aftethat > > I can decide what to do in future. > > Sorry if there's been some going back and forth with the > patches, I think pretty much everybody wants n900 support in > the mainline. > > It's obvious that we're moving everything to be devicetree > only as discussed on the mailing lists over past few years. > For most drivers it's already working, and we can still > initialize platform data too for the legacy devices until > they have bindings, so it should not be too intrusive except > for the configuration changes to use appended DTB or a > chained bootloader with DTB support. > > > For now I see this situation something like: I wrote > > patches, send them to ML and after half of year maintainer > > politely rejected them becuase my patches not using new > > uber cool technology with still not working and also was > > not available half year ago. What happen if I find another > > time to rework this patch and send it again in next 2 or 5 > > months? > > Hmm hasn't there been pending comments until recently on your > patches? > Since 10.07.2013 I do not have any emails for patch 2/2. If I missed something from you, please resend me it. > It seems that with the changes I suggested your patches should > work for both legacy booting and DT based booting, so maybe > just try to update them over next few weeks, let's say by > -rc3 rather than wait 2 to 5 months? :) No need to test them > currently on the DT based booting if you don't have that set > up, just move the code out of the board-*.c file. > Ok, no problem. I will move code as you suggested. > > Tony, if you did not have time for review this patch months > > ago or you found it only today - no problem, I understand > > it. But what I need to know is what will happen with > > board-rx51-* files (and when?) You can see that DT does not > > have definitions of all n900 hw parts (plus it is not in > > last 3.11 kernel!) which means that DT is not usable for me > > and other n900 people. This also means that I cannot > > rewrite my patches for DT and test if they working. > > I usually stop looking at new code around -rc4 and concentrate > on fixes until -rc1 or so. So there can be easily one month > delays on reviewing stuff depending on where we are with the > current merge window or -rc cycle, sorry if that's annoying. > > The .dts files will be separate from the kernel soonish, so > that's not be a show stopper. Just like all the board specific > .config files are separate from the kernel already. Too bad > our .dts changes did not get merged for v3.12 because of > conflicts with other branches, but hey, they should be > independent from the kernel anyways. > > The board files will be going away as soon as things are > working with DT. We've been pretty much only applying fixes > to them for quite some time now. For the timeline, the > earliest we'll be able to remove the board-*.c files and > platform data is for v3.13 assuming the PM dependencies get > sorted out before that. Making omap3 DT only is going remove > about 25k LOC, so that's a good reason for doing that. > > Cheers, > > Tony Thanks for clarification.
* Pali Rohár <pali.rohar@gmail.com> [130918 11:21]: > On Wednesday 18 September 2013 19:18:17 Tony Lindgren wrote: > > > > Hmm hasn't there been pending comments until recently on your > > patches? > > > > Since 10.07.2013 I do not have any emails for patch 2/2. If I > missed something from you, please resend me it. Sorry I noticed it only when looking at them again from "keep in my inbox for applying" or "mark as read and archive" point of view. So no other comments from me are pending. > > It seems that with the changes I suggested your patches should > > work for both legacy booting and DT based booting, so maybe > > just try to update them over next few weeks, let's say by > > -rc3 rather than wait 2 to 5 months? :) No need to test them > > currently on the DT based booting if you don't have that set > > up, just move the code out of the board-*.c file. > > > > Ok, no problem. I will move code as you suggested. Thanks, Tony
Hi! > > Tony, if you did not have time for review this patch months ago > > or you found it only today - no problem, I understand it. But > > what I need to know is what will happen with board-rx51-* files > > (and when?) You can see that DT does not have definitions of all > > n900 hw parts (plus it is not in last 3.11 kernel!) which means > > that DT is not usable for me and other n900 people. This also > > means that I cannot rewrite my patches for DT and test if they > > working. > > I usually stop looking at new code around -rc4 and concentrate > on fixes until -rc1 or so. So there can be easily one month > delays on reviewing stuff depending on where we are with the > current merge window or -rc cycle, sorry if that's annoying. > > The .dts files will be separate from the kernel soonish, so > that's not be a show stopper. Just like all the board specific > .config files are separate from the kernel already. Too bad our > .dts changes did not get merged for v3.12 because of conflicts > with other branches, but hey, they should be independent from the > kernel anyways. Well... I'd say it is still time to merge them. "New hardware support" is ok after -rc1. > The board files will be going away as soon as things are working > with DT. We've been pretty much only applying fixes to them for > quite some time now. For the timeline, the earliest we'll be able > to remove the board-*.c files and platform data is for v3.13 And it would be good to merge n900 dts support for 3.12. Adding device tree at the same release as removing board support files in same release leaves zero room for testing, and practically guarantees regressions. Pavel
* Pavel Machek <pavel@ucw.cz> [130923 17:23]: > Hi! > > > > Tony, if you did not have time for review this patch months ago > > > or you found it only today - no problem, I understand it. But > > > what I need to know is what will happen with board-rx51-* files > > > (and when?) You can see that DT does not have definitions of all > > > n900 hw parts (plus it is not in last 3.11 kernel!) which means > > > that DT is not usable for me and other n900 people. This also > > > means that I cannot rewrite my patches for DT and test if they > > > working. > > > > I usually stop looking at new code around -rc4 and concentrate > > on fixes until -rc1 or so. So there can be easily one month > > delays on reviewing stuff depending on where we are with the > > current merge window or -rc cycle, sorry if that's annoying. > > > > The .dts files will be separate from the kernel soonish, so > > that's not be a show stopper. Just like all the board specific > > .config files are separate from the kernel already. Too bad our > > .dts changes did not get merged for v3.12 because of conflicts > > with other branches, but hey, they should be independent from the > > kernel anyways. > > Well... I'd say it is still time to merge them. "New hardware support" > is ok after -rc1. Sure if there's a good reason like "driver foo is already device tree only and cannot be used for board bar without blah". > > The board files will be going away as soon as things are working > > with DT. We've been pretty much only applying fixes to them for > > quite some time now. For the timeline, the earliest we'll be able > > to remove the board-*.c files and platform data is for v3.13 > > And it would be good to merge n900 dts support for 3.12. Adding > device tree at the same release as removing board support files in > same release leaves zero room for testing, and practically guarantees > regressions. Yes we experienced that with omap4 conversion where it caused some wl12xx regression. So we might want to keep some omap3 board files around until v3.14 if necessary. Also please take a look at the "[PATCH 0/4] Clean up legacy platform data handling for omaps for v3.13" patches I posted few days ago, those should make it easy to have board specific pdata quirks for DT based booting. Regards, Tony
diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c index 03663c2..f234dee 100644 --- a/arch/arm/mach-omap2/board-rx51.c +++ b/arch/arm/mach-omap2/board-rx51.c @@ -2,6 +2,8 @@ * Board support file for Nokia N900 (aka RX-51). * * Copyright (C) 2007, 2008 Nokia + * Copyright (C) 2012 Ivaylo Dimitrov <freemangordon@abv.bg> + * Copyright (C) 2013 Pali Rohár <pali.rohar@gmail.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 @@ -21,6 +23,7 @@ #include <linux/usb/musb.h> #include <linux/platform_data/spi-omap2-mcspi.h> +#include <asm/cacheflush.h> #include <asm/mach-types.h> #include <asm/mach/arch.h> #include <asm/mach/map.h> @@ -31,7 +34,14 @@ #include "mux.h" #include "gpmc.h" #include "pm.h" +#include "soc.h" #include "sdram-nokia.h" +#include "omap-secure.h" + +/* Secure PPA (Primary Protected Application) APIs */ +#define RX51_PPA_HWRNG 29 +#define RX51_PPA_L2_INVAL 40 +#define RX51_PPA_WRITE_ACR 42 #define RX51_GPIO_SLEEP_IND 162 @@ -90,6 +100,66 @@ static struct omap_musb_board_data musb_board_data = { .power = 0, }; +/** + * rx51_secure_dispatcher: Routine to dispatch secure PPA API calls + * @idx: The PPA API index + * @process: Process ID + * @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. + */ +static u32 rx51_secure_dispatcher(u32 idx, u32 process, u32 flag, u32 nargs, + u32 arg1, u32 arg2, u32 arg3, u32 arg4) +{ + u32 ret; + u32 param[5]; + + param[0] = nargs+1; /* RX-51 needs number of arguments + 1 */ + param[1] = arg1; + param[2] = arg2; + param[3] = arg3; + param[4] = arg4; + + /* + * Secure API needs physical address + * pointer for the parameters + */ + local_irq_disable(); + local_fiq_disable(); + flush_cache_all(); + outer_clean_range(__pa(param), __pa(param + 5)); + ret = omap_smc3(idx, process, flag, __pa(param)); + flush_cache_all(); + local_fiq_enable(); + local_irq_enable(); + + 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. +*/ +static 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, + 0, + FLAG_START_CRITICAL, + 1, acr, 0, 0, 0); +} + static void __init rx51_init(void) { struct omap_sdrc_params *sdrc_params; @@ -105,6 +175,14 @@ static void __init rx51_init(void) rx51_peripherals_init(); rx51_camera_init(); + if (omap_type() == OMAP2_DEVICE_TYPE_SEC) { +#ifdef CONFIG_ARM_ERRATA_430973 + pr_info("RX-51: Enabling ARM errata 430973 workaround\n"); + /* set IBE to 1 */ + rx51_secure_update_aux_cr(BIT(6), 0); +#endif + } + /* Ensure SDRC pins are mux'd for self-refresh */ omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT); omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);