Update i2c trivial-devices list by adding the description for
ti,tmp275 temperature sensor and taos,tsl2550 ambient light
sensor.
Signed-off-by: AnilKumar Ch
---
.../devicetree/bindings/i2c/trivial-devices.txt|2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/b
On Fri, Oct 19, 2012 at 12:10:51, AnilKumar, Chimata wrote:
> On Wed, Oct 17, 2012 at 15:48:22, Koen Kooi wrote:
> > Hi,
> >
> > I'm currently building 3.7rc1 kernels meant to run on beagleboards (omap3),
> > pandaboards (omap4) and beaglebones (am335x). At the moment I'm only
> > testing it on
On Wed, Oct 17, 2012 at 15:48:22, Koen Kooi wrote:
> Hi,
>
> I'm currently building 3.7rc1 kernels meant to run on beagleboards (omap3),
> pandaboards (omap4) and beaglebones (am335x). At the moment I'm only testing
> it on beaglebone and I noticed a problem with the different cpufreq drivers
>
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. If the code isn't ready yet, then
don't merge it.
When I asked about
On Thu, Oct 18, 2012 at 07:27:22PM +, Paul Walmsley wrote:
> I wrote that we'll schedule the SoC integration patch for sending upstream
> for 3.8. This does not necessarily mean that our upstreams will take it,
> or that it will result in a working CPSW.
Forgive me for barking up the wrong
Hi Arnd & Olof,
Here's the first set of omap plat header removal for v3.8 merge
window. I have at least one more related set coming, but I wanted
to get these into linux next before driver patches add more
things for me to chase down and fix.
Oh, forgot to mention in the tag that the increase in
* Mark Brown [121018 18:29]:
> On Thu, Oct 18, 2012 at 03:52:37PM -0700, Tony Lindgren wrote:
> > * Tony Lindgren [121017 13:01]:
>
> > > Is it OK for me to merge in your ASoC for-3.7 branch at commit
> > > 68214d99 (ASoC: omap-mcpdm: Remove OMAP revision check) also
> > > into my omap cleanup b
From: Felipe Balbi
In order to make single zImage work for ARM architecture,
we need to make sure we don't depend on private headers.
Move USB platform_data to
and add a minimal drivers/mfd/usb-omap.h.
Cc: Samuel Ortiz
Cc: Alan Stern
Cc: Greg Kroah-Hartman
Cc: Partha Basak
Cc: Keshava Mune
Let's move what we can from plat/usb.h to the local usb.h
for ARM common zImage support.
This is needed so we can remove plat/usb.h for ARM common
zImage support.
Cc: Felipe Balbi
Cc: Samuel Ortiz
Cc: Alan Stern
Cc: Greg Kroah-Hartman
Cc: Partha Basak
Cc: Keshava Munegowda
Cc: linux-...@vge
Hi all,
Here are two patches against v3.7-rc1 to remove
plat/usb.h.
Once people are happy with these, I'll apply these
into omap-for-v3.8/cleanup-headers-usb branch so
usb and mfd trees can also pull these in if needed.
Regards,
Tony
---
Felipe Balbi (1):
ARM: OMAP: move OMAP USB platfo
* Felipe Balbi [121017 22:56]:
> Hi,
>
> On Wed, Oct 17, 2012 at 01:34:04PM -0700, Tony Lindgren wrote:
> > * Felipe Balbi [121017 08:54]:
> > > In order to make single zImage work for ARM architecture,
> > > we need to make sure we don't depend on private headers.
> > >
> > > Move USB platform
On Thu, Oct 18, 2012 at 03:52:37PM -0700, Tony Lindgren wrote:
> * Tony Lindgren [121017 13:01]:
> > Is it OK for me to merge in your ASoC for-3.7 branch at commit
> > 68214d99 (ASoC: omap-mcpdm: Remove OMAP revision check) also
> > into my omap cleanup branch for v3.8?
> > I need that to avoid
Omar,
* Omar Ramirez Luna [121017 16:54]:
> On 16 October 2012 12:22, Tony Lindgren wrote:
>
> > These will need to be rebased on omap-for-v3.8/cleanup-headers-iommu
> > when I have that pushed out as that removes plat/*iommu*.h files.
>
> Ok, will wait and rebase on top of it.
Thanks, the rel
On Fri, Oct 19, 2012 at 12:33:35AM +0100, Russell King - ARM Linux wrote:
> On Thu, Oct 18, 2012 at 04:24:05PM -0700, Mark A. Greer wrote:
> > On Thu, Oct 18, 2012 at 11:55:40PM +0100, Russell King - ARM Linux wrote:
> > > On Thu, Oct 18, 2012 at 03:20:46PM -0700, Mark A. Greer wrote:
> > > > This
On Thu, Oct 18, 2012 at 04:24:05PM -0700, Mark A. Greer wrote:
> On Thu, Oct 18, 2012 at 11:55:40PM +0100, Russell King - ARM Linux wrote:
> > On Thu, Oct 18, 2012 at 03:20:46PM -0700, Mark A. Greer wrote:
> > > This patch seems fairly stable but I've only tested omap-sham (crypto)
> > > and omap_h
On Thu, Oct 18, 2012 at 11:55:40PM +0100, Russell King - ARM Linux wrote:
> On Thu, Oct 18, 2012 at 03:20:46PM -0700, Mark A. Greer wrote:
> > This patch seems fairly stable but I've only tested omap-sham (crypto)
> > and omap_hsmmc (mmc) on an am37x EVM. I also enabled burst mode but
> > that mad
On Thu, Oct 18, 2012 at 03:20:46PM -0700, Mark A. Greer wrote:
> This patch seems fairly stable but I've only tested omap-sham (crypto)
> and omap_hsmmc (mmc) on an am37x EVM. I also enabled burst mode but
> that made the system unstable when exercising either omap-sham or
> omap_hsmmc. I'm unawa
* Tony Lindgren [121017 13:01]:
> Hi Mark,
>
> * Peter Ujfalusi [121004 01:27]:
> > Hello Mark, Tony,
> >
> > Change since v1:
> > - Fixed the second patch to keep the omap_mcpdm_open_stream() - after a
> > coffee
> >
> > The mcpdm driver no longer needs to include any plat/*.h file, clearing
On Fri, 19 Oct 2012, Vaibhav Hiremath wrote:
> 2. There is HW bug as far as idle (in turn ocp reset) is concerned, and
> needs special handling for this. I already have patch for this, which I
> will submit it to the list.
>
> http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;
On Thu, Oct 18, 2012 at 03:20:46PM -0700, Mark A. Greer wrote:
> This patch seems fairly stable but I've only tested omap-sham (crypto)
> and omap_hsmmc (mmc) on an am37x EVM. I also enabled burst mode but
> that made the system unstable when exercising either omap-sham or
> omap_hsmmc. I'm unaw
Enable DMA prefetching by setting the 'OMAP_DMA_DST_SYNC_PREFETCH'
flag whenever there is a destination synchronized DMA transfer.
Prefetching is not allowed on source synchronized DMA transfers.
Enabling prefetch significantly improves DMA performance.
For example, running 'modprobe tcrypt sec=2
* Mauro Carvalho Chehab [121018 13:58]:
> Tony,
>
> Em Thu, 18 Oct 2012 13:28:42 -0700
> Tony Lindgren escreveu:
>
> > Looks like the iommu framework does not have generic functions
> > exported for all the needs yet. The hardware specific functions
> > are defined in files like intel-iommu.h a
Felipe Balbi writes:
[...]
> ps: I'll continue reading the code and further test my series to see
> if I can understand what you say here.
OK. And please get it working in cases where drivers are using I2C in
their suspend/resume (and even late/early) paths, and also where device
runtime PM is
Tony,
Em Thu, 18 Oct 2012 13:28:42 -0700
Tony Lindgren escreveu:
> Looks like the iommu framework does not have generic functions
> exported for all the needs yet. The hardware specific functions
> are defined in files like intel-iommu.h and amd-iommu.h. Follow
> the same standard for omap-iommu
On 10/19/2012 12:14 AM, Richard Cochran wrote:
> On Thu, Oct 18, 2012 at 03:46:15AM +, Paul Walmsley wrote:
>>
>> Probably the driver was submitted before any SoC integration support was
>> available. Grepping for 'cpsw' under arch/ turns up only AM33xx. AM335x
>> didn't have device enume
On 10/17/2012 11:43 PM, Richard Cochran wrote:
> Paul,
>
> Would you please take this bugfix for 3.7-rc2? The suggestion to mail
> you came from Toni Lindgren. The context where it came from is here:
>
> http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html
>
> Thanks,
Felipe Balbi writes:
[...]
> if the device implements none of the suspend methods, then you
> shouldn't suspend it at all, because you'd be masking a bug in the
> driver, IMHO.
OK, let's start over here, because here's the fundamental difference. I
don't think missing suspend methods means a b
* Tony Lindgren [121018 09:27]:
> * Laurent Pinchart [121018 06:45]:
> > Hi,
> >
> > On Monday 15 October 2012 17:36:40 Tony Lindgren wrote:
> > > From: Ido Yariv
> > >
> > > Move iommu/iovmm headers from plat/ to platform_data/ as part of the
> > > single zImage work.
> >
> > Is that really
From: Ido Yariv
Since iommu is not supported on OMAP1 and will not likely to ever be
supported, merge plat/iommu2.h into iommu.h so only one file would have
to move to platform_data/ as part of the single zImage effort.
Cc: Joerg Roedel
Cc: Ohad Ben-Cohen
Cc: Laurent Pinchart
Cc: Mauro Carval
Move iommu/iovmm headers from plat/ to platform_data/ as part of the
single zImage work.
Partially based on an earlier version by Ido Yariv .
Cc: Joerg Roedel
Cc: Ohad Ben-Cohen
Cc: Ido Yariv
Cc: Laurent Pinchart
Cc: Mauro Carvalho Chehab
Cc: Omar Ramirez Luna
Acked-by: Mauro Carvalho Cheha
This file should not be in arch/arm. Move it to drivers/iommu
to allow making most of the header local to drivers/iommu.
This is needed as we are removing plat and mach includes
from drivers for ARM common zImage support.
Cc: Joerg Roedel
Cc: Ohad Ben-Cohen
Cc: Ido Yariv
Cc: Laurent Pinchart
From: Ido Yariv
Move some of the definitions in omap-iommu.h that can be made local to
either drivers/iommu.
Cc: Joerg Roedel
Cc: Ohad Ben-Cohen
Cc: Laurent Pinchart
Cc: Mauro Carvalho Chehab
Cc: Omar Ramirez Luna
Signed-off-by: Ido Yariv
[t...@atomide.com: updated for header changes in th
Looks like the iommu framework does not have generic functions
exported for all the needs yet. The hardware specific functions
are defined in files like intel-iommu.h and amd-iommu.h. Follow
the same standard for omap-iommu.h.
This is needed because we are removing plat and mach includes
for ARM c
From: Ido Yariv
The iopgtable header file is only used by the iommu & iovmm drivers, so
move it to drivers/iommu/, as part of the single zImage effort.
Cc: Joerg Roedel
Cc: Ohad Ben-Cohen
Cc: Laurent Pinchart
Cc: Mauro Carvalho Chehab
Cc: Omar Ramirez Luna
Signed-off-by: Ido Yariv
[t...@at
Hi all,
Here's this one again fixed with the issues Laurent noticed.
Regards,
Tony
---
Ido Yariv (3):
ARM: OMAP: Merge iommu2.h into iommu.h
ARM: OMAP2+: Move iopgtable header to drivers/iommu/
ARM: OMAP2+: Make some definitions local
Tony Lindgren (3):
ARM: OMAP2+: Mo
Hi,
On Thu, Oct 18, 2012 at 11:42:33AM -0700, Kevin Hilman wrote:
> >> Again, this is required because system suspend disables runtime PM
> >> transitions at a certain point, if the device is used after that point,
> >> there is *no other way* for the driver to properly manage the idle
> >> transi
On Thu, 18 Oct 2012, Richard Cochran wrote:
> You say it will be working in 3.8, after 3.7 comes out, in about
> December.
I wrote that we'll schedule the SoC integration patch for sending upstream
for 3.8. This does not necessarily mean that our upstreams will take it,
or that it will result
On 10/18/2012 01:39 PM, Hiremath, Vaibhav wrote:
> On Fri, Oct 19, 2012 at 00:00:31, Hunter, Jon wrote:
>>
>> On 10/18/2012 01:04 PM, Hiremath, Vaibhav wrote:
>>> On Thu, Oct 18, 2012 at 22:12:07, Hunter, Jon wrote:
>>
>> ...
>>
Yes, but do you also see the bug that is hiding in gpmc_mem_init
On Thu, Oct 18, 2012 at 03:46:15AM +, Paul Walmsley wrote:
>
> Probably the driver was submitted before any SoC integration support was
> available. Grepping for 'cpsw' under arch/ turns up only AM33xx. AM335x
> didn't have device enumeration support in the mainline kernel until 3.7,
> vi
On Thu, 18 Oct 2012, Richard Cochran wrote:
> I *do* mind if y'all go merging all kinds of code that has never been
> tested. Those who submit and their reviewers should ensure that the
> code is actually working. Before buying hardware or starting projects,
> I often check what is in mainline. I
Felipe Balbi writes:
> Hi,
>
> On Thu, Oct 18, 2012 at 10:42:37AM -0700, Kevin Hilman wrote:
>> Felipe Balbi writes:
>>
>> > Hi,
>> >
>> > On Thu, Oct 18, 2012 at 09:34:15AM -0700, Kevin Hilman wrote:
>> >> Felipe Balbi writes:
>> >>
>> >> > current implementation doesn't take care about
>> >
On Fri, Oct 19, 2012 at 00:00:31, Hunter, Jon wrote:
>
> On 10/18/2012 01:04 PM, Hiremath, Vaibhav wrote:
> > On Thu, Oct 18, 2012 at 22:12:07, Hunter, Jon wrote:
>
> ...
>
> >> Yes, but do you also see the bug that is hiding in gpmc_mem_init()?
> >>
> >> My point is to highlight this and not hi
On 10/18/2012 01:04 PM, Hiremath, Vaibhav wrote:
> On Thu, Oct 18, 2012 at 22:12:07, Hunter, Jon wrote:
...
>> Yes, but do you also see the bug that is hiding in gpmc_mem_init()?
>>
>> My point is to highlight this and not hide it, so that we can fix it
>> now. Otherwise if we wait until we enab
On Thu, Oct 18, 2012 at 03:46:15AM +, Paul Walmsley wrote:
>
> It doesn't necessarily mean that the driver is usable in that kernel
> release.
Well, it should. We have staging for half-baked stuff.
> Either way, the patch is likely to make it into the mainline kernel.
> It's just that it
On Thu, Oct 18, 2012 at 22:12:07, Hunter, Jon wrote:
>
> On 10/18/2012 11:16 AM, Hiremath, Vaibhav wrote:
> > On Wed, Oct 17, 2012 at 01:17:56, Hunter, Jon wrote:
> >>
> >> On 10/15/2012 02:16 PM, Richard Cochran wrote:
> >>> From: hvaib...@ti.com
> >>>
> >>> With recent changes in omap gpmc driv
Hi,
On Thu, Oct 18, 2012 at 10:42:37AM -0700, Kevin Hilman wrote:
> Felipe Balbi writes:
>
> > Hi,
> >
> > On Thu, Oct 18, 2012 at 09:34:15AM -0700, Kevin Hilman wrote:
> >> Felipe Balbi writes:
> >>
> >> > current implementation doesn't take care about
> >> > drivers which don't provide *_noi
Quoting Grygorii Strashko (2012-10-18 09:38:17)
> Remove OMAP443x and OMAP446x specific clocks from omap44xx_clks
> array and add corresponding set of clocks per each SoC:
> - struct omap_clk omap44xx_clks[]; - common clocks set for all OMAP4
> - struct omap_clk omap443x_clks[]; - specific clocks
Felipe Balbi writes:
> Hi,
>
> On Thu, Oct 18, 2012 at 09:34:15AM -0700, Kevin Hilman wrote:
>> Felipe Balbi writes:
>>
>> > current implementation doesn't take care about
>> > drivers which don't provide *_noirq methods
>>
>> The generic ops handle this. See below.
>>
>> > and we could fal
Hi,
On Thu, Oct 18, 2012 at 07:59:56AM -0700, Sarah Sharp wrote:
> On Tue, Oct 16, 2012 at 12:59:33PM +0300, Felipe Balbi wrote:
> > Hi,
> >
> > > +#ifdef CONFIG_PM_SLEEP
> > > +static int xhci_plat_suspend(struct device *dev)
> > > +{
> > > + struct usb_hcd *hcd= dev_get_drvdata(dev);
> > >
Hi,
On Thu, Oct 18, 2012 at 12:44:50PM -0400, Alan Stern wrote:
> On Thu, 18 Oct 2012, Sarah Sharp wrote:
>
> > For system suspend while the DW3 hardware is in host mode, doesn't the
> > USB core prevent drivers from submitting URBs just before the
> > PCI/platform suspend is called? Alan?
>
>
Hi,
On Thu, Oct 18, 2012 at 08:06:40PM +0300, Felipe Balbi wrote:
> Hi,
>
> On Thu, Oct 18, 2012 at 10:07:31AM -0700, Kevin Hilman wrote:
> > Felipe Balbi writes:
> >
> > > current omap_device PM implementation defines
> > > omap-specific *_noirq methods but uses the
> > > generic versions for
On Thu, Oct 18, 2012 at 10:10:06AM -0700, Kevin Hilman wrote:
> Felipe Balbi writes:
>
> > OMAP I2C driver will re-enable IRQs right after
> > masking them during suspend.
> >
> > That's not what we want. We want to keep IRQs
> > masked until our resume method is called.
> >
> > Signed-off-by: Fe
Hi,
On Thu, Oct 18, 2012 at 10:07:31AM -0700, Kevin Hilman wrote:
> Felipe Balbi writes:
>
> > current omap_device PM implementation defines
> > omap-specific *_noirq methods but uses the
> > generic versions for all other PM methods.
> >
> > As it turns out, if a device decides to implement
> >
Hi,
On Thu, Oct 18, 2012 at 10:01:00AM -0700, Kevin Hilman wrote:
> Felipe Balbi writes:
>
> > device drivers should be smart enough to provide
> > ->suspend/->resume callbacks when needed and they
> > should take care of doing whatever needs to be
> > done in order to allow a device to be suspe
Felipe Balbi writes:
> OMAP I2C driver will re-enable IRQs right after
> masking them during suspend.
>
> That's not what we want. We want to keep IRQs
> masked until our resume method is called.
>
> Signed-off-by: Felipe Balbi
> ---
> drivers/i2c/busses/i2c-omap.c | 10 ++
> 1 file cha
Felipe Balbi writes:
> current omap_device PM implementation defines
> omap-specific *_noirq methods but uses the
> generic versions for all other PM methods.
>
> As it turns out, if a device decides to implement
> non-runtime PM callbacks, we might fall into a
> situation where the hwmod is stil
Hi,
On Thu, Oct 18, 2012 at 09:34:15AM -0700, Kevin Hilman wrote:
> Felipe Balbi writes:
>
> > current implementation doesn't take care about
> > drivers which don't provide *_noirq methods
>
> The generic ops handle this. See below.
>
> > and we could fall into a situation where we would su
Felipe Balbi writes:
> device drivers should be smart enough to provide
> ->suspend/->resume callbacks when needed and they
> should take care of doing whatever needs to be
> done in order to allow a device to be suspended.
>
> Calling pm_runtime_* from system suspend isn't
> the right way to ach
Hi Igor,
On Wed, Oct 17, 2012 at 2:43 PM, Igor Grinberg wrote:
> You are adding declarations inside the common-board-devices.h,
> but the implementation inside the devices.c.
> I can see that devices.c has only on-soc devices in it.
> So, I would expect to have the wl12xx_board_init() function im
On Thu, 18 Oct 2012, Sarah Sharp wrote:
> For system suspend while the DW3 hardware is in host mode, doesn't the
> USB core prevent drivers from submitting URBs just before the
> PCI/platform suspend is called? Alan?
Sure it does.
Alan Stern
--
To unsubscribe from this list: send the line "uns
On 10/18/2012 11:16 AM, Hiremath, Vaibhav wrote:
> On Wed, Oct 17, 2012 at 01:17:56, Hunter, Jon wrote:
>>
>> On 10/15/2012 02:16 PM, Richard Cochran wrote:
>>> From: hvaib...@ti.com
>>>
>>> With recent changes in omap gpmc driver code, in case of DT
>>> boot mode, where bootloader does not confi
Remove OMAP443x and OMAP446x specific clocks from omap44xx_clks
array and add corresponding set of clocks per each SoC:
- struct omap_clk omap44xx_clks[]; - common clocks set for all OMAP4
- struct omap_clk omap443x_clks[]; - specific clocks set for OMAP443x
- struct omap_clk omap446x_clks[]; -
Now the cpu_mask is used to differentiate clocks per each OMAP
platform, SoC version or revision. Such approach has few disadvantages:
- the specific CK_XXX flag need to be added and maintained for each OMAP
SoC;
- it's difficult to update clock tree data in case of differences
between OMAP SoC rev
Currently we use CK_446X etc to differentiate which clk needs to be registered
on which SoC.
The following patch series removes that requirement, instead SoC and SoC
variants are
detected on the fly and only the required clocks are registered in the system.
This will help to remove the CK_XYZ mac
On Thu, Oct 18, 2012 at 21:49:44, Daniel Mack wrote:
> On 18.10.2012 18:12, Vaibhav Hiremath wrote:
> >
> >
> > On 10/18/2012 9:23 PM, Daniel Mack wrote:
> >> This is needed as preparation for platforms where using pm runtime usage
> >> is mandatory.
> >>
> >> Signed-off-by: Daniel Mack
> >
> >
Felipe Balbi writes:
> current implementation doesn't take care about
> drivers which don't provide *_noirq methods
The generic ops handle this. See below.
> and we could fall into a situation where we would suspend/resume
> devices even though they haven't asked for it.
The following explan
* Laurent Pinchart [121018 06:45]:
> Hi,
>
> On Monday 15 October 2012 17:36:40 Tony Lindgren wrote:
> > From: Ido Yariv
> >
> > Move iommu/iovmm headers from plat/ to platform_data/ as part of the
> > single zImage work.
>
> Is that really where those headers belong ? iommu-omap.h contains fa
On 18.10.2012 18:12, Vaibhav Hiremath wrote:
>
>
> On 10/18/2012 9:23 PM, Daniel Mack wrote:
>> This is needed as preparation for platforms where using pm runtime usage
>> is mandatory.
>>
>> Signed-off-by: Daniel Mack
>
> It looks like, you just duplicated effort here.
> RTC patches have been
On Wed, Oct 17, 2012 at 01:17:56, Hunter, Jon wrote:
>
> On 10/15/2012 02:16 PM, Richard Cochran wrote:
> > From: hvaib...@ti.com
> >
> > With recent changes in omap gpmc driver code, in case of DT
> > boot mode, where bootloader does not configure gpmc cs space
> > will result into kernel BUG()
Hi Gururaja,
On 10/18/2012 12:31 AM, Hebbar, Gururaja wrote:
> Jon,
>
> On Thu, Oct 18, 2012 at 02:42:01, Hunter, Jon wrote:
[snip]
>>> My doubt/questions are
>>> 1. Why should debounce registers be updated only when it's accessed
>>> previously?
>>
>> If debounce is not being used by any of t
On 10/18/2012 9:23 PM, Daniel Mack wrote:
> This is needed as preparation for platforms where using pm runtime usage
> is mandatory.
>
> Signed-off-by: Daniel Mack
It looks like, you just duplicated effort here.
RTC patches have been already submitted quite some time back for AM33xx,
probably
This adds bindings for the OMAP RTC driver.
There are currently two compatible string it matches, "ti,omap-rtc" and
"ti,am33xx-rtc". This is done because the AM33xx needs extra registers
to be written in order to unlock the register set.
Also, the OMAP_RTC_OSC_REG can be set up via DT, in particu
This is needed as preparation for platforms where using pm runtime usage
is mandatory.
Signed-off-by: Daniel Mack
---
drivers/rtc/rtc-omap.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 0b614e3..baa876e 100644
--- a/drivers
The same IP is found on AM33xx as well, so let users select it.
Signed-off-by: Daniel Mack
---
drivers/rtc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 19c03ab..5cb5be7 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/r
* Laurent Pinchart [121018 06:46]:
> Hi Tony,
>
> On Tuesday 16 October 2012 16:51:40 Laurent Pinchart wrote:
> > Hi Sakari,
> >
> > Thanks for the patches.
> >
> > For the whole series,
> >
> > Acked-by: Laurent Pinchart
> >
> > Tony, do you want to take patch 1/3 in your tree, or can I pus
On Tue, Oct 16, 2012 at 04:53:28PM +0300, Felipe Balbi wrote:
> Hi,
>
> On Tue, Oct 16, 2012 at 05:10:39PM +0530, Vikas Sajjan wrote:
> > Hi Felipe,
...
> did you have a transfer going through when you suspended ? If you
> didn't, then you haven't stressed well enough.
>
> > 2) We tested by runn
On Tue, Oct 16, 2012 at 12:59:33PM +0300, Felipe Balbi wrote:
> Hi,
>
> > +#ifdef CONFIG_PM_SLEEP
> > +static int xhci_plat_suspend(struct device *dev)
> > +{
> > + struct usb_hcd *hcd= dev_get_drvdata(dev);
> > + struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> > +
> > + /* Make sure that
On Thu, Oct 18, 2012 at 05:39:59PM +0300, Tero Kristo wrote:
> On Thu, 2012-10-18 at 16:53 +0300, Felipe Balbi wrote:
> > hi,
> >
> > On Thu, Oct 18, 2012 at 03:18:04PM +0300, Tero Kristo wrote:
> > > > > +static int __init omap4430_phy_power_down(void)
> > > > > +{
> > > > > + void __iomem *c
On Thu, 18 Oct 2012, Benoit Cousson wrote:
> From: Miguel Vadillo
>
> Since CAM domain (ISS) has no module wake-up dependency
> with any other clock domain of the device and the dynamic
> dependency from L3_main_2 is always disabled, the domain
> needs to be in force wakeup in order to be able t
On Thu, 2012-10-18 at 16:53 +0300, Felipe Balbi wrote:
> hi,
>
> On Thu, Oct 18, 2012 at 03:18:04PM +0300, Tero Kristo wrote:
> > > > +static int __init omap4430_phy_power_down(void)
> > > > +{
> > > > + void __iomem *ctrl_base;
> > > > +
> > > > + if (!cpu_is_omap44xx())
> > > > +
On 10/18/2012 09:23 AM, Benoit Cousson wrote:
> Hi Jon,
>
> This looks good to me, I just have a minor nit comment.
>
> On 10/17/2012 08:33 PM, Jon Hunter wrote:
>> Adds the counter-32k timers nodes present in OMAP2/3/4 devices and
>> device-tree binding documentation for OMAP counter-32k.
>>
>>
Hi Jon,
This looks good to me, I just have a minor nit comment.
On 10/17/2012 08:33 PM, Jon Hunter wrote:
> Adds the counter-32k timers nodes present in OMAP2/3/4 devices and
> device-tree binding documentation for OMAP counter-32k.
>
> Signed-off-by: Jon Hunter
> ---
> .../devicetree/bindings
hi,
On Thu, Oct 18, 2012 at 03:18:04PM +0300, Tero Kristo wrote:
> > > +static int __init omap4430_phy_power_down(void)
> > > +{
> > > + void __iomem *ctrl_base;
> > > +
> > > + if (!cpu_is_omap44xx())
> > > + return 0;
> > > +
> > > + ctrl_base = ioremap(OMAP443X_SCM_BASE, SZ_1K);
> > > +
Hi Tony,
On Tuesday 16 October 2012 16:51:40 Laurent Pinchart wrote:
> Hi Sakari,
>
> Thanks for the patches.
>
> For the whole series,
>
> Acked-by: Laurent Pinchart
>
> Tony, do you want to take patch 1/3 in your tree, or can I push the whole
> series through mine ?
Ping ?
> On Sunday 14
Hi,
On Monday 15 October 2012 17:36:40 Tony Lindgren wrote:
> From: Ido Yariv
>
> Move iommu/iovmm headers from plat/ to platform_data/ as part of the
> single zImage work.
Is that really where those headers belong ? iommu-omap.h contains far more
than platform data, and iovmm-omap.h contains
From: Miguel Vadillo
Since CAM domain (ISS) has no module wake-up dependency
with any other clock domain of the device and the dynamic
dependency from L3_main_2 is always disabled, the domain
needs to be in force wakeup in order to be able to access
it for configure (sysconfig) it or use it.
Als
Adds support for parsing the TI EDMA DT data into the required
EDMA private API platform data.
Calls runtime PM API only in the DT case in order to unidle the
associated hwmods on AM33XX.
Signed-off-by: Matt Porter
---
arch/arm/common/edma.c | 255 +
Adds support for the per-EDMA channel event mux. This is required
for any peripherals using DMA crossbar mapped events.
Signed-off-by: Matt Porter
---
arch/arm/common/edma.c | 63 +++-
include/linux/platform_data/edma.h |1 +
2 files changed, 63
Adds a dma_request_slave_channel_compat() wrapper which accepts
both the arguments from dma_request_channel() and
dma_request_slave_channel(). Based on whether the driver is
instantiated via DT, the appropriate channel request call will be
made.
This allows for a much cleaner migration of drivers
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well. This just moves the
private EDMA API but does not support OMAP.
Signed-off-by: Matt Porter
---
arch/arm/Kconfig |1 +
arch/arm/common/Kconfig
Fix build on OMAP, the irqs are undefined on AM33xx.
These error interrupt handlers were hardcoded as disabled
so since they are unused code, simply remove them.
Signed-off-by: Matt Porter
---
arch/arm/common/edma.c | 37 -
1 file changed, 37 deletions(-)
d
The edma_slave_config() implementation depends on the
direction field such that it will not properly configure
a slave channel when called without direction set.
This fixes the implementation so that the slave config
is copied as is and prep_slave_sg() handles the
direction dependent handling. spi
Changes since v2:
- Rebased on 3.7-rc1
- Fixed bug in DT/pdata parsing first found by Gururaja
that turned out to be masked by some toolchains
- Dropped unused mach-omap2/devices.c hsmmc patch
- Added AM33XX crossbar DMA event mux support
- Added am
The binding definition is based on the generic DMA controller
binding.
Signed-off-by: Matt Porter
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 51 +
1 file changed, 51 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt
diff --git
Convert dmaengine channel requests to use
dma_request_slave_channel_compat(). This supports the DT case of
platforms requiring channel selection from either the OMAP DMA or
the EDMA engine. AM33xx only boots from DT and is the only user
implementing EDMA so in the !DT case we can default to the OMA
The EDMA DMAC has a hardware limitation that prevents supporting
scatter gather lists with any number of segments. Since the EDMA
DMA Engine driver sets the maximum segments to 16, we do the
same.
TODO: this will be replaced once the DMA Engine API supports an
API to query the DMAC's segment size
Adds AM33XX MMC support for am335x-bone and am335x-evm.
Signed-off-by: Matt Porter
---
arch/arm/boot/dts/am335x-bone.dts |6 ++
arch/arm/boot/dts/am335x-evm.dts |6 ++
arch/arm/boot/dts/am33xx.dtsi | 27 +++
3 files changed, 39 insertions(+)
diff -
Adds AM33XX EDMA support to the am33xx.dtsi as documented in
Documentation/devicetree/bindings/dma/ti-edma.txt
Signed-off-by: Matt Porter
---
arch/arm/boot/dts/am33xx.dtsi | 31 +++
1 file changed, 31 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/
The binding definition is based on the generic DMA request binding.
Signed-off-by: Matt Porter
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 25 +++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
Convert dmaengine channel requests to use
dma_request_slave_channel_compat(). This supports the DT case of
platforms requiring channel selection from either the OMAP DMA or
the EDMA engine. AM33xx only boots from DT and is the only user
implementing EDMA so in the !DT case we can default to the OMA
1 - 100 of 131 matches
Mail list logo
