Re: [RFC 0/5] drivers: Add boot constraints core

2017-07-07 Thread Stephen Boyd
On 07/05, Rob Clark wrote: > On Thu, Jun 29, 2017 at 5:00 PM, Stephen Boyd wrote: > > On 06/29, Russell King - ARM Linux wrote: > >> > >> As far as the memory being used goes, they probably locate the frame > >> buffer well away from the kernel or any area that the kernel is

Re: [RFC 0/5] drivers: Add boot constraints core

2017-07-07 Thread Stephen Boyd
On 07/05, Rob Clark wrote: > On Thu, Jun 29, 2017 at 5:00 PM, Stephen Boyd wrote: > > On 06/29, Russell King - ARM Linux wrote: > >> > >> As far as the memory being used goes, they probably locate the frame > >> buffer well away from the kernel or any area that the kernel is likely > >> to use

Re: [RFC 0/5] drivers: Add boot constraints core

2017-07-05 Thread Rob Clark
On Thu, Jun 29, 2017 at 5:00 PM, Stephen Boyd wrote: > On 06/29, Russell King - ARM Linux wrote: >> On Thu, Jun 29, 2017 at 08:28:08PM +0530, Viresh Kumar wrote: >> > On 29-06-17, 13:49, Russell King - ARM Linux wrote: >> > > The thing that concerns me most about this is

Re: [RFC 0/5] drivers: Add boot constraints core

2017-07-05 Thread Rob Clark
On Thu, Jun 29, 2017 at 5:00 PM, Stephen Boyd wrote: > On 06/29, Russell King - ARM Linux wrote: >> On Thu, Jun 29, 2017 at 08:28:08PM +0530, Viresh Kumar wrote: >> > On 29-06-17, 13:49, Russell King - ARM Linux wrote: >> > > The thing that concerns me most about this is that typically the LCD >>

Re: [RFC 0/5] drivers: Add boot constraints core

2017-07-04 Thread Viresh Kumar
On 03-07-17, 16:07, Mark Brown wrote: > On Mon, Jul 03, 2017 at 11:45:52AM +0530, Viresh Kumar wrote: > > The above regulator-min/max-microvolt values I mentioned were for the > > regulator > > device and not what the consumers would request. Yes, DMA will request > > something > > If you're

Re: [RFC 0/5] drivers: Add boot constraints core

2017-07-04 Thread Viresh Kumar
On 03-07-17, 16:07, Mark Brown wrote: > On Mon, Jul 03, 2017 at 11:45:52AM +0530, Viresh Kumar wrote: > > The above regulator-min/max-microvolt values I mentioned were for the > > regulator > > device and not what the consumers would request. Yes, DMA will request > > something > > If you're

Re: [RFC 0/5] drivers: Add boot constraints core

2017-07-03 Thread Mark Brown
On Mon, Jul 03, 2017 at 11:45:52AM +0530, Viresh Kumar wrote: > On 30-06-17, 13:10, Mark Brown wrote: > > On Fri, Jun 30, 2017 at 02:13:30PM +0530, Viresh Kumar wrote: > > > On 30-06-17, 14:36, Chen-Yu Tsai wrote: > > > And so the DT node shall have this: > > > regulator-min-microvolt =

Re: [RFC 0/5] drivers: Add boot constraints core

2017-07-03 Thread Mark Brown
On Mon, Jul 03, 2017 at 11:45:52AM +0530, Viresh Kumar wrote: > On 30-06-17, 13:10, Mark Brown wrote: > > On Fri, Jun 30, 2017 at 02:13:30PM +0530, Viresh Kumar wrote: > > > On 30-06-17, 14:36, Chen-Yu Tsai wrote: > > > And so the DT node shall have this: > > > regulator-min-microvolt =

Re: [RFC 0/5] drivers: Add boot constraints core

2017-07-03 Thread Viresh Kumar
On 30-06-17, 13:10, Mark Brown wrote: > On Fri, Jun 30, 2017 at 02:13:30PM +0530, Viresh Kumar wrote: > > On 30-06-17, 14:36, Chen-Yu Tsai wrote: > > > Operable ranges of the regulator: 1.8 - 3.0 V > > Range required by LCD: 2.0 - 3.0 V > > Range required by DMA: 1.8 - 2.5 V > > > Here DMA can't

Re: [RFC 0/5] drivers: Add boot constraints core

2017-07-03 Thread Viresh Kumar
On 30-06-17, 13:10, Mark Brown wrote: > On Fri, Jun 30, 2017 at 02:13:30PM +0530, Viresh Kumar wrote: > > On 30-06-17, 14:36, Chen-Yu Tsai wrote: > > > Operable ranges of the regulator: 1.8 - 3.0 V > > Range required by LCD: 2.0 - 3.0 V > > Range required by DMA: 1.8 - 2.5 V > > > Here DMA can't

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-30 Thread Mark Brown
On Fri, Jun 30, 2017 at 02:13:30PM +0530, Viresh Kumar wrote: > On 30-06-17, 14:36, Chen-Yu Tsai wrote: > Operable ranges of the regulator: 1.8 - 3.0 V > Range required by LCD: 2.0 - 3.0 V > Range required by DMA: 1.8 - 2.5 V > Here DMA can't work with regulator voltages > 2.5 V, but regulator

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-30 Thread Mark Brown
On Fri, Jun 30, 2017 at 02:13:30PM +0530, Viresh Kumar wrote: > On 30-06-17, 14:36, Chen-Yu Tsai wrote: > Operable ranges of the regulator: 1.8 - 3.0 V > Range required by LCD: 2.0 - 3.0 V > Range required by DMA: 1.8 - 2.5 V > Here DMA can't work with regulator voltages > 2.5 V, but regulator

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-30 Thread Mark Brown
On Fri, Jun 30, 2017 at 12:22:13PM +0800, Chen-Yu Tsai wrote: > What I'm saying is for the DT case, the constraints are already limited > to the intersection of all users, regardless of whether they are turned > on or not. At least this is what I believe makes sense. You really don't > want to

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-30 Thread Mark Brown
On Fri, Jun 30, 2017 at 12:22:13PM +0800, Chen-Yu Tsai wrote: > What I'm saying is for the DT case, the constraints are already limited > to the intersection of all users, regardless of whether they are turned > on or not. At least this is what I believe makes sense. You really don't > want to

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-30 Thread Viresh Kumar
On 30-06-17, 14:36, Chen-Yu Tsai wrote: > = On Fri, Jun 30, 2017 at 1:12 PM, Viresh Kumar > wrote: > > Right, but someone needs to get the regulator first to have that > > considered by the regulator core while deciding the final range. > > AFAIK the regulator core

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-30 Thread Viresh Kumar
On 30-06-17, 14:36, Chen-Yu Tsai wrote: > = On Fri, Jun 30, 2017 at 1:12 PM, Viresh Kumar > wrote: > > Right, but someone needs to get the regulator first to have that > > considered by the regulator core while deciding the final range. > > AFAIK the regulator core automatically corrects any

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-30 Thread Chen-Yu Tsai
= On Fri, Jun 30, 2017 at 1:12 PM, Viresh Kumar wrote: > On 30-06-17, 12:22, Chen-Yu Tsai wrote: >> On Fri, Jun 30, 2017 at 12:12 PM, Viresh Kumar >> wrote: >> > On 30-06-17, 12:05, Chen-Yu Tsai wrote: > >> >> I also want to mention that for DT

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-30 Thread Chen-Yu Tsai
= On Fri, Jun 30, 2017 at 1:12 PM, Viresh Kumar wrote: > On 30-06-17, 12:22, Chen-Yu Tsai wrote: >> On Fri, Jun 30, 2017 at 12:12 PM, Viresh Kumar >> wrote: >> > On 30-06-17, 12:05, Chen-Yu Tsai wrote: > >> >> I also want to mention that for DT based platforms, this constraint >> >> should

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-29 Thread Viresh Kumar
On 30-06-17, 12:22, Chen-Yu Tsai wrote: > On Fri, Jun 30, 2017 at 12:12 PM, Viresh Kumar > wrote: > > On 30-06-17, 12:05, Chen-Yu Tsai wrote: > >> I also want to mention that for DT based platforms, this constraint > >> should already be set in the device tree for the

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-29 Thread Viresh Kumar
On 30-06-17, 12:22, Chen-Yu Tsai wrote: > On Fri, Jun 30, 2017 at 12:12 PM, Viresh Kumar > wrote: > > On 30-06-17, 12:05, Chen-Yu Tsai wrote: > >> I also want to mention that for DT based platforms, this constraint > >> should already be set in the device tree for the regulator, so the > >>

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-29 Thread Chen-Yu Tsai
On Fri, Jun 30, 2017 at 12:12 PM, Viresh Kumar wrote: > On 30-06-17, 12:05, Chen-Yu Tsai wrote: >> On Fri, Jun 30, 2017 at 11:55 AM, Viresh Kumar >> wrote: >> > On 30-06-17, 11:33, Chen-Yu Tsai wrote: >> >> AFAIK regulator constraints are

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-29 Thread Chen-Yu Tsai
On Fri, Jun 30, 2017 at 12:12 PM, Viresh Kumar wrote: > On 30-06-17, 12:05, Chen-Yu Tsai wrote: >> On Fri, Jun 30, 2017 at 11:55 AM, Viresh Kumar >> wrote: >> > On 30-06-17, 11:33, Chen-Yu Tsai wrote: >> >> AFAIK regulator constraints are supposed to satisfy all users of it. >> > >> > Right. >>

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-29 Thread Viresh Kumar
On 30-06-17, 12:05, Chen-Yu Tsai wrote: > On Fri, Jun 30, 2017 at 11:55 AM, Viresh Kumar > wrote: > > On 30-06-17, 11:33, Chen-Yu Tsai wrote: > >> AFAIK regulator constraints are supposed to satisfy all users of it. > > > > Right. > > > >> >> >Let me try with an example.

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-29 Thread Viresh Kumar
On 30-06-17, 12:05, Chen-Yu Tsai wrote: > On Fri, Jun 30, 2017 at 11:55 AM, Viresh Kumar > wrote: > > On 30-06-17, 11:33, Chen-Yu Tsai wrote: > >> AFAIK regulator constraints are supposed to satisfy all users of it. > > > > Right. > > > >> >> >Let me try with an example. A regulator is shared

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-29 Thread Chen-Yu Tsai
On Fri, Jun 30, 2017 at 11:55 AM, Viresh Kumar wrote: > On 30-06-17, 11:33, Chen-Yu Tsai wrote: >> AFAIK regulator constraints are supposed to satisfy all users of it. > > Right. > >> >> >Let me try with an example. A regulator is shared between LCD and DMA >> >>

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-29 Thread Chen-Yu Tsai
On Fri, Jun 30, 2017 at 11:55 AM, Viresh Kumar wrote: > On 30-06-17, 11:33, Chen-Yu Tsai wrote: >> AFAIK regulator constraints are supposed to satisfy all users of it. > > Right. > >> >> >Let me try with an example. A regulator is shared between LCD and DMA >> >> >controller. >> >> > >> >>

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-29 Thread Viresh Kumar
On 30-06-17, 11:33, Chen-Yu Tsai wrote: > AFAIK regulator constraints are supposed to satisfy all users of it. Right. > >> >Let me try with an example. A regulator is shared between LCD and DMA > >> >controller. > >> > > >> >Operable ranges of the regulator: 1.8 - 3.0 V > >> >Range required by

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-29 Thread Viresh Kumar
On 30-06-17, 11:33, Chen-Yu Tsai wrote: > AFAIK regulator constraints are supposed to satisfy all users of it. Right. > >> >Let me try with an example. A regulator is shared between LCD and DMA > >> >controller. > >> > > >> >Operable ranges of the regulator: 1.8 - 3.0 V > >> >Range required by

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-29 Thread Chen-Yu Tsai
On Fri, Jun 30, 2017 at 11:16 AM, Viresh Kumar wrote: > On 29-06-17, 15:06, Enrico Weigelt, metux IT consult wrote: >> On 29.06.2017 14:47, Viresh Kumar wrote: >> >> >No. Drivers are registered to the kernel (randomly, though we can know >> >their order) and devices are

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-29 Thread Chen-Yu Tsai
On Fri, Jun 30, 2017 at 11:16 AM, Viresh Kumar wrote: > On 29-06-17, 15:06, Enrico Weigelt, metux IT consult wrote: >> On 29.06.2017 14:47, Viresh Kumar wrote: >> >> >No. Drivers are registered to the kernel (randomly, though we can know >> >their order) and devices are registered separately

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-29 Thread Viresh Kumar
On 29-06-17, 15:06, Enrico Weigelt, metux IT consult wrote: > On 29.06.2017 14:47, Viresh Kumar wrote: > > >No. Drivers are registered to the kernel (randomly, though we can know > >their order) and devices are registered separately (platform/amba > >devices get registered automatically with DT,

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-29 Thread Viresh Kumar
On 29-06-17, 15:06, Enrico Weigelt, metux IT consult wrote: > On 29.06.2017 14:47, Viresh Kumar wrote: > > >No. Drivers are registered to the kernel (randomly, though we can know > >their order) and devices are registered separately (platform/amba > >devices get registered automatically with DT,

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-29 Thread Stephen Boyd
On 06/29, Russell King - ARM Linux wrote: > On Thu, Jun 29, 2017 at 08:28:08PM +0530, Viresh Kumar wrote: > > On 29-06-17, 13:49, Russell King - ARM Linux wrote: > > > The thing that concerns me most about this is that typically the LCD > > > controller will be performing DMA to system RAM. > > >

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-29 Thread Stephen Boyd
On 06/29, Russell King - ARM Linux wrote: > On Thu, Jun 29, 2017 at 08:28:08PM +0530, Viresh Kumar wrote: > > On 29-06-17, 13:49, Russell King - ARM Linux wrote: > > > The thing that concerns me most about this is that typically the LCD > > > controller will be performing DMA to system RAM. > > >

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-29 Thread Russell King - ARM Linux
On Thu, Jun 29, 2017 at 08:28:08PM +0530, Viresh Kumar wrote: > On 29-06-17, 13:49, Russell King - ARM Linux wrote: > > The thing that concerns me most about this is that typically the LCD > > controller will be performing DMA to system RAM. > > > > The location of the frame buffer is unknown to

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-29 Thread Russell King - ARM Linux
On Thu, Jun 29, 2017 at 08:28:08PM +0530, Viresh Kumar wrote: > On 29-06-17, 13:49, Russell King - ARM Linux wrote: > > The thing that concerns me most about this is that typically the LCD > > controller will be performing DMA to system RAM. > > > > The location of the frame buffer is unknown to

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-29 Thread Enrico Weigelt, metux IT consult
On 29.06.2017 14:47, Viresh Kumar wrote: No. Drivers are registered to the kernel (randomly, though we can know their order) and devices are registered separately (platform/amba devices get registered automatically with DT, hint: drivers/of/platform.c). The device core checks while registering

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-29 Thread Enrico Weigelt, metux IT consult
On 29.06.2017 14:47, Viresh Kumar wrote: No. Drivers are registered to the kernel (randomly, though we can know their order) and devices are registered separately (platform/amba devices get registered automatically with DT, hint: drivers/of/platform.c). The device core checks while registering

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-29 Thread Viresh Kumar
On 29-06-17, 13:49, Russell King - ARM Linux wrote: > The thing that concerns me most about this is that typically the LCD > controller will be performing DMA to system RAM. > > The location of the frame buffer is unknown to the decompressor - and > as the decompressor self-relocates itself

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-29 Thread Viresh Kumar
On 29-06-17, 13:49, Russell King - ARM Linux wrote: > The thing that concerns me most about this is that typically the LCD > controller will be performing DMA to system RAM. > > The location of the frame buffer is unknown to the decompressor - and > as the decompressor self-relocates itself

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-29 Thread Viresh Kumar
On 29-06-17, 12:40, Enrico Weigelt, metux IT consult wrote: > Just curious: aren't the devices (at least w/ DT) only initialized after > dependencies (eg. regulators) are already up ? No. Drivers are registered to the kernel (randomly, though we can know their order) and devices are registered

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-29 Thread Viresh Kumar
On 29-06-17, 12:40, Enrico Weigelt, metux IT consult wrote: > Just curious: aren't the devices (at least w/ DT) only initialized after > dependencies (eg. regulators) are already up ? No. Drivers are registered to the kernel (randomly, though we can know their order) and devices are registered

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-29 Thread Enrico Weigelt, metux IT consult
On 29.06.2017 12:49, Russell King - ARM Linux wrote: The location of the frame buffer is unknown to the decompressor - and as the decompressor self-relocates itself (using purely assembly code), it could relocate itself on top of the frame buffer, causing the "nice" image to become very

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-29 Thread Enrico Weigelt, metux IT consult
On 29.06.2017 12:49, Russell King - ARM Linux wrote: The location of the frame buffer is unknown to the decompressor - and as the decompressor self-relocates itself (using purely assembly code), it could relocate itself on top of the frame buffer, causing the "nice" image to become very

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-29 Thread Russell King - ARM Linux
On Wed, Jun 28, 2017 at 03:56:33PM +0530, Viresh Kumar wrote: > A typical example of that can be the LCD controller, which is used by > the bootloaders to show image(s) while the machine is booting into > Linux. The LCD controller can be using some resources, like clk, > regulators, etc, that are

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-29 Thread Russell King - ARM Linux
On Wed, Jun 28, 2017 at 03:56:33PM +0530, Viresh Kumar wrote: > A typical example of that can be the LCD controller, which is used by > the bootloaders to show image(s) while the machine is booting into > Linux. The LCD controller can be using some resources, like clk, > regulators, etc, that are

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-29 Thread Enrico Weigelt, metux IT consult
On 28.06.2017 10:26, Viresh Kumar wrote: Hi, Some devices are powered ON by the bootloaders before the bootloader handovers control to Linux. It maybe important for those devices to keep working until the time a Linux device driver probes the device and reconfigure its resources. Just

Re: [RFC 0/5] drivers: Add boot constraints core

2017-06-29 Thread Enrico Weigelt, metux IT consult
On 28.06.2017 10:26, Viresh Kumar wrote: Hi, Some devices are powered ON by the bootloaders before the bootloader handovers control to Linux. It maybe important for those devices to keep working until the time a Linux device driver probes the device and reconfigure its resources. Just

[RFC 0/5] drivers: Add boot constraints core

2017-06-28 Thread Viresh Kumar
Hi, I am sending this RFC to get early comments before I put too much effort in the solution proposed here. The solution isn't fully complete yet. Problem statement: Some devices are powered ON by the bootloaders before the bootloader handovers control to Linux. It maybe important for those

[RFC 0/5] drivers: Add boot constraints core

2017-06-28 Thread Viresh Kumar
Hi, I am sending this RFC to get early comments before I put too much effort in the solution proposed here. The solution isn't fully complete yet. Problem statement: Some devices are powered ON by the bootloaders before the bootloader handovers control to Linux. It maybe important for those