Olof,
On Friday 30 November 2012 12:48 PM, Olof Johansson wrote:
On Mon, Nov 26, 2012 at 05:06:11PM -0800, Tony Lindgren wrote:
The following changes since commit 9dc57643738f9fbe45c10cc062903d5dfda5bdd9:
Merge branch 'fixes-timer' of github.com:jonhunter/linux into
omap-for-v3.8/timer
Hi,
On 2012-11-30 06:30, Axel Lin wrote:
The i2c_device_id table is supposed to be zero-terminated.
Signed-off-by: Axel Lin axel@gmail.com
---
drivers/video/omap2/displays/panel-picodlp.c |1 +
1 file changed, 1 insertion(+)
diff --git
Hi Tony,
On 2012-11-22 10:39, Tomi Valkeinen wrote:
The i2c handling in tfp410 driver, which handles converting parallel RGB
to DVI, was changed in 958f2717b84e88bf833d996997fda8f73276f2af
(OMAPDSS: TFP410: pdata rewrite). The patch changed what value the
driver considers as
On Wed, Nov 28, 2012 at 19:51:01, Thierry Reding wrote:
On Tue, Nov 27, 2012 at 02:18:05PM +0530, Philip, Avinash wrote:
In AM33xx PWM sub modules like ECAP, EHRPWM EQEP are integrated to
PWM subsystem. All these submodules shares the resources (clock) has
a clock gating register in PWM
On 11/29/2012 12:14 AM, Javier Martinez Canillas wrote:
Add a generic .dtsi device tree source file for the
common characteristics across IGEP Technology devices.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Acked-by: Matthias Brugger matthias@gmail.com
On 11/29/2012 12:14 AM, Javier Martinez Canillas wrote:
ISEE IGEPv2 is an TI OMAP3 SoC based embedded board.
This patch adds an initial device tree support to boot
an IGEPv2 from the MMC/SD.
Currently is working everything that is supported by DT
on OMAP3 SoCs (MMC/SD, GPIO LEDs, EEPROM,
On Thursday 29 November 2012 05:35 PM, Tomi Valkeinen wrote:
On 2012-11-28 12:41, Chandrabhanu Mahapatra wrote:
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
IGEP technology devices are TI OMAP3 SoC based industrial embedded
and computer-on-module boards. This patch-set adds initial device
tree support for these devices.
The device tree allows to boot from an MMC/SD and are working all
the components that already have device tree support on OMAP3
ISEE IGEP COM Module is an TI OMAP3 SoC computer on module.
This patch adds an initial device tree support to boot an
IGEP COM Module from the MMC/SD.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Matthias Brugger matthias@gmail.com
---
Changes since v1:
ISEE IGEPv2 is an TI OMAP3 SoC based embedded board.
This patch adds an initial device tree support to boot
an IGEPv2 from the MMC/SD.
Currently is working everything that is supported by DT on OMAP3
SoCs (MMC/SD, GPIO LEDs, EEPROM, TWL4030 audio and pinctrl based mux).
Signed-off-by: Javier
Add a generic .dtsi device tree source file for the
common characteristics across IGEP Technology devices.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Matthias Brugger matthias@gmail.com
---
arch/arm/boot/dts/omap3-igep.dtsi | 93
On Fri, 30 Nov 2012 07:47:52 +0100, Thierry Reding
thierry.red...@avionic-design.de wrote:
On Thu, Nov 29, 2012 at 04:10:24PM +, Grant Likely wrote:
On Wed, 28 Nov 2012 09:54:57 +0100, Peter Ujfalusi peter.ujfal...@ti.com
wrote:
Hi Grant, Lars, Thierry,
On 11/26/2012 04:46 PM,
On 2012-11-30 12:02, Chandrabhanu Mahapatra wrote:
On Thursday 29 November 2012 05:35 PM, Tomi Valkeinen wrote:
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 84a7f6a..aa273d8 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@
On 11/30/2012 11:20 AM, Grant Likely wrote:
Umm, I agree with you on duty cycle, but that's got nothing to do with
period. 100% duty cycle looks exactly the same whether the period is
10ns or 100s.
Yes this is true. But some PWM hw can select it's clock based on the period_ns
provided.
In most
On 11/29/2012 05:10 PM, Grant Likely wrote:
/* Enable GPIO us of the PWMs */
gpio-controller = 1;
This line should be simply (the property shouldn't have any data):
gpio-controller;
Yes I know. It is like this already in my code. I just mixed up things while
hacking it
On Fri, Nov 30, 2012 at 10:20:38AM +, Grant Likely wrote:
On Fri, 30 Nov 2012 07:47:52 +0100, Thierry Reding
thierry.red...@avionic-design.de wrote:
On Thu, Nov 29, 2012 at 04:10:24PM +, Grant Likely wrote:
On Wed, 28 Nov 2012 09:54:57 +0100, Peter Ujfalusi
On Fri, Nov 30, 2012 at 11:04 AM, Thierry Reding
thierry.red...@avionic-design.de wrote:
One other problem is that some PWM devices cannot be setup to achieve a
0% or 100% duty-cycle but instead will toggle for at least one period.
This would be another argument in favour of moving the
Hi,
I submitted following patches a while back,
http://www.spinics.net/lists/linux-mmc/msg17624.html. Since
there was no feedback I'm taking a step back, documenting:
1. why is it needed, missing swakeup line
2. transition, enable workaround by default
3. device tree configuration
[why is it
On Tue, 2012-11-06 at 11:51 +0100, Matthieu CASTET wrote:
The driver call nand_scan_ident in 8 bit mode, then
readid or onfi detection are done (and detect bus width).
The driver should update its bus width before calling nand_scan_tail.
This work because readid and onfi are read work 8 byte
On 11/29/2012 05:47 PM, Vinod Koul wrote:
On Thu, 2012-11-29 at 16:24 -0600, Jon Hunter wrote:
When compiling the kernel with DMA engine support enabled and device-tree
support disabled, the following warnings are observed.
Thanks, already committed same change last night.
Great! Thanks.
On Fri, 30 Nov 2012, Philip, Avinash wrote:
Is there any way to get HWMOD and DT patches getting accepted in 3.8?
Or should I wait and send rebased patch based on 3.8-rc1?
Our upstreams aren't taking any more new features for v3.8, so basing on
v3.8-rc1 is the best thing to do now.
In the
On Fri, 30 Nov 2012, Andy Green (林安廸) wrote:
I have everything discussed above ready for a try#2, including the
descendant matching stuff in separate patches. The code got a lot
smaller and better with the _ops struct.
The new code can attach the assets to the targeted hub port as
* Olof Johansson o...@lixom.net [121129 22:55]:
On Mon, Nov 26, 2012 at 05:06:12PM -0800, Tony Lindgren wrote:
The following changes since commit 0f9cb211ba5db93d488fe6b154138231fdd0e22d:
Merge tag 'v3.7-rc7' into next/cleanup (2012-11-25 21:34:34 -0800)
are available in the git
* Santosh Shilimkar santosh.shilim...@ti.com [121130 00:06]:
Olof,
On Friday 30 November 2012 12:48 PM, Olof Johansson wrote:
On Mon, Nov 26, 2012 at 05:06:11PM -0800, Tony Lindgren wrote:
The following changes since commit 9dc57643738f9fbe45c10cc062903d5dfda5bdd9:
Merge branch
* Olof Johansson o...@lixom.net [121129 22:56]:
On Mon, Nov 26, 2012 at 05:06:12PM -0800, Tony Lindgren wrote:
The following changes since commit 558a0780b0a04862a678f7823215424b4e5501f9:
Merge tag 'omap-cleanup-c-for-3.8' of
* Andreas Fenkart andreas.fenk...@streamunlimited.com [121130 03:21]:
The alternative was to configure dat1 line as a GPIO, while
waiting for an IRQ. Then configuring it back as dat1 when the
SDIO card is signalling an IRQ. Or the host starts a transfer. I
guess this will perform poorly,
Hi Tony,
Hi Andreas,
On 30.11.2012 18:40, Tony Lindgren wrote:
* Andreas Fenkart andreas.fenk...@streamunlimited.com [121130 03:21]:
The alternative was to configure dat1 line as a GPIO, while
waiting for an IRQ. Then configuring it back as dat1 when the
SDIO card is signalling an IRQ. Or
Hi,
On Wed, Nov 21, 2012 at 1:51 PM, Tony Lindgren t...@atomide.com wrote:
The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:
Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
are available in the git repository at:
On Fri, Nov 30, 2012 at 9:26 AM, Tony Lindgren t...@atomide.com wrote:
* Olof Johansson o...@lixom.net [121129 22:55]:
On Mon, Nov 26, 2012 at 05:06:12PM -0800, Tony Lindgren wrote:
The following changes since commit
0f9cb211ba5db93d488fe6b154138231fdd0e22d:
Merge tag 'v3.7-rc7' into
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, each struct platform_device could have a list of
30 matches
Mail list logo
