Re: [PATCH v2 3/3] mfd: google,cros-ec: add missing properties

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

 



On Tue, Oct 13, 2020 at 2:46 PM Ricardo Cañuelo
<ricardo.canuelo@xxxxxxxxxxxxx> wrote:
> On vie 09-10-2020 08:34:21, Rob Herring wrote:
> > I would probably go this route. You could add this level if there's
> > ever more than one codec. However, I'm still not clear what the
> > address represents for the codec. Is it needed? The address
> > space/format is defined by the parent node. So is this defined by the
> > EC? If so, other components don't have an address?
>
> The address represents the physical base address and length of a shared
> memory region from the EC. This seems to be the only component in the EC
> that needs an address AFAICT, so I guess the unit address and the
> intermediate node are needed to make it compatible with the existing EC
> binding.

Correct.  The address represents where the EC codec is located.  The
driver uses the address to find the corresponding shared memory (if
any, depends on the EC codec's capabilities).

In practice, there is at most only 1 EC codec per machine.  In theory,
it can be multiple EC codecs though (multiple microprocessors run EC
OS for example).

The intermediate layer (i.e. codecs { ... }) breaks current code as
you already discussed about that in previous threads:
- of_platform_populate only creates immediate child devices.
- the codec driver expects its parent is EC node.




[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