am3517: geting MMC working
What patches do I need to get MMC working with linux-omap master? omap_hsmmc omap_hsmmc.0: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 62 omap-dma-engine omap-dma-engine: allocating channel for 61 omap_hsmmc omap_hsmmc.1: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 48 omap-dma-engine omap-dma-engine: allocating channel for 47 I searched for this issue and saw some patches for common clock framework that were scheduled for 3.6, but I'm not sure it's enough or weather they are already incorporated in linux-omap. Best regards, Yegor -- 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: am3517: geting MMC working
On Thu, Jul 19, 2012 at 11:54 AM, Yegor Yefremov yegor_s...@visionsystems.de wrote: What patches do I need to get MMC working with linux-omap master? omap_hsmmc omap_hsmmc.0: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 62 omap-dma-engine omap-dma-engine: allocating channel for 61 omap_hsmmc omap_hsmmc.1: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 48 omap-dma-engine omap-dma-engine: allocating channel for 47 I searched for this issue and saw some patches for common clock framework that were scheduled for 3.6, but I'm not sure it's enough or weather they are already incorporated in linux-omap. I guess you need [1] to get around the issue. Regards Santosh [1] http://www.spinics.net/lists/linux-omap/msg73965.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: am3517: geting MMC working
Am 19.07.2012 08:34, schrieb Shilimkar, Santosh: On Thu, Jul 19, 2012 at 11:54 AM, Yegor Yefremov yegor_s...@visionsystems.de wrote: What patches do I need to get MMC working with linux-omap master? omap_hsmmc omap_hsmmc.0: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 62 omap-dma-engine omap-dma-engine: allocating channel for 61 omap_hsmmc omap_hsmmc.1: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 48 omap-dma-engine omap-dma-engine: allocating channel for 47 I searched for this issue and saw some patches for common clock framework that were scheduled for 3.6, but I'm not sure it's enough or weather they are already incorporated in linux-omap. I guess you need [1] to get around the issue. [1] http://www.spinics.net/lists/linux-omap/msg73965.html though I haven't applied this patch I have DMA activated (CONFIG_DMADEVICES and CONFIG_DMA_OMAP). Found in some other thread [1]. As far as I can tell, debounce clk is the problem. [1] http://www.spinics.net/lists/linux-omap/msg73703.html Yegor -- 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 5/8] ARM: OMAP2+: PM: introduce power domains achievable functional states
On Fri, Jun 15, 2012 at 6:28 AM, Jean Pihet jean.pi...@newoldbits.com wrote:
1. The while loops need optimization. - This can definitely be
simplified and made non-risky; this also needs some more error
handling
If you are interested using something like the following
static int _match_pwrst(u32 pwrsts, u8 pwrst, u8 default_pwrst)
{
bool found = true;
int new_pwrst = pwrst;
/* Search down */
while (!(pwrsts (1 new_pwrst))) {
if (new_pwrst == PWRDM_POWER_OFF) {
found = false;
break;
}
new_pwrst--;
}
if (found)
goto done;
/* Search up */
new_pwrst = pwrst;
while (!(pwrsts (1 new_pwrst))) {
if (new_pwrst == default_pwrst)
break;
new_pwrst++;
}
done:
return new_pwrst;
}
new_pwrst = _match_pwrst(pwrdm-pwrsts, pwrst,
PWRDM_POWER_ON);
new_logic = _match_pwrst(pwrdm-pwrsts_logic_ret, logic,
PWRDM_POWER_RET);
to achieve the same code..
2. About the power domains state machine: you have only one power
state to move in and out of: it is called ON. If you do ON-CSWR-ON
etc. attempting to program ON-CSWR-OSWR is NOT supported in OMAP and
is an invitation for production team to sit and debug for a while
before finding the use of invalid power states
Point 2 is a good point. The solution would be to implement a state
machine in this function and/or omap_set_pwrdm_state, possibly using a
platform specific handling function.
Point 2 is not completely accurate - Lower pwr state transitions can
indeed and is indeed
supported on OMAP4+. CSWR-OSWR-OFF is possible and omap_setpwrdm_state does
indeed handle this. however going to OSWR-CSWR is possible only by
OSWR-ON-CSWR.
this is again supported in code, however, in practice, we have found
that certain IP blocks(in
personal experience, it was DSS) need IP specific additional work
which is not easily doable..
so when we come out of suspend state, if the IP block has achieved a
lower powerstate than
what was programmed, we just leave it as is.
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6 4/7] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count
Minor nitpick:
On Mon, Jun 11, 2012 at 10:26 AM, Tero Kristo t-kri...@ti.com wrote:
+/**
+ * _omap4_get_context_lost - get context loss counter for a hwmod
Documentation missing for oh
btw, you might be interested in using http://www.omappedia.org/wiki/Kmake
to provide list of kerneldoc errors in addition to other easily
catchable errors..
+ *
+ * Returns the in-memory context loss counter for a hwmod.
+ */
+static int _omap4_get_context_lost(struct omap_hwmod *oh)
+{
+ return oh-prcm.omap4.context_lost_counter;
+}
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: am3517: geting MMC working
On Thu, Jul 19, 2012 at 12:25 PM, Yegor Yefremov yegor_s...@visionsystems.de wrote: Am 19.07.2012 08:34, schrieb Shilimkar, Santosh: On Thu, Jul 19, 2012 at 11:54 AM, Yegor Yefremov yegor_s...@visionsystems.de wrote: What patches do I need to get MMC working with linux-omap master? omap_hsmmc omap_hsmmc.0: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 62 omap-dma-engine omap-dma-engine: allocating channel for 61 omap_hsmmc omap_hsmmc.1: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 48 omap-dma-engine omap-dma-engine: allocating channel for 47 I searched for this issue and saw some patches for common clock framework that were scheduled for 3.6, but I'm not sure it's enough or weather they are already incorporated in linux-omap. I guess you need [1] to get around the issue. [1] http://www.spinics.net/lists/linux-omap/msg73965.html though I haven't applied this patch I have DMA activated (CONFIG_DMADEVICES and CONFIG_DMA_OMAP). Found in some other thread [1]. As far as I can tell, debounce clk is the problem. Sorry. I miss-read the message. Regards santosh -- 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: am3517: geting MMC working
Am 19.07.2012 09:07, schrieb Shilimkar, Santosh: On Thu, Jul 19, 2012 at 12:25 PM, Yegor Yefremov yegor_s...@visionsystems.de wrote: Am 19.07.2012 08:34, schrieb Shilimkar, Santosh: On Thu, Jul 19, 2012 at 11:54 AM, Yegor Yefremov yegor_s...@visionsystems.de wrote: What patches do I need to get MMC working with linux-omap master? omap_hsmmc omap_hsmmc.0: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 62 omap-dma-engine omap-dma-engine: allocating channel for 61 omap_hsmmc omap_hsmmc.1: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 48 omap-dma-engine omap-dma-engine: allocating channel for 47 I searched for this issue and saw some patches for common clock framework that were scheduled for 3.6, but I'm not sure it's enough or weather they are already incorporated in linux-omap. I guess you need [1] to get around the issue. [1] http://www.spinics.net/lists/linux-omap/msg73965.html though I haven't applied this patch I have DMA activated (CONFIG_DMADEVICES and CONFIG_DMA_OMAP). Found in some other thread [1]. As far as I can tell, debounce clk is the problem. Sorry. I miss-read the message. The whole log for reference: Booting Linux on physical CPU 0 Linux version 3.5.0-rc6-12227-g60701f4-dirty () (gcc version 4.5.3 (Buildroot 2012.05-rc2-9-gfbd5a1d-dirty) ) #90 Thu Jul 19 09:23:31 CEST 2012 CPU: ARMv7 Processor [411fc087] revision 7 (ARMv7), cr=10c53c7d CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP3517/AM3517 EVM Ignoring tag cmdline (using the default kernel command line) bootconsole [earlycon0] enabled Memory policy: ECC disabled, Data cache writeback AM3517 ES1.1 (l2cache sgx neon ) Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 Kernel command line: root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 earlyprintk=serial,ttyO2,115200 PID hash table entries: 1024 (order: 0, 4096 bytes) Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 255MB = 255MB total Memory: 247380k/247380k available, 14764k reserved, 0K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) vmalloc : 0xd080 - 0xff00 ( 744 MB) lowmem : 0xc000 - 0xd000 ( 256 MB) pkmap : 0xbfe0 - 0xc000 ( 2 MB) .text : 0xc0008000 - 0xc055e6a8 (5466 kB) .init : 0xc055f000 - 0xc0594874 ( 215 kB) .data : 0xc0596000 - 0xc05fccc0 ( 412 kB) .bss : 0xc05fcce4 - 0xc0b2a1e8 (5302 kB) NR_IRQS:474 IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts Total of 96 interrupts on 1 active controller OMAP clockevent source: GPTIMER1 at 32768 Hz sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms OMAP clocksource: 32k_counter at 32768 Hz Console: colour dummy device 80x30 Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES: 8 ... MAX_LOCK_DEPTH: 48 ... MAX_LOCKDEP_KEYS:8191 ... CLASSHASH_SIZE: 4096 ... MAX_LOCKDEP_ENTRIES: 16384 ... MAX_LOCKDEP_CHAINS: 32768 ... CHAINHASH_SIZE: 16384 memory used by lock dependency info: 3695 kB per task-struct memory footprint: 1152 bytes Calibrating delay loop... 331.40 BogoMIPS (lpj=1296384) pid_max: default: 32768 minimum: 301 Security Framework initialized Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok Setting up static identity map for 0x80444ff0 - 0x80445048 devtmpfs: initialized dummy: NET: Registered protocol family 16 GPMC revision 5.0 gpmc: irq-20 could not claim: err -22 OMAP GPIO hardware version 2.5 omap_mux_init: Add partition: #1: core, flags: 0 _omap_mux_get_by_name: Could not find signal uart4_rx.uart4_rx Reprogramming SDRC clock to 33200 Hz dpll3_m2_clk rate change failed: -22 hw-breakpoint: debug architecture 0x4 unsupported. OMAP DMA hardware revision 4.0 bio: create slab bio-0 at 0 omap-dma-engine omap-dma-engine: OMAP DMA engine driver SCSI subsystem initialized omap_i2c omap_i2c.1: bus 1 rev1.3.12 at 400 kHz omap_i2c omap_i2c.2: bus 2 rev1.3.12 at 400 kHz omap_i2c omap_i2c.3: bus 3 rev1.3.12 at 400 kHz Bluetooth: Core ver 2.16 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: L2CAP socket layer initialized Bluetooth: SCO socket layer initialized cfg80211: Calling CRDA to update world regulatory domain Switching to clocksource 32k_counter NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 6, 294912 bytes) TCP: Hash tables configured (established
Re: am3517: geting MMC working
On Thu, Jul 19, 2012 at 12:58 PM, Yegor Yefremov yegor_s...@visionsystems.de wrote: Am 19.07.2012 09:07, schrieb Shilimkar, Santosh: On Thu, Jul 19, 2012 at 12:25 PM, Yegor Yefremov yegor_s...@visionsystems.de wrote: Am 19.07.2012 08:34, schrieb Shilimkar, Santosh: On Thu, Jul 19, 2012 at 11:54 AM, Yegor Yefremov yegor_s...@visionsystems.de wrote: What patches do I need to get MMC working with linux-omap master? omap_hsmmc omap_hsmmc.0: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 62 omap-dma-engine omap-dma-engine: allocating channel for 61 omap_hsmmc omap_hsmmc.1: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 48 omap-dma-engine omap-dma-engine: allocating channel for 47 I searched for this issue and saw some patches for common clock framework that were scheduled for 3.6, but I'm not sure it's enough or weather they are already incorporated in linux-omap. I guess you need [1] to get around the issue. [1] http://www.spinics.net/lists/linux-omap/msg73965.html though I haven't applied this patch I have DMA activated (CONFIG_DMADEVICES and CONFIG_DMA_OMAP). Found in some other thread [1]. As far as I can tell, debounce clk is the problem. Sorry. I miss-read the message. The whole log for reference: Booting Linux on physical CPU 0 Linux version 3.5.0-rc6-12227-g60701f4-dirty () (gcc version 4.5.3 (Buildroot 2012.05-rc2-9-gfbd5a1d-dirty) ) #90 Thu Jul 19 09:23:31 CEST 2012 CPU: ARMv7 Processor [411fc087] revision 7 (ARMv7), cr=10c53c7d CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP3517/AM3517 EVM Ignoring tag cmdline (using the default kernel command line) bootconsole [earlycon0] enabled Memory policy: ECC disabled, Data cache writeback AM3517 ES1.1 (l2cache sgx neon ) Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 Kernel command line: root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 earlyprintk=serial,ttyO2,115200 PID hash table entries: 1024 (order: 0, 4096 bytes) Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 255MB = 255MB total Memory: 247380k/247380k available, 14764k reserved, 0K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) vmalloc : 0xd080 - 0xff00 ( 744 MB) lowmem : 0xc000 - 0xd000 ( 256 MB) pkmap : 0xbfe0 - 0xc000 ( 2 MB) .text : 0xc0008000 - 0xc055e6a8 (5466 kB) .init : 0xc055f000 - 0xc0594874 ( 215 kB) .data : 0xc0596000 - 0xc05fccc0 ( 412 kB) .bss : 0xc05fcce4 - 0xc0b2a1e8 (5302 kB) NR_IRQS:474 IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts Total of 96 interrupts on 1 active controller OMAP clockevent source: GPTIMER1 at 32768 Hz sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms OMAP clocksource: 32k_counter at 32768 Hz Console: colour dummy device 80x30 Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES: 8 ... MAX_LOCK_DEPTH: 48 ... MAX_LOCKDEP_KEYS:8191 ... CLASSHASH_SIZE: 4096 ... MAX_LOCKDEP_ENTRIES: 16384 ... MAX_LOCKDEP_CHAINS: 32768 ... CHAINHASH_SIZE: 16384 memory used by lock dependency info: 3695 kB per task-struct memory footprint: 1152 bytes Calibrating delay loop... 331.40 BogoMIPS (lpj=1296384) pid_max: default: 32768 minimum: 301 Security Framework initialized Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok Setting up static identity map for 0x80444ff0 - 0x80445048 devtmpfs: initialized dummy: NET: Registered protocol family 16 GPMC revision 5.0 gpmc: irq-20 could not claim: err -22 OMAP GPIO hardware version 2.5 omap_mux_init: Add partition: #1: core, flags: 0 _omap_mux_get_by_name: Could not find signal uart4_rx.uart4_rx Reprogramming SDRC clock to 33200 Hz dpll3_m2_clk rate change failed: -22 hw-breakpoint: debug architecture 0x4 unsupported. OMAP DMA hardware revision 4.0 bio: create slab bio-0 at 0 omap-dma-engine omap-dma-engine: OMAP DMA engine driver SCSI subsystem initialized omap_i2c omap_i2c.1: bus 1 rev1.3.12 at 400 kHz omap_i2c omap_i2c.2: bus 2 rev1.3.12 at 400 kHz omap_i2c omap_i2c.3: bus 3 rev1.3.12 at 400 kHz Bluetooth: Core ver 2.16 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: L2CAP socket layer initialized Bluetooth: SCO socket layer initialized cfg80211: Calling CRDA to update world regulatory domain Switching to clocksource 32k_counter NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
Re: am3517: geting MMC working
Am 19.07.2012 09:43, schrieb S, Venkatraman: On Thu, Jul 19, 2012 at 12:58 PM, Yegor Yefremov yegor_s...@visionsystems.de wrote: Am 19.07.2012 09:07, schrieb Shilimkar, Santosh: On Thu, Jul 19, 2012 at 12:25 PM, Yegor Yefremov yegor_s...@visionsystems.de wrote: Am 19.07.2012 08:34, schrieb Shilimkar, Santosh: On Thu, Jul 19, 2012 at 11:54 AM, Yegor Yefremov yegor_s...@visionsystems.de wrote: What patches do I need to get MMC working with linux-omap master? omap_hsmmc omap_hsmmc.0: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 62 omap-dma-engine omap-dma-engine: allocating channel for 61 omap_hsmmc omap_hsmmc.1: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 48 omap-dma-engine omap-dma-engine: allocating channel for 47 I searched for this issue and saw some patches for common clock framework that were scheduled for 3.6, but I'm not sure it's enough or weather they are already incorporated in linux-omap. I guess you need [1] to get around the issue. [1] http://www.spinics.net/lists/linux-omap/msg73965.html though I haven't applied this patch I have DMA activated (CONFIG_DMADEVICES and CONFIG_DMA_OMAP). Found in some other thread [1]. As far as I can tell, debounce clk is the problem. Sorry. I miss-read the message. The whole log for reference: Booting Linux on physical CPU 0 Linux version 3.5.0-rc6-12227-g60701f4-dirty () (gcc version 4.5.3 (Buildroot 2012.05-rc2-9-gfbd5a1d-dirty) ) #90 Thu Jul 19 09:23:31 CEST 2012 CPU: ARMv7 Processor [411fc087] revision 7 (ARMv7), cr=10c53c7d CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP3517/AM3517 EVM Ignoring tag cmdline (using the default kernel command line) bootconsole [earlycon0] enabled Memory policy: ECC disabled, Data cache writeback AM3517 ES1.1 (l2cache sgx neon ) Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 Kernel command line: root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 earlyprintk=serial,ttyO2,115200 PID hash table entries: 1024 (order: 0, 4096 bytes) Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 255MB = 255MB total Memory: 247380k/247380k available, 14764k reserved, 0K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) vmalloc : 0xd080 - 0xff00 ( 744 MB) lowmem : 0xc000 - 0xd000 ( 256 MB) pkmap : 0xbfe0 - 0xc000 ( 2 MB) .text : 0xc0008000 - 0xc055e6a8 (5466 kB) .init : 0xc055f000 - 0xc0594874 ( 215 kB) .data : 0xc0596000 - 0xc05fccc0 ( 412 kB) .bss : 0xc05fcce4 - 0xc0b2a1e8 (5302 kB) NR_IRQS:474 IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts Total of 96 interrupts on 1 active controller OMAP clockevent source: GPTIMER1 at 32768 Hz sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms OMAP clocksource: 32k_counter at 32768 Hz Console: colour dummy device 80x30 Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES: 8 ... MAX_LOCK_DEPTH: 48 ... MAX_LOCKDEP_KEYS:8191 ... CLASSHASH_SIZE: 4096 ... MAX_LOCKDEP_ENTRIES: 16384 ... MAX_LOCKDEP_CHAINS: 32768 ... CHAINHASH_SIZE: 16384 memory used by lock dependency info: 3695 kB per task-struct memory footprint: 1152 bytes Calibrating delay loop... 331.40 BogoMIPS (lpj=1296384) pid_max: default: 32768 minimum: 301 Security Framework initialized Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok Setting up static identity map for 0x80444ff0 - 0x80445048 devtmpfs: initialized dummy: NET: Registered protocol family 16 GPMC revision 5.0 gpmc: irq-20 could not claim: err -22 OMAP GPIO hardware version 2.5 omap_mux_init: Add partition: #1: core, flags: 0 _omap_mux_get_by_name: Could not find signal uart4_rx.uart4_rx Reprogramming SDRC clock to 33200 Hz dpll3_m2_clk rate change failed: -22 hw-breakpoint: debug architecture 0x4 unsupported. OMAP DMA hardware revision 4.0 bio: create slab bio-0 at 0 omap-dma-engine omap-dma-engine: OMAP DMA engine driver SCSI subsystem initialized omap_i2c omap_i2c.1: bus 1 rev1.3.12 at 400 kHz omap_i2c omap_i2c.2: bus 2 rev1.3.12 at 400 kHz omap_i2c omap_i2c.3: bus 3 rev1.3.12 at 400 kHz Bluetooth: Core ver 2.16 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: L2CAP socket layer initialized Bluetooth: SCO socket layer initialized cfg80211: Calling CRDA to update world regulatory domain Switching to clocksource 32k_counter NET: Registered protocol family 2 IP route cache
Re: am3517: geting MMC working
On Thu, Jul 19, 2012 at 9:43 AM, S, Venkatraman svenk...@ti.com wrote: On Thu, Jul 19, 2012 at 12:58 PM, Yegor Yefremov yegor_s...@visionsystems.de wrote: Am 19.07.2012 09:07, schrieb Shilimkar, Santosh: On Thu, Jul 19, 2012 at 12:25 PM, Yegor Yefremov yegor_s...@visionsystems.de wrote: Am 19.07.2012 08:34, schrieb Shilimkar, Santosh: On Thu, Jul 19, 2012 at 11:54 AM, Yegor Yefremov yegor_s...@visionsystems.de wrote: What patches do I need to get MMC working with linux-omap master? omap_hsmmc omap_hsmmc.0: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 62 omap-dma-engine omap-dma-engine: allocating channel for 61 omap_hsmmc omap_hsmmc.1: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 48 omap-dma-engine omap-dma-engine: allocating channel for 47 I searched for this issue and saw some patches for common clock framework that were scheduled for 3.6, but I'm not sure it's enough or weather they are already incorporated in linux-omap. I guess you need [1] to get around the issue. [1] http://www.spinics.net/lists/linux-omap/msg73965.html though I haven't applied this patch I have DMA activated (CONFIG_DMADEVICES and CONFIG_DMA_OMAP). Found in some other thread [1]. As far as I can tell, debounce clk is the problem. Sorry. I miss-read the message. The whole log for reference: Booting Linux on physical CPU 0 Linux version 3.5.0-rc6-12227-g60701f4-dirty () (gcc version 4.5.3 (Buildroot 2012.05-rc2-9-gfbd5a1d-dirty) ) #90 Thu Jul 19 09:23:31 CEST 2012 CPU: ARMv7 Processor [411fc087] revision 7 (ARMv7), cr=10c53c7d CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP3517/AM3517 EVM Ignoring tag cmdline (using the default kernel command line) bootconsole [earlycon0] enabled Memory policy: ECC disabled, Data cache writeback AM3517 ES1.1 (l2cache sgx neon ) Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 Kernel command line: root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 earlyprintk=serial,ttyO2,115200 PID hash table entries: 1024 (order: 0, 4096 bytes) Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 255MB = 255MB total Memory: 247380k/247380k available, 14764k reserved, 0K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) vmalloc : 0xd080 - 0xff00 ( 744 MB) lowmem : 0xc000 - 0xd000 ( 256 MB) pkmap : 0xbfe0 - 0xc000 ( 2 MB) .text : 0xc0008000 - 0xc055e6a8 (5466 kB) .init : 0xc055f000 - 0xc0594874 ( 215 kB) .data : 0xc0596000 - 0xc05fccc0 ( 412 kB) .bss : 0xc05fcce4 - 0xc0b2a1e8 (5302 kB) NR_IRQS:474 IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts Total of 96 interrupts on 1 active controller OMAP clockevent source: GPTIMER1 at 32768 Hz sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms OMAP clocksource: 32k_counter at 32768 Hz Console: colour dummy device 80x30 Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES: 8 ... MAX_LOCK_DEPTH: 48 ... MAX_LOCKDEP_KEYS:8191 ... CLASSHASH_SIZE: 4096 ... MAX_LOCKDEP_ENTRIES: 16384 ... MAX_LOCKDEP_CHAINS: 32768 ... CHAINHASH_SIZE: 16384 memory used by lock dependency info: 3695 kB per task-struct memory footprint: 1152 bytes Calibrating delay loop... 331.40 BogoMIPS (lpj=1296384) pid_max: default: 32768 minimum: 301 Security Framework initialized Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok Setting up static identity map for 0x80444ff0 - 0x80445048 devtmpfs: initialized dummy: NET: Registered protocol family 16 GPMC revision 5.0 gpmc: irq-20 could not claim: err -22 OMAP GPIO hardware version 2.5 omap_mux_init: Add partition: #1: core, flags: 0 _omap_mux_get_by_name: Could not find signal uart4_rx.uart4_rx Reprogramming SDRC clock to 33200 Hz dpll3_m2_clk rate change failed: -22 hw-breakpoint: debug architecture 0x4 unsupported. OMAP DMA hardware revision 4.0 bio: create slab bio-0 at 0 omap-dma-engine omap-dma-engine: OMAP DMA engine driver SCSI subsystem initialized omap_i2c omap_i2c.1: bus 1 rev1.3.12 at 400 kHz omap_i2c omap_i2c.2: bus 2 rev1.3.12 at 400 kHz omap_i2c omap_i2c.3: bus 3 rev1.3.12 at 400 kHz Bluetooth: Core ver 2.16 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: L2CAP socket layer initialized Bluetooth: SCO socket layer initialized cfg80211: Calling CRDA to update world regulatory domain Switching to clocksource 32k_counter NET: Registered protocol
Re: am3517: geting MMC working
On Thu, Jul 19, 2012 at 1:45 PM, Yegor Yefremov yegor_s...@visionsystems.de wrote: Am 19.07.2012 09:43, schrieb S, Venkatraman: On Thu, Jul 19, 2012 at 12:58 PM, Yegor Yefremov yegor_s...@visionsystems.de wrote: Am 19.07.2012 09:07, schrieb Shilimkar, Santosh: On Thu, Jul 19, 2012 at 12:25 PM, Yegor Yefremov yegor_s...@visionsystems.de wrote: Am 19.07.2012 08:34, schrieb Shilimkar, Santosh: On Thu, Jul 19, 2012 at 11:54 AM, Yegor Yefremov yegor_s...@visionsystems.de wrote: What patches do I need to get MMC working with linux-omap master? omap_hsmmc omap_hsmmc.0: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 62 omap-dma-engine omap-dma-engine: allocating channel for 61 omap_hsmmc omap_hsmmc.1: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 48 omap-dma-engine omap-dma-engine: allocating channel for 47 I searched for this issue and saw some patches for common clock framework that were scheduled for 3.6, but I'm not sure it's enough or weather they are already incorporated in linux-omap. I guess you need [1] to get around the issue. [1] http://www.spinics.net/lists/linux-omap/msg73965.html though I haven't applied this patch I have DMA activated (CONFIG_DMADEVICES and CONFIG_DMA_OMAP). Found in some other thread [1]. As far as I can tell, debounce clk is the problem. Sorry. I miss-read the message. The whole log for reference: Booting Linux on physical CPU 0 Linux version 3.5.0-rc6-12227-g60701f4-dirty () (gcc version 4.5.3 (Buildroot 2012.05-rc2-9-gfbd5a1d-dirty) ) #90 Thu Jul 19 09:23:31 CEST 2012 CPU: ARMv7 Processor [411fc087] revision 7 (ARMv7), cr=10c53c7d CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP3517/AM3517 EVM Ignoring tag cmdline (using the default kernel command line) bootconsole [earlycon0] enabled Memory policy: ECC disabled, Data cache writeback AM3517 ES1.1 (l2cache sgx neon ) Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 Kernel command line: root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 earlyprintk=serial,ttyO2,115200 PID hash table entries: 1024 (order: 0, 4096 bytes) Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 255MB = 255MB total Memory: 247380k/247380k available, 14764k reserved, 0K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) vmalloc : 0xd080 - 0xff00 ( 744 MB) lowmem : 0xc000 - 0xd000 ( 256 MB) pkmap : 0xbfe0 - 0xc000 ( 2 MB) .text : 0xc0008000 - 0xc055e6a8 (5466 kB) .init : 0xc055f000 - 0xc0594874 ( 215 kB) .data : 0xc0596000 - 0xc05fccc0 ( 412 kB) .bss : 0xc05fcce4 - 0xc0b2a1e8 (5302 kB) NR_IRQS:474 IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts Total of 96 interrupts on 1 active controller OMAP clockevent source: GPTIMER1 at 32768 Hz sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms OMAP clocksource: 32k_counter at 32768 Hz Console: colour dummy device 80x30 Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES: 8 ... MAX_LOCK_DEPTH: 48 ... MAX_LOCKDEP_KEYS:8191 ... CLASSHASH_SIZE: 4096 ... MAX_LOCKDEP_ENTRIES: 16384 ... MAX_LOCKDEP_CHAINS: 32768 ... CHAINHASH_SIZE: 16384 memory used by lock dependency info: 3695 kB per task-struct memory footprint: 1152 bytes Calibrating delay loop... 331.40 BogoMIPS (lpj=1296384) pid_max: default: 32768 minimum: 301 Security Framework initialized Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok Setting up static identity map for 0x80444ff0 - 0x80445048 devtmpfs: initialized dummy: NET: Registered protocol family 16 GPMC revision 5.0 gpmc: irq-20 could not claim: err -22 OMAP GPIO hardware version 2.5 omap_mux_init: Add partition: #1: core, flags: 0 _omap_mux_get_by_name: Could not find signal uart4_rx.uart4_rx Reprogramming SDRC clock to 33200 Hz dpll3_m2_clk rate change failed: -22 hw-breakpoint: debug architecture 0x4 unsupported. OMAP DMA hardware revision 4.0 bio: create slab bio-0 at 0 omap-dma-engine omap-dma-engine: OMAP DMA engine driver SCSI subsystem initialized omap_i2c omap_i2c.1: bus 1 rev1.3.12 at 400 kHz omap_i2c omap_i2c.2: bus 2 rev1.3.12 at 400 kHz omap_i2c omap_i2c.3: bus 3 rev1.3.12 at 400 kHz Bluetooth: Core ver 2.16 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: L2CAP socket layer initialized Bluetooth: SCO socket layer initialized cfg80211: Calling CRDA to update world regulatory domain
Re: [PATCH 01/10] ARM: OMAP2+: PM QoS: control the power domains next state from the constraints
On Thu, Jun 14, 2012 at 10:05 AM, Jean Pihet jean.pi...@newoldbits.com wrote:
Minor comment follows:
[...]
+/**
+ * _pwrdm_wakeuplat_update_pwrst - Update power domain power state if needed
+ * @pwrdm: struct powerdomain * to which requesting device belongs to.
+ * @min_latency: the allowed wake-up latency for the given power domain. A
+ * value of PM_QOS_DEV_LAT_DEFAULT_VALUE means 'no constraint' on the pwrdm.
+ *
+ * Finds the power domain next power state that fulfills the constraint.
+ * Programs a new target state if it is different from current power state.
+ * The power domains get the next power state programmed directly in the
+ * registers.
+ *
+ * Returns 0 in case of success, -EINVAL in case of invalid parameters,
+ * or the return value from omap_set_pwrdm_state.
+ */
+static int _pwrdm_wakeuplat_update_pwrst(struct powerdomain *pwrdm,
+long min_latency)
+{
+ int ret = 0, state, new_state = PWRDM_FUNC_PWRST_ON;
+
+ if (!pwrdm) {
+ WARN(1, powerdomain: %s: invalid parameter(s), __func__);
+ return -EINVAL;
+ }
_pwrdm_wakeuplat_update_pwrst is an helper function, we check pwrdm to
be valid here,
however,
[...]
/* Public functions */
/**
+ * pwrdm_wakeuplat_update_constraint - Set or update a powerdomain wakeup
+ * latency constraint and apply it
+ * @pwrdm: struct powerdomain * which the constraint applies to
+ * @cookie: constraint identifier, used for tracking
+ * @min_latency: minimum wakeup latency constraint (in microseconds) for
+ * the given pwrdm
+ *
+ * Tracks the constraints by @cookie.
+ * Constraint set/update: Adds a new entry to powerdomain's wake-up latency
+ * constraint list. If the constraint identifier already exists in the list,
+ * the old value is overwritten.
+ *
+ * Applies the aggregated constraint value for the given pwrdm by calling
+ * _pwrdm_wakeuplat_update_pwrst.
+ *
+ * Returns 0 upon success, -ENOMEM in case of memory shortage, -EINVAL in
+ * case of invalid latency value, or the return value from
+ * _pwrdm_wakeuplat_update_pwrst.
+ *
+ * The caller must check the validity of the parameters.
+ */
+int pwrdm_wakeuplat_update_constraint(struct powerdomain *pwrdm, void
*cookie,
+ long min_latency)
+{
+ struct pwrdm_wkup_constraints_entry *tmp_user, *new_user, *user =
NULL;
+ long value = PM_QOS_DEV_LAT_DEFAULT_VALUE;
+ int free_new_user = 0;
+
+ pr_debug(powerdomain: %s: pwrdm %s, cookie=0x%p, min_latency=%ld\n,
+__func__, pwrdm-name, cookie, min_latency);
here,
+
+ if (min_latency = PM_QOS_DEV_LAT_DEFAULT_VALUE) {
+ pr_warn(%s: min_latency = PM_QOS_DEV_LAT_DEFAULT_VALUE\n,
+ __func__);
+ return -EINVAL;
+ }
+
+ /* Allocate a new entry for insertion in the list */
+ new_user = kzalloc(sizeof(struct pwrdm_wkup_constraints_entry),
+ GFP_KERNEL);
+ if (!new_user) {
+ pr_err(%s: FATAL ERROR: kzalloc failed\n, __func__);
+ return -ENOMEM;
+ }
+
+ mutex_lock(pwrdm-wkup_lat_plist_lock);
here,
+
+ /* Check if there already is a constraint for cookie */
+ plist_for_each_entry(tmp_user, pwrdm-wkup_lat_plist_head, node) {
+ if (tmp_user-cookie == cookie) {
+ user = tmp_user;
+ break;
+ }
+ }
here,
+
+ /* If nothing to update, job done */
+ if (user (user-node.prio == min_latency))
+ goto out;
+
+ if (!user) {
+ /* Add new entry to the list */
+ user = new_user;
+ user-cookie = cookie;
+ } else {
+ /* Update existing entry */
+ plist_del(user-node, pwrdm-wkup_lat_plist_head);
here
+ free_new_user = 1;
+ }
+
+ plist_node_init(user-node, min_latency);
+ plist_add(user-node, pwrdm-wkup_lat_plist_head);
here
+
+ /* Find the aggregated constraint value from the list */
+ if (!plist_head_empty(pwrdm-wkup_lat_plist_head))
...
+ value = plist_first(pwrdm-wkup_lat_plist_head)-prio;
...
+
+ mutex_unlock(pwrdm-wkup_lat_plist_lock);
...
+
+ /* Free the newly allocated entry if not in use */
+ if (free_new_user)
+ kfree(new_user);
+
+ /* Apply the constraint to the pwrdm */
+ pr_debug(powerdomain: %s: pwrdm %s, value=%ld\n,
+__func__, pwrdm-name, value);
...
+ return _pwrdm_wakeuplat_update_pwrst(pwrdm, value);
we have already crashed before we do a WARN in helper.
+
+out:
+ mutex_unlock(pwrdm-wkup_lat_plist_lock);
+ return 0;
+}
+
+/**
+ * pwrdm_wakeuplat_remove_constraint - Release a powerdomain wakeup latency
+ *
Re: [PATCH 04/10] ARM: OMAP: omap_device: register to the per-device PM QoS framework
On Wed, Jun 20, 2012 at 5:41 AM, Rajendra Nayak rna...@ti.com wrote:
+ /* Look for the platform device for the constraint target device
*/
+ pdev = to_platform_device(dev_pm_qos_req-dev);
+
+ /* Try to catch non platform devices */
+ if (pdev-name == NULL) {
Is this a safe way to catch non platform devices?
in addition, we should check !pdev before attempting to dereference
and check for pdev-name
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 04/11] usb: otg: nop: add support for multiple tranceiver
Hi,
On Thu, Jul 19, 2012 at 11:11 AM, Ajay Kumar Gupta ajay.gu...@ti.com wrote:
Currently we have one single nop transceiver support as same is
defined as a global variable in drivers/usb/otg/nop-usb-xceiv.c.
This need to be changed to support multiple otg controller each
using nop transceiver on a platform such as am335x.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c |2 +-
drivers/usb/musb/am35x.c |4 ++--
drivers/usb/musb/blackfin.c |4 ++--
drivers/usb/musb/da8xx.c |4 ++--
drivers/usb/musb/davinci.c |6 +++---
drivers/usb/musb/musb_dsps.c | 10 +-
drivers/usb/musb/tusb6010.c |6 +++---
drivers/usb/otg/nop-usb-xceiv.c | 20
include/linux/usb/otg.h |9 +
9 files changed, 35 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index ef230a0..a3393bc 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -704,7 +704,7 @@ static void __init omap3_evm_init(void)
omap_sdrc_init(mt46h32m32lf6_sdrc_params, NULL);
/* OMAP3EVM uses ISP1504 phy and so register nop transceiver */
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(0);
if (get_omap3_evm_rev() = OMAP3EVM_BOARD_GEN_2) {
/* enable EHCI VBUS using GPIO22 */
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 01203eb..eb6220f 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -364,7 +364,7 @@ static int am35x_musb_init(struct musb *musb)
if (!rev)
return -ENODEV;
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(musb-id);
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv))
return -ENODEV;
@@ -408,7 +408,7 @@ static int am35x_musb_exit(struct musb *musb)
data-set_phy_power(0);
usb_put_phy(musb-xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb-xceiv);
return 0;
}
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index c848b82..03d081c 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -415,7 +415,7 @@ static int bfin_musb_init(struct musb *musb)
}
gpio_direction_output(musb-config-gpio_vrsel, 0);
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(musb-id);
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv)) {
gpio_free(musb-config-gpio_vrsel);
@@ -442,7 +442,7 @@ static int bfin_musb_exit(struct musb *musb)
gpio_free(musb-config-gpio_vrsel);
usb_put_phy(musb-xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb-xceiv);
return 0;
}
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index cebd9d7..3ce4a92 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -425,7 +425,7 @@ static int da8xx_musb_init(struct musb *musb)
if (!rev)
goto fail;
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(musb-id);
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv))
goto fail;
@@ -460,7 +460,7 @@ static int da8xx_musb_exit(struct musb *musb)
phy_off();
usb_put_phy(musb-xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb-xceiv);
return 0;
}
diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
index 3f094f2..d5156b3 100644
--- a/drivers/usb/musb/davinci.c
+++ b/drivers/usb/musb/davinci.c
@@ -385,7 +385,7 @@ static int davinci_musb_init(struct musb *musb)
void __iomem*tibase = musb-ctrl_base;
u32 revision;
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(musb-id);
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv))
goto unregister;
@@ -447,7 +447,7 @@ static int davinci_musb_init(struct musb *musb)
fail:
usb_put_phy(musb-xceiv);
unregister:
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb-xceiv);
return -ENODEV;
}
@@ -496,7 +496,7 @@ static int davinci_musb_exit(struct musb *musb)
phy_off();
usb_put_phy(musb-xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb-xceiv);
return 0;
}
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index a2c8a06..9fcacff 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -420,8 +420,8 @@ static int dsps_musb_init(struct musb *musb)
Re: [PATCH v3 07/11] usb: otg: nop: add dt support
Hi,
On Thu, Jul 19, 2012 at 11:11 AM, Ajay Kumar Gupta ajay.gu...@ti.com wrote:
Added device tree support for nop transceiver driver and updated the
Documentation with device tree binding information for am33xx platform.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
.../devicetree/bindings/usb/am33xx-usb.txt |3 +++
drivers/usb/otg/nop-usb-xceiv.c| 12
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
index ca8fa56..9782585 100644
--- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -12,3 +12,6 @@ AM33XX MUSB GLUE
represents PERIPHERAL.
- power : Should be 250. This signifies the controller can supply upto
500mA when operating in host mode.
+
+NOP USB PHY
+ - compatible : Should be nop-xceiv-usb
diff --git a/drivers/usb/otg/nop-usb-xceiv.c b/drivers/usb/otg/nop-usb-xceiv.c
index 2e5e889..102e7d8 100644
--- a/drivers/usb/otg/nop-usb-xceiv.c
+++ b/drivers/usb/otg/nop-usb-xceiv.c
@@ -27,6 +27,7 @@
*/
#include linux/module.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/usb/otg.h
@@ -152,12 +153,23 @@ static int __devexit nop_usb_xceiv_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id nop_xceiv_id_table[] = {
+ { .compatible = nop-xceiv-usb },
+ {}
+};
+MODULE_DEVICE_TABLE(of, nop_xceiv_id_table);
+#else
+#define nop_xceiv_id_table NULL
+#endif
The *#else* part is not needed as your *of_match_ptr* will take care of it.
+
static struct platform_driver nop_usb_xceiv_driver = {
.probe = nop_usb_xceiv_probe,
.remove = __devexit_p(nop_usb_xceiv_remove),
.driver = {
.name = nop_usb_xceiv,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(nop_xceiv_id_table),
},
};
Thanks
Kishon
--
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: [PATCHv6 4/7] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count
On Thu, 2012-07-19 at 00:55 -0500, Menon, Nishanth wrote:
On Wed, Jul 18, 2012 at 4:15 AM, Tero Kristo t-kri...@ti.com wrote:
On Tue, 2012-07-17 at 02:59 -0500, Menon, Nishanth wrote:
Couple of minor comments:
On Mon, Jun 11, 2012 at 10:26 AM, Tero Kristo t-kri...@ti.com wrote:
[...]
/**
+ * _omap4_update_context_lost - increment hwmod context loss counter
if
+ * hwmod context was lost, and clear hardware context loss reg
+ * @oh: hwmod to check for context loss
+ *
+ * If the PRCM indicates that the hwmod @oh lost context, increment
+ * our in-memory context loss counter, and clear the RM_*_CONTEXT
+ * bits. No return value.
+ */
+static void _omap4_update_context_lost(struct omap_hwmod *oh)
+{
+ u32 r;
+
+ if (oh-prcm.omap4.context_offs == USHRT_MAX)
+ return;
would'nt it be better to return a dummy incremental counter instead of
returning no context loss (count = 0)?
I guess you are right, this way we may have some extra context restores
for modules which don't have context offs defined, rather than not
restoring them at all. Only thing I can think might prevent this is if
there are modules that never lose context but don't have context
register? How about omap5+?
there has been an interesting debate ongoing with HWAUTO and context
loss count handling - since we update only on _enable, this might
actually be interesting to consider:
enable
idle
un_idle (lost context)
read counter - no update
Now to handle modules that never loose context - they have to be in
wakeup domain.. should we consider a flag for those? would'nt matter
o5 or not, context is still the same.. this issue could be resolved if
counter update is done even when a check is done.
Yea, that would be an option. I think I'll add a flag for not losing
context ever.
+
+ r =
omap4_prminst_read_inst_reg(oh-clkdm-pwrdm.ptr-prcm_partition,
+
oh-clkdm-pwrdm.ptr-prcm_offs,
+ oh-prcm.omap4.context_offs);
+
+ if (!r)
+ return;
+
+ oh-prcm.omap4.context_lost_counter++;
need to be careful about counter overflow.
Well, this code can't do much for that even if it overflows... the type
for the context_lost_counter is unsigned though, maybe it should be
expanded if you are worried...?
it can hit 0 with overflow(no context loss). that will not be good, right?
Zero doesn't mean no context loss. If counter was previous MAX_INT, if
it goes to zero it is still a context loss, as the counter value
differs. Drivers do check against diff in the context loss counter, and
if there is one, they do restore which is the right way to handle it. No
need to unnecessarily make this more complicated than it is.
-Tero
--
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: [PATCHv6 3/7] ARM: OMAP4: hwmod: flag hwmods/modules not supporting module level context status
On Wed, 2012-07-18 at 11:24 -0600, Paul Walmsley wrote: On Wed, 18 Jul 2012, Tero Kristo wrote: On Tue, 2012-07-17 at 03:11 -0500, Menon, Nishanth wrote: OMAP4430_RM_ABE_AESS_CONTEXT? why not use LOSTMEM_AESSMEM ? ABE will need to know when it lost context to be able to reload it's firmware, no? It looks like current hwmod data doesn't support specific bits to be used for the context declaration, it is only specifying the register offset. Also, the same register is used by aess hwmod, so this will cause a conflict if I take the same register into use. This could be fixed by adding a field for the context bits, but I guess this should be commented upon by someone (Benoit / Paul) before I craft some sort of patch for that. If you need to add a u8 there to specify the bitshift, go ahead and do it. u8 lostmem_bit, perhaps? Mask might be better, as we have RFF / DFF bits, and also if mask is not defined, we can assume we want to check the whole register (current behavior.) I'll add this for next rev. -Tero -- 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: am3517: geting MMC working
On Thu, Jul 19, 2012 at 2:27 PM, S, Venkatraman svenk...@ti.com wrote: On Thu, Jul 19, 2012 at 1:45 PM, Yegor Yefremov yegor_s...@visionsystems.de wrote: Waiting for root device /dev/mmcblk0p2... mmc0: starting CMD0 arg flags 00c0 omap_hsmmc omap_hsmmc.0: mmc0: CMD0, argument 0x From this, one can only infer that the card is not responding at all, and all attempts are returning with a timeout (CTO=Command Time Out). These (control) commands don't use DMA, so it's not a DMA issue upto this. If the card is fine, and it worked before, I would suggest a bisect. Meanwhile I'll check lo-master with my OMAP4 boards. ~Venkat I checked on 4430sdp, OMAP4 is able to detect both eMMC and SD with lo-master. -- Thanks and Regards, Balaji T K -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 07/11] usb: otg: nop: add dt support
Hi,
Added device tree support for nop transceiver driver and updated the
Documentation with device tree binding information for am33xx platform.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
.../devicetree/bindings/usb/am33xx-usb.txt |3 +++
drivers/usb/otg/nop-usb-xceiv.c| 12
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
index ca8fa56..9782585 100644
--- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -12,3 +12,6 @@ AM33XX MUSB GLUE
represents PERIPHERAL.
- power : Should be 250. This signifies the controller can supply upto
500mA when operating in host mode.
+
+NOP USB PHY
+ - compatible : Should be nop-xceiv-usb
diff --git a/drivers/usb/otg/nop-usb-xceiv.c b/drivers/usb/otg/nop-usb-
xceiv.c
index 2e5e889..102e7d8 100644
--- a/drivers/usb/otg/nop-usb-xceiv.c
+++ b/drivers/usb/otg/nop-usb-xceiv.c
@@ -27,6 +27,7 @@
*/
#include linux/module.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/usb/otg.h
@@ -152,12 +153,23 @@ static int __devexit nop_usb_xceiv_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id nop_xceiv_id_table[] = {
+ { .compatible = nop-xceiv-usb },
+ {}
+};
+MODULE_DEVICE_TABLE(of, nop_xceiv_id_table);
+#else
+#define nop_xceiv_id_table NULL
+#endif
The *#else* part is not needed as your *of_match_ptr* will take care of it.
Ok, I will update this.
Ajay
+
static struct platform_driver nop_usb_xceiv_driver = {
.probe = nop_usb_xceiv_probe,
.remove = __devexit_p(nop_usb_xceiv_remove),
.driver = {
.name = nop_usb_xceiv,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(nop_xceiv_id_table),
},
};
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 04/11] usb: otg: nop: add support for multiple tranceiver
Hi,
Currently we have one single nop transceiver support as same is
defined as a global variable in drivers/usb/otg/nop-usb-xceiv.c.
This need to be changed to support multiple otg controller each
using nop transceiver on a platform such as am335x.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c |2 +-
drivers/usb/musb/am35x.c |4 ++--
drivers/usb/musb/blackfin.c |4 ++--
drivers/usb/musb/da8xx.c |4 ++--
drivers/usb/musb/davinci.c |6 +++---
drivers/usb/musb/musb_dsps.c | 10 +-
drivers/usb/musb/tusb6010.c |6 +++---
drivers/usb/otg/nop-usb-xceiv.c | 20
include/linux/usb/otg.h |9 +
9 files changed, 35 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-
omap2/board-omap3evm.c
index ef230a0..a3393bc 100644
[...]
diff --git a/include/linux/usb/otg.h b/include/linux/usb/otg.h
index 4636d39..36cc791 100644
--- a/include/linux/usb/otg.h
+++ b/include/linux/usb/otg.h
@@ -95,6 +95,7 @@ struct usb_phy {
struct device *dev;
const char *label;
unsigned int flags;
+ u8 id;
Do we really need to have *id* in phy??
I will update the patches dropping this.
enum usb_phy_type type;
enum usb_otg_state state;
@@ -137,14 +138,14 @@ extern void usb_remove_phy(struct usb_phy *);
#if defined(CONFIG_NOP_USB_XCEIV) ||
(defined(CONFIG_NOP_USB_XCEIV_MODULE) defined(MODULE))
/* sometimes transceivers are accessed only through e.g. ULPI */
-extern void usb_nop_xceiv_register(void);
-extern void usb_nop_xceiv_unregister(void);
+extern void usb_nop_xceiv_register(int id);
+extern void usb_nop_xceiv_unregister(struct usb_phy *);
IMHO, these declarations shouldn't be in usb/otg.h. It can be in a
header file specific to usb_nop?
They were in otg.h and just definition getting changed so I think they
need to be in otg.h only as a logical change of this patch.
Location can be changed as a separate patch later.
Thanks,
Ajay
Thanks
Kishon
--
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: USB : Fix the EHCI enumeration and core retention issue
On Thu, Jul 12, 2012 at 12:11 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Wed, Jul 11, 2012 at 7:53 PM, Kevin Hilman khil...@ti.com wrote: Munegowda, Keshava keshava_mgo...@ti.com writes: On Wed, Jul 11, 2012 at 3:59 PM, Samuel Ortiz sa...@linux.intel.com wrote: Hi Keshava, Kevin, On Fri, Jul 06, 2012 at 05:29:00PM +0530, Munegowda, Keshava wrote: Samuel I have sent that patch to disable the ehci in omap2plus_defconfig; after merging that please merge this patch too. This will fix the crashes in during boot with NFS in beagleXM I'm going to apply and push this patch for 3.5, and the defconfig patch can be pushed through Tony's tree. Kevin, could you please ACK it ? Cheers, Samuel. Thanks Samuel Kevin, need your ack for this. You never answered earlier questions from myself or Russ Dill about the more targetted patches from Russ: ARM: OMAP: USB: Fixup ehci_hcd_omap_probe error path Fix OMAP EHCI suspend/resume failure (i693) '354ab856' causes Also, your current $SUBJECT patch is large and not well described. e.g. what is not correct and why. Why does it fix the problems mentioned? The original changelog mentions the core retention issue but this patch does nothing to address that. If you want an Ack from me, especially because I'm not an expert in this IP, you'll have to describe things in a way that I can understand. IMO, at this point of the dev cycle (trying to stabilize v3.5), the full cleanup/fix of this feature will need to be done for v3.6. For v3.5, I think the two patches from Russ Dill should be merged. They are targetted fixes and very well described. Kevin Hi Kevin The usb2 host of omap3/4/5 silicons has the following ips 1. UHH ( /drivers/mfd/omap-usb-host.c ) -- platform driver 2. TLL( /drivers/mfd/omap-usb-host.c ) 3. ehci( /drivers/usb/host/ehci-omap.c) - platform driver 4. ohci ( /drivers/usb/host/ohci-omap3.c ) - platform drivers The 3 platform drivers exists to make the ehci/ohci functional. The UHH-TLL or usb host core driver is the parent platform driver of ehci and ohci. This parent driver doe the clock enable/disable which common for both ehci and ohci. takes care of common port setting and clocks during suspend and resume and ensures that there is no overwrites by ehci and ohci platform drivers. The commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) was handling the clocks in the ehci driver it self, instead it should be handled by usb host core driver as per above explanation. so, the UHH-TLL Driver should handle the changes done by 354ab8567ae3107a8cbe7228c3181990ba598aac. hence this patch removes the changed done by the commit id 354ab8567ae3107a8cbe7228c3181990ba598aac suppose if this patch is not included, then it will cause the following two problems 1. crash during the system boot - observed in beagle xm , with NFS file system the Ethernet is through ehci driver , since the ehci ports clocks are not handled properly by this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac, it leads to crash 2. crash during suspend/resume - observed in beagle xm with ram fs if the ehci is driver is included and if it tries to suspend it leads to crash regards keshava hi Felipe I request you to ack this patch; this will enable the boot issue in beagle xm with NFS. I will rework the patch with commit id 354ab8567ae3107a8cbe7228c3181990ba598aac by Anand gadiyar after the TLL driver gets merged. regards keshava -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 0/5] ARM: OMAP: HOST: TLL driver implementation
On Mon, Jul 16, 2012 at 7:01 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: The TLL (Transceiver Less Link) is an separate IP block, independent of the host controller. Basically this TLL operates like USB PHY which allows the user to connect two USB transceiver interfaces together directly without the use of differential transceivers in omap3 and later chips. The TLL configuration is removed from the UHH driver and implemented as a seperate platform driver. Now, the UHH driver configures the TLL through API's exported by the TLL platform driver. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com In v4: - rebased on top of linux kernel version 3.5.rc7 - reworked as per the comments given by Paul Walmsley p...@pwsan.com In v3: - rebased on top V3 of Russ dill's patch 'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' fixes an issue where the ULPI PHYs were not held in reset while initializing the EHCI controller http://permalink.gmane.org/gmane.linux.usb.general/65988 - rebased on top of patch OMAP: USB : Fix the EHCI enumeration and core retention issue http://permalink.gmane.org/gmane.linux.usb.general/66239 In V2: - covered review comments from linux omap and usb community - rebased on top Russ dill's patch 'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' fixes an issue where the ULPI PHYs were not held in reset while initializing the EHCI controller Keshava Munegowda (5): ARM: OMAP: Add the USB TLL clocks device name ARM: OMAP: USB: HOST TLL platform driver ARM: OMAP: USB: Invoke the TLL driver from USB HS core driver ARM: OMAP: USB: Remove TLL specific code from USB HS core driver ARM: OMAP: Remove older device name of the USB TLL clocks arch/arm/mach-omap2/clock3xxx_data.c |8 +- arch/arm/mach-omap2/clock44xx_data.c |4 +- arch/arm/mach-omap2/usb-host.c| 31 ++- arch/arm/plat-omap/include/plat/usb.h |7 + drivers/mfd/Kconfig |2 +- drivers/mfd/Makefile |2 +- drivers/mfd/omap-usb-host.c | 238 ++--- drivers/mfd/omap-usb-tll.c| 471 + 8 files changed, 523 insertions(+), 240 deletions(-) create mode 100644 drivers/mfd/omap-usb-tll.c -- 1.7.9.5 Felipe/ Paul please let me know if you have any review comments on this v4 series. regards keshava -- 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: USB : Fix the EHCI enumeration and core retention issue
Hi, On Thu, Jun 21, 2012 at 07:12:12PM +0530, Keshava Munegowda wrote: This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) is causing the usb hub and device detection fails in beagle XM causeing NFS not functional. This affects the core retention too. The same commit logic needs to be revisted adhering to hwmod and device tree framework. for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) reverted. This patch is validated on BeagleXM with NFS support over usb ethernet and USB mass storage and other device detection. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Acked-by: Felipe Balbi ba...@ti.com turns out this is causing other issues and another version of the patch will be provided. Greg, Alan, this is basically a git revert of the commit id listed above. -- balbi signature.asc Description: Digital signature
Re: [PATCHv6 4/7] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count
On Thu, Jul 19, 2012 at 4:49 AM, Tero Kristo t-kri...@ti.com wrote: Zero doesn't mean no context loss. If counter was previous MAX_INT, if it goes to zero it is still a context loss, as the counter value differs. Drivers do check against diff in the context loss counter, and if there is one, they do restore which is the right way to handle it. No need to unnecessarily make this more complicated than it is. so we flip the responsibility of overflow to drivers. considering a similar scenario of jiffies /* * These inlines deal with timer wrapping correctly. You are * strongly encouraged to use them * 1. Because people otherwise forget * 2. Because if the timer wrap changes in future you won't have to * alter your driver code. * * time_after(a,b) returns true if the time a is after time b. ... */ from past experience, it is highly possible that drivers never get this right. if the intent is just to let the drivers know context was lost, why not go back to the alternate possibility of a bool lost_context which tells the driver if it lost context since it last called the lost_context api. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6 4/7] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count
On Thu, Jul 19, 2012 at 3:19 PM, Tero Kristo t-kri...@ti.com wrote:
On Thu, 2012-07-19 at 00:55 -0500, Menon, Nishanth wrote:
On Wed, Jul 18, 2012 at 4:15 AM, Tero Kristo t-kri...@ti.com wrote:
On Tue, 2012-07-17 at 02:59 -0500, Menon, Nishanth wrote:
Couple of minor comments:
On Mon, Jun 11, 2012 at 10:26 AM, Tero Kristo t-kri...@ti.com
wrote:
[...]
/**
+ * _omap4_update_context_lost - increment hwmod context loss
counter
if
+ * hwmod context was lost, and clear hardware context loss reg
+ * @oh: hwmod to check for context loss
+ *
+ * If the PRCM indicates that the hwmod @oh lost context,
increment
+ * our in-memory context loss counter, and clear the RM_*_CONTEXT
+ * bits. No return value.
+ */
+static void _omap4_update_context_lost(struct omap_hwmod *oh)
+{
+ u32 r;
+
+ if (oh-prcm.omap4.context_offs == USHRT_MAX)
+ return;
would'nt it be better to return a dummy incremental counter instead
of
returning no context loss (count = 0)?
I guess you are right, this way we may have some extra context
restores
for modules which don't have context offs defined, rather than not
restoring them at all. Only thing I can think might prevent this is if
there are modules that never lose context but don't have context
register? How about omap5+?
there has been an interesting debate ongoing with HWAUTO and context
loss count handling - since we update only on _enable, this might
actually be interesting to consider:
enable
idle
un_idle (lost context)
read counter - no update
Now to handle modules that never loose context - they have to be in
wakeup domain.. should we consider a flag for those? would'nt matter
o5 or not, context is still the same.. this issue could be resolved if
counter update is done even when a check is done.
Yea, that would be an option. I think I'll add a flag for not losing
context ever.
You just access the module power domain from hwmod and then
you already know whether it is AON or not. The flag idea
was discussed in context of [1]. See if you can re-use that same idea.
regards
Santosh
[1] https://patchwork.kernel.org/patch/1133491/
--
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: [PATCHv6] arm/dts: omap4-sdp: Add keypad data
Hi Tony,
On Fri, Jul 13, 2012 at 8:27 PM, Sourav Poddar sourav.pod...@ti.com wrote:
Add keypad data node in omap4 device tree file.
Also fill the device tree binding parameters
with the required value in omap4-sdp dts file.
Tested on omap4430 sdp with 3.5-rc6 kernel.
Cc: Tony Lindgren t...@atomide.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
This patch[1] was initially posted as a series.
The first patch[2] of the series is taken into
dmitry's input tree.
So, posting this as a independent patch .
[1]: https://lkml.org/lkml/2012/6/8/239
[2]: https://lkml.org/lkml/2012/6/1/75
Changes since v5:
Few key mappings were missed, added linux, keymap
data for those key mappings.
arch/arm/boot/dts/omap4-sdp.dts | 70
+++
arch/arm/boot/dts/omap4.dtsi|5 +++
2 files changed, 75 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index d08c4d1..53ded54 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -70,6 +70,76 @@
gpios = gpio5 11 0; /* 139 */
};
};
+
+ keypad@4a31c000 {
+ keypad,num-rows = 8;
+ keypad,num-columns = 8;
+ linux,keymap = 0x0012
+ 0x00010013
+ 0x00020014
+ 0x00030066
+ 0x0004003f
+ 0x000500f0
+ 0x00060017
+ 0x0007002a
+ 0x0120
+ 0x01010021
+ 0x01020022
+ 0x010300e7
+ 0x01040040
+ 0x010500f0
+ 0x01060025
+ 0x0107001c
+ 0x022d
+ 0x0201002e
+ 0x0202002f
+ 0x0203006b
+ 0x02040041
+ 0x020500f0
+ 0x02060034
+ 0x0207003a
+ 0x032c
+ 0x0301004e
+ 0x03020030
+ 0x0303003b
+ 0x03040042
+ 0x030500f0
+ 0x03060018
+ 0x03070039
+ 0x0411
+ 0x04010015
+ 0x04020016
+ 0x0403003c
+ 0x04040073
+ 0x040500f0
+ 0x04060026
+ 0x04070069
+ 0x051f
+ 0x05010023
+ 0x05020024
+ 0x0503003d
+ 0x05040043
+ 0x05050072
+ 0x05060032
+ 0x0507006a
+ 0x0610
+ 0x0601001e
+ 0x06020031
+ 0x0603009e
+ 0x0604000e
+ 0x060500f0
+ 0x06060019
+ 0x06070067
+ 0x0794
+ 0x07010095
+ 0x070200ca
+ 0x070300cb
+ 0x0704003e
+ 0x070500f0
+ 0x07060160
+ 0x0707006c ;
+ linux,input-no-autorepeat;
+ };
};
i2c1 {
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 359c497..11b72d2 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -273,4 +273,9 @@
ti,needs-special-reset;
};
};
+
+ keypad@4a31c000 {
+ compatible = ti,omap4-keypad;
+ ti,hwmods = kbd;
+ };
};
--
1.7.1
Can you please look into this patch?
~Sourav
--
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] MMC: OMAP: make MMC_OMAP* depend on DMA_OMAP
On Thu, Jul 19, 2012 at 10:35 AM, Chris Ball c...@laptop.org wrote: Hi Venkat -- please could you ACK/review this patch? Chris, I think we have to hold on to this patch just for today. There's another thread about this same issue on linux-omap On Wed, Jul 04 2012, Ming Lei wrote: Recent commits on omap mmc/hsmmc in -next tree switch to DMA_ENGINE entirely, so make MMC_OMAP* depend on DMA_OMAP and DMA_ENGINE, otherwise OMAP MMC/HSMMC won't work without enabling DMA_ENGINE and DMA_OMAP. The patch simply make them depend on DMA_OMAP since DMA_OMAP will select DMA_ENGINE automatically. Signed-off-by: Ming Lei ming@canonical.com --- drivers/mmc/host/Kconfig |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig index aa131b3..ef72c50 100644 --- a/drivers/mmc/host/Kconfig +++ b/drivers/mmc/host/Kconfig @@ -231,7 +231,7 @@ config MMC_SDHCI_S3C_DMA config MMC_OMAP tristate TI OMAP Multimedia Card Interface support - depends on ARCH_OMAP + depends on ARCH_OMAP DMA_OMAP select TPS65010 if MACH_OMAP_H2 help Thanks, - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child This selects the TI OMAP Multimedia card Interface. @@ -242,7 +242,7 @@ config MMC_OMAP config MMC_OMAP_HS tristate TI OMAP High Speed Multimedia Card Interface support - depends on SOC_OMAP2430 || ARCH_OMAP3 || ARCH_OMAP4 + depends on (SOC_OMAP2430 || ARCH_OMAP3 || ARCH_OMAP4) DMA_OMAP help This selects the TI OMAP High Speed Multimedia card Interface. If you have an OMAP2430 or OMAP3 board or OMAP4 board with a -- 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/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
* Javier Martinez Canillas martinez.jav...@gmail.com [120718 01:31]: That was my first approach in fact, I sent this patch: https://patchwork.kernel.org/patch/1198401/ But then was told by Kevin Hilman that the right solution was to do the select on the drives to fix not only omap2plus_defconfig but any config. So I sent this patch and Santosh agrees with Kevin. I don't really know the hardware nor the driver well enough to have a strong position on this. Ideally we would not select it or have depends on it. DMA channels can run out, and drivers need to work also without DMA. For doing distro kernels, building everything as modules should be an option rather than forcing to build in all kinds of code. 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 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
* Shilimkar, Santosh santosh.shilim...@ti.com [120718 02:49]: The patch simply make them depend on DMA_OMAP since DMA_OMAP will select DMA_ENGINE automatically This won't be true if the DMA selection are not done at ARCH_OMAP level as discussed in this thread. Having said that, I think Russell and Tony need to take call on how this needs to be handled. As the DMA channels can run out, drivers should also work without DMA. And building everything as modules should be possible for the distro kernels. So I'd rather not have either select or depends and have the drivers fixed. 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: [PATCHv6] arm/dts: omap4-sdp: Add keypad data
Hi,
On Fri, Jul 13, 2012 at 8:27 PM, Sourav Poddar sourav.pod...@ti.com wrote:
Add keypad data node in omap4 device tree file.
Also fill the device tree binding parameters
with the required value in omap4-sdp dts file.
Tested on omap4430 sdp with 3.5-rc6 kernel.
Cc: Tony Lindgren t...@atomide.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
This patch[1] was initially posted as a series.
The first patch[2] of the series is taken into
dmitry's input tree.
So, posting this as a independent patch .
[1]: https://lkml.org/lkml/2012/6/8/239
[2]: https://lkml.org/lkml/2012/6/1/75
Changes since v5:
Few key mappings were missed, added linux, keymap
data for those key mappings.
arch/arm/boot/dts/omap4-sdp.dts | 70
+++
arch/arm/boot/dts/omap4.dtsi|5 +++
2 files changed, 75 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index d08c4d1..53ded54 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -70,6 +70,76 @@
gpios = gpio5 11 0; /* 139 */
};
};
+
+ keypad@4a31c000 {
I think you should drop the address in node name since it does not
have a reg property.
+ keypad,num-rows = 8;
+ keypad,num-columns = 8;
+ linux,keymap = 0x0012
+ 0x00010013
+ 0x00020014
+ 0x00030066
+ 0x0004003f
+ 0x000500f0
+ 0x00060017
+ 0x0007002a
+ 0x0120
+ 0x01010021
+ 0x01020022
+ 0x010300e7
+ 0x01040040
+ 0x010500f0
+ 0x01060025
+ 0x0107001c
+ 0x022d
+ 0x0201002e
+ 0x0202002f
+ 0x0203006b
+ 0x02040041
+ 0x020500f0
+ 0x02060034
+ 0x0207003a
+ 0x032c
+ 0x0301004e
+ 0x03020030
+ 0x0303003b
+ 0x03040042
+ 0x030500f0
+ 0x03060018
+ 0x03070039
+ 0x0411
+ 0x04010015
+ 0x04020016
+ 0x0403003c
+ 0x04040073
+ 0x040500f0
+ 0x04060026
+ 0x04070069
+ 0x051f
+ 0x05010023
+ 0x05020024
+ 0x0503003d
+ 0x05040043
+ 0x05050072
+ 0x05060032
+ 0x0507006a
+ 0x0610
+ 0x0601001e
+ 0x06020031
+ 0x0603009e
+ 0x0604000e
+ 0x060500f0
+ 0x06060019
+ 0x06070067
+ 0x0794
+ 0x07010095
+ 0x070200ca
+ 0x070300cb
+ 0x0704003e
+ 0x070500f0
+ 0x07060160
+ 0x0707006c ;
+ linux,input-no-autorepeat;
+ };
};
i2c1 {
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 359c497..11b72d2 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -273,4 +273,9 @@
ti,needs-special-reset;
};
};
+
+ keypad@4a31c000 {
same comment here.
+ compatible = ti,omap4-keypad;
+ ti,hwmods = kbd;
+ };
};
Thanks
Kishon
--
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/1] ARM: OMAP2+: omap2plus_defconfig: enable OMAP DMA engine support
* Javier Martinez Canillas jav...@dowhile0.org [120716 16:33]: On Mon, Jul 16, 2012 at 7:12 PM, Kevin Hilman khil...@ti.com wrote: Javier Martinez Canillas jav...@dowhile0.org writes: commit 13f30fc893e4610f67dd7a8b0b67aec02eac1775 Author: Russell King rmk+ker...@arm.linux.org.uk Date: Sat Apr 21 22:41:10 2012 +0100 mmc: omap: remove private DMA API implementation removed the private DMA API implementation from the OMAP mmc host to make it use exclusively the DMA engine API. Unfortunately the omap2plus_defconfig doesn't enable this feature leading to the following error on an IGEPv2 Rev.C (and probably on most boards with MMC support): Personally, I'd rather see this fixed by having the drivers that depend on DMA engine 'select DMADEVICES'. That way, any defconfig will work correctly instead of just omap2plus_defconfig. Kevin Hi Kevin, Thanks a lot for your feedback. I'll do what you suggest and send a v2 of the patch. I'd rather see the drivers fixed to work with and without DMA as the channels can run out. Also forcing the select is not good for distro kernels. I'll apply this fix into l-o master branch while we're discussing the issue. 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: [PATCHv6 4/7] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count
On Thu, 2012-07-19 at 16:05 +0530, Shilimkar, Santosh wrote:
On Thu, Jul 19, 2012 at 3:19 PM, Tero Kristo t-kri...@ti.com wrote:
On Thu, 2012-07-19 at 00:55 -0500, Menon, Nishanth wrote:
On Wed, Jul 18, 2012 at 4:15 AM, Tero Kristo t-kri...@ti.com wrote:
On Tue, 2012-07-17 at 02:59 -0500, Menon, Nishanth wrote:
Couple of minor comments:
On Mon, Jun 11, 2012 at 10:26 AM, Tero Kristo t-kri...@ti.com
wrote:
[...]
/**
+ * _omap4_update_context_lost - increment hwmod context loss
counter
if
+ * hwmod context was lost, and clear hardware context loss reg
+ * @oh: hwmod to check for context loss
+ *
+ * If the PRCM indicates that the hwmod @oh lost context,
increment
+ * our in-memory context loss counter, and clear the RM_*_CONTEXT
+ * bits. No return value.
+ */
+static void _omap4_update_context_lost(struct omap_hwmod *oh)
+{
+ u32 r;
+
+ if (oh-prcm.omap4.context_offs == USHRT_MAX)
+ return;
would'nt it be better to return a dummy incremental counter instead
of
returning no context loss (count = 0)?
I guess you are right, this way we may have some extra context
restores
for modules which don't have context offs defined, rather than not
restoring them at all. Only thing I can think might prevent this is if
there are modules that never lose context but don't have context
register? How about omap5+?
there has been an interesting debate ongoing with HWAUTO and context
loss count handling - since we update only on _enable, this might
actually be interesting to consider:
enable
idle
un_idle (lost context)
read counter - no update
Now to handle modules that never loose context - they have to be in
wakeup domain.. should we consider a flag for those? would'nt matter
o5 or not, context is still the same.. this issue could be resolved if
counter update is done even when a check is done.
Yea, that would be an option. I think I'll add a flag for not losing
context ever.
You just access the module power domain from hwmod and then
you already know whether it is AON or not. The flag idea
was discussed in context of [1]. See if you can re-use that same idea.
That looks better still, thanks for the tip.
-Tero
--
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 v4 00/11] usb: musb: adding multi instance support
This series of patches adds, a) Multi instances support in musb driver b) DT support for musb_dsps glue layer c) DT support for NOP transceiver AM33xx and TI81xx has dual musb controller and has two usb PHY of same type. This patch series uses 'phandle' based API devm_usb_get_phy_by_phandle() to get the PHY of same type. This API support is being added by Kishon's patch discussed at [1] The series applies to linux-omap (master branch) + Vaibhav baseport patches on his tree at [3] + Kishon's multi phy patches on Felipe's branch 'xceiv' + Kishon's patch on phandle at [1] + AM33xx musb glue compile and bugfix patches at [4], [5], [6] and [7] + Damodar's recent patch at [2] and have been tested on Beaglebone board. 1. http://marc.info/?l=linux-usbm=134070369306112w=2 2. http://marc.info/?l=linux-usbm=134200284230689w=2 3. https://github.com/hvaibhav/am335x-linux/commits/am335x-upstream-staging 4. http://marc.info/?l=linux-usbm=134131746111637w=2 5. http://marc.info/?l=linux-usbm=134131746411639w=2 6. http://marc.info/?l=linux-usbm=134062716011251w=2 7. http://marc.info/?l=linux-usbm=134061179405213w=2 Changes from v3: - Fixed Kishon's comment on removing id from phy struct and removing unneeded #else part. Changes from v2: - Fixed Sergei's comment on not using address prefix in musb_dsps glue and nop transceiver dt dats. - Also removed the ti string in compatible property for nop data. Changes from v1: - Defined musb_ida to manage core ids based on Felipe's comment in [PATCH 01/11] Ajay Kumar Gupta (11): usb: musb: add musb-id to identify core instance usb: musb: kill global and static for multi instance usb: musb: am335x: add support for dual instance usb: otg: nop: add support for multiple tranceiver usb: musb: dsps: add dt support arm/dts: am33xx: Add dt data for usbss usb: otg: nop: add dt support arm/dts: am33xx: add dt data for usb nop phy usb: musb: dsps: remove explicit NOP device creation usb: musb: dsps: get the PHY using phandle api arm/dts: am33xx: add phy phandle to usbss .../devicetree/bindings/usb/am33xx-usb.txt | 19 ++ arch/arm/boot/dts/am33xx.dtsi | 21 +++ arch/arm/mach-omap2/board-omap3evm.c |2 +- drivers/usb/musb/am35x.c | 46 +++-- drivers/usb/musb/blackfin.c| 30 +++- drivers/usb/musb/da8xx.c | 38 +++-- drivers/usb/musb/davinci.c | 40 +++-- drivers/usb/musb/musb_core.c | 47 -- drivers/usb/musb/musb_core.h |8 + drivers/usb/musb/musb_debugfs.c| 14 +- drivers/usb/musb/musb_dsps.c | 189 ++-- drivers/usb/musb/omap2430.c| 26 ++- drivers/usb/musb/tusb6010.c| 32 +++- drivers/usb/musb/ux500.c | 33 +++- drivers/usb/otg/nop-usb-xceiv.c| 29 +++- include/linux/usb/otg.h|8 +- 16 files changed, 419 insertions(+), 163 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/am33xx-usb.txt -- 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 v4 05/11] usb: musb: dsps: add dt support
Added device tree support for dsps musb glue driver and updated the
Documentation with device tree binding information.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
.../devicetree/bindings/usb/am33xx-usb.txt | 14 +
drivers/usb/musb/musb_dsps.c | 60 +---
2 files changed, 65 insertions(+), 9 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/am33xx-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
new file mode 100644
index 000..ca8fa56
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -0,0 +1,14 @@
+AM33XX MUSB GLUE
+ - compatible : Should be ti,musb-am33xx
+ - ti,hwmods : must be usb_otg_hs
+ - multipoint : Should be 1 indicating the musb controller supports
+ multipoint. This is a MUSB configuration-specific setting.
+ - num_eps : Specifies the number of endpoints. This is also a
+ MUSB configuration-specific setting. Should be set to 16
+ - ram_bits : Specifies the ram address size. Should be set to 12
+ - port0_mode : Should be 3 to represent OTG. 1 signifies HOST and 2
+ represents PERIPHERAL.
+ - port1_mode : Should be 1 to represent HOST. 3 signifies OTG and 2
+ represents PERIPHERAL.
+ - power : Should be 250. This signifies the controller can supply upto
+ 500mA when operating in host mode.
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 9fcacff..ac9f58b 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -31,6 +31,7 @@
#include linux/init.h
#include linux/io.h
+#include linux/of.h
#include linux/err.h
#include linux/platform_device.h
#include linux/dma-mapping.h
@@ -45,6 +46,10 @@
#include musb_core.h
+#ifdef CONFIG_OF
+static const struct of_device_id musb_dsps_of_match[];
+#endif
+
/**
* avoid using musb_readx()/musb_writex() as glue layer should not be
* dependent on musb core layer symbols.
@@ -496,6 +501,8 @@ static int __devinit dsps_create_musb_pdev(struct dsps_glue
*glue, u8 id)
struct device *dev = glue-dev;
struct platform_device *pdev = to_platform_device(dev);
struct musb_hdrc_platform_data *pdata = dev-platform_data;
+ struct device_node *np = pdev-dev.of_node;
+ struct musb_hdrc_config *config;
struct platform_device *musb;
struct resource *res;
struct resource resources[2];
@@ -562,14 +569,40 @@ static int __devinit dsps_create_musb_pdev(struct
dsps_glue *glue, u8 id)
glue-musb[id] = musb;
- pdata-platform_ops = dsps_ops;
-
ret = platform_device_add_resources(musb, resources, 2);
if (ret) {
dev_err(dev, failed to add resources\n);
goto err2;
}
+ if (np) {
+ pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(pdev-dev,
+ failed to allocate musb platfrom data\n);
+ ret = -ENOMEM;
+ goto err2;
+ }
+
+ config = devm_kzalloc(pdev-dev, sizeof(*config), GFP_KERNEL);
+ if (!config) {
+ dev_err(pdev-dev,
+ failed to allocate musb hdrc config\n);
+ goto err2;
+ }
+
+ of_property_read_u32(np, num_eps, (u32 *)config-num_eps);
+ of_property_read_u32(np, ram_bits, (u32 *)config-ram_bits);
+ sprintf(res_name, port%d_mode, id);
+ of_property_read_u32(np, res_name, (u32 *)pdata-mode);
+ of_property_read_u32(np, power, (u32 *)pdata-power);
+ config-multipoint = of_property_read_bool(np, multipoint);
+
+ pdata-config = config;
+ }
+
+ pdata-platform_ops = dsps_ops;
+
ret = platform_device_add_data(musb, pdata, sizeof(*pdata));
if (ret) {
dev_err(dev, failed to add platform_data\n);
@@ -601,14 +634,22 @@ static void __devexit dsps_delete_musb_pdev(struct
dsps_glue *glue, u8 id)
static int __devinit dsps_probe(struct platform_device *pdev)
{
- const struct platform_device_id *id = platform_get_device_id(pdev);
- const struct dsps_musb_wrapper *wrp =
- (struct dsps_musb_wrapper *)id-driver_data;
+ struct device_node *np = pdev-dev.of_node;
+ const struct of_device_id *match;
+ const struct dsps_musb_wrapper *wrp;
struct dsps_glue *glue;
struct resource *iomem;
u32 __iomem *usbss;
int ret, i;
+ match = of_match_node(musb_dsps_of_match, np);
+ if (!match) {
+ dev_err(pdev-dev, fail to get matching of_match struct\n);
+ ret = -EINVAL;
+ goto err0;
+ }
+
[PATCH v4 06/11] arm/dts: am33xx: Add dt data for usbss
Added device tree data for usbss on am33xx. There are two musb controllers
on am33xx platform so have port0_mode and port1_mode additional data.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 59509c4..08e9a40 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -154,5 +154,16 @@
#size-cells = 0;
ti,hwmods = i2c3;
};
+
+ usb_otg_hs: usb_otg_hs {
+ compatible = ti,musb-am33xx;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+ port0_mode = 3;
+ port1_mode = 1;
+ power = 250;
+ };
};
};
--
1.7.0.4
--
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 v4 08/11] arm/dts: am33xx: add dt data for usb nop phy
AM33xx has two musb controller and they have one NOP PHY each.
Added the device tree data for NOP PHY.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 08e9a40..b03a9b5 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -155,6 +155,14 @@
ti,hwmods = i2c3;
};
+ usb0_phy: phy0 {
+ compatible = nop-xceiv-usb;
+ };
+
+ usb1_phy: phy1 {
+ compatible = nop-xceiv-usb;
+ };
+
usb_otg_hs: usb_otg_hs {
compatible = ti,musb-am33xx;
ti,hwmods = usb_otg_hs;
--
1.7.0.4
--
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 v4 04/11] usb: otg: nop: add support for multiple tranceiver
Currently we have one single nop transceiver support as same is
defined as a global variable in drivers/usb/otg/nop-usb-xceiv.c.
This need to be changed to support multiple otg controller each
using nop transceiver on a platform such as am335x.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c |2 +-
drivers/usb/musb/am35x.c |4 ++--
drivers/usb/musb/blackfin.c |4 ++--
drivers/usb/musb/da8xx.c |4 ++--
drivers/usb/musb/davinci.c |6 +++---
drivers/usb/musb/musb_dsps.c | 10 +-
drivers/usb/musb/tusb6010.c |6 +++---
drivers/usb/otg/nop-usb-xceiv.c | 19 +++
include/linux/usb/otg.h |8
9 files changed, 33 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index ef230a0..a3393bc 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -704,7 +704,7 @@ static void __init omap3_evm_init(void)
omap_sdrc_init(mt46h32m32lf6_sdrc_params, NULL);
/* OMAP3EVM uses ISP1504 phy and so register nop transceiver */
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(0);
if (get_omap3_evm_rev() = OMAP3EVM_BOARD_GEN_2) {
/* enable EHCI VBUS using GPIO22 */
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 01203eb..eb6220f 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -364,7 +364,7 @@ static int am35x_musb_init(struct musb *musb)
if (!rev)
return -ENODEV;
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(musb-id);
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv))
return -ENODEV;
@@ -408,7 +408,7 @@ static int am35x_musb_exit(struct musb *musb)
data-set_phy_power(0);
usb_put_phy(musb-xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb-xceiv);
return 0;
}
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index c848b82..03d081c 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -415,7 +415,7 @@ static int bfin_musb_init(struct musb *musb)
}
gpio_direction_output(musb-config-gpio_vrsel, 0);
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(musb-id);
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv)) {
gpio_free(musb-config-gpio_vrsel);
@@ -442,7 +442,7 @@ static int bfin_musb_exit(struct musb *musb)
gpio_free(musb-config-gpio_vrsel);
usb_put_phy(musb-xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb-xceiv);
return 0;
}
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index cebd9d7..3ce4a92 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -425,7 +425,7 @@ static int da8xx_musb_init(struct musb *musb)
if (!rev)
goto fail;
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(musb-id);
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv))
goto fail;
@@ -460,7 +460,7 @@ static int da8xx_musb_exit(struct musb *musb)
phy_off();
usb_put_phy(musb-xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb-xceiv);
return 0;
}
diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
index 3f094f2..d5156b3 100644
--- a/drivers/usb/musb/davinci.c
+++ b/drivers/usb/musb/davinci.c
@@ -385,7 +385,7 @@ static int davinci_musb_init(struct musb *musb)
void __iomem*tibase = musb-ctrl_base;
u32 revision;
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(musb-id);
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv))
goto unregister;
@@ -447,7 +447,7 @@ static int davinci_musb_init(struct musb *musb)
fail:
usb_put_phy(musb-xceiv);
unregister:
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb-xceiv);
return -ENODEV;
}
@@ -496,7 +496,7 @@ static int davinci_musb_exit(struct musb *musb)
phy_off();
usb_put_phy(musb-xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb-xceiv);
return 0;
}
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index a2c8a06..9fcacff 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -420,8 +420,8 @@ static int dsps_musb_init(struct musb *musb)
/* mentor core register starts at offset of 0x400 from musb base */
musb-mregs += wrp-musb_core_offset;
- /* NOP driver needs change if supporting dual instance */
-
[PATCH v4 03/11] usb: musb: am335x: add support for dual instance
AM335x and TI81xx platform has dual musb controller so updating the
musb_dspc.c to support the same.
Changes:
- Moved otg_workaround timer to glue structure
- Moved static local variable last_timer to glue structure
- PHY on/off related cleanups
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
drivers/usb/musb/musb_dsps.c | 93 +
1 files changed, 57 insertions(+), 36 deletions(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 2174699..a2c8a06 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -105,6 +105,8 @@ struct dsps_musb_wrapper {
/* miscellaneous stuff */
u32 musb_core_offset;
u8 poll_seconds;
+ /* number of musb instances */
+ u8 instances;
};
/**
@@ -112,16 +114,18 @@ struct dsps_musb_wrapper {
*/
struct dsps_glue {
struct device *dev;
- struct platform_device *musb; /* child musb pdev */
+ struct platform_device *musb[2];/* child musb pdev */
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
- struct timer_list timer;/* otg_workaround timer */
- u32 __iomem *usb_ctrl;
+ struct timer_list timer[2]; /* otg_workaround timer */
+ unsigned long last_timer[2];/* last timer data for each instance */
+ u32 __iomem *usb_ctrl[2];
u8 usbss_rev;
};
/**
* musb_dsps_phy_control - phy on/off
* @glue: struct dsps_glue *
+ * @id: musb instance
* @on: flag for phy to be switched on or off
*
* This is to enable the PHY using usb_ctrl register in system control
@@ -130,11 +134,11 @@ struct dsps_glue {
* XXX: This function will be removed once we have a seperate driver for
* control module
*/
-static void musb_dsps_phy_control(struct dsps_glue *glue, u8 on)
+static void musb_dsps_phy_control(struct dsps_glue *glue, u8 id, u8 on)
{
u32 usbphycfg;
- usbphycfg = __raw_readl(glue-usb_ctrl);
+ usbphycfg = __raw_readl(glue-usb_ctrl[id]);
if (on) {
if (glue-usbss_rev == MUSB_USBSS_REV_816X) {
@@ -157,7 +161,7 @@ static void musb_dsps_phy_control(struct dsps_glue *glue,
u8 on)
glue-usbss_rev == MUSB_USBSS_REV_33XX)
usbphycfg |= USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN;
}
- __raw_writel(usbphycfg, glue-usb_ctrl);
+ __raw_writel(usbphycfg, glue-usb_ctrl[id]);
}
/**
* dsps_musb_enable - enable interrupts
@@ -247,7 +251,7 @@ static void otg_timer(unsigned long _musb)
devctl = dsps_readb(mregs, MUSB_DEVCTL);
if (devctl MUSB_DEVCTL_BDEVICE)
- mod_timer(glue-timer,
+ mod_timer(glue-timer[musb-id],
jiffies + wrp-poll_seconds * HZ);
else
musb-xceiv-state = OTG_STATE_A_IDLE;
@@ -263,7 +267,6 @@ static void dsps_musb_try_idle(struct musb *musb, unsigned
long timeout)
struct device *dev = musb-controller;
struct platform_device *pdev = to_platform_device(dev-parent);
struct dsps_glue *glue = platform_get_drvdata(pdev);
- static unsigned long last_timer;
if (!is_otg_enabled(musb))
return;
@@ -276,22 +279,23 @@ static void dsps_musb_try_idle(struct musb *musb,
unsigned long timeout)
musb-xceiv-state == OTG_STATE_A_WAIT_BCON)) {
dev_dbg(musb-controller, %s active, deleting timer\n,
otg_state_string(musb-xceiv-state));
- del_timer(glue-timer);
- last_timer = jiffies;
+ del_timer(glue-timer[musb-id]);
+ glue-last_timer[musb-id] = jiffies;
return;
}
- if (time_after(last_timer, timeout) timer_pending(glue-timer)) {
+ if (time_after(glue-last_timer[musb-id], timeout)
+ timer_pending(glue-timer[musb-id])) {
dev_dbg(musb-controller,
Longer idle timer already pending, ignoring...\n);
return;
}
- last_timer = timeout;
+ glue-last_timer[musb-id] = timeout;
dev_dbg(musb-controller, %s inactive, starting idle timer for %u
ms\n,
otg_state_string(musb-xceiv-state),
jiffies_to_msecs(timeout - jiffies));
- mod_timer(glue-timer, timeout);
+ mod_timer(glue-timer[musb-id], timeout);
}
static irqreturn_t dsps_interrupt(int irq, void *hci)
@@ -360,7 +364,7 @@ static irqreturn_t dsps_interrupt(int irq, void *hci)
*/
musb-int_usb = ~MUSB_INTR_VBUSERROR;
musb-xceiv-state = OTG_STATE_A_WAIT_VFALL;
- mod_timer(glue-timer,
+
[PATCH v4 09/11] usb: musb: dsps: remove explicit NOP device creation
As NOP device node is now added in am33xx tree so remove the call which creates the NOP platform_device. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com --- drivers/usb/musb/musb_dsps.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index ac9f58b..78c88fd 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -425,8 +425,7 @@ static int dsps_musb_init(struct musb *musb) /* mentor core register starts at offset of 0x400 from musb base */ musb-mregs += wrp-musb_core_offset; - /* Register NOP driver */ - usb_nop_xceiv_register(musb-id); + /* Get the NOP PHY */ musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2); if (IS_ERR_OR_NULL(musb-xceiv)) return -ENODEV; -- 1.7.0.4 -- 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 v4 01/11] usb: musb: add musb-id to identify core instance
Added 'id' field within 'struct musb' which can be used to determine
the current instance of musb controller.
Also defined musb_ida in musb_core.c to manage the core ids.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
drivers/usb/musb/am35x.c | 42 --
drivers/usb/musb/blackfin.c | 26 --
drivers/usb/musb/da8xx.c | 34 --
drivers/usb/musb/davinci.c | 34 --
drivers/usb/musb/musb_core.c | 31 +++
drivers/usb/musb/musb_core.h |4
drivers/usb/musb/musb_dsps.c | 25 ++---
drivers/usb/musb/omap2430.c | 26 --
drivers/usb/musb/tusb6010.c | 26 --
drivers/usb/musb/ux500.c | 33 +++--
10 files changed, 212 insertions(+), 69 deletions(-)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 7a95ab8..01203eb 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -468,6 +468,7 @@ static int __devinit am35x_probe(struct platform_device
*pdev)
struct clk *clk;
int ret = -ENOMEM;
+ int musbid;
glue = kzalloc(sizeof(*glue), GFP_KERNEL);
if (!glue) {
@@ -475,38 +476,47 @@ static int __devinit am35x_probe(struct platform_device
*pdev)
goto err0;
}
- musb = platform_device_alloc(musb-hdrc, -1);
+ /* get the musb id */
+ musbid = musb_get_id(pdev-dev, GFP_KERNEL);
+ if (musbid 0) {
+ dev_err(pdev-dev, failed to allocate musb id\n);
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ musb = platform_device_alloc(musb-hdrc, musbid);
if (!musb) {
dev_err(pdev-dev, failed to allocate musb device\n);
- goto err1;
+ goto err2;
}
phy_clk = clk_get(pdev-dev, fck);
if (IS_ERR(phy_clk)) {
dev_err(pdev-dev, failed to get PHY clock\n);
ret = PTR_ERR(phy_clk);
- goto err2;
+ goto err3;
}
clk = clk_get(pdev-dev, ick);
if (IS_ERR(clk)) {
dev_err(pdev-dev, failed to get clock\n);
ret = PTR_ERR(clk);
- goto err3;
+ goto err4;
}
ret = clk_enable(phy_clk);
if (ret) {
dev_err(pdev-dev, failed to enable PHY clock\n);
- goto err4;
+ goto err5;
}
ret = clk_enable(clk);
if (ret) {
dev_err(pdev-dev, failed to enable clock\n);
- goto err5;
+ goto err6;
}
+ musb-id= musbid;
musb-dev.parent= pdev-dev;
musb-dev.dma_mask = am35x_dmamask;
musb-dev.coherent_dma_mask = am35x_dmamask;
@@ -524,38 +534,41 @@ static int __devinit am35x_probe(struct platform_device
*pdev)
pdev-num_resources);
if (ret) {
dev_err(pdev-dev, failed to add resources\n);
- goto err6;
+ goto err7;
}
ret = platform_device_add_data(musb, pdata, sizeof(*pdata));
if (ret) {
dev_err(pdev-dev, failed to add platform_data\n);
- goto err6;
+ goto err7;
}
ret = platform_device_add(musb);
if (ret) {
dev_err(pdev-dev, failed to register musb device\n);
- goto err6;
+ goto err7;
}
return 0;
-err6:
+err7:
clk_disable(clk);
-err5:
+err6:
clk_disable(phy_clk);
-err4:
+err5:
clk_put(clk);
-err3:
+err4:
clk_put(phy_clk);
-err2:
+err3:
platform_device_put(musb);
+err2:
+ musb_put_id(pdev-dev, musbid);
+
err1:
kfree(glue);
@@ -567,6 +580,7 @@ static int __devexit am35x_remove(struct platform_device
*pdev)
{
struct am35x_glue *glue = platform_get_drvdata(pdev);
+ musb_put_id(pdev-dev, glue-musb-id);
platform_device_del(glue-musb);
platform_device_put(glue-musb);
clk_disable(glue-clk);
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index 428e6aa..c848b82 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -471,6 +471,7 @@ static int __devinit bfin_probe(struct platform_device
*pdev)
struct bfin_glue*glue;
int ret = -ENOMEM;
+ int musbid;
glue = kzalloc(sizeof(*glue), GFP_KERNEL);
if (!glue) {
@@ -478,12 +479,21 @@ static int __devinit bfin_probe(struct platform_device
*pdev)
goto err0;
[PATCH v4 11/11] arm/dts: am33xx: add phy phandle to usbss
Added NOP PHY phandle to usbss device node as same will be used to get the phy from otg framework. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com --- arch/arm/boot/dts/am33xx.dtsi |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index b03a9b5..d3ab69a 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -172,6 +172,8 @@ port0_mode = 3; port1_mode = 1; power = 250; + usb0-phy = usb0_phy; + usb1-phy = usb1_phy; }; }; }; -- 1.7.0.4 -- 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 v4 07/11] usb: otg: nop: add dt support
Added device tree support for nop transceiver driver and updated the
Documentation with device tree binding information for am33xx platform.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
.../devicetree/bindings/usb/am33xx-usb.txt |3 +++
drivers/usb/otg/nop-usb-xceiv.c| 10 ++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
index ca8fa56..9782585 100644
--- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -12,3 +12,6 @@ AM33XX MUSB GLUE
represents PERIPHERAL.
- power : Should be 250. This signifies the controller can supply upto
500mA when operating in host mode.
+
+NOP USB PHY
+ - compatible : Should be nop-xceiv-usb
diff --git a/drivers/usb/otg/nop-usb-xceiv.c b/drivers/usb/otg/nop-usb-xceiv.c
index aa2f767..2788a00 100644
--- a/drivers/usb/otg/nop-usb-xceiv.c
+++ b/drivers/usb/otg/nop-usb-xceiv.c
@@ -27,6 +27,7 @@
*/
#include linux/module.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/usb/otg.h
@@ -151,12 +152,21 @@ static int __devexit nop_usb_xceiv_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id nop_xceiv_id_table[] = {
+ { .compatible = nop-xceiv-usb },
+ {}
+};
+MODULE_DEVICE_TABLE(of, nop_xceiv_id_table);
+#endif
+
static struct platform_driver nop_usb_xceiv_driver = {
.probe = nop_usb_xceiv_probe,
.remove = __devexit_p(nop_usb_xceiv_remove),
.driver = {
.name = nop_usb_xceiv,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(nop_xceiv_id_table),
},
};
--
1.7.0.4
--
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 v4 02/11] usb: musb: kill global and static for multi instance
Moved global variable musb_debugfs_root and static variable
old_state to 'struct musb' to help support multi instance of
musb controller as present on AM335x platform.
Also removed the global variable orig_dma_mask and filled the
dev-dma_mask with parent device's dma_mask.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
drivers/usb/musb/musb_core.c| 16 +++-
drivers/usb/musb/musb_core.h|4
drivers/usb/musb/musb_debugfs.c | 14 --
3 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 3e09984..a5db4dd 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1802,10 +1802,9 @@ static const struct attribute_group musb_attr_group = {
static void musb_irq_work(struct work_struct *data)
{
struct musb *musb = container_of(data, struct musb, irq_work);
- static int old_state;
- if (musb-xceiv-state != old_state) {
- old_state = musb-xceiv-state;
+ if (musb-xceiv-state != musb-xceiv_old_state) {
+ musb-xceiv_old_state = musb-xceiv-state;
sysfs_notify(musb-controller-kobj, NULL, mode);
}
}
@@ -2115,11 +2114,6 @@ fail0:
/* all implementations (PCI bridge to FPGA, VLYNQ, etc) should just
* bridge to a platform device; this driver then suffices.
*/
-
-#ifndef CONFIG_MUSB_PIO_ONLY
-static u64 *orig_dma_mask;
-#endif
-
static int __devinit musb_probe(struct platform_device *pdev)
{
struct device *dev = pdev-dev;
@@ -2138,10 +2132,6 @@ static int __devinit musb_probe(struct platform_device
*pdev)
return -ENOMEM;
}
-#ifndef CONFIG_MUSB_PIO_ONLY
- /* clobbered by use_dma=n */
- orig_dma_mask = dev-dma_mask;
-#endif
status = musb_init_controller(dev, irq, base);
if (status 0)
iounmap(base);
@@ -2166,7 +2156,7 @@ static int __devexit musb_remove(struct platform_device
*pdev)
iounmap(ctrl_base);
device_init_wakeup(pdev-dev, 0);
#ifndef CONFIG_MUSB_PIO_ONLY
- pdev-dev.dma_mask = orig_dma_mask;
+ pdev-dev.dma_mask = (dev-dev.parent)-dma_mask;
#endif
return 0;
}
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 69ed141..6b6cee9 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -452,6 +452,10 @@ struct musb {
#endif
/* id for multiple musb instances */
u8 id;
+ int xceiv_old_state;
+#ifdef CONFIG_DEBUG_FS
+ struct dentry *debugfs_root;
+#endif
};
static inline struct musb *gadget_to_musb(struct usb_gadget *g)
diff --git a/drivers/usb/musb/musb_debugfs.c b/drivers/usb/musb/musb_debugfs.c
index 40a37c9..b1e8f21 100644
--- a/drivers/usb/musb/musb_debugfs.c
+++ b/drivers/usb/musb/musb_debugfs.c
@@ -103,8 +103,6 @@ static const struct musb_register_map musb_regmap[] = {
{ }/* Terminating Entry */
};
-static struct dentry *musb_debugfs_root;
-
static int musb_regdump_show(struct seq_file *s, void *unused)
{
struct musb *musb = s-private;
@@ -240,20 +238,24 @@ int __devinit musb_init_debugfs(struct musb *musb)
struct dentry *root;
struct dentry *file;
int ret;
+ charname[10];
- root = debugfs_create_dir(musb, NULL);
+ sprintf(name, musb%d, musb-id);
+ root = debugfs_create_dir(name, NULL);
if (!root) {
ret = -ENOMEM;
goto err0;
}
- file = debugfs_create_file(regdump, S_IRUGO, root, musb,
+ sprintf(name, regdump%d, musb-id);
+ file = debugfs_create_file(name, S_IRUGO, root, musb,
musb_regdump_fops);
if (!file) {
ret = -ENOMEM;
goto err1;
}
+ sprintf(name, testmode%d, musb-id);
file = debugfs_create_file(testmode, S_IRUGO | S_IWUSR,
root, musb, musb_test_mode_fops);
if (!file) {
@@ -261,7 +263,7 @@ int __devinit musb_init_debugfs(struct musb *musb)
goto err1;
}
- musb_debugfs_root = root;
+ musb-debugfs_root = root;
return 0;
@@ -274,5 +276,5 @@ err0:
void /* __init_or_exit */ musb_exit_debugfs(struct musb *musb)
{
- debugfs_remove_recursive(musb_debugfs_root);
+ debugfs_remove_recursive(musb-debugfs_root);
}
--
1.7.0.4
--
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 v4 10/11] usb: musb: dsps: get the PHY using phandle api
AM33xx has two PHY of same type used by each musb controller so use phandle of phy nodes to get the phy pointer. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com --- .../devicetree/bindings/usb/am33xx-usb.txt |2 ++ drivers/usb/musb/musb_dsps.c |4 +++- 2 files changed, 5 insertions(+), 1 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt b/Documentation/devicetree/bindings/usb/am33xx-usb.txt index 9782585..e2702df 100644 --- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt +++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt @@ -12,6 +12,8 @@ AM33XX MUSB GLUE represents PERIPHERAL. - power : Should be 250. This signifies the controller can supply upto 500mA when operating in host mode. + - usb0-phy : phandle for usb0 NOP PHY + - usb1-phy : phandle for usb1 NOP PHY NOP USB PHY - compatible : Should be nop-xceiv-usb diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index 78c88fd..ab6b74c 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -419,6 +419,7 @@ static int dsps_musb_init(struct musb *musb) struct dsps_glue *glue = platform_get_drvdata(pdev); const struct dsps_musb_wrapper *wrp = glue-wrp; void __iomem *reg_base = musb-ctrl_base; + char name[10]; u32 rev, val; int status; @@ -426,7 +427,8 @@ static int dsps_musb_init(struct musb *musb) musb-mregs += wrp-musb_core_offset; /* Get the NOP PHY */ - musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2); + sprintf(name, usb%d-phy, musb-id); + musb-xceiv = devm_usb_get_phy_by_phandle(pdev-dev, name); if (IS_ERR_OR_NULL(musb-xceiv)) return -ENODEV; -- 1.7.0.4 -- 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: [PATCHv6 4/7] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count
On Thu, 2012-07-19 at 05:27 -0500, Menon, Nishanth wrote: On Thu, Jul 19, 2012 at 4:49 AM, Tero Kristo t-kri...@ti.com wrote: Zero doesn't mean no context loss. If counter was previous MAX_INT, if it goes to zero it is still a context loss, as the counter value differs. Drivers do check against diff in the context loss counter, and if there is one, they do restore which is the right way to handle it. No need to unnecessarily make this more complicated than it is. so we flip the responsibility of overflow to drivers. considering a similar scenario of jiffies /* * These inlines deal with timer wrapping correctly. You are * strongly encouraged to use them * 1. Because people otherwise forget * 2. Because if the timer wrap changes in future you won't have to * alter your driver code. * * time_after(a,b) returns true if the time a is after time b. ... */ from past experience, it is highly possible that drivers never get this right. if the intent is just to let the drivers know context was lost, why not go back to the alternate possibility of a bool lost_context which tells the driver if it lost context since it last called the lost_context api. This goes to the discussion whether the API of lost context stuff is correct or not, and goes out of scope for this set. I am just attempting to bring omap4 to omap3 level in the first place, we can discuss about the potential API problems separately, and a change like that should be relatively easy to implement anyway but will break several drivers. -Tero -- 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] ARM: OMAP3: clockdomain: fix accidental duplicate registration
* Paul Walmsley p...@pwsan.com [120718 02:58]: Hi On Mon, 16 Jul 2012, Tony Lindgren wrote: Hmm well it seems that we should apply this fix into arm-soc next/cleanup branch if that's where the mismerge happened? It seems the same mismerge is there even without 16e5e2c4? The arm-soc next/cleanup copy of mach-omap2/clockdomains3xxx_data.c is correct. The problem that my patch was designed to fix doesn't exist in that version of the file (868c157df9721675c19729eed2c96bac6c3f1d01). OK You patch applies into arm-soc next/cleanup with fuzz: patching file arch/arm/mach-omap2/clockdomain.c patching file arch/arm/mach-omap2/clockdomain.h Hunk #1 succeeded at 82 (offset -4 lines). patching file arch/arm/mach-omap2/clockdomains3xxx_data.c Hunk #1 succeeded at 347 with fuzz 2 (offset -107 lines). So that's why I'm wondering if it needs some changes. OK, I understand why you're asking. I went back and researched it. The patch that I sent is only needed because the conflict resolution in merge commit 3dd50d0545bd5a8ad83d4339f07935cd3e883271 (Merge tag 'omap-cleanup-for-v3.6' into tmp-merge) adds mpu_3xxx_clkdm back into the clockdomains_common list. The previous commit on that file 16e5e2c471ab889f838bfe1c44032d0481c115e1 removed mpu_3xxx_clkdm from the common list, because the AM35xx chips needed to use a different MPU clockdomain structure from the OMAP3xxx chips. Or, put differently: Before 16e5e2c471ab889f838bfe1c44032d0481c115e1, it was correct to have mpu_3xxx_clkdm in the common list. That's what's in arm-soc next/cleanup and that data is correct. After 16e5e2c471ab889f838bfe1c44032d0481c115e1, it's incorrect to have mpu_3xxx_clkdm in the common list. Hope this isn't even more confusing :-) Well I'm still a bit confused :) Which branch in arm-soc tree should this fix be applied then? Or do we actually need two fixes into arm-soc tree? 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
On Thu, Jul 19, 2012 at 3:50 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Thu, Jun 21, 2012 at 07:12:12PM +0530, Keshava Munegowda wrote: This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) is causing the usb hub and device detection fails in beagle XM causeing NFS not functional. This affects the core retention too. The same commit logic needs to be revisted adhering to hwmod and device tree framework. for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) reverted. This patch is validated on BeagleXM with NFS support over usb ethernet and USB mass storage and other device detection. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Acked-by: Felipe Balbi ba...@ti.com turns out this is causing other issues and another version of the patch will be provided. Greg, Alan, this is basically a git revert of the commit id listed above. -- balbi Thanks Felipe regards keshava -- 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
[RFC][PATCH v2 1/1] ARM: OMAP2+: PM: Register suspend ops even in the presence of DT blob
As per the comment in omap2_common_late_init() looks like the
original intent of the DT check was to treat only the PMIC
and SR initialization differently. Recent changes to consolidate
the suspend-resume code across OMAP3/4 resulted into the
registration of suspend ops also being dependent on the check
for DT blob. Since the suspend-resume operation should not
really be dependent on the usage of DT remove this dependency
by wrapping the PMIC and SR init under the DT check.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
---
v2-v1
- As suggested by Paul, Instead of moving around the suspend ops
registration just wrap the PMIC and SR init under the DT check.
- Fixed up Kevin's email address :\
arch/arm/mach-omap2/pm.c | 21 ++---
1 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 9cb5ced..46848f7 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -302,19 +302,18 @@ int __init omap2_common_pm_late_init(void)
* a completely different mechanism.
* Disable this part if a DT blob is available.
*/
- if (of_have_populated_dt())
- return 0;
+ if (!of_have_populated_dt()) {
+ /* Init the voltage layer */
+ omap_pmic_late_init();
+ omap_voltage_late_init();
- /* Init the voltage layer */
- omap_pmic_late_init();
- omap_voltage_late_init();
+ /* Initialize the voltages */
+ omap3_init_voltages();
+ omap4_init_voltages();
- /* Initialize the voltages */
- omap3_init_voltages();
- omap4_init_voltages();
-
- /* Smartreflex device init */
- omap_devinit_smartreflex();
+ /* Smartreflex device init */
+ omap_devinit_smartreflex();
+ }
#ifdef CONFIG_SUSPEND
suspend_set_ops(omap_pm_ops);
--
1.7.0.4
--
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: OMAP PM late init with DT blob
On Wed, Jul 18, 2012 at 21:52:41, Paul Walmsley wrote: On Wed, 18 Jul 2012, Bedia, Vaibhav wrote: I checked the different inits which get skipped right now. I think _init_voltages() should not really be dependent on the DT check to cover the cases wherein the voltages are controlled using a regular regulator driver. However right now I don't know what approach to take here. For now I have sent an RFC patch [1] with just the movement of suspend ops. That seems reasonable based on a quick glance. Why not update your patch to just keep that code where it is and wrap the the pmic and voltage late init in that DT test? Done. I had somehow messed up Kevin's address also :\ Fixed now. Regards, Vaibhav -- 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] regulator: tps65217: fix build error if REGULATOR is not enabled
Hi Mark, On Wed, Jul 18, 2012 at 15:30:13, Mark Brown wrote: On Wed, Jul 18, 2012 at 09:55:57AM +, AnilKumar, Chimata wrote: Regulators platform data is added to platform device in MFD driver, which we need for regulator driver, of_regulator_match() is used to check the regulator consumers if we pass DT data. If we do not enable CONFIG_REGULATOR then of_regulator_match() is not exported, so we see this error. Why are you doing that in the MFD driver? I got your point, I referred tps6586x driver while developing the initial driver. Based on tps6586x MFD driver I added REGULATOR flag. I think tps6586x MFD driver need to be cleaned up. I will submit a patch to make tps65217 MFD driver independent of REGULATOR framework. Thanks AnilKumar-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 09/11] drivers: usb: musb: Add device tree support for omap musb glue
Hi,
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt | 34 -
drivers/usb/musb/omap2430.c| 55
2 files changed, 88 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 80a28c9..39cdffb 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -1,4 +1,4 @@
-OMAP USB PHY
+OMAP USB PHY AND GLUE
OMAP USB2 PHY
@@ -14,3 +14,35 @@ usb2phy@0x4a0ad080 {
compatible = ti,omap-usb2;
reg = 0x4a0ad080 0x58;
};
+
+OMAP MUSB GLUE
+ - compatible : Should be ti,musb-omap2430
+ - ti,hwmods : must be usb_otg_hs
+ - multipoint : Should be 1 indicating the musb controller supports
+ multipoint. This is a MUSB configuration-specific setting.
+ - num_eps : Specifies the number of endpoints. This is also a
+ MUSB configuration-specific setting. Should be set to 16
+ - ram_bits : Specifies the ram address size. Should be set to 12
+ - interface_type : This is a board specific setting to describe the type
of
+ interface between the controller and the phy. It should be 0 or 1
+ specifying ULPI and UTMI respectively.
+ - mode : Should be 3 to represent OTG. 1 signifies HOST and 2
+ represents PERIPHERAL.
+ - power : Should be 50. This signifies the controller can supply upto
+ 100mA when operating in host mode.
+
+SOC specific device node entry
+usb_otg_hs: usb_otg_hs@4a0ab000 {
+ compatible = ti,musb-omap2430;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+};
+
+Board specific device node entry
+usb_otg_hs {
+ interface_type = 1;
+ mode = 3;
+ power = 50;
+};
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index addbebf..331e477 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -30,6 +30,7 @@
#include linux/init.h
#include linux/list.h
#include linux/io.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/pm_runtime.h
@@ -469,8 +470,11 @@ static u64 omap2430_dmamask = DMA_BIT_MASK(32);
static int __devinit omap2430_probe(struct platform_device *pdev)
{
struct musb_hdrc_platform_data *pdata = pdev-dev.platform_data;
+ struct omap_musb_board_data *data;
struct platform_device *musb;
struct omap2430_glue*glue;
+ struct device_node *np = pdev-dev.of_node;
+ struct musb_hdrc_config *config;
struct resource *res;
int ret = -ENOMEM;
@@ -500,6 +504,43 @@ static int __devinit omap2430_probe(struct
platform_device *pdev)
if (glue-control_otghs == NULL)
dev_dbg(pdev-dev, Failed to obtain control memory\n);
+ if (np) {
+ pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(pdev-dev,
+ failed to allocate musb platfrom data\n);
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ dev_err(pdev-dev,
+ failed to allocate musb board data\n);
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ config = devm_kzalloc(pdev-dev, sizeof(*config), GFP_KERNEL);
+ if (!data) {
+ dev_err(pdev-dev,
+ failed to allocate musb hdrc config\n);
+ goto err1;
+ }
+
+ of_property_read_u32(np, mode, (u32 *)pdata-mode);
+ of_property_read_u32(np, interface_type,
+ (u32 *)data-interface_type);
+ of_property_read_u32(np, num_eps, (u32 *)config-num_eps);
+ of_property_read_u32(np, ram_bits, (u32 *)config-ram_bits);
+ of_property_read_u32(np, mode, (u32 *)pdata-mode);
pdata-mode is already read so above should be removed.
Ajay
+ of_property_read_u32(np, power, (u32 *)pdata-power);
+ config-multipoint = of_property_read_bool(np, multipoint);
+
+ pdata-board_data = data;
+ pdata-config = config;
+ }
+
pdata-platform_ops = omap2430_ops;
platform_set_drvdata(pdev, glue);
@@ -597,12 +638,26 @@ static struct dev_pm_ops omap2430_pm_ops = {
#define DEV_PM_OPS NULL
#endif
+#ifdef CONFIG_OF
+static const struct of_device_id omap2430_id_table[] = {
+ {
+ .compatible =
[PATCHv7 00/12] ARM: OMAP4: core retention support
Hi, Changes compared to previous version: - ported on top of 3.5-rc7 - patch 3: added a few modules here not having context_offs - patch 8: NEW: * ROM code on EMU / HS devices seem to wipe the contents of L4PER_PWRSTCTRL register, thus this patch adds an errata + save and restore for this register, this was noticed while testing cpu_idle on EMU device - patch 9: NEW: * sl2if hwmod is still blocking core retention on omap4, this patch comments it out similarly to aess / usb_host_fs - patch 10: NEW: * adds support for lostcontext_mask, this is needed by l4_abe / aess hwmods as they will share context register, but use different bits within it - patch 11: NEW: * adds the hwmod data for sharing context register for l4_abe / aess - patch 12: NEW: * context lost counter logic update for modules that don't have context register Some of the NEW patches (10..12) are result of comments received on l-o list, and can be merged with other patches in the set if they are seen acceptable. Core retention works without these patches fine, but they address some corner cases. Tested with omap4460 GP panda + omap4430 EMU blaze, with both suspend + cpu_idle. cpu_idle + uart autosuspend seems to have an issue with omap4 currently that it loses some of the characters at the end of a print, should be fixed on uart driver level. Made a quick hack myself for this by modifying the serial_omap_tx_empty() to not use pm_runtime_put but pm_runtime_put_autosuspend at end, but this might not be the right way to fix this. Working test tree available also: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git branch: mainline-3.5-rc7-omap4-ret-v7 Branch contains also func pwrst code from Jean + io_chain set + one timekeeping patch from mainline tip to make suspend work properly. -Tero -- 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
[PATCHv7 01/12] ARM: OMAP4: PM: add errata support
Added similar PM errata flag support as omap3 has. This should be used
in similar manner, set the flags during init time, and check the flag
values during runtime.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm.h |7 +++
arch/arm/mach-omap2/pm44xx.c |1 +
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 7856489..46ab9d9 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -88,6 +88,13 @@ extern void enable_omap3630_toggle_l2_on_restore(void);
static inline void enable_omap3630_toggle_l2_on_restore(void) { }
#endif /* defined(CONFIG_PM) defined(CONFIG_ARCH_OMAP3) */
+#if defined(CONFIG_ARCH_OMAP4)
+extern u16 pm44xx_errata;
+#define IS_PM44XX_ERRATUM(id) (pm44xx_errata (id))
+#else
+#define IS_PM44XX_ERRATUM(id) 0
+#endif
+
#ifdef CONFIG_OMAP_SMARTREFLEX
extern int omap_devinit_smartreflex(void);
extern void omap_enable_smartreflex_on_init(void);
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index c234733..3a484b1 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -33,6 +33,7 @@ struct power_state {
};
static LIST_HEAD(pwrst_list);
+u16 pm44xx_errata;
#ifdef CONFIG_SUSPEND
static int omap4_pm_suspend(void)
--
1.7.4.1
--
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
[PATCHv7 02/12] ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX GIC control register change.
From: Santosh Shilimkar santosh.shilim...@ti.com
On OMAP4+ devices, GIC register context is lost when MPUSS hits
the OSWR(Open Switch Retention). On the CPU wakeup path, ROM code
gets executed and one of the steps in it is to restore the
saved context of the GIC. The ROM Code GIC distributor restoration
is split in two parts: CPU specific register done by each CPU and
common register done by only one CPU.
Below is the abstract flow.
...
- MPUSS in OSWR state.
- CPU0 wakes up on the event(interrupt) and start executing ROM code.
[..]
- CPU0 executes GIC Restoration:
[...]
- CPU0 swicthes to non-secure mode and jumps to OS resume code.
[...]
- CPU0 is online in OS
- CPU0 enables the GIC distributor. GICD.Enable Non-secure = 1
- CPU0 wakes up CPU1 with clock-domain force wakeup method.
- CPU0 continues it's execution.
[..]
- CPU1 wakes up and start executing ROM code.
[..]
- CPU1 executes GIC Restoration:
[..]
- CPU1 swicthes to non-secure mode and jumps to OS resume code.
[...]
- CPU1 is online in OS and start executing.
[...] -
GIC Restoration: /* Common routine for HS and GP devices */
{
if (GICD != 1) { /* This will be true in OSWR state */
if (GIC_SAR_BACKUP_STATE == SAVED)
- CPU restores GIC distributor
else
- reconfigure GIC distributor to boot values.
GICD.Enable secure = 1
}
if (GIC_SAR_BACKUP_STATE == SAVED)
- CPU restore its GIC CPU interface registers if saved.
else
- reconfigure its GIC CPU interface registers to boot
values.
}
...
So as mentioned in the flow, GICD != 1 condition decides how
the GIC registers are handled in ROM code wakeup path from
OSWR. As evident from the flow, ROM code relies on the entire
GICD register value and not specific register bits.
The assumption was valid till CortexA9 r1pX version since there
was only one banked bit to control secure and non-secure GICD.
Secure view which ROM code sees:
bit 0 == Enable Non-secure
Non-secure view which HLOS sees:
bit 0 == Enable secure
But GICD register has changed between CortexA9 r1pX and r2pX.
On r2pX GICD register is composed of 2 bits.
Secure view which ROM code sees:
bit 1 == Enable Non-secure
bit 0 == Enable secure
Non-secure view which HLOS sees:
bit 0 == Enable Non-secure
Hence on OMAP4460(r2pX) devices, if you go through the
above flow again during CPU1 wakeup, GICD == 3 and hence
ROM code fails to understand the real wakeup power state
and reconfigures GIC distributor to boot values. This is
nasty since you loose the entire interrupt controller
context in a live system.
The ROM code fix done on next OMAP4 device (OMAP4470 - r2px) is to
check GICD.Enable secure != 1 for GIC restoration in OSWR wakeup path.
Since ROM code can't be fixed on OMAP4460 devices, a work around
needs to be implemented. As evident from the flow, as long as
CPU1 sees GICD == 1 in it's wakeup path from OSWR, the issue
won't happen. Below is the flow with the work-around.
...
- MPUSS in OSWR state.
- CPU0 wakes up on the event(interrupt) and start executing ROM code.
[..]
- CPU0 executes GIC Restoration:
[..]
- CPU0 swicthes to non-secure mode and jumps to OS resume code.
[..]
- CPU0 is online in OS.
- CPU0 does GICD.Enable Non-secure = 0
- CPU0 wakes up CPU1 with clock domain force wakeup method.
- CPU0 waits for GICD.Enable Non-secure = 1
- CPU0 coninues it's execution.
[..]
- CPU1 wakes up and start executing ROM code.
[..]
- CPU1 executes GIC Restoration:
[..]
- CPU1 swicthes to non-secure mode and jumps to OS resume code.
[..]
- CPU1 is online in OS
- CPU1 does GICD.Enable Non-secure = 1
- CPU1 start executing
[...]
...
With this procedure, the GIC configuration done between the
CPU0 wakeup and CPU1 wakeup will not be lost but during this
short windows, the CPU0 will not receive interrupts.
The BUG is applicable to only OMAP4460(r2pX) devices.
OMAP4470 (also r2pX) is not affected by this bug because
ROM code has been fixed.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/common.h |2 +
arch/arm/mach-omap2/omap-headsmp.S| 38 +
arch/arm/mach-omap2/omap-mpuss-lowpower.c |9 ++-
arch/arm/mach-omap2/omap-smp.c| 28 -
arch/arm/mach-omap2/omap4-common.c|8 +-
arch/arm/mach-omap2/pm.h |2 +
6 files changed, 84 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index be9dfd1..a793ab3 100644
---
[PATCHv7 03/12] ARM: OMAP4: hwmod: flag hwmods/modules not supporting module level context status
On OMAP4 most modules/hwmods support module level context status. On
OMAP3 and earlier, we relied on the power domain level context status.
Identify all modules that don't support 'context_offs' by marking the
offset as USHRT_MAX. Rest have a valid 'context_offs' populated in
.prcm structure already.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 46
1 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index b7bcba5..ad7df4e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -204,6 +204,7 @@ static struct omap_hwmod omap44xx_l4_abe_hwmod = {
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM1_ABE_L4ABE_CLKCTRL_OFFSET,
+ .context_offs = USHRT_MAX,
},
},
};
@@ -260,6 +261,11 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
.name = mpu_private,
.class = omap44xx_mpu_bus_hwmod_class,
.clkdm_name = mpuss_clkdm,
+ .prcm = {
+ .omap4 = {
+ .context_offs = USHRT_MAX,
+ },
+ },
};
/*
@@ -448,6 +454,11 @@ static struct omap_hwmod omap44xx_ctrl_module_core_hwmod =
{
.class = omap44xx_ctrl_module_hwmod_class,
.clkdm_name = l4_cfg_clkdm,
.mpu_irqs = omap44xx_ctrl_module_core_irqs,
+ .prcm = {
+ .omap4 = {
+ .context_offs = USHRT_MAX,
+ },
+ },
};
/* ctrl_module_pad_core */
@@ -455,6 +466,11 @@ static struct omap_hwmod
omap44xx_ctrl_module_pad_core_hwmod = {
.name = ctrl_module_pad_core,
.class = omap44xx_ctrl_module_hwmod_class,
.clkdm_name = l4_cfg_clkdm,
+ .prcm = {
+ .omap4 = {
+ .context_offs = USHRT_MAX,
+ },
+ },
};
/* ctrl_module_wkup */
@@ -462,6 +478,11 @@ static struct omap_hwmod omap44xx_ctrl_module_wkup_hwmod =
{
.name = ctrl_module_wkup,
.class = omap44xx_ctrl_module_hwmod_class,
.clkdm_name = l4_wkup_clkdm,
+ .prcm = {
+ .omap4 = {
+ .context_offs = USHRT_MAX,
+ },
+ },
};
/* ctrl_module_pad_wkup */
@@ -469,6 +490,11 @@ static struct omap_hwmod
omap44xx_ctrl_module_pad_wkup_hwmod = {
.name = ctrl_module_pad_wkup,
.class = omap44xx_ctrl_module_hwmod_class,
.clkdm_name = l4_wkup_clkdm,
+ .prcm = {
+ .omap4 = {
+ .context_offs = USHRT_MAX,
+ },
+ },
};
/*
@@ -2538,6 +2564,11 @@ static struct omap_hwmod omap44xx_prcm_mpu_hwmod = {
.name = prcm_mpu,
.class = omap44xx_prcm_hwmod_class,
.clkdm_name = l4_wkup_clkdm,
+ .prcm = {
+ .omap4 = {
+ .context_offs = USHRT_MAX,
+ },
+ },
};
/* cm_core_aon */
@@ -2545,6 +2576,11 @@ static struct omap_hwmod omap44xx_cm_core_aon_hwmod = {
.name = cm_core_aon,
.class = omap44xx_prcm_hwmod_class,
.clkdm_name = cm_clkdm,
+ .prcm = {
+ .omap4 = {
+ .context_offs = USHRT_MAX,
+ },
+ },
};
/* cm_core */
@@ -2552,6 +2588,11 @@ static struct omap_hwmod omap44xx_cm_core_hwmod = {
.name = cm_core,
.class = omap44xx_prcm_hwmod_class,
.clkdm_name = cm_clkdm,
+ .prcm = {
+ .omap4 = {
+ .context_offs = USHRT_MAX,
+ },
+ },
};
/* prm */
@@ -2588,6 +2629,11 @@ static struct omap_hwmod omap44xx_scrm_hwmod = {
.name = scrm,
.class = omap44xx_scrm_hwmod_class,
.clkdm_name = l4_wkup_clkdm,
+ .prcm = {
+ .omap4 = {
+ .context_offs = USHRT_MAX,
+ },
+ },
};
/*
--
1.7.4.1
--
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
[PATCHv7 04/12] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count
From: Rajendra Nayak rna...@ti.com
OMAP4 has module specific context lost registers which makes it now
possible to have module level context loss count, instead of relying
on the powerdomain level context count.
Add 2 private hwmod api's to update/clear the hwmod/module specific
context lost counters/register.
Update the module specific context_lost_counter and clear the hardware
bits just after enabling the module.
omap_hwmod_get_context_loss_count() now returns the hwmod context loss
count them on platforms where they exist (OMAP4), else fall back on
the pwrdm level counters for older platforms.
Signed-off-by: Rajendra Nayak rna...@ti.com
[p...@pwsan.com: added function kerneldoc, fixed structure kerneldoc,
rearranged structure to avoid memory waste, marked fns as OMAP4-specific,
prevent fn entry on non-OMAP4 chips, reduced indentation, merged update
and clear, merged patches]
Signed-off-by: Paul Walmsley p...@pwsan.com
[t-kri...@ti.com: added support for arch specific hwmod ops, and changed
the no context offset indicator to USHRT_MAX]
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 71 --
arch/arm/plat-omap/include/plat/omap_hwmod.h |8 ++-
2 files changed, 73 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 936da32..a60dfd2 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -170,6 +170,13 @@
/* omap_hwmod_list contains all registered struct omap_hwmods */
static LIST_HEAD(omap_hwmod_list);
+struct hwmod_ops {
+ void(*hwmod_update_context_lost)(struct omap_hwmod *oh);
+ int (*hwmod_get_context_lost)(struct omap_hwmod *oh);
+};
+
+static struct hwmod_ops *arch_hwmod;
+
/* mpu_oh: used to add/remove MPU initiator from sleepdep list */
static struct omap_hwmod *mpu_oh;
@@ -1784,6 +1791,52 @@ static void _reconfigure_io_chain(void)
}
/**
+ * _omap4_update_context_lost - increment hwmod context loss counter if
+ * hwmod context was lost, and clear hardware context loss reg
+ * @oh: hwmod to check for context loss
+ *
+ * If the PRCM indicates that the hwmod @oh lost context, increment
+ * our in-memory context loss counter, and clear the RM_*_CONTEXT
+ * bits. No return value.
+ */
+static void _omap4_update_context_lost(struct omap_hwmod *oh)
+{
+ u32 r;
+
+ if (oh-prcm.omap4.context_offs == USHRT_MAX)
+ return;
+
+ r = omap4_prminst_read_inst_reg(oh-clkdm-pwrdm.ptr-prcm_partition,
+ oh-clkdm-pwrdm.ptr-prcm_offs,
+ oh-prcm.omap4.context_offs);
+
+ if (!r)
+ return;
+
+ oh-prcm.omap4.context_lost_counter++;
+
+ omap4_prminst_write_inst_reg(r, oh-clkdm-pwrdm.ptr-prcm_partition,
+oh-clkdm-pwrdm.ptr-prcm_offs,
+oh-prcm.omap4.context_offs);
+}
+
+/**
+ * _omap4_get_context_lost - get context loss counter for a hwmod
+ * @oh: hwmod to get context loss counter for
+ *
+ * Returns the in-memory context loss counter for a hwmod.
+ */
+static int _omap4_get_context_lost(struct omap_hwmod *oh)
+{
+ return oh-prcm.omap4.context_lost_counter;
+}
+
+static struct hwmod_ops omap4_hwmod_ops = {
+ .hwmod_update_context_lost = _omap4_update_context_lost,
+ .hwmod_get_context_lost = _omap4_get_context_lost,
+};
+
+/**
* _enable - enable an omap_hwmod
* @oh: struct omap_hwmod *
*
@@ -1864,6 +1917,9 @@ static int _enable(struct omap_hwmod *oh)
_enable_clocks(oh);
_enable_module(oh);
+ if (arch_hwmod arch_hwmod-hwmod_update_context_lost)
+ arch_hwmod-hwmod_update_context_lost(oh);
+
r = _wait_target_ready(oh);
if (!r) {
/*
@@ -2700,6 +2756,9 @@ int __init omap_hwmod_setup_one(const char *oh_name)
*/
static int __init omap_hwmod_setup_all(void)
{
+ if (cpu_is_omap44xx())
+ arch_hwmod = omap4_hwmod_ops;
+
_ensure_mpu_hwmod_is_setup(NULL);
omap_hwmod_for_each(_init, NULL);
@@ -3353,17 +3412,21 @@ ohsps_unlock:
* omap_hwmod_get_context_loss_count - get lost context count
* @oh: struct omap_hwmod *
*
- * Query the powerdomain of of @oh to get the context loss
- * count for this device.
+ * Returns the context loss count of associated @oh
+ * upon success, or zero if no context loss data is available.
*
- * Returns the context loss count of the powerdomain assocated with @oh
- * upon success, or zero if no powerdomain exists for @oh.
+ * On OMAP4, this queries the per-hwmod context loss register,
+ * assuming one exists. If not, or on OMAP2/3, this queries the
+ * enclosing powerdomain context loss count.
*/
int omap_hwmod_get_context_loss_count(struct omap_hwmod *oh)
{
struct powerdomain *pwrdm;
int ret = 0;
+ if
[PATCHv7 06/12] ARM: OMAP4: suspend: Program all domains to retention
From: Rajendra Nayak rna...@ti.com Remove the FIXME's in the suspend sequence since we now intend to support system level RET support. Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Tero Kristo t-kri...@ti.com [Jean Pihet j-pi...@ti.com: ported on top of the functional power states] Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/pm44xx.c | 10 +++--- 1 files changed, 3 insertions(+), 7 deletions(-) diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c index 3a484b1..1e845e8 100644 --- a/arch/arm/mach-omap2/pm44xx.c +++ b/arch/arm/mach-omap2/pm44xx.c @@ -97,19 +97,15 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused) if (!strncmp(pwrdm-name, cpu, 3)) return 0; - /* -* FIXME: Remove this check when core retention is supported -* Only MPUSS power domain is added in the list. -*/ - if (strcmp(pwrdm-name, mpu_pwrdm)) - return 0; pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC); if (!pwrst) return -ENOMEM; pwrst-pwrdm = pwrdm; - pwrst-next_state = PWRDM_FUNC_PWRST_CSWR; + pwrst-next_state = pwrdm_get_achievable_func_pwrst( + pwrdm, + PWRDM_FUNC_PWRST_CSWR); list_add(pwrst-node, pwrst_list); return omap_set_pwrdm_state(pwrst-pwrdm, pwrst-next_state); -- 1.7.4.1 -- 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
[PATCHv7 07/12] ARM: OMAP4: PM: put all domains to OSWR during suspend
Signed-off-by: Tero Kristo t-kri...@ti.com --- arch/arm/mach-omap2/pm44xx.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c index 1e845e8..eb3e073 100644 --- a/arch/arm/mach-omap2/pm44xx.c +++ b/arch/arm/mach-omap2/pm44xx.c @@ -105,7 +105,7 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused) pwrst-pwrdm = pwrdm; pwrst-next_state = pwrdm_get_achievable_func_pwrst( pwrdm, - PWRDM_FUNC_PWRST_CSWR); + PWRDM_FUNC_PWRST_OSWR); list_add(pwrst-node, pwrst_list); return omap_set_pwrdm_state(pwrst-pwrdm, pwrst-next_state); -- 1.7.4.1 -- 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
[PATCHv7 05/12] ARM: OMAP4: pwrdm: add support for reading prev logic and mem states
On OMAP4, there is no support to read previous logic state
or previous memory state achieved when a power domain transitions
to RET. Instead there are module level context registers.
In order to support the powerdomain level logic/mem_off_counters
on OMAP4, instead use the previous power state achieved (RET) and
the *programmed* logic/mem RET state to derive if a powerdomain lost
logic or did not.
If the powerdomain is programmed to enter RET state and lose logic
in RET state, knowing that the powerdomain entered RET is good enough
to derive that the logic was lost as well, in such cases.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/powerdomain44xx.c | 59 +
1 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain44xx.c
b/arch/arm/mach-omap2/powerdomain44xx.c
index 030d10c..ab93f08 100644
--- a/arch/arm/mach-omap2/powerdomain44xx.c
+++ b/arch/arm/mach-omap2/powerdomain44xx.c
@@ -151,6 +151,34 @@ static int omap4_pwrdm_read_logic_retst(struct powerdomain
*pwrdm)
return v;
}
+/**
+ * omap4_pwrdm_read_prev_logic_pwrst - read the previous logic powerstate
+ * @pwrdm: struct powerdomain * to read the state for
+ *
+ * Reads the previous logic powerstate for a powerdomain. This function
+ * must determine the previous logic powerstate by first checking the
+ * previous powerstate for the domain. If that was OFF, then logic has
+ * been lost. If previous state was RETENTION, the function reads the
+ * setting for the next retention logic state to see the actual value.
+ * In every other case, the logic is retained. Returns either
+ * PWRDM_LOGIC_MEM_PWRST_OFF or PWRDM_LOGIC_MEM_PWRST_RET depending
+ * whether the logic was retained or not.
+ */
+static int omap4_pwrdm_read_prev_logic_pwrst(struct powerdomain *pwrdm)
+{
+ int state;
+
+ state = omap4_pwrdm_read_prev_pwrst(pwrdm);
+
+ if (state == PWRDM_POWER_OFF)
+ return PWRDM_LOGIC_MEM_PWRST_OFF;
+
+ if (state != PWRDM_POWER_RET)
+ return PWRDM_LOGIC_MEM_PWRST_RET;
+
+ return omap4_pwrdm_read_logic_retst(pwrdm);
+}
+
static int omap4_pwrdm_read_mem_pwrst(struct powerdomain *pwrdm, u8 bank)
{
u32 m, v;
@@ -179,6 +207,35 @@ static int omap4_pwrdm_read_mem_retst(struct powerdomain
*pwrdm, u8 bank)
return v;
}
+/**
+ * omap4_pwrdm_read_prev_mem_pwrst - reads the previous memory powerstate
+ * @pwrdm: struct powerdomain * to read mem powerstate for
+ * @bank: memory bank index
+ *
+ * Reads the previous memory powerstate for a powerdomain. This function
+ * must determine the previous memory powerstate by first checking the
+ * previous powerstate for the domain. If that was OFF, then logic has
+ * been lost. If previous state was RETENTION, the function reads the
+ * setting for the next memory retention state to see the actual value.
+ * In every other case, the logic is retained. Returns either
+ * PWRDM_LOGIC_MEM_PWRST_OFF or PWRDM_LOGIC_MEM_PWRST_RET depending
+ * whether logic was retained or not.
+ */
+static int omap4_pwrdm_read_prev_mem_pwrst(struct powerdomain *pwrdm, u8 bank)
+{
+ int state;
+
+ state = omap4_pwrdm_read_prev_pwrst(pwrdm);
+
+ if (state == PWRDM_POWER_OFF)
+ return PWRDM_LOGIC_MEM_PWRST_OFF;
+
+ if (state != PWRDM_POWER_RET)
+ return PWRDM_LOGIC_MEM_PWRST_RET;
+
+ return omap4_pwrdm_read_mem_retst(pwrdm, bank);
+}
+
static int omap4_pwrdm_wait_transition(struct powerdomain *pwrdm)
{
u32 c = 0;
@@ -220,9 +277,11 @@ struct pwrdm_ops omap4_pwrdm_operations = {
.pwrdm_clear_all_prev_pwrst = omap4_pwrdm_clear_all_prev_pwrst,
.pwrdm_set_logic_retst = omap4_pwrdm_set_logic_retst,
.pwrdm_read_logic_pwrst = omap4_pwrdm_read_logic_pwrst,
+ .pwrdm_read_prev_logic_pwrst= omap4_pwrdm_read_prev_logic_pwrst,
.pwrdm_read_logic_retst = omap4_pwrdm_read_logic_retst,
.pwrdm_read_mem_pwrst = omap4_pwrdm_read_mem_pwrst,
.pwrdm_read_mem_retst = omap4_pwrdm_read_mem_retst,
+ .pwrdm_read_prev_mem_pwrst = omap4_pwrdm_read_prev_mem_pwrst,
.pwrdm_set_mem_onst = omap4_pwrdm_set_mem_onst,
.pwrdm_set_mem_retst= omap4_pwrdm_set_mem_retst,
.pwrdm_wait_transition = omap4_pwrdm_wait_transition,
--
1.7.4.1
--
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
[PATCHv7 11/12] ARM: OMAP4: hwmod_data: add context lose information for l4_abe hwmod
'l4_abe' hwmod uses the LOSTMEM_AESSMEM bit of RM_ABE_AESS_CONTEXT register,
as l4_abe doesn't have its own dedicated register for this purpose. This
register is shared with 'aess' hwmod, thus both hwmods must also specify
which bits of the register are used for them.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 8b60377..48431cb 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -204,7 +204,8 @@ static struct omap_hwmod omap44xx_l4_abe_hwmod = {
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM1_ABE_L4ABE_CLKCTRL_OFFSET,
- .context_offs = USHRT_MAX,
+ .context_offs = OMAP4_RM_ABE_AESS_CONTEXT_OFFSET,
+ .lostcontext_mask = OMAP4430_LOSTMEM_AESSMEM_MASK,
},
},
};
@@ -350,6 +351,7 @@ static struct omap_hwmod omap44xx_aess_hwmod = {
.omap4 = {
.clkctrl_offs = OMAP4_CM1_ABE_AESS_CLKCTRL_OFFSET,
.context_offs = OMAP4_RM_ABE_AESS_CONTEXT_OFFSET,
+ .lostcontext_mask = OMAP4430_LOSTCONTEXT_DFF_MASK,
.modulemode = MODULEMODE_SWCTRL,
},
},
--
1.7.4.1
--
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
[PATCHv7 10/12] ARM: OMAP4: HWMOD: add support for lostcontext_mask
Currently hwmod only provides the offset for the context lose register,
and if we attempt to share the same register between two or more hwmods,
the resulting context loss counts get wrong. Thus, we need a way to
specify which bits are used for the context loss information for each.
This is accomplished by adding a new field to the omap4 prcm struct,
'lostcontext_mask', which specifies a bit-mask to use for filtering
the register. Only the specified bits are read and cleared by the
context lose counter update code. If a hwmod doesn't specify
'lostcontext_mask' (default behavior), the whole contents of the
context register are used without any filtering.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c |8
arch/arm/plat-omap/include/plat/omap_hwmod.h |6 ++
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index a60dfd2..3ebf93e 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1810,11 +1810,19 @@ static void _omap4_update_context_lost(struct
omap_hwmod *oh)
oh-clkdm-pwrdm.ptr-prcm_offs,
oh-prcm.omap4.context_offs);
+ /*
+* If lostcontext_mask is defined, only check these bits for
+* losing context. Otherwise check whole register.
+*/
+ if (oh-prcm.omap4.lostcontext_mask)
+ r = oh-prcm.omap4.lostcontext_mask;
+
if (!r)
return;
oh-prcm.omap4.context_lost_counter++;
+ /* Clear selected bits */
omap4_prminst_write_inst_reg(r, oh-clkdm-pwrdm.ptr-prcm_partition,
oh-clkdm-pwrdm.ptr-prcm_offs,
oh-prcm.omap4.context_offs);
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 75d59f5..ebe3048 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -375,14 +375,20 @@ struct omap_hwmod_omap2_prcm {
* @clkctrl_offs: offset of the PRCM clock control register
* @rstctrl_offs: offset of the XXX_RSTCTRL register located in the PRM
* @context_offs: offset of the RM_*_CONTEXT register
+ * @lostcontext_mask: bitmask for selecting bits from RM_*_CONTEXT register
* @submodule_wkdep_bit: bit shift of the WKDEP range
* @modulemode: allowable modulemodes
* @context_lost_counter: Count of module level context lost
+ *
+ * If @lostcontext_mask is not defined, context loss check code uses
+ * whole register without masking. @lostcontext_mask should only be defined
+ * in cases where @context_offs register is shared by two or more hwmods.
*/
struct omap_hwmod_omap4_prcm {
u16 clkctrl_offs;
u16 rstctrl_offs;
u16 context_offs;
+ u32 lostcontext_mask;
u8 submodule_wkdep_bit;
u8 modulemode;
unsignedcontext_lost_counter;
--
1.7.4.1
--
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
[PATCHv7 08/12] ARM: OMAP4430: PM: Work-around for ROM code BUG of PER pwrst ctrl
On OMAP4430 HS / EMU chips, ROM code appears to re-configure L4PER domain
next powerstate during wakeup from OSWR / OFF, programming it to ON.
This will prevent successive entries to cpuidle retention / off, until
kernel decices to change the L4PER target state, which can be delayed
for a very long time as kernel is lazy programming the target state.
This patch fixes the issue within the low power OSWR / OFF mode code, so
that this register is saved / restored across MPU OSWR / OFF state.
This problem seems to only occur with OMAP4430 HS/EMU, it does not impact
OMAP4460+ or GP devices.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 39 -
arch/arm/mach-omap2/pm.h |1 +
arch/arm/mach-omap2/pm44xx.c | 10 +++
3 files changed, 49 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 0e5f81b..963a61b 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -52,6 +52,7 @@
#include plat/omap44xx.h
+#include iomap.h
#include common.h
#include omap4-sar-layout.h
#include pm.h
@@ -97,6 +98,15 @@ static inline void set_cpu_next_pwrst(unsigned int cpu_id,
omap_set_pwrdm_state(pm_info-pwrdm, power_state);
}
+struct reg_tuple {
+ void __iomem *addr;
+ u32 val;
+};
+
+static struct reg_tuple l4per_reg[] = {
+ {.addr = OMAP4430_PM_L4PER_PWRSTCTRL},
+};
+
/*
* Read CPU's previous power state
*/
@@ -215,6 +225,28 @@ static void save_l2x0_context(void)
{}
#endif
+static inline void save_l4per_regs(void)
+{
+ int i;
+
+ if (!IS_PM44XX_ERRATUM(PM_OMAP4_ROM_L4PER_ERRATUM_PWSTCT))
+ return;
+
+ for (i = 0; i ARRAY_SIZE(l4per_reg); i++)
+ l4per_reg[i].val = __raw_readl(l4per_reg[i].addr);
+}
+
+static inline void restore_l4per_regs(void)
+{
+ int i;
+
+ if (!IS_PM44XX_ERRATUM(PM_OMAP4_ROM_L4PER_ERRATUM_PWSTCT))
+ return;
+
+ for (i = 0; i ARRAY_SIZE(l4per_reg); i++)
+ __raw_writel(l4per_reg[i].val, l4per_reg[i].addr);
+}
+
/**
* omap4_enter_lowpower: OMAP4 MPUSS Low Power Entry Function
* The purpose of this function is to manage low power programming
@@ -265,8 +297,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
* In MPUSS OSWR or device OFF, interrupt controller context is lost.
*/
mpuss_clear_prev_logic_pwrst();
- if (pwrdm_read_next_func_pwrst(mpuss_pd) == PWRDM_FUNC_PWRST_OSWR)
+ if (pwrdm_read_next_func_pwrst(mpuss_pd) == PWRDM_FUNC_PWRST_OSWR) {
+ save_l4per_regs();
save_state = 2;
+ }
cpu_clear_prev_logic_pwrst(cpu);
set_cpu_next_pwrst(cpu, power_state);
@@ -289,6 +323,9 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
wakeup_cpu = smp_processor_id();
set_cpu_next_pwrst(wakeup_cpu, PWRDM_FUNC_PWRST_ON);
+ if (omap4_mpuss_read_prev_context_state())
+ restore_l4per_regs();
+
pwrdm_post_transition();
return 0;
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index d95d1d0..adce520 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -89,6 +89,7 @@ static inline void enable_omap3630_toggle_l2_on_restore(void)
{ }
#endif /* defined(CONFIG_PM) defined(CONFIG_ARCH_OMAP3) */
#define PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD (1 0)
+#define PM_OMAP4_ROM_L4PER_ERRATUM_PWSTCT (1 1)
#if defined(CONFIG_ARCH_OMAP4)
extern u16 pm44xx_errata;
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index eb3e073..1e98909 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -194,6 +194,16 @@ int __init omap4_pm_init(void)
(void) clkdm_for_each(omap_pm_clkdms_setup, NULL);
+ /*
+* ROM core appears to modify the L4PER powerstate control register
+* during wakeup from OSWR / OFF, which will prevent further low
+* power state transitions until the register is re-programmed.
+* Thus, we must save / restore the register during idle. This
+* seems to happen only on omap4430, on HS / EMU chips only.
+*/
+ if (cpu_is_omap443x() omap_type() != OMAP2_DEVICE_TYPE_GP)
+ pm44xx_errata |= PM_OMAP4_ROM_L4PER_ERRATUM_PWSTCT;
+
#ifdef CONFIG_SUSPEND
omap_pm_suspend = omap4_pm_suspend;
#endif
--
1.7.4.1
--
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
[PATCHv7 12/12] ARM: OMAP4: hwmod: update context lost counter logic for hwmods without context reg
With this patch, the hwmods that don't have context register, will now
increment their context lost counter always unless they belong to an
always on powerdomain which never loses context. The always on pwrdm
type is checked by looking at the the powerdomain registered for the
hwmod, and seeing if it only has ON within its valid powerstates.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 21 -
1 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 3ebf93e..daf5322 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1802,9 +1802,28 @@ static void _reconfigure_io_chain(void)
static void _omap4_update_context_lost(struct omap_hwmod *oh)
{
u32 r;
+ struct powerdomain *pwrdm;
+
+ /* Special handling if we have not defined context register */
+ if (oh-prcm.omap4.context_offs == USHRT_MAX) {
+ /* Get powerdomain pointer for this hwmod */
+ if (oh-clkdm)
+ pwrdm = oh-clkdm-pwrdm.ptr;
+ else
+ pwrdm = NULL;
- if (oh-prcm.omap4.context_offs == USHRT_MAX)
+ /*
+* If our powerdomain is of 'always on' type (i.e.
+* available powerstates == PWRSTS_ON), don't increment
+* context lost and return
+*/
+ if (pwrdm pwrdm-pwrsts == PWRSTS_ON)
+ return;
+
+ /* Otherwise, increase context lost counter and return */
+ oh-prcm.omap4.context_lost_counter++;
return;
+ }
r = omap4_prminst_read_inst_reg(oh-clkdm-pwrdm.ptr-prcm_partition,
oh-clkdm-pwrdm.ptr-prcm_offs,
--
1.7.4.1
--
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
[PATCHv7 09/12] ARM: OMAP4: hwmod data: temporarily comment out data for the sl2if IP block
The OMAP4 sl2if IP block requires some special programming for it to
enter idle. Without this programming, they will prevent the rest of
the chip from entering full chip idle.
This patch comments out the IP block data.
Later, once the appropriate support is available, this patch can be
reverted.
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index ad7df4e..8b60377 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -4266,7 +4266,7 @@ static struct omap_hwmod_ocp_if omap44xx_dsp__iva = {
};
/* dsp - sl2if */
-static struct omap_hwmod_ocp_if omap44xx_dsp__sl2if = {
+static struct omap_hwmod_ocp_if __maybe_unused omap44xx_dsp__sl2if = {
.master = omap44xx_dsp_hwmod,
.slave = omap44xx_sl2if_hwmod,
.clk= dpll_iva_m5x2_ck,
@@ -4884,7 +4884,7 @@ static struct omap_hwmod_ocp_if omap44xx_l3_main_2__iss =
{
};
/* iva - sl2if */
-static struct omap_hwmod_ocp_if omap44xx_iva__sl2if = {
+static struct omap_hwmod_ocp_if __maybe_unused omap44xx_iva__sl2if = {
.master = omap44xx_iva_hwmod,
.slave = omap44xx_sl2if_hwmod,
.clk= dpll_iva_m5x2_ck,
@@ -5418,7 +5418,7 @@ static struct omap_hwmod_ocp_if omap44xx_l4_wkup__scrm = {
};
/* l3_main_2 - sl2if */
-static struct omap_hwmod_ocp_if omap44xx_l3_main_2__sl2if = {
+static struct omap_hwmod_ocp_if __maybe_unused omap44xx_l3_main_2__sl2if = {
.master = omap44xx_l3_main_2_hwmod,
.slave = omap44xx_sl2if_hwmod,
.clk= l3_div_ck,
@@ -6088,7 +6088,7 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[]
__initdata = {
omap44xx_l4_abe__dmic,
omap44xx_l4_abe__dmic_dma,
omap44xx_dsp__iva,
- omap44xx_dsp__sl2if,
+ /* omap44xx_dsp__sl2if, */
omap44xx_l4_cfg__dsp,
omap44xx_l3_main_2__dss,
omap44xx_l4_per__dss,
@@ -6124,7 +6124,7 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[]
__initdata = {
omap44xx_l4_per__i2c4,
omap44xx_l3_main_2__ipu,
omap44xx_l3_main_2__iss,
- omap44xx_iva__sl2if,
+ /* omap44xx_iva__sl2if, */
omap44xx_l3_main_2__iva,
omap44xx_l4_wkup__kbd,
omap44xx_l4_cfg__mailbox,
@@ -6155,7 +6155,7 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[]
__initdata = {
omap44xx_l4_cfg__cm_core,
omap44xx_l4_wkup__prm,
omap44xx_l4_wkup__scrm,
- omap44xx_l3_main_2__sl2if,
+ /* omap44xx_l3_main_2__sl2if, */
omap44xx_l4_abe__slimbus1,
omap44xx_l4_abe__slimbus1_dma,
omap44xx_l4_per__slimbus2,
--
1.7.4.1
--
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: am3517: geting MMC working
Am 19.07.2012 10:57, schrieb S, Venkatraman: On Thu, Jul 19, 2012 at 1:45 PM, Yegor Yefremov yegor_s...@visionsystems.de wrote: Am 19.07.2012 09:43, schrieb S, Venkatraman: On Thu, Jul 19, 2012 at 12:58 PM, Yegor Yefremov yegor_s...@visionsystems.de wrote: Am 19.07.2012 09:07, schrieb Shilimkar, Santosh: On Thu, Jul 19, 2012 at 12:25 PM, Yegor Yefremov yegor_s...@visionsystems.de wrote: Am 19.07.2012 08:34, schrieb Shilimkar, Santosh: On Thu, Jul 19, 2012 at 11:54 AM, Yegor Yefremov yegor_s...@visionsystems.de wrote: What patches do I need to get MMC working with linux-omap master? omap_hsmmc omap_hsmmc.0: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 62 omap-dma-engine omap-dma-engine: allocating channel for 61 omap_hsmmc omap_hsmmc.1: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 48 omap-dma-engine omap-dma-engine: allocating channel for 47 I searched for this issue and saw some patches for common clock framework that were scheduled for 3.6, but I'm not sure it's enough or weather they are already incorporated in linux-omap. I guess you need [1] to get around the issue. [1] http://www.spinics.net/lists/linux-omap/msg73965.html though I haven't applied this patch I have DMA activated (CONFIG_DMADEVICES and CONFIG_DMA_OMAP). Found in some other thread [1]. As far as I can tell, debounce clk is the problem. Sorry. I miss-read the message. The whole log for reference: Booting Linux on physical CPU 0 Linux version 3.5.0-rc6-12227-g60701f4-dirty () (gcc version 4.5.3 (Buildroot 2012.05-rc2-9-gfbd5a1d-dirty) ) #90 Thu Jul 19 09:23:31 CEST 2012 CPU: ARMv7 Processor [411fc087] revision 7 (ARMv7), cr=10c53c7d CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP3517/AM3517 EVM Ignoring tag cmdline (using the default kernel command line) bootconsole [earlycon0] enabled Memory policy: ECC disabled, Data cache writeback AM3517 ES1.1 (l2cache sgx neon ) Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 Kernel command line: root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 earlyprintk=serial,ttyO2,115200 PID hash table entries: 1024 (order: 0, 4096 bytes) Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 255MB = 255MB total Memory: 247380k/247380k available, 14764k reserved, 0K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) vmalloc : 0xd080 - 0xff00 ( 744 MB) lowmem : 0xc000 - 0xd000 ( 256 MB) pkmap : 0xbfe0 - 0xc000 ( 2 MB) .text : 0xc0008000 - 0xc055e6a8 (5466 kB) .init : 0xc055f000 - 0xc0594874 ( 215 kB) .data : 0xc0596000 - 0xc05fccc0 ( 412 kB) .bss : 0xc05fcce4 - 0xc0b2a1e8 (5302 kB) NR_IRQS:474 IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts Total of 96 interrupts on 1 active controller OMAP clockevent source: GPTIMER1 at 32768 Hz sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms OMAP clocksource: 32k_counter at 32768 Hz Console: colour dummy device 80x30 Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES: 8 ... MAX_LOCK_DEPTH: 48 ... MAX_LOCKDEP_KEYS:8191 ... CLASSHASH_SIZE: 4096 ... MAX_LOCKDEP_ENTRIES: 16384 ... MAX_LOCKDEP_CHAINS: 32768 ... CHAINHASH_SIZE: 16384 memory used by lock dependency info: 3695 kB per task-struct memory footprint: 1152 bytes Calibrating delay loop... 331.40 BogoMIPS (lpj=1296384) pid_max: default: 32768 minimum: 301 Security Framework initialized Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok Setting up static identity map for 0x80444ff0 - 0x80445048 devtmpfs: initialized dummy: NET: Registered protocol family 16 GPMC revision 5.0 gpmc: irq-20 could not claim: err -22 OMAP GPIO hardware version 2.5 omap_mux_init: Add partition: #1: core, flags: 0 _omap_mux_get_by_name: Could not find signal uart4_rx.uart4_rx Reprogramming SDRC clock to 33200 Hz dpll3_m2_clk rate change failed: -22 hw-breakpoint: debug architecture 0x4 unsupported. OMAP DMA hardware revision 4.0 bio: create slab bio-0 at 0 omap-dma-engine omap-dma-engine: OMAP DMA engine driver SCSI subsystem initialized omap_i2c omap_i2c.1: bus 1 rev1.3.12 at 400 kHz omap_i2c omap_i2c.2: bus 2 rev1.3.12 at 400 kHz omap_i2c omap_i2c.3: bus 3 rev1.3.12 at 400 kHz Bluetooth: Core ver 2.16 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: L2CAP socket layer initialized Bluetooth: SCO socket layer initialized cfg80211:
Re: [PATCHv7 06/12] ARM: OMAP4: suspend: Program all domains to retention
Hello. On 07/19/2012 05:26 PM, Tero Kristo wrote: From: Rajendra Nayak rna...@ti.com Remove the FIXME's in the suspend sequence since we now intend to support system level RET support. Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Tero Kristo t-kri...@ti.com [Jean Pihet j-pi...@ti.com: ported on top of the functional power states] Shouldn't Jean also have signed off? Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com 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
[PATCHv5 13/18] i2c: omap: simplify errata check
From: Felipe Balbi ba...@ti.com omap_i2c_dev is allocated with kzalloc(), so we need not initialize b_hw to zero. Signed-off-by: Felipe Balbi ba...@ti.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/i2c/busses/i2c-omap.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index d732865..19f6048 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1092,9 +1092,7 @@ omap_i2c_probe(struct platform_device *pdev) dev-fifo_size = (dev-fifo_size / 2); - if (dev-rev = OMAP_I2C_REV_ON_3630_4430) - dev-b_hw = 0; /* Disable hardware fixes */ - else + if (dev-rev OMAP_I2C_REV_ON_3630_4430) dev-b_hw = 1; /* Enable hardware fixes */ /* calculate wakeup latency constraint for MPU */ -- 1.7.5.4 -- 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
[PATCHv5 08/18] i2c: omap: re-factor receive/transmit data loop
From: Felipe Balbi ba...@ti.com
re-factor the common parts to a separate function,
so that code is easier to read and understand.
No functional changes.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 204
1 files changed, 82 insertions(+), 122 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 6f98812..700f018 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -749,12 +749,81 @@ static int errata_omap3_i462(struct omap_i2c_dev *dev)
return 0;
}
+static void omap_i2c_receive_data(struct omap_i2c_dev *dev, u8 num_bytes,
+ bool is_rdr)
+{
+ u16 w;
+
+ while (num_bytes--) {
+ if (!dev-buf_len) {
+ dev_err(dev-dev, %s without data,
+ is_rdr ? RDR : RRDY);
+ break;
+ }
+
+ w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
+ *dev-buf++ = w;
+ dev-buf_len--;
+
+ /*
+* Data reg in 2430, omap3 and
+* omap4 is 8 bit wide
+*/
+ if (dev-flags OMAP_I2C_FLAG_16BIT_DATA_REG) {
+ if (dev-buf_len) {
+ *dev-buf++ = w 8;
+ dev-buf_len--;
+ }
+ }
+ }
+}
+
+static int omap_i2c_transmit_data(struct omap_i2c_dev *dev, u8 num_bytes,
+ bool is_xdr)
+{
+ u16 w;
+
+ while (num_bytes--) {
+ if (!dev-buf_len) {
+ dev_err(dev-dev, %s without data,
+ is_xdr ? XDR : XRDY);
+ break;
+ }
+
+ w = *dev-buf++;
+ dev-buf_len--;
+
+ /*
+* Data reg in 2430, omap3 and
+* omap4 is 8 bit wide
+*/
+ if (dev-flags OMAP_I2C_FLAG_16BIT_DATA_REG) {
+ if (dev-buf_len) {
+ w |= *dev-buf++ 8;
+ dev-buf_len--;
+ }
+ }
+
+ if (dev-errata I2C_OMAP_ERRATA_I462) {
+ int ret;
+
+ ret = errata_omap3_i462(dev);
+ if (ret 0)
+ return ret;
+ }
+
+ omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
+ }
+
+ return 0;
+}
+
static irqreturn_t
omap_i2c_isr(int this_irq, void *dev_id)
{
struct omap_i2c_dev *dev = dev_id;
u16 bits;
- u16 stat, w;
+ u16 stat;
int err, count = 0;
if (pm_runtime_suspended(dev-dev))
@@ -807,30 +876,7 @@ complete:
if (dev-fifo_size)
num_bytes = dev-buf_len;
- while (num_bytes--) {
- if (!dev-buf_len) {
- dev_err(dev-dev,
- RDR IRQ while no data
-requested\n);
- break;
- }
-
- w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
- *dev-buf++ = w;
- dev-buf_len--;
-
- /*
-* Data reg in 2430, omap3 and
-* omap4 is 8 bit wide
-*/
- if (dev-flags
- OMAP_I2C_FLAG_16BIT_DATA_REG) {
- if (dev-buf_len) {
- *dev-buf++ = w 8;
- dev-buf_len--;
- }
- }
- }
+ omap_i2c_receive_data(dev, num_bytes, true);
if (dev-errata I2C_OMAP_ERRATA_I207)
i2c_omap_errata_i207(dev, stat);
@@ -845,77 +891,22 @@ complete:
if (dev-fifo_size)
num_bytes = dev-fifo_size;
- while (num_bytes--) {
- if (!dev-buf_len) {
- dev_err(dev-dev,
- RRDY IRQ while no data
-requested\n);
- break;
- }
-
-
[PATCHv5 05/18] i2c: omap: simplify omap_i2c_ack_stat()
From: Felipe Balbi ba...@ti.com
stat BIT(1) is the same as BIT(1), so let's
simplify things a bit by removing stat from
all omap_i2c_ack_stat() calls.
Code snippet (extremely simplified):
if (stat NACK) {
...
omap_i2c_ack_stat(dev, stat NACK);
}
if (stat RDR) {
...
omap_i2c_ack_stat(dev, stat RDR);
}
and so on. The tricky place is only WRT errata handling, for example:
if (*stat (NACK | AL)) {
omap_i2c_ack_stat(dev, *stat (XRDY | XDR));
...
}
but in this case, the errata says we must clear XRDY and XDR if that
errata triggers, so if they just got enabled or not, it doesn't matter.
Another tricky place is RDR | RRDY (likewise for XDR | XRDY):
if (stat (RDR | RRDY)) {
...
omap_i2c_ack_stat(dev, stat (RDR | RRDY));
}
again here there will be no issues because those IRQs never fire
simultaneously and one will only after after we have handled the
previous, that's because the same FIFO is used anyway and we won't shift
data into FIFO until we tell the IP hey, I'm done with the FIFO, you
can shift more data
Signed-off-by: Felipe Balbi ba...@ti.com
Reviewed-by : Santosh Shilimkar santosh.shilim...@ti.com
[Added the explaination from the discurssion to the commit logs]
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 19 ++-
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 323d52e..940ba64 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -728,7 +728,7 @@ static int errata_omap3_i462(struct omap_i2c_dev *dev, u16
*stat, int *err)
while (--timeout !(*stat OMAP_I2C_STAT_XUDF)) {
if (*stat (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
- omap_i2c_ack_stat(dev, *stat (OMAP_I2C_STAT_XRDY |
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
return -ETIMEDOUT;
}
@@ -789,10 +789,11 @@ complete:
*/
if (stat (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK |
OMAP_I2C_STAT_AL)) {
- omap_i2c_ack_stat(dev, stat
- (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR |
- OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR |
- OMAP_I2C_STAT_ARDY));
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_RRDY |
+ OMAP_I2C_STAT_RDR |
+ OMAP_I2C_STAT_XRDY |
+ OMAP_I2C_STAT_XDR |
+ OMAP_I2C_STAT_ARDY));
omap_i2c_complete_cmd(dev, err);
return IRQ_HANDLED;
}
@@ -839,8 +840,8 @@ complete:
}
}
}
- omap_i2c_ack_stat(dev,
- stat (OMAP_I2C_STAT_RRDY |
OMAP_I2C_STAT_RDR));
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_RRDY |
+ OMAP_I2C_STAT_RDR));
continue;
}
@@ -887,8 +888,8 @@ complete:
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
}
- omap_i2c_ack_stat(dev,
- stat (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_XRDY |
+ OMAP_I2C_STAT_XDR));
continue;
}
--
1.7.5.4
--
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
[PATCHv5 14/18] i2c: omap: always return IRQ_HANDLED
From: Felipe Balbi ba...@ti.com
otherwise we could get our IRQ line disabled due
to many spurious IRQs.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 19f6048..6847a98 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -959,7 +959,7 @@ complete:
}
} while (stat);
- return count ? IRQ_HANDLED : IRQ_NONE;
+ return IRQ_HANDLED;
}
static const struct i2c_algorithm omap_i2c_algo = {
--
1.7.5.4
--
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
[PATCHv5 02/18] i2c: omap: simplify num_bytes handling
From: Felipe Balbi ba...@ti.com
trivial patch, no functional changes
If the fifo is disabled or fifo_size is 0 the num_bytes
is set to 1. Else it is set to fifo_size or in case of a
draining interrupt the remaining bytes in the buff stat.
So the zero check is redundant and can be safely optimised.
Signed-off-by: Felipe Balbi ba...@ti.com
Reviewed-by : Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 788c16c..520f3ea 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -809,8 +809,7 @@ complete:
OMAP_I2C_BUFSTAT_REG)
8) 0x3F;
}
- while (num_bytes) {
- num_bytes--;
+ while (num_bytes--) {
w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
if (dev-buf_len) {
*dev-buf++ = w;
@@ -852,8 +851,7 @@ complete:
OMAP_I2C_BUFSTAT_REG)
0x3F;
}
- while (num_bytes) {
- num_bytes--;
+ while (num_bytes--) {
w = 0;
if (dev-buf_len) {
w = *dev-buf++;
--
1.7.5.4
--
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
[PATCHv5 12/18] i2c: omap: bus: add a receiver flag
From: Felipe Balbi ba...@ti.com
that way we can ignore TX IRQs while in receiver
mode and ignore RX IRQs while in transmitter mode.
Signed-off-by: Felipe Balbi ba...@ti.com
[Trivial formatting changes]
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 71047dd..d732865 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -199,6 +199,7 @@ struct omap_i2c_dev {
*/
u8 rev;
unsignedb_hw:1; /* bad h/w fixes */
+ unsignedreceiver:1; /* true when we're in receiver
mode */
u16 iestate;/* Saved interrupt register */
u16 pscstate;
u16 scllstate;
@@ -492,6 +493,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
INIT_COMPLETION(dev-cmd_complete);
dev-cmd_err = 0;
+ dev-receiver = !!(msg-flags I2C_M_RD);
w = OMAP_I2C_CON_EN | OMAP_I2C_CON_MST | OMAP_I2C_CON_STT;
@@ -834,6 +836,12 @@ omap_i2c_isr(int this_irq, void *dev_id)
stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
stat = bits;
+ /* If we're in receiver mode, ignore XDR/XRDY */
+ if (dev-receiver)
+ stat = ~(OMAP_I2C_STAT_XDR | OMAP_I2C_STAT_XRDY);
+ else
+ stat = ~(OMAP_I2C_STAT_RDR | OMAP_I2C_STAT_RRDY);
+
if (!stat) {
/* my work here is done */
return IRQ_HANDLED;
--
1.7.5.4
--
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] MMC: OMAP: make MMC_OMAP* depend on DMA_OMAP
Hi, On Thu, Jul 19 2012, S, Venkatraman wrote: Chris, I think we have to hold on to this patch just for today. There's another thread about this same issue on linux-omap Thanks, I've dropped it from mmc-next -- I'll wait for Russell or Tony to agree with one of the patches. - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- 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
[PATCHv5 10/18] i2c: omap: ack IRQ in parts
From: Felipe Balbi ba...@ti.com
According to flow diagrams on OMAP TRMs,
we should ACK the IRQ as they happen.
Signed-off-by: Felipe Balbi ba...@ti.com
[ack the stat OMAP_I2C_STAT_AL in case of arbitration lost]
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
v5 - ack the OMAP_I2C_STAT_AL.
drivers/i2c/busses/i2c-omap.c | 28
1 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 78fc274..62ad126 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -847,21 +847,19 @@ omap_i2c_isr(int this_irq, void *dev_id)
}
complete:
- /*
-* Ack the stat in one go, but [R/X]DR and [R/X]RDY should be
-* acked after the data operation is complete.
-* Ref: TRM SWPU114Q Figure 18-31
-*/
- omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat
- ~(OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR |
- OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR));
-
- if (stat OMAP_I2C_STAT_NACK)
+ if (stat OMAP_I2C_STAT_NACK) {
err |= OMAP_I2C_STAT_NACK;
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
+ omap_i2c_complete_cmd(dev, err);
+ return IRQ_HANDLED;
+ }
if (stat OMAP_I2C_STAT_AL) {
dev_err(dev-dev, Arbitration lost\n);
err |= OMAP_I2C_STAT_AL;
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_AL);
+ omap_i2c_complete_cmd(dev, err);
+ return IRQ_HANDLED;
}
/*
@@ -938,12 +936,18 @@ complete:
if (stat OMAP_I2C_STAT_ROVR) {
dev_err(dev-dev, Receive overrun\n);
- dev-cmd_err |= OMAP_I2C_STAT_ROVR;
+ err |= OMAP_I2C_STAT_ROVR;
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_ROVR);
+ omap_i2c_complete_cmd(dev, err);
+ return IRQ_HANDLED;
}
if (stat OMAP_I2C_STAT_XUDF) {
dev_err(dev-dev, Transmit underflow\n);
- dev-cmd_err |= OMAP_I2C_STAT_XUDF;
+ err |= OMAP_I2C_STAT_XUDF;
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XUDF);
+ omap_i2c_complete_cmd(dev, err);
+ return IRQ_HANDLED;
}
} while (stat);
--
1.7.5.4
--
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
[PATCHv5 07/18] i2c: omap: improve i462 errata handling
From: Felipe Balbi ba...@ti.com
Make it not depend on ISR's local variables
in order to make it easier to re-factor the
transmit data loop.
Also since we are waiting for XUDF(Transmitter underflow) just before
writing data lets not flag the underflow.
This is anyways going to go once we write
the data.
Signed-off-by: Felipe Balbi ba...@ti.com
[Avoid flagging the XUDF]
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 43
1 files changed, 30 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 5f6d9c5..6f98812 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -722,27 +722,30 @@ omap_i2c_omap1_isr(int this_irq, void *dev_id)
* data to DATA_REG. Otherwise some data bytes can be lost while transferring
* them from the memory to the I2C interface.
*/
-static int errata_omap3_i462(struct omap_i2c_dev *dev, u16 *stat, int *err)
+static int errata_omap3_i462(struct omap_i2c_dev *dev)
{
unsigned long timeout = 1;
+ u16 stat;
- while (--timeout !(*stat OMAP_I2C_STAT_XUDF)) {
- if (*stat (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
+ do {
+ stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
+ if (stat OMAP_I2C_STAT_XUDF)
+ break;
+
+ if (stat (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
- return -ETIMEDOUT;
+ return -EIO;
}
cpu_relax();
- *stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
- }
+ } while (--timeout);
if (!timeout) {
dev_err(dev-dev, timeout waiting on XUDF bit\n);
return 0;
}
- *err |= OMAP_I2C_STAT_XUDF;
return 0;
}
@@ -900,9 +903,16 @@ complete:
}
}
- if ((dev-errata I2C_OMAP_ERRATA_I462)
- errata_omap3_i462(dev, stat, err))
- goto complete;
+ if (dev-errata I2C_OMAP_ERRATA_I462) {
+ int ret;
+
+ ret = errata_omap3_i462(dev);
+ stat = omap_i2c_read_reg(dev,
+ OMAP_I2C_STAT_REG);
+
+ if (ret 0)
+ goto complete;
+ }
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
}
@@ -940,9 +950,16 @@ complete:
}
}
- if ((dev-errata I2C_OMAP_ERRATA_I462)
- errata_omap3_i462(dev, stat, err))
- goto complete;
+ if (dev-errata I2C_OMAP_ERRATA_I462) {
+ int ret;
+
+ ret = errata_omap3_i462(dev);
+ stat = omap_i2c_read_reg(dev,
+ OMAP_I2C_STAT_REG);
+
+ if (ret 0)
+ goto complete;
+ }
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
}
--
1.7.5.4
--
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
[PATCHv5 00/18] I2C big cleanup
Changes since v1:
- removed tabification on patch 6/17
- removed dev_err() which was introduced on patch 09/17
Changes since v2:
- do not set full fifo depth in the RDR interrupt.
- some changelog updates.
- rebase to the Wolfram's tree.
Changes since v3:
- Remove a redundant read of status register
- Read the dev-buf_len variable instead of the register
as the information of the remaining bytes is there.
Changes since v4:
- Ack the arbitration lost.
- Rebase to the i2c-embedded/for-next branch.
Tested on omap4sdp and 3430sdp.
Functional testing.
Also did suspend resume test.
This applies on Wolfram's i2c-embedded/for-next branch
Previous disscurssion
http://www.spinics.net/lists/linux-omap/msg73235.html
are available in the git repository at:
git://gitorious.org/linus-tree/linus-tree.git for_next/i2c/big_cleanup
Felipe Balbi (17):
i2c: omap: switch to devm_* API
i2c: omap: simplify num_bytes handling
i2c: omap: decrease indentation level on data handling
i2c: omap: add blank lines
i2c: omap: simplify omap_i2c_ack_stat()
i2c: omap: split out [XR]DR and [XR]RDY
i2c: omap: improve i462 errata handling
i2c: omap: re-factor receive/transmit data loop
i2c: omap: switch over to do {} while loop
i2c: omap: ack IRQ in parts
i2c: omap: switch to platform_get_irq()
i2c: omap: bus: add a receiver flag
i2c: omap: simplify errata check
i2c: omap: always return IRQ_HANDLED
i2c: omap: simplify IRQ exit path
i2c: omap: resize fifos before each message
i2c: omap: get rid of the complete label
Shubhrajyoti D (1):
i2c: omap: remove redundant status read
drivers/i2c/busses/i2c-omap.c | 392 -
1 files changed, 228 insertions(+), 164 deletions(-)
--
1.7.5.4
--
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
[PATCHv5 15/18] i2c: omap: simplify IRQ exit path
From: Felipe Balbi ba...@ti.com
instead of having multiple return points, use
a goto statement to make that clearer.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 20
1 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 6847a98..3f50021 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -850,24 +850,21 @@ omap_i2c_isr(int this_irq, void *dev_id)
dev_dbg(dev-dev, IRQ (ISR = 0x%04x)\n, stat);
if (count++ == 100) {
dev_warn(dev-dev, Too much work in one IRQ\n);
- omap_i2c_complete_cmd(dev, err);
- return IRQ_HANDLED;
+ goto out;
}
complete:
if (stat OMAP_I2C_STAT_NACK) {
err |= OMAP_I2C_STAT_NACK;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
- omap_i2c_complete_cmd(dev, err);
- return IRQ_HANDLED;
+ goto out;
}
if (stat OMAP_I2C_STAT_AL) {
dev_err(dev-dev, Arbitration lost\n);
err |= OMAP_I2C_STAT_AL;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_AL);
- omap_i2c_complete_cmd(dev, err);
- return IRQ_HANDLED;
+ goto out;
}
/*
@@ -880,8 +877,7 @@ complete:
OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR |
OMAP_I2C_STAT_ARDY));
- omap_i2c_complete_cmd(dev, err);
- return IRQ_HANDLED;
+ goto out;
}
if (stat OMAP_I2C_STAT_RDR) {
@@ -946,19 +942,19 @@ complete:
dev_err(dev-dev, Receive overrun\n);
err |= OMAP_I2C_STAT_ROVR;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_ROVR);
- omap_i2c_complete_cmd(dev, err);
- return IRQ_HANDLED;
+ goto out;
}
if (stat OMAP_I2C_STAT_XUDF) {
dev_err(dev-dev, Transmit underflow\n);
err |= OMAP_I2C_STAT_XUDF;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XUDF);
- omap_i2c_complete_cmd(dev, err);
- return IRQ_HANDLED;
+ goto out;
}
} while (stat);
+out:
+ omap_i2c_complete_cmd(dev, err);
return IRQ_HANDLED;
}
--
1.7.5.4
--
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
[PATCHv5 18/18] i2c: omap: remove redundant status read
Remove the redundant read of the status register. Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/i2c/busses/i2c-omap.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 2e48da9..7ad24ac 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -943,7 +943,6 @@ omap_i2c_isr(int this_irq, void *dev_id) num_bytes = dev-buf_len; ret = omap_i2c_transmit_data(dev, num_bytes, true); - stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG); if (ret 0) goto out; @@ -959,7 +958,6 @@ omap_i2c_isr(int this_irq, void *dev_id) num_bytes = dev-threshold; ret = omap_i2c_transmit_data(dev, num_bytes, false); - stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG); if (ret 0) goto out; -- 1.7.5.4 -- 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
[PATCHv5 16/18] i2c: omap: resize fifos before each message
From: Felipe Balbi ba...@ti.com
This patch will try to avoid the usage of
draining feature by reconfiguring the FIFO
the start condition of each message based
on the message's size.
By doing that, we will be better utilizing
the FIFO when doing big transfers.
While at that also drop the now unneeded
check for dev-buf_len as we always know
the amount of data to be transmitted.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 83 +
1 files changed, 51 insertions(+), 32 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 3f50021..05edae3 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -193,6 +193,7 @@ struct omap_i2c_dev {
u8 *regs;
size_t buf_len;
struct i2c_adapter adapter;
+ u8 threshold;
u8 fifo_size; /* use as flag and value
* fifo_size==0 implies no fifo
* if set, should be trsh+1
@@ -418,13 +419,6 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, scll);
omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, sclh);
- if (dev-fifo_size) {
- /* Note: setup required fifo size - 1. RTRSH and XTRSH */
- buf = (dev-fifo_size - 1) 8 | OMAP_I2C_BUF_RXFIF_CLR |
- (dev-fifo_size - 1) | OMAP_I2C_BUF_TXFIF_CLR;
- omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, buf);
- }
-
/* Take the I2C module out of reset: */
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
@@ -462,6 +456,45 @@ static int omap_i2c_wait_for_bb(struct omap_i2c_dev *dev)
return 0;
}
+static void omap_i2c_resize_fifo(struct omap_i2c_dev *dev, u8 size, bool is_rx)
+{
+ u16 buf;
+
+ if (dev-flags OMAP_I2C_FLAG_NO_FIFO)
+ return;
+
+ /*
+* Set up notification threshold based on message size. We're doing
+* this to try and avoid draining feature as much as possible. Whenever
+* we have big messages to transfer (bigger than our total fifo size)
+* then we might use draining feature to transfer the remaining bytes.
+*/
+
+ dev-threshold = clamp(size, (u8) 1, dev-fifo_size);
+
+ buf = omap_i2c_read_reg(dev, OMAP_I2C_BUF_REG);
+
+ if (is_rx) {
+ /* Clear RX Threshold */
+ buf = ~(0x3f 8);
+ buf |= ((dev-threshold - 1) 8) | OMAP_I2C_BUF_RXFIF_CLR;
+ } else {
+ /* Clear TX Threshold */
+ buf = ~0x3f;
+ buf |= (dev-threshold - 1) | OMAP_I2C_BUF_TXFIF_CLR;
+ }
+
+ omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, buf);
+
+ if (dev-rev OMAP_I2C_REV_ON_3630_4430)
+ dev-b_hw = 1; /* Enable hardware fixes */
+
+ /* calculate wakeup latency constraint for MPU */
+ if (dev-set_mpu_wkup_lat != NULL)
+ dev-latency = (100 * dev-threshold) /
+ (1000 * dev-speed / 8);
+}
+
/*
* Low level master read/write transaction.
*/
@@ -478,6 +511,9 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
if (msg-len == 0)
return -EINVAL;
+ dev-receiver = !!(msg-flags I2C_M_RD);
+ omap_i2c_resize_fifo(dev, msg-len, dev-receiver);
+
omap_i2c_write_reg(dev, OMAP_I2C_SA_REG, msg-addr);
/* REVISIT: Could the STB bit of I2C_CON be used with probing? */
@@ -493,7 +529,6 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
INIT_COMPLETION(dev-cmd_complete);
dev-cmd_err = 0;
- dev-receiver = !!(msg-flags I2C_M_RD);
w = OMAP_I2C_CON_EN | OMAP_I2C_CON_MST | OMAP_I2C_CON_STT;
@@ -757,12 +792,6 @@ static void omap_i2c_receive_data(struct omap_i2c_dev
*dev, u8 num_bytes,
u16 w;
while (num_bytes--) {
- if (!dev-buf_len) {
- dev_err(dev-dev, %s without data,
- is_rdr ? RDR : RRDY);
- break;
- }
-
w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
*dev-buf++ = w;
dev-buf_len--;
@@ -772,10 +801,8 @@ static void omap_i2c_receive_data(struct omap_i2c_dev
*dev, u8 num_bytes,
* omap4 is 8 bit wide
*/
if (dev-flags OMAP_I2C_FLAG_16BIT_DATA_REG) {
- if (dev-buf_len) {
- *dev-buf++ = w 8;
- dev-buf_len--;
- }
+ *dev-buf++ = w 8;
+ dev-buf_len--;
}
}
}
[PATCHv5 09/18] i2c: omap: switch over to do {} while loop
From: Felipe Balbi ba...@ti.com
this will make sure that we execute at least once.
No functional changes otherwise.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 20 ++--
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 700f018..78fc274 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -824,20 +824,28 @@ omap_i2c_isr(int this_irq, void *dev_id)
struct omap_i2c_dev *dev = dev_id;
u16 bits;
u16 stat;
- int err, count = 0;
+ int err = 0, count = 0;
if (pm_runtime_suspended(dev-dev))
return IRQ_NONE;
- bits = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
- while ((stat = (omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG))) bits) {
+ do {
+ bits = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
+ stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
+ stat = bits;
+
+ if (!stat) {
+ /* my work here is done */
+ return IRQ_HANDLED;
+ }
+
dev_dbg(dev-dev, IRQ (ISR = 0x%04x)\n, stat);
if (count++ == 100) {
dev_warn(dev-dev, Too much work in one IRQ\n);
- break;
+ omap_i2c_complete_cmd(dev, err);
+ return IRQ_HANDLED;
}
- err = 0;
complete:
/*
* Ack the stat in one go, but [R/X]DR and [R/X]RDY should be
@@ -937,7 +945,7 @@ complete:
dev_err(dev-dev, Transmit underflow\n);
dev-cmd_err |= OMAP_I2C_STAT_XUDF;
}
- }
+ } while (stat);
return count ? IRQ_HANDLED : IRQ_NONE;
}
--
1.7.5.4
--
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
[PATCHv5 01/18] i2c: omap: switch to devm_* API
From: Felipe Balbi ba...@ti.com
that helps deleting some boiler plate code
and lets driver-core manage our resources
for us.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 41 -
1 files changed, 12 insertions(+), 29 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 8c2d7cf..788c16c 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -940,7 +940,7 @@ omap_i2c_probe(struct platform_device *pdev)
{
struct omap_i2c_dev *dev;
struct i2c_adapter *adap;
- struct resource *mem, *irq, *ioarea;
+ struct resource *mem, *irq;
struct omap_i2c_bus_platform_data *pdata = pdev-dev.platform_data;
struct device_node *node = pdev-dev.of_node;
const struct of_device_id *match;
@@ -959,17 +959,16 @@ omap_i2c_probe(struct platform_device *pdev)
return -ENODEV;
}
- ioarea = request_mem_region(mem-start, resource_size(mem),
- pdev-name);
- if (!ioarea) {
- dev_err(pdev-dev, I2C region already claimed\n);
- return -EBUSY;
+ dev = devm_kzalloc(pdev-dev, sizeof(struct omap_i2c_dev), GFP_KERNEL);
+ if (!dev) {
+ dev_err(pdev-dev, Menory allocation failed\n);
+ return -ENOMEM;
}
- dev = kzalloc(sizeof(struct omap_i2c_dev), GFP_KERNEL);
- if (!dev) {
- r = -ENOMEM;
- goto err_release_region;
+ dev-base = devm_request_and_ioremap(pdev-dev, mem);
+ if (!dev-base) {
+ dev_err(pdev-dev, I2C region already claimed\n);
+ return -ENOMEM;
}
match = of_match_device(of_match_ptr(omap_i2c_of_match), pdev-dev);
@@ -992,11 +991,6 @@ omap_i2c_probe(struct platform_device *pdev)
dev-dev = pdev-dev;
dev-irq = irq-start;
- dev-base = ioremap(mem-start, resource_size(mem));
- if (!dev-base) {
- r = -ENOMEM;
- goto err_free_mem;
- }
platform_set_drvdata(pdev, dev);
init_completion(dev-cmd_complete);
@@ -1054,7 +1048,8 @@ omap_i2c_probe(struct platform_device *pdev)
isr = (dev-rev OMAP_I2C_OMAP1_REV_2) ? omap_i2c_omap1_isr :
omap_i2c_isr;
- r = request_irq(dev-irq, isr, IRQF_NO_SUSPEND, pdev-name, dev);
+ r = devm_request_irq(pdev-dev, dev-irq, isr, IRQF_NO_SUSPEND,
+pdev-name, dev);
if (r) {
dev_err(dev-dev, failure requesting irq %i\n, dev-irq);
@@ -1078,7 +1073,7 @@ omap_i2c_probe(struct platform_device *pdev)
r = i2c_add_numbered_adapter(adap);
if (r) {
dev_err(dev-dev, failure adding adapter\n);
- goto err_free_irq;
+ goto err_unuse_clocks;
}
of_i2c_register_devices(adap);
@@ -1087,18 +1082,12 @@ omap_i2c_probe(struct platform_device *pdev)
return 0;
-err_free_irq:
- free_irq(dev-irq, dev);
err_unuse_clocks:
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(dev-dev);
- iounmap(dev-base);
pm_runtime_disable(pdev-dev);
err_free_mem:
platform_set_drvdata(pdev, NULL);
- kfree(dev);
-err_release_region:
- release_mem_region(mem-start, resource_size(mem));
return r;
}
@@ -1106,12 +1095,10 @@ err_release_region:
static int __devexit omap_i2c_remove(struct platform_device *pdev)
{
struct omap_i2c_dev *dev = platform_get_drvdata(pdev);
- struct resource *mem;
int ret;
platform_set_drvdata(pdev, NULL);
- free_irq(dev-irq, dev);
i2c_del_adapter(dev-adapter);
ret = pm_runtime_get_sync(pdev-dev);
if (IS_ERR_VALUE(ret))
@@ -1120,10 +1107,6 @@ static int __devexit omap_i2c_remove(struct
platform_device *pdev)
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(pdev-dev);
pm_runtime_disable(pdev-dev);
- iounmap(dev-base);
- kfree(dev);
- mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- release_mem_region(mem-start, resource_size(mem));
return 0;
}
--
1.7.5.4
--
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
[PATCHv5 04/18] i2c: omap: add blank lines
From: Felipe Balbi ba...@ti.com
trivial patch to aid readability. No functional
changes.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 6550a7f..323d52e 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -783,6 +783,7 @@ complete:
dev_err(dev-dev, Arbitration lost\n);
err |= OMAP_I2C_STAT_AL;
}
+
/*
* ProDB0017052: Clear ARDY bit twice
*/
@@ -795,6 +796,7 @@ complete:
omap_i2c_complete_cmd(dev, err);
return IRQ_HANDLED;
}
+
if (stat (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
u8 num_bytes = 1;
@@ -841,6 +843,7 @@ complete:
stat (OMAP_I2C_STAT_RRDY |
OMAP_I2C_STAT_RDR));
continue;
}
+
if (stat (OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR)) {
u8 num_bytes = 1;
if (dev-fifo_size) {
@@ -888,10 +891,12 @@ complete:
stat (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
continue;
}
+
if (stat OMAP_I2C_STAT_ROVR) {
dev_err(dev-dev, Receive overrun\n);
dev-cmd_err |= OMAP_I2C_STAT_ROVR;
}
+
if (stat OMAP_I2C_STAT_XUDF) {
dev_err(dev-dev, Transmit underflow\n);
dev-cmd_err |= OMAP_I2C_STAT_XUDF;
--
1.7.5.4
--
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
[PATCHv5 06/18] i2c: omap: split out [XR]DR and [XR]RDY
From: Felipe Balbi ba...@ti.com
While they do pretty much the same thing, there
are a few peculiarities. Specially WRT erratas,
it's best to split those out and re-factor the
read/write loop to another function which both
cases call.
This last part will be done on another patch.
While at that, also avoid an unncessary register
read since dev-fifo_len will always contain the
correct amount of data to be transferred.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
v4: use dev-buf_len as it is in sync with the remaining
bytes avoids a reg read thereby
drivers/i2c/busses/i2c-omap.c | 126 ++---
1 files changed, 92 insertions(+), 34 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 940ba64..5f6d9c5 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -798,36 +798,62 @@ complete:
return IRQ_HANDLED;
}
- if (stat (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
+ if (stat OMAP_I2C_STAT_RDR) {
u8 num_bytes = 1;
+ if (dev-fifo_size)
+ num_bytes = dev-buf_len;
+
+ while (num_bytes--) {
+ if (!dev-buf_len) {
+ dev_err(dev-dev,
+ RDR IRQ while no data
+requested\n);
+ break;
+ }
+
+ w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
+ *dev-buf++ = w;
+ dev-buf_len--;
+
+ /*
+* Data reg in 2430, omap3 and
+* omap4 is 8 bit wide
+*/
+ if (dev-flags
+ OMAP_I2C_FLAG_16BIT_DATA_REG) {
+ if (dev-buf_len) {
+ *dev-buf++ = w 8;
+ dev-buf_len--;
+ }
+ }
+ }
+
if (dev-errata I2C_OMAP_ERRATA_I207)
i2c_omap_errata_i207(dev, stat);
- if (dev-fifo_size) {
- if (stat OMAP_I2C_STAT_RRDY)
- num_bytes = dev-fifo_size;
- else/* read RXSTAT on RDR interrupt */
- num_bytes = (omap_i2c_read_reg(dev,
- OMAP_I2C_BUFSTAT_REG)
-8) 0x3F;
- }
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR);
+ continue;
+ }
+
+ if (stat OMAP_I2C_STAT_RRDY) {
+ u8 num_bytes = 1;
+
+ if (dev-fifo_size)
+ num_bytes = dev-fifo_size;
+
while (num_bytes--) {
if (!dev-buf_len) {
- if (stat OMAP_I2C_STAT_RRDY)
- dev_err(dev-dev,
+ dev_err(dev-dev,
RRDY IRQ while no data
-requested\n);
- if (stat OMAP_I2C_STAT_RDR)
- dev_err(dev-dev,
- RDR IRQ while no data
-requested\n);
+requested\n);
break;
}
w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
*dev-buf++ = w;
dev-buf_len--;
+
/*
* Data reg in 2430, omap3 and
* omap4 is 8 bit wide
@@ -840,36 +866,68 @@ complete:
}
}
}
- omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_RRDY |
- OMAP_I2C_STAT_RDR));
+
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RRDY);
continue;
[PATCHv5 11/18] i2c: omap: switch to platform_get_irq()
From: Felipe Balbi ba...@ti.com
that's a nice helper from drivers core which
will give us the exact IRQ number, instead
of a pointer to an IRQ resource.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 62ad126..71047dd 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -990,11 +990,12 @@ omap_i2c_probe(struct platform_device *pdev)
{
struct omap_i2c_dev *dev;
struct i2c_adapter *adap;
- struct resource *mem, *irq;
+ struct resource *mem;
struct omap_i2c_bus_platform_data *pdata = pdev-dev.platform_data;
struct device_node *node = pdev-dev.of_node;
const struct of_device_id *match;
irq_handler_t isr;
+ int irq;
int r;
/* NOTE: driver uses the static register mapping */
@@ -1003,10 +1004,11 @@ omap_i2c_probe(struct platform_device *pdev)
dev_err(pdev-dev, no mem resource?\n);
return -ENODEV;
}
- irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (!irq) {
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq 0) {
dev_err(pdev-dev, no irq resource?\n);
- return -ENODEV;
+ return irq;
}
dev = devm_kzalloc(pdev-dev, sizeof(struct omap_i2c_dev), GFP_KERNEL);
@@ -1040,7 +1042,7 @@ omap_i2c_probe(struct platform_device *pdev)
}
dev-dev = pdev-dev;
- dev-irq = irq-start;
+ dev-irq = irq;
platform_set_drvdata(pdev, dev);
init_completion(dev-cmd_complete);
--
1.7.5.4
--
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
[PATCHv5 03/18] i2c: omap: decrease indentation level on data handling
From: Felipe Balbi ba...@ti.com
The patch intends to decrease the indentation level on the
data handling
by using the fact that else of if (dev-buf_len) is same as
if (!dev-buf_len)
if (dev-buf_len) {
aaa;
} else {
bbb;
break;
}
to
if (!dev-buf_len) {
bbb;
break;
}
aaa;
Hence no functional changes.
Signed-off-by: Felipe Balbi ba...@ti.com
Reviewed-by : Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 63 -
1 files changed, 31 insertions(+), 32 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 520f3ea..6550a7f 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -810,22 +810,7 @@ complete:
8) 0x3F;
}
while (num_bytes--) {
- w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
- if (dev-buf_len) {
- *dev-buf++ = w;
- dev-buf_len--;
- /*
-* Data reg in 2430, omap3 and
-* omap4 is 8 bit wide
-*/
- if (dev-flags
-OMAP_I2C_FLAG_16BIT_DATA_REG) {
- if (dev-buf_len) {
- *dev-buf++ = w 8;
- dev-buf_len--;
- }
- }
- } else {
+ if (!dev-buf_len) {
if (stat OMAP_I2C_STAT_RRDY)
dev_err(dev-dev,
RRDY IRQ while no data
@@ -836,6 +821,21 @@ complete:
requested\n);
break;
}
+
+ w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
+ *dev-buf++ = w;
+ dev-buf_len--;
+ /*
+* Data reg in 2430, omap3 and
+* omap4 is 8 bit wide
+*/
+ if (dev-flags
+ OMAP_I2C_FLAG_16BIT_DATA_REG) {
+ if (dev-buf_len) {
+ *dev-buf++ = w 8;
+ dev-buf_len--;
+ }
+ }
}
omap_i2c_ack_stat(dev,
stat (OMAP_I2C_STAT_RRDY |
OMAP_I2C_STAT_RDR));
@@ -852,22 +852,7 @@ complete:
0x3F;
}
while (num_bytes--) {
- w = 0;
- if (dev-buf_len) {
- w = *dev-buf++;
- dev-buf_len--;
- /*
-* Data reg in 2430, omap3 and
-* omap4 is 8 bit wide
-*/
- if (dev-flags
-OMAP_I2C_FLAG_16BIT_DATA_REG) {
- if (dev-buf_len) {
- w |= *dev-buf++ 8;
- dev-buf_len--;
- }
- }
- } else {
+ if (!dev-buf_len) {
if (stat OMAP_I2C_STAT_XRDY)
dev_err(dev-dev,
XRDY IRQ while no
@@ -879,6 +864,20 @@ complete:
break;
}
+ w = *dev-buf++;
+ dev-buf_len--;
+ /*
+* Data reg in 2430, omap3 and
+* omap4 is 8 bit wide
+
Re: [PATCHv7 07/12] ARM: OMAP4: PM: put all domains to OSWR during suspend
On Thu, 19 Jul 2012, Tero Kristo wrote: Signed-off-by: Tero Kristo t-kri...@ti.com This one needs at least some short description for the changelog. Maybe just a brief explanation that OSWR saves more energy that CSWR, but has higher resume latency, and since resume from system suspend is considered to be a high-latency operation, OSWR is appropriate here. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv5 17/18] i2c: omap: get rid of the complete label
From: Felipe Balbi ba...@ti.com
we can ack stat and complete the command from
the errata handling itself.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 05edae3..2e48da9 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -772,6 +772,17 @@ static int errata_omap3_i462(struct omap_i2c_dev *dev)
if (stat (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
+ if (stat OMAP_I2C_STAT_NACK) {
+ dev-cmd_err |= OMAP_I2C_STAT_NACK;
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
+ }
+
+ if (stat OMAP_I2C_STAT_AL) {
+ dev_err(dev-dev, Arbitration lost\n);
+ dev-cmd_err |= OMAP_I2C_STAT_AL;
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
+ }
+
return -EIO;
}
@@ -872,7 +883,6 @@ omap_i2c_isr(int this_irq, void *dev_id)
goto out;
}
-complete:
if (stat OMAP_I2C_STAT_NACK) {
err |= OMAP_I2C_STAT_NACK;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
@@ -935,7 +945,7 @@ complete:
ret = omap_i2c_transmit_data(dev, num_bytes, true);
stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
if (ret 0)
- goto complete;
+ goto out;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XDR);
continue;
@@ -951,7 +961,7 @@ complete:
ret = omap_i2c_transmit_data(dev, num_bytes, false);
stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
if (ret 0)
- goto complete;
+ goto out;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XRDY);
continue;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 09/11] drivers: usb: musb: Add device tree support for omap musb glue
Hi,
On Thu, Jul 19, 2012 at 6:51 PM, Gupta, Ajay Kumar ajay.gu...@ti.com wrote:
Hi,
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt | 34 -
drivers/usb/musb/omap2430.c| 55
2 files changed, 88 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 80a28c9..39cdffb 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -1,4 +1,4 @@
-OMAP USB PHY
+OMAP USB PHY AND GLUE
OMAP USB2 PHY
@@ -14,3 +14,35 @@ usb2phy@0x4a0ad080 {
compatible = ti,omap-usb2;
reg = 0x4a0ad080 0x58;
};
+
+OMAP MUSB GLUE
+ - compatible : Should be ti,musb-omap2430
+ - ti,hwmods : must be usb_otg_hs
+ - multipoint : Should be 1 indicating the musb controller supports
+ multipoint. This is a MUSB configuration-specific setting.
+ - num_eps : Specifies the number of endpoints. This is also a
+ MUSB configuration-specific setting. Should be set to 16
+ - ram_bits : Specifies the ram address size. Should be set to 12
+ - interface_type : This is a board specific setting to describe the type
of
+ interface between the controller and the phy. It should be 0 or 1
+ specifying ULPI and UTMI respectively.
+ - mode : Should be 3 to represent OTG. 1 signifies HOST and 2
+ represents PERIPHERAL.
+ - power : Should be 50. This signifies the controller can supply upto
+ 100mA when operating in host mode.
+
+SOC specific device node entry
+usb_otg_hs: usb_otg_hs@4a0ab000 {
+ compatible = ti,musb-omap2430;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+};
+
+Board specific device node entry
+usb_otg_hs {
+ interface_type = 1;
+ mode = 3;
+ power = 50;
+};
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index addbebf..331e477 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -30,6 +30,7 @@
#include linux/init.h
#include linux/list.h
#include linux/io.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/pm_runtime.h
@@ -469,8 +470,11 @@ static u64 omap2430_dmamask = DMA_BIT_MASK(32);
static int __devinit omap2430_probe(struct platform_device *pdev)
{
struct musb_hdrc_platform_data *pdata = pdev-dev.platform_data;
+ struct omap_musb_board_data *data;
struct platform_device *musb;
struct omap2430_glue*glue;
+ struct device_node *np = pdev-dev.of_node;
+ struct musb_hdrc_config *config;
struct resource *res;
int ret = -ENOMEM;
@@ -500,6 +504,43 @@ static int __devinit omap2430_probe(struct
platform_device *pdev)
if (glue-control_otghs == NULL)
dev_dbg(pdev-dev, Failed to obtain control memory\n);
+ if (np) {
+ pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(pdev-dev,
+ failed to allocate musb platfrom data\n);
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ dev_err(pdev-dev,
+ failed to allocate musb board
data\n);
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ config = devm_kzalloc(pdev-dev, sizeof(*config), GFP_KERNEL);
+ if (!data) {
+ dev_err(pdev-dev,
+ failed to allocate musb hdrc config\n);
+ goto err1;
+ }
+
+ of_property_read_u32(np, mode, (u32 *)pdata-mode);
+ of_property_read_u32(np, interface_type,
+ (u32 *)data-interface_type);
+ of_property_read_u32(np, num_eps, (u32 *)config-num_eps);
+ of_property_read_u32(np, ram_bits, (u32 *)config-ram_bits);
+ of_property_read_u32(np, mode, (u32 *)pdata-mode);
pdata-mode is already read so above should be removed.
Ok.
Thanks
Kishon
--
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: USB : Fix the EHCI enumeration and core retention issue
On Thu, 19 Jul 2012, Felipe Balbi wrote: Hi, On Thu, Jun 21, 2012 at 07:12:12PM +0530, Keshava Munegowda wrote: This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) is causing the usb hub and device detection fails in beagle XM causeing NFS not functional. This affects the core retention too. The same commit logic needs to be revisted adhering to hwmod and device tree framework. for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) reverted. This patch is validated on BeagleXM with NFS support over usb ethernet and USB mass storage and other device detection. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Acked-by: Felipe Balbi ba...@ti.com turns out this is causing other issues and another version of the patch will be provided. Greg, Alan, this is basically a git revert of the commit id listed above. I have no objection to reverting the patch. But on a related note, have you had a chance to read my comment: http://marc.info/?l=linux-usbm=134098423528415w=2 ? Alan Stern -- 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: [PATCHv7 07/12] ARM: OMAP4: PM: put all domains to OSWR during suspend
On Thu, 2012-07-19 at 08:44 -0600, Paul Walmsley wrote: On Thu, 19 Jul 2012, Tero Kristo wrote: Signed-off-by: Tero Kristo t-kri...@ti.com This one needs at least some short description for the changelog. Maybe just a brief explanation that OSWR saves more energy that CSWR, but has higher resume latency, and since resume from system suspend is considered to be a high-latency operation, OSWR is appropriate here. Yea, I can add one. How about this: Subject: [PATCHv7 07/12] ARM: OMAP4: PM: put all domains to OSWR during suspend Currently OMAP4 suspend puts all power domains to CSWR. OSWR is a deeper state that saves more power, but has higher latencies also. As suspend is considered a high-latency operation, OSWR is appropriate here. Signed-off-by: Tero Kristo t-kri...@ti.com --- I'll update this to next rev if one is requested. (Kind of hoping this set would be reaching maturity already.) -Tero -- 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 2/2] arm: omap3: am35x: Disable hlt when using Davinci EMAC
On Wed, Jul 18, 2012 at 05:25:16PM -0600, Paul Walmsley wrote: On Wed, 18 Jul 2012, Mark A. Greer wrote: On Tue, Jul 17, 2012 at 09:54:53PM -0600, Paul Walmsley wrote: Want to try something like this? It's your patch but modified to not use disable/enable_hlt(). If it doesn't work in your test case, maybe try uncommenting that second set of deny_idle / allow_idle ... I tested the modified patch (to get it to compile) below. Doh, sorry about that. No worries. It did not work with or without the core_dpll_ck deny_idle/allow_idle commented out. Here's a version with some of the CPUIdle states restricted. Maybe try this one if you're using CPUIdle? I wasn't but I tried this lastest patch with and without CPUidle... If it happens to work, it would also be interesting to know if it works with the CORE DPLL part commented out. ...and, unfortunately, it didnt' work in either case. Mark -- 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] ARM: OMAP3: clockdomain: fix accidental duplicate registration
On Thu, 19 Jul 2012, Tony Lindgren wrote: Well I'm still a bit confused :) Which branch in arm-soc tree should this fix be applied then? In terms of arm-soc, it's needed in arm-soc for-next, due to commit 066b6eba6d58ad1cb9ec3917b6ee79730c3c3310 (Merge branch 'next/cleanup' into for-next). That merge commit resolves the conflict the same way that the linux-omap tree commit 3dd50d0545bd5a8ad83d4339f07935cd3e883271 (Merge tag 'omap-cleanup-for-v3.6' into tmp-merge) did. 066b6eba is also present in a few other arm-soc branches: arm-soc/staging/io-cleanup-pci arm-soc/tmp I did not do an exhaustive search for similar mismerges under different commit IDs. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] arm: omap3: am35x: Disable hlt when using Davinci EMAC
On Thu, 19 Jul 2012, Mark A. Greer wrote: ...and, unfortunately, it didnt' work in either case. OK thanks for the tests. Is the EMAC/MDIO really active and asserting interrupts while all this is happening? Or has that driver called pm_runtime_put*(), and so the EMAC/MDIO isn't waking up? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAPDSS: Do not require a VDDS_DSI regulator on am35xx
On our AM3505 based board, dpi.c complains that there is no VDSS_DSI regulator
and the framebuffer cannot be enabled. However, this check does not seem to
apply to AM3505/17 chips.
I am not the first facing this issue, see this thread from Nov. 2011:
http://marc.info/?l=linux-omapm=132147745930213w=2
The string 'vdds_dsi' does appear once in the technical reference manual[1]
but there is no corresponding power pin on the package[2]. I failed to
locate any signal that could be an equivalent. I am trying to obtain some
clarifications on TI's forum[3]...
In any case, I am currently running with the patch below. In order to keep
cpu_is_xx uses to a minimum, I check for am35xx once at init time and allow
dpi.vdds_dsi_reg to be NULL from then on, getting rid of all the other
cpu_is_omap34xx uses in the process.
Your comments would be appreciated. Please also consider for merging.
[1] http://www.ti.com/litv/pdf/sprugr0b
[2] http://www.ti.com/lit/gpn/am3505
[3]
http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/416/t/202586.aspx
Signed-off-by: Raphael Assenat r...@8d.com
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 8c2056c..d3b428d 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -180,11 +180,6 @@ int omapdss_dpi_display_enable(struct omap_dss_device
*dssdev)
{
int r;
- if (cpu_is_omap34xx() !dpi.vdds_dsi_reg) {
- DSSERR(no VDSS_DSI regulator\n);
- return -ENODEV;
- }
-
if (dssdev-manager == NULL) {
DSSERR(failed to enable display: no manager\n);
return -ENODEV;
@@ -196,7 +191,7 @@ int omapdss_dpi_display_enable(struct omap_dss_device
*dssdev)
goto err_start_dev;
}
- if (cpu_is_omap34xx()) {
+ if (dpi.vdds_dsi_reg) {
r = regulator_enable(dpi.vdds_dsi_reg);
if (r)
goto err_reg_enable;
@@ -240,7 +235,7 @@ err_dsi_pll_init:
err_get_dsi:
dispc_runtime_put();
err_get_dispc:
- if (cpu_is_omap34xx())
+ if (dpi.vdds_dsi_reg)
regulator_disable(dpi.vdds_dsi_reg);
err_reg_enable:
omap_dss_stop_device(dssdev);
@@ -261,7 +256,7 @@ void omapdss_dpi_display_disable(struct omap_dss_device
*dssdev)
dispc_runtime_put();
- if (cpu_is_omap34xx())
+ if (dpi.vdds_dsi_reg)
regulator_disable(dpi.vdds_dsi_reg);
omap_dss_stop_device(dssdev);
@@ -343,7 +338,7 @@ static int __init dpi_init_display(struct omap_dss_device
*dssdev)
{
DSSDBG(init_display\n);
- if (cpu_is_omap34xx() dpi.vdds_dsi_reg == NULL) {
+ if (cpu_is_omap34xx() dpi.vdds_dsi_reg == NULL !soc_is_am35xx()) {
struct regulator *vdds_dsi;
vdds_dsi = dss_get_vdds_dsi();
--
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 2/2] arm: omap3: am35x: Disable hlt when using Davinci EMAC
On Thu, Jul 19, 2012 at 01:19:13PM -0600, Paul Walmsley wrote: On Thu, 19 Jul 2012, Mark A. Greer wrote: ...and, unfortunately, it didnt' work in either case. OK thanks for the tests. Is the EMAC/MDIO really active and asserting interrupts while all this is happening? I should be active but I have not way to tell for sure. Or has that driver called pm_runtime_put*(), and so the EMAC/MDIO isn't waking up? pm_runtime_get has definitely been called and pm_runtime_put has definitely _not_ been called. Mark -- 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: am3517: geting MMC working
On Thu, 19 Jul 2012, S, Venkatraman wrote: From this, one can only infer that the card is not responding at all, and all attempts are returning with a timeout (CTO=Command Time Out). Looks to me like the card is responding to CMD8, CMD55, ACMD41, and CMD0. It's only CMD52 and CMD5 that are timing out. Aren't those timeouts expected with a SD memory card? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] net: ethernet: davinci_emac: add pm_runtime support
From: Mark A. Greer mgr...@animalcreek.com
Add pm_runtime support to the TI Davinci EMAC driver.
CC: Sekhar Nori nsek...@ti.com
CC: Kevin Hilman khil...@ti.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
a) This patch depends on a patch by Kevin Hilman that has been
accepted for 3.6 and is waiting in arm-soc/for-next:
ce9dcb8784611c50974d1c6b600c71f5c0a29308
(ARM: davinci: add runtime PM support for clock management)
b) Applies on top of current k.o. master:
3e4b9459fb0e149c6b74c9e89399a8fc39a92b44
(Merge tag 'md-3.5-fixes' of git://neil.brown.name/md)
drivers/net/ethernet/ti/davinci_emac.c | 43 +-
1 file changed, 22 insertions(+), 21 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_emac.c
b/drivers/net/ethernet/ti/davinci_emac.c
index 4da93a5..f9153b7 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -57,6 +57,7 @@
#include linux/bitops.h
#include linux/io.h
#include linux/uaccess.h
+#include linux/pm_runtime.h
#include linux/davinci_emac.h
#include asm/irq.h
@@ -346,10 +347,6 @@ struct emac_priv {
void (*int_disable) (void);
};
-/* clock frequency for EMAC */
-static struct clk *emac_clk;
-static unsigned long emac_bus_frequency;
-
/* EMAC TX Host Error description strings */
static char *emac_txhost_errcodes[16] = {
No error, SOP error, Ownership bit not set in SOP buffer,
@@ -1535,6 +1532,8 @@ static int emac_dev_open(struct net_device *ndev)
int k = 0;
struct emac_priv *priv = netdev_priv(ndev);
+ pm_runtime_get(priv-pdev-dev);
+
netif_carrier_off(ndev);
for (cnt = 0; cnt ETH_ALEN; cnt++)
ndev-dev_addr[cnt] = priv-mac_addr[cnt];
@@ -1604,7 +1603,7 @@ static int emac_dev_open(struct net_device *ndev)
priv-phy_id);
ret = PTR_ERR(priv-phydev);
priv-phydev = NULL;
- return ret;
+ goto err;
}
priv-link = 0;
@@ -1645,7 +1644,11 @@ rollback:
res = platform_get_resource(priv-pdev, IORESOURCE_IRQ, k-1);
m = res-end;
}
- return -EBUSY;
+
+ ret = -EBUSY;
+err:
+ pm_runtime_put(priv-pdev-dev);
+ return ret;
}
/**
@@ -1687,6 +1690,7 @@ static int emac_dev_stop(struct net_device *ndev)
if (netif_msg_drv(priv))
dev_notice(emac_dev, DaVinci EMAC: %s stopped\n, ndev-name);
+ pm_runtime_put(priv-pdev-dev);
return 0;
}
@@ -1780,6 +1784,9 @@ static int __devinit davinci_emac_probe(struct
platform_device *pdev)
struct emac_platform_data *pdata;
struct device *emac_dev;
struct cpdma_params dma_params;
+ struct clk *emac_clk;
+ unsigned long emac_bus_frequency;
+
/* obtain emac clock from kernel */
emac_clk = clk_get(pdev-dev, NULL);
@@ -1788,12 +1795,14 @@ static int __devinit davinci_emac_probe(struct
platform_device *pdev)
return -EBUSY;
}
emac_bus_frequency = clk_get_rate(emac_clk);
+ clk_put(emac_clk);
+
/* TODO: Probe PHY here if possible */
ndev = alloc_etherdev(sizeof(struct emac_priv));
if (!ndev) {
rc = -ENOMEM;
- goto free_clk;
+ goto no_ndev;
}
platform_set_drvdata(pdev, ndev);
@@ -1909,15 +1918,13 @@ static int __devinit davinci_emac_probe(struct
platform_device *pdev)
SET_ETHTOOL_OPS(ndev, ethtool_ops);
netif_napi_add(ndev, priv-napi, emac_poll, EMAC_POLL_WEIGHT);
- clk_enable(emac_clk);
-
/* register the network device */
SET_NETDEV_DEV(ndev, pdev-dev);
rc = register_netdev(ndev);
if (rc) {
dev_err(pdev-dev, error in register_netdev\n);
rc = -ENODEV;
- goto netdev_reg_err;
+ goto no_irq_res;
}
@@ -1926,10 +1933,12 @@ static int __devinit davinci_emac_probe(struct
platform_device *pdev)
(regs: %p, irq: %d)\n,
(void *)priv-emac_base_phys, ndev-irq);
}
+
+ pm_runtime_enable(pdev-dev);
+ pm_runtime_resume(pdev-dev);
+
return 0;
-netdev_reg_err:
- clk_disable(emac_clk);
no_irq_res:
if (priv-txchan)
cpdma_chan_destroy(priv-txchan);
@@ -1943,8 +1952,7 @@ no_dma:
probe_quit:
free_netdev(ndev);
-free_clk:
- clk_put(emac_clk);
+no_ndev:
return rc;
}
@@ -1978,9 +1986,6 @@ static int __devexit davinci_emac_remove(struct
platform_device *pdev)
iounmap(priv-remap_addr);
free_netdev(ndev);
- clk_disable(emac_clk);
- clk_put(emac_clk);
-
return 0;
}
@@ -1992,8 +1997,6 @@ static int davinci_emac_suspend(struct device *dev)
if (netif_running(ndev))
Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue
On Thu, Jul 19, 2012 at 01:20:14PM +0300, Felipe Balbi wrote: Hi, On Thu, Jun 21, 2012 at 07:12:12PM +0530, Keshava Munegowda wrote: This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) is causing the usb hub and device detection fails in beagle XM causeing NFS not functional. This affects the core retention too. The same commit logic needs to be revisted adhering to hwmod and device tree framework. for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) reverted. This patch is validated on BeagleXM with NFS support over usb ethernet and USB mass storage and other device detection. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Acked-by: Felipe Balbi ba...@ti.com turns out this is causing other issues and another version of the patch will be provided. Greg, Alan, this is basically a git revert of the commit id listed above. Ok, I'll queue it up for 3.6-rc1 and add a -stable mark to it to get into 3.5.1, ok? thanks, greg k-h -- 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: USB : Fix the EHCI enumeration and core retention issue
On Thu, Jul 19, 2012 at 03:54:05PM -0700, Greg KH wrote: On Thu, Jul 19, 2012 at 01:20:14PM +0300, Felipe Balbi wrote: Hi, On Thu, Jun 21, 2012 at 07:12:12PM +0530, Keshava Munegowda wrote: This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) is causing the usb hub and device detection fails in beagle XM causeing NFS not functional. This affects the core retention too. The same commit logic needs to be revisted adhering to hwmod and device tree framework. for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) reverted. This patch is validated on BeagleXM with NFS support over usb ethernet and USB mass storage and other device detection. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Acked-by: Felipe Balbi ba...@ti.com turns out this is causing other issues and another version of the patch will be provided. Greg, Alan, this is basically a git revert of the commit id listed above. Ok, I'll queue it up for 3.6-rc1 and add a -stable mark to it to get into 3.5.1, ok? Hm, that doesn't work as it doesn't apply to my tree :( Can someone please update this against usb-next and send it to me? Felipe? thanks, greg k-h -- 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 2/2] arm: omap3: am35x: Disable hlt when using Davinci EMAC
+ Ilya
Hi Mark
Maybe try something like this on top of the patch that disables the
MPU DPLL autoidle?
I don't know what am35xx_enable_emac_int() is supposed to do. It seems
strange to clear the interrupt status bits when one is supposed to enable
the interrupts. Maybe Ilya can shed some light on it.
- Paul
---
arch/arm/mach-omap2/am35xx-emac.c | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/am35xx-emac.c
b/arch/arm/mach-omap2/am35xx-emac.c
index 2c90ac6..231190e 100644
--- a/arch/arm/mach-omap2/am35xx-emac.c
+++ b/arch/arm/mach-omap2/am35xx-emac.c
@@ -23,23 +23,17 @@
#include control.h
#include am35xx-emac.h
-static void am35xx_enable_emac_int(void)
-{
- u32 v;
-
- v = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
- v |= (AM35XX_CPGMAC_C0_RX_PULSE_CLR | AM35XX_CPGMAC_C0_TX_PULSE_CLR |
- AM35XX_CPGMAC_C0_MISC_PULSE_CLR | AM35XX_CPGMAC_C0_RX_THRESH_CLR);
- omap_ctrl_writel(v, AM35XX_CONTROL_LVL_INTR_CLEAR);
- omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR); /* OCP barrier */
-}
-
static void am35xx_disable_emac_int(void)
{
u32 v;
- v = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
- v |= (AM35XX_CPGMAC_C0_RX_PULSE_CLR | AM35XX_CPGMAC_C0_TX_PULSE_CLR);
+ /* XXX What about the misc interrupts? */
+ /*
+* XXX MDIO driver should handle its interrupts through the EMAC
+* driver
+*/
+ v = (AM35XX_CPGMAC_C0_RX_PULSE_CLR | AM35XX_CPGMAC_C0_TX_PULSE_CLR |
+AM35XX_CPGMAC_C0_MISC_PULSE_CLR | AM35XX_CPGMAC_C0_RX_THRESH_CLR);
omap_ctrl_writel(v, AM35XX_CONTROL_LVL_INTR_CLEAR);
omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR); /* OCP barrier */
}
@@ -51,7 +45,6 @@ static struct emac_platform_data am35xx_emac_pdata = {
.ctrl_ram_size = AM35XX_EMAC_CNTRL_RAM_SIZE,
.hw_ram_addr= AM35XX_EMAC_HW_RAM_ADDR,
.version= EMAC_VERSION_2,
- .interrupt_enable = am35xx_enable_emac_int,
.interrupt_disable = am35xx_disable_emac_int,
};
--
1.7.10.4
--
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
