+- regulator-fixed-gpio: gpio to use for enable control
+- regulator-fixed-startup-delay: startup time in microseconds
startup-delay-ms ?
ok.
+- regulator-fixed-enable-high: Polarity of enable GPIO,
+ 1 = Active High, 0 = Active low
Some gpio specifiers allow you to specify active hig
On Saturday 05 November 2011 03:46 AM, Olof Johansson wrote:
Yeah, ok, but it shouldn't be part of the description of regulator
>> properties per se. See how gpio does it, defining how a gpio-specifier
>> is crafted. The equivalent should be done for regulators.
>
> That seems to be pretty mu
On Saturday 05 November 2011 02:52 AM, Olof Johansson wrote:
> > Also, lower-caps is common instead of V and A.
>
> On the other hand the case is pretty important for SI units
Yeah, true. The fixed regulators used microvolt instead, which could be a good
way to do it.
Ok, will use microvo
Hi Olof,
On Saturday 05 November 2011 01:59 AM, Olof Johansson wrote:
+- regulator-min-uV: smallest voltage consumers may set
> +- regulator-max-uV: largest voltage consumers may set
> +- regulator-uV-offset: Offset applied to voltages to compensate for voltage
drops
> +- regulator-min-uA: s
On Saturday 05 November 2011 01:34 AM, Olof Johansson wrote:
On Fri, Nov 04, 2011 at 05:20:39PM +0530, Rajendra Nayak wrote:
Define dt bindings for the ti-omap-hsmmc, and adapt
the driver to extract data (which was earlier passed as
platform_data) from device tree node.
Signed-off-by: Rajendra
On Saturday 05 November 2011 02:55 AM, Cousson, Benoit wrote:
+Required properties:
+- compatible: Should be "ti,omap-hsmmc", "ti,omap2-hsmmc";
+n is controller instance starting 0, for OMAP2/3 controllers
No, no, no. You should not have to specify the unit-address in the
compatible
field. They
Hi,
On Sat, Nov 05, 2011 at 05:19:54PM +0100, Michael Büsch wrote:
> tahvo_write_reg() needs to take the mutex to avoid a race
> condition with tahvo_set_clear_reg_bits:
>
> tahvo_set_clear_reg_bits(): | tahvo_write_reg():
> __tahvo_read_reg()|
> |
On 11/06/2011 01:18 PM, Russell King - ARM Linux wrote:
> Yet again I find that I'm having to email about crap on OMAP3.
>
> I'm getting really fed up with OMAP stuff which keeps breaking in
> idiotic ways - and the way there's fatal build errors at EVERY merge
> window. The OMAP workflow is tota
USB hub is not functional until is reset.
Reset the USB hub on SB-T35.
Signed-off-by: Igor Grinberg
---
v2: - Rebase on top of fixes branch
- Elaborate on the problem in the commit message
arch/arm/mach-omap2/board-cm-t35.c | 22 --
1 files changed, 20 insertio
TWL4030 audio codec is not being registered if no platform data is
supplied. Provide platform data for the TWL4030 audio codec.
Signed-off-by: Igor Grinberg
---
v2: - Rebase on top of fixes branch
- fix the commit message (10x to Sergei)
arch/arm/mach-omap2/board-cm-t35.c |3 ++-
1 file
cm-t35 DSS suplies are connected to VIO.
In fact, TPS65930 does not have VPLL2.
Signed-off-by: Igor Grinberg
---
v2: - Rebase on top of fixes branch
arch/arm/mach-omap2/board-cm-t35.c | 13 +++--
1 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/b
ads7846 driver fails to find the regulator supply and
as a result the touchscreen is not working.
Fix this by adding a regulator supply for the ads7846 driver.
Signed-off-by: Igor Grinberg
---
v2: - Rebase on top of fixes branch
- Elaborate on the problem in the commit message
arch/
This patch series fixes several issues on boards in subj.
It is based on Tony's fixes branch.
v2: - Rebase on top of fixes branch
- Elaborate more in the commit messages
Igor Grinberg (4):
ARM: OMAP3: cm-t35: fix ads7846 touchscreen
ARM: OMAP3: cm-t35: fix DSS regulator supply
A
Here's a list of my peaves about current platform code - which are
causing me great issue when trying to clean up the arch_reset() stuff:
1. Lack of trailing ',' on structure initializers
This makes it much harder to add additional initializers at the end
of existing initializers, and increa
Hi Tony,
On 11/05/11 01:57, Tony Lindgren wrote:
> * Tony Lindgren [04 16:05]:
>> * Igor Grinberg [111019 02:05]:
>>
>> Applying to board branch for v3.3 merge window.
>
> Hmm, actually I suggest you respin patches 2 and 3 so they apply
> on their own to current fixes branch. Then update 1
On Sun, Nov 6, 2011 at 5:48 PM, Russell King - ARM Linux
wrote:
> Yet again I find that I'm having to email about crap on OMAP3.
>
> I'm getting really fed up with OMAP stuff which keeps breaking in
> idiotic ways - and the way there's fatal build errors at EVERY merge
> window. The OMAP workflow
Yet again I find that I'm having to email about crap on OMAP3.
I'm getting really fed up with OMAP stuff which keeps breaking in
idiotic ways - and the way there's fatal build errors at EVERY merge
window. The OMAP workflow is totally broken. Something MUST change
in the way the OMAP community w
Hi Tony,
This one is stand alone and can be applied to fixes.
I will re spin the rest in a couple of hours.
Thanks
On 10/19/11 18:46, Igor Grinberg wrote:
> OMAP pin mux configuration API has been used incorrectly resulting
> in wrong mux mode set for several DSS pins.
>
> Signed-off-by: Igor G
18 matches
Mail list logo