* Re: What is the strategy to update eglibc?
From: Saul Wold @ 2011-10-31 16:43 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Kang Kai
In-Reply-To: <4EAE04FF.1070207@windriver.com>
On 10/30/2011 07:16 PM, Kang Kai wrote:
> On 2011年10月31日 10:12, Kang Kai wrote:
>> Hi Saul,
>>
>> I just want to update eglibc but eglibc is using its 2.14 branch and
>> use svn commit revision "15225" as current version. Of course it is
>> behind the latest svn revision, but I don't quit sure about which is
>> the right revision to update eglibc.
> Hi Saul,
>
> And right now is 2 commits behind the latest revision, do it worth to
> update right now?
Kai,
I know that Khem recently added the eglibc 2.14 recipe, but I think that
we are still actually using the 2.13 recipe as defined by EGLIBCVERSION.
At this point, it might be good to know what's changed by those 2
commits and maybe do a full build and system test with EGLIBCVERSION set
to 2.14 to find out if the problems are resolved. You might look back
in the email list to mid-June to see what the original set of issues was.
Sau!
> Thanks!
>
>>
>> Could you give me some guide? Thank you!
>>
>> Regards,
>> Kai
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply
* [U-Boot] [PATCH v7 1/4] tegra2: Move MMC clock initialization into MMC driver
From: Stephen Warren @ 2011-10-31 16:51 UTC (permalink / raw)
To: u-boot
This centralizes knowledge of MMC clocking into the MMC driver. This also
removes clock setup from the board files, which will simplify later changes
that modify the Harmony board to support the correct set of MMC controllers.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Cc: Andy Fleming <afleming@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
---
board/nvidia/common/board.c | 13 +------------
drivers/mmc/tegra2_mmc.c | 12 +++++++++---
2 files changed, 10 insertions(+), 15 deletions(-)
diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c
index d13537d..370a259 100644
--- a/board/nvidia/common/board.c
+++ b/board/nvidia/common/board.c
@@ -102,16 +102,6 @@ static void pin_mux_uart(void)
#ifdef CONFIG_TEGRA2_MMC
/*
- * Routine: clock_init_mmc
- * Description: init the PLL and clocks for the SDMMC controllers
- */
-static void clock_init_mmc(void)
-{
- clock_start_periph_pll(PERIPH_ID_SDMMC4, CLOCK_ID_PERIPH, 20000000);
- clock_start_periph_pll(PERIPH_ID_SDMMC3, CLOCK_ID_PERIPH, 20000000);
-}
-
-/*
* Routine: pin_mux_mmc
* Description: setup the pin muxes/tristate values for the SDMMC(s)
*/
@@ -157,8 +147,7 @@ int board_init(void)
int board_mmc_init(bd_t *bd)
{
debug("board_mmc_init called\n");
- /* Enable clocks, muxes, etc. for SDMMC controllers */
- clock_init_mmc();
+ /* Enable muxes, etc. for SDMMC controllers */
pin_mux_mmc();
gpio_config_mmc();
diff --git a/drivers/mmc/tegra2_mmc.c b/drivers/mmc/tegra2_mmc.c
index 9e741f2..78b1190 100644
--- a/drivers/mmc/tegra2_mmc.c
+++ b/drivers/mmc/tegra2_mmc.c
@@ -435,14 +435,22 @@ static int mmc_core_init(struct mmc *mmc)
static int tegra2_mmc_initialize(int dev_index, int bus_width)
{
+ struct mmc_host *host;
struct mmc *mmc;
debug(" mmc_initialize called\n");
+ host = &mmc_host[dev_index];
+
+ host->clock = 0;
+ tegra2_get_setup(host, dev_index);
+
+ clock_start_periph_pll(host->mmc_id, CLOCK_ID_PERIPH, 20000000);
+
mmc = &mmc_dev[dev_index];
sprintf(mmc->name, "Tegra2 SD/MMC");
- mmc->priv = &mmc_host[dev_index];
+ mmc->priv = host;
mmc->send_cmd = mmc_send_cmd;
mmc->set_ios = mmc_set_ios;
mmc->init = mmc_core_init;
@@ -465,8 +473,6 @@ static int tegra2_mmc_initialize(int dev_index, int bus_width)
mmc->f_min = 375000;
mmc->f_max = 48000000;
- mmc_host[dev_index].clock = 0;
- tegra2_get_setup(&mmc_host[dev_index], dev_index);
mmc_register(mmc);
return 0;
--
1.7.0.4
^ permalink raw reply related
* [U-Boot] [PATCH v7 2/4] tegra2: Move board_mmc_init into board files
From: Stephen Warren @ 2011-10-31 16:51 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320079897-29473-1-git-send-email-swarren@nvidia.com>
For Seaboard, this is mostly a cut/paste of board_mmc_init() and
pin_mux_mmc() into seaboard.c; pin_mux_mmc() was modified to add some
missing pinmux_tristate_disable calls for the GPIOs.
For Harmony, those functions were modified to configure SDMMC2 (index 2)
instead of SDMMC3 (index 1), since that's what is present on the board.
However, harmony.c is still missing the required GPIO setup, so neither
port is likely to function correctly yet. This will be fixed in the next
change.
v4: Include board.h to prototype tegra2_mmc_init().
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
---
board/nvidia/common/board.c | 52 -----------------------------------
board/nvidia/harmony/harmony.c | 56 ++++++++++++++++++++++++++++++++++++++
board/nvidia/seaboard/seaboard.c | 53 +++++++++++++++++++++++++++++++++++
3 files changed, 109 insertions(+), 52 deletions(-)
diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c
index 370a259..0f12de2 100644
--- a/board/nvidia/common/board.c
+++ b/board/nvidia/common/board.c
@@ -33,10 +33,6 @@
#include <asm/arch/uart.h>
#include "board.h"
-#ifdef CONFIG_TEGRA2_MMC
-#include <mmc.h>
-#endif
-
DECLARE_GLOBAL_DATA_PTR;
const struct tegra2_sysinfo sysinfo = {
@@ -100,33 +96,6 @@ static void pin_mux_uart(void)
#endif /* CONFIG_TEGRA2_ENABLE_UARTD */
}
-#ifdef CONFIG_TEGRA2_MMC
-/*
- * Routine: pin_mux_mmc
- * Description: setup the pin muxes/tristate values for the SDMMC(s)
- */
-static void pin_mux_mmc(void)
-{
- /* SDMMC4: config 3, x8 on 2nd set of pins */
- pinmux_set_func(PINGRP_ATB, PMUX_FUNC_SDIO4);
- pinmux_set_func(PINGRP_GMA, PMUX_FUNC_SDIO4);
- pinmux_set_func(PINGRP_GME, PMUX_FUNC_SDIO4);
-
- pinmux_tristate_disable(PINGRP_ATB);
- pinmux_tristate_disable(PINGRP_GMA);
- pinmux_tristate_disable(PINGRP_GME);
-
- /* SDMMC3: SDIO3_CLK, SDIO3_CMD, SDIO3_DAT[3:0] */
- pinmux_set_func(PINGRP_SDB, PMUX_FUNC_SDIO3);
- pinmux_set_func(PINGRP_SDC, PMUX_FUNC_SDIO3);
- pinmux_set_func(PINGRP_SDD, PMUX_FUNC_SDIO3);
-
- pinmux_tristate_disable(PINGRP_SDC);
- pinmux_tristate_disable(PINGRP_SDD);
- pinmux_tristate_disable(PINGRP_SDB);
-}
-#endif
-
/*
* Routine: board_init
* Description: Early hardware init.
@@ -142,27 +111,6 @@ int board_init(void)
return 0;
}
-#ifdef CONFIG_TEGRA2_MMC
-/* this is a weak define that we are overriding */
-int board_mmc_init(bd_t *bd)
-{
- debug("board_mmc_init called\n");
- /* Enable muxes, etc. for SDMMC controllers */
- pin_mux_mmc();
- gpio_config_mmc();
-
- debug("board_mmc_init: init eMMC\n");
- /* init dev 0, eMMC chip, with 4-bit bus */
- tegra2_mmc_init(0, 4);
-
- debug("board_mmc_init: init SD slot\n");
- /* init dev 1, SD slot, with 4-bit bus */
- tegra2_mmc_init(1, 4);
-
- return 0;
-}
-#endif
-
#ifdef CONFIG_BOARD_EARLY_INIT_F
int board_early_init_f(void)
{
diff --git a/board/nvidia/harmony/harmony.c b/board/nvidia/harmony/harmony.c
index cbb30d6..f2c3867 100644
--- a/board/nvidia/harmony/harmony.c
+++ b/board/nvidia/harmony/harmony.c
@@ -24,9 +24,11 @@
#include <common.h>
#include <asm/io.h>
#include <asm/arch/tegra2.h>
+#include <asm/arch/pinmux.h>
#ifdef CONFIG_TEGRA2_MMC
#include <mmc.h>
#endif
+#include "../common/board.h"
/*
* Routine: gpio_config_uart
@@ -38,6 +40,39 @@ void gpio_config_uart(void)
#ifdef CONFIG_TEGRA2_MMC
/*
+ * Routine: pin_mux_mmc
+ * Description: setup the pin muxes/tristate values for the SDMMC(s)
+ */
+static void pin_mux_mmc(void)
+{
+ /* SDMMC4: config 3, x8 on 2nd set of pins */
+ pinmux_set_func(PINGRP_ATB, PMUX_FUNC_SDIO4);
+ pinmux_set_func(PINGRP_GMA, PMUX_FUNC_SDIO4);
+ pinmux_set_func(PINGRP_GME, PMUX_FUNC_SDIO4);
+
+ pinmux_tristate_disable(PINGRP_ATB);
+ pinmux_tristate_disable(PINGRP_GMA);
+ pinmux_tristate_disable(PINGRP_GME);
+
+ /* For power GPIO PI6 */
+ pinmux_tristate_disable(PINGRP_ATA);
+ /* For CD GPIO PH2 */
+ pinmux_tristate_disable(PINGRP_ATD);
+
+ /* SDMMC2: SDIO2_CLK, SDIO2_CMD, SDIO2_DAT[7:0] */
+ pinmux_set_func(PINGRP_DTA, PMUX_FUNC_SDIO2);
+ pinmux_set_func(PINGRP_DTD, PMUX_FUNC_SDIO2);
+
+ pinmux_tristate_disable(PINGRP_DTA);
+ pinmux_tristate_disable(PINGRP_DTD);
+
+ /* For power GPIO PT3 */
+ pinmux_tristate_disable(PINGRP_DTB);
+ /* For CD GPIO PI5 */
+ pinmux_tristate_disable(PINGRP_ATC);
+}
+
+/*
* Routine: gpio_config_mmc
* Description: Set GPIOs for SD card
*/
@@ -47,6 +82,27 @@ void gpio_config_mmc(void)
}
/* this is a weak define that we are overriding */
+int board_mmc_init(bd_t *bd)
+{
+ debug("board_mmc_init called\n");
+
+ /* Enable muxes, etc. for SDMMC controllers */
+ pin_mux_mmc();
+ gpio_config_mmc();
+
+ debug("board_mmc_init: init SD slot J26\n");
+ /* init dev 0, SD slot J26, with 4-bit bus */
+ /* The board has an 8-bit bus, but 8-bit doesn't work yet */
+ tegra2_mmc_init(0, 4);
+
+ debug("board_mmc_init: init SD slot J5\n");
+ /* init dev 2, SD slot J5, with 4-bit bus */
+ tegra2_mmc_init(2, 4);
+
+ return 0;
+}
+
+/* this is a weak define that we are overriding */
int board_mmc_getcd(u8 *cd, struct mmc *mmc)
{
debug("board_mmc_getcd called\n");
diff --git a/board/nvidia/seaboard/seaboard.c b/board/nvidia/seaboard/seaboard.c
index bc67d0f..22a0e69 100644
--- a/board/nvidia/seaboard/seaboard.c
+++ b/board/nvidia/seaboard/seaboard.c
@@ -24,10 +24,12 @@
#include <common.h>
#include <asm/io.h>
#include <asm/arch/tegra2.h>
+#include <asm/arch/pinmux.h>
#include <asm/gpio.h>
#ifdef CONFIG_TEGRA2_MMC
#include <mmc.h>
#endif
+#include "../common/board.h"
/*
* Routine: gpio_config_uart
@@ -56,6 +58,36 @@ void gpio_config_uart(void)
#ifdef CONFIG_TEGRA2_MMC
/*
+ * Routine: pin_mux_mmc
+ * Description: setup the pin muxes/tristate values for the SDMMC(s)
+ */
+static void pin_mux_mmc(void)
+{
+ /* SDMMC4: config 3, x8 on 2nd set of pins */
+ pinmux_set_func(PINGRP_ATB, PMUX_FUNC_SDIO4);
+ pinmux_set_func(PINGRP_GMA, PMUX_FUNC_SDIO4);
+ pinmux_set_func(PINGRP_GME, PMUX_FUNC_SDIO4);
+
+ pinmux_tristate_disable(PINGRP_ATB);
+ pinmux_tristate_disable(PINGRP_GMA);
+ pinmux_tristate_disable(PINGRP_GME);
+
+ /* SDMMC3: SDIO3_CLK, SDIO3_CMD, SDIO3_DAT[3:0] */
+ pinmux_set_func(PINGRP_SDB, PMUX_FUNC_SDIO3);
+ pinmux_set_func(PINGRP_SDC, PMUX_FUNC_SDIO3);
+ pinmux_set_func(PINGRP_SDD, PMUX_FUNC_SDIO3);
+
+ pinmux_tristate_disable(PINGRP_SDC);
+ pinmux_tristate_disable(PINGRP_SDD);
+ pinmux_tristate_disable(PINGRP_SDB);
+
+ /* For power GPIO PI6 */
+ pinmux_tristate_disable(PINGRP_ATA);
+ /* For CD GPIO PI5 */
+ pinmux_tristate_disable(PINGRP_ATC);
+}
+
+/*
* Routine: gpio_config_mmc
* Description: Set GPIOs for SDMMC3 SDIO slot.
*/
@@ -69,6 +101,27 @@ void gpio_config_mmc(void)
}
/* this is a weak define that we are overriding */
+int board_mmc_init(bd_t *bd)
+{
+ debug("board_mmc_init called\n");
+
+ /* Enable muxes, etc. for SDMMC controllers */
+ pin_mux_mmc();
+ gpio_config_mmc();
+
+ debug("board_mmc_init: init eMMC\n");
+ /* init dev 0, eMMC chip, with 4-bit bus */
+ /* The board has an 8-bit bus, but 8-bit doesn't work yet */
+ tegra2_mmc_init(0, 4);
+
+ debug("board_mmc_init: init SD slot\n");
+ /* init dev 1, SD slot, with 4-bit bus */
+ tegra2_mmc_init(1, 4);
+
+ return 0;
+}
+
+/* this is a weak define that we are overriding */
int board_mmc_getcd(u8 *cd, struct mmc *mmc)
{
debug("board_mmc_getcd called\n");
--
1.7.0.4
^ permalink raw reply related
* [U-Boot] [PATCH v7 3/4] tegra2: Modify MMC driver to handle power and cd GPIOs
From: Stephen Warren @ 2011-10-31 16:51 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320079897-29473-1-git-send-email-swarren@nvidia.com>
Pass the GPIO numbers for power and card detect to tegra2_mmc_init(), and
modify that function to perform all required GPIO initialization. This
removes the need for board files to perform these operations.
Move board_mmc_getcd() into tegra2_mmc.c now that the driver knows which
GPIOs to use.
Update affected call-sites in seaboard.c and harmony.c. Note that this
change should make all SD ports work on Harmony, since the required GPIO
setup is now being performed.
v4: Fix prototype of tegra2_mmc_init() in board.h to match driver change.
Remove prototype of gpio_config_mmc() from board.h
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Cc: Andy Fleming <afleming@gmail.com>
Tested-by: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
---
board/nvidia/common/board.h | 3 +-
board/nvidia/harmony/harmony.c | 27 ++---------------------
board/nvidia/seaboard/seaboard.c | 33 +----------------------------
drivers/mmc/tegra2_mmc.c | 42 ++++++++++++++++++++++++++++++++-----
drivers/mmc/tegra2_mmc.h | 4 ++-
5 files changed, 45 insertions(+), 64 deletions(-)
diff --git a/board/nvidia/common/board.h b/board/nvidia/common/board.h
index 344e702..35acbca 100644
--- a/board/nvidia/common/board.h
+++ b/board/nvidia/common/board.h
@@ -26,7 +26,6 @@
void tegra2_start(void);
void gpio_config_uart(void);
-void gpio_config_mmc(void);
-int tegra2_mmc_init(int dev_index, int bus_width);
+int tegra2_mmc_init(int dev_index, int bus_width, int pwr_gpio, int cd_gpio);
#endif /* BOARD_H */
diff --git a/board/nvidia/harmony/harmony.c b/board/nvidia/harmony/harmony.c
index f2c3867..3cbe820 100644
--- a/board/nvidia/harmony/harmony.c
+++ b/board/nvidia/harmony/harmony.c
@@ -25,6 +25,7 @@
#include <asm/io.h>
#include <asm/arch/tegra2.h>
#include <asm/arch/pinmux.h>
+#include <asm/gpio.h>
#ifdef CONFIG_TEGRA2_MMC
#include <mmc.h>
#endif
@@ -72,15 +73,6 @@ static void pin_mux_mmc(void)
pinmux_tristate_disable(PINGRP_ATC);
}
-/*
- * Routine: gpio_config_mmc
- * Description: Set GPIOs for SD card
- */
-void gpio_config_mmc(void)
-{
- /* Not implemented for now */
-}
-
/* this is a weak define that we are overriding */
int board_mmc_init(bd_t *bd)
{
@@ -88,29 +80,16 @@ int board_mmc_init(bd_t *bd)
/* Enable muxes, etc. for SDMMC controllers */
pin_mux_mmc();
- gpio_config_mmc();
debug("board_mmc_init: init SD slot J26\n");
/* init dev 0, SD slot J26, with 4-bit bus */
/* The board has an 8-bit bus, but 8-bit doesn't work yet */
- tegra2_mmc_init(0, 4);
+ tegra2_mmc_init(0, 4, GPIO_PI6, GPIO_PH2);
debug("board_mmc_init: init SD slot J5\n");
/* init dev 2, SD slot J5, with 4-bit bus */
- tegra2_mmc_init(2, 4);
+ tegra2_mmc_init(2, 4, GPIO_PT3, GPIO_PI5);
return 0;
}
-
-/* this is a weak define that we are overriding */
-int board_mmc_getcd(u8 *cd, struct mmc *mmc)
-{
- debug("board_mmc_getcd called\n");
- /*
- * Hard-code CD presence for now. Need to add GPIO inputs
- * for Harmony
- */
- *cd = 1;
- return 0;
-}
#endif
diff --git a/board/nvidia/seaboard/seaboard.c b/board/nvidia/seaboard/seaboard.c
index 22a0e69..356d616 100644
--- a/board/nvidia/seaboard/seaboard.c
+++ b/board/nvidia/seaboard/seaboard.c
@@ -87,19 +87,6 @@ static void pin_mux_mmc(void)
pinmux_tristate_disable(PINGRP_ATC);
}
-/*
- * Routine: gpio_config_mmc
- * Description: Set GPIOs for SDMMC3 SDIO slot.
- */
-void gpio_config_mmc(void)
-{
- /* Set EN_VDDIO_SD (GPIO I6) */
- gpio_direction_output(GPIO_PI6, 1);
-
- /* Config pin as GPI for Card Detect (GPIO I5) */
- gpio_direction_input(GPIO_PI5);
-}
-
/* this is a weak define that we are overriding */
int board_mmc_init(bd_t *bd)
{
@@ -107,31 +94,15 @@ int board_mmc_init(bd_t *bd)
/* Enable muxes, etc. for SDMMC controllers */
pin_mux_mmc();
- gpio_config_mmc();
debug("board_mmc_init: init eMMC\n");
/* init dev 0, eMMC chip, with 4-bit bus */
/* The board has an 8-bit bus, but 8-bit doesn't work yet */
- tegra2_mmc_init(0, 4);
+ tegra2_mmc_init(0, 4, -1, -1);
debug("board_mmc_init: init SD slot\n");
/* init dev 1, SD slot, with 4-bit bus */
- tegra2_mmc_init(1, 4);
-
- return 0;
-}
-
-/* this is a weak define that we are overriding */
-int board_mmc_getcd(u8 *cd, struct mmc *mmc)
-{
- debug("board_mmc_getcd called\n");
- *cd = 1; /* Assume card is inserted, or eMMC */
-
- if (IS_SD(mmc)) {
- /* Seaboard SDMMC3 = SDIO3_CD = GPIO_PI5 */
- if (gpio_get_value(GPIO_PI5))
- *cd = 0;
- }
+ tegra2_mmc_init(1, 4, GPIO_PI6, GPIO_PI5);
return 0;
}
diff --git a/drivers/mmc/tegra2_mmc.c b/drivers/mmc/tegra2_mmc.c
index 78b1190..3de9c5d 100644
--- a/drivers/mmc/tegra2_mmc.c
+++ b/drivers/mmc/tegra2_mmc.c
@@ -21,6 +21,7 @@
#include <common.h>
#include <mmc.h>
+#include <asm/gpio.h>
#include <asm/io.h>
#include <asm/arch/clk_rst.h>
#include <asm/arch/clock.h>
@@ -433,20 +434,37 @@ static int mmc_core_init(struct mmc *mmc)
return 0;
}
-static int tegra2_mmc_initialize(int dev_index, int bus_width)
+int tegra2_mmc_init(int dev_index, int bus_width, int pwr_gpio, int cd_gpio)
{
struct mmc_host *host;
+ char gpusage[12]; /* "SD/MMCn PWR" or "SD/MMCn CD" */
struct mmc *mmc;
- debug(" mmc_initialize called\n");
+ debug(" tegra2_mmc_init: index %d, bus width %d "
+ "pwr_gpio %d cd_gpio %d\n",
+ dev_index, bus_width, pwr_gpio, cd_gpio);
host = &mmc_host[dev_index];
host->clock = 0;
+ host->pwr_gpio = pwr_gpio;
+ host->cd_gpio = cd_gpio;
tegra2_get_setup(host, dev_index);
clock_start_periph_pll(host->mmc_id, CLOCK_ID_PERIPH, 20000000);
+ if (host->pwr_gpio >= 0) {
+ sprintf(gpusage, "SD/MMC%d PWR", dev_index);
+ gpio_request(host->pwr_gpio, gpusage);
+ gpio_direction_output(host->pwr_gpio, 1);
+ }
+
+ if (host->cd_gpio >= 0) {
+ sprintf(gpusage, "SD/MMC%d CD", dev_index);
+ gpio_request(host->cd_gpio, gpusage);
+ gpio_direction_input(host->cd_gpio);
+ }
+
mmc = &mmc_dev[dev_index];
sprintf(mmc->name, "Tegra2 SD/MMC");
@@ -478,9 +496,21 @@ static int tegra2_mmc_initialize(int dev_index, int bus_width)
return 0;
}
-int tegra2_mmc_init(int dev_index, int bus_width)
+/* this is a weak define that we are overriding */
+int board_mmc_getcd(u8 *cd, struct mmc *mmc)
{
- debug(" tegra2_mmc_init: index %d, bus width %d\n",
- dev_index, bus_width);
- return tegra2_mmc_initialize(dev_index, bus_width);
+ struct mmc_host *host = (struct mmc_host *)mmc->priv;
+
+ debug("board_mmc_getcd called\n");
+
+ *cd = 1; /* Assume card is inserted, or eMMC */
+
+ if (IS_SD(mmc)) {
+ if (host->cd_gpio >= 0) {
+ if (gpio_get_value(host->cd_gpio))
+ *cd = 0;
+ }
+ }
+
+ return 0;
}
diff --git a/drivers/mmc/tegra2_mmc.h b/drivers/mmc/tegra2_mmc.h
index 28698e0..72f587b 100644
--- a/drivers/mmc/tegra2_mmc.h
+++ b/drivers/mmc/tegra2_mmc.h
@@ -74,9 +74,11 @@ struct mmc_host {
unsigned int clock; /* Current clock (MHz) */
unsigned int base; /* Base address, SDMMC1/2/3/4 */
enum periph_id mmc_id; /* Peripheral ID: PERIPH_ID_... */
+ int pwr_gpio; /* Power GPIO */
+ int cd_gpio; /* Change Detect GPIO */
};
-int tegra2_mmc_init(int dev_index, int bus_width);
+int tegra2_mmc_init(int dev_index, int bus_width, int pwr_gpio, int cd_gpio);
#endif /* __ASSEMBLY__ */
#endif /* __TEGRA2_MMC_H_ */
--
1.7.0.4
^ permalink raw reply related
* [U-Boot] [PATCH v7 4/4] tegra2: Add support for Ventana
From: Stephen Warren @ 2011-10-31 16:51 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320079897-29473-1-git-send-email-swarren@nvidia.com>
Ventana is a board which is very similar to Seaboard. Support it by
re-using board/nvidia/seaboard/seaboard.c with minor run-time conditionals.
v5: Makefile: Use cmd_link_o_target, remove unused clean/distclean targets.
v6: Make gpio_config_uart_seaboard() static.
v7: Add MAINTAINERS entry for Ventana. Tom Warren doesn't have Ventana, so
he asked me to add myself for this board.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
---
MAINTAINERS | 5 +++
board/nvidia/seaboard/seaboard.c | 11 ++++++-
board/nvidia/ventana/Makefile | 49 +++++++++++++++++++++++++++++++++
boards.cfg | 1 +
include/configs/ventana.h | 55 ++++++++++++++++++++++++++++++++++++++
5 files changed, 119 insertions(+), 2 deletions(-)
create mode 100644 board/nvidia/ventana/Makefile
create mode 100644 include/configs/ventana.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 576fea8..6ff894c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -873,6 +873,11 @@ Tom Warren <twarren@nvidia.com>
harmony Tegra2 (ARM7 & A9 Dual Core)
seaboard Tegra2 (ARM7 & A9 Dual Core)
+Tom Warren <twarren@nvidia.com>
+Stephen Warren <twarren@nvidia.com>
+
+ ventana Tegra2 (ARM7 & A9 Dual Core)
+
Lei Wen <leiwen@marvell.com>
dkb ARM926EJS (PANTHEON 88AP920 SOC)
diff --git a/board/nvidia/seaboard/seaboard.c b/board/nvidia/seaboard/seaboard.c
index 356d616..aa77f12 100644
--- a/board/nvidia/seaboard/seaboard.c
+++ b/board/nvidia/seaboard/seaboard.c
@@ -32,10 +32,10 @@
#include "../common/board.h"
/*
- * Routine: gpio_config_uart
+ * Routine: gpio_config_uart_seaboard
* Description: Force GPIO_PI3 low on Seaboard so UART4 works.
*/
-void gpio_config_uart(void)
+static void gpio_config_uart_seaboard(void)
{
int gp = GPIO_PI3;
struct gpio_ctlr *gpio = (struct gpio_ctlr *)NV_PA_GPIO_BASE;
@@ -56,6 +56,13 @@ void gpio_config_uart(void)
writel(val, &bank->gpio_dir_out[GPIO_PORT(gp)]);
}
+void gpio_config_uart(void)
+{
+ if (machine_is_ventana())
+ return;
+ gpio_config_uart_seaboard();
+}
+
#ifdef CONFIG_TEGRA2_MMC
/*
* Routine: pin_mux_mmc
diff --git a/board/nvidia/ventana/Makefile b/board/nvidia/ventana/Makefile
new file mode 100644
index 0000000..9e5a87f
--- /dev/null
+++ b/board/nvidia/ventana/Makefile
@@ -0,0 +1,49 @@
+#
+# (C) Copyright 2010,2011
+# NVIDIA Corporation <www.nvidia.com>
+#
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+ifneq ($(OBJTREE),$(SRCTREE))
+$(shell mkdir -p $(obj)../common)
+endif
+
+LIB = $(obj)lib$(BOARD).o
+
+COBJS += ../seaboard/seaboard.o
+COBJS += ../common/board.o
+
+SRCS := $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+
+$(LIB): $(obj).depend $(OBJS)
+ $(call cmd_link_o_target, $(OBJS))
+
+#########################################################################
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#########################################################################
diff --git a/boards.cfg b/boards.cfg
index 604becf..83a0039 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -194,6 +194,7 @@ s5pc210_universal arm armv7 universal_c210 samsung
smdkv310 arm armv7 smdkv310 samsung s5pc2xx
harmony arm armv7 harmony nvidia tegra2
seaboard arm armv7 seaboard nvidia tegra2
+ventana arm armv7 ventana nvidia tegra2
u8500_href arm armv7 u8500 st-ericsson u8500
actux1_4_16 arm ixp actux1 - - actux1:FLASH2X2
actux1_8_16 arm ixp actux1 - - actux1:FLASH1X8
diff --git a/include/configs/ventana.h b/include/configs/ventana.h
new file mode 100644
index 0000000..afd6ff6
--- /dev/null
+++ b/include/configs/ventana.h
@@ -0,0 +1,55 @@
+/*
+ * (C) Copyright 2010,2011
+ * NVIDIA Corporation <www.nvidia.com>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+#include <asm/sizes.h>
+#include "tegra2-common.h"
+
+/* High-level configuration options */
+#define TEGRA2_SYSMEM "mem=384M at 0M nvmem=128M at 384M mem=512M at 512M"
+#define V_PROMPT "Tegra2 (Ventana) # "
+#define CONFIG_TEGRA2_BOARD_STRING "NVIDIA Ventana"
+
+/* Board-specific serial config */
+#define CONFIG_SERIAL_MULTI
+#define CONFIG_TEGRA2_ENABLE_UARTD
+#define CONFIG_SYS_NS16550_COM1 NV_PA_APB_UARTD_BASE
+
+#define CONFIG_MACH_TYPE MACH_TYPE_VENTANA
+#define CONFIG_SYS_BOARD_ODMDATA 0x300d8011 /* lp1, 1GB */
+
+#define CONFIG_BOARD_EARLY_INIT_F
+
+/* SD/MMC */
+#define CONFIG_MMC
+#define CONFIG_GENERIC_MMC
+#define CONFIG_TEGRA2_MMC
+#define CONFIG_CMD_MMC
+
+#define CONFIG_DOS_PARTITION
+#define CONFIG_EFI_PARTITION
+#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_FAT
+#endif /* __CONFIG_H */
--
1.7.0.4
^ permalink raw reply related
* Re: [Qemu-devel] [PULL] libcacard patches
From: Anthony Liguori @ 2011-10-31 16:51 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20111025134817.GJ3490@bow>
On 10/25/2011 08:48 AM, Alon Levy wrote:
> The following changes since commit 952e849c150b4f1b89f8728cba00f925c1d6e75b:
>
> Merge remote-tracking branch 'bonzini/split-main-loop-for-anthony' into staging (2011-10-24 10:51:12 -0500)
>
> are available in the git repository at:
>
> git://anongit.freedesktop.org/~alon/qemu pull-libcacard-assert
Pulled. Thanks.
Regards,
Anthony Liguori
>
> Alon Levy (2):
> libcacard/cac: fix typo in cac_delete_pki_applet_private
> libcacard/vscclient: fix error paths for socket creation
>
> Stefan Weil (1):
> libcacard: Fix wrong assertion (reported by cppcheck)
>
> libcacard/cac.c | 3 ++-
> libcacard/card_7816.c | 2 +-
> libcacard/vscclient.c | 9 +++++++--
> 3 files changed, 10 insertions(+), 4 deletions(-)
>
> Thanks,
> Alon
>
>
^ permalink raw reply
* RE: [PATCH] kill-subarray: fix, IMSM cannot kill-subarray with unsupported metadata
From: Labun, Marcin @ 2011-10-31 16:52 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid@vger.kernel.org, Williams, Dan J
In-Reply-To: <20111031113151.64f566b1@notabene.brown>
> -----Original Message-----
> From: NeilBrown [mailto:neilb@suse.de]
> Sent: Monday, October 31, 2011 1:32 AM
> To: Labun, Marcin
> Cc: linux-raid@vger.kernel.org; Williams, Dan J
> Subject: Re: [PATCH] kill-subarray: fix, IMSM cannot kill-subarray with
> unsupported metadata
>
> On Fri, 28 Oct 2011 14:46:57 +0000 "Labun, Marcin"
> <Marcin.Labun@intel.com>
> wrote:
>
> > Hi Neil,
> > Please review modified patch in response for your comments.
> > I have introduced two flags, one for activation blocking, second for
> > container wide reshapes
> > Blocking:
> > - some arrays in container are blocked, the others can be activated
> > and reshaped,
> > - some arrays are blocked, others can be activated but container wide
> reshaped is blocked for all.
> >
> > Thanks,
> > Marcin Labun
>
> Thanks. This looks mostly OK.
> I have applied it - with a number of formatting improvements and the
> removal for a debugging printf :-)
Thanks!
It seems that map_lock call appeared from *nowhere* in the modified patch :). Please see the context below.
- /* do not assemble arrays that might have bad blocks */
- if (list && list->array.state & (1<<MD_SB_BBM_ERRORS)) {
- fprintf(stderr, Name ": BBM log found in metadata. "
- "Cannot activate array(s).\n");
- /* free container data and exit */
- sysfs_free(list);
- return 2;
- }
-
+ /* when nothing to activate - quit */
+ if (list == NULL)
+ return 0;
+ if (map_lock(&map))
+ fprintf(stderr, Name ": failed to get exclusive lock on "
+ "mapfile\n");
>
> However this bit looks wrong:
>
> > +/*
> > + * helper routine to check metadata reshape avalability
> > + * 1. Do not "grow" arrays with volume activation blocked
> > + * 2. do not reshape containers with container reshape blocked
> > + *
> > + * IN:
> > + * subarray - array name or NULL for container wide reshape
> > + * content - md device info from container_content
> > + * OUT:
> > + * 0 - block reshape
> > + */
> > +static int check_reshape(char *subarray, struct mdinfo *content) {
> > + char *ep;
> > + unsigned int idx;
> > + printf("subarray: %s\n", subarray);
> > +
> > +
> > + if (!subarray) {
> > + if (content->array.state &
> (1<<MD_SB_BLOCK_CONTAINER_RESHAPE))
> > + return 0;
> > + }
> > + else {
> > + /* do not "grow" arrays with volume activation blocked */
> > + idx = strtoul(subarray, &ep, 10);
> > + if ((*ep == '\0') && (content->container_member == (int)
> idx) &&
> > + (content->array.state & (1<<MD_SB_BLOCK_VOLUME)))
> > + return 0;
> > + }
> > +
> > + return 1;
> > +}
>
> Grow.c shouldn't be doing a 'strtoul' here. The subarray string
> belongs to the metadata handler, mdadm core code shouldn't interpret it
> at all.
>
> What exactly is the point of that bit of code?
>
> Thanks,
> NeilBrown
Grow.c generates subarray string in super_by_fd() function.Derived from (struct mdinfo) sra->text_version.
In check_reshape function I want to know on which subarray grow operates to get subarray blocking bits.
Thanks,
Marcin Labun
^ permalink raw reply
* Re: [PATCH 01/11] drm: add plane support
From: Jesse Barnes @ 2011-10-31 16:52 UTC (permalink / raw)
To: Inki Dae; +Cc: intel-gfx
In-Reply-To: <loom.20111031T113759-104@post.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1853 bytes --]
On Mon, 31 Oct 2011 11:40:57 +0000 (UTC)
Inki Dae <daeinki@gmail.com> wrote:
> below is my simple idea.
> 1. user requests buffer allocation with pixel format and resolution through
> gem framework.
> 2. gem framework checks pixel format.
> 3. specific gem framework allocates buffers as plane count according to the
> pixel format. (please, know that gem framework provides just interface so
> acctual implementation would be done at specific gem framework)
> 4. user gets the gem handle from gem framework.
> 5. user sets the gem handle to specific drm framebuffer through
> drm_mode_addfb2 function.
> 6. user requests setcrtc with fb id and crtc id.
> 7. drm framework sets framebuffer(corresponding to fb id) to drm_mode_set.
> 8. crtc calls set_config callbacks to configure hardware.
> 9. specific crtc framework gets all buffers through framebuffer(actually, it
> would be specific framebuffer)and sets them to overlay registers of hardware
> appropriately.
>
>
> like this, how about using framebuffer and gem framework instead of plane? I'd
> be glad to give me your opinions.
I'm not opposed to pushing the multi-object stuff into GEM instead, but
I don't think step (9) will be enough to avoid having a separate plane
object. Say the user passes in 3 RGB buffers. How do you know which
one is the primary and which are overlays? Or are you saying the fb
would have that information as well? If so, it would be a little
harder to specify things like blending options or colorspace correction
on a per-plane basis...
But maybe I'm missing some part of things; do you have any patches to
illustrate what you mean? I can see how it might work, but I don't
know if it would be any simpler or cleaner than exposing plane objects.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [Qemu-devel] [PULL 00/55] Block patches
From: Anthony Liguori @ 2011-10-31 16:52 UTC (permalink / raw)
To: Kevin Wolf; +Cc: qemu-devel
In-Reply-To: <1320067830-12093-1-git-send-email-kwolf@redhat.com>
On 10/31/2011 08:29 AM, Kevin Wolf wrote:
> The following changes since commit b5a12aa204f842c8010ac9d2e4b115114dbf09f0:
>
> Merge branch 'rth/vis2' of git://repo.or.cz/qemu/rth (2011-10-27 20:27:07 +0000)
>
> are available in the git repository at:
>
> git://repo.or.cz/qemu/kevin.git for-anthony
Pulled. Thanks.
Regards,
Anthony Liguori
>
> Dong Xu Wang (1):
> block: fix qcow2_co_flush deadlock
>
> Eric Sunshine (1):
> Teach block/vdi about "discarded" (no longer allocated) blocks
>
> Kevin Wolf (7):
> block: Remove dead code
> block: Fix bdrv_open use after free
> qcow: Fix bdrv_write_compressed error handling
> ide: Fix off-by-one error in array index check
> vmdk: Fix use of uninitialised value
> vmdk: Improve error handling
> vmdk: Fix possible segfaults
>
> Paolo Bonzini (38):
> scsi: pass correct sense code for ENOMEDIUM
> atapi/scsi: unify definitions for MMC
> atapi: move GESN definitions to scsi-defs.h
> atapi: cleanup/fix mode sense results
> scsi: notify the device when unit attention is reported
> scsi-disk: report media changed via unit attention sense codes
> scsi-disk: fix coding style issues (braces)
> scsi-disk: add stubs for more MMC commands
> scsi-disk: store valid mode pages in a table
> atapi/scsi-disk: make mode page values coherent between the two
> scsi-disk: support DVD profile in GET CONFIGURATION
> scsi-disk: support READ DVD STRUCTURE
> scsi-disk: report media changed via GET EVENT STATUS NOTIFICATION
> scsi: move tcq/ndev to SCSIBusOps (now SCSIBusInfo)
> qdev: switch children device list to QTAILQ
> scsi: remove devs array from SCSIBus
> scsi: implement REPORT LUNS for arbitrary LUNs
> scsi: allow arbitrary LUNs
> scsi: add channel to addressing
> scsi-disk: fail READ CAPACITY if LBA != 0 but PMI == 0
> scsi-disk: fix retrying a flush
> scsi-generic: drop SCSIGenericState
> scsi-generic: remove scsi_req_fixup
> scsi-generic: check ioctl statuses when SG_IO succeeds
> scsi-generic: look at host status
> scsi-generic: snoop READ CAPACITY commands to get block size
> scsi-disk: do not duplicate BlockDriverState member
> scsi-disk: remove cluster_size
> scsi-disk: small clean up to INQUIRY
> scsi: move max_lba to SCSIDevice
> scsi: make reqops const
> scsi: export scsi_generic_reqops
> scsi: pass cdb to alloc_req
> scsi: do not call transfer_data after canceling a request
> scsi-disk: bump SCSIRequest reference count until aio completion runs
> scsi-generic: bump SCSIRequest reference count until aio completion runs
> scsi: push request restart to SCSIDevice
> scsi-disk: add scsi-block for device passthrough
>
> Ronnie Sahlberg (4):
> iSCSI block driver
> Documentation: Add iSCSI section
> Documentation: Describe NBD URL syntax
> Documentation: Add syntax for using sheepdog devices
>
> Stefan Hajnoczi (3):
> qemu-io: delete bs instead of leaking it
> block: set bs->read_only before .bdrv_open()
> block: reinitialize across bdrv_close()/bdrv_open()
>
> Zhi Yong Wu (1):
> qcow2: fix some errors and typo in qcow2.txt
>
> Makefile.objs | 1 +
> block.c | 18 +-
> block/iscsi.c | 591 ++++++++++++++++++++++++++++++++++++
> block/qcow.c | 30 ++-
> block/qcow2.c | 2 +
> block/vdi.c | 23 +-
> block/vmdk.c | 30 ++-
> configure | 31 ++
> docs/specs/qcow2.txt | 6 +-
> hw/acpi_piix4.c | 4 +-
> hw/esp.c | 16 +-
> hw/i2c.c | 2 +-
> hw/ide/atapi.c | 119 +++-----
> hw/ide/core.c | 6 +-
> hw/ide/internal.h | 71 +-----
> hw/ide/macio.c | 2 +-
> hw/intel-hda.c | 6 +-
> hw/lsi53c895a.c | 30 +-
> hw/qdev.c | 24 +-
> hw/qdev.h | 4 +-
> hw/s390-virtio-bus.c | 4 +-
> hw/scsi-bus.c | 279 +++++++++++++----
> hw/scsi-defs.h | 90 ++++++
> hw/scsi-disk.c | 824 +++++++++++++++++++++++++++++++++++++-------------
> hw/scsi-generic.c | 201 ++++++-------
> hw/scsi.h | 39 ++-
> hw/spapr_vio.c | 6 +-
> hw/spapr_vscsi.c | 54 +++-
> hw/ssi.c | 6 +-
> hw/usb-msd.c | 8 +-
> qemu-io.c | 5 +-
> qemu-options.hx | 90 ++++++
> trace-events | 7 +
> 33 files changed, 1979 insertions(+), 650 deletions(-)
> create mode 100644 block/iscsi.c
>
>
^ permalink raw reply
* Re: [Qemu-devel] [PULL 00/10] Trivial patches for October 15 to 26 2011
From: Anthony Liguori @ 2011-10-31 16:52 UTC (permalink / raw)
To: Stefan Hajnoczi; +Cc: qemu-devel
In-Reply-To: <1319638933-19063-1-git-send-email-stefanha@linux.vnet.ibm.com>
On 10/26/2011 09:22 AM, Stefan Hajnoczi wrote:
> The following changes since commit d300854b1ccd036e0d7c58d789f4ab8d372263e6:
>
> target-sparc: Fix use of g_new0 / g_free (2011-10-25 19:30:33 +0000)
>
> are available in the git repository at:
> ssh://repo.or.cz/srv/git/qemu/stefanha.git trivial-patches
Pulled. Thanks.
Regards,
Anthony Liguori
>
> Bernhard Reutner-Fischer (1):
> Documentation: fix typo
>
> Hervé Poussineau (1):
> Fix typo: buf -> bus
>
> Max Filippov (1):
> ahci: fix DPRINTF format strings
>
> Paolo Bonzini (1):
> tools: reorganize Makefile variables
>
> Pavel Borzenkov (4):
> vmdk: remove unneeded variable assignment
> vmdk: vmdk_read_cid returns garbage if p_name is NULL
> qed: don't pass NULL to memcpy
> qed: remove unneeded variable assignment
>
> Stefan Weil (1):
> device_tree: Fix potential memory leak
>
> 陳韋任 (1):
> exec.c: Remove useless comment
>
> Makefile | 32 +++++++++++++++-----------------
> Makefile.objs | 8 ++++----
> block/qed.c | 7 ++++---
> block/vmdk.c | 3 +--
> device_tree.c | 1 +
> exec.c | 1 -
> hw/audiodev.h | 2 +-
> hw/ide/ahci.c | 16 ++++++++++------
> qemu-doc.texi | 2 +-
> 9 files changed, 37 insertions(+), 35 deletions(-)
>
^ permalink raw reply
* Re: [Qemu-devel] [PULL] VirtFS update 7
From: Anthony Liguori @ 2011-10-31 16:52 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: QEMU Developers
In-Reply-To: <87d3dle7r7.fsf@linux.vnet.ibm.com>
On 10/25/2011 04:32 AM, Aneesh Kumar K.V wrote:
>
> Hi,
>
> This include all the pending patches for 1.0
>
> The following changes since commit 952e849c150b4f1b89f8728cba00f925c1d6e75b:
>
> Merge remote-tracking branch 'bonzini/split-main-loop-for-anthony' into staging (2011-10-24 10:51:12 -0500)
>
> are available in the git repository at:
>
> git://repo.or.cz/qemu/v9fs.git for-upstream-7
Pulled. Thanks.
Regards,
Anthony Liguori
>
> Aneesh Kumar K.V (5):
> hw/9pfs: Make VirtFS tracing work correctly
> hw/9pfs: Fix error handling in local_mknod
> configure: Update configure so that open_by_handle_at check returns correct value
> hw/9pfs: Abstract open state of fid to V9fsFidOpenState
> hw/9pfs: Add synthetic file system support using 9p
>
> Harsh Prateek Bora (2):
> qemu-queue: Introduce QLIST_INSERT_HEAD_RCU and dummy RCU wrappers.
> hw/9pfs: Replace rwlocks with RCU variants of interfaces.
>
> M. Mohan Kumar (2):
> qemu: Add opt_set_bool functionality
> hw/9pfs: Read-only support for 9p export
>
> Makefile.objs | 1 +
> configure | 2 +-
> fsdev/file-op-9p.h | 36 ++-
> fsdev/qemu-fsdev.c | 8 +-
> fsdev/qemu-fsdev.h | 1 +
> hw/9pfs/codir.c | 16 +-
> hw/9pfs/cofile.c | 37 ++--
> hw/9pfs/virtio-9p-coth.h | 6 +-
> hw/9pfs/virtio-9p-handle.c | 96 ++++---
> hw/9pfs/virtio-9p-local.c | 113 ++++----
> hw/9pfs/virtio-9p-synth.c | 571 +++++++++++++++++++++++++++++++++++++
> hw/9pfs/virtio-9p-synth.h | 50 ++++
> hw/9pfs/virtio-9p.c | 122 ++++++---
> hw/9pfs/virtio-9p.h | 27 ++-
> qemu-config.c | 7 +
> qemu-option.c | 39 +++-
> qemu-option.h | 3 +-
> qemu-options.hx | 23 ++-
> qemu-queue.h | 13 +
> qemu-thread.h | 3 +
> scripts/analyse-9p-simpletrace.py | 164 ++++++------
> trace-events | 2 +-
> vl.c | 20 ++
> 23 files changed, 1085 insertions(+), 275 deletions(-)
> create mode 100644 hw/9pfs/virtio-9p-synth.c
> create mode 100644 hw/9pfs/virtio-9p-synth.h
>
>
>
^ permalink raw reply
* Re: Setting proper video mode
From: Adam Jackson @ 2011-10-31 16:42 UTC (permalink / raw)
To: Jarek; +Cc: intel-gfx
In-Reply-To: <1319893248.7964.58.camel@tower.local>
On 10/29/11 9:00 AM, Jarek wrote:
> Is there something beside the modeline, which my affect setting display
> mode ? How to compare what is set with iegd that the display is working,
> and how to force xf86-video-intel to do the same ?
The first thing that comes to mind is infoframe setup for HDMI. Is this
an HDMI display?
Also, how does the output of intel_reg_dumper compare between the two
drivers?
> The modeline is exactly the same, except refresh rate, which in iegd is
> 61Hz, and in xf86-video-intel is 61.7 - I don't think that such small
> difference may affect the display.
If they're exactly the same then they can't really have different
refresh rates. Refresh rate is a derived quantity, the modeline
actually stores the pixel clock rate. If you were seeing different
refresh rates in the log file then you were seeing an artifact of the
roundoff math of the thing printing them.
On the other hand you might be reporting the refresh rate as seen on the
LCD's on-screen display, if it has one, in which case it's a little
weirder. That would indicate that you really are sending different
timings to the display, possibly because the PLL search code in iegd
picked a different answer. But dumping the m/n/p registers would tell you.
- ajax
^ permalink raw reply
* Re: [PATCH] dbus: add work around to set right owner in postinst
From: Saul Wold @ 2011-10-31 16:49 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Koen Kooi
In-Reply-To: <FF670D39-26C1-4B22-824A-CBBB99F71AAC@dominion.thruhere.net>
On 10/31/2011 01:54 AM, Koen Kooi wrote:
>
> Op 29 okt. 2011, om 12:53 heeft Martin Jansa het volgende geschreven:
>
>> * even when I see right chown/chmod in log.do_install, files are still
>> owned by bitbake:bitbake (user running bitbake) and we need to fix it on target
>
> I suspect fsperms.txt is breaking things, but I haven't tested it yet.
>
I did try to reset FILESYSTEM_PERMS_TABLE to "" and the issue still existed.
Further testing and debugging showed that both IPK and RPM packaging
seems to kill off the ownership, but DEB packaging retained it correctly!
More research and digging is required.
Sau!
> regards,
>
> Koen
>
>
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply
* Re: [Printing-architecture] Printing in Qt/KDE
From: Petrie, Glen @ 2011-10-31 16:56 UTC (permalink / raw)
To: John Layt, printing-architecture
In-Reply-To: <1923986.CutFMD6I4E@argo.layt.net>
Hi John,
I reviewed the QPrinter Class Reference information. While it appears
that most of the objects, attributes and values needed for printing are
present; I don't see that they align with existing and emerging
standards today; specifically, the PWG.
The PWG has had IPP and is now creating the PWG: Job Ticket (which
contains the objects, attributes and values) for printing. Companies
like Google, Apple, etc have stated or hinted they will be supporting
the PWG standards and the Job Ticket. Therefore, an area for
consideration is for QPrinter to align and extend the current printing
specific enum's to be more inline with the PWG Standards/Specifications.
I have not check if any new QPrinter enum's or functions are needed to
support the above standards; but it is another area for consideration.
Next, the print paradigm is shifting from print/printer drivers to print
services. This further implies that a print service now receives a
"print job" which consist of a print job ticket and print content (print
document, if you like). Like Adobe's Acrobat application which can
generate a JDF Job Ticket, another area of consideration is for QPrinter
to generate a "print job"; consisting of a print job ticket and print
content. This also helps to support Cloud Printing. I do understand
that the QPrinter::paintEngine could provide this functionality but
having the functionality built directly in to QPrinter, eliminates
developer having to recreate it.
Glen
-----Original Message-----
From: printing-architecture-bounces@lists.linux-foundation.org
[mailto:printing-architecture-bounces@lists.linux-foundation.org] On
Behalf Of John Layt
Sent: Thursday, October 27, 2011 10:20 AM
To: printing-architecture@lists.linux-foundation.org
Subject: Re: [Printing-architecture] Printing in Qt/KDE
On Wednesday 22 Jun 2011 23:49:12 John Layt wrote:
> You may have heard that Qt have decided the forthcoming Qt 4.8 release
will
> be the last in the Qt4 series and will be followed by Qt5, the first
> release under the new OpenGovernance development model.
Hi,
Just as a follow up to this, you may have seen that Nokia has now
launched the
Qt Open Governance project at qt-project.org and if you look closely
enough
you will see I have been appointed maintainer of the QPrinter module.
Basically it means I am now responsible for the ongoing maintenance of
QPrinter in Qt 4.8, and have the final say on any new code going into
QPrinter
from Qt 5 onwards. So if you have any issues with Qt printing, you know
who
to kick :-)
With regards to future plans not much has changed, my time is tied up
with
other stuff for Qt 5.0 so I'm starting with a bug triage for now, with
new
code to come in 5.1 or 5.2.
Cheers!
John.
_______________________________________________
Printing-architecture mailing list
Printing-architecture@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture
^ permalink raw reply
* Re: [Qemu-devel] [PULL 00/19]: QMP queue
From: Anthony Liguori @ 2011-10-31 16:52 UTC (permalink / raw)
To: Luiz Capitulino; +Cc: mdroth, qemu-devel
In-Reply-To: <1319742136-8691-1-git-send-email-lcapitulino@redhat.com>
On 10/27/2011 02:01 PM, Luiz Capitulino wrote:
> Anthony,
>
> This pull request contains only my "QAPI conversions round 2" series (which
> got no review comments... last chance!).
>
> The changes (since 9f60639b848944200c3d33a89233d808de0b5a43) are available
> in the following repository:
>
> git://repo.or.cz/qemu/qmp-unstable.git queue/qmp
Pulled. Thanks.
Regards,
Anthony Liguori
>
> Luiz Capitulino (19):
> qapi-commands.py: Don't call the output marshal on error
> qapi: Convert query-mice
> qapi: Convert query-migrate
> Monitor: Make mon_set_cpu() public
> Monitor: Introduce monitor_get_cpu_index()
> qapi: Convert the cpu command
> qapi: Convert query-cpus
> block: iostatus: Drop BDRV_IOS_INVAL
> block: Rename the BlockIOStatus enum values
> qapi: Convert query-block
> qapi: Convert query-blockstats
> qerror: Add a user string for QERR_FEATURE_DISABLED
> qapi: Convert query-vnc
> qapi: Convert query-spice
> qapi: Convert query-balloon
> qapi: Convert query-pci
> QMP: Drop the query commands dispatch table
> Monitor: do_info(): Drop QMP command handling code
> Drop qemu-objects.h from modules that don't require it
>
> balloon.c | 72 +-----
> balloon.h | 6 +-
> block.c | 234 ++++++------------
> block.h | 5 -
> block_int.h | 4 +-
> console.h | 9 -
> cpus.c | 45 ++++
> error.c | 3 +-
> hmp-commands.hx | 3 +-
> hmp.c | 407 ++++++++++++++++++++++++++++++
> hmp.h | 10 +
> hw/pci-stub.c | 15 +-
> hw/pci.c | 322 +++++++++---------------
> hw/pci.h | 4 -
> hw/virtio-balloon.c | 78 +-----
> input.c | 64 ++----
> migration.c | 82 ++-----
> monitor.c | 313 ++----------------------
> monitor.h | 2 +
> qapi-schema.json | 616 ++++++++++++++++++++++++++++++++++++++++++++++
> qerror.c | 4 +
> qmp-commands.hx | 60 +++++-
> qmp.c | 27 ++
> scripts/qapi-commands.py | 4 +-
> ui/spice-core.c | 139 +++++------
> ui/vnc.c | 135 +++++++----
> vl.c | 2 +-
> 27 files changed, 1611 insertions(+), 1054 deletions(-)
>
>
>
^ permalink raw reply
* Re: Flicker-free boot in DRM
From: Jesse Barnes @ 2011-10-31 16:57 UTC (permalink / raw)
To: Keith Packard; +Cc: drivers, Intel
In-Reply-To: <yuny5w4qnv1.fsf@aiko.keithp.com>
[-- Attachment #1.1: Type: text/plain, Size: 2469 bytes --]
On Sat, 29 Oct 2011 00:05:22 -0700
"Keith Packard" <keithp@keithp.com> wrote:
>
> Steve Langasek came over today and we hacked on the i915 driver
> initialization code to try and avoid the initial mode set. I thought I'd
> summarize what we found out.
>
> * Ubuntu has hacked up grub2 so that it gets the boot monitor running
> in a reasonable configuration using VBE calls if possible. In
> particular, it does try to find a 32bpp mode.
>
> Unfortunately, this won't actually work on many machines as the BIOS
> is often missing the native mode for the panel. So, we'll often need to
> deal with situations where the BIOS has got the panel running in the
> right mode, but there's a scaler running and the pipe and plane are
> wrong. I wonder if it's possible to change the plane/pipe/scaler
> configuration without turning the panel off and without causing any
> visible artifacts on the screen. My (limited) testing generated
> quite the visual fireworks...
Should be possible I think, but depends on the specific hardware rev.
Last time I tried lots of combinations was on Crestline for panel
fitting. Scaling down or up with fitting worked w/o shutting down the
pipe, but to scale back up from a centered mode required a pipeconf
toggle. I think BIOSes mostly use the fitter though, so it ought to be
possible.
> * Constructing a fake drm_framebuffer is a pain; there are a million
> places that assume all kinds of things about the frame buffer on
> a crtc.
Easier to just copy the contents out of the current framebuffer into a
new one before flipping to the new buffer.
> * DRM destroys all references to the current mode before crtc->mode_set is
> called. This makes it impossible to short-circuit pieces of mode_set
> internally. There's absolutely no reason for this; all of the
> changed data are available as parameters to the underlying functions.
>
> * drm should let the driver decide whether mode_set_base will work
> to switch frame buffers. Otherwise, there are all kinds of cases
> which the hardware supports and which it will refuse to let through.
> I think it should return -EAGAIN or some such to signal that the
> system should try to do a full mode set.
I think that's already possible if we don't use the helper function for
mode setting.
--
Jesse Barnes, Intel Open Source Technology Center
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [meta-efl][meta-oe 05/12] id3lib: Import from openembedded classic
From: Dodji Seketeli @ 2011-10-31 16:36 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <1320078283.3621.4.camel@mattotaupa>
Paul Menzel <paulepanter@users.sourceforge.net> a écrit:
> The guide lines I referred to [1] have been written for OE-core. ;-)
Just to be sure, do they apply to OE classic as well? They are neat.
> [1] http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
--
Dodji
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 0/6] [PULL] qemu-kvm.git uq/master queue
From: Anthony Liguori @ 2011-10-31 16:52 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: qemu-devel, kvm
In-Reply-To: <cover.1319717419.git.mtosatti@redhat.com>
On 10/27/2011 07:10 AM, Marcelo Tosatti wrote:
> The following changes since commit 952e849c150b4f1b89f8728cba00f925c1d6e75b:
>
> Merge remote-tracking branch 'bonzini/split-main-loop-for-anthony' into staging (2011-10-24 10:51:12 -0500)
>
> are available in the git repository at:
>
> git://github.com/avikivity/qemu.git uq/master
Pulled. Thanks.
Regards,
Anthony Liguori
>
> Avi Kivity (2):
> kvm: avoid reentring kvm_flush_coalesced_mmio_buffer()
> i386: wire up MSR_IA32_MISC_ENABLE
>
> Jan Kiszka (2):
> kvm: Add tool for querying VMX capabilities
> kvm: Add top-like kvm statistics script
>
> Liu, Jinsong (1):
> kvm: support TSC deadline MSR with subsection
>
> Marcelo Tosatti (1):
> Revert "kvm: support TSC deadline MSR"
>
> kvm-all.c | 10 +
> scripts/kvm/kvm_stat | 480 +++++++++++++++++++++++++++++++++++++++++++++++
> scripts/kvm/vmxcap | 224 ++++++++++++++++++++++
> target-i386/cpu.h | 7 +-
> target-i386/helper.c | 1 +
> target-i386/kvm.c | 15 ++
> target-i386/machine.c | 43 ++++-
> target-i386/op_helper.c | 6 +
> 8 files changed, 784 insertions(+), 2 deletions(-)
> create mode 100755 scripts/kvm/kvm_stat
> create mode 100755 scripts/kvm/vmxcap
>
>
^ permalink raw reply
* Re: [PATCH] drm: serialize access to debugs_nodes.list
From: Marcin Slusarz @ 2011-10-31 17:00 UTC (permalink / raw)
To: Daniel Vetter; +Cc: nouveau, dri-devel
In-Reply-To: <20111031080656.GD2920@phenom.ffwll.local>
On Mon, Oct 31, 2011 at 09:06:57AM +0100, Daniel Vetter wrote:
> This is just ugly, you're adding a mutex to every drm_info_node, but only
> use the one embedded into the minor. On a quick grep we're only ever using
> the list in there, so I suggest to
> - replace minor->debugfs_node.list with minor->debugfs_list and kill
> ->debugfs_node
> - add the mutex as minor->debugfs_lock
> That way it's clear what's going on.
Yes, you are right. I don't know what the heck I was thinking.
> Also, you've forgotten to add the locking to i915/i915_debugfs.c
Yeah. Will fix it too.
Marcin
^ permalink raw reply
* Re: [PATCH V2 2/2] mtd: tests: annotate as DANGEROUS in Kconfig
From: Brian Norris @ 2011-10-31 17:00 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linux-mtd, Artem Bityutskiy
In-Reply-To: <20111030203719.GA20162@pengutronix.de>
On Sun, Oct 30, 2011 at 1:37 PM, Wolfram Sang <w.sang@pengutronix.de> wrote:
> On Sun, Oct 30, 2011 at 10:34:53PM +0200, Artem Bityutskiy wrote:
>> On Sun, 2011-10-30 at 17:28 +0100, Wolfram Sang wrote:
>> > + WARNING: Some of the tests will ERASE THE CONTENT of mtd devices!
>> > + Do not use these tests unless you are sure you really need to.
>>
>> Thanks, I've pushed this patch but amended the above text a bit:
>> + WARNING: some of the tests will ERASE entire MTD device which they
>> + test. Do not use these tests unless you really know what you do.
Amendment to the amendment, perhaps? I think "unless you really know
what you do" should be "unless you really know what you are doing".
> OK, thanks! Seems we now finally have it :)
Maybe now we have it?
BTW, I agree that EXPERIMENTAL was not quite the right way to go.
Brian
^ permalink raw reply
* Re: [PATCH 1/2] meta-romley: Fix BSP description in romley.conf
From: Bodke, Kishore K @ 2011-10-31 17:01 UTC (permalink / raw)
To: Zanussi, Tom, yocto@yoctoproject.org
In-Reply-To: <3cf02697e2c7cf03c9f38b4c7d2192c1aceddc56.1319810084.git.tom.zanussi@intel.com>
Acked-by: Kishore Bodke <Kishore.k.bodke@intel.com>
Thanks
Kishore.
-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of tom.zanussi@intel.com
Sent: Friday, October 28, 2011 7:00 AM
To: yocto@yoctoproject.org
Subject: [yocto] [PATCH 1/2] meta-romley: Fix BSP description in romley.conf
From: Tom Zanussi <tom.zanussi@intel.com>
The description still had a reference to Sugar Bay; this changes it to
Romley.
Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
---
meta-romley/conf/machine/romley.conf | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta-romley/conf/machine/romley.conf b/meta-romley/conf/machine/romley.conf
index 38bd17a..2dcb5db 100644
--- a/meta-romley/conf/machine/romley.conf
+++ b/meta-romley/conf/machine/romley.conf
@@ -1,7 +1,7 @@
#@TYPE: Machine
#@NAME: romley
-#@DESCRIPTION: Machine configuration for Sugar Bay systems
+#@DESCRIPTION: Machine configuration for Romley systems
# i.e. Sandy Bridge + Patsburg Chipset
require conf/machine/include/tune-x86_64.inc
--
1.7.0.4
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
^ permalink raw reply related
* [U-Boot] mx31: NAND_SPL boot question for TT-01
From: Helmut Raiger @ 2011-10-31 17:01 UTC (permalink / raw)
To: u-boot
Hi (Stefano),
just a short question. I'd like to add NAND boot to the board
support of our TT-01.
I checked out the mx31pdk code and also found something in doc/README.SPL
which does not seem to correspond.
Before I head into the wrong direction again, is the mx31pdk implementation
still hip?
Thx, Helmut
--
Scanned by MailScanner.
^ permalink raw reply
* Re: [PATCH 2/2] nfs41: handle BLK_LAYOUT CB_RECALL_ANY
From: Peng Tao @ 2011-10-31 17:02 UTC (permalink / raw)
To: Trond Myklebust; +Cc: linux-nfs, bhalevy, Peng Tao
In-Reply-To: <1320079501.4714.9.camel@lade.trondhjem.org>
On Tue, Nov 1, 2011 at 12:45 AM, Trond Myklebust
<Trond.Myklebust@netapp.com> wrote:
> On Tue, 2011-11-01 at 00:38 +0800, Peng Tao wrote:
>> On Mon, Oct 31, 2011 at 11:49 PM, Trond Myklebust
>> <Trond.Myklebust@netapp.com> wrote:
>> > On Mon, 2011-10-31 at 08:15 -0700, Peng Tao wrote:
>> >> For blocklayout, we need to issue layoutreturn to return layouts when
>> >> handling CB_RECALL_ANY.
>> >
>> > Why?
>> Because replying NFS4_OK to CB_RECALL_ANY indicates that client knows
>> that server wants client to return layout. And server will be waiting
>> for layoutreturn in such case.
>
> No it doesn't. NFS4_OK means that the client acknowledges that it has
> been given a new limit on the number of recallable objects it can keep.
> There is no requirement in the text that it should send layoutreturn or
> that the server should expect that.
Per RFC5661 section 20.6.3:
It is the job of the client to bring down the size of the
recallable object set in line with each CB_RECALL_ANY received
For layout objects, the only way client can bring down the object
number is to send layoutreturn.
Besides, the moment client gets CB_RECALL_ANY is likely because server
reaches some resource threshold. If client doesn't send layoutreturn,
server can refusing client from getting more layouts.
>
> In any case, there is no reason to make a difference between block,
> object and file layouts when it comes to CB_RECALL_ANY. The code to
> handle it should be the same for all.
>
object layout isn't handling CB_RECALL_ANY yet. And from current code,
I was assuming file layouts have their own method at server side to
handle it (e.g., translating NFS4_OK of CB_RECALL_ANY into client has
dropped all its layout...).So I made it for block only.
Thanks,
Tao
> --
> Trond Myklebust
> Linux NFS client maintainer
>
> NetApp
> Trond.Myklebust@netapp.com
> www.netapp.com
>
>
--
Thanks,
-Bergwolf
^ permalink raw reply
* Re: [Qemu-devel] [PULL] spice patch queue
From: Anthony Liguori @ 2011-10-31 16:51 UTC (permalink / raw)
To: Gerd Hoffmann; +Cc: qemu-devel
In-Reply-To: <1319545550-24203-1-git-send-email-kraxel@redhat.com>
On 10/25/2011 07:25 AM, Gerd Hoffmann wrote:
> Hi,
>
> Here comes a bunch of spice/qxl fixes and cleanups. No major changes.
Pulled. Thanks.
Regards,
Anthony Liguori
>
> please pull,
> Gerd
>
> The following changes since commit 952e849c150b4f1b89f8728cba00f925c1d6e75b:
>
> Merge remote-tracking branch 'bonzini/split-main-loop-for-anthony' into staging (2011-10-24 10:51:12 -0500)
>
> are available in the git repository at:
>
> git://anongit.freedesktop.org/spice/qemu spice.v45
>
> Alon Levy (2):
> ui/spice-core: fix segfault in monitor
> qxl: reset update_surface
>
> Gerd Hoffmann (3):
> migration: add status query functions
> qxl: factor out properties
> spice: fix file handle cleanup
>
> Jan Kiszka (3):
> spice: Convert core to QEMU thread API
> qxl: Convert to QEMU thread API
> qxl: Drop phread_yield on OOM
>
> Yonit Halperin (3):
> spice: turn client_migrate_info to async
> spice: support the new migration interface (spice 0.8.3)
> qxl: fix guest cursor tracking
>
> hmp-commands.hx | 3 +-
> hw/qxl.c | 66 +++++++++++++++++++++-------------------------
> hw/qxl.h | 3 +-
> migration.c | 11 ++++++++
> migration.h | 2 +
> monitor.c | 6 +++-
> qmp-commands.hx | 3 +-
> ui/qemu-spice.h | 14 ++++++++--
> ui/spice-core.c | 78 +++++++++++++++++++++++++++++++++++++++++++++++-------
> 9 files changed, 132 insertions(+), 54 deletions(-)
>
>
^ permalink raw reply
* Re: [PATCH 2/2] meta-romley: change references to sugarbay in linux-yocto-rt_3.0.bbappend
From: Bodke, Kishore K @ 2011-10-31 17:03 UTC (permalink / raw)
To: Zanussi, Tom, yocto@yoctoproject.org
In-Reply-To: <03a680b265874eda3d07704a048c247c007f35dd.1319810084.git.tom.zanussi@intel.com>
Acked-by: Kishore Bodke <Kishore.k.bodke@intel.com>
Thanks
Kishore.
-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of tom.zanussi@intel.com
Sent: Friday, October 28, 2011 7:00 AM
To: yocto@yoctoproject.org
Subject: [yocto] [PATCH 2/2] meta-romley: change references to sugarbay in linux-yocto-rt_3.0.bbappend
From: Tom Zanussi <tom.zanussi@intel.com>
There are still references to sugarbay in linux-yocto-rt_3.0.bbappend;
this changes them to romley.
Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
---
.../linux/linux-yocto-rt_3.0.bbappend | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta-romley/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend b/meta-romley/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
index d630dc4..1551ccf 100644
--- a/meta-romley/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
+++ b/meta-romley/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
@@ -3,6 +3,6 @@ COMPATIBLE_MACHINE_romley = "romley"
KMACHINE_romley = "romley"
# Update the following to use a different BSP branch or meta SRCREV
-#KBRANCH_sugarbay = "yocto/standard/preempt-rt/base"
-#SRCREV_machine_pn-linux-yocto-rt_sugarbay ?= XXXX
-#SRCREV_meta_pn-linux-yocto-rt_sugarbay ?= XXXX
+#KBRANCH_romley = "yocto/standard/preempt-rt/base"
+#SRCREV_machine_pn-linux-yocto-rt_romley ?= XXXX
+#SRCREV_meta_pn-linux-yocto-rt_romley ?= XXXX
--
1.7.0.4
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.