On Thu, Aug 16, 2012 at 22:27:42, Hunter, Jon wrote:
>
> On 08/15/2012 04:13 AM, Vaibhav Hiremath wrote:
> >
> >
> > On 7/14/2012 3:56 AM, Jon Hunter wrote:
> >> OMAP3 devices may or may not have security features enabled. Security
> >> enabled
> >> devices are known as high-secure (HS) and dev
On Mon, Aug 13, 2012 at 10:57:06AM +0530, Shilimkar, Santosh wrote:
> Greg,
>
> On Wed, Jul 18, 2012 at 12:14 PM, Shilimkar, Santosh
> wrote:
> > On Tue, Jul 17, 2012 at 11:28 PM, Greg KH
> > wrote:
> >> On Tue, Jul 17, 2012 at 10:37:45PM +0530, Shilimkar, Santosh wrote:
> >>> On Tue, Jul 17, 2
On 08/16/12 19:34, Sakari Ailus wrote:
> Hi Sebastian,
>
> On Thu, Aug 16, 2012 at 01:21:04PM +0200, Sebastian Reichel wrote:
>> Hi,
>>
It was an requirement back then that this driver needs to be a module as
99% of the N900 owners still don't even know they have this kind of
capabi
On 08/15/2012 04:13 AM, Vaibhav Hiremath wrote:
>
>
> On 7/14/2012 3:56 AM, Jon Hunter wrote:
>> OMAP3 devices may or may not have security features enabled. Security enabled
>> devices are known as high-secure (HS) and devices without security are known
>> as
>> general purpose (GP).
>>
>> For
Hi Sebastian,
On Thu, Aug 16, 2012 at 01:21:04PM +0200, Sebastian Reichel wrote:
> Hi,
>
> > > It was an requirement back then that this driver needs to be a module as
> > > 99% of the N900 owners still don't even know they have this kind of
> > > capability on their devices, so it doesn't make s
Remove the call of platform_set_drvdata(pdev, NULL) as they are not
needed anymore.
Signed-off-by: Shubhrajyoti D
---
drivers/spi/spi-omap2-mcspi.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index bc4778
Hi Vaibhav,
On 08/15/2012 04:11 AM, Vaibhav Hiremath wrote:
>
>
> On 7/23/2012 8:54 PM, Jon Hunter wrote:
>> Hi Rob,
>>
>> On 07/16/2012 10:56 AM, Jon Hunter wrote:
>>> Hi Rob,
>>>
>>> On 07/13/2012 09:15 PM, Rob Herring wrote:
On 07/13/2012 05:26 PM, Jon Hunter wrote:
> Add the 12 GP t
On Thu, Aug 16, 2012 at 07:33:31PM +0530, Shubhrajyoti D wrote:
> Changes since v1:
>- removed tabification on patch 6/17
>- removed dev_err() which was introduced on patch 09/17
> Changes since v2:
> - do not set full fifo depth in the RDR interrupt.
> - some change
From: Felipe Balbi
move the goto out label one line down, so that
it can be used when stat is read as zero. All
other exits, can be done with a break statement.
While at that, also break out as soon as we
complete draining IRQ, since at that time
we know we transferred everything there was
to be
From: Felipe Balbi
for OMAP2, we can easily switch over to threaded
IRQs on the I2C driver. This will allow us to
spend less time in hardirq context.
Signed-off-by: Felipe Balbi
[Trivial formating changes]
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 43
From: Felipe Balbi
this helps us reduce unnecessary pm transitions
in case we have another i2c message starting soon.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git
From: Felipe Balbi
before starting any messages we call pm_runtime_get_sync()
which will make sure that by the time we program a transfer
and our IRQ handler gets called, we're not suspended
anymore.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c |
From: Felipe Balbi
omap_i2c_dev is allocated with kzalloc(),
so we need not initialize b_hw to zero.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-o
Prevent the NULL pointer access of pdev. The platform_device is anyways
deleted so remove platform_set_drvdata(pdev, NULL);.
[ 654.961761] Unable to handle kernel NULL pointer dereference at virtual
address 0070
[ 654.970611] pgd = df254000
[ 654.973480] [0070] *pgd=9f1da831, *pte=000
From: Felipe Balbi
re-factor the common parts to a separate function,
so that code is easier to read and understand.
No functional changes.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 204
1 files cha
From: Felipe Balbi
This patch will try to avoid the usage of
draining feature by reconfiguring the FIFO
the start condition of each message based
on the message's size.
By doing that, we will be better utilizing
the FIFO when doing big transfers.
While at that also drop the now unneeded
check f
From: Felipe Balbi
this will make sure that we execute at least once.
No functional changes otherwise.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 20 ++--
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/drive
From: Felipe Balbi
trivial patch to aid readability. No functional
changes.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/buss
From: Felipe Balbi
trivial patch, no functional changes
If the fifo is disabled or fifo_size is 0 the num_bytes
is set to 1. Else it is set to fifo_size or in case of a
draining interrupt the remaining bytes in the buff stat.
So the zero check is redundant and can be safely optimised.
Signed-of
From: Felipe Balbi
Make it not depend on ISR's local variables
in order to make it easier to re-factor the
transmit data loop.
Also since we are waiting for XUDF(Transmitter underflow) just before
writing data lets not flag the underflow.
This is anyways going to go once we write
the data.
Signe
From: Felipe Balbi
stat & BIT(1) is the same as BIT(1), so let's
simplify things a bit by removing "stat &" from
all omap_i2c_ack_stat() calls.
Code snippet (extremely simplified):
if (stat & NACK) {
...
omap_i2c_ack_stat(dev, stat & NACK);
}
if (stat & RDR) {
...
From: Felipe Balbi
The patch intends to decrease the indentation level on the
data handling
by using the fact that else of if (dev->buf_len) is same as
if (!dev->buf_len)
if (dev->buf_len) {
aaa;
} else {
bbb;
break;
}
to
if (!dev->buf_len) {
bbb;
break;
From: Felipe Balbi
we can ack stat and complete the command from
the errata handling itself.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/
From: Felipe Balbi
that's a nice helper from drivers core which
will give us the exact IRQ number, instead
of a pointer to an IRQ resource.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 12 +++-
1 files changed, 7 insertions(+), 5 dele
From: Felipe Balbi
that helps deleting some boiler plate code
and lets driver-core manage our resources
for us.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 41 -
1 files changed, 12 insertions(+), 29 d
From: Felipe Balbi
instead of having multiple return points, use
a goto statement to make that clearer.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 20
1 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/driv
From: Felipe Balbi
While they do pretty much the same thing, there
are a few peculiarities. Specially WRT erratas,
it's best to split those out and re-factor the
read/write loop to another function which both
cases call.
This last part will be done on another patch.
While at that, also avoid an
From: Felipe Balbi
that way we can ignore TX IRQs while in receiver
mode and ignore RX IRQs while in transmitter mode.
Signed-off-by: Felipe Balbi
[Remove unnecessary braces]
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c |8
1 files changed, 8 insertions(+), 0 d
Changes since v1:
- removed tabification on patch 6/17
- removed dev_err() which was introduced on patch 09/17
Changes since v2:
- do not set full fifo depth in the RDR interrupt.
- some changelog updates.
- rebase to the Wolfram's tree.
Changes since v3:
From: Felipe Balbi
even if our clocks are disabled, we still
handled the IRQ, so we should return IRQ_HANDLED.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/buss
Remove the redundant read of the status register.
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index dfdcc2b..2dd2301 100644
--- a/drivers/i2
From: Felipe Balbi
According to flow diagrams on OMAP TRMs,
we should ACK the IRQ as they happen.
Signed-off-by: Felipe Balbi
[Ack the stat OMAP_I2C_STAT_AL in case of arbitration lost]
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 28
1 file
From: Felipe Balbi
Always return IRQ_HANDLED otherwise we could get our IRQ line disabled due
to many spurious IRQs.
Signed-off-by: Felipe Balbi
[Trivial changes to commitlogs]
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c |2 +-
1 files changed, 1 insertions(+), 1 delet
On Thu, Aug 16, 2012 at 01:22:27PM +, AnilKumar, Chimata wrote:
> But problem here is single input supply battery/main is not sufficient.
What makes you say this?
> pmic->desc[i].supply_name = info->vin_name;
> with this assignment regulator core searches for exact supply name vcc1 or
> vcc2
Device tree support for McBSP modules on OMAP2+ SoC.
Signed-off-by: Peter Ujfalusi
---
.../devicetree/bindings/sound/omap-mcbsp.txt | 45 +
sound/soc/omap/omap-mcbsp.c| 66 +++-
2 files changed, 110 insertions(+), 1 deletions(-)
crea
Only create the devices in a legacy way if we do not have the DT data.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-omap2/mcbsp.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 660e00b..d57a357 100644
We can use the has_ccr flag to replace the cpu_is_omap* checks.
This provides future proof implementation and we do not need to update the
code if new OMAP revision starts to use the McBSP driver.
Signed-off-by: Peter Ujfalusi
Acked-by: Jarkko Nikula
---
sound/soc/omap/omap-mcbsp.c |8 +
NUM_LINKS is no longer in use by the code.
Signed-off-by: Peter Ujfalusi
Acked-by: Jarkko Nikula
---
sound/soc/omap/omap-mcbsp.h | 16
1 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.h b/sound/soc/omap/omap-mcbsp.h
index baebcee..ba83
Remove the feature to configure the CLKR/FSR mux on McBSP port with 6pin
configuration.
When moving to devicetree these callback can no longer be used in a clean
way anymore.
If a board require to change the 6pin port to work in 4pin setup it needs
to set up the mux in the board file.
For OMAP2/3:
The muxing is done at board level, no need to do it in the ASoC machine
driver.
Signed-off-by: Peter Ujfalusi
Acked-by: Jarkko Nikula
---
sound/soc/omap/am3517evm.c | 20 ++--
1 files changed, 2 insertions(+), 18 deletions(-)
diff --git a/sound/soc/omap/am3517evm.c b/sound/so
am3517evm board uses McBSP1 for audio with 4pin configuration.
The CLKR/FSR signals need to be connected to CLKX/FSX pin of the SoC in
this case.
Signed-off-by: Peter Ujfalusi
Acked-by: Jarkko Nikula
---
arch/arm/mach-omap2/board-am3517evm.c | 13 +
1 files changed, 13 insertions(
On OMAP2430 all McBSP ports have 128 word long buffer, enable the use of
the FIFO for the audio stack.
Signed-off-by: Peter Ujfalusi
Acked-by: Jarkko Nikula
---
arch/arm/mach-omap2/mcbsp.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b
Move the McBSP CLKS re-parenting code to ASoC driver from
arch/arm/mach-omap2.
The call fort the re-parenting has been already limited to OMAP2+ SoC in
the ASoC driver. There is no longer need to have callback function for it.
Signed-off-by: Peter Ujfalusi
Acked-by: Jarkko Nikula
---
arch/arm/m
Hello,
Changes since v2:
- Replaced the IS_ERR_OR_NULL() with IS_ERR()
Changes since v1:
- ICLK workaround for the sidetone module has been kept for legacy mode.
Intro mail from v2:
in order to be able to add DT support for the McBSP driver which is used on all
OMAP platforms (OMAP1/2/3/4/5) I
Mark,
Small correction
On Thu, Aug 16, 2012 at 18:52:25, AnilKumar, Chimata wrote:
> Mark,
>
> On Wed, Aug 15, 2012 at 22:24:32, Mark Brown wrote:
> > On Wed, Aug 15, 2012 at 04:47:02PM +, AnilKumar, Chimata wrote:
> > > On Wed, Aug 15, 2012 at 18:23:39, Mark Brown wrote:
> >
> > > > If you
Mark,
On Wed, Aug 15, 2012 at 22:24:32, Mark Brown wrote:
> On Wed, Aug 15, 2012 at 04:47:02PM +, AnilKumar, Chimata wrote:
> > On Wed, Aug 15, 2012 at 18:23:39, Mark Brown wrote:
>
> > > If you have all these unrelated supplies in the system then your device
> > > tree should accurately refl
On Thu, Aug 16, 2012 at 8:00 AM, Ville Syrjälä
wrote:
> On Wed, Aug 15, 2012 at 03:18:02PM -0500, Rob Clark wrote:
>> From: Andre Renaud
>>
>> Added support for zorder changes through DRM plane properties
>>
>> Signed-off-by: Andre Renaud
>> Signed-off-by: Rob Clark
>> ---
>> drivers/staging/o
On Thu, 2012-08-16 at 17:57 +0530, Archit Taneja wrote:
> On Thursday 16 August 2012 05:08 PM, Tomi Valkeinen wrote:
> > On Thu, 2012-08-16 at 13:06 +0530, Archit Taneja wrote:
> >> The VENC driver currently relies on the omap_dss_device struct to
> >> configure the
> >> video output polarity. Thi
On Wed, Aug 15, 2012 at 03:18:02PM -0500, Rob Clark wrote:
> From: Andre Renaud
>
> Added support for zorder changes through DRM plane properties
>
> Signed-off-by: Andre Renaud
> Signed-off-by: Rob Clark
> ---
> drivers/staging/omapdrm/omap_drv.h |1 +
> drivers/staging/omapdrm/omap_pl
On Thursday 16 August 2012 05:08 PM, Tomi Valkeinen wrote:
On Thu, 2012-08-16 at 13:06 +0530, Archit Taneja wrote:
The VENC driver currently relies on the omap_dss_device struct to configure the
video output polarity. This makes the VENC interface driver dependent on the
omap_dss_device struct.
On Thu, 2012-08-16 at 17:41 +0530, Archit Taneja wrote:
> On Thursday 16 August 2012 04:49 PM, Tomi Valkeinen wrote:
> > On Thu, 2012-08-16 at 13:06 +0530, Archit Taneja wrote:
> >> The DSI driver currently relies on the omap_dss_device struct to know the
> >> mode
> >> of operation of the DSI pro
Adds basic pinctrl device tree data for AM33XX family of devices.
This patch is based on the pinctrl-single driver.
Signed-off-by: AnilKumar Ch
---
Changes from v3:
- Updated the reg length based on latest AM335x TRM.
Changes from v2:
- user led pinmux comments updated according
Adds GPIO pinctrl nodes to am3358_pinmux master node to control
user leds (USR0, USR1, USR2 and USR3) present on BeagleBone.
Signed-off-by: AnilKumar Ch
---
arch/arm/boot/dts/am335x-bone.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
Add Bosch D_CAN controller device tree data to AM33XX dtsi
file by adding d_can device nodes with all the necessary
parameters.
Signed-off-by: AnilKumar Ch
---
arch/arm/boot/dts/am335x-evm.dts |4
arch/arm/boot/dts/am33xx.dtsi| 18 ++
2 files changed, 22 insertions
Add D_CAN1 pinctrl node to am3358_pinmux master node to export
D_CAN functionality on AM335x EVM according to pinctrl-single
driver.
Signed-off-by: AnilKumar Ch
---
Changes from v2:
- Incorporated Vaibhav H's comments on v2
* Added dcan0 instances to am33xx.dtsi file
Changes fr
Add pinctrl and d_can device tree data to AM33XX family of devices.
First two patches add support for pinctrl DT data and rest adds
dcan DT data.
Reason behind combining these patches is to apply cleanly on
linux-omap devel-dt tree because these are sequential patches.
These patches were tested o
On Thu, 2012-08-16 at 17:27 +0530, Archit Taneja wrote:
> On Thursday 16 August 2012 05:01 PM, Tomi Valkeinen wrote:
> > On Thu, 2012-08-16 at 13:06 +0530, Archit Taneja wrote:
> >> The DSI driver currently relies on the omap_dss_device struct to receive
> >> the
> >> video mode timings requested
TWL6040 provides GPO lines to be used for controlling external devices.The
number
of lines different between versions: twl6040 have 3 GPO while TWL6041 have 1.
Signed-off-by: Sergio Aguirre
Signed-off-by: Peter Ujfalusi
Acked-by: Linus Walleij
---
drivers/gpio/Kconfig|7 ++
driver
Add needed platform data structure and code to be able to load
the GPO child of twl6040.
Update the devicetree binding documentation at the same time.
Signed-off-by: Sergio Aguirre
Signed-off-by: Peter Ujfalusi
---
Documentation/devicetree/bindings/mfd/twl6040.txt |9 ++---
drivers/mfd/
Signed-off-by: Peter Ujfalusi
---
include/linux/mfd/twl6040.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/mfd/twl6040.h b/include/linux/mfd/twl6040.h
index eaad49f..269b706 100644
--- a/include/linux/mfd/twl6040.h
+++ b/include/linux/mfd/twl6040.h
@@ -1
Hello,
Changes since v1:
- Removed the ti,use-gpo property from DT bindings
- Register the GPO driver if we booted with DT blob or in legacy if the pdata
for the GPO driver is present
- DT binding Documentation update
The Documentation update has reference to the twl6040.dtsi file which will be
On Thursday 16 August 2012 04:49 PM, Tomi Valkeinen wrote:
On Thu, 2012-08-16 at 13:06 +0530, Archit Taneja wrote:
The DSI driver currently relies on the omap_dss_device struct to know the mode
of operation of the DSI protocol(command or video mode). This makes the DSI
interface driver dependent
On Thursday 16 August 2012 05:01 PM, Tomi Valkeinen wrote:
On Thu, 2012-08-16 at 13:06 +0530, Archit Taneja wrote:
The DSI driver currently relies on the omap_dss_device struct to receive the
video mode timings requested by the panel driver. This makes the DSI interface
driver dependent on the o
Hi,
> > It was an requirement back then that this driver needs to be a module as
> > 99% of the N900 owners still don't even know they have this kind of
> > capability on their devices, so it doesn't make sense to keep the module
> > loaded unless the user actually needs it.
>
> I don't think tha
On Thu, 2012-08-16 at 13:06 +0530, Archit Taneja wrote:
> The VENC driver currently relies on the omap_dss_device struct to configure
> the
> video output polarity. This makes the VENC interface driver dependent on the
> omap_dss_device struct.
>
> Make the VENC driver data maintain it's own pola
On Thu, 2012-08-16 at 13:06 +0530, Archit Taneja wrote:
> The DSI driver currently relies on the omap_dss_device struct to receive the
> video mode timings requested by the panel driver. This makes the DSI interface
> driver dependent on the omap_dss_device struct.
>
> Make the DSI driver data mai
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
initializations in various functions are cleaned and the necessary data are
moved to dss_features structure which is local to dss.c.
Signe
All the cpu_is checks have been moved to dispc_init_features function providing
a much more generic and cleaner interface. The OMAP version and revision
specific functions and data are initialized by dispc_features structure which is
local to dispc.c.
Signed-off-by: Chandrabhanu Mahapatra
---
dr
On Thu, 2012-08-16 at 13:06 +0530, Archit Taneja wrote:
> The DSI driver currently relies on the omap_dss_device struct to know the mode
> of operation of the DSI protocol(command or video mode). This makes the DSI
> interface driver dependent on the omap_dss_device struct.
>
> Make the DSI driver
Variable ret is always evaluated as true, so we don't need to check it.
Signed-off-by: Matthias Brugger
---
drivers/usb/musb/omap2430.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 5fdb9da..2d207c6 10064
On Thu, Aug 16, 2012 at 12:22:14PM +0200, Matthias Brugger wrote:
> Signed-off-by: Matthias Brugger
I need a commit log, even if obvious.
--
balbi
signature.asc
Description: Digital signature
Moi,
On Wed, Aug 15, 2012 at 10:46:43PM +0300, Timo Kokkonen wrote:
> Long time no see.
Indeed! Better late than never I guess. :)
> On 08/15/12 19:06, Sakari Ailus wrote:
> > Heippa,
> >
> > Thanks for the patch! I know Mauro has already applied this so any changes
> > would make a separate pa
Signed-off-by: Matthias Brugger
---
drivers/usb/musb/omap2430.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 5fdb9da..2d207c6 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@
On Thu, Aug 16, 2012 at 03:56:42, Paul Walmsley wrote:
> Hi
>
> On Mon, 9 Jul 2012, Tony Lindgren wrote:
>
> > Below (untested) is what could be done in the short term.
>
> That's fine with me. Do you want to queue it or do you want me to queue
> it?
>
> > Heh these CK_ defines are now ru
* Paul Walmsley [120815 15:27]:
> Hi
>
> On Mon, 9 Jul 2012, Tony Lindgren wrote:
>
> > Below (untested) is what could be done in the short term.
>
> That's fine with me. Do you want to queue it or do you want me to queue
> it?
Probably best for you to take it along with other related patche
* Radek Pilar [120815 14:00]:
> Hello,
> a few months ago, Always Innovating - a company behind their OMAP3 based
> product Touchbook basically stopped production. I've been porting some
> specific drivers for current kernels since then and I'd like to push at
> least some of them to the mainline.
On Wednesday 15 August 2012 03:40 AM, Aaro Koskinen wrote:
It seems commit 2098e95ce9bb039ff2e7bf836df358d18a176139 (regulator: twl:
adapt twl-regulator driver to dt) accidentally deleted VINTANA1. Also
the same commit defines VINTANA2 twice with TWL4030_ADJUSTABLE_LDO and
TWL4030_FIXED_LDO. This
The VENC driver currently relies on the omap_dss_device struct to configure the
video output polarity. This makes the VENC interface driver dependent on the
omap_dss_device struct.
Make the VENC driver data maintain it's own polarity field. A panel driver
is expected to call omapdss_venc_set_vid_o
The VENC driver currently relies on the omap_dss_device struct to configure the
venc type. This makes the VENC interface driver dependent on the omap_dss_device
struct.
Make the VENC driver data maintain it's own 'venc type' field. A panel driver
is expected to call omapdss_venc_set_type() before
The RFBI driver currently relies on the omap_dss_device struct to receive the
rfbi specific timings requested by the panel driver. This makes the RFBI
interface driver dependent on the omap_dss_device struct.
Make the RFBI driver data maintain it's own rfbi specific timings field. The
panel driver
The DSI driver currently relies on the omap_dss_device struct to receive the
video mode timings requested by the panel driver. This makes the DSI interface
driver dependent on the omap_dss_device struct.
Make the DSI driver data maintain it's own video mode timings field. The panel
driver is expec
The struct omap_dss_dsi_videomode_data holds fields which need to be configured
for DSI to operate in video mode. Rename the struct to dsi_videomode_timings.
One reason to do this is because most of the fields in the struct are timings
related. The other reason is to create a generic op for output
The DSI driver currently relies on the omap_dss_device struct to know the mode
of operation of the DSI protocol(command or video mode). This makes the DSI
interface driver dependent on the omap_dss_device struct.
Make the DSI driver data maintain it's own operation mode field. The panel
driver is
This is a continuation of the series below:
http://marc.info/?l=linux-omap&m=134381744304672&w=2
This series tries to pass output specific parameters from panel driver to the
connected output. These are basically parameters which can't really be shared
across different outputs. An attempt has bee
84 matches
Mail list logo
