[meta-fsl-arm-extra][PATCH 1/2] linux-riotboard: Add separate riotboard kernel recipe

[meta-fsl-arm-extra][PATCH 1/2] linux-riotboard: Add separate riotboard kernel recipe

[Nikolay Dimitrov]

Add dedicated RIoTboard kernel recipe for easier maintenance and patch
cherry-picking.

Signed-off-by: Nikolay Dimitrov <picmaster@mail.bg>
---
 conf/machine/imx6dl-riotboard.conf                 |    2 +-
 recipes-kernel/linux/linux-riotboard-4.0/defconfig |  356 ++++++++++++++++++++
 recipes-kernel/linux/linux-riotboard_4.0.bb        |   15 +
 3 files changed, 372 insertions(+), 1 deletion(-)
 create mode 100644 recipes-kernel/linux/linux-riotboard-4.0/defconfig
 create mode 100644 recipes-kernel/linux/linux-riotboard_4.0.bb

diff --git a/conf/machine/imx6dl-riotboard.conf b/conf/machine/imx6dl-riotboard.conf
index b611ffb..04a301b 100644
--- a/conf/machine/imx6dl-riotboard.conf
+++ b/conf/machine/imx6dl-riotboard.conf
@@ -11,7 +11,7 @@ SOC_FAMILY = "mx6:mx6dl"
 
 UBOOT_MACHINE = "riotboard_defconfig"
 
-PREFERRED_PROVIDER_virtual/kernel ?= "linux-fslc"
+PREFERRED_PROVIDER_virtual/kernel ?= "linux-riotboard"
 KERNEL_DEVICETREE = "imx6dl-riotboard.dtb"
 
 SERIAL_CONSOLE = "115200 ttymxc1"
diff --git a/recipes-kernel/linux/linux-riotboard-4.0/defconfig b/recipes-kernel/linux/linux-riotboard-4.0/defconfig
new file mode 100644
index 0000000..f6989fb
--- /dev/null
+++ b/recipes-kernel/linux/linux-riotboard-4.0/defconfig
@@ -0,0 +1,356 @@
+CONFIG_KERNEL_LZO=y
+CONFIG_SYSVIPC=y
+CONFIG_FHANDLE=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_LOG_BUF_SHIFT=18
+CONFIG_CGROUPS=y
+CONFIG_RELAY=y
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_EXPERT=y
+CONFIG_PERF_EVENTS=y
+# CONFIG_SLUB_DEBUG is not set
+# CONFIG_COMPAT_BRK is not set
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_MODVERSIONS=y
+CONFIG_MODULE_SRCVERSION_ALL=y
+# CONFIG_BLK_DEV_BSG is not set
+CONFIG_ARCH_MULTI_V6=y
+CONFIG_ARCH_MXC=y
+CONFIG_MACH_MX31LILLY=y
+CONFIG_MACH_MX31LITE=y
+CONFIG_MACH_PCM037=y
+CONFIG_MACH_PCM037_EET=y
+CONFIG_MACH_MX31_3DS=y
+CONFIG_MACH_MX31MOBOARD=y
+CONFIG_MACH_QONG=y
+CONFIG_MACH_ARMADILLO5X0=y
+CONFIG_MACH_KZM_ARM11_01=y
+CONFIG_MACH_IMX31_DT=y
+CONFIG_MACH_IMX35_DT=y
+CONFIG_MACH_PCM043=y
+CONFIG_MACH_MX35_3DS=y
+CONFIG_MACH_VPR200=y
+CONFIG_SOC_IMX50=y
+CONFIG_SOC_IMX51=y
+CONFIG_SOC_IMX53=y
+CONFIG_SOC_IMX6Q=y
+CONFIG_SOC_IMX6SL=y
+CONFIG_SOC_IMX6SX=y
+CONFIG_SOC_VF610=y
+CONFIG_PCI=y
+CONFIG_PCI_IMX6=y
+CONFIG_PCCARD=y
+CONFIG_SMP=y
+CONFIG_VMSPLIT_2G=y
+CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_AEABI=y
+CONFIG_HIGHMEM=y
+CONFIG_CMA=y
+CONFIG_CMDLINE="noinitrd console=ttymxc0,115200"
+CONFIG_CPU_FREQ=y
+CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
+CONFIG_ARM_IMX6Q_CPUFREQ=y
+CONFIG_VFP=y
+CONFIG_NEON=y
+CONFIG_BINFMT_MISC=m
+CONFIG_PM_DEBUG=y
+CONFIG_PM_TEST_SUSPEND=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+# CONFIG_INET_LRO is not set
+CONFIG_IPV6=y
+CONFIG_NETFILTER=y
+CONFIG_CAN=y
+CONFIG_CAN_FLEXCAN=y
+CONFIG_BT=y
+CONFIG_BT_HCIUART=y
+CONFIG_BT_HCIUART_3WIRE=y
+CONFIG_CFG80211=y
+CONFIG_CFG80211_WEXT=y
+CONFIG_MAC80211=y
+CONFIG_RFKILL=y
+CONFIG_RFKILL_INPUT=y
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_STANDALONE is not set
+CONFIG_DMA_CMA=y
+CONFIG_IMX_WEIM=y
+CONFIG_CONNECTOR=y
+CONFIG_MTD=y
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_JEDECPROBE=y
+CONFIG_MTD_CFI_INTELEXT=y
+CONFIG_MTD_CFI_AMDSTD=y
+CONFIG_MTD_CFI_STAA=y
+CONFIG_MTD_PHYSMAP_OF=y
+CONFIG_MTD_DATAFLASH=y
+CONFIG_MTD_M25P80=y
+CONFIG_MTD_SST25L=y
+CONFIG_MTD_NAND=y
+CONFIG_MTD_NAND_GPMI_NAND=y
+CONFIG_MTD_NAND_MXC=y
+CONFIG_MTD_SPI_NOR=y
+CONFIG_SPI_FSL_QUADSPI=y
+CONFIG_MTD_UBI=y
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_SIZE=65536
+CONFIG_EEPROM_AT24=y
+CONFIG_EEPROM_AT25=y
+# CONFIG_SCSI_PROC_FS is not set
+CONFIG_BLK_DEV_SD=y
+CONFIG_SCSI_CONSTANTS=y
+CONFIG_SCSI_LOGGING=y
+CONFIG_SCSI_SCAN_ASYNC=y
+# CONFIG_SCSI_LOWLEVEL is not set
+CONFIG_ATA=y
+CONFIG_SATA_AHCI_PLATFORM=y
+CONFIG_AHCI_IMX=y
+CONFIG_PATA_IMX=y
+CONFIG_NETDEVICES=y
+# CONFIG_NET_VENDOR_BROADCOM is not set
+CONFIG_CS89x0=y
+CONFIG_CS89x0_PLATFORM=y
+# CONFIG_NET_VENDOR_FARADAY is not set
+# CONFIG_NET_VENDOR_INTEL is not set
+# CONFIG_NET_VENDOR_MARVELL is not set
+# CONFIG_NET_VENDOR_MICREL is not set
+# CONFIG_NET_VENDOR_MICROCHIP is not set
+# CONFIG_NET_VENDOR_NATSEMI is not set
+# CONFIG_NET_VENDOR_SEEQ is not set
+CONFIG_SMC91X=y
+CONFIG_SMC911X=y
+CONFIG_SMSC911X=y
+# CONFIG_NET_VENDOR_STMICRO is not set
+CONFIG_AT803X_PHY=y
+CONFIG_USB_PEGASUS=m
+CONFIG_USB_RTL8150=m
+CONFIG_USB_RTL8152=m
+CONFIG_USB_USBNET=m
+CONFIG_USB_NET_CDC_EEM=m
+CONFIG_PCMCIA_RAYCS=y
+CONFIG_BRCMFMAC=y
+# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
+CONFIG_INPUT_EVDEV=y
+CONFIG_INPUT_EVBUG=m
+CONFIG_KEYBOARD_GPIO=y
+CONFIG_KEYBOARD_IMX=y
+CONFIG_MOUSE_PS2=m
+CONFIG_MOUSE_PS2_ELANTECH=y
+CONFIG_INPUT_TOUCHSCREEN=y
+CONFIG_TOUCHSCREEN_EGALAX=y
+CONFIG_TOUCHSCREEN_MC13783=y
+CONFIG_TOUCHSCREEN_TSC2007=y
+CONFIG_TOUCHSCREEN_STMPE=y
+CONFIG_INPUT_MISC=y
+CONFIG_INPUT_MMA8450=y
+CONFIG_SERIO_SERPORT=m
+# CONFIG_LEGACY_PTYS is not set
+# CONFIG_DEVKMEM is not set
+CONFIG_SERIAL_IMX=y
+CONFIG_SERIAL_IMX_CONSOLE=y
+CONFIG_SERIAL_FSL_LPUART=y
+CONFIG_SERIAL_FSL_LPUART_CONSOLE=y
+CONFIG_HW_RANDOM=y
+# CONFIG_I2C_COMPAT is not set
+CONFIG_I2C_CHARDEV=y
+# CONFIG_I2C_HELPER_AUTO is not set
+CONFIG_I2C_ALGOPCF=m
+CONFIG_I2C_ALGOPCA=m
+CONFIG_I2C_IMX=y
+CONFIG_SPI=y
+CONFIG_SPI_IMX=y
+CONFIG_GPIO_SYSFS=y
+CONFIG_GPIO_MC9S08DZ60=y
+CONFIG_GPIO_STMPE=y
+CONFIG_POWER_SUPPLY=y
+CONFIG_POWER_RESET=y
+CONFIG_POWER_RESET_IMX=y
+CONFIG_POWER_RESET_SYSCON=y
+CONFIG_SENSORS_GPIO_FAN=y
+CONFIG_THERMAL=y
+CONFIG_CPU_THERMAL=y
+CONFIG_IMX_THERMAL=y
+CONFIG_WATCHDOG=y
+CONFIG_IMX2_WDT=y
+CONFIG_MFD_DA9052_I2C=y
+CONFIG_MFD_MC13XXX_SPI=y
+CONFIG_MFD_MC13XXX_I2C=y
+CONFIG_MFD_STMPE=y
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_FIXED_VOLTAGE=y
+CONFIG_REGULATOR_ANATOP=y
+CONFIG_REGULATOR_DA9052=y
+CONFIG_REGULATOR_GPIO=y
+CONFIG_REGULATOR_MC13783=y
+CONFIG_REGULATOR_MC13892=y
+CONFIG_REGULATOR_PFUZE100=y
+CONFIG_MEDIA_SUPPORT=y
+CONFIG_MEDIA_CAMERA_SUPPORT=y
+CONFIG_MEDIA_RC_SUPPORT=y
+CONFIG_RC_DEVICES=y
+CONFIG_IR_GPIO_CIR=y
+CONFIG_MEDIA_USB_SUPPORT=y
+CONFIG_USB_VIDEO_CLASS=m
+CONFIG_V4L_PLATFORM_DRIVERS=y
+CONFIG_SOC_CAMERA=y
+CONFIG_VIDEO_MX3=y
+CONFIG_V4L_MEM2MEM_DRIVERS=y
+CONFIG_VIDEO_CODA=y
+CONFIG_SOC_CAMERA_OV2640=y
+CONFIG_IMX_IPUV3_CORE=y
+CONFIG_DRM=y
+CONFIG_DRM_PANEL_SIMPLE=y
+CONFIG_DRM_IMX=y
+CONFIG_DRM_IMX_FB_HELPER=y
+CONFIG_DRM_IMX_PARALLEL_DISPLAY=y
+CONFIG_DRM_IMX_TVE=y
+CONFIG_DRM_IMX_LDB=y
+CONFIG_DRM_IMX_HDMI=y
+CONFIG_FB_MXS=y
+CONFIG_LCD_CLASS_DEVICE=y
+CONFIG_LCD_L4F00242T03=y
+CONFIG_LCD_PLATFORM=y
+CONFIG_BACKLIGHT_PWM=y
+CONFIG_BACKLIGHT_GPIO=y
+CONFIG_FRAMEBUFFER_CONSOLE=y
+CONFIG_LOGO=y
+CONFIG_SOUND=y
+CONFIG_SND=y
+CONFIG_SND_USB_AUDIO=m
+CONFIG_SND_SOC=y
+CONFIG_SND_SOC_FSL_SAI=y
+CONFIG_SND_IMX_SOC=y
+CONFIG_SND_SOC_PHYCORE_AC97=y
+CONFIG_SND_SOC_EUKREA_TLV320=y
+CONFIG_SND_SOC_IMX_WM8962=y
+CONFIG_SND_SOC_IMX_SGTL5000=y
+CONFIG_SND_SOC_IMX_SPDIF=y
+CONFIG_SND_SOC_IMX_MC13783=y
+CONFIG_SND_SOC_TLV320AIC3X=y
+CONFIG_SND_SIMPLE_CARD=y
+CONFIG_USB=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_MXC=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_CHIPIDEA=y
+CONFIG_USB_CHIPIDEA_UDC=y
+CONFIG_USB_CHIPIDEA_HOST=y
+CONFIG_USB_SERIAL=m
+CONFIG_USB_SERIAL_GENERIC=y
+CONFIG_USB_SERIAL_FTDI_SIO=m
+CONFIG_USB_SERIAL_OPTION=m
+CONFIG_USB_EHSET_TEST_FIXTURE=m
+CONFIG_NOP_USB_XCEIV=y
+CONFIG_USB_MXS_PHY=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_CONFIGFS=m
+CONFIG_USB_CONFIGFS_SERIAL=y
+CONFIG_USB_CONFIGFS_ACM=y
+CONFIG_USB_CONFIGFS_OBEX=y
+CONFIG_USB_CONFIGFS_NCM=y
+CONFIG_USB_CONFIGFS_ECM=y
+CONFIG_USB_CONFIGFS_ECM_SUBSET=y
+CONFIG_USB_CONFIGFS_RNDIS=y
+CONFIG_USB_CONFIGFS_EEM=y
+CONFIG_USB_CONFIGFS_MASS_STORAGE=y
+CONFIG_USB_CONFIGFS_F_LB_SS=y
+CONFIG_USB_CONFIGFS_F_FS=y
+CONFIG_USB_ZERO=m
+CONFIG_USB_ETH=m
+CONFIG_USB_G_NCM=m
+CONFIG_USB_GADGETFS=m
+CONFIG_USB_MASS_STORAGE=m
+CONFIG_USB_G_SERIAL=m
+CONFIG_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_PLTFM=y
+CONFIG_MMC_SDHCI_ESDHC_IMX=y
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_TIMER=y
+CONFIG_LEDS_TRIGGER_ONESHOT=y
+CONFIG_LEDS_TRIGGER_HEARTBEAT=y
+CONFIG_LEDS_TRIGGER_BACKLIGHT=y
+CONFIG_LEDS_TRIGGER_GPIO=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_INTF_DEV_UIE_EMUL=y
+CONFIG_RTC_DRV_DS1307=y
+CONFIG_RTC_DRV_ISL1208=y
+CONFIG_RTC_DRV_PCF8563=y
+CONFIG_RTC_DRV_MC13XXX=y
+CONFIG_RTC_DRV_MXC=y
+CONFIG_RTC_DRV_SNVS=y
+CONFIG_DMADEVICES=y
+CONFIG_IMX_SDMA=y
+CONFIG_MXS_DMA=y
+CONFIG_FSL_EDMA=y
+CONFIG_STAGING=y
+# CONFIG_IOMMU_SUPPORT is not set
+CONFIG_PWM=y
+CONFIG_PWM_IMX=y
+CONFIG_EXT2_FS=y
+CONFIG_EXT2_FS_XATTR=y
+CONFIG_EXT2_FS_POSIX_ACL=y
+CONFIG_EXT2_FS_SECURITY=y
+CONFIG_EXT3_FS=y
+CONFIG_EXT3_FS_POSIX_ACL=y
+CONFIG_EXT3_FS_SECURITY=y
+CONFIG_EXT4_FS=y
+CONFIG_EXT4_FS_POSIX_ACL=y
+CONFIG_EXT4_FS_SECURITY=y
+CONFIG_QUOTA=y
+CONFIG_QUOTA_NETLINK_INTERFACE=y
+# CONFIG_PRINT_QUOTA_WARNING is not set
+CONFIG_AUTOFS4_FS=y
+CONFIG_FUSE_FS=y
+CONFIG_ISO9660_FS=m
+CONFIG_JOLIET=y
+CONFIG_ZISOFS=y
+CONFIG_UDF_FS=m
+CONFIG_MSDOS_FS=m
+CONFIG_VFAT_FS=y
+CONFIG_TMPFS=y
+CONFIG_JFFS2_FS=y
+CONFIG_UBIFS_FS=y
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3_ACL=y
+CONFIG_NFS_V4=y
+CONFIG_ROOT_NFS=y
+CONFIG_NLS_DEFAULT="cp437"
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ASCII=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_NLS_ISO8859_15=m
+CONFIG_NLS_UTF8=y
+CONFIG_PRINTK_TIME=y
+CONFIG_DEBUG_FS=y
+CONFIG_MAGIC_SYSRQ=y
+# CONFIG_SCHED_DEBUG is not set
+CONFIG_PROVE_LOCKING=y
+# CONFIG_DEBUG_BUGVERBOSE is not set
+# CONFIG_FTRACE is not set
+# CONFIG_ARM_UNWIND is not set
+CONFIG_SECURITYFS=y
+# CONFIG_CRYPTO_ANSI_CPRNG is not set
+# CONFIG_CRYPTO_HW is not set
+CONFIG_CRC_CCITT=m
+CONFIG_CRC_T10DIF=y
+CONFIG_CRC7=m
+CONFIG_LIBCRC32C=m
+CONFIG_FONTS=y
+CONFIG_FONT_8x8=y
+CONFIG_FONT_8x16=y
diff --git a/recipes-kernel/linux/linux-riotboard_4.0.bb b/recipes-kernel/linux/linux-riotboard_4.0.bb
new file mode 100644
index 0000000..7ac63fc
--- /dev/null
+++ b/recipes-kernel/linux/linux-riotboard_4.0.bb
@@ -0,0 +1,15 @@
+SUMMARY = "Linux kernel for Embest RIoTboard"
+
+require recipes-kernel/linux/linux-imx.inc
+require recipes-kernel/linux/linux-dtb.inc
+
+DEPENDS += "lzop-native bc-native"
+
+SRCBRANCH = "patches-4.0"
+SRCREV = "48dfc7ce6933a593a651e8ce029cbc5bcca19382"
+
+SRC_URI = "git://github.com/Freescale/linux-fslc.git;branch=${SRCBRANCH} \
+           file://defconfig \
+"
+
+COMPATIBLE_MACHINE = "(imx6dl-riotboard)"
-- 
1.7.10.4

[meta-fsl-arm-extra][PATCH 2/2] linux-riotboard: Fix broken boot

[Nikolay Dimitrov]

Revert patch "mmc: sdhci-esdhc-imx: Call mmc_of_parse()",
commit 1b673ef39236db962ea7cff642949bb5bc485018,
repo https://github.com/Freescale/linux-fslc.

Gary Thomas reported that RIoTboard doesn't boot with commit 48dfc7c, and I
traced the issue to commit 1b673ef. I also verified that the board boots
properly with 1b673ef reverted.

Link: https://lists.yoctoproject.org/pipermail/meta-freescale/2015-April/013486.html # report

Signed-off-by: Nikolay Dimitrov <picmaster@mail.bg>
Cc: Gary Thomas <gary@mlbassoc.com>
Cc: Fabio Estevam <festevam@gmail.com>
---
 ...ert-mmc-sdhci-esdhc-imx-Call-mmc_of_parse.patch |   79 ++++++++++++++++++++
 recipes-kernel/linux/linux-riotboard_4.0.bb        |    1 +
 2 files changed, 80 insertions(+)
 create mode 100644 recipes-kernel/linux/linux-riotboard-4.0/0001-Revert-mmc-sdhci-esdhc-imx-Call-mmc_of_parse.patch

diff --git a/recipes-kernel/linux/linux-riotboard-4.0/0001-Revert-mmc-sdhci-esdhc-imx-Call-mmc_of_parse.patch b/recipes-kernel/linux/linux-riotboard-4.0/0001-Revert-mmc-sdhci-esdhc-imx-Call-mmc_of_parse.patch
new file mode 100644
index 0000000..5ad1700
--- /dev/null
+++ b/recipes-kernel/linux/linux-riotboard-4.0/0001-Revert-mmc-sdhci-esdhc-imx-Call-mmc_of_parse.patch
@@ -0,0 +1,79 @@
+From fc732f2762a98a97e84a40225edd4379d2cb1e6d Mon Sep 17 00:00:00 2001
+From: Nikolay Dimitrov <picmaster@mail.bg>
+Date: Mon, 27 Apr 2015 04:10:47 +0300
+Subject: [PATCH] Revert "mmc: sdhci-esdhc-imx: Call mmc_of_parse()"
+
+This reverts commit 1b673ef39236db962ea7cff642949bb5bc485018.
+
+Gary Thomas reported that RIoTboard doesn't boot with commit 48dfc7c, and I
+traced the issue to commit 1b673ef. I also verified that the board boots
+properly with 1b673ef reverted.
+
+Link: https://lists.yoctoproject.org/pipermail/meta-freescale/2015-April/013486.html # report
+
+Signed-off-by: Nikolay Dimitrov <picmaster@mail.bg>
+---
+ drivers/mmc/host/sdhci-esdhc-imx.c |   38 ++++++++++++++++++++++++++++++------
+ 1 file changed, 32 insertions(+), 6 deletions(-)
+
+diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
+index 1690d0b..10ef824 100644
+--- a/drivers/mmc/host/sdhci-esdhc-imx.c
++++ b/drivers/mmc/host/sdhci-esdhc-imx.c
+@@ -1009,9 +1009,40 @@ static int sdhci_esdhc_imx_probe(struct platform_device *pdev)
+ 					host->mmc->parent->platform_data);
+ 	}
+ 
++	/* write_protect */
++	if (boarddata->wp_type == ESDHC_WP_GPIO) {
++		err = mmc_gpio_request_ro(host->mmc, boarddata->wp_gpio);
++		if (err) {
++			dev_err(mmc_dev(host->mmc),
++				"failed to request write-protect gpio!\n");
++			goto disable_clk;
++		}
++		host->mmc->caps2 |= MMC_CAP2_RO_ACTIVE_HIGH;
++	}
++
+ 	/* card_detect */
+-	if (boarddata->cd_type == ESDHC_CD_CONTROLLER)
++	switch (boarddata->cd_type) {
++	case ESDHC_CD_GPIO:
++		err = mmc_gpio_request_cd(host->mmc, boarddata->cd_gpio, 0);
++		if (err) {
++			dev_err(mmc_dev(host->mmc),
++				"failed to request card-detect gpio!\n");
++			goto disable_clk;
++		}
++		/* fall through */
++
++	case ESDHC_CD_CONTROLLER:
++		/* we have a working card_detect back */
+ 		host->quirks &= ~SDHCI_QUIRK_BROKEN_CARD_DETECTION;
++		break;
++
++	case ESDHC_CD_PERMANENT:
++		host->mmc->caps |= MMC_CAP_NONREMOVABLE;
++		break;
++
++	case ESDHC_CD_NONE:
++		break;
++	}
+ 
+ 	switch (boarddata->max_bus_width) {
+ 	case 8:
+@@ -1044,11 +1075,6 @@ static int sdhci_esdhc_imx_probe(struct platform_device *pdev)
+ 		host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
+ 	}
+ 
+-	/* call to generic mmc_of_parse to support additional capabilities */
+-	err = mmc_of_parse(host->mmc);
+-	if (err)
+-		goto disable_clk;
+-
+ 	err = sdhci_add_host(host);
+ 	if (err)
+ 		goto disable_clk;
+-- 
+1.7.10.4
+
diff --git a/recipes-kernel/linux/linux-riotboard_4.0.bb b/recipes-kernel/linux/linux-riotboard_4.0.bb
index 7ac63fc..47648bb 100644
--- a/recipes-kernel/linux/linux-riotboard_4.0.bb
+++ b/recipes-kernel/linux/linux-riotboard_4.0.bb
@@ -10,6 +10,7 @@ SRCREV = "48dfc7ce6933a593a651e8ce029cbc5bcca19382"
 
 SRC_URI = "git://github.com/Freescale/linux-fslc.git;branch=${SRCBRANCH} \
            file://defconfig \
+           file://0001-Revert-mmc-sdhci-esdhc-imx-Call-mmc_of_parse.patch \
 "
 
 COMPATIBLE_MACHINE = "(imx6dl-riotboard)"
-- 
1.7.10.4

Re: [meta-fsl-arm-extra][PATCH 1/2] linux-riotboard: Add separate riotboard kernel recipe

[Otavio Salvador]

Hello Nikolay,

On Mon, Apr 27, 2015 at 1:35 AM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
> Add dedicated RIoTboard kernel recipe for easier maintenance and patch
> cherry-picking.
>
> Signed-off-by: Nikolay Dimitrov <picmaster@mail.bg>

I want to check with you if you really want to have a dedicated
recipe. For bugfixes (as now) you can use a bbappend as a temporary
solution and, at end of the day, easy to remove once this is fixed in
the kernel.

Please let me know your thoughts...

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [meta-fsl-arm-extra][PATCH 1/2] linux-riotboard: Add separate riotboard kernel recipe

[Daiane Angolini]

On Mon, Apr 27, 2015 at 1:35 AM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
> Add dedicated RIoTboard kernel recipe for easier maintenance and patch
> cherry-picking.

> diff --git a/recipes-kernel/linux/linux-riotboard_4.0.bb b/recipes-kernel/linux/linux-riotboard_4.0.bb
> new file mode 100644
> index 0000000..7ac63fc
> --- /dev/null
> +++ b/recipes-kernel/linux/linux-riotboard_4.0.bb
> @@ -0,0 +1,15 @@
> +SUMMARY = "Linux kernel for Embest RIoTboard"

In case you really need a dedicated kernel, please use a DESCRIPTION
and elaborate it. What is the history of this kernel, why do you need
a different kernel, what is the difference of this kernel, and in case
it is really a 4.0 kernel why the chages are not upstreamed are
possible questions to be answerd in the DESCRIPTION.

> +
> +require recipes-kernel/linux/linux-imx.inc
> +require recipes-kernel/linux/linux-dtb.inc
> +
> +DEPENDS += "lzop-native bc-native"
> +
> +SRCBRANCH = "patches-4.0"
> +SRCREV = "48dfc7ce6933a593a651e8ce029cbc5bcca19382"
> +
> +SRC_URI = "git://github.com/Freescale/linux-fslc.git;branch=${SRCBRANCH} \
> +           file://defconfig \

I don't understand why are you using the same git repository as
linux-fslc, can you, please elaborate/explain your idea?

And, it also means your commit log is weak and you can elaborate it for v2?

Daiane

> +"
> +
> +COMPATIBLE_MACHINE = "(imx6dl-riotboard)"
> --
> 1.7.10.4
>
> --
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale

Re: [meta-fsl-arm-extra][PATCH 1/2] linux-riotboard: Add separate riotboard kernel recipe

[Nikolay Dimitrov]

Hi Otavio,

On 04/27/2015 02:40 PM, Otavio Salvador wrote:
> Hello Nikolay,
>
> On Mon, Apr 27, 2015 at 1:35 AM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
>> Add dedicated RIoTboard kernel recipe for easier maintenance and patch
>> cherry-picking.
>>
>> Signed-off-by: Nikolay Dimitrov <picmaster@mail.bg>
>
> I want to check with you if you really want to have a dedicated
> recipe. For bugfixes (as now) you can use a bbappend as a temporary
> solution and, at end of the day, easy to remove once this is fixed in
> the kernel.
>
> Please let me know your thoughts...

Do you mean something like this (bbappend in meta-fsl-arm-extra)?

diff --git a/recipes-kernel/linux/linux-fslc_4.0.bbappend 
b/recipes-kernel/linux/linux-fslc_4.0.bbappend
new file mode 100644
index 0000000..d7a4e72
--- /dev/null
+++ b/recipes-kernel/linux/linux-fslc_4.0.bbappend
@@ -0,0 +1,3 @@
+FILESEXTRAPATHS_append := ":${THISDIR}/${PN}"
+
+SRC_URI_imx6dl-riotboard = "file://riotboard-specific.patch"

Well, imho the difference between bbappending and having a separate
recipe is that the bbappending mechanism is retro-reactive - I can
bbappend patches to linux-fslc but in the meantime the board support
will be broken.

Maintaining a separate kernel recipe for riotboard is a proactive way,
imho. When linux-fslc updates are happening, they won't immediately
break the riotboard, and after I test the updates I can update SRC_REV
to point it to a specific working commit, or as in my case point
SRC_REV to the latest commit and revert just one specific patch. The
advantage is that all the time the board support will be working.

This was my motivation for the patch. Please tell me if there are any 
drawback of having a separate board kernel recipe.

Regards,
Nikolay

Re: [meta-fsl-arm-extra][PATCH 1/2] linux-riotboard: Add separate riotboard kernel recipe

[Nikolay Dimitrov]

Hi Daiane,

On 04/27/2015 02:54 PM, Daiane Angolini wrote:
> On Mon, Apr 27, 2015 at 1:35 AM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
>> Add dedicated RIoTboard kernel recipe for easier maintenance and patch
>> cherry-picking.
>
>> diff --git a/recipes-kernel/linux/linux-riotboard_4.0.bb b/recipes-kernel/linux/linux-riotboard_4.0.bb
>> new file mode 100644
>> index 0000000..7ac63fc
>> --- /dev/null
>> +++ b/recipes-kernel/linux/linux-riotboard_4.0.bb
>> @@ -0,0 +1,15 @@
>> +SUMMARY = "Linux kernel for Embest RIoTboard"
>
> In case you really need a dedicated kernel, please use a DESCRIPTION
> and elaborate it. What is the history of this kernel, why do you need
> a different kernel, what is the difference of this kernel, and in case
> it is really a 4.0 kernel why the chages are not upstreamed are
> possible questions to be answerd in the DESCRIPTION.

OK, will do.

>> +
>> +require recipes-kernel/linux/linux-imx.inc
>> +require recipes-kernel/linux/linux-dtb.inc
>> +
>> +DEPENDS += "lzop-native bc-native"
>> +
>> +SRCBRANCH = "patches-4.0"
>> +SRCREV = "48dfc7ce6933a593a651e8ce029cbc5bcca19382"
>> +
>> +SRC_URI = "git://github.com/Freescale/linux-fslc.git;branch=${SRCBRANCH} \
>> +           file://defconfig \
>
> I don't understand why are you using the same git repository as
> linux-fslc, can you, please elaborate/explain your idea?

I wanted to revert a specific linux-fslc patch while still reusing as
much code as possible (and not cloning the repo). I can also switch
entirely to mainline and stop using linux-fslc, if you think that's an
issue.

> And, it also means your commit log is weak and you can elaborate it for v2?
>
> Daiane
>
>> +"
>> +
>> +COMPATIBLE_MACHINE = "(imx6dl-riotboard)"
>> --
>> 1.7.10.4
>>
>> --

Thanks for the feedback. I'll take it into account for v2, once Otavio
also acknowledges the need for separate kernel recipe.

Regards,
Nikolay

Re: [meta-fsl-arm-extra][PATCH 1/2] linux-riotboard: Add separate riotboard kernel recipe

[Otavio Salvador]

On Mon, Apr 27, 2015 at 12:27 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
> On 04/27/2015 02:40 PM, Otavio Salvador wrote:
>>
>> Hello Nikolay,
>>
>> On Mon, Apr 27, 2015 at 1:35 AM, Nikolay Dimitrov <picmaster@mail.bg>
>> wrote:
>>>
>>> Add dedicated RIoTboard kernel recipe for easier maintenance and patch
>>> cherry-picking.
>>>
>>> Signed-off-by: Nikolay Dimitrov <picmaster@mail.bg>
>>
>>
>> I want to check with you if you really want to have a dedicated
>> recipe. For bugfixes (as now) you can use a bbappend as a temporary
>> solution and, at end of the day, easy to remove once this is fixed in
>> the kernel.
>>
>> Please let me know your thoughts...
>
>
> Do you mean something like this (bbappend in meta-fsl-arm-extra)?
>
> diff --git a/recipes-kernel/linux/linux-fslc_4.0.bbappend
> b/recipes-kernel/linux/linux-fslc_4.0.bbappend
> new file mode 100644
> index 0000000..d7a4e72
> --- /dev/null
> +++ b/recipes-kernel/linux/linux-fslc_4.0.bbappend
> @@ -0,0 +1,3 @@
> +FILESEXTRAPATHS_append := ":${THISDIR}/${PN}"
> +
> +SRC_URI_imx6dl-riotboard = "file://riotboard-specific.patch"

Yes.

> Well, imho the difference between bbappending and having a separate
> recipe is that the bbappending mechanism is retro-reactive - I can
> bbappend patches to linux-fslc but in the meantime the board support
> will be broken.
>
> Maintaining a separate kernel recipe for riotboard is a proactive way,
> imho. When linux-fslc updates are happening, they won't immediately
> break the riotboard, and after I test the updates I can update SRC_REV
> to point it to a specific working commit, or as in my case point
> SRC_REV to the latest commit and revert just one specific patch. The
> advantage is that all the time the board support will be working.
>
> This was my motivation for the patch. Please tell me if there are any
> drawback of having a separate board kernel recipe.

Maintenance burden.

Your thought is right but what should have been done was people to
report this issue when we included 4.0 recipe.

For now a bbappend would work as a band-aid while the real fix is
being cooked.  I usually do not do design for the exception and I
believe linux-fslc once fixed will be kept working for the board.

This is really up to you but I think a boot test every time we prepare
a bump linux-fslc would be enough to iron out the need of a specific
recipe.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [meta-fsl-arm-extra][PATCH 1/2] linux-riotboard: Add separate riotboard kernel recipe

[Daiane Angolini]

On Mon, Apr 27, 2015 at 1:26 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Mon, Apr 27, 2015 at 12:27 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
>> On 04/27/2015 02:40 PM, Otavio Salvador wrote:
>>>
>>> Hello Nikolay,
>>>
>>> On Mon, Apr 27, 2015 at 1:35 AM, Nikolay Dimitrov <picmaster@mail.bg>
>>> wrote:
>>>>
>>>> Add dedicated RIoTboard kernel recipe for easier maintenance and patch
>>>> cherry-picking.
>>>>
>>>> Signed-off-by: Nikolay Dimitrov <picmaster@mail.bg>
>>>
>>>
>>> I want to check with you if you really want to have a dedicated
>>> recipe. For bugfixes (as now) you can use a bbappend as a temporary
>>> solution and, at end of the day, easy to remove once this is fixed in
>>> the kernel.
>>>
>>> Please let me know your thoughts...
>>
>>
>> Do you mean something like this (bbappend in meta-fsl-arm-extra)?
>>
>> diff --git a/recipes-kernel/linux/linux-fslc_4.0.bbappend
>> b/recipes-kernel/linux/linux-fslc_4.0.bbappend
>> new file mode 100644
>> index 0000000..d7a4e72
>> --- /dev/null
>> +++ b/recipes-kernel/linux/linux-fslc_4.0.bbappend
>> @@ -0,0 +1,3 @@
>> +FILESEXTRAPATHS_append := ":${THISDIR}/${PN}"
>> +
>> +SRC_URI_imx6dl-riotboard = "file://riotboard-specific.patch"
>
> Yes.
>
>> Well, imho the difference between bbappending and having a separate
>> recipe is that the bbappending mechanism is retro-reactive - I can
>> bbappend patches to linux-fslc but in the meantime the board support
>> will be broken.
>>
>> Maintaining a separate kernel recipe for riotboard is a proactive way,
>> imho. When linux-fslc updates are happening, they won't immediately
>> break the riotboard, and after I test the updates I can update SRC_REV
>> to point it to a specific working commit, or as in my case point
>> SRC_REV to the latest commit and revert just one specific patch. The
>> advantage is that all the time the board support will be working.
>>
>> This was my motivation for the patch. Please tell me if there are any
>> drawback of having a separate board kernel recipe.
>
> Maintenance burden.
>
> Your thought is right but what should have been done was people to
> report this issue when we included 4.0 recipe.
>
> For now a bbappend would work as a band-aid while the real fix is
> being cooked.  I usually do not do design for the exception and I
> believe linux-fslc once fixed will be kept working for the board.
>
> This is really up to you but I think a boot test every time we prepare
> a bump linux-fslc would be enough to iron out the need of a specific
> recipe.

Otavio, I really don't like to see more and more linux providers on
top of linux-fslc. We already have too much linux providers.

For me it looks like a temporary fix being assumed mainline.

Daiane
>
> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
> --
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale

Re: [meta-fsl-arm-extra][PATCH 1/2] linux-riotboard: Add separate riotboard kernel recipe

[Otavio Salvador]

On Mon, Apr 27, 2015 at 1:54 PM, Daiane Angolini <daiane.list@gmail.com> wrote:
> On Mon, Apr 27, 2015 at 1:26 PM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
>> On Mon, Apr 27, 2015 at 12:27 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
>>> On 04/27/2015 02:40 PM, Otavio Salvador wrote:
>>>>
>>>> Hello Nikolay,
>>>>
>>>> On Mon, Apr 27, 2015 at 1:35 AM, Nikolay Dimitrov <picmaster@mail.bg>
>>>> wrote:
>>>>>
>>>>> Add dedicated RIoTboard kernel recipe for easier maintenance and patch
>>>>> cherry-picking.
>>>>>
>>>>> Signed-off-by: Nikolay Dimitrov <picmaster@mail.bg>
>>>>
>>>>
>>>> I want to check with you if you really want to have a dedicated
>>>> recipe. For bugfixes (as now) you can use a bbappend as a temporary
>>>> solution and, at end of the day, easy to remove once this is fixed in
>>>> the kernel.
>>>>
>>>> Please let me know your thoughts...
>>>
>>>
>>> Do you mean something like this (bbappend in meta-fsl-arm-extra)?
>>>
>>> diff --git a/recipes-kernel/linux/linux-fslc_4.0.bbappend
>>> b/recipes-kernel/linux/linux-fslc_4.0.bbappend
>>> new file mode 100644
>>> index 0000000..d7a4e72
>>> --- /dev/null
>>> +++ b/recipes-kernel/linux/linux-fslc_4.0.bbappend
>>> @@ -0,0 +1,3 @@
>>> +FILESEXTRAPATHS_append := ":${THISDIR}/${PN}"
>>> +
>>> +SRC_URI_imx6dl-riotboard = "file://riotboard-specific.patch"
>>
>> Yes.
>>
>>> Well, imho the difference between bbappending and having a separate
>>> recipe is that the bbappending mechanism is retro-reactive - I can
>>> bbappend patches to linux-fslc but in the meantime the board support
>>> will be broken.
>>>
>>> Maintaining a separate kernel recipe for riotboard is a proactive way,
>>> imho. When linux-fslc updates are happening, they won't immediately
>>> break the riotboard, and after I test the updates I can update SRC_REV
>>> to point it to a specific working commit, or as in my case point
>>> SRC_REV to the latest commit and revert just one specific patch. The
>>> advantage is that all the time the board support will be working.
>>>
>>> This was my motivation for the patch. Please tell me if there are any
>>> drawback of having a separate board kernel recipe.
>>
>> Maintenance burden.
>>
>> Your thought is right but what should have been done was people to
>> report this issue when we included 4.0 recipe.
>>
>> For now a bbappend would work as a band-aid while the real fix is
>> being cooked.  I usually do not do design for the exception and I
>> believe linux-fslc once fixed will be kept working for the board.
>>
>> This is really up to you but I think a boot test every time we prepare
>> a bump linux-fslc would be enough to iron out the need of a specific
>> recipe.
>
> Otavio, I really don't like to see more and more linux providers on
> top of linux-fslc. We already have too much linux providers.
>
> For me it looks like a temporary fix being assumed mainline.

So the bbappend for a workaround while linux-fslc is proper fixed
seems to be the way to go. I second your view I also prefer to not
have many kernel providers except if there are real reasons for it. In
Linux mainline case I see none.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [meta-fsl-arm-extra][PATCH 1/2] linux-riotboard: Add separate riotboard kernel recipe

[Nikolay Dimitrov]

Hi Daiane, Otavio,

On 04/27/2015 07:59 PM, Otavio Salvador wrote:
> On Mon, Apr 27, 2015 at 1:54 PM, Daiane Angolini
> <daiane.list@gmail.com> wrote:
>> On Mon, Apr 27, 2015 at 1:26 PM, Otavio Salvador
>> <otavio@ossystems.com.br> wrote:
>>> On Mon, Apr 27, 2015 at 12:27 PM, Nikolay Dimitrov
>>> <picmaster@mail.bg> wrote:
>>>> On 04/27/2015 02:40 PM, Otavio Salvador wrote:
>>>>>
>>>>> Hello Nikolay,
>>>>>
>>>>> On Mon, Apr 27, 2015 at 1:35 AM, Nikolay Dimitrov
>>>>> <picmaster@mail.bg> wrote:
>>>>>>
>>>>>> Add dedicated RIoTboard kernel recipe for easier
>>>>>> maintenance and patch cherry-picking.
>>>>>>
>>>>>> Signed-off-by: Nikolay Dimitrov <picmaster@mail.bg>
>>>>>
>>>>>
>>>>> I want to check with you if you really want to have a
>>>>> dedicated recipe. For bugfixes (as now) you can use a
>>>>> bbappend as a temporary solution and, at end of the day, easy
>>>>> to remove once this is fixed in the kernel.
>>>>>
>>>>> Please let me know your thoughts...
>>>>
>>>>
>>>> Do you mean something like this (bbappend in
>>>> meta-fsl-arm-extra)?
>>>>
>>>> diff --git a/recipes-kernel/linux/linux-fslc_4.0.bbappend
>>>> b/recipes-kernel/linux/linux-fslc_4.0.bbappend new file mode
>>>> 100644 index 0000000..d7a4e72 --- /dev/null +++
>>>> b/recipes-kernel/linux/linux-fslc_4.0.bbappend @@ -0,0 +1,3 @@
>>>> +FILESEXTRAPATHS_append := ":${THISDIR}/${PN}" +
>>>> +SRC_URI_imx6dl-riotboard = "file://riotboard-specific.patch"
>>>
>>> Yes.
>>>
>>>> Well, imho the difference between bbappending and having a
>>>> separate recipe is that the bbappending mechanism is
>>>> retro-reactive - I can bbappend patches to linux-fslc but in
>>>> the meantime the board support will be broken.
>>>>
>>>> Maintaining a separate kernel recipe for riotboard is a
>>>> proactive way, imho. When linux-fslc updates are happening,
>>>> they won't immediately break the riotboard, and after I test
>>>> the updates I can update SRC_REV to point it to a specific
>>>> working commit, or as in my case point SRC_REV to the latest
>>>> commit and revert just one specific patch. The advantage is
>>>> that all the time the board support will be working.
>>>>
>>>> This was my motivation for the patch. Please tell me if there
>>>> are any drawback of having a separate board kernel recipe.
>>>
>>> Maintenance burden.
>>>
>>> Your thought is right but what should have been done was people
>>> to report this issue when we included 4.0 recipe.
>>>
>>> For now a bbappend would work as a band-aid while the real fix
>>> is being cooked.  I usually do not do design for the exception
>>> and I believe linux-fslc once fixed will be kept working for the
>>> board.
>>>
>>> This is really up to you but I think a boot test every time we
>>> prepare a bump linux-fslc would be enough to iron out the need of
>>> a specific recipe.
>>
>> Otavio, I really don't like to see more and more linux providers
>> on top of linux-fslc. We already have too much linux providers.

@Daiane, would you like to elaborate on this?

>> For me it looks like a temporary fix being assumed mainline.
>
> So the bbappend for a workaround while linux-fslc is proper fixed
> seems to be the way to go. I second your view I also prefer to not
> have many kernel providers except if there are real reasons for it.
> In Linux mainline case I see none.
>

OK.

Regards,
Nikolay

Re: [meta-fsl-arm-extra][PATCH 1/2] linux-riotboard: Add separate riotboard kernel recipe

[Daiane Angolini]

On Tue, Apr 28, 2015 at 1:14 AM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
> Hi Daiane, Otavio,
>
>
> On 04/27/2015 07:59 PM, Otavio Salvador wrote:
>>
>> On Mon, Apr 27, 2015 at 1:54 PM, Daiane Angolini
>> <daiane.list@gmail.com> wrote:
>>>
>>> On Mon, Apr 27, 2015 at 1:26 PM, Otavio Salvador
>>> <otavio@ossystems.com.br> wrote:
>>>>
>>>> On Mon, Apr 27, 2015 at 12:27 PM, Nikolay Dimitrov
>>>> <picmaster@mail.bg> wrote:
>>>>>
>>>>> On 04/27/2015 02:40 PM, Otavio Salvador wrote:
>>>>>>
>>>>>>
>>>>>> Hello Nikolay,
>>>>>>
>>>>>> On Mon, Apr 27, 2015 at 1:35 AM, Nikolay Dimitrov
>>>>>> <picmaster@mail.bg> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Add dedicated RIoTboard kernel recipe for easier
>>>>>>> maintenance and patch cherry-picking.
>>>>>>>
>>>>>>> Signed-off-by: Nikolay Dimitrov <picmaster@mail.bg>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I want to check with you if you really want to have a
>>>>>> dedicated recipe. For bugfixes (as now) you can use a
>>>>>> bbappend as a temporary solution and, at end of the day, easy
>>>>>> to remove once this is fixed in the kernel.
>>>>>>
>>>>>> Please let me know your thoughts...
>>>>>
>>>>>
>>>>>
>>>>> Do you mean something like this (bbappend in
>>>>> meta-fsl-arm-extra)?
>>>>>
>>>>> diff --git a/recipes-kernel/linux/linux-fslc_4.0.bbappend
>>>>> b/recipes-kernel/linux/linux-fslc_4.0.bbappend new file mode
>>>>> 100644 index 0000000..d7a4e72 --- /dev/null +++
>>>>> b/recipes-kernel/linux/linux-fslc_4.0.bbappend @@ -0,0 +1,3 @@
>>>>> +FILESEXTRAPATHS_append := ":${THISDIR}/${PN}" +
>>>>> +SRC_URI_imx6dl-riotboard = "file://riotboard-specific.patch"
>>>>
>>>>
>>>> Yes.
>>>>
>>>>> Well, imho the difference between bbappending and having a
>>>>> separate recipe is that the bbappending mechanism is
>>>>> retro-reactive - I can bbappend patches to linux-fslc but in
>>>>> the meantime the board support will be broken.
>>>>>
>>>>> Maintaining a separate kernel recipe for riotboard is a
>>>>> proactive way, imho. When linux-fslc updates are happening,
>>>>> they won't immediately break the riotboard, and after I test
>>>>> the updates I can update SRC_REV to point it to a specific
>>>>> working commit, or as in my case point SRC_REV to the latest
>>>>> commit and revert just one specific patch. The advantage is
>>>>> that all the time the board support will be working.
>>>>>
>>>>> This was my motivation for the patch. Please tell me if there
>>>>> are any drawback of having a separate board kernel recipe.
>>>>
>>>>
>>>> Maintenance burden.
>>>>
>>>> Your thought is right but what should have been done was people
>>>> to report this issue when we included 4.0 recipe.
>>>>
>>>> For now a bbappend would work as a band-aid while the real fix
>>>> is being cooked.  I usually do not do design for the exception
>>>> and I believe linux-fslc once fixed will be kept working for the
>>>> board.
>>>>
>>>> This is really up to you but I think a boot test every time we
>>>> prepare a bump linux-fslc would be enough to iron out the need of
>>>> a specific recipe.
>>>
>>>
>>> Otavio, I really don't like to see more and more linux providers
>>> on top of linux-fslc. We already have too much linux providers.
>
>
> @Daiane, would you like to elaborate on this?
>
>>> For me it looks like a temporary fix being assumed mainline.
>>
>>
>> So the bbappend for a workaround while linux-fslc is proper fixed
>> seems to be the way to go. I second your view I also prefer to not
>> have many kernel providers except if there are real reasons for it.
>> In Linux mainline case I see none.
>>

I have been thinking about this topic, and I think I have it
elaborated in my mind already.

My problem is not exactly having another linux provider. My problem is
having an implicit fork of linux-fslc.

The base argument used by Otavio is that you are the machine
mantainer, you decide which kernel you want to you, and I agree with
it.

However, you are not proposing a new kernel provider. You are
proposing a new abstraction layer between your machine and the
linux-fslc. Or, in other words, an implicit fork of linux-fslc.

If you were looking for upstreaming. You would not propose such thing.
Because, when targeting the upstream, you work upstream.

Otavio proposed a bbappend. An explicit way of forking linux-fslc.

Another way would be a fork. For example, if the goal is to add riot
support on top of linux-imx (3.14), the better way would be a fork of
linux-imx adding a patchset to support riot. In this case (linux-imx)
there is no formal upstreaming process.

linux-fslc is itself a fork of kernel.org. A stash we use for 2 main
goals, keep the needed backport patches while it's been accepted into
kernel.org stable releases and keep the cosmetic patches which does
not make sense for kernel.org (i.e. setting the default sdcard number
for boot, setting the default bootargs, and so on)

Maybe, it makes sense for riot to have a fork, being it based on
linux-imx, or linux-fslc or linux-daiane or kernel.org.
In this case, the machine mantainer is the one to decide what to do,
and what to upstream to kernel.org. However, I want to emphasize that
keeping a fork is not an easy task.

For me, only reverting a patch that has been debugged is not a strong
enough argument to have a fork (and all the work behind it). But I
cannot see your future plans for the board.

I have had access to the riot board for really few days, I've taken
advance of each of them to get this board upstreamed asap, because I
knew someone would need and like it. Unfortunately, I don't have the
hardware anymore, so I cannot help the way I would like.

I really hope meta-fsl-arm-extra machine recipe to be only a enabler
for the kernel development focusing on this board.

Regards,
Daiane

>
> OK.
>
> Regards,
> Nikolay

Re: [meta-fsl-arm-extra][PATCH 1/2] linux-riotboard: Add separate riotboard kernel recipe

[Fabio Estevam]

On Tue, Apr 28, 2015 at 10:46 AM, Daiane Angolini <daiane.list@gmail.com> wrote:

> For me, only reverting a patch that has been debugged is not a strong
> enough argument to have a fork (and all the work behind it). But I
> cannot see your future plans for the board.

Just to add on this: I sent a patch that fixes the reported regression
and Gary confirmed it works, so it seems linux-fslc is useable again
with riotboard.

Regards,

Fabio Estevam

Re: [meta-fsl-arm-extra][PATCH 1/2] linux-riotboard: Add separate riotboard kernel recipe

[Gary Thomas]

On 2015-04-28 07:53, Fabio Estevam wrote:
> On Tue, Apr 28, 2015 at 10:46 AM, Daiane Angolini <daiane.list@gmail.com> wrote:
>
>> For me, only reverting a patch that has been debugged is not a strong
>> enough argument to have a fork (and all the work behind it). But I
>> cannot see your future plans for the board.
>
> Just to add on this: I sent a patch that fixes the reported regression
> and Gary confirmed it works, so it seems linux-fslc is useable again
> with riotboard.

How is this going to be handled?  Will you apply your patch
upstream and update the meta-fsl-arm recipe, or just add the
patch there?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: [meta-fsl-arm-extra][PATCH 1/2] linux-riotboard: Add separate riotboard kernel recipe

[Fabio Estevam]

On Tue, Apr 28, 2015 at 10:57 AM, Gary Thomas <gary@mlbassoc.com> wrote:

> How is this going to be handled?  Will you apply your patch
> upstream and update the meta-fsl-arm recipe, or just add the
> patch there?

I still need to test it on warpboard. Will do it later later today as
I don't have access to it here at the moment. After I confirm it also
works there, then we can ask Otavio to apply it in linux-fslc.

Regards,

Fabio Estevam

Re: [meta-fsl-arm-extra][PATCH 1/2] linux-riotboard: Add separate riotboard kernel recipe

[Fabio Estevam]

Hi Gary and Nikolay,

On Tue, Apr 28, 2015 at 11:01 AM, Fabio Estevam <festevam@gmail.com> wrote:
> On Tue, Apr 28, 2015 at 10:57 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>
>> How is this going to be handled?  Will you apply your patch
>> upstream and update the meta-fsl-arm recipe, or just add the
>> patch there?
>
> I still need to test it on warpboard. Will do it later later today as
> I don't have access to it here at the moment. After I confirm it also
> works there, then we can ask Otavio to apply it in linux-fslc.

Please discard my previous workaround patch.

Otavio found a commit from 4.1-rc1 that makes this problem go away:

commit 04e079cf6b24c794bbc52b04b370f84cb728540e
Author: Scott Branden <sbranden@broadcom.com>
Date:   Tue Mar 10 11:35:10 2015 -0700

    mmc: sdhci: fix card presence logic in sdhci_request function

    The sdhci_request function should consider a non-removable device
    always present.
    Call the correct logic already available in sdhci_do_get_cd function.

    This fixes some logic paths where MMC requests are being made to
    non-removable devices that do not have the card detect pin connected
    on the hardware as it is non-removable.

    Signed-off-by: Scott Branden <sbranden@broadcom.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

Will also ask in the linux-mmc if this should be applied to stable.

Applying it on top of 4.0 linux-fslc makes the SD card detection
problem go away.

Thanks Otavio!

Regards,

Fabio Estevam

Re: [meta-fsl-arm-extra][PATCH 1/2] linux-riotboard: Add separate riotboard kernel recipe

[Gary Thomas]

On 2015-04-28 09:39, Fabio Estevam wrote:
> Hi Gary and Nikolay,
>
> On Tue, Apr 28, 2015 at 11:01 AM, Fabio Estevam <festevam@gmail.com> wrote:
>> On Tue, Apr 28, 2015 at 10:57 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>
>>> How is this going to be handled?  Will you apply your patch
>>> upstream and update the meta-fsl-arm recipe, or just add the
>>> patch there?
>>
>> I still need to test it on warpboard. Will do it later later today as
>> I don't have access to it here at the moment. After I confirm it also
>> works there, then we can ask Otavio to apply it in linux-fslc.
>
> Please discard my previous workaround patch.
>
> Otavio found a commit from 4.1-rc1 that makes this problem go away:
>
> commit 04e079cf6b24c794bbc52b04b370f84cb728540e
> Author: Scott Branden <sbranden@broadcom.com>
> Date:   Tue Mar 10 11:35:10 2015 -0700
>
>      mmc: sdhci: fix card presence logic in sdhci_request function
>
>      The sdhci_request function should consider a non-removable device
>      always present.
>      Call the correct logic already available in sdhci_do_get_cd function.
>
>      This fixes some logic paths where MMC requests are being made to
>      non-removable devices that do not have the card detect pin connected
>      on the hardware as it is non-removable.
>
>      Signed-off-by: Scott Branden <sbranden@broadcom.com>
>      Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>
> Will also ask in the linux-mmc if this should be applied to stable.
>
> Applying it on top of 4.0 linux-fslc makes the SD card detection
> problem go away.
>

Works great on my RIoTboard, thanks!

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: [meta-fsl-arm-extra][PATCH 1/2] linux-riotboard: Add separate riotboard kernel recipe

[Otavio Salvador]

On Tue, Apr 28, 2015 at 12:39 PM, Fabio Estevam <festevam@gmail.com> wrote:
...
> Applying it on top of 4.0 linux-fslc makes the SD card detection
> problem go away.
...

I have applied this to linux-fslc tree and applied this to master and
fido branches. It should work out of box now.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [meta-fsl-arm-extra][PATCH 1/2] linux-riotboard: Add separate riotboard kernel recipe

[Nikolay Dimitrov]

Hi Otavio,

On 04/28/2015 07:42 PM, Otavio Salvador wrote:
> On Tue, Apr 28, 2015 at 12:39 PM, Fabio Estevam <festevam@gmail.com> wrote:
> ...
>> Applying it on top of 4.0 linux-fslc makes the SD card detection
>> problem go away.
> ...
>
> I have applied this to linux-fslc tree and applied this to master and
> fido branches. It should work out of box now.

Mainline code worked out of the box in the first place. I'm now
wondering what's the best way to go forward, as we did a lot of work
just to return to the starting point.

Regards.
Nikolay

Re: [meta-fsl-arm-extra][PATCH 1/2] linux-riotboard: Add separate riotboard kernel recipe

[Otavio Salvador]

Hello Nikolay,

On Tue, Apr 28, 2015 at 2:10 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
> On 04/28/2015 07:42 PM, Otavio Salvador wrote:
>>
>> On Tue, Apr 28, 2015 at 12:39 PM, Fabio Estevam <festevam@gmail.com>
>> wrote:
>> ...
>>>
>>> Applying it on top of 4.0 linux-fslc makes the SD card detection
>>> problem go away.
>>
>> ...
>>
>> I have applied this to linux-fslc tree and applied this to master and
>> fido branches. It should work out of box now.
>
>
> Mainline code worked out of the box in the first place. I'm now
> wondering what's the best way to go forward, as we did a lot of work
> just to return to the starting point.

This was a regression when enabling support for BT/WIFI reset handling
which Fabio did to support WaRP. The beauty here we support in a
single kernel a huge set of boards and already using the mainline mode
for them.


-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [meta-fsl-arm-extra][PATCH 1/2] linux-riotboard: Add separate riotboard kernel recipe

[Nikolay Dimitrov]

Hi Otavio,

On 04/28/2015 08:12 PM, Otavio Salvador wrote:
> Hello Nikolay,
>
> On Tue, Apr 28, 2015 at 2:10 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
>> On 04/28/2015 07:42 PM, Otavio Salvador wrote:
>>>
>>> On Tue, Apr 28, 2015 at 12:39 PM, Fabio Estevam <festevam@gmail.com>
>>> wrote:
>>> ...
>>>>
>>>> Applying it on top of 4.0 linux-fslc makes the SD card detection
>>>> problem go away.
>>>
>>> ...
>>>
>>> I have applied this to linux-fslc tree and applied this to master and
>>> fido branches. It should work out of box now.
>>
>>
>> Mainline code worked out of the box in the first place. I'm now
>> wondering what's the best way to go forward, as we did a lot of work
>> just to return to the starting point.
>
> This was a regression when enabling support for BT/WIFI reset handling
> which Fabio did to support WaRP. The beauty here we support in a
> single kernel a huge set of boards and already using the mainline mode
> for them.

I just feel uncomfortable that we loaded Fabio with additional work,
because the boards share a common tree and I didn't have any choice to
switch the kernel recipe to a working commit, that's all.

Regards,
Nikolay

Re: [meta-fsl-arm-extra][PATCH 1/2] linux-riotboard: Add separate riotboard kernel recipe

[Otavio Salvador]

On Tue, Apr 28, 2015 at 2:24 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
> On 04/28/2015 08:12 PM, Otavio Salvador wrote:
>> On Tue, Apr 28, 2015 at 2:10 PM, Nikolay Dimitrov <picmaster@mail.bg>
>> wrote:
>>>
>>> On 04/28/2015 07:42 PM, Otavio Salvador wrote:
>>>>
>>>>
>>>> On Tue, Apr 28, 2015 at 12:39 PM, Fabio Estevam <festevam@gmail.com>
>>>> wrote:
>>>> ...
>>>>>
>>>>>
>>>>> Applying it on top of 4.0 linux-fslc makes the SD card detection
>>>>> problem go away.
>>>>
>>>>
>>>> ...
>>>>
>>>> I have applied this to linux-fslc tree and applied this to master and
>>>> fido branches. It should work out of box now.
>>>
>>>
>>>
>>> Mainline code worked out of the box in the first place. I'm now
>>> wondering what's the best way to go forward, as we did a lot of work
>>> just to return to the starting point.
>>
>>
>> This was a regression when enabling support for BT/WIFI reset handling
>> which Fabio did to support WaRP. The beauty here we support in a
>> single kernel a huge set of boards and already using the mainline mode
>> for them.
>
>
> I just feel uncomfortable that we loaded Fabio with additional work,
> because the boards share a common tree and I didn't have any choice to
> switch the kernel recipe to a working commit, that's all.

In fact Fabio and I checke

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [meta-fsl-arm-extra][PATCH 1/2] linux-riotboard: Add separate riotboard kernel recipe

[Otavio Salvador]

On Tue, Apr 28, 2015 at 2:38 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Tue, Apr 28, 2015 at 2:24 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
>> On 04/28/2015 08:12 PM, Otavio Salvador wrote:
>>> On Tue, Apr 28, 2015 at 2:10 PM, Nikolay Dimitrov <picmaster@mail.bg>
>>> wrote:
>>>>
>>>> On 04/28/2015 07:42 PM, Otavio Salvador wrote:
>>>>>
>>>>>
>>>>> On Tue, Apr 28, 2015 at 12:39 PM, Fabio Estevam <festevam@gmail.com>
>>>>> wrote:
>>>>> ...
>>>>>>
>>>>>>
>>>>>> Applying it on top of 4.0 linux-fslc makes the SD card detection
>>>>>> problem go away.
>>>>>
>>>>>
>>>>> ...
>>>>>
>>>>> I have applied this to linux-fslc tree and applied this to master and
>>>>> fido branches. It should work out of box now.
>>>>
>>>>
>>>>
>>>> Mainline code worked out of the box in the first place. I'm now
>>>> wondering what's the best way to go forward, as we did a lot of work
>>>> just to return to the starting point.
>>>
>>>
>>> This was a regression when enabling support for BT/WIFI reset handling
>>> which Fabio did to support WaRP. The beauty here we support in a
>>> single kernel a huge set of boards and already using the mainline mode
>>> for them.
>>
>>
>> I just feel uncomfortable that we loaded Fabio with additional work,
>> because the boards share a common tree and I didn't have any choice to
>> switch the kernel recipe to a working commit, that's all.
>
> In fact Fabio and I checke

(pressed too fast)

In fact Fabio and I checked what could eventually fix the root cause
and this seems to be a better long term commitment.

I understand your view and while it seems to be very appealing to have
"full control" it also ends with a lot of work duplication.  The
sharing of a single mainline Linux kernel and U-Boot repositories is
the best way to:

 - avoid work duplication
 - reduce maintenance burden and work in mid term
 - easy custom board development
 - maximize BSP robustness

Of course, the price for this is when a regression is found it affects
different boards but a fix also fixes the issue in several boards. It
seems to be the best long-term compromise.


-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [meta-fsl-arm-extra][PATCH 1/2] linux-riotboard: Add separate riotboard kernel recipe

[Nikolay Dimitrov]

Hi Otavio,

On 04/27/2015 07:26 PM, Otavio Salvador wrote:
>>> I want to check with you if you really want to have a dedicated
>>> recipe. For bugfixes (as now) you can use a bbappend as a temporary
>>> solution and, at end of the day, easy to remove once this is fixed in
>>> the kernel.
>>>
>>> Please let me know your thoughts...
>>
>>
>> Do you mean something like this (bbappend in meta-fsl-arm-extra)?
>>
>> diff --git a/recipes-kernel/linux/linux-fslc_4.0.bbappend
>> b/recipes-kernel/linux/linux-fslc_4.0.bbappend
>> new file mode 100644
>> index 0000000..d7a4e72
>> --- /dev/null
>> +++ b/recipes-kernel/linux/linux-fslc_4.0.bbappend
>> @@ -0,0 +1,3 @@
>> +FILESEXTRAPATHS_append := ":${THISDIR}/${PN}"
>> +
>> +SRC_URI_imx6dl-riotboard = "file://riotboard-specific.patch"
>
> Yes.

Just wanted to follow-up this technical topic. Even if considering that
it's not of an urgent topic anymore, it would be good to have working
path forward.

The bbappend proposal above doesn't work. Here's my bbappend code
(layer meta-fsl-arm-extra):


diff --git a/recipes-kernel/linux/linux-fslc_4.0.bbappend 
b/recipes-kernel/linux/linux-fslc_4.0.bbappend
new file mode 100644
index 0000000..4bf2349
--- /dev/null
+++ b/recipes-kernel/linux/linux-fslc_4.0.bbappend
@@ -0,0 +1,4 @@
+FILESEXTRAPATHS_append := ":${THISDIR}/${PN}-4.0"
+
+# Riotboard specific patch
+SRC_URI_imx6dl-riotboard += 
"file://0001-Revert-mmc-sdhci-esdhc-imx-Call-mmc_of_parse.patch"


This doesn't work out for reasons beyond my expertise:


$ bitbake linux-fslc
Loading cache: 100% |###########################################| ETA: 
00:00:00
Loaded 2093 entries from dependency cache.
NOTE: Error during finalise of 
/home/picmaster/work/yocto-master-riotboard/sources/meta-fsl-arm/recipes-kernel/linux/linux-fslc_4.0.bb
ERROR: ExpansionError during parsing 
/home/picmaster/work/yocto-master-riotboard/sources/meta-fsl-arm/recipes-kernel/linux/linux-fslc_4.0.bb: 
Failure expanding variable S: ExpansionError: Failure expanding variable 
SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered 
exception FetchError: Fetcher failure: SRCREV was used yet no valid SCM 
was found in SRC_URI

Summary: There was 1 ERROR message shown, returning a non-zero exit code.


If I remove the board-specific suffix to SRC_URI, it doesn't generate
the error message and works, but obviously doesn't achieve what I need.

Any insight on this issue will be appreciated.

Regards,
Nikolay

Re: [meta-fsl-arm-extra][PATCH 1/2] linux-riotboard: Add separate riotboard kernel recipe

[Otavio Salvador]

On Tue, Apr 28, 2015 at 3:19 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
> Hi Otavio,
>
> On 04/27/2015 07:26 PM, Otavio Salvador wrote:
>>>>
>>>> I want to check with you if you really want to have a dedicated
>>>> recipe. For bugfixes (as now) you can use a bbappend as a temporary
>>>> solution and, at end of the day, easy to remove once this is fixed in
>>>> the kernel.
>>>>
>>>> Please let me know your thoughts...
>>>
>>>
>>>
>>> Do you mean something like this (bbappend in meta-fsl-arm-extra)?
>>>
>>> diff --git a/recipes-kernel/linux/linux-fslc_4.0.bbappend
>>> b/recipes-kernel/linux/linux-fslc_4.0.bbappend
>>> new file mode 100644
>>> index 0000000..d7a4e72
>>> --- /dev/null
>>> +++ b/recipes-kernel/linux/linux-fslc_4.0.bbappend
>>> @@ -0,0 +1,3 @@
>>> +FILESEXTRAPATHS_append := ":${THISDIR}/${PN}"
>>> +
>>> +SRC_URI_imx6dl-riotboard = "file://riotboard-specific.patch"
>>
>>
>> Yes.
>
>
> Just wanted to follow-up this technical topic. Even if considering that
> it's not of an urgent topic anymore, it would be good to have working
> path forward.
>
> The bbappend proposal above doesn't work. Here's my bbappend code
> (layer meta-fsl-arm-extra):
>
>
> diff --git a/recipes-kernel/linux/linux-fslc_4.0.bbappend
> b/recipes-kernel/linux/linux-fslc_4.0.bbappend
> new file mode 100644
> index 0000000..4bf2349
> --- /dev/null
> +++ b/recipes-kernel/linux/linux-fslc_4.0.bbappend
> @@ -0,0 +1,4 @@
> +FILESEXTRAPATHS_append := ":${THISDIR}/${PN}-4.0"
> +
> +# Riotboard specific patch
> +SRC_URI_imx6dl-riotboard +=
> "file://0001-Revert-mmc-sdhci-esdhc-imx-Call-mmc_of_parse.patch"
>
>
> This doesn't work out for reasons beyond my expertise:

SRC_URI_append_imx6dl-riotboard = " file://riotboard-specific.patch"

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [meta-fsl-arm-extra][PATCH 1/2] linux-riotboard: Add separate riotboard kernel recipe

[Nikolay Dimitrov]

Hi Otavio,

On 04/28/2015 09:33 PM, Otavio Salvador wrote:
> On Tue, Apr 28, 2015 at 3:19 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
>> Hi Otavio,
>>
>> On 04/27/2015 07:26 PM, Otavio Salvador wrote:
>>>>>
>>>>> I want to check with you if you really want to have a dedicated
>>>>> recipe. For bugfixes (as now) you can use a bbappend as a temporary
>>>>> solution and, at end of the day, easy to remove once this is fixed in
>>>>> the kernel.
>>>>>
>>>>> Please let me know your thoughts...
>>>>
>>>>
>>>>
>>>> Do you mean something like this (bbappend in meta-fsl-arm-extra)?
>>>>
>>>> diff --git a/recipes-kernel/linux/linux-fslc_4.0.bbappend
>>>> b/recipes-kernel/linux/linux-fslc_4.0.bbappend
>>>> new file mode 100644
>>>> index 0000000..d7a4e72
>>>> --- /dev/null
>>>> +++ b/recipes-kernel/linux/linux-fslc_4.0.bbappend
>>>> @@ -0,0 +1,3 @@
>>>> +FILESEXTRAPATHS_append := ":${THISDIR}/${PN}"
>>>> +
>>>> +SRC_URI_imx6dl-riotboard = "file://riotboard-specific.patch"
>>>
>>>
>>> Yes.
>>
>>
>> Just wanted to follow-up this technical topic. Even if considering that
>> it's not of an urgent topic anymore, it would be good to have working
>> path forward.
>>
>> The bbappend proposal above doesn't work. Here's my bbappend code
>> (layer meta-fsl-arm-extra):
>>
>>
>> diff --git a/recipes-kernel/linux/linux-fslc_4.0.bbappend
>> b/recipes-kernel/linux/linux-fslc_4.0.bbappend
>> new file mode 100644
>> index 0000000..4bf2349
>> --- /dev/null
>> +++ b/recipes-kernel/linux/linux-fslc_4.0.bbappend
>> @@ -0,0 +1,4 @@
>> +FILESEXTRAPATHS_append := ":${THISDIR}/${PN}-4.0"
>> +
>> +# Riotboard specific patch
>> +SRC_URI_imx6dl-riotboard +=
>> "file://0001-Revert-mmc-sdhci-esdhc-imx-Call-mmc_of_parse.patch"
>>
>>
>> This doesn't work out for reasons beyond my expertise:
>
> SRC_URI_append_imx6dl-riotboard = " file://riotboard-specific.patch"

That works, thanks a lot!

Regards,
Nikolay

PS: Sometimes I feel that Bitbake is Turing-complete, intelligent and
even can vote... :D

Re: [meta-fsl-arm-extra][PATCH 1/2] linux-riotboard: Add separate riotboard kernel recipe

[Nikolay Dimitrov]

Hi guys,

On 04/28/2015 06:39 PM, Fabio Estevam wrote:
> Hi Gary and Nikolay,
>
> On Tue, Apr 28, 2015 at 11:01 AM, Fabio Estevam <festevam@gmail.com> wrote:
>> On Tue, Apr 28, 2015 at 10:57 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>
>>> How is this going to be handled?  Will you apply your patch
>>> upstream and update the meta-fsl-arm recipe, or just add the
>>> patch there?
>>
>> I still need to test it on warpboard. Will do it later later today as
>> I don't have access to it here at the moment. After I confirm it also
>> works there, then we can ask Otavio to apply it in linux-fslc.
>
> Please discard my previous workaround patch.
>
> Otavio found a commit from 4.1-rc1 that makes this problem go away:
>
> commit 04e079cf6b24c794bbc52b04b370f84cb728540e
> Author: Scott Branden <sbranden@broadcom.com>
> Date:   Tue Mar 10 11:35:10 2015 -0700
>
>      mmc: sdhci: fix card presence logic in sdhci_request function
>
>      The sdhci_request function should consider a non-removable device
>      always present.
>      Call the correct logic already available in sdhci_do_get_cd function.
>
>      This fixes some logic paths where MMC requests are being made to
>      non-removable devices that do not have the card detect pin connected
>      on the hardware as it is non-removable.
>
>      Signed-off-by: Scott Branden <sbranden@broadcom.com>
>      Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>
> Will also ask in the linux-mmc if this should be applied to stable.
>
> Applying it on top of 4.0 linux-fslc makes the SD card detection
> problem go away.
>
> Thanks Otavio!
>
> Regards,
>
> Fabio Estevam

Sorry for the delay, it looks I somehow got several of Fabio's mails
with delay.

The patch works OK, tested on riotboard, on both USDHC2 & USDHC3
interfaces. Thanks a lot for your help, and also thanks to Gary for
reporting the issue.

Have a nice day,
Nikolay