date:20140211


On 14-02-11 01:01 AM, Darren Hart wrote:

On 2/10/14, 21:45, Bruce Ashfield bruce.ashfi...@windriver.com wrote:


On 2/11/2014, 12:24 AM, Darren Hart wrote:

On 2/10/14, 21:23, Bruce Ashfield bruce.ashfi...@windriver.com
wrote:


On 2/10/2014, 11:59 PM, Darren Hart wrote:

On 2/10/14, 16:21, Bruce Ashfield bruce.ashfi...@gmail.com wrote:


On Mon, Feb 10, 2014 at 5:47 PM, Darren Hart dvh...@linux.intel.com
wrote:

On 2/6/14, 17:18, Darren Hart dvh...@linux.intel.com wrote:


This series does some fragment cleanup and adds the two new common
BSPs
for the
meta-intel layer: intel-core2-32 and intel-corei7-64. These BSPs
currently
include all the corresponding ARCH (32 or 64) BSP descriptions as
well
as
common-pc to build two kernels capable of supporting all these
machines.

v2:
- Generic to specific ordering in scc files
- Use driver fragments from common-pc*, not the entire scc
- Update both machines to use CONFIG_MCORE2



Hi Bruce, any pending concerns on this series?


Nope. I just didn't want to merge it yet, since I have three other
pending updates
to the 3.10 kernel that I was waiting on in the meantime. LTSI being
the
biggest that I want to see merged before piling more on top.


This is for -dev first and can go into 3.10 after the LTSI update.
Could
it go into -dev now? I've got some meta-intel stuff that's queued up
behind this and people clawing at me for it :-)


Ack'd. I can do that, I like to keep them in sync, but I'm willing to
bend that rule to keep things moving. I'll have this merged during
the day tomorrow.



Thank you kindly.


On that same note, I went ahead and merged this to -dev, it is now in
the linux-yocto-dev repository.

I had a reject for 3.10 on the first patch of the series (we've already
done some eg20t work). It wasn't hard to resolve, but can you confirm
that you do want this on 3.10 as well as -dev, before I got ahead and
push that change.

Bruce


As you have expressed an interest in keeping them in sync, please resolve
the conflict with minnow.scc by adding the eg20t include line. This won't
hurt anything as any differences between eg20t.cfg and minnow.cfg will
defer to minnow.cfg as it comes later.


3.10 is still a bit different from the master (-dev) kernel, but I did
a few fixups and it looks sane (enough). Incremental patches to what
I just pushed to 3.10's meta branch are welcomed to fix anything I
did wrong.

Bruce



As I update minnow, we can remove the redundancy later.

--
Darren




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

Re: [linux-yocto] [PATCH v2 0/4] Cleanup eg20t, 8250, add intel-common BSPs

On 2/11/14, 7:45, Bruce Ashfield bruce.ashfi...@windriver.com wrote:

On 14-02-11 01:01 AM, Darren Hart wrote:
 On 2/10/14, 21:45, Bruce Ashfield bruce.ashfi...@windriver.com
wrote:

 On 2/11/2014, 12:24 AM, Darren Hart wrote:
 On 2/10/14, 21:23, Bruce Ashfield bruce.ashfi...@windriver.com
 wrote:

 On 2/10/2014, 11:59 PM, Darren Hart wrote:
 On 2/10/14, 16:21, Bruce Ashfield bruce.ashfi...@gmail.com
wrote:

 On Mon, Feb 10, 2014 at 5:47 PM, Darren Hart
dvh...@linux.intel.com
 wrote:
 On 2/6/14, 17:18, Darren Hart dvh...@linux.intel.com wrote:

 This series does some fragment cleanup and adds the two new
common
 BSPs
 for the
 meta-intel layer: intel-core2-32 and intel-corei7-64. These BSPs
 currently
 include all the corresponding ARCH (32 or 64) BSP descriptions as
 well
 as
 common-pc to build two kernels capable of supporting all these
 machines.

 v2:
 - Generic to specific ordering in scc files
 - Use driver fragments from common-pc*, not the entire scc
 - Update both machines to use CONFIG_MCORE2


 Hi Bruce, any pending concerns on this series?

 Nope. I just didn't want to merge it yet, since I have three other
 pending updates
 to the 3.10 kernel that I was waiting on in the meantime. LTSI
being
 the
 biggest that I want to see merged before piling more on top.

 This is for -dev first and can go into 3.10 after the LTSI update.
 Could
 it go into -dev now? I've got some meta-intel stuff that's queued up
 behind this and people clawing at me for it :-)

 Ack'd. I can do that, I like to keep them in sync, but I'm willing to
 bend that rule to keep things moving. I'll have this merged during
 the day tomorrow.


 Thank you kindly.

 On that same note, I went ahead and merged this to -dev, it is now in
 the linux-yocto-dev repository.

 I had a reject for 3.10 on the first patch of the series (we've already
 done some eg20t work). It wasn't hard to resolve, but can you confirm
 that you do want this on 3.10 as well as -dev, before I got ahead and
 push that change.

 Bruce

 As you have expressed an interest in keeping them in sync, please
resolve
 the conflict with minnow.scc by adding the eg20t include line. This
won't
 hurt anything as any differences between eg20t.cfg and minnow.cfg will
 defer to minnow.cfg as it comes later.

3.10 is still a bit different from the master (-dev) kernel, but I did
a few fixups and it looks sane (enough). Incremental patches to what
I just pushed to 3.10's meta branch are welcomed to fix anything I
did wrong.

Thanks Bruce. I see the changes in 3.10, but I am not seeing the
linux-yocto-dev meta changes:


$ git pull origin meta
From git://git.yoctoproject.org/linux-yocto-dev
 * branchmeta   - FETCH_HEAD
Already up-to-date.

$ git l
0580cff checkpoint dir: meta
469420b checkpoint dir: meta/scripts
180ec63 checkpoint dir: meta/patches
d89dd7d checkpoint dir: meta/cfg/scratch
071c446 checkpoint dir: m



--
Darren


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

Re: [linux-yocto] [PATCHv2 0/2] meta: move PCI mode configurations into separate scc file


On 14-02-11 04:35 AM, rebecca.swee.fun.ch...@intel.com wrote:

From: Chang, Rebecca Swee Fun rebecca.swee.fun.ch...@intel.com

Hi,

This is a pull request for an update on valleyisland-io
cfg and scc files.

Valley Island LPSS devices are supporting both ACPI and
PCI mode enumeration. In order for users to easily enable
ACPI mode enumeration for valleyisland BSP, we moved the
PCI mode configs out into a separate scc file.

By default, kernel recipe will enable PCI mode. When user
found a need to enable ACPI mode, they can refer to README
in meta-valleyisland for further enabling steps.

Please help to pull update into linux-yocto-3.8 meta branch



merged.

Bruce


Thanks.

Rebecca

The following changes since commit f87180481b12aebd16b9234d922d5f4a25a32dca:

   meta: rename scc files for valleyisland bsp (2014-02-04 09:09:17 -0500)

are available in the git repository at:

   git://git.yoctoproject.org/linux-yocto-contrib rebeccas/meta-update
   
http://git.yoctoproject.org/cgit.cgi/linux-yocto-contrib/log/?h=rebeccas/meta-update

Chang, Rebecca Swee Fun (2):
   meta: valleyisland-io: remove PCI mode LPSS device config
   meta: valleyisland-io: move PCI mode related configurations into
 separate scc file

  .../features/valleyisland-io/valleyisland-io-pci.cfg  |8 
  .../features/valleyisland-io/valleyisland-io-pci.scc  |4 
  .../kernel-cache/features/valleyisland-io/valleyisland-io.cfg |9 -
  3 files changed, 12 insertions(+), 9 deletions(-)
  create mode 100644 
meta/cfg/kernel-cache/features/valleyisland-io/valleyisland-io-pci.cfg
  create mode 100644 
meta/cfg/kernel-cache/features/valleyisland-io/valleyisland-io-pci.scc



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

Re: [linux-yocto] [PATCH 0/1] meta: remove duplicated config in valleyisland cfg file


On 14-02-11 12:31 PM, rebecca.swee.fun.ch...@intel.com wrote:

From: Chang, Rebecca Swee Fun rebecca.swee.fun.ch...@intel.com

Hi,

This is a pull request for an update on valleyisland-io
cfg files.

This patchset is about removing CONFIG_BYT_LPSS_BRD from
valleyisland.cfg.

CONFIG_BYT_LPSS_BRD is a duplicated config. It has been
included in features/valleyisland-io/valleyisland-io-pci.

Please help to pull this update into linux-yocto-3.8 meta branch


merged.

Bruce



Thanks.

Rebecca

The following changes since commit f87180481b12aebd16b9234d922d5f4a25a32dca:

   meta: rename scc files for valleyisland bsp (2014-02-04 09:09:17 -0500)

are available in the git repository at:

   git://git.yoctoproject.org/linux-yocto-contrib rebeccas/meta-dev
   
http://git.yoctoproject.org/cgit.cgi/linux-yocto-contrib/log/?h=rebeccas/meta-dev

Chang, Rebecca Swee Fun (1):
   meta: remove CONFIG_BYT_LPSS_BRD from valleyisland cfg file

  meta/cfg/kernel-cache/bsp/valleyisland/valleyisland.cfg |1 -
  1 file changed, 1 deletion(-)



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

[linux-yocto] LTSI for 3.10 - Standard Practice

Bruce,

While looking to update the MinnowBoard dora BSP I noticed that the minnow
platform drivers Greg added to LTSI were not in standard/ltsi. Did you
drop those in favor of the minnow-io feature?

I see the standard/base and standard/ltsi branches are at the same commit
ID. What is the expected usage here? If you want LTSI, are you expected to
specify standard/ltsi? Or is that just a staging branch, and everything
can be assumed to have the contents of LTSI? (The latter was my
expectation, but I wanted to be sure).

-- 
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] LTSI for 3.10 - Standard Practice

On Tue, Feb 11, 2014 at 5:50 PM, Hart, Darren darren.h...@intel.com wrote:
 Bruce,

 While looking to update the MinnowBoard dora BSP I noticed that the minnow
 platform drivers Greg added to LTSI were not in standard/ltsi. Did you
 drop those in favor of the minnow-io feature?

standard/ltsi is applied on top of the standard branch contents, and since
we already had the minnow io features in there, I checked the patches
and went with the ones already in the standard branch.


 I see the standard/base and standard/ltsi branches are at the same commit
 ID. What is the expected usage here? If you want LTSI, are you expected to
 specify standard/ltsi? Or is that just a staging branch, and everything
 can be assumed to have the contents of LTSI? (The latter was my
 expectation, but I wanted to be sure).

All branches have LTSI contained with them, so you can use any branch
in the tree and be assured that you have LTSI + anything extra on the
branch, but definitely an exact superset of LTSI.

So yep, you have it right, standard/ltsi is just where I staged the LTSI
integration, and where I'll merge any updates to it.

Bruce


 --
 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



-- 
Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] LTSI for 3.10 - Standard Practice

On 2/11/14, 16:04, Bruce Ashfield bruce.ashfi...@gmail.com wrote:

On Tue, Feb 11, 2014 at 5:50 PM, Hart, Darren darren.h...@intel.com
wrote:
 Bruce,

 While looking to update the MinnowBoard dora BSP I noticed that the
minnow
 platform drivers Greg added to LTSI were not in standard/ltsi. Did you
 drop those in favor of the minnow-io feature?

standard/ltsi is applied on top of the standard branch contents, and since
we already had the minnow io features in there, I checked the patches
and went with the ones already in the standard branch.

Ah, but I'm talking about minnow-io, which is not in the standard branch,
it exists only in features/minnow-io (and greg's LTSI, but not
standard/ltsi).



 I see the standard/base and standard/ltsi branches are at the same
commit
 ID. What is the expected usage here? If you want LTSI, are you expected
to
 specify standard/ltsi? Or is that just a staging branch, and everything
 can be assumed to have the contents of LTSI? (The latter was my
 expectation, but I wanted to be sure).

All branches have LTSI contained with them, so you can use any branch
in the tree and be assured that you have LTSI + anything extra on the
branch, but definitely an exact superset of LTSI.

So yep, you have it right, standard/ltsi is just where I staged the LTSI
integration, and where I'll merge any updates to it.

Ack, thanks.

-- 
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] LTSI for 3.10 - Standard Practice


On 2/11/2014, 7:06 PM, Hart, Darren wrote:

On 2/11/14, 16:04, Bruce Ashfield bruce.ashfi...@gmail.com wrote:


On Tue, Feb 11, 2014 at 5:50 PM, Hart, Darren darren.h...@intel.com
wrote:

Bruce,

While looking to update the MinnowBoard dora BSP I noticed that the
minnow
platform drivers Greg added to LTSI were not in standard/ltsi. Did you
drop those in favor of the minnow-io feature?


standard/ltsi is applied on top of the standard branch contents, and since
we already had the minnow io features in there, I checked the patches
and went with the ones already in the standard branch.


Ah, but I'm talking about minnow-io, which is not in the standard branch,
it exists only in features/minnow-io (and greg's LTSI, but not
standard/ltsi).


Look again. When I merged LTSI, I had a 1:1 conflict with
patches already applied. So you may think that features/minnow-io
wasn't applied .. but it was.

Bruce







I see the standard/base and standard/ltsi branches are at the same
commit
ID. What is the expected usage here? If you want LTSI, are you expected
to
specify standard/ltsi? Or is that just a staging branch, and everything
can be assumed to have the contents of LTSI? (The latter was my
expectation, but I wanted to be sure).


All branches have LTSI contained with them, so you can use any branch
in the tree and be assured that you have LTSI + anything extra on the
branch, but definitely an exact superset of LTSI.

So yep, you have it right, standard/ltsi is just where I staged the LTSI
integration, and where I'll merge any updates to it.


Ack, thanks.



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

Re: [linux-yocto] LTSI for 3.10 - Standard Practice

On 2/11/14, 16:11, Bruce Ashfield bruce.ashfi...@windriver.com wrote:

On 2/11/2014, 7:06 PM, Hart, Darren wrote:
 On 2/11/14, 16:04, Bruce Ashfield bruce.ashfi...@gmail.com wrote:

 On Tue, Feb 11, 2014 at 5:50 PM, Hart, Darren darren.h...@intel.com
 wrote:
 Bruce,

 While looking to update the MinnowBoard dora BSP I noticed that the
 minnow
 platform drivers Greg added to LTSI were not in standard/ltsi. Did you
 drop those in favor of the minnow-io feature?

 standard/ltsi is applied on top of the standard branch contents, and
since
 we already had the minnow io features in there, I checked the patches
 and went with the ones already in the standard branch.

 Ah, but I'm talking about minnow-io, which is not in the standard
branch,
 it exists only in features/minnow-io (and greg's LTSI, but not
 standard/ltsi).

Look again. When I merged LTSI, I had a 1:1 conflict with
patches already applied. So you may think that features/minnow-io
wasn't applied .. but it was.

There are two things happening here.

1) The PCH_GBE and PCH_UART changes. Those were in standard/base and would
have conflicted with LTSI.

2) The non-upstream minnow-io (drivers/platform/x86/minnow*) drivers.
These are only in minnow-io, still.

$ git rev-parse standard/ltsi
e9cdab78bed262dbeadc7f403989f20972bcddde

$ git rev-parse HEAD
e9cdab78bed262dbeadc7f403989f20972bcddde


$ ls drivers/platform/x86/minnow*
ls: cannot access drivers/platform/x86/minnow*: No such file or directory




$ git rev-parse meta
7fc16a9dc80bfdb8ebde9ba0f153e70e0c1f5f44

$ git rev-parse HEAD
7fc16a9dc80bfdb8ebde9ba0f153e70e0c1f5f44


# Sorry about this... Ugly :-)
$ grep drivers/platform/x86/minnowboard
meta/cfg/kernel-cache/features/minnow-io/*patch | cut -f2 -d ' ' | grep
minnow | grep -ve ^b | sort | uniq
drivers/platform/x86/minnowboard-gpio.c
drivers/platform/x86/minnowboard-gpio.h
drivers/platform/x86/minnowboard-keys.c
drivers/platform/x86/minnowboard.c



So as far as I can tell, the minnow-io patches only exist in the minnow-io
feature and have not been applied to standard/ltsi.

Am I missing something?

--
Darren



Bruce




 I see the standard/base and standard/ltsi branches are at the same
 commit
 ID. What is the expected usage here? If you want LTSI, are you
expected
 to
 specify standard/ltsi? Or is that just a staging branch, and
everything
 can be assumed to have the contents of LTSI? (The latter was my
 expectation, but I wanted to be sure).

 All branches have LTSI contained with them, so you can use any branch
 in the tree and be assured that you have LTSI + anything extra on the
 branch, but definitely an exact superset of LTSI.

 So yep, you have it right, standard/ltsi is just where I staged the
LTSI
 integration, and where I'll merge any updates to it.

 Ack, thanks.





-- 
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] LTSI for 3.10 - Standard Practice

On 2/11/2014, 7:26 PM, Hart, Darren wrote:

On 2/11/14, 16:11, Bruce Ashfield bruce.ashfi...@windriver.com wrote:

On 2/11/2014, 7:06 PM, Hart, Darren wrote:

On 2/11/14, 16:04, Bruce Ashfield bruce.ashfi...@gmail.com wrote:

On Tue, Feb 11, 2014 at 5:50 PM, Hart, Darren darren.h...@intel.com
wrote:

Bruce,

While looking to update the MinnowBoard dora BSP I noticed that the
minnow
platform drivers Greg added to LTSI were not in standard/ltsi. Did you
drop those in favor of the minnow-io feature?

standard/ltsi is applied on top of the standard branch contents, and
since
we already had the minnow io features in there, I checked the patches
and went with the ones already in the standard branch.

Ah, but I'm talking about minnow-io, which is not in the standard
branch,
it exists only in features/minnow-io (and greg's LTSI, but not
standard/ltsi).

Look again. When I merged LTSI, I had a 1:1 conflict with
patches already applied. So you may think that features/minnow-io
wasn't applied .. but it was.

There are two things happening here.

1) The PCH_GBE and PCH_UART changes. Those were in standard/base and would
have conflicted with LTSI.

2) The non-upstream minnow-io (drivers/platform/x86/minnow*) drivers.
These are only in minnow-io, still.

$ git rev-parse standard/ltsi
e9cdab78bed262dbeadc7f403989f20972bcddde

$ git rev-parse HEAD
e9cdab78bed262dbeadc7f403989f20972bcddde

$ ls drivers/platform/x86/minnow*
ls: cannot access drivers/platform/x86/minnow*: No such file or directory

$ git rev-parse meta
7fc16a9dc80bfdb8ebde9ba0f153e70e0c1f5f44

$ git rev-parse HEAD
7fc16a9dc80bfdb8ebde9ba0f153e70e0c1f5f44

# Sorry about this... Ugly :-)
$ grep drivers/platform/x86/minnowboard
meta/cfg/kernel-cache/features/minnow-io/*patch | cut -f2 -d ' ' | grep
minnow | grep -ve ^b | sort | uniq
drivers/platform/x86/minnowboard-gpio.c
drivers/platform/x86/minnowboard-gpio.h
drivers/platform/x86/minnowboard-keys.c
drivers/platform/x86/minnowboard.c

So as far as I can tell, the minnow-io patches only exist in the minnow-io
feature and have not been applied to standard/ltsi.

Am I missing something?

Hmm. I hit a full 8 pack of conflicts and confirmed against the patches
I had available.

But thinking about that process, I was checking their existence in the
kernel-cache and may have assumed to much when I got deeper in the
conflicts .. maybe that's why I dislike unapplied patches so much ;)

Have a look at the kernel-cache, and this block of the series file:

##patches.minnowboard/pch_uart-use-dmi-interface-for-board-detection.patch
##patches.minnowboard/serial-pch_uart-remove-__initdata-annotation-from-dmi_table.patch
##patches.minnowboard/serial-pch_uart-fix-signed-ness-and-casting-of-uartclk-related-fields.patch
##patches.minnowboard/serial-pch_uart-fix-compilation-warning.patch
##patches.minnowboard/pch_gbe-convert-pr_-to-netdev_.patch
##patches.minnowboard/pch_gbe-use-managed-functions-pcim_-and-devm_.patch
##patches.minnowboard/pch_gbe-use-pch_gbe_phy_regs_len-instead-of-32.patch
##patches.minnowboard/pci-add-circuitco-vendor-id-and-subsystem-id.patch
##patches.minnowboard/pch_gbe-add-minnowboard-support.patch
##patches.minnowboard/0001-gpio-sch-Add-sch_gpio_resume_set_enable.patch
##patches.minnowboard/0002-minnowboard-Add-base-platform-driver-for-the-MinnowB.patch
##patches.minnowboard/0003-minnowboard-gpio-Export-MinnowBoard-expansion-GPIO.patch
##patches.minnowboard/0004-minnowboard-keys-Bind-MinnowBoard-buttons-to-arrow-k.patch

Which ones are you seeing that are missing ? I'll double check it myself
and pull in the missing ones.

Bruce

--
Darren

Bruce

I see the standard/base and standard/ltsi branches are at the same
commit
ID. What is the expected usage here? If you want LTSI, are you
expected
to
specify standard/ltsi? Or is that just a staging branch, and
everything
can be assumed to have the contents of LTSI? (The latter was my
expectation, but I wanted to be sure).

All branches have LTSI contained with them, so you can use any branch
in the tree and be assured that you have LTSI + anything extra on the
branch, but definitely an exact superset of LTSI.

So yep, you have it right, standard/ltsi is just where I staged the
LTSI
integration, and where I'll merge any updates to it.

Ack, thanks.

--
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] LTSI for 3.10 - Standard Practice

On 2/11/14, 16:32, Bruce Ashfield bruce.ashfi...@windriver.com wrote:

On 2/11/2014, 7:26 PM, Hart, Darren wrote:
 On 2/11/14, 16:11, Bruce Ashfield bruce.ashfi...@windriver.com
wrote:

 On 2/11/2014, 7:06 PM, Hart, Darren wrote:
 On 2/11/14, 16:04, Bruce Ashfield bruce.ashfi...@gmail.com wrote:

 On Tue, Feb 11, 2014 at 5:50 PM, Hart, Darren darren.h...@intel.com
 wrote:
 Bruce,

 While looking to update the MinnowBoard dora BSP I noticed that the
 minnow
 platform drivers Greg added to LTSI were not in standard/ltsi. Did
you
 drop those in favor of the minnow-io feature?

 standard/ltsi is applied on top of the standard branch contents, and
 since
 we already had the minnow io features in there, I checked the patches
 and went with the ones already in the standard branch.

 Ah, but I'm talking about minnow-io, which is not in the standard
 branch,
 it exists only in features/minnow-io (and greg's LTSI, but not
 standard/ltsi).

 Look again. When I merged LTSI, I had a 1:1 conflict with
 patches already applied. So you may think that features/minnow-io
 wasn't applied .. but it was.

 There are two things happening here.

 1) The PCH_GBE and PCH_UART changes. Those were in standard/base and
would
 have conflicted with LTSI.

 2) The non-upstream minnow-io (drivers/platform/x86/minnow*) drivers.
 These are only in minnow-io, still.

 $ git rev-parse standard/ltsi
 e9cdab78bed262dbeadc7f403989f20972bcddde

 $ git rev-parse HEAD
 e9cdab78bed262dbeadc7f403989f20972bcddde


 $ ls drivers/platform/x86/minnow*
 ls: cannot access drivers/platform/x86/minnow*: No such file or
directory




 $ git rev-parse meta
 7fc16a9dc80bfdb8ebde9ba0f153e70e0c1f5f44

 $ git rev-parse HEAD
 7fc16a9dc80bfdb8ebde9ba0f153e70e0c1f5f44


 # Sorry about this... Ugly :-)
 $ grep drivers/platform/x86/minnowboard
 meta/cfg/kernel-cache/features/minnow-io/*patch | cut -f2 -d ' ' | grep
 minnow | grep -ve ^b | sort | uniq
 drivers/platform/x86/minnowboard-gpio.c
 drivers/platform/x86/minnowboard-gpio.h
 drivers/platform/x86/minnowboard-keys.c
 drivers/platform/x86/minnowboard.c



 So as far as I can tell, the minnow-io patches only exist in the
minnow-io
 feature and have not been applied to standard/ltsi.

 Am I missing something?

Hmm. I hit a full 8 pack of conflicts and confirmed against the patches
I had available.

But thinking about that process, I was checking their existence in the
kernel-cache and may have assumed to much when I got deeper in the
conflicts .. maybe that's why I dislike unapplied patches so much ;)

Have a look at the kernel-cache, and this block of the series file:

##patches.minnowboard/pch_uart-use-dmi-interface-for-board-detection.patch
##patches.minnowboard/serial-pch_uart-remove-__initdata-annotation-from-dm
i_table.patch
##patches.minnowboard/serial-pch_uart-fix-signed-ness-and-casting-of-uartc
lk-related-fields.patch
##patches.minnowboard/serial-pch_uart-fix-compilation-warning.patch
##patches.minnowboard/pch_gbe-convert-pr_-to-netdev_.patch
##patches.minnowboard/pch_gbe-use-managed-functions-pcim_-and-devm_.patch
##patches.minnowboard/pch_gbe-use-pch_gbe_phy_regs_len-instead-of-32.patch
##patches.minnowboard/pci-add-circuitco-vendor-id-and-subsystem-id.patch
##patches.minnowboard/pch_gbe-add-minnowboard-support.patch
##patches.minnowboard/0001-gpio-sch-Add-sch_gpio_resume_set_enable.patch
##patches.minnowboard/0002-minnowboard-Add-base-platform-driver-for-the-Mi
nnowB.patch
##patches.minnowboard/0003-minnowboard-gpio-Export-MinnowBoard-expansion-G
PIO.patch
##patches.minnowboard/0004-minnowboard-keys-Bind-MinnowBoard-buttons-to-ar
row-k.patch

Which ones are you seeing that are missing ? I'll double check it myself
and pull in the missing ones.

That would be the ones with the 000* prefix. Everything listed in
minnow-io.scc:

 cat meta/cfg/kernel-cache/features/minnow-io/minnow-io.scc
# Depends on EG20T and Tunnel Creek GPIO (LPC, SCH, etc.)
kconf hardware minnow-io.cfg

patch 0001-gpio-sch-Add-sch_gpio_resume_set_enable.patch
patch 0002-minnowboard-Add-base-platform-driver-for-the-MinnowB.patch
patch 0003-minnowboard-gpio-Export-MinnowBoard-expansion-GPIO.patch
patch 0004-minnowboard-keys-Bind-MinnowBoard-buttons-to-arrow-k.patch


If we add these to standard/ltsi, then we just need to drop the patches
from the minnow-io fragment. Of course they will need to stay in the
fragment for linux-yocto-dev as it won't have the LTSI bits and these
patches will not go upstream as they are placeholders until there is
proper device properties support in ACPI and the drivers can be updated to
use that.

If you prefer to leave these as patches in minnow-io.scc, I'm fine with
that and will keep the BSP files consistent across versions.

I just noticed the gap and wanted to make sure it was intentional. How
would you like to handle it?

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



___
linux-yocto mailing list

Re: [linux-yocto] [PATCH 1/1] meta: remove CONFIG_BYT_LPSS_BRD from valleyisland cfg file

On 2/11/14, 9:31, rebecca.swee.fun.ch...@intel.com
rebecca.swee.fun.ch...@intel.com wrote:

From: Chang, Rebecca Swee Fun rebecca.swee.fun.ch...@intel.com

Remove CONFIG_BYT_LPSS_BRD from valleyisland.cfg file.
CONFIG_BYT_LPSS_BRD is a duplicated config. It has been
included in features/valleyisland-io/valleyisland-io-pci.

Is it only relevant for the PCI enumeration? Seems to me it would be
needed for both PCI and ACPI until such time as ACPI Device Properties
lands in the ACPI 6.0 specification... Yes/no?

--
Darren


Signed-off-by: Chang, Rebecca Swee Fun rebecca.swee.fun.ch...@intel.com
---
 meta/cfg/kernel-cache/bsp/valleyisland/valleyisland.cfg |1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/cfg/kernel-cache/bsp/valleyisland/valleyisland.cfg
b/meta/cfg/kernel-cache/bsp/valleyisland/valleyisland.cfg
index 0e3a863..140a006 100644
--- a/meta/cfg/kernel-cache/bsp/valleyisland/valleyisland.cfg
+++ b/meta/cfg/kernel-cache/bsp/valleyisland/valleyisland.cfg
@@ -1,6 +1,5 @@
 CONFIG_MCORE2=y
 CONFIG_X86_INTEL_LPSS=y
-CONFIG_BYT_LPSS_BRD=y
 CONFIG_PRINTK=y
 CONFIG_PRINTK_TIME=y
 
-- 
1.7.10.4

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




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

Re: [linux-yocto] Manage utf8 into ext3 rootfs

From:  Cjb_SW Freescale cjb.sw.nos...@gmail.com
Date:  Tuesday, February 11, 2014 at 0:57
To:  linux-yocto linux-yocto@yoctoproject.org
Subject:  [linux-yocto] Manage utf8 into ext3 rootfs

Hi,
our kernel version is 2.6.35-3 from freescale for arm (imx53)

This isn't the list you are looking for then. This is in support of the
linux-yocto Linux kernel recipes. If you are looking for support for a
freescale provided kernel, please check the README/docs from the vendor
for the proper list/channel for support.

--
Darren

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

Re: [linux-yocto] [PATCH 1/1] meta: remove CONFIG_BYT_LPSS_BRD from valleyisland cfg file


On 2/11/14, 18:53, Chang, Rebecca Swee Fun
rebecca.swee.fun.ch...@intel.com wrote:

No, it is only needed in PCI mode device enumeration.

Huh... I guess I need to go review what all was in that board file. I
thought there was some hardware description in there ACPI wasn't yet
capable of describing. So the ACPI driver is able to setup the SPI bus,
for example?

Thanks Rebecca,

Darren

 -Original Message-
 From: Darren Hart [mailto:dvh...@linux.intel.com]
 Sent: 12 February, 2014 10:32 AM
 To: Chang, Rebecca Swee Fun; linux-yocto@yoctoproject.org
 Subject: Re: [linux-yocto] [PATCH 1/1] meta: remove
 CONFIG_BYT_LPSS_BRD from valleyisland cfg file
 
 On 2/11/14, 9:31, rebecca.swee.fun.ch...@intel.com
 rebecca.swee.fun.ch...@intel.com wrote:
 
 From: Chang, Rebecca Swee Fun rebecca.swee.fun.ch...@intel.com
 
 Remove CONFIG_BYT_LPSS_BRD from valleyisland.cfg file.
 CONFIG_BYT_LPSS_BRD is a duplicated config. It has been included in
 features/valleyisland-io/valleyisland-io-pci.
 
 Is it only relevant for the PCI enumeration? Seems to me it would be
needed
 for both PCI and ACPI until such time as ACPI Device Properties lands
in the
 ACPI 6.0 specification... Yes/no?
 
 --
 Darren
 
 
 Signed-off-by: Chang, Rebecca Swee Fun
 rebecca.swee.fun.ch...@intel.com
 ---
  meta/cfg/kernel-cache/bsp/valleyisland/valleyisland.cfg |1 -
  1 file changed, 1 deletion(-)
 
 diff --git a/meta/cfg/kernel-cache/bsp/valleyisland/valleyisland.cfg
 b/meta/cfg/kernel-cache/bsp/valleyisland/valleyisland.cfg
 index 0e3a863..140a006 100644
 --- a/meta/cfg/kernel-cache/bsp/valleyisland/valleyisland.cfg
 +++ b/meta/cfg/kernel-cache/bsp/valleyisland/valleyisland.cfg
 @@ -1,6 +1,5 @@
  CONFIG_MCORE2=y
  CONFIG_X86_INTEL_LPSS=y
 -CONFIG_BYT_LPSS_BRD=y
  CONFIG_PRINTK=y
  CONFIG_PRINTK_TIME=y
 
 --
 1.7.10.4
 
 ___
 linux-yocto mailing list
 linux-yocto@yoctoproject.org
 https://lists.yoctoproject.org/listinfo/linux-yocto
 
 
 





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

Re: [linux-yocto] [PATCH 1/1] meta: remove CONFIG_BYT_LPSS_BRD from valleyisland cfg file

2014-02-11 Thread Chang, Rebecca Swee Fun

Yes, ACPI driver is able to setup themselves. PCI mode drivers rely on the 
clock framework in the board file.
Therefore we need a board file in PCI driver setup.

 -Original Message-
 From: Darren Hart [mailto:dvh...@linux.intel.com]
 Sent: 12 February, 2014 10:59 AM
 To: Chang, Rebecca Swee Fun; linux-yocto@yoctoproject.org
 Subject: Re: [linux-yocto] [PATCH 1/1] meta: remove
 CONFIG_BYT_LPSS_BRD from valleyisland cfg file

 On 2/11/14, 18:53, Chang, Rebecca Swee Fun
 rebecca.swee.fun.ch...@intel.com wrote:

 No, it is only needed in PCI mode device enumeration.

 Huh... I guess I need to go review what all was in that board file. I thought
 there was some hardware description in there ACPI wasn't yet capable of
 describing. So the ACPI driver is able to setup the SPI bus, for example?

 Thanks Rebecca,

 Darren

  -Original Message-
  From: Darren Hart [mailto:dvh...@linux.intel.com]
  Sent: 12 February, 2014 10:32 AM
  To: Chang, Rebecca Swee Fun; linux-yocto@yoctoproject.org
  Subject: Re: [linux-yocto] [PATCH 1/1] meta: remove
  CONFIG_BYT_LPSS_BRD from valleyisland cfg file

  On 2/11/14, 9:31, rebecca.swee.fun.ch...@intel.com
  rebecca.swee.fun.ch...@intel.com wrote:

  From: Chang, Rebecca Swee Fun rebecca.swee.fun.ch...@intel.com

  Remove CONFIG_BYT_LPSS_BRD from valleyisland.cfg file.
  CONFIG_BYT_LPSS_BRD is a duplicated config. It has been included in
  features/valleyisland-io/valleyisland-io-pci.

  Is it only relevant for the PCI enumeration? Seems to me it would be
 needed  for both PCI and ACPI until such time as ACPI Device
 Properties lands in the  ACPI 6.0 specification... Yes/no?

  --
  Darren

  Signed-off-by: Chang, Rebecca Swee Fun
  rebecca.swee.fun.ch...@intel.com
  ---
   meta/cfg/kernel-cache/bsp/valleyisland/valleyisland.cfg |1 -
   1 file changed, 1 deletion(-)

  diff --git a/meta/cfg/kernel-cache/bsp/valleyisland/valleyisland.cfg
  b/meta/cfg/kernel-cache/bsp/valleyisland/valleyisland.cfg
  index 0e3a863..140a006 100644
  --- a/meta/cfg/kernel-cache/bsp/valleyisland/valleyisland.cfg
  +++ b/meta/cfg/kernel-cache/bsp/valleyisland/valleyisland.cfg
  @@ -1,6 +1,5 @@
   CONFIG_MCORE2=y
   CONFIG_X86_INTEL_LPSS=y
  -CONFIG_BYT_LPSS_BRD=y
   CONFIG_PRINTK=y
   CONFIG_PRINTK_TIME=y

  --
  1.7.10.4

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

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

Re: [linux-yocto] [PATCH 1/1] meta: remove CONFIG_BYT_LPSS_BRD from valleyisland cfg file

On 2/11/14, 19:07, Chang, Rebecca Swee Fun
rebecca.swee.fun.ch...@intel.com wrote:

Yes, ACPI driver is able to setup themselves. PCI mode drivers rely on
the clock framework in the board file.
Therefore we need a board file in PCI driver setup.

I'll review the board file and might have some additional questions we can
discuss separately.

Thanks,

Darren


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

Re: [linux-yocto] LTSI for 3.10 - Standard Practice


On 2/11/2014, 7:38 PM, Hart, Darren wrote:

On 2/11/14, 16:32, Bruce Ashfield bruce.ashfi...@windriver.com wrote:


On 2/11/2014, 7:26 PM, Hart, Darren wrote:

On 2/11/14, 16:11, Bruce Ashfield bruce.ashfi...@windriver.com
wrote:


On 2/11/2014, 7:06 PM, Hart, Darren wrote:

On 2/11/14, 16:04, Bruce Ashfield bruce.ashfi...@gmail.com wrote:


On Tue, Feb 11, 2014 at 5:50 PM, Hart, Darren darren.h...@intel.com
wrote:

Bruce,

While looking to update the MinnowBoard dora BSP I noticed that the
minnow
platform drivers Greg added to LTSI were not in standard/ltsi. Did
you
drop those in favor of the minnow-io feature?


standard/ltsi is applied on top of the standard branch contents, and
since
we already had the minnow io features in there, I checked the patches
and went with the ones already in the standard branch.


Ah, but I'm talking about minnow-io, which is not in the standard
branch,
it exists only in features/minnow-io (and greg's LTSI, but not
standard/ltsi).


Look again. When I merged LTSI, I had a 1:1 conflict with
patches already applied. So you may think that features/minnow-io
wasn't applied .. but it was.


There are two things happening here.

1) The PCH_GBE and PCH_UART changes. Those were in standard/base and
would
have conflicted with LTSI.

2) The non-upstream minnow-io (drivers/platform/x86/minnow*) drivers.
These are only in minnow-io, still.

$ git rev-parse standard/ltsi
e9cdab78bed262dbeadc7f403989f20972bcddde

$ git rev-parse HEAD
e9cdab78bed262dbeadc7f403989f20972bcddde


$ ls drivers/platform/x86/minnow*
ls: cannot access drivers/platform/x86/minnow*: No such file or
directory




$ git rev-parse meta
7fc16a9dc80bfdb8ebde9ba0f153e70e0c1f5f44

$ git rev-parse HEAD
7fc16a9dc80bfdb8ebde9ba0f153e70e0c1f5f44


# Sorry about this... Ugly :-)
$ grep drivers/platform/x86/minnowboard
meta/cfg/kernel-cache/features/minnow-io/*patch | cut -f2 -d ' ' | grep
minnow | grep -ve ^b | sort | uniq
drivers/platform/x86/minnowboard-gpio.c
drivers/platform/x86/minnowboard-gpio.h
drivers/platform/x86/minnowboard-keys.c
drivers/platform/x86/minnowboard.c



So as far as I can tell, the minnow-io patches only exist in the
minnow-io
feature and have not been applied to standard/ltsi.

Am I missing something?


Hmm. I hit a full 8 pack of conflicts and confirmed against the patches
I had available.

But thinking about that process, I was checking their existence in the
kernel-cache and may have assumed to much when I got deeper in the
conflicts .. maybe that's why I dislike unapplied patches so much ;)

Have a look at the kernel-cache, and this block of the series file:

##patches.minnowboard/pch_uart-use-dmi-interface-for-board-detection.patch
##patches.minnowboard/serial-pch_uart-remove-__initdata-annotation-from-dm
i_table.patch
##patches.minnowboard/serial-pch_uart-fix-signed-ness-and-casting-of-uartc
lk-related-fields.patch
##patches.minnowboard/serial-pch_uart-fix-compilation-warning.patch
##patches.minnowboard/pch_gbe-convert-pr_-to-netdev_.patch
##patches.minnowboard/pch_gbe-use-managed-functions-pcim_-and-devm_.patch
##patches.minnowboard/pch_gbe-use-pch_gbe_phy_regs_len-instead-of-32.patch
##patches.minnowboard/pci-add-circuitco-vendor-id-and-subsystem-id.patch
##patches.minnowboard/pch_gbe-add-minnowboard-support.patch
##patches.minnowboard/0001-gpio-sch-Add-sch_gpio_resume_set_enable.patch
##patches.minnowboard/0002-minnowboard-Add-base-platform-driver-for-the-Mi
nnowB.patch
##patches.minnowboard/0003-minnowboard-gpio-Export-MinnowBoard-expansion-G
PIO.patch
##patches.minnowboard/0004-minnowboard-keys-Bind-MinnowBoard-buttons-to-ar
row-k.patch

Which ones are you seeing that are missing ? I'll double check it myself
and pull in the missing ones.


That would be the ones with the 000* prefix. Everything listed in
minnow-io.scc:

  cat meta/cfg/kernel-cache/features/minnow-io/minnow-io.scc
# Depends on EG20T and Tunnel Creek GPIO (LPC, SCH, etc.)
kconf hardware minnow-io.cfg

patch 0001-gpio-sch-Add-sch_gpio_resume_set_enable.patch
patch 0002-minnowboard-Add-base-platform-driver-for-the-MinnowB.patch
patch 0003-minnowboard-gpio-Export-MinnowBoard-expansion-GPIO.patch
patch 0004-minnowboard-keys-Bind-MinnowBoard-buttons-to-arrow-k.patch


Right, I had left these as an on demand feature in the kernel-cache,
but I'd rather have them integrated to avoid mistakes like this in
the future.




If we add these to standard/ltsi, then we just need to drop the patches
from the minnow-io fragment. Of course they will need to stay in the
fragment for linux-yocto-dev as it won't have the LTSI bits and these
patches will not go upstream as they are placeholders until there is
proper device properties support in ACPI and the drivers can be updated to
use that.

If you prefer to leave these as patches in minnow-io.scc, I'm fine with
that and will keep the BSP files consistent across versions.


I've added the 4 missing patches to standard/ltsi and then merged that
to all the branches. I've also commented out the

Re: [linux-yocto] LTSI for 3.10 - Standard Practice