RE: [PM-SR][PATCH 11/12] omap3: sr: sr_exit should be static
>>-Original Message-
>>From: Menon, Nishanth
>>Sent: Friday, August 06, 2010 3:54 AM
>>To: linux-omap
>>Cc: Menon, Nishanth; Kevin Hilman; Gopinath, Thara
>>Subject: [PM-SR][PATCH 11/12] omap3: sr: sr_exit should be static
>>
>>sr_exit has no business being a public function.
>>fixes sparse:
>>arch/arm/mach-omap2/smartreflex.c:959:13: warning: symbol 'sr_exit' was not
>>declared. Should it be
>>static?
>>
>>Cc: Kevin Hilman
>>Cc: Thara Gopinath
>>
>>Signed-off-by: Nishanth Menon
>>---
>> arch/arm/mach-omap2/smartreflex.c |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>>diff --git a/arch/arm/mach-omap2/smartreflex.c
>>b/arch/arm/mach-omap2/smartreflex.c
>>index 9b5a10e..a723ac7 100644
>>--- a/arch/arm/mach-omap2/smartreflex.c
>>+++ b/arch/arm/mach-omap2/smartreflex.c
>>@@ -968,7 +968,7 @@ static int __init sr_init(void)
>> return 0;
>> }
>>
>>-void __exit sr_exit(void)
>>+static void __exit sr_exit(void)
Will collate this.
>> {
>> platform_driver_unregister(&smartreflex_driver);
>> }
>>--
>>1.6.3.3
--
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: [PM-SR][PATCH 10/12] omap3: sr: export sr_dbg_dir
>>-Original Message-
>>From: Menon, Nishanth
>>Sent: Friday, August 06, 2010 3:54 AM
>>To: linux-omap
>>Cc: Menon, Nishanth; Kevin Hilman; Gopinath, Thara
>>Subject: [PM-SR][PATCH 10/12] omap3: sr: export sr_dbg_dir
>>
>>sr_dbg_dir is currently used privately in smartreflex.c, however,
>>smartreflex class drivers could store their own debugfs entries there
>>as well.
>>
>>This also fixes the sparse warning:
>>arch/arm/mach-omap2/smartreflex.c:44:15: warning: symbol 'sr_dbg_dir' was not
>>declared. Should it be
>>static?
>>
>>Cc: Kevin Hilman
>>Cc: Thara Gopinath
>>
>>Signed-off-by: Nishanth Menon
>>---
>> arch/arm/plat-omap/include/plat/smartreflex.h |5 +
>> 1 files changed, 5 insertions(+), 0 deletions(-)
>>
>>diff --git a/arch/arm/plat-omap/include/plat/smartreflex.h b/arch/arm/plat-
>>omap/include/plat/smartreflex.h
>>index 1105db0..df58026 100644
>>--- a/arch/arm/plat-omap/include/plat/smartreflex.h
>>+++ b/arch/arm/plat-omap/include/plat/smartreflex.h
>>@@ -263,6 +263,11 @@ int omap_sr_register_class(struct
>>omap_smartreflex_class_data *class_data);
>>
>> /* API to register the pmic specific data with the smartreflex driver. */
>> void omap_sr_register_pmic(struct omap_smartreflex_pmic_data *pmic_data);
>>+
>>+#ifdef CONFIG_PM_DEBUG
>>+extern struct dentry *sr_dbg_dir;
>>+#endif
Will take this in
Regards
Thara
>>+
>> #else
>> static inline void omap_smartreflex_enable(int srid) {}
>> static inline void omap_smartreflex_disable(int srid) {}
>>--
>>1.6.3.3
--
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: [PM-SR][PATCH 09/12] omap3: sr: enable/disable sr only if required
>>-Original Message-
>>From: Menon, Nishanth
>>Sent: Friday, August 06, 2010 3:54 AM
>>To: linux-omap
>>Cc: Menon, Nishanth; Kevin Hilman; Gopinath, Thara
>>Subject: [PM-SR][PATCH 09/12] omap3: sr: enable/disable sr only if required
>>
>>We dont need to go down the path of enabling/disabling the SR
>>if we dont need to. do some sanity check and trigger if needed
>>
>>Cc: Kevin Hilman
>>Cc: Thara Gopinath
>>
>>Signed-off-by: Nishanth Menon
>>---
>> arch/arm/mach-omap2/smartreflex.c | 19 +++
>> 1 files changed, 15 insertions(+), 4 deletions(-)
>>
>>diff --git a/arch/arm/mach-omap2/smartreflex.c
>>b/arch/arm/mach-omap2/smartreflex.c
>>index d63691b..9b5a10e 100644
>>--- a/arch/arm/mach-omap2/smartreflex.c
>>+++ b/arch/arm/mach-omap2/smartreflex.c
>>@@ -778,15 +778,26 @@ static int omap_sr_autocomp_show(void *data, u64 *val)
>> static int omap_sr_autocomp_store(void *data, u64 val)
>> {
>> struct omap_sr *sr_info = (struct omap_sr *) data;
>>+ u32 value = (u32) val;
>>
>> if (!sr_info) {
>> pr_warning("%s: omap_sr struct for SR not found\n", __func__);
>> return -EINVAL;
>> }
>>- if (!val)
>>- sr_stop_vddautocomp(sr_info);
>>- else
>>- sr_start_vddautocomp(sr_info);
>>+
>>+ /* Sanity check */
>>+ if (value && (value != 1)) {
>>+ pr_err("%s: invalid value %d\n", __func__, value);
>>+ return -EINVAL;
>>+ }
Will take this in.
>>+
>>+ /* change only if needed */
>>+ if (sr_info->is_autocomp_active ^ value) {
I do not think this is necessary. sr_start_vddautocomp and sr_stop_vddautocomp
will take care of
enabling and disabling intelligently.
Regards
Thara
>>+ if (!val)
>>+ sr_stop_vddautocomp(sr_info);
>>+ else
>>+ sr_start_vddautocomp(sr_info);
>>+ }
>> return 0;
>> }
>>
>>--
>>1.6.3.3
--
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: [PM-SR][PATCH 08/12] omap3: sr: cleanup pr_xxx
>>-Original Message-
>>From: Menon, Nishanth
>>Sent: Friday, August 06, 2010 3:54 AM
>>To: linux-omap
>>Cc: Menon, Nishanth; Kevin Hilman; Gopinath, Thara
>>Subject: [PM-SR][PATCH 08/12] omap3: sr: cleanup pr_xxx
>>
>>pr_xxx family is not informative for debug unless one decides
>>to grep the code, instead print the function to help debug
>>easier on the field.
>>
>>Cc: Kevin Hilman
>>Cc: Thara Gopinath
>>
>>Signed-off-by: Nishanth Menon
>>---
>> arch/arm/mach-omap2/smartreflex.c |5 +++--
>> 1 files changed, 3 insertions(+), 2 deletions(-)
>>
>>diff --git a/arch/arm/mach-omap2/smartreflex.c
>>b/arch/arm/mach-omap2/smartreflex.c
>>index 57fc9b2..d63691b 100644
>>--- a/arch/arm/mach-omap2/smartreflex.c
>>+++ b/arch/arm/mach-omap2/smartreflex.c
>>@@ -804,8 +804,9 @@ static int omap_sr_params_store(void *data, u64 val)
>> u32 *option = data;
>> *option = val;
>> } else {
>>- pr_notice("DEBUG option not enabled!\n \
>>- echo 1 > pm_debug/enable_sr_vp_debug - to enable\n");
>>+ pr_notice("%s: DEBUG option not enabled! "
>>+ "echo 1 > pm_debug/enable_sr_vp_debug to enable\n",
>>+ __func__);
>> }
Accepted and will be collated with rest of the patches.
>> return 0;
>> }
>>--
>>1.6.3.3
--
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] platform: Facilitate the creation of pseduo-platform busses
On 08/05/2010 04:16 PM, Grant Likely wrote:
> On Thu, Aug 5, 2010 at 9:57 AM, Kevin Hilman
> wrote:
>> Patrick Pannuto writes:
>>
>>> On 08/04/2010 05:16 PM, Kevin Hilman wrote:
Patrick Pannuto writes:
> Inspiration for this comes from:
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31161.html
Also, later in that thread I also wrote[1] what seems to be the core of
what you've done here: namely, allow platform_devices and
platform_drivers to to be used on custom busses. Patch is at the end of
this mail with a more focused changelog. As Greg suggested in his reply
to your first version, this part could be merged today, and the
platform_bus_init stuff could be added later, after some more review.
Some comments below...
>>>
>>> I can split this into 2 patches.
>>
>> Yes, I think that would be better.
>>
>>> Was your patch sent to linux-kernel or just linux-omap? I'm not on
>>> linux-omap...
>>
>> That thread was on linux-arm-kernel and linux-omap
>>
>>>
> [snip]
>
> Which will allow the same driver to easily to used on either
> the platform bus or the newly defined bus type.
Except it requires a re-compile.
Rather than doing this at compile time, it would be better to support
legacy devices at runtime. You could handle this by simply registering
the driver on the custom bus and the platform_bus and let the bus
matching code handle it. Then, the same binary would work on both
legacy and updated SoCs.
>>>
>>> Can you safely register a driver on more than one bus? I didn't think
>>> that was safe -- normally it's impossible since you're calling
>>>
>>> struct BUS_TYPE_driver mydriver;
>>> BUS_TYPE_driver_register(&mydriver)
>>>
>>> but now we have multiple "bus types" that are all actually platform type;
>>> still,
>>> at a minimum you would need:
>>> struct platform_driver mydrvier1 = {
>>> .driver.bus = &sub_bus1,
>>> };
>>> struct platform_driver mydrvier2 = {
>>> .driver.bus = &sub_bus2,
>>> };
>>> which would all point to the same driver functions, yet the respective
>>> devices
>>> attached for the "same" driver would be on different buses. I fear this
>>> might
>>> confuse some drivers. I don't think dynamic bus assignment is this easy
>>>
>>> In short: I do not believe the same driver can be registered on multiple
>>> different buses -- if this is wrong, please correct me.
>>
>> It is possible, and currently done in powerpc land where some
>> drivers handle devices on the platform_bus and the custom OF bus.
>
> As of now, the of_platform_bus_type has been removed. It was a bad
> idea because it tried to encode non-bus-specific information into
> something that was just a clone of the platform_bus. Drivers that
> worked on both had to be bound to both busses. I do actually have
> code that automatically registers a driver on more than one bus, but
> it is rather a hack and was only a temporary measure.
>
> The relevant question before going down this path is, "Is the
> omap/sh/other-soc behaviour something fundamentally different from the
> platform bus? Or is it something complementary that would be better
> handled with a notifier or some orthogonal method of adding new
> behaviour?"
>
> I don't have a problem with multiple platform_bus instances using the
> same code (I did suggest it after all), but I do worry about muddying
> the Linux device model or making it overly complex. Binding single
> drivers to multiple device types could be messy.
>
> Cheers,
> g.
>From your other email, the distinction of /bus_types/ versus /physical
or logical buses/ was very valuable (thanks). I am becoming less
convinced that I need this infrastructure or the ability to create
pseudo-platform buses. Let me outline some thoughts below, which I
think at least solves my problems ( ;) ), and if some of the OMAP folks
and Alan could chime in as to whether they can apply something similar,
or if they still have need of creating actual new bus types?
As we are exploring all of this, let me put a concrete (ish) scenario
out there to discuss:
SUB_BUS1---DEVICE1
/
CPU ---
\
SUB_BUS2---DEVICE2
DEVICE1 and DEVICE2 are the same device (say, usb host controller, or
whatever), and they should be driven by the same driver. However,
physically they are attached to different buses.
SUB_BUS1 and SUB_BUS2 are *different* and let's say require a different
suspend method. If I understand correctly, the right way to build the
topology would be:
struct device_type SUB_BUS1_type = {
.name = "sub-bus1-type",
.pm = &sub_bus1_pm_ops;
};
struct platform_device SUB_BUS1 = {
.init_name = "sub-bus1",
.dev.type = &sub_bus1_type,
};
struct platform_device DEVICE1 = {
.name = "device1",
.dev.parent = &SUB_BUS1.dev,
};
platform_device_register(&SUB_BUS1);
Re: [PATCH] platform: Facilitate the creation of pseduo-platform busses
On Thu, Aug 5, 2010 at 9:57 AM, Kevin Hilman
wrote:
> Patrick Pannuto writes:
>
>> On 08/04/2010 05:16 PM, Kevin Hilman wrote:
>>> Patrick Pannuto writes:
>>>
Inspiration for this comes from:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31161.html
>>>
>>> Also, later in that thread I also wrote[1] what seems to be the core of
>>> what you've done here: namely, allow platform_devices and
>>> platform_drivers to to be used on custom busses. Patch is at the end of
>>> this mail with a more focused changelog. As Greg suggested in his reply
>>> to your first version, this part could be merged today, and the
>>> platform_bus_init stuff could be added later, after some more review.
>>> Some comments below...
>>>
>>
>> I can split this into 2 patches.
>
> Yes, I think that would be better.
>
>> Was your patch sent to linux-kernel or just linux-omap? I'm not on
>> linux-omap...
>
> That thread was on linux-arm-kernel and linux-omap
>
>>
[snip]
Which will allow the same driver to easily to used on either
the platform bus or the newly defined bus type.
>>>
>>> Except it requires a re-compile.
>>>
>>> Rather than doing this at compile time, it would be better to support
>>> legacy devices at runtime. You could handle this by simply registering
>>> the driver on the custom bus and the platform_bus and let the bus
>>> matching code handle it. Then, the same binary would work on both
>>> legacy and updated SoCs.
>>>
>>
>> Can you safely register a driver on more than one bus? I didn't think
>> that was safe -- normally it's impossible since you're calling
>>
>> struct BUS_TYPE_driver mydriver;
>> BUS_TYPE_driver_register(&mydriver)
>>
>> but now we have multiple "bus types" that are all actually platform type;
>> still,
>> at a minimum you would need:
>> struct platform_driver mydrvier1 = {
>> .driver.bus = &sub_bus1,
>> };
>> struct platform_driver mydrvier2 = {
>> .driver.bus = &sub_bus2,
>> };
>> which would all point to the same driver functions, yet the respective
>> devices
>> attached for the "same" driver would be on different buses. I fear this might
>> confuse some drivers. I don't think dynamic bus assignment is this easy
>>
>> In short: I do not believe the same driver can be registered on multiple
>> different buses -- if this is wrong, please correct me.
>
> It is possible, and currently done in powerpc land where some
> drivers handle devices on the platform_bus and the custom OF bus.
As of now, the of_platform_bus_type has been removed. It was a bad
idea because it tried to encode non-bus-specific information into
something that was just a clone of the platform_bus. Drivers that
worked on both had to be bound to both busses. I do actually have
code that automatically registers a driver on more than one bus, but
it is rather a hack and was only a temporary measure.
The relevant question before going down this path is, "Is the
omap/sh/other-soc behaviour something fundamentally different from the
platform bus? Or is it something complementary that would be better
handled with a notifier or some orthogonal method of adding new
behaviour?"
I don't have a problem with multiple platform_bus instances using the
same code (I did suggest it after all), but I do worry about muddying
the Linux device model or making it overly complex. Binding single
drivers to multiple device types could be messy.
Cheers,
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: PM branch updated to v2.6.35, SRF dropped
Kevin Hilman had written, on 08/05/2010 05:29 PM, the following: Nishanth Menon writes: Kevin Hilman had written, on 08/04/2010 05:50 PM, the following: [...] I've only tested the new PM branch on a couple boards to avoid any further delay getting this version out, update, so hopefully others will help test. I've tested RET on idle & suspend, OFF in idle & suspend on: 3430/omap3evm: works 3630/Zoom3: works - Known problem: console hangs on UART wakeup when wakeups are enabled using echo enabled > /sys/devices/platform/serial8250.0/tty/ttyS0/power/wakeup but I haven't debugged this further. Just sharing results from SDP testing omap3_pm_defconfig + earlyprintk: SDP3430 (with denx.com u-boot, nor boot): does not boot to shell full Bootlog: http://pastebin.mozilla.org/761964 Does the same setup boot fine on l-o for-next, or l-o master? yep l-o master (omap3_defconfig): Log: http://pastebin.mozilla.org/762620 l-o for-next (omap3_defconfig): build fails with: drivers/usb/musb/omap2430.c: In function 'musb_platform_init': drivers/usb/musb/omap2430.c:198: error: 'AE5_2430_USB0HS_STP' undeclared (first use in this function) drivers/usb/musb/omap2430.c:198: error: (Each undeclared identifier is reported only once drivers/usb/musb/omap2430.c:198: error: for each function it appears in.) so disabled CONFIG_ARCH_OMAP2430 and CONFIG_MACH_OMAP_2430SDP in .config for quick bootup. Log: http://pastebin.mozilla.org/762637 Ref: remotes/origin/master 8428498 Linux-omap rebuilt: arm changes merged to mainline, final omap changes for 2.6.36 remotes/origin/for-next d21872b Merge branch 'v2.6.35-omap-mailbox-for-next' of git://gitorious.org/~doyu/lk/mainline into omap-for-linus SDP3630 (with TI u-boot, xloader, mmc boot): ret works, uart wakeup fails for off mode (I am guessing this is similar to Kevin's results) full Bootlog: http://pastebin.mozilla.org/761966 OMAP4 Blaze (with TI u-boot, xloader, mmc boot): does not boot, hell lot of crashes - note, need to explicitly enable MACH_OMAP4430_SDP in .config full Bootlog: http://pastebin.mozilla.org/761968 yeah, I don't expect PM branch to work on OMAP4 until we get the OMAP4 hwmod core upstream. :( -- Regards, Nishanth Menon -- 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: [RFC PATCH] platform: Faciliatate the creation of pseduo-platform busses
On Tue, Aug 3, 2010 at 5:56 PM, Greg KH wrote: > On Tue, Aug 03, 2010 at 04:35:06PM -0700, Patrick Pannuto wrote: >> @@ -539,12 +541,12 @@ int __init_or_module platform_driver_probe(struct >> platform_driver *drv, >> * if the probe was successful, and make sure any forced probes of >> * new devices fail. >> */ >> - spin_lock(&platform_bus_type.p->klist_drivers.k_lock); >> + spin_lock(&drv->driver.bus->p->klist_drivers.k_lock); >> drv->probe = NULL; >> if (code == 0 && list_empty(&drv->driver.p->klist_devices.k_list)) >> retval = -ENODEV; >> drv->driver.probe = platform_drv_probe_fail; >> - spin_unlock(&platform_bus_type.p->klist_drivers.k_lock); >> + spin_unlock(&drv->driver.bus->p->klist_drivers.k_lock); >> >> if (code != retval) >> platform_driver_unregister(drv); > > I'm guessing that this chunk can be applied now, right? Yes, I agree. This chunk makes sense independently of the rest of the patch. 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: [RFC PATCH] platform: Faciliatate the creation of pseduo-platform busses
On Tue, Aug 3, 2010 at 6:17 PM, Patrick Pannuto wrote:
>
> struct platform_device sub_bus1 = {
> .name = "sub_bus1",
> .id = -1,
> .dev.bus = &my_bus_type,
> }
> EXPORT_SYMBOL_GPL(sub_bus1);
You really want a bus hanging off of a bus? Normally you need a device
to do that, which is what I think you have here, but the naming is a bit
odd to me.
What would you do with this "sub bus"? It's just a device, but you are
wanting it to be around for something.
>>>
>>> It's for power management stuff, basically, there are actual physical buses
>>> involved that can be completely powered off IFF all of their devices are
>>> not in use. Plus it actually matches bus topology this way.
>>
>> Then create a real bus hanging off of a device, not another device that
>> "acts" like a bus here, right? Or am I missing the point?
>>
>
> The motivation for doing it this was is that one driver could drive
> devices on two different subbusses. In the example, "my-driver" could
> drive a device on sub_bus1 AND sub_bus2 (if there were 2+ devices, one
> or more on each bus).
>
> From my understanding, this is not possible if they are actually
> different busses.
It sounds an awful lot like 2 separate concepts are being conflated
here. In Linux terminology, we have two things:
/bus types/ describe the common behavour of similarly attached things.
/physical or logical busses/ are where devices are actually attached
registered to the system.
These are not the same thing.
The primary thing that a bus-type provides is the set of device driver
that can be bound to the device plus some common functionality.
Almost every struct device has the 'struct bus_type bus' field set so
that it can be bound against a device driver when it is registered.
Every struct device also has a 'struct device *parent' field. The
parent field denotes where the device lives in the Linux device model
(see /sys/devices/*), but it says *nothing* about what the bus type of
device it is. Remember I mentioned physical/logical busses earlier?
Well the core Linux device model doesn't really have a concept of bus
instances, it only knows about devices and bus types. The .parent
field is the closest thing the device model has to a bus instance, but
the model places no constraints on the bus type of each child 'struct
device'.
(caveat: many bus_types do have a concept of bus instances; but that
is specific to the bus_type. The core device model doesn't care.
Also, in practical terms, yes most sibling devices will also be of the
same bus_type, but it is not a given, and it is not enforced.)
For example, a system can have many physical pci busses, but all the
devices hanging off those busses are still just registered on
pci_bus_type. The parent of those devices, however, reflects the
physical bus the device is attached to.
In fact, the bus type has absolutely no bearing on where a device
actually lives in the Linux driver model. A common misunderstanding
is that all platform devices live under /sys/devices/platform.
This also is not true.
By default the platform bus will put devices without a parent into
/sys/devices/platform, but if parent is set, then the device will be
registered where the parent pointer tells it to be registered. It is
totally okay to have the following structure (off the top of my head):
system_bus (platform_bus_type, registers a bunch of child devices)
|--pci_bus (platform_bus_type; implements a pci host bridge)
| |--usb host controller 1 (pci_bus_type, implements a usb bus instance)
| |--usb host controller 2 (pci_bus_type, implements a usb bus instance)
| |--fpga (pci_bus_type, implements a bunch of devices)
| |--spi controller (platform_bus_type)
| |--custom peripheral (platform_bus_type)
|--uart (platform_bus_type)
|--uart (platform_bus_type)
|--ethernet (platform_bus_type)
|--external bus (platform_bus_type; represents and external local bus)
| |--i2c controller (platform_bus_type)
| | |--eeprom (i2c_bus_type)
| | |--temperature sensor (i2c_bus_type)
|--gpio controller (platform_bus_type)
Platform devices can show up just about anywhere in the tree.
(On that point Greg, what is the reason for even having the
/sys/devices/platform/ parent? Why not just let the platform devices
sit at the root of the device tree? In the OF case (granted, I'm
biased) all of the platform_device registrations reflect the actual
device hierarchy expressed in the device tree data.)
So, the *only* reason to have a different bus_type is if the actual
behaviour of the bus is different. A different bus type wouldn't even
cause a different topology if doing so wouldn't make sense. For
example in the OMAP case, the topology might look like:
system_bus (platform_bus_type, registers a bunch of child devices)
| ...
|--uart (omap_bus_type)
|--uart (omap_bus_type)
|--ethernet (platform_bus_type)
Se
Re: PM branch updated to v2.6.35, SRF dropped
"Nayak, Rajendra" writes: >> -Original Message- >> From: linux-omap-ow...@vger.kernel.org >> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman >> Sent: Thursday, August 05, 2010 4:21 AM >> To: linux-omap@vger.kernel.org >> Subject: PM branch updated to v2.6.35, SRF dropped >> >> Hello, >> > > Hi Kevin, > > Can you pull in this patch into your branch as well? > http://marc.info/?l=linux-usb&m=127858711304301&w=2 > Without this multi-omap build seems to be broken. Done. > Also with omap_4430sdp_defconfig, I see these compile errors > arch/arm/kernel/entry-armv.S: Assembler messages: > arch/arm/kernel/entry-armv.S:48: Error: bad instruction `test_for_ipi > r0,r6,r5,lr' > arch/arm/kernel/entry-armv.S:48: Error: bad instruction `test_for_ipi > r0,r6,r5,lr' > make[1]: *** [arch/arm/kernel/entry-armv.o] Error 1 > make: *** [arch/arm/kernel] Error 2 > > Doing a git log on entry-armv.S shows me a top commit which might > be an issue if conflicts are'nt resolved well. > > commit 7b70c4275f28702b76b273c8534c38f8313812e9 > Merge: ceb0885... a20df56... > Author: Russell King > Date: Sat Jul 31 14:20:16 2010 +0100 > > Merge branch 'devel-stable' into devel > > Conflicts: > arch/arm/kernel/entry-armv.S > arch/arm/kernel/setup.c > arch/arm/mm/init.c > > Maybe this is an issue in Tony's for-next as well. Haven't tested > it though. Yeah, I'm guessing this an issue in for-next, and probably l-o master too. Kevin > >> It's been a while since a PM branch update, thanks to a nice summer >> vacation for me. :) >> >> The PM branch has now been updated to v2.6.35 plus Tony's for-next >> branch. >> >> This is mostly a rebase, but the most important change is that I'm >> finally dropping SRF as promised[1]. The new DVFS >> infrastructure is now >> in the RFC/PATCH phase so I'm no longer going to keep dragging SRF >> along. Note that this means that ***DVFS no longer works in >> the PM branch***. >> If this bothers you, then please consider helping review and test the >> new DVFS infrastructure recently posted by Thara so we can >> get the new, >> upstream-ready DVFS code upstream ASAP. >> >> I've only tested the new PM branch on a couple boards to avoid any >> further delay getting this version out, update, so hopefully >> others will >> help test. >> >> I've tested RET on idle & suspend, OFF in idle & suspend on: >> >> 3430/omap3evm: works >> >> 3630/Zoom3: works >> - Known problem: console hangs on UART wakeup when wakeups >> are enabled using >> echo enabled > >> /sys/devices/platform/serial8250.0/tty/ttyS0/power/wakeup >> but I haven't debugged this further. >> >> Kevin >> >> >> [1] http://marc.info/?l=linux-omap&m=127206504624556&w=2 >> -- >> 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 >> -- 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 v6] OMAP4 HSMMC: Adding Card detect support for MMC1 on OMAP4
> -Original Message-
> From: kishore kadiyala [mailto:kishorek.kadiy...@gmail.com]
> Sent: Thursday, August 05, 2010 11:04 AM
> To: Madhusudhan
> Cc: Andrew Morton; linux-...@vger.kernel.org; linux-omap@vger.kernel.org;
> t...@atomide.com; adrian.hun...@nokia.com
> Subject: Re: [PATCH v6] OMAP4 HSMMC: Adding Card detect support for MMC1
> on OMAP4
>
> Madhu,
>
> On Thu, Aug 5, 2010 at 4:26 AM, Madhusudhan wrote:
> >
> >
> >> >> > arch/arm/mach-omap2/board-4430sdp.c | 7 +++-
> >> >> > drivers/mfd/twl6030-irq.c | 76
> >> >> +++
> >> >> > drivers/mmc/host/omap_hsmmc.c | 4 +-
> >> >> > include/linux/i2c/twl.h | 16 +++
> >> >> > 4 files changed, 100 insertions(+), 3 deletions(-)
> >> >> >
> >> >> > diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-
> >> >> omap2/board-4430sdp.c
> >> >> > index f287461..388b96d 100644
> >> >> > --- a/arch/arm/mach-omap2/board-4430sdp.c
> >> >> > +++ b/arch/arm/mach-omap2/board-4430sdp.c
> >> >> > @@ -227,9 +227,14 @@ static int
> omap4_twl6030_hsmmc_late_init(struct
> >> >> device *dev)
> >> >> > struct omap_mmc_platform_data *pdata = dev->platform_data;
> >> >> >
> >> >> > /* Setting MMC1 Card detect Irq */
> >> >> > - if (pdev->id == 0)
> >> >> > + if (pdev->id == 0) {
> >> >> > + ret = twl6030_mmc_card_detect_config();
> >> >> > + if (ret)
> >> >> > + pr_err("Failed configuring MMC1 card
> >> detect\n");
> >> >> > pdata->slots[0].card_detect_irq = TWL6030_IRQ_BASE
> +
> >> >> >
> MMCDETECT_INTR_OFFSET;
> >> >> > + pdata->slots[0].card_detect =
> >> twl6030_mmc_card_detect;
> >
> > You are assigning an exported fn here.
> >
> > What if somebody disables CONFIG_TWL4030_CORE in the
> omap_4430sdp_defconfig
> > file? Does the driver behave nicely with only loosing the hotplug
> > capability?
>
> On mainline 2.6.35 omap3_defconfig works for OMAP4 but without hotplug
> functionality
> Disabling CONFIG_TWL4030_CORE in defconfig means disabling
> regulator's and eventually
> on bootup mmc host drivers probe fails as omap_hsmmc_reg_get( )
> fails. Seems like
> MMC and TWL are tightly coupled because of LDO dependency.
>
> With this V6 patch and omap3_defconfig , disabling CONFIG_TWL4030_CORE
> [also need to disable USB & comment board-devkit8000.c in
> mach-omap2/Makefile as they have dependency on
> twl_i2c_write_u8/twl_i2c_read_u8 defined in twl-core.c] doesn't
> compile due to undefined reference to those exported functions
> twl6030_mmc_card_detect_config & twl6030_mmc_card_detect .
>
> Having below one[in twl.h] in addition to V6 :
>
> /* Card detect Configuration for MMC1 Controller on OMAP4 */
> +#if defined(CONFIG_TWL4030_CORE)
> int twl6030_mmc_card_detect_config(void);
> +#else
> +static inline int twl6030_mmc_card_detect_config(void)
> +{
> + pr_err("twl6030_mmc_card_detect_config not supported\n");
> + return 0;
> +}
> +#endif
>
> /* MMC1 Controller on OMAP4 uses Phoenix irq for Card detect */
> +#if defined(CONFIG_TWL4030_CORE)
> int twl6030_mmc_card_detect(struct device *dev, int slot);
> -
> +#else
> +static inline int twl6030_mmc_card_detect(struct device *dev, int slot)
> +{
> + pr_err("Call back twl6030_mmc_card_detect not supported\n");
> + return -EIO;
> +}
> +#endif
>
> With the above change compilation as well as booting goes well but mmc
> probe
> fails.
>
> Shall I go with above changes and post V7 ?
>
Yes. In my opinion this is better than V6.
Regards,
Madhu
>
>
> Thanks ,
> Kishore
--
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
[PM-SR][PATCH 09/12] omap3: sr: enable/disable sr only if required
We dont need to go down the path of enabling/disabling the SR
if we dont need to. do some sanity check and trigger if needed
Cc: Kevin Hilman
Cc: Thara Gopinath
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/smartreflex.c | 19 +++
1 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index d63691b..9b5a10e 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -778,15 +778,26 @@ static int omap_sr_autocomp_show(void *data, u64 *val)
static int omap_sr_autocomp_store(void *data, u64 val)
{
struct omap_sr *sr_info = (struct omap_sr *) data;
+ u32 value = (u32) val;
if (!sr_info) {
pr_warning("%s: omap_sr struct for SR not found\n", __func__);
return -EINVAL;
}
- if (!val)
- sr_stop_vddautocomp(sr_info);
- else
- sr_start_vddautocomp(sr_info);
+
+ /* Sanity check */
+ if (value && (value != 1)) {
+ pr_err("%s: invalid value %d\n", __func__, value);
+ return -EINVAL;
+ }
+
+ /* change only if needed */
+ if (sr_info->is_autocomp_active ^ value) {
+ if (!val)
+ sr_stop_vddautocomp(sr_info);
+ else
+ sr_start_vddautocomp(sr_info);
+ }
return 0;
}
--
1.6.3.3
--
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
[PM-SR][PATCH 01/12] omap3: voltage: cleanup pr_xxxx
Few more pr_ need cleanup for printing the function name and
not using multiline prints when c allows us to do "".
Cc: Kevin Hilman
Cc: Thara Gopinath
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/voltage.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 148e4d4..3431fa3 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -253,8 +253,9 @@ static int vp_debug_set(void *data, u64 val)
u32 *option = data;
*option = val;
} else {
- pr_notice("DEBUG option not enabled!\n \
- echo 1 > pm_debug/enable_sr_vp_debug - to enable\n");
+ pr_notice("%s: DEBUG option not enabled! "
+ "echo 1 > pm_debug/enable_sr_vp_debug - to enable\n",
+ __func__);
}
return 0;
}
@@ -265,7 +266,7 @@ static int vp_volt_debug_get(void *data, u64 *val)
u8 vsel;
vsel = voltage_read_reg(info->vp_offs.voltage_reg);
- pr_notice("curr_vsel = %x\n", vsel);
+ pr_notice("%s: curr_vsel = %x\n", __func__, vsel);
*val = vsel * 12500 + 60;
return 0;
--
1.6.3.3
--
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
[PM-SR][PATCH 11/12] omap3: sr: sr_exit should be static
sr_exit has no business being a public function.
fixes sparse:
arch/arm/mach-omap2/smartreflex.c:959:13: warning: symbol 'sr_exit' was not
declared. Should it be static?
Cc: Kevin Hilman
Cc: Thara Gopinath
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/smartreflex.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 9b5a10e..a723ac7 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -968,7 +968,7 @@ static int __init sr_init(void)
return 0;
}
-void __exit sr_exit(void)
+static void __exit sr_exit(void)
{
platform_driver_unregister(&smartreflex_driver);
}
--
1.6.3.3
--
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
[PM-SR][PATCH 08/12] omap3: sr: cleanup pr_xxx
pr_xxx family is not informative for debug unless one decides
to grep the code, instead print the function to help debug
easier on the field.
Cc: Kevin Hilman
Cc: Thara Gopinath
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/smartreflex.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 57fc9b2..d63691b 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -804,8 +804,9 @@ static int omap_sr_params_store(void *data, u64 val)
u32 *option = data;
*option = val;
} else {
- pr_notice("DEBUG option not enabled!\n \
- echo 1 > pm_debug/enable_sr_vp_debug - to enable\n");
+ pr_notice("%s: DEBUG option not enabled! "
+ "echo 1 > pm_debug/enable_sr_vp_debug to enable\n",
+ __func__);
}
return 0;
}
--
1.6.3.3
--
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
[PM-SR][PATCH 07/12] omap3: sr: device: make omap_sr_latency static
omap_sr_latency definition does not need to be exposed to the world
but we cant make it __init data as the pointer is stored in odev
to be used beyond basic kernel boot.
also fixes sparse warning:
arch/arm/mach-omap2/sr_device.c:32:31: warning: symbol 'omap_sr_latency' was
not declared. Should it be static?
Cc: Kevin Hilman
Cc: Thara Gopinath
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/sr_device.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index 8fb60d8..e81 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -29,7 +29,7 @@
#include "voltage.h"
-struct omap_device_pm_latency omap_sr_latency[] = {
+static struct omap_device_pm_latency omap_sr_latency[] = {
{
.deactivate_func = omap_device_idle_hwmods,
.activate_func = omap_device_enable_hwmods,
--
1.6.3.3
--
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
[PM-SR][PATCH 02/12] omap3: voltage: make required variables static
debugfs voltage_dir - used only by voltage layer and no reason for
others to add data to it, so make it static.
volt_mod have no business being exposed as global. make it static
we dont expose omap3_vp_offs to the world and is __init data,
so make it static.
This fixes sparse warnings:
arch/arm/mach-omap2/voltage.c:42:15: warning: symbol 'voltage_dir' was not
declared. Should it be static?
arch/arm/mach-omap2/voltage.c:49:5: warning: symbol 'volt_mod' was not
declared. Should it be static?
arch/arm/mach-omap2/voltage.c:130:27: warning: symbol 'omap3_vp_offs' was not
declared. Should it be static?
Cc: Kevin Hilman
Cc: Thara Gopinath
Signed-off-by: Nishanth Menon
---
Note: i had initially considered splitting these into three seperate patches,
but these are too trivial.
arch/arm/mach-omap2/voltage.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 3431fa3..1a3d00d 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -39,14 +39,14 @@
#define VP_TRANXDONE_TIMEOUT 300
#ifdef CONFIG_PM_DEBUG
-struct dentry *voltage_dir;
+static struct dentry *voltage_dir;
#endif
/* VP SR debug support */
u32 enable_sr_vp_debug;
/* PRM voltage module */
-u32 volt_mod;
+static u32 volt_mod;
/* Voltage processor register offsets */
struct vp_reg_offs {
@@ -127,7 +127,7 @@ static struct omap_vdd_info *vdd_info;
static int no_scalable_vdd;
/* OMAP3 VP register offsets and other definitions */
-struct __init vp_reg_offs omap3_vp_offs[] = {
+static struct __init vp_reg_offs omap3_vp_offs[] = {
/* VP1 */
{
.vpconfig_reg = OMAP3_PRM_VP1_CONFIG_OFFSET,
--
1.6.3.3
--
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
[PM-SR][PATCH 12/12] omap3: sr: class3: make class3_data static
we dont expose the structure to the world, so this should be static
however, since sr core does not take a copy of the same, we cant make
it __init data.
fixes sparse warning:
arch/arm/mach-omap2/smartreflex-class3.c:50:36: warning: symbol 'class3_data'
was not declared. Should it be static?
Cc: Kevin Hilman
Cc: Thara Gopinath
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/smartreflex-class3.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex-class3.c
b/arch/arm/mach-omap2/smartreflex-class3.c
index f3b766f..530b2f0 100644
--- a/arch/arm/mach-omap2/smartreflex-class3.c
+++ b/arch/arm/mach-omap2/smartreflex-class3.c
@@ -47,7 +47,7 @@ static int sr_class3_configure(int id)
}
/* SR class3 structure */
-struct omap_smartreflex_class_data class3_data = {
+static struct omap_smartreflex_class_data class3_data = {
.enable = sr_class3_enable,
.disable = sr_class3_disable,
.configure = sr_class3_configure,
--
1.6.3.3
--
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
[PM-SR][PATCH 03/12] omap3: voltage: expose omap_change_voltscale_method
omap_change_voltscale_method is meant to be used for board files desiring to choose a different scaling technique. so this function should be exposed to the world. also fixes sparse warning: arch/arm/mach-omap2/voltage.c:1047:6: warning: symbol 'omap_change_voltscale_method' was not declared. Should it be static? Cc: Kevin Hilman Cc: Thara Gopinath Signed-off-by: Nishanth Menon --- arch/arm/mach-omap2/voltage.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h index a7be515..6dc8ce4 100644 --- a/arch/arm/mach-omap2/voltage.h +++ b/arch/arm/mach-omap2/voltage.h @@ -113,6 +113,7 @@ void omap_voltageprocessor_enable(int vp_id); void omap_voltageprocessor_disable(int vp_id); int omap_voltage_scale(int vdd, unsigned long target_volt); void omap_reset_voltage(int vdd); +void omap_change_voltscale_method(int voltscale_method); int omap_get_voltage_table(int vdd, struct omap_volt_data **volt_data); struct omap_volt_data *omap_get_volt_data(int vdd, unsigned long volt); void omap_voltage_register_pmic(struct omap_volt_pmic_info *pmic_info); -- 1.6.3.3 -- 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
[PM-SR][PATCH 10/12] omap3: sr: export sr_dbg_dir
sr_dbg_dir is currently used privately in smartreflex.c, however,
smartreflex class drivers could store their own debugfs entries there
as well.
This also fixes the sparse warning:
arch/arm/mach-omap2/smartreflex.c:44:15: warning: symbol 'sr_dbg_dir' was not
declared. Should it be static?
Cc: Kevin Hilman
Cc: Thara Gopinath
Signed-off-by: Nishanth Menon
---
arch/arm/plat-omap/include/plat/smartreflex.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/smartreflex.h
b/arch/arm/plat-omap/include/plat/smartreflex.h
index 1105db0..df58026 100644
--- a/arch/arm/plat-omap/include/plat/smartreflex.h
+++ b/arch/arm/plat-omap/include/plat/smartreflex.h
@@ -263,6 +263,11 @@ int omap_sr_register_class(struct
omap_smartreflex_class_data *class_data);
/* API to register the pmic specific data with the smartreflex driver. */
void omap_sr_register_pmic(struct omap_smartreflex_pmic_data *pmic_data);
+
+#ifdef CONFIG_PM_DEBUG
+extern struct dentry *sr_dbg_dir;
+#endif
+
#else
static inline void omap_smartreflex_enable(int srid) {}
static inline void omap_smartreflex_disable(int srid) {}
--
1.6.3.3
--
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
[PM-SR][PATCH 05/12] omap3: sr: device: check for dev_attr
In the unlikely case that hwmod database is messed up, dont crash
report error and attempt to recover.
Cc: Kevin Hilman
Cc: Thara Gopinath
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/sr_device.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index 7d13704..6f70da6 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -130,6 +130,12 @@ static int sr_dev_init(struct omap_hwmod *oh, void *user)
}
sr_dev_data = (struct omap_sr_dev_data *)oh->dev_attr;
+ if (unlikely(!sr_dev_data)) {
+ pr_err("%s: Bad oh->dev_attr!\n", __func__);
+ kfree(sr_data);
+ return -EINVAL;
+ }
+
/*
* OMAP3430 ES3.1 chips by default come with Efuse burnt
* with parameters required for full functionality of
--
1.6.3.3
--
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
[PM-SR][PATCH 04/12] omap3: sr: device: cleanup pr_xxx
Strings in c dont need to be split accross multiple lines with \
. instead they can be put as "abc " "def " and it is equivalent to
"abc def".
Cc: Kevin Hilman
Cc: Thara Gopinath
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/sr_device.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index dbf7603..7d13704 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -151,8 +151,9 @@ static int sr_dev_init(struct omap_hwmod *oh, void *user)
sr_dev_data->volts_supported = omap_get_voltage_table(i,
&sr_dev_data->volt_data);
if (!sr_dev_data->volts_supported) {
- pr_warning("%s: No Voltage table registerd fo VDD%d.Something \
- really wrong\n\n", __func__, i + 1);
+ pr_warning("%s: No Voltage table registerd fo VDD%d. "
+ "Something is really wrong\n",
+ __func__, i + 1);
i++;
kfree(sr_data);
return 0;
--
1.6.3.3
--
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 288/524] staging: tidspbridge: gen: simplify and clean up
From: Andy Shevchenko
There is recently added hex_to_bin() kernel's method which we could use
instead of custom long function.
Signed-off-by: Andy Shevchenko
Cc: Ohad Ben-Cohen
Cc: linux-omap@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/staging/tidspbridge/gen/uuidutil.c | 167 +---
1 files changed, 28 insertions(+), 139 deletions(-)
diff --git a/drivers/staging/tidspbridge/gen/uuidutil.c
b/drivers/staging/tidspbridge/gen/uuidutil.c
index ce9319d..eb09bc3 100644
--- a/drivers/staging/tidspbridge/gen/uuidutil.c
+++ b/drivers/staging/tidspbridge/gen/uuidutil.c
@@ -54,61 +54,19 @@ void uuid_uuid_to_string(IN struct dsp_uuid *uuid_obj, OUT
char *pszUuid,
DBC_ENSURE(i != -1);
}
-/*
- * htoi
- * Purpose:
- * Converts a hex value to a decimal integer.
- */
-
-static int htoi(char c)
+static s32 uuid_hex_to_bin(char *buf, s32 len)
{
- switch (c) {
- case '0':
- return 0;
- case '1':
- return 1;
- case '2':
- return 2;
- case '3':
- return 3;
- case '4':
- return 4;
- case '5':
- return 5;
- case '6':
- return 6;
- case '7':
- return 7;
- case '8':
- return 8;
- case '9':
- return 9;
- case 'A':
- return 10;
- case 'B':
- return 11;
- case 'C':
- return 12;
- case 'D':
- return 13;
- case 'E':
- return 14;
- case 'F':
- return 15;
- case 'a':
- return 10;
- case 'b':
- return 11;
- case 'c':
- return 12;
- case 'd':
- return 13;
- case 'e':
- return 14;
- case 'f':
- return 15;
+ s32 i;
+ s32 result = 0;
+
+ for (i = 0; i < len; i++) {
+ value = hex_to_bin(*buf++);
+ result *= 16;
+ if (value > 0)
+ result += value;
}
- return 0;
+
+ return result;
}
/*
@@ -118,106 +76,37 @@ static int htoi(char c)
*/
void uuid_uuid_from_string(IN char *pszUuid, OUT struct dsp_uuid *uuid_obj)
{
- char c;
- s32 i, j;
- s32 result;
- char *temp = pszUuid;
+ s32 j;
- result = 0;
- for (i = 0; i < 8; i++) {
- /* Get first character in string */
- c = *temp;
-
- /* Increase the results by new value */
- result *= 16;
- result += htoi(c);
-
- /* Go to next character in string */
- temp++;
- }
- uuid_obj->ul_data1 = result;
+ uuid_obj->ul_data1 = uuid_hex_to_bin(pszUuid, 8);
+ pszUuid += 8;
/* Step over underscore */
- temp++;
+ pszUuid++;
- result = 0;
- for (i = 0; i < 4; i++) {
- /* Get first character in string */
- c = *temp;
-
- /* Increase the results by new value */
- result *= 16;
- result += htoi(c);
-
- /* Go to next character in string */
- temp++;
- }
- uuid_obj->us_data2 = (u16) result;
+ uuid_obj->us_data2 = (u16) uuid_hex_to_bin(pszUuid, 4);
+ pszUuid += 4;
/* Step over underscore */
- temp++;
-
- result = 0;
- for (i = 0; i < 4; i++) {
- /* Get first character in string */
- c = *temp;
+ pszUuid++;
- /* Increase the results by new value */
- result *= 16;
- result += htoi(c);
-
- /* Go to next character in string */
- temp++;
- }
- uuid_obj->us_data3 = (u16) result;
+ uuid_obj->us_data3 = (u16) uuid_hex_to_bin(pszUuid, 4);
+ pszUuid += 4;
/* Step over underscore */
- temp++;
-
- result = 0;
- for (i = 0; i < 2; i++) {
- /* Get first character in string */
- c = *temp;
+ pszUuid++;
- /* Increase the results by new value */
- result *= 16;
- result += htoi(c);
+ uuid_obj->uc_data4 = (u8) uuid_hex_to_bin(pszUuid, 2);
+ pszUuid += 2;
- /* Go to next character in string */
- temp++;
- }
- uuid_obj->uc_data4 = (u8) result;
-
- result = 0;
- for (i = 0; i < 2; i++) {
- /* Get first character in string */
- c = *temp;
-
- /* Increase the results by new value */
- result *= 16;
- result += htoi(c);
-
- /* Go to next character in string */
- temp++;
- }
- uuid_obj->uc_data5 = (u8) result;
+ uuid_obj->uc_data5 = (u8) uuid_hex_to_bin(pszUuid, 2);
Re: PM branch updated to v2.6.35, SRF dropped
Nishanth Menon writes: > Kevin Hilman had written, on 08/04/2010 05:50 PM, the following: > [...] > >> I've only tested the new PM branch on a couple boards to avoid any >> further delay getting this version out, update, so hopefully others will >> help test. >> >> I've tested RET on idle & suspend, OFF in idle & suspend on: >> >> 3430/omap3evm: works >> >> 3630/Zoom3: works >> - Known problem: console hangs on UART wakeup when wakeups are enabled using >> echo enabled > /sys/devices/platform/serial8250.0/tty/ttyS0/power/wakeup >> but I haven't debugged this further. > > Just sharing results from SDP testing omap3_pm_defconfig + earlyprintk: > SDP3430 (with denx.com u-boot, nor boot): does not boot to shell > full Bootlog: http://pastebin.mozilla.org/761964 Does the same setup boot fine on l-o for-next, or l-o master? > SDP3630 (with TI u-boot, xloader, mmc boot): ret works, uart wakeup > fails for off mode (I am guessing this is similar to Kevin's results) > full Bootlog: http://pastebin.mozilla.org/761966 > OMAP4 Blaze (with TI u-boot, xloader, mmc boot): does not boot, hell > lot of crashes - note, need to explicitly enable MACH_OMAP4430_SDP in > .config > full Bootlog: http://pastebin.mozilla.org/761968 yeah, I don't expect PM branch to work on OMAP4 until we get the OMAP4 hwmod core upstream. Kevin -- 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] platform: Facilitate the creation of pseduo-platform busses
Patrick Pannuto writes: >> >>> You had indicated that you were going on vacation for a month and I >>> had not seen any more follow-up on this issue, so I forged ahead. >> >> Great, I'm glad you forged ahead. There is definitely a broader need >> for something like this, and I have no personal attachment to the code. >> >> I have no problems with you continuing the work (in fact, I'd prefer it. >> I have lots of other things to catch up on after my vacation.) >> >> In the future though, it's common (and kind) to note the original author >> in the changelog when basing a patch on previous work. Something like >> "originally written by..." or "based on the work of..." etc. > > Ok, I can do that; that was the intention of the "original inspiration from" > line at the beginning. Maybe we need an 'Inspired-by:' tag. :) > Is there a more formal way of indicating this in the > next version of the patch? Should I add you as a "From:" or an "Author:"? I don't know if there is an official way of doing this. I typically add something like "based on the idea/code originally proposed/written by John Doe" in the changelog, and then add Cc: John Doe <...> in the changelog too, but AFAIK, none of this is formalized. Kevin -- 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
[PM-SR][PATCH 00/12 v2] omap3: sr: janitor series
August revision of pending janitor patches for SR rebased on latest pm branch. Should be eventually squashed to the relevant SR patch prior to upstreaming. Note: this series is a merged series posted http://marc.info/?l=linux-omap&m=127741497415352&w=2 (June 24) http://marc.info/?l=linux-omap&m=127750241431955&w=2 (June 25) "omap3: sr: device: add unlikely checks" was dropped from this series based on Artem's guidance - none of the other patches have recieved any review comments so far. Nishanth Menon (12): omap3: voltage: cleanup pr_ omap3: voltage: make required variables static omap3: voltage: expose omap_change_voltscale_method omap3: sr: device: cleanup pr_xxx omap3: sr: device: check for dev_attr omap3: sr: device: fail sr_dev_init should return error omap3: sr: device: make omap_sr_latency static omap3: sr: cleanup pr_xxx omap3: sr: enable/disable sr only if required omap3: sr: export sr_dbg_dir omap3: sr: sr_exit should be static omap3: sr: class3: make class3_data static arch/arm/mach-omap2/smartreflex-class3.c |2 +- arch/arm/mach-omap2/smartreflex.c | 26 ++-- arch/arm/mach-omap2/sr_device.c | 16 +++--- arch/arm/mach-omap2/voltage.c | 13 ++- arch/arm/mach-omap2/voltage.h |1 + arch/arm/plat-omap/include/plat/smartreflex.h |5 6 files changed, 45 insertions(+), 18 deletions(-) Cc: Kevin Hilman Cc: Thara Gopinath Regards, Nishanth Menon -- 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
[PM-SR][PATCH 06/12] omap3: sr: device: fail sr_dev_init should return error
sr_dev_init should return error on error conditions
Cc: Kevin Hilman
Cc: Thara Gopinath
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/sr_device.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index 6f70da6..8fb60d8 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -162,7 +162,7 @@ static int sr_dev_init(struct omap_hwmod *oh, void *user)
__func__, i + 1);
i++;
kfree(sr_data);
- return 0;
+ return -ENODATA;
}
sr_set_nvalues(sr_dev_data, sr_data);
od = omap_device_build(name, i, oh, sr_data, sizeof(*sr_data),
@@ -172,6 +172,7 @@ static int sr_dev_init(struct omap_hwmod *oh, void *user)
pr_warning("%s: Could not build omap_device for %s: %s.\n\n",
__func__, name, oh->name);
kfree(sr_data);
+ return PTR_ERR(od);
}
i++;
return 0;
--
1.6.3.3
--
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] platform: Facilitate the creation of pseduo-platform busses
On 08/04/2010 07:32 PM, Magnus Damm wrote:
> On Thu, Aug 5, 2010 at 7:14 AM, Patrick Pannuto
> wrote:
>> Inspiration for this comes from:
>> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31161.html
>>
>> RFC: http://lkml.org/lkml/2010/8/3/496
>> Patch is unchanged from the RFC. Reviews seemed generally positive
>> and it seemed this was desired functionality.
>
> Thanks for your patch, it's really nice to see work done in this area!
> I'd like to see something like this merged in the not so distant
> future. At this point I'm not so concerned about the details, so I'll
> restrict myself to this:
>
>> /drivers/my_driver.c
>>static struct platform_driver my_driver = {
>>.driver = {
>>.name = "my-driver",
>>.owner = THIS_MODULE,
>>.bus= &my_bus_type,
>>},
>>};
>
> I would really prefer not to have the bus type in the here. I
> understand it's needed at this point, but I wonder if it's possible to
> adjust the device<->driver matching for platform devices to allow any
> type of pseudo-platform bus_type.
>
> The reason why I'd like to avoid having the bus type in the driver is
> that I'd like to reuse the platform driver across multiple
> architectures and buses. For instance, on the SH architecture and
So would I :). That's where this was all heading eventually, I was just
originally doing it in two passes. I have some ideas for how to do this
and will try to send out a patchset either today or tomorrow.
> SH-Mobile ARM we have SoCs with SCIF hardware blocks driven by the
> sh-sci.c serial driver. The sh-sci.c platform driver supports a wide
> range of different SCI(F)(A)(B) hardware blocks, and on any given SoC
> there is a mix of SCIF blocks spread out on different buses.
>
> At this point our SH platform drivers are unaware where their driver
> instanced are located on the SoC. The I/O address and IRQs are
> assigned via struct resource and clocks are managed through clkdev. I
> believe that adding the bus type in the driver will violate this
> abstraction and make it more difficult to just instantiate a driver
> somewhere on the SoC.
>
>> /somewhere/my_device.c
>>static struct platform_device my_device = {
>>.name = "my-device",
>>.id = -1,
>>.dev.bus= &my_bus_type,
>>.dev.parent = &sub_bus_1.dev,
>>};
>
> This I don't mind at all. Actually, this is the place where the
> topology should be defined IMO.
>
Agreed.
> Cheers,
>
> / magnus
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
--
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] platform: Facilitate the creation of pseduo-platform busses
[snip]
Which will allow the same driver to easily to used on either
the platform bus or the newly defined bus type.
>>>
>>> Except it requires a re-compile.
>>>
>>> Rather than doing this at compile time, it would be better to support
>>> legacy devices at runtime. You could handle this by simply registering
>>> the driver on the custom bus and the platform_bus and let the bus
>>> matching code handle it. Then, the same binary would work on both
>>> legacy and updated SoCs.
>>>
>>
>> Can you safely register a driver on more than one bus? I didn't think
>> that was safe -- normally it's impossible since you're calling
>>
>> struct BUS_TYPE_driver mydriver;
>> BUS_TYPE_driver_register(&mydriver)
>>
>> but now we have multiple "bus types" that are all actually platform type;
>> still,
>> at a minimum you would need:
>> struct platform_driver mydrvier1 = {
>> .driver.bus = &sub_bus1,
>> };
>> struct platform_driver mydrvier2 = {
>> .driver.bus = &sub_bus2,
>> };
>> which would all point to the same driver functions, yet the respective
>> devices
>> attached for the "same" driver would be on different buses. I fear this might
>> confuse some drivers. I don't think dynamic bus assignment is this easy
>>
>> In short: I do not believe the same driver can be registered on multiple
>> different buses -- if this is wrong, please correct me.
>
> It is possible, and currently done in powerpc land where some
> drivers handle devices on the platform_bus and the custom OF bus.
>
> However, as noted by Magnus, what we really need here is a way for
> drivers to not care at all what kind of bus they are on. There are an
> increasing number of drivers that are re-used not just across different
> SoCs in the same family, but across totally different SoCs (e.g. drivers
> for hardware shared between TI OMAP and TI DaVinci, or SH and SH-Mobile/ARM)
>
I will start trying to work on this
>>>
>>> Up to here, this looks exactly what I wrote in thread referenced
>>> above.
>>>
>>
>> It is, you just went on vacation :)
>>
>
> Ah, OK. The changelog was missing credits to that affect, but I was
> more concerned that you hadn't seen my example and didn't want to be
> duplicating work.
>
will fix.
[snip]
>
>> if you call it second then they will all already be well-defined and
>> thus not overwritten.
>
> Right, they will not be overwritten, but you'll be left with a mostly
> empty dev_pm_ops on the custom bus.
>
> IOW, Most of these custom busses will only want to customize a small
> subset of the dev_pm_ops methods (e.g. only the runtime PM methods.) If
> you setup your sparsly populated custom dev_pm_ops and then call
> platform_bus_type_init() second, dev_pm_ops on the new buswill have *only*
> your custom fields, and none of the defaults from platform_dev_pm_ops.
>
> So, what I was getting at is that it should probably be clearer to the
> users of platform_bus_type_init() that any customization of dev_pm_ops
> should be done after.
>
I understand what you're saying now, and I can fix this as well.
>
>>
>> If you would like to lead this effort, please do so; I did not mean to step
>> on your toes, it's just that this is an issue for me as well.
>
> No worries there, my toes are fine. :)
Good :)
>
>> You had indicated that you were going on vacation for a month and I
>> had not seen any more follow-up on this issue, so I forged ahead.
>
> Great, I'm glad you forged ahead. There is definitely a broader need
> for something like this, and I have no personal attachment to the code.
>
> I have no problems with you continuing the work (in fact, I'd prefer it.
> I have lots of other things to catch up on after my vacation.)
>
> In the future though, it's common (and kind) to note the original author
> in the changelog when basing a patch on previous work. Something like
> "originally written by..." or "based on the work of..." etc.
Ok, I can do that; that was the intention of the "original inspiration from"
line at the beginning. Is there a more formal way of indicating this in the
next version of the patch? Should I add you as a "From:" or an "Author:"?
-Pat
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
--
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: Board mux entries ignored?
On Wed, Aug 4, 2010 at 11:54 PM, Tony Lindgren wrote:
> * John Faith [100804 22:22]:
>> Hi,
>> I'm trying to set mux modes for a 3530, package CBC in my board.c
>> (2.6.32 kernel) using an omap_board_mux entry:
>> OMAP3_MUX(GPMC_WAIT1, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
>>
>> , but sysfs reports mode4:
>> # grep WAIT1 /sys/kernel/debug/omap_mux/board
>> OMAP3_MUX(GPMC_WAIT1, OMAP_PIN_INPUT | OMAP_MUX_MODE4),
>>
>> I tried adding to bootargs "omap_mux=gpmc_wait1.gpmc_wait1=0x100", but
>> still got MODE4. Doing "echo 0x100 >
>> /sys/kernel/debug/omap_mux/gpmc_wait1" gave me MODE0, but I'd prefer
>> to init pins in board.c. I've also noticed for pin SDMMC2_DAT3 that
>> my OMAP3_MUX() entry specifies MODE1, but sysfs shows MODE4; it
>> changed to MODE1 after adding:
>> omap_mux_init_signal("mcspi3_cs0", OMAP_PIN_OUTPUT);
>>
>> Is just having the mode in omap_board_mux entries sufficient?
>
> Hmm that should be enough. Does dmesg | grep -i mux show any errors?
>
> You do have CONFIG_OMAP_MUX set, right? Otherwise omap_mux_init_signals
> does not do anything, and the mux code just builds a list of GPIO
> pins for PM runtime muxing (not implemented yet).
Hi,
Yes, CONFIG_OMAP_MUX is set. The only non-wait1 error I saw was:
mux: Multiple signal paths (3) for mcspi3_cs0
With CONFIG_OMAP_MUX_DEBUG I now see that after mode0 is set, later
it's set to mode4:
# dmesg | grep -i wait1
mux: Setting signal gpmc_wait1.gpmc_wait1 0x0100 -> 0x0100
mux: Setting signal gpmc_wait1.gpio63 0x0100 -> 0x0104
The same pin was enabled for a different config, fixed with an ifdef.
Thanks!
,
John
--
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 v6] OMAP4 HSMMC: Adding Card detect support for MMC1 on OMAP4
Madhu,
On Thu, Aug 5, 2010 at 4:26 AM, Madhusudhan wrote:
>
>
>> >> > arch/arm/mach-omap2/board-4430sdp.c | 7 +++-
>> >> > drivers/mfd/twl6030-irq.c | 76
>> >> +++
>> >> > drivers/mmc/host/omap_hsmmc.c | 4 +-
>> >> > include/linux/i2c/twl.h | 16 +++
>> >> > 4 files changed, 100 insertions(+), 3 deletions(-)
>> >> >
>> >> > diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-
>> >> omap2/board-4430sdp.c
>> >> > index f287461..388b96d 100644
>> >> > --- a/arch/arm/mach-omap2/board-4430sdp.c
>> >> > +++ b/arch/arm/mach-omap2/board-4430sdp.c
>> >> > @@ -227,9 +227,14 @@ static int omap4_twl6030_hsmmc_late_init(struct
>> >> device *dev)
>> >> > struct omap_mmc_platform_data *pdata = dev->platform_data;
>> >> >
>> >> > /* Setting MMC1 Card detect Irq */
>> >> > - if (pdev->id == 0)
>> >> > + if (pdev->id == 0) {
>> >> > + ret = twl6030_mmc_card_detect_config();
>> >> > + if (ret)
>> >> > + pr_err("Failed configuring MMC1 card
>> detect\n");
>> >> > pdata->slots[0].card_detect_irq = TWL6030_IRQ_BASE +
>> >> > MMCDETECT_INTR_OFFSET;
>> >> > + pdata->slots[0].card_detect =
>> twl6030_mmc_card_detect;
>
> You are assigning an exported fn here.
>
> What if somebody disables CONFIG_TWL4030_CORE in the omap_4430sdp_defconfig
> file? Does the driver behave nicely with only loosing the hotplug
> capability?
On mainline 2.6.35 omap3_defconfig works for OMAP4 but without hotplug
functionality
Disabling CONFIG_TWL4030_CORE in defconfig means disabling
regulator's and eventually
on bootup mmc host drivers probe fails as omap_hsmmc_reg_get( )
fails. Seems like
MMC and TWL are tightly coupled because of LDO dependency.
With this V6 patch and omap3_defconfig , disabling CONFIG_TWL4030_CORE
[also need to disable USB & comment board-devkit8000.c in
mach-omap2/Makefile as they have dependency on
twl_i2c_write_u8/twl_i2c_read_u8 defined in twl-core.c] doesn't
compile due to undefined reference to those exported functions
twl6030_mmc_card_detect_config & twl6030_mmc_card_detect .
Having below one[in twl.h] in addition to V6 :
/* Card detect Configuration for MMC1 Controller on OMAP4 */
+#if defined(CONFIG_TWL4030_CORE)
int twl6030_mmc_card_detect_config(void);
+#else
+static inline int twl6030_mmc_card_detect_config(void)
+{
+ pr_err("twl6030_mmc_card_detect_config not supported\n");
+ return 0;
+}
+#endif
/* MMC1 Controller on OMAP4 uses Phoenix irq for Card detect */
+#if defined(CONFIG_TWL4030_CORE)
int twl6030_mmc_card_detect(struct device *dev, int slot);
-
+#else
+static inline int twl6030_mmc_card_detect(struct device *dev, int slot)
+{
+ pr_err("Call back twl6030_mmc_card_detect not supported\n");
+ return -EIO;
+}
+#endif
With the above change compilation as well as booting goes well but mmc probe
fails.
Shall I go with above changes and post V7 ?
Thanks ,
Kishore
--
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] platform: Facilitate the creation of pseduo-platform busses
Patrick Pannuto writes:
> On 08/04/2010 05:16 PM, Kevin Hilman wrote:
>> Patrick Pannuto writes:
>>
>>> Inspiration for this comes from:
>>> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31161.html
>>
>> Also, later in that thread I also wrote[1] what seems to be the core of
>> what you've done here: namely, allow platform_devices and
>> platform_drivers to to be used on custom busses. Patch is at the end of
>> this mail with a more focused changelog. As Greg suggested in his reply
>> to your first version, this part could be merged today, and the
>> platform_bus_init stuff could be added later, after some more review.
>> Some comments below...
>>
>
> I can split this into 2 patches.
Yes, I think that would be better.
> Was your patch sent to linux-kernel or just linux-omap? I'm not on
> linux-omap...
That thread was on linux-arm-kernel and linux-omap
>
>>> [snip]
>>>
>>> Which will allow the same driver to easily to used on either
>>> the platform bus or the newly defined bus type.
>>
>> Except it requires a re-compile.
>>
>> Rather than doing this at compile time, it would be better to support
>> legacy devices at runtime. You could handle this by simply registering
>> the driver on the custom bus and the platform_bus and let the bus
>> matching code handle it. Then, the same binary would work on both
>> legacy and updated SoCs.
>>
>
> Can you safely register a driver on more than one bus? I didn't think
> that was safe -- normally it's impossible since you're calling
>
> struct BUS_TYPE_driver mydriver;
> BUS_TYPE_driver_register(&mydriver)
>
> but now we have multiple "bus types" that are all actually platform type;
> still,
> at a minimum you would need:
> struct platform_driver mydrvier1 = {
> .driver.bus = &sub_bus1,
> };
> struct platform_driver mydrvier2 = {
> .driver.bus = &sub_bus2,
> };
> which would all point to the same driver functions, yet the respective devices
> attached for the "same" driver would be on different buses. I fear this might
> confuse some drivers. I don't think dynamic bus assignment is this easy
>
> In short: I do not believe the same driver can be registered on multiple
> different buses -- if this is wrong, please correct me.
It is possible, and currently done in powerpc land where some
drivers handle devices on the platform_bus and the custom OF bus.
However, as noted by Magnus, what we really need here is a way for
drivers to not care at all what kind of bus they are on. There are an
increasing number of drivers that are re-used not just across different
SoCs in the same family, but across totally different SoCs (e.g. drivers
for hardware shared between TI OMAP and TI DaVinci, or SH and SH-Mobile/ARM)
>>
>> Up to here, this looks exactly what I wrote in thread referenced
>> above.
>>
>
> It is, you just went on vacation :)
>
Ah, OK. The changelog was missing credits to that affect, but I was
more concerned that you hadn't seen my example and didn't want to be
duplicating work.
>>>
>>> if (code != retval)
>>> platform_driver_unregister(drv);
>>> @@ -1017,6 +1019,26 @@ struct bus_type platform_bus_type = {
>>> };
>>> EXPORT_SYMBOL_GPL(platform_bus_type);
>>>
>>> +/** platform_bus_type_init - fill in a pseudo-platform-bus
>>> + * @bus: foriegn bus type
>>> + *
>>> + * This init is basically a selective memcpy that
>>> + * won't overwrite any user-defined attributes and
>>> + * only copies things that platform bus defines anyway
>>> + */
>>
>> minor nit: kernel doc style has wrong indentation
>>
>
> will fix
>
>>> +void platform_bus_type_init(struct bus_type *bus)
>>> +{
>>> + if (!bus->dev_attrs)
>>> + bus->dev_attrs = platform_bus_type.dev_attrs;
>>> + if (!bus->match)
>>> + bus->match = platform_bus_type.match;
>>> + if (!bus->uevent)
>>> + bus->uevent = platform_bus_type.uevent;
>>> + if (!bus->pm)
>>> + bus->pm = platform_bus_type.pm;
>>> +}
>>> +EXPORT_SYMBOL_GPL(platform_bus_type_init);
>>
>> With this approach, you should note in the comments/changelog that
>> any selective customization of the bus PM methods must be done after
>> calling platform_bus_type_init().
>
> No they don't. If you call platform_bus_type_init first then you'll
> just overwrite them with new values;
Yes.
> if you call it second then they will all already be well-defined and
> thus not overwritten.
Right, they will not be overwritten, but you'll be left with a mostly
empty dev_pm_ops on the custom bus.
IOW, Most of these custom busses will only want to customize a small
subset of the dev_pm_ops methods (e.g. only the runtime PM methods.) If
you setup your sparsly populated custom dev_pm_ops and then call
platform_bus_type_init() second, dev_pm_ops on the new buswill have *only*
your custom fields, and none of the defaults from platform_dev_pm_ops.
So, what I was getting at is that it should probably be clearer to th
[PATCH v3 7/7] OMAP: hwmod: Temporary prevent reset during _setup for I2Cs
For some reason, I2C 1, 2, 3 and 4 does not return the resetdone
status after a softreset.
Prevent the softreset until the root cause is found.
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
Cc: Kevin Hilman
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 5d440d5..9736a49 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2268,6 +2268,7 @@ static struct omap_hwmod_ocp_if *omap44xx_i2c1_slaves[] =
{
static struct omap_hwmod omap44xx_i2c1_hwmod = {
.name = "i2c1",
.class = &omap44xx_i2c_hwmod_class,
+ .flags = HWMOD_INIT_NO_RESET,
.mpu_irqs = omap44xx_i2c1_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_i2c1_irqs),
.sdma_reqs = omap44xx_i2c1_sdma_reqs,
@@ -2320,6 +2321,7 @@ static struct omap_hwmod_ocp_if *omap44xx_i2c2_slaves[] =
{
static struct omap_hwmod omap44xx_i2c2_hwmod = {
.name = "i2c2",
.class = &omap44xx_i2c_hwmod_class,
+ .flags = HWMOD_INIT_NO_RESET,
.mpu_irqs = omap44xx_i2c2_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_i2c2_irqs),
.sdma_reqs = omap44xx_i2c2_sdma_reqs,
@@ -2372,6 +2374,7 @@ static struct omap_hwmod_ocp_if *omap44xx_i2c3_slaves[] =
{
static struct omap_hwmod omap44xx_i2c3_hwmod = {
.name = "i2c3",
.class = &omap44xx_i2c_hwmod_class,
+ .flags = HWMOD_INIT_NO_RESET,
.mpu_irqs = omap44xx_i2c3_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_i2c3_irqs),
.sdma_reqs = omap44xx_i2c3_sdma_reqs,
@@ -2424,6 +2427,7 @@ static struct omap_hwmod_ocp_if *omap44xx_i2c4_slaves[] =
{
static struct omap_hwmod omap44xx_i2c4_hwmod = {
.name = "i2c4",
.class = &omap44xx_i2c_hwmod_class,
+ .flags = HWMOD_INIT_NO_RESET,
.mpu_irqs = omap44xx_i2c4_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_i2c4_irqs),
.sdma_reqs = omap44xx_i2c4_sdma_reqs,
--
1.6.1.3
--
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 v3 6/7] OMAP: hwmod: Temporary prevent reset during _setup for GPIOs
For some reason, GPIO 2, 3, 4, 5 and 6 does not return the resetdone
status after a softreset.
The reset still seems to work fine becasue all the other registers
are reset with the default values.
Prevent the softreset until the root cause is found.
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
Cc: Kevin Hilman
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 83a208d..5d440d5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -1704,6 +1704,7 @@ static struct omap_hwmod_opt_clk gpio2_opt_clks[] = {
static struct omap_hwmod omap44xx_gpio2_hwmod = {
.name = "gpio2",
.class = &omap44xx_gpio_hwmod_class,
+ .flags = HWMOD_INIT_NO_RESET,
.mpu_irqs = omap44xx_gpio2_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_gpio2_irqs),
.main_clk = "gpio2_ick",
@@ -1755,6 +1756,7 @@ static struct omap_hwmod_opt_clk gpio3_opt_clks[] = {
static struct omap_hwmod omap44xx_gpio3_hwmod = {
.name = "gpio3",
.class = &omap44xx_gpio_hwmod_class,
+ .flags = HWMOD_INIT_NO_RESET,
.mpu_irqs = omap44xx_gpio3_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_gpio3_irqs),
.main_clk = "gpio3_ick",
@@ -1806,6 +1808,7 @@ static struct omap_hwmod_opt_clk gpio4_opt_clks[] = {
static struct omap_hwmod omap44xx_gpio4_hwmod = {
.name = "gpio4",
.class = &omap44xx_gpio_hwmod_class,
+ .flags = HWMOD_INIT_NO_RESET,
.mpu_irqs = omap44xx_gpio4_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_gpio4_irqs),
.main_clk = "gpio4_ick",
@@ -1857,6 +1860,7 @@ static struct omap_hwmod_opt_clk gpio5_opt_clks[] = {
static struct omap_hwmod omap44xx_gpio5_hwmod = {
.name = "gpio5",
.class = &omap44xx_gpio_hwmod_class,
+ .flags = HWMOD_INIT_NO_RESET,
.mpu_irqs = omap44xx_gpio5_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_gpio5_irqs),
.main_clk = "gpio5_ick",
@@ -1908,6 +1912,7 @@ static struct omap_hwmod_opt_clk gpio6_opt_clks[] = {
static struct omap_hwmod omap44xx_gpio6_hwmod = {
.name = "gpio6",
.class = &omap44xx_gpio_hwmod_class,
+ .flags = HWMOD_INIT_NO_RESET,
.mpu_irqs = omap44xx_gpio6_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_gpio6_irqs),
.main_clk = "gpio6_ick",
--
1.6.1.3
--
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 v3 4/7] OMAP4: hwmod: Add TIMER data for OMAP4430 ES1 & ES2
Add the data for the 11 timers IPs.
OMAP4 contains two differents IP variants for the timers:
- 8 x regular timer (3, 4, 5, 6, 7, 8, 9 & 11)
- 3 x 1ms timer (1, 2 & 10)
The regular timers registers programming model was changed due to the
adaptation to the new IP interface. Unfortunately the 1ms version
still use the previous programming model. The driver will have
to take care of theses differences.
Please note that the capability and the partitioning is also
different depending of the instance.
- timer 1 is inside the wakeup domain
- timers 5, 6, 7 & 8 are inside in the ABE (audio backend)
- timers 2, 3, 4, 9, 10 & 11 are inside the PER power domain
The timer was previously named gptimerX or dmtimerX, it is
now simply named timerX.
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
Cc: Kevin Hilman
Cc: Rajendra Nayak
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 619
1 files changed, 619 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index e20b0ee..e6aeb57 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -452,6 +452,613 @@ static struct omap_hwmod omap44xx_mpu_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/*
+ * 'timer' class
+ * general purpose timer module with accurate 1ms tick
+ * This class contains several variants: ['timer_1ms', 'timer']
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_timer_1ms_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE |
+ SYSS_MISSING),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_timer_1ms_hwmod_class = {
+ .name = "timer_1ms",
+ .sysc = &omap44xx_timer_1ms_sysc,
+};
+
+static struct omap_hwmod_class_sysconfig omap44xx_timer_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_EMUFREE |
+ SYSC_HAS_SOFTRESET | SYSS_MISSING),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= &omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_timer_hwmod_class = {
+ .name = "timer",
+ .sysc = &omap44xx_timer_sysc,
+};
+
+/* timer1 */
+static struct omap_hwmod omap44xx_timer1_hwmod;
+static struct omap_hwmod_irq_info omap44xx_timer1_irqs[] = {
+ { .irq = 37 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_timer1_addrs[] = {
+ {
+ .pa_start = 0x4a318000,
+ .pa_end = 0x4a31807f,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_wkup -> timer1 */
+static struct omap_hwmod_ocp_if omap44xx_l4_wkup__timer1 = {
+ .master = &omap44xx_l4_wkup_hwmod,
+ .slave = &omap44xx_timer1_hwmod,
+ .clk= "l4_wkup_clk_mux_ck",
+ .addr = omap44xx_timer1_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_timer1_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* timer1 slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_timer1_slaves[] = {
+ &omap44xx_l4_wkup__timer1,
+};
+
+static struct omap_hwmod omap44xx_timer1_hwmod = {
+ .name = "timer1",
+ .class = &omap44xx_timer_1ms_hwmod_class,
+ .mpu_irqs = omap44xx_timer1_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_timer1_irqs),
+ .main_clk = "timer1_fck",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_WKUP_TIMER1_CLKCTRL,
+ },
+ },
+ .slaves = omap44xx_timer1_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_timer1_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/* timer2 */
+static struct omap_hwmod omap44xx_timer2_hwmod;
+static struct omap_hwmod_irq_info omap44xx_timer2_irqs[] = {
+ { .irq = 38 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_timer2_addrs[] = {
+ {
+ .pa_start = 0x48032000,
+ .pa_end = 0x4803207f,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_per -> timer2 */
+static struct omap_hwmod_ocp_if omap44xx_l4_per__timer2 = {
+ .master = &omap44xx_l4_per_hwmod,
+ .slave = &omap44xx_timer2_hwmod,
+ .clk= "l4_div_ck",
+ .addr = omap44xx_timer2_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_timer2_addrs),
+ .user =
[PATCH v3 2/7] OMAP4: clock: Fix clock names and align with hwmod names
The OMAP4 hwmod data introduced the new naming convention for TI
IPs (See patch OMAP4: hwmod: Add partial hwmod support for OMAP4430 ES1.0)
The leaf clock names are using the same IP name and thus must be
modified to match the clock populated in the hwmod data.
- Fix some leaf clocks nodes that were using a _iclk instead of the _fclk
prefix.
- Fix some wrong interface clock name for master IPs connected to
interconnect.
Please not that due to the fact that nodes are sorted by name, the name
change will introduce a quite ugly diff a little bit hard to follow.
Timers clock con_id is still using the old gptX_fck name until the
gptimer driver is updated to omap_device framework.
Timers entries in hwmods DB are still disabled until the migration
if timer to platform_driver + omap_hwmod.
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
Cc: Rajendra Nayak
---
arch/arm/mach-omap2/clock44xx_data.c | 715 --
1 files changed, 335 insertions(+), 380 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index e10db7a..a0e369e 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -22,7 +22,6 @@
#include
#include
#include
-
#include
#include
@@ -914,6 +913,7 @@ static struct clk usb_hs_clk_div_ck = {
static struct dpll_data dpll_usb_dd = {
.mult_div1_reg = OMAP4430_CM_CLKSEL_DPLL_USB,
.clk_bypass = &usb_hs_clk_div_ck,
+ .flags = DPLL_J_TYPE | DPLL_NO_DCO_SEL,
.clk_ref= &dpll_sys_ref_clk,
.control_reg= OMAP4430_CM_CLKMODE_DPLL_USB,
.modes = (1 << DPLL_LOW_POWER_BYPASS) | (1 << DPLL_LOCKED),
@@ -927,7 +927,6 @@ static struct dpll_data dpll_usb_dd = {
.max_multiplier = OMAP4430_MAX_DPLL_MULT,
.max_divider= OMAP4430_MAX_DPLL_DIV,
.min_divider= 1,
- .flags = DPLL_J_TYPE | DPLL_NO_DCO_SEL
};
@@ -1284,16 +1283,6 @@ static struct clk aess_fck = {
.recalc = &followparent_recalc,
};
-static struct clk cust_efuse_fck = {
- .name = "cust_efuse_fck",
- .ops= &clkops_omap2_dflt,
- .enable_reg = OMAP4430_CM_CEFUSE_CEFUSE_CLKCTRL,
- .enable_bit = OMAP4430_MODULEMODE_SWCTRL,
- .clkdm_name = "l4_cefuse_clkdm",
- .parent = &sys_clkin_ck,
- .recalc = &followparent_recalc,
-};
-
static struct clk des3des_fck = {
.name = "des3des_fck",
.ops= &clkops_omap2_dflt,
@@ -1344,6 +1333,16 @@ static struct clk dmic_fck = {
.clkdm_name = "abe_clkdm",
};
+static struct clk dsp_fck = {
+ .name = "dsp_fck",
+ .ops= &clkops_omap2_dflt,
+ .enable_reg = OMAP4430_CM_TESLA_TESLA_CLKCTRL,
+ .enable_bit = OMAP4430_MODULEMODE_HWCTRL,
+ .clkdm_name = "tesla_clkdm",
+ .parent = &dpll_iva_m4_ck,
+ .recalc = &followparent_recalc,
+};
+
static struct clk dss_fck = {
.name = "dss_fck",
.ops= &clkops_omap2_dflt,
@@ -1354,18 +1353,18 @@ static struct clk dss_fck = {
.recalc = &followparent_recalc,
};
-static struct clk ducati_ick = {
- .name = "ducati_ick",
+static struct clk efuse_ctrl_cust_fck = {
+ .name = "efuse_ctrl_cust_fck",
.ops= &clkops_omap2_dflt,
- .enable_reg = OMAP4430_CM_DUCATI_DUCATI_CLKCTRL,
- .enable_bit = OMAP4430_MODULEMODE_HWCTRL,
- .clkdm_name = "ducati_clkdm",
- .parent = &ducati_clk_mux_ck,
+ .enable_reg = OMAP4430_CM_CEFUSE_CEFUSE_CLKCTRL,
+ .enable_bit = OMAP4430_MODULEMODE_SWCTRL,
+ .clkdm_name = "l4_cefuse_clkdm",
+ .parent = &sys_clkin_ck,
.recalc = &followparent_recalc,
};
-static struct clk emif1_ick = {
- .name = "emif1_ick",
+static struct clk emif1_fck = {
+ .name = "emif1_fck",
.ops= &clkops_omap2_dflt,
.enable_reg = OMAP4430_CM_MEMIF_EMIF_1_CLKCTRL,
.enable_bit = OMAP4430_MODULEMODE_HWCTRL,
@@ -1375,8 +1374,8 @@ static struct clk emif1_ick = {
.recalc = &followparent_recalc,
};
-static struct clk emif2_ick = {
- .name = "emif2_ick",
+static struct clk emif2_fck = {
+ .name = "emif2_fck",
.ops= &clkops_omap2_dflt,
.enable_reg = OMAP4430_CM_MEMIF_EMIF_2_CLKCTRL,
.enable_bit = OMAP4430_MODULEMODE_HWCTRL,
@@ -1407,42 +1406,14 @@ static struct clk fdif_fck = {
.clkdm_name = "iss_clkdm",
};
-static const struct clksel per_sgx_fclk_div[] = {
- { .parent = &dpll_per_m2x2_ck, .rates = div3_1to4_rates },
- { .parent = NULL },
-};
-
-static struct clk per_sgx_fclk = {
- .name = "per_sgx_fclk",
-
[PATCH v3 3/7] OMAP4: pm: Change l3_main to l3_main_1 during bus device init
The OMAP4 L3 interconnect is split in 3 part for power saving reason.
Because of that there is no l3_main like on OMAP2 & 3 but 3 differentes
l3_main_X instances.
In the case of OMAP4, query only the l3_main_1 part. The clock and
voltage are shared across the 3 instances.
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
Cc: Kevin Hilman
---
arch/arm/mach-omap2/pm.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 68f9f2e..89e8125 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -70,7 +70,10 @@ static void omap2_init_processor_devices(void)
{
_init_omap_device("mpu", &mpu_dev);
_init_omap_device("iva", &dsp_dev);
- _init_omap_device("l3_main", &l3_dev);
+ if (cpu_is_omap44xx())
+ _init_omap_device("l3_main_1", &l3_dev);
+ else
+ _init_omap_device("l3_main", &l3_dev);
}
static int __init omap2_common_pm_init(void)
--
1.6.1.3
--
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 v3 1/7] OMAP4: hwmod: Add initial data for OMAP4430 ES1 & ES2
The current version contains only the interconnects and the
mpu hwmods.
The remaining hwmods will be introduced by further patches on
top of this one.
- enable as well omap_hwmod.c build for OMAP4 Soc
Please not that this file uses the new naming convention for
naming HW IPs. This convention will be backported soon for previous
OMAP2 & 3 data files.
new nametrm name
- ---
counter_32k synctimer_32k
l3_main l3
timerX gptimerX / dmtimerX
mmcXmmchsX / sdmmcX
dma_system sdma
smartreflex_X sr_X / sr?
usb_host_fs usbfshost
usb_otg_hs hsusbotg
usb_tll_hs usbtllhs_config
wd_timerX wdtimerX
ipu cortexm3 / ducati
dsp c6x / tesla
iva ivahd / iva2.2
kbd kbdocp / keyboard
mailbox system_mailbox
mpu cortexa9 / chiron
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
Cc: Kevin Hilman
Cc: Rajendra Nayak
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/io.c |7 +-
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 482 ++
arch/arm/plat-omap/Makefile |2 +-
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
5 files changed, 489 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap_hwmod_44xx_data.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 2f2b25b..cc0df1b 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -88,6 +88,7 @@ obj-$(CONFIG_ARCH_OMAP2430) += opp2430_data.o
obj-$(CONFIG_ARCH_OMAP2420)+= omap_hwmod_2420_data.o
obj-$(CONFIG_ARCH_OMAP2430)+= omap_hwmod_2430_data.o
obj-$(CONFIG_ARCH_OMAP3) += omap_hwmod_3xxx_data.o
+obj-$(CONFIG_ARCH_OMAP4) += omap_hwmod_44xx_data.o
# EMU peripherals
obj-$(CONFIG_OMAP3_EMU)+= emu.o
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index b9ea70b..490d870 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -323,6 +323,9 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
omap2430_hwmod_init();
else if (cpu_is_omap34xx())
omap3xxx_hwmod_init();
+ else if (cpu_is_omap44xx())
+ omap44xx_hwmod_init();
+
/* The OPP tables have to be registered before a clk init */
omap_pm_if_early_init(mpu_opps, dsp_opps, l3_opps);
@@ -342,9 +345,7 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
#ifndef CONFIG_PM_RUNTIME
skip_setup_idle = 1;
#endif
- if (cpu_is_omap24xx() || cpu_is_omap34xx()) /* FIXME: OMAP4 */
- omap_hwmod_late_init(skip_setup_idle);
-
+ omap_hwmod_late_init(skip_setup_idle);
if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
_omap2_init_reprogram_sdrc();
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
new file mode 100644
index 000..e20b0ee
--- /dev/null
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -0,0 +1,482 @@
+/*
+ * Hardware modules present on the OMAP44xx chips
+ *
+ * Copyright (C) 2009-2010 Texas Instruments, Inc.
+ * Copyright (C) 2009-2010 Nokia Corporation
+ *
+ * Paul Walmsley
+ * Benoit Cousson
+ *
+ * This file is automatically generated from the OMAP hardware databases.
+ * We respectfully ask that any modifications to this file be coordinated
+ * with the public linux-omap@vger.kernel.org mailing list and the
+ * authors above to ensure that the autogeneration scripts are kept
+ * up-to-date with the file contents.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+
+#include
+#include
+
+#include "omap_hwmod_common_data.h"
+
+#include "cm.h"
+#include "prm-regbits-44xx.h"
+
+/* Base offset for all OMAP4 interrupts external to MPUSS */
+#define OMAP44XX_IRQ_GIC_START 32
+
+/* Base offset for all OMAP4 dma requests */
+#define OMAP44XX_DMA_REQ_START 1
+
+/* Backward references (IPs with Bus Master capability) */
+static struct omap_hwmod omap44xx_dmm_hwmod;
+static struct omap_hwmod omap44xx_emif_fw_hwmod;
+static struct omap_hwmod omap44xx_l3_instr_hwmod;
+static struct omap_hwmod omap44xx_l3_main_1_hwmod;
+static struct omap_hwmod omap44xx_l3_main_2_hwmod;
+static struct omap_hwmod omap44xx_l3_main_3_hwmod;
+static struct omap_hwmod omap44xx_l4_abe_hwmod;
+static struct omap_hwmod omap44xx_l4_cfg_hwmod;
+static struct omap_hwmod omap44xx_l4_per_hwmod;
+static struct omap_hwmod omap44xx_l4_wkup_hwmod;
+static struct omap_hwmod omap44xx_mpu_hwmod;
+static struct omap_hwmod omap44xx_mpu_private_hwmod;
+
+/*
+ * Interconnects omap_hwmod structur
[PATCH v3 0/7] OMAP: hwmod: Full data set for OMAP4430 ES1 & ES2
Hi Kevin & Paul, Here is the OMAP4430 ES1 & ES2 hwmod data v3 series. Please note that there is no difference between the ES1 & ES2 wrt hwmod. This series is re-organised in order to allow initial submission for upstream with minimal interconnect data set + mpu. Further data will be sent along with the driver once adapted to hwmod. A first patch is done for the TIMER IP as an example. Patches are based on lo/for-next + for-next-fixes + pm-wip/hwmods-reset + pm-wip/hwmods-debugfs and are available here: git://dev.omapzoom.org/pub/scm/swarch/linux-omap-adv.git pm-wip/hwmods-omap4 Tested on OMAP4430 ES1.0 GP device using PAB board. Thanks, Benoit v1 http://marc.info/?l=linux-omap&m=127324843814741&w=2 v2 http://www.spinics.net/lists/linux-omap/msg29622.html - [PATCH 3/6] OMAP4: hwmod: Enable omap_device build for OMAP4 Removed some old defines for OMAP_32KSYNCT_BASE that has nothing to do in that file and was already removed by Tony. v3 - Re-organize the data for initial submission - Fix and align clock name with the hwmod - Add hardreset support - Add DSS sub-modules - Add mpu_bus for internal access from mpu to mpu subsystem - Fix interconnect wrong class name Benoit Cousson (7): OMAP4: hwmod: Add initial data for OMAP4430 ES1 & ES2 OMAP4: clock: Fix clock names and align with hwmod names OMAP4: pm: Change l3_main to l3_main_1 during bus device init OMAP4: hwmod: Add TIMER data for OMAP4430 ES1 & ES2 OMAP4: hwmod: Add remaining hwmods data for OMAP4430 ES1 & ES2 OMAP: hwmod: Temporary prevent reset during _setup for GPIOs OMAP: hwmod: Temporary prevent reset during _setup for I2Cs arch/arm/mach-omap2/Makefile |1 + arch/arm/mach-omap2/clock44xx_data.c | 715 ++-- arch/arm/mach-omap2/io.c |7 +- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 5801 ++ arch/arm/mach-omap2/pm.c |5 +- arch/arm/plat-omap/Makefile |2 +- arch/arm/plat-omap/include/plat/omap_hwmod.h |1 + 7 files changed, 6147 insertions(+), 385 deletions(-) create mode 100644 arch/arm/mach-omap2/omap_hwmod_44xx_data.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] platform: Facilitate the creation of pseduo-platform busses
Magnus Damm writes:
> On Thu, Aug 5, 2010 at 7:14 AM, Patrick Pannuto
> wrote:
>> Inspiration for this comes from:
>> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31161.html
>>
>> RFC: http://lkml.org/lkml/2010/8/3/496
>> Patch is unchanged from the RFC. Reviews seemed generally positive
>> and it seemed this was desired functionality.
>
> Thanks for your patch, it's really nice to see work done in this area!
> I'd like to see something like this merged in the not so distant
> future. At this point I'm not so concerned about the details, so I'll
> restrict myself to this:
>
>> /drivers/my_driver.c
>> static struct platform_driver my_driver = {
>> .driver = {
>> .name = "my-driver",
>> .owner = THIS_MODULE,
>> .bus = &my_bus_type,
>> },
>> };
>
> I would really prefer not to have the bus type in the here. I
> understand it's needed at this point, but I wonder if it's possible to
> adjust the device<->driver matching for platform devices to allow any
> type of pseudo-platform bus_type.
I totally agree here. Keeping the drivers ignorant of the bus (or SoC)
they are on will make them much more portable.
Kevin
--
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/6] TI816X: Update common omap platform files
Kevin Hilman wrote: > Hemant Pedanekar writes: > >> This patch updates the common platform files with TI816X specific >> additions. >> >> Also adds new files for TI816X modules base addresseses and irq >> definitions. >> [...] >> +bne 9998f >> + >> +/* >> + * ti816x has additional IRQ pending register. Checking this >> + * register on omap2 & omap3 has no effect (read as 0). + >> */ >> +ldr \irqnr, [\base, #0xf8] /* IRQ pending reg 4 */ >> +cmp \irqnr, #0x0 > > This part makes me a slightly nervous. At least according to > the TRMs, > this address is undefined on OMAP2 & OMAP3 (yet still in the > INTC block.) > Was this tested on OMAP2/3 hardware and verified to return 0? > I tested this on OMAP3 but haven't verified on OMAP2. I will try to check this on all the variants. > You might also consider wrapping this section in > #ifdef CONFIG_ARCH_TI816X so a multi-OMAP kernel without 816x support would > avoid this extra read. > Yes, that is better. Will add. >> 9998: >> ldrne \irqnr, [\base, #INTCPS_SIR_IRQ_OFFSET] >> and \irqnr, \irqnr, #ACTIVEIRQ_MASK /* Clear spurious bits >> */ >> @@ -139,6 +148,35 @@ omap_irq_base: .word 0 >> .endm >> #endif >> >> +/* >> + * Optimized irq functions for ti816x >> + */ >> + >> +#ifdef CONFiG_ARCH_TI816X > ^ > typo? these are case-sensitive, so this part would never be compiled > Yes, I will fix this. [...] > > Kevin Thanks - Hemant -- 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] omap3: Remove non-existent config option
Hiroshi, > -Original Message- > From: linux-omap-ow...@vger.kernel.org > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Hiroshi DOYU > Sent: Wednesday, August 04, 2010 6:20 AM > To: t...@atomide.com > Cc: Marathe, Yogesh; linux-omap@vger.kernel.org; Premi, Sanjeev > Subject: Re: [PATCH] omap3: Remove non-existent config option > > From: ext Tony Lindgren > Subject: Re: [PATCH] omap3: Remove non-existent config option > Date: Wed, 4 Aug 2010 13:11:47 +0200 > > > * Marathe, Yogesh [100803 11:03]: > >> ping.. > > > > Hiroshi ack/nak? > > Nak. > > http://www.spinics.net/lists/linux-omap/msg32869.html > > "tidspbridge" is in staging now. Can you please elaborate what this means ? Yogesh patch enables the IOMMU for BRIDGE by default and we need this as IOMMU is going to get use in 3430. > -- > 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 > -- 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 4/6] TI816X: Create board support for TI816X_EVM
Hemant Pedanekar writes:
> This patch adds minimal support for TI816X EVM to enable kernel boot.
>
> Signed-off-by: Hemant Pedanekar
[...]
> diff --git a/arch/arm/mach-omap2/board-ti8168evm.c
> b/arch/arm/mach-omap2/board-ti8168evm.c
> new file mode 100644
> index 000..2271624
> --- /dev/null
> +++ b/arch/arm/mach-omap2/board-ti8168evm.c
> @@ -0,0 +1,71 @@
> +/*
> + * Code for TI8168 EVM.
> + *
> + * Copyright (C) 2010 Texas Instruments, Inc. - http://www.ti.com/
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Looks like most of these headers are not needed for this minimal
support. It's preferred to have a minimal set of headers here and add
them later as needed when the devices are added.
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static void __init ti8168_evm_init_irq(void)
> +{
> + omap2_gp_clockevent_set_gptimer(2);
Just curious why GPT2 is used here.
> + omap2_init_common_hw(NULL, NULL);
> + omap_init_irq();
> +}
Kevin
--
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/6] TI816X: Update common omap platform files
Hemant Pedanekar writes: > This patch updates the common platform files with TI816X specific additions. > > Also adds new files for TI816X modules base addresseses and irq definitions. > > Signed-off-by: Hemant Pedanekar > --- > arch/arm/mach-omap2/include/mach/entry-macro.S | 44 - > arch/arm/plat-omap/common.c| 20 > arch/arm/plat-omap/include/plat/clkdev_omap.h |1 + > arch/arm/plat-omap/include/plat/clock.h|1 + > arch/arm/plat-omap/include/plat/common.h |1 + > arch/arm/plat-omap/include/plat/control.h | 23 > arch/arm/plat-omap/include/plat/hardware.h |1 + > arch/arm/plat-omap/include/plat/io.h | 20 > arch/arm/plat-omap/include/plat/irqs-ti816x.h | 128 > > arch/arm/plat-omap/include/plat/irqs.h |3 + > arch/arm/plat-omap/include/plat/serial.h |5 + > arch/arm/plat-omap/include/plat/ti816x.h | 40 > arch/arm/plat-omap/io.c|7 ++ > 13 files changed, 291 insertions(+), 3 deletions(-) > create mode 100644 arch/arm/plat-omap/include/plat/irqs-ti816x.h > create mode 100644 arch/arm/plat-omap/include/plat/ti816x.h > > diff --git a/arch/arm/mach-omap2/include/mach/entry-macro.S > b/arch/arm/mach-omap2/include/mach/entry-macro.S > index 50fd749..6516cbd 100644 > --- a/arch/arm/mach-omap2/include/mach/entry-macro.S > +++ b/arch/arm/mach-omap2/include/mach/entry-macro.S > @@ -34,7 +34,7 @@ > .endm > > /* > - * Unoptimized irq functions for multi-omap2, 3 and 4 > + * Unoptimized irq functions for multi-omap2, 3, 4 and ti816x > */ > > #ifdef MULTI_OMAP2 > @@ -57,7 +57,8 @@ omap_irq_base: .word 0 > mrc p15, 0, \tmp, c0, c0, 0 @ get processor revision > and \tmp, \tmp, #0x00f0 @ check cortex 8 or 9 > cmp \tmp, #0x0080 @ cortex A-8? > - beq 3400f @ found A-8 so it's omap34xx > + beq 3400f @ found A-8 so it's omap34xx or > + @ ti816x > cmp \tmp, #0x0090 @ cortex A-9? > beq 4400f @ found A-9 so it's omap44xx > 2400:ldr \base, =OMAP2_IRQ_BASE > @@ -80,7 +81,7 @@ omap_irq_base: .word 0 > tst \base, #0x100 @ gic address? > bne 4401f @ found gic > > - /* Handle omap2 and omap3 */ > + /* Handle omap2, omap3 and ti816x */ > ldr \irqnr, [\base, #0x98] /* IRQ pending reg 1 */ > cmp \irqnr, #0x0 > bne 9998f > @@ -89,6 +90,14 @@ omap_irq_base: .word 0 > bne 9998f > ldr \irqnr, [\base, #0xd8] /* IRQ pending reg 3 */ > cmp \irqnr, #0x0 > + bne 9998f > + > + /* > + * ti816x has additional IRQ pending register. Checking this > + * register on omap2 & omap3 has no effect (read as 0). > + */ > + ldr \irqnr, [\base, #0xf8] /* IRQ pending reg 4 */ > + cmp \irqnr, #0x0 This part makes me a slightly nervous. At least according to the TRMs, this address is undefined on OMAP2 & OMAP3 (yet still in the INTC block.) Was this tested on OMAP2/3 hardware and verified to return 0? You might also consider wrapping this section in #ifdef CONFIG_ARCH_TI816X so a multi-OMAP kernel without 816x support would avoid this extra read. > 9998: > ldrne \irqnr, [\base, #INTCPS_SIR_IRQ_OFFSET] > and \irqnr, \irqnr, #ACTIVEIRQ_MASK /* Clear spurious bits > */ > @@ -139,6 +148,35 @@ omap_irq_base: .word 0 > .endm > #endif > > +/* > + * Optimized irq functions for ti816x > + */ > + > +#ifdef CONFiG_ARCH_TI816X ^ typo? these are case-sensitive, so this part would never be compiled > + .macro get_irqnr_preamble, base, tmp > + ldr \base, =OMAP3_IRQ_BASE > + .endm > + > + /* Check the pending interrupts. Note that base already set */ > + .macro get_irqnr_and_base, irqnr, irqstat, base, tmp > + ldr \irqnr, [\base, #0x98] /* IRQ pending reg 1 */ > + cmp \irqnr, #0x0 > + bne f > + ldr \irqnr, [\base, #0xb8] /* IRQ pending reg 2 */ > + cmp \irqnr, #0x0 > + bne f > + ldr \irqnr, [\base, #0xd8] /* IRQ pending reg 3 */ > + cmp \irqnr, #0x0 > + bne f > + ldr \irqnr, [\base, #0xf8] /* IRQ pending reg 4 */ > + cmp \irqnr, #0x0 > +: > + ldrne \irqnr, [\base, #INTCPS_SIR_IRQ_OFFSET] > + and \irqnr, \irqnr, #ACTIVEIRQ_MASK >
Re: [PATCH 2/6] TI816X: Update common omap platform files
Hemant Pedanekar writes: > This patch updates the common platform files with TI816X specific additions. > > Also adds new files for TI816X modules base addresseses and irq definitions. > > Signed-off-by: Hemant Pedanekar General question on the static mapping of the L4_SLOW area. It would help if you comment on why this region should be statically mapped. The mapping is not used in this series, so it's hard to judge here whether it could be mapped dynamically. Kevin -- 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: PM branch updated to v2.6.35, SRF dropped
> -Original Message- > From: linux-omap-ow...@vger.kernel.org > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman > Sent: Thursday, August 05, 2010 4:21 AM > To: linux-omap@vger.kernel.org > Subject: PM branch updated to v2.6.35, SRF dropped > > Hello, > Hi Kevin, Can you pull in this patch into your branch as well? http://marc.info/?l=linux-usb&m=127858711304301&w=2 Without this multi-omap build seems to be broken. Also with omap_4430sdp_defconfig, I see these compile errors arch/arm/kernel/entry-armv.S: Assembler messages: arch/arm/kernel/entry-armv.S:48: Error: bad instruction `test_for_ipi r0,r6,r5,lr' arch/arm/kernel/entry-armv.S:48: Error: bad instruction `test_for_ipi r0,r6,r5,lr' make[1]: *** [arch/arm/kernel/entry-armv.o] Error 1 make: *** [arch/arm/kernel] Error 2 Doing a git log on entry-armv.S shows me a top commit which might be an issue if conflicts are'nt resolved well. commit 7b70c4275f28702b76b273c8534c38f8313812e9 Merge: ceb0885... a20df56... Author: Russell King Date: Sat Jul 31 14:20:16 2010 +0100 Merge branch 'devel-stable' into devel Conflicts: arch/arm/kernel/entry-armv.S arch/arm/kernel/setup.c arch/arm/mm/init.c Maybe this is an issue in Tony's for-next as well. Haven't tested it though. regards, Rajendra > It's been a while since a PM branch update, thanks to a nice summer > vacation for me. :) > > The PM branch has now been updated to v2.6.35 plus Tony's for-next > branch. > > This is mostly a rebase, but the most important change is that I'm > finally dropping SRF as promised[1]. The new DVFS > infrastructure is now > in the RFC/PATCH phase so I'm no longer going to keep dragging SRF > along. Note that this means that ***DVFS no longer works in > the PM branch***. > If this bothers you, then please consider helping review and test the > new DVFS infrastructure recently posted by Thara so we can > get the new, > upstream-ready DVFS code upstream ASAP. > > I've only tested the new PM branch on a couple boards to avoid any > further delay getting this version out, update, so hopefully > others will > help test. > > I've tested RET on idle & suspend, OFF in idle & suspend on: > > 3430/omap3evm: works > > 3630/Zoom3: works > - Known problem: console hangs on UART wakeup when wakeups > are enabled using > echo enabled > > /sys/devices/platform/serial8250.0/tty/ttyS0/power/wakeup > but I haven't debugged this further. > > Kevin > > > [1] http://marc.info/?l=linux-omap&m=127206504624556&w=2 > -- > 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 > -- 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/6] TI816X: Update common OMAP machine specific sources
Kevin Hilman wrote:
> Hemant Pedanekar writes:
>
>> This patch updates the common machine spcific source files with support
>> for TI816X.
>>
>> Note that the nr_irqs is overridden in INTC driver since the number of
>> IRQs on TI816X are different (128) comapared to other OMAPs (96).
>>
>> Signed-off-by: Hemant Pedanekar
>
> One minor issue below...
>
> [...]
>
>> @@ -899,10 +899,10 @@ void omap2_clkdm_allow_idle(struct clockdomain
>> *clkdm)
>>
>> /*
>> * XXX This should be removed once TI adds wakeup/sleep
>> - * dependency code and data for OMAP4.
>> + * dependency code and data for OMAP4, TI816X
>> */
>> -if (cpu_is_omap44xx()) {
>> -WARN_ONCE(1, "clockdomain: OMAP4 wakeup/sleep dependency "
>> +if (cpu_is_omap44xx() || cpu_is_ti816x()) {
>> +WARN_ONCE(1, "clockdomain: wakeup/sleep dependency "
>>"support is not yet implemented\n");
>> } else {
>> if (atomic_read(&clkdm->usecount) > 0)
>> @@ -941,9 +941,9 @@ void omap2_clkdm_deny_idle(struct clockdomain *clkdm)
>>
>> /*
>> * XXX This should be removed once TI adds wakeup/sleep
>> - * dependency code and data for OMAP4.
>> + * dependency code and data for OMAP4, TI816X.
>> */
>> -if (cpu_is_omap44xx()) {
>> +if (cpu_is_omap44xx() || cpu_is_ti816x()) {
>> WARN_ONCE(1, "clockdomain: OMAP4 wakeup/sleep dependency "
>
> Did you want to remove the 'OMAP4' here as you did in the hunk above?
>
> Kevin
Yes, I will fix that in v2.
Thanks
-
Hemant
--
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/6] TI816X: Update common OMAP machine specific sources
Hemant Pedanekar writes:
> This patch updates the common machine spcific source files with support for
> TI816X.
>
> Note that the nr_irqs is overridden in INTC driver since the number of IRQs on
> TI816X are different (128) comapared to other OMAPs (96).
>
> Signed-off-by: Hemant Pedanekar
One minor issue below...
[...]
> @@ -899,10 +899,10 @@ void omap2_clkdm_allow_idle(struct clockdomain *clkdm)
>
> /*
>* XXX This should be removed once TI adds wakeup/sleep
> - * dependency code and data for OMAP4.
> + * dependency code and data for OMAP4, TI816X
>*/
> - if (cpu_is_omap44xx()) {
> - WARN_ONCE(1, "clockdomain: OMAP4 wakeup/sleep dependency "
> + if (cpu_is_omap44xx() || cpu_is_ti816x()) {
> + WARN_ONCE(1, "clockdomain: wakeup/sleep dependency "
> "support is not yet implemented\n");
> } else {
> if (atomic_read(&clkdm->usecount) > 0)
> @@ -941,9 +941,9 @@ void omap2_clkdm_deny_idle(struct clockdomain *clkdm)
>
> /*
>* XXX This should be removed once TI adds wakeup/sleep
> - * dependency code and data for OMAP4.
> + * dependency code and data for OMAP4, TI816X.
>*/
> - if (cpu_is_omap44xx()) {
> + if (cpu_is_omap44xx() || cpu_is_ti816x()) {
> WARN_ONCE(1, "clockdomain: OMAP4 wakeup/sleep dependency "
Did you want to remove the 'OMAP4' here as you did in the hunk above?
Kevin
--
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] omap3: id: fix 3630 rev detection
Wrong placement of break causes all revisions of 3630 to be detected as 3630 es1.2, we need to break main loop if we have an identified chip, default falls through as in the rest of the switches in this function. Cc: Paul Walmsley Cc: Sanjeev Premi Cc: Kevin Hilman Cc: Manjunath K Cc: Anand Gadiyar Cc: Felipe Balbi Cc: linux-omap@vger.kernel.org Signed-off-by: Nishanth Menon --- arch/arm/mach-omap2/id.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c index e8256a2..9a879f9 100644 --- a/arch/arm/mach-omap2/id.c +++ b/arch/arm/mach-omap2/id.c @@ -284,8 +284,8 @@ static void __init omap3_check_revision(void) default: omap_revision = OMAP3630_REV_ES1_2; omap_chip.oc |= CHIP_IS_OMAP3630ES1_2; - break; } + break; default: /* Unknown default to latest silicon rev as default*/ omap_revision = OMAP3630_REV_ES1_2; -- 1.6.3.3 -- 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/3] OMAP3630: Add ES1.1 and ES1.2 detection
* Nishanth Menon [100804 21:55]: > Tony Lindgren had written, on 08/04/2010 06:33 AM, the following: > >From: Anand Gadiyar > >+default: > >+omap_revision = OMAP3630_REV_ES1_2; > >+omap_chip.oc |= CHIP_IS_OMAP3630ES1_2; > >+break; > >+} > > we need to add a break here. to jump out of the main switch statement. > currently with ES1.0 3630, it reports as 3630 ES1.2 Argh.. It's merged already, care to do another patch to fix this? > Tested and verified on SDP3630 with OMAP3630 ES1.0 OK, 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
[PATCH] omap: Update omap3evm board support
- Fix regulator definitions to provide supplies required
by frame buffer (OMAP DSS2) and touch panel drivers,
- fix LCD and touch panel power handling (as disabling the LCD power
disabled touch panel as well which meant no more input events...),
- fix power module LED definition,
- update omap3_defconfig, enabling required drivers
Signed-off-by: Pawel Moll
---
arch/arm/configs/omap3_defconfig |5 +++
arch/arm/mach-omap2/board-omap3evm.c | 51 +
2 files changed, 43 insertions(+), 13 deletions(-)
diff --git a/arch/arm/configs/omap3_defconfig b/arch/arm/configs/omap3_defconfig
index 5db9a6b..fd5980a 100644
--- a/arch/arm/configs/omap3_defconfig
+++ b/arch/arm/configs/omap3_defconfig
@@ -182,6 +182,7 @@ CONFIG_MENELAUS=y
CONFIG_TWL4030_CORE=y
CONFIG_TWL4030_POWER=y
CONFIG_REGULATOR=y
+CONFIG_REGULATOR_FIXED_VOLTAGE=y
CONFIG_REGULATOR_TWL4030=y
CONFIG_REGULATOR_TPS65023=y
CONFIG_REGULATOR_TPS6507X=y
@@ -190,6 +191,10 @@ CONFIG_FIRMWARE_EDID=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
CONFIG_FB_OMAP_LCD_VGA=y
+CONFIG_OMAP2_DSS=y
+CONFIG_FB_OMAP2=y
+CONFIG_PANEL_GENERIC=y
+CONFIG_PANEL_SHARP_LS037V7DW01=y
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=y
CONFIG_LCD_PLATFORM=y
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 6494dbd..d180be7 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -31,6 +31,7 @@
#include
#include
+#include
#include
#include
@@ -157,8 +158,8 @@ static inline void __init omap3evm_init_smsc911x(void) {
return; }
#define OMAP3EVM_LCD_PANEL_ENVDD 153
#define OMAP3EVM_LCD_PANEL_QVGA154
#define OMAP3EVM_LCD_PANEL_RESB155
-#define OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO210
#define OMAP3EVM_DVI_PANEL_EN_GPIO 199
+#define OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO210
static int lcd_enabled;
static int dvi_enabled;
@@ -243,7 +244,11 @@ static int omap3_evm_enable_lcd(struct omap_dss_device
*dssdev)
static void omap3_evm_disable_lcd(struct omap_dss_device *dssdev)
{
+ /* We don't really want to cut off the panel power, as the touch panel
+* is powered from the same source... */
+#if 0
gpio_set_value(OMAP3EVM_LCD_PANEL_ENVDD, 1);
+#endif
if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2)
gpio_set_value(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 1);
@@ -381,7 +386,7 @@ static struct gpio_led gpio_leds[] = {
{
.name = "omap3evm::ledb",
/* normally not visible (board underside) */
- .default_trigger= "default-on",
+ .default_trigger= "heartbeat",
.gpio = -EINVAL, /* gets replaced */
.active_low = true,
},
@@ -419,15 +424,15 @@ static int omap3evm_twl_gpio_setup(struct device *dev,
*/
/* TWL4030_GPIO_MAX + 0 == ledA, LCD Backlight control */
- gpio_request(gpio + TWL4030_GPIO_MAX, "EN_LCD_BKL");
- gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
+ gpio_request(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, "EN_LCD_BKL");
+ gpio_direction_output(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 0);
/* gpio + 7 == DVI Enable */
gpio_request(gpio + 7, "EN_DVI");
gpio_direction_output(gpio + 7, 0);
/* TWL4030_GPIO_MAX + 1 == ledB (out, active low LED) */
- gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
+ gpio_leds[0].gpio = gpio + TWL4030_GPIO_MAX + 1;
platform_device_register(&leds_gpio);
@@ -493,10 +498,8 @@ static struct twl4030_codec_data omap3evm_codec_data = {
.audio = &omap3evm_audio_data,
};
-static struct regulator_consumer_supply omap3_evm_vdda_dac_supply = {
- .supply = "vdda_dac",
- .dev= &omap3_evm_dss_device.dev,
-};
+static struct regulator_consumer_supply omap3_evm_vdda_dac_supply =
+ REGULATOR_SUPPLY("vdda_dac", "omapdss");
/* VDAC for DSS driving S-Video */
static struct regulator_init_data omap3_evm_vdac = {
@@ -514,10 +517,8 @@ static struct regulator_init_data omap3_evm_vdac = {
};
/* VPLL2 for digital video outputs */
-static struct regulator_consumer_supply omap3_evm_vpll2_supply = {
- .supply = "vdvi",
- .dev= &omap3_evm_lcd_device.dev,
-};
+static struct regulator_consumer_supply omap3_evm_vpll2_supply =
+ REGULATOR_SUPPLY("vdds_dsi", "omapdss");
static struct regulator_init_data omap3_evm_vpll2 = {
.constraints = {
@@ -573,6 +574,29 @@ static int __init omap3_evm_i2c_init(void)
return 0;
}
+static struct regulator_consumer_supply ads7846_consumer_supply =
+ REGULATOR_SUPPLY("vcc", "spi1.0");
+
+struct regulator_init_data ads7846_vcc_initdata = {
+ .consumer_supplies = &ads7846_consumer_supply,
+ .num_consumer_supplies = 1,
+};
+
+stat
RE: DSS2 patch series
On Thu, 2010-08-05 at 09:06 +0200, ext Taneja, Archit wrote: > Hi, > > > > > Also, we should think how to reduce if (cpu_is_omap44xx()) > > lines. There should be some kind of DSS capability list > > somewhere, which would tell the features available. I haven't > > thought this more, but it'd be very nice if we could use the > > DSS HW version number to decide what features there are. > > > > However, TI answered that information about DSS HW version > > numbers is not available, and thus cannot be used =(. Perhaps > > you could try to dig out some information from inside TI? > > > > I read the DSS_REVISON, DISPC_REVISION etc registers on 3430, 3630, 4430: > > 3430: DSS rev 2.0, DISPC rev 3.0, RFBI rev 1.0, DSI rev 1.0, VENC rev 2 > 3630: DSS rev 2.0, DISPC rev 3.0, RFBI rev 1.0, DSI rev 1.0, VENC rev 2 > 4430: DSS rev 4.0, DISPC rev 4.0, DSI rev 3.0, RFBI rev 3.5 > > I haven't tried on OMAP2 yet.. > > Don't you think these revision numbers are enough to differentiate the > features of each IP block? Perhaps. The problem is, I don't know what the version numbers mean, ie. when are they changed, what are the changes. I would hope you that you could find some internal info inside TI that would explain the differences =). We can of course reverse engineer the version numbers, and hope that we decipher them correctly. For OMAP3430/3630/4430 the differences look clear. But how about OMAP rev changes? For example, at some 3430 revision the bitfield lengths of video timing registers were changed. Does it show on DSS/DISPC version numbers? I don't think I have boards with those revs, so I can't check. Tomi -- 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] omap: hsmmc: Do not mux the slot if non default muxing is already done
From 33ff72fc0b690c6b89407668d0f4ab9543eec47c Mon Sep 17 00:00:00 2001
From: Jarkko Lavinen
Date: Mon, 26 Apr 2010 16:30:07 +0300
Subject: [PATCH] omap: hsmmc: Do not mux the slot if non default muxing is
already done
Add 'nomux' flag for hsmmc and skip mux'ing is it is set.
Signed-off-by: Jarkko Lavinen
Signed-off-by: Adrian Hunter
---
arch/arm/mach-omap2/devices.c |3 +++
arch/arm/mach-omap2/hsmmc.c |1 +
arch/arm/mach-omap2/hsmmc.h |1 +
3 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 2dbb265..c6329eb 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -608,6 +608,9 @@ static inline void omap_hsmmc_reset(void) {}
static inline void omap2_mmc_mux(struct omap_mmc_platform_data *mmc_controller,
int controller_nr)
{
+ if (mmc_controller->slots[0].nomux)
+ return;
+
if ((mmc_controller->slots[0].switch_pin > 0) && \
(mmc_controller->slots[0].switch_pin < OMAP_MAX_GPIO_LINES))
omap_mux_init_gpio(mmc_controller->slots[0].switch_pin,
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 1ef54b0..e1ec467 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -267,6 +267,7 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
*controllers)
mmc->slots[0].switch_pin = c->gpio_cd;
mmc->slots[0].gpio_wp = c->gpio_wp;
+ mmc->slots[0].nomux = c->nomux;
mmc->slots[0].remux = c->remux;
if (c->cover_only)
diff --git a/arch/arm/mach-omap2/hsmmc.h b/arch/arm/mach-omap2/hsmmc.h
index 36f0ba8..56d65cc 100644
--- a/arch/arm/mach-omap2/hsmmc.h
+++ b/arch/arm/mach-omap2/hsmmc.h
@@ -16,6 +16,7 @@ struct omap2_hsmmc_info {
boolpower_saving; /* Try to sleep or power off when possible */
boolno_off; /* power_saving and power is not to go off */
boolvcc_aux_disable_is_sleep; /* Regulator off remapped to sleep */
+ boolnomux; /* No default muxing for this slot */
int gpio_cd;/* or -EINVAL */
int gpio_wp;/* or -EINVAL */
char*name; /* or NULL for default */
--
1.6.3.3
--
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: DSS2 patch series
Hi, > > Also, we should think how to reduce if (cpu_is_omap44xx()) > lines. There should be some kind of DSS capability list > somewhere, which would tell the features available. I haven't > thought this more, but it'd be very nice if we could use the > DSS HW version number to decide what features there are. > > However, TI answered that information about DSS HW version > numbers is not available, and thus cannot be used =(. Perhaps > you could try to dig out some information from inside TI? > I read the DSS_REVISON, DISPC_REVISION etc registers on 3430, 3630, 4430: 3430: DSS rev 2.0, DISPC rev 3.0, RFBI rev 1.0, DSI rev 1.0, VENC rev 2 3630: DSS rev 2.0, DISPC rev 3.0, RFBI rev 1.0, DSI rev 1.0, VENC rev 2 4430: DSS rev 4.0, DISPC rev 4.0, DSI rev 3.0, RFBI rev 3.5 I haven't tried on OMAP2 yet.. Don't you think these revision numbers are enough to differentiate the features of each IP block? For example, if there are changes in the bit field lengths of video pipeline Registers from omap2 to 3, we can use the dispc revision number to decide to include the feature instead of having a cpu_is_omap24xx() change? Same for global alpha, new color modes and so on. Similarly, if a new video pipeline is introduced in OMAP4, we can use the DISPC revision number to decide the number of pipelines. We could use DSS Revision numbers to introduce changes like new interrupt lines, clocks and addition or removal of IP blocks. Do you mean something else by DSS HW version numbers? Would it be different/more precise compared to the read from the DSS_REVISON register? Thanks, Archit -- 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
