Help me with Linux Toolchain. So that i can do some programming on Board. Linux fedora 12 has been installed on my laptop.!!
Confused a lot. As nothing is visually available. On Sat, Sep 11, 2010 at 6:44 PM, < [email protected]> wrote: > Send Davinci-linux-open-source mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Davinci-linux-open-source digest..." > > > Today's Topics: > > 1. Re: [PATCH v4 1/2] davinci: Add generic PWM support for PWM > control (Caglar Akyuz) > 2. Re: [PATCH v3 00/10] split out emac cpdma and mdio for reuse > (Cyril Chemparathy) > 3. Re: [PATCH v3 00/10] split out emac cpdma and mdio for reuse > (Caglar Akyuz) > 4. Re: Driver (Raffaele Recalcati) > 5. Re: [PATCH v3 00/10] split out emac cpdma and mdio for reuse > (Michael Williamson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 10 Sep 2010 20:42:36 +0300 > From: Caglar Akyuz <[email protected]> > To: Sugumar Natarajan <[email protected]> > Cc: [email protected] > Subject: Re: [PATCH v4 1/2] davinci: Add generic PWM support for PWM > control > Message-ID: <[email protected]> > Content-Type: Text/Plain; charset="iso-8859-1" > > On Thursday 09 September 2010 01:40:49 pm Sugumar Natarajan wrote: > > This patch adds generic PWM support where it maintains the > > list of PWM control devices that can be added or removed. > > > > The interface provides a list of functions that can be accessed > > by the PWM control driver module and the generic PWM driver. > > > > The PWM control driver module such as eCAP uses the interface to > > register and add itself to the list as a PWM control device. > > The generic PWM driver uses the interface to search for a PWM control > > device and if present, uses the device for PWM control. > > > > Signed-off-by: Sugumar Natarajan <[email protected]> > > --- > > Hi, > > [...] > > > + > > +int pwm_enable(struct pwm_device *pwm) > > +{ > > + if (WARN_ON(!pwm)) > > + return -EINVAL; > > + > > + return clk_enable(pwm->clk); > > +} > > +EXPORT_SYMBOL(pwm_enable); > > + > > I think 'clk_enable' should be controlled for un-matched pwm_enable/disable > operation. Otherwise, disabling PWM won't shut down peripheral clock. If I > understand inner workings of DaVinci clock implementation clock use_count > is > incremented with every clk_enable. > > Regards, > Caglar > > > ------------------------------ > > Message: 2 > Date: Fri, 10 Sep 2010 18:59:38 -0400 > From: Cyril Chemparathy <[email protected]> > To: Michael Williamson <[email protected]> > Cc: "[email protected]" > <[email protected]>, > "[email protected]" <[email protected]>, " > [email protected]" > <[email protected]>, "[email protected]" > <[email protected]>, "[email protected]" > <[email protected]> > Subject: Re: [PATCH v3 00/10] split out emac cpdma and mdio for reuse > Message-ID: <[email protected]> > Content-Type: text/plain; charset=UTF-8 > > Hi Mike, > > I have merged your latest two emails and responded to both here. > > [...] > > Your patch doesn't work with my board. It does attempt to reset the bus > on the read call, > > but following wait_for_user_access() calls are timing out and the _read() > and _write() calls punt. > > I bumped up the MDIO_TIMEOUT to 100 ms, and it works. I'm wondering if > the scanning logic > > has to complete an entire cycle (all 32 phys) before issuing a request, > and if it's a lot > > slower than expected. > > Based on the mdio module's state machine code, the scan does not need to > complete before a user-request is issued. However, when the module is > first enabled, it _must_ poll at least one phy (phy id 0) before it > handles the user-access request. Consequently, the first access after > coming out of reset may be slower than subsequent accesses. > > One of the patches posted on my repo [1] replaces the dumb mdelay() with > a bit more logic that calculates the worst-case access time. This > mechanism may work a lot better for you. Would you mind trying it out? > > Since the MDIO_TIMEOUT is simply a defensive measure, I have no > objections to raising this timeout (included in the updated stack). > > > I also found that the initial scanning logic would not reliably find the > PHY until I bumped > > up the delay time following the reset operation. Sometimes it would, > sometimes no. > > > > Also, your while(1) loops with the continue conditions on the second > wait_for_user_access() > > in the read and writes might need some consideration, i.e.: > > > > while (1) { > > ret = wait_for_user_access(data); > > if (ret == -EAGAIN) > > continue; > > if (ret < 0) > > break; > > > > __raw_writel(reg, &data->regs->user[0].access); > > > > ret = wait_for_user_access(data); > > if (ret == -EAGAIN) > > continue; > > ^^^^^^^^^ <--- this will re-issue the request.... > what you want? > > Yes, the wait_for_user_access() would have reset the controller, > throwing the current transaction out. The intent here is to restart the > current transaction with a newly initialized controller. > > > if (ret < 0) > > break; > > > > reg = __raw_readl(&data->regs->user[0].access); > > ret = (reg & USERACCESS_ACK) ? (reg & USERACCESS_DATA) : > -EIO; > > break; > > } > > > > Also, on the shutdown, I get a major kernel trace. Here is the dump, as > much > > as I could catch of it.... (I need a better terminal program) > > [...] > > WARNING: at drivers/net/davinci_emac.c:1025 __cpdma_chan_free+0xac/0xb0() > > The current code spits out a huge volume of stuff as a result of a > WARN_ON in the rx handler. The gitweb on [1] has a patch that fixes this. > > [...] > >> > The MDIO module upgrade (rev 1.4 -> 1.5) could have something to do > with > >> > this behavior. Even so, I can't explain why this issue wasn't seen on > >> > da8xx prior to this series. The original code should (at least in > >> > theory) have sporadically locked up on emac open. > >> > > > I think, if I understand it correctly, that in the previous version of > > this code, the emac was reset *prior* to enabling, scanning, and > assigning > > the associated phy on the MDIO bus. The new implementation sets up and > scans > > the MDIO bus first, then comes back around to the EMAC second... hits a > reset, > > and doesn't re-ENABLE the MDIO. > > AFAICS, that isn't entirely accurate. In the previous version, the mdio > bus was being brought up at probe time in davinci_emac_probe(). The > soft-reset was happening later on when the device is opened, in > emac_hw_enable(). > > The difference, however, is that the original code forced an > emac_mii_reset() immediately after the emac_hw_enable(). This is not > being done with the separated mdio, and that is the problem. In terms > of behavior, with the current work around, the new and old versions > should be close to identical. More below... > > > Also, maybe hitting the EMAC reset while the MDIO state machine is up is > *bad*, I > > seem to recall some text in the user's guide about waiting for the state > > machine to stop before disabling it. I wonder if that also applies to > reset? > > You are correct. EMAC soft-reset stops the MDIO mid-transaction, quite > unlike disabling the module via the control register. Therefore, there > is a risk that a badly designed phy could be left hanging in an > arbitrary state. However, all earlier versions of the emac code have > been exposed to this very same vulnerability (i.e. arbitrary emac > soft-reset regardless of mdio state) all along. > > Regards > Cyril. > > > [1] > > http://arago-project.org/git/people/?p=cyril/linux-tnetv107x.git;a=shortlog;h=refs/heads/emac-cpdma-mdio-fixes > > > ------------------------------ > > Message: 3 > Date: Sat, 11 Sep 2010 11:54:41 +0300 > From: Caglar Akyuz <[email protected]> > To: [email protected] > Cc: "[email protected]" <[email protected]>, > "[email protected]" > <[email protected]>, > "[email protected]" <[email protected]> > Subject: Re: [PATCH v3 00/10] split out emac cpdma and mdio for reuse > Message-ID: <[email protected]> > Content-Type: Text/Plain; charset="utf-8" > > On Friday 10 September 2010 06:23:52 pm Caglar Akyuz wrote: > > On Friday 10 September 2010 12:25:40 am Michael Williamson wrote: > > > Hi Cyril, > > > > > > On 09/09/2010 03:51 PM, Cyril Chemparathy wrote: > > > > Hi Mike, > > > > > > > > [...] > > > > > > > >> The hang is in wait_for_user_access() in the davinci_mdio_read() > call. > > > >> Looks like the state machine got put back into IDLE somewhere > between > > > >> the MDIO probe and the EMAC probe. Seems like there should be some > > > >> sort of time-out and error message in the wait_for_user_access() > > > >> method.... (maybe even a check for IDLE??) > > > >> > > > >> If I add a patch to check the state machine for IDLE and then > > > >> re-enable it in the davinci_mdio_read() call, it is able to press on > > > >> and come up. I don't see any calls to the davinci_mdio_suspend() > call, > > > >> so I am wondering if the EMAC probe routine, particularly the > > > >> application of the SOFTRESET, is causing the MDIO to drop back to > IDLE > > > >> / disabled. > > > >> > > > >> I can post the patch if you like, but it is a bit of a hack... > > > > > > > > An EMAC soft-reset clobbering the MDIO controller state is a > > > > possibility. I will poll TI designers to see if this could be the > > > > case. > > > > > > > > In any case, a couple of unanswered questions remain: > > > > > > > > 1. Why don't other davinci devices display similar behavior? > > > > > > > > 2. If the answer to #1 above is that the timing window is pretty > slim > > > > (i.e., only if an MDIO read/write is in progress during EMAC > > > > soft-reset), why do we hit this situation consistently on > > > > mityomap? > > > > > > Has it been confirmed that this only happens on mityomap? Has anyone > had > > > success using a da850 evm or other da850 platform? The configuration > > > for > > > > Same problem exists on another DA850 board, Hawkboard.(Sorry no support > in > > mainline yet) > > > > > the mityomap, wrt to the EMAC/MII/MDIO, is pretty much identical to > the > > > da850 evm using the MII interface. The only difference I am aware of > is > > > the assigned address to the PHY chip. The reference clocks and rates > > > are identical, AFAIK, to the evm. > > > > > > > I have put together a quick patch (tested dm365). See attached. > > > > > > Your patch doesn't work with my board. It does attempt to reset the > bus > > > on > > > > This patch fixes the problem here. I'm using kernel IP auto configuration > > and mounting fs over NFS. My system boots and I can login to my board. > > > > Regards, > > Caglar > > > > Unfortunately emac driver is not stable after this series. I face lock-ups > time to time, followed by attached kernel trace. > > Regards, > Caglar > _________________________________________________________________ > > [ 1651.440000] nfs: server 192.168.2.34 not responding, still trying > [ 1859.010000] ------------[ cut here ]------------ > [ 1859.010000] WARNING: at net/sched/sch_generic.c:258 > dev_watchdog+0x184/0x294() > [ 1859.020000] NETDEV WATCHDOG: eth0 (davinci_emac): transmit queue 0 timed > out > [ 1859.020000] Modules linked in: > [ 1859.030000] Backtrace: > [ 1859.030000] [<c0030444>] (dump_backtrace+0x0/0x10c) from [<c02d9820>] > (dump_stack+0x18/0x1c) > [ 1859.040000] r7:c03b5de8 r6:c025a13c r5:c039045c r4:00000102 > [ 1859.040000] [<c02d9808>] (dump_stack+0x0/0x1c) from [<c0042e44>] > (warn_slowpath_common+0x58/0x70) > [ 1859.050000] [<c0042dec>] (warn_slowpath_common+0x0/0x70) from > [<c0042f00>] > (warn_slowpath_fmt+0x38/0x40) > [ 1859.060000] r8:c03b4000 r7:00000030 r6:c0437564 r5:c7bbc000 r4:00000000 > [ 1859.070000] [<c0042ec8>] (warn_slowpath_fmt+0x0/0x40) from [<c025a13c>] > (dev_watchdog+0x184/0x294) > [ 1859.080000] r3:c7bbc000 r2:c0390474 > [ 1859.080000] [<c0259fb8>] (dev_watchdog+0x0/0x294) from [<c004e918>] > (run_timer_softirq+0x1c4/0x29c) > [ 1859.090000] [<c004e754>] (run_timer_softirq+0x0/0x29c) from [<c0048b94>] > (__do_softirq+0x98/0x12c) > [ 1859.100000] [<c0048afc>] (__do_softirq+0x0/0x12c) from [<c0048c70>] > (irq_exit+0x48/0x9c) > [ 1859.110000] [<c0048c28>] (irq_exit+0x0/0x9c) from [<c002c080>] > (asm_do_IRQ+0x80/0xa0) > [ 1859.120000] [<c002c000>] (asm_do_IRQ+0x0/0xa0) from [<c002cb2c>] > (__irq_svc+0x4c/0x9c) > [ 1859.120000] Exception stack(0xc03b5f38 to 0xc03b5f80) > [ 1859.130000] 5f20: > 00000000 0005317f > [ 1859.140000] 5f40: 0005217f 60000013 c03b4000 c03b8ba0 c03b89d4 c03dcc50 > c0023e04 41069265 > [ 1859.150000] 5f60: c0023d94 c03b5f8c 600000d3 c03b5f80 c002da6c c002da78 > 60000013 ffffffff > [ 1859.150000] r5:febfd000 r4:ffffffff > [ 1859.160000] [<c002da48>] (default_idle+0x0/0x34) from [<c002dff0>] > (cpu_idle+0x74/0xdc) > [ 1859.170000] [<c002df7c>] (cpu_idle+0x0/0xdc) from [<c02d59d4>] > (rest_init+0xa4/0xbc) > [ 1859.170000] r7:c03b89c8 r6:c0026018 r5:c03dcc1c r4:00000002 > [ 1859.180000] [<c02d5930>] (rest_init+0x0/0xbc) from [<c0008bc4>] > (start_kernel+0x270/0x2d0) > [ 1859.190000] r4:c042d70c > [ 1859.190000] [<c0008954>] (start_kernel+0x0/0x2d0) from [<c0008034>] > (__enable_mmu+0x0/0x2c) > [ 1859.200000] r6:c002641c r5:c03dcc78 r4:00053175 > [ 1859.200000] ---[ end trace d278f645c502dc20 ]--- > > > ------------------------------ > > Message: 4 > Date: Sat, 11 Sep 2010 13:29:57 +0200 > From: Raffaele Recalcati <[email protected]> > To: ?zg?r Ozan Yusufo?lu <[email protected]> > Cc: [email protected] > Subject: Re: Driver > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=UTF-8 > > > Hi, I'm a novice embedded engineer who works in a IPTV STB project. We > are > > using a DaVinci DM6446 based evaluation board for developing a firmware > for > > our STB.? Unfortunetaly I am the only engineer who work in the software > > development side, and? don't have enough backround to deal with problems > > which I encountered.? Could you please enlighten me about these issues > > I'm working on DM365 kernel support development for our boards. > I think, first of all, you need to become familiar with www.ti.com and > Ti E2E community. > Design Support -> Ti E2E community > then Support Forums > than Embedded software > and finally Linux .. > Here you can find some help about Ti releases. > But first read carefully the documentation. > > > 1. I will use the open source Linux DaVinci kernel for development, and I > > didn't understand the driver side, in documents of TI its been said that > LSP > > is integrated with Montavista kernel, is it still available to use LSP > with > > open community Linux kernel? If it is,how can I do this? > > In the case of DM365 (check for DM6446) the PSP kernel release is an > easier way than open source Linux DaVinci kernel. > Here you have the specifications of the latest PSP release > > http://processors.wiki.ti.com/index.php/DaVinci_PSP_03.01_GA_%28r37%29_Release_Notes > > > 2. Is there any pre-builded open source Linux kernel that all these > drivers > > work completely within ? > > PSP kernel release is opensource > > > > 3. It seems that the video-display? driver not functional? for Dm644x, in > > the http://processors.wiki.ti.com/index.php/DaVinci_GIT_Linux_Kernel > > If not you have to develop it or ask for a roadmap to Ti > > > 4. What is the difference between LSP and PSP.? I couldn't find any > document > > that gives detail about these issues . Could you give me any advice about > > where to start? ? > > LSP = montavista > PSP = free and Ti made > > Bye, > Raffaele > > > ------------------------------ > > Message: 5 > Date: Sat, 11 Sep 2010 09:14:14 -0400 > From: Michael Williamson <[email protected]> > To: [email protected] > Cc: "[email protected]" > <[email protected]>, > "[email protected]" <[email protected]>, " > [email protected]" > <[email protected]>, "[email protected]" > <[email protected]>, "[email protected]" > <[email protected]> > Subject: Re: [PATCH v3 00/10] split out emac cpdma and mdio for reuse > Message-ID: <[email protected]> > Content-Type: text/plain; charset=UTF-8 > > Hi Cyril, > > On 09/10/2010 06:59 PM, Cyril Chemparathy wrote: > > Hi Mike, > > > > I have merged your latest two emails and responded to both here. > > > [...] > > One of the patches posted on my repo [1] replaces the dumb mdelay() with > > a bit more logic that calculates the worst-case access time. This > > mechanism may work a lot better for you. Would you mind trying it out? > > > > You patch from [1] is working much more reliably now (well, 6 for 6 boot > cycles as well as > several ifup/ifdown cycles). I do get the "resetting idled controlled" > console message > every cycle, it seems that will be expected now. > > [...] > > >> > >> Also, your while(1) loops with the continue conditions on the second > wait_for_user_access() > >> in the read and writes might need some consideration, i.e.: > >> > >> while (1) { > >> ret = wait_for_user_access(data); > >> if (ret == -EAGAIN) > >> continue; > >> if (ret < 0) > >> break; > >> > >> __raw_writel(reg, &data->regs->user[0].access); > >> > >> ret = wait_for_user_access(data); > >> if (ret == -EAGAIN) > >> continue; > >> ^^^^^^^^^ <--- this will re-issue the > request.... what you want? > > > > Yes, the wait_for_user_access() would have reset the controller, > > throwing the current transaction out. The intent here is to restart the > > current transaction with a newly initialized controller. > > > > OK. Makes sense. Looking at it felt like there was a chance for end > endless spin, but that > seems unlikely given how that condition might fire. > > [...] > > >> Also, on the shutdown, I get a major kernel trace. Here is the dump, as > much > >> as I could catch of it.... (I need a better terminal program) > > > > [...] > >> WARNING: at drivers/net/davinci_emac.c:1025 > __cpdma_chan_free+0xac/0xb0() > > > > The current code spits out a huge volume of stuff as a result of a > > WARN_ON in the rx handler. The gitweb on [1] has a patch that fixes > this. > > > > Yes, these messages are no longer issued with the patches from [1]. > Thanks. > > > [...] > >>>> The MDIO module upgrade (rev 1.4 -> 1.5) could have something to do > with > >>>> this behavior. Even so, I can't explain why this issue wasn't seen on > >>>> da8xx prior to this series. The original code should (at least in > >>>> theory) have sporadically locked up on emac open. > >>>> > >> I think, if I understand it correctly, that in the previous version of > >> this code, the emac was reset *prior* to enabling, scanning, and > assigning > >> the associated phy on the MDIO bus. The new implementation sets up and > scans > >> the MDIO bus first, then comes back around to the EMAC second... hits a > reset, > >> and doesn't re-ENABLE the MDIO. > > > > AFAICS, that isn't entirely accurate. In the previous version, the mdio > > bus was being brought up at probe time in davinci_emac_probe(). The > > soft-reset was happening later on when the device is opened, in > > emac_hw_enable(). > > > > The difference, however, is that the original code forced an > > emac_mii_reset() immediately after the emac_hw_enable(). This is not > > being done with the separated mdio, and that is the problem. In terms > > of behavior, with the current work around, the new and old versions > > should be close to identical. More below... > > > >> Also, maybe hitting the EMAC reset while the MDIO state machine is up is > *bad*, I > >> seem to recall some text in the user's guide about waiting for the state > >> machine to stop before disabling it. I wonder if that also applies to > reset? > > > > You are correct. EMAC soft-reset stops the MDIO mid-transaction, quite > > unlike disabling the module via the control register. Therefore, there > > is a risk that a badly designed phy could be left hanging in an > > arbitrary state. However, all earlier versions of the emac code have > > been exposed to this very same vulnerability (i.e. arbitrary emac > > soft-reset regardless of mdio state) all along. > > > > Thanks for straightening me out on this, Cryil. Your patch series in [1] > seems to > have resolved the issues I've been able to see on the da850 based board I'm > using > here. I appreciate your patience and quick response. I may try to beat on > it a > bit more with some network performance tests (even though it's not at all > related > to the immediate problems you've fixed) -- we've had that on our list of > todos > anyway for this module. > > I think it would be good to float your patches over to davinci-next, if > possible, before the > 37 merge window opens... Speaking, of course, from a very partial > perspective. > > > [1] > > > http://arago-project.org/git/people/?p=cyril/linux-tnetv107x.git;a=shortlog;h=refs/heads/emac-cpdma-mdio-fixes > > -Mike > > > ------------------------------ > > _______________________________________________ > Davinci-linux-open-source mailing list > [email protected] > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > > > End of Davinci-linux-open-source Digest, Vol 57, Issue 43 > ********************************************************* > -- Regards, Chetan Arvind Patil, +919970018364 http://sites.google.com/site/chtpatil/
_______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
