Electronic device and method for modularizing device driver, and non-transitory computer-readable recording medium

Abstract

An electronic device is disclosed. The electronic device may comprise: a display; at least one processor including a processing circuit; and a memory for storing instructions. The electronic device can: obtain a first input for displaying objects representing a plurality of hardware components, while displaying, through the display, a user interface for generating a device tree source (DTS); obtain a second input for connections between the objects; update first attributes of a device manual of each of the objects on the basis of the connections between the objects; update second attributes of a device tree source include (DTSI) of each of the objects on the basis of the updated device manual; and generate a DTS including the updated DTSI of each of the objects.

Description

Electronic device, method, and non-transitory computer-readable recording medium for modularizing a device driver

[0001] The following descriptions relate to electronic devices, methods, and non-transitory computer-readable recording media for modularizing device drivers.

[0002] A device tree may refer to a data structure that describes hardware components for the operating system's kernel to use or manage the hardware components.

[0003] A device tree source (DTS) is a file containing text written according to a common syntax for the kernel. A DTS may contain device tree source include (DTSI) for one or more devices. A DTS may represent one or more devices as tree nodes. A DTS may represent one or more devices, with child nodes of the root node (e.g., " / ") containing processors.

[0004] Embodiments may address the above technical issues.

[0005] An electronic device is disclosed. The electronic device may include a display, at least one processor including a processing circuit; and a memory storing instructions and including one or more storage media. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to obtain a first input for displaying a plurality of objects representing each of a plurality of hardware configurations while displaying a user interface (UI) for generating a device tree source (DTS) through the display. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to obtain a second input representing connections between the plurality of objects. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to update first properties of a device description of each of the plurality of objects based on the connections between the plurality of objects. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to update second properties of a device tree source include (DTSI) of each of the plurality of objects based on the updated device description. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to generate a DTS including the updated DTSI of each of the plurality of objects.

[0006] A method is disclosed. The method may be performed by an electronic device including a display. The method may include an operation of obtaining a first input for displaying a plurality of objects representing each of a plurality of hardware configurations while displaying a UI for generating a DTS through the display. The method may include an operation of obtaining a second input representing connections between the plurality of objects. The method may include an operation of updating first properties of a device description of each of the plurality of objects based on the connections between the plurality of objects. The method may include an operation of updating second properties of a DTSI of each of the plurality of objects based on the updated device description. The method may include an operation of generating a DTS including the updated DTSI of each of the plurality of objects.

[0007] A non-transitory computer-readable storage medium is disclosed. The non-transitory computer-readable storage medium may store a program including instructions. The instructions, when individually or collectively executed by at least one processor of an electronic device including a display, may cause the electronic device to obtain a first input for displaying a plurality of objects representing each of a plurality of hardware configurations while displaying a UI for generating a DTS through the display. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to obtain a second input representing connections between the plurality of objects. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to update first properties of a device description of each of the plurality of objects based on the connections between the plurality of objects. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to update second properties of the DTSI of each of the plurality of objects based on the updated device description. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to generate a DTS including the updated DTSI of each of the plurality of objects.

[0008] The subject-matter of the present disclosure will be fully understood with reference to the accompanying drawings.

[0009] FIG. 1 is a diagram illustrating a device tree source of each of the electronic devices (101, 103, 105).

[0010] Figure 2 is a block diagram of an electronic device (201).

[0011] FIG. 3 is a diagram illustrating an operation in which an electronic device (201) generates a DTSI (device tree source include).

[0012] FIG. 4 is a drawing showing a user interface (UI) for setting a connection relationship between hardware configurations displayed by an electronic device (201).

[0013] FIG. 5 is a drawing showing a UI for setting properties and values ​​between hardware configurations displayed by an electronic device (201).

[0014] FIG. 6a illustrates an example of a device tree managed by an electronic device (201).

[0015] Figure 6b is a diagram illustrating a portion of a device description of a GPIO (general purpose input output).

[0016] Figure 7a is a drawing illustrating a portion of a device description of an AP (application processor).

[0017] Figure 7b is a diagram illustrating a portion of the device description of I2C (inter integrated circuit).

[0018] Figure 7c is a drawing illustrating a portion of a device description of a Hall IC (integrated circuit).

[0019] Figure 7d is a diagram illustrating a portion of the updated device description of GPIO.

[0020] Figure 8 is a diagram illustrating a portion of the DTSI of the GPIO expander.

[0021] Figure 9 is a diagram illustrating a portion of wrapper code for updating DTSI of a GPIO expander.

[0022] Figure 10 is a diagram illustrating a portion of the updated DTSI of GPIO.

[0023] Figure 11 is a diagram illustrating a portion of the updated DTSI of GPIO.

[0024] Figure 12 is a diagram illustrating an operation of an electronic device generating a device tree source.

[0025] Figure 13 is a flowchart illustrating the operation of an electronic device.

[0026] Figure 14 is a block diagram of a server for providing a service for DTS generation to an electronic device.

[0027] Figure 15 is a block diagram of an electronic device within a network environment.

[0028] FIG. 1 is a diagram illustrating a device tree source of each of the electronic devices (101, 103, 105).

[0029] Referring to FIG. 1, each of the electronic devices (101, 103, 105) may include different processors (111, 131, 151). Each of the electronic devices (101, 103, 105) may include identical components (113, 115, 117). For example, each of the components (113, 115, 117) may be an interface (e.g., a bus, a general purpose input and output (GPIO), a serial peripheral interface (SPI), or a mobile industry processor interface (MIPI)), and / or a hardware configuration (e.g., a memory, a battery, a communication circuit, a sensor, a camera, and / or an audio module). However, the present invention is not limited thereto.

[0030] Each of the electronic devices (101, 103, 105) may include a device tree source (DTS) (121, 123, 125) for smooth operation of the processors (111, 131, 151) and components (113, 115, 117).

[0031] Since each of the electronic devices (101, 103, 105) includes different processors (111, 131, 151), the developer of the electronic devices (101, 103, 105) must create a device tree source include (DTSI) for each of the components (113, 115, 117). In other words, when the developer creates a DTS for the electronic devices (101, 103, 105), the developer of the electronic devices (101, 103, 105) must create a DTSI for each of the components (113, 115, 117) due to some grammar (e.g., pin configuration) for which no common standard exists. For example, the developer must create DTSIs (143, 163, 183) for each of the components (113). Additionally, for example, the developer must create DTSIs (145, 165, 185) for component (115), respectively. Additionally, for example, the developer must create DTSIs (147, 167, 187) for component (117), respectively.

[0032] Since DTSI uses a different custom syntax for each device's pin configuration, device driver developers will have to write a new DTSI according to the device's pin configuration syntax each time a model is developed. This is not only inefficient because developers have to duplicate the same code with different syntaxes, but also inconvenient because they have to know all the custom pin configuration syntaxes for each device. This problem is an obstacle for manufacturers developing many models with various chipsets to increase development efficiency through device modularization. This well-known development method of using a device module's DTS based on each model is not only inefficient but also error-prone because the development models are diverse and each model requires device driver developers to write the same code multiple times in the development environment.

[0033] As discussed above, when the same components are incorporated into a large number of electronic devices with different processors, the burden on developers to create DTSIs included in DTSs may increase. Therefore, a method may be needed to reduce the burden on developers to create DTSIs included in DTSs.

[0034] Hereinafter, referring to FIGS. 2 through 14, a method for reducing the difficulty of writing DTSIs is described. In the description below, the features described with respect to examples within parentheses are interpreted as optionally including having, including, or consisting of all, some, or one of such examples.

[0035] Figure 2 is a block diagram of an electronic device (201).

[0036] Referring to FIG. 2, the electronic device (201) may include a memory (210), a processor (220), a communication circuit (230), an input module (240), and a display (250).

[0037] In one embodiment, the memory (210) may (at least temporarily) store instructions for executing operations of the electronic device (201) exemplified in the description of FIG. 13. The instructions may be executed by the processor (220). The instructions may be included in one or more programs stored in the memory (210). For example, the memory (210) may include at least a portion of the memory (1530) of FIG. 15 (or at least a portion of the non-volatile memory (1534)) or may correspond to at least a portion of the memory (1530) of FIG. 15 (or at least a portion of the non-volatile memory (1534)). For example, the memory (210) may include a main memory (e.g., a random access memory (RAM)) within the electronic device (201), a register for the processor (220), a cache for the processor (220), a register for the communication circuit (230), a buffer (or soft buffer) for the communication circuit (230), and / or an auxiliary memory (e.g., a hard disk drive (HDD), a solid state drive (SSD)) of the electronic device (201). For example, the memory (210) may be implemented as a single chip or may be implemented as multiple chips. For example, the memory (210) may be implemented as one integrated circuit or may be implemented as multiple integrated circuits. For example, the memory (210) may be distributedly arranged within the electronic device (201).

[0038] In one embodiment, the processor (220) may be used to execute the operations of the electronic device (201) exemplified in the description of FIG. 13. For example, the processor (220) may include at least a portion of the processor (1520) of FIG. 15 or may correspond to at least a portion of the processor (1520) of FIG. 15. For example, the processor (220) may include one or more processors, including an application processor (AP) and / or a communication processor (CP). For example, the processor (220) may be implemented as a single chip, such as a system on chip (SoC), or may be implemented as multiple chips. For example, the processor (220) may be implemented as a single integrated circuit or may be implemented as multiple integrated circuits. For example, the processor (220) may be distributedly arranged within the electronic device (201).

[0039] In one embodiment, the communication circuit (230) may be used to support wireless communication between the electronic device (201) and another electronic device. For example, the communication circuit (230) may include at least a portion of the communication module (1590) (or the wireless communication module (1592)) of FIG. 15, or may correspond to at least a portion of the communication module (1590) (or the wireless communication module (1592)) of FIG. 15. For example, the communication circuit (230) may include a communication circuit for a long-distance communication network. For example, the communication circuit (230) may be used to establish a communication link. For example, the communication circuit (230) may be implemented as a single chip or as multiple chips. For example, the communication circuit (230) may be implemented as a single integrated circuit or as multiple integrated circuits. For example, the communication circuit (230) may be distributed within the electronic device (201).

[0040] In one embodiment, the input module (240) may be used to obtain (or receive) user input from an external source (e.g., a user) of the electronic device (201). The input module (240) may be, for example, a microphone, a mouse, a keyboard, a key (e.g., a button), or a digital pen (e.g., a stylus pen), but is not limited thereto.

[0041] In one embodiment, the display (250) may include at least a portion of the display module (1560) of FIG. 15, or may correspond to at least a portion of the display module (1560) of FIG. 15. In one embodiment, the display (250) may display a user interface (UI) (e.g., UI (400) of FIG. 4). In one embodiment, the UI (e.g., UI (400) of FIG. 4) may be a UI for generating a device tree source (DTS) (or an execution screen of an application).

[0042] Referring to FIG. 2, the memory (210) may include a device description (260), a DTSI (device tree source include) (265), a device description update module (270), a DTSI update module (280), and a DTS (device tree source) generation module (290).

[0043] In one embodiment, the device description (260) may be a dictionary-type data file consisting of key (or attribute)-value pairs. In one embodiment, the device description (260) may include a plurality of objects. For example, the plurality of objects may include a header, a build, and an interface.

[0044] In one embodiment, the header may include information about the hardware configuration described in the device documentation (260), such as name, unique identification information, and manufacturer information.

[0045] In one embodiment, the build may include mapping information with the kernel of the processor (220). For example, the build may include information on the location of the repository of the source code of the hardware configuration ('path'), information indicating the file name of the device description (260) ('file'), and information related to the file ('location'). For example, the information related to the file ('location') may include information on a file required to build the driver source code of the hardware configuration (or a file to be copied) ('src') and a copy location of the file ('dst').

[0046] In one embodiment, the interface may include input information ('inports') and output information ('outports') of pins required in the DTSI (265). In one embodiment, each of the input information ('inports') and output information ('outports') of the interface may include connection type information ('type') and port information ('labels'). In one embodiment, the port information ('labels') may include a name of the port ('label'), a symbol ('symbol'), and a parent ('parent') indicating a symbol to be used as a (parent) phandle in the device tree.

[0047] In one embodiment, DTSI (265) may be an include file included in a DTS file. For example, DTSI (265) may include SoC-level definitions. For example, DTSI (265) may be a file created based on the grammar of a device tree. For example, the device tree may be a tree structure that includes kernel-level information about a hardware configuration. For example, the device tree may include characteristics of a hardware configuration, connections between hardware configurations, and / or configuration information of a hardware configuration.

[0048] In one embodiment, the DTSI (265) (or DTS (device tree source)) can be written based on its own grammar. A common standard grammar may not be traditionally possible for pin configuration nodes (e.g., nodes representing input information ('inports') and / or output information ('outports')). The pin configuration nodes of hardware configurations refer to the pin configuration contents of the pin control device (e.g., AP, SoC). Accordingly, even if the hardware configuration is the same, the context (or settings and / or values) of the pin configuration nodes may be different depending on the AP (or SoC) that controls the hardware configuration. Therefore, a standardized grammar for the pin configuration nodes may be required for modularized DTSI (265). For this purpose, a wrapper code (e.g., a configuration wrapper macro) may be used. For example, wrapper code can be written for each AP (or vendor of APs) that has the same pin configuration grammar (or syntax). Wrappers can also include code that provides interfaces to other components, typically to facilitate the convenient merging and interaction of wrapped functions.

[0049] In one embodiment, the device description update module (270) may update the device description (260) based on input. For example, the input may be input obtained through the input module (240).

[0050] In one embodiment, the DTSI update module (280) can update the DTSI (265) based on the updated device description (320). In one embodiment, the DTS generation module (290) can generate a DTS including the updated DTSI (265).

[0051] Hereinafter, with reference to FIGS. 3 to 12, the operation of the electronic device (201) generating DTS will be described.

[0052] FIG. 3 is a diagram illustrating an operation of an electronic device (201) generating a device tree source include (DTSI). FIG. 4 is a diagram illustrating a user interface (UI) for setting a connection relationship between hardware configurations displayed by the electronic device (201). FIG. 5 is a diagram illustrating a UI for setting properties and values ​​between hardware configurations displayed by the electronic device (201).

[0053] Referring to FIG. 3, the device description update module (270) can update the device description (260) of each hardware configuration based on the input (310). For example, the input (310) may be an input obtained through the input module (240). For example, the input (310) may be a touch input obtained through the display (250). However, the present invention is not limited thereto.

[0054] For example, referring to FIG. 4, the device description update module (270) can obtain an input (310) for a UI (400) being displayed through the display (250). For example, the input (310) can include an input (e.g., drag and drop) for placing at least one object on the UI (400). For example, the object can include an object (410) representing a hardware configuration for connection (e.g., a general purpose input output (GPIO) expander), an object (420) representing an application processor (AP), an object (430) representing a hardware configuration for connection (e.g., a software (SW) inter integrated circuit (I2C)), or an object (440) representing a sensor (e.g., a Hall IC (integrated circuit)). For example, the input (310) can be an input for connecting objects. For example, input (310) may be an input for creating a connection (411) between an object (410) and an object (420). For example, input (310) may be an input for creating a connection (413) between an object (420) and an object (430). For example, input (310) may be an input for creating a connection (415) between an object (420) and an object (440). However, the present invention is not limited thereto.

[0055] For example, the device description update module (270) can create a connection (411) between an inport (e.g., a GPIO pin) of an object (410) and an outport (e.g., a GPIO pin) of an object (420) through an input (310). For example, referring to FIG. 5, the device description update module (270) can display a UI (501) for setting properties of the connection (411) based on the creation of the connection (411). For example, the device description update module (270) can update properties and / or values ​​of the object (410) of the device description (260) based on the input (310) obtained through the UI (501).

[0056] For example, the device description update module (270) can add (or update) a statement for an attribute ('usrval') and a value ('tlmm-122') to an import object (e.g., RESET: GPIO expander) of the device description (260) associated with the object (410) via an input (310) to the UI (501).

[0057] For example, the device description update module (270) can update the device description (260) so that the value ('${AAA_reset_gpio_parent}') of the attribute ('parent') of an inport object (e.g., RESET: GPIO expander) of the device description (260) related to the object (410) references the value ('tlmm') of the attribute ('parent') of an object that includes the value ('tlmm-122') of the attribute ('label') among the outport objects of another device description related to the object (420), through an input (310) to the UI (501).

[0058] For example, the device description update module (270) can update the device description (260) so that the value ('${AAA_reset_gpio}') of the attribute ('symbol') of an inport object (e.g., RESET: GPIO expander) of the device description (260) related to the object (410) references the value ('AP,tlmm,122') of the attribute ('value') of an object that includes the value ('tlmm-122') of the attribute ('label') among the outport objects of another device description related to the object (420), through an input (310) to the UI (501).

[0059] For example, the device description update module (270) can add (or update) a sentence for an attribute ('usrval') and a value ('tlmm-51) to an import object (e.g., IRQ: GPIO expander) of the device description (260) associated with the object (410) via an input (310) to the UI (501).

[0060] For example, the device description update module (270) can update the device description (260) through an input (310) to the UI (501) so that the value ('${AAA_irq_gpio_parent}') of the attribute ('parent') of an inport object (e.g., IRQ: GPIO expander) of the device description (260) related to the object (410) refers to the value ('tlmm') of the attribute ('parent') of an object that includes the value ('tlmm-51') of the attribute ('label') among the outport objects of another device description related to the object (420).

[0061] For example, the device description update module (270) can update the device description (260) so that the value ('${AAA_irq_gpio}') of the attribute ('symbol') of an inport object (e.g., IRQ: GPIO expander) of the device description (260) related to the object (410) references the value ('AP,tlmm,122') of the attribute ('value') of an object that includes the value ('tlmm-51') of the attribute ('label') among the outport objects of another device description related to the object (420), through an input (310) to the UI (501).

[0062] For example, the device description update module (270) can create a connection (413) between an inport (e.g., an I2C pin) of an object (410) and an outport (e.g., an I2C pin) of an object (430) through an input (310). For example, referring to FIG. 5, the device description update module (270) can display a UI (503) for setting properties of the connection (413) based on the creation of the connection (413). For example, the device description update module (270) can update properties and / or values ​​of an object (410) of the device description (260) based on the input (310) obtained through the UI (503).

[0063] For example, the device description update module (270) can add (or update) a sentence for an attribute ('usrval') and a value ('sw-i2c_3') to an import object (e.g., IRQ: GPIO expander) of the device description (260) associated with the object (410) via an input (310) to the UI (503).

[0064] For example, the device description update module (270) can update the device description (260) so that the value ('${AAA_i2c}') of the attribute ('symbol') of an inport object (e.g., I2C: GPIO expander) of the device description (260) related to the object (410) references the value ('sw_i2c_3') of the attribute ('symbol') of an object that includes the value ('sw-i2c') of the attribute ('label') among the outport objects of another device description related to the object (430), through an input (310) to the UI (503).

[0065] For example, the device description update module (270) can create a connection (415) between an outport (e.g., a GPIO pin) of an object (410) and an inport (e.g., a GPIO pin) of an object (440) through an input (310). For example, referring to FIG. 5, the device description update module (270) can display a UI (505) for setting properties of the connection (415) based on the creation of the connection (415). For example, the device description update module (270) can update properties and / or values ​​of the object (410) and the object (440) of the device description (260) based on the input (310) obtained through the UI (505).

[0066] For example, the device description update module (270) can add (or update) a sentence for an attribute ('usrval') and a value ('expander-p1_1') to an import object (e.g., GPIO: HALL) of another device description associated with the object (440) via an input (310) to the UI (505).

[0067] For example, the device description update module (270) can update another device description associated with the object (440) through an input (310) to the UI (505) such that the value ('${hall_parent}') of the attribute ('parent') of an inport object (e.g., GPIO: HALL) of another device description associated with the object (440) refers to the value ('gpio_expander') of the attribute ('parent') of an object that includes the value ('expander-p1_1') of the attribute ('label') among the outport objects of the device description (260) associated with the object (410).

[0068] For example, the device description update module (270) can update another device description associated with the object (440) through an input (310) to the UI (505) such that the value ('${hall_gpio}') of the attribute ('symbol') of an inport object (e.g., IRQ: GPIO: HALL) of the device description (260) associated with the object (410) refers to the value ('EXP, gpio_expander, 9') of the attribute ('value') of an object that includes the value ('expander-p1_1') of the attribute ('label') among the outport objects of the device description (260) associated with the object (410).

[0069] Hereinafter, the property of the device description (260) that the device description update module (270) updates based on the connections (411, 413, 415) between objects (410, 420, 430, 440) may be referred to as the first property.

[0070] In one embodiment, the DTSI update module (280) may update the DTSI (265) based on the updated device description (320). In one embodiment, the DTSI update module (280) may change the values ​​of the attributes of the DTSI (265) to the values ​​of the attributes included in the updated device description (320).

[0071] For example, the DTSI update module (280) can update the value ('${AAA_irq_gpio_parent}') of the DTSI (265) to the value ('tlmm') included in the updated device description (320). For example, the DTSI update module (280) can update the value ('${AAA_irq_gpio}') of the DTSI (265) to the value ('AP,tlmm,122') included in the updated device description (320). For example, the DTSI update module (280) can update the value ('${AAA_i2c}') of the DTSI (265) to the value ('sw_i2c_3') included in the updated device description (320).

[0072] For example, the DTSI update module (280) can update the value of another DTSI ('${hall_parent}') of the object (440) with the value ('gpio_expander') included in the updated device description (320). For example, the DTSI update module (280) can update the value of another DTSI ('${hall_gpio}') of the object (440) with the value ('EXP, gpio_expander, 9') included in the updated device description (320).

[0073] Hereinafter, the attribute of the DTSI (265) that the DTSI update module (280) updates by referencing the attribute (or value of the attribute) of the updated device description (320) may be referred to as a second attribute.

[0074] For example, the DTSI update module (280) can update the DTSI (265) through the updated device description (320) and then additionally update it through a wrapper. For example, the DTSI update module (280) can additionally update the DTSI (265) with updated values ​​through the wrapper. For example, the DTSI update module (280) can update the DTSI (265) with updated values ​​based on the wrapper, based on the build of the driver (or driver source code) for the object (410). The operation of the DTSI update module (280) updating the DTSI (265) through the wrapper can be described below with reference to FIGS. 8 to 11.

[0075] Hereinafter, the property of DTSI (265) that the DTSI update module (280) updates through the wrapper may be referred to as a third property.

[0076] In one embodiment, the DTS generation module (290) may generate a DTS file containing updated DTSIs (330) generated via the DTSI update module (280). For example, as the DTS file is built, a device tree blob (DTB) may be generated.

[0077] As described above, the electronic device (201) can set (or update) the attribute values ​​of the device description (260) of each hardware configuration by connecting the hardware configurations using a block coding technique. In addition, the electronic device (201) can update the DTSI (265) of each hardware configuration by using the updated attribute values ​​of the device description (260) of each of the set hardware configurations. Accordingly, the developer (or user) can more conveniently create the DTSI of each hardware configuration connected to different APs through simple input (e.g., drag and drop). Accordingly, the electronic device (201) can reduce the burden on the developer (or user) of having to create a new DTSI when developing a product.

[0078] As described above, the electronic device (201) can modularize the DTSI by declaring the values ​​of attributes (e.g., GPIO, I2C) that require reference to different information for each AP (or vendor) as symbols (e.g., ${AAA reset_gpio_parent}, ${AAA_reset_gpio}, ${AAA_i2c}) and then referencing the information (or values) (e.g., tlmm, pinctrl_0) required for each connected hardware configuration.

[0079] Fig. 6a illustrates an example of a device tree managed by an electronic device (201). Fig. 6b is a diagram illustrating a portion of a device description of a GPIO (general purpose input output).

[0080] Referring to the device tree (600) of FIG. 6A, nodes for multiple device drivers may be located in subnodes of the device node. For example, nodes for multiple device drivers may be located in independent nodes other than subnodes of the AP (or AP kernel). For example, nodes for multiple device drivers may be located in subnodes of sibling nodes of the AP (or AP kernel) node. In order to build a device tree (600) having such a structure, connection information with the AP kernel and device descriptions (260) for each of the device drivers may be required. By adopting a device tree (600) having such a structure, fragmentation of source code (e.g., DTS) may be reduced (or prevented), and ease of management may be increased.

[0081] Referring to FIG. 6b, the device description (260) may include a header, a build, and an interface.

[0082] In one embodiment, the header may include information about the hardware configuration described in the device documentation (260), such as name (e.g., AAA GPIO), unique identification information (uuid), and manufacturer information (vendor).

[0083] In one embodiment, the build (641) may include mapping information with the kernel of the processor (220) (or the AP kernel of FIG. 6A). For example, the build (641) may include information on the location of the repository of the source code of the hardware configuration ('path' and 'pgio / DDD / '), information indicating the file name of the device description (260) ('file' and 'EEE.py'), and information related to the file ('location'). For example, the information related to the file ('location') may include information on a file required to build the driver source code of the hardware configuration (or a file to be copied) ('src') and a copy location of the file ('dst').

[0084] In one embodiment, the interface may include input information ('inports') and output information ('outports') of pins required in the DTSI (265). In one embodiment, each of the input information ('inports') and output information ('outports') of the interface may include connection type information ('type') and port information ('labels'). In one embodiment, the port information ('labels') may include a name of the port ('label'), a symbol ('symbol'), and a parent ('parent') indicating a symbol to be used as a (parent) phandle in the device tree. For example, the interface may include port information (611) for RESET: GPIO expander, port information (613) for IRQ: GPIO expander, port information (621) for I2C: GPIO expander, and port information (631) for expander_p1_1.

[0085] Figure 7a is a drawing illustrating a portion of a device description of an AP (application processor).

[0086] Figure 7a illustrates a portion of the interface in the device description of the AP.

[0087] In one embodiment, the interface (701) of the device description of the AP may include pin output information ('outports') required in the DTSI. In one embodiment, each of the output information ('outports') of the interface (701) may include connection type information ('type') and port information ('labels'). In one embodiment, the port information ('labels') may include a name of the port ('label'), a parent ('parent') indicating a symbol to be used as a (parent) phandle in the device tree, and a value ('value'). For example, the interface (701) may include port information (711) for tlmm_122 and port information (715) for tlmm_51.

[0088] Figure 7b is a diagram illustrating a portion of the device description of I2C (inter integrated circuit).

[0089] Figure 7b illustrates a portion of the interface in the device description of I2C.

[0090] In one embodiment, the interface (703) of the device description of I2C may include output information ('outports') of pins required in DTSI. In one embodiment, each output information ('outports') of the interface (703) may include connection type information ('type') and port information ('labels'). In one embodiment, the port information ('labels') may include the name of the port ('label') and a value ('value'). For example, the interface (703) may include port information (721) for sw-i2c.

[0091] Figure 7c is a drawing illustrating a portion of a device description of a Hall IC (integrated circuit).

[0092] Figure 7c illustrates a portion of the interface in the device description of the Hall IC.

[0093] In one embodiment, the interface (705) of the device description of the Hall IC may include input information ('inports') of pins required in the DTSI. In one embodiment, each input information ('inports') of the interface (705) may include connection type information ('type') and port information ('labels'). In one embodiment, the port information ('labels') may include a name ('label') of the port, a symbol ('symbol'), and a parent ('parent') indicating a symbol to be used as a (parent) phandle in the device tree. For example, the interface (705) may include port information (731) for GPIO: HALL. For example, the interface (705) may have a sentence (735) added for an attribute ('usrval') and a value ('expander-p1-1') based on the connection between the Hall IC and the GPIO expander.

[0094] Figure 7d is a diagram illustrating a portion of the updated device description of GPIO.

[0095] FIG. 7d may illustrate an updated device description (320) based on the device description according to FIGS. 7a to 7c.

[0096] For example, the updated device description (320) can be updated by the connection between the GPIO expander and the AP, the connection between the GPIO expander and the SW I2C, and the connection between the GPIO expander and the Hall IC.

[0097] Referring to FIG. 7d, an updated device description (320) associated with an object (410) may add a statement (741) for an attribute ('usrval') and a value ('tlmm-122') to an import object (e.g., RESET: GPIO expander). For example, an updated device description (320) associated with an object (410) may add a statement (743) for an attribute ('usrval') and a value ('tlmm-51) to an import object (e.g., IRQ: GPIO expander). For example, an updated device description (320) associated with an object (410) may add a statement (745) for an attribute ('usrval') and a value ('sw-i2c_3') to an import object (e.g., IRQ: GPIO expander).

[0098] Figure 8 is a diagram illustrating a portion of the DTSI of the GPIO expander.

[0099] Referring to FIG. 8, DTSI (265) may include attributes (or symbols). For example, attributes may be updated through updated device descriptions (320) and / or wrapper code. For example, attributes may be statements declared as symbols.

[0100] For example, the properties updated through the updated device description (320) may include ${AAA_reset_gpio_parent}(810), ${AAA_i2c}(830), and ${AAA_reset_gpio}(860, 880). Here, AAA may be the name of a GPIO expander. For example, the properties updated through the updated device description (320) may be organized as shown in Table 1 below.

[0101] Symbol 1st value 2nd value ${AAA_reset_gpio_parent}tlmmpinctrl_0${AAA_reset_gpio}AP,tlmm,122AP,gpf1,gpf1,0${AAA_i2c}sw_i2c3hsi2c_0

[0102] In Table 1, the first value or the second value may be the values ​​of properties indicated by objects (420, 430, 440) connected to the object (410) that are referenced by the symbol (e.g., ${AAA_reset_gpio_parent}) of the object (410). For example, when the object (410) is connected to the object (420) of the first AP (or, first vendor) through the input (310) for the UI (501), the value ('${AAA_reset_gpio_parent}') of the device description (260) may refer to the first value, not the second value. For example, through the input (310) to the UI (501), as the object (410) is connected to an object of the second AP (or, second vendor), the value ('${AAA_reset_gpio_parent}') of the device description (260) may refer to a second value rather than the first value. For example, the device description update module (270) may refer to a value corresponding to identification information (e.g., uuid) of the hardware configuration indicated by the object (420, 430, 440) connected to the object (410) or vendor information (e.g., vendor). However, the present invention is not limited thereto.

[0103] For example, properties updated through wrapper code may include GPIO_CONFIG_PUD_DRV(820), FUNC_OUTPUT_HIGH, PULL_NONE, DRV_LV1(870), &expander_reset_active(850), and SEC-GPIO_REF(850). Updating properties through wrapper code may be described with reference to FIGS. 9 to 11.

[0104] Figure 9 is a diagram illustrating a portion of wrapper code for updating the DTSI of a GPIO expander. Figure 10 is a diagram illustrating a portion of the updated DTSI of a GPIO. Figure 11 is a diagram illustrating a portion of the updated DTSI of a GPIO.

[0105] Referring to FIG. 9, for a DTSI (265) of an arbitrary hardware configuration (e.g., a GPIO expander), there may be wrapper codes (901, 905) for each of hardware configurations (e.g., multiple APs, multiple Hall ICs, multiple I2Cs) that can be connected to the arbitrary hardware configuration. For example, the wrapper code (901) may be a wrapper code for a connection between the arbitrary hardware configuration (e.g., a GPIO expander) and a first AP. For example, the wrapper code (905) may be a wrapper code for a connection between the arbitrary hardware configuration (e.g., a GPIO expander) and a second AP. However, the present invention is not limited thereto. For example, the wrapper code (901) may be a wrapper code set for a manufacturer of the first AP connected to the arbitrary hardware configuration (e.g., a GPIO expander). For example, the wrapper code (905) may be a wrapper code set for the manufacturer of the second AP connected to an arbitrary hardware configuration (e.g., a GPIO expander). For example, the DTSI update module (280) may determine a wrapper code corresponding to identification information (e.g., uuid) of a hardware configuration indicated by an object (420, 430, 440) connected to the object (410) among a plurality of wrapper codes (901, 905) for the object (410) or vendor information (e.g., vendor).

[0106] Referring to the wrapper codes (901, 905) of FIG. 9, it can be defined (#define) that an attribute (e.g., PIN_AP_FUNC_OUTPUT_HIGH) is replaced with a specified value (e.g., gpio, or 0x1).

[0107] When comparing the wrapper codes (901, 905) of FIG. 9, the substituted values ​​for the same attribute may be different from each other. For example, the substituted values ​​(911, 915) for the attribute (850) of the wrapper codes (901, 905) may be different from each other. For example, the substituted values ​​(931, 935) for the attribute (930) of the wrapper codes (901, 905) may be different from each other. However, this is not limited thereto. When comparing the wrapper codes (901, 905) of FIG. 9, the substituted values ​​for the same attribute may be the same from each other. For example, the substituted values ​​(921) for the attribute (820) of the wrapper codes (901, 905) may be the same from each other.

[0108] Comparing the wrapper codes (901, 905) of FIG. 9, the number of times a value is substituted for the same attribute may be different. For example, the number of times a value is substituted for an attribute (850) of the wrapper code (901) may be once, and the number of times a value is substituted for an attribute (850) of the wrapper code (905) may be twice. For example, the attribute (850) of the wrapper code (901) may be directly substituted with a value (911), while the attribute (850) of the wrapper code (905) may be substituted with a value (915), and then the value (915) may be finally substituted with another value (945) by the attribute (940) and another value (945).

[0109] The updated DTSI (265) of FIG. 10 may be an updated DTSI through an updated device description (320) and wrapper code (901).

[0110] Referring to FIG. 10, it can be seen that ${AAA_reset_gpio_parent}(810), ${AAA_i2c}(830), and ${AAA_reset_gpio}(860, 880) are replaced with tlmm(1011), sw_i2c3(1015), and tlmm 122(1019), respectively, by the updated device description (320).

[0111] Referring to FIG. 10, by the wrapper code (901), the attribute (820), the attribute (870), and the value (931) substituted from the value (e.g., the value (tlmm 122) substituted from ${AAA_reset_gpio}(860)) are replaced with the attributes (mux, config, pins, function, drive-strength, output, bias) and values ​​(gpio122, gpio, <2> , high, disable) can be seen to be replaced with an object (1013).

[0112] The updated DTSI (1101) of FIG. 11 may be an updated DTSI through an updated device description (320) and wrapper code (905).

[0113] Referring to FIG. 11, it can be seen that ${AAA_reset_gpio_parent}(810), ${AAA_i2c}(830), and ${AAA_reset_gpio}(860, 880) are replaced with pinctrl_3(1111), hsi2c_0(1115), and gpf1 0(1019), respectively, by the updated device description (320).

[0114] Referring to FIG. 11, by the wrapper code (905), the attribute (820), the attribute (870), and the value (935) substituted from the value (e.g., the value (gpf1 0) substituted from ${AAA_reset_gpio}(860)) are replaced with the attributes (pins, pin-function, pin-pud, pin-drv) and values ​​(gpf1-0, <0x1>, <0> , it can be seen that it is replaced with an object (1113) containing <0x0>.

[0115] As described above, the electronic device (201) can reduce the resource input of a developer (or user) required to create a DTSI (265) such as FIG. 10 and a DTSI (1101) such as FIG. 11. For example, by inputting (310) for selection (or drag and drop) of objects (410, 420, 430, 440) through UI (400) and connection (411, 413, 415) between objects (410, 420, 430, 440) and inputting (310) for definition of properties of connections (411, 413, 415) through UIs (501, 503, 505), a DTSI (265) as in FIG. 10 and a DTSI (1101) as in FIG. 11 are created, thereby reducing the effort of a developer (or user) required to create DTSIs of GPIO expanders connected to different APs.

[0116] Figure 12 is a diagram illustrating an operation of an electronic device generating a device tree source.

[0117] Referring to FIG. 12, in the first situation (1210), the electronic device (201) can store the device description of AP A, the DTSI of AP A, the device description of device B, the DTSI of device B, the device description of device C, the DTSI of device C, the device description of device D, and the DTSI of device D.

[0118] In a first situation (1210), the electronic device (201) may obtain an input (310) for updating device manuals. In one embodiment, the input (310) may be an input for selecting (e.g., dragging and dropping) an object representing AP A (e.g., object (420)), an object representing device B (e.g., object (410)), an object representing device C (e.g., object (430)), and an object representing device D (e.g., object (440)) through the UI (400). In one embodiment, the input (310) may be an input for creating a connection (e.g., connection (411, 413, 415)) between an object representing AP A (e.g., object (420)), an object representing device B (e.g., object (410)), an object representing device C (e.g., object (430)), and an object representing device D (e.g., object (440)) through the UI (400). In one embodiment, input (310) may be an input that sets properties and values ​​for each of the connections (e.g., connections (411, 413, 415)) via UIs (501, 503, 505).

[0119] In the second situation (1220), the electronic device (201) can generate updated device descriptions as the update of the device descriptions is completed.

[0120] In a second situation (1220), the electronic device (201) can update DTSIs based on updated device descriptions. For example, the electronic device (201) can update properties of the DTSIs through updated device descriptions and / or wrapper codes. For example, a wrapper code for updating a DTSI can be identified by connected hardware configurations among a plurality of wrapper codes for the DTSI. For example, the electronic device (201) can update the DTSI of the B device (e.g., the GPIO expander) based on the wrapper code for the B device (e.g., the GPIO expander) and the A AP, and the wrapper code for the B device (e.g., the GPIO expander) and the XXX AP by connection (411).

[0121] In the third situation (1230), the electronic device (201) can generate updated DTSIs as the update of the DTSIs is completed.

[0122] In a fourth situation (1240), the electronic device (201) may generate a device tree source (1250) based on the updated DTSIs. For example, the electronic device (201) may generate a device tree source (1250) including updated DTSIs corresponding to hardware configurations included in the product and connections between the hardware configurations.

[0123] Figure 13 is a flowchart illustrating the operation of an electronic device.

[0124] Fig. 13 can be explained with reference to Figs. 2 to 5.

[0125] Some of the operations in Fig. 13 may be omitted in some cases. Some of the operations in Fig. 13 may be performed in different orders.

[0126] Referring to FIG. 13, in operation 1310, the electronic device (201) may obtain an input for connecting devices. For example, the input (310) may be an input obtained through the input module (240). For example, the input (310) may be a touch input obtained through the display (250). However, the present invention is not limited thereto.

[0127] In one embodiment, the electronic device (201) may obtain an input (310) for a UI (400) being displayed through the display (250). For example, the input (310) may include an input (e.g., drag and drop) for placing at least one object on the UI (400). For example, the object may include an object (410) representing a hardware configuration for connection (e.g., a general purpose input output (GPIO) expander), an object (420) representing an application processor (AP), an object (430) representing a hardware configuration for connection (e.g., a software (SW) inter integrated circuit (I2C)), or an object (440) representing a sensor (e.g., a Hall IC (integrated circuit)). For example, the input (310) may be an input for connecting objects. For example, input (310) may be an input for creating a connection (411) between an object (410) and an object (420). For example, input (310) may be an input for creating a connection (413) between an object (420) and an object (430). For example, input (310) may be an input for creating a connection (415) between an object (420) and an object (440). However, the present invention is not limited thereto.

[0128] In operation 1320, the electronic device (201) may obtain input for determining values ​​of properties between connected devices.

[0129] For example, the electronic device (201) may identify an input (310) for a connection (411) between an inport (e.g., a GPIO pin) of an object (410) and an outport (e.g., a GPIO pin) of an object (420). For example, the input (310) for the UI (501) may be an input for updating properties and values ​​in an inport object (e.g., RESET: GPIO expander, IRQ: GPIO expander) of a device description (260) associated with the object (410).

[0130] For example, the electronic device (201) may identify an input (310) for a connection (413) between an inport (e.g., an I2C pin) of an object (410) and an outport (e.g., an I2C pin) of an object (430). For example, the input (310) to the UI (503) may add (or update) statements for properties and values ​​to an inport object (e.g., IRQ: GPIO expander) of a device description (260) associated with the object (410).

[0131] In operation 1330, the electronic device (201) may update DTSIs based on the values ​​of the connections and properties between the devices. For example, the electronic device (201) may update DTSIs based on the updated device description (320) based on the values ​​of the connections and properties between the devices. For example, the electronic device (201) may additionally update DTSIs through a wrapper for the associated hardware configuration (or the vendor of the hardware configuration).

[0132] At operation 1340, the electronic device (201) may generate a DTS including updated DTSIs.

[0133] Figure 14 is a block diagram of a server for providing a service for DTS generation to an electronic device.

[0134] Compared to FIG. 2, in FIG. 14, a device description (260), a DTSI (265), a device description update module (270), a DTSI update module (280), and a DTS generation module (290) may be included in the server (1401).

[0135] For example, the electronic device (201) can transmit an input (310) for a UI (400, 501, 503, 505) displayed through a display (250) to a server (190) through a communication circuit (230).

[0136] For example, the server (1401) can update the device description (260) based on input (310) obtained via the communication circuit (1430). For example, the server (1401) can update the DTSI (265) based on the updated device description (320) and / or wrapper code (901, 905). For example, the server (1401) can generate the DTS based on the updated DTSI (330).

[0137] For example, the server (1401) can transmit a DTS including an updated DTSI (330) to the electronic device (201) via a communication circuit (1430).

[0138] As described above, the server (1401) can provide a web service (or cloud service) to the electronic device (201). For example, the server (1401) can generate a DTS file based on input (310) from the electronic device (201) and transmit the generated DTS file to the electronic device (201). Accordingly, the burden of the electronic device (201) having to maintain a device description (260) and / or DTSI (265) for multiple hardware configurations can be reduced.

[0139] Figure 15 is a block diagram of an electronic device (1501) within a network environment (1500).

[0140] Referring to FIG. 15, in a network environment (1500), an electronic device (1501) may communicate with an electronic device (1502) via a first network (1598) (e.g., a short-range wireless communication network), or may communicate with at least one of an electronic device (1504) or a server (1508) via a second network (1599) (e.g., a long-range wireless communication network). In one embodiment, the electronic device (1501) may communicate with the electronic device (1504) via the server (1508). According to one embodiment, the electronic device (1501) may include a processor (1520), a memory (1530), an input module (1550), an audio output module (1555), a display module (1560), an audio module (1570), a sensor module (1576), an interface (1577), a connection terminal (1578), a haptic module (1579), a camera module (1580), a power management module (1588), a battery (1589), a communication module (1590), a subscriber identification module (1596), or an antenna module (1597). In some embodiments, the electronic device (1501) may omit at least one of these components (e.g., the connection terminal (1578)), or may have one or more other components added. In some embodiments, some of these components (e.g., sensor module (1576), camera module (1580), or antenna module (1597)) may be integrated into a single component (e.g., display module (1560)).

[0141] The processor (1520) may, for example, execute software (e.g., a program (1540)) to control at least one other component (e.g., a hardware or software component) of the electronic device (1501) connected to the processor (1520) and perform various data processing or operations. According to one embodiment, as at least a part of the data processing or operations, the processor (1520) may store commands or data received from other components (e.g., a sensor module (1576) or a communication module (1590)) in a volatile memory (1532), process the commands or data stored in the volatile memory (1532), and store result data in a non-volatile memory (1534). According to one embodiment, the processor (1520) may include a main processor (1521) (e.g., a central processing unit or an application processor) or an auxiliary processor (1523) (e.g., a graphics processing unit, a neural processing unit (NPU), an image signal processor, a sensor hub processor, or a communication processor) that can operate independently or together with the main processor (1521). For example, when the electronic device (1501) includes the main processor (1521) and the auxiliary processor (1523), the auxiliary processor (1523) may be configured to use less power than the main processor (1521) or to be specialized for a given function. The auxiliary processor (1523) may be implemented separately from the main processor (1521) or as a part thereof.

[0142] The auxiliary processor (1523) may control at least a portion of functions or states associated with at least one component (e.g., the display module (1560), the sensor module (1576), or the communication module (1590)) of the electronic device (1501), for example, on behalf of the main processor (1521) while the main processor (1521) is in an inactive (e.g., sleep) state, or together with the main processor (1521) while the main processor (1521) is in an active (e.g., application execution) state. In one embodiment, the auxiliary processor (1523) (e.g., an image signal processor or a communication processor) may be implemented as a part of another functionally related component (e.g., a camera module (1580) or a communication module (1590)). In one embodiment, the auxiliary processor (1523) (e.g., a neural network processing unit) may include a hardware structure specialized for processing artificial intelligence models. The artificial intelligence models may be generated through machine learning. This learning can be performed, for example, on the electronic device (1501) where the artificial intelligence model is executed, or can be performed through a separate server (e.g., server (1508)). The learning algorithm can include, for example, supervised learning, unsupervised learning, semi-supervised learning, or reinforcement learning, but is not limited to the examples described above. The artificial intelligence model can include multiple artificial neural network layers.The artificial neural network may be one of a deep neural network (DNN), a convolutional neural network (CNN), a recurrent neural network (RNN), a restricted Boltzmann machine (RBM), a deep belief network (DBN), a bidirectional recurrent deep neural network (BRDNN), a deep Q-network, or a combination of two or more of the above, but is not limited to the examples described above. In addition to, or alternatively to, a hardware structure, an artificial intelligence model may include a software structure.

[0143] The memory (1530) can store various data used by at least one component (e.g., the processor (1520) or the sensor module (1576)) of the electronic device (1501). The data can include, for example, software (e.g., the program (1540)) and input data or output data for commands related thereto. The memory (1530) can include volatile memory (1532) or non-volatile memory (1534).

[0144] The program (1540) may be stored as software in memory (1530) and may include, for example, an operating system (1542), middleware (1544), or an application (1546). Examples of operating systems include Unix. TM and Linux TM Includes.

[0145] The input module (1550) can receive commands or data to be used in a component of the electronic device (1501) (e.g., a processor (1520)) from an external source (e.g., a user) of the electronic device (1501). The input module (1550) can include, for example, a microphone, a mouse, a keyboard, a key (e.g., a button), or a digital pen (e.g., a stylus pen).

[0146] The audio output module (1555) can output audio signals to the outside of the electronic device (1501). The audio output module (1555) can include, for example, a speaker or a receiver. The speaker can be used for general purposes, such as multimedia playback or recording playback. The receiver can be used to receive incoming calls. In one embodiment, the receiver can be implemented separately from the speaker or as part of the speaker.

[0147] The display module (1560) can visually provide information to an external party (e.g., a user) of the electronic device (1501). The display module (1560) may include, for example, a display, a holographic device, or a projector, and a control circuit for controlling the device. In one embodiment, the display module (1560) may include a touch sensor configured to detect a touch, or a pressure sensor configured to measure the intensity of a force generated by the touch.

[0148] The audio module (1570) can convert sound into an electrical signal, or vice versa. According to one embodiment, the audio module (1570) can acquire sound through the input module (1550), output sound through the sound output module (1555), or an external electronic device (e.g., electronic device (1502)) (e.g., speaker or headphone) directly or wirelessly connected to the electronic device (1501).

[0149] The sensor module (1576) can detect the operating status (e.g., power or temperature) of the electronic device (1501) or the external environmental status (e.g., user status) and generate an electrical signal or data value corresponding to the detected status. According to one embodiment, the sensor module (1576) can include, for example, a gesture sensor, a gyro sensor, a barometric pressure sensor, a magnetic sensor, an acceleration sensor, a grip sensor, a proximity sensor, a color sensor, an IR (infrared) sensor, a biometric sensor, a temperature sensor, a humidity sensor, or an illuminance sensor.

[0150] The interface (1577) may support one or more designated protocols that may be used to directly or wirelessly connect the electronic device (1501) with an external electronic device (e.g., the electronic device (1502)). In one embodiment, the interface (1577) may include, for example, a high definition multimedia interface (HDMI), a universal serial bus (USB) interface, an SD card interface, or an audio interface.

[0151] The connection terminal (1578) may include a connector through which the electronic device (1501) may be physically connected to an external electronic device (e.g., the electronic device (1502)). In one embodiment, the connection terminal (1578) may include, for example, an HDMI connector, a USB connector, an SD card connector, or an audio connector (e.g., a headphone connector).

[0152] The haptic module (1579) can convert electrical signals into mechanical stimuli (e.g., vibration or movement) or electrical stimuli that a user can perceive through tactile or kinesthetic sensations. In one embodiment, the haptic module (1579) may include, for example, a motor, a piezoelectric element, or an electrical stimulation device.

[0153] The camera module (1580) can capture still images and videos. In one embodiment, the camera module (1580) may include one or more lenses, image sensors, image signal processors, or flashes.

[0154] The power management module (1588) can manage the power supplied to the electronic device (1501). According to one embodiment, the power management module (1588) can be implemented as at least a part of, for example, a power management integrated circuit (PMIC).

[0155] A battery (1589) may power at least one component of the electronic device (1501). In one embodiment, the battery (1589) may include, for example, a non-rechargeable primary battery, a rechargeable secondary battery, or a fuel cell.

[0156] The communication module (1590) may support the establishment of a direct (e.g., wired) communication channel or a wireless communication channel between the electronic device (1501) and an external electronic device (e.g., electronic device (1502), electronic device (1504), or server (1508)), and the performance of communication through the established communication channel. The communication module (1590) may operate independently from the processor (1520) (e.g., application processor) and may include one or more communication processors that support direct (e.g., wired) communication or wireless communication. According to one embodiment, the communication module (1590) may include a wireless communication module (1592) (e.g., a cellular communication module, a short-range wireless communication module, or a global navigation satellite system (GNSS) communication module) or a wired communication module (1594) (e.g., a local area network (LAN) communication module, or a power line communication module). Any of these communication modules may communicate with an external electronic device (1504) via a first network (1598) (e.g., a short-range communication network such as Bluetooth, wireless fidelity (WiFi) direct, or infrared data association (IrDA)) or a second network (1599) (e.g., a long-range communication network such as a legacy cellular network, a 5G network, a next-generation communication network, the Internet, or a computer network (e.g., a local area network or a wide area network)). These various types of communication modules may be integrated into a single component (e.g., a single chip) or implemented as multiple separate components (e.g., multiple chips). The wireless communication module (1592) may use subscriber information (e.g., an international mobile subscriber identity (IMSI)) stored in the subscriber identification module (1596) to identify or authenticate the electronic device (1501) within a communication network such as the first network (1598) or the second network (1599).

[0157] The wireless communication module (1592) can support 5G networks and next-generation communication technologies following the 4G network, such as NR access technology (new radio access technology). NR access technology can support high-speed transmission of high-capacity data (eMBB (enhanced mobile broadband)), minimizing terminal power and connecting multiple terminals (mMTC (massive machine type communications)), or high reliability and low latency communications (URLLC (ultra-reliable and low-latency communications)). The wireless communication module (1592) can support, for example, a high-frequency band (e.g., mmWave band) to achieve a high data transmission rate. The wireless communication module (1592) can support various technologies for securing performance in high-frequency bands, such as beamforming, massive multiple-input and multiple-output (MIMO), full dimensional MIMO (FD-MIMO), array antenna, analog beam-forming, or large scale antenna. The wireless communication module (1592) can support various requirements specified in the electronic device (1501), an external electronic device (e.g., the electronic device (1504)), or a network system (e.g., the second network (1599)). According to one embodiment, the wireless communication module (1592) can support a peak data rate (e.g., 20 Gbps or more) for eMBB realization, a loss coverage (e.g., 664 dB or less) for mMTC realization, or a U-plane latency (e.g., 0.5 ms or less for downlink (DL) and uplink (UL), or 6 ms or less for round trip) for URLLC realization.

[0158] The antenna module (1597) can transmit or receive signals or power to or from an external device (e.g., an external electronic device). In one embodiment, the antenna module (1597) may include an antenna including a radiator formed of a conductor or a conductive pattern formed on a substrate (e.g., a PCB). In one embodiment, the antenna module (1597) may include a plurality of antennas (e.g., an array antenna). In this case, at least one antenna suitable for a communication method used in a communication network, such as the first network (1598) or the second network (1599), may be selected from the plurality of antennas by, for example, the communication module (1590). A signal or power may be transmitted or received between the communication module (1590) and an external electronic device via the at least one selected antenna. In some embodiments, in addition to the radiator, another component (e.g., a radio frequency integrated circuit (RFIC)) may be additionally formed as a part of the antenna module (1597).

[0159] According to various embodiments, the antenna module (1597) may form a mmWave antenna module. In one embodiment, the mmWave antenna module may include a printed circuit board, an RFIC disposed on or adjacent a first side (e.g., a bottom side) of the printed circuit board and capable of supporting a designated high frequency band (e.g., a mmWave band), and a plurality of antennas (e.g., an array antenna) disposed on or adjacent a second side (e.g., a top side or a side side) of the printed circuit board and capable of transmitting or receiving signals in the designated high frequency band.

[0160] At least some of the above components can be interconnected and exchange signals (e.g., commands or data) with each other via a communication method between peripheral devices (e.g., a bus, GPIO (general purpose input and output), SPI (serial peripheral interface), or MIPI (mobile industry processor interface)).

[0161] According to one embodiment, commands or data may be transmitted or received between the electronic device (1501) and an external electronic device (1504) via a server (1508) connected to a second network (1599). Each of the external electronic devices (1502 or 1504) may be the same or a different type of device as the electronic device (1501). According to one embodiment, all or part of the operations executed in the electronic device (1501) may be executed in one or more of the external electronic devices (1502, 1504, or 1508). For example, when the electronic device (1501) is to perform a certain function or service automatically or in response to a request from a user or another device, the electronic device (1501) may, instead of or in addition to executing the function or service itself, request one or more external electronic devices to perform the function or at least a part of the service. One or more external electronic devices that receive the request may execute at least a portion of the requested function or service, or an additional function or service related to the request, and transmit the result of the execution to the electronic device (1501). The electronic device (1501) may process the result as is or additionally and provide it as at least a portion of a response to the request. For this purpose, cloud computing, distributed computing, mobile edge computing (MEC), or client-server computing technology may be used, for example. The electronic device (1501) may provide an ultra-low latency service using, for example, distributed computing or mobile edge computing. In another embodiment, the external electronic device (1504) may include an Internet of Things (IoT) device. The server (1508) may be an intelligent server utilizing machine learning and / or a neural network.According to one embodiment, an external electronic device (1504) or server (1508) may be included within the second network (1599). The electronic device (1501) may be applied to intelligent services (e.g., smart homes, smart cities, smart cars, or healthcare) based on 5G communication technology and IoT-related technology.

[0162] As described above, the electronic device (201) may include a display (250), at least one processor (220) including a processing circuit; and a memory (210) storing instructions and including one or more storage media. The instructions, when individually or collectively executed by the at least one processor (220), may cause the electronic device (201) to obtain a first input (310) for displaying objects (410, 420, 430, 440) representing a plurality of hardware configurations while displaying a user interface (UI) (400) for generating a device tree source (DTS) through the display (250). The instructions, when individually or collectively executed by the at least one processor (220), may cause the electronic device (201) to obtain a second input (310) for connections (411, 413, 415) between the objects (410, 420, 430, 440). The instructions, when individually or collectively executed by the at least one processor (220), may cause the electronic device (201) to update first properties of device descriptions (260) of each of the objects (410, 420, 430, 440) based on the connections (411, 413, 415) between the objects (410, 420, 430, 440). The above instructions, when individually or collectively executed by the at least one processor (220), may cause the electronic device (201) to update second properties of the DTSI (device tree source include) (265) of each of the objects (410, 420, 430, 440) based on the updated device description (320).The above instructions, when individually or collectively executed by the at least one processor (220), may cause the electronic device (201) to generate a DTS including the updated DTSI (330) of each of the objects (410, 420, 430, 440).

[0163] The instructions, when individually or collectively executed by the at least one processor (220), may cause the electronic device (201) to identify a wrapper code corresponding to a manufacturer of a second object (420) associated with the first object (410). The instructions, when individually or collectively executed by the at least one processor (220), may cause the electronic device (201) to update third properties of the DTSI (265) of the first object (410) based on the wrapper code.

[0164] The above instructions, when individually or collectively executed by the at least one processor (220), may cause the electronic device (201) to update the third properties based on the wrapper code after updating the second properties of the DTSI (265) of the first object (410).

[0165] The above instructions, when individually or collectively executed by the at least one processor (220), may cause the electronic device (201) to update the third properties based on the wrapper code, based on which a driver for the first object (410) is built.

[0166] The above instructions, when individually or collectively executed by the at least one processor (220), may cause the electronic device (201) to add a sentence indicating a usrval attribute specified in the inport of the first device description (260) of the first object (410) and a value specified for the usrval attribute, based on the connection between the inport of the first object (410) and the outport of the second object (420).

[0167] The above instructions, when individually or collectively executed by the at least one processor (220), may cause the electronic device (201) to update the value of the parent attribute of the import of the first device description (260) of the first object (410) such that the value of the parent attribute of the outport of the second device description (701) of the second object (420) refers to the value of the parent attribute of the outport of the second device description (701). The instructions, when individually or collectively executed by the at least one processor (220), may cause the electronic device (201) to update the value of the symbol attribute of the inport of the first device description (260) of the first object (410) such that the value of the symbol attribute of the inport of the first device description (260) of the first object (410) refers to the value of the value attribute of the outport of the second device description (701) of the second object (420).

[0168] The above instructions, when individually or collectively executed by the at least one processor (220), may cause the electronic device (201) to update second properties of the DTSI (265) of the first object (410) based on the value of the parent property and the value of the symbol property of the import of the first device description (260) of the first object (410).

[0169] The above instructions, when individually or collectively executed by the at least one processor (220), may cause the electronic device (201) to display another UI (501, 503, 505) for updating the first properties based on obtaining the second input (310).

[0170] The driver for each of the above plurality of hardware configurations may be included in a subnode of a sibling node of the AP (application processor) node.

[0171] As described above, the method may be performed by an electronic device (201) including a display (250). The method may include an operation of obtaining a first input (310) for displaying objects (410, 420, 430, 440) representing a plurality of hardware configurations while displaying a user interface (UI) for generating a device tree source (DTS) through the display (250). The method may include an operation of obtaining a second input (310) for connections (411, 413, 415) between the objects (410, 420, 430, 440). The method may include an operation of updating first properties of a device description (260) of each of the objects (410, 420, 430, 440) based on the connections (411, 413, 415) between the objects (410, 420, 430, 440). The method may include an operation of updating second properties of a device tree source include (DTSI) (265) of each of the objects (410, 420, 430, 440) based on the updated device description (320). The method may include an operation of generating a DTS including the updated DTSI (330) of each of the objects (410, 420, 430, 440).

[0172] The method may include an operation of identifying a wrapper code corresponding to a manufacturer of a second object (420) connected to a first object (410). The method may include an operation of updating third properties of a DTSI (265) of the first object (410) based on the wrapper code.

[0173] The method may include an operation of updating the third properties based on the wrapper code after updating the second properties of the DTSI (265) of the first object (410).

[0174] The method may include an operation of updating the third properties based on the wrapper code, based on the driver being built for the first object (410).

[0175] The above method may include an operation of adding a sentence indicating a usrval attribute specified in the import of the first device description (260) of the first object (410) and a value specified for the usrval attribute based on the fact that the import of the first object (410) and the outport of the second object (420) are connected to each other.

[0176] The method may include an operation of updating the value of the parent attribute of the import of the first device description (260) of the first object (410) so that the value of the parent attribute of the import of the first device description (260) of the first object (410) refers to the value of the parent attribute of the outport of the second device description (701) of the second object (420). The method may include an operation of updating the value of the symbol attribute of the import of the first device description (260) of the first object (410) so that the value of the symbol attribute of the import of the first device description (260) of the first object (410) refers to the value of the value attribute of the outport of the second device description (701) of the second object (420).

[0177] The method may include an operation of updating second properties of the DTSI (265) of the first object (410) based on the value of the parent property of the import of the first device description (260) of the first object (410) and the value of the symbol property.

[0178] The method may include an operation of displaying another UI (501, 503, 505) for updating the first properties based on obtaining the second input (310).

[0179] The driver for each of the above plurality of hardware configurations may be included in a subnode of a sibling node of the AP (application processor) node.

[0180] As described above, a non-transitory computer readable storage medium can store a program including instructions. The instructions, when individually or collectively executed by at least one processor (220) of an electronic device (201) including a display (250), can cause the electronic device (201) to obtain a first input (310) for displaying objects (410, 420, 430, 440) representing a plurality of hardware configurations while displaying a user interface (UI) for generating a device tree source (DTS) through the display (250). The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to obtain a second input (310) for connections (411, 413, 415) between the objects (410, 420, 430, 440). The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to update first properties of a device description (260) of each of the objects (410, 420, 430, 440) based on the connections (411, 413, 415) between the objects (410, 420, 430, 440). The above instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to update second properties of a device tree source include (DTSI) (265) of each of the objects (410, 420, 430, 440) based on the updated device description (320).The above instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to generate a DTS including the updated DTSI (330) of each of the objects (410, 420, 430, 440).

[0181] The instructions, when individually or collectively executed by the at least one processor (220), may cause the electronic device (201) to identify a wrapper code corresponding to a manufacturer of a second object (420) associated with the first object (410). The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to update third properties of the DTSI (265) of the first object (410) based on the wrapper code.

[0182] Electronic devices according to the various embodiments disclosed in this document may take various forms. Electronic devices may include, for example, portable communication devices (e.g., smartphones), computer devices, portable multimedia devices, portable medical devices, cameras, wearable devices, or home appliances. Electronic devices according to the embodiments of this document are not limited to the aforementioned devices.

[0183] In connection with the description of the drawings, similar reference numerals may be used for similar or related components. The singular form of a noun corresponding to an item may include one or more of said items, unless the context clearly indicates otherwise. In this document, phrases such as "A or B," "at least one of A and B," "at least one of A or B," "A, B, or C," "at least one of A, B, and C," and "at least one of A, B, or C" may each include any one of the items listed together in that phrase, or all possible combinations thereof. Terms such as "first," "second," or "first" or "second" may be used simply to distinguish the corresponding component from other corresponding components and do not limit the corresponding components in any other respect (e.g., importance or order). When a component (e.g., a first component) is referred to as being "coupled" or "connected" to another component (e.g., a second component), with or without the terms "functionally" or "communicatively," it means that the component can be connected to the other component directly (e.g., wired), wirelessly, or through a third component.

[0184] The term "module" used in various embodiments of this document may include a unit implemented in hardware, software, or firmware, and may be used interchangeably with terms such as logic, logic block, component, or circuit. A module may be an integral component, or a minimum unit or part of such a component that performs one or more functions. For example, according to one embodiment, a module may be implemented in the form of an application-specific integrated circuit (ASIC).

[0185] Various embodiments of the present document may be implemented as software (e.g., a program (1540)) including one or more instructions stored in a storage medium (e.g., an internal memory (1536) or an external memory (1538)) readable by a machine (e.g., an electronic device (1501)). For example, a processor (e.g., a processor (1520)) of the machine (e.g., an electronic device (1501)) may call at least one instruction among the one or more instructions stored from the storage medium and execute it. This enables the machine to operate to perform at least one function according to the at least one called instruction. The one or more instructions may include code generated by a compiler or code executable by an interpreter. The machine-readable storage medium may be provided in the form of a non-transitory storage medium. Here, 'non-transitory' simply means that the storage medium is a tangible device and does not contain signals (e.g., electromagnetic waves), and the term does not distinguish between cases where data is stored semi-permanently or temporarily on the storage medium.

[0186] The methods according to various embodiments disclosed in this document may be provided as a computer program product. The computer program product may be traded between sellers and buyers as a product. The computer program product may be distributed in the form of a device-readable storage medium (e.g., CD-ROM (compact disc read-only memory)) or may be available through an application store (e.g., Play Store). TM) or directly between two user devices (e.g., smart phones), online distribution (e.g., downloading or uploading). In the case of online distribution, at least a portion of the computer program product may be at least temporarily stored or temporarily created in a machine-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or an intermediary server.

[0187] According to various embodiments, each component (e.g., a module or a program) of the above-described components may include one or more entities, and some of the entities may be separated and placed in other components. According to various embodiments, one or more components or operations of the aforementioned components may be omitted, or one or more other components or operations may be added. Alternatively or additionally, a plurality of components (e.g., a module or a program) may be integrated into a single component. In such a case, the integrated component may perform one or more functions of each of the plurality of components identically or similarly to those performed by the corresponding component among the plurality of components prior to the integration. According to various embodiments, the operations performed by a module, program, or other component may be executed sequentially, in parallel, iteratively, or heuristically, or one or more of the operations may be executed in a different order, omitted, or one or more other operations may be added.

Claims

1. In the electronic device (201), Display (250), At least one processor (220) comprising a processing circuit; and A memory (210) storing instructions and including one or more storage media, wherein the instructions, when individually or collectively executed by the at least one processor (220), cause the electronic device (201) to: While displaying a UI (user interface) (400) for generating a DTS (device tree source) through the above display (250), a first input (310) is acquired for displaying a plurality of objects (410, 420, 430, 440) representing each of a plurality of hardware configurations, Obtain a second input (310) representing connections (411, 413, 415) between the above plurality of objects (410, 420, 430, 440), Based on the connections (411, 413, 415) between the plurality of objects (410, 420, 430, 440), the first properties of the device description (260) of each of the plurality of objects (410, 420, 430, 440) are updated, Based on the above updated device description (320), the second properties of the DTSI (device tree source include) (265) of each of the plurality of objects (410, 420, 430, 440) are updated, Causing to generate a DTS including the updated DTSI (330) of each of the above plurality of objects (410, 420, 430, 440), Electronic devices.

2. In claim 1, The above instructions, when individually or collectively executed by the at least one processor (220), cause the electronic device (201) to: Identify the wrapper code corresponding to the manufacturer of the second object (420) connected to the first object (410) of the above plurality of objects, Based on the above wrapper code, causing the third properties of the DTSI (265) of the first object (410) to be updated, Electronic devices.

3. In claim 2, The above instructions, when individually or collectively executed by the at least one processor (220), cause the electronic device (201) to: After updating the second properties of the DTSI (265) of the first object (410), based on the wrapper code, causing the third properties to be updated. Electronic devices.

4. In claim 3, The above instructions, when individually or collectively executed by the at least one processor (220), cause the electronic device (201) to: Based on the driver being built for the first object (410), causing the third properties to be updated based on the wrapper code, Electronic devices.

5. In claim 1, The above instructions, when individually or collectively executed by the at least one processor (220), cause the electronic device (201) to: Based on the fact that the inport of the first object (410) and the outport of the second object (420) are connected to each other, a sentence indicating a usrval attribute specified in the inport of the first device description (260) of the first object (410) and a value specified for the usrval attribute is added. Electronic devices.

6. In claim 1, The above instructions, when individually or collectively executed by the at least one processor (220), cause the electronic device (201) to: The value of the parent attribute of the import of the first device description (260) of the first object (410) is updated so that the value of the parent attribute of the outport of the second device description (701) of the second object (410) is referenced. Causes the value of the symbol attribute of the import of the first device description (260) of the first object (410) to be updated so that the value of the symbol attribute of the import of the first device description (260) refers to the value of the value attribute of the outport of the second device description (701) of the second object (420). Electronic devices.

7. In claim 6, The above instructions, when individually or collectively executed by the at least one processor (220), cause the electronic device (201) to: Causing the second properties of the DTSI (265) of the first object (410) to be updated based on the value of the parent property of the import of the first device description (260) of the first object (410) and the value of the symbol property, Electronic devices.

8. In claim 1, The above instructions, when individually or collectively executed by the at least one processor (220), cause the electronic device (201) to: Based on obtaining the second input (310), causing another UI (501, 503, 505) to be displayed for updating the first properties. Electronic devices.

9. In claim 1, The driver of each of the above plurality of hardware configurations is included in a subnode of a sibling node of the AP (application processor) node. Electronic devices.

10. In a method of an electronic device (201) including a display (250), An operation of acquiring a first input (310) for displaying a plurality of objects (410, 420, 430, 440) representing each of a plurality of hardware configurations while displaying a UI (user interface) for generating a DTS (device tree source) through the above display (250), An operation of obtaining a second input (310) representing connections (411, 413, 415) between the plurality of objects (410, 420, 430, 440), An operation of updating first properties of the device description (260) of each of the plurality of objects (410, 420, 430, 440) based on the connections (411, 413, 415) between the plurality of objects (410, 420, 430, 440), An operation of updating the second properties of the DTSI (device tree source include) (265) of each of the plurality of objects (410, 420, 430, 440) based on the updated device description (320), and An operation of generating a DTS including the updated DTSI (330) of each of the plurality of objects (410, 420, 430, 440) method.

11. In claim 10, An operation of identifying a wrapper code corresponding to a manufacturer of a second object (420) connected to a first object (410) of multiple objects, and Based on the above wrapper code, an operation for updating the third properties of the DTSI (265) of the first object (410) is included. method.

12. In claim 11, After updating the second properties of the DTSI (265) of the first object (410), an operation of updating the third properties based on the wrapper code is included. method.

13. In claim 12, Based on the driver being built for the first object (410), including an operation of updating the third properties based on the wrapper code. method.

14. In claim 10, An operation including adding a sentence indicating a usrval attribute specified in the import of the first device description (260) of the first object (410) and a value specified for the usrval attribute based on the connection of the import of the first object (410) and the outport of the second object (420) to each other. method.

15. In a non-transitory computer readable storage medium, Save a program containing instructions, The above instructions, when executed individually or collectively by at least one processor (220) of an electronic device (201) including a display (250), cause the electronic device (201) to: While displaying a UI (user interface) for generating a DTS (device tree source) through the above display (250), a first input (310) is acquired for displaying a plurality of objects (410, 420, 430, 440) representing each of a plurality of hardware configurations, Obtain a second input (310) representing connections (411, 413, 415) between the above plurality of objects (410, 420, 430, 440), Based on the connections (411, 413, 415) between the plurality of objects (410, 420, 430, 440), the first properties of the device description (260) of each of the plurality of objects (410, 420, 430, 440) are updated, Based on the above updated device description (320), the second properties of the DTSI (device tree source include) (265) of each of the plurality of objects (410, 420, 430, 440) are updated, Causing to generate a DTS including the updated DTSI (330) of each of the above plurality of objects (410, 420, 430, 440), Non-transitory computer-readable recording medium.

Images