Re: [GIT PULL] omap multiplatform warning fixes for v3.9 merge window

2013-02-09 Thread Tony Lindgren 
* Olof Johansson  [130209 20:31]:
> Hi,
> 
> 
> On Sat, Feb 9, 2013 at 8:19 PM, Tony Lindgren  wrote:
> > The following changes since commit ad1bb1b4e01c5ecbe32133ce6921d0e76cb76dcf:
> >
> >   ARM: OMAP2+: Remove now obsolete uncompress.h and debug-macro.S 
> > (2013-01-11 11:24:20 -0800)
> >
> > are available in the git repository at:
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
> > tags/omap-for-v3.9/multiplatform-fixes-signed-v2
> 
> Sorry for the confusion on this; I obviously already had the
> hwspinlock patch but I hadn't pushed it out.
> 
> So, to make things a little easier I just cherry-picked over the two I
> didn't have. Thanks for staging them though. :)

OK no problem. 
 
> They're all in next/multiplatform now. I'll push out shortly as soon
> as my test build completes.

Thanks

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] omap multiplatform warning fixes for v3.9 merge window

2013-02-09 Thread Olof Johansson 
Hi,


On Sat, Feb 9, 2013 at 8:19 PM, Tony Lindgren  wrote:
> The following changes since commit ad1bb1b4e01c5ecbe32133ce6921d0e76cb76dcf:
>
>   ARM: OMAP2+: Remove now obsolete uncompress.h and debug-macro.S (2013-01-11 
> 11:24:20 -0800)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
> tags/omap-for-v3.9/multiplatform-fixes-signed-v2

Sorry for the confusion on this; I obviously already had the
hwspinlock patch but I hadn't pushed it out.

So, to make things a little easier I just cherry-picked over the two I
didn't have. Thanks for staging them though. :)


They're all in next/multiplatform now. I'll push out shortly as soon
as my test build completes.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Latest additional build warnings

2013-02-09 Thread Olof Johansson 
On Sat, Feb 9, 2013 at 7:22 PM, Tony Lindgren  wrote:
> * Olof Johansson  [130209 19:08]:
>> On Sat, Feb 9, 2013 at 7:00 PM, Tony Lindgren  wrote:
>> > * Russell King - ARM Linux  [130209 03:53]:
>> >> On Tue, Feb 05, 2013 at 02:22:18PM +, Russell King - ARM Linux wrote:
>> >> > arch/arm/mach-omap2/hwspinlock.c:60:1: warning: data definition has no 
>> >> > type or storage class
>> >> > arch/arm/mach-omap2/hwspinlock.c:60:1: warning: type defaults to 'int' 
>> >> > in declaration of 'omap_postcore_initcall'
>> >> > arch/arm/mach-omap2/hwspinlock.c:60:1: warning: parameter names 
>> >> > (without types) in function declaration
>> >> > arch/arm/mach-omap2/hwspinlock.c:31:122: warning: 'hwspinlocks_init' 
>> >> > defined but not used
>> >>
>> >> I'm still seeing the above in the build of Friday's merge.  I'm also
>> >> seeing additional warnings in the randconfig similar to the above for
>> >> arch/arm/mach-omap2/omap-iommu.c.
>> >
>> > Thanks for letting me know about the omap-iommu.c one. Looks like
>> > there's also one patch for drm.c.
>> >
>> > Olof, if you did not yet apply the hwspinlock.c warning fix, I'll
>> > just do a branch with all three of them for you.
>>
>> I haven't (must have missed it), so please just send a branch.
>
> OK will do. Probably you started fixing up the bad Reported-by
> line in my patch and then got disrupted :)
>
> Found one more after some grepping, after the following patch they
> should be all fixed up. Pull request coming shortly.

Oh wait -- I got confused there for a bit (this came in right as I had
to step out for a while).

I definitely picked up the hwspinlock patch, and it's there in my
local for-next. Looks like I missed pushing it out though. That
explains why Russell didn't see the fix. :(


So, the hwspinlock patch is already applied. The soc.h one is not, and
I'm not sure what the third one is?


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL] omap multiplatform warning fixes for v3.9 merge window

2013-02-09 Thread Tony Lindgren 
The following changes since commit ad1bb1b4e01c5ecbe32133ce6921d0e76cb76dcf:

  ARM: OMAP2+: Remove now obsolete uncompress.h and debug-macro.S (2013-01-11 
11:24:20 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
tags/omap-for-v3.9/multiplatform-fixes-signed-v2

for you to fetch changes up to 09cee18dbced86b27c6c7d4501126cf2a287d089:

  ARM: OMAP2+: Make sure files with omap initcalls include soc.h (2013-02-09 
19:20:57 -0800)


Few trivial compile warning fixes if omap initcalls are
used but soc.h is not included.


André Hentschel (1):
  ARM: OMAP2+: Include soc.h to drm.c to fix compiling

Tony Lindgren (2):
  ARM: OMAP2+: Fix warning for hwspinlock omap_postcore_initcall
  ARM: OMAP2+: Make sure files with omap initcalls include soc.h

 arch/arm/mach-omap2/drm.c| 1 +
 arch/arm/mach-omap2/hwspinlock.c | 1 +
 arch/arm/mach-omap2/omap-iommu.c | 1 +
 arch/arm/mach-omap2/smartreflex-class3.c | 1 +
 4 files changed, 4 insertions(+)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Latest additional build warnings

2013-02-09 Thread Tony Lindgren 
* Tony Lindgren  [130209 19:29]:
> 
> From: Tony Lindgren 
> Date: Sat, 9 Feb 2013 19:20:57 -0800
> Subject: [PATCH] ARCH: OMAP2+: Make sure files with omap initcalls include 
> soc.h

Oops, will fix up the subject to say ARM: OMAP2+ instead of ARCH..
 
> Looks like there are few more places that I missed that can cause
> compiler warnings. After grepping for omap initcall, all files
> needing soc.h should now have it.
> 
> Reported-by: Russell King 
> Signed-off-by: Tony Lindgren 
> 
> --- a/arch/arm/mach-omap2/omap-iommu.c
> +++ b/arch/arm/mach-omap2/omap-iommu.c
> @@ -16,6 +16,7 @@
>  #include 
>  
>  #include 
> +#include "soc.h"
>  #include "omap_hwmod.h"
>  #include "omap_device.h"
>  
> --- a/arch/arm/mach-omap2/smartreflex-class3.c
> +++ b/arch/arm/mach-omap2/smartreflex-class3.c
> @@ -12,6 +12,7 @@
>   */
>  
>  #include 
> +#include "soc.h"
>  #include "voltage.h"
>  
>  static int sr_class3_enable(struct omap_sr *sr)
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Latest additional build warnings

2013-02-09 Thread Tony Lindgren 
* Olof Johansson  [130209 19:08]:
> On Sat, Feb 9, 2013 at 7:00 PM, Tony Lindgren  wrote:
> > * Russell King - ARM Linux  [130209 03:53]:
> >> On Tue, Feb 05, 2013 at 02:22:18PM +, Russell King - ARM Linux wrote:
> >> > arch/arm/mach-omap2/hwspinlock.c:60:1: warning: data definition has no 
> >> > type or storage class
> >> > arch/arm/mach-omap2/hwspinlock.c:60:1: warning: type defaults to 'int' 
> >> > in declaration of 'omap_postcore_initcall'
> >> > arch/arm/mach-omap2/hwspinlock.c:60:1: warning: parameter names (without 
> >> > types) in function declaration
> >> > arch/arm/mach-omap2/hwspinlock.c:31:122: warning: 'hwspinlocks_init' 
> >> > defined but not used
> >>
> >> I'm still seeing the above in the build of Friday's merge.  I'm also
> >> seeing additional warnings in the randconfig similar to the above for
> >> arch/arm/mach-omap2/omap-iommu.c.
> >
> > Thanks for letting me know about the omap-iommu.c one. Looks like
> > there's also one patch for drm.c.
> >
> > Olof, if you did not yet apply the hwspinlock.c warning fix, I'll
> > just do a branch with all three of them for you.
> 
> I haven't (must have missed it), so please just send a branch.

OK will do. Probably you started fixing up the bad Reported-by
line in my patch and then got disrupted :)

Found one more after some grepping, after the following patch they
should be all fixed up. Pull request coming shortly.

Tony


From: Tony Lindgren 
Date: Sat, 9 Feb 2013 19:20:57 -0800
Subject: [PATCH] ARCH: OMAP2+: Make sure files with omap initcalls include soc.h

Looks like there are few more places that I missed that can cause
compiler warnings. After grepping for omap initcall, all files
needing soc.h should now have it.

Reported-by: Russell King 
Signed-off-by: Tony Lindgren 

--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -16,6 +16,7 @@
 #include 
 
 #include 
+#include "soc.h"
 #include "omap_hwmod.h"
 #include "omap_device.h"
 
--- a/arch/arm/mach-omap2/smartreflex-class3.c
+++ b/arch/arm/mach-omap2/smartreflex-class3.c
@@ -12,6 +12,7 @@
  */
 
 #include 
+#include "soc.h"
 #include "voltage.h"
 
 static int sr_class3_enable(struct omap_sr *sr)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] arm: Include soc.h to fix compiling

2013-02-09 Thread Tony Lindgren 
* André Hentschel  [130206 14:46]:
> I needed this when compiling for pandaboard at commit: 
> 0944c0a03465718909ba8e800a5230528aeabafb
> 
> Signed-off-by: André Hentschel From: 
> =?UTF-8?q?Andr=C3=A9=20Hentschel?= 
> From: =?UTF-8?q?Andr=C3=A9=20Hentschel?= 
> Date: Wed, 6 Feb 2013 23:16:20 +0100
> Subject: [PATCH] arm: Include soc.h to fix compiling

Thanks, applying into omap-for-v3.9/multiplatform-fixes
with the comments fixed up a bit.

Tony
 
> ---
>  arch/arm/mach-omap2/drm.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-omap2/drm.c b/arch/arm/mach-omap2/drm.c
> index 4c7566c..b4faf96 100644
> --- a/arch/arm/mach-omap2/drm.c
> +++ b/arch/arm/mach-omap2/drm.c
> @@ -27,6 +27,7 @@
>  
>  #include "omap_device.h"
>  #include "omap_hwmod.h"
> +#include "soc.h"
>  
>  #if defined(CONFIG_DRM_OMAP) || (CONFIG_DRM_OMAP_MODULE)
>  
> -- 
> 1.8.0
> 
> Best Regards, André Hentschel
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Latest additional build warnings

2013-02-09 Thread Olof Johansson 
On Sat, Feb 9, 2013 at 7:00 PM, Tony Lindgren  wrote:
> * Russell King - ARM Linux  [130209 03:53]:
>> On Tue, Feb 05, 2013 at 02:22:18PM +, Russell King - ARM Linux wrote:
>> > arch/arm/mach-omap2/hwspinlock.c:60:1: warning: data definition has no 
>> > type or storage class
>> > arch/arm/mach-omap2/hwspinlock.c:60:1: warning: type defaults to 'int' in 
>> > declaration of 'omap_postcore_initcall'
>> > arch/arm/mach-omap2/hwspinlock.c:60:1: warning: parameter names (without 
>> > types) in function declaration
>> > arch/arm/mach-omap2/hwspinlock.c:31:122: warning: 'hwspinlocks_init' 
>> > defined but not used
>>
>> I'm still seeing the above in the build of Friday's merge.  I'm also
>> seeing additional warnings in the randconfig similar to the above for
>> arch/arm/mach-omap2/omap-iommu.c.
>
> Thanks for letting me know about the omap-iommu.c one. Looks like
> there's also one patch for drm.c.
>
> Olof, if you did not yet apply the hwspinlock.c warning fix, I'll
> just do a branch with all three of them for you.

I haven't (must have missed it), so please just send a branch.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Latest additional build warnings

2013-02-09 Thread Tony Lindgren 
* Russell King - ARM Linux  [130209 03:53]:
> On Tue, Feb 05, 2013 at 02:22:18PM +, Russell King - ARM Linux wrote:
> > arch/arm/mach-omap2/hwspinlock.c:60:1: warning: data definition has no type 
> > or storage class
> > arch/arm/mach-omap2/hwspinlock.c:60:1: warning: type defaults to 'int' in 
> > declaration of 'omap_postcore_initcall'
> > arch/arm/mach-omap2/hwspinlock.c:60:1: warning: parameter names (without 
> > types) in function declaration
> > arch/arm/mach-omap2/hwspinlock.c:31:122: warning: 'hwspinlocks_init' 
> > defined but not used
> 
> I'm still seeing the above in the build of Friday's merge.  I'm also
> seeing additional warnings in the randconfig similar to the above for
> arch/arm/mach-omap2/omap-iommu.c.

Thanks for letting me know about the omap-iommu.c one. Looks like
there's also one patch for drm.c.

Olof, if you did not yet apply the hwspinlock.c warning fix, I'll
just do a branch with all three of them for you.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] ARM: OMAP4: Add OMAP4 Blaze Tablet support

2013-02-09 Thread Tony Lindgren 
Hi,

* Ruslan Bilovol  [130208 11:41]:
> The OMAP4 Blaze Tablet is TI OMAP4 processor-based
> development platform in a tablet formfactor.
> The platform contains many of the features found in
> present-day handsets (such as audio, video, wireless
> functions and user interfaces) and in addition
> contains features for software development and test.
> 
> This patch adds initial support for the OMAP4 Blaze
> Tablet development platform. Additional functionality
> depends on different drivers and code modifications that
> are not upstreamed yet so will be added later.

Nice that you have it working, however, we're not adding
any more board-*.c files as we're moving things to device
tree based booting.

Care to try to get the basic .dts file done for this?
You will probably need to add CONFIG_ARM_APPENDED_DTB=y
and CONFIG_ARM_ATAG_DTB_COMPAT=y to omap2plus_defconfig
and append the .dtb file to zImage and run mkimage then
manually to boot it. But you should get serial and MMC
at least working to start with :)

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] omap twl platform init changes for v3.9 merge window

2013-02-09 Thread Tony Lindgren 
* Olof Johansson  [130209 17:01]:
> On Wed, Feb 06, 2013 at 09:25:00AM -0800, Tony Lindgren wrote:
> > The following changes since commit 949db153b6466c6f7cad5a427ecea94985927311:
> > 
> >   Linux 3.8-rc5 (2013-01-25 11:57:28 -0800)
> > 
> > are available in the git repository at:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
> > tags/omap-for-v3.9/twl-signed-v2
> 
> 
> It would be nice to see TI enabling device-tree on these platforms/drivers
> instead of adding to legacy board files.
> 

I believe it already has at least for audio, but we cannot yet drop
the legacy support. Currently am33xx is DT only, omap4 is pretty close
to be flipped over to be DT only.
 
> Pulled into next/boards.

Thanks,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 1/7] platform: add a device node

2013-02-09 Thread Javier Martinez Canillas 
Hi Greg,

Thanks a lot for your feedback.

On 02/10/2013 02:02 AM, Greg Kroah-Hartman wrote:
> On Sat, Feb 09, 2013 at 09:44:25PM +0100, Javier Martinez Canillas wrote:
>> When using Device Trees, it is necessary to associate a
>> device node with a platform device.
>> 
>> Usually this device node has to used in the device probe
>> function (e.g: to initizalize the pinctrl pads assocaited
>> with the device).
>> 
>> So, platform code needs to pass a device node as a platform
>> device info to the platform device registration function.
> 
> Really?  We don't already have enough other pointers in the platform
> device structure that we need another one?
>

I knew this would be controversial and that's why I didn't mean it to be a patch
but a RFC :)

The problem basically is that you have to associate the platform device with its
corresponding DT device node because it can be used in the driver probe 
function.

But you can't do this before calling platform_device_register_resndata() since
the platform_device has not been allocated yet and you can't do it after since
by then the driver probe function has been executed already.

You could certainly pass the device node as a platform device resource by for
example storing the dev node pointer in the struct resource .start member or by
adding it to the structure (struct smsc911x_platform_config in this case) that
gets copied to the struct platform_device_info void *data.

Then in the driver probe function you could get the device node from either the
platform_data or a dev->resource.

But I expect most users of platform_device_register_resndata() will have a
similar issue as more and more platform drivers are migrated to DT.

So, to avoid each driver to do the same (encode and decode the DT device node
using platform_data or a device resource) I thought that it could make sense to
add yet another pointer to the struct platform_device_info structure and set:

pdev->dev.of_node = pdevinfo->of_node

inside platform_device_register_full().

> I don't buy it, sorry.  Any reason you didn't run this by Grant as well?
> 

No reason at all, it is just me being goofy. I thought that Grant was cc'ed
already and I just realized that he wasn't. cc'ing him as well.

> greg k-h
> 

Thanks a lot and best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 1/7] platform: add a device node

2013-02-09 Thread Greg Kroah-Hartman 
On Sat, Feb 09, 2013 at 09:44:25PM +0100, Javier Martinez Canillas wrote:
> When using Device Trees, it is necessary to associate a
> device node with a platform device.
> 
> Usually this device node has to used in the device probe
> function (e.g: to initizalize the pinctrl pads assocaited
> with the device).
> 
> So, platform code needs to pass a device node as a platform
> device info to the platform device registration function.

Really?  We don't already have enough other pointers in the platform
device structure that we need another one?

I don't buy it, sorry.  Any reason you didn't run this by Grant as well?

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] omap twl platform init changes for v3.9 merge window

2013-02-09 Thread Olof Johansson 
On Wed, Feb 06, 2013 at 09:25:00AM -0800, Tony Lindgren wrote:
> The following changes since commit 949db153b6466c6f7cad5a427ecea94985927311:
> 
>   Linux 3.8-rc5 (2013-01-25 11:57:28 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
> tags/omap-for-v3.9/twl-signed-v2


It would be nice to see TI enabling device-tree on these platforms/drivers
instead of adding to legacy board files.


Pulled into next/boards.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 7/7] ARM: omap2: gpmc-onenand: Replace printk KERN_ERR with dev_warn()

2013-02-09 Thread Felipe Balbi 
On Sat, Feb 09, 2013 at 03:05:31PM -0300, Ezequiel Garcia wrote:
> On Sat, Feb 09, 2013 at 06:55:32PM +0200, Felipe Balbi wrote:
> > Hi,
> > 
> > On Sat, Feb 09, 2013 at 01:38:16PM -0300, Ezequiel Garcia wrote:
> > > Since the condition is not an error but a warning, replace
> > > printk KERN_ERR with dev_warn.
> > > 
> > > Signed-off-by: Ezequiel Garcia 
> > > ---
> > >  arch/arm/mach-omap2/gpmc-onenand.c |2 +-
> > >  1 files changed, 1 insertions(+), 1 deletions(-)
> > > 
> > > diff --git a/arch/arm/mach-omap2/gpmc-onenand.c 
> > > b/arch/arm/mach-omap2/gpmc-onenand.c
> > > index 4771945..fd6e35b 100644
> > > --- a/arch/arm/mach-omap2/gpmc-onenand.c
> > > +++ b/arch/arm/mach-omap2/gpmc-onenand.c
> > > @@ -367,7 +367,7 @@ void gpmc_onenand_init(struct 
> > > omap_onenand_platform_data *_onenand_data)
> > >  
> > >   if (cpu_is_omap24xx() &&
> > >   (gpmc_onenand_data->flags & ONENAND_SYNC_READWRITE)) {
> > > - printk(KERN_ERR "Onenand using only SYNC_READ on 24xx\n");
> > > + dev_warn(dev, "OneNAND using only SYNC_READ on 24xx\n");
> > 
> > it would seem more natural to use dev_err() instead.
> > 
> 
> Are you sure? The error seems more a warning to me,
> although I guess it's arguable.
> 
> Let me know and I'll fix it in v2.

my bad, should've read the code more carefuly. Indeed it looks more like
a warning as we continue to try to use the IP. My bad.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 3/7] ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value

2013-02-09 Thread Felipe Balbi 
Hi,

On Sat, Feb 09, 2013 at 03:14:33PM -0300, Ezequiel Garcia wrote:
> > >  static int gpmc_cs_reserved(int cs)
> > >  {
> > >   if (cs > GPMC_CS_NUM)
> > >   return -ENODEV;
> > >  
> > > - return gpmc_cs_map & (1 << cs);
> > > + if (gpmc_cs_map & (1 << cs))
> > > + return -EBUSY;
> > > +
> > > + return 0;
> > 
> > you could use a ternary operator here:
> > 
> > bit = gpmc_cs_map & (1 << cs);
> > 
> > return bit ? -EBUSY : 0;
> > 
> > But to be frank, I'm not sure this makes that much sense, I'd expect
> > gpmc_cs_reserved() to return 0 or 1 depending on the state (just as it
> > was before). The name of the method asks for a boolean return value.
> > 
> 
> Well, we can change the return value to a boolean.
> 
> However, note that the function 'as it was before' was somewhat inconsistent:
> gpmc_cs_reserved returned -ENODEV if the given 'cs' was out of range and
> a non-negative integer otherwise, 0 if the cs is available and positive
> integer otherwise.
> 
> So, what I'm doing here is fixing this by returning an appropriate error
> condition or 0 if the CS is available.
> 
> If we change it to return a boolean, we won't be able to distinguish
> between EBUSY and ENODEV.

that's the thing. IMO this should return 1 if it is available and 0 if
it's not. The method looks like a yes/no question:

Q: Is this GPMC CS reserved ?
A: Yes (1)

or

A: No (0)

then it's als far easier to use, just as code was before:

if (gpmc_cs_reserved(cs)) {
dev_dbg(dev, "Oops, CS #%d is busy\n", cs);
return -EBUSY;
} else {
dev_dbg(dev, "Hurray!\n");
return 0;
}

-- 
balbi


signature.asc
Description: Digital signature

[PATCH RFC 7/7] ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support

2013-02-09 Thread Javier Martinez Canillas 
IGEPv2 boards has an SMSC LAN9221i ethernet chip connected to
the OMAP3 processor though the General-Purpose Memory Controller.

This patch adds a device node for the ethernet chip so the GPMC
driver will call the gpmc-smsc911x setup code.

Signed-off-by: Javier Martinez Canillas 
---
 arch/arm/boot/dts/omap3-igep.dtsi|6 ++
 arch/arm/boot/dts/omap3-igep0020.dts |   24 
 2 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-igep.dtsi 
b/arch/arm/boot/dts/omap3-igep.dtsi
index 100eb41..2f02581 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -48,6 +48,12 @@
0x126 0x0100/* sdmmc1_dat7.sdmmc1_dat7 INPUT | MODE 
0 */
>;
};
+
+smsc911x_pins: pinmux_smsc911x_pins {
+pinctrl-single,pins = <
+0x1a2 0x0104/* mcspi1_cs2.gpio_176 INPUT | MODE4 */
+>;
+};
 };
 
 &i2c1 {
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts 
b/arch/arm/boot/dts/omap3-igep0020.dts
index e2b9849..68b7cf3 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -40,6 +40,18 @@
gpios = <&twl_gpio 19 1>;
};
};
+
+vddvario: regulator-vddvario {
+compatible = "regulator-fixed";
+regulator-name = "vddvario";
+regulator-always-on;
+};
+
+vdd33a: regulator-vdd33a {
+compatible = "regulator-fixed";
+regulator-name = "vdd33a";
+regulator-always-on;
+};
 };
 
 &i2c3 {
@@ -54,3 +66,15 @@
reg = <0x50>;
};
 };
+
+&gpmc {
+   gpmc_smsc911x@0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&smsc911x_pins>;
+   gpmc,cs = <5>; /* IGEP2_SMSC911X_CS */
+   gpmc,gpio_irq = <176>; /* IGEP2_SMSC911X_GPIO */
+   gpmc,flags = <18>; /* SMSC911X_USE_32BIT | 
SMSC911X_SAVE_MAC_ADDRESS */
+   vmmc-supply = <&vddvario>;
+   vmmc_aux-supply = <&vdd33a>;
+  };
+};
-- 
1.7.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RFC 5/7] ARM: OMAP: gpmc: add support for gpmc-smsc911x child nodes

2013-02-09 Thread Javier Martinez Canillas 
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices to the OMAP processor that use the GPMC
as a data bus. One of these devices is the smsc911x LAN chip.

This patch allows an smsc911x LAN pheripheral to be defined
as an GPMC child node an call its corresponding setup function.

Signed-off-by: Javier Martinez Canillas 
---
 arch/arm/mach-omap2/gpmc.c |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index f55b504..fd22c62 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -40,6 +40,7 @@
 #include "gpmc.h"
 #include "gpmc-nand.h"
 #include "gpmc-onenand.h"
+#include "gpmc-smsc911x.h"
 
 #defineDEVICE_NAME "omap-gpmc"
 
@@ -1320,6 +1321,14 @@ static int gpmc_probe_dt(struct platform_device *pdev)
return ret;
}
}
+
+   for_each_node_by_name(child, "gpmc_smsc911x") {
+   ret = gpmc_smsc911x_init_dt(child);
+   if (ret < 0) {
+   of_node_put(child);
+   return ret;
+   }
+   }
return 0;
 }
 #else
-- 
1.7.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RFC 6/7] ARM: dts: OMAP: Add an GPMC node for OMAP3

2013-02-09 Thread Javier Martinez Canillas 
This patch adds a General-Purpose Memory Controller (GPMC)
device node to be used for OMAP3 based SoC boards.

Signed-off-by: Javier Martinez Canillas 
---
 arch/arm/boot/dts/omap3.dtsi |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 6c63118..38b52b3 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -403,5 +403,16 @@
ti,timer-alwon;
ti,timer-secure;
};
+
+   gpmc: gpmc@6e00 {
+   compatible = "ti,omap3430-gpmc";
+   ti,hwmods = "gpmc";
+   reg = <0x6e00 0x100>;
+   interrupts = <20>; /* M_IRQ_20 interrupt */
+   gpmc,num-cs = <8>;
+   gpmc,num-waitpins = <4>;
+   #address-cells = <2>;
+   #size-cells = <1>;
+   };
};
 };
-- 
1.7.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RFC 3/7] ARM: OMAP: gpmc-smsc911x: add DT dev node init function

2013-02-09 Thread Javier Martinez Canillas 
This patch adds a helper function to parse a device node that
contains all the properties needed to initialize an smsc911x
device connected to an OMAP processor through OMAP's GPMC.

Signed-off-by: Javier Martinez Canillas 
---
 .../devicetree/bindings/net/gpmc-smsc911x.txt  |   39 
 arch/arm/mach-omap2/gpmc-smsc911x.c|   29 +++
 arch/arm/mach-omap2/gpmc-smsc911x.h|6 +++
 3 files changed, 74 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/gpmc-smsc911x.txt

diff --git a/Documentation/devicetree/bindings/net/gpmc-smsc911x.txt 
b/Documentation/devicetree/bindings/net/gpmc-smsc911x.txt
new file mode 100644
index 000..8bb0df2
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/gpmc-smsc911x.txt
@@ -0,0 +1,39 @@
+* GPMC connected Smart Mixed-Signal Connectivity (SMSC) LAN911x/912x Controller
+
+GPMC connected SMSC LAN911x/912x Controllers are represented as child nodes
+of the OMAP General-Purpose Memory Controller with a name of "gpmc_smsc911x".
+
+All timing relevant properties as well as generic gpmc child properties are
+explained in a separate documents - please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Required properties:
+- gpmc,cs : The chip select line the pheripheral is connected to
+- gpmc,gpio_irq : The GPIO pin that is connected to the SMSC LAN IRQ line
+
+Optional properties:
+- gpmc,flags : SMSC LAN flags - please refer to include/linux/smsc911x.h
+- gpmc,gpio_reset : The GPIO pin connected to the SMSC LAN reset line
+
+Note: Besides these properties, the gpmc_smsc911x device node could need
+aditional setup such as pin/pad mux settings and voltage regulators. This
+depend on how the pheripheral is wired and his board specific.
+
+Example (for an OMAP3 board):
+
+gpmc@6e00 {
+ compatible = "ti,omap3430-gpmc";
+ ti,hwmods = "gpmc";
+ reg = <0x6e00 0x100>;
+ interrupts = <20>;
+ gpmc,num-cs = <8>;
+ gpmc,num-waitpins = <4>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+
+ gpmc_smsc911x@0 {
+ gpmc,cs = <5>;
+ gpmc,gpio_irq = <176>;
+ gpmc,flags = <4>; /* SMSC911X_USE_32BIT */
+ };
+};
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c 
b/arch/arm/mach-omap2/gpmc-smsc911x.c
index 5ce00ad2..59a2ee4 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "gpmc.h"
 #include "gpmc-smsc911x.h"
@@ -98,3 +99,31 @@ free1:
 
pr_err("Could not initialize smsc911x device\n");
 }
+
+int gpmc_smsc911x_init_dt(struct device_node *node)
+{
+   struct omap_smsc911x_platform_data gpmc_cfg;
+
+   if (WARN_ON(!node))
+   return -ENODEV;
+
+   if (of_property_read_u32(node, "gpmc,cs", &gpmc_cfg.cs)) {
+   pr_err("Unable to get GPMC smsc911x chip select\n");
+   return -EINVAL;
+   }
+
+   if (of_property_read_u32(node, "gpmc,gpio_irq", &gpmc_cfg.gpio_irq)) {
+   pr_err("Unable to get GPMC smsc911x GPIO IRQ\n");
+   return -EINVAL;
+   }
+
+   if (of_property_read_u32(node, "gpmc,gpio_reset", &gpmc_cfg.gpio_reset))
+   gpmc_cfg.gpio_reset = -EINVAL;
+
+   if (of_property_read_u32(node, "gpmc,flags", &gpmc_cfg.flags))
+   gpmc_cfg.flags = 0;
+
+   gpmc_smsc911x_init(&gpmc_cfg);
+
+   return 0;
+}
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.h 
b/arch/arm/mach-omap2/gpmc-smsc911x.h
index ea6c9c8..bbcb8bc 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.h
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.h
@@ -25,11 +25,17 @@ struct omap_smsc911x_platform_data {
 
 extern void gpmc_smsc911x_init(struct omap_smsc911x_platform_data *d);
 
+extern int gpmc_smsc911x_init_dt(struct device_node *node);
+
 #else
 
 static inline void gpmc_smsc911x_init(struct omap_smsc911x_platform_data *d)
 {
 }
 
+static inline int gpmc_smsc911x_init_dt(struct device_node *node)
+{
+}
+
 #endif
 #endif
-- 
1.7.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RFC 4/7] ARM: OMAP: gpmc-smsc911x: pass a dev node to platform registration

2013-02-09 Thread Javier Martinez Canillas 
The smsc911x driver needs the GPMC smsc911x associated device
node to set the OMAP mux pins using the pinctrl framework.

Signed-off-by: Javier Martinez Canillas 
---
 arch/arm/mach-omap2/gpmc-smsc911x.c |5 -
 arch/arm/mach-omap2/gpmc-smsc911x.h |1 +
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c 
b/arch/arm/mach-omap2/gpmc-smsc911x.c
index 59a2ee4..9f3b0a5 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -83,7 +83,8 @@ void __init gpmc_smsc911x_init(struct 
omap_smsc911x_platform_data *gpmc_cfg)
 
pdev = platform_device_register_resndata(NULL, "smsc911x", gpmc_cfg->id,
 gpmc_smsc911x_resources, ARRAY_SIZE(gpmc_smsc911x_resources),
-&gpmc_smsc911x_config, sizeof(gpmc_smsc911x_config), NULL);
+&gpmc_smsc911x_config, sizeof(gpmc_smsc911x_config),
+gpmc_cfg->of_node);
if (!pdev) {
pr_err("Unable to register platform device\n");
gpio_free(gpmc_cfg->gpio_reset);
@@ -107,6 +108,8 @@ int gpmc_smsc911x_init_dt(struct device_node *node)
if (WARN_ON(!node))
return -ENODEV;
 
+   gpmc_cfg.of_node = node;
+
if (of_property_read_u32(node, "gpmc,cs", &gpmc_cfg.cs)) {
pr_err("Unable to get GPMC smsc911x chip select\n");
return -EINVAL;
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.h 
b/arch/arm/mach-omap2/gpmc-smsc911x.h
index bbcb8bc..32a7df0 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.h
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.h
@@ -19,6 +19,7 @@ struct omap_smsc911x_platform_data {
int gpio_irq;
int gpio_reset;
u32 flags;
+   struct device_node *of_node;
 };
 
 #if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
-- 
1.7.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RFC 1/7] platform: add a device node

2013-02-09 Thread Javier Martinez Canillas 
When using Device Trees, it is necessary to associate a
device node with a platform device.

Usually this device node has to used in the device probe
function (e.g: to initizalize the pinctrl pads assocaited
with the device).

So, platform code needs to pass a device node as a platform
device info to the platform device registration function.

Signed-off-by: Javier Martinez Canillas 
---
 arch/arm/mach-imx/devices/platform-gpio-mxc.c |2 +-
 arch/arm/mach-imx/devices/platform-imx-dma.c  |4 ++--
 arch/arm/mach-imx/mach-armadillo5x0.c |2 +-
 arch/arm/mach-imx/mach-imx27_visstrim_m10.c   |3 ++-
 arch/arm/mach-imx/mach-mx1ads.c   |2 +-
 arch/arm/mach-nomadik/cpu-8815.c  |2 +-
 arch/arm/mach-omap2/fb.c  |2 +-
 arch/arm/mach-omap2/gpmc-smsc911x.c   |2 +-
 arch/arm/mach-ux500/board-mop500-audio.c  |2 +-
 arch/arm/mach-ux500/devices-common.c  |3 ++-
 arch/arm/mach-ux500/devices-db8500.h  |2 +-
 arch/unicore32/kernel/puv3-core.c |2 +-
 arch/unicore32/kernel/puv3-nb0916.c   |2 +-
 drivers/base/platform.c   |1 +
 drivers/leds/leds-gpio-register.c |2 +-
 drivers/virtio/virtio_mmio.c  |2 +-
 include/linux/platform_device.h   |9 ++---
 sound/soc/samsung/i2s.c   |2 +-
 18 files changed, 26 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-imx/devices/platform-gpio-mxc.c 
b/arch/arm/mach-imx/devices/platform-gpio-mxc.c
index 26483fa..4f4d8f9 100644
--- a/arch/arm/mach-imx/devices/platform-gpio-mxc.c
+++ b/arch/arm/mach-imx/devices/platform-gpio-mxc.c
@@ -28,5 +28,5 @@ struct platform_device *__init mxc_register_gpio(char *name, 
int id,
};
 
return platform_device_register_resndata(&mxc_aips_bus,
-   name, id, res, ARRAY_SIZE(res), NULL, 0);
+   name, id, res, ARRAY_SIZE(res), NULL, 0, NULL);
 }
diff --git a/arch/arm/mach-imx/devices/platform-imx-dma.c 
b/arch/arm/mach-imx/devices/platform-imx-dma.c
index ccdb5dc..1e3838c 100644
--- a/arch/arm/mach-imx/devices/platform-imx-dma.c
+++ b/arch/arm/mach-imx/devices/platform-imx-dma.c
@@ -28,7 +28,7 @@ struct platform_device __init __maybe_unused 
*imx_add_imx_dma(char *name,
};
 
return platform_device_register_resndata(&mxc_ahb_bus,
-   name, -1, res, ARRAY_SIZE(res), NULL, 0);
+   name, -1, res, ARRAY_SIZE(res), NULL, 0, NULL);
 }
 
 struct platform_device __init __maybe_unused *imx_add_imx_sdma(char *name,
@@ -47,5 +47,5 @@ struct platform_device __init __maybe_unused 
*imx_add_imx_sdma(char *name,
};
 
return platform_device_register_resndata(&mxc_ahb_bus, name,
-   -1, res, ARRAY_SIZE(res), pdata, sizeof(*pdata));
+   -1, res, ARRAY_SIZE(res), pdata, sizeof(*pdata), NULL);
 }
diff --git a/arch/arm/mach-imx/mach-armadillo5x0.c 
b/arch/arm/mach-imx/mach-armadillo5x0.c
index 59bd6b0..e664681 100644
--- a/arch/arm/mach-imx/mach-armadillo5x0.c
+++ b/arch/arm/mach-imx/mach-armadillo5x0.c
@@ -519,7 +519,7 @@ static void __init armadillo5x0_init(void)
platform_device_register_resndata(NULL, "physmap-flash", -1,
&armadillo5x0_nor_flash_resource, 1,
&armadillo5x0_nor_flash_pdata,
-   sizeof(armadillo5x0_nor_flash_pdata));
+   sizeof(armadillo5x0_nor_flash_pdata), NULL);
 
/* Register NAND Flash */
imx31_add_mxc_nand(&armadillo5x0_nand_board_info);
diff --git a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c 
b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
index 318bd8d..5065f67 100644
--- a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
+++ b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
@@ -570,7 +570,8 @@ static void __init visstrim_m10_board_init(void)
imx_add_platform_device("mx27vis", 0, NULL, 0, &snd_mx27vis_pdata,
sizeof(snd_mx27vis_pdata));
platform_device_register_resndata(NULL, "soc-camera-pdrv", 0, NULL, 0,
- &iclink_tvp5150, sizeof(iclink_tvp5150));
+ &iclink_tvp5150, sizeof(iclink_tvp5150),
+ NULL);
gpio_led_register_device(0, &visstrim_m10_led_data);
 
/* Use mother board version to decide what video devices we shall use */
diff --git a/arch/arm/mach-imx/mach-mx1ads.c b/arch/arm/mach-imx/mach-mx1ads.c
index 06b4837..9ce64a5 100644
--- a/arch/arm/mach-imx/mach-mx1ads.c
+++ b/arch/arm/mach-imx/mach-mx1ads.c
@@ -118,7 +118,7 @@ static void __init mx1ads_init(void)
/* Physmap flash */
platform_device_register_resndata(NULL, "physmap-flash", 0,
&flash_resource, 1,
-   &mx1ads_flash_data, sizeof(mx1ads_flash_data));
+

[PATCH RFC 2/7] net: smsc911x: add pinctrl support

2013-02-09 Thread Javier Martinez Canillas 
If no pinctrl is available just report a warning since
it may not needed in some cases (e.g: non-DT kernels).

Signed-off-by: Javier Martinez Canillas 
---
 drivers/net/ethernet/smsc/smsc911x.c |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/drivers/net/ethernet/smsc/smsc911x.c 
b/drivers/net/ethernet/smsc/smsc911x.c
index e112877..40766c7 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -59,6 +59,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "smsc911x.h"
 
 #define SMSC_CHIPNAME  "smsc911x"
@@ -2352,6 +2353,7 @@ static int smsc911x_drv_probe(struct platform_device 
*pdev)
struct smsc911x_data *pdata;
struct smsc911x_platform_config *config = pdev->dev.platform_data;
struct resource *res, *irq_res;
+   struct pinctrl *pinctrl;
unsigned int intcfg = 0;
int res_size, irq_flags;
int retval;
@@ -2381,6 +2383,15 @@ static int smsc911x_drv_probe(struct platform_device 
*pdev)
goto out_0;
}
 
+   pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
+   if (IS_ERR(pinctrl)) {
+   retval = PTR_ERR(pinctrl);
+   if (retval == -EPROBE_DEFER)
+   goto out_0;
+
+   dev_warn(&pdev->dev, "No pinctrl provided\n");
+   }
+
dev = alloc_etherdev(sizeof(struct smsc911x_data));
if (!dev) {
retval = -ENOMEM;
-- 
1.7.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RFC 0/7] ARM: OMAP: add DT binding for gpmc-smsc911x

2013-02-09 Thread Javier Martinez Canillas 
Hello,

This is an RFC to add Device Tree support for SMSC LAN chips connected
to OMAP processors though its General-Purpose Memory Controller.

The patch-set is composed of the following patches:

[PATCH RFC 1/7] platform: add a device node
[PATCH RFC 2/7] net: smsc911x: add pinctrl support
[PATCH RFC 3/7] ARM: OMAP: gpmc-smsc911x: add DT dev node init function
[PATCH RFC 4/7] ARM: OMAP: gpmc-smsc911x: pass a dev node to platform
[PATCH RFC 5/7] ARM: OMAP: gpmc: add support for gpmc-smsc911x child
[PATCH RFC 6/7] ARM: dts: OMAP: Add an GPMC node for OMAP3
[PATCH RFC 7/7] ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support

It is an RFC because I had to modify the platform_device_register_resndata()
platform device registration function to allow passing a device node and
associate to the platform device after allocation. The patch-set updates all
current users and this shouldn't have a function effect on them.

I think that the need for platform code to pass the DT device node to the
platform registration infraestructure will be needed for other devices too
whose probe function needs to access the device node associated with the
device.

The binding has been tested on an TI OMAP3 based board (IGEPv2) and added
support is included on the RFC as an example.

It is based on Linus' latest master branch + linux-omap/omap-for-v3.9/gpmc
+ linux-omap-dt/for_3.9/dts

Thanks a lot and best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

2013-02-09 Thread Russell King - ARM Linux 
On Sat, Feb 09, 2013 at 09:35:53PM +0530, Sekhar Nori wrote:
> On 2/1/2013 11:52 PM, Matt Porter wrote:
> > +   ret = of_address_to_resource(node, 1, &res);
> 
> of_address_to_resource() needs 
> 
> > +   if (IS_ERR_VALUE(ret))
> 
> This needs 

More importantly, is this the correct way to check for errors from
of_address_to_resource() ?  Grepping the source shows that either less
than 0 or non-zero are the commonly used conditions here.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/7] ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value

2013-02-09 Thread Ezequiel Garcia 
Hi Felipe,

On Sat, Feb 09, 2013 at 06:53:35PM +0200, Felipe Balbi wrote:
> On Sat, Feb 09, 2013 at 01:38:12PM -0300, Ezequiel Garcia wrote:
> > Fix gpmc_cs_reserved() so it returns 0 if the chip select
> > is available (not reserved) or an error otherwise.
> > This allows to use the return value directly and return a proper error code.
> > 
> > Signed-off-by: Ezequiel Garcia 
> > ---
> >  arch/arm/mach-omap2/gpmc.c |   12 
> >  1 files changed, 8 insertions(+), 4 deletions(-)
> > 
> > diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> > index bd3bc93..604c1eb 100644
> > --- a/arch/arm/mach-omap2/gpmc.c
> > +++ b/arch/arm/mach-omap2/gpmc.c
> > @@ -452,12 +452,16 @@ static int gpmc_cs_set_reserved(int cs, int reserved)
> > return 0;
> >  }
> >  
> > +/* Returns 0 if CS is available (not reseverd) or an error otherwise */
> 
> s/reseverd/reserved/
> 

Indeed.

> >  static int gpmc_cs_reserved(int cs)
> >  {
> > if (cs > GPMC_CS_NUM)
> > return -ENODEV;
> >  
> > -   return gpmc_cs_map & (1 << cs);
> > +   if (gpmc_cs_map & (1 << cs))
> > +   return -EBUSY;
> > +
> > +   return 0;
> 
> you could use a ternary operator here:
> 
> bit = gpmc_cs_map & (1 << cs);
> 
> return bit ? -EBUSY : 0;
> 
> But to be frank, I'm not sure this makes that much sense, I'd expect
> gpmc_cs_reserved() to return 0 or 1 depending on the state (just as it
> was before). The name of the method asks for a boolean return value.
> 

Well, we can change the return value to a boolean.

However, note that the function 'as it was before' was somewhat inconsistent:
gpmc_cs_reserved returned -ENODEV if the given 'cs' was out of range and
a non-negative integer otherwise, 0 if the cs is available and positive
integer otherwise.

So, what I'm doing here is fixing this by returning an appropriate error
condition or 0 if the CS is available.

If we change it to return a boolean, we won't be able to distinguish
between EBUSY and ENODEV.

Let me know what you prefer and I'll fix it on v2.

Thanks for the review,

-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 7/7] ARM: omap2: gpmc-onenand: Replace printk KERN_ERR with dev_warn()

2013-02-09 Thread Ezequiel Garcia 
On Sat, Feb 09, 2013 at 06:55:32PM +0200, Felipe Balbi wrote:
> Hi,
> 
> On Sat, Feb 09, 2013 at 01:38:16PM -0300, Ezequiel Garcia wrote:
> > Since the condition is not an error but a warning, replace
> > printk KERN_ERR with dev_warn.
> > 
> > Signed-off-by: Ezequiel Garcia 
> > ---
> >  arch/arm/mach-omap2/gpmc-onenand.c |2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/arch/arm/mach-omap2/gpmc-onenand.c 
> > b/arch/arm/mach-omap2/gpmc-onenand.c
> > index 4771945..fd6e35b 100644
> > --- a/arch/arm/mach-omap2/gpmc-onenand.c
> > +++ b/arch/arm/mach-omap2/gpmc-onenand.c
> > @@ -367,7 +367,7 @@ void gpmc_onenand_init(struct 
> > omap_onenand_platform_data *_onenand_data)
> >  
> > if (cpu_is_omap24xx() &&
> > (gpmc_onenand_data->flags & ONENAND_SYNC_READWRITE)) {
> > -   printk(KERN_ERR "Onenand using only SYNC_READ on 24xx\n");
> > +   dev_warn(dev, "OneNAND using only SYNC_READ on 24xx\n");
> 
> it would seem more natural to use dev_err() instead.
> 

Are you sure? The error seems more a warning to me,
although I guess it's arguable.

Let me know and I'll fix it in v2.

-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 7/7] ARM: omap2: gpmc-onenand: Replace printk KERN_ERR with dev_warn()

2013-02-09 Thread Felipe Balbi 
Hi,

On Sat, Feb 09, 2013 at 01:38:16PM -0300, Ezequiel Garcia wrote:
> Since the condition is not an error but a warning, replace
> printk KERN_ERR with dev_warn.
> 
> Signed-off-by: Ezequiel Garcia 
> ---
>  arch/arm/mach-omap2/gpmc-onenand.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/gpmc-onenand.c 
> b/arch/arm/mach-omap2/gpmc-onenand.c
> index 4771945..fd6e35b 100644
> --- a/arch/arm/mach-omap2/gpmc-onenand.c
> +++ b/arch/arm/mach-omap2/gpmc-onenand.c
> @@ -367,7 +367,7 @@ void gpmc_onenand_init(struct omap_onenand_platform_data 
> *_onenand_data)
>  
>   if (cpu_is_omap24xx() &&
>   (gpmc_onenand_data->flags & ONENAND_SYNC_READWRITE)) {
> - printk(KERN_ERR "Onenand using only SYNC_READ on 24xx\n");
> + dev_warn(dev, "OneNAND using only SYNC_READ on 24xx\n");

it would seem more natural to use dev_err() instead.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 3/7] ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value

2013-02-09 Thread Felipe Balbi 
On Sat, Feb 09, 2013 at 01:38:12PM -0300, Ezequiel Garcia wrote:
> Fix gpmc_cs_reserved() so it returns 0 if the chip select
> is available (not reserved) or an error otherwise.
> This allows to use the return value directly and return a proper error code.
> 
> Signed-off-by: Ezequiel Garcia 
> ---
>  arch/arm/mach-omap2/gpmc.c |   12 
>  1 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> index bd3bc93..604c1eb 100644
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -452,12 +452,16 @@ static int gpmc_cs_set_reserved(int cs, int reserved)
>   return 0;
>  }
>  
> +/* Returns 0 if CS is available (not reseverd) or an error otherwise */

s/reseverd/reserved/

>  static int gpmc_cs_reserved(int cs)
>  {
>   if (cs > GPMC_CS_NUM)
>   return -ENODEV;
>  
> - return gpmc_cs_map & (1 << cs);
> + if (gpmc_cs_map & (1 << cs))
> + return -EBUSY;
> +
> + return 0;

you could use a ternary operator here:

bit = gpmc_cs_map & (1 << cs);

return bit ? -EBUSY : 0;

But to be frank, I'm not sure this makes that much sense, I'd expect
gpmc_cs_reserved() to return 0 or 1 depending on the state (just as it
was before). The name of the method asks for a boolean return value.

-- 
balbi


signature.asc
Description: Digital signature

[PATCH 7/7] ARM: omap2: gpmc-onenand: Replace printk KERN_ERR with dev_warn()

2013-02-09 Thread Ezequiel Garcia 
Since the condition is not an error but a warning, replace
printk KERN_ERR with dev_warn.

Signed-off-by: Ezequiel Garcia 
---
 arch/arm/mach-omap2/gpmc-onenand.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-onenand.c 
b/arch/arm/mach-omap2/gpmc-onenand.c
index 4771945..fd6e35b 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -367,7 +367,7 @@ void gpmc_onenand_init(struct omap_onenand_platform_data 
*_onenand_data)
 
if (cpu_is_omap24xx() &&
(gpmc_onenand_data->flags & ONENAND_SYNC_READWRITE)) {
-   printk(KERN_ERR "Onenand using only SYNC_READ on 24xx\n");
+   dev_warn(dev, "OneNAND using only SYNC_READ on 24xx\n");
gpmc_onenand_data->flags &= ~ONENAND_SYNC_READWRITE;
gpmc_onenand_data->flags |= ONENAND_SYNC_READ;
}
-- 
1.7.8.6

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 6/7] ARM: omap2: gpmc-onenand: Replace pr_err() with dev_err()

2013-02-09 Thread Ezequiel Garcia 
Signed-off-by: Ezequiel Garcia 
---
 arch/arm/mach-omap2/gpmc-onenand.c |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-onenand.c 
b/arch/arm/mach-omap2/gpmc-onenand.c
index 0ee5317..4771945 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -359,6 +359,7 @@ static int gpmc_onenand_setup(void __iomem *onenand_base, 
int *freq_ptr)
 void gpmc_onenand_init(struct omap_onenand_platform_data *_onenand_data)
 {
int err;
+   struct device *dev = &gpmc_onenand_device.dev;
 
gpmc_onenand_data = _onenand_data;
gpmc_onenand_data->onenand_setup = gpmc_onenand_setup;
@@ -379,8 +380,8 @@ void gpmc_onenand_init(struct omap_onenand_platform_data 
*_onenand_data)
err = gpmc_cs_request(gpmc_onenand_data->cs, ONENAND_IO_SIZE,
(unsigned long *)&gpmc_onenand_resource.start);
if (err < 0) {
-   pr_err("%s: Cannot request GPMC CS %d, error %d\n",
-  __func__, gpmc_onenand_data->cs, err);
+   dev_err(dev, "Cannot request GPMC CS %d, error %d\n",
+   gpmc_onenand_data->cs, err);
return;
}
 
@@ -388,7 +389,7 @@ void gpmc_onenand_init(struct omap_onenand_platform_data 
*_onenand_data)
ONENAND_IO_SIZE - 1;
 
if (platform_device_register(&gpmc_onenand_device) < 0) {
-   pr_err("%s: Unable to register OneNAND device\n", __func__);
+   dev_err(dev, "Unable to register OneNAND device\n");
gpmc_cs_free(gpmc_onenand_data->cs);
return;
}
-- 
1.7.8.6

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/7] ARM: omap2: gpmc-onenand: Print something useful on CS request failure

2013-02-09 Thread Ezequiel Garcia 
If CS request fails the current error message is rather unhelpful.
Fix it by printing the failing chip select and the error code.

Signed-off-by: Ezequiel Garcia 
---
 arch/arm/mach-omap2/gpmc-onenand.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-onenand.c 
b/arch/arm/mach-omap2/gpmc-onenand.c
index fadd8743..0ee5317 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -379,7 +379,8 @@ void gpmc_onenand_init(struct omap_onenand_platform_data 
*_onenand_data)
err = gpmc_cs_request(gpmc_onenand_data->cs, ONENAND_IO_SIZE,
(unsigned long *)&gpmc_onenand_resource.start);
if (err < 0) {
-   pr_err("%s: Cannot request GPMC CS\n", __func__);
+   pr_err("%s: Cannot request GPMC CS %d, error %d\n",
+  __func__, gpmc_onenand_data->cs, err);
return;
}
 
-- 
1.7.8.6

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/7] ARM: omap2: gpmc-nand: Print something useful on CS request failure

2013-02-09 Thread Ezequiel Garcia 
If CS request fails the current error message is rather unhelpful.
Fix it by printing the failing chip select and the error code.

Signed-off-by: Ezequiel Garcia 
---
 arch/arm/mach-omap2/gpmc-nand.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index afc1e8c..e50e438 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -122,7 +122,8 @@ int gpmc_nand_init(struct omap_nand_platform_data 
*gpmc_nand_data,
err = gpmc_cs_request(gpmc_nand_data->cs, NAND_IO_SIZE,
(unsigned long *)&gpmc_nand_resource[0].start);
if (err < 0) {
-   dev_err(dev, "Cannot request GPMC CS\n");
+   dev_err(dev, "Cannot request GPMC CS %d, error %d\n",
+   gpmc_nand_data->cs, err);
return err;
}
 
-- 
1.7.8.6

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/7] ARM: omap2: gpmc: Remove unused gpmc_round_ns_to_ticks() function

2013-02-09 Thread Ezequiel Garcia 
Signed-off-by: Ezequiel Garcia 
---
 arch/arm/mach-omap2/gpmc.c |7 ---
 1 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index ffe3e1e..bd3bc93 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -230,13 +230,6 @@ unsigned int gpmc_ticks_to_ns(unsigned int ticks)
return ticks * gpmc_get_fclk_period() / 1000;
 }
 
-static unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns)
-{
-   unsigned long ticks = gpmc_ns_to_ticks(time_ns);
-
-   return ticks * gpmc_get_fclk_period() / 1000;
-}
-
 static unsigned int gpmc_ticks_to_ps(unsigned int ticks)
 {
return ticks * gpmc_get_fclk_period();
-- 
1.7.8.6

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/7] ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value

2013-02-09 Thread Ezequiel Garcia 
Fix gpmc_cs_reserved() so it returns 0 if the chip select
is available (not reserved) or an error otherwise.
This allows to use the return value directly and return a proper error code.

Signed-off-by: Ezequiel Garcia 
---
 arch/arm/mach-omap2/gpmc.c |   12 
 1 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index bd3bc93..604c1eb 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -452,12 +452,16 @@ static int gpmc_cs_set_reserved(int cs, int reserved)
return 0;
 }
 
+/* Returns 0 if CS is available (not reseverd) or an error otherwise */
 static int gpmc_cs_reserved(int cs)
 {
if (cs > GPMC_CS_NUM)
return -ENODEV;
 
-   return gpmc_cs_map & (1 << cs);
+   if (gpmc_cs_map & (1 << cs))
+   return -EBUSY;
+
+   return 0;
 }
 
 static unsigned long gpmc_mem_align(unsigned long size)
@@ -516,10 +520,10 @@ int gpmc_cs_request(int cs, unsigned long size, unsigned 
long *base)
return -ENOMEM;
 
spin_lock(&gpmc_mem_lock);
-   if (gpmc_cs_reserved(cs)) {
-   r = -EBUSY;
+   r = gpmc_cs_reserved(cs);
+   if (r < 0)
goto out;
-   }
+
if (gpmc_cs_mem_enabled(cs))
r = adjust_resource(res, res->start & ~(size - 1), size);
if (r < 0)
-- 
1.7.8.6

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/7] ARM: omap2: GPMC cleanup

2013-02-09 Thread Ezequiel Garcia 
This patchset is a small cleanup consisting in:
 * mark some functions as 'static' when appropriate
 * remove an unused function from gpmc.c
 * improve error messages when a CS request fails
 * migrate to dev_err and dev_warn

It has been tested on a IGEP v2 board with OneNAND,
which means the gpmc-nand patch is tested by compilation only.

Altough these patchset is almost trivial,
any feedback or testing is more than welcome.

Ezequiel Garcia (7):
  ARM: omap2: gpmc: Mark local scoped functions static
  ARM: omap2: gpmc: Remove unused gpmc_round_ns_to_ticks() function
  ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value
  ARM: omap2: gpmc-nand: Print something useful on CS request failure
  ARM: omap2: gpmc-onenand: Print something useful on CS request failure
  ARM: omap2: gpmc-onenand: Replace pr_err() with dev_err()
  ARM: omap2: gpmc-onenand: Replace printk KERN_ERR with dev_warn()

 arch/arm/mach-omap2/gpmc-nand.c|3 ++-
 arch/arm/mach-omap2/gpmc-onenand.c |8 +---
 arch/arm/mach-omap2/gpmc.c |   31 ++-
 arch/arm/mach-omap2/gpmc.h |7 ---
 4 files changed, 21 insertions(+), 28 deletions(-)

-- 
1.7.8.6

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/7] ARM: omap2: gpmc: Mark local scoped functions static

2013-02-09 Thread Ezequiel Garcia 
This patch marks a bunch of functions that are local
to gpmc.c file only as static.

Signed-off-by: Ezequiel Garcia 
---
 arch/arm/mach-omap2/gpmc.c |   14 +++---
 arch/arm/mach-omap2/gpmc.h |7 ---
 2 files changed, 7 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 1e8bcb4..ffe3e1e 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -181,7 +181,7 @@ void gpmc_cs_write_reg(int cs, int idx, u32 val)
__raw_writel(val, reg_addr);
 }
 
-u32 gpmc_cs_read_reg(int cs, int idx)
+static u32 gpmc_cs_read_reg(int cs, int idx)
 {
void __iomem *reg_addr;
 
@@ -190,7 +190,7 @@ u32 gpmc_cs_read_reg(int cs, int idx)
 }
 
 /* TODO: Add support for gpmc_fck to clock framework and use it */
-unsigned long gpmc_get_fclk_period(void)
+static unsigned long gpmc_get_fclk_period(void)
 {
unsigned long rate = clk_get_rate(gpmc_l3_clk);
 
@@ -205,7 +205,7 @@ unsigned long gpmc_get_fclk_period(void)
return rate;
 }
 
-unsigned int gpmc_ns_to_ticks(unsigned int time_ns)
+static unsigned int gpmc_ns_to_ticks(unsigned int time_ns)
 {
unsigned long tick_ps;
 
@@ -215,7 +215,7 @@ unsigned int gpmc_ns_to_ticks(unsigned int time_ns)
return (time_ns * 1000 + tick_ps - 1) / tick_ps;
 }
 
-unsigned int gpmc_ps_to_ticks(unsigned int time_ps)
+static unsigned int gpmc_ps_to_ticks(unsigned int time_ps)
 {
unsigned long tick_ps;
 
@@ -230,7 +230,7 @@ unsigned int gpmc_ticks_to_ns(unsigned int ticks)
return ticks * gpmc_get_fclk_period() / 1000;
 }
 
-unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns)
+static unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns)
 {
unsigned long ticks = gpmc_ns_to_ticks(time_ns);
 
@@ -448,7 +448,7 @@ static int gpmc_cs_mem_enabled(int cs)
return l & GPMC_CONFIG7_CSVALID;
 }
 
-int gpmc_cs_set_reserved(int cs, int reserved)
+static int gpmc_cs_set_reserved(int cs, int reserved)
 {
if (cs > GPMC_CS_NUM)
return -ENODEV;
@@ -459,7 +459,7 @@ int gpmc_cs_set_reserved(int cs, int reserved)
return 0;
 }
 
-int gpmc_cs_reserved(int cs)
+static int gpmc_cs_reserved(int cs)
 {
if (cs > GPMC_CS_NUM)
return -ENODEV;
diff --git a/arch/arm/mach-omap2/gpmc.h b/arch/arm/mach-omap2/gpmc.h
index fe0a844..b79e35c 100644
--- a/arch/arm/mach-omap2/gpmc.h
+++ b/arch/arm/mach-omap2/gpmc.h
@@ -195,20 +195,13 @@ extern int gpmc_calc_timings(struct gpmc_timings *gpmc_t,
 extern void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs);
 extern int gpmc_get_client_irq(unsigned irq_config);
 
-extern unsigned int gpmc_ns_to_ticks(unsigned int time_ns);
-extern unsigned int gpmc_ps_to_ticks(unsigned int time_ps);
 extern unsigned int gpmc_ticks_to_ns(unsigned int ticks);
-extern unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns);
-extern unsigned long gpmc_get_fclk_period(void);
 
 extern void gpmc_cs_write_reg(int cs, int idx, u32 val);
-extern u32 gpmc_cs_read_reg(int cs, int idx);
 extern int gpmc_calc_divider(unsigned int sync_clk);
 extern int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t);
 extern int gpmc_cs_request(int cs, unsigned long size, unsigned long *base);
 extern void gpmc_cs_free(int cs);
-extern int gpmc_cs_set_reserved(int cs, int reserved);
-extern int gpmc_cs_reserved(int cs);
 extern void omap3_gpmc_save_context(void);
 extern void omap3_gpmc_restore_context(void);
 extern int gpmc_cs_configure(int cs, int cmd, int wval);
-- 
1.7.8.6

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

2013-02-09 Thread Sekhar Nori 
Hi Matt,

This version introduces build/bisect issues.

On 2/1/2013 11:52 PM, Matt Porter wrote:
> Move mach-davinci/dma.c to common/edma.c so it can be used
> by OMAP (specifically AM33xx) as well.
> 
> Signed-off-by: Matt Porter 
> Acked-by: Sekhar Nori 

> diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/common/edma.c

> @@ -25,7 +25,7 @@
>  #include 
>  #include 
>  
> -#include 
> +#include 

>  /*---*/
> +static int edma_of_read_u32_to_s8_array(const struct device_node *np,
> +  const char *propname, s8 *out_values,
> +  size_t sz)
> +{
> + int ret;
> +
> + ret = of_property_read_u8_array(np, propname, out_values, sz);

This needs  to be included in this file.

> +static int edma_xbar_event_map(struct device *dev,
> +struct device_node *node,
> +struct edma_soc_info *pdata, int len)
> +{
> + int ret = 0;
> + int i;
> + struct resource res;
> + void *xbar;
> + const s16 (*xbar_chans)[2];
> + u32 shift, offset, mux;
> +
> + xbar_chans = devm_kzalloc(dev,
> +   len/sizeof(s16) + 2*sizeof(s16),
> +   GFP_KERNEL);
> + if (!xbar_chans)
> + return -ENOMEM;
> +
> + ret = of_address_to_resource(node, 1, &res);

of_address_to_resource() needs 

> + if (IS_ERR_VALUE(ret))

This needs 

> + return -EIO;
> +
> + xbar = devm_ioremap(dev, res.start, resource_size(&res));
> + if (!xbar)
> + return -ENOMEM;
> +
> + ret = edma_of_read_u32_to_s16_array(node,
> + "ti,edma-xbar-event-map",
> + (s16 *)xbar_chans,
> + len/sizeof(u32));
> + if (IS_ERR_VALUE(ret))
> + return -EIO;
> +
> + for (i = 0; xbar_chans[i][0] != -1; i++) {
> + shift = (xbar_chans[i][1] % 4) * 8;
> + offset = xbar_chans[i][1] >> 2;
> + offset <<= 2;
> + mux = readl((void *)((u32)xbar + offset));
> + mux &= ~(0xff << shift);
> + mux |= xbar_chans[i][0] << shift;
> + writel(mux, (void *)((u32)xbar + offset));
> + }
> +
> + pdata->xbar_chans = xbar_chans;

There is no member xbar_chans ATM. It seems to be introduced in 03/10.

> +
> +static struct of_dma_filter_info edma_filter_info = {

of_dma_filter_info needs .

> + .filter_fn = edma_filter_fn,

edma_filter_fn needs 

BTW, I am not sure if you really intended to introduce EDMA DT support
in this patch. I thought 1/10 was supposed to just move EDMA private API
to a common place. If you really want to introduce DT support as well,
that should be noted in the description. I think it is better done in a
later patch.

> diff --git a/sound/soc/davinci/davinci-sffsdr.c 
> b/sound/soc/davinci/davinci-sffsdr.c

> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -28,12 +29,14 @@
>  #include 
>  #endif
>  
> -#include 
>  
>  #include "../codecs/pcm3008.h"
>  #include "davinci-pcm.h"
>  #include "davinci-i2s.h"
>  
> +#define DAVINCI_DMA_MCBSP_TX 2
> +#define DAVINCI_DMA_MCBSP_RX 3
> +
>  /*
>   * CLKX and CLKR are the inputs for the Sample Rate Generator.
>   * FSX and FSR are outputs, driven by the sample Rate Generator.
> @@ -124,7 +127,7 @@ static struct resource sffsdr_snd_resources[] = {
>  
>  static struct evm_snd_platform_data sffsdr_snd_data = {
>   .tx_dma_ch  = DAVINCI_DMA_MCBSP_TX,
> - .rx_dma_ch  = DAVINCI_DMA_MCBSP_RX,

> + .rx_dma_ch  = DAVINCI_DMA_MCBAP_RX,

Typo here. Should be DAVINCI_DMA_MCBSP_RX. Unfortunately
davinci-sffsdr.c seems to be broken already.

Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] ARM: OMAP2+: Prevent potential crash if GPMC probe fails

2013-02-09 Thread Ezequiel Garcia 
On Fri, Feb 08, 2013 at 04:56:19PM -0600, Jon Hunter wrote:
> 
> On 02/01/2013 04:08 PM, Tony Lindgren wrote:
> > * Jon Hunter  [130201 08:42]:
> >> If the GPMC probe fails, devices that use the GPMC (such as ethernet
> >> chips, flash memories, etc) can still allocate a GPMC chip-select and
> >> register the device. On the OMAP2420 H4 board, this was causing the
> >> kernel to crash after the gpmc probe failed and the board attempted
> >> to start networking. Prevent this by marking all the chip-selects as
> >> reserved by default and only make them available for devices to request
> >> if the GPMC probe succeeds.
> > 
> > Thanks applying into omap-for-v3.9/gpmc.
> 
> Hi Tony, this one appears to be merged incorrectly. The unreserve ended 
> up in the gpmc_calc_timings() function. Here is a patch to fix.
> 
> Cheers
> Jon
> 
> From ebc0613fb5a70f36fcb119cbe58724f9b442903a Mon Sep 17 00:00:00 2001
> From: Jon Hunter 
> Date: Fri, 8 Feb 2013 16:48:25 -0600
> Subject: [PATCH] ARM: OMAP2+: Fix-up gpmc merge error
> 
> Commit "ARM: OMAP2+: Prevent potential crash if GPMC probe fails" added
> code to ensure that GPMC chip-selects could not be requested until the
> device probe was successful. The chip-selects should have been
> unreserved at the end of the probe function, but the code to unreserve
> them appears to have ended up in the gpmc_calc_timings() function and
> hence, this is causing problems requesting chip-selects. Fix this merge
> error by unreserving the chip-selects at the end of the probe, but
> before we call the gpmc child probe functions (for device-tree) which
> request a chip-select.
> 
> Signed-off-by: Jon Hunter 

Without this patch, GPMC is currently broken on my igep board setup,
if initialized through a device tree.

Tested-by: Ezequiel Garcia 

Thanks a lot for the fix,

-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] drivers/gpio: using common order: let 'static const' instead of 'const static'

2013-02-09 Thread Grant Likely 
On Wed, 6 Feb 2013 16:17:24 +0530, Santosh Shilimkar  
wrote:
> On Wednesday 06 February 2013 04:14 PM, Chen Gang wrote:
> >
> >'const static ' is not a common order, better to use 'static const' 
> > instead.
> >
> > building:
> >make EXTRA_CFLAGS=-W ARCH=arm
> >
> >drivers/gpio/gpio-omap.c:1479:
> >  warning: 'static' is not at beginning of declaration
> >drivers/gpio/gpio-omap.c:1485:
> >  warning: 'static' is not at beginning of declaration
> >drivers/gpio/gpio-omap.c:1491:
> >  warning: 'static' is not at beginning of declaration
> >
> >
> > Signed-off-by: Chen Gang 
> > Cc: Santosh Shilimkar 
> > ---
> Thanks for update.
> Acked-by: Santosh Shilimkar 

Applied, thanks.

g.

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] gpio: twl4030: Cache the direction and output states in private data

2013-02-09 Thread Grant Likely 
On Thu, 10 Jan 2013 14:09:35 +0100, Peter Ujfalusi  
wrote:
> Hi Linus,
> 
> On 01/10/2013 11:41 AM, Linus Walleij wrote:
> > On Thu, Dec 20, 2012 at 10:44 AM, Peter Ujfalusi  
> > wrote:
> > 
> >> Use more coherent locking in the driver. Use bitfield to store the GPIO
> >> direction and if the pin is configured as output store the status also in a
> >> bitfiled.
> >> In this way we can just look at these bitfields when we need information
> >> about the pin status and only reach out to the chip when it is needed.
> >>
> >> Signed-off-by: Peter Ujfalusi 
> >> Acked-by: Linus Walleij 
> >> ---
> >> Hi Grant,
> >>
> >> Changes sicne v2:
> >> - Fixed the mutex_unlock found by Michael.
> >> - Removed the debug prints addedd by v2 patch (remains from debugging)
> >> - Removed one blank line between includes and the first comment section.
> > 
> > Sorry Peter this must have been missed somehow.
> > 
> > This does not apply to the current v3.8-rc3, could you respin
> > this on top of Torvalds' tree?
> 
> Grant applied the patch which this one depends on:
> [1] https://patchwork.kernel.org/patch/1844511/

I had applied it, never pushed the tree out because I wasn't able to
test my kernel tree for a couple of weeks due to travel. I saw the patch
in Linus' tree and pulled it out of mine before I pushed it out.

g.

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DT GPMC SRAM and NOR flash support ?

2013-02-09 Thread Ezequiel Garcia 
Hi Mark,

On Thu, Feb 7, 2013 at 6:51 AM, Mark Jackson  wrote:
> Okay ... I have made some progress, but it's not ideal.
>
> Currently I've hacked the GPMC DT driver (gpmc_probe_dt(), etc) so it now 
> handles setting up the
> chip selects and timings for NOR devices, e.g.
>
> gpmc: gpmc@5000 {
> status = "okay";
> ranges = <0 0 0x0800 0x0800>;   /* CS0: NOR 
> 16M */
>
> nor@0,0 {
> compatible = "spansion,s29gl064n90t", 
> "cfi-flash";
> reg = <0 0 0>;
> bank-width = <2>;
>
> gpmc,sync-clk = <0>;
> gpmc,cs-on = <10>;
> gpmc,cs-rd-off = <150>;
> gpmc,cs-wr-off = <150>;
> gpmc,adv-on = <10>;
> gpmc,adv-rd-off = <10>;
> gpmc,adv-wr-off = <10>;
> gpmc,oe-on = <30>;
> gpmc,oe-off = <150>;
> gpmc,we-on = <30>;
> gpmc,we-off = <150>;
> gpmc,rd-cycle = <150>;
> gpmc,wr-cycle = <150>;
> gpmc,access = <130>;
> gpmc,page-burst-access = <10>;
> gpmc,cycle2cycle-diff = <1>;
> gpmc,cycle2cycle-same = <1>;
> gpmc,cycle2cycle-delay = <10>;
> gpmc,wr-data-mux-bus = <60>;
> };
> };
>
> But the physmap driver (of_flash_probe()) is unable to use this information.  
> It seems that although
> I can call of_flash_probe() from my NOR setup code, the platform_device being 
> reference is wrong.
>
> The platform_device passed to my gpmc_probe_nor_child() routine from 
> gpmc_probe_dt() points to my
> gpmc entry (above), but the physmap probe requires its own DT entry (rather 
> than a node child such
> as my NOR entry with the GPMC device entry).
>

I think you can call something like:

of_platform_populate();

On your GPMC node and have the child initialize.
This way you don't need to have separate cfi-flash compatible nodes,
you can have them as childs.

Although I'm not sure this is a sane approach, I'm almost sure this should work.

-- 
Ezequiel
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Latest additional build warnings

2013-02-09 Thread Russell King - ARM Linux 
On Tue, Feb 05, 2013 at 02:22:18PM +, Russell King - ARM Linux wrote:
> arch/arm/mach-omap2/hwspinlock.c:60:1: warning: data definition has no type 
> or storage class
> arch/arm/mach-omap2/hwspinlock.c:60:1: warning: type defaults to 'int' in 
> declaration of 'omap_postcore_initcall'
> arch/arm/mach-omap2/hwspinlock.c:60:1: warning: parameter names (without 
> types) in function declaration
> arch/arm/mach-omap2/hwspinlock.c:31:122: warning: 'hwspinlocks_init' defined 
> but not used

I'm still seeing the above in the build of Friday's merge.  I'm also
seeing additional warnings in the randconfig similar to the above for
arch/arm/mach-omap2/omap-iommu.c.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver

2013-02-09 Thread Russell King - ARM Linux 
On Wed, Feb 06, 2013 at 03:03:16PM -0600, Jon Hunter wrote:
> @@ -673,7 +702,7 @@ static int omap_dma_init(void)
>  {
>   int rc = platform_driver_register(&omap_dma_driver);
>  
> - if (rc == 0) {
> + if ((rc == 0) && (!of_have_populated_dt())) {

Looks good, the worst I can find is this over-use of parens...
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/4] mtd: devices: elm: Low power transition support

2013-02-09 Thread Russell King - ARM Linux 
On Thu, Feb 07, 2013 at 06:06:57PM +0530, Philip Avinash wrote:
> +static int elm_suspend(struct device *dev)
> +{
> + struct elm_info *info = dev_get_drvdata(dev);
> + wait_queue_head_t wq;
> + DECLARE_WAITQUEUE(wait, current);
> +
> + init_waitqueue_head(&wq);
> + while (1) {
> + /* Make sure that ELM not running */
> + if (info->idle) {
> + add_wait_queue(&wq, &wait);
> + schedule();
> + remove_wait_queue(&wq, &wait);
> + } else {
> + break;
> + }
> + }

The above code looks really wrong - it will just spin endlessly with the
waitqueues doing nothing useful.  What are you trying to do here?
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html