* [PATCH 2/2] OMAP3: beagle xm: enable upto 800MHz OPP
From: Premi, Sanjeev @ 2011-01-06 14:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D25CB18.3080904@ti.com>
> -----Original Message-----
> From: Menon, Nishanth
> Sent: Thursday, January 06, 2011 7:31 PM
> To: Premi, Sanjeev
> Cc: Koen Kooi; Hilman, Kevin; l-o; l-a; Tony
> Subject: Re: [PATCH 2/2] OMAP3: beagle xm: enable upto 800MHz OPP
>
> Premi, Sanjeev had written, on 01/06/2011 07:58 AM, the following:
> [..]
> > Some of the patches generic that Koen attached are based on my
> > submissions. As part of migration to 2.6.37, I am in process of
> > validating them on internal integration tree. Will post them
> > soon... may be end of tomorrow.
> >
> > I will be testing them on OMAP3EVM.
> Sure. please do post them to l-o and cc l-a - I suppose until
> then, they
> are unofficial if they are lying around in some private tree(even if
> viewable over internet ;) ).
That's what I meant by submitting :)
My plans were tomorrow/MON - wasn't expecting this thread to happen!!
~sanjeev
>
> --
> Regards,
> Nishanth Menon
>
^ permalink raw reply
* [PATCH 1/2] stackprotector: add stack smashing protector generic implementation
From: Russell King - ARM Linux @ 2011-01-06 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D25CEB9.7090205@st.com>
On Thu, Jan 06, 2011 at 03:16:25PM +0100, Carmelo AMOROSO wrote:
> Well, SH (in CC) does not have this support. Indeed we posted it
> initially to linux-sh only. We got useful feedback from Paul, Mike and
> Nicolas suggesting to promote the ARM/SH solution based on the global
> __stack_chk_guard variable as a generic solution for all other
> architectures. This is why I thought to post to the LKML instead of each
> linux-<arch> list.
Have you thought about posting it to _the_ linux-arch list?
^ permalink raw reply
* [PATCH 1/2] stackprotector: add stack smashing protector generic implementation
From: Carmelo AMOROSO @ 2011-01-06 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106093940.GA31708@n2100.arm.linux.org.uk>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 1/6/2011 10:39 AM, Russell King - ARM Linux wrote:
> On Wed, Jan 05, 2011 at 12:59:18PM +0100, Carmelo AMOROSO wrote:
> > Is someone interested into this stuff ?
>
> Looking at the CC list, you're asking the people who already have the
> support in the kernel. I suspect they don't have that much of an
> interest in it.
>
> Maybe you should try asking other architecture maintainers who don't
> support this yet? Not every architecture maintainer is subscribed to,
> or reads LKML...
>
Hi Russel, thanks for your feedback.
Well, SH (in CC) does not have this support. Indeed we posted it
initially to linux-sh only. We got useful feedback from Paul, Mike and
Nicolas suggesting to promote the ARM/SH solution based on the global
__stack_chk_guard variable as a generic solution for all other
architectures. This is why I thought to post to the LKML instead of each
linux-<arch> list.
The code is able to detect if the arch implementation is based on the
global (if so the generic implementation should work cleanly), otherwise
it will fail to compile when trying to include the
linux/asm/stackprotector.h. This is an easy way to detect the lack of an
arch specific implementation (but likely only x86 needs it... I don't know).
So the idea is to use the ARM code as generic's one (tested on SH
kernel). Mike Frysinger volunteered to try on blackfin for example.
cheers
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0lzrkACgkQoRq/3BrK1s/JhACdERr4TFBaGmf4XuQEUA/9X/Kt
lz4An0fctncE+n9fhHvvZEbIZEilJKNO
=5yFm
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH 2/2] OMAP3: beagle xm: enable upto 800MHz OPP
From: Nishanth Menon @ 2011-01-06 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <FAF33A33-767F-45DD-B0E4-1C173342CFB1@beagleboard.org>
Koen Kooi had written, on 01/06/2011 08:01 AM, the following:
> Op 6 jan 2011, om 14:44 heeft Nishanth Menon het volgende geschreven:
>
>> Koen Kooi had written, on 01/06/2011 07:00 AM, the following:
>>> Op 6 jan 2011, om 13:24 heeft Nishanth Menon het volgende geschreven:
>>>> Kevin Hilman wrote, on 01/05/2011 05:28 PM:
>>>>> Nishanth Menon<nm@ti.com> writes:
>>>>>
>>>>>> Beagle XM uses 3730 and the board design allows enabling 800MHz and 1GHz
>>>>>> OPPs. However, We need Smart reflex class 1.5 and ABB to enable 1GHz safely.
>>>>>> For the moment, we tweak the default table to allow for 800Mhz OPP usage.
>>>>> Isn't this common to any board using 3730 (or 3630?)
>>>> no it is not. only certain boards are capable of higher frequencies - there is a procedure called PDN analysis and vmin search that needs to be performed to guarentee this.
>>> What about the "new" 3530s that can run at 720MHz? Those have been speed binned and given a different SKU. I'm using the attached 4 patches (Tony master + beagle patches _+ dvfs: http://dominion.thruhere.net/git/cgit.cgi/linux-omap/log/?h=koen/beagle-next) on my beagle C4 and overo tide to get 720MHz. They don't really work:
>> for 3530, keep in mind that not *all* boards can support 720MHz (esp the old 3430 boards, like my poor SDP3430).
>
> Right, that's why it's a different SKU and we can probe for it, see the 0002 patch I attached.
please discuss with Sanjeev on patch ownership and post required series
using git send-email :)
>> since we consider 3530 as 3430 as well, add a default disabled 720MHz OPP in the 3430 table
>
> That's what 0001 does :)
>
>> and enable it:
>> a) if this has anything to do with board behavior (which, unlike 36xx, I dont think is the case for 35xx), enable similar to this patch on the required boards on a need basis (e.g. based on board rev)
>
> That's what 0003 and 0004 are doing for overo and beagle
then it is wrong. see below
>
>> b) if this is a silicon behavior, then, you should modify the omap3_opp_init to ensure that for the right silicon this is enabled (e.g. only for 3530 rev X onwards or something similar) - but you will need some way to detect it in s/w (not through bootargs please!)
>
> See 0002, it does it as an omap feature.
if it is OMAP feature, you should be doing this in omap3_opp_init
instead of each and every board file! (basically patches 3 and 4 are
wrong!).
>
>>> root at usrp-e1xx:~# cpufreq-set -f 720000
>>> [ 104.976318] platform iva.0: omap_voltage_scale: Already at the requestedrate 430000000
>>> [ 104.986236] platform mpu.0: omap_voltage_scale: Already at the requestedrate 600000000
>>> [ 104.996032] platform iva.0: omap_voltage_scale: Already at the requestedrate 430000000
>>> [ 105.006408] platform mpu.0: omap_voltage_scale: Already at the requestedrate 600000000
>> This is coz we dont have 720MHz and max enabled freq is 600MHz so it falls back to that freq.
>
> Even after 0001 adds it to the table and 0004 enables it?
a) have you checked if the clock framework has the required bits?
b) voltage layer maintains it's own voltage table as well (surprise
:D).. so you need to add to that as well!
see the secret table in arch/arm/mach-omap2/voltage.c - I prefer all
voltage and frequency information to be in a centralized location to
prevent mess like this from happening, but sorry we gotta merge these
two tables at some point ahead IMHO, we are not there yet.
--
Regards,
Nishanth Menon
^ permalink raw reply
* [patch v2] mtd: pxa3xx_nand: NULL dereference in pxa3xx_nand_probe
From: Dan Carpenter @ 2011-01-06 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294321502.2218.5.camel@sven>
"info->cmdset" gets dereferenced in __readid() so it needs to be
initialized earlier in the function. This bug was introduced in
18c81b1828f8 "mtd: pxa3xx_nand: remove the flash info in driver
structure".
Cc: stable at kernel.org [2.6.37+]
Reported-and-tested-by: Sven Neumann <s.neumann@raumfeld.com>
Signed-off-by: Dan Carpenter <error27@gmail.com>
---
v2: changed the commit text. added stable at kernel.org and a reported-by tag.
diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
index 17f8518..ea2c288 100644
--- a/drivers/mtd/nand/pxa3xx_nand.c
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -885,6 +885,7 @@ static int pxa3xx_nand_detect_config(struct pxa3xx_nand_info *info)
/* set info fields needed to __readid */
info->read_id_bytes = (info->page_size == 2048) ? 4 : 2;
info->reg_ndcr = ndcr;
+ info->cmdset = &default_cmdset;
if (__readid(info, &id))
return -ENODEV;
@@ -915,7 +916,6 @@ static int pxa3xx_nand_detect_config(struct pxa3xx_nand_info *info)
info->ndtr0cs0 = nand_readl(info, NDTR0CS0);
info->ndtr1cs0 = nand_readl(info, NDTR1CS0);
- info->cmdset = &default_cmdset;
return 0;
}
^ permalink raw reply related
* [PATCH 2/2] OMAP3: beagle xm: enable upto 800MHz OPP
From: Koen Kooi @ 2011-01-06 14:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D25C745.7060600@ti.com>
Op 6 jan 2011, om 14:44 heeft Nishanth Menon het volgende geschreven:
> Koen Kooi had written, on 01/06/2011 07:00 AM, the following:
>> Op 6 jan 2011, om 13:24 heeft Nishanth Menon het volgende geschreven:
>>> Kevin Hilman wrote, on 01/05/2011 05:28 PM:
>>>> Nishanth Menon<nm@ti.com> writes:
>>>>
>>>>> Beagle XM uses 3730 and the board design allows enabling 800MHz and 1GHz
>>>>> OPPs. However, We need Smart reflex class 1.5 and ABB to enable 1GHz safely.
>>>>> For the moment, we tweak the default table to allow for 800Mhz OPP usage.
>>>> Isn't this common to any board using 3730 (or 3630?)
>>> no it is not. only certain boards are capable of higher frequencies - there is a procedure called PDN analysis and vmin search that needs to be performed to guarentee this.
>> What about the "new" 3530s that can run at 720MHz? Those have been speed binned and given a different SKU. I'm using the attached 4 patches (Tony master + beagle patches _+ dvfs: http://dominion.thruhere.net/git/cgit.cgi/linux-omap/log/?h=koen/beagle-next) on my beagle C4 and overo tide to get 720MHz. They don't really work:
> for 3530, keep in mind that not *all* boards can support 720MHz (esp the old 3430 boards, like my poor SDP3430).
Right, that's why it's a different SKU and we can probe for it, see the 0002 patch I attached.
> since we consider 3530 as 3430 as well, add a default disabled 720MHz OPP in the 3430 table
That's what 0001 does :)
> and enable it:
> a) if this has anything to do with board behavior (which, unlike 36xx, I dont think is the case for 35xx), enable similar to this patch on the required boards on a need basis (e.g. based on board rev)
That's what 0003 and 0004 are doing for overo and beagle
> b) if this is a silicon behavior, then, you should modify the omap3_opp_init to ensure that for the right silicon this is enabled (e.g. only for 3530 rev X onwards or something similar) - but you will need some way to detect it in s/w (not through bootargs please!)
See 0002, it does it as an omap feature.
>
>> root at usrp-e1xx:~# cpufreq-set -f 720000
>> [ 104.976318] platform iva.0: omap_voltage_scale: Already at the requestedrate 430000000
>> [ 104.986236] platform mpu.0: omap_voltage_scale: Already at the requestedrate 600000000
>> [ 104.996032] platform iva.0: omap_voltage_scale: Already at the requestedrate 430000000
>> [ 105.006408] platform mpu.0: omap_voltage_scale: Already at the requestedrate 600000000
> This is coz we dont have 720MHz and max enabled freq is 600MHz so it falls back to that freq.
Even after 0001 adds it to the table and 0004 enables it?
regards,
Koen
^ permalink raw reply
* [PATCH 2/2] OMAP3: beagle xm: enable upto 800MHz OPP
From: Nishanth Menon @ 2011-01-06 14:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB5930248201A37@dbde02.ent.ti.com>
Premi, Sanjeev had written, on 01/06/2011 07:58 AM, the following:
[..]
> Some of the patches generic that Koen attached are based on my
> submissions. As part of migration to 2.6.37, I am in process of
> validating them on internal integration tree. Will post them
> soon... may be end of tomorrow.
>
> I will be testing them on OMAP3EVM.
Sure. please do post them to l-o and cc l-a - I suppose until then, they
are unofficial if they are lying around in some private tree(even if
viewable over internet ;) ).
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 2/2] OMAP3: beagle xm: enable upto 800MHz OPP
From: Premi, Sanjeev @ 2011-01-06 13:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D25C745.7060600@ti.com>
> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org
> [mailto:linux-omap-owner at vger.kernel.org] On Behalf Of Menon, Nishanth
> Sent: Thursday, January 06, 2011 7:15 PM
> To: Koen Kooi
> Cc: Hilman, Kevin; l-o; l-a; Tony
> Subject: Re: [PATCH 2/2] OMAP3: beagle xm: enable upto 800MHz OPP
>
> Koen Kooi had written, on 01/06/2011 07:00 AM, the following:
> > Op 6 jan 2011, om 13:24 heeft Nishanth Menon het volgende
> geschreven:
> >
> >> Kevin Hilman wrote, on 01/05/2011 05:28 PM:
> >>> Nishanth Menon<nm@ti.com> writes:
> >>>
> >>>> Beagle XM uses 3730 and the board design allows enabling
> 800MHz and 1GHz
> >>>> OPPs. However, We need Smart reflex class 1.5 and ABB to
> enable 1GHz safely.
> >>>> For the moment, we tweak the default table to allow for
> 800Mhz OPP usage.
> >>> Isn't this common to any board using 3730 (or 3630?)
> >> no it is not. only certain boards are capable of higher
> frequencies - there is a procedure called PDN analysis and
> vmin search that needs to be performed to guarentee this.
> >
> > What about the "new" 3530s that can run at 720MHz? Those
> have been speed binned and given a different SKU. I'm using
> the attached 4 patches (Tony master + beagle patches _+ dvfs:
> http://dominion.thruhere.net/git/cgit.cgi/linux-omap/log/?h=ko
> en/beagle-next) on my beagle C4 and overo tide to get 720MHz.
> They don't really work:
> for 3530, keep in mind that not *all* boards can support
> 720MHz (esp the
> old 3430 boards, like my poor SDP3430).
> since we consider 3530 as 3430 as well, add a default disabled 720MHz
> OPP in the 3430 table and enable it:
> a) if this has anything to do with board behavior (which,
> unlike 36xx, I
> dont think is the case for 35xx), enable similar to this patch on the
> required boards on a need basis (e.g. based on board rev)
> b) if this is a silicon behavior, then, you should modify the
> omap3_opp_init to ensure that for the right silicon this is enabled
> (e.g. only for 3530 rev X onwards or something similar) - but
> you will
> need some way to detect it in s/w (not through bootargs please!)
Nishanth,
Some of the patches generic that Koen attached are based on my
submissions. As part of migration to 2.6.37, I am in process of
validating them on internal integration tree. Will post them
soon... may be end of tomorrow.
I will be testing them on OMAP3EVM.
~sanjeev
[snip]...[snip]
^ permalink raw reply
* [PATCH] arm: mach-omap2: pm: cleanup !CONFIG_SUSPEND handling
From: Russell King - ARM Linux @ 2011-01-06 13:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <BC214410FD04D84F9079A62423659707164311@008-AM1MPN1-003.mgdnok.nokia.com>
On Thu, Jan 06, 2011 at 12:05:51PM +0000, aaro.koskinen at nokia.com wrote:
> Hi,
>
> Russell King - ARM Linux [linux at arm.linux.org.uk]:
> > > > -static struct platform_suspend_ops omap_pm_ops = {
> > > > - .begin = omap2_pm_begin,
> > > > - .enter = omap2_pm_enter,
> > > > - .end = omap2_pm_end,
> > > > - .valid = suspend_valid_only_mem,
> > > > +static const struct platform_suspend_ops omap_pm_ops[] = {
> > > > + {
> > > > + .begin = omap2_pm_begin,
> > > > + .enter = omap2_pm_enter,
> > > > + .end = omap2_pm_end,
> > > > + .valid = suspend_valid_only_mem,
> > > > + }
> > > > };
> > > > -#else
> > > > -static const struct platform_suspend_ops __initdata omap_pm_ops;
> > > > #endif /* CONFIG_SUSPEND */
> > > >
> > > > /* XXX This function should be shareable between OMAP2xxx and OMAP3 */
> > > > @@ -582,7 +582,7 @@ static int __init omap2_pm_init(void)
> > > > omap24xx_cpu_suspend_sz);
> > > > }
> > > >
> > > > - suspend_set_ops(&omap_pm_ops);
> > > > + suspend_set_ops(omap_pm_ops);
> >
> > Utterly yuck. Declaring it as a single element array just to avoid an
> > ifdef. That's worse than having an ifdef here.
>
> Why it is worse? Reducing the amount of different preprocessor branches will
> result in better compile test / static analysis coverage.
You're not doing that. You're just spreading the yuck around making it
far worse:
- in some header file
#ifndef CONFIG_FOO
#define omap_pm_ops NULL
#endif
- in lots of C files
#ifdef CONFIG_FOO
static const struct platform_suspend_ops omap_pm_ops[] = {
{
...
}
};
#endif
suspend_set_ops(omap_pm_ops);
So, rather than just having the full story in each file, it's spread
across two files. Not only that, but over time CONFIG_FOO will probably
change, and that will lead to compile errors.
You're creating an array just to be able to use the symbol as a pointer.
That's a hack rather than an elegant solution.
So no, your implementation is _NOT_ a sane approach.
I'm going to explicitly say NAK to your patch here and now. I really
don't like it one bit. It's a complete hack through and through, and
that hack is spread across many files.
^ permalink raw reply
* LCD driver
From: kalyan Alle @ 2011-01-06 13:52 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Plz let me know the location of LCD panel driver for OMAP3 EVM (AM37xx
EVM). Iam using the latest 2.6 kernel.
thanks
kalyan alle
^ permalink raw reply
* [patch] mtd: pxa3xx_nand: NULL dereference in pxa3xx_nand_probe
From: Sven Neumann @ 2011-01-06 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106124525.GA1717@bicker>
Hi Dan,
On Thu, 2011-01-06 at 15:45 +0300, Dan Carpenter wrote:
> Could you test this patch? I don't have an arm so I can't compile this.
Yes, this change fixes the boot problem for me. Thanks for the quick
help.
> This was introduced in 18c81b1828f8 "mtd: pxa3xx_nand: remove the flash
> info in driver structure"
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Tested-by: Sven Neumann <s.neumann@raumfeld.com>
> diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
> index 17f8518..ea2c288 100644
> --- a/drivers/mtd/nand/pxa3xx_nand.c
> +++ b/drivers/mtd/nand/pxa3xx_nand.c
> @@ -885,6 +885,7 @@ static int pxa3xx_nand_detect_config(struct pxa3xx_nand_info *info)
> /* set info fields needed to __readid */
> info->read_id_bytes = (info->page_size == 2048) ? 4 : 2;
> info->reg_ndcr = ndcr;
> + info->cmdset = &default_cmdset;
>
> if (__readid(info, &id))
> return -ENODEV;
> @@ -915,7 +916,6 @@ static int pxa3xx_nand_detect_config(struct pxa3xx_nand_info *info)
>
> info->ndtr0cs0 = nand_readl(info, NDTR0CS0);
> info->ndtr1cs0 = nand_readl(info, NDTR1CS0);
> - info->cmdset = &default_cmdset;
>
> return 0;
> }
>
^ permalink raw reply
* [PATCH 2/2] OMAP3: beagle xm: enable upto 800MHz OPP
From: Nishanth Menon @ 2011-01-06 13:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <579AA000-EB86-4DD3-B3B7-29F7A72E0415@beagleboard.org>
Koen Kooi had written, on 01/06/2011 07:00 AM, the following:
> Op 6 jan 2011, om 13:24 heeft Nishanth Menon het volgende geschreven:
>
>> Kevin Hilman wrote, on 01/05/2011 05:28 PM:
>>> Nishanth Menon<nm@ti.com> writes:
>>>
>>>> Beagle XM uses 3730 and the board design allows enabling 800MHz and 1GHz
>>>> OPPs. However, We need Smart reflex class 1.5 and ABB to enable 1GHz safely.
>>>> For the moment, we tweak the default table to allow for 800Mhz OPP usage.
>>> Isn't this common to any board using 3730 (or 3630?)
>> no it is not. only certain boards are capable of higher frequencies - there is a procedure called PDN analysis and vmin search that needs to be performed to guarentee this.
>
> What about the "new" 3530s that can run at 720MHz? Those have been speed binned and given a different SKU. I'm using the attached 4 patches (Tony master + beagle patches _+ dvfs: http://dominion.thruhere.net/git/cgit.cgi/linux-omap/log/?h=koen/beagle-next) on my beagle C4 and overo tide to get 720MHz. They don't really work:
for 3530, keep in mind that not *all* boards can support 720MHz (esp the
old 3430 boards, like my poor SDP3430).
since we consider 3530 as 3430 as well, add a default disabled 720MHz
OPP in the 3430 table and enable it:
a) if this has anything to do with board behavior (which, unlike 36xx, I
dont think is the case for 35xx), enable similar to this patch on the
required boards on a need basis (e.g. based on board rev)
b) if this is a silicon behavior, then, you should modify the
omap3_opp_init to ensure that for the right silicon this is enabled
(e.g. only for 3530 rev X onwards or something similar) - but you will
need some way to detect it in s/w (not through bootargs please!)
>
> root at usrp-e1xx:~# cpufreq-set -f 720000
> [ 104.976318] platform iva.0: omap_voltage_scale: Already at the requestedrate 430000000
> [ 104.986236] platform mpu.0: omap_voltage_scale: Already at the requestedrate 600000000
> [ 104.996032] platform iva.0: omap_voltage_scale: Already at the requestedrate 430000000
> [ 105.006408] platform mpu.0: omap_voltage_scale: Already at the requestedrate 600000000
This is coz we dont have 720MHz and max enabled freq is 600MHz so it
falls back to that freq.
>
> But:
>
> root at usrp-e1xx:~# dmesg | grep 720
> [ 0.000000] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp 720mhz )
> [ 0.000000] Kernel command line: console=ttyO2,115200n8 mpurate=720 vram=16M mem=99M at 0x80000000 mem=384M at 0x88000000 omapfb.mode=dvi:1024x768MR-24 at 60 omapfb.vram=0:8M,1:4M,2:4M omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
> [ 0.000000] overo_opp_init: 720MHz MPU OPPs enabled!
> [ 0.000000] Switched to new clocking rate (Crystal/Core/MPU): 26.0/224/720 MHz
>
>
> root at usrp-e1xx:~# cpufreq-info
> cpufrequtils 006: cpufreq-info (C) Dominik Brodowski 2004-2009
> Report errors and bugs to cpufreq at vger.kernel.org, please.
> analyzing CPU 0:
> driver: omap
> CPUs which run at the same hardware frequency: 0
> CPUs which need to have their frequency coordinated by software: 0
> maximum transition latency: 300 us.
> hardware limits: 125 MHz - 720 MHz
> available frequency steps: 125 MHz, 250 MHz, 500 MHz, 550 MHz, 600 MHz, 720 MHz
> available cpufreq governors: conservative, ondemand, userspace, powersave, performance
> current policy: frequency should be within 125 MHz and 720 MHz.
> The governor "userspace" may decide which speed to use
> within this range.
> current CPU frequency is 600 MHz (asserted by call to hardware).
> cpufreq stats: 125 MHz:0.00%, 250 MHz:0.00%, 500 MHz:0.00%, 550 MHz:0.00%, 600 MHz:100.00%, 720 MHz:0.00% (1)
>
> So how do I "properly" get 720MHz on those parts?
as discussed above.
--
Regards,
Nishanth Menon
^ permalink raw reply
* mxc: i2c register mapped twice?
From: Sascha Hauer @ 2011-01-06 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106122611.GA31718@shlinux1.ap.freescale.net>
On Thu, Jan 06, 2011 at 08:26:12PM +0800, Richard Zhao wrote:
> Hi Sascha,
>
> I just realized i2c registers are mapped twice. It's first static mapped at
> mx5x_io_desc and second mapped in driver.
> Drivers always feel happy to receive physical address in resource, and ioremap
> it itself. We might static map too many register regions in machine level?
> I'm sure it's not just i2c.
There are some devices which use the static mappings, like watchdog (for
reset), irq controller, gpt. Otherwise you are right. Feel free to cleanup
here if you think there are unnecessary mappings.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH] debug-8250: add a 32 bit mode
From: Jamie Iles @ 2011-01-06 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1290437502-2717-1-git-send-email-jamie@jamieiles.com>
On Mon, Nov 22, 2010 at 02:51:42PM +0000, Jamie Iles wrote:
> Some platforms such as picoChip picoXCell devices can only do 32 bit
> accesses to APB peripherals. If the platform defines
> DEBUG_8250_ACCESS_32 before including debug-8250.S in debug-macros.S
> then use 32-bit accesses for senduart, busyuart and waituart. If not
> defined, use 8-bit accesses.
>
> Signed-off-by: Jamie Iles <jamie@jamieiles.com>
Any opinions on this patch? I'm not entirely happy with the way I've
done it, but the alternatives are:
1. Create a new debug-8250-32bit.S with ldr/str
2. Move this into the platform
(1) involves duplicating the code and extra maintenance (although
debug-8250 hasn't been touched much) and (2) could be useful to other
platforms in the future.
I'm happy to rework in any form though.
Jamie
> ---
>
> Note: for the TTY support we also need
> [8250: add a UPIO_DWAPB32 for 32 bit accesses (v2)] at
> http://marc.info/?l=linux-serial&m=129043658715199&w=2
>
> arch/arm/include/asm/hardware/debug-8250.S | 21 ++++++++++++++++++---
> 1 files changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/include/asm/hardware/debug-8250.S b/arch/arm/include/asm/hardware/debug-8250.S
> index 22c6892..71f0839 100644
> --- a/arch/arm/include/asm/hardware/debug-8250.S
> +++ b/arch/arm/include/asm/hardware/debug-8250.S
> @@ -9,12 +9,26 @@
> */
> #include <linux/serial_reg.h>
>
> +/*
> + * Some platforms may only be able to perform 32-bit accesses to peripherals
> + * on an APB bus. If this is the case, define DEBUG_8250_ACCESS_32 before
> + * including this file.
> + */
> +#ifdef DEBUG_8250_ACCESS_32
> +# define ldr_uart ldr
> +# define str_uart str
> +#else /* DEBUG_8250_ACCESS_32 */
> +# define ldr_uart ldrb
> +# define str_uart strb
> +#endif /* DEBUG_8250_ACCESS_32 */
> +
> .macro senduart,rd,rx
> - strb \rd, [\rx, #UART_TX << UART_SHIFT]
> + and \rd, \rd, #0xff
> + str_uart \rd, [\rx, #UART_TX << UART_SHIFT]
> .endm
>
> .macro busyuart,rd,rx
> -1002: ldrb \rd, [\rx, #UART_LSR << UART_SHIFT]
> +1002: ldr_uart \rd, [\rx, #UART_LSR << UART_SHIFT]
> and \rd, \rd, #UART_LSR_TEMT | UART_LSR_THRE
> teq \rd, #UART_LSR_TEMT | UART_LSR_THRE
> bne 1002b
> @@ -22,7 +36,8 @@
>
> .macro waituart,rd,rx
> #ifdef FLOW_CONTROL
> -1001: ldrb \rd, [\rx, #UART_MSR << UART_SHIFT]
> +1001: ldr_uart \rd, [\rx, #UART_MSR << UART_SHIFT]
> + and \rd, \rd, 0xff
> tst \rd, #UART_MSR_CTS
> beq 1001b
> #endif
> --
> 1.7.2.3
>
^ permalink raw reply
* [PATCH 2/2] OMAP3: beagle xm: enable upto 800MHz OPP
From: Koen Kooi @ 2011-01-06 13:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D25B482.3080709@ti.com>
Op 6 jan 2011, om 13:24 heeft Nishanth Menon het volgende geschreven:
> Kevin Hilman wrote, on 01/05/2011 05:28 PM:
>> Nishanth Menon<nm@ti.com> writes:
>>
>>> Beagle XM uses 3730 and the board design allows enabling 800MHz and 1GHz
>>> OPPs. However, We need Smart reflex class 1.5 and ABB to enable 1GHz safely.
>>> For the moment, we tweak the default table to allow for 800Mhz OPP usage.
>>
>> Isn't this common to any board using 3730 (or 3630?)
>
> no it is not. only certain boards are capable of higher frequencies - there is a procedure called PDN analysis and vmin search that needs to be performed to guarentee this.
What about the "new" 3530s that can run at 720MHz? Those have been speed binned and given a different SKU. I'm using the attached 4 patches (Tony master + beagle patches _+ dvfs: http://dominion.thruhere.net/git/cgit.cgi/linux-omap/log/?h=koen/beagle-next) on my beagle C4 and overo tide to get 720MHz. They don't really work:
root at usrp-e1xx:~# cpufreq-set -f 720000
[ 104.976318] platform iva.0: omap_voltage_scale: Already at the requestedrate 430000000
[ 104.986236] platform mpu.0: omap_voltage_scale: Already at the requestedrate 600000000
[ 104.996032] platform iva.0: omap_voltage_scale: Already at the requestedrate 430000000
[ 105.006408] platform mpu.0: omap_voltage_scale: Already at the requestedrate 600000000
But:
root at usrp-e1xx:~# dmesg | grep 720
[ 0.000000] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp 720mhz )
[ 0.000000] Kernel command line: console=ttyO2,115200n8 mpurate=720 vram=16M mem=99M at 0x80000000 mem=384M at 0x88000000 omapfb.mode=dvi:1024x768MR-24 at 60 omapfb.vram=0:8M,1:4M,2:4M omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
[ 0.000000] overo_opp_init: 720MHz MPU OPPs enabled!
[ 0.000000] Switched to new clocking rate (Crystal/Core/MPU): 26.0/224/720 MHz
root at usrp-e1xx:~# cpufreq-info
cpufrequtils 006: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq at vger.kernel.org, please.
analyzing CPU 0:
driver: omap
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 300 us.
hardware limits: 125 MHz - 720 MHz
available frequency steps: 125 MHz, 250 MHz, 500 MHz, 550 MHz, 600 MHz, 720 MHz
available cpufreq governors: conservative, ondemand, userspace, powersave, performance
current policy: frequency should be within 125 MHz and 720 MHz.
The governor "userspace" may decide which speed to use
within this range.
current CPU frequency is 600 MHz (asserted by call to hardware).
cpufreq stats: 125 MHz:0.00%, 250 MHz:0.00%, 500 MHz:0.00%, 550 MHz:0.00%, 600 MHz:100.00%, 720 MHz:0.00% (1)
So how do I "properly" get 720MHz on those parts?
regards,
Koen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-omap3-add-support-for-720MHz-MPU-OPP.patch
Type: application/octet-stream
Size: 1377 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110106/47da5059/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-OMAP35x-Add-support-for-720MHz-part.patch
Type: application/octet-stream
Size: 2710 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110106/47da5059/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-OMAP3-beagle-C4-enable-upto-720MHz-OPP.patch
Type: application/octet-stream
Size: 1881 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110106/47da5059/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-OMAP3-Overo-Tide-enable-upto-720MHz-OPP.patch
Type: application/octet-stream
Size: 2720 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110106/47da5059/attachment-0003.obj>
^ permalink raw reply
* Memory sharing issue by application on V4L2 based device driver with system mmu.
From: daeinki @ 2011-01-06 12:57 UTC (permalink / raw)
To: linux-arm-kernel
Hello, all.
I'd like to discuss memory sharing issue by application on v4l2 based
device driver with system mmu and get some advices about that.
Now I am working on Samsung SoC C210 platform and this platform has some
multimedia devices with system mmu such as fimc, and mfc also we have
implemented device drivers for them. those drivers are based on V4L2
framework with videobuf2. for system mmu of each device, we used
VCM(Virtual Contiguous Memory) framework.
Simply, VCM framework provides physical memory, device virtual memory
allocation and memory mapping between them. when device driver is
initialized or operated by user application, each driver allocates
physical memory and device virtual memory and then mapping using VCM
interface.
refer to below link for more detail.
http://www.spinics.net/lists/linux-media/msg26548.html
Physical memory access process is as the following.
DVA PA
device --------------> system mmu ------------------> physical memory
DVA : device virtual address.
PA : physical address.
like this, device virtual address should be set to buffer(source or
destination) register of multimedia device.
the problem is that application want to share own memory with any device
driver to avoid memory copy. in other words, user-allocated memory could
be source or destination memory of multimedia device driver.
let's see the diagram below.
user application
|
|
|
|
| 1. UVA(allocated by malloc)
|
|
?|/ 2. UVA(in page unit)
-----> multimedia device driver -------------------> videobuf2
|
| | ^ |
| | | |
| | -------------------------------------------
| | 3. PA(in page unit)
| |
| | 4. PA(in page unit)
6. DVA | |
| |
| |
| ?|/
|
| Virtual Contiguous Memory ---------
| |
| | ^ |
| | | | 5. map PA to DVA
| | | |
| | | |
------------- -------------------------
PA : physical address.
UVA : user virtual address.
DVA : device virtual address.
1. user application allocates user space memory through malloc function
and sending it to multimedia device driver based on v4l2 framework
through userptr feature.
2, 3. multimedia device driver gets translated physical address from
videobuf2 framework in page unit.
4, 5. multimedia device driver gets allocated device virtual address and
mapping it to physical address and then mapping them through VCM interface.
6. multimedia device driver sets device virtual address from VCM to
buffer register.
the diagram above is fully theoretical so I wonder that this way is
reasonable and has some problems also what should be considered.
thank you for your interesting.
^ permalink raw reply
* [patch] mtd: pxa3xx_nand: NULL dereference in pxa3xx_nand_probe
From: Dan Carpenter @ 2011-01-06 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294227801.3996.62.camel@sven>
Hi Sven,
Could you test this patch? I don't have an arm so I can't compile this.
This was introduced in 18c81b1828f8 "mtd: pxa3xx_nand: remove the flash
info in driver structure"
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
index 17f8518..ea2c288 100644
--- a/drivers/mtd/nand/pxa3xx_nand.c
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -885,6 +885,7 @@ static int pxa3xx_nand_detect_config(struct pxa3xx_nand_info *info)
/* set info fields needed to __readid */
info->read_id_bytes = (info->page_size == 2048) ? 4 : 2;
info->reg_ndcr = ndcr;
+ info->cmdset = &default_cmdset;
if (__readid(info, &id))
return -ENODEV;
@@ -915,7 +916,6 @@ static int pxa3xx_nand_detect_config(struct pxa3xx_nand_info *info)
info->ndtr0cs0 = nand_readl(info, NDTR0CS0);
info->ndtr1cs0 = nand_readl(info, NDTR1CS0);
- info->cmdset = &default_cmdset;
return 0;
}
^ permalink raw reply related
* [PATCH] i2c-pxa: fix unbidding/rebidding of the device
From: Uwe Kleine-König @ 2011-01-06 12:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294311682-13287-1-git-send-email-dbaryshkov@gmail.com>
Hello
$Subject ~= s/bidd/bind/g
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH 3/3] ARM i.MX53 enable sdhc support on EVK board
From: yong.shen at freescale.com @ 2011-01-06 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294317033-9194-1-git-send-email-yong.shen@freescale.com>
From: Yong Shen <yong.shen@freescale.com>
1. changes some register address to fit macro definition
2. add platform data and clock for sdhc
Signed-off-by: Yong Shen <yong.shen@freescale.com>
---
arch/arm/mach-mx5/Kconfig | 1 +
arch/arm/mach-mx5/board-mx53_evk.c | 3 +++
arch/arm/mach-mx5/clock-mx51-mx53.c | 2 ++
arch/arm/mach-mx5/devices-imx53.h | 5 +++++
.../plat-mxc/devices/platform-sdhci-esdhc-imx.c | 12 ++++++++++++
arch/arm/plat-mxc/include/mach/mx53.h | 16 ++++++++--------
6 files changed, 31 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
index 632d711..23b0e3f 100644
--- a/arch/arm/mach-mx5/Kconfig
+++ b/arch/arm/mach-mx5/Kconfig
@@ -125,6 +125,7 @@ config MACH_MX53_EVK
select SOC_IMX53
select IMX_HAVE_PLATFORM_IMX_UART
select IMX_HAVE_PLATFORM_IMX_I2C
+ select IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX
help
Include support for MX53 EVK platform. This includes specific
configurations for the board and its peripherals.
diff --git a/arch/arm/mach-mx5/board-mx53_evk.c b/arch/arm/mach-mx5/board-mx53_evk.c
index ba6184b..b6981f1 100644
--- a/arch/arm/mach-mx5/board-mx53_evk.c
+++ b/arch/arm/mach-mx5/board-mx53_evk.c
@@ -99,6 +99,9 @@ static void __init mx53_evk_board_init(void)
imx53_add_imx_i2c(0, &mx53_evk_i2c_data);
imx53_add_imx_i2c(1, &mx53_evk_i2c_data);
+
+ imx53_add_sdhci_esdhc_imx(0, NULL);
+ imx53_add_sdhci_esdhc_imx(1, NULL);
}
static void __init mx53_evk_timer_init(void)
diff --git a/arch/arm/mach-mx5/clock-mx51-mx53.c b/arch/arm/mach-mx5/clock-mx51-mx53.c
index 0ade3c4..15fa89e 100644
--- a/arch/arm/mach-mx5/clock-mx51-mx53.c
+++ b/arch/arm/mach-mx5/clock-mx51-mx53.c
@@ -1328,6 +1328,8 @@ static struct clk_lookup mx53_lookups[] = {
_REGISTER_CLOCK(NULL, "iim_clk", iim_clk)
_REGISTER_CLOCK("imx-i2c.0", NULL, i2c1_clk)
_REGISTER_CLOCK("imx-i2c.1", NULL, i2c2_clk)
+ _REGISTER_CLOCK("sdhci-esdhc-imx.0", NULL, esdhc1_clk)
+ _REGISTER_CLOCK("sdhci-esdhc-imx.1", NULL, esdhc2_clk)
};
static void clk_tree_init(void)
diff --git a/arch/arm/mach-mx5/devices-imx53.h b/arch/arm/mach-mx5/devices-imx53.h
index ca1232b..f7c89ef 100644
--- a/arch/arm/mach-mx5/devices-imx53.h
+++ b/arch/arm/mach-mx5/devices-imx53.h
@@ -20,3 +20,8 @@ extern const struct imx_imx_uart_1irq_data imx53_imx_uart_data[] __initconst;
extern const struct imx_imx_i2c_data imx53_imx_i2c_data[] __initconst;
#define imx53_add_imx_i2c(id, pdata) \
imx_add_imx_i2c(&imx53_imx_i2c_data[id], pdata)
+
+extern const struct imx_sdhci_esdhc_imx_data
+imx53_sdhci_esdhc_imx_data[] __initconst;
+#define imx53_add_sdhci_esdhc_imx(id, pdata) \
+ imx_add_sdhci_esdhc_imx(&imx53_sdhci_esdhc_imx_data[id], pdata)
diff --git a/arch/arm/plat-mxc/devices/platform-sdhci-esdhc-imx.c b/arch/arm/plat-mxc/devices/platform-sdhci-esdhc-imx.c
index b352564..6b2940b 100644
--- a/arch/arm/plat-mxc/devices/platform-sdhci-esdhc-imx.c
+++ b/arch/arm/plat-mxc/devices/platform-sdhci-esdhc-imx.c
@@ -53,6 +53,18 @@ imx51_sdhci_esdhc_imx_data[] __initconst = {
};
#endif /* ifdef CONFIG_SOC_IMX51 */
+#ifdef CONFIG_SOC_IMX53
+const struct imx_sdhci_esdhc_imx_data
+imx53_sdhci_esdhc_imx_data[] __initconst = {
+#define imx53_sdhci_esdhc_imx_data_entry(_id, _hwid) \
+ imx_sdhci_esdhc_imx_data_entry(MX53, _id, _hwid)
+ imx53_sdhci_esdhc_imx_data_entry(0, 1),
+ imx53_sdhci_esdhc_imx_data_entry(1, 2),
+ imx53_sdhci_esdhc_imx_data_entry(2, 3),
+ imx53_sdhci_esdhc_imx_data_entry(3, 4),
+};
+#endif /* ifdef CONFIG_SOC_IMX53 */
+
struct platform_device *__init imx_add_sdhci_esdhc_imx(
const struct imx_sdhci_esdhc_imx_data *data,
const struct esdhc_platform_data *pdata)
diff --git a/arch/arm/plat-mxc/include/mach/mx53.h b/arch/arm/plat-mxc/include/mach/mx53.h
index a35e0c7..340937f 100644
--- a/arch/arm/plat-mxc/include/mach/mx53.h
+++ b/arch/arm/plat-mxc/include/mach/mx53.h
@@ -53,13 +53,13 @@
#define MX53_SPBA0_BASE_ADDR 0x50000000
#define MX53_SPBA0_SIZE SZ_1M
-#define MX53_MMC_SDHC1_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x00004000)
-#define MX53_MMC_SDHC2_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x00008000)
+#define MX53_ESDHC1_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x00004000)
+#define MX53_ESDHC2_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x00008000)
#define MX53_UART3_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x0000C000)
#define MX53_CSPI1_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x00010000)
#define MX53_SSI2_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x00014000)
-#define MX53_MMC_SDHC3_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x00020000)
-#define MX53_MMC_SDHC4_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x00024000)
+#define MX53_ESDHC3_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x00020000)
+#define MX53_ESDHC4_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x00024000)
#define MX53_SPDIF_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x00028000)
#define MX53_ASRC_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x0002C000)
#define MX53_ATA_DMA_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x00030000)
@@ -229,10 +229,10 @@
* Interrupt numbers
*/
#define MX53_INT_RESV0 0
-#define MX53_INT_MMC_SDHC1 1
-#define MX53_INT_MMC_SDHC2 2
-#define MX53_INT_MMC_SDHC3 3
-#define MX53_INT_MMC_SDHC4 4
+#define MX53_INT_ESDHC1 1
+#define MX53_INT_ESDHC2 2
+#define MX53_INT_ESDHC3 3
+#define MX53_INT_ESDHC4 4
#define MX53_INT_RESV5 5
#define MX53_INT_SDMA 6
#define MX53_INT_IOMUX 7
--
1.7.1
^ permalink raw reply related
* [PATCH 2/3] ARM i.MX53 enable i2c on EVK board
From: yong.shen at freescale.com @ 2011-01-06 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294317033-9194-1-git-send-email-yong.shen@freescale.com>
From: Yong Shen <yong.shen@freescale.com>
add i2c platform data and clock
Signed-off-by: Yong Shen <yong.shen@freescale.com>
---
arch/arm/mach-mx5/Kconfig | 1 +
arch/arm/mach-mx5/board-mx53_evk.c | 7 +++++++
arch/arm/mach-mx5/clock-mx51-mx53.c | 2 ++
arch/arm/mach-mx5/devices-imx53.h | 5 +++++
arch/arm/plat-mxc/devices/platform-imx-i2c.c | 9 +++++++++
5 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
index 55254b6..632d711 100644
--- a/arch/arm/mach-mx5/Kconfig
+++ b/arch/arm/mach-mx5/Kconfig
@@ -124,6 +124,7 @@ config MACH_MX53_EVK
bool "Support MX53 EVK platforms"
select SOC_IMX53
select IMX_HAVE_PLATFORM_IMX_UART
+ select IMX_HAVE_PLATFORM_IMX_I2C
help
Include support for MX53 EVK platform. This includes specific
configurations for the board and its peripherals.
diff --git a/arch/arm/mach-mx5/board-mx53_evk.c b/arch/arm/mach-mx5/board-mx53_evk.c
index b9ab386..ba6184b 100644
--- a/arch/arm/mach-mx5/board-mx53_evk.c
+++ b/arch/arm/mach-mx5/board-mx53_evk.c
@@ -65,6 +65,10 @@ static inline void mx53_evk_init_uart(void)
imx53_add_imx_uart(2, &mx53_evk_uart_pdata);
}
+static const struct imxi2c_platform_data mx53_evk_i2c_data __initconst = {
+ .bitrate = 100000,
+};
+
static inline void mx53_evk_fec_reset(void)
{
int ret;
@@ -92,6 +96,9 @@ static void __init mx53_evk_board_init(void)
mx53_evk_init_uart();
mx53_evk_fec_reset();
imx53_add_fec(&mx53_evk_fec_pdata);
+
+ imx53_add_imx_i2c(0, &mx53_evk_i2c_data);
+ imx53_add_imx_i2c(1, &mx53_evk_i2c_data);
}
static void __init mx53_evk_timer_init(void)
diff --git a/arch/arm/mach-mx5/clock-mx51-mx53.c b/arch/arm/mach-mx5/clock-mx51-mx53.c
index b21bc47..0ade3c4 100644
--- a/arch/arm/mach-mx5/clock-mx51-mx53.c
+++ b/arch/arm/mach-mx5/clock-mx51-mx53.c
@@ -1326,6 +1326,8 @@ static struct clk_lookup mx53_lookups[] = {
_REGISTER_CLOCK(NULL, "gpt", gpt_clk)
_REGISTER_CLOCK("fec.0", NULL, fec_clk)
_REGISTER_CLOCK(NULL, "iim_clk", iim_clk)
+ _REGISTER_CLOCK("imx-i2c.0", NULL, i2c1_clk)
+ _REGISTER_CLOCK("imx-i2c.1", NULL, i2c2_clk)
};
static void clk_tree_init(void)
diff --git a/arch/arm/mach-mx5/devices-imx53.h b/arch/arm/mach-mx5/devices-imx53.h
index dbf1989..ca1232b 100644
--- a/arch/arm/mach-mx5/devices-imx53.h
+++ b/arch/arm/mach-mx5/devices-imx53.h
@@ -15,3 +15,8 @@ extern const struct imx_fec_data imx53_fec_data __initconst;
extern const struct imx_imx_uart_1irq_data imx53_imx_uart_data[] __initconst;
#define imx53_add_imx_uart(id, pdata) \
imx_add_imx_uart_1irq(&imx53_imx_uart_data[id], pdata)
+
+
+extern const struct imx_imx_i2c_data imx53_imx_i2c_data[] __initconst;
+#define imx53_add_imx_i2c(id, pdata) \
+ imx_add_imx_i2c(&imx53_imx_i2c_data[id], pdata)
diff --git a/arch/arm/plat-mxc/devices/platform-imx-i2c.c b/arch/arm/plat-mxc/devices/platform-imx-i2c.c
index 72ba880..7ba94e1 100644
--- a/arch/arm/plat-mxc/devices/platform-imx-i2c.c
+++ b/arch/arm/plat-mxc/devices/platform-imx-i2c.c
@@ -78,6 +78,15 @@ const struct imx_imx_i2c_data imx51_imx_i2c_data[] __initconst = {
};
#endif /* ifdef CONFIG_SOC_IMX51 */
+#ifdef CONFIG_SOC_IMX53
+const struct imx_imx_i2c_data imx53_imx_i2c_data[] __initconst = {
+#define imx53_imx_i2c_data_entry(_id, _hwid) \
+ imx_imx_i2c_data_entry(MX53, _id, _hwid, SZ_4K)
+ imx53_imx_i2c_data_entry(0, 1),
+ imx53_imx_i2c_data_entry(1, 2),
+};
+#endif /* ifdef CONFIG_SOC_IMX51 */
+
struct platform_device *__init imx_add_imx_i2c(
const struct imx_imx_i2c_data *data,
const struct imxi2c_platform_data *pdata)
--
1.7.1
^ permalink raw reply related
* [PATCH 1/3] ARM i.MX53: enable fec driver on EVK board
From: yong.shen at freescale.com @ 2011-01-06 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294317033-9194-1-git-send-email-yong.shen@freescale.com>
From: Yong Shen <yong.shen@freescale.com>
1. Adjust FEC base address name to fit macro definition
2. Add platform data and reset function for FEC
Signed-off-by: Yong Shen <yong.shen@freescale.com>
---
arch/arm/mach-mx5/board-mx53_evk.c | 27 +++++++++++++++++++++++++++
arch/arm/mach-mx5/devices-imx53.h | 4 ++++
arch/arm/plat-mxc/devices/Kconfig | 2 +-
arch/arm/plat-mxc/devices/platform-fec.c | 5 +++++
arch/arm/plat-mxc/include/mach/mx53.h | 2 +-
5 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-mx5/board-mx53_evk.c b/arch/arm/mach-mx5/board-mx53_evk.c
index fa97d0d..b9ab386 100644
--- a/arch/arm/mach-mx5/board-mx53_evk.c
+++ b/arch/arm/mach-mx5/board-mx53_evk.c
@@ -21,14 +21,19 @@
#include <linux/init.h>
#include <linux/clk.h>
+#include <linux/fec.h>
+#include <linux/delay.h>
#include <mach/common.h>
#include <mach/hardware.h>
+#include <mach/gpio.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
#include <asm/mach/time.h>
#include <mach/imx-uart.h>
#include <mach/iomux-mx53.h>
+#define SMD_FEC_PHY_RST IMX_GPIO_NR(7, 6)
+
#include "crm_regs.h"
#include "devices-imx53.h"
@@ -60,11 +65,33 @@ static inline void mx53_evk_init_uart(void)
imx53_add_imx_uart(2, &mx53_evk_uart_pdata);
}
+static inline void mx53_evk_fec_reset(void)
+{
+ int ret;
+
+ /* reset FEC PHY */
+ ret = gpio_request(SMD_FEC_PHY_RST, "fec-phy-reset");
+ if (ret) {
+ printk(KERN_ERR"failed to get GPIO_FEC_PHY_RESET: %d\n", ret);
+ return;
+ }
+ gpio_direction_output(SMD_FEC_PHY_RST, 0);
+ gpio_set_value(SMD_FEC_PHY_RST, 0);
+ msleep(1);
+ gpio_set_value(SMD_FEC_PHY_RST, 1);
+}
+
+static struct fec_platform_data mx53_evk_fec_pdata = {
+ .phy = PHY_INTERFACE_MODE_RMII,
+};
+
static void __init mx53_evk_board_init(void)
{
mxc_iomux_v3_setup_multiple_pads(mx53_evk_pads,
ARRAY_SIZE(mx53_evk_pads));
mx53_evk_init_uart();
+ mx53_evk_fec_reset();
+ imx53_add_fec(&mx53_evk_fec_pdata);
}
static void __init mx53_evk_timer_init(void)
diff --git a/arch/arm/mach-mx5/devices-imx53.h b/arch/arm/mach-mx5/devices-imx53.h
index 9d0ec25..dbf1989 100644
--- a/arch/arm/mach-mx5/devices-imx53.h
+++ b/arch/arm/mach-mx5/devices-imx53.h
@@ -8,6 +8,10 @@
#include <mach/mx53.h>
#include <mach/devices-common.h>
+extern const struct imx_fec_data imx53_fec_data __initconst;
+#define imx53_add_fec(pdata) \
+ imx_add_fec(&imx53_fec_data, pdata)
+
extern const struct imx_imx_uart_1irq_data imx53_imx_uart_data[] __initconst;
#define imx53_add_imx_uart(id, pdata) \
imx_add_imx_uart_1irq(&imx53_imx_uart_data[id], pdata)
diff --git a/arch/arm/plat-mxc/devices/Kconfig b/arch/arm/plat-mxc/devices/Kconfig
index 2537166..b9ab1d5 100644
--- a/arch/arm/plat-mxc/devices/Kconfig
+++ b/arch/arm/plat-mxc/devices/Kconfig
@@ -1,6 +1,6 @@
config IMX_HAVE_PLATFORM_FEC
bool
- default y if ARCH_MX25 || SOC_IMX27 || SOC_IMX35 || SOC_IMX51
+ default y if ARCH_MX25 || SOC_IMX27 || SOC_IMX35 || SOC_IMX51 || SOC_IMX53
config IMX_HAVE_PLATFORM_FLEXCAN
select HAVE_CAN_FLEXCAN if CAN
diff --git a/arch/arm/plat-mxc/devices/platform-fec.c b/arch/arm/plat-mxc/devices/platform-fec.c
index 269ec78..b50c351 100644
--- a/arch/arm/plat-mxc/devices/platform-fec.c
+++ b/arch/arm/plat-mxc/devices/platform-fec.c
@@ -36,6 +36,11 @@ const struct imx_fec_data imx51_fec_data __initconst =
imx_fec_data_entry_single(MX51);
#endif
+#ifdef CONFIG_SOC_IMX53
+const struct imx_fec_data imx53_fec_data __initconst =
+ imx_fec_data_entry_single(MX53);
+#endif
+
struct platform_device *__init imx_add_fec(
const struct imx_fec_data *data,
const struct fec_platform_data *pdata)
diff --git a/arch/arm/plat-mxc/include/mach/mx53.h b/arch/arm/plat-mxc/include/mach/mx53.h
index 9577cdb..a35e0c7 100644
--- a/arch/arm/plat-mxc/include/mach/mx53.h
+++ b/arch/arm/plat-mxc/include/mach/mx53.h
@@ -136,7 +136,7 @@
#define MX53_MIPI_HSC_BASE_ADDR (MX53_AIPS2_BASE_ADDR + 0x000DC000)
#define MX53_MLB_BASE_ADDR (MX53_AIPS2_BASE_ADDR + 0x000E4000)
#define MX53_SSI3_BASE_ADDR (MX53_AIPS2_BASE_ADDR + 0x000E8000)
-#define MX53_MXC_FEC_BASE_ADDR (MX53_AIPS2_BASE_ADDR + 0x000EC000)
+#define MX53_FEC_BASE_ADDR (MX53_AIPS2_BASE_ADDR + 0x000EC000)
#define MX53_TVE_BASE_ADDR (MX53_AIPS2_BASE_ADDR + 0x000F0000)
#define MX53_VPU_BASE_ADDR (MX53_AIPS2_BASE_ADDR + 0x000F4000)
#define MX53_SAHARA_BASE_ADDR (MX53_AIPS2_BASE_ADDR + 0x000F8000)
--
1.7.1
^ permalink raw reply related
* [PATCH 0/3] ARM i.MX53: enable some devices on EVK board
From: yong.shen at freescale.com @ 2011-01-06 12:30 UTC (permalink / raw)
To: linux-arm-kernel
fec enable patch (1/3) was post hours before, I changed it a little bit as per Baruch's comments. Since they are ordered, so I post them all togather.
^ permalink raw reply
* mxc: i2c register mapped twice?
From: Richard Zhao @ 2011-01-06 12:26 UTC (permalink / raw)
To: linux-arm-kernel
Hi Sascha,
I just realized i2c registers are mapped twice. It's first static mapped at
mx5x_io_desc and second mapped in driver.
Drivers always feel happy to receive physical address in resource, and ioremap
it itself. We might static map too many register regions in machine level?
I'm sure it's not just i2c.
Thanks
Richard
^ permalink raw reply
* [PATCH 2/2] OMAP3: beagle xm: enable upto 800MHz OPP
From: Nishanth Menon @ 2011-01-06 12:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <874o9nvskt.fsf@ti.com>
Kevin Hilman wrote, on 01/05/2011 05:28 PM:
> Nishanth Menon<nm@ti.com> writes:
>
>> Beagle XM uses 3730 and the board design allows enabling 800MHz and 1GHz
>> OPPs. However, We need Smart reflex class 1.5 and ABB to enable 1GHz safely.
>> For the moment, we tweak the default table to allow for 800Mhz OPP usage.
>
> Isn't this common to any board using 3730 (or 3630?)
no it is not. only certain boards are capable of higher frequencies -
there is a procedure called PDN analysis and vmin search that needs to
be performed to guarentee this.
>
> IOW, what is Beagle specific about this?
beagle is one of the boards capable of higher frequencies.
>
> Kevin
>
>> Reported-by: Koen Kooi<koen@beagleboard.org>
>> Tested-by: Koen Kooi<koen@beagleboard.org>
>>
>> Signed-off-by: Nishanth Menon<nm@ti.com>
>> ---
>> arch/arm/mach-omap2/board-omap3beagle.c | 50 +++++++++++++++++++++++++++++++
>> 1 files changed, 50 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
>> index 6c12760..0b99b80 100644
>> --- a/arch/arm/mach-omap2/board-omap3beagle.c
>> +++ b/arch/arm/mach-omap2/board-omap3beagle.c
>> @@ -23,6 +23,7 @@
>> #include<linux/gpio.h>
>> #include<linux/input.h>
>> #include<linux/gpio_keys.h>
>> +#include<linux/opp.h>
>>
>> #include<linux/mtd/mtd.h>
>> #include<linux/mtd/partitions.h>
>> @@ -44,10 +45,12 @@
>> #include<plat/gpmc.h>
>> #include<plat/nand.h>
>> #include<plat/usb.h>
>> +#include<plat/omap_device.h>
>>
>> #include "mux.h"
>> #include "hsmmc.h"
>> #include "timer-gp.h"
>> +#include "pm.h"
>>
>> #define NAND_BLOCK_SIZE SZ_128K
>>
>> @@ -556,6 +559,52 @@ static struct omap_musb_board_data musb_board_data = {
>> .power = 100,
>> };
>>
>> +static void __init beagle_opp_init(void)
>> +{
>> + int r = 0;
>> +
>> + /* Initialize the omap3 opp table */
>> + if (omap3_opp_init()) {
>> + pr_err("%s: opp default init failed\n", __func__);
>> + return;
>> + }
>> +
>> + /* Custom OPP enabled for XM */
>> + if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
>> + struct omap_hwmod *mh = omap_hwmod_lookup("mpu");
>> + struct omap_hwmod *dh = omap_hwmod_lookup("iva");
>> + struct device *dev;
>> +
>> + if (!mh || !dh) {
>> + pr_err("%s: Aiee.. no mpu/dsp devices? %p %p\n",
>> + __func__, mh, dh);
>> + r = -EINVAL;
>> + } else {
>> + /* Enable MPU 1GHz and lower opps */
>> + dev =&mh->od->pdev.dev;
>> + r = opp_enable(dev, 800000000);
>> + /* TODO: MPU 1GHz needs SR and ABB */
>> +
>> + /* Enable IVA 800MHz and lower opps */
>> + dev =&dh->od->pdev.dev;
>> + r |= opp_enable(dev, 660000000);
>> + /* TODO: DSP 800MHz needs SR and ABB */
>> + }
>> + if (r) {
>> + pr_err("%s: failed to enable higher opp %d\n",
>> + __func__, r);
>> + /*
>> + * Cleanup - disable the higher freqs - we dont care
>> + * about the results
>> + */
>> + dev =&mh->od->pdev.dev;
>> + opp_disable(dev, 800000000);
>> + dev =&dh->od->pdev.dev;
>> + opp_disable(dev, 660000000);
>> + }
>> + }
>> +}
>> +
>> static void __init omap3_beagle_init(void)
>> {
>> omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
>> @@ -579,6 +628,7 @@ static void __init omap3_beagle_init(void)
>> omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
>>
>> beagle_display_init();
>> + beagle_opp_init();
>> }
>>
>> MACHINE_START(OMAP3_BEAGLE, "OMAP3 Beagle Board")
--
Regards,
Nishanth Menon
^ permalink raw reply
* Current OMAP build failures
From: Santosh Shilimkar @ 2011-01-06 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106110336.GC31708@n2100.arm.linux.org.uk>
Russell,
> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> owner at vger.kernel.org] On Behalf Of Russell King - ARM Linux
> Sent: Thursday, January 06, 2011 4:34 PM
> To: Tony Lindgren
> Cc: linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> Subject: Current OMAP build failures
>
Have you used any custom build/ additional build flags
for omap2/3/4 reported issues ?
I just rebased Tony's 'omap-for-linus' branch with 2.6.37 and
it not seems to report below issues. May be it's getting
fixed as part of 2.6.38 omap queue or my build config is
not same as yours. I used omap2plus_defconfig.
> === omap2 ===
> arch/arm/plat-omap/devices.c:253: warning: ?omap_init_wdt? defined
> but not used
> arch/arm/mach-omap2/irq.c:64: warning: ?intc_context? defined but
> not used
> arch/arm/mach-omap2/prcm.c:122: warning: ?prcm_context? defined but
> not used
>
> Missing __maybe_unused or something else?
These seems to be fixed in omap queue.
>
> It also comes with three section mismatches:
>
> WARNING: vmlinux.o(.text+0x1f4c4): Section mismatch in reference
> from the function omap_early_device_register() to the function
> .init.text:early_platform_add_devices()
> The function omap_early_device_register() references
> the function __init early_platform_add_devices().
> This is often because omap_early_device_register lacks a __init
> annotation or the annotation of early_platform_add_devices is wrong.
>
> As early_platform_add_devices() is marked __init, so too should be
> omap_early_device_register().
I don't see this one. May be fixed
>
> WARNING: vmlinux.o(.text+0x1f6bc): Section mismatch in reference
> from the function omap_device_build_ss() to the function
> .init.text:early_platform_add_devices()
> The function omap_device_build_ss() references
> the function __init early_platform_add_devices().
> This is often because omap_device_build_ss lacks a __init
> annotation or the annotation of early_platform_add_devices is wrong.
>
> This looks like omap_early_device_register() has been inlined into
> omap_device_build_ss(), and it doesn't look like it can be marked
> __init.
>
> Rather than passing an 'is_early_device' into this function, split
> out the common code into a separate function which takes a function
> pointer to the registration function. Then you can have two
> additional
> functions, one marked __init which uses omap_early_device_register()
> and one not marked __init using omap_device_register().
>
> This also means that we get the init-section type checking further
> up
> the chain.
This too
>
> WARNING: vmlinux.o(.data+0x6bd4): Section mismatch in reference from
> the variable h4_config to the (unknown reference)
> .init.data:(unknown)
> The variable h4_config references
> the (unknown reference) __initdata (unknown)
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the
> variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
>
> Maybe it shouldn't be marked __initdata?
This too
>
> === omap3 ===
> WARNING: vmlinux.o(.text+0x1b780): Section mismatch in reference
> from the function sdp3430_twl_gpio_setup() to the function
> .init.text:omap2_hsmmc_init()
> The function sdp3430_twl_gpio_setup() references
> the function __init omap2_hsmmc_init().
> This is often because sdp3430_twl_gpio_setup lacks a __init
> annotation or the annotation of omap2_hsmmc_init is wrong.
>
> Missing __init on sdp3430_twl_gpio_setup ?
This too
>
> WARNING: vmlinux.o(.text+0x1f714): Section mismatch in reference
> from the function omap_early_device_register() to the function
> .init.text:early_platform_add_devices()
> The function omap_early_device_register() references
> the function __init early_platform_add_devices().
> This is often because omap_early_device_register lacks a __init
> annotation or the annotation of early_platform_add_devices is wrong.
>
> As before.
This too
>
> WARNING: vmlinux.o(.text+0x1f90c): Section mismatch in reference
> from the function omap_device_build_ss() to the function
> .init.text:early_platform_add_devices()
> The function omap_device_build_ss() references
> the function __init early_platform_add_devices().
> This is often because omap_device_build_ss lacks a __init
> annotation or the annotation of early_platform_add_devices is wrong.
>
> As before.
This too
>
> WARNING: vmlinux.o(.data+0x20670): Section mismatch in reference
> from the variable twl_driver to the function .init.text:twl_probe()
> The variable twl_driver references
> the function __init twl_probe()
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the
> variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
>
> twl_probe shouldn't be __init ?
>
I only see the twl_probe section miss-match. Have attached full build
log for reference.
Regards,
Santosh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2.6.37_omap_for_linus.tar.bz2
Type: application/octet-stream
Size: 8378 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110106/5786427a/attachment.obj>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox