SanDisk MMC card timeouts
[Added Steven Sakoman to the CC list] Hi, We're seeing timeout errors with SanDisk MMC cards and a 2.6.32 kernel (BeagleBoard Rev C5). The suggested fix of setting dto timeout to 14 (http://www.mail-archive.com/linux-omap@vger.kernel.org/msg42214.html) doesn't help. Any other suggestions with any familiar with this issue? The errors seem to be entering logs from mmc_blk_issue_rw_rq in drivers/mmc/card/block.c Here is a boot log: --- Texas Instruments X-Loader 1.5.0 (Jun 14 2011 - 22:04:07) Beagle xM Reading boot sector Loading u-boot.bin from mmc U-Boot 2011.03-rc1-0-g9a3cc57-dirty (Apr 01 2011 - 17:41:42) OMAP3630/3730-GP ES2.1, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz OMAP3 Beagle board + LPDDR/NAND I2C: ready DRAM: 512 MiB NAND: 0 MiB MMC: OMAP SD/MMC: 0 *** Warning - readenv() failed, using default environment In:serial Out: serial Err: serial Beagle xM Rev C No EEPROM on expansion board Die ID #73f600029ff8015f26ad0f025029 Hit any key to stop autoboot: 3 2 1 0 The user button is currently NOT pressed. SD/MMC found on device 0 reading uEnv.txt 622 bytes read Loaded environment from uEnv.txt Importing environment from mmc ... Running uenvcmd ... Device nand0 not found! Loading file /boot/MLO from mmc device 0:2 (xxa2) 23852 bytes read Error: Can't switch ecc, no devices available no devices available no devices available Loading file /boot/u-boot.bin from mmc device 0:2 (xxa2) 284788 bytes read Error: Can't switch ecc, no devices available no devices available no devices available Loading file /boot/uImage from mmc device 0:2 (xxa2) 3202868 bytes read Error: Can't switch ecc, no devices available no devices available no devices available Saving Environment to NAND... Erasing Nand... Attempt to erase non page aligned data writing root fs after booting Loading file /boot/uImage from mmc device 0:2 (xxa2) 3202868 bytes read Booting from mmc ... ## Booting kernel from Legacy Image at 8020 ... Image Name: Angstrom/2.6.32/beagleboard Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3202804 Bytes = 3.1 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux. done, booting the kernel. [0.00] Linux version 2.6.32 (joel@chase-ubuntu) (gcc version 4.3.3 (GCC) ) #3 PREEMPT Fri Jul 15 17:30:31 CDT 2011 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7f [0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [0.00] Machine: OMAP3 Beagle Board [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] OMAP3630/DM3730 ES1.0 (l2cache iva sgx neon isp 192mhz_clk ) [0.00] SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x10 [0.00] Reserving 12582912 bytes SDRAM for VRAM [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 [0.00] Kernel command line: console=ttyS2,115200n8 mpurate=auto buddy=none camera=none vram=12M omapfb.mode=dvi:640x480MR-16@60 omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait [0.00] Beagle expansionboard: none [0.00] Beagle cameraboard: none [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Memory: 256MB 256MB = 512MB total [0.00] Memory: 500352KB available (5900K code, 673K data, 204K init, 0K highmem) [0.00] Hierarchical RCU implementation. [0.00] NR_IRQS:402 [0.00] Clocking rate (Crystal/Core/MPU): 26.0/332/600 MHz [0.00] Reprogramming SDRC clock to 33200 Hz [0.00] GPMC revision 5.0 [0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts [0.00] Total of 96 interrupts on 1 active controller [0.00] OMAP GPIO hardware version 2.5 [0.00] OMAP clockevent source: GPTIMER12 at 32768 Hz [0.00] Console: colour dummy device 80x30 [0.00] Calibrating delay loop... 501.02 BogoMIPS (lpj=1957888) [0.00] Mount-cache hash table entries: 512 [0.00] CPU: Testing write buffer coherency: ok [0.00] tmpfs: No value for mount option 'mode' [0.00] devtmpfs: initialized [0.00] regulator: core version 0.5 [0.00] NET: Registered protocol family 16 [0.00] OMAP3 Beagle Rev: xM C [0.00] Found NAND on CS0 [0.00] Registering NAND on CS0 [0.00] Unable to get DVI reset GPIO [0.00] omap_init_mbox: platform not supported [ 11.337036] OMAP DMA hardware revision 5.0 [
SanDisk MMC card timeouts
Hi, We're seeing MMC timeout errors with SanDisk MMC cards and a 2.6.32 kernel (BeagleBoard Rev C5). The suggested fix of setting dto timeout to 14 (http://www.mail-archive.com/linux-omap@vger.kernel.org/msg42214.html) doesn't help. Any other suggestions with any familiar with this issue? The errors seem to be entering logs from mmc_blk_issue_rw_rq in drivers/mmc/card/block.c Here is a boot log: --- Texas Instruments X-Loader 1.5.0 (Jun 14 2011 - 22:04:07) Beagle xM Reading boot sector Loading u-boot.bin from mmc U-Boot 2011.03-rc1-0-g9a3cc57-dirty (Apr 01 2011 - 17:41:42) OMAP3630/3730-GP ES2.1, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz OMAP3 Beagle board + LPDDR/NAND I2C: ready DRAM: 512 MiB NAND: 0 MiB MMC: OMAP SD/MMC: 0 *** Warning - readenv() failed, using default environment In:serial Out: serial Err: serial Beagle xM Rev C No EEPROM on expansion board Die ID #73f600029ff8015f26ad0f025029 Hit any key to stop autoboot: 3 2 1 0 The user button is currently NOT pressed. SD/MMC found on device 0 reading uEnv.txt 622 bytes read Loaded environment from uEnv.txt Importing environment from mmc ... Running uenvcmd ... Device nand0 not found! Loading file /boot/MLO from mmc device 0:2 (xxa2) 23852 bytes read Error: Can't switch ecc, no devices available no devices available no devices available Loading file /boot/u-boot.bin from mmc device 0:2 (xxa2) 284788 bytes read Error: Can't switch ecc, no devices available no devices available no devices available Loading file /boot/uImage from mmc device 0:2 (xxa2) 3202868 bytes read Error: Can't switch ecc, no devices available no devices available no devices available Saving Environment to NAND... Erasing Nand... Attempt to erase non page aligned data writing root fs after booting Loading file /boot/uImage from mmc device 0:2 (xxa2) 3202868 bytes read Booting from mmc ... ## Booting kernel from Legacy Image at 8020 ... Image Name: Angstrom/2.6.32/beagleboard Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3202804 Bytes = 3.1 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux. done, booting the kernel. [0.00] Linux version 2.6.32 (joel@chase-ubuntu) (gcc version 4.3.3 (GCC) ) #3 PREEMPT Fri Jul 15 17:30:31 CDT 2011 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7f [0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [0.00] Machine: OMAP3 Beagle Board [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] OMAP3630/DM3730 ES1.0 (l2cache iva sgx neon isp 192mhz_clk ) [0.00] SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x10 [0.00] Reserving 12582912 bytes SDRAM for VRAM [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 [0.00] Kernel command line: console=ttyS2,115200n8 mpurate=auto buddy=none camera=none vram=12M omapfb.mode=dvi:640x480MR-16@60 omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait [0.00] Beagle expansionboard: none [0.00] Beagle cameraboard: none [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Memory: 256MB 256MB = 512MB total [0.00] Memory: 500352KB available (5900K code, 673K data, 204K init, 0K highmem) [0.00] Hierarchical RCU implementation. [0.00] NR_IRQS:402 [0.00] Clocking rate (Crystal/Core/MPU): 26.0/332/600 MHz [0.00] Reprogramming SDRC clock to 33200 Hz [0.00] GPMC revision 5.0 [0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts [0.00] Total of 96 interrupts on 1 active controller [0.00] OMAP GPIO hardware version 2.5 [0.00] OMAP clockevent source: GPTIMER12 at 32768 Hz [0.00] Console: colour dummy device 80x30 [0.00] Calibrating delay loop... 501.02 BogoMIPS (lpj=1957888) [0.00] Mount-cache hash table entries: 512 [0.00] CPU: Testing write buffer coherency: ok [0.00] tmpfs: No value for mount option 'mode' [0.00] devtmpfs: initialized [0.00] regulator: core version 0.5 [0.00] NET: Registered protocol family 16 [0.00] OMAP3 Beagle Rev: xM C [0.00] Found NAND on CS0 [0.00] Registering NAND on CS0 [0.00] Unable to get DVI reset GPIO [0.00] omap_init_mbox: platform not supported [ 11.337036] OMAP DMA hardware revision 5.0 [ 11.343322] bio: create slab
Re: [beagleboard] SanDisk MMC card timeouts
Op 18 jul 2011, om 08:30 heeft Joel A Fernandes het volgende geschreven: Hi, We're seeing MMC timeout errors with SanDisk MMC cards and a 2.6.32 kernel (BeagleBoard Rev C5). Does the same happen with a more recent, e.g. 2.6.39 kernel? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] dmaengine: add dma_ctrl_cmd to pass buffer stride configuration
-Original Message-
From: Jassi Brar [mailto:jassisinghb...@gmail.com]
Sent: Tuesday, July 12, 2011 6:15 PM
To: Raju, Sundaram
Cc: Linus Walleij; linux-arm-ker...@lists.infradead.org; linux-
ker...@vger.kernel.org; davinci-linux-open-sou...@linux.davincidsp.com;
li...@arm.linux.org.uk; dan.j.willi...@intel.com; linux-omap@vger.kernel.org
Subject: Re: [PATCH] dmaengine: add dma_ctrl_cmd to pass buffer stride
configuration
On Tue, Jul 12, 2011 at 5:01 PM, Raju, Sundaram sunda...@ti.com wrote:
-Original Message-
From: Jassi Brar [mailto:jassisinghb...@gmail.com]
Sent: Tuesday, July 12, 2011 4:51 PM
To: Linus Walleij
Cc: Raju, Sundaram; linux-arm-ker...@lists.infradead.org; linux-
ker...@vger.kernel.org; davinci-linux-open-sou...@linux.davincidsp.com;
li...@arm.linux.org.uk; dan.j.willi...@intel.com; linux-
o...@vger.kernel.org
Subject: Re: [PATCH] dmaengine: add dma_ctrl_cmd to pass buffer stride
configuration
On Tue, Jul 12, 2011 at 3:33 PM, Linus Walleij linus.wall...@linaro.org
wrote:
On Tue, Jul 12, 2011 at 6:17 AM, Jassi Brar jassisinghb...@gmail.com
wrote:
1) Striding, in one form or other, is supported by other DMACs as well.
The number will only increase in future.
Are we to add VENDOR_DMA_STRIDE_CONFIG for each case ?
If we are sure about this and striding will work in a similar way on all
then let's have the enum named DMA_STRIDE_CONFIG and move the
passed-in struct to linux/dmaengine.h) then?
Would that be:
struct dma_stride_config {
u32 read_bytes;
u32 skip_bytes;
};
Or something more complex?
Well, I am not sure if striding needs any special treatment at all.
Why not have client drivers prepare and submit sg-list.
Let the DMAC drivers interpret/parse the sg-list and program it
as strides if the h/w supports it.
If anything, we should make preparation and submission of sg-list
as efficient as possible.
Jassi,
sg_lists describe only a bunch of disjoint buffers. But what if the
DMAC can skip and read the bytes within each of the buffers in
the sg_list? (like TI EDMAC and TI SDMAC)
How can that information be passed to the offload
engine driver from the client?
OK, I overlooked.
We do need something new to handle these ultra-fine-grained sg-lists.
But still we shouldn't add SoC specific API to the common sub-systems.
Maybe a new api to pass fixed-format variable-length encoded message
to the DMAC drivers?
Which could be interpreted by DMAC drivers to extract all the needed xfer
parameters from the 'header' section and instructions to program the xfers
in the DMAC from the variable length body of the 'message' buffer.
It might sound complicated but we can have helpers to make the job easy.
Btw, the regular single/sg-list xfers could also be expressed by this method.
Do you expect this variable length body of the message to be DMAC
independent? I don't think so. In that case how is this different from what
we have here already?
If it can be DMAC independent, can you illustrate more on how this can
be done? But the point to note is, if this can be made DMAC independent
then the control command we have also can be made DMAC independent
by generalizing the configuration structure passed to it.
~ Sundaram
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
Re: conflicts between omap/cleanup branch and omap_dss2 tree
* Arnd Bergmann a...@arndb.de [110717 14:36]: Hi Paul and Tomi, I'm trying to get the arm-soc tree integrated into linux-next, but right now that fails because of lots of conflicts in the arch/arm/mach-omap2/clock44xx_data.c and arch/arm/mach-omap2/omap_hwmod_44xx_data.c files. I've done a dumb resolution by pulling in the omap_dss2/for_next tree as a depedency and taking Tomi's version of the files, which is probably wrong but lets Stephen at least take the arm-soc tree. Yes that's the wrong way around for these files.. Please fix this properly in either the omap or the omap_dss2 trees. The clock and hwmod data patches should get queued by Benoit and Paul, so I'm suspecting these are some of Tomi's patches still in development. Tomi can you please check what you have in for-next? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 0/5] OMAP SMPS regulator driver
* Tero Kristo t-kri...@ti.com [110713 06:56]: Hello, Based on the comments for the previous version of this set, I implemented a regulator driver for the OMAP SMPS now. It could actually be moved under arch/arm/mach-omap2/ directory instead of drivers/regulator, I think it should work from there also. This would also require less hacking for the header files. Any thoughts on this? If it's a driver it should be under drivers/ then. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] join omap4panda and pcm049
* Jan Weitzel j.weit...@phytec.de [110715 09:01]: First try to join both boards. Only compile testet. basis for discusson Jan Weitzel (2): omap4: board-omap4panda: prepare for join omap4: board-omap4panda: join Phytec phyCORE-OMAP4 arch/arm/mach-omap2/Kconfig |6 + arch/arm/mach-omap2/board-omap4panda.c | 817 +++--- arch/arm/plat-omap/include/plat/uncompress.h |1 + 3 files changed, 616 insertions(+), 208 deletions(-) Thanks for working on this. To me it seems that it might be more readable to have board-panda-common.c file instead of having everything in one file. Then from the board specific files you could just call panda_common_init(omap4_panda_config). Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] dt: omap3: add generic board file for dt support
* Grant Likely grant.lik...@secretlab.ca [110716 22:08]: The way I see it, you've got two options: 1) modify the of_platform_bus_create() to call some kind of of_platform_bus_create_omap() for devices that match ti,omap3-device or something. 2) Leave of_platform_bus_create(), and instead us a notifier to attach hwmod data to normal platform devices. omap_device_build() is actually pretty simple. It allocated a device, it attaches platform_data and hwmod pointers to the device and registers it. omap_device_register() is just a wrapper around platform_device_register(). My preference is definitely #2, but there is a wrinkle in this approach. Unfortunately omap_devices are not simply plain platform_devices with extra data attached, an omap_device actually embeds the platform_device inside it, which cannot be attached after the fact. I think I had talked with Kevin (cc'd) about eliminating the embedding, but I cannot remember clearly on this point. As long as platform_device remains embedded inside struct omap_device, #2 won't work. In either case, looking up the correct hwmod data should be easy for any device provided the omap code maintains a lookup table of compatible strings and base addresses of devices (much like auxdata). In fact, I'd be okay with extending auxdata to include OMAP fields if that would be easiest since the whole point of auxdata is to ease the transition to DT support. When a matching device is created, the hwmod pointer can easily be attached. This should work transparently for all omap devices, not just the i2c bus. Well we should be able to automgagically build the omap_device for each device tree entry. And then the device driver probe and runtime PM should be able to take care of the rest for the driver. And then there's no more driver specific platform init code needed ;) How about if we just have the hwmod code call omap_device_build for each device tree entry? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] dt: omap3: add generic board file for dt support
Hi Grant,
On 17 July 2011 10:43, Grant Likely grant.lik...@secretlab.ca wrote:
Hi Manjunath,
Comments below. I left in a lot of context for the new folks that
I've cc'd (Tony and Kevin).
On Sat, Jul 16, 2011 at 2:07 PM, G, Manjunath Kondaiah manj...@ti.com wrote:
On Thu, Jul 14, 2011 at 4:45 AM, Grant Likely grant.lik...@secretlab.ca
wrote:
+static void __init omap3_init(void)
+{
+ struct device_node *node;
+
[...]
+static struct omap_device *of_omap_i2c_device_create(struct device_node
*node,
+ const char *bus_id,
+ void *platform_data,
+ struct device *parent)
+{
+ struct platform_device *pdev;
+ struct i2c_board_info *i2c_board_info;
+ u8 id;
+
+ printk(Creating omap i2c device %s\n, node-full_name);
+
+ if (!of_device_is_available(node))
+ return NULL;
+
+ id = simple_strtol(bus_id, NULL, 0);
+ pdev = kzalloc(sizeof(*pdev), GFP_KERNEL);
+ pdev-dev.of_node = of_node_get(node);
+ if (!pdev-dev.of_node) {
+ speed = 100;
+ } else {
+ u32 prop;
+ if (!of_property_read_u32(pdev-dev.of_node,
clock-frequency,
+
prop))
+ speed = prop/100;
+ else
+ speed = 100;
+ }
+ printk(%s : speed-%d\n,__func__, speed);
+
+ for_each_child_of_node(bus, child) {
+ u32 prop;
+
+ printk( create child: %s\n, child-full_name);
+ i2c_board_info = kzalloc(sizeof(*i2c_board_info),
GFP_KERNEL);
+ if (!of_property_read_u32(pdev-dev.of_node, reg,
+ prop))
+ i2c_board_info-addr = prop;
+ if (!of_property_read_u32(pdev-dev.of_node, interrupts,
+ prop))
+ i2c_board_info-irq = prop;
+ i2c_board_info-platform_data = platform_data;
+ strncpy(i2c_board_info-type, child-name,
+ sizeof(i2c_board_info-type));
+ }
+ omap_register_i2c_bus(id, speed, i2c_board_info, 1);
While this does in a sense work, and creates an omap_device for the
i2c bus that does get probed, it ends up encoding an awful lot of
device specific details into the generic devicetree support code. The
i2c bus driver itself must be responsible for decoding the speed and
child nodes, and in fact it can easily be modified to do so (I've
Decoding speed in i2c driver seems to be fine. But the i2c child nodes are
board specific. We might bring board specific handling code into i2c driver
with this approach.
BTW, I have observed that, if we create i2c device node in omapx-soc.dtsi
file and the define i2c bus clock-frequency in beagle.dts, the clock-frequency
is not available in driver probe. Is this expected behavior?
-M
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 01/11] OMAP: prcm: switch to a chained IRQ handler mechanism
On Fri, 2011-07-15 at 18:40 +0200, Todd Poynor wrote:
On Tue, Jul 05, 2011 at 01:27:47PM +0300, Tero Kristo wrote:
Introduce a chained interrupt handler mechanism for the PRCM
interrupt, so that individual PRCM event can cleanly be handled by
handlers in separate drivers. We do this by introducing PRCM event
names, which are then matched to the particular PRCM interrupt bit
depending on the specific OMAP SoC being used.
arch/arm/mach-omap2/prcm.c implements the chained interrupt mechanism
itself, with individual PRCM events for OMAP3 and OMAP4 being
described in arch/arm/mach-omap2/prcm3xxx.c and
arch/arm/mach-omap2/prcm4xxx.c respectively. At initialization time,
the set of PRCM events is filtered against the SoC on which we are
running, keeping only the ones that are actually useful. All the logic
is written to be generic with regard to OMAP3/OMAP4, even though OMAP3
has single PRCM event registers and OMAP4 has two PRCM event
registers.
...
+
+ prcm_wkup_irq = omap_prcm_event_to_irq(wkup);
+ prcm_io_irq = omap_prcm_event_to_irq(io);
Should check error return for both.
Not needed, the next calls for request_irq will fail if these do not
succeed (attempting to request irq with invalid number.)
Rest of the return value checks I can add to the next version of this
set.
+
+ ret = request_irq(prcm_wkup_irq, _prcm_int_handle_wakeup,
+ IRQF_NO_SUSPEND | IRQF_DISABLED, prcm_wkup, NULL);
...
+ for (i = 0; i = max_irq / 32; i++) {
+ gc = irq_alloc_generic_chip(PRCM, 1,
+ irq_setup-base_irq + i * 32, NULL, handle_level_irq);
+
Should check NULL return for out of memory.
+ ct = gc-chip_types;
...
+ /* Copy setup from __initdata section */
+ irq_setup = kmalloc(sizeof(struct omap_prcm_irq_setup), GFP_KERNEL);
Check NULL return.
+ memcpy(irq_setup, setup, sizeof(struct omap_prcm_irq_setup));
+
+ irqs = kmalloc(sizeof(struct omap_prcm_irq) *
+ setup-num_irqs, GFP_KERNEL);
Check NULL return.
+ memcpy(irqs, setup-irqs, sizeof(struct omap_prcm_irq) *
+ setup-num_irqs);
Todd
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap1: select GENERIC_IRQ_CHIP for TI OMAP1
Axel Lin axel@gmail.com writes: 2011/6/28 Kevin Hilman khil...@ti.com: Axel Lin axel@gmail.com writes: The gpio-omap driver has been converted to use generic IRQ chip. Thus select GENERIC_IRQ_CHIP for TI OMAP1 to fix below build error. LD vmlinux drivers/built-in.o: In function `omap_mpuio_alloc_gc': drivers/gpio/gpio-omap.c:1087: undefined reference to `irq_alloc_generic_chip' drivers/gpio/gpio-omap.c:1100: undefined reference to `irq_setup_generic_chip' drivers/built-in.o: In function `omap_gpio_show_rev': drivers/gpio/gpio-omap.c:998: undefined reference to `irq_gc_mask_clr_bit' drivers/gpio/gpio-omap.c:998: undefined reference to `irq_gc_mask_set_bit' make: *** [vmlinux] Error 1 Signed-off-by: Axel Lin axel@gmail.com Thanks, I have a fix for this already queued for v3.0-rc3 series: http://marc.info/?l=linux-omapm=130749135312468w=2 Seems this patch is not upstream. I still have the same build error with [linux-next: Tree for July 16]. Hmm, you're right. Tony hasn't queued that fix yet. Tony? Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 0/6] OMAP SMPS regulator driver
Hello, Main changes compared to v2: - cleanup should now work better - register all available regulators always, if no initdata = readonly - added board init support functionality to twl-common - constraints not touched by the driver anymore Tested on omap3 beagle. -Tero Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 1/6] OMAP: move voltage.h and vp.h under platform include directory
This is needed so that these include files can be accessed from drivers.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/voltage.h | 180 -
arch/arm/mach-omap2/vp.h | 128
arch/arm/plat-omap/include/plat/voltage.h | 179
arch/arm/plat-omap/include/plat/vp.h | 128
4 files changed, 307 insertions(+), 308 deletions(-)
delete mode 100644 arch/arm/mach-omap2/voltage.h
delete mode 100644 arch/arm/mach-omap2/vp.h
create mode 100644 arch/arm/plat-omap/include/plat/voltage.h
create mode 100644 arch/arm/plat-omap/include/plat/vp.h
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
deleted file mode 100644
index 38a0145..000
--- a/arch/arm/mach-omap2/voltage.h
+++ /dev/null
@@ -1,180 +0,0 @@
-/*
- * OMAP Voltage Management Routines
- *
- * Author: Thara Gopinath th...@ti.com
- *
- * Copyright (C) 2009 Texas Instruments, Inc.
- * Thara Gopinath th...@ti.com
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#ifndef __ARCH_ARM_MACH_OMAP2_VOLTAGE_H
-#define __ARCH_ARM_MACH_OMAP2_VOLTAGE_H
-
-#include linux/err.h
-
-#include vc.h
-#include vp.h
-
-struct powerdomain;
-
-/* XXX document */
-#define VOLTSCALE_VPFORCEUPDATE1
-#define VOLTSCALE_VCBYPASS 2
-
-/*
- * OMAP3 GENERIC setup times. Revisit to see if these needs to be
- * passed from board or PMIC file
- */
-#define OMAP3_CLKSETUP 0xff
-#define OMAP3_VOLTOFFSET 0xff
-#define OMAP3_VOLTSETUP2 0xff
-
-/**
- * struct omap_vfsm_instance - per-voltage manager FSM register/bitfield
- * data
- * @voltsetup_mask: SETUP_TIME* bitmask in the PRM_VOLTSETUP* register
- * @voltsetup_reg: register offset of PRM_VOLTSETUP from PRM base
- * @voltsetup_shift: SETUP_TIME* field shift in the PRM_VOLTSETUP* register
- *
- * XXX What about VOLTOFFSET/VOLTCTRL?
- * XXX It is not necessary to have both a _mask and a _shift for the same
- * bitfield - remove one!
- */
-struct omap_vfsm_instance {
- u32 voltsetup_mask;
- u8 voltsetup_reg;
- u8 voltsetup_shift;
-};
-
-/**
- * struct voltagedomain - omap voltage domain global structure.
- * @name: Name of the voltage domain which can be used as a unique identifier.
- * @scalable: Whether or not this voltage domain is scalable
- * @node: list_head linking all voltage domains
- * @pwrdm_node: list_head linking all powerdomains in this voltagedomain
- * @vdd: to be removed
- * @pwrdms: powerdomains in this voltagedomain
- * @scale: function used to scale the voltage of the voltagedomain
- * @curr_volt: current nominal voltage for this voltage domain
- */
-struct voltagedomain {
- char *name;
- bool scalable;
- struct list_head node;
- struct list_head pwrdm_list;
- struct omap_vc_channel *vc;
- const struct omap_vfsm_instance *vfsm;
- struct omap_vp_instance *vp;
- struct omap_voltdm_pmic *pmic;
-
- /* VC/VP register access functions: SoC specific */
- u32 (*read) (u8 offset);
- void (*write) (u32 val, u8 offset);
- u32 (*rmw)(u32 mask, u32 bits, u8 offset);
-
- union {
- const char *name;
- u32 rate;
- } sys_clk;
-
- int (*scale) (struct voltagedomain *voltdm,
- unsigned long target_volt);
- u32 curr_volt;
- struct omap_volt_data *volt_data;
-};
-
-/**
- * struct omap_volt_data - Omap voltage specific data.
- * @voltage_nominal: The possible voltage value in uV
- * @sr_efuse_offs: The offset of the efuse register(from system
- * control module base address) from where to read
- * the n-target value for the smartreflex module.
- * @sr_errminlimit:Error min limit value for smartreflex. This value
- * differs at differnet opp and thus is linked
- * with voltage.
- * @vp_errorgain: Error gain value for the voltage processor. This
- * field also differs according to the voltage/opp.
- */
-struct omap_volt_data {
- u32 volt_nominal;
- u32 sr_efuse_offs;
- u8 sr_errminlimit;
- u8 vp_errgain;
-};
-
-/**
- * struct omap_voltdm_pmic - PMIC specific data required by voltage driver.
- * @slew_rate: PMIC slew rate (in uv/us)
- * @step_size: PMIC voltage step size (in uv)
- * @i2c_high_speed: whether VC uses I2C high-speed mode to PMIC
- * @i2c_mcode: master code value for I2C high-speed preamble transmission
- * @vsel_to_uv:PMIC API to convert vsel value to actual voltage in uV.
- * @uv_to_vsel:PMIC API to convert voltage in uV to vsel value.
- */
-struct omap_voltdm_pmic {
- int slew_rate;
- int step_size;
-
[PATCHv3 2/6] omap: voltage: change code to use new location of voltage.h and vp.h
These are now under plat-omap/include/plat. Signed-off-by: Tero Kristo t-kri...@ti.com --- arch/arm/mach-omap2/io.c |2 +- arch/arm/mach-omap2/omap_opp_data.h |3 +-- arch/arm/mach-omap2/omap_twl.c|2 +- arch/arm/mach-omap2/pm.c |2 +- arch/arm/mach-omap2/powerdomain.h |3 +-- arch/arm/mach-omap2/prm2xxx_3xxx.c|3 +-- arch/arm/mach-omap2/prm44xx.c |2 +- arch/arm/mach-omap2/smartreflex.h |2 +- arch/arm/mach-omap2/sr_device.c |2 +- arch/arm/mach-omap2/vc.c |2 +- arch/arm/mach-omap2/vc3xxx_data.c |2 +- arch/arm/mach-omap2/vc44xx_data.c |2 +- arch/arm/mach-omap2/voltage.c |3 +-- arch/arm/mach-omap2/voltagedomains2xxx_data.c |2 +- arch/arm/mach-omap2/voltagedomains3xxx_data.c |3 +-- arch/arm/mach-omap2/voltagedomains44xx_data.c |3 +-- arch/arm/mach-omap2/vp.c |4 ++-- arch/arm/mach-omap2/vp3xxx_data.c |3 +-- arch/arm/mach-omap2/vp44xx_data.c |4 +--- 19 files changed, 20 insertions(+), 29 deletions(-) diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c index 4c8a5de..b151fca 100644 --- a/arch/arm/mach-omap2/io.c +++ b/arch/arm/mach-omap2/io.c @@ -31,6 +31,7 @@ #include plat/sram.h #include plat/sdrc.h #include plat/serial.h +#include plat/voltage.h #include clock2xxx.h #include clock3xxx.h @@ -38,7 +39,6 @@ #include io.h #include plat/omap-pm.h -#include voltage.h #include powerdomain.h #include clockdomain.h diff --git a/arch/arm/mach-omap2/omap_opp_data.h b/arch/arm/mach-omap2/omap_opp_data.h index c784c12..4d93209 100644 --- a/arch/arm/mach-omap2/omap_opp_data.h +++ b/arch/arm/mach-omap2/omap_opp_data.h @@ -20,8 +20,7 @@ #define __ARCH_ARM_MACH_OMAP2_OMAP_OPP_DATA_H #include plat/omap_hwmod.h - -#include voltage.h +#include plat/voltage.h /* * *BIG FAT WARNING*: diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c index f515a1a..b9720a0 100644 --- a/arch/arm/mach-omap2/omap_twl.c +++ b/arch/arm/mach-omap2/omap_twl.c @@ -18,7 +18,7 @@ #include linux/kernel.h #include linux/i2c/twl.h -#include voltage.h +#include plat/voltage.h #include pm.h diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c index 659e400..699d347 100644 --- a/arch/arm/mach-omap2/pm.c +++ b/arch/arm/mach-omap2/pm.c @@ -18,8 +18,8 @@ #include plat/omap-pm.h #include plat/omap_device.h #include plat/common.h +#include plat/voltage.h -#include voltage.h #include powerdomain.h #include clockdomain.h #include pm.h diff --git a/arch/arm/mach-omap2/powerdomain.h b/arch/arm/mach-omap2/powerdomain.h index 2c685a5..2ae9236 100644 --- a/arch/arm/mach-omap2/powerdomain.h +++ b/arch/arm/mach-omap2/powerdomain.h @@ -23,8 +23,7 @@ #include linux/atomic.h #include plat/cpu.h - -#include voltage.h +#include plat/voltage.h /* Powerdomain basic power states */ #define PWRDM_POWER_OFF0x0 diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c b/arch/arm/mach-omap2/prm2xxx_3xxx.c index 3b83763..e096c76 100644 --- a/arch/arm/mach-omap2/prm2xxx_3xxx.c +++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c @@ -19,8 +19,7 @@ #include plat/common.h #include plat/cpu.h #include plat/prcm.h - -#include vp.h +#include plat/vp.h #include prm2xxx_3xxx.h #include cm2xxx_3xxx.h diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c index 495a31a..5979803 100644 --- a/arch/arm/mach-omap2/prm44xx.c +++ b/arch/arm/mach-omap2/prm44xx.c @@ -20,8 +20,8 @@ #include plat/common.h #include plat/cpu.h #include plat/prcm.h +#include plat/vp.h -#include vp.h #include prm44xx.h #include prm-regbits-44xx.h #include prcm44xx.h diff --git a/arch/arm/mach-omap2/smartreflex.h b/arch/arm/mach-omap2/smartreflex.h index 5f35b9e..fe9b242 100644 --- a/arch/arm/mach-omap2/smartreflex.h +++ b/arch/arm/mach-omap2/smartreflex.h @@ -22,7 +22,7 @@ #include linux/platform_device.h -#include voltage.h +#include plat/voltage.h /* * Different Smartreflex IPs version. The v1 is the 65nm version used in diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c index 2782d3f..bc08751 100644 --- a/arch/arm/mach-omap2/sr_device.c +++ b/arch/arm/mach-omap2/sr_device.c @@ -23,9 +23,9 @@ #include linux/io.h #include plat/omap_device.h +#include plat/voltage.h #include smartreflex.h -#include voltage.h #include control.h #include pm.h diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c index aa9f0bc..2c8bc24 100644 --- a/arch/arm/mach-omap2/vc.c +++ b/arch/arm/mach-omap2/vc.c @@ -3,8 +3,8 @@ #include linux/init.h #include plat/cpu.h +#include plat/voltage.h -#include voltage.h #include vc.h #include prm-regbits-34xx.h #include prm-regbits-44xx.h diff --git a/arch/arm/mach-omap2/vc3xxx_data.c
[PATCHv3 3/6] regulator: omap smps regulator driver
OMAP SMPS regulator driver provides access to OMAP voltage processor
controlled regulators. These include VDD_MPU and VDD_CORE for OMAP3 and
additionally VDD_IVA for OMAP4. SMPS regulators use the OMAP voltage
layer for the actual voltage regulation operations.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Todd Poynor toddpoy...@google.com
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Liam Girdwood l...@ti.com
---
drivers/regulator/Kconfig |9 ++
drivers/regulator/Makefile |1 +
drivers/regulator/omap-smps-regulator.c | 180 +++
include/linux/regulator/omap-smps.h | 20
4 files changed, 210 insertions(+), 0 deletions(-)
create mode 100644 drivers/regulator/omap-smps-regulator.c
create mode 100644 include/linux/regulator/omap-smps.h
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index d7ed20f..bb18ff2 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -303,5 +303,14 @@ config REGULATOR_TPS65910
help
This driver supports TPS65910 voltage regulator chips.
+config REGULATOR_OMAP_SMPS
+ tristate TI OMAP SMPS Power Regulators
+ depends on (ARCH_OMAP3 || ARCH_OMAP4) PM TWL4030_CORE
+ help
+ This driver supports the OMAP3 / OMAP4 SMPS regulators for VDD1,
+ VDD2 and VDD3. These regulators reside inside the TWL4030 /
+ TWL6030 chip but are accessed using the voltage processor
+ interface of OMAP.
+
endif
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 3932d2e..191e3d5 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -43,5 +43,6 @@ obj-$(CONFIG_REGULATOR_ISL6271A) += isl6271a-regulator.o
obj-$(CONFIG_REGULATOR_AB8500) += ab8500.o
obj-$(CONFIG_REGULATOR_DB8500_PRCMU) += db8500-prcmu.o
obj-$(CONFIG_REGULATOR_TPS65910) += tps65910-regulator.o
+obj-$(CONFIG_REGULATOR_OMAP_SMPS) += omap-smps-regulator.o
ccflags-$(CONFIG_REGULATOR_DEBUG) += -DDEBUG
diff --git a/drivers/regulator/omap-smps-regulator.c
b/drivers/regulator/omap-smps-regulator.c
new file mode 100644
index 000..8b56e4f
--- /dev/null
+++ b/drivers/regulator/omap-smps-regulator.c
@@ -0,0 +1,179 @@
+/*
+ * omap-vp-regulator.c -- support SMPS regulators for OMAP chips
+ *
+ * Copyright (C) 2011 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.
+ */
+
+#include linux/kernel.h
+#include linux/ctype.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/init.h
+#include linux/err.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/regulator/driver.h
+#include linux/regulator/machine.h
+#include linux/regulator/omap-smps.h
+#include plat/voltage.h
+
+#define DRIVER_NAMEomap-smps
+
+struct omap_smps_reg_info {
+ const char *vdd_name;
+ struct regulator_dev*rdev;
+ struct voltagedomain*voltdm;
+ struct regulator_desc desc;
+};
+
+static int omap_smps_set_voltage(struct regulator_dev *rdev, int min_uV,
+ int max_uV, unsigned *selector)
+{
+ struct omap_smps_reg_info *info = rdev_get_drvdata(rdev);
+ return voltdm_scale(info-voltdm, min_uV);
+}
+
+static int omap_smps_get_voltage(struct regulator_dev *rdev)
+{
+ struct omap_smps_reg_info *info = rdev_get_drvdata(rdev);
+ return omap_vp_get_curr_volt(info-voltdm);
+}
+
+static struct regulator_ops omap_smps_ops = {
+ .set_voltage= omap_smps_set_voltage,
+ .get_voltage= omap_smps_get_voltage,
+};
+
+#define SMPS_REG(name) { \
+ .vdd_name = #name, \
+ .desc = { \
+ .ops = omap_smps_ops, \
+ .type = REGULATOR_VOLTAGE, \
+ .owner = THIS_MODULE, \
+ }, \
+ }
+
+static struct omap_smps_reg_info omap_smps_regs[] = {
+ SMPS_REG(mpu),
+ SMPS_REG(mpu_iva),
+ SMPS_REG(iva),
+ SMPS_REG(core),
+};
+
+static void omap_smps_reg_cleanup(void)
+{
+ int i;
+ struct omap_smps_reg_info *info;
+
+ for (i = 0; i ARRAY_SIZE(omap_smps_regs); i++) {
+ info = omap_smps_regs[i];
+ if (info-rdev) {
+ regulator_unregister(info-rdev);
+ info-rdev = NULL;
+ }
+
+ kfree(info-desc.name);
+ info-desc.name = NULL;
+ }
+}
+
+static struct regulator_init_data dummy_initdata __initdata;
+
+static int __devinit omap_smps_reg_probe(struct platform_device *pdev)
+{
+ int i, j, ret;
+ struct omap_smps_reg_info
[PATCHv3 5/6] omap3: beagleboard: add SMPS regulators
This is using the common API defined in twl-common.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 32f5f89..d493b0b 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -444,6 +444,8 @@ static struct platform_device keys_gpio = {
},
};
+static struct platform_device beagle_smps;
+
static void __init omap3_beagle_init_early(void)
{
omap2_init_common_infrastructure();
@@ -459,6 +461,7 @@ static void __init omap3_beagle_init_irq(void)
static struct platform_device *omap3_beagle_devices[] __initdata = {
leds_gpio,
keys_gpio,
+ beagle_smps,
};
static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
@@ -533,6 +536,7 @@ static void __init omap3_beagle_init(void)
gpio_buttons[0].gpio = beagle_config.usr_button_gpio;
+ omap3_pmic_get_smps_config(beagle_smps);
platform_add_devices(omap3_beagle_devices,
ARRAY_SIZE(omap3_beagle_devices));
omap_display_init(beagle_dss_data);
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 4/6] omap3: pmic: add API to get common SMPS regulators
omap3_pmic_get_smps_config can now be used to get regulator configuration
for MPU and CORE SMPS regulators. This should be expanded later to add IVA
SMPS regulator for OMAP4.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/twl-common.c | 62 ++
arch/arm/mach-omap2/twl-common.h | 14
2 files changed, 76 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index 2543342..dc36053 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -23,8 +23,10 @@
#include linux/i2c.h
#include linux/i2c/twl.h
#include linux/gpio.h
+#include linux/slab.h
#include linux/regulator/machine.h
#include linux/regulator/fixed.h
+#include linux/regulator/omap-smps.h
#include plat/i2c.h
#include plat/usb.h
@@ -302,3 +304,63 @@ void __init omap3_pmic_get_config(struct
twl4030_platform_data *pmic_data,
if (regulators_flags TWL_COMMON_REGULATOR_VPLL2 !pmic_data-vpll2)
pmic_data-vpll2 = omap3_vpll2_idata;
}
+
+static struct regulator_consumer_supply omap_smps_mpu_iva_supply[] = {
+ REGULATOR_SUPPLY(vcc, mpu_iva),
+};
+
+static struct regulator_consumer_supply omap_smps_core_supply[] = {
+ REGULATOR_SUPPLY(vcc, core),
+};
+
+static struct regulator_init_data omap_smps_mpu_iva = {
+ .constraints = {
+ .min_uV = 60,
+ .max_uV = 145,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(omap_smps_mpu_iva_supply),
+ .consumer_supplies = omap_smps_mpu_iva_supply,
+};
+
+static struct regulator_init_data omap_smps_core = {
+ .constraints = {
+ .min_uV = 60,
+ .max_uV = 145,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(omap_smps_core_supply),
+ .consumer_supplies = omap_smps_core_supply,
+};
+
+void omap_pmic_get_smps_config(struct platform_device *smps_dev,
+ u32 smps_flags)
+{
+ struct omap_smps_platform_data *info;
+ struct regulator_init_data **reg_list;
+ int num_reg = 0;
+
+ reg_list = kmalloc(sizeof(void *) * hweight32(smps_flags), GFP_KERNEL);
+ info = kzalloc(sizeof(struct omap_smps_platform_data), GFP_KERNEL);
+
+ if (!reg_list || !info)
+ return;
+
+ if (smps_flags SMPS_COMMON_REGULATOR_MPU_IVA) {
+ reg_list[num_reg] = omap_smps_mpu_iva;
+ num_reg++;
+ }
+ if (smps_flags SMPS_COMMON_REGULATOR_CORE) {
+ reg_list[num_reg] = omap_smps_core;
+ num_reg++;
+ }
+
+ info-regulators = reg_list;
+ info-num_regulators = num_reg;
+
+ smps_dev-name = omap-smps;
+ smps_dev-id = -1;
+ smps_dev-dev.platform_data = info;
+}
diff --git a/arch/arm/mach-omap2/twl-common.h b/arch/arm/mach-omap2/twl-common.h
index 5e83a5b..fde8467 100644
--- a/arch/arm/mach-omap2/twl-common.h
+++ b/arch/arm/mach-omap2/twl-common.h
@@ -25,6 +25,11 @@
#define TWL_COMMON_REGULATOR_VPLL1 (1 4)
#define TWL_COMMON_REGULATOR_VPLL2 (1 5)
+/* TWL SMPS regulators */
+#define SMPS_COMMON_REGULATOR_MPU (1 0)
+#define SMPS_COMMON_REGULATOR_CORE (1 1)
+#define SMPS_COMMON_REGULATOR_IVA (1 2)
+#define SMPS_COMMON_REGULATOR_MPU_IVA (1 3)
struct twl4030_platform_data;
@@ -56,4 +61,13 @@ void omap3_pmic_get_config(struct twl4030_platform_data
*pmic_data,
void omap4_pmic_get_config(struct twl4030_platform_data *pmic_data,
u32 pdata_flags, u32 regulators_flags);
+void omap_pmic_get_smps_config(struct platform_device *smps_dev,
+ u32 smps_flags);
+
+static inline void omap3_pmic_get_smps_config(struct platform_device *smps_dev)
+{
+ omap_pmic_get_smps_config(smps_dev, SMPS_COMMON_REGULATOR_MPU_IVA |
+ SMPS_COMMON_REGULATOR_CORE);
+}
+
#endif /* __OMAP_PMIC_COMMON__ */
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 6/6] TEMP: OMAP3: beagle rev-c4: enable OPP6
Beagleboard rev-c4 has a speed sorted OMAP3530 chip which can run at 720MHz.
This is a temporary patch for supporting this set only, do not integrate.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 32 +++
arch/arm/mach-omap2/opp3xxx_data.c |4 +++
2 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index d493b0b..4d7fd3f 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -492,6 +492,38 @@ static void __init beagle_opp_init(void)
return;
}
+ /* Custom OPP enabled for C4 */
+ if (omap3_beagle_version == OMAP3BEAGLE_BOARD_C4) {
+ struct omap_hwmod *mh = omap_hwmod_lookup(mpu);
+ struct omap_hwmod *dh = omap_hwmod_lookup(iva);
+ struct device *dev;
+
+ if (!mh || !dh) {
+ pr_err(%s: Aiee.. no mpu/dsp devices? %p %p\n,
+ __func__, mh, dh);
+ }
+ /* Enable MPU 720MHz opp */
+ dev = mh-od-pdev.dev;
+ r = opp_enable(dev, 72000);
+
+ /* Enable IVA 520MHz opp */
+ dev = dh-od-pdev.dev;
+ r |= opp_enable(dev, 52000);
+
+ if (r) {
+ pr_err(%s: failed to enable higher opp %d\n,
+ __func__, r);
+ /*
+* Cleanup - disable the higher freqs - we dont care
+* about the results
+*/
+ dev = mh-od-pdev.dev;
+ opp_disable(dev, 72000);
+ dev = dh-od-pdev.dev;
+ opp_disable(dev, 52000);
+ }
+ }
+
/* Custom OPP enabled for all xM versions */
if (cpu_is_omap3630()) {
struct omap_hwmod *mh = omap_hwmod_lookup(mpu);
diff --git a/arch/arm/mach-omap2/opp3xxx_data.c
b/arch/arm/mach-omap2/opp3xxx_data.c
index d95f3f9..a0f5fe1 100644
--- a/arch/arm/mach-omap2/opp3xxx_data.c
+++ b/arch/arm/mach-omap2/opp3xxx_data.c
@@ -98,6 +98,8 @@ static struct omap_opp_def __initdata omap34xx_opp_def_list[]
= {
OPP_INITIALIZER(mpu, true, 55000, OMAP3430_VDD_MPU_OPP4_UV),
/* MPU OPP5 */
OPP_INITIALIZER(mpu, true, 6, OMAP3430_VDD_MPU_OPP5_UV),
+ /* MPU OPP6 : omap3530 high speed grade only */
+ OPP_INITIALIZER(mpu, false, 72000, OMAP3430_VDD_MPU_OPP5_UV),
/*
* L3 OPP1 - 41.5 MHz is disabled because: The voltage for that OPP is
@@ -123,6 +125,8 @@ static struct omap_opp_def __initdata
omap34xx_opp_def_list[] = {
OPP_INITIALIZER(iva, true, 4, OMAP3430_VDD_MPU_OPP4_UV),
/* DSP OPP5 */
OPP_INITIALIZER(iva, true, 43000, OMAP3430_VDD_MPU_OPP5_UV),
+ /* DSP OPP6 : omap3530 high speed grade only */
+ OPP_INITIALIZER(iva, false, 52000, OMAP3430_VDD_MPU_OPP5_UV),
};
static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 0/6] OMAP SMPS regulator driver
On Mon, 2011-07-18 at 19:35 +0200, Kristo, Tero wrote: Hello, Main changes compared to v2: - cleanup should now work better - register all available regulators always, if no initdata = readonly - added board init support functionality to twl-common - constraints not touched by the driver anymore forgot to mention, this set was also rebased on top of linux-omap/pm/wip/voltdm branch. Tested on omap3 beagle. -Tero Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 1/6] OMAP: move voltage.h and vp.h under platform include directory
Hi, On Mon, Jul 18, 2011 at 08:35:17PM +0300, Tero Kristo wrote: This is needed so that these include files can be accessed from drivers. Signed-off-by: Tero Kristo t-kri...@ti.com --- arch/arm/mach-omap2/voltage.h | 180 - arch/arm/mach-omap2/vp.h | 128 arch/arm/plat-omap/include/plat/voltage.h | 179 arch/arm/plat-omap/include/plat/vp.h | 128 4 files changed, 307 insertions(+), 308 deletions(-) delete mode 100644 arch/arm/mach-omap2/voltage.h delete mode 100644 arch/arm/mach-omap2/vp.h create mode 100644 arch/arm/plat-omap/include/plat/voltage.h create mode 100644 arch/arm/plat-omap/include/plat/vp.h just one small tip, if you use git format-patch -M, it would detect that this was just a rename ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCHv3 2/6] omap: voltage: change code to use new location of voltage.h and vp.h
Hi, On Mon, Jul 18, 2011 at 08:35:18PM +0300, Tero Kristo wrote: These are now under plat-omap/include/plat. Signed-off-by: Tero Kristo t-kri...@ti.com this has to be folded into previous patch, otherwise we will have a broken bisection point. -- balbi signature.asc Description: Digital signature
Re: [PATCHv3 3/6] regulator: omap smps regulator driver
Hi,
On Mon, Jul 18, 2011 at 08:35:19PM +0300, Tero Kristo wrote:
diff --git a/drivers/regulator/omap-smps-regulator.c
b/drivers/regulator/omap-smps-regulator.c
new file mode 100644
index 000..8b56e4f
--- /dev/null
+++ b/drivers/regulator/omap-smps-regulator.c
@@ -0,0 +1,179 @@
+/*
+ * omap-vp-regulator.c -- support SMPS regulators for OMAP chips
name is wrong here.
+ *
+ * Copyright (C) 2011 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.
+ */
+
+#include linux/kernel.h
+#include linux/ctype.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/init.h
+#include linux/err.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/regulator/driver.h
+#include linux/regulator/machine.h
+#include linux/regulator/omap-smps.h
+#include plat/voltage.h
+
+#define DRIVER_NAME omap-smps
+
+struct omap_smps_reg_info {
+ const char *vdd_name;
+ struct regulator_dev*rdev;
+ struct voltagedomain*voltdm;
+ struct regulator_desc desc;
+};
+
+static int omap_smps_set_voltage(struct regulator_dev *rdev, int min_uV,
+ int max_uV, unsigned *selector)
+{
+ struct omap_smps_reg_info *info = rdev_get_drvdata(rdev);
+ return voltdm_scale(info-voltdm, min_uV);
+}
+
+static int omap_smps_get_voltage(struct regulator_dev *rdev)
+{
+ struct omap_smps_reg_info *info = rdev_get_drvdata(rdev);
+ return omap_vp_get_curr_volt(info-voltdm);
+}
+
+static struct regulator_ops omap_smps_ops = {
should this be const ?
--
balbi
signature.asc
Description: Digital signature
Re: [PATCHv3 4/6] omap3: pmic: add API to get common SMPS regulators
Hi,
On Mon, Jul 18, 2011 at 08:35:20PM +0300, Tero Kristo wrote:
diff --git a/arch/arm/mach-omap2/twl-common.h
b/arch/arm/mach-omap2/twl-common.h
index 5e83a5b..fde8467 100644
--- a/arch/arm/mach-omap2/twl-common.h
+++ b/arch/arm/mach-omap2/twl-common.h
@@ -25,6 +25,11 @@
#define TWL_COMMON_REGULATOR_VPLL1 (1 4)
#define TWL_COMMON_REGULATOR_VPLL2 (1 5)
+/* TWL SMPS regulators */
+#define SMPS_COMMON_REGULATOR_MPU(1 0)
+#define SMPS_COMMON_REGULATOR_CORE (1 1)
+#define SMPS_COMMON_REGULATOR_IVA(1 2)
+#define SMPS_COMMON_REGULATOR_MPU_IVA(1 3)
struct twl4030_platform_data;
@@ -56,4 +61,13 @@ void omap3_pmic_get_config(struct twl4030_platform_data
*pmic_data,
void omap4_pmic_get_config(struct twl4030_platform_data *pmic_data,
u32 pdata_flags, u32 regulators_flags);
+void omap_pmic_get_smps_config(struct platform_device *smps_dev,
+ u32 smps_flags);
+
+static inline void omap3_pmic_get_smps_config(struct platform_device
*smps_dev)
+{
+ omap_pmic_get_smps_config(smps_dev, SMPS_COMMON_REGULATOR_MPU_IVA |
+ SMPS_COMMON_REGULATOR_CORE);
+}
if these are specific to OMAP SoC, why do they come on twl-common.h
header ?
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 1/6] OMAP4: Add missing clock divider for OCP_ABE_ICLK
On 7/15/2011 9:34, Jon Hunter wrote: 2). The ocp_abe_iclk is an interface clock and is not a parent to any other functional clock and therefore, is not driving any internal logic in a peripheral which would have a direct impact of the speed of that peripheral. However, there does appear to be another bug here in the clock44xx_data.c as it shows that the ocp_abe_iclk is parent to the slimbus1_fck which I believe is incorrect. According to the TRM, the the ocp_abe_iclk is parent to the slimbus1_iclk. I can send another patch for this. However, I will let Benoit chime in first. On further inspection of the clock44xx_data.c, it appears that all interface clocks are called xxx_fck and not xxx_ick. I will ask Benoit about this. However, this particular clock we are dealing with here is an interface clock. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] OMAP4: Add missing clock divider for OCP_ABE_ICLK
On 7/18/2011 15:57, Jon Hunter wrote: On further inspection of the clock44xx_data.c, it appears that all interface clocks are called xxx_fck and not xxx_ick. I will ask Benoit about this. However, this particular clock we are dealing with here is an interface clock. Actually, the above it not true. I will ask Benoit about the naming of the slimbus interface clocks. Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 7/8] drivers: introduce rpmsg, a remote-processor messaging bus
Hi! @@ -0,0 +1,75 @@ +What:/sys/bus/rpmsg/devices/.../name +Date:June 2011 +KernelVersion: 3.2 +Contact: Ohad Ben-Cohen o...@wizery.com +Description: + Every rpmsg device is a communication channel with a remote + processor. Channels are identified with a (textual) name, + which is maximum 32 bytes long (defined as RPMSG_NAME_SIZE in + rpmsg.h). + + This sysfs entry contains the name of this channel. + +What:/sys/bus/rpmsg/devices/.../src +Date:June 2011 +KernelVersion: 3.2 +Contact: Ohad Ben-Cohen o...@wizery.com +Description: + Every rpmsg device is a communication channel with a remote + processor. Channels have a local (source) rpmsg address, + and remote (destination) rpmsg address. When an entity + starts listening on one end of a channel, it assigns it with + a unique rpmsg address (a 32 bits integer). This way when + inbound messages arrive to this address, the rpmsg core + dispatches them to the listening entity (a kernel driver). + + This sysfs entry contains the src (local) rpmsg address + of this channel. If it contains 0x, then an address + wasn't assigned (can happen if no driver exists for this + channel). So this is basically networking... right? Why not implement it as sockets? (accept, connect, read, write)? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap-serial: Allow IXON and IXOFF to be disabled.
On Thu, Jul 14, 2011 at 10:37 PM, Govindraj govindraj...@gmail.com wrote: On Fri, Jul 15, 2011 at 12:19 AM, Nick Pelly npe...@google.com wrote: Fixes logic bug that software flow control cannot be disabled, because serial_omap_configure_xonxoff() is not called if both IXON and IXOFF bits are cleared. Thanks, Good Point. need to send to this patch to linux-ser...@vger.kernel.org, CC'ing Greg Kroah-Hartman gre...@suse.de will be merged through tty tree. feel free to add Acked-by: Govindraj.R govindraj.r...@ti.com Tested-by: Govindraj.R govindraj.r...@ti.com Done. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: Enable DMA mode1 RX for USB-Mass-Storage
On Sat, Jul 16, 2011 at 4:22 AM, Sergei Shtylyov sshtyl...@mvista.com wrote:
Hello.
On 16-07-2011 3:44, Vikram Pandita wrote:
From: Vikram Pandita vikram.pand...@ti.com
This patch enables the DMA mode1 RX support.
This feature is enabled based on the short_not_ok flag passed from
gadget drivers.
This will result in a thruput performance gain of around
40% for USB mass-storage/mtp use cases.
Based on Original work by
Anand Gadiyargadi...@ti.com on 2.6.35 kernel
Tested on OMAP4460 Blaze board.
Signed-off-by: Moiz Sonasath m-sonas...@ti.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
drivers/usb/musb/musb_gadget.c | 42
---
1 files changed, 30 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 9412410..e643ec2 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -624,6 +624,7 @@ void musb_g_tx(struct musb *musb, u8 epnum)
/*
* Context: controller locked, IRQs blocked, endpoint selected
*/
+
Why?
typo - will fix in v2
static void rxstate(struct musb *musb, struct musb_request *req)
{
const u8 epnum = req-epnum;
@@ -714,10 +728,13 @@ static void rxstate(struct musb *musb, struct
musb_request *req)
* then becomes usable as a runtime use mode 1 hint...
*/
- csr |= MUSB_RXCSR_DMAENAB;
-#ifdef USE_MODE1
+ /* Experimental: Mode1 works with mass storage use cases
+ */
+ if (use_mode_1) {
No, you can't put the code at the arbitrary indentation levels. Please
indent properly.
agree. v2 will address.
csr |= MUSB_RXCSR_AUTOCLEAR;
- /* csr |= MUSB_RXCSR_DMAMODE; */
+ musb_writew(epio, MUSB_RXCSR, csr);
+ csr |= MUSB_RXCSR_DMAENAB;
+ musb_writew(epio, MUSB_RXCSR, csr);
/* this special sequence (enabling and then
* disabling MUSB_RXCSR_DMAMODE) is required
@@ -725,26 +742,27 @@ static void rxstate(struct musb *musb, struct
musb_request *req)
*/
musb_writew(epio, MUSB_RXCSR,
csr | MUSB_RXCSR_DMAMODE);
-#else
+ musb_writew(epio, MUSB_RXCSR, csr);
+
+ } else {
if (!musb_ep-hb_mult
musb_ep-hw_ep-rx_double_buffered)
csr |= MUSB_RXCSR_AUTOCLEAR;
-#endif
+ csr |= MUSB_RXCSR_DMAENAB;
musb_writew(epio, MUSB_RXCSR, csr);
+ }
if (request-actual request-length) {
int transfer_size = 0;
-#ifdef USE_MODE1
+ if (use_mode_1) {
Same here.
agree. v2 will address.
transfer_size = min(request-length -
request-actual,
channel-max_len);
-#else
+ musb_ep-dma-desired_mode = 1;
+ } else {
transfer_size = min(request-length -
request-actual,
(unsigned)len);
-#endif
- if (transfer_size =
musb_ep-packet_sz)
- musb_ep-dma-desired_mode =
0;
- else
- musb_ep-dma-desired_mode =
1;
+ musb_ep-dma-desired_mode = 0;
+ }
use_dma = c-channel_program(
channel,
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 3/6] regulator: omap smps regulator driver
Felipe Balbi ba...@ti.com writes: On Mon, Jul 18, 2011 at 08:35:19PM +0300, Tero Kristo wrote: diff --git a/drivers/regulator/omap-smps-regulator.c b/drivers/regulator/omap-smps-regulator.c new file mode 100644 index 000..8b56e4f --- /dev/null +++ b/drivers/regulator/omap-smps-regulator.c @@ -0,0 +1,179 @@ +/* + * omap-vp-regulator.c -- support SMPS regulators for OMAP chips name is wrong here. In fact, just leave filenames out of file headers all together to avoid this kind of problem. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 1/6] OMAP: move voltage.h and vp.h under platform include directory
Tero Kristo t-kri...@ti.com writes: This is needed so that these include files can be accessed from drivers. I think you can get by with a plat/voltage.h with simply an opaque struct voltagedomain, and the definitions of the functions needed by the regulator driver (currently only voltdm_scale, omap_vp_get_curr_volt). Then mach-omap2/voltage.h could just include plat/voltage.h and all the truly internal stuff can stay internal. Also note that in the latest pm-wip/voltdm branch (just pushed) omap_vp_get_curr_volt() no longer exists. Just use voltdm_get_voltage(). Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] usb: musb: Enable DMA mode1 RX for USB-Mass-Storage
From: Vikram Pandita vikram.pand...@ti.com
This patch enables the DMA mode1 RX support.
This feature is enabled based on the short_not_ok flag passed from
gadget drivers.
This will result in a thruput performance gain of around
40% for USB mass-storage/mtp use cases.
Based on Original work by
Anand Gadiyar gadi...@ti.com on 2.6.35 kernel
Change-Id: I9b3a7cae73b63e86128d2caf4cdd67ab77556e75
Signed-off-by: Moiz Sonasath m-sonas...@ti.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
V1 - initial drop
V2 - fixed whitespace issues as per Sergei Shtylyovsshtyl...@mvista.com
comments
drivers/usb/musb/musb_gadget.c | 68 ---
1 files changed, 42 insertions(+), 26 deletions(-)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 6aeb363..4a1432e 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -634,6 +634,7 @@ static void rxstate(struct musb *musb, struct musb_request
*req)
u16 len;
u16 csr = musb_readw(epio, MUSB_RXCSR);
struct musb_hw_ep *hw_ep = musb-endpoints[epnum];
+ u8 use_mode_1;
if (hw_ep-is_shared_fifo)
musb_ep = hw_ep-ep_in;
@@ -683,6 +684,18 @@ static void rxstate(struct musb *musb, struct musb_request
*req)
if (csr MUSB_RXCSR_RXPKTRDY) {
len = musb_readw(epio, MUSB_RXCOUNT);
+
+ /*
+* Enable Mode 1 for RX transfers only for mass-storage
+* use-case, based on short_not_ok flag which is set only
+* from file_storage and f_mass_storage drivers
+*/
+
+ if (request-short_not_ok len == musb_ep-packet_sz)
+ use_mode_1 = 1;
+ else
+ use_mode_1 = 0;
+
if (request-actual request-length) {
#ifdef CONFIG_USB_INVENTRA_DMA
if (is_buffer_mapped(req)) {
@@ -714,37 +727,40 @@ static void rxstate(struct musb *musb, struct
musb_request *req)
* then becomes usable as a runtime use mode 1 hint...
*/
- csr |= MUSB_RXCSR_DMAENAB;
-#ifdef USE_MODE1
- csr |= MUSB_RXCSR_AUTOCLEAR;
- /* csr |= MUSB_RXCSR_DMAMODE; */
-
- /* this special sequence (enabling and then
-* disabling MUSB_RXCSR_DMAMODE) is required
-* to get DMAReq to activate
-*/
- musb_writew(epio, MUSB_RXCSR,
- csr | MUSB_RXCSR_DMAMODE);
-#else
- if (!musb_ep-hb_mult
- musb_ep-hw_ep-rx_double_buffered)
+ /* Experimental: Mode1 works with mass storage
use cases */
+ if (use_mode_1) {
csr |= MUSB_RXCSR_AUTOCLEAR;
-#endif
- musb_writew(epio, MUSB_RXCSR, csr);
+ musb_writew(epio, MUSB_RXCSR, csr);
+ csr |= MUSB_RXCSR_DMAENAB;
+ musb_writew(epio, MUSB_RXCSR, csr);
+
+ /* this special sequence (enabling and
then
+ * disabling MUSB_RXCSR_DMAMODE) is
required
+ * to get DMAReq to activate
+ */
+ musb_writew(epio, MUSB_RXCSR,
+ csr | MUSB_RXCSR_DMAMODE);
+ musb_writew(epio, MUSB_RXCSR, csr);
+
+ } else {
+ if (!musb_ep-hb_mult
+
musb_ep-hw_ep-rx_double_buffered)
+ csr |= MUSB_RXCSR_AUTOCLEAR;
+ csr |= MUSB_RXCSR_DMAENAB;
+ musb_writew(epio, MUSB_RXCSR, csr);
+ }
if (request-actual request-length) {
int transfer_size = 0;
-#ifdef USE_MODE1
- transfer_size = min(request-length -
request-actual,
- channel-max_len);
-#else
- transfer_size = min(request-length -
request-actual,
- (unsigned)len);
-#endif
- if (transfer_size = musb_ep-packet_sz)
-
Example: Plain Text Message
: This is a test message. Best Regards, Smart Williams wsmar...@yahoo.nl Sent on 2011-07-18 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 7/8] drivers: introduce rpmsg, a remote-processor messaging bus
Hi Pavel, On Thu, Jun 9, 2011 at 8:12 PM, Pavel Machek pa...@ucw.cz wrote: So this is basically networking... right? Why not implement it as sockets? (accept, connect, read, write)? This patch focuses on adding the core rpmsg kernel infrastructure. The next step, after getting the basic stuff in, would be adding rpmsg drivers, and exposing user space API. For some use cases, where userland talks directly with remote entities (and otherwise requires no kernel involvement besides exposing the transport), socket API is very nice as it's flexible and prevalent. We already have several rpmsg drivers and a rpmsg-based socket API implementation too, but we'll get to it only after the core stuff gets in. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] dt: omap3: add generic board file for dt support
Grant/Kevin,
On Sun, Jul 17, 2011 at 10:43 AM, Grant Likely
grant.lik...@secretlab.ca wrote:
Hi Manjunath,
Comments below. I left in a lot of context for the new folks that
I've cc'd (Tony and Kevin).
On Sat, Jul 16, 2011 at 2:07 PM, G, Manjunath Kondaiah manj...@ti.com wrote:
On Thu, Jul 14, 2011 at 4:45 AM, Grant Likely grant.lik...@secretlab.ca
wrote:
+static void __init omap3_init(void)
+{
[...]
+ omap_register_i2c_bus(id, speed, i2c_board_info, 1);
While this does in a sense work, and creates an omap_device for the
i2c bus that does get probed, it ends up encoding an awful lot of
device specific details into the generic devicetree support code. The
i2c bus driver itself must be responsible for decoding the speed and
child nodes, and in fact it can easily be modified to do so (I've
already demonstrated how to do so). The real problem is making sure
the platform_device is created in a way that attaches the correct
hwmod data. For this context, the current omap_register_i2c_bus()
isn't a useful method for doing so.
So what is to be done? omap_register_i2c_bus() does three things;
1) register an i2c board info for the bus with i2c_register_board_info(),
2) fill platform_data for the device, and
3) use omap_i2c_add_bus to create the platform_device with attached hwmod.
Of these three, 1 2 must not be done when using the DT. Only
omap_i2c_add_bus() does something useful, but that is still specific
to the i2c device.
omap_i2c_add_bus() splits to omap{1,2}_add_bus().
omap1_i2c_add_bus() sets up pinmux and calls platform_device register.
pinmux setup needs to be factored out anyway for generic DT platform
device registration, which just leaves platform_device creation which
is already handled by of_platform_populate().
omap2_i2c_add_bus() does the same thing, except it also looks up the
hwmod data (*oh) and uses it to call omap_device_build().
omap_device_build() or something equivalent needs to be called for
every omap device in the system, which is to create platform_devices
with hwmod attached. Now we're starting to hit generic code. :-)
The way I see it, you've got two options:
1) modify the of_platform_bus_create() to call some kind of
of_platform_bus_create_omap() for devices that match ti,omap3-device
or something.
2) Leave of_platform_bus_create(), and instead us a notifier to attach
hwmod data to normal platform devices. omap_device_build() is
actually pretty simple. It allocated a device, it attaches
platform_data and hwmod pointers to the device and registers it.
omap_device_register() is just a wrapper around
platform_device_register().
My preference is definitely #2, but there is a wrinkle in this
approach. Unfortunately omap_devices are not simply plain
platform_devices with extra data attached, an omap_device actually
embeds the platform_device inside it, which cannot be attached after
the fact. I think I had talked with Kevin (cc'd) about eliminating
the embedding, but I cannot remember clearly on this point. As long
as platform_device remains embedded inside struct omap_device, #2
won't work.
Can you please elaborate more on this issue?
-Manjunath
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
