- greybus-dev - lists.linaro.org

[PATCH v3 0/6] Enable Greybus Audio codec driver

by Vaibhav Agarwal

The existing GB Audio codec driver is dependent on MSM8994 Audio driver. During the development stage, this dependency was configured due to various changes involved in MSM Audio driver to enable addtional codec card and some of the changes proposed in mainline ASoC framework. However, these are not the real dependencies and some of them can be easily removed. The folowing patch series includes the changes to resolve unnecessary depedencies and make the codec driver functional with the latest kernel. Patch 1,2: Incudes jack framework related changes. Patch 3,4,5: Resolves compilation error observed with the latest kernel and also provides helper APIs required to allow dynamic addition/removal of modules. Patch 6: Finally provides config options and related Makefile changes to enable GB Codec driver. Thanks to Alexandre for raising the headsup [1] and motivating me to provide the necessary changes. This patchset is intended to resolve the componentization issue only. And as per the suggestion [2] from Mark, I'll share a separate patch series aligned to ASoC tree. Once the relevant changes are accepted in snd-soc framework, I'll share relevant patches to pull GB Audio out of the staging tree. [1] https://lore.kernel.org/lkml/20200507212912.599433-1-alexandre.belloni@boot… [2] https://lore.kernel.org/alsa-devel/20200612160620.GK5396@sirena.org.uk/ v1: - Include the changes for the review comments suggested by Dan - Rebase to latest staging-next v2: - Avoid defining unused 'update' pointer - Fix the missing connect bool value required during mixer_update_power - Added Reviewed-by tag from Dan - Rebase to latest staging-next Vaibhav Agarwal (6): staging: greybus: audio: Update snd_jack FW usage as per new APIs staging: greybus: audio: Maintain jack list within GB Audio module staging: greybus: audio: Resolve compilation errors for GB codec module staging: greybus: audio: Resolve compilation error in topology parser staging: greybus: audio: Add helper APIs for dynamic audio modules staging: greybus: audio: Enable GB codec, audio module compilation. drivers/staging/greybus/Kconfig | 14 +- drivers/staging/greybus/Makefile | 6 +- drivers/staging/greybus/audio_codec.c | 178 +++++++++++--------- drivers/staging/greybus/audio_codec.h | 12 +- drivers/staging/greybus/audio_helper.c | 197 +++++++++++++++++++++++ drivers/staging/greybus/audio_helper.h | 17 ++ drivers/staging/greybus/audio_module.c | 15 +- drivers/staging/greybus/audio_topology.c | 123 +++++++------- 8 files changed, 409 insertions(+), 153 deletions(-) create mode 100644 drivers/staging/greybus/audio_helper.c create mode 100644 drivers/staging/greybus/audio_helper.h base-commit: 98fe05e21a6e0ca242e974650ed58b64813cb2dc -- 2.26.2

4 years

3
9
0 0

[PATCH v2] greybus: fix typos in GREYBUS/GREYBUS_ES2 help text

by Zenyu Sy

From: Zenyu Sy <zenyu(a)tuta.io> Fix typos ("an" -> "a", "chose" -> "choose") in Kconfig Signed-off-by: Zenyu Sy <zenyu(a)tuta.io> --- base-commit: f5e94d10e4c468357019e5c28d48499f677b284f Fixed the white-space formatting problem. drivers/greybus/Kconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/greybus/Kconfig b/drivers/greybus/Kconfig index b84fcaf8b..aeea082f1 100644 --- a/drivers/greybus/Kconfig +++ b/drivers/greybus/Kconfig @@ -3,7 +3,7 @@ menuconfig GREYBUS tristate "Greybus support" depends on SYSFS ---help--- - This option enables the Greybus driver core. Greybus is an + This option enables the Greybus driver core. Greybus is a hardware protocol that was designed to provide Unipro with a sane application layer. It was originally designed for the ARA project, a module phone system, but has shown up in other @@ -12,7 +12,7 @@ menuconfig GREYBUS Say Y here to enable support for these types of drivers. - To compile this code as a module, chose M here: the module + To compile this code as a module, choose M here: the module will be called greybus.ko if GREYBUS @@ -25,7 +25,7 @@ config GREYBUS_ES2 acts as a Greybus "host controller". This device is a bridge from a USB device to a Unipro network. - To compile this code as a module, chose M here: the module + To compile this code as a module, choose M here: the module will be called gb-es2.ko endif # GREYBUS -- 2.26.1

4 years

2
1
0 0

[PATCH 4.9 092/128] staging: greybus: sdio: Respect the cmd->busy_timeout from the mmc core

by Greg Kroah-Hartman

From: Ulf Hansson <ulf.hansson(a)linaro.org> [ Upstream commit a389087ee9f195fcf2f31cd771e9ec5f02c16650 ] Using a fixed 1s timeout for all commands is a bit problematic. For some commands it means waiting longer than needed for the timeout to expire, which may not a big issue, but still. For other commands, like for an erase (CMD38) that uses a R1B response, may require longer timeouts than 1s. In these cases, we may end up treating the command as it failed, while it just needed some more time to complete successfully. Fix the problem by respecting the cmd->busy_timeout, which is provided by the mmc core. Cc: Rui Miguel Silva <rmfrfs(a)gmail.com> Cc: Johan Hovold <johan(a)kernel.org> Cc: Alex Elder <elder(a)kernel.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: greybus-dev(a)lists.linaro.org Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Acked-by: Rui Miguel Silva <rmfrfs(a)gmail.com> Acked-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Link: https://lore.kernel.org/r/20200414161413.3036-20-ulf.hansson@linaro.org Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/staging/greybus/sdio.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/staging/greybus/sdio.c b/drivers/staging/greybus/sdio.c index 5649ef1e379d..82a1c2cf6687 100644 --- a/drivers/staging/greybus/sdio.c +++ b/drivers/staging/greybus/sdio.c @@ -413,6 +413,7 @@ static int gb_sdio_command(struct gb_sdio_host *host, struct mmc_command *cmd) struct gb_sdio_command_request request = {0}; struct gb_sdio_command_response response; struct mmc_data *data = host->mrq->data; + unsigned int timeout_ms; u8 cmd_flags; u8 cmd_type; int i; @@ -471,9 +472,12 @@ static int gb_sdio_command(struct gb_sdio_host *host, struct mmc_command *cmd) request.data_blksz = cpu_to_le16(data->blksz); } - ret = gb_operation_sync(host->connection, GB_SDIO_TYPE_COMMAND, - &request, sizeof(request), &response, - sizeof(response)); + timeout_ms = cmd->busy_timeout ? cmd->busy_timeout : + GB_OPERATION_TIMEOUT_DEFAULT; + + ret = gb_operation_sync_timeout(host->connection, GB_SDIO_TYPE_COMMAND, + &request, sizeof(request), &response, + sizeof(response), timeout_ms); if (ret < 0) goto out; -- 2.25.1

4 years

1
0
0 0

[PATCH 4.14 132/190] staging: greybus: sdio: Respect the cmd->busy_timeout from the mmc core

by Greg Kroah-Hartman

From: Ulf Hansson <ulf.hansson(a)linaro.org> [ Upstream commit a389087ee9f195fcf2f31cd771e9ec5f02c16650 ] Using a fixed 1s timeout for all commands is a bit problematic. For some commands it means waiting longer than needed for the timeout to expire, which may not a big issue, but still. For other commands, like for an erase (CMD38) that uses a R1B response, may require longer timeouts than 1s. In these cases, we may end up treating the command as it failed, while it just needed some more time to complete successfully. Fix the problem by respecting the cmd->busy_timeout, which is provided by the mmc core. Cc: Rui Miguel Silva <rmfrfs(a)gmail.com> Cc: Johan Hovold <johan(a)kernel.org> Cc: Alex Elder <elder(a)kernel.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: greybus-dev(a)lists.linaro.org Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Acked-by: Rui Miguel Silva <rmfrfs(a)gmail.com> Acked-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Link: https://lore.kernel.org/r/20200414161413.3036-20-ulf.hansson@linaro.org Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/staging/greybus/sdio.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/staging/greybus/sdio.c b/drivers/staging/greybus/sdio.c index 101ca5097fc9..93e2c091c565 100644 --- a/drivers/staging/greybus/sdio.c +++ b/drivers/staging/greybus/sdio.c @@ -412,6 +412,7 @@ static int gb_sdio_command(struct gb_sdio_host *host, struct mmc_command *cmd) struct gb_sdio_command_request request = {0}; struct gb_sdio_command_response response; struct mmc_data *data = host->mrq->data; + unsigned int timeout_ms; u8 cmd_flags; u8 cmd_type; int i; @@ -470,9 +471,12 @@ static int gb_sdio_command(struct gb_sdio_host *host, struct mmc_command *cmd) request.data_blksz = cpu_to_le16(data->blksz); } - ret = gb_operation_sync(host->connection, GB_SDIO_TYPE_COMMAND, - &request, sizeof(request), &response, - sizeof(response)); + timeout_ms = cmd->busy_timeout ? cmd->busy_timeout : + GB_OPERATION_TIMEOUT_DEFAULT; + + ret = gb_operation_sync_timeout(host->connection, GB_SDIO_TYPE_COMMAND, + &request, sizeof(request), &response, + sizeof(response), timeout_ms); if (ret < 0) goto out; -- 2.25.1

4 years

1
0
0 0

[PATCH 4.19 178/267] staging: greybus: sdio: Respect the cmd->busy_timeout from the mmc core

by Greg Kroah-Hartman

From: Ulf Hansson <ulf.hansson(a)linaro.org> [ Upstream commit a389087ee9f195fcf2f31cd771e9ec5f02c16650 ] Using a fixed 1s timeout for all commands is a bit problematic. For some commands it means waiting longer than needed for the timeout to expire, which may not a big issue, but still. For other commands, like for an erase (CMD38) that uses a R1B response, may require longer timeouts than 1s. In these cases, we may end up treating the command as it failed, while it just needed some more time to complete successfully. Fix the problem by respecting the cmd->busy_timeout, which is provided by the mmc core. Cc: Rui Miguel Silva <rmfrfs(a)gmail.com> Cc: Johan Hovold <johan(a)kernel.org> Cc: Alex Elder <elder(a)kernel.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: greybus-dev(a)lists.linaro.org Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Acked-by: Rui Miguel Silva <rmfrfs(a)gmail.com> Acked-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Link: https://lore.kernel.org/r/20200414161413.3036-20-ulf.hansson@linaro.org Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/staging/greybus/sdio.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/staging/greybus/sdio.c b/drivers/staging/greybus/sdio.c index 38e85033fc4b..afb2e5e5111a 100644 --- a/drivers/staging/greybus/sdio.c +++ b/drivers/staging/greybus/sdio.c @@ -411,6 +411,7 @@ static int gb_sdio_command(struct gb_sdio_host *host, struct mmc_command *cmd) struct gb_sdio_command_request request = {0}; struct gb_sdio_command_response response; struct mmc_data *data = host->mrq->data; + unsigned int timeout_ms; u8 cmd_flags; u8 cmd_type; int i; @@ -469,9 +470,12 @@ static int gb_sdio_command(struct gb_sdio_host *host, struct mmc_command *cmd) request.data_blksz = cpu_to_le16(data->blksz); } - ret = gb_operation_sync(host->connection, GB_SDIO_TYPE_COMMAND, - &request, sizeof(request), &response, - sizeof(response)); + timeout_ms = cmd->busy_timeout ? cmd->busy_timeout : + GB_OPERATION_TIMEOUT_DEFAULT; + + ret = gb_operation_sync_timeout(host->connection, GB_SDIO_TYPE_COMMAND, + &request, sizeof(request), &response, + sizeof(response), timeout_ms); if (ret < 0) goto out; -- 2.25.1

4 years

1
0
0 0

[PATCH 5.4 141/261] staging: greybus: sdio: Respect the cmd->busy_timeout from the mmc core

by Greg Kroah-Hartman

From: Ulf Hansson <ulf.hansson(a)linaro.org> [ Upstream commit a389087ee9f195fcf2f31cd771e9ec5f02c16650 ] Using a fixed 1s timeout for all commands is a bit problematic. For some commands it means waiting longer than needed for the timeout to expire, which may not a big issue, but still. For other commands, like for an erase (CMD38) that uses a R1B response, may require longer timeouts than 1s. In these cases, we may end up treating the command as it failed, while it just needed some more time to complete successfully. Fix the problem by respecting the cmd->busy_timeout, which is provided by the mmc core. Cc: Rui Miguel Silva <rmfrfs(a)gmail.com> Cc: Johan Hovold <johan(a)kernel.org> Cc: Alex Elder <elder(a)kernel.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: greybus-dev(a)lists.linaro.org Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Acked-by: Rui Miguel Silva <rmfrfs(a)gmail.com> Acked-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Link: https://lore.kernel.org/r/20200414161413.3036-20-ulf.hansson@linaro.org Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/staging/greybus/sdio.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/staging/greybus/sdio.c b/drivers/staging/greybus/sdio.c index 68c5718be827..c4b16bb5c1a4 100644 --- a/drivers/staging/greybus/sdio.c +++ b/drivers/staging/greybus/sdio.c @@ -411,6 +411,7 @@ static int gb_sdio_command(struct gb_sdio_host *host, struct mmc_command *cmd) struct gb_sdio_command_request request = {0}; struct gb_sdio_command_response response; struct mmc_data *data = host->mrq->data; + unsigned int timeout_ms; u8 cmd_flags; u8 cmd_type; int i; @@ -469,9 +470,12 @@ static int gb_sdio_command(struct gb_sdio_host *host, struct mmc_command *cmd) request.data_blksz = cpu_to_le16(data->blksz); } - ret = gb_operation_sync(host->connection, GB_SDIO_TYPE_COMMAND, - &request, sizeof(request), &response, - sizeof(response)); + timeout_ms = cmd->busy_timeout ? cmd->busy_timeout : + GB_OPERATION_TIMEOUT_DEFAULT; + + ret = gb_operation_sync_timeout(host->connection, GB_SDIO_TYPE_COMMAND, + &request, sizeof(request), &response, + sizeof(response), timeout_ms); if (ret < 0) goto out; -- 2.25.1

4 years

1
0
0 0

[PATCH 5.7 230/376] staging: greybus: sdio: Respect the cmd->busy_timeout from the mmc core

by Greg Kroah-Hartman

From: Ulf Hansson <ulf.hansson(a)linaro.org> [ Upstream commit a389087ee9f195fcf2f31cd771e9ec5f02c16650 ] Using a fixed 1s timeout for all commands is a bit problematic. For some commands it means waiting longer than needed for the timeout to expire, which may not a big issue, but still. For other commands, like for an erase (CMD38) that uses a R1B response, may require longer timeouts than 1s. In these cases, we may end up treating the command as it failed, while it just needed some more time to complete successfully. Fix the problem by respecting the cmd->busy_timeout, which is provided by the mmc core. Cc: Rui Miguel Silva <rmfrfs(a)gmail.com> Cc: Johan Hovold <johan(a)kernel.org> Cc: Alex Elder <elder(a)kernel.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: greybus-dev(a)lists.linaro.org Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Acked-by: Rui Miguel Silva <rmfrfs(a)gmail.com> Acked-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Link: https://lore.kernel.org/r/20200414161413.3036-20-ulf.hansson@linaro.org Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/staging/greybus/sdio.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/staging/greybus/sdio.c b/drivers/staging/greybus/sdio.c index 68c5718be827..c4b16bb5c1a4 100644 --- a/drivers/staging/greybus/sdio.c +++ b/drivers/staging/greybus/sdio.c @@ -411,6 +411,7 @@ static int gb_sdio_command(struct gb_sdio_host *host, struct mmc_command *cmd) struct gb_sdio_command_request request = {0}; struct gb_sdio_command_response response; struct mmc_data *data = host->mrq->data; + unsigned int timeout_ms; u8 cmd_flags; u8 cmd_type; int i; @@ -469,9 +470,12 @@ static int gb_sdio_command(struct gb_sdio_host *host, struct mmc_command *cmd) request.data_blksz = cpu_to_le16(data->blksz); } - ret = gb_operation_sync(host->connection, GB_SDIO_TYPE_COMMAND, - &request, sizeof(request), &response, - sizeof(response)); + timeout_ms = cmd->busy_timeout ? cmd->busy_timeout : + GB_OPERATION_TIMEOUT_DEFAULT; + + ret = gb_operation_sync_timeout(host->connection, GB_SDIO_TYPE_COMMAND, + &request, sizeof(request), &response, + sizeof(response), timeout_ms); if (ret < 0) goto out; -- 2.25.1

4 years

1
0
0 0

[PATCH AUTOSEL 4.14 037/108] staging: greybus: fix a missing-check bug in gb_lights_light_config()

by Sasha Levin

From: Chen Zhou <chenzhou10(a)huawei.com> [ Upstream commit 9bb086e5ba9495ac150fbbcc5c8c2bccc06261dd ] In gb_lights_light_config(), 'light->name' is allocated by kstrndup(). It returns NULL when fails, add check for it. Signed-off-by: Chen Zhou <chenzhou10(a)huawei.com> Acked-by: Rui Miguel Silva <rmfrfs(a)gmail.com> Link: https://lore.kernel.org/r/20200401030017.100274-1-chenzhou10@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/staging/greybus/light.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c index 4e7575147775..9fab0e2751aa 100644 --- a/drivers/staging/greybus/light.c +++ b/drivers/staging/greybus/light.c @@ -1033,7 +1033,8 @@ static int gb_lights_light_config(struct gb_lights *glights, u8 id) light->channels_count = conf.channel_count; light->name = kstrndup(conf.name, NAMES_MAX, GFP_KERNEL); - + if (!light->name) + return -ENOMEM; light->channels = kcalloc(light->channels_count, sizeof(struct gb_channel), GFP_KERNEL); if (!light->channels) -- 2.25.1

4 years

1
0
0 0

[PATCH AUTOSEL 4.19 052/172] staging: greybus: fix a missing-check bug in gb_lights_light_config()

by Sasha Levin

From: Chen Zhou <chenzhou10(a)huawei.com> [ Upstream commit 9bb086e5ba9495ac150fbbcc5c8c2bccc06261dd ] In gb_lights_light_config(), 'light->name' is allocated by kstrndup(). It returns NULL when fails, add check for it. Signed-off-by: Chen Zhou <chenzhou10(a)huawei.com> Acked-by: Rui Miguel Silva <rmfrfs(a)gmail.com> Link: https://lore.kernel.org/r/20200401030017.100274-1-chenzhou10@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/staging/greybus/light.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c index 40680eaf3974..db06cd544af5 100644 --- a/drivers/staging/greybus/light.c +++ b/drivers/staging/greybus/light.c @@ -1028,7 +1028,8 @@ static int gb_lights_light_config(struct gb_lights *glights, u8 id) light->channels_count = conf.channel_count; light->name = kstrndup(conf.name, NAMES_MAX, GFP_KERNEL); - + if (!light->name) + return -ENOMEM; light->channels = kcalloc(light->channels_count, sizeof(struct gb_channel), GFP_KERNEL); if (!light->channels) -- 2.25.1

4 years

1
0
0 0

[PATCH AUTOSEL 5.4 085/266] staging: greybus: fix a missing-check bug in gb_lights_light_config()

by Sasha Levin

From: Chen Zhou <chenzhou10(a)huawei.com> [ Upstream commit 9bb086e5ba9495ac150fbbcc5c8c2bccc06261dd ] In gb_lights_light_config(), 'light->name' is allocated by kstrndup(). It returns NULL when fails, add check for it. Signed-off-by: Chen Zhou <chenzhou10(a)huawei.com> Acked-by: Rui Miguel Silva <rmfrfs(a)gmail.com> Link: https://lore.kernel.org/r/20200401030017.100274-1-chenzhou10@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/staging/greybus/light.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c index d6ba25f21d80..d2672b65c3f4 100644 --- a/drivers/staging/greybus/light.c +++ b/drivers/staging/greybus/light.c @@ -1026,7 +1026,8 @@ static int gb_lights_light_config(struct gb_lights *glights, u8 id) light->channels_count = conf.channel_count; light->name = kstrndup(conf.name, NAMES_MAX, GFP_KERNEL); - + if (!light->name) + return -ENOMEM; light->channels = kcalloc(light->channels_count, sizeof(struct gb_channel), GFP_KERNEL); if (!light->channels) -- 2.25.1

4 years

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

greybus-dev