On Fri, Aug 10, 2012 at 11:38 AM, DebBarma, Tarun Kanti
wrote:
>
> On Thu, Aug 9, 2012 at 8:28 PM, Kevin Hilman wrote:
> > "DebBarma, Tarun Kanti" writes:
> >
> >> On Wed, Aug 8, 2012 at 10:40 PM, Kevin Hilman wrote:
> >>> Tarun Kanti DebBarma writes:
> >>>
> Add *remove* callback so that
* Mark Brown [120808 06:27]:
> On Wed, Aug 08, 2012 at 12:54:06PM +0300, Peter Ujfalusi wrote:
>
> > Changes under arch/arm/mach-omap2/ are trivial, I don't expect merge issues
> > later. If it is OK for the maintainers I would like this to go via audio
> > tree
> > (with the McBSP and the twl40
* Peter Ujfalusi [120808 02:54]:
> These boards have similar audio setup and they can all use the same driver
> for audio support if it is enabled in the kernel config.
After the naming changes suggested by Igor:
Acked-by: Tony Lindgren
--
To unsubscribe from this list: send the line "unsubscri
* Peter Ujfalusi [120808 02:54]:
> Since several OMAP3 based boards will be using the unified simple audio
> driver it is better to not have duplicated code in the board files for this
> purpose.
> Board files can call omap_twl4030_audio_init(); to set up the needed device
> for the audio support.
* Peter Ujfalusi [120808 02:42]:
> Remove the use of set_hs_extmute callback and let the codec driver to
> handle the extmute GPIO.
Acked-by: Tony Lindgren
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordom
On Thu, Aug 9, 2012 at 8:28 PM, Kevin Hilman wrote:
> "DebBarma, Tarun Kanti" writes:
>
>> On Wed, Aug 8, 2012 at 10:40 PM, Kevin Hilman wrote:
>>> Tarun Kanti DebBarma writes:
>>>
Add *remove* callback so that necessary cleanup operations are
performed when device is unregistered. Th
On Thu, Aug 9, 2012 at 10:26 PM, Rob Clark wrote:
> On Thu, Aug 9, 2012 at 12:14 AM, Andy Gross wrote:
>> Fix the following sparse warnings:
>>
>> drivers/staging/omapdrm/omap_dmm_tiler.c:123:13:
>>warning: symbol 'omap_dmm_irq_handler' was not declared.
>>Should it be static?
>>
>> drive
This is not required after commit f7df20ec
"regulator: core: Use list_voltage() to read single voltage regulators"
Signed-off-by: Axel Lin
---
drivers/regulator/twl-regulator.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/regulator/twl-regulator.c
b/drivers/regulato
"Rafael J. Wysocki" writes:
> On Thursday, August 09, 2012, Kevin Hilman wrote:
>> "Rafael J. Wysocki" writes:
>>
>> > On Thursday, August 09, 2012, Rajendra Nayak wrote:
>> >> On OMAP4, if the first CPU fails to get a valid frequency table (this
>> >> could happen if the platform does not regi
(20120809)
Changes since v1:
* addressed review comments
* moved device tree parsing to the backlight driver
Signed-off-by: Matthias Kaehlcke
---
drivers/mfd/tps65217.c| 32 +++
drivers/video/backlight/Kconfig |7 +
drivers/video/backlight/Makefile |1
On Thursday, August 09, 2012, Kevin Hilman wrote:
> "Rafael J. Wysocki" writes:
>
> > On Thursday, August 09, 2012, Rajendra Nayak wrote:
> >> On OMAP4, if the first CPU fails to get a valid frequency table (this
> >> could happen if the platform does not register any OPP table), the
> >> subsequ
On Thu, Aug 9, 2012 at 12:14 AM, Andy Gross wrote:
> Fix the following sparse warnings:
>
> drivers/staging/omapdrm/omap_dmm_tiler.c:123:13:
>warning: symbol 'omap_dmm_irq_handler' was not declared.
>Should it be static?
>
> drivers/staging/omapdrm/omap_dmm_tiler.c:370:24:
>warning: Us
Hi Peter,
On 08/09/2012 02:05 AM, Peter Ujfalusi wrote:
Hi Ricardo,
On 08/09/2012 01:12 AM, Ricardo Neri wrote:
Is this another case in which it is required to change the idle-mode on a
per-use-case basis? In the past I was trying to do the same with HDMI [1]. In
that case it was decided to ad
Rajendra Nayak writes:
> Hi Kevin,
>
> On Wednesday 08 August 2012 10:48 PM, Kevin Hilman wrote:
>>> The 4430 OPP table was being registered for all other OMAP4 variants
>>> > too, like 4460 and 4470 causing issues with cpufreq driver
>>> > enabled. 4460 and 4470 devices have different OPPs as
"Rafael J. Wysocki" writes:
> On Thursday, August 09, 2012, Rajendra Nayak wrote:
>> On OMAP4, if the first CPU fails to get a valid frequency table (this
>> could happen if the platform does not register any OPP table), the
>> subsequent CPU instances end up dealing with a NULL freq_table and
>>
"DebBarma, Tarun Kanti" writes:
> On Wed, Aug 8, 2012 at 10:40 PM, Kevin Hilman wrote:
>> Tarun Kanti DebBarma writes:
>>
>>> Add *remove* callback so that necessary cleanup operations are
>>> performed when device is unregistered. The device is deleted
>>> from the list and associated clock ha
Hi Paul,
On Thu, Aug 09, 2012 at 01:49:34, Paul Walmsley wrote:
> Hi Vaibhav
>
> On Wed, 8 Aug 2012, Bedia, Vaibhav wrote:
>
> > On Wed, Aug 08, 2012 at 19:35:50, Paul Walmsley wrote:
> >
> > > It doesn't seem to me that this would necessarily always be an error.
> > > Suppose some init code t
On 08/09/12 16:19, Igor Grinberg wrote:
> Hi Timo,
>
> On 08/09/12 15:41, Timo Kokkonen wrote:
>> The IR diode on the RX51 is connected to the GPT9. This data is needed
>> for the IR driver to function.
>>
>> Signed-off-by: Timo Kokkonen
>> ---
>> arch/arm/mach-omap2/board-rx51-peripherals.c |
On 08/09/2012 01:36 PM, Mark Brown wrote:
> On Thu, Aug 09, 2012 at 01:18:50PM +0300, Peter Ujfalusi wrote:
>> On 08/08/2012 05:49 PM, Mark Brown wrote:
>
>>> That makes sense if the GPIO is actively driven, open drain should be
>>> better here, but it's still a generic thing which it'd be nice to
On 08/09/12 15:41, Timo Kokkonen wrote:
> This is the driver for the IR transmitter diode found on the Nokia
> N900 (also known as RX51) device. The driver is mostly the same as
> found in the original 2.6.28 based kernel that comes with the device.
>
> The following modifications have been made c
Hi Timo,
On 08/09/12 15:41, Timo Kokkonen wrote:
> The IR diode on the RX51 is connected to the GPT9. This data is needed
> for the IR driver to function.
>
> Signed-off-by: Timo Kokkonen
> ---
> arch/arm/mach-omap2/board-rx51-peripherals.c | 30
> ++
> 1 files change
On 08/09/12 13:21, Peter Ujfalusi wrote:
> On 08/08/2012 04:06 PM, Igor Grinberg wrote:
>> Well, yes I know we will need to adjust the user space.
>> I wanted to change that for a long time and did not get to it...
>> Now, with your patches, it seems like the best time for doing this.
>
> Done for
This is the driver for the IR transmitter diode found on the Nokia
N900 (also known as RX51) device. The driver is mostly the same as
found in the original 2.6.28 based kernel that comes with the device.
The following modifications have been made compared to the original
driver version:
- Adopt t
The IR diode on the RX51 is connected to the GPT9. This data is needed
for the IR driver to function.
Signed-off-by: Timo Kokkonen
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-oma
These patches add the support for sending IR remote controller codes
on the Nokia N900 phone. The code is taken from the public N900 kernel
release and modified to work with today's kernel.
The code has been tested with a real Nokia N900 device and confirmed
to work. I can identify only one known
Add function omapdss_venc_get_timing() which returns the timings
maintained by the VENC interface driver in it's driver data. This is just used
once by the driver during it's probe. This prevents the need for the panel
driver to configure default timings in it's probe.
Int the VENC interface's pro
The VENC driver currently relies on the timings in omap_dss_device struct to
configure the DISPC and VENC blocks accordingly. This makes the VENC interface
driver dependent on the omap_dss_device struct.
Make the VENC driver data maintain it's own timings field. The panel driver is
expected to cal
The current venc.c driver contains both the interface and panel driver code.
This makes the driver hard to read, and difficult to understand the work split
between the interface and panel driver and the how the locking works.
This also makes it easier to clearly define the VENC interface ops calle
The SDI driver currently relies on the timings in omap_dss_device struct to
configure the DISPC accordingly. This makes the SDI interface driver dependent
on the omap_dss_device struct.
Make the SDI driver data maintain it's own timings field. The panel driver is
expected to call omapdss_sdi_set_t
Create function omapdss_sdi_set_timings(). Configuring new timings is done the
same way as before, SDI is disabled, and re-enabled with the new timings in
dssdev. This just moves the code from the panel drivers to the SDI driver.
The panel drivers shouldn't be aware of how SDI manages to configure
The hdmi interface driver exposes functions to the hdmi panel driver to
get and configure the interface timings maintained by the hdmi driver.
These timings(stored in hdmi.ip_data.cfg) should be protected by the hdmi lock
to ensure they are called sequentially, this is similar to how hdmi enable a
Add function omapdss_hdmi_display_get_timing() which returns the timings
maintained by the HDMI interface driver in it's hdmi_config field. This
prevents the need for the panel driver to configure default timings in it's
probe.
This function is just intended to be used once during the panel driver
The hdmi driver currently updates only the 'code' member of hdmi_config when
the op omapdss_hdmi_display_set_timing() is called by the hdmi panel driver.
The 'timing' field of hdmi_config is updated only when hdmi_power_on is called.
It makes more sense to configure the whole hdmi_config field in t
During a command mode update using DISPC video port, we may need to swap the
connected overlay manager's width and height when 90 or 270 degree rotation is
done via the panel by changing it's address mode.
Call dss_mgr_set_timings() in update_screen_dispc() before starting the manager
update. The
DSI command mode panels don't need to configure a full set of timings to
configure DSI, they only require the width and the height of the panel in
pixels.
Use omapdss_dsi_set_size for command mode panels, omapdss_dsi_set_timings is
meant for video mode panels. When performing rotation via chaning
The DSI driver currently relies on the timings in omap_dss_device struct to
configure the DISPC and DSI blocks accordingly. This makes the DSI interface
driver dependent on the omap_dss_device struct.
Make the DSI driver data maintain it's own timings field. A DSI video mode panel
driver is expect
The timings maintained in omap_dss_device(dssdev->panel.timings) should be
maintained by the panel driver itself. It's the panel drivers responsibility
to update it if a new set of timings is to be configured. The DPI interface
driver shouldn't be responsible of updating the panel timings, it's res
The DPI driver currently relies on the timings in omap_dss_device struct to
configure the DISPC accordingly. This makes the DPI interface driver dependent
on the omap_dss_device struct.
Make the DPI driver data maintain it's own timings field. The panel driver is
expected to call dpi_set_timings()
This is a follow up series. The orginal one can be seen here:
http://marc.info/?l=linux-omap&m=134381744304672&w=2
Changes in v2:
- Removed misc fixes out of this set
- Not trying to optimize SDI when setting new timings, using the old strategy
- Added a function for setting size for DSI command
On Wed, Aug 8, 2012 at 6:46 PM, Tomi Valkeinen wrote:
> On Wed, 2012-08-08 at 17:08 +0530, Chandrabhanu Mahapatra wrote:
>> All the cpu_is checks have been moved to dss_init_features function
>> providing a
>> much more generic and cleaner interface. The OMAP version and revision
>> specific
>>
On Sat, Jul 07, 2012 at 08:39:49AM +1000, NeilBrown wrote:
>
> Hello `./scripts/get_maintainer.pl -f drivers/usb/musb/omap2430.c`
>
> omap2430_musb_set_vbus in omap2430.c contains:
>
> while (musb_readb(musb->mregs, MUSB_DEVCTL) & 0x80) {
>
>
Hi, Tony.
On 08/08/2012 06:59 PM, Konstantin Baydarov wrote:
> Yes, omap_type() is called very early , that is why I'm using
> early_initcall for omap_control_base initialization.
>
> Do you mean following?:
> void __init omap2_set_globals_control(struct omap_globals *omap2_globals)
> {
>
On Thu, Aug 09, 2012 at 01:18:50PM +0300, Peter Ujfalusi wrote:
> On 08/08/2012 05:49 PM, Mark Brown wrote:
> > That makes sense if the GPIO is actively driven, open drain should be
> > better here, but it's still a generic thing which it'd be nice to
> > extract.
> To cover all of this in a gene
On 08/08/2012 04:06 PM, Igor Grinberg wrote:
> Well, yes I know we will need to adjust the user space.
> I wanted to change that for a long time and did not get to it...
> Now, with your patches, it seems like the best time for doing this.
Done for the v2. You will have card named "cm-t3x".
--
P
On 08/08/2012 05:49 PM, Mark Brown wrote:
> That makes sense if the GPIO is actively driven, open drain should be
> better here, but it's still a generic thing which it'd be nice to
> extract.
Yes, the idea in it's core is generic, but right now I can not think of a
generic implementation which wo
On Thursday, August 09, 2012, Rajendra Nayak wrote:
> On OMAP4, if the first CPU fails to get a valid frequency table (this
> could happen if the platform does not register any OPP table), the
> subsequent CPU instances end up dealing with a NULL freq_table and
> crash.
>
> Check for an already ex
These are minor cleanups and fixes which make some of the future work of making
outputs less dependant a bit easier. Some patches remove a few omap_dss_device
references which aren't needed any more after the patch:
"OMAPDSS: move clock settings from dssdev to dss pdata"
The rest add locking requ
The function dss_mgr_set_timings is supposed to apply timings passed by an
interface driver. It is not supposed to change the timings. Add const qualifier
to the omap_video_timings pointer argument in dss_mgr_set_timings().
Signed-off-by: Archit Taneja
---
drivers/video/omap2/dss/apply.c |4
The generic DPI panel driver doesn't currently have locking to ensure that
the display states and the driver data is maintained correctly. Add mutex
locking to take care of this. Add a new get_timings driver op to override the
default get_timings op. The new driver op contains locking to ensure the
The DPI interface driver currently relies on the panel driver to ensure calls
like omapdss_dpi_display_enable() and omapdss_dpi_display_disable() are executed
sequentially. Also, currently, there is no way to protect the DPI driver data.
All DPI panel drivers don't ensure this, and in general, a D
The clock related info for DSS modules is not tied anymore to a panel's
omap_dss_device struct. It's now passed via platform data. The function
hdmi_compute_pll() do not need the omap_dss_device argument to retieve these
clocks. They use the api dss_get_platform_clock_config() get the clocks. Remov
The clock related info for DSS modules is not tied anymore to a panel's
omap_dss_device struct. It's now passed via platform data. The functions
dpi_set_dsi_clk() and dpi_set_dispc_clk() do not need the omap_dss_device
argument to retieve these clocks. They use the api dss_get_platform_clock_config
On Thu, Aug 9, 2012 at 12:38 PM, Rajendra Nayak wrote:
> The 4430 OPP table was being registered for all other OMAP4 variants
> too, like 4460 and 4470 causing issues with cpufreq driver
> enabled. 4460 and 4470 devices have different OPPs as compared to
> 4430, and they should be populated sepera
Hi Kevin,
On Wednesday 08 August 2012 10:48 PM, Kevin Hilman wrote:
The 4430 OPP table was being registered for all other OMAP4 variants
> too, like 4460 and 4470 causing issues with cpufreq driver
> enabled. 4460 and 4470 devices have different OPPs as compared to
> 4430, and they should be
The 4430 OPP table was being registered for all other OMAP4 variants
too, like 4460 and 4470 causing issues with cpufreq driver
enabled. 4460 and 4470 devices have different OPPs as compared to
4430, and they should be populated seperately. As long as that
happens, let the OPP table registeration h
On OMAP4, if the first CPU fails to get a valid frequency table (this
could happen if the platform does not register any OPP table), the
subsequent CPU instances end up dealing with a NULL freq_table and
crash.
Check for an already existing freq_table, before trying to create one,
and increment th
Changes in v2:
Fixed the handling of freq_table_users in Patch 1/2 as
suggested by Santosh. Patch 2/2 is unchanged.
Hi Kevin,
While testing cpufreq on 3.6-rc1, I noticed strange issues on OMAP4,
like a lockup when booting with 'performace' governer as default,
and crashes when using 'usespace' (w
OMAP4 sleep entry code even though itself don't use many CPU registers
makes call to the v7_flush_dcache_all() which uses them. Since
v7_flush_dcache_all() doesn't make use of stack, the caller must take
care of the stack frame. Otherwise it will lead to corrupted stack frame.
Fix it by saving use
Hi Ricardo,
On 08/09/2012 01:12 AM, Ricardo Neri wrote:
> Is this another case in which it is required to change the idle-mode on a
> per-use-case basis? In the past I was trying to do the same with HDMI [1]. In
> that case it was decided to add the HWMOD_SWSUP_SIDLE to hwmod data with the
> drawb
59 matches
Mail list logo
