[PATCH] ARM: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set

[Paul Walmsley]

After commit 846a136881b8f73c1f74250bf6acfaa309cab1f2 ("ARM: vfp: fix
saving d16-d31 vfp registers on v6+ kernels"), the OMAP 2430SDP board
started crashing during boot with omap2plus_defconfig:

[3.875122] mmcblk0: mmc0:e624 SD04G 3.69 GiB
[3.915954]  mmcblk0: p1
[4.086639] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
[4.093719] Modules linked in:
[4.096954] CPU: 0Not tainted  (3.6.0-02232-g759e00b #570)
[4.103149] PC is at vfp_reload_hw+0x1c/0x44
[4.107666] LR is at __und_usr_fault_32+0x0/0x8

It turns out that the context save/restore fix unmasked a latent bug in 
commit 5aaf254409f8d58229107b59507a8235b715a960 ("ARM: 6203/1: Make VFPv3 
usable on ARMv6").  When CONFIG_VFPv3 is set, but the kernel is booted on 
a pre-VFPv3 core, the code attempts to save and restore the d16-d31 VFP 
registers.  These are only present on non-D16 VFPv3+, so the kernel dies 
with an undefined instruction exception.  The kernel didn't crash before 
commit 846a136 because the save and restore code only touched d0-d15, 
present on all VFP.

Fix to save and restore the d16-d31 registers only if they are
present.

Signed-off-by: Paul Walmsley 
Cc: Tony Lindgren 
Cc: Russell King 
Cc: Catalin Marinas 
Cc: Dave Martin 
---
 arch/arm/include/asm/vfp.h   |6 ++
 arch/arm/include/asm/vfpmacros.h |8 
 arch/arm/vfp/vfpmodule.c |   10 ++
 3 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/vfp.h b/arch/arm/include/asm/vfp.h
index f4ab34f..5689798 100644
--- a/arch/arm/include/asm/vfp.h
+++ b/arch/arm/include/asm/vfp.h
@@ -82,3 +82,9 @@
 #define VFPOPDESC_UNUSED_BIT   (24)
 #define VFPOPDESC_UNUSED_MASK  (0xFF << VFPOPDESC_UNUSED_BIT)
 #define VFPOPDESC_OPDESC_MASK  (~(VFPOPDESC_LENGTH_MASK | 
VFPOPDESC_UNUSED_MASK))
+
+#ifndef __ASSEMBLER__
+#include 
+
+extern u32 vfp_has_d16_d31;
+#endif
diff --git a/arch/arm/include/asm/vfpmacros.h b/arch/arm/include/asm/vfpmacros.h
index 6a6f1e4..11496a9 100644
--- a/arch/arm/include/asm/vfpmacros.h
+++ b/arch/arm/include/asm/vfpmacros.h
@@ -25,9 +25,9 @@
 #endif
 #ifdef CONFIG_VFPv3
 #if __LINUX_ARM_ARCH__ <= 6
-   ldr \tmp, =elf_hwcap@ may not have MVFR regs
+   ldr \tmp, =vfp_has_d16_d31  @ have VFP regs d16-d31?
ldr \tmp, [\tmp, #0]
-   tst \tmp, #HWCAP_VFPv3D16
+   cmp \tmp, #1
ldceql  p11, cr0, [\base],#32*4 @ FLDMIAD \base!, {d16-d31}
addne   \base, \base, #32*4 @ step over unused register 
space
 #else
@@ -49,9 +49,9 @@
 #endif
 #ifdef CONFIG_VFPv3
 #if __LINUX_ARM_ARCH__ <= 6
-   ldr \tmp, =elf_hwcap@ may not have MVFR regs
+   ldr \tmp, =vfp_has_d16_d31  @ have VFP regs d16-d31?
ldr \tmp, [\tmp, #0]
-   tst \tmp, #HWCAP_VFPv3D16
+   cmp \tmp, #1
stceql  p11, cr0, [\base],#32*4 @ FSTMIAD \base!, {d16-d31}
addne   \base, \base, #32*4 @ step over unused register 
space
 #else
diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index c834b32..929b53b 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -58,6 +58,12 @@ unsigned int VFP_arch;
 union vfp_state *vfp_current_hw_state[NR_CPUS];
 
 /*
+ * If the VFP on this ARM core has registers d16-d31, vfp_has_d16_d31 will
+ * be set to 1; otherwise, 0.  Only valid after startup.
+ */
+u32 vfp_has_d16_d31;
+
+/*
  * Is 'thread's most up to date state stored in this CPUs hardware?
  * Must be called from non-preemptible context.
  */
@@ -691,6 +697,8 @@ static int __init vfp_init(void)
thread_register_notifier(&vfp_notifier_block);
vfp_pm_init();
 
+   vfp_has_d16_d31 = 0;
+
/*
 * We detected VFP, and the support code is
 * in place; report VFP support to userspace.
@@ -706,6 +714,8 @@ static int __init vfp_init(void)
 */
if (((fmrx(MVFR0) & MVFR0_A_SIMD_MASK)) == 1)
elf_hwcap |= HWCAP_VFPv3D16;
+   else
+   vfp_has_d16_d31 = 1;
}
 #endif
/*
-- 
1.7.10.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 1/4] MMC: omap_hsmmc: set platform data after probe from DT node

[Grant Likely]

Balaji T K  wrote:

>On Friday 12 October 2012 08:44 PM, Daniel Mack wrote:
>> On 12.10.2012 16:56, Balaji T K wrote:
>>> On Friday 12 October 2012 07:59 PM, Daniel Mack wrote:
 On 12.10.2012 12:58, Daniel Mack wrote:
> diff --git a/drivers/mmc/host/omap_hsmmc.c
>b/drivers/mmc/host/omap_hsmmc.c
> index 19ccb59..4b70823 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -1728,6 +1728,7 @@ static int __devinit omap_hsmmc_probe(struct
>platform_device *pdev)
>   const u16 *offsetp = match->data;
>   pdata->reg_offset = *offsetp;
>   }
> + pdev->dev.platform_data = pdata;
>   }
>
>   if (pdata == NULL) {
>

 FWIW, this is the Oops I see without this patch:
>>> Hi,
>>> Shouldn't pdev->dev.platform_data be set to NULL on _remove ?
>>
>> Why?
>
>To make sure on second insmod it is NULL, When built as module,
>So that of_get_hsmmc_pdata is called to create pdata.

Actually the driver should *never* modify the value of dev->platform_data. 
Ever. Make a copy instead.

g.

-- 
Grant Likely, P.Eng.
Secret Lab Technologies Ltd.
--
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] drm/omap: fix issue w/ fb attached to multiple CRTCs

[Rob Clark]

From: Rob Clark 

When the fb is detached from one CRTC/plane, paddr was set back to
zero.  But really we don't want to do this because the fb could still
be attached to other CRTC/plane(s).  This originally worked like this
to catch cases of freeing a pinned fb (but with the refcnt'ing this
should no longer be needed).  Also, there is checking in the GEM code
for freeing a pinned GEM object, so this extra level of checking is
redundant.

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_fb.c |   14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_fb.c 
b/drivers/staging/omapdrm/omap_fb.c
index 446801d..75d2ff1 100644
--- a/drivers/staging/omapdrm/omap_fb.c
+++ b/drivers/staging/omapdrm/omap_fb.c
@@ -253,6 +253,7 @@ int omap_framebuffer_replace(struct drm_framebuffer *a,
int ret = 0, i, na, nb;
struct omap_framebuffer *ofba = to_omap_framebuffer(a);
struct omap_framebuffer *ofbb = to_omap_framebuffer(b);
+   uint32_t pinned_mask = 0;
 
na = a ? drm_format_num_planes(a->pixel_format) : 0;
nb = b ? drm_format_num_planes(b->pixel_format) : 0;
@@ -263,25 +264,24 @@ int omap_framebuffer_replace(struct drm_framebuffer *a,
pa = (i < na) ? &ofba->planes[i] : NULL;
pb = (i < nb) ? &ofbb->planes[i] : NULL;
 
-   if (pa) {
+   if (pa)
unpin(arg, pa->bo);
-   pa->paddr = 0;
-   }
 
if (pb && !ret) {
ret = omap_gem_get_paddr(pb->bo, &pb->paddr, true);
-   if (!ret)
+   if (!ret) {
omap_gem_dma_sync(pb->bo, DMA_TO_DEVICE);
+   pinned_mask |= (1 << i);
+   }
}
}
 
if (ret) {
/* something went wrong.. unpin what has been pinned */
for (i = 0; i < nb; i++) {
-   struct plane *pb = &ofba->planes[i];
-   if (pb->paddr) {
+   if (pinned_mask & (1 << i)) {
+   struct plane *pb = &ofba->planes[i];
unpin(arg, pb->bo);
-   pb->paddr = 0;
}
}
}
-- 
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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.

[Tony Lindgren]

* Kevin Hilman  [121012 13:34]:
>
> I'm not conviced (yet) that a mismatch is the root cause.  Yes, that's
> what the author of $SUBJECT patch assumed and stated, but I'm not
> pursuaded.  
> 
> If it's an improperly configured mux issue, then the UART will break
> whenever the device is actually omap_device_enable'd, whether in the
> driver or in the bus layer.

I tried booting n800 here with CONFIG_OMAP_MUX disabled, and no
change. Serial console output stops right when the console initializes.

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] tidspbridge: Refactor mapping find/remove operations

[Laurent Pinchart]

Hi Felipe, Omar,

Could I please get your feedback on this patch and 2/2 ? They try to split 
08/15 in easier to review chunks.

On Tuesday 25 September 2012 01:13:05 Laurent Pinchart wrote:
> Split the remove_mapping_information() function into find_dsp_mapping()
> to locate the mapping and remove_mapping_information() to remove it.
> Rename find_containing_mapping() to find_mpu_mapping() and share the
> search code between find_dsp_mapping() and find_mpu_mapping().
> 
> This prepares the driver for VM_PFNMAP support.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/staging/tidspbridge/rmgr/proc.c |  116 ++--
>  1 files changed, 59 insertions(+), 57 deletions(-)
> 
> diff --git a/drivers/staging/tidspbridge/rmgr/proc.c
> b/drivers/staging/tidspbridge/rmgr/proc.c index 7e4f12f..64b1bba 100644
> --- a/drivers/staging/tidspbridge/rmgr/proc.c
> +++ b/drivers/staging/tidspbridge/rmgr/proc.c
> @@ -145,47 +145,67 @@ static struct dmm_map_object *add_mapping_info(struct
> process_context *pr_ctxt, return map_obj;
>  }
> 
> -static int match_exact_map_obj(struct dmm_map_object *map_obj,
> - u32 dsp_addr, u32 size)
> +static void remove_mapping_information(struct process_context *pr_ctxt,
> +struct dmm_map_object *map_obj)
>  {
> - if (map_obj->dsp_addr == dsp_addr && map_obj->size != size)
> - pr_err("%s: addr match (0x%x), size don't (0x%x != 0x%x)\n",
> - __func__, dsp_addr, map_obj->size, size);
> + if (map_obj == NULL)
> + return;
> 
> - return map_obj->dsp_addr == dsp_addr &&
> - map_obj->size == size;
> + pr_debug("%s: match, deleting map info\n", __func__);
> +
> + spin_lock(&pr_ctxt->dmm_map_lock);
> + list_del(&map_obj->link);
> + spin_unlock(&pr_ctxt->dmm_map_lock);
> +
> + kfree(map_obj->dma_info.sg);
> + kfree(map_obj->pages);
> + kfree(map_obj);
>  }
> 
> -static void remove_mapping_information(struct process_context *pr_ctxt,
> - u32 dsp_addr, u32 size)
> +static struct dmm_map_object *
> +find_mapping(struct process_context *pr_ctxt, u32 addr, u32 size,
> +  int (*match)(struct dmm_map_object *, u32, u32))
>  {
>   struct dmm_map_object *map_obj;
> 
> - pr_debug("%s: looking for virt 0x%x size 0x%x\n", __func__,
> - dsp_addr, size);
> -
>   spin_lock(&pr_ctxt->dmm_map_lock);
>   list_for_each_entry(map_obj, &pr_ctxt->dmm_map_list, link) {
> - pr_debug("%s: candidate: mpu_addr 0x%x virt 0x%x size 0x%x\n",
> - __func__,
> - map_obj->mpu_addr,
> - map_obj->dsp_addr,
> - map_obj->size);
> -
> - if (match_exact_map_obj(map_obj, dsp_addr, size)) {
> - pr_debug("%s: match, deleting map info\n", __func__);
> - list_del(&map_obj->link);
> - kfree(map_obj->dma_info.sg);
> - kfree(map_obj->pages);
> - kfree(map_obj);
> + pr_debug("%s: candidate: mpu_addr 0x%x dsp_addr 0x%x size 
> 0x%x\n",
> +  __func__, map_obj->mpu_addr, map_obj->dsp_addr,
> +  map_obj->size);
> +
> + if (match(map_obj, addr, size)) {
> + pr_debug("%s: match!\n", __func__);
>   goto out;
>   }
> - pr_debug("%s: candidate didn't match\n", __func__);
> +
> + pr_debug("%s: no match!\n", __func__);
>   }
> 
> - pr_err("%s: failed to find given map info\n", __func__);
> + map_obj = NULL;
>  out:
>   spin_unlock(&pr_ctxt->dmm_map_lock);
> + return map_obj;
> +}
> +
> +static int match_exact_map_obj(struct dmm_map_object *map_obj,
> + u32 dsp_addr, u32 size)
> +{
> + if (map_obj->dsp_addr == dsp_addr && map_obj->size != size)
> + pr_err("%s: addr match (0x%x), size don't (0x%x != 0x%x)\n",
> + __func__, dsp_addr, map_obj->size, size);
> +
> + return map_obj->dsp_addr == dsp_addr &&
> + map_obj->size == size;
> +}
> +
> +static struct dmm_map_object *
> +find_dsp_mapping(struct process_context *pr_ctxt, u32 dsp_addr, u32 size)
> +{
> + pr_debug("%s: looking for virt 0x%x size 0x%x\n", __func__,
> +  dsp_addr, size);
> +
> + return find_mapping(pr_ctxt, dsp_addr, size, match_exact_map_obj);
>  }
> 
>  static int match_containing_map_obj(struct dmm_map_object *map_obj,
> @@ -197,33 +217,13 @@ static int match_containing_map_obj(struct
> dmm_map_object *map_obj, mpu_addr + size <= map_obj_end;
>  }
> 
> -static struct dmm_map_object *fi

Re: [PATCH 2/6] ARM: OMAP3/4: iommu: adapt to runtime pm

[Felipe Contreras]

On Fri, Oct 12, 2012 at 7:46 PM, Omar Ramirez Luna  wrote:
> On 12 October 2012 02:48, Felipe Contreras  wrote:
>> I already made most of these comments, but here they go again.
>
> I replied to all, but here it goes again:

Mostly, but not all :)

>>> @@ -142,11 +142,10 @@ static int iommu_enable(struct omap_iommu *obj)
>>> }
>>> }
>>>
>>> -   clk_enable(obj->clk);
>>> +   pm_runtime_get_sync(obj->dev);
>>>
>>> err = arch_iommu->enable(obj);
>>>
>>> -   clk_disable(obj->clk);
>>
>> The device will never go to sleep, until iommu_disable is called.
>> clk_enable -> pm_runtime_get_sync, clk_disable pm_runtime_put.
>
> Which is what you want... why would you want your iommu to be disabled
> if the client of that iommu could request a translation?

That's the whole point of *dynamic* pm; _when_ the client wants to
request a translation, _then_ the device is waken up, which is what I
believe the code currently does.

After your patch, even if I don't use the camera, or the DSP, the
iommu devices will be enabled, and will be consuming energy *all the
time*. Which I don't think is what we want.

I'm not saying I have a solution, I'm simply saying that's what's
going to happen if I'm correct.

> Remember that these iommus, sit along of other processors not on the
> main processor side. So, this code should enable it for the other
> processor to use, and there is no point where the processor can say
> "I'm not using it, shut it down" or "I'm using it, turn it on" in the
> middle of execution, other than suspend/resume and if supported,
> autosuspend.

I understand, but perhaps there should be?

>>> @@ -288,7 +285,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, 
>>> struct iotlb_entry *e)
>>> if (!obj || !obj->nr_tlb_entries || !e)
>>> return -EINVAL;
>>>
>>> -   clk_enable(obj->clk);
>>> +   pm_runtime_get_sync(obj->dev);
>>>
>>> iotlb_lock_get(obj, &l);
>>> if (l.base == obj->nr_tlb_entries) {
>>> @@ -318,7 +315,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, 
>>> struct iotlb_entry *e)
>>>
>>> cr = iotlb_alloc_cr(obj, e);
>>> if (IS_ERR(cr)) {
>>> -   clk_disable(obj->clk);
>>> +   pm_runtime_put_sync(obj->dev);
>>> return PTR_ERR(cr);
>>> }
>>
>> If I'm correct, the above pm_runtime_get/put are redundant, because
>> the count can't possibly reach 0 because of the reason I explained
>> before.
>>
>> The same for all the cases below.
>
> You can access this paths through debugfs, some of them doesn't work
> if the module is not enabled first, but in future if you just want to
> idle the iommu withouth freeing, these are needed to debug.
>
> BTW, the next patch in the series: ARM: OMAP: iommu: pm runtime save
> and restore context, let's you do a pm_runtime_[enable|put] through
> save/restore ctx functions, which is just for compatibility on how isp
> code uses the save and restore code.

All right, it has been some time since I've touched pm code, so if you say so.

>>> @@ -1009,7 +1001,8 @@ static int __devexit omap_iommu_remove(struct 
>>> platform_device *pdev)
>>> release_mem_region(res->start, resource_size(res));
>>> iounmap(obj->regbase);
>>>
>>> -   clk_put(obj->clk);
>>> +   pm_runtime_disable(obj->dev);
>>
>> This will turn on the device unnecessarily, wasting power, and there's
>> no need for that, kfree will take care of that without resuming.
>
> Left aside the aesthetics of having balanced calls, the device will be
> enabled if there was a pending resume to be executed, otherwise it
> won't, kfree won't increment the disable_depth counter and I don't
> think that freeing the pointer is enough reason to ignore
> pm_runtime_disable.

You are doing __pm_runtime_disable(dev, true), kfree will do
__pm_runtime_disable(dev, false), which is what we want. Both will
decrement the disable_depth.

But at least you agree that there's a chance that the device will be waken up.

>> Also, I still think that something like this is needed:
> ...
>> +static struct clk cam_fck = {
>> +   .name   = "cam_fck",
>> +   .ops= &clkops_omap2_iclk_dflt,
>> +   .parent = &l3_ick,
>> +   .enable_reg = OMAP_CM_REGADDR(OMAP3430_CAM_MOD, CM_ICLKEN),
>
> a cam_fck name to enable the ick?

Yeap, according to the TRM. Take a look at 12.3 Camera ISP Integration
Fig 12-50.

Cheers.

-- 
Felipe Contreras
--
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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.

[Kevin Hilman]

Russell King - ARM Linux  writes:

> On Fri, Oct 12, 2012 at 10:59:22AM -0700, Kevin Hilman wrote:
>> Russell King - ARM Linux  writes:
>> 
>> > On Fri, Oct 12, 2012 at 09:35:54AM -0700, Kevin Hilman wrote:
>> >> Sourav  writes:
>> >> > diff --git a/drivers/tty/serial/omap-serial.c
>> >> > b/drivers/tty/serial/omap-serial.c
>> >> > index 6ede6fd..3fbc7f7 100644
>> >> > --- a/drivers/tty/serial/omap-serial.c
>> >> > +++ b/drivers/tty/serial/omap-serial.c
>> >> > @@ -1414,6 +1414,7 @@ static int __devinit serial_omap_probe(struct
>> >> > platform_device *pdev)
>> >> > INIT_WORK(&up->qos_work, serial_omap_uart_qos_work);
>> >> >
>> >> > platform_set_drvdata(pdev, up);
>> >> > +   pm_runtime_set_active(&pdev->dev);
>> >> 
>> >> NAK.
>> >> 
>> >> This will obviously break platforms where the UARTs are not active
>> >> before driver loads.
>> >
>> > I thought I had proposed a solution for this issue, which was this
>> > sequence:
>> >
>> > omap_device_enable(dev);   
>> >  
>> > pm_runtime_set_active(dev);
>> >  
>> > pm_runtime_enable(dev);
>> >  
>> >
>> > Yes, I can understand people not liking the omap_device_enable()
>> > there, but I also notice that the email suggesting that never got a
>> > reply either - not even a "I tried this and it doesn't work" or "it
>> > does work".
>> 
>> Yes, that solution would work (though I didn't actually try it.)
>> 
>> However, we can't use omap_device_enable() in the driver.  We're trying
>> to clean all the drivers of OMAP-specific APIs.  That being said,
>> something similar could be done in the device/board init code to ensure
>> the UART HW is in the state that the driver is expecting it, but again,
>> that would just mask the real problem which is that a (re)init of the
>> console UART on 2420/n800 is causing output to disappear.
>
> See my more expansive suggestion just posted.
>
> Whatever way, this discrepancy between runtime PM state and actual device
> state is what is biting you, and it is that which needs fixing.  

I'm not conviced (yet) that a mismatch is the root cause.  Yes, that's
what the author of $SUBJECT patch assumed and stated, but I'm not
pursuaded.  

If it's an improperly configured mux issue, then the UART will break
whenever the device is actually omap_device_enable'd, whether in the
driver or in the bus layer.

Kevin

--
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] i2c: omap: fix spurious IRQs: disable/enable IRQ at INTC when idle

[Shubhrajyoti Datta]

On Sat, Oct 13, 2012 at 12:10 AM, Kevin Hilman
 wrote:
> From: Kevin Hilman 
>
> Currently, runtime PM is used to keep the device enabled only during
> active transfers and for a configurable runtime PM autosuspend timout
> after an xfer.
>
> In addition to idling the device, driver's ->runtime_suspend() method
> currently disables device interrupts when idle.  However, on some SoCs
> (notably OMAP4+), the I2C hardware may shared with other coprocessors.
> This means that the MPU will still recieve interrupts if a coprocessor
> is using the I2C device.  To avoid this, also disable interrupts at
> the MPU INTC when idling the device in ->runtime_suspend() (and
> re-enable them in ->runtime_resume().)  This part based on an original
> patch from Shubhrajyoti Datta.  NOTE: for proper sharing the I2C with
> a coprocessor, this driver still needs hwspinlock support added.
>
> This change is also meant to address an issue reported by Kalle
> Jokiniemi where I2C bus interrupt may be enabled before an I2C device
> interrupt handler (e.g. just after noirq resume phase) causing an
> interrupt flood on the I2C bus interrupt before the device interrupt
> is enabled (e.g. interrupts coming from devices on I2C connected PMIC
> before the PMIC chained hanlder is enabled.)  This problem is addresed
> by ensuring that the I2C bus interrupt left disabled until an I2C xfer
> is requested.

Looks good to me.
Will wait for Kalle though.

>
> Cc: Kalle Jokiniemi 
> Cc: Grygorii Strashko 
> Cc: Shubhrajyoti Datta ,
> Cc: Huzefa Kankroliwala 
> Cc: Nishanth Menon 
> Signed-off-by: Kevin Hilman 
> ---
>  drivers/i2c/busses/i2c-omap.c |3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index db31eae..e6413e8 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -1255,6 +1255,7 @@ static int omap_i2c_runtime_suspend(struct device *dev)
> /* Flush posted write */
> omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG);
> }
> +   disable_irq(_dev->irq);
>
> return 0;
>  }
> @@ -1275,6 +1276,8 @@ static int omap_i2c_runtime_resume(struct device *dev)
> omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
> }
>
> +   enable_irq(_dev->irq);
> +
> /*
>  * Don't write to this register if the IE state is 0 as it can
>  * cause deadlock.
> --
> 1.7.9.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" 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 v3] ARM: OMAP: i2c: fix interrupt flood during resume

[shubhro]

On Saturday 13 October 2012 12:34 AM, Kevin Hilman wrote:
> Shubhrajyoti Datta  writes:
>
>> On Fri, Oct 12, 2012 at 10:13 PM, Kevin Hilman
>>  wrote:
>>> "Strashko, Grygorii"  writes:
>>>
 Hi Kevin,

 yep, [1] is the same fix - thanks.
 Hi Kalle,

 i've applied these changes and PM runtime fix on top of 
 git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git 
 (omap2plus_defconfig)
 Could you check it with your use case, pls? (just to be sure that idea is 
 right)
>>> I think the ideas is right, but [1] introduces more potential problems
>>> since it disables the IRQ at the INTC well before being disabled at the
>>> device.
>> I fail to see this point. Current driver supports master mode only.
>> So unless there is a msg queued by the core. May be no interrupts should 
>> fire.
>>
>> what I mean
>>
>> msg -> conf -> intr -> completion/error  -> autosuspend.
>>
>>>  With runtime PM autosuspend timeouts, that means any IRQs
>>> firing during the autosuspend delay will be lost, which basically
>>> nullifies the use of autosuspend.
>> so I do not expect any interrupts between completion/error -> autosuspend.
> Runtime PM is designed for concurrent users (hence the usecounting.)
> The I2C driver may not fully support this, since there is a single bus
> to share, but the usage of runtime PM currently allows multiple users to
> do runtime PM get/put (though in this driver they will block in the
> wait_for_bb.)
>
> So the fundamental problem in doing the enable/disable IRQ in the xfer
> function, and not the runtime PM callbacks is that you're ignoring the
> runtime PM usecount.  You're assuming that the 'get' is *always*
> incrementing the usecount from zero to 1, and the 'put' is *always* a
> transition from 1 to zero.  This may be the case in current usage and
> tests, but does not have to be the case.
>
> Even if that never happens in practice, it can in theory, and to me
> leads to confusing code.  It simply doesn't make sense in terms of
> readability to disable the IRQ at the INTC in xfer, and disable IRQs at
> the device level in the runtime PM callback.
Agree.
>
> To put it more simply: anything that needs to be done when the I2C is
> about to be idled/enabled should be done in the runtime PM callbacks.
>
> Please have a look at the patch I just sent[1].  In addition to making
> it more readable (IMO), it elminates the need for an extra disable_irq()
> in probe.

 thanks.
>
> Kevin
>
> [1] http://marc.info/?l=linux-omap&m=135006723121147&w=2

--
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] ARM: OMAP: i2c: fix interrupt flood during resume

[Kevin Hilman]

Shubhrajyoti Datta  writes:

> On Fri, Oct 12, 2012 at 10:13 PM, Kevin Hilman
>  wrote:
>> "Strashko, Grygorii"  writes:
>>
>>> Hi Kevin,
>>>
>>> yep, [1] is the same fix - thanks.
>>
>>> Hi Kalle,
>>>
>>> i've applied these changes and PM runtime fix on top of 
>>> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git 
>>> (omap2plus_defconfig)
>>> Could you check it with your use case, pls? (just to be sure that idea is 
>>> right)
>>
>> I think the ideas is right, but [1] introduces more potential problems
>> since it disables the IRQ at the INTC well before being disabled at the
>> device.
> I fail to see this point. Current driver supports master mode only.
> So unless there is a msg queued by the core. May be no interrupts should fire.
>
> what I mean
>
> msg -> conf -> intr -> completion/error  -> autosuspend.
>
>>  With runtime PM autosuspend timeouts, that means any IRQs
>> firing during the autosuspend delay will be lost, which basically
>> nullifies the use of autosuspend.
>
> so I do not expect any interrupts between completion/error -> autosuspend.

Runtime PM is designed for concurrent users (hence the usecounting.)
The I2C driver may not fully support this, since there is a single bus
to share, but the usage of runtime PM currently allows multiple users to
do runtime PM get/put (though in this driver they will block in the
wait_for_bb.)

So the fundamental problem in doing the enable/disable IRQ in the xfer
function, and not the runtime PM callbacks is that you're ignoring the
runtime PM usecount.  You're assuming that the 'get' is *always*
incrementing the usecount from zero to 1, and the 'put' is *always* a
transition from 1 to zero.  This may be the case in current usage and
tests, but does not have to be the case.

Even if that never happens in practice, it can in theory, and to me
leads to confusing code.  It simply doesn't make sense in terms of
readability to disable the IRQ at the INTC in xfer, and disable IRQs at
the device level in the runtime PM callback.

To put it more simply: anything that needs to be done when the I2C is
about to be idled/enabled should be done in the runtime PM callbacks.

Please have a look at the patch I just sent[1].  In addition to making
it more readable (IMO), it elminates the need for an extra disable_irq()
in probe.

Kevin

[1] http://marc.info/?l=linux-omap&m=135006723121147&w=2
--
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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.

[Russell King - ARM Linux]

On Fri, Oct 12, 2012 at 10:59:22AM -0700, Kevin Hilman wrote:
> Russell King - ARM Linux  writes:
> 
> > On Fri, Oct 12, 2012 at 09:35:54AM -0700, Kevin Hilman wrote:
> >> Sourav  writes:
> >> > diff --git a/drivers/tty/serial/omap-serial.c
> >> > b/drivers/tty/serial/omap-serial.c
> >> > index 6ede6fd..3fbc7f7 100644
> >> > --- a/drivers/tty/serial/omap-serial.c
> >> > +++ b/drivers/tty/serial/omap-serial.c
> >> > @@ -1414,6 +1414,7 @@ static int __devinit serial_omap_probe(struct
> >> > platform_device *pdev)
> >> > INIT_WORK(&up->qos_work, serial_omap_uart_qos_work);
> >> >
> >> > platform_set_drvdata(pdev, up);
> >> > +   pm_runtime_set_active(&pdev->dev);
> >> 
> >> NAK.
> >> 
> >> This will obviously break platforms where the UARTs are not active
> >> before driver loads.
> >
> > I thought I had proposed a solution for this issue, which was this
> > sequence:
> >
> > omap_device_enable(dev);
> > 
> > pm_runtime_set_active(dev); 
> > 
> > pm_runtime_enable(dev); 
> > 
> >
> > Yes, I can understand people not liking the omap_device_enable()
> > there, but I also notice that the email suggesting that never got a
> > reply either - not even a "I tried this and it doesn't work" or "it
> > does work".
> 
> Yes, that solution would work (though I didn't actually try it.)
> 
> However, we can't use omap_device_enable() in the driver.  We're trying
> to clean all the drivers of OMAP-specific APIs.  That being said,
> something similar could be done in the device/board init code to ensure
> the UART HW is in the state that the driver is expecting it, but again,
> that would just mask the real problem which is that a (re)init of the
> console UART on 2420/n800 is causing output to disappear.

See my more expansive suggestion just posted.

Whatever way, this discrepancy between runtime PM state and actual device
state is what is biting you, and it is that which needs fixing.  It's
fairly easy to fix given the right design, one which several other bus
types are already using.

Given the route that OMAP went down when adopting runtime PM, it's going
to be a big change across many drivers, because there's no way to gradually
transition them, but that's unfortunately one of the results of ignoring
requirements of the layers being used.  Sooner or later the oversights
come back to haunt.  Just make sure it's not the ghost of Jaws.
--
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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.

[Russell King - ARM Linux]

On Fri, Oct 12, 2012 at 05:29:55PM +, Poddar, Sourav wrote:
> Hi Russell,
> 
> From: Russell King - ARM Linux [li...@arm.linux.org.uk]
> Sent: Friday, October 12, 2012 10:12 PM
> To: Kevin Hilman
> Cc: Poddar, Sourav; Paul Walmsley; Balbi, Felipe; gre...@linuxfoundation.org; 
> t...@atomide.com; linux-ker...@vger.kernel.org; Shilimkar, Santosh; 
> linux-ser...@vger.kernel.org; linux-omap@vger.kernel.org; 
> linux-arm-ker...@lists.infradead.org; a...@linux.intel.com
> Subject: Re: [RFT/PATCH] serial: omap: prevent resume if device is not  
> suspended.
> 
> On Fri, Oct 12, 2012 at 09:35:54AM -0700, Kevin Hilman wrote:
> > Sourav  writes:
> > > diff --git a/drivers/tty/serial/omap-serial.c
> > > b/drivers/tty/serial/omap-serial.c
> > > index 6ede6fd..3fbc7f7 100644
> > > --- a/drivers/tty/serial/omap-serial.c
> > > +++ b/drivers/tty/serial/omap-serial.c
> > > @@ -1414,6 +1414,7 @@ static int __devinit serial_omap_probe(struct
> > > platform_device *pdev)
> > > INIT_WORK(&up->qos_work, serial_omap_uart_qos_work);
> > >
> > > platform_set_drvdata(pdev, up);
> > > +   pm_runtime_set_active(&pdev->dev);
> >
> > NAK.
> >
> > This will obviously break platforms where the UARTs are not active
> > before driver loads.
> 
> I thought I had proposed a solution for this issue, which was this
> sequence:
> 
> omap_device_enable(dev);
> pm_runtime_set_active(dev);
> pm_runtime_enable(dev);
> 
> Yes, I can understand people not liking the omap_device_enable()
> there, but I also notice that the email suggesting that never got a
> reply either - not even a "I tried this and it doesn't work" or "it
> does work".
> 
> Sorry for the late reply on this. I tried this sequence and it worked 
> perfectly fine on
> panda and beagle. 
> 
> As such, it seems this issue isn't making any progress as we had
> already established that merely doing a "pm_runtime_set_active()"
> before "pm_runtime_enable()" was going to break other platforms.
> 
>  I was  trying to analyse your explanations on this and since
> omap_device_enable is not generally recommended,  I was trying to see
> if anything else can be done to get around this.

Right, so what you need is explanation about why I believe the above
sequence to be necessary.

What is happening is that we're starting from a device in unknown state.
We don't know whether it is enabled or disabled.  We don't know the
state of the clocks or the power domain.

PM runtime state is initialized at device creation in the "device is
suspended" state.  If we merely enable PM runtime from that state, we
are telling the PM runtime subsystem that the device is _indeed_
suspended (disabled) at boot time.

So, that causes the first pm_runtime_get() call to resume the device.
Due to the OMAP runtime PM hooks at the bus layer, this causes
_od_runtime_resume() to be called.

_od_runtime_resume() does two things.  It calls omap_device_enable()
to ensure that the device is woken up (such as, ensuring that the
power domain is on, and turning on the clocks etc.)  It then goes on
to call the device PM layers to call the driver specific runtime PM
resume hook.

So, in summary, what this sequence does is:

pm_runtime_enable(&pdev->dev);
pm_runtime_use_autosuspend(&pdev->dev);
pm_runtime_set_autosuspend_delay(&pdev->dev,
omap_up_info->autosuspend_timeout);

pm_runtime_irq_safe(&pdev->dev);
pm_runtime_get_sync(&pdev->dev);

is, at the last call, it calls:

_od_runtime_resume()
omap_device_enable()
serial_omap_runtime_resume()

Your original patch at the head of this thread says that the driver
specific runtime resume call causes a problem for N800 - because the
device is already enabled and setup.

Okay, so the initial device state does not match the runtime PM state.

So, what happens if we _do_ make it match your state - as required by
the runtime PM documentation - by adding a call before the sequence:

pm_runtime_set_active(&pdev->dev);
pm_runtime_enable(&pdev->dev);
pm_runtime_use_autosuspend(&pdev->dev);
pm_runtime_set_autosuspend_delay(&pdev->dev,
omap_up_info->autosuspend_timeout);

pm_runtime_irq_safe(&pdev->dev);
pm_runtime_get_sync(&pdev->dev);

Right, now runtime PM knows that the device is enabled and alive prior
to that pm_runtime_get_sync() call, and it will _not_ call the runtime
resume hooks.

However, this breaks beaglebone, because the device is disabled when
this driver probes.  So, we have exactly the opposite problem here -
the device is disabled, but runtime PM thinks it is enabled.

The _two_ problems are precisely the same problem: the runtime PM state
does not accurately reflect the actual hardware state - again, as required
by the runtime PM documentation.  The only sane solution to this is to
ensure that the

Re: Errors at boot time from OMAP4430SDP (and a whinge about serial stuff)

[Kevin Hilman]

Tony Lindgren  writes:

> * Russell King - ARM Linux  [121012 08:56]:
>> For those who don't bother looking at my kautobuild boot tests on the OMAP
>> boards I have, here's the errors which get spat out at boot time.  Note
>> that some of these I've reported in the past, and one of them is missing
>> a newline character at the end of its string.

[...]

>
>> omap_vc_i2c_init: I2C config for vdd_iva does not match other channels (0).
>> omap_vc_i2c_init: I2C config for vdd_mpu does not match other channels 
>> (0).Power Management for TI OMAP4.
>
> Kevin?

Have had a fix for this for awhile, but it's currently part of a broader
VC/VP feature set.  I thought about breaking it out as its own fix, but
since voltage scaling is currently not supported/working on OMAP4
anyways, I decided it was not urgent.

Kevin
--
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] i2c: omap: fix spurious IRQs: disable/enable IRQ at INTC when idle

[Kevin Hilman]

From: Kevin Hilman 

Currently, runtime PM is used to keep the device enabled only during
active transfers and for a configurable runtime PM autosuspend timout
after an xfer.

In addition to idling the device, driver's ->runtime_suspend() method
currently disables device interrupts when idle.  However, on some SoCs
(notably OMAP4+), the I2C hardware may shared with other coprocessors.
This means that the MPU will still recieve interrupts if a coprocessor
is using the I2C device.  To avoid this, also disable interrupts at
the MPU INTC when idling the device in ->runtime_suspend() (and
re-enable them in ->runtime_resume().)  This part based on an original
patch from Shubhrajyoti Datta.  NOTE: for proper sharing the I2C with
a coprocessor, this driver still needs hwspinlock support added.

This change is also meant to address an issue reported by Kalle
Jokiniemi where I2C bus interrupt may be enabled before an I2C device
interrupt handler (e.g. just after noirq resume phase) causing an
interrupt flood on the I2C bus interrupt before the device interrupt
is enabled (e.g. interrupts coming from devices on I2C connected PMIC
before the PMIC chained hanlder is enabled.)  This problem is addresed
by ensuring that the I2C bus interrupt left disabled until an I2C xfer
is requested.

Cc: Kalle Jokiniemi 
Cc: Grygorii Strashko 
Cc: Shubhrajyoti Datta ,
Cc: Huzefa Kankroliwala 
Cc: Nishanth Menon 
Signed-off-by: Kevin Hilman 
---
 drivers/i2c/busses/i2c-omap.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index db31eae..e6413e8 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1255,6 +1255,7 @@ static int omap_i2c_runtime_suspend(struct device *dev)
/* Flush posted write */
omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG);
}
+   disable_irq(_dev->irq);
 
return 0;
 }
@@ -1275,6 +1276,8 @@ static int omap_i2c_runtime_resume(struct device *dev)
omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
}
 
+   enable_irq(_dev->irq);
+
/*
 * Don't write to this register if the IE state is 0 as it can
 * cause deadlock.
-- 
1.7.9.2

--
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] ARM: OMAP: i2c: fix interrupt flood during resume

[Shubhrajyoti Datta]

On Fri, Oct 12, 2012 at 10:13 PM, Kevin Hilman
 wrote:
> "Strashko, Grygorii"  writes:
>
>> Hi Kevin,
>>
>> yep, [1] is the same fix - thanks.
>
>> Hi Kalle,
>>
>> i've applied these changes and PM runtime fix on top of 
>> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git 
>> (omap2plus_defconfig)
>> Could you check it with your use case, pls? (just to be sure that idea is 
>> right)
>
> I think the ideas is right, but [1] introduces more potential problems
> since it disables the IRQ at the INTC well before being disabled at the
> device.
I fail to see this point. Current driver supports master mode only.
So unless there is a msg queued by the core. May be no interrupts should fire.

what I mean

msg -> conf -> intr -> completion/error  -> autosuspend.

>  With runtime PM autosuspend timeouts, that means any IRQs
> firing during the autosuspend delay will be lost, which basically
> nullifies the use of autosuspend.

so I do not expect any interrupts between completion/error -> autosuspend.

>
> Since Shubhrajyoti didn't respond to my runtime PM comments on the
> original patch,

my apologies for the delay.

> I'll respin this patch by moving the INTC disable/enable
> into the runtime PM callbacks and make the changelog a bit more clear.
>
> Grygorii, that pm_runtime_resume() change is needed to.  Can you spin a
> patch with just that change with a nice descriptive changelog about why
> it is needed?  Thanks.
>
> Kevin
--
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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.

[Kevin Hilman]

Russell King - ARM Linux  writes:

> On Fri, Oct 12, 2012 at 09:35:54AM -0700, Kevin Hilman wrote:
>> Sourav  writes:
>> > diff --git a/drivers/tty/serial/omap-serial.c
>> > b/drivers/tty/serial/omap-serial.c
>> > index 6ede6fd..3fbc7f7 100644
>> > --- a/drivers/tty/serial/omap-serial.c
>> > +++ b/drivers/tty/serial/omap-serial.c
>> > @@ -1414,6 +1414,7 @@ static int __devinit serial_omap_probe(struct
>> > platform_device *pdev)
>> > INIT_WORK(&up->qos_work, serial_omap_uart_qos_work);
>> >
>> > platform_set_drvdata(pdev, up);
>> > +   pm_runtime_set_active(&pdev->dev);
>> 
>> NAK.
>> 
>> This will obviously break platforms where the UARTs are not active
>> before driver loads.
>
> I thought I had proposed a solution for this issue, which was this
> sequence:
>
> omap_device_enable(dev);  
>   
> pm_runtime_set_active(dev);   
>   
> pm_runtime_enable(dev);   
>   
>
> Yes, I can understand people not liking the omap_device_enable()
> there, but I also notice that the email suggesting that never got a
> reply either - not even a "I tried this and it doesn't work" or "it
> does work".

Yes, that solution would work (though I didn't actually try it.)

However, we can't use omap_device_enable() in the driver.  We're trying
to clean all the drivers of OMAP-specific APIs.  That being said,
something similar could be done in the device/board init code to ensure
the UART HW is in the state that the driver is expecting it, but again,
that would just mask the real problem which is that a (re)init of the
console UART on 2420/n800 is causing output to disappear.

As I detailed in an earlier response, I still think it's the fact that
the pinmux is not setup correctly for the console UART pins in the board
file, so when the UART is initialized, its mux settings are changed from
the bootloader defaults, causing output to disappear.

> As such, it seems this issue isn't making any progress as we had
> already established that merely doing a "pm_runtime_set_active()"
> before "pm_runtime_enable()" was going to break other platforms.

Agreed.

Kevin
--
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/6] ARM: OMAP3/4: iommu: adapt to runtime pm

[Omar Ramirez Luna]

On 12 October 2012 02:48, Felipe Contreras  wrote:
> I already made most of these comments, but here they go again.

I replied to all, but here it goes again:

>> @@ -142,11 +142,10 @@ static int iommu_enable(struct omap_iommu *obj)
>> }
>> }
>>
>> -   clk_enable(obj->clk);
>> +   pm_runtime_get_sync(obj->dev);
>>
>> err = arch_iommu->enable(obj);
>>
>> -   clk_disable(obj->clk);
>
> The device will never go to sleep, until iommu_disable is called.
> clk_enable -> pm_runtime_get_sync, clk_disable pm_runtime_put.

Which is what you want... why would you want your iommu to be disabled
if the client of that iommu could request a translation?

Remember that these iommus, sit along of other processors not on the
main processor side. So, this code should enable it for the other
processor to use, and there is no point where the processor can say
"I'm not using it, shut it down" or "I'm using it, turn it on" in the
middle of execution, other than suspend/resume and if supported,
autosuspend.

>> @@ -288,7 +285,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, 
>> struct iotlb_entry *e)
>> if (!obj || !obj->nr_tlb_entries || !e)
>> return -EINVAL;
>>
>> -   clk_enable(obj->clk);
>> +   pm_runtime_get_sync(obj->dev);
>>
>> iotlb_lock_get(obj, &l);
>> if (l.base == obj->nr_tlb_entries) {
>> @@ -318,7 +315,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, 
>> struct iotlb_entry *e)
>>
>> cr = iotlb_alloc_cr(obj, e);
>> if (IS_ERR(cr)) {
>> -   clk_disable(obj->clk);
>> +   pm_runtime_put_sync(obj->dev);
>> return PTR_ERR(cr);
>> }
>
> If I'm correct, the above pm_runtime_get/put are redundant, because
> the count can't possibly reach 0 because of the reason I explained
> before.
>
> The same for all the cases below.

You can access this paths through debugfs, some of them doesn't work
if the module is not enabled first, but in future if you just want to
idle the iommu withouth freeing, these are needed to debug.

BTW, the next patch in the series: ARM: OMAP: iommu: pm runtime save
and restore context, let's you do a pm_runtime_[enable|put] through
save/restore ctx functions, which is just for compatibility on how isp
code uses the save and restore code.

>> @@ -1009,7 +1001,8 @@ static int __devexit omap_iommu_remove(struct 
>> platform_device *pdev)
>> release_mem_region(res->start, resource_size(res));
>> iounmap(obj->regbase);
>>
>> -   clk_put(obj->clk);
>> +   pm_runtime_disable(obj->dev);
>
> This will turn on the device unnecessarily, wasting power, and there's
> no need for that, kfree will take care of that without resuming.

Left aside the aesthetics of having balanced calls, the device will be
enabled if there was a pending resume to be executed, otherwise it
won't, kfree won't increment the disable_depth counter and I don't
think that freeing the pointer is enough reason to ignore
pm_runtime_disable.

> Also, I still think that something like this is needed:
...
> +static struct clk cam_fck = {
> +   .name   = "cam_fck",
> +   .ops= &clkops_omap2_iclk_dflt,
> +   .parent = &l3_ick,
> +   .enable_reg = OMAP_CM_REGADDR(OMAP3430_CAM_MOD, CM_ICLKEN),

a cam_fck name to enable the ick?

Cheers,

Omar
--
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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.

[Poddar, Sourav]

Hi Russell,

From: Russell King - ARM Linux [li...@arm.linux.org.uk]
Sent: Friday, October 12, 2012 10:12 PM
To: Kevin Hilman
Cc: Poddar, Sourav; Paul Walmsley; Balbi, Felipe; gre...@linuxfoundation.org; 
t...@atomide.com; linux-ker...@vger.kernel.org; Shilimkar, Santosh; 
linux-ser...@vger.kernel.org; linux-omap@vger.kernel.org; 
linux-arm-ker...@lists.infradead.org; a...@linux.intel.com
Subject: Re: [RFT/PATCH] serial: omap: prevent resume if device is not  
suspended.

On Fri, Oct 12, 2012 at 09:35:54AM -0700, Kevin Hilman wrote:
> Sourav  writes:
> > diff --git a/drivers/tty/serial/omap-serial.c
> > b/drivers/tty/serial/omap-serial.c
> > index 6ede6fd..3fbc7f7 100644
> > --- a/drivers/tty/serial/omap-serial.c
> > +++ b/drivers/tty/serial/omap-serial.c
> > @@ -1414,6 +1414,7 @@ static int __devinit serial_omap_probe(struct
> > platform_device *pdev)
> > INIT_WORK(&up->qos_work, serial_omap_uart_qos_work);
> >
> > platform_set_drvdata(pdev, up);
> > +   pm_runtime_set_active(&pdev->dev);
>
> NAK.
>
> This will obviously break platforms where the UARTs are not active
> before driver loads.

I thought I had proposed a solution for this issue, which was this
sequence:

omap_device_enable(dev);
pm_runtime_set_active(dev);
pm_runtime_enable(dev);

Yes, I can understand people not liking the omap_device_enable()
there, but I also notice that the email suggesting that never got a
reply either - not even a "I tried this and it doesn't work" or "it
does work".

Sorry for the late reply on this. I tried this sequence and it worked perfectly 
fine on
panda and beagle. 

As such, it seems this issue isn't making any progress as we had
already established that merely doing a "pm_runtime_set_active()"
before "pm_runtime_enable()" was going to break other platforms.

 I was  trying to analyse your explanations on this and since 
omap_device_enable is not generally 
recommended,  I was trying to see if anything else can be done to get around 
this.

I send this patch for N800 testing so  as to see how it behaves. (We are 
suspecting that there might be
mux setting issue also with N800).   

~Sourav
--
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: Errors at boot time from OMAP4430SDP (and a whinge about serial stuff)

[Tony Lindgren]

* Benoit Cousson  [121012 09:36]:
> Hi Tony,
> 
> On 10/12/2012 06:24 PM, Tony Lindgren wrote:
> > * Russell King - ARM Linux  [121012 08:56]:
> >> For those who don't bother looking at my kautobuild boot tests on the OMAP
> >> boards I have, here's the errors which get spat out at boot time.  Note
> >> that some of these I've reported in the past, and one of them is missing
> >> a newline character at the end of its string.
> > 
> > Thanks, let's get those fixed ASAP.
> >  
> >> twd: can't register interrupt 45 (-22)
> >> twd_local_timer_register failed -22

Posted a fix for this as "ARM: OMAP4: Fix twd_local_timer_register
regression".
 
> > Hmm I think this regression was caused by my sparse IRQ changes,
> > looks like I have a typo using OMAP_INTC_START in stead of the
> > GIC base. Will do a patch for this.
> > 
> >> omap_hwmod: mcpdm: cannot be enabled for reset (3)
> > 
> > Paul, Benoit, care to take a look at this?
> 
> Yeah, that one is a warning. The mcpdm is not accessible at boot time if
> the external clock (from twl6040) is not enabled.
> 
> Paul introduced a HWMOD_EXT_OPT_MAIN_CLK flag to avoid the warning [1],
> but it looks like that code is not merged.
> I'll check where that patch is stuck.

Thanks, seems like that would be OK to do during the early -rc
cycle to fix the warning.

Regards,

Tony
 
> [1]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-June/103019.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

[PATCH] ARM: OMAP4: Fix twd_local_timer_register regression

[Tony Lindgren]

Commit 7d7e1eba (ARM: OMAP2+: Prepare for irqs.h removal)
changed the interrupts to allow enabling sparse IRQ, but
accidentally added the omap3 INTC base to the local IRQ.
This causes the following:

twd: can't register interrupt 45 (-22)
twd_local_timer_register failed -22

The right fix is to not add any base, as it is a local
timer. For the OMAP44XX_IRQ_LOCALWDT we had defined earlier
there are no users, so no need to fix that.

Reported-by: Russell King 
Signed-off-by: Tony Lindgren 

--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -467,7 +467,7 @@ OMAP_SYS_TIMER(3_am33xx)
 #ifdef CONFIG_ARCH_OMAP4
 #ifdef CONFIG_LOCAL_TIMERS
 static DEFINE_TWD_LOCAL_TIMER(twd_local_timer,
- OMAP44XX_LOCAL_TWD_BASE, 29 + OMAP_INTC_START);
+ OMAP44XX_LOCAL_TWD_BASE, 29);
 #endif
 
 static void __init omap4_timer_init(void)
--
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] ARM: OMAP: i2c: fix interrupt flood during resume

[Kevin Hilman]

"Strashko, Grygorii"  writes:

> Hi Kevin,
>
> yep, [1] is the same fix - thanks. 

> Hi Kalle,
>
> i've applied these changes and PM runtime fix on top of 
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git 
> (omap2plus_defconfig)
> Could you check it with your use case, pls? (just to be sure that idea is 
> right)

I think the ideas is right, but [1] introduces more potential problems
since it disables the IRQ at the INTC well before being disabled at the
device.  With runtime PM autosuspend timeouts, that means any IRQs
firing during the autosuspend delay will be lost, which basically
nullifies the use of autosuspend.

Since Shubhrajyoti didn't respond to my runtime PM comments on the
original patch, I'll respin this patch by moving the INTC disable/enable
into the runtime PM callbacks and make the changelog a bit more clear.

Grygorii, that pm_runtime_resume() change is needed to.  Can you spin a
patch with just that change with a nice descriptive changelog about why
it is needed?  Thanks.

Kevin


>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index a0e49f6..cb09e20 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -586,6 +586,9 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg 
> msgs[], int num)
> if (IS_ERR_VALUE(r))
> goto out;
>  
> +   /* We have the bus, enable IRQ */
> +   enable_irq(dev->irq);
> +
> r = omap_i2c_wait_for_bb(dev);
> if (r < 0)
> goto out;
> @@ -606,6 +609,7 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg 
> msgs[], int num)
> r = num;
>  
> omap_i2c_wait_for_bb(dev);
> +   disable_irq(dev->irq);
>  out:
> pm_runtime_put(dev->dev);
> return r;
> @@ -1060,6 +1064,9 @@ omap_i2c_probe(struct platform_device *pdev)
>
> omap_i2c_isr;
> r = request_irq(dev->irq, isr, IRQF_NO_SUSPEND, pdev->name, dev);
>  
> +   /* We enable IRQ only when request for I2C from master */
> +disable_irq(dev->irq);
> +
> if (r) {
> dev_err(dev->dev, "failure requesting irq %i\n", dev->irq);
> goto err_unuse_clocks;
> @@ -1182,7 +1189,23 @@ static int omap_i2c_runtime_resume(struct device *dev)
>  }
>  #endif /* CONFIG_PM_RUNTIME */
>  
> +static int omap_i2c_suspend(struct device *dev)
> +{
> +   int ret;
> +
> +   /*
> +*  Enable I2C device, so it will be accessible during
> +* later stages of suspending when device Runtime PM is disabled.
> +* I2C device will be turned off at "noirq" suspend stage.
> +*/
> +   ret = pm_runtime_resume(dev);
> +   if (ret < 0)
> +   return ret;
> +   return 0;
> +}
> +
>  static struct dev_pm_ops omap_i2c_pm_ops = {
> +   SET_SYSTEM_SLEEP_PM_OPS(omap_i2c_suspend, NULL)
> SET_RUNTIME_PM_OPS(omap_i2c_runtime_suspend,
>omap_i2c_runtime_resume, NULL)
>  };
>
> - Grygorii
> 
> From: Kevin Hilman [khil...@deeprootsystems.com]
> Sent: Friday, October 12, 2012 5:34 PM
> To: Strashko, Grygorii
> Cc: Kalle Jokiniemi; linux-...@vger.kernel.org; w.s...@pengutronix.de; 
> ben-li...@fluff.org; t...@atomide.com; linux-omap@vger.kernel.org; Datta, 
> Shubhrajyoti; Kankroliwala, Huzefa
> Subject: Re: [PATCH v3] ARM: OMAP: i2c: fix interrupt flood during resume
>
> "Strashko, Grygorii"  writes:
>
>> Hi All,
>>
>> Sorry, for the late reply.
>> + CC Huzefa Kankroliwala - who is I2C driver owner on Android Kernel 3.4.
>
> Hi Grygorii, thanks for reviewing.  I was hoping you would have some
> ideas here as this was sounding familiar to something you had
> mentioned elsewhere.
>
>> Regarding this patch -  from my point of view, it fixes corner case and not 
>> an issue in general.
>> Let take a look on resume sequence:
>>- platform resume
>>- syscore resume
>>- resume_noirq
>>- enable IRQs - resume_device_irqs()
>>  |- at this point IRQ handler will be invoked if IRQ state is 
>> IRQS_PENDING.
>>  |- so, the I2C device IRQ handler may be called at time when I2C 
>> adapter IRQ is still disabled and, as result, the I2C device IRQ-handler may 
>> fail. (I2C device and I2C adapter may use different physical IRQ lines)
>>- resume_late
>>  |- enable I2C bus IRQ
>>
>> Possibly, the better way is to enable/disable I2C bus IRQ when needed - in 
>> our case in omap_i2c_xfer().
>> We use such approach in Android kernel 3.4
>> (http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=1445a4d3b587c164bd30d108b6176007365e)
>
> I agree, that should work and cover the cases where I2C is used by other
> processors also.  Shubhrajyoti already posted something similar[1] but
> it needed some rework (comments from Russell and myself.)
>
> Huzefa, Shubhrajyoti, who can rework this idea for the ups

Re: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.

[Russell King - ARM Linux]

On Fri, Oct 12, 2012 at 09:35:54AM -0700, Kevin Hilman wrote:
> Sourav  writes:
> > diff --git a/drivers/tty/serial/omap-serial.c
> > b/drivers/tty/serial/omap-serial.c
> > index 6ede6fd..3fbc7f7 100644
> > --- a/drivers/tty/serial/omap-serial.c
> > +++ b/drivers/tty/serial/omap-serial.c
> > @@ -1414,6 +1414,7 @@ static int __devinit serial_omap_probe(struct
> > platform_device *pdev)
> > INIT_WORK(&up->qos_work, serial_omap_uart_qos_work);
> >
> > platform_set_drvdata(pdev, up);
> > +   pm_runtime_set_active(&pdev->dev);
> 
> NAK.
> 
> This will obviously break platforms where the UARTs are not active
> before driver loads.

I thought I had proposed a solution for this issue, which was this
sequence:

omap_device_enable(dev);
pm_runtime_set_active(dev); 
pm_runtime_enable(dev); 

Yes, I can understand people not liking the omap_device_enable()
there, but I also notice that the email suggesting that never got a
reply either - not even a "I tried this and it doesn't work" or "it
does work".

As such, it seems this issue isn't making any progress as we had
already established that merely doing a "pm_runtime_set_active()"
before "pm_runtime_enable()" was going to break other platforms.
--
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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.

[Kevin Hilman]

Sourav  writes:

> Hi Paul,
>
> There are
> On Thursday 11 October 2012 11:58 PM, Paul Walmsley wrote:
>> Hi Sourav, Felipe,
>>
>> any progress on fixing the N800 problem?  Would be good to keep it booting
>> since we use it as our primary 2420 test platform.
>>
>>
>> - Paul
> The patch sent inlined below might help us to get rid of the serial
> init issue.
> Unfortunately, I dont have a N800 board with me to test it and will require
> your help to do so.
> ---
> From: Sourav Poddar 
> Date: Wed, 1 Aug 2012 15:44:12 +0530
> Subject: [RFT/PATCH] serial: omap: Fix N800 serial init issue.
>
>
> This patch might solve the N800 serial init issue.
>
> This patch will also give pointers if there is any mux settings issue
> with N800 OR
> a mismatch between the initial harware state, runtime PM state and
> omap hwmod state.

> I don't have a N800 schematics to check about the mux settings getting used.
>
> The observation on beagle board XM with this patch on different boards
> looks flaky,
> so your feedback on beagle board will also be very helpful.
>
> Cc: Felipe Balbi 
> Signed-off-by: Sourav Poddar 
> ---
>  drivers/tty/serial/omap-serial.c |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/tty/serial/omap-serial.c
> b/drivers/tty/serial/omap-serial.c
> index 6ede6fd..3fbc7f7 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -1414,6 +1414,7 @@ static int __devinit serial_omap_probe(struct
> platform_device *pdev)
> INIT_WORK(&up->qos_work, serial_omap_uart_qos_work);
>
> platform_set_drvdata(pdev, up);
> +   pm_runtime_set_active(&pdev->dev);

NAK.

This will obviously break platforms where the UARTs are not active
before driver loads.

Kevin

> pm_runtime_enable(&pdev->dev);
> pm_runtime_use_autosuspend(&pdev->dev);
> pm_runtime_set_autosuspend_delay(&pdev->dev,
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Errors at boot time from OMAP4430SDP (and a whinge about serial stuff)

[Benoit Cousson]

Hi Tony,

On 10/12/2012 06:24 PM, Tony Lindgren wrote:
> * Russell King - ARM Linux  [121012 08:56]:
>> For those who don't bother looking at my kautobuild boot tests on the OMAP
>> boards I have, here's the errors which get spat out at boot time.  Note
>> that some of these I've reported in the past, and one of them is missing
>> a newline character at the end of its string.
> 
> Thanks, let's get those fixed ASAP.
>  
>> twd: can't register interrupt 45 (-22)
>> twd_local_timer_register failed -22
> 
> Hmm I think this regression was caused by my sparse IRQ changes,
> looks like I have a typo using OMAP_INTC_START in stead of the
> GIC base. Will do a patch for this.
> 
>> omap_hwmod: mcpdm: cannot be enabled for reset (3)
> 
> Paul, Benoit, care to take a look at this?

Yeah, that one is a warning. The mcpdm is not accessible at boot time if
the external clock (from twl6040) is not enabled.

Paul introduced a HWMOD_EXT_OPT_MAIN_CLK flag to avoid the warning [1],
but it looks like that code is not merged.
I'll check where that patch is stuck.

Regards,
Benoit

[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-June/103019.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: Errors at boot time from OMAP4430SDP (and a whinge about serial stuff)

[Russell King - ARM Linux]

On Fri, Oct 12, 2012 at 09:24:52AM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux  [121012 08:56]:
> > As of today, I've rebased my serial changes as far forward as I dare at
> > the moment (to the commit before removal of DMA), and then merged it
> > into the latest trees from armsoc and myself, fixing up all the horrid
> > conflicts. I've finally got it to a stage where at least it compiles,
> > but unfortunately something has broken serial output from userspace
> > quite badly to the point that it doesn't work.
> > 
> > I know that my serial changes were fine before I tried rebasing them (the
> > set I posted to the mailing list certainly did work) so I suspect that
> > it's down to incompatibilities between the fixes done by others (who didn't
> > really understand all issues involved) and those done by myself.
> 
> Have you been able to locate the breaking patches, maybe those could
> be reverted?

Not yet; I'll look into it this weekend.  I've only recently got stuff
back into a state where the kautobuild kernels don't error out during
the build for the OMAP and SA11x0 stuff.  OMAP ended up in that
situation because of the duplicated serial efforts causing rather
disgusting and horrid conflicts.
--
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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.

[Sourav]

Hi Paul,

There are
On Thursday 11 October 2012 11:58 PM, Paul Walmsley wrote:

Hi Sourav, Felipe,

any progress on fixing the N800 problem?  Would be good to keep it booting
since we use it as our primary 2420 test platform.


- Paul
The patch sent inlined below might help us to get rid of the serial init 
issue.

Unfortunately, I dont have a N800 board with me to test it and will require
your help to do so.
---
From: Sourav Poddar 
Date: Wed, 1 Aug 2012 15:44:12 +0530
Subject: [RFT/PATCH] serial: omap: Fix N800 serial init issue.


This patch might solve the N800 serial init issue.

This patch will also give pointers if there is any mux settings issue 
with N800 OR
a mismatch between the initial harware state, runtime PM state and omap 
hwmod state.


I don't have a N800 schematics to check about the mux settings getting used.

The observation on beagle board XM with this patch on different boards 
looks flaky,

so your feedback on beagle board will also be very helpful.

Cc: Felipe Balbi 
Signed-off-by: Sourav Poddar 
---
 drivers/tty/serial/omap-serial.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c 
b/drivers/tty/serial/omap-serial.c

index 6ede6fd..3fbc7f7 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1414,6 +1414,7 @@ static int __devinit serial_omap_probe(struct 
platform_device *pdev)

INIT_WORK(&up->qos_work, serial_omap_uart_qos_work);

platform_set_drvdata(pdev, up);
+   pm_runtime_set_active(&pdev->dev);
pm_runtime_enable(&pdev->dev);
pm_runtime_use_autosuspend(&pdev->dev);
pm_runtime_set_autosuspend_delay(&pdev->dev,
--
1.7.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: Errors at boot time from OMAP4430SDP (and a whinge about serial stuff)

[Tony Lindgren]

* Russell King - ARM Linux  [121012 08:56]:
> For those who don't bother looking at my kautobuild boot tests on the OMAP
> boards I have, here's the errors which get spat out at boot time.  Note
> that some of these I've reported in the past, and one of them is missing
> a newline character at the end of its string.

Thanks, let's get those fixed ASAP.
 
> twd: can't register interrupt 45 (-22)
> twd_local_timer_register failed -22

Hmm I think this regression was caused by my sparse IRQ changes,
looks like I have a typo using OMAP_INTC_START in stead of the
GIC base. Will do a patch for this.

> omap_hwmod: mcpdm: cannot be enabled for reset (3)

Paul, Benoit, care to take a look at this?

> omap-gpmc omap-gpmc: error: clk_get
> omap-gpmc: probe of omap-gpmc failed with error -2

I think Afzal posted something about this already? Looks
like this too could be sparse IRQ related regression..

> Error setting wl12xx data: -38

Hmm I wonder if wl12xx_set_platform_data() is really
supposed to return -EBUSY if platform_data exists?
Ohad, can you please take a look?

> omap_hsmmc omap_hsmmc.1: Failed to get debounce clk
> omap_hsmmc omap_hsmmc.0: Failed to get debounce clk
> omap_hsmmc omap_hsmmc.4: Failed to get debounce clk

These should be optional AFAIK, so no warning should be
printed.

> twl6040-codec twl6040-codec: ASoC: Failed to create Capture debugfs file

Peter, can you take a look please?

> omap_vc_i2c_init: I2C config for vdd_iva does not match other channels (0).
> omap_vc_i2c_init: I2C config for vdd_mpu does not match other channels 
> (0).Power Management for TI OMAP4.

Kevin?

> mmc1: host does not support reading read-only switch. assuming write-enable.

This too should be optional.
 
> As of today, I've rebased my serial changes as far forward as I dare at
> the moment (to the commit before removal of DMA), and then merged it
> into the latest trees from armsoc and myself, fixing up all the horrid
> conflicts. I've finally got it to a stage where at least it compiles,
> but unfortunately something has broken serial output from userspace
> quite badly to the point that it doesn't work.
> 
> I know that my serial changes were fine before I tried rebasing them (the
> set I posted to the mailing list certainly did work) so I suspect that
> it's down to incompatibilities between the fixes done by others (who didn't
> really understand all issues involved) and those done by myself.

Have you been able to locate the breaking patches, maybe those could
be reverted?

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

Errors at boot time from OMAP4430SDP (and a whinge about serial stuff)

[Russell King - ARM Linux]

For those who don't bother looking at my kautobuild boot tests on the OMAP
boards I have, here's the errors which get spat out at boot time.  Note
that some of these I've reported in the past, and one of them is missing
a newline character at the end of its string.

twd: can't register interrupt 45 (-22)
twd_local_timer_register failed -22
omap_hwmod: mcpdm: cannot be enabled for reset (3)
omap-gpmc omap-gpmc: error: clk_get
omap-gpmc: probe of omap-gpmc failed with error -2
Error setting wl12xx data: -38
omap_hsmmc omap_hsmmc.1: Failed to get debounce clk
omap_hsmmc omap_hsmmc.0: Failed to get debounce clk
omap_hsmmc omap_hsmmc.4: Failed to get debounce clk
twl6040-codec twl6040-codec: ASoC: Failed to create Capture debugfs file
omap_vc_i2c_init: I2C config for vdd_iva does not match other channels (0).
omap_vc_i2c_init: I2C config for vdd_mpu does not match other channels 
(0).Power Management for TI OMAP4.
mmc1: host does not support reading read-only switch. assuming write-enable.

As of today, I've rebased my serial changes as far forward as I dare at
the moment (to the commit before removal of DMA), and then merged it
into the latest trees from armsoc and myself, fixing up all the horrid
conflicts. I've finally got it to a stage where at least it compiles,
but unfortunately something has broken serial output from userspace
quite badly to the point that it doesn't work.

I know that my serial changes were fine before I tried rebasing them (the
set I posted to the mailing list certainly did work) so I suspect that
it's down to incompatibilities between the fixes done by others (who didn't
really understand all issues involved) and those done by myself.

Unfortunately, the series of patches to fix the register writes and bits
to enable hardware assisted software flow control which have gone into
mainline have actually made the situation much worse - now the hardware
can end up with IXANY stuck on, and no way to turn off hardware assisted
software flow control - which is bad news for binary serial protocols.
It would have been far better to leave the driver as-is - at least the
software flow control would have been dealt correctly by the generic tty
layer.  Instead, we have a worse situation today...

While I may be the ex-maintainer of serial-core, given that I had already
investigated the issues there and had an understanding of the problems,
-and that was known-, copying me with the patches before they went into
mainline would've been the decent thing to have done, so that someone
with the knowledge of the breakage could have said "yes lets take those
patches" and "no, those shouldn't go in because it'll cause breakage"
such as I describe above.

I know how this situation arose; TI are desperate to get rid of the legacy
OMAP DMA API, and wanted me to look at the crypto drivers for DMA engine
support.  In the mean time, they silently took the serial issues away from
me and gave them other people to look at.  Reality is, I could have sorted
out the serial issues while I wait for responses from Dan Williams on the
async tx API issues.

Eventually, I got bored of waiting for Dan's responses, that I looked at
the serial issues anyway, and produced _my_ patch set which fixes the
issues _properly_, so at least I can say that I had done something producive.
The sad thing is, most of that is now having to be reworked to sort out an
entirely new set of problems caused by TI's attitude towards this stuff,
and this rework is consuming a lot more time than it needed to.

As for Dan, an update for the situation from Monday's call.  I have a reply
to my email I sent during that call, and Dan is looking at getting back up
to speed with DMA engine stuff - but he no longer has the hardware.  He
seems to want to keep hold of the responsibility for that, so I think we're
rather stuck at the moment over anything OMAP which uses the crypto stuff.

That's fine for the time being; the schedule for the removal of the legacy
OMAP DMA stuff that I put into feature-removal.txt says "2013" and I _never_
intended that to mean the start of 2013.
--
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 4/4] MMC: omap_hsmmc: add DT property for max bus frequency

[Daniel Mack]

On 12.10.2012 17:25, Rob Herring wrote:
> On 10/12/2012 05:58 AM, Daniel Mack wrote:
>> Maximum bus frequency can be limited by external circuitry like level
>> shifters etc. Allow passing this value from DT.
>>
>> Signed-off-by: Daniel Mack 
>> Cc: Venkatraman S 
>> Cc: Chris Ball 
>> Cc: Grant Likely 
>> Cc: Rob Herring 
>> Cc: linux-omap@vger.kernel.org
>> ---
>>  drivers/mmc/host/omap_hsmmc.c | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
>> index 86f0759..4650ef7 100644
>> --- a/drivers/mmc/host/omap_hsmmc.c
>> +++ b/drivers/mmc/host/omap_hsmmc.c
>> @@ -1676,7 +1676,7 @@ static struct omap_mmc_platform_data 
>> *of_get_hsmmc_pdata(struct device *dev)
>>  {
>>  struct omap_mmc_platform_data *pdata;
>>  struct device_node *np = dev->of_node;
>> -u32 bus_width;
>> +u32 bus_width, max_freq;
>>  
>>  pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>>  if (!pdata)
>> @@ -1703,6 +1703,9 @@ static struct omap_mmc_platform_data 
>> *of_get_hsmmc_pdata(struct device *dev)
>>  if (of_find_property(np, "ti,needs-special-reset", NULL))
>>  pdata->slots[0].features |= HSMMC_HAS_UPDATED_RESET;
>>  
>> +if (!of_property_read_u32(np, "max-frequency", &max_freq))
>> +pdata->max_freq = max_freq;
>> +
> 
> Is this property documented?

Yes, in the generic part. Forgot to mention that.

  Documentation/devicetree/bindings/mmc/mmc.txt


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] MMC: omap_hsmmc: add DT property for max bus frequency

[Rob Herring]

On 10/12/2012 05:58 AM, Daniel Mack wrote:
> Maximum bus frequency can be limited by external circuitry like level
> shifters etc. Allow passing this value from DT.
> 
> Signed-off-by: Daniel Mack 
> Cc: Venkatraman S 
> Cc: Chris Ball 
> Cc: Grant Likely 
> Cc: Rob Herring 
> Cc: linux-omap@vger.kernel.org
> ---
>  drivers/mmc/host/omap_hsmmc.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 86f0759..4650ef7 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -1676,7 +1676,7 @@ static struct omap_mmc_platform_data 
> *of_get_hsmmc_pdata(struct device *dev)
>  {
>   struct omap_mmc_platform_data *pdata;
>   struct device_node *np = dev->of_node;
> - u32 bus_width;
> + u32 bus_width, max_freq;
>  
>   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>   if (!pdata)
> @@ -1703,6 +1703,9 @@ static struct omap_mmc_platform_data 
> *of_get_hsmmc_pdata(struct device *dev)
>   if (of_find_property(np, "ti,needs-special-reset", NULL))
>   pdata->slots[0].features |= HSMMC_HAS_UPDATED_RESET;
>  
> + if (!of_property_read_u32(np, "max-frequency", &max_freq))
> + pdata->max_freq = max_freq;
> +

Is this property documented?

Rob

>   return pdata;
>  }
>  #else
> 
--
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/4] MMC: omap_hsmmc: set platform data after probe from DT node

[Balaji T K]

On Friday 12 October 2012 08:44 PM, Daniel Mack wrote:

On 12.10.2012 16:56, Balaji T K wrote:

On Friday 12 October 2012 07:59 PM, Daniel Mack wrote:

On 12.10.2012 12:58, Daniel Mack wrote:

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 19ccb59..4b70823 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1728,6 +1728,7 @@ static int __devinit omap_hsmmc_probe(struct 
platform_device *pdev)
const u16 *offsetp = match->data;
pdata->reg_offset = *offsetp;
}
+   pdev->dev.platform_data = pdata;
}

if (pdata == NULL) {



FWIW, this is the Oops I see without this patch:

Hi,
Shouldn't pdev->dev.platform_data be set to NULL on _remove ?


Why?


To make sure on second insmod it is NULL, When built as module,
So that of_get_hsmmc_pdata is called to create pdata.




BTW, I posted a patch for the same by accessing saved version from
host->pdata
http://permalink.gmane.org/gmane.linux.kernel.mmc/16996


Ok, that's another solution. I thought about this too, but then chose
the easier way :) I don't care which patch is taken, as long as we have
a fix in mainline.



Agree this patch is easiest :-)



Thanks,
Daniel


--
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/4] MMC: omap_hsmmc: set platform data after probe from DT node

[Daniel Mack]

On 12.10.2012 16:56, Balaji T K wrote:
> On Friday 12 October 2012 07:59 PM, Daniel Mack wrote:
>> On 12.10.2012 12:58, Daniel Mack wrote:
>>> When probed from DT, the self-allocated platform data has to be attached
>>> to the actual device. Otherwise a NULL pointer will be dereferenced from
>>> omap_hsmmc_card_detect if a gpio handle for card-detect has been passed.
>>>
>>> Signed-off-by: Daniel Mack 
>>> Cc: Venkatraman S 
>>> Cc: Chris Ball 
>>> Cc: Grant Likely 
>>> Cc: Rob Herring 
>>> Cc: linux-omap@vger.kernel.org
>>> ---
>>>   drivers/mmc/host/omap_hsmmc.c | 1 +
>>>   1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
>>> index 19ccb59..4b70823 100644
>>> --- a/drivers/mmc/host/omap_hsmmc.c
>>> +++ b/drivers/mmc/host/omap_hsmmc.c
>>> @@ -1728,6 +1728,7 @@ static int __devinit omap_hsmmc_probe(struct 
>>> platform_device *pdev)
>>> const u16 *offsetp = match->data;
>>> pdata->reg_offset = *offsetp;
>>> }
>>> +   pdev->dev.platform_data = pdata;
>>> }
>>>
>>> if (pdata == NULL) {
>>>
>>
>> FWIW, this is the Oops I see without this patch:
> Hi,
> Shouldn't pdev->dev.platform_data be set to NULL on _remove ?

Why?

> BTW, I posted a patch for the same by accessing saved version from 
> host->pdata
> http://permalink.gmane.org/gmane.linux.kernel.mmc/16996

Ok, that's another solution. I thought about this too, but then chose
the easier way :) I don't care which patch is taken, as long as we have
a fix in mainline.


Thanks,
Daniel

--
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/4] usb: phy: add a new driver for usb3 phy

[Tony Lindgren]

* kishon  [121012 02:10]:
> Hi Tony,
> 
> On Thursday 11 October 2012 06:29 AM, Tony Lindgren wrote:
> >Hi,
> >
> >* Kishon Vijay Abraham I  [120919 04:32]:
> >>Added a driver for usb3 phy that handles the interaction between usb phy
> >>device and dwc3 controller.
> >>
> >>This also includes device tree support for usb3 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.
> >
> >You may be able to set up the control module register with one
> >of the following Linux standard frameworks:
> >
> >1. Fixed regulator defined in mach-omap2/control.c
> 
> Is it control.c?

Hmm after looking into it more we're missing one piece of the puzzle
to handle SCM regulators, which is omap-scm-regulator.c :)
I'll do a minimal DT only version of that.

> >In this case the PHY driver can pick up the regulator by name.
> 
> Do you mean we have to define something like fixed_voltage_config
> defined in board-4430sdp.c?
> From whatever I could make out from regulator/fixed.c,
> enabling/disabling of regulator is done using only gpio. I'm not
> sure how we can use that to write to control module register.

Yes you're right, we're missing omap-scm-regulator.c, then it will
be trivial to select the regulator from DT like we have for the
twl-regulator.c.

> >>+usb3phy@4a084400 {
> >>+   compatible = "ti,omap-usb3";
> >>+   reg = <0x0x4a084400 0x80>,
> >>+ <0x4a084800 0x64>,
> >>+ <0x4a084c00 0x40>,
> >>+ <0x4a002370 0x4>;
> >>+};
> >
> >And register 0x4a002370 here. Care to post some info what the
> >0x4a002370 register bits do? Is that same as CONTROL_DEV_CONF
> >on omap4, or does it have other bits there too?
> 
> It's CONTROL_PHY_POWER_USB register and it's structure looks like this.
> 31:22 USB_PWRCTL_CLK_FREQ
> 21:14 USB_PWRCTL_CLK_CMD
> 13:0 RESERVED
> 
> CLK_CMD takes values to power up/down the TX and RX in various combinations.
> 
> And CLK_FREQ takes values for clock configuration.

Oh, it's a clock. Then it would be best to set it up using the
common clock framework and have the clock registered by the
SCM core driver when those are available.

Maybe please just add a comment for that for later on?

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/4] MMC: omap_hsmmc: set platform data after probe from DT node

[Balaji T K]

On Friday 12 October 2012 07:59 PM, Daniel Mack wrote:

On 12.10.2012 12:58, Daniel Mack wrote:

When probed from DT, the self-allocated platform data has to be attached
to the actual device. Otherwise a NULL pointer will be dereferenced from
omap_hsmmc_card_detect if a gpio handle for card-detect has been passed.

Signed-off-by: Daniel Mack 
Cc: Venkatraman S 
Cc: Chris Ball 
Cc: Grant Likely 
Cc: Rob Herring 
Cc: linux-omap@vger.kernel.org
---
  drivers/mmc/host/omap_hsmmc.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 19ccb59..4b70823 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1728,6 +1728,7 @@ static int __devinit omap_hsmmc_probe(struct 
platform_device *pdev)
const u16 *offsetp = match->data;
pdata->reg_offset = *offsetp;
}
+   pdev->dev.platform_data = pdata;
}

if (pdata == NULL) {



FWIW, this is the Oops I see without this patch:

Hi,
Shouldn't pdev->dev.platform_data be set to NULL on _remove ?

BTW, I posted a patch for the same by accessing saved version from 
host->pdata

http://permalink.gmane.org/gmane.linux.kernel.mmc/16996




[1.492727] Unable to handle kernel NULL pointer dereference at
virtual address 0040
[1.501327] pgd = c0004000
[1.504166] [0040] *pgd=
[1.507993] Internal error: Oops: 5 [#1] SMP THUMB2
[1.513100] Modules linked in:
[1.516315] CPU: 0Not tainted  (3.6.0-10656-g4bc7e4d-dirty #75)
[1.522890] PC is at omap_hsmmc_card_detect+0x6/0x18
[1.528090] LR is at omap_hsmmc_get_cd+0x1d/0x24
[1.532929] pc : []lr : []psr: 4133
[1.532929] sp : cf1b5e78  ip : 0c288145  fp : 0002
[1.544939] r10: cf1b4000  r9 : cf1b5eb8  r8 : 
[1.550408] r7 : cf1a4600  r6 : 6113  r5 : cf33ba98  r4 : cf33b800
[1.557240] r3 :   r2 :   r1 :   r0 : cf0d1c10
[1.564075] Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA Thumb
Segment kernel
[1.571906] Control: 50c5387d  Table: 80004019  DAC: 0015
[1.577921] Process kworker/u:1 (pid: 19, stack limit = 0xcf1b4240)
[1.584480] Stack: (0xcf1b5e78 to 0xcf1b6000)
[1.589045] 5e60:
c025a3e9 c0259fed
[1.597611] 5e80: c0259fd1 c024f959 cf33bb0c cf1a5dc0 c05c87c0
c003a42f 0002 
[1.606176] 5ea0: c003a3d8 c005e181 cf1b35c0  
c024f829 c0adfe68 c0687048
[1.614741] 5ec0:  c0494f78 c05c8780 cf1a5dc0 c05c88e8
cf1b4000 c05c88f0 cf1a5dd0
[1.623306] 5ee0: c0531f40 c053d678 c05c8780 c003c2ab cf1b5f18
c005e935 c05c87c0 c0531f40
[1.631872] 5f00: c0531f40 c7e3f1f9 cf1b5f34 cf069e20 cf1b5f34
 cf1a5dc0 c003c191
[1.640436] 5f20:    c003f809 
  cf1a5dc0
[1.649001] 5f40:   dead4ead  
c05c8ef8  
[1.657565] 5f60: c0455c08 cf1b5f64 cf1b5f64  
dead4ead  
[1.666130] 5f80: c05c8ef8   c0455c08 cf1b5f90
cf1b5f90 cf069e20 c003f791
[1.674694] 5fa0:    c000d1e1 aaa3aaab
b1ba aae3ea32 aba2a3aa
[1.683260] 5fc0: baaababe bbbaaaba aa2b bb2e2aba aabaa2bb
aaabb2bb aaabbaf3 f3bb2aaa
[1.691824] 5fe0: aabaabba 23ae2beb a2afab2a b2a2ab2a 0013
aaabaaab bfaf a0a2
[1.700399] [] (omap_hsmmc_card_detect+0x6/0x18) from
[] (omap_hsmmc_get_cd+0x1d/0x24)
[1.710528] [] (omap_hsmmc_get_cd+0x1d/0x24) from
[] (mmc_rescan+0x131/0x1e4)
[1.719842] [] (mmc_rescan+0x131/0x1e4) from []
(process_one_work+0x137/0x37c)
[1.729234] [] (process_one_work+0x137/0x37c) from
[] (worker_thread+0x11b/0x364)
[1.738899] [] (worker_thread+0x11b/0x364) from
[] (kthread+0x79/0x84)
[1.747572] [] (kthread+0x79/0x84) from []
(ret_from_kernel_thread+0xd/0x14)
[1.756773] Code: bf00 b508 f8d0 3084 (6c18) f75f
[1.761943] ---[ end trace b94c447c4835422d ]---

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" 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: [RFC 00/24] OMAP serial driver flow control fixes, and preparation for DMA engine conversion

[Grazvydas Ignotas]

On Thu, Oct 11, 2012 at 1:21 PM, Sourav  wrote:
> If you have any pointers on how to test hardware flow control, I will like
> to do that on my beagle board.

If you can find some board with BT chip connected to UART, that would
be a good test as they usually have flow control lines connected and
can run at high bitrates. I think some EVM or Zoom boards have BT
chips.


-- 
Gražvydas
--
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] ARM: OMAP: i2c: fix interrupt flood during resume

[Strashko, Grygorii]

Hi Kevin,

yep, [1] is the same fix - thanks. 

Hi Kalle,

i've applied these changes and PM runtime fix on top of 
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git 
(omap2plus_defconfig)
Could you check it with your use case, pls? (just to be sure that idea is right)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index a0e49f6..cb09e20 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -586,6 +586,9 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg 
msgs[], int num)
if (IS_ERR_VALUE(r))
goto out;
 
+   /* We have the bus, enable IRQ */
+   enable_irq(dev->irq);
+
r = omap_i2c_wait_for_bb(dev);
if (r < 0)
goto out;
@@ -606,6 +609,7 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg 
msgs[], int num)
r = num;
 
omap_i2c_wait_for_bb(dev);
+   disable_irq(dev->irq);
 out:
pm_runtime_put(dev->dev);
return r;
@@ -1060,6 +1064,9 @@ omap_i2c_probe(struct platform_device *pdev)
   omap_i2c_isr;
r = request_irq(dev->irq, isr, IRQF_NO_SUSPEND, pdev->name, dev);
 
+   /* We enable IRQ only when request for I2C from master */
+disable_irq(dev->irq);
+
if (r) {
dev_err(dev->dev, "failure requesting irq %i\n", dev->irq);
goto err_unuse_clocks;
@@ -1182,7 +1189,23 @@ static int omap_i2c_runtime_resume(struct device *dev)
 }
 #endif /* CONFIG_PM_RUNTIME */
 
+static int omap_i2c_suspend(struct device *dev)
+{
+   int ret;
+
+   /*
+*  Enable I2C device, so it will be accessible during
+* later stages of suspending when device Runtime PM is disabled.
+* I2C device will be turned off at "noirq" suspend stage.
+*/
+   ret = pm_runtime_resume(dev);
+   if (ret < 0)
+   return ret;
+   return 0;
+}
+
 static struct dev_pm_ops omap_i2c_pm_ops = {
+   SET_SYSTEM_SLEEP_PM_OPS(omap_i2c_suspend, NULL)
SET_RUNTIME_PM_OPS(omap_i2c_runtime_suspend,
   omap_i2c_runtime_resume, NULL)
 };

- Grygorii

From: Kevin Hilman [khil...@deeprootsystems.com]
Sent: Friday, October 12, 2012 5:34 PM
To: Strashko, Grygorii
Cc: Kalle Jokiniemi; linux-...@vger.kernel.org; w.s...@pengutronix.de; 
ben-li...@fluff.org; t...@atomide.com; linux-omap@vger.kernel.org; Datta, 
Shubhrajyoti; Kankroliwala, Huzefa
Subject: Re: [PATCH v3] ARM: OMAP: i2c: fix interrupt flood during resume

"Strashko, Grygorii"  writes:

> Hi All,
>
> Sorry, for the late reply.
> + CC Huzefa Kankroliwala - who is I2C driver owner on Android Kernel 3.4.

Hi Grygorii, thanks for reviewing.  I was hoping you would have some
ideas here as this was sounding familiar to something you had
mentioned elsewhere.

> Regarding this patch -  from my point of view, it fixes corner case and not 
> an issue in general.
> Let take a look on resume sequence:
>- platform resume
>- syscore resume
>- resume_noirq
>- enable IRQs - resume_device_irqs()
>  |- at this point IRQ handler will be invoked if IRQ state is 
> IRQS_PENDING.
>  |- so, the I2C device IRQ handler may be called at time when I2C adapter 
> IRQ is still disabled and, as result, the I2C device IRQ-handler may fail. 
> (I2C device and I2C adapter may use different physical IRQ lines)
>- resume_late
>  |- enable I2C bus IRQ
>
> Possibly, the better way is to enable/disable I2C bus IRQ when needed - in 
> our case in omap_i2c_xfer().
> We use such approach in Android kernel 3.4
> (http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=1445a4d3b587c164bd30d108b6176007365e)

I agree, that should work and cover the cases where I2C is used by other
processors also.  Shubhrajyoti already posted something similar[1] but
it needed some rework (comments from Russell and myself.)

Huzefa, Shubhrajyoti, who can rework this idea for the upstream and/or
follow up with the earlier patch[1]?

Wolfram, I guess for now lets hold off on $SUBJECT patch.  Seems we can
come up with a broader solution.  Thanks.

Kevin

[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-October/124427.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 v3] ARM: OMAP: i2c: fix interrupt flood during resume

[Kevin Hilman]

"Strashko, Grygorii"  writes:

> Hi All,
>
> Sorry, for the late reply.
> + CC Huzefa Kankroliwala - who is I2C driver owner on Android Kernel 3.4.

Hi Grygorii, thanks for reviewing.  I was hoping you would have some
ideas here as this was sounding familiar to something you had
mentioned elsewhere.

> Regarding this patch -  from my point of view, it fixes corner case and not 
> an issue in general.
> Let take a look on resume sequence:
>- platform resume
>- syscore resume
>- resume_noirq
>- enable IRQs - resume_device_irqs()
>  |- at this point IRQ handler will be invoked if IRQ state is 
> IRQS_PENDING.
>  |- so, the I2C device IRQ handler may be called at time when I2C adapter 
> IRQ is still disabled and, as result, the I2C device IRQ-handler may fail. 
> (I2C device and I2C adapter may use different physical IRQ lines)
>- resume_late
>  |- enable I2C bus IRQ
>
> Possibly, the better way is to enable/disable I2C bus IRQ when needed - in 
> our case in omap_i2c_xfer().
> We use such approach in Android kernel 3.4
> (http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=1445a4d3b587c164bd30d108b6176007365e)

I agree, that should work and cover the cases where I2C is used by other
processors also.  Shubhrajyoti already posted something similar[1] but
it needed some rework (comments from Russell and myself.)

Huzefa, Shubhrajyoti, who can rework this idea for the upstream and/or
follow up with the earlier patch[1]?

Wolfram, I guess for now lets hold off on $SUBJECT patch.  Seems we can
come up with a broader solution.  Thanks.

Kevin

[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-October/124427.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 1/4] MMC: omap_hsmmc: set platform data after probe from DT node

[Daniel Mack]

On 12.10.2012 12:58, Daniel Mack wrote:
> When probed from DT, the self-allocated platform data has to be attached
> to the actual device. Otherwise a NULL pointer will be dereferenced from
> omap_hsmmc_card_detect if a gpio handle for card-detect has been passed.
> 
> Signed-off-by: Daniel Mack 
> Cc: Venkatraman S 
> Cc: Chris Ball 
> Cc: Grant Likely 
> Cc: Rob Herring 
> Cc: linux-omap@vger.kernel.org
> ---
>  drivers/mmc/host/omap_hsmmc.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 19ccb59..4b70823 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -1728,6 +1728,7 @@ static int __devinit omap_hsmmc_probe(struct 
> platform_device *pdev)
>   const u16 *offsetp = match->data;
>   pdata->reg_offset = *offsetp;
>   }
> + pdev->dev.platform_data = pdata;
>   }
>  
>   if (pdata == NULL) {
> 

FWIW, this is the Oops I see without this patch:

[1.492727] Unable to handle kernel NULL pointer dereference at
virtual address 0040
[1.501327] pgd = c0004000
[1.504166] [0040] *pgd=
[1.507993] Internal error: Oops: 5 [#1] SMP THUMB2
[1.513100] Modules linked in:
[1.516315] CPU: 0Not tainted  (3.6.0-10656-g4bc7e4d-dirty #75)
[1.522890] PC is at omap_hsmmc_card_detect+0x6/0x18
[1.528090] LR is at omap_hsmmc_get_cd+0x1d/0x24
[1.532929] pc : []lr : []psr: 4133
[1.532929] sp : cf1b5e78  ip : 0c288145  fp : 0002
[1.544939] r10: cf1b4000  r9 : cf1b5eb8  r8 : 
[1.550408] r7 : cf1a4600  r6 : 6113  r5 : cf33ba98  r4 : cf33b800
[1.557240] r3 :   r2 :   r1 :   r0 : cf0d1c10
[1.564075] Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA Thumb
Segment kernel
[1.571906] Control: 50c5387d  Table: 80004019  DAC: 0015
[1.577921] Process kworker/u:1 (pid: 19, stack limit = 0xcf1b4240)
[1.584480] Stack: (0xcf1b5e78 to 0xcf1b6000)
[1.589045] 5e60:
   c025a3e9 c0259fed
[1.597611] 5e80: c0259fd1 c024f959 cf33bb0c cf1a5dc0 c05c87c0
c003a42f 0002 
[1.606176] 5ea0: c003a3d8 c005e181 cf1b35c0  
c024f829 c0adfe68 c0687048
[1.614741] 5ec0:  c0494f78 c05c8780 cf1a5dc0 c05c88e8
cf1b4000 c05c88f0 cf1a5dd0
[1.623306] 5ee0: c0531f40 c053d678 c05c8780 c003c2ab cf1b5f18
c005e935 c05c87c0 c0531f40
[1.631872] 5f00: c0531f40 c7e3f1f9 cf1b5f34 cf069e20 cf1b5f34
 cf1a5dc0 c003c191
[1.640436] 5f20:    c003f809 
  cf1a5dc0
[1.649001] 5f40:   dead4ead  
c05c8ef8  
[1.657565] 5f60: c0455c08 cf1b5f64 cf1b5f64  
dead4ead  
[1.666130] 5f80: c05c8ef8   c0455c08 cf1b5f90
cf1b5f90 cf069e20 c003f791
[1.674694] 5fa0:    c000d1e1 aaa3aaab
b1ba aae3ea32 aba2a3aa
[1.683260] 5fc0: baaababe bbbaaaba aa2b bb2e2aba aabaa2bb
aaabb2bb aaabbaf3 f3bb2aaa
[1.691824] 5fe0: aabaabba 23ae2beb a2afab2a b2a2ab2a 0013
aaabaaab bfaf a0a2
[1.700399] [] (omap_hsmmc_card_detect+0x6/0x18) from
[] (omap_hsmmc_get_cd+0x1d/0x24)
[1.710528] [] (omap_hsmmc_get_cd+0x1d/0x24) from
[] (mmc_rescan+0x131/0x1e4)
[1.719842] [] (mmc_rescan+0x131/0x1e4) from []
(process_one_work+0x137/0x37c)
[1.729234] [] (process_one_work+0x137/0x37c) from
[] (worker_thread+0x11b/0x364)
[1.738899] [] (worker_thread+0x11b/0x364) from
[] (kthread+0x79/0x84)
[1.747572] [] (kthread+0x79/0x84) from []
(ret_from_kernel_thread+0xd/0x14)
[1.756773] Code: bf00 b508 f8d0 3084 (6c18) f75f
[1.761943] ---[ end trace b94c447c4835422d ]---

--
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/4] MMC: omap_hsmmc: fix DMA config block

[Daniel Mack]

On 12.10.2012 13:12, Russell King - ARM Linux wrote:
> On Fri, Oct 12, 2012 at 12:58:13PM +0200, Daniel Mack wrote:
>> The .direction field of the config passed to dmaengine_slave_config()
>> must be set in order to make the generic code store the configured bus
>> width.
> 
> NAK.  The direction field is deprecated, and should not be used anymore.
> 

Yes, thanks for the heads-up. Matt already pointed me to an updated
series of his EDMA patches, so this patch can be dropped.

--
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] ARM: OMAP: i2c: fix interrupt flood during resume

[Kevin Hilman]

"Strashko, Grygorii"  writes:

> Hi All,
>
> Sorry, for the late reply.
> + CC Huzefa Kankroliwala - who is I2C driver owner on Android Kernel 3.4.

Hi Grygorii, thanks for reviewing.  I was hoping you would have some
ideas here as this was sounding familiar to something you had mentioned
elsewhere.

> Regarding this patch -  from my point of view, it fixes corner case and not 
> an issue in general.
> Let take a look on resume sequence:
>- platform resume
>- syscore resume
>- resume_noirq
>- enable IRQs - resume_device_irqs()
>  |- at this point IRQ handler will be invoked if IRQ state is 
> IRQS_PENDING.
>  |- so, the I2C device IRQ handler may be called at time when I2C adapter 
> IRQ is still disabled and, as result, the I2C device IRQ-handler may fail. 
> (I2C device and I2C adapter may use different physical IRQ lines)
>- resume_late
>  |- enable I2C bus IRQ
>
> Possibly, the better way is to enable/disable I2C bus IRQ when needed - in 
> our case in omap_i2c_xfer().
> We use such approach in Android kernel 3.4
> (http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=1445a4d3b587c164bd30d108b6176007365e)

I agree, that should work and cover the cases where I2C is used by other
processors also.  Shubhrajyoti already posted something similar[1] but
it needed some rework (comments from Russell and myself.)

Huzefa, Shubhrajyoti, who can rework this idea for the upstream driver
and submit a patch?

Wolfram, I guess for now lets hold off on $SUBJECT patch.  Seems we can
come up with a broader solution.  Thanks.

Kevin

[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-October/124427.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 1/3] usb: dwc3: Add the suspend/resume functionality

[Vikas Sajjan]

Hi kishon,

On 12 October 2012 16:27, kishon  wrote:
> Hi,
>
>
> On Wednesday 10 October 2012 07:35 PM, Vikas C Sajjan wrote:
>>
>> From: Vikas Sajjan 
>>
>> Adding the suspend and resume funtionality to DWC3 core.
>>
>> Signed-off-by: Abhilash Kesavan 
>> Signed-off-by: Vikas C Sajjan 
>> CC: Doug Anderson 
>> ---
>>   drivers/usb/dwc3/core.c |  268
>> +-
>>   1 files changed, 169 insertions(+), 99 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>> index b415c0c..58b51e1 100644
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>>
>> @@ -70,51 +70,20 @@ MODULE_PARM_DESC(maximum_speed, "Maximum supported
>> speed.");
>>
>>   static DECLARE_BITMAP(dwc3_devs, DWC3_DEVS_POSSIBLE);
>>
>> -int dwc3_get_device_id(void)
>> -{
>> -   int id;
>> -
>> -again:
>> -   id = find_first_zero_bit(dwc3_devs, DWC3_DEVS_POSSIBLE);
>> -   if (id < DWC3_DEVS_POSSIBLE) {
>> -   int old;
>> -
>> -   old = test_and_set_bit(id, dwc3_devs);
>> -   if (old)
>> -   goto again;
>> -   } else {
>> -   pr_err("dwc3: no space for new device\n");
>> -   id = -ENOMEM;
>> -   }
>> -
>> -   return id;
>> -}
>> -EXPORT_SYMBOL_GPL(dwc3_get_device_id);
>> -
>> -void dwc3_put_device_id(int id)
>> -{
>> -   int ret;
>> -
>> -   if (id < 0)
>> -   return;
>> -
>> -   ret = test_bit(id, dwc3_devs);
>> -   WARN(!ret, "dwc3: ID %d not in use\n", id);
>> -   smp_mb__before_clear_bit();
>> -   clear_bit(id, dwc3_devs);
>> -}
>> -EXPORT_SYMBOL_GPL(dwc3_put_device_id);
>> -
>> -void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
>> +static void __devinit dwc3_cache_hwparams(struct dwc3 *dwc)
>>   {
>> -   u32 reg;
>> +   struct dwc3_hwparams*parms = &dwc->hwparams;
>>
>> -   reg = dwc3_readl(dwc->regs, DWC3_GCTL);
>> -   reg &= ~(DWC3_GCTL_PRTCAPDIR(DWC3_GCTL_PRTCAP_OTG));
>> -   reg |= DWC3_GCTL_PRTCAPDIR(mode);
>> -   dwc3_writel(dwc->regs, DWC3_GCTL, reg);
>> +   parms->hwparams0 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS0);
>> +   parms->hwparams1 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS1);
>> +   parms->hwparams2 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS2);
>> +   parms->hwparams3 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS3);
>> +   parms->hwparams4 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS4);
>> +   parms->hwparams5 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS5);
>> +   parms->hwparams6 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS6);
>> +   parms->hwparams7 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS7);
>> +   parms->hwparams8 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS8);
>>   }
>> -
>>   /**
>>* dwc3_core_soft_reset - Issues core soft reset and PHY reset
>>* @dwc: pointer to our context structure
>> @@ -160,6 +129,102 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
>> dwc3_writel(dwc->regs, DWC3_GCTL, reg);
>>   }
>>
>> +static int dwc3_core_reset(struct dwc3 *dwc)
>> +{
>> +   unsigned long   timeout;
>> +   u32 reg;
>> +
>> +   /* issue device SoftReset too */
>> +   timeout = jiffies + msecs_to_jiffies(500);
>> +   dwc3_writel(dwc->regs, DWC3_DCTL, DWC3_DCTL_CSFTRST);
>> +   do {
>> +   reg = dwc3_readl(dwc->regs, DWC3_DCTL);
>> +   if (!(reg & DWC3_DCTL_CSFTRST))
>> +   break;
>> +
>> +   if (time_after(jiffies, timeout)) {
>> +   dev_err(dwc->dev, "Reset Timed Out\n");
>> +   return -ETIMEDOUT;
>> +   }
>> +
>> +   cpu_relax();
>> +   } while (true);
>> +
>> +   dwc3_core_soft_reset(dwc);
>> +
>> +   dwc3_cache_hwparams(dwc);
>> +
>> +   reg = dwc3_readl(dwc->regs, DWC3_GCTL);
>> +   reg &= ~DWC3_GCTL_SCALEDOWN_MASK;
>> +   reg &= ~DWC3_GCTL_DISSCRAMBLE;
>> +
>> +   switch (DWC3_GHWPARAMS1_EN_PWROPT(dwc->hwparams.hwparams1)) {
>> +   case DWC3_GHWPARAMS1_EN_PWROPT_CLK:
>> +   reg &= ~DWC3_GCTL_DSBLCLKGTNG;
>> +   break;
>> +   default:
>> +   dev_dbg(dwc->dev, "No power optimization available\n");
>> +   }
>> +
>> +   /*
>>
>> +* WORKAROUND: DWC3 revisions <1.90a have a bug
>> +* where the device can fail to connect at SuperSpeed
>> +* and falls back to high-speed mode which causes
>> +* the device to enter a Connect/Disconnect loop
>> +*/
>> +   if (dwc->revision < DWC3_REVISION_190A)
>> +   reg |= DWC3_GCTL_U2RSTECN;
>> +
>> +   dwc3_writel(dwc->regs, DWC3_GCTL, reg);
>> +
>> +   return 0;
>> +}
>> +
>> +int dwc3_get_device_id(void)
>> +{
>> +   int id;
>> +
>> +again:
>> +   id = find_first_zero_bit(dwc3_devs, DWC3_DEVS_POSSIBLE);
>> +   if (id < DWC3_DEVS_POSSIBLE) {
>> +   int old;
>> +
>> +   old = t

RE: [PATCH v3] ARM: OMAP: i2c: fix interrupt flood during resume

[Kalle Jokiniemi]

Hi,

pe, 2012-10-12 kello 10:18 +, Strashko, Grygorii kirjoitti:
> Hi All,
> 
> Sorry, for the late reply.
> + CC Huzefa Kankroliwala - who is I2C driver owner on Android Kernel 3.4.
> 
> Regarding this patch -  from my point of view, it fixes corner case and not 
> an issue in general.
> Let take a look on resume sequence:
>- platform resume
>- syscore resume
>- resume_noirq
>- enable IRQs - resume_device_irqs()
>  |- at this point IRQ handler will be invoked if IRQ state is 
> IRQS_PENDING.
>  |- so, the I2C device IRQ handler may be called at time when I2C
>   adapter IRQ is still disabled and, as result, the I2C device
>   IRQ-handler may fail. (I2C device and I2C adapter may use different
>   physical IRQ lines)

The use case is to wake up the the device from suspend via twl4030 power
key line. The twl4030 then will interrupt host via the i2c bus. And on
the host the i2c bus is then read by the twl4030-pwrkey threaded SW
interrupt (which is disabled at the point when i2c bus HW interrupt
occurs).


>   - resume_late
>  |- enable I2C bus IRQ
> 
> Possibly, the better way is to enable/disable I2C bus IRQ when needed - in 
> our case in omap_i2c_xfer().
> We use such approach in Android kernel 3.4
> (http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=1445a4d3b587c164bd30d108b6176007365e)

Sounds like it could work... however I tested the patch above, but my
device now dies when waking it from suspend (autosleep, actually) with
power key :(

Have you guys considered reworking that patch for upstream? There seems
to be some spinlocking there that was not in linux-omap that I tested
on.

- Kalle

> 
> Grygorii
> 
> From: Kevin Hilman [khil...@deeprootsystems.com]
> Sent: Friday, October 12, 2012 12:08 AM
> To: Kalle Jokiniemi
> Cc: linux-...@vger.kernel.org; w.s...@pengutronix.de; ben-li...@fluff.org; 
> t...@atomide.com; linux-omap@vger.kernel.org; Strashko, Grygorii; Datta, 
> Shubhrajyoti
> Subject: Re: [PATCH v3] ARM: OMAP: i2c: fix interrupt flood during resume
> 
> Hi Kalle,
> 
> Kalle Jokiniemi  writes:
> 
> > The resume_noirq enables interrupts one-by-one starting from
> > first one. Now if the wake up event for suspend came from i2c
> > device, the i2c bus irq gets enabled before the threaded
> > i2c device irq, causing a flood of i2c bus interrupts as the
> > threaded irq that should clear the event is not enabled yet.
> >
> > Fixed the issue by adding suspend_noirq and resume_early
> > functions that keep i2c bus interrupts disabled until
> > resume_noirq has run completely.
> >
> > Issue was detected doing a wake up from autosleep with
> > twl4030 power key on N9. Patch tested on N9.
> >
> > Signed-off-by: Kalle Jokiniemi 
> 
> This version looks good, thanks for the extra comments.
> 
> Reviewed-by: Kevin Hilman 
> Tested-by: Kevin Hilman 
> 
> Wolfram, This should also probably be Cc'd to stable since it affects
> earlier kernels as well.  Thanks,
> 
> Kevin
> 
> > ---
> >  drivers/i2c/busses/i2c-omap.c |   34 ++
> >  1 files changed, 34 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> > index a0e49f6..991341b 100644
> > --- a/drivers/i2c/busses/i2c-omap.c
> > +++ b/drivers/i2c/busses/i2c-omap.c
> > @@ -1132,6 +1132,36 @@ static int __devexit omap_i2c_remove(struct 
> > platform_device *pdev)
> >  }
> >
> >  #ifdef CONFIG_PM
> > +#ifdef CONFIG_PM_SLEEP
> > +static int omap_i2c_suspend_noirq(struct device *dev)
> > +{
> > +
> > + struct platform_device *pdev = to_platform_device(dev);
> > + struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
> > +
> > + /* Disabling irq here to balance the enable in resume_early */
> > + disable_irq(_dev->irq);
> > + return 0;
> > +}
> > +
> > +static int omap_i2c_resume_early(struct device *dev)
> > +{
> > +
> > + struct platform_device *pdev = to_platform_device(dev);
> > + struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
> > +
> > + /*
> > +  * The noirq_resume enables the interrupts one by one,
> > +  * this causes a interrupt flood if the SW irq actually reading
> > +  * event from i2c device is enabled only after i2c bus irq, as the
> > +  * irq that should clear the event is still disabled. We have to
> > +  * keep the bus irq disabled until all other irqs have been enabled.
> > +  */
> > + enable_irq(_dev->irq);
> > +
> > + return 0;
> > +}
> > +#endif
> >  #ifdef CONFIG_PM_RUNTIME
> >  static int omap_i2c_runtime_suspend(struct device *dev)
> >  {
> > @@ -1183,6 +1213,10 @@ static int omap_i2c_runtime_resume(struct device 
> > *dev)
> >  #endif /* CONFIG_PM_RUNTIME */
> >
> >  static struct dev_pm_ops omap_i2c_pm_ops = {
> > +#ifdef CONFIG_PM_SLEEP
> > + .suspend_noirq = omap_i2c_suspend_noirq,
> > + .resume_early = omap_i2c_resume_early,
> > +#endif
> >   SET_RUNTIME_PM_OPS(om

[PATCH 2/2] ARM: config: make sure that platforms are ordered by option string

[Russell King]

The large platform selection choice should be sorted by option string
so it's easy to find the platform you're looking for.  Fix the few
options which are out of this order.

Signed-off-by: Russell King 
---
 arch/arm/Kconfig |   76 +++---
 1 files changed, 38 insertions(+), 38 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index bd12ddd..1bc092e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -348,16 +348,6 @@ config ARCH_BCM2835
  This enables support for the Broadcom BCM2835 SoC. This SoC is
  use in the Raspberry Pi, and Roku 2 devices.
 
-config ARCH_CLPS711X
-   bool "Cirrus Logic CLPS711x/EP721x/EP731x-based"
-   select ARCH_USES_GETTIMEOFFSET
-   select CLKDEV_LOOKUP
-   select COMMON_CLK
-   select CPU_ARM720T
-   select NEED_MACH_MEMORY_H
-   help
- Support for Cirrus Logic 711x/721x/731x based boards.
-
 config ARCH_CNS3XXX
bool "Cavium Networks CNS3XXX family"
select ARM_GIC
@@ -369,6 +359,16 @@ config ARCH_CNS3XXX
help
  Support for Cavium Networks CNS3XXX platform.
 
+config ARCH_CLPS711X
+   bool "Cirrus Logic CLPS711x/EP721x/EP731x-based"
+   select ARCH_USES_GETTIMEOFFSET
+   select CLKDEV_LOOKUP
+   select COMMON_CLK
+   select CPU_ARM720T
+   select NEED_MACH_MEMORY_H
+   help
+ Support for Cirrus Logic 711x/721x/731x based boards.
+
 config ARCH_GEMINI
bool "Cortina Systems Gemini"
select ARCH_REQUIRE_GPIOLIB
@@ -549,21 +549,6 @@ config ARCH_KIRKWOOD
  Support for the following Marvell Kirkwood series SoCs:
  88F6180, 88F6192 and 88F6281.
 
-config ARCH_LPC32XX
-   bool "NXP LPC32XX"
-   select ARCH_REQUIRE_GPIOLIB
-   select ARM_AMBA
-   select CLKDEV_LOOKUP
-   select CLKSRC_MMIO
-   select CPU_ARM926T
-   select GENERIC_CLOCKEVENTS
-   select HAVE_IDE
-   select HAVE_PWM
-   select USB_ARCH_HAS_OHCI
-   select USE_OF
-   help
- Support for the NXP LPC32XX family of processors
-
 config ARCH_MV78XX0
bool "Marvell MV78xx0"
select ARCH_REQUIRE_GPIOLIB
@@ -630,6 +615,21 @@ config ARCH_W90X900
  
 
+config ARCH_LPC32XX
+   bool "NXP LPC32XX"
+   select ARCH_REQUIRE_GPIOLIB
+   select ARM_AMBA
+   select CLKDEV_LOOKUP
+   select CLKSRC_MMIO
+   select CPU_ARM926T
+   select GENERIC_CLOCKEVENTS
+   select HAVE_IDE
+   select HAVE_PWM
+   select USB_ARCH_HAS_OHCI
+   select USE_OF
+   help
+ Support for the NXP LPC32XX family of processors
+
 config ARCH_TEGRA
bool "NVIDIA Tegra"
select ARCH_HAS_CPUFREQ
@@ -823,7 +823,7 @@ config ARCH_S5PV210
  Samsung S5PV210/S5PC110 series based systems
 
 config ARCH_EXYNOS
-   bool "SAMSUNG EXYNOS"
+   bool "Samsung EXYNOS"
select ARCH_HAS_CPUFREQ
select ARCH_HAS_HOLES_MEMORYMODEL
select ARCH_SPARSEMEM_ENABLE
@@ -899,6 +899,18 @@ config ARCH_NOMADIK
help
  Support for the Nomadik platform by ST-Ericsson
 
+config PLAT_SPEAR
+   bool "ST SPEAr"
+   select ARCH_REQUIRE_GPIOLIB
+   select ARM_AMBA
+   select CLKDEV_LOOKUP
+   select CLKSRC_MMIO
+   select COMMON_CLK
+   select GENERIC_CLOCKEVENTS
+   select HAVE_CLK
+   help
+ Support for ST's SPEAr platform (SPEAr3xx, SPEAr6xx and SPEAr13xx).
+
 config ARCH_DAVINCI
bool "TI DaVinci"
select ARCH_HAS_HOLES_MEMORYMODEL
@@ -926,18 +938,6 @@ config ARCH_OMAP
help
  Support for TI's OMAP platform (OMAP1/2/3/4).
 
-config PLAT_SPEAR
-   bool "ST SPEAr"
-   select ARCH_REQUIRE_GPIOLIB
-   select ARM_AMBA
-   select CLKDEV_LOOKUP
-   select CLKSRC_MMIO
-   select COMMON_CLK
-   select GENERIC_CLOCKEVENTS
-   select HAVE_CLK
-   help
- Support for ST's SPEAr platform (SPEAr3xx, SPEAr6xx and SPEAr13xx).
-
 config ARCH_VT8500
bool "VIA/WonderMedia 85xx"
select ARCH_HAS_CPUFREQ
-- 
1.7.4.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 v3] ARM: OMAP: i2c: fix interrupt flood during resume

[Kankroliwala, Huzefa]

Shubro,
As Grygorii pointed out we had a generic issue of arm getting interrupted for 
i2c accesses outside it (IPU in case of omap4/omap5) and to avoid that we would 
enable/disable mpu level interrupts only when required from i2c-omap driver.

Regards
Huzefa

-Original Message-
From: Datta, Shubhrajyoti 
Sent: Friday, October 12, 2012 6:33 AM
To: Strashko, Grygorii
Cc: Kevin Hilman; Kalle Jokiniemi; linux-...@vger.kernel.org; 
w.s...@pengutronix.de; ben-li...@fluff.org; t...@atomide.com; 
linux-omap@vger.kernel.org; Kankroliwala, Huzefa
Subject: Re: [PATCH v3] ARM: OMAP: i2c: fix interrupt flood during resume

On Friday 12 October 2012 03:48 PM, Strashko, Grygorii wrote:
> Hi All,
>
> Sorry, for the late reply.
> + CC Huzefa Kankroliwala - who is I2C driver owner on Android Kernel 3.4.
>
> Regarding this patch
hmm I had similar ideas however my idea was to pacify the arm interrupts
when the ip is used by another processor.(something my hw spin patch missed)

Any-ways will wait for Huzefa to comment.


>  -  from my point of view, it fixes corner case and not an issue in general.
> Let take a look on resume sequence:
>- platform resume
>- syscore resume
>- resume_noirq
>- enable IRQs - resume_device_irqs()
>  |- at this point IRQ handler will be invoked if IRQ state is 
> IRQS_PENDING.
>  |- so, the I2C device IRQ handler may be called at time when I2C adapter 
> IRQ is still disabled and, as result, the I2C device IRQ-handler may fail. 
> (I2C device and I2C adapter may use different physical IRQ lines)
>- resume_late
>  |- enable I2C bus IRQ
>
> Possibly, the better way is to enable/disable I2C bus IRQ when needed - in 
> our case in omap_i2c_xfer().
> We use such approach in Android kernel 3.4
> (http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=1445a4d3b587c164bd30d108b6176007365e)
>
> Grygorii
> __

--
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 v2 08/16] ARM: omap: add hsmmc am33xx specific init

[Matt Porter]

On Fri, Oct 12, 2012 at 09:17:53AM +, Hebbar, Gururaja wrote:
> Matt
> 
> On Fri, Oct 12, 2012 at 00:34:33, Porter, Matt wrote:
> > AM33xx requires special handling in hsmmc initialization
> > platform glue.
> 
> Since AM335x boots mainly through DT, do we still need this patch.
> This function will be called in case of initializing hsmmc with
> Platform data. 

Yes, thanks, will drop in v3.

-Matt
--
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] ARM: OMAP: i2c: fix interrupt flood during resume

[Shubhrajyoti]

On Friday 12 October 2012 03:48 PM, Strashko, Grygorii wrote:
> Hi All,
>
> Sorry, for the late reply.
> + CC Huzefa Kankroliwala - who is I2C driver owner on Android Kernel 3.4.
>
> Regarding this patch
hmm I had similar ideas however my idea was to pacify the arm interrupts
when the ip is used by another processor.(something my hw spin patch missed)

Any-ways will wait for Huzefa to comment.


>  -  from my point of view, it fixes corner case and not an issue in general.
> Let take a look on resume sequence:
>- platform resume
>- syscore resume
>- resume_noirq
>- enable IRQs - resume_device_irqs()
>  |- at this point IRQ handler will be invoked if IRQ state is 
> IRQS_PENDING.
>  |- so, the I2C device IRQ handler may be called at time when I2C adapter 
> IRQ is still disabled and, as result, the I2C device IRQ-handler may fail. 
> (I2C device and I2C adapter may use different physical IRQ lines)
>- resume_late
>  |- enable I2C bus IRQ
>
> Possibly, the better way is to enable/disable I2C bus IRQ when needed - in 
> our case in omap_i2c_xfer().
> We use such approach in Android kernel 3.4
> (http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=1445a4d3b587c164bd30d108b6176007365e)
>
> Grygorii
> __

--
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/4] MMC: omap_hsmmc: fix DMA config block

[Russell King - ARM Linux]

On Fri, Oct 12, 2012 at 12:58:13PM +0200, Daniel Mack wrote:
> The .direction field of the config passed to dmaengine_slave_config()
> must be set in order to make the generic code store the configured bus
> width.

NAK.  The direction field is deprecated, and should not be used anymore.
--
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/4] MMC: omap_hsmmc: claim pinctrl at probe time

[Linus Walleij]

On Fri, Oct 12, 2012 at 12:58 PM, Daniel Mack  wrote:

> This allows DT-driven board to set up the pin mux only when the driver
> is in use.
>
> Signed-off-by: Daniel Mack 
> Cc: Venkatraman S 
> Cc: Chris Ball 
> Cc: Grant Likely 
> Cc: Rob Herring 
> Cc: Linus Walleij 
> Cc: linux-omap@vger.kernel.org

Looks nice!
Acked-by: Linus Walleij 

Yours,
Linus Walleij
--
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/4] MMC: omap_hsmmc: fix DMA config block

[Porter, Matt]

On Oct 12, 2012, at 6:58 AM, Daniel Mack wrote:

> The .direction field of the config passed to dmaengine_slave_config()
> must be set in order to make the generic code store the configured bus
> width.
> 
> Without this patch, I keep getting the following error on a AM33xx
> board:
> 
> [1.963144] edma-dma-engine edma-dma-engine.0: Undefined slave buswidth
> [1.970158] omap_hsmmc mmc.4: prep_slave_sg() failed
> [1.975454] mmc1: error -1 whilst initialising SD card

Hi Daniel,

I posted a patch to fix the slave config handling in the EDMA DMA Engine
driver here: https://patchwork.kernel.org/patch/1474411/

Vinod didn't pick that up for 3.7, probably because it's not triggered by
any of the in-tree davinci drivers that are converted. However, I am
carrying the same patch in the am335x edma dmaengine v2 series
(https://lkml.org/lkml/2012/10/11/345) so there's no need to change this
driver.

-Matt

> 
> Signed-off-by: Daniel Mack 
> Cc: Venkatraman S 
> Cc: Chris Ball 
> Cc: Grant Likely 
> Cc: Rob Herring 
> Cc: linux-omap@vger.kernel.org
> Cc: Matt Porter 
> Cc: Russell King 
> ---
> drivers/mmc/host/omap_hsmmc.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 4b70823..2c57b0d 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -1260,6 +1260,8 @@ static int omap_hsmmc_start_dma_transfer(struct 
> omap_hsmmc_host *host,
>   cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
>   cfg.src_maxburst = data->blksz / 4;
>   cfg.dst_maxburst = data->blksz / 4;
> + cfg.direction = data->flags & MMC_DATA_WRITE ?
> + DMA_MEM_TO_DEV : DMA_DEV_TO_MEM;
> 
>   ret = dmaengine_slave_config(chan, &cfg);
>   if (ret)
> @@ -1270,8 +1272,8 @@ static int omap_hsmmc_start_dma_transfer(struct 
> omap_hsmmc_host *host,
>   return ret;
> 
>   tx = dmaengine_prep_slave_sg(chan, data->sg, data->sg_len,
> - data->flags & MMC_DATA_WRITE ? DMA_MEM_TO_DEV : DMA_DEV_TO_MEM,
> - DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
> +  cfg.direction,
> +  DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
>   if (!tx) {
>   dev_err(mmc_dev(host->mmc), "prep_slave_sg() failed\n");
>   /* FIXME: cleanup */
> -- 
> 1.7.11.4
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/4] MMC: omap_hsmmc: claim pinctrl at probe time

[Daniel Mack]

This allows DT-driven board to set up the pin mux only when the driver
is in use.

Signed-off-by: Daniel Mack 
Cc: Venkatraman S 
Cc: Chris Ball 
Cc: Grant Likely 
Cc: Rob Herring 
Cc: Linus Walleij 
Cc: linux-omap@vger.kernel.org
---
 drivers/mmc/host/omap_hsmmc.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 2c57b0d..86f0759 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1722,6 +1723,7 @@ static int __devinit omap_hsmmc_probe(struct 
platform_device *pdev)
const struct of_device_id *match;
dma_cap_mask_t mask;
unsigned tx_req, rx_req;
+   struct pinctrl *pinctrl;
 
match = of_match_device(of_match_ptr(omap_mmc_of_match), &pdev->dev);
if (match) {
@@ -1948,6 +1950,11 @@ static int __devinit omap_hsmmc_probe(struct 
platform_device *pdev)
 
omap_hsmmc_disable_irq(host);
 
+   pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
+   if (IS_ERR(pinctrl))
+   dev_warn(&pdev->dev,
+   "pins are not configured from the driver\n");
+
omap_hsmmc_protect_card(host);
 
mmc_add_host(mmc);
-- 
1.7.11.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/4] MMC: omap_hsmmc: add DT property for max bus frequency

[Daniel Mack]

Maximum bus frequency can be limited by external circuitry like level
shifters etc. Allow passing this value from DT.

Signed-off-by: Daniel Mack 
Cc: Venkatraman S 
Cc: Chris Ball 
Cc: Grant Likely 
Cc: Rob Herring 
Cc: linux-omap@vger.kernel.org
---
 drivers/mmc/host/omap_hsmmc.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 86f0759..4650ef7 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1676,7 +1676,7 @@ static struct omap_mmc_platform_data 
*of_get_hsmmc_pdata(struct device *dev)
 {
struct omap_mmc_platform_data *pdata;
struct device_node *np = dev->of_node;
-   u32 bus_width;
+   u32 bus_width, max_freq;
 
pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
@@ -1703,6 +1703,9 @@ static struct omap_mmc_platform_data 
*of_get_hsmmc_pdata(struct device *dev)
if (of_find_property(np, "ti,needs-special-reset", NULL))
pdata->slots[0].features |= HSMMC_HAS_UPDATED_RESET;
 
+   if (!of_property_read_u32(np, "max-frequency", &max_freq))
+   pdata->max_freq = max_freq;
+
return pdata;
 }
 #else
-- 
1.7.11.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/4] MMC: omap_hsmmc: set platform data after probe from DT node

[Daniel Mack]

When probed from DT, the self-allocated platform data has to be attached
to the actual device. Otherwise a NULL pointer will be dereferenced from
omap_hsmmc_card_detect if a gpio handle for card-detect has been passed.

Signed-off-by: Daniel Mack 
Cc: Venkatraman S 
Cc: Chris Ball 
Cc: Grant Likely 
Cc: Rob Herring 
Cc: linux-omap@vger.kernel.org
---
 drivers/mmc/host/omap_hsmmc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 19ccb59..4b70823 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1728,6 +1728,7 @@ static int __devinit omap_hsmmc_probe(struct 
platform_device *pdev)
const u16 *offsetp = match->data;
pdata->reg_offset = *offsetp;
}
+   pdev->dev.platform_data = pdata;
}
 
if (pdata == NULL) {
-- 
1.7.11.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/4] MMC: omap_hsmmc: fix DMA config block

[Daniel Mack]

The .direction field of the config passed to dmaengine_slave_config()
must be set in order to make the generic code store the configured bus
width.

Without this patch, I keep getting the following error on a AM33xx
board:

[1.963144] edma-dma-engine edma-dma-engine.0: Undefined slave buswidth
[1.970158] omap_hsmmc mmc.4: prep_slave_sg() failed
[1.975454] mmc1: error -1 whilst initialising SD card

Signed-off-by: Daniel Mack 
Cc: Venkatraman S 
Cc: Chris Ball 
Cc: Grant Likely 
Cc: Rob Herring 
Cc: linux-omap@vger.kernel.org
Cc: Matt Porter 
Cc: Russell King 
---
 drivers/mmc/host/omap_hsmmc.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4b70823..2c57b0d 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1260,6 +1260,8 @@ static int omap_hsmmc_start_dma_transfer(struct 
omap_hsmmc_host *host,
cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
cfg.src_maxburst = data->blksz / 4;
cfg.dst_maxburst = data->blksz / 4;
+   cfg.direction = data->flags & MMC_DATA_WRITE ?
+   DMA_MEM_TO_DEV : DMA_DEV_TO_MEM;
 
ret = dmaengine_slave_config(chan, &cfg);
if (ret)
@@ -1270,8 +1272,8 @@ static int omap_hsmmc_start_dma_transfer(struct 
omap_hsmmc_host *host,
return ret;
 
tx = dmaengine_prep_slave_sg(chan, data->sg, data->sg_len,
-   data->flags & MMC_DATA_WRITE ? DMA_MEM_TO_DEV : DMA_DEV_TO_MEM,
-   DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+cfg.direction,
+DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!tx) {
dev_err(mmc_dev(host->mmc), "prep_slave_sg() failed\n");
/* FIXME: cleanup */
-- 
1.7.11.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 1/3] usb: dwc3: Add the suspend/resume functionality

[kishon]

Hi,

On Wednesday 10 October 2012 07:35 PM, Vikas C Sajjan wrote:

From: Vikas Sajjan 

Adding the suspend and resume funtionality to DWC3 core.

Signed-off-by: Abhilash Kesavan 
Signed-off-by: Vikas C Sajjan 
CC: Doug Anderson 
---
  drivers/usb/dwc3/core.c |  268 +-
  1 files changed, 169 insertions(+), 99 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index b415c0c..58b51e1 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -70,51 +70,20 @@ MODULE_PARM_DESC(maximum_speed, "Maximum supported speed.");

  static DECLARE_BITMAP(dwc3_devs, DWC3_DEVS_POSSIBLE);

-int dwc3_get_device_id(void)
-{
-   int id;
-
-again:
-   id = find_first_zero_bit(dwc3_devs, DWC3_DEVS_POSSIBLE);
-   if (id < DWC3_DEVS_POSSIBLE) {
-   int old;
-
-   old = test_and_set_bit(id, dwc3_devs);
-   if (old)
-   goto again;
-   } else {
-   pr_err("dwc3: no space for new device\n");
-   id = -ENOMEM;
-   }
-
-   return id;
-}
-EXPORT_SYMBOL_GPL(dwc3_get_device_id);
-
-void dwc3_put_device_id(int id)
-{
-   int ret;
-
-   if (id < 0)
-   return;
-
-   ret = test_bit(id, dwc3_devs);
-   WARN(!ret, "dwc3: ID %d not in use\n", id);
-   smp_mb__before_clear_bit();
-   clear_bit(id, dwc3_devs);
-}
-EXPORT_SYMBOL_GPL(dwc3_put_device_id);
-
-void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
+static void __devinit dwc3_cache_hwparams(struct dwc3 *dwc)
  {
-   u32 reg;
+   struct dwc3_hwparams*parms = &dwc->hwparams;

-   reg = dwc3_readl(dwc->regs, DWC3_GCTL);
-   reg &= ~(DWC3_GCTL_PRTCAPDIR(DWC3_GCTL_PRTCAP_OTG));
-   reg |= DWC3_GCTL_PRTCAPDIR(mode);
-   dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+   parms->hwparams0 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS0);
+   parms->hwparams1 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS1);
+   parms->hwparams2 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS2);
+   parms->hwparams3 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS3);
+   parms->hwparams4 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS4);
+   parms->hwparams5 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS5);
+   parms->hwparams6 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS6);
+   parms->hwparams7 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS7);
+   parms->hwparams8 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS8);
  }
-
  /**
   * dwc3_core_soft_reset - Issues core soft reset and PHY reset
   * @dwc: pointer to our context structure
@@ -160,6 +129,102 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
dwc3_writel(dwc->regs, DWC3_GCTL, reg);
  }

+static int dwc3_core_reset(struct dwc3 *dwc)
+{
+   unsigned long   timeout;
+   u32 reg;
+
+   /* issue device SoftReset too */
+   timeout = jiffies + msecs_to_jiffies(500);
+   dwc3_writel(dwc->regs, DWC3_DCTL, DWC3_DCTL_CSFTRST);
+   do {
+   reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+   if (!(reg & DWC3_DCTL_CSFTRST))
+   break;
+
+   if (time_after(jiffies, timeout)) {
+   dev_err(dwc->dev, "Reset Timed Out\n");
+   return -ETIMEDOUT;
+   }
+
+   cpu_relax();
+   } while (true);
+
+   dwc3_core_soft_reset(dwc);
+
+   dwc3_cache_hwparams(dwc);
+
+   reg = dwc3_readl(dwc->regs, DWC3_GCTL);
+   reg &= ~DWC3_GCTL_SCALEDOWN_MASK;
+   reg &= ~DWC3_GCTL_DISSCRAMBLE;
+
+   switch (DWC3_GHWPARAMS1_EN_PWROPT(dwc->hwparams.hwparams1)) {
+   case DWC3_GHWPARAMS1_EN_PWROPT_CLK:
+   reg &= ~DWC3_GCTL_DSBLCLKGTNG;
+   break;
+   default:
+   dev_dbg(dwc->dev, "No power optimization available\n");
+   }
+
+   /*
+* WORKAROUND: DWC3 revisions <1.90a have a bug
+* where the device can fail to connect at SuperSpeed
+* and falls back to high-speed mode which causes
+* the device to enter a Connect/Disconnect loop
+*/
+   if (dwc->revision < DWC3_REVISION_190A)
+   reg |= DWC3_GCTL_U2RSTECN;
+
+   dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+
+   return 0;
+}
+
+int dwc3_get_device_id(void)
+{
+   int id;
+
+again:
+   id = find_first_zero_bit(dwc3_devs, DWC3_DEVS_POSSIBLE);
+   if (id < DWC3_DEVS_POSSIBLE) {
+   int old;
+
+   old = test_and_set_bit(id, dwc3_devs);
+   if (old)
+   goto again;
+   } else {
+   pr_err("dwc3: no space for new device\n");
+   id = -ENOMEM;
+   }
+
+   return id;
+}
+EXPORT_SYMBOL_GPL(dwc3_get_device_id);
+
+void dwc3_put_device_id(int id)
+{
+   int ret;
+
+   if (id < 0)
+   return;
+
+   ret = test_bit(id, dwc3_devs);
+   WARN(!ret, "dwc3: ID %d not in use\n", id);
+   

Re: omap DSS fails with tft410 driver panel?

[Tomi Valkeinen]

On 2012-10-11 18:58, Enric Balletbo Serra wrote:
> Hi all,
> 
> I see that commit dac8eb5f (OMAPDSS: TFP410: rename dvi files to
> tfp410) and commit 2e6f2ee7 (OMAPDSS: TFP410: rename dvi -> tfp410)
> changes the panel driver used on some boards. I tested current
> linux-next-20101011 kernel with my IGEPv2 board and DSS fails with
> following error (see http://pastebin.com/VjPGCQDt for full log) :
> 
>[   21.222808] omapdss OVERLAY error: check_overlay: paddr cannot be 0
>[   21.229583] omapdss OVERLAY error: check_overlay: paddr cannot be 0
>[   21.236236] omapfb omapfb: setup_plane failed
> 
> Before checking what happens there is a known issue with this ?

Works fine for me, although only with a quite minimal test environment.

Looking at the log, it looks to me that your userspace is trying to
configure the overlays, and that somehow leads to the driver getting
zero as the fb address.

I'm guessing that some wrong value is passed when configuring, or
missing some step in configuring. However, It should be the omapfb that
rejects configuration that would lead to paddr == 0, not omapdss, so
there's definitely bug in the error handling of omapfb.

Can you tell me more what's going on there? I presume the error happens
when booting? What userspace component is using omapfb in your setup? X?

If you can, put some debug prints into omapfb-ioctl.c:omapfb_setup_plane
to see what code path it takes, and where it goes wrong.

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: [PATCH 1/3] usb: dwc3: Add the suspend/resume functionality

[Felipe Balbi]

Hi,

On Fri, Oct 12, 2012 at 02:29:39PM +0530, Vikas Sajjan wrote:
> > > @@ -339,49 +390,9 @@ static int __devinit dwc3_core_init(struct dwc3
> > > *dwc)
> > >   }
> > >   dwc->revision = reg;
> > >
> > > - /* issue device SoftReset too */
> > > - timeout = jiffies + msecs_to_jiffies(500);
> > > - dwc3_writel(dwc->regs, DWC3_DCTL, DWC3_DCTL_CSFTRST);
> > > - do {
> > > - reg = dwc3_readl(dwc->regs, DWC3_DCTL);
> > > - if (!(reg & DWC3_DCTL_CSFTRST))
> > > - break;
> > > -
> > > - if (time_after(jiffies, timeout)) {
> > > - dev_err(dwc->dev, "Reset Timed Out\n");
> > > - ret = -ETIMEDOUT;
> > > - goto err0;
> > > - }
> > > -
> > > - cpu_relax();
> > > - } while (true);
> > > -
> > > - dwc3_core_soft_reset(dwc);
> > > -
> > > - dwc3_cache_hwparams(dwc);
> > > -
> > > - reg = dwc3_readl(dwc->regs, DWC3_GCTL);
> > > - reg &= ~DWC3_GCTL_SCALEDOWN_MASK;
> > > - reg &= ~DWC3_GCTL_DISSCRAMBLE;
> > > -
> > > - switch (DWC3_GHWPARAMS1_EN_PWROPT(dwc->hwparams.hwparams1)) {
> > > - case DWC3_GHWPARAMS1_EN_PWROPT_CLK:
> > > - reg &= ~DWC3_GCTL_DSBLCLKGTNG;
> > > - break;
> > > - default:
> > > - dev_dbg(dwc->dev, "No power optimization available\n");
> > > - }
> > > -
> > > - /*
> > > -  * WORKAROUND: DWC3 revisions <1.90a have a bug
> > > -  * where the device can fail to connect at SuperSpeed
> > > -  * and falls back to high-speed mode which causes
> > > -  * the device to enter a Connect/Disconnect loop
> > > -  */
> > > - if (dwc->revision < DWC3_REVISION_190A)
> > > - reg |= DWC3_GCTL_U2RSTECN;
> > > -
> > > - dwc3_writel(dwc->regs, DWC3_GCTL, reg);
> > > + ret = dwc3_core_reset(dwc);
> > > + if (ret < 0)
> > > + goto err0;
> > >
> > >   ret = dwc3_alloc_event_buffers(dwc, DWC3_EVENT_BUFFERS_SIZE);
> >
> > I would rather move dwc3_alloc_event_buffers() outside of
> > dwc3_core_init() and use that directly on ->resume(). dwc3_core_init()
> > shouldn't be doing any memory allocations, so we can re-use it, and it
> > doesn't matter when we allocate the event buffers anyway.
> >
> dwc3_alloc_event_buffers() was already inside the dwc3_core_init() in
> the existing code, the only change I made is, a common function called
>  dwc3_core_reset() is added which will be used both in probe and
> resume.
> so basically resume only does dwc3_core_reset() and
> dwc3_event_buffers_setup() as dwc3_alloc_event_buffers() is done in
> probe.

we already have too many functions call *reset*, adding another one will
just make code more difficult to follow and it will be error-prone.

This is what I suggested:

commit 9aba985696690c1e8c2cf4f34e35b3f5b296175d
Author: Felipe Balbi 
Date:   Thu Oct 11 13:54:36 2012 +0300

usb: dwc3: core: move event buffer allocation out of dwc3_core_init()

This patch is in preparation for adding PM support
dwc3 driver. We want to re-use dwc3_core_init and
dwc3_core_exit() functions on resume() and suspend()
callbacks respectively.

Moving even buffer allocation away from dwc3_core_init()
will allow us to reuse the event buffer which was allocated
long ago on our probe() routine.

Signed-off-by: Felipe Balbi 

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 8d543ea..b923183 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -381,24 +381,14 @@ static int __devinit dwc3_core_init(struct dwc3 *dwc)
 
dwc3_writel(dwc->regs, DWC3_GCTL, reg);
 
-   ret = dwc3_alloc_event_buffers(dwc, DWC3_EVENT_BUFFERS_SIZE);
-   if (ret) {
-   dev_err(dwc->dev, "failed to allocate event buffers\n");
-   ret = -ENOMEM;
-   goto err1;
-   }
-
ret = dwc3_event_buffers_setup(dwc);
if (ret) {
dev_err(dwc->dev, "failed to setup event buffers\n");
-   goto err1;
+   goto err0;
}
 
return 0;
 
-err1:
-   dwc3_free_event_buffers(dwc);
-
 err0:
return ret;
 }
@@ -406,7 +396,6 @@ err0:
 static void dwc3_core_exit(struct dwc3 *dwc)
 {
dwc3_event_buffers_cleanup(dwc);
-   dwc3_free_event_buffers(dwc);
 }
 
 #define DWC3_ALIGN_MASK(16 - 1)
@@ -509,10 +498,17 @@ static int __devinit dwc3_probe(struct platform_device 
*pdev)
pm_runtime_get_sync(dev);
pm_runtime_forbid(dev);
 
+   ret = dwc3_alloc_event_buffers(dwc, DWC3_EVENT_BUFFERS_SIZE);
+   if (ret) {
+   dev_err(dwc->dev, "failed to allocate event buffers\n");
+   ret = -ENOMEM;
+   goto err0;
+   }
+
ret = dwc3_core_init(dwc);
if (ret) {
dev_err(dev, "failed to initialize core\n");
-   return ret;
+   goto err0;
 

RE: [PATCH v3] ARM: OMAP: i2c: fix interrupt flood during resume

[Strashko, Grygorii]

Hi All,

Sorry, for the late reply.
+ CC Huzefa Kankroliwala - who is I2C driver owner on Android Kernel 3.4.

Regarding this patch -  from my point of view, it fixes corner case and not an 
issue in general.
Let take a look on resume sequence:
   - platform resume
   - syscore resume
   - resume_noirq
   - enable IRQs - resume_device_irqs()
 |- at this point IRQ handler will be invoked if IRQ state is IRQS_PENDING.
 |- so, the I2C device IRQ handler may be called at time when I2C adapter 
IRQ is still disabled and, as result, the I2C device IRQ-handler may fail. (I2C 
device and I2C adapter may use different physical IRQ lines)
   - resume_late
 |- enable I2C bus IRQ

Possibly, the better way is to enable/disable I2C bus IRQ when needed - in our 
case in omap_i2c_xfer().
We use such approach in Android kernel 3.4
(http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=1445a4d3b587c164bd30d108b6176007365e)

Grygorii

From: Kevin Hilman [khil...@deeprootsystems.com]
Sent: Friday, October 12, 2012 12:08 AM
To: Kalle Jokiniemi
Cc: linux-...@vger.kernel.org; w.s...@pengutronix.de; ben-li...@fluff.org; 
t...@atomide.com; linux-omap@vger.kernel.org; Strashko, Grygorii; Datta, 
Shubhrajyoti
Subject: Re: [PATCH v3] ARM: OMAP: i2c: fix interrupt flood during resume

Hi Kalle,

Kalle Jokiniemi  writes:

> The resume_noirq enables interrupts one-by-one starting from
> first one. Now if the wake up event for suspend came from i2c
> device, the i2c bus irq gets enabled before the threaded
> i2c device irq, causing a flood of i2c bus interrupts as the
> threaded irq that should clear the event is not enabled yet.
>
> Fixed the issue by adding suspend_noirq and resume_early
> functions that keep i2c bus interrupts disabled until
> resume_noirq has run completely.
>
> Issue was detected doing a wake up from autosleep with
> twl4030 power key on N9. Patch tested on N9.
>
> Signed-off-by: Kalle Jokiniemi 

This version looks good, thanks for the extra comments.

Reviewed-by: Kevin Hilman 
Tested-by: Kevin Hilman 

Wolfram, This should also probably be Cc'd to stable since it affects
earlier kernels as well.  Thanks,

Kevin

> ---
>  drivers/i2c/busses/i2c-omap.c |   34 ++
>  1 files changed, 34 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index a0e49f6..991341b 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -1132,6 +1132,36 @@ static int __devexit omap_i2c_remove(struct 
> platform_device *pdev)
>  }
>
>  #ifdef CONFIG_PM
> +#ifdef CONFIG_PM_SLEEP
> +static int omap_i2c_suspend_noirq(struct device *dev)
> +{
> +
> + struct platform_device *pdev = to_platform_device(dev);
> + struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
> +
> + /* Disabling irq here to balance the enable in resume_early */
> + disable_irq(_dev->irq);
> + return 0;
> +}
> +
> +static int omap_i2c_resume_early(struct device *dev)
> +{
> +
> + struct platform_device *pdev = to_platform_device(dev);
> + struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
> +
> + /*
> +  * The noirq_resume enables the interrupts one by one,
> +  * this causes a interrupt flood if the SW irq actually reading
> +  * event from i2c device is enabled only after i2c bus irq, as the
> +  * irq that should clear the event is still disabled. We have to
> +  * keep the bus irq disabled until all other irqs have been enabled.
> +  */
> + enable_irq(_dev->irq);
> +
> + return 0;
> +}
> +#endif
>  #ifdef CONFIG_PM_RUNTIME
>  static int omap_i2c_runtime_suspend(struct device *dev)
>  {
> @@ -1183,6 +1213,10 @@ static int omap_i2c_runtime_resume(struct device *dev)
>  #endif /* CONFIG_PM_RUNTIME */
>
>  static struct dev_pm_ops omap_i2c_pm_ops = {
> +#ifdef CONFIG_PM_SLEEP
> + .suspend_noirq = omap_i2c_suspend_noirq,
> + .resume_early = omap_i2c_resume_early,
> +#endif
>   SET_RUNTIME_PM_OPS(omap_i2c_runtime_suspend,
>  omap_i2c_runtime_resume, 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

RE: [RFC PATCH v2 08/16] ARM: omap: add hsmmc am33xx specific init

[Hebbar, Gururaja]

Matt

On Fri, Oct 12, 2012 at 00:34:33, Porter, Matt wrote:
> AM33xx requires special handling in hsmmc initialization
> platform glue.

Since AM335x boots mainly through DT, do we still need this patch.
This function will be called in case of initializing hsmmc with
Platform data. 

> 
> Signed-off-by: Matt Porter 
> ---
>  arch/arm/mach-omap2/hsmmc.c |7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 

..snip..
..snip..

>   name = "omap_hsmmc";
>   res = snprintf(oh_name, MAX_OMAP_MMC_HWMOD_NAME_LEN,
> -- 
> 1.7.9.5
> 
> ___
> Davinci-linux-open-source mailing list
> davinci-linux-open-sou...@linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> 


Regards, 
Gururaja
--
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/4] usb: phy: add a new driver for usb3 phy

[kishon]

Hi Tony,

On Thursday 11 October 2012 06:29 AM, Tony Lindgren wrote:

Hi,

* Kishon Vijay Abraham I  [120919 04:32]:

Added a driver for usb3 phy that handles the interaction between usb phy
device and dwc3 controller.

This also includes device tree support for usb3 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.


You may be able to set up the control module register with one
of the following Linux standard frameworks:

1. Fixed regulator defined in mach-omap2/control.c


Is it control.c?


In this case the PHY driver can pick up the regulator by name.


Do you mean we have to define something like fixed_voltage_config 
defined in board-4430sdp.c?
From whatever I could make out from regulator/fixed.c, 
enabling/disabling of regulator is done using only gpio. I'm not sure 
how we can use that to write to control module register.


2. A mux mapped with pinctrl framework using pinctrl-single,bits
binding

And in this case the PHY driver can request the named pinctrl
states like "enabled" and "disabled".


--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -15,3 +15,21 @@ usb2phy@4a0ad080 {
reg = <0x4a0ad080 0x58>,
  <0x4a002300 0x4>;
  };


The comments also apply to the omap_usb2.c driver for
0x4a002300 above.


+
+OMAP USB3 PHY
+
+Required properties:
+ - compatible: Should be "ti,omap-usb3"
+ - reg : Address and length of the register set for the device. Also
+add the address of control module phy power register until a driver for
+control module is added
+
+This is usually a subnode of ocp2scp to which it is connected.
+
+usb3phy@4a084400 {
+   compatible = "ti,omap-usb3";
+   reg = <0x0x4a084400 0x80>,
+ <0x4a084800 0x64>,
+ <0x4a084c00 0x40>,
+ <0x4a002370 0x4>;
+};


And register 0x4a002370 here. Care to post some info what the
0x4a002370 register bits do? Is that same as CONTROL_DEV_CONF
on omap4, or does it have other bits there too?


It's CONTROL_PHY_POWER_USB register and it's structure looks like this.
31:22 USB_PWRCTL_CLK_FREQ
21:14 USB_PWRCTL_CLK_CMD
13:0 RESERVED

CLK_CMD takes values to power up/down the TX and RX in various combinations.

And CLK_FREQ takes values for clock configuration.

Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] usb: dwc3: Add the suspend/resume functionality

[Vikas Sajjan]

Hi Felipe,

On 11 October 2012 13:17, Felipe Balbi  wrote:
>
> Hi,
>
> On Wed, Oct 10, 2012 at 07:35:47PM +0530, Vikas C Sajjan wrote:
> > From: Vikas Sajjan 
> >
> > Adding the suspend and resume funtionality to DWC3 core.
> >
> > Signed-off-by: Abhilash Kesavan 
> > Signed-off-by: Vikas C Sajjan 
> > CC: Doug Anderson 
> > ---
> >  drivers/usb/dwc3/core.c |  268
> > +-
> >  1 files changed, 169 insertions(+), 99 deletions(-)
> >
> > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> > index b415c0c..58b51e1 100644
> > --- a/drivers/usb/dwc3/core.c
> > +++ b/drivers/usb/dwc3/core.c
> > @@ -70,51 +70,20 @@ MODULE_PARM_DESC(maximum_speed, "Maximum supported
> > speed.");
> >
> >  static DECLARE_BITMAP(dwc3_devs, DWC3_DEVS_POSSIBLE);
> >
> > -int dwc3_get_device_id(void)
> > -{
> > - int id;
> > -
> > -again:
> > - id = find_first_zero_bit(dwc3_devs, DWC3_DEVS_POSSIBLE);
> > - if (id < DWC3_DEVS_POSSIBLE) {
> > - int old;
> > -
> > - old = test_and_set_bit(id, dwc3_devs);
> > - if (old)
> > - goto again;
> > - } else {
> > - pr_err("dwc3: no space for new device\n");
> > - id = -ENOMEM;
> > - }
> > -
> > - return id;
> > -}
> > -EXPORT_SYMBOL_GPL(dwc3_get_device_id);
> > -
> > -void dwc3_put_device_id(int id)
> > -{
> > - int ret;
> > -
> > - if (id < 0)
> > - return;
> > -
> > - ret = test_bit(id, dwc3_devs);
> > - WARN(!ret, "dwc3: ID %d not in use\n", id);
> > - smp_mb__before_clear_bit();
> > - clear_bit(id, dwc3_devs);
> > -}
> > -EXPORT_SYMBOL_GPL(dwc3_put_device_id);
> > -
> > -void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
>
> why are you even moving all this code around ? Doesn't look necessary.
>
> > +static void __devinit dwc3_cache_hwparams(struct dwc3 *dwc)
> >  {
> > - u32 reg;
> > + struct dwc3_hwparams*parms = &dwc->hwparams;
> >
> > - reg = dwc3_readl(dwc->regs, DWC3_GCTL);
> > - reg &= ~(DWC3_GCTL_PRTCAPDIR(DWC3_GCTL_PRTCAP_OTG));
> > - reg |= DWC3_GCTL_PRTCAPDIR(mode);
> > - dwc3_writel(dwc->regs, DWC3_GCTL, reg);
> > + parms->hwparams0 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS0);
> > + parms->hwparams1 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS1);
> > + parms->hwparams2 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS2);
> > + parms->hwparams3 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS3);
> > + parms->hwparams4 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS4);
> > + parms->hwparams5 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS5);
> > + parms->hwparams6 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS6);
> > + parms->hwparams7 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS7);
> > + parms->hwparams8 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS8);
> >  }
> > -
> >  /**
> >   * dwc3_core_soft_reset - Issues core soft reset and PHY reset
> >   * @dwc: pointer to our context structure
> > @@ -160,6 +129,102 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
> >   dwc3_writel(dwc->regs, DWC3_GCTL, reg);
> >  }
> >
> > +static int dwc3_core_reset(struct dwc3 *dwc)
>
> this looks unnecessary.
>
dwc3_core_reset() function is added to avoid the code duplication, and
can be reused both in probe and resume.
> > +{
> > + unsigned long   timeout;
> > + u32 reg;
> > +
> > + /* issue device SoftReset too */
> > + timeout = jiffies + msecs_to_jiffies(500);
> > + dwc3_writel(dwc->regs, DWC3_DCTL, DWC3_DCTL_CSFTRST);
> > + do {
> > + reg = dwc3_readl(dwc->regs, DWC3_DCTL);
> > + if (!(reg & DWC3_DCTL_CSFTRST))
> > + break;
> > +
> > + if (time_after(jiffies, timeout)) {
> > + dev_err(dwc->dev, "Reset Timed Out\n");
> > + return -ETIMEDOUT;
> > + }
> > +
> > + cpu_relax();
> > + } while (true);
> > +
> > + dwc3_core_soft_reset(dwc);
> > +
> > + dwc3_cache_hwparams(dwc);
> > +
> > + reg = dwc3_readl(dwc->regs, DWC3_GCTL);
> > + reg &= ~DWC3_GCTL_SCALEDOWN_MASK;
> > + reg &= ~DWC3_GCTL_DISSCRAMBLE;
> > +
> > + switch (DWC3_GHWPARAMS1_EN_PWROPT(dwc->hwparams.hwparams1)) {
> > + case DWC3_GHWPARAMS1_EN_PWROPT_CLK:
> > + reg &= ~DWC3_GCTL_DSBLCLKGTNG;
> > + break;
> > + default:
> > + dev_dbg(dwc->dev, "No power optimization available\n");
> > + }
> > +
> > + /*
> > +  * WORKAROUND: DWC3 revisions <1.90a have a bug
> > +  * where the device can fail to connect at SuperSpeed
> > +  * and falls back to high-speed mode which causes
> > +  * the device to enter a Connect/Disconnect loop
> > +  */
> > + if (dwc->revision < DWC3_REVISION_190A)
> > + reg |= DWC3_GCTL_U2RSTECN;
> > +
> > + dwc3_writel(dwc->regs, DWC3_GCTL, reg);
> > +
> > + return 0;
> > +}
> > +
> > +int dwc3_get_device_id(void)
> > +{
> > + int 

Re: [PATCH 2/6] ARM: OMAP3/4: iommu: adapt to runtime pm

[Felipe Contreras]

On Fri, Oct 12, 2012 at 3:06 AM, Omar Ramirez Luna  wrote:
> Use runtime PM functionality interfaced with hwmod enable/idle
> functions, to replace direct clock operations and sysconfig
> handling.
>
> Dues to reset sequence, pm_runtime_put_sync must be used, to avoid
> possible operations with the module under reset.

I already made most of these comments, but here they go again.

> @@ -142,11 +142,10 @@ static int iommu_enable(struct omap_iommu *obj)
> }
> }
>
> -   clk_enable(obj->clk);
> +   pm_runtime_get_sync(obj->dev);
>
> err = arch_iommu->enable(obj);
>
> -   clk_disable(obj->clk);

The device will never go to sleep, until iommu_disable is called.
clk_enable -> pm_runtime_get_sync, clk_disable pm_runtime_put.

> @@ -288,7 +285,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, 
> struct iotlb_entry *e)
> if (!obj || !obj->nr_tlb_entries || !e)
> return -EINVAL;
>
> -   clk_enable(obj->clk);
> +   pm_runtime_get_sync(obj->dev);
>
> iotlb_lock_get(obj, &l);
> if (l.base == obj->nr_tlb_entries) {
> @@ -318,7 +315,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, 
> struct iotlb_entry *e)
>
> cr = iotlb_alloc_cr(obj, e);
> if (IS_ERR(cr)) {
> -   clk_disable(obj->clk);
> +   pm_runtime_put_sync(obj->dev);
> return PTR_ERR(cr);
> }

If I'm correct, the above pm_runtime_get/put are redundant, because
the count can't possibly reach 0 because of the reason I explained
before.

The same for all the cases below.

> @@ -1009,7 +1001,8 @@ static int __devexit omap_iommu_remove(struct 
> platform_device *pdev)
> release_mem_region(res->start, resource_size(res));
> iounmap(obj->regbase);
>
> -   clk_put(obj->clk);
> +   pm_runtime_disable(obj->dev);

This will turn on the device unnecessarily, wasting power, and there's
no need for that, kfree will take care of that without resuming.

> dev_info(&pdev->dev, "%s removed\n", obj->name);
> kfree(obj);
> return 0;

Also, I still think that something like this is needed:

--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -,8 +,17 @@ static struct clk cam_mclk = {
.recalc = &followparent_recalc,
 };

+static struct clk cam_fck = {
+   .name   = "cam_fck",
+   .ops= &clkops_omap2_iclk_dflt,
+   .parent = &l3_ick,
+   .enable_reg = OMAP_CM_REGADDR(OMAP3430_CAM_MOD, CM_ICLKEN),
+   .enable_bit = OMAP3430_EN_CAM_SHIFT,
+   .clkdm_name = "cam_clkdm",
+   .recalc = &followparent_recalc,
+};
+
 static struct clk cam_ick = {
-   /* Handles both L3 and L4 clocks */
.name   = "cam_ick",
.ops= &clkops_omap2_iclk_dflt,
.parent = &l4_ick,
@@ -3394,6 +3403,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK("omapdss_dss",  "ick",  &dss_ick_3430es2,
 CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
CLK(NULL,   "dss_ick",  &dss_ick_3430es2,
 CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
CLK(NULL,   "cam_mclk", &cam_mclk,  CK_34XX | CK_36XX),
+   CLK(NULL,   "cam_fck",  &cam_fck,   CK_34XX | CK_36XX),
CLK(NULL,   "cam_ick",  &cam_ick,   CK_34XX | CK_36XX),
CLK(NULL,   "csi2_96m_fck", &csi2_96m_fck,  CK_34XX | CK_36XX),
CLK(NULL,   "usbhost_120m_fck", &usbhost_120m_fck,
CK_3430ES2PLUS | CK_AM35XX | CK_36XX),

Cheers.

-- 
Felipe Contreras
--
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

[RESEND] [PATCH 3.6.0- 4/6] ARM/pxa: use module_platform_driver macro

[Srinivas KANDAGATLA]

From: Srinivas Kandagatla 

This patch removes some code duplication by using
module_platform_driver.

Signed-off-by: Srinivas Kandagatla 
---
 arch/arm/mach-pxa/tosa-bt.c |   15 +--
 1 files changed, 1 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-pxa/tosa-bt.c b/arch/arm/mach-pxa/tosa-bt.c
index b9b1e5c..fe2a9e1 100644
--- a/arch/arm/mach-pxa/tosa-bt.c
+++ b/arch/arm/mach-pxa/tosa-bt.c
@@ -132,17 +132,4 @@ static struct platform_driver tosa_bt_driver = {
.owner = THIS_MODULE,
},
 };
-
-
-static int __init tosa_bt_init(void)
-{
-   return platform_driver_register(&tosa_bt_driver);
-}
-
-static void __exit tosa_bt_exit(void)
-{
-   platform_driver_unregister(&tosa_bt_driver);
-}
-
-module_init(tosa_bt_init);
-module_exit(tosa_bt_exit);
+module_platform_driver(tosa_bt_driver);
-- 
1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RESEND] [PATCH 3.6.0- 1/6] ARM/omap1: use module_platform_driver macro

[Srinivas KANDAGATLA]

From: Srinivas Kandagatla 

This patch removes some code duplication by using
module_platform_driver.

Signed-off-by: Srinivas Kandagatla 
---
 arch/arm/mach-omap1/mailbox.c |   14 +-
 1 files changed, 1 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index e962926..45c8719 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -179,19 +179,7 @@ static struct platform_driver omap1_mbox_driver = {
.name   = "omap-mailbox",
},
 };
-
-static int __init omap1_mbox_init(void)
-{
-   return platform_driver_register(&omap1_mbox_driver);
-}
-
-static void __exit omap1_mbox_exit(void)
-{
-   platform_driver_unregister(&omap1_mbox_driver);
-}
-
-module_init(omap1_mbox_init);
-module_exit(omap1_mbox_exit);
+module_platform_driver(omap1_mbox_driver);
 
 MODULE_LICENSE("GPL v2");
 MODULE_DESCRIPTION("omap mailbox: omap1 architecture specific functions");
-- 
1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RESEND] [PATCH 3.6.0- 6/6] omap_rng: use module_platform_driver macro

[Srinivas KANDAGATLA]

From: Srinivas Kandagatla 

This patch removes some code duplication by using
module_platform_driver.

Signed-off-by: Srinivas Kandagatla 
---
 drivers/char/hw_random/omap-rng.c |   14 +-
 1 files changed, 1 insertions(+), 13 deletions(-)

diff --git a/drivers/char/hw_random/omap-rng.c 
b/drivers/char/hw_random/omap-rng.c
index a5effd8..29732c6 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -217,19 +217,7 @@ static struct platform_driver omap_rng_driver = {
.probe  = omap_rng_probe,
.remove = __exit_p(omap_rng_remove),
 };
-
-static int __init omap_rng_init(void)
-{
-   return platform_driver_register(&omap_rng_driver);
-}
-
-static void __exit omap_rng_exit(void)
-{
-   platform_driver_unregister(&omap_rng_driver);
-}
-
-module_init(omap_rng_init);
-module_exit(omap_rng_exit);
+module_platform_driver(omap_rng_driver);
 
 MODULE_AUTHOR("Deepak Saxena (and others)");
 MODULE_LICENSE("GPL");
-- 
1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RESEND] [PATCH 3.6.0- 2/6] ARM/omap2: use module_platform_driver macro

[Srinivas KANDAGATLA]

From: Srinivas Kandagatla 

This patch removes some code duplication by using
module_platform_driver.

Signed-off-by: Srinivas Kandagatla 
---
 arch/arm/mach-omap2/mailbox.c |   14 +-
 1 files changed, 1 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 0d97456..eb64ca9 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -409,19 +409,7 @@ static struct platform_driver omap2_mbox_driver = {
.name = "omap-mailbox",
},
 };
-
-static int __init omap2_mbox_init(void)
-{
-   return platform_driver_register(&omap2_mbox_driver);
-}
-
-static void __exit omap2_mbox_exit(void)
-{
-   platform_driver_unregister(&omap2_mbox_driver);
-}
-
-module_init(omap2_mbox_init);
-module_exit(omap2_mbox_exit);
+module_platform_driver(omap2_mbox_driver);
 
 MODULE_LICENSE("GPL v2");
 MODULE_DESCRIPTION("omap mailbox: omap2/3/4 architecture specific functions");
-- 
1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RESEND] [PATCH 3.6.0- 0/6] ARM: use module_platform_driver macro

[Srinivas KANDAGATLA]

From: Srinivas Kandagatla 

Running Coccinelle lookup pattern like below on the 
latest kernel showed about 52 hits. This patch series is a subset 
of those 52 patches, so that it will be easy for maintainers to review.

@  @
- initfunc(void)
- { return platform_driver_register(&dr); }

...

- module_init(initfunc);
...

- exitfunc(void)
- { platform_driver_unregister(&dr); }

...

- module_exit(exitfunc);
+ module_platform_driver(dr); 

Srinivas Kandagatla (6):
  ARM/omap1: use module_platform_driver macro
  ARM/omap2: use module_platform_driver macro
  ARM/pxa: use module_platform_driver macro
  ARM/pxa: use module_platform_driver macro
  ARM/omap: use module_platform_driver macro
  omap_rng: use module_platform_driver macro

 arch/arm/mach-omap1/mailbox.c |   14 +-
 arch/arm/mach-omap2/mailbox.c |   14 +-
 arch/arm/mach-pxa/pxa3xx-ulpi.c   |   13 +
 arch/arm/mach-pxa/tosa-bt.c   |   15 +--
 arch/arm/plat-omap/dmtimer.c  |   13 +
 drivers/char/hw_random/omap-rng.c |   14 +-
 6 files changed, 6 insertions(+), 77 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

[RESEND] [PATCH 3.6.0- 5/6] ARM/omap: use module_platform_driver macro

[Srinivas KANDAGATLA]

From: Srinivas Kandagatla 

This patch removes some code duplication by using
module_platform_driver.

Signed-off-by: Srinivas Kandagatla 
---
 arch/arm/plat-omap/dmtimer.c |   13 +
 1 files changed, 1 insertions(+), 12 deletions(-)

diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 938b50a..c89fc6a 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -786,19 +786,8 @@ static struct platform_driver omap_dm_timer_driver = {
},
 };
 
-static int __init omap_dm_timer_driver_init(void)
-{
-   return platform_driver_register(&omap_dm_timer_driver);
-}
-
-static void __exit omap_dm_timer_driver_exit(void)
-{
-   platform_driver_unregister(&omap_dm_timer_driver);
-}
-
 early_platform_init("earlytimer", &omap_dm_timer_driver);
-module_init(omap_dm_timer_driver_init);
-module_exit(omap_dm_timer_driver_exit);
+module_platform_driver(omap_dm_timer_driver);
 
 MODULE_DESCRIPTION("OMAP Dual-Mode Timer Driver");
 MODULE_LICENSE("GPL");
-- 
1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RESEND] [PATCH 3.6.0- 3/6] ARM/pxa: use module_platform_driver macro

[Srinivas KANDAGATLA]

From: Srinivas Kandagatla 

This patch removes some code duplication by using
module_platform_driver.

Signed-off-by: Srinivas Kandagatla 
---
 arch/arm/mach-pxa/pxa3xx-ulpi.c |   13 +
 1 files changed, 1 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-pxa/pxa3xx-ulpi.c b/arch/arm/mach-pxa/pxa3xx-ulpi.c
index 7dbe3cc..e329cce 100644
--- a/arch/arm/mach-pxa/pxa3xx-ulpi.c
+++ b/arch/arm/mach-pxa/pxa3xx-ulpi.c
@@ -384,18 +384,7 @@ static struct platform_driver pxa3xx_u2d_ulpi_driver = {
 .probe  = pxa3xx_u2d_probe,
 .remove = pxa3xx_u2d_remove,
 };
-
-static int pxa3xx_u2d_ulpi_init(void)
-{
-   return platform_driver_register(&pxa3xx_u2d_ulpi_driver);
-}
-module_init(pxa3xx_u2d_ulpi_init);
-
-static void __exit pxa3xx_u2d_ulpi_exit(void)
-{
-   platform_driver_unregister(&pxa3xx_u2d_ulpi_driver);
-}
-module_exit(pxa3xx_u2d_ulpi_exit);
+module_platform_driver(pxa3xx_u2d_ulpi_driver);
 
 MODULE_DESCRIPTION("PXA3xx U2D ULPI driver");
 MODULE_AUTHOR("Igor Grinberg");
-- 
1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html