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 dur
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
>>
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 put
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 = <
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
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 ca
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 set
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 vo
= 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 alre
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
> >> scen
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.
>>
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 bet
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.
>> >> >
>> >> >Operab
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 LC
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 (plat
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, h
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.
> > >
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 t
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
d
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 (using
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 sep
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 colourfu
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 s
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 curious
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 dev
25 matches
Mail list logo