Hi Sourav,
On Fri, Oct 05, 2012 at 12:56:26PM +0530, Sourav Poddar wrote:
> From: G, Manjunath Kondaiah
>
> SMSC ECE1099 is a keyboard scan or GPIO expansion device.The device
> supports a keypad scan matrix of 23*8.This driver uses this
> device as a keypad driver.
>
> Tested on omap5430 evm w
On Tue, Oct 23, 2012 at 10:12:29AM +, Hiremath, Vaibhav wrote:
>
> I understand, and as you mentioned we are not fully there at v3.7-rc1 with
> all the drivers/module support, due to all known reasons. Its good that with
> v3.7-rc2, Beaglebone boots up out of box from mainline.
Can you say
On 2012-10-23 20:21, Ricardo Neri wrote:
>> If so, you could pass only that one address, instead of the whole HDMI
>> register space?
> Yes, that could work. I thought about that but the common HDMI driver
> would have to know the the IP-specific register, which it should not.
Argh, of course...
From: "Mark A. Greer"
Remove usage of the private OMAP DMA API.
The dmaengine API will be used instead.
CC: Russell King
CC: Dmitry Kasatkin
Signed-off-by: Mark A. Greer
---
drivers/crypto/omap-sham.c | 117 -
1 file changed, 117 deletions(-)
diff
From: "Mark A. Greer"
Add code to use the new dmaengine API alongside
the existing DMA code that uses the private
OMAP DMA API. The API to use is chosen by
defining or undefining 'OMAP_SHAM_DMA_PRIVATE'.
CC: Russell King
CC: Dmitry Kasatkin
Signed-off-by: Mark A. Greer
---
drivers/crypto/om
From: "Mark A. Greer"
Convert the omap-sham crypto driver to use the
pm_runtime API instead of the clk API.
CC: Kevin Hilman
CC: Paul Walmsley
CC: Dmitry Kasatkin
Signed-off-by: Mark A. Greer
---
drivers/crypto/omap-sham.c | 25 +++--
1 file changed, 7 insertions(+), 18
From: "Mark A. Greer"
Convert the device data for the OMAP3 SHAM2 (SHA1/MD5) crypto IP
from explicit platform_data to hwmod.
CC: Paul Walmsley
Signed-off-by: Mark A. Greer
---
arch/arm/mach-omap2/clock3xxx_data.c | 1 +
arch/arm/mach-omap2/devices.c | 42 ++
From: "Mark A. Greer"
Remove the error message that prints when there is no SHA IP
present to make it consistent with all the other IPs.
CC: Paul Walmsley
Signed-off-by: Mark A. Greer
---
arch/arm/mach-omap2/devices.c | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
From: "Mark A. Greer"
The current OMAP2 SHAM support doesn't enable DMA
so add that support so it can use DMA just like OMAP3.
CC: Paul Walmsley
Signed-off-by: Mark A. Greer
---
arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c | 2 +-
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
From: "Mark A. Greer"
Convert the device data for the OMAP2 SHAM crypto IP from
explicit platform_data to hwmod.
CC: Paul Walmsley
Signed-off-by: Mark A. Greer
---
arch/arm/mach-omap2/clock2430_data.c | 1 +
arch/arm/mach-omap2/devices.c | 34 --
From: "Mark A. Greer"
Changes since v1:
- Removed the check of CM_IDLEST to see if the module exists
and instead add the hwmod data for all omap2's and omap3 GP's.
- Placed new sha_ick clk entries after the 'omap-sham' entry
in the clockxxx_data.c files
* Jon Hunter [121017 11:57]:
> From: Vaibhav Hiremath
>
> Add dmtimer clock aliases for AM33XX devices so that the parent clock for
> the dmtimer can be set correctly by the dmtimer driver. Without these clock
> aliases the dmtimer driver will fail to find the parent clocks for the
> dmtimer.
>
* Ohad Ben-Cohen [121021 07:56]:
> On Fri, Oct 19, 2012 at 7:07 PM, Tony Lindgren wrote:
> --- a/arch/arm/mach-davinci/board-da850-evm.c
> +++ b/arch/arm/mach-davinci/board-da850-evm.c
> @@ -1401,13 +1401,9 @@ static __init int da850_wl12xx_init(void)
> goto free_wlan_en;
> }
* Kevin Hilman [121023 15:15]:
> Tony,
>
> Here are a few more fixes PM-related fixes for v3.7-rc
>
> Kevin
>
>
> The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556:
>
> Linux 3.7-rc2 (2012-10-20 12:11:32 -0700)
>
> are available in the git repository at:
>
> gi
On 10/23/2012 1:15 PM, Jon Hunter wrote:
> Hi Mitch,
>
> On 10/23/2012 11:55 AM, Mitch Bradley wrote:
>> On 10/23/2012 4:49 AM, Jon Hunter wrote:
>>
>>> Therefore, I believe it will improve search time and hence, boot time if
>>> we have interrupt-parent defined in each node.
>>
>> I strongly susp
Hi Mitch,
On 10/23/2012 11:55 AM, Mitch Bradley wrote:
> On 10/23/2012 4:49 AM, Jon Hunter wrote:
>
>> Therefore, I believe it will improve search time and hence, boot time if
>> we have interrupt-parent defined in each node.
>
> I strongly suspect (based on many years of performance tuning, wit
On Tue, 23 Oct 2012, Kevin Hilman wrote:
> Russell King - ARM Linux writes:
>
> > On Tue, Oct 16, 2012 at 03:07:49PM -0700, Kevin Hilman wrote:
> >> From: Thomas Gleixner
> >>
> >> Attempts to retrigger nested threaded IRQs currently fail because they
> >> have no primary handler. In order to
Russell King - ARM Linux writes:
> On Tue, Oct 16, 2012 at 03:07:49PM -0700, Kevin Hilman wrote:
>> From: Thomas Gleixner
>>
>> Attempts to retrigger nested threaded IRQs currently fail because they
>> have no primary handler. In order to support retrigger of nested
>> IRQs, the parent IRQ nee
Tony,
Here are a few more fixes PM-related fixes for v3.7-rc
Kevin
The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556:
Linux 3.7-rc2 (2012-10-20 12:11:32 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-om
On Mon, Oct 22, 2012 at 07:49:47PM +, Paul Walmsley wrote:
> On Mon, 22 Oct 2012, Mark A. Greer wrote:
>
> > On Sat, Oct 20, 2012 at 07:40:19PM +, Paul Walmsley wrote:
> >
> > > > static void omap_init_sham(void)
> > > > {
> > > > - if (cpu_is_omap24xx()) {
> > > > -
Felipe Balbi writes:
> Hi,
>
> On Tue, Oct 23, 2012 at 11:09:31AM -0700, Kevin Hilman wrote:
>> From: Kevin Hilman
>>
>> When debounce clocks are disabled, ensure that the banks
>> dbck_enable_mask is cleared also. Otherwise, context restore on
>> subsequent off-mode transition will restore pr
SoC integration of SmartReflex AVS block is varied. Some use
Voltage Processor for a hardware loop in certain OMAP SoC (called
hardware loop), while others have just the AVS block without
hardware loop automatic calibration mechanism for AVS block
to talk through. So provide the Voltage Processor A
Move the SmartReflex AVS class3 driver to AVS directory along with the
config definition
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/Makefile |1 -
arch/arm/plat-omap/Kconfig |9 -
drivers/power/avs/Kconfig
Remove duplicate definitions which are already present
in linux/platform_data/voltage-omap.h
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/voltage.h |3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index 7283b7e..af9d4
Don't see why the source should be in drivers/power/avs, but not
config option
Signed-off-by: Nishanth Menon
---
arch/arm/plat-omap/Kconfig | 22 --
drivers/power/avs/Kconfig | 22 ++
2 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/ar
Minor cleanup to use the preferred pr_warn
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/smartreflex-class3.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex-class3.c
b/arch/arm/mach-omap2/smartreflex-class3.c
index 201e219..75a
smartreflex.c now resides in drivers/power/avs directory, but class driver
is in mach-omap2. High time we move it off to drivers/power/avs.
This series *does not* try to fix VP/VC to be voltage regulator OR introduce
a new OMAP voltage regulator series. instead, it purely tries to do the minimal
c
Move voltdm_reset to include/linux/platform_data/voltage-omap.h
This is an intermediate step to allow usage of the header by smartreflex
driver for usage of the same.
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/voltage.h |1 -
include/linux/platform_data/voltage-omap.h
On Tue, Oct 23, 2012 at 02:03:43PM -0700, Kevin Hilman wrote:
> Matt Porter writes:
>
> [...]
>
> > Ok, very quick update...no need to mess around with the eeprom. I just
> > received the official word on what will be supported. Since A2 is
> > pre-release, simply go to http://beagleboard.org/su
Matt Porter writes:
[...]
> Ok, very quick update...no need to mess around with the eeprom. I just
> received the official word on what will be supported. Since A2 is
> pre-release, simply go to http://beagleboard.org/support/rma and fill
> out the form to have it replaced with the current revis
Hi,
There seems to be an issue in the omap nand driver
(drivers/mtd/nand/omap2.c) concerning sub-page reads (visible when
using 16bit LP NAND, SOFT_ECC and UBI).
Problem is caused by the omap_read_buf_pref() function using 32bit
reads from the pre-fetch engine. It takes care of the mis-aligned
l
Commit 7be2958 (ARM: PMU: Add runtime PM Support) updated the ARM PMU code to
use runtime PM which was prototyped and validated on the OMAP devices. In this
commit, there is no call pm_runtime_enable() and for OMAP devices
pm_runtime_enable() is currently being called from the OMAP PMU code when th
On Tue, Oct 23, 2012 at 11:18:12AM +0200, Benoit Cousson wrote:
> Hi Dimitry,
>
> On 10/22/2012 05:50 PM, Dmitry Torokhov wrote:
> > Hi Sourav,
> >
> > On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
> >> Adapt keypad to use pinctrl framework.
> >>
> >> Tested on omap4430 sdp with
On Mon, 22 Oct 2012, Tony Lindgren wrote:
> * Jon Hunter [121022 09:30]:
> > On 10/20/2012 04:26 PM, Paul Walmsley wrote:
> > >
> > > * 2430sdp: vfp_reload_hw oops during MMC initialization
> > > - Kernel attempts to save FP registers that don't exist; fix posted:
> > > - http://www.spinic
On Tue, Oct 23, 2012 at 9:19 PM, Paul Walmsley wrote:
> On Mon, 22 Oct 2012, Jean Pihet wrote:
>
>> On Mon, Oct 22, 2012 at 6:12 PM, Jean Pihet
>> wrote:
>>
>> > Do you have CPU_IDLE enabled?
>> FYI the issue is not present with CPU_IDLE enabled.
>
> Hmm, how can you tell? I thought you weren't
On Mon, 22 Oct 2012, Jean Pihet wrote:
> On Mon, Oct 22, 2012 at 6:12 PM, Jean Pihet wrote:
>
> > Do you have CPU_IDLE enabled?
> FYI the issue is not present with CPU_IDLE enabled.
Hmm, how can you tell? I thought you weren't able to reproduce it with
CPU_IDLE disabled either?
- Paul
--
To
Hi
On Mon, 22 Oct 2012, Jean Pihet wrote:
> I tried the latest l-o with omap2plus defconfig on my Beagleboard B5
> (ES2.1) and could not reproduce the problem.
> I do not have the I2C error messages at boot, nor at user space start
> up. I tried to read/write the TWL RTC, successfully.
>
> Anoth
Hi,
On Tue, Oct 23, 2012 at 08:57:19PM +0530, Shubhrajyoti D wrote:
> re-factor omap_i2c_init() so that we can re-use it for resume.
> While at it also remove the bufstate variable as we write it
> in omap_i2c_resize_fifo for every transfer.
>
> Signed-off-by: Shubhrajyoti D
> ---
> Applies on F
Jean Pihet writes:
> Hi,
>
> On Sat, Oct 20, 2012 at 8:14 AM, Paul Walmsley wrote:
>> Hi Jean
>>
>> On Fri, 19 Oct 2012, Paul Walmsley wrote:
>>
>>> On Thu, 18 Oct 2012, Paul Walmsley wrote:
>>>
>>> > Here are some basic OMAP test results for Linux v3.7-rc1.
>>> > Logs and other details at
>>>
Hi,
On Tue, Oct 23, 2012 at 11:09:31AM -0700, Kevin Hilman wrote:
> From: Kevin Hilman
>
> When debounce clocks are disabled, ensure that the banks
> dbck_enable_mask is cleared also. Otherwise, context restore on
> subsequent off-mode transition will restore previous value from the
> shadow co
Kevin Hilman writes:
> +Igor
>
> Paul Walmsley writes:
>
>> Here are some basic OMAP test results for Linux v3.7-rc2.
>> Logs and other details at:
>>
>> http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/
>
> [...]
>
>> * 37xx EVM: CORE not entering dynamic off-idle
>> - Caus
From: Kevin Hilman
When debounce clocks are disabled, ensure that the banks
dbck_enable_mask is cleared also. Otherwise, context restore on
subsequent off-mode transition will restore previous value from the
shadow copies (bank->context.debounce*) leading to mismatch state
between driver state a
On Tue, Oct 23, 2012 at 11:27 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Oct 23, 2012 at 11:26:15PM +0530, Shubhrajyoti Datta wrote:
>> >> @@ -1268,23 +1271,8 @@ static int omap_i2c_runtime_resume(struct device
>> >> *dev)
>> >> {
>> >> struct omap_i2c_dev *_dev = dev_get_drvdata(dev);
>> >
Hi,
On Tue, Oct 23, 2012 at 11:26:15PM +0530, Shubhrajyoti Datta wrote:
> >> @@ -1268,23 +1271,8 @@ static int omap_i2c_runtime_resume(struct device
> >> *dev)
> >> {
> >> struct omap_i2c_dev *_dev = dev_get_drvdata(dev);
> >>
> >> - if (_dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE)
Hi,
(please don't top-post)
On Tue, Oct 23, 2012 at 07:51:22AM -1000, Mitch Bradley wrote:
> Perhaps I misunderstood what you were suggesting. I thought that, when
> you said "explicitly manage all their resources", you meant that the
> driver should know the platform-specific details about cloc
On Tue, Oct 23, 2012 at 10:48 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Oct 23, 2012 at 08:57:19PM +0530, Shubhrajyoti D wrote:
>> re-factor omap_i2c_init() so that we can re-use it for resume.
>> While at it also remove the bufstate variable as we write it
>> in omap_i2c_resize_fifo for every tra
Perhaps I misunderstood what you were suggesting. I thought that, when
you said "explicitly manage all their resources", you meant that the
driver should know the platform-specific details about clocks and power
domains. That is one possible interpretation of the word "explicit".
Now I see that
On Tue, Oct 23, 2012 at 9:39 PM, Kevin Hilman
wrote:
> Shubhrajyoti Datta writes:
[...]
>
> Could you please explain what worked and didn't work on each platforms?
>
> Also, which 3430 did you test on? If it's SDP, then it has a UART1
> console, correct?
idle mode
set autosuspend for uart
sleep
HI,
On Tue, Oct 23, 2012 at 07:02:09AM -1000, Mitch Bradley wrote:
> On 10/23/2012 12:03 AM, Felipe Balbi wrote:
> > Hi,
> >
> > I much prefer having drivers explicitly manage all their resources,
> > which would mean that pinctrl calls need to be done on probe() and, if
> > necessary, during sus
Hi,
On Tue, Oct 23, 2012 at 08:57:19PM +0530, Shubhrajyoti D wrote:
> re-factor omap_i2c_init() so that we can re-use it for resume.
> While at it also remove the bufstate variable as we write it
> in omap_i2c_resize_fifo for every transfer.
>
> Signed-off-by: Shubhrajyoti D
> ---
> Applies on F
On 10/23/2012 11:17 AM, Tomi Valkeinen wrote:
On 2012-10-23 18:42, Ricardo Neri wrote:
What registers does the audio side need to access?
It only needs access to the DMA audio data port. All other operations
that the audio driver needs are done through the omapdss audio interface.
Hmm, so
Kevin Hilman writes:
> Paul Walmsley writes:
>
>> Hi Tero,
>>
>> On Mon, 22 Oct 2012, Tero Kristo wrote:
>>
>>> When waking up from off-mode, some IP blocks are reset automatically by
>>> hardware. For this reason, software must wait until the reset has
>>> completed before attempting to access
On 10/23/2012 12:03 AM, Felipe Balbi wrote:
> Hi,
>
> I much prefer having drivers explicitly manage all their resources,
> which would mean that pinctrl calls need to be done on probe() and, if
> necessary, during suspend()/resume().
Per-driver resource management is certainly convenient when y
On 10/23/2012 4:49 AM, Jon Hunter wrote:
> Therefore, I believe it will improve search time and hence, boot time if
> we have interrupt-parent defined in each node.
I strongly suspect (based on many years of performance tuning, with
special focus on boot time) that the time difference will be com
On 2012-10-23 18:42, Ricardo Neri wrote:
>> What registers does the audio side need to access?
>
> It only needs access to the DMA audio data port. All other operations
> that the audio driver needs are done through the omapdss audio interface.
Hmm, so the audio side only needs the address of on
Hi Benoit and John,
On 10/23/2012 06:07 PM, Benoit Cousson wrote:
On 10/23/2012 05:59 PM, Jon Hunter wrote:
On 10/23/2012 10:09 AM, Benoit Cousson wrote:
On 10/23/2012 04:49 PM, Jon Hunter wrote:
Hi Seb,
On 10/23/2012 03:37 AM, Sebastien Guiriec wrote:
Add base address and interrupt line i
Shubhrajyoti Datta writes:
> On Tue, Oct 23, 2012 at 3:16 AM, Kevin Hilman
> wrote:
>> Tero Kristo writes:
>>
>>> When waking up from off-mode, some IP blocks are reset automatically by
>>> hardware. For this reason, software must wait until the reset has
>>> completed before attempting to acce
On 10/23/2012 05:59 PM, Jon Hunter wrote:
>
> On 10/23/2012 10:09 AM, Benoit Cousson wrote:
>> On 10/23/2012 04:49 PM, Jon Hunter wrote:
>>> Hi Seb,
>>>
>>> On 10/23/2012 03:37 AM, Sebastien Guiriec wrote:
Add base address and interrupt line inside Device Tree data for
OMAP5
Si
On 10/23/2012 10:09 AM, Benoit Cousson wrote:
> On 10/23/2012 04:49 PM, Jon Hunter wrote:
>> Hi Seb,
>>
>> On 10/23/2012 03:37 AM, Sebastien Guiriec wrote:
>>> Add base address and interrupt line inside Device Tree data for
>>> OMAP5
>>>
>>> Signed-off-by: Sebastien Guiriec
>>> ---
>>> arch/arm/
On 10/23/2012 04:37 AM, Tomi Valkeinen wrote:
On 2012-10-23 03:48, Ricardo Neri wrote:
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+#define HDMI_AUDIO_MEM_RESOURCE 0
+#define HDMI_AUDIO_DMA_RESOURCE 1
I don't see much point with these definitions. They are hdmi.c internal,
so the audio driver
On Tue, Oct 23, 2012 at 3:16 AM, Kevin Hilman
wrote:
> Tero Kristo writes:
>
>> When waking up from off-mode, some IP blocks are reset automatically by
>> hardware. For this reason, software must wait until the reset has
>> completed before attempting to access the IP block.
>>
>> This patch fixe
re-factor omap_i2c_init() so that we can re-use it for resume.
While at it also remove the bufstate variable as we write it
in omap_i2c_resize_fifo for every transfer.
Signed-off-by: Shubhrajyoti D
---
Applies on Felipe's series
http://www.spinics.net/lists/linux-omap/msg79995.html
Tested with T
On 10/23/2012 04:49 PM, Jon Hunter wrote:
> Hi Seb,
>
> On 10/23/2012 03:37 AM, Sebastien Guiriec wrote:
>> Add base address and interrupt line inside Device Tree data for
>> OMAP5
>>
>> Signed-off-by: Sebastien Guiriec
>> ---
>> arch/arm/boot/dts/omap5.dtsi | 16
>> 1 file ch
Hi Seb,
On 10/23/2012 03:37 AM, Sebastien Guiriec wrote:
> Add base address and interrupt line inside Device Tree data for
> OMAP5
>
> Signed-off-by: Sebastien Guiriec
> ---
> arch/arm/boot/dts/omap5.dtsi | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm/boo
On Tuesday 23 October 2012 07:58 PM, Kevin Hilman wrote:
Paul Walmsley writes:
Hi Tero,
On Mon, 22 Oct 2012, Tero Kristo wrote:
When waking up from off-mode, some IP blocks are reset automatically by
hardware. For this reason, software must wait until the reset has
completed before attempti
Paul Walmsley writes:
> Hi Tero,
>
> On Mon, 22 Oct 2012, Tero Kristo wrote:
>
>> When waking up from off-mode, some IP blocks are reset automatically by
>> hardware. For this reason, software must wait until the reset has
>> completed before attempting to access the IP block.
>>
>> This patch f
On Tue, Oct 23, 2012 at 08:24:36AM -0400, Matt Porter wrote:
> On Tue, Oct 23, 2012 at 03:15:44AM +, Paul Walmsley wrote:
> > On Mon, 22 Oct 2012, Matt Porter wrote:
> >
> > > I've mentioned this a few times in various threads...no need to use
> > > appended DTB on a current U-Boot. Some of us
On Tue, Oct 23, 2012 at 03:15:44AM +, Paul Walmsley wrote:
> On Mon, 22 Oct 2012, Matt Porter wrote:
>
> > I've mentioned this a few times in various threads...no need to use
> > appended DTB on a current U-Boot. Some of us are indeed booting this way
> > with the DTB properly passed separatel
On Tue, 23 Oct 2012 12:45:33 +0200, Linus Walleij wrote:
> Hm so I have had this idea of runtime PM core helping out
> with pins, so I could add something like
>
> pm_pins_fetch()
> pm_pins_default()
> pm_pins_idle()
> pm_pins_sleep()
>
> So if one is using the pin states defined in
> then the
Hi,
On Tue, Oct 23, 2012 at 12:45:33PM +0200, Linus Walleij wrote:
> On Tue, Oct 23, 2012 at 12:29 PM, Felipe Balbi wrote:
> > On Tue, Oct 23, 2012 at 12:29:28PM +0200, Linus Walleij wrote:
>
> >> So the biggest implementation of the notifier approach to resource
> >> handling is the SH clock th
On Tue, Oct 23, 2012 at 12:29 PM, Felipe Balbi wrote:
> On Tue, Oct 23, 2012 at 12:29:28PM +0200, Linus Walleij wrote:
>> So the biggest implementation of the notifier approach to resource
>> handling is the SH clock thing:
>> drivers/base/power/clock_ops.c
>
> that's different right ? It's just
Hi,
On Tue, Oct 23, 2012 at 12:29:28PM +0200, Linus Walleij wrote:
> On Tue, Oct 23, 2012 at 12:23 PM, Thomas Petazzoni
> wrote:
> >
> > On Tue, 23 Oct 2012 13:03:33 +0300, Felipe Balbi wrote:
> >
> >> > But it appears that shmobile prefer to get all resources using
> >> > bus notifiers.
> >> >
>
On Tue, Oct 23, 2012 at 12:23 PM, Thomas Petazzoni
wrote:
>
> On Tue, 23 Oct 2012 13:03:33 +0300, Felipe Balbi wrote:
>
>> > But it appears that shmobile prefer to get all resources using
>> > bus notifiers.
>> >
>> > So we need to form some kind of consensus ... or live with
>> > the fact that di
On Tue, 23 Oct 2012 13:03:33 +0300, Felipe Balbi wrote:
> > But it appears that shmobile prefer to get all resources using
> > bus notifiers.
> >
> > So we need to form some kind of consensus ... or live with
> > the fact that different systems do it different ways. Which will
> > explode the da
On Tue, Oct 16, 2012 at 00:18:30, Peter Korsgaard wrote:
> > Philip, Avinash writes:
>
> > Add support for BCH ECC scheme to gpmc driver and also enabling multi
> > sector read/write. This helps in doing single shot NAND page read and
> > write.
>
> > ECC engine configurations
> > BCH 4
On Tue, Oct 16, 2012 at 01:10:47, Peter Korsgaard wrote:
> > Philip, Avinash writes:
>
> > Platforms containing the ELM module can be used to correct errors
> > reported by BCH 4, 8 & 16 bit ECC scheme. For now only 4 & 8 bit
> > support is added.
>
> This sounds odd to me. What about som
On Tue, Oct 16, 2012 at 00:26:40, Peter Korsgaard wrote:
> > Philip, Avinash writes:
>
> > Update number of errors using nand ecc strength.
> > Also add macro definitions BCH8_ERROR_MAX & BCH4_ERROR_MAX
>
> > Signed-off-by: Philip, Avinash
> > ---
> > :100644 100644 5b31386... af511a9.
On Fri, Oct 19, 2012 at 11:46:30, Richard Cochran wrote:
> On Fri, Oct 19, 2012 at 02:18:29AM +0530, Vaibhav Hiremath wrote:
> >
> > Another important point is, this driver is also required and used for
> > Davinci family of devices (arch/mach/mach-davinci/).
>
> That is really beside the point.
On Mon, Oct 22, 2012 at 1:54 PM, Felipe Balbi wrote:
> The scheduler imposes a requirement to sched_clock()
> which is to stop the clock during suspend, if we don't
> do that IRQ threads will be rescheduled in the future
> which might cause transfers to timeout depending on
> how driver is writte
On Fri, Oct 12, 2012 at 04:54:34PM +0100, Russell King - ARM Linux wrote:
> For those who don't bother looking at my kautobuild boot tests on the OMAP
> boards I have, here's the errors which get spat out at boot time. Note
> that some of these I've reported in the past, and one of them is missing
Hi,
On Tue, Oct 23, 2012 at 12:04:01PM +0200, Linus Walleij wrote:
> On Tue, Oct 23, 2012 at 11:35 AM, Benoit Cousson wrote:
> > On 10/23/2012 11:13 AM, Linus Walleij wrote:
>
> >> So Sourav, please tell us a bit about your plans for this
> >> and other drivers!
> >
> > Yeah, this idea is to han
On Tue, Oct 23, 2012 at 11:35 AM, Benoit Cousson wrote:
> On 10/23/2012 11:13 AM, Linus Walleij wrote:
>> So Sourav, please tell us a bit about your plans for this
>> and other drivers!
>
> Yeah, this idea is to handle pinctrl from all the drivers, and
> potentially change the mode during suspend
On 10/23/12 09:51, Ohad Ben-Cohen wrote:
> On Tue, Oct 23, 2012 at 9:37 AM, Igor Grinberg
> wrote:
>>> + ret = wl12xx_set_platform_data(wlan_data);
>>> + /* bail out silently in case wl12xx isn't configured */
>>> + if (ret == -ENOSYS)
>>> + return ret;
>>
>> Since we ha
On 2012-10-23 03:48, Ricardo Neri wrote:
>>> +#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
>>> +#define HDMI_AUDIO_MEM_RESOURCE 0
>>> +#define HDMI_AUDIO_DMA_RESOURCE 1
>>
>> I don't see much point with these definitions. They are hdmi.c internal,
>> so the audio driver can't use them, and so they are
Hi Linus,
On 10/23/2012 11:13 AM, Linus Walleij wrote:
> On Mon, Oct 22, 2012 at 5:50 PM, Dmitry Torokhov
> wrote:
>> Hi Sourav,
>>
>> On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
>>> Adapt keypad to use pinctrl framework.
>>>
>>> Tested on omap4430 sdp with 3.7-rc1 kernel.
>>
>
On Mon, Oct 22, 2012 at 09:47:06AM -0700, Kevin Hilman wrote:
> Peter Zijlstra writes:
>
> > On Fri, 2012-10-19 at 16:54 -0700, Kevin Hilman wrote:
> >
> >> So I did the same thing for my ARM SoC, and it definitley stops the RT
> >> throttling.
> >>
> >> However, it has the undesriable (IMO) s
Hi Dimitry,
On 10/22/2012 05:50 PM, Dmitry Torokhov wrote:
> Hi Sourav,
>
> On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
>> Adapt keypad to use pinctrl framework.
>>
>> Tested on omap4430 sdp with 3.7-rc1 kernel.
>
> I do not see anything in the driver that would directly use p
On Mon, Oct 22, 2012 at 5:50 PM, Dmitry Torokhov
wrote:
> Hi Sourav,
>
> On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
>> Adapt keypad to use pinctrl framework.
>>
>> Tested on omap4430 sdp with 3.7-rc1 kernel.
>
> I do not see anything in the driver that would directly use pinctr
Add base address and interrupt line inside Device Tree data for
OMAP5.
Signed-off-by: Sebastien Guiriec
Reviewed-by: Shubhrajyoti D
---
arch/arm/boot/dts/omap5.dtsi | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/bo
Add base address and interrupt line inside Device Tree data for
OMAP5
Signed-off-by: Sebastien Guiriec
---
arch/arm/boot/dts/omap5.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 42c78be..9e39f9f 10064
Add base address and interrupt line inside Device Tree data for
OMAP5.
Signed-off-by: Sebastien Guiriec
---
arch/arm/boot/dts/omap5.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 413df94..b643cd3 100644
---
Add base address and interrupt line inside Device Tree data for
OMAP5
Signed-off-by: Sebastien Guiriec
Reviewed-by: Shubhrajyoti D
---
arch/arm/boot/dts/omap5.dtsi | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/
Since kernel 3.7 the DTS data are not overwriten by hwmod data we can add the
address space
and interrupt line description inside dtsi file for OMAP5. This serie is
updating the
current OMAP5 IP with missing entry.
It has been tested on OMAP5 with 3.7-audio-display feature tree.
- MMC is probing
Hi Paul,
> When you have the opportunity, could you take a look at this patch, and
> the subsequent patch 6/7, and ack them if you're okay with them?
Signed them off, Acked-by would probably have been better :-).
> We'd like to merge thse as part of a larger cleanup series through the
> arm-so
Hi Paul,
On Tue, 2012-10-23 at 07:47 +, Paul Walmsley wrote:
> Hi Tero,
>
> On Mon, 22 Oct 2012, Tero Kristo wrote:
>
> > When waking up from off-mode, some IP blocks are reset automatically by
> > hardware. For this reason, software must wait until the reset has
> > completed before attempt
Hi Paul,
> Previously the OMAP watchdog driver used a non-standard way to report
> the chip reset source via the GETBOOTSTATUS ioctl. This patch
> converts the driver to use the standard WDIOF_* flags for this
> purpose.
>
> This patch may break existing userspace code that uses the existing
> n
Hi Paul,
> The OMAP watchdog timer driver directly calls a function exported by
> code in arch/arm/mach-omap2. This is not good; it tightly couples
> this driver to the mach-omap2 integration code. Instead, add a
> temporary platform_data function pointer to abstract this function
> call. A sub
On Tue, Oct 23, 2012 at 9:37 AM, Igor Grinberg wrote:
>> + ret = wl12xx_set_platform_data(wlan_data);
>> + /* bail out silently in case wl12xx isn't configured */
>> + if (ret == -ENOSYS)
>> + return ret;
>
> Since we have the function ifdef'ed, I don't think we need
> the
Hi Tero,
On Mon, 22 Oct 2012, Tero Kristo wrote:
> When waking up from off-mode, some IP blocks are reset automatically by
> hardware. For this reason, software must wait until the reset has
> completed before attempting to access the IP block.
>
> This patch fixes for example the bug introduced
On 10/21/12 16:54, Ohad Ben-Cohen wrote:
> On Fri, Oct 19, 2012 at 7:07 PM, Tony Lindgren wrote:
> ...
>> We could optimize away a minimal amount of code for many configurations
>> with the ifdef? :)
>
> Sure, here goes (compile tested only):
>
>>From 6b82365da2c04986e647d06c285197efece7cb34 Mon
100 matches
Mail list logo