Date   

Re: [PATCH linux-4.4.y-cip v2 1/3] gitlab-ci: Split tests into separate jobs

Nobuhiro Iwamatsu
 

Hi all,

In another email, there is a discussion on how to manage the gitlab-ci.yaml file,
but I apply these patches and linux-4.19.y-cip as they are now needed for testing.

Best regards,
Nobuhiro

-----Original Message-----
From: cip-dev-bounces@...
[mailto:cip-dev-bounces@...] On Behalf Of Chris
Paterson
Sent: Monday, October 14, 2019 4:49 PM
To: cip-dev@...
Subject: [cip-dev] [PATCH linux-4.4.y-cip v2 1/3] gitlab-ci: Split tests
into separate jobs

This will allow tests to run as soon as the corresponding build job is
complete.

This will help spread the load on the test infrastructure and save time.

Signed-off-by: Chris Paterson <chris.paterson2@...>
---

v1 -> v2
* Added missing 'needs' entries

.gitlab-ci.yml | 62
+++++++++++++++++++++++++++++++++-----------------
1 file changed, 41 insertions(+), 21 deletions(-)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index
e33099ea6594..ad8ec722b717 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -4,8 +4,10 @@ variables:
DOCKER_DRIVER: overlay2
DOCKER_IMAGE_TAG: v2

-# Building
-arm_hitachi_omap_defconfig:
+###############################
+# Standard CIP configurations #
+###############################
+build:arm_hitachi_omap_defconfig:
stage: build
image:
registry.gitlab.com/cip-project/cip-testing/linux-cip-ci:build-$DOCK
ER_IMAGE_TAG
variables:
@@ -21,7 +23,7 @@ arm_hitachi_omap_defconfig:
paths:
- output

-arm_moxa_mxc_defconfig:
+build:arm_moxa_mxc_defconfig:
stage: build
image:
registry.gitlab.com/cip-project/cip-testing/linux-cip-ci:build-$DOCK
ER_IMAGE_TAG
variables:
@@ -37,7 +39,7 @@ arm_moxa_mxc_defconfig:
paths:
- output

-arm_renesas_shmobile_defconfig:
+build:arm_renesas_shmobile_defconfig:
stage: build
image:
registry.gitlab.com/cip-project/cip-testing/linux-cip-ci:build-$DOCK
ER_IMAGE_TAG
variables:
@@ -54,7 +56,23 @@ arm_renesas_shmobile_defconfig:
paths:
- output

-arm_siemens_am335x-axm2_defconfig:
+test:arm_renesas_shmobile_defconfig:
+ stage: test
+ needs: ["build:arm_renesas_shmobile_defconfig"]
+ image:
+registry.gitlab.com/cip-project/cip-testing/linux-cip-ci:test-$DOCK
ER_I
+MAGE_TAG
+ when: always
+ variables:
+ GIT_STRATEGY: none
+ TEST_TIMEOUT: 60
+ script:
+ - /opt/submit_tests.sh
+ artifacts:
+ name: "$CI_JOB_NAME"
+ when: always
+ paths:
+ - output
+
+build:arm_siemens_am335x-axm2_defconfig:
stage: build
image:
registry.gitlab.com/cip-project/cip-testing/linux-cip-ci:build-$DOCK
ER_IMAGE_TAG
variables:
@@ -70,7 +88,7 @@ arm_siemens_am335x-axm2_defconfig:
paths:
- output

-arm_siemens_am335x-draco_defconfig:
+build:arm_siemens_am335x-draco_defconfig:
stage: build
image:
registry.gitlab.com/cip-project/cip-testing/linux-cip-ci:build-$DOCK
ER_IMAGE_TAG
variables:
@@ -86,7 +104,7 @@ arm_siemens_am335x-draco_defconfig:
paths:
- output

-arm_siemens_am335x-dxr2_defconfig:
+build:arm_siemens_am335x-dxr2_defconfig:
stage: build
image:
registry.gitlab.com/cip-project/cip-testing/linux-cip-ci:build-$DOCK
ER_IMAGE_TAG
variables:
@@ -102,7 +120,7 @@ arm_siemens_am335x-dxr2_defconfig:
paths:
- output

-arm_siemens_am335x-etamin_defconfig:
+build:arm_siemens_am335x-etamin_defconfig:
stage: build
image:
registry.gitlab.com/cip-project/cip-testing/linux-cip-ci:build-$DOCK
ER_IMAGE_TAG
variables:
@@ -118,7 +136,7 @@ arm_siemens_am335x-etamin_defconfig:
paths:
- output

-arm_siemens_am57xx-pxm3.config:
+build:arm_siemens_am57xx-pxm3.config:
stage: build
image:
registry.gitlab.com/cip-project/cip-testing/linux-cip-ci:build-$DOCK
ER_IMAGE_TAG
variables:
@@ -134,7 +152,7 @@ arm_siemens_am57xx-pxm3.config:
paths:
- output

-arm_siemens_dcu2.config:
+build:arm_siemens_dcu2.config:
stage: build
image:
registry.gitlab.com/cip-project/cip-testing/linux-cip-ci:build-$DOCK
ER_IMAGE_TAG
variables:
@@ -150,7 +168,7 @@ arm_siemens_dcu2.config:
paths:
- output

-arm_siemens_imx6_defconfig:
+build:arm_siemens_imx6_defconfig:
stage: build
image:
registry.gitlab.com/cip-project/cip-testing/linux-cip-ci:build-$DOCK
ER_IMAGE_TAG
variables:
@@ -166,7 +184,7 @@ arm_siemens_imx6_defconfig:
paths:
- output

-arm_toshiba_tegra_defconfig:
+build:arm_toshiba_tegra_defconfig:
stage: build
image:
registry.gitlab.com/cip-project/cip-testing/linux-cip-ci:build-$DOCK
ER_IMAGE_TAG
variables:
@@ -182,7 +200,7 @@ arm_toshiba_tegra_defconfig:
paths:
- output

-arm_toshiba_zynq_defconfig:
+build:arm_toshiba_zynq_defconfig:
stage: build
image:
registry.gitlab.com/cip-project/cip-testing/linux-cip-ci:build-$DOCK
ER_IMAGE_TAG
variables:
@@ -198,7 +216,7 @@ arm_toshiba_zynq_defconfig:
paths:
- output

-x86_plathome_obsvx1.config:
+build:x86_plathome_obsvx1.config:
stage: build
image:
registry.gitlab.com/cip-project/cip-testing/linux-cip-ci:build-$DOCK
ER_IMAGE_TAG
variables:
@@ -214,7 +232,7 @@ x86_plathome_obsvx1.config:
paths:
- output

-x86_siemens_iot2000.config:
+build:x86_siemens_iot2000.config:
stage: build
image:
registry.gitlab.com/cip-project/cip-testing/linux-cip-ci:build-$DOCK
ER_IMAGE_TAG
variables:
@@ -230,7 +248,7 @@ x86_siemens_iot2000.config:
paths:
- output

-x86_siemens_server_defconfig:
+build:x86_siemens_server_defconfig:
stage: build
image:
registry.gitlab.com/cip-project/cip-testing/linux-cip-ci:build-$DOCK
ER_IMAGE_TAG
variables:
@@ -246,7 +264,7 @@ x86_siemens_server_defconfig:
paths:
- output

-x86_toshiba_defconfig:
+build:x86_toshiba_defconfig:
stage: build
image:
registry.gitlab.com/cip-project/cip-testing/linux-cip-ci:build-$DOCK
ER_IMAGE_TAG
variables:
@@ -262,8 +280,10 @@ x86_toshiba_defconfig:
paths:
- output

-# Extra build configurations
-arm_shmobile_defconfig:
+########################
+# Extra configurations #
+########################
+build:arm_shmobile_defconfig:
stage: build
image:
registry.gitlab.com/cip-project/cip-testing/linux-cip-ci:build-$DOCK
ER_IMAGE_TAG
variables:
@@ -280,9 +300,9 @@ arm_shmobile_defconfig:
paths:
- output

-# Testing
-run_tests:
+test:arm_shmobile_defconfig:
stage: test
+ needs: ["build:arm_shmobile_defconfig"]
image:
registry.gitlab.com/cip-project/cip-testing/linux-cip-ci:test-$DOCKE
R_IMAGE_TAG
when: always
variables:
--
2.17.1

_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: [PATCH 4.19.y-cip 50/57] ASoC: rsnd: fixup 6ch settings to 8ch

Kuninori Morimoto <kuninori.morimoto.gx@...>
 

Hi Pavel

+int rsnd_channel_normalization(int chan)
+{
+ if ((chan > 8) || (chan < 0))
+ return 0;
+
+ /* TDM Extend Mode needs 8ch */
+ if (chan == 6)
+ chan = 8;
+
+ return chan;
+}
+
Should the if ((chan > 8) || (chan < 0)) ever be true in practice?
Sounds like bogus inputs to me. Should we dev_err() and return error
in those cases? Or at least WARN_ON()?
Hmm... indeed.
Thank you for your report.
I will re-check code, and post patch

Thank you for your help !!
Best regards
---
Kuninori Morimoto


Re: [PATCH 4.19.y-cip 39/57] ASoC: rsnd: remove RSND_REG_ from rsnd_reg

Kuninori Morimoto <kuninori.morimoto.gx@...>
 

Hi Pavel

+#define SRCIN_TIMSEL(i) (SRCIN_TIMSEL0 + (i))
+#define SRCOUT_TIMSEL(i) (SRCOUT_TIMSEL0 + (i))
+#define CTU_SVxxR(i, j) (CTU_SV00R + (i * 8) + (j))
+#define DVC_VOLxR(i) (DVC_VOL0R + (i))
+#define AUDIO_CLK_SEL(i) (AUDIO_CLK_SEL0 + (i))
+#define SSI_BUSIF_MODE(i) (SSI_BUSIF0_MODE + (i))
+#define SSI_BUSIF_ADINR(i) (SSI_BUSIF0_ADINR + (i))
+#define SSI_BUSIF_DALIGN(i) (SSI_BUSIF0_DALIGN + (i))
+#define SSI_SYS_STATUS(i) (SSI_SYS_STATUS0 + (i))
Would it still make sense to test that i is in expected range?

#define CHECK_RANGE(i) ({ WARN_ON(i<0 || i>4); i; })
#define SRCIN_TIMSEL(i) (SRCIN_TIMSEL0 + (i))
Which range ?? for SRCIN ?
I'm not sure it make sense. Can you send use case ??

Thank you for your help !!
Best regards
---
Kuninori Morimoto


Re: [PATCH 4.19.y-cip 52/57] ASoC: rsnd: fixup mod ID calculation in rsnd_ctu_probe_

Pavel Machek
 

On Thu 2019-10-17 08:05:24, Biju Das wrote:
From: Nilkanth Ahirrao <anilkanth@...>

commit ac28ec07ae1c5c1e18ed6855eb105a328418da88 upstream.

commit c16015f36cc1 ("ASoC: rsnd: add .get_id/.get_id_sub")
introduces rsnd_ctu_id which calcualates and gives
the main Device id of the CTU by dividing the id by 4.
rsnd_mod_id uses this interface to get the CTU main
Device id. But this commit forgets to revert the main
Device id calcution previously done in rsnd_ctu_probe_
which also divides the id by 4. This path corrects the
same to get the correct main Device id.

The issue is observered when rsnd_ctu_probe_ is done for CTU1

Fixes: c16015f36cc1 ("ASoC: rsnd: add .get_id/.get_id_sub")
@@ -108,7 +108,7 @@ static int rsnd_ctu_probe_(struct rsnd_mod *mod,
struct rsnd_dai_stream *io,
struct rsnd_priv *priv)
{
- return rsnd_cmd_attach(io, rsnd_mod_id(mod) / 4);
+ return rsnd_cmd_attach(io, rsnd_mod_id(mod));
}

static void rsnd_ctu_value_init(struct rsnd_dai_stream *io,
Ok, but again, could it be next to the patch it fixes?

Thanks,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 4.19.y-cip 50/57] ASoC: rsnd: fixup 6ch settings to 8ch

Pavel Machek
 

On Thu 2019-10-17 08:05:22, Biju Das wrote:
From: Kuninori Morimoto <kuninori.morimoto.gx@...>

commit 66287def435315d9d8de740da4c543e37630b897 upstream.

rsnd need to use 8ch clock settings for 6ch for TDM.
Otherwise, it can't work correctly.
This patch fixup it.
Ok, but...

+int rsnd_channel_normalization(int chan)
+{
+ if ((chan > 8) || (chan < 0))
+ return 0;
+
+ /* TDM Extend Mode needs 8ch */
+ if (chan == 6)
+ chan = 8;
+
+ return chan;
+}
+
Should the if ((chan > 8) || (chan < 0)) ever be true in practice?
Sounds like bogus inputs to me. Should we dev_err() and return error
in those cases? Or at least WARN_ON()?

Best regards,
Pavel

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 4.19.y-cip 49/57] ASoC: rsnd: src: fix compiler warnings

Pavel Machek
 

Hi!

From: Jiada Wang <jiada_wang@...>

commit 399706df420ea8bc8b31283a919e6475f737d0ea upstream.

compiler complains about following declarations

sound/soc/sh/rcar/src.c:174:1: warning: 'static' is not at beginning of declaration [-Wold-style-declaration]
const static u32 bsdsr_table_pattern1[] = {
I'd prefer this to be need the patch it fixes, too.

Thanks,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 4.19.y-cip 48/57] ASoC: rsnd: src: Avoid a potential deadlock

Pavel Machek
 

On Thu 2019-10-17 08:05:20, Biju Das wrote:
From: Jiada Wang <jiada_wang@...>

commit ba164a49f8f7390b036713bf8a70a150a938c670 upstream.

lockdep warns us that priv->lock and k->k_lock can cause a
deadlock when after acquire of k->k_lock, process is interrupted
by src, while in another routine of src .init, k->k_lock is
acquired with priv->lock held.

This patch avoids a potential deadlock by not calling soc_device_match()
in SRC .init callback, instead it adds new soc fields in priv->flags to
differentiate SoCs.
Could this be moved near the patch it fixes? Or even merged to it?
Introducing deadlocks is bad for bisection at the very least...

Best regards,
Pavel

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 4.19.y-cip 40/57] ASoC: rsnd: update BSDSR/BSDISR handling

Pavel Machek
 

Hi!

Current BSDSR/BSDISR are using temporary/generic settings, but it can't
handle all SRCx/SoC. It needs to handle correctry.
Otherwise, sampling rate converted sound channel will be broken if it
was TDM. One note is that it needs to overwrite settings on E3 case.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@...>
static void rsnd_src_set_convert_rate(struct rsnd_dai_stream *io,
struct rsnd_mod *mod)
{
...
+ if (chan > 8 ||
+ idx >= ARRAY_SIZE(chan222222))
+ goto convert_rate_err;
...
@@ -244,6 +344,11 @@ static void rsnd_src_set_convert_rate(struct rsnd_dai_stream *io,
rsnd_mod_write(mod, SRC_BUSIF_DALIGN, rsnd_get_dalign(mod, io));

rsnd_adg_set_src_timesel_gen2(mod, io, fin, fout);
+
+ return;
+
+convert_rate_err:
+ dev_err(dev, "unknown BSDSR/BSDIR settings\n");
}
If error happens, would it make sense to propagate it back to the
caller?

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 4.19.y-cip 39/57] ASoC: rsnd: remove RSND_REG_ from rsnd_reg

Pavel Machek
 

Hi!

From: Kuninori Morimoto <kuninori.morimoto.gx@...>

commit b7169ddea2f2a90538f606688adf4948f2da82ce upstream.

Current rsnd is using RSND_REG_xxx for register naming,
and using RSND_REG_##f style macro for read/write.
The biggest reason why it uses this style is that
we can avoid non-existing register access.
But, its demerit is sequential register access code will
be very ugly.
Current rsnd driver is well tested, so, let's remove RSND_REG_
from rsnd_reg, and cleanup sequential register access code.
+#define SRCIN_TIMSEL(i) (SRCIN_TIMSEL0 + (i))
+#define SRCOUT_TIMSEL(i) (SRCOUT_TIMSEL0 + (i))
+#define CTU_SVxxR(i, j) (CTU_SV00R + (i * 8) + (j))
+#define DVC_VOLxR(i) (DVC_VOL0R + (i))
+#define AUDIO_CLK_SEL(i) (AUDIO_CLK_SEL0 + (i))
+#define SSI_BUSIF_MODE(i) (SSI_BUSIF0_MODE + (i))
+#define SSI_BUSIF_ADINR(i) (SSI_BUSIF0_ADINR + (i))
+#define SSI_BUSIF_DALIGN(i) (SSI_BUSIF0_DALIGN + (i))
+#define SSI_SYS_STATUS(i) (SSI_SYS_STATUS0 + (i))
Would it still make sense to test that i is in expected range?

#define CHECK_RANGE(i) ({ WARN_ON(i<0 || i>4); i; })
#define SRCIN_TIMSEL(i) (SRCIN_TIMSEL0 + (i))
...

Thanks and best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 4.19.y-cip 0/6] Add HDMI AUDIO/CAN/CANFD support

Chris Paterson
 

Hello Pavel,

From: Pavel Machek <pavel@...>
Sent: 24 October 2019 13:49

Hi!

This patch series add HDMI AUDIO/CAN/CANFD support for HiHope
RZ/G2M platform.

This patch series is based on linux-4.19.y-cip and all the patches in
this series are cherry-picked from linux rc tree.
Series seems ok to me, if there are no objections I can apply it.
Thanks for the review
I applied the patches. Tests are still running (
https://gitlab.com/cip-project/cip-kernel/linux-cip/pipelines/91254170
) but I don't expect problems there.
Just to let you know, the arm64 boards are currently offline in the Renesas LAVA lab.
I'm working to get them online again, but the impact will be that your test jobs will eventually timeout and fail.

Sorry for the inconvenience.

Kind regards, Chris


Best regards,
                                                              Pavel
--
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 4.19.y-cip 0/6] Add HDMI AUDIO/CAN/CANFD support

Pavel Machek
 

Hi!

This patch series add HDMI AUDIO/CAN/CANFD support for HiHope
RZ/G2M platform.

This patch series is based on linux-4.19.y-cip and all the patches in
this series are cherry-picked from linux rc tree.
Series seems ok to me, if there are no objections I can apply it.
Thanks for the review
I applied the patches. Tests are still running (
https://gitlab.com/cip-project/cip-kernel/linux-cip/pipelines/91254170
) but I don't expect problems there.

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: CIP IRC weekly meeting today

masashi.kudo@...
 

Hi, SZ-san,

 

Yes, please close this AI. Thanks very much for your cooperation.

 

Best regards,

--

M. Kudo

 

From: SZ Lin (林上智) <SZ.Lin@...>
Sent: Thursday, October 24, 2019 2:54 PM
To:
工藤 雅司(CTJ <masashi.kudo@...>
Cc: cip-dev@...
Subject: RE: [cip-dev] CIP IRC weekly meeting today

 

Hi Kudo-san,

 

Thanks for you heads up.

 

For now, we’re waiting for your patches. So I think we can close this AI if you have no objection.

 

SZ

 

From: masashi.kudo@... <masashi.kudo@...>
Sent: Thursday, October 24, 2019 1:51 PM
To: SZ Lin (
林上智) <SZ.Lin@...>
Cc: cip-dev@...
Subject: Re: [cip-dev] CIP IRC weekly meeting today

 

SZ-san,

 

> 3. Review the proposal from Kudo-san - Kernel team  

 

I'm sorry, but I cannot attend today's meeting due to another appointment.

If I need to do anything, please let me know.

 

Best regards,

--

M. Kudo

 

20191024() 10:55 SZ Lin (林上智) <SZ.Lin@...>:

Hi all,

 

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

 

*Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC meeting*

https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=10&day=24&hour=9&min=0&sec=0&p1=241&p2=137&p3=179&p4=136&p5=37&p6=248

         

US-West US-East   UK     DE     TW     JP

02:00    05:00   10:00   11:00   17:00   18:00

 

Channel:

* irc:chat.freenode.net:6667/cip

 

Last week's meeting minutes:

https://irclogs.baserock.org/meetings/cip/2019/10/cip.2019-10-17-09.00.html

 

Agenda:

 

* Action item

1. Provide the cases to cip-testing to build up the test environment - Iwamatsu-san

 

2. Test LTS (pre)releases directly patersonc

 

3. Review the proposal from Kudo-san - Kernel team

 

* Kernel maintenance updates

* Kernel testing

* CIP Core

* Software update

* AOB

 

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.

 

Best regards,

 

SZ Lin, Moxa.

_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: CIP IRC weekly meeting today

SZ Lin (林上智) <SZ.Lin@...>
 

Hi Kudo-san,

 

Thanks for you heads up.

 

For now, we’re waiting for your patches. So I think we can close this AI if you have no objection.

 

SZ

 

From: masashi.kudo@... <masashi.kudo@...>
Sent: Thursday, October 24, 2019 1:51 PM
To: SZ Lin (
林上智) <SZ.Lin@...>
Cc: cip-dev@...
Subject: Re: [cip-dev] CIP IRC weekly meeting today

 

SZ-san,

 

> 3. Review the proposal from Kudo-san - Kernel team  

 

I'm sorry, but I cannot attend today's meeting due to another appointment.

If I need to do anything, please let me know.

 

Best regards,

--

M. Kudo

 

20191024() 10:55 SZ Lin (林上智) <SZ.Lin@...>:

Hi all,

 

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

 

*Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC meeting*

https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=10&day=24&hour=9&min=0&sec=0&p1=241&p2=137&p3=179&p4=136&p5=37&p6=248

         

US-West US-East   UK     DE     TW     JP

02:00    05:00   10:00   11:00   17:00   18:00

 

Channel:

* irc:chat.freenode.net:6667/cip

 

Last week's meeting minutes:

https://irclogs.baserock.org/meetings/cip/2019/10/cip.2019-10-17-09.00.html

 

Agenda:

 

* Action item

1. Provide the cases to cip-testing to build up the test environment - Iwamatsu-san

 

2. Test LTS (pre)releases directly patersonc

 

3. Review the proposal from Kudo-san - Kernel team

 

* Kernel maintenance updates

* Kernel testing

* CIP Core

* Software update

* AOB

 

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.

 

Best regards,

 

SZ Lin, Moxa.

_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: CIP IRC weekly meeting today

masashi.kudo@...
 

SZ-san,

> 3. Review the proposal from Kudo-san - Kernel team  

I'm sorry, but I cannot attend today's meeting due to another appointment.
If I need to do anything, please let me know.

Best regards,
--
M. Kudo

2019年10月24日(木) 10:55 SZ Lin (林上智) <SZ.Lin@...>:

Hi all,

 

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

 

*Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC meeting*

https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=10&day=24&hour=9&min=0&sec=0&p1=241&p2=137&p3=179&p4=136&p5=37&p6=248

         

US-West US-East   UK     DE     TW     JP

02:00    05:00   10:00   11:00   17:00   18:00

 

Channel:

* irc:chat.freenode.net:6667/cip

 

Last week's meeting minutes:

https://irclogs.baserock.org/meetings/cip/2019/10/cip.2019-10-17-09.00.html

 

Agenda:

 

* Action item

1. Provide the cases to cip-testing to build up the test environment - Iwamatsu-san

 

2. Test LTS (pre)releases directly patersonc

 

3. Review the proposal from Kudo-san - Kernel team

 

* Kernel maintenance updates

* Kernel testing

* CIP Core

* Software update

* AOB

 

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.

 

Best regards,

 

SZ Lin, Moxa.

_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


CIP IRC weekly meeting today

SZ Lin (林上智) <SZ.Lin@...>
 

Hi all,

 

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

 

*Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC meeting*

https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=10&day=24&hour=9&min=0&sec=0&p1=241&p2=137&p3=179&p4=136&p5=37&p6=248

         

US-West US-East   UK     DE     TW     JP

02:00    05:00   10:00   11:00   17:00   18:00

 

Channel:

* irc:chat.freenode.net:6667/cip

 

Last week's meeting minutes:

https://irclogs.baserock.org/meetings/cip/2019/10/cip.2019-10-17-09.00.html

 

Agenda:

 

* Action item

1. Provide the cases to cip-testing to build up the test environment - Iwamatsu-san

 

2. Test LTS (pre)releases directly patersonc

 

3. Review the proposal from Kudo-san - Kernel team

 

* Kernel maintenance updates

* Kernel testing

* CIP Core

* Software update

* AOB

 

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.

 

Best regards,

 

SZ Lin, Moxa.


Re: [PATCH 4.19.y-cip 15/57] ASoC: convert for_each_rtd_codec_dai() for missing part

Biju Das <biju.das@...>
 

Hello Morimota-San,

Thanks for the feedback.

Subject: Re: [PATCH 4.19.y-cip 15/57] ASoC: convert
for_each_rtd_codec_dai() for missing part


Hi

@@ -1321,8 +1322,7 @@ static struct snd_soc_pcm_runtime
*dpcm_get_be(struct snd_soc_card *card,
if (be->cpu_dai->playback_widget == widget)
return be;

- for (i = 0; i < be->num_codecs; i++) {
- struct snd_soc_dai *dai = be->codec_dais[i];
+ for_each_rtd_codec_dai(be, i, dai) {
if (dai->playback_widget == widget)
return be;
}
This conversion is not equivalent. Original code always goes through
num_codecs, new code stops at first NULL pointer. I assume there are
always non-NULL pointers in the list, but perhaps new code should
not be ignoring the NULLs silently?
Do you have any opinion on Pavel's findings?
Hmm.. strange.
If original code goes through eventhough NULL pointer, it will be Oops at dai-
playback_widget access ?
? Does this comment came from code review, instead of actual machine
operation issue ?
This comments are from code review.

https://lists.cip-project.org/pipermail/cip-dev/2019-October/thread.html#3456

Cheers,
Biju


if so, it is always non-NULL pointer list.


Re: [PATCH 4.19.y-cip 19/57] ASoC: rsnd: use 32bit TDM width as default

Kuninori Morimoto <kuninori.morimoto.gx@...>
 

Hi

@@ -738,8 +738,8 @@ static int rsnd_soc_set_dai_tdm_slot(struct snd_soc_dai *dai,
case 32:
break;
default:
- dev_err(dev, "unsupported slot width value: %d\n", slot_width);
- return -EINVAL;
+ /* use default */
+ slot_width = 32;
}

switch (slots) {
I don't think I like this. People should not be passing strange values to this
function. Can the caller be fixed, instead?
Morimoto San, Do you agree to Pavel's comment?
As git-log said, it is default values, not strange value.
People don't set all settings, especially it was default.

Thank you for your help !!
Best regards
---
Kuninori Morimoto


Re: [PATCH 4.19.y-cip 25/57] ASoC: rsnd: remove endpoint bidirectional check

Kuninori Morimoto <kuninori.morimoto.gx@...>
 

Hi

DTC commit df536831d02c ("checks: add graph binding checks") is
checking endpoint bidirectional, and it is upstreamed to linux by
commit 50aafd60898a ("scripts/dtc: Update to upstream version
v1.4.6-21-g84e414b0b5bc").
Let's remove own bidirectional check
I don't really understand what bidirectional check? Are you saying that
of_graph_get_remote_endpoint() never fails in 4.19.X ?
On OF-graph DT, remote-endpoint need to be pair.
ex)
endpoint1: endpoint {
remote-endpoint = <&endpoint2>;
};

endpoint2: endpoint {
remote-endpoint = <&endpoint1>;
};

This "bidirectional check" is for it.
Now, it is checked by DTC.

+++ b/sound/soc/sh/rcar/ssi.c
@@ -1095,11 +1095,7 @@ void rsnd_ssi_parse_hdmi_connection(struct
rsnd_priv *priv,
int dai_i)
{
struct rsnd_dai *rdai = rsnd_rdai_get(priv, dai_i);
- struct device_node *remote_ep;
-
- remote_ep = of_graph_get_remote_endpoint(endpoint);
- if (!remote_ep)
- return;
+ struct device_node *remote_ep =
+of_graph_get_remote_endpoint(endpoint);
Plus the code seems to be missing of_node_put().
Thanks. indeed it missing of_node_put().
I will post fixup patch


Thank you for your help !!
Best regards
---
Kuninori Morimoto


Re: [PATCH 4.19.y-cip 16/57] ASoC: add for_each_dpcm_fe() macro

Kuninori Morimoto <kuninori.morimoto.gx@...>
 

Hi

--- a/include/sound/soc-dpcm.h
+++ b/include/sound/soc-dpcm.h
@@ -103,6 +103,9 @@ struct snd_soc_dpcm_runtime {
int trigger_pending; /* trigger cmd + 1 if pending, 0 if not */ };

+#define for_each_dpcm_fe(be, stream, dpcm)
\
+ list_for_each_entry(dpcm, &(be)->dpcm[stream].fe_clients, list_fe)
+
This macro is really confusing. dpcm is used as both control variable of the
loop and name of the field in *be.
Ohh, yes, indeed.
Thank you for pointing it. I will post fixup patch

Plus it relies on list_fe variable to be
present in the context including it... that's non-standard.
sorry I couldn't understand about this

Oh and "&(be)->" can be written as "(be)." AFAICT.
This "&" is for fe_clients

Thank you for your help !!
Best regards
---
Kuninori Morimoto


Re: [PATCH 4.19.y-cip 15/57] ASoC: convert for_each_rtd_codec_dai() for missing part

Kuninori Morimoto <kuninori.morimoto.gx@...>
 

Hi

@@ -1321,8 +1322,7 @@ static struct snd_soc_pcm_runtime
*dpcm_get_be(struct snd_soc_card *card,
if (be->cpu_dai->playback_widget == widget)
return be;

- for (i = 0; i < be->num_codecs; i++) {
- struct snd_soc_dai *dai = be->codec_dais[i];
+ for_each_rtd_codec_dai(be, i, dai) {
if (dai->playback_widget == widget)
return be;
}
This conversion is not equivalent. Original code always goes through
num_codecs, new code stops at first NULL pointer. I assume there are
always non-NULL pointers in the list, but perhaps new code should not be
ignoring the NULLs silently?
Do you have any opinion on Pavel's findings?
Hmm.. strange.
If original code goes through eventhough NULL pointer,
it will be Oops at dai->playback_widget access ?

? Does this comment came from code review,
instead of actual machine operation issue ?

if so, it is always non-NULL pointer list.

Thank you for your help !!
Best regards
---
Kuninori Morimoto

6581 - 6600 of 10141