Hi,
On Fri, Mar 5, 2021 at 8:07 AM Srinivas Kandagatla
wrote:
>
> > If you think it's confusing to change the behavior of the existing
> > functions, would you be opposed to me adding a new function like
> > nvmem_cell_read_le_u32_or_smaller() (or provide me a better name) that
> > would be
On 05/03/2021 14:58, Doug Anderson wrote:
Hi,
On Fri, Mar 5, 2021 at 2:27 AM Srinivas Kandagatla
wrote:
On 27/02/2021 00:26, Douglas Anderson wrote:
The current way that cell "length" is specified for nvmem cells is a
little fuzzy. For instance, let's look at the gpu speed bin
Hi,
On Fri, Mar 5, 2021 at 2:27 AM Srinivas Kandagatla
wrote:
>
>
>
> On 27/02/2021 00:26, Douglas Anderson wrote:
> > The current way that cell "length" is specified for nvmem cells is a
> > little fuzzy. For instance, let's look at the gpu speed bin currently
> > in sc7180.dtsi:
> >
> >
On 27/02/2021 00:26, Douglas Anderson wrote:
The current way that cell "length" is specified for nvmem cells is a
little fuzzy. For instance, let's look at the gpu speed bin currently
in sc7180.dtsi:
gpu_speed_bin: gpu_speed_bin@1d2 {
reg = <0x1d2 0x2>;
bits = <5 8>;
};
This
The current way that cell "length" is specified for nvmem cells is a
little fuzzy. For instance, let's look at the gpu speed bin currently
in sc7180.dtsi:
gpu_speed_bin: gpu_speed_bin@1d2 {
reg = <0x1d2 0x2>;
bits = <5 8>;
};
This is an 8-bit value (as specified by the "bits" field).
5 matches
Mail list logo
