Re: [linux-yocto] [PATCH 0/4] mmc backports for linux-yocto-4.4 standard/base and standard/intel

[Bruce Ashfield]

On 2016-06-03 01:39 PM, Sullivan, California L wrote:

It looks like "mmc: sdhci-pci: Remove MMC_CAP_BUS_WIDTH_TEST for Intel
controller" was brought in by the 4.4.12 update. Drop that one and they
should apply.


Cool. thanks for the confirmation, I had skipped it before, but wanted
a second opinion.

I've staged these now.

Bruce



Thanks,
Cal


On 06/03/2016 09:17 AM, Bruce Ashfield wrote:

On 2016-06-02 11:08 PM, California Sullivan wrote:

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

Are the patches on the branch different than the patches to the list ?
I grabbed the patches in email, and I have rejects with "already applied
changes".

Maybe standard/base changed since you made the series ? If you could double
check and let me know, that would be great.

Bruce


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







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

Re: [linux-yocto] [PATCH 0/4] mmc backports for linux-yocto-4.4 standard/base and standard/intel

[Sullivan, California L]

It looks like "mmc: sdhci-pci: Remove MMC_CAP_BUS_WIDTH_TEST for Intel
controller" was brought in by the 4.4.12 update. Drop that one and they
should apply.

Thanks,
Cal


On 06/03/2016 09:17 AM, Bruce Ashfield wrote:
> On 2016-06-02 11:08 PM, California Sullivan wrote:
>> 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
> Are the patches on the branch different than the patches to the list ?
> I grabbed the patches in email, and I have rejects with "already applied
> changes".
>
> Maybe standard/base changed since you made the series ? If you could double
> check and let me know, that would be great.
>
> Bruce
>
>> 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(-)
>>
>

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

[California Sullivan]

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(>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(>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 2/4] mmc: block: Pause re-tuning while switched to the RPMB partition

[California Sullivan]

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 4/4] mmc: sdhci-pci: Remove MMC_CAP_BUS_WIDTH_TEST for Intel controller

[California Sullivan]

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

Re: [linux-yocto] [PULL REQUEST] add standard/bxt-rebase branch

[Bruce Ashfield]

On 2016-06-03 10:12 AM, Tom Zanussi wrote:

On 06/02/2016 11:25 PM, Tom Zanussi wrote:

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



OK, I've posted the meta-intel patches, so ready to go there...


the branch renames are also done.



Tom


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

Re: [linux-yocto] [PULL REQUEST] add standard/bxt-rebase branch

[Tom Zanussi]

On 06/02/2016 11:25 PM, Tom Zanussi wrote:
> 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..
> 

OK, I've posted the meta-intel patches, so ready to go there...

Tom

> 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 

Re: [linux-yocto] [PATCH] ARM: dts: am335x-boneblack: configure i2c1 and 2

[Bruce Ashfield]

On 2016-06-03 4:36 AM, Li, Yong B wrote:

Hi Bruce,

Please help to send me a note when you merged the i2c patch, I will discard the 
local patch files in Ostro OS.



It is merged, SRCREV updates will follow later. You can set your own
REVs to see the change.

Bruce


Thanks,
Yong
-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Thursday, June 2, 2016 8:07 PM
To: Li, Yong B ; Yong Li 
Cc: linux-yocto@yoctoproject.org; s...@linux.intel.com; Wold, Saul 

Subject: Re: [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/00
0 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