[no subject]
This is version three of the patch set. Unless something serious comes up I would drop the RFC on the next post. So far I should have everything covered up comparing to the omap-serial driver except for the throttle callbacks. And now I would slowly start looking into DMA support… Sebastian -- 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
[no subject]
-- 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
[no subject]
When an OMAP GPIO is used as an IRQ line, a call to gpio_request()
has to be made to initialize the OMAP GPIO bank before a driver
request the IRQ. Otherwise the call to request_irq() fails.
Drivers should not be aware of this neither care wether an IRQ line
is a GPIO or not. They should just request the IRQ and this has to
be handled by the irq_chip driver.
With the current OMAP GPIO DT binding, if we define:
gpio6: gpio@49058000 {
compatible = ti,omap3-gpio;
reg = 0x49058000 0x200;
interrupts = 34;
ti,hwmods = gpio6;
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
#interrupt-cells = 2;
};
interrupt-parent = gpio6;
interrupts = 16 8;
The GPIO is correctly mapped as an IRQ but a call to gpio_request()
is never made. Ideally this has to be handled by the IRQ core and
there are some work-in-progress to add this logic to the core but
until this general solution gets into mainline we need to solve this
on a per irq_chip driver basis.
Some drivers solve this by calling gpio_request() using a custom
.xlate function handler. But .xlate could get called many times
while the irq domain .map function handler is called just once
when a IRQ mapping is created with a call to irq_create_mapping().
This patch-set adds a custom .map function handler for the gpio-omap
irq_chip driver that automatically call gpio_request() when a IRQ
mapping is created for the GPIO line used as interrupt. This is
just a temporary solution (a.k.a a hack) until a kernel wide approach
is implemented and added to mainline.
The patch-set is composed of the following patches:
[PATCH v2 1/2] gpio/omap: don't create an IRQ mapping for every GPIO on DT
[PATCH v2 2/2] gpio/omap: auto request GPIO as input if used as IRQ via DT
This was tested on an OMAP3 DM3735 board (IGEPv2) and all the supported
peripherals are working correctly with both legacy and DT booting. Further
testing will be highly appreciated.
Many thanks to Jon Hunter and Grant Likely for their feedback and
suggestions on how to solve this.
Best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
Loan Syndicacion Am AFG Guaranty Trust Bank, zu strukturieren wir Kreditlinien treffen Sie unsere Kunden spezifischen geschäftlichen Anforderungen und einen deutlichen Mehrwert für unsere Kunden Unternehmen. eine Division der AFG Finance und Private Bank plc. Wenn Sie erwägen, eine große Akquisition oder ein Großprojekt sind, können Sie brauchen eine erhebliche Menge an Kredit. AFG Guaranty Trust Bank setzen können zusammen das Syndikat, das die gesamte Kredit schnürt für Sie. Als Bank mit internationaler Reichweite, sind wir gekommen, um Darlehen zu identifizieren Syndizierungen als Teil unseres Kerngeschäfts und durch spitzte diese Zeile aggressiv sind wir an einem Punkt, wo wir kommen, um als erkannt haben Hauptakteur in diesem Bereich. öffnen Sie ein Girokonto heute mit einem Minimum Bankguthaben von 500 £ und Getup zu £ 10.000 als Darlehen und auch den Hauch einer Chance und gewann die Sterne Preis von £ 500.000 in die sparen und gewinnen promo in may.aply jetzt. mit dem Folowing Informationen über Rechtsanwalt steven lee das Konto Offizier. FULL NAME; Wohnadresse; E-MAIL-ADRESSE; Telefonnummer; Nächsten KINS; MUTTER MAIDEN NAME; Familienstand; BÜROADRESSE; ALTERNATIVE Telefonnummer; TO @ yahoo.com bar.stevenlee NOTE; ALLE Darlehen sind für 10JAHRE RATE VALID ANGEBOT ENDET BALD SO JETZT HURRY -- 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
[no subject]
binZdJucJYmRx.bin Description: iso-8859-1
[no subject]
binz8t4k_0ZSO.bin Description: iso-8859-1
[no subject]
Hi,
It is good idea add this feature.
1: Can we let the ret = hwspin_lock_tests(ops, hwlock); add after
hwspin_lock_register_single have return
succeed, that can avoid test duplicated Or error lockid. Of course, If
this interface is intend to test soc hardware capability only, we can
put it in the arch module not this core framework. For driver hardware
sanity check, i would add it after software have register it.
2:Is it possible that interface add configs that choose which locks
will be test? Because the hwspinlock module is init late in
postcore_initcall phase, Maybe MACH/ARCH code(for example: code in
early_initcall) need use private other interfaces to lock some
hwspinlocks and then register hw locks to hwspinlock framework, Maybe
some hw locks is in lock status but which test failed.
--
Steve Zhan
From: Ido Yariv i...@wizery.com
To: Ohad Ben-Cohen o...@wizery.com, linux-ker...@vger.kernel.org,
linux-arm-ker...@lists.infradead.org, linux-omap@vger.kernel.org
Cc: Ido Yariv i...@wizery.com
Subject: [PATCH] hwspinlock/core: Add testing capabilities
Message-ID: 1355344026-17222-1-git-send-email-...@wizery.com
Add testing capabilities for verifying correctness of the underlying
hwspinlock layers. This can be handy especially during development.
These tests are performed only once as part of the hwspinlock
registration.
Signed-off-by: Ido Yariv i...@wizery.com
---
drivers/hwspinlock/Kconfig |9 +
drivers/hwspinlock/hwspinlock_core.c | 54
++
2 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig
index c7c3128..ad632cd 100644
--- a/drivers/hwspinlock/Kconfig
+++ b/drivers/hwspinlock/Kconfig
@@ -8,6 +8,15 @@ config HWSPINLOCK
menu Hardware Spinlock drivers
+config HWSPINLOCK_TEST
+ bool Verify underlying hwspinlock implementation
+ depends on HWSPINLOCK
+ help
+ Say Y here to perform tests on the underlying hwspinlock
+ implementation. The tests are only performed once per implementation.
+
+ Say N, unless you absolutely know what you are doing.
+
config HWSPINLOCK_OMAP
tristate OMAP Hardware Spinlock device
depends on ARCH_OMAP4
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index 085e28e..1874e85 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -307,6 +307,53 @@ out:
return hwlock;
}
+#ifdef CONFIG_HWSPINLOCK_TEST
+#define NUM_OF_TEST_ITERATIONS 100
+static int hwspin_lock_tests(const struct hwspinlock_ops *ops,
+ struct hwspinlock *hwlock)
+{
+ int i;
+ int ret;
+
+ for (i = 0; i NUM_OF_TEST_ITERATIONS; i++) {
+ ret = ops-trylock(hwlock);
+ if (!ret) {
+ pr_err(%s: Initial lock failed\n, __func__);
+ return -EFAULT;
+ }
+
+ /* Verify lock actually works - re-acquiring it should fail */
+ ret = ops-trylock(hwlock);
+ if (ret) {
+ /* Keep locks balanced even in failure cases */
+ ops-unlock(hwlock);
+ ops-unlock(hwlock);
+ pr_err(%s: Recursive lock succeeded unexpectedly\n,
+__func__);
+ return -EFAULT;
+ }
+
+ /* Verify unlock by re-acquiring the lock after releasing it */
+ ops-unlock(hwlock);
+ ret = ops-trylock(hwlock);
+ if (!ret) {
+ pr_err(%s: Unlock failed\n, __func__);
+ return -EINVAL;
+ }
+
+ ops-unlock(hwlock);
+ }
+
+ return 0;
+}
+#else /* CONFIG_HWSPINLOCK_TEST*/
+static int hwspin_lock_tests(const struct hwspinlock_ops *ops,
+ struct hwspinlock *hwlock)
+{
+ return 0;
+}
+#endif
+
/**
* hwspin_lock_register() - register a new hw spinlock device
* @bank: the hwspinlock device, which usually provides numerous hw locks
@@ -345,6 +392,13 @@ int hwspin_lock_register(struct hwspinlock_device
*bank, struct device *dev,
spin_lock_init(hwlock-lock);
hwlock-bank = bank;
+ ret = hwspin_lock_tests(ops, hwlock);
+ if (ret) {
+ pr_err(hwspinlock tests failed on lock %d\n,
+base_id + i);
+ goto reg_failed;
+ }
+
ret = hwspin_lock_register_single(hwlock, base_id + i);
if (ret)
goto reg_failed;
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: gpmc generic retime function (subject was RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration)
Hi Jon, On Fri, Aug 17, 2012 at 20:32:34, Hunter, Jon wrote: And we have been able to create such a function. Below is an implementation that has been made for handling asynchronous timings. It has been tested for OneNAND SMSC on OMAP3EVM (rev G C) with [1-4]. OneNAND was tested using [5] (OMAP3EVM OneNAND works in async mode) SMSC using [6] (mainline does not have a timing calculation for smsc911x) Are you able to verify that the timing calculated by this function are identical? May be some more details on exactly how you tested this would be good. Yes, it was verified. A new driver preparation series has been posted, http://marc.info/?l=linux-omapm=134554573104116w=2 that includes generic timing calculation method. The new series mentions how timing values were validated. There are a couple of timing parameters that would vary as mentioned in the above mentioned mail, but these I don't expect to create problems as this is more inline with gpmc peripheral timings. And both of the these has been verified that it would not create problem with peripheral functionality. One was tested directly (we_on related for OneNAND) and other indirectly (adv_rd(wr)_off on SMSC 9220 for SMSC 91C96). Reason for doing so was that quirks required to handle these specific cases could be avoided, otherwise new peripheral timing data would be required and it would be difficult to achieve DT bindings (when DT happens) for these kind of fixup timings. But if this causes any problems (which I don't expect), then we will have to fallback to the quirks that I wanted to avoid. Do you think that there is any value in making the tusb member a u32 dev_type and then set it too GPMC_DEVICE_TUSB then this could be used for other devices in the future too if needed? Would it be possible to create a sub-function called gpmc_calc_timings_tusb() and put all these if (tusb) statements in there? Or maybe a generic function called gpmc_calc_timings_prepare(). Usage of a tusb check was something that I really wanted to avoid as that was making generic timing calculation function peripheral Gnostic. With the newly posted series, tusb field has been removed. Regards Afzal -- 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: gpmc generic retime function (subject was RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration)
Hi Afzal,
Sorry for the delay, I have been out of the office.
On 08/06/2012 08:38 AM, Mohammed, Afzal wrote:
Hi Tony, Jon,
On Wed, Jul 11, 2012 at 12:17:25, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [120710 10:20]:
The DT node should simply have the information required by the retime
function or gpmc timings themselves if available. In the case of OneNAND
These can be stored in the DT and then translated to gpmc timings at
runtime. DT should only store static timing or clock information known
Yup. And the format of the timing data in DT should be standardized so
the only differences for each connected peripheral is the retime function.
If we are able to achieve a generic retime function applicable to all
peripherals then we don't need wrapper layer for retime handling or two
linux devices and drivers (one the existing and the other to handle retime)
to represent a single physical gpmc peripheral device (for DT conversion).
Then handling core frequency scaling and DT conversion would be easier.
We were trying to create such a retime function that would be generic so
as to handle different types of gpmc peripherals.
Sounds like a much better approach!
And we have been able to create such a function. Below is an implementation
that has been made for handling asynchronous timings. It has been tested for
OneNAND SMSC on OMAP3EVM (rev G C) with [1-4]. OneNAND was tested using
[5] (OMAP3EVM OneNAND works in async mode) SMSC using [6] (mainline does
not have a timing calculation for smsc911x)
Are you able to verify that the timing calculated by this function are
identical? May be some more details on exactly how you tested this would
be good.
It was difficult to squeeze tusb6010 timing calculation into generic timing
calculation, hence a boolean tusb has been used. This is what I could
achieve based on existing retime for tusb6010 and for lack of tusb6010
timing specifications.
8---
/* Device timings in picoseconds */
struct gpmc_device_timings {
u32 cs_setup; /* CS setup time */
u32 adv_setup; /* ADV setup time */
u32 adv_rd_off; /* ADV read off time */
u32 adv_add_hold; /* address hold time */
u32 oe_setup; /* OE setup time */
u32 adv_access; /* access time from ADV assertion */
u32 rd_access; /* read access time */
u32 oe_access; /* access time from OE assertion */
u32 cs_access; /* access time from CS asertion */
u32 rd_cycle; /* read cycle time */
u32 cs_highz; /* CS deassertion to high Z */
u32 oe_highz; /* OE deassertion to high Z */
u32 adv_wr_off; /* ADV write off time */
u32 we_setup; /* WE setup time */
u32 wr_pulse; /* write assertion time */
u32 wr_data_setup; /* data setup time from write assertion */
u32 wr_high;/* write deassertion time */
u32 we_highz; /* WE deassertion to high Z */
u32 wr_cycle; /* write cycle time */
boolmux;/* address data muxed */
booltusb; /* peripheral is tusb6010 */
Do you think that there is any value in making the tusb member a u32
dev_type and then set it too GPMC_DEVICE_TUSB then this could be used
for other devices in the future too if needed?
};
struct gpmc_timings gpmc_calc_timings(struct gpmc_device_timings *dev_t)
{
struct gpmc_timings gpmc_t;
bool mux = dev_t-mux;
bool tusb = dev_t-tusb;
u32 temp;
memset(gpmc_t, 0, sizeof(gpmc_t));
/* cs_on */
gpmc_t.cs_on = gpmc_round_ns_to_ticks(dev_t-cs_setup / 1000);
/* adv_on */
temp = dev_t-adv_setup;
if (tusb)
temp = max_t(u32,
(gpmc_t.cs_on + gpmc_ticks_to_ns(1)) * 1000, temp);
gpmc_t.adv_on = gpmc_round_ns_to_ticks(temp / 1000);
Would it be possible to create a sub-function called
gpmc_calc_timings_tusb() and put all these if (tusb) statements in
there? Or maybe a generic function called gpmc_calc_timings_prepare().
For the above case could have ...
void gpmc_calc_timings_prepare(struct gpmc_device_timings *dev_t)
{
if (dev_t-tusb) {
dev_t-adv_on = max_t(u32,
(gpmc_t.cs_on + gpmc_ticks_to_ns(1)) * 1000,
dev_t-adv_setup);
...
} else {
dev_t-adv_on = dev_t-adv_setup;
...
}
}
And then in the gpmc_calc_timings() you would just have ...
gpmc_t.adv_on = gpmc_round_ns_to_ticks(dev_t-adv_on / 1000);
/* adv_rd_off */
temp = dev_t-adv_rd_off;
if (tusb)
temp = max_t(u32,
gpmc generic retime function (subject was RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration)
Hi Tony, Jon,
On Wed, Jul 11, 2012 at 12:17:25, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [120710 10:20]:
The DT node should simply have the information required by the retime
function or gpmc timings themselves if available. In the case of OneNAND
These can be stored in the DT and then translated to gpmc timings at
runtime. DT should only store static timing or clock information known
Yup. And the format of the timing data in DT should be standardized so
the only differences for each connected peripheral is the retime function.
If we are able to achieve a generic retime function applicable to all
peripherals then we don't need wrapper layer for retime handling or two
linux devices and drivers (one the existing and the other to handle retime)
to represent a single physical gpmc peripheral device (for DT conversion).
Then handling core frequency scaling and DT conversion would be easier.
We were trying to create such a retime function that would be generic so
as to handle different types of gpmc peripherals.
And we have been able to create such a function. Below is an implementation
that has been made for handling asynchronous timings. It has been tested for
OneNAND SMSC on OMAP3EVM (rev G C) with [1-4]. OneNAND was tested using
[5] (OMAP3EVM OneNAND works in async mode) SMSC using [6] (mainline does
not have a timing calculation for smsc911x)
It was difficult to squeeze tusb6010 timing calculation into generic timing
calculation, hence a boolean tusb has been used. This is what I could
achieve based on existing retime for tusb6010 and for lack of tusb6010
timing specifications.
8---
/* Device timings in picoseconds */
struct gpmc_device_timings {
u32 cs_setup; /* CS setup time */
u32 adv_setup; /* ADV setup time */
u32 adv_rd_off; /* ADV read off time */
u32 adv_add_hold; /* address hold time */
u32 oe_setup; /* OE setup time */
u32 adv_access; /* access time from ADV assertion */
u32 rd_access; /* read access time */
u32 oe_access; /* access time from OE assertion */
u32 cs_access; /* access time from CS asertion */
u32 rd_cycle; /* read cycle time */
u32 cs_highz; /* CS deassertion to high Z */
u32 oe_highz; /* OE deassertion to high Z */
u32 adv_wr_off; /* ADV write off time */
u32 we_setup; /* WE setup time */
u32 wr_pulse; /* write assertion time */
u32 wr_data_setup; /* data setup time from write assertion */
u32 wr_high;/* write deassertion time */
u32 we_highz; /* WE deassertion to high Z */
u32 wr_cycle; /* write cycle time */
boolmux;/* address data muxed */
booltusb; /* peripheral is tusb6010 */
};
struct gpmc_timings gpmc_calc_timings(struct gpmc_device_timings *dev_t)
{
struct gpmc_timings gpmc_t;
bool mux = dev_t-mux;
bool tusb = dev_t-tusb;
u32 temp;
memset(gpmc_t, 0, sizeof(gpmc_t));
/* cs_on */
gpmc_t.cs_on = gpmc_round_ns_to_ticks(dev_t-cs_setup / 1000);
/* adv_on */
temp = dev_t-adv_setup;
if (tusb)
temp = max_t(u32,
(gpmc_t.cs_on + gpmc_ticks_to_ns(1)) * 1000, temp);
gpmc_t.adv_on = gpmc_round_ns_to_ticks(temp / 1000);
/* adv_rd_off */
temp = dev_t-adv_rd_off;
if (tusb)
temp = max_t(u32,
(gpmc_t.adv_on + gpmc_ticks_to_ns(1)) * 1000, temp);
gpmc_t.adv_rd_off = gpmc_round_ns_to_ticks(temp / 1000);
/* oe_on */
if (mux)
temp = gpmc_t.adv_rd_off * 1000 + dev_t-adv_add_hold;
else
temp = dev_t-oe_setup;
if (tusb)
temp = max_t(u32,
(gpmc_t.adv_rd_off + gpmc_ticks_to_ns(1)) * 1000, temp);
gpmc_t.oe_on = gpmc_round_ns_to_ticks(temp / 1000);
/* access */
temp = max_t(u32, dev_t-rd_access,
gpmc_t.oe_on * 1000 + dev_t-oe_access);
temp = max_t(u32, temp,
gpmc_t.cs_on * 1000 + dev_t-cs_access);
temp = max_t(u32, temp,
gpmc_t.adv_on * 1000 + dev_t-adv_access);
if (tusb) {
temp = max_t(u32, temp,
(gpmc_t.oe_on + gpmc_ticks_to_ns(1)) * 1000);
temp = max_t(u32, temp, gpmc_t.oe_on * 1000 + 300);
}
gpmc_t.access = gpmc_round_ns_to_ticks(temp / 1000);
gpmc_t.oe_off = gpmc_t.access + gpmc_ticks_to_ns(1);
gpmc_t.cs_rd_off = gpmc_t.oe_off;
/* rd_cycle */
temp = max_t(u32,
[no subject]
From 8b0f9153d078b7182efd604ef8525d50899ce1a3 Mon Sep 17 00:00:00 2001
From: Ricardo Neri ricardo.n...@ti.com
Date: Mon, 30 Jul 2012 17:54:59 -0500
Subject: [PATCH v3] OMAPDSS: DISPC: Improvements to DIGIT sync signal selection
DSS code wrongly assumes that VENC is always available as source for the
external
sync signal for the display controller DIGIT channel. One cannot blindly
write/read
the value of DSS_CONTROL[15] as in certain processors (e.g., OMAP5) this
operation
may not be valid. If the the sync source is not read correctly, the callers of
dss_get_hdmi_venc_clk_source might make wrong assumptions about, for instance,
video timings.
Logic is added to correctly get the sync signal based on the available displays
in the DIGIT channel. The source is set only if both VENC and HDMI are
supported.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
v3: instead of BUG_ON calls, select only if both VENC and HDMI are available.
v2: use BUG_ON() to simplify handling of invalid cases.
drivers/video/omap2/dss/dss.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 04b4586..29e677e 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -648,9 +648,14 @@ void dss_set_dac_pwrdn_bgz(bool enable)
REG_FLD_MOD(DSS_CONTROL, enable, 5, 5); /* DAC Power-Down Control */
}
-void dss_select_hdmi_venc_clk_source(enum dss_hdmi_venc_clk_source_select hdmi)
+void dss_select_hdmi_venc_clk_source(enum dss_hdmi_venc_clk_source_select src)
{
- REG_FLD_MOD(DSS_CONTROL, hdmi, 15, 15); /* VENC_HDMI_SWITCH */
+ enum omap_display_type dp;
+ dp = dss_feat_get_supported_displays(OMAP_DSS_CHANNEL_DIGIT);
+
+ /* Select only if we have options */
+ if ((dp OMAP_DISPLAY_TYPE_VENC) (dp OMAP_DISPLAY_TYPE_HDMI))
+ REG_FLD_MOD(DSS_CONTROL, src, 15, 15);
}
enum dss_hdmi_venc_clk_source_select dss_get_hdmi_venc_clk_source(void)
@@ -661,6 +666,9 @@ enum dss_hdmi_venc_clk_source_select
dss_get_hdmi_venc_clk_source(void)
if ((displays OMAP_DISPLAY_TYPE_HDMI) == 0)
return DSS_VENC_TV_CLK;
+ if ((displays OMAP_DISPLAY_TYPE_VENC) == 0)
+ return DSS_HDMI_M_PCLK;
+
return REG_GET(DSS_CONTROL, 15, 15);
}
--
1.7.5.4
--
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
[no subject]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony The following changes since commit 485802a6c524e62b5924849dd727ddbb1497cc71: Linux 3.5-rc3 (2012-06-16 17:25:17 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-cleanup-a-for-3.6 for you to fetch changes up to 07b3a13957aa250ff5b5409b8ed756b113544112: Merge branches 'clock_cleanup_misc_3.6', 'control_clean_dspbridge_writes_cleanup_3.6', 'hwmod_soc_conditional_cleanup_3.6', 'mcbsp_clock_aliases_cleanup_3.6' and 'remove_clkdm_requirement_from_hwmod_3.6' into omap_cleanup_a_3.6 (2012-06-20 20:11:36 -0600) - Some OMAP hwmod, clock, and System Control Module cleanup patches for 3.6. - Testing logs are available at http://www.pwsan.com/omap/bootlogs/20120620/omap_cleanup_a_3.6__07b3a13957aa250ff5b5409b8ed756b113544112/ The summary is that 5912OSK NFS root and N800 MMC don't boot to userspace; this broke between v3.4-rc2 and v3.5-rc3. 3517 boards are still broken with NFS root and also several stack tracebacks during boot. In terms of PM, core isn't entering idle on OMAP3 or OMAP4. These problems all exist in v3.5-rc3 - they aren't caused by this series. object size (delta in bytes from v3.5-rc3 (485802a6c524e62b5924849dd727ddbb1497cc71)): textdata bss total kernel 0 0 0 0 5912osk_testconfig/vmlinux +4636-400 0 +4236 am33xx_testconfig/vmlinux +440-408 +32 +64 n800_multi_omap2xxx/vmlinux +416-192 +32+256 n800_testconfig/vmlinux 0 0 0 0 omap1510_defconfig/vmlinux 0 0 0 0 omap1_defconfig/vmlinux +732-456 0+276 omap2_4_testconfig/vmlinux +4776-624 0 +4152 omap2plus_defconfig/vmlinux +684-664 0 +20 omap2plus_no_pm/vmlinux +616-336 +64+344 omap3_4_testconfig/vmlinux +360-384 0 -24 omap3_testconfig/vmlinux +580-120 +64+524 omap4_testconfig/vmlinux Kevin Hilman (7): ARM: OMAP4: hwmod: rename _enable_module to _omap4_enable_module() ARM: OMAP2+: hwmod: use init-time function ptrs for enable/disable module ARM: OMAP4: hwmod: drop extra cpu_is check from _wait_target_disable() ARM: OMAP2+: hwmod: use init-time function pointer for wait_target_ready ARM: OMAP2+: hwmod: use init-time function pointer for hardreset ARM: OMAP2+: hwmod: use init-time function pointer for _init_clkdm ARM: OMAP2+: CLEANUP: Remove ARCH_OMAPx ifdef from struct dpll_data Omar Ramirez Luna (2): ARM: OMAP2+: control: new APIs to configure boot address and mode ARM: OMAP: dsp: interface to control module functions Paul Walmsley (2): ARM: OMAP2+: hwmod: remove prm_clkdm, cm_clkdm; allow hwmods to have no clockdomain Merge branches 'clock_cleanup_misc_3.6', 'control_clean_dspbridge_writes_cleanup_3.6', 'hwmod_soc_conditional_cleanup_3.6', 'mcbsp_clock_aliases_cleanup_3.6' and 'remove_clkdm_requirement_from_hwmod_3.6' into omap_cleanup_a_3.6 Peter Ujfalusi (3): ARM: OMAP2: Move McBSP fck clock alias to hwmod data for OMAP2420 ARM: OMAP2: Move McBSP fck clock alias to hwmod data for OMAP2430 ARM: OMAP3: Move McBSP fck clock alias to hwmod data arch/arm/mach-omap2/Makefile |1 - arch/arm/mach-omap2/clock2420_data.c |4 - arch/arm/mach-omap2/clock2430_data.c | 10 - arch/arm/mach-omap2/clock3xxx_data.c | 10 - arch/arm/mach-omap2/clockdomain.h |2 - arch/arm/mach-omap2/clockdomains2420_data.c|2 - arch/arm/mach-omap2/clockdomains2430_data.c|2 - arch/arm/mach-omap2/clockdomains3xxx_data.c|2 - arch/arm/mach-omap2/clockdomains44xx_data.c|2 - arch/arm/mach-omap2/clockdomains_common_data.c | 24 -- arch/arm/mach-omap2/control.c | 43 ++ arch/arm/mach-omap2/control.h |2 + arch/arm/mach-omap2/dsp.c |4 + .../include/mach/ctrl_module_core_44xx.h |1 + arch/arm/mach-omap2/omap_hwmod.c | 427 ++-- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 10 + arch/arm/mach-omap2/omap_hwmod_2430_data.c | 16 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 23 ++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c |4 +- arch/arm/plat-omap/include/plat/clock.h|2 - arch/arm/plat-omap/include/plat/dsp.h |3 + arch/arm/plat-omap/include/plat/omap_hwmod.h |2 + 22 files changed, 409 insertions(+), 187 deletions(-) delete mode 100644 arch/arm/mach-omap2/clockdomains_common_data.c -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12
[no subject]
Following 2 hwmod strcuture are added:
UHH hwmod of usbhs with uhh base address and
EHCI , OHCI irq and base addresses.
TLL hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 184
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 153 +++
2 files changed, 337 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 909a84d..fe9a176 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -84,6 +84,8 @@ static struct omap_hwmod omap3xxx_mcbsp4_hwmod;
static struct omap_hwmod omap3xxx_mcbsp5_hwmod;
static struct omap_hwmod omap3xxx_mcbsp2_sidetone_hwmod;
static struct omap_hwmod omap3xxx_mcbsp3_sidetone_hwmod;
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap34xx_usb_tll_hs_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -3574,6 +3576,185 @@ static struct omap_hwmod omap3xxx_mmc3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap34xx_usb_host_hs__l3_main_2 = {
+ .master = omap34xx_usb_host_hs_hwmod,
+ .slave = omap3xxx_l3_main_hwmod,
+ .clk= core_l3_ick,
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_class_sysconfig omap34xx_usb_host_hs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap34xx_usb_host_hs_hwmod_class = {
+ .name = usbhs_uhh,
+ .sysc = omap34xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_masters[] = {
+ omap34xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_irq_info omap34xx_usb_host_hs_irqs[] = {
+ { .name = ohci-irq, .irq = 76 },
+ { .name = ehci-irq, .irq = 77 },
+};
+
+static struct omap_hwmod_addr_space omap34xx_usb_host_hs_addrs[] = {
+ {
+ .name = uhh,
+ .pa_start = 0x48064000,
+ .pa_end = 0x480643ff,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ .name = ohci,
+ .pa_start = 0x48064400,
+ .pa_end = 0x480647FF,
+ .flags = ADDR_MAP_ON_INIT
+ },
+ {
+ .name = ehci,
+ .pa_start = 0x48064800,
+ .pa_end = 0x48064CFF,
+ .flags = ADDR_MAP_ON_INIT
+ }
+};
+
+static struct omap_hwmod_ocp_if omap34xx_l4_cfg__usb_host_hs = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap34xx_usb_host_hs_hwmod,
+ .clk= l4_ick,
+ .addr = omap34xx_usb_host_hs_addrs,
+ .addr_cnt = ARRAY_SIZE(omap34xx_usb_host_hs_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if omap34xx_f128m_cfg__usb_host_hs = {
+ .clk= usbhost_120m_fck,
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
+};
+
+static struct omap_hwmod_ocp_if omap34xx_f48m_cfg__usb_host_hs = {
+ .clk= usbhost_48m_fck,
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_slaves[] = {
+ omap34xx_l4_cfg__usb_host_hs,
+ omap34xx_f128m_cfg__usb_host_hs,
+ omap34xx_f48m_cfg__usb_host_hs,
+};
+
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod = {
+ .name = usbhs_uhh,
+ .class = omap34xx_usb_host_hs_hwmod_class,
+ .mpu_irqs = omap34xx_usb_host_hs_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap34xx_usb_host_hs_irqs),
+ .main_clk = usbhost_ick,
+ .prcm = {
+ .omap2 = {
+ .module_offs = OMAP3430ES2_USBHOST_MOD,
+ .prcm_reg_id = 1,
+ .module_bit = 0,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = 1,
+ .idlest_stdby_bit = 0,
+ },
+ },
+ .slaves = omap34xx_usb_host_hs_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap34xx_usb_host_hs_slaves),
+ .masters= omap34xx_usb_host_hs_masters,
+ .masters_cnt=
[no subject]
Subscribe -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] *** SUBJECT HERE ***
On Tue, Mar 8, 2011 at 10:04 PM, David Cohen daco...@gmail.com wrote: *** BLURB HERE *** Sorry for this garbage :/ Br, David David Cohen (2): omap3: change ISP's IOMMU da_start address omap: iovmm: don't check 'da' to set IOVMF_DA_FIXED flag Michael Jones (1): omap: iovmm: disallow mapping NULL address arch/arm/mach-omap2/omap-iommu.c | 2 +- arch/arm/plat-omap/include/plat/iovmm.h | 2 -- arch/arm/plat-omap/iovmm.c | 30 +++--- 3 files changed, 16 insertions(+), 18 deletions(-) -- 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: Re: Ping- Subject: [PATCH] omap: omap3evm: add support for the WL12xx WLAN module to the omap3evm
* Eyal Reizer eyalrei...@googlemail.com [110227 02:43]: This patch is again current omap-for-linus branch Adds platform initialization for working with the WLAN module attached to the omap3evm. The patch includes MMC2 initialization, SDIO and control pins muxing and platform device registration. Thanks applying. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: Ping- Subject: [PATCH] omap: omap3evm: add support for the WL12xx WLAN module to the omap3evm
This patch is again current omap-for-linus branch
Adds platform initialization for working with the WLAN module
attached to the omap3evm.
The patch includes MMC2 initialization, SDIO and control pins
muxing and platform device registration.
Signed-off-by: Eyal Reizer ey...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c | 32 ++--
1 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 5364147..7341f96 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -411,7 +411,7 @@ static struct omap2_hsmmc_info mmc[] = {
#ifdef CONFIG_WL12XX_PLATFORM_DATA
{
.name = wl1271,
- .mmc= 2,
+ .mmc= 2,
.caps = MMC_CAP_4_BIT_DATA | MMC_CAP_POWER_OFF_CARD,
.gpio_wp= -EINVAL,
.gpio_cd= -EINVAL,
@@ -603,10 +603,8 @@ static struct regulator_init_data omap3evm_vio = {
#define OMAP3EVM_WLAN_PMENA_GPIO (150)
#define OMAP3EVM_WLAN_IRQ_GPIO (149)
-static struct regulator_consumer_supply omap3evm_vmmc2_supply = {
- .supply = vmmc,
- .dev_name = mmci-omap-hs.1,
-};
+static struct regulator_consumer_supply omap3evm_vmmc2_supply =
+ REGULATOR_SUPPLY(vmmc, mmci-omap-hs.1);
/* VMMC2 for driving the WL12xx module */
static struct regulator_init_data omap3evm_vmmc2 = {
@@ -627,7 +625,7 @@ static struct fixed_voltage_config omap3evm_vwlan = {
.init_data = omap3evm_vmmc2,
};
-static struct platform_device omap3evm_vwlan_device = {
+static struct platform_device omap3evm_wlan_regulator = {
.name = reg-fixed-voltage,
.id = 1,
.dev = {
@@ -637,8 +635,7 @@ static struct platform_device omap3evm_vwlan_device = {
struct wl12xx_platform_data omap3evm_wlan_data __initdata = {
.irq = OMAP_GPIO_IRQ(OMAP3EVM_WLAN_IRQ_GPIO),
- /* ref clock is 38.4 MHz */
- .board_ref_clock = 2,
+ .board_ref_clock = WL12XX_REFCLOCK_38, /* 38.4 MHz */
};
#endif
@@ -765,7 +762,7 @@ static struct omap_board_mux omap35x_board_mux[] __initdata
= {
OMAP_PIN_OFF_NONE),
#ifdef CONFIG_WL12XX_PLATFORM_DATA
/* WLAN IRQ - GPIO 149 */
- OMAP3_MUX(UART1_RTS, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(UART1_RTS, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
/* WLAN POWER ENABLE - GPIO 150 */
OMAP3_MUX(UART1_CTS, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
@@ -801,6 +798,21 @@ static struct omap_board_mux omap36x_board_mux[]
__initdata = {
OMAP3_MUX(SYS_BOOT4, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
OMAP3_MUX(SYS_BOOT5, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
OMAP3_MUX(SYS_BOOT6, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
+#ifdef CONFIG_WL12XX_PLATFORM_DATA
+ /* WLAN IRQ - GPIO 149 */
+ OMAP3_MUX(UART1_RTS, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
+
+ /* WLAN POWER ENABLE - GPIO 150 */
+ OMAP3_MUX(UART1_CTS, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+
+ /* MMC2 SDIO pin muxes for WL12xx */
+ OMAP3_MUX(SDMMC2_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(SDMMC2_CMD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(SDMMC2_DAT0, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(SDMMC2_DAT1, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(SDMMC2_DAT2, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(SDMMC2_DAT3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+#endif
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
@@ -871,7 +883,7 @@ static void __init omap3_evm_init(void)
/* WL12xx WLAN Init */
if (wl12xx_set_platform_data(omap3evm_wlan_data))
pr_err(error setting wl12xx data\n);
- platform_device_register(omap3evm_vwlan_device);
+ platform_device_register(omap3evm_wlan_regulator);
#endif
}
--
1.7.0.4
--
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
FW: Re: Ping- Subject: [PATCH] omap: omap3evm: add support for the WL12xx WLAN module to the omap3evm
As asked ,this patch is against current omap-for-linus branch
Adds platform initialization for working with the WLAN module
attached to the omap3evm.
The patch includes MMC2 initialization, SDIO and control pins
muxing and platform device registration.
Signed-off-by: Eyal Reizer ey...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c | 32 ++--
1 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 5364147..7341f96 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -411,7 +411,7 @@ static struct omap2_hsmmc_info mmc[] = {
#ifdef CONFIG_WL12XX_PLATFORM_DATA
{
.name = wl1271,
- .mmc= 2,
+ .mmc= 2,
.caps = MMC_CAP_4_BIT_DATA | MMC_CAP_POWER_OFF_CARD,
.gpio_wp= -EINVAL,
.gpio_cd= -EINVAL,
@@ -603,10 +603,8 @@ static struct regulator_init_data omap3evm_vio = {
#define OMAP3EVM_WLAN_PMENA_GPIO (150)
#define OMAP3EVM_WLAN_IRQ_GPIO (149)
-static struct regulator_consumer_supply omap3evm_vmmc2_supply = {
- .supply = vmmc,
- .dev_name = mmci-omap-hs.1,
-};
+static struct regulator_consumer_supply omap3evm_vmmc2_supply =
+ REGULATOR_SUPPLY(vmmc, mmci-omap-hs.1);
/* VMMC2 for driving the WL12xx module */
static struct regulator_init_data omap3evm_vmmc2 = {
@@ -627,7 +625,7 @@ static struct fixed_voltage_config omap3evm_vwlan = {
.init_data = omap3evm_vmmc2,
};
-static struct platform_device omap3evm_vwlan_device = {
+static struct platform_device omap3evm_wlan_regulator = {
.name = reg-fixed-voltage,
.id = 1,
.dev = {
@@ -637,8 +635,7 @@ static struct platform_device omap3evm_vwlan_device = {
struct wl12xx_platform_data omap3evm_wlan_data __initdata = {
.irq = OMAP_GPIO_IRQ(OMAP3EVM_WLAN_IRQ_GPIO),
- /* ref clock is 38.4 MHz */
- .board_ref_clock = 2,
+ .board_ref_clock = WL12XX_REFCLOCK_38, /* 38.4 MHz */
};
#endif
@@ -765,7 +762,7 @@ static struct omap_board_mux omap35x_board_mux[] __initdata
= {
OMAP_PIN_OFF_NONE),
#ifdef CONFIG_WL12XX_PLATFORM_DATA
/* WLAN IRQ - GPIO 149 */
- OMAP3_MUX(UART1_RTS, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(UART1_RTS, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
/* WLAN POWER ENABLE - GPIO 150 */
OMAP3_MUX(UART1_CTS, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
@@ -801,6 +798,21 @@ static struct omap_board_mux omap36x_board_mux[]
__initdata = {
OMAP3_MUX(SYS_BOOT4, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
OMAP3_MUX(SYS_BOOT5, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
OMAP3_MUX(SYS_BOOT6, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
+#ifdef CONFIG_WL12XX_PLATFORM_DATA
+ /* WLAN IRQ - GPIO 149 */
+ OMAP3_MUX(UART1_RTS, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
+
+ /* WLAN POWER ENABLE - GPIO 150 */
+ OMAP3_MUX(UART1_CTS, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+
+ /* MMC2 SDIO pin muxes for WL12xx */
+ OMAP3_MUX(SDMMC2_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(SDMMC2_CMD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(SDMMC2_DAT0, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(SDMMC2_DAT1, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(SDMMC2_DAT2, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(SDMMC2_DAT3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+#endif
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
@@ -871,7 +883,7 @@ static void __init omap3_evm_init(void)
/* WL12xx WLAN Init */
if (wl12xx_set_platform_data(omap3evm_wlan_data))
pr_err(error setting wl12xx data\n);
- platform_device_register(omap3evm_vwlan_device);
+ platform_device_register(omap3evm_wlan_regulator);
#endif
}
--
1.7.0.4
--
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: Re: Ping- Subject: [PATCH] omap: omap3evm: add support for the WL12xx WLAN module to the omap3evm
* Reizer, Eyal ey...@ti.com [110223 23:25]: Adds platform initialization for working with the WLAN module attached to the omap3evm. The patch includes MMC2 initialization, SDIO and control pins muxing and platform device registration. Sorry still can't get this one to apply. Can you please rebase this on top of the current omap-for-linus branch? Thanks, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: Ping- Subject: [PATCH] omap: omap3evm: add support for the WL12xx WLAN module to the omap3evm
Hi Eyal,
On Thu, Feb 24, 2011 at 1:47 PM, Tony Lindgren t...@atomide.com wrote:
Sorry still can't get this one to apply. Can you please rebase
this on top of the current omap-for-linus branch?
...
+#include linux/wl12xx.h
...
+struct wl12xx_platform_data omap3evm_wlan_data __initdata = {
+ .irq = OMAP_GPIO_IRQ(OMAP3EVM_WLAN_IRQ_GPIO),
+ .board_ref_clock = 2, /* ref clock is 38.4 MHz */
+};
If you're anyway resubmitting the patch, could you please use
WL12XX_REFCLOCK_38 (defined in linux/wl12xx.h) instead of the direct
value ? It will make it easier for others to understand where is this
value taken from, and how to port it to other boards.
Thanks,
Ohad.
--
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: Re: Ping- Subject: [PATCH] omap: omap3evm: add support for the WL12xx WLAN module to the omap3evm
Hi Tony,
Below is an updated patch that addresses comments received from
community members over the weekend.
Please use this patch instead of the previous one.
Please notice that on the devel-board branch there are now two mux
arrays, one for omap35x and one for omap36x.
Please merge the mux intialization part of the patch to both structures.
Many Thanks,
Eyal
...
...
Adds platform initialization for working with the WLAN module
attached to the omap3evm.
The patch includes MMC2 initialization, SDIO and control pins
muxing and platform device registration.
Signed-off-by: Eyal Reizer ey...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c | 74
++
1 files changed, 74 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 323c380..349aac9 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -30,6 +30,8 @@
#include linux/usb/otg.h
#include linux/smsc911x.h
+#include linux/wl12xx.h
+#include linux/regulator/fixed.h
#include linux/regulator/machine.h
#include linux/mmc/host.h
@@ -381,6 +383,16 @@ static struct omap2_hsmmc_info mmc[] = {
.gpio_cd= -EINVAL,
.gpio_wp= 63,
},
+#ifdef CONFIG_WL12XX_PLATFORM_DATA
+ {
+ .name = wl1271,
+ .mmc= 2,
+ .caps = MMC_CAP_4_BIT_DATA |
MMC_CAP_POWER_OFF_CARD,
+ .gpio_wp= -EINVAL,
+ .gpio_cd= -EINVAL,
+ .nonremovable = true,
+ },
+#endif
{} /* Terminator */
};
@@ -538,6 +550,47 @@ static struct regulator_init_data omap3_evm_vpll2 =
{
.consumer_supplies = omap3_evm_vpll2_supply,
};
+#ifdef CONFIG_WL12XX_PLATFORM_DATA
+
+#define OMAP3EVM_WLAN_PMENA_GPIO (150)
+#define OMAP3EVM_WLAN_IRQ_GPIO (149)
+
+static struct regulator_consumer_supply omap3evm_vmmc2_supply =
+ REGULATOR_SUPPLY(vmmc, mmci-omap-hs.1);
+
+/* VMMC2 for driving the WL12xx module */
+static struct regulator_init_data omap3evm_vmmc2 = {
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = omap3evm_vmmc2_supply,
+};
+
+static struct fixed_voltage_config omap3evm_vwlan = {
+ .supply_name= vwl1271,
+ .microvolts = 180, /* 1.80V */
+ .gpio = OMAP3EVM_WLAN_PMENA_GPIO,
+ .startup_delay = 7, /* 70ms */
+ .enable_high= 1,
+ .enabled_at_boot= 0,
+ .init_data = omap3evm_vmmc2,
+};
+
+static struct platform_device omap3evm_wlan_regulator = {
+ .name = reg-fixed-voltage,
+ .id = 1,
+ .dev = {
+ .platform_data = omap3evm_vwlan,
+ },
+};
+
+struct wl12xx_platform_data omap3evm_wlan_data __initdata = {
+ .irq = OMAP_GPIO_IRQ(OMAP3EVM_WLAN_IRQ_GPIO),
+ .board_ref_clock = 2, /* ref clock is 38.4 MHz */
+};
+#endif
+
static struct twl4030_platform_data omap3evm_twldata = {
.irq_base = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
@@ -658,6 +711,21 @@ static struct omap_board_mux board_mux[] __initdata
= {
OMAP_PIN_OFF_WAKEUPENABLE),
OMAP3_MUX(MCSPI1_CS1, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
OMAP_PIN_OFF_INPUT_PULLUP |
OMAP_PIN_OFF_OUTPUT_LOW),
+#ifdef CONFIG_WL12XX_PLATFORM_DATA
+ /* WLAN IRQ - GPIO 149 */
+ OMAP3_MUX(UART1_RTS, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
+
+ /* WLAN POWER ENABLE - GPIO 150 */
+ OMAP3_MUX(UART1_CTS, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+
+ /* MMC2 SDIO pin muxes for WL12xx */
+ OMAP3_MUX(SDMMC2_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(SDMMC2_CMD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(SDMMC2_DAT0, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(SDMMC2_DAT1, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(SDMMC2_DAT2, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(SDMMC2_DAT3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+#endif
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#endif
@@ -715,6 +783,12 @@ static void __init omap3_evm_init(void)
ads7846_dev_init();
omap3evm_init_smsc911x();
omap3_evm_display_init();
+
+#ifdef CONFIG_WL12XX_PLATFORM_DATA
+ /* WL12xx WLAN Init */
+ if (wl12xx_set_platform_data(omap3evm_wlan_data))
+ pr_err(error setting wl12xx data\n);
+ platform_device_register(omap3evm_wlan_regulator);
+#endif
}
MACHINE_START(OMAP3EVM, OMAP3 EVM)
--
1.7.0.4
On Thu, 2011-02-17 at 14:20 -0800, Tony Lindgren wrote:
* Reizer, Eyal ey...@ti.com [110215 07:11]:
Dear Tony,
I did not receive any comments to
Re: Re: Ping- Subject: [PATCH] omap: omap3evm: add support for the WL12xx WLAN module to the omap3evm
* Reizer, Eyal ey...@ti.com [110223 04:22]: Hi Tony, Below is an updated patch that addresses comments received from community members over the weekend. Please use this patch instead of the previous one. Please notice that on the devel-board branch there are now two mux arrays, one for omap35x and one for omap36x. Please merge the mux intialization part of the patch to both structures. Sorry looks like already merged your previous patch into omap-for-linus. Would apply this, but the patch is wrapped. Can you please resend? Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Re: Ping- Subject: [PATCH] omap: omap3evm: add support for the WL12xx WLAN module to the omap3evm
Adds platform initialization for working with the WLAN module
attached to the omap3evm.
The patch includes MMC2 initialization, SDIO and control pins
muxing and platform device registration.
Signed-off-by: Eyal Reizer ey...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c | 74 ++
1 files changed, 74 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 323c380..349aac9 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -30,6 +30,8 @@
#include linux/usb/otg.h
#include linux/smsc911x.h
+#include linux/wl12xx.h
+#include linux/regulator/fixed.h
#include linux/regulator/machine.h
#include linux/mmc/host.h
@@ -381,6 +383,16 @@ static struct omap2_hsmmc_info mmc[] = {
.gpio_cd= -EINVAL,
.gpio_wp= 63,
},
+#ifdef CONFIG_WL12XX_PLATFORM_DATA
+ {
+ .name = wl1271,
+ .mmc= 2,
+ .caps = MMC_CAP_4_BIT_DATA | MMC_CAP_POWER_OFF_CARD,
+ .gpio_wp= -EINVAL,
+ .gpio_cd= -EINVAL,
+ .nonremovable = true,
+ },
+#endif
{} /* Terminator */
};
@@ -538,6 +550,47 @@ static struct regulator_init_data omap3_evm_vpll2 = {
.consumer_supplies = omap3_evm_vpll2_supply,
};
+#ifdef CONFIG_WL12XX_PLATFORM_DATA
+
+#define OMAP3EVM_WLAN_PMENA_GPIO (150)
+#define OMAP3EVM_WLAN_IRQ_GPIO (149)
+
+static struct regulator_consumer_supply omap3evm_vmmc2_supply =
+ REGULATOR_SUPPLY(vmmc, mmci-omap-hs.1);
+
+/* VMMC2 for driving the WL12xx module */
+static struct regulator_init_data omap3evm_vmmc2 = {
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = omap3evm_vmmc2_supply,
+};
+
+static struct fixed_voltage_config omap3evm_vwlan = {
+ .supply_name= vwl1271,
+ .microvolts = 180, /* 1.80V */
+ .gpio = OMAP3EVM_WLAN_PMENA_GPIO,
+ .startup_delay = 7, /* 70ms */
+ .enable_high= 1,
+ .enabled_at_boot= 0,
+ .init_data = omap3evm_vmmc2,
+};
+
+static struct platform_device omap3evm_wlan_regulator = {
+ .name = reg-fixed-voltage,
+ .id = 1,
+ .dev = {
+ .platform_data = omap3evm_vwlan,
+ },
+};
+
+struct wl12xx_platform_data omap3evm_wlan_data __initdata = {
+ .irq = OMAP_GPIO_IRQ(OMAP3EVM_WLAN_IRQ_GPIO),
+ .board_ref_clock = 2, /* ref clock is 38.4 MHz */
+};
+#endif
+
static struct twl4030_platform_data omap3evm_twldata = {
.irq_base = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
@@ -658,6 +711,21 @@ static struct omap_board_mux board_mux[] __initdata = {
OMAP_PIN_OFF_WAKEUPENABLE),
OMAP3_MUX(MCSPI1_CS1, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
OMAP_PIN_OFF_INPUT_PULLUP |
OMAP_PIN_OFF_OUTPUT_LOW),
+#ifdef CONFIG_WL12XX_PLATFORM_DATA
+ /* WLAN IRQ - GPIO 149 */
+ OMAP3_MUX(UART1_RTS, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
+
+ /* WLAN POWER ENABLE - GPIO 150 */
+ OMAP3_MUX(UART1_CTS, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+
+ /* MMC2 SDIO pin muxes for WL12xx */
+ OMAP3_MUX(SDMMC2_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(SDMMC2_CMD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(SDMMC2_DAT0, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(SDMMC2_DAT1, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(SDMMC2_DAT2, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(SDMMC2_DAT3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+#endif
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#endif
@@ -715,6 +783,12 @@ static void __init omap3_evm_init(void)
ads7846_dev_init();
omap3evm_init_smsc911x();
omap3_evm_display_init();
+#ifdef CONFIG_WL12XX_PLATFORM_DATA
+ /* WL12xx WLAN Init */
+ if (wl12xx_set_platform_data(omap3evm_wlan_data))
+ pr_err(error setting wl12xx data\n);
+ platform_device_register(omap3evm_wlan_regulator);
+#endif
}
MACHINE_START(OMAP3EVM, OMAP3 EVM)
--
1.7.0.4
--
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: Re: Ping- Subject: [PATCH] omap: omap3evm: add support for the WL12xx WLAN module to the omap3evm
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Reizer, Eyal Sent: Sunday, February 20, 2011 4:20 PM To: t...@atomide.com Cc: linux-omap@vger.kernel.org Subject: Re: Re: Ping- Subject: [PATCH] omap: omap3evm: add support for the WL12xx WLAN module to the omap3evm On Thu, 2011-02-17 at 14:20 -0800, Tony Lindgren wrote: * Reizer, Eyal ey...@ti.com [110215 07:11]: Dear Tony, I did not receive any comments to the patch I have send in the following link: http://marc.info/?l=linux-omapm=129612179900695w=2 Are there any issues with excepting this patch? Pushing to devel-board branch for the upcoming merge window. Can you please check it's working? I had to merge some other evm board changes manually.. Tony Dear Tony, As you requested, I have tested the devel-board branch this morning and found one merge issue. I see that there are now two mux arrays, one for omap35x and one for omap36x. You have merged the muxes changes to the omap35x_board_mux[] array, but have missed the other structure called omap36x_board_mux[]. The same change should be merged there as well. The result is that it would work OK on an evm with an omap35x SOM but not on aboard with an omap37x SOM. Please find below a fix for that. Eyal, I am assuming that you will be sending an updated version of the patch fixing some of the issues pointed in this response: http://marc.info/?l=linux-omapm=129820402332111w=2 You can add the patch below to updated submission. ~sanjeev Best Regards, Eyal Reizer [snip]...[snip] -- 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: Re: Ping- Subject: [PATCH] omap: omap3evm: add support for the WL12xx WLAN module to the omap3evm
On Thu, 2011-02-17 at 14:20 -0800, Tony Lindgren wrote: * Reizer, Eyal ey...@ti.com [110215 07:11]: Dear Tony, I did not receive any comments to the patch I have send in the following link: http://marc.info/?l=linux-omapm=129612179900695w=2 Are there any issues with excepting this patch? Pushing to devel-board branch for the upcoming merge window. Can you please check it's working? I had to merge some other evm board changes manually.. Tony Dear Tony, As you requested, I have tested the devel-board branch this morning and found one merge issue. I see that there are now two mux arrays, one for omap35x and one for omap36x. You have merged the muxes changes to the omap35x_board_mux[] array, but have missed the other structure called omap36x_board_mux[]. The same change should be merged there as well. The result is that it would work OK on an evm with an omap35x SOM but not on aboard with an omap37x SOM. Please find below a fix for that. Best Regards, Eyal Reizer diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-om index d4a1157..b77140f 100644 --- a/arch/arm/mach-omap2/board-omap3evm.c +++ b/arch/arm/mach-omap2/board-omap3evm.c @@ -815,6 +815,21 @@ static struct omap_board_mux omap36x_board_mux[] __initdata OMAP3_MUX(SYS_BOOT4, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE), OMAP3_MUX(SYS_BOOT5, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE), OMAP3_MUX(SYS_BOOT6, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE), +#ifdef CONFIG_WL12XX_PLATFORM_DATA + /* WLAN IRQ - GPIO 149 */ + OMAP3_MUX(UART1_RTS, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP), + + /* WLAN POWER ENABLE - GPIO 150 */ + OMAP3_MUX(UART1_CTS, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT), + + /* MMC2 SDIO pin muxes for WL12xx */ + OMAP3_MUX(SDMMC2_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), + OMAP3_MUX(SDMMC2_CMD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), + OMAP3_MUX(SDMMC2_DAT0, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), + OMAP3_MUX(SDMMC2_DAT1, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), + OMAP3_MUX(SDMMC2_DAT2, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), + OMAP3_MUX(SDMMC2_DAT3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), +#endif attachment: winmail.dat
Re: Re: Ping- Subject: [PATCH] omap: omap3evm: add support for the WL12xx WLAN module to the omap3evm
Hi Ohad, On Sun, 2011-02-20 at 13:32 +0200, Ohad Ben-Cohen wrote: Hi Eyal, (posting from a mobile device, so formatting maybe funky) On Feb 20, 2011, at 12:50 PM, Reizer, Eyal ey...@ti.com wrote: ... +#ifdef CONFIG_WL12XX_PLATFORM_DATA [?][?]CONFIG_WL12XX_PLATFORM_DATAhere is a bit problematic. But we can change that once those other modules show up (if any) er: there is only one wlan module available for the omap3evm board (both made by Mistral) so this should be ok. [?] [?] No need to have the host pulling up the 1271's interrupt line (it's just wasting power). Yeah, we have that on ZOOM, too, but it's redundant. er: ok, I will change that for the omap3evm. Best Regards, Eyal attachment: winmail.dat
RE: Ping- Subject: [PATCH] omap: omap3evm: add support for the WL12xx WLAN module to the omap3evm
Sure, Will test it first thing on Sunday. Best Regards, Eyal From: Tony Lindgren [t...@atomide.com] Sent: Friday, February 18, 2011 12:20 AM To: Reizer, Eyal Cc: linux-omap@vger.kernel.org Subject: Re: Ping- Subject:[PATCH] omap: omap3evm: add support for the WL12xx WLAN module to the omap3evm * Reizer, Eyal ey...@ti.com [110215 07:11]: Dear Tony, I did not receive any comments to the patch I have send in the following link: http://marc.info/?l=linux-omapm=129612179900695w=2 Are there any issues with excepting this patch? Pushing to devel-board branch for the upcoming merge window. Can you please check it's working? I had to merge some other evm board changes manually.. Tony-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Ping- Subject: [PATCH] omap: omap3evm: add support for the WL12xx WLAN module to the omap3evm
* Reizer, Eyal ey...@ti.com [110215 07:11]: Dear Tony, I did not receive any comments to the patch I have send in the following link: http://marc.info/?l=linux-omapm=129612179900695w=2 Are there any issues with excepting this patch? Pushing to devel-board branch for the upcoming merge window. Can you please check it's working? I had to merge some other evm board changes manually.. 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
[no subject]
From: Hema HK hem...@ti.com
Moved all the board specific internal PHY functions out of usb_musb.c file
as this file is shared between the OMAP2+ and AM35xx platforms.
There exists a file which has the functions specific to internal PHY
used for OMAP4 platform. Moved all phy specific functions to this file
and passing these functions through board data in the board file.
Signed-off-by: Hema HK hem...@ti.com
Index: linux-2.6/arch/arm/mach-omap2/board-am3517evm.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/board-am3517evm.c
+++ linux-2.6/arch/arm/mach-omap2/board-am3517evm.c
@@ -409,6 +409,10 @@ static struct omap_musb_board_data musb_
.interface_type = MUSB_INTERFACE_ULPI,
.mode = MUSB_OTG,
.power = 500,
+ .set_phy_power = am35x_musb_phy_power,
+ .clear_irq = am35x_musb_clear_irq,
+ .set_mode = am35x_musb_set_mode,
+ .reset = am35x_musb_reset,
};
static __init void am3517_evm_musb_init(void)
Index: linux-2.6/arch/arm/mach-omap2/omap_phy_internal.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/omap_phy_internal.c
+++ linux-2.6/arch/arm/mach-omap2/omap_phy_internal.c
@@ -29,6 +29,7 @@
#include linux/usb.h
#include plat/usb.h
+#include control.h
/* OMAP control module register for UTMI PHY */
#define CONTROL_DEV_CONF 0x300
@@ -147,3 +148,95 @@ int omap4430_phy_exit(struct device *dev
return 0;
}
+
+void am35x_musb_reset(void)
+{
+ u32 regval;
+
+ /* Reset the musb interface */
+ regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
+
+ regval |= AM35XX_USBOTGSS_SW_RST;
+ omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
+
+ regval = ~AM35XX_USBOTGSS_SW_RST;
+ omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
+
+ regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
+}
+
+void am35x_musb_phy_power(u8 on)
+{
+ unsigned long timeout = jiffies + msecs_to_jiffies(100);
+ u32 devconf2;
+
+ if (on) {
+ /*
+* Start the on-chip PHY and its PLL.
+*/
+ devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+ devconf2 = ~(CONF2_RESET | CONF2_PHYPWRDN | CONF2_OTGPWRDN);
+ devconf2 |= CONF2_PHY_PLLON;
+
+ omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
+
+ pr_info(KERN_INFO Waiting for PHY clock good...\n);
+ while (!(omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2)
+CONF2_PHYCLKGD)) {
+ cpu_relax();
+
+ if (time_after(jiffies, timeout)) {
+ pr_err(KERN_ERR musb PHY clock good timed
out\n);
+ break;
+ }
+ }
+ } else {
+ /*
+* Power down the on-chip PHY.
+*/
+ devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+ devconf2 = ~CONF2_PHY_PLLON;
+ devconf2 |= CONF2_PHYPWRDN | CONF2_OTGPWRDN;
+ omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
+ }
+}
+
+void am35x_musb_clear_irq(void)
+{
+ u32 regval;
+
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval |= AM35XX_USBOTGSS_INT_CLR;
+ omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+}
+
+void am35x_musb_set_mode(u8 musb_mode)
+{
+ u32 devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+ devconf2 = ~CONF2_OTGMODE;
+ switch (musb_mode) {
+#ifdef CONFIG_USB_MUSB_HDRC_HCD
+ case MUSB_HOST: /* Force VBUS valid, ID = 0 */
+ devconf2 |= CONF2_FORCE_HOST;
+ break;
+#endif
+#ifdef CONFIG_USB_GADGET_MUSB_HDRC
+ case MUSB_PERIPHERAL: /* Force VBUS valid, ID = 1 */
+ devconf2 |= CONF2_FORCE_DEVICE;
+ break;
+#endif
+#ifdef CONFIG_USB_MUSB_OTG
+ case MUSB_OTG: /* Don't override the VBUS/ID comparators */
+ devconf2 |= CONF2_NO_OVERRIDE;
+ break;
+#endif
+ default:
+ pr_info(KERN_INFO Unsupported mode %u\n, musb_mode);
+ }
+
+ omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
+}
Index: linux-2.6/arch/arm/mach-omap2/usb-musb.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/usb-musb.c
+++ linux-2.6/arch/arm/mach-omap2/usb-musb.c
@@ -30,102 +30,9 @@
#include mach/irqs.h
#include mach/am35xx.h
#include plat/usb.h
-#include control.h
#if defined(CONFIG_USB_MUSB_OMAP2PLUS) || defined (CONFIG_USB_MUSB_AM35X)
-static void am35x_musb_reset(void)
-{
-
[no subject]
Moved all the board specific internal PHY functions out of usb_musb.c file
as this file is shared between the OMAP2+ and AM35xx platforms.
There exists a file which has the functions specific to internal PHY
used for OMAP4 platform. Moved all phy specific functions to this file
and passing these functions through board data in the board file.
Signed-off-by: Hema HK hem...@ti.com
Cc: Felipe Balbi ba...@ti.com
Index: linux-2.6/arch/arm/mach-omap2/board-am3517evm.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/board-am3517evm.c
+++ linux-2.6/arch/arm/mach-omap2/board-am3517evm.c
@@ -409,6 +409,10 @@ static struct omap_musb_board_data musb_
.interface_type = MUSB_INTERFACE_ULPI,
.mode = MUSB_OTG,
.power = 500,
+ .set_phy_power = am35x_musb_phy_power,
+ .clear_irq = am35x_musb_clear_irq,
+ .set_mode = am35x_musb_set_mode,
+ .reset = am35x_musb_reset,
};
static __init void am3517_evm_musb_init(void)
Index: linux-2.6/arch/arm/mach-omap2/omap_phy_internal.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/omap_phy_internal.c
+++ linux-2.6/arch/arm/mach-omap2/omap_phy_internal.c
@@ -29,6 +29,7 @@
#include linux/usb.h
#include plat/usb.h
+#include control.h
/* OMAP control module register for UTMI PHY */
#define CONTROL_DEV_CONF 0x300
@@ -147,3 +148,95 @@ int omap4430_phy_exit(struct device *dev
return 0;
}
+
+void am35x_musb_reset(void)
+{
+ u32 regval;
+
+ /* Reset the musb interface */
+ regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
+
+ regval |= AM35XX_USBOTGSS_SW_RST;
+ omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
+
+ regval = ~AM35XX_USBOTGSS_SW_RST;
+ omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
+
+ regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
+}
+
+void am35x_musb_phy_power(u8 on)
+{
+ unsigned long timeout = jiffies + msecs_to_jiffies(100);
+ u32 devconf2;
+
+ if (on) {
+ /*
+* Start the on-chip PHY and its PLL.
+*/
+ devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+ devconf2 = ~(CONF2_RESET | CONF2_PHYPWRDN | CONF2_OTGPWRDN);
+ devconf2 |= CONF2_PHY_PLLON;
+
+ omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
+
+ pr_info(KERN_INFO Waiting for PHY clock good...\n);
+ while (!(omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2)
+CONF2_PHYCLKGD)) {
+ cpu_relax();
+
+ if (time_after(jiffies, timeout)) {
+ pr_err(KERN_ERR musb PHY clock good timed
out\n);
+ break;
+ }
+ }
+ } else {
+ /*
+* Power down the on-chip PHY.
+*/
+ devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+ devconf2 = ~CONF2_PHY_PLLON;
+ devconf2 |= CONF2_PHYPWRDN | CONF2_OTGPWRDN;
+ omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
+ }
+}
+
+void am35x_musb_clear_irq(void)
+{
+ u32 regval;
+
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval |= AM35XX_USBOTGSS_INT_CLR;
+ omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+}
+
+void am35x_musb_set_mode(u8 musb_mode)
+{
+ u32 devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+ devconf2 = ~CONF2_OTGMODE;
+ switch (musb_mode) {
+#ifdef CONFIG_USB_MUSB_HDRC_HCD
+ case MUSB_HOST: /* Force VBUS valid, ID = 0 */
+ devconf2 |= CONF2_FORCE_HOST;
+ break;
+#endif
+#ifdef CONFIG_USB_GADGET_MUSB_HDRC
+ case MUSB_PERIPHERAL: /* Force VBUS valid, ID = 1 */
+ devconf2 |= CONF2_FORCE_DEVICE;
+ break;
+#endif
+#ifdef CONFIG_USB_MUSB_OTG
+ case MUSB_OTG: /* Don't override the VBUS/ID comparators */
+ devconf2 |= CONF2_NO_OVERRIDE;
+ break;
+#endif
+ default:
+ pr_info(KERN_INFO Unsupported mode %u\n, musb_mode);
+ }
+
+ omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
+}
Index: linux-2.6/arch/arm/mach-omap2/usb-musb.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/usb-musb.c
+++ linux-2.6/arch/arm/mach-omap2/usb-musb.c
@@ -30,102 +30,9 @@
#include mach/irqs.h
#include mach/am35xx.h
#include plat/usb.h
-#include control.h
#if defined(CONFIG_USB_MUSB_OMAP2PLUS) || defined (CONFIG_USB_MUSB_AM35X)
-static void am35x_musb_reset(void)
-{
-
Subject: [PATCH 0/5 v6]usb: musb: hwmod and runtime pm support for musb
This patch series makes OMAP2PLUS musb module implemented in HWMOD FW way. It also implements musb driver to use the runtime pm apis. As per the OMAP usbotg specification[1] musb sysconfig register has to be set to force idle and force standby when not used and set smart idle/standby or no idle/standby during operation. otherwise core-off will be prevented by musb. [1]: http://focus.ti.com/pdfs/wtbu/SWPU223D_Final_EPDF_06_07_2010.pdf This patch series is based on V2.6.38-rc4 + [1] +[2] [1] https://patchwork.kernel.org/patch/513461 [2] http://www.spinics.net/lists/linux-usb/msg40575.html with this patch series tested musb functionality like testusb, masstorage OMAP4430SDP, OMAP3430SDP, and OMAP3630 zoom3. Tested global suspend resume for offmode and retention on OMAP3630Zoom3. Idle path retention and offmode validation is not done with these patch series. Version History: --- Version V6 Calling runtime_pm_suspend in the pm_ops function was not effective. So using the bus runtime methods directly in the pm_ops suspend/resume functions. Version V5: Fixed review comments from Felipe. Version V4: Rebased the changes based on the re-orgnized patches submitted by Felipe. Fixed review comments received for V3. Dropped the idlepath power management patch with this series. Some of the links for V3 review comments: https://patchwork.kernel.org/patch/199482/ http://www.mail-archive.com/linux-omap@vger.kernel.org/msg35488.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg33201.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg35387.html Version V3 Added the patch for adding the hwmod database for OMAP2430. Re-arranged the patches in such a way that first migrate the musb driver to use the runtime PM apis and then added a patch to support offmode in idle path. Calling the runtime PM apis before disbaling the interupts in the idle path. Added the #ifdef CONFIG_PM_RUNTIME check in the musb core driver for calling the runtime PM APIs as non-omap platforms may not have the runtime pm enabled and clk_enable/disable should be called for them. Optimized the context save restore of musb registers only if the next state is going to offmode and previous state was offmode. Some of the links for V2 review comments http://www.mail-archive.com/linux-omap@vger.kernel.org/msg34068.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg32024.html http://www.spinics.net/lists/linux-usb/msg35562.html http://www.spinics.net/lists/linux-usb/msg35720.html Vesrion v2: Fixed review comments. Removed the omap_hwmod.h inclusion from musb.h file which was breaking the non-omap platform build. Using the runtime pm apis in the idle path(interrupts disabled). Added the omap4 hwmod data base. Version v1: initial version of the patch series. Some of the links for v1 http://www.spinics.net/lists/linux-usb/msg34570.html http://www.spinics.net/lists/linux-omap/msg34568.html http://www.spinics.net/lists/linux-usb/msg34544.html http://www.spinics.net/lists/linux-usb/msg34540.html http://www.spinics.net/lists/linux-usb/msg34589.html http://www.spinics.net/lists/linux-usb/msg34554.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg32973.html Signed-off-by: Hema HK hem...@ti.com Cc: Felipe Balbi ba...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Cousson, Benoit b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com --- Cousson, Benoit (1): OMAP4430: hwmod data: Adding USBOTG Hema HK (4): OMAP2430: hwmod data: Add USBOTG OMAP3xxx: hwmod data: Add USBOTG OMAP2+: musb: HWMOD adaptation for musb. usb: musb: Using runtime pm APIs for musb. arch/arm/mach-omap2/omap_hwmod_2430_data.c | 98 +++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 101 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 93 + arch/arm/mach-omap2/usb-musb.c | 76 +++-- drivers/usb/musb/musb_core.h |2 +- drivers/usb/musb/omap2430.c| 79 ++ 6 files changed, 369 insertions(+), 80 deletions(-) -- 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
[no subject]
unsubscribe linux-omap -- 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
Subject: [PATCH 0/5 v4]usb: musb: hwmod and runtime pm support for musb
This patch series makes OMAP2PLUS musb module implemented in HWMOD FW way. It also implements musb driver to use the runtime pm apis. As per the OMAP usbotg specification[1] musb sysconfig register has to be set to force idle and force standby when not used and set smart idle/standby or no idle/standby during operation. otherwise core-off will be prevented by musb. [1]: http://focus.ti.com/pdfs/wtbu/SWPU223D_Final_EPDF_06_07_2010.pdf This patch series is based on V2.6.37-rc4 + [2]+[3]+[4] [2] http://www.listware.net/201011/linux-usb/ 65625-patch-resend-v3-usb-musb-do-not-use-dma-for-control-transfers.html [3] Felipe's musb-reorg patch series. http://gitorious.org/usb/usb/commits/musb-hw [4] usb: otg: TWL6030: OMAP4430: musb transceiver driver support for OMAP4 posted by me. with this patch series tested musb functionality like testusb, masstorage OMAP4430SDP, OMAP3630 zoom3, OMAP3430 SDP Power management tests like retention and offmode validation tests are not done with these patches. There will be another set of patches submitted with PM on musb. Version History: --- Version V4: Rebased the changes based on the re-orgnized patches submitted by Felipe. Fixed review comments received for V3. Dropped the idlepath power management patch with this series. Some of the links for V3 review comments: https://patchwork.kernel.org/patch/199482/ http://www.mail-archive.com/linux-omap@vger.kernel.org/msg35488.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg33201.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg35387.html Version V3 Added the patch for adding the hwmod database for OMAP2430. Re-arranged the patches in such a way that first migrate the musb driver to use the runtime PM apis and then added a patch to support offmode in idle path. Calling the runtime PM apis before disbaling the interupts in the idle path. Added the #ifdef CONFIG_PM_RUNTIME check in the musb core driver for calling the runtime PM APIs as non-omap platforms may not have the runtime pm enabled and clk_enable/disable should be called for them. Optimized the context save restore of musb registers only if the next state is going to offmode and previous state was offmode. Some of the links for V2 review comments http://www.mail-archive.com/linux-omap@vger.kernel.org/msg34068.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg32024.html http://www.spinics.net/lists/linux-usb/msg35562.html http://www.spinics.net/lists/linux-usb/msg35720.html Vesrion v2: Fixed review comments. Removed the omap_hwmod.h inclusion from musb.h file which was breaking the non-omap platform build. Using the runtime pm apis in the idle path(interrupts disabled). Added the omap4 hwmod data base. Version v1: initial version of the patch series. Some of the links for v1 http://www.spinics.net/lists/linux-usb/msg34570.html http://www.spinics.net/lists/linux-omap/msg34568.html http://www.spinics.net/lists/linux-usb/msg34544.html http://www.spinics.net/lists/linux-usb/msg34540.html http://www.spinics.net/lists/linux-usb/msg34589.html http://www.spinics.net/lists/linux-usb/msg34554.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg32973.html Cousson, Benoit (1): OMAP4430: hwmod data: Adding USBOTG Hema HK (4): OMAP2430: hwmod data: Add USBOTG OMAP3xxx: hwmod data: Add USBOTG OMAP2+: musb: HWMOD adaptation for musb. usb: musb: Using runtime pm APIs for musb. arch/arm/mach-omap2/omap_hwmod_2430_data.c | 97 +++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 100 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 94 ++ arch/arm/mach-omap2/usb-musb.c | 66 ++ drivers/usb/musb/musb_core.h |2 +- drivers/usb/musb/omap2430.c| 77 + 6 files changed, 362 insertions(+), 74 deletions(-) -- 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
Subject: [PATCH 0/5 v5]usb: musb: hwmod and runtime pm support for musb
This patch series makes OMAP2PLUS musb module implemented in HWMOD FW way. It also implements musb driver to use the runtime pm apis. As per the OMAP usbotg specification[1] musb sysconfig register has to be set to force idle and force standby when not used and set smart idle/standby or no idle/standby during operation. otherwise core-off will be prevented by musb. [1]: http://focus.ti.com/pdfs/wtbu/SWPU223D_Final_EPDF_06_07_2010.pdf This patch series is based on V2.6.37-rc4 + [2]+[3]+[4] [2] http://www.listware.net/201011/linux-usb/ 65625-patch-resend-v3-usb-musb-do-not-use-dma-for-control-transfers.html [3] Felipe's musb-reorg patch series. http://gitorious.org/usb/usb/commits/musb-hw [4] usb: otg: TWL6030: OMAP4430: musb transceiver driver support for OMAP4 posted by me. with this patch series tested musb functionality like testusb, masstorage OMAP4430SDP, OMAP3630 zoom3, OMAP3430 SDP Power management tests like retention and offmode validation tests are not done with these patches. There will be another set of patches submitted with PM on musb. Version History: --- Version V5: Fixed review comments from Felipe. Version V4: Rebased the changes based on the re-orgnized patches submitted by Felipe. Fixed review comments received for V3. Dropped the idlepath power management patch with this series. Some of the links for V3 review comments: https://patchwork.kernel.org/patch/199482/ http://www.mail-archive.com/linux-omap@vger.kernel.org/msg35488.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg33201.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg35387.html Version V3 Added the patch for adding the hwmod database for OMAP2430. Re-arranged the patches in such a way that first migrate the musb driver to use the runtime PM apis and then added a patch to support offmode in idle path. Calling the runtime PM apis before disbaling the interupts in the idle path. Added the #ifdef CONFIG_PM_RUNTIME check in the musb core driver for calling the runtime PM APIs as non-omap platforms may not have the runtime pm enabled and clk_enable/disable should be called for them. Optimized the context save restore of musb registers only if the next state is going to offmode and previous state was offmode. Some of the links for V2 review comments http://www.mail-archive.com/linux-omap@vger.kernel.org/msg34068.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg32024.html http://www.spinics.net/lists/linux-usb/msg35562.html http://www.spinics.net/lists/linux-usb/msg35720.html Vesrion v2: Fixed review comments. Removed the omap_hwmod.h inclusion from musb.h file which was breaking the non-omap platform build. Using the runtime pm apis in the idle path(interrupts disabled). Added the omap4 hwmod data base. Version v1: initial version of the patch series. Some of the links for v1 http://www.spinics.net/lists/linux-usb/msg34570.html http://www.spinics.net/lists/linux-omap/msg34568.html http://www.spinics.net/lists/linux-usb/msg34544.html http://www.spinics.net/lists/linux-usb/msg34540.html http://www.spinics.net/lists/linux-usb/msg34589.html http://www.spinics.net/lists/linux-usb/msg34554.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg32973.html Signed-off-by: Hema HK hem...@ti.com Cc: Felipe Balbi ba...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Cousson, Benoit b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com --- Cousson, Benoit (1): OMAP4430: hwmod data: Adding USBOTG Hema HK (4): OMAP2430: hwmod data: Add USBOTG OMAP3xxx: hwmod data: Add USBOTG OMAP2+: musb: HWMOD adaptation for musb. usb: musb: Using runtime pm APIs for musb. arch/arm/mach-omap2/omap_hwmod_2430_data.c | 97 +++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 100 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 94 ++ arch/arm/mach-omap2/usb-musb.c | 66 ++ drivers/usb/musb/musb_core.h |2 +- drivers/usb/musb/omap2430.c| 77 + 6 files changed, 362 insertions(+), 74 deletions(-) -- 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
[no subject]
unsubscribe linux-omap-- 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
[no subject]
subscribe linux-omap -- 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
Subject: [PATCH 06/10] [PM-WIP-UART] OMAP4 hwmod : Adding hwmod data for UART
From: Benoit Cousson b-cous...@ti.com
Adding HWMOD data for UART on OMAP4
Cc: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 234
1 files changed, 234 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 db62b84..8266b5c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -778,6 +778,235 @@ static struct omap_hwmod omap44xx_mpu_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/*
+ * 'uart' class
+ * universal asynchronous receiver/transmitter (uart)
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_uart_sysc = {
+ .rev_offs = 0x0050,
+ .sysc_offs = 0x0054,
+ .syss_offs = 0x0058,
+ .sysc_flags = (SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_uart_hwmod_class = {
+ .name = uart,
+ .sysc = omap44xx_uart_sysc,
+};
+
+/* uart1 */
+static struct omap_hwmod omap44xx_uart1_hwmod;
+static struct omap_hwmod_irq_info omap44xx_uart1_irqs[] = {
+ { .irq = 72 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_dma_info omap44xx_uart1_sdma_reqs[] = {
+ { .name = tx, .dma_req = 48 + OMAP44XX_DMA_REQ_START },
+ { .name = rx, .dma_req = 49 + OMAP44XX_DMA_REQ_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_uart1_addrs[] = {
+ {
+ .pa_start = 0x4806a000,
+ .pa_end = 0x4806a0ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_per - uart1 */
+static struct omap_hwmod_ocp_if omap44xx_l4_per__uart1 = {
+ .master = omap44xx_l4_per_hwmod,
+ .slave = omap44xx_uart1_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_uart1_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_uart1_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* uart1 slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_uart1_slaves[] = {
+ omap44xx_l4_per__uart1,
+};
+
+static struct omap_hwmod omap44xx_uart1_hwmod = {
+ .name = uart1,
+ .class = omap44xx_uart_hwmod_class,
+ .mpu_irqs = omap44xx_uart1_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_uart1_irqs),
+ .sdma_reqs = omap44xx_uart1_sdma_reqs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap44xx_uart1_sdma_reqs),
+ .main_clk = uart1_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_L4PER_UART1_CLKCTRL,
+ },
+ },
+ .slaves = omap44xx_uart1_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_uart1_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/* uart2 */
+static struct omap_hwmod omap44xx_uart2_hwmod;
+static struct omap_hwmod_irq_info omap44xx_uart2_irqs[] = {
+ { .irq = 73 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_dma_info omap44xx_uart2_sdma_reqs[] = {
+ { .name = tx, .dma_req = 50 + OMAP44XX_DMA_REQ_START },
+ { .name = rx, .dma_req = 51 + OMAP44XX_DMA_REQ_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_uart2_addrs[] = {
+ {
+ .pa_start = 0x4806c000,
+ .pa_end = 0x4806c0ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_per - uart2 */
+static struct omap_hwmod_ocp_if omap44xx_l4_per__uart2 = {
+ .master = omap44xx_l4_per_hwmod,
+ .slave = omap44xx_uart2_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_uart2_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_uart2_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* uart2 slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_uart2_slaves[] = {
+ omap44xx_l4_per__uart2,
+};
+
+static struct omap_hwmod omap44xx_uart2_hwmod = {
+ .name = uart2,
+ .class = omap44xx_uart_hwmod_class,
+ .mpu_irqs = omap44xx_uart2_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_uart2_irqs),
+ .sdma_reqs = omap44xx_uart2_sdma_reqs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap44xx_uart2_sdma_reqs),
+ .main_clk = uart2_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_L4PER_UART2_CLKCTRL,
+ },
+ },
+ .slaves = omap44xx_uart2_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_uart2_slaves),
+ .omap_chip =
Re: Subject: [PATCH 06/10] [PM-WIP-UART] OMAP4 hwmod : Adding hwmod data for UART
Please ignore , will send with proper subject
Regards,
Kishore
From: Benoit Cousson b-cous...@ti.com
Adding HWMOD data for UART on OMAP4
Cc: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 234
1 files changed, 234 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 db62b84..8266b5c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -778,6 +778,235 @@ static struct omap_hwmod omap44xx_mpu_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/*
+ * 'uart' class
+ * universal asynchronous receiver/transmitter (uart)
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_uart_sysc = {
+ .rev_offs = 0x0050,
+ .sysc_offs = 0x0054,
+ .syss_offs = 0x0058,
+ .sysc_flags = (SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
+SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_uart_hwmod_class = {
+ .name = uart,
+ .sysc = omap44xx_uart_sysc,
+};
+
+/* uart1 */
+static struct omap_hwmod omap44xx_uart1_hwmod;
+static struct omap_hwmod_irq_info omap44xx_uart1_irqs[] = {
+ { .irq = 72 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_dma_info omap44xx_uart1_sdma_reqs[] = {
+ { .name = tx, .dma_req = 48 + OMAP44XX_DMA_REQ_START },
+ { .name = rx, .dma_req = 49 + OMAP44XX_DMA_REQ_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_uart1_addrs[] = {
+ {
+ .pa_start = 0x4806a000,
+ .pa_end = 0x4806a0ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_per - uart1 */
+static struct omap_hwmod_ocp_if omap44xx_l4_per__uart1 = {
+ .master = omap44xx_l4_per_hwmod,
+ .slave = omap44xx_uart1_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_uart1_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_uart1_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* uart1 slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_uart1_slaves[] = {
+ omap44xx_l4_per__uart1,
+};
+
+static struct omap_hwmod omap44xx_uart1_hwmod = {
+ .name = uart1,
+ .class = omap44xx_uart_hwmod_class,
+ .mpu_irqs = omap44xx_uart1_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_uart1_irqs),
+ .sdma_reqs = omap44xx_uart1_sdma_reqs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap44xx_uart1_sdma_reqs),
+ .main_clk = uart1_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_L4PER_UART1_CLKCTRL,
+ },
+ },
+ .slaves = omap44xx_uart1_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_uart1_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/* uart2 */
+static struct omap_hwmod omap44xx_uart2_hwmod;
+static struct omap_hwmod_irq_info omap44xx_uart2_irqs[] = {
+ { .irq = 73 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_dma_info omap44xx_uart2_sdma_reqs[] = {
+ { .name = tx, .dma_req = 50 + OMAP44XX_DMA_REQ_START },
+ { .name = rx, .dma_req = 51 + OMAP44XX_DMA_REQ_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_uart2_addrs[] = {
+ {
+ .pa_start = 0x4806c000,
+ .pa_end = 0x4806c0ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_per - uart2 */
+static struct omap_hwmod_ocp_if omap44xx_l4_per__uart2 = {
+ .master = omap44xx_l4_per_hwmod,
+ .slave = omap44xx_uart2_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_uart2_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_uart2_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* uart2 slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_uart2_slaves[] = {
+ omap44xx_l4_per__uart2,
+};
+
+static struct omap_hwmod omap44xx_uart2_hwmod = {
+ .name = uart2,
+ .class = omap44xx_uart_hwmod_class,
+ .mpu_irqs = omap44xx_uart2_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_uart2_irqs),
+ .sdma_reqs = omap44xx_uart2_sdma_reqs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap44xx_uart2_sdma_reqs),
+ .main_clk = uart2_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_L4PER_UART2_CLKCTRL,
+ },
+ },
+ .slaves = omap44xx_uart2_slaves,
+ .slaves_cnt
[no subject]
I have a urgent message to share with you get back to me for details... -- 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
[no subject]
unsubscribe linux-omap ming.c...@authentec.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
subscribe linux-omap -- 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
[no subject]
Subject: [PATCH] MFD: TWL4030: changes for TRITON glitch fix.
Fix for TWL5030 Silicon Errata 27 28:
27 - VDD1, VDD2, may have glitches when their output value is updated.
28 - VDD1 and / or VDD2 DCDC clock may stop working when internal clock
is switched from internal to external.
Workaround requires the TWL DCDCs to use HFCLK instead of internal oscillator.
Also enable TWL watchdog before switching the osc to recover
if the VDD1/VDD2 stop working.
Fix is required for TWL5030 Silicon version less than or equal to ES1.1
Changes are done under the macro CONFIG_TWL5030_GLITCH_FIX,
since the IDCODE register on TWL5030 Si is not updated correctly.
Updated the TWL resource settings and volt, clock setuptime.
Changes taken from Nishanth Menons gaia glitch fix patch.
Signed-off-by: Lesly A M lesl...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: David Derrick dderr...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
This patch has dependency on:
SmartReflex patch series from Thara.
Update TRITON power scripts from Lesly.
This patch series is based off Kevin's tree origin/pm branch.
This changes are tested on OMAP3430 SDP board with:
enable_off_mode
voltage_off_while_idle
sleep_while_idle (VDD1/VDD2 voltage scaling to 0v) enabled in cpuidle
and suspned path.
Also tested for reboot and dvfs.
arch/arm/mach-omap2/board-3430sdp.c | 40 +
arch/arm/mach-omap2/board-zoom-peripherals.c | 40 +
arch/arm/mach-omap2/include/mach/board-sdp.h |4 +
arch/arm/mach-omap2/include/mach/board-zoom.h |4 +
arch/arm/mach-omap2/twl4030-script.c | 84 +++
arch/arm/mach-omap2/twl4030-script.h |9 ++
arch/arm/mach-omap2/voltage.c | 10 +++
arch/arm/mach-omap2/voltage.h |4 +
arch/arm/plat-omap/Kconfig|7 ++
drivers/mfd/twl4030-power.c | 106 +
10 files changed, 308 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 4f94b6f..d174d21 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -475,6 +475,36 @@ static struct twl4030_resconfig twl4030_rconfig[] = {
{ 0, 0},
};
+#ifdef CONFIG_TWL5030_GLITCH_FIX
+static struct twl4030_resconfig twl4030_rconfig_glitchfix[] = {
+ { .resource = RES_VPLL1, .devgroup = DEV_GRP_P1 | DEV_GRP_P3,
+ .type = 3, .type2 = 1, .remap_sleep = RES_STATE_OFF },
+ { .resource = RES_VINTANA1, .devgroup = DEV_GRP_ALL, .type = 1,
+ .type2 = 2, .remap_sleep = RES_STATE_SLEEP },
+ { .resource = RES_VINTANA2, .devgroup = DEV_GRP_ALL, .type = 0,
+ .type2 = 2, .remap_sleep = RES_STATE_SLEEP },
+ { .resource = RES_VINTDIG, .devgroup = DEV_GRP_ALL, .type = 1,
+ .type2 = 2, .remap_sleep = RES_STATE_SLEEP },
+ { .resource = RES_VIO, .devgroup = DEV_GRP_ALL, .type = 2,
+ .type2 = 2, .remap_sleep = RES_STATE_SLEEP },
+ { .resource = RES_VDD1, .devgroup = DEV_GRP_P1 | DEV_GRP_P3,
+ .type = 4, .type2 = 1, .remap_sleep = RES_STATE_OFF },
+ { .resource = RES_VDD2, .devgroup = DEV_GRP_P1 | DEV_GRP_P3,
+ .type = 3, .type2 = 1, .remap_sleep = RES_STATE_OFF },
+ { .resource = RES_REGEN, .devgroup = DEV_GRP_ALL, .type = 2,
+ .type2 = 1, .remap_sleep = RES_STATE_SLEEP },
+ { .resource = RES_NRES_PWRON, .devgroup = DEV_GRP_ALL, .type = 0,
+ .type2 = 1, .remap_sleep = RES_STATE_SLEEP },
+ { .resource = RES_CLKEN, .devgroup = DEV_GRP_ALL, .type = 3,
+ .type2 = 2, .remap_sleep = RES_STATE_SLEEP },
+ { .resource = RES_SYSEN, .devgroup = DEV_GRP_ALL, .type = 6,
+ .type2 = 1, .remap_sleep = RES_STATE_SLEEP },
+ { .resource = RES_HFCLKOUT, .devgroup = DEV_GRP_P1 | DEV_GRP_P3,
+ .type = 0, .type2 = 1, .remap_sleep = RES_STATE_SLEEP },
+ { 0, 0},
+};
+#endif
+
static struct twl4030_power_data sdp3430_t2scripts_data __initdata = {
.resource_config = twl4030_rconfig,
};
@@ -840,6 +870,16 @@ static struct omap_musb_board_data musb_board_data = {
.power = 100,
};
+#ifdef CONFIG_TWL5030_GLITCH_FIX
+void twl5030_glitchfix_changes_3430sdp(void)
+{
+ sdp3430_t2scripts_data.resource_config = twl4030_rconfig_glitchfix;
+ use_twl4030_script_glitchfix(sdp3430_t2scripts_data);
+ omap_voltage_twl5030_glitchfix();
+}
+EXPORT_SYMBOL(twl5030_glitchfix_changes_3430sdp);
+#endif
+
static void __init omap_3430sdp_init(void)
{
twl4030_get_scripts(sdp3430_t2scripts_data);
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 462d7ee..76f28d1 100755
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
[no subject]
Subject: [PATCH/RFC] OMAP2: serial.c: Fix number of uarts in early_init
The omap_serial_early_init prints the following errors:
Could not get uart4_ick
Could not get uart4_fck
because all the uarts available in omap_uart[] will be initialized.
Only omap4430 and omap3630 have 4 uarts at the moment.
This patch reduces the number of uarts when cpu is not omap4430 or
omap3630.
Signed-off-by: Thomas Weber we...@corscience.de
---
arch/arm/mach-omap2/serial.c | 15 ++-
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index b79bc89..da77930 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -644,16 +644,21 @@ static void serial_out_override(struct uart_port *up, int
offset, int value)
}
void __init omap_serial_early_init(void)
{
- int i;
+ int i, nr_ports;
char name[16];
+ if (!(cpu_is_omap3630() || cpu_is_omap4430()))
+ nr_ports = 3;
+ else
+ nr_ports = ARRAY_SIZE(omap_uart);
+
/*
* Make sure the serial ports are muxed on at this point.
* You have to mux them off in device drivers later on
* if not needed.
*/
- for (i = 0; i ARRAY_SIZE(omap_uart); i++) {
+ for (i = 0; i nr_ports; i++) {
struct omap_uart_state *uart = omap_uart[i];
struct platform_device *pdev = uart-pdev;
struct device *dev = pdev-dev;
@@ -669,17 +674,17 @@ void __init omap_serial_early_init(void)
continue;
}
- sprintf(name, uart%d_ick, i+1);
+ sprintf(name, uart%d_ick, i + 1);
uart-ick = clk_get(NULL, name);
if (IS_ERR(uart-ick)) {
- printk(KERN_ERR Could not get uart%d_ick\n, i+1);
+ printk(KERN_ERR Could not get uart%d_ick\n, i + 1);
uart-ick = NULL;
}
sprintf(name, uart%d_fck, i+1);
uart-fck = clk_get(NULL, name);
if (IS_ERR(uart-fck)) {
- printk(KERN_ERR Could not get uart%d_fck\n, i+1);
+ printk(KERN_ERR Could not get uart%d_fck\n, i + 1);
uart-fck = NULL;
}
--
1.6.4.4
--
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
[no subject]
This patch disables the newly introduced internal pull-up feature in
OMAP3630, to use only the external HW resitor = 470 Ohm for the
assured functionality in HS mode.
While testing the I2C in High Speed mode, it was discovered that
without a proper pull-up resitor, there is data corruption during
multi-byte transfers. RTC(time_set) test case was used for testing.
From the analysis done, it was concluded that ideally we need a pull-up
of 1.6 K Ohm (recomended) or atleast 470 Ohm or greater for assured
performance in HS mode.
Signed-off-by: Moiz Sonasath m-sonas...@ti.com
Signed-off-by: Allen Pais allen.p...@ti.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
arch/arm/mach-omap2/i2c.c | 24
arch/arm/plat-omap/include/plat/control.h | 14 ++
2 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/i2c.c b/arch/arm/mach-omap2/i2c.c
index 789ca8c..2e6eb28 100644
--- a/arch/arm/mach-omap2/i2c.c
+++ b/arch/arm/mach-omap2/i2c.c
@@ -22,6 +22,7 @@
#include plat/cpu.h
#include plat/i2c.h
#include plat/mux.h
+#include plat/control.h
#include mux.h
@@ -52,5 +53,28 @@ int __init omap_register_i2c_bus(int bus_id, u32 clkrate,
omap_mux_init_signal(mux_name, OMAP_PIN_INPUT);
}
+ /* Disable OMAP 3630 internal pull-ups for all I2Ci */
+ if (cpu_is_omap3630() !(omap_ctrl_readl(OMAP343X_CONTROL_PROG_IO1)
OMAP3630_PRG_I2C1_PULLUPRESX)) {
+
+ u32 prog_io;
+
+ prog_io = omap_ctrl_readl(OMAP343X_CONTROL_PROG_IO1);
+ /* Program (bit 19)=1 to disable internal pull-up on I2C1 */
+ prog_io |= OMAP3630_PRG_I2C1_PULLUPRESX;
+ /* Program (bit 0)=1 to disable internal pull-up on I2C2 */
+ prog_io |= OMAP3630_PRG_I2C2_PULLUPRESX;
+ omap_ctrl_writel(prog_io, OMAP343X_CONTROL_PROG_IO1);
+
+ prog_io = omap_ctrl_readl(OMAP36XX_CONTROL_PROG_IO2);
+ /* Program (bit 7)=1 to disable internal pull-up on I2C3 */
+ prog_io |= OMAP3630_PRG_I2C3_PULLUPRESX;
+ omap_ctrl_writel(prog_io, OMAP36XX_CONTROL_PROG_IO2);
+
+ prog_io = omap_ctrl_readl(OMAP36XX_CONTROL_PROG_IO_WKUP1);
+ /* Program (bit 5)=1 to disable internall pull-up on I2C4(SR) */
+ prog_io |= OMAP3630_PRG_SR_PULLUPRESX;
+ omap_ctrl_writel(prog_io, OMAP36XX_CONTROL_PROG_IO_WKUP1);
+ }
+
return omap_plat_register_i2c_bus(bus_id, clkrate, info, len);
}
diff --git a/arch/arm/plat-omap/include/plat/control.h
b/arch/arm/plat-omap/include/plat/control.h
index 2074473..9e58d8e 100644
--- a/arch/arm/plat-omap/include/plat/control.h
+++ b/arch/arm/plat-omap/include/plat/control.h
@@ -169,6 +169,9 @@
#define AM35XX_CONTROL_IP_SW_RESET (OMAP2_CONTROL_GENERAL + 0x0328)
#define AM35XX_CONTROL_IPSS_CLK_CTRL(OMAP2_CONTROL_GENERAL + 0x032C)
+/* 36xx-only CONTROL_GENERAL register offsets */
+#define OMAP36XX_CONTROL_PROG_IO2 (OMAP2_CONTROL_GENERAL + 0x0198)
+
/* 34xx PADCONF register offsets */
#define OMAP343X_PADCONF_ETK(i)(OMAP2_CONTROL_PADCONFS + 0x5a8
+ \
(i)*2)
@@ -200,6 +203,9 @@
#define OMAP343X_CONTROL_WKUP_DEBOBS3 (OMAP343X_CONTROL_GENERAL_WKUP + 0x014)
#define OMAP343X_CONTROL_WKUP_DEBOBS4 (OMAP343X_CONTROL_GENERAL_WKUP + 0x018)
+/* 36xx-only GENERAL_WKUP register offsets */
+#define OMAP36XX_CONTROL_PROG_IO_WKUP1 (OMAP343X_CONTROL_GENERAL_WKUP + 0x020)
+
/* 34xx D2D idle-related pins, handled by PM core */
#define OMAP3_PADCONF_SAD2D_MSTANDBY 0x250
#define OMAP3_PADCONF_SAD2D_IDLEACK0x254
@@ -250,6 +256,8 @@
#define OMAP2_PBIASLITEVMODE0 (1 0)
/* CONTROL_PROG_IO1 bits */
+#define OMAP3630_PRG_I2C2_PULLUPRESX(1 0)
+#define OMAP3630_PRG_I2C1_PULLUPRESX (1 19)
#define OMAP3630_PRG_SDMMC1_SPEEDCTRL (1 20)
/* CONTROL_IVA2_BOOTMOD bits */
@@ -257,6 +265,12 @@
#define OMAP3_IVA2_BOOTMOD_MASK(0xf 0)
#define OMAP3_IVA2_BOOTMOD_IDLE(0x1 0)
+/* CONTROL_PROG_IO2 bits on omap3630 */
+#define OMAP3630_PRG_I2C3_PULLUPRESX(1 7)
+
+/* CONTROL_PROG_IO_WKUP1 bits on omap3630 */
+#define OMAP3630_PRG_SR_PULLUPRESX(1 5)
+
/* CONTROL_PADCONF_X bits */
#define OMAP3_PADCONF_WAKEUPEVENT0 (1 15)
#define OMAP3_PADCONF_WAKEUPENABLE0(1 14)
--
1.5.6.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
[no subject]
unsubscribe linux-omap -- 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
[no subject]
Bcc: Subject: GPIO chip select support in omap2_mcspi driver Hey, Recently I have been looking to use a BeagleBoard to drive several serial ADCs and DACs in a data acquisition and analysis setup. Unfortunately, the BeagleBoard is severely limited by the number of SPI controllers it exposes on the expansion connector (McSPI3 with 2 CS lines and McSPI4 with one). This is insufficient for our application and thus I have been investigating adding support to the mcspi driver for using GPIO lines as chip select lines, as is done in the pxa2xx, bfin5xx, and s3c24xx drivers. To this end, I have a few questions about how this support was implemented. First, it seems that the s3c24xx driver is built on the spi_bitbang driver, despite interfacing with a dedicated hardware SPI controller. What is the reason for this? Was this done specifically for the purpose of incorporating support for GPIO CS pins? It seems like the rough idea is to add a cs_gpio field to the device struct (omap2_mcspi) and add the appropriate code to the omap2_mcspi_force_cs() to bring cs_gpio high or low if it is valid. The potential problem I can see with this is that omap2_mcspi_set_enable() is called to enable the channel before the force_cs() is called (in omap2_mcspi_work()). If I'm interpreting the documentation correctly, the enable bit starts the clocks, meaning that the chip will begin clocking out data before CS is brought high. I must be missing something here, no? For reference, I included a short list of relevant commits below, largely for my own benefit. I would greatly appreciate any feedback you might have. Thanks, - Ben pxa2xx_spi: a7bb3909b3293d503211d7f6af8ed62c1644b686 bfin_spi: 42c78b2bf51bafb4cfa98dfecc28dd9b8bcd04b0 -- 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
[no subject]
From: Vimal Singh vimalsi...@ti.com
Adding NAND support for ZOOM2 and LDP board. I have tested it for ZOOM2
boards, someone can verify it for LDP, hopefully it should not have any
problem.
The size of the U-Boot environment partition was increased to 1.25MB.
Vikram: Changed ldp name to zoom.
Future boards will be called Zoom2/3/4 etc.
LDP is a Zoom1. Somhow the LDP name got stuck to that.
In v-3: Corrected prototype of 'unlock' function pointer in structure
'omap_nand_platform_data'.
Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
arch/arm/mach-omap2/Makefile |2
arch/arm/mach-omap2/board-ldp.c |2
arch/arm/mach-omap2/board-zoom-flash.c | 196 +++
arch/arm/mach-omap2/board-zoom2.c|2
arch/arm/plat-omap/include/mach/board-zoom.h | 36
arch/arm/plat-omap/include/mach/nand.h |2
6 files changed, 240 insertions(+)
Index: linux-omap-2.6/arch/arm/mach-omap2/Makefile
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/Makefile
+++ linux-omap-2.6/arch/arm/mach-omap2/Makefile
@@ -59,6 +59,7 @@ obj-$(CONFIG_MACH_OMAP_APOLLON) += boar
obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \
mmc-twl4030.o
obj-$(CONFIG_MACH_OMAP_LDP)+= board-ldp.o \
+ board-zoom-flash.o \
mmc-twl4030.o
obj-$(CONFIG_MACH_OVERO) += board-overo.o \
mmc-twl4030.o
@@ -74,6 +75,7 @@ obj-$(CONFIG_MACH_NOKIA_RX51) += board-
board-rx51-peripherals.o \
mmc-twl4030.o
obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \
+ board-zoom-flash.o \
mmc-twl4030.o \
board-zoom-debugboard.o
Index: linux-omap-2.6/arch/arm/mach-omap2/board-ldp.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/board-ldp.c
+++ linux-omap-2.6/arch/arm/mach-omap2/board-ldp.c
@@ -42,6 +42,7 @@
#include mach/control.h
#include mach/usb.h
#include mach/keypad.h
+#include mach/board-zoom.h
#include mmc-twl4030.h
@@ -381,6 +382,7 @@ static void __init omap_ldp_init(void)
ads7846_dev_init();
omap_serial_init();
usb_musb_init();
+ zoom_flash_init();
twl4030_mmc_init(mmc);
/* link regulators to MMC adapters */
Index: linux-omap-2.6/arch/arm/mach-omap2/board-zoom-flash.c
===
--- /dev/null
+++ linux-omap-2.6/arch/arm/mach-omap2/board-zoom-flash.c
@@ -0,0 +1,196 @@
+/*
+ * arch/arm/mach-omap2/board-zoom-flash.c
+ *
+ * Copyright (C) 2008-09 Texas Instruments Inc.
+ *
+ * Modified from mach-omap2/board-2430sdp-flash.c
+ * Author(s): Rohit Choraria rohi...@ti.com
+ *Vimal Singh vimalsi...@ti.com
+ *
+ * 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 linux/kernel.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/mtd/mtd.h
+#include linux/mtd/partitions.h
+#include linux/mtd/nand.h
+#include linux/types.h
+#include linux/io.h
+
+#include asm/mach/flash.h
+#include mach/board.h
+#include mach/gpmc.h
+#include mach/nand.h
+
+#include mach/board-zoom.h
+
+#define NAND_CMD_UNLOCK1 0x23
+#define NAND_CMD_UNLOCK2 0x24
+/**
+ * @brief platform specific unlock function
+ *
+ * @param mtd - mtd info
+ * @param ofs - offset to start unlock from
+ * @param len - length to unlock
+ *
+ * @return - unlock status
+ */
+static int omap_ldp_nand_unlock(struct mtd_info *mtd, loff_t ofs, size_t len)
+{
+ int ret = 0;
+ int chipnr;
+ int status;
+ unsigned long page;
+ struct nand_chip *this = mtd-priv;
+ printk(KERN_INFO nand_unlock: start: %08x, length: %d!\n,
+ (int)ofs, (int)len);
+
+ /* select the NAND device */
+ chipnr = (int)(ofs this-chip_shift);
+ this-select_chip(mtd, chipnr);
+ /* check the WP bit */
+ this-cmdfunc(mtd, NAND_CMD_STATUS, -1, -1);
+ if ((this-read_byte(mtd) 0x80) == 0) {
+ printk(KERN_ERR nand_unlock: Device is write protected!\n);
+ ret = -EINVAL;
+ goto out;
+ }
+
+ if ((ofs (mtd-writesize - 1)) != 0) {
+ printk(KERN_ERR nand_unlock: Start address must be
+ beginning of nand page!\n);
+ ret = -EINVAL;
+
[no subject]
From: Syed Rafiuddin rafiuddin.s...@ti.com
This patch Adds Keypad support on OMAP4.And adds
OMAP4 register addresses and configures them for OMAP4.
This patch has been updated as per the comments received from
Trilok Soni to remove GPIO based omap2 keypad logic from omap_keypad.c
(http://www.mail-archive.com/linux-omap@vger.kernel.org/msg14570.html)
Matrix_keypad.c (gpio based keypad driver) can be used in OMAP2,
which is not tested on OMAP2 since unavailability of omap2 target's.
Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com
---
drivers/input/keyboard/omap-keypad.c | 247 ---
1 files changed, 115 insertions(+), 132 deletions(-)
Index: kernel-omap4-base/drivers/input/keyboard/omap-keypad.c
===
--- kernel-omap4-base.orig/drivers/input/keyboard/omap-keypad.c 2009-08-19
12:23:14.0 +0530
+++ kernel-omap4-base/drivers/input/keyboard/omap-keypad.c 2009-08-19
18:25:17.0 +0530
@@ -44,6 +44,36 @@
#undef NEW_BOARD_LEARNING_MODE
+#define OMAP4_KBDOCP_BASE 0x4A31C000
+#define OMAP4_KBD_REVISION 0x00
+#define OMAP4_KBD_SYSCONFIG0x10
+#define OMAP4_KBD_SYSSTATUS0x14
+#define OMAP4_KBD_IRQSTATUS0x18
+#define OMAP4_KBD_IRQENABLE0x1C
+#define OMAP4_KBD_WAKEUPENABLE 0x20
+#define OMAP4_KBD_PENDING 0x24
+#define OMAP4_KBD_CTRL 0x28
+#define OMAP4_KBD_DEBOUNCINGTIME 0x2C
+#define OMAP4_KBD_LONGKEYTIME 0x30
+#define OMAP4_KBD_TIMEOUT 0x34
+#define OMAP4_KBD_STATEMACHINE 0x38
+#define OMAP4_KBD_ROWINPUTS0x3C
+#define OMAP4_KBD_COLUMNOUTPUTS0x40
+#define OMAP4_KBD_FULLCODE31_0 0x44
+#define OMAP4_KBD_FULLCODE63_320x48
+
+#define OMAP4_KBD_SYSCONFIG_SOFTRST(1 1)
+#define OMAP4_KBD_SYSCONFIG_ENAWKUP(1 2)
+#define OMAP4_KBD_IRQENABLE_EVENTEN(1 0)
+#define OMAP4_KBD_IRQENABLE_LONGKEY(1 1)
+#define OMAP4_KBD_IRQENABLE_TIMEOUTEN (1 2)
+#define OMAP4_KBD_CTRL_NOSOFTMODE (1 1)
+#define OMAP4_KBD_CTRLPTVVALUE (1 2)
+#define OMAP4_KBD_CTRLPTV (1 1)
+#define OMAP4_KBD_IRQDISABLE 0x00
+
+#define OMAP4_KBD_IRQSTATUSDISABLE 0x
+
static void omap_kp_tasklet(unsigned long);
static void omap_kp_timer(unsigned long);
@@ -65,55 +95,16 @@ struct omap_kp {
static DECLARE_TASKLET_DISABLED(kp_tasklet, omap_kp_tasklet, 0);
static int *keymap;
-static unsigned int *row_gpios;
-static unsigned int *col_gpios;
-
-#ifdef CONFIG_ARCH_OMAP2
-static void set_col_gpio_val(struct omap_kp *omap_kp, u8 value)
-{
- int col;
-
- for (col = 0; col omap_kp-cols; col++)
- gpio_set_value(col_gpios[col], value (1 col));
-}
-
-static u8 get_row_gpio_val(struct omap_kp *omap_kp)
-{
- int row;
- u8 value = 0;
-
- for (row = 0; row omap_kp-rows; row++) {
- if (gpio_get_value(row_gpios[row]))
- value |= (1 row);
- }
- return value;
-}
-#else
-#defineset_col_gpio_val(x, y) do {} while (0)
-#defineget_row_gpio_val(x) 0
-#endif
static irqreturn_t omap_kp_interrupt(int irq, void *dev_id)
{
- struct omap_kp *omap_kp = dev_id;
+ if (cpu_is_omap44xx()) {
+ /* disable keyboard interrupt and schedule for handling */
+ omap_writel(OMAP4_KBD_IRQDISABLE, OMAP4_KBDOCP_BASE +
+ OMAP4_KBD_IRQENABLE);
- /* disable keyboard interrupt and schedule for handling */
- if (cpu_is_omap24xx()) {
- int i;
-
- for (i = 0; i omap_kp-rows; i++) {
- int gpio_irq = gpio_to_irq(row_gpios[i]);
- /*
-* The interrupt which we're currently handling should
-* be disabled _nosync() to avoid deadlocks waiting
-* for this handler to complete. All others should
-* be disabled the regular way for SMP safety.
-*/
- if (gpio_irq == irq)
- disable_irq_nosync(gpio_irq);
- else
- disable_irq(gpio_irq);
- }
+ omap_writel(omap_readl(OMAP4_KBDOCP_BASE + OMAP4_KBD_IRQSTATUS),
+ OMAP4_KBDOCP_BASE + OMAP4_KBD_IRQSTATUS);
} else
/* disable keyboard interrupt and schedule for handling */
omap_writew(1, OMAP_MPUIO_BASE + OMAP_MPUIO_KBD_MASKIT);
@@ -132,14 +123,13 @@ static void omap_kp_scan_keypad(struct o
{
int col = 0;
+ u32 *p = (u32 *) state;
/* read the keypad status */
- if (cpu_is_omap24xx()) {
- /* read the keypad status */
- for (col = 0; col omap_kp-cols; col++) {
-
[PATCH 0/3] *** SUBJECT HERE ***
From: Moiz Sonasath m-sonas...@ti.com i2c-omap: I2C clean-up patch This patch includes the following fixes: -Fix I2C status ACK -ACK pending [R/X]DR and [R/X]RDY interrupts in the error/completeion path -Enable workaround for Errata 1.153 based on I2C IP block Signed-off-by: Moiz Sonasath m-sonas...@ti.com Signed-off-by: Vikram Pandita vikram.pand...@ti.com Moiz Sonasath (3): i2c-omap: Fix I2C status ACK i2c-omap: ACK pending [R/X]DR and [R/X]RDY interrupts in the error/completeion path i2c-omap: Enable workaround for Errata 1.153 based on I2C IP block drivers/i2c/busses/i2c-omap.c | 14 -- 1 files changed, 12 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] *** SUBJECT HERE ***
i2c-omap: I2C clean-up patch This patch includes the following fixes: -Fix I2C status ACK -ACK pending [R/X]DR and [R/X]RDY interrupts in the error/completeion path -Enable workaround for Errata 1.153 based on I2C IP block Signed-off-by: Moiz Sonasath m-sonas...@ti.com Signed-off-by: Vikram Pandita vikram.pand...@ti.com Moiz Sonasath (3): i2c-omap: Fix I2C status ACK i2c-omap: ACK pending [R/X]DR and [R/X]RDY interrupts in the error/completeion path i2c-omap: Enable workaround for Errata 1.153 based on I2C IP block drivers/i2c/busses/i2c-omap.c | 14 -- 1 files changed, 12 insertions(+), 2 deletions(-) -- 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
[no subject]
On 7/30/09, Felipe Balbi felipe.ba...@nokia.com wrote: On Thu, Jul 30, 2009 at 01:30:44PM +0200, ext Tar Gz wrote: hello everybody i'm student from indonesia..i'm sorry if my english too bad i want omap 3430 device drivers can running in the linux, where i can download any driver for omap 3430?.. which driver ? For which device ? google a little bit about how to use git and you can download current linux omap with: git clone git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git -- balbi all device driver omap 3430 like usb driver,camera driver, etc..where i can download that? -- 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
[no subject]
All, The DSS2 code base seems to inadvertently prevent downscaling of video overlay frames. Attached is my attempt at a patch to resolve this issue. As I gather from the code, there is an attempt to limit the overlay output frame size (x, y, outw, outh) to the managers updated window (mc-x, mc-y, mc-w, mc-h). The problem is that the input frame size (w h) is being used to instead of the output frame size (outw, outh). Due to this, when the input frame size is large than the output frame size, the input frame is being cropped, thus no downscaling occurs. My patch corrects this issue and also attempts to properly scale the input frame size if indeed the output frame is cropped. In my particular case, the output frame size is never cropped, so I have not explicitly tested these equations, but I believe they are mathematically correct. With this patch overlay downscaling is functional. Steve. 0001-Proper-Scaling-Fix.patch Description: 0001-Proper-Scaling-Fix.patch
[no subject]
subscribe -- 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
[no subject]
[EMAIL PROTECTED]
Bcc:
Subject: Re: [PATCH 0/3] lp5521
Reply-To: [EMAIL PROTECTED]
In-Reply-To: [EMAIL PROTECTED]
On Mon, Oct 06, 2008 at 12:11:28PM +0300, Felipe Balbi wrote:
A few cleanups and moving to drivers/leds. This driver
is probably ok for making its way to mainline, by the morning
I'll generate a patch against mainline and send to Richard
(led maintainer) for integration.
*** Note: compile tested only due to the fact n810 doesn't boot.
News here ??
Felipe Balbi (3):
i2c: lp5521: remove dead code
i2c: lp5521: cosmetic fixes
lp5521: move to drivers/leds
drivers/i2c/chips/Kconfig |7 -
drivers/i2c/chips/Makefile |1 -
drivers/leds/Kconfig |7 +
drivers/leds/Makefile |1 +
drivers/{i2c/chips/lp5521.c = leds/leds-lp5521.c} | 181
5 files changed, 81 insertions(+), 116 deletions(-)
rename drivers/{i2c/chips/lp5521.c = leds/leds-lp5521.c} (79%)
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] *** SUBJECT HERE ***
*** BLURB HERE *** Peter 'p2' De Schrijver (1): Fix build for beagleboard drivers/i2c/chips/twl4030-power.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
Hi All Does any one has the ramdisk_ks.gz file ? I checked for the site : http://www.wearablegroup.org/software/ramdisk But I am not able to fine this site now? ( looks like the site validity is expired ) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
