On 10/06/18 12:36, Alban wrote:
On Sun, 10 Jun 2018 11:32:36 +0100
Srinivas Kandagatla wrote:
On 08/06/18 18:07, Alban wrote:
On Fri, 8 Jun 2018 12:34:12 +0100
Srinivas Kandagatla wrote:
...
I looked into this. It would work fine for the cells but not so nicely
for the nvmem device
On Sun, 10 Jun 2018 11:32:36 +0100
Srinivas Kandagatla wrote:
> On 08/06/18 18:07, Alban wrote:
> > On Fri, 8 Jun 2018 12:34:12 +0100
> > Srinivas Kandagatla wrote:
> >
> ...
> >
> > I looked into this. It would work fine for the cells but not so nicely
> > for the nvmem device API. The phan
On 08/06/18 18:07, Alban wrote:
On Fri, 8 Jun 2018 12:34:12 +0100
Srinivas Kandagatla wrote:
...
I looked into this. It would work fine for the cells but not so nicely
for the nvmem device API. The phandle for the nvmem device would have
to reference the node passed here and not the real
On Fri, 8 Jun 2018 12:34:12 +0100
Srinivas Kandagatla wrote:
> >> Can you try this with your original subnode proposal:
> >> just pass the subnode node pointer in np of nvmem_config:
> >>
> >> ->cut<
> >> diff --git a/drivers/nvmem/c
On 08/06/18 11:59, Alban wrote:
On Thu, 7 Jun 2018 18:03:16 +0100
Srinivas Kandagatla wrote:
On 07/06/18 17:41, Alban wrote:
AFAIU the only thing that we disagree on now is if the nodes
representing the cells should be direct children of the provider
or in a dedicated subnode. For the MTD
On Thu, 7 Jun 2018 18:03:16 +0100
Srinivas Kandagatla wrote:
> On 07/06/18 17:41, Alban wrote:
> > AFAIU the only thing that we disagree on now is if the nodes
> > representing the cells should be direct children of the provider
> > or in a dedicated subnode. For the MTD case both solution would
On 07/06/18 17:41, Alban wrote:
AFAIU the only thing that we disagree on now is if the nodes
representing the cells should be direct children of the provider
or in a dedicated subnode. For the MTD case both solution would solve
the binding clash. I would really appreciate if the DT people coul
On Tue, 1 May 2018 17:49:03 +0100
Srinivas Kandagatla wrote:
> On 18/04/18 14:34, Alban wrote:
> > On Wed, 18 Apr 2018 13:53:56 +0100
> > Srinivas Kandagatla wrote:
> >
> >> On 18/04/18 13:32, Alban wrote:
> I was also suggesting you to use nvmem-cell subnode, but make it a
> prop
On 18/04/18 14:34, Alban wrote:
On Wed, 18 Apr 2018 13:53:56 +0100
Srinivas Kandagatla wrote:
On 18/04/18 13:32, Alban wrote:
I was also suggesting you to use nvmem-cell subnode, but make it a
proper nvmem provider device, rather than reusing its parent device.
You would end up some thing
On Wed, 18 Apr 2018 13:53:56 +0100
Srinivas Kandagatla wrote:
> On 18/04/18 13:32, Alban wrote:
> >> I was also suggesting you to use nvmem-cell subnode, but make it a
> >> proper nvmem provider device, rather than reusing its parent device.
> >>
> >> You would end up some thing like this in dt.
On 18/04/18 13:32, Alban wrote:
I was also suggesting you to use nvmem-cell subnode, but make it a
proper nvmem provider device, rather than reusing its parent device.
You would end up some thing like this in dt.
flash@0 {
#address-cells = <1>;
#size-cells = <1>;
compa
On Wed, 18 Apr 2018 13:12:48 +0100
Srinivas Kandagatla wrote:
> On 18/04/18 12:41, Alban wrote:
> > On Tue, 17 Apr 2018 18:00:40 +0200
> > Alban wrote:
> >
> >> On Tue, 17 Apr 2018 16:44:01 +0100
> >> Srinivas Kandagatla wrote:
> >>
> >>> Thanks for explaining,
> >>>
> >>> On 17/04/18 15:5
On 18/04/18 12:41, Alban wrote:
On Tue, 17 Apr 2018 18:00:40 +0200
Alban wrote:
On Tue, 17 Apr 2018 16:44:01 +0100
Srinivas Kandagatla wrote:
Thanks for explaining,
On 17/04/18 15:54, Alban wrote:
This will not only allow reading the calibration data from nvmem, but
will also create a p
On Tue, 17 Apr 2018 18:00:40 +0200
Alban wrote:
> On Tue, 17 Apr 2018 16:44:01 +0100
> Srinivas Kandagatla wrote:
>
> > Thanks for explaining,
> >
> > On 17/04/18 15:54, Alban wrote:
> > > This will not only allow reading the calibration data from nvmem, but
> > > will also create a partitio
On Tue, 17 Apr 2018 16:44:01 +0100
Srinivas Kandagatla wrote:
> Thanks for explaining,
>
> On 17/04/18 15:54, Alban wrote:
> > This will not only allow reading the calibration data from nvmem, but
> > will also create a partition on the MTD device, which is not acceptable.
> > With my proposed b
Thanks for explaining,
On 17/04/18 15:54, Alban wrote:
This will not only allow reading the calibration data from nvmem, but
will also create a partition on the MTD device, which is not acceptable.
With my proposed binding this would become:
flash@0 {
#address-cells = <1>;
#size
On Tue, 17 Apr 2018 13:54:07 +0100
Srinivas Kandagatla wrote:
> On 24/03/18 23:24, Alban Bedel wrote:
> > Having the cells as subnodes of the provider device without any
> > compatible property might clash with other bindings. To avoid this
> > problem update the binding to have all the cells in
On 24/03/18 23:24, Alban Bedel wrote:
Having the cells as subnodes of the provider device without any
compatible property might clash with other bindings. To avoid this
problem update the binding to have all the cells in a 'nvmem-cells'
subnode with a 'nvmem-cells' compatible string. This new b
On Mon, 16 Apr 2018 16:04:29 -0500
Rob Herring wrote:
> On Sun, Mar 25, 2018 at 12:24:57AM +0100, Alban Bedel wrote:
> > Having the cells as subnodes of the provider device without any
> > compatible property might clash with other bindings. To avoid this
> > problem update the binding to have al
On Sun, Mar 25, 2018 at 12:24:57AM +0100, Alban Bedel wrote:
> Having the cells as subnodes of the provider device without any
> compatible property might clash with other bindings. To avoid this
> problem update the binding to have all the cells in a 'nvmem-cells'
> subnode with a 'nvmem-cells' co
Having the cells as subnodes of the provider device without any
compatible property might clash with other bindings. To avoid this
problem update the binding to have all the cells in a 'nvmem-cells'
subnode with a 'nvmem-cells' compatible string. This new binding
guarantee that we can turn any kind
21 matches
Mail list logo
