Re: [PATCHv3 1/2] OMAP3: PM: Smartreflex IP update changes for OMAP3630
Thara Gopinath writes: > OMAP3430 uses the 65nm version of the smartreflex IP where as > OMAP3630 and OMAP4430 uses the 45nm updated IP. > > This patch adds support for the updated smartreflex IP used > in OMAP3630 and OMAP4 in the smartreflex driver. > > Major changes between the two versions of IP involve: > 1. Change in offset position for ERRCONFIG and SENERROR registers > 2. Change in bit positions for VP bound interrupt enable and status >in ERRCONFIG register. > 3. Change in bit positions and width of SENNENABLE and SENPENABLE >bits in SRCONFIG registers. > 4. Introduction of separate irq registers for MCU bound interrupts. > 5. Removal of clockactivity bits in ERRCONFIG and introduction of > idlemode and wakeupenable bits in ERRCONFIG. > > Signed-off-by: Thara Gopinath Looks good. One minor comment for discussion below... [...] > @@ -619,6 +717,7 @@ static int __devinit omap_smartreflex_probe(struct > platform_device *pdev) > sr_info->srid = pdev->id; > sr_info->is_autocomp_active = 0; > sr_info->clk_length = 0; > + sr_info->sr_ip_type = odev->hwmods[0]->class->rev; I'm not crazy about drivers having to know the details of hwmod structs. I'd suggest a HWMOD API for getting this revision. Other ideas? Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP:GPIO:hwmod: Fix mmc compile errors
Charulatha V writes: > In origin/pm-wip/runtime branch, compilation errors are > observed for OMAP2430. The compilation errors are due to > usage of clkdev_dev_id, clkdev_con_id and sysconfig fields > in mmc hwmod structures. This patch fixes the same. > > Signed-off-by: Charulatha V Thanks, folded into MMC hwmods patch in pm-wip/hwmods branch. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/5] omap3: pm: Use generic TRITON power scripts for 3430SDP board
Lesly A M writes: > This patch will removed the sleep/wakeup/warm_rest sequence from the > 3430SDP board file and use the generic script. > > Modified the resource config structure in the board file for using > generic script. Updating the sleep/wakeup/warm_rest sequence & voltsetup_time > in the board file from generic script file. Unless I missed something, a quick look at the resource configs for SDP and Zoom[23] and they look identical to me. That suggest to me something that should probably also live in twl4030.c as a default resource config. Otherwise, we'll be copying that between all the board files too. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 2/5] omap3: pm: Using separate clk/volt setup_time for RET and OFF states
Lesly A M writes:
> This patch will use separate clk/volt setup_time for RET and OFF state,
> also create separate copies of vc parameters for each Si in voltage.c.
>
> Re-programing the setup time according to the target state of CORE power
> domain.
> The voltsetup2 is used only when the device exits sys_off mode
> (with PRM_VOLTCTRL[3]SEL_OFF set to 1).
This needs more detail. First, you're moving the voltsetup2 programming
into common code and then also adding dynamic programming of clksetup
and volsetup1.
> Changed vdd0_/vdd1_ to vdd1_/vdd2_ in prcm vc setuptime structure.
Typically, these 3 unrelated changes would be done in 3 separate
patches for easier review. Especially this last one which is just a
rename. Mixing rename/cleanup changes with functional changes makes
things very difficult to sort out.
Otherwise, getting much better. Thanks. A few minor comments
below...
> Signed-off-by: Lesly A M
> Cc: Nishanth Menon
> Cc: David Derrick
> Cc: Samuel Ortiz
> ---
> arch/arm/mach-omap2/board-3430sdp.c | 21 +
> arch/arm/mach-omap2/board-3630sdp.c |4 +-
> arch/arm/mach-omap2/board-zoom2.c |4 +-
> arch/arm/mach-omap2/board-zoom3.c |4 +-
> arch/arm/mach-omap2/pm.h| 18
> arch/arm/mach-omap2/pm34xx.c| 26 +-
> arch/arm/mach-omap2/voltage.c | 157 ++
> arch/arm/mach-omap2/voltage.h | 31 +++
> 8 files changed, 165 insertions(+), 100 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-3430sdp.c
> b/arch/arm/mach-omap2/board-3430sdp.c
> index e80f8d4..9cc8569 100644
> --- a/arch/arm/mach-omap2/board-3430sdp.c
> +++ b/arch/arm/mach-omap2/board-3430sdp.c
> @@ -48,7 +48,6 @@
> #include "mux.h"
> #include "sdram-qimonda-hyb18m512160af-6.h"
> #include "hsmmc.h"
> -#include "pm.h"
> #include "voltage.h"
> #include "omap3-opp.h"
> #include "smartreflex-class3.h"
> @@ -79,23 +78,6 @@ static struct cpuidle_params omap3_cpuidle_params_table[]
> = {
> {1, 1, 3, 30},
> };
>
> -/* FIXME: These are not the optimal setup values to be used on 3430sdp*/
> -static struct prm_setup_vc omap3_setuptime_table = {
> - .clksetup = 0xff,
> - .voltsetup_time1 = 0xfff,
> - .voltsetup_time2 = 0xfff,
> - .voltoffset = 0xff,
> - .voltsetup2 = 0xff,
> - .vdd0_on = 0x30,
> - .vdd0_onlp = 0x20,
> - .vdd0_ret = 0x1e,
> - .vdd0_off = 0x00,
> - .vdd1_on = 0x2c,
> - .vdd1_onlp = 0x20,
> - .vdd1_ret = 0x1e,
> - .vdd1_off = 0x00,
> -};
> -
> static int board_keymap[] = {
> KEY(0, 0, KEY_LEFT),
> KEY(0, 1, KEY_RIGHT),
> @@ -348,7 +330,6 @@ static void __init omap_3430sdp_init_irq(void)
> omap_board_config_size = ARRAY_SIZE(sdp3430_config);
> omap3_pm_init_opp_table();
> omap3_pm_init_cpuidle(omap3_cpuidle_params_table);
> - omap_voltage_init_vc(&omap3_setuptime_table);
> omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL);
> omap_init_irq();
> omap_gpio_init();
> @@ -897,6 +878,8 @@ static struct omap_musb_board_data musb_board_data = {
>
> static void __init omap_3430sdp_init(void)
> {
> + omap_voltage_init_vc(NULL);
> +
> omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
> omap3430_i2c_init();
> platform_add_devices(sdp3430_devices, ARRAY_SIZE(sdp3430_devices));
> diff --git a/arch/arm/mach-omap2/board-3630sdp.c
> b/arch/arm/mach-omap2/board-3630sdp.c
> index 2fc1d0b..19ecd67 100644
> --- a/arch/arm/mach-omap2/board-3630sdp.c
> +++ b/arch/arm/mach-omap2/board-3630sdp.c
> @@ -25,8 +25,8 @@
>
> #include "mux.h"
> #include "sdram-hynix-h8mbx00u0mer-0em.h"
> -#include "pm.h"
> #include "omap3-opp.h"
> +#include "voltage.h"
>
> #if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91X_MODULE)
>
> @@ -101,6 +101,8 @@ static struct omap_board_mux board_mux[] __initdata = {
>
> static void __init omap_sdp_init(void)
> {
> + omap_voltage_init_vc(NULL);
If a board isn't going to override, it shouldn't have to call the
function. A default VC init should handle the default init for all
boards that don't need to override. Otherwise, we'll have t add this
call to all board files.
[...]
> @@ -496,18 +488,6 @@ void omap_sram_idle(void)
> }
> omap_uart_resume_idle(0);
> omap_uart_resume_idle(1);
> - if (core_next_state == PWRDM_POWER_OFF) {
> - u32 voltctrl = OMAP3430_AUTO_OFF;
> -
> - if (voltage_off_while_idle)
> - voltctrl |= OMAP3430_SEL_OFF;
> - prm_clear_mod_reg_bits(voltctrl,
> -OMAP3430_GR_MOD,
> -OMAP3_PRM_VOLTCTRL_OFFSET);
> - } else if (core_next_state == PWRDM_POWER_RET)
> - prm_clear_mod_reg_bits(OMAP3430_AUTO_RET,
> - OMAP3430_GR_MOD,
> -
Re: [PATCH] OMAP3: PM: Fix compilation error observed when cpufreq is disabled
Ranjith Lohithakshan writes: > Currently on PM branch, compilation fails when cpufreq is disabled > > arch/arm/mach-omap2/clock3xxx_data.c: In function 'omap3xxx_clk_init': > arch/arm/mach-omap2/clock3xxx_data.c:3563: error: 'struct clk_functions' > has no member named 'clk_init_cpufreq_table' > arch/arm/mach-omap2/clock3xxx_data.c:3564: error: > 'omap3_clk_init_cpufreq_table' undeclared (first use > in this function) > arch/arm/mach-omap2/clock3xxx_data.c:3564: error: (Each undeclared > identifier is reported only once > arch/arm/mach-omap2/clock3xxx_data.c:3564: error: for each function it > appears in.) > make[1]: *** [arch/arm/mach-omap2/clock3xxx_data.o] Error 1 > make: *** [arch/arm/mach-omap2] Error 2 > > This patch fixes the issue by avoiding runtime init of > clk_init_cpufreq_table in omap3xxx_clk_init and instead doing it when > omap2_clk_functions are defined. > > Signed-off-by: Ranjith Lohithakshan Do you still have this problem? I'm unable to reproduce on current PM branch. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] DSPBRIDGE: use dm timer framework for gpt timers
Nishanth Menon writes: > Kevin Hilman had written, on 04/28/2010 12:59 PM, the following: >> Omar Ramirez Luna writes: >> >>> On 4/28/2010 11:36 AM, Menon, Nishanth wrote: Kevin Hilman had written, on 04/28/2010 11:29 AM, the following: > Omar Ramirez Luna writes: > >> On 4/28/2010 2:46 AM, Felipe Contreras wrote: >>> On Wed, Apr 28, 2010 at 4:29 AM, Omar Ramirez Luna >>> wrote: This patch switches to use DM timer framework instead of a custom one for GPT timers, currently dsp can make use of gpt 5, 6, 7 or 8. >>> I heard someone that was using gpt 8 for something else. Is it >>> possible to configure dsp-bridge to not use it? >>> >> There are two scenarios: >> >> 1. The request comes from the DSP side (afaik for video use case), the >> change should be in the DSP side binaries to request some other gpt >> instead. I don't know how possible is to get this changed. >> >> 2. bridge driver also requests gpt8 whenever a mmu fault is triggered, >> this to set a timer to interrupt the dsp after the mmu fault dump has >> been finished, I think this can be easily replaced in bridge to use >> some other gpt, but "1" is still there. (besides a new patch is needed >> to remove direct access to dm timer inside ue_deh and make it to go >> through dsp-clock) > Why does Bridge care at all which specific timers it requests? They > are all the same, with the exception of GPT1 which is in the WKUP > powerdomain and already used as the kernel clocksource. > > Bridge should just use the generic _request() instead of > _request_specific() > trouble I believe is that DSP BIOS uses a specific timer. >>> yes, dsp side wants: >>> bios --> GPT5 (only used during boot up -> baseimage load) >>> load monitoring --> GPT 6 (used while the dsp is awake) >>> AV Sync --> GPT 8 (based on use case) >>> >>> to generate the interrupt for mmu fault case it needs one connected to >>> the dsp interrupt line and only 5, 6, 7 or 8 apply. >> >> Then DSP bios is broken by hard-coding *general purpose* timers. > /me just eats my own words. > Not really.. I just got educated internally that DSP does not get > interrupts from all GPTs. > Ref: http://focus.ti.com/pdfs/wtbu/SWPU114Q_PrelimFinal_EPDF_03_05_2009.pdf > page 1753 -> only mentioned these timers can generate interrupts for > DSP, and hence for BIOS's usage. OK, now that part makes sense. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] DSPBRIDGE: use dm timer framework for gpt timers
Vladimir Pantelic had written, on 04/28/2010 02:52 PM, the following: Nishanth Menon wrote: [...] trouble I believe is that DSP BIOS uses a specific timer. yes, dsp side wants: bios --> GPT5 (only used during boot up -> baseimage load) load monitoring --> GPT 6 (used while the dsp is awake) AV Sync --> GPT 8 (based on use case) to generate the interrupt for mmu fault case it needs one connected to the dsp interrupt line and only 5, 6, 7 or 8 apply. Then DSP bios is broken by hard-coding *general purpose* timers. /me just eats my own words. Not really.. I just got educated internally that DSP does not get interrupts from all GPTs. Ref: http://focus.ti.com/pdfs/wtbu/SWPU114Q_PrelimFinal_EPDF_03_05_2009.pdf page 1753 -> only mentioned these timers can generate interrupts for DSP, and hence for BIOS's usage. Added to this, the fact that GPT PWM is usable on 9,10,11 as well, makes me believe this is something to consider as part of board design based on which peripherals one uses and their constraints. BIOS is not at fault here to use the resources it requires, but is part of system design to look at options, constraints and select the ones appropriately.. A similar example is mux pins, you have options to plug to one of many options, but if you plug in both a interrupt and a data line to the same pin which could run in two different modes, there is a problem there right? Alright, that is too obvious i suppose Yes, just that pin mux issues are pretty obvious reading the TRM and DM, but the fact that bridge blocks GPT5,6 and 8 is not. You are telling me that using all 4 GPTs for PWM or input event capture is not possible when using dspbridge? As I understand, bridge mostly uses 2 of the GPTs (6 for load monitoring, 8 for sync/mmu fault), so I think moving GPT8 to 7 should make both sides happy, no? Seriously, is this debate going to close even then? case a) some other guy is gonna use GPT7 then we are all screwed again case b) the DSPBIOS guys need more GPT to do something else later on (I dont know what.. but just guessing), again screwed? case c) *what if* some bloke is already using GPT7 for some reason of his own and he already has a board working, is'nt he screwed if we switch to GPT7 now? -- 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 v2] DSPBRIDGE: use dm timer framework for gpt timers
Nishanth Menon wrote: > Kevin Hilman had written, on 04/28/2010 12:59 PM, the following: >> Omar Ramirez Luna writes: >> >>> On 4/28/2010 11:36 AM, Menon, Nishanth wrote: Kevin Hilman had written, on 04/28/2010 11:29 AM, the following: > Omar Ramirez Luna writes: > >> On 4/28/2010 2:46 AM, Felipe Contreras wrote: >>> On Wed, Apr 28, 2010 at 4:29 AM, Omar Ramirez >>> Luna wrote: This patch switches to use DM timer framework instead of a custom one for GPT timers, currently dsp can make use of gpt 5, 6, 7 or 8. >>> I heard someone that was using gpt 8 for something else. Is it >>> possible to configure dsp-bridge to not use it? >>> >> There are two scenarios: >> >> 1. The request comes from the DSP side (afaik for video use case), >> the >> change should be in the DSP side binaries to request some other gpt >> instead. I don't know how possible is to get this changed. >> >> 2. bridge driver also requests gpt8 whenever a mmu fault is >> triggered, >> this to set a timer to interrupt the dsp after the mmu fault dump has >> been finished, I think this can be easily replaced in bridge to use >> some other gpt, but "1" is still there. (besides a new patch is >> needed >> to remove direct access to dm timer inside ue_deh and make it to go >> through dsp-clock) > Why does Bridge care at all which specific timers it requests? They > are all the same, with the exception of GPT1 which is in the WKUP > powerdomain and already used as the kernel clocksource. > > Bridge should just use the generic _request() instead of > _request_specific() > trouble I believe is that DSP BIOS uses a specific timer. >>> yes, dsp side wants: >>> bios --> GPT5 (only used during boot up -> baseimage load) >>> load monitoring --> GPT 6 (used while the dsp is awake) >>> AV Sync --> GPT 8 (based on use case) >>> >>> to generate the interrupt for mmu fault case it needs one connected to >>> the dsp interrupt line and only 5, 6, 7 or 8 apply. >> >> Then DSP bios is broken by hard-coding *general purpose* timers. > /me just eats my own words. > Not really.. I just got educated internally that DSP does not get > interrupts from all GPTs. > Ref: http://focus.ti.com/pdfs/wtbu/SWPU114Q_PrelimFinal_EPDF_03_05_2009.pdf > page 1753 -> only mentioned these timers can generate interrupts for > DSP, and hence for BIOS's usage. Added to this, the fact that GPT PWM is > usable on 9,10,11 as well, makes me believe this is something to > consider as part of board design based on which peripherals one uses and > their constraints. BIOS is not at fault here to use the resources it > requires, but is part of system design to look at options, constraints > and select the ones appropriately.. > > A similar example is mux pins, you have options to plug to one of many > options, but if you plug in both a interrupt and a data line to the same > pin which could run in two different modes, there is a problem there > right? Alright, that is too obvious i suppose Yes, just that pin mux issues are pretty obvious reading the TRM and DM, but the fact that bridge blocks GPT5,6 and 8 is not. You are telling me that using all 4 GPTs for PWM or input event capture is not possible when using dspbridge? As I understand, bridge mostly uses 2 of the GPTs (6 for load monitoring, 8 for sync/mmu fault), so I think moving GPT8 to 7 should make both sides happy, no? Regards, Vladimir -- 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] Disable the non working eMMC on Zoom2/3
* Madhusudhan [100428 12:30]: > > > > -Original Message- > > From: Tony Lindgren [mailto:t...@atomide.com] > > Sent: Wednesday, April 28, 2010 2:23 PM > > To: Madhusudhan > > Cc: 'Nishanth Menon'; 'Ghorai, Sukumar'; linux-omap@vger.kernel.org; > > linux-...@vger.kernel.org > > Subject: Re: [PATCH] Disable the non working eMMC on Zoom2/3 > > > > * Tony Lindgren [100427 11:16]: > > > * Madhusudhan [100408 10:07]: > > > > > > > > > > > > Tony, do you care to just look up the serial number of your board? > > > > > > > > > > Sorry for the delay in replying, I've been travelling for a few > > weeks > > > > > and been in meetings quite a bit. Anyways, it's a 1013037 REV A > > board, > > > > > which seems to be production in the table above. > > > > > > > > > > > > > That means we can not assume all production units have a working eMMC. > > > > Would you mind sharing your bootup log? When this device is detected > > > > something like below is a clear issue. > > > > > > > > mmcblk1: mmc1:0001 STM16G 1.00 GiB > > > > mmcblk1: p1 p2 > > > > For the eMMC I seem to have that: > > > > [0.978363] mmc1: new high speed MMC card at address 0001 > > [0.984344] mmcblk1: mmc1:0001 STM16G 1.00 GiB > > [0.989105] mmcblk1: unknown partition table > > ... > > > > zoom:~# fdisk -l /dev/mmcblk1 > > [ 120.306396] mmcblk1: retrying using single block read > > [ 120.503692] mmcblk1: retrying using single block read > > [ 120.683593] mmcblk1: error -110 transferring data, sector 2097144, nr > > 8, card status 0x900 > > [ 120.691894] end_request: I/O error, dev mmcblk1, sector 2097144 > > [ 120.872680] mmcblk1: error -110 transferring data, sector 2097145, nr > > 7, card status 0x900 > > ... > > > > > Hmm, finally got around looking into this again. Looks like the mmc > > > is now working on my zoom3 with the current Linus' tree at commit > > > 7c6bd2010fced38444c9fd658f4c6ce61bd185bf. So I guess something that > > > we had in omap-fixes fixed this. Or maybe some fix for drivers/mmc? > > > > > > This is with the debug_ll patch applied: > > > > > > https://patchwork.kernel.org/patch/87532/ > > > > For the microSD card, turns out the card I used was flakey. So > > that should explain some of the problems. I'm almost certain > > I tried with two different cards earlier though. In any case, > > let's assume the problem is only the eMMC. > > > Sorry, I did not get a complete picture. Your earlier email said that with > Linus tree eMMC on your Zoom3 is working. Is that correct? Nope, now the microSD is working, eMMC is not working. > IMHO, an omap level fix can not solve the problem with eMMC because as I can > see from the log you provided above that a 16G device is detected as 1G. > This is certainly due to the issue I mentioned earlier. OK 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] Disable the non working eMMC on Zoom2/3
> -Original Message- > From: Tony Lindgren [mailto:t...@atomide.com] > Sent: Wednesday, April 28, 2010 2:23 PM > To: Madhusudhan > Cc: 'Nishanth Menon'; 'Ghorai, Sukumar'; linux-omap@vger.kernel.org; > linux-...@vger.kernel.org > Subject: Re: [PATCH] Disable the non working eMMC on Zoom2/3 > > * Tony Lindgren [100427 11:16]: > > * Madhusudhan [100408 10:07]: > > > > > > > > > > Tony, do you care to just look up the serial number of your board? > > > > > > > > Sorry for the delay in replying, I've been travelling for a few > weeks > > > > and been in meetings quite a bit. Anyways, it's a 1013037 REV A > board, > > > > which seems to be production in the table above. > > > > > > > > > > That means we can not assume all production units have a working eMMC. > > > Would you mind sharing your bootup log? When this device is detected > > > something like below is a clear issue. > > > > > > mmcblk1: mmc1:0001 STM16G 1.00 GiB > > > mmcblk1: p1 p2 > > For the eMMC I seem to have that: > > [0.978363] mmc1: new high speed MMC card at address 0001 > [0.984344] mmcblk1: mmc1:0001 STM16G 1.00 GiB > [0.989105] mmcblk1: unknown partition table > ... > > zoom:~# fdisk -l /dev/mmcblk1 > [ 120.306396] mmcblk1: retrying using single block read > [ 120.503692] mmcblk1: retrying using single block read > [ 120.683593] mmcblk1: error -110 transferring data, sector 2097144, nr > 8, card status 0x900 > [ 120.691894] end_request: I/O error, dev mmcblk1, sector 2097144 > [ 120.872680] mmcblk1: error -110 transferring data, sector 2097145, nr > 7, card status 0x900 > ... > > > Hmm, finally got around looking into this again. Looks like the mmc > > is now working on my zoom3 with the current Linus' tree at commit > > 7c6bd2010fced38444c9fd658f4c6ce61bd185bf. So I guess something that > > we had in omap-fixes fixed this. Or maybe some fix for drivers/mmc? > > > > This is with the debug_ll patch applied: > > > > https://patchwork.kernel.org/patch/87532/ > > For the microSD card, turns out the card I used was flakey. So > that should explain some of the problems. I'm almost certain > I tried with two different cards earlier though. In any case, > let's assume the problem is only the eMMC. > Sorry, I did not get a complete picture. Your earlier email said that with Linus tree eMMC on your Zoom3 is working. Is that correct? IMHO, an omap level fix can not solve the problem with eMMC because as I can see from the log you provided above that a 16G device is detected as 1G. This is certainly due to the issue I mentioned earlier. Regards, Madhu > 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] Disable the non working eMMC on Zoom2/3
* Tony Lindgren [100427 11:16]: > * Madhusudhan [100408 10:07]: > > > > > > > > Tony, do you care to just look up the serial number of your board? > > > > > > Sorry for the delay in replying, I've been travelling for a few weeks > > > and been in meetings quite a bit. Anyways, it's a 1013037 REV A board, > > > which seems to be production in the table above. > > > > > > > That means we can not assume all production units have a working eMMC. > > Would you mind sharing your bootup log? When this device is detected > > something like below is a clear issue. > > > > mmcblk1: mmc1:0001 STM16G 1.00 GiB > > mmcblk1: p1 p2 For the eMMC I seem to have that: [0.978363] mmc1: new high speed MMC card at address 0001 [0.984344] mmcblk1: mmc1:0001 STM16G 1.00 GiB [0.989105] mmcblk1: unknown partition table ... zoom:~# fdisk -l /dev/mmcblk1 [ 120.306396] mmcblk1: retrying using single block read [ 120.503692] mmcblk1: retrying using single block read [ 120.683593] mmcblk1: error -110 transferring data, sector 2097144, nr 8, card status 0x900 [ 120.691894] end_request: I/O error, dev mmcblk1, sector 2097144 [ 120.872680] mmcblk1: error -110 transferring data, sector 2097145, nr 7, card status 0x900 ... > Hmm, finally got around looking into this again. Looks like the mmc > is now working on my zoom3 with the current Linus' tree at commit > 7c6bd2010fced38444c9fd658f4c6ce61bd185bf. So I guess something that > we had in omap-fixes fixed this. Or maybe some fix for drivers/mmc? > > This is with the debug_ll patch applied: > > https://patchwork.kernel.org/patch/87532/ For the microSD card, turns out the card I used was flakey. So that should explain some of the problems. I'm almost certain I tried with two different cards earlier though. In any case, let's assume the problem is only the eMMC. 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 v2] DSPBRIDGE: use dm timer framework for gpt timers
Kevin Hilman had written, on 04/28/2010 12:59 PM, the following: Omar Ramirez Luna writes: On 4/28/2010 11:36 AM, Menon, Nishanth wrote: Kevin Hilman had written, on 04/28/2010 11:29 AM, the following: Omar Ramirez Luna writes: On 4/28/2010 2:46 AM, Felipe Contreras wrote: On Wed, Apr 28, 2010 at 4:29 AM, Omar Ramirez Luna wrote: This patch switches to use DM timer framework instead of a custom one for GPT timers, currently dsp can make use of gpt 5, 6, 7 or 8. I heard someone that was using gpt 8 for something else. Is it possible to configure dsp-bridge to not use it? There are two scenarios: 1. The request comes from the DSP side (afaik for video use case), the change should be in the DSP side binaries to request some other gpt instead. I don't know how possible is to get this changed. 2. bridge driver also requests gpt8 whenever a mmu fault is triggered, this to set a timer to interrupt the dsp after the mmu fault dump has been finished, I think this can be easily replaced in bridge to use some other gpt, but "1" is still there. (besides a new patch is needed to remove direct access to dm timer inside ue_deh and make it to go through dsp-clock) Why does Bridge care at all which specific timers it requests? They are all the same, with the exception of GPT1 which is in the WKUP powerdomain and already used as the kernel clocksource. Bridge should just use the generic _request() instead of _request_specific() trouble I believe is that DSP BIOS uses a specific timer. yes, dsp side wants: bios --> GPT5 (only used during boot up -> baseimage load) load monitoring --> GPT 6 (used while the dsp is awake) AV Sync --> GPT 8 (based on use case) to generate the interrupt for mmu fault case it needs one connected to the dsp interrupt line and only 5, 6, 7 or 8 apply. Then DSP bios is broken by hard-coding *general purpose* timers. /me just eats my own words. Not really.. I just got educated internally that DSP does not get interrupts from all GPTs. Ref: http://focus.ti.com/pdfs/wtbu/SWPU114Q_PrelimFinal_EPDF_03_05_2009.pdf page 1753 -> only mentioned these timers can generate interrupts for DSP, and hence for BIOS's usage. Added to this, the fact that GPT PWM is usable on 9,10,11 as well, makes me believe this is something to consider as part of board design based on which peripherals one uses and their constraints. BIOS is not at fault here to use the resources it requires, but is part of system design to look at options, constraints and select the ones appropriately.. A similar example is mux pins, you have options to plug to one of many options, but if you plug in both a interrupt and a data line to the same pin which could run in two different modes, there is a problem there right? Alright, that is too obvious i suppose -- 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 v2] OMAP3: PM: Add milliseconds interface to suspend wakeup timer
Phil Carmody writes: > On 23/03/10 08:04 +0100, Kauppi Ari (EXT-Ixonos/Oulu) wrote: >> Millisecond resolution is possible and there are use cases for it >> (automatic testing). >> >> Seconds-based interface is preserved for compatibility. >> >> Signed-off-by: Ari Kauppi >> >> --- >> v2: Keep seconds and milliseconds interfaces strictly separate: >> - Consistent interface, setting/getting seconds and milliseconds >>is always accurate >> - Fixes potential overflow issues in omap2_pm_wakeup_on_timer >> - Cleaner patch > > Nice one. Just what we need, nothing more, nothing less. > > Reviewed-by: Phil Carmody > Thanks, tested on omap3evm. Pulling into PM branch queueing for 2.6.35. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ARM suspend to disk?
Hey there, I last posted a few weeks ago; I'm Peter Tseng, using the Gumstix Overo for a project. I'm interested in power management and a few related things. A few of the things I am interested in are suspend to disk and snapshot boot. I found a page on elinux.org with a few notes on the issue for ARM. However, it looks to be a bit outdated: http://elinux.org/Suspend_To_Disk_For_ARM I am wondering how applicable anything on this page is to the current omap-pm developments. Or, if not, any pointers on how it might be done - for example, if I felt like I should do some hacking to try to get this working and contribute these back, a general outline of what I might have to do) Thanks for your time, Peter Tseng -- 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: Unable to build for omap3_evm_defconfig using latest kernel-omap3 git
OK, thanks - I thought that the 'integration' kernel for OMAP3 would be my best choice, based on the statement "TI integration tree is in general the most up-to-date version of the kernel for a TI platform since all necessary sub systems have been pre-integrated." from the OMAPedia wiki at http://omappedia.org/wiki/Linux_Kernel_Int_Trees. Rick -Original Message- From: Gadiyar, Anand [mailto:gadi...@ti.com] Sent: Wednesday, April 28, 2010 10:53 AM To: Rick Ball; linux-omap@vger.kernel.org Subject: RE: Unable to build for omap3_evm_defconfig using latest kernel-omap3 git Rick Ball wrote: > I get the following error when attempting to build a kernel for the > default config of the OMAP3 EVM board with the latest 'git' from: > > git://dev.omapzoom.org/pub/scm/integration/kernel-omap3.git > ... > > Am I doing something wrong here? Am I mistaken in thinking that > compiling for this board should work? Yes, you're using the wrong kernel. Use the linux-omap kernel: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git Or Linus' tree directly: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git The one you're using is an internal development tree on which the OMAP3 EVM board is not well supported. - Anand -- 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] OMAP3EVM: Update pad configuration for wakeup enabled pads
Ranjith Lohithakshan writes:
> Kevin,
>
> On Tue, 27-Apr-10 8:46 PM +0530, Kevin Hilman wrote:
>> Ranjith Lohithakshan writes:
>>
>>> OMAP3530 TRM section 7.4.4.4.2 requires OFFOUTENABLE to be set (active low)
>>> if wakeup capabilities are enabled on a pad. During OFF mode testing
>>> on OMAP3530 EVM, it was observed that the device was not residing in
>>> the OFF state. The device enters into the OFF state and immediately exits
>>> from that state as if an IO wakeup event has occured. The issue was traced
>>> down to the pad configuration of wkaeup enabled pad's.
>>
>> Nice.
>>
>>> Also, the pad configuration is included only if the respective drivers are
>>> enabled in the defconfig.
>>
>> Hmm, do you really want this? If you don't have the driver enabled,
>> you have to rely on the bootloader settings of these pads which may
>> also be wrong and trigger an IO wakeup as well.
>
> The thought process was that, for example, if keypad is not enabled
> in a system configuration you probably don't want to see a wakeup
> occurring if someone presses a key stroke. I understand the concern
> that you have raised regarding bootloader mis-configurations. My
> impression was that the bootloaders typically set the mux modes and
> pull up's/downs and dont really program or enable the wakeup
> capability. But we cannot depend on that thumb rule.
Unfortunately, Bootloaders don't "typically" do anything. They are
routinely hacked/patched and cannot be trusted at all.
> What is your recommendation?
First, I suggest you fix the OFFOUTENABLE bug in a single patch
without introducing the #ifdefs. Then, address the enable/disable of
the wakeups in a separate patch.
Next, ideally wakeups should not be configured a this level of board
code. There are APIs for that: enable_irq_wake()/disable_irq_wake()
For GPIOs (like the touchscreen), you really need to enable wakeups
using existing APIs, either in the driver or in board init code and be
sure there is an interrupt handler. Please see the 'Known Problems'
section of the OMAP PM wiki[2] where it talks about GPIO wakeups.
Below[2] is an test patch I've used.
For MPU IRQs, the IRQ wake APIs don't quite work as expected. You
can look at board-3430sdp.c to see how wakeups are enabled there.
If you want to make that conditional on the T2 driver being installed,
it could be part of the T2 init process.
Kevin
[1] http://elinux.org/OMAP_Power_Management#Known_Problems
[2]
commit a12a1b43c75795fa106d1222730591354209c037
Author: Kevin Hilman
Date: Wed Sep 9 11:58:20 2009 -0700
OMAP3: PM: Enable touchscreen GPIO wakeups on SDP and omap3evm
For the GPIO wakeup to work, the GPIO IRQ must be configured as a
wakeup IRQ.
In addition, a corresponding interrupt handler must be used and enabled
so that after coming out of idle/suspend the interrupt will be cleared.
Otherwise, a pending GPIO IRQ will prevent future idle request. (c.f.
GPIO 'Interrupt and Wakeup' section of the TRM, specifically the
subsection 'Involved Configuration Registers'.)
Signed-off-by: Kevin Hilman
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index c1742d0..96f921e 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -24,6 +24,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -140,6 +142,11 @@ static struct twl4030_keypad_data sdp3430_kp_data = {
static int ts_gpio;/* Needed for ads7846_get_pendown_state */
+static irqreturn_t dummy_interrupt_handler (int irq, void *dev_id)
+{
+ return IRQ_HANDLED;
+}
+
/**
* @brief ads7846_dev_init : Requests & sets GPIO line for pen-irq
*
@@ -147,6 +154,8 @@ static int ts_gpio; /* Needed for ads7846_get_pendown_state
*/
*/
static void ads7846_dev_init(void)
{
+ int ret;
+
if (gpio_request(ts_gpio, "ADS7846 pendown") < 0) {
printk(KERN_ERR "can't get ads746 pen down GPIO\n");
return;
@@ -156,6 +165,12 @@ static void ads7846_dev_init(void)
omap_set_gpio_debounce(ts_gpio, 1);
omap_set_gpio_debounce_time(ts_gpio, 0xa);
+
+ ret = request_irq(gpio_to_irq(ts_gpio),
+ (irq_handler_t)dummy_interrupt_handler,
+ IRQF_TRIGGER_FALLING,
+ "ads7846-dummy", NULL);
+ enable_irq_wake(gpio_to_irq(ts_gpio));
}
static int ads7846_get_pendown_state(void)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 9ac1eb2..1647440 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -574,8 +574,15 @@ static int __init omap3_evm_i2c_init(void)
return 0;
}
+static irqreturn_t dummy_interrupt_handler (int irq, void *dev_id)
+{
+ return IRQ_HANDLED;
+}
+
static void ads7846_dev_init(void)
{
+ int ret;
+
if (gpio_request(OMAP3_EVM_T
Re: [PATCH v2] DSPBRIDGE: use dm timer framework for gpt timers
Omar Ramirez Luna writes: > On 4/28/2010 11:36 AM, Menon, Nishanth wrote: >> Kevin Hilman had written, on 04/28/2010 11:29 AM, the following: >>> Omar Ramirez Luna writes: >>> On 4/28/2010 2:46 AM, Felipe Contreras wrote: > On Wed, Apr 28, 2010 at 4:29 AM, Omar Ramirez Luna > wrote: >> This patch switches to use DM timer framework instead of >> a custom one for GPT timers, currently dsp can make use of >> gpt 5, 6, 7 or 8. > I heard someone that was using gpt 8 for something else. Is it > possible to configure dsp-bridge to not use it? > There are two scenarios: 1. The request comes from the DSP side (afaik for video use case), the change should be in the DSP side binaries to request some other gpt instead. I don't know how possible is to get this changed. 2. bridge driver also requests gpt8 whenever a mmu fault is triggered, this to set a timer to interrupt the dsp after the mmu fault dump has been finished, I think this can be easily replaced in bridge to use some other gpt, but "1" is still there. (besides a new patch is needed to remove direct access to dm timer inside ue_deh and make it to go through dsp-clock) >>> >>> Why does Bridge care at all which specific timers it requests? They >>> are all the same, with the exception of GPT1 which is in the WKUP >>> powerdomain and already used as the kernel clocksource. >>> >>> Bridge should just use the generic _request() instead of >>> _request_specific() >>> >> trouble I believe is that DSP BIOS uses a specific timer. >> > > yes, dsp side wants: > bios --> GPT5 (only used during boot up -> baseimage load) > load monitoring --> GPT 6 (used while the dsp is awake) > AV Sync --> GPT 8 (based on use case) > > to generate the interrupt for mmu fault case it needs one connected to > the dsp interrupt line and only 5, 6, 7 or 8 apply. Then DSP bios is broken by hard-coding *general purpose* timers. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] DSPBRIDGE: use dm timer framework for gpt timers
Vladimir Pantelic had written, on 04/28/2010 12:11 PM, the following: Omar Ramirez Luna wrote: yes, dsp side wants: bios --> GPT5 (only used during boot up -> baseimage load) load monitoring --> GPT 6 (used while the dsp is awake) AV Sync --> GPT 8 (based on use case) to generate the interrupt for mmu fault case it needs one connected to the dsp interrupt line and only 5, 6, 7 or 8 apply. and it is also GPT8 for mmu fault handling atm. So, as GPT8 is one of the PWM capable, could that functionality be moved to GPT7? Obvious good point instead to tell DSP BIOS which timers to use as part of the params we pass to the DSP similar to what we do with frequencies for DSP Load balancer to work.. makes it scalable and does not allow DSP to hog a timer which could be used for LCD backlight dimming with PWM for example.. -- 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 v2] DSPBRIDGE: use dm timer framework for gpt timers
Omar Ramirez Luna wrote: yes, dsp side wants: bios --> GPT5 (only used during boot up -> baseimage load) load monitoring --> GPT 6 (used while the dsp is awake) AV Sync --> GPT 8 (based on use case) to generate the interrupt for mmu fault case it needs one connected to the dsp interrupt line and only 5, 6, 7 or 8 apply. and it is also GPT8 for mmu fault handling atm. So, as GPT8 is one of the PWM capable, could that functionality be moved to GPT7? -- 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 v2] DSPBRIDGE: use dm timer framework for gpt timers
On Wed, Apr 28, 2010 at 7:36 PM, Nishanth Menon wrote: > Kevin Hilman had written, on 04/28/2010 11:29 AM, the following: >> >> Omar Ramirez Luna writes: >> >>> On 4/28/2010 2:46 AM, Felipe Contreras wrote: On Wed, Apr 28, 2010 at 4:29 AM, Omar Ramirez Luna wrote: > > This patch switches to use DM timer framework instead of > a custom one for GPT timers, currently dsp can make use of > gpt 5, 6, 7 or 8. I heard someone that was using gpt 8 for something else. Is it possible to configure dsp-bridge to not use it? >>> There are two scenarios: >>> >>> 1. The request comes from the DSP side (afaik for video use case), the >>> change should be in the DSP side binaries to request some other gpt >>> instead. I don't know how possible is to get this changed. >>> >>> 2. bridge driver also requests gpt8 whenever a mmu fault is triggered, >>> this to set a timer to interrupt the dsp after the mmu fault dump has >>> been finished, I think this can be easily replaced in bridge to use >>> some other gpt, but "1" is still there. (besides a new patch is needed >>> to remove direct access to dm timer inside ue_deh and make it to go >>> through dsp-clock) >> >> Why does Bridge care at all which specific timers it requests? They >> are all the same, with the exception of GPT1 which is in the WKUP >> powerdomain and already used as the kernel clocksource. >> >> Bridge should just use the generic _request() instead of >> _request_specific() >> > trouble I believe is that DSP BIOS uses a specific timer. FTR, this is the conversation... I don't understand what PWM is, hopefully somebody else does: felipec: ping av500: pong dspbridge uses GPT8 which is one of the PWM capable ones which is not so nice as my hw guy uses that PWM otoh, only GPT5-8 can deliver IRQ to DSP so I see code that handles 5-8, but somehow only GPT6 and GPT8 seem to be really used av500: you are wondering if it could use GPT7 or something? yup GPT8 is unfortunately in the DSP and the PWM set DSP 5-8, PWM 8-11 av500: I've no idea =/ felipec: ok, and who could? that's for the mailing list I guess l-o? yup k, thx orbarron maybe orbarron: ^^^ Cheers. -- Felipe Contreras -- 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 v2] DSPBRIDGE: use dm timer framework for gpt timers
Hi, > -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Menon, Nishanth > Sent: Wednesday, April 28, 2010 11:36 AM > To: Kevin Hilman > Cc: Ramirez Luna, Omar; Felipe Contreras; linux-omap; Ameya Palande; > Hiroshi Doyu; Felipe Contreras; Omar Ramirez Luna > Subject: Re: [PATCH v2] DSPBRIDGE: use dm timer framework for gpt timers > > Kevin Hilman had written, on 04/28/2010 11:29 AM, the following: > > Omar Ramirez Luna writes: > > > >> On 4/28/2010 2:46 AM, Felipe Contreras wrote: > >>> On Wed, Apr 28, 2010 at 4:29 AM, Omar Ramirez > Luna wrote: > This patch switches to use DM timer framework instead of > a custom one for GPT timers, currently dsp can make use of > gpt 5, 6, 7 or 8. > >>> I heard someone that was using gpt 8 for something else. Is it > >>> possible to configure dsp-bridge to not use it? > >>> > >> There are two scenarios: > >> > >> 1. The request comes from the DSP side (afaik for video use case), the > >> change should be in the DSP side binaries to request some other gpt > >> instead. I don't know how possible is to get this changed. > >> > >> 2. bridge driver also requests gpt8 whenever a mmu fault is triggered, > >> this to set a timer to interrupt the dsp after the mmu fault dump has > >> been finished, I think this can be easily replaced in bridge to use > >> some other gpt, but "1" is still there. (besides a new patch is needed > >> to remove direct access to dm timer inside ue_deh and make it to go > >> through dsp-clock) > > > > Why does Bridge care at all which specific timers it requests? They > > are all the same, with the exception of GPT1 which is in the WKUP > > powerdomain and already used as the kernel clocksource. > > > > Bridge should just use the generic _request() instead of > > _request_specific() > > > trouble I believe is that DSP BIOS uses a specific timer. DSP/BIOS uses GPT5 on bridge boot up, after that the GPT5 is released. The GPT6 is used in DSP Bridge for DSP CPU Load Monitoring. Regards, Armando. -- 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 v2] DSPBRIDGE: use dm timer framework for gpt timers
On 4/28/2010 11:36 AM, Menon, Nishanth wrote: Kevin Hilman had written, on 04/28/2010 11:29 AM, the following: Omar Ramirez Luna writes: On 4/28/2010 2:46 AM, Felipe Contreras wrote: On Wed, Apr 28, 2010 at 4:29 AM, Omar Ramirez Luna wrote: This patch switches to use DM timer framework instead of a custom one for GPT timers, currently dsp can make use of gpt 5, 6, 7 or 8. I heard someone that was using gpt 8 for something else. Is it possible to configure dsp-bridge to not use it? There are two scenarios: 1. The request comes from the DSP side (afaik for video use case), the change should be in the DSP side binaries to request some other gpt instead. I don't know how possible is to get this changed. 2. bridge driver also requests gpt8 whenever a mmu fault is triggered, this to set a timer to interrupt the dsp after the mmu fault dump has been finished, I think this can be easily replaced in bridge to use some other gpt, but "1" is still there. (besides a new patch is needed to remove direct access to dm timer inside ue_deh and make it to go through dsp-clock) Why does Bridge care at all which specific timers it requests? They are all the same, with the exception of GPT1 which is in the WKUP powerdomain and already used as the kernel clocksource. Bridge should just use the generic _request() instead of _request_specific() trouble I believe is that DSP BIOS uses a specific timer. yes, dsp side wants: bios --> GPT5 (only used during boot up -> baseimage load) load monitoring --> GPT 6 (used while the dsp is awake) AV Sync --> GPT 8 (based on use case) to generate the interrupt for mmu fault case it needs one connected to the dsp interrupt line and only 5, 6, 7 or 8 apply. Regards, Omar -- 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 v2] DSPBRIDGE: use dm timer framework for gpt timers
Kevin Hilman had written, on 04/28/2010 11:29 AM, the following: Omar Ramirez Luna writes: On 4/28/2010 2:46 AM, Felipe Contreras wrote: On Wed, Apr 28, 2010 at 4:29 AM, Omar Ramirez Luna wrote: This patch switches to use DM timer framework instead of a custom one for GPT timers, currently dsp can make use of gpt 5, 6, 7 or 8. I heard someone that was using gpt 8 for something else. Is it possible to configure dsp-bridge to not use it? There are two scenarios: 1. The request comes from the DSP side (afaik for video use case), the change should be in the DSP side binaries to request some other gpt instead. I don't know how possible is to get this changed. 2. bridge driver also requests gpt8 whenever a mmu fault is triggered, this to set a timer to interrupt the dsp after the mmu fault dump has been finished, I think this can be easily replaced in bridge to use some other gpt, but "1" is still there. (besides a new patch is needed to remove direct access to dm timer inside ue_deh and make it to go through dsp-clock) Why does Bridge care at all which specific timers it requests? They are all the same, with the exception of GPT1 which is in the WKUP powerdomain and already used as the kernel clocksource. Bridge should just use the generic _request() instead of _request_specific() trouble I believe is that DSP BIOS uses a specific timer. -- 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 v2] DSPBRIDGE: use dm timer framework for gpt timers
Omar Ramirez Luna writes: > On 4/28/2010 2:46 AM, Felipe Contreras wrote: >> On Wed, Apr 28, 2010 at 4:29 AM, Omar Ramirez Luna >> wrote: >>> This patch switches to use DM timer framework instead of >>> a custom one for GPT timers, currently dsp can make use of >>> gpt 5, 6, 7 or 8. >> >> I heard someone that was using gpt 8 for something else. Is it >> possible to configure dsp-bridge to not use it? >> > > There are two scenarios: > > 1. The request comes from the DSP side (afaik for video use case), the > change should be in the DSP side binaries to request some other gpt > instead. I don't know how possible is to get this changed. > > 2. bridge driver also requests gpt8 whenever a mmu fault is triggered, > this to set a timer to interrupt the dsp after the mmu fault dump has > been finished, I think this can be easily replaced in bridge to use > some other gpt, but "1" is still there. (besides a new patch is needed > to remove direct access to dm timer inside ue_deh and make it to go > through dsp-clock) Why does Bridge care at all which specific timers it requests? They are all the same, with the exception of GPT1 which is in the WKUP powerdomain and already used as the kernel clocksource. Bridge should just use the generic _request() instead of _request_specific() Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] omap: gpmc-nand: add ability to keep timings defined by the bootloader
Signed-off-by: Mike Rapoport
---
arch/arm/mach-omap2/gpmc-nand.c| 19 ++-
arch/arm/plat-omap/include/plat/nand.h |1 +
2 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index e57fb29..7c6c027 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -22,6 +22,7 @@
#define WR_RD_PIN_MONITORING 0x0060
static struct omap_nand_platform_data *gpmc_nand_data;
+static struct gpmc_timings gpmc_default_timings;
static struct resource gpmc_nand_resource = {
.flags = IORESOURCE_MEM,
@@ -34,13 +35,24 @@ static struct platform_device gpmc_nand_device = {
.resource = &gpmc_nand_resource,
};
+static void gpmc_nand_detect_timings(void)
+{
+ struct gpmc_timings t;
+
+ memset(&t, 0, sizeof(t));
+ gpmc_cs_get_timings(gpmc_nand_data->cs, &gpmc_default_timings);
+}
+
static int omap2_nand_gpmc_retime(void)
{
+ struct device *dev = &gpmc_nand_device.dev;
struct gpmc_timings t;
int err;
- if (!gpmc_nand_data->gpmc_t)
+ if (!gpmc_nand_data->gpmc_t) {
+ dev_warn(dev, "No timings provided, skipping retime\n");
return 0;
+ }
memset(&t, 0, sizeof(t));
t.sync_clk = gpmc_round_ns_to_ticks(gpmc_nand_data->gpmc_t->sync_clk);
@@ -112,6 +124,11 @@ int __init gpmc_nand_init(struct omap_nand_platform_data
*_nand_data)
return err;
}
+ if (gpmc_nand_data->keep_timings) {
+ gpmc_nand_detect_timings();
+ gpmc_nand_data->gpmc_t = &gpmc_default_timings;
+ }
+
err = gpmc_nand_setup();
if (err < 0) {
dev_err(dev, "NAND platform setup failed: %d\n", err);
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index f8efd54..0f727ea 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -24,6 +24,7 @@ struct omap_nand_platform_data {
void __iomem*gpmc_cs_baseaddr;
void __iomem*gpmc_baseaddr;
int devsize;
+ boolkeep_timings;
};
/* size (4 KiB) for IO mapping */
--
1.6.6.2
--
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 1/2] omap: gpmc: add gpmc_cs_get_timings
Add gpmc_cs_get_timings counterpart of gpmc_cs_set_timings and
convinience macros to read particular timing configuration fields
Signed-off-by: Mike Rapoport
---
arch/arm/mach-omap2/gpmc.c | 79
arch/arm/plat-omap/include/plat/gpmc.h |1 +
2 files changed, 80 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 5bc3ca0..416336f 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -163,6 +163,36 @@ unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns)
}
#ifdef DEBUG
+static int get_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit,
+ const char *name)
+#else
+static int get_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit)
+#endif
+{
+ u32 l;
+ int ticks, mask, nr_bits, time;
+
+ nr_bits = end_bit - st_bit + 1;
+ mask = ((1 << nr_bits) - 1);
+
+ l = gpmc_cs_read_reg(cs, reg);
+ ticks = (l >> st_bit) & mask;
+
+ if (ticks == 0)
+ time = 0;
+ else
+ time = gpmc_ticks_to_ns(ticks);
+
+#ifdef DEBUG
+ printk(KERN_INFO
+ "GPMC CS%d: %-10s: %3d ticks, %3d ns\n",
+ cs, name, ticks, time);
+#endif
+
+ return time;
+}
+
+#ifdef DEBUG
static int set_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit,
int time, const char *name)
#else
@@ -206,10 +236,14 @@ static int set_gpmc_timing_reg(int cs, int reg, int
st_bit, int end_bit,
if (set_gpmc_timing_reg(cs, (reg), (st), (end), \
t->field, #field) < 0) \
return -1
+#define GPMC_GET_ONE(reg, st, end, field) \
+ t->field = get_gpmc_timing_reg(cs, (reg), (st), (end), #field)
#else
#define GPMC_SET_ONE(reg, st, end, field) \
if (set_gpmc_timing_reg(cs, (reg), (st), (end), t->field) < 0) \
return -1
+#define GPMC_GET_ONE(reg, st, end, field) \
+ t->field = get_gpmc_timing_reg(cs, (reg), (st), (end))
#endif
int gpmc_cs_calc_divider(int cs, unsigned int sync_clk)
@@ -227,6 +261,51 @@ int gpmc_cs_calc_divider(int cs, unsigned int sync_clk)
return div;
}
+void gpmc_cs_get_timings(int cs, struct gpmc_timings *t)
+{
+ int div;
+ u32 l;
+
+ GPMC_GET_ONE(GPMC_CS_CONFIG2, 0, 3, cs_on);
+ GPMC_GET_ONE(GPMC_CS_CONFIG2, 8, 12, cs_rd_off);
+ GPMC_GET_ONE(GPMC_CS_CONFIG2, 16, 20, cs_wr_off);
+
+ GPMC_GET_ONE(GPMC_CS_CONFIG3, 0, 3, adv_on);
+ GPMC_GET_ONE(GPMC_CS_CONFIG3, 8, 12, adv_rd_off);
+ GPMC_GET_ONE(GPMC_CS_CONFIG3, 16, 20, adv_wr_off);
+
+ GPMC_GET_ONE(GPMC_CS_CONFIG4, 0, 3, oe_on);
+ GPMC_GET_ONE(GPMC_CS_CONFIG4, 8, 12, oe_off);
+ GPMC_GET_ONE(GPMC_CS_CONFIG4, 16, 19, we_on);
+ GPMC_GET_ONE(GPMC_CS_CONFIG4, 24, 28, we_off);
+
+ GPMC_GET_ONE(GPMC_CS_CONFIG5, 0, 4, rd_cycle);
+ GPMC_GET_ONE(GPMC_CS_CONFIG5, 8, 12, wr_cycle);
+ GPMC_GET_ONE(GPMC_CS_CONFIG5, 16, 20, access);
+
+ GPMC_GET_ONE(GPMC_CS_CONFIG5, 24, 27, page_burst_access);
+
+ if (cpu_is_omap34xx()) {
+ GPMC_GET_ONE(GPMC_CS_CONFIG6, 16, 19, wr_data_mux_bus);
+ GPMC_GET_ONE(GPMC_CS_CONFIG6, 24, 28, wr_access);
+ }
+
+ l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+ if (l & (GPMC_CONFIG1_READTYPE_SYNC | GPMC_CONFIG1_WRITETYPE_SYNC)) {
+ div = (l & 0x03) + 1;
+#ifdef DEBUG
+ printk(KERN_INFO "GPMC CS%d CLK period is %lu ns (div %d)\n",
+ cs, (div * gpmc_get_fclk_period()) / 1000, div);
+#endif
+ t->sync_clk = (div * gpmc_get_fclk_period()) / 1000;
+ } else {
+ t->sync_clk = 0;
+ }
+
+ gpmc_dump_regs(cs);
+ gpmc_dump_timings(t);
+}
+
int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t)
{
int div;
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 145838a..5c345f1 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -102,6 +102,7 @@ extern void gpmc_cs_write_reg(int cs, int idx, u32 val);
extern u32 gpmc_cs_read_reg(int cs, int idx);
extern int gpmc_cs_calc_divider(int cs, unsigned int sync_clk);
extern int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t);
+extern void gpmc_cs_get_timings(int cs, struct gpmc_timings *t);
extern int gpmc_cs_request(int cs, unsigned long size, unsigned long *base);
extern void gpmc_cs_free(int cs);
extern int gpmc_cs_set_reserved(int cs, int reserved);
--
1.6.6.2
--
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 0/2] omap: gpmc-nand: add ability to keep timings defined by the bootloader
These patches add ability to keep GPMC timings configured by the bootloader. The platforms have to either define NAND GPMC timinings explicitly via gpmc_t field of omap_nand_platform_data or set keep_timings flag to allow detection of current timing configuration and its subsequent use in omap2_nand_gpmc_retime. The following changes since commit 104a77440f05430f29f9d3f4ecb88c1536819585: Tony Lindgren (1): Linux-omap rebuilt: Merged in i2c-omap-for-ben branch and cleaned up cbus branch Mike Rapoport (2): omap: gpmc: add gpmc_cs_get_timings omap: gpmc-nand: add ability to keep timings defined by the bootloader arch/arm/mach-omap2/gpmc-nand.c| 19 +++- arch/arm/mach-omap2/gpmc.c | 79 arch/arm/plat-omap/include/plat/gpmc.h |1 + arch/arm/plat-omap/include/plat/nand.h |1 + 4 files changed, 99 insertions(+), 1 deletions(-) -- 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: Unable to build for omap3_evm_defconfig using latest kernel-omap3 git
Rick Ball wrote: > I get the following error when attempting to build a kernel > for the default config of the OMAP3 EVM board with the latest > 'git' from: > > git://dev.omapzoom.org/pub/scm/integration/kernel-omap3.git > ... > > Am I doing something wrong here? Am I mistaken in thinking > that compiling for this board should work? Yes, you're using the wrong kernel. Use the linux-omap kernel: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git Or Linus' tree directly: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git The one you're using is an internal development tree on which the OMAP3 EVM board is not well supported. - Anand -- 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: Bug in omap2_nand_gpmc_retime?
Vimal Singh wrote: On Wed, Apr 28, 2010 at 8:35 PM, Mike Rapoport wrote: While working on implementation of gpmc_nand_detect_timings I've seen that omap2_nand_gpmc_retime converts the timings supplied by the platform to ticks and passes it to gpmc_cs_set_timings which in turn converts the timings to ticks. Is it a bug or am I missing something? No, 'omap2_nand_gpmc_retime' does not convert timings supplied by the platform to tick. Rather it rounds the timings passed by the platform to timings in units of 'tick' period. Thanks for the clarification. I still wonder why is this necessary. Anyway gpmc_set_cs_timings will do the conversion? -- Sincerely yours, Mike. -- 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
Unable to build for omap3_evm_defconfig using latest kernel-omap3 git
I get the following error when attempting to build a kernel for the default config of the OMAP3 EVM board with the latest 'git' from: git://dev.omapzoom.org/pub/scm/integration/kernel-omap3.git I'm compiling with CodeSourcery 2009q3, using the 'arm-none-linux-gnueabi-' cross-compile prefix, arch=arm: LD .tmp_vmlinux1 arch/arm/mach-omap2/built-in.o: In function `omap_reset_voltage': arch/arm/mach-omap2/voltage.c:699: undefined reference to `get_vdd1_opp' arch/arm/mach-omap2/voltage.c:711: undefined reference to `get_vdd2_opp' arch/arm/mach-omap2/built-in.o: In function `vp_forceupdate_scale_voltage': arch/arm/mach-omap2/voltage.c:391: undefined reference to `get_vdd1_opp' arch/arm/mach-omap2/voltage.c:402: undefined reference to `get_vdd2_opp' arch/arm/mach-omap2/built-in.o: In function `vp_reg_offs_configure': arch/arm/mach-omap2/voltage.c:296: undefined reference to `get_vdd1_opp' arch/arm/mach-omap2/built-in.o: In function `vp_latch_vsel': arch/arm/mach-omap2/voltage.c:203: undefined reference to `get_vdd1_opp' make[1]: *** [.tmp_vmlinux1] Error 1 make: *** [sub-make] Error 2 Earlier, I got the following warnings while compiling 'voltage.c': CC arch/arm/mach-omap2/voltage.o arch/arm/mach-omap2/voltage.c: In function 'vp_latch_vsel': arch/arm/mach-omap2/voltage.c:220: warning: passing argument 1 of 'opp_find_by_opp_id' makes pointer from integer without a cast arch/arm/plat-omap/include/plat/opp.h:293: note: expected 'struct omap_opp *' but argument is of type 'int' arch/arm/mach-omap2/voltage.c: In function 'omap_reset_voltage': arch/arm/mach-omap2/voltage.c:716: warning: passing argument 1 of 'opp_find_by_opp_id' makes pointer from integer without a cast arch/arm/plat-omap/include/plat/opp.h:293: note: expected 'struct omap_opp *' but argument is of type 'int' It looks like the Makefile for the mach-omap2 folder doesn't include the file that defines 'get_vdd1_opp' (resource34xx.c), since CONFIG_OMAP_PM_SRF isn't set by the config. But if I modify the config so it will also compile this file, it just opens a different can of worms. Am I doing something wrong here? Am I mistaken in thinking that compiling for this board should work? Thanks, Rick Ball (rb...@aesaustin.com) -- 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: Bug in omap2_nand_gpmc_retime? (was: Re: [PATCH] OMAP: fix gpmc nand setup when no timings supplied)
On Wed, Apr 28, 2010 at 8:35 PM, Mike Rapoport wrote: > Tony Lindgren wrote: >> >> * Mike Rapoport [100427 00:40]: >>> >>> Tony Lindgren wrote: * Mike Rapoport [100422 01:41]: > > Ghorai, Sukumar wrote: > > CM-T35, for instance can be assembled with different NAND flash > chips. Besides, boards that use NAND as primary boot device, we > anyway depend on proper GPMC configuration in the bootloader chain. > Having ability to define GPMC timings in the kernel and keep the > settings made by the bootloader adds flexibility level for board > designers. Not implementing the retime function for GPMC will cause issues with PM as you cannot scale the L3 frequency without breaking your GPMC timings. >>> >>> I agree that without retime function scaling the frequency will >>> break the GPMC timings. But my point was that there should be an >>> _option_ to keep the timings defined by the bootloader rather than >>> enforce board files to specify timings. >> >> Sure. Can you please check one more time your patch and what is >> still missing after Stanley's fix? That's now in omap-fixes and master >> branches as commit 11e1ef2d105900a302b7ca92bcaf96a96d0274a1. >> >>> Since skipping the retime function will break gpmc timings in >>> PM-enabled kernel, we need to implement this option in smarter way. >>> E.g. something like: >> >> Yeah we should print some warning if the retime function is not >> implemented as it can cause mysterious bugs later on. I guess >> implementing a dummy retime function would be best as then the >> warning would be related to the actual L3 rate change. > > While working on implementation of gpmc_nand_detect_timings I've seen that > omap2_nand_gpmc_retime converts the timings supplied by the platform to > ticks and passes it to gpmc_cs_set_timings which in turn converts the > timings to ticks. Is it a bug or am I missing something? No, 'omap2_nand_gpmc_retime' does not convert timings supplied by the platform to tick. Rather it rounds the timings passed by the platform to timings in units of 'tick' period. -- Regards, Vimal Singh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 00/19] DSPBRIDGE: generic clk module removal
This set of patches remove clk module from the services layer. Now: - GPT 5-8 are controlled through DM Timer framework. - MCBSP clocks are enabled by requesting the proper mcbsp device. - WDT is left for bridge driver to control rather than on request from dsp. - SSI is controlled by enabling/disabling its sst, ssr and ick clocks. v2: - rebased - keep iva2 handling as it is advised to turn off the clocks for iva reset sources. - release all the clocks (disable & free) if driver is uninstalled. Omar Ramirez Luna (19): DSPBRIDGE: remove clk_handle from drv interface DSPBRIDGE: fail if clk handle is NULL DSPBRIDGE: Now actually fail if a clk handle is wrong DSPBRIDGE: Rename services_clk_* to dsp_clk_* DSPBRIDGE: remove unused clock sys_ck DSPBRIDGE: remove function clk_set32k_hz DSPBRIDGE: remove clk_get_use_cnt DSPBRIDGE: trivial clock cleanup for unused code DSPBRIDGE: function to get the type of clock requested by dsp DSPBRIDGE: iva2 clock handling DSPBRIDGE: use dm timer framework for gpt timers DSPBRIDGE: use omap mcbsp to enable mcbsp clocks DSPBRIDGE: remove wdt3 from dsp control DSPBRIDGE: dsp interface to enable ssi clocks DSPBRIDGE: use one call for both ick and fck clocks DSPBRIDGE: Move MCBSP_CLOCKS code to a common place DSPBRIDGE: Balance the number of enable/disable DSPBRIDGE: move clk to dsp-clock DSPBRIDGE: reorganize the code to handle peripheral clocks arch/arm/plat-omap/include/dspbridge/clk.h | 103 ++-- drivers/dsp/bridge/Makefile|4 +- drivers/dsp/bridge/rmgr/drv_interface.c| 12 +- drivers/dsp/bridge/services/clk.c | 323 drivers/dsp/bridge/services/services.c | 10 +- drivers/dsp/bridge/wmd/_tiomap.h | 25 +- drivers/dsp/bridge/wmd/_tiomap_pwr.h | 17 -- drivers/dsp/bridge/wmd/dsp-clock.c | 377 drivers/dsp/bridge/wmd/tiomap3430.c| 62 +- drivers/dsp/bridge/wmd/tiomap3430_pwr.c| 147 +-- drivers/dsp/bridge/wmd/tiomap_io.c |4 +- drivers/dsp/bridge/wmd/ue_deh.c|2 +- 12 files changed, 440 insertions(+), 646 deletions(-) delete mode 100644 drivers/dsp/bridge/services/clk.c create mode 100644 drivers/dsp/bridge/wmd/dsp-clock.c -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 03/19] DSPBRIDGE: Now actually fail if a clk handle is wrong
The value returned by clk_get on error is not NULL.
This checks if the value returned is an error or not.
Signed-off-by: Omar Ramirez Luna
---
drivers/dsp/bridge/services/clk.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/dsp/bridge/services/clk.c
b/drivers/dsp/bridge/services/clk.c
index 1089e72..b9fb9ef 100644
--- a/drivers/dsp/bridge/services/clk.c
+++ b/drivers/dsp/bridge/services/clk.c
@@ -126,7 +126,7 @@ bool services_clk_init(void)
clk_handle = clk_get(&dspbridge_device.dev,
services_clks[i].clk_name);
- if (!clk_handle) {
+ if (IS_ERR(clk_handle)) {
pr_err("%s: failed to get clk handle %s, dev id = %d\n",
__func__, services_clks[i].clk_name,
services_clks[i].id);
--
1.6.2.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 v2 04/19] DSPBRIDGE: Rename services_clk_* to dsp_clk_*
Rename services_clk_* to dsp_clk_*
Signed-off-by: Omar Ramirez Luna
---
arch/arm/plat-omap/include/dspbridge/clk.h | 78
drivers/dsp/bridge/services/clk.c | 88 ++--
drivers/dsp/bridge/services/services.c |6 +-
drivers/dsp/bridge/wmd/_tiomap.h | 26
drivers/dsp/bridge/wmd/tiomap3430.c| 10 ++--
drivers/dsp/bridge/wmd/tiomap3430_pwr.c| 16 +++---
6 files changed, 112 insertions(+), 112 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/clk.h
b/arch/arm/plat-omap/include/dspbridge/clk.h
index c36b634..a547225 100644
--- a/arch/arm/plat-omap/include/dspbridge/clk.h
+++ b/arch/arm/plat-omap/include/dspbridge/clk.h
@@ -21,37 +21,37 @@
/* Generic TIMER object: */
struct timer_object;
-enum services_clk_id {
- SERVICESCLK_IVA2_CK = 0,
- SERVICESCLK_GPT5_FCK,
- SERVICESCLK_GPT5_ICK,
- SERVICESCLK_GPT6_FCK,
- SERVICESCLK_GPT6_ICK,
- SERVICESCLK_GPT7_FCK,
- SERVICESCLK_GPT7_ICK,
- SERVICESCLK_GPT8_FCK,
- SERVICESCLK_GPT8_ICK,
- SERVICESCLK_WDT3_FCK,
- SERVICESCLK_WDT3_ICK,
- SERVICESCLK_MCBSP1_FCK,
- SERVICESCLK_MCBSP1_ICK,
- SERVICESCLK_MCBSP2_FCK,
- SERVICESCLK_MCBSP2_ICK,
- SERVICESCLK_MCBSP3_FCK,
- SERVICESCLK_MCBSP3_ICK,
- SERVICESCLK_MCBSP4_FCK,
- SERVICESCLK_MCBSP4_ICK,
- SERVICESCLK_MCBSP5_FCK,
- SERVICESCLK_MCBSP5_ICK,
- SERVICESCLK_SSI_FCK,
- SERVICESCLK_SSI_ICK,
- SERVICESCLK_SYS32K_CK,
- SERVICESCLK_SYS_CK,
- SERVICESCLK_NOT_DEFINED
+enum dsp_clk_id {
+ DSP_CLK_IVA2_CK = 0,
+ DSP_CLK_GPT5_FCK,
+ DSP_CLK_GPT5_ICK,
+ DSP_CLK_GPT6_FCK,
+ DSP_CLK_GPT6_ICK,
+ DSP_CLK_GPT7_FCK,
+ DSP_CLK_GPT7_ICK,
+ DSP_CLK_GPT8_FCK,
+ DSP_CLK_GPT8_ICK,
+ DSP_CLK_WDT3_FCK,
+ DSP_CLK_WDT3_ICK,
+ DSP_CLK_MCBSP1_FCK,
+ DSP_CLK_MCBSP1_ICK,
+ DSP_CLK_MCBSP2_FCK,
+ DSP_CLK_MCBSP2_ICK,
+ DSP_CLK_MCBSP3_FCK,
+ DSP_CLK_MCBSP3_ICK,
+ DSP_CLK_MCBSP4_FCK,
+ DSP_CLK_MCBSP4_ICK,
+ DSP_CLK_MCBSP5_FCK,
+ DSP_CLK_MCBSP5_ICK,
+ DSP_CLK_SSI_FCK,
+ DSP_CLK_SSI_ICK,
+ DSP_CLK_SYS32K_CK,
+ DSP_CLK_SYS_CK,
+ DSP_CLK_NOT_DEFINED
};
/*
- * clk_exit
+ * dsp_clk_exit
* Purpose:
* Discontinue usage of module; free resources when reference count
* reaches 0.
@@ -62,10 +62,10 @@ enum services_clk_id {
* Ensures:
* Resources used by module are freed when cRef reaches zero.
*/
-extern void clk_exit(void);
+extern void dsp_clk_exit(void);
/*
- * services_clk_init
+ * dsp_clk_init
* Purpose:
* Initializes private state of CLK module.
* Parameters:
@@ -75,10 +75,10 @@ extern void clk_exit(void);
* Ensures:
* CLK initialized.
*/
-extern bool services_clk_init(void);
+extern bool dsp_clk_init(void);
/*
- * services_clk_enable
+ * dsp_clk_enable
* Purpose:
* Enables the clock requested.
* Parameters:
@@ -88,10 +88,10 @@ extern bool services_clk_init(void);
* Requires:
* Ensures:
*/
-extern dsp_status services_clk_enable(IN enum services_clk_id clk_id);
+extern dsp_status dsp_clk_enable(IN enum dsp_clk_id clk_id);
/*
- * services_clk_disable
+ * dsp_clk_disable
* Purpose:
* Disables the clock requested.
* Parameters:
@@ -101,10 +101,10 @@ extern dsp_status services_clk_enable(IN enum
services_clk_id clk_id);
* Requires:
* Ensures:
*/
-extern dsp_status services_clk_disable(IN enum services_clk_id clk_id);
+extern dsp_status dsp_clk_disable(IN enum dsp_clk_id clk_id);
/*
- * services_clk_get_rate
+ * dsp_clk_get_rate
* Purpose:
* Get the clock rate of requested clock.
* Parameters:
@@ -114,7 +114,7 @@ extern dsp_status services_clk_disable(IN enum
services_clk_id clk_id);
* Requires:
* Ensures:
*/
-extern dsp_status services_clk_get_rate(IN enum services_clk_id clk_id,
+extern dsp_status dsp_clk_get_rate(IN enum dsp_clk_id clk_id,
u32 *speedMhz);
/*
* clk_set32k_hz
@@ -127,7 +127,7 @@ extern dsp_status services_clk_get_rate(IN enum
services_clk_id clk_id,
* Requires:
* Ensures:
*/
-extern dsp_status clk_set32k_hz(IN enum services_clk_id clk_id);
+extern dsp_status clk_set32k_hz(IN enum dsp_clk_id clk_id);
extern void ssi_clk_prepare(bool FLAG);
/*
@@ -141,6 +141,6 @@ extern void ssi_clk_prepare(bool FLAG);
* Requires:
* Ensures:
*/
-extern s32 clk_get_use_cnt(IN enum services_clk_id clk_id);
+extern s32 clk_get_use_cnt(IN enum dsp_clk_id clk_id);
#endif /* _SYNC_H */
diff --git a/drivers/dsp/bridge/services/clk.c
b/drivers
[PATCH v2 15/19] DSPBRIDGE: use one call for both ick and fck clocks
Instead of two calls to enable/disable for ick and fck use
one call to enable/disable both.
Signed-off-by: Omar Ramirez Luna
---
arch/arm/plat-omap/include/dspbridge/clk.h | 35 +--
drivers/dsp/bridge/services/clk.c | 14 +-
drivers/dsp/bridge/wmd/_tiomap.h | 25 +--
drivers/dsp/bridge/wmd/tiomap3430.c|8 +++---
drivers/dsp/bridge/wmd/tiomap3430_pwr.c| 35
5 files changed, 45 insertions(+), 72 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/clk.h
b/arch/arm/plat-omap/include/dspbridge/clk.h
index 2602d9f..e6b09c7 100644
--- a/arch/arm/plat-omap/include/dspbridge/clk.h
+++ b/arch/arm/plat-omap/include/dspbridge/clk.h
@@ -20,29 +20,18 @@
#define _CLK_H
enum dsp_clk_id {
- DSP_CLK_IVA2_CK = 0,
- DSP_CLK_GPT5_FCK,
- DSP_CLK_GPT5_ICK,
- DSP_CLK_GPT6_FCK,
- DSP_CLK_GPT6_ICK,
- DSP_CLK_GPT7_FCK,
- DSP_CLK_GPT7_ICK,
- DSP_CLK_GPT8_FCK,
- DSP_CLK_GPT8_ICK,
- DSP_CLK_WDT3_FCK,
- DSP_CLK_WDT3_ICK,
- DSP_CLK_MCBSP1_FCK,
- DSP_CLK_MCBSP1_ICK,
- DSP_CLK_MCBSP2_FCK,
- DSP_CLK_MCBSP2_ICK,
- DSP_CLK_MCBSP3_FCK,
- DSP_CLK_MCBSP3_ICK,
- DSP_CLK_MCBSP4_FCK,
- DSP_CLK_MCBSP4_ICK,
- DSP_CLK_MCBSP5_FCK,
- DSP_CLK_MCBSP5_ICK,
- DSP_CLK_SSI_FCK,
- DSP_CLK_SSI_ICK,
+ DSP_CLK_IVA2 = 0,
+ DSP_CLK_GPT5,
+ DSP_CLK_GPT6,
+ DSP_CLK_GPT7,
+ DSP_CLK_GPT8,
+ DSP_CLK_WDT3,
+ DSP_CLK_MCBSP1,
+ DSP_CLK_MCBSP2,
+ DSP_CLK_MCBSP3,
+ DSP_CLK_MCBSP4,
+ DSP_CLK_MCBSP5,
+ DSP_CLK_SSI,
DSP_CLK_NOT_DEFINED
};
diff --git a/drivers/dsp/bridge/services/clk.c
b/drivers/dsp/bridge/services/clk.c
index c72f574..9a439c7 100644
--- a/drivers/dsp/bridge/services/clk.c
+++ b/drivers/dsp/bridge/services/clk.c
@@ -52,8 +52,8 @@
/* Bridge GPT id (1 - 4), DM Timer id (5 - 8) */
#define DMT_ID(id) ((id) + 4)
-/* Bridge MCBSP id (6 - 10), OMAP Mcbsp id (1 - 5) */
-#define MCBSP_ID(id) ((id) - 13)
+/* Bridge MCBSP id (6 - 10), OMAP Mcbsp id (0 - 4) */
+#define MCBSP_ID(id) ((id) - 6)
static struct omap_dm_timer *timer[4];
@@ -71,15 +71,15 @@ static s8 get_clk_type(u8 id)
{
s8 type;
- if (id == DSP_CLK_IVA2_CK)
+ if (id == DSP_CLK_IVA2)
type = IVA2_CLK;
- else if (id <= DSP_CLK_GPT8_ICK)
+ else if (id <= DSP_CLK_GPT8)
type = GPT_CLK;
- else if (id <= DSP_CLK_WDT3_ICK)
+ else if (id == DSP_CLK_WDT3)
type = WDT_CLK;
- else if (id <= DSP_CLK_MCBSP5_ICK)
+ else if (id <= DSP_CLK_MCBSP5)
type = MCBSP_CLK;
- else if (id < DSP_CLK_SSI_ICK)
+ else if (id == DSP_CLK_SSI)
type = SSI_CLK;
else
type = -1;
diff --git a/drivers/dsp/bridge/wmd/_tiomap.h b/drivers/dsp/bridge/wmd/_tiomap.h
index 887232b..56efb84 100644
--- a/drivers/dsp/bridge/wmd/_tiomap.h
+++ b/drivers/dsp/bridge/wmd/_tiomap.h
@@ -246,22 +246,21 @@ static const u32 bpwr_clkid[] = {
struct bpwr_clk_t {
u32 clk_id;
- enum dsp_clk_id fun_clk;
- enum dsp_clk_id int_clk;
+ enum dsp_clk_id clk;
};
static const struct bpwr_clk_t bpwr_clks[] = {
- {(u32) BPWR_GP_TIMER5, DSP_CLK_GPT5_FCK, DSP_CLK_GPT5_ICK},
- {(u32) BPWR_GP_TIMER6, DSP_CLK_GPT6_FCK, DSP_CLK_GPT6_ICK},
- {(u32) BPWR_GP_TIMER7, DSP_CLK_GPT7_FCK, DSP_CLK_GPT7_ICK},
- {(u32) BPWR_GP_TIMER8, DSP_CLK_GPT8_FCK, DSP_CLK_GPT8_ICK},
- {(u32) BPWR_WD_TIMER3, DSP_CLK_WDT3_FCK, DSP_CLK_WDT3_ICK},
- {(u32) BPWR_MCBSP1, DSP_CLK_MCBSP1_FCK, DSP_CLK_MCBSP1_ICK},
- {(u32) BPWR_MCBSP2, DSP_CLK_MCBSP2_FCK, DSP_CLK_MCBSP2_ICK},
- {(u32) BPWR_MCBSP3, DSP_CLK_MCBSP3_FCK, DSP_CLK_MCBSP3_ICK},
- {(u32) BPWR_MCBSP4, DSP_CLK_MCBSP4_FCK, DSP_CLK_MCBSP4_ICK},
- {(u32) BPWR_MCBSP5, DSP_CLK_MCBSP5_FCK, DSP_CLK_MCBSP5_ICK},
- {(u32) BPWR_SSI, DSP_CLK_SSI_FCK, DSP_CLK_SSI_ICK}
+ {(u32) BPWR_GP_TIMER5, DSP_CLK_GPT5},
+ {(u32) BPWR_GP_TIMER6, DSP_CLK_GPT6},
+ {(u32) BPWR_GP_TIMER7, DSP_CLK_GPT7},
+ {(u32) BPWR_GP_TIMER8, DSP_CLK_GPT8},
+ {(u32) BPWR_WD_TIMER3, DSP_CLK_WDT3},
+ {(u32) BPWR_MCBSP1, DSP_CLK_MCBSP1},
+ {(u32) BPWR_MCBSP2, DSP_CLK_MCBSP2},
+ {(u32) BPWR_MCBSP3, DSP_CLK_MCBSP3},
+ {(u32) BPWR_MCBSP4, DSP_CLK_MCBSP4},
+ {(u32) BPWR_MCBSP5, DSP_CLK_MCBSP5},
+ {(u32) BPWR_SSI, DSP_CLK_SSI}
};
/* Interrupt Register Offsets */
diff --git a/drivers/dsp/bridge/wmd/tiomap3430.c
b/drivers/dsp/bridge/wmd/tiomap3430.c
index 38338d1..4ac53ea 100644
--- a/drivers/dsp/bridge/wmd/tiomap3430.c
+++ b/drivers/dsp/bridge/wmd/tiomap3430.c
@@ -305,7 +305,7 @@ static dsp_status bridge_brd_monitor(struct wmd_dev_context
*hDevContext)
}
(*pdata->dsp_prm_rmw_bits)(OMAP3430_RST2_IVA2, 0
[PATCH v2 05/19] DSPBRIDGE: remove unused clock sys_ck
Remove unused clock sys_ck
Signed-off-by: Omar Ramirez Luna
---
arch/arm/plat-omap/include/dspbridge/clk.h |1 -
drivers/dsp/bridge/services/clk.c |1 -
2 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/clk.h
b/arch/arm/plat-omap/include/dspbridge/clk.h
index a547225..2a43aab 100644
--- a/arch/arm/plat-omap/include/dspbridge/clk.h
+++ b/arch/arm/plat-omap/include/dspbridge/clk.h
@@ -46,7 +46,6 @@ enum dsp_clk_id {
DSP_CLK_SSI_FCK,
DSP_CLK_SSI_ICK,
DSP_CLK_SYS32K_CK,
- DSP_CLK_SYS_CK,
DSP_CLK_NOT_DEFINED
};
diff --git a/drivers/dsp/bridge/services/clk.c
b/drivers/dsp/bridge/services/clk.c
index 4101c38..23d4346 100644
--- a/drivers/dsp/bridge/services/clk.c
+++ b/drivers/dsp/bridge/services/clk.c
@@ -76,7 +76,6 @@ static struct dsp_clk_t dsp_clks[] = {
{NULL, "ssi_ssr_sst_fck", -1},
{NULL, "ssi_ick", -1},
{NULL, "omap_32k_fck", -1},
- {NULL, "sys_ck", -1},
{NULL, ""}
};
--
1.6.2.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 v2 12/19] DSPBRIDGE: use omap mcbsp to enable mcbsp clocks
Use omap mcbsp to enable mcbsp clocks
Signed-off-by: Omar Ramirez Luna
---
drivers/dsp/bridge/services/clk.c | 24 ++--
1 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/dsp/bridge/services/clk.c
b/drivers/dsp/bridge/services/clk.c
index 37739a9..2e3c64d 100644
--- a/drivers/dsp/bridge/services/clk.c
+++ b/drivers/dsp/bridge/services/clk.c
@@ -19,6 +19,7 @@
/* --- Host OS */
#include
#include
+#include
/* --- DSP/BIOS Bridge */
#include
@@ -48,12 +49,12 @@
#define MCBSP_CLK 3
#define SSI_CLK4
-/*
- * Bridge specific DM Timer macro.
- * Bridge GPT id (1 - 4), DM Timer id (5 - 8)
- */
+/* Bridge GPT id (1 - 4), DM Timer id (5 - 8) */
#define DMT_ID(id) ((id) + 4)
+/* Bridge MCBSP id (6 - 10), OMAP Mcbsp id (1 - 5) */
+#define MCBSP_ID(id) ((id) - 13)
+
struct dsp_clk_t {
struct clk *clk_handle;
const char *clk_name;
@@ -65,16 +66,6 @@ static struct omap_dm_timer *timer[4];
static struct dsp_clk_t dsp_clks[] = {
{NULL, "wdt_fck", 3},
{NULL, "wdt_ick", 3},
- {NULL, "mcbsp_fck", 1},
- {NULL, "mcbsp_ick", 1},
- {NULL, "mcbsp_fck", 2},
- {NULL, "mcbsp_ick", 2},
- {NULL, "mcbsp_fck", 3},
- {NULL, "mcbsp_ick", 3},
- {NULL, "mcbsp_fck", 4},
- {NULL, "mcbsp_ick", 4},
- {NULL, "mcbsp_fck", 5},
- {NULL, "mcbsp_ick", 5},
{NULL, "ssi_ssr_sst_fck", -1},
{NULL, "ssi_ick", -1},
};
@@ -146,6 +137,9 @@ dsp_status dsp_clk_enable(IN enum dsp_clk_id clk_id)
timer[clk_id] = omap_dm_timer_request_specific(DMT_ID(clk_id));
break;
case MCBSP_CLK:
+ omap_mcbsp_set_io_type(MCBSP_ID(clk_id), OMAP_MCBSP_POLL_IO);
+ omap_mcbsp_request(MCBSP_ID(clk_id));
+ break;
case WDT_CLK:
case SSI_CLK:
clk_handle = dsp_clks[clk_id].clk_handle;
@@ -194,6 +188,8 @@ dsp_status dsp_clk_disable(IN enum dsp_clk_id clk_id)
omap_dm_timer_free(timer[clk_id]);
break;
case MCBSP_CLK:
+ omap_mcbsp_free(MCBSP_ID(clk_id));
+ break;
case WDT_CLK:
case SSI_CLK:
clk_handle = dsp_clks[clk_id].clk_handle;
--
1.6.2.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 v2 13/19] DSPBRIDGE: remove wdt3 from dsp control
WDT3 is used as a way to detect dsp hangs, as of now its
control is left to arm side driver, so, no requests should
be received by the dsp to enable/disable this clock.
Signed-off-by: Omar Ramirez Luna
---
drivers/dsp/bridge/services/clk.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/dsp/bridge/services/clk.c
b/drivers/dsp/bridge/services/clk.c
index 2e3c64d..ee85905 100644
--- a/drivers/dsp/bridge/services/clk.c
+++ b/drivers/dsp/bridge/services/clk.c
@@ -64,8 +64,6 @@ struct dsp_clk_t {
static struct omap_dm_timer *timer[4];
static struct dsp_clk_t dsp_clks[] = {
- {NULL, "wdt_fck", 3},
- {NULL, "wdt_ick", 3},
{NULL, "ssi_ssr_sst_fck", -1},
{NULL, "ssi_ick", -1},
};
@@ -141,6 +139,8 @@ dsp_status dsp_clk_enable(IN enum dsp_clk_id clk_id)
omap_mcbsp_request(MCBSP_ID(clk_id));
break;
case WDT_CLK:
+ dev_err(bridge, "ERROR: DSP requested to enable WDT3 clk\n");
+ break;
case SSI_CLK:
clk_handle = dsp_clks[clk_id].clk_handle;
if (clk_enable(clk_handle)) {
@@ -191,6 +191,8 @@ dsp_status dsp_clk_disable(IN enum dsp_clk_id clk_id)
omap_mcbsp_free(MCBSP_ID(clk_id));
break;
case WDT_CLK:
+ dev_err(bridge, "ERROR: DSP requested to disable WDT3 clk\n");
+ break;
case SSI_CLK:
clk_handle = dsp_clks[clk_id].clk_handle;
--
1.6.2.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 v2 09/19] DSPBRIDGE: function to get the type of clock requested by dsp
DSP can request between 5 types of clocks: IVA2, GPT (5-8), WDT (3),
MCBSP (1-5) or SSI clock. This function will be useful in case
a specific clock framework is associated with the clock.
Signed-off-by: Omar Ramirez Luna
---
drivers/dsp/bridge/services/clk.c | 89 -
1 files changed, 68 insertions(+), 21 deletions(-)
diff --git a/drivers/dsp/bridge/services/clk.c
b/drivers/dsp/bridge/services/clk.c
index e35b929..d5c3d4e 100644
--- a/drivers/dsp/bridge/services/clk.c
+++ b/drivers/dsp/bridge/services/clk.c
@@ -40,6 +40,13 @@
#define SSI_SIDLE_SMARTIDLE(2 << 3)
#define SSI_MIDLE_NOIDLE (1 << 12)
+/* Clk types requested by the dsp */
+#define IVA2_CLK 0
+#define GPT_CLK1
+#define WDT_CLK2
+#define MCBSP_CLK 3
+#define SSI_CLK4
+
struct dsp_clk_t {
struct clk *clk_handle;
const char *clk_name;
@@ -76,6 +83,26 @@ static struct dsp_clk_t dsp_clks[] = {
{NULL, ""}
};
+static s8 get_clk_type(u8 id)
+{
+ s8 type;
+
+ if (id == DSP_CLK_IVA2_CK)
+ type = IVA2_CLK;
+ else if (id <= DSP_CLK_GPT8_ICK)
+ type = GPT_CLK;
+ else if (id <= DSP_CLK_WDT3_ICK)
+ type = WDT_CLK;
+ else if (id <= DSP_CLK_MCBSP5_ICK)
+ type = MCBSP_CLK;
+ else if (id < DSP_CLK_SSI_ICK)
+ type = SSI_CLK;
+ else
+ type = -1;
+
+ return type;
+}
+
/*
* dsp_clk_exit
* Purpose:
@@ -141,23 +168,33 @@ dsp_status dsp_clk_enable(IN enum dsp_clk_id clk_id)
dsp_status status = DSP_SOK;
struct clk *clk_handle;
- DBC_REQUIRE(clk_id < DSP_CLK_NOT_DEFINED);
+ switch (get_clk_type(clk_id)) {
+ case IVA2_CLK:
+ case GPT_CLK:
+ case MCBSP_CLK:
+ case WDT_CLK:
+ case SSI_CLK:
+ clk_handle = dsp_clks[clk_id].clk_handle;
+ if (clk_enable(clk_handle)) {
+ pr_err("dsp_clk_enable: failed to Enable CLK %s, "
+ "CLK dev id = %d\n", dsp_clks[clk_id].clk_name,
+ dsp_clks[clk_id].id);
+ status = -EPERM;
+ }
- clk_handle = dsp_clks[clk_id].clk_handle;
- if (clk_enable(clk_handle)) {
- pr_err("dsp_clk_enable: failed to Enable CLK %s, "
- "CLK dev id = %d\n",
- dsp_clks[clk_id].clk_name,
- dsp_clks[clk_id].id);
- status = -EPERM;
+ /*
+* The SSI module need to configured not to have the Forced
+* idle for master interface. If it is set to forced idle,
+* the SSI module is transitioning to standby thereby causing
+* the client in the DSP hang waiting for the SSI module to
+* be active after enabling the clocks
+*/
+ if (clk_id == DSP_CLK_SSI_ICK)
+ ssi_clk_prepare(true);
+ break;
+ default:
+ dev_err(bridge, "Invalid clock id for enable\n");
}
- /* The SSI module need to configured not to have the Forced idle for
-* master interface. If it is set to forced idle, the SSI module is
-* transitioning to standby thereby causing the client in the DSP hang
-* waiting for the SSI module to be active after enabling the clocks
-*/
- if (clk_id == DSP_CLK_SSI_FCK)
- ssi_clk_prepare(true);
return status;
}
@@ -175,12 +212,22 @@ dsp_status dsp_clk_disable(IN enum dsp_clk_id clk_id)
DBC_REQUIRE(clk_id < DSP_CLK_NOT_DEFINED);
- clk_handle = dsp_clks[clk_id].clk_handle;
-
- if (clk_id == DSP_CLK_SSI_ICK)
- ssi_clk_prepare(false);
-
- clk_disable(clk_handle);
+ switch (get_clk_type(clk_id)) {
+ case IVA2_CLK:
+ case GPT_CLK:
+ case MCBSP_CLK:
+ case WDT_CLK:
+ case SSI_CLK:
+ clk_handle = dsp_clks[clk_id].clk_handle;
+
+ if (clk_id == DSP_CLK_SSI_ICK)
+ ssi_clk_prepare(false);
+
+ clk_disable(clk_handle);
+ break;
+ default:
+ dev_err(bridge, "Invalid clock id for disable\n");
+ }
return status;
}
--
1.6.2.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 v2 11/19] DSPBRIDGE: use dm timer framework for gpt timers
This patch switches to use DM timer framework instead of
a custom one for GPT timers, currently dsp can make use of
gpt 5, 6, 7 or 8.
Signed-off-by: Omar Ramirez Luna
---
drivers/dsp/bridge/services/clk.c | 25 ---
drivers/dsp/bridge/wmd/tiomap3430.c | 36 ---
2 files changed, 13 insertions(+), 48 deletions(-)
diff --git a/drivers/dsp/bridge/services/clk.c
b/drivers/dsp/bridge/services/clk.c
index 9c994d3..37739a9 100644
--- a/drivers/dsp/bridge/services/clk.c
+++ b/drivers/dsp/bridge/services/clk.c
@@ -18,6 +18,7 @@
/* --- Host OS */
#include
+#include
/* --- DSP/BIOS Bridge */
#include
@@ -47,24 +48,21 @@
#define MCBSP_CLK 3
#define SSI_CLK4
+/*
+ * Bridge specific DM Timer macro.
+ * Bridge GPT id (1 - 4), DM Timer id (5 - 8)
+ */
+#define DMT_ID(id) ((id) + 4)
+
struct dsp_clk_t {
struct clk *clk_handle;
const char *clk_name;
int id;
};
-/* The row order of the below array needs to match with the clock enumerations
- * 'dsp_clk_id' provided in the header file.. any changes in the
- * enumerations needs to be fixed in the array as well */
+static struct omap_dm_timer *timer[4];
+
static struct dsp_clk_t dsp_clks[] = {
- {NULL, "gpt5_fck", -1},
- {NULL, "gpt5_ick", -1},
- {NULL, "gpt6_fck", -1},
- {NULL, "gpt6_ick", -1},
- {NULL, "gpt7_fck", -1},
- {NULL, "gpt7_ick", -1},
- {NULL, "gpt8_fck", -1},
- {NULL, "gpt8_ick", -1},
{NULL, "wdt_fck", 3},
{NULL, "wdt_ick", 3},
{NULL, "mcbsp_fck", 1},
@@ -79,7 +77,6 @@ static struct dsp_clk_t dsp_clks[] = {
{NULL, "mcbsp_ick", 5},
{NULL, "ssi_ssr_sst_fck", -1},
{NULL, "ssi_ick", -1},
- {NULL, ""}
};
struct clk *iva2_clk;
@@ -146,6 +143,8 @@ dsp_status dsp_clk_enable(IN enum dsp_clk_id clk_id)
clk_enable(iva2_clk);
break;
case GPT_CLK:
+ timer[clk_id] = omap_dm_timer_request_specific(DMT_ID(clk_id));
+ break;
case MCBSP_CLK:
case WDT_CLK:
case SSI_CLK:
@@ -192,6 +191,8 @@ dsp_status dsp_clk_disable(IN enum dsp_clk_id clk_id)
clk_disable(iva2_clk);
break;
case GPT_CLK:
+ omap_dm_timer_free(timer[clk_id]);
+ break;
case MCBSP_CLK:
case WDT_CLK:
case SSI_CLK:
diff --git a/drivers/dsp/bridge/wmd/tiomap3430.c
b/drivers/dsp/bridge/wmd/tiomap3430.c
index bb78df2..38338d1 100644
--- a/drivers/dsp/bridge/wmd/tiomap3430.c
+++ b/drivers/dsp/bridge/wmd/tiomap3430.c
@@ -392,9 +392,6 @@ static dsp_status bridge_brd_start(struct wmd_dev_context
*hDevContext,
u32 clk_cmd;
struct io_mgr *hio_mgr;
u32 ul_load_monitor_timer;
- u32 ext_clk_id = 0;
- u32 tmp_index;
- u32 clk_id_index = MBX_PM_MAX_RESOURCES;
struct dspbridge_platform_data *pdata =
omap_dspbridge_dev->dev.platform_data;
@@ -529,25 +526,9 @@ static dsp_status bridge_brd_start(struct wmd_dev_context
*hDevContext,
if (DSP_SUCCEEDED(status)) {
if (ul_load_monitor_timer != 0x) {
- clk_cmd = (BPWR_DISABLE_CLOCK << MBX_PM_CLK_CMDSHIFT) |
- ul_load_monitor_timer;
-
- dsp_peripheral_clk_ctrl(dev_context, &clk_cmd);
-
- ext_clk_id = clk_cmd & MBX_PM_CLK_IDMASK;
- for (tmp_index = 0; tmp_index < MBX_PM_MAX_RESOURCES;
-tmp_index++) {
- if (ext_clk_id == bpwr_clkid[tmp_index]) {
- clk_id_index = tmp_index;
- break;
- }
- }
-
clk_cmd = (BPWR_ENABLE_CLOCK << MBX_PM_CLK_CMDSHIFT) |
ul_load_monitor_timer;
-
dsp_peripheral_clk_ctrl(dev_context, &clk_cmd);
-
} else {
dev_dbg(bridge, "Not able to get the symbol for Load "
"Monitor Timer\n");
@@ -556,26 +537,9 @@ static dsp_status bridge_brd_start(struct wmd_dev_context
*hDevContext,
if (DSP_SUCCEEDED(status)) {
if (ul_bios_gp_timer != 0x) {
- clk_cmd = (BPWR_DISABLE_CLOCK << MBX_PM_CLK_CMDSHIFT) |
- ul_bios_gp_timer;
-
- dsp_peripheral_clk_ctrl(dev_context, &clk_cmd);
-
- ext_clk_id = clk_cmd & MBX_PM_CLK_IDMASK;
-
- for (tmp_index = 0; tmp_index < MBX_PM_MAX_RESOURCES;
-tmp_index++) {
- if (ext_clk_id == bpwr_clkid[tmp_index]) {
-
[PATCH v2 10/19] DSPBRIDGE: iva2 clock handling
Change the way iva2 clock is handled and since the rate is needed
for this clock only, make the function get_rate to be specific for
iva clock.
Signed-off-by: Omar Ramirez Luna
---
arch/arm/plat-omap/include/dspbridge/clk.h | 16 +--
drivers/dsp/bridge/services/clk.c | 71 +++-
drivers/dsp/bridge/services/services.c |9 +---
drivers/dsp/bridge/wmd/tiomap3430.c|3 +-
4 files changed, 22 insertions(+), 77 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/clk.h
b/arch/arm/plat-omap/include/dspbridge/clk.h
index f19d024..2602d9f 100644
--- a/arch/arm/plat-omap/include/dspbridge/clk.h
+++ b/arch/arm/plat-omap/include/dspbridge/clk.h
@@ -71,7 +71,7 @@ extern void dsp_clk_exit(void);
* Ensures:
* CLK initialized.
*/
-extern bool dsp_clk_init(void);
+extern void dsp_clk_init(void);
/*
* dsp_clk_enable
@@ -99,19 +99,7 @@ extern dsp_status dsp_clk_enable(IN enum dsp_clk_id clk_id);
*/
extern dsp_status dsp_clk_disable(IN enum dsp_clk_id clk_id);
-/*
- * dsp_clk_get_rate
- * Purpose:
- * Get the clock rate of requested clock.
- * Parameters:
- * Returns:
- * DSP_SOK:Success.
- * -EPERM: Error occured while Getting the clock rate.
- * Requires:
- * Ensures:
- */
-extern dsp_status dsp_clk_get_rate(IN enum dsp_clk_id clk_id,
- u32 *speedMhz);
+extern u32 dsp_clk_get_iva2_rate(void);
extern void ssi_clk_prepare(bool FLAG);
diff --git a/drivers/dsp/bridge/services/clk.c
b/drivers/dsp/bridge/services/clk.c
index d5c3d4e..9c994d3 100644
--- a/drivers/dsp/bridge/services/clk.c
+++ b/drivers/dsp/bridge/services/clk.c
@@ -57,7 +57,6 @@ struct dsp_clk_t {
* 'dsp_clk_id' provided in the header file.. any changes in the
* enumerations needs to be fixed in the array as well */
static struct dsp_clk_t dsp_clks[] = {
- {NULL, "iva2_ck", -1},
{NULL, "gpt5_fck", -1},
{NULL, "gpt5_ick", -1},
{NULL, "gpt6_fck", -1},
@@ -83,6 +82,8 @@ static struct dsp_clk_t dsp_clks[] = {
{NULL, ""}
};
+struct clk *iva2_clk;
+
static s8 get_clk_type(u8 id)
{
s8 type;
@@ -110,17 +111,7 @@ static s8 get_clk_type(u8 id)
*/
void dsp_clk_exit(void)
{
- int i = 0;
-
- /* Relinquish the clock handles */
- while (i < DSP_CLK_NOT_DEFINED) {
- if (dsp_clks[i].clk_handle)
- clk_put(dsp_clks[i].clk_handle);
-
- dsp_clks[i].clk_handle = NULL;
- i++;
- }
-
+ clk_put(iva2_clk);
}
/*
@@ -128,33 +119,15 @@ void dsp_clk_exit(void)
* Purpose:
* Initialize CLK module.
*/
-bool dsp_clk_init(void)
+void dsp_clk_init(void)
{
static struct platform_device dspbridge_device;
- struct clk *clk_handle;
- int i = 0;
dspbridge_device.dev.bus = &platform_bus_type;
- /* Get the clock handles from base port and store locally */
- while (i < DSP_CLK_NOT_DEFINED) {
- /* get the handle from BP */
- dspbridge_device.id = dsp_clks[i].id;
-
- clk_handle = clk_get(&dspbridge_device.dev,
-dsp_clks[i].clk_name);
-
- if (IS_ERR(clk_handle)) {
- pr_err("%s: failed to get clk handle %s, dev id = %d\n",
- __func__, dsp_clks[i].clk_name,
- dsp_clks[i].id);
- return false;
- }
- dsp_clks[i].clk_handle = clk_handle;
- i++;
- }
-
- return true;
+ iva2_clk = clk_get(&dspbridge_device.dev, "iva2_ck");
+ if (IS_ERR(iva2_clk))
+ dev_err(bridge, "failed to get iva2 clock %p\n", iva2_clk);
}
/*
@@ -170,6 +143,8 @@ dsp_status dsp_clk_enable(IN enum dsp_clk_id clk_id)
switch (get_clk_type(clk_id)) {
case IVA2_CLK:
+ clk_enable(iva2_clk);
+ break;
case GPT_CLK:
case MCBSP_CLK:
case WDT_CLK:
@@ -214,6 +189,8 @@ dsp_status dsp_clk_disable(IN enum dsp_clk_id clk_id)
switch (get_clk_type(clk_id)) {
case IVA2_CLK:
+ clk_disable(iva2_clk);
+ break;
case GPT_CLK:
case MCBSP_CLK:
case WDT_CLK:
@@ -232,29 +209,15 @@ dsp_status dsp_clk_disable(IN enum dsp_clk_id clk_id)
return status;
}
-/*
- * dsp_clk_get_rate
- * Purpose:
- * GetClock Speed.
- *
- */
-
-dsp_status dsp_clk_get_rate(IN enum dsp_clk_id clk_id, u32 *speedKhz)
+u32 dsp_clk_get_iva2_rate(void)
{
- dsp_status status = DSP_SOK;
- struct clk *clk_handle;
- u32 clk_speed_hz;
+ u32 clk_speed_khz;
- DBC_REQUIRE(clk_id < SERVICESCLK_NOT_DEFINED);
- *speedKhz = 0x0;
+ clk_speed_khz = clk_get_rate(iva2_clk);
+ clk_speed_khz /= 1000;
+ dev_dbg
[PATCH v2 17/19] DSPBRIDGE: Balance the number of enable/disable
This patch ensure a balanced number of enable/disable
calls is made.
Signed-off-by: Omar Ramirez Luna
---
drivers/dsp/bridge/services/clk.c | 37 +
1 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/drivers/dsp/bridge/services/clk.c
b/drivers/dsp/bridge/services/clk.c
index 763a599..c4f0874 100644
--- a/drivers/dsp/bridge/services/clk.c
+++ b/drivers/dsp/bridge/services/clk.c
@@ -71,6 +71,23 @@ struct dsp_ssi {
static struct dsp_ssi ssi;
+static u32 dsp_clocks;
+
+static inline u32 is_dsp_clk_active(u32 clk, u8 id)
+{
+ return clk & (1 << id);
+}
+
+static inline void set_dsp_clk_active(u32 *clk, u8 id)
+{
+ *clk |= (1 << id);
+}
+
+static inline void set_dsp_clk_inactive(u32 *clk, u8 id)
+{
+ *clk &= ~(1 << id);
+}
+
static s8 get_clk_type(u8 id)
{
s8 type;
@@ -184,6 +201,11 @@ dsp_status dsp_clk_enable(IN enum dsp_clk_id clk_id)
{
dsp_status status = DSP_SOK;
+ if (is_dsp_clk_active(dsp_clocks, clk_id)) {
+ dev_err(bridge, "WARN: clock id %d already enabled\n", clk_id);
+ goto out;
+ }
+
switch (get_clk_type(clk_id)) {
case IVA2_CLK:
clk_enable(iva2_clk);
@@ -215,8 +237,13 @@ dsp_status dsp_clk_enable(IN enum dsp_clk_id clk_id)
break;
default:
dev_err(bridge, "Invalid clock id for enable\n");
+ status = -EPERM;
}
+ if (DSP_SUCCEEDED(status))
+ set_dsp_clk_active(&dsp_clocks, clk_id);
+
+out:
return status;
}
@@ -230,6 +257,11 @@ dsp_status dsp_clk_disable(IN enum dsp_clk_id clk_id)
{
dsp_status status = DSP_SOK;
+ if (!is_dsp_clk_active(dsp_clocks, clk_id)) {
+ dev_err(bridge, "ERR: clock id %d already disabled\n", clk_id);
+ goto out;
+ }
+
switch (get_clk_type(clk_id)) {
case IVA2_CLK:
clk_disable(iva2_clk);
@@ -253,8 +285,13 @@ dsp_status dsp_clk_disable(IN enum dsp_clk_id clk_id)
break;
default:
dev_err(bridge, "Invalid clock id for disable\n");
+ status = -EPERM;
}
+ if (DSP_SUCCEEDED(status))
+ set_dsp_clk_inactive(&dsp_clocks, clk_id);
+
+out:
return status;
}
--
1.6.2.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 v2 19/19] DSPBRIDGE: reorganize the code to handle peripheral clocks
This patch moves and simplifies the code used to enable/disable
all the requested peripheral clocks.
Signed-off-by: Omar Ramirez Luna
---
arch/arm/plat-omap/include/dspbridge/clk.h |4 ++
drivers/dsp/bridge/rmgr/drv_interface.c|1 +
drivers/dsp/bridge/wmd/_tiomap_pwr.h | 17 --
drivers/dsp/bridge/wmd/dsp-clock.c | 43 +
drivers/dsp/bridge/wmd/tiomap3430_pwr.c| 47 +++-
drivers/dsp/bridge/wmd/tiomap_io.c |4 +-
drivers/dsp/bridge/wmd/ue_deh.c|2 +-
7 files changed, 56 insertions(+), 62 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/clk.h
b/arch/arm/plat-omap/include/dspbridge/clk.h
index e6b09c7..439fc2d 100644
--- a/arch/arm/plat-omap/include/dspbridge/clk.h
+++ b/arch/arm/plat-omap/include/dspbridge/clk.h
@@ -75,6 +75,8 @@ extern void dsp_clk_init(void);
*/
extern dsp_status dsp_clk_enable(IN enum dsp_clk_id clk_id);
+u32 dsp_clock_enable_all(u32 dsp_per_clocks);
+
/*
* dsp_clk_disable
* Purpose:
@@ -90,6 +92,8 @@ extern dsp_status dsp_clk_disable(IN enum dsp_clk_id clk_id);
extern u32 dsp_clk_get_iva2_rate(void);
+u32 dsp_clock_disable_all(u32 dsp_per_clocks);
+
extern void ssi_clk_prepare(bool FLAG);
#endif /* _SYNC_H */
diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
b/drivers/dsp/bridge/rmgr/drv_interface.c
index db1c746..04b17be 100644
--- a/drivers/dsp/bridge/rmgr/drv_interface.c
+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
@@ -41,6 +41,7 @@
/* --- OS Adaptation Layer */
#include
+#include
#include
/* --- Platform Manager */
diff --git a/drivers/dsp/bridge/wmd/_tiomap_pwr.h
b/drivers/dsp/bridge/wmd/_tiomap_pwr.h
index a7a4fc2..1948e83 100644
--- a/drivers/dsp/bridge/wmd/_tiomap_pwr.h
+++ b/drivers/dsp/bridge/wmd/_tiomap_pwr.h
@@ -64,23 +64,6 @@ dsp_status pre_scale_dsp(struct wmd_dev_context
*dev_context, IN void *pargs);
*/
dsp_status handle_constraints_set(struct wmd_dev_context *dev_context,
IN void *pargs);
-/*
- * dsp_peripheral_clocks_disable
- * This function disables all the peripheral clocks that
- * were enabled by DSP. Call this function only when
- * DSP is entering Hibernation or when DSP is in
- * Error state
- */
-dsp_status dsp_peripheral_clocks_disable(struct wmd_dev_context *dev_context,
-IN void *pargs);
-
-/*
- * dsp_peripheral_clocks_enable
- * This function enables all the peripheral clocks that
- * were requested by DSP.
- */
-dsp_status dsp_peripheral_clocks_enable(struct wmd_dev_context *dev_context,
- IN void *pargs);
/*
* dsp_clk_wakeup_event_ctrl
diff --git a/drivers/dsp/bridge/wmd/dsp-clock.c
b/drivers/dsp/bridge/wmd/dsp-clock.c
index c4f0874..608ff03 100644
--- a/drivers/dsp/bridge/wmd/dsp-clock.c
+++ b/drivers/dsp/bridge/wmd/dsp-clock.c
@@ -115,6 +115,8 @@ static s8 get_clk_type(u8 id)
*/
void dsp_clk_exit(void)
{
+ dsp_clock_disable_all(dsp_clocks);
+
clk_put(iva2_clk);
clk_put(ssi.sst_fck);
clk_put(ssi.ssr_fck);
@@ -247,6 +249,25 @@ out:
return status;
}
+/**
+ * dsp_clock_enable_all - Enable clocks used by the DSP
+ * @dev_contextDriver's device context strucure
+ *
+ * This function enables all the peripheral clocks that were requested by DSP.
+ */
+u32 dsp_clock_enable_all(u32 dsp_per_clocks)
+{
+ u32 clk_id;
+ u32 status = -EPERM;
+
+ for (clk_id = 0; clk_id < DSP_CLK_NOT_DEFINED; clk_id++) {
+ if (is_dsp_clk_active(dsp_per_clocks, clk_id))
+ status = dsp_clk_enable(clk_id);
+ }
+
+ return status;
+}
+
/*
* dsp_clk_disable
* Purpose:
@@ -295,6 +316,27 @@ out:
return status;
}
+/**
+ * dsp_clock_disable_all - Disable all active clocks
+ * @dev_contextDriver's device context structure
+ *
+ * This function disables all the peripheral clocks that were enabled by DSP.
+ * It is meant to be called only when DSP is entering hibernation or when DSP
+ * is in error state.
+ */
+u32 dsp_clock_disable_all(u32 dsp_per_clocks)
+{
+ u32 clk_id;
+ u32 status = -EPERM;
+
+ for (clk_id = 0; clk_id < DSP_CLK_NOT_DEFINED; clk_id++) {
+ if (is_dsp_clk_active(dsp_per_clocks, clk_id))
+ status = dsp_clk_disable(clk_id);
+ }
+
+ return status;
+}
+
u32 dsp_clk_get_iva2_rate(void)
{
u32 clk_speed_khz;
@@ -332,3 +374,4 @@ void ssi_clk_prepare(bool FLAG)
__raw_writel(value, ssi_base + OMAP_SSI_SYSCONFIG_OFFSET);
iounmap(ssi_base);
}
+
diff --git a/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
b/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
index 6d1d557..906c2c5 100644
---
[PATCH v2 14/19] DSPBRIDGE: dsp interface to enable ssi clocks
This patch fixes the wrong name for ssi clock,
now it has been split into ssr and sst for fck. It
handle ick/ssr_fck/sst_fck clocks with one call to
disable/enable.
Signed-off-by: Omar Ramirez Luna
---
drivers/dsp/bridge/services/clk.c | 56 ++---
1 files changed, 27 insertions(+), 29 deletions(-)
diff --git a/drivers/dsp/bridge/services/clk.c
b/drivers/dsp/bridge/services/clk.c
index ee85905..c72f574 100644
--- a/drivers/dsp/bridge/services/clk.c
+++ b/drivers/dsp/bridge/services/clk.c
@@ -55,20 +55,17 @@
/* Bridge MCBSP id (6 - 10), OMAP Mcbsp id (1 - 5) */
#define MCBSP_ID(id) ((id) - 13)
-struct dsp_clk_t {
- struct clk *clk_handle;
- const char *clk_name;
- int id;
-};
-
static struct omap_dm_timer *timer[4];
-static struct dsp_clk_t dsp_clks[] = {
- {NULL, "ssi_ssr_sst_fck", -1},
- {NULL, "ssi_ick", -1},
+struct clk *iva2_clk;
+
+struct dsp_ssi {
+ struct clk *sst_fck;
+ struct clk *ssr_fck;
+ struct clk *ick;
};
-struct clk *iva2_clk;
+static struct dsp_ssi ssi;
static s8 get_clk_type(u8 id)
{
@@ -98,6 +95,9 @@ static s8 get_clk_type(u8 id)
void dsp_clk_exit(void)
{
clk_put(iva2_clk);
+ clk_put(ssi.sst_fck);
+ clk_put(ssi.ssr_fck);
+ clk_put(ssi.ick);
}
/*
@@ -114,6 +114,14 @@ void dsp_clk_init(void)
iva2_clk = clk_get(&dspbridge_device.dev, "iva2_ck");
if (IS_ERR(iva2_clk))
dev_err(bridge, "failed to get iva2 clock %p\n", iva2_clk);
+
+ ssi.sst_fck = clk_get(&dspbridge_device.dev, "ssi_sst_fck");
+ ssi.ssr_fck = clk_get(&dspbridge_device.dev, "ssi_ssr_fck");
+ ssi.ick = clk_get(&dspbridge_device.dev, "ssi_ick");
+
+ if (IS_ERR(ssi.sst_fck) || IS_ERR(ssi.ssr_fck) || IS_ERR(ssi.ick))
+ dev_err(bridge, "failed to get ssi: sst %p, ssr %p, ick %p\n",
+ ssi.sst_fck, ssi.ssr_fck, ssi.ick);
}
/*
@@ -125,7 +133,6 @@ void dsp_clk_init(void)
dsp_status dsp_clk_enable(IN enum dsp_clk_id clk_id)
{
dsp_status status = DSP_SOK;
- struct clk *clk_handle;
switch (get_clk_type(clk_id)) {
case IVA2_CLK:
@@ -142,13 +149,9 @@ dsp_status dsp_clk_enable(IN enum dsp_clk_id clk_id)
dev_err(bridge, "ERROR: DSP requested to enable WDT3 clk\n");
break;
case SSI_CLK:
- clk_handle = dsp_clks[clk_id].clk_handle;
- if (clk_enable(clk_handle)) {
- pr_err("dsp_clk_enable: failed to Enable CLK %s, "
- "CLK dev id = %d\n", dsp_clks[clk_id].clk_name,
- dsp_clks[clk_id].id);
- status = -EPERM;
- }
+ clk_enable(ssi.sst_fck);
+ clk_enable(ssi.ssr_fck);
+ clk_enable(ssi.ick);
/*
* The SSI module need to configured not to have the Forced
@@ -157,8 +160,7 @@ dsp_status dsp_clk_enable(IN enum dsp_clk_id clk_id)
* the client in the DSP hang waiting for the SSI module to
* be active after enabling the clocks
*/
- if (clk_id == DSP_CLK_SSI_ICK)
- ssi_clk_prepare(true);
+ ssi_clk_prepare(true);
break;
default:
dev_err(bridge, "Invalid clock id for enable\n");
@@ -176,9 +178,6 @@ dsp_status dsp_clk_enable(IN enum dsp_clk_id clk_id)
dsp_status dsp_clk_disable(IN enum dsp_clk_id clk_id)
{
dsp_status status = DSP_SOK;
- struct clk *clk_handle;
-
- DBC_REQUIRE(clk_id < DSP_CLK_NOT_DEFINED);
switch (get_clk_type(clk_id)) {
case IVA2_CLK:
@@ -194,12 +193,11 @@ dsp_status dsp_clk_disable(IN enum dsp_clk_id clk_id)
dev_err(bridge, "ERROR: DSP requested to disable WDT3 clk\n");
break;
case SSI_CLK:
- clk_handle = dsp_clks[clk_id].clk_handle;
-
- if (clk_id == DSP_CLK_SSI_ICK)
- ssi_clk_prepare(false);
-
- clk_disable(clk_handle);
+ ssi_clk_prepare(false);
+ ssi_clk_prepare(false);
+ clk_disable(ssi.sst_fck);
+ clk_disable(ssi.ssr_fck);
+ clk_disable(ssi.ick);
break;
default:
dev_err(bridge, "Invalid clock id for disable\n");
--
1.6.2.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 v2 16/19] DSPBRIDGE: Move MCBSP_CLOCKS code to a common place
Given that:
"Bridge should enable McBSP_CLKS (using T2 clock) so that DPLL4
can be gated. Once McBSP2 clock is released, it should disable
McBSP_CLKS as it prevents PER and CORE domain transitions when
OFF is set to target power state."
It seems this code was duplicated, now it has been moved to be
called only when dsp is requesting a MCBSP clock.
Signed-off-by: Omar Ramirez Luna
---
drivers/dsp/bridge/services/clk.c | 52 +
drivers/dsp/bridge/wmd/tiomap3430_pwr.c | 77 ---
2 files changed, 52 insertions(+), 77 deletions(-)
diff --git a/drivers/dsp/bridge/services/clk.c
b/drivers/dsp/bridge/services/clk.c
index 9a439c7..763a599 100644
--- a/drivers/dsp/bridge/services/clk.c
+++ b/drivers/dsp/bridge/services/clk.c
@@ -25,6 +25,10 @@
#include
#include
#include
+#include
+#include
+#include
+#include "_tiomap.h"
/* --- Trace & Debug */
#include
@@ -124,6 +128,52 @@ void dsp_clk_init(void)
ssi.sst_fck, ssi.ssr_fck, ssi.ick);
}
+static void mcbsp_clk_prepare(bool flag, u8 id)
+{
+ struct cfg_hostres *resources;
+ struct dev_object *hdev_object = NULL;
+ struct wmd_dev_context *wmd_context = NULL;
+ u32 val;
+
+ hdev_object = (struct dev_object *)drv_get_first_dev_object();
+ if (!hdev_object)
+ return;
+
+ dev_get_wmd_context(hdev_object, &wmd_context);
+ if (!wmd_context)
+ return;
+
+ resources = wmd_context->resources;
+ if (!resources)
+ return;
+
+ if (flag) {
+ if (id == DSP_CLK_MCBSP1) {
+ /* set MCBSP1_CLKS, on McBSP1 ON */
+ val = __raw_readl(resources->dw_sys_ctrl_base + 0x274);
+ val |= 1 << 2;
+ __raw_writel(val, resources->dw_sys_ctrl_base + 0x274);
+ } else if (id == DSP_CLK_MCBSP2) {
+ /* set MCBSP2_CLKS, on McBSP2 ON */
+ val = __raw_readl(resources->dw_sys_ctrl_base + 0x274);
+ val |= 1 << 6;
+ __raw_writel(val, resources->dw_sys_ctrl_base + 0x274);
+ }
+ } else {
+ if (id == DSP_CLK_MCBSP1) {
+ /* clear MCBSP1_CLKS, on McBSP1 OFF */
+ val = __raw_readl(resources->dw_sys_ctrl_base + 0x274);
+ val &= ~(1 << 2);
+ __raw_writel(val, resources->dw_sys_ctrl_base + 0x274);
+ } else if (id == DSP_CLK_MCBSP2) {
+ /* clear MCBSP2_CLKS, on McBSP2 OFF */
+ val = __raw_readl(resources->dw_sys_ctrl_base + 0x274);
+ val &= ~(1 << 6);
+ __raw_writel(val, resources->dw_sys_ctrl_base + 0x274);
+ }
+ }
+}
+
/*
* dsp_clk_enable
* Purpose:
@@ -142,6 +192,7 @@ dsp_status dsp_clk_enable(IN enum dsp_clk_id clk_id)
timer[clk_id] = omap_dm_timer_request_specific(DMT_ID(clk_id));
break;
case MCBSP_CLK:
+ mcbsp_clk_prepare(true, clk_id);
omap_mcbsp_set_io_type(MCBSP_ID(clk_id), OMAP_MCBSP_POLL_IO);
omap_mcbsp_request(MCBSP_ID(clk_id));
break;
@@ -187,6 +238,7 @@ dsp_status dsp_clk_disable(IN enum dsp_clk_id clk_id)
omap_dm_timer_free(timer[clk_id]);
break;
case MCBSP_CLK:
+ mcbsp_clk_prepare(false, clk_id);
omap_mcbsp_free(MCBSP_ID(clk_id));
break;
case WDT_CLK:
diff --git a/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
b/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
index 879f99e..6d1d557 100644
--- a/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
+++ b/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
@@ -288,16 +288,10 @@ dsp_status dsp_peripheral_clk_ctrl(struct wmd_dev_context
*dev_context,
u32 tmp_index;
u32 dsp_per_clks_before;
dsp_status status = DSP_SOK;
- struct cfg_hostres *resources = dev_context->resources;
- u32 value;
dsp_per_clks_before = dev_context->dsp_per_clks;
ext_clk = (u32) *((u32 *) pargs);
-
- if (!resources)
- return -EPERM;
-
ext_clk_id = ext_clk & MBX_PM_CLK_IDMASK;
/* process the power message -- TODO, keep it in a separate function */
@@ -317,21 +311,6 @@ dsp_status dsp_peripheral_clk_ctrl(struct wmd_dev_context
*dev_context,
ext_clk_cmd = (ext_clk >> MBX_PM_CLK_CMDSHIFT) & MBX_PM_CLK_CMDMASK;
switch (ext_clk_cmd) {
case BPWR_DISABLE_CLOCK:
- if (bpwr_clkid[clk_id_index] == BPWR_MCBSP1) {
- /* clear MCBSP1_CLKS, on McBSP1 OFF */
- value = __raw_readl(
- resources->dw_sys_ctrl_base + 0x274);
-
[PATCH v2 18/19] DSPBRIDGE: move clk to dsp-clock
Rename file and move it outside services layer.
Signed-off-by: Omar Ramirez Luna
---
drivers/dsp/bridge/Makefile |4 +-
drivers/dsp/bridge/rmgr/drv_interface.c |2 +
drivers/dsp/bridge/services/clk.c | 334 ---
drivers/dsp/bridge/services/services.c |3 -
drivers/dsp/bridge/wmd/dsp-clock.c | 334 +++
5 files changed, 338 insertions(+), 339 deletions(-)
delete mode 100644 drivers/dsp/bridge/services/clk.c
create mode 100644 drivers/dsp/bridge/wmd/dsp-clock.c
diff --git a/drivers/dsp/bridge/Makefile b/drivers/dsp/bridge/Makefile
index e243670..8b9a681 100644
--- a/drivers/dsp/bridge/Makefile
+++ b/drivers/dsp/bridge/Makefile
@@ -1,11 +1,11 @@
obj-$(CONFIG_MPU_BRIDGE) += bridgedriver.o
libgen = gen/gb.o gen/gs.o gen/gh.o gen/uuidutil.o
-libservices = services/sync.o services/clk.o services/cfg.o \
+libservices = services/sync.o services/cfg.o \
services/ntfy.o services/services.o
libwmd = wmd/chnl_sm.o wmd/msg_sm.o wmd/io_sm.o wmd/tiomap3430.o \
wmd/tiomap3430_pwr.o wmd/tiomap_io.o \
- wmd/mmu_fault.o wmd/ue_deh.o wmd/wdt.o
+ wmd/mmu_fault.o wmd/ue_deh.o wmd/wdt.o wmd/dsp-clock.o
libpmgr = pmgr/chnl.o pmgr/io.o pmgr/msg.o pmgr/cod.o pmgr/dev.o pmgr/wcd.o \
pmgr/dmm.o pmgr/cmm.o pmgr/dbll.o
librmgr = rmgr/dbdcd.o rmgr/disp.o rmgr/drv.o rmgr/mgr.o rmgr/node.o \
diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
b/drivers/dsp/bridge/rmgr/drv_interface.c
index ea2a5f3..db1c746 100644
--- a/drivers/dsp/bridge/rmgr/drv_interface.c
+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
@@ -285,6 +285,7 @@ static int __devinit omap34_xx_bridge_probe(struct
platform_device *pdev)
}
#endif
+ dsp_clk_init();
services_init();
/* Autostart flag. This should be set to true if the DSP image should
@@ -382,6 +383,7 @@ static int __devexit omap34_xx_bridge_remove(struct
platform_device *pdev)
func_cont:
mem_ext_phys_pool_release();
+ dsp_clk_exit();
services_exit();
devno = MKDEV(driver_major, 0);
diff --git a/drivers/dsp/bridge/services/clk.c
b/drivers/dsp/bridge/services/clk.c
deleted file mode 100644
index c4f0874..000
--- a/drivers/dsp/bridge/services/clk.c
+++ /dev/null
@@ -1,334 +0,0 @@
-/*
- * clk.c
- *
- * DSP-BIOS Bridge driver support functions for TI OMAP processors.
- *
- * Clock and Timer services.
- *
- * Copyright (C) 2005-2006 Texas Instruments, Inc.
- *
- * This package is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
- * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
- * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
- */
-
-/* --- Host OS */
-#include
-#include
-#include
-
-/* --- DSP/BIOS Bridge */
-#include
-#include
-#include
-#include
-#include
-#include
-#include "_tiomap.h"
-
-/* --- Trace & Debug */
-#include
-
-/* --- This */
-#include
-
-/* --- Defines, Data Structures, Typedefs */
-
-#define OMAP_SSI_OFFSET0x58000
-#define OMAP_SSI_SIZE 0x1000
-#define OMAP_SSI_SYSCONFIG_OFFSET 0x10
-
-#define SSI_AUTOIDLE (1 << 0)
-#define SSI_SIDLE_SMARTIDLE(2 << 3)
-#define SSI_MIDLE_NOIDLE (1 << 12)
-
-/* Clk types requested by the dsp */
-#define IVA2_CLK 0
-#define GPT_CLK1
-#define WDT_CLK2
-#define MCBSP_CLK 3
-#define SSI_CLK4
-
-/* Bridge GPT id (1 - 4), DM Timer id (5 - 8) */
-#define DMT_ID(id) ((id) + 4)
-
-/* Bridge MCBSP id (6 - 10), OMAP Mcbsp id (0 - 4) */
-#define MCBSP_ID(id) ((id) - 6)
-
-static struct omap_dm_timer *timer[4];
-
-struct clk *iva2_clk;
-
-struct dsp_ssi {
- struct clk *sst_fck;
- struct clk *ssr_fck;
- struct clk *ick;
-};
-
-static struct dsp_ssi ssi;
-
-static u32 dsp_clocks;
-
-static inline u32 is_dsp_clk_active(u32 clk, u8 id)
-{
- return clk & (1 << id);
-}
-
-static inline void set_dsp_clk_active(u32 *clk, u8 id)
-{
- *clk |= (1 << id);
-}
-
-static inline void set_dsp_clk_inactive(u32 *clk, u8 id)
-{
- *clk &= ~(1 << id);
-}
-
-static s8 get_clk_type(u8 id)
-{
- s8 type;
-
- if (id == DSP_CLK_IVA2)
- type = IVA2_CLK;
- else if (id <= DSP_CLK_GPT8)
- type = GPT_CLK;
- else if (id == DSP_CLK_WDT3)
- type = WDT_CLK;
- else if (id <= DSP_CLK_MCBSP5)
- type = MCBSP_CLK;
- else if (id == DSP_CLK_SSI)
- type = SSI_CLK;
- else
-
[PATCH v2 08/19] DSPBRIDGE: trivial clock cleanup for unused code
Remove unusued struct and typedef.
Signed-off-by: Omar Ramirez Luna
---
arch/arm/plat-omap/include/dspbridge/clk.h |2 --
drivers/dsp/bridge/services/clk.c |7 ---
2 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/clk.h
b/arch/arm/plat-omap/include/dspbridge/clk.h
index 621d08f..f19d024 100644
--- a/arch/arm/plat-omap/include/dspbridge/clk.h
+++ b/arch/arm/plat-omap/include/dspbridge/clk.h
@@ -19,8 +19,6 @@
#ifndef _CLK_H
#define _CLK_H
- /* Generic TIMER object: */
-struct timer_object;
enum dsp_clk_id {
DSP_CLK_IVA2_CK = 0,
DSP_CLK_GPT5_FCK,
diff --git a/drivers/dsp/bridge/services/clk.c
b/drivers/dsp/bridge/services/clk.c
index e447d54..e35b929 100644
--- a/drivers/dsp/bridge/services/clk.c
+++ b/drivers/dsp/bridge/services/clk.c
@@ -32,8 +32,6 @@
/* --- Defines, Data Structures, Typedefs */
-typedef volatile unsigned long reg_uword32;
-
#define OMAP_SSI_OFFSET0x58000
#define OMAP_SSI_SIZE 0x1000
#define OMAP_SSI_SYSCONFIG_OFFSET 0x10
@@ -78,11 +76,6 @@ static struct dsp_clk_t dsp_clks[] = {
{NULL, ""}
};
-/* Generic TIMER object: */
-struct timer_object {
- struct timer_list timer;
-};
-
/*
* dsp_clk_exit
* Purpose:
--
1.6.2.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 v2 07/19] DSPBRIDGE: remove clk_get_use_cnt
Instead of querying the use count, balanced number of
enable/disable should be enforced across the system.
Signed-off-by: Omar Ramirez Luna
---
arch/arm/plat-omap/include/dspbridge/clk.h | 13 -
drivers/dsp/bridge/services/clk.c | 23 ---
2 files changed, 0 insertions(+), 36 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/clk.h
b/arch/arm/plat-omap/include/dspbridge/clk.h
index 5f7a925..621d08f 100644
--- a/arch/arm/plat-omap/include/dspbridge/clk.h
+++ b/arch/arm/plat-omap/include/dspbridge/clk.h
@@ -117,17 +117,4 @@ extern dsp_status dsp_clk_get_rate(IN enum dsp_clk_id
clk_id,
extern void ssi_clk_prepare(bool FLAG);
-/*
- * CLK_Get_RefCnt
- * Purpose:
- * get the reference count for the clock.
- * Parameters:
- * Returns:
- * s32:Reference Count for the clock.
- * -EPERM: Error occured while getting the reference count of a clock.
- * Requires:
- * Ensures:
- */
-extern s32 clk_get_use_cnt(IN enum dsp_clk_id clk_id);
-
#endif /* _SYNC_H */
diff --git a/drivers/dsp/bridge/services/clk.c
b/drivers/dsp/bridge/services/clk.c
index b4f5709..e447d54 100644
--- a/drivers/dsp/bridge/services/clk.c
+++ b/drivers/dsp/bridge/services/clk.c
@@ -179,20 +179,11 @@ dsp_status dsp_clk_disable(IN enum dsp_clk_id clk_id)
{
dsp_status status = DSP_SOK;
struct clk *clk_handle;
- s32 clk_use_cnt;
DBC_REQUIRE(clk_id < DSP_CLK_NOT_DEFINED);
clk_handle = dsp_clks[clk_id].clk_handle;
- clk_use_cnt = clk_get_use_cnt(clk_id);
- if (clk_use_cnt == -1) {
- pr_err("%s: failed to get CLK Use count for CLK %s, CLK dev id"
- " = %d\n", __func__, dsp_clks[clk_id].clk_name,
- dsp_clks[clk_id].id);
- } else if (clk_use_cnt == 0) {
- return status;
- }
if (clk_id == DSP_CLK_SSI_ICK)
ssi_clk_prepare(false);
@@ -226,20 +217,6 @@ dsp_status dsp_clk_get_rate(IN enum dsp_clk_id clk_id, u32
*speedKhz)
return status;
}
-s32 clk_get_use_cnt(IN enum dsp_clk_id clk_id)
-{
- struct clk *clk_handle;
- s32 use_count = -1;
- DBC_REQUIRE(clk_id < DSP_CLK_NOT_DEFINED);
-
- clk_handle = dsp_clks[clk_id].clk_handle;
-
- /* FIXME: usecount shouldn't be used */
- use_count = clk_handle->usecount;
-
- return use_count;
-}
-
void ssi_clk_prepare(bool FLAG)
{
void __iomem *ssi_base;
--
1.6.2.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 v2 01/19] DSPBRIDGE: remove clk_handle from drv interface
Since it is not used, remove.
Signed-off-by: Omar Ramirez Luna
---
drivers/dsp/bridge/rmgr/drv_interface.c |9 -
1 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
b/drivers/dsp/bridge/rmgr/drv_interface.c
index 2f92278..ea2a5f3 100644
--- a/drivers/dsp/bridge/rmgr/drv_interface.c
+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
@@ -149,7 +149,6 @@ static struct file_operations bridge_fops = {
#ifdef CONFIG_PM
static u32 time_out = 1000;
#ifdef CONFIG_BRIDGE_DVFS
-static struct clk *clk_handle;
s32 dsp_max_opps = VDD1_OPP5;
#endif
@@ -324,10 +323,6 @@ static int __devinit omap34_xx_bridge_probe(struct
platform_device *pdev)
for (i = 0; i < 6; i++)
pdata->mpu_speed[i] = vdd1_rate_table_bridge[i].rate;
- clk_handle = clk_get(NULL, "iva2_ck");
- if (!clk_handle)
- pr_err("%s: clk_get failed to get iva2_ck\n", __func__);
-
if (!cpufreq_register_notifier(&iva_clk_notifier,
CPUFREQ_TRANSITION_NOTIFIER))
pr_err("%s: clk_notifier_register failed for iva2_ck\n",
@@ -383,10 +378,6 @@ static int __devexit omap34_xx_bridge_remove(struct
platform_device *pdev)
driver_context = 0;
DBC_ASSERT(ret == true);
}
-#ifdef CONFIG_BRIDGE_DVFS
- clk_put(clk_handle);
- clk_handle = NULL;
-#endif /* #ifdef CONFIG_BRIDGE_DVFS */
func_cont:
mem_ext_phys_pool_release();
--
1.6.2.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 v2 02/19] DSPBRIDGE: fail if clk handle is NULL
If we fail if a clk handle is NULL during initialization
then there is no need to keep checking every time if the
handle is NULL for enable/disable/set_32k/get_use_cnt.
Signed-off-by: Omar Ramirez Luna
---
drivers/dsp/bridge/services/clk.c | 68 +++--
1 files changed, 20 insertions(+), 48 deletions(-)
diff --git a/drivers/dsp/bridge/services/clk.c
b/drivers/dsp/bridge/services/clk.c
index fb2ca81..1089e72 100644
--- a/drivers/dsp/bridge/services/clk.c
+++ b/drivers/dsp/bridge/services/clk.c
@@ -130,7 +130,7 @@ bool services_clk_init(void)
pr_err("%s: failed to get clk handle %s, dev id = %d\n",
__func__, services_clks[i].clk_name,
services_clks[i].id);
- /* should we fail here?? */
+ return false;
}
services_clks[i].clk_handle = clk_handle;
i++;
@@ -153,17 +153,11 @@ dsp_status services_clk_enable(IN enum services_clk_id
clk_id)
DBC_REQUIRE(clk_id < SERVICESCLK_NOT_DEFINED);
clk_handle = services_clks[clk_id].clk_handle;
- if (clk_handle) {
- if (clk_enable(clk_handle)) {
- pr_err("services_clk_enable: failed to Enable CLK %s, "
- "CLK dev id = %d\n",
- services_clks[clk_id].clk_name,
- services_clks[clk_id].id);
- status = -EPERM;
- }
- } else {
- pr_err("%s: failed to get CLK %s, CLK dev id = %d\n", __func__,
-services_clks[clk_id].clk_name, services_clks[clk_id].id);
+ if (clk_enable(clk_handle)) {
+ pr_err("services_clk_enable: failed to Enable CLK %s, "
+ "CLK dev id = %d\n",
+ services_clks[clk_id].clk_name,
+ services_clks[clk_id].id);
status = -EPERM;
}
/* The SSI module need to configured not to have the Forced idle for
@@ -193,13 +187,11 @@ dsp_status clk_set32k_hz(IN enum services_clk_id clk_id)
DBC_REQUIRE(clk_id < SERVICESCLK_NOT_DEFINED);
clk_handle = services_clks[clk_id].clk_handle;
- if (clk_handle) {
- if (!(clk_set_parent(clk_handle, clk_parent) == 0x0)) {
- pr_err("%s: failed for %s, dev id = %d\n", __func__,
- services_clks[clk_id].clk_name,
- services_clks[clk_id].id);
- status = -EPERM;
- }
+ if (!(clk_set_parent(clk_handle, clk_parent) == 0x0)) {
+ pr_err("%s: failed for %s, dev id = %d\n", __func__,
+ services_clks[clk_id].clk_name,
+ services_clks[clk_id].id);
+ status = -EPERM;
}
return status;
}
@@ -231,15 +223,8 @@ dsp_status services_clk_disable(IN enum services_clk_id
clk_id)
if (clk_id == SERVICESCLK_SSI_ICK)
ssi_clk_prepare(false);
- if (clk_handle) {
- clk_disable(clk_handle);
- } else {
- pr_err("services_clk_disable: failed to get CLK %s,"
- "CLK dev id = %d\n",
- services_clks[clk_id].clk_name,
- services_clks[clk_id].id);
- status = -EPERM;
- }
+ clk_disable(clk_handle);
+
return status;
}
@@ -260,38 +245,25 @@ dsp_status services_clk_get_rate(IN enum services_clk_id
clk_id, u32 *speedKhz)
*speedKhz = 0x0;
clk_handle = services_clks[clk_id].clk_handle;
- if (clk_handle) {
- clk_speed_hz = clk_get_rate(clk_handle);
- *speedKhz = clk_speed_hz / 1000;
- dev_dbg(bridge, "%s: clk_speed_hz = %d, speedinKhz = %d\n",
+ clk_speed_hz = clk_get_rate(clk_handle);
+ *speedKhz = clk_speed_hz / 1000;
+ dev_dbg(bridge, "%s: clk_speed_hz = %d, speedinKhz = %d\n",
__func__, clk_speed_hz, *speedKhz);
- } else {
- pr_err("%s: failed to get %s, dev Id = %d\n", __func__,
- services_clks[clk_id].clk_name,
- services_clks[clk_id].id);
- status = -EPERM;
- }
+
return status;
}
s32 clk_get_use_cnt(IN enum services_clk_id clk_id)
{
- dsp_status status = DSP_SOK;
struct clk *clk_handle;
s32 use_count = -1;
DBC_REQUIRE(clk_id < SERVICESCLK_NOT_DEFINED);
clk_handle = services_clks[clk_id].clk_handle;
- if (clk_handle) {
- /* FIXME: usecount shouldn't be used */
- use_count = clk_handle->usecount;
- } else {
- pr_err("%s: failed to get %s, dev Id = %d\n", __func__,
- services_clks[clk_id].clk_name,
- services_clk
[PATCH v2 06/19] DSPBRIDGE: remove function clk_set32k_hz
This is only used for GPTs and should be addressed once
those clocks are requested using DM timer framework.
This patch might break functionality.
Signed-off-by: Omar Ramirez Luna
---
arch/arm/plat-omap/include/dspbridge/clk.h | 14 +-
drivers/dsp/bridge/services/clk.c | 26 --
drivers/dsp/bridge/wmd/tiomap3430.c| 15 ---
3 files changed, 1 insertions(+), 54 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/clk.h
b/arch/arm/plat-omap/include/dspbridge/clk.h
index 2a43aab..5f7a925 100644
--- a/arch/arm/plat-omap/include/dspbridge/clk.h
+++ b/arch/arm/plat-omap/include/dspbridge/clk.h
@@ -45,7 +45,6 @@ enum dsp_clk_id {
DSP_CLK_MCBSP5_ICK,
DSP_CLK_SSI_FCK,
DSP_CLK_SSI_ICK,
- DSP_CLK_SYS32K_CK,
DSP_CLK_NOT_DEFINED
};
@@ -115,18 +114,7 @@ extern dsp_status dsp_clk_disable(IN enum dsp_clk_id
clk_id);
*/
extern dsp_status dsp_clk_get_rate(IN enum dsp_clk_id clk_id,
u32 *speedMhz);
-/*
- * clk_set32k_hz
- * Purpose:
- * Set the requested clock to 32KHz.
- * Parameters:
- * Returns:
- * DSP_SOK:Success.
- * -EPERM: Error occured while setting the clock parent to 32KHz.
- * Requires:
- * Ensures:
- */
-extern dsp_status clk_set32k_hz(IN enum dsp_clk_id clk_id);
+
extern void ssi_clk_prepare(bool FLAG);
/*
diff --git a/drivers/dsp/bridge/services/clk.c
b/drivers/dsp/bridge/services/clk.c
index 23d4346..b4f5709 100644
--- a/drivers/dsp/bridge/services/clk.c
+++ b/drivers/dsp/bridge/services/clk.c
@@ -75,7 +75,6 @@ static struct dsp_clk_t dsp_clks[] = {
{NULL, "mcbsp_ick", 5},
{NULL, "ssi_ssr_sst_fck", -1},
{NULL, "ssi_ick", -1},
- {NULL, "omap_32k_fck", -1},
{NULL, ""}
};
@@ -171,31 +170,6 @@ dsp_status dsp_clk_enable(IN enum dsp_clk_id clk_id)
}
/*
- * clk_set32k_hz
- * Purpose:
- * To Set parent of a clock to 32KHz.
- */
-
-dsp_status clk_set32k_hz(IN enum dsp_clk_id clk_id)
-{
- dsp_status status = DSP_SOK;
- struct clk *clk_handle;
- struct clk *clk_parent;
- clk_parent = dsp_clks[DSP_CLK_SYS32K_CK].clk_handle;
-
- DBC_REQUIRE(clk_id < DSP_CLK_NOT_DEFINED);
-
- clk_handle = dsp_clks[clk_id].clk_handle;
- if (!(clk_set_parent(clk_handle, clk_parent) == 0x0)) {
- pr_err("%s: failed for %s, dev id = %d\n", __func__,
- dsp_clks[clk_id].clk_name,
- dsp_clks[clk_id].id);
- status = -EPERM;
- }
- return status;
-}
-
-/*
* dsp_clk_disable
* Purpose:
* Disable the clock.
diff --git a/drivers/dsp/bridge/wmd/tiomap3430.c
b/drivers/dsp/bridge/wmd/tiomap3430.c
index 896941c..52ec3bc 100644
--- a/drivers/dsp/bridge/wmd/tiomap3430.c
+++ b/drivers/dsp/bridge/wmd/tiomap3430.c
@@ -543,13 +543,6 @@ static dsp_status bridge_brd_start(struct wmd_dev_context
*hDevContext,
}
}
- if (clk_id_index < MBX_PM_MAX_RESOURCES) {
- status =
- clk_set32k_hz(bpwr_clks
- [clk_id_index].fun_clk);
- } else {
- status = -EPERM;
- }
clk_cmd = (BPWR_ENABLE_CLOCK << MBX_PM_CLK_CMDSHIFT) |
ul_load_monitor_timer;
@@ -578,14 +571,6 @@ static dsp_status bridge_brd_start(struct wmd_dev_context
*hDevContext,
}
}
- if (clk_id_index < MBX_PM_MAX_RESOURCES) {
- status =
- clk_set32k_hz(bpwr_clks
- [clk_id_index].fun_clk);
- } else {
- status = -EPERM;
- }
-
clk_cmd = (BPWR_ENABLE_CLOCK << MBX_PM_CLK_CMDSHIFT) |
ul_bios_gp_timer;
--
1.6.2.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
Bug in omap2_nand_gpmc_retime? (was: Re: [PATCH] OMAP: fix gpmc nand setup when no timings supplied)
Tony Lindgren wrote: * Mike Rapoport [100427 00:40]: Tony Lindgren wrote: * Mike Rapoport [100422 01:41]: Ghorai, Sukumar wrote: CM-T35, for instance can be assembled with different NAND flash chips. Besides, boards that use NAND as primary boot device, we anyway depend on proper GPMC configuration in the bootloader chain. Having ability to define GPMC timings in the kernel and keep the settings made by the bootloader adds flexibility level for board designers. Not implementing the retime function for GPMC will cause issues with PM as you cannot scale the L3 frequency without breaking your GPMC timings. I agree that without retime function scaling the frequency will break the GPMC timings. But my point was that there should be an _option_ to keep the timings defined by the bootloader rather than enforce board files to specify timings. Sure. Can you please check one more time your patch and what is still missing after Stanley's fix? That's now in omap-fixes and master branches as commit 11e1ef2d105900a302b7ca92bcaf96a96d0274a1. Since skipping the retime function will break gpmc timings in PM-enabled kernel, we need to implement this option in smarter way. E.g. something like: Yeah we should print some warning if the retime function is not implemented as it can cause mysterious bugs later on. I guess implementing a dummy retime function would be best as then the warning would be related to the actual L3 rate change. While working on implementation of gpmc_nand_detect_timings I've seen that omap2_nand_gpmc_retime converts the timings supplied by the platform to ticks and passes it to gpmc_cs_set_timings which in turn converts the timings to ticks. Is it a bug or am I missing something? Regards, Tony -- Sincerely yours, Mike. -- 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] OMAP3: I2C: Clean up Errata 1p153 handling
Clean up existing Errata 1p153 handling to use generic
errata handling mechanism through dev flag.
Signed-off-by: Manjunatha GK
Cc: linux-...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: ben-li...@fluff.org
Cc: Tony Lindgren
Cc: Nishanth Menon
Cc: Alexander Shishkin
---
PS : This patch has dependency on the patch:
https://patchwork.kernel.org/patch/95616/
drivers/i2c/busses/i2c-omap.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 5f5207e..0caa8fe 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -168,6 +168,7 @@ enum {
/* Errata definitions */
#define I2C_OMAP_ERRATA_I207 (1 << 0)
+#define I2C_OMAP3_1P153(1 << 1)
struct omap_i2c_dev {
struct device *dev;
@@ -946,7 +947,7 @@ complete:
break;
}
- if ((dev->rev <= OMAP_I2C_REV_ON_3430) &&
+ if ((dev->errata & I2C_OMAP3_1P153) &&
errata_omap3_1p153(dev, &stat, &err))
goto complete;
@@ -1049,6 +1050,9 @@ omap_i2c_probe(struct platform_device *pdev)
dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) & 0xff;
+ if (dev->rev <= OMAP_I2C_REV_ON_3430)
+ dev->errata |= I2C_OMAP3_1P153;
+
if (!(cpu_class_is_omap1() || cpu_is_omap2420())) {
u16 s;
--
1.6.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_musb_board_data -- trouble specifying 500mA supply
Hi,
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Cliff Brake
> Sent: Wednesday, April 28, 2010 7:40 PM
> To: Linux OMAP Users
> Subject: omap_musb_board_data -- trouble specifying 500mA supply
>
> Hello,
>
> We are designing a custom OMAP board that will have a 500mA supply on
> the OTG port. It looks like the power is set with:
>
> struct omap_musb_board_data {
> u8 interface_type;
> u8 mode;
> u8 power;
> };
>
> However, with a u8, the max value is 255. Should power be changed to a
> u16?
There is already a fix submitted and is available at Greg's queue,
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/usb.current/musb-fix-power-field-to-hold-all-possible-values.patch
Ajay
>
> Thanks,
> Cliff
> --
> 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
--
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_musb_board_data -- trouble specifying 500mA supply
Hi,
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Cliff Brake
> Sent: Wednesday, April 28, 2010 7:40 PM
> To: Linux OMAP Users
> Subject: omap_musb_board_data -- trouble specifying 500mA supply
>
> Hello,
>
> We are designing a custom OMAP board that will have a 500mA supply on
> the OTG port. It looks like the power is set with:
>
> struct omap_musb_board_data {
> u8 interface_type;
> u8 mode;
> u8 power;
> };
>
> However, with a u8, the max value is 255. Should power be changed to a
> u16?
There is already a fix submitted and is available in Greg's queue below,
>
> Thanks,
> Cliff
> --
> 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
--
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] OMAP3630: Update ES1.1 silicon revision detection
This patch updates ES1.1 silicon revision ID for OMAP3630
processor. The silicon revision can be read by reading hawkeye
and revision bits in IDCODE register.
Tested on 3630sdp(with ES1.1 silicon) and Zoom3(with ES1.0) silicon.
Signed-off-by: Manjunatha GK
Cc: Nishanth Menon
Cc: Tony Lindgren
---
arch/arm/mach-omap2/id.c | 20
arch/arm/plat-omap/include/plat/cpu.h |3 +++
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 37b8a1a..dd26092 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -259,11 +259,20 @@ void __init omap3_check_revision(void)
omap_chip.oc |= CHIP_IS_OMAP3430ES3_1;
break;
case 0xb891:
- /* FALLTHROUGH */
- default:
- /* Unknown default to latest silicon rev as default*/
- omap_revision = OMAP3630_REV_ES1_0;
+ /* Handle 36xx devices */
omap_chip.oc |= CHIP_IS_OMAP3630ES1;
+
+ switch(rev) {
+ case 0: /* Take care of early samples */
+ omap_revision = OMAP3630_REV_ES1_0;
+ break;
+ case 1:
+ /* Fall through */
+ default:
+ /* Use the latest known revision as default */
+ omap_revision = OMAP3630_REV_ES1_1;
+ omap_chip.oc |= CHIP_IS_OMAP3630ES1_1;
+ }
}
}
@@ -339,6 +348,9 @@ void __init omap3_cpuinfo(void)
case OMAP_REVBITS_00:
strcpy(cpu_rev, "1.0");
break;
+ case OMAP_REVBITS_01:
+ strcpy(cpu_rev, "1.1");
+ break;
case OMAP_REVBITS_10:
strcpy(cpu_rev, "2.0");
break;
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 7514174..04c7baa 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -66,6 +66,7 @@ unsigned int omap_rev(void);
* family. This difference can be handled separately.
*/
#define OMAP_REVBITS_000x00
+#define OMAP_REVBITS_010x01
#define OMAP_REVBITS_100x10
#define OMAP_REVBITS_200x20
#define OMAP_REVBITS_300x30
@@ -376,6 +377,7 @@ IS_OMAP_TYPE(3517, 0x3517)
#define OMAP3430_REV_ES3_1_2 0x34305034
#define OMAP3630_REV_ES1_0 0x36300034
+#define OMAP3630_REV_ES1_1 0x36300134
#define OMAP35XX_CLASS 0x3534
#define OMAP3503_REV(v)(OMAP35XX_CLASS | (0x3503 << 16) | (v
<< 8))
@@ -411,6 +413,7 @@ IS_OMAP_TYPE(3517, 0x3517)
#define CHIP_IS_OMAP3430ES3_1 (1 << 6)
#define CHIP_IS_OMAP3630ES1(1 << 7)
#define CHIP_IS_OMAP4430ES1(1 << 8)
+#define CHIP_IS_OMAP3630ES1_1 (1 << 9)
#define CHIP_IS_OMAP24XX (CHIP_IS_OMAP2420 | CHIP_IS_OMAP2430)
--
1.6.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 2/2] crypto: omap-sham - omap sha1 & md5 driver
Earlier kernel contained omap sha1 and md5 driver, which was not maintained,
was not ported to new crypto APIs and removed from the source tree.
- implements async crypto API using dma and cpu.
- supports multiple sham instances if available
- hmac
- concurrent requests
Signed-off-by: Dmitry Kasatkin
---
drivers/crypto/Kconfig |9 +
drivers/crypto/Makefile|2 +
drivers/crypto/omap-sham.c | 1259
3 files changed, 1270 insertions(+), 0 deletions(-)
create mode 100644 drivers/crypto/omap-sham.c
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index b08403d..9073aa0 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -222,4 +222,13 @@ config CRYPTO_DEV_PPC4XX
help
This option allows you to have support for AMCC crypto acceleration.
+config CRYPTO_DEV_OMAP_SHAM
+ tristate "Support for OMAP SHA1/MD5 hw accelerator"
+ depends on ARCH_OMAP2 || ARCH_OMAP3
+ select CRYPTO_SHA1
+ select CRYPTO_MD5
+ help
+ OMAP processors have SHA1/MD5 hw accelerator. Select this if you
+ want to use the OMAP module for SHA1/MD5 algorithms.
+
endif # CRYPTO_HW
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 6ffcb3f..c9494e1 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -6,3 +6,5 @@ obj-$(CONFIG_CRYPTO_DEV_MV_CESA) += mv_cesa.o
obj-$(CONFIG_CRYPTO_DEV_TALITOS) += talitos.o
obj-$(CONFIG_CRYPTO_DEV_IXP4XX) += ixp4xx_crypto.o
obj-$(CONFIG_CRYPTO_DEV_PPC4XX) += amcc/
+obj-$(CONFIG_CRYPTO_DEV_OMAP_SHAM) += omap-sham.o
+
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
new file mode 100644
index 000..8b03433
--- /dev/null
+++ b/drivers/crypto/omap-sham.c
@@ -0,0 +1,1259 @@
+/*
+ * Cryptographic API.
+ *
+ * Support for OMAP SHA1/MD5 HW acceleration.
+ *
+ * Copyright (c) 2010 Nokia Corporation
+ * Author: Dmitry Kasatkin
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ *
+ * Some ideas are from old omap-sha1-md5.c driver.
+ */
+
+#define pr_fmt(fmt) "%s: " fmt, __func__
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#define SHA_REG_DIGEST(x) (0x00 + ((x) * 0x04))
+#define SHA_REG_DIN(x) (0x1C + ((x) * 0x04))
+
+#define SHA1_MD5_BLOCK_SIZESHA1_BLOCK_SIZE
+#define MD5_DIGEST_SIZE16
+
+#define SHA_REG_DIGCNT 0x14
+
+#define SHA_REG_CTRL 0x18
+#define SHA_REG_CTRL_LENGTH(0x << 5)
+#define SHA_REG_CTRL_CLOSE_HASH(1 << 4)
+#define SHA_REG_CTRL_ALGO_CONST(1 << 3)
+#define SHA_REG_CTRL_ALGO (1 << 2)
+#define SHA_REG_CTRL_INPUT_READY (1 << 1)
+#define SHA_REG_CTRL_OUTPUT_READY (1 << 0)
+
+#define SHA_REG_REV0x5C
+#define SHA_REG_REV_MAJOR 0xF0
+#define SHA_REG_REV_MINOR 0x0F
+
+#define SHA_REG_MASK 0x60
+#define SHA_REG_MASK_DMA_EN(1 << 3)
+#define SHA_REG_MASK_IT_EN (1 << 2)
+#define SHA_REG_MASK_SOFTRESET (1 << 1)
+#define SHA_REG_AUTOIDLE (1 << 0)
+
+#define SHA_REG_SYSSTATUS 0x64
+#define SHA_REG_SYSSTATUS_RESETDONE(1 << 0)
+
+#define DEFAULT_TIMEOUT_INTERVAL HZ
+
+#define FLAGS_FIRST0x0001
+#define FLAGS_FINUP0x0002
+#define FLAGS_FINAL0x0004
+#define FLAGS_FAST 0x0008
+#define FLAGS_SHA1 0x0010
+#define FLAGS_DMA_ACTIVE 0x0020
+#define FLAGS_OUTPUT_READY 0x0040
+#define FLAGS_CLEAN0x0080
+#define FLAGS_INIT 0x0100
+#define FLAGS_CPU 0x0200
+#define FLAGS_HMAC 0x0400
+
+/* 3rd byte */
+#define FLAGS_BUSY 16
+
+#define OP_UPDATE 1
+#define OP_FINAL 2
+
+struct omap_sham_dev;
+
+struct omap_sham_reqctx {
+ struct omap_sham_dev*dd;
+ unsigned long flags;
+ unsigned long op;
+
+ size_t digcnt;
+ u8 *buffer;
+ size_t bufcnt;
+ size_t buflen;
+ dma_addr_t dma_addr;
+
+ /* walk state */
+ struct scatterlist *sg;
+ unsigned intoffset; /* offset in current sg */
+ unsigned inttotal; /* total request */
+};
+
+struct omap_sham_hmac_ctx {
+ struct crypto_shash *shash;
+ u8 ipad[SHA1_MD5_BLOCK_SIZE];
+ u8 opad[SHA1_MD5_BLOCK_SIZE];
+};
+
+
[PATCHv4 0/2] omap-sham: OMAP SHA1/MD5 driver
Changes to v4: - concurrent requests support via queue - hmac - shash support removed Dmitry Kasatkin (2): crypto: updates omap sham device related platform code crypto: omap-sham - omap sha1 & md5 driver arch/arm/mach-omap2/clock2420_data.c |2 +- arch/arm/mach-omap2/clock2430_data.c |2 +- arch/arm/mach-omap2/clock3xxx_data.c |2 +- arch/arm/mach-omap2/devices.c | 58 ++- arch/arm/plat-omap/include/plat/omap34xx.h |5 + drivers/crypto/Kconfig |9 + drivers/crypto/Makefile|2 + drivers/crypto/omap-sham.c | 1259 8 files changed, 1326 insertions(+), 13 deletions(-) create mode 100644 drivers/crypto/omap-sham.c -- 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 1/2] crypto: updates omap sham device related platform code
- registration with multi OMAP kernels support
- clocks
Signed-off-by: Dmitry Kasatkin
---
arch/arm/mach-omap2/clock2420_data.c |2 +-
arch/arm/mach-omap2/clock2430_data.c |2 +-
arch/arm/mach-omap2/clock3xxx_data.c |2 +-
arch/arm/mach-omap2/devices.c | 58 +++-
arch/arm/plat-omap/include/plat/omap34xx.h |5 ++
5 files changed, 56 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index d932b14..1820a55 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1836,7 +1836,7 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, "vlynq_ick",&vlynq_ick, CK_242X),
CLK(NULL, "vlynq_fck",&vlynq_fck, CK_242X),
CLK(NULL, "des_ick", &des_ick, CK_242X),
- CLK(NULL, "sha_ick", &sha_ick, CK_242X),
+ CLK("omap-sham","ick", &sha_ick, CK_242X),
CLK("omap_rng", "ick", &rng_ick, CK_242X),
CLK(NULL, "aes_ick", &aes_ick, CK_242X),
CLK(NULL, "pka_ick", &pka_ick, CK_242X),
diff --git a/arch/arm/mach-omap2/clock2430_data.c
b/arch/arm/mach-omap2/clock2430_data.c
index 0438b6e..5884ac6 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1924,7 +1924,7 @@ static struct omap_clk omap2430_clks[] = {
CLK(NULL, "sdma_ick", &sdma_ick, CK_243X),
CLK(NULL, "sdrc_ick", &sdrc_ick, CK_243X),
CLK(NULL, "des_ick", &des_ick, CK_243X),
- CLK(NULL, "sha_ick", &sha_ick, CK_243X),
+ CLK("omap-sham","ick", &sha_ick, CK_243X),
CLK("omap_rng", "ick", &rng_ick, CK_243X),
CLK(NULL, "aes_ick", &aes_ick, CK_243X),
CLK(NULL, "pka_ick", &pka_ick, CK_243X),
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 9cba556..52638df 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3360,7 +3360,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK("mmci-omap-hs.2", "ick", &mmchs3_ick,CK_3430ES2 | CK_AM35XX),
CLK(NULL, "icr_ick", &icr_ick, CK_343X),
CLK(NULL, "aes2_ick", &aes2_ick, CK_343X),
- CLK(NULL, "sha12_ick",&sha12_ick, CK_343X),
+ CLK("omap-sham","ick", &sha12_ick, CK_343X),
CLK(NULL, "des2_ick", &des2_ick, CK_343X),
CLK("mmci-omap-hs.1", "ick", &mmchs2_ick,CK_3XXX),
CLK("mmci-omap-hs.0", "ick", &mmchs1_ick,CK_3XXX),
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 2271b9b..beac46c 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include "mux.h"
@@ -453,8 +454,10 @@ static void omap_init_mcspi(void)
static inline void omap_init_mcspi(void) {}
#endif
-#ifdef CONFIG_OMAP_SHA1_MD5
-static struct resource sha1_md5_resources[] = {
+#if defined(CONFIG_CRYPTO_DEV_OMAP_SHAM) ||
defined(CONFIG_CRYPTO_DEV_OMAP_SHAM_MODULE)
+
+#ifdef CONFIG_ARCH_OMAP24XX
+static struct resource omap2_sham_resources[] = {
{
.start = OMAP24XX_SEC_SHA1MD5_BASE,
.end= OMAP24XX_SEC_SHA1MD5_BASE + 0x64,
@@ -465,20 +468,55 @@ static struct resource sha1_md5_resources[] = {
.flags = IORESOURCE_IRQ,
}
};
+static int omap2_sham_resources_sz = ARRAY_SIZE(omap2_sham_resources);
+#else
+#define omap2_sham_resources NULL
+#define omap2_sham_resources_sz0
+#endif
-static struct platform_device sha1_md5_device = {
- .name = "OMAP SHA1/MD5",
+#ifdef CONFIG_ARCH_OMAP34XX
+static struct resource omap3_sham_resources[] = {
+ {
+ .start = OMAP34XX_SEC_SHA1MD5_BASE,
+ .end= OMAP34XX_SEC_SHA1MD5_BASE + 0x64,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = INT_34XX_SHA1MD52_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = OMAP34XX_DMA_SHA1MD5_RX,
+ .flags = IORESOURCE_DMA,
+ }
+};
+static int omap3_sham_resources_sz = ARRAY_SIZE(omap3_sham_resources);
+#else
+#define omap3_sham_resources NULL
+#define omap3_sham_resources_sz0
+#endif
+
+static struct platform_device sham_device = {
+ .name = "omap-sham",
.id = -1,
- .num_resources = ARRAY_SIZE(sha1_md5_resources),
- .resource = sha1_md5_resources,
};
-static void omap_init_sha1_md5(void)
+static void omap_init_sham(void)
{
- platform_device_reg
Re: [PATCH v6] OMAP2/3: I2C: Errata ID i207: Clear wrong RDR interrupt
Nishanth Menon writes:
> very minor comments below:
> On 04/28/2010 12:47 AM, G, Manjunath Kondaiah wrote:
[...]
>> struct omap_i2c_dev {
>> struct device *dev;
>> @@ -199,6 +201,7 @@ struct omap_i2c_dev {
>> u16 bufstate;
>> u16 syscstate;
>> u16 westate;
>> +u16 errata;
> overall I'd prefer the term quirk over errata - quirk is more of a
> standard linux term used accross network, usb and other drivers, will
> allow the code to be a little more familiar with the upstream
> maintainers/reviewers.. but i leave it to tony and others to comment
> more.. maybe it is just me being an ass again ;)
I prefer the term errata since it is also the term used by TI docs.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] DSPBRIDGE: use dm timer framework for gpt timers
On 4/28/2010 2:46 AM, Felipe Contreras wrote: On Wed, Apr 28, 2010 at 4:29 AM, Omar Ramirez Luna wrote: This patch switches to use DM timer framework instead of a custom one for GPT timers, currently dsp can make use of gpt 5, 6, 7 or 8. I heard someone that was using gpt 8 for something else. Is it possible to configure dsp-bridge to not use it? There are two scenarios: 1. The request comes from the DSP side (afaik for video use case), the change should be in the DSP side binaries to request some other gpt instead. I don't know how possible is to get this changed. 2. bridge driver also requests gpt8 whenever a mmu fault is triggered, this to set a timer to interrupt the dsp after the mmu fault dump has been finished, I think this can be easily replaced in bridge to use some other gpt, but "1" is still there. (besides a new patch is needed to remove direct access to dm timer inside ue_deh and make it to go through dsp-clock) Regards, omar -- 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
omap_musb_board_data -- trouble specifying 500mA supply
Hello,
We are designing a custom OMAP board that will have a 500mA supply on
the OTG port. It looks like the power is set with:
struct omap_musb_board_data {
u8 interface_type;
u8 mode;
u8 power;
};
However, with a u8, the max value is 255. Should power be changed to a u16?
Thanks,
Cliff
--
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 v2] generic clk module removal
On 4/27/2010 8:34 PM, Nishanth Menon wrote: On 04/27/2010 08:29 PM, Omar Ramirez Luna wrote: This set of patches remove clk module from the services layer. Now: - GPT 5-8 are controlled through DM Timer framework. - MCBSP clocks are enabled by requesting the proper mcbsp device. - WDT is left for bridge driver to control rather than on request from dsp. - SSI is controlled by enabling/disabling its sst, ssr and ick clocks. v2: - rebased - keep iva2 handling as it is advised to turn off the clocks for iva reset sources. - release all the clocks (disable& free) if driver is uninstalled. [...] is there a series numbering for this patchset? wrong sed substitution command to place "v2" :/ I will resend. - omar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] [I2C]pass scll, sclh through board file for Errata i585
Krishnamoorthy, Balaji T had written, on 04/28/2010 07:34 AM, the following:
From: Tony Lindgren [mailto:t...@atomide.com]
* balaj...@ti.com [100419 07:59]:
From: Balaji T K
Errata ID: i535 - I2C1 to 3 SCL low period is shorter in FS mode
Due to IO cell influence, I2C1 to 3 SCL low period can be shorter than
expected.
As a result, I2C AC timing (SCL minimum low period) in FS mode may not meet
the timing configured by software.
I2C1 to 3, SCL low period is programmable and proper adjustments
to the SCLL/HSSCLL values can avoid the issue.
This patch provides flexibility to control tLOW, tHIGH for different boards.
scll, sclh values are to be provide in board data
for differents modes (standard, fast and high speed mode)
as the scl rate (I2C bus speed) can be changed by bootargs.
If scll, sclh values are not provided, scll and sclh values will be computed
for duty cycle tHIGH:tLOW of 1:2 (for HS, FS) and 1:1 for Standard as before
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -594,6 +594,26 @@ static struct twl4030_platform_data sdp3430_twldata = {
.vpll2 = &sdp3430_vpll2,
};
+static struct omap_i2c_scl_data __initdata sdp3430_i2c1_scl_data = {
+ .rate = 2600,
+ .standard_scll = 20, /* For 100Khz */
+ .standard_sclh = 20, /* For 100Khz */
Scll and sclh calculation for other than omap1 and omap2420
from the given formula
fsscll = internal_clk / (dev->speed * 2);
fssclh = internal_clk / (dev->speed * 2);
where internal_clk is 4000KHz, dev-speed is 100Khz
and the assumption is 1:1 duty cycle, 50%tHIGH, 50%tLOW
ref: http://marc.info/?t=12354086592&r=1&w=2
tHigh and tLow are dependent of i2c bus capacitance as well.. TRM says:
The equations in Table 17-12 give the SCL timing values for
SCLL/SCLH/HSSCLL/HSSCLH at HS I2C controller outputs. Actual tlow and
thigh periods may vary, depending on the board (the load capacitance on
the SCL signal). If necessary, any adjustments to the
SCLL/SCLH/HSSCLL/HSSCLH values must be determined by measurements of
actual SCL signal on the board...
so it is imperative that we provide some mechanism to provide
a) an autoconfiguration using the standard equation as in TRM
b) boards with different bus capacitance (less or more), should be able
to define their own values.
This patch is in the direction to provide us that flexibility, which
IMHO is necessary.
+ .fast_mode_scll = 16, /* For 400Khz */
+ .fast_mode_sclh = 8,/* For 400Khz */
scl = internal_clk / dev->speed;
fsscll = scl - (scl / 3);
fssclh = (scl / 3);
internal_clk is 9600, dev->speed =400
and the assumption is 1:2 duty cycle, 33%tHIGH, 66%tLOW
+ .hs_phase1_scll = 32, /* For 2600Khz */
+ .hs_phase1_sclh = 16, /* For 2600Khz */
fsscll = scl - (scl / 3);
fssclh = (scl / 3);
internal_clk is 19200, dev->speed =400
+ .hs_phase2_scll = 24, /* For 2600Khz */
+ .hs_phase2_sclh = 12, /* For 2600Khz */
scl = fclk_rate / dev->speed;
hsscll = scl - (scl / 3);
hssclh = (scl / 3);
fclk_rate is 96000, dev->speed is 2600
and the assumption is 1:2 duty cycle, 33%tHIGH, 66%tLOW
+};
Can you please describe how you get these values for each board-*.c file?
Internal_clk is initialized to predefined value of 4000Khz, 9600, 19200
depending on i2c bus speed of 100, 400, or >400.
However fclk_rate varies between omap and needs to be determined by debug printk
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -70,14 +70,14 @@ static struct resource i2c_resources[][2] = {
}, \
}
-static u32 i2c_rate[ARRAY_SIZE(i2c_resources)];
+static struct omap_i2c_platform_data i2c_pdata[ARRAY_SIZE(i2c_resources)];
static struct platform_device omap_i2c_devices[] = {
- I2C_DEV_BUILDER(1, i2c_resources[0], &i2c_rate[0]),
+ I2C_DEV_BUILDER(1, i2c_resources[0], &i2c_pdata[0]),
#ifdefined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
- I2C_DEV_BUILDER(2, i2c_resources[1], &i2c_rate[1]),
+ I2C_DEV_BUILDER(2, i2c_resources[1], &i2c_pdata[1]),
#endif
#ifdefined(CONFIG_ARCH_OMAP3)
- I2C_DEV_BUILDER(3, i2c_resources[2], &i2c_rate[2]),
+ I2C_DEV_BUILDER(3, i2c_resources[2], &i2c_pdata[2]),
#endif
};
@@ -146,8 +146,8 @@ static int __init omap_i2c_bus_setup(char *str)
get_options(str, 3, ints);
if (ints[0] < 2 || ints[1] < 1 || ints[1] > ports)
return 0;
- i2c_rate[ints[1] - 1] = ints[2];
- i2c_rate[ints[1] - 1] |= OMAP_I2C_CMDLINE_SETUP;
+ i2c_pdata[ints[1] - 1].rate = ints[2];
+ i2c_pdata[ints[1] - 1].rate
RE: [RFC][PATCH] [I2C]pass scll, sclh through board file for Errata i585
> From: Tony Lindgren [mailto:t...@atomide.com]
> * balaj...@ti.com [100419 07:59]:
> > From: Balaji T K
> >
> > Errata ID: i535 - I2C1 to 3 SCL low period is shorter in FS mode
> > Due to IO cell influence, I2C1 to 3 SCL low period can be shorter than
> expected.
> > As a result, I2C AC timing (SCL minimum low period) in FS mode may not meet
> > the timing configured by software.
> >
> > I2C1 to 3, SCL low period is programmable and proper adjustments
> > to the SCLL/HSSCLL values can avoid the issue.
> >
> > This patch provides flexibility to control tLOW, tHIGH for different boards.
> > scll, sclh values are to be provide in board data
> > for differents modes (standard, fast and high speed mode)
> > as the scl rate (I2C bus speed) can be changed by bootargs.
> >
> > If scll, sclh values are not provided, scll and sclh values will be computed
> > for duty cycle tHIGH:tLOW of 1:2 (for HS, FS) and 1:1 for Standard as before
>
>
>
> > --- a/arch/arm/mach-omap2/board-3430sdp.c
> > +++ b/arch/arm/mach-omap2/board-3430sdp.c
> > @@ -594,6 +594,26 @@ static struct twl4030_platform_data sdp3430_twldata = {
> > .vpll2 = &sdp3430_vpll2,
> > };
> >
> > +static struct omap_i2c_scl_data __initdata sdp3430_i2c1_scl_data = {
> > + .rate = 2600,
> > + .standard_scll = 20, /* For 100Khz */
> > + .standard_sclh = 20, /* For 100Khz */
Scll and sclh calculation for other than omap1 and omap2420
from the given formula
fsscll = internal_clk / (dev->speed * 2);
fssclh = internal_clk / (dev->speed * 2);
where internal_clk is 4000KHz, dev-speed is 100Khz
and the assumption is 1:1 duty cycle, 50%tHIGH, 50%tLOW
> > + .fast_mode_scll = 16, /* For 400Khz */
> > + .fast_mode_sclh = 8,/* For 400Khz */
scl = internal_clk / dev->speed;
fsscll = scl - (scl / 3);
fssclh = (scl / 3);
internal_clk is 9600, dev->speed =400
and the assumption is 1:2 duty cycle, 33%tHIGH, 66%tLOW
> > + .hs_phase1_scll = 32, /* For 2600Khz */
> > + .hs_phase1_sclh = 16, /* For 2600Khz */
fsscll = scl - (scl / 3);
fssclh = (scl / 3);
internal_clk is 19200, dev->speed =400
> > + .hs_phase2_scll = 24, /* For 2600Khz */
> > + .hs_phase2_sclh = 12, /* For 2600Khz */
scl = fclk_rate / dev->speed;
hsscll = scl - (scl / 3);
hssclh = (scl / 3);
fclk_rate is 96000, dev->speed is 2600
and the assumption is 1:2 duty cycle, 33%tHIGH, 66%tLOW
> > +};
>
> Can you please describe how you get these values for each board-*.c file?
Internal_clk is initialized to predefined value of 4000Khz, 9600, 19200
depending on i2c bus speed of 100, 400, or >400.
However fclk_rate varies between omap and needs to be determined by debug printk
>
> > --- a/arch/arm/plat-omap/i2c.c
> > +++ b/arch/arm/plat-omap/i2c.c
> > @@ -70,14 +70,14 @@ static struct resource i2c_resources[][2] = {
> > }, \
> > }
> >
> > -static u32 i2c_rate[ARRAY_SIZE(i2c_resources)];
> > +static struct omap_i2c_platform_data i2c_pdata[ARRAY_SIZE(i2c_resources)];
> > static struct platform_device omap_i2c_devices[] = {
> > - I2C_DEV_BUILDER(1, i2c_resources[0], &i2c_rate[0]),
> > + I2C_DEV_BUILDER(1, i2c_resources[0], &i2c_pdata[0]),
> > #ifdefined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
> > - I2C_DEV_BUILDER(2, i2c_resources[1], &i2c_rate[1]),
> > + I2C_DEV_BUILDER(2, i2c_resources[1], &i2c_pdata[1]),
> > #endif
> > #ifdefined(CONFIG_ARCH_OMAP3)
> > - I2C_DEV_BUILDER(3, i2c_resources[2], &i2c_rate[2]),
> > + I2C_DEV_BUILDER(3, i2c_resources[2], &i2c_pdata[2]),
> > #endif
> > };
> >
> > @@ -146,8 +146,8 @@ static int __init omap_i2c_bus_setup(char *str)
> > get_options(str, 3, ints);
> > if (ints[0] < 2 || ints[1] < 1 || ints[1] > ports)
> > return 0;
> > - i2c_rate[ints[1] - 1] = ints[2];
> > - i2c_rate[ints[1] - 1] |= OMAP_I2C_CMDLINE_SETUP;
> > + i2c_pdata[ints[1] - 1].rate = ints[2];
> > + i2c_pdata[ints[1] - 1].rate |= OMAP_I2C_CMDLINE_SETUP;
> >
> > return 1;
> > }
>
> FYI, the change from i2c_rate to i2c_pdata is needed also for
> "i2c-omap: add mpu wake up latency constraint in i2c" as that
> blocks some PM changes from going upstream. So once that's sorted
> out some minor rebasing of that patch is needed.
OK
>
> > @@ -446,24 +453,47 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
> >
> > /* For first phase of HS mode */
> > scl = internal_clk / 400;
> > - fsscll = scl - (scl / 3) - 7;
> > - fssclh = (scl / 3) - 5;
> > + if ((pdata->hs_phase1.scll > 7) &&
> > + (pdata->hs_phase1.sclh >
Re: [PATCH 4/4] omap: mailbox: convert block api to kfifo
On Wed, Apr 28, 2010 at 2:52 PM, Hiroshi DOYU wrote:
> From: ext Ohad Ben-Cohen
> Subject: Re: [PATCH 4/4] omap: mailbox: convert block api to kfifo
> Date: Wed, 28 Apr 2010 13:25:41 +0200
>
>> On Wed, Apr 28, 2010 at 2:16 PM, Hiroshi DOYU wrote:
>>> From: ext Ohad Ben-Cohen
>>> Subject: Re: [PATCH 4/4] omap: mailbox: convert block api to kfifo
>>> Date: Wed, 28 Apr 2010 13:02:06 +0200
>>>
>> diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
>> index 72b17ad..b1324f3 100644
>> --- a/arch/arm/plat-omap/mailbox.c
>> +++ b/arch/arm/plat-omap/mailbox.c
>> @@ -26,6 +26,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>>
>> @@ -67,7 +68,7 @@ static inline int is_mbox_irq(struct omap_mbox *mbox,
>> omap_mbox_irq_t irq)
>> /*
>> * message sender
>> */
>> -static int __mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t msg)
>> +static int __mbox_poll_for_space(struct omap_mbox *mbox)
>> {
>> int ret = 0, i = 1000;
>>
>> @@ -78,49 +79,54 @@ static int __mbox_msg_send(struct omap_mbox *mbox,
>> mbox_msg_t msg)
>> return -1;
>> udelay(1);
>> }
>> - mbox_fifo_write(mbox, msg);
>> return ret;
>> }
>>
>> -
>> int omap_mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t msg)
>> {
>> + struct omap_mbox_queue *mq = mbox->txq;
>> + int ret = 0, len;
>>
>> - struct request *rq;
>> - struct request_queue *q = mbox->txq->queue;
>> + spin_lock(&mq->lock);
>>
>> - rq = blk_get_request(q, WRITE, GFP_ATOMIC);
>> - if (unlikely(!rq))
>> - return -ENOMEM;
>> + if (kfifo_avail(&mq->fifo) < sizeof(msg)) {
>> + ret = -ENOMEM;
>> + goto out;
>> + }
>> +
>> + len = kfifo_in(&mq->fifo, (unsigned char *)&msg, sizeof(msg));
>> + if (unlikely(len != sizeof(msg))) {
>> + pr_err("%s: kfifo_in anomaly\n", __func__);
>> + ret = -ENOMEM;
>> + }
>>
>> - blk_insert_request(q, rq, 0, (void *) msg);
>> tasklet_schedule(&mbox->txq->tasklet);
>>
>> - return 0;
>> +out:
>> + spin_unlock(&mq->lock);
>> + return ret;
>> }
>> EXPORT_SYMBOL(omap_mbox_msg_send);
>>
>> static void mbox_tx_tasklet(unsigned long tx_data)
>> {
>> - int ret;
>> - struct request *rq;
>> struct omap_mbox *mbox = (struct omap_mbox *)tx_data;
>> - struct request_queue *q = mbox->txq->queue;
>> -
>> - while (1) {
>> -
>> - rq = blk_fetch_request(q);
>> -
>> - if (!rq)
>> - break;
>> + struct omap_mbox_queue *mq = mbox->txq;
>> + mbox_msg_t msg;
>> + int ret;
>>
>> - ret = __mbox_msg_send(mbox, (mbox_msg_t)rq->special);
>> - if (ret) {
>> + while (kfifo_len(&mq->fifo)) {
>> + if (__mbox_poll_for_space(mbox)) {
>> omap_mbox_enable_irq(mbox, IRQ_TX);
>> - blk_requeue_request(q, rq);
>> - return;
>> + break;
>> }
>> - blk_end_request_all(rq, 0);
>> +
>> + ret = kfifo_out(&mq->fifo, (unsigned char *)&msg,
>> +
>> sizeof(msg));
>> + if (unlikely(ret != sizeof(msg)))
>> + pr_err("%s: kfifo_out anomaly\n", __func__);
>
> No error recovery? same for other anomalies.
I thought about it too, but eventually I think it doesn't really make
a lot of sense:
The only reason that kfifo_out/kfifo_in can fail here is if there's
not enough data/space (respectively).
Since we are checking for the availability of data/space before calling
kfifo_out/kfifo_in, it cannot really fail.
If it does fail, that's a critical bug that we cannot really recover from.
Only reasonable explanation can be a bug in the code (either ours or
kfifo's),
and with such a bug it really feels futile to put some recovery.
So maybe we should really make this a WARN_ON.
What do you think ?
>>>
>>> Makes sense. What about BUG_ON if it shouldn't happen theoretically?
>>
>> I'm not sure this bug is critical enough to panic and enforce the user
>> to reboot immediately - he can probably still do a clean shutdown here.
>
> I agree that WARN_ON would be enough for this case. I just thought of
> the rareness of this triggering.
Yeah, I was thinking exactly the same, and wanted to put BUG_ON too initially,
but the combination of its calling panic and its header comment
convinced me otherwise:
/*
* Don't use BUG
Re: [PATCH 4/4] omap: mailbox: convert block api to kfifo
From: ext Ohad Ben-Cohen
Subject: Re: [PATCH 4/4] omap: mailbox: convert block api to kfifo
Date: Wed, 28 Apr 2010 13:25:41 +0200
> On Wed, Apr 28, 2010 at 2:16 PM, Hiroshi DOYU wrote:
>> From: ext Ohad Ben-Cohen
>> Subject: Re: [PATCH 4/4] omap: mailbox: convert block api to kfifo
>> Date: Wed, 28 Apr 2010 13:02:06 +0200
>>
> diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
> index 72b17ad..b1324f3 100644
> --- a/arch/arm/plat-omap/mailbox.c
> +++ b/arch/arm/plat-omap/mailbox.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -67,7 +68,7 @@ static inline int is_mbox_irq(struct omap_mbox *mbox,
> omap_mbox_irq_t irq)
> /*
> * message sender
> */
> -static int __mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t msg)
> +static int __mbox_poll_for_space(struct omap_mbox *mbox)
> {
> int ret = 0, i = 1000;
>
> @@ -78,49 +79,54 @@ static int __mbox_msg_send(struct omap_mbox *mbox,
> mbox_msg_t msg)
> return -1;
> udelay(1);
> }
> - mbox_fifo_write(mbox, msg);
> return ret;
> }
>
> -
> int omap_mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t msg)
> {
> + struct omap_mbox_queue *mq = mbox->txq;
> + int ret = 0, len;
>
> - struct request *rq;
> - struct request_queue *q = mbox->txq->queue;
> + spin_lock(&mq->lock);
>
> - rq = blk_get_request(q, WRITE, GFP_ATOMIC);
> - if (unlikely(!rq))
> - return -ENOMEM;
> + if (kfifo_avail(&mq->fifo) < sizeof(msg)) {
> + ret = -ENOMEM;
> + goto out;
> + }
> +
> + len = kfifo_in(&mq->fifo, (unsigned char *)&msg, sizeof(msg));
> + if (unlikely(len != sizeof(msg))) {
> + pr_err("%s: kfifo_in anomaly\n", __func__);
> + ret = -ENOMEM;
> + }
>
> - blk_insert_request(q, rq, 0, (void *) msg);
> tasklet_schedule(&mbox->txq->tasklet);
>
> - return 0;
> +out:
> + spin_unlock(&mq->lock);
> + return ret;
> }
> EXPORT_SYMBOL(omap_mbox_msg_send);
>
> static void mbox_tx_tasklet(unsigned long tx_data)
> {
> - int ret;
> - struct request *rq;
> struct omap_mbox *mbox = (struct omap_mbox *)tx_data;
> - struct request_queue *q = mbox->txq->queue;
> -
> - while (1) {
> -
> - rq = blk_fetch_request(q);
> -
> - if (!rq)
> - break;
> + struct omap_mbox_queue *mq = mbox->txq;
> + mbox_msg_t msg;
> + int ret;
>
> - ret = __mbox_msg_send(mbox, (mbox_msg_t)rq->special);
> - if (ret) {
> + while (kfifo_len(&mq->fifo)) {
> + if (__mbox_poll_for_space(mbox)) {
> omap_mbox_enable_irq(mbox, IRQ_TX);
> - blk_requeue_request(q, rq);
> - return;
> + break;
> }
> - blk_end_request_all(rq, 0);
> +
> + ret = kfifo_out(&mq->fifo, (unsigned char *)&msg,
> +
> sizeof(msg));
> + if (unlikely(ret != sizeof(msg)))
> + pr_err("%s: kfifo_out anomaly\n", __func__);
No error recovery? same for other anomalies.
>>>
>>> I thought about it too, but eventually I think it doesn't really make
>>> a lot of sense:
>>> The only reason that kfifo_out/kfifo_in can fail here is if there's
>>> not enough data/space (respectively).
>>> Since we are checking for the availability of data/space before calling
>>> kfifo_out/kfifo_in, it cannot really fail.
>>> If it does fail, that's a critical bug that we cannot really recover from.
>>> Only reasonable explanation can be a bug in the code (either ours or
>>> kfifo's),
>>> and with such a bug it really feels futile to put some recovery.
>>> So maybe we should really make this a WARN_ON.
>>> What do you think ?
>>
>> Makes sense. What about BUG_ON if it shouldn't happen theoretically?
>
> I'm not sure this bug is critical enough to panic and enforce the user
> to reboot immediately - he can probably still do a clean shutdown here.
I agree that WARN_ON would be enough for this case. I just thought of
the rareness of this triggering.
--
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 4/4] omap: mailbox: convert block api to kfifo
On Wed, Apr 28, 2010 at 2:16 PM, Hiroshi DOYU wrote:
> From: ext Ohad Ben-Cohen
> Subject: Re: [PATCH 4/4] omap: mailbox: convert block api to kfifo
> Date: Wed, 28 Apr 2010 13:02:06 +0200
>
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 72b17ad..b1324f3 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
@@ -67,7 +68,7 @@ static inline int is_mbox_irq(struct omap_mbox *mbox,
omap_mbox_irq_t irq)
/*
* message sender
*/
-static int __mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t msg)
+static int __mbox_poll_for_space(struct omap_mbox *mbox)
{
int ret = 0, i = 1000;
@@ -78,49 +79,54 @@ static int __mbox_msg_send(struct omap_mbox *mbox,
mbox_msg_t msg)
return -1;
udelay(1);
}
- mbox_fifo_write(mbox, msg);
return ret;
}
-
int omap_mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t msg)
{
+ struct omap_mbox_queue *mq = mbox->txq;
+ int ret = 0, len;
- struct request *rq;
- struct request_queue *q = mbox->txq->queue;
+ spin_lock(&mq->lock);
- rq = blk_get_request(q, WRITE, GFP_ATOMIC);
- if (unlikely(!rq))
- return -ENOMEM;
+ if (kfifo_avail(&mq->fifo) < sizeof(msg)) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ len = kfifo_in(&mq->fifo, (unsigned char *)&msg, sizeof(msg));
+ if (unlikely(len != sizeof(msg))) {
+ pr_err("%s: kfifo_in anomaly\n", __func__);
+ ret = -ENOMEM;
+ }
- blk_insert_request(q, rq, 0, (void *) msg);
tasklet_schedule(&mbox->txq->tasklet);
- return 0;
+out:
+ spin_unlock(&mq->lock);
+ return ret;
}
EXPORT_SYMBOL(omap_mbox_msg_send);
static void mbox_tx_tasklet(unsigned long tx_data)
{
- int ret;
- struct request *rq;
struct omap_mbox *mbox = (struct omap_mbox *)tx_data;
- struct request_queue *q = mbox->txq->queue;
-
- while (1) {
-
- rq = blk_fetch_request(q);
-
- if (!rq)
- break;
+ struct omap_mbox_queue *mq = mbox->txq;
+ mbox_msg_t msg;
+ int ret;
- ret = __mbox_msg_send(mbox, (mbox_msg_t)rq->special);
- if (ret) {
+ while (kfifo_len(&mq->fifo)) {
+ if (__mbox_poll_for_space(mbox)) {
omap_mbox_enable_irq(mbox, IRQ_TX);
- blk_requeue_request(q, rq);
- return;
+ break;
}
- blk_end_request_all(rq, 0);
+
+ ret = kfifo_out(&mq->fifo, (unsigned char *)&msg,
+ sizeof(msg));
+ if (unlikely(ret != sizeof(msg)))
+ pr_err("%s: kfifo_out anomaly\n", __func__);
>>>
>>> No error recovery? same for other anomalies.
>>
>> I thought about it too, but eventually I think it doesn't really make
>> a lot of sense:
>> The only reason that kfifo_out/kfifo_in can fail here is if there's
>> not enough data/space (respectively).
>> Since we are checking for the availability of data/space before calling
>> kfifo_out/kfifo_in, it cannot really fail.
>> If it does fail, that's a critical bug that we cannot really recover from.
>> Only reasonable explanation can be a bug in the code (either ours or
>> kfifo's),
>> and with such a bug it really feels futile to put some recovery.
>> So maybe we should really make this a WARN_ON.
>> What do you think ?
>
> Makes sense. What about BUG_ON if it shouldn't happen theoretically?
I'm not sure this bug is critical enough to panic and enforce the user
to reboot immediately - he can probably still do a clean shutdown here.
Thanks,
Ohad.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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 4/4] omap: mailbox: convert block api to kfifo
From: ext Ohad Ben-Cohen
Subject: Re: [PATCH 4/4] omap: mailbox: convert block api to kfifo
Date: Wed, 28 Apr 2010 13:02:06 +0200
>>> diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
>>> index 72b17ad..b1324f3 100644
>>> --- a/arch/arm/plat-omap/mailbox.c
>>> +++ b/arch/arm/plat-omap/mailbox.c
>>> @@ -26,6 +26,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> #include
>>>
>>> @@ -67,7 +68,7 @@ static inline int is_mbox_irq(struct omap_mbox *mbox,
>>> omap_mbox_irq_t irq)
>>> /*
>>> * message sender
>>> */
>>> -static int __mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t msg)
>>> +static int __mbox_poll_for_space(struct omap_mbox *mbox)
>>> {
>>> int ret = 0, i = 1000;
>>>
>>> @@ -78,49 +79,54 @@ static int __mbox_msg_send(struct omap_mbox *mbox,
>>> mbox_msg_t msg)
>>> return -1;
>>> udelay(1);
>>> }
>>> - mbox_fifo_write(mbox, msg);
>>> return ret;
>>> }
>>>
>>> -
>>> int omap_mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t msg)
>>> {
>>> + struct omap_mbox_queue *mq = mbox->txq;
>>> + int ret = 0, len;
>>>
>>> - struct request *rq;
>>> - struct request_queue *q = mbox->txq->queue;
>>> + spin_lock(&mq->lock);
>>>
>>> - rq = blk_get_request(q, WRITE, GFP_ATOMIC);
>>> - if (unlikely(!rq))
>>> - return -ENOMEM;
>>> + if (kfifo_avail(&mq->fifo) < sizeof(msg)) {
>>> + ret = -ENOMEM;
>>> + goto out;
>>> + }
>>> +
>>> + len = kfifo_in(&mq->fifo, (unsigned char *)&msg, sizeof(msg));
>>> + if (unlikely(len != sizeof(msg))) {
>>> + pr_err("%s: kfifo_in anomaly\n", __func__);
>>> + ret = -ENOMEM;
>>> + }
>>>
>>> - blk_insert_request(q, rq, 0, (void *) msg);
>>> tasklet_schedule(&mbox->txq->tasklet);
>>>
>>> - return 0;
>>> +out:
>>> + spin_unlock(&mq->lock);
>>> + return ret;
>>> }
>>> EXPORT_SYMBOL(omap_mbox_msg_send);
>>>
>>> static void mbox_tx_tasklet(unsigned long tx_data)
>>> {
>>> - int ret;
>>> - struct request *rq;
>>> struct omap_mbox *mbox = (struct omap_mbox *)tx_data;
>>> - struct request_queue *q = mbox->txq->queue;
>>> -
>>> - while (1) {
>>> -
>>> - rq = blk_fetch_request(q);
>>> -
>>> - if (!rq)
>>> - break;
>>> + struct omap_mbox_queue *mq = mbox->txq;
>>> + mbox_msg_t msg;
>>> + int ret;
>>>
>>> - ret = __mbox_msg_send(mbox, (mbox_msg_t)rq->special);
>>> - if (ret) {
>>> + while (kfifo_len(&mq->fifo)) {
>>> + if (__mbox_poll_for_space(mbox)) {
>>> omap_mbox_enable_irq(mbox, IRQ_TX);
>>> - blk_requeue_request(q, rq);
>>> - return;
>>> + break;
>>> }
>>> - blk_end_request_all(rq, 0);
>>> +
>>> + ret = kfifo_out(&mq->fifo, (unsigned char *)&msg,
>>> + sizeof(msg));
>>> + if (unlikely(ret != sizeof(msg)))
>>> + pr_err("%s: kfifo_out anomaly\n", __func__);
>>
>> No error recovery? same for other anomalies.
>
> I thought about it too, but eventually I think it doesn't really make
> a lot of sense:
> The only reason that kfifo_out/kfifo_in can fail here is if there's
> not enough data/space (respectively).
> Since we are checking for the availability of data/space before calling
> kfifo_out/kfifo_in, it cannot really fail.
> If it does fail, that's a critical bug that we cannot really recover from.
> Only reasonable explanation can be a bug in the code (either ours or kfifo's),
> and with such a bug it really feels futile to put some recovery.
> So maybe we should really make this a WARN_ON.
> What do you think ?
Makes sense. What about BUG_ON if it shouldn't happen theoretically?
--
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 4/4] omap: mailbox: convert block api to kfifo
On Wed, Apr 28, 2010 at 8:56 AM, Hiroshi DOYU wrote: > From: ext Ohad Ben-Cohen > Subject: [PATCH 4/4] omap: mailbox: convert block api to kfifo > Date: Tue, 27 Apr 2010 19:56:22 +0200 > >> The underlying buffering implementation of mailbox >> is converted from block API to kfifo due to the simplicity >> and speed of kfifo. >> >> Signed-off-by: Ohad Ben-Cohen >> Signed-off-by: Hari Kanigeri >> --- >> arch/arm/plat-omap/include/plat/mailbox.h | 5 +- >> arch/arm/plat-omap/mailbox.c | 108 >> + >> 2 files changed, 52 insertions(+), 61 deletions(-) >> >> diff --git a/arch/arm/plat-omap/include/plat/mailbox.h >> b/arch/arm/plat-omap/include/plat/mailbox.h >> index 729166b..014cc58 100644 >> --- a/arch/arm/plat-omap/include/plat/mailbox.h >> +++ b/arch/arm/plat-omap/include/plat/mailbox.h >> @@ -7,6 +7,7 @@ >> #include >> #include > > Also the above is not necessary? Good point. It will be removed. Thanks, Ohad. > >> #include >> +#include > -- 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 4/4] omap: mailbox: convert block api to kfifo
Hi Hiroshi,
On Wed, Apr 28, 2010 at 8:52 AM, Hiroshi DOYU wrote:
> Hi Ohad,
>
> From: ext Ohad Ben-Cohen
> Subject: [PATCH 4/4] omap: mailbox: convert block api to kfifo
> Date: Tue, 27 Apr 2010 19:56:22 +0200
>
>> The underlying buffering implementation of mailbox
>> is converted from block API to kfifo due to the simplicity
>> and speed of kfifo.
>>
>> Signed-off-by: Ohad Ben-Cohen
>> Signed-off-by: Hari Kanigeri
>> ---
>> arch/arm/plat-omap/include/plat/mailbox.h | 5 +-
>> arch/arm/plat-omap/mailbox.c | 108
>> +
>> 2 files changed, 52 insertions(+), 61 deletions(-)
>>
>> diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
>> b/arch/arm/plat-omap/include/plat/mailbox.h
>> index 729166b..014cc58 100644
>> --- a/arch/arm/plat-omap/include/plat/mailbox.h
>> +++ b/arch/arm/plat-omap/include/plat/mailbox.h
>> @@ -7,6 +7,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> typedef u32 mbox_msg_t;
>> struct omap_mbox;
>> @@ -19,6 +20,8 @@ typedef int __bitwise omap_mbox_type_t;
>> #define OMAP_MBOX_TYPE1 ((__force omap_mbox_type_t) 1)
>> #define OMAP_MBOX_TYPE2 ((__force omap_mbox_type_t) 2)
>>
>> +#define MBOX_KFIFO_SIZE (256)
>
> Can this be a module parameter? Then, OEM could set their optimized value.
Sure.
>
>> +
>> struct omap_mbox_ops {
>> omap_mbox_type_t type;
>> int (*startup)(struct omap_mbox *mbox);
>> @@ -42,7 +45,7 @@ struct omap_mbox_ops {
>>
>> struct omap_mbox_queue {
>> spinlock_t lock;
>> - struct request_queue *queue;
>> + struct kfifo fifo;
>> struct work_struct work;
>> struct tasklet_struct tasklet;
>> int (*callback)(void *);
>> diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
>> index 72b17ad..b1324f3 100644
>> --- a/arch/arm/plat-omap/mailbox.c
>> +++ b/arch/arm/plat-omap/mailbox.c
>> @@ -26,6 +26,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>>
>> @@ -67,7 +68,7 @@ static inline int is_mbox_irq(struct omap_mbox *mbox,
>> omap_mbox_irq_t irq)
>> /*
>> * message sender
>> */
>> -static int __mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t msg)
>> +static int __mbox_poll_for_space(struct omap_mbox *mbox)
>> {
>> int ret = 0, i = 1000;
>>
>> @@ -78,49 +79,54 @@ static int __mbox_msg_send(struct omap_mbox *mbox,
>> mbox_msg_t msg)
>> return -1;
>> udelay(1);
>> }
>> - mbox_fifo_write(mbox, msg);
>> return ret;
>> }
>>
>> -
>> int omap_mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t msg)
>> {
>> + struct omap_mbox_queue *mq = mbox->txq;
>> + int ret = 0, len;
>>
>> - struct request *rq;
>> - struct request_queue *q = mbox->txq->queue;
>> + spin_lock(&mq->lock);
>>
>> - rq = blk_get_request(q, WRITE, GFP_ATOMIC);
>> - if (unlikely(!rq))
>> - return -ENOMEM;
>> + if (kfifo_avail(&mq->fifo) < sizeof(msg)) {
>> + ret = -ENOMEM;
>> + goto out;
>> + }
>> +
>> + len = kfifo_in(&mq->fifo, (unsigned char *)&msg, sizeof(msg));
>> + if (unlikely(len != sizeof(msg))) {
>> + pr_err("%s: kfifo_in anomaly\n", __func__);
>> + ret = -ENOMEM;
>> + }
>>
>> - blk_insert_request(q, rq, 0, (void *) msg);
>> tasklet_schedule(&mbox->txq->tasklet);
>>
>> - return 0;
>> +out:
>> + spin_unlock(&mq->lock);
>> + return ret;
>> }
>> EXPORT_SYMBOL(omap_mbox_msg_send);
>>
>> static void mbox_tx_tasklet(unsigned long tx_data)
>> {
>> - int ret;
>> - struct request *rq;
>> struct omap_mbox *mbox = (struct omap_mbox *)tx_data;
>> - struct request_queue *q = mbox->txq->queue;
>> -
>> - while (1) {
>> -
>> - rq = blk_fetch_request(q);
>> -
>> - if (!rq)
>> - break;
>> + struct omap_mbox_queue *mq = mbox->txq;
>> + mbox_msg_t msg;
>> + int ret;
>>
>> - ret = __mbox_msg_send(mbox, (mbox_msg_t)rq->special);
>> - if (ret) {
>> + while (kfifo_len(&mq->fifo)) {
>> + if (__mbox_poll_for_space(mbox)) {
>> omap_mbox_enable_irq(mbox, IRQ_TX);
>> - blk_requeue_request(q, rq);
>> - return;
>> + break;
>> }
>> - blk_end_request_all(rq, 0);
>> +
>> + ret = kfifo_out(&mq->fifo, (unsigned char *)&msg,
>> + sizeof(msg));
>> + if (unlikely(ret != sizeof(msg)))
>> + pr_err("%s: kfifo_out anomaly\n", __func__);
>
> No error recovery? same for other anomalies.
I thought about it too, but eventually I think it doesn't really make
a lot of sense:
The only reason that kfifo_out/kfifo_in can fail here is if there's
not enough data/space (respectively).
Since we are checking for the ava
Re: [PATCH 1/4] omap: mailbox cleanup: convert rwlocks to spinlock
Hi Hiroshi, On Wed, Apr 28, 2010 at 10:50 AM, Hiroshi DOYU wrote: > Hi Ohad, > > From: ext Ohad Ben-Cohen > Subject: [PATCH 1/4] omap: mailbox cleanup: convert rwlocks to spinlock > Date: Tue, 27 Apr 2010 19:56:19 +0200 > >> rwlocks are slower and have potential starvation issues so spinlocks are >> generally preferred > > Would it be possible to explain the above a bit more? Sure, sorry for the laconic description. Jonathan Corbet wrote a nice summary about this: http://lwn.net/Articles/364583/ We could switch to rcu, but it's really an overkill because we don't really have a high bandwidth of readers (omap_mbox_get is not being called so much). The only disadvantage of a plain spinlock is that readers now will have to wait in the line, but since omap_mbox_get isn't called so frequently, I guess that by moving to spinlocks the average performance will actually increase (since spinlocks are faster and most likely there will not be multiple concurrent calls to omap_mbox_get). Anyway I only consider this as a cleanup and not really a performance issue, as mboxes_lock is not really on a hot path. Thanks, Ohad. > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6] OMAP2/3: I2C: Errata ID i207: Clear wrong RDR interrupt
On 04/28/2010 05:20 AM, G, Manjunath Kondaiah wrote: [..] + dev->errata = 0; + + if (cpu_is_omap2430() || cpu_is_omap34xx()) wont cpu_is_omap24xx() cover omap2420 as well? I think it might be better using that.. apologies on missing it in the last look. This errata is not applicable for 2420 and it is applicable for: 1. omap2430 2. omap34xx(including omap3630). Sorry. My earlier patch was using this errata logic for all omap's except omap4 which was wrong(for omap2420 and omap1 - not sure, I don't have any data hence ignoring this errata for omap1 also). Could you fix your commit message to state so instead of using OMAP2? thanks.. I think we are almost close to the final rev is Tony is ok as well.. Thanks for hanging in there.. [...] 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 v6] OMAP2/3: I2C: Errata ID i207: Clear wrong RDR interrupt
> -Original Message-
> From: Menon, Nishanth
> Sent: Wednesday, April 28, 2010 3:35 PM
> To: G, Manjunath Kondaiah
> Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
> ben-li...@fluff.org; Kalliguddi, Hema; Aaro Koskinen; Tony Lindgren
> Subject: Re: [PATCH v6] OMAP2/3: I2C: Errata ID i207: Clear
> wrong RDR interrupt
>
> very minor comments below:
> On 04/28/2010 12:47 AM, G, Manjunath Kondaiah wrote:
> > Under certain rare conditions, I2C_STAT[13].RDR bit may be set
> > and the corresponding interrupt fire, even there is no data in
> > the receive FIFO, or the I2C data transfer is still ongoing.
> > These spurious RDR events must be ignored by the software.
> >
> > This patch handles and ignores RDR spurious interrupts.
> >
> > The below sequence is required in interrupt handler for
> > handling this errata:
> > 1. If RDR is set to 1, clear RDR
> > 2. Read I2C status register and check for BusBusy bit. If BusBusy
> > bit is set, skip remaining steps.
> > 3. If BusBusy bit is not set, perform read operation on I2C status
> > register.
> > 4. If RDR is set, clear the same. Check RDR again and clear
> if it sets
> > RDR bit again.
> > 5. Perform I2C Data Read operation N number of times(where
> N is value
> > read from the register BUFSTAT-RXSTAT bit fields).
> >
> > Note : This errata is applicable for OMAP2 and OMAP3 platforms only.
> > It is not applicable for OMAP4.
> >
> > Signed-off-by: Manjunatha GK
> > Cc: linux-...@vger.kernel.org
> > Cc: ben-li...@fluff.org
> > Cc: Kalliguddi, Hema
> > Cc: Nishanth Menon
> > Cc: Aaro Koskinen
> > Cc: Tony Lindgren
> > ---
> > drivers/i2c/busses/i2c-omap.c | 40
>
> > 1 files changed, 40 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-omap.c
> b/drivers/i2c/busses/i2c-omap.c
> > index ef73483..cdcdfeb 100644
> > --- a/drivers/i2c/busses/i2c-omap.c
> > +++ b/drivers/i2c/busses/i2c-omap.c
> > @@ -166,6 +166,8 @@ enum {
> > #define SYSC_IDLEMODE_SMART 0x2
> > #define SYSC_CLOCKACTIVITY_FCLK 0x2
> >
> > +/* Errata definitions */
> > +#define I2C_OMAP_ERRATA_I207 (1<< 0)
>
>tiny nit: s/1< >
> > struct omap_i2c_dev {
> > struct device *dev;
> > @@ -199,6 +201,7 @@ struct omap_i2c_dev {
> > u16 bufstate;
> > u16 syscstate;
> > u16 westate;
> > + u16 errata;
> overall I'd prefer the term quirk over errata - quirk is more of a
> standard linux term used accross network, usb and other drivers, will
> allow the code to be a little more familiar with the upstream
> maintainers/reviewers.. but i leave it to tony and others to comment
> more.. maybe it is just me being an ass again ;)
>
> > };
> >
> > const static u8 reg_map[] = {
> > @@ -498,6 +501,11 @@ static int omap_i2c_init(struct
> omap_i2c_dev *dev)
> > /* Take the I2C module out of reset: */
> > omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
> >
> > + dev->errata = 0;
> > +
> > + if (cpu_is_omap2430() || cpu_is_omap34xx())
> wont cpu_is_omap24xx() cover omap2420 as
> well? I think it might be better using that.. apologies on
> missing it in
> the last look.
This errata is not applicable for 2420 and it is applicable for:
1. omap2430
2. omap34xx(including omap3630).
Sorry. My earlier patch was using this errata logic for all omap's
except omap4 which was wrong(for omap2420 and omap1 - not sure, I don't have
any data hence ignoring this errata for omap1 also).
>
> > + dev->errata |= I2C_OMAP_ERRATA_I207;
> > +
> > /* Enable interrupts */
> > dev->iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
> > OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK |
> > @@ -695,6 +703,34 @@ omap_i2c_ack_stat(struct omap_i2c_dev
> *dev, u16 stat)
> > omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat);
> > }
> >
> > +static inline void i2c_omap_errata_i207(struct
> omap_i2c_dev *dev, u16 stat)
> > +{
> > + /*
> > +* I2C Errata(Errata Nos. OMAP2: 1.67, OMAP3: 1.8)
> > +* Not applicable for OMAP4.
> > +* Under certain rare conditions, RDR could be set again
> > +* when the bus is busy, then ignore the interrupt and
> > +* clear the interrupt.
> > +*/
> > + if (stat& OMAP_I2C_STAT_RDR) {
> > + /* Step 1: If RDR is set, clear it */
> > + omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR);
> > +
> > + /* Step 2: */
> > + if (!(omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG)
> > + & OMAP_I2C_STAT_BB)) {
> > +
> > + /* Step 3: */
> > + if (omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG)
> > + & OMAP_I2C_STAT_RDR) {
> > + omap_i2c_
Re: [PATCH v6] OMAP2/3: I2C: Errata ID i207: Clear wrong RDR interrupt
very minor comments below:
On 04/28/2010 12:47 AM, G, Manjunath Kondaiah wrote:
Under certain rare conditions, I2C_STAT[13].RDR bit may be set
and the corresponding interrupt fire, even there is no data in
the receive FIFO, or the I2C data transfer is still ongoing.
These spurious RDR events must be ignored by the software.
This patch handles and ignores RDR spurious interrupts.
The below sequence is required in interrupt handler for
handling this errata:
1. If RDR is set to 1, clear RDR
2. Read I2C status register and check for BusBusy bit. If BusBusy
bit is set, skip remaining steps.
3. If BusBusy bit is not set, perform read operation on I2C status
register.
4. If RDR is set, clear the same. Check RDR again and clear if it sets
RDR bit again.
5. Perform I2C Data Read operation N number of times(where N is value
read from the register BUFSTAT-RXSTAT bit fields).
Note : This errata is applicable for OMAP2 and OMAP3 platforms only.
It is not applicable for OMAP4.
Signed-off-by: Manjunatha GK
Cc: linux-...@vger.kernel.org
Cc: ben-li...@fluff.org
Cc: Kalliguddi, Hema
Cc: Nishanth Menon
Cc: Aaro Koskinen
Cc: Tony Lindgren
---
drivers/i2c/busses/i2c-omap.c | 40
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index ef73483..cdcdfeb 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -166,6 +166,8 @@ enum {
#define SYSC_IDLEMODE_SMART 0x2
#define SYSC_CLOCKACTIVITY_FCLK 0x2
+/* Errata definitions */
+#define I2C_OMAP_ERRATA_I207 (1<< 0)
tiny nit: s/1<
struct omap_i2c_dev {
struct device *dev;
@@ -199,6 +201,7 @@ struct omap_i2c_dev {
u16 bufstate;
u16 syscstate;
u16 westate;
+ u16 errata;
overall I'd prefer the term quirk over errata - quirk is more of a
standard linux term used accross network, usb and other drivers, will
allow the code to be a little more familiar with the upstream
maintainers/reviewers.. but i leave it to tony and others to comment
more.. maybe it is just me being an ass again ;)
};
const static u8 reg_map[] = {
@@ -498,6 +501,11 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
/* Take the I2C module out of reset: */
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ dev->errata = 0;
+
+ if (cpu_is_omap2430() || cpu_is_omap34xx())
wont cpu_is_omap24xx() cover omap2420 as
well? I think it might be better using that.. apologies on missing it in
the last look.
+ dev->errata |= I2C_OMAP_ERRATA_I207;
+
/* Enable interrupts */
dev->iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK |
@@ -695,6 +703,34 @@ omap_i2c_ack_stat(struct omap_i2c_dev *dev, u16 stat)
omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat);
}
+static inline void i2c_omap_errata_i207(struct omap_i2c_dev *dev, u16 stat)
+{
+ /*
+* I2C Errata(Errata Nos. OMAP2: 1.67, OMAP3: 1.8)
+* Not applicable for OMAP4.
+* Under certain rare conditions, RDR could be set again
+* when the bus is busy, then ignore the interrupt and
+* clear the interrupt.
+*/
+ if (stat& OMAP_I2C_STAT_RDR) {
+ /* Step 1: If RDR is set, clear it */
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR);
+
+ /* Step 2: */
+ if (!(omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG)
+ & OMAP_I2C_STAT_BB)) {
+
+ /* Step 3: */
+ if (omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG)
+ & OMAP_I2C_STAT_RDR) {
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR);
+ dev_dbg(dev->dev, "RDR when bus is busy.\n");
+ }
+
+ }
+ }
+}
+
/* rev1 devices are apparently only on some 15xx */
#ifdef CONFIG_ARCH_OMAP15XX
@@ -826,6 +862,10 @@ complete:
}
if (stat& (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
u8 num_bytes = 1;
+
+ 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;
Thanks, sparse and checkpatch are happy now :)
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 ma
Re: [PATCH] OMAP3EVM: Update pad configuration for wakeup enabled pads
Kevin,
On Tue, 27-Apr-10 8:46 PM +0530, Kevin Hilman wrote:
> Ranjith Lohithakshan writes:
>
>> OMAP3530 TRM section 7.4.4.4.2 requires OFFOUTENABLE to be set (active low)
>> if wakeup capabilities are enabled on a pad. During OFF mode testing
>> on OMAP3530 EVM, it was observed that the device was not residing in
>> the OFF state. The device enters into the OFF state and immediately exits
>> from that state as if an IO wakeup event has occured. The issue was traced
>> down to the pad configuration of wkaeup enabled pad's.
>
> Nice.
>
>> Also, the pad configuration is included only if the respective drivers are
>> enabled in the defconfig.
>
> Hmm, do you really want this? If you don't have the driver enabled,
> you have to rely on the bootloader settings of these pads which may
> also be wrong and trigger an IO wakeup as well.
The thought process was that, for example, if keypad is not enabled in a
system configuration you probably don't want to see a wakeup occurring
if someone presses a key stroke. I understand the concern that you have
raised regarding bootloader mis-configurations. My impression was that
the bootloaders typically set the mux modes and pull up's/downs and dont
really program or enable the wakeup capability. But we cannot depend on
that thumb rule. What is your recommendation?
>
>> Signed-off-by: Ranjith Lohithakshan
>> ---
>> arch/arm/mach-omap2/board-omap3evm.c |8 ++--
>> 1 files changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/board-omap3evm.c
>> b/arch/arm/mach-omap2/board-omap3evm.c
>> index 017bb2f..ce66ef0 100644
>> --- a/arch/arm/mach-omap2/board-omap3evm.c
>> +++ b/arch/arm/mach-omap2/board-omap3evm.c
>> @@ -650,12 +650,16 @@ static struct ehci_hcd_omap_platform_data ehci_pdata
>> __initdata = {
>>
>> #ifdef CONFIG_OMAP_MUX
>> static struct omap_board_mux board_mux[] __initdata = {
>> +#ifdef CONFIG_KEYBOARD_TWL4030
>> OMAP3_MUX(SYS_NIRQ, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP |
>> -OMAP_PIN_OFF_INPUT_PULLUP |
>> +OMAP_PIN_OFF_INPUT_PULLUP |
>> OMAP_PIN_OFF_OUTPUT_LOW |
>> OMAP_PIN_OFF_WAKEUPENABLE),
>> +#endif
>> +#ifdef CONFIG_TOUCHSCREEN_ADS7846
>> OMAP3_MUX(MCSPI1_CS1, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
>> -OMAP_PIN_OFF_INPUT_PULLUP |
>> +OMAP_PIN_OFF_INPUT_PULLUP |
>> OMAP_PIN_OFF_OUTPUT_LOW |
>> OMAP_PIN_OFF_WAKEUPENABLE),
>> +#endif
>> { .reg_offset = OMAP_MUX_TERMINATOR },
>> };
>> #else
>> --
>> 1.6.2.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
--
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/4] omap: mailbox cleanup: convert rwlocks to spinlock
Hi Ohad, From: ext Ohad Ben-Cohen Subject: [PATCH 1/4] omap: mailbox cleanup: convert rwlocks to spinlock Date: Tue, 27 Apr 2010 19:56:19 +0200 > rwlocks are slower and have potential starvation issues so spinlocks are > generally preferred Would it be possible to explain the above a bit more? -- 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 v2] DSPBRIDGE: use dm timer framework for gpt timers
On Wed, Apr 28, 2010 at 4:29 AM, Omar Ramirez Luna wrote: > This patch switches to use DM timer framework instead of > a custom one for GPT timers, currently dsp can make use of > gpt 5, 6, 7 or 8. I heard someone that was using gpt 8 for something else. Is it possible to configure dsp-bridge to not use it? -- Felipe Contreras -- 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
