Re: [PATCH] OMAP PM interface, version 2
"ext Paul Walmsley" <[EMAIL PROTECTED]> writes: > Hello Jouni, > > On Wed, 18 Jun 2008, Högander Jouni wrote: > >> "ext Paul Walmsley" <[EMAIL PROTECTED]> writes: >> >> > Major changes since the first version: >> > >> > 1. Jouni Hogander suggested that the set_max_cpu_lat() function be >> >merged into set_max_dev_wakeup_lat(), when set_max_dev_wakeup_lat() >> >is called with the CPU0 sys_device (via get_cpu_sysdev(0)). He feels >> >that this will be easier for device driver developers to use. This >> >change has been made. >> >> I just noticed that this won't work. We have this declaration: >> >> (*pdata->set_max_dev_wakeup_lat)(struct device *dev, unsigned long t) >> >> In case of cpu it is not possible to underlying code to identify the >> caller. > > Eh, nice catch. Let's add set_max_intr_lat() back in - perhaps call it > set_max_mpu_wakeup_lat() instead for symmetry? Yes, I agree. Originally my idea to change this was related to that pm qos extending and actually I didn't expect you to do this change. > >> This derives a question should we have parameter for caller >> identification in set_max_dev_wakeup_lat()? >> >> I mean currently we are assuming that there is only one caller for each >> device. Is this correct assumination? If we think e.g. busses. There >> might be drivers for devices on some specific bus. Each of them might >> want to set latency constraint for the bus. > > In the case of bus wakeup latency, all of the on-chip interconnects share > the same wakeup latency - the CORE powerdomain wakeup latency. So > set_max_dma_lat() covers all of the interconnect latencies. Well I didn't mean interconnect busses here. I was thinking busses like spi, which can have multiple devices on it. Drivers for theses devices might want to set latency constraints for spi bus. In current plan we are assuming that spi driver is the only one who sets the latency constraint for spi bus. How could spi driver know what is the spi latency requirement for the device that is connected to it? > > We could call it set_max_bus_wakeup_lat(), with a prototype similar to > set_max_dev_wakeup_lat(), for consistency. (The bus agent argument would > effectively be ignored in OMAP2/3.) Lets not change that, originally it was planned to control sdma latency constraint, without caring that it actually affects also to interconnect bus latencies. Is this plan changed? At some point it was thought to be changed to set_max_sdma_lat(), right? If we are some day at point where interconnect busses are modelled as a bus, then adding set_max_bus_wakeup_lat() could be good idea. Further if also sdma will be modelled as a platform device, then set_max_dma_lat() could be removed and set_max_dev_wakeup_lat() used instead for sdma. Currently set_max_intr_lat() could be already removed with adding one more parameter to set_max_dev_wakeup_lat(): set_max_dev_wakeup_lat(struct device *dev, struct device *req, unsigned long t); This is just an idea, please do not change:) Instead I think your idea to change it back to what it was is better at this point. -- Jouni Högander -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP PM interface, version 2
Hello Jouni, On Wed, 18 Jun 2008, Högander Jouni wrote: > "ext Paul Walmsley" <[EMAIL PROTECTED]> writes: > > > Major changes since the first version: > > > > 1. Jouni Hogander suggested that the set_max_cpu_lat() function be > >merged into set_max_dev_wakeup_lat(), when set_max_dev_wakeup_lat() > >is called with the CPU0 sys_device (via get_cpu_sysdev(0)). He feels > >that this will be easier for device driver developers to use. This > >change has been made. > > I just noticed that this won't work. We have this declaration: > > (*pdata->set_max_dev_wakeup_lat)(struct device *dev, unsigned long t) > > In case of cpu it is not possible to underlying code to identify the > caller. Eh, nice catch. Let's add set_max_intr_lat() back in - perhaps call it set_max_mpu_wakeup_lat() instead for symmetry? > This derives a question should we have parameter for caller > identification in set_max_dev_wakeup_lat()? > > I mean currently we are assuming that there is only one caller for each > device. Is this correct assumination? If we think e.g. busses. There > might be drivers for devices on some specific bus. Each of them might > want to set latency constraint for the bus. In the case of bus wakeup latency, all of the on-chip interconnects share the same wakeup latency - the CORE powerdomain wakeup latency. So set_max_dma_lat() covers all of the interconnect latencies. We could call it set_max_bus_wakeup_lat(), with a prototype similar to set_max_dev_wakeup_lat(), for consistency. (The bus agent argument would effectively be ignored in OMAP2/3.) Thoughts? - Paul
Video playback on osk with linux-2.6.18
Dear All, I have an OSK-Omap5912 with linux-2.6.18 running on it. i want to add video playback support to it. Has someone done this before? could you suggest some ways to do it? thank you. regards, Mohammed -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] suppress needless timer reprogramming {tick-sched.c}
On Wednesday 18 June 2008, Woodruff, Richard wrote: > > > > As measured using ETM trace this drops my reprogramming penalty from > > almost 60% CPU load down to 15% during high interrupt rate. If you like > > I can send traces to show this. More than doubling the available-for-real-use CPU time! Impressive. I'd imagine that many systems using reprogrammable 32K timers for scheduling could win from such a patch, although not necessarily quite so visibly as on this ARM unless their CPU clocks were also in the 500+ MHz range. Seems like a "law of unintended consequences" here. Use a 32K timer since it takes less power than a multi-MHz one, and so the faster clocks can be gated off more comprehensively (in hardware) to give more power savings. Then throw NO_HZ on top to get one more increment of power savings ... whoops, it was assuming that it was dirt cheap to reprogram timers, major badness! - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP2/3 PM: Add OMAP PM no-op layer
Hi Paul,
- Original Message -
From: "Paul Walmsley" <[EMAIL PROTECTED]>
To:
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, June 17, 2008 8:31 PM
Subject: [PATCH] OMAP2/3 PM: Add OMAP PM no-op layer
> +/**
> + * omap_pm_cpu_get_freq_table - return a cpufreq_frequency_table array
ptr
> + *
> + * Provide a frequency table usable by CPUFreq for the current
chip/board.
> + * Returns a pointer to a struct cpufreq_frequency_table array or NULL
> + * upon error.
> + */
> +struct cpufreq_frequency_table **omap_pm_cpu_get_freq_table(void)
> +{
> + pr_debug("OMAP PM: CPUFreq request for frequency table\n");
> +
> + /*
> + * Allocate and build CPUFreq frequency table here: loop over
> + * all VDD1 clkrates, pull out the mpu_ck frequencies, build
> + * table
> + */
> +
> + return NULL;
> +}
> +
Will this interface provides information of max number if OPPs supported and
the frequency corresponding to eah OPP level?
Notification of OPP level change to DSP
--
MPU Bridge is required to inform the DSP about OPP level change for load
predictor use in DSP;
this is done as part of in post notification in dspbridge. Do we have
support for Post Notification in this framework?
Please let us know your comments.
Thanks & regards
Ramesh Gupta G
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH/RFC 1/2] Add Dspbridge driver to OMAP GIT kernel
Hi Trilok, > Hi Hari, > > > > > >, doesn't use > > > common frameworks which were already written once for nokia > > > dspgateway, > > > > It is agreed with Doyu-san that we will consider this as a long > > term plan. > > > > Setting up a GIT tree for dspbridge driver, should not be on long term > plan, as long term plan should be to get dspbridge merged on to OMAP > GIT itself. In this case separate GIT tree, should serve as staging > tree and playground for cleanups so that others (specifically outside > TI guys) can watch your commits/comment and help you guys on cleanups. > It is really tough to track and review your changes as you are putting > very big patches and we are unable to keep sync with your changes in > incremental fashion. > > For most of the open source guys, setting up GIT tree is sometime > first step in-order to make changes visible to others in better way :) > - The quote I made about long term plan is regarding common framework, and not about GIT tree. > > -- > ---Trilok Soni > http://triloksoni.wordpress.com -Hari -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 1/2] Add Dspbridge driver to OMAP GIT kernel
Hi Hari, On 6/17/08, Kanigeri, Hari <[EMAIL PROTECTED]> wrote: > Hi Trilok, > > > This code is sitting on pile of un-necessary wrappers, doesn't use > > common frameworks which were already written once for nokia > > dspgateway, > > --- This is addressed in the email sent to the mailing list. > > > I am sure it will not pass checkpatch and sparse screening > > tests even. > > --- The checkpatch (version 18) is ran on the patch file that is sent to > the mailing list, and we observed only 65 errors (most of them are false > errors reported by checkpatch), and there are around 365 warnings > (mostly complaints on typedefs) > > > >, doesn't use > > common frameworks which were already written once for nokia > > dspgateway, > > It is agreed with Doyu-san that we will consider this as a long > term plan. > Setting up a GIT tree for dspbridge driver, should not be on long term plan, as long term plan should be to get dspbridge merged on to OMAP GIT itself. In this case separate GIT tree, should serve as staging tree and playground for cleanups so that others (specifically outside TI guys) can watch your commits/comment and help you guys on cleanups. It is really tough to track and review your changes as you are putting very big patches and we are unable to keep sync with your changes in incremental fashion. For most of the open source guys, setting up GIT tree is sometime first step in-order to make changes visible to others in better way :) -- ---Trilok Soni http://triloksoni.wordpress.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 1/2] Add Dspbridge driver to OMAP GIT kernel
On Wed, 18 Jun 2008 12:52:53 +0300, Tony Lindgren <[EMAIL PROTECTED]> wrote: > In addition, read the following: > > Documentation/CodingStyle > Documentation/SubmittingDrivers > Documentation/SubmittingPatches > Documentation/SubmitChecklist > > And then make sure scripts/checkpatch.pl will not produce errors or > obvious warnings. Otherwise this code will just get ignored by people > who should review the patches. sparse would also be quite nice :-) -- Best Regards, Felipe Balbi http://felipebalbi.com [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP PM interface, version 2
"ext Paul Walmsley" <[EMAIL PROTECTED]> writes: > Hello everyone, > > this is the second version of the OMAP PM interface patch. > > Major changes since the first version: > > 1. Jouni Hogander suggested that the set_max_cpu_lat() function be >merged into set_max_dev_wakeup_lat(), when set_max_dev_wakeup_lat() >is called with the CPU0 sys_device (via get_cpu_sysdev(0)). He feels >that this will be easier for device driver developers to use. This >change has been made. I just noticed that this won't work. We have this declaration: (*pdata->set_max_dev_wakeup_lat)(struct device *dev, unsigned long t) In case of cpu it is not possible to underlying code to identify the caller. This derives a question should we have parameter for caller identification in set_max_dev_wakeup_lat()? I mean currently we are assuming that there is only one caller for each device. Is this correct assumination? If we think e.g. busses. There might be drivers for devices on some specific bus. Each of them might want to set latency constraint for the bus. -- Jouni Högander -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 1/2] Add Dspbridge driver to OMAP GIT kernel
Hi, Some comments on integration below. * Kanigeri, Hari <[EMAIL PROTECTED]> [080617 19:49]: > Hi Koen > > > > That still seems to have the OSAL layer. I don't think the linux > > kernel needs code to support things like symbian and windows mobile. > > > > --- Thank you for your comments. Can you please elaborate your specific > concerns on the modules present in OSAL layer. Majority of the code that > is present in this OSAL layer are not acting as wrappers to the kernel > calls, and even the functions that are acting as wrappers (eg: > MEM_Alloc) provides some additional debugging feature that are very > handy in debugging some critical Bridge issues. Does renaming OSAL to > some other name address your concern ? > > Thank you, > Best regards, > Hari > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:linux-omap- > > [EMAIL PROTECTED] On Behalf Of Koen Kooi > > Sent: Saturday, June 14, 2008 3:48 AM > > To: Kanigeri, Hari > > Subject: Re: [PATCH/RFC 1/2] Add Dspbridge driver to OMAP GIT kernel > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > > > Op 14 jun 2008, om 02:01 heeft Kanigeri, Hari het volgende geschreven: > > > > > > > > This patch adds the dspbridge driver functionality for OMAP3 > platform > > > to the OMAP GIT kernel. DSP Bridge driver provides features to > control > > > and communicate with DSP enabling parallel processing for multimedia > > > acceleration. It enables the applications running on MCU to offload > > > the processing to DSP. > > > > > > Some of the key features of DSP Bridge are listed below. > > > > > > - Messaging: Ability to exchange fixed size control messages with > DSP. > > > - Dynamic memory management: Ability to dynamically map files to DSP > > > address > > > space. > > > - Dynamic loading: Ability to dynamically load new nodes on DSP at > run > > > time. > > > - Power Management: Static and dynamic power management for DSP. > > > > > > The patch is available at > > > http://www.omapzoom.org/pub/dspbridge/dspbridge_mpu_driver.patch > > > > > > The documents for reference can be accessed from > > > http://www.omapzoom.org/pub/dspbridge/db_linux_pguide.pdf > > > http://www.omapzoom.org/pub/dspbridge/db_linux_rguide.pdf > > > http://www.omapzoom.org/pub/dspbridge/ > > > Linux_Bridge_Integration_3430.pdf > > > > > > Please let me know your comments on how we can work to include the > > > Dspbridge driver source code in OMAP GIT tree. > > > > That still seems to have the OSAL layer. I don't think the linux > > kernel needs code to support things like symbian and windows mobile. > > Guys, we're trying to do things the standard Linux way. Please break your giant patch in to logical readable patches and start submitting them few patches at a time. Nobody's going to read this giant single patch. In addition, read the following: Documentation/CodingStyle Documentation/SubmittingDrivers Documentation/SubmittingPatches Documentation/SubmitChecklist And then make sure scripts/checkpatch.pl will not produce errors or obvious warnings. Otherwise this code will just get ignored by people who should review the patches. Regards, Tony > > regards, > > > > Koen > > > > > > > > > > > > > > > > Please let me know if you need any additional information or > questions > > > on dspbridge. > > > > > > Thank you, > > > Best regards, > > > Hari > > > -- > > > To unsubscribe from this list: send the line "unsubscribe linux- > > > omap" in > > > the body of a message to [EMAIL PROTECTED] > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > > > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1.4.5 (Darwin) > > > > iD8DBQFIU4XDMkyGM64RGpERAp1cAKCl1amRWN9D0LbELsk0veON+TR6RwCfUPv8 > > TPiGLJ2+cjlf0tneY0UuPHE= > > =GFHv > > -END PGP SIGNATURE- > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-omap" > in > > the body of a message to [EMAIL PROTECTED] > > 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 [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/4] McBSP support for 34XX
thanks for the comments i will make the necessary changes (for your and tony's comments) and resend it asap. - Original Message - From: "Jarkko Nikula" <[EMAIL PROTECTED]> To: "ext Chandra shekhar" <[EMAIL PROTECTED]> Cc: Sent: Wednesday, June 18, 2008 12:46 PM Subject: Re: [RFC/PATCH 0/4] McBSP support for 34XX Hi, Here is a patch that adds support for McBSP on 34XX. It has been verified in digital loopback mode. Hi, I tested the set with N810 ASoC audio and still plays :-) Some comments. First, commit messages should more descriptive than "McBSP support for 34XX" for all of them. Like: 1. Add support for OMAP34xx McBSP ports 3-4 2. Fix register access width for OMAP34xx (this should be -rc patch?) 3. ... The patch includes the following features. 1. McBSP enabled in defconfig This should go as a separate patch since it is for 3430dsp only. 2. Supporting all the LP features. 3. Support of DMA chaining mode and one time configuration for entire transfer to improve performance. 4. Independent configurations and transfer of Rx and Tx 5. MCBSP data transfer in 8, 16 and 32 bit mode. I think we should have some expected use case for these before adding the features? 6. instead of mcbsp client configuring all the register, it allows clients to configure parameters like clk polarity, clk src and other parameters. This would be good direction. E.g. it's bit hacky how configuration is now done in sound/soc/omap/omap-mcbsp.c where McBSP register cache is have to use because all of the registers are written in once with omap_mcbsp_config. Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/02] OMAP3 CPUidle driver
"ext Kevin Hilman" <[EMAIL PROTECTED]> writes: > "Rajendra Nayak" <[EMAIL PROTECTED]> writes: > >>> "Rajendra Nayak" <[EMAIL PROTECTED]> writes: >>> >>> > This patch adds the OMAP3 cpuidle driver. Irq enable/disable is done >>> > in the core cpuidle driver before it queries the governor for the >>> > next state. >>> >>> Can you explain why you need the IRQ/FIQ disable added to >>> cpuidle_idle_call() >>> >> >> This was done to prevent any interrupts firing in between a >> cpuidle_curr_governor->select() and target_state->enter(). > > I understand that, but I still don't understand exactly what you're > trying to prevent. Did you have a specific bug that this prevented? > >> An interrupt in between could end up with a previously selected >> state to be programmed. > > Remember that this function _is_ the idle loop, meaning when this runs > nothing else is happening. After the select, if other system activity > has happened (e.g. and interrupt, or thread wakeup etc.), it will run > before the target_state->enter() because of the check for > need_resched(). What happens if this interrupt, or thread wakeup causes change on latency requirements? Then we are entering sleep state which was selected using wrong latency requirement data. > >> Any suggestions on a better way to handle this? > > Just drop the IRQ/FIQ disables altogether. At least these are needed at some point in idle loop. Otherwise we might stepout from idle and sram in a point where it is not acceptable. -- Jouni Högander -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 1/4] McBSP support for 34XX
On Mon, 16 Jun 2008 17:50:58 +0530 "ext Chandra shekhar" <[EMAIL PROTECTED]> wrote: > > Signed-off-by: chandra shekhar <[EMAIL PROTECTED]> > --- > arch/arm/configs/omap_3430sdp_defconfig |1 > arch/arm/mach-omap2/mcbsp.c | 45 ++ > ++ arch/arm/plat-omap/mcbsp.c |2 - > include/asm-arm/arch-omap/mcbsp.h | 34 + > +-- 4 files changed, 79 insertions(+), 3 deletions(-) ... > +#define OMAP_MCBSP_BIT(ARG) ((0x01)<<(ARG)) > > +#define DILB OMAP_MCBSP_BIT(5) > This OMAP_MCBSP_BIT(ARG) is needless. Usual (1 << 5) convention would be better or follow the same 0x0020 convention what mcbsp.h is doing currently. Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/4] McBSP support for 34XX
> Hi, > > Here is a patch that adds support for McBSP on 34XX. > It has been verified in digital loopback mode. > Hi, I tested the set with N810 ASoC audio and still plays :-) Some comments. First, commit messages should more descriptive than "McBSP support for 34XX" for all of them. Like: 1. Add support for OMAP34xx McBSP ports 3-4 2. Fix register access width for OMAP34xx (this should be -rc patch?) 3. ... > The patch includes the following features. > > 1. McBSP enabled in defconfig This should go as a separate patch since it is for 3430dsp only. > 2. Supporting all the LP features. > 3. Support of DMA chaining mode and one time configuration for entire > transfer to improve performance. > 4. Independent configurations and transfer of Rx and Tx > 5. MCBSP data transfer in 8, 16 and 32 bit mode. > I think we should have some expected use case for these before adding the features? > 6. instead of mcbsp client configuring all the register, it allows > clients to configure parameters like clk polarity, clk src and other > parameters. > This would be good direction. E.g. it's bit hacky how configuration is now done in sound/soc/omap/omap-mcbsp.c where McBSP register cache is have to use because all of the registers are written in once with omap_mcbsp_config. Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/8] 34XX: PM: Workaround to disable mmc
"ext Madhusudhan Chikkature" <[EMAIL PROTECTED]> writes: > - Original Message - > From: ""Högander" Jouni" <[EMAIL PROTECTED]> > To: "ext Felipe Balbi" <[EMAIL PROTECTED]> > Cc: > Sent: Tuesday, June 17, 2008 5:39 PM > Subject: Re: [PATCH 7/8] 34XX: PM: Workaround to disable mmc > > >> "ext Felipe Balbi" <[EMAIL PROTECTED]> writes: >> >>> On Tue, 17 Jun 2008 10:31:11 +0300, Jouni Hogander >>> <[EMAIL PROTECTED]> wrote: Current hsmmc is not pm friendly. Disable it because it prevents omap3 retention >>> >>> Disabling will just hide the bug. Better making it modular >>> and let mmc guys dig on it. >> >> Ok, I can change it, if this set needs to be sent again. I think >> disabling mmc increases visibility of its PM problems. I mean missing >> mmc driver is more visible than missing PM in this case. >> >>> >>> What do you need to make it more pm friendly? >> >> Not to prevent omap retention. > When are you expecting the omap to go into retention? Is it in the > suspend path? I expect it to enter retention when suspending yes. It should also enter retention dynamically. I mean when mpu enters wfi in pm_idle loop. -- Jouni Högander -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
