Re: [beagleboard] [PATCH] Second RFC version of mt9p031 sensor with power managament.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Javier,

On Friday 27 May 2011 17:36:24 javier Martin wrote:
> On 27 May 2011 16:31, Laurent Pinchart wrote:
> > On Thursday 26 May 2011 13:31:37 javier Martin wrote:
> >> OK, I think I've found the problem with the power management.
> >> 
> >> As it is stated in mt9p031 datasheet [3] p 59, a sequence involving
> >> [VAA,VAA_PIX,VDD_PLL], [VDD,VDD_IO], [Reset] and [Ext Clk] must be
> >> followed in order to properly power up or down the sensor.
> >> 
> >> If we take a look to the LI-5M031 schematic[1] and Beagleboard xM
> >> schematic [2] we'll notice that voltages are connected as follows:
> >> 
> >> [VDD] (1,8V) <--- V2.8 <--- CAM_CORE <--- VAUX3 TPS65950
> >> [VDD_IO (VDDQ)] (1,8V) <--- V1.8 <--- CAM_IO <--- VAUX4 TPS65950
> >> [VAA, VAA_PIX, VDD_PLL] (2,8V) <---| U6 |<-- V3.3VD <-- HUB_3V3 <--|
> >> U16 | enabled by USBHOST_PWR_EN <-- LEDA TPS65950
> >> 
> >> VAUX3 (VDD) and VAUX4 (VDD_IO) are fine, they are only used for
> >> powering our camera sensor. However, when it comes to the analog part
> >> (VAA, VAA_PIX...), it is got from HUB_3V3 which is also used for
> >> powering USB and ethernet.
> > 
> > *sigh* Why do hardware designers do things like that, really ?
> > 
> >> If we really want to activate/deactivate regulators that power mt9p031
> >> we need to follow [3] p59. However, for that purpose we need to ensure
> >> that a call to regulator_enable() or regulator_disable() will really
> >> power on/off that supply, otherwise the sequence won't be matched and
> >> the chip will have problems.
> >> 
> >> Beagleboard xM is a good example of platform where this happens since
> >> HUB_3V3 and thus (VAA, VAA_PIX, etc...) cannot be deactivated since it
> >> is being used by other devices. But there could be others.
> >> 
> >> So, as a conclusion, and in order to unblock my work, my purpose for
> >> power management in mt9p031 would be the following:
> >> - Drop regulator handling as we cannot guarantee that power on
> >> sequence will be accomplished.
> >> - Keep on asserting/de-asserting reset which saves a lot of power.
> >> - Also activate/deactivate clock when necessary to save some power.
> >> 
> >> I'm looking forward to read your comments on this.
> > 
> > Even if you keep the sensor powered all the time, how do you ensure that
> > VAUX3 is available before HUB_3V3 when the system is powered up ?
> 
> You can't. And in fact what happens its the opposite. But it works.

I wonder why, as the power supplies are sequenced the wrong way. It seems like 
the hardware has been designed not to work. Sometimes I wish hardware 
designers would read the chip specs before shipping boards in the wild and 
relying on us to fix their mistakes.

> On the other hand, not being able to disable/enable HUB_3V3 can make,
> as a hardware guy has told me, power on reset internal circuit not to
> work [1] and thus the power down / power up fails.
> 
> [1] http://en.wikipedia.org/wiki/Power-on_reset

-- 
Regards,

Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux