Hi,
On 2013-02-08 17:43, Ruslan Bilovol wrote:
Hi,
This patch adds support for TC358765 DSI-to-LVDS transmitter
from Toshiba, that is used in OMAP4 Blaze Tablet development
platform. It was originally developed a long time ago and
was used internally survived few kernel migrations.
Current CPU PM code code make use of common cpu_suspend() path for all the
CPU power states which is not optimal. In fact cpu_suspend() path is needed
only when we put CPU power domain to off state where the CPU context is lost.
Update the code accordingly so that the expensive cpu_suspend() path
On Tue, Feb 12, 2013 at 08:01:05PM +, Loic PALLARDY wrote:
Hi Mark,
Thanks for your comments.
On 02/12/2013 11:39 AM, Mark Rutland wrote:
Hello,
I have a few comments on the devicetree binding and the way it's parsed.
+static const struct of_device_id dbx500_mailbox_match[] =
Hi Tony,
These patches were send as seperate ones before[1], but did not recieve any
comments. Resending them all as a single patch series, as some affect the same
files.
[1]: https://patchwork.kernel.org/patch/2054891/
https://patchwork.kernel.org/patch/2054871/
Add mcspi node and pinmux data for omap5 mcspi controller.
Tested on omap5430 evm with 3.8-rc6 custom kernel.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/omap5-evm.dts | 46 +++
1 files changed, 46 insertions(+), 0 deletions(-)
Booting 3.8-rc6 on omap 5430evm results in the following error
omap_i2c 4807.i2c: did not get pins for i2c error: -19
[1.024261] omap_i2c 4807.i2c: bus 0 rev0.12 at 100 kHz
[1.030181] omap_i2c 48072000.i2c: did not get pins for i2c error: -19
[1.037384] omap_i2c 48072000.i2c:
Booting 3.8-rc6 on omap4 panda results in the following error
[0.27] omap_i2c 4807.i2c: did not get pins for i2c error: -19
[0.445770] omap_i2c 4807.i2c: bus 0 rev0.11 at 400 kHz
[0.473937] omap_i2c 48072000.i2c: did not get pins for i2c error: -19
[0.474670] omap_i2c
From: Felipe Balbi ba...@ti.com
Add all 4 mcspi instances to omap5.dtsi file.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 40
1 files changed, 40 insertions(+), 0
Booting 3.8-rc6 on omap 4430sdp results in the following error
omap_i2c 4807.i2c: did not get pins for i2c error: -19
[1.024261] omap_i2c 4807.i2c: bus 0 rev0.12 at 100 kHz
[1.030181] omap_i2c 48072000.i2c: did not get pins for i2c error: -19
[1.037384] omap_i2c 48072000.i2c:
Hi Kevin,
On Tue, Feb 12, 2013 at 05:03:23, Kevin Hilman wrote:
Vaibhav Bedia vaibhav.be...@ti.com writes:
TPTC0 needs to be idled and put to standby under SW control.
Please elaborate about why (e.g. HW support not available, HW support
broken/buggy, etc.) since these blocks are not
Following current trend of placing memory controllers drivers under
drivers/memory, this patch anticipates this by moving the binding
documentation to Documentation/devicetree/bindings/memory-controller.
Some other SoCs will have similar memory controllers placed under
drivers/memory and it seems
GPMC stands for General Purpose Memory Controller, and it's primarily
used to handle memories such as NOR, NAND, SRAM.
Note that this controller is also used to handle network controllers
such as smsc911x.
This patch moves the documentation binding to memory-controllers,
where it belongs.
On Sat, Feb 09, 2013 at 15:52:44, Russell King - ARM Linux wrote:
On Thu, Feb 07, 2013 at 06:06:57PM +0530, Philip Avinash wrote:
+static int elm_suspend(struct device *dev)
+{
+ struct elm_info *info = dev_get_drvdata(dev);
+ wait_queue_head_t wq;
+ DECLARE_WAITQUEUE(wait,
On Wed, Feb 13, 2013 at 11:42:01AM +, Philip, Avinash wrote:
On Sat, Feb 09, 2013 at 15:52:44, Russell King - ARM Linux wrote:
On Thu, Feb 07, 2013 at 06:06:57PM +0530, Philip Avinash wrote:
+static int elm_suspend(struct device *dev)
+{
+ struct elm_info *info =
On 02/13/2013 08:22 AM, Sebastien Guiriec wrote:
Clean up dmic code with devm_request_and_ioremap function.
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
Signed-off-by: Sebastien Guiriec s-guir...@ti.com
---
sound/soc/omap/omap-dmic.c | 11 ++-
1 file changed, 2 insertions(+),
On 02/13/2013 08:21 AM, Sebastien Guiriec wrote:
Clean up McPDM driver with devm_ function.
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
Signed-off-by: Sebastien Guiriec s-guir...@ti.com
---
sound/soc/omap/omap-mcpdm.c | 14 +-
1 file changed, 5 insertions(+), 9
On Wed, Feb 13, 2013 at 08:21:54AM +0100, Sebastien Guiriec wrote:
Clean up McPDM driver with devm_ function.
Applied, thanks.
signature.asc
Description: Digital signature
On Wed, Feb 13, 2013 at 08:22:07AM +0100, Sebastien Guiriec wrote:
Clean up dmic code with devm_request_and_ioremap function.
Applied, thanks.
signature.asc
Description: Digital signature
On Tue, Feb 12, 2013 at 5:56 AM, Suman Anna s-a...@ti.com wrote:
I have hosted the series at [3].
[3] https://github.com/sumananna/mailbox/commits/dbx500-prcmu-mailbox
Suman, I suggest you ask Stepgen Rothwell to include this
branch into the linux-next tree, so we can get some
rotation of this
On Wed, Feb 13, 2013 at 02:36:32PM +0100, Linus Walleij wrote:
On Tue, Feb 12, 2013 at 5:56 AM, Suman Anna s-a...@ti.com wrote:
I have hosted the series at [3].
[3] https://github.com/sumananna/mailbox/commits/dbx500-prcmu-mailbox
Suman, I suggest you ask Stepgen Rothwell to include this
Hi Kevin,
On Tue, Feb 12, 2013 at 06:57:50, Kevin Hilman wrote:
[...]
+
+void (*am33xx_do_wfi_sram)(void);
static?
Will fix.
[...]
+
+ /*
+* By default the following IPs do not have MSTANDBY asserted
+* which is necessary for PER domain transition. If the drivers
+
Hi Jon,
On 02/12/2013 05:15 PM, Jon Hunter wrote:
On 02/12/2013 01:26 AM, Peter Ujfalusi wrote:
On 02/11/2013 09:22 PM, Jon Hunter wrote:
Good point. I just noticed that none of my omap2+ board were booting and
on omap3/4 I was the panic in the twl code. I can't say that I checked
the
These patches perform cleanups which will help the omapdss driver to migrate
to DT more easily:
- omapdss panel drivers call platform specific backlight functions defined in
board files. These callbacks are removed. Setting of max backlight level
in the board file is also removed.
- other
From: Tomi Valkeinen tomi.valkei...@ti.com
acx565akm has support to call set_backlight/get_backlight in platform
code. They are not used by any board, and thus can be removed from the
driver.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Signed-off-by: Archit Taneja arc...@ti.com
---
From: Tomi Valkeinen tomi.valkei...@ti.com
Sharp ls037v7dw01 driver contains support to call platform backlight
functions. These are not used by any board, and can be removed.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Signed-off-by: Archit Taneja arc...@ti.com
---
omap_dss_device provides a callback function to set backlight. Panel backlight
on Zoom board is implemented by the function zoom_set_bl_intensity() in the
board file. This needs to be removed. The PWM backlight should be implemented
with the pwm_bl driver.
For now, function
From: Tomi Valkeinen tomi.valkei...@ti.com
The n8x0 panel contains support to call platform backlight functions.
These are not used by any board, and can be removed.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Signed-off-by: Archit Taneja arc...@ti.com
---
From: Tomi Valkeinen tomi.valkei...@ti.com
Now that no board nor panel is using set_backlight and get_backlight
functions, we can remove them from omapdss.h.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Signed-off-by: Archit Taneja arc...@ti.com
---
include/video/omapdss.h |2 --
1
Use devm_kzalloc instead of kzalloc to allocate driver data for the generic dpi
panel driver. This simplifies the driver's probe and remove functions.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/displays/panel-generic-dpi.c |6 +-
1 file changed, 1 insertion(+), 5
Use devm_kzalloc instead of kzalloc to allocate driver data for the lg phillips
panel driver. This simplifies the driver's probe and remove functions.
Cc: Steve Sakoman st...@sakoman.com
Signed-off-by: Archit Taneja arc...@ti.com
---
.../omap2/displays/panel-lgphilips-lb035q02.c | 16
Use devm_kzalloc instead of kzalloc to allocate driver data for the picodlp
panel driver. This simplifies the driver's probe and remove functions.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/displays/panel-picodlp.c | 16 ++--
1 file changed, 6 insertions(+),
The omap_dss_device provides platform related parameters ext_te and ext_te_gpio
for DSI command mode panels. These parameters are now owned by a panel driver's
platform_data instead.
Remove these fields as they aren't used anymore.
Signed-off-by: Archit Taneja arc...@ti.com
---
The omap_dss_device structs's max_backlight_level is used to pass maximum
backlight level for the platform. However, no board file using this panel
populates this field. Therefore, we remove it's usage from the panel driver.
Signed-off-by: Archit Taneja arc...@ti.com
---
The maximum backlight level supported is a parameter which should come from
the panel's platform data. Usage of max_backlight_level in omap_dss_device has
been removed from all panel drivers. Remove it from the omap_dss_device struct.
Signed-off-by: Archit Taneja arc...@ti.com
---
On Mon, Feb 11, 2013 at 7:56 PM, Tony Lindgren t...@atomide.com wrote:
* Ruslan Bilovol ruslan.bilo...@ti.com [130206 14:54]:
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -602,6 +602,7 @@ void __init omap4430_init_late(void)
omap2_common_pm_late_init();
init functions in omap board files request panel specific gpios, and provide
functions which omapdss panel drivers call to enable or disable them.
Instead of the board files requesting these gpios, they should just pass the
platform specific data(like the gpio numbers), the panel should retrieve
Structs for platform data of omapdss panels are found in headers in the
'include/video/' path. Board files populate these structs with platform
specific values, and the panel driver uses these to configure the panel.
Currently, each panel has it's own header in the above path. Move all the
From: Tomi Valkeinen tomi.valkei...@ti.com
The generic dpi panel driver leaves gpio configurations to the platform_enable
and disable calls in the platform's board file. These should happen in the
panel driver itself.
Add a generic way of passing gpio information to the generic dpi panel driver
The 2430sdp board file currently requests gpios required to configure the NEC
DPI panel, and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the generic dpi panel driver itself and shouldn't
be done in the board files.
Remove the gpio requests and the
The devkit8000 board file currently requests gpios required to configure the
innolux DPI panel, and provides platform_enable/disable callbacks to configure
them.
These tasks have been moved to the generic dpi panel driver itself and should
be removed from the board files.
Remove the gpio request
The cm-t35 board file currently requests gpios required to configure the tdo35s
panel, and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the generic dpi panel driver itself and shouldn't
be done in the board files.
Remove the gpio requests and the
The apollon board file currently configures the LCD_PWR_EN gpio by muxing the
corresponding pin to gpio 11, and configuring it in PULL UP mode.
Remove this muxing from the board file. Add the gpio information to generic dpi
panel's platform data so that it's passed to the panel driver. The panel
The am3517 board file currently requests gpios required to configure the sharp
lq DPI panel, and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the generic dpi panel driver itself and shouldn't
be done in the board files.
Remove the gpio requests and
The ldp board file currently requests gpios required to configure the NEC DPI
panel, and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the generic dpi panel driver itself and shouldn't
be done in the board files.
Remove the gpio requests and the
The lgphilips panel driver leaves gpio configurations to the platform_enable
and disable calls in the platform's board file. These should happen in the
panel driver itself.
Use the platform data as defined for generic dpi panels to pass gpio information
to the lgphilips driver.
This will help in
The overo board file currently requests gpios required by the lb035q02 panel,
and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the lb035q02 dpi panel driver itself and should
be removed from the board files.
The lb035q02 panel driver uses generic
The lgphilips panel driver now manages the gpios required to configure the
panel. This was previously done in omap_dss_device's platform_enable/disable
callbacks defined in board files using this panel.
All the board files using this panel now pass the gpio information as platform
data via the
The generic dpi panel driver now sets the gpios required to configure the panel.
This was previously done in platform_enable/disable callbacks in board files.
All the board files using generic dpi panel now correctly pass the gpio related
information as platform data, which is needed by the panel
The omap3430sdp board file currently requests gpios required by the sharp_ls dpi
panel, and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the sharp_ls panel driver itself and shouldn't
be done in the board files.
Remove the gpio requests and the
The sharp-ls panel driver now manages the gpios required to configure the panel.
This was previously done in omap_dss_device's platform_enable/disable callbacks
defined in board files using this panel.
All the board files using this panel now pass the gpio information as platform
data via the
The acx565akm panel driver leaves gpio configurations to the platform_enable
and disable calls in the platform's board file. These should happen in the panel
driver itself.
Create a platform data struct for the panel, this contains the reset gpio number
used by the panel driver, this struct will
The rx-51 board file currently requests gpios required by the acx565akm panel,
and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the acx565akm panel driver itself and shouldn't
be done in the board files.
Remove the gpio requests and the platform
The nec-nl8048hl11-01 panel driver leaves gpio configurations to the
platform_enable and disable calls in the platform's board file. These should
happen in the panel driver itself.
Create a platform data struct for the panel, this contains the gpio numbers
used by the panel driver, this struct
The nec-nl8048 panel driver now manages the gpios required to configure the
panel. This was previously done in omap_dss_device's platform_enable/disable
callbacks defined in board files using this panel.
All the board files using this panel now pass the gpio information as platform
data via the
The zoom board file currently requests gpios required by the nec-nl8048hl11-01
dpi panel, and provides dummy platform_enable/disable callbacks.
gpio request and configuration have been moved to the nec-nl8048hl11-01 panel
driver itself and shouldn't be done in the board files.
Remove the gpio
The tpo-td043mtea1 panel driver leaves gpio configurations to the
platform_enable and disable calls in the platform's board file. These should
happen in the panel driver itself.
Create a platform data struct for the panel, this contains the reset gpio
number used by the panel driver, this struct
The omap3pandora board file currently passes the reset gpio number to the
tpo-td043mtea1 panel driver via the reset_gpio field in omap_dss_device.
Platform related information should be passed via the panel driver's platform
data struct.
Add the reset gpio information to panel_tpo_td043_data so
The tpo-td043 panel driver now manages the gpios required to configure the
panel.
This was previously done in omap_dss_device's platform_enable/disable callbacks
defined in board files using this panel.
All the board files using this panel now pass the gpio information as platform
data via the
The picodlp panel driver leaves gpio requests to the platform's board file.
These should happen in the panel driver itself.
A platform data struct called picodlp_panel_data already exists to hold gpio
numbers and other platform data. Request all the gpios in the panel driver so
that the board
The dss-common file currently requests gpios required by the picodlp DPI
panel on the 4430sdp/blaze board. It also requests DISPLAY_SEL_GPIO and
DLP_POWER_ON_GPIO gpios which are board specific gpios to switch between lcd2
panel and picodlp, and setting intermediate power supplies for picodlp
The picodlp panel driver now manages the gpios required to configure the
panel. This was previously done in omap_dss_device's platform_enable/disable
callbacks defined in board files using this panel.
All the board files using this panel now pass the gpio information as platform
data via the
The omap3evm board file currently requests gpios required by the sharp_ls dpi
panel, and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the sharp_ls panel driver itself and shouldn't
be done in the board files.
Remove the gpio requests and the
The n8x0 panel driver leaves gpio configurations to the platform_enable and
disable calls in the platform's board file. These should happen in the panel
driver itself.
A platform data struct called panel_n8x0_data already exists to hold gpio
numbers and other platform data. However, the gpio
The n8x0 panel driver now manages the gpios required to configure the panel.
This was previously done in panel_n8x0_data's platform_enable/disable callbacks
defined in board files using this panel.
All the board files using this panel now pass the gpio information as platform
data via the
The omap_dss_device's platform_enable/disable callbacks don't do anything for
any of the boards. The platform calls from the VENC driver will also be removed
in the future. Remove these calls from the board which have a VENC device.
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Archit Taneja
The platform_enable/disable callbacks in board files for VENC omap_dss_device
instances don't do anything. Hence, we can remove these callbacks from the VENC
driver.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/venc.c |9 -
1 file changed, 9 deletions(-)
None of the omapdss panel drivers call platform_enable/disable callbacks, and
none of the omap board files define these callbacks for any omap_dss_device.
Hence these callbacks can be removed form the omap_dss_device struct.
Signed-off-by: Archit Taneja arc...@ti.com
---
include/video/omapdss.h
gpio reset info is passed to the tfp410 panel driver via the panel's platform
data struct 'tfp410_platform_data'. The tfp driver doesn't use the reset_gpio
field in the omap4_panda_dvi_device struct. Remove this field.
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Archit Taneja arc...@ti.com
The reset_gpio field isn't used by any panel driver to retrieve a reset gpio
number. All the panel drivers receive gpio data from their corresponding
platform_data structs. Remove the reset_gpio field.
Signed-off-by: Archit Taneja arc...@ti.com
---
include/video/omapdss.h |2 --
1 file
On 02/13/2013 05:13 AM, Ezequiel Garcia wrote:
GPMC stands for General Purpose Memory Controller, and it's primarily
used to handle memories such as NOR, NAND, SRAM.
Note that this controller is also used to handle network controllers
such as smsc911x.
This patch moves the documentation
Hi Archit,
On 02/13/13 16:21, Archit Taneja wrote:
The cm-t35 board file currently requests gpios required to configure the
tdo35s
panel, and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the generic dpi panel driver itself and
shouldn't
be
On 2013-02-13 17:16, Igor Grinberg wrote:
Hi Archit,
On 02/13/13 16:21, Archit Taneja wrote:
The cm-t35 board file currently requests gpios required to configure the
tdo35s
panel, and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the generic
On 02/13/2013 07:04 AM, Kumar, Anil wrote:
Hi Peter,
Just trying to understand.
In omap-twl4030.c file probe function :-
dai_node = of_parse_phandle(node, ti,mcbsp, 0);
if (!dai_node) {
dev_err(pdev-dev, McBSP node is not provided\n);
On 02/13/2013 03:28 AM, Sourav Poddar wrote:
Booting 3.8-rc6 on omap4 panda results in the following error
[0.27] omap_i2c 4807.i2c: did not get pins for i2c error: -19
[0.445770] omap_i2c 4807.i2c: bus 0 rev0.11 at 400 kHz
[0.473937] omap_i2c 48072000.i2c: did not
On 2013-02-13 17:28, Tomi Valkeinen wrote:
On 2013-02-13 17:16, Igor Grinberg wrote:
Hi Archit,
On 02/13/13 16:21, Archit Taneja wrote:
The cm-t35 board file currently requests gpios required to configure the
tdo35s
panel, and provides platform_enable/disable callbacks to configure them.
On 02/13/2013 09:57 AM, Jon Hunter wrote:
On 02/13/2013 03:28 AM, Sourav Poddar wrote:
Booting 3.8-rc6 on omap4 panda results in the following error
[0.27] omap_i2c 4807.i2c: did not get pins for i2c error: -19
[0.445770] omap_i2c 4807.i2c: bus 0 rev0.11 at 400 kHz
[
* Jon Hunter jon-hun...@ti.com [130213 08:10]:
On 02/13/2013 09:57 AM, Jon Hunter wrote:
On 02/13/2013 03:28 AM, Sourav Poddar wrote:
A quick look at the data manual shows that omap4430 and omap4460 has the
same pin mux options for i2c. Furthermore, the data manual shows only
one mux
Hi,
On Wed, Feb 13, 2013 at 9:22 PM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
On 02/13/2013 07:04 AM, Kumar, Anil wrote:
Hi Peter,
Just trying to understand.
In omap-twl4030.c file probe function :-
dai_node = of_parse_phandle(node, ti,mcbsp, 0);
if (!dai_node) {
On Wed, Feb 13, 2013 at 02:36:32PM +0100, Linus Walleij wrote:
On Tue, Feb 12, 2013 at 5:56 AM, Suman Anna s-a...@ti.com wrote:
I have hosted the series at [3].
[3]
https://github.com/sumananna/mailbox/commits/dbx500-prcmu-mailbox
Suman, I suggest you ask Stepgen Rothwell to
* Archit Taneja arc...@ti.com [130213 06:26]:
init functions in omap board files request panel specific gpios, and provide
functions which omapdss panel drivers call to enable or disable them.
Instead of the board files requesting these gpios, they should just pass the
platform specific
Hi Peter,
On Wed, Feb 13, 2013 at 10:10 PM, Anil Kumar anilk...@gmail.com wrote:
Hi,
On Wed, Feb 13, 2013 at 9:22 PM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
On 02/13/2013 07:04 AM, Kumar, Anil wrote:
Hi Peter,
Just trying to understand.
In omap-twl4030.c file probe function :-
Hi,
On Wed, Feb 13, 2013 at 07:52:08PM +0530, Archit Taneja wrote:
+static struct panel_acx565akm_data *get_panel_data(struct omap_dss_device
*dssdev)
+{
+ return (struct panel_acx565akm_data *) dssdev-data;
+}
+
static int acx_panel_probe(struct omap_dss_device *dssdev)
{
Hi,
On Wed, Feb 13, 2013 at 07:52:19PM +0530, Archit Taneja wrote:
@@ -444,6 +445,20 @@ static int n8x0_panel_probe(struct omap_dss_device
*dssdev)
dssdev-ctrl.rfbi_timings = n8x0_panel_timings;
dssdev-caps = OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE;
+ if
Hi Andi,
Thanks for your review,
On Mon, Feb 11, 2013 at 1:51 AM, Andi Shyti a...@etezian.org wrote:
Hi Ruslan,
TC358765 is DSI-to-LVDS transmitter from Toshiba, used in
OMAP44XX Blaze Tablet and Blaze Tablet2 boards.
I think it's fine, just some nitpicks and checkpatch warnings
+struct
On Wed, 13 Feb 2013, J, KEERTHY wrote:
So the patch needs to be rebased after 3.9 right?
No, I've already done that. At this point, I don't think there's anything
further that you need to do with it. Will let you know if that turns out
not to be true.
- Paul
--
To unsubscribe from this
Hi Suman,
I'll send new version of patch 11 taking into account Mark Rutland's
comments.
Regards,
Loic
On 02/13/2013 05:41 PM, Anna, Suman wrote:
On Wed, Feb 13, 2013 at 02:36:32PM +0100, Linus Walleij wrote:
On Tue, Feb 12, 2013 at 5:56 AM, Suman Annas-a...@ti.com wrote:
I have hosted
From: Loic Pallardy loic.palla...@st.com
Add STEriccson DBX500 PRCM mailbox support.
Change-Id: I36cbef646e26469a9490d46a5e143667aa93d762
Signed-off-by: Loic Pallardy loic.palla...@st.com
Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
On Wed, Feb 13, 2013 at 09:42:07PM +0100, Loic Pallardy wrote:
From: Loic Pallardy loic.palla...@st.com
Add STEriccson DBX500 PRCM mailbox support.
Change-Id: I36cbef646e26469a9490d46a5e143667aa93d762
These mean nothing when submitting kernel patches, please never include
them.
thanks,
Sorry my mistake, I forgot to clean this before sending.
Regards,
Loic
On 02/13/2013 09:55 PM, Greg Kroah-Hartman wrote:
On Wed, Feb 13, 2013 at 09:42:07PM +0100, Loic Pallardy wrote:
From: Loic Pallardyloic.palla...@st.com
Add STEriccson DBX500 PRCM mailbox support.
Change-Id:
On 02/07/2013 03:51 AM, Mark Jackson wrote:
Okay ... I have made some progress, but it's not ideal.
Currently I've hacked the GPMC DT driver (gpmc_probe_dt(), etc) so it now
handles setting up the
chip selects and timings for NOR devices, e.g.
gpmc: gpmc@5000 {
From: Loic Pallardy loic.palla...@st.com
Add STEriccson DBX500 PRCM mailbox support.
Signed-off-by: Loic Pallardy loic.palla...@st.com
Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
.../devicetree/bindings/mailbox/dbx500-mailbox.txt | 27 +
drivers/mailbox/Kconfig
Hi Tony, Jon,
On Mon, Feb 11, 2013 at 9:00 PM, Tony Lindgren t...@atomide.com wrote:
* Jon Hunter jon-hun...@ti.com [130211 10:58]:
Please note that the blaze is derived from the omap4-sdp board and so I
would hope that we can use the existing for sdp dts and board file for
blaze. In fact
Hi Tomi,
On Wed, Feb 13, 2013 at 10:18 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Hi,
On 2013-02-08 17:43, Ruslan Bilovol wrote:
Hi,
This patch adds support for TC358765 DSI-to-LVDS transmitter
from Toshiba, that is used in OMAP4 Blaze Tablet development
platform. It was originally
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Thursday, February 14, 2013 1:14 AM
To: J, KEERTHY
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: RE: [PATCH] ARM: OMAP: Clock: Remove CK_* flags
On Wed, 13 Feb 2013, J, KEERTHY
Hi,
On Wednesday 13 February 2013 11:05 PM, Aaro Koskinen wrote:
Hi,
On Wed, Feb 13, 2013 at 07:52:19PM +0530, Archit Taneja wrote:
@@ -444,6 +445,20 @@ static int n8x0_panel_probe(struct omap_dss_device *dssdev)
dssdev-ctrl.rfbi_timings = n8x0_panel_timings;
dssdev-caps =
On Wednesday 13 February 2013 10:59 PM, Aaro Koskinen wrote:
Hi,
On Wed, Feb 13, 2013 at 07:52:08PM +0530, Archit Taneja wrote:
+static struct panel_acx565akm_data *get_panel_data(struct omap_dss_device
*dssdev)
+{
+ return (struct panel_acx565akm_data *) dssdev-data;
+}
+
static int
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/13/13 17:59, Tomi Valkeinen wrote:
On 2013-02-13 17:28, Tomi Valkeinen wrote:
On 2013-02-13 17:16, Igor Grinberg wrote:
Hi Archit,
On 02/13/13 16:21, Archit Taneja wrote:
The cm-t35 board file currently requests gpios required to configure
On 2013-02-14 08:51, Archit Taneja wrote:
On Wednesday 13 February 2013 10:59 PM, Aaro Koskinen wrote:
Hi,
On Wed, Feb 13, 2013 at 07:52:08PM +0530, Archit Taneja wrote:
+static struct panel_acx565akm_data *get_panel_data(struct
omap_dss_device *dssdev)
+{
+return (struct
On 2013-02-14 08:56, Igor Grinberg wrote:
On 02/13/13 17:59, Tomi Valkeinen wrote:
Okay, so I just realized there's an spi backlight driver used here, and
that backlight driver is actually handling the SPI transactions with the
panel, instead of the panel driver. So this looks quite messed
On Thursday 14 February 2013 12:28 PM, Tomi Valkeinen wrote:
On 2013-02-14 08:51, Archit Taneja wrote:
On Wednesday 13 February 2013 10:59 PM, Aaro Koskinen wrote:
Hi,
On Wed, Feb 13, 2013 at 07:52:08PM +0530, Archit Taneja wrote:
+static struct panel_acx565akm_data *get_panel_data(struct
1 - 100 of 101 matches
Mail list logo
