Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1676535 > unrolled thread

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

Back to article view | Back to linux.kernel

Contents

  [RFC 0/5] drivers: Add boot constraints core Viresh Kumar <viresh.kumar@linaro.org> - 2017-06-28 12:30 +0200
    [RFC 1/5] drivers: Add boot constraints core Viresh Kumar <viresh.kumar@linaro.org> - 2017-06-28 12:30 +0200
      Re: [RFC 1/5] drivers: Add boot constraints core Randy Dunlap <rdunlap@infradead.org> - 2017-06-28 18:00 +0200
        Re: [RFC 1/5] drivers: Add boot constraints core Viresh Kumar <viresh.kumar@linaro.org> - 2017-06-29 06:00 +0200
          Re: [RFC 1/5] drivers: Add boot constraints core Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-06-29 15:00 +0200
            Re: [RFC 1/5] drivers: Add boot constraints core Viresh Kumar <viresh.kumar@linaro.org> - 2017-06-29 17:00 +0200
    Re: [RFC 0/5] drivers: Add boot constraints core "Enrico Weigelt, metux IT consult" <enrico.weigelt@gr13.net> - 2017-06-29 14:50 +0200
      Re: [RFC 0/5] drivers: Add boot constraints core Viresh Kumar <viresh.kumar@linaro.org> - 2017-06-29 16:50 +0200
        Re: [RFC 0/5] drivers: Add boot constraints core "Enrico Weigelt, metux IT consult" <enrico.weigelt@gr13.net> - 2017-06-29 17:10 +0200
          Re: [RFC 0/5] drivers: Add boot constraints core Viresh Kumar <viresh.kumar@linaro.org> - 2017-06-30 05:20 +0200
            Re: [RFC 0/5] drivers: Add boot constraints core Chen-Yu Tsai <wens@csie.org> - 2017-06-30 05:40 +0200
              Re: [RFC 0/5] drivers: Add boot constraints core Viresh Kumar <viresh.kumar@linaro.org> - 2017-06-30 06:00 +0200
                Re: [RFC 0/5] drivers: Add boot constraints core Chen-Yu Tsai <wens@csie.org> - 2017-06-30 06:10 +0200
                  Re: [RFC 0/5] drivers: Add boot constraints core Viresh Kumar <viresh.kumar@linaro.org> - 2017-06-30 06:20 +0200
                    Re: [RFC 0/5] drivers: Add boot constraints core Chen-Yu Tsai <wens@csie.org> - 2017-06-30 06:30 +0200
                      Re: [RFC 0/5] drivers: Add boot constraints core Viresh Kumar <viresh.kumar@linaro.org> - 2017-06-30 07:20 +0200
                        Re: [RFC 0/5] drivers: Add boot constraints core Chen-Yu Tsai <wens@csie.org> - 2017-06-30 08:40 +0200
                          Re: [RFC 0/5] drivers: Add boot constraints core Viresh Kumar <viresh.kumar@linaro.org> - 2017-06-30 10:50 +0200
                            Re: [RFC 0/5] drivers: Add boot constraints core Mark Brown <broonie@kernel.org> - 2017-06-30 14:20 +0200
                              Re: [RFC 0/5] drivers: Add boot constraints core Viresh Kumar <viresh.kumar@linaro.org> - 2017-07-03 08:20 +0200
                      Re: [RFC 0/5] drivers: Add boot constraints core Mark Brown <broonie@kernel.org> - 2017-06-30 14:20 +0200
    Re: [RFC 0/5] drivers: Add boot constraints core Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-06-29 14:50 +0200
      Re: [RFC 0/5] drivers: Add boot constraints core "Enrico Weigelt, metux IT consult" <enrico.weigelt@gr13.net> - 2017-06-29 15:10 +0200
      Re: [RFC 0/5] drivers: Add boot constraints core Viresh Kumar <viresh.kumar@linaro.org> - 2017-06-29 17:00 +0200
        Re: [RFC 0/5] drivers: Add boot constraints core Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-06-29 17:50 +0200
          Re: [RFC 0/5] drivers: Add boot constraints core Stephen Boyd <sboyd@codeaurora.org> - 2017-06-29 23:10 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1678762

[Multipart message — attachments visible in raw view] — view raw

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 a regulator such that it over voltages for a subset of its
> consumers. Consumers might not have proper power isolation for this.

Right, and we also shouldn't have voltage setting code in consumers that
don't need to vary their voltage at runtime.  This keeps complexity out
of drivers and avoids the need to handle things like variants that have
different power requirements.

> I think what you mean is that the DT constraints are the union of all
> consumer constraints (1.8 - 3.0 V in this case), then each consumer
> comes in and adds its own constraints. And for such a design, the kernel
> needs to know which and what constraints to apply.

That's the broad idea.

[toc] | [prev] | [next] | [standalone]

#1677716

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 shared between several devices. These shared
> resources should be programmed so that all the users of them are
> satisfied. If a user (X) driver gets probed before the LCD controller
> driver in this case, then it may end up reconfiguring these resources to
> ranges satisfying the current users (only user X) and that can make the
> LCD screen unstable.

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 purely assembly code),
it could relocate itself on top of the frame buffer, causing the "nice"
image to become very colourful.

The decompressor doesn't have the information from DT at that point to
know what are safe locations, so it's up to the boot loader to place
the frame buffer somewhere out of the way.  (If people want to write
a DT parser in position independent ARM assembly code that may change.)

As long as people realise this, then it's not a problem, but given the
number of problems that we've already encountered with boot loaders and
memory space layout, I don't trust them to get this right.

Right now, the ARM kernel booting document requires:

- Quiesce all DMA capable devices so that memory does not get
  corrupted by bogus network packets or disk data. This will save
  you many hours of debug.

so we would need to modify that to make an exception for LCD controllers.
However, we definitely can't have devices left enabled which are capable
of writing to system memory, or which changing system memory is likely
to cause bad effects (eg, packet ring buffers, USB buffers etc, which is
really what the above requirement is about.)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[toc] | [prev] | [next] | [standalone]

#1677741

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 colourful.

Could the bootloader pass safe (or blocked) memory regions to the
decompressor ?

--mtx

[toc] | [prev] | [next] | [standalone]

#1677837

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 purely assembly code),
> it could relocate itself on top of the frame buffer, causing the "nice"
> image to become very colourful.
> 
> The decompressor doesn't have the information from DT at that point to
> know what are safe locations, so it's up to the boot loader to place
> the frame buffer somewhere out of the way.  (If people want to write
> a DT parser in position independent ARM assembly code that may change.)
> 
> As long as people realise this, then it's not a problem, but given the
> number of problems that we've already encountered with boot loaders and
> memory space layout, I don't trust them to get this right.
> 
> Right now, the ARM kernel booting document requires:
> 
> - Quiesce all DMA capable devices so that memory does not get
>   corrupted by bogus network packets or disk data. This will save
>   you many hours of debug.
> 
> so we would need to modify that to make an exception for LCD controllers.
> However, we definitely can't have devices left enabled which are capable
> of writing to system memory, or which changing system memory is likely
> to cause bad effects (eg, packet ring buffers, USB buffers etc, which is
> really what the above requirement is about.)

Well, LCD was just an example here. But yeah, it is one of the most
probable case we have.

So, this thing is already working for sure, of course with some out of
tree hacks. Every smart phone shows their company's logo (some kind of
flash) while the phone boots. How do they get around such issues?

@Stephen: Any idea how Qcom does it ? :)

Must be fixing some area in RAM for this purpose, isn't it ?

-- 
viresh

[toc] | [prev] | [next] | [standalone]

#1677881

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 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 colourful.
> > 
> > The decompressor doesn't have the information from DT at that point to
> > know what are safe locations, so it's up to the boot loader to place
> > the frame buffer somewhere out of the way.  (If people want to write
> > a DT parser in position independent ARM assembly code that may change.)
> > 
> > As long as people realise this, then it's not a problem, but given the
> > number of problems that we've already encountered with boot loaders and
> > memory space layout, I don't trust them to get this right.
> > 
> > Right now, the ARM kernel booting document requires:
> > 
> > - Quiesce all DMA capable devices so that memory does not get
> >   corrupted by bogus network packets or disk data. This will save
> >   you many hours of debug.
> > 
> > so we would need to modify that to make an exception for LCD controllers.
> > However, we definitely can't have devices left enabled which are capable
> > of writing to system memory, or which changing system memory is likely
> > to cause bad effects (eg, packet ring buffers, USB buffers etc, which is
> > really what the above requirement is about.)
> 
> Well, LCD was just an example here. But yeah, it is one of the most
> probable case we have.
> 
> So, this thing is already working for sure, of course with some out of
> tree hacks. Every smart phone shows their company's logo (some kind of
> flash) while the phone boots. How do they get around such issues?

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 during decompression.

It's probably also marked as a reserved memory region in DT to avoid
the kernel touching it during boot, or _maybe_ they just locate it
somewhere in memory that they've tested that the kernel doesn't touch
until after their kernel has initialised the LCD controller (thereby
avoiding the memory being permanently consumed.)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[toc] | [prev] | [next] | [standalone]

#1678198

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.
> > > 
> > > 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 colourful.
> > > 
> > > The decompressor doesn't have the information from DT at that point to
> > > know what are safe locations, so it's up to the boot loader to place
> > > the frame buffer somewhere out of the way.  (If people want to write
> > > a DT parser in position independent ARM assembly code that may change.)
> > > 
> > > As long as people realise this, then it's not a problem, but given the
> > > number of problems that we've already encountered with boot loaders and
> > > memory space layout, I don't trust them to get this right.
> > > 
> > > Right now, the ARM kernel booting document requires:
> > > 
> > > - Quiesce all DMA capable devices so that memory does not get
> > >   corrupted by bogus network packets or disk data. This will save
> > >   you many hours of debug.
> > > 
> > > so we would need to modify that to make an exception for LCD controllers.
> > > However, we definitely can't have devices left enabled which are capable
> > > of writing to system memory, or which changing system memory is likely
> > > to cause bad effects (eg, packet ring buffers, USB buffers etc, which is
> > > really what the above requirement is about.)
> > 
> > Well, LCD was just an example here. But yeah, it is one of the most
> > probable case we have.
> > 
> > So, this thing is already working for sure, of course with some out of
> > tree hacks. Every smart phone shows their company's logo (some kind of
> > flash) while the phone boots. How do they get around such issues?
> 
> 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 during decompression.
> 
> It's probably also marked as a reserved memory region in DT to avoid
> the kernel touching it during boot, or _maybe_ they just locate it
> somewhere in memory that they've tested that the kernel doesn't touch
> until after their kernel has initialised the LCD controller (thereby
> avoiding the memory being permanently consumed.)
> 

Yes. The display controller is typically pointed to a memory
carveout that we treat as reserved in the kernel. I'm fairly
certain that we avoid the "permanently consumed" problem by
making it a carveout for the display controller, so that when the
display controller probes it can take ownership of the memory
from the bootloader.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web