Re: [PATCH] perf: Use pre-empt safe cpu_get/put insted of smp_processor_id
Hi Jean,
My bad, I didn't follow up with this. My guess is that it has not been
picked up. Tony, Kevin?
regards,
-roger
On 09/06/2012 09:59 PM, Jean Pihet wrote:
> Fixed Paul's email address
>
> On Thu, Sep 6, 2012 at 8:56 PM, Jean Pihet wrote:
>> Hi Roger,
>>
>> On Fri, Aug 10, 2012 at 4:05 PM, 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
>>>
>>> Signed-off-by: Roger Quadros
>>
>> What his the status of the patch? Has it been reviewed and taken in an
>> integration tree? I cannot find anything about it in l-o and
>> linux-next.
>>
>> I have some changes on-going in the OMAP PM code and I would like to
>> know if $SUBJECT is applicable.
>>
>> Regards,
>> Jean
>>
>>> ---
>>> 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();
>>> clk->ops->disable(clk);
>>> }
>>>
>>> @@ -339,7 +340,8 @@ int omap2_clk_enable(struct clk *clk)
>>> }
>>>
>>> if (clk->ops && clk->ops->enable) {
>>> - trace_clock_enable(clk->name, 1, smp_processor_id());
>>> + trace_clock_enable(clk->name, 1, get_cpu());
>>> + put_cpu();
>>> ret = clk->ops->enable(clk);
>>> if (ret) {
>>> WARN(1, "clock: %s: could not enable: %d\n",
>>> @@ -380,7 +382,8 @@ int omap2_clk_set_rate(struct clk *clk, unsigned long
>>> rate)
>>>
>>> /* dpll_ck, core_ck, virt_prcm_set; plus all clksel clocks */
>>> if (clk->set_rate) {
>>> - trace_clock_set_rate(clk->name, rate, smp_processor_id());
>>> + trace_clock_set_rate(clk->name, rate, get_cpu());
>>> + put_cpu();
>>> ret = clk->set_rate(clk, rate);
>>> }
>>>
>>> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
>>> index e4fc88c..81fec2e 100644
>>> --- a/arch/arm/mach-omap2/pm34xx.c
>>> +++ b/arch/arm/mach-omap2/pm34xx.c
>>> @@ -357,18 +357,22 @@ void omap_sram_idle(void)
>>>
>>> static void omap3_pm_idle(void)
>>> {
>>> + unsigned cpu;
>>> +
>>> local_fiq_disable();
>>>
>>> if (omap_irq_pending())
>>> goto out;
>>>
>>> - trace_power_start(POWER_CSTATE, 1, smp_processor_id());
>>> - trace_cpu_idle(1, smp_processor_id());
>>> + cpu = get_cpu();
>>> + trace_power_start(POWER_CSTATE, 1, cpu);
>>> + trace_cpu_idle(1, cpu);
>>>
>>> omap_sram_idle();
>>>
>>> - trace_power_end(smp_processor_id());
>>> - trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
>>> + trace_power_end(cpu);
>>> + trace_cpu_idle(PWR_EVENT_EXIT, cpu);
>>> + put_cpu();
>>>
>>> out:
>>> local_fiq_enable();
>>> diff --git a/arch/arm/mach-omap2/powerdomain.c
>>> b/arch/arm/mach-omap2/powerdomain.c
>>> index 69b36e1..138bf86 100644
>>> --- a/arch/arm/mach-omap2/powerdomain.c
>>> +++ b/arch/arm/mach-omap2/powerdomain.c
>>> @@ -169,7 +169,8 @@ static int _pwrdm_state_switch(struct powerdomain
>>> *pwrdm, int flag)
>>>((state & OMAP_POWERSTATE_MASK) <<
>>> 8) |
>>>((prev & OMAP_POWERSTATE_MASK) <<
>>> 0));
>>> trace_power_domain_target(pwrdm->name, trace_state,
>>> - smp_processor_id());
>>> + get_cpu());
>>> + put_cpu();
>>> }
>>> break;
>>> default:
>>> @@ -491,7 +492,8 @@ int pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8
>>> pwrst)
>>> if (arch_pwrdm && arch_pwrdm->pwrdm_set_next_pwrst) {
>>> /* Trace the pwrdm desired target state */
>>> trace_power_domain_target(pwrdm->name, pwrst,
>>> - smp_processor_id());
>>> + get_cpu());
>>> + put_cpu();
>>> /* Program the pwrdm desired target state */
>>>
Re: OMAP baseline test results for v3.6-rc4
On 09/05/12 18:44, Paul Walmsley wrote: > > Here are some basic boot and power management test results for v3.6-rc4: > > http://www.pwsan.com/omap/testlogs/test_v3.6-rc4/20120904122415/ > > Some observations: > [...] > * CM-T3517: L3 in-band error with USB OTG during boot > - Cause unknown; longstanding issue; does not occur on the 3517EVM We see this problem on several cm-t3517, but not all of them. It looks something like: cut NET: Registered protocol family 16 GPMC revision 5.0 gpmc: irq-20 could not claim: err -22 OMAP GPIO hardware version 2.5 In-band Error seen by USB_OTG at address 0 [ cut here ] WARNING: at /home/lifshitz/workroot/git-repo/linux-cm-t3x/arch/arm/mach-omap2/omap_l3_smx.c:162 omap3_l3_app_irq+0xdc/0x120() Modules linked in: [] (unwind_backtrace+0x0/0xf4) from [] (warn_slowpath_common+0x4c/0x64) [] (warn_slowpath_common+0x4c/0x64) from [] (warn_slowpath_null+0x1c/0x24) [] (warn_slowpath_null+0x1c/0x24) from [] (omap3_l3_app_irq+0xdc/0x120) [] (omap3_l3_app_irq+0xdc/0x120) from [] (handle_irq_event_percpu+0xac/0x298) [] (handle_irq_event_percpu+0xac/0x298) from [] (handle_irq_event+0x54/0x74) [] (handle_irq_event+0x54/0x74) from [] (handle_level_irq+0xc4/0x118) [] (handle_level_irq+0xc4/0x118) from [] (generic_handle_irq+0x2c/0x44) [] (generic_handle_irq+0x2c/0x44) from [] (handle_IRQ+0x60/0x80) [] (handle_IRQ+0x60/0x80) from [] (omap3_intc_handle_irq+0x60/0x74) [] (omap3_intc_handle_irq+0x60/0x74) from [] (__irq_svc+0x40/0x74) Exception stack(0xcf02de00 to 0xcf02de48) de00: 000a 0021 c074bcac cf046280 000a 6013 de20: c074bcdc c070020c 0001 cf02de48 c008c988 de40: 4013 [] (__irq_svc+0x40/0x74) from [] (__setup_irq+0x2a8/0x404) [] (__setup_irq+0x2a8/0x404) from [] (request_threaded_irq+0xe8/0x13c) [] (request_threaded_irq+0xe8/0x13c) from [] (omap3_l3_probe+0x10c/0x16c) [] (omap3_l3_probe+0x10c/0x16c) from [] (platform_drv_probe+0x18/0x1c) [] (platform_drv_probe+0x18/0x1c) from [] (really_probe+0xac/0x1c8) [] (really_probe+0xac/0x1c8) from [] (driver_probe_device+0x48/0x60) [] (driver_probe_device+0x48/0x60) from [] (__driver_attach+0x60/0x84) [] (__driver_attach+0x60/0x84) from [] (bus_for_each_dev+0x4c/0x80) [] (bus_for_each_dev+0x4c/0x80) from [] (bus_add_driver+0xa4/0x294) [] (bus_add_driver+0xa4/0x294) from [] (driver_register+0xa4/0x188) [] (driver_register+0xa4/0x188) from [] (platform_driver_probe+0x18/0x98) [] (platform_driver_probe+0x18/0x98) from [] (do_one_initcall+0xac/0x16c) [] (do_one_initcall+0xac/0x16c) from [] (do_basic_setup+0x88/0xc0) [] (do_basic_setup+0x88/0xc0) from [] (kernel_init+0x60/0xfc) [] (kernel_init+0x60/0xfc) from [] (kernel_thread_exit+0x0/0x8) ---[ end trace 1b75b31a2719ed1c ]--- -cut--- After that, the board continues to function properly. Any hints how to debug this? [...] > > (The objective in posting these is to determine what is and isn't working > in the mainline releases, as well as to make it easier to determine what > is fixed or is broken by subsequent series that use this as a base.) Thanks for doing this. -- Regards, Igor. -- 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: Converting OMAP's custom vram allocator
Hello, On Wednesday, September 05, 2012 12:09 PM Tomi Valkeinen wrote: > OMAP has a custom video ram allocator, which I'd like to remove and use > the standard dma allocation functions. > > There are two problems for which I'd like to hear suggestions or > comments: > > First one is that the dma_alloc_* functions map the allocated memory for > cpu use. In many cases with OMAP DSS (display subsystem) this is not > needed: the memory may be written only by the SGX or the DSP, and it's > only read by the DSS, so it's never touched by the CPU. > > This is even more true when using VRFB on omap3 (and probably TILER on > omap4) for rotation, as VRFB hides the actual memory and offers rotated > views. In this case the backend memory is never accessed by anyone else > than VRFB. > > Is there a way to allocate the memory without creating a mapping? While > it won't break anything as such, the allocated areas can be quite large > thus causing large areas of the kernel's memory space to be needlessly > reserved. Please check commits d5724f172fd1 and 955c757e090 merged to v3.6-rc1. Support for this attribute is now only available in IOMMU-aware dma-mapping implementation, but I plan to add it also to standard linear ARM dma-mapping implementation based on alloc_pages_exact(). Some not-well-documented example can be found here: https://patchwork.kernel.org/patch/1323591/ (at the bottom). You probably might need to add your own custom dma_map_ops set of functions for TILER device, but I'm not really sure if I get right what does that device do and what will be the use cases for it. > The second case is passing a framebuffer address from the bootloader to > the kernel. Often with mobile devices the bootloader will initialize the > display hardware, showing a company logo or such. To keep the image on > the screen when kernel starts we need to reserve the same physical > memory area early at boot, and use that for the framebuffer. > > I'm not sure if there's any actual problem with this one, presuming > there is a solution for the first case. Somehow the memory is reserved > at early boot time, and this is passed to the fb driver. But can the > memory be managed the same way as in normal case (for example freeing > it), or does it need to be handled as a special case? The only solution I see here is to use custom coherent memory pool for the framebuffer device and setup it starting from the physical address of the framebuffer configured by bootloader. See dma_declare_coherent() function. Some usage example on ARM architecture can be found in arch/arm/plat-samsung/s5p-dev-mfc.c The other possibility is to enable Contiguous Memory Allocator and define a custom contiguous memory area for framebuffer device at the same physical address as configured by bootloader: http://git.linaro.org/gitweb?p=people/mszyprowski/linux-archive.git;a=commitdiff;h=f8ff4f99cfa4f67e09a3c948e007e82a0c21434a Feel free to comment both possibilities, maybe we can work out something better for solving this quite common use case. Best regards -- Marek Szyprowski Samsung Poland R&D Center -- 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
Hi, On Thu, Sep 06, 2012 at 03:44:13PM -0700, Kevin Hilman wrote: > Felipe Balbi writes: > > > Hi guys, > > > > here's v4 of the omap uart patchset. No changes other than a rebase on top > > of > > Greg's tty-next branch and Tony's Acked-by being added to a couple patches > > > > Note: I'm resending the series with Vikram's Software Flow Control fix > > anyway > > as it can just be ignored if it's decided it needs to go into this merge > > window. > > Sorry to be late to the party... just getting back from some time off. > > I'm assuming that this was not tested with PM, so decided I better do it you assumed wrong. See the previous versions of the series and you'll see I mention all the basic pm testing I did. > myself seeing that Greg is has already merge it. To test, I merged > Greg's tty-next branch with v3.6-rc4 and did some PM testing. > > The bad news is that it doesn't even compile (see reply to [PATCH v4 > 20/21]). yeah, that was an automerge issue when rebasing on greg's tty-next branch, plus me assuming omap serial was already enabled on my .config and not checking the compile output. Sent a patch now. > Also, there is a big WARNING on boot[1], which seems to be triggered by > a new check added for v3.6-rc3[2]. This appears to be introduced by > $SUBJECT series, because I don't see it on vanilla v3.6-rc4. > > The good news is that after hacking to fix up the compile problems, > basic PM testing seems to be fine: idle to retention and off as well as > suspend to retention and off work fine on 3430/n900, 3530/Overo, > 3730/OveroSTORM, 3730/Beagle-xM. > > Kevin > > > [1] > [8.745666] WARNING: at /work/kernel/omap/pm/drivers/tty/tty_io.c:1420 > tty_init_dev+0x14c/0x17c() > [8.755218] tty_init_dev: ttyO driver does not set tty->port. This will > crash the kernel later. Fix the driver! > [8.765991] Modules linked in: > [8.769287] [] (unwind_backtrace+0x0/0xf0) from [] > (warn_slowpath_common+0x4c/0x64) > [8.779327] [] (warn_slowpath_common+0x4c/0x64) from > [] (warn_slowpath_fmt+0x30/0x40) > [8.789550] [] (warn_slowpath_fmt+0x30/0x40) from [] > (tty_init_dev+0x14c/0x17c) > [8.799224] [] (tty_init_dev+0x14c/0x17c) from [] > (tty_open+0x11c/0x52c) > [8.808258] [] (tty_open+0x11c/0x52c) from [] > (chrdev_open+0x90/0x15c) > [8.817108] [] (chrdev_open+0x90/0x15c) from [] > (do_dentry_open+0x1e8/0x270) > [8.826507] [] (do_dentry_open+0x1e8/0x270) from [] > (finish_open+0x34/0x4c) > [8.835784] [] (finish_open+0x34/0x4c) from [] > (do_last.isra.21+0x5b0/0xbbc) > [8.845184] [] (do_last.isra.21+0x5b0/0xbbc) from [] > (path_openat+0xa8/0x44c) > [8.854675] [] (path_openat+0xa8/0x44c) from [] > (do_filp_open+0x2c/0x80) > [8.863708] [] (do_filp_open+0x2c/0x80) from [] > (do_sys_open+0xe8/0x184) > [8.872711] [] (do_sys_open+0xe8/0x184) from [] > (ret_fast_syscall+0x0/0x3c) > [8.882019] ---[ end trace e9bf408c37051346 ]--- This doesn't seem to be caused by $SUBJECT at all. See that we are calling uart_add_one_port() which will call tty_port_register_device() which, in turn, will call tty_port_link_device() and that will set driver->ports[index] correctly. Have you checked if this doesn't happen without my series before waving your blame hammer ? FWIW, that part of the code wasn't change by $SUBJECT at all. -- balbi signature.asc Description: Digital signature
RE: [PATCH v2 1/8] ARM/dts: OMAP2: Add McBSP entries for OMAP2420 and OMAP2430 SoC
On Wed, Sep 05, 2012 at 20:11:11, Hiremath, Vaibhav wrote: > On Wed, Sep 05, 2012 at 19:01:55, Cousson, Benoit wrote: > > Hi Vaibhav, > > > > On 09/05/2012 11:15 AM, Hiremath, Vaibhav wrote: > > > On Wed, Sep 05, 2012 at 13:53:58, Ujfalusi, Peter wrote: > > >> Hi, > > >> > > >> On 09/05/2012 09:11 AM, Hiremath, Vaibhav wrote: > > Not yet, but we discussed that with Peter and since he does have these > > patches for DT, he'll be able to test your series with the McBSP > > changes. > > > > >>> > > >>> Great. > > >> > > >> With his series and your patch for omap-hwmod audio was probing and > > >> working on > > >> OMAP3/4/5 without issues. > > >> > > > Peter, > > > Care to provide your Tested-By?? > > > > > > Benoit, > > > Can we merge this patch now? > > > > Yes, I'll include it in the pull request along with DTS patches. > > > > I've just tested it as well on OMAP4 by hacking the DTS for GPIO. > > I'll try to update at least all the OMAP4 IPs as well with the proper > > DTS resources for 3.7. > > > > Thanks Benoit, > > 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/ > Few more DT patches which are pending arm/dts: AM33XX: Add basic pinctrl device tree data http://www.spinics.net/lists/linux-omap/msg76684.html arm/dts: AM33XX: Configure pinmuxs for user leds control on Bone http://www.spinics.net/lists/linux-omap/msg76682.html arm/dts: AM33XX: Add D_CAN device tree data http://www.spinics.net/lists/linux-omap/msg76683.html Thanks AnilKumar -- 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 v7 0/3] arm/dts: Add device tree data for AM33XX devices
On Thu, Sep 06, 2012 at 15:08:21, AnilKumar, Chimata wrote: > Add pinctrl and d_can device tree data to AM33XX family of devices. > First two patches add support for pinctrl DT data and third one > adds dcan DT data. > > Reason behind combining these patches is to apply cleanly on > linux-omap tree, because these are sequential patches. > > These patches were tested on AM335x-Bone, AM335x-EVM and based > on linux-omap:master with this patch > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg74393.html > If there are no changes in this patch series ACK from reviewers (esp. Tony, koen and Marc) will help. Thanks AnilKumar -- 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 5/5] omap-serial: Request pins using pinctrl framework
Hi,
On Thu, Sep 06, 2012 at 02:17:26PM -0700, Tony Lindgren wrote:
> * Felipe Balbi [120906 13:01]:
> > Hi,
> >
> > On Thu, Sep 06, 2012 at 11:58:32AM -0700, Tony Lindgren wrote:
> > > Request pins using pinctrl framework. Only show a warning
> > > on error as some boards set the pins in the bootloader
> > > even if CONFIG_PINCTRL is enabled.
> > >
> > > Cc: linux-ser...@vger.kernel.org
> > > Cc: Greg Kroah-Hartman
> > > Signed-off-by: Tony Lindgren
> > > ---
> > > arch/arm/plat-omap/include/plat/omap-serial.h |1 +
> > > drivers/tty/serial/omap-serial.c | 10 ++
> > > 2 files changed, 11 insertions(+)
> > >
> > > diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
> > > b/arch/arm/plat-omap/include/plat/omap-serial.h
> > > index 1a52725..0f4de14 100644
> > > --- a/arch/arm/plat-omap/include/plat/omap-serial.h
> > > +++ b/arch/arm/plat-omap/include/plat/omap-serial.h
> > > @@ -106,6 +106,7 @@ struct uart_omap_port {
> > > struct uart_portport;
> > > struct uart_omap_dmauart_dma;
> > > struct platform_device *pdev;
> > > + struct pinctrl *pins;
> >
> > this won't apply to Greg's tty-next as I moved this structure to the C
> > file :-s
>
> Hmm the tty-next fails to build right now for omaps:
>
> drivers/tty/serial/omap-serial.c: In function ‘serial_omap_set_mctrl’:
> drivers/tty/serial/omap-serial.c:514: error: ‘struct uart_omap_port’ has no
> member named ‘DTR_gpio’
>
> Maybe check how you want to fix that first? I can then update
> my patch for tty-next.
oops, my bad. Patch sent.
--
balbi
signature.asc
Description: Digital signature
[PATCH v2] serial: omap: fix compile breakage
when rebasing patches on top of Greg's tty-next,
it looks like automerge broke a few things which
I didn't catch (for whatever reason I didn't
have OMAP Serial enabled on .config) so I ended
up breaking the build on Greg's tty-next branch.
Fix the breakage by re-adding the three missing
members on struct uart_omap_port.
Reported-by: Tony Lindgren
Signed-off-by: Felipe Balbi
---
Changes since v1:
. remove the fields from
arch/arm/plat-omap/include/plat/omap-serial.h | 4
drivers/tty/serial/omap-serial.c | 4
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 57ff78c..74caddc 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -79,8 +79,4 @@ struct omap_uart_port_info {
void (*enable_wakeup)(struct device *, bool);
};
-
- int DTR_gpio;
- int DTR_inverted;
- int DTR_active;
#endif /* __OMAP_SERIAL_H__ */
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index e31d291..8e4a7aa 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -123,6 +123,10 @@ struct uart_omap_port {
u8 wakeups_enabled;
unsigned intirq_pending:1;
+ int DTR_gpio;
+ int DTR_inverted;
+ int DTR_active;
+
struct pm_qos_request pm_qos_request;
u32 latency;
u32 calc_latency;
--
1.7.12.rc3
--
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] serial: omap: fix compile breakage
when rebasing patches on top of Greg's tty-next,
it looks like automerge broke a few things which
I didn't catch (for whatever reason I didn't
have OMAP Serial enabled on .config) so I ended
up breaking the build on Greg's tty-next branch.
Fix the breakage by re-adding the three missing
members on struct uart_omap_port.
Reported-by: Tony Lindgren
Signed-off-by: Felipe Balbi
---
drivers/tty/serial/omap-serial.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index e31d291..8e4a7aa 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -123,6 +123,10 @@ struct uart_omap_port {
u8 wakeups_enabled;
unsigned intirq_pending:1;
+ int DTR_gpio;
+ int DTR_inverted;
+ int DTR_active;
+
struct pm_qos_request pm_qos_request;
u32 latency;
u32 calc_latency;
--
1.7.12.rc3
--
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: [GIT PULL] ARM: OMAP2+: PRCM/hwmod: some fixes for 3.6-rc
On 9/5/2012 9:45 PM, Paul Walmsley wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi Tony, > > The following changes since commit 4cbe5a555fa58a79b6ecbb6c531b8bab0650778d: > > Linux 3.6-rc4 (2012-09-01 10:39:58 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git > tags/omap-fixes-a-for-3.6rc > > for you to fetch changes up to 8a94febc21743fe121bdaf1d1470d98b1135acc2: > > Merge branches 'clkdev_fixes_3.6rc', 'clkdm_fixes_3.6rc' and > 'hwmod_data_fixes_a_3.6rc' into omap_fixes_a_3.6rc (2012-09-03 11:52:02 -0600) > Paul, Isn't below patch good for -rc candidate (so as part of this 'fixes')? ARM: OMAP2+: dpll: Add missing soc_is_am33xx() check for common functions https://patchwork.kernel.org/patch/1371611/ Thanks, Vaibhav > - > > Some hwmod, clockdomain, am335x fixes against v3.6-rc4. > > Test logs can be found here: > >http://www.pwsan.com/omap/testlogs/omap_fixes_a_3.6rc/20120904110254/ > > - > Misael Lopez Cruz (1): > ARM: OMAP: hwmod code: Disable module when hwmod enable fails > > Paul Walmsley (2): > ARM: OMAP3xxx: clockdomain: fix software supervised wakeup/sleep > Merge branches 'clkdev_fixes_3.6rc', 'clkdm_fixes_3.6rc' and > 'hwmod_data_fixes_a_3.6rc' into omap_fixes_a_3.6rc > > Tero Kristo (2): > ARM: OMAP3: hwmod data: fix iva2 reset info > ARM: OMAP4: hwmod data: temporarily comment out data for the sl2if IP > block > > Vaibhav Hiremath (1): > ARM: OMAP2+: am33xx: Fix the timer fck clock naming convention > > arch/arm/mach-omap2/clock33xx_data.c | 14 > arch/arm/mach-omap2/clockdomain2xxx_3xxx.c | 50 > ++-- > arch/arm/mach-omap2/cm-regbits-34xx.h |1 + > arch/arm/mach-omap2/omap_hwmod.c |1 + > arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 15 +++-- > arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 12 +++ > 6 files changed, 75 insertions(+), 18 deletions(-) > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.12 (GNU/Linux) > > iQIcBAEBAgAGBQJQR3ooAAoJEMePsQ0LvSpLQ94P/1DzifcEU/R0YFLZF+20XPd5 > hOrUk2EWn7SlPAxZJMG1K+In7EZ3K4r7IYaROIbwUWJTO/hQdx6zwyAOec/qnutV > WYRnQ+KN+x7gd8EYZPnS1voiqeH0SnP/wI2ri9UcMTV+tpAtO6ibD10iAUmBxSfX > x9HaYb65cYA+ulMsQXX2g1oejV2+4eR+fWWI0+bGfOxIHPGQcEhSGSvNkDs9W/bE > QfBKmTWeizx2jlRlXBG8pxV8MtEIDtwRZitcgTnyStw8LMqR/YnCOLIRoU2OHVcP > UtQwIxtNqGaoqm3i6IXGM1BLI4ZT/EN0kr+1LZVl1WoFqL1tDrn39dSvSVfxfGje > CjhkTk9XVzbV4GV+1yTt6JlfD3AimLwYqihKDs21a2OleAsQAu8a+gftsJtSp8Xu > fscJcjr1c5JKyjE5CzbH7mbDgX+LTveZV3b6pT1m599UidP/NZ4yzUYrmkTmoSkk > JdqQlTgahLxjBoBBDfNhavuCzA4cYNh6q0Pt6GhmWc1ZC7aR3+7xU4wUNXAvbKoe > mUksJmjROwk4MlswLqpIkgt8iiEGa2LzHcyL7eVD2+oCun0FFlolqa1R3gTF9x8y > Hr8iNv4b0OeX55oSZ53ijIDY4WwgmBVvnVjiWEiAkBuwqsghRLii5eemX572szGU > lTSzo95e8x7kAaO6moNI > =wc/t > -END PGP SIGNATURE- > > ___ > 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
RE: [PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module
On Thu, Sep 06, 2012 at 22:43:03, Balbi, Felipe wrote:
> Hi,
>
> On Thu, Sep 06, 2012 at 09:04:58PM +0530, Vaibhav Hiremath 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.
>
Understood and thanks for confirming.
Thanks,
Vaibhav
> --
> 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
[GIT PULL] omap fixes for v3.6-rc4
The following changes since commit 4cbe5a555fa58a79b6ecbb6c531b8bab0650778d: Linux 3.6-rc4 (2012-09-01 10:39:58 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-fixes-for-v3.6-rc4 for you to fetch changes up to 6ab019b62e0505289b26bd00d997dc7686192fa4: Merge tag 'omap-fixes-a-for-3.6rc' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into fixes (2012-09-05 10:09:31 -0700) Fixes for timer, sram, memory corruption, and one board file that affect booting on various omaps. Then some PM related fixes for reset, sleep and wakeup. Aaro Koskinen (2): ARM: OMAP: sram: fix OMAP4 errata handling ARM: OMAP: sram: skip the first 16K on OMAP3 HS Igor Grinberg (1): ARM: OMAP: timer: obey the !CONFIG_OMAP_32K_TIMER Misael Lopez Cruz (1): ARM: OMAP: hwmod code: Disable module when hwmod enable fails Paul Walmsley (2): ARM: OMAP3xxx: clockdomain: fix software supervised wakeup/sleep Merge branches 'clkdev_fixes_3.6rc', 'clkdm_fixes_3.6rc' and 'hwmod_data_fixes_a_3.6rc' into omap_fixes_a_3.6rc Radek Pilar (1): ARM: OMAP: Config fix for omap3-touchbook board Tero Kristo (2): ARM: OMAP3: hwmod data: fix iva2 reset info ARM: OMAP4: hwmod data: temporarily comment out data for the sl2if IP block Tony Lindgren (3): ARM: OMAP4: Fix array size for irq_target_cpu Merge branch 'fixes-wakeupgen' into fixes Merge tag 'omap-fixes-a-for-3.6rc' of git://git.kernel.org/.../pjw/omap-pending into fixes Vaibhav Hiremath (1): ARM: OMAP2+: am33xx: Fix the timer fck clock naming convention arch/arm/mach-omap2/Kconfig|3 +- arch/arm/mach-omap2/Makefile |2 +- arch/arm/mach-omap2/clock33xx_data.c | 14 arch/arm/mach-omap2/clockdomain2xxx_3xxx.c | 50 ++-- arch/arm/mach-omap2/cm-regbits-34xx.h |1 + arch/arm/mach-omap2/omap-wakeupgen.c |2 +- arch/arm/mach-omap2/omap_hwmod.c |1 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 15 +++-- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 12 +++ arch/arm/mach-omap2/timer.c|7 arch/arm/plat-omap/sram.c | 11 -- 11 files changed, 94 insertions(+), 24 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] can: c_can: Add runtime PM support to Bosch C_CAN/D_CAN controller
Hi Kevin,
On Fri, Sep 07, 2012 at 05:07:56, Kevin Hilman wrote:
> AnilKumar Ch writes:
>
> > Add Runtime PM support to C_CAN/D_CAN controller. The runtime PM
> > APIs control clocks for C_CAN/D_CAN IP and prevent access to the
> > register of C_CAN/D_CAN IP when clock is turned off.
> >
> > Signed-off-by: AnilKumar Ch
>
> I'm not familar with the CAN specifics here, but some comments on the
> runtime PM implementation.
Thanks for the comments.
>
> > ---
> > This patch has been tested on AM335X EVM. Due to lack of hardware
> > I am not able to test c_can functionality. I appreciate if anyone
> > can test c_can functionality with this patch.
> >
> > This patch is based on "can-next/master"
> >
> > Changes from v8:
> > - corrected the return path sequence in c_can_probe()
> >
> > Changes from v7:
> > - Incorporated Marc's comments on v7
> > * changed device pointer to c_can_priv pointer
> >
> > Changes from v6:
> > - Incorporated Marc's comments on v6
> > * changed dev pointer to priv
> > * removed platform_device.h include from c_can.c
> >
> > Changes from v5:
> > - Incorporated Marc's comments on v5
> > * changed runtime pm calls in c_can driver to handle
> > the drivers which are not using platform drivers.
> > * added device pointer protection in c_can driver if
> > not passed from platform/pci driver.
> >
> > Changes from v4:
> > - Incorporated Vaibhav H review comments on v4.
> > * Moved pm_runtime put/get_sync calls to appropriate positions.
> > - This patch is from "Add DT support to C_CAN/D_CAN controller"
> > patch series. Rest of the patches in this series were applied
> > so this v5 contains only this patch.
> >
> > drivers/net/can/c_can/c_can.c | 24 +++-
> > drivers/net/can/c_can/c_can.h |1 +
> > drivers/net/can/c_can/c_can_platform.c | 11 +--
> > 3 files changed, 33 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
> > index 4c538e3..966d318 100644
> > --- a/drivers/net/can/c_can/c_can.c
> > +++ b/drivers/net/can/c_can/c_can.c
> > @@ -34,6 +34,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > @@ -201,6 +202,18 @@ static const struct can_bittiming_const
> > c_can_bittiming_const = {
> > .brp_inc = 1,
> > };
> >
> > +static inline void c_can_pm_runtime_get_sync(struct c_can_priv *priv)
> > +{
> > + if (priv->device)
> > + pm_runtime_get_sync(priv->device);
> > +}
> > +
> > +static inline void c_can_pm_runtime_put_sync(struct c_can_priv *priv)
> > +{
> > + if (priv->device)
> > + pm_runtime_put_sync(priv->device);
> > +}
>
> IMO, these extra helpers are rather unsightly, and should not be needed.
> The driver should just be directly doing get_sync/put_sync. If
> priv->device isn't presnt, then runtime PM should just never be enabled.
>
In case of c_can driver we have two drivers one is generic c_can.c driver,
provides the basic functionality of CAN. Another two drivers c_can_platform.c
and c_can_pci.c, which uses core c_can.c driver by exporting some platform
specific ops like read/write.
priv->device pointer is passed from c_can_platform.c by this means
"priv->device = &pdev->dev;" (see below) but not for c_can_pci.c
The purpose of check here is for *_pci.c driver which do not have runtime pm
implemented yet so we should do and get_sync/put_sync. In case of *_pci.c
driver there is no pm_runtime_enable/disable once that is implemented then
this check will be removed.
Thanks
AnilKumar
>
> > static inline int get_tx_next_msg_obj(const struct c_can_priv *priv)
> > {
> > return (priv->tx_next & C_CAN_NEXT_MSG_OBJ_MASK) +
> > @@ -673,11 +686,15 @@ static int c_can_get_berr_counter(const struct
> > net_device *dev,
> > unsigned int reg_err_counter;
> > struct c_can_priv *priv = netdev_priv(dev);
> >
> > + c_can_pm_runtime_get_sync(priv);
> > +
> > reg_err_counter = priv->read_reg(priv, C_CAN_ERR_CNT_REG);
> > bec->rxerr = (reg_err_counter & ERR_CNT_REC_MASK) >>
> > ERR_CNT_REC_SHIFT;
> > bec->txerr = reg_err_counter & ERR_CNT_TEC_MASK;
> >
> > + c_can_pm_runtime_put_sync(priv);
> > +
> > return 0;
> > }
> >
> > @@ -1053,11 +1070,13 @@ static int c_can_open(struct net_device *dev)
> > int err;
> > struct c_can_priv *priv = netdev_priv(dev);
> >
> > + c_can_pm_runtime_get_sync(priv);
> > +
> > /* open the can device */
> > err = open_candev(dev);
> > if (err) {
> > netdev_err(dev, "failed to open can device\n");
> > - return err;
> > + goto exit_open_fail;
> > }
> >
> > /* register interrupt handler */
> > @@ -1079,6 +1098,8 @@ static int c_can_open(struct net_device *dev)
> >
> > exit_irq_fail:
> > close_candev(dev);
> > +exit_open_fail:
> > + c_can_pm_ru
RE: [PATCH 5/5] omap-serial: Request pins using pinctrl framework
Hi Tony,
On Fri, Sep 07, 2012 at 00:28:32, Tony Lindgren wrote:
> Request pins using pinctrl framework. Only show a warning
> on error as some boards set the pins in the bootloader
> even if CONFIG_PINCTRL is enabled.
>
> Cc: linux-ser...@vger.kernel.org
> Cc: Greg Kroah-Hartman
> Signed-off-by: Tony Lindgren
> ---
> arch/arm/plat-omap/include/plat/omap-serial.h |1 +
> drivers/tty/serial/omap-serial.c | 10 ++
> 2 files changed, 11 insertions(+)
>
> diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
> b/arch/arm/plat-omap/include/plat/omap-serial.h
> index 1a52725..0f4de14 100644
> --- a/arch/arm/plat-omap/include/plat/omap-serial.h
> +++ b/arch/arm/plat-omap/include/plat/omap-serial.h
> @@ -106,6 +106,7 @@ struct uart_omap_port {
> struct uart_portport;
> struct uart_omap_dmauart_dma;
> struct platform_device *pdev;
> + struct pinctrl *pins;
>
> unsigned char ier;
> unsigned char lcr;
> diff --git a/drivers/tty/serial/omap-serial.c
> b/drivers/tty/serial/omap-serial.c
> index d3cda0c..068e88c 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -39,6 +39,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -1492,6 +1493,13 @@ static int serial_omap_probe(struct platform_device
> *pdev)
> goto err_port_line;
> }
>
> + up->pins = pinctrl_get_select_default(&pdev->dev);
> + if (IS_ERR(up->pins)) {
> + dev_warn(&pdev->dev, "did not get pins for uart%i error: %li\n",
> + up->port.line, PTR_ERR(up->pins));
> + up->pins = NULL;
> + }
> +
> sprintf(up->name, "OMAP UART%d", up->port.line);
> up->port.mapbase = mem->start;
> up->port.membase = devm_ioremap(&pdev->dev, mem->start,
> @@ -1570,6 +1578,8 @@ static int serial_omap_remove(struct platform_device
> *dev)
> pm_runtime_disable(&up->pdev->dev);
> uart_remove_one_port(&serial_omap_reg, &up->port);
> pm_qos_remove_request(&up->pm_qos_request);
> + if (up->pins)
> + pinctrl_put(up->pins);
I think this can be removed if we use devm_pinctrl_get_select_default()
above.
Thanks
AnilKumar
--
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 v6 2/3] arm/dts: AM33XX: Configure pinmuxs for user leds control on Bone
Tony,
On Fri, Sep 07, 2012 at 02:28:12, Tony Lindgren wrote:
> * AnilKumar Ch [120905 04:42]:
> > Adds GPIO pinctrl nodes to am3358_pinmux master node to control
> > user leds (USR0, USR1, USR2 and USR3) present on BeagleBone.
> >
> > [k...@dominion.thruhere.net: led0, led1 suggested by koen]
> > Signed-off-by: AnilKumar Ch
> > ---
> > arch/arm/boot/dts/am335x-bone.dts | 43
> > +
> > 1 file changed, 43 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/am335x-bone.dts
> > b/arch/arm/boot/dts/am335x-bone.dts
> > index c634f87..822efe6 100644
> > --- a/arch/arm/boot/dts/am335x-bone.dts
> > +++ b/arch/arm/boot/dts/am335x-bone.dts
> > @@ -18,11 +18,54 @@
> > reg = <0x8000 0x1000>; /* 256 MB */
> > };
> >
> > + am3358_pinmux: pinmux@44e10800 {
> > + userled_pins: pinmux_userled_pins {
> > + pinctrl-single,pins = <
> > + 0x54 0x7/* gpmc_a5.gpio1_21, OUTPUT |
> > MODE7 */
> > + 0x58 0x17 /* gpmc_a6.gpio1_22,
> > OUTPUT_PULLUP | MODE7 */
> > + 0x5c 0x7/* gpmc_a7.gpio1_23, OUTPUT |
> > MODE7 */
> > + 0x60 0x17 /* gpmc_a8.gpio1_24,
> > OUTPUT_PULLUP | MODE7 */
> > + >;
> > + };
> > + };
> > +
>
> Just checking.. am3358_pinmux should be am33xx_pinmux in this patch
> too as discussed.
>
Yes, this is also changed in v7.
Thanks
AnilKumar
--
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: [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes
On 09/06/2012 08:45 AM, Rob Herring wrote: > On 07/23/2012 10:24 AM, Jon Hunter wrote: [snip] >> Do you have any inputs on the above? Does it make sense to reserve timer >> resources for kernel system timers in device-tree? > > This issue is not unique to omap. So if we do specify clockevent and > clocksource in dts, then it should be in a common way. I think using > "linux,clockevent" either as an alias name or property within the timer > node would work. I don't have a strong preference, but I tend to lean > toward an alias. Primarily this is because we are already using aliases > for similar purposes. > > However, I still think this could be done by looking at properties. > There's not really any reason you can't check properties at timer init > stage. The FDT has already been un-flattened. What are the features or > lack of features you care about to determine which timer to use? I agree. Currently, I am looking into implementing something that will use timer properties to select the system timers for the kernel and not require us to select them in the device-tree. Once I have something working I will send out for review. 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 v6 10/10] ARM: OMAP2+: tusb6010: generic timing calculation
+ Rajendra Hi On Thu, 6 Sep 2012, Mohammed, Afzal wrote: > I tried to get an n800, but has been unsuccessful. We took an n800 to TII a few years ago, hopefully you can find it. Cc'ing Rajendra who might know where it is. - Paul -- 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] leds: leds-gpio: adopt pinctrl support
Dear Tony Lindgren, > * Marek Vasut [120905 19:05]: > > Hi Tony, > > > > > * Marek Vasut [120904 20:13]: > > > > Dear Bryan Wu, > > > > > > > > > On Sat, Sep 1, 2012 at 4:16 PM, AnilKumar Ch wrote: > > > > > > Adopt pinctrl support to leds-gpio driver based on leds-gpio > > > > > > device pointer, pinctrl driver configure SoC pins to GPIO > > > > > > mode according to definitions provided in .dts file. > > > > > > > > > > Thanks for this, actually Marek Vasut submitted a similar patch > > > > > before. I'm pretty fine with this patch. > > > > > > > > Thanks for submitting this actually ... I didn't have time to > > > > properly investigate this. > > > > > > > > > But without proper DT setting, it will also give us warning I > > > > > think. or we can provide some dummy functions as a temp solution > > > > > as Shawn pointed out before. > > > > > > > > But this driver is also used on hardware that's not yet coverted to > > > > DT, so I'd say dev_warn() if CONFIG_OF is enabled and otherwise > > > > simply go on ? Actually, can we not skip whole this pinctrl thing if > > > > CONFIG_OF is disabled? Actually (2), what's the relationship between > > > > OF and pinctrl? > > > > > > The warning should be pinctrl related as the pinctrl drivers may not be > > > device tree based drivers. > > > > Exactly my concern. Also the warning shouldnt be present on systems where > > pinctrl is disabled. > > But pinctrl_get_select() returns 0 in include/linux/pinctrl/consumer.h if > CONFIG_PINCTRL is not selected, so no warning is produced AFAIK ;) Oh all right then. > Or do you get some warning if CONFIG_PINCTRL is not selected for your > hardware? No, I don't have much hardware like such anymore :-( Best regards, Marek Vasut -- 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] can: c_can: Add runtime PM support to Bosch C_CAN/D_CAN controller
AnilKumar Ch writes:
> Add Runtime PM support to C_CAN/D_CAN controller. The runtime PM
> APIs control clocks for C_CAN/D_CAN IP and prevent access to the
> register of C_CAN/D_CAN IP when clock is turned off.
>
> Signed-off-by: AnilKumar Ch
I'm not familar with the CAN specifics here, but some comments on the
runtime PM implementation.
> ---
> This patch has been tested on AM335X EVM. Due to lack of hardware
> I am not able to test c_can functionality. I appreciate if anyone
> can test c_can functionality with this patch.
>
> This patch is based on "can-next/master"
>
> Changes from v8:
> - corrected the return path sequence in c_can_probe()
>
> Changes from v7:
> - Incorporated Marc's comments on v7
> * changed device pointer to c_can_priv pointer
>
> Changes from v6:
> - Incorporated Marc's comments on v6
> * changed dev pointer to priv
> * removed platform_device.h include from c_can.c
>
> Changes from v5:
> - Incorporated Marc's comments on v5
> * changed runtime pm calls in c_can driver to handle
> the drivers which are not using platform drivers.
> * added device pointer protection in c_can driver if
> not passed from platform/pci driver.
>
> Changes from v4:
> - Incorporated Vaibhav H review comments on v4.
> * Moved pm_runtime put/get_sync calls to appropriate positions.
> - This patch is from "Add DT support to C_CAN/D_CAN controller"
> patch series. Rest of the patches in this series were applied
> so this v5 contains only this patch.
>
> drivers/net/can/c_can/c_can.c | 24 +++-
> drivers/net/can/c_can/c_can.h |1 +
> drivers/net/can/c_can/c_can_platform.c | 11 +--
> 3 files changed, 33 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
> index 4c538e3..966d318 100644
> --- a/drivers/net/can/c_can/c_can.c
> +++ b/drivers/net/can/c_can/c_can.c
> @@ -34,6 +34,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -201,6 +202,18 @@ static const struct can_bittiming_const
> c_can_bittiming_const = {
> .brp_inc = 1,
> };
>
> +static inline void c_can_pm_runtime_get_sync(struct c_can_priv *priv)
> +{
> + if (priv->device)
> + pm_runtime_get_sync(priv->device);
> +}
> +
> +static inline void c_can_pm_runtime_put_sync(struct c_can_priv *priv)
> +{
> + if (priv->device)
> + pm_runtime_put_sync(priv->device);
> +}
IMO, these extra helpers are rather unsightly, and should not be needed.
The driver should just be directly doing get_sync/put_sync. If
priv->device isn't presnt, then runtime PM should just never be enabled.
Kevin
> static inline int get_tx_next_msg_obj(const struct c_can_priv *priv)
> {
> return (priv->tx_next & C_CAN_NEXT_MSG_OBJ_MASK) +
> @@ -673,11 +686,15 @@ static int c_can_get_berr_counter(const struct
> net_device *dev,
> unsigned int reg_err_counter;
> struct c_can_priv *priv = netdev_priv(dev);
>
> + c_can_pm_runtime_get_sync(priv);
> +
> reg_err_counter = priv->read_reg(priv, C_CAN_ERR_CNT_REG);
> bec->rxerr = (reg_err_counter & ERR_CNT_REC_MASK) >>
> ERR_CNT_REC_SHIFT;
> bec->txerr = reg_err_counter & ERR_CNT_TEC_MASK;
>
> + c_can_pm_runtime_put_sync(priv);
> +
> return 0;
> }
>
> @@ -1053,11 +1070,13 @@ static int c_can_open(struct net_device *dev)
> int err;
> struct c_can_priv *priv = netdev_priv(dev);
>
> + c_can_pm_runtime_get_sync(priv);
> +
> /* open the can device */
> err = open_candev(dev);
> if (err) {
> netdev_err(dev, "failed to open can device\n");
> - return err;
> + goto exit_open_fail;
> }
>
> /* register interrupt handler */
> @@ -1079,6 +1098,8 @@ static int c_can_open(struct net_device *dev)
>
> exit_irq_fail:
> close_candev(dev);
> +exit_open_fail:
> + c_can_pm_runtime_put_sync(priv);
> return err;
> }
>
> @@ -1091,6 +1112,7 @@ static int c_can_close(struct net_device *dev)
> c_can_stop(dev);
> free_irq(dev->irq, dev);
> close_candev(dev);
> + c_can_pm_runtime_put_sync(priv);
>
> return 0;
> }
> diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
> index 4e56baa..1437a6d 100644
> --- a/drivers/net/can/c_can/c_can.h
> +++ b/drivers/net/can/c_can/c_can.h
> @@ -153,6 +153,7 @@ struct c_can_priv {
> struct can_priv can;/* must be the first member */
> struct napi_struct napi;
> struct net_device *dev;
> + struct device *device;
> int tx_object;
> int current_status;
> int last_status;
> diff --git a/drivers/net/can/c_can/c_can_platform.c
> b/drivers/net/can/c_can/c_can_platform.c
> index d0a66cf..90801c4 100644
> --- a/drivers/net/can/c_can/c_can_platform.
Re: [PATCH v4 00/21] OMAP UART Patches
Felipe Balbi writes: > Hi guys, > > here's v4 of the omap uart patchset. No changes other than a rebase on top of > Greg's tty-next branch and Tony's Acked-by being added to a couple patches > > Note: I'm resending the series with Vikram's Software Flow Control fix anyway > as it can just be ignored if it's decided it needs to go into this merge > window. Sorry to be late to the party... just getting back from some time off. I'm assuming that this was not tested with PM, so decided I better do it myself seeing that Greg is has already merge it. To test, I merged Greg's tty-next branch with v3.6-rc4 and did some PM testing. The bad news is that it doesn't even compile (see reply to [PATCH v4 20/21]). Also, there is a big WARNING on boot[1], which seems to be triggered by a new check added for v3.6-rc3[2]. This appears to be introduced by $SUBJECT series, because I don't see it on vanilla v3.6-rc4. The good news is that after hacking to fix up the compile problems, basic PM testing seems to be fine: idle to retention and off as well as suspend to retention and off work fine on 3430/n900, 3530/Overo, 3730/OveroSTORM, 3730/Beagle-xM. Kevin [1] [8.745666] WARNING: at /work/kernel/omap/pm/drivers/tty/tty_io.c:1420 tty_init_dev+0x14c/0x17c() [8.755218] tty_init_dev: ttyO driver does not set tty->port. This will crash the kernel later. Fix the driver! [8.765991] Modules linked in: [8.769287] [] (unwind_backtrace+0x0/0xf0) from [] (warn_slowpath_common+0x4c/0x64) [8.779327] [] (warn_slowpath_common+0x4c/0x64) from [] (warn_slowpath_fmt+0x30/0x40) [8.789550] [] (warn_slowpath_fmt+0x30/0x40) from [] (tty_init_dev+0x14c/0x17c) [8.799224] [] (tty_init_dev+0x14c/0x17c) from [] (tty_open+0x11c/0x52c) [8.808258] [] (tty_open+0x11c/0x52c) from [] (chrdev_open+0x90/0x15c) [8.817108] [] (chrdev_open+0x90/0x15c) from [] (do_dentry_open+0x1e8/0x270) [8.826507] [] (do_dentry_open+0x1e8/0x270) from [] (finish_open+0x34/0x4c) [8.835784] [] (finish_open+0x34/0x4c) from [] (do_last.isra.21+0x5b0/0xbbc) [8.845184] [] (do_last.isra.21+0x5b0/0xbbc) from [] (path_openat+0xa8/0x44c) [8.854675] [] (path_openat+0xa8/0x44c) from [] (do_filp_open+0x2c/0x80) [8.863708] [] (do_filp_open+0x2c/0x80) from [] (do_sys_open+0xe8/0x184) [8.872711] [] (do_sys_open+0xe8/0x184) from [] (ret_fast_syscall+0x0/0x3c) [8.882019] ---[ end trace e9bf408c37051346 ]--- [2] commit 5d4121c04b3577e37e389b3553d442f44bb346d7 Author: Jiri Slaby Date: Fri Aug 17 14:27:52 2012 +0200 TTY: check if tty->port is assigned And if not, complain loudly. None in-kernel module should trigger that, but let us find out for sure. On the other hand, all the out-of-tree modules will hit that. Give them some time (maybe one release) to catch up. Signed-off-by: Jiri Slaby Signed-off-by: Greg Kroah-Hartman -- 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 20/21] serial: omap: move uart_omap_port definition to C file
Felipe Balbi writes:
> nobody needs to access the uart_omap_port structure
> other than omap-serial.c file. Let's move that
> structure definition to the C source file in order
> to prevent anyone from accessing our structure.
>
> Tested-by: Shubhrajyoti D
> Acked-by: Tony Lindgren
> Signed-off-by: Felipe Balbi
This one is clearly broken, and causes compile breakage...
> ---
> arch/arm/plat-omap/include/plat/omap-serial.h | 37 --
> drivers/tty/serial/omap-serial.c | 38
> +++
> 2 files changed, 38 insertions(+), 37 deletions(-)
>
> diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
> b/arch/arm/plat-omap/include/plat/omap-serial.h
> index a79ed8b..3c9fd3e 100644
> --- a/arch/arm/plat-omap/include/plat/omap-serial.h
> +++ b/arch/arm/plat-omap/include/plat/omap-serial.h
> @@ -105,45 +105,8 @@ struct uart_omap_dma {
> unsigned intrx_timeout;
> };
>
> -struct uart_omap_port {
> - struct uart_portport;
> - struct uart_omap_dmauart_dma;
> - struct device *dev;
> -
> - unsigned char ier;
> - unsigned char lcr;
> - unsigned char mcr;
> - unsigned char fcr;
> - unsigned char efr;
> - unsigned char dll;
> - unsigned char dlh;
> - unsigned char mdr1;
> - unsigned char scr;
> -
> - int use_dma;
> - /*
> - * Some bits in registers are cleared on a read, so they must
> - * be saved whenever the register is read but the bits will not
> - * be immediately processed.
> - */
> - unsigned intlsr_break_flag;
> - unsigned char msr_saved_flags;
> - charname[20];
> - unsigned long port_activity;
> - u32 context_loss_cnt;
> - u32 errata;
> - u8 wakeups_enabled;
>
> int DTR_gpio;
> int DTR_inverted;
> int DTR_active;
The whole struct has moved, but some fields left behind?
This looks to be caused by the rebase which includes Neil Brown's DTR
GPIO change[1]
> -
> - struct pm_qos_request pm_qos_request;
> - u32 latency;
> - u32 calc_latency;
> - struct work_struct qos_work;
> -};
> -
> -#define to_uart_omap_port(p) ((container_of((p), struct uart_omap_port,
> port)))
> -
> #endif /* __OMAP_SERIAL_H__ */
> diff --git a/drivers/tty/serial/omap-serial.c
> b/drivers/tty/serial/omap-serial.c
> index 881b652..164c3c9 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -70,6 +70,44 @@
> #define OMAP_UART_MVR_MAJ_SHIFT 8
> #define OMAP_UART_MVR_MIN_MASK 0x3f
>
> +struct uart_omap_port {
> + struct uart_portport;
> + struct uart_omap_dmauart_dma;
> + struct device *dev;
> +
> + unsigned char ier;
> + unsigned char lcr;
> + unsigned char mcr;
> + unsigned char fcr;
> + unsigned char efr;
> + unsigned char dll;
> + unsigned char dlh;
> + unsigned char mdr1;
> + unsigned char scr;
> +
> + int use_dma;
> + /*
> + * Some bits in registers are cleared on a read, so they must
> + * be saved whenever the register is read but the bits will not
> + * be immediately processed.
> + */
> + unsigned intlsr_break_flag;
> + unsigned char msr_saved_flags;
> + charname[20];
> + unsigned long port_activity;
> + u32 context_loss_cnt;
> + u32 errata;
> + u8 wakeups_enabled;
> + unsigned intirq_pending:1;
And this field was not in the original, yet the changelog describes this
as a move.
Why is a this new field added (and not described in the changelog.)
Kevin
[1]
commit 9574f36fb801035f6ab0fbb1b53ce2c12c17d100
Author: NeilBrown
Date: Mon Jul 30 10:30:26 2012 +1000
OMAP/serial: Add support for driving a GPIO as DTR.
OMAP hardware doesn't provide a phyisical DTR line, but
some configurations may need a DTR line which tracks whether
the device is open or not.
So allow a gpio to be configured as the DTR line.
Signed-off-by: NeilBrown
Signed-off-by: Greg Kroah-Hartman
--
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
Hi On Thu, 6 Sep 2012, Felipe Balbi wrote: > Hi guys, > > here's v4 of the omap uart patchset. No changes other than a rebase on top of > Greg's tty-next branch and Tony's Acked-by being added to a couple patches > > Note: I'm resending the series with Vikram's Software Flow Control fix anyway > as it can just be ignored if it's decided it needs to go into this merge > window. Was curious to know if these have been PM-tested, and if so, under what configurations? - Paul -- 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: Converting OMAP's custom vram allocator
On Wed, Sep 5, 2012 at 5:08 AM, Tomi Valkeinen wrote: > Hi, > > OMAP has a custom video ram allocator, which I'd like to remove and use > the standard dma allocation functions. > > There are two problems for which I'd like to hear suggestions or > comments: > > First one is that the dma_alloc_* functions map the allocated memory for > cpu use. In many cases with OMAP DSS (display subsystem) this is not > needed: the memory may be written only by the SGX or the DSP, and it's > only read by the DSS, so it's never touched by the CPU. see dma_alloc_attrs() and DMA_ATTR_NO_KERNEL_MAPPING > This is even more true when using VRFB on omap3 (and probably TILER on > omap4) for rotation, as VRFB hides the actual memory and offers rotated > views. In this case the backend memory is never accessed by anyone else > than VRFB. just fwiw, we don't actually need contiguous memory on o4/tiler :-) (well, at least if you ignore things like secure playback) > Is there a way to allocate the memory without creating a mapping? While > it won't break anything as such, the allocated areas can be quite large > thus causing large areas of the kernel's memory space to be needlessly > reserved. > > The second case is passing a framebuffer address from the bootloader to > the kernel. Often with mobile devices the bootloader will initialize the > display hardware, showing a company logo or such. To keep the image on > the screen when kernel starts we need to reserve the same physical > memory area early at boot, and use that for the framebuffer. with a bit of handwaving, this is possible. You can pass a base address to dma_declare_contiguous() when you setup your device's CMA pool. Although that doesn't really guarantee you're allocation from that pool is at offset zero, I suppose. > I'm not sure if there's any actual problem with this one, presuming > there is a solution for the first case. Somehow the memory is reserved > at early boot time, and this is passed to the fb driver. But can the > memory be managed the same way as in normal case (for example freeing > it), or does it need to be handled as a special case? special-casing it might be better.. although possibly a dma attr could be added for this to tell dma_alloc_from_contiguous() that we need a particular address within the CMA pool. It seems a bit like a hack, but OTOH I guess pretty much every consumer device would need a hack like this. BR, -R > Tomi > -- 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 5/5] omap-serial: Request pins using pinctrl framework
* Felipe Balbi [120906 13:01]:
> Hi,
>
> On Thu, Sep 06, 2012 at 11:58:32AM -0700, Tony Lindgren wrote:
> > Request pins using pinctrl framework. Only show a warning
> > on error as some boards set the pins in the bootloader
> > even if CONFIG_PINCTRL is enabled.
> >
> > Cc: linux-ser...@vger.kernel.org
> > Cc: Greg Kroah-Hartman
> > Signed-off-by: Tony Lindgren
> > ---
> > arch/arm/plat-omap/include/plat/omap-serial.h |1 +
> > drivers/tty/serial/omap-serial.c | 10 ++
> > 2 files changed, 11 insertions(+)
> >
> > diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
> > b/arch/arm/plat-omap/include/plat/omap-serial.h
> > index 1a52725..0f4de14 100644
> > --- a/arch/arm/plat-omap/include/plat/omap-serial.h
> > +++ b/arch/arm/plat-omap/include/plat/omap-serial.h
> > @@ -106,6 +106,7 @@ struct uart_omap_port {
> > struct uart_portport;
> > struct uart_omap_dmauart_dma;
> > struct platform_device *pdev;
> > + struct pinctrl *pins;
>
> this won't apply to Greg's tty-next as I moved this structure to the C
> file :-s
Hmm the tty-next fails to build right now for omaps:
drivers/tty/serial/omap-serial.c: In function ‘serial_omap_set_mctrl’:
drivers/tty/serial/omap-serial.c:514: error: ‘struct uart_omap_port’ has no
member named ‘DTR_gpio’
Maybe check how you want to fix that first? I can then update
my patch for tty-next.
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 v3 10/14] ARM: OMAP/ASoC: Zoom2: Let the codec to handle the hs_extmute GPIO
* Peter Ujfalusi [120906 05:13]: > Remove the use of set_hs_extmute callback and let the codec driver to > handle the extmute GPIO. > > Signed-off-by: Peter Ujfalusi > --- > arch/arm/mach-omap2/board-zoom-peripherals.c | 9 ++--- > arch/arm/mach-omap2/include/mach/board-zoom.h | 2 -- Here board-zoom.h will be moved to be just #include "board-zoom.h". But we can deal with that once I have an immutable header cleanup branch that you can pull in. 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
Re: [PATCH v6 2/3] arm/dts: AM33XX: Configure pinmuxs for user leds control on Bone
* AnilKumar Ch [120905 04:42]:
> Adds GPIO pinctrl nodes to am3358_pinmux master node to control
> user leds (USR0, USR1, USR2 and USR3) present on BeagleBone.
>
> [k...@dominion.thruhere.net: led0, led1 suggested by koen]
> Signed-off-by: AnilKumar Ch
> ---
> arch/arm/boot/dts/am335x-bone.dts | 43
> +
> 1 file changed, 43 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am335x-bone.dts
> b/arch/arm/boot/dts/am335x-bone.dts
> index c634f87..822efe6 100644
> --- a/arch/arm/boot/dts/am335x-bone.dts
> +++ b/arch/arm/boot/dts/am335x-bone.dts
> @@ -18,11 +18,54 @@
> reg = <0x8000 0x1000>; /* 256 MB */
> };
>
> + am3358_pinmux: pinmux@44e10800 {
> + userled_pins: pinmux_userled_pins {
> + pinctrl-single,pins = <
> + 0x54 0x7/* gpmc_a5.gpio1_21, OUTPUT |
> MODE7 */
> + 0x58 0x17 /* gpmc_a6.gpio1_22,
> OUTPUT_PULLUP | MODE7 */
> + 0x5c 0x7/* gpmc_a7.gpio1_23, OUTPUT |
> MODE7 */
> + 0x60 0x17 /* gpmc_a8.gpio1_24,
> OUTPUT_PULLUP | MODE7 */
> + >;
> + };
> + };
> +
Just checking.. am3358_pinmux should be am33xx_pinmux in this patch
too as discussed.
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: Converting OMAP's custom vram allocator
* Tomi Valkeinen [120905 03:09]: > Hi, > > OMAP has a custom video ram allocator, which I'd like to remove and use > the standard dma allocation functions. > > There are two problems for which I'd like to hear suggestions or > comments: > > First one is that the dma_alloc_* functions map the allocated memory for > cpu use. In many cases with OMAP DSS (display subsystem) this is not > needed: the memory may be written only by the SGX or the DSP, and it's > only read by the DSS, so it's never touched by the CPU. > > This is even more true when using VRFB on omap3 (and probably TILER on > omap4) for rotation, as VRFB hides the actual memory and offers rotated > views. In this case the backend memory is never accessed by anyone else > than VRFB. > > Is there a way to allocate the memory without creating a mapping? While > it won't break anything as such, the allocated areas can be quite large > thus causing large areas of the kernel's memory space to be needlessly > reserved. > > The second case is passing a framebuffer address from the bootloader to > the kernel. Often with mobile devices the bootloader will initialize the > display hardware, showing a company logo or such. To keep the image on > the screen when kernel starts we need to reserve the same physical > memory area early at boot, and use that for the framebuffer. > > I'm not sure if there's any actual problem with this one, presuming > there is a solution for the first case. Somehow the memory is reserved > at early boot time, and this is passed to the fb driver. But can the > memory be managed the same way as in normal case (for example freeing > it), or does it need to be handled as a special case? Sounds like you might be able to do this all with CMA with some additional patches? 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 0/2] ARM: omap/dts: Add support for Gumstix Overo with Tobi expansion
* Florian Vaussard [120831 09:07]: > The Gumstix Overo is a computer on module using an OMAP3 processor. > This module must be plugged into an expansion board. > > This patchset adds a first device tree support for the Overo, using the > Tobi expansion board. The current support is able to boot and mount > the rootfs from MMC, with a few extra features. > > The first patch creates the device tree for both the Overo and the > Tobi expansion board, and updates the dtb build target. > > The second patch updates the omap/dts documentation. > > This patchset applies on tony's tree [1], devel-dt branch. Great, I'm assuming Benoit will pick this up as well. Regards, Tony > Regards, > > Florian > > [1] http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=summary > > > Florian Vaussard (2): > ARM: omap/dts: Add support for Gumstix Overo with Tobi expansion > board > ARM: omap/dts: update the documentation > > .../devicetree/bindings/arm/omap/omap.txt |3 + > arch/arm/boot/dts/omap3-overo.dtsi | 42 > > arch/arm/boot/dts/omap3-tobi.dts | 35 > arch/arm/mach-omap2/Makefile.boot |2 +- > 4 files changed, 81 insertions(+), 1 deletions(-) > create mode 100644 arch/arm/boot/dts/omap3-overo.dtsi > create mode 100644 arch/arm/boot/dts/omap3-tobi.dts > > -- > 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 v2 0/2] gpio-twl4030: add new device tree properties
* Benoit Cousson [120905 07:42]: > Hi Florian, > > On 09/05/2012 09:46 AM, Florian Vaussard wrote: > > Hello, > > > > A number of platform data are missing when using twl4030/gpio from a > > device tree. This patchset adds the missing properties, updates the > > documentation with the new bindings, and updates existing device trees. > > It mainly enables LEDA and LEDB outputs, as well as pullups / > > pulldowns on GPIOs. > > > > The 1st patch changes the device driver and updates the documentation. > > The 2nd patch updates the device trees for BeagleBoard and omap3-evm. > > > > Changes since v1: > > - Patches on driver and documentation merged into the same patch > > - Put device trees' values in hexadecimal > > - Handle bool property using of_property_read_bool() > > - Prefix the patches with the correct convention > > Thanks for the update. > > > Tested on Gumstix Overo. V1 was tested on omap3-evm by Vaibhav Hiremath. > > I've just tested it on beagle xM. I can play with D12 led using: > > echo 255 > /sys/class/leds/beagleboard\:\:pmu_stat/brightness > > Tested-by: Benoit Cousson > > > > BTW: who will merge this? > > Since Linus already acked it, Tony can merge it. > > > Tony, > > I can add that series in my DTS series for 3.7 if you want. Yes please do thanks. 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 1/3] gpio-twl4030: get platform data from device tree
* Linus Walleij [120904 00:31]: > On Mon, Sep 3, 2012 at 3:54 PM, Florian Vaussard > wrote: > > > Adds a number of missing properties to the device tree of > > twl4030/gpio: > > - "ti,use-leds" -> .use_leds > > - "ti,debounce" -> .debounce > > - "ti,mmc-cd"-> .mmc_cd > > - "ti,pullups" -> .pullups > > - "ti,pulldowns" -> .pulldowns > > > > Signed-off-by: Florian Vaussard > > Acked-by: Linus Walleij > > Tony will you carry this in the OMAP tree? Yes thanks I can queue this once the acks are there, I guess Benoit is planning to test the series first. 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 v6 10/10] ARM: OMAP2+: tusb6010: generic timing calculation
* Mohammed, Afzal [120906 00:40]: > Hi Tony, > > On Mon, Sep 03, 2012 at 11:04:10, Mohammed, Afzal wrote: > > On Mon, Aug 27, 2012 at 14:04:44, Mohammed, Afzal wrote: > > > On Sat, Aug 25, 2012 at 01:16:30, Tony Lindgren wrote: > > > > > This hangs n800 during the boot. > > Paul reported that n800 stopped booting on OMAP baseline [1] > due to an mmc issue and has posted a solution [2]. > > Are you facing the same issue ?, if so, then it is not > due to this series. No that's a separate issue. Your series works except for this patch makes thing hang. Regards, Tony > I tried to get an n800, but has been unsuccessful. > > Regards > Afzal > > [1] http://marc.info/?l=linux-omap&m=134685988517580&w=2 > [2] http://www.spinics.net/lists/arm-kernel/msg190879.html > > > > > > > > Shall I read the above as n800 boot without patch 10/10, > > > but with the other patches in this series ? > > > > > > As per the board file, n800 has tusb6010 as well as > > > OneNAND in sync read & async write mode, was OneNAND > > > working without 10/10. > > > > > > Do you have any idea, which timing could have gone wrong, > > > can you please sent me DEBUG enabled gpmc log with and > > > without 10/10. > > > > Can you please sent me GPMC DEBUG enabled logs with and > > without this series. > -- 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 6/9] ARM: OMAP: Move gpio.h to include/linux/platform_data
* Mohammed, Afzal [120903 03:15]: > Hi, > > On Fri, Aug 31, 2012 at 06:22:34, Tony Lindgren wrote: > > This way we can remove includes of plat/gpio.h which won't work > > with the single zImage support. > > > > Note that we also remove the cpu_class_is_omap2() check > > in gpio-omap.c as the drivers should not call it as we need to > > make it local to arch/arm/mach-omap2 for single zImage support. > > > > While at it, arrange the related includes in the standard way. > > > > Cc: Grant Likely > > Cc: Linus Walleij > > Cc: linux-...@lists.infradead.org > > Cc: alsa-de...@alsa-project.org > > Acked-by: Tony Lindgren > > I think there is only one Tony ;) Heh thanks I'll tell myself to replace it with Signed-off-by :) 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 v2 6/8] ARM/dts: omap3-beagle: Enable audio support
* Peter Ujfalusi [120829 06:31]:
> Add the needed sections to enable audio support on BeagleBoard when booted
> with DT blob.
>
> Signed-off-by: Peter Ujfalusi
> ---
> arch/arm/boot/dts/omap3-beagle.dts | 14 ++
> 1 files changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap3-beagle.dts
> b/arch/arm/boot/dts/omap3-beagle.dts
> index cdcb98c..28cf180 100644
> --- a/arch/arm/boot/dts/omap3-beagle.dts
> +++ b/arch/arm/boot/dts/omap3-beagle.dts
I've renamed this to omap3-beagle-xm.dts as it's for beagle xm only
based on the 512 MB of ram. Not a big deal, we can deal with it
while I pull in the branch from Benoit if it does not get automatically
resolved.
Regards,
Tony
> @@ -17,6 +17,14 @@
> device_type = "memory";
> reg = <0x8000 0x2000>; /* 512 MB */
> };
> +
> + sound {
> + compatible = "ti,omap-twl4030";
> + ti,model = "omap3beagle";
> +
> + ti,mcbsp = <&mcbsp2>;
> + ti,codec = <&twl_audio>;
> + };
> };
>
> &i2c1 {
> @@ -32,6 +40,12 @@
> regulator-min-microvolt = <180>;
> regulator-max-microvolt = <300>;
> };
> +
> + twl_audio: audio {
> + compatible = "ti,twl4030-audio";
> + codec {
> + };
> + };
> };
> };
>
> --
> 1.7.8.6
>
--
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 2/8] ARM/dts: omap2420-h4: Include omap2420.dtsi file instead the common omap2
* Peter Ujfalusi [120829 06:31]:
> Since the board is based on OMAP2420 we should include the dedicated dtsi
> file (which includes the common omap2 dtsi).
>
> Signed-off-by: Peter Ujfalusi
> ---
> arch/arm/boot/dts/omap2420-h4.dts |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap2420-h4.dts
> b/arch/arm/boot/dts/omap2420-h4.dts
> index 25b50b7..77b84e1 100644
> --- a/arch/arm/boot/dts/omap2420-h4.dts
> +++ b/arch/arm/boot/dts/omap2420-h4.dts
> @@ -7,7 +7,7 @@
> */
> /dts-v1/;
>
> -/include/ "omap2.dtsi"
> +/include/ "omap2420.dtsi"
>
> / {
> model = "TI OMAP2420 H4 board";
Oops looks like I have this too in one of my patches. I'll drop
that part in my patches.
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 0/8] OMAPDSS: Misc improvements
* Tomi Valkeinen [120904 00:23]: > Hi Tony, > > Can you check the arch/arm patches below, and suggest how you'd like to > go forward with them? Acked them, then as soon as we have the initial immutable header move branch available, you should merge with that to avoid merge conflicts in upstream. 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 3/8] OMAP4: TWL: add vdda_hdmi_dac regulator supply
* Tomi Valkeinen [120823 06:46]:
> HDMI requires vdda_hdmi_dac (vdac) power for operation. The regulator,
> or the regulator supplying the vdac, has been enabled by default and
> things have worked without the HDMI driver enabling the vdac.
>
> I encountered the problem when implementing HDMI device tree support,
> where the regulator was not enabled by default.
>
> This patch adds the vdda_hdmi_dac to twl-common.c so that the HDMI
> driver can use it.
>
> Signed-off-by: Tomi Valkeinen
> Cc: Tony Lindgren
Looks safe to merge vi fb changes:
Acked-by: Tony Lindgren
> ---
> arch/arm/mach-omap2/twl-common.c |6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/twl-common.c
> b/arch/arm/mach-omap2/twl-common.c
> index 119d5a9..bf90356 100644
> --- a/arch/arm/mach-omap2/twl-common.c
> +++ b/arch/arm/mach-omap2/twl-common.c
> @@ -257,6 +257,10 @@ static struct twl4030_usb_data omap4_usb_pdata = {
> .phy_suspend= omap4430_phy_suspend,
> };
>
> +static struct regulator_consumer_supply omap4_vdda_hdmi_dac_supplies[] = {
> + REGULATOR_SUPPLY("vdda_hdmi_dac", "omapdss_hdmi"),
> +};
> +
> static struct regulator_init_data omap4_vdac_idata = {
> .constraints = {
> .min_uV = 180,
> @@ -266,6 +270,8 @@ static struct regulator_init_data omap4_vdac_idata = {
> .valid_ops_mask = REGULATOR_CHANGE_MODE
> | REGULATOR_CHANGE_STATUS,
> },
> + .num_consumer_supplies = ARRAY_SIZE(omap4_vdda_hdmi_dac_supplies),
> + .consumer_supplies = omap4_vdda_hdmi_dac_supplies,
> .supply_regulator = "V2V1",
> };
>
> --
> 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 7/8] OMAP: 4430SDP: remove DSI clock config from board file
* Tomi Valkeinen [120823 06:46]: > DSI clocks are now configured dynamically by the DSI driver, so we can > remove the hardcoded clock configuration from the board file. > > Signed-off-by: Tomi Valkeinen > Cc: Tony Lindgren This should be safe to merge via fb tree: 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
Re: [PATCH V5 0/6] OMAPDSS: Cleanup cpu_is checks
* Tomi Valkeinen [120831 04:24]: > On Thu, 2012-08-30 at 10:19 -0700, Tony Lindgren wrote: > > Hi, > > > > * Tomi Valkeinen [120830 00:35]: > > > On Wed, 2012-08-29 at 17:20 -0700, Tony Lindgren wrote: > > > > > > > > Good to see this, we need this badly to avoid blocking > > > > single zImage effort on omaps. Can you also please take > > > > > > What is the issue with single zImage? How do cpu_is_ check affect it? > > > > The usage for that should only be limited to arch/arm/mach-omap2 > > so we can make cpu.h local as we can't include mach and plat > > header files from the drivers with single zImage. > > Ok. > > > > $ git grep -E " > > drivers/video/omap/lcd_ams_delta.c:#include > > > * Needs to be moved > > > > Yes, that should be either mach/board-ams-delta.h, or separate driver > > specific headers in include/linux/platform_data. For omap1 we are not > > planning common zImage support, so let's just make sure we're not > > breaking anything there as people are still using it. > > Hmm, so did I understand right, for omap1 stuff we can still include > from arch/arm/mach-omap1/include/mach? Yes that's a separate issue to fix that up for armv4/5 common zImage support if people want to do that later on. > If so, that makes things easier. I can manage the omap2+ stuff fine, but > I have no experience with omap1, nor do I have any omap1 devices. So I'd > rather keep the omap1 code as it is, in fear that I'd just break it > totally, and I'd rather spend my time on omap2+ code. 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: Interaction between USB phy power and MADC driver
On Thu, Sep 06, 2012 at 02:57:42PM -0400, Frank Agius wrote: > I'm seeing what I think is an unintended consequence of powering down > the USB phy. All the relavent code is in file twl4030_usb.c. My > system is setup to use the USB in otg mode. If nothing is connected > to the USB OTG port, the phy suspension code is called. In the chain > of calls that follows, the vusb3v1 regulator is disabled. However, > according to the OMAP power management manual, vusb3v1 is used "to > bias the analog multiplexers on the four MCPC pins between the carkit > and the MADC". I've seen if there is no bias on this mux, the MADC > driver returns incorrect counts on these 4 pins that should be in A/D > mode. If I plug something into the USB OTG port, the MADC driver > returns the expected counts. I also created a debug version of the > twl4030-usb driver, with the disabling of the vusb3v1 commented out > and the MADC returns the correct counts regardless of the state of > the USB OTG port. > > Since the vusb3v1 regulator is required for the proper operation of > the mux and by extension the MADC and carkit mode, shouldn't it > always be enabled? If MADC needs that regulator, it should request it as well so the regulator framework has correct usecounts. Also, IIRC there is a "suspend" mode for the regulator which won't power it down, but it will consume minimal power while mantaining MADC working. -- balbi signature.asc Description: Digital signature
Re: [PATCH 5/5] omap-serial: Request pins using pinctrl framework
Hi,
On Thu, Sep 06, 2012 at 11:58:32AM -0700, Tony Lindgren wrote:
> Request pins using pinctrl framework. Only show a warning
> on error as some boards set the pins in the bootloader
> even if CONFIG_PINCTRL is enabled.
>
> Cc: linux-ser...@vger.kernel.org
> Cc: Greg Kroah-Hartman
> Signed-off-by: Tony Lindgren
> ---
> arch/arm/plat-omap/include/plat/omap-serial.h |1 +
> drivers/tty/serial/omap-serial.c | 10 ++
> 2 files changed, 11 insertions(+)
>
> diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
> b/arch/arm/plat-omap/include/plat/omap-serial.h
> index 1a52725..0f4de14 100644
> --- a/arch/arm/plat-omap/include/plat/omap-serial.h
> +++ b/arch/arm/plat-omap/include/plat/omap-serial.h
> @@ -106,6 +106,7 @@ struct uart_omap_port {
> struct uart_portport;
> struct uart_omap_dmauart_dma;
> struct platform_device *pdev;
> + struct pinctrl *pins;
this won't apply to Greg's tty-next as I moved this structure to the C
file :-s
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module
* Felipe Balbi [120906 10:23]:
> Hi,
>
> On Thu, Sep 06, 2012 at 08:13:03PM +0300, Felipe Balbi wrote:
> > Hi,
> >
> > On Thu, Sep 06, 2012 at 09:04:58PM +0530, Vaibhav Hiremath 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 ;)
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 5/5] omap-serial: Request pins using pinctrl framework
* Tony Lindgren [120906 11:59]:
> Request pins using pinctrl framework. Only show a warning
> on error as some boards set the pins in the bootloader
> even if CONFIG_PINCTRL is enabled.
>
> Cc: linux-ser...@vger.kernel.org
> Cc: Greg Kroah-Hartman
> Signed-off-by: Tony Lindgren
> ---
Greg, this patch should be OK for you to pick, it should not break
anything even if pinctrl is not available yet. Let me know if it
needs rebasing on top of other things you've queued for omap-serial.
Regards,
Tony
> arch/arm/plat-omap/include/plat/omap-serial.h |1 +
> drivers/tty/serial/omap-serial.c | 10 ++
> 2 files changed, 11 insertions(+)
>
> diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
> b/arch/arm/plat-omap/include/plat/omap-serial.h
> index 1a52725..0f4de14 100644
> --- a/arch/arm/plat-omap/include/plat/omap-serial.h
> +++ b/arch/arm/plat-omap/include/plat/omap-serial.h
> @@ -106,6 +106,7 @@ struct uart_omap_port {
> struct uart_portport;
> struct uart_omap_dmauart_dma;
> struct platform_device *pdev;
> + struct pinctrl *pins;
>
> unsigned char ier;
> unsigned char lcr;
> diff --git a/drivers/tty/serial/omap-serial.c
> b/drivers/tty/serial/omap-serial.c
> index d3cda0c..068e88c 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -39,6 +39,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -1492,6 +1493,13 @@ static int serial_omap_probe(struct platform_device
> *pdev)
> goto err_port_line;
> }
>
> + up->pins = pinctrl_get_select_default(&pdev->dev);
> + if (IS_ERR(up->pins)) {
> + dev_warn(&pdev->dev, "did not get pins for uart%i error: %li\n",
> + up->port.line, PTR_ERR(up->pins));
> + up->pins = NULL;
> + }
> +
> sprintf(up->name, "OMAP UART%d", up->port.line);
> up->port.mapbase = mem->start;
> up->port.membase = devm_ioremap(&pdev->dev, mem->start,
> @@ -1570,6 +1578,8 @@ static int serial_omap_remove(struct platform_device
> *dev)
> pm_runtime_disable(&up->pdev->dev);
> uart_remove_one_port(&serial_omap_reg, &up->port);
> pm_qos_remove_request(&up->pm_qos_request);
> + if (up->pins)
> + pinctrl_put(up->pins);
> }
>
> platform_set_drvdata(dev, NULL);
>
> --
> 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
--
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] pinctrl: pinctrl-single: Add pinctrl-single,bits type of mux
Hi Peter,
* Peter Ujfalusi [120905 02:02]:
> 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.
You have a typo here: ^
> --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
> @@ -31,6 +31,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 can 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.
> +
Is it now safe to assume that we always have width of three if
pinctrl-single,bits is specified? The reason I'm asking is..
> @@ -657,18 +664,29 @@ static int pcs_parse_one_pinctrl_entry(struct
> pcs_device *pcs,
> {
> struct pcs_func_vals *vals;
> const __be32 *mux;
> - int size, rows, *pins, index = 0, found = 0, res = -ENOMEM;
> + int size, params, rows, *pins, index = 0, found = 0, res = -ENOMEM;
> struct pcs_function *function;
>
> - mux = of_get_property(np, PCS_MUX_NAME, &size);
> - if ((!mux) || (size < sizeof(*mux) * 2)) {
> - dev_err(pcs->dev, "bad data for mux %s\n",
> - np->name);
> + mux = of_get_property(np, PCS_MUX_PINS_NAME, &size);
> + if (mux) {
> + params = 2;
> + } else {
> + mux = of_get_property(np, PCS_MUX_BITS_NAME, &size);
> + if (!mux) {
> + dev_err(pcs->dev, "no valid property for %s\n",
> + np->name);
> + return -EINVAL;
> + }
> + params = 3;
> + }
..because here we could assume the default value for params is 2
if pinctrl-single,pins is specified, and otherwise params is 3
if pinctrl-single,bits is specified for the controller. That would
avoid querying a potentially non-exiting property for each entry.
> @@ -686,6 +704,10 @@ static int pcs_parse_one_pinctrl_entry(struct pcs_device
> *pcs,
> val = be32_to_cpup(mux + index++);
> vals[found].reg = pcs->base + offset;
> vals[found].val = val;
> + if (params == 3) {
> + val = be32_to_cpup(mux + index++);
> + vals[found].mask = val;
> + }
>
> pin = pcs_get_pin_by_offset(pcs, offset);
> if (pin < 0) {
Here params too would be then set during probe already.
Other than that, seems to still work for me for my test cases.
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 1/2] pinctrl: pinctrl-single: Make sure we do not change bits outside of mask
* Peter Ujfalusi [120905 02:02]:
> Use the pcs->fmask to make sure that the value is not changing (setting)
> bits in areas where it should not.
> To avoid situations like this:
>
> pmx_dummy: pinmux@4a100040 {
> compatible = "pinctrl-single";
> reg = <0x4a100040 0x0196>;
> #address-cells = <1>;
> #size-cells = <0>;
> pinctrl-single,register-width = <16>;
> pinctrl-single,function-mask = <0x00ff>;
> };
>
> &pmx_dummy {
> pinctrl-names = "default";
> pinctrl-0 = <&board_pins>;
>
> board_pins: pinmux_board_pins {
> pinctrl-single,pins = <
> 0x6c 0xf0f
> 0x6e 0x10f
> 0x70 0x23f
> 0x72 0xa5f
> >;
> };
> };
>
> Signed-off-by: Peter Ujfalusi
Thanks this is a valid fix:
Acked-by: Tony Lindgren
> ---
> drivers/pinctrl/pinctrl-single.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/pinctrl-single.c
> b/drivers/pinctrl/pinctrl-single.c
> index 76a4260..3508631 100644
> --- a/drivers/pinctrl/pinctrl-single.c
> +++ b/drivers/pinctrl/pinctrl-single.c
> @@ -337,7 +337,7 @@ static int pcs_enable(struct pinctrl_dev *pctldev,
> unsigned fselector,
> vals = &func->vals[i];
> val = pcs->read(vals->reg);
> val &= ~pcs->fmask;
> - val |= vals->val;
> + val |= (vals->val & pcs->fmask);
> pcs->write(val, vals->reg);
> }
>
> --
> 1.7.12
>
--
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] musb: Kill __init from function that are called at other times as well.
Hi Felipe, On Sep 6, 2012, at 8:41 PM, Felipe Balbi wrote: > Hi, > > On Thu, Sep 06, 2012 at 08:42:56PM +0300, Pantelis Antoniou wrote: >> >> On Sep 6, 2012, at 8:37 PM, Felipe Balbi wrote: >> >>> Hi, >>> >>> On Thu, Sep 06, 2012 at 08:36:39PM +0300, Pantelis Antoniou wrote: Hi Felipe I see about __devinit. There's no crash because in those logs the __init modifiers are gone. >>> >>> it'd be cool to see the crash, though ;-) >>> >>> -- >>> balbi >> >> Heh, OK, >> >> My word is not enough? :) >> >> Gimme a few minutes... > > Didn't say that, but I don't know what issue you're talking about since > __devinit is supposed to keep .devinit.text intact unless !HOTPLUG. > > This could be a bug on some linker script (though unlikely) just trying > to get understand the issue before I apply the patch, that's all. > > -- > balbi With my init removal patch reverted, but with the instrumentation printk still in Board hanged this time. It is not certain you will crash, you might get a hang or anything else. It all depends on what kind of garbage is there in memory when you start calling into the void. The results are boundedly undefined :) Regards -- Pantelis > root@beagleboard:~# modprobe omap2430 > [ 119.741851] drivers/usb/musb/omap2430.c:584 (omap2430) omap2430_init > [ 119.748870] drivers/usb/musb/omap2430.c:445 (omap2430) omap2430_probe > root@beagleboard:~# [ 119.797760] drivers/usb/musb/musb_core.c:2409 > (musb_hdrc) musb_init > [ 119.804504] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host) > [ 119.811004] drivers/usb/musb/musb_core.c:2118 (musb_hdrc) musb_probe > [ 119.817962] drivers/usb/musb/musb_core.c:1888 (musb_hdrc) > musb_init_controller > [ 119.825622] drivers/usb/musb/musb_core.c:1813 (musb_hdrc) allocate_instance > [ 119.841735] twl4030_usb twl4030_usb: twl4030_phy_resume > [ 119.847290] drivers/usb/musb/musbhsdma.c:391 (musb_hdrc) > dma_controller_create > [ 119.855041] drivers/usb/musb/musb_core.c:1388 (musb_hdrc) musb_core_init > [ 119.862121] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, > bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) > [ 119.873229] musb-hdrc: MHDRC RTL version 1.800 > [ 119.877990] drivers/usb/musb/musb_core.c:1246 (musb_hdrc) > ep_config_from_table > [ 119.885620] musb-hdrc: setup fifo_mode 4 > [ 119.889801] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup > [ 119.896514] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup > [ 119.903228] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup > [ 119.909912] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup > [ 119.916625] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup > [ 119.923339] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup > [ 119.930084] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup > [ 119.936798] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup > [ 119.943542] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup > [ 119.950256] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup > [ 119.956939] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup > [ 119.963653] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup > [ 119.970367] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup > [ 119.977081] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup > [ 119.983825] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup > [ 119.990539] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup > [ 119.997253] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup > [ 120.003936] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup > [ 120.010650] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup > [ 120.017364] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup > [ 120.024078] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup > [ 120.030792] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup > [ 120.037536] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup > [ 120.044250] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup > [ 120.050933] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup > [ 120.057678] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup > [ 120.064392] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup > [ 120.071105] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup > [ 120.077819] musb-hdrc: 28/31 max ep, 16384/16384 memory > [ 120.083587] drivers/usb/musb/musb_gadget.c:1879 (musb_hdrc) > musb_gadget_setup > [ 120.091156] drivers/usb/musb/musb_gadget.c:1842 (musb_hdrc) > musb_g_init_endpoints > [ 120.099060] drivers/usb/musb/musb_gadget.c:1803 (musb_hdrc) > init_peripheral_ep > [ 120.106689] drivers/usb/musb/musb_gadget.c:1803 (musb_hdrc) > init_peripheral_ep > [ 120.114318] drivers/usb/musb/musb_gadget.c:1803 (musb_hdrc) > init_peripheral_ep > [ 120.121948] drivers/usb/musb/musb_gadget.c:1803 (musb_hdrc) > init_peripher
Re: [PATCH] perf: Use pre-empt safe cpu_get/put insted of smp_processor_id
Fixed Paul's email address
On Thu, Sep 6, 2012 at 8:56 PM, Jean Pihet wrote:
> Hi Roger,
>
> On Fri, Aug 10, 2012 at 4:05 PM, 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
>>
>> Signed-off-by: Roger Quadros
>
> What his the status of the patch? Has it been reviewed and taken in an
> integration tree? I cannot find anything about it in l-o and
> linux-next.
>
> I have some changes on-going in the OMAP PM code and I would like to
> know if $SUBJECT is applicable.
>
> Regards,
> Jean
>
>> ---
>> 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();
>> clk->ops->disable(clk);
>> }
>>
>> @@ -339,7 +340,8 @@ int omap2_clk_enable(struct clk *clk)
>> }
>>
>> if (clk->ops && clk->ops->enable) {
>> - trace_clock_enable(clk->name, 1, smp_processor_id());
>> + trace_clock_enable(clk->name, 1, get_cpu());
>> + put_cpu();
>> ret = clk->ops->enable(clk);
>> if (ret) {
>> WARN(1, "clock: %s: could not enable: %d\n",
>> @@ -380,7 +382,8 @@ int omap2_clk_set_rate(struct clk *clk, unsigned long
>> rate)
>>
>> /* dpll_ck, core_ck, virt_prcm_set; plus all clksel clocks */
>> if (clk->set_rate) {
>> - trace_clock_set_rate(clk->name, rate, smp_processor_id());
>> + trace_clock_set_rate(clk->name, rate, get_cpu());
>> + put_cpu();
>> ret = clk->set_rate(clk, rate);
>> }
>>
>> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
>> index e4fc88c..81fec2e 100644
>> --- a/arch/arm/mach-omap2/pm34xx.c
>> +++ b/arch/arm/mach-omap2/pm34xx.c
>> @@ -357,18 +357,22 @@ void omap_sram_idle(void)
>>
>> static void omap3_pm_idle(void)
>> {
>> + unsigned cpu;
>> +
>> local_fiq_disable();
>>
>> if (omap_irq_pending())
>> goto out;
>>
>> - trace_power_start(POWER_CSTATE, 1, smp_processor_id());
>> - trace_cpu_idle(1, smp_processor_id());
>> + cpu = get_cpu();
>> + trace_power_start(POWER_CSTATE, 1, cpu);
>> + trace_cpu_idle(1, cpu);
>>
>> omap_sram_idle();
>>
>> - trace_power_end(smp_processor_id());
>> - trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
>> + trace_power_end(cpu);
>> + trace_cpu_idle(PWR_EVENT_EXIT, cpu);
>> + put_cpu();
>>
>> out:
>> local_fiq_enable();
>> diff --git a/arch/arm/mach-omap2/powerdomain.c
>> b/arch/arm/mach-omap2/powerdomain.c
>> index 69b36e1..138bf86 100644
>> --- a/arch/arm/mach-omap2/powerdomain.c
>> +++ b/arch/arm/mach-omap2/powerdomain.c
>> @@ -169,7 +169,8 @@ static int _pwrdm_state_switch(struct powerdomain
>> *pwrdm, int flag)
>>((state & OMAP_POWERSTATE_MASK) << 8)
>> |
>>((prev & OMAP_POWERSTATE_MASK) << 0));
>> trace_power_domain_target(pwrdm->name, trace_state,
>> - smp_processor_id());
>> + get_cpu());
>> + put_cpu();
>> }
>> break;
>> default:
>> @@ -491,7 +492,8 @@ int pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8
>> pwrst)
>> if (arch_pwrdm && arch_pwrdm->pwrdm_set_next_pwrst) {
>> /* Trace the pwrdm desired target state */
>> trace_power_domain_target(pwrdm->name, pwrst,
>> - smp_processor_id());
>> + get_cpu());
>> + put_cpu();
>> /* Program the pwrdm desired target state */
>> ret = arch_pwrdm->pwrdm_set_next_pwrst(pwrdm, pwrst);
>> }
>> --
>> 1.7.4.1
>>
--
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 5/5] omap-serial: Request pins using pinctrl framework
Request pins using pinctrl framework. Only show a warning
on error as some boards set the pins in the bootloader
even if CONFIG_PINCTRL is enabled.
Cc: linux-ser...@vger.kernel.org
Cc: Greg Kroah-Hartman
Signed-off-by: Tony Lindgren
---
arch/arm/plat-omap/include/plat/omap-serial.h |1 +
drivers/tty/serial/omap-serial.c | 10 ++
2 files changed, 11 insertions(+)
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 1a52725..0f4de14 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -106,6 +106,7 @@ struct uart_omap_port {
struct uart_portport;
struct uart_omap_dmauart_dma;
struct platform_device *pdev;
+ struct pinctrl *pins;
unsigned char ier;
unsigned char lcr;
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index d3cda0c..068e88c 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1492,6 +1493,13 @@ static int serial_omap_probe(struct platform_device
*pdev)
goto err_port_line;
}
+ up->pins = pinctrl_get_select_default(&pdev->dev);
+ if (IS_ERR(up->pins)) {
+ dev_warn(&pdev->dev, "did not get pins for uart%i error: %li\n",
+up->port.line, PTR_ERR(up->pins));
+ up->pins = NULL;
+ }
+
sprintf(up->name, "OMAP UART%d", up->port.line);
up->port.mapbase = mem->start;
up->port.membase = devm_ioremap(&pdev->dev, mem->start,
@@ -1570,6 +1578,8 @@ static int serial_omap_remove(struct platform_device *dev)
pm_runtime_disable(&up->pdev->dev);
uart_remove_one_port(&serial_omap_reg, &up->port);
pm_qos_remove_request(&up->pm_qos_request);
+ if (up->pins)
+ pinctrl_put(up->pins);
}
platform_set_drvdata(dev, NULL);
--
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/5] arm/dts: Mux uart pins for omap4-sdp
Mux uart pins for the serial ports.
Signed-off-by: Tony Lindgren
---
arch/arm/boot/dts/omap4-sdp.dts | 42 +++
1 file changed, 42 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index dbcdc4a..00edbe6 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -115,6 +115,33 @@
};
};
+&omap4_pmx_core {
+ uart2_pins: pinmux_uart2_pins {
+ pinctrl-single,pins = <
+ 0xd8 0x118 /* uart2_cts.uart2_cts INPUT_PULLUP |
MODE0 */
+ 0xda 0 /* uart2_rts.uart2_rts OUTPUT | MODE0 */
+ 0xdc 0x118 /* uart2_rx.uart2_rx INPUT_PULLUP |
MODE0 */
+ 0xde 0 /* uart2_tx.uart2_tx OUTPUT | MODE0 */
+ >;
+ };
+
+ uart3_pins: pinmux_uart3_pins {
+ pinctrl-single,pins = <
+ 0x100 0x118 /* uart3_cts_rctx.uart3_cts_rctx
INPUT_PULLUP | MODE0 */
+ 0x102 0 /* uart3_rts_sd.uart3_rts_sd OUTPUT |
MODE0 */
+ 0x104 0x100 /* uart3_rx_irrx.uart3_rx_irrx INPUT |
MODE0 */
+ 0x106 0 /* uart3_tx_irtx.uart3_tx_irtx OUTPUT |
MODE0 */
+ >;
+ };
+
+ uart4_pins: pinmux_uart4_pins {
+ pinctrl-single,pins = <
+ 0x11c 0x100 /* uart4_rx.uart4_rx INPUT | MODE0 */
+ 0x11e 0 /* uart4_tx.uart4_tx OUTPUT | MODE0 */
+ >;
+ };
+};
+
&i2c1 {
clock-frequency = <40>;
@@ -226,3 +253,18 @@
bus-width = <4>;
ti,non-removable;
};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2_pins>;
+};
+
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart3_pins>;
+};
+
+&uart4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart4_pins>;
+};
--
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/5] ARM: OMAP2+: select PINCTRL in Kconfig
From: AnilKumar Ch Select PINCTRL in Kconfig under Typical OMAP configuration, this is required to add pinctrl driver to omap2+ family of devices. Signed-off-by: AnilKumar Ch [t...@atomide.com: updated to select pinctrl-single in defconfig] Signed-off-by: Tony Lindgren --- arch/arm/configs/omap2plus_defconfig |1 + arch/arm/mach-omap2/Kconfig |1 + 2 files changed, 2 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index e58edc3..6230304 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -123,6 +123,7 @@ CONFIG_HW_RANDOM=y CONFIG_I2C_CHARDEV=y CONFIG_SPI=y CONFIG_SPI_OMAP24XX=y +CONFIG_PINCTRL_SINGLE=y CONFIG_DEBUG_GPIO=y CONFIG_GPIO_SYSFS=y CONFIG_GPIO_TWL4030=y diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 4a4d058..e45bbff 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -18,6 +18,7 @@ config ARCH_OMAP2PLUS_TYPICAL select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4 select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4 select HIGHMEM + select PINCTRL help Compile a kernel suitable for booting most boards -- 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/5] arm/dts: Add pinctrl driver entries for omap2/3/4
Add pinctrl driver entries for omap2+. These all use
the generic pinctrl-single driver for the padconf
registers.
Note that as 2420 and 2430 have different padmux
registers, we now need to include omap2420.dtsi from
omap2420-h4.dts.
Cc: Linus Walleij
Cc: devicetree-disc...@lists.ozlabs.org
Signed-off-by: Tony Lindgren
---
arch/arm/boot/dts/omap2420-h4.dts |2 +-
arch/arm/boot/dts/omap2420.dtsi | 22 ++
arch/arm/boot/dts/omap2430.dtsi | 22 ++
arch/arm/boot/dts/omap3.dtsi | 18 ++
arch/arm/boot/dts/omap4.dtsi | 17 +
5 files changed, 80 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/omap2420.dtsi
create mode 100644 arch/arm/boot/dts/omap2430.dtsi
diff --git a/arch/arm/boot/dts/omap2420-h4.dts
b/arch/arm/boot/dts/omap2420-h4.dts
index 25b50b7..77b84e1 100644
--- a/arch/arm/boot/dts/omap2420-h4.dts
+++ b/arch/arm/boot/dts/omap2420-h4.dts
@@ -7,7 +7,7 @@
*/
/dts-v1/;
-/include/ "omap2.dtsi"
+/include/ "omap2420.dtsi"
/ {
model = "TI OMAP2420 H4 board";
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
new file mode 100644
index 000..8097d13
--- /dev/null
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -0,0 +1,22 @@
+/*
+ * 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.
+ */
+
+/include/ "omap2.dtsi"
+
+/ {
+ ocp {
+ omap2420_pmx: pinmux@4830 {
+ compatible = "ti,omap2420-padconf", "pinctrl-single";
+ reg = <0x4830 0x0113>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-single,register-width = <8>;
+ pinctrl-single,function-mask = <0x3f>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
new file mode 100644
index 000..d27b6f5
--- /dev/null
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -0,0 +1,22 @@
+/*
+ * 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.
+ */
+
+/include/ "omap2.dtsi"
+
+/ {
+ ocp {
+ omap2430_pmx: pinmux@49002030 {
+ compatible = "ti,omap2430-padconf", "pinctrl-single";
+ reg = <0x49002030 0x0154>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-single,register-width = <8>;
+ pinctrl-single,function-mask = <0x3f>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 9965ed6..c3334bf 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -68,6 +68,24 @@
reg = <0x4820 0x1000>;
};
+ omap3_pmx_core: pinmux@48002030 {
+ compatible = "ti,omap3-padconf", "pinctrl-single";
+ reg = <0x48002030 0x05cc>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-single,register-width = <16>;
+ pinctrl-single,function-mask = <0x7fff>;
+ };
+
+ omap3_pmx_wkup: pinmux@0x48002a58 {
+ compatible = "ti,omap3-padconf", "pinctrl-single";
+ reg = <0x48002a58 0x5c>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-single,register-width = <16>;
+ pinctrl-single,function-mask = <0x7fff>;
+ };
+
gpio1: gpio@4831 {
compatible = "ti,omap3-gpio";
ti,hwmods = "gpio1";
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 04cbbcb..4aaab12 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -104,6 +104,23 @@
<0x48240100 0x0100>;
};
+ omap4_pmx_core: pinmux@4a100040 {
+ compatible = "ti,omap4-padconf", "pinctrl-single";
+ reg = <0x4a100040 0x0196>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-single,register-width = <16>;
+ pinctrl-single,function-mask = <0x7fff>;
+ };
+ omap4_pmx_wkup: pinmux@4a31e040 {
+ compatible = "ti,omap4-padconf",
[PATCH 1/5] arm/dts: Add omap36xx.dtsi file and rename omap3-beagle to omap3-beagle-xm
The extra serial port is not available on 34xx. And the current
omap3-beagle.dts file is for omap3-beagle-xm.dts as it lists 512MB
of memory.
Please somebody submit a new omap3-beagle.dts for the original 34xx
BeagleBoard after testing it properly.
Cc: Benoit Cousson
Cc: devicetree-disc...@lists.ozlabs.org
Signed-off-by: Tony Lindgren
---
arch/arm/boot/dts/omap3-beagle-xm.dts |6 +++---
arch/arm/boot/dts/omap3.dtsi |7 ---
arch/arm/boot/dts/omap36xx.dtsi | 25 +
arch/arm/mach-omap2/Makefile.boot |2 +-
4 files changed, 29 insertions(+), 11 deletions(-)
rename arch/arm/boot/dts/{omap3-beagle.dts => omap3-beagle-xm.dts} (89%)
create mode 100644 arch/arm/boot/dts/omap36xx.dtsi
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
similarity index 89%
rename from arch/arm/boot/dts/omap3-beagle.dts
rename to arch/arm/boot/dts/omap3-beagle-xm.dts
index e60cba0..df6d485 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -7,11 +7,11 @@
*/
/dts-v1/;
-/include/ "omap3.dtsi"
+/include/ "omap36xx.dtsi"
/ {
- model = "TI OMAP3 BeagleBoard";
- compatible = "ti,omap3-beagle", "ti,omap3";
+ model = "TI OMAP3 BeagleBoard xM";
+ compatible = "ti,omap3-beagle-xm, ti,omap3-beagle", "ti,omap3";
memory {
device_type = "memory";
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 8109471..9965ed6 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -17,7 +17,6 @@
serial0 = &uart1;
serial1 = &uart2;
serial2 = &uart3;
- serial3 = &uart4;
};
cpus {
@@ -141,12 +140,6 @@
clock-frequency = <4800>;
};
- uart4: serial@49042000 {
- compatible = "ti,omap3-uart";
- ti,hwmods = "uart4";
- clock-frequency = <4800>;
- };
-
i2c1: i2c@4807 {
compatible = "ti,omap3-i2c";
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
new file mode 100644
index 000..96bf028
--- /dev/null
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -0,0 +1,25 @@
+/*
+ * Device Tree Source for OMAP3 SoC
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ "omap3.dtsi"
+
+/ {
+ aliases {
+ serial3 = &uart4;
+ };
+
+ ocp {
+ uart4: serial@49042000 {
+ compatible = "ti,omap3-uart";
+ ti,hwmods = "uart4";
+ clock-frequency = <4800>;
+ };
+ };
+};
diff --git a/arch/arm/mach-omap2/Makefile.boot
b/arch/arm/mach-omap2/Makefile.boot
index 6cf1c2d..0e602b7 100644
--- a/arch/arm/mach-omap2/Makefile.boot
+++ b/arch/arm/mach-omap2/Makefile.boot
@@ -3,7 +3,7 @@ params_phys-y := 0x8100
initrd_phys-y := 0x8080
dtb-$(CONFIG_SOC_OMAP2420) += omap2420-h4.dtb
-dtb-$(CONFIG_ARCH_OMAP3) += omap3-beagle.dtb omap3-evm.dtb
+dtb-$(CONFIG_ARCH_OMAP3) += 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
[PATCH 0/5] Enable pinctrl-single for omap2/3/4
Hi all,
Now that pinctrl-single driver is merged, this series enables
pinctrl for omap2/3/4.
Regards,
Tony
---
AnilKumar Ch (1):
ARM: OMAP2+: select PINCTRL in Kconfig
Tony Lindgren (4):
arm/dts: Add omap36xx.dtsi file and rename omap3-beagle to omap3-beagle-xm
arm/dts: Add pinctrl driver entries for omap2/3/4
arm/dts: Mux uart pins for omap4-sdp
omap-serial: Request pins using pinctrl framework
arch/arm/boot/dts/omap2420-h4.dts |2 +
arch/arm/boot/dts/omap2420.dtsi | 22 +
arch/arm/boot/dts/omap2430.dtsi | 22 +
arch/arm/boot/dts/omap3-beagle-xm.dts |6 ++--
arch/arm/boot/dts/omap3.dtsi | 25 +++
arch/arm/boot/dts/omap36xx.dtsi | 25 +++
arch/arm/boot/dts/omap4-sdp.dts | 42 +
arch/arm/boot/dts/omap4.dtsi | 17 ++
arch/arm/configs/omap2plus_defconfig |1 +
arch/arm/mach-omap2/Kconfig |1 +
arch/arm/mach-omap2/Makefile.boot |2 +
arch/arm/plat-omap/include/plat/omap-serial.h |1 +
drivers/tty/serial/omap-serial.c | 10 ++
13 files changed, 164 insertions(+), 12 deletions(-)
create mode 100644 arch/arm/boot/dts/omap2420.dtsi
create mode 100644 arch/arm/boot/dts/omap2430.dtsi
rename arch/arm/boot/dts/{omap3-beagle.dts => omap3-beagle-xm.dts} (89%)
create mode 100644 arch/arm/boot/dts/omap36xx.dtsi
--
Signature
--
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
Interaction between USB phy power and MADC driver
I'm seeing what I think is an unintended consequence of powering down the USB phy. All the relavent code is in file twl4030_usb.c. My system is setup to use the USB in otg mode. If nothing is connected to the USB OTG port, the phy suspension code is called. In the chain of calls that follows, the vusb3v1 regulator is disabled. However, according to the OMAP power management manual, vusb3v1 is used "to bias the analog multiplexers on the four MCPC pins between the carkit and the MADC". I've seen if there is no bias on this mux, the MADC driver returns incorrect counts on these 4 pins that should be in A/D mode. If I plug something into the USB OTG port, the MADC driver returns the expected counts. I also created a debug version of the twl4030-usb driver, with the disabling of the vusb3v1 commented out and the MADC returns the correct counts regardless of the state of the USB OTG port. Since the vusb3v1 regulator is required for the proper operation of the mux and by extension the MADC and carkit mode, shouldn't it always be enabled? frank -- 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] perf: Use pre-empt safe cpu_get/put insted of smp_processor_id
Hi Roger,
On Fri, Aug 10, 2012 at 4:05 PM, 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
>
> Signed-off-by: Roger Quadros
What his the status of the patch? Has it been reviewed and taken in an
integration tree? I cannot find anything about it in l-o and
linux-next.
I have some changes on-going in the OMAP PM code and I would like to
know if $SUBJECT is applicable.
Regards,
Jean
> ---
> 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();
> clk->ops->disable(clk);
> }
>
> @@ -339,7 +340,8 @@ int omap2_clk_enable(struct clk *clk)
> }
>
> if (clk->ops && clk->ops->enable) {
> - trace_clock_enable(clk->name, 1, smp_processor_id());
> + trace_clock_enable(clk->name, 1, get_cpu());
> + put_cpu();
> ret = clk->ops->enable(clk);
> if (ret) {
> WARN(1, "clock: %s: could not enable: %d\n",
> @@ -380,7 +382,8 @@ int omap2_clk_set_rate(struct clk *clk, unsigned long
> rate)
>
> /* dpll_ck, core_ck, virt_prcm_set; plus all clksel clocks */
> if (clk->set_rate) {
> - trace_clock_set_rate(clk->name, rate, smp_processor_id());
> + trace_clock_set_rate(clk->name, rate, get_cpu());
> + put_cpu();
> ret = clk->set_rate(clk, rate);
> }
>
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index e4fc88c..81fec2e 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -357,18 +357,22 @@ void omap_sram_idle(void)
>
> static void omap3_pm_idle(void)
> {
> + unsigned cpu;
> +
> local_fiq_disable();
>
> if (omap_irq_pending())
> goto out;
>
> - trace_power_start(POWER_CSTATE, 1, smp_processor_id());
> - trace_cpu_idle(1, smp_processor_id());
> + cpu = get_cpu();
> + trace_power_start(POWER_CSTATE, 1, cpu);
> + trace_cpu_idle(1, cpu);
>
> omap_sram_idle();
>
> - trace_power_end(smp_processor_id());
> - trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
> + trace_power_end(cpu);
> + trace_cpu_idle(PWR_EVENT_EXIT, cpu);
> + put_cpu();
>
> out:
> local_fiq_enable();
> diff --git a/arch/arm/mach-omap2/powerdomain.c
> b/arch/arm/mach-omap2/powerdomain.c
> index 69b36e1..138bf86 100644
> --- a/arch/arm/mach-omap2/powerdomain.c
> +++ b/arch/arm/mach-omap2/powerdomain.c
> @@ -169,7 +169,8 @@ static int _pwrdm_state_switch(struct powerdomain *pwrdm,
> int flag)
>((state & OMAP_POWERSTATE_MASK) << 8) |
>((prev & OMAP_POWERSTATE_MASK) << 0));
> trace_power_domain_target(pwrdm->name, trace_state,
> - smp_processor_id());
> + get_cpu());
> + put_cpu();
> }
> break;
> default:
> @@ -491,7 +492,8 @@ int pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8
> pwrst)
> if (arch_pwrdm && arch_pwrdm->pwrdm_set_next_pwrst) {
> /* Trace the pwrdm desired target state */
> trace_power_domain_target(pwrdm->name, pwrst,
> - smp_processor_id());
> + get_cpu());
> + put_cpu();
> /* Program the pwrdm desired target state */
> ret = arch_pwrdm->pwrdm_set_next_pwrst(pwrdm, pwrst);
> }
> --
> 1.7.4.1
>
--
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] musb: Kill __init from function that are called at other times as well.
Hi, On Thu, Sep 06, 2012 at 08:42:56PM +0300, Pantelis Antoniou wrote: > > On Sep 6, 2012, at 8:37 PM, Felipe Balbi wrote: > > > Hi, > > > > On Thu, Sep 06, 2012 at 08:36:39PM +0300, Pantelis Antoniou wrote: > >> Hi Felipe > >> > >> I see about __devinit. > >> There's no crash because in those logs the __init modifiers are gone. > > > > it'd be cool to see the crash, though ;-) > > > > -- > > balbi > > Heh, OK, > > My word is not enough? :) > > Gimme a few minutes... Didn't say that, but I don't know what issue you're talking about since __devinit is supposed to keep .devinit.text intact unless !HOTPLUG. This could be a bug on some linker script (though unlikely) just trying to get understand the issue before I apply the patch, that's all. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2] leds: leds-gpio: adopt pinctrl support
* Marek Vasut [120905 19:05]: > Hi Tony, > > > * Marek Vasut [120904 20:13]: > > > Dear Bryan Wu, > > > > > > > On Sat, Sep 1, 2012 at 4:16 PM, AnilKumar Ch wrote: > > > > > Adopt pinctrl support to leds-gpio driver based on leds-gpio > > > > > device pointer, pinctrl driver configure SoC pins to GPIO > > > > > mode according to definitions provided in .dts file. > > > > > > > > Thanks for this, actually Marek Vasut submitted a similar patch > > > > before. I'm pretty fine with this patch. > > > > > > Thanks for submitting this actually ... I didn't have time to properly > > > investigate this. > > > > > > > But without proper DT setting, it will also give us warning I think. > > > > or we can provide some dummy functions as a temp solution as Shawn > > > > pointed out before. > > > > > > But this driver is also used on hardware that's not yet coverted to DT, > > > so I'd say dev_warn() if CONFIG_OF is enabled and otherwise simply go on > > > ? Actually, can we not skip whole this pinctrl thing if CONFIG_OF is > > > disabled? Actually (2), what's the relationship between OF and pinctrl? > > > > The warning should be pinctrl related as the pinctrl drivers may not be > > device tree based drivers. > > Exactly my concern. Also the warning shouldnt be present on systems where > pinctrl is disabled. But pinctrl_get_select() returns 0 in include/linux/pinctrl/consumer.h if CONFIG_PINCTRL is not selected, so no warning is produced AFAIK ;) Or do you get some warning if CONFIG_PINCTRL is not selected for your hardware? 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] musb: Kill __init from function that are called at other times as well.
On Sep 6, 2012, at 8:37 PM, Felipe Balbi wrote: > Hi, > > On Thu, Sep 06, 2012 at 08:36:39PM +0300, Pantelis Antoniou wrote: >> Hi Felipe >> >> I see about __devinit. >> There's no crash because in those logs the __init modifiers are gone. > > it'd be cool to see the crash, though ;-) > > -- > balbi Heh, OK, My word is not enough? :) Gimme a few minutes... -- Pantelis -- 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] musb: Kill __init from function that are called at other times as well.
Hi, On Thu, Sep 06, 2012 at 08:36:39PM +0300, Pantelis Antoniou wrote: > Hi Felipe > > I see about __devinit. > There's no crash because in those logs the __init modifiers are gone. it'd be cool to see the crash, though ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCH] musb: Kill __init from function that are called at other times as well.
Hi Felipe I see about __devinit. There's no crash because in those logs the __init modifiers are gone. Regards -- Pantelis On Sep 6, 2012, at 8:07 PM, Felipe Balbi wrote: > Hi, > > On Thu, Sep 06, 2012 at 05:58:27PM +0300, Pantelis Antoniou wrote: >> Hi Felipe, >> >> A proper answer required some instrumentation printks(). >> >> So what I did is that I peppered each function marked with a removed >> __init or __devinit with a >> >>> printk(KERN_INFO "%s:%d (%s) %s\n", __FILE__, __LINE__, KBUILD_MODNAME, >>> __func__); >>> >> >> Both omap2430 & musb_hdrc are compiled as module, and I issued the following >> commands on a beagleboard xm. >> >> # modprobe omap2430 >> # modprobe g_mass_storage file=backing_file >> # rmmod g_mass_storage >> # rmmod omap2430 >> # modprobe omap2430 >> >> The problem is obvious when you see that functions marked as init or devinit >> are >> called when re-loading the omap2430 module again. Those functions if marked >> as >> much can (and will as I have witnessed) be removed from memory, leading to a >> crash. >> >> What do you think? > > the problem would be with usage of __init. __devinit will only drop > .devinit.text if HOTPLUG and MODULE isn't set, AFAICT. I also can't see > a crash on below logs. > > -- > 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: omap: hwmod: make *phy_48m* as the main_clk of ocp2scp
Hi,
On Mon, Jul 02, 2012 at 02:25:37PM +0530, Kishon Vijay Abraham I wrote:
> Made *ocp2scp_usb_phy_phy_48m* as the main_clk for ocp2scp.
> Since this ocp2scp module does not have any fck but does have a
> single opt_clock, it is added as the main_clk for ocp2scp. Also
> removed phy_48m as the optional clock since it is now made as the
> main clock.
Just one comment here, you failed to note what good does it do from the
driver perspective, other than that, you can add my Reviewed-by as below
> Cc: Benoît Cousson
> Signed-off-by: Kishon Vijay Abraham I
FWIW:
Reviewed-by: Felipe Balbi
> ---
> Changes from [RFC PATCH 1/5] arm: omap: hwmod: make *phy_48m* as the main_clk
> of ocp2scp:
> * Removed *ocp2scp_usb_phy_phy_48m* as the optional functional clock
>
> arch/arm/mach-omap2/omap_hwmod_44xx_data.c |7 +--
> 1 files changed, 1 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> index f30e861..17cf933 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -2504,14 +2504,11 @@ static struct omap_hwmod_class
> omap44xx_ocp2scp_hwmod_class = {
> };
>
> /* ocp2scp_usb_phy */
> -static struct omap_hwmod_opt_clk ocp2scp_usb_phy_opt_clks[] = {
> - { .role = "phy_48m", .clk = "ocp2scp_usb_phy_phy_48m" },
> -};
> -
> static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod = {
> .name = "ocp2scp_usb_phy",
> .class = &omap44xx_ocp2scp_hwmod_class,
> .clkdm_name = "l3_init_clkdm",
> + .main_clk = "ocp2scp_usb_phy_phy_48m",
> .prcm = {
> .omap4 = {
> .clkctrl_offs =
> OMAP4_CM_L3INIT_USBPHYOCP2SCP_CLKCTRL_OFFSET,
> @@ -2519,8 +2516,6 @@ static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod
> = {
> .modulemode = MODULEMODE_HWCTRL,
> },
> },
> - .opt_clks = ocp2scp_usb_phy_opt_clks,
> - .opt_clks_cnt = ARRAY_SIZE(ocp2scp_usb_phy_opt_clks),
> };
>
> /*
> --
> 1.7.5.4
>
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v4 00/21] OMAP UART Patches
On Thu, Sep 06, 2012 at 09:18:35AM -0700, Greg KH wrote: > On Thu, Sep 06, 2012 at 03:45:19PM +0300, Felipe Balbi wrote: > > Hi guys, > > > > here's v4 of the omap uart patchset. No changes other than a rebase on top > > of > > Greg's tty-next branch and Tony's Acked-by being added to a couple patches > > > > Note: I'm resending the series with Vikram's Software Flow Control fix > > anyway > > as it can just be ignored if it's decided it needs to go into this merge > > window. > > > > Changes since v3: > > . Rebased on top of Greg's tty-next branch > > . Added Tony's Acked-by > > Thanks for rebasing, all now applied. thank you, actually ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module
Hi,
On Thu, Sep 06, 2012 at 08:13:03PM +0300, Felipe Balbi wrote:
> Hi,
>
> On Thu, Sep 06, 2012 at 09:04:58PM +0530, Vaibhav Hiremath 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.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module
Hi,
On Thu, Sep 06, 2012 at 09:04:58PM +0530, Vaibhav Hiremath 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.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] musb: Kill __init from function that are called at other times as well.
Hi, On Thu, Sep 06, 2012 at 05:58:27PM +0300, Pantelis Antoniou wrote: > Hi Felipe, > > A proper answer required some instrumentation printks(). > > So what I did is that I peppered each function marked with a removed > __init or __devinit with a > > > printk(KERN_INFO "%s:%d (%s) %s\n", __FILE__, __LINE__, KBUILD_MODNAME, > > __func__); > > > > Both omap2430 & musb_hdrc are compiled as module, and I issued the following > commands on a beagleboard xm. > > # modprobe omap2430 > # modprobe g_mass_storage file=backing_file > # rmmod g_mass_storage > # rmmod omap2430 > # modprobe omap2430 > > The problem is obvious when you see that functions marked as init or devinit > are > called when re-loading the omap2430 module again. Those functions if marked as > much can (and will as I have witnessed) be removed from memory, leading to a > crash. > > What do you think? the problem would be with usage of __init. __devinit will only drop .devinit.text if HOTPLUG and MODULE isn't set, AFAICT. I also can't see a crash on below logs. -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 00/21] OMAP UART Patches
On Thu, Sep 06, 2012 at 03:45:19PM +0300, Felipe Balbi wrote: > Hi guys, > > here's v4 of the omap uart patchset. No changes other than a rebase on top of > Greg's tty-next branch and Tony's Acked-by being added to a couple patches > > Note: I'm resending the series with Vikram's Software Flow Control fix anyway > as it can just be ignored if it's decided it needs to go into this merge > window. > > Changes since v3: > . Rebased on top of Greg's tty-next branch > . Added Tony's Acked-by Thanks for rebasing, all now applied. greg k-h -- 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 v3 08/14] Input: twl4030-vibra: Support for DT booted kernel
Hi Peter,
On Thu, Sep 06, 2012 at 03:12:15PM +0300, Peter Ujfalusi wrote:
> Add support when the kernel has been booted with DT blob. In this case the
> pdata is NULL, we need to reach up to the core node and check if the codec
> part has been enabled to determine if we need to coexist with the codec or
> not.
>
> Signed-off-by: Peter Ujfalusi
> ---
> drivers/input/misc/twl4030-vibra.c | 20 ++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/misc/twl4030-vibra.c
> b/drivers/input/misc/twl4030-vibra.c
> index fc0ed9b..15620f8 100644
> --- a/drivers/input/misc/twl4030-vibra.c
> +++ b/drivers/input/misc/twl4030-vibra.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -194,13 +195,28 @@ static int twl4030_vibra_resume(struct device *dev)
> static SIMPLE_DEV_PM_OPS(twl4030_vibra_pm_ops,
>twl4030_vibra_suspend, twl4030_vibra_resume);
>
> +static bool twl4030_vibra_check_coexist(struct twl4030_vibra_data *pdata,
> + struct device_node *node)
> +{
> + if (pdata && pdata->coexist)
> + return true;
> +
> +#ifdef CONFIG_OF
> + if (of_find_node_by_name(node, "codec"))
> + return true;
> +#endif
In patch 6 you added a stub for of_find_node_by_name(), so do you really
need this #ifdef?
Otherwise it looks good.
Acked-by: Dmitry Torokhov
Thanks.
--
Dmitry
--
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 02/10] ARM: OMAP: Fix timer posted mode support
On 09/06/2012 09:20 AM, Jon Hunter wrote:
>
> On 09/06/2012 07:57 AM, Vaibhav Hiremath wrote:
>>
>>
>> On 9/6/2012 12:34 AM, Jon Hunter wrote:
>>> Currently the dmtimer posted mode is being enabled when the function
>>> __omap_dm_timer_reset() is called. This function is only being called for
>>> OMAP1 timers and OMAP2+ timers that are being used as system timers. Hence,
>>> for OMAP2+ timers that are NOT being used as a system timer, posted mode is
>>> not enabled but the "timer->posted" variable is still set (incorrectly) in
>>> the omap_dm_timer_prepare() function.
>>>
>>> This is a regression introduced by commit 3392cdd3 (ARM: OMAP: dmtimer:
>>> switch-over to platform device driver) which changed the code to only call
>>> omap_dm_timer_reset() for OMAP1 devices. Although this is a regression from
>>> the original code it only impacts performance and so is not needed for
>>> stable.
>>>
>>> Signed-off-by: Jon Hunter
>>> ---
>>> arch/arm/mach-omap2/timer.c |3 +--
>>> arch/arm/plat-omap/dmtimer.c | 14 +-
>>> arch/arm/plat-omap/include/plat/dmtimer.h |9 -
>>> 3 files changed, 14 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
>>> index 5471706..e24ee0f 100644
>>> --- a/arch/arm/mach-omap2/timer.c
>>> +++ b/arch/arm/mach-omap2/timer.c
>>> @@ -194,10 +194,9 @@ static int __init omap_dm_timer_init_one(struct
>>> omap_dm_timer *timer,
>>> }
>>> __omap_dm_timer_init_regs(timer);
>>> __omap_dm_timer_reset(timer, 1, 1);
>>> - timer->posted = 1;
>>> + __omap_dm_timer_enable_posted(timer);
>>>
>>> timer->rate = clk_get_rate(timer->fclk);
>>> -
>>> timer->reserved = 1;
>>>
>>> return res;
>>> diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
>>> index c34f55b..22790ea 100644
>>> --- a/arch/arm/plat-omap/dmtimer.c
>>> +++ b/arch/arm/plat-omap/dmtimer.c
>>> @@ -122,21 +122,15 @@ static void omap_dm_timer_wait_for_reset(struct
>>> omap_dm_timer *timer)
>>>
>>> static void omap_dm_timer_reset(struct omap_dm_timer *timer)
>>> {
>>> - omap_dm_timer_enable(timer);
>>> if (timer->pdev->id != 1) {
>>> omap_dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG, 0x06);
>>> omap_dm_timer_wait_for_reset(timer);
>>> }
>>> -
>>> __omap_dm_timer_reset(timer, 0, 0);
>>> - omap_dm_timer_disable(timer);
>>> - timer->posted = 1;
>>> }
>>>
>>> int omap_dm_timer_prepare(struct omap_dm_timer *timer)
>>> {
>>> - int ret;
>>> -
>>> /*
>>> * FIXME: OMAP1 devices do not use the clock framework for dmtimers so
>>> * do not call clk_get() for these devices.
>>> @@ -150,13 +144,15 @@ int omap_dm_timer_prepare(struct omap_dm_timer *timer)
>>> }
>>> }
>>>
>>> + omap_dm_timer_enable(timer);
>>> +
>>> if (timer->capability & OMAP_TIMER_NEEDS_RESET)
>>> omap_dm_timer_reset(timer);
>>>
>>> - ret = omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
>>> + __omap_dm_timer_enable_posted(timer);
>>> + omap_dm_timer_disable(timer);
>>>
>>> - timer->posted = 1;
>>> - return ret;
>>> + return omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
>>
>> May be I am speculating here and I know this is tested and supposed to
>> work, but Isn't it safe to set parent keeping module enables.
>
> So you would rather change the functional clock while the timer is
> enabled/active? So although that we are doing this today, that does not
> sound like a good idea to me :-)
Actually, we are not doing this today. If you look at the current code
we are only enabling the timer while doing the soft-reset for omap1
devices. Hence, even in the current code we set the parent while the
timer is not enabled. So there is no actual change here in the sequence.
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 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module
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.
Thanks,
Vaibhav
> { }
> };
>
>
--
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 01/10] ARM: OMAP3+: Implement timer workaround for errata i103 and i767
On 09/06/2012 09:42 AM, Jon Hunter wrote:
>
> On 09/06/2012 09:06 AM, Jon Hunter wrote:
>>
>> On 09/06/2012 12:07 AM, Vaibhav Hiremath wrote:
>>>
>>>
>>> On 9/6/2012 12:34 AM, Jon Hunter wrote:
Errata Titles:
i103: Delay needed to read some GP timer, WD timer and sync timer registers
after wakeup (OMAP3/4)
i767: Delay needed to read some GP timer registers after wakeup (OMAP5)
Description (i103/i767):
If a General Purpose Timer (GPTimer) is in posted mode (TSICR
[2].POSTED=1),
due to internal resynchronizations, values read in TCRR, TCAR1 and TCAR2
registers right after the timer interface clock (L4) goes from stopped to
active may not return the expected values. The most common event leading to
this situation occurs upon wake up from idle.
GPTimer non-posted synchronization mode is not impacted by this limitation.
Workarounds:
1). Disable posted mode
2). Use static dependency between timer clock domain and MPUSS clock domain
3). Use no-idle mode when the timer is active
Workarounds #2 and #3 are not pratical from a power standpoint and so
workaround #1 has been implemented. Disabling posted mode adds some CPU
overhead
for configuring the timers as the CPU has to wait for the write to
complete.
However, disabling posted mode guarantees correct operation.
Please note that it is safe to use posted mode for timers if the counter
(TCRR)
and capture (TCARx) registers will never be read. An example of this is the
clock-event system timer. This is used by the kernel to schedule events
however,
the timers counter is never read and capture registers are not used. Given
that
the kernel configures this timer often yet never reads the counter
register it
is safe to enable posted mode in this case. Hence, for the timer used for
kernel
clock-events, posted mode is enabled by overriding the errata for devices
that
are impacted by this defect.
Although both dmtimers and watchdogs are impacted by this defect this
patch only
implements the workaround for the dmtimer. Currently the watchdog driver
does
not read the counter register and so no workaround is necessary.
Confirmed with Vaibhav Hiremath that this bug also impacts AM33xx devices.
>>>
>>> Thanks for pinging me on this and getting it confirmed.
>>>
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/timer.c |9 +++
arch/arm/plat-omap/dmtimer.c |2 ++
arch/arm/plat-omap/include/plat/dmtimer.h | 39
+
3 files changed, 50 insertions(+)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 2ff6d41..5471706 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -208,6 +208,13 @@ static void __init omap2_gp_clockevent_init(int
gptimer_id,
{
int res;
+ /*
+ * For clock-event timers we never read the timer counter and
+ * so we are not impacted by errata i103 and i767. Therefore,
+ * we can safely ignore this errata for clock-event timers.
+ */
+ __omap_dm_timer_populate_errata(&clkev, OMAP_TIMER_ERRATA_I103_I767);
+
>>>
>>> Couple of points,
>>>
>>> 1. It is confusing to me, as you are passing the errata flag so i expect
>>> api should set it. Why can't we do reverse way, you pass 0 here, since
>>> you don't want to set and pass this flag every other places where you
>>> want to enable this errata.
>>
>> Per the design of the __omap_dm_timer_populate_errata function, the 2nd
>> argument is called override to allow us to override an errata. I am not
>> a huge fan of this, but I wanted to be explicit in the code that we are
>> intentionally allowing posted mode for the clock-events timer.
>>
>> I did not wish to pass the flags we want to set because if there more
>> flags added in the future then we will have to keep changing the calls
>> to the populate_errata function to add these.
>
> By the way, your proposal could work nicely if we could pass errata
> flags from HWMOD. However, I am not sure if Paul or Benoit would go for
> this as they want HWMOD data to be auto-generated as much as possible
> and so I am not sure how that would work for errata which are not
> expected by design ;-)
Another alternative would be to drop the override argument altogether
and just do something like the following for the clock-events timer ...
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 43da595..f59e797 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -206,12 +206,14 @@ static void __init omap2_gp_clockevent_init(int
gptimer_id,
{
int res;
+ __omap_dm_timer_populate_errata(&clkev);
+
/*
Re: [PATCH 0/2] OMAP: hwmod: fix hardreset handling
Hi Omar, On 09/03/2012 04:29 PM, Omar Ramirez Luna wrote: > On 22 August 2012 00:42, Omar Ramirez Luna wrote: >> From: Omar Ramirez Luna >> >> The patch to expose hwmod assert/deassert functions through omap_device >> has been accepted and queued for 3.7[1], however these two patches are >> needed to make the API functional. Hence a revised version is being sent >> according to previous comments: >> >> - ARM: OMAP: hwmod: revise deassert sequence >> Now it uses enable|disable_module to handle the configuration of the >> modulemode inside CLKCTRL. As part of the cleanup of leaf clocks, the >> one associated with ipu_mmu will be removed along with the iommu hwmod >> migration[2]. >> >> - ARM: OMAP: hwmod: partially un-reset hwmods might not be properly >> enabled >> More infomation added in the patch description[3]. >> >> [1] http://patchwork.kernel.org/patch/1266731/ >> [2] http://patchwork.kernel.org/patch/1201791/ >> [3] http://patchwork.kernel.org/patch/1201801/ >> >> Omar Ramirez Luna (2): >> ARM: OMAP: hwmod: partially un-reset hwmods might not be properly >> enabled >> ARM: OMAP: hwmod: revise deassert sequence >> >> arch/arm/mach-omap2/omap_hwmod.c | 74 >> ++ >> 1 file changed, 59 insertions(+), 15 deletions(-) > > Ping. Oops, sorry, I forgot your series. Beside the concern about the duplication of code, that looks good to me. I'll sync with Paul to see who will push that series. 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 2/2] ARM: OMAP: hwmod: revise deassert sequence
Hi Omar,
On 08/22/2012 07:42 AM, Omar Ramirez Luna wrote:
> For a reset sequence to complete cleanly, a module needs its
> associated clocks to be enabled, otherwise the timeout check
> in prcm code can print a false failure (failed to hardreset)
> that occurs because the clocks aren't powered ON and the status
> bit checked can't transition without them.
>
> Signed-off-by: Omar Ramirez Luna
> ---
> arch/arm/mach-omap2/omap_hwmod.c | 37 +
> 1 file changed, 37 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
> b/arch/arm/mach-omap2/omap_hwmod.c
> index eaedc33..b65e021 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -1509,6 +1509,7 @@ static int _deassert_hardreset(struct omap_hwmod *oh,
> const char *name)
> {
> struct omap_hwmod_rst_info ohri;
> int ret = -EINVAL;
> + int hwsup = 0;
>
> if (!oh)
> return -EINVAL;
> @@ -1520,10 +1521,46 @@ static int _deassert_hardreset(struct omap_hwmod *oh,
> const char *name)
> if (IS_ERR_VALUE(ret))
> return ret;
>
> + if (oh->clkdm) {
> + /*
> + * A clockdomain must be in SW_SUP otherwise reset
> + * might not be completed. The clockdomain can be set
> + * in HW_AUTO only when the module become ready.
> + */
> + hwsup = clkdm_in_hwsup(oh->clkdm);
> + ret = clkdm_hwmod_enable(oh->clkdm, oh);
> + if (ret) {>
> + WARN(1, "omap_hwmod: %s: could not enable clockdomain
> %s: %d\n",
> + oh->name, oh->clkdm->name, ret);
> + return ret;
> + }
> + }
> +
> + _enable_clocks(oh);
> + if (soc_ops.enable_module)
> + soc_ops.enable_module(oh);
> +
> ret = soc_ops.deassert_hardreset(oh, &ohri);
> +
> + if (soc_ops.disable_module)
> + soc_ops.disable_module(oh);
> + _disable_clocks(oh);
> +
> if (ret == -EBUSY)
> pr_warning("omap_hwmod: %s: failed to hardreset\n", oh->name);
>
> + if (!ret) {
> + /*
> + * Set the clockdomain to HW_AUTO, assuming that the
> + * previous state was HW_AUTO.
> + */
> + if (oh->clkdm && hwsup)
> + clkdm_allow_idle(oh->clkdm);
> + } else {
> + if (oh->clkdm)
> + clkdm_hwmod_disable(oh->clkdm, oh);
> + }
> +
> return ret;
> }
>
The sequence is good, I'm just a little bit concern about the
duplication of code compared to _enable sequence.
That being said, this is the consequence of removing the hardreset
sequence outside of the main _enable/_shutdown sequence.
So I'm not sure I have any better way of doing that :-(
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: [RFC PATCH 2/5] arm: omap: remove ocp2scp_usb_phy_ick clock node
Hi, On Wed, May 30, 2012 at 4:26 PM, Kishon Vijay Abraham I wrote: > "ocp2scp_usb_phy_ick" clock node was a fake clock node created > to control MODULEMODE of ocp2scp. Since the hwmod for ocp2scp is now added > (which can be used to control MODULEMODE) this clock node is removed. > > Cc: Benoit Cousson > Signed-off-by: Kishon Vijay Abraham I If there isn't any comments for this patch, can someone queue it up? 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: omap: hwmod: make *phy_48m* as the main_clk of ocp2scp
Hi, On Mon, Jul 2, 2012 at 2:25 PM, Kishon Vijay Abraham I wrote: > Made *ocp2scp_usb_phy_phy_48m* as the main_clk for ocp2scp. > Since this ocp2scp module does not have any fck but does have a > single opt_clock, it is added as the main_clk for ocp2scp. Also > removed phy_48m as the optional clock since it is now made as the > main clock. > > Cc: Benoît Cousson > Signed-off-by: Kishon Vijay Abraham I If there is not any comments for this patch, can someone queue it. This is needed for musb to be functional with dt in omap4. 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 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..544fa97
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -0,0 +1,33 @@
+OMAP GLUE
+
+OMAP MUSB GLUE
+ - compatible : Should be "ti,musb-omap2430"
+ - 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,musb-omap2430";
+ 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 platform_driver
[PATCH 5/5] arm: omap: phy: remove unused functions from omap-phy-internal.c
All the unnessary functions in omap-phy-internal is removed.
These functionality are now handled by omap-usb2 phy driver.
Cc: Felipe Balbi
Signed-off-by: Kishon Vijay Abraham I
Acked-by: Tony Lindgren
---
arch/arm/mach-omap2/omap_phy_internal.c | 138 ---
arch/arm/mach-omap2/twl-common.c|5 --
arch/arm/mach-omap2/usb-musb.c |3 -
3 files changed, 146 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index d52651a..874aecc 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -31,144 +31,6 @@
#include
#include "control.h"
-/* OMAP control module register for UTMI PHY */
-#define CONTROL_DEV_CONF 0x300
-#define PHY_PD 0x1
-
-#define USBOTGHS_CONTROL 0x33c
-#defineAVALID BIT(0)
-#defineBVALID BIT(1)
-#defineVBUSVALID BIT(2)
-#defineSESSEND BIT(3)
-#defineIDDIG BIT(4)
-
-static struct clk *phyclk, *clk48m, *clk32k;
-static void __iomem *ctrl_base;
-static int usbotghs_control;
-
-int omap4430_phy_init(struct device *dev)
-{
- ctrl_base = ioremap(OMAP443X_SCM_BASE, SZ_1K);
- if (!ctrl_base) {
- pr_err("control module ioremap failed\n");
- return -ENOMEM;
- }
- /* Power down the phy */
- __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
-
- if (!dev) {
- iounmap(ctrl_base);
- return 0;
- }
-
- phyclk = clk_get(dev, "ocp2scp_usb_phy_ick");
- if (IS_ERR(phyclk)) {
- dev_err(dev, "cannot clk_get ocp2scp_usb_phy_ick\n");
- iounmap(ctrl_base);
- return PTR_ERR(phyclk);
- }
-
- clk48m = clk_get(dev, "ocp2scp_usb_phy_phy_48m");
- if (IS_ERR(clk48m)) {
- dev_err(dev, "cannot clk_get ocp2scp_usb_phy_phy_48m\n");
- clk_put(phyclk);
- iounmap(ctrl_base);
- return PTR_ERR(clk48m);
- }
-
- clk32k = clk_get(dev, "usb_phy_cm_clk32k");
- if (IS_ERR(clk32k)) {
- dev_err(dev, "cannot clk_get usb_phy_cm_clk32k\n");
- clk_put(phyclk);
- clk_put(clk48m);
- iounmap(ctrl_base);
- return PTR_ERR(clk32k);
- }
- return 0;
-}
-
-int omap4430_phy_set_clk(struct device *dev, int on)
-{
- static int state;
-
- if (on && !state) {
- /* Enable the phy clocks */
- clk_enable(phyclk);
- clk_enable(clk48m);
- clk_enable(clk32k);
- state = 1;
- } else if (state) {
- /* Disable the phy clocks */
- clk_disable(phyclk);
- clk_disable(clk48m);
- clk_disable(clk32k);
- state = 0;
- }
- return 0;
-}
-
-int omap4430_phy_power(struct device *dev, int ID, int on)
-{
- if (on) {
- if (ID)
- /* enable VBUS valid, IDDIG groung */
- __raw_writel(AVALID | VBUSVALID, ctrl_base +
- USBOTGHS_CONTROL);
- else
- /*
-* Enable VBUS Valid, AValid and IDDIG
-* high impedance
-*/
- __raw_writel(IDDIG | AVALID | VBUSVALID,
- ctrl_base + USBOTGHS_CONTROL);
- } else {
- /* Enable session END and IDIG to high impedance. */
- __raw_writel(SESSEND | IDDIG, ctrl_base +
- USBOTGHS_CONTROL);
- }
- return 0;
-}
-
-int omap4430_phy_suspend(struct device *dev, int suspend)
-{
- if (suspend) {
- /* Disable the clocks */
- omap4430_phy_set_clk(dev, 0);
- /* Power down the phy */
- __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
-
- /* save the context */
- usbotghs_control = __raw_readl(ctrl_base + USBOTGHS_CONTROL);
- } else {
- /* Enable the internel phy clcoks */
- omap4430_phy_set_clk(dev, 1);
- /* power on the phy */
- if (__raw_readl(ctrl_base + CONTROL_DEV_CONF) & PHY_PD) {
- __raw_writel(~PHY_PD, ctrl_base + CONTROL_DEV_CONF);
- mdelay(200);
- }
-
- /* restore the context */
- __raw_writel(usbotghs_control, ctrl_base + USBOTGHS_CONTROL);
- }
-
- return 0;
-}
-
-int omap4430_phy_exit(struct device *dev)
-{
- if (ctrl_base)
- iounmap(ctrl_base);
- if (phyclk)
-
[PATCH 3/5] drivers: usb: twl6030: Add dt support for twl6030 usb
Add device tree support for twl6030 usb driver.
Update the Documentation with device tree binding information.
Signed-off-by: Kishon Vijay Abraham I
---
.../devicetree/bindings/usb/twl-usb.txt| 21 +++
drivers/usb/otg/twl6030-usb.c | 39 +---
2 files changed, 47 insertions(+), 13 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/twl-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/twl-usb.txt
b/Documentation/devicetree/bindings/usb/twl-usb.txt
new file mode 100644
index 000..930f9ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/twl-usb.txt
@@ -0,0 +1,21 @@
+USB COMPARATOR OF TWL CHIPS
+
+TWL6030 USB COMPARATOR
+ - compatible : Should be "ti,twl6030-usb"
+ - interrupts : Two interrupt numbers to the cpu should be specified. First
+ interrupt number is the otg interrupt number that raises ID interrupts when
+ the controller has to act as host and the second interrupt number is the
+ usb interrupt number that raises VBUS interrupts when the controller has to
+ act as device
+ - usb-supply : phandle to the regulator device tree node. It should be vusb
+ if it is twl6030 or ldousb if it is twl6025 subclass.
+
+twl6030-usb {
+ compatible = "ti,twl6030-usb";
+ interrupts = < 4 10 >;
+};
+
+Board specific device node entry
+&twl6030-usb {
+ usb-supply = <&vusb>;
+};
diff --git a/drivers/usb/otg/twl6030-usb.c b/drivers/usb/otg/twl6030-usb.c
index 32525bb..fcadef7 100644
--- a/drivers/usb/otg/twl6030-usb.c
+++ b/drivers/usb/otg/twl6030-usb.c
@@ -105,7 +105,7 @@ struct twl6030_usb {
u8 asleep;
boolirq_enabled;
boolvbus_enable;
- unsigned long features;
+ const char *regulator;
};
#definecomparator_to_twl(x) container_of((x), struct twl6030_usb,
comparator)
@@ -153,13 +153,6 @@ static int twl6030_start_srp(struct phy_companion
*comparator)
static int twl6030_usb_ldo_init(struct twl6030_usb *twl)
{
- char *regulator_name;
-
- if (twl->features & TWL6025_SUBCLASS)
- regulator_name = "ldousb";
- else
- regulator_name = "vusb";
-
/* Set to OTG_REV 1.3 and turn on the ID_WAKEUP_COMP */
twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x1, TWL6030_BACKUP_REG);
@@ -169,7 +162,7 @@ static int twl6030_usb_ldo_init(struct twl6030_usb *twl)
/* Program MISC2 register and set bit VUSB_IN_VBAT */
twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x10, TWL6030_MISC2);
- twl->usb3v3 = regulator_get(twl->dev, regulator_name);
+ twl->usb3v3 = regulator_get(twl->dev, twl->regulator);
if (IS_ERR(twl->usb3v3))
return -ENODEV;
@@ -322,9 +315,9 @@ static int __devinit twl6030_usb_probe(struct
platform_device *pdev)
u32 ret;
struct twl6030_usb *twl;
int status, err;
- struct twl4030_usb_data *pdata;
- struct device *dev = &pdev->dev;
- pdata = dev->platform_data;
+ struct device_node *np = pdev->dev.of_node;
+ struct device *dev = &pdev->dev;
+ struct twl4030_usb_data *pdata = dev->platform_data;
twl = devm_kzalloc(dev, sizeof *twl, GFP_KERNEL);
if (!twl)
@@ -333,7 +326,6 @@ static int __devinit twl6030_usb_probe(struct
platform_device *pdev)
twl->dev= &pdev->dev;
twl->irq1 = platform_get_irq(pdev, 0);
twl->irq2 = platform_get_irq(pdev, 1);
- twl->features = pdata->features;
twl->linkstat = OMAP_MUSB_UNKNOWN;
twl->comparator.set_vbus= twl6030_set_vbus;
@@ -345,6 +337,18 @@ static int __devinit twl6030_usb_probe(struct
platform_device *pdev)
return -EPROBE_DEFER;
}
+ if (np) {
+ twl->regulator = "usb";
+ } else if (pdata) {
+ if (pdata->features & TWL6025_SUBCLASS)
+ twl->regulator = "ldousb";
+ else
+ twl->regulator = "vusb";
+ } else {
+ dev_err(&pdev->dev, "twl6030 initialized without pdata\n");
+ return -EINVAL;
+ }
+
/* init spinlock for workqueue */
spin_lock_init(&twl->lock);
@@ -406,12 +410,21 @@ static int __exit twl6030_usb_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id twl6030_usb_id_table[] = {
+ { .compatible = "ti,twl6030-usb" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, twl6030_usb_id_table);
+#endif
+
static struct platform_driver twl6030_usb_driver = {
.probe = twl6030_usb_probe,
.remove = __exit_p(twl6030_usb_remove),
.driver = {
.name = "twl6030_usb",
.owner = THIS_M
[PATCH 0/5] usb: phy/otg: add dt support
This patch series adds device tree support for phy's (twl4030 and twl6030). A new omap-usb2 phy driver has been added (with only dt suppport) to perform phy configurations. Previously this configuration was performed by twl6030, using pdata function pointers. With the addition of omap-usb2 to perform phy configurations, twl6030 is made as a comparator driver to detect VBUS and ID events and notify it to the glue layer. Previously these patches were part of [PATCH v7 0/7] omap: musb: Add device tree support This patch series was developed on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv Kishon Vijay Abraham I (5): drivers: usb: phy: add a new driver for omap usb2 phy drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2 drivers: usb: twl6030: Add dt support for twl6030 usb drivers: usb: twl4030: Add device tree support for twl4030 usb arm: omap: phy: remove unused functions from omap-phy-internal.c .../devicetree/bindings/usb/twl-usb.txt| 40 +++ Documentation/devicetree/bindings/usb/usb-phy.txt | 17 ++ arch/arm/mach-omap2/omap_phy_internal.c| 138 -- arch/arm/mach-omap2/twl-common.c |5 - arch/arm/mach-omap2/usb-musb.c |3 - drivers/usb/otg/Kconfig|2 +- drivers/usb/otg/twl4030-usb.c | 26 +- drivers/usb/otg/twl6030-usb.c | 157 drivers/usb/phy/Kconfig|9 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/omap-usb2.c| 271 include/linux/usb/omap_usb.h | 46 include/linux/usb/phy_companion.h | 34 +++ 13 files changed, 483 insertions(+), 266 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/twl-usb.txt create mode 100644 Documentation/devicetree/bindings/usb/usb-phy.txt create mode 100644 drivers/usb/phy/omap-usb2.c create mode 100644 include/linux/usb/omap_usb.h create mode 100644 include/linux/usb/phy_companion.h -- 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 4/5] drivers: usb: twl4030: Add device tree support for twl4030 usb
Add device tree support for twl4030 usb driver.
Update the Documentation with device tree binding information.
Signed-off-by: Kishon Vijay Abraham I
---
.../devicetree/bindings/usb/twl-usb.txt| 19 ++
drivers/usb/otg/twl4030-usb.c | 26 +++-
2 files changed, 39 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/twl-usb.txt
b/Documentation/devicetree/bindings/usb/twl-usb.txt
index 930f9ff..36b9aed 100644
--- a/Documentation/devicetree/bindings/usb/twl-usb.txt
+++ b/Documentation/devicetree/bindings/usb/twl-usb.txt
@@ -19,3 +19,22 @@ Board specific device node entry
&twl6030-usb {
usb-supply = <&vusb>;
};
+
+TWL4030 USB PHY AND COMPARATOR
+ - compatible : Should be "ti,twl4030-usb"
+ - interrupts : The interrupt numbers to the cpu should be specified. First
+ interrupt number is the otg interrupt number that raises ID interrupts
+ and VBUS interrupts. The second interrupt number is optional.
+ - -supply : phandle to the regulator device tree node.
+should be vusb1v5, vusb1v8 and vusb3v1
+ - usb_mode : The mode used by the phy to connect to the controller. "1"
+ specifies "ULPI" mode and "2" specifies "CEA2011_3PIN" mode.
+
+twl4030-usb {
+ compatible = "ti,twl4030-usb";
+ interrupts = < 10 4 >;
+ usb1v5-supply = <&vusb1v5>;
+ usb1v8-supply = <&vusb1v8>;
+ usb3v1-supply = <&vusb3v1>;
+ usb_mode = <1>;
+};
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 523cad5..f0d2e75 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -585,23 +585,28 @@ static int __devinit twl4030_usb_probe(struct
platform_device *pdev)
struct twl4030_usb *twl;
int status, err;
struct usb_otg *otg;
-
- if (!pdata) {
- dev_dbg(&pdev->dev, "platform_data not available\n");
- return -EINVAL;
- }
+ struct device_node *np = pdev->dev.of_node;
twl = devm_kzalloc(&pdev->dev, sizeof *twl, GFP_KERNEL);
if (!twl)
return -ENOMEM;
+ if (np)
+ of_property_read_u32(np, "usb_mode",
+ (enum twl4030_usb_mode *)&twl->usb_mode);
+ else if (pdata)
+ twl->usb_mode = pdata->usb_mode;
+ else {
+ dev_err(&pdev->dev, "twl4030 initialized without pdata\n");
+ return -EINVAL;
+ }
+
otg = devm_kzalloc(&pdev->dev, sizeof *otg, GFP_KERNEL);
if (!otg)
return -ENOMEM;
twl->dev= &pdev->dev;
twl->irq= platform_get_irq(pdev, 0);
- twl->usb_mode = pdata->usb_mode;
twl->vbus_supplied = false;
twl->asleep = 1;
twl->linkstat = OMAP_MUSB_UNKNOWN;
@@ -690,12 +695,21 @@ static int __exit twl4030_usb_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id twl4030_usb_id_table[] = {
+ { .compatible = "ti,twl4030-usb" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, twl4030_usb_id_table);
+#endif
+
static struct platform_driver twl4030_usb_driver = {
.probe = twl4030_usb_probe,
.remove = __exit_p(twl4030_usb_remove),
.driver = {
.name = "twl4030_usb",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(twl4030_usb_id_table),
},
};
--
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/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 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. 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 |5 + drivers/usb/musb/omap2430.c| 106 ++-- drivers/usb/musb/omap2430.h|9 ++ 4 files changed, 146 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 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.
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
+ },
{ }
};
--
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/5] drivers: usb: phy: add a new driver for omap usb2 phy
All phy related programming like enabling/disabling the clocks, powering
on/off the phy is taken care of by this driver. It is also used for OTG
related functionality like srp.
This also includes device tree support for usb2 phy driver and
the documentation with device tree binding information is updated.
Currently writing to control module register is taken care in this
driver which will be removed once the control module driver is in place.
Cc: Felipe Balbi
Signed-off-by: Kishon Vijay Abraham I
---
Documentation/devicetree/bindings/usb/usb-phy.txt | 17 ++
drivers/usb/phy/Kconfig |9 +
drivers/usb/phy/Makefile |1 +
drivers/usb/phy/omap-usb2.c | 271 +
include/linux/usb/omap_usb.h | 46
include/linux/usb/phy_companion.h | 34 +++
6 files changed, 378 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/usb-phy.txt
create mode 100644 drivers/usb/phy/omap-usb2.c
create mode 100644 include/linux/usb/omap_usb.h
create mode 100644 include/linux/usb/phy_companion.h
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
b/Documentation/devicetree/bindings/usb/usb-phy.txt
new file mode 100644
index 000..80d4148
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -0,0 +1,17 @@
+USB PHY
+
+OMAP USB2 PHY
+
+Required properties:
+ - compatible: Should be "ti,omap-usb2"
+ - reg : Address and length of the register set for the device. Also
+add the address of control module dev conf register until a driver for
+control module is added
+
+This is usually a subnode of ocp2scp to which it is connected.
+
+usb2phy@4a0ad080 {
+ compatible = "ti,omap-usb2";
+ reg = <0x4a0ad080 0x58>,
+ <0x4a002300 0x4>;
+};
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 2838adb..63c339b 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -4,6 +4,15 @@
comment "USB Physical Layer drivers"
depends on USB || USB_GADGET
+config OMAP_USB2
+ tristate "OMAP USB2 PHY Driver"
+ select USB_OTG_UTILS
+ help
+ Enable this to support the transceiver that is part of SOC. This
+ driver takes care of all the PHY functionality apart from comparator.
+ The USB OTG controller communicates with the comparator using this
+ driver.
+
config USB_ISP1301
tristate "NXP ISP1301 USB transceiver support"
depends on USB || USB_GADGET
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index bb948fb..b069f29 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -4,6 +4,7 @@
ccflags-$(CONFIG_USB_DEBUG) := -DDEBUG
+obj-$(CONFIG_OMAP_USB2)+= omap-usb2.o
obj-$(CONFIG_USB_ISP1301) += isp1301.o
obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o
obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o
diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
new file mode 100644
index 000..15ab3d6
--- /dev/null
+++ b/drivers/usb/phy/omap-usb2.c
@@ -0,0 +1,271 @@
+/*
+ * omap-usb2.c - USB PHY, talking to musb controller in OMAP.
+ *
+ * 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 as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * omap_usb2_set_comparator - links the comparator present in the sytem with
+ * this phy
+ * @comparator - the companion phy(comparator) for this phy
+ *
+ * The phy companion driver should call this API passing the phy_companion
+ * filled with set_vbus and start_srp to be used by usb phy.
+ *
+ * For use by phy companion driver
+ */
+int omap_usb2_set_comparator(struct phy_companion *comparator)
+{
+ struct omap_usb *phy;
+ struct usb_phy *x = usb_get_phy(USB_PHY_TYPE_USB2);
+
+ if (IS_ERR(x))
+ return -ENODEV;
+
+ phy = phy_to_omapusb(x);
+ phy->comparator = comparator;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(omap_usb2_set_comparator);
+
+/**
+ * omap_usb_phy_power - power on/off the phy using control module reg
+ * @phy: struct omap_usb *
+ * @on: 0 or 1, based on powering on or off the PHY
+ *
+ * XXX: Remove this function once control module driver gets merged
+ */
+static void omap_usb_phy_power(struct omap_
Re: [PATCH] musb: Kill __init from function that are called at other times as well.
Hi Felipe,
A proper answer required some instrumentation printks().
So what I did is that I peppered each function marked with a removed
__init or __devinit with a
> printk(KERN_INFO "%s:%d (%s) %s\n", __FILE__, __LINE__, KBUILD_MODNAME,
> __func__);
>
Both omap2430 & musb_hdrc are compiled as module, and I issued the following
commands on a beagleboard xm.
# modprobe omap2430
# modprobe g_mass_storage file=backing_file
# rmmod g_mass_storage
# rmmod omap2430
# modprobe omap2430
The problem is obvious when you see that functions marked as init or devinit are
called when re-loading the omap2430 module again. Those functions if marked as
much can (and will as I have witnessed) be removed from memory, leading to a
crash.
What do you think?
Regards
-- Pantelis
On Sep 6, 2012, at 4:04 PM, Felipe Balbi wrote:
> On Thu, Sep 06, 2012 at 05:01:46PM +0300, Pantelis Antoniou wrote:
>> Marking functions as __init or __devinit and calling them at other times
>> leads to predictable crashes (if you're lucky).
>>
>> Remove them for now.
>>
>> Signed-off-by: Pantelis Antoniou
>> ---
>> drivers/usb/musb/musb_core.c| 16
>> drivers/usb/musb/musb_debugfs.c | 2 +-
>> drivers/usb/musb/musb_dma.h | 2 +-
>> drivers/usb/musb/musb_gadget.c | 6 +++---
>> drivers/usb/musb/musbhsdma.c| 2 +-
>> drivers/usb/musb/omap2430.c | 2 +-
>> 6 files changed, 15 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
>> index 26f1bef..215d2d5 100644
>> --- a/drivers/usb/musb/musb_core.c
>> +++ b/drivers/usb/musb/musb_core.c
>> @@ -1160,7 +1160,7 @@ static struct musb_fifo_cfg __devinitdata mode_5_cfg[]
>> = {
>> *
>> * returns negative errno or offset for next fifo.
>> */
>> -static int __devinit
>> +static int
>> fifo_setup(struct musb *musb, struct musb_hw_ep *hw_ep,
>> const struct musb_fifo_cfg *cfg, u16 offset)
>
> Are you sure all these functions are called from outside .init.text ? At
> least fifo_setup(), ep_config_from_table() and musb_core_init() are only
> during probe(), which sits in .init.text too.
>
> --
> balbi
Log...
> root@beagleboard:~# modprobe omap2430
> [ 114.643920] drivers/usb/musb/omap2430.c:584 (omap2430) omap2430_init
> [ 114.650939] drivers/usb/musb/omap2430.c:445 (omap2430) omap2430_probe
> [ 114.792205] drivers/usb/musb/musb_core.c:2409 (musb_hdrc) musb_init
> [ 114.798889] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
> [ 114.805358] drivers/usb/musb/musb_core.c:2118 (musb_hdrc) musb_probe
> [ 114.812225] drivers/usb/musb/musb_core.c:1888 (musb_hdrc)
> musb_init_controller
> [ 114.819824] drivers/usb/musb/musb_core.c:1813 (musb_hdrc) allocate_instance
> [ 114.835723] twl4030_usb twl4030_usb: twl4030_phy_resume
> [ 114.841339] drivers/usb/musb/musbhsdma.c:391 (musb_hdrc)
> dma_controller_create
> [ 114.848999] drivers/usb/musb/musb_core.c:1388 (musb_hdrc) musb_core_init
> [ 114.856079] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine,
> bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
> [ 114.867095] musb-hdrc: MHDRC RTL version 1.800
> [ 114.871887] drivers/usb/musb/musb_core.c:1246 (musb_hdrc)
> ep_config_from_table
> [ 114.879486] musb-hdrc: setup fifo_mode 4
> [ 114.883666] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup
> [ 114.890319] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup
> [ 114.897033] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup
> [ 114.903686] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup
> [ 114.910369] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup
> [ 114.917083] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup
> [ 114.923767] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup
> [ 114.930480] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup
> [ 114.937133] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup
> [ 114.943817] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup
> [ 114.950500] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup
> [ 114.957183] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup
> [ 114.963867] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup
> [ 114.970550] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup
> [ 114.977264] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup
> [ 114.983947] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup
> [ 114.990631] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup
> [ 114.997314] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup
> [ 115.003997] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup
> [ 115.010711] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup
> [ 115.017395] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup
> [ 115.024078] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup
> [ 115.030761] drivers/usb/musb/musb_core.c:1173 (musb_hdrc) fifo_setup
> [ 115.037475] d
[PATCH 2/5] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
All the PHY configuration other than VBUS, ID GND and OTG SRP are removed
from twl6030. The phy configurations are taken care by the dedicated
usb2 phy driver. So twl6030 is made as comparator driver for VBUS and
ID detection.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/otg/Kconfig |2 +-
drivers/usb/otg/twl6030-usb.c | 118 +++--
2 files changed, 19 insertions(+), 101 deletions(-)
diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig
index 13fd1ddf..d8c8a42 100644
--- a/drivers/usb/otg/Kconfig
+++ b/drivers/usb/otg/Kconfig
@@ -68,7 +68,7 @@ config TWL4030_USB
config TWL6030_USB
tristate "TWL6030 USB Transceiver Driver"
- depends on TWL4030_CORE
+ depends on TWL4030_CORE && OMAP_USB2
select USB_OTG_UTILS
help
Enable this to support the USB OTG transceiver on TWL6030
diff --git a/drivers/usb/otg/twl6030-usb.c b/drivers/usb/otg/twl6030-usb.c
index 6907d8d..32525bb 100644
--- a/drivers/usb/otg/twl6030-usb.c
+++ b/drivers/usb/otg/twl6030-usb.c
@@ -25,8 +25,9 @@
#include
#include
#include
-#include
#include
+#include
+#include
#include
#include
#include
@@ -87,7 +88,7 @@
#defineVBUS_DETBIT(2)
struct twl6030_usb {
- struct usb_phy phy;
+ struct phy_companioncomparator;
struct device *dev;
/* for vbus reporting with irqs disabled */
@@ -107,7 +108,7 @@ struct twl6030_usb {
unsigned long features;
};
-#define phy_to_twl(x) container_of((x), struct twl6030_usb, phy)
+#definecomparator_to_twl(x) container_of((x), struct twl6030_usb,
comparator)
/*-*/
@@ -137,50 +138,9 @@ static inline u8 twl6030_readb(struct twl6030_usb *twl, u8
module, u8 address)
return ret;
}
-static int twl6030_phy_init(struct usb_phy *x)
+static int twl6030_start_srp(struct phy_companion *comparator)
{
- struct twl6030_usb *twl;
- struct device *dev;
- struct twl4030_usb_data *pdata;
-
- twl = phy_to_twl(x);
- dev = twl->dev;
- pdata = dev->platform_data;
-
- if (twl->linkstat == OMAP_MUSB_ID_GROUND)
- pdata->phy_power(twl->dev, 1, 1);
- else
- pdata->phy_power(twl->dev, 0, 1);
-
- return 0;
-}
-
-static void twl6030_phy_shutdown(struct usb_phy *x)
-{
- struct twl6030_usb *twl;
- struct device *dev;
- struct twl4030_usb_data *pdata;
-
- twl = phy_to_twl(x);
- dev = twl->dev;
- pdata = dev->platform_data;
- pdata->phy_power(twl->dev, 0, 0);
-}
-
-static int twl6030_phy_suspend(struct usb_phy *x, int suspend)
-{
- struct twl6030_usb *twl = phy_to_twl(x);
- struct device *dev = twl->dev;
- struct twl4030_usb_data *pdata = dev->platform_data;
-
- pdata->phy_suspend(dev, suspend);
-
- return 0;
-}
-
-static int twl6030_start_srp(struct usb_otg *otg)
-{
- struct twl6030_usb *twl = phy_to_twl(otg->phy);
+ struct twl6030_usb *twl = comparator_to_twl(comparator);
twl6030_writeb(twl, TWL_MODULE_USB, 0x24, USB_VBUS_CTRL_SET);
twl6030_writeb(twl, TWL_MODULE_USB, 0x84, USB_VBUS_CTRL_SET);
@@ -313,23 +273,8 @@ static irqreturn_t twl6030_usbotg_irq(int irq, void *_twl)
return IRQ_HANDLED;
}
-static int twl6030_set_peripheral(struct usb_otg *otg,
- struct usb_gadget *gadget)
+static int twl6030_enable_irq(struct twl6030_usb *twl)
{
- if (!otg)
- return -ENODEV;
-
- otg->gadget = gadget;
- if (!gadget)
- otg->phy->state = OTG_STATE_UNDEFINED;
-
- return 0;
-}
-
-static int twl6030_enable_irq(struct usb_phy *x)
-{
- struct twl6030_usb *twl = phy_to_twl(x);
-
twl6030_writeb(twl, TWL_MODULE_USB, 0x1, USB_ID_INT_EN_HI_SET);
twl6030_interrupt_unmask(0x05, REG_INT_MSK_LINE_C);
twl6030_interrupt_unmask(0x05, REG_INT_MSK_STS_C);
@@ -362,9 +307,9 @@ static void otg_set_vbus_work(struct work_struct *data)
CHARGERUSB_CTRL1);
}
-static int twl6030_set_vbus(struct usb_otg *otg, bool enabled)
+static int twl6030_set_vbus(struct phy_companion *comparator, bool enabled)
{
- struct twl6030_usb *twl = phy_to_twl(otg->phy);
+ struct twl6030_usb *twl = comparator_to_twl(comparator);
twl->vbus_enable = enabled;
schedule_work(&twl->set_vbus_work);
@@ -372,23 +317,12 @@ static int twl6030_set_vbus(struct usb_otg *otg, bool
enabled)
return 0;
}
-static int twl6030_set_host(struct usb_otg *otg, struct usb_bus *host)
-{
- if (!otg)
- return -ENODEV;
-
- otg->host = host;
- if (!host)
- otg->phy->state = OTG_STATE_UNDEFINED;
- return 0;
-}
-
static int __devinit twl6030_usb_probe(struct platform_devi
Re: [PATCH v2 1/8] ARM/dts: OMAP2: Add McBSP entries for OMAP2420 and OMAP2430 SoC
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. 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 01/10] ARM: OMAP3+: Implement timer workaround for errata i103 and i767
On 09/06/2012 09:06 AM, Jon Hunter wrote:
>
> On 09/06/2012 12:07 AM, Vaibhav Hiremath wrote:
>>
>>
>> On 9/6/2012 12:34 AM, Jon Hunter wrote:
>>> Errata Titles:
>>> i103: Delay needed to read some GP timer, WD timer and sync timer registers
>>> after wakeup (OMAP3/4)
>>> i767: Delay needed to read some GP timer registers after wakeup (OMAP5)
>>>
>>> Description (i103/i767):
>>> If a General Purpose Timer (GPTimer) is in posted mode (TSICR [2].POSTED=1),
>>> due to internal resynchronizations, values read in TCRR, TCAR1 and TCAR2
>>> registers right after the timer interface clock (L4) goes from stopped to
>>> active may not return the expected values. The most common event leading to
>>> this situation occurs upon wake up from idle.
>>>
>>> GPTimer non-posted synchronization mode is not impacted by this limitation.
>>>
>>> Workarounds:
>>> 1). Disable posted mode
>>> 2). Use static dependency between timer clock domain and MPUSS clock domain
>>> 3). Use no-idle mode when the timer is active
>>>
>>> Workarounds #2 and #3 are not pratical from a power standpoint and so
>>> workaround #1 has been implemented. Disabling posted mode adds some CPU
>>> overhead
>>> for configuring the timers as the CPU has to wait for the write to complete.
>>> However, disabling posted mode guarantees correct operation.
>>>
>>> Please note that it is safe to use posted mode for timers if the counter
>>> (TCRR)
>>> and capture (TCARx) registers will never be read. An example of this is the
>>> clock-event system timer. This is used by the kernel to schedule events
>>> however,
>>> the timers counter is never read and capture registers are not used. Given
>>> that
>>> the kernel configures this timer often yet never reads the counter register
>>> it
>>> is safe to enable posted mode in this case. Hence, for the timer used for
>>> kernel
>>> clock-events, posted mode is enabled by overriding the errata for devices
>>> that
>>> are impacted by this defect.
>>>
>>> Although both dmtimers and watchdogs are impacted by this defect this patch
>>> only
>>> implements the workaround for the dmtimer. Currently the watchdog driver
>>> does
>>> not read the counter register and so no workaround is necessary.
>>>
>>> Confirmed with Vaibhav Hiremath that this bug also impacts AM33xx devices.
>>>
>>
>> Thanks for pinging me on this and getting it confirmed.
>>
>>> Signed-off-by: Jon Hunter
>>> ---
>>> arch/arm/mach-omap2/timer.c |9 +++
>>> arch/arm/plat-omap/dmtimer.c |2 ++
>>> arch/arm/plat-omap/include/plat/dmtimer.h | 39
>>> +
>>> 3 files changed, 50 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
>>> index 2ff6d41..5471706 100644
>>> --- a/arch/arm/mach-omap2/timer.c
>>> +++ b/arch/arm/mach-omap2/timer.c
>>> @@ -208,6 +208,13 @@ static void __init omap2_gp_clockevent_init(int
>>> gptimer_id,
>>> {
>>> int res;
>>>
>>> + /*
>>> +* For clock-event timers we never read the timer counter and
>>> +* so we are not impacted by errata i103 and i767. Therefore,
>>> +* we can safely ignore this errata for clock-event timers.
>>> +*/
>>> + __omap_dm_timer_populate_errata(&clkev, OMAP_TIMER_ERRATA_I103_I767);
>>> +
>>
>> Couple of points,
>>
>> 1. It is confusing to me, as you are passing the errata flag so i expect
>> api should set it. Why can't we do reverse way, you pass 0 here, since
>> you don't want to set and pass this flag every other places where you
>> want to enable this errata.
>
> Per the design of the __omap_dm_timer_populate_errata function, the 2nd
> argument is called override to allow us to override an errata. I am not
> a huge fan of this, but I wanted to be explicit in the code that we are
> intentionally allowing posted mode for the clock-events timer.
>
> I did not wish to pass the flags we want to set because if there more
> flags added in the future then we will have to keep changing the calls
> to the populate_errata function to add these.
By the way, your proposal could work nicely if we could pass errata
flags from HWMOD. However, I am not sure if Paul or Benoit would go for
this as they want HWMOD data to be auto-generated as much as possible
and so I am not sure how that would work for errata which are not
expected by design ;-)
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 00/10] ARM: OMAP: DMTIMER fixes and clean-up
On 09/06/2012 07:58 AM, Vaibhav Hiremath wrote:
>
>
> On 9/6/2012 12:34 AM, Jon Hunter wrote:
>> This series includes several fixes for the OMAP DMTIMER driver and a few
>> clean-ups to simplify some of the code. This series is based upon 3.6-rc4.
>>
>> Tested on OMAP5912 OSK, OMAP2420 H4, OMAP3430 Beagle and OMAP4430 Panda.
>> Testing includes ...
>> 1. Booting kernel on above boards
>> 2. Set date and ensuring time of day is correct after 24 hours
>> 3. Checking the timer counter is incrementing when configuring and starting
>>a timer
>> 4. Checking the timer overflow interrupt when timer expires.
>> 5. Using different clock sources to operate the timer with.
>> 6. Running a loop test overnight that continually runs test #3 and #4 for
>>each available timer
>>
>
> On the other hand I have validated this patch-series on both AM37xEVM
> and BeagleBone platform. I used the test code which you shared with me
> to validate it.
Thanks!
> AM33XX Clock tree needs minor change here,
>
> diff --git a/arch/arm/mach-omap2/clock33xx_data.c
> b/arch/arm/mach-omap2/clock33xx_data.c
> index a4006b2..daa36a5 100644
> --- a/arch/arm/mach-omap2/clock33xx_data.c
> +++ b/arch/arm/mach-omap2/clock33xx_data.c
> @@ -1070,6 +1070,8 @@ static struct omap_clk am33xx_clks[] = {
> CLK(NULL, "gfx_fck_div_ck", &gfx_fck_div_ck,
> CK_AM33XX),
> CLK(NULL, "sysclkout_pre_ck", &sysclkout_pre_ck,
> CK_AM33XX),
> CLK(NULL, "clkout2_ck", &clkout2_ck,CK_AM33XX),
> + CLK(NULL, "timer_32k_ck", &clkdiv32k_ick, CK_AM33XX),
> + CLK(NULL, "timer_sys_ck", &sys_clkin_ck, CK_AM33XX),
> };
>
> int __init am33xx_clk_init(void)
Ok, do you plan to submit this? If I need to do a V2 of this series, I
can include this one too.
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 15/17] OMAPDSS: remove extra_info completion code
On Thu, 2012-09-06 at 19:31 +0530, Archit Taneja wrote: > On Thursday 06 September 2012 07:12 PM, Tomi Valkeinen wrote: > > On Thu, 2012-09-06 at 19:05 +0530, Archit Taneja wrote: > >> On Thursday 06 September 2012 06:34 PM, Tomi Valkeinen wrote: > >>> On Wed, 2012-09-05 at 19:01 +0530, Archit Taneja wrote: > On Wednesday 05 September 2012 01:55 PM, Tomi Valkeinen wrote: > > Now that fifo merge has been removed, nobody uses the extra_info related > > completion code, which can be removed. > > I think this might come into use when we fix the usage of channel out > field. That is, since channel out is an immediate write field, when we > set a new manager for an overlay, we may need to wait till the overlay > disable kicks in, only then we should change channel out. > > For this, we would need some wait for extra_info, right? > >>> > >>> Hmm, yes, I think you are right. Previously the ovl_disable waited until > >>> the overlay is not used anymore, but now it doesn't. > >>> > >>> So I think I need to add wait_pending_extra_info_updates() call to the > >>> beginning of dss_ovl_set_manager(). Or, should it be in unset_manager... > >>> I think unset is better, then a "free" overlay always disabled also in > >>> the HW level. > >> > >> Yes, I also think it should be in unset_manager. One option could be to > >> leave the wait_pending_extra_info_updates() in ovl_disable itself, as it > >> was before. But that would force us to use mutexes there, and we'd > >> rather have overlay enabling and disabling as a non blocking thing. > > > > Actually, we do have mutexes there. You are thinking about the prototype > > API I have. (I also thought we didn't have mutex there =). > > Ah, I missed looking at that :) > > > > > So, in fact, we can have the wait at ovl_disable like it was before. The > > prototype API, which cannot block, will not have the wait, but there the > > caller (i.e. omapdrm) will have to manage the proper wait. > > I'm more inclined towards waiting in the unset_manager() now, we have a > choice between "wait in ovl_disable, ensure the overlay is actually > disabled in hw, and then get out" and "wait only when you know you need > to wait (i.e, in unset_manager)". The second choice seems more efficient. > > This wait would could last for a 1 VSYNC if we do it in ovl_disable. If > the next task of the user of DSS is to enable another overlay, this wait > would unnecessarily delay the enabling of the second overlay by a VSYNC. > We could have done these tasks in the same VSYNC (since we aren't > supporting fifomerge). > > So, I feel that we should rather wait in unset_manager, where we know an > immediate write can mess things up. Maybe, we could delay it set_manager > too. But yeah, we won't know whether we are aligned with hw or not. Good points. Then again, the wait function doesn't wait for the ovl to be disabled, it waits for all extra_info changes to be done. So we could be waiting unnecessarily in unset/set_manager. Which makes me think that we should remove the current wait function and implement a specialized wait for ovl disable. But that can be looked at later if seen necessary. Also, it feels safer to ensure the ovl is disabled at ovl_disable call. However, I was going through the code and I didn't come up with a case where it would cause problems, except the set_manager part. So, I guess having the wait in unset_manager is still best overall, we don't unnecessarily spend time waiting at ovl_disable. > So even with the prototype API, where omapdrm is responsible for doing > the waiting, it should probably wait when switching the manager, rather > than when disabling the overlay. Yep. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 09/10] ARM: OMAP: Add dmtimer interrupt disable function
On 09/06/2012 07:58 AM, Vaibhav Hiremath wrote: > > > On 9/6/2012 12:34 AM, Jon Hunter wrote: >> The OMAP dmtimer driver does not currently have a function to disable the >> timer interrupts. For some timer instances the timer interrupt enable >> function can be used to disable the interrupts because the same interrupt >> enable register is used to disable interrupts. However, some timer instances >> have separate interrupt enable/disable registers and so this will not work. >> Therefore, add a dedicated function to disable interrupts. >> > > I think you should clearly specify which timer and which device you are > referring to. OMAP4+ devices. For OMAP4 all timers apart from 1, 2 and 10. For OMAP5 all timers. 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 02/10] ARM: OMAP: Fix timer posted mode support
On 09/06/2012 07:57 AM, Vaibhav Hiremath wrote:
>
>
> On 9/6/2012 12:34 AM, Jon Hunter wrote:
>> Currently the dmtimer posted mode is being enabled when the function
>> __omap_dm_timer_reset() is called. This function is only being called for
>> OMAP1 timers and OMAP2+ timers that are being used as system timers. Hence,
>> for OMAP2+ timers that are NOT being used as a system timer, posted mode is
>> not enabled but the "timer->posted" variable is still set (incorrectly) in
>> the omap_dm_timer_prepare() function.
>>
>> This is a regression introduced by commit 3392cdd3 (ARM: OMAP: dmtimer:
>> switch-over to platform device driver) which changed the code to only call
>> omap_dm_timer_reset() for OMAP1 devices. Although this is a regression from
>> the original code it only impacts performance and so is not needed for
>> stable.
>>
>> Signed-off-by: Jon Hunter
>> ---
>> arch/arm/mach-omap2/timer.c |3 +--
>> arch/arm/plat-omap/dmtimer.c | 14 +-
>> arch/arm/plat-omap/include/plat/dmtimer.h |9 -
>> 3 files changed, 14 insertions(+), 12 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
>> index 5471706..e24ee0f 100644
>> --- a/arch/arm/mach-omap2/timer.c
>> +++ b/arch/arm/mach-omap2/timer.c
>> @@ -194,10 +194,9 @@ static int __init omap_dm_timer_init_one(struct
>> omap_dm_timer *timer,
>> }
>> __omap_dm_timer_init_regs(timer);
>> __omap_dm_timer_reset(timer, 1, 1);
>> -timer->posted = 1;
>> +__omap_dm_timer_enable_posted(timer);
>>
>> timer->rate = clk_get_rate(timer->fclk);
>> -
>> timer->reserved = 1;
>>
>> return res;
>> diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
>> index c34f55b..22790ea 100644
>> --- a/arch/arm/plat-omap/dmtimer.c
>> +++ b/arch/arm/plat-omap/dmtimer.c
>> @@ -122,21 +122,15 @@ static void omap_dm_timer_wait_for_reset(struct
>> omap_dm_timer *timer)
>>
>> static void omap_dm_timer_reset(struct omap_dm_timer *timer)
>> {
>> -omap_dm_timer_enable(timer);
>> if (timer->pdev->id != 1) {
>> omap_dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG, 0x06);
>> omap_dm_timer_wait_for_reset(timer);
>> }
>> -
>> __omap_dm_timer_reset(timer, 0, 0);
>> -omap_dm_timer_disable(timer);
>> -timer->posted = 1;
>> }
>>
>> int omap_dm_timer_prepare(struct omap_dm_timer *timer)
>> {
>> -int ret;
>> -
>> /*
>> * FIXME: OMAP1 devices do not use the clock framework for dmtimers so
>> * do not call clk_get() for these devices.
>> @@ -150,13 +144,15 @@ int omap_dm_timer_prepare(struct omap_dm_timer *timer)
>> }
>> }
>>
>> +omap_dm_timer_enable(timer);
>> +
>> if (timer->capability & OMAP_TIMER_NEEDS_RESET)
>> omap_dm_timer_reset(timer);
>>
>> -ret = omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
>> +__omap_dm_timer_enable_posted(timer);
>> +omap_dm_timer_disable(timer);
>>
>> -timer->posted = 1;
>> -return ret;
>> +return omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
>
> May be I am speculating here and I know this is tested and supposed to
> work, but Isn't it safe to set parent keeping module enables.
So you would rather change the functional clock while the timer is
enabled/active? So although that we are doing this today, that does not
sound like a good idea to me :-)
> I would still recommend you to move is before omap_dm_timer_disable().
> There could be devices or hw bugs/issues, may be related to standby/idle
> protocol happening underneath module enable/disable.
The register for setting the timer parent clock is located in the
Configuration Module (OMAP1) and PRCM (OMAP2+) and so there is no
requirement to keep the timer active while doing this.
Furthermore, if you look at the omap_dm_timer_set_source() function that
can be called from any driver using the timer, we never enable the timer
when setting the timer clock source. So this way is more consistent with
how the set_source function is implemented.
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] OMAP GPIO - don't wake from suspend unless requested.
On Thursday 06 September 2012 12:32 PM, NeilBrown wrote: > From: NeilBrown > Subject: [PATCH] OMAP GPIO - don't wake from suspend unless requested. > > Current kernel will wake from suspend on an event on any active > GPIO even if enable_irq_wake() wasn't called. > > There are two reasons that the hardware wake-enable bit should be set: > > 1/ while non-suspended the CPU might go into a deep sleep (off_mode) > in which the wake-enable bit is needed for an interrupt to be > recognised. > 2/ while suspended the GPIO interrupt should wake from suspend if and >only if irq_wake as been enabled. > > The code currently doesn't keep these two reasons separate so they get > confused and sometimes the wakeup flags is set incorrectly. > > This patch reverts: > commit 9c4ed9e6c01e7a8bd9079da8267e1f03cb4761fc > gpio/omap: remove suspend/resume callbacks > and > commit 0aa2727399c0b78225021413022c164cb99fbc5e > gpio/omap: remove suspend_wakeup field from struct gpio_bank > > and makes some minor changes so that we have separate flags for "GPIO > should wake from deep idle" and "GPIO should wake from suspend". > > With this patch, the GPIO from my touch screen doesn't wake my device > any more, which is what I want. Just gave it a try fixes a similar issue on my omap4 board as well. > > Cc: Kevin Hilman > Cc: Tony Lindgren > Cc: Santosh Shilimkar > Cc: Cousson Benoit > Cc: Grant Likely > Cc: Tarun Kanti DebBarma > Cc: Felipe Balbi > Cc: Govindraj.R > > Signed-off-by: NeilBrown -- 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 01/10] ARM: OMAP3+: Implement timer workaround for errata i103 and i767
On 09/06/2012 12:07 AM, Vaibhav Hiremath wrote:
>
>
> On 9/6/2012 12:34 AM, Jon Hunter wrote:
>> Errata Titles:
>> i103: Delay needed to read some GP timer, WD timer and sync timer registers
>> after wakeup (OMAP3/4)
>> i767: Delay needed to read some GP timer registers after wakeup (OMAP5)
>>
>> Description (i103/i767):
>> If a General Purpose Timer (GPTimer) is in posted mode (TSICR [2].POSTED=1),
>> due to internal resynchronizations, values read in TCRR, TCAR1 and TCAR2
>> registers right after the timer interface clock (L4) goes from stopped to
>> active may not return the expected values. The most common event leading to
>> this situation occurs upon wake up from idle.
>>
>> GPTimer non-posted synchronization mode is not impacted by this limitation.
>>
>> Workarounds:
>> 1). Disable posted mode
>> 2). Use static dependency between timer clock domain and MPUSS clock domain
>> 3). Use no-idle mode when the timer is active
>>
>> Workarounds #2 and #3 are not pratical from a power standpoint and so
>> workaround #1 has been implemented. Disabling posted mode adds some CPU
>> overhead
>> for configuring the timers as the CPU has to wait for the write to complete.
>> However, disabling posted mode guarantees correct operation.
>>
>> Please note that it is safe to use posted mode for timers if the counter
>> (TCRR)
>> and capture (TCARx) registers will never be read. An example of this is the
>> clock-event system timer. This is used by the kernel to schedule events
>> however,
>> the timers counter is never read and capture registers are not used. Given
>> that
>> the kernel configures this timer often yet never reads the counter register
>> it
>> is safe to enable posted mode in this case. Hence, for the timer used for
>> kernel
>> clock-events, posted mode is enabled by overriding the errata for devices
>> that
>> are impacted by this defect.
>>
>> Although both dmtimers and watchdogs are impacted by this defect this patch
>> only
>> implements the workaround for the dmtimer. Currently the watchdog driver does
>> not read the counter register and so no workaround is necessary.
>>
>> Confirmed with Vaibhav Hiremath that this bug also impacts AM33xx devices.
>>
>
> Thanks for pinging me on this and getting it confirmed.
>
>> Signed-off-by: Jon Hunter
>> ---
>> arch/arm/mach-omap2/timer.c |9 +++
>> arch/arm/plat-omap/dmtimer.c |2 ++
>> arch/arm/plat-omap/include/plat/dmtimer.h | 39
>> +
>> 3 files changed, 50 insertions(+)
>>
>> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
>> index 2ff6d41..5471706 100644
>> --- a/arch/arm/mach-omap2/timer.c
>> +++ b/arch/arm/mach-omap2/timer.c
>> @@ -208,6 +208,13 @@ static void __init omap2_gp_clockevent_init(int
>> gptimer_id,
>> {
>> int res;
>>
>> +/*
>> + * For clock-event timers we never read the timer counter and
>> + * so we are not impacted by errata i103 and i767. Therefore,
>> + * we can safely ignore this errata for clock-event timers.
>> + */
>> +__omap_dm_timer_populate_errata(&clkev, OMAP_TIMER_ERRATA_I103_I767);
>> +
>
> Couple of points,
>
> 1. It is confusing to me, as you are passing the errata flag so i expect
> api should set it. Why can't we do reverse way, you pass 0 here, since
> you don't want to set and pass this flag every other places where you
> want to enable this errata.
Per the design of the __omap_dm_timer_populate_errata function, the 2nd
argument is called override to allow us to override an errata. I am not
a huge fan of this, but I wanted to be explicit in the code that we are
intentionally allowing posted mode for the clock-events timer.
I did not wish to pass the flags we want to set because if there more
flags added in the future then we will have to keep changing the calls
to the populate_errata function to add these.
> 2. Why can't we enable for all timers? Even though clock-event is anyway
> not reading it, but still is is applicable to it, right?
Yes it is still applicable but we never read it so it is ok to override.
If you see Richard W's original patch for enabling posted mode it is to
reduce overhead of programming timers, specifically the clock-events
timer which is program very often.
For other timers, we do not know how they will be used and so by default
we disable posted mode as this is safe.
> 3. Why can't we just simply Add this flag to hwmod_data file and read it
> back in omap_timer_init() and omap_dm_timer_init_one(). Wouldn't that be
> a good approach to handle it?
It could be done in this case, but typically I have not seen errata
flags added to HWMOD. One limitation you would have with HWMOD is if an
erratum is only specific to a certain revision of the device. In this
case it is not and so it could work.
In general I think that having errata described by HWMOD would be a good
thing, but if think that should be a longer term goal with agreement
from Ben
Re: [PATCH] Don't clobber access methods when !regmap
Hi, On Sep 6, 2012, at 5:01 PM, Peter Ujfalusi wrote: > Hi, > > On 09/05/2012 07:43 PM, Pantelis Antoniou wrote: >> The driver in question (twl4030.c) does not call >> snd_soc_codec_set_cache_io(). >> However the snd-soc core does call it in sound/soc/soc-core.c in >> soc_probe_codec. >> >> I do see that there's a commit 98d3088e534a2a61f6690b5426909b0c3b57a785 that >> is >> fixing it in a different manner. > > I also noticed this (with 3.6-rc1 I think). > The commit you mention does fix it so we do not have issue anymore. > I sent two patches related to this: > http://mailman.alsa-project.org/pipermail/alsa-devel/2012-August/053864.html > http://mailman.alsa-project.org/pipermail/alsa-devel/2012-August/053876.html > > Mark took a different route which gives us the commit you mentioned: > http://mailman.alsa-project.org/pipermail/alsa-devel/2012-August/053889.html > > Regards, > Péter Quite similar to my patches. They're not needed now, since I have verified that the issue is fixed. Regards -- Pantelis -- 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] OMAPDSS: remove extra_info completion code
On Thursday 06 September 2012 07:12 PM, Tomi Valkeinen wrote: On Thu, 2012-09-06 at 19:05 +0530, Archit Taneja wrote: On Thursday 06 September 2012 06:34 PM, Tomi Valkeinen wrote: On Wed, 2012-09-05 at 19:01 +0530, Archit Taneja wrote: On Wednesday 05 September 2012 01:55 PM, Tomi Valkeinen wrote: Now that fifo merge has been removed, nobody uses the extra_info related completion code, which can be removed. I think this might come into use when we fix the usage of channel out field. That is, since channel out is an immediate write field, when we set a new manager for an overlay, we may need to wait till the overlay disable kicks in, only then we should change channel out. For this, we would need some wait for extra_info, right? Hmm, yes, I think you are right. Previously the ovl_disable waited until the overlay is not used anymore, but now it doesn't. So I think I need to add wait_pending_extra_info_updates() call to the beginning of dss_ovl_set_manager(). Or, should it be in unset_manager... I think unset is better, then a "free" overlay always disabled also in the HW level. Yes, I also think it should be in unset_manager. One option could be to leave the wait_pending_extra_info_updates() in ovl_disable itself, as it was before. But that would force us to use mutexes there, and we'd rather have overlay enabling and disabling as a non blocking thing. Actually, we do have mutexes there. You are thinking about the prototype API I have. (I also thought we didn't have mutex there =). Ah, I missed looking at that :) So, in fact, we can have the wait at ovl_disable like it was before. The prototype API, which cannot block, will not have the wait, but there the caller (i.e. omapdrm) will have to manage the proper wait. I'm more inclined towards waiting in the unset_manager() now, we have a choice between "wait in ovl_disable, ensure the overlay is actually disabled in hw, and then get out" and "wait only when you know you need to wait (i.e, in unset_manager)". The second choice seems more efficient. This wait would could last for a 1 VSYNC if we do it in ovl_disable. If the next task of the user of DSS is to enable another overlay, this wait would unnecessarily delay the enabling of the second overlay by a VSYNC. We could have done these tasks in the same VSYNC (since we aren't supporting fifomerge). So, I feel that we should rather wait in unset_manager, where we know an immediate write can mess things up. Maybe, we could delay it set_manager too. But yeah, we won't know whether we are aligned with hw or not. So even with the prototype API, where omapdrm is responsible for doing the waiting, it should probably wait when switching the manager, rather than when disabling the overlay. Archit -- 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] Don't clobber access methods when !regmap
Hi, On 09/05/2012 07:43 PM, Pantelis Antoniou wrote: > The driver in question (twl4030.c) does not call snd_soc_codec_set_cache_io(). > However the snd-soc core does call it in sound/soc/soc-core.c in > soc_probe_codec. > > I do see that there's a commit 98d3088e534a2a61f6690b5426909b0c3b57a785 that > is > fixing it in a different manner. I also noticed this (with 3.6-rc1 I think). The commit you mention does fix it so we do not have issue anymore. I sent two patches related to this: http://mailman.alsa-project.org/pipermail/alsa-devel/2012-August/053864.html http://mailman.alsa-project.org/pipermail/alsa-devel/2012-August/053876.html Mark took a different route which gives us the commit you mentioned: http://mailman.alsa-project.org/pipermail/alsa-devel/2012-August/053889.html Regards, Péter -- 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 0/2] arm/dts: AM33XX: Add reg and interrupt property for all nodes
Hi Vaihbav, On 08/27/2012 02:31 PM, Vaibhav Hiremath wrote: > This series is trivial patch-series and should be considered as > preparation for the future where we supposed to get rid of > hwmod dependency. > > 1/2: Converts all hex numbers to lowercase, fixing inconsistency > 2/2: Add reg and interrupt property to all device/module nodes inside > DTS files. > > Although currently hwmod overwrites resources, I have validated this > patch series by changing the omap_device layer to respect DT resources > and boot Tested on BeagleBone platform. > I will be submitting the changes for omap_device layer as well, still > needs to fix on certain things. > > Vaibhav Hiremath (2): > arm/dts: AM33XX: Convert all hex numbers to lower-case > arm/dts: AM33XX: Specify reg and interrupt property for all nodes > > arch/arm/boot/dts/am335x-bone.dts |2 +- > arch/arm/boot/dts/am335x-evm.dts |2 +- > arch/arm/boot/dts/am33xx.dtsi | 62 > +++-- > 3 files changed, 54 insertions(+), 12 deletions(-) I'll queue that along with the other DT stuff for 3.7. Thanks, 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: [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes
On 07/23/2012 10:24 AM, Jon Hunter wrote:
> Hi Rob,
>
> On 07/16/2012 10:56 AM, Jon Hunter wrote:
>> Hi Rob,
>>
>> On 07/13/2012 09:15 PM, Rob Herring wrote:
>>> On 07/13/2012 05:26 PM, Jon Hunter wrote:
Add the 12 GP timers nodes present in OMAP3.
Add the 11 GP timers nodes present in OMAP4.
Add documentation for timer properties specific to OMAP.
For each timer an alias is being added. The purpose for doing this is
because
the OMAP dmtimer driver uses an ID to distinguish between the different
timer
instances. For example, a timer can be requested by its ID. By adding an
alias
for each timer we can then use the function of_alias_get_id() to extract
the
ID for each timer from the alias name. The same method is used for the TTY
serial devices. If it is preferred that such an alias is not added and
there
is a better way to pass an ID from device-tree let me know.
>>>
>>> I'm not sure this is really a good use of aliases. UARTs use aliases
>>> because it is important that the UART number to tty number is known and
>>> fixed. IIUC, as an example you are picking timer1 because it has
>>> properties X, Y and Z. If so, then you should describe those h/w
>>> properties within the timer nodes so you can pick which timer to use
>>> based on it's h/w properties.
>>
>> Thanks for the feedback. What you suggest could definitely work for most
>> timers. The only item that I would need to resolve here is the handling
>> of system timers (ie. those used for clockevents and clocksource). These
>> system timers (for OMAP) are reserved during early boot based upon the
>> timer ID today and so this is before the actual main timer driver has
>> been probed and all the attributes of the timers has been read for
>> device-tree.
>>
>> One thought would be to move the reservation of the system timers out of
>> the kernel and into device-tree itself. Then we query device tree on
>> start-up to see which we should use. I am wondering if this could be a
>> better use of alias? For example, say I want to use timer1 as my
>> clockevent timer and so I could have an alias of ...
>>
>> alias {
>> clockevent_timer = &timer1;
>> }
>>
>> However, I am not sure if this is even correct, because there does not
>> appear to be an API to search the aliases by name and return the
>> phandle, just of_alias_get_id(). Alternatively, I could add another
>> property called "ti,timer-clockevent" that is populated for the timer
>> used as the clockevent timer.
>
> Do you have any inputs on the above? Does it make sense to reserve timer
> resources for kernel system timers in device-tree?
This issue is not unique to omap. So if we do specify clockevent and
clocksource in dts, then it should be in a common way. I think using
"linux,clockevent" either as an alias name or property within the timer
node would work. I don't have a strong preference, but I tend to lean
toward an alias. Primarily this is because we are already using aliases
for similar purposes.
However, I still think this could be done by looking at properties.
There's not really any reason you can't check properties at timer init
stage. The FDT has already been un-flattened. What are the features or
lack of features you care about to determine which timer to use?
Rob
--
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: Resume crash: MUSB interrupt routine interactions with omap2430_musb_set_vbus()
Felipe let me know of the patch that I didn't see in the queue. Thanks! - Tim On 09/06/12 08:35, Tim Nordell wrote: All - We've been doing some suspend/resume testing and found that on occasion (on the order of 1 in 5000 cycles) the system would lock up. The problem was traced into the MUSB subsystem. Specifically, the interrupt requested inside musb_core.c is of the non-threaded type (e.g. it runs in the interrupt context). -- 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] OMAPDSS: remove extra_info completion code
On Thu, 2012-09-06 at 19:05 +0530, Archit Taneja wrote: > On Thursday 06 September 2012 06:34 PM, Tomi Valkeinen wrote: > > On Wed, 2012-09-05 at 19:01 +0530, Archit Taneja wrote: > >> On Wednesday 05 September 2012 01:55 PM, Tomi Valkeinen wrote: > >>> Now that fifo merge has been removed, nobody uses the extra_info related > >>> completion code, which can be removed. > >> > >> I think this might come into use when we fix the usage of channel out > >> field. That is, since channel out is an immediate write field, when we > >> set a new manager for an overlay, we may need to wait till the overlay > >> disable kicks in, only then we should change channel out. > >> > >> For this, we would need some wait for extra_info, right? > > > > Hmm, yes, I think you are right. Previously the ovl_disable waited until > > the overlay is not used anymore, but now it doesn't. > > > > So I think I need to add wait_pending_extra_info_updates() call to the > > beginning of dss_ovl_set_manager(). Or, should it be in unset_manager... > > I think unset is better, then a "free" overlay always disabled also in > > the HW level. > > Yes, I also think it should be in unset_manager. One option could be to > leave the wait_pending_extra_info_updates() in ovl_disable itself, as it > was before. But that would force us to use mutexes there, and we'd > rather have overlay enabling and disabling as a non blocking thing. Actually, we do have mutexes there. You are thinking about the prototype API I have. (I also thought we didn't have mutex there =). So, in fact, we can have the wait at ovl_disable like it was before. The prototype API, which cannot block, will not have the wait, but there the caller (i.e. omapdrm) will have to manage the proper wait. Tomi signature.asc Description: This is a digitally signed message part
Re: [RFC PATCH] OMAPDSS: DISPC: Fix IRQ unregister race
Hi, On Sun, 2012-09-02 at 22:12 +0300, Dimitar Dimitrov wrote: > Very rare kernel crashes are reported on a custom OMAP4 board. Kernel > panics due to corrupted completion structure while executing > dispc_irq_wait_handler(). Excerpt from kernel log: > > Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP > Unable to handle kernel paging request at virtual address 00400130 > ... > PC is at 0xebf205bc > LR is at __wake_up_common+0x54/0x94 > ... > (__wake_up_common+0x0/0x94) > (complete+0x0/0x60) > (dispc_irq_wait_handler.36902+0x0/0x14) > (omap_dispc_irq_handler+0x0/0x354) > (handle_irq_event_percpu+0x0/0x188) > (handle_irq_event+0x0/0x64) > (handle_fasteoi_irq+0x0/0x10c) > (generic_handle_irq+0x0/0x48) > (asm_do_IRQ+0x0/0xc0) > > DISPC IRQ executes callbacks with dispc.irq_lock released. Hence > unregister_isr() and DISPC IRQ might be running in parallel on different > CPUs. So there is a chance that a callback is executed even though it > has been unregistered. As omap_dispc_wait_for_irq_timeout() declares a > completion on stack, the dispc_irq_wait_handler() callback might try to > access a completion structure that is invalid. This leads to crashes and > hangs. > > Solution is to divide unregister calls into two sets: > 1. Non-strict unregistering of callbacks. Callbacks could safely be > executed after unregistering them. This is the case with unregister > calls from the IRQ handler itself. > 2. Strict (synchronized) unregistering. Callbacks are not allowed > after unregistering. This is the case with completion waiting. > > The above solution should satisfy one of the original intentions of the > driver: callbacks should be able to unregister themselves. I think it'd be better to create a new function for the nosync version, and keep the old name for the sync version. The reason for this is to minimize the amount of changes, as I think this one needs to be applied to stable kernel trees also. Also, I think we need similar one for dsi.c, as it has the same kind of irq handling. But with a quick glance only sync version is needed there. However, I'm not quite sure about this approach. The fix makes sense, but it makes me think if the irq handling is designed the wrong way. While debugging and fixing this, did you think some other irq handling approach would be saner? Tomi signature.asc Description: This is a digitally signed message part
