Re: [PATCH v5 04/12] spi: add ti-ssp spi master driver
On Tue, 2010-11-16 at 00:22 -0700, Grant Likely wrote: After discussions about device init dependencies at plumbers, and since this is the first SPI device driver I've reviewed since that dicussion, this driver gets to be the first to implement the proposed policy. :-) Change this to module_initcall(). Many spi and i2c drivers use module or subsys_initcall to try and influence driver probe order so that certain regulator chips get registered before the devices that try to use them. This approach is insane. Last I observed the issue ... the situation was that various core drivers were required to be able to say that a key subsystem was functional ... with said subsystem required to boot properly. The dependency being, that is, driver on subsystem (but that subsystem needed a core/bus driver running before it could work. What's insane is that Linux *STILL* has no clean way to express that type of system dependency ... where driver dependencies are pure side effects. (Albeit ones that never change on many platforms, but where board-specific differences are routine, and have the same kind of indirect dependencies. - Dave ___ 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 v5 04/12] spi: add ti-ssp spi master driver
On Tue, Nov 16, 2010 at 07:17:18PM -0500, Cyril Chemparathy wrote: The ability to wait on multiple devices may come handy. ... You mean you'd like to add such a mechanism to the framework? Or do you want a driver-specific mechanism (non-portable)? If I had to do that, I'd just use existing kernel mechanisms to wait, and then issue SPI transactions as needed. Portable, straightforward. ___ 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 08/12] gpio: add ti-ssp gpio driver
I thought the point of this device was that a single [SSP] device hosted a pair of multi-function serial interfaces, with each implementing a separate function. function chosen based on what the board needs. Codec interface, SPI, GPIO, etc. If so, then it makes sense for the base driver to register child devices of the appropriate kinds. I'd normally say board setup registers them; a coredriver can't know what children would be needed. But the point I was making was about code factoring not driver setup. When the functions don't have much commonality, they might as well just write to the relevant registers instead of expecting to have a non-register programming interface (of dubious generality of a core driver, but much complexity). Easier just to have children use registers directly, in several similar cases. Less overhead, too. - Dave ___ 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 08/12] gpio: add ti-ssp gpio driver
--- On Wed, 11/3/10, Linus Walleij linus.ml.wall...@gmail.com wrote: \ Date: Wednesday, November 3, 2010, 3:18 AM 2010/11/3 David Brownell davi...@pacbell.net: That seems like a better structure for various vendors' SSP hardware (multifunction serial interface logic) Incidentally the ARM PrimeCell PL022 is called SSP, Synchronous Serial Port and is not multifunction at all. ISTR coming across that IP module; are you sure that it only supports a single serial protocol, instead of just a small variety (multi)? Unless the hardware only supports one protocol, my point holds. I wasn't implying that modules named SSP have more in common than tending to support more than a single serial protocol. If they only support one, they get names likeUSART or sometimes CODEC. - Dave ___ 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 08/12] gpio: add ti-ssp gpio driver
--- On Tue, 10/26/10, Cyril Chemparathy cy...@ti.com wrote: From: Cyril Chemparathy cy...@ti.com Subject: [PATCH v4 08/12] gpio: add ti-ssp gpio driver On the assumptions you've tested this *AND* will resubmit with the previously-requested change of removing all references to non-existent virtualness in the driver ... I'll likely add my ack to that resubmitted version Also, chip2gpio seems an excessively generic name; maybe chip2_ti_ssp_gpio or somesuch? I'd still be happier seeing this stack packaged as a hardware library called by various drivers (like GPIO, SPI, etc) rather than a core driver that's called by other drivers. That seems like a better structure for various vendors' SSP hardware (multifunction serial interface logic) since most function drivers just need to poke the registers a bit differently, and don't have much to share with a core driver beyond a few setup routines (if that). - Dave ___ 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 08/12] gpio: add ti-ssp virtual gpio driver
On Mon, 2010-10-18 at 15:25 -0400, Cyril Chemparathy wrote:
This patch adds a GPIO driver based on TI's SSP device. This driver does not
support GPIO-IRQs.
Doesn't look particularly evil, except I don't much like the notion of
needing a stack if it's not being used like an MFD where numerous
functions are accessed concurrently, better IMO to just have each
function's driver bind exclusively to the chip (and drive it in the
mode it supports -- SPI, GPIO etc).
Also, the patch description is weak/confusing. First, there's not a
thing virtual about this. Second, just say that this GPIO driver is
bypassing pretty much everything in the SSP module (notably, all the
silicon support for serial protocols) and just driving some of the
pins as GPIOs. (Right?)
Signed-off-by: Cyril Chemparathy cy...@ti.com
---
arch/arm/mach-davinci/include/mach/ti_ssp.h |4 +
drivers/gpio/Kconfig| 10 ++
drivers/gpio/Makefile |1 +
drivers/gpio/ti-ssp-gpio.c | 200
+++
4 files changed, 215 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpio/ti-ssp-gpio.c
diff --git a/arch/arm/mach-davinci/include/mach/ti_ssp.h
b/arch/arm/mach-davinci/include/mach/ti_ssp.h
index 63c88fe..21f1429 100644
--- a/arch/arm/mach-davinci/include/mach/ti_ssp.h
+++ b/arch/arm/mach-davinci/include/mach/ti_ssp.h
@@ -39,6 +39,10 @@ struct ti_ssp_spi_data {
void(*select)(int cs);
};
+struct ti_ssp_gpio_data {
+ int start;
+};
+
/*
* Sequencer port IO pin configuration bits. These do not correlate 1-1 with
* the hardware. The iosel field in the port data combines iosel1 and
iosel2,
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 510aa20..e400761 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -111,6 +111,16 @@ config GPIO_SCH
This driver can also be built as a module. If so, the module
will be called sch-gpio.
+config GPIO_TI_SSP
+ tristate TI SSP Controller GPIO Driver
+ depends on GPIOLIB TI_SSP
+ help
+ Say yes here to support a virtual GPIO interface on TI SSP ports.
+ Each SSP port translates into 4 GPIOs, with no IRQ support.
Don't emphasize the no IRQ part so much; lots of GPIOs don't do IRQs.
If a board uses SSP this way, it won't care; Kconfig users have no
control over such board wiring issues.
+
+ This driver can also be built as a module. If so, the module
+ will be called ti-ssp-gpio.
+
comment I2C GPIO expanders:
config GPIO_MAX7300
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index fc6019d..98b4551 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_GPIO_PL061)+= pl061.o
obj-$(CONFIG_GPIO_STMPE) += stmpe-gpio.o
obj-$(CONFIG_GPIO_TC35892) += tc35892-gpio.o
obj-$(CONFIG_GPIO_TIMBERDALE)+= timbgpio.o
+obj-$(CONFIG_GPIO_TI_SSP)+= ti-ssp-gpio.o
obj-$(CONFIG_GPIO_TWL4030) += twl4030-gpio.o
obj-$(CONFIG_GPIO_UCB1400) += ucb1400_gpio.o
obj-$(CONFIG_GPIO_XILINX)+= xilinx_gpio.o
diff --git a/drivers/gpio/ti-ssp-gpio.c b/drivers/gpio/ti-ssp-gpio.c
new file mode 100644
index 000..c046713
--- /dev/null
+++ b/drivers/gpio/ti-ssp-gpio.c
@@ -0,0 +1,200 @@
+/*
+ * Sequencer Serial Port (SSP) based virtual GPIO driver
+ *
+ * Copyright (C) 2010 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/init.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/io.h
+#include linux/err.h
+#include linux/slab.h
+#include linux/gpio.h
+#include linux/platform_device.h
+
+#include mach/ti_ssp.h
+
+struct ti_ssp_gpio {
+ struct gpio_chipchip;
+#define chip2gpio(chip) container_of(chip, struct ti_ssp_gpio, chip)
+ struct device *dev;
+ spinlock_t lock;
+ u8 out;
+ u32 iosel;
+};
+
+static int direction_in(struct gpio_chip *chip, unsigned gpio_num)
+{
+ struct ti_ssp_gpio *gpio = chip2gpio(chip);
+ int error = 0;
+
+ spin_lock(gpio-lock);
+
+
Re: C implementation of DaVinci 4-bit NAND ECC?
I think it's been implemented as a part of the OpenOCD project. Not unless someone snuck in a LOT of code when I wasn't looking. The original DaVinci NAND support used the hardware ECC logic for 1-bit and 4-bit ECC. - Dave ___ 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] m25p80: add support for a callback to platform code on successful device probe
On Tue, Aug 10, 2010 at 12:47:05, Mike Frysinger wrote: it is necessary that you do these things from kernel space instead of standard userspace. Hard to get userspace to do this stuff if you're doing a network boot, and thus need to have the MAC address working early.. it's easy if the kernel can get the MAC address, else not possible to boot. Right? ___ 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
--- On Wed, 6/2/10, Jon Povey jon.po...@racelogic.co.uk wrote: From: Jon Povey jon.po...@racelogic.co.uk Subject: MUSB: Idea: board-specific OTG ID pin interrupt support To: linux-...@vger.kernel.org linux-...@vger.kernel.org, davinci-linux-open-source@linux.davincidsp.com davinci-linux-open-source@linux.davincidsp.com Cc: felipe.ba...@nokia.com felipe.ba...@nokia.com, Sergei Shtylyov sshtyl...@mvista.com Date: Wednesday, June 2, 2010, 5:52 PM Playing around with MUSB OTG on TI DM355 I am having some trouble getting A-B role switching working. On my board by happy design foresight, USB ID is also wired to a GPIO. I am currently having a go at hacking an ID interrupt into the MUSB driver to prod the state machine. I don't recall having difficulties getting the ID-based role switching to behave with the DM355 EVM... GPIO IRQs should not be needed. Of course, maybe my memory has faded; this is the type of situation where Mentor's silicon design team gratuitiously disregarded OTG specs. In fact ISTR some chicken/egg issues specifically regarding the ID pin status bit in whichever register held it... making host vs perhipheral initialization a real PITA. Maybe ULPI hooks would help. Regardless, I did see the cable based role switch logic working without such gpio logic. - Dave ___ 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] rtc: omap: let device wakeup capability be configured from chip init logic
--- On Wed, 6/16/10, Nori, Sekhar nsek...@ti.com wrote: rtc-li...@googlegroups.com Date: Wednesday, June 16, 2010, 9:46 PM Hi Dave, Any thoughts on my responses below? If you are satisfied, would you please Ack my patch? I don't have time to properly review it. If it works, go for it ... bugs can be fixed later, and the principle behind the patch is fine. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: yaffs
i have enable yaffs support in the kernl it gives following error when i mount using yaffs2 Try asking YAFFS questions on a YAFFS mailing list; that's not standard Linux stuff. And for that matter, UBI and UBIFS are still the preferred approaches for NAND in Linux ... with the MTD lists ready to help, since that tech is standard in mainline. - Dave ___ 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 ?
In answer to the question in $SUBJECT: the whole pinmux configuration, yes. But Quite a lot of it can also be derived from driver configuration. (Which is board-coupled.) So (a partly made up example) if a given SPI bus is configured, with two chipselect lines active ... that rules out PINMUX configs here the MOSI/MISO/SCK lines for that SPI bus are not muxed out, or where those chipselects are unavailable. (Unless the chipselects are done using GPIOs, which is a driver/device config... the board-specific code in the second-stage (post-RBL) boot loader sets up PINMUX, as I recall, but Linux could do that based on the devices configured (as sketched above), or even just sanity check what it's given by that second stage loader. ___ 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 11/14] regulator: add support for Dallas DS1803 dual digital potentiometer
A digital pot is not a regulator, and it'd be better to expose a potentiometer interface (even a chip-specific one) than require all such chips to be used in regulator configs. (The first board I saw with a digital pot used it for LCD control ... another used one in a feedback loop. ___ 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
There is a standard request you can make to any USB hub to power down a given port. Most root hubs don't support that request though, and many external hubs don't either. so it's best to train yourself to not even want to power down a port. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: usb 1-1: device descriptor read/64, error -110
kernel: musb_h_ep0_irq 1067: no URB for end 0 kernel: usb 1-1: device descriptor read/64, error -110 Some devices are flakey about device descriptor reads. Note -110 is -ETIMEDOUT. The code in usbcore to read descriptors has all sorts of logic to handle flakey descriptor reporting from USB peripherals, and the first place such things show up is usually device descriptors. Root causes are normally peripheral bugs, but it's also possible the MUSB code might need tweaking. I see some comments in musb/musb_host.c for ‘no URB for end 0’, saying this should never happen. where should is the operative word ... not can. Butit's clearly happening to you ... My question is how to fix this error. No suggestions, sorry; but you have TWO errors, soI'd debug them one at a time. - Dave ___ 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
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). t things are as intended, with confusing side effects. Namely, gpio_to_irq(1) returns 65, which eth0 reports on boot: Why would that be confusing? Most embedded Linux platforms don't map GPIO IRQs to numbers recognized by the top level IRQ controller ... GPIO IRQs get fed to some bank IRQ, and the handler for that IRQ dispatches to the right handler. ___ 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..?
--- On Fri, 5/28/10, Sergei Shtylyov sshtyl...@mvista.com wrote: Would anyone like to comment on the status of MUSB OTG (for DM355) in the current git version? Haven't tried... As of something like 18 months ago, two key mechanisms mostly worked when I tested against (a) OMAP3, and (b) the fullspeed OTG tester. The two mechanisms were (i) cable based role switch: ID pin sensing, etc, during link setup. (This was working before, but I found a few bugs to fix.) (ii) basic HNP behavior, although some of the timings were out of spec, and some other minor non-compliance situations existed too. ISTR that SRP worked in some cases too, but that was rather awkward to test with the current PM framework. Haven't tried recently. My box that had the fullspeed OTG tester died (sigh), so I'll not be able to retest that any time soon. Those code paths were kind of fragile, so it would not surprise me to learn that someone patched something and (accidentally) broke some of them. And/or on the TI CPPI DMA option? Should basically work... .. Within limits of its design flaws, ISTR it was more or less behaving. Read the comments; RX woes explains some of how the original design was USB-antagonistic, TX was less so. Later CPPI (4.1) addressed at least some of the issues. I never trusted the code to abort transactions (TI never documented how to do that stuff so that code was always iffy). Since I last touched that code, I believe various folk have not just worked on it, but have successfully made it work better (yay!). Fixed corner cases and patched over undocumented bhaviors, and so on. I note that OTG depends on EXPERIMENTAL and the CPPI driver has a lot of discouraging comments and REVISITs throughout it. Well, the whole MUSB driver has a lot of REVISITs. :-) Coming from odd hardware design artifacts, both from Mentor (the M in MUSB) and from how various teams at TI integrated that IP with DMA. - Dave Thanks, WBR, Sergei __ ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: DM355+MSP430+push buttons
In case the answer didn't get posted (vs. being buried in my mailbox): --- On Tue, 5/4/10, Idriss Ghodhbane idriss.ghodhb...@gmail.com wrote: From: Idriss Ghodhbane idriss.ghodhb...@gmail.com Subject: DM355+MSP430+push buttons I am stuck at the level of controlling the push buttons of my EVM DM355(SW10/11/12/13/14).After searching on the net, I had discovered that I haven't the nexassary libraries for the microcontroller MSP430 neither integrated in my DVSDK_2_00_00_22 nor in the LSP linux-2.6.18_pro500 which is the kernel. Have you a solution for this issue? The mainline kernel driver for this is drivers/input/misc/dm355evm_keys.c It handles the IR remote control and LEDs too. ___ 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] rtc: omap: let device wakeup capability be configured from chip init logic
On Sun, Mar 07, 2010 at 18:05:54, Nori, Sekhar wrote: The rtc-omap driver currently hardcodes the RTC wakeup capability to be not capable. While this seems to be true for existing OMAP1 boards which are not wired for this, the DA850/OMAP-L138 SoC, the RTC can always be wake up source from its deep sleep mode. Good. Linux has work to do yet getting wake events to behave, and I keep thinking that RTC support is the best place for such work to start ... (since most RTCs seem to issue wake events, even on ACPI/PC hardware). So having RTCs do this right is forward motion, and will help (I'd hope!) get other wake event sources working too. That driver, as you know, started with OMAP1 where few boards were actually wired so the RTC would wake. Which is why it ignored the wake events ... :( This patch lets the wakeup capability to be set from platform data and does not override the setting from the driver. For DA850/OMAP-L138, this is done from arch/arm/mach-davinci/devices-da8xx.c:da8xx_register_rtc() Note that this patch does not change the behavior on any existing OMAP1 board since the platform device registration sets the wakeup capability to 0 by default. Dave, would you please ack this patch if you are satisfied? I don't see how it could work, since it always sets the wake capability to the default of can't wake... Even if the board *can* wake... The model I've worked with is that for devices which can issue wake events, the board init code sets that flag, and the driver responds appropriately. Presumably that could work here too... Can you please ack this patch if it looks good (or suggest any other changes you would like to see)? device_init_wakeup(pdev-dev, 0); Having that line seems to defeat the purpose... ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: WARNING: at drivers/gpio/gpiolib.c:1288 __gpio_get_value
I'm getting this Warning littered everywhere in my Kernel Bootlog... (arago-2.6.32-rc2 dm365) Does anyone understand why the GPIO lib thinks it needs to WARN_ON? WARN_ON(extra_checks chip-can_sleep); Is this just overkill warnings ? or are they legitimate? The warning means that you enabled debugging, and that the GPIO you're accessing through the spinlock-safe call may need to sleep. So yes, legit: callers expect no sleeping via those calls. Presuming those GPIOs can really block (canonical example being needing to go over I2C or SPI), the bug is in the caller not using the cansleep() variants, and/or possibly being mis-structured. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Multiple sd devices on dm644x
On Wednesday 23 September 2009, arun thomas whitchurch wrote: We are using a dm6446 based board with an sdio device and an sd slot on the sd/mmc bus. The driver seems to detect the sdio device but not any card plugged in to the sd slot. SD is a one-card-per-bus arrangement; SDIO too, as I understand. MMC supports multiple cards per bus, at least the older/slower versions of MMC. So absent external hardware like a bus switch letting you talk to either an SDIO device *or* an SD card, I don't think you can do that. (And such a switch would likely interfere badly with SDIO interrupts...) - Dave ___ 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: EDMA: Updating terminlogy in EDMA driver
On Sunday 20 September 2009, s-paul...@ti.com wrote: PARAM entries in the present GIT kernel are referred to as slots. New API's being added to the EDMA driver were referring to these PARAM entries as params. This patch updates the terminolgy used in the EDMA driver. Good; thanks. Avoiding confusion by using sane names, consistently, helps. :) ___ 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 1/2] Input: DaVinci Keypad Driver
On Wednesday 23 September 2009, Dmitry Torokhov wrote: __devexit? [MA] According to comments from David Brownell to the first version of this patch the __exit should be used. - Use platform_driver_probe() and __exit/__exit_p(); there's no point in keeping that code around in typical configs, it'd just waste memory. I am afraid David is wrong here. No, you're just pointing out a bug introduced in some unrelated code. Such bugs happen when folk ignore the code bloat issues. (And didn't Linus recently point out how such code bloat is becoming an issue?) Even when we register driver with platform_driver_probe() we still have unbind attribute in sysfs which may be used to unbind the device from driver. If code is __exit then such attempts will cause oops. That would be a bug in the unbind() code, which doesn't currently recognize that not every driver or bus supports hotplugging. It should probably check for a null release() pointer in the driver, and politely fail in that case. That's just about the only place that a third party (neither the driver nor its hotplug-aware bus framework) will try to decouple device and driver ... and it's doing it wrong. So it's unlikely such bugs will be elsewhere. It's *ALWAYS* been legit to have a NULL pointer in the remove() methods. That's why the __exit_p() -- or for hotpluggable drivers, __devexit_p() -- macros exist: for that particular case. - Dave ___ 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 1/2] nand: Add bad block table overrides to Davinci NAND driver
On Friday 18 September 2009, Mark A. Greer wrote: The issue is that the values for the 'offs' and 'veroffs' are wrong in the defaults used by nand_base.c:nand_default_bbt(). In what way wrong? ___ 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 1/2] Input: Add DaVinci DM365 Keypad support
On Thursday 17 September 2009, Miguel Aguilar wrote: I have another question: When should I use dev_err and dev_dbg in a probe function, for reporting the errors (-ENOMEM, -ENODEV, -ENOMEM, etc)? My two cents: dev_dbg() for configuration errors, which vanish once the board config is properly set up and are only needed in early debug stages. For anything else (rare!) it's OK to use dev_err(). Some folk like to clutter kernel images with gobs of strings for messages that never appear. I'm not one of them; and I think drivers should be written to minimize space used on production systems. Save that RAM for Real Work (tm)! It's a good habit to scan the driver object before you call work on it done. For platform drivers, probe/remove code should normally sit in init/exit sections. Symbols should as a rule not be exported from drivers. Having more than a handful of strings should raise red flags ... who is ever going to read them? (And why, and what should they do with them once they've seen those messages?) Real hardware faults generally deserve log messages. Little else does. Even look at the object code generated ... you may well observe stupidly large amounts of code generated for some things, which can easily be trimmed. (Remember that the cost of a few extra fetches into I-cache often dwarf call/return costs for a few helper subroutines, even on critical paths!) Sometimes a few minutes spent with such basic checks can show problems that bloat the runtime footprint by 20% or more. (Less after you get good habits though!) - Dave ___ 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: EDMA: New API edma_free_resource
On Monday 14 September 2009, Tivy, Robert wrote: Without this API, in order to call either edma_free_slot() or edma_free_channel() the LinuxUtils EDMAK device driver will have to carry a slot-vs-channel flag or cookie around with the EDMA allocation record. It already needs one of those though doesn't it? You can't use a slot to trigger a DMA transfer (keyed on an event, manually, or by chaining). Unless it's been set up as a QDMA channel... which and thus needs even more special handling during deallocation. The reason there'is no edma_alloc_resource() is that there really are two very distinct resource types, which need distinct treatment almost everywhere. - Dave ___ 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 1/2] Input: Add DaVinci DM365 Keypad support
On Monday 14 September 2009, miguel.agui...@ridgerun.com wrote:
+ dm365_kp = kzalloc(sizeof *dm365_kp, GFP_KERNEL);
+ key_dev = input_allocate_device();
+
+ if (!dm365_kp || !key_dev) {
+ dev_dbg(dev, Could not allocate input device\n);
+ return -ENOMEM;
+ }
Can still leak the kzalloc'ed data...
+ dm365_kp-irq = platform_get_irq(pdev, 0);
+ if (dm365_kp-irq = 0) {
+ dev_dbg(dev, %s: No DM365 Keypad irq\n, pdev-name);
+ goto fail1;
+ }
Still discards the true fault codes here and later ...
+ printk(KERN_INFO DaVinci DM365 Keypad Driver\n);
Nicer not to have such banners; a dev_info() in probe() is
better and won't show on boards where this driver isn't used.
___
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: dm646x-evm: Add platform data for NAND
On Thursday 03 September 2009, Siddharth Choudhuri wrote: Heh. My suggestion is to go the other way: just a single bootloader partition of eight blocks or so. Don't expose any of the substructure at all. Updating U-Boot from Linux seems kind of nice, but on the other hand why not just do it from U-Boot? If you have a device on field for which a u-boot upgrade is required, doing it from Linux is easier. You could have a small app that can talk over the network, fetch an updated u-boot and flash it. Not with the standard in-kernel partition tables, which make the U-Boot and UBL areas read-only: can't write them from Linux. Plus there's also the annoying problem of needing to make sure the ECC bytes are laid out the way the RBL and/or UBL want them, vs the way Linux reads and writes them. Thing is, if details of that boot layout aren't exposed to Linux, they can be improved without impacting Linux. Like adding backups for UBL or ABL/U-Boot; or for the U-Boot environment, for that matter. Makes sense. That not needing to understand funky ECC/OOB layout rules falls into the same category. :) For our use case, having the u-boot partitions exposed to Linux has been advantageous. However, if this is not the common case, then having a single partition labeled has boot serves the purpose. -sid ___ 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 1/2] Input: Add DaVinci DM365 Keypad support
On Thursday 10 September 2009, Miguel Aguilar wrote: Can anyone check this patch to make it ready to be pushed in the mainline? I tried it and it seemed to behave. Re ready to push, you should submit it ASAP to linux-input for review, to see if they think it's ready ... after addressing the following comments: - struct davinci_kp should be driver-internal, not part of the mach/... header used to interface platform_data - (number) is bad; just #define as the number, no parens - KEYPAD_BASE is unused (and shouldn't exist anyway) - Some of the keypad irq masks use spaces not tabs to line up; fix - Don't #undef DEBUG in the driver; that should normally be set conditionally via Makefile - Why do you expose non-static symbols in the driver? As a rule, drivers should not export symbols... - I see excess #includes - Those #ifdef DEBUG then pr_info() things should just be dev_debug() with no #ifdefs. - Your probe() logic can leak some of the memory you allocate ... and the cannot allocate input device message also has *two* failure modes, despite that text. (That case should fail with -ENOMEM; and I'd make most of those messages dev_debug not dev_err, on the grounds that once a board works they're all just wasted space and you want them to compile out.) - Use dev_err() not printk(KERN_ERR) - Use resource_size() to compute base_size. - The probe() should return the status code that's provided by the lower level functions, instead of always discarding that in favor of -EINVAL. Most failure modes are not related to bad arguments. - Surely your kp_remove() method should release the resources in the reverse of the order in which they were acquired? In particular, get rid of the IRQ before unregistering the input device, so you never need to worry about IRQs coming in on devices that have been unregistered, and thus triggering upcalls that the input subsystem will choke on. - Use platform_driver_probe() and __exit/__exit_p(); there's no point in keeping that code around in typical configs, it'd just waste memory. - Snug the module_init() decl up next to the function it identifies; ditto the module_exit() decl and the function which *it* identifies. ___ 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 2/3] ASoC: DaVinci: pcm, rename variables in prep for ping/pong
On Monday 31 August 2009, Troy Kisky wrote: - int master_lch; /* Master DMA channel */ - int slave_lch; /* linked parameter RAM reload slot */ + int asp_master_lch; /* Master DMA channel */ + int asp_link_lch[2];/* asp parameter link channel, ping/pong */ If you're going to rename things, may I suggest getting rid of lch ... use either channel or link, since those are the two basic hardware roles in EDMA. The original lch (logical channel) terminology was an IMO misguded attempt to hide the distinction between channels and links. But links can not be used when a channel is required, so that attempt was doomed to fail. (Channels could double as links, but as a rule that's not done since they're relatively scarce.) - Dave ___ 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 detect SD card size for DM6446.
On Monday 31 August 2009, Harshada Pendse wrote: I want to detect the SD card size from my application. /sys/block/mmcblk0/size ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Filesystem loading problem at 2.6.31 kernel on DM355 platform
On Thursday 03 September 2009, Venkatachala Upadhya wrote: As I recall, the linux root file system must be either NFS or EXT. No way. You need to tell the kernel rootfstype=... though; see Documentation/kernel-parameters.txt and other docs. For root on MMC/SD you'd probably use ext3 or somesuch; for root on NAND it'd be more like ubifs. ___ 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: dm646x-evm: Add platform data for NAND
On Wednesday 02 September 2009, Siddharth Choudhuri wrote: I would suggest splitting the bootloader partition into two -- (i) ubl and (ii) uboot. UBL can be 5 blocks (1 + 4 spare blocks) and u-boot could be the rest of the blocks. One of the advantages of this approach is that u-boot can be upgraded/reflashed easily from within Linux using flash_eraseall and nandwrite. (Although, even with the current partition scheme, u-boot can be written, but requires erasing individual blocks and could be error prone). Heh. My suggestion is to go the other way: just a single bootloader partition of eight blocks or so. Don't expose any of the substructure at all. Updating U-Boot from Linux seems kind of nice, but on the other hand why not just do it from U-Boot? Either way you have to stick an extra header on the binary. And most folk don't use that demo-quality U-Boot tool to access the u-boot environment block. Thing is, if details of that boot layout aren't exposed to Linux, they can be improved without impacting Linux. Like adding backups for UBL or ABL/U-Boot; or for the U-Boot environment, for that matter. - Dave ___ 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 2/3] ASoC: DaVinci: pcm, rename variables in prep for ping/pong
On Thursday 03 September 2009, Troy Kisky wrote: David Brownell wrote: On Monday 31 August 2009, Troy Kisky wrote: - int master_lch; /* Master DMA channel */ - int slave_lch; /* linked parameter RAM reload slot */ + int asp_master_lch; /* Master DMA channel */ + int asp_link_lch[2];/* asp parameter link channel, ping/pong */ If you're going to rename things, may I suggest getting rid of lch ... use either channel or link, since those are the two basic hardware roles in EDMA. I agree, but can that be a separate patch... However you like; I'd just suggest that *one* rename-things patch is normally preferred. If this one's already in the merge queue that might be awkward. ___ 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] SPI: DaVinci SPI Driver
On Thursday 03 September 2009, Paulraj, Sandeep wrote: I think these fixes are to be sent as incremental patches. Yes. No more complete-driver-replacement patches please; they impede reviewing. Andrew may well merge them before he sends them upstream. ___ 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] SPI: DaVinci SPI Driver
On Tuesday 01 September 2009, s-paul...@ti.com wrote:
From: Sandeep Paulraj s-paul...@ti.com
The patch adds a SPI driver for the DaVinci series of SOCs
[dbrown...@users.sourceforge.net: fixes and cleanup]
Signed-off-by: Sandeep Paulraj s-paul...@ti.com
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
NAK. I've not seen this version before.
Can you please send just a delta patch, vs what I submitted
and signed off on?
Signed-off-by: Mark A. Greer mgr...@mvista.com
Signed-off-by: Philby John pj...@in.mvista.com
... I hope these two folk are OK with this version of
the code, and you just got those signoffs off-list.
---
This patch was tested on the DaVinci DM355/DM365 and DM6467.
Separate patches have been sent to the DaVinci GIT kernel to enable SPI
in DM355/DM365/DM6467 through board specific code.
arch/arm/mach-davinci/include/mach/spi.h | 45 ++
drivers/spi/Kconfig |7 +
drivers/spi/Makefile |1 +
drivers/spi/davinci_spi.c| 757
++
drivers/spi/davinci_spi.h| 163 +++
5 files changed, 973 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-davinci/include/mach/spi.h
create mode 100644 drivers/spi/davinci_spi.c
create mode 100644 drivers/spi/davinci_spi.h
diff --git a/arch/arm/mach-davinci/include/mach/spi.h
b/arch/arm/mach-davinci/include/mach/spi.h
new file mode 100644
index 000..590393c
--- /dev/null
+++ b/arch/arm/mach-davinci/include/mach/spi.h
@@ -0,0 +1,45 @@
+/*
+ * Copyright 2009 Texas Instruments.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#ifndef __ARCH_ARM_DAVINCI_SPI_H
+#define __ARCH_ARM_DAVINCI_SPI_H
+
+#define SPI_INTERN_CS0xFF
+
+enum {
+ SPI_VERSION_1, /* For DM355/DM365/DM6467 */
+ SPI_VERSION_2, /* For DA8xx */
+};
+
+struct davinci_spi_platform_data {
+ u8 version;
+ u8 num_chipselect;
+ u8 wdelay;
+ u8 odd_parity;
+ u8 parity_enable;
+ u8 wait_enable;
+ u8 timer_disable;
+ u8 clk_internal;
+ u8 cs_hold;
+ u8 intr_level;
+ u8 poll_mode;
+ u8 c2tdelay;
+ u8 t2cdelay;
+};
+
+#endif /* __ARCH_ARM_DAVINCI_SPI_H */
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index cd3acfe..7f795c1 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -77,6 +77,13 @@ config SPI_AU1550
This driver can also be built as a module. If so, the module
will be called au1550_spi.
+config SPI_DAVINCI
+ tristate SPI controller driver for DaVinci/DA8xx SoC's
+ depends on SPI_MASTER ARCH_DAVINCI
+ select SPI_BITBANG
+ help
+ SPI master controller for DaVinci and DA8xx SPI modules.
+
config SPI_BITBANG
tristate Utilities for Bitbanging SPI masters
help
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index fbfc5f2..25b94fc 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_SPI_S3C24XX) += spi_s3c24xx.o
obj-$(CONFIG_SPI_TXX9) += spi_txx9.o
obj-$(CONFIG_SPI_XILINX) += xilinx_spi.o
obj-$(CONFIG_SPI_SH_SCI) += spi_sh_sci.o
+obj-$(CONFIG_SPI_DAVINCI)+= davinci_spi.o
#... add above this line ...
# SPI protocol drivers (device/link on bus)
diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
new file mode 100644
index 000..0d93732
--- /dev/null
+++ b/drivers/spi/davinci_spi.c
@@ -0,0 +1,757 @@
+/*
+ * Copyright (C) 2009 Texas Instruments.
+ * Copyright (C) 2008 MontaVista Software, Inc. sou...@mvista.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You
Re: [PATCH 1/6] DaVinci: SPI Driver for DaVinci and DA8xx SOC's
On Tuesday 25 August 2009, Paulraj, Sandeep wrote: I have not sent this patch to any list because I was under the impression that David Brownell would do so. I just did so ... AFAIK it's Sandeep's last version plus the two bugfix patches I sent. If there are further issues, just send delta patches... ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Direct SPI access on dm365 / dm355 using SPIDEV
On Wednesday 12 August 2009, Juraj Zopp wrote: Hi, Did someone successed to work with SPI from application? E.g. Use /dev/spi3 for controlling additional CPU from shell or with suggested spidev.c (linux/documentation/spi/spidev). I have no idea what /dev/spi3 is but you will note that the doc you reference gives a different path ... I use: mv_linux-2.6.18_pro500 and dvsdk_2_10_00_17 Best to try current kernel with the driver that's going upstream; if you want mv_linux you could ask them for help directly. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[patch 2.6.31-rc7] spi: davinci spi driver
From: Sandeep Paulraj s-paul...@ti.com
The patch adds a SPI driver for DaVinci series SOC's.
[dbrown...@users.sourceforge.net: fixes and cleanup]
Signed-off-by: Sandeep Paulraj s-paul...@ti.com
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
arch/arm/mach-davinci/include/mach/spi.h | 45 +
drivers/spi/Kconfig |7
drivers/spi/Makefile |1
drivers/spi/davinci_spi.c| 757 +
drivers/spi/davinci_spi.h| 163 ++
5 files changed, 973 insertions(+)
--- /dev/null
+++ b/arch/arm/mach-davinci/include/mach/spi.h
@@ -0,0 +1,45 @@
+/*
+ * Copyright 2009 Texas Instruments.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#ifndef __ARCH_ARM_DAVINCI_SPI_H
+#define __ARCH_ARM_DAVINCI_SPI_H
+
+#define SPI_INTERN_CS 0xFF
+
+enum {
+ SPI_VERSION_1, /* For DM355/DM365/DM6467*/
+ SPI_VERSION_2, /* For DA8xx */
+};
+
+struct davinci_spi_platform_data {
+ u8 version;
+ u16 num_chipselect;
+ u32 wdelay;
+ u32 odd_parity;
+ u32 parity_enable;
+ u32 wait_enable;
+ u32 timer_disable;
+ u32 clk_internal;
+ u32 cs_hold;
+ u32 intr_level;
+ u32 poll_mode;
+ u8 c2tdelay;
+ u8 t2cdelay;
+};
+
+#endif /* __ARCH_ARM_DAVINCI_SPI_H */
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -77,6 +77,13 @@ config SPI_AU1550
This driver can also be built as a module. If so, the module
will be called au1550_spi.
+config SPI_DAVINCI
+ tristate SPI controller driver for DaVinci/DA8xx SoC's
+ depends on SPI_MASTER ARCH_DAVINCI
+ select SPI_BITBANG
+ help
+ SPI master controller for DaVinci and DA8xx SPI modules.
+
config SPI_BITBANG
tristate Utilities for Bitbanging SPI masters
help
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_SPI_BFIN)+= spi_bfin5xx.
obj-$(CONFIG_SPI_BITBANG) += spi_bitbang.o
obj-$(CONFIG_SPI_AU1550) += au1550_spi.o
obj-$(CONFIG_SPI_BUTTERFLY)+= spi_butterfly.o
+obj-$(CONFIG_SPI_DAVINCI) += davinci_spi.o
obj-$(CONFIG_SPI_GPIO) += spi_gpio.o
obj-$(CONFIG_SPI_IMX) += mxc_spi.o
obj-$(CONFIG_SPI_LM70_LLP) += spi_lm70llp.o
--- /dev/null
+++ b/drivers/spi/davinci_spi.c
@@ -0,0 +1,757 @@
+/*
+ * Copyright (C) 2009 Texas Instruments.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/gpio.h
+#include linux/module.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/err.h
+#include linux/clk.h
+
+#include linux/spi/spi.h
+#include linux/spi/spi_bitbang.h
+
+#include mach/spi.h
+
+#include davinci_spi.h
+
+
+static void davinci_spi_rx_buf_u8(u32 data, struct davinci_spi *davinci_spi)
+{
+ u8 *rx = davinci_spi-rx;
+
+ *rx++ = (u8)data;
+ davinci_spi-rx = rx;
+}
+
+static void davinci_spi_rx_buf_u16(u32 data, struct davinci_spi *davinci_spi)
+{
+ u16 *rx = davinci_spi-rx;
+
+ *rx++ = (u16)data;
+ davinci_spi-rx = rx;
+}
+
+static u32 davinci_spi_tx_buf_u8(struct davinci_spi *davinci_spi)
+{
+ u32 data;
+ const u8 *tx = davinci_spi-tx;
+
+ data = *tx++;
+ davinci_spi-tx = tx;
+ return data;
+}
+
+static u32 davinci_spi_tx_buf_u16(struct davinci_spi *davinci_spi)
+{
+ u32 data;
+ const u16 *tx = davinci_spi-tx;
+
+ data = *tx
Re: [patch 2.6.31-rc7] spi: davinci spi driver
On Friday 28 August 2009, Sergei Shtylyov wrote: Hello. David Brownell wrote: From: Sandeep Paulraj s-paul...@ti.com The patch adds a SPI driver for DaVinci series SOC's. [dbrown...@users.sourceforge.net: fixes and cleanup] Signed-off-by: Sandeep Paulraj s-paul...@ti.com Signed-off-by: David Brownell dbrown...@users.sourceforge.net This patch lacks MV people's signoffs (and MV copyright on the driver). -ENOPATCH I don't recall seeing any version with MV attributions, FWIW. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Problem with the current EDMA driver in the DaVinci GIT kernel
On Friday 28 August 2009, Tivy, Robert wrote: I'd like to suggest a scheme involving some sort of driver-controlled unlocking of reserved channels, intended to be used late in the EDMA acquisition timeline. I think the suggestion I made was a lot simpler, and less error prone. The very *notion* of locking/unlocking things is asking for trouble. Why expose such a concept when it's clearly not needed? Before exploring different solutions ... how about giving my previous suggestion a fair shake first?? A simple implementation would be just scanning all the platform devices at some point (say, the first EDMA_ANY allocation) to construct that mask of potentially used on this board EDMA channels ... making the rest available for EDMA_ANY usage. Completely transparent to callers, and no need for SOC-specific hackery. And a fairly trivial thing to implement too ... just a driver model call to walk the platform_bus devices, then an array iteration to find the DMA resources. The LinuxUtils EDMA driver has a strong need for EDMA_ANY type of allocation, to support memory-to-memory transfers by codecs, mostly. My suggestion made many such channels available. It would be nice to also solve the issue of raw EDMA usage through mmap()'ing the EDMA register set and directly writing registers. Perhaps the /dev/mem driver can intercept these requests and somehow negotiate or control access to those registers (I'm just tossing this out there with not much idea of how to solve it). The /dev/mem (and /dev/kmem etc) drivers embed no policy. If you want policy, you'd need to write a new driver. - Dave ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Problem with the current EDMA driver in the DaVinci GIT kernel
On Friday 28 August 2009, Tivy, Robert wrote: And a fairly trivial thing to implement too ... just a driver model call to walk the platform_bus devices, then an array iteration to find the DMA resources. Is this something that can be implemented today, with the current driver model, Yes; bus_for_each_dev(platform_bus_type, ...) then using platform_device.resource[] to check for channels. or would it need some new information to be added to every DMA-using driver? (sorry for asking you to educate me, but I'm just not that familiar with all the driver specifics) Given they fetch their channels correctly (as resources), all the data is already in place. ASoC was trouble in the past; fixed now, I hope. The LinuxUtils EDMA driver has a strong need for EDMA_ANY type of allocation, to support memory-to-memory transfers by codecs, mostly. My suggestion made many such channels available. Great. BTW, I've been told that future codecs would want on the order of 50 EDMA_ANY-type channels. Sounds a bit excessive; like they needlessly refuse to share those resources! But if that's on hardware with channels to burn, so be it. - Dave ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Problem with the current EDMA driver in the DaVinci GIT kernel
On Tuesday 25 August 2009, Paulraj, Sandeep wrote: Soon TI will support a DVSDK release based on the DaVinci GIT kernel for DM355 and DM365. The entire DVSDK release uses EDAM API's for some resource management and to acquire resources(Channels, PARAMS). But under the current implementation very few channels can be acquired by the Linuxutils component of the DVSDK which manages EDMA resources. So why not just fix that Linuxutils stuff?? In DM355 very few channels can be acquired using the EDMA_CHANNEL_ANY and in DM365 0 channels can be acquired with this option. Right; there are only so many EDMA channels that aren't wired up to any hardware, and that's what CHANNEL_ANY provides. Thus I propose to use 2 patches [deleted] What this will effectively do is to change the meaning of th e dma_chan_dm355_no_event structure. Other channels do have events associated with them but we intentionally add them to this structure so that it can be acquired by the DVSDK. Seems like an especially ugly hack. Why not just define some new EDMA_CHANNEL_* selector with new semantics? What's unclear is just why you chose those numbers. I suspect the issue is that you just want to avoid channels which are (a) used by Linux drivers, and (b) the board uses the relevant driver. Suggesting a name like EDMA_CHANNEL_HW_UNUSED. So if for example the UART driver doesn't use EDMA the UART channels could be candidates ... as could GPIO banks in most cases, and direct GPIOs on a more board-specific basis. - Dave ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Problem with the current EDMA driver in the DaVinci GIT kernel
So why not just fix that Linuxutils stuff?? [Sandeep] That's done by other teams within TI and we want to re use as much as possible. Fine, but from what you said, their stuff basically does not work today. So there's nothing to reuse. If features need to be added it has to be in the EDMA kernel driver And adding features means working with that team so everyone agrees on the interface. In DM355 very few channels can be acquired using the EDMA_CHANNEL_ANY and in DM365 0 channels can be acquired with this option. Right; there are only so many EDMA channels that aren't wired up to any hardware, and that's what CHANNEL_ANY provides. [Sandeep] NO. I know for DM355 you are referring to pages 36-37 in http://focus.ti.com/lit/ug/spruee4a/spruee4a.pdf which says that channels 12, 13, 24, 56-63 are reserved. These do have hardware events associated with them and are used by the IMCOP in DM355. Sounds like a doc bug to me. It should at least say which channels are used by IMCOP, vs which are free for use by software triggering (or chaining), vs being e.g. broken. So the name dma_chan_dm355_no_event which suggest that there is no hardware event associated with the channels (in that structure) is not true. It's as accurate as possible given that doc bug... Maybe just add a comment what we are trying to achieve should serve the purpose. There already *is* a description of what CHANNEL_ANY is supposed to deliver... if you're going to redefine those semantics, do it properly. My default assumption is, FWIW, that new semantics need a new EDMA_CHANNEL_* symbol. In this case one might argue that we don't want the old semantics, just the new ones. Which still requires updating the interface spec. What's unclear is just why you chose those numbers. I suspect the issue is that you just want to avoid channels which are (a) used by Linux drivers, and (b) the board uses the relevant driver. [Sandeep] yes Suggesting a name like EDMA_CHANNEL_HW_UNUSED. [Sandeep] I don't think this is needed Maybe not. If all devices associated with DMA drivers can be relied on to (i) register by a certain point in the init sequence, and (ii) properly list the DMA channels they use in their platform resources, then it's obviously possible to construct a set of all DMA channels potentially in use by drivers on that particular board. And the list of channels available for use with software triggering, or chaining, or whatever this LinuxUtils thing is ... would be the inverse of that set. At that point in the init sequence -- and before drivers are expected to make CHANNEL_whatever allocations -- feed the set of free channels to the EDMA infrastructure. IMCOP and similar codec drivers would of course need to claim the channels they need; same deal. That would maximize the number of channels available for dynamic use by triggering and chaining. - Dave So if for example the UART driver doesn't use EDMA the UART channels could be candidates ... as could GPIO banks in most cases, and direct GPIOs on a more board-specific basis. [Sandeep] that's correct - Dave ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Problem with the current EDMA driver in the DaVinci GIT kernel
On Wednesday 26 August 2009, Paulraj, Sandeep wrote: What's unclear is just why you chose those numbers. I suspect the issue is that you just want to avoid channels which are (a) used by Linux drivers, and (b) the board uses the relevant driver. [Sandeep] yes Suggesting a name like EDMA_CHANNEL_HW_UNUSED. [Sandeep] I don't think this is needed Maybe not. If all devices associated with DMA drivers can be relied on to (i) register by a certain point in the init sequence, and (ii) properly list the DMA channels they use in their platform resources, then it's obviously possible to construct a set of all DMA channels potentially in use by drivers on that particular board. [Sandeep] this can also be achieved by updating the structure appropriately as I have done in the patches whose links I had given earlier No; that's not maintainable. Each time a new driver starts to use a channel, someone has to remember to update that table. That's why it's just a hack. People WILL forget to update that stuff, and then things WILL break. Plus, notice that your static updates won't accomodate board-specific differences either ... like a board not using one peripheral, and thereby making its DMA channels available for other use. And the list of channels available for use with software triggering, or chaining, or whatever this LinuxUtils thing is ... would be the inverse of that set. At that point in the init sequence -- and before drivers are expected to make CHANNEL_whatever allocations -- feed the set of free channels to the EDMA infrastructure. IMCOP and similar codec drivers would of course need to claim the channels they need; same deal. [Sandeep] how the IMCOP deals with its channels is handled by other components of the DVSDK. I am not sure of how exactly it is handled and I don't even know if the IMCOP actually used hardware triggering. If those components don't say that they use those DMA channels, then something other than IMCOP will be able to allocate them... trouble. So you'd better *find out* how it allocates those resources, if you're trying to redefine the semantics of the mechanism you identified. Or at least, you need to make sure they use the right allocation scheme. That would maximize the number of channels available for dynamic use by triggering and chaining. [Sandeep] basically the objective is to atleast allow all channels not being used by the kernel to be acquired by the linuxutils/DVSDK. How they then use these channels is the responsibility of these other components. If they want a channel they need to use the allocation calls. The how they use them is irrelevant ... but if as you said some of them (IMCOP etc) need *specific* channels, usually because they're hard-wired to some peripheral but maybe just because some firmware doesn't understand dynamic allocation, it's got to request those specific channels. The reason to use CHANNEL_ANY is because you don't have a requirement for a specific channel. - Dave ___ 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 3/5 - v3] DaVinci: platform changes to support vpfe camera capture
On Monday 17 August 2009, m-kariche...@ti.com wrote:
static struct i2c_board_info dm355evm_i2c_info[] = {
{ I2C_BOARD_INFO(dm355evm_msp, 0x25),
.platform_data = dm355evm_mmcsd_gpios,
},
+ {
+ I2C_BOARD_INFO(PCA9543A, 0x73),
+ },
/* { plus irq }, */
/* { I2C_BOARD_INFO(tlv320aic3x, 0x1b), }, */
};
The DM355 EVM board has no PCA9543A I2C multiplexor
chip, so this is not a good approach to use. (*)
If I understand correctly you are configuring some
particular add-on board, which uses a chip like that.
There are at least two such boards today, yes? And
potentially more. Don't preclude (or complicate)
use of different boards...
The scalable approach is to have a file for each
daughtercard, and Kconfig options to enable the
support for those cards. The EVM board init code
might call a dm355evm_card_init() routine, and
provide a weak binding for it which would be
overridden by the
- Dave
(*) Separate issue: there's ongoing work to get the
I2C stack to support such chips in generic ways;
you should plan to use that work, which ISTR wasn't
too far from being mergeable.
___
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] MMC: SDIO reset functionality to the existing MMC frame work
On Thursday 06 August 2009, PhaneendraKumar A wrote:
Observed some issues during the initialization of SDIO cards. The
initialization sequence for SDIO card is not according to the SDIO
specification. Hence the card is not getting initialized during module
reload with card always present in the slot. This patch fixes the
issue.
This needs to go to LKML and merge to mainline ...
Signed-off-by: ph...@embwise.com
---
drivers/mmc/core/core.c |1 +
drivers/mmc/core/sdio_ops.c | 22 ++
drivers/mmc/core/sdio_ops.h |1 +
3 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index d84c880..5ec7e75 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -890,6 +890,7 @@ void mmc_rescan(struct work_struct *work)
mmc_claim_host(host);
mmc_power_up(host);
+ mmc_reset_sdio(host);
mmc_go_idle(host);
mmc_send_if_cond(host, host-ocr_avail);
diff --git a/drivers/mmc/core/sdio_ops.c b/drivers/mmc/core/sdio_ops.c
index 4eb7825..2e77ab8 100644
--- a/drivers/mmc/core/sdio_ops.c
+++ b/drivers/mmc/core/sdio_ops.c
@@ -19,6 +19,28 @@
#include core.h
#include sdio_ops.h
+int mmc_reset_sdio(struct mmc_host *host)
+{
+ struct mmc_command cmd;
+ int err = 0;
+
+ BUG_ON(!host);
+
+ memset(cmd, 0, sizeof(struct mmc_command));
+
+ cmd.opcode = SD_IO_RW_DIRECT;
+ cmd.arg = 0x8000;
+ cmd.arg |= (SDIO_CCCR_ABORT) 9;
+ cmd.arg |= (13);
+ cmd.flags = MMC_RSP_R5 | MMC_CMD_AC;
+
+ err = mmc_wait_for_cmd(host, cmd, 0);
+ if (err)
+ return err;
+
+ return 0;
+}
+
int mmc_send_io_op_cond(struct mmc_host *host, u32 ocr, u32 *rocr)
{
struct mmc_command cmd;
diff --git a/drivers/mmc/core/sdio_ops.h b/drivers/mmc/core/sdio_ops.h
index e2e74b0..2ef70b8 100644
--- a/drivers/mmc/core/sdio_ops.h
+++ b/drivers/mmc/core/sdio_ops.h
@@ -17,6 +17,7 @@ int mmc_io_rw_direct(struct mmc_card *card, int
write, unsigned fn,
unsigned addr, u8 in, u8* out);
int mmc_io_rw_extended(struct mmc_card *card, int write, unsigned fn,
unsigned addr, int incr_addr, u8 *buf, unsigned blocks, unsigned blksz);
+int mmc_reset_sdio(struct mmc_host *host);
#endif
--
1.6.0.4
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Montavista Compiler License
On Thursday 06 August 2009, Vladimir Pantelic wrote: http://gcc.gnu.org/ml/gcc/2008-08/msg00041.html Those messages don't touch on the FlexLM issue. Distributing just GCC (+patches) isn't enough. Because its seems the GPL'd core is combined with FlexLM, source to both must be available to anyone who gets that combined product. If FlexLM is actually secure, exposing its source won't reduce security... TI may have duties here too, since they distribute some MV tools with e.g. EVM boards. ___ 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 + sd card (mmc1) is not detected
On Monday 03 August 2009, kirthika varadarajan wrote: Is there in any other thing which i have to do to detect MMC 1. Yeah, I reported the same problem. Unrelated: if you're using the ARM JTAG connector, SRST is nonfunctional. The CPLD is just programmed that way. Easy enough to fix, given the right tools. - Dave ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: DM355 SDIO support
On Wednesday 29 July 2009, Phaneendra kumar wrote:
This patch will add SDIO support to the DM355 host controller driver.
I have verified this on DM355 EVM board in both DMA and PIO modes.
The MMC driver isn't specific to that chip. :)
And i have used open source libertas driver for verifying the SDIO
functionality.
That seems to be necessary. Other SDIO hardware isn't very
easy to come by nowadays!
Signed-off-by: Phaneendra Kumar ph...@embwise.com
This seems to be missing something basic: a request_irq() call
for the SDIO interrupt. See the appended, which is the updated
version of something I sent around several months ago ... hoping
someone had libertas hardware and some test/debug cycles!
Maybe you can combine the two and get code which works more like
it's supposed to work. I see that you did address the what if
the interrupt is already triggering case, for example.
- Dave
==
SDIO support in the MMC framework seems to involve no more than just
being able to report SDIO irqs. Here's (untested) code to do that.
# REVISIT -- errata doc, usage note 2.1.5, sez:
# - issue: must check SDIOIST.IONT and sample SDIOST0.DAT1 to detect
# level triggered SDIO using edge detect in ctrlr, given races
# between irq enable at sdio card and (then) controller
# - before enable: sample DAT1 (INTPRD=1, DAT1=1)
# ... may have been raised before enabled in ctrlr
# - does sdio_irq() clear irq status as it reads it?
# ... mask irq before signaling irq
---
drivers/mmc/host/davinci_mmc.c | 53 ++-
1 file changed, 52 insertions(+), 1 deletion(-)
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -163,6 +163,7 @@ struct mmc_davinci_host {
void __iomem *base;
struct resource *mem_res;
int irq;
+ int sdio_irq;
unsigned char bus_mode;
#define DAVINCI_MMC_DATADIR_NONE 0
@@ -1011,6 +1012,35 @@ static irqreturn_t mmc_davinci_irq(int i
return IRQ_HANDLED;
}
+static irqreturn_t mmc_davinci_sdio_irq(int irq, void *dev_id)
+{
+ struct mmc_davinci_host *host = dev_id;
+ u32 sdiost;
+
+ sdiost = readl(host-base + DAVINCI_SDIOST);
+ if (sdiost BIT(0))
+ mmc_signal_sdio_irq(host-mmc);
+ return IRQ_HANDLED;
+}
+
+static void mmc_davinci_enable_sdio_irq(struct mmc_host *mmc, int enable)
+{
+ struct mmc_davinci_host *host = mmc_priv(mmc);
+ u32 sdioen;
+
+ /* FIXME card may already be issuing (level) IRQ ... so when
+* enabling, check DAT1 here and handle the case where we won't
+* trigger since the edge already happened.
+*/
+
+ sdioen = readl(host-base + DAVINCI_SDIOEN);
+ if (!enable)
+ sdioen = ~BIT(0);
+ else
+ sdioen |= BIT(0);
+ writel(sdioen, host-base + DAVINCI_SDIOEN);
+}
+
static int mmc_davinci_get_cd(struct mmc_host *mmc)
{
struct platform_device *pdev = to_platform_device(mmc-parent);
@@ -1036,6 +1066,7 @@ static struct mmc_host_ops mmc_davinci_o
.set_ios= mmc_davinci_set_ios,
.get_cd = mmc_davinci_get_cd,
.get_ro = mmc_davinci_get_ro,
+ .enable_sdio_irq = mmc_davinci_enable_sdio_irq,
};
/*--*/
@@ -1058,6 +1089,8 @@ static void __init init_mmcsd_host(struc
writel(0x1FFF, host-base + DAVINCI_MMCTOR);
writel(0x, host-base + DAVINCI_MMCTOD);
+ writel(0, host-base + DAVINCI_SDIOEN);
+
writel(readl(host-base + DAVINCI_MMCCTL) ~MMCCTL_DATRST,
host-base + DAVINCI_MMCCTL);
writel(readl(host-base + DAVINCI_MMCCTL) ~MMCCTL_CMDRST,
@@ -1132,9 +1165,24 @@ static int __init davinci_mmcsd_probe(st
/* REVISIT: someday, support IRQ-driven card detection. */
mmc-caps |= MMC_CAP_NEEDS_POLL;
- if (!pdata || pdata-wires == 4 || pdata-wires == 0)
+ if (!pdata || pdata-wires == 4 || pdata-wires == 0) {
mmc-caps |= MMC_CAP_4_BIT_DATA;
+ /* for now, no support for IRQs (on DAT1) except
+* when 4-wire mode is supported.
+* REVISIT there's a DAT2 read-wait IRQ too ...
+*/
+ host-sdio_irq = platform_get_irq(pdev, 1);
+ if (host-sdio_irq 0) {
+ ret = request_irq(host-sdio_irq,
+ mmc_davinci_sdio_irq, 0,
+ mmc_hostname(mmc), host);
+ if (ret == 0)
+ mmc-caps |= MMC_CAP_SDIO_IRQ;
+ }
+ }
+
+
host-version = pdata-version;
mmc-ops = mmc_davinci_ops;
@@ -1215,6 +1263,9 @@ static int __exit davinci_mmcsd_remove(s
platform_set_drvdata(pdev, NULL);
if (host) {
+ if
Re: [PATCH 1/6] DaVinci: SPI Driver for DaVinci and DA8xx SOC's
On Thursday 30 July 2009, Paulraj, Sandeep wrote: Functions set_fmt_bits and clear_fmt_bits are wrong here. Which SPIFMTn register to use is decided by the DFSEL bit in SPIDAT1 register and this patch is using SPIFMT0 as the default value of DFSEL is ZERO. But the above functions are writing to SPIFMT1 if bus_num is 1. [Sandeep] I'll rectify Rectified already in the patch I sent on 16-July .. ___ 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 1/6] DaVinci: SPI Driver for DaVinci and DA8xx SOC's
On Thursday 16 July 2009, David Brownell wrote:
On Wednesday 15 July 2009, s-paul...@ti.com wrote:
arch/arm/mach-davinci/include/mach/spi.h | 45 ++
drivers/spi/Kconfig | 7 +
drivers/spi/Makefile | 1 +
drivers/spi/davinci_spi.c | 751
++
drivers/spi/davinci_spi.h | 163 +++
5 files changed, 967 insertions(+), 0 deletions(-)
It's getting a lot closer. See the appended ... the issues I
see remaining are partly performance (if you only set the FMT
register in the setup code the per-message overhead will be
a lot less) and partly functional (those per-device settings
that are treated as global, or wrongly held back on v1 parts).
Let me know if you plan to address either of those.
- Dave
I saw a followup from you that was incorrect (failed when
spi_setup was called with an operation pending) ... so here's
a second fixup, going on top of that 16-july patch, which
moves almost everything out of per-message overhead. Verified
on dm355evm and dm365evm
Please let me know if there's a reason I shouldn't send
your [1/6] patch upstream after combining it with the two
fixup patches I've sent.
- Dave
CUT HERE
A few more fixes vs my previous patch:
- Remove needless spi-bits_per_word default, now handled
by the SPI core;
- Move SPIFMTx setting to the spi_setup() code, out of
the per-message overhead;
- Move some never-change SPI settings to probe(), again
out of the per-message overhead.
This keeps a lot of setup code from being per-message overhead.
---
drivers/spi/davinci_spi.c | 89 ++--
1 file changed, 46 insertions(+), 43 deletions(-)
--- a/drivers/spi/davinci_spi.c
+++ b/drivers/spi/davinci_spi.c
@@ -198,10 +198,6 @@ static int davinci_spi_setup(struct spi_
davinci_spi = spi_master_get_devdata(spi-master);
- /* if bits per word length is zero then set it default 8 */
- if (!spi-bits_per_word)
- spi-bits_per_word = 8;
-
/*
* SPI in DaVinci and DA8xx operate between
* 600 KHz and 50 MHz
@@ -209,23 +205,13 @@ static int davinci_spi_setup(struct spi_
if (spi-max_speed_hz 60 || spi-max_speed_hz 5000)
return -EINVAL;
- retval = davinci_spi_setup_transfer(spi, NULL);
-
- return retval;
-}
-
-static int davinci_spi_bufs_prep(struct spi_device *spi,
-struct davinci_spi *davinci_spi)
-{
- int op_mode = 0;
-
/*
-* Set up device-specific SPI configuration parameters.
-* Most of these would normally be handled in spi_setup(),
-* updating the per-chipselect FMT registers, but some of
-* them use global controls like SPI_LOOP and SPI_READY.
+* Set up SPIFMTn register, unique to this chipselect.
+*
+* NOTE: we could do all of these with one write. Also, some
+* of the version 2 features are found in chips that don't
+* support all of them...
*/
-
if (spi-mode SPI_LSB_FIRST)
set_fmt_bits(davinci_spi-base, SPIFMT_SHIFTDIR_MASK,
spi-chip_select);
@@ -247,6 +233,19 @@ static int davinci_spi_bufs_prep(struct
clear_fmt_bits(davinci_spi-base, SPIFMT_PHASE_MASK,
spi-chip_select);
+ /*
+* Version 1 hardware supports two basic SPI modes:
+* - Standard SPI mode uses 4 pins, with chipselect
+* - 3 pin SPI is a 4 pin variant without CS (SPI_NO_CS)
+* (distinct from SPI_3WIRE, with just one data wire;
+* or similar variants without MOSI or without MISO)
+*
+* Version 2 hardware supports an optional handshaking signal,
+* so it can support two more modes:
+* - 5 pin SPI variant is standard SPI plus SPI_READY
+* - 4 pin with enable is (SPI_READY | SPI_NO_CS)
+*/
+
if (davinci_spi-version == SPI_VERSION_2) {
clear_fmt_bits(davinci_spi-base, SPIFMT_WDELAY_MASK,
spi-chip_select);
@@ -293,33 +292,21 @@ static int davinci_spi_bufs_prep(struct
spi-chip_select);
}
- /* Clock internal */
- if (davinci_spi-pdata-clk_internal)
- set_io_bits(davinci_spi-base + SPIGCR1,
- SPIGCR1_CLKMOD_MASK);
- else
- clear_io_bits(davinci_spi-base + SPIGCR1,
- SPIGCR1_CLKMOD_MASK);
+ retval = davinci_spi_setup_transfer(spi, NULL);
- /* master mode default */
- set_io_bits(davinci_spi-base + SPIGCR1, SPIGCR1_MASTER_MASK);
+ return retval;
+}
- if (davinci_spi-pdata-intr_level)
- iowrite32(SPI_INTLVL_1, davinci_spi-base + SPILVL);
- else
Re: New MMC maintainer needed
[ NOTE: cc list morphed ] On Friday 31 July 2009, Pierre Ossman wrote: [PATCH] DaVinci: MMC: V5: MMC/SD controller driver for DaVinci family. (couldn't find an archive) This driver has undergone some reviews and should be more or less done. Please check the previous review comments to confirm that everything has been fixed. Yep, it's past time this merges ... further cleanup can be done as patches against mainline. I think Vipin was shepherding this to mainline, and thus has the latest? ___ 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] [MTD] m25p80: memory accessor interface for SPI MTD driver
On Monday 03 August 2009, Sudhakar Rajashekhara wrote: On TI's da850/omap-l138 EVM, MAC address is stored in SPI flash. This patch implements memory accessor interface for SPI MTD driver which enables the kernel to access flash data. If that's going to be possible, shouldn't it work for any MTD device? And the lack of protection bothers me a bit more here than with EEPROMs and NVRAM, since it seems kind of easy to clobber UBI (or JFFS2 etc) data. Maybe there should be a way to make jus a specific partition available this way? This patch also changes the initialization sequence of the drivers by moving mtd and spi ahead of net in drivers/Makefile thereby enabling da850/omap-l138 ethernet driver to read the MAC address while booting. Worth a separate patch. That much raises no flags for me. For the SPI move: Acked-by: David Brownell dbrown...@users.sourceforge.net - Dave Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com ___ 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 1/6] DaVinci: SPI Driver for DaVinci and DA8xx SOC's
On Tuesday 04 August 2009, Paulraj, Sandeep wrote: I do not see a reason why this should not go upstream. OK, I'll try to send that soon ... There is 1 issue At this point of time i am unable to think of a good solution which actually takes care of minor differences in the IP between DM355/DM365/DM6467 and Primus. I do not know of a clean way to do it without using is_cpu_* which i understand is strictly discouraged. Actually *some* of it can be driven purely by the board setup code ... rely on it not to set features that the hardware doesn't support, and that suffices for quite a few of those mechanisms. Maybe all of them, even ... ___ 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] mfd: Correct ro and cd implemantion on DM355
On Wednesday 22 July 2009, Vipin Bhandari wrote:
This patch corrects the support for MMCSD card detection
and read only feature for SoC DM355.
EVMDM355_ECP_VA4.pdf, from Spectrum digital, suggests that
Bit 2 and 4 should be checked for card detection. However
on the EVM, bits 1 and 3 gives this status, for MMC/SD
instance 0 and 1 respectively. The pdf also suggests that
Bit 1 and 3 should be checked for write protection. However
on the EVM bits 2 and 4 gives this status.
In short: card detection works iff the writeprotect switch
isn't used, since the two signals are swapped.
This document can be downloaded from
http://c6000.spectrumdigital.com/evmdm355/reve/files/EVMDM355_ECP_VA4.pdf
Signed-off-by: Vipin Bhandari vipin.bhand...@ti.com
Acked-by: David Brownell dbrown...@users.sourceforge.net
but this should merge through the MFD tree. Send it to
(per MAINTAINERS):
MULTIFUNCTION DEVICES (MFD)
P: Samuel Ortiz
M: sa...@linux.intel.com
T: git git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6.git
S: Supported
F: drivers/mfd/
---
This patch has been tested on DM355 EVM.
Since the previous version, format of the multi-line comment
has been corrected.
drivers/mfd/dm355evm_msp.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/dm355evm_msp.c b/drivers/mfd/dm355evm_msp.c
index 5b6e58a..3d4a861 100644
--- a/drivers/mfd/dm355evm_msp.c
+++ b/drivers/mfd/dm355evm_msp.c
@@ -107,8 +107,16 @@ static const u8 msp_gpios[] = {
MSP_GPIO(2, SWITCH1), MSP_GPIO(3, SWITCH1),
MSP_GPIO(4, SWITCH1),
/* switches on MMC/SD sockets */
- MSP_GPIO(1, SDMMC), MSP_GPIO(2, SDMMC), /* mmc0 WP, nCD */
- MSP_GPIO(3, SDMMC), MSP_GPIO(4, SDMMC), /* mmc1 WP, nCD */
+ /*
+ * Note: EVMDM355_ECP_VA4.pdf suggests that Bit 2 and 4 should be
+ * checked for card detection. However on the EVM bit 1 and 3 gives
+ * this status, for 0 and 1 instance respectively. The pdf also
+ * suggests that Bit 1 and 3 should be checked for write protection.
+ * However on the EVM bit 2 and 4 gives this status,for 0 and 1
+ * instance respectively.
+ */
+ MSP_GPIO(2, SDMMC), MSP_GPIO(1, SDMMC), /* mmc0 WP, nCD */
+ MSP_GPIO(4, SDMMC), MSP_GPIO(3, SDMMC), /* mmc1 WP, nCD */
};
#define MSP_GPIO_REG(offset) (msp_gpios[(offset)] 3)
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: DM6446 - ARM CPU blocked during EDMA transfers?
On Friday 17 July 2009, Steve Chen wrote: We will will move the DMA input to one of the other banks and disable that bank’s interrupt. If that cannot be done on our hardware, we will try reworking the DaVinci interrupt handler so we only enable for interrupt selected GPIO0…7 pins and and BANK1..4, and never BANK0. I remember seeing an extensive discussion on this mailing list regarding DaVinci GPIO bank vs individual interrupt. You may find these discussions helpful. For *current* GIT kernels you could also just set davinci_soc_info.gpio_unbanked = 8; in your board init, to make it so the bank IRQs are not used at all ... and only the first 8 GPIO IRQs are available. That number 8 is specific to the DM6446, since it has 8 non-banked GPIO IRQs. ___ 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 1/6] DaVinci: SPI Driver for DaVinci and DA8xx SOC's
On Friday 17 July 2009, Steve Chen wrote: On Thu, 2009-07-16 at 18:55 -0700, David Brownell wrote: On Thursday 16 July 2009, Paulraj, Sandeep wrote: There are differences also in the diff pin modes(3,4, 5 pins) between all the different IPs. I see, then. Comments missing. :) This is the sort of thing which makes me want to put cpu_is_XXX() logic into drivers ... it's a good way to handle lots of little differences. [Sandeep] What would be your suggestion? Should I leave it for the time being? Yes. There used to be cpu_is_xxx logic in this and other DaVinci drivers. This is a new driver. :) The code became very messy as new SoCs were added. It took a great amount of effort to clean up and remove all instances of cpu_is_xxx from drivers. Lets stay away from reintroducing the cpu_is_xxx macros back into the driver if all possible. I know there's some dislike of those macros, which is why I was pointing out that this is the kind of problem that's fairly awkward to solve *without* using them. And why I'm not pushing to switch to them, at least for now. - Dave ___ 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] SPI: DaVinci: Adding SPI driver for DM3xx/DM6467/DA8xx
You goofed on the changes to spi_setup() ...
On Friday 17 July 2009, s-paul...@ti.com wrote:
+static int davinci_spi_setup(struct spi_device *spi)
+{
+ int retval;
+ int op_mode = 0;
+ struct davinci_spi *davinci_spi;
+
+ davinci_spi = spi_master_get_devdata(spi-master);
+
+ /*
+ * Set up device-specific SPI configuration parameters.
+ * Most of these would normally be handled in spi_setup(),
... by just moving all of the old davinci_spi_bufs_prep() here.
Example, that comment is specific to the old davinci_spi_bufs_prep()
code not this version. That's an easy fix (although I'd still
rather see this have a single read and write to the FMT register).
Except the global options (loopback, READY handsdhaking) should
not be here ... in this hardware they are global, so that by
setting them here you could trash an ongoing transfer.
The rule of thumb for the setup() methods is that you must expect
they are called in the middle of a transfer for some *OTHER* chip
select line. See 6e538aaf50ae782a890cbc02c27950448d8193e1 ...
+ * updating the per-chipselect FMT registers, but some of
+ * them use global controls like SPI_LOOP and SPI_READY.
+ */
+
+ if (spi-mode SPI_LSB_FIRST)
+ set_fmt_bits(davinci_spi-base, SPIFMT_SHIFTDIR_MASK,
+ spi-chip_select);
+ else
+ clear_fmt_bits(davinci_spi-base, SPIFMT_SHIFTDIR_MASK,
+ spi-chip_select);
+
+ if (spi-mode SPI_CPOL)
+ set_fmt_bits(davinci_spi-base, SPIFMT_POLARITY_MASK,
+ spi-chip_select);
+ else
+ clear_fmt_bits(davinci_spi-base, SPIFMT_POLARITY_MASK,
+ spi-chip_select);
+
+ if (!(spi-mode SPI_CPHA))
+ set_fmt_bits(davinci_spi-base, SPIFMT_PHASE_MASK,
+ spi-chip_select);
+ else
+ clear_fmt_bits(davinci_spi-base, SPIFMT_PHASE_MASK,
+ spi-chip_select);
+
+ if (davinci_spi-version == SPI_VERSION_2) {
+ clear_fmt_bits(davinci_spi-base, SPIFMT_WDELAY_MASK,
+ spi-chip_select);
+ set_fmt_bits(davinci_spi-base,
+ (davinci_spi-pdata-wdelay
+ SPIFMT_WDELAY_SHIFT)
+ SPIFMT_WDELAY_MASK,
+ spi-chip_select);
+
+ if (davinci_spi-pdata-odd_parity)
+ set_fmt_bits(davinci_spi-base,
+ SPIFMT_ODD_PARITY_MASK,
+ spi-chip_select);
+ else
+ clear_fmt_bits(davinci_spi-base,
+ SPIFMT_ODD_PARITY_MASK,
+ spi-chip_select);
+
+ if (davinci_spi-pdata-parity_enable)
+ set_fmt_bits(davinci_spi-base,
+ SPIFMT_PARITYENA_MASK,
+ spi-chip_select);
+ else
+ clear_fmt_bits(davinci_spi-base,
+ SPIFMT_PARITYENA_MASK,
+ spi-chip_select);
+
+ if (davinci_spi-pdata-wait_enable)
+ set_fmt_bits(davinci_spi-base,
+ SPIFMT_WAITENA_MASK,
+ spi-chip_select);
+ else
+ clear_fmt_bits(davinci_spi-base,
+ SPIFMT_WAITENA_MASK,
+ spi-chip_select);
+
+ if (davinci_spi-pdata-timer_disable)
+ set_fmt_bits(davinci_spi-base,
+ SPIFMT_DISTIMER_MASK,
+ spi-chip_select);
+ else
+ clear_fmt_bits(davinci_spi-base,
+ SPIFMT_DISTIMER_MASK,
+ spi-chip_select);
+ }
All those *_fmt_bits() ops are OK; the FMT register is specific to
a given chipselect line. And you can trust that *THIS* chipselect
is not in use when this method is called.
+
+ /* Clock internal */
+ if (davinci_spi-pdata-clk_internal)
+ set_io_bits(davinci_spi-base + SPIGCR1,
+ SPIGCR1_CLKMOD_MASK);
+ else
+ clear_io_bits(davinci_spi-base + SPIGCR1,
+ SPIGCR1_CLKMOD_MASK);
+
+ /* master mode default */
+ set_io_bits(davinci_spi-base + SPIGCR1, SPIGCR1_MASTER_MASK);
+
+ if
Re: [PATCH v3 3/3] mtd-nand: DaVinci: Add 4-bit ECC support for large page NAND chips
On Thursday 16 July 2009, nsnehapra...@ti.com wrote: It also fixes a bug in the ECC correction handler. When we introduce 5 bit-errors in chunk, error correction stops working. When errors are detected the 4BITECC_START bit was left high, which should be cleared. Agreed that needs to be fixed, but there should be a comment about this being an *undocumented* behavior in the hardware. The reason that the bug exists at all is because this step has never been documented. So, please roll in this update. - Dave --- drivers/mtd/nand/davinci_nand.c |7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/drivers/mtd/nand/davinci_nand.c +++ b/drivers/mtd/nand/davinci_nand.c @@ -350,13 +350,16 @@ compare: /* * Clear any previous address calculation by doing a dummy read of an -* error address register. +* error address register. UNDOCUMENTED that the ECC engine won't +* recover after 5-bit ECC errors without this step. */ davinci_nand_readl(info, NAND_ERR_ADD1_OFFSET); /* Start address calculation, and wait for it to complete. * We _could_ start reading more data while this is working, -* to speed up the overall page read. +* to speed up the overall page read. UNDOCUMENTED that +* reading some ERRVAL register is needed in all cases, not +* just when an error must be corrected. */ davinci_nand_writel(info, NANDFCR_OFFSET, davinci_nand_readl(info, NANDFCR_OFFSET) | BIT(13)); ___ 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 3/3] mtd-nand: DaVinci: Add 4-bit ECC support for large page NAND chips
On Friday 17 July 2009, Narnakaje, Snehaprabha wrote: Agreed that needs to be fixed, but there should be a comment about this being an *undocumented* behavior in the hardware. The reason that the bug exists at all is because this step has never been documented. So, please roll in this update. How about, we get the documents updated for this missing step. I had hoped this was in the works, but I was told that for some reason being able to do that was a problem. And in the few months since this issue was identified, the docs haven't been updated. :( - Dve ___ 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 1/6] DaVinci: SPI Driver for DaVinci and DA8xx SOC's
On Wednesday 15 July 2009, s-paul...@ti.com wrote:
arch/arm/mach-davinci/include/mach/spi.h | 45 ++
drivers/spi/Kconfig | 7 +
drivers/spi/Makefile | 1 +
drivers/spi/davinci_spi.c | 751
++
drivers/spi/davinci_spi.h | 163 +++
5 files changed, 967 insertions(+), 0 deletions(-)
It's getting a lot closer. See the appended ... the issues I
see remaining are partly performance (if you only set the FMT
register in the setup code the per-message overhead will be
a lot less) and partly functional (those per-device settings
that are treated as global, or wrongly held back on v1 parts).
Let me know if you plan to address either of those.
- Dave
CUT HERE
Minor fixes:
* get rid of global sdev ... driver should work with
more than one controller
* rename set_bits() as set_io_bits(), minimizing confusion
with standard set_bit() call; likewise clear_bits()
* Version 1 chips can also handle SPI_NO_CS
* Remove duplicate or otherwise unneeded #includes
Less-minor ones:
* Remove confusion between buses (MOSI/MISO/SCK; one per SPI
controller) and the chip-selects used to share them.
* Fix test for SPI_CPHA ...
Didn't touch:
* All the stuff in davinci_spi_bufs_prep() which really belongs
in davinci_spi_setup() ... it's just a slowdown, since the FMT
register could be written just once.
* The WDELAY and parity stuff in davinci_spi_bufs_prep() which
doesn't kick in for version 1 controllers (even though they
support it) and which is handled as *global* options instead
of per-device ones (controls are in per-device FMT registers):
(a) set it with other updates to FMT register
(b) make those per-device policies
---
drivers/spi/davinci_spi.c | 115 ++--
1 file changed, 59 insertions(+), 56 deletions(-)
--- a/drivers/spi/davinci_spi.c
+++ b/drivers/spi/davinci_spi.c
@@ -16,20 +16,14 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
-#include linux/types.h
-#include linux/io.h
-#include linux/dma-mapping.h
+#include linux/interrupt.h
#include linux/io.h
#include linux/gpio.h
-#include linux/interrupt.h
#include linux/module.h
-#include linux/device.h
#include linux/delay.h
#include linux/platform_device.h
-#include linux/device.h
#include linux/err.h
#include linux/clk.h
-#include linux/gpio.h
#include linux/spi/spi.h
#include linux/spi/spi_bitbang.h
@@ -38,7 +32,6 @@
#include davinci_spi.h
-struct device *sdev;
static void davinci_spi_rx_buf_u8(u32 data, struct davinci_spi *davinci_spi)
{
@@ -76,7 +69,7 @@ static u32 davinci_spi_tx_buf_u16(struct
return data;
}
-static inline void set_bits(void __iomem *addr, u32 bits)
+static inline void set_io_bits(void __iomem *addr, u32 bits)
{
u32 v = ioread32(addr);
@@ -84,7 +77,7 @@ static inline void set_bits(void __iomem
iowrite32(v, addr);
}
-static inline void clear_bits(void __iomem *addr, u32 bits)
+static inline void clear_io_bits(void __iomem *addr, u32 bits)
{
u32 v = ioread32(addr);
@@ -92,14 +85,14 @@ static inline void clear_bits(void __iom
iowrite32(v, addr);
}
-static inline void set_fmt_bits(void __iomem *addr, u32 bits, int bus_num)
+static inline void set_fmt_bits(void __iomem *addr, u32 bits, int cs_num)
{
- set_bits(addr + SPIFMT0 + (0x4 * bus_num), bits);
+ set_io_bits(addr + SPIFMT0 + (0x4 * cs_num), bits);
}
-static inline void clear_fmt_bits(void __iomem *addr, u32 bits, int bus_num)
+static inline void clear_fmt_bits(void __iomem *addr, u32 bits, int cs_num)
{
- clear_bits(addr + SPIFMT0 + (0x4 * bus_num), bits);
+ clear_io_bits(addr + SPIFMT0 + (0x4 * cs_num), bits);
}
/*
@@ -119,7 +112,7 @@ static void davinci_spi_chipselect(struc
* line for the controller
*/
if (value == BITBANG_CS_INACTIVE) {
- set_bits(davinci_spi-base + SPIDEF, CS_DEFAULT);
+ set_io_bits(davinci_spi-base + SPIDEF, CS_DEFAULT);
data1_reg_val |= CS_DEFAULT SPIDAT1_CSNR_SHIFT;
iowrite32(data1_reg_val, davinci_spi-base + SPIDAT1);
@@ -179,14 +172,14 @@ static int davinci_spi_setup_transfer(st
hz = spi-max_speed_hz;
clear_fmt_bits(davinci_spi-base, SPIFMT_CHARLEN_MASK,
- spi-master-bus_num);
+ spi-chip_select);
set_fmt_bits(davinci_spi-base, bits_per_word 0x1f,
- spi-master-bus_num);
+ spi-chip_select);
prescale = ((clk_get_rate(davinci_spi-clk) / hz) - 1) 0xff;
- clear_fmt_bits(davinci_spi-base, 0xff00, spi-master-bus_num);
- set_fmt_bits(davinci_spi-base, prescale 8, spi-master-bus_num);
+ clear_fmt_bits(davinci_spi-base, 0xff00, spi-chip_select);
+
Re: [PATCH 1/6] DaVinci: SPI Driver for DaVinci and DA8xx SOC's
On Thursday 16 July 2009, Paulraj, Sandeep wrote: Didn't touch: * All the stuff in davinci_spi_bufs_prep() which really belongs in davinci_spi_setup() ... it's just a slowdown, since the FMT register could be written just once. [Sandeep] I'll make change and test it across DM355, DM365 and DM6467. OK. That will matter more when DMA support gets added ... but this is the sort of structural issue that's best fixed early (IMNSHO). * The WDELAY and parity stuff in davinci_spi_bufs_prep() which doesn't kick in for version 1 controllers (even though they support it) and which is handled as *global* options instead of per-device ones (controls are in per-device FMT registers): (a) set it with other updates to FMT register (b) make those per-device policies [Sandeep] I'll tell you what the real issue is. IN reality SPI module on DM355, DM6467, DM355 and DA8xx are all different. You can maybe tell I was looking at dm365 docs for that. ;) Errata are a different story. DM355 seemed to have the worst story there. IF you a take a close look at the Dm355 SPI module guide http://focus.ti.com/lit/ug/sprued4b/sprued4b.pdf you will notice that it does not have the WDELAY and parity stuff. The DM365 IP itself is similar to DM355 so it was decided to use the version 1 string for DM365 as well. There are differences also in the diff pin modes(3,4, 5 pins) between all the different IPs. I see, then. Comments missing. :) This is the sort of thing which makes me want to put cpu_is_XXX() logic into drivers ... it's a good way to handle lots of little differences. - Dave ___ 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 1/6] DaVinci: SPI Driver for DaVinci and DA8xx SOC's
On Thursday 16 July 2009, Paulraj, Sandeep wrote: There are differences also in the diff pin modes(3,4, 5 pins) between all the different IPs. I see, then. Comments missing. :) This is the sort of thing which makes me want to put cpu_is_XXX() logic into drivers ... it's a good way to handle lots of little differences. [Sandeep] What would be your suggestion? Should I leave it for the time being? Yes. ___ 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/RFC 1/1] recover from davinci i2c time out conditions
On Wednesday 15 July 2009, Philby John wrote:
/*
+ * Configure the i2c data pin as a GPIO input and the i2c clock pin as a
+ * high GPIO output.
+ */
+static void disable_i2c_pins(void)
+{
+ unsigned long flags;
+
+ local_irq_save(flags);
+ if (cpu_is_davinci_dm355()) {
+ gpio_direction_input(15);
+ gpio_direction_output(14, 0);
+ gpio_set_value(14, 1);
As noted: gpio_direction_output(14, 1) is better.
+ davinci_cfg_reg(DM355_I2C_SDA);
+ davinci_cfg_reg(DM355_I2C_SCL);
+ }
+ local_irq_restore(flags);
+}
+
+/* Connect the i2c pins to the i2c controller. */
+static void enable_i2c_pins(void)
+{
+ unsigned long flags;
+
+ local_irq_save(flags);
+ if (cpu_is_davinci_dm355()) {
+ davinci_cfg_reg(DM355_I2C_SDA);
+ davinci_cfg_reg(DM355_I2C_SCL);
+ }
+ local_irq_restore(flags);
+}
+
+
+/* Generate a pulse on the i2c clock pin. */
+static void pulse_i2c_clock(void)
+{
+ if (cpu_is_davinci_dm355()) {
+ gpio_set_value(14, 0);
+ udelay(20);
+ gpio_set_value(14, 1);
+ udelay(20);
+ }
+}
+
The general problem with how that's done is that the SoC-specific
bits should not be in this file. The mach-davinc/dm355.c file
should hold that configuration; likewise for other SoCs.
+ /* Disable i2c */
+ disable_i2c_pins();
+ for (i = 0; i 10; i++)
+ pulse_i2c_clock();
+ /* Re-enable i2c */
+ enable_i2c_pins();
A better description of this is that you're trying to follow
the I2Cv3 instructions about how to *reset* the bus, yes?
+ i2c_davinci_init(dev);
___
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 3/5] DaVinci: DM365: Enabling SPI0 on the DM365 EVM
On Wednesday 15 July 2009, s-paul...@ti.com wrote: + .modalias = at25, + .platform_data = at25640, + .max_speed_hz = 10 * 1000 * 1000, /* at 3v3 */ + .bus_num= 0, + .chip_select= 0, + .mode = SPI_MODE_1, My copy of the at26540 data sheet says very explicitly that the chip supports only modes 0 and 3. If it doesn't work when configured for mode 0, you're hiding some kind of driver bug ... ___ 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 2/5] Davinci: DM365: Adding support for SPI in DM365 SOC
On Wednesday 15 July 2009, s-paul...@ti.com wrote:
+/*
+ * The davinci_spi_platform_data can have a chip_sel array of GPIOs
+ * For example :
+ * static u8 dm365_spi0_chip_sel[] = {23, 45, 68};
OK -- although troublesome to have *here* in two respects:
(a) No such board-specific stuff should ever get stuck into
these SoC-specific setup files.
(b) The mechanism isn't SoC-specific anyway.
I suggest a better way to do this is let the board provide
GPIO config data to the init_spi0() call, with (though you
seem to disagree) doc in the driver itself. But ...
+ * This array should then become be a part of the platform data
+ * .chip_sel = dm365_spi0_chip_sel,
+ * Appropriately change the 'num_chipselect' in the structure below
+ */
+
+static struct davinci_spi_platform_data dm365_spi0_pdata = {
...
+void __init dm365_init_spi0(unsigned chipselect_mask,
+ struct spi_board_info *info, unsigned len)
+{
+ davinci_cfg_reg(DM365_SPI0_SCLK);
+ davinci_cfg_reg(DM365_SPI0_SDI);
+ davinci_cfg_reg(DM365_SPI0_SDO);
+
+ /* not all slaves will be wired up */
+ if (chipselect_mask BIT(0))
+ davinci_cfg_reg(DM365_SPI0_SDENA0);
+ if (chipselect_mask BIT(1))
+ davinci_cfg_reg(DM365_SPI0_SDENA1);
... here you require the first two chip selects to be managed
using the standard chip select lines. So it's not handling
the GPIO scenario correctly.
All things considered ... why don't you just remove the GPIO
chipselect support for the initial merge? I agree it would
be a good thing to have-- two chipselects is weak! -- but it's
not *needed* just yet, and I'd rather not drag out this first
phase any longer.
+
+ spi_register_board_info(info, len);
+
+ platform_device_register(dm365_spi0_device);
+}
___
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 3/5] DaVinci: DM365: Enabling SPI0 on the DM365 EVM
On Wednesday 15 July 2009, Paulraj, Sandeep wrote: My copy of the at26540 data sheet says very explicitly that the chip supports only modes 0 and 3. [Sandeep] so does mine and I've had this question before. 8 months before to be precise. I have checked multiple TI sources(RBL, UBL) across multiple SOC's and even Spectrum Digital code. They all set bit 16 of the SPI format register to 1. That means phase is 1. Or more likely, that BIT(16) == !CPOL ... the dm365 SPI docs say for bit 16 0 SPI clock signal is not delayed versus the transmit/receive data stream. The first data bit is transmitted with the first clock edge and the first bit is received with the second (inverse) clock edge. 1 SPI clock signal is delayed by a half SPI clock cycle versus the transmit/receive data stream. The first transmit bit has to output prior to the first clock edge. Master and slave receive the first bit with the first edge. But for example http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus#Clock_polarity_and_phase describes CPOL=0 CPHA=0 as ... data are read on the clock's rising edge (low-high transition) and data are changed on a falling edge (high-low clock transition). Which fits the BIT(16) == !CPOL theory quite nicely, and also matches what the at25640 data sheet timing diagrams show (Figure 3 for mode 0). When I was verifying SPI on the EVM (not running Linux and just running CCS test programs) long ago, that I have had issues when the phase is not set to '1'. Understandable ... it seems BIT(16) == !CPOL, so it must be set. :) - Dave ___ 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 6/6] DaVinci: Adding SPI driver for DM3xx/DM6467/DA8xx
On Wednesday 15 July 2009, Paulraj, Sandeep wrote: [Sandeep] OK, I'll get rid of them. Can I still keep a separate davinci_spi.h header file in /drivers/spi? You already got an OK for that. Both styles are in use. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Windows usbnet driver?
On Monday 13 July 2009, Subbrathnam, Swaminathan wrote: There were some crashes relating to the RNDIS stack in 2.6.29 I do not know whether that has been resolved in 2.6.3x There have been some RNDIS bugfixes merged since 2.6.29. ___ 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 1/6] DaVinci: Header File for SPI
On Monday 13 July 2009, s-paul...@ti.com wrote: From: Sandeep Paulraj s-paul...@ti.com The patch adds a header in the /arch/arm/mach-davinci/include/mach folder for SPI. It has a structure for the platform data for SPI These patches mostly look good. I might commbine this one with #6 ... and #6 should request_irq() using pdev-dev.name so the instance ID shows up. More comments later. Signed-off-by: Sandeep Paulraj s-paul...@ti.com --- arch/arm/mach-davinci/include/mach/spi.h | 46 ++ 1 files changed, 46 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-davinci/include/mach/spi.h ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: EDMA alloc slot question
On Tuesday 14 July 2009, Paulraj, Sandeep wrote: According to dm355.c I can see channel 12 in the dma_chan_dm355_no_event Structure. Which means that *one* of the *three* ways to use channels to start DMA doesn't work ... but the other two work just fine. If you care that it has an entry in that table, you should be requesting channel 12. Not the slot that happens to be coupled to it... -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of David Brownell Sent: Monday, July 13, 2009 6:36 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: Re: EDMA alloc slot question On Monday 13 July 2009, Liu, Yan wrote: I do not understand why slot the user specified needs to be smaller than 'edma_info[ctlr]-num_channels'. In the case of dm355, this is 64. Because allocating a parameter RAM slot is different from allocating a DMA channel. If you want to allocate a channel, so so explicitly; you will also get an associated RAM slot. But by asking for a slot, you've said you want to get ONLY that RAM slot, and will be using it with some channel you have already allocated. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ 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 6/6] DaVinci: Adding SPI driver for DM3xx/DM6467/DA8xx
On Tuesday 14 July 2009, Nori, Sekhar wrote: +#define DAVINCI_SPI_T2CDELAY_SHIFT 16 +#define DAVINCI_SPI_C2TDELAY_SHIFT 24 getting rid of DAVINCI_ prefix may actually cut down the number of driver lines by half :) More like cutting the line lengths in half ... :) Agreed, that would be nicer. I'll send more comments later; maybe not today though. ___ 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 6/6] DaVinci: Adding SPI driver for DM3xx/DM6467/DA8xx
On Tuesday 14 July 2009, Nori, Sekhar wrote:
+ if (int_status DAVINCI_SPIFLG_TIMEOUT_MASK) {
+ printk(KERN_ERR SPI Time-out Error\n);
+ ret = -1;
dev_err will be more suitable (if possible)
Yes, very possible. But thes should be dev_dbg(), and
the return codes should be a negative errno that's passed
up the stack.
- Dave
___
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 6/6] DaVinci: Adding SPI driver for DM3xx/DM6467/DA8xx
On Monday 13 July 2009, s-paul...@ti.com wrote:
The patch adds support for SPI driver for DaVinci
DM355/DM365/DM6467 and DA8xx
Comments-in-the-form-of-a-patch below ... I figured this
could expedite things. :)
- Dave
===
Various bits of cleanup for the davinci_spi driver:
- Kconfig should never have default y
- Reorder #includes ... standard stuff should go first
- Remove pointless inlines
- Remove needless (and sometimes unused) #defines
- Declare the special SPI_* modes which are supported!
- Whitespace fixes
- Update busy-wait loops
- Streamline op_mode setup
- ... more
NOT ADDRESSED:
- The printk(KERN_ERR ...) messages that should be dev_dbg(...)
- The use of -1 error codes instead of negative errno
- Timing out busy-wait loops
- Adding a comment explaining that either built-in chipselects
*or* GPIO versions may be used. (If GPIO, can up to 4 slaves
be supported?)
---
drivers/spi/Kconfig |1
drivers/spi/davinci_spi.c | 142
drivers/spi/davinci_spi.h | 42 +
3 files changed, 59 insertions(+), 126 deletions(-)
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -81,7 +81,6 @@ config SPI_DAVINCI
tristate SPI controller driver for DaVinci SoC
depends on SPI_MASTER ARCH_DAVINCI
select SPI_BITBANG
- default y
help
SPI master controller for DaVinci SPI modules.
--- a/drivers/spi/davinci_spi.c
+++ b/drivers/spi/davinci_spi.c
@@ -17,11 +17,10 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
-#include davinci_spi.h
+#include linux/types.h
+#include linux/io.h
#include linux/dma-mapping.h
#include linux/io.h
-#include mach/mux.h
-#include mach/gpio.h
#include linux/interrupt.h
#include linux/module.h
#include linux/device.h
@@ -29,9 +28,17 @@
#include linux/platform_device.h
#include linux/err.h
#include linux/clk.h
+#include linux/gpio.h
-static inline void davinci_spi_rx_buf_u8(u32 data,
-struct davinci_spi *davinci_spi)
+#include linux/spi/spi.h
+#include linux/spi/spi_bitbang.h
+
+#include mach/spi.h
+
+#include davinci_spi.h
+
+
+static void davinci_spi_rx_buf_u8(u32 data, struct davinci_spi *davinci_spi)
{
u8 *rx = davinci_spi-rx;
@@ -39,8 +46,7 @@ static inline void davinci_spi_rx_buf_u8
davinci_spi-rx = rx;
}
-static inline void davinci_spi_rx_buf_u16(u32 data,
- struct davinci_spi *davinci_spi)
+static void davinci_spi_rx_buf_u16(u32 data, struct davinci_spi *davinci_spi)
{
u16 *rx = davinci_spi-rx;
@@ -48,7 +54,7 @@ static inline void davinci_spi_rx_buf_u1
davinci_spi-rx = rx;
}
-static inline u32 davinci_spi_tx_buf_u8(struct davinci_spi *davinci_spi)
+static u32 davinci_spi_tx_buf_u8(struct davinci_spi *davinci_spi)
{
u32 data;
const u8 *tx = davinci_spi-tx;
@@ -58,7 +64,7 @@ static inline u32 davinci_spi_tx_buf_u8(
return data;
}
-static inline u32 davinci_spi_tx_buf_u16(struct davinci_spi *davinci_spi)
+static u32 davinci_spi_tx_buf_u16(struct davinci_spi *davinci_spi)
{
u32 data;
const u16 *tx = davinci_spi-tx;
@@ -71,6 +77,7 @@ static inline u32 davinci_spi_tx_buf_u16
static inline void set_bits(void __iomem *addr, u32 bits)
{
u32 v = ioread32(addr);
+
v |= bits;
iowrite32(v, addr);
}
@@ -78,6 +85,7 @@ static inline void set_bits(void __iomem
static inline void clear_bits(void __iomem *addr, u32 bits)
{
u32 v = ioread32(addr);
+
v = ~bits;
iowrite32(v, addr);
}
@@ -114,7 +122,7 @@ static void davinci_spi_chipselect(struc
if (pdata-chip_sel != NULL) {
for (i = 0; i pdata-num_chipselect; i++) {
if (pdata-chip_sel[i] != DAVINCI_SPI_INTERN_CS)
- __gpio_set_value(pdata-chip_sel[i], 1);
+ gpio_set_value(pdata-chip_sel[i], 1);
}
}
@@ -123,10 +131,9 @@ static void davinci_spi_chipselect(struc
data1_reg_val |= CS_DEFAULT DAVINCI_SPIDAT1_CSNR_SHIFT;
iowrite32(data1_reg_val, davinci_spi-base + SPIDAT1);
- while (1)
- if (ioread32(davinci_spi-base + SPIBUF)
-DAVINCI_SPIBUF_RXEMPTY_MASK)
- break;
+ while ((ioread32(davinci_spi-base + SPIBUF)
+DAVINCI_SPIBUF_RXEMPTY_MASK) == 0)
+ cpu_relax();
}
}
@@ -309,67 +316,21 @@ static int davinci_spi_bufs_prep(struct
iowrite32(DAVINCI_SPI_INTLVL_0, davinci_spi-base + SPILVL);
/*
-* The driver uses new flags SPI_NO_CS and SPI_RAEDY
-* These can be found in
Re: [PATCH 6/6] DaVinci: Adding SPI driver for DM3xx/DM6467/DA8xx
On Tuesday 14 July 2009, Paulraj, Sandeep wrote: David, Thanks for the patch. I'll trying to send updates ASAP. I have just a few questions though. IS it OK if I continue to use DAVINCI_ in my #defines. It's OK. You're maintaining it, not me. :) I think we should because these are used only in DaVinci. I had a look at the mmc driver for DaVinci and it is full of such #define with DAVINCI_ I wouldn't have used them there either. Those prefixes are superfluous; using them adds nothing. And a few more below -Original Message- From: David Brownell [mailto:davi...@pacbell.net] Sent: Tuesday, July 14, 2009 12:54 PM To: davinci-linux-open-source@linux.davincidsp.com Cc: Paulraj, Sandeep Subject: Re: [PATCH 6/6] DaVinci: Adding SPI driver for DM3xx/DM6467/DA8xx On Monday 13 July 2009, s-paul...@ti.com wrote: The patch adds support for SPI driver for DaVinci DM355/DM365/DM6467 and DA8xx Comments-in-the-form-of-a-patch below ... I figured this could expedite things. :) - Dave === Various bits of cleanup for the davinci_spi driver: - Kconfig should never have default y - Reorder #includes ... standard stuff should go first - Remove pointless inlines - Remove needless (and sometimes unused) #defines - Declare the special SPI_* modes which are supported! - Whitespace fixes - Update busy-wait loops - Streamline op_mode setup - ... more NOT ADDRESSED: - The printk(KERN_ERR ...) messages that should be dev_dbg(...) [Sandeep] I'll address - The use of -1 error codes instead of negative errno [Sandeep] What would be the most appropriate error value. What if I use -EADV that is for advertise error. If it is not appropriate then can you suggest a more appropriate return value Look at each error and return an appropriate error. Like -ETIMEDOUT for a timeout ... this driver doesn't advertise anything so -EADV will be meaningless. - Timing out busy-wait loops [Sandeep] OK - Adding a comment explaining that either built-in chipselects *or* GPIO versions may be used. (If GPIO, can up to 4 slaves be supported?) [Sandeep] The most ideal place for this explanation would be in a wiki page at wiki.davincidsp.com. No; add at least a mention of the issue here. HOWTO, yeah that could go into a wiki. But I will still add an explanation for this in dm355.c and dm365.c and not in the driver. Why put it in two places, when one (driver) suffices? :) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Windows usbnet driver?
On Monday 13 July 2009, Dave Munch wrote: Can you recommend a windows ethernet over usb solution that will allow our windows application to communicate with our new davinci based product across USB via usbnet? One should avoid Microsoft's RNDIS stuff; it's known to crash, do bluescreens, and the like. It sort-of-works, but not well (at least, not without information that doesn't seem to be very available to the public). I'm told that MCCI's drivers can work pretty well. They have both proprietary and standard (CDC Ethernet) solutions. - Dave ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: EDMA alloc slot question
On Monday 13 July 2009, Liu, Yan wrote: I do not understand why slot the user specified needs to be smaller than 'edma_info[ctlr]-num_channels'. In the case of dm355, this is 64. Because allocating a parameter RAM slot is different from allocating a DMA channel. If you want to allocate a channel, so so explicitly; you will also get an associated RAM slot. But by asking for a slot, you've said you want to get ONLY that RAM slot, and will be using it with some channel you have already allocated. ___ 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 3/3] ASoC: davinci: clock pointers instead of clock names
On Monday 13 July 2009, Kevin Hilman wrote: grepping in sound/soc for clk_get, all the users of clk_get have hard-coded clock names, which is exactly what we do not want for DaVinci. The problem we have on DaVinci is trying to use the same driver across multiple SoCs that may have different clock names. Or have multiple instances of the driver with different clock names on the same SoC. I've lost something here ... c = clk_get(device, logical_name); should work regardless of the physical name used by the clock(s) on a given platform, yes? The last time I looked at ASoc, the problem I recall was that the device wasn't a standard platform device; it had to be an ASoC-created thing. And that's where the problems came from: there was no hook make sure the lookup above returned the right clock, since the device was unknown to the clock tree. Either that should help clarify something, or else it should sow more confusion. I hope the former. ;) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: spi master and slave device and driver
On Monday 06 July 2009, 邹卫军 wrote: But when I want to register the mcp2510's spi driver, I find that this driver can not find the proper spi device to attach(The spi device registered in spi_bus is attached to the spidev drivers). One device, one driver. *EITHER* use spidev from userspace, or some kernel driver from inside the kernel. ___ 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 1/2] davinci: Add cpufreq support
On Monday 06 July 2009, Sekhar Nori wrote: The patch implements cpufreq driver, support to change PLL output rate and recalculation of the rates of PLL derived clocks It seems to me this is missing some sanity checks. First, that the DRAM isn't being clocked through this PLL... since changing the PLL would imply recalculating all of its timings, and might require running the re-clock from SRAM. Second, similar issues crop up with every clock derived from that same PLL. If you change the clock going into the MMC controller, that can require recalculating the dividers used to clock the MMC/SD card it's talking to. Now, those are issues the clock framework handles poorly. So I don't think there are likely to be easy fixes for those PLL recalc problems ... unless I missed something. It might be simpler to just restrict a first pass of this to changing dividers for the ARM's clock. Also, this patch is doing two separate things. One is adding clk_set_rate() support for PLLs. The other is matching $SUBJECT. Better to split those two. (And notice how your patch [2/2] hit that second issue already, with the UART2 clock getting goofed ...) - Dave ___ 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/11 - v3] ARM: DaVinci: Video: DM355/DM6446 VPFE Capture driver
On Monday 29 June 2009, Yusuf Caglar AKYUZ wrote: BTW, does this tree includes musb patches which was submitted to usb mailing list. but yet not included in mainline and davinci trees? Can you please be more specific which musb patches you are referring to? I must admit that I lost track of musb patches. Currently I see: * One keyboard and mouse at the same time does not work. I remember seeing some mentioning of improvements to the interrupt end points on the list. * DMA is not usable and transfer speeds are so slow. I guess I need to check some archives. That stuff is in mainline, but hasn't yet been pulled down into the DaVinci tree. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: why cann't i use kernel RTC(DS1672) ?
On Wednesday 01 July 2009, Bjørn Forsman wrote: when i reboot my kernel and i read the datatime it is the old time 1970-01-01 00:00:00,why it cann't read time from ds1672? I think that the command line utility 'date' does not write to hardware. You should use the 'hwclock' utility for that. And ... make sure the drivers/rtc/rtc-ds1672.c driver is configured, along with the CONFIG_RTC_HCTOSYS, setting up to use that RTC when booting. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: debug tools for uboot on DM365 EVM
On Wednesday 01 July 2009, Tao Wu wrote: Hi, Can anyone suggest a jtag emulator to debug uboot on DM365 EVM? I have a XDS 510USB jtag. But that works in CCS. I do not know whether it has software like bdigdb. I've hooked up one of the inexpensive FT2232 based ones, with OpenOCD. Haven't *also* hooked up GDB, but that should just work. That may be part of what you need. It's probably a bit rough if you're used to supported products like bdigdb, CCS, or the Lauterbach tools. But the low cost should help make up for that. :) ___ 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 3/3 - v0] davinci: platform changes to support vpfe camera capture
On Tuesday 30 June 2009, Karicheri, Muralidharan wrote: The code that I am developing is most up to date and is written against the latest tree. If you insist. Regardless, the $SUBJECT patch had some significant problems (against current code) and should not merge. ___ 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] RFC: ARM: DaVinci: ASoc use iram to buffer sound
On Tuesday 30 June 2009, Steve Chen wrote: Can you try aplay -D hw:0,1 r441_c2.wav If you see something like Warning: rate is not accurate (requested = 44100Hz, got = 48000Hz) please, try the plug plugin That means McBSP/AIC33 are not setup to handle sample rate of 44.1K directly. The sample rates are covered by software. The problem is likely in the area of rate conversion. And ... seeking someone who has a bit of spare time, a DM6446 EVM, and interest in solving it: that EVM can switch audio clocking at runtime, among six different sample rates (of which those are two). So it would be interesting to get that working. :) If you don't see the warning, McBSP/AIC33 is setup to handle 44.1K directly. You man want to check with clock settings (make sure AIC33 is setup as the master). ___ 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 3/3 - v0] davinci: platform changes to support vpfe camera capture
On Monday 29 June 2009, Karicheri, Muralidharan wrote:
snip
-static struct tvp514x_platform_data tvp5146_pdata = {
- .clk_polarity = 0,
- .hs_polarity = 1,
- .vs_polarity = 1
Clearly this patch is against neither mainline nor the
current DaVinci GIT tree... I suggest reissuing against
mainline, now that it's got most DM355 stuff.
That is because, I have my first (vpfe capture version v3)
patch lined up for merge to upstream/davinci git kernel ...
NOTE: Depends on v3 version of vpfe capture driver patch
What is your suggestion in such cases?
Always submit against mainline. In the handfull of cases
that won't work (e.g. depends on code that's not there),
submit against the DaVinci tree.
+static const struct i2c_device_id dm355evm_msp_ids[] = {
+ { dm355evm_msp, 0, },
+ { /* end of list */ },
+};
Needless to say: NAK on all this. There is already a
drivers/mfd/dm355evm_msp.c managing this device. You
shouldn't have video code crap all over it.
It currently sets up for TVP5146 based capture iff that
driver is configured (else the external imager); and
exports the NTSC/nPAL switch setting as a GPIO that's
also visible in sysfs.
I suggest the first revision of this VPFE stuff use
the existing setup. A later patch could add some
support for runtime reconfiguration.
I didn't know that you have a video code crap added to
drivers/mfd/dm355evm_msp.c :)
:)
It's just setting up everything the msp430 touches,
so the board is in a known sane state. Standard
stuff for initialization code.
The first patch is already out and is using TVP5146.
So I will investigate your msp driver and see how I
can support run time configuring the input.
If you have any suggestion let me know.
Wondering why you chose to make msp driver dm355
specific? MSP430 is available on dm6446 and dm355, right?
The MSP430 is a microcontroller family. The firmware used
on each board is extremely board-specific. On DM355 EVM,
the firmware's I2C interface was at least sanely structured.
- Dave
___
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 3/3 - v0] davinci: platform changes to support vpfe camera capture
On Monday 29 June 2009, Karicheri, Muralidharan wrote: I think you didn't get my point. We have patches that are in the pipeline waiting for merge that is neither available in the upstream nor in the DaVinci tree. The linux-media pipeline. Sure. I'm quite familiar with what it means to have pathes depending on others, which are headed upstream by different merge queues. That gets merged to upstream at some point in future and also will get rebased to DaVinci later. But If I need to make patches based on them (like this one) it can be done only by applying the patches to the DaVinci tree and then creating new patches based on that. That is why my note clearly says Depends on v3 version of vpfe capture driver patch Maybe you're not getting my point: that submitting a patch series against mainline (or almost-mainline) means you don't trip across goofs like the one I first noted. That one was pretty obvious. The more subtle problems are harder to see... In this case, your patch ignored a driver that's been in GIT since December. Which means that you're developing against a code base that's ... pretty old, not nearly current enough. I fully understand that all this video stuff is a large and complex chunk of driver code. That's *ALL THE MORE REASON* to be sure you're tracking mainline (or in some cases the DaVinci platform code) very closely when you send patches upstream. Because all kinds of stuff will have changed between six months ago and today. Standard policy is to develop such merge patches with more or less bleeding edge code, so integration issues show up (and get resolved) ASAP. I can't believe the current linux-media or V4L2 trees are six months out of date. - Dave ___ 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 3/3 - v0] davinci: platform changes to support vpfe camera capture
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -136,10 +136,66 @@ static void dm355evm_mmcsd_gpios(unsigned gpio)
dm355evm_mmc_gpios = gpio;
}
-static struct tvp514x_platform_data tvp5146_pdata = {
- .clk_polarity = 0,
- .hs_polarity = 1,
- .vs_polarity = 1
Clearly this patch is against neither mainline nor the
current DaVinci GIT tree... I suggest reissuing against
mainline, now that it's got most DM355 stuff.
+/*
+ * MSP430 supports RTC, card detection, input from IR remote, and
+ * a bit more. It triggers interrupts on GPIO(7) from pressing
+ * buttons on the IR remote, and for card detect switches.
+ */
+static struct i2c_client *dm355evm_msp;
+
+static int dm355evm_msp_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ dm355evm_msp = client;
+ return 0;
+}
+
+static int dm355evm_msp_remove(struct i2c_client *client)
+{
+ dm355evm_msp = NULL;
+ return 0;
+}
+
+static const struct i2c_device_id dm355evm_msp_ids[] = {
+ { dm355evm_msp, 0, },
+ { /* end of list */ },
+};
Needless to say: NAK on all this. There is already a
drivers/mfd/dm355evm_msp.c managing this device. You
shouldn't have video code crap all over it.
It currently sets up for TVP5146 based capture iff that
driver is configured (else the external imager); and
exports the NTSC/nPAL switch setting as a GPIO that's
also visible in sysfs.
I suggest the first revision of this VPFE stuff use
the existing setup. A later patch could add some
support for runtime reconfiguration.
- Dave
+
+static struct i2c_driver dm355evm_msp_driver = {
+ .driver.name= dm355evm_msp,
+ .id_table = dm355evm_msp_ids,
+ .probe = dm355evm_msp_probe,
+ .remove = dm355evm_msp_remove,
+};
+
___
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/5] davinci: This patch series ports PWM driver from 2.6.10 tree.
On Thursday 25 June 2009, Yusuf Caglar AKYUZ wrote: BTW, I'm not aware of any PWM kernel infrastructure. While porting this driver I looked into to kernel tree but I couldn't find anything related to. linux/pwm.h ... pretty minimal, and ISTR PXA-centric, but it can be evolved. ___ 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-git] davinci: dm365 gpio irq support
From: David Brownell dbrown...@users.sourceforge.net
Support DM365 GPIOs ... primarily by handling non-banked GPIO IRQs:
- Flag DM365 chips as using non-banked GPIO interrupts, using a
new soc_info field.
- Replace the gpio_to_irq() mapping logic. This now uses some
runtime infrastructure, keyed off that new soc_info field,
which doesn't handle irq_to_gpio().
- Provide a new irq_chip ... GPIO IRQs handled directly by AINTC
still need edge triggering managed by the GPIO controller.
DM365 chips no longer falsely report 104 GPIO IRQs as they boot.
Intelligence about IRQ muxing is missing, so for the moment this
only exposes the first eight DM365 GPIOs, which are never muxed.
The next eight are muxed, half with Ethernet (which uses most of
those pins anyway).
Tested on DM355 (10 unbanked IRQs _or_ 104 banked ones) and also
on DM365 (16 unbanked ones, only 8 made available).
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
arch/arm/mach-davinci/dm365.c |3
arch/arm/mach-davinci/gpio.c| 105 --
arch/arm/mach-davinci/include/mach/common.h |1
arch/arm/mach-davinci/include/mach/gpio.h |8 -
4 files changed, 105 insertions(+), 12 deletions(-)
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -878,7 +878,8 @@ static struct davinci_soc_info davinci_s
.timer_info = dm365_timer_info,
.gpio_base = IO_ADDRESS(DAVINCI_GPIO_BASE),
.gpio_num = 104,
- .gpio_irq = 44,
+ .gpio_irq = IRQ_DM365_GPIO0,
+ .gpio_unbanked = 8,/* really 16 ... skip muxed GPIOs */
.serial_dev = dm365_serial_device,
.emac_pdata = dm365_emac_pdata,
.sram_dma = 0x0001,
--- a/arch/arm/mach-davinci/gpio.c
+++ b/arch/arm/mach-davinci/gpio.c
@@ -34,6 +34,7 @@ static DEFINE_SPINLOCK(gpio_lock);
struct davinci_gpio {
struct gpio_chipchip;
struct gpio_controller *__iomem regs;
+ int irq_base;
};
static struct davinci_gpio chips[DIV_ROUND_UP(DAVINCI_N_GPIO, 32)];
@@ -161,8 +162,7 @@ pure_initcall(davinci_gpio_setup);
* used as output pins ... which is convenient for testing.
*
* NOTE: The first few GPIOs also have direct INTC hookups in addition
- * to their GPIOBNK0 irq, with a bit less overhead but less flexibility
- * on triggering (e.g. no edge options). We don't try to use those.
+ * to their GPIOBNK0 irq, with a bit less overhead.
*
* All those INTC hookups (direct, plus several IRQ banks) can also
* serve as EDMA event triggers.
@@ -171,7 +171,7 @@ pure_initcall(davinci_gpio_setup);
static void gpio_irq_disable(unsigned irq)
{
struct gpio_controller *__iomem g = get_irq_chip_data(irq);
- u32 mask = __gpio_mask(irq_to_gpio(irq));
+ u32 mask = (u32) get_irq_data(irq);
__raw_writel(mask, g-clr_falling);
__raw_writel(mask, g-clr_rising);
@@ -180,7 +180,7 @@ static void gpio_irq_disable(unsigned ir
static void gpio_irq_enable(unsigned irq)
{
struct gpio_controller *__iomem g = get_irq_chip_data(irq);
- u32 mask = __gpio_mask(irq_to_gpio(irq));
+ u32 mask = (u32) get_irq_data(irq);
unsigned status = irq_desc[irq].status;
status = IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING;
@@ -196,7 +196,7 @@ static void gpio_irq_enable(unsigned irq
static int gpio_irq_type(unsigned irq, unsigned trigger)
{
struct gpio_controller *__iomem g = get_irq_chip_data(irq);
- u32 mask = __gpio_mask(irq_to_gpio(irq));
+ u32 mask = (u32) get_irq_data(irq);
if (trigger ~(IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING))
return -EINVAL;
@@ -260,6 +260,45 @@ gpio_irq_handler(unsigned irq, struct ir
/* now it may re-trigger */
}
+static int gpio_to_irq_banked(struct gpio_chip *chip, unsigned offset)
+{
+ struct davinci_gpio *d = container_of(chip, struct davinci_gpio, chip);
+
+ if (d-irq_base = 0)
+ return d-irq_base + offset;
+ else
+ return -ENODEV;
+}
+
+static int gpio_to_irq_unbanked(struct gpio_chip *chip, unsigned offset)
+{
+ struct davinci_soc_info *soc_info = davinci_soc_info;
+
+ /* NOTE: we assume for now that only irqs in the first gpio_chip
+* can provide direct-mapped IRQs to AINTC (up to 32 GPIOs).
+*/
+ if (offset soc_info-gpio_unbanked)
+ return soc_info-gpio_irq + offset;
+ else
+ return -ENODEV;
+}
+
+static int gpio_irq_type_unbanked(unsigned irq, unsigned trigger)
+{
+ struct gpio_controller *__iomem g = get_irq_chip_data(irq);
+ u32 mask = (u32) get_irq_data(irq);
+
+ if (trigger ~(IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING))
+ return -EINVAL;
+
+ __raw_writel(mask, (trigger
Re: [RFC][PATCH] DM365 RTC Support
On Sunday 21 June 2009, s-paul...@ti.com wrote: +#define DM365_RTC_BASE 0x01c69000 This is actually the PRTCIF, which is used by more than just the RTC. I think there should be - a small mach-davinci/prtcif.c module that maps this region and exports accessor routines; - and a mach/prtcif.c module declaring those accessors plus maybe the dm365 registers in the prtcif module. That prtcif.c might be a reasonable place to package the support for the 11 GPIOs exported by that module, I guess. There's not much to be done with those on the EVM, since most of them go to the CPLD which then ignores them. But updated VHDL there, or another board, might well need to use those GPIOs or their IRQs. - Dave ___ 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: minor edma cleanup
From: David Brownell dbrown...@users.sourceforge.net Minor EDMA cleanup: remove unused SoC-specific #define; and when requesting the channel controller region, use the device's name (to be more useful on chips with multiple such controllers). Signed-off-by: David Brownell dbrown...@users.sourceforge.net --- arch/arm/mach-davinci/dma.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) --- a/arch/arm/mach-davinci/dma.c +++ b/arch/arm/mach-davinci/dma.c @@ -100,8 +100,6 @@ #define EDMA_SHADOW0 0x2000 /* 4 regions shadowing global channels */ #define EDMA_PARM 0x4000 /* 128 param entries */ -#define DAVINCI_DMA_3PCC_BASE 0x01C0 - #define PARM_OFFSET(param_no) (EDMA_PARM + ((param_no) 5)) #define EDMA_MAX_DMACH 64 @@ -1209,7 +1207,7 @@ static int __init edma_probe(struct plat len = r-end - r-start + 1; - r = request_mem_region(r-start, len, r-name); + r = request_mem_region(r-start, len, dev_name(pdev-dev)); if (!r) return -EBUSY; ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[patch] remove ancient NAND_ECC_HWx_y symbols
From: David Brownell dbrown...@users.sourceforge.net
Remove some remnants of ancient NAND code that have been
lingering in the DaVinci tree ... so this tree is a closer
match to mainline.
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
drivers/mtd/nand/nand_base.c |7 ---
include/linux/mtd/nand.h |7 ---
2 files changed, 14 deletions(-)
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2671,13 +2671,6 @@ int nand_scan_tail(struct mtd_info *mtd)
*/
switch (chip-ecc.mode) {
-#ifdef CONFIG_NAND_FLASH_HW_ECC
- case NAND_ECC_HW12_2048:
- case NAND_ECC_HW8_512:
- case NAND_ECC_HW6_512:
- case NAND_ECC_HW3_512:
- case NAND_ECC_HW3_256:
-#endif
case NAND_ECC_HW:
/* Use standard hwecc read page function ? */
if (!chip-ecc.read_page)
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -121,13 +121,6 @@ typedef enum {
NAND_ECC_SOFT,
NAND_ECC_HW,
NAND_ECC_HW_SYNDROME,
-#ifdef CONFIG_NAND_FLASH_HW_ECC
- NAND_ECC_HW3_256,
- NAND_ECC_HW3_512,
- NAND_ECC_HW6_512,
- NAND_ECC_HW8_512,
- NAND_ECC_HW12_2048,
-#endif
} nand_ecc_modes_t;
/*
___
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] DM365 EDMA Support
On Saturday 20 June 2009, s-paul...@ti.com wrote:
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -93,6 +93,20 @@ static void dm365evm_emac_configure(void)
davinci_cfg_reg(DM365_INT_EMAC_MISCPULSE);
}
+static void dm365evm_edma_configure(void)
+{
+ /*
+ * EDMA interrupts are multiplexed
+ * Details are available at the DM365 ARM
+ * Subsystem Users Guide(sprufg5.pdf) pages 133 - 134
+ */
+ davinci_cfg_reg(DM365_INT_EDMA_CC);
+ davinci_cfg_reg(DM365_INT_EDMA_TC0_ERR);
+ davinci_cfg_reg(DM365_INT_EDMA_TC1_ERR);
+ davinci_cfg_reg(DM365_INT_EDMA_TC2_ERR);
+ davinci_cfg_reg(DM365_INT_EDMA_TC3_ERR);
The TC_ERR handlers are still NOPs, so I suspect they're
not worth enabling for now. EDMA_CC is needed for all
boards ... I suggest just doing this muxing in dm365.c
with some mask as a parameter saying what to enable.
(That is, if the TC_ERR stuff is even needed.)
+}
+
static void __init evm_init_i2c(void)
{
davinci_init_i2c(i2c_pdata);
@@ -116,6 +130,7 @@ static __init void dm365_evm_init(void)
davinci_serial_init(uart_config);
dm365evm_emac_configure();
+ dm365evm_edma_configure();
soc_info-emac_pdata-phy_mask = DM365_EVM_PHY_MASK;
soc_info-emac_pdata-mdio_max_freq = DM365_EVM_MDIO_FREQUENCY;
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RFC][PATCH] DM365 RTC Support
On Monday 22 June 2009, Paulraj, Sandeep wrote: The DM365 EVM does not have a battery so when on resetting the EVM by doing a power reset you lose the date and time information. The registers were lost *without* a power reset. That is, with either (a) reboot from command line, or (b) pressing the reset button. No loss of power. That's why I was surprised: no loss of power, but the RTC acted as if there were one. Chapter 10 of the ARM guide (SPRUFG5) says PRTCSS has only a power-on-reset -- PWRST is the signal, from a tps65510 chip on the EVM, which is not going to be issued except on board power-up without a backup battery (or presumably, with a dead battery). Would having PERI_CLKCTL.PRTCSSCLKS set wrong matter? Or is the RTC probe() maybe resetting things? You need a battery backup running for the date and time info to be saved. Date and time info are erased on power reset. If you're saying that normal no-power-loss resets also cause RTC re-init, maybe because the chip or board is designed to act that way, it's worth mentioning that surprise in the driver's Kconfig entry. - Dave Without the battery and mains, no information is retained and all registers, including RTC_SEC, RTC_MIN , RTC_HOUR , RTC_DAY0 and RTC_DAY1 which store date and time info are reset to default values. You are seeing January 1, 2000 because the driver initializes it to that value -Original Message- From: David Brownell [mailto:davi...@pacbell.net] Sent: Sunday, June 21, 2009 8:50 PM To: davinci-linux-open-source@linux.davincidsp.com Cc: Paulraj, Sandeep Subject: Re: [RFC][PATCH] DM365 RTC Support This RTC resets to January 1, 2000 when I reboot. How to stop that behavior? ___ 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] MMC/SD Support for DM365 EVM
On Monday 22 June 2009, Paulraj, Sandeep wrote: MMC0 seems OK, but MMC1 doesn't work most of the time. I've seen it enumerate a few cards ... but mostly it just fails. Lots of MMC1 IRQs though. Are you sure the pinmux is correct? [Sandeep] I just tried 3 SD cards and all worked fine. I tried SD, SDHC, and MMC cards. SDHC and MMC did not enumerate at all in that slot. SD usually doesn't, but did a couple times ... but then when I removed it, the card refused to enumerate a second time. This is with just your first eight patches, applied in the order you sent them. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RFC][PATCH] DM365 Keypad Support
On Sunday 21 June 2009, s-paul...@ti.com wrote: In the mean while i'd like comments on the driver itself. CC drivers/input/keyboard/dm365evm_keypad.o drivers/input/keyboard/dm365evm_keypad.c: In function 'dm365_kp_probe': drivers/input/keyboard/dm365evm_keypad.c:112: warning: unused variable 'val' :) Since it is DM365 EVM specific, i add all the structures in the board specific file rather than the DM365 SOC file Look at how the OMAP drivers handle this. It should *NOT* be a board-specific driver. Use platform_data to feed in a table that maps scan codes (from the hardware) to symbolic keycodes. The next dm365 board should be able to re-use this driver and just feed it a different table. This is a different situation from the dm355 keypad, which is highly specific to that board's msp430 firmware. - Dave ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RFC][PATCH] DM365 RTC Support
On Sunday 21 June 2009, s-paul...@ti.com wrote: I would also like comments on where i am registering the RTC Driver for DM365. At present i register the RTC device in SOC specific file(dm365.c). RTC INTMUX should most probably be done in some other way than what i am doing at the moment. I'd just add a comment that the alternative for INT 29 is getting a DDR2 EMIF interrupt, in case anyone gets interested in handling such things. Unless they do, I can't see any reason not to handle it this way. I Added this just before registering the RTC. Did some basic testing using this driver. hwclock command works. Also transitions between months/years/leap years has been verified Try the rtctest.c at the end of Documentation/rtc.txt too, that's the closest thing there is to a real test harness. The once-per-second IRQs (first test case!) don't work. A quick glance at docs suggests this RTC doesn't offer such IRQs, just alarms on hour/minute/day match. If so, you should reject the once-per-second IRQs... - Dave ___ 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] MMC/SD Support for DM365 EVM
On Saturday 20 June 2009, s-paul...@ti.com wrote: Patch adds support for MMC/SD in the DM365 EVM. Pinmux for MMC/SD slot 1 on the DM365 EVM is also configured. MMC0 seems OK, but MMC1 doesn't work most of the time. I've seen it enumerate a few cards ... but mostly it just fails. Lots of MMC1 IRQs though. Are you sure the pinmux is correct? ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
