Re: [PATCH 2/2] omap4: sdp: convert to device model

2020-06-15 Thread Peter Ujfalusi
Hi Tom,

On 15/06/2020 16.38, Tom Rini wrote:
> On Mon, Jun 15, 2020 at 04:35:52PM +0300, Peter Ujfalusi wrote:
>> Hi Tom,
>>
>> On 15/06/2020 16.14, Tom Rini wrote:
>>> On Mon, Jun 15, 2020 at 04:08:51PM +0300, Tero Kristo wrote:
>>>> On 15/06/2020 15:53, Tom Rini wrote:
>>>>> On Mon, Jun 15, 2020 at 01:16:05PM +0300, Peter Ujfalusi wrote:
>>>>>
>>>>>> Convert omap4 sdp to device model.
>>>>>>
>>>>>> Signed-off-by: Peter Ujfalusi 
>>>>>> ---
>>>>>>   arch/arm/dts/Makefile   |  4 
>>>>>>   board/ti/sdp4430/sdp.c  | 12 
>>>>>>   configs/omap4_sdp4430_defconfig |  8 
>>>>>>   3 files changed, 24 insertions(+)
>>>>>
>>>>> Please note that this, like the pandaboard series, aren't dealing with
>>>>> the DM_SPI conversion which brought up removing this to start with.
>>>>> While I'm pretty sure pandaboard exposes SPI on a header, I don't know
>>>>> if sdp does and perhaps you just want to remove SPI?  Thanks!
>>>>
>>>> Can you provide a reference to the DM_SPI discussion?
>>>>
>>>> I guess we could remove DM_SPI from pandaboard also if it is causing
>>>> problems. My initial attempt on that series was just to get basic boot
>>>> working via MMC, and that should be done now if I am not terribly
>>>> mistaken...
>>>
>>> It's over in
>>> http://patchwork.ozlabs.org/project/uboot/patch/20200527125637.149189-16-ja...@amarulasolutions.com/
>>> but there's not much to discuss as the DM_SPI / DM_SPI_FLASH conversion
>>> deadline was a year ago this next release, hence the removal of
>>> platforms that haven't.  The good news for OMAP4 (and OMAP5) is that the
>>> driver itself has already been converted so it's no more work than the
>>> USB, etc, conversions that you've both done recently.  Thanks!
>>
>> Adding DM_SPI to the defconfig? In the board file I don't see any trace
>> of SPI being enabled or used.
>> As I said, the ethernet would need SPI, but that never worked in mainline..
> 
> It's enabled in the defconfig today.  If you don't want to enable SPI in
> U-Boot (which is fine for the 4430, I assume no one wants to spend the
> time trying to enable ethernet on it at this point) just disable it.

Right, on the SDP SPI is used for DLP (display projector),
WLAN/BT/Radio, Modem interface and the KSZ8851SNL Ethernet.
With the exception of ethernet all of them are don't care for u-boot imho.
It is actually pretty annoying that I can not use tftp boot on the
Blaze. With DM_SPI it might make sense to revisit the issue as we had
some old u-boot which used omap_mcsspi API to get ethernet working...

I'll disable the SPI for SDP in v2, let's re-enable if we can get
ethernet working on it.

> I only have an open question on if that's right for pandaboard because I
> thought it's exposed on the expansion header, but I don't know how big a
> deal that is these days really.  Thanks!
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki



Re: [PATCH 2/2] omap4: sdp: convert to device model

2020-06-15 Thread Peter Ujfalusi
Hi Tom,

On 15/06/2020 16.14, Tom Rini wrote:
> On Mon, Jun 15, 2020 at 04:08:51PM +0300, Tero Kristo wrote:
>> On 15/06/2020 15:53, Tom Rini wrote:
>>> On Mon, Jun 15, 2020 at 01:16:05PM +0300, Peter Ujfalusi wrote:
>>>
>>>> Convert omap4 sdp to device model.
>>>>
>>>> Signed-off-by: Peter Ujfalusi 
>>>> ---
>>>>   arch/arm/dts/Makefile   |  4 
>>>>   board/ti/sdp4430/sdp.c  | 12 
>>>>   configs/omap4_sdp4430_defconfig |  8 
>>>>   3 files changed, 24 insertions(+)
>>>
>>> Please note that this, like the pandaboard series, aren't dealing with
>>> the DM_SPI conversion which brought up removing this to start with.
>>> While I'm pretty sure pandaboard exposes SPI on a header, I don't know
>>> if sdp does and perhaps you just want to remove SPI?  Thanks!
>>
>> Can you provide a reference to the DM_SPI discussion?
>>
>> I guess we could remove DM_SPI from pandaboard also if it is causing
>> problems. My initial attempt on that series was just to get basic boot
>> working via MMC, and that should be done now if I am not terribly
>> mistaken...
> 
> It's over in
> http://patchwork.ozlabs.org/project/uboot/patch/20200527125637.149189-16-ja...@amarulasolutions.com/
> but there's not much to discuss as the DM_SPI / DM_SPI_FLASH conversion
> deadline was a year ago this next release, hence the removal of
> platforms that haven't.  The good news for OMAP4 (and OMAP5) is that the
> driver itself has already been converted so it's no more work than the
> USB, etc, conversions that you've both done recently.  Thanks!

Adding DM_SPI to the defconfig? In the board file I don't see any trace
of SPI being enabled or used.
As I said, the ethernet would need SPI, but that never worked in mainline..

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki



Re: [PATCH 0/2] omap4: sdp: convert to device model

2020-06-15 Thread Peter Ujfalusi



On 15/06/2020 13.16, Peter Ujfalusi wrote:
> Hi,
> 
> The series is based on Tero's omap4 panda and omap5 uevm device model 
> conversion
> patches.
> 
> To avoid removal of the SDP4430 due to neglect.
> With these patches applied no more complaints about DM_SPL conversion and the
> board boots up Linux.
> We never had ethernet support for spd4430 in mainline (ks8851 on spi bus), 
> this
> is still the case.
> 
> Linux boots up, but for some reason ethernet is not responsible, that needs to
> be investigated, unlikely caused by u-boot.

Actually it works in Linux.

> I really like to keep sdp4430/Blaze support as it is the platform where I can
> test DMIC and other audio features of McPDM/twl6040. The board also have dual
> LCD, which is a nice thing to have.
> 
> Regards,
> Peter
> ---
> Peter Ujfalusi (2):
>   omap4: Copy device tree from Linux 5.7.y for SDP4430
>   omap4: sdp: convert to device model
> 
>  arch/arm/dts/Makefile   |   4 +
>  arch/arm/dts/omap4-sdp-es23plus.dts |  14 +
>  arch/arm/dts/omap4-sdp.dts  | 713 
>  board/ti/sdp4430/sdp.c  |  12 +
>  configs/omap4_sdp4430_defconfig |   8 +
>  5 files changed, 751 insertions(+)
>  create mode 100644 arch/arm/dts/omap4-sdp-es23plus.dts
>  create mode 100644 arch/arm/dts/omap4-sdp.dts
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki



[PATCH 1/2] omap4: Copy device tree from Linux 5.7.y for SDP4430

2020-06-15 Thread Peter Ujfalusi
Copy all device tree files required for omap4 sdp4430 support from
mainline Linux.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/dts/omap4-sdp-es23plus.dts |  14 +
 arch/arm/dts/omap4-sdp.dts  | 713 
 2 files changed, 727 insertions(+)
 create mode 100644 arch/arm/dts/omap4-sdp-es23plus.dts
 create mode 100644 arch/arm/dts/omap4-sdp.dts

diff --git a/arch/arm/dts/omap4-sdp-es23plus.dts 
b/arch/arm/dts/omap4-sdp-es23plus.dts
new file mode 100644
index ..42154520d383
--- /dev/null
+++ b/arch/arm/dts/omap4-sdp-es23plus.dts
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ */
+#include "omap4-sdp.dts"
+
+/* SDP boards with 4430 ES2.3+ or 4460 have external pullups on SCL & SDA */
+_hdmi_pins {
+   pinctrl-single,pins = <
+   OMAP4_IOPAD(0x09a, PIN_INPUT | MUX_MODE0)   /* 
hdmi_cec.hdmi_cec */
+   OMAP4_IOPAD(0x09c, PIN_INPUT | MUX_MODE0)   /* 
hdmi_scl.hdmi_scl */
+   OMAP4_IOPAD(0x09e, PIN_INPUT | MUX_MODE0)   /* 
hdmi_sda.hdmi_sda */
+   >;
+};
diff --git a/arch/arm/dts/omap4-sdp.dts b/arch/arm/dts/omap4-sdp.dts
new file mode 100644
index ..91480ac1f328
--- /dev/null
+++ b/arch/arm/dts/omap4-sdp.dts
@@ -0,0 +1,713 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ */
+/dts-v1/;
+
+#include "omap443x.dtsi"
+#include "elpida_ecb240abacn.dtsi"
+#include "omap4-mcpdm.dtsi"
+
+/ {
+   model = "TI OMAP4 SDP board";
+   compatible = "ti,omap4-sdp", "ti,omap4430", "ti,omap4";
+
+   memory@8000 {
+   device_type = "memory";
+   reg = <0x8000 0x4000>; /* 1 GB */
+   };
+
+   aliases {
+   display0 = 
+   display1 = 
+   display2 = 
+   };
+
+   vdd_eth: fixedregulator-vdd-eth {
+   pinctrl-names = "default";
+   pinctrl-0 = <_enable_gpio>;
+
+   compatible = "regulator-fixed";
+   regulator-name = "VDD_ETH";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = < 16 GPIO_ACTIVE_HIGH>;  /* gpio line 48 */
+   enable-active-high;
+   regulator-boot-on;
+   startup-delay-us = <25000>;
+   };
+
+   vbat: fixedregulator-vbat {
+   compatible = "regulator-fixed";
+   regulator-name = "VBAT";
+   regulator-min-microvolt = <375>;
+   regulator-max-microvolt = <375>;
+   regulator-boot-on;
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   debug0 {
+   label = "omap4:green:debug0";
+   gpios = < 29 GPIO_ACTIVE_HIGH>; /* 61 */
+   };
+
+   debug1 {
+   label = "omap4:green:debug1";
+   gpios = < 30 GPIO_ACTIVE_HIGH>; /* 30 */
+   };
+
+   debug2 {
+   label = "omap4:green:debug2";
+   gpios = < 7 GPIO_ACTIVE_HIGH>; /* 7 */
+   };
+
+   debug3 {
+   label = "omap4:green:debug3";
+   gpios = < 8 GPIO_ACTIVE_HIGH>; /* 8 */
+   };
+
+   debug4 {
+   label = "omap4:green:debug4";
+   gpios = < 18 GPIO_ACTIVE_HIGH>; /* 50 */
+   };
+
+   user1 {
+   label = "omap4:blue:user";
+   gpios = < 9 GPIO_ACTIVE_HIGH>; /* 169 */
+   };
+
+   user2 {
+   label = "omap4:red:user";
+   gpios = < 10 GPIO_ACTIVE_HIGH>; /* 170 */
+   };
+
+   user3 {
+   label = "omap4:green:user";
+   gpios = < 11 GPIO_ACTIVE_HIGH>; /* 139 */
+   };
+   };
+
+   pwmleds {
+   compatible = "pwm-leds";
+   kpad {
+   label = "omap4::keypad";
+   pwms = <_pwm 0 7812500>;
+   max-brightness = <127>;
+   };
+
+   charging {
+   label = "omap4:green:chrg";
+   pwms = <_pwmled 0 7812500>;
+   max-brightness = <255>;
+   };
+   };
+
+ 

[PATCH 2/2] omap4: sdp: convert to device model

2020-06-15 Thread Peter Ujfalusi
Convert omap4 sdp to device model.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/dts/Makefile   |  4 
 board/ti/sdp4430/sdp.c  | 12 
 configs/omap4_sdp4430_defconfig |  8 
 3 files changed, 24 insertions(+)

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 5ce44d701c19..03b1f8388df7 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -852,6 +852,10 @@ dtb-$(CONFIG_TARGET_OMAP4_PANDA) += \
omap4-panda.dtb \
omap4-panda-es.dtb
 
+dtb-$(CONFIG_TARGET_OMAP4_SDP4430) += \
+   omap4-sdp.dtb \
+   omap4-sdp-es23plus.dtb
+
 dtb-$(CONFIG_TARGET_OMAP5_UEVM) += \
omap5-uevm.dtb
 
diff --git a/board/ti/sdp4430/sdp.c b/board/ti/sdp4430/sdp.c
index a5b350404530..5b294ea79b23 100644
--- a/board/ti/sdp4430/sdp.c
+++ b/board/ti/sdp4430/sdp.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -91,6 +92,17 @@ void board_mmc_power_init(void)
 #endif
 #endif
 
+#if defined(CONFIG_SPL_OS_BOOT)
+int spl_start_uboot(void)
+{
+   /* break into full u-boot on 'c' */
+   if (serial_tstc() && serial_getc() == 'c')
+   return 1;
+
+   return 0;
+}
+#endif /* CONFIG_SPL_OS_BOOT */
+
 /*
  * get_board_rev() - get board revision
  */
diff --git a/configs/omap4_sdp4430_defconfig b/configs/omap4_sdp4430_defconfig
index 219721388f13..17751cde8fdc 100644
--- a/configs/omap4_sdp4430_defconfig
+++ b/configs/omap4_sdp4430_defconfig
@@ -5,6 +5,7 @@ CONFIG_ARCH_OMAP2PLUS=y
 CONFIG_ENV_OFFSET=0xE
 CONFIG_OMAP44XX=y
 CONFIG_TARGET_OMAP4_SDP4430=y
+CONFIG_DEFAULT_DEVICE_TREE="omap4-sdp"
 CONFIG_CMD_BAT=y
 CONFIG_SPL=y
 CONFIG_SPL_TEXT_BASE=0x4030
@@ -12,6 +13,7 @@ CONFIG_DISTRO_DEFAULTS=y
 CONFIG_BOOTCOMMAND="if test ${boot_fit} -eq 1; then run update_to_fit; fi; run 
findfdt; run init_console; run envboot; run distro_bootcmd"
 CONFIG_SYS_CONSOLE_IS_IN_ENV=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
+CONFIG_DEFAULT_FDT_FILE="omap4-sdp.dtb"
 CONFIG_VERSION_VARIABLE=y
 # CONFIG_SPL_I2C_SUPPORT is not set
 # CONFIG_SPL_NAND_SUPPORT is not set
@@ -23,16 +25,20 @@ CONFIG_CMD_SPI=y
 # CONFIG_CMD_SETEXPR is not set
 # CONFIG_CMD_NFS is not set
 CONFIG_CMD_EXT4_WRITE=y
+CONFIG_OF_CONTROL=y
 # CONFIG_EFI_PARTITION is not set
 CONFIG_SPL_PARTITION_UUIDS=y
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_DM=y
+CONFIG_DM_MMC=y
 CONFIG_MMC_OMAP_HS=y
 CONFIG_CONS_INDEX=3
 CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
 CONFIG_OMAP3_SPI=y
 CONFIG_USB=y
+CONFIG_DM_USB=y
 CONFIG_USB_MUSB_UDC=y
 CONFIG_USB_OMAP3=y
 CONFIG_USB_GADGET=y
@@ -40,3 +46,5 @@ CONFIG_FAT_WRITE=y
 # CONFIG_REGEX is not set
 CONFIG_OF_LIBFDT=y
 # CONFIG_EFI_LOADER is not set
+CONFIG_SYS_MALLOC_F_LEN=0x4000
+CONFIG_DM_ETH=y
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki



[PATCH 0/2] omap4: sdp: convert to device model

2020-06-15 Thread Peter Ujfalusi
Hi,

The series is based on Tero's omap4 panda and omap5 uevm device model conversion
patches.

To avoid removal of the SDP4430 due to neglect.
With these patches applied no more complaints about DM_SPL conversion and the
board boots up Linux.
We never had ethernet support for spd4430 in mainline (ks8851 on spi bus), this
is still the case.

Linux boots up, but for some reason ethernet is not responsible, that needs to
be investigated, unlikely caused by u-boot.

I really like to keep sdp4430/Blaze support as it is the platform where I can
test DMIC and other audio features of McPDM/twl6040. The board also have dual
LCD, which is a nice thing to have.

Regards,
Peter
---
Peter Ujfalusi (2):
  omap4: Copy device tree from Linux 5.7.y for SDP4430
  omap4: sdp: convert to device model

 arch/arm/dts/Makefile   |   4 +
 arch/arm/dts/omap4-sdp-es23plus.dts |  14 +
 arch/arm/dts/omap4-sdp.dts  | 713 
 board/ti/sdp4430/sdp.c  |  12 +
 configs/omap4_sdp4430_defconfig |   8 +
 5 files changed, 751 insertions(+)
 create mode 100644 arch/arm/dts/omap4-sdp-es23plus.dts
 create mode 100644 arch/arm/dts/omap4-sdp.dts

-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki



Re: [PATCH 09/33] dma: Rename free() to rfree()

2020-01-12 Thread Peter Ujfalusi
Hi Simon,

On 12/01/2020 21.06, Simon Glass wrote:
> This function name conflicts with our desire to #define free() to
> something else on sandbox. Since it deals with resources, rename it to
> rfree().
> 
> Signed-off-by: Simon Glass 
> ---
> 
>  drivers/dma/dma-uclass.c   | 4 ++--
>  drivers/dma/sandbox-dma-test.c | 2 +-
>  drivers/dma/ti/k3-udma.c   | 2 +-
>  include/dma-uclass.h   | 4 ++--
>  4 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/dma/dma-uclass.c b/drivers/dma/dma-uclass.c
> index 5598bca21c..a0159d7888 100644
> --- a/drivers/dma/dma-uclass.c
> +++ b/drivers/dma/dma-uclass.c
> @@ -122,10 +122,10 @@ int dma_free(struct dma *dma)
>  
>   debug("%s(dma=%p)\n", __func__, dma);
>  
> - if (!ops->free)
> + if (!ops->rfree)
>   return 0;
>  
> - return ops->free(dma);
> + return ops->rfree(dma);
>  }
>  
>  int dma_enable(struct dma *dma)
> diff --git a/drivers/dma/sandbox-dma-test.c b/drivers/dma/sandbox-dma-test.c
> index 8fcef1863e..5aa7838ff5 100644
> --- a/drivers/dma/sandbox-dma-test.c
> +++ b/drivers/dma/sandbox-dma-test.c
> @@ -229,7 +229,7 @@ static const struct dma_ops sandbox_dma_ops = {
>   .transfer   = sandbox_dma_transfer,
>   .of_xlate   = sandbox_dma_of_xlate,
>   .request= sandbox_dma_request,
> - .free   = sandbox_dma_free,
> + .rfree  = sandbox_dma_free,

Please also change the name of the implementing callback function:
s/sandbox_dma_free/sandbox_dma_rfree

>   .enable = sandbox_dma_enable,
>   .disable= sandbox_dma_disable,
>   .send   = sandbox_dma_send,
> diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
> index f7128610c5..23d6ed0697 100644
> --- a/drivers/dma/ti/k3-udma.c
> +++ b/drivers/dma/ti/k3-udma.c
> @@ -1720,7 +1720,7 @@ static const struct dma_ops udma_ops = {
>   .transfer   = udma_transfer,
>   .of_xlate   = udma_of_xlate,
>   .request= udma_request,
> - .free   = udma_free,
> + .rfree  = udma_free,

Same here.

>   .enable = udma_enable,
>   .disable= udma_disable,
>   .send   = udma_send,
> diff --git a/include/dma-uclass.h b/include/dma-uclass.h
> index a1d9d26ac5..340437acc1 100644
> --- a/include/dma-uclass.h
> +++ b/include/dma-uclass.h
> @@ -58,14 +58,14 @@ struct dma_ops {
>*/
>   int (*request)(struct dma *dma);
>   /**
> -  * free - Free a previously requested dma.
> +  * rfree - Free a previously requested dma.
>*
>* This is the implementation of the client dma_free() API.
>*
>* @dma: The DMA to free.
>* @return 0 if OK, or a negative error code.
>*/
> - int (*free)(struct dma *dma);
> + int (*rfree)(struct dma *dma);
>   /**
>* enable() - Enable a DMA Channel.
>*
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


Re: [U-Boot] [PATCH] drivers: dma: ti: k3-udma: Extract packet data only when Meta data is not NULL

2019-04-24 Thread Peter Ujfalusi


On 24/04/2019 14.03, Keerthy wrote:
> Currently packet data is wrongly extracted when metadata is NULL.
> Fix it and negate the if check.

Good catch.

Reviewed-by: Peter Ujfalusi 

> 
> Signed-off-by: Keerthy 
> Reviewed-by: Grygorii Strashko 
> ---
>  drivers/dma/ti/k3-udma.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
> index f78a01aa8f..e9ca09d8d3 100644
> --- a/drivers/dma/ti/k3-udma.c
> +++ b/drivers/dma/ti/k3-udma.c
> @@ -1492,7 +1492,7 @@ static int udma_send(struct dma *dma, void *src, size_t 
> len, void *metadata)
>   u32 tc_ring_id;
>   int ret;
>  
> - if (!metadata)
> + if (metadata)
>   packet_data = *((struct ti_udma_drv_packet_data *)metadata);
>  
>   if (dma->id >= (ud->rchan_cnt + ud->tchan_cnt)) {
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] fit: load all fragments from the extra configurations

2019-03-06 Thread Peter Ujfalusi
Currently only the first fdt is loaded from the extra configuration of
FIT image.
If the configuration have multiple fdt, load them all as well.

Signed-off-by: Peter Ujfalusi 
---
 common/image-fit.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/common/image-fit.c b/common/image-fit.c
index ac901e131ca1..a74b44f2982c 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -2118,6 +2118,18 @@ int boot_get_fdt_fit(bootm_headers_t *images, ulong addr,
if (next_config)
*next_config++ = '\0';
uname = NULL;
+
+   /*
+* fit_image_load() would load the first FDT from the
+* extra config only when uconfig is specified.
+* Check if the extra config contains multiple FDTs and
+* if so, load them.
+*/
+   cfg_noffset = fit_conf_get_node(fit, uconfig);
+
+   i = 0;
+   count = fit_conf_get_prop_node_count(fit, cfg_noffset,
+FIT_FDT_PROP);
}
 
debug("%d: using uname=%s uconfig=%s\n", i, uname, uconfig);
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 4/6] dma: ti: add driver to K3 UDMA

2019-01-23 Thread Peter Ujfalusi
Tom,

On 22/01/2019 20.56, Tom Rini wrote:
> On Tue, Jan 22, 2019 at 08:33:57PM +0530, Vignesh R wrote:
> 
>> The UDMA-P is intended to perform similar (but significantly upgraded) 
>> functions
>> as the packet-oriented DMA used on previous SoC devices. The UDMA-P module
>> supports the transmission and reception of various packet types.
>> The UDMA-P also supports acting as both a UTC and UDMA-C for its internal
>> channels. Channels in the UDMA-P can be configured to be either Packet-Based 
>> or
>> Third-Party channels on a channel by channel basis.
>>
>> The initial driver supports:
>> - MEM_TO_MEM (TR mode)
>> - DEV_TO_MEM (Packet mode)
>> - MEM_TO_DEV (Packet mode)
>>
>> Signed-off-by: Peter Ujfalusi 
>> Signed-off-by: Grygorii Strashko 
>> Signed-off-by: Vignesh R 
> 
> Reviewed-by: Tom Rini 
> 
> And the DT binding is common to Linux, and been reviewed there?  Or?

The binding is the same for Linux but unfortunately it has not went
through a proper review yet due to the fact that I need to wait for the
interrupt support to arrive to mainline.

However I have sent an earlier version as RFC:
https://www.spinics.net/lists/dmaengine/msg16661.html

As for the bindings (and code):
The linux bindings are different:

- there is no ti,psi-proxy anymore.
- ringacc uses tisci to get GP ring range and we need
  ti,sci-rm-range-gp-rings property in DT for it
- UDMA also uses tisci to get resource ranges and needs:
  ti,sci-rm-range-tchan, ti,sci-rm-range-rchan, ti,sci-rm-range-rflow in DT
- UDMA does not have/need dma-channels property
- properties needed for interrupts (currently msi-parent)

FWIW this is how the MCU NAVSS looks like in Linux atm:
https://github.com/omap-audio/linux-audio/blob/peter/linux-next-wip/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi

and the binding documentation for UDMA:
https://github.com/omap-audio/linux-audio/blob/peter/linux-next-wip/Documentation/devicetree/bindings/dma/ti/k3-udma.txt

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] sdp4430: fix mux configuration for SYS_NIRQ2

2012-05-17 Thread Peter Ujfalusi
SYS_NIRQ2 is servicing the interrupt from twl6040.
Configure the SYS_NIRQ2 so we can actually receive the interrupts.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 board/ti/sdp4430/sdp4430_mux_data.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/board/ti/sdp4430/sdp4430_mux_data.h 
b/board/ti/sdp4430/sdp4430_mux_data.h
index 0a20968..beb7c7a 100644
--- a/board/ti/sdp4430/sdp4430_mux_data.h
+++ b/board/ti/sdp4430/sdp4430_mux_data.h
@@ -216,7 +216,7 @@ const struct pad_conf_entry 
core_padconf_array_non_essential[] = {
{FREF_CLK1_OUT, (M0)},  /* 
fref_clk1_out */
{FREF_CLK2_OUT, (M0)},  /* 
fref_clk2_out */
{SYS_NIRQ1, (PTU | IEN | M0)},  /* 
sys_nirq1 */
-   {SYS_NIRQ2, (M7)},  /* 
sys_nirq2 */
+   {SYS_NIRQ2, (PTU | IEN | M0)},  /* 
sys_nirq2 */
{SYS_BOOT0, (PTU | IEN | M3)},  /* 
gpio_184 */
{SYS_BOOT1, (M3)},  /* 
gpio_185 */
{SYS_BOOT2, (PTD | IEN | M3)},  /* 
gpio_186 */
-- 
1.7.8.6

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] sdp4430: fix mux configuration for SYS_NIRQ2

2012-05-17 Thread Peter Ujfalusi
Hi Sricharan,

On 05/17/2012 11:48 AM, R, Sricharan wrote:
 diff --git a/board/ti/sdp4430/sdp4430_mux_data.h 
 b/board/ti/sdp4430/sdp4430_mux_data.h
 index 0a20968..beb7c7a 100644
 --- a/board/ti/sdp4430/sdp4430_mux_data.h
 +++ b/board/ti/sdp4430/sdp4430_mux_data.h
 @@ -216,7 +216,7 @@ const struct pad_conf_entry 
 core_padconf_array_non_essential[] = {
{FREF_CLK1_OUT, (M0)},  /* 
 fref_clk1_out */
{FREF_CLK2_OUT, (M0)},  /* 
 fref_clk2_out */
{SYS_NIRQ1, (PTU | IEN | M0)},  /* 
 sys_nirq1 */
 -   {SYS_NIRQ2, (M7)},  /* 
 sys_nirq2 */
 +   {SYS_NIRQ2, (PTU | IEN | M0)},  /* 
 sys_nirq2 */
 
Looks fine. But how about doing this in the kernel using mux framework?

The SYS_NIRQ2 has been configured correctly in case of PandaBoard in u-boot.
Looking at the kernel: neither of the sdp4430 or PandaBoard board files
are configuring SYS_NIRQ1/2, all relies on the bootloader to set this up.
I can as well send patches for sdp4430 and PandaBoard board files to
configure the SYS_NIRQ2 explicitly, but IMHO the bootloader can do this
for us with ease as well.
I think if we can we should set up things in a bootloader and let the
kernel to deal with smaller differences (like things differs between
board revisions and stuff).

Regards,
Péter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot