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
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
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
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
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
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 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 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
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
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
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
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
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
= 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
= 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
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
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
> >>
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
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.
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
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
>> >>
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.
>> >> >
>> >>
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
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
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
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
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,
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,
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
50 matches
Mail list logo