Re: [PATCH V3 3/3] mfd: palmas: Add support for optional wakeup
On Fri, 19 Sep 2014, Tony Lindgren wrote: > * Thomas Gleixner [140919 12:47]: > > Why on earth are you wanting tasklets in there? That's just silly, > > really. > > Lack of a framework on driver side to cope with this in a generic > way? :p So instead of creating such a thing we rather have a completely ass backward workaround which spreads itself all over the tree? You SoC folks really need a quarterly sanity check. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ARM: edma: unconditionally ack the error interrupt
On 09/18/2014 07:12 PM, Sebastian Andrzej Siewior wrote:
> * Peter Ujfalusi | 2014-09-18 12:42:24 [+0300]:
>
>> My hunch on what could be causing this that we might have unhandled dma event
>> and another comes. This will flag the EDMA_EMR register. Any change in this
>> register will assert error interrupt which can only be cleared by writing to
>> EDMA_EMRC register.
>> The EDMA_EMRC register bits also cleared on edma_start(), edma_stop() and
>> edma_clean_channel() apart from the error interrupt handler.
>> So it is possible that we have missed event on one of the channels but a stop
>> might clear the event so in the interrupt hander we do not see this.
>> I think it would be good to understand what is going on the backround...
>> Can you print out the EDMA_EMCR just before we clear it in the places I have
>> mentioned? We might get better understanding on which stage we clear it and
>> probably we can understand how to fix this properly so we are not going to
>> have missed events on channels.
>
> Okay. For the protocol I applied this patch:
>
> diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
> index 160460ae3a49..16598625a4d1 100644
> --- a/arch/arm/common/edma.c
> +++ b/arch/arm/common/edma.c
> @@ -422,20 +422,24 @@ static irqreturn_t dma_ccerr_handler(int irq, void
> *data)
> int i;
> int ctlr;
> unsigned int cnt = 0;
> + u32 emr0;
>
> ctlr = irq2ctlr(irq);
> if (ctlr < 0)
> return IRQ_NONE;
>
> dev_dbg(data, "dma_ccerr_handler\n");
> + emr0 = edma_read_array(ctlr, EDMA_EMR, 0);
>
> - if ((edma_read_array(ctlr, EDMA_EMR, 0) == 0) &&
> + if ((emr0 == 0) &&
> (edma_read_array(ctlr, EDMA_EMR, 1) == 0) &&
> (edma_read(ctlr, EDMA_QEMR) == 0) &&
> (edma_read(ctlr, EDMA_CCERR) == 0)) {
> edma_write(ctlr, EDMA_EEVAL, 1);
> + trace_printk("Unhandled\n");
> return IRQ_NONE;
> }
> + trace_printk("emr0: %x\n", emr0);
>
> while (1) {
> int j = -1;
> @@ -1310,6 +1314,9 @@ int edma_start(unsigned channel)
> pr_debug("EDMA: ER%d %08x\n", j,
> edma_shadow0_read_array(ctlr, SH_ER, j));
> /* Clear any pending event or error */
> + trace_printk("j%d mask%x EDMA_EMCR: %x\n",
> + j, mask,
> + edma_read_array(ctlr, EDMA_EMCR, j));
> edma_write_array(ctlr, EDMA_ECR, j, mask);
> edma_write_array(ctlr, EDMA_EMCR, j, mask);
> /* Clear any SER */
> @@ -1347,6 +1354,9 @@ void edma_stop(unsigned channel)
> edma_shadow0_write_array(ctlr, SH_EECR, j, mask);
> edma_shadow0_write_array(ctlr, SH_ECR, j, mask);
> edma_shadow0_write_array(ctlr, SH_SECR, j, mask);
> + trace_printk("j%d mask%x EDMA_EMCR: %x\n",
> + j, mask,
> + edma_read_array(ctlr, EDMA_EMCR, j));
> edma_write_array(ctlr, EDMA_EMCR, j, mask);
>
> pr_debug("EDMA: EER%d %08x\n", j,
> @@ -1387,6 +1397,9 @@ void edma_clean_channel(unsigned channel)
> edma_read_array(ctlr, EDMA_EMR, j));
> edma_shadow0_write_array(ctlr, SH_ECR, j, mask);
> /* Clear the corresponding EMR bits */
> + trace_printk("j%d mask%x EDMA_EMCR: %x\n",
> + j, mask,
> + edma_read_array(ctlr, EDMA_EMCR, j));
> edma_write_array(ctlr, EDMA_EMCR, j, mask);
> /* Clear any SER */
> edma_shadow0_write_array(ctlr, SH_SECR, j, mask);
>
> --
>
> and the result is something like this:
>
>-0 [000] dnh. 303.356403: edma_start: j0 mask800
> EDMA_EMCR: 0
>-0 [000] d.h. 303.396721: edma_stop: j0 mask800
> EDMA_EMCR: 0
>-0 [000] dnh. 303.557103: edma_start: j0 mask800
> EDMA_EMCR: 0
>-0 [000] dnh. 303.557129: edma_stop: j0 mask400
> EDMA_EMCR: 0
>-0 [000] dnH. 303.557142: dma_ccerr_handler: Unhandled
> less-2612 [000] d... 303.557237: edma_start: j0 mask400
> EDMA_EMCR: 0
> less-2612 [000] d.h. 303.562491: edma_stop: j0 mask400
> EDMA_EMCR: 0
> less-2612 [000] d... 303.564475: edma_start: j0 mask400
> EDMA_EMCR: 0
>
> The full trace is at [0]. I haven't found a single entry where EDMA_EMCR
> was != 0 at those spots. *If* there is a edma_stop() before the
> interrupt then the interrupt remains unhandled. If there is a
> edma_start() with mask 800 then we have dma_ccerr_handler() with a
> mask of 400.
mask 800 means URXEVT0 (UART0 rx), 400 is UTXEVT0 (UART0 tx) events.
But it is clear that my theory was not even close to what's going on.
Do you have some tool which can be used to reproduce this issue?
Re: [PATCH 00/26] ARM: OMAP2+: PRCM cleanups for 3.18 merge window
On 09/18/2014 02:16 PM, Tony Lindgren wrote: > * Tony Lindgren [140918 10:17]: >> * Tero Kristo [140901 11:09]: >>> Hi, >>> >>> This set contains PRCM related cleanups meant for 3.18 merge window. >>> These are based on top of 3.17-rc1 + the PRM set from Nishanth Menon >>> (http://article.gmane.org/gmane.linux.ports.arm.kernel/350305.) Nishanth's >>> set is used as basis to avoid merge issues. >>> >>> Purpose of this work is to eventually convert the PRCM code into a >>> separate driver, but this is done in incremental parts as the amount >>> of changes is substantial. Expected conclusion of this work is 3.19 >>> if everything goes fine. >>> >>> This part of the work mostly moves some of the SoC specific PRCM driver >>> calls under generic version of the same, and adds SoC-ops to support >>> these on the driver level. >>> >>> Working branch posted here: >>> >>> tree: https://github.com/t-kristo/linux-pm.git >>> branch: for-v3.18/prcm-cleanup >> >> Paul, any comments on this series? > > Just gave this branch a quick try, it seems to work with off-idle > for me when merged with current linux-omap master branch. The following > merge resolution is needed because of the recent pre es3.1 fix though. > > I've pushed out this merged with all the other pending patches into > omap-for-v3.18/tmp-merge-2014-09-18. > > Nishant, care to give it a try and check your recent PM related > changes work with it? > Sure. Sorry about the delay.. needed to find some workarounds for working with my board farm.. Tested-by: Nishanth Menon Based on: omap-for-v3.18/tmp-merge-2014-09-18 0164b2d Merge branch 'omap-for-v3.18/prcm' into omap-for-v3.18/tmp-merge Test #1: basic testing Added 69c6133 HACK: Makefile: Build a uImage with dtb already appended (for legacy boards) commit 0164b2dbe83e885a53b0c9a99a508bdbfdf7ee6d BASIC boot 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2zy9OUOMM 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2t0JaiHYf 3: am3517-evm: Boot PASS: http://slexy.org/raw/s2SRkMMQwp 4: am37x-evm: Boot PASS: http://slexy.org/raw/s20T0sq5dp 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s2AVYqDVBf 6: am43xx-gpevm: Boot PASS: http://slexy.org/raw/s213N14B9r 7: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s21yyMkFRS 8: beagleboard-vanilla: Boot PASS: http://slexy.org/raw/s2SYJOHRwI 9: beaglebone-black: Boot PASS: http://slexy.org/raw/s214QDgb06 10: beaglebone: Boot PASS: http://slexy.org/raw/s21SOLcjMD 11: craneboard: Boot PASS: http://slexy.org/raw/s218cXoYSl 12: dra72x-evm: Boot FAIL: http://slexy.org/raw/s21BAnAW8N 13: dra7xx-evm: Boot PASS: http://slexy.org/raw/s21kf4G5Sh 14: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s21QIGwFOM 15: n900: Boot PASS: http://slexy.org/raw/s21T5xECo2 16: omap5-evm: Boot PASS: http://slexy.org/raw/s20qxa3iPw 17: pandaboard-es: Boot PASS: http://slexy.org/raw/s2Fh0hMW7n 18: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s2vqUc528i 19:sdp2430: Boot PASS: http://slexy.org/raw/s21gAsEAeD 20:sdp3430: Boot PASS: http://slexy.org/raw/s2dvThSn5D TOTAL = 20 boards, Booted Boards = 19, No Boot boards = 1 Test #2: PM test (cpufreq/cpuidle/suspend-resume where applicable) Testing script: (http://slexy.org/view/s21SRQehwu) Added the following patches: 59bf40d ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support (discussion still going on https://patchwork.kernel.org/patch/4764661/ - but good to know if it still continues to work with PRM changes). 69c6133 HACK: Makefile: Build a uImage with dtb already appended (for legacy boards) b854ca8 gpio: omap: Fix interrupt names (https://patchwork.kernel.org/patch/4854511/) c50fc8b pinctrl: single: AM437x: Add pinctrl compatibility 37d17bf pinctrl: single: Add DRA7 pinctrl compatibility 74121c6 pinctrl: bindings: Add OMAP pinctrl binding (all of the above are in linux-next) efb2486 clk: prevent erronous parsing of children during rate change b92ac70 clk: ti: dra7-atl: Provide error check for incoming parameters in set_rate 96e8b6b clk: ti: divider: Provide error check for incoming parameters in set_rate (all above picked up by mike) 92e5e74 ARM: OMAP2+ / pm_debug: add support for wakeup_timer configuration (wakeup timer for testing purposes - remote boards) with these: commit 0164b2dbe83e885a53b0c9a99a508bdbfdf7ee6d + Additional patches basic PM test 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2xRMuVHvj 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2qEHyI9Rs 3: am3517-evm: Boot PASS: http://slexy.org/raw/s2Vptpboop 4: am37x-evm: Boot PASS: http://slexy.org/raw/s21TKVsyet 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s20KGye4N9 6: am43xx-gpevm: Boot PASS: http://slexy.org/raw/s201uuCOp2 7: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s21ChQP74I 8: beagleboard-vanilla: Boot PASS: http://slexy.org/raw/s20oagBAsl 9: beaglebone-black: Boot PASS: http://slexy.org/raw/s2VT200vL0 10: beaglebone: Boot PASS: http://slexy.org/raw/s20raoHSya 11: craneboard:
Re: [PATCH V3 3/3] mfd: palmas: Add support for optional wakeup
* Thomas Gleixner [140919 12:47]:
> On Fri, 19 Sep 2014, Tony Lindgren wrote:
> > * Thomas Gleixner [140919 10:37]:
> > >From hardware point of view the wake-up events behave like interrupts
> > and could also be used as the only interrupt in some messed up cases.
> > That avoids all kinds of custom APIs from driver point.
> >
> > The re-entrancy problem we've most likely had ever since we enabled
> > the PRCM interrupts, and maybe that's why I did not even consider
> > that part. I think before that we were calling the driver interrupt
> > after waking up from the PM code..
> >
> > Anyways, how about the following to deal with the re-entrancy problem:
> >
> > 1. The wake-up interrupt handler must have a separate interrupt
> >handler that just calls tasklet_schedule()
> >
> > 2. The device interrupt handler also just calls tasklet_schedule()
> >
> > 3. The tasklet then does pm_runtime_get, handles the registers, and
> >so on.
> >
> > Or would we still have a re-entrancy problem somewhere else with
> > that?
>
> Why on earth are you wanting tasklets in there? That's just silly,
> really.
Lack of a framework on driver side to cope with this in a generic
way? :p
> The wakeup handler is supposed to bring the thing out of deep sleep
> and nothing else. All you want it to do is to mask itself and save the
> information that the real device irq is pending.
Yes that is enough.
> A stub handler for the wakeup irq is enough. We can have that in the
> irq/pm core and all it would do is simply:
>
> irqreturn_t handle_jinxed_wakeup_irq(unsigned irq, void *dev_id)
> {
> unsigned device_irq = get_dev_irq(dev_id);
>
> force_mask(irq);
> set_irq_pending(device_irq);
> return HANDLED;
> }
>
> So on resume_device_irqs() the real device interrupt gets reenabled
> and unmasked (if it was masked) and the interrupt gets resent either
> in hardware (level or retrigger) or by the software resend mechanism.
>
> That completely avoids tasklets, reentrant irq handlers and all other
> crap which might be required.
Okie dokie, that sounds good to me. Having this generic for the
drivers would be excellent, that's the missing piece.
Thanks,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 3/3] mfd: palmas: Add support for optional wakeup
On Fri, 19 Sep 2014, Tony Lindgren wrote:
> * Thomas Gleixner [140919 10:37]:
> >From hardware point of view the wake-up events behave like interrupts
> and could also be used as the only interrupt in some messed up cases.
> That avoids all kinds of custom APIs from driver point.
>
> The re-entrancy problem we've most likely had ever since we enabled
> the PRCM interrupts, and maybe that's why I did not even consider
> that part. I think before that we were calling the driver interrupt
> after waking up from the PM code..
>
> Anyways, how about the following to deal with the re-entrancy problem:
>
> 1. The wake-up interrupt handler must have a separate interrupt
>handler that just calls tasklet_schedule()
>
> 2. The device interrupt handler also just calls tasklet_schedule()
>
> 3. The tasklet then does pm_runtime_get, handles the registers, and
>so on.
>
> Or would we still have a re-entrancy problem somewhere else with
> that?
Why on earth are you wanting tasklets in there? That's just silly,
really.
The wakeup handler is supposed to bring the thing out of deep sleep
and nothing else. All you want it to do is to mask itself and save the
information that the real device irq is pending.
A stub handler for the wakeup irq is enough. We can have that in the
irq/pm core and all it would do is simply:
irqreturn_t handle_jinxed_wakeup_irq(unsigned irq, void *dev_id)
{
unsigned device_irq = get_dev_irq(dev_id);
force_mask(irq);
set_irq_pending(device_irq);
return HANDLED;
}
So on resume_device_irqs() the real device interrupt gets reenabled
and unmasked (if it was masked) and the interrupt gets resent either
in hardware (level or retrigger) or by the software resend mechanism.
That completely avoids tasklets, reentrant irq handlers and all other
crap which might be required.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 3/3] mfd: palmas: Add support for optional wakeup
* Thomas Gleixner [140919 10:37]: > On Fri, 19 Sep 2014, Nishanth Menon wrote: > > On 08:37-20140919, Thomas Gleixner wrote: > > > The other omap drivers using this have the same issue ... And of > > > course they are subtly different. > > > > > > The uart one handles the actual device interrupt, which is violating > > > the general rule of possible interrupt reentrancy in the pm-runtime > > > case if the two interrupts are affine to two different cores. Yes, > > > it's protected by a lock and works by chance > > > > > > The mmc one issues a disable_irq_nosync() in the wakeup irq handler > > > itself. > > > > > > WHY does one driver need that and the other does not? You are not even > > > able to come up with a common scheme for OMAP. I don't want to see the > > > mess others are going to create when this stuff becomes more used. > > > > > > Thanks, > > > > > > tglx > > > > I think I understand your concern - I request Tony to comment about > > this. I mean, I can try and hook things like uart in other drivers > > (like https://patchwork.kernel.org/patch/4759171/ ), but w.r.t overall > > generic usage guideline wise, I would prefer Tony to comment. > > No, the uart and that i2c thing are just wrong. Assume the following > > device irq affine to cpu0 > wakeup irq affine to cpu1 > > CPU 0 CPU 1 > > runtime suspend > > enable_wake(wakeup irq); > > wakeup interrupt is raiseddevice interrupt is raised > > dev_handler(device) dev_handler(device) > > It might work due to locking, but it is nevertheless wrong. Interrupt > handlers for devices are guaranteed not to be reentrant. And this > brilliant stuff simply violates that guarantee. So, no. It's wrong > even if it happens to work by chance. Hmm yeah that's a good point indeed. >From hardware point of view the wake-up events behave like interrupts and could also be used as the only interrupt in some messed up cases. That avoids all kinds of custom APIs from driver point. The re-entrancy problem we've most likely had ever since we enabled the PRCM interrupts, and maybe that's why I did not even consider that part. I think before that we were calling the driver interrupt after waking up from the PM code.. Anyways, how about the following to deal with the re-entrancy problem: 1. The wake-up interrupt handler must have a separate interrupt handler that just calls tasklet_schedule() 2. The device interrupt handler also just calls tasklet_schedule() 3. The tasklet then does pm_runtime_get, handles the registers, and so on. Or would we still have a re-entrancy problem somewhere else with that? 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 v4 4/7] ARM: l2c: Add support for overriding prefetch settings
On 19/09/2014 at 17:39:32 +0100, Russell King - ARM Linux wrote : > On Fri, Sep 19, 2014 at 11:50:01AM +0200, Alexandre Belloni wrote: > > On 26/08/2014 at 16:17:57 +0200, Tomasz Figa wrote : > > > Firmware on certain boards (e.g. ODROID-U3) can leave incorrect L2C > > > prefetch > > > settings configured in registers leading to crashes if L2C is enabled > > > without overriding them. This patch introduces bindings to enable > > > prefetch settings to be specified from DT and necessary support in the > > > driver. > > > > > > Signed-off-by: Tomasz Figa > > > > Tested-by: Alexandre Belloni > > > > It is working and useful on Atmel's sama5d4 were the bootloader is not > > configuring the L2C prefetch. However, I'm wondering whether we should > > add support for setting L310_PREFETCH_CTRL_DATA_PREFETCH and > > L310_PREFETCH_CTRL_INSTR_PREFETCH. I'm currently doing it by using > > ".l2c_aux_val= L310_AUX_CTRL_DATA_PREFETCH | > > L310_AUX_CTRL_INSTR_PREFETCH" (those are the same bits) but this has the > > disadvantage of displaying the "L2C: platform modifies aux control > > register:" twice. > > The L2C documentation, freely available from the ARM infocentre website, > has the answer to this for you. > > The two bits in the prefetch control register which control the data > and instruction prefetching are aliases of the aux control register. > If you set them to a value in one register, they are reflected in the > other. > > The reason for that is that once the L2 cache is enabled, writes to > the aux control register are no longer permitted, but it's safe to > enable and disable the prefetching with the cache already enabled. > This reason is even stated in the documentation. > Yeah, so my question still holds, should we have an other way to enable/disable I/D prefetch by adding two other DT bindings ? -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- 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 3/3] mfd: palmas: Add support for optional wakeup
On Fri, 19 Sep 2014, Nishanth Menon wrote: > On 08:37-20140919, Thomas Gleixner wrote: > > The other omap drivers using this have the same issue ... And of > > course they are subtly different. > > > > The uart one handles the actual device interrupt, which is violating > > the general rule of possible interrupt reentrancy in the pm-runtime > > case if the two interrupts are affine to two different cores. Yes, > > it's protected by a lock and works by chance > > > > The mmc one issues a disable_irq_nosync() in the wakeup irq handler > > itself. > > > > WHY does one driver need that and the other does not? You are not even > > able to come up with a common scheme for OMAP. I don't want to see the > > mess others are going to create when this stuff becomes more used. > > > > Thanks, > > > > tglx > > I think I understand your concern - I request Tony to comment about > this. I mean, I can try and hook things like uart in other drivers > (like https://patchwork.kernel.org/patch/4759171/ ), but w.r.t overall > generic usage guideline wise, I would prefer Tony to comment. No, the uart and that i2c thing are just wrong. Assume the following device irq affine to cpu0 wakeup irq affine to cpu1 CPU 0 CPU 1 runtime suspend enable_wake(wakeup irq); wakeup interrupt is raised device interrupt is raised dev_handler(device) dev_handler(device) It might work due to locking, but it is nevertheless wrong. Interrupt handlers for devices are guaranteed not to be reentrant. And this brilliant stuff simply violates that guarantee. So, no. It's wrong even if it happens to work by chance. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/26] ARM: OMAP2+: PRCM cleanups for 3.18 merge window
On Fri, 19 Sep 2014, Paul Walmsley wrote: > However, I saw the following crash at boot on 37xxevm during one of > the boot test. Ran thirty more boot tests afterwards on that board > and it did not recur. It seems unlikely that the problem is related > to this series, but looks like we may have some intermittent boot > failure or race on 37xx :-( ... > [4.892211] Unhandled fault: external abort on non-linefetch (0x1028) at > 0xfa318034 > [4.900299] Internal error: : 1028 [#1] SMP ARM > [4.905090] Modules linked in: > [4.908325] CPU: 0 PID: 0 Comm: swapper/0 Not tainted > 3.17.0-rc5-12866-g0164b2d #1 > [4.916320] task: c0835db0 ti: c082a000 task.ti: c082a000 > [4.922027] PC is at omap2_gp_timer_set_next_event+0x24/0x78 > [4.928009] LR is at clockevents_program_event+0xc0/0x148 > [4.933715] pc : []lr : []psr: 0193 > [4.933715] sp : c082bed8 ip : fp : > [4.945800] r10: r9 : 24101100 r8 : c0839080 > [4.951324] r7 : 0001 r6 : 237bc339 r5 : 009f r4 : 3d9759e7 > [4.958190] r3 : fa318034 r2 : c08cb920 r1 : 0003 r0 : fec1 > [4.965087] Flags: nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment > kernel > [4.972900] Control: 10c5387d Table: 80004019 DAC: 0015 > [4.978942] Process swapper/0 (pid: 0, stack limit = 0xc082a248) > [4.985290] Stack: (0xc082bed8 to 0xc082c000) > [4.989868] bec0: > 237bc339 0001 > [4.998504] bee0: 0001 24101100 0001 cfc7d6c8 0001 cfc7da50 > cfc7d720 c00a4780 > [5.007141] bf00: c00962b0 cfc7d720 c0096180 0001 > 0001 c08256c8 > [5.015777] bf20: c082a000 c08256c8 c00962b0 237b4c04 0001 > 0002 a193 > [5.024414] bf40: 00989680 24101100 0001 cfc7da50 > c108cc78 > [5.033020] bf60: c00962b0 0002 0001 > c108cc78 c00a56f0 > [5.041656] bf80: 0002 237b4c04 0001 c08c8ce8 c082a000 > c08c8ce8 > [5.050292] bfa0: c08329dc c0832978 cfc7f0f8 c0072808 c0559928 c08270f0 > c08caf40 c080fdc0 > [5.058929] bfc0: c07c3b74 c07c35f0 > c080fdc0 > [5.067535] bfe0: c08cb154 c0832968 c080fdbc c083763c 80004059 80008074 > > [5.076171] [] (omap2_gp_timer_set_next_event) from [] > (clockevents_program_event+0xc0/0x148) > [5.087005] [] (clockevents_program_event) from [] > (tick_program_event+0x44/0x54) > [5.096771] [] (tick_program_event) from [] > (__hrtimer_start_range_ns+0x3c0/0x4a0) > [5.106597] [] (__hrtimer_start_range_ns) from [] > (hrtimer_start_range_ns+0x24/0x2c) > [5.116577] [] (hrtimer_start_range_ns) from [] > (tick_nohz_idle_exit+0x140/0x1ec) > [5.126342] [] (tick_nohz_idle_exit) from [] > (cpu_startup_entry+0xf4/0x2d0) > [5.135528] [] (cpu_startup_entry) from [] > (start_kernel+0x340/0x3a8) > [5.144165] [] (start_kernel) from [<80008074>] (0x80008074) > [5.151031] Code: 13a0c000 0a04 ee07cfba e592301c (e5931000) > [5.157470] ---[ end trace f92de024d996d904 ]--- > [5.162353] Kernel panic - not syncing: Attempted to kill the idle task! > [5.169433] ---[ end Kernel panic - not syncing: Attempted to kill the > idle task! Actually it just occurred to me that if something broke *wait_target_ready(), we'd expect to see intermittent failures like this, and this series touches *wait_target_ready(). So it might be worth taking a look at that with a magnifying glass to make sure that it's working. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/26] ARM: OMAP2+: PRCM cleanups for 3.18 merge window
On Thu, 18 Sep 2014, Tony Lindgren wrote: > * Tony Lindgren [140918 10:17]: > > * Tero Kristo [140901 11:09]: > > > Hi, > > > > > > This set contains PRCM related cleanups meant for 3.18 merge window. > > > These are based on top of 3.17-rc1 + the PRM set from Nishanth Menon > > > (http://article.gmane.org/gmane.linux.ports.arm.kernel/350305.) Nishanth's > > > set is used as basis to avoid merge issues. > > > > > > Purpose of this work is to eventually convert the PRCM code into a > > > separate driver, but this is done in incremental parts as the amount > > > of changes is substantial. Expected conclusion of this work is 3.19 > > > if everything goes fine. > > > > > > This part of the work mostly moves some of the SoC specific PRCM driver > > > calls under generic version of the same, and adds SoC-ops to support > > > these on the driver level. > > > > > > Working branch posted here: > > > > > > tree: https://github.com/t-kristo/linux-pm.git > > > branch: for-v3.18/prcm-cleanup > > > > Paul, any comments on this series? > > Just gave this branch a quick try, it seems to work with off-idle > for me when merged with current linux-omap master branch. The following > merge resolution is needed because of the recent pre es3.1 fix though. > > I've pushed out this merged with all the other pending patches into > omap-for-v3.18/tmp-merge-2014-09-18. Ran the tests here, they seemed to pass: http://www.pwsan.com/omap/testlogs/tmp-merge-2014-09-18/20140918132302/ However, I saw the following crash at boot on 37xxevm during one of the boot test. Ran thirty more boot tests afterwards on that board and it did not recur. It seems unlikely that the problem is related to this series, but looks like we may have some intermittent boot failure or race on 37xx :-( - Paul Texas Instruments X-Loader 1.47 (Jan 14 2011 - 15:43:28) Starting X-loader on MMC Reading boot sector 212836 Bytes Read from MMC Starting OS Bootloader from MMC... Starting OS Bootloader... U-Boot 2010.06 (Jan 14 2011 - 15:43:45) OMAP34xx/35xx-GP ES2.1, CPU-OPP2 L3-165MHz OMAP3 EVM board + LPDDR/NAND I2C: ready DRAM: 256 MiB NAND: 512 MiBhelp |230400 8N1 | NOR | script /home/p | VT102 | Offline In:serial Out: serial Err: serial Read back SMSC id 0x9220 Die ID #368000229ff8016071640902c013 Net: smc911x-0 Hit any key to stop autoboot: 0 OMAP3_EVM # OMAP3_EVM # OMAP3_EVM # dhcp smc911x: detected LAN9220 controller smc911x: phy initialized smc911x: MAC 00:50:c2:7e:99:42 BOOTP broadcast 1 DHCP client bound to address 192.168.57.131 Using smc911x-0 device TFTP from server 192.168.57.1; our IP address is 192.168.57.131 Filename 'uImage-dtb.omap3-evm-37xx'. Load address: 0x8200 Loading: # # # # # # # # # # # # # # done Bytes transferred = 4452813 (43f1cd hex) OMAP3_EVM # setenv bootargs console=ttyO0,115200n8 ignore_loglevel earlyprintk root=/dev/nfs nfsroot=192.168.57.1:/srv/nfs4/rootfs2 nfsrootdebug ip=dhcp init=/bin/sh OMAP3_EVM # OMAP3_EVM # bootm ## Booting kernel from Legacy Image at 8200 ... Image Name: Linux- Image Type: ARM Linux Kernel Image (uncompressed) Data Size:4452749 Bytes = 4.2 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.17.0-rc5-12866-g0164b2d (paul@nozomi) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP Thu Sep 18 13:29:12 MDT 2014 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine model: TI OMAP37XX EVM (TMDSEVM3730) [0.00] debug: ignoring loglevel setting. [0.00] cma: Reserved 16 MiB at 8e80 [0.00] Memory policy: Data cache writeback [0.00] On node 0 totalpages: 65280 [0.00] free_area_init_node: node 0, pgdat c08c5480,
Re: [PATCH v4 4/7] ARM: l2c: Add support for overriding prefetch settings
On Fri, Sep 19, 2014 at 11:50:01AM +0200, Alexandre Belloni wrote: > On 26/08/2014 at 16:17:57 +0200, Tomasz Figa wrote : > > Firmware on certain boards (e.g. ODROID-U3) can leave incorrect L2C prefetch > > settings configured in registers leading to crashes if L2C is enabled > > without overriding them. This patch introduces bindings to enable > > prefetch settings to be specified from DT and necessary support in the > > driver. > > > > Signed-off-by: Tomasz Figa > > Tested-by: Alexandre Belloni > > It is working and useful on Atmel's sama5d4 were the bootloader is not > configuring the L2C prefetch. However, I'm wondering whether we should > add support for setting L310_PREFETCH_CTRL_DATA_PREFETCH and > L310_PREFETCH_CTRL_INSTR_PREFETCH. I'm currently doing it by using > ".l2c_aux_val= L310_AUX_CTRL_DATA_PREFETCH | > L310_AUX_CTRL_INSTR_PREFETCH" (those are the same bits) but this has the > disadvantage of displaying the "L2C: platform modifies aux control > register:" twice. The L2C documentation, freely available from the ARM infocentre website, has the answer to this for you. The two bits in the prefetch control register which control the data and instruction prefetching are aliases of the aux control register. If you set them to a value in one register, they are reflected in the other. The reason for that is that once the L2 cache is enabled, writes to the aux control register are no longer permitted, but it's safe to enable and disable the prefetching with the cache already enabled. This reason is even stated in the documentation. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- 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] clk: ti: change clock init to use generic of_clk_init
On Thu, 18 Sep 2014, Tony Lindgren wrote: > * Tero Kristo [140821 06:52]: > > Previously, the TI clock driver initialized all the clocks hierarchically > > under each separate clock provider node. Now, each clock that requires > > IO access will instead check their parent node to find out which IO range > > to use. > > > > This patch allows the TI clock driver to use a few new features provided > > by the generic of_clk_init, and also allows registration of clock nodes > > outside the clock hierarchy (for example, any external clocks.) > > Paul, any comments on this one? Not at this point. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/26] ARM: OMAP2+: PRCM cleanups for 3.18 merge window
On Thu, 18 Sep 2014, Tony Lindgren wrote:
> * Tero Kristo [140901 11:09]:
> > Hi,
> >
> > This set contains PRCM related cleanups meant for 3.18 merge window.
> > These are based on top of 3.17-rc1 + the PRM set from Nishanth Menon
> > (http://article.gmane.org/gmane.linux.ports.arm.kernel/350305.) Nishanth's
> > set is used as basis to avoid merge issues.
> >
> > Purpose of this work is to eventually convert the PRCM code into a
> > separate driver, but this is done in incremental parts as the amount
> > of changes is substantial. Expected conclusion of this work is 3.19
> > if everything goes fine.
> >
> > This part of the work mostly moves some of the SoC specific PRCM driver
> > calls under generic version of the same, and adds SoC-ops to support
> > these on the driver level.
> >
> > Working branch posted here:
> >
> > tree: https://github.com/t-kristo/linux-pm.git
> > branch: for-v3.18/prcm-cleanup
>
> Paul, any comments on this series?
Patches 1, 3, 5, 8, 10, 13, 17, 18, 20, 21, 22, 23, 24 are:
Acked-by: Paul Walmsley
Here are some specific comments on a few other patches:
Regarding patch 7: The kerneldoc-nano function comments are good, but
should begin with "/**" rather than "/*". When that's fixed, it can be
considered acked by me.
Regarding patches 14, 15, 16: Non-static prm_* functions really should
start with omap*_ to avoid potential naming conflicts with other drivers
when these are moved to drivers/. (Obviously the same would apply for any
CM function names in other, future patches.) When that's fixed, it can be
considered acked by me.
Regarding patch 25: What are "I/O wakeup gaes" -- gates? When that's
fixed, an acked-by for me can be added.
Regarding patch 26: It seems wise to ensure that omap_prm_reset_system()
ends with a 'while(1) { cpu_relax(); }' or something similar, to ensure
that execution flow does not proceed past that point. At that point, it
should be possible to remove the "while(1) {}"s from omap44xx_restart(),
omap2xxx_restart(), etc. When that's fixed, an acked-by for me can be
added.
...
And some general comments: none of which should probably block this
series, but seemed worth noting:
Regarding patches 6 and 19: Tero, could you please share the DT node data
that you're planning to submit for the PRM, CM1, and CM2 on the OMAP4*
platforms? According to the TRM, these are separate IP blocks, with
separate OCP header register areas. So these should probably have
separate DT nodes, regs, etc. if the DTS files are to match the hardware.
The planned DTS data may impact the way these patches are written, at
least, if more patches are to be avoided later.
As far as patches 2, 4, 9, 11, and 12 go, I'll let those go without
comment.
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 3/3] mfd: palmas: Add support for optional wakeup
On 08:37-20140919, Thomas Gleixner wrote:
> On Thu, 18 Sep 2014, Nishanth Menon wrote:
> > On 17:57-20140918, Thomas Gleixner wrote:
> >
> > I suppose I can improve the commit message to elaborate this better?
> > Will that help?
>
> You also want to improve the comment in the empty handler.
OK. will do the same. Thanks for suggesting.
>
> > >
> > > > +*/
> > > > + return IRQ_NONE;
>
> And it still does not explain WHY you think that returning IRQ_NONE is
> the right thing to do here. You actually handle the interrupt, right?
> Just because the handler is an NOP does not mean you did not handle
> it.
Hmm.. My motivation for IRQ_NONE was because this specific handler does
not handle the interrupt. Now, from this discussion, I understand that I
should rather use IRQ_HANDLED since the event is indeed handled (just
not here).
Thank you for correcting my understanding. Will update in my next rev
(once we solve the following discussion)..
>
> > > > +static int palmas_i2c_suspend(struct i2c_client *i2c, pm_message_t
> > > > mesg)
> > > > +{
> > > > + struct palmas *palmas = i2c_get_clientdata(i2c);
> > > > + struct device *dev = &i2c->dev;
> > > > +
> > > > + if (!palmas->wakeirq)
> > > > + return 0;
> > > > +
> > > > + if (device_may_wakeup(dev))
> > > > + enable_irq(palmas->wakeirq);
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +static int palmas_i2c_resume(struct i2c_client *i2c)
> > > > +{
> > > > + struct palmas *palmas = i2c_get_clientdata(i2c);
> > > > + struct device *dev = &i2c->dev;
> > > > +
> > > > + if (!palmas->wakeirq)
> > > > + return 0;
> > > > +
> > > > + if (device_may_wakeup(dev))
> > > > + disable_irq_nosync(palmas->wakeirq);
> > >
> > > Again, why nosync?
> > true - nosync is not necessary at here. disable_irq is however necessary
> > as we are not interested in wakeup events for level changes.
> >
> > We just use the enable/disable to control when we'd want to arm the pin
> > for waking up from suspend state.
>
> And what is issuing the call to enable/disable_irq_wake()?
>
> So if that interrupt is not marked proper then you can bring your
> device into a wont resume state easily
>
>start suspend
>enable wakeirq
>disable_device_irqs()
> if (!iswakeup_irq())
> disable_irq() // does not mask due to lazy masking
>
>
>wakeirq fires
> if (irq_is_disabled())
>mask_irq();
>
>transition into suspend
>
> Now your pinctrl irq is masked at the HW level and wont wake the
> machine up ever again.
True.
>
> So now looking at that pinctrl irq chip thing, which seems to be
> designed to handle these kind of wakeups. That thing looks massivly
> wrong as well, simply because it enforces to use
> enable_irq/disable_irq().
>
> So because the sole purpose of this chip is to handle the separate
> wakeup style interrupt, it should actually NOT enable the interrupt in
> the irq_unmask callback.
>
> Simply because during normal operation nothing is interested in the
> interrupt and any operation which might enable it (including request
> irq) is just making the system handle completely pointless interrupts
> and hoops and loops juggling with enable/disable irq.
>
> So the right thing here is to have an empty unmask function and do the
> actual unmask only in the irq_set_wake() callback. mask of course
> needs to do what it says. The point is, that the following sequence of
> code will just work w/o generating an interrupt on the wakeirq line
> outside of the wake enabled context.
>
> dev_init()
> request_wakeirq();
>
> suspend()
> if (may_wake())
> enable_irq_wake();
>
> resume()
> if (may_wake())
> disable_irq_wake();
>
> The other omap drivers using this have the same issue ... And of
> course they are subtly different.
>
> The uart one handles the actual device interrupt, which is violating
> the general rule of possible interrupt reentrancy in the pm-runtime
> case if the two interrupts are affine to two different cores. Yes,
> it's protected by a lock and works by chance
>
> The mmc one issues a disable_irq_nosync() in the wakeup irq handler
>
Re: [PATCH 00/26] ARM: OMAP2+: PRCM cleanups for 3.18 merge window
On Thu, 18 Sep 2014, Tony Lindgren wrote: > * Tero Kristo [140901 11:09]: > > Hi, > > > > This set contains PRCM related cleanups meant for 3.18 merge window. > > These are based on top of 3.17-rc1 + the PRM set from Nishanth Menon > > (http://article.gmane.org/gmane.linux.ports.arm.kernel/350305.) Nishanth's > > set is used as basis to avoid merge issues. > > > > Purpose of this work is to eventually convert the PRCM code into a > > separate driver, but this is done in incremental parts as the amount > > of changes is substantial. Expected conclusion of this work is 3.19 > > if everything goes fine. > > > > This part of the work mostly moves some of the SoC specific PRCM driver > > calls under generic version of the same, and adds SoC-ops to support > > these on the driver level. > > > > Working branch posted here: > > > > tree: https://github.com/t-kristo/linux-pm.git > > branch: for-v3.18/prcm-cleanup > > Paul, any comments on this series? Yeah, I'll send a few comments today. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 3/3] mfd: palmas: Add support for optional wakeup
On Thu, 18 Sep 2014, Nishanth Menon wrote:
> On 17:57-20140918, Thomas Gleixner wrote:
>
> I suppose I can improve the commit message to elaborate this better?
> Will that help?
You also want to improve the comment in the empty handler.
> >
> > > + */
> > > + return IRQ_NONE;
And it still does not explain WHY you think that returning IRQ_NONE is
the right thing to do here. You actually handle the interrupt, right?
Just because the handler is an NOP does not mean you did not handle
it.
> > > +static int palmas_i2c_suspend(struct i2c_client *i2c, pm_message_t mesg)
> > > +{
> > > + struct palmas *palmas = i2c_get_clientdata(i2c);
> > > + struct device *dev = &i2c->dev;
> > > +
> > > + if (!palmas->wakeirq)
> > > + return 0;
> > > +
> > > + if (device_may_wakeup(dev))
> > > + enable_irq(palmas->wakeirq);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int palmas_i2c_resume(struct i2c_client *i2c)
> > > +{
> > > + struct palmas *palmas = i2c_get_clientdata(i2c);
> > > + struct device *dev = &i2c->dev;
> > > +
> > > + if (!palmas->wakeirq)
> > > + return 0;
> > > +
> > > + if (device_may_wakeup(dev))
> > > + disable_irq_nosync(palmas->wakeirq);
> >
> > Again, why nosync?
> true - nosync is not necessary at here. disable_irq is however necessary
> as we are not interested in wakeup events for level changes.
>
> We just use the enable/disable to control when we'd want to arm the pin
> for waking up from suspend state.
And what is issuing the call to enable/disable_irq_wake()?
So if that interrupt is not marked proper then you can bring your
device into a wont resume state easily
start suspend
enable wakeirq
disable_device_irqs()
if (!iswakeup_irq())
disable_irq() // does not mask due to lazy masking
wakeirq fires
if (irq_is_disabled())
mask_irq();
transition into suspend
Now your pinctrl irq is masked at the HW level and wont wake the
machine up ever again.
So now looking at that pinctrl irq chip thing, which seems to be
designed to handle these kind of wakeups. That thing looks massivly
wrong as well, simply because it enforces to use
enable_irq/disable_irq().
So because the sole purpose of this chip is to handle the separate
wakeup style interrupt, it should actually NOT enable the interrupt in
the irq_unmask callback.
Simply because during normal operation nothing is interested in the
interrupt and any operation which might enable it (including request
irq) is just making the system handle completely pointless interrupts
and hoops and loops juggling with enable/disable irq.
So the right thing here is to have an empty unmask function and do the
actual unmask only in the irq_set_wake() callback. mask of course
needs to do what it says. The point is, that the following sequence of
code will just work w/o generating an interrupt on the wakeirq line
outside of the wake enabled context.
dev_init()
request_wakeirq();
suspend()
if (may_wake())
enable_irq_wake();
resume()
if (may_wake())
disable_irq_wake();
The other omap drivers using this have the same issue ... And of
course they are subtly different.
The uart one handles the actual device interrupt, which is violating
the general rule of possible interrupt reentrancy in the pm-runtime
case if the two interrupts are affine to two different cores. Yes,
it's protected by a lock and works by chance
The mmc one issues a disable_irq_nosync() in the wakeup irq handler
itself.
WHY does one driver need that and the other does not? You are not even
able to come up with a common scheme for OMAP. I don't want to see the
mess others are going to create when this stuff becomes more used.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH v3 0/5] Beaglebone-Black HDMI audio
On 09/19/2014 04:24 PM, Tomi Valkeinen wrote: On 17/09/14 10:51, Jyri Sarha wrote: On 09/17/2014 04:06 AM, Dave Airlie wrote: On 17 September 2014 06:40, Jyri Sarha wrote: Changes since v2: - Change compatible property from "ti,gpio-clock" to "ti,gpio-gate-clock" - Some minor cleanups The code has a functional dependency to: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg109264.html Without the above patch the audio card does not probe. The code has been rebased on top of Linux 3.17-rc5. The patches bellow, the above dependency, and couple of commits to add BBB HDMI audio support to omap2plus_defconfig can be pulled from: https://github.com/jsarha/linux.git linux-master-bbb-hdmi-audio How do you intend to get this merge, sending patchsets like this without indication to maintainers on a merge strategy is kinda messy. I'm not sure how maintained tilcdc is. Well, it is used but AFAIK the people who have been working with it the most have left TI. I think eventually someone at TI needs to take it over, but I do not know anything about that. I was hoping that because the change to tilcdc is quite minimal it could go in via you. I am sure I could get a reviewed-by and tested-by from from Darren how has bit more experience with tilcdc and maybe from Tomi too if that helps. (Adding Tomi to cc). The "drm/tilcdc: Add I2S HDMI audio config for tda998x"-patch itself just adds the audio configuration to pda998x pdata and fills the swap, and mirr parameters with default values (they are usually coming in hard coded at the beginning of tda998x_create()). I think Dave's point was that the series touches three different subsystems, and you didn't give any thoughts about how this could be merged. Must this be merged in one piece, because xxx depends on yyy etc? Can these all be merged separately, via respective trees? If in one piece, you could ask acks from Mr x and Mr y, for the parts they maintain. Etc. And of course, it'd be good to include all the maintainers (At least Mike was missing). I think the clock patch could be handled totally separate, as it's in no way related to HDMI. The video and audio part may be handled together, if they have dependencies. There should be no build time breakage no matter what is the merging order. The BBB HDMI audio functionality simply does not work before all the pieces are in. 1. The audio device does not probe if the ti,gpio-gate-clock is misssing. 2. The audio device probes, but there is no sound coming out if the tilcdc_slave change is missing. 3. Without ASoC or DTS changes there is no audio device. Best regards, Jyri -- 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 1/5] clk: ti: add "ti,gpio-gate-clock" controlled clock
On 19/09/14 16:12, Nishanth Menon wrote: > On 09/19/2014 08:07 AM, Tomi Valkeinen wrote: >> On 16/09/14 23:40, Jyri Sarha wrote: >>> The added ti,gpio-gate-clock is a basic clock that can be enabled and >>> disabled trough a gpio output. The DT binding document for the clock >>> is also added. For EPROBE_DEFER handling the registering of the clock >>> has to be delayed until of_clk_get() call time. >>> >>> Signed-off-by: Jyri Sarha >>> --- >>> .../bindings/clock/ti/gpio-gate-clock.txt | 21 ++ >>> drivers/clk/ti/Makefile|2 +- >>> drivers/clk/ti/gpio.c | 202 >>> >>> 3 files changed, 224 insertions(+), 1 deletion(-) >>> create mode 100644 >>> Documentation/devicetree/bindings/clock/ti/gpio-gate-clock.txt >>> create mode 100644 drivers/clk/ti/gpio.c >> >> Why is this a TI clock? Sounds like a generic one to me. > > Like thread: https://lkml.org/lkml/2014/9/5/284 ? Right, I should've read the earlier versions before making any smart comments =). Tomi signature.asc Description: OpenPGP digital signature
Re: [alsa-devel] [PATCH v3 0/5] Beaglebone-Black HDMI audio
On 17/09/14 10:51, Jyri Sarha wrote: > On 09/17/2014 04:06 AM, Dave Airlie wrote: >> On 17 September 2014 06:40, Jyri Sarha wrote: >>> Changes since v2: >>> - Change compatible property from "ti,gpio-clock" to >>> "ti,gpio-gate-clock" >>> - Some minor cleanups >>> >>> The code has a functional dependency to: >>> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg109264.html >>> >>> Without the above patch the audio card does not probe. >>> >>> The code has been rebased on top of Linux 3.17-rc5. The patches >>> bellow, the above dependency, and couple of commits to add BBB HDMI >>> audio >>> support to omap2plus_defconfig can be pulled from: >>> >>> https://github.com/jsarha/linux.git linux-master-bbb-hdmi-audio >> >> How do you intend to get this merge, sending patchsets like this without >> indication to maintainers on a merge strategy is kinda messy. >> >> I'm not sure how maintained tilcdc is. >> > > Well, it is used but AFAIK the people who have been working with it the > most have left TI. I think eventually someone at TI needs to take it > over, but I do not know anything about that. > > I was hoping that because the change to tilcdc is quite minimal it could > go in via you. I am sure I could get a reviewed-by and tested-by from > from Darren how has bit more experience with tilcdc and maybe from Tomi > too if that helps. (Adding Tomi to cc). > > The "drm/tilcdc: Add I2S HDMI audio config for tda998x"-patch itself > just adds the audio configuration to pda998x pdata and fills the swap, > and mirr parameters with default values (they are usually coming in hard > coded at the beginning of tda998x_create()). I think Dave's point was that the series touches three different subsystems, and you didn't give any thoughts about how this could be merged. Must this be merged in one piece, because xxx depends on yyy etc? Can these all be merged separately, via respective trees? If in one piece, you could ask acks from Mr x and Mr y, for the parts they maintain. Etc. And of course, it'd be good to include all the maintainers (At least Mike was missing). I think the clock patch could be handled totally separate, as it's in no way related to HDMI. The video and audio part may be handled together, if they have dependencies. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 1/5] clk: ti: add "ti,gpio-gate-clock" controlled clock
On 09/19/2014 08:07 AM, Tomi Valkeinen wrote: > On 16/09/14 23:40, Jyri Sarha wrote: >> The added ti,gpio-gate-clock is a basic clock that can be enabled and >> disabled trough a gpio output. The DT binding document for the clock >> is also added. For EPROBE_DEFER handling the registering of the clock >> has to be delayed until of_clk_get() call time. >> >> Signed-off-by: Jyri Sarha >> --- >> .../bindings/clock/ti/gpio-gate-clock.txt | 21 ++ >> drivers/clk/ti/Makefile|2 +- >> drivers/clk/ti/gpio.c | 202 >> >> 3 files changed, 224 insertions(+), 1 deletion(-) >> create mode 100644 >> Documentation/devicetree/bindings/clock/ti/gpio-gate-clock.txt >> create mode 100644 drivers/clk/ti/gpio.c > > Why is this a TI clock? Sounds like a generic one to me. Like thread: https://lkml.org/lkml/2014/9/5/284 ? > > In any case, this should go through Mike. > yep - should have been posted independent of this series :). -- Regards, Nishanth Menon -- 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 1/5] clk: ti: add "ti,gpio-gate-clock" controlled clock
On 16/09/14 23:40, Jyri Sarha wrote: > The added ti,gpio-gate-clock is a basic clock that can be enabled and > disabled trough a gpio output. The DT binding document for the clock > is also added. For EPROBE_DEFER handling the registering of the clock > has to be delayed until of_clk_get() call time. > > Signed-off-by: Jyri Sarha > --- > .../bindings/clock/ti/gpio-gate-clock.txt | 21 ++ > drivers/clk/ti/Makefile|2 +- > drivers/clk/ti/gpio.c | 202 > > 3 files changed, 224 insertions(+), 1 deletion(-) > create mode 100644 > Documentation/devicetree/bindings/clock/ti/gpio-gate-clock.txt > create mode 100644 drivers/clk/ti/gpio.c Why is this a TI clock? Sounds like a generic one to me. In any case, this should go through Mike. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH] rtc: omap: Support regulator supply for RTC
On 09/19/2014 04:48 AM, Lokesh Vutla wrote:
> +linux-omap, linux-arm-kernel, devicetree
> On Friday 19 September 2014 03:16 PM, Lokesh Vutla wrote:
>> On some Soc's RTC is powered by an external power regulator.
>> e.g. RTC on DRA7 SoC. Make the OMAP RTC driver support a
>> power regulator.
>> And also making the driver as module_platform_driver to
>> support probe deferal.
>>
>> Signed-off-by: Lokesh Vutla
>> ---
>> Tested on DRA7. Logs here: http://fpaste.org/134804/11200041/
Is that the only platform using rtc-omap.c?
>>
>> Documentation/devicetree/bindings/rtc/rtc-omap.txt | 3 +++
>> drivers/rtc/rtc-omap.c | 28
>> --
>> 2 files changed, 29 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
>> b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
>> index 5a0f02d..c9f963a 100644
>> --- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
>> +++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
>> @@ -10,6 +10,9 @@ Required properties:
>> - interrupts: rtc timer, alarm interrupts in order
>> - interrupt-parent: phandle for the interrupt controller
>>
>> +Optional Properties:
>> + - rtc-supply : phandle to the regulator device tree node if needed.
>> +
>> Example:
>>
>> rtc@1c23000 {
>> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
>> index 21142e6..4473d1d 100644
>> --- a/drivers/rtc/rtc-omap.c
>> +++ b/drivers/rtc/rtc-omap.c
>> @@ -24,6 +24,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> /* The OMAP1 RTC is a year/month/day/hours/minutes/seconds BCD clock
>> * with century-range alarm matching, driven by the 32kHz clock.
>> @@ -121,6 +122,7 @@
>> #define OMAP_RTC_HAS_32KCLK_EN BIT(2)
>>
>> static void __iomem *rtc_base;
^^ this can easily be removed by allocating data in probe.
>> +static struct regulator *rtc_reg;
So, two instances cannot have different RTC supplies? we dont need to
do this.
>>
>> #define rtc_read(addr) readb(rtc_base + (addr))
>> #define rtc_write(val, addr)writeb(val, rtc_base + (addr))
>> @@ -372,11 +374,12 @@ static const struct of_device_id omap_rtc_of_match[] =
>> {
>> };
>> MODULE_DEVICE_TABLE(of, omap_rtc_of_match);
>>
>> -static int __init omap_rtc_probe(struct platform_device *pdev)
>> +static int omap_rtc_probe(struct platform_device *pdev)
>> {
>> struct resource *res;
>> struct rtc_device *rtc;
>> u8 reg, new_ctrl;
>> +int ret;
>> const struct platform_device_id *id_entry;
>> const struct of_device_id *of_id;
>>
>> @@ -402,6 +405,23 @@ static int __init omap_rtc_probe(struct platform_device
>> *pdev)
>> return -ENOENT;
>> }
>>
>> +rtc_reg = devm_regulator_get_optional(&pdev->dev, "rtc");
>> +if (IS_ERR(rtc_reg)) {
>> +if (PTR_ERR(rtc_reg) == -EPROBE_DEFER) {
>> +dev_err(&pdev->dev, "regulator not ready, retry\n");
>> +return -EPROBE_DEFER;
>> +}
>> +rtc_reg = NULL;
>> +}
>> +
>> +if (rtc_reg) {
>> +ret = regulator_enable(rtc_reg);
>> +if (ret) {
>> +dev_dbg(&pdev->dev, "regulator enable failed\n");
>> +return ret;
>> +}
>> +}
>> +
Do you have a specific voltage you need for your rtc device?
>> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> rtc_base = devm_ioremap_resource(&pdev->dev, res);
>> if (IS_ERR(rtc_base))
>> @@ -517,6 +537,9 @@ static int __exit omap_rtc_remove(struct platform_device
>> *pdev)
>> pm_runtime_put_sync(&pdev->dev);
>> pm_runtime_disable(&pdev->dev);
>>
>> +if (rtc_reg)
>> +regulator_disable(rtc_reg);
>> +
>> return 0;
>> }
>>
>> @@ -565,6 +588,7 @@ static void omap_rtc_shutdown(struct platform_device
>> *pdev)
>>
>> MODULE_ALIAS("platform:omap_rtc");
>> static struct platform_driver omap_rtc_driver = {
>> +.probe = omap_rtc_probe,
>> .remove = __exit_p(omap_rtc_remove),
>> .shutdown = omap_rtc_shutdown,
>> .driver = {
>> @@ -576,7 +600,7 @@ static struct platform_driver omap_rtc_driver = {
>> .id_table = omap_rtc_devtype,
>> };
>>
>> -module_platform_driver_probe(omap_rtc_driver, omap_rtc_probe);
>> +module_platform_driver(omap_rtc_driver);
>>
>> MODULE_AUTHOR("George G. Davis (and others)");
>> MODULE_LICENSE("GPL");
>>
>
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/16] tty: serial: 8250_dma: Add a TX trigger workaround for AM33xx
On 09/19/2014 06:58 AM, Sebastian Andrzej Siewior wrote: > On 09/19/2014 12:22 PM, Heikki Krogerus wrote: >> Couldn't you just replace the handle_irq with a custom irq routine in >> the omap driver like you did with set_termios? Where you would do >> those tricks and/or call serial8250_handle_irq()? > > Tricks within serial8250_handle_irq(), see [0]. It is not a lot but > still. I could provide my own handle irq, just asking what you would > prefer. > > [0] > http://git.breakpoint.cc/cgit/bigeasy/linux.git/commit/?h=uart_v10_pre2&id=f26f161d998ee4a84a0aa6ddff69a435c25f204d > >> The 8250_core changes in that patch #10 only modify >> serial8250_handle_irg right? > > Correct. However there is another change due to the RX_DMA_BUG. A while > ago you said that this RX_DMA_BUG thing might be something that other > SoC could use, too. > If you ask me now for my own irq routine it would make sense to move RX > bug handling into omap specific code as well. I'm not excited at the prospect of an omap-specific irq handler, especially if this is just a silicon bug. I think it will create and encourage unnecessary code variation in the 8250 driver. The inertia of an omap-specific irq handler will mean it will probable stay forever. Suppose this tx dma bug is later discovered to be fixable inline (rather than by state), then we'll be stuck with an irq handler that no one will want to integrate. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/16] tty: serial: 8250_dma: Add a TX trigger workaround for AM33xx
On 09/19/2014 12:22 PM, Heikki Krogerus wrote: > Couldn't you just replace the handle_irq with a custom irq routine in > the omap driver like you did with set_termios? Where you would do > those tricks and/or call serial8250_handle_irq()? Tricks within serial8250_handle_irq(), see [0]. It is not a lot but still. I could provide my own handle irq, just asking what you would prefer. [0] http://git.breakpoint.cc/cgit/bigeasy/linux.git/commit/?h=uart_v10_pre2&id=f26f161d998ee4a84a0aa6ddff69a435c25f204d > The 8250_core changes in that patch #10 only modify > serial8250_handle_irg right? Correct. However there is another change due to the RX_DMA_BUG. A while ago you said that this RX_DMA_BUG thing might be something that other SoC could use, too. If you ask me now for my own irq routine it would make sense to move RX bug handling into omap specific code as well. > Cheers, Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/16] tty: serial: 8250_dma: Add a TX trigger workaround for AM33xx
On Wed, Sep 17, 2014 at 06:34:45PM +0200, Sebastian Andrzej Siewior wrote: > On 09/11/2014 01:42 PM, Sebastian Andrzej Siewior wrote: > >> We should add hooks like tx_dma and rx_dma to struct uart_8250_dma so > >> that the probe drivers can replace serial8250_tx_dma and > >> seria8250_rx_dma, like I think Alan already suggested. > > > > Okay. Wasn't aware that Alan already suggested that. > > I also need a watchdog timer for TX since it seems that on omap3 the > > DMA engine suddenly forgets to continue with DMA… > > > > If this is really what we want, I would need to refactor a few things… > > > >> Let's keep serial8250_tx_dma/rx_dma as the default, and not add any > >> quirks to them. Only if there is a very common case should it be > >> handled in those. The case of RX req needing to be sent before data in > >> FIFO maybe one of those, but I'm no sure. > > > > keep in mind that both (RX & TX bugs/hacks) need also a bit of handling > > in the 8250-core so it works together (like the tx_err member so we > > fall back to manual xmit) > > Done. I've kept the RX workarounds in the 8250_dma and moved the TX > part into the omap driver. > I needed to add the 8250_core pieces of patch #10 [0]. Now If you say, > couldn't this done in an other way then I could move the RX workarounds > pieces to the omap driver as well as the interrupt routine. Any > preferences? > > [0] [PATCH 10/16] tty: serial: 8250_dma: optimize the xmit path due to > UART_BUG_DMA_TX Couldn't you just replace the handle_irq with a custom irq routine in the omap driver like you did with set_termios? Where you would do those tricks and/or call serial8250_handle_irq()? The 8250_core changes in that patch #10 only modify serial8250_handle_irg right? Cheers, -- heikki -- 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] rtc: omap: Support regulator supply for RTC
+linux-omap, linux-arm-kernel, devicetree
On Friday 19 September 2014 03:16 PM, Lokesh Vutla wrote:
> On some Soc's RTC is powered by an external power regulator.
> e.g. RTC on DRA7 SoC. Make the OMAP RTC driver support a
> power regulator.
> And also making the driver as module_platform_driver to
> support probe deferal.
>
> Signed-off-by: Lokesh Vutla
> ---
> Tested on DRA7. Logs here: http://fpaste.org/134804/11200041/
>
> Documentation/devicetree/bindings/rtc/rtc-omap.txt | 3 +++
> drivers/rtc/rtc-omap.c | 28
> --
> 2 files changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> index 5a0f02d..c9f963a 100644
> --- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> +++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> @@ -10,6 +10,9 @@ Required properties:
> - interrupts: rtc timer, alarm interrupts in order
> - interrupt-parent: phandle for the interrupt controller
>
> +Optional Properties:
> + - rtc-supply : phandle to the regulator device tree node if needed.
> +
> Example:
>
> rtc@1c23000 {
> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> index 21142e6..4473d1d 100644
> --- a/drivers/rtc/rtc-omap.c
> +++ b/drivers/rtc/rtc-omap.c
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
>
> /* The OMAP1 RTC is a year/month/day/hours/minutes/seconds BCD clock
> * with century-range alarm matching, driven by the 32kHz clock.
> @@ -121,6 +122,7 @@
> #define OMAP_RTC_HAS_32KCLK_EN BIT(2)
>
> static void __iomem *rtc_base;
> +static struct regulator *rtc_reg;
>
> #define rtc_read(addr) readb(rtc_base + (addr))
> #define rtc_write(val, addr) writeb(val, rtc_base + (addr))
> @@ -372,11 +374,12 @@ static const struct of_device_id omap_rtc_of_match[] = {
> };
> MODULE_DEVICE_TABLE(of, omap_rtc_of_match);
>
> -static int __init omap_rtc_probe(struct platform_device *pdev)
> +static int omap_rtc_probe(struct platform_device *pdev)
> {
> struct resource *res;
> struct rtc_device *rtc;
> u8 reg, new_ctrl;
> + int ret;
> const struct platform_device_id *id_entry;
> const struct of_device_id *of_id;
>
> @@ -402,6 +405,23 @@ static int __init omap_rtc_probe(struct platform_device
> *pdev)
> return -ENOENT;
> }
>
> + rtc_reg = devm_regulator_get_optional(&pdev->dev, "rtc");
> + if (IS_ERR(rtc_reg)) {
> + if (PTR_ERR(rtc_reg) == -EPROBE_DEFER) {
> + dev_err(&pdev->dev, "regulator not ready, retry\n");
> + return -EPROBE_DEFER;
> + }
> + rtc_reg = NULL;
> + }
> +
> + if (rtc_reg) {
> + ret = regulator_enable(rtc_reg);
> + if (ret) {
> + dev_dbg(&pdev->dev, "regulator enable failed\n");
> + return ret;
> + }
> + }
> +
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> rtc_base = devm_ioremap_resource(&pdev->dev, res);
> if (IS_ERR(rtc_base))
> @@ -517,6 +537,9 @@ static int __exit omap_rtc_remove(struct platform_device
> *pdev)
> pm_runtime_put_sync(&pdev->dev);
> pm_runtime_disable(&pdev->dev);
>
> + if (rtc_reg)
> + regulator_disable(rtc_reg);
> +
> return 0;
> }
>
> @@ -565,6 +588,7 @@ static void omap_rtc_shutdown(struct platform_device
> *pdev)
>
> MODULE_ALIAS("platform:omap_rtc");
> static struct platform_driver omap_rtc_driver = {
> + .probe = omap_rtc_probe,
> .remove = __exit_p(omap_rtc_remove),
> .shutdown = omap_rtc_shutdown,
> .driver = {
> @@ -576,7 +600,7 @@ static struct platform_driver omap_rtc_driver = {
> .id_table = omap_rtc_devtype,
> };
>
> -module_platform_driver_probe(omap_rtc_driver, omap_rtc_probe);
> +module_platform_driver(omap_rtc_driver);
>
> MODULE_AUTHOR("George G. Davis (and others)");
> MODULE_LICENSE("GPL");
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/7] ARM: l2c: Add support for overriding prefetch settings
On 26/08/2014 at 16:17:57 +0200, Tomasz Figa wrote :
> Firmware on certain boards (e.g. ODROID-U3) can leave incorrect L2C prefetch
> settings configured in registers leading to crashes if L2C is enabled
> without overriding them. This patch introduces bindings to enable
> prefetch settings to be specified from DT and necessary support in the
> driver.
>
> Signed-off-by: Tomasz Figa
Tested-by: Alexandre Belloni
It is working and useful on Atmel's sama5d4 were the bootloader is not
configuring the L2C prefetch. However, I'm wondering whether we should
add support for setting L310_PREFETCH_CTRL_DATA_PREFETCH and
L310_PREFETCH_CTRL_INSTR_PREFETCH. I'm currently doing it by using
".l2c_aux_val= L310_AUX_CTRL_DATA_PREFETCH |
L310_AUX_CTRL_INSTR_PREFETCH" (those are the same bits) but this has the
disadvantage of displaying the "L2C: platform modifies aux control
register:" twice.
> + if (!of_property_read_u32(np, "arm,prefetch-offset", &val)) {
> + prefetch &= ~L310_PREFETCH_CTRL_OFFSET_MASK;
> + prefetch |= val & L310_PREFETCH_CTRL_OFFSET_MASK;
> + }
> +
While you use val directly here, later, while printing the offset, val +
1 is used. Maybe it would be better to have the same number in both
places, else you end up with having "arm,prefetch-offset = <1>" in your
DT and the kernel printing "L2C-310 ID prefetch enabled, offset 2
lines".
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
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: OMAP3/AM3517 EHCI USB Issue
On 09/19/2014 12:37 PM, Michael Trimarchi wrote: > Hi Roger > > On Fri, Sep 19, 2014 at 11:22 AM, Roger Quadros wrote: >> Hi Michael, >> > > It should be noted that the external HUB must be prevented from > autosuspend > otherwise the resume fails. OK. I was able to reproduce the issue on my beagleboard as well. The key to reproduce the issue is to use a device which has autosuspend working. Earlier I was using a mass storage device so couldn't reproduce the issue. On using a HUB I could see the issue. Debugging this issue is on my action list. >>> >>> I will keep an eye out for the fix if it is possible. The implementation of >>> the remote resume workaround as listed in the sprz306d.pdf seems to hack >>> into the core EHCI drivers and limits you to a single USB host. >>> >> >> Please see Advisory 1.1.33 HSUSB Interoperability Issue with SMSC USB3320 PHY >> (sprz306d errata doc). >> >> It seems ULPI suspend/resume is broken and there is no workaround. So you >> have to >> prevent the USB device connected at root port from suspending. >> > > It's very important to understand if this affect even OMAP4 and > tusb1210 that is suggested by TI. > This particular issue was fixed in omap3630 ES1.1 onwards. But that doesn't mean OMAP4 is free of issues around USB EHCI. 4430 brought it's own set of issues which were fixed in 4460. But there were still some issues requiring software workaround especially around USB suspend/resume. e.g. There is still an issue with both 4430 and 4460 called i701 (USB Host - Possible Interoperability With External PHY At Resume Time) which is observed on certain PHYs (at least not on usb3320). There is a software workaround for that. cheers, -roger -- 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: OMAP3/AM3517 EHCI USB Issue
Hi Roger On Fri, Sep 19, 2014 at 11:22 AM, Roger Quadros wrote: > Hi Michael, > > On 08/04/2014 06:27 PM, Michael Welling wrote: >> On Mon, Aug 04, 2014 at 12:34:16PM +0300, Roger Quadros wrote: >>> On 08/02/2014 02:51 AM, Michael Welling wrote: On Fri, Aug 1, 2014 at 6:04 PM, Michael Welling wrote: > On Wed, Jul 30, 2014 at 12:03:22PM +0300, Roger Quadros wrote: >> On 07/29/2014 06:20 PM, Michael Welling wrote: >>> On Tue, Jul 29, 2014 at 11:59:07AM +0300, Roger Quadros wrote: Hi Michael, On 07/28/2014 09:10 PM, Felipe Balbi wrote: > On Mon, Jul 28, 2014 at 12:57:39PM -0500, Michael Welling wrote: >> On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote: >>> Hi, >>> >>> On Mon, Jul 28, 2014 at 10:29:49AM -0500, Michael Welling wrote: On Mon, Jul 28, 2014 at 11:02:47AM -0400, Alan Stern wrote: > On Fri, 25 Jul 2014, Michael Welling wrote: > >> The plot thickens >> >> So if I run the above command before anything is plugged into >> the ports >> the HUB disconnects. >> >> root@som3517:~# echo on > /sys/bus/usb/devices/1-1/power/control >> [ 63.068839] usb 1-1: USB disconnect, device number 2 >> >> Here is the output of the usbmon output when running the above >> command: >> root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t >> de382e40 376573 S Ci:001:00 s a3 00 0001 0004 4 < >> de382e40 3788890604 C Ci:001:00 0 4 = 0705 >> de382e40 3788892965 S Ci:001:00 s a3 00 0002 0004 4 < >> de382e40 3788893093 C Ci:001:00 0 4 = 0001 >> de382e40 3788894834 S Ci:001:00 s a3 00 0003 0004 4 < >> de382e40 3788894958 C Ci:001:00 0 4 = 0001 >> de7d92c0 3788896519 S Ii:001:01 -115 4 < >> de382e40 3788898778 S Ci:001:00 s a3 00 0001 0004 4 < >> de382e40 3788900188 C Ci:001:00 0 4 = 0705 >> de382e40 3788902705 S Co:001:00 s 23 01 0002 0001 0 >> de382e40 3788905793 C Co:001:00 0 0 >> de382e40 3788940998 S Ci:001:00 s a3 00 0001 0004 4 < >> de7d92c0 3788942065 C Ii:001:01 0 1 = 02 >> de7d92c0 3788943013 S Ii:001:01 -115 4 < >> de382e40 3788943145 C Ci:001:00 0 4 = 03050400 >> de382e40 3788961031 S Co:001:00 s 23 01 0012 0001 0 >> de382e40 3788961175 C Co:001:00 0 0 >> de382e40 3788961304 S Ci:002:00 s 80 00 0002 2 < >> de382e40 3788965395 C Ci:002:00 -71 0 >> de249040 3788966954 S Co:001:00 s 23 03 0004 0001 0 >> de249040 3788968362 C Co:001:00 0 0 >> de249040 3789021103 S Ci:001:00 s a3 00 0001 0004 4 < >> de7d92c0 3789022194 C Ii:001:01 0 1 = 02 >> de7d92c0 378906 S Ii:001:01 -115 4 < >> de249040 3789023423 C Ci:001:00 0 4 = 01051200 >> de249040 3789025010 S Co:001:00 s 23 03 0004 0001 0 >> de249040 3789026815 C Co:001:00 0 0 >> de249040 3789230980 S Ci:001:00 s a3 00 0001 0004 4 < >> de249040 378923 C Ci:001:00 0 4 = 00010300 >> de249040 3789232280 S Co:001:00 s 23 01 0014 0001 0 >> de249040 3789232404 C Co:001:00 0 0 >> de249040 3789233056 S Co:001:00 s 23 01 0001 0001 0 >> de249040 3789235345 C Co:001:00 0 0 >> de249040 3789236820 S Co:001:00 s 23 01 0001 0001 0 >> de249040 3789237201 C Co:001:00 0 0 >> de249040 3789238180 S Co:001:00 s 23 01 0001 0001 0 >> de249040 3789238510 C Co:001:00 0 0 >> de249040 3789240602 S Ci:001:00 s a3 00 0001 0004 4 < >> de249040 3789241661 C Ci:001:00 0 4 = 00010300 >> de249040 3789242264 S Co:001:00 s 23 01 0010 0001 0 >> de249040 3789243921 C Co:001:00 0 0 >> de249040 3789246540 S Co:001:00 s 23 01 0011 0001 0 >> de249040 3789246930 C Co:001:00 0 0 >> de2490c0 3789283096 S Ci:001:00 s a3 00 0001 0004 4 < >> de2490c0 3789286255 C Ci:001:00 0 4 = 0001 >> de2490c0 3789330975 S Ci:001:00 s a3 00 0001 0004 4 < >> de2490c0 3789332606 C Ci:001:00 0 4 = 0001 >> de2490c0 3789371015 S Ci:001:00 s a3 00 0001 0004 4 < >> de2490c0 3789371146 C Ci:001:00 0 4 = 0001 >> de2490c0 3789410975 S Ci:001:00 s a3 00 0001 0004 4 < >> de2490c0 3789411097 C Ci:001:00 0 4 = 0001 >> de2490c0 3789450972 S Ci:001:00 s a3 00 0001 0004 4 < >> de2490c0 3789451081 C Ci:001:00 0 4 = 0001 >> de7d92c0 3789452462 C Ii:001:01 -2 0
Re: OMAP3/AM3517 EHCI USB Issue
Hi Michael, On 08/04/2014 06:27 PM, Michael Welling wrote: > On Mon, Aug 04, 2014 at 12:34:16PM +0300, Roger Quadros wrote: >> On 08/02/2014 02:51 AM, Michael Welling wrote: >>> On Fri, Aug 1, 2014 at 6:04 PM, Michael Welling >>> wrote: On Wed, Jul 30, 2014 at 12:03:22PM +0300, Roger Quadros wrote: > On 07/29/2014 06:20 PM, Michael Welling wrote: >> On Tue, Jul 29, 2014 at 11:59:07AM +0300, Roger Quadros wrote: >>> Hi Michael, >>> >>> On 07/28/2014 09:10 PM, Felipe Balbi wrote: On Mon, Jul 28, 2014 at 12:57:39PM -0500, Michael Welling wrote: > On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote: >> Hi, >> >> On Mon, Jul 28, 2014 at 10:29:49AM -0500, Michael Welling wrote: >>> On Mon, Jul 28, 2014 at 11:02:47AM -0400, Alan Stern wrote: On Fri, 25 Jul 2014, Michael Welling wrote: > The plot thickens > > So if I run the above command before anything is plugged into the > ports > the HUB disconnects. > > root@som3517:~# echo on > /sys/bus/usb/devices/1-1/power/control > [ 63.068839] usb 1-1: USB disconnect, device number 2 > > Here is the output of the usbmon output when running the above > command: > root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t > de382e40 376573 S Ci:001:00 s a3 00 0001 0004 4 < > de382e40 3788890604 C Ci:001:00 0 4 = 0705 > de382e40 3788892965 S Ci:001:00 s a3 00 0002 0004 4 < > de382e40 3788893093 C Ci:001:00 0 4 = 0001 > de382e40 3788894834 S Ci:001:00 s a3 00 0003 0004 4 < > de382e40 3788894958 C Ci:001:00 0 4 = 0001 > de7d92c0 3788896519 S Ii:001:01 -115 4 < > de382e40 3788898778 S Ci:001:00 s a3 00 0001 0004 4 < > de382e40 3788900188 C Ci:001:00 0 4 = 0705 > de382e40 3788902705 S Co:001:00 s 23 01 0002 0001 0 > de382e40 3788905793 C Co:001:00 0 0 > de382e40 3788940998 S Ci:001:00 s a3 00 0001 0004 4 < > de7d92c0 3788942065 C Ii:001:01 0 1 = 02 > de7d92c0 3788943013 S Ii:001:01 -115 4 < > de382e40 3788943145 C Ci:001:00 0 4 = 03050400 > de382e40 3788961031 S Co:001:00 s 23 01 0012 0001 0 > de382e40 3788961175 C Co:001:00 0 0 > de382e40 3788961304 S Ci:002:00 s 80 00 0002 2 < > de382e40 3788965395 C Ci:002:00 -71 0 > de249040 3788966954 S Co:001:00 s 23 03 0004 0001 0 > de249040 3788968362 C Co:001:00 0 0 > de249040 3789021103 S Ci:001:00 s a3 00 0001 0004 4 < > de7d92c0 3789022194 C Ii:001:01 0 1 = 02 > de7d92c0 378906 S Ii:001:01 -115 4 < > de249040 3789023423 C Ci:001:00 0 4 = 01051200 > de249040 3789025010 S Co:001:00 s 23 03 0004 0001 0 > de249040 3789026815 C Co:001:00 0 0 > de249040 3789230980 S Ci:001:00 s a3 00 0001 0004 4 < > de249040 378923 C Ci:001:00 0 4 = 00010300 > de249040 3789232280 S Co:001:00 s 23 01 0014 0001 0 > de249040 3789232404 C Co:001:00 0 0 > de249040 3789233056 S Co:001:00 s 23 01 0001 0001 0 > de249040 3789235345 C Co:001:00 0 0 > de249040 3789236820 S Co:001:00 s 23 01 0001 0001 0 > de249040 3789237201 C Co:001:00 0 0 > de249040 3789238180 S Co:001:00 s 23 01 0001 0001 0 > de249040 3789238510 C Co:001:00 0 0 > de249040 3789240602 S Ci:001:00 s a3 00 0001 0004 4 < > de249040 3789241661 C Ci:001:00 0 4 = 00010300 > de249040 3789242264 S Co:001:00 s 23 01 0010 0001 0 > de249040 3789243921 C Co:001:00 0 0 > de249040 3789246540 S Co:001:00 s 23 01 0011 0001 0 > de249040 3789246930 C Co:001:00 0 0 > de2490c0 3789283096 S Ci:001:00 s a3 00 0001 0004 4 < > de2490c0 3789286255 C Ci:001:00 0 4 = 0001 > de2490c0 3789330975 S Ci:001:00 s a3 00 0001 0004 4 < > de2490c0 3789332606 C Ci:001:00 0 4 = 0001 > de2490c0 3789371015 S Ci:001:00 s a3 00 0001 0004 4 < > de2490c0 3789371146 C Ci:001:00 0 4 = 0001 > de2490c0 3789410975 S Ci:001:00 s a3 00 0001 0004 4 < > de2490c0 3789411097 C Ci:001:00 0 4 = 0001 > de2490c0 3789450972 S Ci:001:00 s a3 00 0001 0004 4 < > de2490c0 3789451081 C Ci:001:00 0 4 = 0001 > de7d92c0 3789452462 C Ii:001:01 -2 0 > > Not sure what any of it means. Basically it means what you said above: the hub disconnected. I can
Department of Public Works
Business Proposal..doc Description: MS-Word document
Re: [RESEND PATCH] gpio: omap: Fix interrupt names
On Sat, Sep 6, 2014 at 4:52 AM, Nishanth Menon wrote: > When viewing the /proc/interrupts, there is no information about which > GPIO bank a specific gpio interrupt is hooked on to. This is more than a > bit irritating as such information can esily be provided back to the > user and at times, can be crucial for debug. > > So, instead of displaying something like: > 31: 0 0 GPIO 0 palmas > 32: 0 0 GPIO 27 mmc0 > > Display the following with appropriate device name: > 31: 0 0 4ae1.gpio 0 palmas > 32: 0 0 4805d000.gpio 27 mmc0 > > This requires that we create irq_chip instance specific for each GPIO > bank which is trivial to achieve. Acked-by: Alexandre Courbot -- 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
