On 19-04-21, 13:52, Bjorn Andersson wrote:
> On Tue 19 Jan 11:45 CST 2021, AngeloGioacchino Del Regno wrote:
> @Viresh, do you have any suggestion regarding my last comment?
> > static int qcom_cpufreq_hw_driver_probe(struct platform_device *pdev)
> > {
> > + const struct qcom_cpufreq_soc_data
On Mon 19 Apr 15:59 CDT 2021, AngeloGioacchino Del Regno wrote:
> Il 19/04/21 20:52, Bjorn Andersson ha scritto:
> > On Tue 19 Jan 11:45 CST 2021, AngeloGioacchino Del Regno wrote:
[..]
> > > +static int qcom_cpufreq_hw_acd_init(struct device *cpu_dev,
> > > + struct cp
Il 19/04/21 20:52, Bjorn Andersson ha scritto:
On Tue 19 Jan 11:45 CST 2021, AngeloGioacchino Del Regno wrote:
On new SoCs (SDM845 onwards) the Operating State Manager (OSM) is
being programmed in the bootloader and write-protected by the
hypervisor, leaving to the OS read-only access to some o
On Wed 14 Apr 20:31 CDT 2021, Taniya Das wrote:
>
> On 4/13/2021 9:19 AM, Viresh Kumar wrote:
> > On 12-04-21, 15:01, Taniya Das wrote:
> > > Technically the HW we are trying to program here differs in terms of
> > > clocking, the LUT definitions and many more. It will definitely make
> > > debug
On Tue 19 Jan 11:45 CST 2021, AngeloGioacchino Del Regno wrote:
> On new SoCs (SDM845 onwards) the Operating State Manager (OSM) is
> being programmed in the bootloader and write-protected by the
> hypervisor, leaving to the OS read-only access to some of its
> registers (in order to read the Look
On 4/13/2021 9:19 AM, Viresh Kumar wrote:
On 12-04-21, 15:01, Taniya Das wrote:
Technically the HW we are trying to program here differs in terms of
clocking, the LUT definitions and many more. It will definitely make
debugging much more troublesome if we try to accommodate multiple versions o
On 12-04-21, 15:01, Taniya Das wrote:
> Technically the HW we are trying to program here differs in terms of
> clocking, the LUT definitions and many more. It will definitely make
> debugging much more troublesome if we try to accomodate multiple versions of
> CPUFREQ-HW in the same code.
>
> Thus
Hi Bjorn,
On 1/21/2021 12:35 AM, Bjorn Andersson wrote:
On Wed 20 Jan 12:25 CST 2021, Taniya Das wrote:
The CPUFREQ-HW driver is intended to be used only for CPUFREQ HW designs
where the firmware programs the look up tables.
It's obvious that this is the intended target for the current ver
On 20-01-21, 13:05, Bjorn Andersson wrote:
> On Wed 20 Jan 12:25 CST 2021, Taniya Das wrote:
>
> > The CPUFREQ-HW driver is intended to be used only for CPUFREQ HW designs
> > where the firmware programs the look up tables.
> >
>
> It's obvious that this is the intended target for the current ve
Il 20/01/21 19:25, Taniya Das ha scritto:
The CPUFREQ-HW driver is intended to be used only for CPUFREQ HW designs
where the firmware programs the look up tables.
Suggestion is to separate out the driver where the programming is
managed by high level OS.
The CPUFREQ HW designs are effectiv
On Wed 20 Jan 12:25 CST 2021, Taniya Das wrote:
> The CPUFREQ-HW driver is intended to be used only for CPUFREQ HW designs
> where the firmware programs the look up tables.
>
It's obvious that this is the intended target for the current version of
the driver, but what are your technical argument
The CPUFREQ-HW driver is intended to be used only for CPUFREQ HW designs
where the firmware programs the look up tables.
Suggestion is to separate out the driver where the programming is
managed by high level OS.
On 1/19/2021 11:15 PM, AngeloGioacchino Del Regno wrote:
On new SoCs (SDM845 on
On new SoCs (SDM845 onwards) the Operating State Manager (OSM) is
being programmed in the bootloader and write-protected by the
hypervisor, leaving to the OS read-only access to some of its
registers (in order to read the Lookup Tables and also some
status registers) and write access to the p-state
13 matches
Mail list logo
