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_mai
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/
https://patchwork.ke
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
---
arch/arm/boot/dts/omap5-evm.dts | 46 +++
1 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/arch/arm
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: b
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 4
From: Felipe Balbi
Add all 4 mcspi instances to omap5.dtsi file.
Signed-off-by: Felipe Balbi
Signed-off-by: Sourav Poddar
---
arch/arm/boot/dts/omap5.dtsi | 40
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.d
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: b
Hi Kevin,
On Tue, Feb 12, 2013 at 05:03:23, Kevin Hilman wrote:
> Vaibhav Bedia 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 well documented i
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.
Signed-
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(wa
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 = dev_get
On 02/13/2013 08:22 AM, Sebastien Guiriec wrote:
> Clean up dmic code with devm_request_and_ioremap function.
Acked-by: Peter Ujfalusi
>
> Signed-off-by: Sebastien Guiriec
> ---
> sound/soc/omap/omap-dmic.c | 11 ++-
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git
On 02/13/2013 08:21 AM, Sebastien Guiriec wrote:
> Clean up McPDM driver with devm_ function.
Acked-by: Peter Ujfalusi
>
> Signed-off-by: Sebastien Guiriec
> ---
> sound/soc/omap/omap-mcpdm.c | 14 +-
> 1 file changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/sound/soc/
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 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 stuff in pr
On Wed, Feb 13, 2013 at 02:36:32PM +0100, Linus Walleij wrote:
> On Tue, Feb 12, 2013 at 5:56 AM, Suman Anna 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
> bra
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
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
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 misc
From: Tomi Valkeinen
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
Signed-off-by: Archit Taneja
---
drivers/video/omap2/displays/panel-acx565akm.c |6 +-
From: Tomi Valkeinen
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
Signed-off-by: Archit Taneja
---
.../video/omap2/displays/panel-sharp-ls037v7dw01.c | 62 --
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 zoom_set_bl_intensity()
From: Tomi Valkeinen
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
Signed-off-by: Archit Taneja
---
drivers/video/omap2/displays/panel-n8x0.c | 74 -
includ
From: Tomi Valkeinen
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
Signed-off-by: Archit Taneja
---
include/video/omapdss.h |2 --
1 file changed, 2 deletions(-)
diff --git a/include/video/
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
---
drivers/video/omap2/displays/panel-generic-dpi.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
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
Signed-off-by: Archit Taneja
---
.../omap2/displays/panel-lgphilips-lb035q02.c | 16 +---
1 file changed, 5
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
---
drivers/video/omap2/displays/panel-picodlp.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(
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
---
include/video/omapdss.h |3
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
---
drivers/video/omap2/displays/panel-acx
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
---
include/video/omapdss.h |
On Mon, Feb 11, 2013 at 7:56 PM, Tony Lindgren wrote:
> * Ruslan Bilovol [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();
>> omap4_pm_init();
>> omap2_c
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 t
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
omapdss
From: Tomi Valkeinen
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
via it's platform_data
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 pl
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 d
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 plat
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 dp
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 pan
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 plat
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 pane
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 b
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 cal
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 wil
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 pa
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 req
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 w
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 t
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 pa
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 file
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
respe
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 panel
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 platfor
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 reque
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 panel_n8
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
Signed-off-by: Archit Taneja
---
arch/arm/ma
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
---
drivers/video/omap2/dss/venc.c |9 -
1 file changed, 9 deletions(-)
diff --git a/dri
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
---
include/video/omapdss.h |4
1
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
Signed-off-by: Archit Taneja
---
arch/arm/mach-omap2/dss-c
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
---
include/video/omapdss.h |2 --
1 file changed, 2 deletion
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 documentati
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'
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
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 provide
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 n
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 co
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
* Jon Hunter [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 option f
Hi,
On Wed, Feb 13, 2013 at 9:22 PM, Peter Ujfalusi 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 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 [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 data(like the
Hi Peter,
On Wed, Feb 13, 2013 at 10:10 PM, Anil Kumar wrote:
> Hi,
>
> On Wed, Feb 13, 2013 at 9:22 PM, Peter Ujfalusi 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_pa
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 (gpio_is_valid(
Hi Andi,
Thanks for your review,
On Mon, Feb 11, 2013 at 1:51 AM, Andi Shyti 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 lis
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 Anna wrote:
>>>
I have hosted the
From: Loic Pallardy
Add STEriccson DBX500 PRCM mailbox support.
Change-Id: I36cbef646e26469a9490d46a5e143667aa93d762
Signed-off-by: Loic Pallardy
Signed-off-by: Linus Walleij
---
.../devicetree/bindings/mailbox/dbx500-mailbox.txt | 27 +
drivers/mailbox/Kconfig|
On Wed, Feb 13, 2013 at 09:42:07PM +0100, Loic Pallardy wrote:
> From: Loic Pallardy
>
> Add STEriccson DBX500 PRCM mailbox support.
>
> Change-Id: I36cbef646e26469a9490d46a5e143667aa93d762
These mean nothing when submitting kernel patches, please never include
them.
thanks,
greg k-h
--
To un
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 Pallardy
>>
>> Add STEriccson DBX500 PRCM mailbox support.
>>
>> Change-Id: I36cbef646e26469a9490
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
Add STEriccson DBX500 PRCM mailbox support.
Signed-off-by: Loic Pallardy
Signed-off-by: Linus Walleij
---
.../devicetree/bindings/mailbox/dbx500-mailbox.txt | 27 +
drivers/mailbox/Kconfig| 7 +
drivers/mailbox/Makefile
Hi Tony, Jon,
On Mon, Feb 11, 2013 at 9:00 PM, Tony Lindgren wrote:
> * Jon Hunter [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 this is what I do today for
Hi Tomi,
On Wed, Feb 13, 2013 at 10:18 AM, Tomi Valkeinen 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 developed
> -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, KE
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 = OM
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 requir
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 (st
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 mes
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
oma
1 - 100 of 101 matches
Mail list logo