On Thu, 2011-05-19 at 11:01 +0530, Amber Jain wrote:
Adds new color formats supported by OMAP4.
It wouldn't hurt to be a bit more descriptive. What new color formats?
Do all of them work after this patch (NV12 doesn't, I presume)? Anything
else worth mentioning? Also the subject should mention
On Thu, 2011-05-19 at 11:01 +0530, Amber Jain wrote:
fir_hinc and fir_vinc can only have a non-zero value as per TRM.
Hence removed the if...else condition and also made the necesary changes
Typo with necessary.
caused as the result of the condition removal.
Here also a bit more description
On Thu, 2011-05-19 at 11:01 +0530, Amber Jain wrote:
Adds new register definitions and simple helper functions to configure them.
Remember that the subject and the description are separate things. Even
if you mention NV12 in the subject, the description also should be
whole and mention NV12, as
On Thu, 2011-05-19 at 11:01 +0530, Amber Jain wrote:
Adds the support for NV12 color format.
Added basic scaling support for the UV-plane in case of NV12 format.
This is the most complex part of the patch set, do you feel the lines
above explain what the patch is about? What about this patch
2011/5/16 Russell King - ARM Linux li...@arm.linux.org.uk:
As nothing should be writing to the clocksource name string, make the
clocksource name pointer const. Build-tested on ARM Versatile Express.
Acked-by: Linus Walleij linus.wall...@linaro.org
Yours,
Linus Walleij
--
To unsubscribe from
Jean,
On 5/18/2011 11:02 PM, jean.pi...@newoldbits.com wrote:
From: Jean Pihetj-pi...@ti.com
Provide omap_pm_tick_nohz_get_sleep_length_us so that the code
from the OMAP PM modules can use it.
Signed-off-by: Jean Pihetj-pi...@ti.com
---
arch/arm/mach-omap2/pm-debug.c |7 ---
On 5/18/2011 11:02 PM, jean.pi...@newoldbits.com wrote:
From: Jean Pihetj-pi...@ti.com
Provide the the assembly function v7_flush_dcache_all to the
OMAP3 PM module, under CONFIG_CPU_V7.
v7_flush_dcache_all is used by the low level sleep code.
Signed-off-by: Jean Pihetj-pi...@ti.com
---
On 5/18/2011 11:02 PM, jean.pi...@newoldbits.com wrote:
From: Jean Pihetj-pi...@ti.com
Addition of EXPORT_SYMBOL for functions and variables used by
the code in PM modules.
Signed-off-by: Jean Pihetj-pi...@ti.com
---
arch/arm/kernel/setup.c|1 +
arch/arm/kernel/smp_tlb.c
Shweta Gulati shweta.gul...@ti.com writes:
To set sr ntarget values for all volt_domain,
volt_table is retrieved by doing a look_up of 'vdd_name'
field from omap_hwmod but voltage domain pointer does not
belong to omap_hwmod and is not used anywhere else.
As a part of voltage layer and SR
Hi,
On Thu, May 19, 2011 at 2:29 PM, Kevin Hilman khil...@ti.com wrote:
Shweta Gulati shweta.gul...@ti.com writes:
To set sr ntarget values for all volt_domain,
volt_table is retrieved by doing a look_up of 'vdd_name'
field from omap_hwmod but voltage domain pointer does not
belong to
-Original Message-
From: Hilman, Kevin
Sent: Wednesday, May 18, 2011 10:04 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] omap:pm: Fix boot-time errors with
debugfs disabled
Hi Sanjeev,
Sanjeev Premi pr...@ti.com writes:
There is an implicit
On Thursday 24 February 2011 04:28 PM, Cousson, Benoit wrote:
On 2/24/2011 6:42 AM, Datta, Shubhrajyoti wrote:
From: Shubhrajyoti Dshubhrajy...@ti.com
Enable the keypad in the hwmod database.
Signed-off-by: Shubhrajyoti Dshubhrajy...@ti.com
Cc: Benoit Coussonb-cous...@ti.com
Acked-by:
Nishanth Menon n...@ti.com writes:
freq_table allocated by opp_init_cpufreq_table in omap_cpu_init
needs to be freed in omap_cpu_exit.
Actually it needs to be freed by a corresponding OPP layer function.
IOW, what happens if the OPP core code switches from using kmalloc to
static tables, or
Hi,
On Thursday 19 May 2011 03:30:51 Steve Calfee wrote:
On 05/17/11 03:42, Peter Ujfalusi wrote:
Good suggestion. After switching to my codec as master, I could see the
clocks. But one problem was the beagleboardxm trainer has level
shifters, but they are one directional, and not correct for
Hi Santosh,
On Thu, May 19, 2011 at 9:59 AM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
Jean,
On 5/18/2011 11:02 PM, jean.pi...@newoldbits.com wrote:
From: Jean Pihetj-pi...@ti.com
Provide omap_pm_tick_nohz_get_sleep_length_us so that the code
from the OMAP PM modules can use it.
On Wed, May 18, 2011 at 10:22:28AM -0600, Paul Walmsley wrote:
On Mon, 9 May 2011, Avinash.H.M. wrote:
On Thu, May 05, 2011 at 03:58:56PM -0600, Paul Walmsley wrote:
The patch is based on
*
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
Nishanth Menon n...@ti.com writes:
OMAP2 does not use OPP tables at the moment for DVFS. Currently,
we depend on opp table initialization to give us the freq_table,
which makes sense for OMAP3+. for OMAP2, we should be using
clk_init_cpufreq_table - so if the opp based frequency table
On Thu, May 19, 2011 at 05:26, Kevin Hilman khil...@ti.com wrote:
Nishanth Menon n...@ti.com writes:
freq_table allocated by opp_init_cpufreq_table in omap_cpu_init
needs to be freed in omap_cpu_exit.
Actually it needs to be freed by a corresponding OPP layer function.
IOW, what happens if
On Thu, May 19, 2011 at 08:12, Kevin Hilman khil...@ti.com wrote:
Nishanth Menon n...@ti.com writes:
OMAP2 does not use OPP tables at the moment for DVFS. Currently,
we depend on opp table initialization to give us the freq_table,
which makes sense for OMAP3+. for OMAP2, we should be using
On Thu, May 19, 2011 at 05:30, Premi, Sanjeev pr...@ti.com wrote:
-Original Message-
From: Hilman, Kevin
Sent: Wednesday, May 18, 2011 10:04 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] omap:pm: Fix boot-time errors with
debugfs disabled
Hi Sanjeev,
This patch-set adds support for NV12 color format:
- Add support for various new color formats supported by OMAP4.
- Corrects the fir_hinc and fir_vinc to have a non-zero value
as per TRM.
- Add the support for NV12 along with the extra registers that needs to be
configured for the same.
-
Add new color formats supported by OMAP4: NV12, RGBA16, RGBX16,
ARGB16_1555, XRGB16_1555.
NV12 color format is defined here, its support in DSS will be added separately.
Signed-off-by: Amber Jain am...@ti.com
---
Changes from v1:
- Updated the subject to mention OMAP4.
- Listed down all the newly
FIR values can never be zero as per TRM, and the current code writes zero
when scaling is not used. It was not causing any problem as scaling was
disabled when zero was written. Its still safer to not write zero to
it in any case.
Now we configure correct FIR values even when scaling is not used
Use for loop instead of individual entries for OVL_FIR_COEF_H, OVL_FIR_COEF_HV,
OVL_FIR_COEF_V and OVL_CONV_COEF in SR() and RR().
Signed-off-by: Amber Jain am...@ti.com
---
Changes since v1:
- removed previously added for loops from DUMPREG() as that was not getting
printed correctly.
Add new registers specific to UV color component that are introduced in OMAP4.
Add simple helper functions to configure the newly added registers.
These new registers are mainly:
- UV base address registers used specifically for NV12 color-format
- FIR registers used for UV-color-component scaling
Add the support for NV12 color format.
Configure base address for UV component of NV12 color format.
Change the way chroma scaling is handled for YUV formats on OMAP4 by enabling
chroma-resampling for video pipeline and hence using FIR2 register set for
scaling UV.
Changes to _dispc_set_scaling(),
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Charulatha V ch...@ti.com
gpio_bank_count is the count of number of GPIO devices
in a SoC. Remove this dependency from the driver. Also remove
the dependency on array of pointers to gpio_bank struct of
all GPIO devices.
The cpu_is*()
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Charulatha V ch...@ti.com
Use USHRT_MAX for revision offset instead of -1 if revision register
is not available for a given SoC since rev offset is a u16 value.
Signed-off-by: Charulatha V ch...@ti.com
Cc: Santosh Shilimkar
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
We can get rid of ifdef / if checks of OMAP revision in
set_24xx_gpio_triggering()
and omap_gpio_free().
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Charulatha V ch...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc:
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
Since wake_status, wake_clear, wake_set is common for all banks on a given
OMAP version it is enough to get their values once during probe().
Also, register offsets are already initialzed according to OMAP versions
during device registration. We
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
By adding level and edge detection register offsets and then initializing them
correctly according to OMAP versions during device registrations we can now
remove
lot of revision checks in these functions.
Signed-off-by: Tarun Kanti DebBarma
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Charulatha V ch...@ti.com
Reset GPIO (OMAP_GPIO_152) for QUART in zoom2/zoom3 debug-board is
not requested at all. This would lead to problems if this GPIO is
wrongly requested. Hence request OMAP GPIO 152 for QUART RESET but
do not
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Charulatha V ch...@ti.com
In omap3, save/restore context is implemented for GPIO
banks 2-6 as GPIO bank1 is in wakeup domain. Instead
of identifying bank's power domain by bank id, make use
of a flag loses_context which is filled by
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Charulatha V ch...@ti.com
gpio_bank_count is the count of number of GPIO devices
in a SoC. Remove this dependency from the driver. Also remove
the dependency on array of pointers to gpio_bank struct of
all GPIO devices.
The cpu_is*()
On Thu, May 12, 2011 at 02:57:04AM +0200, Linus Walleij wrote:
2011/5/4 Tony Lindgren t...@atomide.com:
* Linus Walleij linus.wall...@linaro.org [110504 00:37]:
2011/5/3 Kevin Hilman khil...@ti.com:
Are you OK with a move of the current OMAP GPIO drivers (rather ugly)
into
On Thu, May 12, 2011 at 11:42:39AM +0200, Kevin Hilman wrote:
Linus Walleij linus.wall...@linaro.org writes:
[...]
For TI I guess this currently means you simply cannot work
on GPIO stuff until you know where to go with it unless you
allow the OMAP GPIO authors to keep churning in
On 05/19/11 04:28, Peter Ujfalusi wrote:
...
My codec cannot be set to use only 16 bits per phase. Is there a way to
setup the omap so that data is sent to both channels? As you can see
above the xphase bit is one saying dual channels. Is this a dma setup
problem?
I can not find datasheet
On 05/18/11 18:06, Steve Calfee wrote:
On 05/16/11 23:37, Jarkko Nikula wrote:
Did you try to run OMAP as an I2S master like what omap3pandora.c is
doing?
Missing clock in codec master configuration suggests that reason
is in codec side and reversed roles during development makes easier to
On Thu, May 19, 2011 at 01:08:41PM -0600, Grant Likely wrote:
On Thu, May 12, 2011 at 11:42:39AM +0200, Kevin Hilman wrote:
Linus Walleij linus.wall...@linaro.org writes:
[...]
For TI I guess this currently means you simply cannot work
on GPIO stuff until you know where to go with
39 matches
Mail list logo
