From: Hemanth V
Date: Fri, 26 Aug 2011 10:49:29 +0530
Subject: [PATCH] Add PWM1 and PWM2 support to twl6030-pwm driver
This patch adds support for PWM1/PWM2. TWL6030 PWM driver also
supports Indicator LED PWM. Function pointers are defined for
for init, enable, disable and configuration for both
On Tue, Aug 30, 2011 at 2:17 AM, Kevin Hilman wrote:
> Kevin Hilman writes:
>
>> Keshava Munegowda writes:
>>
>>> From: Keshava Munegowda
>>>
>>> The usbhs core driver does not enable/disable the intefrace and
>>> fucntional clocks; These clocks are handled by hwmod and runtime pm,
>>> hence in
Hi, folks
I tried to enable musb on beagleboard-xM. But it always failed with
"insufficient available bus power".
I am using linux-3.0 from linus git tree.
Do i need to use a hub? But i heard that musb doesn't support hub.
Thanks.
# dmesg | grep 'musb'
musb-hdrc: version 6.0, pio, host
omap_d
On Fri, Aug 26, 2011 at 04:13:15PM +0200, Cousson, Benoit wrote:
> On 8/26/2011 12:58 PM, Arnd Bergmann wrote:
> >On Friday 26 August 2011, David Gibson wrote:
> >>Seriously, how many times do I have to say it?
>
> [...]
>
> >>Insisting that the names come from the DT is to mistakenly think of
>
Hemant Pedanekar writes:
> This patch adds minimum required hwmod data (e.g., UARTs) for bootup of TI81XX
> devices (currently common data for TI816X and TI814X is added).
>
> Signed-off-by: Hemant Pedanekar
I haven't looked at the details yet, but just tried to boot this using
current mainline
Hemant Pedanekar writes:
> This patch adds minimal support and build configuration for TI8148 EVM. Also
> adds support for low level debugging on UART1 console on the EVM.
>
> Signed-off-by: Hemant Pedanekar
[...]
> +static void __init ti8148_init_early(void)
> +{
> + omap2_init_common_inf
On Sat, Aug 27, 2011 at 03:47:55PM -0600, Paul Walmsley wrote:
> Certainly, from a kernel development perspective, one can decide to just
> dump this kind of DT generation problem back on the hardware vendors.
> But it seems more efficient and less error-prone to simply remove both
> mapping t
+Benoit
Keerthy writes:
> OMAP4460 specific temperature sensor register bit fields are added.
...and existing OMAP4 entries are renamed to OMAP4430.
Please be sure to describe thoroughly *all* the changes that are being
done in the changelog.
> Signed-off-by: Keerthy
> Cc: t...@atomide.com
Keerthy writes:
> div_ts_ck feeds only the temperature sensor functional clock
> and also has a clksel associated (for divider selection). Mapping this
> as the functional clock for the temperature sensor in clkdev table,
> so a clk_set_rate() in the driver would have the effect of changing the
>
Hi Johan,
Johan Hovold writes:
> Clean up error messages by adding missing whitespace, reducing excessive
> verbosity, and fixing a few language issues.
>
> Signed-off-by: Johan Hovold
I've got a major voltage layer cleanup series in progess (and just
posted a few series.) Would you care to r
Hi Johan,
Johan Hovold writes:
> Fix typos in comment and error message.
>
> Signed-off-by: Johan Hovold
Thanks for these PM-related cleanups. They're much appreciated.
Patches 1 & 2 look fine. However, can you please repost with the
linux-arm-kernel mailing list in Cc?All patches for u
Kevin Hilman writes:
> Keshava Munegowda writes:
>
>> From: Keshava Munegowda
>>
>> The usbhs core driver does not enable/disable the intefrace and
>> fucntional clocks; These clocks are handled by hwmod and runtime pm,
>> hence insted of the clock enable/disable, the runtime pm APIS are
>> use
One thing I forgot to mention: For my tests, I did modify the original
cyclictest to check for return codes for the APIs (and errno's on
failure and print them at the end) and both clock_gettime and
clock_nanosleep returned 0 (success), when the actual failure
happened. So, the APIs did not fail an
From: Laurent Pinchart
omap_iovmm requires page-aligned buffers, and that sometimes causes
omap3isp failures (i.e. whenever the buffer passed from userspace is not
page-aligned).
Remove this limitation by rounding the address of the first page entry
down, and adding the offset back to the device
On Mon, Aug 29, 2011 at 12:41 PM, Luciano Coelho wrote:
> From: Randy Dunlap
>
> Combine MFD_SUPPORT (which only enabled the remainder of the MFD
> menu) and MFD_CORE. This allows other drivers to select MFD_CORE
> without needing to also select MFD_SUPPORT, which fixes some
> kconfig unmet depe
Keshava Munegowda writes:
> From: Keshava Munegowda
>
> The usbhs core driver does not enable/disable the intefrace and
> fucntional clocks; These clocks are handled by hwmod and runtime pm,
> hence insted of the clock enable/disable, the runtime pm APIS are
> used. however,the port clocks are h
From: Randy Dunlap
Combine MFD_SUPPORT (which only enabled the remainder of the MFD
menu) and MFD_CORE. This allows other drivers to select MFD_CORE
without needing to also select MFD_SUPPORT, which fixes some
kconfig unmet dependency warnings. Modeled after I2C kconfig.
[Forward-ported to 3.1
Todd Poynor writes:
> On Fri, Aug 12, 2011 at 12:20:21PM +0530, Munegowda, Keshava wrote:
>> On Wed, Aug 10, 2011 at 10:01 PM, Todd Poynor wrote:
>> >> @@ -913,12 +598,15 @@ static int usbhs_enable(struct device *dev)
>> >> (pdata->ehci_data->reset_gpio_port[1], 1);
Russell King - ARM Linux writes:
> Consolidate 24 trivial gpiolib implementions out of mach/gpio.h
> into asm/gpio.h. This is basically the include of asm-generic/gpio.h
> and the definition of gpio_get_value, gpio_set_value, and gpio_cansleep
> as described in Documentation/gpio.txt
>
> Signed-
Russell King - ARM Linux writes:
> Signed-off-by: Russell King
Acked-by: Kevin Hilman
--
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
From: Patrick Titiano
omap_twl_vsel_to_uv() and omap_twl_uv_to_vsel() functions used to convert
voltages to TWL6030 SMPS commands (a.k.a "vsel") implement incorrect conversion
formula.
It uses legacy OMAP3 formula, but OMAP4 Power IC has different offset and
voltage step:
- Voltage Step is now 1
From: Nishanth Menon
Without the command register, ON/ONLP/RET/OFF voltages are
useless. and TWL will be unable to use these
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/omap_twl.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_t
From: Patrick Titiano
According to latest OMAP4430 Data Manual v0.4 dated March 2011:
- Retention voltage shall be set to 0.83V. See tables 2.2, 2.4 and 2.6 in DM.
This allows saving a little more power in retention states.
- OPP100 IVA nominal voltage is 1.188V. See table 2.4 in DM.
This
From: Nishanth Menon
0V conversions should be mapped to 0 as it is meant to denote
off voltages.
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/omap_twl.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/oma
This series focuses on cleanups and fixes in support of the TWL6030 PMIC.
Available in the pm-wip/voltdm_e branch of my linux-omap-pm tree
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
Applies on v3.1-rc3 + the part A, B, C & D series.
Kevin
Nishanth Menon (3):
OMA
From: Nishanth Menon
using 1.35V as a check is not correct, we know that beyond 0x39,
voltages are non linear - hence use the conversion iff uV greater
than that for 0x39. For example, with 709mV as the smps offset,
the max linear is actually 1.41V(0x39vsel)!
Signed-off-by: Nishanth Menon
---
Hello everyone,
Greetings. I have tried the following kernels and found "the problem"
to occur on all of them with high resolution timer enabled
(1) mainline stable 3.0.1 kernel but with Hemant Pedanekar's patch
(http://www.spinics.net/lists/linux-omap/msg50742.html) and by
disabling 32KHz Timer
This series focuses on cleanup of the remaining voltage domain layer
(non-VC/VP code)
Available in the pm-wip/voltdm_d branch of my linux-omap-pm tree
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
Applies on v3.1-rc3 + the part A, B & C series.
Kevin
Kevin Hilman (6)
Track current nominal voltage as part of struct voltagedomain instead
of omap_vdd_info, which will soon be removed.
Also renames field from curr_volt to nominal_volt.
No functional changes.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/vc.c |5 ++---
arch/arm/mach-omap2/voltage.
From: Tero Kristo
Needed as some of the voltage layer functionality is accessed from the
SMPS regulator driver.
Signed-off-by: Tero Kristo
Signed-off-by: Kevin Hilman
---
arch/arm/plat-omap/include/plat/voltage.h | 20
1 files changed, 20 insertions(+), 0 deletions(-)
Starting with OMAP5, the following registers are per-channel and not
common to a all VC channels:
- SMPS I2C slave address
- SMPS voltage register address offset
- SMPS cmd/value register address offset
- VC channel configuration register
Move these from the channel-common struct into the per
Use preferred voltdm_ naming for getting current nominal voltage.
No functional changes.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/smartreflex-class3.c |2 +-
arch/arm/mach-omap2/voltage.c| 14 --
arch/arm/mach-omap2/voltage.h|2 +-
3 file
Currently, the nominal voltage is updated in the VC post-scale function
which is common to both scaling methods. However, this has readabiliy
problems as this update is not where it might be expected. Instead, move
the updated into voltdm_scale() upon a successful return of voltdm->scale()
Signe
Remove last remaining member (volt_data) from omap_vdd_info into
struct voltagedomain and removal remaining usage and reference to
omap_vdd_info.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/voltage.c | 54
arch/arm/mach-omap2/voltage.h
Rename voltage scaling related functions to use voltdm_ prefix intead
of omap_voltage_, and cleanup kerneldoc comments in the process.
s/omap_voltage_scale_vdd/voltdm_scale/
s/omap_voltage_reset/voltdm_reset/
Also, in voltdm_reset() s/target_uvdc/target_volt/ to be consistent with
naming througho
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/vp.c | 34 --
arch/arm/mach-omap2/vp.h |1 -
2 files changed, 0 insertions(+), 35 deletions(-)
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index 29698ac..24020ea 100644
--- a/arch/arm/m
combine VPCONFIG init voltage setup into common function and use from
both vp_enable and from vp_forceupdate_scale().
NOTE: this patch changes the sequence of when the initVDD bit is
cleared. The bit is now cleared immediately after it was written.
Since only the rising edge of this bit has any a
Add check for valid VP in omap_vp_update_errorgain()
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/vp.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index 3807620..29698ac 100644
--- a/arch/arm/mach-omap2/vp.
Function pointer used for actual voltage scaling (e.g. VP force update
or VC bypass) is moved from omap_vdd_info into struct voltagedomain,
resulting in renames s/vdd->volt_scale/voltdm->scale/
No functional changes.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/voltage.c | 24 +++--
From: Todd Poynor
Reading the VPVOLTAGE field of PRM_VP_*_VOLTAGE registers currently
relies on a u32 -> u8 conversion to mask off the FORCEUPDATEWAIT field
in the upper bits. Make this explicit using the mask symbol
already defined, added as a new field in struct omap_vp_common.
Signed-off-by:
Remove the "runtime" VP data in favor of direct programming of VP registers.
The VP is in the PRM, which is in the wakeup powerdomain, so there is no
need to keep the state dynamically.
Fixes to original version from Nishanth Menon
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/voltage.h
Create new helper function in VP layer for updating VP error gain.
Currently used during pre-scale for VP force update and VC bypass.
TODO: determine if this can be removed from the pre-scale path and
moved to VP enable path.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/vc.c | 19 ++---
Move VP timing calcluation (based on sys clock) and register programming
into VP init.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/voltage.c | 22 --
arch/arm/mach-omap2/vp.c | 23 ++-
2 files changed, 22 insertions(+), 23 deletions(-)
di
Add sys clock name and rate to struct voltage domain. SoC specific
voltagedomain init code initializes sys clock name. After clock
framework is initialized, voltage late init will then use use the
sys_clk rate to calculate the various timing that depend on that rate.
Signed-off-by: Kevin Hilman
In struct omap_vp_common, the shift value can be derived from the mask
value by using __ffs(), so remove the shift value for the various
VPCONFIG bitfields, and use __ffs() in the code for the shift value.
While here, rename field names in kerneldoc comment to match actual
field names in structure
Remove read-only debugfs interface to VP values. Most of the values
are init-time only and never change. Current voltage value should be
retreived from the (eventual) regulator framework interface to the
voltage domain.
Fixes to original version provided by Nishanth Menon
Signed-off-by: Kevin
- move VP instance struct from vdd_info into struct voltage domain
- remove _data suffix from structure name
- rename vp_ prefix from vp_common field: accesses are now vp->common
- move vp_enabled bool from vdd_info into VP instance
- remove remaining references to omap_vdd_info
No functional chan
This series focuses on cleanup and better abstraction in the voltage
processor (VP) layer.
Available in the pm-wip/voltdm_c branch of my linux-omap-pm tree
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
Applies on v3.1-rc3 + the part A & B series.
Kevin
Kevin Hilman (1
- support both voltage register address and command register address
for each VC channel
- add fields for voltage register address (volra) and command register
address (cmdra) to struct omap_vc_channel
- use VC/VP register access read/modify/write helper
- remove volra_shift field (use __ffs(ma
- Add an i2c_slave_address field to the omap_vc_channel
- use VC/VP read/modify/write helper instead of open-coding
- remove smps_sa_shift, use __ffs(mask) for shift value
- I2C addresses 10-bit, change size to u16
Special thanks to Shweta Gulati for suggesting
the use of __ffs(x) instead of ffs(
This series focuses on cleanup and better abstraction in the voltage
controller (VC) layer.
Available in the pm-wip/voltdm_b branch of my linux-omap-pm tree
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
Applies on v3.1-rc3 + the part A series (pm-wip/voltdm_a branch)
Ke
Create basic voltagedomains for OMAP2 and associate OMAP2 powerdomains
with the newly created voltage domains.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/Makefile |3 +-
arch/arm/mach-omap2/io.c |2 +
arch/arm/mach-omap2/powerdomains2xxx_dat
Add voltage domain name to indicate which voltagedomain each
powerdomain is in.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c |2 ++
arch/arm/mach-omap2/powerdomains3xxx_data.c | 16
2 files changed, 18 insertions(+), 0 deletions(-)
Convert VC/VP register access to use PRM VC/VP accessor functions. In
the process, move the read/write function pointers from vdd_info into
struct voltagedomain.
No functional changes.
Additional cleanup:
- remove prm_mod field from VC/VP data structures, the PRM register
access functions kno
On OMAP3+, the voltage controller (VC) and voltage processor (VP) are
inside the PRM. Add some PRM helper functions for register access to
these module registers.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/prm2xxx_3xxx.c | 15 +++
arch/arm/mach-omap2/prm2xxx_3xxx.h |8
Each powerdomain is associated with a voltage domain. Add an entry to
struct powerdomain where the enclosing voltagedomain can be
referenced.
Modeled after similar relationship between clockdomains and powerdomains.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/powerdomain.h |7 +
Add a 'bool scalable' flag to the struct powerdomain and set it for
the scalable domains on OMAP3 and OMAP4.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/voltage.c |3 +++
arch/arm/mach-omap2/voltage.h |2 ++
arch/arm/mach-omap2/voltagedomains3xxx_d
The VC layer can support PMICs with separate voltage and command
registers by putting the different registers in the PRM_VC_SMPS_VOL_RA
and PRCM_VC_SMPS_CMD_RA registers respectively.
The PMIC data must supply at least a voltage register address
(volt_reg_addr). The command register address (cmd_
Replace the VP tranxdone check/clear with helper functions from the
PRM layer.
In the process, remove prm_irqst_* voltage structure fields for IRQ
status checking which are no longer needed.
Since these reads/writes of the IRQ status bits were the only PRM
accesses that were not to VC/VP register
Add SoC specific PRM VP helper functions for checking and clearing
the VP transaction done status.
Longer term, these events should be handled by the forthcoming PRCM
interrupt handler.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/prm2xxx_3xxx.c | 41 ++
arc
This patch is primarily a move of VP specific code from voltage.c into
its own code in vp.c and adds prototypes to vp.h
No functional changes, except debugfs...
VP debugfs moved to 'vp' subdir of /voltage/ and 'vp_'
prefixes removed from all debugfs filenames.
Signed-off-by: Kevin Hilman
---
a
VC is initialized first, set default scaling method to VC bypass.
If/when VP is initialized, default scaling method will be changed to
VP force-update.
Enabling VC bypass as default as soon as VC is initialized allows for
VC bypass scaling to work when no VP is configured/initialized for a
given v
Move the VC instance struct from omap_vdd_info into struct voltagedomain.
While moving, perform some misc. renames for readability.
No functional changes.
Summary of renames:
- rename omap_vc_instance to omap_vc_channel, since there is only
one instance of the VC IP and this actually represents
As part of the voltage layer cleanup, split out VC specific code into
a dedicated VC layer. This patch primarily just moves VC code from
voltage.c into vc.c, and adds prototypes to vc.h.
No functional changes.
For readability, each function was given a local 'vc' pointer:
struct omap_vc_ins
When a powerdomain is registered, lookup the voltage domain by name
and keep a pointer to the containing voltagedomain in the powerdomain
structure.
Modeled after similar method between powerdomain and clockdomain layers.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/powerdomain.c | 21
When a powerdomain is registered and it has an associated voltage domain,
add the powerdomain to the voltagedomain using voltdm_add_pwrdm().
Also add voltagedomain iterator helper functions to iterate over all
registered voltagedomains and all powerdomains associated with a
voltagedomain.
Modeled
This voltage domain (a.k.a. VDD1) contains both the MPU and the IVA, so
rename appropriately.
Also fixup any users of the "mpu" name to use "mpu_iva"
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c|4 ++--
arch/arm/mach-omap2/omap_twl.c|2 +
Add wakeup voltage domain so that the wakeup powerdomain can have an
associated powerdomain. Note that the scalable flat is not set for
the this voltagedomain, so it will not be fully initialized like
scalable voltage domains.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/voltagedomains3x
From: Benoit Cousson
Add voltage domain name to indicate which voltagedomain each
powerdomain is in.
The fixed voltage domain like ldo_wakeup for emu and wkup power
domain is added too.
Update the TI copyright date to 2011.
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
[khil...@ti.com]: re
Start cleaning up the voltage layer to have a voltage domain layer
that resembles the structure of the existing clock and power domain
layers. To that end:
- move the 'struct voltagedomain' out of 'struct omap_vdd_info' to
become the primary data structure.
- convert any functions taking a poi
The prm_irqst_reg is not part of the VP. Move it up into the common
voltage domain struct.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/voltage.c | 15 +++
arch/arm/mach-omap2/voltage.h |1 +
arch/arm/mach-omap2/voltagedomains3xxx_data.c
Eliminate need for global variables for the various PRM module offsets by
making them part of the VP/VC common structures
Eventually, these will likely be moved again, or more likely removed
when VP/VC code is isolated, but for now just getting rid of them as
global variabes so that the voltage do
The voltage domain pointer currently in struct omap_hwmod is not used
and does not belong here. Instead, voltage domains will be associated
with powerdomains in forthcoming patches.
Acked-by: Paul Walmsley
Signed-off-by: Kevin Hilman
---
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 -
1
This is the first phase of the OMAP voltage layer cleanup. The
primary goal is to cleanup/reorganize data structures to facilitate
splitting apart the voltage processor (VP) and voltage controller (VC)
into separate layers.
Based on v3.1-rc3
Series available in branch pm-wip/voltdm_a in my linux
On Sunday 28 August 2011, David Gibson wrote:
> > Right, and I guess we can simply ignore DMA and ioport resources because
> > they
> > are extremely rare, right?
>
> Well, remember it's where resources can appear in the DT node that
> matters, not what the types are in the platform device. iopo
On Saturday 27 August 2011, Paul Walmsley wrote:
> On Sat, 27 Aug 2011, Arnd Bergmann wrote:
>
> > Right, and I guess we can simply ignore DMA and ioport resources because
> > they are extremely rare, right?
>
> DMA resources are quite widely used.
>
> For example, looking at the SoCs with some
This is the first phase of the OMAP voltage layer cleanup. The
primary goal is to cleanup/reorganize data structures to facilitate
splitting apart the voltage processor (VP) and voltage controller (VC)
into separate layers.
Benoit Cousson (1):
OMAP4: powerdomain data: add voltage domains
Kevin
On Mon, 29 Aug 2011, Ming Lei wrote:
> Suppose HC can see the old value in hw_token, which has the ACTIVE bit clear.
>
> The qtd transaction will not be executed until the new token is
> flushed into memory.
> From view of CPU, the irq is still be delayed because ioc irq is generated
> after the
On Mon, 2011-08-29 at 23:55 +0800, Ming Lei wrote:
> If writing to coherent memory can't reach physical memory immediately on
> other ARCHs, the problem can still happen on these ARCHs. But I am
> not sure if there are these kind of ARCHs except for ARM.
If there is write buffering which prevents
Vishwanath Sripathy writes:
[...]
>> >> diff --git a/arch/arm/mach-omap2/opp3xxx_data.c b/arch/arm/mach-
>> omap2/opp3xxx_data.c
>> >> index d95f3f9..b5d8294 100644
>> >> --- a/arch/arm/mach-omap2/opp3xxx_data.c
>> >> +++ b/arch/arm/mach-omap2/opp3xxx_data.c
>> >> @@ -26,6 +26,16 @@
>> >> #incl
Hi,
On Mon, Aug 29, 2011 at 9:57 PM, Alan Stern wrote:
> On Mon, 29 Aug 2011, Russell King - ARM Linux wrote:
>
>> > You know better than I do what is needed to resolve the ordering issue.
>> > However, contrary to what the original patch description said, this
>> > isn't entirely a matter of mak
Hi,
On Mon, Aug 29, 2011 at 11:03 PM, Alan Stern wrote:
> On Mon, 29 Aug 2011, Ming Lei wrote:
>
>> IMO, the dummy has been linked into queue pointed by qh->hw->hw_qtd_next,
>> so EHCI will fetch dummy qtd and execute the transaction and will not have
>> any delay on the transaction.
>>
>> Let me
On Mon, 29 Aug 2011, Ming Lei wrote:
> IMO, the dummy has been linked into queue pointed by qh->hw->hw_qtd_next,
> so EHCI will fetch dummy qtd and execute the transaction and will not have
> any delay on the transaction.
>
> Let me explain the problem again: On ARM, the wmb() before
> 'dummy->hw
Hi,
On Mon, Aug 29, 2011 at 1:00 AM, Alan Stern wrote:
> On Sun, 28 Aug 2011, Ming Lei wrote:
>
>> > I've been following this whole discussion. I didn't understand the
>> > idea behind the original patch, and I don't understand this. What
>> > reason is there for adding a memory barrier after t
On Mon, 29 Aug 2011, Russell King - ARM Linux wrote:
> > You know better than I do what is needed to resolve the ordering issue.
> > However, contrary to what the original patch description said, this
> > isn't entirely a matter of making the write visible to the host
> > controller: No doubt in
From: Afzal Mohammed
This patch updates the common machine specific source files for
support for AM335x with cpu type, macros for identification of
AM335X device.
Signed-off-by: Vaibhav Hiremath
Signed-off-by: Afzal Mohammed
---
arch/arm/mach-omap2/clock3xxx_data.c |3 +++
arch/arm/
From: Afzal Mohammed
This patch updates the common platform files with AM335X device
support.
The approach taken in this patch is,
AM33XX device will be considered as OMAP3 variant, and a separate
SoC class created for AM33XX family of devices with a subclass type
for AM335X device which is newl
From: Afzal Mohammed
Add support for low level debugging on AM335X EVM. Currently only
support for UART1 console, which is used on AM335X EVM is added.
Signed-off-by: Vaibhav Hiremath
Signed-off-by: Afzal Mohammed
---
arch/arm/mach-omap2/include/mach/debug-macro.S | 22 +
From: Afzal Mohammed
This patch adds minimal support and build configuration for
AM335X EVM.
Signed-off-by: Vaibhav Hiremath
Signed-off-by: Afzal Mohammed
---
arch/arm/mach-omap2/Kconfig |5 +++
arch/arm/mach-omap2/Makefile |2 +
arch/arm/mach-omap2/board-am335xevm.
From: Vaibhav Hiremath
This patch set adds support for AM335x device having
Cortex-A8 MPU.
AM335X is treated as another OMAP3 variant, where,
along with existing cpu class OMAP34XX, new cpu class AM33XX is created
and the respective type is AM335X, which is newly added device in the family.
This
[...]
> > void omap2_gpio_prepare_for_idle(int off_mode)
> > {
> > - int i, c = 0;
> > - int min = 0;
> > -
> > - if (cpu_is_omap34xx())
> > - min = 1;
> > + int c = 0;
> > + struct gpio_bank *bank;
> >
> > - for (i = min; i< gpio_bank_count; i++) {
> > - struct
Hi Govindraj,
With this commit added, it is booting up.Thanks for the info.
Thanks,
Deepthy Ravi.
From: Govindraj [govindraj...@gmail.com]
Sent: Monday, August 29, 2011 4:59 PM
To: Ravi, Deepthy
Cc: linux-omap@vger.kernel.org
Subject: Re: Booting hangs with
On Mon, Aug 29, 2011 at 4:18 PM, Ravi, Deepthy wrote:
> Hi,
> I tried booting OMAP3EVM with the updated linux-omap kernel .
> The last commit details on the kernel are :
> Author: Tony Lindgren
> commit b148d763841161894ed6629794064065a834aa2b
> Linux-omap rebuilt: Updated to use omap_sdrc_init
>
On Mon, Aug 29, 2011 at 4:18 PM, Ravi, Deepthy wrote:
> Hi,
> I tried booting OMAP3EVM with the updated linux-omap kernel .
> The last commit details on the kernel are :
> Author: Tony Lindgren
> commit b148d763841161894ed6629794064065a834aa2b
> Linux-omap rebuilt: Updated to use omap_sdrc_init
>
Hi,
I tried booting OMAP3EVM with the updated linux-omap kernel .
The last commit details on the kernel are :
Author: Tony Lindgren
commit b148d763841161894ed6629794064065a834aa2b
Linux-omap rebuilt: Updated to use omap_sdrc_init
It hangs at one point.
Following is the boot log,
Texas Instrume
Hi,
> > > we really need to find a better way to handle this :-(
> >
> > How about passing the mode info from musb_config (musb->config-
> >fifo_mode),
> > same way as musb->config->fifo_cfg
>
> not sure... Ideally we wouldn't really need those fifo tables,
Yes, if all the board files provide the
On Saturday 27 August 2011 04:41 AM, Kevin Hilman wrote:
Shubhrajyoti D writes:
- The reset in the driver at init is not needed anymore as the
hwmod framework takes care of reseting it.
- Reset is removed from omap_i2c_init, which was called
not only during probe, but also after time
On Saturday 27 August 2011 04:36 AM, Kevin Hilman wrote:
Shubhrajyoti D writes:
Under some error conditions the i2c driver may do a reset.
Adding a reset field and support in the device-specific code.
Signed-off-by: Shubhrajyoti D
Needs update/rebase to apply against my for_3.2/i2c-cleanup b
On Sun, Aug 28, 2011 at 09:51:10PM -0400, Alan Stern wrote:
> Hmmm. Although the semantics of the various mb() macros were
> originally defined only for inter-CPU synchronization, I believe they
> are also supposed to work for guaranteeing the order of accesses to
> DMA-coherent memory. If that's
Hi,
On Mon, Aug 29, 2011 at 11:01:54AM +0530, Gupta, Ajay Kumar wrote:
> > > diff --git a/drivers/usb/musb/musb_core.c
> > > b/drivers/usb/musb/musb_core.c index 20a2873..07f3faf 100644
> > > --- a/drivers/usb/musb/musb_core.c
> > > +++ b/drivers/usb/musb/musb_core.c
> > > @@ -1014,7 +1014,9 @@ st
1 - 100 of 103 matches
Mail list logo
