Currently the runtime functions are compiled regardless
of CONFIG_PM_RUNTIME flag. This patch intends to fix the same by
using SET_RUNTIME_PM_OPS.
Cc : Keshava Munegowda
Signed-off-by: Shubhrajyoti D
---
applies on Tony's ehci branch.
Compile tested only.
drivers/mfd/omap-usb-host.c |4 ++-
Hi Mark,
On Mon, Jan 02, 2012 at 18:46:48, Mark Brown wrote:
> On Mon, Jan 02, 2012 at 06:18:42PM +0530, AnilKumar Ch wrote:
> > This patch adds tps65217 PMIC as a regulator
>
> Use subject lines appropriate for the subsystem you're submitting
> against.
>
> > +config REGULATOR_TPS65217
> > +
Hi Mythri, Mark,
On Thu, 2011-12-29 at 18:48 +, Mark Brown wrote:
> On Thu, Dec 29, 2011 at 03:26:48PM +0530, K, Mythri P wrote:
>
> > We could not also try to move the ASoC HDMI audio codec driver from
> > DSS to sound, but this is good for now.
>
> You should certainly send the driver for r
On Sat, 31 Dec 2011 12:27:43 +0100 Lars-Peter Clausen wrote:
> On 12/30/2011 12:13 PM, Grazvydas Ignotas wrote:
> > CCing Lars who added this. I vaguely recall something about generating
> > events to make some battery monitors update but I forget the details
> > now, maybe it was about something
Felipe Contreras writes:
> On Sat, Dec 31, 2011 at 2:59 AM, Mark Brown
> wrote:
>> On Fri, Dec 30, 2011 at 10:00:55PM +0200, Felipe Contreras wrote:
>>> On Thu, Dec 29, 2011 at 11:54 PM, Mark Brown
>>> > On Thu, Dec 29, 2011 at 11:51:11PM +0200, Felipe Contreras wrote:
>>
>>> >> >> > That should
Hi Neil,
On Fri, Dec 30 2011, Kishore Kadiyala wrote:
> On Thu, Dec 29, 2011 at 8:35 PM, NeilBrown wrote:
>>
>>
>> As the card-detect irq handler just schedules work to be done by
>> a thread, we can use request_threaded_irq to do much of the work for
>> us. This means that interrupts which arri
On Mon, Jan 02, 2012 at 08:33:03PM +0200, Felipe Contreras wrote:
> On Sat, Dec 31, 2011 at 2:59 AM, Mark Brown
> > Which is relevant because...? To repeat, the ordering of module loading
> > is totally ortogonal as any ordering of modules is supported. You
> > appear to be totally ignoring what
On Sat, Dec 31, 2011 at 2:59 AM, Mark Brown
wrote:
> On Fri, Dec 30, 2011 at 10:00:55PM +0200, Felipe Contreras wrote:
>> On Thu, Dec 29, 2011 at 11:54 PM, Mark Brown
>> > On Thu, Dec 29, 2011 at 11:51:11PM +0200, Felipe Contreras wrote:
>
>> >> >> > That should not be required, the modules should
On Mon, Jan 02, 2012 at 06:18:42PM +0530, AnilKumar Ch wrote:
> This patch adds tps65217 PMIC as a regulator
Use subject lines appropriate for the subsystem you're submitting
against.
> +config REGULATOR_TPS65217
> + tristate "TI TPS65217 Power regulators"
> + depends on (I2C && MFD_TPS65
This patch adds tps65217 PMIC as a regulator
The regulator module consists of 3 DCDCs and 4 LDOs. The output
voltages are configurable and are meant to supply power to the
main processor and other components
Signed-off-by: AnilKumar Ch
---
drivers/regulator/Kconfig |9 +
driver
The TPS65217 chip is a power management IC for Portable Navigation Systems
and Tablet Computing devices. It contains the following components:
- Regulators
- White LED
- USB battery charger
This patch adds support for tps65217 mfd device. At this time only
the regulator functionality is made avai
TPS65217 power management IC supports various features, like
Battery charger, white LED driver along with basic regulator
Functionality.
This patch set adds support as an MFD device into the kernel
to facilitate adding additional drivers on top of it.
This device is used on one of AM335x platform
On Fri, Dec 30, 2011 at 04:04:56AM +0100, Janusz Krzysztofik wrote:
> This functionality has just been implemented in the cx20442 codec
> driver, no need to keep it here duplicated.
Acked-by: Mark Brown
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a mess
On Fri, Dec 30, 2011 at 04:04:54AM +0100, Janusz Krzysztofik wrote:
> Now that a regulator device for controlling the codec chip reset state
> over a platform agnostic regulator API is available on the only board
> using this driver so far, extend the driver with a bias control function
> which wil
On Mon, Jan 02, 2012 at 09:48:40AM +, AnilKumar, Chimata wrote:
> I am discussing with hardware folks on what to do about this, but for
> now I will skip interpreting the CHIPID. I can print it out for reference
> though.
Logging for diagnostics is probably enough - it'll verify that register
Hi Vaibhav,
On Mon, Jan 2, 2012 at 2:55 PM, Bedia, Vaibhav wrote:
> Hello,
>
> On Fri, Nov 11, 2011 at 15:31:52, R, Govindraj wrote:
> [...]
>>
>> - if ((cpu_is_omap34xx() || cpu_is_omap44xx()) && bdata->pads)
>> + if (((cpu_is_omap34xx() || cpu_is_omap44xx()) && bdata->pads)
>> +
Hi Mark,
> >
> > > +/* All register addresses */
> > > +#define TPS65217_REG_CHIPID 0X00
> >
> > You should verify this as part of the probe() routine - read it back to
> > make sure it's what's expected, and log the chip revision too in case it
> > is useful for diagnostics.
> >
>
Hello,
On Fri, Nov 11, 2011 at 15:31:52, R, Govindraj wrote:
[...]
>
> - if ((cpu_is_omap34xx() || cpu_is_omap44xx()) && bdata->pads)
> + if (((cpu_is_omap34xx() || cpu_is_omap44xx()) && bdata->pads)
> + && !uart_debug)
> device_init_wakeup(&pdev->dev, t
From: Mythri P K
Configure the IP to support the limited range and full range quantization
mode. If the full range is configured HDMI transmitter will expand the range
of pixel data from 16-235 to full 8 bit 0-235.
Signed-off-by: Mythri P K
---
drivers/video/omap2/dss/ti_hdmi.h |7
From: Mythri P K
With AVI infoframe various parameters of video stream such as
aspect ratio, quantization range, videocode etc will be indicated
from source to sink.Thus AVI information needs to be set/accessed
by the middle ware based on the video content.
Thus this parameter is now moved to the
From: Mythri P K
Add sysfs support for the uset space to configure limited range or full range
quantization for HDMI.
Signed-off-by: Mythri P K
---
drivers/video/omap2/dss/dss.h |2 +
drivers/video/omap2/dss/dss_features.c |1 +
drivers/video/omap2/dss/hdmi.c | 28 ++
From: Mythri P K
With AVI infoframe various parameters of video stream such as
aspect ratio, quantization range, videocode etc will be indicated
from source to sink.Thus AVI information needs to be set/accessed
by the middle ware based on the video content.
Thus this parameter is now moved to the
On Thu, Dec 22, 2011 at 03:56:37PM +0100, Benoit Cousson wrote:
> Add initial device-tree support for twl familly chips.
> The current version is missing the regulator entries due
> to the lack of DT regulator bindings for the moment.
> Only the simple sub-modules that do not depend on
> platform_d
From: Mythri P K
Add the vsync polarity, hsync polarity, interlace to hdmi_video_timings.
Remove the now duplicate structure hdmi_timings.
update the static table structure in HDMI with CEA/VESA code and mode.
Signed-off-by: Mythri P K
---
drivers/video/omap2/dss/hdmi.c| 96 +
From: Mythri P K
Change the timing match logic, Instead of the statically mapped method
to get the corresponding timings for a given code and mode, move to a
simpler array indexed method. It will help to scale up to add more
timings when needed.
Signed-off-by: Mythri P K
---
drivers/video/oma
From: Mythri P K
code and mode parameters are already a part of the ip_data structure
so no need to keep the same parameters again in hdmi global structure.
Signed-off-by: Mythri P K
---
drivers/video/omap2/dss/hdmi.c | 18 +++---
1 files changed, 7 insertions(+), 11 deletions(-)
From: Mythri P K
video interface structure is a duplicate structure with parameters which are
already present in ip_data config structure, Thus removing the structure and
modifying corresponding code.
Signed-off-by: Mythri P K
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 31 +++---
From: Mythri P K
There are some duplicate timing structure which are not needed thus removing
them to clean the code.
Also the static mapped timing structure is quite complicated to add new
timings, so simplify it by using array indexed method.
changes since V1: change of hdmi_find_timing functi
From: Mythri P K
Disables the internal pull resistor for SDA and SCL which are enabled by
default, as there are external pull up's in 4460 and 4430 ES2.3
SDP, Blaze and Panda Boards, It is done to avoid the EDID read failure.
Signed-off-by: Ricardo Salveti de Araujo
Signed-off-by: Mythri P K
-
From: Mythri P K
Move duplicate HDMI mux_init code from omap4 and panda board file
to display file.
Signed-off-by: Mythri P K
---
arch/arm/mach-omap2/board-4430sdp.c| 16 +---
arch/arm/mach-omap2/board-omap4panda.c | 17 +
arch/arm/mach-omap2/display.c
From: Mythri P K
Clean up of boardfiles to have the functions common to differnt boards in a
common display file, Also in some OMAP4 boards external pull-up's are enabled
thus enabling internal pull up should be a parameter from the boardfile.
changes since v3 : Comment improvement to move some
31 matches
Mail list logo