Hi,
On Thu, Oct 18, 2012 at 06:49:17PM -0700, Tony Lindgren wrote:
> * 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 ne
On Thu, Oct 18, 2012 at 07:20:05PM -0700, Tony Lindgren wrote:
> 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
Acked-by: Felipe Balbi
> Cc: Samuel
Hi Avinash,
This look good to me except the: status = "disabled".
The "disabled" should be reserved for variant that does not contain the IP.
Is it the case here?
Regards,
Benoit
On 09/18/2012 07:30 AM, Philip, Avinash wrote:
> Add McSPI data node to AM33XX device tree file. The McSPI module (a
Hi Tony,
Thanks for the patch.
On Thursday 18 October 2012 13:28:42 Tony Lindgren wrote:
> 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
Hi Tony,
On Thursday 18 October 2012 13:28:48 Tony Lindgren wrote:
> 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 Ram
On Fri, Oct 19, 2012 at 13:54:15, Cousson, Benoit wrote:
> Hi Avinash,
>
> This look good to me except the: status = "disabled".
status = "disabled" in soc .dtsi file to make sure that IP driver
won't loaded unless if IP used.
So from board .dts file status = "okay" should be set if IP being us
Hi Matt,
On Thu, Oct 18, 2012 at 18:56:39, Porter, Matt wrote:
> 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
>
Hi Mike,
> In addition to removing CK_443X/CK_446X you could also get rid of struct
> omap_clk completely (arch/arm/plat-omap/include/plat/clkdev_omap.h) and
> the CLK macro by changing the clk array to be of type struct clk_lookup
> and using the CLKDEV_INIT macro.
Yes. It may be done. As I under
+ linux-omap and Daniel
On Fri, Oct 19, 2012 at 16:20:21, Mohammed, Afzal wrote:
> add am33xx rtc node.
>
> Signed-off-by: Afzal Mohammed
> ---
>
> Based on v3.7-rc1,
> Dependent on series "rtc: omap dt support (for am33xx)",
> (https://lkml.org/lkml/2012/10/19/163)
> Tested on Beagle Bone.
>
Hi Daniel,
On Thu, Oct 18, 2012 at 22:03:13, Hiremath, Vaibhav wrote:
> On Thu, Oct 18, 2012 at 21:49:44, Daniel Mack wrote:
> > On 18.10.2012 18:12, Vaibhav Hiremath wrote:
> > > It would be really helpful if you could test these patches and ack them.
> > Ok, will do tomorrow. What's missing th
On Fri, Oct 19, 2012 at 10:26:20AM +, Bedia, Vaibhav wrote:
> Hi Matt,
>
> On Thu, Oct 18, 2012 at 18:56:39, Porter, Matt wrote:
> > 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 too
On Fri, Oct 19, 2012 at 10:24:15AM +0200, Benoit Cousson wrote:
> Hi Avinash,
>
> This look good to me except the: status = "disabled".
>
> The "disabled" should be reserved for variant that does not contain the IP.
> Is it the case here?
http://comments.gmane.org/gmane.linux.drivers.devicetree/
On Fri, Oct 19, 2012 at 16:45:58, Porter, Matt wrote:
> On Fri, Oct 19, 2012 at 10:26:20AM +, Bedia, Vaibhav wrote:
[...]
> >
> > I didn't see all the patches that you posted on edma-dmaengine-v3
> > but I do seem them on edma-dmaengine-am33xx-v3 branch.
>
> I see I referenced the wrong branc
Hi Matt,
On 10/19/2012 01:30 PM, Matt Porter wrote:
> On Fri, Oct 19, 2012 at 10:24:15AM +0200, Benoit Cousson wrote:
>> Hi Avinash,
>>
>> This look good to me except the: status = "disabled".
>>
>> The "disabled" should be reserved for variant that does not contain the IP.
>> Is it the case here?
Hi,
On 10/19/2012 01:33 AM, Russell King - ARM Linux wrote:
> I would suggest getting some feedback from the ASoC people first, before
> trying to invent new APIs to work around this stuff. If they can live
> with having prefetch enabled on OMAP then there isn't an issue here. If
> not, we need
On Fri, Oct 19, 2012 at 02:40:58PM +0200, Benoit Cousson wrote:
> Hi Matt,
>
> On 10/19/2012 01:30 PM, Matt Porter wrote:
> > On Fri, Oct 19, 2012 at 10:24:15AM +0200, Benoit Cousson wrote:
> >> Hi Avinash,
> >>
> >> This look good to me except the: status = "disabled".
> >>
> >> The "disabled" sh
On Thu, 2012-10-18 at 08:51 +0300, Felipe Balbi wrote:
> > So the primary question remains: is RT runtime supposed to include the
> > time spent suspended? I suspect not.
>
> you might be right there, though we need Thomas or Peter to answer :-s
re, sorry both tglx and I have been traveling, h
This series adds device-tree support for the timers on OMAP2+ devices
including AM33xx. Based upon v3.7-rc1.
Testing:
1. I have booted tested this series on OMAP2420 H4, OMAP3430 Beagle, OMAP4430
Panda and AM335x Beagle Bone with/without ...
a). device-tree present
b). CONFIG_OMAP_32K_TIM
OMAP3 devices may or may not have security features enabled. Security enabled
devices are known as high-secure (HS) and devices without security are known as
general purpose (GP).
For OMAP3 devices there are 12 general purpose timers available. On secure
devices the 12th timer is reserved for secu
Currently OMAP timers can be requested by requesting any available or by a
numerical device ID. If a specific timer is required because it has a particular
capability, such as can interrupt the on-chip DSP in addition to the ARM CPU,
then the user needs to know the device ID of the timer with this
Add the 12 GP timers nodes present in OMAP2.
Add the 12 GP timers nodes present in OMAP3.
Add the 11 GP timers nodes present in OMAP4.
Add the 7 GP timers nodes present in AM33xx.
Add documentation for timer properties specific to OMAP.
Thanks to Vaibhav Hiremath for creating the AM33xx timer nod
OMAP3 devices may or may not have security features enabled. Security enabled
devices are known as high-secure (HS) and devices without security are known as
general purpose (GP).
Some OMAP3 boards, such as the OMAP3 beagle board, only use GP devices and for
GP devices there is a 12th timer availa
In order to add device-tree support to the timer driver the following changes
were made ...
1. Allocate system timers (used for clock-events and clock-source) based upon
timer properties rather than using an hard-coded timer instance ID. To allow
this a new helper function called omap_dmtime
On 10/19/2012 09:59 AM, Jon Hunter wrote:
> Add the 12 GP timers nodes present in OMAP2.
> Add the 12 GP timers nodes present in OMAP3.
> Add the 11 GP timers nodes present in OMAP4.
> Add the 7 GP timers nodes present in AM33xx.
>
> Add documentation for timer properties specific to OMAP.
>
> Th
This series adds device-tree support for the 32kHz counter on OMAP2+ devices,
which is used as the default kernel clock-source for OMAP devices.
Boot tested on OMAP2420 H4, OMAP3430 Beagle Board and OMAP4430 Panda Board
with and without device-tree present.
Based and dependent upon OMAP2+ series
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/arm/omap/counter.txt | 15 +++
arch/arm/boot/dts/omap2420.dtsi|6 ++
ar
For OMAP devices, the 32kHz counter is the default clock-source for the kernel.
However, this is not the only possible clock-source the kernel can use for OMAP
devices.
When booting with device-tree, if the 32kHz counter is the desired clock-source
for the kernel, then parse the device-tree blob t
Hi Daniel,
On Thursday 11 October 2012 05:15 PM, Daniel Mack wrote:
Could you tell me which patches I need on top of soon-to-be-3.7-rc1? I
would like to augment this to make GPMC attached NAND probable in DT, in
case this is still an open topic.
In case you can help on making gpmc nand dt pro
* Felipe Balbi [121019 00:01]:
> On Thu, Oct 18, 2012 at 06:49:17PM -0700, Tony Lindgren wrote:
> >
> > Yes. Figured it out, it fails to apply with quilt, but applies
> > with git.
>
> probably because of file rename.
Yeh so it seems.
> > But it does not compile with all configs though, and d
* Richard Cochran [121018 23:18]:
> 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 read
* Laurent Pinchart [121019 02:41]:
>
> Nitpicking, please keep the headers sorted alphabetically, here and in all
> locations below (especially the OMAP3 ISP driver).
>
> (OK, there's already one misplaced #include, but let's not make it worse :-))
Sure I'll check that.
> I plan to push clea
* Laurent Pinchart [121019 02:45]:
> On Thursday 18 October 2012 13:28:48 Tony Lindgren wrote:
> > @@ -117,13 +112,6 @@ static inline struct omap_iommu
> > *dev_to_omap_iommu(struct device *dev) }
> > #endif
> >
> > -/* IOMMU errors */
> > -#define OMAP_IOMMU_ERR_TLB_MISS(1 << 0)
> >
On Fri, Oct 19, 2012 at 09:00:41AM -0700, Tony Lindgren wrote:
> * Richard Cochran [121018 23:18]:
> > 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/mac
Hi,
On Fri, Oct 19, 2012 at 04:00:27PM +0200, Peter Zijlstra wrote:
> On Thu, 2012-10-18 at 08:51 +0300, Felipe Balbi wrote:
> > > So the primary question remains: is RT runtime supposed to include the
> > > time spent suspended? I suspect not.
> >
> > you might be right there, though we need T
Tony,
On 18 October 2012 18:52, Tony Lindgren wrote:
> Thanks, the related patches are now posted in thread
> "[PATCH v3 0/6] omap iommu changes to remove plat includes".
Ok.
> Also, can you please take a look at the "Updated status of the removal
> of plat headers" thread?
>
> I've tagged you
On Fri, Oct 19, 2012 at 12:02:42PM +, Bedia, Vaibhav wrote:
> On Fri, Oct 19, 2012 at 16:45:58, Porter, Matt wrote:
> > On Fri, Oct 19, 2012 at 10:26:20AM +, Bedia, Vaibhav wrote:
> [...]
> > >
> > > I didn't see all the patches that you posted on edma-dmaengine-v3
> > > but I do seem them
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 http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/
And here's two more.
> Failing tests: needing investigation
>
>
>
> Boot tests
* Aaro Koskinen [121017 14:22]:
> On Wed, Oct 17, 2012 at 11:03:00PM +0200, Pavel Machek wrote:
> >
> > This adds product names (that most users know) to Kconfig and board
> > comments.
> >
> > Signed-off-by: Pavel Machek
>
> Reviewed-by: Aaro Koskinen
Thanks applying into omap-for-v3.8/boa
Hi,
On Fri, Oct 19, 2012 at 04:55:38PM +, 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 http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/
>
> And here's two more.
>
> > Failing t
* Ohad Ben-Cohen [121018 10:00]:
> 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
In 16bit NAND mode the GPMC would send the command 0xNN as 0xFFNN
instead of 0x00NN on the bus. The 0xFFs were actually uninitialized
bits that were left unset in the GPMC command output register. The
reason they weren't initialized in 16bit mode is that if the same code
that writes to this registe
In 16bit NAND mode the GPMC would send the command 0xNN as 0xFFNN
instead of 0x00NN on the bus. The 0xFFs were actually uninitialized
bits that were left unset in the GPMC command output register. The
reason they weren't initialized in 16bit mode is that if the same code
that writes to this registe
Hi,
On 16 October 2012 18:00, Tony Lindgren wrote:
> Hi all,
>
> Here's a quick status update on the removal of remaining
> #include files. Most files are now fixed up, and
> we only have the following remaining:
>
> cpu.h wrapper only left, will be removed as soon as drivers are
> fi
just a small patch to access NAND registers with 16 bits when the NAND
is in 16 bit mode. I tested this on a 2.6.37 kernel, and noticed it
was still unpatched in the latest kernel. I don't have the hardware
setup or defconfigs to test this patch out, and even if I did I don't
have the logic analyze
Hi Felipe,
On Fri, 19 Oct 2012, Felipe Balbi wrote:
> On Fri, Oct 19, 2012 at 04:55:38PM +, 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
> > > http://www.pwsan.com/omap/
Hi,
On Fri, Oct 19, 2012 at 05:56:48PM +, Paul Walmsley wrote:
> Hi Felipe,
>
> On Fri, 19 Oct 2012, Felipe Balbi wrote:
>
> > On Fri, Oct 19, 2012 at 04:55:38PM +, Paul Walmsley wrote:
> > > On Thu, 18 Oct 2012, Paul Walmsley wrote:
> > >
> > > > Here are some basic OMAP test results f
* Omar Ramirez Luna [121019 10:45]:
> Hi,
>
> On 16 October 2012 18:00, Tony Lindgren wrote:
> > Hi all,
> >
> > Here's a quick status update on the removal of remaining
> > #include files. Most files are now fixed up, and
> > we only have the following remaining:
> >
> > cpu.h wrappe
Hi,
On Fri, Oct 19, 2012 at 04:55:38PM +, 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 http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/
>
> And here's two more.
[...]
> * 3530
On Fri, Oct 19, 2012 at 10:03:58PM +0300, Aaro Koskinen wrote:
> Hi,
>
> On Fri, Oct 19, 2012 at 04:55:38PM +, 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
> > > http://w
Hi,
On Fri, Oct 19, 2012 at 10:01:36PM +0300, Felipe Balbi wrote:
> On Fri, Oct 19, 2012 at 10:03:58PM +0300, Aaro Koskinen wrote:
> > FYI, I saw I2C hangs also on Nokia N900 with v3.7-rc1 (omap_i2c
> > omap_i2c.1: timeout waiting for bus ready). After several reboots they
> > disappered (kernel b
From: "Mark A. Greer"
This series updates the crypto omap-sham driver and supporting
infrastructure.
Notes:
a) Based on current k.o. c9623de (Merge branch 'v4l_for_linus'
of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media)
b) These have only been tested on an omap2420 h4 a
From: "Mark A. Greer"
Convert the device data for the OMAP2 SHAM crypto IP from
explicit platform_data to hwmod. When bit 1 (OMAP24XX_ST_SHA_MASK)
of the CM_IDLEST4_CORE register is set, the SHA IP is present.
CC: Paul Walmsley
Signed-off-by: Mark A. Greer
---
arch/arm/mach-omap2/clock2420_d
From: "Mark A. Greer"
Add the DMA information for the OMAP2 SHA module.
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 | 6 ++
2 files changed, 7 insertions(+), 1 de
From: "Mark A. Greer"
Convert the device data for the OMAP3 SHAM2 (SHA1/MD5) crypto IP
from explicit platform_data to hwmod. When bit 27 (OMAP3430_ST_SHA12_MASK)
of the CM_IDLEST1_CORE register is 0, the SHA2 IP is present.
CC: Paul Walmsley
Signed-off-by: Mark A. Greer
---
arch/arm/mach-omap
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 | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/mach-omap2/de
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"
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"
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: Kevin Hilman
The runtime PM framework assumes that the hardware state of devices
when initialized is disabled. For all omap_devices, we idle/disable
device by default. However, the console uart uses a "no idle" option
during omap_device init in order to allow earlyprintk usage to work
sea
Peter Zijlstra writes:
> On Thu, 2012-10-18 at 08:51 +0300, Felipe Balbi wrote:
>> > So the primary question remains: is RT runtime supposed to include the
>> > time spent suspended? I suspect not.
>>
>> you might be right there, though we need Thomas or Peter to answer :-s
>
> re, sorry both
Peter Zijlstra writes:
> On Thu, 2012-10-18 at 08:51 +0300, Felipe Balbi wrote:
>> > So the primary question remains: is RT runtime supposed to include the
>> > time spent suspended? I suspect not.
>>
>> you might be right there, though we need Thomas or Peter to answer :-s
>
> re, sorry both
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 http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/
...
> > Failing tests: needing investigation
> > ---
Hi Kevin
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 http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/
...
> > Failing tests: needing investigation
> > --
On Sat, 20 Oct 2012, Anil Kumar wrote:
> I am trying to boot devkit8000(based on OMP35xx) with kernel 3.6
> and board stopped booting here (kernel logs [1]). It looks Paul also
> faced same type issue or i am missing some some thing ?
3.6 boots fine for me on Beagle.
> Waiting for root device /
On Sat, 20 Oct 2012, Paul Walmsley wrote:
> On Sat, 20 Oct 2012, Anil Kumar wrote:
>
> > I am trying to boot devkit8000(based on OMP35xx) with kernel 3.6
> > and board stopped booting here (kernel logs [1]). It looks Paul also
> > faced same type issue or i am missing some some thing ?
>
> 3.6
65 matches
Mail list logo
