* [meta-fsl-arm][PATCH 0/3] SabreLite updates
@ 2012-12-21 16:25 Gary Thomas
2012-12-21 16:25 ` [meta-fsl-arm][PATCH 1/3] xf86-video-imxfb-vivante: Update for new X server API Gary Thomas
` (2 more replies)
0 siblings, 3 replies; 19+ messages in thread
From: Gary Thomas @ 2012-12-21 16:25 UTC (permalink / raw)
To: meta-freescale
These changes allow building a fully functional X image for the SabreLite with
LCD/touchpanel
Gary Thomas (3):
xf86-video-imxfb-vivante: Update for new X server API
xserver-xf86-config: Add touch screen configuration for SabreLite
imx6qsabrelite/defconfig: Enable devtmpfs which is needed by udev 182
.../fix-vivante-compile.patch | 381 ++++++++++++++++++++
.../xf86-video-imxfb-vivante_12.09.01.bb | 1 +
.../imx6qsabrelite/11-touchscreen.conf | 7 +
.../xserver-xf86-config/imx6qsabrelite/xorg.conf | 14 +
.../xorg-xserver/xserver-xf86-config_0.1.bbappend | 9 +
.../linux-imx-3.0.35/imx6qsabrelite/defconfig | 2 +
6 files changed, 414 insertions(+), 0 deletions(-)
create mode 100644 recipes-graphics/xorg-driver/xf86-video-imxfb-vivante/fix-vivante-compile.patch
create mode 100644 recipes-graphics/xorg-xserver/xserver-xf86-config/imx6qsabrelite/11-touchscreen.conf
create mode 100644 recipes-graphics/xorg-xserver/xserver-xf86-config/imx6qsabrelite/xorg.conf
--
1.7.7.6
^ permalink raw reply [flat|nested] 19+ messages in thread* [meta-fsl-arm][PATCH 1/3] xf86-video-imxfb-vivante: Update for new X server API 2012-12-21 16:25 [meta-fsl-arm][PATCH 0/3] SabreLite updates Gary Thomas @ 2012-12-21 16:25 ` Gary Thomas 2012-12-21 16:46 ` Daiane Angolini 2012-12-21 16:25 ` [meta-fsl-arm][PATCH 2/3] xserver-xf86-config: SabreLite configuration Gary Thomas 2012-12-21 16:25 ` [meta-fsl-arm][PATCH 3/3] imx6qsabrelite/defconfig: Enable devtmpfs Gary Thomas 2 siblings, 1 reply; 19+ messages in thread From: Gary Thomas @ 2012-12-21 16:25 UTC (permalink / raw) To: meta-freescale X server 1.13 introduced driver API changes. These patches handle those changes in a backwards compatible way. Signed-off-by: Gary Thomas <gary@mlbassoc.com> --- .../fix-vivante-compile.patch | 381 ++++++++++++++++++++ .../xf86-video-imxfb-vivante_12.09.01.bb | 1 + 2 files changed, 382 insertions(+), 0 deletions(-) create mode 100644 recipes-graphics/xorg-driver/xf86-video-imxfb-vivante/fix-vivante-compile.patch diff --git a/recipes-graphics/xorg-driver/xf86-video-imxfb-vivante/fix-vivante-compile.patch b/recipes-graphics/xorg-driver/xf86-video-imxfb-vivante/fix-vivante-compile.patch new file mode 100644 index 0000000..d92acce --- /dev/null +++ b/recipes-graphics/xorg-driver/xf86-video-imxfb-vivante/fix-vivante-compile.patch @@ -0,0 +1,381 @@ +This patch handles changes in the X server API which appeared in version 1.13 +The changes should be backwards compatible so this driver still works in earlier +versions of the X server. + +Upstream-Status: Pending + +Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante_dri.h +=================================================================== +--- xserver-xorg-video-imx-viv-12.09.01.orig/src/vivante_fbdev/vivante_dri.h ++++ xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante_dri.h +@@ -67,7 +67,7 @@ typedef struct _vvtDeviceInfoRec { + } vvtDeviceInfo; + + Bool VivDRIScreenInit(ScreenPtr pScreen); +-void VivDRICloseScreen(ScreenPtr pScreen); ++void VivDRICloseScreen(CLOSE_SCREEN_ARGS_DECL); + Bool VivDRIFinishScreenInit(ScreenPtr pScreen); + + #endif /* _VIVANTE_DRI_H_ */ +Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante_fbdev_driver.c +=================================================================== +--- xserver-xorg-video-imx-viv-12.09.01.orig/src/vivante_fbdev/vivante_fbdev_driver.c ++++ xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante_fbdev_driver.c +@@ -19,7 +19,6 @@ + *****************************************************************************/ + + +- + #include "vivante_common.h" + #include "vivante.h" + #include "vivante_exa.h" +@@ -54,9 +53,8 @@ static const OptionInfoRec *VivAvailable + static void VivIdentify(int flags); + static Bool VivProbe(DriverPtr drv, int flags); + static Bool VivPreInit(ScrnInfoPtr pScrn, int flags); +-static Bool VivScreenInit(int Index, ScreenPtr pScreen, int argc, +- char **argv); +-static Bool VivCloseScreen(int scrnIndex, ScreenPtr pScreen); ++static Bool VivScreenInit(SCREEN_INIT_ARGS_DECL); ++static Bool VivCloseScreen(CLOSE_SCREEN_ARGS_DECL); + static Bool VivDriverFunc(ScrnInfoPtr pScrn, xorgDriverFuncOp op, + pointer ptr); + +@@ -178,7 +176,7 @@ VivSetup(pointer module, pointer opts, i + + static Bool InitExaLayer(ScreenPtr pScreen) { + ExaDriverPtr pExa; +- ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum]; ++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen); + VivPtr pViv = GET_VIV_PTR(pScrn); + + TRACE_ENTER(); +@@ -274,7 +272,7 @@ static Bool InitExaLayer(ScreenPtr pScre + } + + static Bool DestroyExaLayer(ScreenPtr pScreen) { +- ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum]; ++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen); + VivPtr pViv = GET_VIV_PTR(pScrn); + TRACE_ENTER(); + xf86DrvMsg(pScreen->myNum, X_INFO, "Shutdown EXA\n"); +@@ -590,7 +588,7 @@ VivPreInit(ScrnInfoPtr pScrn, int flags) + static Bool + VivCreateScreenResources(ScreenPtr pScreen) { + PixmapPtr pPixmap; +- ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum]; ++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen); + VivPtr fPtr = GET_VIV_PTR(pScrn); + Bool ret; + +@@ -612,8 +610,8 @@ VivCreateScreenResources(ScreenPtr pScre + } + + static Bool +-VivScreenInit(int scrnIndex, ScreenPtr pScreen, int argc, char **argv) { +- ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum]; ++VivScreenInit(SCREEN_INIT_ARGS_DECL) { ++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen); + VivPtr fPtr = GET_VIV_PTR(pScrn); + VisualPtr visual; + int init_picture = 0; +@@ -631,7 +629,7 @@ VivScreenInit(int scrnIndex, ScreenPtr p + + /*Mapping the Video memory*/ + if (NULL == (fPtr->mFB.mFBMemory = fbdevHWMapVidmem(pScrn))) { +- xf86DrvMsg(scrnIndex, X_ERROR, "mapping of video memory" ++ xf86DrvMsg(pScrn->scrnIndex, X_ERROR, "mapping of video memory" + " failed\n"); + TRACE_EXIT(FALSE); + } +@@ -647,11 +645,11 @@ VivScreenInit(int scrnIndex, ScreenPtr p + + /*Init the hardware in current mode*/ + if (!fbdevHWModeInit(pScrn, pScrn->currentMode)) { +- xf86DrvMsg(scrnIndex, X_ERROR, "mode initialization failed\n"); ++ xf86DrvMsg(pScrn->scrnIndex, X_ERROR, "mode initialization failed\n"); + TRACE_EXIT(FALSE); + } + fbdevHWSaveScreen(pScreen, SCREEN_SAVER_ON); +- fbdevHWAdjustFrame(scrnIndex, 0, 0, 0); ++ fbdevHWAdjustFrame(FBDEVHWADJUSTFRAME_ARGS(0, 0)); + + + +@@ -659,7 +657,7 @@ VivScreenInit(int scrnIndex, ScreenPtr p + miClearVisualTypes(); + if (pScrn->bitsPerPixel > 8) { + if (!miSetVisualTypes(pScrn->depth, TrueColorMask, pScrn->rgbBits, TrueColor)) { +- xf86DrvMsg(scrnIndex, X_ERROR, "visual type setup failed" ++ xf86DrvMsg(pScrn->scrnIndex, X_ERROR, "visual type setup failed" + " for %d bits per pixel [1]\n", + pScrn->bitsPerPixel); + TRACE_EXIT(FALSE); +@@ -668,14 +666,14 @@ VivScreenInit(int scrnIndex, ScreenPtr p + if (!miSetVisualTypes(pScrn->depth, + miGetDefaultVisualMask(pScrn->depth), + pScrn->rgbBits, pScrn->defaultVisual)) { +- xf86DrvMsg(scrnIndex, X_ERROR, "visual type setup failed" ++ xf86DrvMsg(pScrn->scrnIndex, X_ERROR, "visual type setup failed" + " for %d bits per pixel [2]\n", + pScrn->bitsPerPixel); + TRACE_EXIT(FALSE); + } + } + if (!miSetPixmapDepths()) { +- xf86DrvMsg(scrnIndex, X_ERROR, "pixmap depth setup failed\n"); ++ xf86DrvMsg(pScrn->scrnIndex, X_ERROR, "pixmap depth setup failed\n"); + return FALSE; + } + +@@ -684,14 +682,14 @@ VivScreenInit(int scrnIndex, ScreenPtr p + pScrn->displayWidth = fbdevHWGetLineLength(pScrn) / + (pScrn->bitsPerPixel / 8); + if (pScrn->displayWidth != pScrn->virtualX) { +- xf86DrvMsg(scrnIndex, X_INFO, ++ xf86DrvMsg(pScrn->scrnIndex, X_INFO, + "Pitch updated to %d after ModeInit\n", + pScrn->displayWidth); + } + /*Logical start address*/ + fPtr->mFB.mFBStart = fPtr->mFB.mFBMemory + fPtr->mFB.mFBOffset; + +- xf86DrvMsg(scrnIndex, X_INFO, ++ xf86DrvMsg(pScrn->scrnIndex, X_INFO, + "FB Start = %p FB Base = %p FB Offset = %p\n", + fPtr->mFB.mFBStart, fPtr->mFB.mFBMemory, fPtr->mFB.mFBOffset); + +@@ -708,7 +706,7 @@ VivScreenInit(int scrnIndex, ScreenPtr p + init_picture = 1; + break; + default: +- xf86DrvMsg(scrnIndex, X_ERROR, ++ xf86DrvMsg(pScrn->scrnIndex, X_ERROR, + "internal error: invalid number of bits per" + " pixel (%d) encountered in" + " VivScreenInit()\n", pScrn->bitsPerPixel); +@@ -740,7 +738,7 @@ VivScreenInit(int scrnIndex, ScreenPtr p + if (fPtr->mFakeExa.mUseExaFlag) { + TRACE_INFO("Loading EXA"); + if (!InitExaLayer(pScreen)) { +- xf86DrvMsg(scrnIndex, X_ERROR, ++ xf86DrvMsg(pScrn->scrnIndex, X_ERROR, + "internal error: initExaLayer failed " + "in VivScreenInit()\n"); + } +@@ -759,7 +757,7 @@ VivScreenInit(int scrnIndex, ScreenPtr p + + /* colormap */ + if (!miCreateDefColormap(pScreen)) { +- xf86DrvMsg(scrnIndex, X_ERROR, ++ xf86DrvMsg(pScrn->scrnIndex, X_ERROR, + "internal error: miCreateDefColormap failed " + "in VivScreenInit()\n"); + TRACE_EXIT(FALSE); +@@ -799,18 +797,18 @@ VivScreenInit(int scrnIndex, ScreenPtr p + } + + static Bool +-VivCloseScreen(int scrnIndex, ScreenPtr pScreen) { +- ScrnInfoPtr pScrn = xf86Screens[scrnIndex]; ++VivCloseScreen(CLOSE_SCREEN_ARGS_DECL) { ++ CLOSE_SCREEN_DECL_ScrnInfoPtr; + VivPtr fPtr = GET_VIV_PTR(pScrn); + Bool ret = FALSE; + TRACE_ENTER(); + +- VivDRICloseScreen(pScreen); ++ VivDRICloseScreen(CLOSE_SCREEN_ARGS); + + if (fPtr->mFakeExa.mUseExaFlag) { + DEBUGP("UnLoading EXA"); + if (fPtr->mFakeExa.mIsInited && !DestroyExaLayer(pScreen)) { +- xf86DrvMsg(scrnIndex, X_ERROR, ++ xf86DrvMsg(pScrn->scrnIndex, X_ERROR, + "internal error: DestroyExaLayer failed " + "in VivCloseScreen()\n"); + } +@@ -823,7 +821,7 @@ VivCloseScreen(int scrnIndex, ScreenPtr + + pScreen->CreateScreenResources = fPtr->CreateScreenResources; + pScreen->CloseScreen = fPtr->CloseScreen; +- ret = (*pScreen->CloseScreen)(scrnIndex, pScreen); ++ ret = (*pScreen->CloseScreen)(CLOSE_SCREEN_ARGS); + TRACE_EXIT(ret); + } + +Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_util/compat-api.h +=================================================================== +--- /dev/null ++++ xserver-xorg-video-imx-viv-12.09.01/src/vivante_util/compat-api.h +@@ -0,0 +1,106 @@ ++/* ++ * Copyright 2012 Red Hat, Inc. ++ * ++ * Permission is hereby granted, free of charge, to any person obtaining a ++ * copy of this software and associated documentation files (the "Software"), ++ * to deal in the Software without restriction, including without limitation ++ * the rights to use, copy, modify, merge, publish, distribute, sublicense, ++ * and/or sell copies of the Software, and to permit persons to whom the ++ * Software is furnished to do so, subject to the following conditions: ++ * ++ * The above copyright notice and this permission notice (including the next ++ * paragraph) shall be included in all copies or substantial portions of the ++ * Software. ++ * ++ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR ++ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, ++ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL ++ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER ++ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING ++ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER ++ * DEALINGS IN THE SOFTWARE. ++ * ++ * Author: Dave Airlie <airlied@redhat.com> ++ */ ++ ++/* this file provides API compat between server post 1.13 and pre it, ++ it should be reused inside as many drivers as possible */ ++#ifndef COMPAT_API_H ++#define COMPAT_API_H ++ ++#ifndef GLYPH_HAS_GLYPH_PICTURE_ACCESSOR ++#define GetGlyphPicture(g, s) GlyphPicture((g))[(s)->myNum] ++#define SetGlyphPicture(g, s, p) GlyphPicture((g))[(s)->myNum] = p ++#endif ++ ++#ifndef XF86_HAS_SCRN_CONV ++#define xf86ScreenToScrn(s) xf86Screens[(s)->myNum] ++#define xf86ScrnToScreen(s) screenInfo.screens[(s)->scrnIndex] ++#endif ++ ++#ifndef XF86_SCRN_INTERFACE ++ ++#define SCRN_ARG_TYPE int ++#define SCRN_INFO_PTR(arg1) ScrnInfoPtr pScrn = xf86Screens[(arg1)] ++ ++#define SCREEN_ARG_TYPE int ++#define SCREEN_PTR(arg1) ScreenPtr pScreen = screenInfo.screens[(arg1)] ++ ++#define SCREEN_INIT_ARGS_DECL int index, ScreenPtr pScreen, int argc, char **argv ++ ++#define BLOCKHANDLER_ARGS_DECL int arg, pointer blockData, pointer pTimeout, pointer pReadmask ++#define BLOCKHANDLER_ARGS arg, blockData, pTimeout, pReadmask ++ ++#define CLOSE_SCREEN_ARGS_DECL int scrnIndex, ScreenPtr pScreen ++#define CLOSE_SCREEN_ARGS scrnIndex, pScreen ++#define CLOSE_SCREEN_DECL_ScrnInfoPtr ScrnInfoPtr pScrn = xf86Screens[scrnIndex]; ++ ++#define FBDEVHWADJUSTFRAME_ARGS(x, y) scrnIndex, (x), (y), 0 ++ ++#define ADJUST_FRAME_ARGS_DECL int arg, int x, int y, int flags ++ ++#define SWITCH_MODE_ARGS_DECL int arg, DisplayModePtr mode, int flags ++ ++#define FREE_SCREEN_ARGS_DECL int arg, int flags ++#define FREE_SCREEN_ARGS(x) (x)->scrnIndex, 0 ++ ++#define VT_FUNC_ARGS_DECL int arg, int flags ++#define VT_FUNC_ARGS(flags) pScrn->scrnIndex, (flags) ++ ++#define ENABLE_DISABLE_FB_ACCESS_ARGS(pScrn, b) pScrn->scrnIndex, b ++ ++#define XF86_ENABLEDISABLEFB_ARG(x) ((x)->scrnIndex) ++#else ++#define SCRN_ARG_TYPE ScrnInfoPtr ++#define SCRN_INFO_PTR(arg1) ScrnInfoPtr pScrn = (arg1) ++ ++#define SCREEN_ARG_TYPE ScreenPtr ++#define SCREEN_PTR(arg1) ScreenPtr pScreen = (arg1) ++ ++#define SCREEN_INIT_ARGS_DECL ScreenPtr pScreen, int argc, char **argv ++ ++#define BLOCKHANDLER_ARGS_DECL ScreenPtr arg, pointer pTimeout, pointer pReadmask ++#define BLOCKHANDLER_ARGS arg, pTimeout, pReadmask ++ ++#define CLOSE_SCREEN_ARGS_DECL ScreenPtr pScreen ++#define CLOSE_SCREEN_ARGS pScreen ++#define CLOSE_SCREEN_DECL_ScrnInfoPtr ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum]; ++ ++#define FBDEVHWADJUSTFRAME_ARGS(x, y) pScrn, (x), (y) ++ ++#define ADJUST_FRAME_ARGS_DECL ScrnInfoPtr arg, int x, int y ++#define SWITCH_MODE_ARGS_DECL ScrnInfoPtr arg, DisplayModePtr mode ++ ++#define FREE_SCREEN_ARGS_DECL ScrnInfoPtr arg ++#define FREE_SCREEN_ARGS(x) (x) ++ ++#define VT_FUNC_ARGS_DECL ScrnInfoPtr arg ++#define VT_FUNC_ARGS(flags) pScrn ++ ++#define ENABLE_DISABLE_FB_ACCESS_ARGS(pScrn, b) pScrn, b ++ ++#define XF86_ENABLEDISABLEFB_ARG(x) (x) ++ ++#endif ++ ++#endif +Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_util/vivante_common.h +=================================================================== +--- xserver-xorg-video-imx-viv-12.09.01.orig/src/vivante_util/vivante_common.h ++++ xserver-xorg-video-imx-viv-12.09.01/src/vivante_util/vivante_common.h +@@ -76,6 +76,9 @@ extern "C" { + #include "xf86Crtc.h" + #include "cursorstr.h" + ++ /* System API compatability */ ++#include "compat-api.h" ++ + /*Debug*/ + #include "vivante_debug.h" + +Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante.h +=================================================================== +--- xserver-xorg-video-imx-viv-12.09.01.orig/src/vivante_fbdev/vivante.h ++++ xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante.h +@@ -99,11 +99,11 @@ extern "C" { + #define GET_VIV_PTR(p) ((VivPtr)((p)->driverPrivate)) + + #define VIVPTR_FROM_PIXMAP(x) \ +- GET_VIV_PTR(xf86Screens[(x)->drawable.pScreen->myNum]) ++ GET_VIV_PTR(xf86ScreenToScrn((x)->drawable.pScreen)) + #define VIVPTR_FROM_SCREEN(x) \ +- GET_VIV_PTR(xf86Screens[(x)->myNum]) ++ GET_VIV_PTR(xf86ScreenToScrn((x))) + #define VIVPTR_FROM_PICTURE(x) \ +- GET_VIV_PTR(xf86Screens[(x)->pDrawable->pScreen->myNum]) ++ GET_VIV_PTR(xf86ScreenToScrn((x)->pDrawable->pScreen)) + + /******************************************************************************** + * +Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante_dri.c +=================================================================== +--- xserver-xorg-video-imx-viv-12.09.01.orig/src/vivante_fbdev/vivante_dri.c ++++ xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante_dri.c +@@ -49,7 +49,7 @@ VivDestroyContext(ScreenPtr pScreen, drm + + Bool + VivDRIFinishScreenInit(ScreenPtr pScreen) { +- ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum]; ++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen); + VivPtr pViv = GET_VIV_PTR(pScrn); + DRIInfoPtr pDRIInfo = (DRIInfoPtr) pViv->pDRIInfo; + +@@ -79,7 +79,7 @@ VivDRIMoveBuffers(WindowPtr pParent, DDX + } + + Bool VivDRIScreenInit(ScreenPtr pScreen) { +- ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum]; ++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen); + DRIInfoPtr pDRIInfo; + VivPtr pViv = GET_VIV_PTR(pScrn); + +@@ -185,7 +185,7 @@ Bool VivDRIScreenInit(ScreenPtr pScreen) + } + + void VivDRICloseScreen(ScreenPtr pScreen) { +- ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum]; ++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen); + VivPtr pViv = GET_VIV_PTR(pScrn); + + if (pViv->pDRIInfo) { diff --git a/recipes-graphics/xorg-driver/xf86-video-imxfb-vivante_12.09.01.bb b/recipes-graphics/xorg-driver/xf86-video-imxfb-vivante_12.09.01.bb index 2b0d0a0..798e450 100644 --- a/recipes-graphics/xorg-driver/xf86-video-imxfb-vivante_12.09.01.bb +++ b/recipes-graphics/xorg-driver/xf86-video-imxfb-vivante_12.09.01.bb @@ -10,6 +10,7 @@ DEPENDS += "virtual/libx11 virtual/libgal-x11 gpu-viv-bin-mx6q" LIC_FILES_CHKSUM = "file://src/vivante_fbdev/vivante.h;endline=19;md5=93a322f91ec495569dcbcfbb2a95454a" SRC_URI = "${FSL_MIRROR}/xserver-xorg-video-imx-viv-${PV}.tar.gz \ + file://fix-vivante-compile.patch \ file://Makefile.am-remove-prefixed-include-path.patch" SRC_URI[md5sum] = "1948119717aa01bed1f630be9ee7a708" SRC_URI[sha256sum] = "5b3be4b426d2d2803554df9e4d8919d1f9d17659c3153c71c6529f43c37e6ed1" -- 1.7.7.6 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [meta-fsl-arm][PATCH 1/3] xf86-video-imxfb-vivante: Update for new X server API 2012-12-21 16:25 ` [meta-fsl-arm][PATCH 1/3] xf86-video-imxfb-vivante: Update for new X server API Gary Thomas @ 2012-12-21 16:46 ` Daiane Angolini 2012-12-21 17:25 ` Andrei Gherzan 0 siblings, 1 reply; 19+ messages in thread From: Daiane Angolini @ 2012-12-21 16:46 UTC (permalink / raw) To: Gary Thomas; +Cc: meta-freescale On 12/21/2012 02:25 PM, Gary Thomas wrote: > X server 1.13 introduced driver API changes. These patches handle those > changes in a backwards compatible way. > > Signed-off-by: Gary Thomas <gary@mlbassoc.com> Reviewed-by: Daiane Angolini <daiane.angolini@freescale.com> ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [meta-fsl-arm][PATCH 1/3] xf86-video-imxfb-vivante: Update for new X server API 2012-12-21 16:46 ` Daiane Angolini @ 2012-12-21 17:25 ` Andrei Gherzan 0 siblings, 0 replies; 19+ messages in thread From: Andrei Gherzan @ 2012-12-21 17:25 UTC (permalink / raw) To: Daiane Angolini; +Cc: meta-freescale@yoctoproject.org [-- Attachment #1: Type: text/plain, Size: 829 bytes --] Great work. *Andrei Gherzan* mobile +40.744.478.414 fax +40.31.816.28.12 Email: andrei@gherzan.ro Email: andrei.gherzan@windriver.com Romania On Fri, Dec 21, 2012 at 6:46 PM, Daiane Angolini < daiane.angolini@freescale.com> wrote: > On 12/21/2012 02:25 PM, Gary Thomas wrote: > >> X server 1.13 introduced driver API changes. These patches handle those >> changes in a backwards compatible way. >> >> Signed-off-by: Gary Thomas <gary@mlbassoc.com> >> > > Reviewed-by: Daiane Angolini <daiane.angolini@freescale.com**> > > > ______________________________**_________________ > meta-freescale mailing list > meta-freescale@yoctoproject.**org <meta-freescale@yoctoproject.org> > https://lists.yoctoproject.**org/listinfo/meta-freescale<https://lists.yoctoproject.org/listinfo/meta-freescale> > [-- Attachment #2: Type: text/html, Size: 2135 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* [meta-fsl-arm][PATCH 2/3] xserver-xf86-config: SabreLite configuration 2012-12-21 16:25 [meta-fsl-arm][PATCH 0/3] SabreLite updates Gary Thomas 2012-12-21 16:25 ` [meta-fsl-arm][PATCH 1/3] xf86-video-imxfb-vivante: Update for new X server API Gary Thomas @ 2012-12-21 16:25 ` Gary Thomas 2012-12-21 16:50 ` Daiane Angolini 2012-12-21 17:16 ` Otavio Salvador 2012-12-21 16:25 ` [meta-fsl-arm][PATCH 3/3] imx6qsabrelite/defconfig: Enable devtmpfs Gary Thomas 2 siblings, 2 replies; 19+ messages in thread From: Gary Thomas @ 2012-12-21 16:25 UTC (permalink / raw) To: meta-freescale Complete X configuration for SabreLite with LCD/touch screen Signed-off-by: Gary Thomas <gary@mlbassoc.com> --- .../imx6qsabrelite/11-touchscreen.conf | 7 +++++++ .../xserver-xf86-config/imx6qsabrelite/xorg.conf | 14 ++++++++++++++ .../xorg-xserver/xserver-xf86-config_0.1.bbappend | 9 +++++++++ 3 files changed, 30 insertions(+), 0 deletions(-) create mode 100644 recipes-graphics/xorg-xserver/xserver-xf86-config/imx6qsabrelite/11-touchscreen.conf create mode 100644 recipes-graphics/xorg-xserver/xserver-xf86-config/imx6qsabrelite/xorg.conf diff --git a/recipes-graphics/xorg-xserver/xserver-xf86-config/imx6qsabrelite/11-touchscreen.conf b/recipes-graphics/xorg-xserver/xserver-xf86-config/imx6qsabrelite/11-touchscreen.conf new file mode 100644 index 0000000..526b840 --- /dev/null +++ b/recipes-graphics/xorg-xserver/xserver-xf86-config/imx6qsabrelite/11-touchscreen.conf @@ -0,0 +1,7 @@ +Section "InputClass" +Identifier "tsc2004" +MatchProduct "tsc2004" +MatchDevicePath "/dev/input/event*" +Driver "evdev" +Option "InvertX" "true" +EndSection diff --git a/recipes-graphics/xorg-xserver/xserver-xf86-config/imx6qsabrelite/xorg.conf b/recipes-graphics/xorg-xserver/xserver-xf86-config/imx6qsabrelite/xorg.conf new file mode 100644 index 0000000..b89bed6 --- /dev/null +++ b/recipes-graphics/xorg-xserver/xserver-xf86-config/imx6qsabrelite/xorg.conf @@ -0,0 +1,14 @@ +Section "Device" + Identifier "i.MX Accelerated Framebuffer Device" + Driver "vivante" + Option "fbdev" "/dev/fb0" + Option "vivante_fbdev" "/dev/fb0" + Option "HWcursor" "false" +EndSection + +Section "ServerFlags" + Option "BlankTime" "0" + Option "StandbyTime" "0" + Option "SuspendTime" "0" + Option "OffTime" "0" +EndSection diff --git a/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend b/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend index 8337e55..1c5334b 100644 --- a/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend +++ b/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend @@ -2,3 +2,12 @@ FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" PRINC := "${@int(PRINC) + 8}" + +# Mouse/touchscreen configuration +SRC_URI_append_imx6qsabrelite = " file://11-touchscreen.conf" + +do_install_append_imx6qsabrelite () { + install -d -m 0755 ${D}/etc/X11/xorg.conf.d + install -m 0755 ${WORKDIR}/11-touchscreen.conf ${D}/etc/X11/xorg.conf.d +} + -- 1.7.7.6 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [meta-fsl-arm][PATCH 2/3] xserver-xf86-config: SabreLite configuration 2012-12-21 16:25 ` [meta-fsl-arm][PATCH 2/3] xserver-xf86-config: SabreLite configuration Gary Thomas @ 2012-12-21 16:50 ` Daiane Angolini 2012-12-21 16:52 ` Gary Thomas 2012-12-21 17:16 ` Otavio Salvador 1 sibling, 1 reply; 19+ messages in thread From: Daiane Angolini @ 2012-12-21 16:50 UTC (permalink / raw) To: Gary Thomas; +Cc: meta-freescale On 12/21/2012 02:25 PM, Gary Thomas wrote: > Complete X configuration for SabreLite with LCD/touch screen > > Signed-off-by: Gary Thomas <gary@mlbassoc.com> > --- > .../imx6qsabrelite/11-touchscreen.conf | 7 +++++++ Do you think it would work for other boards? Or it's only to *one* imx6 sabre lite touchscreen? If it's for only one display, I think you should detail it on commit log. > .../xserver-xf86-config/imx6qsabrelite/xorg.conf | 14 ++++++++++++++ What's the difference on this xorg.conf? Why you cannot you the imx6 one? Daiane ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [meta-fsl-arm][PATCH 2/3] xserver-xf86-config: SabreLite configuration 2012-12-21 16:50 ` Daiane Angolini @ 2012-12-21 16:52 ` Gary Thomas 0 siblings, 0 replies; 19+ messages in thread From: Gary Thomas @ 2012-12-21 16:52 UTC (permalink / raw) To: Daiane Angolini; +Cc: meta-freescale On 2012-12-21 09:50, Daiane Angolini wrote: > On 12/21/2012 02:25 PM, Gary Thomas wrote: >> Complete X configuration for SabreLite with LCD/touch screen >> >> Signed-off-by: Gary Thomas <gary@mlbassoc.com> >> --- >> .../imx6qsabrelite/11-touchscreen.conf | 7 +++++++ > > Do you think it would work for other boards? Or it's only to *one* imx6 sabre lite touchscreen? > > If it's for only one display, I think you should detail it on commit log. > >> .../xserver-xf86-config/imx6qsabrelite/xorg.conf | 14 ++++++++++++++ > > What's the difference on this xorg.conf? Why you cannot you the imx6 one? There currently is no difference but at some point there might be. Plus bitbake complains when it's not there. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [meta-fsl-arm][PATCH 2/3] xserver-xf86-config: SabreLite configuration 2012-12-21 16:25 ` [meta-fsl-arm][PATCH 2/3] xserver-xf86-config: SabreLite configuration Gary Thomas 2012-12-21 16:50 ` Daiane Angolini @ 2012-12-21 17:16 ` Otavio Salvador 2012-12-21 17:22 ` Gary Thomas 1 sibling, 1 reply; 19+ messages in thread From: Otavio Salvador @ 2012-12-21 17:16 UTC (permalink / raw) To: Gary Thomas; +Cc: meta-freescale@yoctoproject.org Gary, On Fri, Dec 21, 2012 at 2:25 PM, Gary Thomas <gary@mlbassoc.com> wrote: > Complete X configuration for SabreLite with LCD/touch screen > > Signed-off-by: Gary Thomas <gary@mlbassoc.com> Please take a look at https://wiki.kubuntu.org/X/InputConfiguration as it has a nice description how to map the Xorg configuration to udev rules. The nice thing about it is it would allow for it to be applied in all boards and in case same touch where used it'd just work as well. I'll skip this patch at this moment... -- Otavio Salvador O.S. Systems E-mail: otavio@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [meta-fsl-arm][PATCH 2/3] xserver-xf86-config: SabreLite configuration 2012-12-21 17:16 ` Otavio Salvador @ 2012-12-21 17:22 ` Gary Thomas 2012-12-21 17:26 ` Otavio Salvador 0 siblings, 1 reply; 19+ messages in thread From: Gary Thomas @ 2012-12-21 17:22 UTC (permalink / raw) To: Otavio Salvador; +Cc: meta-freescale@yoctoproject.org On 2012-12-21 10:16, Otavio Salvador wrote: > Gary, > > On Fri, Dec 21, 2012 at 2:25 PM, Gary Thomas <gary@mlbassoc.com> wrote: >> Complete X configuration for SabreLite with LCD/touch screen >> >> Signed-off-by: Gary Thomas <gary@mlbassoc.com> > > Please take a look at https://wiki.kubuntu.org/X/InputConfiguration as > it has a nice description how to map the Xorg configuration to udev > rules. The nice thing about it is it would allow for it to be applied > in all boards and in case same touch where used it'd just work as > well. > > I'll skip this patch at this moment... I'll look at this, but it seems waaaay complicated. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [meta-fsl-arm][PATCH 2/3] xserver-xf86-config: SabreLite configuration 2012-12-21 17:22 ` Gary Thomas @ 2012-12-21 17:26 ` Otavio Salvador 0 siblings, 0 replies; 19+ messages in thread From: Otavio Salvador @ 2012-12-21 17:26 UTC (permalink / raw) To: Gary Thomas; +Cc: meta-freescale@yoctoproject.org On Fri, Dec 21, 2012 at 3:22 PM, Gary Thomas <gary@mlbassoc.com> wrote: > On 2012-12-21 10:16, Otavio Salvador wrote: >> >> Gary, >> >> On Fri, Dec 21, 2012 at 2:25 PM, Gary Thomas <gary@mlbassoc.com> wrote: >>> >>> Complete X configuration for SabreLite with LCD/touch screen >>> >>> Signed-off-by: Gary Thomas <gary@mlbassoc.com> >> >> >> Please take a look at https://wiki.kubuntu.org/X/InputConfiguration as >> it has a nice description how to map the Xorg configuration to udev >> rules. The nice thing about it is it would allow for it to be applied >> in all boards and in case same touch where used it'd just work as >> well. >> >> I'll skip this patch at this moment... > > > I'll look at this, but it seems waaaay complicated. It is not. You deal with X11 options using ENV and rest is very similar to Xorg or (historic) HAL fdi files. -- Otavio Salvador O.S. Systems E-mail: otavio@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ^ permalink raw reply [flat|nested] 19+ messages in thread
* [meta-fsl-arm][PATCH 3/3] imx6qsabrelite/defconfig: Enable devtmpfs 2012-12-21 16:25 [meta-fsl-arm][PATCH 0/3] SabreLite updates Gary Thomas 2012-12-21 16:25 ` [meta-fsl-arm][PATCH 1/3] xf86-video-imxfb-vivante: Update for new X server API Gary Thomas 2012-12-21 16:25 ` [meta-fsl-arm][PATCH 2/3] xserver-xf86-config: SabreLite configuration Gary Thomas @ 2012-12-21 16:25 ` Gary Thomas 2012-12-21 16:51 ` Daiane Angolini 2012-12-21 17:19 ` Otavio Salvador 2 siblings, 2 replies; 19+ messages in thread From: Gary Thomas @ 2012-12-21 16:25 UTC (permalink / raw) To: meta-freescale Recent versions of udev (182 in OE-core) need devtmpfs to operate correctly Signed-off-by: Gary Thomas <gary@mlbassoc.com> --- .../linux-imx-3.0.35/imx6qsabrelite/defconfig | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/recipes-kernel/linux/linux-imx-3.0.35/imx6qsabrelite/defconfig b/recipes-kernel/linux/linux-imx-3.0.35/imx6qsabrelite/defconfig index 4118cba..1c8d6f3 100644 --- a/recipes-kernel/linux/linux-imx-3.0.35/imx6qsabrelite/defconfig +++ b/recipes-kernel/linux/linux-imx-3.0.35/imx6qsabrelite/defconfig @@ -86,6 +86,8 @@ CONFIG_CFG80211=y CONFIG_MAC80211=y CONFIG_RFKILL=y CONFIG_RFKILL_INPUT=y +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_CONNECTOR=y CONFIG_MTD=y -- 1.7.7.6 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [meta-fsl-arm][PATCH 3/3] imx6qsabrelite/defconfig: Enable devtmpfs 2012-12-21 16:25 ` [meta-fsl-arm][PATCH 3/3] imx6qsabrelite/defconfig: Enable devtmpfs Gary Thomas @ 2012-12-21 16:51 ` Daiane Angolini 2012-12-21 17:25 ` Andrei Gherzan 2012-12-21 17:19 ` Otavio Salvador 1 sibling, 1 reply; 19+ messages in thread From: Daiane Angolini @ 2012-12-21 16:51 UTC (permalink / raw) To: Gary Thomas; +Cc: meta-freescale On 12/21/2012 02:25 PM, Gary Thomas wrote: > Recent versions of udev (182 in OE-core) need devtmpfs to operate correctly > > Signed-off-by: Gary Thomas <gary@mlbassoc.com> Reviewed-by: Daiane Angolini <daiane.angolini@freescale.com> ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [meta-fsl-arm][PATCH 3/3] imx6qsabrelite/defconfig: Enable devtmpfs 2012-12-21 16:51 ` Daiane Angolini @ 2012-12-21 17:25 ` Andrei Gherzan 0 siblings, 0 replies; 19+ messages in thread From: Andrei Gherzan @ 2012-12-21 17:25 UTC (permalink / raw) To: Daiane Angolini; +Cc: meta-freescale@yoctoproject.org [-- Attachment #1: Type: text/plain, Size: 788 bytes --] ack *Andrei Gherzan* mobile +40.744.478.414 fax +40.31.816.28.12 Email: andrei@gherzan.ro Email: andrei.gherzan@windriver.com Romania On Fri, Dec 21, 2012 at 6:51 PM, Daiane Angolini < daiane.angolini@freescale.com> wrote: > On 12/21/2012 02:25 PM, Gary Thomas wrote: > >> Recent versions of udev (182 in OE-core) need devtmpfs to operate >> correctly >> >> Signed-off-by: Gary Thomas <gary@mlbassoc.com> >> > > Reviewed-by: Daiane Angolini <daiane.angolini@freescale.com**> > > > > ______________________________**_________________ > meta-freescale mailing list > meta-freescale@yoctoproject.**org <meta-freescale@yoctoproject.org> > https://lists.yoctoproject.**org/listinfo/meta-freescale<https://lists.yoctoproject.org/listinfo/meta-freescale> > [-- Attachment #2: Type: text/html, Size: 2092 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [meta-fsl-arm][PATCH 3/3] imx6qsabrelite/defconfig: Enable devtmpfs 2012-12-21 16:25 ` [meta-fsl-arm][PATCH 3/3] imx6qsabrelite/defconfig: Enable devtmpfs Gary Thomas 2012-12-21 16:51 ` Daiane Angolini @ 2012-12-21 17:19 ` Otavio Salvador 2012-12-21 18:37 ` Eric Nelson 1 sibling, 1 reply; 19+ messages in thread From: Otavio Salvador @ 2012-12-21 17:19 UTC (permalink / raw) To: Gary Thomas; +Cc: meta-freescale@yoctoproject.org On Fri, Dec 21, 2012 at 2:25 PM, Gary Thomas <gary@mlbassoc.com> wrote: > Recent versions of udev (182 in OE-core) need devtmpfs to operate correctly > > Signed-off-by: Gary Thomas <gary@mlbassoc.com> Merged to master with reworded commit log and bump PR. -- Otavio Salvador O.S. Systems E-mail: otavio@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [meta-fsl-arm][PATCH 3/3] imx6qsabrelite/defconfig: Enable devtmpfs 2012-12-21 17:19 ` Otavio Salvador @ 2012-12-21 18:37 ` Eric Nelson 2012-12-21 18:41 ` Otavio Salvador 0 siblings, 1 reply; 19+ messages in thread From: Eric Nelson @ 2012-12-21 18:37 UTC (permalink / raw) To: Otavio Salvador; +Cc: meta-freescale@yoctoproject.org On 12/21/2012 10:19 AM, Otavio Salvador wrote: > On Fri, Dec 21, 2012 at 2:25 PM, Gary Thomas <gary@mlbassoc.com> wrote: >> Recent versions of udev (182 in OE-core) need devtmpfs to operate correctly >> >> Signed-off-by: Gary Thomas <gary@mlbassoc.com> > > Merged to master with reworded commit log and bump PR. > Hi Otavio, I have a configuration patch to make, adding CONFIG_FEC_NAPI. Should I submit it with a bump in PR as you did, or without, so that you can coordinate that? The patch itself is to prevent network performance from cratering under load as discussed in this blog post: http://boundarydevices.com/i-mx6-ethernet/ And in this patch: https://github.com/boundarydevices/linux-imx6/commit/38d622938f1352a6550a5e38c624b46b6929439f Without it, network receive performance can get really bad under load. Please advise, Eric ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [meta-fsl-arm][PATCH 3/3] imx6qsabrelite/defconfig: Enable devtmpfs 2012-12-21 18:37 ` Eric Nelson @ 2012-12-21 18:41 ` Otavio Salvador 2012-12-21 19:12 ` Eric Nelson 0 siblings, 1 reply; 19+ messages in thread From: Otavio Salvador @ 2012-12-21 18:41 UTC (permalink / raw) To: Eric Nelson; +Cc: meta-freescale@yoctoproject.org On Fri, Dec 21, 2012 at 4:37 PM, Eric Nelson <eric.nelson@boundarydevices.com> wrote: > On 12/21/2012 10:19 AM, Otavio Salvador wrote: >> >> On Fri, Dec 21, 2012 at 2:25 PM, Gary Thomas <gary@mlbassoc.com> wrote: >>> >>> Recent versions of udev (182 in OE-core) need devtmpfs to operate >>> correctly >>> >>> Signed-off-by: Gary Thomas <gary@mlbassoc.com> >> >> >> Merged to master with reworded commit log and bump PR. >> > > Hi Otavio, > > I have a configuration patch to make, adding CONFIG_FEC_NAPI. > > Should I submit it with a bump in PR as you did, or without, so > that you can coordinate that? Please do it with bump in PR so it is easier for me. > The patch itself is to prevent network performance from cratering > under load as discussed in this blog post: > http://boundarydevices.com/i-mx6-ethernet/ > > And in this patch: > > https://github.com/boundarydevices/linux-imx6/commit/38d622938f1352a6550a5e38c624b46b6929439f > > Without it, network receive performance can get really bad under > load. Very nice! However you might like to simply sync the patch for your boundary tree (the patch compares FSL branch with Bondary ones) so this would be included. Or this should be applied in all boards? -- Otavio Salvador O.S. Systems E-mail: otavio@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [meta-fsl-arm][PATCH 3/3] imx6qsabrelite/defconfig: Enable devtmpfs 2012-12-21 18:41 ` Otavio Salvador @ 2012-12-21 19:12 ` Eric Nelson 2012-12-21 19:24 ` Otavio Salvador 0 siblings, 1 reply; 19+ messages in thread From: Eric Nelson @ 2012-12-21 19:12 UTC (permalink / raw) To: Otavio Salvador; +Cc: meta-freescale@yoctoproject.org On 12/21/2012 11:41 AM, Otavio Salvador wrote: > On Fri, Dec 21, 2012 at 4:37 PM, Eric Nelson > <eric.nelson@boundarydevices.com> wrote: >> On 12/21/2012 10:19 AM, Otavio Salvador wrote: >>> >>> On Fri, Dec 21, 2012 at 2:25 PM, Gary Thomas <gary@mlbassoc.com> wrote: >>>> >>>> Recent versions of udev (182 in OE-core) need devtmpfs to operate >>>> correctly >>>> >>>> Signed-off-by: Gary Thomas <gary@mlbassoc.com> >>> >>> >>> Merged to master with reworded commit log and bump PR. >>> >> >> Hi Otavio, >> >> I have a configuration patch to make, adding CONFIG_FEC_NAPI. >> >> Should I submit it with a bump in PR as you did, or without, so >> that you can coordinate that? > > Please do it with bump in PR so it is easier for me. > >> The patch itself is to prevent network performance from cratering >> under load as discussed in this blog post: >> http://boundarydevices.com/i-mx6-ethernet/ >> >> And in this patch: >> >> https://github.com/boundarydevices/linux-imx6/commit/38d622938f1352a6550a5e38c624b46b6929439f >> >> Without it, network receive performance can get really bad under >> load. > > Very nice! However you might like to simply sync the patch for your > boundary tree (the patch compares FSL branch with Bondary ones) so > this would be included. Or this should be applied in all boards? > Well... I was thinking that I'd just push this one, since it has a much bigger impact than the patches we made to flow control and error handling. I think I was a bit mistaken though. I didn't catch that this line was itself in a patch file: +# CONFIG_FEC_NAPI is not set I also didn't catch and don't quite understand how the defconfig file is applied in the build process. Is 'nitrogen6x_defconfig' even used? I don't see CONFIG_FEC in the defconfig. Does that file somehow get applied on top of a base configuration to apply Yocto specifics? There are some things in our boundary-L3.0.35_12.09.01_GA tree that I was hoping to clean up before submitting In particular, we set things up to allow a single image to boot on Quad->Solo that the Freescale team didn't like, so we'll probably revert it as we migrate to the 2012-10 branch, which will take a couple of weeks. I'm not really sure how to proceed. Please advise, Eric ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [meta-fsl-arm][PATCH 3/3] imx6qsabrelite/defconfig: Enable devtmpfs 2012-12-21 19:12 ` Eric Nelson @ 2012-12-21 19:24 ` Otavio Salvador 2012-12-21 20:06 ` Eric Nelson 0 siblings, 1 reply; 19+ messages in thread From: Otavio Salvador @ 2012-12-21 19:24 UTC (permalink / raw) To: Eric Nelson; +Cc: meta-freescale@yoctoproject.org On Fri, Dec 21, 2012 at 5:12 PM, Eric Nelson <eric.nelson@boundarydevices.com> wrote: > On 12/21/2012 11:41 AM, Otavio Salvador wrote: >> >> On Fri, Dec 21, 2012 at 4:37 PM, Eric Nelson >> <eric.nelson@boundarydevices.com> wrote: >>> >>> On 12/21/2012 10:19 AM, Otavio Salvador wrote: >>>> >>>> >>>> On Fri, Dec 21, 2012 at 2:25 PM, Gary Thomas <gary@mlbassoc.com> wrote: >>>>> >>>>> >>>>> Recent versions of udev (182 in OE-core) need devtmpfs to operate >>>>> correctly >>>>> >>>>> Signed-off-by: Gary Thomas <gary@mlbassoc.com> >>>> >>>> >>>> >>>> Merged to master with reworded commit log and bump PR. >>>> >>> >>> Hi Otavio, >>> >>> I have a configuration patch to make, adding CONFIG_FEC_NAPI. >>> >>> Should I submit it with a bump in PR as you did, or without, so >>> that you can coordinate that? >> >> >> Please do it with bump in PR so it is easier for me. >> >>> The patch itself is to prevent network performance from cratering >>> under load as discussed in this blog post: >>> http://boundarydevices.com/i-mx6-ethernet/ >>> >>> And in this patch: >>> >>> >>> https://github.com/boundarydevices/linux-imx6/commit/38d622938f1352a6550a5e38c624b46b6929439f >>> >>> Without it, network receive performance can get really bad under >>> load. >> >> >> Very nice! However you might like to simply sync the patch for your >> boundary tree (the patch compares FSL branch with Bondary ones) so >> this would be included. Or this should be applied in all boards? >> > > Well... I was thinking that I'd just push this one, since it has a much > bigger impact than the patches we made to flow control and error > handling. > > I think I was a bit mistaken though. I didn't catch that this line was > itself in a patch file: > +# CONFIG_FEC_NAPI is not set > > I also didn't catch and don't quite understand how the defconfig file > is applied in the build process. Is 'nitrogen6x_defconfig' even used? > > I don't see CONFIG_FEC in the defconfig. Does that file somehow get > applied on top of a base configuration to apply Yocto specifics? The defconfig, at linux-imx-<version> is generated using the machine config and calling make savedefconfig; so it should be the shorter version and produce same .config as result of dependencies. So the build system copy the defconfig onto .config, run "yes 'n' | make oldconfig" and build the kernel. You can sync the 12.09.01 branch and update the patch at: http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/recipes-kernel/linux/linux-imx-3.0.35/imx6qsabrelite/sync-boundary-changes.patch and updated: http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/recipes-kernel/linux/linux-imx-3.0.35/imx6qsabrelite/defconfig As I did the trick of using sabrelite as fallback to nitrogen board (check https://github.com/Freescale/meta-fsl-arm-extra/blob/master/conf/machine/nitrogen6x.conf#L6) it will use those, except a nitrogen specific one is provided. I did it to avoid duplicating things and easy maintenance. > There are some things in our boundary-L3.0.35_12.09.01_GA tree that > I was hoping to clean up before submitting > > In particular, we set things up to allow a single image to boot on > Quad->Solo that the Freescale team didn't like, so we'll probably It'd be nice indeed. Why they didn't like it? > revert it as we migrate to the 2012-10 branch, which will take a > couple of weeks. So revert back to several images depending on SoC model? Regards, -- Otavio Salvador O.S. Systems E-mail: otavio@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [meta-fsl-arm][PATCH 3/3] imx6qsabrelite/defconfig: Enable devtmpfs 2012-12-21 19:24 ` Otavio Salvador @ 2012-12-21 20:06 ` Eric Nelson 0 siblings, 0 replies; 19+ messages in thread From: Eric Nelson @ 2012-12-21 20:06 UTC (permalink / raw) To: Otavio Salvador; +Cc: meta-freescale@yoctoproject.org On 12/21/2012 12:24 PM, Otavio Salvador wrote: > On Fri, Dec 21, 2012 at 5:12 PM, Eric Nelson > <eric.nelson@boundarydevices.com> wrote: >> On 12/21/2012 11:41 AM, Otavio Salvador wrote: >>> >>> On Fri, Dec 21, 2012 at 4:37 PM, Eric Nelson >>> <eric.nelson@boundarydevices.com> wrote: >>>> >>>> On 12/21/2012 10:19 AM, Otavio Salvador wrote: >>>>> >>>>> On Fri, Dec 21, 2012 at 2:25 PM, Gary Thomas <gary@mlbassoc.com> wrote: >>>>>> >>>>>> Recent versions of udev (182 in OE-core) need devtmpfs to operate >>>>>> correctly >>>>>> >>>>>> Signed-off-by: Gary Thomas <gary@mlbassoc.com> >>>>> >>>>> Merged to master with reworded commit log and bump PR. >>>>> >>>> Hi Otavio, >>>> >>>> I have a configuration patch to make, adding CONFIG_FEC_NAPI. >>>> >>>> Should I submit it with a bump in PR as you did, or without, so >>>> that you can coordinate that? >>> >>> >>> Please do it with bump in PR so it is easier for me. >>> >>>> The patch itself is to prevent network performance from cratering >>>> under load as discussed in this blog post: >>>> http://boundarydevices.com/i-mx6-ethernet/ >>>> >>>> And in this patch: >>>> >>>> https://github.com/boundarydevices/linux-imx6/commit/38d622938f1352a6550a5e38c624b46b6929439f >>>> >>>> Without it, network receive performance can get really bad under >>>> load. >>> >>> >>> Very nice! However you might like to simply sync the patch for your >>> boundary tree (the patch compares FSL branch with Bondary ones) so >>> this would be included. Or this should be applied in all boards? >>> >> >> Well... I was thinking that I'd just push this one, since it has a much >> bigger impact than the patches we made to flow control and error >> handling. >> >> I think I was a bit mistaken though. I didn't catch that this line was >> itself in a patch file: >> +# CONFIG_FEC_NAPI is not set >> >> I also didn't catch and don't quite understand how the defconfig file >> is applied in the build process. Is 'nitrogen6x_defconfig' even used? >> >> I don't see CONFIG_FEC in the defconfig. Does that file somehow get >> applied on top of a base configuration to apply Yocto specifics? > > The defconfig, at linux-imx-<version> is generated using the machine > config and calling make savedefconfig; so it should be the shorter > version and produce same .config as result of dependencies. > > So the build system copy the defconfig onto .config, run "yes 'n' | > make oldconfig" and build the kernel. > > You can sync the 12.09.01 branch and update the patch at: > > http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/recipes-kernel/linux/linux-imx-3.0.35/imx6qsabrelite/sync-boundary-changes.patch > > and updated: > > http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/recipes-kernel/linux/linux-imx-3.0.35/imx6qsabrelite/defconfig > > As I did the trick of using sabrelite as fallback to nitrogen board > (check https://github.com/Freescale/meta-fsl-arm-extra/blob/master/conf/machine/nitrogen6x.conf#L6) > it will use those, except a nitrogen specific one is provided. I did > it to avoid duplicating things and easy maintenance. > I think I understand this, but will need to walk the exercise to be sure and it will likely take a couple of days before I can get to it. >> There are some things in our boundary-L3.0.35_12.09.01_GA tree that >> I was hoping to clean up before submitting >> >> In particular, we set things up to allow a single image to boot on >> Quad->Solo that the Freescale team didn't like, so we'll probably > > It'd be nice indeed. Why they didn't like it? > This is the tricky bit, with a double-include of a header: https://github.com/boundarydevices/linux-imx6/commit/a11553187650003a3d88b187fd175b963b2fa957#L0R123 It's origin is in the observation that the board defines the pins and pads, which are the same regardless of the CPU, but the addresses are different. By including it twice, you get two copies of the static mux-config arrays: https://github.com/boundarydevices/linux-imx6/blob/boundary-L3.0.35_12.09.01_GA/arch/arm/mach-mx6/pads-mx6_sabrelite.h#L49 Then one of them is selected at run-time based on the CPU: https://github.com/boundarydevices/linux-imx6/commit/a11553187650003a3d88b187fd175b963b2fa957#L0R141 >> revert it as we migrate to the 2012-10 branch, which will take a >> couple of weeks. > > So revert back to several images depending on SoC model? > Yeah. That's certainly allows more optimization, since we can remove stuff like SATA, which only applies on 6Quad and 6Dual. > Regards, > > -- > Otavio Salvador O.S. Systems > E-mail: otavio@ossystems.com.br http://www.ossystems.com.br > Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br > ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2012-12-21 20:06 UTC | newest] Thread overview: 19+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-12-21 16:25 [meta-fsl-arm][PATCH 0/3] SabreLite updates Gary Thomas 2012-12-21 16:25 ` [meta-fsl-arm][PATCH 1/3] xf86-video-imxfb-vivante: Update for new X server API Gary Thomas 2012-12-21 16:46 ` Daiane Angolini 2012-12-21 17:25 ` Andrei Gherzan 2012-12-21 16:25 ` [meta-fsl-arm][PATCH 2/3] xserver-xf86-config: SabreLite configuration Gary Thomas 2012-12-21 16:50 ` Daiane Angolini 2012-12-21 16:52 ` Gary Thomas 2012-12-21 17:16 ` Otavio Salvador 2012-12-21 17:22 ` Gary Thomas 2012-12-21 17:26 ` Otavio Salvador 2012-12-21 16:25 ` [meta-fsl-arm][PATCH 3/3] imx6qsabrelite/defconfig: Enable devtmpfs Gary Thomas 2012-12-21 16:51 ` Daiane Angolini 2012-12-21 17:25 ` Andrei Gherzan 2012-12-21 17:19 ` Otavio Salvador 2012-12-21 18:37 ` Eric Nelson 2012-12-21 18:41 ` Otavio Salvador 2012-12-21 19:12 ` Eric Nelson 2012-12-21 19:24 ` Otavio Salvador 2012-12-21 20:06 ` Eric Nelson
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.