* OMAP4 clock/pm fixes [was: [PATCH v4 2/3] ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage
From: Archit Taneja @ 2012-10-05 13:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506ED492.5010709@ti.com>
On Friday 05 October 2012 06:07 PM, Rajendra Nayak wrote:
> On Friday 05 October 2012 05:59 PM, Archit Taneja wrote:
>> The other not so good option to make DSS PM work would be to add
>> OCPIF_SWSUP_IDLE flag to our l3_main_2__dss_* slave interfaces(which
>> have the hack "dss_fck" as slave clock). I gave this approach a try,
>> that too isn't working so well. When I disable DSS, I get
>> CM_DSS_DSS_CLKCTRL.IDLEST as 0x1, and
>> CM_DSS_CLKSTCTRL.CLKACTIVITY_DSS_L3_ICLK is set. I wonder why that's
>> happening.
>
> I have seen DSS get stuck in transition, with just a clkdm state toggle
> (from say HWSUP to SWWKUP) while its optional clocks are not running.
> Thats probably whats happening now.
Oh ok, I can notice that too. So in the _idle() path, the clocks are
disabled first, and then we try to change the clkdm state. I guess that
could be the reason why DSS doesn't sleep.
But then, I don't understand why this problem isn't seen if I try the
alternative option of removing the fake dss_fck slave clock, and tie
modulemode to only the parent hwmod. There DSS IDLEST is 0x3 when I
disable DSS.
I think with this approach, the problem is with _disable_clocks(), in
disable_clocks, main_clk is disabled first, and then the slave clocks.
That translates to DSS_FCK opt clock getting disabled first, and then
MODULEMODE bits. I think DSS doesn't transition to sleep with this
disable sequence.
>
> Did you try keeping the modulemode enabled and see if it really gates
> DSS/system sleep. I remember testing with Teros CORE ret/off patches
> and I was always seeing DSS modulemode enabled but it wasn't gating
> sleep.
If the clkdm is in HW_AUTO, I can get DSS in sleep(STBYST and IDLEST all
set). Is this helpful? Can we just leave modulemode on all the time?
That'll be the best :)
Anyway, I guess it would be the best to have a custom _setup function(or
skip them all together) for DSS as Benoit suggested.
Archit
^ permalink raw reply
* [PATCH 1/2] ARM: nomadik: switch over to using the FSMC driver
From: Alessandro Rubini @ 2012-10-05 12:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYMz05DwtLtHkggvo8VFOtvPLpovwq6fLceeiFK0Wci0Q@mail.gmail.com>
>> The Nomadik NAND driver is really just a subset of the existing
>> FSMC driver,
>>
>> Cc: Alessandro Rubini <rubini@unipv.it>
> Still requesting Mike's ACK, but not for merging through ARM SoC
> but through MTD.
Oh, and please get mine too. Sorry for not noticing the message, busy
times...
I'm pretty sure there was no fsmc driver back then. But clearly
something coming from the vendor and used on several boards is better
then something made by an external consultant for a specific
evaluation board. So ok to ditch my nand driver.
Acked-by: Alessandro Rubini <rubini@unipv.it>
^ permalink raw reply
* [PATCH 1/2] ARM: nomadik: switch over to using the FSMC driver
From: Linus Walleij @ 2012-10-05 12:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349335709-13399-1-git-send-email-linus.walleij@linaro.org>
On Thu, Oct 4, 2012 at 9:28 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> The Nomadik NAND driver is really just a subset of the existing
> FSMC driver, so let's switch over to using that driver instead,
> since it handles more variants of this chip. The callbacks for
> setting up the chip is doing stuff now handled by the FSMC
> driver.
>
> Cc: Alessandro Rubini <rubini@unipv.it>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> I'm requesting Mike Turquette's ACK on this patch so I can merge
> it through ARM SoC.
Still requesting Mike's ACK, but not for merging through ARM SoC
but through MTD.
If you apply Jean-Christophe's patch first (please do that) I will
send a v2 of this patch set to be applied onto MTD as well
(should be OK).
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/1] mtd: st fsmc_nand: pass the ale and cmd resource via resource
From: Linus Walleij @ 2012-10-05 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349356456-13371-1-git-send-email-plagnioj@jcrosoft.com>
On Thu, Oct 4, 2012 at 3:14 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> Do not use the platform_data to pass resource and be smart in the drivers.
> Just pass it via resource
>
> Switch to devm_request_and_ioremap at the sametime
>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Vipin Kumar <vipin.kumar@st.com>
> Cc: linux-mtd at lists.infradead.org
This is much better. Actually I was confused by these offsets recently...
Acked-by: Linus Walleij <linus.walleij@linaro.org>
My patch to convert the Nomadik to the FSMC driver will collide with this,
but I can sure fix it up as we run into it, no big deal.
Yours,
Linus Walleij
^ permalink raw reply
* OMAP4 clock/pm fixes [was: [PATCH v4 2/3] ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage
From: Rajendra Nayak @ 2012-10-05 12:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506ED29E.7070403@ti.com>
On Friday 05 October 2012 05:59 PM, Archit Taneja wrote:
> The other not so good option to make DSS PM work would be to add
> OCPIF_SWSUP_IDLE flag to our l3_main_2__dss_* slave interfaces(which
> have the hack "dss_fck" as slave clock). I gave this approach a try,
> that too isn't working so well. When I disable DSS, I get
> CM_DSS_DSS_CLKCTRL.IDLEST as 0x1, and
> CM_DSS_CLKSTCTRL.CLKACTIVITY_DSS_L3_ICLK is set. I wonder why that's
> happening.
I have seen DSS get stuck in transition, with just a clkdm state toggle
(from say HWSUP to SWWKUP) while its optional clocks are not running.
Thats probably whats happening now.
Did you try keeping the modulemode enabled and see if it really gates
DSS/system sleep. I remember testing with Teros CORE ret/off patches
and I was always seeing DSS modulemode enabled but it wasn't gating
sleep.
^ permalink raw reply
* OMAP4 clock/pm fixes [was: [PATCH v4 2/3] ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage
From: Archit Taneja @ 2012-10-05 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506ED079.70700@ti.com>
On Friday 05 October 2012 05:50 PM, Benoit Cousson wrote:
> Hi Archit,
>
> On 10/05/2012 11:46 AM, Archit Taneja wrote:
>> Hi,
>>
>> On Friday 31 August 2012 01:58 PM, Archit Taneja wrote:
>>> On Friday 31 August 2012 01:57 PM, Tomi Valkeinen wrote:
>>>> On Fri, 2012-08-31 at 13:50 +0530, Archit Taneja wrote:
>>>>> On Friday 31 August 2012 12:45 PM, Tomi Valkeinen wrote:
>>>>>> On Fri, 2012-08-31 at 11:53 +0530, Archit Taneja wrote:
>>>>>>
>>>>>>> The only little problem was that during bootup, when hwmods are
>>>>>>> setup,
>>>>>>> only the 'parent' hwmod was able to get reset properly, all the other
>>>>>>> 'child' hwmods don't have modulemode bits tied to them, and hence
>>>>>>> weren't able to reset. So we got some error prints.
>>>>>>>
>>>>>>> Once DSS driver kicks in, the driver ensures the parent is enabled
>>>>>>> for
>>>>>>> any child to be enabled, so we don't face the issue again.
>>>>>>>
>>>>>>> So, if DSS driver is not built in, and if the bootloader left DSS
>>>>>>> in a
>>>>>>> bad state, the DSS clocks might remain messed up all the time since
>>>>>>> hwmod fwk wasn't able to reset them.
>>>>>>>
>>>>>>> I think this is why we didn't proceed with remove "dss_fck" as a
>>>>>>> slave
>>>>>>> clock. If this issue is minor, we could go ahead and remove it.
>>>>>>
>>>>>> I wonder if we could handle this with a custom reset function. We
>>>>>> already have a reset func for dss core. If I remember right, the main
>>>>>> point for that is the fact that omap 4 doesn't have a softreset for dss
>>>>>> core, so we manually write the default values to registers.
>>>>>>
>>>>>> For omap2/3 this would be simple: skip the resets for all other dss
>>>>>> submodules, and dss core's reset would enable all the clocks and set
>>>>>> the
>>>>>> softreset bit. This would reset all the submodules also.
>>>>>>
>>>>>> Omap4 is more tricky. I guess we'd need to enable all the clocks,
>>>>>> clear
>>>>>> manually dss core's registers, and then set softreset bits in all the
>>>>>> submodules. So in this case dss core would need to have information
>>>>>> about the other submodules.
>>>>>
>>>>> The is a good idea. I don't clearly understand your approach though.
>>>>> Are
>>>>> you saying we have a custom reset function for only dss core? And reset
>>>>> the submodules in it manually?
>>>>
>>>> Yes.
>>>>
>>>>> An alternative approach would be to implement custom reset functions
>>>>> for
>>>>> each submodule(or each hwmod), and in the beginning of every reset
>>>>> function, add a hack to enable MODULEMODE bits(since we don't want
>>>>> hwmod
>>>>> fwk to touch MODULEMODE for the DSS submodules), and then set the soft
>>>>> reset bits.
>>>>
>>>> I thought about that also. We'd need reset functions for all of them,
>>>> and for omap2/3 we'd just reset the submodules again as they have
>>>> already been reset with the dss core reset.
>>>>
>>>> The dss submodule resets are a bit linked. For omap2/3 the connection is
>>>> obvious as dss core reset resets also the submodules, and for omap4 we
>>>> have this requirement for the modulemode. That's why I though it'd be
>>>> perhaps cleaner to handle the reset of the DSS block as a whole, in one
>>>> place.
>>>>
>>>>> Your approach would ensure that we get a clean reset of DSS, but it
>>>>> would still give the annoying prints when each of the submodule
>>>>> tries to
>>>>> reset itself.
>>>>
>>>> The other submodules would not be reset by the hwmod framework at all,
>>>> so there wouldn't be prints. I think there's a flag for that.
>>
>> Sorry for bringing up an old thread. I was working on cleaning up the
>> OMAP4 DSS related clock/pm issues, hence brought it up.
>>
>> We were discussing here on how to setting up and reset the OMAP4 DSS
>> submodules correctly without tying the MODULEMODE bits to the
>> corresponding hwmods.
>>
>> Tomi, your suggestion was to do soft resets for the submodules manually
>> in the dss_core hwmod's custom reset function itself, and use the flag
>> HWMOD_INIT_NO_RESET to prevent _reset() being called.
>
> Yep, that's the right approach.
>
>> However, this won't still resolve the issue of the errors we see a
>> bootup. The function _setup_reset() looks like this:
>>
>> static int _setup_reset(struct omap_hwmod *oh)
>> {
>> ...
>> r = _enable(oh);
>> if (r) {
>> pr_warning("omap_hwmod: %s: cannot be enabled for
>> reset (%d)\n", oh->name, oh->_state);
>> return -EINVAL;
>> }
>> ...
>>
>> if (!(oh->flags & HWMOD_INIT_NO_RESET))
>> r = _reset(oh);
>>
>> ...
>> }
>>
>> So, even if we have ask hwmod not to reset the DSS submodules, it will
>> still try to enable them, and we can't enable them since MODULEMODE
>> isn't tied to them. I don't see how we can get a clean reset done for
>> the DSS submodules without making some changes in hwmod framework.
>
> Yeah, I do agree. Some module cannot but enabled automatically in the fmwk due to PM dependency.
> This is the case as well for MCPDM, IPU, DSP, ISS, FDIF...
>
> In that case the early setup should just be skipped and the DSS driver should take care of that during probe / pm_runtime_enable.
>
> I already have a WIP series that delay the setup until the driver probe the device. It will allow the setup to work properly in the case of the DSS assuming the DISPC and other sub IPs are setup in the context of DSS probe. At that time the DSS will be enabled already and thus every sub IPs will be able to get enabled.
>
> It is done in the context of DT boot, but should work as well for legacy boot.
> I can share the current crappy patches as soon as I fixed a couple of regression introduced by the patches :-(
Ah, that will be great!
The other not so good option to make DSS PM work would be to add
OCPIF_SWSUP_IDLE flag to our l3_main_2__dss_* slave interfaces(which
have the hack "dss_fck" as slave clock). I gave this approach a try,
that too isn't working so well. When I disable DSS, I get
CM_DSS_DSS_CLKCTRL.IDLEST as 0x1, and
CM_DSS_CLKSTCTRL.CLKACTIVITY_DSS_L3_ICLK is set. I wonder why that's
happening.
Thanks,
Archit
^ permalink raw reply
* alignment faults in 3.6
From: Rob Herring @ 2012-10-05 12:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121005082439.GF4625@n2100.arm.linux.org.uk>
On 10/05/2012 03:24 AM, Russell King - ARM Linux wrote:
> On Fri, Oct 05, 2012 at 09:20:56AM +0100, Mans Rullgard wrote:
>> On 5 October 2012 08:12, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>> On Fri, Oct 05, 2012 at 03:25:16AM +0100, Mans Rullgard wrote:
>>>> On 5 October 2012 02:56, Rob Herring <robherring2@gmail.com> wrote:
>>>>> This struct is the IP header, so a struct ptr is just set to the
>>>>> beginning of the received data. Since ethernet headers are 14 bytes,
>>>>> often the IP header is not aligned unless the NIC can place the frame at
>>>>> a 2 byte offset (which is something I need to investigate). So this
>>>>> function cannot make any assumptions about the alignment. Does the ABI
>>>>> define structs have some minimum alignment? Does the struct need to be
>>>>> declared as packed or something?
>>>>
>>>> The ABI defines the alignment of structs as the maximum alignment of its
>>>> members. Since this struct contains 32-bit members, the alignment for the
>>>> whole struct becomes 32 bits as well. Declaring it as packed tells gcc it
>>>> might be unaligned (in addition to removing any holes within).
>>>
>>> This has come up before in the past.
>>>
>>> The Linux network folk will _not_ allow - in any shape or form - for
>>> this struct to be marked packed (it's the struct which needs to be
>>> marked packed) because by doing so, it causes GCC to issue byte loads/
>>> stores on architectures where there isn't a problem, and that decreases
>>> the performance of the Linux IP stack unnecessarily.
>>
>> Which architectures? I have never seen anything like that.
>
> Does it matter? I'm just relaying the argument against adding __packed
> which was used before we were forced (by the networking folk) to implement
> the alignment fault handler.
It doesn't really matter what will be accepted or not as adding __packed
to struct iphdr doesn't fix the problem anyway. gcc still emits a ldm.
The only way I've found to eliminate the alignment fault is adding a
barrier between the 2 loads. That seems like a compiler issue to me if
there is not a better fix.
Rob
^ permalink raw reply
* [PATCH V2 0/3] spi: spi-pl022: Fixup use of runtime pm
From: Mark Brown @ 2012-10-05 12:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbYzr4HH1tFjnZT0A=v_iOGVbkey_vxyAUW+85nw2bEZA@mail.gmail.com>
On Fri, Oct 05, 2012 at 02:21:15PM +0200, Linus Walleij wrote:
> I think patch 1/3 and 2/3 needs to go into the -rc fixes.
> Who's funneling this now? Grant or Mark?
Me still for the moment.
^ permalink raw reply
* [PATCH V2 1/3] Revert "spi/pl022: fix spi-pl022 pm enable at probe"
From: Mark Brown @ 2012-10-05 12:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349337881-15917-2-git-send-email-ulf.hansson@stericsson.com>
On Thu, Oct 04, 2012 at 10:04:39AM +0200, Ulf Hansson wrote:
> From: Ulf Hansson <ulf.hansson@linaro.org>
>
> This reverts commit 6887237cd7da904184dab2750504040c68f3a080.
>
> This reverts is done due to earlier wrong commit, which is
> also reverted. "Revert "spi/pl022: enable runtime PM""
Why? "Wrong" isn't terribly detailed...
^ permalink raw reply
* [PATCH V2 0/3] spi: spi-pl022: Fixup use of runtime pm
From: Linus Walleij @ 2012-10-05 12:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349337881-15917-1-git-send-email-ulf.hansson@stericsson.com>
On Thu, Oct 4, 2012 at 10:04 AM, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
> From: Ulf Hansson <ulf.hansson@linaro.org>
>
> Some old runtime pm patches got merged whiched messed up things.
> These are now reverted. Additionaly one patch do a simplification
> of the use of runtime pm functions.
>
> V2:
> Rebased patches and updated commit messages.
>
> Ulf Hansson (3):
> Revert "spi/pl022: fix spi-pl022 pm enable at probe"
> Revert "spi/pl022: enable runtime PM"
> spi: spi-pl022: Minor simplification for runtime pm
I think patch 1/3 and 2/3 needs to go into the -rc fixes.
Who's funneling this now? Grant or Mark?
Yours,
Linus Walleij
^ permalink raw reply
* OMAP4 clock/pm fixes [was: [PATCH v4 2/3] ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage
From: Benoit Cousson @ 2012-10-05 12:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506EAC89.2070307@ti.com>
Hi Archit,
On 10/05/2012 11:46 AM, Archit Taneja wrote:
> Hi,
>
> On Friday 31 August 2012 01:58 PM, Archit Taneja wrote:
>> On Friday 31 August 2012 01:57 PM, Tomi Valkeinen wrote:
>>> On Fri, 2012-08-31 at 13:50 +0530, Archit Taneja wrote:
>>>> On Friday 31 August 2012 12:45 PM, Tomi Valkeinen wrote:
>>>>> On Fri, 2012-08-31 at 11:53 +0530, Archit Taneja wrote:
>>>>>
>>>>>> The only little problem was that during bootup, when hwmods are
>>>>>> setup,
>>>>>> only the 'parent' hwmod was able to get reset properly, all the other
>>>>>> 'child' hwmods don't have modulemode bits tied to them, and hence
>>>>>> weren't able to reset. So we got some error prints.
>>>>>>
>>>>>> Once DSS driver kicks in, the driver ensures the parent is enabled
>>>>>> for
>>>>>> any child to be enabled, so we don't face the issue again.
>>>>>>
>>>>>> So, if DSS driver is not built in, and if the bootloader left DSS
>>>>>> in a
>>>>>> bad state, the DSS clocks might remain messed up all the time since
>>>>>> hwmod fwk wasn't able to reset them.
>>>>>>
>>>>>> I think this is why we didn't proceed with remove "dss_fck" as a
>>>>>> slave
>>>>>> clock. If this issue is minor, we could go ahead and remove it.
>>>>>
>>>>> I wonder if we could handle this with a custom reset function. We
>>>>> already have a reset func for dss core. If I remember right, the main
>>>>> point for that is the fact that omap 4 doesn't have a softreset for dss
>>>>> core, so we manually write the default values to registers.
>>>>>
>>>>> For omap2/3 this would be simple: skip the resets for all other dss
>>>>> submodules, and dss core's reset would enable all the clocks and set
>>>>> the
>>>>> softreset bit. This would reset all the submodules also.
>>>>>
>>>>> Omap4 is more tricky. I guess we'd need to enable all the clocks,
>>>>> clear
>>>>> manually dss core's registers, and then set softreset bits in all the
>>>>> submodules. So in this case dss core would need to have information
>>>>> about the other submodules.
>>>>
>>>> The is a good idea. I don't clearly understand your approach though.
>>>> Are
>>>> you saying we have a custom reset function for only dss core? And reset
>>>> the submodules in it manually?
>>>
>>> Yes.
>>>
>>>> An alternative approach would be to implement custom reset functions
>>>> for
>>>> each submodule(or each hwmod), and in the beginning of every reset
>>>> function, add a hack to enable MODULEMODE bits(since we don't want
>>>> hwmod
>>>> fwk to touch MODULEMODE for the DSS submodules), and then set the soft
>>>> reset bits.
>>>
>>> I thought about that also. We'd need reset functions for all of them,
>>> and for omap2/3 we'd just reset the submodules again as they have
>>> already been reset with the dss core reset.
>>>
>>> The dss submodule resets are a bit linked. For omap2/3 the connection is
>>> obvious as dss core reset resets also the submodules, and for omap4 we
>>> have this requirement for the modulemode. That's why I though it'd be
>>> perhaps cleaner to handle the reset of the DSS block as a whole, in one
>>> place.
>>>
>>>> Your approach would ensure that we get a clean reset of DSS, but it
>>>> would still give the annoying prints when each of the submodule
>>>> tries to
>>>> reset itself.
>>>
>>> The other submodules would not be reset by the hwmod framework at all,
>>> so there wouldn't be prints. I think there's a flag for that.
>
> Sorry for bringing up an old thread. I was working on cleaning up the
> OMAP4 DSS related clock/pm issues, hence brought it up.
>
> We were discussing here on how to setting up and reset the OMAP4 DSS
> submodules correctly without tying the MODULEMODE bits to the
> corresponding hwmods.
>
> Tomi, your suggestion was to do soft resets for the submodules manually
> in the dss_core hwmod's custom reset function itself, and use the flag
> HWMOD_INIT_NO_RESET to prevent _reset() being called.
Yep, that's the right approach.
> However, this won't still resolve the issue of the errors we see a
> bootup. The function _setup_reset() looks like this:
>
> static int _setup_reset(struct omap_hwmod *oh)
> {
> ...
> r = _enable(oh);
> if (r) {
> pr_warning("omap_hwmod: %s: cannot be enabled for
> reset (%d)\n", oh->name, oh->_state);
> return -EINVAL;
> }
> ...
>
> if (!(oh->flags & HWMOD_INIT_NO_RESET))
> r = _reset(oh);
>
> ...
> }
>
> So, even if we have ask hwmod not to reset the DSS submodules, it will
> still try to enable them, and we can't enable them since MODULEMODE
> isn't tied to them. I don't see how we can get a clean reset done for
> the DSS submodules without making some changes in hwmod framework.
Yeah, I do agree. Some module cannot but enabled automatically in the fmwk due to PM dependency.
This is the case as well for MCPDM, IPU, DSP, ISS, FDIF...
In that case the early setup should just be skipped and the DSS driver should take care of that during probe / pm_runtime_enable.
I already have a WIP series that delay the setup until the driver probe the device. It will allow the setup to work properly in the case of the DSS assuming the DISPC and other sub IPs are setup in the context of DSS probe. At that time the DSS will be enabled already and thus every sub IPs will be able to get enabled.
It is done in the context of DT boot, but should work as well for legacy boot.
I can share the current crappy patches as soon as I fixed a couple of regression introduced by the patches :-(
Regards,
Benoit
^ permalink raw reply
* [PATCH V2 3/3] spi: spi-pl022: Minor simplification for runtime pm
From: Linus Walleij @ 2012-10-05 12:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFqZXKtpJ8vSFKfZuD8FGayQUhmYKtZKzkZ15jKRA5nu6Q@mail.gmail.com>
On Thu, Oct 4, 2012 at 11:07 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> Mark, I am not sure this particular patch is actually wanted. Realized
> that when reading up on the driver/base/* patches for PM changes this
> summer. Especially how device probe/suspend/shutdown etc. has been
> changed for runtime PM point of view.
Mark will get you for top-posting ;-)
>> From: Ulf Hansson <ulf.hansson@linaro.org>
>>
>> In probe pm_runtime_put_autosuspend has the same effect as doing
>> pm_runtime_put. This due to upper layer in driver core is preventing
>> the device from being runtime suspended by a pm_runtime_get*.
>>
>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>> ---
>> drivers/spi/spi-pl022.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
>> index a1db91a..51b7a95 100644
>> --- a/drivers/spi/spi-pl022.c
>> +++ b/drivers/spi/spi-pl022.c
>> @@ -2246,10 +2246,9 @@ pl022_probe(struct amba_device *adev, const struct amba_id *id)
>> pm_runtime_set_autosuspend_delay(dev,
>> platform_info->autosuspend_delay);
>> pm_runtime_use_autosuspend(dev);
>> - pm_runtime_put_autosuspend(dev);
>> - } else {
>> - pm_runtime_put(dev);
>> }
>> + pm_runtime_put(dev);
>> +
>> return 0;
I'm paging Rafael and Magnus for their comments so we don't
overload Mark with runtime PM semantics...
Yours,
Linus Walleij
^ permalink raw reply
* [RFC PATCH v3 1/4] watchdog: core: dt: add support for the timeout-sec dt property
From: Fabio Porcedda @ 2012-10-05 12:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121005111642.GA12462@game.jcrosoft.org>
On Fri, Oct 5, 2012 at 1:16 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> On 12:16 Fri 05 Oct , Fabio Porcedda wrote:
>> Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
>> ---
>> Documentation/watchdog/watchdog-kernel-api.txt | 4 ++++
>> drivers/watchdog/watchdog_core.c | 27 ++++++++++++++++++++++++++
>> include/linux/watchdog.h | 4 ++++
>> 3 files changed, 35 insertions(+)
>>
>> diff --git a/Documentation/watchdog/watchdog-kernel-api.txt b/Documentation/watchdog/watchdog-kernel-api.txt
>> index 086638f..2208db7 100644
>> --- a/Documentation/watchdog/watchdog-kernel-api.txt
>> +++ b/Documentation/watchdog/watchdog-kernel-api.txt
>> @@ -212,3 +212,7 @@ driver specific data to and a pointer to the data itself.
>> The watchdog_get_drvdata function allows you to retrieve driver specific data.
>> The argument of this function is the watchdog device where you want to retrieve
>> data from. The function returns the pointer to the driver specific data.
>> +
>> +The watchdog_init_timeout function allows you to initialize the timeout field
>> +using the module timeout parameter or retrieving the timeout-sec property from
>> +the device tree.
>> diff --git a/drivers/watchdog/watchdog_core.c b/drivers/watchdog/watchdog_core.c
>> index 3796434..646be48 100644
>> --- a/drivers/watchdog/watchdog_core.c
>> +++ b/drivers/watchdog/watchdog_core.c
>> @@ -143,6 +143,33 @@ void watchdog_unregister_device(struct watchdog_device *wdd)
>> }
>> EXPORT_SYMBOL_GPL(watchdog_unregister_device);
>>
>> +/**
>> + * watchdog_init_timeout() - initialize the timeout field
>> + * @parm_timeout: timeout module parameter, it takes precedence over the
>> + * timeout-sec property.
>> + * @node: Retrieve the timeout-sec property only if the parm_timeout
>> + * is out of bounds.
>> + */
>> +void watchdog_init_timeout(struct watchdog_device *wdd,
>> + unsigned int parm_timeout, struct device_node *node)
>> +{
>> + unsigned int t = 0;
>> +
>> + if ((parm_timeout >= wdd->min_timeout) &&
>> + (parm_timeout <= wdd->max_timeout)) {
>> + wdd->timeout = parm_timeout;
>> + return;
>> + }
>> +
>> + if (!node)
>> + return;
>> +
>> + of_property_read_u32(node, "timeout-sec", &t);
> why I bother to comment
> *make this of generic* this is not watchdog specific other driver can use it
You mean to add the function in of.h and use that function inside
watchdog_init_timeout or to
use the of_* function instead of the watchdog_init_timeout function?
Do you like the use of watchdog_init_timeout function inside the
at91sam9_wdt driver?
Best regards
--
Fabio Porcedda
^ permalink raw reply
* [RFC PATCH v3 1/4] watchdog: core: dt: add support for the timeout-sec dt property
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-05 11:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349432169-13006-2-git-send-email-fabio.porcedda@gmail.com>
On 12:16 Fri 05 Oct , Fabio Porcedda wrote:
> Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
> ---
> Documentation/watchdog/watchdog-kernel-api.txt | 4 ++++
> drivers/watchdog/watchdog_core.c | 27 ++++++++++++++++++++++++++
> include/linux/watchdog.h | 4 ++++
> 3 files changed, 35 insertions(+)
>
> diff --git a/Documentation/watchdog/watchdog-kernel-api.txt b/Documentation/watchdog/watchdog-kernel-api.txt
> index 086638f..2208db7 100644
> --- a/Documentation/watchdog/watchdog-kernel-api.txt
> +++ b/Documentation/watchdog/watchdog-kernel-api.txt
> @@ -212,3 +212,7 @@ driver specific data to and a pointer to the data itself.
> The watchdog_get_drvdata function allows you to retrieve driver specific data.
> The argument of this function is the watchdog device where you want to retrieve
> data from. The function returns the pointer to the driver specific data.
> +
> +The watchdog_init_timeout function allows you to initialize the timeout field
> +using the module timeout parameter or retrieving the timeout-sec property from
> +the device tree.
> diff --git a/drivers/watchdog/watchdog_core.c b/drivers/watchdog/watchdog_core.c
> index 3796434..646be48 100644
> --- a/drivers/watchdog/watchdog_core.c
> +++ b/drivers/watchdog/watchdog_core.c
> @@ -143,6 +143,33 @@ void watchdog_unregister_device(struct watchdog_device *wdd)
> }
> EXPORT_SYMBOL_GPL(watchdog_unregister_device);
>
> +/**
> + * watchdog_init_timeout() - initialize the timeout field
> + * @parm_timeout: timeout module parameter, it takes precedence over the
> + * timeout-sec property.
> + * @node: Retrieve the timeout-sec property only if the parm_timeout
> + * is out of bounds.
> + */
> +void watchdog_init_timeout(struct watchdog_device *wdd,
> + unsigned int parm_timeout, struct device_node *node)
> +{
> + unsigned int t = 0;
> +
> + if ((parm_timeout >= wdd->min_timeout) &&
> + (parm_timeout <= wdd->max_timeout)) {
> + wdd->timeout = parm_timeout;
> + return;
> + }
> +
> + if (!node)
> + return;
> +
> + of_property_read_u32(node, "timeout-sec", &t);
why I bother to comment
*make this of generic* this is not watchdog specific other driver can use it
Best Regards,
J.
^ permalink raw reply
* alignment faults in 3.6
From: Russell King - ARM Linux @ 2012-10-05 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121005072914.GE4625@n2100.arm.linux.org.uk>
On Fri, Oct 05, 2012 at 08:29:14AM +0100, Russell King - ARM Linux wrote:
> On Thu, Oct 04, 2012 at 06:10:26PM -0500, Rob Herring wrote:
> > I would think the scheduling while atomic messages are harmless in this
> > case. However, in addition to spewing out BUG messages this commit also
> > seems to eventually cause a kernel panic in __napi_complete. That panic
> > seems to go away if I put barrier() between the 2 accesses above which
> > eliminates the alignment faults. I haven't figured that part out yet.
> >
> > There's at least a couple of problems here:
> >
> > This seems like an overly aggressive compiler optimization considering
> > unaligned accesses are not supported by ldm/stm.
> >
> > The alignment fault handler should handle kernel address faults atomically.
>
> This is bad news. do_alignment() can be called in almost any kernel
> context, and it must work. die() and oops dumps - specifically dump_mem()
> and dump_instr() will suffer from exactly the same problem.
Okay, this should fix the issue... I've only compile tested it so far.
Rob, as you have a way to trigger this easily, can you give this patch
a go and let me know if it solves your problem? Thanks.
arch/arm/kernel/traps.c | 34 +++++++---------------------------
arch/arm/mm/alignment.c | 11 ++++-------
2 files changed, 11 insertions(+), 34 deletions(-)
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index b0179b8..62f429e 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -89,17 +89,8 @@ static void dump_mem(const char *lvl, const char *str, unsigned long bottom,
unsigned long top)
{
unsigned long first;
- mm_segment_t fs;
int i;
- /*
- * We need to switch to kernel mode so that we can use __get_user
- * to safely read from kernel space. Note that we now dump the
- * code first, just in case the backtrace kills us.
- */
- fs = get_fs();
- set_fs(KERNEL_DS);
-
printk("%s%s(0x%08lx to 0x%08lx)\n", lvl, str, bottom, top);
for (first = bottom & ~31; first < top; first += 32) {
@@ -112,7 +103,7 @@ static void dump_mem(const char *lvl, const char *str, unsigned long bottom,
for (p = first, i = 0; i < 8 && p < top; i++, p += 4) {
if (p >= bottom && p < top) {
unsigned long val;
- if (__get_user(val, (unsigned long *)p) == 0)
+ if (probe_kernel_address(p, val) == 0)
sprintf(str + i * 9, " %08lx", val);
else
sprintf(str + i * 9, " ????????");
@@ -120,8 +111,6 @@ static void dump_mem(const char *lvl, const char *str, unsigned long bottom,
}
printk("%s%04lx:%s\n", lvl, first & 0xffff, str);
}
-
- set_fs(fs);
}
static void dump_instr(const char *lvl, struct pt_regs *regs)
@@ -129,25 +118,18 @@ static void dump_instr(const char *lvl, struct pt_regs *regs)
unsigned long addr = instruction_pointer(regs);
const int thumb = thumb_mode(regs);
const int width = thumb ? 4 : 8;
- mm_segment_t fs;
char str[sizeof("00000000 ") * 5 + 2 + 1], *p = str;
int i;
- /*
- * We need to switch to kernel mode so that we can use __get_user
- * to safely read from kernel space. Note that we now dump the
- * code first, just in case the backtrace kills us.
- */
- fs = get_fs();
- set_fs(KERNEL_DS);
-
for (i = -4; i < 1 + !!thumb; i++) {
unsigned int val, bad;
- if (thumb)
- bad = __get_user(val, &((u16 *)addr)[i]);
- else
- bad = __get_user(val, &((u32 *)addr)[i]);
+ if (thumb) {
+ u16 instr;
+ bad = probe_kernel_address(addr, instr);
+ val = instr;
+ } else
+ bad = probe_kernel_address(addr, val);
if (!bad)
p += sprintf(p, i == 0 ? "(%0*x) " : "%0*x ",
@@ -158,8 +140,6 @@ static void dump_instr(const char *lvl, struct pt_regs *regs)
}
}
printk("%sCode: %s\n", lvl, str);
-
- set_fs(fs);
}
#ifdef CONFIG_ARM_UNWIND
diff --git a/arch/arm/mm/alignment.c b/arch/arm/mm/alignment.c
index b9f60eb..f8f14fc 100644
--- a/arch/arm/mm/alignment.c
+++ b/arch/arm/mm/alignment.c
@@ -749,7 +749,6 @@ do_alignment(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
unsigned long instr = 0, instrptr;
int (*handler)(unsigned long addr, unsigned long instr, struct pt_regs *regs);
unsigned int type;
- mm_segment_t fs;
unsigned int fault;
u16 tinstr = 0;
int isize = 4;
@@ -760,16 +759,15 @@ do_alignment(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
instrptr = instruction_pointer(regs);
- fs = get_fs();
- set_fs(KERNEL_DS);
if (thumb_mode(regs)) {
- fault = __get_user(tinstr, (u16 *)(instrptr & ~1));
+ unsigned long ptr = instrptr;
+ fault = probe_kernel_address(ptr, tinstr);
if (!fault) {
if (cpu_architecture() >= CPU_ARCH_ARMv7 &&
IS_T32(tinstr)) {
/* Thumb-2 32-bit */
u16 tinst2 = 0;
- fault = __get_user(tinst2, (u16 *)(instrptr+2));
+ fault = probe_kernel_address(ptr + 2, tinst2);
instr = (tinstr << 16) | tinst2;
thumb2_32b = 1;
} else {
@@ -778,8 +776,7 @@ do_alignment(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
}
}
} else
- fault = __get_user(instr, (u32 *)instrptr);
- set_fs(fs);
+ fault = probe_kernel_address(instrptr, instr);
if (fault) {
type = TYPE_FAULT;
^ permalink raw reply related
* [PATCH v3 5/6] ARM: davinci: Add support for PRUSS on DA850
From: Sekhar Nori @ 2012-10-05 10:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121004163546.GK11149@beef>
On 10/4/2012 10:05 PM, Matt Porter wrote:
> On Thu, Oct 04, 2012 at 05:52:45PM +0530, Sekhar Nori wrote:
>> On 10/3/2012 8:25 PM, Matt Porter wrote:
>>> +static struct clk pruss_clk = {
>>> + .name = "pruss",
>>> + .parent = &pll0_sysclk2,
>>> + .lpsc = DA8XX_LPSC0_PRUSS,
>>> +};
>>> +
>>> static struct clk uart0_clk = {
>>> .name = "uart0",
>>> .parent = &pll0_sysclk2,
>>> @@ -378,6 +384,7 @@ static struct clk_lookup da850_clks[] = {
>>> CLK(NULL, "tptc1", &tptc1_clk),
>>> CLK(NULL, "tpcc1", &tpcc1_clk),
>>> CLK(NULL, "tptc2", &tptc2_clk),
>>> + CLK(NULL, "pruss", &pruss_clk),
>>
>> This is actually incorrect since we should use device name rather than
>> con_id for matching the clock. If there is just one clock that the
>> driver needs, connection id should be NULL. Looking at the driver now,
>> the clk_get() call seems to pass a valid device pointer. So, I wonder
>> how you are able to look up the clock even with a NULL device name.
>
> I doublechecked the clk_get() find implentation to confirm that I indeed
> did get lucky here. Since pruss has only one instance and the clk_find()
> implementation looks for the best found match, it's able to find the
> clock just by the con_id, though it's not the "best possible" match in
> the find implementation...it's the "best found" match.. As you noted,
> this is incorrect though for a clock expected to be used from a driver
> context so I will address this in the update.
Thanks for debugging and clarifying.
Regards,
Sekhar
^ permalink raw reply
* [PATCH] ARM: picoxcell: remove unnecessary header common.h
From: Tobias Klauser @ 2012-10-05 10:17 UTC (permalink / raw)
To: linux-arm-kernel
Since commit 66314223 ("ARM: socfpga: initial support for Altera's
SOCFPGA platform") struct sys_timer dw_apb_timer is an extern in
<linux/dw_apb_timer.h>, so there is no need for common.h anymore,
instead directly #include <asm/mach/time.h> in common.c
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
arch/arm/mach-picoxcell/common.c | 3 +--
arch/arm/mach-picoxcell/common.h | 17 -----------------
2 files changed, 1 insertions(+), 19 deletions(-)
delete mode 100644 arch/arm/mach-picoxcell/common.h
diff --git a/arch/arm/mach-picoxcell/common.c b/arch/arm/mach-picoxcell/common.c
index f6c0849..bc36f12 100644
--- a/arch/arm/mach-picoxcell/common.c
+++ b/arch/arm/mach-picoxcell/common.c
@@ -19,8 +19,7 @@
#include <asm/mach/arch.h>
#include <asm/hardware/vic.h>
#include <asm/mach/map.h>
-
-#include "common.h"
+#include <asm/mach/time.h>
#define PHYS_TO_IO(x) (((x) & 0x00ffffff) | 0xfe000000)
#define PICOXCELL_PERIPH_BASE 0x80000000
diff --git a/arch/arm/mach-picoxcell/common.h b/arch/arm/mach-picoxcell/common.h
deleted file mode 100644
index a65cb02..0000000
--- a/arch/arm/mach-picoxcell/common.h
+++ /dev/null
@@ -1,17 +0,0 @@
-/*
- * Copyright (c) 2011 Picochip Ltd., Jamie Iles
- *
- * 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.
- *
- * All enquiries to support at picochip.com
- */
-#ifndef __PICOXCELL_COMMON_H__
-#define __PICOXCELL_COMMON_H__
-
-#include <asm/mach/time.h>
-
-extern struct sys_timer dw_apb_timer;
-
-#endif /* __PICOXCELL_COMMON_H__ */
--
1.7.5.4
^ permalink raw reply related
* [RFC PATCH v3 4/4] watchdog: WatchDog Timer Driver Core: fix comment
From: Fabio Porcedda @ 2012-10-05 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349432169-13006-1-git-send-email-fabio.porcedda@gmail.com>
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
---
include/linux/watchdog.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/watchdog.h b/include/linux/watchdog.h
index d09dda7..9e6a8f2 100644
--- a/include/linux/watchdog.h
+++ b/include/linux/watchdog.h
@@ -175,7 +175,7 @@ static inline void *watchdog_get_drvdata(struct watchdog_device *wdd)
return wdd->driver_data;
}
-/* drivers/watchdog/core/watchdog_core.c */
+/* drivers/watchdog/watchdog_core.c */
extern int watchdog_register_device(struct watchdog_device *);
extern void watchdog_unregister_device(struct watchdog_device *);
extern void watchdog_init_timeout(struct watchdog_device *wdd,
--
1.7.11.3
^ permalink raw reply related
* [RFC PATCH v3 3/4] watchdog: orion_wdt: litte cleanup
From: Fabio Porcedda @ 2012-10-05 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349432169-13006-1-git-send-email-fabio.porcedda@gmail.com>
- Move the min_timeout initialization inside the orion_wdt definition.
- Change orion_wdt_of_match_table from __devinitdata to __devinitconst.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
---
drivers/watchdog/orion_wdt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
index 3417f1b..9e09598 100644
--- a/drivers/watchdog/orion_wdt.c
+++ b/drivers/watchdog/orion_wdt.c
@@ -139,6 +139,7 @@ static const struct watchdog_ops orion_wdt_ops = {
static struct watchdog_device orion_wdt = {
.info = &orion_wdt_info,
.ops = &orion_wdt_ops,
+ .min_timeout = 1,
};
static int __devinit orion_wdt_probe(struct platform_device *pdev)
@@ -161,7 +162,6 @@ static int __devinit orion_wdt_probe(struct platform_device *pdev)
wdt_max_duration = WDT_MAX_CYCLE_COUNT / wdt_tclk;
- orion_wdt.min_timeout = 1;
orion_wdt.max_timeout = wdt_max_duration;
orion_wdt.timeout = wdt_max_duration;
watchdog_init_timeout(&orion_wdt, heartbeat, pdev->dev.of_node);
@@ -190,7 +190,7 @@ static void orion_wdt_shutdown(struct platform_device *pdev)
orion_wdt_stop(&orion_wdt);
}
-static const struct of_device_id orion_wdt_of_match_table[] __devinitdata = {
+static const struct of_device_id orion_wdt_of_match_table[] __devinitconst = {
{ .compatible = "marvell,orion-wdt", },
{},
};
--
1.7.11.3
^ permalink raw reply related
* [RFC PATCH v3 2/4] watchdog: add timeout-sec property binding to some drivers
From: Fabio Porcedda @ 2012-10-05 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349432169-13006-1-git-send-email-fabio.porcedda@gmail.com>
The binding is provided by the watchdog core.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
---
.../devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++
Documentation/devicetree/bindings/watchdog/marvel.txt | 5 +++++
.../devicetree/bindings/watchdog/pnx4008-wdt.txt | 4 ++++
drivers/watchdog/Kconfig | 1 +
drivers/watchdog/at91sam9_wdt.c | 17 +++++++++++++----
drivers/watchdog/orion_wdt.c | 9 +++------
drivers/watchdog/pnx4008_wdt.c | 7 +++----
7 files changed, 33 insertions(+), 14 deletions(-)
diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
index 2957ebb..27af70d 100644
--- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
@@ -7,9 +7,13 @@ Required properties:
- reg: physical base address of the controller and length of memory mapped
region.
+Optional properties:
+- timeout-sec: Contains the watchdog timeout in seconds
+
Example:
watchdog at fffffd40 {
compatible = "atmel,at91sam9260-wdt";
reg = <0xfffffd40 0x10>;
+ timeout-sec = <10>;
};
diff --git a/Documentation/devicetree/bindings/watchdog/marvel.txt b/Documentation/devicetree/bindings/watchdog/marvel.txt
index 0b2503a..5dc8d30 100644
--- a/Documentation/devicetree/bindings/watchdog/marvel.txt
+++ b/Documentation/devicetree/bindings/watchdog/marvel.txt
@@ -5,10 +5,15 @@ Required Properties:
- Compatibility : "marvell,orion-wdt"
- reg : Address of the timer registers
+Optional properties:
+
+- timeout-sec : Contains the watchdog timeout in seconds
+
Example:
wdt at 20300 {
compatible = "marvell,orion-wdt";
reg = <0x20300 0x28>;
+ timeout-sec = <10>;
status = "okay";
};
diff --git a/Documentation/devicetree/bindings/watchdog/pnx4008-wdt.txt b/Documentation/devicetree/bindings/watchdog/pnx4008-wdt.txt
index 7c7f688..47461f5 100644
--- a/Documentation/devicetree/bindings/watchdog/pnx4008-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/pnx4008-wdt.txt
@@ -5,9 +5,13 @@ Required properties:
- reg: physical base address of the controller and length of memory mapped
region.
+Optional properties:
+- timeout-sec: Contains the watchdog timeout in seconds
+
Example:
watchdog at 4003C000 {
compatible = "nxp,pnx4008-wdt";
reg = <0x4003C000 0x1000>;
+ timeout-sec = <10>;
};
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index ad1bb93..dda695f 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -114,6 +114,7 @@ config AT91RM9200_WATCHDOG
config AT91SAM9X_WATCHDOG
tristate "AT91SAM9X / AT91CAP9 watchdog"
depends on ARCH_AT91 && !ARCH_AT91RM9200
+ select WATCHDOG_CORE
help
Watchdog timer embedded into AT91SAM9X and AT91CAP9 chips. This will
reboot your system when the timeout is reached.
diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c
index dc42e44..f901cc0 100644
--- a/drivers/watchdog/at91sam9_wdt.c
+++ b/drivers/watchdog/at91sam9_wdt.c
@@ -32,7 +32,6 @@
#include <linux/timer.h>
#include <linux/bitops.h>
#include <linux/uaccess.h>
-#include <linux/of.h>
#include "at91sam9_wdt.h"
@@ -57,8 +56,10 @@
#define WDT_TIMEOUT (HZ/2)
/* User land timeout */
+#define MIN_HEARTBEAT 1
+#define MAX_HEARTBEAT 16
#define WDT_HEARTBEAT 15
-static int heartbeat = WDT_HEARTBEAT;
+static int heartbeat = 0;
module_param(heartbeat, int, 0);
MODULE_PARM_DESC(heartbeat, "Watchdog heartbeats in seconds. "
"(default = " __MODULE_STRING(WDT_HEARTBEAT) ")");
@@ -255,6 +256,12 @@ static struct miscdevice at91wdt_miscdev = {
.fops = &at91wdt_fops,
};
+static struct watchdog_device at91wdt_wdd __initdata = {
+ .timeout = WDT_HEARTBEAT,
+ .min_timeout = MIN_HEARTBEAT,
+ .max_timeout = MAX_HEARTBEAT,
+};
+
static int __init at91wdt_probe(struct platform_device *pdev)
{
struct resource *r;
@@ -273,6 +280,8 @@ static int __init at91wdt_probe(struct platform_device *pdev)
return -ENOMEM;
}
+ watchdog_init_timeout(&at91wdt_wdd, heartbeat, pdev->dev.of_node);
+
/* Set watchdog */
res = at91_wdt_settimeout(ms_to_ticks(WDT_HW_TIMEOUT * 1000));
if (res)
@@ -282,12 +291,12 @@ static int __init at91wdt_probe(struct platform_device *pdev)
if (res)
return res;
- at91wdt_private.next_heartbeat = jiffies + heartbeat * HZ;
+ at91wdt_private.next_heartbeat = jiffies + at91wdt_wdd.timeout * HZ;
setup_timer(&at91wdt_private.timer, at91_ping, 0);
mod_timer(&at91wdt_private.timer, jiffies + WDT_TIMEOUT);
pr_info("enabled (heartbeat=%d sec, nowayout=%d)\n",
- heartbeat, nowayout);
+ at91wdt_wdd.timeout, nowayout);
return 0;
}
diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
index c20f96b..3417f1b 100644
--- a/drivers/watchdog/orion_wdt.c
+++ b/drivers/watchdog/orion_wdt.c
@@ -24,7 +24,6 @@
#include <linux/spinlock.h>
#include <linux/clk.h>
#include <linux/err.h>
-#include <linux/of.h>
#include <mach/bridge-regs.h>
/*
@@ -162,12 +161,10 @@ static int __devinit orion_wdt_probe(struct platform_device *pdev)
wdt_max_duration = WDT_MAX_CYCLE_COUNT / wdt_tclk;
- if ((heartbeat < 1) || (heartbeat > wdt_max_duration))
- heartbeat = wdt_max_duration;
-
- orion_wdt.timeout = heartbeat;
orion_wdt.min_timeout = 1;
orion_wdt.max_timeout = wdt_max_duration;
+ orion_wdt.timeout = wdt_max_duration;
+ watchdog_init_timeout(&orion_wdt, heartbeat, pdev->dev.of_node);
watchdog_set_nowayout(&orion_wdt, nowayout);
ret = watchdog_register_device(&orion_wdt);
@@ -177,7 +174,7 @@ static int __devinit orion_wdt_probe(struct platform_device *pdev)
}
pr_info("Initial timeout %d sec%s\n",
- heartbeat, nowayout ? ", nowayout" : "");
+ orion_wdt.timeout, nowayout ? ", nowayout" : "");
return 0;
}
diff --git a/drivers/watchdog/pnx4008_wdt.c b/drivers/watchdog/pnx4008_wdt.c
index 87722e1..152e9fb 100644
--- a/drivers/watchdog/pnx4008_wdt.c
+++ b/drivers/watchdog/pnx4008_wdt.c
@@ -142,6 +142,7 @@ static const struct watchdog_ops pnx4008_wdt_ops = {
static struct watchdog_device pnx4008_wdd = {
.info = &pnx4008_wdt_ident,
.ops = &pnx4008_wdt_ops,
+ .timeout = DEFAULT_HEARTBEAT,
.min_timeout = 1,
.max_timeout = MAX_HEARTBEAT,
};
@@ -151,8 +152,7 @@ static int __devinit pnx4008_wdt_probe(struct platform_device *pdev)
struct resource *r;
int ret = 0;
- if (heartbeat < 1 || heartbeat > MAX_HEARTBEAT)
- heartbeat = DEFAULT_HEARTBEAT;
+ watchdog_init_timeout(&pnx4008_wdd, heartbeat, pdev->dev.of_node);
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
wdt_base = devm_request_and_ioremap(&pdev->dev, r);
@@ -167,7 +167,6 @@ static int __devinit pnx4008_wdt_probe(struct platform_device *pdev)
if (ret)
goto out;
- pnx4008_wdd.timeout = heartbeat;
pnx4008_wdd.bootstatus = (readl(WDTIM_RES(wdt_base)) & WDOG_RESET) ?
WDIOF_CARDRESET : 0;
watchdog_set_nowayout(&pnx4008_wdd, nowayout);
@@ -181,7 +180,7 @@ static int __devinit pnx4008_wdt_probe(struct platform_device *pdev)
}
dev_info(&pdev->dev, "PNX4008 Watchdog Timer: heartbeat %d sec\n",
- heartbeat);
+ pnx4008_wdd.timeout);
return 0;
--
1.7.11.3
^ permalink raw reply related
* [RFC PATCH v3 1/4] watchdog: core: dt: add support for the timeout-sec dt property
From: Fabio Porcedda @ 2012-10-05 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349432169-13006-1-git-send-email-fabio.porcedda@gmail.com>
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
---
Documentation/watchdog/watchdog-kernel-api.txt | 4 ++++
drivers/watchdog/watchdog_core.c | 27 ++++++++++++++++++++++++++
include/linux/watchdog.h | 4 ++++
3 files changed, 35 insertions(+)
diff --git a/Documentation/watchdog/watchdog-kernel-api.txt b/Documentation/watchdog/watchdog-kernel-api.txt
index 086638f..2208db7 100644
--- a/Documentation/watchdog/watchdog-kernel-api.txt
+++ b/Documentation/watchdog/watchdog-kernel-api.txt
@@ -212,3 +212,7 @@ driver specific data to and a pointer to the data itself.
The watchdog_get_drvdata function allows you to retrieve driver specific data.
The argument of this function is the watchdog device where you want to retrieve
data from. The function returns the pointer to the driver specific data.
+
+The watchdog_init_timeout function allows you to initialize the timeout field
+using the module timeout parameter or retrieving the timeout-sec property from
+the device tree.
diff --git a/drivers/watchdog/watchdog_core.c b/drivers/watchdog/watchdog_core.c
index 3796434..646be48 100644
--- a/drivers/watchdog/watchdog_core.c
+++ b/drivers/watchdog/watchdog_core.c
@@ -143,6 +143,33 @@ void watchdog_unregister_device(struct watchdog_device *wdd)
}
EXPORT_SYMBOL_GPL(watchdog_unregister_device);
+/**
+ * watchdog_init_timeout() - initialize the timeout field
+ * @parm_timeout: timeout module parameter, it takes precedence over the
+ * timeout-sec property.
+ * @node: Retrieve the timeout-sec property only if the parm_timeout
+ * is out of bounds.
+ */
+void watchdog_init_timeout(struct watchdog_device *wdd,
+ unsigned int parm_timeout, struct device_node *node)
+{
+ unsigned int t = 0;
+
+ if ((parm_timeout >= wdd->min_timeout) &&
+ (parm_timeout <= wdd->max_timeout)) {
+ wdd->timeout = parm_timeout;
+ return;
+ }
+
+ if (!node)
+ return;
+
+ of_property_read_u32(node, "timeout-sec", &t);
+ if ((t >= wdd->min_timeout) && (t <= wdd->max_timeout))
+ wdd->timeout = t;
+}
+EXPORT_SYMBOL_GPL(watchdog_init_timeout);
+
static int __init watchdog_init(void)
{
int err;
diff --git a/include/linux/watchdog.h b/include/linux/watchdog.h
index da70f0f..d09dda7 100644
--- a/include/linux/watchdog.h
+++ b/include/linux/watchdog.h
@@ -11,6 +11,7 @@
#include <linux/ioctl.h>
#include <linux/types.h>
+#include <linux/of.h>
#define WATCHDOG_IOCTL_BASE 'W'
@@ -177,6 +178,9 @@ static inline void *watchdog_get_drvdata(struct watchdog_device *wdd)
/* drivers/watchdog/core/watchdog_core.c */
extern int watchdog_register_device(struct watchdog_device *);
extern void watchdog_unregister_device(struct watchdog_device *);
+extern void watchdog_init_timeout(struct watchdog_device *wdd,
+ unsigned int parm_timeout,
+ struct device_node *node);
#endif /* __KERNEL__ */
--
1.7.11.3
^ permalink raw reply related
* [RFC PATCH v3 0/4] watchdog: core: dt: add support for the timeout-sec dt property
From: Fabio Porcedda @ 2012-10-05 10:16 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
this patchset add the timeout-sec property to the watchdog core,
in the next revision i will add the s3c2410 driver.
changes:
v3:
- rename watchdog_probe_dt_timeout -> watchdog_init_timeout
- move the watchdog_init_timeout function from inline to watchdog_core.c
- add timeout parameter handling code to watchdog_init_timeout
- add timeout-sec property to the pnx4008-wdt driver
- add two small commit for fixup and cleanup
v2:
- change "timeout" to "timeout-sec" as asked by Jean-Christophe
- at91sam9_wdt: use the new helper function
- at91sam9_wdt: add bounds checking
- watchdog.h: add bounds checking
Fabio Porcedda (4):
watchdog: core: dt: add support for the timeout-sec dt property
watchdog: add timeout-sec property binding to some drivers
watchdog: orion_wdt: litte cleanup
watchdog: WatchDog Timer Driver Core: fix comment
.../devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++
.../devicetree/bindings/watchdog/marvel.txt | 5 ++++
.../devicetree/bindings/watchdog/pnx4008-wdt.txt | 4 ++++
Documentation/watchdog/watchdog-kernel-api.txt | 4 ++++
drivers/watchdog/Kconfig | 1 +
drivers/watchdog/at91sam9_wdt.c | 17 ++++++++++----
drivers/watchdog/orion_wdt.c | 13 ++++-------
drivers/watchdog/pnx4008_wdt.c | 7 +++---
drivers/watchdog/watchdog_core.c | 27 ++++++++++++++++++++++
include/linux/watchdog.h | 6 ++++-
10 files changed, 71 insertions(+), 17 deletions(-)
--
1.7.11.3
^ permalink raw reply
* [PATCH 2/2] ARM: Exynos5250: Enabling ohci-exynos driver
From: Vivek Gautam @ 2012-10-05 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349431818-15639-1-git-send-email-gautam.vivek@samsung.com>
Adding OHCI device tree node for Exynos5250 along with
the device base address.
Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
---
.../devicetree/bindings/usb/exynos-usb.txt | 15 +++++++++++++++
arch/arm/boot/dts/exynos5250.dtsi | 6 ++++++
arch/arm/mach-exynos/include/mach/map.h | 1 +
arch/arm/mach-exynos/mach-exynos5-dt.c | 2 ++
4 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index 56e35c7..bff10a8 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -23,3 +23,18 @@ Example:
interrupts = <0 71 0>;
samsung,vbus-gpio = <&gpx2 6 1 3 3>;
};
+
+OHCI
+Required properties:
+ - compatible: should be "samsung,exynos-ohci" for USB 2.0
+ OHCI companion controller in host mode.
+ - reg: physical base address of the controller and length of memory mapped
+ region.
+ - interrupts: interrupt number to the cpu.
+
+Example:
+ ohci {
+ compatible = "samsung,exynos-ohci";
+ reg = <0x12120000 0x100>;
+ interrupts = <0 71 0>;
+ };
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index 73ea844..bcdfbe2 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -224,6 +224,12 @@
interrupts = <0 71 0>;
};
+ ohci {
+ compatible = "samsung,exynos-ohci";
+ reg = <0x12120000 0x100>;
+ interrupts = <0 71 0>;
+ };
+
amba {
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-exynos/include/mach/map.h
index 825fe40..cfede1f 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -196,6 +196,7 @@
#define EXYNOS4_PA_OHCI 0x12590000
#define EXYNOS4_PA_HSPHY 0x125B0000
#define EXYNOS5_PA_EHCI 0x12110000
+#define EXYNOS5_PA_OHCI 0x12120000
#define EXYNOS4_PA_MFC 0x13400000
#define EXYNOS4_PA_UART 0x13800000
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c b/arch/arm/mach-exynos/mach-exynos5-dt.c
index 6d950d7b..e6c2144 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -74,6 +74,8 @@ static const struct of_dev_auxdata exynos5250_auxdata_lookup[] __initconst = {
"exynos-gsc.3", NULL),
OF_DEV_AUXDATA("samsung,exynos-ehci", EXYNOS5_PA_EHCI,
"s5p-ehci", NULL),
+ OF_DEV_AUXDATA("samsung,exynos-ohci", EXYNOS5_PA_OHCI,
+ "exynos-ohci", NULL),
{},
};
--
1.7.6.5
^ permalink raw reply related
* [PATCH 1/2] ARM: Exynos5250: Enabling ehci-s5p driver
From: Vivek Gautam @ 2012-10-05 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349431818-15639-1-git-send-email-gautam.vivek@samsung.com>
Adding EHCI device tree node for Exynos5250 along with
the device base adress and gpio line for vbus.
Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
---
.../devicetree/bindings/usb/exynos-usb.txt | 25 ++++++++++++++++++++
arch/arm/boot/dts/exynos5250-smdk5250.dts | 4 +++
arch/arm/boot/dts/exynos5250.dtsi | 6 ++++
arch/arm/mach-exynos/include/mach/map.h | 1 +
arch/arm/mach-exynos/mach-exynos5-dt.c | 2 +
5 files changed, 38 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/exynos-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt b/Documentation/devicetree/bindings/usb/exynos-usb.txt
new file mode 100644
index 0000000..56e35c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -0,0 +1,25 @@
+Samsung Exynos SoC USB controller
+
+The USB devices interface with USB controllers on Exynos SOCs.
+The device node has following properties.
+
+EHCI
+Required properties:
+ - compatible: should be "samsung,exynos-ehci" for USB 2.0
+ EHCI controller in host mode.
+ - reg: physical base address of the controller and length of memory mapped
+ region.
+ - interrupts: interrupt number to the cpu.
+
+Optional properties:
+ - samsung,vbus-gpio: if present, specifies the GPIO that
+ needs to be pulled up for the bus to be powered.
+
+Example:
+
+ ehci {
+ compatible = "samsung,exynos-ehci";
+ reg = <0x12110000 0x100>;
+ interrupts = <0 71 0>;
+ samsung,vbus-gpio = <&gpx2 6 1 3 3>;
+ };
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index a352df4..089576b 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -166,4 +166,8 @@
spi_2: spi at 12d40000 {
status = "disabled";
};
+
+ ehci {
+ samsung,vbus-gpio = <&gpx2 6 1 3 3>;
+ };
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index dddfd6e..73ea844 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -218,6 +218,12 @@
#size-cells = <0>;
};
+ ehci {
+ compatible = "samsung,exynos-ehci";
+ reg = <0x12110000 0x100>;
+ interrupts = <0 71 0>;
+ };
+
amba {
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-exynos/include/mach/map.h
index 8480849..825fe40 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -195,6 +195,7 @@
#define EXYNOS4_PA_EHCI 0x12580000
#define EXYNOS4_PA_OHCI 0x12590000
#define EXYNOS4_PA_HSPHY 0x125B0000
+#define EXYNOS5_PA_EHCI 0x12110000
#define EXYNOS4_PA_MFC 0x13400000
#define EXYNOS4_PA_UART 0x13800000
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c b/arch/arm/mach-exynos/mach-exynos5-dt.c
index fee9dcd..6d950d7b 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -72,6 +72,8 @@ static const struct of_dev_auxdata exynos5250_auxdata_lookup[] __initconst = {
"exynos-gsc.2", NULL),
OF_DEV_AUXDATA("samsung,exynos5-gsc", EXYNOS5_PA_GSC3,
"exynos-gsc.3", NULL),
+ OF_DEV_AUXDATA("samsung,exynos-ehci", EXYNOS5_PA_EHCI,
+ "s5p-ehci", NULL),
{},
};
--
1.7.6.5
^ permalink raw reply related
* [PATCH 0/2] Enable ehci and ohci devices for exynos5250
From: Vivek Gautam @ 2012-10-05 10:10 UTC (permalink / raw)
To: linux-arm-kernel
Based on for-next branch of linux-samsung.
Vivek Gautam (2):
ARM: Exynos5250: Enabling ehci-s5p driver
ARM: Exynos5250: Enabling ohci-exynos driver
.../devicetree/bindings/usb/exynos-usb.txt | 40 ++++++++++++++++++++
arch/arm/boot/dts/exynos5250-smdk5250.dts | 4 ++
arch/arm/boot/dts/exynos5250.dtsi | 12 ++++++
arch/arm/mach-exynos/include/mach/map.h | 2 +
arch/arm/mach-exynos/mach-exynos5-dt.c | 4 ++
5 files changed, 62 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/exynos-usb.txt
--
1.7.6.5
^ 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