DM365 intermittent boot-time hang when configuring AEMIF regs
Hello list, I have an intermittent hang during boot on DM365, traced to the first access of AEMIF registers in davinci_nand.c, which is a read of A1CR during probe. JTAG debug (OpenOCD) is unable to halt the CPU while in this state. This only seems to happen when powered on from cold, if the reset line is toggled when already powered up then it's OK. This is on our latest PCB revision, the previous one seemed OK. Bit of a long shot asking here but thought I would in case it rang a bell with anyone - maybe we just have some power supply sequencing or reflow problems or something to find. Any clues welcome. Thanks, -- Jon Povey Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Davinci (and other?) MUSB does not unload cleanly as module
I've been trying to get musb drivers for Davinci DM365 working as modules. I can get them loading and working (on 3.0-rc7) but they don't unload properly. It seems to be some problem with the way the platform resources are claimed and released, particularly the way the same resources are used for two platform devices; the iomem resource tree gets screwed up. The resource handling seems the same for the different musb glue layers, so I don't think this is a davinci-specific problem. I have tried to test on 3.4 but that dies a horrible OOPS death the moment the modules are loaded, which I haven't looked into further. Can provide details if interested, but patches are needed to get musb loading on DM365 at all. I cherry-picked e9e8c85 usb: musb: make modules behave better and as far as I can see the platform resource handling is the same as in 3.4. Here's information about what I see under 3.0-rc7. I'm hoping someone (Felipe?) can give me some clues about what's going on with the platform resource handling. Sorry this is not a report against 3.4 but I haven't got that working. :/ I configure and build musb_hdrc.ko and davinci.ko. musb-davinci device with resources is added by the board, using mach-davinci/usb.c. On first modprobe davinci, things load and work OK. Then I can rmmod davinci and it unloads. If I try to modprobe davinci again, I get root@H:/# modprobe davinci musb-hdrc: version 6.0, cppi-dma, otg (peripheral+host) musb-hdrc: failed to claim resource 0 musb-davinci musb-davinci: failed to register musb device musb-davinci: probe of musb-davinci failed with error -16 /proc/iomem is interesting: After boot, before loading any modules there is a musb region in the list: 01c64000-01c645ff : musb-davinci After loading the modules, an identical line appears (a child?), but on unloading the modules, BOTH musb-davinci lines disappear. I tweaked kernel/resource.c to also print the pointer to the resource in question: Clean boot: 01c64000-01c645ff : musb-davinci (c046c470) Module(s) loaded: 01c64000-01c645ff : musb-davinci (c23e9900) 01c64000-01c645ff : musb-davinci (c046c470) Module unloaded: (lines are gone). Note that the new copy of the resource created when adding the musb-hdrc device has ended up as the PARENT of the original allocation. That looks like a bug to me. At unload time the copy gets removed and the original allocation disappears (leaks memory?) I don't understand the platform resource code very well, but I don't see how it's supposed to make sense to assign the same resource structs to two devices; the musb-davinci glue device and the real musb-hdrc. I will continue to try some very ugly hacks to manipulate the iomem resource tree, but I am starting to go cross-eyed on this, hence this plea for help. Does musb as module work correctly with load/unload/reload for any of the supported glue layers, does anyone know? Happy to reciprocate with some testing/patches! Thanks, -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v2] usb: musb: davinci: Fix build breakage
This appears to have been broken by commit 5cfb19ac604a68c030b245561f575c2d1bac1d49 (ARM: davinci: streamline sysmod access) For now, fix by hardcoding USB_PHY_CTRL and DM355_DEEPSLEEP Tested on DM365 with defconfig changes. Signed-off-by: Jon Povey jon.po...@racelogic.co.uk Acked-by: Sekhar Nori nsek...@ti.com CC: Felipe Balbi ba...@ti.com Cc: sta...@vger.kernel.org # v3.4.x --- Commit message updated after comments. Patch unchanged. drivers/usb/musb/davinci.c |1 + drivers/usb/musb/davinci.h |4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c index 768b4b5..9d63ba4 100644 --- a/drivers/usb/musb/davinci.c +++ b/drivers/usb/musb/davinci.c @@ -34,6 +34,7 @@ #include linux/dma-mapping.h #include mach/cputype.h +#include mach/hardware.h #include asm/mach-types.h diff --git a/drivers/usb/musb/davinci.h b/drivers/usb/musb/davinci.h index 046c844..371baa0 100644 --- a/drivers/usb/musb/davinci.h +++ b/drivers/usb/musb/davinci.h @@ -15,7 +15,7 @@ */ /* Integrated highspeed/otg PHY */ -#define USBPHY_CTL_PADDR (DAVINCI_SYSTEM_MODULE_BASE + 0x34) +#define USBPHY_CTL_PADDR 0x01c40034 #define USBPHY_DATAPOL BIT(11) /* (dm355) switch D+/D- */ #define USBPHY_PHYCLKGDBIT(8) #define USBPHY_SESNDEN BIT(7) /* v(sess_end) comparator */ @@ -27,7 +27,7 @@ #define USBPHY_OTGPDWN BIT(1) #define USBPHY_PHYPDWN BIT(0) -#define DM355_DEEPSLEEP_PADDR (DAVINCI_SYSTEM_MODULE_BASE + 0x48) +#define DM355_DEEPSLEEP_PADDR 0x01c40048 #define DRVVBUS_FORCE BIT(2) #define DRVVBUS_OVERRIDE BIT(1) -- 1.6.3.3 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] usb: musb: davinci: Fix build breakage
Sekhar Nori wrote: On 5/24/2012 5:23 PM, Sergei Shtylyov wrote: On 24-05-2012 6:25, Jon Povey wrote: This follows from my email DaVinci MUSB driver compile errors on 3.4 I suppose this should go to stable too, but I can't see a nice way to add them as CC in the patch but NOT email them right now when using git send-email. You can do both at once AFAIK. I do this by including a --suppress-cc=cc and then Ccing the e-mail ids I actually need explicitly. May be there is a better way. This fix should only go into v3.4.x so please indicate that when copying stable. Cc: sta...@vger.kernel.org # v3.4.x Happily my git send-email (1.6.3.3) turns out to have a feature/bug where the trailing # stuff on that Cc makes it unable to extract that email address - exactly what I want! Maybe if stable guys don't want to be CC'd by email they should pick a different tag for the commit message.. To test on DM365 I had to apply a patch similar to this one: http://linux.omap.com/pipermail/davinci-linux-open-source/2011 -July/023212.html That patch wasn't split/recast as needed that's why it wasn't accepted. It would be nice if someone at TI were to pick this up, at the moment there is no mainline support for DM365 USB, and if it is supposed to work with some board support mods, it seems the musb driver side is now broken and getting no testing. As a separate issue, MUSB drivers seem quite broken on DM365 in 3.2 and 3.4, but at least with this patch they compile. One step at a time.. Maybe I'll try to test it on DM6446 EVM. Though it doesn'[t support OTG mode... I beat Sergei to it! I tested this on DM6446 EVM using a mass storage device in PIO mode. After fixing issues above that Sergei mentioned, please add my: Acked-by: Sekhar Nori nsek...@ti.com Added and resent, thanks. But maybe take a look on a DM365 EVM..? Pretty broken for me. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] usb: musb: davinci: Fix build breakage
This appears to have been broken by commit 5cfb19ac604a68c030b245561f575c2d1bac1d49 For now, fix by hardcoding USB_PHY_CTRL and DM355_DEEPSLEEP Tested on DM365 with defconfig changes. Signed-off-by: Jon Povey jon.po...@racelogic.co.uk Cc: Sekhar Nori nsek...@ti.com Cc: Felipe Balbi ba...@ti.com --- This follows from my email DaVinci MUSB driver compile errors on 3.4 I suppose this should go to stable too, but I can't see a nice way to add them as CC in the patch but NOT email them right now when using git send-email. To test on DM365 I had to apply a patch similar to this one: http://linux.omap.com/pipermail/davinci-linux-open-source/2011-July/023212.html As a separate issue, MUSB drivers seem quite broken on DM365 in 3.2 and 3.4, but at least with this patch they compile. One step at a time.. drivers/usb/musb/davinci.c |1 + drivers/usb/musb/davinci.h |4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c index 768b4b5..9d63ba4 100644 --- a/drivers/usb/musb/davinci.c +++ b/drivers/usb/musb/davinci.c @@ -34,6 +34,7 @@ #include linux/dma-mapping.h #include mach/cputype.h +#include mach/hardware.h #include asm/mach-types.h diff --git a/drivers/usb/musb/davinci.h b/drivers/usb/musb/davinci.h index 046c844..371baa0 100644 --- a/drivers/usb/musb/davinci.h +++ b/drivers/usb/musb/davinci.h @@ -15,7 +15,7 @@ */ /* Integrated highspeed/otg PHY */ -#define USBPHY_CTL_PADDR (DAVINCI_SYSTEM_MODULE_BASE + 0x34) +#define USBPHY_CTL_PADDR 0x01c40034 #define USBPHY_DATAPOL BIT(11) /* (dm355) switch D+/D- */ #define USBPHY_PHYCLKGDBIT(8) #define USBPHY_SESNDEN BIT(7) /* v(sess_end) comparator */ @@ -27,7 +27,7 @@ #define USBPHY_OTGPDWN BIT(1) #define USBPHY_PHYPDWN BIT(0) -#define DM355_DEEPSLEEP_PADDR (DAVINCI_SYSTEM_MODULE_BASE + 0x48) +#define DM355_DEEPSLEEP_PADDR 0x01c40048 #define DRVVBUS_FORCE BIT(2) #define DRVVBUS_OVERRIDE BIT(1) -- 1.6.3.3 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: DaVinci MUSB driver compile errors on 3.4
Sekhar Nori wrote: On 5/23/2012 8:24 AM, Jon Povey wrote: I've just been trying to build musb driver modules for DM365 on kernel 3.4. I am getting errors which I think are due to the rearrangement of the mach-davinci/davinci.h and associated headers: CC [M] drivers/usb/musb/davinci.o drivers/usb/musb/davinci.c: In function 'phy_on': drivers/usb/musb/davinci.c:67: error: implicit declaration of function 'IO_ADDRESS' drivers/usb/musb/davinci.c:67: error: 'DAVINCI_SYSTEM_MODULE_BASE' undeclared (first use in this function) Not sure the right way to fix, I am just bodging for now. I see this too. Looks like this was missed all along because the davinci_all_defconfig does not enable the MUSB davinci glue layer. This needs to be corrected too. There is a lot of machine specific code in the davinci glue layer which needs to be cleaned up for a correct solution to this issue. For now, to fix this regression, we can directly define USB_PHY_CTRL and DM355_DEEPSLEEP to the correct register addresses. Then include mach/hardware.h to get definition of IO_ADDRESS(). I guess this what you did too. Pretty much, I just copied the define of DAVINCI_SYSTEM_MODULE_BASE Do you mind sending this to Felipe and checking if he is OK with taking it? Sent. Note that USB doesn't work on DM365 at the moment, the phy_ctrl is not set up right and the evm board file doesn't call the arch USB init. I started with this patch: http://linux.omap.com/pipermail/davinci-linux-open-source/2011-July/023212.html Maybe there is some reason why DM365 USB support has not made it to mainline? By the way: I am trying to get this working at the moment for dual role USB mass storage as host, and CDC serial as gadget. Based on kernel 3.0-rc7 seems more or less OK, just that it doesn't switch back to peripheral mode once host mode has been used. But I tried rebasing my board to 3.2 and 3.4 and things seem a lot more broken, no reaction to USB sticks being plugged in, and plugging into a PC gives an immediate OOPS in gadget ep0 interrupt handler. I haven't bisected any further than that as it's quite time-consuming rebasing the board support each time. Let me know if you want any more info about the above. This is on our own board and cables which control the ID pin appropriately, I don't have access to a DM365 EVM again until July. But if someone wants me to test some DM365 USB patches, let me know. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
DaVinci MUSB driver compile errors on 3.4
I've just been trying to build musb driver modules for DM365 on kernel 3.4. I am getting errors which I think are due to the rearrangement of the mach-davinci/davinci.h and associated headers: CC [M] drivers/usb/musb/davinci.o drivers/usb/musb/davinci.c: In function 'phy_on': drivers/usb/musb/davinci.c:67: error: implicit declaration of function 'IO_ADDRESS' drivers/usb/musb/davinci.c:67: error: 'DAVINCI_SYSTEM_MODULE_BASE' undeclared (first use in this function) Not sure the right way to fix, I am just bodging for now. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: RT patch on Davinci PSP kernel
davinci-linux-open-source-boun...@linux.davincidsp.com wrote: I was wondering if anyone has been able to apply a RT patch to the kernel supplied by the DaVinci PSP. I'm working with an OMAP L137 EVM board, and I need to run an application on the ARM that handles some routines periodically. On the DSP I can make use of the timer to handle my RT needs, but from the Linux part I have no idea how to do this. I've tried applying the RT patch for the kernel version on which the DaVinci kernel is based on, but even though I managed to compile it, it crashes whenever I try to boot from it. Please let me know if anyone has managed to apply a RT correctly or give me some advice on what direction to look for to satisfy the needs of my application. What are the needs of your application? Do you really need the RT patches? Many features from RT are in the mainline now. You can of course do things preiodically under Linux without RT, it just depends on maximum acceptable latency... -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: RT patch on Davinci PSP kernel
davinci-linux-open-source-boun...@linux.davincidsp.com wrote: Thanks for the quick answer, my application needs to handle a periodic routine every 16ms, with a latency of no more than 200us I've tried with the Linux timers and it work great when I had only that process running but when I added other processes depending on the CPU load the latency could sometimes be higher than the one accepted. That does sound like quite tight timing. Have you looked at SCHED_FIFO and priority? Maybe you can get away without PREEMPT_RT.. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: DaVinci unbanked GPIO IRQs broken
On Fri, Jan 27, 2012 at 18:49:42, Nori, Sekhar wrote: Hi Jon, On Tue, Jan 17, 2012 at 15:32:23, Nori, Sekhar wrote: I was able to reproduce this on the EVM using v2.6.38 (works) and v3.2 + my patch (doesn't work). I just started poking some registers to see what is happening. Will keep you updated on any progress. Following patch fixes the issue of interrupt handler not getting called. I tested it using GPIO3 on DM365. On applying this, I see a constant rate of 4-5 interrupts per second on that line. Yet to figure out what is triggering those. Anyway I will wait for you to test this after you are back before sending this to Grant. Are you back? Did you get a chance to test this? Hi, sorry about that. I was away for a month, and forgot about this. Tested just now. It seems good, GPIO interrupts work under 3.2 with this patch same as they do if I revert the genirq change. I noticed that something else is broken for me under 3.2 (my FPGA driver fails to load bitstream) compared with 3.0, but that is also broken with genirq reverted so I think it's a separate issue and your patch is good. So, Tested-By: Jon Povey jon.po...@racelogic.co.uk -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: DaVinci unbanked GPIO IRQs broken
Nori, Sekhar wrote: On Wed, Jan 11, 2012 at 17:17:34, Jon Povey wrote: Unbanked GPIO IRQs (I am on DM365) seem to have been broken by commit aac4dd1dab8acfc244d697473d2a5f4424a5746c, conversion to generic irq chip, leading to an oops from request_irq(). The root cause indeed seems to be chip_data getting overwritten. I made a patch for it and was able to test that requesting IRQ number 44 doesn't oops. Yet to figure out if there is an easy way to trigger an unbanked GPIO IRQ on the EVM, so a large part of the patch is actually untested. Anyway, can you give this patch a shot (hopefully not mailer mangled)? I don't like the fact that it increases davinci_soc_info usage, but first lets see if it fixes the issue. gpio_export(n, 1) and using sysfs to set the gpio to output can be used to test. Tried quickly rebasing my stuff to 3.2, your patch fixes the oops, but the interrupt does not trigger. I don't have time to investigate why not right now, sorry. But I did try reverting the genirq change too, and the interrupt handler still wasn't called, so maybe something else broke somewhere, or it could be something needs updating in my board support. I tried applying this patch (modulo gpio path change) to my 3.0-rc7 base with the genirq stuff left in. I still get an oops and backtrace when requesting the irq! If this is clearer: 3.2 vanilla: oops requesting irq 3.2 + your patch: no oops, isr is not run 3.2 + reverted genirq: no oops, isr is not run 3.0-rc7: oops requesting irq 3.0-rc7 + your patch: oops requesting irq 3.0-rc7 + reverted genirq: no oops, isr works -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: DaVinci unbanked GPIO IRQs broken
Sorry, last email had some lies, I had testing errors: Jon Povey wrote: But I did try reverting the genirq change too, and the interrupt handler still wasn't called This was incorrect, interrupt DOES work with genirq reverted on 3.2. 3.2 vanilla: oops requesting irq 3.2 + your patch: no oops, isr is not run These are still the case 3.2 + reverted genirq: no oops, isr is not run This was incorrect, real result is: no oops, isr WORKS. (with or without your patch). -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
DaVinci unbanked GPIO IRQs broken
+0x0/0x4c) from [c01f3d10] (device_add+0x4d4/0x648) [c01f383c] (device_add+0x0/0x648) from [c022b1a0] (spi_add_device+0xc8/0x128) [c022b0d8] (spi_add_device+0x0/0x128) from [c022b27c] (spi_new_device+0x7c/0xb4) r7:c33e3dd8 r6: r5:c33e3dd8 r4:c25caa00 [c022b200] (spi_new_device+0x0/0xb4) from [bf016f60] (mcu_probe+0x144/0x224 [mcu]) r7:c33e3dd8 r6:c0451c80 r5:bf01763c r4: [bf016e1c] (mcu_probe+0x0/0x224 [mcu]) from [c01f72f4] (platform_drv_probe+0x20/0x24) [c01f72d4] (platform_drv_probe+0x0/0x24) from [c01f5d88] (driver_probe_device+0x88/0x1b0) [c01f5d00] (driver_probe_device+0x0/0x1b0) from [c01f5f44] (__driver_attach+0x94/0x98) [c01f5eb0] (__driver_attach+0x0/0x98) from [c01f5534] (bus_for_each_dev+0x68/0x94) r7:c01f5eb0 r6:bf0174dc r5:c33e3e98 r4: [c01f54cc] (bus_for_each_dev+0x0/0x94) from [c01f5bec] (driver_attach+0x20/0x28) r7:c0462ac8 r6:bf0174dc r5:00098258 r4:3cd8 [c01f5bcc] (driver_attach+0x0/0x28) from [c01f4d30] (bus_add_driver+0xb4/0x258) [c01f4c7c] (bus_add_driver+0x0/0x258) from [c01f6588] (driver_register+0x74/0x158) [c01f6514] (driver_register+0x0/0x158) from [c01f777c] (platform_driver_register+0x4c/0x60) r7:c33e2000 r6: r5:00098258 r4:3cd8 [c01f7730] (platform_driver_register+0x0/0x60) from [bf019014] (mcu_init+0x14/0x20 [mcu]) [bf019000] (mcu_init+0x0/0x20 [mcu]) from [c002f3ec] (do_one_initcall+0x38/0x170) [c002f3b4] (do_one_initcall+0x0/0x170) from [c007b934] (sys_init_module+0x8c/0x1a4) [c007b8a8] (sys_init_module+0x0/0x1a4) from [c0030020] (ret_fast_syscall+0x0/0x2c) r7:0080 r6:0003 r5: r4:3cd8 -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
OT: ARM Linux job in Buckingham, UK
Hello folks, My company Racelogic is looking for another ARM Linux dev to work in Buckingham, UK with me and the rest of our dev team, job ad here: http://www.racelogic.co.uk/index.php/en/careersjobs Sorry if this is considered off-topic, I don't mean to be spammy. Suggestions for more appropriate ways to find people like this are welcome and appreciated. Thanks, -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
DaVinci NAND writing utility release, was: RE: [RFC] Change ECC algorithm from userspace
Adding davinci linux open source ML to CC as folk there might find this utility useful. Javier Martinez Canillas wrote: On Fri, Oct 28, 2011 at 12:33 PM, Jon Povey jon.po...@racelogic.co.uk wrote: linux-mtd-boun...@lists.infradead.org wrote: DM355 and DM365 has similar issues as the RBL expects a different OOB/ECC layout to Linux. What I have done is write a utility that calculates ECC and writes to the mtd device in RAW mode. So to rewrite the bootloader I take care of the ECC and layout at application level without changing the kernel. Is your utility publicly available? It would be great if I can use it as an starting point. Management have given the thumbs-up, this is now released under GPL v2 at https://github.com/jonpovey/flashtool Supports DM355 and DM365 RBL layouts, ECC generation, UBI image writing, and various bad block / range handling. Enjoy! -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH RESEND 2/4] davinci vpbe: add dm365 VPBE display driver changes
davinci-linux-open-source-boun...@linux.davincidsp.com wrote: This patch implements the core additions to the display driver, mainly controlling the VENC and other encoders for dm365. This patch also includes addition of amplifier subdevice to the vpbe driver and interfacing with venc subdevice. One small nit. Sorry about the probably broken quoting to follow. @@ -704,6 +717,39 @@ static int vpbe_initialize(struct device *dev, struct vpbe_device *vpbe_dev) + v4l2_warn(vpbe_dev-v4l2_dev, non-i2c amplifiers + currently not supported); + } + } else + vpbe_dev-amp = NULL; iirc this is not kernel style, if the then side of an if needs braces then the else side must have them too. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v2 0/8] RFC for Media Controller capture driver for DM365
davinci-linux-open-source-boun...@linux.davincidsp.com wrote: Hello Sakari, I have attached two .ps files with the entity graph details in them, one with RAW input and the other with YCbCr. Hope this is what you were looking for? Just wanted to say thanks for these and the new input drivers you have been working on. I am trying to puzzle out drivers for a new design based on dm365 so this is all interesting stuff. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] davinci: fix DM365 EVM video input mux bits
Hadli, Manjunath wrote: Jon, The fix looks correct. As a part of a different implementation which will go soon upstream, this has been taken care of, where we have used macros CPLD_VIDEO_INPUT_MUX_TVP70020x1 CPLD_VIDEO_INPUT_MUX_IMAGER 0x2 So, if you can do the same, it will look better. If you have a patch you can split out that has your defines where and how you want them then great. Otherwise I'd suggest just getting this or something equivalent in to fix the bug first, and reimplement it later. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] davinci: fix DM365 EVM video input mux bits
Video input mux settings for tvp7002 and imager inputs were swapped.
Comment was correct.
Tested on EVM with tvp7002 input.
Signed-off-by: Jon Povey jon.po...@racelogic.co.uk
---
As a bugfix maybe this should try to get into 3.0?
arch/arm/mach-davinci/board-dm365-evm.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-davinci/board-dm365-evm.c
index c67f684..09a87e6 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -520,7 +520,7 @@ fail:
*/
if (have_imager()) {
label = HD imager;
- mux |= 1;
+ mux |= 2;
/* externally mux MMC1/ENET/AIC33 to imager */
mux |= BIT(6) | BIT(5) | BIT(3);
@@ -540,7 +540,7 @@ fail:
resets = ~BIT(1);
if (have_tvp7002()) {
- mux |= 2;
+ mux |= 1;
resets = ~BIT(2);
label = tvp7002 HD;
} else {
--
1.6.3.3
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Attention TI people: Problems with TI E2E
This is a little OT for the list, but I am having problems using the TI E2E website and there is no obvious support contact for it. There is forum-based support, but it's the forums that are broken. When I try to post or reply it tries to contact sam01-prod.itg.ti.com, there is no itg.ti.com according to TI's DNS servers. This is since the 29th of June or so. Hoping someone from TI will see this and pass it along to the appropriate people. Thanks, -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
How to investigate latency causes
Hi folks, I am working on a video recording app on DM365, using DVSDK 4.02 which means kernel 2.6.32. Anyone got any advice on how to trace latency issues on this kernel? I was hoping to use tools/perf, but it's not supported for ARM on this old kernel it seems. I want to see what is going on when my process stalls so I can look at things like user+kernel thread priorities, threaded ISRs etc. to meet realtime deadlines. Kprobes maybe? There are various historical performance analysis tools that seem to have come and gone for Linux, any tips that can save me wasting time looking into less useful ones would be welcome. Related, I'd be interested to know how possible it is to use DMAI etc. on top of the current mainline kernel, or what's missing. For now I'm sticking with the TI DVSDK+PSP bundle but might want to change kernels before too long. Maybe I should ask that separately, later. Thanks, -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Davinci DM365 NAND Flash SYNDROME Support
Andrea Gasparini wrote: Hi Michael, hi jon! I'm resurrecting this thread just to know if anyone landed on a practical solution. Sorry, without dates or more reference I can't remember what the problem is that you're looking for a solution for. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 0/6] i2c-davinci gpio pulsed SCL recovery with ICPFUNC
Ben Gardiner wrote: In i2c-davinci: Fix race when setting up for TX and i2c-davinci: Fix TX setup for more SoCs you mention testing on DM355 -- is there any you have hardware on which the recovery procedure is executed on occasion and that you would be available to test modifications to the current implementation? Nope, sorry. I've never seen the bus lock up. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Intermittent SD write corruption on DM355, kernel 2.6.36
Jon Povey wrote: I am seeing rare SD card write corruption on DM355 I think I have a fix for this now - just CC'd you on the patch RFC [RFC] mmc: davinci: fix corruption after surprise card eject (Which fixes it, but may not be the best way of going about it). -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Intermittent SD write corruption on DM355, kernel 2.6.36
Gilles Chanteperdrix wrote: Jon Povey wrote: I think I have a fix for this now - just CC'd you on the patch RFC [RFC] mmc: davinci: fix corruption after surprise card eject (Which fixes it, but may not be the best way of going about it). If I read you correctly, it seems that the fix does things which are already done, right? So, how come it fixes ? :-) Not sure I understand. The existing code resets the controller core when handling certain errors, but more MMC commands are run after those error handlers. Presumably one of those puts the core into a bad state, a later reset (my patch) fixes it. Feel free to try it out! Although, maybe it may makes sense to post the patch on the linux-arm-kernel mailing list too. Hmm, should maybe have CC'd them. And David Brownell. Ho well. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Intermittent SD write corruption on DM355, kernel 2.6.36
Gilles Chanteperdrix wrote: Jon Povey wrote: I am seeing rare SD card write corruption on DM355 We did not investigate this issue any further (and notably, we did not hexdump the SD card contents when corrupted), but it certainly looks like something like this. The issue is kind of deterministic with regard to the timing when we remove the SD card. When we do so, we observe the SD card controller, or its driver has one of three reactions: - it continues to work normally - it fails to detect later re-insertion of an SD card - next dosfsck reports error in available clusters count and repairing the filesystem actually corrupts the FAT32 FS information sector, making it unmountable, and fails to detect the superblock on any later SD card. Thanks again for the info. I have been doing hexdumps of cards, using HxD on Windows (http://mh-nexus.de/en/) I have now been able to reproduce the state where the system corrupts all writes, shifting the data by 2 bytes. Pulling the card during write seems to be the trigger as you found. Assuming you are seeing the same thing, the system will corrupt the file contents, directories, FAT and FSINFO sectors the same way, whenever it writes them. The last two bytes from a sector write show up as the first two bytes of the next sector written, for example the last two bytes of a test file appear as the first two bytes of a (corrupted) directory sector. I have seen similar complaints about FSINFO from Linux and corruption / lost clusters from Windows. In our case, removing the SD card after recording 45s triggers the third case almost certainly. I assumed 45s is the time when the FS information sector is first modified in our case, but this timing is probably specific to our application. That sounds about right. Under Linux the OS will cache those writes for some (tuneable) amount of time before flushing them to disk. Some other information: we have this issue on DM368 using the 2.6.32 kernel from the Arago tree. And our SD card are correctly formatted, i.e. the same way as how the SD association SD card formatter does. That is interesting. It suggests that at least it's not a silicon errata in the MMC/SD block that was found and fixed between DM355 and DM368. I am busy getting familiar with the sources and working out how best to approach debugging this. Will send info when/if I learn something.. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Intermittent SD write corruption on DM355, kernel 2.6.36
Gilles Chanteperdrix wrote: Jon Povey wrote: I am seeing rare SD card write corruption on DM355 running 2.6.36. The system will get itself into a state where it appears all SD writes are offset by two bytes. This is using a vfat filesystem on the SD, and affects the FAT and directories at least. we observe something similar with the 2.6.32 kernel. In our case, it happens almost systematically if we remove the SD card while a transfer is occuring. Thanks for the report. That sounds like what we are seeing. I suspect some kind of incomplete DMA or controller state clearing on surprise removal. Will see if I can debug it and post a patch if I work it out. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Intermittent SD write corruption on DM355, kernel 2.6.36
I am seeing rare SD card write corruption on DM355 running 2.6.36. The system will get itself into a state where it appears all SD writes are offset by two bytes. This is using a vfat filesystem on the SD, and affects the FAT and directories at least. When I look at the contents of the SD card, corrupt sectors start with two bytes of junk which looks like the end of the previous sector write, then valid data (but shifted up two byte places), with the last two bytes missing - they seem to get written at the start of whatever sector gets written next. When the system is in this state I can umount and change cards, mount, touch a file and unmount and it repeatably corrupts the sector containing the directory entry. Unfortunately after a reboot everything works fine again, I haven't found a repeatable way to get the system back into the corrupting state. I have seen this happen on at least two separate occasions now and was not doing anything particularly abusive or unusual this time, so I know now this is real and needs to be fixed. I am going to look at git history since 2.6.36 to see if anything looking like a fix has been committed, will also try banging on things to reproduce the problem. But if anyone has any similar experiences, comments, suggestions they would be most welcome. Thanks. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] davinci: tnetv107x: fix register indexing for GPIOs numbers 31
davinci-linux-open-source-boun...@linux.davincidsp.com wrote: The bug implied the use of macros to access the relevant hardware register e.g. the driver code used the macro like this: 'gpio_reg_clear_bit(reg-data_out, gpio)' But it has to be used like this: 'gpio_reg_clear_bit(reg-data_out, gpio)'. Could the macro be made into an inline function so it can do type-checking to avoid/catch this in future? -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] davinci: tnetv107x: fix register indexing for GPIOs numbers 31
Hirosh Dabui wrote: On 01/26/2011 07:14 AM, Jon Povey wrote: davinci-linux-open-source-boun...@linux.davincidsp.com wrote: The bug implied the use of macros to access the relevant hardware register e.g. the driver code used the macro like this: 'gpio_reg_clear_bit(reg-data_out, gpio)' But it has to be used like this: 'gpio_reg_clear_bit(reg-data_out, gpio)'. Could the macro be made into an inline function so it can do type-checking to avoid/catch this in future? Hello Jon, if you do inline from it, it will not crash, the behaviour is the same. Also i have not seen a compiler warning.. The point is, if you make it an inline function instead of a macro, the compiler can check that you pass the appropriate type instead of a pointer to it. So it would give compiler warnings if you pass the wrong thing, where at the moment it silently allows a bug. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Davinci DM365 NAND Flash SYNDROME Support
davinci-linux-open-source-boun...@linux.davincidsp.com wrote: I have upgraded our DM365 platform to run with Linux kernel 2.6.32-rc2, which I got from the official TI release. Our platform uses the NAND flash with SYNDROME calculation and I am unable to get the kernel to recognize these devices. In particular, I get bad-block errors. What kernel were you running before? The old MontaVista based 2.6.10 kernel at least used a different OOB layout on 512 byte page size devices and the new kernel will not read/write those correctly. If you want to upgrade an existing system with data on the flash, to a new OOB layout, it involves considerable low level hackery. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Davinci DM365 NAND Flash SYNDROME Support
Hi. Let's keep the list CC'd in, might be useful for someone else reading archives later. Also, inline quoting is prefered.. Michael Hallak-Stamler wrote: We are using the original 2.6.18 Montavista kernel with the SYNDROME calculation. Since we have many existing devices in the field and we want to perform a remote upgrade, we need to maintain the same format on the NAND devices in order preserve other important data on them, such as the UBOOT and UBL and other data. Our system uses a technique whereby one of two NAND devices are read locked. Hence, there is not way to reformat the device for a new technique. We are stuck with having to maintain the original SYNDROME calculation. Are you physically (electrically) unable to erase/write one of your NAND devices? You do know about read disturb, right?... In short it means that to correctly manage a NAND device you have to rewrite blocks from time to time as bit errors appear randomly after reads from time to time. I have seen this brick devices in the field with naieve NAND handling firmware. I hope you can unlock your locked device.. I don't understand why this was not maintained so that we have backward compatibility. Is there no solution or patch that you are aware of? I do see partial support for the SYNDROME calculation in the kernel but nothing that gives a complete solution. I don't know, sorry. The original layout was simplistic and just plain wrong, didn't agree with manufacturer's idea of OOB layout and factory marked bad blocks, so it was fixed. This caused headaches for people trying to upgrade, yes.. Although I don't know if the old layout ever was in the mainline kernel, if not then who can really be blamed if MV/TI did it one way once and the mainline does it the right way, you are comparing apples and oranges to some extent. Anyway, you have the source and can beat it into submission :) This is assuming of course that you are running into the problems I did and not something completely different.. FYI I ended up rewriting chunks of flash in MTD RAW mode using software to change OOB layout and calculate ECC so that when rebooted it would be correct. Had to write various utilities to do that - and don't have the rights to the sources, sorry. Related point, eMMC looks nice for the future, takes away all the ECC and wear levelling hassle it seems.. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Davinci DM365 NAND Flash SYNDROME Support
Michael Hallak-Stamler wrote: Hi Jon, I won't mention this every time, but; like I said before, inline quoting is strongly prefered on this list (and most Linux/OSS lists). Look it up if you don't know what it is. I came on board well after the hardware was closed and employed in the field. Unfortunately, the base NAND device is hardware locked and can not be written to in the field, period. On the other hand reads are relatively rare, for booting and UBOOT usage mainly. But you are right about the the read problem. We are simply not able to write to it. Unlucky :( Bear in mind the read disturb issue if/when you start getting weird failures in the field. They will be fixable by rewrite of the NANDs. So as I understand I am on my own regarding this issue. I'm just in absolute wonder how it is that I am the only one in this very large world who has this issue? Am I the first?? Hard to believe. Quite possibly. Not all that many people want to do such a big update to firmware already in the field - they either do incremental bugfixes or there is such high churn that they're already end-of-lifing it and selling the next thing. That's my impression, anyway. Anyway, I will continue to work on it and hope to provide a patch to others who may want it. It may be as simple as copying (and refactoring) the OOB layout structs, and associated tweaks; platform data and such. Figuring out how that stuff fits together is the time-consuming bit though if it's your first time grubbing around in the guts of MTD. Have fun! -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: NFS
davinci-linux-open-source-boun...@linux.davincidsp.com wrote: On Wed, Oct 27, 2010 at 1:28 PM, chetan patil chtpa...@gmail.com wrote: we even tried USB on dm6446 and some how managed to mount but the one file in pendrive which is hello world is not working after using ./hello command. This implies that you can boot the target complete using non-NFS method. Consider doing a NFS mount directory for shared application programs. Also, for DM355 at least, the ARM ABI changed between the MV toolchain and the current recommended CodeSourcery one. So the binaries are incompatible - don't run on the other system. I.e. you need a cross-toolchain that matches your kernel. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: I want to get the address to download the package ofDavinci-linux-open-source
davinci-linux-open-source-boun...@linux.davincidsp.com wrote: I interested in davinci,wo I want to get the address of the package of Davinci-linux-open-source to download for study.thank you Lots of good info on the wiki: http://processors.wiki.ti.com/index.php/DaVinci_GIT_Linux_Kernel#Overview -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v4 7/9] davinci: MMC/SD support for Omapl138-Hawkboar
davinci-linux-open-source-boun...@linux.davincidsp.com wrote: I think that you mean that I should not call gpio_direction_input if gpio_request failed am I right ? Yes, if gpio_request() fails that means you have not claimed that gpio, something else is using it already or it's not available due to other misconfiguration. So you shouldn't be trying to set its direction or anything like that. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] i2c: davinci: Fix TX setup for more SoCs
This patch is an improvement to 4bba0fd8d1c6d405df666e2573e1a1f917098be0
which got to mainline a little early.
Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode
settings before DXR for correct behaviour, so load MDR first with
STT cleared and later load again with STT set.
Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985
Signed-off-by: Jon Povey jon.po...@racelogic.co.uk
Acked-by: Troy Kisky troy.ki...@boundarydevices.com
Tested-by: Sudhakar Rajashekhara sudhakar@ti.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
---
This patches to what was v4 of the original patch.
The original patch which made it to 2.6.36-rc7 will as I understand it have
introduced a regression for OMAP-L138 so this patch is a regression fix and
wants to get into 2.6.36.
drivers/i2c/busses/i2c-davinci.c | 24 +++-
1 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index b8feac5..5795c83 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -331,21 +331,16 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct
i2c_msg *msg, int stop)
INIT_COMPLETION(dev-cmd_complete);
dev-cmd_err = 0;
- /* Take I2C out of reset, configure it as master and set the
-* start bit */
- flag = DAVINCI_I2C_MDR_IRS | DAVINCI_I2C_MDR_MST | DAVINCI_I2C_MDR_STT;
+ /* Take I2C out of reset and configure it as master */
+ flag = DAVINCI_I2C_MDR_IRS | DAVINCI_I2C_MDR_MST;
/* if the slave address is ten bit address, enable XA bit */
if (msg-flags I2C_M_TEN)
flag |= DAVINCI_I2C_MDR_XA;
if (!(msg-flags I2C_M_RD))
flag |= DAVINCI_I2C_MDR_TRX;
- if (stop)
- flag |= DAVINCI_I2C_MDR_STP;
- if (msg-len == 0) {
+ if (msg-len == 0)
flag |= DAVINCI_I2C_MDR_RM;
- flag = ~DAVINCI_I2C_MDR_STP;
- }
/* Enable receive or transmit interrupts */
w = davinci_i2c_read_reg(dev, DAVINCI_I2C_IMR_REG);
@@ -358,17 +353,28 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct
i2c_msg *msg, int stop)
dev-terminate = 0;
/*
+* Write mode register first as needed for correct behaviour
+* on OMAP-L138, but don't set STT yet to avoid a race with XRDY
+* occuring before we have loaded DXR
+*/
+ davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
+
+ /*
* First byte should be set here, not after interrupt,
* because transmit-data-ready interrupt can come before
* NACK-interrupt during sending of previous message and
* ICDXR may have wrong data
+* It also saves us one interrupt, slightly faster
*/
if ((!(msg-flags I2C_M_RD)) dev-buf_len) {
davinci_i2c_write_reg(dev, DAVINCI_I2C_DXR_REG, *dev-buf++);
dev-buf_len--;
}
- /* write the data into mode register; start transmitting */
+ /* Set STT to begin transmit now DXR is loaded */
+ flag |= DAVINCI_I2C_MDR_STT;
+ if (stop msg-len != 0)
+ flag |= DAVINCI_I2C_MDR_STP;
davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
r = wait_for_completion_interruptible_timeout(dev-cmd_complete,
--
1.6.3.3
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v4] i2c: davinci: Fix race when setting up for TX
Kevin Hilman wrote: I just noticed that it has already been pulled and is part of -rc7. Jon, care to submit a new patch with v4 diff and including the acks and tested-bys? Done and sent: Message-Id: 1286858825-21540-1-git-send-email-jon.po...@racelogic.co.uk -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v4] i2c: davinci: Fix race when setting up for TX
Hi Ben, I am not on the i2c list but noticed this pull request: http://www.spinics.net/linux/lists/linux-i2c/msg04022.html I think you have the wrong (old) version of this patch in that branch, http://git.fluff.org/gitweb?p=bjdooks/linux.git;a=commitdiff;h=4bba0fd8d1c6d405df666e2573e1a1f917098be0 The correct v4 one from the start of this thread has more lines of patch and this commit message: When setting up to transmit, a race exists between the ISR and i2c_davinci_xfer_msg() trying to load the first byte and adjust counters. This is mostly visible for transmits 1 byte long. The hardware starts sending immediately that MDR.STT is set. IMR trickery doesn't work because if we start sending, finish the first byte and an XRDY event occurs before we load IMR to unmask it, we never get an interrupt, and we timeout. Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode settings before DXR for correct behaviour, so load MDR first with STT cleared and later load again with STT set. Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985 Signed-off-by: Jon Povey jon.po...@racelogic.co.uk CC: Sudhakar Rajashekhara sudhakar@ti.com CC: Troy Kisky troy.ki...@boundarydevices.com It also has some more acks and a tested, via Kevin: Acked-by: Troy Kisky troy.ki...@boundarydevices.com Tested-by: Sudhakar Rajashekhara sudhakar@ti.com Acked-by: Kevin Hilman khil...@deeprootsystems.com -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: UBI crashes / fixing NAND subpage writes
Marc-Andre Chenier wrote: Hi, I found that the most elegant way to patch the problem is to not use sub page at all. This can be done by adding the NAND_NO_SUBPAGE_WRITE options bit exception to the NAND chip option mask. This is nice and simple but makes less efficient use of the flash and may (not sure) mean slower mount times due to the scan. You can also pass a VID offset of 2048 to ubiattach to need no kernel patching.. but if you forget it, on my system at least it got locked in a loop torturing the same block again and again. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: UBI crashes / fixing NAND subpage writes
davinci-linux-open-source-boun...@linux.davincidsp.com wrote: Jon, i studied the davinci subpage write problem to find an applicable solution, but can not come up with a good idea. Your findings about the cause of the problem is totally correct but there is a question in my mind: Nand subpage support is added to the mainline kernel with this patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.g it;a=commit;h=29072b96078ffde36f03d51e6b5d0cff1ba8c7df link Since its in mainline i guess nand subpage support is working with other nand controllers, but not with davinci. There must be a way to solve this problem within the davinci_nand.c driver without touching the main nand API's. Unfortunately there is not a good way of doing it only within davinci that I can see. The problem is that the nand_base layer handles a subpage write by writing a whole page, with areas outside the written subpage set to FFs. The davinci layer can't tell the difference. I hacked this up by adding start offset and length parameters to all the page writing functions, which works for me but isn't going to be acceptable for mainline. Artem over on the MTD list suggested a write_subpage family of functions might be the way to go, but I haven't implemented that. http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2010-September/020206.html -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: musb: repeatable CPPI DMA hang bug on peripheral RX 64 byte packet
Felipe Balbi wrote: On Thu, Sep 23, 2010 at 06:35:11AM -0500, Jon Povey wrote: loading musb_hdrc with debug=7 shows up some suspicious differences when receiving a 64-byte line, some console logs below. I note that bits 0x3 of csr are set in the problem case. that's RxPktRdy and FifoFull. Yup. But I don't know enough about this driver and hardware to know what that implies. Can you check if you have the same with 512 byte transfers ?? Yes, it looks like it. 511 is ok, 512 locks up rx and gives the below on the console. 128 chars also locks things up. cppi_interrupt 1173: CPPI IRQ Tx0 Rx1 cppi_dump_rx 378: RX DMA0/K: 0 left, csr 2003, H S86eb78a0 C86eb78a0, B879eea00 L0200 0200 .. 86eb78a0 cppi_rx_scan 1046: C/RXBD 86eb78a0: nxt buf 879ee800 off.len 0200 opt.len d200 (0) cppi_dump_rx 378: RX DMA0/completed: 0 left, csr 2003, H S86eb78a0 C86eb78a0, B879eea00 L0200 0200 .. 86eb78a0 musb_g_rx 763: == ep1out, rxcsr 2003 (dma) c6efdcc0 musb_g_rx 806: RXCSR1 0003, dma off, 0003, len 512, req c6efdcc0 musb_g_giveback 143: ep1out done request c6efdcc0, 512/512 gs_read_complete: req c6efdcc0 cppi_next_rx_segment 832: RX DMA0 seg, maxp 512 onepacket bds 1 (cnt 0) dma 0x879eec00 len 512 0/512 RXBD/S 86eb78c0: nxt buf 879eec00 off.blen 0200 opt.plen e200 cppi_dump_rx 378: RX DMA0/S: 3 left, csr 0003, H86eb78c0 S86eb78a0 C86eb78a0, B879eea00 L0200 0200 .. 86eb78a0 davinci_interrupt 292: IRQ ttyGS 512 bytes to tty (c C - ... 0x2e 0x0a) musb_gadget_queue 1148: == to ep1out request=c6efdcc0 musb_ep_restart 1088: == TX/IN request c6e927c0 len 1 on hw_ep1 txstate 298: hw_ep1, maxpacket 512, fifo count 1, txcsr 2404 what's this one byte you're sending back ? I snipped the rest but it seems the tty layer was echoing back each character, individually (!) stty -F /dev/ttyGS0 -echo stopped that. I don't remember it doing this echoing by default with 2.6.34.. Subsequent 63-byte RX (fails to arrive at tty) Not quite sure what's going on here, something very different: davinci_interrupt 292: IRQ 0001 musb_interrupt 1583: ** IRQ peripheral usb tx0001 rx only ep0 IRQ ?!? weird. Oh, I think was ACM traffic from the Windows app reopening the serial port when it gets a TX timeout. I stopped it doing that, now after sending a line with killer length, any subsequent line times out and there are no more console messages from usb. Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is ... remove this sort of footer when sending mails to the mailing list!!! I'd love to, but it's not my decision, and part of it is a legal requirement: http://www.theregister.co.uk/2006/12/21/new_web_email_regulation/ Sorry. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
musb: repeatable CPPI DMA hang bug on peripheral RX 64 byte packet
.. 86e71800 txstate 410: ep1in TX/IN dma len 0/1, txcsr 3404, fifo 1/512 cppi_interrupt 1172: CPPI IRQ Tx1 Rx0 cppi_dump_tx 405: TX DMA0/E: csr 3404, H S86e71800 C86e71800 86854a01, F0002 L0001 .. 86e71800 cppi_interrupt 1217: C/TXBD ff32a800 n 0 b 86854a00 off 1 opt d000 musb_g_tx 430: == ep1in, txcsr 3404 musb_g_tx 475: TXCSR1 2400, DMA off, len 1, req c6e927c0 musb_g_giveback 143: ep1in done request c6e927c0, 1/1 musb_g_tx 522: ep1in idle now Subsequent 63-byte RX (fails to arrive at tty) Not quite sure what's going on here, something very different: davinci_interrupt 292: IRQ 0001 musb_interrupt 1583: ** IRQ peripheral usb tx0001 rx musb_g_ep0_irq 671: csr 0001, count 8, myaddr 3, ep0stage idle musb_read_fifo 283: RX ep0 fifo fec64420 count 8 buf c0363e36 musb_read_setup 605: SETUP req21.22 v i l0 musb_g_ep0_irq 853: handled 0, csr 0001, ep0stage wait g_serial gadget: acm ttyGS0 req21.22 v i l0 musb_g_ep0_queue 959: queue to ep0 (OUT/RX), length=0 musb_g_giveback 143: ep0 done request c6eca040, 0/0 -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
New WARN from dm9000 since merge to 2.6.36-rc4
80020ce8 41069265 80020cb4 c0363f9c 60d3 c0363f90 3f80: c0027a4c c0027a58 6013 r5:fec48000 r4: [c0027a24] (default_idle+0x0/0x38) from [c0027fd8] (cpu_idle+0x78/0xe4) [c0027f60] (cpu_idle+0x0/0xe4) from [c0290940] (rest_init+0xa8/0xc0) r5:c0381a60 r4:0002 [c0290898] (rest_init+0x0/0xc0) from [c00089f0] (start_kernel+0x270/0x2c4) r5:c0381a60 r4:c0396584 [c0008780] (start_kernel+0x0/0x2c4) from [80008034] (0x80008034) r5:c0381b04 r4:00053175 ---[ end trace af4a93804142fc65 ]--- , OK IP-Config: Got DHCP answer from 192.168.1.1, my address is 192.168.1.142 IP-Config: Complete: device=eth0, addr=192.168.1.142, mask=255.255.255.0, gw=192.168.1.1, host=192.168.1.142, domain=, nis-domain=(none), bootserver=192.168.1.1, rootserver=192.168.1.140, rootpath= Looking up port of RPC 13/2 on 192.168.1.140 Looking up port of RPC 15/1 on 192.168.1.140 VFS: Mounted root (nfs filesystem) on device 0:14. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v4] i2c: davinci: Fix race when setting up for TX
When setting up to transmit, a race exists between the ISR and
i2c_davinci_xfer_msg() trying to load the first byte and adjust counters.
This is mostly visible for transmits 1 byte long.
The hardware starts sending immediately that MDR.STT is set. IMR trickery
doesn't work because if we start sending, finish the first byte and an
XRDY event occurs before we load IMR to unmask it, we never get an
interrupt, and we timeout.
Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode
settings before DXR for correct behaviour, so load MDR first with
STT cleared and later load again with STT set.
Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985
Signed-off-by: Jon Povey jon.po...@racelogic.co.uk
CC: Sudhakar Rajashekhara sudhakar@ti.com
CC: Troy Kisky troy.ki...@boundarydevices.com
---
Reworked after comments by Troy and Sudhakar.
Looking at the datasheet it seemed like setting STP without STT early
might cause a stray STOP to be generated, so I moved it into the second
MDR load.
This passes a quick smoke test but I can't do much more testing right at
the moment. Sudhakar, your comments would be welcomed.
drivers/i2c/busses/i2c-davinci.c | 24 +++-
1 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index c87..5795c83 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -331,21 +331,16 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct
i2c_msg *msg, int stop)
INIT_COMPLETION(dev-cmd_complete);
dev-cmd_err = 0;
- /* Take I2C out of reset, configure it as master and set the
-* start bit */
- flag = DAVINCI_I2C_MDR_IRS | DAVINCI_I2C_MDR_MST | DAVINCI_I2C_MDR_STT;
+ /* Take I2C out of reset and configure it as master */
+ flag = DAVINCI_I2C_MDR_IRS | DAVINCI_I2C_MDR_MST;
/* if the slave address is ten bit address, enable XA bit */
if (msg-flags I2C_M_TEN)
flag |= DAVINCI_I2C_MDR_XA;
if (!(msg-flags I2C_M_RD))
flag |= DAVINCI_I2C_MDR_TRX;
- if (stop)
- flag |= DAVINCI_I2C_MDR_STP;
- if (msg-len == 0) {
+ if (msg-len == 0)
flag |= DAVINCI_I2C_MDR_RM;
- flag = ~DAVINCI_I2C_MDR_STP;
- }
/* Enable receive or transmit interrupts */
w = davinci_i2c_read_reg(dev, DAVINCI_I2C_IMR_REG);
@@ -357,7 +352,11 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct
i2c_msg *msg, int stop)
dev-terminate = 0;
- /* write the data into mode register */
+ /*
+* Write mode register first as needed for correct behaviour
+* on OMAP-L138, but don't set STT yet to avoid a race with XRDY
+* occuring before we have loaded DXR
+*/
davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
/*
@@ -365,12 +364,19 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct
i2c_msg *msg, int stop)
* because transmit-data-ready interrupt can come before
* NACK-interrupt during sending of previous message and
* ICDXR may have wrong data
+* It also saves us one interrupt, slightly faster
*/
if ((!(msg-flags I2C_M_RD)) dev-buf_len) {
davinci_i2c_write_reg(dev, DAVINCI_I2C_DXR_REG, *dev-buf++);
dev-buf_len--;
}
+ /* Set STT to begin transmit now DXR is loaded */
+ flag |= DAVINCI_I2C_MDR_STT;
+ if (stop msg-len != 0)
+ flag |= DAVINCI_I2C_MDR_STP;
+ davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
+
r = wait_for_completion_interruptible_timeout(dev-cmd_complete,
dev-adapter.timeout);
if (r == 0) {
--
1.6.3.3
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Alpha blending on captured video with DM365.
davinci-linux-open-source-boun...@linux.davincidsp.com wrote: Hi, I need to display timestamps with transparent background (Capture date/time) on the captured video on DM365. You can't use the hardware OSD to do this alpha blending before encoding, the frame is blended before being output, there is no path back to RAM for the blended frame. Your options are to blend graphics onto the frame using software, or use external hardware to either do the blending or encoding. The DM365 can't do both in hardware. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v3] i2c: davinci: Fix race when setting up for TX
Troy Kisky wrote:
On 9/17/2010 6:09 AM, Sudhakar Rajashekhara wrote:
Hi,
Seems I didn't get Sudhakar's email.. I wonder why?
On Fri, Sep 17, 2010 at 08:32:11, Jon Povey wrote:
Move the MDR load after DXR,IMR loads to avoid this race without
locking.
I remember I had some issues on OMAP-L138 with this fix, that's when
I reverted to configuring ICMDR before writing to DXR (Please see
here: https://patchwork.kernel.org/patch/75262/). I checked the BIOS
I2C driver code for OMAP-L138 and there also we are configuring MDR
before accessing DXR.
Ah :/
How about killing the lines from commit
c6c7c729a22bfeb8e63eafce48dbaeea20e68703
---
/*
* First byte should be set here, not after interrupt,
* because transmit-data-ready interrupt can come before
* NACK-interrupt during sending of previous message and
* ICDXR may have wrong data
*/
if ((!(msg-flags I2C_M_RD)) dev-buf_len) {
davinci_i2c_write_reg(dev, DAVINCI_I2C_DXR_REG, *dev-buf++);
dev-buf_len--; }
--
and resetting the i2c upon a NAK interrupt (after the stop)
to clear the bad fifo data?
I can't really comment on how valid that would be and can't easily test it.
However preloading DXR does save one interrupt on transmit so the whole
operation is faster and more efficient.
Maybe v1 of my patch, with locking, is the best option?
--
Jon Povey
jon.po...@racelogic.co.uk
Racelogic is a limited company registered in England. Registered number 2743719
.
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks,
MK18 1TB .
The information contained in this electronic mail transmission is intended by
Racelogic Ltd for the use of the named individual or entity to which it is
directed and may contain information that is confidential or privileged. If you
have received this electronic mail transmission in error, please delete it from
your system without copying or forwarding it, and notify the sender of the
error by reply email so that the sender's address records can be corrected. The
views expressed by the sender of this communication do not necessarily
represent those of Racelogic Ltd. Please note that Racelogic reserves the right
to monitor e-mail communications passing through its network
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v2] i2c: davinci: Fix race when setting up for TX
When setting up to transmit, a race exists between the ISR and
i2c_davinci_xfer_msg() trying to load the first byte and adjust counters.
This is mostly visible for transmits 1 byte long.
The hardware starts sending immediately that MDR is loaded. IMR trickery
doesn't work because if we start sending, finish the first byte and an
XRDY event occurs before we load IMR to unmask it, we never get an
interrupt, and we timeout.
Move the MDR load after DXR,IMR loads to avoid this race without locking.
Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985
Signed-off-by: Jon Povey jon.po...@racelogic.co.uk
---
Troy, thanks for the input. I tried reordering the IMR load before but got
occasional timeouts. Went back to the logic analyser today and worked out
why, see above comment in the commit message.
Moving the MDR load seems to fix things without locking, much neater and
tiny patch.
As I understand it we can be confident inside i2c_davinci_xfer_msg() that
the peripheral is not busy sending or receiving something else, I had a
look at the other interrupt sources in the datasheet and this seems safe
enough.
I'm not sure what the correct thing to do for followup message IDs here..
My original email? Troy's? Clues welcome for next time.
drivers/i2c/busses/i2c-davinci.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index 72df4af..baa5209 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -349,9 +349,6 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct
i2c_msg *msg, int stop)
dev-terminate = 0;
- /* write the data into mode register */
- davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
-
/*
* First byte should be set here, not after interrupt,
* because transmit-data-ready interrupt can come before
@@ -371,6 +368,9 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct
i2c_msg *msg, int stop)
w |= DAVINCI_I2C_IMR_XRDY;
davinci_i2c_write_reg(dev, DAVINCI_I2C_IMR_REG, w);
+ /* write the data into mode register; start transmitting */
+ davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
+
r = wait_for_completion_interruptible_timeout(dev-cmd_complete,
dev-adapter.timeout);
if (r == 0) {
--
1.6.3.3
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v3] i2c: davinci: Fix race when setting up for TX
When setting up to transmit, a race exists between the ISR and
i2c_davinci_xfer_msg() trying to load the first byte and adjust counters.
This is mostly visible for transmits 1 byte long.
The hardware starts sending immediately that MDR is loaded. IMR trickery
doesn't work because if we start sending, finish the first byte and an
XRDY event occurs before we load IMR to unmask it, we never get an
interrupt, and we timeout.
Move the MDR load after DXR,IMR loads to avoid this race without locking.
Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985
Signed-off-by: Jon Povey jon.po...@racelogic.co.uk
---
Oops, v2 was based on the wrong version. Rebased so this should apply
against mainline.
Troy, thanks for the input. I tried reordering the IMR load before but got
occasional timeouts. Went back to the logic analyser today and worked out
why, see above comment in the commit message.
Moving the MDR load seems to fix things without locking, much neater and
tiny patch.
As I understand it we can be confident inside i2c_davinci_xfer_msg() that
the peripheral is not busy sending or receiving something else, I had a
look at the other interrupt sources in the datasheet and this seems safe
enough.
I'm not sure what the correct thing to do for followup message IDs here..
My original email? Troy's? Clues welcome for next time.
drivers/i2c/busses/i2c-davinci.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index c87..b8feac5 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -357,9 +357,6 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct
i2c_msg *msg, int stop)
dev-terminate = 0;
- /* write the data into mode register */
- davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
-
/*
* First byte should be set here, not after interrupt,
* because transmit-data-ready interrupt can come before
@@ -371,6 +368,9 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct
i2c_msg *msg, int stop)
dev-buf_len--;
}
+ /* write the data into mode register; start transmitting */
+ davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
+
r = wait_for_completion_interruptible_timeout(dev-cmd_complete,
dev-adapter.timeout);
if (r == 0) {
--
1.6.3.3
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Prefered web server fo Davinci
davinci-linux-open-source-boun...@linux.davincidsp.com wrote: Could someone please tell me if there is a better, smaller, easier to cross compile, and secure web server that you would recommend? http://www.acme.com/software/thttpd/ looks promising at a glance. I haven't tried it, but it's small and uses GNU configure so may not be painful to cross-compile. I'd be interested to know your results - I may need to do something similar soon. As for security.. always a crapshoot. Perhaps you gain a little security through obscurity not using Apache. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
UBI crashes / fixing NAND subpage writes
I have been playing with UBI/UBIFS on 2KB page NAND, on TI DaVinci DM355 and having crashes due to subpage write problems. ubiattach with -O 2048 avoids the problem, but I want to fix it, and use the flash more efficiently in space and time. The DaVinci family generate 10 bytes of ECC in hardware for each 512 bytes of data; on 2KB page NAND the 4x10 bytes of ECC are concatenated together at the end of a page. The problem is that the ECC generated for an all-FFs page is not all-FFs, and subpage writes are handled by nand_do_write_ops() by writing a full page with FFs in the unset data areas. When UBI attaches it detects the subpage size as 512 bytes and tries to do two subpage writes, which results in two writes of (different) non-FF ECC data, causing corrupt ECC. An ubiattach, ubidetach, ubiattach sequence puts the kernel into a loop torturing the same block over and over, repeating these lines: UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB 2:512, read 512 bytes UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB 263:512, read 512 bytes UBI: run torture test for PEB 263 UBI: PEB 263 passed torture test, do not mark it a bad I hacked around this as a proof-of-concept by checking for an all-FF subpage in nand_write_page_hwecc() and setting that subpage's ECC to all-FFs, which works - I can attach, detatch, reattach, mount, write files, etc. Of course this is not a very good solution. The right thing to do would seem to be make nand_do_write_ops() properly subpage aware and either add start and end offsets to the nand_write_page* family of functions, or add a nand_write_subpage* family of functions. I don't mind having a go at some of this but am not confident to start such major overhaul of nand_base.c without at least seeking comment from others, so: This email. Maybe there's already something being worked on? Comments welcome... -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: DM365 - Watchdog Timer
Hank Magnuski wrote: I'm trying to find code in UBL and/or U-Boot where the watchdog timer is reset. Is that part of the normal boot process, or is it only done in Linux? UBL and U-Boot don't touch the WDT. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
SDIO WIFI for DM355? [Hijacked, was: Is there a USB 802.11n wifi card which suit DM6446?]
Subbrathnam, Swaminathan wrote: Zydas 1211b chipset - (now) Atheros chipset, from edimax and other vendors. Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network A related question; anyone care to recommend an SDIO WIFI card for use with DM355? Thanks, -- Jon Povey jon.po...@racelogic.co.uk ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
C implementation of DaVinci 4-bit NAND ECC?
Just on the off-chance I'm reinventing the wheel, are there any C implementations of the DaVinci 4-bit NAND ECC algorithm out there? I am aware of the C# implementation in the TI flash_utils, looking through it there is more Scary Maths than I anticipated. Planning to reverse-engineer and rewrite it in C, hardcoded for 512 bytes + 4-bit sizing, unless there is a better idea (no, I don't want to use Mono, and it needs to build with GCC.) For context, this is to run on the DM355 so I can calculate ECC in software and write NAND flash in raw mode with different OOB layouts. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
How to stop mtd char device generating ECC on writes?
I am trying to write a binary image to NAND flash using nandwrite on TI DaVinci DM355. For historical reasons involving badly-written ROM bootloaders, I want to write the legacy OOB format for one area of flash (the UBL, second-stage bootloader). For reference the legacy layout of a 2KB flash page is 4x (512B data followed by 16B OOB (6 spare then 10 ECC)). The new format used by u-boot, MTD etc. is 2KB data followed by 64B OOB (24 spare then 40 ECC). I can get a bootloader image with the needed (legacy) OOB and ECC using nanddump -f ubl0.dump -s 0x2 -l 0x8000 -n /dev/mtd0 But I can't seem to write it back properly using nandwrite. Testing on another partition mtd6, If I do this: nandwrite -r -s 0x2 /dev/mtd6 ubl0.dump then it seems my 64 bytes of OOB are skipped and I get a generated 24 bytes of 0xFF spare and 40 bytes of generated ECC. If I use --noecc --oob instead of -r, it looks like my 64 bytes of OOB does get written, but then hardware ECC is getting written OVER THE TOP, i.e. the last 40 bytes have various bits 0 that should be 1 (but no 1s that should be 0) I am looking through the nandwrite and drivers/mtd sources at the moment, but would love to get a clue if someone can tell me - Does MTD support what I'm trying to do from userland? - If yes, could this be a bug in the DaVinci NAND driver? - Or, is nandwrite supposed to support this? or do I need to modify it? Thanks folks, -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: How to stop mtd char device generating ECC on writes?
Matthieu CASTET wrote: Jon Povey a écrit : - Does MTD support what I'm trying to do from userland? yes write in raw mode + MEMWRITEOOB. But you will need 2 number of program. Thanks Matthieu. Sod's law, I actually found the answer a few minutes after sending the email.. Realised I hadn't tried --noecc --raw combination of switches. Works great. Sorry for noise, hopefuly some archive reader can learn from my mistake. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Linux Usb key and Fat buffer.
Pierre wrote: we are expriencing a peridodic slow down of the writing speed of the images. We have not mounted the key as physically synchronised. - Should i use in my application a fifo buffer for writing data to avoid the slow down? I found similar things a while back with 2.6.10, ended up splitting the app into two threads, producer and writer. That worked to smooth out the slow spots. As for the underlying cause.. I'd love to know. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v3] davinci: Add MityDSP-L138/MityARM-1808 SOM support
Nori, Sekhar wrote: On Tue, Jul 27, 2010 at 08:32:18, Jon Povey wrote: I have one type switch at the moment which I'm intending to do in this way; sensing a gpio pull in a driver. Why is this bad? It doesn't feel too great, but.. not seen any threads about it. If you could point me at these discussions, I'd appreciate it. In my mind this thread remains the most comprehensive discussion on this topic: http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg11285.html Quoting David Brownell from somewhere in that long thread: I thought there was pretty much a consensus that drivers should never be directly involved in pinmux. Among other things, it's rare that those details stay the same between different revisions of a given SoC. Oh, OK, pinmux. I think my situation is sufficiently different, bespoke, and obscure.. and doesn't mess with pinmuxing. Thanks for the info. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
UBI and subpage writes on DaVinci
I am getting started with UBI/UBIFS on DM355, things go quite wrong if I use the default options to ubiattach; I have to use the -O 2048 option to force the location of some metadata to a page offset (on 2K page SLC NAND). I can live with this, but - aiui I lose 4KB to UBI metadata per 128K eraseblock, instead of 2K - something is clearly wrong somewhere and should be fixed, either the default 512-byte offset it is trying to use should work, or it should be detecting that it must use the 2048-byte offset. I found this which looks similar, from Caglar Akyuz: http://patchwork.ozlabs.org/patch/50601/ Anyone run into this and know the issues? Any clues welcome. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v3] davinci: Add MityDSP-L138/MityARM-1808 SOM support
Hi Michael, I am coming up against some similar sounding issues here for supporting multiple hardware configurations. Michael Williamson wrote: c) Allow peripheral drivers to probe and initialize pins, etc. in the modules, then load the right drivers up for your board. There are a lot of threads about why letting drivers mess with the pins is bad. So this is a non-starter. I have one type switch at the moment which I'm intending to do in this way; sensing a gpio pull in a driver. Why is this bad? It doesn't feel too great, but.. not seen any threads about it. If you could point me at these discussions, I'd appreciate it. Thanks, and good luck with your projects, -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Anyone using ftrace on DaVinci git?
Is anyone using ftrace on DaVinci git with success? I'm trying to use the irqsoff tracer to look into an irq latency problem on DM355, but it seems not to be recording small time changes, jumping in units of 10ms. Example partial trace: ksoftirq-3 0d..1.0us : finish_task_switch -trace_hardirqs_on ksoftirq-3 0d..1.0us : trace_hardirqs_on -trace_hardirqs_on ksoftirq-3 0d..1.0us : do_softirq -trace_hardirqs_off ksoftirq-3 0d.s1.0us : __do_softirq -trace_hardirqs_on ksoftirq-3 0d.s1.0us : trace_hardirqs_on -trace_hardirqs_on ksoftirq-3 0d.s1.0us!: hrtimer_peek_ahead_timers -trace_hardirqs_off ksoftirq-3 0d.s1. 2us : hrtimer_peek_ahead_timers -trace_hardirqs_on ksoftirq-3 0d.s1. 2us : trace_hardirqs_on -trace_hardirqs_on ksoftirq-3 0d.s1. 2us : stack trace Related, I have an IRQ handler that seems to be getting interrupted for up to 2+ms by something. This surprises me, I thought IRQs should be disabled? I wonder if CONFIG_PREEMPT is related? Any hints welcome. For now I suppose I'll go back to poking around with LED wiggling and logic analyser. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v2] mtd-nand: davinci: correct 4-bit error correction
Sudhakar Rajashekhara wrote:
On TI's DA830/OMAP-L137, DA850/OMAP-L138 and DM365, after setting the
4BITECC_ADD_CALC_START bit in the NAND Flash control register to 1 and
before waiting for the NAND Flash status register to be equal to 1, 2
or 3, we have to wait till the ECC HW goes to correction state.
Without this wait, ECC correction calculations will not be proper.
This has been tested on DA830/OMAP-L137, DA850/OMAP-L138, DM355 and
DM365 EVMs.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
Acked-by: Sneha Narnakaje nsnehapra...@ti.com
Cc: David Woodhouse dw...@infradead.org
Signed-off-by: Andrew Morton a...@linux-foundation.org
Have these people acked and signed off this new version of the patch?
Since v1:
a. Timeout has been changed from 100 msec to 100 usec.
b. Comment above the do, while loop was not matching the code.
This has been corrected.
c. Initialization of 'timeo' variable has been moved down.
d. It was observed that, while calculating the time in the loop,
if there is a context switch between setting the
4BITECC_ADD_CALC_START bit and reading of ECC_STATE field, then
the loop will not come out until the timeout happens. To prevent
the context switch, spin_lock_irqsave and spin_unlock_irqrestore
are used.
d. means interrupts are disabled for up to 100us while waiting for ECC.
Doesn't sound good if it can be avoided.
How about instead of spinlock, set timeo first time inside the loop?
From this:
+ timeo = jiffies + usecs_to_jiffies(100);
+ do {
+ ecc_state = (davinci_nand_readl(info,
+ NANDFSR_OFFSET) 8) 0x0f;
+ cpu_relax();
+ } while ((ecc_state 4) time_before(jiffies, timeo));
+ spin_unlock_irqrestore(ecc_spin_lock, flags);
To something like:
+ timeo = 0;
+ do {
+ ecc_state = (davinci_nand_readl(info,
+ NANDFSR_OFFSET) 8) 0x0f;
+ if (!timeo)
+ timeo = jiffies + usecs_to_jiffies(100);
+ cpu_relax();
+ } while ((ecc_state 4) time_before(jiffies, timeo));
Sorry if my mailer has messed up the formatting. Hopefuly readable.
--
Jon Povey
jon.po...@racelogic.co.uk
Racelogic is a limited company registered in England. Registered number 2743719
.
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks,
MK18 1TB .
The information contained in this electronic mail transmission is intended by
Racelogic Ltd for the use of the named individual or entity to which it is
directed and may contain information that is confidential or privileged. If you
have received this electronic mail transmission in error, please delete it from
your system without copying or forwarding it, and notify the sender of the
error by reply email so that the sender's address records can be corrected. The
views expressed by the sender of this communication do not necessarily
represent those of Racelogic Ltd. Please note that Racelogic reserves the right
to monitor e-mail communications passing through its network
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: GPIO in userspace
Nicolas Luna wrote: Hi, I wonder what would be the easiest way to control GPIO in userspace. I read the documentation gpio.txt but I'm not sure what I should use (Control interfaces?, GPIO controllers?) and how to implement it. Is there more explication about int gpio_export_link(struct device *dev, const char *name, unsigned gpio) because I think it could be the key. Will I need to write my own module and communicate with it?. You don't need to write a module. You can access GPIOs from a shell script: echo $GPIO_NUMBER /sys/class/gpio/export creates a directory /sys/class/gpio/gpio$GPIO_NUMBER, e.g. 8. (That will fail if something else like a driver has requested that gpio already). cat /sys/class/gpio/gpio8/value gets the value 0/1 echo 1 /sys/class/gpio/gpio8/direction sets it to output (iirc) echo 1 /sys/class/gpio/gpio8/value now sets the output value. echo 8 /sys/class/gpio/unexport to release it when you are finished. gpio_export_link() is for when you claim a gpio for use in the kernel but also want to export one of the above kind of sysfs entries. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] i2c: davinci: Fix race when setting up for TX
Move the interrupt enable after the first byte load for TX, as it
was racing with the interrupt handler and corrupting dev-buf_len
for messages 1 byte.
Tested on DM355.
Signed-off-by: Jon Povey jon.po...@racelogic.co.uk
---
The race seems to have been introduced by
869e6692d527983958216f13c3c8e095791909df
This fixes the problem for me, but someone from TI might want to comment
on the validity of starting the transfer before enabling the RDY interrupts.
Any possibility of losing interrupts?
Considered a spinlock but if this reordering is OK then it's neater.
I'm guessing not many people have been sending multi-byte messages..
drivers/i2c/busses/i2c-davinci.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index c87..72df4af 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -347,14 +347,6 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct
i2c_msg *msg, int stop)
flag = ~DAVINCI_I2C_MDR_STP;
}
- /* Enable receive or transmit interrupts */
- w = davinci_i2c_read_reg(dev, DAVINCI_I2C_IMR_REG);
- if (msg-flags I2C_M_RD)
- w |= DAVINCI_I2C_IMR_RRDY;
- else
- w |= DAVINCI_I2C_IMR_XRDY;
- davinci_i2c_write_reg(dev, DAVINCI_I2C_IMR_REG, w);
-
dev-terminate = 0;
/* write the data into mode register */
@@ -371,6 +363,14 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct
i2c_msg *msg, int stop)
dev-buf_len--;
}
+ /* Enable receive or transmit interrupts */
+ w = davinci_i2c_read_reg(dev, DAVINCI_I2C_IMR_REG);
+ if (msg-flags I2C_M_RD)
+ w |= DAVINCI_I2C_IMR_RRDY;
+ else
+ w |= DAVINCI_I2C_IMR_XRDY;
+ davinci_i2c_write_reg(dev, DAVINCI_I2C_IMR_REG, w);
+
r = wait_for_completion_interruptible_timeout(dev-cmd_complete,
dev-adapter.timeout);
if (r == 0) {
--
1.6.3.3
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: DM365 UBoot + NAND Query
Krunal Patil wrote: NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron NAND 1GiB 3,3V 8-bit) 2 NAND chips detected Creating 5 MTD partitions on nand_davinci.0: 0x-0x0078 : bootloader 0x0078-0x0080 : params 0x0080-0x00c0 : kernel 0x00c0-0x20c0 : filesystem1 0x20c0-0x8000 : filesystem2 I don't see anything wrong the NAND partition. I simply tried to erase the mtd4 partition using flash_eraseall /dev/mtd4. The erase was successful. But next time when I reboot the board it does not booted up. It has erased the UBL/UBoot also. Am I missing something or doing something wrong? Please suggest. The partitions look OK. Are the chip selects on your board wired up with the right logic and no shorts? Try scoping the chip selects on both chips while running the erase. Looks like it might be erasing both? -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: DM365 UBoot + NAND Query
Steve Poulsen wrote: 1) Use hexdump to view the first bit of the bootloader and note the data values. 2) Load a filesystem into filesystem2. 3) Use hexdump to view the first bit of the bootloader and note the changes. 4) hexdump filesystem2 and search for the pattern. ( you might dump it to NFS filesystem for easier searching) Good suggestions - Krunal note if you try this first one, you may have to write a lot of data to filesystem2 before you see it overwrite the bootloader. If it's completely erased then writing about 512MB (0x2000) should cross into the second chip select. But wear levelling abstration layers may move things around or leave gaps. I would try Steve's u-boot approach: 1) In u-boot, use the nand commands to erase, write, and dump. You should be able to narrow it down to writing to block N causes block M to also change. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Shouldn't PINMUX configuration be board specific ?
Caglar Akyuz wrote: On Thursday 17 June 2010 11:43:27 am Christophe Aeschlimann wrote: I was surprised to see that the PINMUX registers configuration (in da850.c) is SOC dependant (part of common initialisation). I think the PINMUX configuration is definitely a board specific setting. Actually it is not SoC specific. Possible pinmux configurations are defined in SoC specific files, then they are adjusted in board specific files using 'davinci_cfg_reg' which is defined in mach/mux.h. There is at least one instance I have run into: dm355.c:dm355_ccdc_setup_pinmux() hardcodes several VPFE pins as video inputs, 3 of which aren't used on our board. Not sure how this should ideally be fixed, not a big deal for us, maybe an array of muxes passed as platform data for ccdc? -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: DM365 UBoot + NAND Query
Krunal Patil wrote: I am working on a DM365 based customize board which has two nand chips each of 1GB. At the UBoot level I am getting following errors: UBoot Log: U-Boot 2009.03 (Mar 18 2010 - 20:23:55) I2C: ready DRAM: 128 MB NAND: NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron NAND 1GiB 3,3V 8-bit) Bad block table found at page 262080, version 0x01 Bad block table found at page 262016, version 0x01 nand_bbt: ECC error while reading bad block table NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron NAND 1GiB 3,3V 8-bit) Bad block table found at page 262080, version 0x01 Bad block table found at page 262016, version 0x01 nand_bbt: ECC error while reading bad block table 2048 MiB 1.Why the bad blocks for the the NANDs are shown for the same page? That is normal: Those page numbers are per chip. the BBTs are stored at the same offset in each chip. I would be more concerned about the ECC errors and that the kernel is reporting BBT not found. Bad block table not found for chip 0 Bad block table not found for chip 1 Bad block table not found for chip 0 Bad block table not found for chip 1 I suspect you have large page OOB layout mismatch issues between u-boot and kernel. And at some point in the past, u-boot didn't do 4-bit ECC correctly anyway, not sure when it was fixed. Seems to be OK by version 2010.03. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: DM365 UBoot + NAND Query
Krunal Patil wrote: 1.How can I verify whether UBoot is detecting and accessing both the NANDs not only one? u-boot can read, write and erase NAND; you could erase and write a page on one chip and see if it shows up on the other. 2.Can you please through some light on I would be more concerned about the ECC errors and that the kernel is reporting BBT not found. Well, this should not happen: nand_bbt: ECC error while reading bad block table And the kernel should find the BBTs, it should agree with U-boot. I suggest trying a more recent version of u-boot if that's an option. 3.How can I verify Large page OOB layout in UBoot and Kernel? How can I fix this mismatch? I find OpenOCD useful, it's JTAG software with davinci NAND drivers for both large page layouts, and config files for many davinci boards. If you do that, build the latest version from git, there have been some important patches to davinci NAND handling since the last released version 0.4.0. The source code for the OpenOCD davinci NAND driver should help you understand the layout differences. Also, I think there is some related stuff in the silicon errata for DM365. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Booting Via TFTP and NFS
amr ali wrote: I figured out the command dhcp in uboot sets the serverip env variable automatically. How can I override that behavior. What I want is to get dynamic ip using my boot loader, then do tftp booting from my machine ip not the dhcp server ip. How can I do that?!! -- I had the same thing. Set the variable autoload=no Then make your bootcmd something like dhcp; setenv serverip x.x.x.x; tftpboot -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Reseting USB port power
Alok Kumar wrote: I am using kernel 2.6.30 from the davinci git tree with Davinci 6446. We don't have any hardware discrete attach to USB power supply and we are looking for SW way to reset the USB power supply or something which does equivalent. It's an ugly hack, but you can try building the USB driver as a module and unloading / reloading it from userland. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: MUSB: Idea: board-specific OTG ID pin interrupt support
jean-philippe francois wrote: 2010/6/3 Jon Povey jon.po...@racelogic.co.uk: jean-philippe francois wrote: I achieved this by monitoring '/sys/devices/platform/musb_hdrc/mode' in user space. We did similar using hotplug events on 2.6.10 for both mmc and usb storage. But there is no hotplug event in gadget mode . No. We worked around that ;) It's a portable video recorder which you can plug a USB stick into to record. You can also (swap cables and) plug into a PC, when it goes into gadget serial mode to communicate with our setup software. We did this on 2.6.10 by having two sets of USB modules build in Host and Peripheral mode, and our own driver monitor the ID pin and unload/reload modules. It worked, but OTG would be cleaner, faster to switch and not needing of nasty build time hacks. So all the ID pin sensing is in addition to the DM OTG machinery, or is it a replacement for a malfunctionning OTG mode, where you kind of manually switch from one role to another ? It was the latter. I am planning / working on integrating it into the OTG machinery. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Davinci GPIO - IRQ confusion
David Brownell wrote: Because there isn't an actual IRQ for each pin, they need to be virtual. Actually, some of them could be real IRQs instead of being dispatched through the GPIO bank IRQ (which is a real IRQ, of course). But that gets messy. At one point it didn't work at all in Linux. It should work now, but as a rule you should expect IRQs associated with DaVinci GPIOs to be dispatched through some top-level bank IRQ ... most Linux platforms do the same thing (so doing anything else is what should be a surprise). I suppose that's just my inexperience showing, then. It does seem confusing that there are two sets of values called irq used in the kernel code, one agreeing with the datasheet and one made-up token. I'm sure it's all straightforward when you're used to it, and really who is to say what's a real IRQ anyway, as the AINTC is a Davinci-specific thing as much as banked GPIO interrupts, the ARM only having two really hard interrupts. It made more sense as the dust settled. A shame it violates the principle of least surprise (to my eyes) but I see why and can't think of a good clean fix without another layer of abstraction. Shutting up. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: The state of MUSB OTG + CPPI DMA..?
Hi Sergei, I am reading up on the OTG state machine, also on my board I have USB ID wired to a GPIO so may be able to hack in an interrupt to help me out if I have to. Meanwhile though here is what I have found; thanks for any clues: Sergei Shtylyov wrote: Jon Povey wrote: but having some problems with it not finding memory sticks in host mode after connecting as a gadget, IIRC, that should be cured by adding musb_platfrom_try_idle() to drivers/usb/musb/davinci.c. I'm not sure why it lacks this function, while it's been proven that DA830 needs it. You can try copying the code from omap2430.c (you'll also have to modify the #ifdef'ery around the declaration in musb_core.h). My memory may be wrong though... I had a go at hacking that in, triggering otg_timer() with some extra case statements. I can see it printing things during module shutdown at debug level 4. It hasn't made any difference to my main issues which are: After use in host mode (memory stick detected), swapping cables for use in gadget (serial) mode, does not react to cable connect/disconnect. Gadget mode does work if tried first after module load, and can disconnect/reconnect multiple times (until cables are swapped and a memory stick is used) I have two USB memory sticks here which I will call good and bad. Different models, both work fine on PC, I have no reason to think there is anything wrong with the bad stick, but the bad stick will only be detected after the good stick has successfully been detected, or immediately after driver module load iff the correct cable was connected at module load time. Note the stick doesn't have to be plugged into the cable at module load time, the cable just has to be plugged into the board. After use in gadget mode and swapping cables, the bad stick will not be detected until the good stick has been. I will paste a couple of console logs at the end of this email. and a few weird error messages. Like? When I have a memory stick connected and detected, if I remove the cable from the board I get dma warnings: usb 1-1: USB disconnect, address 11 drivers/usb/musb/davinci.c musb_platform_enable: dma not reactivated This doesn't happen if I remove the stick from the cable but leave the cable connected to the board, then remove the cable a few seconds later. The cable connector has the ID pin grounded.. I assume it's something to do with that. I looked at the code generating the dma warnings; it seems to be a flag that's not actually associated with any DMA (dma_off in davinci.c) - seems to be pointless. Also, a possible red herring: I have times when I will get a console screen full of messages like serial8250: too much work for irq14 serial8250: too much work for irq14 ttyS2: 5 input overrun(s) serial8250: too much work for irq14 which seems to be associated with loading and doing things with the musb driver, but only very loosely and intermittently. May be something else entirely. We do have something hooked up to ttyS2 sending lots of data that's probably not configured right yet, so ignore this if it doesn't mean anything to you. Log for gadget - memory stick -- r...@h:/# # disconnect gadget r...@h:/# davinci_interrupt 362: IRQ 0001 musb_interrupt 1505: ** IRQ peripheral usb0001 tx rx musb_stage0_irq 380: == Power=f0, DevCtl=99, int_usb=0x1 musb_stage0_irq 564: SUSPEND (b_peripheral) devctl 99 power f0 musb_g_suspend 1921: devctl 99 r...@h:/# # plug in host cable r...@h:/# # plug in black stick (no reaction) r...@h:/# # swap for blue stick r...@h:/# davinci_interrupt 362: IRQ 0020 musb_interrupt 1505: ** IRQ peripheral usb0020 tx rx musb_stage0_irq 380: == Power=e0, DevCtl=88, int_usb=0x20 musb_stage0_irq 696: DISCONNECT (b_peripheral) as Peripheral, devctl 88 musb_g_disconnect 1957: devctl 88 nuke 189: ep1out: abort DMA -- 0 musb_gadget_disable 1038: ep1out nuke 189: ep1in: abort DMA -- 0 musb_gadget_disable 1038: ep1in nuke 189: ep2in: abort DMA -- 0 musb_gadget_disable 1038: ep2in otg_timer 216: poll devctl 88 (b_idle) davinci_interrupt 362: IRQ 0100 davinci_interrupt 423: VBUS on (a_wait_vrise), devctl 19 davinci_interrupt 362: IRQ 0010 musb_interrupt 1505: ** IRQ host usb0010 tx rx musb_stage0_irq 380: == Power=e0, DevCtl=5d, int_usb=0x10 musb_stage0_irq 689: CONNECT (a_host) devctl 5d Log for stick - gadget --- r...@h:/# # remove memory stick r...@h:/# davinci_interrupt 362: IRQ 0020 musb_interrupt 1505: ** IRQ peripheral usb0020 tx rx musb_stage0_irq 380: == Power=e0, DevCtl=19, int_usb=0x20 musb_stage0_irq 696: DISCONNECT (a_host) as Host, devctl 19 musb_platform_try_idle 328: a_wait_bcon inactive, for idle timer for 1100 ms musb_hub_control 356: port status 00010100 musb_hub_control 290: clear feature 16 usb 1-1: USB disconnect, address 2 musb_hub_control 356: port status 0100
The state of MUSB OTG + CPPI DMA..?
Hi all, I'm playing around trying to get MUSB OTG working on DM355, for mass storage (memory sticks) and gadget serial. We had similar functionality in MV 2.6.10 via some hacks involving a GPIO to monitor USB_ID, and a script to reload USB driver modules.. but it would be nice to do it Right(tm) or at least Better. OTG sort-of works for me after playing with it today, but having some problems with it not finding memory sticks in host mode after connecting as a gadget, and a few weird error messages. Would anyone like to comment on the status of MUSB OTG (for DM355) in the current git version? And/or on the TI CPPI DMA option? I note that OTG depends on EXPERIMENTAL and the CPPI driver has a lot of discouraging comments and REVISITs throughout it. Thought it was worth posting in case someone wanted to say OTG and CPPI are both (buggy|slow) for DaVinci, don't try and use them, that would save me some time and frustration and I can reimplement the old hacks. Thanks, -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
MUSB Kconfig bugs?
I am seeing some weirdness trying to configure MUSB for Gadget mode; I deleted all USB lines from .config and ran make oldconfig hoping to be prompted for things. Perhaps that approach is wrong? Such odd things happened as getting the peripheral controller automatically selected, and not having an option for the Inventra controller; a snippet from make oldconfig which automatically selected 1: USB Peripheral Controller 1. Renesas R8A66597 USB Peripheral Controller (USB_GADGET_R8A66597) (NEW) 2. Renesas M66592 USB Peripheral Controller (USB_GADGET_M66592) (NEW) choice[1-2?]: 1 I had to make two passes and do a few hand-edits to sort things out. Things worked fine once I did. One thing that jumps out at me is that there are config USB_GADGET_MUSB_HDRC lines in both usb/gadget/Kconfig and usb/musb/Kconfig, ie the same variable in two places. I'm not a Kconfig expert but that seems wrong. The dependencies seem a bit mixed up and maybe a little circular, I don't know how kconfig resolves such things but USB_MUSB_PERIPHERAL in musb/Kconfig depends on USB_GADGET which doesn't appear until gadget/Kconfig which is sourced later. I am not quite sure what is wrong or how to fix it, but thought it was worth bringing up. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Inspiration needed to track down early kernel startup crash
Jon Povey wrote: Trying to get the git kernel running on our in-house board and have an unpleasant crash somewhere between kernel start and console output, with code jumping off to 0x000c. In case my experience is useful to anyone else, it seems this is what was happening: - RBL was enabling Timer0 and its FIQ - perhaps to flash an LED warning that I have no valid UBL on my NAND - My JTAG connector lacks SRST so the board was not getting fully reset - u-boot was loaded and run over JTAG (ignoring Timer0 + FIQ?) - Linux starts, enables FIQ in boot_cpu_init() and crashes because it has not setup the interrupt vector tables yet. I added a software disable and clear of interrupts over JTAG to my reset handler, and now I can boot. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Inspiration needed to track down early kernel startup crash
Trying to get the git kernel running on our in-house board and have an unpleasant crash somewhere between kernel start and console output, with code jumping off to 0x000c. This is using u-boot v2010.03 and kernel based on davinci master at 5954dd1d2cab4b378e22256edbfe132bf4f82f22 Sympoms are; this is the last output I get on the console: Starting kernel ... Uncompressing Linux... done, booting the kernel. If I now halt the CPU over JTAG it tells me: target halted in ARM state due to debug-request, current mode: Abort cpsr: 0x20d7 pc: 0x000c MMU: enabled, D-Cache: enabled, I-Cache: enabled I tried both the vanilla EVM versions of bootloader and kernel, and in-house modified (for different pinmuxing, board file etc). Both combinations boot OK on the DM355EVM, both crash in the same way on our in-house board. This in-house board and many like it were previously running a MontaVista (DM355 Beta SDK) based setup, so is capable of running linux and the board design should be sound. There is no UBL on the board at present: I am doing initial setup and loading u-boot over JTAG with OpenOCD. I stepped through the code enough to determine that the uncompress, relocate and jump to kernel (and several instructions after) seems OK. I am looking into the ARM ETM/ETB + OpenOCD hoping that could give me a trace of how I end up at 0x000c but not having any joy with that so far. Inspiration for approaches to debugging this problem would be much appreciated, running low on ideas. Thanks, -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: davinci linux kernel updata
liuyue18301 wrote: if i want to updata the davinci linux kernel to the higher.what should i do,i think the gcc version has to update.now,i have download the kernle version:2.6.32 and gcc 4.3.3,what i do is just update the gcc and linux kernel in the SEED-SDK.the flow is ok? I don't know what the SEED-SDK is. For the git kernel I have been using the CodeSourcery toolchain: http://www.codesourcery.com/sgpp/lite/arm/portal/release858 As recommended here: http://processors.wiki.ti.com/index.php?title=DaVinci_GIT_Linux_Kernel#Overview Hope this helps. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v3] USB: musb: suppress warning about unused flags
Wrap flags with uninitialized_var() to suppress this: drivers/usb/musb/cppi_dma.c:1158: warning: 'flags' may be used uninitialized in this function Signed-off-by: Jon Povey jon.po...@racelogic.co.uk --- Revised after feedback from davinci mailing list, and signoff added. drivers/usb/musb/cppi_dma.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/musb/cppi_dma.c b/drivers/usb/musb/cppi_dma.c index 59dc3d3..e3753ba 100644 --- a/drivers/usb/musb/cppi_dma.c +++ b/drivers/usb/musb/cppi_dma.c @@ -1155,7 +1155,7 @@ irqreturn_t cppi_interrupt(int irq, void *dev_id) struct musb_hw_ep *hw_ep = NULL; u32 rx, tx; int i, index; - unsigned long flags; + unsigned long uninitialized_var(flags); cppi = container_of(musb-dma_controller, struct cppi, controller); if (cppi-irq) -- 1.6.3.3 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] USB: musb: silence warning about unused flags
My first attempt at a kernel patch. Mostly I am interested in feedback about if my patch posting style is right, if this is the right way to deal with this kind of warning, and if this kind of tiny patch is welcomed. --- drivers/usb/musb/cppi_dma.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/musb/cppi_dma.c b/drivers/usb/musb/cppi_dma.c index 59dc3d3..428ca1b 100644 --- a/drivers/usb/musb/cppi_dma.c +++ b/drivers/usb/musb/cppi_dma.c @@ -1155,7 +1155,7 @@ irqreturn_t cppi_interrupt(int irq, void *dev_id) struct musb_hw_ep *hw_ep = NULL; u32 rx, tx; int i, index; - unsigned long flags; + unsigned long flags = 0; cppi = container_of(musb-dma_controller, struct cppi, controller); if (cppi-irq) -- 1.6.3.3 Thanks, -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v2] USB: musb: suppress warning about unused flags
Wrap flags with uninitialized_var() to suppress unhelpful warning. --- Patch take 2.. Fixes this warning: CC drivers/usb/musb/cppi_dma.o drivers/usb/musb/cppi_dma.c: In function 'cppi_interrupt': drivers/usb/musb/cppi_dma.c:1158: warning: 'flags' may be used uninitialized in this function Feedback welcome again.. Also I'm not subscribed to linux-usb, is it appropriate to cross-post there without being subscribed? And is it OK to ramble away in this part of the patch mail? Thanks.. drivers/usb/musb/cppi_dma.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/musb/cppi_dma.c b/drivers/usb/musb/cppi_dma.c index 59dc3d3..e3753ba 100644 --- a/drivers/usb/musb/cppi_dma.c +++ b/drivers/usb/musb/cppi_dma.c @@ -1155,7 +1155,7 @@ irqreturn_t cppi_interrupt(int irq, void *dev_id) struct musb_hw_ep *hw_ep = NULL; u32 rx, tx; int i, index; - unsigned long flags; + unsigned long uninitialized_var(flags); cppi = container_of(musb-dma_controller, struct cppi, controller); if (cppi-irq) -- 1.6.3.3 -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v2] USB: musb: suppress warning about unused flags
Sergei Shtylyov wrote: The warning should probably have been cited before the --- tearline. OK. [disclaimer] What's not OK is this text. However, you probably don't have control over its appearance in your mails? Nope :( Thanks for the feedback. I suppose I'll wait a while for any more comments then repost to both lists. Lots of drama for a one-line patch, but.. Have to learn somehow. :) -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: UBL Question
Raffaele Recalcati wrote: I'm defining the situation for ubl+u-boot programming. First of all I haven't yet found a git tree of ubl. This is not so nice, because I'd like that ubl project could become better day by day. From http://processors.wiki.ti.com/index.php/SD_card_boot_and_flashing_tool_for_DM355_and_DM365 I can't find a project on ubl. Any suggestion? This would be of great interest to me, too. I need to look into this soon. There are some pointers to UBL versions here: http://processors.wiki.ti.com/index.php/RBL_UBL_and_host_program But I am not aware of any active community UBL. I would be interested in contributing to one. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: UBL Question
Brian G Rhodes wrote: Those commands work for me from Linux to produce a working system. I can't say it's entirely reliable reading and writing without ECC though. You may want to spend the time to add a routine in the Linux davinci NAND driver to write those blocks using rbl's ECC layout and save yourself some potential headaches. Some thoughts: John, I recommend using JTAG to see what is going on inside your NAND chip - lets you read/write/erase blocks with or without OOB and works even when the board won't boot because of bad NAND contents. I use OpenOCD, which includes configs for some davinci EVMs and NAND flash layouts, with an Amontec JTAGKey-Tiny - total cost around 30 euro. Also good for bootloader debug etc. What DaVinci device are you using? The DM355 RBL ignores ECC completely (see silicon errata document) but uses this wacky OOB layout on large page size NAND. I am in the position of trying to work out a firmware upgrade path such that git kernel Linux (with correct OOB layout) can rewrite UBL (in DM355 RBL infix layout format). The UBL shouldn't need valid ECC on DM355, but if I need it for other things I plan to use a software utility to calculate ECC and format the OOB data, then use the raw+oob write mode of mtd - I think I remember it can do that.. Will find out soon (!). I am hoping to derive the software ECC calculation util from the GenECC tool described here: http://processors.wiki.ti.com/index.php/NAND_ECC_Generation_for_DaVinci_Family_of_Devices HTH, -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: UBL Question
Hi Andreas, Gaer, A. wrote: Currently I'm investigating two options: - Change the ECC layout in the davinci_nand.c driver of kernel/u-boot = I'm not sure if this works together with JFFS2 or UBI as they also have their opinions about OOB layout - Writing a special tool that does its own OOB data handling I notice we both seem to be working in the same area. Perhaps we can share notes, I would be happy to. Either on or off-list. You may have seen some of my mails on the list; I am working with DM355, 2KB page NAND, OpenOCD JTAG and am working on migrating from our in-production product based on the beta SDK with legacy OOB layout, to current git kernel and U-Boot. I plan to go the route of special tool that does its own OOB handling, partly because I may need something like that to do field upgrades from one to the other (particularly to translate the BBT and rewrite the u-boot environment). -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: can't detect video input
Chris wrote: I want to revert to the default bootargs that ship with the board, but I can't find that info anywhere, and I've written over the NAND with new bootargs for the NFS mount. Does anybody know what the default bootarg string is? With DM355 EVM, I think that info was printed in the getting started or technical reference dead tree guides that came with the EVM. Not sure about 6446. Hope that helps or someone else answers.. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Possible uboot crashes
John Tobias wrote: Since, the ubl default block in DVFlasher is block 1, I modified the DVFlasher to write the ubl data onto block 5 . By doing this, I can dump the contents of the failing block since the DVFlasher won't erase it. After making sure that the ubl would be written on block 5, I re-program my device. Then, I modified my kernel to expose the ubl block1 - block5 in linux userspace and from there, I dumped the information of my failing ubl block and compare it to the working copy. You can also read/write NAND flash through JTAG. This is very useful when you have bricked your NAND. I have used a Ronetix PEEDI flash programmer a lot, it has a telnet interface and can read/write/erase things with or without OOB. I am now just setting up to use OpenOCD which now has Davinci NAND support. Also good for debugging bootloaders, etc. And dirt cheap interface hardware is available. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Can't Mount NFS from DVEVM 6446
Chris wrote: Hello all, I am having trouble mounting to the NFS server on my host Linux machine. My configuration is as follows. You might need a leading slash on your env rootpath. Also check sudo exportfs on the ubuntu host. You need to do exportfs -ra after changing /etc/exports, not sure if restarting the NFS server helps. I am not sure if error -13 means it has contacted the server OK or not. If that fails, can you test basic networking from u-boot (ping, maybe dhcp)? After that look for NFS traffic with tcpdump on the host machine. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Layout of OOB data in NAND flash
Gaer, A. wrote: Hi! It seems like the layout of OOB/4-Bit-ECC data in NAND flash differs from RBL/UBL to u-boot/linux (at least on a DM365 device). Is there any good reason for this? Hi, just to say I am working in similar areas (trying to understand what the hell TI are doing with their NAND ECC layouts), on DM355 so far but may start looking at DM365 before long. So I am interested in whatever progress you make. The DM355 silicon errata admits that the DM355 RBL doesn't actually check 4-bit ECC at all. But the layout used by UBL, u-boot and linux is all messed up. There is some stuff about DM365 RBL ECC handling in the DM365 silicon errata too, not the same thing, but maybe of interest. As far as I understand, the RBL/UBL uses this layout (2048 byte pages): What is your understanding based on? What wrote that format? Are you reading that from flash or working it out by inspecting code? The different layout means that it is impossible to update UBL/u-boot from u-boot or linux. Have you tried? On DM355 at least, it seems this would actually work. Another question: 512 byte pages in linux seem to have a really funny oob layout EXEE XEEE Does anybody know the reason for that? (I know the 6th byte is the manufacturer bad-block marker. But why not just put the ECC data into the last 10 byte of oob like RBL/UBL do it?) Good luck getting good answers to these questions. This might be worth some wiki documenting when it becomes clearer. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
DM355 JTAG reset without SRST?
Hi all, Trying to setup OpenOCD for use on DM355 using an Amontec JTAGKey-Tiny and the TI 14-pin JTAG header - which doesn't have SRST. I need to write a routine for OpenOCD that writes some registers or whatever through JTAG to do a full reset of the DM355. Not done this kind of reset stuff before, I'm looking at the watchdog timer at the moment, but any suggestions? Thanks, -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
DM355 RBL updates for ECC layout?
Can anyone point me at more information about a DM355 RBL change to NAND ECC layout handling? This email from David Brownell on the u-boot mailing list http://www.mail-archive.com/u-b...@lists.denx.de/msg21042.html mentions a discussion here and hints at an RBL change, but I can't see anything obvious in the archives. As far as I know DM355 RBL can only handle infix ECC layout on 2KB page NAND, i.e. clobbering manufacturer bad block markers. Just want to check that: - DM355 RBL can't handle the new/correct layout (ECC together at end of page) - We're not going to buy another batch of DM355s and suddenly find a new RBL which expects a different ECC layout. If so I better start planning now.. Thanks, -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v2] DA8XX/OMAP-L1XX: FB: Implement double buffering
Andrew Morton wrote: On Wed, 31 Mar 2010 20:43:29 -0500 Ambrose, Martin mar...@ti.com wrote: If the calling process has signal_pending() (say, someone hit ^C) then wait_event_interruptible_timeout() will fall straight through with -ERESTARTSYS. Will this cause the driver to malfunction at all? I don't think so since the driver doesn't make use of this information in any way. This is just status to the caller that the current frame has finished DMA'ing out of the framebuffer. Could you maybe propose a scenario/use case where you think it is problematic? I could then either reason why it should be OK or I'll create a test harness and see how the driver can/should be modified. Gee, I dunno - I don't understand the driver to that level. If you're OK with this wait being interrupted by a signal and the driver handles it OK then fine, that's a feature. To test it I suppose you should give your test app a signal handler and blast kills at it from another process. Jumping in.. This should not cause a problem for the driver; its purpose is to tell userland that it can write to the buffer without corrupting graphics (as presumably it is double-buffering and the other buffer is now being DMA'd from by the hardware). At worst, if the userland software doesn't handle this correctly it may draw one bad frame of graphics. Although if it's had a ctrl-C it probably has bigger things to worry about. If the app wants to handle signals it needs to consider such things.. I would not expect the driver to do anything other than what this patch does. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
dma_alloc_coherent and cache fun
Hi folks, We are using an OSD framebuffer allocated with dma_alloc_coherent(), mmap()ing it to userspace and doing stuff like software alpha blending. The buffer is double-sized and we do pan() stuff to implement double-buffering. The userspace app is taking a lot of cpu (in userspace, not system) which I suspect may be to do with lots of small reads and writes to this uncached memory. I'd like to have write-back caching on for this buffer and explicitly flush it in the swap-buffer routine. Are there some functions I can call on the buffer I got from dma_alloc_coherent to turn cache back on and do this? Or should I be allocating the buffer some other way? Thanks, -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: NAND ECC and filesystem with git DM355 - JFFS2, UBIFS, YAFFS2?
On Wednesday 17 March 2010 11:07:19 am Andrea Gasparini wrote: Hi Jon, what's up? :) Hey Andrea, same old same old :) the git kernel on DM355 NAND - YAFFS2? JFFS2? UBIFS (which I don't Having looked a little at this it seems UBIFS is promoted nowadays. I will try that instead of YAFFS2. Anyone using it already? My latest story is about 2.6.18, I found that I should disable CONFIG_DAVINCI_NAND_STD_LAYOUT in order to have a working NAND, although Linux made a ironiclittle of/ironic confusion reading the bbt table. My solution was to purge the BBT table from u-boot, recompile 2.6.18 kernel without NAND_STD_LAYOUT, and rewrite all stuff into the NAND (uboot,kernel,rootfs). I don't know if git kernel has the same problems, but this is just how we rescued our board. OK, thanks for the clues. If we have to do a watershed-upgrade of everything to latest versions then we can do that. Çaglar AKYÜZ wrote: My experience was latest u-boot was consistent with latest kernels but ubl(and rbl) was using a different layout thus no ubl updates from kernel or u-boot which is not good. No that is not good.. We would really like to be able to write the ubl from linux. I wonder if we can write raw and calculate the ECC ourselves in software for the RBL a.k.a. wrong style. If u-boot was incompatible with ubl, did you use u-boot to write itself? I am wondering how ubl read u-boot if u-boot was written with different layout. When transiting from an older u-boot(or kernel) to a newer one nand bbt should be erased or new u-boot will mark all pages bad. Did you find it was just the bbt format that had changed, or the ECC layout inside each page? bye! ( happy to know that NAND with git will continue to be a pain ) A little, not that much. I hope not too much.. Thanks, -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
NAND ECC and filesystem with git DM355 - JFFS2, UBIFS, YAFFS2?
Hi folks, Trying to move from TI beta SDK MV kernel + u-boot, to git on DM355. I find I am reopening the can of worms that is NAND ECC and filesystem choice. We have been using YAFFS2, but I seem to remember some incompatibilities between UBL, u-boot and Linux's ideas of how the ECC should work. I vaugely recall some things (u-boot?) ignoring ECC errors on write, or somesuch. Also the ECC layout was not as specified by the chip manufacturer (512 byte chunks of data followed by ECC instead of 2K + ECC) Having booted a new kernel and apparently messed up my NAND flash somehow (lots of bad blocks, clobbered BBTs; investigating), I am looking for any clues about what might have changed in terms of NAND/ECC handling, and also what filesystem people are using with the git kernel on DM355 NAND - YAFFS2? JFFS2? UBIFS (which I don't know much about)? I had a look on the wiki but didn't turn up much. Hints or war stories appreciated, thanks. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Custom pinmuxing on DM355 with git kernel
Nori, Sekhar wrote: On Mon, Mar 15, 2010 at 07:47:44, Jon Povey wrote: - Board init would setup pinmuxing resource structures that could be passed to drivers, something like gpio, but supporting the different DaVinci devices (insert handwaving here) - Device driver can callback to request / release its mux resources - mux layer can print/warn/bug for debug if claimed resources conflict Aplogies if this is all very wrongheaded. I am still getting to grips with the provided APIs, attempting to specify a new one is a stretch. As far as possible, the interfaces to device drivers should not be SoC specific ones, but should be portable across platforms and architectures. So, what you are proposing needs to be an interface defined in include/linux/* and cannot be DaVinci specific. The problem is there is no cross-platform framework for handling pin as a resource defined yet. Currently, every platform that runs into this solves it in its own way. Have a look at this post from the thread I posted earlier.. http://www.mail-archive.com/davinci-linux-open-sou...@linux.davincidsp.c om/msg11301.html .. and the response from Dave Brownell to that. http://www.mail-archive.com/davinci-linux-open-sou...@linux.davincidsp.c om/msg11303.html Thanks for those useful archive links. How about a generic interface which included claim/free resource methods, like for gpio, but taking a pointer to a mux resource struct instead of a gpio number. The mux resource struct would include function pointers to mach- or soc- specific functions to do the work of checking, setting and freeing the mux resources. The mux resource struct would also contain a list of mach- or soc- specific resource data required by that device (pointers into an array of mux resource structs or whatever?) The mux resources would be setup and passed by the board init to the driver. The driver could claim and release them using the platform-independent functions. The platform-independent functions could just be wrappers calling the mach-specific functions, or do more elaborate generic things (sysfs stuff, printing/handling conflicts) I appreciate this is fairly simpleminded and doesn't handle, for example, large peripherals that you may not want to mux all of the pins for (I'm thinking DM355 VPFE, we reuse the sync pins for example). Obviously I am handwaving all implementation details. Just trying to get a grip on the theory and appreciate all experienced criticism. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: davinci git updated to v2.6.34-rc1
Nori, Sekhar wrote: On Mon, Mar 15, 2010 at 07:54:57, Jon Povey wrote: I did a bit of wiki-work this morning, improvements encouraged to http://wiki.davincidsp.com/index.php/Linux_Toolchain#Linux_Kernel Hmm, did not realize this is documented here so far. Thanks! The details look pretty complete to me. What would you would like to see added there? I just meant, I wrote it up to the best of my ability, but TI folks / Kevin / others may have a better idea of the differences between the available kernels. If my understanding is good, great! Information on submitting patches upstream is documented here: http://wiki.davincidsp.com/index.php/Patch_upstream_sending Ah, I wasn't aware of that page. There seem to be a lot of hidden gems (and hidden crusy old junk) hiding in the wiki. Note that this is a public wiki, so modifications can be made by anyone in the community (not just TI folks). Yup.. I just linked the upstream patches page from that kernels section :) -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Custom pinmuxing on DM355 with git kernel
Kevin Hilman wrote: Nori, Sekhar nsek...@ti.com writes: I don't think having drivers handle pinmux directly is acceptable at all. Correct. Drivers should not do muxing. This should be done by SoC or board init code. If your bootloader is doing it, that suggests that it is init-time only, and should be done in init code. I still think splitting davinci_cfg_reg() they way you describe may have some merit in terms of code organization, but I fail to see where it will be useful (at least in the current kernel). I'm all for cleaning up the mux code, but I'm with Sekhar and don't currently understand the use case you're proposing. My thoughts are a bit wooly, but Mike Williamson seems to be thinking similar thoughts: Mike Williamson wrote: Having a pile of custom machines (kernel configurations) for every permutation seems painful if all they are doing is enabling different devices. I sort of thought the point of modular kernel drivers was to provide pluggable support for dynamic device control. I appreciate that someone needs to keep track of the resources, but couldn't there be some sort of allocation mechanism to allow drivers to test and see if they can have a set of resources before using them, much like the gpiolib? I am not sure I actually need it for what I'm doing right now, but having a supported way to change pinmuxing outside of board init seems like a good thing for boards where the wiring can support it. I can imagine designs that might. Also like the gpiolib something seems not quite right in the way pinmuxing is done now; you need to remember to set it up right in your board init code otherwise things will fail to work in confusing ways. I can imagine how it might work, but this would perhaps be epic overkill: - Board init would setup pinmuxing resource structures that could be passed to drivers, something like gpio, but supporting the different DaVinci devices (insert handwaving here) - Device driver can callback to request / release its mux resources - mux layer can print/warn/bug for debug if claimed resources conflict Aplogies if this is all very wrongheaded. I am still getting to grips with the provided APIs, attempting to specify a new one is a stretch. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: libmpeg4.a math.h dependency.
Deepak Shankar-ERS,HCLTech. wrote: I tried to update the png library to the v1.4(latest from libpng). However after updating this when I tried to rebuild the dvsdk the libmpeg4enc.a is not linking. I did a diff and found that the math.h related operations are removed from the latest pnglibrary(which Im not able to reason out - separately). Now since the code libraries are dependent on the math.h why is it include through the libpng shared object instead of directly from libmpeg4.a Is there a way the libmpeg4.a could be locally rebuilt? ** /opt/mv_pro_4.0.1/montavista/pro/devkit/arm/v5t_le/bin/../target/usr/lib /libpng. so: undefined reference to `pow' ** Rest of dump: ** /home/avalon/dvsdk_1_30_00_40/dm355_codecs_1_13_000/packages/ti/sdo/code cs/mpeg4 enc/dm355/lib/libmp4enc.a(mp4venc_rate_cnt.o)(.text+0x30): In function `MP4VENC_ TI_DM350_calc_d0': mp4venc_rate_cnt.c: undefined reference to `floor' Looks like you need to link against the math library libm, is -lm in your CFLAGS? If that doesn't help please paste the compiler command line which is failing (you may need to turn on verbose output with a switch, maybe V=1) -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
