On Fri, Dec 04, 2015 at 12:26:58PM -, Simon Arlott wrote:
> On Fri, December 4, 2015 11:00, Mark Brown wrote:
> > OK, so the power domains should be being represented and managed as such
> > rather than using regulators - it's a better fit (doing things like
> > support atomic context) and it
On Thu, Dec 03, 2015 at 11:51:16PM +, Simon Arlott wrote:
> On 03/12/15 23:45, Mark Brown wrote:
> > Are you *sure* these are regulators and not power domains? These names
> > look a lot like they could be power domains.
> No, I'm not sure. Some of them are may actually be regulators (the
On Fri, December 4, 2015 11:00, Mark Brown wrote:
> On Thu, Dec 03, 2015 at 11:51:16PM +, Simon Arlott wrote:
>> On 03/12/15 23:45, Mark Brown wrote:
>
>> > Are you *sure* these are regulators and not power domains? These names
>> > look a lot like they could be power domains.
>
>> No, I'm
On 03/12/15 00:06, Mark Brown wrote:
> On Wed, Dec 02, 2015 at 08:26:36PM +, Simon Arlott wrote:
>> On 02/12/15 12:53, Mark Brown wrote:
>
>> > This is the sort of thing you can pick up from the SoC compatible
>> > strings. As things stand there is zero content in this driver that
>> >
On Thu, Dec 03, 2015 at 08:14:33AM +, Simon Arlott wrote:
> On 03/12/15 00:06, Mark Brown wrote:
> > this it should know at least something about how to control the device
> > from the compatible string. If you're making a generic driver it should
> > not make reference to specific devices.
On Thu, Dec 03, 2015 at 11:38:28PM +, Simon Arlott wrote:
> #define MISC_IDDQ_CTRL_GMAC (1<<18)
> #define MISC_IDDQ_CTRL_WLAN_PADS(1<<13)
> #define MISC_IDDQ_CTRL_PCIE (1<<12)
> #define MISC_IDDQ_CTRL_FAP (1<<11)
> #define MISC_IDDQ_CTRL_VDSL_MIPS(1<<10)
>
On 03/12/15 23:45, Mark Brown wrote:
> On Thu, Dec 03, 2015 at 11:38:28PM +, Simon Arlott wrote:
>
>> #define MISC_IDDQ_CTRL_GMAC (1<<18)
>> #define MISC_IDDQ_CTRL_WLAN_PADS(1<<13)
>> #define MISC_IDDQ_CTRL_PCIE (1<<12)
>> #define MISC_IDDQ_CTRL_FAP (1<<11)
>>
On 03/12/15 15:05, Mark Brown wrote:
> On Thu, Dec 03, 2015 at 08:14:33AM +, Simon Arlott wrote:
>> On 03/12/15 00:06, Mark Brown wrote:
>
>> > this it should know at least something about how to control the device
>> > from the compatible string. If you're making a generic driver it should
On 02/12/15 12:53, Mark Brown wrote:
> On Wed, Dec 02, 2015 at 12:45:50PM -, Simon Arlott wrote:
>> On Tue, December 1, 2015 22:16, Mark Brown wrote:
>
>> > Why are these in the DT, I would expect that if this is a driver for a
>> > specific SoC all these properties would be known as a result
On Wed, Dec 02, 2015 at 08:26:36PM +, Simon Arlott wrote:
> On 02/12/15 12:53, Mark Brown wrote:
> > This is the sort of thing you can pick up from the SoC compatible
> > strings. As things stand there is zero content in this driver that
> > relates to this SoC.
> There's always going to be
On Tue, December 1, 2015 22:16, Mark Brown wrote:
> On Mon, Nov 30, 2015 at 08:30:07PM +, Simon Arlott wrote:
>
>> +- offset: register offset
>> +- mask: register enable mask
>> +- startup-delay-us: startup time in microseconds
>
> Why are these in the DT, I would expect that if this is a
On Wed, Dec 02, 2015 at 12:45:50PM -, Simon Arlott wrote:
> On Tue, December 1, 2015 22:16, Mark Brown wrote:
> > Why are these in the DT, I would expect that if this is a driver for a
> > specific SoC all these properties would be known as a result of that.
> This is a driver for multiple
On Mon, Nov 30, 2015 at 08:30:07PM +, Simon Arlott wrote:
> +- offset: register offset
> +- mask: register enable mask
> +- startup-delay-us: startup time in microseconds
Why are these in the DT, I would expect that if this is a driver for a
specific SoC all these properties would be known
The BCM63xx has one or more registers with bits that act as regulators
to enable/disable power to individual chip peripherals.
Signed-off-by: Simon Arlott
---
.../bindings/regulator/brcm,bcm63xx-regulator.txt | 33 ++
1 file changed, 33 insertions(+)
14 matches
Mail list logo