On Tuesday 30 October 2012 01:33 AM, Felipe Balbi wrote:
Hi,
On Mon, Oct 29, 2012 at 01:53:37PM +0530, Santosh Shilimkar wrote:
Just to expand a bit, Out of 6 GPIO banks, GPIO1 bank is in always ON
domain where as remaing 5 are in peripheral domain. Letting individual
banks idle allowed you
Hi,
On Tue, Oct 30, 2012 at 12:02:17PM +0530, Santosh Shilimkar wrote:
I still think mod_usage needs to go, so does
omap_gpio_prepare_for_idle() and omap_gpio_resume_from_idle(). To me, it
looks like that needs to be done on -prepare()/-complete() callbacks
of system suspend and the gpio
Hi Paul,
On 10/30/2012 05:05 AM, Paul Walmsley wrote:
omap_hwmod: mcpdm: cannot be enabled for reset (3)
The McPDM on OMAP4 can only receive its functional clock from an
off-chip source. This source is not guaranteed to be present on the
board, and when present, it is controlled by I2C.
Hi Paul,
On Tue, Oct 30, 2012 at 5:16 AM, Paul Walmsley p...@pwsan.com wrote:
Hello Jean,
On Tue, 23 Oct 2012, Jean Pihet wrote:
Let me try with the same setup as yours (bootloader images,
omap2pus_defconfig, angstrom roots).
Had any luck reproducing this one that Aaro I are seeing?
Hi Sourav,
On 10/30/2012 6:26 AM, Sourav wrote:
Hi Benoit,
On Monday 29 October 2012 10:14 PM, Benoit Cousson wrote:
Hi Sourav,
On 10/29/2012 11:40 AM, Sourav Poddar wrote:
Add keypad data node in omap5-evm.
Based on I2C support patch for omap5, which has been
already posted as a different
Hi Benoit,
On Tuesday 30 October 2012 02:43 PM, Cousson, Benoit wrote:
Hi Sourav,
On 10/30/2012 6:26 AM, Sourav wrote:
Hi Benoit,
On Monday 29 October 2012 10:14 PM, Benoit Cousson wrote:
Hi Sourav,
On 10/29/2012 11:40 AM, Sourav Poddar wrote:
Add keypad data node in omap5-evm.
Based on
On Mon, Oct 29, 2012 at 14:40:02, Philip, Avinash wrote:
On Thu, Oct 18, 2012 at 18:56:55, Porter, Matt wrote:
Adds AM33XX SPI support for am335x-bone and am335x-evm.
Matt,
Can you build SPI DT patch with DMA support on top of SPI DT patch
I submitted [1]. With the patch [1] SPI can work on
Hello,
This series resolves the issue we currently have with the resource handling when
booting with DT.
In short: at the moment the omap_device_alloc() decides if it needs to update
the
OF filled resources based on the number of resources on the device and in the
hwmod database.
This prevents
Add flags parameter for omap_hwmod_count_resources() so users can tell which
type of resources they are interested when counting them in hwmod database.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 27 ---
When booting with DT the OF core can fill up the resources provided within
the DT blob.
The current way of handling the DT boot prevents us from removing hwmod data
for platforms only suppose to boot with DT (OMAP5 for example) since we need
to keep the whole hwmod database intact in order to have
On 10/30/2012 11:33 AM, Peter Ujfalusi wrote:
When booting with DT the OF core can fill up the resources provided within
the DT blob.
The current way of handling the DT boot prevents us from removing hwmod data
for platforms only suppose to boot with DT (OMAP5 for example) since we need
to
Hi Jean,
On Tue, 30 Oct 2012, Jean Pihet wrote:
On Tue, Oct 30, 2012 at 5:16 AM, Paul Walmsley p...@pwsan.com wrote:
On Tue, 23 Oct 2012, Jean Pihet wrote:
Let me try with the same setup as yours (bootloader images,
omap2pus_defconfig, angstrom roots).
Had any luck reproducing this
Add flags parameter for omap_hwmod_count_resources() so users can tell which
type of resources they are interested when counting them in hwmod database.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 27 ---
Hello,
Changes since v1:
- If the device does not have DMA resource do not try to recreate the resources
Intro mail from v1:
This series resolves the issue we currently have with the resource handling when
booting with DT.
In short: at the moment the omap_device_alloc() decides if it needs to
When booting with DT the OF core can fill up the resources provided within
the DT blob.
The current way of handling the DT boot prevents us from removing hwmod data
for platforms only suppose to boot with DT (OMAP5 for example) since we need
to keep the whole hwmod database intact in order to have
On Tue, 30 Oct 2012, Peter Ujfalusi wrote:
Tony, Benoit, Paul: Not sure if this qualify for 3.7 inclusion, but for sure
going to help us to clean up the OMAP5 hwmod database.
It's definitely not 3.7 material, but will look at it for 3.8 merge
window. The OMAP5 hwmod data isn't in mainline
On 30/10/12 02:36, Paul Walmsley wrote:
Here are some basic OMAP test results for Linux v3.7-rc3.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.7-rc3/20121028162003/
Passing tests
-
Boot to userspace: 2420n800, 3517evm, 3530es3beagle,
On 10/30/2012 12:25 PM, Paul Walmsley wrote:
On Tue, 30 Oct 2012, Peter Ujfalusi wrote:
Tony, Benoit, Paul: Not sure if this qualify for 3.7 inclusion, but for sure
going to help us to clean up the OMAP5 hwmod database.
It's definitely not 3.7 material, but will look at it for 3.8 merge
cc Vaibhav Hiremath
On Tue, 30 Oct 2012, Mark Jackson wrote:
At what point is booting from MMC on the BeagleBone going to start working ?
I only ask, since, by default, a new BeagleBone is setup to boot from
MMC, so anyone testing a new kernel will probably expect the same setup
to work.
Hello.
You forgot to sign off on the patch, so it can't be applied.
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
On Tue, Oct 30, 2012 at 11:24:10AM +, Mark Brown wrote:
This is why I think hiding things from drivers makes no sense. Also
consider the situations Linus W exposed on another subthread. If you
change ordering of certain calls, you will really break the
functionality of the IP.
On Mon, 29 Oct 2012, Vaibhav Hiremath wrote:
On 10/26/2012 4:51 AM, Paul Walmsley wrote:
Remove arch/arm/mach-omap2/prcm.c and
arch/arm/plat-omap/include/plat/prcm.h. This is in preparation for
moving the PRM/CM code to drivers/, although to be fair, these files
should have been
Tony,
On 29 October 2012 12:52, Tony Lindgren t...@atomide.com wrote:
--- /dev/null
+++ b/include/linux/platform_data/omap_mailbox.h
@@ -0,0 +1,105 @@
This file should only contain pure platform data needed
by the core omap code to pass to the mailbox driver.
Ok, looking at it closely,
Alan,
On Mon, Oct 29, 2012 at 8:54 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Mon, 29 Oct 2012, Mohan V wrote:
I'm not going to be able to help very much with an Android kernel.
Does the same problem occur with a vanilla non-Android 3.6 kernel? If
it doesn't, that indicates the
Hi,
On Tue, Oct 30, 2012 at 12:17:11PM +, Paul Walmsley wrote:
On Mon, 29 Oct 2012, Felipe Balbi wrote:
that's too bad :-(
Can you compile with:
CONFIG_I2C_DEBUG_CORE=y
CONFIG_I2C_DEBUG_ALGO=y
CONFIG_I2C_DEBUG_BUS=y
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=9
so that I can see
On Tue, Oct 30, 2012 at 17:17:00, Paul Walmsley wrote:
cc Vaibhav Hiremath
On Tue, 30 Oct 2012, Mark Jackson wrote:
At what point is booting from MMC on the BeagleBone going to start working ?
I only ask, since, by default, a new BeagleBone is setup to boot from
MMC, so anyone
On Tue, 30 Oct 2012, Felipe Balbi wrote:
the wmb() patch should help, but you said it doesn't, right ?
Correct. Not sure why you think that would help; the problem is almost
certainly PM-idle related, given that the problem goes away by reverting
Jean's commit
Hi,
On Tue, Oct 30, 2012 at 12:50:52PM +, Paul Walmsley wrote:
On Tue, 30 Oct 2012, Felipe Balbi wrote:
the wmb() patch should help, but you said it doesn't, right ?
Correct. Not sure why you think that would help; the problem is almost
because of how the driver is behaving...
The
On Tue, 30 Oct 2012, Vaibhav Hiremath wrote:
On 10/30/2012 8:06 AM, Paul Walmsley wrote:
* AM335x Beaglebone: omap2plus_defconfig kernels don't boot
- Due to GPMC missing support for DT
- Temporary workaround at
http://www.spinics.net/lists/arm-kernel/msg200787.html
- May be
On Tue, 30 Oct 2012, Felipe Balbi wrote:
On Tue, Oct 30, 2012 at 12:50:52PM +, Paul Walmsley wrote:
certainly PM-idle related, given that the problem goes away by reverting
Jean's commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc ARM: OMAP: convert
I2C driver to PM QoS for MPU latency
On Tue, Oct 30, 2012 at 12:34 PM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Sun, Oct 28, 2012 at 09:12:52PM +0100, Linus Walleij wrote:
Moving this handling to bus code or anywhere else
invariably implies that resource acquisition/release order
does not matter, and my point is
On Tue, 30 Oct 2012, Paul Walmsley wrote:
Based on a very quick look, I'd say the original patch 3db11fe is broken.
I don't see how it can ensure that its PM_QOS_CPU_DMA_LATENCY request is
honored when CONFIG_CPU_IDLE=n. CONFIG_CPU_IDLE=n is the default for
omap2plus_defconfig.
So in
On Tue, Oct 30, 2012 at 01:49:49PM +0200, Felipe Balbi wrote:
On Tue, Oct 30, 2012 at 11:24:10AM +, Mark Brown wrote:
We need some place to put the SoC integration; power domains seem like
the obvious place to me but YMMV. Nothing about having this out of the
except that pin muxing
On Tue, Oct 30, 2012 at 12:49 PM, Felipe Balbi ba...@ti.com wrote:
On Tue, Oct 30, 2012 at 11:24:10AM +, Mark Brown wrote:
We need some place to put the SoC integration; power domains seem like
the obvious place to me but YMMV. Nothing about having this out of the
except that pin muxing
On Wed, Oct 03, 2012 at 18:06:10, Linus Walleij wrote:
On Wed, Oct 3, 2012 at 12:52 PM, AnilKumar, Chimata anilku...@ti.com wrote:
On Tue, Oct 02, 2012 at 01:29:37, Linus Walleij wrote:
This is what we're doing for ux500 and should be a good model.
I have looked into this, but not seen
Hi Felipe,
On 10/30/2012 02:09 AM, Felipe Balbi wrote:
...
its bit of an issue to take care. How do you ensure that GPIO
does idle on SOC idle C-state attempts in such cases. Today that
job is done by omap_gpio_[prepare/resume]_for_idle.
that's only there because we pm_runtime_get_sync()
On Tue, Oct 30, 2012 at 03:02:23PM +0100, Linus Walleij wrote:
I worry that we will end up with power/resource domain
code that start to look like this:
suspend()
switch (device.id) {
case DEV_FOO:
clk_disable();
pinctrl_set_state();
power_domain_off();
case DEV_BAR:
Well, if
On Mon, 29 Oct 2012, Vaibhav Hiremath wrote:
This patch adds reboot capability to all AM33XX based boards/EVM's,
by asserting PRM warm reset bit on 'reboot' command.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Tested-by: Daniel Mack zon...@gmail.com
Cc: Paul Walmsley p...@pwsan.com
On 10/30/2012 6:09 PM, Hiremath, Vaibhav wrote:
On Tue, Oct 30, 2012 at 17:17:00, Paul Walmsley wrote:
cc Vaibhav Hiremath
On Tue, 30 Oct 2012, Mark Jackson wrote:
At what point is booting from MMC on the BeagleBone going to start working ?
I only ask, since, by default, a new BeagleBone
On Tue, Oct 30, 2012 at 03:16:02PM +0100, Linus Walleij wrote:
On Tue, Oct 30, 2012 at 3:07 PM, Mark Brown
Essentially all the patches I'm seeing adding pinctrl are totally
mindless, most of them are just doing the initial setup on boot and not
doing any active management at runtime at
Hi,
On Tue, Oct 30, 2012 at 09:16:34AM -0500, Jon Hunter wrote:
Hi Felipe,
On 10/30/2012 02:09 AM, Felipe Balbi wrote:
...
its bit of an issue to take care. How do you ensure that GPIO
does idle on SOC idle C-state attempts in such cases. Today that
job is done by
Hi,
On Tue, Oct 30, 2012 at 02:07:15PM +, Mark Brown wrote:
On Tue, Oct 30, 2012 at 01:49:49PM +0200, Felipe Balbi wrote:
On Tue, Oct 30, 2012 at 11:24:10AM +, Mark Brown wrote:
We need some place to put the SoC integration; power domains seem like
the obvious place to me but
On Tue, Oct 30, 2012 at 05:16:42PM +0200, Felipe Balbi wrote:
On Tue, Oct 30, 2012 at 02:07:15PM +, Mark Brown wrote:
and all of that SoC-specific detail is already hidden behind power
domains, runtime PM, pinctrl, clk API, regulator framework, etc.
That's all getting rather open
On Tue, 30 Oct 2012, Mohan V wrote:
Device not getting detected when
connected---
/ # [ 135.621002] usbhs_wakeup: Enabling clocks
[ 135.625762] usbhs_runtime_resume:++
[ 135.630371] usbhs_runtime_resume:--
[
Hi,
The aim of this series is to enable using DSI PLL as the pixel clock source for
DPI output. There are the following main parts:
* first 4 patches are slightly related generic improvements/fixes
* fix DSI PLL problem related to non-50% duty cycle
* fix DSI PLL problem related to powering
*
It seems that using the second EDID block causes more problems than is
of any help. The first mode in the extended block will get
FB_MODE_IS_FIRST set, which will override the first mode from the first
EDID block, thus making the default videomode selection not to work
properly.
This patch
The current omapfb code goes over all the modes found from the monitors
EDID data, and searches for a mode that is compatible with the DSS
hardware and has the highest x-res.
While this works ok as such, it proves problematic when using DSI PLL
for pixel clock. Calculating DSI PLL dividers is not
DPI may use DSI PLL, so it depends on DSI. However, currently DPI driver
is added first, which causes DPI initialization to fail when it tries to
get the DSI PLL.
This patch changes the init order to fix this.
A better solution would be to separate DSI PLL and DSI drivers. They
have
dss_generic_clk_source_names is missing the names for clocks from DSI2
PLL. Add them.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dss.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index
The DSI PLL and HSDivider can be used to generate the pixel clock for
LCD overlay manager, which then goes to DPI output. On the DPI output
pin the voltage of the signal is shifted from the OMAP's internal
minimal voltage to 1.8V range. The shifting is not instant, and the
higher the clock
It looks like on many OMAP versions powers for both HSClk and HSDiv to
be enabled to have a functional HSDiv.
This patch fixes the issue by forcing both powers on.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dsi.c |6 ++
1 file changed, 6
dss_calc_clock_rates() was removed earlier as it was not used, but it is
needed for DSI PLL calculations, so this patch adds it back.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dss.c | 23 +++
drivers/video/omap2/dss/dss.h |1 +
2
We don't currently set the dss fck when starting up. This is not a
problem, as we setup the fck later when configuring the pixel clocks. Or
this is how it was for omap2, for the rest of the omaps this may not be
so.
For DSI, HDMI and also for DPI when using DSI PLL, we don't need to
change the
dss.c currently exposes functions to configure the dispc source clock
and lcd source clock. There are configured separately from the output
drivers.
However, there is no safe way for the output drivers to handle dispc
clock, as it's shared between the outputs. Thus, if, say, the DSI driver
sets
The SoCs that have DSI module should have a working DSI PLL. However,
some rare boards have not connected the powers to the DSI PLL.
This patch adds a function that tries to power up the DSI PLL, and
reports if that doesn't succeed. DPI uses this function to fall back to
PRCM clocks if DSI PLL
Instead of using dpi_use_dsi_pll() to check if dsi pll is to be used, we
can just check if dpi.dsidev != NULL.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dpi.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git
We currently get the decision whether to use PRCM or DSI PLL clock for
DPI from the board file. This is not a good way to handle it, and it
won't work with device tree.
This patch changes DPI to always use DSI PLL if it's available.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
* Omar Ramirez Luna omar.l...@linaro.org [121030 05:20]:
Tony,
On 29 October 2012 12:52, Tony Lindgren t...@atomide.com wrote:
--- /dev/null
+++ b/include/linux/platform_data/omap_mailbox.h
@@ -0,0 +1,105 @@
This file should only contain pure platform data needed
by the core omap
* Vaibhav Hiremath hvaib...@ti.com [121030 07:50]:
MMC is dependent on EDMA-DMA conversion patches from Matt, which he has
already submitted to the list recently. So MMC support will come along with
EDMA support. DMA-EDMA patches are targeted for v3.8, lets see how it goes.
This is a
* Tony Lindgren t...@atomide.com [121026 11:02]:
* Ohad Ben-Cohen o...@wizery.com [121026 02:56]:
Hi Laurent,
On Fri, Oct 26, 2012 at 11:35 AM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
That's on my to-do list, as well as porting the OMAP3 ISP driver to
videobuf2,
Hi Peter,
On 10/30/2012 12:24 PM, Peter Ujfalusi wrote:
Hello,
Changes since v1:
- If the device does not have DMA resource do not try to recreate the resources
Intro mail from v1:
This series resolves the issue we currently have with the resource handling when
booting with DT.
In short: at
Hi,
On Tue, Oct 30, 2012 at 03:58:21PM +, Mark Brown wrote:
and this is one of the issues we're all trying to solve today so we have
single zImage approach for the ARM port.
I don't see the relevance of single zImage here; device tree is supposed
to solve that one.
DT is
Hi,
On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
* Vaibhav Hiremath hvaib...@ti.com [121030 07:50]:
MMC is dependent on EDMA-DMA conversion patches from Matt, which he has
already submitted to the list recently. So MMC support will come along
with
EDMA
* Felipe Balbi ba...@ti.com [121030 10:34]:
Hi,
On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
* Vaibhav Hiremath hvaib...@ti.com [121030 07:50]:
MMC is dependent on EDMA-DMA conversion patches from Matt, which he has
already submitted to the list recently. So
There's no reason to have the OF defines; it complicates the driver.
There's also no need for the funky platform_driver_probe.
Add a few warnings in case there's a failure; helps us find out
what went wrong.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
Various platforms need access to the EEPROM in other
places besides their platform registration callbacks.
Export the memory accessor to the i2c_client and implement
it for the at24 driver.
And before you ask, no, the platform callback can't be used
for anything that depends on DT.
The MFD parent device now uses a regmap, instead of direct
memory access. Use the same method in the sub devices to avoid
nasty surprises.
Also rework the channel initialization of tiadc a bit.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/iio/adc/ti_am335x_adc.c
The revision check fails for the beaglebone; Add new revision ID.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/video/da8xx-fb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 80665f6..866d804 100644
---
Enable pinctrl for pwm-backlight.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/video/backlight/pwm_bl.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 0c91023..f3b6194 100644
---
There's no need for this to be const. It interferes with
creating the platform data dynamically.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
include/video/da8xx-fb.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/video/da8xx-fb.h
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/video/da8xx-fb.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index c661665..c1f5d30 100644
--- a/drivers/video/da8xx-fb.c
+++
This driver can be used for AM33xx devices, like the popular beaglebone.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/video/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index
The current code expect the configuration of the backlight to stay
constant after initialization. This patch allows to move it around.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/video/backlight/tps65217_bl.c | 103 ++
1 file
This simple patch enables dynamic changes of the DT tree on runtime
to be visible to the device-tree proc interface.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
arch/arm/include/asm/prom.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/include/asm/prom.h
Enable pinctrl for w1-gpio.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/w1/masters/w1-gpio.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/w1/masters/w1-gpio.c b/drivers/w1/masters/w1-gpio.c
index 6012c4e..aec35bd 100644
---
Probe devices for a node other that the adapter node.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/of/of_i2c.c| 14 ++
include/linux/of_i2c.h | 3 +++
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/of/of_i2c.c
No need to hide of_pwm_request, it's useful to other in-kernel users.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/pwm/core.c | 6 +-
include/linux/pwm.h | 7 +++
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/pwm/core.c
Export an interface that other in-kernel users can utilize.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/spi/spi.c | 31 +++
include/linux/spi/spi.h | 18 ++
2 files changed, 41 insertions(+), 8 deletions(-)
diff
Add an IIO map interface that consumers can use.
Also make sure the mfd device doesn't activate a driver which
the configuration doesn't require.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/iio/adc/ti_am335x_adc.c | 53 ++--
Looks like the lcdc clock definition got dropped.
It is required for the LCD controller to work. Reintroduce.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
arch/arm/mach-omap2/clock33xx_data.c | 11 +++
1 file changed, 11 insertions(+)
diff --git
From: Koen Kooi k...@dominion.thruhere.net
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
drivers/video/da8xx-fb.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 4462d9e..c661665 100644
---
* Pantelis Antoniou pa...@antoniou-consulting.com [121030 11:04]:
Enable pinctrl for i2c-omap.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
Looks good to me:
Acked-by: Tony Lindgren t...@atomide.com
---
drivers/i2c/busses/i2c-omap.c | 10 ++
1 file changed, 10
* Pantelis Antoniou pa...@antoniou-consulting.com [121030 11:04]:
Looks like the lcdc clock definition got dropped.
It is required for the LCD controller to work. Reintroduce.
This looks like a regression, can you also add the commit
causing it?
Regards,
Tony
Signed-off-by: Pantelis
Add standard panel definition that can work for the beaglebone
DVI cape.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/video/da8xx-fb.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index
Enable pinctrl for i2c-omap.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/i2c/busses/i2c-omap.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index db31eae..4c38aa0 100644
---
Enable pinctrl support for gpio-keys.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/input/keyboard/gpio_keys.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/input/keyboard/gpio_keys.c
b/drivers/input/keyboard/gpio_keys.c
index 6a68041..e421082
On Tue, Oct 30, 2012 at 07:25:13PM +0200, Felipe Balbi wrote:
On Tue, Oct 30, 2012 at 03:58:21PM +, Mark Brown wrote:
But then this comes round to the mindless code that ought to be factored
out :) Only the more interesting cases that do something unusual really
register here.
* Pantelis Antoniou pa...@antoniou-consulting.com [121030 11:05]:
omap_hwmod_lookup / omap_device_build / omap_device_build_ss;
these functions can be used just fine by modules, there's no need not
to have them exported.
Just curious, where do you plan to use these?
These will be private to
Hi Tony,
The patches that use them are going to be posted in about 30mins.
They will make this clear.
Regards
-- Pantelis
On Oct 30, 2012, at 8:22 PM, Tony Lindgren wrote:
* Pantelis Antoniou pa...@antoniou-consulting.com [121030 11:05]:
omap_hwmod_lookup / omap_device_build /
* Pantelis Antoniou pa...@antoniou-consulting.com [121030 11:23]:
Enable pinctrl support for gpio-keys.
There's some discussion going on regarding doing the
pinctrl boilerplate things somewhere else started by
Dmitry, but meanwhile:
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by:
* Pantelis Antoniou pa...@antoniou-consulting.com [121030 11:17]:
Enable pinctrl for w1-gpio.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
Acked-by: Tony Lindgren t...@atomide.com
---
drivers/w1/masters/w1-gpio.c | 7 +++
1 file changed, 7 insertions(+)
diff --git
On 10/31/2012 04:55 PM, Pantelis Antoniou wrote:
The MFD parent device now uses a regmap, instead of direct
memory access. Use the same method in the sub devices to avoid
nasty surprises.
Also rework the channel initialization of tiadc a bit.
Those two bits are not even closely related,
On 10/31/2012 04:55 PM, Pantelis Antoniou wrote:
Add an IIO map interface that consumers can use.
Also make sure the mfd device doesn't activate a driver which
the configuration doesn't require.
Same here, two completely different changes in the same patch.
Signed-off-by: Pantelis Antoniou
OK,
Will rework it, and repost.
On Oct 30, 2012, at 8:21 PM, Lars-Peter Clausen wrote:
On 10/31/2012 04:55 PM, Pantelis Antoniou wrote:
The MFD parent device now uses a regmap, instead of direct
memory access. Use the same method in the sub devices to avoid
nasty surprises.
Also rework
On Tue, Oct 30, 2012 at 07:25:13PM +0200, Felipe Balbi wrote:
On Tue, Oct 30, 2012 at 03:58:21PM +, Mark Brown wrote:
But then this comes round to the mindless code that ought to be factored
out :) Only the more interesting cases that do something unusual really
register here.
fair
On 10/31/2012 08:56 AM, Pantelis Antoniou wrote:
Various platforms need access to the EEPROM in other
places besides their platform registration callbacks.
Export the memory accessor to the i2c_client
i2c_clients are *not* intrinsically memory, so adding this to the
generic i2c_client
Hi David,
On Oct 30, 2012, at 8:46 PM, David Daney wrote:
On 10/31/2012 08:56 AM, Pantelis Antoniou wrote:
Various platforms need access to the EEPROM in other
places besides their platform registration callbacks.
Export the memory accessor to the i2c_client
i2c_clients are *not*
Hi,
On Tue, Oct 30, 2012 at 11:20:07AM -0700, Dmitry Torokhov wrote:
On Tue, Oct 30, 2012 at 07:25:13PM +0200, Felipe Balbi wrote:
On Tue, Oct 30, 2012 at 03:58:21PM +, Mark Brown wrote:
But then this comes round to the mindless code that ought to be factored
out :) Only the
Hi,
On Tue, Oct 30, 2012 at 10:58:59AM -0700, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [121030 10:34]:
Hi,
On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
* Vaibhav Hiremath hvaib...@ti.com [121030 07:50]:
MMC is dependent on EDMA-DMA conversion
Capebus is created to address the problem of many SoCs that can provide a
multitude of hardware interfaces but in order to keep costs down the main
boards only support a limited number of them. The rest are typically brought
out to pin connectors on to which other boards, named capes are connected
1 - 100 of 151 matches
Mail list logo
