On Fri, 2012-08-24 at 11:50 +0530, Archit Taneja wrote:
> On Thursday 23 August 2012 07:15 PM, Tomi Valkeinen wrote:
> > The HDMI driver requires vdda_hdmi_dac power for operation, but does not
> > enable it. This has worked because the regulator has been always
> > enabled.
> >
> > But this may no
On Fri, 2012-08-24 at 11:30 +0530, Archit Taneja wrote:
> On Thursday 23 August 2012 07:15 PM, Tomi Valkeinen wrote:
> > We currently manage HDMI GPIOs in the board files via
> > platform_enable/disable calls. This won't work with device tree, and in
> > any case the correct place to manage the GPI
Op 24 aug. 2012, om 07:50 heeft "AnilKumar, Chimata" het
volgende geschreven:
> Hi Koen,
>
> On Thu, Aug 23, 2012 at 19:43:48, Koen Kooi wrote:
>>
>> Op 21 aug. 2012, om 13:17 heeft AnilKumar Ch het volgende
>> geschreven:
>>
>>> Add tps65217 regulator device tree data to AM335x-Bone by ad
On Thursday 23 August 2012 07:15 PM, Tomi Valkeinen wrote:
The HDMI driver requires vdda_hdmi_dac power for operation, but does not
enable it. This has worked because the regulator has been always
enabled.
But this may not always be the case, as I encountered when implementing
HDMI device tree s
On Thursday 23 August 2012 07:15 PM, Tomi Valkeinen wrote:
Currently the way to configure clocks related to DSI (both DSI and DISPC
clocks) happens via omapdss platform data. The reason for this is that
configuring the DSS clocks is a very complex problem, and it's
impossible for the SW to know r
After commit 26b88520b80695a6fa5fd95b5d97c03f4daf87e0 ("mmc:
omap_hsmmc: remove private DMA API implementation"), the Nokia N800
here stopped booting:
[2.086181] Waiting for root device /dev/mmcblk0p1...
[2.324066] Unhandled fault: imprecise external abort (0x406) at 0x
[2.331
On Thursday 23 August 2012 07:15 PM, Tomi Valkeinen wrote:
We currently manage HDMI GPIOs in the board files via
platform_enable/disable calls. This won't work with device tree, and in
any case the correct place to manage the GPIOs is in the HDMI driver.
This patch moves the handling of the GPIO
On Thursday 23 August 2012 07:15 PM, Tomi Valkeinen wrote:
Recent commit dca2b1522ccab28d03fb79f6e70e70ea78033d52 (OMAPDSS: DSI:
Maintain copy of operation mode in driver data) broke DSI for video mode
displays. The commit changed the way dssdev->caps are initialized, and
the result was that ever
Hi Koen,
On Thu, Aug 23, 2012 at 19:43:48, Koen Kooi wrote:
>
> Op 21 aug. 2012, om 13:17 heeft AnilKumar Ch het volgende
> geschreven:
>
> > Add tps65217 regulator device tree data to AM335x-Bone by adding
> > regulator consumers with tightened constraints and regulator-name.
> > TPS65217 reg
At Thu, 23 Aug 2012 20:44:32 -0500,
Ricardo Neri wrote:
>
> Hi Takashi,
>
> On 08/22/2012 02:55 AM, Takashi Iwai wrote:
> > At Tue, 21 Aug 2012 19:58:02 -0500,
> > Ricardo Neri wrote:
> >>
> >>
> >>
> >> On 08/21/2012 07:39 AM, Clark, Rob wrote:
> >>> On Tue, Aug 21, 2012 at 1:01 AM, Tomi Valkein
On 08/23/2012 07:44 PM, Ricardo Neri wrote:
> On 08/22/2012 02:55 AM, Takashi Iwai wrote:
>> At Tue, 21 Aug 2012 19:58:02 -0500,
>> Ricardo Neri wrote:
...
>>> Maybe the lack of audio support in drm is because the audio users should
>>> not talk to drm directly but to a lower level component (omapd
Hi Takashi,
On 08/22/2012 02:55 AM, Takashi Iwai wrote:
At Tue, 21 Aug 2012 19:58:02 -0500,
Ricardo Neri wrote:
On 08/21/2012 07:39 AM, Clark, Rob wrote:
On Tue, Aug 21, 2012 at 1:01 AM, Tomi Valkeinen wrote:
On Mon, 2012-08-20 at 20:47 -0500, Ricardo Neri wrote:
Hello!
I have been work
On Wed, 18 Jul 2012, Javier Martinez Canillas wrote:
> On Wed, Jul 18, 2012 at 10:36 AM, Shilimkar, Santosh
> wrote:
> > On Wed, Jul 18, 2012 at 1:14 PM, S, Venkatraman wrote:
> >> On Wed, Jul 18, 2012 at 12:40 PM, Tony Lindgren wrote:
> >>> * Shilimkar, Santosh [120718 00:09]:
> On Wed,
Signed-off-by: Peter Meerwald
---
drivers/usb/otg/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig
index 13fd1ddf..fefca18 100644
--- a/drivers/usb/otg/Kconfig
+++ b/drivers/usb/otg/Kconfig
@@ -58,7 +58,7 @@ config US
On Mon, 20 Aug 2012, Felipe Balbi wrote:
> On Mon, Aug 20, 2012 at 04:37:28PM +0530, ABRAHAM, KISHON VIJAY wrote:
> > Hi,
> >
> > On Mon, Aug 20, 2012 at 3:56 PM, Felipe Balbi wrote:
> > > On Mon, Aug 20, 2012 at 03:46:07PM +0530, ABRAHAM, KISHON VIJAY wrote:
> > >> Hi,
> > >>
> > >> On Mon, Aug
Hi Tomi,
On 08/21/2012 06:09 AM, Tomi Valkeinen wrote:
> Hi Florian,
>
> Here are two small fixes for omapfb and omapdss. The first one fixes an old
> bug
> that causes colors to be wrong on fb console. The other fixes SDI output that
> got broken in the previous merge window.
Applied both patc
On Thu, Aug 23, 2012 at 03:08:59PM -0500, Clark, Rob wrote:
> On Wed, Aug 22, 2012 at 6:49 PM, Tejun Heo wrote:
> > This is an equivalent conversion and will ease scheduled removal of
> > WQ_NON_REENTRANT.
> >
> > Only compile tested.
> >
> > Signed-off-by: Tejun Heo
>
> I've tested it
>
> Sign
On Wed, Aug 22, 2012 at 6:49 PM, Tejun Heo wrote:
> This is an equivalent conversion and will ease scheduled removal of
> WQ_NON_REENTRANT.
>
> Only compile tested.
>
> Signed-off-by: Tejun Heo
I've tested it
Signed-off-by: Rob Clark
> ---
> drivers/staging/omapdrm/omap_drv.c |3 +--
> 1
Makes it easier to just do 'make dtbs' for whatever the kernel was
configured for, just like some other platforms.
Signed-off-by: Olof Johansson
---
arch/arm/mach-omap2/Makefile.boot | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/mach-omap2/Makefile.boot
b/arch/arm/mach-omap
On Thu, Aug 23, 2012 at 09:35:01AM +0300, Peter Ujfalusi wrote:
> Fixes:
> CC arch/arm/mach-omap2/twl-common.o
> arch/arm/mach-omap2/twl-common.c:562: error: conflicting types for
> ‘omap_twl4030_audio_init’
> arch/arm/mach-omap2/twl-common.h:62: error: previous declaration of
> ‘omap_twl40
Op 21 aug. 2012, om 13:17 heeft AnilKumar Ch het volgende
geschreven:
> Add tps65217 regulator device tree data to AM335x-Bone by adding
> regulator consumers with tightened constraints and regulator-name.
> TPS65217 regulator handle can be obtained by using this regulator
> name.
>
> This pat
Safety check for the validity of the resource name before calling strcmp().
If the resource name is NULL do not compare it, just skip it.
Signed-off-by: Peter Ujfalusi
---
Hi Greg,
I have experienced with a kernel crash because the r->name was NULL when booting
OMAP4+ kernel with devicetree.
I
When booted with some resource will have their name set to NULL. This can
cause later kernel crash since this is not expected by the platform code.
When we boot without DT the devices are created with platform_device_add()
which itself fixes up the missing resource names:
if (r->name == NULL)
Recent commit dca2b1522ccab28d03fb79f6e70e70ea78033d52 (OMAPDSS: DSI:
Maintain copy of operation mode in driver data) broke DSI for video mode
displays. The commit changed the way dssdev->caps are initialized, and
the result was that every DSI display is initialized with manual-update
and tear-elim
HDMI requires vdda_hdmi_dac (vdac) power for operation. The regulator,
or the regulator supplying the vdac, has been enabled by default and
things have worked without the HDMI driver enabling the vdac.
I encountered the problem when implementing HDMI device tree support,
where the regulator was no
Currently the way to configure clocks related to DSI (both DSI and DISPC
clocks) happens via omapdss platform data. The reason for this is that
configuring the DSS clocks is a very complex problem, and it's
impossible for the SW to know requirements about things like
interference.
However, for gen
DSI clocks are now configured dynamically by the DSI driver, so we can
remove the hardcoded clock configuration from the board file.
Signed-off-by: Tomi Valkeinen
Cc: Tony Lindgren
---
arch/arm/mach-omap2/board-4430sdp.c | 46 ---
1 file changed, 46 deletions(-
Add max value of DSI functional clock to dss_features, so that DSI
driver can use it.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dss_features.c |2 ++
drivers/video/omap2/dss/dss_features.h |1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/video/omap2/dss/dss_fe
The HDMI driver requires vdda_hdmi_dac power for operation, but does not
enable it. This has worked because the regulator has been always
enabled.
But this may not always be the case, as I encountered when implementing
HDMI device tree support.
This patch changes the HDMI driver to use the vdda_h
TPD12S015A spec says to wait 300us after setting CT_CP_HPD gpio for the
5V power output to reach 90% of the voltage. This patch adds the delay
to the driver.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/hdmi.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/video/o
We currently manage HDMI GPIOs in the board files via
platform_enable/disable calls. This won't work with device tree, and in
any case the correct place to manage the GPIOs is in the HDMI driver.
This patch moves the handling of the GPIOs to the HDMI driver. The GPIO
handling is moved to the commo
Hi,
This series contains miscellaneous improvements for omapdss, which I've made
while implementing device tree support for omapdss. This includes some changes
to arch/arm/:
* remove OMAP4 HDMI gpio handling from board files
* add vdda_hdmi_dac supply for HDMI to twl-common.c
* remove DSS clock d
On 08/23/2012 02:22 PM, Mark Brown wrote:
> Which branch needs this?
for-3.7, for-next and topic/omap needs this patch.
--
Péter
--
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.kern
> Which branch needs this?
for-next for sure, haven't tested on any other
--
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
Hi Timo,
On Wed, Aug 22, 2012 at 9:50 PM, Timo Kokkonen wrote:
> The ir-rx51 driver calls omap_pm_set_max_mpu_wakeup_lat() in order to
> avoid problems that occur when MPU goes to sleep in the middle of
> sending an IR code. Without such calls it takes ridiculously long for
> the MPU to wake up f
On Thu, Aug 23, 2012 at 04:51:41PM +0530, Shubhrajyoti wrote:
> On Thursday 23 August 2012 12:12 AM, Felipe Balbi wrote:
> >> > if (_dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
> >> > omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
> >> > @@ -1266,6 +1267,15 @@ static
On Thu, Aug 23, 2012 at 09:35:01AM +0300, Peter Ujfalusi wrote:
> Fixes:
> CC arch/arm/mach-omap2/twl-common.o
> arch/arm/mach-omap2/twl-common.c:562: error: conflicting types for
> ‘omap_twl4030_audio_init’
> arch/arm/mach-omap2/twl-common.h:62: error: previous declaration of
> ‘omap_twl40
On Thursday 23 August 2012 12:12 AM, Felipe Balbi wrote:
>> >if (_dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
>> >omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
>> > @@ -1266,6 +1267,15 @@ static int omap_i2c_runtime_resume(struct device
>> > *dev)
>> >omap_i2c_wr
current code only works because struct uart_port
is the first member on the uart_omap_port structure.
If, for whatever reason, someone puts another
member as the first of the structure, that cast
won't work anymore. In order to be safe, let's use
a container_of() which, for now, gets optimized int
The driver doesn't need to know about its platform_device.
Everything the driver needs can be done through the
struct device pointer. In case we need to use the
OMAP-specific PM function pointers, those can make
sure to find the device's platform_device pointer
so they can find the struct omap_dev
quite a few changes here, though they are
pretty obvious. In summary we're making sure
to detect which interrupt type we need to
handle before calling the underlying interrupt
handling procedure.
Tested-by: Shubhrajyoti D
Acked-by: Santosh Shilimkar
Signed-off-by: Felipe Balbi
---
drivers/tty/
OMAP has some extra Interrupt types which can
be really useful for SW. Let's define them
so we can later use those in OMAP's serial driver.
Tested-by: Shubhrajyoti D
Acked-by: Santosh Shilimkar
Signed-off-by: Felipe Balbi
---
include/linux/serial_reg.h | 4
1 file changed, 4 insertions(+)
receive_chars() was getting too big and too difficult
to follow. By splitting it into separate RDI and RSLI
handlers, we have smaller functions which are easy
to understand and only touch the pieces which they need
to touch.
Tested-by: Shubhrajyoti D
Acked-by: Santosh Shilimkar
Signed-off-by: Fe
since all other IRQ types now do all necessary
checks inside their handlers, transmit_chars()
was the only one left expecting serial_omap_irq()
to check THRE for it. We can move THRE check to
transmit_chars() in order to make serial_omap_irq()
more uniform.
Tested-by: Shubhrajyoti D
Acked-by: San
if platform_get_drvdata() returns NULL, that's
quite a nasty bug on the driver which we want to
catch ASAP. Otherwise, that check is hugely
unneeded.
Tested-by: Shubhrajyoti D
Acked-by: Santosh Shilimkar
Signed-off-by: Felipe Balbi
---
drivers/tty/serial/omap-serial.c | 9 +++--
1 file cha
before removing the driver, let's make sure
to force device into a suspended state in order
to conserve power.
Tested-by: Shubhrajyoti D
Acked-by: Santosh Shilimkar
Signed-off-by: Felipe Balbi
---
drivers/tty/serial/omap-serial.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/
When we're running our hardirq handler, there's
not need to disable IRQs with spin_lock_irqsave()
because IRQs are already disabled. It also makes
no difference if we save or not IRQ flags.
Switch over to simple spin_lock/spin_unlock and
drop the "flags" variable.
Tested-by: Shubhrajyoti D
Signe
From: Ruchika Kharwar
This patch unlocks the port lock before calling a serial_core API
and re-acquires the port lock after calling it.
This patch fixes a system freeze issue seen when the serial_core
API uart_write_wakeup() eventually attempts to acquire the port lock
already acquired by omap se
if we would reach serial_omap_get_char() while
Data Ready bit isn't set, we would return from
it without kicking our pm timer. This would mean
we would, eventually, have an unbalanced
pm_runtime_get on our device which would prevent
it from ever sleeping again.
Tested-by: Shubhrajyoti D
Signed-of
by the time we call our first pm_runtme_get_sync()
after enable pm_runtime, our resume method might
be called. To avoid problems, we must make sure
that our dev->drvdata is set correctly before
our resume method gets called.
Tested-by: Shubhrajyoti D
Acked-by: Santosh Shilimkar
Signed-off-by: Fe
Everytime we're done using our TTY, we want
the pm timer to be reinitilized. By sticking
to pm_runtime_pm_autosuspend() we make sure
that this will always be the case.
The idea behind this patch is to make sure we
will always reinitialize the pm timer so that
we don't fall into a situation where p
The current support is known to be broken and
a later patch will come re-adding it using
dma engine API.
Tested-by: Shubhrajyoti D
Acked-by: Santosh Shilimkar
Signed-off-by: Felipe Balbi
---
drivers/tty/serial/omap-serial.c | 330 ++-
1 file changed, 12 inse
this patch is in preparation to a few other changes
which will align on the prototype for function
pointers passed through pdata.
It also helps cleaning up the driver a little by
agregating checks for pdata in a single location.
Tested-by: Shubhrajyoti D
Acked-by: Santosh Shilimkar
Signed-off-b
From: Ruchika Kharwar
pm_runtime_enable() needs to be invoked before
pm_runtime_use_autosuspend(), and
pm_runtime_set_autosuspend_delay() functions.
Tested-by: Shubhrajyoti D
Signed-off-by: Nishanth Menon
Signed-off-by: Ruchika Kharwar
Signed-off-by: Felipe Balbi
---
drivers/tty/serial/omap
it makes no sense to mark our IRQ handler inline
since it's passed as a function pointer when
enabling the IRQ line.
Tested-by: Shubhrajyoti D
Signed-off-by: Felipe Balbi
---
drivers/tty/serial/omap-serial.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/
This has been missing from OMAP UART driver
for quite a while and it's simple enough
to implement it.
Tested-by: Shubhrajyoti D
Signed-off-by: Felipe Balbi
---
drivers/tty/serial/omap-serial.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/tty/serial/omap-serial.c b/dri
From: Vikram Pandita
Software flow control register bits were not defined correctly.
Also clarify the IXON and IXOFF logic to reflect what userspace wants.
Cc: sta...@vger.kernel.org
Tested-by: Shubhrajyoti D
Signed-off-by: Vikram Pandita
Signed-off-by: Shubhrajyoti D
Signed-off-by: Felipe B
enable RX FIFO for 16 characters and TX FIFO
for 16 spaces.
Tested-by: Shubhrajyoti D
Signed-off-by: Felipe Balbi
---
drivers/tty/serial/omap-serial.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial
nobody needs to access the uart_omap_port structure
other than omap-serial.c file. Let's move that
structure definition to the C source file in order
to prevent anyone from accessing our structure.
Tested-by: Shubhrajyoti D
Signed-off-by: Felipe Balbi
---
arch/arm/plat-omap/include/plat/omap-se
this driver doesn't use any from , so
we can remove it without any problems.
This will, however cause a problem because omap-serial.c
was relying on indirect inclusion of ,
let's fix the issue by including
on omap-serial.c as it should be.
Tested-by: Shubhrajyoti D
Signed-off-by: Felipe Balbi
Two functions:
omap_serial_fill_features_erratas() and
of_get_uart_port_info() are only called from probe().
Marking them as __devinit gives us another
oportunity to free some code after .init.text
is done.
Tested-by: Shubhrajyoti D
Signed-off-by: Ruchika Kharwar
Signed-off-by: Felipe Balbi
---
Hi guys,
here's v3 and hopefully final version of this series. A whole bunch of new
patches added but the good thing is that now I had another engineer's help to
test, so he's got his Tested-by in all patches.
Changes since v2:
. Added a bunch of new patches
. Fixed a problem wher
Hi AnilKumar,
thanks for your comments
El Thu, Aug 23, 2012 at 07:53:49AM + AnilKumar, Chimata ha dit:
> This patch should divide into 2 patches, one patch meant for
> MFD changes other for backlight.
will do
> > +struct tps65217_bl {
> > + struct tps65217 *tps;
> > + struct device *de
On Thu, 23 Aug 2012 11:47:59 +0300
Peter Ujfalusi wrote:
> On 08/22/2012 11:19 PM, Andreas Kemnade wrote:
> > if I understand the TRM correctly, according to Figure 21-26 in chapter
> > 21.4.2.3.
> > if GSYNC is set, the receiver uses the signal from the sample rate
> > generator,
> > so CLKX d
Add the needed sections to enable audio support on BeagleBoard when booted
with DT blob.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/omap3-beagle.dts | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot
Create the sections describing the McBSP ports to be able to use them via
DT.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/omap5.dtsi | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/d
Create the sections describing the McBSP ports to be able to use them via
DT.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/omap4.dtsi | 47 ++
1 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/
Create the needed sections to be able to probe McBSP ports via DT.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/omap3.dtsi | 69 ++
1 files changed, 69 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/om
Since the board is based on OMAP2420 we should include the dedicated dtsi
file (which includes the common omap2 dtsi).
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/omap2420-h4.dts |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap2420-h4.dts
The McBSP IP within OMAP2420 and 2430 is different we need to create separate
dtsi files for them.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/omap2420.dtsi | 39 ++
arch/arm/boot/dts/omap2430.dtsi | 83 +++
2 files changed, 122 ins
Hello,
The following series will add the needed entries for OMAP McBSP for DeviceTree
and enable the audio support on BeagleBoard when booted with DT.
Regards,
Peter
---
Peter Ujfalusi (6):
ARM/dts: OMAP2: Add McBSP entries for OMAP2420 and OMAP2430 SoC
ARM/dts: omap2420-h4: Include omap2420.
On 08/22/2012 11:19 PM, Andreas Kemnade wrote:
> if I understand the TRM correctly, according to Figure 21-26 in chapter
> 21.4.2.3.
> if GSYNC is set, the receiver uses the signal from the sample rate generator,
> so CLKX does not need to be the CLKR source.
> But I tried also with the DEVCONF0 M
Hi Mark,
On 08/22/2012 10:15 PM, Mark Brown wrote:
> Applied but this didn't quite apply cleanly, please check that it did so.
The part which removes the omap_mcbsp_6pin_src_mux() function from
sound/soc/omap/mcbsp.c is the one which did not made it.
It failed to apply on top of topic/omap is th
Hi Kaehlcke,
On Thu, Aug 23, 2012 at 02:34:19, Matthias Kaehlcke wrote:
> The TPS65217 chip contains a boost converter and current sinks which can be
> used to drive LEDs for use as backlights. Expose this functionality via the
> backlight API.
>
> Tested on an AM335x based custom board with a si
Benoit,
On Monday 13 August 2012 04:30 PM, Santosh Shilimkar wrote:
These are the few device tree related patches which has been posted and
reviewed on the list. They are intended for 3.7 merge window but I am
posting them early enough to get into linux-next and linux-omap for testing.
The foll
75 matches
Mail list logo
