* [PATCH] clk: respect the clock dependencies in of_clk_init
From: Boris BREZILLON @ 2014-02-05 8:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391554766-11285-1-git-send-email-gregory.clement@free-electrons.com>
Hi Greg,
On 04/02/2014 23:59, Gregory CLEMENT wrote:
> Until now the clock providers were initialized in the order found in
> the device tree. This led to have the dependencies between the clocks
> not respected: children clocks could be initialized before their
> parent clocks.
>
> Instead of forcing each platform to manage its own initialization order,
> this patch adds this work inside the framework itself.
>
> Using the data of the device tree the of_clk_init function now delayed
> the initialization of a clock provider if its parent provider was not
> ready yet.
>
Great! I remember having some trouble with this "parent is not
registered yet" issue (but I don't recall how I solved it, maybe in
reordering clk nodes).
Anyway, this will help other platforms too (at least the at91 one).
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
> Mike,
>
> this patch could solve the issues we get on severals mvebu platform
> since 3.14-rc1. This is an alternate solution of the patch set sent by
> Sebastian. However as it modifies the clock framework itself, it is
> more sensible.
>
> I find this solution more elegant than changing the order of the
> initialization of the clock at the platform level. However as it
> should be tested on more platforms that only the mvebu ones, it would
> take some time, and I don't want to still have "broken" platform
> during more release candidate. So at the end this patch should be part
> of the 3.15 kernel.
>
> Thanks,
>
> Gregory
>
> drivers/clk/clk.c | 94 +++++++++++++++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 91 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 5517944495d8..beb0f8b0c2a0 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -2526,24 +2526,112 @@ const char *of_clk_get_parent_name(struct device_node *np, int index)
> }
> EXPORT_SYMBOL_GPL(of_clk_get_parent_name);
>
> +struct clock_provider {
> + of_clk_init_cb_t clk_init_cb;
> + struct device_node *np;
> + struct list_head node;
> +};
> +
> +static LIST_HEAD(clk_provider_list);
> +
> +/*
> + * This function looks for a parent clock. If there is one, then it
> + * checks that the provider for this parent clock was initialized, in
> + * this case the parent clock will be ready.
> + */
> +static int parent_ready(struct device_node *np)
> +{
> + struct of_phandle_args clkspec;
> + struct of_clk_provider *provider;
> +
> + /*
> + * If there is no clock parent, no need to wait for them, then
> + * we can consider their absence as being ready
> + */
> + if (of_parse_phandle_with_args(np, "clocks", "#clock-cells", 0,
> + &clkspec))
> + return 1;
> +
> + /* Check if we have such a provider in our array */
> + list_for_each_entry(provider, &of_clk_providers, link) {
> + if (provider->node == clkspec.np)
> + return 1;
> + }
Shouldn't we wait for all parents to be ready (If I'm right, you're only
waiting for the first parent...) ?
And if you only request for one clk to be ready, why the first one (you
could loop over parent clks and stop when one of its parent is ready) ?
Best Regards,
Boris
> +
> + return 0;
> +}
> +
> /**
> * of_clk_init() - Scan and init clock providers from the DT
> * @matches: array of compatible values and init functions for providers.
> *
> - * This function scans the device tree for matching clock providers and
> - * calls their initialization functions
> + * This function scans the device tree for matching clock providers
> + * and calls their initialization functions. It also do it by trying
> + * to follow the dependencies.
> */
> void __init of_clk_init(const struct of_device_id *matches)
> {
> const struct of_device_id *match;
> struct device_node *np;
> + struct clock_provider *clk_provider, *next;
> + bool is_init_done;
>
> if (!matches)
> matches = &__clk_of_table;
>
> for_each_matching_node_and_match(np, matches, &match) {
> of_clk_init_cb_t clk_init_cb = match->data;
> - clk_init_cb(np);
> +
> +
> + if (parent_ready(np)) {
> + /*
> + * The parent clock is ready or there is no
> + * clock parent at all, in this case the
> + * provider can be initialize immediately.
> + */
> + clk_init_cb(np);
> + } else {
> + /*
> + * The parent clock is not ready, this
> + * provider is moved to a list to be
> + * initialized later
> + */
> + struct clock_provider *parent = kzalloc(sizeof(struct clock_provider),
> + GFP_KERNEL);
> +
> + parent->clk_init_cb = match->data;
> + parent->np = np;
> + list_add(&parent->node, &clk_provider_list);
> + }
> + }
> +
> + while (!list_empty(&clk_provider_list)) {
> + is_init_done = false;
> + list_for_each_entry_safe(clk_provider, next,
> + &clk_provider_list, node) {
> + if (parent_ready(clk_provider->np)) {
> + clk_provider->clk_init_cb(clk_provider->np);
> + list_del(&clk_provider->node);
> + kfree(clk_provider);
> + is_init_done = true;
> + }
> + }
> +
> + if (!is_init_done) {
> + /*
> + * We didn't managed to initialize any of the
> + * remaining providers during the last loop,
> + * so now we initialize all the remaining ones
> + * unconditionally in case the clock parent
> + * was not mandatory
> + */
> + list_for_each_entry_safe(clk_provider, next,
> + &clk_provider_list, node) {
> + clk_provider->clk_init_cb(clk_provider->np);
> + list_del(&clk_provider->node);
> + kfree(clk_provider);
> + }
> + }
> }
> }
> #endif
>
^ permalink raw reply
* [PATCH v2 4/4] clk: at91: optimization of the determine_rate callback
From: Boris BREZILLON @ 2014-02-05 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391589458-28018-5-git-send-email-jjhiblot@traphandler.com>
Hi JJ,
I guess you're commit message is wrong: you're optimizing set_rate not
determine_rate.
Best Regards,
Boris
On 05/02/2014 09:37, Jean-Jacques Hiblot wrote:
> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
> ---
> drivers/clk/at91/clk-programmable.c | 38 ++++++++-----------------------------
> 1 file changed, 8 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/clk/at91/clk-programmable.c b/drivers/clk/at91/clk-programmable.c
> index 7bcc725..62e2509 100644
> --- a/drivers/clk/at91/clk-programmable.c
> +++ b/drivers/clk/at91/clk-programmable.c
> @@ -139,43 +139,21 @@ static int clk_programmable_set_rate(struct clk_hw *hw, unsigned long rate,
> struct clk_programmable *prog = to_clk_programmable(hw);
> struct at91_pmc *pmc = prog->pmc;
> const struct clk_programmable_layout *layout = prog->layout;
> - unsigned long best_rate = parent_rate;
> - unsigned long best_diff;
> - unsigned long new_diff;
> - unsigned long cur_rate;
> + unsigned long div = parent_rate / rate;
> int shift = 0;
> u32 tmp = pmc_read(pmc, AT91_PMC_PCKR(prog->id)) &
> ~(PROG_PRES_MASK << layout->pres_shift);
>
> - if (rate > parent_rate)
> - return parent_rate;
> - else
> - best_diff = parent_rate - rate;
> + if (!div)
> + return -EINVAL;
>
> - if (!best_diff) {
> - pmc_write(pmc, AT91_PMC_PCKR(prog->id), tmp | shift);
> - return 0;
> - }
> -
> - for (shift = 1; shift < PROG_PRES_MASK; shift++) {
> - cur_rate = parent_rate >> shift;
> -
> - if (cur_rate > rate)
> - new_diff = cur_rate - rate;
> - else
> - new_diff = rate - cur_rate;
> -
> - if (!new_diff)
> - break;
> + shift = fls(div) - 1;
>
> - if (new_diff < best_diff) {
> - best_diff = new_diff;
> - best_rate = cur_rate;
> - }
> + if (div != (1<<shift))
> + return -EINVAL;
>
> - if (rate > cur_rate)
> - break;
> - }
> + if (shift >= PROG_PRES_MASK)
> + return -EINVAL;
>
> pmc_write(pmc, AT91_PMC_PCKR(prog->id),
> tmp | (shift << layout->pres_shift));
^ permalink raw reply
* [PATCH] backlight: add PWM dependencies
From: Linus Walleij @ 2014-02-05 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <000401cf222f$43263b20$c972b160$%han@samsung.com>
On Wed, Feb 5, 2014 at 6:01 AM, Jingoo Han <jg1.han@samsung.com> wrote:
> On Tuesday, February 04, 2014 9:57 PM, Linus Walleij wrote:
>>
>> In some compilations the LM3630A and LP855X backlight drivers
>> fail like this:
>>
>> drivers/built-in.o: In function `lm3630a_pwm_ctrl':
>> drivers/video/backlight/lm3630a_bl.c:168: undefined reference to `pwm_config'
>> drivers/video/backlight/lm3630a_bl.c:172: undefined reference to `pwm_disable'
>> drivers/video/backlight/lm3630a_bl.c:170: undefined reference to `pwm_enable'
>> drivers/built-in.o: In function `lp855x_pwm_ctrl':
>> drivers/video/backlight/lp855x_bl.c:249: undefined reference to `pwm_config'
>> drivers/video/backlight/lp855x_bl.c:253: undefined reference to `pwm_disable'
>> drivers/video/backlight/lp855x_bl.c:251: undefined reference to `pwm_enable'
>>
>> This is because both drivers depend on the PWM framework, so
>> add this dependency to their Kconfig entries.
>
> However, even though, when CONFIG_PWM is not enabled, the problem
> should not happen. pwm_config(),pwm_disable(), and pwm_enable()
> are already defined for CONFIG_PWM=n case as below.
So you may think but it does happen :-)
I reproduced this with the defconfig for ARM pxa255-idp and enabling
all boards for that platform, then enabling all available backlight drivers
as compiled-in objects (y).
> ./include/linux/pwm.h
> #if IS_ENABLED(CONFIG_PWM) || IS_ENABLED(CONFIG_HAVE_PWM)
> .....
> #else
Hm PXA that I am using defines CONFIG_HAVE_PWM, but doesn't
provide the required signatures (pwm_config/pwm_disable/pwm_enable).
One of two things is wrong:
- Either the PXA platform is breaking the CONFIG_HAVE_PWM
contract by not providing pwm_config/pwm_disable/pwm_enable
functions. Then HAVE_PWM should be removed from the PXA
Kconfig selects.
Or:
- There is no such contract that these functions must exist if
CONFIG_HAVE_PWM is defined, and the
#if IS_ENABLED(CONFIG_HAVE_PWM)
should be removed from <linux/pwm.h>
Does anyone know which one it is?
PWM subsystem maintainer? :-)
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: OMAP3+: DPLL: stop reparenting to same parent if already done
From: Nishanth Menon @ 2014-02-05 9:04 UTC (permalink / raw)
To: linux-arm-kernel
omap3_noncore_dpll_set_rate forces a reparent to the same clk_ref
for every call that takes place. This is an can be done only if a change
is detected.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm/mach-omap2/dpll3xxx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index 3185ced..d9bcbf7 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -525,7 +525,7 @@ int omap3_noncore_dpll_set_rate(struct clk_hw *hw, unsigned long rate,
* stuff is inherited for free
*/
- if (!ret)
+ if (!ret && clk_get_parent(hw->clk) != new_parent)
__clk_reparent(hw->clk, new_parent);
return 0;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/6] i2c: bcm-kona: register with subsys_initcall
From: Wolfram Sang @ 2014-02-05 9:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391516352-32359-2-git-send-email-mporter@linaro.org>
On Tue, Feb 04, 2014 at 07:19:07AM -0500, Matt Porter wrote:
> Voltage regulators are needed very early due to deferred probe
> being incompatible with built-in USB gadget drivers.
What does it need to fix those instead?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140205/9c9b7759/attachment.sig>
^ permalink raw reply
* [PATCH v3 4/5] ASoC: tda998x: adjust the audio hw parameters from EDID
From: Jean-Francois Moine @ 2014-02-05 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140204180625.GM22609@sirena.org.uk>
On Tue, 4 Feb 2014 18:06:25 +0000
Mark Brown <broonie@kernel.org> wrote:
> On Mon, Jan 27, 2014 at 09:48:54AM +0100, Jean-Francois Moine wrote:
>
> > + /* change the snd_soc_pcm_stream values of the driver */
> > + stream->rates = rate_mask;
> > + stream->channels_max = max_channels;
> > + stream->formats = formats;
>
> > + /* copy the DAI driver to a writable area */
> > + dai_drv = devm_kzalloc(&pdev->dev, sizeof(tda998x_dai), GFP_KERNEL);
> > + if (!dai_drv)
> > + return -ENOMEM;
> > + memcpy(dai_drv, tda998x_dai, sizeof(tda998x_dai));
> > +
>
> The code should be doing this by setting constraints based on the
> current setup rather than by editing the data structure - the expecation
> is very much that the data won't change so this prevents surprises with
> future work on the core.
As it is done in the soc core, in soc_pcm_open(), the runtime hw_params
are initialized after the call to the CODEC startup, and the next CODEC
event is hw_params() when the user has already chosen all the parameters.
So, in the CODEC, I don't see how I could update the parameters
dictated by the EDID otherwise in changing the DAI driver parameters.
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [Linux-kernel] [PATCH 2/3] ARM: shmobile: r8a7790: specify multiple parents for cpg_clks
From: Ben Dooks @ 2014-02-05 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391537858-28593-3-git-send-email-william.towle@codethink.co.uk>
On 04/02/14 18:17, William Towle wrote:
> The current drivers/clk/shmobile/clk-rcar-gen2.c uses the
> extal_clk reference for the parent of all the clocks that
> it registers. However the lb, qspi, sdh, sd0 and sd1 clocks
> are all parented to either pll1 or pll1_div2 which means
> that the clock rates are incorrect.
>
> This is part of the fix that corrects the SDHI0 clock
> rate error where it reports 1MHz instead of 97.5:
> sh_mobile_sdhi ee100000.sd: mmc0 base at 0xee100000 clock rate 1 MHz
>
> Notes:
> - May require cross-merge with clk-rcar-gen2.c fix
> - Also not clear which clock "z" is to fix it.
Laurent, if you could give us an idea of how to fix this then
it would be helpful to get this patch fully fixed.
>
> [ben.dooks at codethink.co.uk: updated patch description]
> Signed-off-by: William Towle <william.towle@codethink.co.uk>
> Reviewed-by: Ben Dooks <ben.dooks@codethink.co.uk>
> ---
> arch/arm/boot/dts/r8a7790.dtsi | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
> index ff55c6e..242e6e2 100644
> --- a/arch/arm/boot/dts/r8a7790.dtsi
> +++ b/arch/arm/boot/dts/r8a7790.dtsi
> @@ -446,7 +446,13 @@
> compatible = "renesas,r8a7790-cpg-clocks",
> "renesas,rcar-gen2-cpg-clocks";
> reg = <0 0xe6150000 0 0x1000>;
> - clocks = <&extal_clk>;
> + clocks = <&extal_clk>, <&extal_clk>, <&extal_clk>, <&extal_clk>,
> + <&cpg_clocks R8A7790_CLK_PLL1>,
> + <&pll1_div2_clk>,
> + <&cpg_clocks R8A7790_CLK_PLL1>,
> + <&cpg_clocks R8A7790_CLK_PLL1>,
> + <&cpg_clocks R8A7790_CLK_PLL1>
Should we add a pll1_clk node, or leave this as is?
> + /* not known for "z" ...,<> */;
> #clock-cells = <1>;
> clock-output-names = "main", "pll0", "pll1", "pll3",
> "lb", "qspi", "sdh", "sd0", "sd1",
>
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply
* [PATCH v5] ARM: davinci: aemif: get rid of davinci-nand driver dependency on aemif
From: Sekhar Nori @ 2014-02-05 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391079820-13018-1-git-send-email-ivan.khoronzhuk@ti.com>
Hi Brian,
On Thursday 30 January 2014 04:33 PM, Ivan Khoronzhuk wrote:
> The problem that the set timings code contains the call of Davinci
> platform function davinci_aemif_setup_timing() which is not
> accessible if kernel is built for another platform like Keystone.
>
> The Keysone platform is going to use TI AEMIF driver.
> If TI AEMIF is used we don't need to set timings and bus width.
> It is done by AEMIF driver.
>
> To get rid of davinci-nand driver dependency on aemif platform code
> we moved aemif code to davinci platform.
>
> The platform AEMIF code (aemif.c) has to be removed once Davinci
> will be converted to DT and use ti-aemif.c driver.
>
> Acked-by: Brian Norris <computersforpeace@gmail.com>
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
> [nsekhar at ti.com: fixed checkpatch error and a build breakage due to
> missing include, rebased onto l2-mtd/master]
> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Hope this patch looks good to you now. I would like to take it for v3.15
via DaVinci tree.
Thanks,
Sekhar
^ permalink raw reply
* [alsa-devel] [PATCH v3 4/5] ASoC: tda998x: adjust the audio hw parameters from EDID
From: Lars-Peter Clausen @ 2014-02-05 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140205101134.4591e5c3@armhf>
On 02/05/2014 10:11 AM, Jean-Francois Moine wrote:
> On Tue, 4 Feb 2014 18:06:25 +0000
> Mark Brown <broonie@kernel.org> wrote:
>
>> On Mon, Jan 27, 2014 at 09:48:54AM +0100, Jean-Francois Moine wrote:
>>
>>> + /* change the snd_soc_pcm_stream values of the driver */
>>> + stream->rates = rate_mask;
>>> + stream->channels_max = max_channels;
>>> + stream->formats = formats;
>>
>>> + /* copy the DAI driver to a writable area */
>>> + dai_drv = devm_kzalloc(&pdev->dev, sizeof(tda998x_dai), GFP_KERNEL);
>>> + if (!dai_drv)
>>> + return -ENOMEM;
>>> + memcpy(dai_drv, tda998x_dai, sizeof(tda998x_dai));
>>> +
>>
>> The code should be doing this by setting constraints based on the
>> current setup rather than by editing the data structure - the expecation
>> is very much that the data won't change so this prevents surprises with
>> future work on the core.
>
> As it is done in the soc core, in soc_pcm_open(), the runtime hw_params
> are initialized after the call to the CODEC startup, and the next CODEC
> event is hw_params() when the user has already chosen all the parameters.
>
> So, in the CODEC, I don't see how I could update the parameters
> dictated by the EDID otherwise in changing the DAI driver parameters.
>
The startup function is the right place. But instead of modifying the DAI
use snd_pcm_hw_constraint_mask64(), snd_pcm_hw_constraint_list(), etc. to
setup the additional constraints that come from the EDID.
Bonus points for making this a generic helper function that takes a runtime
and a EDID and then applies the EDID constraints on the runtime.
- Lars
^ permalink raw reply
* [PATCH 09/10] watchdog: xilinx: Add missing binding
From: Michal Simek @ 2014-02-05 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201402042027.15898.arnd@arndb.de>
On 02/04/2014 08:27 PM, Arnd Bergmann wrote:
> On Monday 03 February 2014, Michal Simek wrote:
>> On 02/03/2014 04:32 PM, Arnd Bergmann wrote:
>>> On Monday 03 February 2014 16:13:47 Michal Simek wrote:
>>>> Intention wasn't to fix binding but document current one
>>>> which is in mainline for a long time.
>>>
>>> Ok, I see.
>>>
>>>> Apart of this - yes, wdt-enable-once is nowayout and wdt-interval should be timeout
>>>> is seconds, and clock-frequency should go out and use CCF for getting clock.
>>>
>>> Could we make a common binding then, and document that the xilinx
>>> watchdog can optionally provide either one?
>>
>> Do you mean to have 2 DT bindings?
>>
>> This binding is used from 2011-07.
>> It means it was generated for all hw designs at least from this time.
>> I would say from DT usage on Microblaze because it is not special case
>> in our dt generator.
>
> I certainly wasn't suggesting to break the binding, quite the contrary.
> What I tried to say is that the properties look like they should be
> useful for different kinds of watchdogs, not just xilinx, so it would
> be good to have a common definition using generic strings.
>
> The xilinx driver would definitely have to keep supporting the traditional
> property names, but it could also support the generic names in the
> future.
No problem with to do in future.
>> xlnx,XXX are XXX parameters which you have to setup in tools
>> and get synthesized. This is valid for all xilinx IPs. We have full
>> IP description by generating xlnx,XXX parameters directly from tools
>> because we know all variants which can happen.
>>
>> Just back to your previous post:
>> "I'm not sure about the enable-once flag, which seems to just map to the
>> "nowayout" watchdog option that is not a hardware feature at all"
>> this is hw feature which you can select in tools because this is fpga. :-)
>
> Ah, so you mean the properties are not settings that the driver
> programs into the hardware, but they are hardware properties that the
> driver reports to user space?
yes, they are hardware properties which you can choose based on your
configuration. Every user just decides if this watchdog can be started just
once and how long it takes in synthesis time. There is no option to program
this by software.
I am not quite sure what you mean by reports to user space.
If you mean to get timeout through ioctl for example - then yes it is working
through standard watchdog ioctl interface and timeout is calculated
from hardware setup.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140205/99e851c4/attachment-0001.sig>
^ permalink raw reply
* [PATCH] security: select correct default LSM_MMAP_MIN_ADDR on arm on arm64
From: Eric Paris @ 2014-02-05 9:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140204093843.GB16708@mudshark.cambridge.arm.com>
Acked-by: Eric Paris <eparis@redhat.com>
On Tue, Feb 4, 2014 at 4:38 AM, Will Deacon <will.deacon@arm.com> wrote:
> On Tue, Feb 04, 2014 at 02:15:32AM +0000, Colin Cross wrote:
>> Binaries compiled for arm may run on arm64 if CONFIG_COMPAT is
>> selected. Set LSM_MMAP_MIN_ADDR to 32768 if ARM64 && COMPAT to
>> prevent selinux failures launching 32-bit static executables that
>> are mapped at 0x8000.
>>
>> Signed-off-by: Colin Cross <ccross@android.com>
>> ---
>> security/Kconfig | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/security/Kconfig b/security/Kconfig
>> index e9c6ac724fef..beb86b500adf 100644
>> --- a/security/Kconfig
>> +++ b/security/Kconfig
>> @@ -103,7 +103,7 @@ config INTEL_TXT
>> config LSM_MMAP_MIN_ADDR
>> int "Low address space for LSM to protect from user allocation"
>> depends on SECURITY && SECURITY_SELINUX
>> - default 32768 if ARM
>> + default 32768 if ARM || (ARM64 && COMPAT)
>> default 65536
>> help
>> This is the portion of low virtual memory which should be protected
>
> Since ARM64 && COMPAT implies 4k pages, this change looks ok to me.
>
> Acked-by: Will Deacon <will.deacon@arm.com>
>
> Will
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 0/6] ARM: STi reset controller support
From: Philipp Zabel @ 2014-02-05 9:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391437665-11913-1-git-send-email-srinivas.kandagatla@st.com>
Hi Srinivas,
Am Montag, den 03.02.2014, 14:27 +0000 schrieb
srinivas.kandagatla at st.com:
> From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
>
> Hi All,
>
> This patch series adds reset controller support for STi SOC series STiH415 and
> STiH416. It adds support for both power down reset and soft reset controllers.
> On STi series SOCs reset lines are wired up to system configuration registers.
> Most of the IPs on STi SOCs are left in reset state, so this driver is very
> important for other drivers to use the IPs.
>
> Patch 01: Adds reset controller based on system configuration registers via
> regmap.
>
> Patch 02, 03: adds STiH415 and STiH416 reset controller drivers.
>
> Patch 04, 05: adds STiH415 and STiH416 soft reset controllers.
>
> The final patch 06 selects reset controller in mach-sti Kconfig.
>
> I would like get this driver in to 3.15, so that its possible to add dt
> support for other IPs with reset lines. Without this patchset its impossible
> to add DT support to IPs with reset lines as reset line definition is in
> common header file in include/dt-bindings/.
>
> This reset controller will be used by gmac, i2c and st-ir drivers.
>
>
> Comments?
the patchset looks good to me for the soft resets. But for the powerdown
bits I am wondering whether the reset controller API is the right
abstraction. Depending on whether those bits really just put the IPs
into reset or there is some power gating / sequencing involved,
shouldn't this rather be handled as a set of pm domains?
I see that for example on STiH415 there are both soft resets and
powerdown bits for USB[012].
regards
Philipp
^ permalink raw reply
* [PATCH] arm: add DSB after icache flush in __flush_icache_all()
From: Vinayak Kale @ 2014-02-05 9:33 UTC (permalink / raw)
To: linux-arm-kernel
Add DSB after icache flush to complete the cache maintenance operation.
Signed-off-by: Vinayak Kale <vkale@apm.com>
---
PS:
- This patch is tested for ARM-v7.
arch/arm/include/asm/cacheflush.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/include/asm/cacheflush.h b/arch/arm/include/asm/cacheflush.h
index ee753f1..ab91ebb 100644
--- a/arch/arm/include/asm/cacheflush.h
+++ b/arch/arm/include/asm/cacheflush.h
@@ -212,6 +212,7 @@ extern void copy_to_user_page(struct vm_area_struct *, struct page *,
static inline void __flush_icache_all(void)
{
__flush_icache_preferred();
+ dsb();
}
/*
--
1.7.9.5
^ permalink raw reply related
* [PATCH] arm64: add DSB after icache flush in __flush_icache_all()
From: Vinayak Kale @ 2014-02-05 9:34 UTC (permalink / raw)
To: linux-arm-kernel
Add DSB after icache flush to complete the cache maintenance operation.
The function __flush_icache_all() is used only for user space mappings
and an ISB is not required because of an exception return before executing
user instructions. An exception return would behave like an ISB.
Signed-off-by: Vinayak Kale <vkale@apm.com>
---
arch/arm64/include/asm/cacheflush.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/include/asm/cacheflush.h b/arch/arm64/include/asm/cacheflush.h
index fea9ee3..88932498 100644
--- a/arch/arm64/include/asm/cacheflush.h
+++ b/arch/arm64/include/asm/cacheflush.h
@@ -116,6 +116,7 @@ extern void flush_dcache_page(struct page *);
static inline void __flush_icache_all(void)
{
asm("ic ialluis");
+ dsb();
}
#define flush_dcache_mmap_lock(mapping) \
--
1.7.9.5
^ permalink raw reply related
* [PATCH 09/10] watchdog: xilinx: Add missing binding
From: Arnd Bergmann @ 2014-02-05 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F20387.3090709@monstr.eu>
On Wednesday 05 February 2014, Michal Simek wrote:
> I am not quite sure what you mean by reports to user space.
> If you mean to get timeout through ioctl for example - then yes it is working
> through standard watchdog ioctl interface and timeout is calculated
> from hardware setup.
Yes, that is what I meant. I believe most other watchdogs let
you program the timeout, but I don't see anything wrong with
having that fixed in the FPGA in your case.
Still, the choice of putting the timeout into DT in terms of
cycles rather than miliseconds wasn't ideal from an interface
perspective and we should change that if/when we do a generic
binding. I can definitely see where it's coming from for your
case, as the cycle count totally makes sense from an FPGA
tool perspective...
Arnd
^ permalink raw reply
* [PATCH V2] arm64: add DSB after icache flush in __flush_icache_all()
From: Vinayak Kale @ 2014-02-05 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140203111754.GB14112@mudshark.cambridge.arm.com>
On Mon, Feb 3, 2014 at 4:47 PM, Will Deacon <will.deacon@arm.com> wrote:
> Hi Nico, Russell,
>
> Thanks for the replies.
>
> On Fri, Jan 31, 2014 at 10:48:50AM +0000, Russell King - ARM Linux wrote:
>> On Fri, Jan 31, 2014 at 12:16:48AM +0000, Will Deacon wrote:
>> > On Thu, Jan 30, 2014 at 09:42:29PM +0000, Nicolas Pitre wrote:
>> > > I don't think they would be reordered at all with the
>> > > volatile qualifiers.
>> >
>> > Whilst that may be the case in current compilers (i.e. I've not actually
>> > seen the above sequence get re-ordered), the GCC documentation states that:
>> >
>> > Similarly, you can't expect a sequence of volatile asm instructions to remain
>> > perfectly consecutive. If you want consecutive output, use a single asm. Also,
>> > GCC performs some optimizations across a volatile asm instruction; GCC does not
>> > `forget everything' when it encounters a volatile asm instruction the way some
>> > other compilers do.
>> >
>> > so I really think that the "memory" clobbers are needed to ensure strict
>> > ordering. This matches my understanding from discussions with the compiler
>> > engineers at ARM.
>>
>> What it means is that the compiler may introduce additional instructions
>> between your consecutive asm() statements. So there's no guarantee that
>> the ISB will immediately follow the MSR instruction - there may be other
>> instructions which the compiler may decide to schedule between the two.
>>
>> For example, instructions to load the address of the variable(s) may be
>> inserted between the assembly specified in the asm() statements which
>> may involve loading from a literal pool.
>
> That matches what Nicolas said and, to be honest, makes a lot of sense. I'm
> just slightly concerned that it doesn't match the explanation I received
> from some compiler guys, but I can chase that down separately.
>
> Vinayak: sorry for leading you down the garden path on this. Please can you
> stick with your original patch, but adding something equivalent for
> arch/arm?
I have posted a patch for arch/arm, have tested it for ARM-v7.
>
> Cheers,
>
> Will
^ permalink raw reply
* [PATCH 09/10] watchdog: xilinx: Add missing binding
From: Michal Simek @ 2014-02-05 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201402051036.19428.arnd@arndb.de>
On 02/05/2014 10:36 AM, Arnd Bergmann wrote:
> On Wednesday 05 February 2014, Michal Simek wrote:
>> I am not quite sure what you mean by reports to user space.
>> If you mean to get timeout through ioctl for example - then yes it is working
>> through standard watchdog ioctl interface and timeout is calculated
>> from hardware setup.
>
> Yes, that is what I meant. I believe most other watchdogs let
> you program the timeout, but I don't see anything wrong with
> having that fixed in the FPGA in your case.
>
> Still, the choice of putting the timeout into DT in terms of
> cycles rather than miliseconds wasn't ideal from an interface
> perspective and we should change that if/when we do a generic
> binding. I can definitely see where it's coming from for your
> case, as the cycle count totally makes sense from an FPGA
> tool perspective...
Thanks. I take this like ACK for this current binding description.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140205/a5adb1d4/attachment-0001.sig>
^ permalink raw reply
* [PATCH] clk: add strict of_clk_init dependency check
From: Boris BREZILLON @ 2014-02-05 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391554766-11285-1-git-send-email-gregory.clement@free-electrons.com>
The parent dependency check is only available on the first parent of a given
clk.
Add support for strict dependency check: all parents of a given clk must be
initialized.
Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
---
Hello Gregory,
This patch adds support for strict check on clk dependencies (check if all
parents specified by an DT clk node are initialized).
I'm not sure this is what you were expecting (maybe testing the first parent
is what you really want), so please feel free to tell me if I'm wrong.
Best Regards,
Boris
drivers/clk/clk.c | 27 +++++++++++++++++++++------
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index beb0f8b..6849769 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2543,22 +2543,37 @@ static int parent_ready(struct device_node *np)
{
struct of_phandle_args clkspec;
struct of_clk_provider *provider;
+ int num_parents;
+ bool found;
+ int i;
/*
* If there is no clock parent, no need to wait for them, then
* we can consider their absence as being ready
*/
- if (of_parse_phandle_with_args(np, "clocks", "#clock-cells", 0,
- &clkspec))
+ num_parents = of_count_phandle_with_args(np, "clocks", "#clock-cells");
+ if (num_parents <= 0)
return 1;
- /* Check if we have such a provider in our array */
- list_for_each_entry(provider, &of_clk_providers, link) {
- if (provider->node == clkspec.np)
+ for (i = 0; i < num_parents; i++) {
+ if (of_parse_phandle_with_args(np, "clocks", "#clock-cells", i,
+ &clkspec))
return 1;
+
+ /* Check if we have such a provider in our array */
+ found = false;
+ list_for_each_entry(provider, &of_clk_providers, link) {
+ if (provider->node == clkspec.np) {
+ found = true;
+ break;
+ }
+ }
+
+ if (!found)
+ return 0;
}
- return 0;
+ return 1;
}
/**
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 1/7] cpufreq: cpufreq-cpu0: allow optional safe voltage during frequency transitions
From: Heiko Stübner @ 2014-02-05 9:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140201041051.9977.46568@quantum>
Am Freitag, 31. Januar 2014, 20:10:51 schrieb Mike Turquette:
> Quoting Heiko St?bner (2014-01-30 07:09:04)
>
> > On Thursday, 30. January 2014 18:23:44 Thomas Abraham wrote:
> > > Hi Mike,
> > >
> > > On Wed, Jan 29, 2014 at 12:17 AM, Mike Turquette <mturquette@linaro.org>
> >
> > wrote:
> > > > On Mon, Jan 27, 2014 at 9:30 PM, Thomas Abraham <ta.omasab@gmail.com>
> >
> > wrote:
> > > >> Hi Mike,
> > > >>
> > > >> On Tue, Jan 28, 2014 at 1:55 AM, Mike Turquette
> > > >> <mturquette@linaro.org>
> >
> > wrote:
> > > >>> Quoting Thomas Abraham (2014-01-18 04:10:51)
> > > >
> > > > As far as I can tell
> > > > the remux does not happen because it is necessary to generate the
> > > > required clock rate, but because we don't want to run the ARM core out
> > > > of spec for a short time while the PLL relocks. Assuming I have that
> > > > part of it right, I prefer for the parent mux operation to be a part
> > > > of the CPUfreq driver's .target callback instead of hidden away in the
> > > > clock driver.
> > >
> > > The re-parenting is mostly done to keep the ARM CPU clocked while the
> > > PLL is stopped, reprogrammed and restarted. One of the side effects of
> > > that is, the clock speed of the temporary parent could be higher then
> > > what is allowed due to the ARM voltage at the time of re-parenting.
> > > That is the reason to use the safe voltage.
> >
> > The Rockchip-SoCs use something similar, so I'm following quite closely
> > what Thomas is trying to do here, as similar solution would also solve
> > this issue for me.
> >
> > On some Rockchip-SoCs even stuff like pclk and hclk seems to be sourced
> > from the divided armclk, creating additional constraints.
> >
> > But on the RKs (at least in the upstream sources) the armclk is simply
> > equal to the pll output. A divider exists, but is only used to make sure
> > that the armclk stays below the original rate when sourced from the
> > temp-parent, like>
> > if (clk_get_rate(temp_parent) > clk_get_rate(main_parent)
> >
> > set_divider(something so that rate(temp) <= rate(main)
> >
> > clk_set_parent(...)
> >
> > Isn't there a similar possiblity on your platform, as it would remove the
> > need for the safe-voltage?
> >
> >
> > In general I also like the approach of hiding the rate-change logic inside
> > this composite clock, as the depending clocks can be easily kept in sync.
> > As with the Rockchips the depending clocks are different for each of the
> > three Cortex-A9 SoCs I looked at, it would be "interesting" if all of
> > this would need to be done in a cpufreq driver.
>
> I wonder if hiding these details inside of the composite clock
> implementation indicates the lack of some needed feature in the clk
> core? I've discussed the idea of "coordinated rate changes" before. E.g:
>
> _________________________________________________________
>
> | clk | opp-low | opp-mid | opp-fast |
> |
> |pll | 300000 | 600000 | 600000 |
> |
> |div | 150000 | 300000 | 600000 |
> |
> |mpu_clk| 150000 | 300000 | 600000 |
> |
> |periph | 150000 | 150000 | 300000 |
>
> ---------------------------------------------------------
>
> A call to clk_set_rate() against any of those clocks will result in all
> of their dividers being updated. At the implementation level this might
> look something like this extremely simplified pseudocode:
>
> int clk_set_rate(struct clk* clk, unsigned long rate)
> {
> /* trap clks that support coordinated rate changes */
> if (clk->ops->coordinate_rate)
> return clk->ops->coordinate_rate(clk->hw, rate);
> ...
> }
>
> and,
>
> struct coord_rates {
> struct clk_hw *hw;
> struct clk *parent;
> struct clk *rate;
> };
>
> and in the clock driver,
>
> #define PLL 0
> #define DIV 1
> #define MPU 2
> #define PER 3
>
> #define NR_OPP 4
> #define NR_CLK 4
>
> struct coord_rates my_opps[NR_OPP][NR_CLK]; // populated from DT data
>
> int my_coordinate_rate_callback(struct clk_hw *hw, unsigned long rate)
> {
> struct coord_rate **selected_opp;
>
> for(i = 0; i < NR_OPP; i++) {
> for(j = 0; j < NR_CLK; j++) {
> if (my_opps[i][j]->hw == hw &&
> my_opps[i][j]->rate == rate)
> selected_opp = my_opps[i];
> break;
> }
> }
>
> /*
> * order of operations is specific to my hardware and should be
> * managed by my clock driver, not generic code
> */
>
> __clk_set_parent(selected_opp[DIV]->hw, temp_parent);
> __clk_set_rate(selected_opp[PLL]->hw, selected_opp[PLL]->rate);
> __clk_set_parent(selected_opp[DIV]->hw,
> selected_opp[PLL]->hw->clk);
> ...
>
> /*
> * note that the above could be handled by a switch-case or
> * something else
> */
> }
>
> Thoughts? Please forgive any gaps in my logic or abuse of C.
>
> I have long thought that something like the above would someday go into
> a generic dvfs layer instead of the clock framework, but maybe starting
> with the clk framework makes more sense?
Similar to Thomas, this looks like the thing I'd need for my core clocks.
Also to me this really looks like something belonging to the clock framework,
as we at this point really only have some clocks that in all cases need to be
set together, independent of it beeing embedded in some scaling context or
something else.
Heiko
^ permalink raw reply
* [PATCH v2 5/5] of: document bindings for reserved-memory nodes
From: Grant Likely @ 2014-02-05 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391515773-6112-6-git-send-email-m.szyprowski@samsung.com>
On Tue, 04 Feb 2014 13:09:33 +0100, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> From: Grant Likely <grant.likely@linaro.org>
>
> Reserved memory nodes allow for the reservation of static (fixed
> address) regions, or dynamically allocated regions for a specific
> purpose.
>
> [joshc: Based on binding document proposed (in non-patch form) here:
> http://lkml.kernel.org/g/20131030134702.19B57C402A0 at trevor.secretlab.ca
> adapted to support #memory-region-cells]
>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Laura Abbott <lauraa@codeaurora.org>
> Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> .../bindings/reserved-memory/reserved-memory.txt | 138 ++++++++++++++++++++
> 1 file changed, 138 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
>
> diff --git a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> new file mode 100644
> index 000000000000..a606ce90c9c4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> @@ -0,0 +1,138 @@
> +*** Reserved memory regions ***
> +
> +Reserved memory is specified as a node under the /reserved-memory node.
> +The operating system shall exclude reserved memory from normal usage
> +one can create child nodes describing particular reserved (excluded from
> +normal use) memory regions. Such memory regions are usually designed for
> +the special usage by various device drivers.
> +
> +Parameters for each memory region can be encoded into the device tree
> +with the following nodes:
> +
> +/reserved-memory node
> +---------------------
> +#address-cells, #size-cells (required) - standard definition
> + - Should use the same values as the root node
> +#memory-region-cells (required) - dictates number of cells used in the child
> + nodes memory-region specifier
I don't think this isn't defined well enough. These reserved regions may
not have a driver attached to them, so there is no central agent to
decide what the specifier means. That leaves the interpretation of
the memory region in the hands of the client drivers. How do you see the
specifier getting parsed and used?
Otherwise the binding looks good to me. Also, please add my s-o-b line
to the patch (instead of a-b because I authored part of the text)
Signed-off-by: Grant Likely <grant.likely@linaro.org>
g.
> +ranges (required) - standard definition
> + - Should be empty
> +
> +/reserved-memory/ child nodes
> +-----------------------------
> +Each child of the reserved-memory node specifies one or more regions of
> +reserved memory. Each child node may either use a 'reg' property to
> +specify a specific range of reserved memory, or a 'size' property with
> +optional constraints to request a dynamically allocated block of memory.
> +
> +Following the generic-names recommended practice, node names should
> +reflect the purpose of the node (ie. "framebuffer" or "dma-pool"). Unit
> +address (@<address>) should be appended to the name if the node is a
> +static allocation.
> +
> +Properties:
> +Requires either a) or b) below.
> +a) static allocation
> + reg (required) - standard definition
> +b) dynamic allocation
> + size (required) - length based on parent's #size-cells
> + - Size in bytes of memory to reserve.
> + alignment (optional) - length based on parent's #size-cells
> + - Address boundary for alignment of allocation.
> + alloc-ranges (optional) - prop-encoded-array (address, length pairs).
> + - Specifies regions of memory that are
> + acceptable to allocate from.
> +
> +If both reg and size are present, then the reg property takes precedence
> +and size is ignored.
> +
> +Additional properties:
> +compatible (optional) - standard definition
> + - may contain the following strings:
> + - shared-dma-pool: This indicates a region of memory meant to be
> + used as a shared pool of DMA buffers for a set of devices. It can
> + be used by an operating system to instanciate the necessary pool
> + management subsystem if necessary.
> + - vendor specific string in the form <vendor>,[<device>-]<usage>
> +no-map (optional) - empty property
> + - Indicates the operating system must not create a virtual mapping
> + of the region as part of its standard mapping of system memory,
> + nor permit speculative access to it under any circumstances other
> + than under the control of the device driver using the region.
> +reusable (optional) - empty property
> + - The operating system can use the memory in this region with the
> + limitation that the device driver(s) owning the region need to be
> + able to reclaim it back. Typically that means that the operating
> + system can use that region to store volatile or cached data that
> + can be otherwise regenerated or migrated elsewhere.
> +
> +Linux implementation note:
> +- If a "linux,cma-default" property is present, then Linux will use the
> + region for the default pool of the contiguous memory allocator.
> +
> +Device node references to reserved memory
> +-----------------------------------------
> +Regions in the /reserved-memory node may be referenced by other device
> +nodes by adding a memory-region property to the device node.
> +
> +memory-region (optional) - phandle, specifier pairs to children of /reserved-memory
> +
> +Example
> +-------
> +This example defines 3 contiguous regions are defined for Linux kernel:
> +one default of all device drivers (named linux,cma at 72000000 and 64MiB in size),
> +one dedicated to the framebuffer device (named framebuffer at 78000000, 8MiB), and
> +one for multimedia processing (named multimedia-memory at 77000000, 64MiB).
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + memory {
> + reg = <0x40000000 0x40000000>;
> + };
> +
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + /* global autoconfigured region for contiguous allocations */
> + linux,cma {
> + compatible = "shared-dma-pool";
> + reusable;
> + #memory-region-cells = <0>;
> + size = <0x4000000>;
> + alignment = <0x2000>;
> + linux,cma-default;
> + };
> +
> + display_reserved: framebuffer at 78000000 {
> + #memory-region-cells = <0>;
> + reg = <0x78000000 0x800000>;
> + };
> +
> + multimedia_reserved: multimedia at 77000000 {
> + compatible = "acme,multimedia-memory";
> + #memory-region-cells = <1>;
> + reg = <0x77000000 0x4000000>;
> + };
> + };
> +
> + /* ... */
> +
> + fb0: video at 12300000 {
> + memory-region = <&display_reserved>;
> + /* ... */
> + };
> +
> + scaler: scaler at 12500000 {
> + memory-region = <&multimedia_reserved 0xdeadbeef>;
> + /* ... */
> + };
> +
> + codec: codec at 12600000 {
> + memory-region = <&multimedia_reserved 0xfeebdaed>;
> + /* ... */
> + };
> +};
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH v2 1/2] arm64: vdso: fix coarse clock handling
From: Will Deacon @ 2014-02-05 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391579584-412-1-git-send-email-nathan_lynch@mentor.com>
On Wed, Feb 05, 2014 at 05:53:04AM +0000, Nathan Lynch wrote:
> When __kernel_clock_gettime is called with a CLOCK_MONOTONIC_COARSE or
> CLOCK_REALTIME_COARSE clock id, it returns incorrectly to whatever the
> caller has placed in x2 ("ret x2" to return from the fast path). Fix
> this by saving x30/LR to x2 only in code that will call
> __do_get_tspec, restoring x30 afterward, and using a plain "ret" to
> return from the routine.
>
> Also: while the resulting tv_nsec value for CLOCK_REALTIME and
> CLOCK_MONOTONIC must be computed using intermediate values that are
> left-shifted by cs_shift (x12, set by __do_get_tspec), the results for
> coarse clocks should be calculated using unshifted values
> (xtime_coarse_nsec is in units of actual nanoseconds). The current
> code shifts intermediate values by x12 unconditionally, but x12 is
> uninitialized when servicing a coarse clock. Fix this by setting x12
> to 0 once we know we are dealing with a coarse clock id.
>
> Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com>
> ---
Thanks for the quick update Nathan!
Acked-by: Will Deacon <will.deacon@arm.com>
Catalin: both of these are candidates for stable.
Will
^ permalink raw reply
* [PATCH] arm64: add DSB after icache flush in __flush_icache_all()
From: Will Deacon @ 2014-02-05 10:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391592876-18627-1-git-send-email-vkale@apm.com>
On Wed, Feb 05, 2014 at 09:34:36AM +0000, Vinayak Kale wrote:
> Add DSB after icache flush to complete the cache maintenance operation.
> The function __flush_icache_all() is used only for user space mappings
> and an ISB is not required because of an exception return before executing
> user instructions. An exception return would behave like an ISB.
>
> Signed-off-by: Vinayak Kale <vkale@apm.com>
> ---
> arch/arm64/include/asm/cacheflush.h | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH v2 4/5] ARM: init: add support for reserved memory defined by device tree
From: Grant Likely @ 2014-02-05 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391515773-6112-5-git-send-email-m.szyprowski@samsung.com>
On Tue, 04 Feb 2014 13:09:32 +0100, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> Enable reserved memory initialization from device tree.
>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Laura Abbott <lauraa@codeaurora.org>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> arch/arm/mm/init.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index 804d61566a53..ebafdb479410 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -17,6 +17,7 @@
> #include <linux/nodemask.h>
> #include <linux/initrd.h>
> #include <linux/of_fdt.h>
> +#include <linux/of_reserved_mem.h>
> #include <linux/highmem.h>
> #include <linux/gfp.h>
> #include <linux/memblock.h>
> @@ -323,6 +324,8 @@ void __init arm_memblock_init(struct meminfo *mi,
> if (mdesc->reserve)
> mdesc->reserve();
>
> + early_init_dt_scan_reserved_mem();
> +
The new binding is being made fundamental. If the reserved-memory node
is present, then it needs to be honored, even if the kernel doesn't know
how to use the regions. Therefore, This needs to be unconditional for
all architectures. The hook should be called in early_init_dt_scan()
(drivers/of/fdt.c) immediately after the early_init_dt_scan_memory()
hook.
> /*
> * reserve memory for DMA contigouos allocations,
> * must come from DMA area inside low memory
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* [PATCH v2 7/7] cpufreq: exynos: remove all exynos specific cpufreq driver support
From: Thomas Abraham @ 2014-02-05 10:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140120090815.39e8c21a@amdc2363>
Hi Lukasz,
On Mon, Jan 20, 2014 at 1:38 PM, Lukasz Majewski <l.majewski@samsung.com> wrote:
> Hi Thomas,
>
>> From: Thomas Abraham <thomas.ab@samsung.com>
>>
>> Exynos4210, Exynos4x12 and Exynos5250 based platforms have switched
>> over to use cpufreq-cpu0 driver for cpufreq functionality. So the
>> Exynos specific cpufreq drivers for these platforms can be removed.
>>
<snip>
>> -static unsigned int exynos4x12_volt_table[] = {
>> - 1350000, 1287500, 1250000, 1187500, 1137500, 1087500,
>> 1037500,
>> - 1000000, 987500, 975000, 950000, 925000, 900000, 900000
>> -};
>> -
>> -static struct cpufreq_frequency_table exynos4x12_freq_table[] = {
>> - {CPUFREQ_BOOST_FREQ, 1500 * 1000},
>
> Here, you are removing BOOST support for Exynos4412, without any code,
> which brings back this functionality in the new code.
>
> I'd propose adding new property to cpus node and during
> operating-points parsing mark the entry at the cpufreq_frequency_table
> accordingly.
I tried doing this as you suggested with [1] but looks like that will
not go through at this point. The other alternative would be to use
exynos specific cpufreq drivers only if multiplatform config is not
selected or use cpufreq-cpu0 if multiplatform config is selected (but
this is not something I would want to do). With this, there are issues
like clock blocks encapsulated within the opaque clock type cannot be
removed since exynos specific cpufreq drivers need it and hence it is
not really a clean solution. The other option is to drop the support
for boost on exynos4x12 for now and reintroduce that when the OPP
bindings have been finalized. Would that be okay? Any other
suggestions will also be helpful.
Thanks,
Thomas.
>
>> - {L1, 1400 * 1000},
>> - {L2, 1300 * 1000},
>> - {L3, 1200 * 1000},
>> - {L4, 1100 * 1000},
>> - {L5, 1000 * 1000},
>> - {L6, 900 * 1000},
>> - {L7, 800 * 1000},
>> - {L8, 700 * 1000},
>> - {L9, 600 * 1000},
>> - {L10, 500 * 1000},
>> - {L11, 400 * 1000},
>> - {L12, 300 * 1000},
>> - {L13, 200 * 1000},
>> - {0, CPUFREQ_TABLE_END},
>> -};
>> -
>> -static struct apll_freq *apll_freq_4x12;
>> -
>> -static struct apll_freq apll_freq_4212[] = {
>> - /*
>> - * values:
>> - * freq
>> - * clock divider for CORE, COREM0, COREM1, PERIPH, ATB,
>> PCLK_DBG, APLL, CORE2
>> - * clock divider for COPY, HPM, RESERVED
>> - * PLL M, P, S
>> - */
>> - APLL_FREQ(1500, 0, 3, 7, 0, 6, 1, 2, 0, 6, 2, 0, 250, 4, 0),
>> - APLL_FREQ(1400, 0, 3, 7, 0, 6, 1, 2, 0, 6, 2, 0, 175, 3, 0),
>> - APLL_FREQ(1300, 0, 3, 7, 0, 5, 1, 2, 0, 5, 2, 0, 325, 6, 0),
>> - APLL_FREQ(1200, 0, 3, 7, 0, 5, 1, 2, 0, 5, 2, 0, 200, 4, 0),
>> - APLL_FREQ(1100, 0, 3, 6, 0, 4, 1, 2, 0, 4, 2, 0, 275, 6, 0),
>> - APLL_FREQ(1000, 0, 2, 5, 0, 4, 1, 1, 0, 4, 2, 0, 125, 3, 0),
>> - APLL_FREQ(900, 0, 2, 5, 0, 3, 1, 1, 0, 3, 2, 0, 150, 4, 0),
>> - APLL_FREQ(800, 0, 2, 5, 0, 3, 1, 1, 0, 3, 2, 0, 100, 3, 0),
>> - APLL_FREQ(700, 0, 2, 4, 0, 3, 1, 1, 0, 3, 2, 0, 175, 3, 1),
>> - APLL_FREQ(600, 0, 2, 4, 0, 3, 1, 1, 0, 3, 2, 0, 200, 4, 1),
>> - APLL_FREQ(500, 0, 2, 4, 0, 3, 1, 1, 0, 3, 2, 0, 125, 3, 1),
>> - APLL_FREQ(400, 0, 2, 4, 0, 3, 1, 1, 0, 3, 2, 0, 100, 3, 1),
>> - APLL_FREQ(300, 0, 2, 4, 0, 2, 1, 1, 0, 3, 2, 0, 200, 4, 2),
>> - APLL_FREQ(200, 0, 1, 3, 0, 1, 1, 1, 0, 3, 2, 0, 100, 3, 2),
>> -};
>> -
>> -static struct apll_freq apll_freq_4412[] = {
>> - /*
>> - * values:
>> - * freq
>> - * clock divider for CORE, COREM0, COREM1, PERIPH, ATB,
>> PCLK_DBG, APLL, CORE2
>> - * clock divider for COPY, HPM, CORES
>> - * PLL M, P, S
>> - */
>> - APLL_FREQ(1500, 0, 3, 7, 0, 6, 1, 2, 0, 6, 0, 7, 250, 4, 0),
>> - APLL_FREQ(1400, 0, 3, 7, 0, 6, 1, 2, 0, 6, 0, 6, 175, 3, 0),
>> - APLL_FREQ(1300, 0, 3, 7, 0, 5, 1, 2, 0, 5, 0, 6, 325, 6, 0),
>> - APLL_FREQ(1200, 0, 3, 7, 0, 5, 1, 2, 0, 5, 0, 5, 200, 4, 0),
>> - APLL_FREQ(1100, 0, 3, 6, 0, 4, 1, 2, 0, 4, 0, 5, 275, 6, 0),
>> - APLL_FREQ(1000, 0, 2, 5, 0, 4, 1, 1, 0, 4, 0, 4, 125, 3, 0),
>> - APLL_FREQ(900, 0, 2, 5, 0, 3, 1, 1, 0, 3, 0, 4, 150, 4, 0),
>> - APLL_FREQ(800, 0, 2, 5, 0, 3, 1, 1, 0, 3, 0, 3, 100, 3, 0),
>> - APLL_FREQ(700, 0, 2, 4, 0, 3, 1, 1, 0, 3, 0, 3, 175, 3, 1),
>> - APLL_FREQ(600, 0, 2, 4, 0, 3, 1, 1, 0, 3, 0, 2, 200, 4, 1),
>> - APLL_FREQ(500, 0, 2, 4, 0, 3, 1, 1, 0, 3, 0, 2, 125, 3, 1),
>> - APLL_FREQ(400, 0, 2, 4, 0, 3, 1, 1, 0, 3, 0, 1, 100, 3, 1),
>> - APLL_FREQ(300, 0, 2, 4, 0, 2, 1, 1, 0, 3, 0, 1, 200, 4, 2),
>> - APLL_FREQ(200, 0, 1, 3, 0, 1, 1, 1, 0, 3, 0, 0, 100, 3, 2),
>> -};
>> -
>> -static void exynos4x12_set_clkdiv(unsigned int div_index)
>> -{
>> - unsigned int tmp;
>> - unsigned int stat_cpu1;
>> -
>> - /* Change Divider - CPU0 */
>> -
>> - tmp = apll_freq_4x12[div_index].clk_div_cpu0;
>> -
>> - __raw_writel(tmp, EXYNOS4_CLKDIV_CPU);
>> -
>> - while (__raw_readl(EXYNOS4_CLKDIV_STATCPU) & 0x11111111)
>> - cpu_relax();
>> -
>> - /* Change Divider - CPU1 */
>> - tmp = apll_freq_4x12[div_index].clk_div_cpu1;
>> -
>> - __raw_writel(tmp, EXYNOS4_CLKDIV_CPU1);
>> - if (soc_is_exynos4212())
>> - stat_cpu1 = 0x11;
>> - else
>> - stat_cpu1 = 0x111;
>> -
>> - while (__raw_readl(EXYNOS4_CLKDIV_STATCPU1) & stat_cpu1)
>> - cpu_relax();
>> -}
>> -
>> -static void exynos4x12_set_apll(unsigned int index)
>> -{
>> - unsigned int tmp, freq = apll_freq_4x12[index].freq;
>> -
>> - /* MUX_CORE_SEL = MPLL, ARMCLK uses MPLL for lock time */
>> - clk_set_parent(moutcore, mout_mpll);
>> -
>> - do {
>> - cpu_relax();
>> - tmp = (__raw_readl(EXYNOS4_CLKMUX_STATCPU)
>> - >> EXYNOS4_CLKSRC_CPU_MUXCORE_SHIFT);
>> - tmp &= 0x7;
>> - } while (tmp != 0x2);
>> -
>> - clk_set_rate(mout_apll, freq * 1000);
>> -
>> - /* MUX_CORE_SEL = APLL */
>> - clk_set_parent(moutcore, mout_apll);
>> -
>> - do {
>> - cpu_relax();
>> - tmp = __raw_readl(EXYNOS4_CLKMUX_STATCPU);
>> - tmp &= EXYNOS4_CLKMUX_STATCPU_MUXCORE_MASK;
>> - } while (tmp != (0x1 << EXYNOS4_CLKSRC_CPU_MUXCORE_SHIFT));
>> -}
>> -
>> -static void exynos4x12_set_frequency(unsigned int old_index,
>> - unsigned int new_index)
>> -{
>> - if (old_index > new_index) {
>> - exynos4x12_set_clkdiv(new_index);
>> - exynos4x12_set_apll(new_index);
>> - } else if (old_index < new_index) {
>> - exynos4x12_set_apll(new_index);
>> - exynos4x12_set_clkdiv(new_index);
>> - }
>> -}
>> -
>> -int exynos4x12_cpufreq_init(struct exynos_dvfs_info *info)
>> -{
>> - unsigned long rate;
>> -
>> - cpu_clk = clk_get(NULL, "armclk");
>> - if (IS_ERR(cpu_clk))
>> - return PTR_ERR(cpu_clk);
>> -
>> - moutcore = clk_get(NULL, "moutcore");
>> - if (IS_ERR(moutcore))
>> - goto err_moutcore;
>> -
>> - mout_mpll = clk_get(NULL, "mout_mpll");
>> - if (IS_ERR(mout_mpll))
>> - goto err_mout_mpll;
>> -
>> - rate = clk_get_rate(mout_mpll) / 1000;
>> -
>> - mout_apll = clk_get(NULL, "mout_apll");
>> - if (IS_ERR(mout_apll))
>> - goto err_mout_apll;
>> -
>> - if (soc_is_exynos4212())
>> - apll_freq_4x12 = apll_freq_4212;
>> - else
>> - apll_freq_4x12 = apll_freq_4412;
>> -
>> - info->mpll_freq_khz = rate;
>> - /* 800Mhz */
>> - info->pll_safe_idx = L7;
>> - info->cpu_clk = cpu_clk;
>> - info->volt_table = exynos4x12_volt_table;
>> - info->freq_table = exynos4x12_freq_table;
>> - info->set_freq = exynos4x12_set_frequency;
>> -
>> - return 0;
>> -
>> -err_mout_apll:
>> - clk_put(mout_mpll);
>> -err_mout_mpll:
>> - clk_put(moutcore);
>> -err_moutcore:
>> - clk_put(cpu_clk);
>> -
>> - pr_debug("%s: failed initialization\n", __func__);
>> - return -EINVAL;
>> -}
>> diff --git a/drivers/cpufreq/exynos5250-cpufreq.c
>> b/drivers/cpufreq/exynos5250-cpufreq.c deleted file mode 100644
>> index 5f90b82..0000000
>> --- a/drivers/cpufreq/exynos5250-cpufreq.c
>> +++ /dev/null
>> @@ -1,183 +0,0 @@
>> -/*
>> - * Copyright (c) 2010-20122Samsung Electronics Co., Ltd.
>> - * http://www.samsung.com
>> - *
>> - * EXYNOS5250 - CPU frequency scaling support
>> - *
>> - * 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 <linux/module.h>
>> -#include <linux/kernel.h>
>> -#include <linux/err.h>
>> -#include <linux/clk.h>
>> -#include <linux/io.h>
>> -#include <linux/slab.h>
>> -#include <linux/cpufreq.h>
>> -
>> -#include <mach/map.h>
>> -
>> -#include "exynos-cpufreq.h"
>> -
>> -static struct clk *cpu_clk;
>> -static struct clk *moutcore;
>> -static struct clk *mout_mpll;
>> -static struct clk *mout_apll;
>> -
>> -static unsigned int exynos5250_volt_table[] = {
>> - 1300000, 1250000, 1225000, 1200000, 1150000,
>> - 1125000, 1100000, 1075000, 1050000, 1025000,
>> - 1012500, 1000000, 975000, 950000, 937500,
>> - 925000
>> -};
>> -
>> -static struct cpufreq_frequency_table exynos5250_freq_table[] = {
>> - {L0, 1700 * 1000},
>> - {L1, 1600 * 1000},
>> - {L2, 1500 * 1000},
>> - {L3, 1400 * 1000},
>> - {L4, 1300 * 1000},
>> - {L5, 1200 * 1000},
>> - {L6, 1100 * 1000},
>> - {L7, 1000 * 1000},
>> - {L8, 900 * 1000},
>> - {L9, 800 * 1000},
>> - {L10, 700 * 1000},
>> - {L11, 600 * 1000},
>> - {L12, 500 * 1000},
>> - {L13, 400 * 1000},
>> - {L14, 300 * 1000},
>> - {L15, 200 * 1000},
>> - {0, CPUFREQ_TABLE_END},
>> -};
>> -
>> -static struct apll_freq apll_freq_5250[] = {
>> - /*
>> - * values:
>> - * freq
>> - * clock divider for ARM, CPUD, ACP, PERIPH, ATB, PCLK_DBG,
>> APLL, ARM2
>> - * clock divider for COPY, HPM, RESERVED
>> - * PLL M, P, S
>> - */
>> - APLL_FREQ(1700, 0, 3, 7, 7, 7, 3, 5, 0, 0, 2, 0, 425, 6, 0),
>> - APLL_FREQ(1600, 0, 3, 7, 7, 7, 1, 4, 0, 0, 2, 0, 200, 3, 0),
>> - APLL_FREQ(1500, 0, 2, 7, 7, 7, 1, 4, 0, 0, 2, 0, 250, 4, 0),
>> - APLL_FREQ(1400, 0, 2, 7, 7, 6, 1, 4, 0, 0, 2, 0, 175, 3, 0),
>> - APLL_FREQ(1300, 0, 2, 7, 7, 6, 1, 3, 0, 0, 2, 0, 325, 6, 0),
>> - APLL_FREQ(1200, 0, 2, 7, 7, 5, 1, 3, 0, 0, 2, 0, 200, 4, 0),
>> - APLL_FREQ(1100, 0, 3, 7, 7, 5, 1, 3, 0, 0, 2, 0, 275, 6, 0),
>> - APLL_FREQ(1000, 0, 1, 7, 7, 4, 1, 2, 0, 0, 2, 0, 125, 3, 0),
>> - APLL_FREQ(900, 0, 1, 7, 7, 4, 1, 2, 0, 0, 2, 0, 150, 4, 0),
>> - APLL_FREQ(800, 0, 1, 7, 7, 4, 1, 2, 0, 0, 2, 0, 100, 3, 0),
>> - APLL_FREQ(700, 0, 1, 7, 7, 3, 1, 1, 0, 0, 2, 0, 175, 3, 1),
>> - APLL_FREQ(600, 0, 1, 7, 7, 3, 1, 1, 0, 0, 2, 0, 200, 4, 1),
>> - APLL_FREQ(500, 0, 1, 7, 7, 2, 1, 1, 0, 0, 2, 0, 125, 3, 1),
>> - APLL_FREQ(400, 0, 1, 7, 7, 2, 1, 1, 0, 0, 2, 0, 100, 3, 1),
>> - APLL_FREQ(300, 0, 1, 7, 7, 1, 1, 1, 0, 0, 2, 0, 200, 4, 2),
>> - APLL_FREQ(200, 0, 1, 7, 7, 1, 1, 1, 0, 0, 2, 0, 100, 3, 2),
>> -};
>> -
>> -static void set_clkdiv(unsigned int div_index)
>> -{
>> - unsigned int tmp;
>> -
>> - /* Change Divider - CPU0 */
>> -
>> - tmp = apll_freq_5250[div_index].clk_div_cpu0;
>> -
>> - __raw_writel(tmp, EXYNOS5_CLKDIV_CPU0);
>> -
>> - while (__raw_readl(EXYNOS5_CLKDIV_STATCPU0) & 0x11111111)
>> - cpu_relax();
>> -
>> - /* Change Divider - CPU1 */
>> - tmp = apll_freq_5250[div_index].clk_div_cpu1;
>> -
>> - __raw_writel(tmp, EXYNOS5_CLKDIV_CPU1);
>> -
>> - while (__raw_readl(EXYNOS5_CLKDIV_STATCPU1) & 0x11)
>> - cpu_relax();
>> -}
>> -
>> -static void set_apll(unsigned int index)
>> -{
>> - unsigned int tmp;
>> - unsigned int freq = apll_freq_5250[index].freq;
>> -
>> - /* MUX_CORE_SEL = MPLL, ARMCLK uses MPLL for lock time */
>> - clk_set_parent(moutcore, mout_mpll);
>> -
>> - do {
>> - cpu_relax();
>> - tmp = (__raw_readl(EXYNOS5_CLKMUX_STATCPU) >> 16);
>> - tmp &= 0x7;
>> - } while (tmp != 0x2);
>> -
>> - clk_set_rate(mout_apll, freq * 1000);
>> -
>> - /* MUX_CORE_SEL = APLL */
>> - clk_set_parent(moutcore, mout_apll);
>> -
>> - do {
>> - cpu_relax();
>> - tmp = __raw_readl(EXYNOS5_CLKMUX_STATCPU);
>> - tmp &= (0x7 << 16);
>> - } while (tmp != (0x1 << 16));
>> -}
>> -
>> -static void exynos5250_set_frequency(unsigned int old_index,
>> - unsigned int new_index)
>> -{
>> - if (old_index > new_index) {
>> - set_clkdiv(new_index);
>> - set_apll(new_index);
>> - } else if (old_index < new_index) {
>> - set_apll(new_index);
>> - set_clkdiv(new_index);
>> - }
>> -}
>> -
>> -int exynos5250_cpufreq_init(struct exynos_dvfs_info *info)
>> -{
>> - unsigned long rate;
>> -
>> - cpu_clk = clk_get(NULL, "armclk");
>> - if (IS_ERR(cpu_clk))
>> - return PTR_ERR(cpu_clk);
>> -
>> - moutcore = clk_get(NULL, "mout_cpu");
>> - if (IS_ERR(moutcore))
>> - goto err_moutcore;
>> -
>> - mout_mpll = clk_get(NULL, "mout_mpll");
>> - if (IS_ERR(mout_mpll))
>> - goto err_mout_mpll;
>> -
>> - rate = clk_get_rate(mout_mpll) / 1000;
>> -
>> - mout_apll = clk_get(NULL, "mout_apll");
>> - if (IS_ERR(mout_apll))
>> - goto err_mout_apll;
>> -
>> - info->mpll_freq_khz = rate;
>> - /* 800Mhz */
>> - info->pll_safe_idx = L9;
>> - info->cpu_clk = cpu_clk;
>> - info->volt_table = exynos5250_volt_table;
>> - info->freq_table = exynos5250_freq_table;
>> - info->set_freq = exynos5250_set_frequency;
>> -
>> - return 0;
>> -
>> -err_mout_apll:
>> - clk_put(mout_mpll);
>> -err_mout_mpll:
>> - clk_put(moutcore);
>> -err_moutcore:
>> - clk_put(cpu_clk);
>> -
>> - pr_err("%s: failed initialization\n", __func__);
>> - return -EINVAL;
>> -}
>
>
>
> --
> Best regards,
>
> Lukasz Majewski
>
> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply
* [PATCH v3 3/6] misc: fuse: Add efuse driver for Tegra
From: Jim Lin @ 2014-02-05 10:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140203141529.GF19389@tbergstrom-lnx.Nvidia.com>
Please ignore my comment.
I will try to use exported tegra_fuse_readl().
-----Original Message-----
From: Peter De Schrijver [mailto:pdeschrijver at nvidia.com]
Sent: Monday, February 03, 2014 10:15 PM
To: Jim Lin
Cc: linux-arm-kernel at lists.infradead.org; linux-tegra at vger.kernel.org; linux-kernel at vger.kernel.org; Rob Landley; Stephen Warren; Thierry Reding; Grant Likely; Rob Herring; Danny Huang; linux-doc at vger.kernel.org; devicetree at vger.kernel.org
Subject: Re: [PATCH v3 3/6] misc: fuse: Add efuse driver for Tegra
On Wed, Jan 29, 2014 at 03:26:18AM +0100, Jim Lin wrote:
> On Wed, 2014-01-29 at 07:36 +0800, Peter De Schrijver wrote:
> > Implement fuse driver for Tegra20, Tegra30, Tegra114 and Tegra124.
> >
> > Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
> > ---
> > Documentation/ABI/testing/sysfs-driver-tegra-fuse | 8 +
> > drivers/misc/fuse/Makefile | 1 +
> > drivers/misc/fuse/tegra/Makefile | 7 +
> > drivers/misc/fuse/tegra/fuse-tegra.c | 228 ++++++++++++++++
> > drivers/misc/fuse/tegra/fuse-tegra20.c | 136 ++++++++++
> > drivers/misc/fuse/tegra/fuse-tegra30.c | 178 +++++++++++++
> > drivers/misc/fuse/tegra/fuse.h | 82 ++++++
> Could we move this fuse.h to other folder under /include/linux (like
> /include/linux/platform_data) for other driver to include?
I don't think we should expose everything in fuse.h to the world.
> So other driver can invoke function to read fuse data if needed.
Which functionality do you want? Just reading the fuse data exposed in the sysfs file from a driver? exporting tegra_fuse_readl() should do that I think?
Cheers,
Peter.
--nvpublic
^ 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