* [PATCH 1/4] ARM: runtime patching of __virt_to_phys() and __phys_to_virt()
From: Russell King - ARM Linux @ 2011-01-04 16:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1101040926100.22191@xanadu.home>
On Tue, Jan 04, 2011 at 09:32:41AM -0500, Nicolas Pitre wrote:
> On Tue, 4 Jan 2011, Russell King - ARM Linux wrote:
> > This is basically my patch with a few blank lines removed, a couple
> > of \n's also removed, a #error if __virt_to_phys is defined by a platform,
> > a minor tweak to the assembly and it being only usable on PXA.
> >
> > I much prefer my patch over this as anyone can use it. That's one of
> > the reasons why I arranged the code testing for __virt_to_phys as I
> > did, so the config option could be offered without having a big long
> > dependency list attached to it.
>
> I don't think offering the option that people can turn on and not having
> the code effectively perform as expected is a good idea. People might
> be expecting the feature to be there while in practice it is ignored
> which would lead to confusion.
Our aims are different then. My aim is to move the code to a point where
it works for _everyone_ it possibly can - and theoretically that's every
platform except:
1. MSM due to their PHYS_OFFSET being 2MB aligned, rather than the more
normal 256MB alignment.
2. Anyone with complex V:P mappings
(1) is dealt with easily by a dependency in the configuration preventing
the option being visible. (2) is dealt with at runtime by ignoring the
configuration option - resulting in the p2v tables being empty. The end
result will still run on the platform, but it won't do the relocation
stuff. (2) could also be dealt with by adding the necessary dependencies
to the configuration option which is the longer term solution.
Lastly, marking the option as 'EXPERIMENTAL' is there to convey that it
may not work for everyone, and people should expect things not to work if
they enable such an option (and report when that's the case.)
Another reason why selecting this option is wrong is that it is incompatible
with XIP. If you're going to unconditionally enable it for platforms like
PXA, make sure you strip out all of PXA's XIP support before you do so,
otherwise you'll build a kernel which has absolutely no way of ever booting.
> As to the authorship, since I drafted the original design, Eric Miao did
> the first implementation to validate the concept, and the code surviving
> is mostly yours, I didn't know who to singularly attribute the patch to
> in the author field. I can put yourself there if you feel this is more
> appropriate.
The correct thing to do is to ensure that it has Eric's and my sign-offs.
If you compare Eric's to my version, mine has a fair amount of changes.
^ permalink raw reply
* [PATCHv8 00/12] Contiguous Memory Allocator
From: Michał Nazarewicz @ 2011-01-04 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C832F8F5D375BD43BFA11E82E0FE9FE00829C13EB2@EXDCVYMBSTM005.EQ1STM.local>
> Russell King wrote:
>> Has anyone addressed my issue with it that this is wide-open for
>> abuse by allocating large chunks of memory, and then remapping
>> them in some way with different attributes, thereby violating the
>> ARM architecture specification?
2011/1/4 Johan MOSSBERG <johan.xx.mossberg@stericsson.com>:
> Where in the specification (preferably ARMv7) can I find
> information about this? Is the problem that it is simply
> forbidden to map an address multiple times with different cache
> setting and if this is done the hardware might start failing? Or
> is the problem that having an address mapped cached means that
> speculative pre-fetch can read it into the cache at any time,
> possibly causing problems if an un-cached mapping exists?
IIRC both apply.
^ permalink raw reply
* [PATCHv8 00/12] Contiguous Memory Allocator
From: Russell King - ARM Linux @ 2011-01-04 17:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C832F8F5D375BD43BFA11E82E0FE9FE00829C13EB2@EXDCVYMBSTM005.EQ1STM.local>
On Tue, Jan 04, 2011 at 05:23:37PM +0100, Johan MOSSBERG wrote:
> Russell King wrote:
> > Has anyone addressed my issue with it that this is wide-open for
> > abuse by allocating large chunks of memory, and then remapping
> > them in some way with different attributes, thereby violating the
> > ARM architecture specification?
>
> I seem to have missed the previous discussion about this issue.
> Where in the specification (preferably ARMv7) can I find
> information about this?
Here's the extracts from the architecture reference manual:
* If the same memory locations are marked as having different
cacheability attributes, for example by the use of aliases in a
virtual to physical address mapping, behavior is UNPREDICTABLE.
A3.5.7 Memory access restrictions
Behavior is UNPREDICTABLE if the same memory location:
* is marked as Shareable Normal and Non-shareable Normal
* is marked as having different memory types (Normal, Device, or
Strongly-ordered)
* is marked as having different cacheability attributes
* is marked as being Shareable Device and Non-shareable Device memory.
Such memory marking contradictions can occur, for example, by the use of
aliases in a virtual to physical address mapping.
Glossary:
UNPREDICTABLE
Means the behavior cannot be relied upon. UNPREDICTABLE behavior must not
represent security holes. UNPREDICTABLE behavior must not halt or hang
the processor, or any parts of the system. UNPREDICTABLE behavior must not
be documented or promoted as having a defined effect.
> Is the problem that it is simply
> forbidden to map an address multiple times with different cache
> setting and if this is done the hardware might start failing? Or
> is the problem that having an address mapped cached means that
> speculative pre-fetch can read it into the cache at any time,
> possibly causing problems if an un-cached mapping exists? In my
> opinion option number two can be handled and I've made an attempt
> at doing that in hwmem (posted on linux-mm a while ago), look in
> cache_handler.c. Hwmem currently does not use cma but the next
> version probably will.
Given the extract from the architecture reference manual, do you want
to run a system where you can't predict what the behaviour will be if
you have two mappings present, one which is cacheable and one which is
non-cacheable, and you're relying on the non-cacheable mapping to never
return data from the cache?
What if during your testing, it appears to work correctly, but out in
the field, someone's loaded a different application to your setup
resulting in different memory access patterns, causing cache lines to
appear in the non-cacheable mapping, and then the CPU hits them on
subsequent accesses corrupting data...
You can't say that will never happen if you're relying on this
unpredictable behaviour.
^ permalink raw reply
* [PATCH v6 1/2] ARM: mx5: dynamically allocate pwm devices
From: Fabio Estevam @ 2011-01-04 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=rTbL2SHCPtn5sGQ4O1x+DgOHfJOEi3fG7ZrZy@mail.gmail.com>
Uwe/Sascha,
Any comments about this series?
Regards,
Fabio Estevam
On Tue, Dec 7, 2010 at 5:20 PM, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Uwe,
>
> Does this series look OK now?
>
> Thanks,
>
> Fabio Estevam
>
>
> On Wed, Dec 1, 2010 at 11:11 AM, Fabio Estevam
> <fabio.estevam@freescale.com> wrote:
>> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
>> ---
>> ?arch/arm/mach-mx5/devices-imx51.h ? ? ? ? ? ?| ? ?4 ++++
>> ?arch/arm/plat-mxc/devices/platform-mxc_pwm.c | ? ?9 +++++++++
>> ?arch/arm/plat-mxc/include/mach/mx51.h ? ? ? ?| ? ?4 ++--
>> ?3 files changed, 15 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-mx5/devices-imx51.h b/arch/arm/mach-mx5/devices-imx51.h
>> index 939d2e8..e4bc426 100644
>> --- a/arch/arm/mach-mx5/devices-imx51.h
>> +++ b/arch/arm/mach-mx5/devices-imx51.h
>> @@ -47,3 +47,7 @@ extern const struct imx_spi_imx_data imx51_ecspi_data[] __initconst;
>> ?extern const struct imx_imx2_wdt_data imx51_imx2_wdt_data __initconst;
>> ?#define imx51_imx2_wdt_data(pdata) ? ? \
>> ? ? ? ?imx_add_imx2_wdt_data(&imx51_imx2_wdt_data, pdata)
>> +
>> +extern const struct imx_mxc_pwm_data imx51_mxc_pwm_data[] __initconst;
>> +#define imx51_add_mxc_pwm(id, pdata) ? \
>> + ? ? ? imx_add_mxc_pwm(&imx51_mxc_pwm_data[id], pdata)
>> diff --git a/arch/arm/plat-mxc/devices/platform-mxc_pwm.c b/arch/arm/plat-mxc/devices/platform-mxc_pwm.c
>> index 3d8ebdb..b0c4ae2 100644
>> --- a/arch/arm/plat-mxc/devices/platform-mxc_pwm.c
>> +++ b/arch/arm/plat-mxc/devices/platform-mxc_pwm.c
>> @@ -40,6 +40,15 @@ const struct imx_mxc_pwm_data imx27_mxc_pwm_data __initconst =
>> ? ? ? ?imx_mxc_pwm_data_entry_single(MX27, 0, , SZ_4K);
>> ?#endif /* ifdef CONFIG_SOC_IMX27 */
>>
>> +#ifdef CONFIG_SOC_IMX51
>> +const struct imx_mxc_pwm_data imx51_mxc_pwm_data[] __initconst = {
>> +#define imx51_mxc_pwm_data_entry(_id, _hwid) ? ? ? ? ? ? ? ? ? ? ? ? ? \
>> + ? ? ? imx_mxc_pwm_data_entry(MX51, _id, _hwid, SZ_16K)
>> + ? ? ? imx51_mxc_pwm_data_entry(0, 1),
>> + ? ? ? imx51_mxc_pwm_data_entry(1, 2),
>> +};
>> +#endif /* ifdef CONFIG_SOC_IMX51 */
>> +
>> ?struct platform_device *__init imx_add_mxc_pwm(
>> ? ? ? ? ? ? ? ?const struct imx_mxc_pwm_data *data)
>> ?{
>> diff --git a/arch/arm/plat-mxc/include/mach/mx51.h b/arch/arm/plat-mxc/include/mach/mx51.h
>> index 8fddfef..54b58a0 100644
>> --- a/arch/arm/plat-mxc/include/mach/mx51.h
>> +++ b/arch/arm/plat-mxc/include/mach/mx51.h
>> @@ -302,7 +302,7 @@
>> ?#define MX51_MXC_INT_WDOG1 ? ? ? ? ? ? 58
>> ?#define MX51_MXC_INT_WDOG2 ? ? ? ? ? ? 59
>> ?#define MX51_MXC_INT_KPP ? ? ? ? ? ? ? 60
>> -#define MX51_MXC_INT_PWM1 ? ? ? ? ? ? ?61
>> +#define MX51_INT_PWM1 ? ? ? ? ? ? ? ? ?61
>> ?#define MX51_INT_I2C1 ? ? ? ? ? ? ? ? ?62
>> ?#define MX51_INT_I2C2 ? ? ? ? ? ? ? ? ?63
>> ?#define MX51_MXC_INT_HS_I2C ? ? ? ? ? ?64
>> @@ -335,7 +335,7 @@
>> ?#define MX51_MXC_INT_SPDIF ? ? ? ? ? ? 91
>> ?#define MX51_MXC_INT_TVE ? ? ? ? ? ? ? 92
>> ?#define MX51_MXC_INT_FIRI ? ? ? ? ? ? ?93
>> -#define MX51_MXC_INT_PWM2 ? ? ? ? ? ? ?94
>> +#define MX51_INT_PWM2 ? ? ? ? ? ? ? ? ?94
>> ?#define MX51_MXC_INT_SLIM_EXP ? ? ? ? ?95
>> ?#define MX51_MXC_INT_SSI3 ? ? ? ? ? ? ?96
>> ?#define MX51_MXC_INT_EMI_BOOT ? ? ? ? ?97
>> --
>> 1.6.0.4
>>
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>
^ permalink raw reply
* [PATCH v5] davinci: Support various speedgrades for MityDSP-L138 and MityARM-1808 SoMs
From: Kevin Hilman @ 2011-01-04 17:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294145423-18245-1-git-send-email-michael.williamson@criticallink.com>
Michael Williamson <michael.williamson@criticallink.com> writes:
> For the MityDSP-L138/MityARM-1808 SoMs, the speed grade can be determined
> from the part number string read from the factory configuration block on
> the on-board I2C PROM. Configure the maximum CPU speed based on this
> information.
>
> This patch was tested using a MityDSP-L138 and MityARM-1808 at various
> speedgrades. Also, for code coverage, a bogus configuration was tested
> as well as a configuration having an unknown part number.
>
> Signed-off-by: Michael Williamson <michael.williamson@criticallink.com>
> Tested-by: Michael Williamson <michael.williamson@criticallink.com>
> Reviewed-by: Sekhar Nori <nsekhar@ti.com>
> ---
> Changes since v4.
>
> - Fixup indenting on if block per comments.
Thanks, queuing this for 2.6.39.
Kevin
> arch/arm/mach-davinci/board-mityomapl138.c | 83 +++++++++++++++++++++++++---
> 1 files changed, 75 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
> index 0bb5f0c..0ea5932 100644
> --- a/arch/arm/mach-davinci/board-mityomapl138.c
> +++ b/arch/arm/mach-davinci/board-mityomapl138.c
> @@ -44,38 +44,109 @@ struct factory_config {
>
> static struct factory_config factory_config;
>
> +struct part_no_info {
> + const char *part_no; /* part number string of interest */
> + int max_freq; /* khz */
> +};
> +
> +static struct part_no_info mityomapl138_pn_info[] = {
> + {
> + .part_no = "L138-C",
> + .max_freq = 300000,
> + },
> + {
> + .part_no = "L138-D",
> + .max_freq = 375000,
> + },
> + {
> + .part_no = "L138-F",
> + .max_freq = 456000,
> + },
> + {
> + .part_no = "1808-C",
> + .max_freq = 300000,
> + },
> + {
> + .part_no = "1808-D",
> + .max_freq = 375000,
> + },
> + {
> + .part_no = "1808-F",
> + .max_freq = 456000,
> + },
> + {
> + .part_no = "1810-D",
> + .max_freq = 375000,
> + },
> +};
> +
> +#ifdef CONFIG_CPU_FREQ
> +static void mityomapl138_cpufreq_init(const char *partnum)
> +{
> + int i, ret;
> +
> + for (i = 0; partnum && i < ARRAY_SIZE(mityomapl138_pn_info); i++) {
> + /*
> + * the part number has additional characters beyond what is
> + * stored in the table. This information is not needed for
> + * determining the speed grade, and would require several
> + * more table entries. Only check the first N characters
> + * for a match.
> + */
> + if (!strncmp(partnum, mityomapl138_pn_info[i].part_no,
> + strlen(mityomapl138_pn_info[i].part_no))) {
> + da850_max_speed = mityomapl138_pn_info[i].max_freq;
> + break;
> + }
> + }
> +
> + ret = da850_register_cpufreq("pll0_sysclk3");
> + if (ret)
> + pr_warning("cpufreq registration failed: %d\n", ret);
> +}
> +#else
> +static void mityomapl138_cpufreq_init(const char *partnum) { }
> +#endif
> +
> static void read_factory_config(struct memory_accessor *a, void *context)
> {
> int ret;
> + const char *partnum = NULL;
> struct davinci_soc_info *soc_info = &davinci_soc_info;
>
> ret = a->read(a, (char *)&factory_config, 0, sizeof(factory_config));
> if (ret != sizeof(struct factory_config)) {
> pr_warning("MityOMAPL138: Read Factory Config Failed: %d\n",
> ret);
> - return;
> + goto bad_config;
> }
>
> if (factory_config.magic != FACTORY_CONFIG_MAGIC) {
> pr_warning("MityOMAPL138: Factory Config Magic Wrong (%X)\n",
> factory_config.magic);
> - return;
> + goto bad_config;
> }
>
> if (factory_config.version != FACTORY_CONFIG_VERSION) {
> pr_warning("MityOMAPL138: Factory Config Version Wrong (%X)\n",
> factory_config.version);
> - return;
> + goto bad_config;
> }
>
> pr_info("MityOMAPL138: Found MAC = %pM\n", factory_config.mac);
> - pr_info("MityOMAPL138: Part Number = %s\n", factory_config.partnum);
> if (is_valid_ether_addr(factory_config.mac))
> memcpy(soc_info->emac_pdata->mac_addr,
> factory_config.mac, ETH_ALEN);
> else
> pr_warning("MityOMAPL138: Invalid MAC found "
> "in factory config block\n");
> +
> + partnum = factory_config.partnum;
> + pr_info("MityOMAPL138: Part Number = %s\n", partnum);
> +
> +bad_config:
> + /* default maximum speed is valid for all platforms */
> + mityomapl138_cpufreq_init(partnum);
> }
>
> static struct at24_platform_data mityomapl138_fd_chip = {
> @@ -383,10 +454,6 @@ static void __init mityomapl138_init(void)
> if (ret)
> pr_warning("rtc setup failed: %d\n", ret);
>
> - ret = da850_register_cpufreq("pll0_sysclk3");
> - if (ret)
> - pr_warning("cpufreq registration failed: %d\n", ret);
> -
> ret = da8xx_register_cpuidle();
> if (ret)
> pr_warning("cpuidle registration failed: %d\n", ret);
^ permalink raw reply
* [PATCHv8 00/12] Contiguous Memory Allocator
From: Santosh Shilimkar @ 2011-01-04 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110104171928.GB24935@n2100.arm.linux.org.uk>
> -----Original Message-----
> From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux-
> arm-kernel-bounces at lists.infradead.org] On Behalf Of Russell King -
> ARM Linux
> Sent: Tuesday, January 04, 2011 10:49 PM
> To: Johan MOSSBERG
> Cc: Daniel Walker; Kyungmin Park; Mel Gorman; KAMEZAWA Hiroyuki;
> Michal Nazarewicz; linux-kernel at vger.kernel.org; Michal Nazarewicz;
> linux-mm at kvack.org; Ankita Garg; Andrew Morton; Marek Szyprowski;
> linux-arm-kernel at lists.infradead.org; linux-media at vger.kernel.org
> Subject: Re: [PATCHv8 00/12] Contiguous Memory Allocator
>
> On Tue, Jan 04, 2011 at 05:23:37PM +0100, Johan MOSSBERG wrote:
> > Russell King wrote:
> > > Has anyone addressed my issue with it that this is wide-open for
> > > abuse by allocating large chunks of memory, and then remapping
> > > them in some way with different attributes, thereby violating
> the
> > > ARM architecture specification?
> >
> > I seem to have missed the previous discussion about this issue.
> > Where in the specification (preferably ARMv7) can I find
> > information about this?
>
> Here's the extracts from the architecture reference manual:
>
> * If the same memory locations are marked as having different
> cacheability attributes, for example by the use of aliases in a
> virtual to physical address mapping, behavior is UNPREDICTABLE.
>
> A3.5.7 Memory access restrictions
>
> Behavior is UNPREDICTABLE if the same memory location:
> * is marked as Shareable Normal and Non-shareable Normal
> * is marked as having different memory types (Normal, Device, or
> Strongly-ordered)
> * is marked as having different cacheability attributes
> * is marked as being Shareable Device and Non-shareable Device
> memory.
>
> Such memory marking contradictions can occur, for example, by the
> use of
> aliases in a virtual to physical address mapping.
>
> Glossary:
> UNPREDICTABLE
> Means the behavior cannot be relied upon. UNPREDICTABLE behavior
> must not
> represent security holes. UNPREDICTABLE behavior must not halt or
> hang
> the processor, or any parts of the system. UNPREDICTABLE behavior
> must not
> be documented or promoted as having a defined effect.
>
> > Is the problem that it is simply
> > forbidden to map an address multiple times with different cache
> > setting and if this is done the hardware might start failing? Or
> > is the problem that having an address mapped cached means that
> > speculative pre-fetch can read it into the cache at any time,
> > possibly causing problems if an un-cached mapping exists? In my
> > opinion option number two can be handled and I've made an attempt
> > at doing that in hwmem (posted on linux-mm a while ago), look in
> > cache_handler.c. Hwmem currently does not use cma but the next
> > version probably will.
>
> Given the extract from the architecture reference manual, do you
> want
> to run a system where you can't predict what the behaviour will be
> if
> you have two mappings present, one which is cacheable and one which
> is
> non-cacheable, and you're relying on the non-cacheable mapping to
> never
> return data from the cache?
>
> What if during your testing, it appears to work correctly, but out
> in
> the field, someone's loaded a different application to your setup
> resulting in different memory access patterns, causing cache lines
> to
> appear in the non-cacheable mapping, and then the CPU hits them on
> subsequent accesses corrupting data...
>
> You can't say that will never happen if you're relying on this
> unpredictable behaviour.
>
Just to add to Russell's point, we did land up in un-traceable
CPU deadlocks while running the kernel which was violating some of
the rules set by ARM ARM.
The usecase use to work ~98% of the time.
Regards,
Santosh
^ permalink raw reply
* [PATCH 2/4] arm: Kconfig: remove duplicated GENERIC_HARDIRQS entry
From: Russell King - ARM Linux @ 2011-01-04 17:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110104140031.GE25121@pengutronix.de>
On Tue, Jan 04, 2011 at 03:00:31PM +0100, Uwe Kleine-K?nig wrote:
> On Tue, Jan 04, 2011 at 02:02:55PM +0200, Felipe Balbi wrote:
> > GENERIC_HARDIRQS is defined under kernel/irq/Kconfig,
> > so it's safe to drop the duplicated entry and simply
> > select HAVE_GENERIC_HARDIRQS.
> >
> > Signed-off-by: Felipe Balbi <balbi@ti.com>
> > ---
> > arch/arm/Kconfig | 8 +-------
> > 1 files changed, 1 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index d56d21c0..e6f0f8b 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -15,6 +15,7 @@ config ARM
> > select HAVE_FTRACE_MCOUNT_RECORD if (!XIP_KERNEL)
> > select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL)
> > select HAVE_GENERIC_DMA_COHERENT
> > + select HAVE_GENERIC_HARDIRQS
> > select HAVE_KERNEL_GZIP
> > select HAVE_KERNEL_LZO
> > select HAVE_KERNEL_LZMA
> > @@ -88,10 +89,6 @@ config MCA
> > <file:Documentation/mca.txt> (and especially the web page given
> > there) before attempting to build an MCA bus kernel.
> >
> > -config GENERIC_HARDIRQS
> > - bool
> > - default y
> > -
> > config STACKTRACE_SUPPORT
> > bool
> > default y
> > @@ -171,9 +168,6 @@ config FIQ
> > config ARCH_MTD_XIP
> > bool
> >
> > -config GENERIC_HARDIRQS_NO__DO_IRQ
> > - def_bool y
> > -
> You didn't mention this change in the commit log. Is this duplicated,
> too or did it just slip through?
If you look at kernel/irq/Kconfig (as I did with the original patch)
you'd notice kernel/irq/Kconfig defines both of these symbols being
removed when HAVE_GENERIC_HARDIRQS is enabled.
If you read the discussion in the previous version of this patch set,
you'd notice that the removal of this was specifically requested.
It's very tiresome to have to re-explain these things. Please take
some more time to research the points you bring up, rather than
impulse-replying.
^ permalink raw reply
* [PATCH 1/4] ARM: runtime patching of __virt_to_phys() and __phys_to_virt()
From: Nicolas Pitre @ 2011-01-04 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110104165347.GA24935@n2100.arm.linux.org.uk>
On Tue, 4 Jan 2011, Russell King - ARM Linux wrote:
> On Tue, Jan 04, 2011 at 09:32:41AM -0500, Nicolas Pitre wrote:
> > On Tue, 4 Jan 2011, Russell King - ARM Linux wrote:
> > > This is basically my patch with a few blank lines removed, a couple
> > > of \n's also removed, a #error if __virt_to_phys is defined by a platform,
> > > a minor tweak to the assembly and it being only usable on PXA.
> > >
> > > I much prefer my patch over this as anyone can use it. That's one of
> > > the reasons why I arranged the code testing for __virt_to_phys as I
> > > did, so the config option could be offered without having a big long
> > > dependency list attached to it.
> >
> > I don't think offering the option that people can turn on and not having
> > the code effectively perform as expected is a good idea. People might
> > be expecting the feature to be there while in practice it is ignored
> > which would lead to confusion.
>
> Our aims are different then. My aim is to move the code to a point where
> it works for _everyone_ it possibly can - and theoretically that's every
> platform except:
>
> 1. MSM due to their PHYS_OFFSET being 2MB aligned, rather than the more
> normal 256MB alignment.
> 2. Anyone with complex V:P mappings
I completely agree with that goal. But I'd prefer for those platforms
which are not yet supported by this feature not to be able to compile
rather than silently ignore the feature and not behave as expected.
> (1) is dealt with easily by a dependency in the configuration preventing
> the option being visible. (2) is dealt with at runtime by ignoring the
> configuration option - resulting in the p2v tables being empty. The end
> result will still run on the platform, but it won't do the relocation
> stuff. (2) could also be dealt with by adding the necessary dependencies
> to the configuration option which is the longer term solution.
Since (2) is not supported yet with this config option selected, I think
it is best to simply #error the build.
> Lastly, marking the option as 'EXPERIMENTAL' is there to convey that it
> may not work for everyone, and people should expect things not to work if
> they enable such an option (and report when that's the case.)
Sure, hence my #error in the patch which is even easier to diagnose and
self explanatory.
And in fact I think that this would indeed be simpler to just fall back
to a global variable for PHYS_OFFSET when a platform defines its own
p2v/v2p mapping. This way, the goal of this feature would be
universally available.
OTOH, one of the long term goal for this is to be able to support more
than one SOC family with the same kernel binary. I don't think it is
worth extending this support to be able to also include those platforms
with a complex v2p and p2v translation, as the overhead for all included
platforms would simply kill the advantages of having a single kernel
binary. So I still don't see a big compelling reason to support (2) at
all with this, except maybe only for kdump purposes.
> Another reason why selecting this option is wrong is that it is incompatible
> with XIP. If you're going to unconditionally enable it for platforms like
> PXA, make sure you strip out all of PXA's XIP support before you do so,
> otherwise you'll build a kernel which has absolutely no way of ever booting.
Well, my idea is more about a global config option that makes sense for
the user, like "physically position independent kernel binary" or
something like that. This option would of course be dependent on !XIP
and !ZBOOT_ROM, and would in turn select AUTO_ZRELADDR and
ARM_PATCH_PHYS_VIRT. In fact, maybe those options should all be
consolidated under a single generic config option expressing the goal to
be achieved instead of the implementation strategy.
> > As to the authorship, since I drafted the original design, Eric Miao did
> > the first implementation to validate the concept, and the code surviving
> > is mostly yours, I didn't know who to singularly attribute the patch to
> > in the author field. I can put yourself there if you feel this is more
> > appropriate.
>
> The correct thing to do is to ensure that it has Eric's and my
> sign-offs.
Fair enough.
> If you compare Eric's to my version, mine has a fair amount of
> changes.
Yep, and I'm now adding to the mix. So this is a good idea to clarify
this issue.
Nicolas
^ permalink raw reply
* [PATCH] OMAP: GPIO: fix _set_gpio_triggering() for OMAP2+
From: Kevin Hilman @ 2011-01-04 17:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1293620491-7201-1-git-send-email-ext-mika.1.westerberg@nokia.com>
Mika Westerberg <ext-mika.1.westerberg@nokia.com> writes:
> In case on OMAP2+ we call set_24xx_gpio_triggering() instead of
> updating reg and l values. However, at the end of the function we
> perform a write:
>
> __raw_writel(l, reg);
>
> So on OMAP2+ we end up writing 0 to the bank->base which is not
> correct (typically this points to GPIO_REVISION register).
>
> Fix this by returning immediately after call to
> set_24xx_gpio_triggering().
>
> Signed-off-by: Mika Westerberg <ext-mika.1.westerberg@nokia.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Tony, this should be added to omap-for-linus as it fixes a problem in
the recently merged GPIO omap_device/hwmod conversion.
Thanks,
Kevin
> ---
> arch/arm/plat-omap/gpio.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
> index c05c653..4dcb66f 100644
> --- a/arch/arm/plat-omap/gpio.c
> +++ b/arch/arm/plat-omap/gpio.c
> @@ -867,7 +867,7 @@ static int _set_gpio_triggering(struct gpio_bank *bank, int gpio, int trigger)
> case METHOD_GPIO_24XX:
> case METHOD_GPIO_44XX:
> set_24xx_gpio_triggering(bank, gpio, trigger);
> - break;
> + return 0;
> #endif
> default:
> goto bad;
^ permalink raw reply
* [PATCH 2/4] ARM: make PHYS_OFFSET actually variable
From: Nicolas Pitre @ 2011-01-04 17:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110104123049.GC16671@n2100.arm.linux.org.uk>
On Tue, 4 Jan 2011, Russell King - ARM Linux wrote:
> On Tue, Jan 04, 2011 at 03:20:06AM -0500, Nicolas Pitre wrote:
> > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> > index 336f14e..7502bc1 100644
> > --- a/arch/arm/kernel/setup.c
> > +++ b/arch/arm/kernel/setup.c
> > @@ -703,8 +703,10 @@ static struct init_tags {
> > } init_tags __initdata = {
> > { tag_size(tag_core), ATAG_CORE },
> > { 1, PAGE_SIZE, 0xff },
> > +#ifndef CONFIG_ARM_PATCH_PHYS_VIRT
> > { tag_size(tag_mem32), ATAG_MEM },
> > { MEM_SIZE, PHYS_OFFSET },
> > +#endif
>
> Removing the definition is not really on - it's there as a fallback and
> removing fallbacks is not a good idea unless you can prove beyond doubt
> that it'll never be used.
>
> As that depends on the boot loader, it's something that can never be
> proven. So, arrange for it to be initialized at runtime, just like I
> will be doing in my revised version I'm working on which I detailed in
> a previous email.
Agreed.
I'll wait for that revised version before working on this further.
Nicolas
^ permalink raw reply
* [PATCH 0/2] OMAP: TWL: sparse fixes
From: Kevin Hilman @ 2011-01-04 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294081110-23695-1-git-send-email-nm@ti.com>
Nishanth Menon <nm@ti.com> writes:
> Source:
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
> branch: omap-for-linus
>
> Doing a rm arch/arm/mach-omap2/*.o;make C=1 arch/arm/mach-omap2/
> resulted in the following sparse warnings:
> http://pastebin.mozilla.org/907954
>
> This series fixes the twl warnings
> Nishanth Menon (2):
> OMAP2+: TWL: make conversion routines static
> OMAP2+: TWL: include pm header for init protos
>
> arch/arm/mach-omap2/omap_twl.c | 10 ++++++----
> 1 files changed, 6 insertions(+), 4 deletions(-)
Acked-by: Kevin Hilman <khilman@ti.com>
Tony, these should probably queue for .38 if it's not too late.
Kevin
^ permalink raw reply
* [PATCH] omap: boards w/ wl12xx should select REGULATOR_FIXED_VOLTAGE
From: Ohad Ben-Cohen @ 2011-01-04 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1290593090-6288-1-git-send-email-ohad@wizery.com>
On Wed, Nov 24, 2010 at 12:04 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> Power to the wl12xx wlan device is controlled by a fixed regulator.
>
> Boards that have the wl12xx should select REGULATOR_FIXED_VOLTAGE so
> users will not be baffled.
>
> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
> ---
Hi Tony,
Gentle reminder,
Thanks,
Ohad.
> ?arch/arm/mach-omap2/Kconfig | ? ?3 +++
> ?1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index fc3a181..cc386da 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -190,6 +190,7 @@ config MACH_OMAP3_PANDORA
> ? ? ? ?depends on ARCH_OMAP3
> ? ? ? ?default y
> ? ? ? ?select OMAP_PACKAGE_CBB
> + ? ? ? select REGULATOR_FIXED_VOLTAGE
>
> ?config MACH_OMAP3_TOUCHBOOK
> ? ? ? ?bool "OMAP3 Touch Book"
> @@ -235,6 +236,7 @@ config MACH_OMAP_ZOOM2
> ? ? ? ?select SERIAL_8250
> ? ? ? ?select SERIAL_CORE_CONSOLE
> ? ? ? ?select SERIAL_8250_CONSOLE
> + ? ? ? select REGULATOR_FIXED_VOLTAGE
>
> ?config MACH_OMAP_ZOOM3
> ? ? ? ?bool "OMAP3630 Zoom3 board"
> @@ -244,6 +246,7 @@ config MACH_OMAP_ZOOM3
> ? ? ? ?select SERIAL_8250
> ? ? ? ?select SERIAL_CORE_CONSOLE
> ? ? ? ?select SERIAL_8250_CONSOLE
> + ? ? ? select REGULATOR_FIXED_VOLTAGE
>
> ?config MACH_CM_T35
> ? ? ? ?bool "CompuLab CM-T35 module"
> --
> 1.7.0.4
>
>
^ permalink raw reply
* [PATCH 1/4] ARM: runtime patching of __virt_to_phys() and __phys_to_virt()
From: Russell King - ARM Linux @ 2011-01-04 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1101041225070.22191@xanadu.home>
On Tue, Jan 04, 2011 at 12:50:28PM -0500, Nicolas Pitre wrote:
> On Tue, 4 Jan 2011, Russell King - ARM Linux wrote:
> > Our aims are different then. My aim is to move the code to a point where
> > it works for _everyone_ it possibly can - and theoretically that's every
> > platform except:
> >
> > 1. MSM due to their PHYS_OFFSET being 2MB aligned, rather than the more
> > normal 256MB alignment.
> > 2. Anyone with complex V:P mappings
>
> I completely agree with that goal. But I'd prefer for those platforms
> which are not yet supported by this feature not to be able to compile
> rather than silently ignore the feature and not behave as expected.
>
> > (1) is dealt with easily by a dependency in the configuration preventing
> > the option being visible. (2) is dealt with at runtime by ignoring the
> > configuration option - resulting in the p2v tables being empty. The end
> > result will still run on the platform, but it won't do the relocation
> > stuff. (2) could also be dealt with by adding the necessary dependencies
> > to the configuration option which is the longer term solution.
>
> Since (2) is not supported yet with this config option selected, I think
> it is best to simply #error the build.
>
> > Lastly, marking the option as 'EXPERIMENTAL' is there to convey that it
> > may not work for everyone, and people should expect things not to work if
> > they enable such an option (and report when that's the case.)
>
> Sure, hence my #error in the patch which is even easier to diagnose and
> self explanatory.
You're making a mountain out of a mole hill. At present, there is one
platform which defines its own complex v:p mapping and that is Realview,
but only when sparsemem is enabled. As already mentioned, MSM is the
only other platform which can't use this method. So that's a simple
dependency line against the config.
The other breakages are use of PHYS_OFFSET as an initializer which is a
build-error inducing failure, and adopting the approach I outlined in my
4 patch set results in many of those going away before we get support for
this merged - even better, if PHYS_OFFSET were always to be variable-like,
then we'd stop any new uses even appearing.
> And in fact I think that this would indeed be simpler to just fall back
> to a global variable for PHYS_OFFSET when a platform defines its own
> p2v/v2p mapping. This way, the goal of this feature would be
> universally available.
Not really. Platforms define their own mapping because it's not a simple
addition or subtraction, but because it's a complex non-linear conversion.
#define __phys_to_virt(phys) \
((phys) >= 0x80000000 ? (phys) - 0x80000000 + PAGE_OFFSET2 : \
(phys) >= 0x20000000 ? (phys) - 0x20000000 + PAGE_OFFSET1 : \
(phys) + PAGE_OFFSET)
#define __virt_to_phys(virt) \
((virt) >= PAGE_OFFSET2 ? (virt) - PAGE_OFFSET2 + 0x80000000 : \
(virt) >= PAGE_OFFSET1 ? (virt) - PAGE_OFFSET1 + 0x20000000 : \
(virt) - PAGE_OFFSET)
This doesn't lend itself in any way to a variable-based PHYS_OFFSET, and
could never be subsituted code-wise at run time without significant
effort.
In fact, platforms which have complex V:P mappings can _never_ be a part
of a kernel which has this feature enabled.
^ permalink raw reply
* [PATCH 1/4] ARM: runtime patching of __virt_to_phys() and __phys_to_virt()
From: David Brown @ 2011-01-04 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110104180620.GC24935@n2100.arm.linux.org.uk>
On Tue, Jan 04 2011, Russell King - ARM Linux wrote:
> On Tue, Jan 04, 2011 at 12:50:28PM -0500, Nicolas Pitre wrote:
> You're making a mountain out of a mole hill. At present, there is one
> platform which defines its own complex v:p mapping and that is Realview,
> but only when sparsemem is enabled. As already mentioned, MSM is the
> only other platform which can't use this method. So that's a simple
> dependency line against the config.
This is unfortunate, however, for us, since it would keep us having all
of our targets having to be built exclusively.
Any idea how much it would hurt other targets to have the
__virt_to_phys() and __phys_to_virt() have a 16-bit fixup, even if only
the upper 8 bits are used?
David
^ permalink raw reply
* [PATCH 0/5] omap2plus: Trivial build break fixes
From: Santosh Shilimkar @ 2011-01-04 18:26 UTC (permalink / raw)
To: linux-arm-kernel
These are trivial build fixes which I found while doing some
testing 'omap-for-linus' branch.
The series is generated against the linux-omap 'omap-for-linus' branch
and boot tested on OMAP4430 SDP and OMAP3630 ZOOM.
The following changes since commit dc69d1af9e8d9cbbabff88bb35a6782187a22229:
Ben Gamari (1):
omap2: Make OMAP2PLUS select OMAP_DM_TIMER
Santosh Shilimkar (5):
omap2plus: clockdomain: Trivial fix for build break because of clktrctrl_mask
omap2plus: prm: Trvial build break fix for undefined reference to 'omap2_prm_read_mod_reg'
omap2plus: voltage: Trivial warning fix 'no return statement'
omap2plus: voltage: Trivial linking fix 'undefined reference'
omap2plus: voltage: Trivial linking fix for 'EINVAL' undeclared
arch/arm/mach-omap2/Makefile | 2 +-
arch/arm/mach-omap2/clockdomain.h | 2 +-
arch/arm/mach-omap2/prm2xxx_3xxx.h | 45 ++++++++++++++++++++++++++++-
arch/arm/plat-omap/include/plat/voltage.h | 17 ++++++++--
4 files changed, 59 insertions(+), 7 deletions(-)
^ permalink raw reply
* [PATCH 1/5] omap2plus: clockdomain: Trivial fix for build break because of clktrctrl_mask
From: Santosh Shilimkar @ 2011-01-04 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294165576-15628-1-git-send-email-santosh.shilimkar@ti.com>
struct clockdomain member clktrctrl_mask is available for only for OMAP2
and OMAP3 architectures. Technially it is also used only for these archs
but this breaks the build with custom OMAP4 configuration.
CC arch/arm/mach-omap2/clockdomain.o
arch/arm/mach-omap2/clockdomain.c: In function '_enable_hwsup':
arch/arm/mach-omap2/clockdomain.c:251: error: 'struct clockdomain' has no member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c:254: error: 'struct clockdomain' has no member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c: In function '_disable_hwsup':
arch/arm/mach-omap2/clockdomain.c:277: error: 'struct clockdomain' has no member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c:280: error: 'struct clockdomain' has no member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c: In function 'omap2_clkdm_sleep':
arch/arm/mach-omap2/clockdomain.c:744: error: 'struct clockdomain' has no member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c: In function 'omap2_clkdm_wakeup':
arch/arm/mach-omap2/clockdomain.c:789: error: 'struct clockdomain' has no member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c: In function 'omap2_clkdm_clk_enable':
arch/arm/mach-omap2/clockdomain.c:922: error: 'struct clockdomain' has no member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c:926: error: 'struct clockdomain' has no member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c: In function 'omap2_clkdm_clk_disable':
arch/arm/mach-omap2/clockdomain.c:994: error: 'struct clockdomain' has no member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c:998: error: 'struct clockdomain' has no member named 'clktrctrl_mask'
make[1]: *** [arch/arm/mach-omap2/clockdomain.o] Error 1
make: *** [arch/arm/mach-omap2] Error 2
Fix the build break with use of ARCH_OMAP2PLUS instead of OMAP2 or OMAP3
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
---
arch/arm/mach-omap2/clockdomain.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.h b/arch/arm/mach-omap2/clockdomain.h
index de3faa2..6fa82f5 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -103,7 +103,7 @@ struct clockdomain {
const char *name;
struct powerdomain *ptr;
} pwrdm;
-#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
+#ifdef CONFIG_ARCH_OMAP2PLUS
const u16 clktrctrl_mask;
#endif
const u8 flags;
--
1.6.0.4
^ permalink raw reply related
* [PATCH 2/5] omap2plus: prm: Trvial build break fix for undefined reference to 'omap2_prm_read_mod_reg'
From: Santosh Shilimkar @ 2011-01-04 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294165576-15628-2-git-send-email-santosh.shilimkar@ti.com>
omap2plus_defocnfig build breaks when customised with only ARCH_OMAP4
selected. This is because common files make references to the functions
which are defined only for omap2xxx and omap3xxx.
LD .tmp_vmlinux1
arch/arm/mach-omap2/built-in.o: In function `pm_dbg_regset_store':
arch/arm/mach-omap2/pm-debug.c:335: undefined reference to `omap2_prm_read_mod_reg'
arch/arm/mach-omap2/built-in.o: In function `omap2_pm_dump':
arch/arm/mach-omap2/pm-debug.c:121: undefined reference to `omap2_prm_read_mod_reg'
arch/arm/mach-omap2/pm-debug.c:123: undefined reference to `omap2_prm_read_mod_reg'
arch/arm/mach-omap2/pm-debug.c:124: undefined reference to `omap2_prm_read_mod_reg'
arch/arm/mach-omap2/pm-debug.c:125: undefined reference to `omap2_prm_read_mod_reg'
arch/arm/mach-omap2/built-in.o: In function `omap_prcm_arch_reset':
arch/arm/mach-omap2/prcm.c:106: undefined reference to `omap2_prm_set_mod_reg_bits'
arch/arm/mach-omap2/prcm.c:108: undefined reference to `omap2_prm_read_mod_reg'
arch/arm/mach-omap2/built-in.o: In function `omap_prcm_get_reset_sources':
arch/arm/mach-omap2/prcm.c:53: undefined reference to `omap2_prm_read_mod_reg'
arch/arm/mach-omap2/built-in.o: In function `clkdm_clear_all_wkdeps':
arch/arm/mach-omap2/clockdomain.c:545: undefined reference to `omap2_prm_clear_mod_reg_bits'
arch/arm/mach-omap2/built-in.o: In function `clkdm_del_wkdep':
arch/arm/mach-omap2/clockdomain.c:475: undefined reference to `omap2_prm_clear_mod_reg_bits'
arch/arm/mach-omap2/built-in.o: In function `clkdm_read_wkdep':
arch/arm/mach-omap2/clockdomain.c:511: undefined reference to `omap2_prm_read_mod_bits_shift'
arch/arm/mach-omap2/built-in.o: In function `clkdm_add_wkdep':
arch/arm/mach-omap2/clockdomain.c:440: undefined reference to `omap2_prm_set_mod_reg_bits'
make: *** [.tmp_vmlinux1] Error 1
This patch adds stubs for these functions so that build continues to work.
Probably alternately the build can be fixed as below but that not seems to
be the right way.
----------------------------------------------------------------------
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
---
arch/arm/mach-omap2/Makefile | 2 +-
arch/arm/mach-omap2/prm2xxx_3xxx.h | 45 +++++++++++++++++++++++++++++++++++-
2 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 4ab82f6..359a7f2 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -84,7 +84,7 @@ obj-$(CONFIG_ARCH_OMAP3) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o
# use OMAP4-specific PRCM functions.
obj-$(CONFIG_ARCH_OMAP4) += prcm.o cm2xxx_3xxx.o cminst44xx.o \
cm44xx.o prcm_mpu44xx.o \
- prminst44xx.o
+ prminst44xx.o prm2xxx_3xxx.o
# OMAP powerdomain framework
powerdomain-common += powerdomain.o powerdomain-common.o
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.h b/arch/arm/mach-omap2/prm2xxx_3xxx.h
index 53d44f6..517e077 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.h
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.h
@@ -228,7 +228,49 @@
#ifndef __ASSEMBLER__
-
+/*
+ * Stub omap2xxx/omap3xxx functions so that common files
+ * continue to build when custom builds are used
+ */
+#if defined(CONFIG_ARCH_OMAP4) && !(defined(CONFIG_ARCH_OMAP2) || \
+ defined(CONFIG_ARCH_OMAP3))
+static inline u32 omap2_prm_read_mod_reg(s16 module, u16 idx)
+{
+ return 0;
+}
+static inline void omap2_prm_write_mod_reg(u32 val, s16 module, u16 idx)
+{
+}
+static inline u32 omap2_prm_rmw_mod_reg_bits(u32 mask, u32 bits,
+ s16 module, s16 idx)
+{
+ return 0;
+}
+static inline u32 omap2_prm_set_mod_reg_bits(u32 bits, s16 module, s16 idx)
+{
+ return 0;
+}
+static inline u32 omap2_prm_clear_mod_reg_bits(u32 bits, s16 module, s16 idx)
+{
+ return 0;
+}
+static inline u32 omap2_prm_read_mod_bits_shift(s16 domain, s16 idx, u32 mask)
+{
+ return 0;
+}
+static inline int omap2_prm_is_hardreset_asserted(s16 prm_mod, u8 shift)
+{
+ return 0;
+}
+static inline int omap2_prm_assert_hardreset(s16 prm_mod, u8 shift)
+{
+ return 0;
+}
+static inline int omap2_prm_deassert_hardreset(s16 prm_mod, u8 shift)
+{
+ return 0;
+}
+#else
/* Power/reset management domain register get/set */
extern u32 omap2_prm_read_mod_reg(s16 module, u16 idx);
extern void omap2_prm_write_mod_reg(u32 val, s16 module, u16 idx);
@@ -242,6 +284,7 @@ extern int omap2_prm_is_hardreset_asserted(s16 prm_mod, u8 shift);
extern int omap2_prm_assert_hardreset(s16 prm_mod, u8 shift);
extern int omap2_prm_deassert_hardreset(s16 prm_mod, u8 shift);
+#endif /* CONFIG_ARCH_OMAP4 */
#endif
/*
--
1.6.0.4
^ permalink raw reply related
* [PATCH 3/5] omap2plus: voltage: Trivial warning fix 'no return statement'
From: Santosh Shilimkar @ 2011-01-04 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294165576-15628-3-git-send-email-santosh.shilimkar@ti.com>
Fix below build warnings
CC arch/arm/mach-omap2/common.o
CC arch/arm/mach-omap2/gpio.o
In file included from arch/arm/plat-omap/include/plat/omap_hwmod.h:38,
from arch/arm/mach-omap2/gpio.c:25:
arch/arm/plat-omap/include/plat/voltage.h: In function 'omap_voltage_register_pmic':
arch/arm/plat-omap/include/plat/voltage.h:137: warning: no return statement in function returning non-void
CC arch/arm/mach-omap2/dma.o
In file included from arch/arm/plat-omap/include/plat/omap_hwmod.h:38,
from arch/arm/mach-omap2/dma.c:32:
arch/arm/plat-omap/include/plat/voltage.h: In function 'omap_voltage_register_pmic':
arch/arm/plat-omap/include/plat/voltage.h:137: warning: no return statement in function returning non-void
CC arch/arm/mach-omap2/wd_timer.o
In file included from arch/arm/plat-omap/include/plat/omap_hwmod.h:38,
from arch/arm/mach-omap2/wd_timer.c:15:
arch/arm/plat-omap/include/plat/voltage.h: In function 'omap_voltage_register_pmic':
arch/arm/plat-omap/include/plat/voltage.h:137: warning: no return statement in function returning non-void
CC arch/arm/mach-omap2/prm44xx.o
CC arch/arm/mach-omap2/omap_hwmod.o
In file included from arch/arm/plat-omap/include/plat/omap_hwmod.h:38,
from arch/arm/mach-omap2/omap_hwmod.c:145:
arch/arm/plat-omap/include/plat/voltage.h: In function 'omap_voltage_register_pmic':
arch/arm/plat-omap/include/plat/voltage.h:137: warning: no return statement in function returning non-void
CC arch/arm/mach-omap2/omap_hwmod_common_data.o
In file included from arch/arm/plat-omap/include/plat/omap_hwmod.h:38,
from arch/arm/mach-omap2/omap_hwmod_common_data.c:20:
arch/arm/plat-omap/include/plat/voltage.h: In function 'omap_voltage_register_pmic':
arch/arm/plat-omap/include/plat/voltage.h:137: warning: no return statement in function returning non-void
The error is reported when omap2plus_defconfig built with CONFIG_PM disabled
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Thara Gopinath <thara@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
---
arch/arm/plat-omap/include/plat/voltage.h | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/voltage.h b/arch/arm/plat-omap/include/plat/voltage.h
index 0ff1233..710f4ea 100644
--- a/arch/arm/plat-omap/include/plat/voltage.h
+++ b/arch/arm/plat-omap/include/plat/voltage.h
@@ -134,7 +134,10 @@ void omap_change_voltscale_method(struct voltagedomain *voltdm,
int omap_voltage_late_init(void);
#else
static inline int omap_voltage_register_pmic(struct voltagedomain *voltdm,
- struct omap_volt_pmic_info *pmic_info) {}
+ struct omap_volt_pmic_info *pmic_info)
+{
+ return 0;
+}
static inline void omap_change_voltscale_method(struct voltagedomain *voltdm,
int voltscale_method) {}
static inline int omap_voltage_late_init(void)
--
1.6.0.4
^ permalink raw reply related
* [PATCH 4/5] omap2plus: voltage: Trivial linking fix 'undefined reference'
From: Santosh Shilimkar @ 2011-01-04 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294165576-15628-4-git-send-email-santosh.shilimkar@ti.com>
LD init/built-in.o
LD .tmp_vmlinux1
arch/arm/mach-omap2/built-in.o: In function `omap2_set_init_voltage':
arch/arm/mach-omap2/pm.c:181: undefined reference to `omap_voltage_domain_lookup'
arch/arm/mach-omap2/built-in.o: In function `omap4_twl_init':
arch/arm/mach-omap2/omap_twl.c:244: undefined reference to `omap_voltage_domain_lookup'
arch/arm/mach-omap2/omap_twl.c:247: undefined reference to `omap_voltage_domain_lookup'
arch/arm/mach-omap2/omap_twl.c:250: undefined reference to `omap_voltage_domain_lookup'
make: *** [.tmp_vmlinux1] Error 1
The error is reported when omap2plus_defconfig built with CONFIG_PM disabled
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Thara Gopinath <thara@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
---
arch/arm/plat-omap/include/plat/voltage.h | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/voltage.h b/arch/arm/plat-omap/include/plat/voltage.h
index 710f4ea..c095351 100644
--- a/arch/arm/plat-omap/include/plat/voltage.h
+++ b/arch/arm/plat-omap/include/plat/voltage.h
@@ -65,9 +65,6 @@ struct voltagedomain {
char *name;
};
-/* API to get the voltagedomain pointer */
-struct voltagedomain *omap_voltage_domain_lookup(char *name);
-
/**
* struct omap_volt_data - Omap voltage specific data.
* @voltage_nominal: The possible voltage value in uV
@@ -131,6 +128,9 @@ int omap_voltage_register_pmic(struct voltagedomain *voltdm,
struct omap_volt_pmic_info *pmic_info);
void omap_change_voltscale_method(struct voltagedomain *voltdm,
int voltscale_method);
+/* API to get the voltagedomain pointer */
+struct voltagedomain *omap_voltage_domain_lookup(char *name);
+
int omap_voltage_late_init(void);
#else
static inline int omap_voltage_register_pmic(struct voltagedomain *voltdm,
@@ -144,6 +144,10 @@ static inline int omap_voltage_late_init(void)
{
return -EINVAL;
}
+static inline struct voltagedomain *omap_voltage_domain_lookup(char *name)
+{
+ return NULL;
+}
#endif
#endif
--
1.6.0.4
^ permalink raw reply related
* [PATCH 5/5] omap2plus: voltage: Trivial linking fix for 'EINVAL' undeclared
From: Santosh Shilimkar @ 2011-01-04 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294165576-15628-5-git-send-email-santosh.shilimkar@ti.com>
CC arch/arm/mach-omap2/omap_hwmod_common_data.o
In file included from arch/arm/plat-omap/include/plat/omap_hwmod.h:38,
from arch/arm/mach-omap2/omap_hwmod_common_data.c:20:
arch/arm/plat-omap/include/plat/voltage.h: In function 'omap_voltage_late_init':
arch/arm/plat-omap/include/plat/voltage.h:145: error: 'EINVAL' undeclared (first use in this function)
arch/arm/plat-omap/include/plat/voltage.h:145: error: (Each undeclared identifier is reported only once
arch/arm/plat-omap/include/plat/voltage.h:145: error: for each function it appears in.)
make[1]: *** [arch/arm/mach-omap2/omap_hwmod_common_data.o] Error 1
make: *** [arch/arm/mach-omap2] Error 2
The error is reported when omap2plus_defconfig built with CONFIG_PM disabled
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Thara Gopinath <thara@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
---
arch/arm/plat-omap/include/plat/voltage.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/voltage.h b/arch/arm/plat-omap/include/plat/voltage.h
index c095351..2b776f0 100644
--- a/arch/arm/plat-omap/include/plat/voltage.h
+++ b/arch/arm/plat-omap/include/plat/voltage.h
@@ -14,6 +14,8 @@
#ifndef __ARCH_ARM_MACH_OMAP2_VOLTAGE_H
#define __ARCH_ARM_MACH_OMAP2_VOLTAGE_H
+#include <linux/err.h>
+
#define VOLTSCALE_VPFORCEUPDATE 1
#define VOLTSCALE_VCBYPASS 2
--
1.6.0.4
^ permalink raw reply related
* [PATCH 1/4] ARM: runtime patching of __virt_to_phys() and __phys_to_virt()
From: Nicolas Pitre @ 2011-01-04 18:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110104180620.GC24935@n2100.arm.linux.org.uk>
On Tue, 4 Jan 2011, Russell King - ARM Linux wrote:
> On Tue, Jan 04, 2011 at 12:50:28PM -0500, Nicolas Pitre wrote:
> > On Tue, 4 Jan 2011, Russell King - ARM Linux wrote:
> > > Our aims are different then. My aim is to move the code to a point where
> > > it works for _everyone_ it possibly can - and theoretically that's every
> > > platform except:
> > >
> > > 1. MSM due to their PHYS_OFFSET being 2MB aligned, rather than the more
> > > normal 256MB alignment.
> > > 2. Anyone with complex V:P mappings
> >
> > I completely agree with that goal. But I'd prefer for those platforms
> > which are not yet supported by this feature not to be able to compile
> > rather than silently ignore the feature and not behave as expected.
> >
> > > (1) is dealt with easily by a dependency in the configuration preventing
> > > the option being visible. (2) is dealt with at runtime by ignoring the
> > > configuration option - resulting in the p2v tables being empty. The end
> > > result will still run on the platform, but it won't do the relocation
> > > stuff. (2) could also be dealt with by adding the necessary dependencies
> > > to the configuration option which is the longer term solution.
> >
> > Since (2) is not supported yet with this config option selected, I think
> > it is best to simply #error the build.
> >
> > > Lastly, marking the option as 'EXPERIMENTAL' is there to convey that it
> > > may not work for everyone, and people should expect things not to work if
> > > they enable such an option (and report when that's the case.)
> >
> > Sure, hence my #error in the patch which is even easier to diagnose and
> > self explanatory.
>
> You're making a mountain out of a mole hill. At present, there is one
> platform which defines its own complex v:p mapping and that is Realview,
> but only when sparsemem is enabled. As already mentioned, MSM is the
> only other platform which can't use this method. So that's a simple
> dependency line against the config.
OK, agreed.
The #error might still be a good idea as a stop gate if some future
platforms also define a complex v:p mapping and the Kbuild dependency is
missed, just like we have things like:
#if __LINUX_ARM_ARCH__ < 6
#error SMP not supported on pre-ARMv6 CPUs
#endif
> The other breakages are use of PHYS_OFFSET as an initializer which is a
> build-error inducing failure, and adopting the approach I outlined in my
> 4 patch set results in many of those going away before we get support for
> this merged - even better, if PHYS_OFFSET were always to be variable-like,
> then we'd stop any new uses even appearing.
Completely agreed.
> > And in fact I think that this would indeed be simpler to just fall back
> > to a global variable for PHYS_OFFSET when a platform defines its own
> > p2v/v2p mapping. This way, the goal of this feature would be
> > universally available.
>
> Not really. Platforms define their own mapping because it's not a simple
> addition or subtraction, but because it's a complex non-linear conversion.
>
> #define __phys_to_virt(phys) \
> ((phys) >= 0x80000000 ? (phys) - 0x80000000 + PAGE_OFFSET2 : \
> (phys) >= 0x20000000 ? (phys) - 0x20000000 + PAGE_OFFSET1 : \
> (phys) + PAGE_OFFSET)
>
> #define __virt_to_phys(virt) \
> ((virt) >= PAGE_OFFSET2 ? (virt) - PAGE_OFFSET2 + 0x80000000 : \
> (virt) >= PAGE_OFFSET1 ? (virt) - PAGE_OFFSET1 + 0x20000000 : \
> (virt) - PAGE_OFFSET)
Indeed, no point trying to support that.
> This doesn't lend itself in any way to a variable-based PHYS_OFFSET, and
> could never be subsituted code-wise at run time without significant
> effort.
>
> In fact, platforms which have complex V:P mappings can _never_ be a part
> of a kernel which has this feature enabled.
I said the same already, perhaps not as strongly.
If we _wanted_ to support such platforms in a common kernel binary, then
we would have to fall back to function pointers. The end goal would be
accomplished through a different implementation. I don't think it is
worth going there though.
Nicolas
^ permalink raw reply
* [PATCH 1/4] ARM: runtime patching of __virt_to_phys() and __phys_to_virt()
From: Nicolas Pitre @ 2011-01-04 18:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8yahbdoh6fs.fsf@huya.qualcomm.com>
On Tue, 4 Jan 2011, David Brown wrote:
> On Tue, Jan 04 2011, Russell King - ARM Linux wrote:
>
> > On Tue, Jan 04, 2011 at 12:50:28PM -0500, Nicolas Pitre wrote:
>
> > You're making a mountain out of a mole hill. At present, there is one
> > platform which defines its own complex v:p mapping and that is Realview,
> > but only when sparsemem is enabled. As already mentioned, MSM is the
> > only other platform which can't use this method. So that's a simple
> > dependency line against the config.
>
> This is unfortunate, however, for us, since it would keep us having all
> of our targets having to be built exclusively.
>
> Any idea how much it would hurt other targets to have the
> __virt_to_phys() and __phys_to_virt() have a 16-bit fixup, even if only
> the upper 8 bits are used?
Probably not that much. But let's make it work satisfactorily for the
general case first, and then we might consider and test variations that
could accommodate msm.
Nicolas
^ permalink raw reply
* [PATCH 2/5] omap2plus: prm: Trvial build break fix for undefined reference to 'omap2_prm_read_mod_reg'
From: Paul Walmsley @ 2011-01-04 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294165576-15628-3-git-send-email-santosh.shilimkar@ti.com>
Hi Santosh,
On Tue, 4 Jan 2011, Santosh Shilimkar wrote:
> omap2plus_defocnfig build breaks when customised with only ARCH_OMAP4
> selected. This is because common files make references to the functions
> which are defined only for omap2xxx and omap3xxx.
>
> LD .tmp_vmlinux1
> arch/arm/mach-omap2/built-in.o: In function `pm_dbg_regset_store':
> arch/arm/mach-omap2/pm-debug.c:335: undefined reference to `omap2_prm_read_mod_reg'
> arch/arm/mach-omap2/built-in.o: In function `omap2_pm_dump':
> arch/arm/mach-omap2/pm-debug.c:121: undefined reference to `omap2_prm_read_mod_reg'
> arch/arm/mach-omap2/pm-debug.c:123: undefined reference to `omap2_prm_read_mod_reg'
> arch/arm/mach-omap2/pm-debug.c:124: undefined reference to `omap2_prm_read_mod_reg'
> arch/arm/mach-omap2/pm-debug.c:125: undefined reference to `omap2_prm_read_mod_reg'
> arch/arm/mach-omap2/built-in.o: In function `omap_prcm_arch_reset':
> arch/arm/mach-omap2/prcm.c:106: undefined reference to `omap2_prm_set_mod_reg_bits'
> arch/arm/mach-omap2/prcm.c:108: undefined reference to `omap2_prm_read_mod_reg'
> arch/arm/mach-omap2/built-in.o: In function `omap_prcm_get_reset_sources':
> arch/arm/mach-omap2/prcm.c:53: undefined reference to `omap2_prm_read_mod_reg'
> arch/arm/mach-omap2/built-in.o: In function `clkdm_clear_all_wkdeps':
> arch/arm/mach-omap2/clockdomain.c:545: undefined reference to `omap2_prm_clear_mod_reg_bits'
> arch/arm/mach-omap2/built-in.o: In function `clkdm_del_wkdep':
> arch/arm/mach-omap2/clockdomain.c:475: undefined reference to `omap2_prm_clear_mod_reg_bits'
> arch/arm/mach-omap2/built-in.o: In function `clkdm_read_wkdep':
> arch/arm/mach-omap2/clockdomain.c:511: undefined reference to `omap2_prm_read_mod_bits_shift'
> arch/arm/mach-omap2/built-in.o: In function `clkdm_add_wkdep':
> arch/arm/mach-omap2/clockdomain.c:440: undefined reference to `omap2_prm_set_mod_reg_bits'
> make: *** [.tmp_vmlinux1] Error 1
>
> This patch adds stubs for these functions so that build continues to work.
>
> Probably alternately the build can be fixed as below but that not seems to
> be the right way.
Since these functions now return 0, maybe it would be better to call
WARN() or BUG() in these functions for OMAP4. Otherwise, they are going
to silently do the wrong thing, and someone needs to fix any usage of
these functions where they shouldn't be used. e.g., in mach-omap2/prcm.c
or mach-omap2/pm-debug.c ...
- Paul
^ permalink raw reply
* [PATCH v5 1/3] ARM: add CPPI 4.1 DMA support
From: Felipe Balbi @ 2011-01-04 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTinPEpMofTX0YWbv18gSdWtPLVFa85S1E=+QxFT=@mail.gmail.com>
Hi,
On Tue, Jan 04, 2011 at 11:41:05PM +0800, Ming Lei wrote:
> OMAP GPIOs have many usages or use cases, so we can use gpiolib
> to simplify access to GPIOs. If GPIOs has only one usage or use case,
> it is not necessary to access GPIOs by gpiolib.
>
> Now this kind of DMA controllers are only used by MUSB or only for
> MUSB, so it doesn't matter to access them by dmaengine or not.
Not entirely true. TUSB uses OMAP system DMA and AFAICT CPPI is used
also for ethernet. The thing is that we want to get rid of non-standard
"APIs" as much as possible.
--
balbi
^ permalink raw reply
* [PATCH 1/5] omap2plus: clockdomain: Trivial fix for build break because of clktrctrl_mask
From: Paul Walmsley @ 2011-01-04 18:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294165576-15628-2-git-send-email-santosh.shilimkar@ti.com>
Hi Santosh
On Tue, 4 Jan 2011, Santosh Shilimkar wrote:
> struct clockdomain member clktrctrl_mask is available for only for OMAP2
> and OMAP3 architectures. Technially it is also used only for these archs
> but this breaks the build with custom OMAP4 configuration.
>
> CC arch/arm/mach-omap2/clockdomain.o
> arch/arm/mach-omap2/clockdomain.c: In function '_enable_hwsup':
> arch/arm/mach-omap2/clockdomain.c:251: error: 'struct clockdomain' has no member named 'clktrctrl_mask'
> arch/arm/mach-omap2/clockdomain.c:254: error: 'struct clockdomain' has no member named 'clktrctrl_mask'
> arch/arm/mach-omap2/clockdomain.c: In function '_disable_hwsup':
> arch/arm/mach-omap2/clockdomain.c:277: error: 'struct clockdomain' has no member named 'clktrctrl_mask'
> arch/arm/mach-omap2/clockdomain.c:280: error: 'struct clockdomain' has no member named 'clktrctrl_mask'
> arch/arm/mach-omap2/clockdomain.c: In function 'omap2_clkdm_sleep':
> arch/arm/mach-omap2/clockdomain.c:744: error: 'struct clockdomain' has no member named 'clktrctrl_mask'
> arch/arm/mach-omap2/clockdomain.c: In function 'omap2_clkdm_wakeup':
> arch/arm/mach-omap2/clockdomain.c:789: error: 'struct clockdomain' has no member named 'clktrctrl_mask'
> arch/arm/mach-omap2/clockdomain.c: In function 'omap2_clkdm_clk_enable':
> arch/arm/mach-omap2/clockdomain.c:922: error: 'struct clockdomain' has no member named 'clktrctrl_mask'
> arch/arm/mach-omap2/clockdomain.c:926: error: 'struct clockdomain' has no member named 'clktrctrl_mask'
> arch/arm/mach-omap2/clockdomain.c: In function 'omap2_clkdm_clk_disable':
> arch/arm/mach-omap2/clockdomain.c:994: error: 'struct clockdomain' has no member named 'clktrctrl_mask'
> arch/arm/mach-omap2/clockdomain.c:998: error: 'struct clockdomain' has no member named 'clktrctrl_mask'
> make[1]: *** [arch/arm/mach-omap2/clockdomain.o] Error 1
> make: *** [arch/arm/mach-omap2] Error 2
>
> Fix the build break with use of ARCH_OMAP2PLUS instead of OMAP2 or OMAP3
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> ---
> arch/arm/mach-omap2/clockdomain.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clockdomain.h b/arch/arm/mach-omap2/clockdomain.h
> index de3faa2..6fa82f5 100644
> --- a/arch/arm/mach-omap2/clockdomain.h
> +++ b/arch/arm/mach-omap2/clockdomain.h
> @@ -103,7 +103,7 @@ struct clockdomain {
> const char *name;
> struct powerdomain *ptr;
> } pwrdm;
> -#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
> +#ifdef CONFIG_ARCH_OMAP2PLUS
No need for this, just drop the #ifdef...
> const u16 clktrctrl_mask;
- Paul
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox