Re: [PATCH] of: Kconfig: OF_OVERLAY, select OF_EARLY_FLATTREE

On 02/18/18 17:46, Rob Herring wrote: > On Sun, Feb 18, 2018 at 6:29 PM, <frowand.l...@gmail.com> wrote: >> From: Frank Rowand <frank.row...@sony.com> >> >> kbuild test robot reported a new warning for a recent patch: >>>> drivers/of/overlay.c:8

Re: [PATCH] of: Kconfig: OF_OVERLAY, select OF_EARLY_FLATTREE

On 02/18/18 17:46, Rob Herring wrote: > On Sun, Feb 18, 2018 at 6:29 PM, wrote: >> From: Frank Rowand >> >> kbuild test robot reported a new warning for a recent patch: >>>> drivers/of/overlay.c:832:2: error: implicit declaration of function >>>&

Re: [PATCH v3] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()

On 02/16/18 14:20, Frank Rowand wrote: > On 02/16/18 01:04, Chintan Pandya wrote: >> >> >> On 2/15/2018 6:22 AM, frowand.l...@gmail.com wrote: >>> From: Frank Rowand <frank.row...@sony.com> >>> >>> Create a cache of the nodes that contain a

Re: [PATCH v3] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()

On 02/16/18 14:20, Frank Rowand wrote: > On 02/16/18 01:04, Chintan Pandya wrote: >> >> >> On 2/15/2018 6:22 AM, frowand.l...@gmail.com wrote: >>> From: Frank Rowand >>> >>> Create a cache of the nodes that contain a phandle property.  Use this >

Re: [PATCH] of: add early boot allocation of of_find_node_by_phandle() cache

On 02/16/18 01:07, Chintan Pandya wrote: > > > On 2/15/2018 6:14 AM, frowand.l...@gmail.com wrote: >> From: Frank Rowand <frank.row...@sony.com> >> >> The initial implementation of the of_find_node_by_phandle() cache >> allocates the cache using k

Re: [PATCH] of: add early boot allocation of of_find_node_by_phandle() cache

On 02/16/18 01:07, Chintan Pandya wrote: > > > On 2/15/2018 6:14 AM, frowand.l...@gmail.com wrote: >> From: Frank Rowand >> >> The initial implementation of the of_find_node_by_phandle() cache >> allocates the cache using kcalloc().  Add an early b

Re: [PATCH v3] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()

On 02/16/18 01:04, Chintan Pandya wrote: > > > On 2/15/2018 6:22 AM, frowand.l...@gmail.com wrote: >> From: Frank Rowand <frank.row...@sony.com> >> >> Create a cache of the nodes that contain a phandle property.  Use this >> cache to find the node for a

Re: [PATCH v3] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()

On 02/16/18 01:04, Chintan Pandya wrote: > > > On 2/15/2018 6:22 AM, frowand.l...@gmail.com wrote: >> From: Frank Rowand >> >> Create a cache of the nodes that contain a phandle property.  Use this >> cache to find the node for a given phandle value instead of s

Re: [PATCH] of: add early boot allocation of of_find_node_by_phandle() cache

On 02/14/18 16:44, frowand.l...@gmail.com wrote: > From: Frank Rowand <frank.row...@sony.com> > > The initial implementation of the of_find_node_by_phandle() cache > allocates the cache using kcalloc(). Add an early boot allocation > of the cache so it will be usable durin

Re: [PATCH] of: add early boot allocation of of_find_node_by_phandle() cache

On 02/14/18 16:44, frowand.l...@gmail.com wrote: > From: Frank Rowand > > The initial implementation of the of_find_node_by_phandle() cache > allocates the cache using kcalloc(). Add an early boot allocation > of the cache so it will be usable during early boot. Switch over &

Re: [PATCH v2] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()

On 02/13/18 06:49, Rob Herring wrote: > On Mon, Feb 12, 2018 at 12:27 AM, <frowand.l...@gmail.com> wrote: >> From: Frank Rowand <frank.row...@sony.com> >> >> Create a cache of the nodes that contain a phandle property. Use this >> cache to find the

Re: [PATCH v2] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()

On 02/13/18 06:49, Rob Herring wrote: > On Mon, Feb 12, 2018 at 12:27 AM, wrote: >> From: Frank Rowand >> >> Create a cache of the nodes that contain a phandle property. Use this >> cache to find the node for a given phandle value instead of scanning >>

Re: [PATCH v2] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()

Hi Rob, On 02/11/18 22:56, Frank Rowand wrote: > Hi Rob, > > On 02/11/18 22:27, frowand.l...@gmail.com wrote: >> From: Frank Rowand <frank.row...@sony.com> >> >> Create a cache of the nodes that contain a phandle property. Use this >> cache to find the

Re: [PATCH v2] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()

Hi Rob, On 02/11/18 22:56, Frank Rowand wrote: > Hi Rob, > > On 02/11/18 22:27, frowand.l...@gmail.com wrote: >> From: Frank Rowand >> >> Create a cache of the nodes that contain a phandle property. Use this >> cache to find the node for a given

Re: RFC: build config via DT names

Hi Enrico, On 02/12/18 15:13, Frank Rowand wrote: > + devicetree mail list > > On 02/10/18 07:52, Enrico Weigelt, metux IT consult wrote: >> Hi folks, >> >> I've regularily have the task of configuring a kernel for a given DT. >> To make this a

Re: RFC: build config via DT names

Hi Enrico, On 02/12/18 15:13, Frank Rowand wrote: > + devicetree mail list > > On 02/10/18 07:52, Enrico Weigelt, metux IT consult wrote: >> Hi folks, >> >> I've regularily have the task of configuring a kernel for a given DT. >> To make this a

Re: RFC: build config via DT names

+ devicetree mail list On 02/10/18 07:52, Enrico Weigelt, metux IT consult wrote: > Hi folks, > > I've regularily have the task of configuring a kernel for a given DT. > To make this a little bit easier, I'd like to do this automatically. > > The tuff task here is getting a mapping between dt

Re: RFC: build config via DT names

+ devicetree mail list On 02/10/18 07:52, Enrico Weigelt, metux IT consult wrote: > Hi folks, > > I've regularily have the task of configuring a kernel for a given DT. > To make this a little bit easier, I'd like to do this automatically. > > The tuff task here is getting a mapping between dt

Re: [PATCH v2 4/4] of: improve reporting invalid overlay target path

On 02/12/18 01:00, Geert Uytterhoeven wrote: > Hi Frank, > > On Mon, Feb 12, 2018 at 9:51 AM, <frowand.l...@gmail.com> wrote: >> From: Frank Rowand <frank.row...@sony.com> >> >> Errors while developing the patch to create of_overlay_fdt_apply() >&g

Re: [PATCH v2 4/4] of: improve reporting invalid overlay target path

On 02/12/18 01:00, Geert Uytterhoeven wrote: > Hi Frank, > > On Mon, Feb 12, 2018 at 9:51 AM, wrote: >> From: Frank Rowand >> >> Errors while developing the patch to create of_overlay_fdt_apply() >> exposed inadequate error messages to debug problems when ove

Re: [PATCH v2] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()

On 02/12/18 02:51, Chintan Pandya wrote: > > > On 2/12/2018 11:57 AM, frowand.l...@gmail.com wrote: >> From: Frank Rowand <frank.row...@sony.com> >> >> Create a cache of the nodes that contain a phandle property.  Use this >> cache to find the node for a

Re: [PATCH v2] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()

On 02/12/18 02:51, Chintan Pandya wrote: > > > On 2/12/2018 11:57 AM, frowand.l...@gmail.com wrote: >> From: Frank Rowand >> >> Create a cache of the nodes that contain a phandle property.  Use this >> cache to find the node for a given phandle value inst

Re: [PATCH v2] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()

On 02/12/18 00:58, Rasmus Villemoes wrote: > On 2018-02-12 07:27, frowand.l...@gmail.com wrote: >> From: Frank Rowand <frank.row...@sony.com> >> >> Create a cache of the nodes that contain a phandle property. Use this >> cache to find the node for a given

Re: [PATCH v2] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()

On 02/12/18 00:58, Rasmus Villemoes wrote: > On 2018-02-12 07:27, frowand.l...@gmail.com wrote: >> From: Frank Rowand >> >> Create a cache of the nodes that contain a phandle property. Use this >> cache to find the node for a given phandle value instead of scannin

Re: [PATCH v2] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()

On 02/11/18 22:27, frowand.l...@gmail.com wrote: > From: Frank Rowand <frank.row...@sony.com> > > Create a cache of the nodes that contain a phandle property. Use this > cache to find the node for a given phandle value instead of scanning > the devicetree to find the node.

Re: [PATCH v2] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()

On 02/11/18 22:27, frowand.l...@gmail.com wrote: > From: Frank Rowand > > Create a cache of the nodes that contain a phandle property. Use this > cache to find the node for a given phandle value instead of scanning > the devicetree to find the node. If the phandle val

Re: [PATCH v2] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()

Hi Rob, On 02/11/18 22:27, frowand.l...@gmail.com wrote: > From: Frank Rowand <frank.row...@sony.com> > > Create a cache of the nodes that contain a phandle property. Use this > cache to find the node for a given phandle value instead of scanning > the device

Re: [PATCH v2] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()

Hi Rob, On 02/11/18 22:27, frowand.l...@gmail.com wrote: > From: Frank Rowand > > Create a cache of the nodes that contain a phandle property. Use this > cache to find the node for a given phandle value instead of scanning > the devicetree to find the node. If the phandle val

Re: [PATCH] of: cache phandle nodes to decrease cost of of_find_node_by_phandle()

On 02/07/18 04:44, Chintan Pandya wrote: > > > On 2/5/2018 5:53 PM, Chintan Pandya wrote: >> >>> >>> My question was trying to determine whether the numbers reported above >>> are for a debug configuration or a production configuration. >> My reported numbers are from debug configuration. >> >>>

Re: [PATCH] of: cache phandle nodes to decrease cost of of_find_node_by_phandle()

On 02/07/18 04:44, Chintan Pandya wrote: > > > On 2/5/2018 5:53 PM, Chintan Pandya wrote: >> >>> >>> My question was trying to determine whether the numbers reported above >>> are for a debug configuration or a production configuration. >> My reported numbers are from debug configuration. >> >>>

Re: [PATCH] of: cache phandle nodes to decrease cost of of_find_node_by_phandle()

On 02/01/18 21:53, Chintan Pandya wrote: > > > On 2/2/2018 2:39 AM, Frank Rowand wrote: >> On 02/01/18 06:24, Rob Herring wrote: >>> And so >>> far, no one has explained why a bigger cache got slower. >> >> Yes, I still find that surprising.

Re: [PATCH] of: cache phandle nodes to decrease cost of of_find_node_by_phandle()

On 02/01/18 21:53, Chintan Pandya wrote: > > > On 2/2/2018 2:39 AM, Frank Rowand wrote: >> On 02/01/18 06:24, Rob Herring wrote: >>> And so >>> far, no one has explained why a bigger cache got slower. >> >> Yes, I still find that surprising.

Re: [PATCH] of: cache phandle nodes to decrease cost of of_find_node_by_phandle()

On 02/01/18 19:45, Rob Herring wrote: > On Thu, Feb 1, 2018 at 3:09 PM, Frank Rowand <frowand.l...@gmail.com> wrote: >> On 02/01/18 06:24, Rob Herring wrote: >>> On Wed, Jan 31, 2018 at 3:43 PM, Frank Rowand <frowand.l...@gmail.com> >>> wrote: >>>&

Re: [PATCH] of: cache phandle nodes to decrease cost of of_find_node_by_phandle()

On 02/01/18 19:45, Rob Herring wrote: > On Thu, Feb 1, 2018 at 3:09 PM, Frank Rowand wrote: >> On 02/01/18 06:24, Rob Herring wrote: >>> On Wed, Jan 31, 2018 at 3:43 PM, Frank Rowand >>> wrote: >>>> On 01/31/18 12:05, frowand.l...@gmail.com wrote: >&

Re: [PATCH] of: cache phandle nodes to decrease cost of of_find_node_by_phandle()

On 02/01/18 21:59, Chintan Pandya wrote: > > > On 2/2/2018 12:40 AM, Frank Rowand wrote: >> On 02/01/18 02:31, Chintan Pandya wrote: >>> >>>>> Anyways, will fix this locally and share test results. >>>> >>>> Thanks, I look forward

Re: [PATCH] of: cache phandle nodes to decrease cost of of_find_node_by_phandle()

On 02/01/18 21:59, Chintan Pandya wrote: > > > On 2/2/2018 12:40 AM, Frank Rowand wrote: >> On 02/01/18 02:31, Chintan Pandya wrote: >>> >>>>> Anyways, will fix this locally and share test results. >>>> >>>> Thanks, I look forward

Re: [PATCH] of: cache phandle nodes to decrease cost of of_find_node_by_phandle()

On 02/01/18 06:34, Rob Herring wrote: > On Wed, Jan 31, 2018 at 2:05 PM, <frowand.l...@gmail.com> wrote: >> From: Frank Rowand <frank.row...@sony.com> >> >> Create a cache of the nodes that contain a phandle property. Use this >> cache to find the

Re: [PATCH] of: cache phandle nodes to decrease cost of of_find_node_by_phandle()

On 02/01/18 06:34, Rob Herring wrote: > On Wed, Jan 31, 2018 at 2:05 PM, wrote: >> From: Frank Rowand >> >> Create a cache of the nodes that contain a phandle property. Use this >> cache to find the node for a given phandle value instead of scanning >>

Re: [PATCH] of: cache phandle nodes to decrease cost of of_find_node_by_phandle()

On 02/01/18 06:24, Rob Herring wrote: > On Wed, Jan 31, 2018 at 3:43 PM, Frank Rowand <frowand.l...@gmail.com> wrote: >> On 01/31/18 12:05, frowand.l...@gmail.com wrote: >>> From: Frank Rowand <frank.row...@sony.com> >>> >>> Create a cache of

Re: [PATCH] of: cache phandle nodes to decrease cost of of_find_node_by_phandle()

On 02/01/18 06:24, Rob Herring wrote: > On Wed, Jan 31, 2018 at 3:43 PM, Frank Rowand wrote: >> On 01/31/18 12:05, frowand.l...@gmail.com wrote: >>> From: Frank Rowand >>> >>> Create a cache of the nodes that contain a phandle property. Use this >>&g

Re: [PATCH] of: cache phandle nodes to decrease cost of of_find_node_by_phandle()

On 02/01/18 02:31, Chintan Pandya wrote: > >>> Anyways, will fix this locally and share test results. >> >> Thanks, I look forward to the results. >> > > Set up for this time was slightly different. So, taken all the numbers again. > > Boot to shell time (in ms): Experiment 2 > [1] Base 

Re: [PATCH] of: cache phandle nodes to decrease cost of of_find_node_by_phandle()

On 02/01/18 02:31, Chintan Pandya wrote: > >>> Anyways, will fix this locally and share test results. >> >> Thanks, I look forward to the results. >> > > Set up for this time was slightly different. So, taken all the numbers again. > > Boot to shell time (in ms): Experiment 2 > [1] Base 

Re: [PATCH] of: cache phandle nodes to decrease cost of of_find_node_by_phandle()

On 01/31/18 22:45, Chintan Pandya wrote: > > > On 2/1/2018 1:35 AM, frowand.l...@gmail.com wrote: >> From: Frank Rowand <frank.row...@sony.com> > >> + >> +static void of_populate_phandle_cache(void) >> +{ >> +    unsigned long flags; &g

Re: [PATCH] of: cache phandle nodes to decrease cost of of_find_node_by_phandle()

On 01/31/18 22:45, Chintan Pandya wrote: > > > On 2/1/2018 1:35 AM, frowand.l...@gmail.com wrote: >> From: Frank Rowand > >> + >> +static void of_populate_phandle_cache(void) >> +{ >> +    unsigned long flags; >> +    phandle max_phandle; >&

Re: [PATCH] of: cache phandle nodes to decrease cost of of_find_node_by_phandle()

On 01/31/18 12:05, frowand.l...@gmail.com wrote: > From: Frank Rowand <frank.row...@sony.com> > > Create a cache of the nodes that contain a phandle property. Use this > cache to find the node for a given phandle value instead of scanning > the devicetree to find the node.

Re: [PATCH] of: cache phandle nodes to decrease cost of of_find_node_by_phandle()

On 01/31/18 12:05, frowand.l...@gmail.com wrote: > From: Frank Rowand > > Create a cache of the nodes that contain a phandle property. Use this > cache to find the node for a given phandle value instead of scanning > the devicetree to find the node. If the phandle val

Re: [PATCH] of: cache phandle nodes to decrease cost of of_find_node_by_phandle()

resolver.c will fail on 4.9 because that code does not exist yet -- you can just remove that portion of the patch. -Frank On 01/31/18 12:05, frowand.l...@gmail.com wrote: > From: Frank Rowand <frank.row...@sony.com> > > Create a cache of the nodes that contain a phandle

Re: [PATCH] of: cache phandle nodes to decrease cost of of_find_node_by_phandle()

resolver.c will fail on 4.9 because that code does not exist yet -- you can just remove that portion of the patch. -Frank On 01/31/18 12:05, frowand.l...@gmail.com wrote: > From: Frank Rowand > > Create a cache of the nodes that contain a phandle property. Use this > cache to f

Re: [PATCH] of: cache phandle nodes to decrease cost of of_find_node_by_phandle()

Hi Rob, Please ignore this one. My signed-off is below the first "---". -Frank On 01/31/18 12:02, frowand.l...@gmail.com wrote: > From: Frank Rowand <frank.row...@sony.com> > > Create a cache of the nodes that contain a phandle property. Use this > cache to find

Re: [PATCH] of: cache phandle nodes to decrease cost of of_find_node_by_phandle()

Hi Rob, Please ignore this one. My signed-off is below the first "---". -Frank On 01/31/18 12:02, frowand.l...@gmail.com wrote: > From: Frank Rowand > > Create a cache of the nodes that contain a phandle property. Use this > cache to find the node for a given

Re: [PATCH v2] of: use hash based search in of_find_node_by_phandle

On 01/30/18 00:04, Chintan Pandya wrote: >> (1) >> >> Can you point me to the driver code that is invoking >> the search? > There are many locations. Few of them being, > https://source.codeaurora.org/quic/la/kernel/msm-4.9/tree/drivers/of/irq.c?h=msm-4.9#n214 >

Re: [PATCH v2] of: use hash based search in of_find_node_by_phandle

On 01/30/18 00:04, Chintan Pandya wrote: >> (1) >> >> Can you point me to the driver code that is invoking >> the search? > There are many locations. Few of them being, > https://source.codeaurora.org/quic/la/kernel/msm-4.9/tree/drivers/of/irq.c?h=msm-4.9#n214 >

Re: [PATCH 0/2] of: change overlay apply input data from EDT to FDT

t-path form needed by the fpga subsystem, or can this be removed? -Frank On 01/29/18 16:22, Frank Rowand wrote: > On 01/29/18 06:08, Geert Uytterhoeven wrote: >> Hi Frank, >> >> On Mon, Jan 29, 2018 at 3:53 AM, <frowand.l...@gmail.com> wrote: >>> F

Re: [PATCH 0/2] of: change overlay apply input data from EDT to FDT

t-path form needed by the fpga subsystem, or can this be removed? -Frank On 01/29/18 16:22, Frank Rowand wrote: > On 01/29/18 06:08, Geert Uytterhoeven wrote: >> Hi Frank, >> >> On Mon, Jan 29, 2018 at 3:53 AM, wrote: >>> From: Frank Rowand >>> >>>

Re: [PATCH 0/2] of: change overlay apply input data from EDT to FDT

On 01/29/18 06:08, Geert Uytterhoeven wrote: > Hi Frank, > > On Mon, Jan 29, 2018 at 3:53 AM, <frowand.l...@gmail.com> wrote: >> From: Frank Rowand <frank.row...@sony.com> >> >> Move duplicating and unflattening of an overlay flattened devicetree >

Re: [PATCH 0/2] of: change overlay apply input data from EDT to FDT

On 01/29/18 06:08, Geert Uytterhoeven wrote: > Hi Frank, > > On Mon, Jan 29, 2018 at 3:53 AM, wrote: >> From: Frank Rowand >> >> Move duplicating and unflattening of an overlay flattened devicetree >> (FDT) into the overlay application code. To acc

Re: [PATCH 2/2] of: convert unittest overlay devicetree source to sugar syntax

On 01/29/18 02:37, Geert Uytterhoeven wrote: > Hi Frank, > > On Mon, Jan 29, 2018 at 3:53 AM, <frowand.l...@gmail.com> wrote: >> From: Frank Rowand <frank.row...@sony.com> >> >> The unittest-data overlays have been pulled into proper overlay >

Re: [PATCH 2/2] of: convert unittest overlay devicetree source to sugar syntax

On 01/29/18 02:37, Geert Uytterhoeven wrote: > Hi Frank, > > On Mon, Jan 29, 2018 at 3:53 AM, wrote: >> From: Frank Rowand >> >> The unittest-data overlays have been pulled into proper overlay >> devicetree source files without changing their format. The >&

Re: [PATCH 1/2] of: change overlay apply input data from EDT to FDT

On 01/29/18 07:05, Geert Uytterhoeven wrote: > On Mon, Jan 29, 2018 at 3:42 PM, Rob Herring <r...@kernel.org> wrote: >> On Sun, Jan 28, 2018 at 8:53 PM, <frowand.l...@gmail.com> wrote: >>> From: Frank Rowand <frank.row...@sony.com> >>> >>> Mov

Re: [PATCH 1/2] of: change overlay apply input data from EDT to FDT

On 01/29/18 07:05, Geert Uytterhoeven wrote: > On Mon, Jan 29, 2018 at 3:42 PM, Rob Herring wrote: >> On Sun, Jan 28, 2018 at 8:53 PM, wrote: >>> From: Frank Rowand >>> >>> Move duplicating and unflattening of an overlay flattened devicetree >>

Re: [PATCH 1/2] of: change overlay apply input data from EDT to FDT

On 01/29/18 06:42, Rob Herring wrote: > On Sun, Jan 28, 2018 at 8:53 PM, <frowand.l...@gmail.com> wrote: >> From: Frank Rowand <frank.row...@sony.com> >> >> Move duplicating and unflattening of an overlay flattened devicetree >> (FDT) into the o

Re: [PATCH 1/2] of: change overlay apply input data from EDT to FDT

On 01/29/18 06:42, Rob Herring wrote: > On Sun, Jan 28, 2018 at 8:53 PM, wrote: >> From: Frank Rowand >> >> Move duplicating and unflattening of an overlay flattened devicetree >> (FDT) into the overlay application code. To accomplish this, >&g

Re: [PATCH v2] of: use hash based search in of_find_node_by_phandle

Hi Chintan, On 01/26/18 00:31, Chintan Pandya wrote: > of_find_node_by_phandle() takes a lot of time (1ms per > call) to find right node when your intended device is > too deeper in the fdt. Reason is, we search for each > device serially in the fdt. See this, > > struct device_node

Re: [PATCH v2] of: use hash based search in of_find_node_by_phandle

Hi Chintan, On 01/26/18 00:31, Chintan Pandya wrote: > of_find_node_by_phandle() takes a lot of time (1ms per > call) to find right node when your intended device is > too deeper in the fdt. Reason is, we search for each > device serially in the fdt. See this, > > struct device_node

Re: [PATCH 1/2] of: change overlay apply input data from EDT to FDT

On 01/28/18 19:21, Masahiro Yamada wrote: > Hi Frank, > > 2018-01-29 11:53 GMT+09:00 <frowand.l...@gmail.com>: >> From: Frank Rowand <frank.row...@sony.com> >> diff --git a/drivers/of/unittest-data/Makefile >> b/drivers/of/unittest-data/Makefile >

Re: [PATCH 1/2] of: change overlay apply input data from EDT to FDT

On 01/28/18 19:21, Masahiro Yamada wrote: > Hi Frank, > > 2018-01-29 11:53 GMT+09:00 : >> From: Frank Rowand >> diff --git a/drivers/of/unittest-data/Makefile >> b/drivers/of/unittest-data/Makefile >> index df697976740a..2b7ee68c908e 100644 >> --- a/dri

Re: [PATCH] of: use hash based search in of_find_node_by_phandle

On 01/26/18 13:29, Frank Rowand wrote: > On 01/26/18 13:27, Frank Rowand wrote: >> On 01/26/18 00:22, Chintan Pandya wrote: >>> >>> >>> On 1/26/2018 1:24 AM, Frank Rowand wrote: >>>> On 01/25/18 02:14, Chintan Pandya wrote: >>>>> of

Re: [PATCH] of: use hash based search in of_find_node_by_phandle

On 01/26/18 13:29, Frank Rowand wrote: > On 01/26/18 13:27, Frank Rowand wrote: >> On 01/26/18 00:22, Chintan Pandya wrote: >>> >>> >>> On 1/26/2018 1:24 AM, Frank Rowand wrote: >>>> On 01/25/18 02:14, Chintan Pandya wrote: >>>>> of

Re: [PATCH] of: use hash based search in of_find_node_by_phandle

On 01/26/18 13:27, Frank Rowand wrote: > On 01/26/18 00:22, Chintan Pandya wrote: >> >> >> On 1/26/2018 1:24 AM, Frank Rowand wrote: >>> On 01/25/18 02:14, Chintan Pandya wrote: >>>> of_find_node_by_phandle() takes a lot of time finding >>>>

Re: [PATCH] of: use hash based search in of_find_node_by_phandle

On 01/26/18 13:27, Frank Rowand wrote: > On 01/26/18 00:22, Chintan Pandya wrote: >> >> >> On 1/26/2018 1:24 AM, Frank Rowand wrote: >>> On 01/25/18 02:14, Chintan Pandya wrote: >>>> of_find_node_by_phandle() takes a lot of time finding >>>>

Re: [PATCH] of: use hash based search in of_find_node_by_phandle

On 01/26/18 00:22, Chintan Pandya wrote: > > > On 1/26/2018 1:24 AM, Frank Rowand wrote: >> On 01/25/18 02:14, Chintan Pandya wrote: >>> of_find_node_by_phandle() takes a lot of time finding >>> right node when your intended device is too right-side >>

Re: [PATCH] of: use hash based search in of_find_node_by_phandle

On 01/26/18 00:22, Chintan Pandya wrote: > > > On 1/26/2018 1:24 AM, Frank Rowand wrote: >> On 01/25/18 02:14, Chintan Pandya wrote: >>> of_find_node_by_phandle() takes a lot of time finding >>> right node when your intended device is too right-side >>

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

On 01/25/18 15:53, Tyrel Datwyler wrote: > On 01/25/2018 01:49 PM, Frank Rowand wrote: >> Hi Wolfram, >> >> On 01/25/18 03:03, Steven Rostedt wrote: >>> On Wed, 24 Jan 2018 22:55:13 -0800 >>> Frank Rowand <frowand.l...@gmail.com> wrote: >>>

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

On 01/25/18 15:53, Tyrel Datwyler wrote: > On 01/25/2018 01:49 PM, Frank Rowand wrote: >> Hi Wolfram, >> >> On 01/25/18 03:03, Steven Rostedt wrote: >>> On Wed, 24 Jan 2018 22:55:13 -0800 >>> Frank Rowand wrote: >>> >>>> Hi Steve, >&g

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

On 01/25/18 15:14, Wolfram Sang wrote: > >> This means that ftrace can not be used for the of_node_get(), >> of_node_put(), and of_node_release() debug info, because >> these functions are called before early_initcall(). > > For the record: You can still unbind/bind devices. This is how I >

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

On 01/25/18 15:14, Wolfram Sang wrote: > >> This means that ftrace can not be used for the of_node_get(), >> of_node_put(), and of_node_release() debug info, because >> these functions are called before early_initcall(). > > For the record: You can still unbind/bind devices. This is how I >

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

On 01/25/18 15:12, Wolfram Sang wrote: > Frank, > > here seems to be a misunderstanding going on. I don't want to push this > patch upstream against all odds. I merely wanted to find out what the > status of this patch is. Because one possibility was that it had just > been forgotten... > >>>

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

On 01/25/18 15:12, Wolfram Sang wrote: > Frank, > > here seems to be a misunderstanding going on. I don't want to push this > patch upstream against all odds. I merely wanted to find out what the > status of this patch is. Because one possibility was that it had just > been forgotten... > >>>

Re: [RFC PATCH v2 1/1] of: introduce event tracepoints for dynamic device_node lifecyle

On 01/25/18 14:40, Tyrel Datwyler wrote: > On 01/24/2018 10:48 PM, Frank Rowand wrote: >> On 01/21/18 06:31, Wolfram Sang wrote: >>> From: Tyrel Datwyler <tyr...@linux.vnet.ibm.com> >>> >>> This patch introduces event tracepoints for tracking a device_nod

Re: [RFC PATCH v2 1/1] of: introduce event tracepoints for dynamic device_node lifecyle

On 01/25/18 14:40, Tyrel Datwyler wrote: > On 01/24/2018 10:48 PM, Frank Rowand wrote: >> On 01/21/18 06:31, Wolfram Sang wrote: >>> From: Tyrel Datwyler >>> >>> This patch introduces event tracepoints for tracking a device_nodes >>> reference cycl

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

Hi Wolfram, On 01/25/18 03:03, Steven Rostedt wrote: > On Wed, 24 Jan 2018 22:55:13 -0800 > Frank Rowand <frowand.l...@gmail.com> wrote: > >> Hi Steve, > >> >> Off the top of your head, can you tell me know early in the boot >> process a trace_ev

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

Hi Wolfram, On 01/25/18 03:03, Steven Rostedt wrote: > On Wed, 24 Jan 2018 22:55:13 -0800 > Frank Rowand wrote: > >> Hi Steve, > >> >> Off the top of your head, can you tell me know early in the boot >> process a trace_event can be called and successfully p

Re: [PATCH] of: use hash based search in of_find_node_by_phandle

On 01/25/18 02:14, Chintan Pandya wrote: > of_find_node_by_phandle() takes a lot of time finding > right node when your intended device is too right-side > in the fdt. Reason is, we search each device serially > from the fdt, starting from left-most to right-most. Please give me a pointer to the

Re: [PATCH] of: use hash based search in of_find_node_by_phandle

On 01/25/18 02:14, Chintan Pandya wrote: > of_find_node_by_phandle() takes a lot of time finding > right node when your intended device is too right-side > in the fdt. Reason is, we search each device serially > from the fdt, starting from left-most to right-most. Please give me a pointer to the

Re: [RFC PATCH v2 1/1] of: introduce event tracepoints for dynamic device_node lifecyle

On 01/21/18 06:31, Wolfram Sang wrote: > From: Tyrel Datwyler > > This patch introduces event tracepoints for tracking a device_nodes > reference cycle as well as reconfig notifications generated in response > to node/property manipulations. > > With the recent

Re: [RFC PATCH v2 1/1] of: introduce event tracepoints for dynamic device_node lifecyle

On 01/21/18 06:31, Wolfram Sang wrote: > From: Tyrel Datwyler > > This patch introduces event tracepoints for tracking a device_nodes > reference cycle as well as reconfig notifications generated in response > to node/property manipulations. > > With the recent upstreaming of the refcount API

Re: [RFC PATCH v2 1/1] of: introduce event tracepoints for dynamic device_node lifecyle

On 01/25/18 00:01, Geert Uytterhoeven wrote: > Hi Frank, > > On Thu, Jan 25, 2018 at 7:48 AM, Frank Rowand <frowand.l...@gmail.com> wrote: >>> create mode 100644 include/trace/events/of.h >> >> mode looks incorrect. Existing files in include/trace/events/ are

Re: [RFC PATCH v2 1/1] of: introduce event tracepoints for dynamic device_node lifecyle

On 01/25/18 00:01, Geert Uytterhoeven wrote: > Hi Frank, > > On Thu, Jan 25, 2018 at 7:48 AM, Frank Rowand wrote: >>> create mode 100644 include/trace/events/of.h >> >> mode looks incorrect. Existing files in include/trace/events/ are -rw-rw > > Not in

Re: [RFC PATCH v2 1/1] of: introduce event tracepoints for dynamic device_node lifecyle

On 01/24/18 22:48, Frank Rowand wrote: > On 01/21/18 06:31, Wolfram Sang wrote: >> From: Tyrel Datwyler <tyr...@linux.vnet.ibm.com> >> >> This patch introduces event tracepoints for tracking a device_nodes >> reference cycle as well as reconfig notifications

Re: [RFC PATCH v2 1/1] of: introduce event tracepoints for dynamic device_node lifecyle

On 01/24/18 22:48, Frank Rowand wrote: > On 01/21/18 06:31, Wolfram Sang wrote: >> From: Tyrel Datwyler >> >> This patch introduces event tracepoints for tracking a device_nodes >> reference cycle as well as reconfig notifications generated in response >&g

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

Hi Steve, On 01/21/18 06:31, Wolfram Sang wrote: > I got a bug report for a DT node refcounting problem in the I2C subsystem. > This > patch was a huge help in validating the bug report and the proposed solution. > So, I thought I bring it to attention again. Thanks Tyrel, for the initial >

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

Hi Steve, On 01/21/18 06:31, Wolfram Sang wrote: > I got a bug report for a DT node refcounting problem in the I2C subsystem. > This > patch was a huge help in validating the bug report and the proposed solution. > So, I thought I bring it to attention again. Thanks Tyrel, for the initial >

Re: [RFC PATCH v2 1/1] of: introduce event tracepoints for dynamic device_node lifecyle

On 01/21/18 06:31, Wolfram Sang wrote: > From: Tyrel Datwyler > > This patch introduces event tracepoints for tracking a device_nodes > reference cycle as well as reconfig notifications generated in response > to node/property manipulations. > > With the recent

Re: [RFC PATCH v2 1/1] of: introduce event tracepoints for dynamic device_node lifecyle

On 01/21/18 06:31, Wolfram Sang wrote: > From: Tyrel Datwyler > > This patch introduces event tracepoints for tracking a device_nodes > reference cycle as well as reconfig notifications generated in response > to node/property manipulations. > > With the recent upstreaming of the refcount API

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

On 01/21/18 06:31, Wolfram Sang wrote: > I got a bug report for a DT node refcounting problem in the I2C subsystem. > This > patch was a huge help in validating the bug report and the proposed solution. > So, I thought I bring it to attention again. Thanks Tyrel, for the initial > work! > > Note

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

On 01/21/18 06:31, Wolfram Sang wrote: > I got a bug report for a DT node refcounting problem in the I2C subsystem. > This > patch was a huge help in validating the bug report and the proposed solution. > So, I thought I bring it to attention again. Thanks Tyrel, for the initial > work! > > Note

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

On 01/22/18 03:49, Wolfram Sang wrote: > Hi Frank, > >> Please go back and read the thread for version 1. Simply resubmitting a >> forward port is ignoring that whole conversation. >> >> There is a lot of good info in that thread. I certainly learned stuff in it. > > Yes, I did that and

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

On 01/22/18 03:49, Wolfram Sang wrote: > Hi Frank, > >> Please go back and read the thread for version 1. Simply resubmitting a >> forward port is ignoring that whole conversation. >> >> There is a lot of good info in that thread. I certainly learned stuff in it. > > Yes, I did that and

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

On 01/23/18 04:11, Michael Ellerman wrote: > Wolfram Sang writes: > >> Hi Frank, >> >>> Please go back and read the thread for version 1. Simply resubmitting a >>> forward port is ignoring that whole conversation. >>> >>> There is a lot of good info in that thread. I

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

On 01/23/18 04:11, Michael Ellerman wrote: > Wolfram Sang writes: > >> Hi Frank, >> >>> Please go back and read the thread for version 1. Simply resubmitting a >>> forward port is ignoring that whole conversation. >>> >>> There is a lot of good info in that thread. I certainly learned stuff in

<    1   2   3   4   5   6   7   8   9   10   >