All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dr. Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] About convert to LIVE DT
Date: Tue, 13 Feb 2018 12:20:28 +0100	[thread overview]
Message-ID: <8F5D7C40-1C6A-414B-858C-869F50FA5E15@theobroma-systems.com> (raw)
In-Reply-To: <39cd31d8-eecf-a433-f5ac-fbfc4ed7eff7@rock-chips.com>

Kever,

> On 13 Feb 2018, at 09:04, Kever Yang <kever.yang@rock-chips.com> wrote:
> 
> Simon,
> 
> 
> On 02/12/2018 10:35 PM, Simon Glass wrote:
>> Hi Kever,
>> 
>> On 4 February 2018 at 18:00, Kever Yang <kever.yang@rock-chips.com> wrote:
>>> 
>>> On 02/04/2018 09:40 PM, Simon Glass wrote:
>>>> Hi Kever,
>>>> 
>>>> On 4 February 2018 at 00:44, Kever Yang <kever.yang@rock-chips.com> wrote:
>>>>> Hi Simon, Philipp,
>>>>> 
>>>>>    When I try to convert to live dt, I fount there are many APIs work
>>>>> in fdt are missing in live dt,
>>>>> 
>>>>> do you have any suggestion to add these APIs in live dt quickly? I need:
>>>>> 
>>>>> fdtdec_get_addr_size_auto_noparent
>>>> dev_read_addr_size() - not having a parent doesn't happen with livetree
>>>> 
>>>>> fdt_alloc_phandle
>>>> We don't support changing the live tree yet.
>>>> 
>>>>> fdt_device_is_available
>>>> dev_read_enabled()
>>>> 
>>>>> fdt_for_each_subnode
>>>> dev_for_each_subnode()
>>>> 
>>>>> fdt_getprop
>>>> dev_read_prop()
>>>> 
>>>>> fdt_getprop_u32_default_node
>>>> This is an odd function. Can you first check that the property exists,
>>>> and then use a dev_read_...() function to read it?
>>>> 
>>>>> fdt_get_named_resource
>>>> dev_read_resource_byname()
>>>> 
>>>>> fdt_get_name
>>>> dev_read_name() - although I see that the comment is wrong
>>>> 
>>>>> fdt_get_path
>>>> Not available but you can add it
>>>> 
>>>>> fdt_get_phandle
>>>> Why do you need this?
>>> Most of the APIs are used in this file or other files in this folder,
>>> https://github.com/rockchip-linux/u-boot/blob/release/drivers/video/drm/rockchip_display.c
>>> It needs to handle quite complicated dts node for display system in
>>> rockchip drm display driver(not upstream yet):
>>> https://github.com/rockchip-linux/u-boot/blob/release/arch/arm/dts/rk3128.dtsi#L421
>>> https://github.com/rockchip-linux/u-boot/blob/release/arch/arm/dts/rk3126-bnd-d708.dts#L114
>> One difference I see with Linux is that U-Boot creates devices for all
>> nodes automatically, provided that they have a compatible string and
>> matching driver. This should simplify things in U-Boot.
>> 
>> The supernode-at-depth function looks like it just takes the parent of
>> the parent when an argument of -2 is used.
>> 
>> The existing rockchip driver in U-Boot handles a similar binding,
>> doesn't it? It has phandles and multiple nodes and subnodes.
> 
> Yes, but it does not able to migrate to support both live dt and fdt,
> because there is no same api in live dt, and here is what I do locally
> for live dt:
> 823                 phandle = ofnode_read_u32_default(node, "connect",
> -1);        
> 824                 if (phandle < 0)
> {                                             
> 825                         printf("Warn: can't find connect node's
> handle\n");    
> 826                        
> continue;                                              
> 827                
> }                                                              
> 828                 ep_node =
> of_find_node_by_phandle(phandle);                    
> 829                 if (!ofnode_valid(np_to_ofnode(ep_node)))
> {                    
> 830                         printf("Warn: can't find endpoint node from
> phandle\n");
> 831                        
> continue;                                              
> 832                
> }                                                              
> 833                 port_node =
> of_get_parent(ep_node);                            
> 834                 if (!ofnode_valid(np_to_ofnode(port_node)))
> {                  
> 835                         printf("Warn: can't find port node from
> phandle\n");   
> 836                        
> continue;                                              
> 837                
> }                                                              
> 838                 vop_node =
> of_get_parent(port_node);                           
> 839                 if (!ofnode_valid(np_to_ofnode(vop_node)))
> {                   
> 840                         printf("Warn: can't find crtc node from
> phandle\n");   
> 841                        
> continue;                                              
> 842                
> }                                                              
> 843                 ret =
> uclass_get_device_by_ofnode(UCLASS_VIDEO_CRTC,           
> 844                                                  
> np_to_ofnode(vop_node),      
> 845                                                   &crtc_dev);
> 
> In usb phy, we have similar requirement, but only need find "-1" depth
> parent.

Can you use dev_get_parent() to get the parent and then use dev_read_*()
on the parent?

> Thanks,
> - Kever
>> 
>>> Thanks,
>>> - Kever
>>>>> fdt_node_depth
>>>>> fdt_node_offset_by_phandle
>>>>> fdt_node_offset_by_phandle_node
>>>> uclass_get_device_by_phandle() or similar?
>>>> 
>>>>> fdt_path_offset
>>>> ofnode_path() although it does not return a device. Best avoided.
>>>> 
>>>>> fdt_set_phandle
>>>> You can't change the livtree at present.
>>>> 
>>>>> fdt_stringlist_get
>>>> dev_read_string_index()
>>>> 
>>>>> fdt_stringlist_search
>>>> dev_read_stringlist_search()
>>>> 
>>>>> fdt_subnode_offset
>>>> Why do you want that?
>>>> 
>>>>> fdt_supernode_atdepth_offset
>>>> This should be found by scanning, generally using separate drivers for
>>>> each DT node.
>>>> 
>>>> If you like you could send a patch with the info above, to
>>>> doc/driver-model/livetree.txt to help others.
>> Regards,
>> Simon

      reply	other threads:[~2018-02-13 11:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-04  7:44 [U-Boot] About convert to LIVE DT Kever Yang
2018-02-04 13:40 ` Simon Glass
2018-02-05  1:00   ` Kever Yang
2018-02-12 14:35     ` Simon Glass
2018-02-13  8:04       ` Kever Yang
2018-02-13 11:20         ` Dr. Philipp Tomsich [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8F5D7C40-1C6A-414B-858C-869F50FA5E15@theobroma-systems.com \
    --to=philipp.tomsich@theobroma-systems.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.