Re: [linux-yocto] [PULL REQUEST] add standard/bxt-rebase branch
On 06/02/2016 07:19 PM, Bruce Ashfield wrote: > On 2016-06-01 5:03 PM, Tom Zanussi wrote: >> On 06/01/2016 12:50 PM, Tom Zanussi wrote: >>> On 06/01/2016 12:24 PM, Bruce Ashfield wrote: On 2016-06-01 1:21 PM, Tom Zanussi wrote: > On 06/01/2016 11:57 AM, Bruce Ashfield wrote: >> On 2016-06-01 12:56 PM, Tom Zanussi wrote: >>> On 06/01/2016 11:50 AM, Bruce Ashfield wrote: On 2016-06-01 11:36 AM, Saul Wold wrote: > On Tue, 2016-05-31 at 23:31 -0400, Bruce Ashfield wrote: >> >> On 2016-05-31 6:24 PM, Ranostay, Matt wrote: >>> >>> >>> This pull request is for adding the standard/bxt-rebase >>> branch with >>> has various backports from 4.6 and 4.5, which are have an >>> unacceptable risk of breaking other platforms. >>> This is based on standard/intel and will be rebased. Thus nobody >>> should expect the history to be linear. >> Seems sane to me. >> >> One minor question though. To keep the branch naming and >> inheritance >> sane, I'd create this as standard/intel/bxt-rebase >> >> Any objections ? >> > This is actually what I had asked for (standard/intel/bxt-rebase) > so no > objections here. And crap. I wasn't thinking clearly when I created standard/intel, that now needs to become standard/intel/base. We'll run into the git fetch not being able to update local copies of the repo (unless they are full cleared). I typically do create these as /base .. but forgot this time. Tom: we need to coordinate KBRANCH updates .. how did you want to do that ? >>> >>> Hmm, I thought the plan was to have a standard/intel based on >>> standard/base, which is what we have... >>> >>> All this rebase stuff should be based on standard/intel, right? >> >> Yep, and if we want to show that inheritance properly, it shouldbve >> standard/intel/ .. that's the kicker. >> > > So why can't we do something like standard/intel-rebase-branch > based on > standard/intel and avoid the problem, since these are supposed to be > temporary one-off staging branches anyway? I could live with standard/intel-rebase, it doesn't exactly match the inheritance notation .. but it is close enough. >>> >>> I think that's fine - the original intent was to have standard/intel, >>> standard/preempt/intel, etc, be THE common Intel branches for all (or >>> all who wanted to be) Intel BSPs to be based off of. >>> >>> It wasn't until later that it became apparent that some BSPs would >>> temporarily have a need for even more half-baked patches than could even >>> go into standard/*/intel, and the -rebase idea was introduced. >>> >>> So to me it doesn't seem appropriate for the half-baked stuff to drive >>> the overall cleanliness of the branch layout... But then it's not up to >>> me - the whole scheme was introduced to make it easier to satisfy our >>> 'customers' who would benefit from the more timely (if possibly >>> less-baked) platform support. If anyone objects to the intel-rebase vs >>> intel/rebase scheme, please speak up... >>> >> >> Actually, we also still need to do this for 4.6 now too. Considering >> that, and that we're going to run into the same git fetch problem in >> that case anyway, we might as well make it all completely consistent and >> do the standard/intel/base version throughout. >> >> If that works, Bruce, I can create a series to do that for all the >> kernel versions (4.1, 4.4, and 4.6). Make sense? > > Just so I don't drop the ball on this. We might both be waiting for > the other :D > > I can rename the branches at any time, since there aren't any references > to standard/intel in the recipes, we won't have a KBRANCH conflict. > > The kernel-cache shouldn't even need any changes, since the tools know > how to handle foo and foo/base as the same thing. > Right, I've updated the meta-intel bbappends locally and was doing some build-testing here, and will need to again update the krogoth linux-yocto-rt, but yeah, if you can go ahead and do the renames, I can take care of the rest tomorrow.. Tom > Cheers, > > Bruce > >> >> Tom >> >> >>> Tom >>> >>> I've made a note to generate all future repos with /base Bruce > > Tom > >> Bruce >> >>> >>> Tom >>> >>> Bruce > > Sau! > >> >> Bruce >> >>> >>> >>> >>> The following changes since commit >>> 53e84104c5e68eb468823dd0d262a64623d01a55: >>> >>> mmc: mmc: Fix partition switch timeout for some eMMCs >>> (2016-05- >>> 19 >>> 17:15:25 -0700) >>> >>> are available in t
Re: [linux-yocto] [PULL REQUEST] add standard/bxt-rebase branch
On 2016-06-01 5:03 PM, Tom Zanussi wrote: On 06/01/2016 12:50 PM, Tom Zanussi wrote: On 06/01/2016 12:24 PM, Bruce Ashfield wrote: On 2016-06-01 1:21 PM, Tom Zanussi wrote: On 06/01/2016 11:57 AM, Bruce Ashfield wrote: On 2016-06-01 12:56 PM, Tom Zanussi wrote: On 06/01/2016 11:50 AM, Bruce Ashfield wrote: On 2016-06-01 11:36 AM, Saul Wold wrote: On Tue, 2016-05-31 at 23:31 -0400, Bruce Ashfield wrote: On 2016-05-31 6:24 PM, Ranostay, Matt wrote: This pull request is for adding the standard/bxt-rebase branch with has various backports from 4.6 and 4.5, which are have an unacceptable risk of breaking other platforms. This is based on standard/intel and will be rebased. Thus nobody should expect the history to be linear. Seems sane to me. One minor question though. To keep the branch naming and inheritance sane, I'd create this as standard/intel/bxt-rebase Any objections ? This is actually what I had asked for (standard/intel/bxt-rebase) so no objections here. And crap. I wasn't thinking clearly when I created standard/intel, that now needs to become standard/intel/base. We'll run into the git fetch not being able to update local copies of the repo (unless they are full cleared). I typically do create these as /base .. but forgot this time. Tom: we need to coordinate KBRANCH updates .. how did you want to do that ? Hmm, I thought the plan was to have a standard/intel based on standard/base, which is what we have... All this rebase stuff should be based on standard/intel, right? Yep, and if we want to show that inheritance properly, it shouldbve standard/intel/ .. that's the kicker. So why can't we do something like standard/intel-rebase-branch based on standard/intel and avoid the problem, since these are supposed to be temporary one-off staging branches anyway? I could live with standard/intel-rebase, it doesn't exactly match the inheritance notation .. but it is close enough. I think that's fine - the original intent was to have standard/intel, standard/preempt/intel, etc, be THE common Intel branches for all (or all who wanted to be) Intel BSPs to be based off of. It wasn't until later that it became apparent that some BSPs would temporarily have a need for even more half-baked patches than could even go into standard/*/intel, and the -rebase idea was introduced. So to me it doesn't seem appropriate for the half-baked stuff to drive the overall cleanliness of the branch layout... But then it's not up to me - the whole scheme was introduced to make it easier to satisfy our 'customers' who would benefit from the more timely (if possibly less-baked) platform support. If anyone objects to the intel-rebase vs intel/rebase scheme, please speak up... Actually, we also still need to do this for 4.6 now too. Considering that, and that we're going to run into the same git fetch problem in that case anyway, we might as well make it all completely consistent and do the standard/intel/base version throughout. If that works, Bruce, I can create a series to do that for all the kernel versions (4.1, 4.4, and 4.6). Make sense? Just so I don't drop the ball on this. We might both be waiting for the other :D I can rename the branches at any time, since there aren't any references to standard/intel in the recipes, we won't have a KBRANCH conflict. The kernel-cache shouldn't even need any changes, since the tools know how to handle foo and foo/base as the same thing. Cheers, Bruce Tom Tom I've made a note to generate all future repos with /base Bruce Tom Bruce Tom Bruce Sau! Bruce The following changes since commit 53e84104c5e68eb468823dd0d262a64623d01a55: mmc: mmc: Fix partition switch timeout for some eMMCs (2016-05- 19 17:15:25 -0700) are available in the git repository at: git://sandbox.sakoman.com/linux-yocto-4.4.git standard/bxt-rebase for you to fetch changes up to 1203930e034957e1fc9e0c4842ecd7922d5e0897: [UPSTREAM] ASoC: skylake: added WARN_ON invalid dsp (2016-05-27 17:21:19 -0700) Aaron Plattner (1): ALSA: hda - Add new GPU codec ID 0x10de0083 to snd-hda Adrian Hunter (4): mmc: core: Add a facility to "pause" re-tuning mmc: block: Pause re-tuning while switched to the RPMB partition mmc: block: Always switch back to main area after RPMB access mmc: sdhci-pci: Remove MMC_CAP_BUS_WIDTH_TEST for Intel controller Alan (1): ASoC: Intel: Skylake: fix pointer scaling Alan Cox (1): ASoC: Intel: Skylake: remove bogus comparison of an array with NULL Alex Dai (2): drm/i915/guc: Add GuC css header parser drm/i915/guc: Clean up locks in GuC Alex Goins (2): i915: wait for fence in mmio_flip_work_func i915: wait for fence in prepare_plane_fb Ander Conselvan de Oliveira (10): drm/i915: Don't pass *DP around to link training functions drm/i915: Split write of pattern to DP reg from intel_d
[linux-yocto] [PATCH 3/4] mmc: core: Add a facility to "pause" re-tuning
From: Adrian Hunter
commit 7ff2760999a86e4d2b1af93dcf0f0d336c309571 upstream.
Re-tuning is not possible when switched to the RPMB
partition. However re-tuning should not be needed
if re-tuning is done immediately before switching,
a small set of operations is done, and then we
immediately switch back to the main partition.
To ensure that re-tuning can't be done for a short
while, add a facility to "pause" re-tuning.
The existing facility to hold / release re-tuning
is used but it also flags re-tuning as needed to cause
re-tuning before the next command (which will be the
switch to RPMB).
We also need to "unpause" in the recovery path, which
is catered for by adding it to mmc_retune_disable().
Signed-off-by: Adrian Hunter
Signed-off-by: Ulf Hansson
Signed-off-by: California Sullivan
---
drivers/mmc/core/host.c | 24
include/linux/mmc/host.h | 4
2 files changed, 28 insertions(+)
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index da950c4..e11a66d 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -69,8 +69,32 @@ void mmc_retune_enable(struct mmc_host *host)
jiffies + host->retune_period * HZ);
}
+/*
+ * Pause re-tuning for a small set of operations. The pause begins after the
+ * next command and after first doing re-tuning.
+ */
+void mmc_retune_pause(struct mmc_host *host)
+{
+ if (!host->retune_paused) {
+ host->retune_paused = 1;
+ mmc_retune_needed(host);
+ mmc_retune_hold(host);
+ }
+}
+EXPORT_SYMBOL(mmc_retune_pause);
+
+void mmc_retune_unpause(struct mmc_host *host)
+{
+ if (host->retune_paused) {
+ host->retune_paused = 0;
+ mmc_retune_release(host);
+ }
+}
+EXPORT_SYMBOL(mmc_retune_unpause);
+
void mmc_retune_disable(struct mmc_host *host)
{
+ mmc_retune_unpause(host);
host->can_retune = 0;
del_timer_sync(&host->retune_timer);
host->retune_now = 0;
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 8673ffe..fb8e351 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -316,6 +316,7 @@ struct mmc_host {
unsigned intcan_retune:1; /* re-tuning can be used */
unsigned intdoing_retune:1; /* re-tuning in progress */
unsigned intretune_now:1; /* do re-tuning at next req */
+ unsigned intretune_paused:1; /* re-tuning is temporarily
disabled */
int rescan_disable; /* disable card detection */
int rescan_entered; /* used with nonremovable
devices */
@@ -515,4 +516,7 @@ static inline void mmc_retune_recheck(struct mmc_host *host)
host->retune_now = 1;
}
+void mmc_retune_pause(struct mmc_host *host);
+void mmc_retune_unpause(struct mmc_host *host);
+
#endif /* LINUX_MMC_HOST_H */
--
2.5.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 2/4] mmc: block: Pause re-tuning while switched to the RPMB partition
From: Adrian Hunter
commit 57da0c042f4af52614f4bd1a148155a299ae5cd8 upstream.
Re-tuning is not possible when switched to the RPMB
partition. However re-tuning should not be needed
if re-tuning is done immediately before switching,
a small set of operations is done, and then we
immediately switch back to the main partition.
A previous patch ensured that we immediately switch
back to the main partition.
This patch uses the new facility to "pause" re-tuning
before switching to the RPMB partition, and to "unpause"
it after switching from the RPMB partition.
Signed-off-by: Adrian Hunter
Signed-off-by: Ulf Hansson
Signed-off-by: California Sullivan
---
drivers/mmc/card/block.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index cbc4211..6e4b26e 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -760,16 +760,25 @@ static inline int mmc_blk_part_switch(struct mmc_card
*card,
if (mmc_card_mmc(card)) {
u8 part_config = card->ext_csd.part_config;
+ if (md->part_type == EXT_CSD_PART_CONFIG_ACC_RPMB)
+ mmc_retune_pause(card->host);
+
part_config &= ~EXT_CSD_PART_CONFIG_ACC_MASK;
part_config |= md->part_type;
ret = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
EXT_CSD_PART_CONFIG, part_config,
card->ext_csd.part_time);
- if (ret)
+ if (ret) {
+ if (md->part_type == EXT_CSD_PART_CONFIG_ACC_RPMB)
+ mmc_retune_unpause(card->host);
return ret;
+ }
card->ext_csd.part_config = part_config;
+
+ if (main_md->part_curr == EXT_CSD_PART_CONFIG_ACC_RPMB)
+ mmc_retune_unpause(card->host);
}
main_md->part_curr = md->part_type;
--
2.5.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 1/4] mmc: block: Always switch back to main area after RPMB access
From: Adrian Hunter commit 3c866568aff7dcfc0bbd5ffc7fcc34fa8f100f67 upstream. In preparation to support the use of the RPMB partition with transfer modes that might require re-tuning, always switch back to the main area after RPMB access. RPMB is accessible only via IOCTL so only those paths are affected. Signed-off-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: California Sullivan --- drivers/mmc/card/block.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c index 553113e..cbc4211 100644 --- a/drivers/mmc/card/block.c +++ b/drivers/mmc/card/block.c @@ -624,6 +624,10 @@ static int mmc_blk_ioctl_cmd(struct block_device *bdev, ioc_err = __mmc_blk_ioctl_cmd(card, md, idata); + /* Always switch back to main area after RPMB access */ + if (md->area_type & MMC_BLK_DATA_AREA_RPMB) + mmc_blk_part_switch(card, dev_get_drvdata(&card->dev)); + mmc_put_card(card); err = mmc_blk_ioctl_copy_to_user(ic_ptr, idata); @@ -689,6 +693,10 @@ static int mmc_blk_ioctl_multi_cmd(struct block_device *bdev, for (i = 0; i < num_of_cmds && !ioc_err; i++) ioc_err = __mmc_blk_ioctl_cmd(card, md, idata[i]); + /* Always switch back to main area after RPMB access */ + if (md->area_type & MMC_BLK_DATA_AREA_RPMB) + mmc_blk_part_switch(card, dev_get_drvdata(&card->dev)); + mmc_put_card(card); /* copy to user if data and response */ -- 2.5.5 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 4/4] mmc: sdhci-pci: Remove MMC_CAP_BUS_WIDTH_TEST for Intel controller
From: Adrian Hunter
commit 822969369482166050c5b2f7013501505e025c39 upstream.
CMD19/CMD14 bus width test has been found to be unreliable in
some cases. It is not essential, so simply remove it.
Signed-off-by: Adrian Hunter
Cc: sta...@vger.kernel.org
Signed-off-by: California Sullivan
---
drivers/mmc/host/sdhci-pci-core.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/mmc/host/sdhci-pci-core.c
b/drivers/mmc/host/sdhci-pci-core.c
index adbc1a7..04096ff 100644
--- a/drivers/mmc/host/sdhci-pci-core.c
+++ b/drivers/mmc/host/sdhci-pci-core.c
@@ -361,7 +361,6 @@ static int byt_emmc_probe_slot(struct sdhci_pci_slot *slot)
{
slot->host->mmc->caps |= MMC_CAP_8_BIT_DATA | MMC_CAP_NONREMOVABLE |
MMC_CAP_HW_RESET | MMC_CAP_1_8V_DDR |
-MMC_CAP_BUS_WIDTH_TEST |
MMC_CAP_WAIT_WHILE_BUSY;
slot->host->mmc->caps2 |= MMC_CAP2_HC_ERASE_SZ;
slot->hw_reset = sdhci_pci_int_hw_reset;
@@ -377,15 +376,13 @@ static int byt_emmc_probe_slot(struct sdhci_pci_slot
*slot)
static int byt_sdio_probe_slot(struct sdhci_pci_slot *slot)
{
slot->host->mmc->caps |= MMC_CAP_POWER_OFF_CARD | MMC_CAP_NONREMOVABLE |
-MMC_CAP_BUS_WIDTH_TEST |
MMC_CAP_WAIT_WHILE_BUSY;
return 0;
}
static int byt_sd_probe_slot(struct sdhci_pci_slot *slot)
{
- slot->host->mmc->caps |= MMC_CAP_BUS_WIDTH_TEST |
-MMC_CAP_WAIT_WHILE_BUSY;
+ slot->host->mmc->caps |= MMC_CAP_WAIT_WHILE_BUSY;
slot->cd_con_id = NULL;
slot->cd_idx = 0;
slot->cd_override_level = true;
--
2.5.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 0/4] mmc backports for linux-yocto-4.4 standard/base and standard/intel
Hi Bruce, This set of backports solves some issues we are seeing with mmc on Broxton-based boards. I also tested the updated kernel on a MinnowBoard Turbot and found no additional errors. These commits can also be pulled from git://git.yoctoproject.org/linux-yocto-contrib branch clsulliv/standard/base Thanks, Cal Sullivan Adrian Hunter (4): mmc: block: Always switch back to main area after RPMB access mmc: block: Pause re-tuning while switched to the RPMB partition mmc: core: Add a facility to "pause" re-tuning mmc: sdhci-pci: Remove MMC_CAP_BUS_WIDTH_TEST for Intel controller drivers/mmc/card/block.c | 19 ++- drivers/mmc/core/host.c | 24 drivers/mmc/host/sdhci-pci-core.c | 5 + include/linux/mmc/host.h | 4 4 files changed, 47 insertions(+), 5 deletions(-) -- 2.5.5 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH] meta: add efi-ext into common-pc-64.scc
On 5/30/16, 11:03 AM, "Bruce Ashfield" wrote: >On 2016-05-27 07:51 PM, Jianxun Zhang wrote: >> Sync up with 32 bit common-pc variant to bring EFI >> framebuffer driver into 64 bit PC config. >> >> [YOCTO #9653] >> >> Signed-off-by: Jianxun Zhang >> --- >> This patch is for Fido (3.14 kernel). We could have another one to >> kernel cache once it is accepted. Basic test done with sato and >> lsb-sdk images on Fido. > >this looks fine to me. Feel free to send kernel-cache patches for >other kernel versions. > >I've merged this to 3.14 meta. Bruce, could you confirm the merging? We don’t see it in 3.14 meta today. I will submit patches to other kernel versions too. Thanks! > >Bruce > >> >> meta/cfg/kernel-cache/bsp/common-pc-64/common-pc-64.scc | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/meta/cfg/kernel-cache/bsp/common-pc-64/common-pc-64.scc >> b/meta/cfg/kernel-cache/bsp/common-pc-64/common-pc-64.scc >> index 82f0f27..d9a4cfe 100644 >> --- a/meta/cfg/kernel-cache/bsp/common-pc-64/common-pc-64.scc >> +++ b/meta/cfg/kernel-cache/bsp/common-pc-64/common-pc-64.scc >> @@ -4,6 +4,8 @@ kconf hardware bsp/common-pc/common-pc-eth.cfg >> kconf hardware bsp/common-pc/common-pc-gfx.cfg >> kconf hardware bsp/common-pc/common-pc-wifi.cfg >> >> +include cfg/efi-ext.scc >> + >> include cfg/x86_64.scc >> include features/usb/ehci-hcd.scc >> include features/usb/uhci-hcd.scc >> > -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH] ARM: dts: am335x-boneblack: configure i2c1 and 2
On 06/01/2016 01:29 PM, Bruce Ashfield wrote: > On 2016-05-31 10:43 PM, Li, Yong B wrote: >> Thanks Nishanth for your information. I find the 5d1a2961adf9 commit in >> linux-omap. It seems to me that it only enables the I2C2 bus. Is it correct? >> We want to enable both the I2C1 and I2C2 buses for external i2c devices. >> > > As long as it works for what you need (i.e. you've tested it), and > the patch is from some public repo that I can refernece. I'm ok > with merging it. > >> Hi Bruce, the original source for the patch is >> https://github.com/nmenon/powertool/blob/master/kernel-patches/0001-v3.15.0-ARM-dts-am335x-boneblack-configure-i2c1-and-2.patch > > That's fine with me, can you update the commit log and re-submit the > patch ? Preferably with a short summary of how you tested the change > as well. the patch was created by me on an ancient kernel previously because there was no dt overlay support. neither i2c1 nor i2c2 are necessary for BBB to function. as the original author of the patch, I have to request a NAK. it was specifically done for a power measurement tool that i had written which runs on BBB (it uses i2c to read INA226 measurement IC) -- Regards, Nishanth Menon -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH] ARM: dts: am335x-boneblack: configure i2c1 and 2
On 2016-06-02 3:41 AM, Li, Yong B wrote: Hi Bruce, Since the patch is used for beaglebone black board, it should be merged into 4.1 kernel. I have tested the 0001-ARM-dts-Beaglebone-i2c-definitions.patch in Ostro OS(4.1.6), it works as expected(I2C0/I2C2 are okay). Aha. Thanks, I had gone back to find your original send and I thought it was against 4.1 .. I must have mis-read! Bruce Thanks, Yong -Original Message- From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] Sent: Thursday, June 2, 2016 10:51 AM To: Yong Li Cc: Nishanth Menon ; Li, Yong B ; linux-yocto@yoctoproject.org; s...@linux.intel.com; Wold, Saul Subject: Re: [PATCH] ARM: dts: am335x-boneblack: configure i2c1 and 2 On 2016-06-01 9:27 PM, Yong Li wrote: Thanks Nishanth! Hi Bruce, based on the discussion, please merge the 5d1a2961adf906f965b00eb8059fd2e0585e0e09 from git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git. While that is a better upstream reference, the patch didn't cherry pick cleanly into the 4.4 kernel. Have you tried that same cherry pick ? Regardless if the patch does come over cleanly, knowing that it worked in a run time test would be better. Bruce Regarding I2C1 support, let me try to find/submit another patch. Thanks, Yong 2016-06-02 3:22 GMT+08:00 Bruce Ashfield : On 2016-06-01 02:33 PM, Nishanth Menon wrote: On 06/01/2016 01:29 PM, Bruce Ashfield wrote: On 2016-05-31 10:43 PM, Li, Yong B wrote: Thanks Nishanth for your information. I find the 5d1a2961adf9 commit in linux-omap. It seems to me that it only enables the I2C2 bus. Is it correct? We want to enable both the I2C1 and I2C2 buses for external i2c devices. As long as it works for what you need (i.e. you've tested it), and the patch is from some public repo that I can refernece. I'm ok with merging it. Hi Bruce, the original source for the patch is https://github.com/nmenon/powertool/blob/master/kernel-patches/000 1-v3.15.0-ARM-dts-am335x-boneblack-configure-i2c1-and-2.patch That's fine with me, can you update the commit log and re-submit the patch ? Preferably with a short summary of how you tested the change as well. the patch was created by me on an ancient kernel previously because there was no dt overlay support. neither i2c1 nor i2c2 are necessary for BBB to function. as the original author of the patch, I have to request a NAK. it was specifically done for a power measurement tool that i had written which runs on BBB (it uses i2c to read INA226 measurement IC) Aha! Thanks for the history. We definitely want/need the modern support for the buses and addons. So I'll drop this merge. Bruce -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH] ARM: dts: am335x-boneblack: configure i2c1 and 2
Hi Bruce, Since the patch is used for beaglebone black board, it should be merged into 4.1 kernel. I have tested the 0001-ARM-dts-Beaglebone-i2c-definitions.patch in Ostro OS(4.1.6), it works as expected(I2C0/I2C2 are okay). Thanks, Yong -Original Message- From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] Sent: Thursday, June 2, 2016 10:51 AM To: Yong Li Cc: Nishanth Menon ; Li, Yong B ; linux-yocto@yoctoproject.org; s...@linux.intel.com; Wold, Saul Subject: Re: [PATCH] ARM: dts: am335x-boneblack: configure i2c1 and 2 On 2016-06-01 9:27 PM, Yong Li wrote: > Thanks Nishanth! > > Hi Bruce, based on the discussion, please merge the > 5d1a2961adf906f965b00eb8059fd2e0585e0e09 from > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git. While that is a better upstream reference, the patch didn't cherry pick cleanly into the 4.4 kernel. Have you tried that same cherry pick ? Regardless if the patch does come over cleanly, knowing that it worked in a run time test would be better. Bruce > > Regarding I2C1 support, let me try to find/submit another patch. > > Thanks, > Yong > > 2016-06-02 3:22 GMT+08:00 Bruce Ashfield : >> On 2016-06-01 02:33 PM, Nishanth Menon wrote: >>> >>> On 06/01/2016 01:29 PM, Bruce Ashfield wrote: On 2016-05-31 10:43 PM, Li, Yong B wrote: > > Thanks Nishanth for your information. I find the 5d1a2961adf9 > commit in linux-omap. It seems to me that it only enables the I2C2 bus. > Is it correct? > We want to enable both the I2C1 and I2C2 buses for external i2c devices. > As long as it works for what you need (i.e. you've tested it), and the patch is from some public repo that I can refernece. I'm ok with merging it. > Hi Bruce, the original source for the patch is > https://github.com/nmenon/powertool/blob/master/kernel-patches/000 > 1-v3.15.0-ARM-dts-am335x-boneblack-configure-i2c1-and-2.patch That's fine with me, can you update the commit log and re-submit the patch ? Preferably with a short summary of how you tested the change as well. >>> >>> >>> >>> the patch was created by me on an ancient kernel previously because >>> there was no dt overlay support. neither i2c1 nor i2c2 are necessary >>> for BBB to function. as the original author of the patch, I have to >>> request a NAK. it was specifically done for a power measurement tool >>> that i had written which runs on BBB (it uses i2c to read INA226 >>> measurement IC) >> >> >> Aha! Thanks for the history. >> >> We definitely want/need the modern support for the buses and addons. >> So I'll drop this merge. >> >> Bruce >> >>> >>> >> -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
