On Wed, Oct 31, 2012 at 11:14:28, Balbi, Felipe wrote:
> Hi,
>
> On Wed, Oct 31, 2012 at 06:17:02AM +0100, Hebbar, Gururaja wrote:
> > On Mon, Oct 29, 2012 at 21:47:19, Balbi, Felipe wrote:
> > > Hi,
> > >
> > > On Mon, Oct 29, 2012 at 06:26:48PM +0530, Hebbar, Gururaja wrote:
> > > > HSMMC IP on
On Tuesday 30 October 2012 09:40 PM, Tomi Valkeinen wrote:
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 shar
On Tuesday 30 October 2012 09:40 PM, Tomi Valkeinen wrote:
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. T
On Wed, 31 Oct 2012, Vaibhav Hiremath wrote:
> omap5xxx_restart declaration needs to be removed from here.
> There is no such function implemented in code.
Thanks, prototype dropped.
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majo
On Wed, Oct 31, 2012 at 11:19:44, Paul Walmsley wrote:
> On Wed, 31 Oct 2012, Hiremath, Vaibhav wrote:
>
> > As far as lck clock node is concerned, we had deliberately dropped all leaf-
> > node clocks from the clock tree, please refer to the description mentioned
> > in -
> > http://lists.infrad
On 10/26/2012 4:51 AM, Paul Walmsley wrote:
> Split omap_prcm_restart() from mach-omap2/prcm.c into SoC-specific
> variants. These functions need to be able to save the reboot reason
> into the scratchpad RAM. This implies a dependency on both the PRM
> and SCM IP blocks, so they've been moved
On Tuesday 30 October 2012 09:40 PM, Tomi Valkeinen wrote:
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 als
On 2012-10-31 08:10, Archit Taneja wrote:
> On Tuesday 30 October 2012 09:39 PM, Tomi Valkeinen wrote:
>> 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
On Tuesday 30 October 2012 09:39 PM, Tomi Valkeinen wrote:
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
On Tue, Oct 30, 2012 at 09:41:00PM -0700, Russ Dill wrote:
> On Wed, Oct 31, 2012 at 8:55 AM, 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 ch
Hi,
On Wed, Oct 31, 2012 at 06:17:02AM +0100, Hebbar, Gururaja wrote:
> On Mon, Oct 29, 2012 at 21:47:19, Balbi, Felipe wrote:
> > Hi,
> >
> > On Mon, Oct 29, 2012 at 06:26:48PM +0530, Hebbar, Gururaja wrote:
> > > HSMMC IP on AM33xx need a special setting to handle High-speed cards.
> > > Other
On Wed, 31 Oct 2012, Hiremath, Vaibhav wrote:
> As far as lck clock node is concerned, we had deliberately dropped all leaf-
> node clocks from the clock tree, please refer to the description mentioned
> in -
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-May/101987.html
Ach, shoul
On Wed, Oct 31, 2012 at 01:58:32, Joel A Fernandes wrote:
> Hi Gururaja,
>
> On Mon, Oct 29, 2012 at 10:45 AM, Hebbar, Gururaja
> wrote:
> > Matt,
> >
> > On Wed, Oct 10, 2012 at 20:00:49, Porter, Matt wrote:
> >> 6ea74cb ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage
> >> exposes
On Tue, Oct 30, 2012 at 17:27:02, Paul Walmsley wrote:
> 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 P
Hi,
On Wed, Oct 31, 2012 at 21:26:08, Pantelis Antoniou wrote:
> This driver can be used for AM33xx devices, like the popular beaglebone.
>
> Signed-off-by: Pantelis Antoniou
> ---
> drivers/video/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/Kc
On Mon, Oct 29, 2012 at 21:47:19, Balbi, Felipe wrote:
> Hi,
>
> On Mon, Oct 29, 2012 at 06:26:48PM +0530, Hebbar, Gururaja wrote:
> > HSMMC IP on AM33xx need a special setting to handle High-speed cards.
> > Other platforms like TI81xx, OMAP4 may need this as-well. This depends
> > on the HSMMC I
On Wed, Oct 31, 2012 at 04:56:40, Paul Walmsley wrote:
> + Vaibhav Hiremath
>
> On Tue, 30 Oct 2012, Tony Lindgren wrote:
>
> > * Pantelis Antoniou [121030 11:04]:
> > > Looks like the lcdc clock definition got dropped.
> > > It is required for the LCD controller to work. Reintroduce.
> >
> > T
Our e-mail content detector has just been triggered by a message you sent:
To: jaid...@ashokabuilders.com
Subject: Mail System Error - Returned Mail
Date: Wed Oct 31 10:13:06 2012
One or more of the attachments (jaideepashokabuilders.com.doc.scr,
jaid...@ashokabuilders.com.zip) are on
the
On Wed, Oct 31, 2012 at 8:55 AM, 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.
>
> Signed-off-by: Pantelis Antoniou
On Wed, Oct 31, 2012 at 21:26:24, Pantelis Antoniou wrote:
> The revision check fails for the beaglebone; Add new revision ID.
>
> Signed-off-by: Pantelis Antoniou
> ---
> drivers/video/da8xx-fb.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/video/da8xx-fb.c b/drivers/video/
On Tue, 30 Oct 2012, Tony Lindgren wrote:
> As discussed on linux-arm-kernel, we want to avoid
> relative includes for the arch/arm/*omap* shared code:
>
> http://www.spinics.net/lists/linux-omap/msg80520.html
>
> Let's add plat/debug-devices.h for debug_card_init()
> to fix the relative include
* Pantelis Antoniou [121030 13:18]:
> On Oct 30, 2012, at 9:39 PM, Tony Lindgren wrote:
>
> > * Pantelis Antoniou [121030 12:00]:
> >> +
> >> + priv->lcdc_oh = omap_hwmod_lookup("lcdc");
> >> + if (priv->lcdc_oh == NULL) {
> >> + dev_err(&pdev->dev, "Failed to lookup omap_hwmod lcdc\n
* Tony Lindgren [121027 09:34]:
> * Russell King - ARM Linux [121027 02:03]:
> >
> > Rather than moving all the files from plat-omap/include/plat into plat-omap
> > and then having all these totally disgusting relative includes, why don't
> > you add to these makefiles:
> >
> > ccflags += -I$(s
As discussed on linux-arm-kernel, we want to avoid
relative includes for the arch/arm/*omap* code:
http://www.spinics.net/lists/linux-omap/msg80520.html
Note that eventually when the omap1 specific drivers
are fixed to not use cpu_is_omap macros and not depend
on mach/hardware.h, this patch can b
This code will be eventually in drivers, and for the
code in the drivers we don't want to have any cpu_is_omap
usage. Those macros should be private to arch/arm/mach-omap1
and arch/arm/mach-omap2.
To fix this, let's move the define for dma_omap2plus()
to dma-omap.h, and use the existing dma_attr p
As discussed on linux-arm-kernel, we want to avoid
relative includes for the arch/arm/*omap* shared code:
http://www.spinics.net/lists/linux-omap/msg80520.html
Let's add plat/debug-devices.h for debug_card_init()
to fix the relative includes.
Note that drivers must not use this header as it will
Most of the prototypes in plat-omap/common.h are not
common to omap1 and omap2+, they are local to omap2+
and should not be in plat-omap/common.h.
The only shared function prototype in this file is
omap_init_clocksource_32k(), let's put that into
counter-32k.h.
Note that the new plat/counter-32k.
This code should be private to mach-omap2.
The only use for it in for omap1 has been in dmtimer.c
to check for context loss. However, omap1 does not
lose context during idle, so the code is not needed.
Further, omap1 timer has OMAP_TIMER_ALWON set, so omap1
was not hitting omap_pm_get_dev_context_
As discussed on linux-arm-kernel, we want to avoid
relative includes for the arch/arm/*omap* shared code:
http://www.spinics.net/lists/linux-omap/msg80520.html
To fix this for the shared i2c.h, let's re-introduce
a minimal plat/i2c.h.
Note that drivers must not use this header as it will
break b
The common code should not have any omap1 or omap2+
specific code, and should not need to call the cpu_is_omap
macros.
The only remaining user for cpu_is_omap macros is
omap_i2c_nr_ports(). Let's make those checks in
the omap specific implementation of omap_i2c_add_bus()
instead in order to remove
Let's make the omap2+ specific parts private to mach-omap2.
This leaves just a minimal shared code into plat-omap like
it should be.
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/Makefile |2
arch/arm/mach-omap2/sram.c | 305 ++
arch/arm/pl
Let's make the omap1 specific parts private to mach-omap1.
These should not be in the shared code.
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap1/Makefile|3 +-
arch/arm/mach-omap1/sram-init.c | 76 +++
arch/arm/plat-omap/sram.c | 49 ++
This will allow us to separate out omap1 and omap2+ specific
code in the later patches.
Signed-off-by: Tony Lindgren
---
arch/arm/plat-omap/include/plat/sram.h |4 ++
arch/arm/plat-omap/sram.c | 64 +---
2 files changed, 46 insertions(+), 22 deletio
Most of the defines are specific to omap1 and omap2+,
and should be in the local headers. Only minimal function
prototypes need to be shared.
As discussed on linux-arm-kernel, we want to avoid
relative includes for the arch/arm/*omap* shared code:
http://www.spinics.net/lists/linux-omap/msg80520.
Hi all,
As discussed on this list, here are fixes to get rid of
the relative includes for omap that got introduced with
the recent clean-up.
This is based on what I have queued up in the
omap-for-v3.8/cleanup-headers branch at commit 986bfa5c.
Note that this series introduces few new plat/*.h fi
+ Vaibhav Hiremath
On Tue, 30 Oct 2012, Tony Lindgren wrote:
> * Pantelis Antoniou [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?
L
On Tuesday, October 30, 2012 10:51:11 PM Linus Walleij wrote:
> On Tue, Oct 30, 2012 at 7:37 PM, Mark Brown
> wrote:
>
> > More seriously the amount of time we seem to have been spending recently
> > on changes which end up requiring us to go through essentially every
> > driver and add code to t
On Tue, Oct 30, 2012 at 7:37 PM, Mark Brown
wrote:
> More seriously the amount of time we seem to have been spending recently
> on changes which end up requiring us to go through essentially every
> driver and add code to them (often several times) doesn't seem like
> we're doing a good job here.
> "Vaibhav" == Vaibhav Hiremath writes:
Vaibhav> From: Mugunthan V N
Vaibhav> Add CPSW and MDIO related device tree data for AM33XX.
Vaibhav> Also enable them into board/evm dts files by providing
Vaibhav> respective phy-id.
Vaibhav> Signed-off-by: Mugunthan V N
Vaibhav> Signed-off-b
> "Vaibhav" == Vaibhav Hiremath writes:
Vaibhav> From: Mugunthan V N
Vaibhav> This patch adds hwmod entry for davinci MDIO module,
Vaibhav> creating parent<->child relationship between CPSW and MDIO module.
Vaibhav> This Parent-child relation is required in order to use common
resource
> "Vaibhav" == Vaibhav Hiremath writes:
Vaibhav> CPGMAC SubSystem consist of various sub-modules, like, mdio,
Vaibhav> cpdma, cpsw, etc... These sub-modules are also used in some of
Vaibhav> Davinci family of devices. Now based on requirement, use-case
Vaibhav> and available technology no
> "Vaibhav" == Vaibhav Hiremath writes:
Vaibhav> By mistake (most likely a copy-paste), instead of
pm_runtime_get_sync()
Vaibhav> api, driver is calling pm_runtime_put_sync() api in resume callback
Vaibhav> function. The bug was introduced by commit id (ae2c07aaf74:
Vaibhav> davinci_mdio
On Tue, Oct 30, 2012 at 09:24:42AM -0700, Tony Lindgren wrote:
> * Omar Ramirez Luna [121030 05:20]:
> > Tony,
> >
> > On 29 October 2012 12:52, Tony Lindgren wrote:
> > >> --- /dev/null
> > >> +++ b/include/linux/platform_data/omap_mailbox.h
> > >> @@ -0,0 +1,105 @@
> > >
> > > This file should
Hi Gururaja,
On Mon, Oct 29, 2012 at 10:45 AM, Hebbar, Gururaja
wrote:
> Matt,
>
> On Wed, Oct 10, 2012 at 20:00:49, Porter, Matt wrote:
>> 6ea74cb ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage
>> exposes a bug in the AM33XX clock data for mcasp. After moving to
>> clk_get() usage
On Oct 30, 2012, at 10:14 PM, Sebastien Guiriec wrote:
> Hi Pantelis,
>
> Can you look at the early thread?
> https://patchwork.kernel.org/patch/1601331/
>
> I send a similar patch earlier with defer probe usage.
>
> Best regards,
>
> Sebastien
I see. Well let me drop the patch then.
One
On Oct 30, 2012, at 9:39 PM, Tony Lindgren wrote:
> * Pantelis Antoniou [121030 12:00]:
>> +
>> +priv->lcdc_oh = omap_hwmod_lookup("lcdc");
>> +if (priv->lcdc_oh == NULL) {
>> +dev_err(&pdev->dev, "Failed to lookup omap_hwmod lcdc\n");
>> +return -ENODEV;
>> +}
Hi Pantelis,
Can you look at the early thread?
https://patchwork.kernel.org/patch/1601331/
I send a similar patch earlier with defer probe usage.
Best regards,
Sebastien
On 10/31/2012 04:55 PM, Pantelis Antoniou wrote:
Enable pinctrl for i2c-omap.
Signed-off-by: Pantelis Antoniou
---
dr
* Pantelis Antoniou [121030 12:00]:
> +
> + priv->lcdc_oh = omap_hwmod_lookup("lcdc");
> + if (priv->lcdc_oh == NULL) {
> + dev_err(&pdev->dev, "Failed to lookup omap_hwmod lcdc\n");
> + return -ENODEV;
> + }
> +
> + priv->lcdc_pdev = omap_device_build("da8x
* Pantelis Antoniou [121030 12:00]:
> +#include
> +#include
We already have queued patches to make omap_device.h
private to arch/arm/mach-omap2. Then plat/clock.h will
be gone with the common clock framework patches.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe l
On Oct 30, 2012, at 2:53 PM, Felipe Balbi wrote:
> Hi,
>
> On Wed, Oct 31, 2012 at 05:55:30PM +0200, Pantelis Antoniou wrote:
>> Enable pinctrl for i2c-omap.
>>
>> Signed-off-by: Pantelis Antoniou
>> ---
>> drivers/i2c/busses/i2c-omap.c | 10 ++
>> 1 file changed, 10 insertions(+)
>>
>
On 10/30/2012 11:51 AM, Pantelis Antoniou wrote:
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
Introducing beaglebone generic cape support.
With this you can create almost any kind of cape driver
that doesn't require complex interconnection of the parts.
Most beaglebone capes can be created with this, including
all the display capes (DVI/VGA/LCD) with touchscreen or not,
capes that only us
Support beaglebone's geiger cape.
The geiger cape allows you to measure the amount of
ionising radiation in your area, and as an example
of how to create a complex non-generic cape driver.
Signed-off-by: Pantelis Antoniou
---
drivers/capebus/capes/Kconfig| 7 +
drivers/capebus/cap
Describe capebus DT bindings in detail.
Signed-off-by: Pantelis Antoniou
---
.../capebus/bone-capebus-slot-override.txt | 28 +++
.../devicetree/bindings/capebus/bone-capebus.txt | 50 +++
.../bindings/capebus/bone-geiger-cape.txt | 78 +
.../bindin
Small summary of capebus.
Signed-off-by: Pantelis Antoniou
---
Documentation/capebus/capebus-summary | 40 +++
1 file changed, 40 insertions(+)
create mode 100644 Documentation/capebus/capebus-summary
diff --git a/Documentation/capebus/capebus-summary
b/Documen
Update the common beaglebone's DTS with the required DT
entries for all known working capes as of now.
Signed-off-by: Pantelis Antoniou
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 689 --
1 file changed, 659 insertions(+), 30 deletions(-)
diff --git a/arch/arm/bo
Introducing capebus; a bus that allows small boards (capes) to connect
to a complex SoC using simple expansion connectors.
Up to now to support these kind of boards, one had to hack the board files,
and do all sort of gymnastics to handle all the different cases of
conflict resolution.
Capebus pr
Introduce beaglebone capebus board support.
This patch creates the beaglebone's board cape bus controller.
The board controller is responsible for the probing of capes
at the well defined I2C address for capes, parsing the EEPROM
info and matching them to specific cape drivers.
On top of that, a
Hi Felipe,
On Oct 30, 2012, at 8:53 PM, Felipe Balbi wrote:
> Hi,
>
> On Wed, Oct 31, 2012 at 05:55:30PM +0200, Pantelis Antoniou wrote:
>> Enable pinctrl for i2c-omap.
>>
>> Signed-off-by: Pantelis Antoniou
>> ---
>> drivers/i2c/busses/i2c-omap.c | 10 ++
>> 1 file changed, 10 insertio
Hi,
On Wed, Oct 31, 2012 at 05:55:30PM +0200, Pantelis Antoniou wrote:
> Enable pinctrl for i2c-omap.
>
> Signed-off-by: Pantelis Antoniou
> ---
> drivers/i2c/busses/i2c-omap.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/buss
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
Hi,
On Tue, Oct 30, 2012 at 10:58:59AM -0700, Tony Lindgren wrote:
> * Felipe Balbi [121030 10:34]:
> > Hi,
> >
> > On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
> > > * Vaibhav Hiremath [121030 07:50]:
> > > > >
> > > > > MMC is dependent on EDMA-DMA conversion patches from M
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 :) O
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*
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 structur
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.
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.
>>
>> Al
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 Anto
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,
* Pantelis Antoniou [121030 11:17]:
> Enable pinctrl for w1-gpio.
>
> Signed-off-by: Pantelis Antoniou
Acked-by: Tony Lindgren
> ---
> 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
> in
* Pantelis Antoniou [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
> Signed-off-by: Pantelis Antoniou
> ---
> drivers/input/keybo
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 [121030 11:05]:
>> omap_hwmod_lookup / omap_device_build / omap_device_build_ss;
>> these functions
* Pantelis Antoniou [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 arch/arm/mach-omap2 and won'
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 her
Enable pinctrl support for gpio-keys.
Signed-off-by: Pantelis Antoniou
---
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 100644
--- a/drivers/input/keybo
Enable pinctrl for i2c-omap.
Signed-off-by: Pantelis Antoniou
---
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
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/dr
Add standard panel definition that can work for the beaglebone
DVI cape.
Signed-off-by: Pantelis Antoniou
---
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 866d804..4462d9e 100644
--- a/drive
* Pantelis Antoniou [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 Antoniou
> ---
> arch/arm/mach-
* Pantelis Antoniou [121030 11:04]:
> Enable pinctrl for i2c-omap.
>
> Signed-off-by: Pantelis Antoniou
Looks good to me:
Acked-by: Tony Lindgren
> ---
> drivers/i2c/busses/i2c-omap.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drive
From: Koen Kooi
Signed-off-by: Koen Kooi
---
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
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -284,6 +28
Looks like the lcdc clock definition got dropped.
It is required for the LCD controller to work. Reintroduce.
Signed-off-by: Pantelis Antoniou
---
arch/arm/mach-omap2/clock33xx_data.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/mach-omap2/clock33xx_data.c
b/arch/ar
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
---
drivers/iio/adc/ti_am335x_adc.c | 53 ++--
drivers/mfd/ti_am335x_tscadc.c
Export an interface that other in-kernel users can utilize.
Signed-off-by: Pantelis Antoniou
---
drivers/spi/spi.c | 31 +++
include/linux/spi/spi.h | 18 ++
2 files changed, 41 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/spi.c b/driv
No need to hide of_pwm_request, it's useful to other in-kernel users.
Signed-off-by: Pantelis Antoniou
---
drivers/pwm/core.c | 6 +-
include/linux/pwm.h | 7 +++
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index f5acdaa..f8c7e6
Probe devices for a node other that the adapter node.
Signed-off-by: Pantelis Antoniou
---
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 b/drivers/of/of_i2c.c
index 3550f3b..7f36b05
Enable pinctrl for w1-gpio.
Signed-off-by: Pantelis Antoniou
---
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
--- a/drivers/w1/masters/w1-gpio.c
+++ b/drivers/w1/m
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
---
arch/arm/include/asm/prom.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/include/asm/prom.h b/arch/arm/include/asm/prom.h
in
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
---
drivers/video/backlight/tps65217_bl.c | 103 ++
1 file changed, 92 insertions(+), 11 deletio
This driver can be used for AM33xx devices, like the popular beaglebone.
Signed-off-by: Pantelis Antoniou
---
drivers/video/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 9791d10..e7868d8 100644
--- a/drivers/video/
Signed-off-by: Pantelis Antoniou
---
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
+++ b/drivers/video/da8xx-fb.c
@@ -298,6 +298,20 @@ st
There's no need for this to be const. It interferes with
creating the platform data dynamically.
Signed-off-by: Pantelis Antoniou
---
include/video/da8xx-fb.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/video/da8xx-fb.h b/include/video/da8xx-fb.h
index 5a0e4f9
Enable pinctrl for pwm-backlight.
Signed-off-by: Pantelis Antoniou
---
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
--- a/drivers/video/backlight/pwm_b
The revision check fails for the beaglebone; Add new revision ID.
Signed-off-by: Pantelis Antoniou
---
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
--- a/drivers/video/da8xx-fb.c
+++
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
---
drivers/iio/adc/ti_am335x_adc.c | 27 +
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.
Signed-off-by:
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
---
drivers/w1/masters/w1-gpio.c | 58
* Felipe Balbi [121030 10:34]:
> Hi,
>
> On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
> > * Vaibhav Hiremath [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
Hi,
On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
> * Vaibhav Hiremath [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
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 on
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 t
1 - 100 of 163 matches
Mail list logo
