Re: [PATCH 00/14] Allwinner MIPI CSI-2 support for A31/V3s/A83T
Hi On Fri, Oct 30, 2020 at 07:44:28PM -0300, Helen Koike wrote: > On thing that is confusing me is the name csi2 with csi (that makes me > think of csi vesun6i-csirsion one, which is not the case), I would > rename it to sun6i-video (or maybe it is just me who gets confused). > > I know this driver is already upstream and not part of this series, > but on the other hand it doesn't seem to be used. It's definitely confusing but CSI is the name of the IP, but it supports more than just MIPI-CSI :) Maxime signature.asc Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 08/14] media: sunxi: Add support for the A31 MIPI CSI-2 controller
On Fri, Oct 30, 2020 at 07:45:18PM -0300, Helen Koike wrote: > On 10/23/20 2:45 PM, Paul Kocialkowski wrote: > > The A31 MIPI CSI-2 controller is a dedicated MIPI CSI-2 controller > > found on Allwinner SoCs such as the A31 and V3/V3s. > > > > It is a standalone block, connected to the CSI controller on one side > > and to the MIPI D-PHY block on the other. It has a dedicated address > > space, interrupt line and clock. > > > > Currently, the MIPI CSI-2 controller is hard-tied to a specific CSI > > controller (CSI0) but newer SoCs (such as the V5) may allow switching > > MIPI CSI-2 controllers between CSI controllers. > > > > It is represented as a V4L2 subdev to the CSI controller and takes a > > MIPI CSI-2 sensor as its own subdev, all using the fwnode graph and > > media controller API. > > Maybe this is a bad idea, but I was thinking: > This driver basically just turn on/off and catch some interrupts for errors, > and all the rest of v4l2 config you just forward to the next subdevice > on the pipeline. > > So instead of exposing it as a subdevice, I was wondering if modeling > this driver also through the phy subsystem wouldn't be cleaner, so > you won't need all the v4l2 subdevice/topology boilerplate code that > it seems you are not using (unless you have plans to add controls or > some specific configuration on this node later). > > But this would require changes on the sun6i-csi driver. > > What do you think? Eventually we'll need to filter the virtual channels / datatypes I guess, so it's definitely valuable to have it in v4l2 Maxime signature.asc Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: comedi: cb_pcidas: reinstate delay removed from trimpot setting
On 29/10/2020 14:18, Ian Abbott wrote:
Commit eddd2a4c675c ("staging: comedi: cb_pcidas: refactor
write_calibration_bitstream()") inadvertently removed one of the
`udelay(1)` calls when writing to the calibration register in
`cb_pcidas_calib_write()`. Reinstate the delay. It may seem strange
that the delay is placed before the register write, but this function is
called in a loop so the extra delay can make a difference.
This _might_ solve reported issues reading analog inputs on a
PCIe-DAS1602/16 card where the analog input values "were scaled in a
strange way that didn't make sense". On the same hardware running a
system with a 3.13 kernel, and then a system with a 4.4 kernel, but with
the same application software, the system with the 3.13 kernel was fine,
but the one with the 4.4 kernel exhibited the problem. Of the 90
changes to the driver between those kernel versions, this change looked
like the most likely culprit.
Actually, I've realized that this patch will have no effect on the
PCIe-DAS1602/16 card because it uses a different driver - cb_pcimdas,
not cb_pcidas.
Greg, you might as well drop this patch if you haven't already applied
it, since it was only a hunch that it fixed a problem.
--
-=( Ian Abbott || MEV Ltd. is a company )=-
-=( registered in England & Wales. Regd. number: 02862268. )=-
-=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=-
-=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: comedi: cb_pcidas: reinstate delay removed from trimpot setting
On 02/11/2020 10:25, Ian Abbott wrote:
On 29/10/2020 14:18, Ian Abbott wrote:
Commit eddd2a4c675c ("staging: comedi: cb_pcidas: refactor
write_calibration_bitstream()") inadvertently removed one of the
`udelay(1)` calls when writing to the calibration register in
`cb_pcidas_calib_write()`. Reinstate the delay. It may seem strange
that the delay is placed before the register write, but this function is
called in a loop so the extra delay can make a difference.
This _might_ solve reported issues reading analog inputs on a
PCIe-DAS1602/16 card where the analog input values "were scaled in a
strange way that didn't make sense". On the same hardware running a
system with a 3.13 kernel, and then a system with a 4.4 kernel, but with
the same application software, the system with the 3.13 kernel was fine,
but the one with the 4.4 kernel exhibited the problem. Of the 90
changes to the driver between those kernel versions, this change looked
like the most likely culprit.
Actually, I've realized that this patch will have no effect on the
PCIe-DAS1602/16 card because it uses a different driver - cb_pcimdas,
not cb_pcidas.
But that's also confusing because PCIe-DAS1602/16 was not supported
until the 3.19 kernel! I know the reported has both PCI-DAS1602/16 and
PCIe-DAS1602/16 cards (supported by cb_pcidas and cb_pcimdas
respectively), so there could have been some mix-up in the reporting.
Greg, you might as well drop this patch if you haven't already applied
it, since it was only a hunch that it fixed a problem.
--
-=( Ian Abbott || MEV Ltd. is a company )=-
-=( registered in England & Wales. Regd. number: 02862268. )=-
-=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=-
-=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH -next] media: cedrus: fix reference leak in cedrus_start_streaming
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to pm_runtime_put_noidle will result in
reference leak in cedrus_start_streaming. We should fix it.
Fixes: d5aecd289babf ("media: cedrus: Implement runtime PM")
Signed-off-by: Zhang Qilong
---
drivers/staging/media/sunxi/cedrus/cedrus_video.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
index 667b86dde1ee..911f607d9b09 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
@@ -479,8 +479,10 @@ static int cedrus_start_streaming(struct vb2_queue *vq,
unsigned int count)
if (V4L2_TYPE_IS_OUTPUT(vq->type)) {
ret = pm_runtime_get_sync(dev->dev);
- if (ret < 0)
+ if (ret < 0) {
+ pm_runtime_put_noidle(dev->dev);
goto err_cleanup;
+ }
if (dev->dec_ops[ctx->current_codec]->start) {
ret = dev->dec_ops[ctx->current_codec]->start(ctx);
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH -next] media: staging: rkisp1: cap: fix runtime PM imbalance on error
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to pm_runtime_put_noidle will result in
reference imbalance in rkisp1_vb2_start_streaming, so we
should fix it.
Fixes: 56e3b29f9f6b2 ("media: staging: rkisp1: add streaming paths")
Signed-off-by: Zhang Qilong
---
drivers/staging/media/rkisp1/rkisp1-capture.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/media/rkisp1/rkisp1-capture.c
b/drivers/staging/media/rkisp1/rkisp1-capture.c
index b6f497ce3e95..0c934ca5adaa 100644
--- a/drivers/staging/media/rkisp1/rkisp1-capture.c
+++ b/drivers/staging/media/rkisp1/rkisp1-capture.c
@@ -992,6 +992,7 @@ rkisp1_vb2_start_streaming(struct vb2_queue *queue,
unsigned int count)
ret = pm_runtime_get_sync(cap->rkisp1->dev);
if (ret < 0) {
+ pm_runtime_put_noidle(cap->rkisp1->dev);
dev_err(cap->rkisp1->dev, "power up failed %d\n", ret);
goto err_destroy_dummy;
}
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH -next] media: cedrus: fix reference leak in cedrus_start_streaming
On Mon, Nov 02, 2020 at 10:26:22PM +0800, Zhang Qilong wrote:
> pm_runtime_get_sync will increment pm usage counter even it
> failed. Forgetting to pm_runtime_put_noidle will result in
> reference leak in cedrus_start_streaming. We should fix it.
>
> Fixes: d5aecd289babf ("media: cedrus: Implement runtime PM")
> Signed-off-by: Zhang Qilong
Shouldn't we fix pm_runtime_get_sync instead then? It seems that most of
the callers get this wrong, and that's definitely non-obvious.
Maxime
signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
答复: [PATCH -next] media: cedrus: fix reference leak in cedrus_start_streaming
Hi
>
> On Mon, Nov 02, 2020 at 10:26:22PM +0800, Zhang Qilong wrote:
> > pm_runtime_get_sync will increment pm usage counter even it failed.
> > Forgetting to pm_runtime_put_noidle will result in reference leak in
> > cedrus_start_streaming. We should fix it.
> >
> > Fixes: d5aecd289babf ("media: cedrus: Implement runtime PM")
> > Signed-off-by: Zhang Qilong
>
> Shouldn't we fix pm_runtime_get_sync instead then? It seems that most of the
> callers get this wrong, and that's definitely non-obvious.
>
I have ever thought to fix fix pm_runtime_get_sync, then I went to read the
comment on this function, and found that this is what the author intended to
do(comment: The possible return values of this function are the same as for
pm_runtime_resume() and the runtime PM usage counter of @dev remains
incremented in all cases, even if it returns an error code). On the other hand,
I found that the number of callers that getting this right is much bigger than
getting this wrong even many callers get wrong. So I submit server patches to
fix them as I could.
Thanks, best wish!
Zhang Qilong
> Maxime
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH -next] media: cedrus: fix reference leak in cedrus_start_streaming
On Mon, Nov 02, 2020 at 03:18:38PM +0100, Maxime Ripard wrote:
> On Mon, Nov 02, 2020 at 10:26:22PM +0800, Zhang Qilong wrote:
> > pm_runtime_get_sync will increment pm usage counter even it
> > failed. Forgetting to pm_runtime_put_noidle will result in
> > reference leak in cedrus_start_streaming. We should fix it.
> >
> > Fixes: d5aecd289babf ("media: cedrus: Implement runtime PM")
> > Signed-off-by: Zhang Qilong
>
> Shouldn't we fix pm_runtime_get_sync instead then? It seems that most of
> the callers get this wrong, and that's definitely non-obvious.
>
> Maxime
The other bug that people run into is that pm_runtime_get_sync() can
return 1 on success.
drivers/spi/spi-img-spfi.c:734 img_spfi_resume() warn: pm_runtime_get_sync()
also returns 1 on success
drivers/mfd/arizona-core.c:49 arizona_clk32k_enable() warn:
pm_runtime_get_sync() also returns 1 on success
drivers/usb/dwc3/dwc3-pci.c:212 dwc3_pci_resume_work() warn:
pm_runtime_get_sync() also returns 1 on success
drivers/input/keyboard/omap4-keypad.c:279 omap4_keypad_probe() warn:
pm_runtime_get_sync() also returns 1 on success
drivers/gpu/drm/vc4/vc4_dsi.c:839 vc4_dsi_encoder_enable() warn:
pm_runtime_get_sync() also returns 1 on success
drivers/gpu/drm/i915/selftests/mock_gem_device.c:157 mock_gem_device() warn:
'pm_runtime_get_sync(&pdev->dev)' returns positive and negative
drivers/watchdog/rti_wdt.c:230 rti_wdt_probe() warn: pm_runtime_get_sync() also
returns 1 on success
drivers/media/platform/exynos4-is/mipi-csis.c:513 s5pcsis_s_stream() warn:
pm_runtime_get_sync() also returns 1 on success
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c:89 mtk_vcodec_dec_pw_on()
warn: pm_runtime_get_sync() also returns 1 on success
drivers/media/platform/ti-vpe/cal.c:794 cal_probe() warn: pm_runtime_get_sync()
also returns 1 on success
drivers/media/platform/ti-vpe/vpe.c:2478 vpe_runtime_get() warn:
pm_runtime_get_sync() also returns 1 on success
drivers/media/i2c/smiapp/smiapp-core.c:1529 smiapp_pm_get_init() warn:
pm_runtime_get_sync() also returns 1 on success
I don't really understand the point of incrementing the counter on
failure well enough to write a check for this...
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers: most: add ALSA sound driver
On Mon, Nov 02, 2020 at 04:14:03PM +0100, Christian Gromm wrote:
> This patch moves the ALSA sound driver out of the staging area and adds it
> to the stable part of the MOST driver. Modifications to the Makefiles and
> Kconfigs are done accordingly to not break the build.
>
> Signed-off-by: Christian Gromm
> ---
> drivers/most/Kconfig| 10 +
> drivers/most/Makefile | 1 +
> drivers/most/most_snd.c | 753
>
> drivers/staging/most/Kconfig| 2 -
> drivers/staging/most/Makefile | 1 -
> drivers/staging/most/sound/Kconfig | 14 -
> drivers/staging/most/sound/Makefile | 4 -
> drivers/staging/most/sound/sound.c | 753
>
> 8 files changed, 764 insertions(+), 774 deletions(-)
> create mode 100644 drivers/most/most_snd.c
> delete mode 100644 drivers/staging/most/sound/Kconfig
> delete mode 100644 drivers/staging/most/sound/Makefile
> delete mode 100644 drivers/staging/most/sound/sound.c
>
> diff --git a/drivers/most/Kconfig b/drivers/most/Kconfig
> index ebfe84e..4b8145b 100644
> --- a/drivers/most/Kconfig
> +++ b/drivers/most/Kconfig
> @@ -32,4 +32,14 @@ config MOST_CDEV
>
> To compile this driver as a module, choose M here: the
> module will be called most_cdev.
> +
> +config MOST_SND
> + tristate "Sound"
> + depends on SND
> + select SND_PCM
> + help
> + Say Y here if you want to commumicate via ALSA/sound devices.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called most_sound.
> endif
> diff --git a/drivers/most/Makefile b/drivers/most/Makefile
> index 8b53ca4..60db6cd 100644
> --- a/drivers/most/Makefile
> +++ b/drivers/most/Makefile
> @@ -5,3 +5,4 @@ most_core-y :=core.o \
>
> obj-$(CONFIG_MOST_USB_HDM) += most_usb.o
> obj-$(CONFIG_MOST_CDEV) += most_cdev.o
> +obj-$(CONFIG_MOST_SND) += most_snd.o
> diff --git a/drivers/most/most_snd.c b/drivers/most/most_snd.c
> new file mode 100644
> index 000..8a449ab
> --- /dev/null
> +++ b/drivers/most/most_snd.c
> @@ -0,0 +1,753 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * sound.c - Sound component for Mostcore
> + *
> + * Copyright (C) 2015 Microchip Technology Germany II GmbH & Co. KG
> + */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DRIVER_NAME "sound"
> +#define STRING_SIZE 80
> +
> +static struct most_component comp;
> +
> +/**
> + * struct channel - private structure to keep channel specific data
> + * @substream: stores the substream structure
> + * @iface: interface for which the channel belongs to
> + * @cfg: channel configuration
> + * @card: registered sound card
> + * @list: list for private use
> + * @id: channel index
> + * @period_pos: current period position (ring buffer)
> + * @buffer_pos: current buffer position (ring buffer)
> + * @is_stream_running: identifies whether a stream is running or not
> + * @opened: set when the stream is opened
> + * @playback_task: playback thread
> + * @playback_waitq: waitq used by playback thread
> + */
> +struct channel {
> + struct snd_pcm_substream *substream;
> + struct snd_pcm_hardware pcm_hardware;
> + struct most_interface *iface;
> + struct most_channel_config *cfg;
> + struct snd_card *card;
> + struct list_head list;
> + int id;
> + unsigned int period_pos;
> + unsigned int buffer_pos;
> + bool is_stream_running;
> + struct task_struct *playback_task;
> + wait_queue_head_t playback_waitq;
> + void (*copy_fn)(void *alsa, void *most, unsigned int bytes);
> +};
> +
> +struct sound_adapter {
> + struct list_head dev_list;
> + struct most_interface *iface;
> + struct snd_card *card;
> + struct list_head list;
> + bool registered;
> + int pcm_dev_idx;
> +};
> +
> +static struct list_head adpt_list;
> +
> +#define MOST_PCM_INFO (SNDRV_PCM_INFO_MMAP | \
> +SNDRV_PCM_INFO_MMAP_VALID | \
> +SNDRV_PCM_INFO_BATCH | \
> +SNDRV_PCM_INFO_INTERLEAVED | \
> +SNDRV_PCM_INFO_BLOCK_TRANSFER)
> +
> +#define swap16(val) ( \
> + (((u16)(val) << 8) & (u16)0xFF00) | \
> + (((u16)(val) >> 8) & (u16)0x00FF))
> +
> +#define swap32(val) ( \
> + (((u32)(val) << 24) & (u32)0xFF00) | \
> + (((u32)(val) << 8) & (u32)0x00FF) | \
> + (((u32)(val) >> 8) & (u32)0xFF00) | \
> + (((u32)(val) >> 24) & (u32)0x00FF))
Doesn't swab16() and swab32() work for this? I don't think you need to
reimplement these.
> +
> +static void swap_copy16(u16 *dest, const u16 *source, unsigned int bytes)
> +{
> + unsigned int i = 0;
> +
> + while (i < (bytes / 2)) {
> + dest[i] = swap16(source[i]);
> + i++;
> +
Re: [PATCH 01/23] dt-bindings: introduce silabs,wfx.yaml
Jérôme Pouiller writes: > On Tuesday 13 October 2020 18:49:35 CEST Rob Herring wrote: >> On Mon, Oct 12, 2020 at 12:46:26PM +0200, Jerome Pouiller wrote: >> > From: Jérôme Pouiller > [...] >> > + Note that in add of the properties below, the WFx driver also supports >> > + `mac-address` and `local-mac-address` as described in >> > + Documentation/devicetree/bindings/net/ethernet.txt >> >> Note what ethernet.txt contains... This should have a $ref to >> ethernet-controller.yaml to express the above. >> >> You can add 'mac-address: true' if you want to be explicit about what >> properties are used. > > Here, only mac-address and local-mac-address are supported. So, would the > code below do the job? > > local-mac-address: > $ref: ethernet-controller.yaml#/properties/local-mac-address > > mac-address: > $ref: ethernet-controller.yaml#/properties/mac-address > > > [...] >> > + spi-max-frequency: >> > +description: (SPI only) Maximum SPI clocking speed of device in Hz. >> >> No need to redefine a common property. > > When a property is specific to a bus, I would have like to explicitly > say it. That's why I redefined the description. > > > [...] >> > + config-file: >> > +description: Use an alternative file as PDS. Default is `wf200.pds`. >> > Only >> > + necessary for development/debug purpose. >> >> 'firmware-name' is typically what we'd use here. Though if just for >> debug/dev, perhaps do a debugfs interface for this instead. As DT should >> come from the firmware/bootloader, requiring changing the DT for >> dev/debug is not the easiest workflow compared to doing something from >> userspace. > > This file is not a firmware. It mainly contains data related to the > antenna. At the beginning, this property has been added for > development. With the time, I think it can be used to have one disk > image for several devices that differ only in antenna. > > I am going to remove the part about development/debug purpose. config-file doesn't sound right either. So what kind of data is this, calibration data or what? -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 07/23] wfx: add bus_sdio.c
Ulf Hansson writes:
> On Thu, 15 Oct 2020 at 16:03, Jérôme Pouiller
> wrote:
>>
>> On Wednesday 14 October 2020 14:43:34 CEST Pali Rohár wrote:
>> > On Wednesday 14 October 2020 13:52:15 Jérôme Pouiller wrote:
>> > > On Tuesday 13 October 2020 22:11:56 CEST Pali Rohár wrote:
>> > > > On Monday 12 October 2020 12:46:32 Jerome Pouiller wrote:
>> > > > > +#define SDIO_VENDOR_ID_SILABS0x
>> > > > > +#define SDIO_DEVICE_ID_SILABS_WF200 0x1000
>> > > > > +static const struct sdio_device_id wfx_sdio_ids[] = {
>> > > > > + { SDIO_DEVICE(SDIO_VENDOR_ID_SILABS,
>> > > > > SDIO_DEVICE_ID_SILABS_WF200) },
>> > > >
>> > > > Please move ids into common include file include/linux/mmc/sdio_ids.h
>> > > > where are all SDIO ids. Now all drivers have ids defined in that file.
>> > > >
>> > > > > + // FIXME: ignore VID/PID and only rely on device tree
>> > > > > + // { SDIO_DEVICE(SDIO_ANY_ID, SDIO_ANY_ID) },
>> > > >
>> > > > What is the reason for ignoring vendor and device ids?
>> > >
>> > > The device has a particularity, its VID/PID is :1000 (as you can see
>> > > above). This value is weird. The risk of collision with another device is
>> > > high.
>> >
>> > Those ids looks strange. You are from Silabs, can you check internally
>> > in Silabs if ids are really correct? And which sdio vendor id you in
>> > Silabs got assigned for your products?
>>
>> I confirm these ids are the ones burned in the WF200. We have to deal with
>> that :( .
>
> Yep. Unfortunately this isn't so uncommon when targeting the embedded
> types of devices.
>
> The good thing is, that we already have bindings allowing us to specify this.
>
>>
>>
>> > I know that sdio devices with multiple functions may have different sdio
>> > vendor/device id particular function and in common CIS (function 0).
>> >
>> > Could not be a problem that on one place is vendor/device id correct and
>> > on other place is that strange value?
>> >
>> > I have sent following patch (now part of upstream kernel) which exports
>> > these ids to userspace:
>> > https://lore.kernel.org/linux-mmc/20200527110858.17504-2-p...@kernel.org/T/#u
>> >
>> > Also for debugging ids and information about sdio cards, I sent another
>> > patch which export additional data:
>> > https://lore.kernel.org/linux-mmc/20200727133837.19086-1-p...@kernel.org/T/#u
>> >
>> > Could you try them and look at /sys/class/mmc_host/ attribute outputs?
>>
>> Here is:
>>
>> # cd /sys/class/mmc_host/ && grep -r . mmc1/
>> mmc1/power/runtime_suspended_time:0
>> grep: mmc1/power/autosuspend_delay_ms: Input/output error
>> mmc1/power/runtime_active_time:0
>> mmc1/power/control:auto
>> mmc1/power/runtime_status:unsupported
>> mmc1/mmc1:0001/vendor:0x
>> mmc1/mmc1:0001/rca:0x0001
>> mmc1/mmc1:0001/device:0x1000
>> mmc1/mmc1:0001/mmc1:0001:1/vendor:0x
>> mmc1/mmc1:0001/mmc1:0001:1/device:0x1000
>> grep: mmc1/mmc1:0001/mmc1:0001:1/info4: No data available
>> mmc1/mmc1:0001/mmc1:0001:1/power/runtime_suspended_time:0
>> grep: mmc1/mmc1:0001/mmc1:0001:1/power/autosuspend_delay_ms:
>> Input/output error
>> mmc1/mmc1:0001/mmc1:0001:1/power/runtime_active_time:0
>> mmc1/mmc1:0001/mmc1:0001:1/power/control:auto
>> mmc1/mmc1:0001/mmc1:0001:1/power/runtime_status:unsupported
>> mmc1/mmc1:0001/mmc1:0001:1/class:0x00
>> grep: mmc1/mmc1:0001/mmc1:0001:1/info2: No data available
>> mmc1/mmc1:0001/mmc1:0001:1/modalias:sdio:c00vd1000
>> mmc1/mmc1:0001/mmc1:0001:1/revision:0.0
>> mmc1/mmc1:0001/mmc1:0001:1/uevent:OF_NAME=mmc
>> mmc1/mmc1:0001/mmc1:0001:1/uevent:OF_FULLNAME=/soc/sdhci@7e30/mmc@1
>> mmc1/mmc1:0001/mmc1:0001:1/uevent:OF_COMPATIBLE_0=silabs,wfx-sdio
>> mmc1/mmc1:0001/mmc1:0001:1/uevent:OF_COMPATIBLE_N=1
>> mmc1/mmc1:0001/mmc1:0001:1/uevent:SDIO_CLASS=00
>> mmc1/mmc1:0001/mmc1:0001:1/uevent:SDIO_ID=:1000
>> mmc1/mmc1:0001/mmc1:0001:1/uevent:SDIO_REVISION=0.0
>> mmc1/mmc1:0001/mmc1:0001:1/uevent:MODALIAS=sdio:c00vd1000
>> grep: mmc1/mmc1:0001/mmc1:0001:1/info3: No data available
>> grep: mmc1/mmc1:0001/mmc1:0001:1/info1: No data available
>> mmc1/mmc1:0001/ocr:0x0020
>> grep: mmc1/mmc1:0001/info4: No data available
>> mmc1/mmc1:0001/power/runtime_suspended_time:0
>> grep: mmc1/mmc1:0001/power/autosuspend_delay_ms: Input/output error
>> mmc1/mmc1:0001/power/runtime_active_time:0
>> mmc1/mmc1:0001/power/control:auto
>> mmc1/mmc1:0001/power/runtime_status:unsupported
>> grep: mmc1/mmc1:0001/info2: No data available
>> mmc1/mmc1:0001/type:SDIO
>> mmc1/mmc1:0001/revision:0.0
>> mmc1/mmc1:0001/uevent:MMC_TYPE=SDIO
>> mmc1/mmc1:0001/uevent:SDIO_ID=:1000
>> mmc1/mmc1:0001/uevent:SDIO_REVISION=0.0
>> grep: mmc1/mmc1:0001/info3: No data available
>> grep: mmc1/mmc1:0001/info1: No data available
>>
>>
>
> Please have a look at the
> Documentation/devicetree/bindings/mmc/mmc-controller.yaml,
. ,,
Sincerely ask for your involvement in this transaction. If interested, write me back for further clarification Take note will also be a partner in this transaction as i can orderly see this transaction through. If you have any questions or if I can be of any assistance to you. Email: mailpatrick...@protonmail.com Regards Patrick Ho ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] drivers: most: add ALSA sound driver
This patch moves the ALSA sound driver out of the staging area and adds it
to the stable part of the MOST driver. Modifications to the Makefiles and
Kconfigs are done accordingly to not break the build.
Signed-off-by: Christian Gromm
---
drivers/most/Kconfig| 10 +
drivers/most/Makefile | 1 +
drivers/most/most_snd.c | 753
drivers/staging/most/Kconfig| 2 -
drivers/staging/most/Makefile | 1 -
drivers/staging/most/sound/Kconfig | 14 -
drivers/staging/most/sound/Makefile | 4 -
drivers/staging/most/sound/sound.c | 753
8 files changed, 764 insertions(+), 774 deletions(-)
create mode 100644 drivers/most/most_snd.c
delete mode 100644 drivers/staging/most/sound/Kconfig
delete mode 100644 drivers/staging/most/sound/Makefile
delete mode 100644 drivers/staging/most/sound/sound.c
diff --git a/drivers/most/Kconfig b/drivers/most/Kconfig
index ebfe84e..4b8145b 100644
--- a/drivers/most/Kconfig
+++ b/drivers/most/Kconfig
@@ -32,4 +32,14 @@ config MOST_CDEV
To compile this driver as a module, choose M here: the
module will be called most_cdev.
+
+config MOST_SND
+ tristate "Sound"
+ depends on SND
+ select SND_PCM
+ help
+ Say Y here if you want to commumicate via ALSA/sound devices.
+
+ To compile this driver as a module, choose M here: the
+ module will be called most_sound.
endif
diff --git a/drivers/most/Makefile b/drivers/most/Makefile
index 8b53ca4..60db6cd 100644
--- a/drivers/most/Makefile
+++ b/drivers/most/Makefile
@@ -5,3 +5,4 @@ most_core-y := core.o \
obj-$(CONFIG_MOST_USB_HDM) += most_usb.o
obj-$(CONFIG_MOST_CDEV) += most_cdev.o
+obj-$(CONFIG_MOST_SND) += most_snd.o
diff --git a/drivers/most/most_snd.c b/drivers/most/most_snd.c
new file mode 100644
index 000..8a449ab
--- /dev/null
+++ b/drivers/most/most_snd.c
@@ -0,0 +1,753 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * sound.c - Sound component for Mostcore
+ *
+ * Copyright (C) 2015 Microchip Technology Germany II GmbH & Co. KG
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_NAME "sound"
+#define STRING_SIZE80
+
+static struct most_component comp;
+
+/**
+ * struct channel - private structure to keep channel specific data
+ * @substream: stores the substream structure
+ * @iface: interface for which the channel belongs to
+ * @cfg: channel configuration
+ * @card: registered sound card
+ * @list: list for private use
+ * @id: channel index
+ * @period_pos: current period position (ring buffer)
+ * @buffer_pos: current buffer position (ring buffer)
+ * @is_stream_running: identifies whether a stream is running or not
+ * @opened: set when the stream is opened
+ * @playback_task: playback thread
+ * @playback_waitq: waitq used by playback thread
+ */
+struct channel {
+ struct snd_pcm_substream *substream;
+ struct snd_pcm_hardware pcm_hardware;
+ struct most_interface *iface;
+ struct most_channel_config *cfg;
+ struct snd_card *card;
+ struct list_head list;
+ int id;
+ unsigned int period_pos;
+ unsigned int buffer_pos;
+ bool is_stream_running;
+ struct task_struct *playback_task;
+ wait_queue_head_t playback_waitq;
+ void (*copy_fn)(void *alsa, void *most, unsigned int bytes);
+};
+
+struct sound_adapter {
+ struct list_head dev_list;
+ struct most_interface *iface;
+ struct snd_card *card;
+ struct list_head list;
+ bool registered;
+ int pcm_dev_idx;
+};
+
+static struct list_head adpt_list;
+
+#define MOST_PCM_INFO (SNDRV_PCM_INFO_MMAP | \
+ SNDRV_PCM_INFO_MMAP_VALID | \
+ SNDRV_PCM_INFO_BATCH | \
+ SNDRV_PCM_INFO_INTERLEAVED | \
+ SNDRV_PCM_INFO_BLOCK_TRANSFER)
+
+#define swap16(val) ( \
+ (((u16)(val) << 8) & (u16)0xFF00) | \
+ (((u16)(val) >> 8) & (u16)0x00FF))
+
+#define swap32(val) ( \
+ (((u32)(val) << 24) & (u32)0xFF00) | \
+ (((u32)(val) << 8) & (u32)0x00FF) | \
+ (((u32)(val) >> 8) & (u32)0xFF00) | \
+ (((u32)(val) >> 24) & (u32)0x00FF))
+
+static void swap_copy16(u16 *dest, const u16 *source, unsigned int bytes)
+{
+ unsigned int i = 0;
+
+ while (i < (bytes / 2)) {
+ dest[i] = swap16(source[i]);
+ i++;
+ }
+}
+
+static void swap_copy24(u8 *dest, const u8 *source, unsigned int bytes)
+{
+ unsigned int i = 0;
+
+ while (i < bytes - 2) {
+ dest[i] = source[i + 2];
+ dest[i + 1] = source[i + 1];
+ dest[i + 2] = source[i];
+ i += 3;
+ }
+}
+
+static void swap_copy32(u32 *dest, const u32 *source, unsi
[PATCH] staging: mt7621-dma: Prefer Using BIT Macro instead of left shifting on 1.
Replace left shifting on 1 by a BIT macro to fix checkpatch warning. Signed-off-by: Siddhant Gupta --- drivers/staging/mt7621-dma/mtk-hsdma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/mt7621-dma/mtk-hsdma.c b/drivers/staging/mt7621-dma/mtk-hsdma.c index 354536783e1c..a9e1a1b14035 100644 --- a/drivers/staging/mt7621-dma/mtk-hsdma.c +++ b/drivers/staging/mt7621-dma/mtk-hsdma.c @@ -72,7 +72,7 @@ #define HSDMA_GLO_TX_DMA BIT(0) #define HSDMA_BT_SIZE_16BYTES (0 << HSDMA_GLO_BT_SHIFT) -#define HSDMA_BT_SIZE_32BYTES (1 << HSDMA_GLO_BT_SHIFT) +#define HSDMA_BT_SIZE_32BYTES BIT(HSDMA_GLO_BT_SHIFT) #define HSDMA_BT_SIZE_64BYTES (2 << HSDMA_GLO_BT_SHIFT) #define HSDMA_BT_SIZE_128BYTES (3 << HSDMA_GLO_BT_SHIFT) -- 2.25.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: mt7621-dma: Prefer Using BIT Macro instead of left shifting on 1.
On Tue, Nov 03, 2020 at 01:04:02AM +0530, siddhant gupta(siddhant1223) wrote: > > Replace left shifting on 1 by a BIT macro to fix checkpatch warning. > > Signed-off-by: Siddhant Gupta > > --- > drivers/staging/mt7621-dma/mtk-hsdma.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/mt7621-dma/mtk-hsdma.c > b/drivers/staging/mt7621-dma/mtk-hsdma.c > index 354536783e1c..a9e1a1b14035 100644 > --- a/drivers/staging/mt7621-dma/mtk-hsdma.c > +++ b/drivers/staging/mt7621-dma/mtk-hsdma.c > @@ -72,7 +72,7 @@ > #define HSDMA_GLO_TX_DMA BIT(0) > > #define HSDMA_BT_SIZE_16BYTES(0 << HSDMA_GLO_BT_SHIFT) > -#define HSDMA_BT_SIZE_32BYTES(1 << HSDMA_GLO_BT_SHIFT) > +#define HSDMA_BT_SIZE_32BYTESBIT(HSDMA_GLO_BT_SHIFT) > #define HSDMA_BT_SIZE_64BYTES(2 << HSDMA_GLO_BT_SHIFT) > #define HSDMA_BT_SIZE_128BYTES (3 << HSDMA_GLO_BT_SHIFT) In looking at the code, does this change really make sense? (hint, I don't think so...) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: Add 024c:0627 to the list of SDIO device-ids
On Fri, Oct 30, 2020 at 10:25 AM Arend Van Spriel
wrote:
>
> On 10/29/2020 2:52 PM, Brian O'Keefe wrote:
> > Add 024c:0627 to the list of SDIO device-ids, based on hardware found in
> > the wild. This hardware exists on at least some Acer SW1-011 tablets.
> >
> > Signed-off-by: Brian O'Keefe
> > ---
> > drivers/staging/rtl8723bs/os_dep/sdio_intf.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
> > b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
> > index 5b1392deb0a7..7256d55fcc1b 100644
> > --- a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
> > +++ b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
> > @@ -21,6 +21,7 @@ static const struct sdio_device_id sdio_ids[] =
> > { SDIO_DEVICE(0x024c, 0x0525), },
> > { SDIO_DEVICE(0x024c, 0x0623), },
> > { SDIO_DEVICE(0x024c, 0x0626), },
> > + { SDIO_DEVICE(0x024c, 0x0627), },
> > { SDIO_DEVICE(0x024c, 0xb723), },
>
> shouldn't these be listed in include/linux/mmc/sdio_ids.h ?
It certainly looks that way; this was the only place that used hex
values in the SDIO_DEVICE macro directly. I'm happy to submit a
follow-up patch to create constants in sdio_ids.h and use those
instead.
>
> Regards,
> Arend
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: mt7621-pci: avoid to request pci bus resources
After upgrading kernel to version 5.9.x the driver was not
working anymore showing the following kernel trace:
...
mt7621-pci 1e14.pcie: resource collision:
[mem 0x6000-0x6fff] conflicts with pcie@1e14 [mem
0x6000-0x6fff]
[ cut here ]
WARNING: CPU: 2 PID: 73 at kernel/resource.c:1400
devm_request_resource+0xfc/0x10c
Modules linked in:
CPU: 2 PID: 73 Comm: kworker/2:1 Not tainted 5.9.2 #0
Workqueue: events deferred_probe_work_func
Stack : 8159 807d0a1c 808a 8fd49080
807d 0009 808ac820
0001 808338d0 7fff0001 800839dc 0049
0001 8fe51b00 367204ab
807d0a1c 807c 0001
80082358 8fe5 00559000
8fe519f1 0005
0001 807d
0009 808ac820 0001 808338d0 0001
803bf1b0 0008 81390008
Call Trace:
[<8000d018>] show_stack+0x30/0x100
[<8032e66c>] dump_stack+0xa4/0xd4
[<8002db1c>] __warn+0xc0/0x134
[<8002dbec>] warn_slowpath_fmt+0x5c/0xac
[<80033b34>] devm_request_resource+0xfc/0x10c
[<80365ff8>] devm_request_pci_bus_resources+0x58/0xdc
[<8048e13c>] mt7621_pci_probe+0x8dc/0xe48
[<803d2140>] platform_drv_probe+0x40/0x94
[<803cfd94>] really_probe+0x108/0x4ec
[<803cd958>] bus_for_each_drv+0x70/0xb0
[<803d0388>] __device_attach+0xec/0x164
[<803cec8c>] bus_probe_device+0xa4/0xc0
[<803cf1c4>] deferred_probe_work_func+0x80/0xc4
[<80048444>] process_one_work+0x260/0x510
[<80048a4c>] worker_thread+0x358/0x5cc
[<8004f7d0>] kthread+0x134/0x13c
[<80007478>] ret_from_kernel_thread+0x14/0x1c
---[ end trace a9dd2e37537510d3 ]---
mt7621-pci 1e14.pcie: Error requesting resources
mt7621-pci: probe of 1e14.pcie failed with error -16
...
With commit 669cbc708122 ("PCI: Move DT resource setup into
devm_pci_alloc_host_bridge()"), the DT 'ranges' is parsed and populated
into resources when the host bridge is allocated. The resources are
requested as well, but that happens a 2nd time for this driver in
mt7621_pcie_request_resources(). Hence we should avoid this second
request.
Also, the bus ranges was also populated by default, so we can remove
it from mt7621_pcie_request_resources() to avoid the following trace
if we don't avoid it:
pci_bus :00: busn_res: can not insert [bus 00-ff]
under domain [bus 00-ff] (conflicts with (null) [bus 00-ff])
Function 'mt7621_pcie_request_resources' has been renamed into
'mt7621_pcie_add_resources' which now is a more accurate name
for this function.
Cc: sta...@vger.kernel.org#5.9.x-
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt7621-pci/pci-mt7621.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c
b/drivers/staging/mt7621-pci/pci-mt7621.c
index f961b353c22e..8831db383fad 100644
--- a/drivers/staging/mt7621-pci/pci-mt7621.c
+++ b/drivers/staging/mt7621-pci/pci-mt7621.c
@@ -653,16 +653,11 @@ static int mt7621_pcie_init_virtual_bridges(struct
mt7621_pcie *pcie)
return 0;
}
-static int mt7621_pcie_request_resources(struct mt7621_pcie *pcie,
-struct list_head *res)
+static void mt7621_pcie_add_resources(struct mt7621_pcie *pcie,
+ struct list_head *res)
{
- struct device *dev = pcie->dev;
-
pci_add_resource_offset(res, &pcie->io, pcie->offset.io);
pci_add_resource_offset(res, &pcie->mem, pcie->offset.mem);
- pci_add_resource(res, &pcie->busn);
-
- return devm_request_pci_bus_resources(dev, res);
}
static int mt7621_pcie_register_host(struct pci_host_bridge *host,
@@ -738,11 +733,7 @@ static int mt7621_pci_probe(struct platform_device *pdev)
setup_cm_memory_region(pcie);
- err = mt7621_pcie_request_resources(pcie, &res);
- if (err) {
- dev_err(dev, "Error requesting resources\n");
- return err;
- }
+ mt7621_pcie_add_resources(pcie, &res);
err = mt7621_pcie_register_host(bridge, &res);
if (err) {
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[staging:staging-next] BUILD SUCCESS 83e63b2cc416904b50895eeee8d8e0d7ea0418fe
ge_imp3a_defconfig powerpc mpc8313_rdb_defconfig powerpcgamecube_defconfig powerpc tqm8541_defconfig shecovec24-romimage_defconfig sh sh7770_generic_defconfig armmulti_v5_defconfig h8300 edosk2674_defconfig sh sh2007_defconfig ia64 alldefconfig mips cobalt_defconfig microblazenommu_defconfig arm gemini_defconfig sparc sparc32_defconfig powerpc allnoconfig powerpc tqm8xx_defconfig powerpc chrp32_defconfig shedosk7760_defconfig riscvalldefconfig m68kmvme147_defconfig mips ip27_defconfig xtensasmp_lx200_defconfig m68k sun3_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig s390 allyesconfig parisc allyesconfig s390defconfig sparcallyesconfig sparc defconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig i386 randconfig-a004-20201102 i386 randconfig-a006-20201102 i386 randconfig-a005-20201102 i386 randconfig-a001-20201102 i386 randconfig-a002-20201102 i386 randconfig-a003-20201102 i386 randconfig-a004-20201101 i386 randconfig-a006-20201101 i386 randconfig-a005-20201101 i386 randconfig-a001-20201101 i386 randconfig-a002-20201101 i386 randconfig-a003-20201101 x86_64 randconfig-a012-20201102 x86_64 randconfig-a015-20201102 x86_64 randconfig-a011-20201102 x86_64 randconfig-a013-20201102 x86_64 randconfig-a014-20201102 x86_64 randconfig-a016-20201102 i386 randconfig-a013-20201102 i386 randconfig-a015-20201102 i386 randconfig-a014-20201102 i386 randconfig-a016-20201102 i386 randconfig-a011-20201102 i386 randconfig-a012-20201102 riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig x86_64 rhel x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec clang tested configs: x86_64 randconfig-a004-20201102 x86_64 randconfig-a005-20201102 x86_64 randconfig-a003-20201102 x86_64 randconfig-a002-20201102 x86_64 randconfig-a006-20201102 x86_64 randconfig-a001-20201102 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[driver-core:driver-core-linus] BUILD SUCCESS 9d4fdda3344611ec53ededccc0c13cb149ba4375
multi_v5_defconfig powerpc tqm5200_defconfig powerpc lite5200b_defconfig m68kmvme147_defconfig c6x defconfig sh sh7710voipgw_defconfig mips ip27_defconfig xtensasmp_lx200_defconfig m68k sun3_defconfig powerpccell_defconfig arm pxa3xx_defconfig arm cns3420vb_defconfig arm colibri_pxa270_defconfig m68k allyesconfig ia64 allmodconfig ia64defconfig m68k allmodconfig m68kdefconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allmodconfig powerpc allyesconfig powerpc allnoconfig i386 randconfig-a004-20201102 i386 randconfig-a006-20201102 i386 randconfig-a005-20201102 i386 randconfig-a001-20201102 i386 randconfig-a002-20201102 i386 randconfig-a003-20201102 x86_64 randconfig-a012-20201102 x86_64 randconfig-a015-20201102 x86_64 randconfig-a011-20201102 x86_64 randconfig-a013-20201102 x86_64 randconfig-a014-20201102 x86_64 randconfig-a016-20201102 i386 randconfig-a013-20201102 i386 randconfig-a015-20201102 i386 randconfig-a014-20201102 i386 randconfig-a016-20201102 i386 randconfig-a011-20201102 i386 randconfig-a012-20201102 riscvnommu_k210_defconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec clang tested configs: x86_64 randconfig-a004-20201102 x86_64 randconfig-a005-20201102 x86_64 randconfig-a003-20201102 x86_64 randconfig-a002-20201102 x86_64 randconfig-a006-20201102 x86_64 randconfig-a001-20201102 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[staging:staging-testing] BUILD SUCCESS 9364a2cf567187c0a075942c22d1f434c758de5d
sh7710voipgw_defconfig arm pxa3xx_defconfig arm cns3420vb_defconfig arm colibri_pxa270_defconfig m68k allyesconfig ia64 allmodconfig ia64defconfig m68k allmodconfig m68kdefconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allmodconfig powerpc allyesconfig powerpc allnoconfig i386 randconfig-a004-20201102 i386 randconfig-a006-20201102 i386 randconfig-a005-20201102 i386 randconfig-a001-20201102 i386 randconfig-a002-20201102 i386 randconfig-a003-20201102 x86_64 randconfig-a012-20201102 x86_64 randconfig-a015-20201102 x86_64 randconfig-a011-20201102 x86_64 randconfig-a013-20201102 x86_64 randconfig-a014-20201102 x86_64 randconfig-a016-20201102 i386 randconfig-a013-20201102 i386 randconfig-a014-20201102 i386 randconfig-a016-20201102 i386 randconfig-a011-20201102 i386 randconfig-a012-20201102 i386 randconfig-a015-20201102 riscvallyesconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec clang tested configs: x86_64 randconfig-a004-20201102 x86_64 randconfig-a005-20201102 x86_64 randconfig-a003-20201102 x86_64 randconfig-a002-20201102 x86_64 randconfig-a006-20201102 x86_64 randconfig-a001-20201102 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH AUTOSEL 5.9 29/35] staging: mmal-vchiq: Fix memory leak for vchiq_instance
From: Seung-Woo Kim
[ Upstream commit b6ae84d648954fae096d94faea1ddb6518b27841 ]
The vchiq_instance is allocated with vchiq_initialise() but never
freed properly. Fix memory leak for the vchiq_instance.
Reported-by: Jaehoon Chung
Signed-off-by: Seung-Woo Kim
Link:
https://lore.kernel.org/r/1603706150-10806-1-git-send-email-sw0312@samsung.com
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
.../vc04_services/vchiq-mmal/mmal-vchiq.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
index e798d494f00ff..bbf033ca47362 100644
--- a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
+++ b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
@@ -179,6 +179,9 @@ struct vchiq_mmal_instance {
/* ordered workqueue to process all bulk operations */
struct workqueue_struct *bulk_wq;
+
+ /* handle for a vchiq instance */
+ struct vchiq_instance *vchiq_instance;
};
static struct mmal_msg_context *
@@ -1840,6 +1843,7 @@ int vchiq_mmal_finalise(struct vchiq_mmal_instance
*instance)
mutex_unlock(&instance->vchiq_mutex);
+ vchiq_shutdown(instance->vchiq_instance);
flush_workqueue(instance->bulk_wq);
destroy_workqueue(instance->bulk_wq);
@@ -1856,6 +1860,7 @@ EXPORT_SYMBOL_GPL(vchiq_mmal_finalise);
int vchiq_mmal_init(struct vchiq_mmal_instance **out_instance)
{
int status;
+ int err = -ENODEV;
struct vchiq_mmal_instance *instance;
static struct vchiq_instance *vchiq_instance;
struct vchiq_service_params params = {
@@ -1890,17 +1895,21 @@ int vchiq_mmal_init(struct vchiq_mmal_instance
**out_instance)
status = vchiq_connect(vchiq_instance);
if (status) {
pr_err("Failed to connect VCHI instance (status=%d)\n", status);
- return -EIO;
+ err = -EIO;
+ goto err_shutdown_vchiq;
}
instance = kzalloc(sizeof(*instance), GFP_KERNEL);
- if (!instance)
- return -ENOMEM;
+ if (!instance) {
+ err = -ENOMEM;
+ goto err_shutdown_vchiq;
+ }
mutex_init(&instance->vchiq_mutex);
instance->bulk_scratch = vmalloc(PAGE_SIZE);
+ instance->vchiq_instance = vchiq_instance;
mutex_init(&instance->context_map_lock);
idr_init_base(&instance->context_map, 1);
@@ -1932,7 +1941,9 @@ int vchiq_mmal_init(struct vchiq_mmal_instance
**out_instance)
err_free:
vfree(instance->bulk_scratch);
kfree(instance);
- return -ENODEV;
+err_shutdown_vchiq:
+ vchiq_shutdown(vchiq_instance);
+ return err;
}
EXPORT_SYMBOL_GPL(vchiq_mmal_init);
--
2.27.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers: most: add ALSA sound driver
On Mon, 2020-11-02 at 16:31 +0100, Greg KH wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
>
> On Mon, Nov 02, 2020 at 04:14:03PM +0100, Christian Gromm wrote:
> > This patch moves the ALSA sound driver out of the staging area and
> > adds it
> > to the stable part of the MOST driver. Modifications to the
> > Makefiles and
> > Kconfigs are done accordingly to not break the build.
> >
> > Signed-off-by: Christian Gromm
> > ---
> > drivers/most/Kconfig| 10 +
> > drivers/most/Makefile | 1 +
> > drivers/most/most_snd.c | 753
> >
> > drivers/staging/most/Kconfig| 2 -
> > drivers/staging/most/Makefile | 1 -
> > drivers/staging/most/sound/Kconfig | 14 -
> > drivers/staging/most/sound/Makefile | 4 -
> > drivers/staging/most/sound/sound.c | 753
> >
> > 8 files changed, 764 insertions(+), 774 deletions(-)
> > create mode 100644 drivers/most/most_snd.c
> > delete mode 100644 drivers/staging/most/sound/Kconfig
> > delete mode 100644 drivers/staging/most/sound/Makefile
> > delete mode 100644 drivers/staging/most/sound/sound.c
> >
> > diff --git a/drivers/most/Kconfig b/drivers/most/Kconfig
> > index ebfe84e..4b8145b 100644
> > --- a/drivers/most/Kconfig
> > +++ b/drivers/most/Kconfig
> > @@ -32,4 +32,14 @@ config MOST_CDEV
> >
> > To compile this driver as a module, choose M here: the
> > module will be called most_cdev.
> > +
> > +config MOST_SND
> > + tristate "Sound"
> > + depends on SND
> > + select SND_PCM
> > + help
> > + Say Y here if you want to commumicate via ALSA/sound
> > devices.
> > +
> > + To compile this driver as a module, choose M here: the
> > + module will be called most_sound.
> > endif
> > diff --git a/drivers/most/Makefile b/drivers/most/Makefile
> > index 8b53ca4..60db6cd 100644
> > --- a/drivers/most/Makefile
> > +++ b/drivers/most/Makefile
> > @@ -5,3 +5,4 @@ most_core-y :=core.o \
> >
> > obj-$(CONFIG_MOST_USB_HDM) += most_usb.o
> > obj-$(CONFIG_MOST_CDEV) += most_cdev.o
> > +obj-$(CONFIG_MOST_SND) += most_snd.o
> > diff --git a/drivers/most/most_snd.c b/drivers/most/most_snd.c
> > new file mode 100644
> > index 000..8a449ab
> > --- /dev/null
> > +++ b/drivers/most/most_snd.c
> > @@ -0,0 +1,753 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * sound.c - Sound component for Mostcore
> > + *
> > + * Copyright (C) 2015 Microchip Technology Germany II GmbH & Co.
> > KG
> > + */
> > +
> > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define DRIVER_NAME "sound"
> > +#define STRING_SIZE 80
> > +
> > +static struct most_component comp;
> > +
> > +/**
> > + * struct channel - private structure to keep channel specific
> > data
> > + * @substream: stores the substream structure
> > + * @iface: interface for which the channel belongs to
> > + * @cfg: channel configuration
> > + * @card: registered sound card
> > + * @list: list for private use
> > + * @id: channel index
> > + * @period_pos: current period position (ring buffer)
> > + * @buffer_pos: current buffer position (ring buffer)
> > + * @is_stream_running: identifies whether a stream is running or
> > not
> > + * @opened: set when the stream is opened
> > + * @playback_task: playback thread
> > + * @playback_waitq: waitq used by playback thread
> > + */
> > +struct channel {
> > + struct snd_pcm_substream *substream;
> > + struct snd_pcm_hardware pcm_hardware;
> > + struct most_interface *iface;
> > + struct most_channel_config *cfg;
> > + struct snd_card *card;
> > + struct list_head list;
> > + int id;
> > + unsigned int period_pos;
> > + unsigned int buffer_pos;
> > + bool is_stream_running;
> > + struct task_struct *playback_task;
> > + wait_queue_head_t playback_waitq;
> > + void (*copy_fn)(void *alsa, void *most, unsigned int bytes);
> > +};
> > +
> > +struct sound_adapter {
> > + struct list_head dev_list;
> > + struct most_interface *iface;
> > + struct snd_card *card;
> > + struct list_head list;
> > + bool registered;
> > + int pcm_dev_idx;
> > +};
> > +
> > +static struct list_head adpt_list;
> > +
> > +#define MOST_PCM_INFO (SNDRV_PCM_INFO_MMAP | \
> > +SNDRV_PCM_INFO_MMAP_VALID | \
> > +SNDRV_PCM_INFO_BATCH | \
> > +SNDRV_PCM_INFO_INTERLEAVED | \
> > +SNDRV_PCM_INFO_BLOCK_TRANSFER)
> > +
> > +#define swap16(val) ( \
> > + (((u16)(val) << 8) & (u16)0xFF00) | \
> > + (((u16)(val) >> 8) & (u16)0x00FF))
> > +
> > +#define swap32(val) ( \
> > + (((u32)(val) << 24) & (u32)0xFF00) | \
> > + (((u32)(val)
Re: [PATCH] staging: mt7621-dma: Prefer Using BIT Macro instead of left shifting on 1.
On Tue, 3 Nov 2020 at 01:10, Greg KH wrote: > > On Tue, Nov 03, 2020 at 01:04:02AM +0530, siddhant gupta(siddhant1223) wrote: > > > > Replace left shifting on 1 by a BIT macro to fix checkpatch warning. > > > > Signed-off-by: Siddhant Gupta > > > > --- > > drivers/staging/mt7621-dma/mtk-hsdma.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/staging/mt7621-dma/mtk-hsdma.c > > b/drivers/staging/mt7621-dma/mtk-hsdma.c > > index 354536783e1c..a9e1a1b14035 100644 > > --- a/drivers/staging/mt7621-dma/mtk-hsdma.c > > +++ b/drivers/staging/mt7621-dma/mtk-hsdma.c > > @@ -72,7 +72,7 @@ > > #define HSDMA_GLO_TX_DMA BIT(0) > > > > #define HSDMA_BT_SIZE_16BYTES(0 << HSDMA_GLO_BT_SHIFT) > > -#define HSDMA_BT_SIZE_32BYTES(1 << HSDMA_GLO_BT_SHIFT) > > +#define HSDMA_BT_SIZE_32BYTESBIT(HSDMA_GLO_BT_SHIFT) > > #define HSDMA_BT_SIZE_64BYTES(2 << HSDMA_GLO_BT_SHIFT) > > #define HSDMA_BT_SIZE_128BYTES (3 << HSDMA_GLO_BT_SHIFT) > > In looking at the code, does this change really make sense? > > (hint, I don't think so...) Following Checkpatch, I thought it might be good to do as checkpatch said, but the code looks better and more readable without the change. This is my first patch and also a lesson that i should not fix every checkpatch warnings. I'll pick something better next time Thanks for your comment . ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers: most: add ALSA sound driver
On Mon, Nov 02, 2020 at 11:17:40PM +, christian.gr...@microchip.com wrote:
> On Mon, 2020-11-02 at 16:31 +0100, Greg KH wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you
> > know the content is safe
> >
> > On Mon, Nov 02, 2020 at 04:14:03PM +0100, Christian Gromm wrote:
> > > This patch moves the ALSA sound driver out of the staging area and
> > > adds it
> > > to the stable part of the MOST driver. Modifications to the
> > > Makefiles and
> > > Kconfigs are done accordingly to not break the build.
> > >
> > > Signed-off-by: Christian Gromm
> > > ---
> > > drivers/most/Kconfig| 10 +
> > > drivers/most/Makefile | 1 +
> > > drivers/most/most_snd.c | 753
> > >
> > > drivers/staging/most/Kconfig| 2 -
> > > drivers/staging/most/Makefile | 1 -
> > > drivers/staging/most/sound/Kconfig | 14 -
> > > drivers/staging/most/sound/Makefile | 4 -
> > > drivers/staging/most/sound/sound.c | 753
> > >
> > > 8 files changed, 764 insertions(+), 774 deletions(-)
> > > create mode 100644 drivers/most/most_snd.c
> > > delete mode 100644 drivers/staging/most/sound/Kconfig
> > > delete mode 100644 drivers/staging/most/sound/Makefile
> > > delete mode 100644 drivers/staging/most/sound/sound.c
> > >
> > > diff --git a/drivers/most/Kconfig b/drivers/most/Kconfig
> > > index ebfe84e..4b8145b 100644
> > > --- a/drivers/most/Kconfig
> > > +++ b/drivers/most/Kconfig
> > > @@ -32,4 +32,14 @@ config MOST_CDEV
> > >
> > > To compile this driver as a module, choose M here: the
> > > module will be called most_cdev.
> > > +
> > > +config MOST_SND
> > > + tristate "Sound"
> > > + depends on SND
> > > + select SND_PCM
> > > + help
> > > + Say Y here if you want to commumicate via ALSA/sound
> > > devices.
> > > +
> > > + To compile this driver as a module, choose M here: the
> > > + module will be called most_sound.
> > > endif
> > > diff --git a/drivers/most/Makefile b/drivers/most/Makefile
> > > index 8b53ca4..60db6cd 100644
> > > --- a/drivers/most/Makefile
> > > +++ b/drivers/most/Makefile
> > > @@ -5,3 +5,4 @@ most_core-y :=core.o \
> > >
> > > obj-$(CONFIG_MOST_USB_HDM) += most_usb.o
> > > obj-$(CONFIG_MOST_CDEV) += most_cdev.o
> > > +obj-$(CONFIG_MOST_SND) += most_snd.o
> > > diff --git a/drivers/most/most_snd.c b/drivers/most/most_snd.c
> > > new file mode 100644
> > > index 000..8a449ab
> > > --- /dev/null
> > > +++ b/drivers/most/most_snd.c
> > > @@ -0,0 +1,753 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * sound.c - Sound component for Mostcore
> > > + *
> > > + * Copyright (C) 2015 Microchip Technology Germany II GmbH & Co.
> > > KG
> > > + */
> > > +
> > > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#define DRIVER_NAME "sound"
> > > +#define STRING_SIZE 80
> > > +
> > > +static struct most_component comp;
> > > +
> > > +/**
> > > + * struct channel - private structure to keep channel specific
> > > data
> > > + * @substream: stores the substream structure
> > > + * @iface: interface for which the channel belongs to
> > > + * @cfg: channel configuration
> > > + * @card: registered sound card
> > > + * @list: list for private use
> > > + * @id: channel index
> > > + * @period_pos: current period position (ring buffer)
> > > + * @buffer_pos: current buffer position (ring buffer)
> > > + * @is_stream_running: identifies whether a stream is running or
> > > not
> > > + * @opened: set when the stream is opened
> > > + * @playback_task: playback thread
> > > + * @playback_waitq: waitq used by playback thread
> > > + */
> > > +struct channel {
> > > + struct snd_pcm_substream *substream;
> > > + struct snd_pcm_hardware pcm_hardware;
> > > + struct most_interface *iface;
> > > + struct most_channel_config *cfg;
> > > + struct snd_card *card;
> > > + struct list_head list;
> > > + int id;
> > > + unsigned int period_pos;
> > > + unsigned int buffer_pos;
> > > + bool is_stream_running;
> > > + struct task_struct *playback_task;
> > > + wait_queue_head_t playback_waitq;
> > > + void (*copy_fn)(void *alsa, void *most, unsigned int bytes);
> > > +};
> > > +
> > > +struct sound_adapter {
> > > + struct list_head dev_list;
> > > + struct most_interface *iface;
> > > + struct snd_card *card;
> > > + struct list_head list;
> > > + bool registered;
> > > + int pcm_dev_idx;
> > > +};
> > > +
> > > +static struct list_head adpt_list;
> > > +
> > > +#define MOST_PCM_INFO (SNDRV_PCM_INFO_MMAP | \
> > > +SNDRV_PCM_INFO_MMAP_VALID | \
> > > +SNDRV_PCM_INFO_BATCH
