Re: [PATCH v2] arm64: dts: imx8mp: Add DT nodes for the two ISPs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 24-06-13, Marek Vasut wrote:
> On 6/11/24 5:01 AM, Peng Fan wrote:
> 
> [...]
> 
> > > > > According to the i.MX8MP Data sheet, the nominal speed for
> > > > > MEDIA_ISP_CLOCL_ROOT is 400MHZ with 500MHz being allowed in
> > > overdrive
> > > > > mode.
> > > > > 
> > > > > I think this clock rate should drop to  the nominal value of 400MHz
> > > > > and those boards who support overdrive can increase it to 500MHz to
> > > > > avoid stiability issues and/or running out of spec.  I created an
> > > > > imx8mm and imx8mn- overdrive.dtsi file.  If there is interest, I can do the
> > > same for the 8MP as well.
> > > > > 
> > > > > I haven't gone through all the clocks to determine if/what clocks are
> > > > > being overdriven.
> > > > 
> > > > Shouldn't the bootloader take the work to runtime update the freq?
> > > > Why need introduce an extra overdrive.dtsi?
> > > 
> > > Shouldn't the overdrive/non-overdrive decision be done in board DT instead ?
> > 
> > It is bootloader configure voltage to nominal, then bootloader should use
> > nominal device tree or runtime update dtb.
> > If bootloader configure voltage to over-drive, bootloader could use
> > nominal or over-drive dtb
> 
> I think the bootloader should always configure the minimal common
> configuration, i.e. nominal voltage, nominal clock, so that it would achieve
> maximum compatibility with any SoC in that SoC line up.
> 
> If the user does need overdrive configuration, they should specify that in
> their board DT.

+1

> Keep in mind, the kernel is easy to update (including kernel DT), the
> bootloader is not easy to update (esp. in field, bootloader update may
> render a system unbootable if it fails). I would say, it is better to keep
> the complicated things out of the bootloader if at all possible.
> 
> > If introduce x.dtsi and x-overdrive.dtsi, how to let board choose which dtsi
> > to include?
> 
> #include "x.dtsi"
> or
> #include "x-overdrive.dtsi"
> 
> But I think your question is -- how to do that at runtime ?
> 
> U-Boot can apply DT overlays onto DT that is passed to Linux, so if the user
> has board variants where they need both nonoverdrive/overdrive options, they
> can apply DT overlay which enables the overdrive mode on boards which need
> it. This can be done from U-Boot boot.scr or similar boot script, which can
> again be easily updated, without the need to update the bootloader itself
> (if something goes wrong or needs to be changed in the future).

+1 for the runtime configuration via overlay as well. The overlay can be
generated very easily by including the x-overdrive.dtsi into a .dtso and
for those who want to run in overdrive mode always they can mae use of
the x-overdrive.dtsi directly within the .dts file.

Regards,
  Marco




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux