Re: [linux-yocto] kernel-yocto: validate_branches questions

2014-02-18 Thread Bruce Ashfield

  
  
On 14-02-17 06:52 PM, Moore, Tysen
  wrote:


  
  
  I have some questions regarding
creating a recipe for a kernel build. Specifically I am having
troubles with the validate_branches (kernel-yocto.bbclass). I
have the following set:
KBRANCH = "axsb/axsb_dra7xx-evm_6_03_00_01.XSE"
SRCREV_machine = "717bdd79798d9fa41bc8bd2d089b17ebb52819cd"
SRCREV = "717bdd79798d9fa41bc8bd2d089b17ebb52819cd"
KMETA is not set. 
  


Sorry for the slower than normal reply, yesterday was a holiday
here.

Quick question, is this on master ? I apologize if this is covered,
but 
my scan missed it!


  

The output for the verify_branches indicates that two different
branches have the same commit (717bdd797)--my KBRANCH and
another (fred/xsrapid-demo-glsdk-6.0.3.0). However only the one
I specified in KBRANCH contains the defconfig that I need, the
other does not--neither does master. The other potential issue
is that the other branch head is not 717bdd797. When looking at
the code I can see the file exists from the normal fetch and
unpack. It is when the validate_branches does the "git checkout
-q master" that it checks out master and the file is obviously
gone. The next for loop checks for the head commit of the
braches containing my commit and if not head it switches to
them. This is the part that is especially troublesome. It
switches to the wrong branch and then since I have no KMETA
configured exists out. My questions are:
1. Why does it not just switch to the KBRANCH I specified
originally? Isn't that the point of KBRANCH to ensure the
correct branch is used.
  


For the most part, the point of KBRANCH is to keep the fetcher happy.
It
needs a branch and SRCREV to ensure that what you want to build is
in
the repository. Note that do_validate_branches pre-dates the fetcher
changes
that help enforce what it was imposing on the kernel tree, so I have
a mostly
re-written version of the routine that will be submitted to master
in the not
to distant future.

As for what you build, KBRANCH is a hint. What you actually build is
described
by the BSP .scc files (auto-generated or not). Typically the two
sources of
input agree, if they don't, a warning is generated. 

As the kernel patches, configuration and features are processed, the
tree is
manipulated, that manipulation can involve git merges, or other
operations
that require branch changes, so immediately checking it out isn't
done .. since
the branches can change before landing on what is built.

do_validate_branches has had a few revisions over time to deal with
different
workflows and bugs, so what you see represents fixes for various
issues
that may arise .. which of course means, that I modify it very
carefully to 
not cause regressions :)

So what happens in that loop you are having trouble with, is that
the SRCREV
as specified represents the head commit of what should be built ..
or patched ..
and since the tree can be manipulated as part of the build process,
do_validate_branches
looks for that commit in the tree, and resets any branches that
contain the
commit .. to that commit, so if any one of those branches is used to
build, you 
will start from the SRCREV as specific in the recipe, that's your
consistent baseline.


  
2. What is the difference between SRCREV and SRCREV_machine?
  


Just the standard bitbake variable overrides. SRCREV_machine is the
machine specific override for the SRCREV.


  
3. If I comment out the KMETA check resolves the problem. The
code that follows reverts back to the KBRANCH as I would hope.
Is this the root of my problem? If so, what is the use for
KMETA? (Can't find much of anything online) In much of the bb
code it can be unset and is assumed "meta". While, this routine
may seem to expect something.
  


Which kmeta check ? If you don't actually have a meta branch in your
kernel tree, and you've left it empty the validation should return
early
and not process anything.

KMETA is for trees that have kernel configuration and BSP
descriptions
stored within the tree itself .. that's the meta data, and it is
contained
in the branch pointed to by KMETA.


  

Any help or insight would be MUCH appreciated.
  


We may have a bug .. so let's see what we can figure out :)

Bruce


  

Tysen

LOG BELOW: (with my debug output: "FILE 

[linux-yocto] [PATCH 00/18] Re-submit upgrades to the lsi 3.10 axxia

2014-02-18 Thread Charlie Paul
The patch is the resubmittal of the upgrades to AXXIA, specifically in the arm 
and powerpc realm

Anders Berg (4):
  arm: mmu: Fix truncated 40-bit physaddr (LPAE)
  axxia: Fixed earlyprintk
  arm/mach-axxia: Same build for HW and simlation.
  i2c-axxia: Support I2C_M_RECV_LEN

Charlie Paul (2):
  arch/arm/mach-axxia: fixed the split print statement
  arm: mmu: cleanup as per checkpatch

David Mercado (1):
  LSI AXM55XX: Add PMU support

John Jacques (5):
  arch/arm/mach-axxia: Added Clocks to the Device Tree for AXM55xx
Emulation
  arch/arm/mach-axxia: Support for DDR Retention Resets
  arch/powerpc: backport of mpic
  arch/arm/axxia: Updated Device Trees for LSI Axxia Simulation
  axxia: Remove Wrapper Functions

SangeethaRao (6):
  driver/usb/host: ehci controller halt function
  arch/powerpc: Checking in correct USB entries to ACP3421 DTS
  arch/powerpc: Added PCIe driver support for ACP35xx
  arch/powerpc: Replace printk with pr_ functions
  arm/mach-axxia: Updated PCIe driver to set PCIe BASE_ADDR1 register
  arch/arm/mach-axxia: added support for ncr_read/ncr_write() to access
PCIe/SRIO SerDes Config in 0x115 node

 arch/arm/Kconfig.debug |4 +
 arch/arm/Makefile  |3 -
 arch/arm/boot/dts/axm55xx.dts  |   11 +
 arch/arm/boot/dts/axm55xxemu.dts   |   17 +
 arch/arm/boot/dts/axm55xxsim.dts   |  104 +
 arch/arm/boot/dts/axm55xxsim16.dts |  459 ++
 arch/arm/include/asm/spinlock.h|5 +-
 arch/arm/kernel/perf_event_v7.c|   21 +-
 arch/arm/mach-axxia/Kconfig|3 -
 arch/arm/mach-axxia/Makefile   |2 +-
 arch/arm/mach-axxia/axxia-gic.c|   25 +-
 arch/arm/mach-axxia/axxia.c|   74 +--
 arch/arm/mach-axxia/axxia.h|4 +-
 arch/arm/mach-axxia/clock.c|  181 +++
 arch/arm/mach-axxia/ddr_retention.c|  290 +++-
 arch/arm/mach-axxia/include/mach/debug-macro.S |   24 +-
 arch/arm/mach-axxia/include/mach/hardware.h|   25 +-
 arch/arm/mach-axxia/include/mach/ncr.h |   44 ++
 arch/arm/mach-axxia/ncr.c  |  597 
 arch/arm/mach-axxia/pci.c  |   13 +-
 arch/arm/mach-axxia/platsmp.c  |  178 ++-
 arch/arm/mach-axxia/wrappers.c |  174 ---
 arch/arm/mm/mmu.c  |  108 ++---
 arch/powerpc/boot/dts/acp342x.dts  |   33 +-
 arch/powerpc/boot/dts/acp35xx.dts  |4 +-
 arch/powerpc/sysdev/Makefile   |2 -
 arch/powerpc/sysdev/lsi_acp_wrappers.c |  132 --
 arch/powerpc/sysdev/lsi_pci.c  |  125 ++---
 arch/powerpc/sysdev/mpic.c |  148 +++---
 drivers/i2c/busses/i2c-axxia.c |  220 ++---
 drivers/misc/Kconfig   |2 +-
 drivers/misc/lsi-smmon.c   |  364 +++
 drivers/net/ethernet/lsi/lsi_acp_net.c |9 +-
 drivers/usb/host/ehci-ci13612.c|   57 ++-
 34 files changed, 2124 insertions(+), 1338 deletions(-)
 create mode 100644 arch/arm/boot/dts/axm55xxsim16.dts
 create mode 100644 arch/arm/mach-axxia/include/mach/ncr.h
 create mode 100644 arch/arm/mach-axxia/ncr.c
 delete mode 100644 arch/arm/mach-axxia/wrappers.c
 delete mode 100644 arch/powerpc/sysdev/lsi_acp_wrappers.c

-- 
1.7.9.5

___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


[linux-yocto] [PATCH 02/18] driver/usb/host: ehci controller halt function

2014-02-18 Thread Charlie Paul
From: SangeethaRao sangeetha@lsi.com

 Adding a new ehci halt function that
 doesn't use spinlocks to be called during startup to
 just halt the EHCI controller

 incorrect ehci_regs struct member was being used in USB driver

Signed-off-by: SangeethaRao sangeetha@lsi.com
---
 drivers/usb/host/ehci-ci13612.c |   57 +++
 1 file changed, 40 insertions(+), 17 deletions(-)

diff --git a/drivers/usb/host/ehci-ci13612.c b/drivers/usb/host/ehci-ci13612.c
index b39dc0e..b20ec40 100644
--- a/drivers/usb/host/ehci-ci13612.c
+++ b/drivers/usb/host/ehci-ci13612.c
@@ -32,11 +32,13 @@
 #include ehci-ci13612.h
 
 
+static int ci13612_ehci_halt(struct ehci_hcd *ehci);
+
 #ifdef CONFIG_LSI_USB_SW_WORKAROUND
 static void ci13612_usb_setup(struct usb_hcd *hcd)
 {
int USB_TXFIFOTHRES, VUSB_HS_TX_BURST;
-   u32 device_mode;
+   u32 devicemode;
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
u32 txfulltuning = 0;
 
@@ -55,18 +57,18 @@ static void ci13612_usb_setup(struct usb_hcd *hcd)
 * Unspecified Length Bursts by setting SBUSCFG to 0x0, or use stream
 * disable mode by setting USBMODE.SDIS to 0x1.
 */
-   device_mode = ehci_readl(ehci, hcd-regs + 0x1A8);
+   devicemode = ehci_readl(ehci, hcd-regs + 0x1A8);
 
-   if ((device_mode  0x3) == 0x2) {
+   if ((devicemode  0x3) == 0x2) {
/* device mode */
writel(0x0, hcd-regs + 0x90);
-   } else if ((device_mode  0x3) == 0x3) {
+   } else if ((devicemode  0x3) == 0x3) {
/* host mode */
writel(0x6, hcd-regs + 0x90);
}
 
-   pr_info(ehci-ci13612 (ci13612_usb_setup): VUSB_HS_TX_BURST = 0x%x,
-   USB_TXFIFOTHRES = 0x%x\n, VUSB_HS_TX_BURST, USB_TXFIFOTHRES);
+   pr_err(ehci-ci13612 (ci13612_usb_setup): VUSB_HS_TX_BURST = 
0x%x,USB_TXFIFOTHRES = 0x%x\n,
+   VUSB_HS_TX_BURST, USB_TXFIFOTHRES);
return;
 }
 #endif
@@ -102,7 +104,7 @@ static int ci13612_ehci_init(struct usb_hcd *hcd)
ehci-sbrn = 0x20;
 
/* Reset is only allowed on a stopped controller */
-   ehci_halt(ehci);
+   ci13612_ehci_halt(ehci);
 
/* reset controller */
ehci_reset(ehci);
@@ -136,8 +138,7 @@ ci13612_fixup_usbcmd_rs(struct ehci_hcd *ehci)
port_status = ehci_readl(ehci, ehci-regs-port_status[0]);
pr_info(ehci-ci13612: port_status = 0x%x\n, port_status);
if (port_status  0x100) {
-   pr_err(ehci-ci13612: USB port is in reset status, 
-  not able to change HC status to run\n);
+   pr_err(ehci-ci13612: USB port is in reset status, not able to 
change HC status to run\n);
return -EFAULT;
}
return 0;
@@ -169,7 +170,7 @@ ci13612_fixup_txpburst(struct ehci_hcd *ehci)
ehci_writel(ehci, burst_size, ehci-regs-reserved1[1]);
 }
 #else
-#define ci13612_fixup_txpburst(ehci) do { (void)ehci; } while (0)
+#define ci13612_fixup_txpburst(ehci) do { (void)ehci; } while(0)
 #endif
 
 static int ci13612_ehci_run(struct usb_hcd *hcd)
@@ -182,8 +183,11 @@ static int ci13612_ehci_run(struct usb_hcd *hcd)
if (retval)
return retval;
 
+
+#ifndef CONFIG_LSI_USB_SW_WORKAROUND
/* Setup AMBA interface to force INCR16 busts when possible */
writel(3, USB_SBUSCFG);
+#endif
 
retval = ehci_run(hcd);
if (retval)
@@ -191,10 +195,12 @@ static int ci13612_ehci_run(struct usb_hcd *hcd)
 
ci13612_fixup_txpburst(ehci);
 
+#ifndef CONFIG_LSI_USB_SW_WORKAROUND
/* Set ITC (bits [23:16]) to zero for interrupt on every micro-frame */
tmp = ehci_readl(ehci, ehci-regs-command);
tmp = 0x;
ehci_writel(ehci, tmp  0x, ehci-regs-command);
+#endif
 
return retval;
 }
@@ -227,9 +233,7 @@ static int ci13612_ehci_probe(struct platform_device *pdev)
 {
struct device_node *np = pdev-dev.of_node;
struct usb_hcd *hcd;
-#ifdef CONFIG_ARM
void __iomem *gpreg_base;
-#endif
int irq;
int retval;
struct resource *res;
@@ -239,6 +243,7 @@ static int ci13612_ehci_probe(struct platform_device *pdev)
 
irq = platform_get_irq(pdev, 0);
if (irq  0) {
+   dev_dbg(pdev-dev, error getting irq number\n);
retval = irq;
goto fail_create_hcd;
}
@@ -256,12 +261,15 @@ static int ci13612_ehci_probe(struct platform_device 
*pdev)
return -ENODEV;
}
 
+
+#ifndef CONFIG_LSI_USB_SW_WORKAROUND
/* Device using 32-bit addressing */
pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
pdev-dev.dma_mask = pdev-dev.coherent_dma_mask;
+#endif
 
-   hcd = usb_create_hcd(ci13612_hc_driver, pdev-dev,
-dev_name(pdev-dev));
+   hcd = usb_create_hcd(ci13612_hc_driver,
+   pdev-dev, dev_name(pdev-dev));
if 

[linux-yocto] [PATCH 01/18] arch/arm/mach-axxia: Added Clocks to the Device Tree for AXM55xx Emulation

2014-02-18 Thread Charlie Paul
From: John Jacques john.jacq...@lsi.com

Signed-off-by: John Jacques john.jacq...@lsi.com
---
 arch/arm/boot/dts/axm55xxemu.dts |   17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/axm55xxemu.dts b/arch/arm/boot/dts/axm55xxemu.dts
index 99d7a70..d95af00 100644
--- a/arch/arm/boot/dts/axm55xxemu.dts
+++ b/arch/arm/boot/dts/axm55xxemu.dts
@@ -93,6 +93,23 @@
*/
};
 
+   clocks {
+   #address-cells = 1;
+   #size-cells = 0;
+
+   cpu {
+   frequency = 0; /* Filled in by the boot loader. */
+   };
+
+   peripheral {
+   frequency = 0; /* Filled in by the boot loader. */
+   };
+
+   emmc {
+   frequency = 0; /* Filled in by the boot loader. */
+   };
+   };
+
memory@ {
device_type = memory;
reg = 0 0x 0 0x1000;
-- 
1.7.9.5

___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


[linux-yocto] [PATCH 04/18] arch/powerpc: Added PCIe driver support for ACP35xx

2014-02-18 Thread Charlie Paul
From: SangeethaRao sangeetha@lsi.com

Signed-off-by: SangeethaRao sangeetha@lsi.com
---
 arch/powerpc/boot/dts/acp35xx.dts |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/boot/dts/acp35xx.dts 
b/arch/powerpc/boot/dts/acp35xx.dts
index 83a4c90..a6686fd 100644
--- a/arch/powerpc/boot/dts/acp35xx.dts
+++ b/arch/powerpc/boot/dts/acp35xx.dts
@@ -393,8 +393,8 @@
  0 0 4 MPIC 55 2
 ;
 };
-+  SRIO0: srio0 {
-+  compatible = acp,rapidio-delta;
+   SRIO0: srio0 {
+   compatible = acp,rapidio-delta;
 device_type = rapidio;
enabled = 0;
#size = 0;/* 0 = (256, small system)
-- 
1.7.9.5

___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


[linux-yocto] [PATCH 03/18] arch/powerpc: Checking in correct USB entries to ACP3421 DTS

2014-02-18 Thread Charlie Paul
From: SangeethaRao sangeetha@lsi.com

Signed-off-by: SangeethaRao sangeetha@lsi.com
---
 arch/powerpc/boot/dts/acp342x.dts |   33 +
 1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/arch/powerpc/boot/dts/acp342x.dts 
b/arch/powerpc/boot/dts/acp342x.dts
index b851788..f5cf3a6 100644
--- a/arch/powerpc/boot/dts/acp342x.dts
+++ b/arch/powerpc/boot/dts/acp342x.dts
@@ -90,64 +90,65 @@
 clock-frequency = 0; // Filled in by zImage
 UART0: serial@00404000 {
 device_type = serial;
-compatible = acp-uart0;
+compatible = lsi,acp-uart0;
 enabled = 1;
 reg = 0x00404000 0x1000;
 clock-reg = 0x00408040 0x20;
 clock-frequency = 0xbebc200;
 current-speed = 9600;
 interrupt-parent = MPIC;
-interrupts = 22 4;
+interrupts = 22;
 };
 UART1: serial@00405000 {
 device_type = serial;
-compatible = acp-uart1;
+compatible = lsi,acp-uart1;
 enabled = 0;
 reg = 0x00405000 0x1000;
 clock-reg = 0x00408060 0x20;
 clock-frequency = 2;
 current-speed = 9600;
 interrupt-parent = MPIC;
-interrupts = 23 4;
+interrupts = 23;
 };
 USB0: usb@004a4000 {
 device_type = usb;
-compatible = acp-usb;
-enabled = 0;
-reg = 0x004a4000 0x0002;
+compatible = lsi,acp-usb;
+enabled = 1;
+reg = 0x20 0x004A 0x0 002,
+   0x20 0x0040C000 0x0 0001000;
 interrupt-parent = MPIC;
-interrupts = 31 4;
+interrupts = 31;
 };
 I2C: i2c@00403000 {
-compatible = acp-i2c;
+compatible = lsi,acp-i2c;
 enabled = 0;
 reg = 0x00403000 0x1000;
 interrupt-parent = MPIC;
-interrupts = 21 4;
+interrupts = 21;
 };
 SSP: ssp@00402000 {
-compatible = acp-ssp;
+compatible = arm,acp-ssp;
 enabled = 0;
 reg = 0x00402000 0x1000;
 interrupt-parent = MPIC;
-interrupts = 20 4;
+interrupts = 20;
 };
 NAND: nand@0044 {
 device_type = nand;
-compatible = acp-nand;
+compatible = lsi,acp-nand;
 enabled = 1;
 reg = 0x0044 0x2
0x0040c000 0x1000;
 };
 FEMAC: femac@0048 {
 device_type = network;
-compatible = acp-femac;
+compatible = lsi,acp-femac;
 enabled = 1;
 reg = 0x0048 0x1000
0x00481000 0x1000
0x00482000 0x1000;
 interrupt-parent = MPIC;
-interrupts = 33 4;
+interrupts = 33;
 mdio-reg = 0x00409000 0x1000;
 // The following will get filled in by
 // the boot loader.
@@ -284,7 +285,7 @@
 };
 
 rio0: rapidio@f002 {
-compatible = acp,rapidio-delta;
+compatible = lsi,rapidio-delta;
 device_type = rapidio;
 enabled = 0;
 #size = 0;/* 0 = (256, small system)
-- 

[linux-yocto] [PATCH 09/18] arm/mach-axxia: Updated PCIe driver to set PCIe BASE_ADDR1 register

2014-02-18 Thread Charlie Paul
From: SangeethaRao sangeetha@lsi.com

Updated PCIe driver to set PCIe BASE_ADDR1 register to 0x0 without
which PCIe inbound access wasn't working and we were seeing several
suprious PEI interrupts including BAR mismatch interrupt.

Signed-off-by: SangeethaRao sangeetha@lsi.com
Signed-off-by: Paul Butler paul.but...@windriver.com
---
 arch/arm/mach-axxia/pci.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-axxia/pci.c b/arch/arm/mach-axxia/pci.c
index bb52908..b45cae4 100644
--- a/arch/arm/mach-axxia/pci.c
+++ b/arch/arm/mach-axxia/pci.c
@@ -661,20 +661,23 @@ static int axxia_pcie_setup(int portno, struct 
pci_sys_data *sys)
 
/* Configure the inbound window size */
inbound_size = (u32) resource_size(port-inbound);
-   writel(inbound_size, port-regs + PCIE_RC_BAR0_SIZE);
+   writel(~(inbound_size-1), port-regs + PCIE_RC_BAR0_SIZE);
 
/* Verify BAR0 size */
{
u32 bar0_size;
writel(~0, port-regs + PCI_BASE_ADDRESS_0);
bar0_size = readl(port-regs + PCI_BASE_ADDRESS_0);
-   if ((bar0_size  ~0xf) != inbound_size)
+   if ((bar0_size  ~0xf) != ~(inbound_size-1))
pr_err(PCIE%d: Config BAR0 failed\n, port-index);
}
 
/* Set the BASE0 address to start of PCIe base */
writel(port-pci_bar, port-regs + PCI_BASE_ADDRESS_0);
 
+   /* Set the BASE1 address to 0x0 */
+   writel(0x0, port-regs + PCI_BASE_ADDRESS_1);
+
/* Setup TPAGE registers for inbound mapping
 *
 * We set the MSB of each TPAGE to select 128-bit AXI access. For the
-- 
1.7.9.5

___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


[linux-yocto] [PATCH 12/18] arm: mmu: Fix truncated 40-bit physaddr (LPAE)

2014-02-18 Thread Charlie Paul
From: Anders Berg anders.b...@lsi.com

Wrong type for parameter 'phys' caused adress to be truncated to 32-bits,
causing iotable_init() to produce wrong MMU mappings on LPAE system.

Signed-off-by: Anders Berg anders.b...@lsi.com
---
 arch/arm/mm/mmu.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index daf336f..253f85e 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -675,7 +675,7 @@ static void __init alloc_init_pmd(pud_t *pud, unsigned long 
addr,
 }
 
 static void __init alloc_init_pud(pgd_t *pgd, unsigned long addr,
-   unsigned long end, unsigned long phys, const struct mem_type *type)
+   unsigned long end, phys_addr_t phys, const struct mem_type 
*type)
 {
pud_t *pud = pud_offset(pgd, addr);
unsigned long next;
-- 
1.7.9.5

___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


[linux-yocto] [PATCH 06/18] LSI AXM55XX: Add PMU support

2014-02-18 Thread Charlie Paul
From: David Mercado david.merc...@windriver.com

This patch adds PMU support to the Axxia AXM55xx platform. Note that
on this platform, all PMU IRQ lines are OR'ed together into a single
IRQ, and therefore, this implementation uses a rotating IRQ affinity
scheme to deal with it.

Signed-off-by: David Mercado david.merc...@windriver.com
---
 arch/arm/kernel/perf_event_v7.c |   21 +++--
 arch/arm/mach-axxia/axxia-gic.c |   25 +++--
 arch/arm/mach-axxia/axxia.c |2 +-
 3 files changed, 35 insertions(+), 13 deletions(-)

diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
index 039cffb..13e1a5c 100644
--- a/arch/arm/kernel/perf_event_v7.c
+++ b/arch/arm/kernel/perf_event_v7.c
@@ -93,6 +93,7 @@ enum armv7_a5_perf_types {
 
 /* ARMv7 Cortex-A15 specific event types */
 enum armv7_a15_perf_types {
+   ARMV7_A15_PERFCTR_CPU_CYCLES= 0x11,
ARMV7_A15_PERFCTR_L1_DCACHE_ACCESS_READ = 0x40,
ARMV7_A15_PERFCTR_L1_DCACHE_ACCESS_WRITE= 0x41,
ARMV7_A15_PERFCTR_L1_DCACHE_REFILL_READ = 0x42,
@@ -487,7 +488,7 @@ static const unsigned 
armv7_a5_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
  * Cortex-A15 HW events mapping
  */
 static const unsigned armv7_a15_perf_map[PERF_COUNT_HW_MAX] = {
-   [PERF_COUNT_HW_CPU_CYCLES]  = ARMV7_PERFCTR_CPU_CYCLES,
+   [PERF_COUNT_HW_CPU_CYCLES]  = ARMV7_A15_PERFCTR_CPU_CYCLES,
[PERF_COUNT_HW_INSTRUCTIONS]= ARMV7_PERFCTR_INSTR_EXECUTED,
[PERF_COUNT_HW_CACHE_REFERENCES]= 
ARMV7_PERFCTR_L1_DCACHE_ACCESS,
[PERF_COUNT_HW_CACHE_MISSES]= 
ARMV7_PERFCTR_L1_DCACHE_REFILL,
@@ -917,34 +918,34 @@ static void armv7_pmnc_dump_regs(struct arm_pmu *cpu_pmu)
u32 val;
unsigned int cnt;
 
-   printk(KERN_INFO PMNC registers dump:\n);
+   pr_info(PMNC registers dump:\n);
 
asm volatile(mrc p15, 0, %0, c9, c12, 0 : =r (val));
-   printk(KERN_INFO PMNC  =0x%08x\n, val);
+   pr_info(PMNC  =0x%08x\n, val);
 
asm volatile(mrc p15, 0, %0, c9, c12, 1 : =r (val));
-   printk(KERN_INFO CNTENS=0x%08x\n, val);
+   pr_info(CNTENS=0x%08x\n, val);
 
asm volatile(mrc p15, 0, %0, c9, c14, 1 : =r (val));
-   printk(KERN_INFO INTENS=0x%08x\n, val);
+   pr_info(INTENS=0x%08x\n, val);
 
asm volatile(mrc p15, 0, %0, c9, c12, 3 : =r (val));
-   printk(KERN_INFO FLAGS =0x%08x\n, val);
+   pr_info(FLAGS =0x%08x\n, val);
 
asm volatile(mrc p15, 0, %0, c9, c12, 5 : =r (val));
-   printk(KERN_INFO SELECT=0x%08x\n, val);
+   pr_info(SELECT=0x%08x\n, val);
 
asm volatile(mrc p15, 0, %0, c9, c13, 0 : =r (val));
-   printk(KERN_INFO CCNT  =0x%08x\n, val);
+   pr_info(CCNT  =0x%08x\n, val);
 
for (cnt = ARMV7_IDX_COUNTER0;
cnt = ARMV7_IDX_COUNTER_LAST(cpu_pmu); cnt++) {
armv7_pmnc_select_counter(cnt);
asm volatile(mrc p15, 0, %0, c9, c13, 2 : =r (val));
-   printk(KERN_INFO CNT[%d] count =0x%08x\n,
+   pr_info(CNT[%d] count =0x%08x\n,
ARMV7_IDX_TO_COUNTER(cnt), val);
asm volatile(mrc p15, 0, %0, c9, c13, 1 : =r (val));
-   printk(KERN_INFO CNT[%d] evtsel=0x%08x\n,
+   pr_info(CNT[%d] evtsel=0x%08x\n,
ARMV7_IDX_TO_COUNTER(cnt), val);
}
 }
diff --git a/arch/arm/mach-axxia/axxia-gic.c b/arch/arm/mach-axxia/axxia-gic.c
index d2edcef..5aefa42 100644
--- a/arch/arm/mach-axxia/axxia-gic.c
+++ b/arch/arm/mach-axxia/axxia-gic.c
@@ -283,6 +283,10 @@ static void gic_mask_irq(struct irq_data *d)
if ((irqid = IPI0_CPU0)  (irqid  MAX_AXM_IPI_NUM))
return;
 
+   /* Don't mess with the PMU IRQ either. */
+   if (irqid == IRQ_PMU)
+   return;
+
/* Deal with PPI interrupts directly. */
if ((irqid  16)  (irqid  32)) {
_gic_mask_irq(d);
@@ -327,6 +331,10 @@ static void gic_unmask_irq(struct irq_data *d)
if ((irqid = IPI0_CPU0)  (irqid  MAX_AXM_IPI_NUM))
return;
 
+   /* Don't mess with the PMU IRQ either. */
+   if (irqid == IRQ_PMU)
+   return;
+
/* Deal with PPI interrupts directly. */
if ((irqid  15)  (irqid  32)) {
_gic_unmask_irq(d);
@@ -565,8 +573,8 @@ static int gic_set_affinity(struct irq_data *d,
 * different than the prior cluster, remove the IRQ affinity
 * on the old cluster.
 */
-   if ((cpu_logical_map(cpu) / CORES_PER_CLUSTER) !=
-   (irq_cpuid[irqid] / CORES_PER_CLUSTER)) {
+   if ((irqid != IRQ_PMU)  ((cpu_logical_map(cpu) / CORES_PER_CLUSTER) !=
+   (irq_cpuid[irqid] / CORES_PER_CLUSTER))) {
/*
 * If old cpu assignment falls within the same cluster as
 * the cpu we're 

[linux-yocto] [PATCH 10/18] arch/powerpc: backport of mpic

2014-02-18 Thread Charlie Paul
From: John Jacques john.jacq...@lsi.com

Backport of 32dda05f4ec2b854b594bd91590c46c5197d77e1

Otherwise, we get a debug traceback due to the use of
smp_processor_id() (or get_paca()) inside hard_smp_processor_id().
mpic_host_map() is just looking for a default CPU, so it doesn't matter
if we migrate after getting the CPU ID.

This is signed off by Scott Wood scottw...@freescale.com

Signed-off-by: John Jacques john.jacq...@lsi.com
---
 arch/powerpc/sysdev/mpic.c |  148 
 1 file changed, 81 insertions(+), 67 deletions(-)

diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 3cc2f91..f9a26d8 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -142,7 +142,7 @@ static u32 mpic_infos[][MPIC_IDX_END] = {
},
 };
 
-#define MPIC_INFO(name) mpic-hw_set[MPIC_IDX_##name]
+#define MPIC_INFO(name) (mpic-hw_set[MPIC_IDX_##name])
 
 #else /* CONFIG_MPIC_WEIRD */
 
@@ -166,10 +166,10 @@ static inline unsigned int mpic_processor_id(struct mpic 
*mpic)
 
 
 static inline u32 _mpic_read(enum mpic_reg_type type,
-struct mpic_reg_bank *rb,
-unsigned int reg)
+   struct mpic_reg_bank *rb,
+   unsigned int reg)
 {
-   switch(type) {
+   switch (type) {
 #ifdef CONFIG_PPC_DCR
case mpic_access_dcr:
return dcr_read(rb-dhost, reg);
@@ -183,10 +183,10 @@ static inline u32 _mpic_read(enum mpic_reg_type type,
 }
 
 static inline void _mpic_write(enum mpic_reg_type type,
-  struct mpic_reg_bank *rb,
-  unsigned int reg, u32 value)
+   struct mpic_reg_bank *rb,
+   unsigned int reg, u32 value)
 {
-   switch(type) {
+   switch (type) {
 #ifdef CONFIG_PPC_DCR
case mpic_access_dcr:
dcr_write(rb-dhost, reg, value);
@@ -213,7 +213,8 @@ static inline u32 _mpic_ipi_read(struct mpic *mpic, 
unsigned int ipi)
return _mpic_read(type, mpic-gregs, offset);
 }
 
-static inline void _mpic_ipi_write(struct mpic *mpic, unsigned int ipi, u32 
value)
+static inline void _mpic_ipi_write(struct mpic *mpic,
+   unsigned int ipi, u32 value)
 {
unsigned int offset = MPIC_INFO(GREG_IPI_VECTOR_PRI_0) +
  (ipi * MPIC_INFO(GREG_IPI_STRIDE));
@@ -250,14 +251,16 @@ static inline u32 _mpic_cpu_read(struct mpic *mpic, 
unsigned int reg)
return _mpic_read(mpic-reg_type, mpic-cpuregs[cpu], reg);
 }
 
-static inline void _mpic_cpu_write(struct mpic *mpic, unsigned int reg, u32 
value)
+static inline void _mpic_cpu_write(struct mpic *mpic,
+   unsigned int reg, u32 value)
 {
unsigned int cpu = mpic_processor_id(mpic);
 
_mpic_write(mpic-reg_type, mpic-cpuregs[cpu], reg, value);
 }
 
-static inline u32 _mpic_irq_read(struct mpic *mpic, unsigned int src_no, 
unsigned int reg)
+static inline u32 _mpic_irq_read(struct mpic *mpic,
+   unsigned int src_no, unsigned int reg)
 {
unsigned intisu = src_no  mpic-isu_shift;
unsigned intidx = src_no  mpic-isu_mask;
@@ -289,16 +292,16 @@ static inline void _mpic_irq_write(struct mpic *mpic, 
unsigned int src_no,
 #endif
 }
 
-#define mpic_read(b,r) _mpic_read(mpic-reg_type,(b),(r))
-#define mpic_write(b,r,v)  _mpic_write(mpic-reg_type,(b),(r),(v))
-#define mpic_ipi_read(i)   _mpic_ipi_read(mpic,(i))
-#define mpic_ipi_write(i,v)_mpic_ipi_write(mpic,(i),(v))
-#define mpic_tm_read(i)_mpic_tm_read(mpic,(i))
-#define mpic_tm_write(i,v) _mpic_tm_write(mpic,(i),(v))
-#define mpic_cpu_read(i)   _mpic_cpu_read(mpic,(i))
-#define mpic_cpu_write(i,v)_mpic_cpu_write(mpic,(i),(v))
-#define mpic_irq_read(s,r) _mpic_irq_read(mpic,(s),(r))
-#define mpic_irq_write(s,r,v)  _mpic_irq_write(mpic,(s),(r),(v))
+#define mpic_read(b, r)_mpic_read(mpic-reg_type, (b), (r))
+#define mpic_write(b, r, v)_mpic_write(mpic-reg_type, (b), (r), (v))
+#define mpic_ipi_read(i)   _mpic_ipi_read(mpic, (i))
+#define mpic_ipi_write(i, v)   _mpic_ipi_write(mpic, (i), (v))
+#define mpic_tm_read(i)_mpic_tm_read(mpic, (i))
+#define mpic_tm_write(i, v)_mpic_tm_write(mpic, (i), (v))
+#define mpic_cpu_read(i)   _mpic_cpu_read(mpic, (i))
+#define mpic_cpu_write(i, v)   _mpic_cpu_write(mpic, (i), (v))
+#define mpic_irq_read(s, r)_mpic_irq_read(mpic, (s), (r))
+#define mpic_irq_write(s, r, v)_mpic_irq_write(mpic, (s), (r), (v))
 
 
 /*
@@ -333,7 +336,7 @@ static inline void mpic_map(struct mpic *mpic,
_mpic_map_mmio(mpic, phys_addr, rb, offset, size);
 }
 #else /* CONFIG_PPC_DCR */
-#define mpic_map(m,p,b,o,s)_mpic_map_mmio(m,p,b,o,s)
+#define mpic_map(m, p, b, o, s)_mpic_map_mmio(m, p, b, o, s)
 #endif /* !CONFIG_PPC_DCR */
 
 
@@ -345,11 +348,12 @@ static void __init mpic_test_broken_ipi(struct mpic 

[linux-yocto] [PATCH 11/18] arch/arm/mach-axxia: added support for ncr_read/ncr_write() to access PCIe/SRIO SerDes Config in 0x115 node

2014-02-18 Thread Charlie Paul
From: SangeethaRao sangeetha@lsi.com

Signed-off-by: SangeethaRao sangeetha@lsi.com
---
 arch/arm/mach-axxia/ncr.c |  133 +
 1 file changed, 122 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-axxia/ncr.c b/arch/arm/mach-axxia/ncr.c
index 58b959a..4112038 100644
--- a/arch/arm/mach-axxia/ncr.c
+++ b/arch/arm/mach-axxia/ncr.c
@@ -224,7 +224,7 @@ ncr_read(unsigned long region, unsigned long address, int 
number,
if (0 != ncr_lock(LOCK_DOMAIN))
return -1;
 
-   if (NCP_NODE_ID(region) != 0x0153) {
+   if ((NCP_NODE_ID(region) != 0x0153)  (NCP_NODE_ID(region) != 0x115)) {
/*
Set up the read command.
*/
@@ -274,6 +274,7 @@ ncr_read(unsigned long region, unsigned long address, int 
number,
*((unsigned long *) buffer) =
ncr_register_read((unsigned *) address);
address += 4;
+   buffer += 4;
number -= 4;
}
 
@@ -284,17 +285,76 @@ ncr_read(unsigned long region, unsigned long address, int 
number,
}
} else {
 #ifdef APB2SER_PHY_PHYS_ADDRESS
-   void __iomem *targ_address = apb2ser0_address +
+   if (NCP_NODE_ID(region) != 0x115) {
+   void __iomem *targ_address = apb2ser0_address +
(address  (~0x3));
-   /*
-   Copy data words to the buffer.
-   */
+   /*
+   * Copy data words to the buffer.
+   */
+
+   while (4 = number) {
+   *((unsigned long *) buffer) =
+   *((unsigned long *) targ_address);
+   targ_address += 4;
+   number -= 4;
+   }
+   } else {
+   void __iomem *base;
+   if (0x  address) {
+   ncr_unlock(LOCK_DOMAIN);
+   return -1;
+   }
+
+   switch (NCP_TARGET_ID(region)) {
+   case 0:
+   base = (apb2ser0_address + 0x1e0);
+   break;
+   case 1:
+   base = (apb2ser0_address + 0x1f0);
+   break;
+   case 2:
+   base = (apb2ser0_address + 0x200);
+   break;
+   case 3:
+   base = (apb2ser0_address + 0x210);
+   break;
+   case 4:
+   base = (apb2ser0_address + 0x220);
+   break;
+   case 5:
+   base = (apb2ser0_address + 0x230);
+   break;
+   default:
+   ncr_unlock(LOCK_DOMAIN);
+   return -1;
+   }
+   if ((NCP_TARGET_ID(region) == 0x1) ||
+   (NCP_TARGET_ID(region) == 0x4)) {
+   writel((0x84c0 + address), (base + 4));
+   } else {
+   writel((0x8540 + address), (base + 4));
+   }
+   do {
+   --wfc_timeout;
+   *((unsigned long *) buffer) =
+   readl(base + 4);
+   } while (0 != (*((unsigned long *) buffer)  0x8000)
+0  wfc_timeout);
+
+   if (0 == wfc_timeout) {
+   ncr_unlock(LOCK_DOMAIN);
+   return -1;
+   }
+
+   if ((NCP_TARGET_ID(region) == 0x1) ||
+   (NCP_TARGET_ID(region) == 0x4)) {
+   *((unsigned short *) buffer) =
+   readl(base + 8);
+   } else {
+   *((unsigned long *) buffer) =
+   readl(base + 8);
+   }
 
-   while (4 = number) {
-   *((unsigned long *) buffer) =
-   *((unsigned long *) targ_address);
-   targ_address += 4;
-   number -= 4;
}
 #else
ncr_unlock(LOCK_DOMAIN);
@@ -335,7 +395,7 @@ ncr_write(unsigned long region, unsigned long address, int 
number,
if (0 != ncr_lock(LOCK_DOMAIN))

[linux-yocto] [PATCH 13/18] arm: mmu: cleanup as per checkpatch

2014-02-18 Thread Charlie Paul
From: Charlie Paul charlie.p...@windriver.com

Cleaned up file as required by checkpatch

Signed-off-by: Charlie Paul charlie.p...@windriver.com

 Author:   Charlie Paul charlie.paul@windriver
---
 arch/arm/mm/mmu.c |  106 +
 1 file changed, 50 insertions(+), 56 deletions(-)

diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 253f85e..61df283 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -55,15 +55,17 @@ pmd_t *top_pmd;
 #define CPOLICY_WRITEALLOC 4
 
 static unsigned int cachepolicy __initdata = CPOLICY_WRITEBACK;
-static unsigned int ecc_mask __initdata = 0;
+static unsigned int ecc_mask __initdata;
 pgprot_t pgprot_user;
+EXPORT_SYMBOL(pgprot_user);
+
 pgprot_t pgprot_kernel;
+EXPORT_SYMBOL(pgprot_kernel);
+
 pgprot_t pgprot_hyp_device;
 pgprot_t pgprot_s2;
 pgprot_t pgprot_s2_device;
 
-EXPORT_SYMBOL(pgprot_user);
-EXPORT_SYMBOL(pgprot_kernel);
 
 struct cachepolicy {
const char  policy[16];
@@ -135,7 +137,7 @@ static int __init early_cachepolicy(char *p)
}
}
if (i == ARRAY_SIZE(cache_policies))
-   printk(KERN_ERR ERROR: unknown or unsupported cache policy\n);
+   pr_err(ERROR: unknown or unsupported cache policy\n);
/*
 * This restriction is partly to do with the way we boot; it is
 * unpredictable to have memory mapped using two different sets of
@@ -144,7 +146,7 @@ static int __init early_cachepolicy(char *p)
 * page tables.
 */
if (cpu_architecture() = CPU_ARCH_ARMv6) {
-   printk(KERN_WARNING Only cachepolicy=writeback supported on 
ARMv6 and later\n);
+   pr_warn(Only cachepolicy=writeback supported on ARMv6 and 
later\n);
cachepolicy = CPOLICY_WRITEBACK;
}
flush_cache_all();
@@ -156,7 +158,7 @@ early_param(cachepolicy, early_cachepolicy);
 static int __init early_nocache(char *__unused)
 {
char *p = buffered;
-   printk(KERN_WARNING nocache is deprecated; use cachepolicy=%s\n, p);
+   pr_warn(nocache is deprecated; use cachepolicy=%s\n, p);
early_cachepolicy(p);
return 0;
 }
@@ -165,7 +167,7 @@ early_param(nocache, early_nocache);
 static int __init early_nowrite(char *__unused)
 {
char *p = uncached;
-   printk(KERN_WARNING nowb is deprecated; use cachepolicy=%s\n, p);
+   pr_warn(nowb is deprecated; use cachepolicy=%s\n, p);
early_cachepolicy(p);
return 0;
 }
@@ -216,20 +218,20 @@ void adjust_cr(unsigned long mask, unsigned long set)
 
 static int __init early_cachepolicy(char *p)
 {
-   pr_warning(cachepolicy kernel parameter not supported without cp15\n);
+   pr_warn(cachepolicy kernel parameter not supported without cp15\n);
 }
 early_param(cachepolicy, early_cachepolicy);
 
 static int __init noalign_setup(char *__unused)
 {
-   pr_warning(noalign kernel parameter not supported without cp15\n);
+   pr_warn(noalign kernel parameter not supported without cp15\n);
 }
 __setup(noalign, noalign_setup);
 
 #endif /* ifdef CONFIG_CPU_CP15 / else */
 
-#define PROT_PTE_DEVICE
L_PTE_PRESENT|L_PTE_YOUNG|L_PTE_DIRTY|L_PTE_XN
-#define PROT_SECT_DEVICE   PMD_TYPE_SECT|PMD_SECT_AP_WRITE
+#define PROT_PTE_DEVICE
(L_PTE_PRESENT|L_PTE_YOUNG|L_PTE_DIRTY|L_PTE_XN)
+#define PROT_SECT_DEVICE   (PMD_TYPE_SECT|PMD_SECT_AP_WRITE)
 
 static struct mem_type mem_types[] = {
[MT_DEVICE] = {   /* Strongly ordered / ARMv6 shared device */
@@ -556,7 +558,7 @@ static void __init build_mem_type_table(void)
mem_types[MT_CACHECLEAN].prot_sect |= PMD_SECT_WB;
break;
}
-   printk(Memory policy: ECC %sabled, Data cache %s\n,
+   pr_info(Memory policy: ECC %sabled, Data cache %s\n,
ecc_mask ? en : dis, cp-policy);
 
for (i = 0; i  ARRAY_SIZE(mem_types); i++) {
@@ -595,7 +597,8 @@ static void __init *early_alloc(unsigned long sz)
return early_alloc_aligned(sz, sz);
 }
 
-static pte_t * __init early_pte_alloc(pmd_t *pmd, unsigned long addr, unsigned 
long prot)
+static pte_t * __init early_pte_alloc(pmd_t *pmd,
+   unsigned long addr, unsigned long prot)
 {
if (pmd_none(*pmd)) {
pte_t *pte = early_alloc(PTE_HWTABLE_OFF + PTE_HWTABLE_SIZE);
@@ -700,9 +703,8 @@ static void __init create_36bit_mapping(struct map_desc *md,
length = PAGE_ALIGN(md-length);
 
if (!(cpu_architecture() = CPU_ARCH_ARMv6 || cpu_is_xsc3())) {
-   printk(KERN_ERR MM: CPU does not support supersection 
-  mapping for 0x%08llx at 0x%08lx\n,
-  (long long)__pfn_to_phys((u64)md-pfn), addr);
+   pr_err(MM: CPU does not support supersection mapping for 
0x%08llx at 0x%08lx\n,
+   (long long)__pfn_to_phys((u64)md-pfn), addr);
return;
}
 
@@ -713,16 

[linux-yocto] [PATCH 18/18] axxia: Remove Wrapper Functions

2014-02-18 Thread Charlie Paul
From: John Jacques john.jacq...@lsi.com

These functions were temporary.  They were added to allow
development to continue on an external module that was not,
at the time, released under the GPL.

Signed-off-by: John Jacques john.jacq...@lsi.com
Signed-off-by: Paul Butler paul.but...@windriver.com
---
 arch/arm/mach-axxia/Makefile   |1 -
 arch/arm/mach-axxia/wrappers.c |  132 
 arch/powerpc/sysdev/Makefile   |2 -
 arch/powerpc/sysdev/lsi_acp_wrappers.c |  132 
 4 files changed, 267 deletions(-)
 delete mode 100644 arch/arm/mach-axxia/wrappers.c
 delete mode 100644 arch/powerpc/sysdev/lsi_acp_wrappers.c

diff --git a/arch/arm/mach-axxia/Makefile b/arch/arm/mach-axxia/Makefile
index 79053c8..7dbad2a 100644
--- a/arch/arm/mach-axxia/Makefile
+++ b/arch/arm/mach-axxia/Makefile
@@ -1,7 +1,6 @@
 #
 # Makefile for the linux kernel.
 #
-obj-y  += wrappers.o
 obj-y  += axxia.o
 obj-y  += clock.o
 obj-y   += io.o
diff --git a/arch/arm/mach-axxia/wrappers.c b/arch/arm/mach-axxia/wrappers.c
deleted file mode 100644
index 513dd9c..000
--- a/arch/arm/mach-axxia/wrappers.c
+++ /dev/null
@@ -1,132 +0,0 @@
-/*
- * arch/arm/mach-axxia/wrappers.c
- *
- * Copyright (C) 2013 LSI
- *
- * 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 linux/module.h
-#include asm/irq.h
-#include linux/io.h
-#include linux/irqdomain.h
-#include linux/skbuff.h
-#include linux/platform_device.h
-
-/*
-  
==
-  
==
-  Platform Device Registration
-  
==
-  
==
-*/
-
-/*
-  
--
-  acp_platform_device_register
-*/
-
-int
-acp_platform_device_register(struct platform_device *pdev)
-{
-   return platform_device_register(pdev);
-}
-EXPORT_SYMBOL(acp_platform_device_register);
-
-/*
-  
--
-  acp_platform_device_unregister
-*/
-
-void
-acp_platform_device_unregister(struct platform_device *pdev)
-{
-   platform_device_unregister(pdev);
-
-   return;
-}
-EXPORT_SYMBOL(acp_platform_device_unregister);
-
-/*
-  
-  
-  SKB
-  
-  
-*/
-
-/*
-  
-  acp_skb_tstamp_tx
-*/
-
-void
-acp_skb_tstamp_tx(struct sk_buff *orig_skb,
- struct skb_shared_hwtstamps *hwtstamps) {
-   skb_tstamp_tx(orig_skb, hwtstamps);
-}
-EXPORT_SYMBOL(acp_skb_tstamp_tx);
-
-/*
-  
-  
-  Interrupts
-  
-  
-*/
-
-/*
- * -
- * acp_irq_create_mapping
- */
-unsigned int acp_irq_create_mapping(struct irq_domain *host,
-   irq_hw_number_t hwirq)
-{
-   unsigned int mapped_irq;
-
-   preempt_disable();
-   mapped_irq = irq_create_mapping(host, hwirq);
-   preempt_enable();
-
-   return mapped_irq;
-}
-EXPORT_SYMBOL(acp_irq_create_mapping);
-
-/*
-  
==
-  
==
-  Linux Stuff
-  
==
- 

[linux-yocto] [PATCH 17/18] i2c-axxia: Support I2C_M_RECV_LEN

2014-02-18 Thread Charlie Paul
From: Anders Berg anders.b...@lsi.com

Add support for the I2C_M_RECV_LEN flag to enable SMBus block data transfers.

This patch also fixes an issue where the master failed to perform a proper
repeated start, but instead issued a stop followed by a start. This behaviour
confused some SMBus slave devices.

The STOP-START was caused by the use of the automatic mode of the controller.
By using manual mode the driver gets control over when a STOP condition is
signalled.

Signed-off-by: Anders Berg anders.b...@lsi.com
---
 drivers/i2c/busses/i2c-axxia.c |  220 +++-
 1 file changed, 151 insertions(+), 69 deletions(-)

diff --git a/drivers/i2c/busses/i2c-axxia.c b/drivers/i2c/busses/i2c-axxia.c
index 4f86418..e0a4b24 100644
--- a/drivers/i2c/busses/i2c-axxia.c
+++ b/drivers/i2c/busses/i2c-axxia.c
@@ -27,7 +27,8 @@
 #include linux/module.h
 
 #define SCL_WAIT_TIMEOUT_NS 2500
-#define I2C_TIMEOUT (msecs_to_jiffies(1000))
+#define I2C_XFER_TIMEOUT(msecs_to_jiffies(500))
+#define I2C_STOP_TIMEOUT(msecs_to_jiffies(100))
 #define TX_FIFO_SIZE8
 #define RX_FIFO_SIZE8
 
@@ -123,12 +124,10 @@ struct axxia_i2c_dev {
int irq;
/* xfer completion object */
struct completion msg_complete;
-   /* pointer to current message data */
-   u8 *msg_buf;
-   /* size of unsent data in the message buffer */
-   size_t msg_buf_remaining;
-   /* identifies read transfers */
-   int msg_read;
+   /* pointer to current message */
+   struct i2c_msg *msg;
+   /* number of bytes transferred in msg */
+   size_t msg_xfrd;
/* error code for completed message */
int msg_err;
/* current i2c bus clock rate */
@@ -168,10 +167,21 @@ axxia_i2c_init(struct axxia_i2c_dev *idev)
u32 t_setup;
u32 tmo_clk;
u32 prescale;
+   unsigned long timeout;
 
dev_dbg(idev-dev, rate=%uHz per_clk=%uMHz - ratio=1:%u\n,
idev-bus_clk_rate, clk_mhz, divisor);
 
+   /* Reset controller */
+   writel(0x01, idev-regs-soft_reset);
+   timeout = jiffies + msecs_to_jiffies(100);
+   while (readl(idev-regs-soft_reset)  1) {
+   if (time_after(jiffies, timeout)) {
+   dev_warn(idev-dev, Soft reset failed\n);
+   break;
+   }
+   }
+
/* Enable Master Mode */
writel(0x1, idev-regs-global_control);
 
@@ -186,8 +196,8 @@ axxia_i2c_init(struct axxia_i2c_dev *idev)
 
/* SDA Setup Time */
writel(t_setup, idev-regs-sda_setup_time);
-   /* SDA Hold Time, 5ns */
-   writel(ns_to_clk(5, clk_mhz), idev-regs-sda_hold_time);
+   /* SDA Hold Time, 300ns */
+   writel(ns_to_clk(300, clk_mhz), idev-regs-sda_hold_time);
/* Filter 50ns spikes */
writel(ns_to_clk(50, clk_mhz), idev-regs-spike_fltr_len);
 
@@ -195,15 +205,16 @@ axxia_i2c_init(struct axxia_i2c_dev *idev)
tmo_clk = ns_to_clk(SCL_WAIT_TIMEOUT_NS, clk_mhz);
 
/*
-* Find the prescaler value that makes tmo_clk fit in 15-bits counter.
+  Find the prescaler value that makes tmo_clk fit in 15-bits counter.
 */
-   for (prescale = 0; prescale  15; ++prescale) {
+   for (prescale=0; prescale  15; ++prescale) {
if (tmo_clk = 0x7fff)
break;
tmo_clk = 1;
}
-   if (tmo_clk  0x7fff)
+   if (tmo_clk  0x7fff) {
tmo_clk = 0x7fff;
+   }
 
/* Prescale divider (log2) */
writel(prescale, idev-regs-timer_clock_div);
@@ -228,15 +239,40 @@ axxia_i2c_init(struct axxia_i2c_dev *idev)
 }
 
 static int
-axxia_i2c_empty_rx_fifo(struct axxia_i2c_dev *idev)
+i2c_m_rd(const struct i2c_msg *msg)
 {
-   size_t rx_fifo_avail = readl(idev-regs-mst_rx_fifo);
-   int bytes_to_transfer = min(rx_fifo_avail, idev-msg_buf_remaining);
+   return (msg-flags  I2C_M_RD) != 0;
+}
 
-   idev-msg_buf_remaining -= bytes_to_transfer;
+static int
+i2c_m_recv_len(const struct i2c_msg *msg)
+{
+   return (msg-flags  I2C_M_RECV_LEN) != 0;
+}
 
-   while (0  bytes_to_transfer--)
-   *idev-msg_buf++ = readl(idev-regs-mst_data);
+static int
+axxia_i2c_empty_rx_fifo(struct axxia_i2c_dev *idev)
+{
+   struct i2c_msg *msg = idev-msg;
+   size_t rx_fifo_avail = readl(idev-regs-mst_rx_fifo);
+   int bytes_to_transfer = min(rx_fifo_avail, msg-len - idev-msg_xfrd);
+
+   while (0  bytes_to_transfer--) {
+   int c = readl(idev-regs-mst_data);
+   if (idev-msg_xfrd == 0  i2c_m_recv_len(msg)) {
+   if (c == 0 || c  I2C_SMBUS_BLOCK_MAX) {
+   idev-msg_err = -EPROTO;
+   i2c_int_disable(idev, ~0);
+   dev_err(idev-dev,
+   invalid SMBus block size (%d)\n, c);
+  

Re: [linux-yocto] [PATCH 1/2] baytrail: Add feature/soc/baytrail

2014-02-18 Thread Darren Hart
On 2/16/14, 18:27, Ong, Boon Leong boon.leong@intel.com wrote:

 -Original Message-
 From: linux-yocto-boun...@yoctoproject.org [mailto:linux-yocto-
 boun...@yoctoproject.org] On Behalf Of Darren Hart
 Sent: Saturday, February 15, 2014 8:31 AM
 To: Linux Yocto
 Cc: Darren Hart
 Subject: [linux-yocto] [PATCH 1/2] baytrail: Add feature/soc/baytrail
 
 Add support for the various devices on the BayTrail SoCs, including PWM,
 SPI, I2C, ASOC, UARTs, DMA, LPSS, etc.
 
 Signed-off-by: Darren Hart dvh...@linux.intel.com
 ---
  .../features/soc/baytrail/baytrail.cfg |   61

  .../features/soc/baytrail/baytrail.scc |   13 +
  2 files changed, 74 insertions(+)
  create mode 100644 meta/cfg/kernel-
 cache/features/soc/baytrail/baytrail.cfg
  create mode 100644 meta/cfg/kernel-
 cache/features/soc/baytrail/baytrail.scc
 
 diff --git a/meta/cfg/kernel-cache/features/soc/baytrail/baytrail.cfg
 b/meta/cfg/kernel-cache/features/soc/baytrail/baytrail.cfg
 new file mode 100644
 index 000..cf46d2b8
 --- /dev/null
 +++ b/meta/cfg/kernel-cache/features/soc/baytrail/baytrail.cfg
 @@ -0,0 +1,61 @@
 +CONFIG_PCI=y
 +
 +CONFIG_INPUT=y
 +CONFIG_INPUT_EVDEV=y
 +
 +CONFIG_SOUND=y
 +CONFIG_SND=y
 +CONFIG_SND_HDA_INTEL=y

 +CONFIG_SND_SOC=m
 +CONFIG_SND_DESIGNWARE_I2S=m
 +CONFIG_SND_SOC_I2C_AND_SPI=m
 +CONFIG_SND_SIMPLE_CARD=m
Are the above configs meant to enable a specific skus of BYT with
designware I2S? 
For BYT-I, the ASoC is not upstream yet.

Thank you for the review - I don't have the same insight into the silicon
as your team, I will update the fragment per your comments. Much
appreciated.


 +
 +CONFIG_BACKLIGHT_LCD_SUPPORT=y
 +CONFIG_BACKLIGHT_CLASS_DEVICE=y
 +
 +# SATA Support
 +CONFIG_ATA=y
 +CONFIG_SATA_AHCI=y
 +CONFIG_CHR_DEV_SG=y
 +
 +CONFIG_X86_INTEL_LPSS=y
 +
 +CONFIG_PINMUX=y
 +CONFIG_PINCONF=y
 +CONFIG_PINCTRL_BAYTRAIL=y
 +
 +CONFIG_SERIAL_8250_DW=y
 +
 +# MMC / SDHCI Support
 +CONFIG_MMC=y
 +CONFIG_MMC_SDHCI=y
 +CONFIG_MMC_SDHCI_PCI=y
 +CONFIG_MMC_SDHCI_ACPI=y
 +
 +CONFIG_I2C_DESIGNWARE_CORE=m
 +CONFIG_I2C_DESIGNWARE_PLATFORM=m

 +CONFIG_I2C_DESIGNWARE_PCI=m
drivers/i2c/busses/i2c-designware-pcidrv.c does not contain BYT support
yet,
so is this intentional to make it m now?

Mostly erring on the side of caution, better to enable more than necessary
than to inadvertently disable something we need. I will drop this from the
fragment.


 +
 +# SMBus Support
 +CONFIG_I2C_I801=m
 +
 +CONFIG_SPI_PXA2XX=m
 +CONFIG_SPI_PXA2XX_PCI=m
drivers/spi/spi-pxa2xx-pci.c does not contain BYT support yet,
so is this intentional to make it m now?

 +
 +CONFIG_DW_DMAC=m
 +
Should DW_DMAC_PCI be added since it has been added into LTSI
patches.baytrail/1139-dma-dw-add-PCI-part-of-the-driver.patch

Is that upstream as well or only LTSI? If only LTSI, then it needs to be
handled special or we will get errors on the mainline configcheck.


 +# GPIO Support
 +CONFIG_GPIOLIB=y
 +CONFIG_GPIO_SYSFS=y
Suggest to move these configs to be next to CONFIG_PINMUX.

OK

 

 +
 +# PWM Support
 +CONFIG_PWM=y
The PWM for BYT driver has not been up-streamed yet.

But we will want the subsystem enabled when it is, so this will be needed
and doesn't break anything as is.

 

 +
 +# USB Device Support
 +CONFIG_USB_DWC3=y
 +CONFIG_USB_DWC3_GADGET=y
 +CONFIG_USB_GADGET=y
 +CONFIG_USB_LIBCOMPOSITE=m
 +CONFIG_USB_MASS_STORAGE=m
 +CONFIG_NOP_USB_XCEIV=y

Reviewed-by: Chew Chiau Ee  Ong Boon Leong

Thank you for the review!

-- 
Darren Hart
Yocto Project - Linux Kernel
Intel Open Source Technology Center




___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


Re: [linux-yocto] kernel-yocto: validate_branches questions

2014-02-18 Thread Bruce Ashfield

  
  
On 14-02-18 10:51 AM, Moore, Tysen
  wrote:


  
  Bruce,

Thanks for the fast response. I only posted the question
yesterday.
  


I like to reply quickly to problems :)


  

The "KMETA Check" that I am referring to is:
 ## KMETA branch validation
 meta_head=`git show-ref -s --heads ${KMETA}`
 target_meta_head="${SRCREV_meta}"
 git show-ref --quiet --verify -- "refs/heads/${KMETA}"
 if [ $? -eq 1 ]; then
  return
#
EXITS HERE
 fi

Because with KMETA not defined here it exists early. The
problem is that the earlier "SRCREV loop" starts with, "git
checkout -q master". Since KMETA is not defined and we exit
early the code that follows the KMETA check to change back to
KBRANCH is not executed.
  


Correct. But that's supposed to be safe, the checkout of the machine
branch at the bottom of the routine is not supposed to be the last
manipulation of the branches. You should still end up on the right
branch when the build happens.

I'm driving to understand why that is happening.

Can you share some specific details ? If this is master, and you
go into the kernel's source directory tmp/work/*/linux/ and cat 
.meta/top_tgt, that should point to a generated file, what are the
contents of that generated description.

One solution would be to allow that final git checkout to run (as
you mentioned), but if other manipulations of the tree happen, 
you'll still be broken, and I want to avoid that.

Bruce


  

The only workaround I've come up with is very
hackish--embarrassing to post;-) 
do_validate_branches_prepend() {
 KMETA="${KBRANCH}"
 SRCREV_meta="${SRCREV}"
 SRCREV_machine="${SRCREV}"
}
do_validate_branches_append() {
 KMETA=""
 SRCREV_meta=""
 SRCREV_machine=""
}
[As you can imagine I'd prefer not to use this hack.]

The problem is that if I do not clear KMETA the configme
(kgit-meta and friends) call later fails. The kernel_configme
code allows KMETA to be undefined but it is almost like the
validate_branches is coded without that same option. Shouldn't
the KMETA "check" code listed above be skipped when KMETA is not
defined? I think this change to the validate_branches code would
fix this use case. I don't think it would break other use
cases, but I am rather green with Yocto.

Thanks again for the detailed description and help.

Tysen
  
  
  

  

   
  
  
  XS Embedded LLC
  29065 Cabot Drive, Suite 200
  Novi, MI 48377
  USA
  


  

  Phone
  +1 (248) 209 - 6613


  Fax
  +1 (248) 281 - 7020

  


www.xs-embedded.com
  tysen.mo...@xs-embedded.com
  
  :: based.on.visions ::

  

  
  
XS Embedded LLC
  Managing Director: Joachim Kobinger
  

  
  
Confidentiality Notice: This e-mail
  message, including any attachments, is for the sole
  use of the intended recipient(s) and may contain
  confidential and privileged information. Any
  unauthorized review, use, disclosure or distribution
  is prohibited. If you are not the intended recipient,
  please contact the sender by return e-mail and destroy
  all copies of the original message.

  

  
  


  

___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


Re: [linux-yocto] kernel-yocto: validate_branches questions

2014-02-18 Thread Bruce Ashfield

On 14-02-18 03:23 PM, Moore, Tysen wrote:

I looked for the file you requested but did not see it.  Where can I
find this?  Is it part of the linux kernel WORKDIR?  If so, I greped the
tree and I don't see it.  Or am I looking in the wrong place?  If I can
find it I will be sure to pass it on.


What yocto branch are you using ?

It's in the WORKDIR/linux/.meta/ directory.



What I've got are two branches:
- My KBRANCH branch with the last commit being: (717bdd797)
- Another branch with the last commit being (c826758fb), then the commit
(717bdd797)

So the validate_branches does a checkout of master, the goes over these
two branches and puts them on the commit I wanted--I think this is
fine.  Then the KMETA check takes place and fails because I do not have
KMETA defined, thus exiting early and leaving me at master.  The problem
seems to be the failing of this KMETA that is not defined.  It seems
like KMETA is required for this to work properly.


KMETA is definitely not required, I do korg based builds all the time,
all without a meta branch, so we can make this work, I just need to know
what has broken .. with a bit more information, we'll get there.

Bruce




*From:* Bruce Ashfield [bruce.ashfi...@windriver.com]
*Sent:* Tuesday, February 18, 2014 2:29 PM
*To:* Moore, Tysen; linux-yocto@yoctoproject.org
*Subject:* Re: [linux-yocto] kernel-yocto: validate_branches questions

On 14-02-18 10:51 AM, Moore, Tysen wrote:

XSe Logo

*XS Embedded LLC*
29065 Cabot Drive, Suite 200
Novi, MI 48377
USA

Phone   +1 (248) 209 - 6613
Fax +1 (248) 281 - 7020


www.xs-embedded.com http://www.xs-embedded.com
tysen.mo...@xs-embedded.com mailto:tysen.mo...@xs-embedded.com

*:: based.on.visions ::*

XS Embedded LLC
Managing Director: Joachim Kobinger

Confidentiality Notice: This e-mail message, including any attachments,
is for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by return e-mail and destroy all
copies of the original message.



Bruce,

Thanks for the fast response.  I only posted the question yesterday.


I like to reply quickly to problems :)



The KMETA Check that I am referring to is:
## KMETA branch validation
 meta_head=`git show-ref -s --heads ${KMETA}`
 target_meta_head=${SRCREV_meta}
git show-ref --quiet --verify -- refs/heads/${KMETA}
if [ $? -eq 1 ]; then
return# EXITS HERE
fi

Because with KMETA not defined here it exists early.  The problem is
that the earlier SRCREV loop starts with, git checkout -q master.
Since KMETA is not defined and we exit early the code that follows the
KMETA check to change back to KBRANCH is not executed.


Correct. But that's supposed to be safe, the checkout of the machine
branch at the bottom of the routine is not supposed to be the last
manipulation of the branches. You should still end up on the right
branch when the build happens.

I'm driving to understand why that is happening.

Can you share some specific details ?  If this is master, and you
go into the kernel's source directory tmp/work/*/linux/ and cat
.meta/top_tgt, that should point to a generated file, what are the
contents of that generated description.

One solution would be to allow that final git checkout to run (as
you mentioned), but if other manipulations of the tree happen,
you'll still be broken, and I want to avoid that.

Bruce



The only workaround I've come up with is very hackish--embarrassing to
post;-)
do_validate_branches_prepend() {
KMETA=${KBRANCH}
SRCREV_meta=${SRCREV}
SRCREV_machine=${SRCREV}
}
do_validate_branches_append() {
KMETA=
SRCREV_meta=
SRCREV_machine=
}
[As you can imagine I'd prefer not to use this hack.]

The problem is that if I do not clear KMETA the configme (kgit-meta
and friends) call later fails.  The kernel_configme code allows KMETA
to be undefined but it is almost like the validate_branches is coded
without that same option.  Shouldn't the KMETA check code listed
above be skipped when KMETA is not defined? I think this change to the
validate_branches code would fix this use case.  I don't think it
would break other use cases, but I am rather green with Yocto.

Thanks again for the detailed description and help.

Tysen

XSe Logo

*XS Embedded LLC*
29065 Cabot Drive, Suite 200
Novi, MI 48377
USA

Phone   +1 (248) 209 - 6613
Fax +1 (248) 281 - 7020


www.xs-embedded.com http://www.xs-embedded.com
tysen.mo...@xs-embedded.com mailto:tysen.mo...@xs-embedded.com

*:: based.on.visions ::*

XS Embedded LLC
Managing Director: Joachim Kobinger

Confidentiality Notice: This e-mail message, including any
attachments, is for the sole use of the intended recipient(s) and may
contain confidential and 

Re: [linux-yocto] [PATCH 1/2] baytrail: Add feature/soc/baytrail

2014-02-18 Thread Ong, Boon Leong


 -Original Message-
 From: Darren Hart [mailto:dvh...@linux.intel.com]
 Sent: Wednesday, February 19, 2014 3:12 AM
 To: Ong, Boon Leong; linux-yocto@yoctoproject.org
 Subject: Re: [linux-yocto] [PATCH 1/2] baytrail: Add feature/soc/baytrail
 
 On 2/16/14, 18:27, Ong, Boon Leong boon.leong@intel.com wrote:
 
 +CONFIG_SND_SOC=m
 +CONFIG_SND_DESIGNWARE_I2S=m
 +CONFIG_SND_SOC_I2C_AND_SPI=m
 +CONFIG_SND_SIMPLE_CARD=m
 Are the above configs meant to enable a specific skus of BYT with
 designware I2S?
 For BYT-I, the ASoC is not upstream yet.
 
 
 This will be needed when it is supported right?
 
 What is missing here?
 
I am commenting from BYT-I perspective below:
CONFIG_SND_SOC=m : yes it is needed.
CONFIG_SND_DESIGNWARE_I2S, CONFIG_SND_SOC_I2C_AND_SPI  CONFIG_SND_SIMPLE_CARD:
are not needed for BYT-I sku. 
Since they are still working their way up-stream, I can only get the correct 
CONFIGS once the drivers 
are available.

 --
 Darren Hart
 Yocto Project - Linux Kernel
 Intel Open Source Technology Center
 
 
 

___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


Re: [linux-yocto] kernel-yocto: validate_branches questions

2014-02-18 Thread Moore, Tysen
We are using:
BitBake Build Tool Core version 1.18.0, bitbake version 1.18.0

Unfortunately I am not 100% sure what version we are using of Yocto/etc.  I do 
know we are a bit behind.  I did compare validate_branches versus one I found 
on github and the only difference was some SRCREV_machine checking in the 
beginning of the routine.  Is there an easy way to tell what version of 
yocto/poky/etc is loaded?

XS Embedded LLC
29065 Cabot Drive, Suite 200
Novi, MI 48377
USA

Phone +1 (248) 209 - 6613
Fax   +1 (248) 281 - 7020

www.xs-embedded.com
tysen.mo...@xs-embedded.com

:: based.on.visions ::


XS Embedded LLC
Managing Director: Joachim Kobinger

Confidentiality Notice: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and may contain confidential and 
privileged information. Any unauthorized review, use, disclosure or 
distribution is prohibited. If you are not the intended recipient, please 
contact the sender by return e-mail and destroy all copies of the original 
message.


From: Bruce Ashfield [bruce.ashfi...@windriver.com]
Sent: Tuesday, February 18, 2014 4:01 PM
To: Moore, Tysen; linux-yocto@yoctoproject.org
Subject: Re: [linux-yocto] kernel-yocto: validate_branches questions

On 14-02-18 03:23 PM, Moore, Tysen wrote:
 I looked for the file you requested but did not see it.  Where can I
 find this?  Is it part of the linux kernel WORKDIR?  If so, I greped the
 tree and I don't see it.  Or am I looking in the wrong place?  If I can
 find it I will be sure to pass it on.

What yocto branch are you using ?

It's in the WORKDIR/linux/.meta/ directory.


 What I've got are two branches:
 - My KBRANCH branch with the last commit being: (717bdd797)
 - Another branch with the last commit being (c826758fb), then the commit
 (717bdd797)

 So the validate_branches does a checkout of master, the goes over these
 two branches and puts them on the commit I wanted--I think this is
 fine.  Then the KMETA check takes place and fails because I do not have
 KMETA defined, thus exiting early and leaving me at master.  The problem
 seems to be the failing of this KMETA that is not defined.  It seems
 like KMETA is required for this to work properly.

KMETA is definitely not required, I do korg based builds all the time,
all without a meta branch, so we can make this work, I just need to know
what has broken .. with a bit more information, we'll get there.

Bruce


 
 *From:* Bruce Ashfield [bruce.ashfi...@windriver.com]
 *Sent:* Tuesday, February 18, 2014 2:29 PM
 *To:* Moore, Tysen; linux-yocto@yoctoproject.org
 *Subject:* Re: [linux-yocto] kernel-yocto: validate_branches questions

 On 14-02-18 10:51 AM, Moore, Tysen wrote:

 XSe Logo

 *XS Embedded LLC*
 29065 Cabot Drive, Suite 200
 Novi, MI 48377
 USA

 Phone +1 (248) 209 - 6613
 Fax   +1 (248) 281 - 7020


 www.xs-embedded.com http://www.xs-embedded.com
 tysen.mo...@xs-embedded.com mailto:tysen.mo...@xs-embedded.com

 *:: based.on.visions ::*

 XS Embedded LLC
 Managing Director: Joachim Kobinger

 Confidentiality Notice: This e-mail message, including any attachments,
 is for the sole use of the intended recipient(s) and may contain
 confidential and privileged information. Any unauthorized review, use,
 disclosure or distribution is prohibited. If you are not the intended
 recipient, please contact the sender by return e-mail and destroy all
 copies of the original message.


 Bruce,

 Thanks for the fast response.  I only posted the question yesterday.

 I like to reply quickly to problems :)


 The KMETA Check that I am referring to is:
 ## KMETA branch validation
  meta_head=`git show-ref -s --heads ${KMETA}`
  target_meta_head=${SRCREV_meta}
 git show-ref --quiet --verify -- refs/heads/${KMETA}
 if [ $? -eq 1 ]; then
 return# EXITS HERE
 fi

 Because with KMETA not defined here it exists early.  The problem is
 that the earlier SRCREV loop starts with, git checkout -q master.
 Since KMETA is not defined and we exit early the code that follows the
 KMETA check to change back to KBRANCH is not executed.

 Correct. But that's supposed to be safe, the checkout of the machine
 branch at the bottom of the routine is not supposed to be the last
 manipulation of the branches. You should still end up on the right
 branch when the build happens.

 I'm driving to understand why that is happening.

 Can you share some specific details ?  If this is master, and you
 go into the kernel's source directory tmp/work/*/linux/ and cat
 .meta/top_tgt, that should point to a generated file, what are the
 contents of that generated description.

 One solution would be to allow that final git checkout to run (as
 you mentioned), but if other manipulations of the tree happen,
 you'll still be broken, and I want to avoid