When the GPIO is configured as output we need to read the GPIODATAOUT*
register to get correct information. When the GPIO is output the GPIODATAIN*
registers report 0 all the time (no feedback from output path).
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/gpio/gpio-twl4030.c
Hi everyone,
this patch series aims at cleaning up of dss_features.c by moving features to
respective submodule drivers.
The 1st patch
* moved struct omap_dss_features members burst_size_unit and buffer_size_unit
to dispc_features
The 2nd patch
* added definition of struct omapdss_reg_field
The burst_size and buffer_size being local data to DISPC are moved to
dispc_features and so removed from struct omap_dss_features. The functions
referring to burst and buffer size are also removed from dss_features.c as they
are now accessed locally in dispc.c.
Signed-off-by: Chandrabhanu
The register fields in dss_reg_fields specific to DISPC are moved from struct
omap_dss_features to corresponding dispc_reg_fields, initialized in struct
dispc_features, thereby enabling local access.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/video/omap2/dss/dispc.c
The DISPC specific dss_param_range are moved from struct omap_dss_features to
corresponding DSS version specific dispc_param_range struct, initialized in
dispc_features thereby enabling local access. The mgr_width_max and
mgr_height_max, members of dispc_features, are also moved to
The DSI specific dss_reg_fields are moved to corresponding dsi_reg_fields
initialized in dsi_feats. The dsi_feats structure is initialized as per
corresponding DSS version in dsi_init_features().
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/video/omap2/dss/dsi.c |
The DSI specific dss_param_range are moved from struct omap_dss_features to
corresponding struct dsi_param_range, which is initialized in struct dsi_feats
thereby enabling local access.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/video/omap2/dss/dsi.c | 80
The members fld_dispc_clk_switch and dss_fck_max are added to struct
dss_features and are initialized in corresponding dss_feats structure as per DSS
version. The reg_fields, num_reg_fields and dss_params entries are removed from
struct omap_dss_features as they are no longer referenced.
Hello,
I am not working on OMAP anymore and not able to test anything.
But in general changes are OK for me.
- Dmitry
On Mon, Nov 19, 2012 at 8:54 PM, Mark A. Greer mgr...@animalcreek.com wrote:
From: Mark A. Greer mgr...@animalcreek.com
Changes since v3:
- Added hwmod support for
Hello,
I am not working on OMAP anymore and not able to test anything.
But in general changes are OK for me.
- Dmitry
On Tue, Nov 20, 2012 at 2:08 PM, Kasatkin, Dmitry
dmitry.kasat...@intel.com wrote:
Great. You also worked on AES...
Will take a loos asap.
On Mon, Nov 19, 2012 at 9:03 PM,
Hi Avinash,
On 11/29/2012 5:16 PM, Philip, Avinash wrote:
Update number of errors using nand ecc strength.
Also add macro definitions BCH8_ERROR_MAX BCH4_ERROR_MAX
Can you please describe why the original method of setting nerrors was
incorrect? Was it causing any issues in any particular
On Wed, Dec 05, 2012 at 17:33:37, Nori, Sekhar wrote:
Hi Avinash,
On 11/29/2012 5:16 PM, Philip, Avinash wrote:
Update number of errors using nand ecc strength.
Also add macro definitions BCH8_ERROR_MAX BCH4_ERROR_MAX
Can you please describe why the original method of setting nerrors
On 29.11.2012 21:59, Jon Hunter wrote:
On 11/29/2012 02:42 PM, Daniel Mack wrote:
On 29.11.2012 21:32, Jon Hunter wrote:
On 11/29/2012 01:59 PM, Jon Hunter wrote:
On 11/29/2012 10:01 AM, Daniel Mack wrote:
The am33xx is capable of handling bch error correction modes, so
enable that feature
Hello.
On 04-12-2012 18:31, Roger Quadros wrote:
clk_set_parent is expected to fail on OMAP3 platforms. We don't
consider that as fatal so don't spam console.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 18 +-
1 files changed, 9
Hello.
On 04-12-2012 18:12, Roger Quadros wrote:
Use devm_ variants of kzalloc() and ioremap(). Simplify the error path.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-tll.c | 37 +++--
1 files changed, 11 insertions(+), 26
Hi Jassi,
On 12/01/2012 09:49 AM, Jassi Brar wrote:
On Tue, Nov 27, 2012 at 10:32 PM, Greg KH gre...@linuxfoundation.org wrote:
On Tue, Nov 27, 2012 at 11:30:11AM -0500, Alan Stern wrote:
We should have a more generic solution in a more central location, like
the device core.
For example,
On 12/05/2012 03:42 PM, Sergei Shtylyov wrote:
Hello.
On 04-12-2012 18:31, Roger Quadros wrote:
clk_set_parent is expected to fail on OMAP3 platforms. We don't
consider that as fatal so don't spam console.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c |
On 12/05/2012 04:08 PM, Sergei Shtylyov wrote:
Hello.
On 04-12-2012 18:12, Roger Quadros wrote:
Use devm_ variants of kzalloc() and ioremap(). Simplify the error path.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-tll.c | 37
On Wed, 5 Dec 2012, Andy Green wrote:
The details of this aren't clear yet. For instance, should the device
core try to match the port with the asset info, or should this be done
by the USB code when the port is created?
Currently what I have (this is before changing it to pm domain,
On 12/03/2012 05:00 AM, Ming Lei wrote:
On Mon, Dec 3, 2012 at 12:02 AM, Andy Green andy.gr...@linaro.org wrote:
On 02/12/12 23:01, the mail apparently from Ming Lei included:
Power controller is an abstract on simple power on/off switch.
One power controller can bind to more than one
Hi,
* Ming Lei tom.leim...@gmail.com [121202 07:05]:
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
...
+
+static struct notifier_block usb_port_nb = {
+ .notifier_call = device_notify,
+};
+
We'll be flipping omap4 over to be device tree
* Daniel Mack zon...@gmail.com [121205 05:07]:
On 29.11.2012 21:59, Jon Hunter wrote:
On 11/29/2012 02:42 PM, Daniel Mack wrote:
On 29.11.2012 21:32, Jon Hunter wrote:
On 11/29/2012 01:59 PM, Jon Hunter wrote:
On 11/29/2012 10:01 AM, Daniel Mack wrote:
The am33xx is capable of
Hi Tony,
On 05.12.2012 18:19, Tony Lindgren wrote:
* Daniel Mack zon...@gmail.com [121205 05:07]:
On 29.11.2012 21:59, Jon Hunter wrote:
On 11/29/2012 02:42 PM, Daniel Mack wrote:
On 29.11.2012 21:32, Jon Hunter wrote:
On 11/29/2012 01:59 PM, Jon Hunter wrote:
On 11/29/2012 10:01 AM,
* Daniel Mack zon...@gmail.com [121205 09:29]:
On 05.12.2012 18:19, Tony Lindgren wrote:
The plat/cpu.h file will disappear after the merge window, which means
omap2+ related drivers cannot use cpu_is_omap macros.
For legacy booting systems, this flag should be just passed in the
On 12/05/2012 11:41 AM, Tony Lindgren wrote:
* Daniel Mack zon...@gmail.com [121205 09:29]:
On 05.12.2012 18:19, Tony Lindgren wrote:
The plat/cpu.h file will disappear after the merge window, which means
omap2+ related drivers cannot use cpu_is_omap macros.
For legacy booting systems,
* Jon Hunter jon-hun...@ti.com [121205 10:22]:
On 12/05/2012 11:41 AM, Tony Lindgren wrote:
* Daniel Mack zon...@gmail.com [121205 09:29]:
On 05.12.2012 18:19, Tony Lindgren wrote:
The plat/cpu.h file will disappear after the merge window, which means
omap2+ related drivers cannot use
On 05.12.2012 19:33, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [121205 10:22]:
On 12/05/2012 11:41 AM, Tony Lindgren wrote:
* Daniel Mack zon...@gmail.com [121205 09:29]:
On 05.12.2012 18:19, Tony Lindgren wrote:
The plat/cpu.h file will disappear after the merge window, which
* Roger Quadros rog...@ti.com [121204 06:15]:
Instead of using cpu_is_omap..() macros in the device driver we
rely on information provided in the platform data.
The only information we need is whether the USB Host module has
a single ULPI bypass control bit for all ports or individual bypass
On 05.12.2012 18:41, Tony Lindgren wrote:
* Daniel Mack zon...@gmail.com [121205 09:29]:
On 05.12.2012 18:19, Tony Lindgren wrote:
The plat/cpu.h file will disappear after the merge window, which means
omap2+ related drivers cannot use cpu_is_omap macros.
For legacy booting systems, this
On DT driven boards, the gpmc node will match the driver. Hence, there's
no need to do that unconditionally from the initcall.
Signed-off-by: Daniel Mack zon...@gmail.com
---
arch/arm/mach-omap2/gpmc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c
This is a series of patches to support GPMC peripherals on OMAP boards.
Grant, Rob, could you have a look and give your Acked-by if
appropriate?
Many thanks again,
Daniel
Tested on Linus' master +
omap-next (branch omap-for-v3.8/cleanup-headers-gpmc)
Generated from linux-next as of today,
The am33xx is capable of handling bch error correction modes, so
enable that feature in the driver.
Signed-off-by: Daniel Mack zon...@gmail.com
---
arch/arm/mach-omap2/gpmc-nand.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c
Pass an optional device_node pointer in the platform data, which in turn
will be put into a mtd_part_parser_data. This way, code that sets up the
platform devices can pass along the node from DT so that the partitions
can be parsed.
For non-DT boards, this change has no effect.
Signed-off-by:
This patch adds basic DT bindings for OMAP GPMC.
The actual peripherals are instantiated from child nodes within the GPMC
node, and the only type of device that is currently supported is NAND.
Code was added to parse the generic GPMC timing parameters and some
documentation with examples on how
gpmc_nand_init() will be called from another driver's probe() function,
so the easiest way to prevent section mismatches is to drop the
annotation here.
Signed-off-by: Daniel Mack zon...@gmail.com
---
arch/arm/mach-omap2/gpmc-nand.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
On 12/05/2012 12:40 PM, Daniel Mack wrote:
On 05.12.2012 19:33, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [121205 10:22]:
On 12/05/2012 11:41 AM, Tony Lindgren wrote:
* Daniel Mack zon...@gmail.com [121205 09:29]:
On 05.12.2012 18:19, Tony Lindgren wrote:
The plat/cpu.h file
On 12/05/2012 01:09 PM, Daniel Mack wrote:
This is a series of patches to support GPMC peripherals on OMAP boards.
Grant, Rob, could you have a look and give your Acked-by if
appropriate?
Many thanks again,
Daniel
Tested on Linus' master +
omap-next (branch
On 05.12.2012 20:22, Jon Hunter wrote:
On 12/05/2012 01:09 PM, Daniel Mack wrote:
This is a series of patches to support GPMC peripherals on OMAP boards.
Grant, Rob, could you have a look and give your Acked-by if
appropriate?
Many thanks again,
Daniel
Tested on Linus' master +
Here are some basic OMAP test results for Linux v3.7-rc8.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.7-rc8/20121204220128/
Passing tests
-
Boot to userspace (10/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
3730beaglexm, 37xxevm, 4430es2panda,
On Wed, 5 Dec 2012 20:09:31 +0100, Daniel Mack zon...@gmail.com wrote:
This patch adds basic DT bindings for OMAP GPMC.
The actual peripherals are instantiated from child nodes within the GPMC
node, and the only type of device that is currently supported is NAND.
Code was added to parse
Hi Grant,
On 12/05/2012 04:22 PM, Grant Likely wrote:
On Wed, 5 Dec 2012 20:09:31 +0100, Daniel Mack zon...@gmail.com wrote:
This patch adds basic DT bindings for OMAP GPMC.
The actual peripherals are instantiated from child nodes within the GPMC
node, and the only type of device that is
On Wed, 5 Dec 2012 10:49:45 +0100, Peter Ujfalusi peter.ujfal...@ti.com wrote:
When the GPIO is configured as output we need to read the GPIODATAOUT*
register to get correct information. When the GPIO is output the GPIODATAIN*
registers report 0 all the time (no feedback from output path).
On Wed, 5 Dec 2012 16:33:48 -0600, Jon Hunter jon-hun...@ti.com wrote:
Hi Grant,
On 12/05/2012 04:22 PM, Grant Likely wrote:
On Wed, 5 Dec 2012 20:09:31 +0100, Daniel Mack zon...@gmail.com wrote:
This patch adds basic DT bindings for OMAP GPMC.
The actual peripherals are instantiated
* Grant Likely grant.lik...@secretlab.ca [121205 15:26]:
On Wed, 5 Dec 2012 16:33:48 -0600, Jon Hunter jon-hun...@ti.com wrote:
On 12/05/2012 04:22 PM, Grant Likely wrote:
Please, be specific. Use something like ti,am3340-gpmc or
ti,omap3430-gpmc. The compatible property is a list so
On 06/12/12 00:42, the mail apparently from Alan Stern included:
On Wed, 5 Dec 2012, Andy Green wrote:
The details of this aren't clear yet. For instance, should the device
core try to match the port with the asset info, or should this be done
by the USB code when the port is created?
Hi,
Well, I'm not any less busy than yesterday, as it turns out, but I'm expecting
that to continue tomorrow, so I may as well have a look at it now. :-)
On Tuesday, December 04, 2012 12:10:32 PM Alan Stern wrote:
[CC: list trimmed; the people who were on it should be subscribed to at
least
On Thu, Dec 6, 2012 at 12:49 AM, Roger Quadros rog...@ti.com wrote:
On 12/03/2012 05:00 AM, Ming Lei wrote:
On Mon, Dec 3, 2012 at 12:02 AM, Andy Green andy.gr...@linaro.org wrote:
On 02/12/12 23:01, the mail apparently from Ming Lei included:
Power controller is an abstract on simple power
On 6 December 2012 06:57, Ming Lei tom.leim...@gmail.com wrote:
On Thu, Dec 6, 2012 at 12:49 AM, Roger Quadros rog...@ti.com wrote:
On 12/03/2012 05:00 AM, Ming Lei wrote:
On Mon, Dec 3, 2012 at 12:02 AM, Andy Green andy.gr...@linaro.org wrote:
On 02/12/12 23:01, the mail apparently from Ming
48 matches
Mail list logo
