Re: [PATCH] omap-i2c: fix incorrect log message when using a device tree
Hello Wolfram, When booting using a device tree, the adapter number is dynamically assigned after the log message is sent. This patch modifies the log message to get a correct adapter id. Applies on 3.6-rc3. Tested on OMAP3 (Gumstix Overo). Thanks for the fix. Tested successfully on OMAP4 SDP DT boot as well. [0.00] Linux version 3.6.0-rc3-00030-g491038d (bcousson@lnwes3201) (gcc version 4.5.2 (Sourcery G++ Lite 2011.03-41) ) #6 SMP Fri Aug 31 13:50:48 CEST 2012 [0.00] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic OMAP4 (Flattened Device Tree), model: TI OMAP4 SDP board ... [0.667205] omap_i2c i2c.15: bus 0 rev2.4.0 at 400 kHz ... [0.768341] omap_i2c i2c.16: bus 1 rev2.4.0 at 400 kHz [0.783905] omap_i2c i2c.17: bus 2 rev2.4.0 at 400 kHz [0.799530] omap_i2c i2c.18: bus 3 rev2.4.0 at 400 kHz Signed-off-by: Florian Vaussard Tested-by: Benoit Cousson and Acked-by: Benoit Cousson Regards, Benoit Was this patch picked-up by the i2c-embedded subsystem? Thank you. Regards, Florian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP4: wakeupgen: remove duplicate AUXCOREBOOT* read/write
On Tue, Sep 11, 2012 at 12:13 PM, Paul Walmsley wrote: > On Tue, 11 Sep 2012, Shilimkar, Santosh wrote: > >> On Tue, Sep 11, 2012 at 12:07 PM, Paul Walmsley wrote: >> > On Tue, 11 Sep 2012, Shilimkar, Santosh wrote: >> > >> >> On Tue, Sep 11, 2012 at 12:25 AM, Tony Lindgren wrote: >> >> > * Shilimkar, Santosh [120908 01:20]: >> >> >> >> >> >> Will you able to pick up these couple of wakeupgen fixes from here or >> >> >> do you want me to send you a pull request for 3.6-rc5/6 >> >> > >> >> > I can pick them into fixes-noncritical. But if the second one is >> >> > a major bug for the -rc series, the patch should be describe what >> >> > breaks (regression? oops?). >> >> > >> >> Fixes non critical is fine. No major issue without these patches. >> > >> > There's an ordering constraint though: Santosh's patch needs to go in >> > first, then mine. >> > >> Its other way round ;-) >> Mine I created after applying your change. > > The problem is that if my patch is applied first, then there will be a > point after my patch where the AUXCOREBOOT1 register won't be saved, which > might break PM. So the patches may need to be updated. > Good point. It's trivial to re-order them. Tony, Updated patches in the end of the email. Also attached. Regards Santosh >From 4e1da2a44d92b956c3a740f5af6a45ff1c2dc294 Mon Sep 17 00:00:00 2001 From: Paul Walmsley Date: Tue, 11 Sep 2012 12:43:18 +0530 Subject: [PATCH 2/2] ARM: OMAP4: wakeupgen: remove duplicate AUXCOREBOOT* read/write The wakeupgen context-save code reads and stores the AUXCOREBOOT0 and AUXCOREBOOT1 register contents twice. This seems like a waste of time, so, remove the duplicates. Acked-by: Santosh Shilimkar Signed-off-by: Paul Walmsley --- arch/arm/mach-omap2/omap-wakeupgen.c |6 -- 1 file changed, 6 deletions(-) diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c index c3795c2..567f672 100644 --- a/arch/arm/mach-omap2/omap-wakeupgen.c +++ b/arch/arm/mach-omap2/omap-wakeupgen.c @@ -233,12 +233,6 @@ static inline void omap4_irq_save_context(void) __raw_writel(val, sar_base + AUXCOREBOOT1_OFFSET); /* Save SyncReq generation logic */ - val = __raw_readl(wakeupgen_base + OMAP_AUX_CORE_BOOT_0); - __raw_writel(val, sar_base + AUXCOREBOOT0_OFFSET); - val = __raw_readl(wakeupgen_base + OMAP_AUX_CORE_BOOT_0); - __raw_writel(val, sar_base + AUXCOREBOOT1_OFFSET); - - /* Save SyncReq generation logic */ val = __raw_readl(wakeupgen_base + OMAP_PTMSYNCREQ_MASK); __raw_writel(val, sar_base + PTMSYNCREQ_MASK_OFFSET); val = __raw_readl(wakeupgen_base + OMAP_PTMSYNCREQ_EN); -- 1.7.9.5 >From 6e3b8a3f6ec231f588b860d87b7a80f6ba38ce98 Mon Sep 17 00:00:00 2001 From: Santosh Shilimkar Date: Thu, 6 Sep 2012 11:51:34 +0530 Subject: [PATCH 1/2] ARM: OMAP4: wakeupgen: Fix the typo in AUXCOREBOOT register save The wakeupgen context-save code reads AUXCOREBOOT0 register instead of AUXCOREBOOT1 register contents while saving AUXCOREBOOT1. Fix the same. Signed-off-by: Santosh Shilimkar --- arch/arm/mach-omap2/omap-wakeupgen.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c index 05fdebf..c3795c2 100644 --- a/arch/arm/mach-omap2/omap-wakeupgen.c +++ b/arch/arm/mach-omap2/omap-wakeupgen.c @@ -229,7 +229,7 @@ static inline void omap4_irq_save_context(void) /* Save AuxBoot* registers */ val = __raw_readl(wakeupgen_base + OMAP_AUX_CORE_BOOT_0); __raw_writel(val, sar_base + AUXCOREBOOT0_OFFSET); - val = __raw_readl(wakeupgen_base + OMAP_AUX_CORE_BOOT_0); + val = __raw_readl(wakeupgen_base + OMAP_AUX_CORE_BOOT_1); __raw_writel(val, sar_base + AUXCOREBOOT1_OFFSET); /* Save SyncReq generation logic */ -- 1.7.9.5 0002-ARM-OMAP4-wakeupgen-remove-duplicate-AUXCOREBOOT-rea.patch Description: Binary data 0001-ARM-OMAP4-wakeupgen-Fix-the-typo-in-AUXCOREBOOT-regi.patch Description: Binary data
Re: [PATCH] ARM: OMAP2+: mux: add support for PAD wakeup event handler
On Tue, Sep 11, 2012 at 12:09 AM, Tony Lindgren wrote: > * Ruslan Bilovol [120910 03:39]: >> OMAP mux now parses active wakeup events from pad registers and calls >> corresponding handler, if handler is not registered - corresponding >> hwmod ISRs once a wakeup is detected. >> This is useful for cases when routing wakeups to corresponding hwmod >> ISRs complicates those ISRs handlers (for example, ISR handler may >> not know who the interrupt source is) > > The mux code in arch/arm/mach-omap2 will be going away and replaced > by device tree based pinctrl-single. Thanks tony when is this device tree based pinctrl-single will be available in mainline? regards keshava -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/8] ARM: OMAP2+: PM: introduce the power domains functional states
Hi Tero, Paul, After discussion with Paul at LPC I produced a new version that we are now internally reviewing. Paul, what is your plan? Regards, Jean On Mon, Sep 10, 2012 at 5:09 PM, Tero Kristo wrote: > On Thu, 2012-08-16 at 11:20 +0530, Shilimkar, Santosh wrote: >> Paul, >> >> On Thu, Aug 16, 2012 at 6:18 AM, Paul Walmsley wrote: >> > >> > Hi Santosh, >> > >> > On Wed, 15 Aug 2012, Shilimkar, Santosh wrote: >> > >> > > On Wed, Aug 15, 2012 at 3:32 PM, Jean Pihet >> > > wrote: >> > > >> > > I didn't find any mention here about why are we going in this path and >> > > not >> > > in the direction proposed in another RFC [1] >> > > I have already given my comments[2] against the introduction of another >> > > PD >> > > layer which can be avoided easily as demonstrated by the RFC[1]. The >> > > comments >> > > are still applicable for this series too. >> > > >> > > We really need to reduce OMAP specific framework overhead and >> > > move towards more generic PM frameworks. For me, this series is >> > > a step back-ward from that direction. Am really sorry for being critical >> > > again but I remain unconvinced about this series and the problem it >> > > is trying to solve. >> > > >> > > May be you have valid reasons not to follow the approach in [1] and in >> > > that case, it will be good to clarify that so that some of us get >> > > to know your rationale. >> > >> > I've asked Jean to handle the work of evaluating and/or integrating any >> > feedback from you and Rajendra into this series. Jean, has this latest >> > series fully considered those issues? Or are there still some areas of >> > misalignment / lack of clarity? >> > >> Thanks for the information. The main objection to this series was to >> not add un-necessary glue layer which still remains. >> >> From our discussion in past on and off list, your main intention for such >> a series was - >> >> 1. Need a way to support OSWR. >> - OSWR by definition is a RET with configurable logic and memory states. >> Its a true power state from PD point of view and its not a logical state. >> Now since we have agreed to make the OSWR as a static definition >> (in all products so far OSWR is used as a static definition with logic >> lost, memory retained kind of configuration.) >> >> - The above requirement can be easily fixed by adding the OSWR >> as an additional basic power state as demonstrated in RFC. >> >> - There is no need to add another glue layer for above. >> >> 2. Locking so that the low level APIs don't race and henec abstracting the >> exported API to 1 or 2 and making rest as private functions. >> >> -- Even before this series, except low level PM code, only one >> common API was used to set the PD low power state. >> int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 pwrst) >> >> -- Once we make OSWR as basic power state, we also avoid usage of >> pwrdm_set_logic_retst() API. >> >> -- We implement lock at this API and export only above API + >> may be omap_get_pwrdm_state() kind of API based on need. >> >> -- This solves the second requirement too. >> >> Even if we have more requirement, they can be addressed >> too without need of another layer. >> >> If you look at the diffstat alone between two approaches, it is >> evident how small piece of code is needed to support above. >> Am not too much into the lines of code but basic objection we >> have is not to add another glue layer. >> >> Thinking bit loud, for the logical layer for power domain >> we should move towards common device power domain >> APIs and if needed add/enhance them to support OMAP. >>drivers/base/power/domain.c >> May be this though is bit premature but the intetion is >> to move towards generic linux framework. >> >> > Anyway. If there's a problem with this process, it sounds like you, >> > Rajendra, Jean, Benoît and I should schedule some time to talk over the >> > same issues that you discussed with me on the phone. Perhaps next week? >> > >> We can surely do a call if needed. But the comments given so far and the >> RFC makes things more or less clear the contention point against the >> $subject series. > > What is the latest status with this set? This is kind of blocking the > omap4 core retention feature also as I am supposed to put the patches on > top of this set. Do we have a consensus which way this set should > evolve? > > Or, should I just base the core retention patches on top of baseline and > forget about the functional power states for now? > > -Tero > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm/dts: omap: Add omap-usb2 dt data
Hi Kishon,
On 09/11/2012 08:12 AM, Kishon Vijay Abraham I wrote:
> Add omap-usb2 data node in omap4 device tree file. Since omap-usb2 is
> connected to ocp2scp, omap-usb2 dt data is added as a child node
> of ocp2scp.
Could you add more details about the omap-usb2?
You must update the Documentation binding with that compatible name.
Is it already part of the driver serie? The MUSB driver is referring to
"ti,musb-omap2430" only.
>
> Acked-by: Felipe Balbi
> Signed-off-by: Kishon Vijay Abraham I
> ---
> Applies on
> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git for-next
> arch/arm/boot/dts/omap4.dtsi |5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
> index 8a780b2..bdc21f1 100644
> --- a/arch/arm/boot/dts/omap4.dtsi
> +++ b/arch/arm/boot/dts/omap4.dtsi
> @@ -302,6 +302,11 @@
> #size-cells = <1>;
> ranges;
> ti,hwmods = "ocp2scp_usb_phy";
There is no ocp2scp_usb_phy in the current omap4.dtsi?
What base did you used?
You have to use lo/devel-dt branch as a base. All the latest DTS patches
an in there for 3.7.
Regards,
Benoit
> + usb2phy@4a0ad080 {
> + compatible = "ti,omap-usb2";
> + reg = <0x4a0ad080 0x58>,
> + <0x4a002300 0x4>;
> + };
> };
> };
> };
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] perf: Use pre-empt safe cpu_get/put insted of smp_processor_id
On 09/10/2012 08:53 PM, Stephen Boyd wrote:
> On 09/10/12 04:30, Roger Quadros wrote:
>> gets rid of below messages with CONFIG_DEBUG_PREEMPT enabled
>>
>> [ 28.832916] debug_smp_processor_id: 18 callbacks suppressed
>> [ 28.832946] BUG: using smp_processor_id() in preemptible [] code:
>> modprobe/1763
>> [ 28.841491] caller is pwrdm_set_next_pwrst+0x54/0x120
>>
>> changes in v2:
>> - rebased on 3.6-rc5
>> - use put_cpu() immediately after get_cpu() in omap3_pm_idle()
>>
>> Signed-off-by: Roger Quadros
>> ---
>> arch/arm/mach-omap2/clock.c |9 ++---
>> arch/arm/mach-omap2/pm34xx.c | 12
>> arch/arm/mach-omap2/powerdomain.c |6 --
>> 3 files changed, 18 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
>> index ea3f565..06747b6 100644
>> --- a/arch/arm/mach-omap2/clock.c
>> +++ b/arch/arm/mach-omap2/clock.c
>> @@ -285,7 +285,8 @@ void omap2_clk_disable(struct clk *clk)
>> pr_debug("clock: %s: disabling in hardware\n", clk->name);
>>
>> if (clk->ops && clk->ops->disable) {
>> -trace_clock_disable(clk->name, 0, smp_processor_id());
>> +trace_clock_disable(clk->name, 0, get_cpu());
>> +put_cpu();
>
> Why are you doing this? Why not just use raw_smp_processor_id()? Do you
> really care about the CPU number? get_cpu() and put_cpu() are about
> non-preemptible sections where you want to ensure the CPU the code is
> operating on is actually on that CPU.
You are right. raw_smp_processor_id() makes perfect sense here.
>
> How about just put 0 all the time because the CPU number is already part
> of the trace event?
>
I'm not sure about this. I can see that removing the cpu_id field from
trace_cpu_idle() was discussed here [1] and it was decided to keep it.
There was no conclusion about removing it from
trace_clock_enable/disable though.
For now, I will resend the patch with raw_smp_processor_id().
regards,
-roger
[1] https://lkml.org/lkml/2011/8/19/316
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm/dts: omap: Add omap-usb2 dt data
Hi, On Tue, Sep 11, 2012 at 1:53 PM, Benoit Cousson wrote: > Hi Kishon, > > On 09/11/2012 08:12 AM, Kishon Vijay Abraham I wrote: >> Add omap-usb2 data node in omap4 device tree file. Since omap-usb2 is >> connected to ocp2scp, omap-usb2 dt data is added as a child node >> of ocp2scp. > > Could you add more details about the omap-usb2? I think information about omap-usb2 driver is added in *usb: phy: add a new driver for omap usb2 phy.*. Do you want the same thing to be added here? > > You must update the Documentation binding with that compatible name. Yes. It's part of *usb: phy: add a new driver for omap usb2 phy.* > Is it already part of the driver serie? The MUSB driver is referring to > "ti,musb-omap2430" only. Will correct the Documentation for MUSB. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module
Hi,
On Mon, Sep 10, 2012 at 10:13 PM, Felipe Balbi wrote:
> Hi,
>
> On Mon, Sep 10, 2012 at 06:17:03PM +0200, Benoit Cousson wrote:
>> > On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
>> >> The mailbox register for usb otg in omap is present in control module.
>> >> On detection of any events VBUS or ID, this register should be written
>> >> to send the notification to musb core.
>> >>
>> >> Till we have a separate control module driver to write to control
>> >> module,
>> >> omap2430 will handle the register writes to control module by itself.
>> >> So
>> >> a new address space to represent this control module register is added
>> >> to usb_otg_hs.
>> >>
>> >> Cc: Benoit Cousson
>> >> Signed-off-by: Kishon Vijay Abraham I
>> >> ---
>> >> arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 +
>> >> 1 file changed, 5 insertions(+)
>> >>
>> >> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>> >> b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>> >> index 242aee4..02341bc 100644
>> >> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>> >> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>> >> @@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space
>> >> omap44xx_usb_otg_hs_addrs[] = {
>> >>.pa_end = 0x4a0ab003,
>> >>.flags = ADDR_TYPE_RT
>> >>},
>> >> + {
>> >> + .pa_start = 0x4a00233c,
>> >> + .pa_end = 0x4a00233f,
>> >> + .flags = ADDR_TYPE_RT
>> >> + },
>> >
>> > I do not have any objection/comment here, but I believe this is control
>> > module address space required for USB module, right?
>> > I am not sure this is right way of accessing control module space.
>> > Actually Control Module Access required for drivers is one of the
>> > blocking issue we have currently.
>> >
>> > Also there was some effort put up by 'Konstantine' to convert Control
>> > module to MFD driver, I haven't seen any further update on it. But it
>> > would be good to check with him.
>>
>> this was an agreement with Benoit since we already lost a couple merge
>> windows for this patchset. We agreed to wait until -rc4 for SCM driver
>> and if it wasn't ready, we'd go ahead with this and SCM author would fix
>> it up on a patch converting users to new SCM driver.
>> >>>
>> >>> Tony, can I get your Acked-by to this patch so I can take it together
>> >>> with the rest of the series ? Thanks
>> >>>
>> >>> ps: I'll apply this to my 'musb' branch which is immutable, so it's safe
>> >>> to merge it into your tree once I apply.
>> >>
>> >> It would be best if this got acked by Benoit and Paul as they may
>> >> have some other patches queued up. I'll ack if they ack ;)
>> >
>> > Benoit, care to ack this patch ???
>>
>> Gosh, that's hard to ack something like that :-)
>
> btw, that's not different than what's already in tree, the only
> difference is that now hwmod knows about it...
>
>> But considering that the control module driver is not there yet, I have
>> no choice but accepting that one if we want to have the functionality
>> we've been waiting for years.
>>
>> Could you just update the patch with a big disclaimer on top of the
>> address range to explain that this should not belong here and will be
>> removed ASAP, when the proper driver will be done.
>
> sure, that's doable... Kishon, can you do this ASAP ? I want to send my
> pull requests tomorrow at the latest.
Sure. Will send now.
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] pinctrl: pinctrl-single: Add pinctrl-single,bits type of mux
With pinctrl-single,bits it is possible to update just part of the register
within the pinctrl-single,function-mask area.
This is useful when one register configures mmore than one pin's mux.
pinctrl-single,bits takes three parameters:
Signed-off-by: Peter Ujfalusi
---
Hello Tony, Linus,
Changes since v1:
- Added boolean for the pinctrl-single: pinctrl-single,bit-per-mux
When this is set the it indicates that the area contains registers which
changes mux for multible pins.
- Documentation updated reflecting this change (with example for this type)
Regards,
Peter
.../devicetree/bindings/pinctrl/pinctrl-single.txt | 41 +--
drivers/pinctrl/pinctrl-single.c | 46 +-
2 files changed, 74 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
index 5187f0d..2c81e45 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
@@ -14,10 +14,12 @@ Optional properties:
- pinctrl-single,function-off : function off mode for disabled state if
available and same for all registers; if not specified, disabling of
pin functions is ignored
+- pinctrl-single,bit-per-mux : boolean to indicate that one register controls
+ more than one pin
-This driver assumes that there is only one register for each pin,
-and uses the common pinctrl bindings as specified in the pinctrl-bindings.txt
-document in this directory.
+This driver assumes that there is only one register for each pin (unless the
+pinctrl-single,bit-per-mux is set), and uses the common pinctrl bindings as
+specified in the pinctrl-bindings.txt document in this directory.
The pin configuration nodes for pinctrl-single are specified as pinctrl
register offset and value pairs using pinctrl-single,pins. Only the bits
@@ -31,6 +33,15 @@ device pinctrl register, and 0x118 contains the desired
value of the
pinctrl register. See the device example and static board pins example
below for more information.
+In case when one register changes more than one pin's mux the
+pinctrl-single,bits need to be used which takes three parameters:
+
+ pinctrl-single,bits = <0xdc 0x18, 0xff>;
+
+Where 0xdc is the offset from the pinctrl register base address for the
+device pinctrl register, 0x18 is the desired value, and 0xff is the sub mask to
+be used when applying this change to the register.
+
Example:
/* SoC common file */
@@ -55,6 +66,15 @@ pmx_wkup: pinmux@4a31e040 {
pinctrl-single,function-mask = <0x>;
};
+control_devconf0: pinmux@48002274 {
+ compatible = "pinctrl-single";
+ reg = <0x48002274 4>; /* Single register */
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-single,bit-per-mux;
+ pinctrl-single,register-width = <32>;
+ pinctrl-single,function-mask = <0x5F>;
+};
/* board specific .dts file */
@@ -87,6 +107,21 @@ pmx_wkup: pinmux@4a31e040 {
};
};
+&control_devconf0 {
+ mcbsp1_pins: pinmux_mcbsp1_pins {
+ pinctrl-single,bits = <
+ 0x00 0x18 0x18 /* FSR/CLKR signal from FSX/CLKX pin */
+ >;
+ };
+
+ mcbsp2_clks_pins: pinmux_mcbsp2_clks_pins {
+ pinctrl-single,bits = <
+ 0x00 0x40 0x40 /* McBSP2 CLKS from McBSP_CLKS pin */
+ >;
+ };
+
+};
+
&uart2 {
pinctrl-names = "default";
pinctrl-0 = <&uart2_pins>;
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index 3508631..759b5a6 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -26,7 +26,8 @@
#include "core.h"
#define DRIVER_NAME"pinctrl-single"
-#define PCS_MUX_NAME "pinctrl-single,pins"
+#define PCS_MUX_PINS_NAME "pinctrl-single,pins"
+#define PCS_MUX_BITS_NAME "pinctrl-single,bits"
#define PCS_REG_NAME_LEN ((sizeof(unsigned long) * 2) + 1)
#define PCS_OFF_DISABLED ~0U
@@ -54,6 +55,7 @@ struct pcs_pingroup {
struct pcs_func_vals {
void __iomem *reg;
unsigned val;
+ unsigned mask;
};
/**
@@ -139,6 +141,7 @@ struct pcs_device {
unsigned fshift;
unsigned foff;
unsigned fmax;
+ bool bits_per_mux;
struct pcs_name *names;
struct pcs_data pins;
struct radix_tree_root pgtree;
@@ -332,12 +335,17 @@ static int pcs_enable(struct pinctrl_dev *pctldev,
unsigned fselector,
for (i = 0; i < func->nvals; i++) {
struct pcs_func_vals *vals;
- unsigned val;
+ unsigned val, mask;
vals = &func->vals[i];
val = pcs->read(vals->reg);
- val &= ~pcs->fmask;
- val |= (vals->val & pcs->fmask);
+
[PATCH v2 0/3] omap: musb: Add device tree support
This patch series adds device tree support for MUSB. The glue layer is now made to write to mailbox register (present in control module) instead of calling phy layer to write to mailbox register. Writing to mailbox register notifies the core of events like device connect/disconnect. Changes from v1: * Added a comment in hwmod data to remove the control module data from otg_hs once control driver is in place. * Fixed the omap-usb Documentation to the correct compatible value (Should be "ti,omap4-musb" or "ti,omap3-musb") Previously these patches were part of [PATCH v7 0/7] omap: musb: Add device tree support This patch series was created to contain only the *musb* part and it also has one hwmod patch. This patch series was created on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git musb Kishon Vijay Abraham I (3): arm: omap: hwmod: add a new addr space in otg for writing to control module usb: musb: omap: write directly to mailbox instead of using phy usb: musb: omap: Add device tree support for omap musb glue Documentation/devicetree/bindings/usb/omap-usb.txt | 33 ++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 ++ drivers/usb/musb/omap2430.c| 106 ++-- drivers/usb/musb/omap2430.h|9 ++ 4 files changed, 147 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] usb: musb: omap: write directly to mailbox instead of using phy
The glue layer should directly write to mailbox register (present in
control module) instead of calling phy layer to write to mailbox
register. Writing to mailbox register notifies the core of events like
device connect/disconnect.
Currently writing to control module register is taken care in this
driver which will be removed once the control module driver is in place.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/musb/omap2430.c | 52 +--
drivers/usb/musb/omap2430.h |9
2 files changed, 54 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 02c39a7..f4d9503 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -45,6 +45,7 @@ struct omap2430_glue {
struct platform_device *musb;
enum omap_musb_vbus_id_status status;
struct work_struct omap_musb_mailbox_work;
+ u32 __iomem *control_otghs;
};
#define glue_to_musb(g)platform_get_drvdata(g->musb)
@@ -52,6 +53,26 @@ struct omap2430_glue *_glue;
static struct timer_list musb_idle_timer;
+/**
+ * omap4_usb_phy_mailbox - write to usb otg mailbox
+ * @glue: struct omap2430_glue *
+ * @val: the value to be written to the mailbox
+ *
+ * On detection of a device (ID pin is grounded), this API should be called
+ * to set AVALID, VBUSVALID and ID pin is grounded.
+ *
+ * When OMAP is connected to a host (OMAP in device mode), this API
+ * is called to set AVALID, VBUSVALID and ID pin in high impedance.
+ *
+ * XXX: This function will be removed once we have a seperate driver for
+ * control module
+ */
+static void omap4_usb_phy_mailbox(struct omap2430_glue *glue, u32 val)
+{
+ if (glue->control_otghs)
+ writel(val, glue->control_otghs);
+}
+
static void musb_do_idle(unsigned long _musb)
{
struct musb *musb = (void *)_musb;
@@ -247,6 +268,7 @@ EXPORT_SYMBOL_GPL(omap_musb_mailbox);
static void omap_musb_set_mailbox(struct omap2430_glue *glue)
{
+ u32 val;
struct musb *musb = glue_to_musb(glue);
struct device *dev = musb->controller;
struct musb_hdrc_platform_data *pdata = dev->platform_data;
@@ -262,7 +284,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
musb->xceiv->last_event = USB_EVENT_ID;
if (musb->gadget_driver) {
pm_runtime_get_sync(dev);
- usb_phy_init(musb->xceiv);
+ val = AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
omap2430_musb_set_vbus(musb, 1);
}
break;
@@ -275,7 +298,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
musb->xceiv->last_event = USB_EVENT_VBUS;
if (musb->gadget_driver)
pm_runtime_get_sync(dev);
- usb_phy_init(musb->xceiv);
+ val = IDDIG | AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
break;
case OMAP_MUSB_ID_FLOAT:
@@ -292,7 +316,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
if (musb->xceiv->otg->set_vbus)
otg_set_vbus(musb->xceiv->otg, 0);
}
- usb_phy_shutdown(musb->xceiv);
+ val = SESSEND | IDDIG;
+ omap4_usb_phy_mailbox(glue, val);
break;
default:
dev_dbg(dev, "ID float\n");
@@ -367,6 +392,7 @@ err1:
static void omap2430_musb_enable(struct musb *musb)
{
u8 devctl;
+ u32 val;
unsigned long timeout = jiffies + msecs_to_jiffies(1000);
struct device *dev = musb->controller;
struct omap2430_glue *glue = dev_get_drvdata(dev->parent);
@@ -376,7 +402,8 @@ static void omap2430_musb_enable(struct musb *musb)
switch (glue->status) {
case OMAP_MUSB_ID_GROUND:
- usb_phy_init(musb->xceiv);
+ val = AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
if (data->interface_type != MUSB_INTERFACE_UTMI)
break;
devctl = musb_readb(musb->mregs, MUSB_DEVCTL);
@@ -395,7 +422,8 @@ static void omap2430_musb_enable(struct musb *musb)
break;
case OMAP_MUSB_VBUS_VALID:
- usb_phy_init(musb->xceiv);
+ val = IDDIG | AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
break;
default:
@@ -405,11 +433,14 @@ static void omap2430_musb_enable(struct musb *musb)
static void omap2430_musb_disable(struct musb *musb)
{
+ u32 val;
struct device *dev = musb->controller;
struct omap2430_glue *glue = dev_get_drvdata(dev->parent);
- if (glue->status != OMAP_MUS
[PATCH v2 3/3] usb: musb: omap: Add device tree support for omap musb glue
Added device tree support for omap musb driver and updated the
Documentation with device tree binding information.
Signed-off-by: Kishon Vijay Abraham I
---
Documentation/devicetree/bindings/usb/omap-usb.txt | 33
drivers/usb/musb/omap2430.c| 54
2 files changed, 87 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
new file mode 100644
index 000..29a043e
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -0,0 +1,33 @@
+OMAP GLUE
+
+OMAP MUSB GLUE
+ - compatible : Should be "ti,omap4-musb" or "ti,omap3-musb"
+ - ti,hwmods : must be "usb_otg_hs"
+ - multipoint : Should be "1" indicating the musb controller supports
+ multipoint. This is a MUSB configuration-specific setting.
+ - num_eps : Specifies the number of endpoints. This is also a
+ MUSB configuration-specific setting. Should be set to "16"
+ - ram_bits : Specifies the ram address size. Should be set to "12"
+ - interface_type : This is a board specific setting to describe the type of
+ interface between the controller and the phy. It should be "0" or "1"
+ specifying ULPI and UTMI respectively.
+ - mode : Should be "3" to represent OTG. "1" signifies HOST and "2"
+ represents PERIPHERAL.
+ - power : Should be "50". This signifies the controller can supply upto
+ 100mA when operating in host mode.
+
+SOC specific device node entry
+usb_otg_hs: usb_otg_hs@4a0ab000 {
+ compatible = "ti,omap4-musb";
+ ti,hwmods = "usb_otg_hs";
+ multipoint = <1>;
+ num_eps = <16>;
+ ram_bits = <12>;
+};
+
+Board specific device node entry
+&usb_otg_hs {
+ interface_type = <1>;
+ mode = <3>;
+ power = <50>;
+};
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index f4d9503..d96873b 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -470,8 +471,11 @@ static u64 omap2430_dmamask = DMA_BIT_MASK(32);
static int __devinit omap2430_probe(struct platform_device *pdev)
{
struct musb_hdrc_platform_data *pdata = pdev->dev.platform_data;
+ struct omap_musb_board_data *data;
struct platform_device *musb;
struct omap2430_glue*glue;
+ struct device_node *np = pdev->dev.of_node;
+ struct musb_hdrc_config *config;
struct resource *res;
int ret = -ENOMEM;
@@ -501,6 +505,42 @@ static int __devinit omap2430_probe(struct platform_device
*pdev)
if (glue->control_otghs == NULL)
dev_dbg(&pdev->dev, "Failed to obtain control memory\n");
+ if (np) {
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(&pdev->dev,
+ "failed to allocate musb platfrom data\n");
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ dev_err(&pdev->dev,
+ "failed to allocate musb board data\n");
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ config = devm_kzalloc(&pdev->dev, sizeof(*config), GFP_KERNEL);
+ if (!data) {
+ dev_err(&pdev->dev,
+ "failed to allocate musb hdrc config\n");
+ goto err1;
+ }
+
+ of_property_read_u32(np, "mode", (u32 *)&pdata->mode);
+ of_property_read_u32(np, "interface_type",
+ (u32 *)&data->interface_type);
+ of_property_read_u32(np, "num_eps", (u32 *)&config->num_eps);
+ of_property_read_u32(np, "ram_bits", (u32 *)&config->ram_bits);
+ of_property_read_u32(np, "power", (u32 *)&pdata->power);
+ config->multipoint = of_property_read_bool(np, "multipoint");
+
+ pdata->board_data = data;
+ pdata->config = config;
+ }
+
pdata->platform_ops = &omap2430_ops;
platform_set_drvdata(pdev, glue);
@@ -597,12 +637,26 @@ static struct dev_pm_ops omap2430_pm_ops = {
#define DEV_PM_OPS NULL
#endif
+#ifdef CONFIG_OF
+static const struct of_device_id omap2430_id_table[] = {
+ {
+ .compatible = "ti,omap4-musb"
+ },
+ {
+ .compatible = "ti,omap3-musb"
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap2430_id_table);
+#endif
+
static struct pl
[PATCH v2 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module
The mailbox register for usb otg in omap is present in control module.
On detection of any events VBUS or ID, this register should be written
to send the notification to musb core.
Till we have a separate control module driver to write to control module,
omap2430 will handle the register writes to control module by itself. So
a new address space to represent this control module register is added
to usb_otg_hs.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 242aee4..3c19120 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5890,6 +5890,12 @@ static struct omap_hwmod_addr_space
omap44xx_usb_otg_hs_addrs[] = {
.pa_end = 0x4a0ab003,
.flags = ADDR_TYPE_RT
},
+ {
+ /* XXX: Remove this once control module driver is in place */
+ .pa_start = 0x4a00233c,
+ .pa_end = 0x4a00233f,
+ .flags = ADDR_TYPE_RT
+ },
{ }
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module
On 09/11/2012 11:09 AM, Kishon Vijay Abraham I wrote:
> The mailbox register for usb otg in omap is present in control module.
> On detection of any events VBUS or ID, this register should be written
> to send the notification to musb core.
>
> Till we have a separate control module driver to write to control module,
> omap2430 will handle the register writes to control module by itself. So
> a new address space to represent this control module register is added
> to usb_otg_hs.
>
> Signed-off-by: Kishon Vijay Abraham I
Acked-by: Benoit Cousson
> ---
> arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> index 242aee4..3c19120 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -5890,6 +5890,12 @@ static struct omap_hwmod_addr_space
> omap44xx_usb_otg_hs_addrs[] = {
> .pa_end = 0x4a0ab003,
> .flags = ADDR_TYPE_RT
> },
> + {
> + /* XXX: Remove this once control module driver is in place */
> + .pa_start = 0x4a00233c,
> + .pa_end = 0x4a00233f,
> + .flags = ADDR_TYPE_RT
> + },
> { }
> };
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 00/13] usb: musb: adding multi instance support
Hi, On Fri, Aug 31, 2012 at 04:39:46PM +0530, Ravi Babu wrote: > This series of patches adds, > a) Multi instances support in musb driver > b) DT support for musb_dsps glue layer > c) DT support for NOP transceiver > > AM33xx and TI81xx has dual musb controller and has two usb PHY of same type. > This patch series uses 'phandle' based API devm_usb_get_phy_by_phandle() to > get the PHY of same type. This API support is being added by Kishon's patch > discussed at [1] > > The series applies to felipe/master [1] branch > + Vaibhav baseport patches on his tree at [4] > + Kishon's multi phy patches on Felipe's branch 'xceiv' > + Kishon's patch on phandle at [2] > + Damodar's recent patch at [3] > + Ajay's & Damodar's patches at [5] and [6] included in this series > > 1. http://git.kernel.org/?p=linux/kernel/git/balbi/usb.git;a=summary > 2. http://marc.info/?l=linux-usb&m=134070369306112&w=2 > 3. http://marc.info/?l=linux-usb&m=134200284230689&w=2 > 4. https://github.com/hvaibhav/am335x-linux/commits/am335x-upstream-staging > 5. http://marc.info/?l=linux-usb&m=134200285530701&w=2 > 6. http://marc.info/?l=linux-usb&m=134208820028625&w=2 > > Changes from v8: > - included Sergei's comment, removing underscore in device tree file > - removed duplicated signoff from patches > Changes from v7: > - patches rebased on felipe/master branch & verified > - included additional two patches 0001 & 0002 as part of this series > which are already submitted [5] & [6] > Changes from v6: > - Removed parent_pdev to get glue and used dev_get_getdrv() as per > Felipe's comment > - use pr_debug() instead of pr_info() as per Felipe's comment > Changes from v5: > - Removed musb->id as per Felipe's comment > - used nop_ida as per Felipe's comment > Changes from v4: > - Fixed Felipe's comment for adding EXPORT_SYMBOL_GPL() > - Fixed Felipe's comment on using dev_set_mask() > Changes from v3: > - Fixed Kishon's comment on removing "id" from phy struct and > removing unneeded "#else" part. > Changes from v2: > - Fixed Sergei's comment on not using address prefix in musb_dsps > glue and nop transceiver dt dats. > - Also removed the "ti" string in compatible property for nop data. > Changes from v1: > - Defined musb_ida to manage core ids based on Felipe's comment > in [PATCH 01/11] I tried appliying this, but this doesn't apply. Please rebase on my musb branch. Unfortunately there's no time anymore to wait otherwise the entire musb branch will miss this merge window. I'm sorry -- balbi signature.asc Description: Digital signature
Re: [PATCH] omap-i2c: fix incorrect log message when using a device tree
On Friday 31 August 2012 04:32 PM, Florian Vaussard wrote: > When booting using a device tree, the adapter number is dynamically > assigned after the log message is sent. > This patch modifies the log message to get a correct adapter id. > > Applies on 3.6-rc3. Tested on OMAP3 (Gumstix Overo). > > Signed-off-by: Florian Vaussard Looks good to me. Acked-by: Shubhrajyoti D > --- > drivers/i2c/busses/i2c-omap.c |6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c > index 5d19a49..136b4fe 100644 > --- a/drivers/i2c/busses/i2c-omap.c > +++ b/drivers/i2c/busses/i2c-omap.c > @@ -1064,9 +1064,6 @@ omap_i2c_probe(struct platform_device *pdev) > goto err_unuse_clocks; > } > > - dev_info(dev->dev, "bus %d rev%d.%d.%d at %d kHz\n", pdev->id, > - dev->dtrev, dev->rev >> 4, dev->rev & 0xf, dev->speed); > - > adap = &dev->adapter; > i2c_set_adapdata(adap, dev); > adap->owner = THIS_MODULE; > @@ -1084,6 +1081,9 @@ omap_i2c_probe(struct platform_device *pdev) > goto err_free_irq; > } > > + dev_info(dev->dev, "bus %d rev%d.%d.%d at %d kHz\n", adap->nr, > + dev->dtrev, dev->rev >> 4, dev->rev & 0xf, dev->speed); > + > of_i2c_register_devices(adap); > > pm_runtime_put(dev->dev); -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: OMAP5: Enable arch timer support
Benoit,
On Mon, Sep 10, 2012 at 7:09 PM, Shilimkar, Santosh
wrote:
> On Mon, Sep 10, 2012 at 6:44 PM, Benoit Cousson wrote:
>>
[...]
>> >> Silly question: Don't we have one arch-timer per CPU?
>> >>
>> > It is per CPU just like A9 TWD
>>
>> Shouldn't we have two nodes then?
>>
> I need to check this but arch timer DT node should be same
> as the twd DT node. May be one node with reference to
> each CPU node should do but am not too sure about the DT
> nodes and how all that work.
>
Here is an updated patch based on our discussion. Thanks for comments.
Let me know if you are ok with this version.
>From 98f6a3b4b52ef7c76ed8b19bf9257c51ee5d7323 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar
Date: Mon, 13 Aug 2012 14:39:03 +0530
Subject: [PATCH] ARM: OMAP5: Enable arch timer support
Enable Cortex A15 generic timer support for OMAP5 based SOCs.
The CPU local timers run on the free running real time counter clock.
Signed-off-by: Santosh Shilimkar
---
arch/arm/boot/dts/omap5.dtsi | 12
arch/arm/mach-omap2/Kconfig |1 +
arch/arm/mach-omap2/timer.c |7 +++
3 files changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 57e5270..7b986ed 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -33,9 +33,21 @@
cpus {
cpu@0 {
compatible = "arm,cortex-a15";
+ timer {
+ compatible = "arm,armv7-timer";
+ /* 14th PPI IRQ, active low level-sensitive */
+ interrupts = <1 14 0x308>;
+ clock-frequency = <6144000>;
+ };
};
cpu@1 {
compatible = "arm,cortex-a15";
+ timer {
+ compatible = "arm,armv7-timer";
+ /* 14th PPI IRQ, active low level-sensitive */
+ interrupts = <1 14 0x308>;
+ clock-frequency = <6144000>;
+ };
};
};
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 2120f90..53fb77c 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -73,6 +73,7 @@ config SOC_OMAP5
select ARM_GIC
select HAVE_SMP
select SOC_HAS_REALTIME_COUNTER
+ select ARM_ARCH_TIMER
comment "OMAP Core Type"
depends on ARCH_OMAP2
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 8f5b88b..46982d0 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#include "common.h"
#include
#include
@@ -481,9 +482,15 @@ OMAP_SYS_TIMER(4)
#ifdef CONFIG_SOC_OMAP5
static void __init omap5_timer_init(void)
{
+ int err;
+
omap2_gp_clockevent_init(1, OMAP4_CLKEV_SOURCE);
omap2_clocksource_init(2, OMAP4_MPU_SOURCE);
realtime_counter_init();
+
+ err = arch_timer_of_register();
+ if (err)
+ pr_err("%s: arch_timer_register failed %d\n", __func__, err);
}
OMAP_SYS_TIMER(5)
#endif
--
1.7.9.5
0001-ARM-OMAP5-Enable-arch-timer-support.patch
Description: Binary data
[PATCHv7 00/23]I2C big cleanup
Changes since v1:
- removed tabification on patch 6/17
- removed dev_err() which was introduced on patch 09/17
Changes since v2:
- do not set full fifo depth in the RDR interrupt.
- some changelog updates.
- rebase to the Wolfram's tree.
Changes since v3:
- Remove a redundant read of status register
- Read the dev->buf_len variable instead of the register
as the information of the remaining bytes is there.
Changes since v4:
- Ack the arbitration lost.
- Rebase to the i2c-embedded/for-next branch.
Changes since v5:
- Rebase to latest mainline
- Added some more cleanup patches so as have a consolidated series.
Changes since v6:
- Fix comments on setting the pdev to NULL.
- Trivial changelog update
Previous discussions can be found here
http://www.spinics.net/lists/linux-i2c/msg09482.html
This is the cleanup only series.
Tested on omap4sdp and 3430sdp.
The following changes since commit 55d512e245bc7699a8800e23df1a24195dd08217:
Linux 3.6-rc5 (2012-09-08 16:43:45 -0700)
are available in the git repository at:
git://gitorious.org/linus-tree/linus-tree.git for_3.7/i2c/big_cleanup
Felipe Balbi (22):
i2c: omap: switch to devm_* API
i2c: omap: simplify num_bytes handling
i2c: omap: decrease indentation level on data handling
i2c: omap: add blank lines
i2c: omap: simplify omap_i2c_ack_stat()
i2c: omap: split out [XR]DR and [XR]RDY
i2c: omap: improve i462 errata handling
i2c: omap: re-factor receive/transmit data loop
i2c: omap: switch over to do {} while loop
i2c: omap: ack IRQ in parts
i2c: omap: switch to platform_get_irq()
i2c: omap: bus: add a receiver flag
i2c: omap: simplify errata check
i2c: omap: always return IRQ_HANDLED
i2c: omap: simplify IRQ exit path
i2c: omap: resize fifos before each message
i2c: omap: get rid of the "complete" label
i2c: omap: always return IRQ_HANDLED
i2c: omap: switch to threaded IRQ support
i2c: omap: remove unnecessary pm_runtime_suspended check
i2c: omap: switch over to autosuspend API
i2c: omap: sanitize exit path
Shubhrajyoti D (1):
i2c: omap: remove redundant status read
drivers/i2c/busses/i2c-omap.c | 442 +
1 files changed, 271 insertions(+), 171 deletions(-)
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv7 05/23] i2c: omap: simplify omap_i2c_ack_stat()
From: Felipe Balbi
stat & BIT(1) is the same as BIT(1), so let's
simplify things a bit by removing "stat &" from
all omap_i2c_ack_stat() calls.
Code snippet (extremely simplified):
if (stat & NACK) {
...
omap_i2c_ack_stat(dev, stat & NACK);
}
if (stat & RDR) {
...
omap_i2c_ack_stat(dev, stat & RDR);
}
and so on. The tricky place is only WRT errata handling, for example:
if (*stat & (NACK | AL)) {
omap_i2c_ack_stat(dev, *stat & (XRDY | XDR));
...
}
but in this case, the errata says we must clear XRDY and XDR if that
errata triggers, so if they just got enabled or not, it doesn't matter.
Another tricky place is RDR | RRDY (likewise for XDR | XRDY):
if (stat & (RDR | RRDY)) {
...
omap_i2c_ack_stat(dev, stat & (RDR | RRDY));
}
again here there will be no issues because those IRQs never fire
simultaneously and one will only after after we have handled the
previous, that's because the same FIFO is used anyway and we won't shift
data into FIFO until we tell the IP "hey, I'm done with the FIFO, you
can shift more data"
Signed-off-by: Felipe Balbi
Reviewed-by : Santosh Shilimkar
[Added the explaination from the discurssion to the commit logs]
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 19 ++-
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 30ea63c..f24eae9 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -731,7 +731,7 @@ static int errata_omap3_i462(struct omap_i2c_dev *dev, u16
*stat, int *err)
while (--timeout && !(*stat & OMAP_I2C_STAT_XUDF)) {
if (*stat & (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
- omap_i2c_ack_stat(dev, *stat & (OMAP_I2C_STAT_XRDY |
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
return -ETIMEDOUT;
}
@@ -792,10 +792,11 @@ complete:
*/
if (stat & (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK |
OMAP_I2C_STAT_AL)) {
- omap_i2c_ack_stat(dev, stat &
- (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR |
- OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR |
- OMAP_I2C_STAT_ARDY));
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_RRDY |
+ OMAP_I2C_STAT_RDR |
+ OMAP_I2C_STAT_XRDY |
+ OMAP_I2C_STAT_XDR |
+ OMAP_I2C_STAT_ARDY));
omap_i2c_complete_cmd(dev, err);
return IRQ_HANDLED;
}
@@ -842,8 +843,8 @@ complete:
}
}
}
- omap_i2c_ack_stat(dev,
- stat & (OMAP_I2C_STAT_RRDY |
OMAP_I2C_STAT_RDR));
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_RRDY |
+ OMAP_I2C_STAT_RDR));
continue;
}
@@ -890,8 +891,8 @@ complete:
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
}
- omap_i2c_ack_stat(dev,
- stat & (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_XRDY |
+ OMAP_I2C_STAT_XDR));
continue;
}
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv7 06/23] i2c: omap: split out [XR]DR and [XR]RDY
From: Felipe Balbi
While they do pretty much the same thing, there
are a few peculiarities. Specially WRT erratas,
it's best to split those out and re-factor the
read/write loop to another function which both
cases call.
This last part will be done on another patch.
While at that, also avoid an unncessary register
read since dev->fifo_len will always contain the
correct amount of data to be transferred.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 126 ++---
1 files changed, 92 insertions(+), 34 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index f24eae9..815577b 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -801,36 +801,62 @@ complete:
return IRQ_HANDLED;
}
- if (stat & (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
+ if (stat & OMAP_I2C_STAT_RDR) {
u8 num_bytes = 1;
+ if (dev->fifo_size)
+ num_bytes = dev->buf_len;
+
+ while (num_bytes--) {
+ if (!dev->buf_len) {
+ dev_err(dev->dev,
+ "RDR IRQ while no data"
+ " requested\n");
+ break;
+ }
+
+ w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
+ *dev->buf++ = w;
+ dev->buf_len--;
+
+ /*
+* Data reg in 2430, omap3 and
+* omap4 is 8 bit wide
+*/
+ if (dev->flags &
+ OMAP_I2C_FLAG_16BIT_DATA_REG) {
+ if (dev->buf_len) {
+ *dev->buf++ = w >> 8;
+ dev->buf_len--;
+ }
+ }
+ }
+
if (dev->errata & I2C_OMAP_ERRATA_I207)
i2c_omap_errata_i207(dev, stat);
- if (dev->fifo_size) {
- if (stat & OMAP_I2C_STAT_RRDY)
- num_bytes = dev->fifo_size;
- else/* read RXSTAT on RDR interrupt */
- num_bytes = (omap_i2c_read_reg(dev,
- OMAP_I2C_BUFSTAT_REG)
- >> 8) & 0x3F;
- }
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR);
+ continue;
+ }
+
+ if (stat & OMAP_I2C_STAT_RRDY) {
+ u8 num_bytes = 1;
+
+ if (dev->fifo_size)
+ num_bytes = dev->fifo_size;
+
while (num_bytes--) {
if (!dev->buf_len) {
- if (stat & OMAP_I2C_STAT_RRDY)
- dev_err(dev->dev,
+ dev_err(dev->dev,
"RRDY IRQ while no data"
- " requested\n");
- if (stat & OMAP_I2C_STAT_RDR)
- dev_err(dev->dev,
- "RDR IRQ while no data"
- " requested\n");
+ " requested\n");
break;
}
w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
*dev->buf++ = w;
dev->buf_len--;
+
/*
* Data reg in 2430, omap3 and
* omap4 is 8 bit wide
@@ -843,36 +869,68 @@ complete:
}
}
}
- omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_RRDY |
- OMAP_I2C_STAT_RDR));
+
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RRDY);
continue;
}
- if (stat & (OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR)) {
+
[PATCHv7 04/23] i2c: omap: add blank lines
From: Felipe Balbi
trivial patch to aid readability. No functional
changes.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 0dd647a..30ea63c 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -786,6 +786,7 @@ complete:
dev_err(dev->dev, "Arbitration lost\n");
err |= OMAP_I2C_STAT_AL;
}
+
/*
* ProDB0017052: Clear ARDY bit twice
*/
@@ -798,6 +799,7 @@ complete:
omap_i2c_complete_cmd(dev, err);
return IRQ_HANDLED;
}
+
if (stat & (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
u8 num_bytes = 1;
@@ -844,6 +846,7 @@ complete:
stat & (OMAP_I2C_STAT_RRDY |
OMAP_I2C_STAT_RDR));
continue;
}
+
if (stat & (OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR)) {
u8 num_bytes = 1;
if (dev->fifo_size) {
@@ -891,10 +894,12 @@ complete:
stat & (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
continue;
}
+
if (stat & OMAP_I2C_STAT_ROVR) {
dev_err(dev->dev, "Receive overrun\n");
dev->cmd_err |= OMAP_I2C_STAT_ROVR;
}
+
if (stat & OMAP_I2C_STAT_XUDF) {
dev_err(dev->dev, "Transmit underflow\n");
dev->cmd_err |= OMAP_I2C_STAT_XUDF;
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv7 03/23] i2c: omap: decrease indentation level on data handling
From: Felipe Balbi
The patch intends to decrease the indentation level on the
data handling
by using the fact that else of if (dev->buf_len) is same as
if (!dev->buf_len)
if (dev->buf_len) {
aaa;
} else {
bbb;
break;
}
to
if (!dev->buf_len) {
bbb;
break;
}
aaa;
Hence no functional changes.
Signed-off-by: Felipe Balbi
Reviewed-by : Santosh Shilimkar
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 63 -
1 files changed, 31 insertions(+), 32 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 236cb38..0dd647a 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -813,22 +813,7 @@ complete:
>> 8) & 0x3F;
}
while (num_bytes--) {
- w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
- if (dev->buf_len) {
- *dev->buf++ = w;
- dev->buf_len--;
- /*
-* Data reg in 2430, omap3 and
-* omap4 is 8 bit wide
-*/
- if (dev->flags &
-OMAP_I2C_FLAG_16BIT_DATA_REG) {
- if (dev->buf_len) {
- *dev->buf++ = w >> 8;
- dev->buf_len--;
- }
- }
- } else {
+ if (!dev->buf_len) {
if (stat & OMAP_I2C_STAT_RRDY)
dev_err(dev->dev,
"RRDY IRQ while no data"
@@ -839,6 +824,21 @@ complete:
" requested\n");
break;
}
+
+ w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
+ *dev->buf++ = w;
+ dev->buf_len--;
+ /*
+* Data reg in 2430, omap3 and
+* omap4 is 8 bit wide
+*/
+ if (dev->flags &
+ OMAP_I2C_FLAG_16BIT_DATA_REG) {
+ if (dev->buf_len) {
+ *dev->buf++ = w >> 8;
+ dev->buf_len--;
+ }
+ }
}
omap_i2c_ack_stat(dev,
stat & (OMAP_I2C_STAT_RRDY |
OMAP_I2C_STAT_RDR));
@@ -855,22 +855,7 @@ complete:
& 0x3F;
}
while (num_bytes--) {
- w = 0;
- if (dev->buf_len) {
- w = *dev->buf++;
- dev->buf_len--;
- /*
-* Data reg in 2430, omap3 and
-* omap4 is 8 bit wide
-*/
- if (dev->flags &
-OMAP_I2C_FLAG_16BIT_DATA_REG) {
- if (dev->buf_len) {
- w |= *dev->buf++ << 8;
- dev->buf_len--;
- }
- }
- } else {
+ if (!dev->buf_len) {
if (stat & OMAP_I2C_STAT_XRDY)
dev_err(dev->dev,
"XRDY IRQ while no "
@@ -882,6 +867,20 @@ complete:
break;
}
+ w = *dev->buf++;
+ dev->buf_len--;
+ /*
+* Data reg in 2430, omap3 and
+* omap4 is 8 bit wide
+
[PATCHv7 13/23] i2c: omap: simplify errata check
From: Felipe Balbi omap_i2c_dev is allocated with kzalloc(), so we need not initialize b_hw to zero. Signed-off-by: Felipe Balbi Signed-off-by: Shubhrajyoti D --- drivers/i2c/busses/i2c-omap.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 3be147a..7918e48 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1095,9 +1095,7 @@ omap_i2c_probe(struct platform_device *pdev) dev->fifo_size = (dev->fifo_size / 2); - if (dev->rev >= OMAP_I2C_REV_ON_3630_4430) - dev->b_hw = 0; /* Disable hardware fixes */ - else + if (dev->rev < OMAP_I2C_REV_ON_3630_4430) dev->b_hw = 1; /* Enable hardware fixes */ /* calculate wakeup latency constraint for MPU */ -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv7 07/23] i2c: omap: improve i462 errata handling
From: Felipe Balbi
Make it not depend on ISR's local variables
in order to make it easier to re-factor the
transmit data loop.
Also since we are waiting for XUDF(Transmitter underflow) just before
writing data lets not flag the underflow.
This is anyways going to go once we write
the data.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 43
1 files changed, 30 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 815577b..fb57221 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -725,27 +725,30 @@ omap_i2c_omap1_isr(int this_irq, void *dev_id)
* data to DATA_REG. Otherwise some data bytes can be lost while transferring
* them from the memory to the I2C interface.
*/
-static int errata_omap3_i462(struct omap_i2c_dev *dev, u16 *stat, int *err)
+static int errata_omap3_i462(struct omap_i2c_dev *dev)
{
unsigned long timeout = 1;
+ u16 stat;
- while (--timeout && !(*stat & OMAP_I2C_STAT_XUDF)) {
- if (*stat & (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
+ do {
+ stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
+ if (stat & OMAP_I2C_STAT_XUDF)
+ break;
+
+ if (stat & (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
- return -ETIMEDOUT;
+ return -EIO;
}
cpu_relax();
- *stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
- }
+ } while (--timeout);
if (!timeout) {
dev_err(dev->dev, "timeout waiting on XUDF bit\n");
return 0;
}
- *err |= OMAP_I2C_STAT_XUDF;
return 0;
}
@@ -903,9 +906,16 @@ complete:
}
}
- if ((dev->errata & I2C_OMAP_ERRATA_I462) &&
- errata_omap3_i462(dev, &stat, &err))
- goto complete;
+ if (dev->errata & I2C_OMAP_ERRATA_I462) {
+ int ret;
+
+ ret = errata_omap3_i462(dev);
+ stat = omap_i2c_read_reg(dev,
+ OMAP_I2C_STAT_REG);
+
+ if (ret < 0)
+ goto complete;
+ }
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
}
@@ -943,9 +953,16 @@ complete:
}
}
- if ((dev->errata & I2C_OMAP_ERRATA_I462) &&
- errata_omap3_i462(dev, &stat, &err))
- goto complete;
+ if (dev->errata & I2C_OMAP_ERRATA_I462) {
+ int ret;
+
+ ret = errata_omap3_i462(dev);
+ stat = omap_i2c_read_reg(dev,
+ OMAP_I2C_STAT_REG);
+
+ if (ret < 0)
+ goto complete;
+ }
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
}
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv7 10/23] i2c: omap: ack IRQ in parts
From: Felipe Balbi
According to flow diagrams on OMAP TRMs,
we should ACK the IRQ as they happen.
Signed-off-by: Felipe Balbi
[Ack the stat OMAP_I2C_STAT_AL in case of arbitration lost]
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 28
1 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 4045134..bac1f11 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -850,21 +850,19 @@ omap_i2c_isr(int this_irq, void *dev_id)
}
complete:
- /*
-* Ack the stat in one go, but [R/X]DR and [R/X]RDY should be
-* acked after the data operation is complete.
-* Ref: TRM SWPU114Q Figure 18-31
-*/
- omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat &
- ~(OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR |
- OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR));
-
- if (stat & OMAP_I2C_STAT_NACK)
+ if (stat & OMAP_I2C_STAT_NACK) {
err |= OMAP_I2C_STAT_NACK;
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
+ omap_i2c_complete_cmd(dev, err);
+ return IRQ_HANDLED;
+ }
if (stat & OMAP_I2C_STAT_AL) {
dev_err(dev->dev, "Arbitration lost\n");
err |= OMAP_I2C_STAT_AL;
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_AL);
+ omap_i2c_complete_cmd(dev, err);
+ return IRQ_HANDLED;
}
/*
@@ -941,12 +939,18 @@ complete:
if (stat & OMAP_I2C_STAT_ROVR) {
dev_err(dev->dev, "Receive overrun\n");
- dev->cmd_err |= OMAP_I2C_STAT_ROVR;
+ err |= OMAP_I2C_STAT_ROVR;
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_ROVR);
+ omap_i2c_complete_cmd(dev, err);
+ return IRQ_HANDLED;
}
if (stat & OMAP_I2C_STAT_XUDF) {
dev_err(dev->dev, "Transmit underflow\n");
- dev->cmd_err |= OMAP_I2C_STAT_XUDF;
+ err |= OMAP_I2C_STAT_XUDF;
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XUDF);
+ omap_i2c_complete_cmd(dev, err);
+ return IRQ_HANDLED;
}
} while (stat);
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv7 09/23] i2c: omap: switch over to do {} while loop
From: Felipe Balbi
this will make sure that we execute at least once.
No functional changes otherwise.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 20 ++--
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 2c7d7cc..4045134 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -827,20 +827,28 @@ omap_i2c_isr(int this_irq, void *dev_id)
struct omap_i2c_dev *dev = dev_id;
u16 bits;
u16 stat;
- int err, count = 0;
+ int err = 0, count = 0;
if (pm_runtime_suspended(dev->dev))
return IRQ_NONE;
- bits = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
- while ((stat = (omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG))) & bits) {
+ do {
+ bits = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
+ stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
+ stat &= bits;
+
+ if (!stat) {
+ /* my work here is done */
+ return IRQ_HANDLED;
+ }
+
dev_dbg(dev->dev, "IRQ (ISR = 0x%04x)\n", stat);
if (count++ == 100) {
dev_warn(dev->dev, "Too much work in one IRQ\n");
- break;
+ omap_i2c_complete_cmd(dev, err);
+ return IRQ_HANDLED;
}
- err = 0;
complete:
/*
* Ack the stat in one go, but [R/X]DR and [R/X]RDY should be
@@ -940,7 +948,7 @@ complete:
dev_err(dev->dev, "Transmit underflow\n");
dev->cmd_err |= OMAP_I2C_STAT_XUDF;
}
- }
+ } while (stat);
return count ? IRQ_HANDLED : IRQ_NONE;
}
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv7 11/23] i2c: omap: switch to platform_get_irq()
From: Felipe Balbi
that's a nice helper from drivers core which
will give us the exact IRQ number, instead
of a pointer to an IRQ resource.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index bac1f11..0da8169 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -993,11 +993,12 @@ omap_i2c_probe(struct platform_device *pdev)
{
struct omap_i2c_dev *dev;
struct i2c_adapter *adap;
- struct resource *mem, *irq;
+ struct resource *mem;
struct omap_i2c_bus_platform_data *pdata = pdev->dev.platform_data;
struct device_node *node = pdev->dev.of_node;
const struct of_device_id *match;
irq_handler_t isr;
+ int irq;
int r;
/* NOTE: driver uses the static register mapping */
@@ -1006,10 +1007,11 @@ omap_i2c_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "no mem resource?\n");
return -ENODEV;
}
- irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (!irq) {
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0) {
dev_err(&pdev->dev, "no irq resource?\n");
- return -ENODEV;
+ return irq;
}
dev = devm_kzalloc(&pdev->dev, sizeof(struct omap_i2c_dev), GFP_KERNEL);
@@ -1043,7 +1045,7 @@ omap_i2c_probe(struct platform_device *pdev)
}
dev->dev = &pdev->dev;
- dev->irq = irq->start;
+ dev->irq = irq;
platform_set_drvdata(pdev, dev);
init_completion(&dev->cmd_complete);
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv7 14/23] i2c: omap: always return IRQ_HANDLED
From: Felipe Balbi
Always return IRQ_HANDLED otherwise we could get our IRQ line disabled due
to many spurious IRQs.
Signed-off-by: Felipe Balbi
[Trivial changes to commitlogs]
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 7918e48..96fd528 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -962,7 +962,7 @@ complete:
}
} while (stat);
- return count ? IRQ_HANDLED : IRQ_NONE;
+ return IRQ_HANDLED;
}
static const struct i2c_algorithm omap_i2c_algo = {
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv7 08/23] i2c: omap: re-factor receive/transmit data loop
From: Felipe Balbi
re-factor the common parts to a separate function,
so that code is easier to read and understand.
No functional changes.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 204
1 files changed, 82 insertions(+), 122 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index fb57221..2c7d7cc 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -752,12 +752,81 @@ static int errata_omap3_i462(struct omap_i2c_dev *dev)
return 0;
}
+static void omap_i2c_receive_data(struct omap_i2c_dev *dev, u8 num_bytes,
+ bool is_rdr)
+{
+ u16 w;
+
+ while (num_bytes--) {
+ if (!dev->buf_len) {
+ dev_err(dev->dev, "%s without data",
+ is_rdr ? "RDR" : "RRDY");
+ break;
+ }
+
+ w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
+ *dev->buf++ = w;
+ dev->buf_len--;
+
+ /*
+* Data reg in 2430, omap3 and
+* omap4 is 8 bit wide
+*/
+ if (dev->flags & OMAP_I2C_FLAG_16BIT_DATA_REG) {
+ if (dev->buf_len) {
+ *dev->buf++ = w >> 8;
+ dev->buf_len--;
+ }
+ }
+ }
+}
+
+static int omap_i2c_transmit_data(struct omap_i2c_dev *dev, u8 num_bytes,
+ bool is_xdr)
+{
+ u16 w;
+
+ while (num_bytes--) {
+ if (!dev->buf_len) {
+ dev_err(dev->dev, "%s without data",
+ is_xdr ? "XDR" : "XRDY");
+ break;
+ }
+
+ w = *dev->buf++;
+ dev->buf_len--;
+
+ /*
+* Data reg in 2430, omap3 and
+* omap4 is 8 bit wide
+*/
+ if (dev->flags & OMAP_I2C_FLAG_16BIT_DATA_REG) {
+ if (dev->buf_len) {
+ w |= *dev->buf++ << 8;
+ dev->buf_len--;
+ }
+ }
+
+ if (dev->errata & I2C_OMAP_ERRATA_I462) {
+ int ret;
+
+ ret = errata_omap3_i462(dev);
+ if (ret < 0)
+ return ret;
+ }
+
+ omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
+ }
+
+ return 0;
+}
+
static irqreturn_t
omap_i2c_isr(int this_irq, void *dev_id)
{
struct omap_i2c_dev *dev = dev_id;
u16 bits;
- u16 stat, w;
+ u16 stat;
int err, count = 0;
if (pm_runtime_suspended(dev->dev))
@@ -810,30 +879,7 @@ complete:
if (dev->fifo_size)
num_bytes = dev->buf_len;
- while (num_bytes--) {
- if (!dev->buf_len) {
- dev_err(dev->dev,
- "RDR IRQ while no data"
- " requested\n");
- break;
- }
-
- w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
- *dev->buf++ = w;
- dev->buf_len--;
-
- /*
-* Data reg in 2430, omap3 and
-* omap4 is 8 bit wide
-*/
- if (dev->flags &
- OMAP_I2C_FLAG_16BIT_DATA_REG) {
- if (dev->buf_len) {
- *dev->buf++ = w >> 8;
- dev->buf_len--;
- }
- }
- }
+ omap_i2c_receive_data(dev, num_bytes, true);
if (dev->errata & I2C_OMAP_ERRATA_I207)
i2c_omap_errata_i207(dev, stat);
@@ -848,77 +894,22 @@ complete:
if (dev->fifo_size)
num_bytes = dev->fifo_size;
- while (num_bytes--) {
- if (!dev->buf_len) {
- dev_err(dev->dev,
- "RRDY IRQ while no data"
- " requested\n");
- break;
- }
-
-
[PATCHv7 01/23] i2c: omap: switch to devm_* API
From: Felipe Balbi
that helps deleting some boiler plate code
and lets driver-core manage our resources
for us.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 41 -
1 files changed, 12 insertions(+), 29 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 5d19a49..2d9b03c 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -943,7 +943,7 @@ omap_i2c_probe(struct platform_device *pdev)
{
struct omap_i2c_dev *dev;
struct i2c_adapter *adap;
- struct resource *mem, *irq, *ioarea;
+ struct resource *mem, *irq;
struct omap_i2c_bus_platform_data *pdata = pdev->dev.platform_data;
struct device_node *node = pdev->dev.of_node;
const struct of_device_id *match;
@@ -962,17 +962,16 @@ omap_i2c_probe(struct platform_device *pdev)
return -ENODEV;
}
- ioarea = request_mem_region(mem->start, resource_size(mem),
- pdev->name);
- if (!ioarea) {
- dev_err(&pdev->dev, "I2C region already claimed\n");
- return -EBUSY;
+ dev = devm_kzalloc(&pdev->dev, sizeof(struct omap_i2c_dev), GFP_KERNEL);
+ if (!dev) {
+ dev_err(&pdev->dev, "Menory allocation failed\n");
+ return -ENOMEM;
}
- dev = kzalloc(sizeof(struct omap_i2c_dev), GFP_KERNEL);
- if (!dev) {
- r = -ENOMEM;
- goto err_release_region;
+ dev->base = devm_request_and_ioremap(&pdev->dev, mem);
+ if (!dev->base) {
+ dev_err(&pdev->dev, "I2C region already claimed\n");
+ return -ENOMEM;
}
match = of_match_device(of_match_ptr(omap_i2c_of_match), &pdev->dev);
@@ -995,11 +994,6 @@ omap_i2c_probe(struct platform_device *pdev)
dev->dev = &pdev->dev;
dev->irq = irq->start;
- dev->base = ioremap(mem->start, resource_size(mem));
- if (!dev->base) {
- r = -ENOMEM;
- goto err_free_mem;
- }
platform_set_drvdata(pdev, dev);
init_completion(&dev->cmd_complete);
@@ -1057,7 +1051,8 @@ omap_i2c_probe(struct platform_device *pdev)
isr = (dev->rev < OMAP_I2C_OMAP1_REV_2) ? omap_i2c_omap1_isr :
omap_i2c_isr;
- r = request_irq(dev->irq, isr, IRQF_NO_SUSPEND, pdev->name, dev);
+ r = devm_request_irq(&pdev->dev, dev->irq, isr, IRQF_NO_SUSPEND,
+pdev->name, dev);
if (r) {
dev_err(dev->dev, "failure requesting irq %i\n", dev->irq);
@@ -1081,7 +1076,7 @@ omap_i2c_probe(struct platform_device *pdev)
r = i2c_add_numbered_adapter(adap);
if (r) {
dev_err(dev->dev, "failure adding adapter\n");
- goto err_free_irq;
+ goto err_unuse_clocks;
}
of_i2c_register_devices(adap);
@@ -1090,18 +1085,12 @@ omap_i2c_probe(struct platform_device *pdev)
return 0;
-err_free_irq:
- free_irq(dev->irq, dev);
err_unuse_clocks:
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(dev->dev);
- iounmap(dev->base);
pm_runtime_disable(&pdev->dev);
err_free_mem:
platform_set_drvdata(pdev, NULL);
- kfree(dev);
-err_release_region:
- release_mem_region(mem->start, resource_size(mem));
return r;
}
@@ -1109,12 +1098,10 @@ err_release_region:
static int __devexit omap_i2c_remove(struct platform_device *pdev)
{
struct omap_i2c_dev *dev = platform_get_drvdata(pdev);
- struct resource *mem;
int ret;
platform_set_drvdata(pdev, NULL);
- free_irq(dev->irq, dev);
i2c_del_adapter(&dev->adapter);
ret = pm_runtime_get_sync(&pdev->dev);
if (IS_ERR_VALUE(ret))
@@ -1123,10 +1110,6 @@ static int __devexit omap_i2c_remove(struct
platform_device *pdev)
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(&pdev->dev);
pm_runtime_disable(&pdev->dev);
- iounmap(dev->base);
- kfree(dev);
- mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- release_mem_region(mem->start, resource_size(mem));
return 0;
}
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv7 16/23] i2c: omap: resize fifos before each message
From: Felipe Balbi
This patch will try to avoid the usage of
draining feature by reconfiguring the FIFO
the start condition of each message based
on the message's size.
By doing that, we will be better utilizing
the FIFO when doing big transfers.
While at that also drop the now unneeded
check for dev->buf_len as we always know
the amount of data to be transmitted.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 83 +
1 files changed, 51 insertions(+), 32 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 4af123f..f33bc5a 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -193,6 +193,7 @@ struct omap_i2c_dev {
u8 *regs;
size_t buf_len;
struct i2c_adapter adapter;
+ u8 threshold;
u8 fifo_size; /* use as flag and value
* fifo_size==0 implies no fifo
* if set, should be trsh+1
@@ -418,13 +419,6 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, scll);
omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, sclh);
- if (dev->fifo_size) {
- /* Note: setup required fifo size - 1. RTRSH and XTRSH */
- buf = (dev->fifo_size - 1) << 8 | OMAP_I2C_BUF_RXFIF_CLR |
- (dev->fifo_size - 1) | OMAP_I2C_BUF_TXFIF_CLR;
- omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, buf);
- }
-
/* Take the I2C module out of reset: */
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
@@ -462,6 +456,45 @@ static int omap_i2c_wait_for_bb(struct omap_i2c_dev *dev)
return 0;
}
+static void omap_i2c_resize_fifo(struct omap_i2c_dev *dev, u8 size, bool is_rx)
+{
+ u16 buf;
+
+ if (dev->flags & OMAP_I2C_FLAG_NO_FIFO)
+ return;
+
+ /*
+* Set up notification threshold based on message size. We're doing
+* this to try and avoid draining feature as much as possible. Whenever
+* we have big messages to transfer (bigger than our total fifo size)
+* then we might use draining feature to transfer the remaining bytes.
+*/
+
+ dev->threshold = clamp(size, (u8) 1, dev->fifo_size);
+
+ buf = omap_i2c_read_reg(dev, OMAP_I2C_BUF_REG);
+
+ if (is_rx) {
+ /* Clear RX Threshold */
+ buf &= ~(0x3f << 8);
+ buf |= ((dev->threshold - 1) << 8) | OMAP_I2C_BUF_RXFIF_CLR;
+ } else {
+ /* Clear TX Threshold */
+ buf &= ~0x3f;
+ buf |= (dev->threshold - 1) | OMAP_I2C_BUF_TXFIF_CLR;
+ }
+
+ omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, buf);
+
+ if (dev->rev < OMAP_I2C_REV_ON_3630_4430)
+ dev->b_hw = 1; /* Enable hardware fixes */
+
+ /* calculate wakeup latency constraint for MPU */
+ if (dev->set_mpu_wkup_lat != NULL)
+ dev->latency = (100 * dev->threshold) /
+ (1000 * dev->speed / 8);
+}
+
/*
* Low level master read/write transaction.
*/
@@ -478,6 +511,9 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
if (msg->len == 0)
return -EINVAL;
+ dev->receiver = !!(msg->flags & I2C_M_RD);
+ omap_i2c_resize_fifo(dev, msg->len, dev->receiver);
+
omap_i2c_write_reg(dev, OMAP_I2C_SA_REG, msg->addr);
/* REVISIT: Could the STB bit of I2C_CON be used with probing? */
@@ -493,7 +529,6 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
INIT_COMPLETION(dev->cmd_complete);
dev->cmd_err = 0;
- dev->receiver = !!(msg->flags & I2C_M_RD);
w = OMAP_I2C_CON_EN | OMAP_I2C_CON_MST | OMAP_I2C_CON_STT;
@@ -760,12 +795,6 @@ static void omap_i2c_receive_data(struct omap_i2c_dev
*dev, u8 num_bytes,
u16 w;
while (num_bytes--) {
- if (!dev->buf_len) {
- dev_err(dev->dev, "%s without data",
- is_rdr ? "RDR" : "RRDY");
- break;
- }
-
w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
*dev->buf++ = w;
dev->buf_len--;
@@ -775,10 +804,8 @@ static void omap_i2c_receive_data(struct omap_i2c_dev
*dev, u8 num_bytes,
* omap4 is 8 bit wide
*/
if (dev->flags & OMAP_I2C_FLAG_16BIT_DATA_REG) {
- if (dev->buf_len) {
- *dev->buf++ = w >> 8;
- dev->buf_len--;
- }
+ *dev->buf++ = w >> 8;
+ dev->buf_len--;
}
[PATCHv7 19/23] i2c: omap: always return IRQ_HANDLED
From: Felipe Balbi
even if our clocks are disabled, we still
handled the IRQ, so we should return IRQ_HANDLED.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 498a462..4a696bd 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -862,7 +862,7 @@ omap_i2c_isr(int this_irq, void *dev_id)
int err = 0, count = 0;
if (pm_runtime_suspended(dev->dev))
- return IRQ_NONE;
+ return IRQ_HANDLED;
do {
bits = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv7 20/23] i2c: omap: switch to threaded IRQ support
From: Felipe Balbi
for OMAP2, we can easily switch over to threaded
IRQs on the I2C driver. This will allow us to
spend less time in hardirq context.
Signed-off-by: Felipe Balbi
[Trivial formating changes]
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 43 +++-
1 files changed, 37 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 4a696bd..e391370 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -176,6 +176,7 @@ enum {
#define I2C_OMAP_ERRATA_I462 (1 << 1)
struct omap_i2c_dev {
+ spinlock_t lock; /* IRQ synchronization */
struct device *dev;
void __iomem*base; /* virtual */
int irq;
@@ -854,9 +855,30 @@ static int omap_i2c_transmit_data(struct omap_i2c_dev
*dev, u8 num_bytes,
}
static irqreturn_t
-omap_i2c_isr(int this_irq, void *dev_id)
+omap_i2c_isr(int irq, void *dev_id)
{
struct omap_i2c_dev *dev = dev_id;
+ irqreturn_t ret = IRQ_HANDLED;
+ u16 mask;
+ u16 stat;
+
+ spin_lock(&dev->lock);
+ mask = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
+ stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
+
+ if (stat & mask)
+ ret = IRQ_WAKE_THREAD;
+
+ spin_unlock(&dev->lock);
+
+ return ret;
+}
+
+static irqreturn_t
+omap_i2c_isr_thread(int this_irq, void *dev_id)
+{
+ struct omap_i2c_dev *dev = dev_id;
+ unsigned long flags;
u16 bits;
u16 stat;
int err = 0, count = 0;
@@ -864,6 +886,7 @@ omap_i2c_isr(int this_irq, void *dev_id)
if (pm_runtime_suspended(dev->dev))
return IRQ_HANDLED;
+ spin_lock_irqsave(&dev->lock, flags);
do {
bits = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
@@ -877,6 +900,7 @@ omap_i2c_isr(int this_irq, void *dev_id)
if (!stat) {
/* my work here is done */
+ spin_unlock_irqrestore(&dev->lock, flags);
return IRQ_HANDLED;
}
@@ -985,6 +1009,8 @@ omap_i2c_isr(int this_irq, void *dev_id)
out:
omap_i2c_complete_cmd(dev, err);
+ spin_unlock_irqrestore(&dev->lock, flags);
+
return IRQ_HANDLED;
}
@@ -1028,7 +1054,6 @@ omap_i2c_probe(struct platform_device *pdev)
struct omap_i2c_bus_platform_data *pdata = pdev->dev.platform_data;
struct device_node *node = pdev->dev.of_node;
const struct of_device_id *match;
- irq_handler_t isr;
int irq;
int r;
@@ -1078,6 +1103,8 @@ omap_i2c_probe(struct platform_device *pdev)
dev->dev = &pdev->dev;
dev->irq = irq;
+ spin_lock_init(&dev->lock);
+
platform_set_drvdata(pdev, dev);
init_completion(&dev->cmd_complete);
@@ -1130,10 +1157,14 @@ omap_i2c_probe(struct platform_device *pdev)
/* reset ASAP, clearing any IRQs */
omap_i2c_init(dev);
- isr = (dev->rev < OMAP_I2C_OMAP1_REV_2) ? omap_i2c_omap1_isr :
- omap_i2c_isr;
- r = devm_request_irq(&pdev->dev, dev->irq, isr, IRQF_NO_SUSPEND,
-pdev->name, dev);
+ if (dev->rev < OMAP_I2C_OMAP1_REV_2)
+ r = devm_request_irq(&pdev->dev, dev->irq, omap_i2c_omap1_isr,
+ IRQF_NO_SUSPEND, pdev->name, dev);
+ else
+ r = devm_request_threaded_irq(&pdev->dev, dev->irq,
+ omap_i2c_isr, omap_i2c_isr_thread,
+ IRQF_NO_SUSPEND | IRQF_ONESHOT,
+ pdev->name, dev);
if (r) {
dev_err(dev->dev, "failure requesting irq %i\n", dev->irq);
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv7 12/23] i2c: omap: bus: add a receiver flag
From: Felipe Balbi
that way we can ignore TX IRQs while in receiver
mode and ignore RX IRQs while in transmitter mode.
Signed-off-by: Felipe Balbi
[Remove unnecessary braces]
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 0da8169..3be147a 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -199,6 +199,7 @@ struct omap_i2c_dev {
*/
u8 rev;
unsignedb_hw:1; /* bad h/w fixes */
+ unsignedreceiver:1; /* true when we're in receiver
mode */
u16 iestate;/* Saved interrupt register */
u16 pscstate;
u16 scllstate;
@@ -492,6 +493,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
INIT_COMPLETION(dev->cmd_complete);
dev->cmd_err = 0;
+ dev->receiver = !!(msg->flags & I2C_M_RD);
w = OMAP_I2C_CON_EN | OMAP_I2C_CON_MST | OMAP_I2C_CON_STT;
@@ -837,6 +839,12 @@ omap_i2c_isr(int this_irq, void *dev_id)
stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
stat &= bits;
+ /* If we're in receiver mode, ignore XDR/XRDY */
+ if (dev->receiver)
+ stat &= ~(OMAP_I2C_STAT_XDR | OMAP_I2C_STAT_XRDY);
+ else
+ stat &= ~(OMAP_I2C_STAT_RDR | OMAP_I2C_STAT_RRDY);
+
if (!stat) {
/* my work here is done */
return IRQ_HANDLED;
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv7 18/23] i2c: omap: remove redundant status read
Remove the redundant read of the status register. Signed-off-by: Shubhrajyoti D --- drivers/i2c/busses/i2c-omap.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 5d4bad4..498a462 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -946,7 +946,6 @@ omap_i2c_isr(int this_irq, void *dev_id) num_bytes = dev->buf_len; ret = omap_i2c_transmit_data(dev, num_bytes, true); - stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG); if (ret < 0) goto out; @@ -962,7 +961,6 @@ omap_i2c_isr(int this_irq, void *dev_id) num_bytes = dev->threshold; ret = omap_i2c_transmit_data(dev, num_bytes, false); - stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG); if (ret < 0) goto out; -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv7 21/23] i2c: omap: remove unnecessary pm_runtime_suspended check
From: Felipe Balbi
before starting any messages we call pm_runtime_get_sync()
which will make sure that by the time we program a transfer
and our IRQ handler gets called, we're not suspended
anymore.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index e391370..6d38a57 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -883,9 +883,6 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
u16 stat;
int err = 0, count = 0;
- if (pm_runtime_suspended(dev->dev))
- return IRQ_HANDLED;
-
spin_lock_irqsave(&dev->lock, flags);
do {
bits = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv7 23/23] i2c: omap: sanitize exit path
From: Felipe Balbi
move the goto out label one line down, so that
it can be used when stat is read as zero. All
other exits, can be done with a break statement.
While at that, also break out as soon as we
complete draining IRQ, since at that time
we know we transferred everything there was
to be transferred.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 26 +-
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 122f517..b149e32 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -901,27 +901,26 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
if (!stat) {
/* my work here is done */
- spin_unlock_irqrestore(&dev->lock, flags);
- return IRQ_HANDLED;
+ goto out;
}
dev_dbg(dev->dev, "IRQ (ISR = 0x%04x)\n", stat);
if (count++ == 100) {
dev_warn(dev->dev, "Too much work in one IRQ\n");
- goto out;
+ break;
}
if (stat & OMAP_I2C_STAT_NACK) {
err |= OMAP_I2C_STAT_NACK;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
- goto out;
+ break;
}
if (stat & OMAP_I2C_STAT_AL) {
dev_err(dev->dev, "Arbitration lost\n");
err |= OMAP_I2C_STAT_AL;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_AL);
- goto out;
+ break;
}
/*
@@ -934,7 +933,7 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR |
OMAP_I2C_STAT_ARDY));
- goto out;
+ break;
}
if (stat & OMAP_I2C_STAT_RDR) {
@@ -949,7 +948,7 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
i2c_omap_errata_i207(dev, stat);
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR);
- continue;
+ break;
}
if (stat & OMAP_I2C_STAT_RRDY) {
@@ -972,10 +971,10 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
ret = omap_i2c_transmit_data(dev, num_bytes, true);
if (ret < 0)
- goto out;
+ break;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XDR);
- continue;
+ break;
}
if (stat & OMAP_I2C_STAT_XRDY) {
@@ -987,7 +986,7 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
ret = omap_i2c_transmit_data(dev, num_bytes, false);
if (ret < 0)
- goto out;
+ break;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XRDY);
continue;
@@ -997,19 +996,20 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
dev_err(dev->dev, "Receive overrun\n");
err |= OMAP_I2C_STAT_ROVR;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_ROVR);
- goto out;
+ break;
}
if (stat & OMAP_I2C_STAT_XUDF) {
dev_err(dev->dev, "Transmit underflow\n");
err |= OMAP_I2C_STAT_XUDF;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XUDF);
- goto out;
+ break;
}
} while (stat);
-out:
omap_i2c_complete_cmd(dev, err);
+
+out:
spin_unlock_irqrestore(&dev->lock, flags);
return IRQ_HANDLED;
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv7 22/23] i2c: omap: switch over to autosuspend API
From: Felipe Balbi
this helps us reduce unnecessary pm transitions
in case we have another i2c message starting soon.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 6d38a57..122f517 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -55,6 +55,9 @@
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
+/* timeout for pm runtime autosuspend */
+#define OMAP_I2C_PM_TIMEOUT1000/* ms */
+
/* For OMAP3 I2C_IV has changed to I2C_WE (wakeup enable) */
enum {
OMAP_I2C_REV_REG = 0,
@@ -645,7 +648,8 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
omap_i2c_wait_for_bb(dev);
out:
- pm_runtime_put(dev->dev);
+ pm_runtime_mark_last_busy(dev->dev);
+ pm_runtime_put_autosuspend(dev->dev);
return r;
}
@@ -1113,6 +1117,9 @@ omap_i2c_probe(struct platform_device *pdev)
dev->regs = (u8 *)reg_map_ip_v1;
pm_runtime_enable(dev->dev);
+ pm_runtime_set_autosuspend_delay(dev->dev, OMAP_I2C_PM_TIMEOUT);
+ pm_runtime_use_autosuspend(dev->dev);
+
r = pm_runtime_get_sync(dev->dev);
if (IS_ERR_VALUE(r))
goto err_free_mem;
@@ -1190,7 +1197,8 @@ omap_i2c_probe(struct platform_device *pdev)
of_i2c_register_devices(adap);
- pm_runtime_put(dev->dev);
+ pm_runtime_mark_last_busy(dev->dev);
+ pm_runtime_put_autosuspend(dev->dev);
return 0;
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv7 15/23] i2c: omap: simplify IRQ exit path
From: Felipe Balbi
instead of having multiple return points, use
a goto statement to make that clearer.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 20
1 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 96fd528..4af123f 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -853,24 +853,21 @@ omap_i2c_isr(int this_irq, void *dev_id)
dev_dbg(dev->dev, "IRQ (ISR = 0x%04x)\n", stat);
if (count++ == 100) {
dev_warn(dev->dev, "Too much work in one IRQ\n");
- omap_i2c_complete_cmd(dev, err);
- return IRQ_HANDLED;
+ goto out;
}
complete:
if (stat & OMAP_I2C_STAT_NACK) {
err |= OMAP_I2C_STAT_NACK;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
- omap_i2c_complete_cmd(dev, err);
- return IRQ_HANDLED;
+ goto out;
}
if (stat & OMAP_I2C_STAT_AL) {
dev_err(dev->dev, "Arbitration lost\n");
err |= OMAP_I2C_STAT_AL;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_AL);
- omap_i2c_complete_cmd(dev, err);
- return IRQ_HANDLED;
+ goto out;
}
/*
@@ -883,8 +880,7 @@ complete:
OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR |
OMAP_I2C_STAT_ARDY));
- omap_i2c_complete_cmd(dev, err);
- return IRQ_HANDLED;
+ goto out;
}
if (stat & OMAP_I2C_STAT_RDR) {
@@ -949,19 +945,19 @@ complete:
dev_err(dev->dev, "Receive overrun\n");
err |= OMAP_I2C_STAT_ROVR;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_ROVR);
- omap_i2c_complete_cmd(dev, err);
- return IRQ_HANDLED;
+ goto out;
}
if (stat & OMAP_I2C_STAT_XUDF) {
dev_err(dev->dev, "Transmit underflow\n");
err |= OMAP_I2C_STAT_XUDF;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XUDF);
- omap_i2c_complete_cmd(dev, err);
- return IRQ_HANDLED;
+ goto out;
}
} while (stat);
+out:
+ omap_i2c_complete_cmd(dev, err);
return IRQ_HANDLED;
}
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv7 17/23] i2c: omap: get rid of the "complete" label
From: Felipe Balbi
we can ack stat and complete the command from
the errata handling itself.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index f33bc5a..5d4bad4 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -775,6 +775,17 @@ static int errata_omap3_i462(struct omap_i2c_dev *dev)
if (stat & (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
+ if (stat & OMAP_I2C_STAT_NACK) {
+ dev->cmd_err |= OMAP_I2C_STAT_NACK;
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
+ }
+
+ if (stat & OMAP_I2C_STAT_AL) {
+ dev_err(dev->dev, "Arbitration lost\n");
+ dev->cmd_err |= OMAP_I2C_STAT_AL;
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
+ }
+
return -EIO;
}
@@ -875,7 +886,6 @@ omap_i2c_isr(int this_irq, void *dev_id)
goto out;
}
-complete:
if (stat & OMAP_I2C_STAT_NACK) {
err |= OMAP_I2C_STAT_NACK;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
@@ -938,7 +948,7 @@ complete:
ret = omap_i2c_transmit_data(dev, num_bytes, true);
stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
if (ret < 0)
- goto complete;
+ goto out;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XDR);
continue;
@@ -954,7 +964,7 @@ complete:
ret = omap_i2c_transmit_data(dev, num_bytes, false);
stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
if (ret < 0)
- goto complete;
+ goto out;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XRDY);
continue;
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv7 02/23] i2c: omap: simplify num_bytes handling
From: Felipe Balbi
trivial patch, no functional changes
If the fifo is disabled or fifo_size is 0 the num_bytes
is set to 1. Else it is set to fifo_size or in case of a
draining interrupt the remaining bytes in the buff stat.
So the zero check is redundant and can be safely optimised.
Signed-off-by: Felipe Balbi
Reviewed-by : Santosh Shilimkar
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 2d9b03c..236cb38 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -812,8 +812,7 @@ complete:
OMAP_I2C_BUFSTAT_REG)
>> 8) & 0x3F;
}
- while (num_bytes) {
- num_bytes--;
+ while (num_bytes--) {
w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
if (dev->buf_len) {
*dev->buf++ = w;
@@ -855,8 +854,7 @@ complete:
OMAP_I2C_BUFSTAT_REG)
& 0x3F;
}
- while (num_bytes) {
- num_bytes--;
+ while (num_bytes--) {
w = 0;
if (dev->buf_len) {
w = *dev->buf++;
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/29] Move OMAP2+ over to use COMMON clock
On 9/11/2012 12:05 PM, Paul Walmsley wrote: > > Hi Rajendra, > > A CCF testing branch has been built here. The base is v3.6-rc5, plus the > most recent version of the Common Clock Framework preparation patches that > you posted to the list, "[PATCH v4 0/3] Prepare for OMAP2+ movement to > Common Clk", but updated to take RMK's feedback into account. Then the > 'clk-next-omap-3.6-rc3' branch from your repo at > 'git://github.com/rrnayak/linux.git' was added. Then some patches to drop > the old arch/arm/mach-omap2/clock*_data.c files were added. > > This branch was then run through checkpatch.pl, and all of the parenthesis > alignment warnings have been fixed. I don't know what to do about these > crazy DECLARE_CLK_* macros; they have so many arguments that they are > basically impossible to read. Mike and I discussed converting them > into C99 structure initializers with named fields, but am not sure if it's > a readability advantage; it's probably going to be "write-only data" > either way. I've reflowed many of them to save diffstat but there are > quite a few more to go. > > The branch was then built with a set of testing Kconfigs. Here's what was > found: (these are still being investigated) > > - The OMAP4-only testconfig and rmk's OMAP4430-SDP Kconfigs failed: > "undefined reference to `omap2_clkt_iclk_allow_idle'": > > > http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/build/omap4_testconfig/ > > http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/build/rmk_omap4430_sdp_oldconfig/ > > - RMK's OMAP3430-LDP Kconfig failed with a whole set of warnings: > > > http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/build/rmk_omap3430_ldp_oldconfig/ > > > The kernel built with omap2plus_defconfig was then booted on several > OMAP2+ boards. Here's what was found: > > - The kernel wouldn't boot on either the 3517EVM nor CM-T3517 boards. > This turned out to be due to some missing AM35XX clkdev aliases, the > lack of which cause the CCF code to panic. The patch that adds the > OMAP3 data has been updated to fix that bug and an HSOTGUSB clkdev > alias bug that was found by visual inspection. > > - The 3730 Beagle XM issued a warning and stack trace upon boot. > Debugging with Mike, this turned out to be due to a bug in the > modified omap2_init_clksel_parent() function: it returned a register > bitfield rather than an array index. The patch that modifies this > function was then updated to fix the bug. > > - The 2420 N800 seems to have some kind of MMC-related problem > that prevents it from booting. Still looking into this: > > > http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/2420n800/2420n800_log.txt > > > Then the branch was PM-tested to determine whether it can suspend and > serial-resume properly, and whether dynamic idle works. These tests > didn't go so well: > > - 3530ES3 Beagleboard here was able to enter retention-idle > suspend, and leave it with serial wakeup, but the CORE powerdomain never > entered a low-power state. Dynamic retention-idle with serial wakeup > never resumed, and the test stopped there: > > > http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/3530es3beagle/3530es3beagle_log.txt > > - 37xx EVM and 3730 Beagle XM fared better; they made it through the whole > test program, but the CORE powerdomain also never entered a low-power > state: > > > http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/37xxevm/37xxevm_log.txt > > http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/3730beaglexm/3730beaglexm_log.txt > > - 4430ES2 Panda never made past the first retention-idle suspend: > > > http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/4430es2panda/4430es2panda_log.txt > > > Could you please take a look and see if you can identify why the patches > aren't passing the tests? I can't send these upstream until they pass the > PM tests. > > This testing branch can be found at the branch named > "common_clk_testing_devel_3.7" of git://git.pwsan.com/linux-2.6 > > The testbed reports from this branch can be found here: > > > http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/ > > And the baseline test reports from v3.6-rc5 can be found here: > >http://www.pwsan.com/omap/testlogs/test_v3.6-rc5/20120908202511/ > I tried this branch on BeagleBone platform and needs one small typo correction in hwmod data patch (submitted earlier, which you are going to queue it) diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c index de7a3ab..767a77d 100644 --- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c @@ -14
Re: [PATCH v2 3/3] usb: musb: omap: Add device tree support for omap musb glue
On 9/11/2012 2:39 PM, Kishon Vijay Abraham I wrote:
> Added device tree support for omap musb driver and updated the
> Documentation with device tree binding information.
>
> Signed-off-by: Kishon Vijay Abraham I
> ---
> Documentation/devicetree/bindings/usb/omap-usb.txt | 33
> drivers/usb/musb/omap2430.c| 54
>
> 2 files changed, 87 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt
>
> diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
> b/Documentation/devicetree/bindings/usb/omap-usb.txt
> new file mode 100644
> index 000..29a043e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
> @@ -0,0 +1,33 @@
> +OMAP GLUE
> +
> +OMAP MUSB GLUE
> + - compatible : Should be "ti,omap4-musb" or "ti,omap3-musb"
> + - ti,hwmods : must be "usb_otg_hs"
> + - multipoint : Should be "1" indicating the musb controller supports
> + multipoint. This is a MUSB configuration-specific setting.
> + - num_eps : Specifies the number of endpoints. This is also a
> + MUSB configuration-specific setting. Should be set to "16"
> + - ram_bits : Specifies the ram address size. Should be set to "12"
> + - interface_type : This is a board specific setting to describe the type of
> + interface between the controller and the phy. It should be "0" or "1"
> + specifying ULPI and UTMI respectively.
> + - mode : Should be "3" to represent OTG. "1" signifies HOST and "2"
> + represents PERIPHERAL.
> + - power : Should be "50". This signifies the controller can supply upto
> + 100mA when operating in host mode.
> +
> +SOC specific device node entry
> +usb_otg_hs: usb_otg_hs@4a0ab000 {
> + compatible = "ti,omap4-musb";
> + ti,hwmods = "usb_otg_hs";
> + multipoint = <1>;
> + num_eps = <16>;
> + ram_bits = <12>;
> +};
reg and interrupt properties are missing here.
I would encourage to specify "reg" and "interrupt" properties in every
node getting newly added to the OMAP DTS files.
Thanks,
Vaibhav
> +
> +Board specific device node entry
> +&usb_otg_hs {
> + interface_type = <1>;
> + mode = <3>;
> + power = <50>;
> +};
> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> index f4d9503..d96873b 100644
> --- a/drivers/usb/musb/omap2430.c
> +++ b/drivers/usb/musb/omap2430.c
> @@ -30,6 +30,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -470,8 +471,11 @@ static u64 omap2430_dmamask = DMA_BIT_MASK(32);
> static int __devinit omap2430_probe(struct platform_device *pdev)
> {
> struct musb_hdrc_platform_data *pdata = pdev->dev.platform_data;
> + struct omap_musb_board_data *data;
> struct platform_device *musb;
> struct omap2430_glue*glue;
> + struct device_node *np = pdev->dev.of_node;
> + struct musb_hdrc_config *config;
> struct resource *res;
> int ret = -ENOMEM;
>
> @@ -501,6 +505,42 @@ static int __devinit omap2430_probe(struct
> platform_device *pdev)
> if (glue->control_otghs == NULL)
> dev_dbg(&pdev->dev, "Failed to obtain control memory\n");
>
> + if (np) {
> + pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata) {
> + dev_err(&pdev->dev,
> + "failed to allocate musb platfrom data\n");
> + ret = -ENOMEM;
> + goto err1;
> + }
> +
> + data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
> + if (!data) {
> + dev_err(&pdev->dev,
> + "failed to allocate musb board data\n");
> + ret = -ENOMEM;
> + goto err1;
> + }
> +
> + config = devm_kzalloc(&pdev->dev, sizeof(*config), GFP_KERNEL);
> + if (!data) {
> + dev_err(&pdev->dev,
> + "failed to allocate musb hdrc config\n");
> + goto err1;
> + }
> +
> + of_property_read_u32(np, "mode", (u32 *)&pdata->mode);
> + of_property_read_u32(np, "interface_type",
> + (u32 *)&data->interface_type);
> + of_property_read_u32(np, "num_eps", (u32 *)&config->num_eps);
> + of_property_read_u32(np, "ram_bits", (u32 *)&config->ram_bits);
> + of_property_read_u32(np, "power", (u32 *)&pdata->power);
> + config->multipoint = of_property_read_bool(np, "multipoint");
> +
> + pdata->board_data = data;
> + pdata->config = config;
> + }
> +
> pdata->platform_ops = &omap2430_ops;
>
> platform_set_drvdata(pdev, glue);
> @@ -597,12 +637,26 @@ st
[PATCH v9 0/3] GPMC driver conversion
Hi, Basic gpmc driver conversion series. Driver that is now created out of gpmc code is a simple one, it handles tasks that were earlier executed by gpmc_init. Now instead of relying on cpu_is_* checks, it obtains resources and clk handle in the standard Linux way. The existing gpmc interface works as was without this series. HWMOD patch also has been brought into this series back with v7 series As this creates only a basic driver, further gpmc driver work can be based over this, while having a driver first in place. This series is based on l-o/testing-cleanup as on 11-Sep-12, i.e. over commit, e274bffb ARM: OMAP1: Move SoC specific headers from plat to mach for omap1 It is available @git://gitorious.org/x0148406-public/linux-kernel.git gpmc-drv-v9 This series has been tested on omap3evm (rev G). GPMC (General Purpose Memory Controller) in brief: GPMC is an unified memory controller dedicated to interfacing external memory devices like Asynchronous SRAM like memories and application specific integrated circuit devices. Asynchronous, synchronous, and page mode burst NOR flash devices NAND flash Pseudo-SRAM devices GPMC details can be referred in AM335X Technical Reference Manual @ http://www.ti.com/lit/pdf/spruh73 Regards Afzal v9: 3xxx gpmc clock domain as core_l3_clkdm Lower case hex numbers v8: Use feature flag to decide whether wr_access and wr_data_mux_bus timings has to be configured (PATCH 3/3) v7: Create a simple driver that gets resources & clk the standard Linux way Pull in HMWOD patch back into this series v6: Capability flag added that stores features based on revision Macros used for finding revision Return value from memory setup function corrected Comments added to clarify handling of device type, size Bool type time setting patch removed as has been taken care in [2] Handle variable number of waitpin Warn if driver is unable to configure interrupt Enhance some of commit messages Handle shared writeprotect case Fix a bug in gpmc_create_device Get clk from hwmod Remove unwanted code v5: Make this a purely driver conversion series, i.e. gpmc-mtd interactions has been made as a separate series, so is adding hwmod entry for OMAP2/3. And modifying gpmc peripheral platform initialization has been separated out of this series, so is migrating boards to use new driver interface. GPMC driver conversion which was done in a few patches in v4 has been tranformed to series of small patches. Also care has been taken care that old interface will not break with any of these patches, so both interfaces can coexist. This helps in converting boards one-by-one gradually. Acquiring CS has been thrown out. And conclusive comments on v4 has been addressed. v4: Handle wait pin (except for interrupts), enhance configuration & timing interface of GPMC to take care of all boards. Dynamic allocation of interrupt instead of static. Convert remaining peripherals to work with GPMC driver. Handle acquiring NAND CS#, adapt to HWMOD, update HWMOD OMAP2/3 entries, other minor commenst on v3. v3: Single device structure passed from platform for peripherals using multiple CS instead of using multiple device structure having a few redundant data, handle interrupts, GPMC NAND handling by GPMC NAND driver instead of GPMC driver v2: Avoid code movement that kept similar code together (for easy review) Afzal Mohammed (3): ARM: OMAP2/3: hwmod data: add gpmc ARM: OMAP2+: gpmc: Adapt to HWMOD ARM: OMAP2+: gpmc: minimal driver support arch/arm/mach-omap2/gpmc.c | 193 +++- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 18 ++ arch/arm/mach-omap2/omap_hwmod_2430_data.c | 18 ++ arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 44 +- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 54 ++ arch/arm/mach-omap2/omap_hwmod_common_data.h |1 + arch/arm/mach-omap2/prcm-common.h |2 + 7 files changed, 280 insertions(+), 50 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 1/3] ARM: OMAP2/3: hwmod data: add gpmc
Add gpmc hwmod and associated interconnect data
Signed-off-by: Afzal Mohammed
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 18 +++
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 18 +++
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 44 -
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 54
arch/arm/mach-omap2/omap_hwmod_common_data.h |1 +
arch/arm/mach-omap2/prcm-common.h |2 +
6 files changed, 136 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 4e81637..5fcd225 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -535,6 +535,15 @@ static struct omap_hwmod_addr_space
omap2420_counter_32k_addrs[] = {
{ }
};
+static struct omap_hwmod_addr_space omap2420_gpmc_addrs[] = {
+ {
+ .pa_start = 0x6800a000,
+ .pa_end = 0x6800afff,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
static struct omap_hwmod_ocp_if omap2420_l4_wkup__counter_32k = {
.master = &omap2xxx_l4_wkup_hwmod,
.slave = &omap2xxx_counter_32k_hwmod,
@@ -543,6 +552,14 @@ static struct omap_hwmod_ocp_if
omap2420_l4_wkup__counter_32k = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_ocp_if omap2420_l3__gpmc = {
+ .master = &omap2xxx_l3_main_hwmod,
+ .slave = &omap2xxx_gpmc_hwmod,
+ .clk= "core_l3_ck",
+ .addr = omap2420_gpmc_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *omap2420_hwmod_ocp_ifs[] __initdata = {
&omap2xxx_l3_main__l4_core,
&omap2xxx_mpu__l3_main,
@@ -586,6 +603,7 @@ static struct omap_hwmod_ocp_if *omap2420_hwmod_ocp_ifs[]
__initdata = {
&omap2420_l4_core__msdi1,
&omap2420_l4_core__hdq1w,
&omap2420_l4_wkup__counter_32k,
+ &omap2420_l3__gpmc,
NULL,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index ceb23c3..a560563 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -887,6 +887,15 @@ static struct omap_hwmod_addr_space
omap2430_counter_32k_addrs[] = {
{ }
};
+static struct omap_hwmod_addr_space omap2430_gpmc_addrs[] = {
+ {
+ .pa_start = 0x6e00,
+ .pa_end = 0x6e000fff,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
static struct omap_hwmod_ocp_if omap2430_l4_wkup__counter_32k = {
.master = &omap2xxx_l4_wkup_hwmod,
.slave = &omap2xxx_counter_32k_hwmod,
@@ -895,6 +904,14 @@ static struct omap_hwmod_ocp_if
omap2430_l4_wkup__counter_32k = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_ocp_if omap2430_l3__gpmc = {
+ .master = &omap2xxx_l3_main_hwmod,
+ .slave = &omap2xxx_gpmc_hwmod,
+ .clk= "core_l3_ck",
+ .addr = omap2430_gpmc_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *omap2430_hwmod_ocp_ifs[] __initdata = {
&omap2xxx_l3_main__l4_core,
&omap2xxx_mpu__l3_main,
@@ -945,6 +962,7 @@ static struct omap_hwmod_ocp_if *omap2430_hwmod_ocp_ifs[]
__initdata = {
&omap2430_l4_core__mcbsp5,
&omap2430_l4_core__hdq1w,
&omap2430_l4_wkup__counter_32k,
+ &omap2430_l3__gpmc,
NULL,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index ceb3052..d848c7a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -173,6 +173,26 @@ struct omap_hwmod_class omap2xxx_mcspi_class = {
};
/*
+ * 'gpmc' class
+ * general purpose memory controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap2xxx_gpmc_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2xxx_gpmc_hwmod_class = {
+ .name = "gpmc",
+ .sysc = &omap2xxx_gpmc_sysc,
+};
+
+/*
* IP blocks
*/
@@ -724,7 +744,6 @@ struct omap_hwmod omap2xxx_mcspi2_hwmod = {
.dev_attr = &omap_mcspi2_dev_attr,
};
-
static struct omap_hwmod_class omap2xxx_counter_hwmod_class = {
.name = "counter",
};
@@ -743,3 +762,26 @@ struct omap_hwmod oma
[PATCH v9 2/3] ARM: OMAP2+: gpmc: Adapt to HWMOD
Create API for platforms to adapt GPMC to HWMOD
Signed-off-by: Afzal Mohammed
Reviewed-by: Jon Hunter
---
arch/arm/mach-omap2/gpmc.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 055ae8b..5462666 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -31,10 +31,13 @@
#include
#include
#include
+#include
#include "soc.h"
#include "common.h"
+#defineDEVICE_NAME "omap-gpmc"
+
/* GPMC register offsets */
#define GPMC_REVISION 0x00
#define GPMC_SYSCONFIG 0x10
@@ -898,6 +901,25 @@ static int __init gpmc_init(void)
}
postcore_initcall(gpmc_init);
+static int __init omap_gpmc_init(void)
+{
+ struct omap_hwmod *oh;
+ struct platform_device *pdev;
+ char *oh_name = "gpmc";
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err("Could not look up %s\n", oh_name);
+ return -ENODEV;
+ }
+
+ pdev = omap_device_build(DEVICE_NAME, -1, oh, NULL, 0, NULL, 0, 0);
+ WARN(IS_ERR(pdev), "could not build omap_device for %s\n", oh_name);
+
+ return IS_ERR(pdev) ? PTR_ERR(pdev) : 0;
+}
+postcore_initcall(omap_gpmc_init);
+
static irqreturn_t gpmc_handle_irq(int irq, void *dev)
{
int i;
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 3/3] ARM: OMAP2+: gpmc: minimal driver support
Create a minimal driver out of gpmc code.
Responsibilities handled by earlier gpmc
initialization is now achieved in probe.
Signed-off-by: Afzal Mohammed
Reviewed-by: Jon Hunter
---
arch/arm/mach-omap2/gpmc.c | 171 +++-
1 files changed, 122 insertions(+), 49 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 5462666..a628fdc 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -86,6 +87,12 @@
#define ENABLE_PREFETCH(0x1 << 7)
#define DMA_MPU_MODE 2
+#defineGPMC_REVISION_MAJOR(l) ((l >> 4) & 0xf)
+#defineGPMC_REVISION_MINOR(l) (l & 0xf)
+
+#defineGPMC_HAS_WR_ACCESS 0x1
+#defineGPMC_HAS_WR_DATA_MUX_BUS0x2
+
/* XXX: Only NAND irq has been considered,currently these are the only ones
used
*/
#defineGPMC_NR_IRQ 2
@@ -131,7 +138,10 @@ static struct resource gpmc_cs_mem[GPMC_CS_NUM];
static DEFINE_SPINLOCK(gpmc_mem_lock);
static unsigned int gpmc_cs_map; /* flag for cs which are initialized */
static int gpmc_ecc_used = -EINVAL;/* cs using ecc engine */
-
+static struct device *gpmc_dev;
+static int gpmc_irq;
+static resource_size_t phys_base, mem_size;
+static unsigned gpmc_capability;
static void __iomem *gpmc_base;
static struct clk *gpmc_l3_clk;
@@ -321,10 +331,10 @@ int gpmc_cs_set_timings(int cs, const struct gpmc_timings
*t)
GPMC_SET_ONE(GPMC_CS_CONFIG5, 24, 27, page_burst_access);
- if (cpu_is_omap34xx()) {
+ if (gpmc_capability & GPMC_HAS_WR_DATA_MUX_BUS)
GPMC_SET_ONE(GPMC_CS_CONFIG6, 16, 19, wr_data_mux_bus);
+ if (gpmc_capability & GPMC_HAS_WR_ACCESS)
GPMC_SET_ONE(GPMC_CS_CONFIG6, 24, 28, wr_access);
- }
/* caller is expected to have initialized CONFIG1 to cover
* at least sync vs async
@@ -434,6 +444,19 @@ static int gpmc_cs_insert_mem(int cs, unsigned long base,
unsigned long size)
return r;
}
+static int gpmc_cs_delete_mem(int cs)
+{
+ struct resource *res = &gpmc_cs_mem[cs];
+ int r;
+
+ spin_lock(&gpmc_mem_lock);
+ r = release_resource(&gpmc_cs_mem[cs]);
+ res->start = res->end = 0;
+ spin_unlock(&gpmc_mem_lock);
+
+ return r;
+}
+
int gpmc_cs_request(int cs, unsigned long size, unsigned long *base)
{
struct resource *res = &gpmc_cs_mem[cs];
@@ -770,7 +793,7 @@ static void gpmc_irq_noop(struct irq_data *data) { }
static unsigned int gpmc_irq_noop_ret(struct irq_data *data) { return 0; }
-static int gpmc_setup_irq(int gpmc_irq)
+static int gpmc_setup_irq(void)
{
int i;
u32 regval;
@@ -814,7 +837,37 @@ static int gpmc_setup_irq(int gpmc_irq)
return request_irq(gpmc_irq, gpmc_handle_irq, 0, "gpmc", NULL);
}
-static void __init gpmc_mem_init(void)
+static __exit int gpmc_free_irq(void)
+{
+ int i;
+
+ if (gpmc_irq)
+ free_irq(gpmc_irq, NULL);
+
+ for (i = 0; i < GPMC_NR_IRQ; i++) {
+ irq_set_handler(gpmc_client_irq[i].irq, NULL);
+ irq_set_chip(gpmc_client_irq[i].irq, &no_irq_chip);
+ irq_modify_status(gpmc_client_irq[i].irq, 0, 0);
+ }
+
+ irq_free_descs(gpmc_irq_start, GPMC_NR_IRQ);
+
+ return 0;
+}
+
+static void __devexit gpmc_mem_exit(void)
+{
+ int cs;
+
+ for (cs = 0; cs < GPMC_CS_NUM; cs++) {
+ if (!gpmc_cs_mem_enabled(cs))
+ continue;
+ gpmc_cs_delete_mem(cs);
+ }
+
+}
+
+static void __devinit gpmc_mem_init(void)
{
int cs;
unsigned long boot_rom_space = 0;
@@ -841,65 +894,85 @@ static void __init gpmc_mem_init(void)
}
}
-static int __init gpmc_init(void)
+static __devinit int gpmc_probe(struct platform_device *pdev)
{
u32 l;
- int ret = -EINVAL;
- int gpmc_irq;
- char *ck = NULL;
-
- if (cpu_is_omap24xx()) {
- ck = "core_l3_ck";
- if (cpu_is_omap2420())
- l = OMAP2420_GPMC_BASE;
- else
- l = OMAP34XX_GPMC_BASE;
- gpmc_irq = 20 + OMAP_INTC_START;
- } else if (cpu_is_omap34xx()) {
- ck = "gpmc_fck";
- l = OMAP34XX_GPMC_BASE;
- gpmc_irq = 20 + OMAP_INTC_START;
- } else if (cpu_is_omap44xx() || soc_is_omap54xx()) {
- /* Base address and irq number are same for OMAP4/5 */
- ck = "gpmc_ck";
- l = OMAP44XX_GPMC_BASE;
- gpmc_irq = 20 + OMAP44XX_IRQ_GIC_START;
- }
+ struct resource *res;
- if (WARN_ON(!ck))
- return ret;
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (res == NULL)
+ return -
Re: [PATCH v2] watchdog: omap_wdt: convert to new watchdog core
On Saturday 08 September 2012 11:34 PM, Aaro Koskinen wrote:
> -static struct platform_device *omap_wdt_dev;
> -
> static unsigned timer_margin;
> module_param(timer_margin, uint, 0);
> MODULE_PARM_DESC(timer_margin, "initial watchdog timeout (in seconds)");
>
> -static unsigned int wdt_trgr_pattern = 0x1234;
> -static DEFINE_SPINLOCK(wdt_lock);
> -
you may want to describe this more.
> struct omap_wdt_dev {
> void __iomem*base; /* physical */
> struct device *dev;
> - int omap_wdt_users;
> + boolomap_wdt_users;
> struct resource *mem;
> - struct miscdevice omap_wdt_miscdev;
> + int wdt_trgr_pattern;
> + struct mutexlock; /* to avoid races with PM */
> };
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v8 2/3] ARM: OMAP2+: gpmc: Adapt to HWMOD
Hi Jon, On Thu, Sep 06, 2012 at 01:25:23, Hunter, Jon wrote: > Nit-pick, I see some devices writing the above as ... > > WARN(IS_ERR(pdev), "could not build omap_device for %s\n", oh_name); > > return IS_ERR(pdev) ? PTR_ERR(pdev) : 0; > Otherwise ... > > Reviewed-by: Jon Hunter Thanks for your reviews, updated series has been posted Regards Afzal
Re: [PATCHv7 00/23]I2C big cleanup
On Tuesday 11 September 2012 03:11 PM, Shubhrajyoti D wrote:
> Changes since v1:
>- removed tabification on patch 6/17
>- removed dev_err() which was introduced on patch 09/17
> Changes since v2:
> - do not set full fifo depth in the RDR interrupt.
> - some changelog updates.
> - rebase to the Wolfram's tree.
> Changes since v3:
> - Remove a redundant read of status register
> - Read the dev->buf_len variable instead of the register
> as the information of the remaining bytes is there.
> Changes since v4:
> - Ack the arbitration lost.
> - Rebase to the i2c-embedded/for-next branch.
> Changes since v5:
> - Rebase to latest mainline
> - Added some more cleanup patches so as have a consolidated series.
> Changes since v6:
> - Fix comments on setting the pdev to NULL.
> - Trivial changelog update
>
> Previous discussions can be found here
> http://www.spinics.net/lists/linux-i2c/msg09482.html
Also this gives better performance
With the patches:
Performance counter stats for '/build/i2c/bin/i2cdump -y -f 1 0x48
b':
78.796376 task-clock#0.453 CPUs
utilized
516 context-switches #0.007
M/sec
0 CPU-migrations#0.000
K/sec
114 page-faults #0.001 M/sec
0.174011183 seconds time elapsed
Without the patches
Performance counter stats for '/build/i2c/bin/i2cdump -y -f 1 0x48
b':
123.504640 task-clock#0.049 CPUs
utilized
337 context-switches #0.003
M/sec
0 CPU-migrations#0.000
K/sec
144 page-faults #0.001
M/sec
2.534424040 seconds time elapsed
The auto suspend is probably the one :-)
> This is the cleanup only series.
>
> Tested on omap4sdp and 3430sdp.
>
> The following changes since commit 55d512e245bc7699a8800e23df1a24195dd08217:
>
> Linux 3.6-rc5 (2012-09-08 16:43:45 -0700)
>
> are available in the git repository at:
> git://gitorious.org/linus-tree/linus-tree.git for_3.7/i2c/big_cleanup
>
>
>
> Felipe Balbi (22):
> i2c: omap: switch to devm_* API
> i2c: omap: simplify num_bytes handling
> i2c: omap: decrease indentation level on data handling
> i2c: omap: add blank lines
> i2c: omap: simplify omap_i2c_ack_stat()
> i2c: omap: split out [XR]DR and [XR]RDY
> i2c: omap: improve i462 errata handling
> i2c: omap: re-factor receive/transmit data loop
> i2c: omap: switch over to do {} while loop
> i2c: omap: ack IRQ in parts
> i2c: omap: switch to platform_get_irq()
> i2c: omap: bus: add a receiver flag
> i2c: omap: simplify errata check
> i2c: omap: always return IRQ_HANDLED
> i2c: omap: simplify IRQ exit path
> i2c: omap: resize fifos before each message
> i2c: omap: get rid of the "complete" label
> i2c: omap: always return IRQ_HANDLED
> i2c: omap: switch to threaded IRQ support
> i2c: omap: remove unnecessary pm_runtime_suspended check
> i2c: omap: switch over to autosuspend API
> i2c: omap: sanitize exit path
>
> Shubhrajyoti D (1):
> i2c: omap: remove redundant status read
>
> drivers/i2c/busses/i2c-omap.c | 442
> +
> 1 files changed, 271 insertions(+), 171 deletions(-)
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v9 00/13] usb: musb: adding multi instance support
> > Hi, > > On Fri, Aug 31, 2012 at 04:39:46PM +0530, Ravi Babu wrote: > > This series of patches adds, > > a) Multi instances support in musb driver > > b) DT support for musb_dsps glue layer > > c) DT support for NOP transceiver > > > > AM33xx and TI81xx has dual musb controller and has two usb > PHY of same type. > > This patch series uses 'phandle' based API > > devm_usb_get_phy_by_phandle() to get the PHY of same type. This API > > support is being added by Kishon's patch discussed at [1] > > > > The series applies to felipe/master [1] branch > > + Vaibhav baseport patches on his tree at [4] > > + Kishon's multi phy patches on Felipe's branch 'xceiv' > > + Kishon's patch on phandle at [2] > > + Damodar's recent patch at [3] > > + Ajay's & Damodar's patches at [5] and [6] included in > this series > > > > 1. http://git.kernel.org/?p=linux/kernel/git/balbi/usb.git;a=summary > > 2. http://marc.info/?l=linux-usb&m=134070369306112&w=2 > > 3. http://marc.info/?l=linux-usb&m=134200284230689&w=2 > > 4. > > > https://github.com/hvaibhav/am335x-linux/commits/am335x-upstream-stagi > > ng 5. http://marc.info/?l=linux-usb&m=134200285530701&w=2 > > 6. http://marc.info/?l=linux-usb&m=134208820028625&w=2 > > > > Changes from v8: > > - included Sergei's comment, removing underscore in > device tree file > > - removed duplicated signoff from patches Changes from v7: > > - patches rebased on felipe/master branch & verified > > - included additional two patches 0001 & 0002 as part > of this series > > which are already submitted [5] & [6] Changes from v6: > > - Removed parent_pdev to get glue and used > dev_get_getdrv() as per > > Felipe's comment > > - use pr_debug() instead of pr_info() as per Felipe's > comment Changes > > from v5: > > - Removed musb->id as per Felipe's comment > > - used nop_ida as per Felipe's comment Changes from v4: > > - Fixed Felipe's comment for adding EXPORT_SYMBOL_GPL() > > - Fixed Felipe's comment on using dev_set_mask() > Changes from v3: > > - Fixed Kishon's comment on removing "id" from phy struct and > > removing unneeded "#else" part. > > Changes from v2: > > - Fixed Sergei's comment on not using address prefix in > musb_dsps > > glue and nop transceiver dt dats. > > - Also removed the "ti" string in compatible property > for nop data. > > Changes from v1: > > - Defined musb_ida to manage core ids based on Felipe's comment > > in [PATCH 01/11] > > I tried appliying this, but this doesn't apply. Please rebase > on my musb branch. Unfortunately there's no time anymore to > wait otherwise the entire musb branch will miss this merge window. > > I'm sorry Felipe, patch set is ready, I will re-send the patches shortly by today. > > -- > balbi > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v8 0/3] GPMC driver conversion
Hi Tony, On Sat, Sep 08, 2012 at 03:40:34, Tony Lindgren wrote: > Great, this all looks good to me. I suggest that on top of this > we add minimal devicetree binding that does not even attempt to > deal with the timings yet. > > Then once the minimal devicetree binding is in place, we can > call the current GPMC timing functions using the compatible flags > and auxdata in the gpmc.c driver. > > That way we get all the legacy boards booting with GPMC support > for smsc911x etc, and can even remove some less used board-*.c > files. Thanks. I agree with your suggestion and would be proceeding so as to achieve minimal devicetree support. And a newer version of this series has been posted. > Then we just add the generic GPMC timings when we're happy with > those. Meanwhile can you send me the gpmc debug logs for n800 where tusb patch on generic timing was causing the hang along with logs without the culprit tusb patch so that we could arrive at generic gpmc timings. Regards Afzal
Re: [balbi-usb:master 33/36] drivers/usb/gadget/serial.c:89:22: sparse: cast truncates bits from constant value (24000000 becomes 0)
On Mon, Sep 10, 2012 at 07:05:15PM +0200, Sebastian Andrzej Siewior wrote:
> On 09/10/2012 06:40 PM, Fengguang Wu wrote:
> >tree: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git master
> >head: d9c88901337158c9f253a7de58a10b5125d61d26
> >commit: 7a7322b0a5d984025dd4faea9098b8fef07f8d8f [33/36] usb: gadget: remove
> >usb_gadget_controller_number()
> >
> >All sparse warnings:
>
> Once again, thank you.
You are welcome!
> > drivers/usb/gadget/f_acm.c:287:9: sparse: advancing past deep designator
> > drivers/usb/gadget/f_obex.c:60:9: sparse: advancing past deep designator
> > drivers/usb/gadget/f_serial.c:134:9: sparse: advancing past deep
> > designator
> > drivers/usb/gadget/serial.c:66:9: sparse: advancing past deep designator
>
> I don't get these. The purpose is an all NULL terminating entry. Could
> this be a sparse bug or is the [] / {} switch not really good C code?
http://marc.info/?l=linux-sparse&m=130673652023059&w=4
According to Dan's explanations, I'll filter out these warnings in future.
> >+ drivers/usb/gadget/serial.c:89:22: sparse: cast truncates bits from
> >constant value (2400 becomes 0)
>
> I've sent a patch for this.
Thank you!
Fengguang
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] usb: musb: omap: Add device tree support for omap musb glue
Hi,
On Tue, Sep 11, 2012 at 3:23 PM, Vaibhav Hiremath wrote:
>
>
> On 9/11/2012 2:39 PM, Kishon Vijay Abraham I wrote:
>> Added device tree support for omap musb driver and updated the
>> Documentation with device tree binding information.
>>
>> Signed-off-by: Kishon Vijay Abraham I
>> ---
>> Documentation/devicetree/bindings/usb/omap-usb.txt | 33
>> drivers/usb/musb/omap2430.c| 54
>>
>> 2 files changed, 87 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt
>>
>> diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
>> b/Documentation/devicetree/bindings/usb/omap-usb.txt
>> new file mode 100644
>> index 000..29a043e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
>> @@ -0,0 +1,33 @@
>> +OMAP GLUE
>> +
>> +OMAP MUSB GLUE
>> + - compatible : Should be "ti,omap4-musb" or "ti,omap3-musb"
>> + - ti,hwmods : must be "usb_otg_hs"
>> + - multipoint : Should be "1" indicating the musb controller supports
>> + multipoint. This is a MUSB configuration-specific setting.
>> + - num_eps : Specifies the number of endpoints. This is also a
>> + MUSB configuration-specific setting. Should be set to "16"
>> + - ram_bits : Specifies the ram address size. Should be set to "12"
>> + - interface_type : This is a board specific setting to describe the type of
>> + interface between the controller and the phy. It should be "0" or "1"
>> + specifying ULPI and UTMI respectively.
>> + - mode : Should be "3" to represent OTG. "1" signifies HOST and "2"
>> + represents PERIPHERAL.
>> + - power : Should be "50". This signifies the controller can supply upto
>> + 100mA when operating in host mode.
>> +
>> +SOC specific device node entry
>> +usb_otg_hs: usb_otg_hs@4a0ab000 {
>> + compatible = "ti,omap4-musb";
>> + ti,hwmods = "usb_otg_hs";
>> + multipoint = <1>;
>> + num_eps = <16>;
>> + ram_bits = <12>;
>> +};
>
>
> reg and interrupt properties are missing here.
>
> I would encourage to specify "reg" and "interrupt" properties in every
> node getting newly added to the OMAP DTS files.
Sure. will add that in my next version.
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: AM33XX: fix gpio node numbering to match hardware
On Tue, Sep 11, 2012 at 04:57:08AM +, Hiremath, Vaibhav wrote:
> On Mon, Sep 10, 2012 at 21:50:20, Porter, Matt wrote:
> > On AM33xx, the datasheet and TRM refer to four GPIO instances that
> > are 0-based, GPIO0-3.
> >
>
> Thanks Matt,
> I think Anil labeled it as gpio1-4 due to hwmod naming convention, as you
> can not have gpioo id = 0 (refer to arch/arm/mach-omap2/gpio.c).
Right, and that convention originally came from the assumption that
everything would be 1-based like OMAP3/4.
> But in case of DT we should simply follow TRM/Spec, as naming convention is
> based on base-addr and not id, so your patch looks good me.
Yes, my biggest concern here was the coming frustration that the end
"user" or system integrator would have with these labels not matching
the docs that have been around for a year. It would be !sane to have
somebody look at a schematic and then write their dts with a value that
doesn't match the h/w. That would run counter to the fundamental
requirement that DT is a description of the hardware. The user led patch
was already the first example of that where the comments mentioned gpio1
in the pinmux data but the data referenced the gpio2 label.
-Matt
> > Signed-off-by: Matt Porter
> > ---
> > arch/arm/boot/dts/am33xx.dtsi |8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> > index bb31bff..1369bfc 100644
> > --- a/arch/arm/boot/dts/am33xx.dtsi
> > +++ b/arch/arm/boot/dts/am33xx.dtsi
> > @@ -62,7 +62,7 @@
> > reg = <0x4820 0x1000>;
> > };
> >
> > - gpio1: gpio@44e07000 {
> > + gpio0: gpio@44e07000 {
> > compatible = "ti,omap4-gpio";
> > ti,hwmods = "gpio1";
> > gpio-controller;
> > @@ -74,7 +74,7 @@
> > interrupts = <96>;
> > };
> >
> > - gpio2: gpio@4804c000 {
> > + gpio1: gpio@4804c000 {
> > compatible = "ti,omap4-gpio";
> > ti,hwmods = "gpio2";
> > gpio-controller;
> > @@ -86,7 +86,7 @@
> > interrupts = <98>;
> > };
> >
> > - gpio3: gpio@481ac000 {
> > + gpio2: gpio@481ac000 {
> > compatible = "ti,omap4-gpio";
> > ti,hwmods = "gpio3";
> > gpio-controller;
> > @@ -98,7 +98,7 @@
> > interrupts = <32>;
> > };
> >
> > - gpio4: gpio@481ae000 {
> > + gpio3: gpio@481ae000 {
> > compatible = "ti,omap4-gpio";
> > ti,hwmods = "gpio4";
> > gpio-controller;
> > --
> > 1.7.9.5
> >
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm/dts: Add omap3-beagle.dts
Hi Jon,
On 09/11/2012 12:57 AM, Jon Hunter wrote:
> Add a minimal dts for original OMAP3430/3530 version of the Beagle board. This
> version of the Beagle board has 256MB of DDR and features the same TWL4030
> power management IC (PMIC) as the Beagle board XM.
Thanks for the patch.
> Given that the Beagle and Beagle-XM boards use the same PMIC, move the
> definition of the VSIM regulator into the TWL4030.dtsi file so that we do not
> need to duplicate in the Beagle board dts file.
Good, catch, regulator definition has indeed nothing to do outside the
twl4030.dtsi.
> This has been boot tested on an OMAP3530 Beagle board and verifing that the
> SD/MMC interface is working with a SD card.
>
> This patch is generated on top of Tony's patch for adding the Beagle board XM
> dts file [1].
Tony has just updated his devel-dt with the DTS series I pushed plus the
beagle-xm introduction, so I'm gonna put this one on top and built a
for_3.7/dts_part2 branch sinec there are a couplf of USB / AM33xx pending.
Thanks,
Benoit
> [1] http://marc.info/?l=linux-omap&m=134695790516943&w=2
>
> Signed-off-by: Jon Hunter
> ---
> arch/arm/boot/dts/omap3-beagle-xm.dts |6 -
> arch/arm/boot/dts/omap3-beagle.dts| 46
> +
> arch/arm/boot/dts/twl4030.dtsi|6 +
> arch/arm/mach-omap2/Makefile.boot |3 ++-
> 4 files changed, 54 insertions(+), 7 deletions(-)
> create mode 100644 arch/arm/boot/dts/omap3-beagle.dts
>
> diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
> b/arch/arm/boot/dts/omap3-beagle-xm.dts
> index df6d485..ef2c711 100644
> --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
> +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
> @@ -26,12 +26,6 @@
> reg = <0x48>;
> interrupts = <7>; /* SYS_NIRQ cascaded to intc */
> interrupt-parent = <&intc>;
> -
> - vsim: regulator-vsim {
> - compatible = "ti,twl4030-vsim";
> - regulator-min-microvolt = <180>;
> - regulator-max-microvolt = <300>;
> - };
> };
> };
>
> diff --git a/arch/arm/boot/dts/omap3-beagle.dts
> b/arch/arm/boot/dts/omap3-beagle.dts
> new file mode 100644
> index 000..90790d9
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap3-beagle.dts
> @@ -0,0 +1,46 @@
> +/*
> + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
2012?
> + *
> + * 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.
> + */
> +/dts-v1/;
> +
> +/include/ "omap3.dtsi"
> +
> +/ {
> + model = "TI OMAP3 BeagleBoard";
> + compatible = "ti,omap3-beagle", "ti,omap3";
> +
> + memory {
> + device_type = "memory";
> + reg = <0x8000 0x1000>; /* 256 MB */
> + };
> +};
> +
> +&i2c1 {
> + clock-frequency = <260>;
> +
> + twl: twl@48 {
> + reg = <0x48>;
> + interrupts = <7>; /* SYS_NIRQ cascaded to intc */
> + interrupt-parent = <&intc>;
> + };
> +};
> +
> +/include/ "twl4030.dtsi"
> +
> +&mmc1 {
> + vmmc-supply = <&vmmc1>;
> + vmmc_aux-supply = <&vsim>;
> + bus-width = <8>;
> +};
> +
> +&mmc2 {
> + status = "disabled";
> +};
> +
> +&mmc3 {
> + status = "disabled";
> +};
> diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
> index ff00017..c5337d4 100644
> --- a/arch/arm/boot/dts/twl4030.dtsi
> +++ b/arch/arm/boot/dts/twl4030.dtsi
> @@ -37,6 +37,12 @@
> regulator-max-microvolt = <315>;
> };
>
> + vsim: regulator-vsim {
> + compatible = "ti,twl4030-vsim";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <300>;
> + };
> +
> twl_gpio: gpio {
> compatible = "ti,twl4030-gpio";
> gpio-controller;
> diff --git a/arch/arm/mach-omap2/Makefile.boot
> b/arch/arm/mach-omap2/Makefile.boot
> index 0e602b7..a469a55 100644
> --- a/arch/arm/mach-omap2/Makefile.boot
> +++ b/arch/arm/mach-omap2/Makefile.boot
> @@ -3,7 +3,8 @@ params_phys-y := 0x8100
> initrd_phys-y:= 0x8080
>
> dtb-$(CONFIG_SOC_OMAP2420) += omap2420-h4.dtb
> -dtb-$(CONFIG_ARCH_OMAP3) += omap3-beagle-xm.dtb omap3-evm.dtb
> +dtb-$(CONFIG_ARCH_OMAP3) += omap3-beagle.dtb omap3-beagle-xm.dtb \
> +omap3-evm.dtb
> dtb-$(CONFIG_ARCH_OMAP4) += omap4-panda.dtb omap4-pandaES.dtb
> dtb-$(CONFIG_ARCH_OMAP4) += omap4-var_som.dtb omap4-sdp.dtb
> dtb-$(CONFIG_SOC_OMAP5) += omap5-evm.dtb
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: dts: AM33XX: fix gpio node numbering to match hardware
On Tue, Sep 11, 2012 at 16:59:05, Porter, Matt wrote:
> On Tue, Sep 11, 2012 at 04:57:08AM +, Hiremath, Vaibhav wrote:
> > On Mon, Sep 10, 2012 at 21:50:20, Porter, Matt wrote:
> > > On AM33xx, the datasheet and TRM refer to four GPIO instances that
> > > are 0-based, GPIO0-3.
> > >
> >
> > Thanks Matt,
> > I think Anil labeled it as gpio1-4 due to hwmod naming convention, as you
> > can not have gpioo id = 0 (refer to arch/arm/mach-omap2/gpio.c).
>
> Right, and that convention originally came from the assumption that
> everything would be 1-based like OMAP3/4.
>
> > But in case of DT we should simply follow TRM/Spec, as naming convention is
> > based on base-addr and not id, so your patch looks good me.
>
> Yes, my biggest concern here was the coming frustration that the end
> "user" or system integrator would have with these labels not matching
> the docs that have been around for a year. It would be !sane to have
> somebody look at a schematic and then write their dts with a value that
> doesn't match the h/w. That would run counter to the fundamental
> requirement that DT is a description of the hardware. The user led patch
> was already the first example of that where the comments mentioned gpio1
> in the pinmux data but the data referenced the gpio2 label.
>
I understand and your patch is already fixing the "biggest concern" here,
right.
Thanks,
Vaibhav
> -Matt
>
> > > Signed-off-by: Matt Porter
> > > ---
> > > arch/arm/boot/dts/am33xx.dtsi |8
> > > 1 file changed, 4 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> > > index bb31bff..1369bfc 100644
> > > --- a/arch/arm/boot/dts/am33xx.dtsi
> > > +++ b/arch/arm/boot/dts/am33xx.dtsi
> > > @@ -62,7 +62,7 @@
> > > reg = <0x4820 0x1000>;
> > > };
> > >
> > > - gpio1: gpio@44e07000 {
> > > + gpio0: gpio@44e07000 {
> > > compatible = "ti,omap4-gpio";
> > > ti,hwmods = "gpio1";
> > > gpio-controller;
> > > @@ -74,7 +74,7 @@
> > > interrupts = <96>;
> > > };
> > >
> > > - gpio2: gpio@4804c000 {
> > > + gpio1: gpio@4804c000 {
> > > compatible = "ti,omap4-gpio";
> > > ti,hwmods = "gpio2";
> > > gpio-controller;
> > > @@ -86,7 +86,7 @@
> > > interrupts = <98>;
> > > };
> > >
> > > - gpio3: gpio@481ac000 {
> > > + gpio2: gpio@481ac000 {
> > > compatible = "ti,omap4-gpio";
> > > ti,hwmods = "gpio3";
> > > gpio-controller;
> > > @@ -98,7 +98,7 @@
> > > interrupts = <32>;
> > > };
> > >
> > > - gpio4: gpio@481ae000 {
> > > + gpio3: gpio@481ae000 {
> > > compatible = "ti,omap4-gpio";
> > > ti,hwmods = "gpio4";
> > > gpio-controller;
> > > --
> > > 1.7.9.5
> > >
> > >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 00/21] OMAP UART Patches
On Sunday 09 September 2012 12:34 AM, Felipe Balbi wrote: >> In addition, IMO, if this was only tested on Panda (as suggested by >> > earlier cover letters), it really should not have been merged until it >> > got some broader testing. > Shubhro's got his Tested-by tag. I believe he tested on beagleboard and > omap4sdp. Shubhro, can you confirm which platforms you tested the UART > patches ? cheers Felipe I had boot tested on omap3sdp and onap4 sdp and did pm testing on both with omap3 hitting off. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/17] ARM: OMAP: Split plat/hardware.h, use local soc.h for omap2+
Hi Tony, > As the plat and mach includes need to disappear for single zImage work, > we need to remove plat/hardware.h. > > Do this by splitting plat/hardware.h into omap1 and omap2+ specific files. > > The old plat/hardware.h already has omap1 only defines, so it gets moved > to mach/hardware.h for omap1. For omap2+, we use the local soc.h > that for now just includes the related SoC headers to keep this patch more > readable. > > Note that the local soc.h still includes plat/cpu.h that can be dealt > with in later patches. Let's also include plat/serial.h from common.h for > all the board-*.c files. This allows making the include files local later > on without patching these files again. > > Note that only minimal changes are done in this patch for the > drivers/watchdog/omap_wdt.c driver to keep things compiling. Further > patches are needed to eventually remove cpu_is_omap usage in the drivers. > > Also only minimal changes are done to sound/soc/omap/* to remove the > unneeded includes and to define OMAP44XX_MCPDM_L3_BASE locally so there's > no need to include omap44xx.h. > > While at it, also sort some of the includes in the standard way. > > Cc: linux-watch...@vger.kernel.org > Cc: Wim Van Sebroeck Acked-by for the watchdog part. Kind regards, Wim. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Help]: Omap-serial: UART DMA Engine
Hi Russell, I am currently working on implementing DMA Engine for omap serial driver. Came to know from santosh that you had suggested that certain modification need to be done in the tty core layer, which I am unaware of. Can you please explain what sort of changes need to be done? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 3/3] usb: musb: omap: Add device tree support for omap musb glue
On Tue, Sep 11, 2012 at 16:54:37, ABRAHAM, KISHON VIJAY wrote:
> Hi,
>
> On Tue, Sep 11, 2012 at 3:23 PM, Vaibhav Hiremath wrote:
> >
> >
> > On 9/11/2012 2:39 PM, Kishon Vijay Abraham I wrote:
> >> Added device tree support for omap musb driver and updated the
> >> Documentation with device tree binding information.
> >>
> >> Signed-off-by: Kishon Vijay Abraham I
> >> ---
> >> Documentation/devicetree/bindings/usb/omap-usb.txt | 33
> >> drivers/usb/musb/omap2430.c| 54
> >>
> >> 2 files changed, 87 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
> >> b/Documentation/devicetree/bindings/usb/omap-usb.txt
> >> new file mode 100644
> >> index 000..29a043e
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
> >> @@ -0,0 +1,33 @@
> >> +OMAP GLUE
> >> +
> >> +OMAP MUSB GLUE
> >> + - compatible : Should be "ti,omap4-musb" or "ti,omap3-musb"
> >> + - ti,hwmods : must be "usb_otg_hs"
> >> + - multipoint : Should be "1" indicating the musb controller supports
> >> + multipoint. This is a MUSB configuration-specific setting.
> >> + - num_eps : Specifies the number of endpoints. This is also a
> >> + MUSB configuration-specific setting. Should be set to "16"
> >> + - ram_bits : Specifies the ram address size. Should be set to "12"
> >> + - interface_type : This is a board specific setting to describe the type
> >> of
> >> + interface between the controller and the phy. It should be "0" or "1"
> >> + specifying ULPI and UTMI respectively.
> >> + - mode : Should be "3" to represent OTG. "1" signifies HOST and "2"
> >> + represents PERIPHERAL.
> >> + - power : Should be "50". This signifies the controller can supply upto
> >> + 100mA when operating in host mode.
> >> +
> >> +SOC specific device node entry
> >> +usb_otg_hs: usb_otg_hs@4a0ab000 {
> >> + compatible = "ti,omap4-musb";
> >> + ti,hwmods = "usb_otg_hs";
> >> + multipoint = <1>;
> >> + num_eps = <16>;
> >> + ram_bits = <12>;
> >> +};
> >
> >
> > reg and interrupt properties are missing here.
> >
> > I would encourage to specify "reg" and "interrupt" properties in every
> > node getting newly added to the OMAP DTS files.
>
> Sure. will add that in my next version.
>
I saw there is some discussion going-on for which baseline to use, so make
sure that you test the patches on top of below patch (already available in
linux-omap/devel-dt)
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=commit;h=b82b04e8eb27abe0cfe9cd7bf4fee8bb1bb9b013
Thanks,
Vaibhav
> Thanks
> Kishon
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 00/13] usb: musb: adding multi instance support
On Tue, Sep 11, 2012 at 10:45:44AM +, B, Ravi wrote: > > > > Hi, > > > > On Fri, Aug 31, 2012 at 04:39:46PM +0530, Ravi Babu wrote: > > > This series of patches adds, > > > a) Multi instances support in musb driver > > > b) DT support for musb_dsps glue layer > > > c) DT support for NOP transceiver > > > > > > AM33xx and TI81xx has dual musb controller and has two usb > > PHY of same type. > > > This patch series uses 'phandle' based API > > > devm_usb_get_phy_by_phandle() to get the PHY of same type. This API > > > support is being added by Kishon's patch discussed at [1] > > > > > > The series applies to felipe/master [1] branch > > > + Vaibhav baseport patches on his tree at [4] > > > + Kishon's multi phy patches on Felipe's branch 'xceiv' > > > + Kishon's patch on phandle at [2] > > > + Damodar's recent patch at [3] > > > + Ajay's & Damodar's patches at [5] and [6] included in > > this series > > > > > > 1. http://git.kernel.org/?p=linux/kernel/git/balbi/usb.git;a=summary > > > 2. http://marc.info/?l=linux-usb&m=134070369306112&w=2 > > > 3. http://marc.info/?l=linux-usb&m=134200284230689&w=2 > > > 4. > > > > > https://github.com/hvaibhav/am335x-linux/commits/am335x-upstream-stagi > > > ng 5. http://marc.info/?l=linux-usb&m=134200285530701&w=2 > > > 6. http://marc.info/?l=linux-usb&m=134208820028625&w=2 > > > > > > Changes from v8: > > > - included Sergei's comment, removing underscore in > > device tree file > > > - removed duplicated signoff from patches Changes from v7: > > > - patches rebased on felipe/master branch & verified > > > - included additional two patches 0001 & 0002 as part > > of this series > > > which are already submitted [5] & [6] Changes from v6: > > > - Removed parent_pdev to get glue and used > > dev_get_getdrv() as per > > > Felipe's comment > > > - use pr_debug() instead of pr_info() as per Felipe's > > comment Changes > > > from v5: > > > - Removed musb->id as per Felipe's comment > > > - used nop_ida as per Felipe's comment Changes from v4: > > > - Fixed Felipe's comment for adding EXPORT_SYMBOL_GPL() > > > - Fixed Felipe's comment on using dev_set_mask() > > Changes from v3: > > > - Fixed Kishon's comment on removing "id" from phy struct and > > > removing unneeded "#else" part. > > > Changes from v2: > > > - Fixed Sergei's comment on not using address prefix in > > musb_dsps > > > glue and nop transceiver dt dats. > > > - Also removed the "ti" string in compatible property > > for nop data. > > > Changes from v1: > > > - Defined musb_ida to manage core ids based on Felipe's comment > > > in [PATCH 01/11] > > > > I tried appliying this, but this doesn't apply. Please rebase > > on my musb branch. Unfortunately there's no time anymore to > > wait otherwise the entire musb branch will miss this merge window. > > > > I'm sorry > > Felipe, patch set is ready, I will re-send the patches shortly by today. Thanks a lot. So I'll wait for a few more hours before sending out my musb pull request ;-) -- balbi signature.asc Description: Digital signature
RE: [PATCH v2 1/8] ARM/dts: OMAP2: Add McBSP entries for OMAP2420 and OMAP2430 SoC
+ Andrew, On Thu, Sep 06, 2012 at 20:12:07, Cousson, Benoit wrote: > > On 09/05/2012 04:41 PM, Hiremath, Vaibhav wrote: > ... > > There are other patches which are pending, > > > > arm/dts: AM33XX: Convert all hex numbers to lower-case > > https://patchwork.kernel.org/patch/1377351/ > > arm/dts: AM33XX: Specify reg and interrupt property for all nodes > > https://patchwork.kernel.org/patch/1377361/ > > OK, so these ones are fine, you should just rebase them because theyu > are conflicting with patches already inside lo/devel-dt > > > Probably your Ack is required for, > > > > ARM: AM33XX: clock: Add dcan clock aliases for device-tree > > https://patchwork.kernel.org/patch/1377061/ > > Paul already queued this one so it is fine. > > > RTC: > > I am not sure how to deal with RTC DT support, as I understand the list is > > very unresponsive there. > > OK, so I did have the same issue for TWL RTC since the maintainer is no > longer very active. In that case you should go through Andrew Morton. > Andrew, Can you please merge these omap-rtc patches, there are no review comments so far and I believe it should be safe now to merge. Thanks, Vaiibhav > Regards, > Benoit > > > http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg23253.html > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v9 00/13] usb: musb: adding multi instance support
> > > > > > On Fri, Aug 31, 2012 at 04:39:46PM +0530, Ravi Babu wrote: > > > > This series of patches adds, > > > > a) Multi instances support in musb driver > > > > b) DT support for musb_dsps glue layer > > > > c) DT support for NOP transceiver > > > > > > > > AM33xx and TI81xx has dual musb controller and has two usb > > > PHY of same type. > > > > This patch series uses 'phandle' based API > > > > devm_usb_get_phy_by_phandle() to get the PHY of same type. This > > > > API support is being added by Kishon's patch discussed at [1] > > > > > > > > The series applies to felipe/master [1] branch > > > > + Vaibhav baseport patches on his tree at [4] > > > > + Kishon's multi phy patches on Felipe's branch 'xceiv' > > > > + Kishon's patch on phandle at [2] > > > > + Damodar's recent patch at [3] > > > > + Ajay's & Damodar's patches at [5] and [6] included in > > > this series > > > > > > > > 1. > > > > > http://git.kernel.org/?p=linux/kernel/git/balbi/usb.git;a=summary > > > > 2. http://marc.info/?l=linux-usb&m=134070369306112&w=2 > > > > 3. http://marc.info/?l=linux-usb&m=134200284230689&w=2 > > > > 4. > > > > > > > > https://github.com/hvaibhav/am335x-linux/commits/am335x-upstream-sta > > > gi > > > > ng 5. http://marc.info/?l=linux-usb&m=134200285530701&w=2 > > > > 6. http://marc.info/?l=linux-usb&m=134208820028625&w=2 > > > > > > > > Changes from v8: > > > > - included Sergei's comment, removing underscore in > > > device tree file > > > > - removed duplicated signoff from patches > Changes from v7: > > > > - patches rebased on felipe/master branch & verified > > > > - included additional two patches 0001 & 0002 as part > > > of this series > > > > which are already submitted [5] & [6] Changes from v6: > > > > - Removed parent_pdev to get glue and used > > > dev_get_getdrv() as per > > > > Felipe's comment > > > > - use pr_debug() instead of pr_info() as per Felipe's > > > comment Changes > > > > from v5: > > > > - Removed musb->id as per Felipe's comment > > > > - used nop_ida as per Felipe's comment Changes from v4: > > > > - Fixed Felipe's comment for adding EXPORT_SYMBOL_GPL() > > > > - Fixed Felipe's comment on using dev_set_mask() > > > Changes from v3: > > > > - Fixed Kishon's comment on removing "id" from > phy struct and > > > > removing unneeded "#else" part. > > > > Changes from v2: > > > > - Fixed Sergei's comment on not using address prefix in > > > musb_dsps > > > > glue and nop transceiver dt dats. > > > > - Also removed the "ti" string in compatible property > > > for nop data. > > > > Changes from v1: > > > > - Defined musb_ida to manage core ids based on > Felipe's comment > > > > in [PATCH 01/11] > > > > > > I tried appliying this, but this doesn't apply. Please > rebase on my > > > musb branch. Unfortunately there's no time anymore to > wait otherwise > > > the entire musb branch will miss this merge window. > > > > > > I'm sorry > > > > Felipe, patch set is ready, I will re-send the patches > shortly by today. > > Thanks a lot. So I'll wait for a few more hours before > sending out my musb pull request ;-) > Thanks Felipe, these v9 patches are created on felipe/master branch. Now working on, to rebase on felipe/musb branch, will try to provide by end of today. > -- > balbi > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm/dts: Add omap3-beagle.dts
On 09/11/2012 01:29 PM, Benoit Cousson wrote: > Hi Jon, > > On 09/11/2012 12:57 AM, Jon Hunter wrote: >> Add a minimal dts for original OMAP3430/3530 version of the Beagle board. >> This >> version of the Beagle board has 256MB of DDR and features the same TWL4030 >> power management IC (PMIC) as the Beagle board XM. > > Thanks for the patch. > >> Given that the Beagle and Beagle-XM boards use the same PMIC, move the >> definition of the VSIM regulator into the TWL4030.dtsi file so that we do not >> need to duplicate in the Beagle board dts file. > > Good, catch, regulator definition has indeed nothing to do outside the > twl4030.dtsi. > >> This has been boot tested on an OMAP3530 Beagle board and verifing that the >> SD/MMC interface is working with a SD card. >> >> This patch is generated on top of Tony's patch for adding the Beagle board XM >> dts file [1]. > > Tony has just updated his devel-dt with the DTS series I pushed plus the > beagle-xm introduction, so I'm gonna put this one on top and built a > for_3.7/dts_part2 branch sinec there are a couplf of USB / AM33xx pending. OK, so in fact, it does not apply very well due to all the changes I introduced in my for_3.7/dts pull and then the beagle is now missing all the LEDs support recently added. So you should refresh that patch taking the latest devel-dt branch as a base and copying the latest beagle-xm.dts file. >> diff --git a/arch/arm/mach-omap2/Makefile.boot >> b/arch/arm/mach-omap2/Makefile.boot >> index 0e602b7..a469a55 100644 >> --- a/arch/arm/mach-omap2/Makefile.boot >> +++ b/arch/arm/mach-omap2/Makefile.boot >> @@ -3,7 +3,8 @@ params_phys-y:= 0x8100 >> initrd_phys-y := 0x8080 >> >> dtb-$(CONFIG_SOC_OMAP2420) += omap2420-h4.dtb >> -dtb-$(CONFIG_ARCH_OMAP3)+= omap3-beagle-xm.dtb omap3-evm.dtb >> +dtb-$(CONFIG_ARCH_OMAP3)+= omap3-beagle.dtb omap3-beagle-xm.dtb \ >> + omap3-evm.dtb You'd better duplicate the whole line like it is done for OMAP4 instead of using the "\" +dtb-$(CONFIG_ARCH_OMAP3) += omap3-evm.dtb Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 00/21] OMAP UART Patches
On Tue, Sep 11, 2012 at 05:01:06PM +0530, Shubhrajyoti wrote: > On Sunday 09 September 2012 12:34 AM, Felipe Balbi wrote: > >> In addition, IMO, if this was only tested on Panda (as suggested by > >> > earlier cover letters), it really should not have been merged until it > >> > got some broader testing. > > Shubhro's got his Tested-by tag. I believe he tested on beagleboard and > > omap4sdp. Shubhro, can you confirm which platforms you tested the UART > > patches ? cheers > Felipe I had boot tested on omap3sdp and onap4 sdp and did pm testing > on both with omap3 hitting off. Thanks ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCHv7 00/23]I2C big cleanup
Hi, On Tue, Sep 11, 2012 at 03:48:34PM +0530, Shubhrajyoti wrote: > On Tuesday 11 September 2012 03:11 PM, Shubhrajyoti D wrote: > > Changes since v1: > >- removed tabification on patch 6/17 > >- removed dev_err() which was introduced on patch 09/17 > > Changes since v2: > > - do not set full fifo depth in the RDR interrupt. > > - some changelog updates. > > - rebase to the Wolfram's tree. > > Changes since v3: > > - Remove a redundant read of status register > > - Read the dev->buf_len variable instead of the register > > as the information of the remaining bytes is there. > > Changes since v4: > > - Ack the arbitration lost. > > - Rebase to the i2c-embedded/for-next branch. > > Changes since v5: > > - Rebase to latest mainline > > - Added some more cleanup patches so as have a consolidated series. > > Changes since v6: > > - Fix comments on setting the pdev to NULL. > > - Trivial changelog update > > > > Previous discussions can be found here > > http://www.spinics.net/lists/linux-i2c/msg09482.html > Also this gives better performance > With the patches: > > Performance counter stats for '/build/i2c/bin/i2cdump -y -f 1 0x48 > b': > > > > 78.796376 task-clock#0.453 CPUs > utilized >516 context-switches #0.007 > M/sec > 0 CPU-migrations#0.000 > K/sec >114 page-faults #0.001 M/sec > > 0.174011183 seconds time elapsed > > Without the patches > Performance counter stats for '/build/i2c/bin/i2cdump -y -f 1 0x48 > b': > > > > 123.504640 task-clock#0.049 CPUs > utilized >337 context-switches #0.003 > M/sec > 0 CPU-migrations#0.000 > K/sec >144 page-faults #0.001 > M/sec > > > > >2.534424040 seconds time elapsed > > The auto suspend is probably the one :-) Awesome, I didn't go as far as checking performance counters :-) -- balbi signature.asc Description: Digital signature
Re: [PATCH] omap: remoteproc: set bootaddr support
Hi Juan, On Wed, Aug 15, 2012 at 6:25 PM, Juan Gutierrez wrote: > Some remote processors (like Omap4's DSP) need to explicitly > set a boot address from which they start executing code when > taken out of reset. > > Support for this has been added to remoteproc code through > a set_bootaddr function in the platform data which, if needed, > must be set according to the backend rproc. > > For omap4's dsp we can use the next control funtion: > > .set_bootaddr = omap_ctrl_write_dsp_boot_addr > > Signed-off-by: Juan Gutierrez Applied with slight changes to the commit log. Thanks! Ohad. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/16] ARM: big platform data header rename
As we discussed at the ARM mini summit in San Diego, we are
going to move all platform specific header files that are used
in drivers out of the mach-* directories, at least for those
platforms that we want to have in a multiplatform kernel.
A big step in this direction is to move all the platform_data
definitions into include/linux/platform_data/. This takes
care of about a third of the header files in question and
should be relatively uncontroversial.
I changed the file names after the rename to be
include/linux/${subsystem}-${driver}.h where possible, to
have a more consistent naming there.
I would like to merge the series through the arm-soc tree
as an early branch so other branches can be based on top
or merge this branch into the other one to avoid conflicts.
Platform maintainers: please provide ACKs so I can take
it into the for-next branch as a stable sub-branch.
Driver maintainers: There should be nothing controversial
here, just a heads-up so you know that some one-line changes
are coming through the arm-soc tree that might cause an
occasional merge conflict. I've put a lot of people on
bcc in this mail so they know what the individual ones are
about. If you have specific comments, please reply on the
patches you are Cc'd on.
Arnd
Arnd Bergmann (16):
ARM: at91: move platform_data definitions
ARM: davinci: move platform_data definitions
ARM: ep93xx: move platform_data definitions
ARM: imx: move platform_data definitions
ARM: msm: move platform_data definitions
ARM: netx: move platform_data definitions
ARM: pxa: move platform_data definitions
ARM: sa1100: move platform_data definitions
ARM: tegra: move platform_data definitions
ARM: vt8500: move platform_data definitions
ARM: w90x900: move platform_data definitions
ARM: nomadik: move platform_data definitions
ARM: omap: move platform_data definitions
ARM: orion: move platform_data definitions
ARM: samsung: move platform_data definitions
ARM: spear: move platform_data definitions
Documentation/spi/ep93xx_spi |2 +-
arch/arm/mach-at91/at91sam9g45_devices.c |2 +-
arch/arm/mach-at91/at91sam9rl_devices.c|2 +-
arch/arm/mach-at91/include/mach/at_hdmac.h | 61 ---
arch/arm/mach-at91/include/mach/atmel-mci.h|2 +-
arch/arm/mach-davinci/aemif.c |2 +-
arch/arm/mach-davinci/board-da830-evm.c|8 +-
arch/arm/mach-davinci/board-da850-evm.c|6 +-
arch/arm/mach-davinci/board-dm355-evm.c|8 +-
arch/arm/mach-davinci/board-dm355-leopard.c|8 +-
arch/arm/mach-davinci/board-dm365-evm.c|8 +-
arch/arm/mach-davinci/board-dm644x-evm.c | 10 +-
arch/arm/mach-davinci/board-dm646x-evm.c |6 +-
arch/arm/mach-davinci/board-mityomapl138.c |4 +-
arch/arm/mach-davinci/board-neuros-osd2.c |8 +-
arch/arm/mach-davinci/board-sffsdr.c |4 +-
arch/arm/mach-davinci/davinci.h|4 +-
arch/arm/mach-davinci/devices.c|4 +-
arch/arm/mach-davinci/dm355.c |4 +-
arch/arm/mach-davinci/dm365.c |6 +-
arch/arm/mach-davinci/dm644x.c |2 +-
arch/arm/mach-davinci/dm646x.c |2 +-
arch/arm/mach-davinci/include/mach/aemif.h | 36
arch/arm/mach-davinci/include/mach/asp.h | 137 ---
arch/arm/mach-davinci/include/mach/da8xx.h | 10 +-
arch/arm/mach-davinci/include/mach/i2c.h | 26 ---
arch/arm/mach-davinci/include/mach/keyscan.h | 42 -
arch/arm/mach-davinci/include/mach/mmc.h | 39 -
arch/arm/mach-davinci/include/mach/nand.h | 90 --
arch/arm/mach-davinci/include/mach/spi.h | 89 --
arch/arm/mach-davinci/include/mach/tnetv107x.h |4 +-
arch/arm/mach-davinci/include/mach/usb.h | 59 ---
arch/arm/mach-davinci/usb.c|2 +-
arch/arm/mach-dove/common.c|2 +-
arch/arm/mach-ep93xx/core.c|6 +-
arch/arm/mach-ep93xx/dma.c |2 +-
arch/arm/mach-ep93xx/edb93xx.c |4 +-
arch/arm/mach-ep93xx/include/mach/dma.h| 93 ---
arch/arm/mach-ep93xx/include/mach/ep93xx_keypad.h | 35
arch/arm/mach-ep93xx/include/mach/ep93xx_spi.h | 29
arch/arm/mach-ep93xx/include/mach/fb.h | 56 ---
arch/arm/mach-ep93xx/simone.c |2 +-
arch/arm/mach-ep93xx/snappercl15.c |2 +-
arch/arm/mach-ep93xx/vision_ep9307.c |4 +-
arch/arm/mach-exynos/dev-audio.c |2 +-
arch/arm/mach-exynos/dev-ohci.c|2 +-
arch/arm/mach-exynos/include/mach/ohci.h | 21 ---
Re: Seeking clarity on IRQCHIP_MASK_ON_SUSPEND
On Tue, 11 Sep 2012, NeilBrown wrote: > On Mon, 10 Sep 2012 12:28:35 +0200 (CEST) Thomas Gleixner > wrote: > > You might be looking for a different functionality. Can you explain > > what you need? > > I want as particular GPIO interrupt to be masked before entering suspend. > I produced code to get the ->suspend() callback to perform this masking. > Another developer (Santosh) felt that IRQCHIP_MASK_ON_SUSPEND was the > preferred way to do this and on the surface this looks like it should be > correct. However it doesn't work as explained previously. > I want a resolution to this difference of opinion that doesn't just sweep the > issue under that carpet but provides a clear answer to this sort of issue. > > My current opinion is that IRQCHIP_MASK_ON_SUSPEND should be discarded. The > patch which introduced it says: > > Rather than working around this in the affected interrupt chip > implementations we can solve this elegant in the core code itself. > > It appears that the solution in core code, while elegant, is wrong. It > happens too late to be generally usable. It is easy enough to handle this Sigh. The flag was invented with the semantics to keep the current "check for any interrupt" pending functionality alive and then mask it right before going down, so only the designated wakeup interrupts can wake the device. That was the result of the discussion back then and that was what the developer wanted to achieve with his driver suspend hackery. > issue in the interrupt chip drivers so maybe that is the best place > to handle it. And have the same "keep track of wakeup interrupts" code over and over in the drivers. > The the very least I think we need a big comment saying the > IRQCHIP_MASK_ON_SUSPEND can only be used for irqchips which can always be > programmed, even when they are suspended from an runtime-PM perspective, > and that those chips must handle masking in their 'suspend' callback. Sigh, no. Either we make IRQCHIP_MASK_ON_SUSPEND into an implementation which masks the interrupts early, if the existing users find this acceptable or have a separate IRQCHIP_MASK_BEFORE_SUSPEND flag. This GPIO driver at hand is probably not the last one which requires this and we really want to do stuff in the core code instead of having random implementations of the same stuff all over the place. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/16] ARM: omap: move platform_data definitions
Platform data for device drivers should be defined in include/linux/platform_data/*.h, not in the architecture and platform specific directories. This moves such data out of the omap include directories Signed-off-by: Arnd Bergmann Cc: Tony Lindgren Cc: Kevin Hilman Cc: "Benoît Cousson" Cc: Dmitry Torokhov Cc: David Woodhouse Cc: Kyungmin Park Cc: Ohad Ben-Cohen Cc: Grant Likely Cc: Omar Ramirez Luna Cc: Greg Kroah-Hartman Cc: Tomi Valkeinen Cc: Florian Tobias Schandinat Cc: Peter Ujfalusi Cc: Jarkko Nikula Cc: Liam Girdwood Cc: Mark Brown Cc: Artem Bityutskiy Cc: Jean Pihet Cc: J Keerthy Cc: linux-omap@vger.kernel.org --- arch/arm/mach-omap1/board-ams-delta.c |2 +- arch/arm/mach-omap1/board-fsample.c|2 +- arch/arm/mach-omap1/board-h2.c |2 +- arch/arm/mach-omap1/board-h3.c |2 +- arch/arm/mach-omap1/board-htcherald.c |2 +- arch/arm/mach-omap1/board-innovator.c |2 +- arch/arm/mach-omap1/board-nokia770.c |4 ++-- arch/arm/mach-omap1/board-osk.c|2 +- arch/arm/mach-omap1/board-palmte.c |2 +- arch/arm/mach-omap1/board-palmtt.c |2 +- arch/arm/mach-omap1/board-palmz71.c|2 +- arch/arm/mach-omap1/board-perseus2.c |2 +- arch/arm/mach-omap1/board-sx1.c|2 +- arch/arm/mach-omap1/mcbsp.c|2 +- arch/arm/mach-omap2/board-3430sdp.c|2 +- arch/arm/mach-omap2/board-cm-t35.c |4 ++-- arch/arm/mach-omap2/board-cm-t3517.c |2 +- arch/arm/mach-omap2/board-devkit8000.c |4 ++-- arch/arm/mach-omap2/board-flash.c |4 ++-- arch/arm/mach-omap2/board-igep0020.c |2 +- arch/arm/mach-omap2/board-ldp.c|2 +- arch/arm/mach-omap2/board-n8x0.c |4 ++-- arch/arm/mach-omap2/board-omap3beagle.c|2 +- arch/arm/mach-omap2/board-omap3evm.c |4 ++-- arch/arm/mach-omap2/board-omap3pandora.c |4 ++-- arch/arm/mach-omap2/board-omap3stalker.c |4 ++-- arch/arm/mach-omap2/board-omap3touchbook.c |4 ++-- arch/arm/mach-omap2/board-overo.c |4 ++-- arch/arm/mach-omap2/board-rm680.c |2 +- arch/arm/mach-omap2/board-rx51-peripherals.c |4 ++-- arch/arm/mach-omap2/board-rx51-video.c |2 +- arch/arm/mach-omap2/board-rx51.c |2 +- arch/arm/mach-omap2/board-zoom-display.c |2 +- arch/arm/mach-omap2/common-board-devices.c |4 ++-- arch/arm/mach-omap2/devices.c |2 +- arch/arm/mach-omap2/dsp.c |2 +- arch/arm/mach-omap2/gpmc-nand.c|2 +- arch/arm/mach-omap2/gpmc-onenand.c |2 +- arch/arm/mach-omap2/mcbsp.c|2 +- arch/arm/mach-omap2/omap_hwmod_2420_data.c |2 +- arch/arm/mach-omap2/omap_hwmod_2430_data.c |4 ++-- arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |2 +- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |4 ++-- arch/arm/mach-omap2/omap_hwmod_44xx_data.c |4 ++-- arch/arm/mach-omap2/voltage.h |2 +- arch/arm/plat-omap/common.c|2 +- drivers/input/keyboard/omap-keypad.c |2 +- drivers/mtd/nand/omap2.c |2 +- drivers/mtd/onenand/omap2.c|2 +- drivers/remoteproc/omap_remoteproc.c |2 +- drivers/spi/spi-omap2-mcspi.c |2 +- drivers/staging/tidspbridge/core/dsp-clock.c |2 +- drivers/staging/tidspbridge/core/tiomap3430.c |2 +- drivers/staging/tidspbridge/core/tiomap3430_pwr.c |2 +- drivers/staging/tidspbridge/core/tiomap_io.c |2 +- drivers/staging/tidspbrid
[PATCH 13/16] ARM: omap: move platform_data definitions
Platform data for device drivers should be defined in include/linux/platform_data/*.h, not in the architecture and platform specific directories. This moves such data out of the omap include directories Signed-off-by: Arnd Bergmann Cc: Tony Lindgren Cc: Kevin Hilman Cc: "Benoît Cousson" Cc: Dmitry Torokhov Cc: David Woodhouse Cc: Kyungmin Park Cc: Ohad Ben-Cohen Cc: Grant Likely Cc: Omar Ramirez Luna Cc: Greg Kroah-Hartman Cc: Tomi Valkeinen Cc: Florian Tobias Schandinat Cc: Peter Ujfalusi Cc: Jarkko Nikula Cc: Liam Girdwood Cc: Mark Brown Cc: Artem Bityutskiy Cc: Jean Pihet Cc: J Keerthy Cc: linux-omap@vger.kernel.org --- arch/arm/mach-omap1/board-ams-delta.c |2 +- arch/arm/mach-omap1/board-fsample.c|2 +- arch/arm/mach-omap1/board-h2.c |2 +- arch/arm/mach-omap1/board-h3.c |2 +- arch/arm/mach-omap1/board-htcherald.c |2 +- arch/arm/mach-omap1/board-innovator.c |2 +- arch/arm/mach-omap1/board-nokia770.c |4 ++-- arch/arm/mach-omap1/board-osk.c|2 +- arch/arm/mach-omap1/board-palmte.c |2 +- arch/arm/mach-omap1/board-palmtt.c |2 +- arch/arm/mach-omap1/board-palmz71.c|2 +- arch/arm/mach-omap1/board-perseus2.c |2 +- arch/arm/mach-omap1/board-sx1.c|2 +- arch/arm/mach-omap1/mcbsp.c|2 +- arch/arm/mach-omap2/board-3430sdp.c|2 +- arch/arm/mach-omap2/board-cm-t35.c |4 ++-- arch/arm/mach-omap2/board-cm-t3517.c |2 +- arch/arm/mach-omap2/board-devkit8000.c |4 ++-- arch/arm/mach-omap2/board-flash.c |4 ++-- arch/arm/mach-omap2/board-igep0020.c |2 +- arch/arm/mach-omap2/board-ldp.c|2 +- arch/arm/mach-omap2/board-n8x0.c |4 ++-- arch/arm/mach-omap2/board-omap3beagle.c|2 +- arch/arm/mach-omap2/board-omap3evm.c |4 ++-- arch/arm/mach-omap2/board-omap3pandora.c |4 ++-- arch/arm/mach-omap2/board-omap3stalker.c |4 ++-- arch/arm/mach-omap2/board-omap3touchbook.c |4 ++-- arch/arm/mach-omap2/board-overo.c |4 ++-- arch/arm/mach-omap2/board-rm680.c |2 +- arch/arm/mach-omap2/board-rx51-peripherals.c |4 ++-- arch/arm/mach-omap2/board-rx51-video.c |2 +- arch/arm/mach-omap2/board-rx51.c |2 +- arch/arm/mach-omap2/board-zoom-display.c |2 +- arch/arm/mach-omap2/common-board-devices.c |4 ++-- arch/arm/mach-omap2/devices.c |2 +- arch/arm/mach-omap2/dsp.c |2 +- arch/arm/mach-omap2/gpmc-nand.c|2 +- arch/arm/mach-omap2/gpmc-onenand.c |2 +- arch/arm/mach-omap2/mcbsp.c|2 +- arch/arm/mach-omap2/omap_hwmod_2420_data.c |2 +- arch/arm/mach-omap2/omap_hwmod_2430_data.c |4 ++-- arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |2 +- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |4 ++-- arch/arm/mach-omap2/omap_hwmod_44xx_data.c |4 ++-- arch/arm/mach-omap2/voltage.h |2 +- arch/arm/plat-omap/common.c|2 +- drivers/input/keyboard/omap-keypad.c |2 +- drivers/mtd/nand/omap2.c |2 +- drivers/mtd/onenand/omap2.c|2 +- drivers/remoteproc/omap_remoteproc.c |2 +- drivers/spi/spi-omap2-mcspi.c |2 +- drivers/staging/tidspbridge/core/dsp-clock.c |2 +- drivers/staging/tidspbridge/core/tiomap3430.c |2 +- drivers/staging/tidspbridge/core/tiomap3430_pwr.c |2 +- drivers/staging/tidspbridge/core/tiomap_io.c |2 +- drivers/staging/tidspbrid
Re: [PATCH 13/16] ARM: omap: move platform_data definitions
Hi Arnd, On 09/11/2012 03:59 PM, Arnd Bergmann wrote: > Platform data for device drivers should be defined in > include/linux/platform_data/*.h, not in the architecture > and platform specific directories. > > This moves such data out of the omap include directories > > Signed-off-by: Arnd Bergmann > Cc: Tony Lindgren > Cc: Kevin Hilman > Cc: "Benoît Cousson" > Cc: Dmitry Torokhov > Cc: David Woodhouse > Cc: Kyungmin Park > Cc: Ohad Ben-Cohen > Cc: Grant Likely > Cc: Omar Ramirez Luna > Cc: Greg Kroah-Hartman > Cc: Tomi Valkeinen > Cc: Florian Tobias Schandinat > Cc: Peter Ujfalusi > Cc: Jarkko Nikula > Cc: Liam Girdwood > Cc: Mark Brown > Cc: Artem Bityutskiy > Cc: Jean Pihet > Cc: J Keerthy > Cc: linux-omap@vger.kernel.org > --- > arch/arm/mach-omap1/board-ams-delta.c |2 +- > arch/arm/mach-omap1/board-fsample.c|2 +- > arch/arm/mach-omap1/board-h2.c |2 +- > arch/arm/mach-omap1/board-h3.c |2 +- > arch/arm/mach-omap1/board-htcherald.c |2 +- > arch/arm/mach-omap1/board-innovator.c |2 +- > arch/arm/mach-omap1/board-nokia770.c |4 > ++-- > arch/arm/mach-omap1/board-osk.c|2 +- > arch/arm/mach-omap1/board-palmte.c |2 +- > arch/arm/mach-omap1/board-palmtt.c |2 +- > arch/arm/mach-omap1/board-palmz71.c|2 +- > arch/arm/mach-omap1/board-perseus2.c |2 +- > arch/arm/mach-omap1/board-sx1.c|2 +- > arch/arm/mach-omap1/mcbsp.c|2 +- > arch/arm/mach-omap2/board-3430sdp.c|2 +- > arch/arm/mach-omap2/board-cm-t35.c |4 > ++-- > arch/arm/mach-omap2/board-cm-t3517.c |2 +- > arch/arm/mach-omap2/board-devkit8000.c |4 > ++-- > arch/arm/mach-omap2/board-flash.c |4 > ++-- > arch/arm/mach-omap2/board-igep0020.c |2 +- > arch/arm/mach-omap2/board-ldp.c|2 +- > arch/arm/mach-omap2/board-n8x0.c |4 > ++-- > arch/arm/mach-omap2/board-omap3beagle.c|2 +- > arch/arm/mach-omap2/board-omap3evm.c |4 > ++-- > arch/arm/mach-omap2/board-omap3pandora.c |4 > ++-- > arch/arm/mach-omap2/board-omap3stalker.c |4 > ++-- > arch/arm/mach-omap2/board-omap3touchbook.c |4 > ++-- > arch/arm/mach-omap2/board-overo.c |4 > ++-- > arch/arm/mach-omap2/board-rm680.c |2 +- > arch/arm/mach-omap2/board-rx51-peripherals.c |4 > ++-- > arch/arm/mach-omap2/board-rx51-video.c |2 +- > arch/arm/mach-omap2/board-rx51.c |2 +- > arch/arm/mach-omap2/board-zoom-display.c |2 +- > arch/arm/mach-omap2/common-board-devices.c |4 > ++-- > arch/arm/mach-omap2/devices.c |2 +- > arch/arm/mach-omap2/dsp.c |2 +- > arch/arm/mach-omap2/gpmc-nand.c|2 +- > arch/arm/mach-omap2/gpmc-onenand.c |2 +- > arch/arm/mach-omap2/mcbsp.c|2 +- > arch/arm/mach-omap2/omap_hwmod_2420_data.c |2 +- > arch/arm/mach-omap2/omap_hwmod_2430_data.c |4 > ++-- > arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |2 +- > arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |4 > ++-- > arch/arm/mach-omap2/omap_hwmod_44xx_data.c |4 > ++-- > arch/arm/mach-omap2/voltage.h |2 +- > arch/arm/plat-omap/common.c|2 +- > drivers/input/keyboard/omap-keypad.c |2 +- > drivers/mtd/nand/omap2.c |2 +- > drivers/mtd/onenand/omap2.c|2 +- > drivers/remoteproc/omap_remoteproc.c |2 +- > drivers/spi/spi-omap2-mcspi.c |2 +- > drivers/staging/tidspbridge/core/dsp-clock.c |2 +-
Re: [PATCH 13/16] ARM: omap: move platform_data definitions
Arnd, On Tue, Sep 11, 2012 at 6:32 PM, Arnd Bergmann wrote: > Platform data for device drivers should be defined in > include/linux/platform_data/*.h, not in the architecture > and platform specific directories. > > This moves such data out of the omap include directories > > Signed-off-by: Arnd Bergmann [...] > 81 files changed, 87 insertions(+), 87 deletions(-) > rename arch/arm/plat-omap/include/plat/mcbsp.h => > include/linux/platform_data/dsp-mcbsp.h (100%) > rename arch/arm/plat-omap/include/plat/dsp.h => > include/linux/platform_data/dsp-omap.h (100%) > rename arch/arm/plat-omap/include/plat/keypad.h => > include/linux/platform_data/keypad-omap.h (100%) > rename arch/arm/plat-omap/include/plat/lcd_mipid.h => > include/linux/platform_data/lcd-mipid.h (100%) > rename arch/arm/plat-omap/include/plat/nand.h => > include/linux/platform_data/mtd-nand-omap2.h (100%) > rename arch/arm/plat-omap/include/plat/onenand.h => > include/linux/platform_data/mtd-onenand-omap2.h (100%) > rename arch/arm/plat-omap/include/plat/remoteproc.h => > include/linux/platform_data/remoteproc-omap.h (100%) > rename arch/arm/plat-omap/include/plat/voltage.h => > include/linux/platform_data/smartreflex-omap.h (100%) > rename arch/arm/plat-omap/include/plat/mcspi.h => > include/linux/platform_data/spi-omap2-mcspi.h (100%) > Just curious to know how you came with some of the above header names ? plat/mcbsp ---> dsp-mcbsp.h There is no connection of DSP with McBSP. "omap-mcbsp.h" would been a better name. plat/nand.h --> /mtd-nand-omap2.h plat/onenand.h --> /mtd-onenand-omap2.h May be "omap-nand.h" and "omap-onenand.h" plat/mcspi.h-->spi-omap2-mcspi.h May be "omap-spi.h" Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/16] ARM: omap: move platform_data definitions
On Tuesday 11 September 2012, Shilimkar, Santosh wrote: > Just curious to know how you came with some of the above header names ? > > plat/mcbsp ---> dsp-mcbsp.h > There is no connection of DSP with McBSP. "omap-mcbsp.h" would been a > better name. This one was a mistake on my side, as Tony and Peter already pointed out. How about asoc-mcbsp.h or asoc-omap-mcbsp.h? > plat/nand.h --> /mtd-nand-omap2.h > plat/onenand.h --> /mtd-onenand-omap2.h > May be "omap-nand.h" and "omap-onenand.h" > > plat/mcspi.h-->spi-omap2-mcspi.h > May be "omap-spi.h" > As I wrote in the introductory mail, I tried to always prefix the file names with the subsystem, followed by the name of the driver, in order to standardize on just one set of rules. The drivers implementing the three headers above are: drivers/mtd/nand/omap2.c drivers/mtd/onenand/omap2.c drivers/spi/spi-omap2-mcspi.c so these all seem appropriate. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/16] ARM: omap: move platform_data definitions
On Tue, Sep 11, 2012 at 7:47 PM, Arnd Bergmann wrote: > On Tuesday 11 September 2012, Shilimkar, Santosh wrote: >> Just curious to know how you came with some of the above header names ? >> >> plat/mcbsp ---> dsp-mcbsp.h >> There is no connection of DSP with McBSP. "omap-mcbsp.h" would been a >> better name. > > This one was a mistake on my side, as Tony and Peter already pointed out. > How about asoc-mcbsp.h or asoc-omap-mcbsp.h? > After re-reading the cover-letter and your below response, 'asoc-omap-mcbsp.h' seems to be fine. >> plat/nand.h --> /mtd-nand-omap2.h >> plat/onenand.h --> /mtd-onenand-omap2.h >> May be "omap-nand.h" and "omap-onenand.h" >> >> plat/mcspi.h-->spi-omap2-mcspi.h >> May be "omap-spi.h" >> > > As I wrote in the introductory mail, I tried to always prefix the file > names with the subsystem, followed by the name of the driver, in order > to standardize on just one set of rules. > Just read that now. > The drivers implementing the three headers above are: > > drivers/mtd/nand/omap2.c > drivers/mtd/onenand/omap2.c > drivers/spi/spi-omap2-mcspi.c > > so these all seem appropriate. > Sorry I missed the subsystem prefix point. These names seems to be fine then. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2] arm/dts: Add omap3-beagle.dts
Add a minimal dts for original OMAP3430/3530 version of the Beagle board. This
version of the Beagle board has 256MB of DDR and features the same TWL4030
power management IC (PMIC) as the Beagle board XM.
Given that the Beagle and Beagle-XM boards use the same PMIC, move the
definition of the VSIM regulator into the TWL4030.dtsi file so that we do not
need to duplicate in the Beagle board dts file.
This has been boot tested on an OMAP3530 Beagle board and verifing that the
SD/MMC interface is working with a SD card.
This patch is generated on top of Tony Lindgren's devel-dt branch [1].
V2 changes
- Rebased upon of devel-dt
- Corrected copyright date in omap3-beagle.dts file
- Added LED support after verifing that Beagle and Beagle XM have the same LED
configuration
[1] git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git devel-dt
Signed-off-by: Jon Hunter
---
arch/arm/boot/dts/omap3-beagle-xm.dts |6 ---
arch/arm/boot/dts/omap3-beagle.dts| 67 +
arch/arm/boot/dts/twl4030.dtsi|6 +++
arch/arm/mach-omap2/Makefile.boot |3 +-
4 files changed, 75 insertions(+), 7 deletions(-)
create mode 100644 arch/arm/boot/dts/omap3-beagle.dts
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index c38cf76..3705a81 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -55,12 +55,6 @@
interrupts = <7>; /* SYS_NIRQ cascaded to intc */
interrupt-parent = <&intc>;
- vsim: regulator-vsim {
- compatible = "ti,twl4030-vsim";
- regulator-min-microvolt = <180>;
- regulator-max-microvolt = <300>;
- };
-
twl_audio: audio {
compatible = "ti,twl4030-audio";
codec {
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
new file mode 100644
index 000..f624dc8
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -0,0 +1,67 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ "omap3.dtsi"
+
+/ {
+ model = "TI OMAP3 BeagleBoard";
+ compatible = "ti,omap3-beagle", "ti,omap3";
+
+ memory {
+ device_type = "memory";
+ reg = <0x8000 0x1000>; /* 256 MB */
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pmu_stat {
+ label = "beagleboard::pmu_stat";
+ gpios = <&twl_gpio 19 0>; /* LEDB */
+ };
+
+ heartbeat {
+ label = "beagleboard::usr0";
+ gpios = <&gpio5 22 0>; /* 150 -> D6 LED */
+ linux,default-trigger = "heartbeat";
+ };
+
+ mmc {
+ label = "beagleboard::usr1";
+ gpios = <&gpio5 21 0>; /* 149 -> D7 LED */
+ linux,default-trigger = "mmc0";
+ };
+ };
+
+};
+
+&i2c1 {
+ clock-frequency = <260>;
+
+ twl: twl@48 {
+ reg = <0x48>;
+ interrupts = <7>; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = <&intc>;
+ };
+};
+
+/include/ "twl4030.dtsi"
+
+&mmc1 {
+ vmmc-supply = <&vmmc1>;
+ vmmc_aux-supply = <&vsim>;
+ bus-width = <8>;
+};
+
+&mmc2 {
+ status = "disabled";
+};
+
+&mmc3 {
+ status = "disabled";
+};
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index ff00017..c5337d4 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -37,6 +37,12 @@
regulator-max-microvolt = <315>;
};
+ vsim: regulator-vsim {
+ compatible = "ti,twl4030-vsim";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <300>;
+ };
+
twl_gpio: gpio {
compatible = "ti,twl4030-gpio";
gpio-controller;
diff --git a/arch/arm/mach-omap2/Makefile.boot
b/arch/arm/mach-omap2/Makefile.boot
index be0fe92..384005a 100644
--- a/arch/arm/mach-omap2/Makefile.boot
+++ b/arch/arm/mach-omap2/Makefile.boot
@@ -3,7 +3,8 @@ params_phys-y := 0x8100
initrd_phys-y := 0x8080
dtb-$(CONFIG_SOC_OMAP2420) += omap2420-h4.dtb
-dtb-$(CONFIG_ARCH_OMAP3) += omap3-beagle-xm.dtb omap3-evm.dtb
omap3-tobi.dtb
+dtb-$(CONFIG_ARCH_OMAP3) += omap3-beagle.dtb omap3-beagle-xm.dtb
+dtb-$(CONFIG_ARCH_OMAP3) += omap3-evm.dtb omap3-tobi.dtb
dtb-$(CONFIG_ARCH_OMAP4) += omap4-panda.dt
Re: [PATCH 13/16] ARM: omap: move platform_data definitions
On 9/11/2012 7:54 PM, Shilimkar, Santosh wrote: > On Tue, Sep 11, 2012 at 7:47 PM, Arnd Bergmann wrote: >> On Tuesday 11 September 2012, Shilimkar, Santosh wrote: >>> Just curious to know how you came with some of the above header names ? >>> >>> plat/mcbsp ---> dsp-mcbsp.h >>> There is no connection of DSP with McBSP. "omap-mcbsp.h" would been a >>> better name. >> >> This one was a mistake on my side, as Tony and Peter already pointed out. >> How about asoc-mcbsp.h or asoc-omap-mcbsp.h? >> > After re-reading the cover-letter and your below response, > 'asoc-omap-mcbsp.h' seems to be fine. > Note that mcbsp is also applicable to Davinci family of devices. Thanks, Vaibhav >>> plat/nand.h --> /mtd-nand-omap2.h >>> plat/onenand.h --> /mtd-onenand-omap2.h >>> May be "omap-nand.h" and "omap-onenand.h" >>> >>> plat/mcspi.h-->spi-omap2-mcspi.h >>> May be "omap-spi.h" >>> >> >> As I wrote in the introductory mail, I tried to always prefix the file >> names with the subsystem, followed by the name of the driver, in order >> to standardize on just one set of rules. >> > Just read that now. > >> The drivers implementing the three headers above are: >> >> drivers/mtd/nand/omap2.c >> drivers/mtd/onenand/omap2.c >> drivers/spi/spi-omap2-mcspi.c >> >> so these all seem appropriate. >> > Sorry I missed the subsystem prefix point. > These names seems to be fine then. > > Regards > Santosh > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] staging: omap-thermal: Correct checkpatch.pl warnings
From: J Keerthy
Removes checkpatch warnings on omap-bandgap.c.
Signed-off-by: J Keerthy
Signed-off-by: Eduardo Valentin
---
drivers/staging/omap-thermal/omap-bandgap.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index c556abb..9ef44ea 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -1037,20 +1037,20 @@ static int omap_bandgap_save_ctxt(struct omap_bandgap
*bg_ptr)
if (OMAP_BANDGAP_HAS(bg_ptr, MODE_CONFIG))
rval->bg_mode_ctrl = omap_bandgap_readl(bg_ptr,
-
tsr->bgap_mode_ctrl);
+ tsr->bgap_mode_ctrl);
if (OMAP_BANDGAP_HAS(bg_ptr, COUNTER))
rval->bg_counter = omap_bandgap_readl(bg_ptr,
-
tsr->bgap_counter);
+ tsr->bgap_counter);
if (OMAP_BANDGAP_HAS(bg_ptr, TALERT)) {
rval->bg_threshold = omap_bandgap_readl(bg_ptr,
-
tsr->bgap_threshold);
+ tsr->bgap_threshold);
rval->bg_ctrl = omap_bandgap_readl(bg_ptr,
- tsr->bgap_mask_ctrl);
+ tsr->bgap_mask_ctrl);
}
if (OMAP_BANDGAP_HAS(bg_ptr, TSHUT_CONFIG))
rval->tshut_threshold = omap_bandgap_readl(bg_ptr,
-
tsr->tshut_threshold);
+ tsr->tshut_threshold);
}
return 0;
@@ -1074,8 +1074,9 @@ static int omap_bandgap_restore_ctxt(struct omap_bandgap
*bg_ptr)
if (val == 0) {
if (OMAP_BANDGAP_HAS(bg_ptr, TSHUT_CONFIG))
- omap_bandgap_writel(bg_ptr,
rval->tshut_threshold,
-
tsr->tshut_threshold);
+ omap_bandgap_writel(bg_ptr,
+ rval->tshut_threshold,
+ tsr->tshut_threshold);
/* Force immediate temperature measurement and update
* of the DTEMP field
*/
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] staging: omap-thermal: improve conf data handling and initialization
While registering the thermal zone, it is required to have the cooling
devices already setup, so that the .bind callback can succeed.
Due to that, the driver code needs to be reorganized so that we first
setup the cooling devices then the zones. This way we cope with the
right thermal framework initialization sequence.
This patch changes the order of the thermal zone initialization,
so that we create it only when the cooling devices are available.
It also adds some defensive checks for the config data, so that
the callbacks are ready for calls when the data is still not
initialized.
Signed-off-by: Eduardo Valentin
---
drivers/staging/omap-thermal/omap-bandgap.c|6 ++--
drivers/staging/omap-thermal/omap-thermal-common.c | 38 +---
2 files changed, 36 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index 9ef44ea..ff93c15 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -953,12 +953,12 @@ int __devinit omap_bandgap_probe(struct platform_device
*pdev)
for (i = 0; i < bg_ptr->conf->sensor_count; i++) {
char *domain;
+ if (bg_ptr->conf->sensors[i].register_cooling)
+ bg_ptr->conf->sensors[i].register_cooling(bg_ptr, i);
+
domain = bg_ptr->conf->sensors[i].domain;
if (bg_ptr->conf->expose_sensor)
bg_ptr->conf->expose_sensor(bg_ptr, i, domain);
-
- if (bg_ptr->conf->sensors[i].register_cooling)
- bg_ptr->conf->sensors[i].register_cooling(bg_ptr, i);
}
/*
diff --git a/drivers/staging/omap-thermal/omap-thermal-common.c
b/drivers/staging/omap-thermal/omap-thermal-common.c
index d156424..46ee0a9 100644
--- a/drivers/staging/omap-thermal/omap-thermal-common.c
+++ b/drivers/staging/omap-thermal/omap-thermal-common.c
@@ -77,10 +77,16 @@ static inline int omap_thermal_get_temp(struct
thermal_zone_device *thermal,
unsigned long *temp)
{
struct omap_thermal_data *data = thermal->devdata;
- struct omap_bandgap *bg_ptr = data->bg_ptr;
- struct omap_temp_sensor *s = &bg_ptr->conf->sensors[data->sensor_id];
+ struct omap_bandgap *bg_ptr;
+ struct omap_temp_sensor *s;
int ret, tmp, pcb_temp, slope, constant;
+ if (!data)
+ return 0;
+
+ bg_ptr = data->bg_ptr;
+ s = &bg_ptr->conf->sensors[data->sensor_id];
+
ret = omap_bandgap_read_temperature(bg_ptr, data->sensor_id, &tmp);
if (ret)
return ret;
@@ -227,21 +233,37 @@ static struct thermal_zone_device_ops omap_thermal_ops = {
.get_crit_temp = omap_thermal_get_crit_temp,
};
-int omap_thermal_expose_sensor(struct omap_bandgap *bg_ptr, int id,
- char *domain)
+static struct omap_thermal_data
+*omap_thermal_build_data(struct omap_bandgap *bg_ptr, int id)
{
struct omap_thermal_data *data;
data = devm_kzalloc(bg_ptr->dev, sizeof(*data), GFP_KERNEL);
if (!data) {
dev_err(bg_ptr->dev, "kzalloc fail\n");
- return -ENOMEM;
+ return NULL;
}
data->sensor_id = id;
data->bg_ptr = bg_ptr;
data->mode = THERMAL_DEVICE_ENABLED;
INIT_WORK(&data->thermal_wq, omap_thermal_work);
+ return data;
+}
+
+int omap_thermal_expose_sensor(struct omap_bandgap *bg_ptr, int id,
+ char *domain)
+{
+ struct omap_thermal_pdata pdata;
+
+ data = omap_bandgap_get_sensor_data(bg_ptr, id);
+
+ if (!data)
+ data = omap_thermal_build_pdata(bg_ptr, id);
+
+ if (!data)
+ return -EINVAL;
+
/* TODO: remove TC1 TC2 */
/* Create thermal zone */
data->omap_thermal = thermal_zone_device_register(domain,
@@ -335,6 +357,11 @@ int omap_thermal_register_cpu_cooling(struct omap_bandgap
*bg_ptr, int id)
int tab_size, ret;
data = omap_bandgap_get_sensor_data(bg_ptr, id);
+ if (!data)
+ data = omap_thermal_build_pdata(bg_ptr, id);
+
+ if (!data)
+ return -EINVAL;
ret = omap_thermal_build_cpufreq_clip(bg_ptr, &tab_ptr, &tab_size);
if (ret < 0) {
@@ -351,6 +378,7 @@ int omap_thermal_register_cpu_cooling(struct omap_bandgap
*bg_ptr, int id)
return PTR_ERR(data->cool_dev);
}
bg_ptr->conf->sensors[id].cooling_data.freq_clip_count = tab_size;
+ omap_bandgap_set_sensor_data(bg_ptr, id, data);
return 0;
}
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] staging: omap-thermal: fix polling period settings
While registering the omap thermal zones we need to
properly specify TC1 and TC2, as long as the proper
passive polling period and monitor period.
This patch fixes the parameters passed while registering
the thermal zone.
Signed-off-by: Eduardo Valentin
---
drivers/staging/omap-thermal/omap-thermal-common.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-thermal-common.c
b/drivers/staging/omap-thermal/omap-thermal-common.c
index 0675a5e..d156424 100644
--- a/drivers/staging/omap-thermal/omap-thermal-common.c
+++ b/drivers/staging/omap-thermal/omap-thermal-common.c
@@ -246,7 +246,9 @@ int omap_thermal_expose_sensor(struct omap_bandgap *bg_ptr,
int id,
/* Create thermal zone */
data->omap_thermal = thermal_zone_device_register(domain,
OMAP_TRIP_NUMBER, 0, data, &omap_thermal_ops,
- 0, FAST_TEMP_MONITORING_RATE, 0, 0);
+ 1, 2, /*TODO: remove this when FW allows */
+ FAST_TEMP_MONITORING_RATE,
+ FAST_TEMP_MONITORING_RATE);
if (IS_ERR_OR_NULL(data->omap_thermal)) {
dev_err(bg_ptr->dev, "thermal zone device is NULL\n");
return PTR_ERR(data->omap_thermal);
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] staging: omap-thermal: clean-ups and fixes
Hello Greg, Here are some patches to clean the omap-thermal driver code a bit. There are 2 fixes as well related to registration to thermal fw. These patches are based on staging-next tree. They are also available here: g...@gitorious.org:thermal-framework/thermal-framework.git thermal_work/omap/omap-thermal-fixes All best, Eduardo Valentin (3): staging: omap-thermal: remove checkpatch.pl warnings on data files staging: omap-thermal: fix polling period settings staging: omap-thermal: improve conf data handling and initialization J Keerthy (1): staging: omap-thermal: Correct checkpatch.pl warnings drivers/staging/omap-thermal/omap-bandgap.c| 21 drivers/staging/omap-thermal/omap-thermal-common.c | 42 +-- drivers/staging/omap-thermal/omap4-thermal.c | 54 ++-- drivers/staging/omap-thermal/omap5-thermal.c | 38 +++--- 4 files changed, 93 insertions(+), 62 deletions(-) -- 1.7.7.1.488.ge8e1c -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] staging: omap-thermal: remove checkpatch.pl warnings on data files
Simple checkpatch.pl clean ups.
Signed-off-by: Eduardo Valentin
---
drivers/staging/omap-thermal/omap4-thermal.c | 54 +-
drivers/staging/omap-thermal/omap5-thermal.c | 38 +-
2 files changed, 46 insertions(+), 46 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap4-thermal.c
b/drivers/staging/omap-thermal/omap4-thermal.c
index fa9dbcd..04c02b6 100644
--- a/drivers/staging/omap-thermal/omap4-thermal.c
+++ b/drivers/staging/omap-thermal/omap4-thermal.c
@@ -77,15 +77,15 @@ const struct omap_bandgap_data omap4430_data = {
.remove_sensor = omap_thermal_remove_sensor,
.sensors = {
{
- .registers = &omap4430_mpu_temp_sensor_registers,
- .ts_data = &omap4430_mpu_temp_sensor_data,
- .domain = "cpu",
- .slope = 0,
- .constant = 2,
- .slope_pcb = 0,
- .constant_pcb = 2,
- .register_cooling = omap_thermal_register_cpu_cooling,
- .unregister_cooling =
omap_thermal_unregister_cpu_cooling,
+ .registers = &omap4430_mpu_temp_sensor_registers,
+ .ts_data = &omap4430_mpu_temp_sensor_data,
+ .domain = "cpu",
+ .slope = 0,
+ .constant = 2,
+ .slope_pcb = 0,
+ .constant_pcb = 2,
+ .register_cooling = omap_thermal_register_cpu_cooling,
+ .unregister_cooling = omap_thermal_unregister_cpu_cooling,
},
},
.sensor_count = 1,
@@ -215,15 +215,15 @@ const struct omap_bandgap_data omap4460_data = {
.remove_sensor = omap_thermal_remove_sensor,
.sensors = {
{
- .registers = &omap4460_mpu_temp_sensor_registers,
- .ts_data = &omap4460_mpu_temp_sensor_data,
- .domain = "cpu",
- .slope = OMAP_GRADIENT_SLOPE_4460,
- .constant = OMAP_GRADIENT_CONST_4460,
- .slope_pcb = OMAP_GRADIENT_SLOPE_W_PCB_4460,
- .constant_pcb = OMAP_GRADIENT_CONST_W_PCB_4460,
- .register_cooling = omap_thermal_register_cpu_cooling,
- .unregister_cooling =
omap_thermal_unregister_cpu_cooling,
+ .registers = &omap4460_mpu_temp_sensor_registers,
+ .ts_data = &omap4460_mpu_temp_sensor_data,
+ .domain = "cpu",
+ .slope = OMAP_GRADIENT_SLOPE_4460,
+ .constant = OMAP_GRADIENT_CONST_4460,
+ .slope_pcb = OMAP_GRADIENT_SLOPE_W_PCB_4460,
+ .constant_pcb = OMAP_GRADIENT_CONST_W_PCB_4460,
+ .register_cooling = omap_thermal_register_cpu_cooling,
+ .unregister_cooling = omap_thermal_unregister_cpu_cooling,
},
},
.sensor_count = 1,
@@ -244,15 +244,15 @@ const struct omap_bandgap_data omap4470_data = {
.remove_sensor = omap_thermal_remove_sensor,
.sensors = {
{
- .registers = &omap4460_mpu_temp_sensor_registers,
- .ts_data = &omap4460_mpu_temp_sensor_data,
- .domain = "cpu",
- .slope = OMAP_GRADIENT_SLOPE_4470,
- .constant = OMAP_GRADIENT_CONST_4470,
- .slope_pcb = OMAP_GRADIENT_SLOPE_W_PCB_4470,
- .constant_pcb = OMAP_GRADIENT_CONST_W_PCB_4470,
- .register_cooling = omap_thermal_register_cpu_cooling,
- .unregister_cooling =
omap_thermal_unregister_cpu_cooling,
+ .registers = &omap4460_mpu_temp_sensor_registers,
+ .ts_data = &omap4460_mpu_temp_sensor_data,
+ .domain = "cpu",
+ .slope = OMAP_GRADIENT_SLOPE_4470,
+ .constant = OMAP_GRADIENT_CONST_4470,
+ .slope_pcb = OMAP_GRADIENT_SLOPE_W_PCB_4470,
+ .constant_pcb = OMAP_GRADIENT_CONST_W_PCB_4470,
+ .register_cooling = omap_thermal_register_cpu_cooling,
+ .unregister_cooling = omap_thermal_unregister_cpu_cooling,
},
},
.sensor_count = 1,
diff --git a/drivers/staging/omap-thermal/omap5-thermal.c
b/drivers/staging/omap-thermal/omap5-thermal.c
index 0658af2..2f3a498 100644
--- a/drivers/staging/omap-thermal/omap5-thermal.c
+++ b/drivers/staging/omap-thermal/omap5-thermal.c
@@ -268,29 +268,29 @@ const struct omap_bandgap_data omap5430_data = {
.remove_sensor = omap_thermal_remove_sensor,
.sensors = {
{
- .registers = &omap5430_mpu_temp_sensor_registers,
- .ts_data = &omap5430_mpu_temp_sensor_data,
- .domain = "cpu",
-
[PATCH v10 2/5] usb: musb: kill global and static for multi instance
From: Ajay Kumar Gupta
Moved global variable "musb_debugfs_root" and static variable
"old_state" to 'struct musb' to help support multi instance of
musb controller as present on AM335x platform.
Also removed the global variable "orig_dma_mask" and filled the
dev->dma_mask with parent device's dma_mask.
Signed-off-by: Ajay Kumar Gupta
Signed-off-by: Santhapuri, Damodar
Signed-off-by: Ravi Babu
Signed-off-by: Felipe Balbi
---
drivers/usb/musb/musb_core.c| 22 +++---
drivers/usb/musb/musb_core.h|4
drivers/usb/musb/musb_debugfs.c |8 +++-
3 files changed, 14 insertions(+), 20 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 61b64fc..bb56a0e 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -100,6 +100,7 @@
#include
#include
#include
+#include
#include "musb_core.h"
@@ -1797,10 +1798,9 @@ static const struct attribute_group musb_attr_group = {
static void musb_irq_work(struct work_struct *data)
{
struct musb *musb = container_of(data, struct musb, irq_work);
- static int old_state;
- if (musb->xceiv->state != old_state) {
- old_state = musb->xceiv->state;
+ if (musb->xceiv->state != musb->xceiv_old_state) {
+ musb->xceiv_old_state = musb->xceiv->state;
sysfs_notify(&musb->controller->kobj, NULL, "mode");
}
}
@@ -2060,11 +2060,6 @@ fail0:
/* all implementations (PCI bridge to FPGA, VLYNQ, etc) should just
* bridge to a platform device; this driver then suffices.
*/
-
-#ifndef CONFIG_MUSB_PIO_ONLY
-static u64 *orig_dma_mask;
-#endif
-
static int __devinit musb_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -2083,10 +2078,6 @@ static int __devinit musb_probe(struct platform_device
*pdev)
return -ENOMEM;
}
-#ifndef CONFIG_MUSB_PIO_ONLY
- /* clobbered by use_dma=n */
- orig_dma_mask = dev->dma_mask;
-#endif
status = musb_init_controller(dev, irq, base);
if (status < 0)
iounmap(base);
@@ -2096,7 +2087,8 @@ static int __devinit musb_probe(struct platform_device
*pdev)
static int __devexit musb_remove(struct platform_device *pdev)
{
- struct musb *musb = dev_to_musb(&pdev->dev);
+ struct device *dev = &pdev->dev;
+ struct musb *musb = dev_to_musb(dev);
void __iomem*ctrl_base = musb->ctrl_base;
/* this gets called on rmmod.
@@ -2109,9 +2101,9 @@ static int __devexit musb_remove(struct platform_device
*pdev)
musb_free(musb);
iounmap(ctrl_base);
- device_init_wakeup(&pdev->dev, 0);
+ device_init_wakeup(dev, 0);
#ifndef CONFIG_MUSB_PIO_ONLY
- pdev->dev.dma_mask = orig_dma_mask;
+ dma_set_mask(dev, *dev->parent->dma_mask);
#endif
return 0;
}
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index a69ffd6..c158aac 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -437,6 +437,10 @@ struct musb {
#ifdef MUSB_CONFIG_PROC_FS
struct proc_dir_entry *proc_entry;
#endif
+ int xceiv_old_state;
+#ifdef CONFIG_DEBUG_FS
+ struct dentry *debugfs_root;
+#endif
};
static inline struct musb *gadget_to_musb(struct usb_gadget *g)
diff --git a/drivers/usb/musb/musb_debugfs.c b/drivers/usb/musb/musb_debugfs.c
index 40a37c9..1d6e8af 100644
--- a/drivers/usb/musb/musb_debugfs.c
+++ b/drivers/usb/musb/musb_debugfs.c
@@ -103,8 +103,6 @@ static const struct musb_register_map musb_regmap[] = {
{ }/* Terminating Entry */
};
-static struct dentry *musb_debugfs_root;
-
static int musb_regdump_show(struct seq_file *s, void *unused)
{
struct musb *musb = s->private;
@@ -241,7 +239,7 @@ int __devinit musb_init_debugfs(struct musb *musb)
struct dentry *file;
int ret;
- root = debugfs_create_dir("musb", NULL);
+ root = debugfs_create_dir(dev_name(musb->controller), NULL);
if (!root) {
ret = -ENOMEM;
goto err0;
@@ -261,7 +259,7 @@ int __devinit musb_init_debugfs(struct musb *musb)
goto err1;
}
- musb_debugfs_root = root;
+ musb->debugfs_root = root;
return 0;
@@ -274,5 +272,5 @@ err0:
void /* __init_or_exit */ musb_exit_debugfs(struct musb *musb)
{
- debugfs_remove_recursive(musb_debugfs_root);
+ debugfs_remove_recursive(musb->debugfs_root);
}
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v10 5/5] usb: musb: dsps: remove explicit NOP device creation
From: Ajay Kumar Gupta As NOP device node is now added in am33xx tree so remove the call which creates the NOP platform_device. Signed-off-by: Ajay Kumar Gupta Signed-off-by: Santhapuri, Damodar Signed-off-by: Ravi Babu Signed-off-by: Felipe Balbi --- drivers/usb/musb/musb_dsps.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index b8aecbb..2785e28 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -376,8 +376,7 @@ static int dsps_musb_init(struct musb *musb) /* mentor core register starts at offset of 0x400 from musb base */ musb->mregs += wrp->musb_core_offset; - /* NOP driver needs change if supporting dual instance */ - usb_nop_xceiv_register(); + /* Get the NOP PHY */ musb->xceiv = usb_get_phy(USB_PHY_TYPE_USB2); if (IS_ERR_OR_NULL(musb->xceiv)) return -ENODEV; -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v10 0/5] usb: musb: adding multi instance support
This series of patches adds multi instances support in musb driver AM33xx and TI81xx has dual musb controller and has two usb PHY of same type. The series applies to felipe/musb branch + Vaibhav baseport patches on his tree at [4] + Kishon's multi phy patches on Felipe's branch 'xceiv' + Kishon's patch on phandle at [2] + Damodar's recent patch at [3] + Ajay's & Damodar's patches at [5] and [6] included in this series 1. http://git.kernel.org/?p=linux/kernel/git/balbi/usb.git;a=summary 2. http://marc.info/?l=linux-usb&m=134070369306112&w=2 3. http://marc.info/?l=linux-usb&m=134200284230689&w=2 4. https://github.com/hvaibhav/am335x-linux/commits/am335x-upstream-staging 5. http://marc.info/?l=linux-usb&m=134200285530701&w=2 6. http://marc.info/?l=linux-usb&m=134208820028625&w=2 Changes from v9: - patches rebased on felipe/musb - DT and xceiv patches not included in this series Changes from v8: - included Sergei's comment, removing underscore in device tree file - removed duplicated signoff from patches Changes from v7: - patches rebased on felipe/master branch & verified - included additional two patches 0001 & 0002 as part of this series which are already submitted [5] & [6] Changes from v6: - Removed parent_pdev to get glue and used dev_get_getdrv() as per Felipe's comment - use pr_debug() instead of pr_info() as per Felipe's comment Changes from v5: - Removed musb->id as per Felipe's comment - used nop_ida as per Felipe's comment Changes from v4: - Fixed Felipe's comment for adding EXPORT_SYMBOL_GPL() - Fixed Felipe's comment on using dev_set_mask() Changes from v3: - Fixed Kishon's comment on removing "id" from phy struct and removing unneeded "#else" part. Changes from v2: - Fixed Sergei's comment on not using address prefix in musb_dsps glue and nop transceiver dt dats. - Also removed the "ti" string in compatible property for nop data. Changes from v1: - Defined musb_ida to manage core ids based on Felipe's comment in [PATCH 01/11] Ajay Kumar Gupta (3): usb: musb: kill global and static for multi instance usb: musb: dsps: add dt support usb: musb: dsps: remove explicit NOP device creation B, Ravi (2): usb: musb: add musb_ida for multi instance support usb: musb: am335x: add support for dual instance .../devicetree/bindings/usb/am33xx-usb.txt | 14 ++ drivers/usb/musb/am35x.c | 42 -- drivers/usb/musb/blackfin.c| 26 +++- drivers/usb/musb/da8xx.c | 34 +++-- drivers/usb/musb/davinci.c | 34 +++-- drivers/usb/musb/musb_core.c | 53 +-- drivers/usb/musb/musb_core.h |6 + drivers/usb/musb/musb_debugfs.c|8 +- drivers/usb/musb/musb_dsps.c | 167 ++-- drivers/usb/musb/omap2430.c| 26 +++- drivers/usb/musb/tusb6010.c| 26 +++- drivers/usb/musb/ux500.c | 33 +++-- 12 files changed, 338 insertions(+), 131 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/am33xx-usb.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v10 1/5] usb: musb: add musb_ida for multi instance support
From: B, Ravi
Added musb_ida in musb_core.c to manage the multi core ids.
Signed-off-by: Ravi Babu
Signed-off-by: Ajay Kumar Gupta
Signed-off-by: Santhapuri, Damodar
Signed-off-by: Felipe Balbi
---
drivers/usb/musb/am35x.c | 42 --
drivers/usb/musb/blackfin.c | 26 --
drivers/usb/musb/da8xx.c | 34 --
drivers/usb/musb/davinci.c | 34 --
drivers/usb/musb/musb_core.c | 31 +++
drivers/usb/musb/musb_core.h |2 ++
drivers/usb/musb/musb_dsps.c | 25 ++---
drivers/usb/musb/omap2430.c | 26 --
drivers/usb/musb/tusb6010.c | 26 --
drivers/usb/musb/ux500.c | 33 +++--
10 files changed, 210 insertions(+), 69 deletions(-)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 9fbe736..de717b5 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -458,6 +458,7 @@ static int __devinit am35x_probe(struct platform_device
*pdev)
struct clk *clk;
int ret = -ENOMEM;
+ int musbid;
glue = kzalloc(sizeof(*glue), GFP_KERNEL);
if (!glue) {
@@ -465,38 +466,47 @@ static int __devinit am35x_probe(struct platform_device
*pdev)
goto err0;
}
- musb = platform_device_alloc("musb-hdrc", -1);
+ /* get the musb id */
+ musbid = musb_get_id(&pdev->dev, GFP_KERNEL);
+ if (musbid < 0) {
+ dev_err(&pdev->dev, "failed to allocate musb id\n");
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ musb = platform_device_alloc("musb-hdrc", musbid);
if (!musb) {
dev_err(&pdev->dev, "failed to allocate musb device\n");
- goto err1;
+ goto err2;
}
phy_clk = clk_get(&pdev->dev, "fck");
if (IS_ERR(phy_clk)) {
dev_err(&pdev->dev, "failed to get PHY clock\n");
ret = PTR_ERR(phy_clk);
- goto err2;
+ goto err3;
}
clk = clk_get(&pdev->dev, "ick");
if (IS_ERR(clk)) {
dev_err(&pdev->dev, "failed to get clock\n");
ret = PTR_ERR(clk);
- goto err3;
+ goto err4;
}
ret = clk_enable(phy_clk);
if (ret) {
dev_err(&pdev->dev, "failed to enable PHY clock\n");
- goto err4;
+ goto err5;
}
ret = clk_enable(clk);
if (ret) {
dev_err(&pdev->dev, "failed to enable clock\n");
- goto err5;
+ goto err6;
}
+ musb->id= musbid;
musb->dev.parent= &pdev->dev;
musb->dev.dma_mask = &am35x_dmamask;
musb->dev.coherent_dma_mask = am35x_dmamask;
@@ -514,38 +524,41 @@ static int __devinit am35x_probe(struct platform_device
*pdev)
pdev->num_resources);
if (ret) {
dev_err(&pdev->dev, "failed to add resources\n");
- goto err6;
+ goto err7;
}
ret = platform_device_add_data(musb, pdata, sizeof(*pdata));
if (ret) {
dev_err(&pdev->dev, "failed to add platform_data\n");
- goto err6;
+ goto err7;
}
ret = platform_device_add(musb);
if (ret) {
dev_err(&pdev->dev, "failed to register musb device\n");
- goto err6;
+ goto err7;
}
return 0;
-err6:
+err7:
clk_disable(clk);
-err5:
+err6:
clk_disable(phy_clk);
-err4:
+err5:
clk_put(clk);
-err3:
+err4:
clk_put(phy_clk);
-err2:
+err3:
platform_device_put(musb);
+err2:
+ musb_put_id(&pdev->dev, musbid);
+
err1:
kfree(glue);
@@ -557,6 +570,7 @@ static int __devexit am35x_remove(struct platform_device
*pdev)
{
struct am35x_glue *glue = platform_get_drvdata(pdev);
+ musb_put_id(&pdev->dev, glue->musb->id);
platform_device_del(glue->musb);
platform_device_put(glue->musb);
clk_disable(glue->clk);
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index 54f1b98..26cc8b7 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -454,6 +454,7 @@ static int __devinit bfin_probe(struct platform_device
*pdev)
struct bfin_glue*glue;
int ret = -ENOMEM;
+ int musbid;
glue = kzalloc(sizeof(*glue), GFP_KERNEL);
if (!glue) {
@@ -461,12 +462,21 @@ static int __devinit bfin_probe(struct platform_d
[PATCH v10 3/5] usb: musb: am335x: add support for dual instance
From: B, Ravi
AM335x and TI81xx platform has dual musb controller so updating the
musb_dspc.c to support the same.
Changes:
- Moved otg_workaround timer to glue structure
- Moved static local variable last_timer to glue structure
- PHY on/off related cleanups
Signed-off-by: Ravi Babu
Signed-off-by: Ajay Kumar Gupta
Signed-off-by: Santhapuri, Damodar
[af...@ti.com: remove control module related modifications]
Signed-off-by: Afzal Mohammed
Signed-off-by: Felipe Balbi
---
drivers/usb/musb/musb_dsps.c | 81 +
1 files changed, 49 insertions(+), 32 deletions(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 5351e96..796fc60 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -105,6 +105,8 @@ struct dsps_musb_wrapper {
/* miscellaneous stuff */
u32 musb_core_offset;
u8 poll_seconds;
+ /* number of musb instances */
+ u8 instances;
};
/**
@@ -112,9 +114,10 @@ struct dsps_musb_wrapper {
*/
struct dsps_glue {
struct device *dev;
- struct platform_device *musb; /* child musb pdev */
+ struct platform_device *musb[2];/* child musb pdev */
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
- struct timer_list timer;/* otg_workaround timer */
+ struct timer_list timer[2]; /* otg_workaround timer */
+ unsigned long last_timer[2];/* last timer data for each instance */
};
/**
@@ -164,8 +167,8 @@ static void otg_timer(unsigned long _musb)
struct musb *musb = (void *)_musb;
void __iomem *mregs = musb->mregs;
struct device *dev = musb->controller;
- struct platform_device *pdev = to_platform_device(dev->parent);
- struct dsps_glue *glue = platform_get_drvdata(pdev);
+ struct platform_device *pdev = to_platform_device(dev);
+ struct dsps_glue *glue = dev_get_drvdata(dev->parent);
const struct dsps_musb_wrapper *wrp = glue->wrp;
u8 devctl;
unsigned long flags;
@@ -201,7 +204,7 @@ static void otg_timer(unsigned long _musb)
case OTG_STATE_B_IDLE:
devctl = dsps_readb(mregs, MUSB_DEVCTL);
if (devctl & MUSB_DEVCTL_BDEVICE)
- mod_timer(&glue->timer,
+ mod_timer(&glue->timer[pdev->id],
jiffies + wrp->poll_seconds * HZ);
else
musb->xceiv->state = OTG_STATE_A_IDLE;
@@ -215,9 +218,8 @@ static void otg_timer(unsigned long _musb)
static void dsps_musb_try_idle(struct musb *musb, unsigned long timeout)
{
struct device *dev = musb->controller;
- struct platform_device *pdev = to_platform_device(dev->parent);
- struct dsps_glue *glue = platform_get_drvdata(pdev);
- static unsigned long last_timer;
+ struct platform_device *pdev = to_platform_device(dev);
+ struct dsps_glue *glue = dev_get_drvdata(dev->parent);
if (timeout == 0)
timeout = jiffies + msecs_to_jiffies(3);
@@ -227,22 +229,23 @@ static void dsps_musb_try_idle(struct musb *musb,
unsigned long timeout)
musb->xceiv->state == OTG_STATE_A_WAIT_BCON)) {
dev_dbg(musb->controller, "%s active, deleting timer\n",
otg_state_string(musb->xceiv->state));
- del_timer(&glue->timer);
- last_timer = jiffies;
+ del_timer(&glue->timer[pdev->id]);
+ glue->last_timer[pdev->id] = jiffies;
return;
}
- if (time_after(last_timer, timeout) && timer_pending(&glue->timer)) {
+ if (time_after(glue->last_timer[pdev->id], timeout) &&
+ timer_pending(&glue->timer[pdev->id])) {
dev_dbg(musb->controller,
"Longer idle timer already pending, ignoring...\n");
return;
}
- last_timer = timeout;
+ glue->last_timer[pdev->id] = timeout;
dev_dbg(musb->controller, "%s inactive, starting idle timer for %u
ms\n",
otg_state_string(musb->xceiv->state),
jiffies_to_msecs(timeout - jiffies));
- mod_timer(&glue->timer, timeout);
+ mod_timer(&glue->timer[pdev->id], timeout);
}
static irqreturn_t dsps_interrupt(int irq, void *hci)
@@ -250,8 +253,8 @@ static irqreturn_t dsps_interrupt(int irq, void *hci)
struct musb *musb = hci;
void __iomem *reg_base = musb->ctrl_base;
struct device *dev = musb->controller;
- struct platform_device *pdev = to_platform_device(dev->parent);
- struct dsps_glue *glue = platform_get_drvdata(pdev);
+ struct platform_device *pdev = to_platform_device(dev);
+ struct dsps_glue *glue = dev_get_drvdata(dev->parent);
[PATCH v10 4/5] usb: musb: dsps: add dt support
From: Ajay Kumar Gupta
Added device tree support for dsps musb glue driver and updated the
Documentation with device tree binding information.
Signed-off-by: Ajay Kumar Gupta
Signed-off-by: Santhapuri, Damodar
Signed-off-by: Ravi Babu
[af...@ti.com: use '-' instead of '_' for dt properties]
Signed-off-by: Afzal Mohammed
Signed-off-by: Felipe Balbi
---
.../devicetree/bindings/usb/am33xx-usb.txt | 14 +
drivers/usb/musb/musb_dsps.c | 60 +---
2 files changed, 65 insertions(+), 9 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/am33xx-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
new file mode 100644
index 000..ca8fa56
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -0,0 +1,14 @@
+AM33XX MUSB GLUE
+ - compatible : Should be "ti,musb-am33xx"
+ - ti,hwmods : must be "usb_otg_hs"
+ - multipoint : Should be "1" indicating the musb controller supports
+ multipoint. This is a MUSB configuration-specific setting.
+ - num_eps : Specifies the number of endpoints. This is also a
+ MUSB configuration-specific setting. Should be set to "16"
+ - ram_bits : Specifies the ram address size. Should be set to "12"
+ - port0_mode : Should be "3" to represent OTG. "1" signifies HOST and "2"
+ represents PERIPHERAL.
+ - port1_mode : Should be "1" to represent HOST. "3" signifies OTG and "2"
+ represents PERIPHERAL.
+ - power : Should be "250". This signifies the controller can supply upto
+ 500mA when operating in host mode.
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 796fc60..b8aecbb 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -31,6 +31,7 @@
#include
#include
+#include
#include
#include
#include
@@ -45,6 +46,10 @@
#include "musb_core.h"
+#ifdef CONFIG_OF
+static const struct of_device_id musb_dsps_of_match[];
+#endif
+
/**
* avoid using musb_readx()/musb_writex() as glue layer should not be
* dependent on musb core layer symbols.
@@ -448,6 +453,8 @@ static int __devinit dsps_create_musb_pdev(struct dsps_glue
*glue, u8 id)
struct device *dev = glue->dev;
struct platform_device *pdev = to_platform_device(dev);
struct musb_hdrc_platform_data *pdata = dev->platform_data;
+ struct device_node *np = pdev->dev.of_node;
+ struct musb_hdrc_config *config;
struct platform_device *musb;
struct resource *res;
struct resource resources[2];
@@ -499,14 +506,40 @@ static int __devinit dsps_create_musb_pdev(struct
dsps_glue *glue, u8 id)
glue->musb[id] = musb;
- pdata->platform_ops = &dsps_ops;
-
ret = platform_device_add_resources(musb, resources, 2);
if (ret) {
dev_err(dev, "failed to add resources\n");
goto err2;
}
+ if (np) {
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(&pdev->dev,
+ "failed to allocate musb platfrom data\n");
+ ret = -ENOMEM;
+ goto err2;
+ }
+
+ config = devm_kzalloc(&pdev->dev, sizeof(*config), GFP_KERNEL);
+ if (!config) {
+ dev_err(&pdev->dev,
+ "failed to allocate musb hdrc config\n");
+ goto err2;
+ }
+
+ of_property_read_u32(np, "num-eps", (u32 *)&config->num_eps);
+ of_property_read_u32(np, "ram-bits", (u32 *)&config->ram_bits);
+ sprintf(res_name, "port%d-mode", id);
+ of_property_read_u32(np, res_name, (u32 *)&pdata->mode);
+ of_property_read_u32(np, "power", (u32 *)&pdata->power);
+ config->multipoint = of_property_read_bool(np, "multipoint");
+
+ pdata->config = config;
+ }
+
+ pdata->platform_ops = &dsps_ops;
+
ret = platform_device_add_data(musb, pdata, sizeof(*pdata));
if (ret) {
dev_err(dev, "failed to add platform_data\n");
@@ -538,13 +571,21 @@ static void dsps_delete_musb_pdev(struct dsps_glue *glue,
u8 id)
static int __devinit dsps_probe(struct platform_device *pdev)
{
- const struct platform_device_id *id = platform_get_device_id(pdev);
- const struct dsps_musb_wrapper *wrp =
- (struct dsps_musb_wrapper *)id->driver_data;
+ struct device_node *np = pdev->dev.of_node;
+ const struct of_device_id *match;
+ const struct dsps_musb_wrapper *wrp;
struct dsps_glue *glue;
struct resource *iomem;
int ret, i;
+ match = of_match_node(musb_dsps_of_match, np);
+ if (!match) {
+
Re: [PATCH 09/17] serial/8250: Limit the omap workarounds to omap1
On Mon, 10 Sep 2012 22:31:04 -0700
Tony Lindgren wrote:
> These workarounds do not apply for CONFIG_ARCH_OMAP2PLUS at all,
> so let's make it just CONFIG_ARCH_OMAP1.
>
> This is needed to for ARM common zImage changes for
> omap2+ to avoid including plat and mach headers.
>
> Cc: Alan Cox
> Cc: Greg Kroah-Hartman
> Cc: linux-ser...@vger.kernel.org
> Signed-off-by: Tony Lindgren
> ---
> drivers/tty/serial/8250/8250.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/serial/8250/8250.c
> b/drivers/tty/serial/8250/8250.c index 8123f78..5b3f2fe 100644
> --- a/drivers/tty/serial/8250/8250.c
> +++ b/drivers/tty/serial/8250/8250.c
> @@ -2336,7 +2336,7 @@ serial8250_do_set_termios(struct uart_port
> *port, struct ktermios *termios, serial_port_out(port, UART_EFR, efr);
> }
>
> -#ifdef CONFIG_ARCH_OMAP
> +#ifdef CONFIG_ARCH_OMAP1
> /* Workaround to enable 115200 baud on OMAP1510 internal
> ports */ if (cpu_is_omap1510() && is_omap_port(up)) {
> if (baud == 115200) {
> @@ -2426,7 +2426,7 @@ static unsigned int serial8250_port_size(struct
> uart_8250_port *pt) {
> if (pt->port.iotype == UPIO_AU)
> return 0x1000;
> -#ifdef CONFIG_ARCH_OMAP
> +#ifdef CONFIG_ARCH_OMAP1
> if (is_omap_port(pt))
> return 0x16 << pt->port.regshift;
> #endif
>
Acked-by: Alan Cox
Even better would be if for other cases is_omap_port and friends
returned 0...
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/10] ARM: OMAP: Clean-up timer posted mode support
On 09/10/2012 07:58 PM, Tony Lindgren wrote: > * Jon Hunter [120910 15:00]: >> >> On 09/07/2012 05:22 PM, Tony Lindgren wrote: >>> * Jon Hunter [120905 12:05]: The dmtimer functions to read and write the dmtimer registers are currently defined as follows ... static inline u32 __omap_dm_timer_read(struct omap_dm_timer *timer, u32 reg, int posted); static inline void __omap_dm_timer_write(struct omap_dm_timer *timer, u32 reg, u32 val, int posted); The posted variable indicates if the timer is configured to use the posted mode when performing register accesses. The posted mode configuration of the dmtimer is stored in the omap_dm_timer structure that is also being passed to the above functions and therefore we do not need to pass the posted variable separately. Therefore, simplify the above functions by removing the posted variable as an argument as this is not necessary. >>> >>> I believe the reason for passing the posted flag was to optimize out some >>> functions from the timer code as that's being run all the time. >>> >>> Care to check the assembly before and after this patch for the timer >>> functions with objdump -d to make sure it does not add tons of bloat >>> there? >> >> Hi Tony, >> >> Thanks for the details here. I see that makes sense and that the >> compiler could take advantage of this as the functions are inlined. >> >> I have taken a look at the disassembled output using objdump as you >> mentioned. What I see is ... >> >> 1. For dmtimer.c the impact appears negligible, the total number of >>lines outputted by objdump only changed by 8 with (1215 lines) and >>without (1207 lines) the patch applied. >> >> 2. For timer.c the impact is greater. I see that >>omap2_gp_timer_set_next_event() increased by 6 instructions from 29 >>to 35. clocksource_read_cycles() increased by 2 instructions 15 to >>17 instructions. dmtimer_read_sched_clock() increased by 2 >>instructions from 17 to 19. omap2_gp_timer_set_mode() increased by >>21 instructions from 102 to 123. >> >> I imagine that we are mainly concerned about >> omap2_gp_timer_set_next_event(), clocksource_read_cycles() and >> dmtimer_read_sched_clock() as these will be called often. Therefore, I >> am not sure if you wish to drop this patch. > > Well does it at lots of new ldr to the critical code? For the omap2_gp_timer_set_next_event() function it adds 3 load instructions, increasing the number of possible loads from 11 to 14. For the clocksource_read_cycles() function it adds 1 load instruction, increasing the number of possible loads from 7 to 8. For the dmtimer_read_sched_clock() function, I don't see any additional loads, but instructions added are a tst and beq instruction. >> By the way, if we do drop this patch, I would then need to fix the >> setting of the posted variable in mach-omap2/timer.c for clock-source in >> the case where a dmtimer is used. Today the code assumes that for >> clock-source and clock-events posted mode is always used. However, with >> the errata i103/i767 we will disable posted mode for clock-source on >> omap2/3/4/5/am33xx devices. > > Yes I see, I guess that means just adding a new systimer entry? Actually, I think we can avoid that by not using posted mode for clock-source timers at all. Posted mode only benefits the clock-events timers that are configured often. The benefit of not using posted mode for clock-source timers and setting the "posted" parameter to 0, will really allow the compiler to optimise the clocksource_read_cycles() and dmtimer_read_sched_clock() quite a bit. So this could be a nice optimisation. Cheers Jon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: mux: add support for PAD wakeup event handler
* Munegowda, Keshava [120911 00:43]:
> On Tue, Sep 11, 2012 at 12:09 AM, Tony Lindgren wrote:
> > * Ruslan Bilovol [120910 03:39]:
> >> OMAP mux now parses active wakeup events from pad registers and calls
> >> corresponding handler, if handler is not registered - corresponding
> >> hwmod ISRs once a wakeup is detected.
> >> This is useful for cases when routing wakeups to corresponding hwmod
> >> ISRs complicates those ISRs handlers (for example, ISR handler may
> >> not know who the interrupt source is)
> >
> > The mux code in arch/arm/mach-omap2 will be going away and replaced
> > by device tree based pinctrl-single.
>
> Thanks tony
>when is this device tree based pinctrl-single will be available
> in mainline?
It is already merged during v3.6 merge window, please see:
drivers/pinctrl/pinctrl-single.c
Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
For omap-serial, see the patch "serial: omap: Request pins using pinctrl
framework" in tty-next.
Then for setting up wake-up events, you can define alternative
named states, such as:
default: driver specific static pins that only get set once during the probe
active: subset of driver specific dynamic pins that are remuxed for runtime
idle:subset of driver specific dynamic pins that are remuxed for idle
Then just in the pinctrl using driver probe do:
foo->pins = pinctrl_get_select_default(&pdev->dev);
...
foo->pins_active = pinctrl_lookup_state(foo->pins, "active");
...
foo->pins_idle = pinctrl_lookup_state(foo->pins, PINCTRL_STATE_IDLE);
...
And then you can toggle the pin settings in foo_runtime_suspend and
resume:
if (foo->pins_idle) {
int res;
res = pinctrl_select_state(foo->pins, foo->pins_idle);
...
}
I don't think we have anything available for handling the wake-up
events yet in the pinctrl framework, but that should be added in
a Linux generic way to pinctrl framework so drivers can set up
their wake-up handles. That we we don't end up patching a custom
framework that's going away.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/3] GPMC driver conversion
* Mohammed, Afzal [120911 03:54]: > Hi Tony, > > On Sat, Sep 08, 2012 at 03:40:34, Tony Lindgren wrote: > > > Great, this all looks good to me. I suggest that on top of this > > we add minimal devicetree binding that does not even attempt to > > deal with the timings yet. > > > > Then once the minimal devicetree binding is in place, we can > > call the current GPMC timing functions using the compatible flags > > and auxdata in the gpmc.c driver. > > > > That way we get all the legacy boards booting with GPMC support > > for smsc911x etc, and can even remove some less used board-*.c > > files. > > Thanks. I agree with your suggestion and would be proceeding so > as to achieve minimal devicetree support. > > And a newer version of this series has been posted. OK great! > > Then we just add the generic GPMC timings when we're happy with > > those. > > Meanwhile can you send me the gpmc debug logs for n800 where tusb > patch on generic timing was causing the hang along with logs > without the culprit tusb patch so that we could arrive at generic > gpmc timings. Yes sorry been meaning to do that but keep getting distracted continuously somehow.. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/10] ARM: OMAP: Clean-up timer posted mode support
* Jon Hunter [120911 09:26]: > > On 09/10/2012 07:58 PM, Tony Lindgren wrote: > > * Jon Hunter [120910 15:00]: > >> > >> On 09/07/2012 05:22 PM, Tony Lindgren wrote: > >>> * Jon Hunter [120905 12:05]: > The dmtimer functions to read and write the dmtimer registers are > currently > defined as follows ... > > static inline u32 __omap_dm_timer_read(struct omap_dm_timer *timer, u32 > reg, > int posted); > static inline void __omap_dm_timer_write(struct omap_dm_timer *timer, > u32 reg, u32 val, int posted); > > The posted variable indicates if the timer is configured to use the > posted mode > when performing register accesses. The posted mode configuration of the > dmtimer > is stored in the omap_dm_timer structure that is also being passed to > the above > functions and therefore we do not need to pass the posted variable > separately. > Therefore, simplify the above functions by removing the posted variable > as an > argument as this is not necessary. > >>> > >>> I believe the reason for passing the posted flag was to optimize out some > >>> functions from the timer code as that's being run all the time. > >>> > >>> Care to check the assembly before and after this patch for the timer > >>> functions with objdump -d to make sure it does not add tons of bloat > >>> there? > >> > >> Hi Tony, > >> > >> Thanks for the details here. I see that makes sense and that the > >> compiler could take advantage of this as the functions are inlined. > >> > >> I have taken a look at the disassembled output using objdump as you > >> mentioned. What I see is ... > >> > >> 1. For dmtimer.c the impact appears negligible, the total number of > >>lines outputted by objdump only changed by 8 with (1215 lines) and > >>without (1207 lines) the patch applied. > >> > >> 2. For timer.c the impact is greater. I see that > >>omap2_gp_timer_set_next_event() increased by 6 instructions from 29 > >>to 35. clocksource_read_cycles() increased by 2 instructions 15 to > >>17 instructions. dmtimer_read_sched_clock() increased by 2 > >>instructions from 17 to 19. omap2_gp_timer_set_mode() increased by > >>21 instructions from 102 to 123. > >> > >> I imagine that we are mainly concerned about > >> omap2_gp_timer_set_next_event(), clocksource_read_cycles() and > >> dmtimer_read_sched_clock() as these will be called often. Therefore, I > >> am not sure if you wish to drop this patch. > > > > Well does it at lots of new ldr to the critical code? > > For the omap2_gp_timer_set_next_event() function it adds 3 load > instructions, increasing the number of possible loads from 11 to 14. > > For the clocksource_read_cycles() function it adds 1 load instruction, > increasing the number of possible loads from 7 to 8. > > For the dmtimer_read_sched_clock() function, I don't see any additional > loads, but instructions added are a tst and beq instruction. > > >> By the way, if we do drop this patch, I would then need to fix the > >> setting of the posted variable in mach-omap2/timer.c for clock-source in > >> the case where a dmtimer is used. Today the code assumes that for > >> clock-source and clock-events posted mode is always used. However, with > >> the errata i103/i767 we will disable posted mode for clock-source on > >> omap2/3/4/5/am33xx devices. > > > > Yes I see, I guess that means just adding a new systimer entry? > > Actually, I think we can avoid that by not using posted mode for > clock-source timers at all. Posted mode only benefits the clock-events > timers that are configured often. > > The benefit of not using posted mode for clock-source timers and setting > the "posted" parameter to 0, will really allow the compiler to optimise > the clocksource_read_cycles() and dmtimer_read_sched_clock() quite a > bit. So this could be a nice optimisation. OK up to you, but maybe run some benchmarks first to figure out what makes most sense? Updating the timer used to be a bottleneck earlier. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/17] serial/8250: Limit the omap workarounds to omap1
* Alan Cox [120911 09:25]:
> On Mon, 10 Sep 2012 22:31:04 -0700
> Tony Lindgren wrote:
>
> > These workarounds do not apply for CONFIG_ARCH_OMAP2PLUS at all,
> > so let's make it just CONFIG_ARCH_OMAP1.
> >
> > This is needed to for ARM common zImage changes for
> > omap2+ to avoid including plat and mach headers.
> >
> > Cc: Alan Cox
> > Cc: Greg Kroah-Hartman
> > Cc: linux-ser...@vger.kernel.org
> > Signed-off-by: Tony Lindgren
> > ---
> > drivers/tty/serial/8250/8250.c |4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/tty/serial/8250/8250.c
> > b/drivers/tty/serial/8250/8250.c index 8123f78..5b3f2fe 100644
> > --- a/drivers/tty/serial/8250/8250.c
> > +++ b/drivers/tty/serial/8250/8250.c
> > @@ -2336,7 +2336,7 @@ serial8250_do_set_termios(struct uart_port
> > *port, struct ktermios *termios, serial_port_out(port, UART_EFR, efr);
> > }
> >
> > -#ifdef CONFIG_ARCH_OMAP
> > +#ifdef CONFIG_ARCH_OMAP1
> > /* Workaround to enable 115200 baud on OMAP1510 internal
> > ports */ if (cpu_is_omap1510() && is_omap_port(up)) {
> > if (baud == 115200) {
> > @@ -2426,7 +2426,7 @@ static unsigned int serial8250_port_size(struct
> > uart_8250_port *pt) {
> > if (pt->port.iotype == UPIO_AU)
> > return 0x1000;
> > -#ifdef CONFIG_ARCH_OMAP
> > +#ifdef CONFIG_ARCH_OMAP1
> > if (is_omap_port(pt))
> > return 0x16 << pt->port.regshift;
> > #endif
> >
>
> Acked-by: Alan Cox
Thanks.
> Even better would be if for other cases is_omap_port and friends
> returned 0...
Yes it seems that those macros could be moved from plat-omap/serial.h
to live in drivers/tty/serial/8250/8250.h? Or do you have some better
place in mind?
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/16] ARM: omap: move platform_data definitions
On Tuesday 11 September 2012, Vaibhav Hiremath wrote: > On 9/11/2012 7:54 PM, Shilimkar, Santosh wrote: > > On Tue, Sep 11, 2012 at 7:47 PM, Arnd Bergmann wrote: > >> On Tuesday 11 September 2012, Shilimkar, Santosh wrote: > >>> Just curious to know how you came with some of the above header names ? > >>> > >>> plat/mcbsp ---> dsp-mcbsp.h > >>> There is no connection of DSP with McBSP. "omap-mcbsp.h" would been a > >>> better name. > >> > >> This one was a mistake on my side, as Tony and Peter already pointed out. > >> How about asoc-mcbsp.h or asoc-omap-mcbsp.h? > >> > > After re-reading the cover-letter and your below response, > > 'asoc-omap-mcbsp.h' seems to be fine. > > > > Note that mcbsp is also applicable to Davinci family of devices. asoc-ti-mcbsp.h then? Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/16] ARM: omap: move platform_data definitions
* Arnd Bergmann [120911 10:05]: > On Tuesday 11 September 2012, Vaibhav Hiremath wrote: > > On 9/11/2012 7:54 PM, Shilimkar, Santosh wrote: > > > On Tue, Sep 11, 2012 at 7:47 PM, Arnd Bergmann wrote: > > >> On Tuesday 11 September 2012, Shilimkar, Santosh wrote: > > >>> Just curious to know how you came with some of the above header names ? > > >>> > > >>> plat/mcbsp ---> dsp-mcbsp.h > > >>> There is no connection of DSP with McBSP. "omap-mcbsp.h" would been a > > >>> better name. > > >> > > >> This one was a mistake on my side, as Tony and Peter already pointed > > >> out. > > >> How about asoc-mcbsp.h or asoc-omap-mcbsp.h? > > >> > > > After re-reading the cover-letter and your below response, > > > 'asoc-omap-mcbsp.h' seems to be fine. > > > > > > > Note that mcbsp is also applicable to Davinci family of devices. > > asoc-ti-mcbsp.h then? Sounds good to me. Whatever the name ends up being: Acked-by: Tony Lindgren -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Add pinctrl support to omap2-mcspi
This series enables pinctrl support for McSPI. Platforms that boot only from DT and rely on pinctrl to set pinmuxes appropriately require this for omap2-mcspi operation. It has been tested on AM335x BeagleBone with an Adafruit SPI LCD attached and regression tested on Beagleboard xM booting in the !DT case, using board-omap3evm.c. There is a dependency on the patch to enable PINCTRL support (https://patchwork.kernel.org/patch/1376331/) for ARCH_OMAP2PLUS_TYPICAL. Matt Porter (2): spi: omap2-mcspi: add pinctrl support ARM: OMAP2+: Enable pinctrl dummy states arch/arm/mach-omap2/devices.c |4 drivers/spi/spi-omap2-mcspi.c |9 + 2 files changed, 13 insertions(+) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: OMAP2+: Enable pinctrl dummy states
Enable pinctrl dummy states for all OMAP platforms. This allows
drivers to be converted to pinctrl while still running on
platforms that do not provide pinctrl data.
Signed-off-by: Matt Porter
---
arch/arm/mach-omap2/devices.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index c00c689..577cd04 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -631,6 +632,9 @@ static inline void omap_init_vout(void) {}
static int __init omap2_init_devices(void)
{
+ /* Enable dummy states for those platforms without pinctrl support */
+ pinctrl_provide_dummies();
+
/*
* please keep these calls, and their implementations above,
* in alphabetical order so they're easier to sort through.
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] spi: omap2-mcspi: add pinctrl support
Adds pinctrl support to support OMAP platforms that boot from DT
and rely on pinctrl support to set pinmuxes.
Signed-off-by: Matt Porter
---
drivers/spi/spi-omap2-mcspi.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index b2fb141..6c67cdb 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -38,6 +38,8 @@
#include
#include
#include
+#include
+#include
#include
@@ -1124,6 +1126,7 @@ static int __devinit omap2_mcspi_probe(struct
platform_device *pdev)
static int bus_num = 1;
struct device_node *node = pdev->dev.of_node;
const struct of_device_id *match;
+ struct pinctrl *pinctrl;
master = spi_alloc_master(&pdev->dev, sizeof *mcspi);
if (master == NULL) {
@@ -1219,6 +1222,12 @@ static int __devinit omap2_mcspi_probe(struct
platform_device *pdev)
if (status < 0)
goto dma_chnl_free;
+ pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
+ if (IS_ERR(pinctrl)) {
+ status = PTR_ERR(pinctrl);
+ goto dma_chnl_free;
+ }
+
pm_runtime_use_autosuspend(&pdev->dev);
pm_runtime_set_autosuspend_delay(&pdev->dev, SPI_AUTOSUSPEND_TIMEOUT);
pm_runtime_enable(&pdev->dev);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
