* [PATCH 01/33] clk_ops: change round_rate() to return unsigned long
From: Stephen Boyd @ 2018-01-02 23:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c2212d56-a8b5-cba5-46a7-c2c7f66e752b@nexus-software.ie>
On 01/02, Bryan O'Donoghue wrote:
> On 02/01/18 19:01, Stephen Boyd wrote:
> >On 12/31, Bryan O'Donoghue wrote:
> >>On 30/12/17 16:36, Mikko Perttunen wrote:
> >>>FWIW, we had this problem some years ago with the Tegra CPU clock
> >>>- then it was determined that a simpler solution was to have the
> >>>determine_rate callback support unsigned long rates - so clock
> >>>drivers that need to return rates higher than 2^31 can instead
> >>>implement the determine_rate callback. That is what's currently
> >>>implemented.
> >>>
> >>>Mikko
> >>
> >>Granted we could work around it but, having both zero and less than
> >>zero indicate error means you can't support larger than LONG_MAX
> >>which is I think worth fixing.
> >>
> >
> >Ok. But can you implement the determine_rate op instead of the
> >round_rate op for your clk?
>
> Don't know .
Please try.
>
> >It's not a work-around, it's the
> >preferred solution. That would allow rates larger than 2^31 for
> >the clk without pushing through a change to all the drivers to
> >express zero as "error" and non-zero as the rounded rate.
> >
> >I'm not entirely opposed to this approach, because we probably
> >don't care to pass the particular error value from a clk provider
> >to a clk consumer about what the error is.
>
> Which was my thought. The return value of clk_ops->round_rate()
> appears not to get pushed up the stack, which is what the last patch
> in this series deals with.
>
> [PATCH 33/33] clk: change handling of round_rate() such that only
> zero is an error
Hmm? clk_core_determine_round_nolock() returns 'rate' if rate < 0
from the round_rate op. clk_core_round_rate_nolock() returns that
value to clk_round_rate() which returns it to the consumer.
>
> >It's actually what we
> >proposed as the solution for clk_round_rate() to return values
> >larger than LONG_MAX to consumers. But doing that consumer API
> >change or this provider side change is going to require us to
> >evaluate all the consumers of these clks to make sure they don't
> >check for some error value that's less than zero. This series
> >does half the work,
>
> Do you mean users of clk_rounda_rate() ? I have a set of patches for
> that but wanted to separate that from clk_ops->round_rate() so as
> not to send ~70 patches out to LKML at once - even if they are in
> two blocks.
Ok. What have you done to the consumers of clk_round_rate()?
Made them treat 0 as an error instead of less than zero? The
documentation in clk.h needs to be updated. See this patch from
Paul Wamsley[1] for one proposed patch that went nowhere. Also
include Russell King please. It was also proposed to change the
function signature of clk_round_rate() to return unsigned long,
but that didn't go anywhere either.
>
> If so, I can publish that set too for reference.
>
> AFAICT on clk_ops->round_rate the last patch #33 ought to cover the
> usage of the return value of clk_ops->round_rate().
>
> Have I missed something ?
Hopefully not!
>
> >by changing the provider side, while ignoring
> >the consumer side and any potential fallout of the less than zero
> >to zero return value change.
> >
>
> Can you look at #33 ? I'm not sure if you saw that one.
>
Yeah I looked at it. From what I can tell it makes
clk_round_rate() return 0 now instead of whatever negative value
the clk_ops::round_rate function returns.
[1] https://lkml.kernel.org/r/alpine.DEB.2.02.1311251603310.23090 at tamien
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [RESEND PATCH v2 11/15] ASoC: qcom: qdsp6: Add support to q6afe dai driver
From: Bjorn Andersson @ 2018-01-02 23:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214173402.19074-12-srinivas.kandagatla@linaro.org>
On Thu 14 Dec 09:33 PST 2017, srinivas.kandagatla at linaro.org wrote:
> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>
> This patch adds support to q6afe backend dais driver.
>
Isn't the list of backend DAIs platform-dependent?
[..]
> +static const struct snd_soc_dapm_widget hdmi_dapm_widgets[] = {
> + SND_SOC_DAPM_AIF_OUT("HDMI", "HDMI Playback", 0, 0, 0, 0),
> + SND_SOC_DAPM_OUTPUT("HDMI-RX"),
> +};
> +
> +static const struct snd_soc_component_driver msm_dai_hdmi_q6_component = {
How will this look beyond HDMI? I'm having issues mapping this to
downstream.
> + .name = "msm-dai-q6-hdmi",
> + .dapm_widgets = hdmi_dapm_widgets,
> + .num_dapm_widgets = ARRAY_SIZE(hdmi_dapm_widgets),
> + .controls = hdmi_config_controls,
> + .num_controls = ARRAY_SIZE(hdmi_config_controls),
> + .dapm_routes = hdmi_dapm_routes,
> + .num_dapm_routes = ARRAY_SIZE(hdmi_dapm_routes),
> +};
> +
Regards,
Bjorn
^ permalink raw reply
* [PATCH 1/8] ARM: dts: keystone: Move keystone_irq to under device-state-control
From: Suman Anna @ 2018-01-02 23:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180102170202.15045-2-afd@ti.com>
Hi Andrew,
On 01/02/2018 11:01 AM, Andrew F. Davis wrote:
> The keystone_irq node describes a device that is a component of the device
> state control module.
I would prefer 'address space' to be added to this statement as this
module is really not a single IP but really a collection of different
register sets providing different functionalities. Some of these
comments apply to the following patches as well.
As such, it should not be a member of soc0 bus
> but instead a sub-node of device-state-control.
>
> This move also fixes a warning about not having a reg property. Now
> that this is a sub-node of device-state-control, a syscon type node,
> we add this reg property but relative to the syscon base, this way
> when the dt-binding/driver are updated we can drop the non-standard
> ti,syscon-dev property completely and simply use get_resource() in
> the driver.
Please add an appropriate 'ranges' property in the parent node following
the parent-child node convention, it's upto individual drivers to use
the appropriate API for whether they want to deal with the offset or the
actual bus addresses. You should not tie this into forcing to use a
get_resource() without ranges to get the offset.
>
> Signed-off-by: Andrew F. Davis <afd@ti.com>
> Acked-by: Nishanth Menon <nm@ti.com>
> ---
> arch/arm/boot/dts/keystone.dtsi | 21 ++++++++++++---------
> 1 file changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
> index 93ea5c69ea77..158e0a903f7e 100644
> --- a/arch/arm/boot/dts/keystone.dtsi
> +++ b/arch/arm/boot/dts/keystone.dtsi
> @@ -87,8 +87,19 @@
> };
>
> devctrl: device-state-control at 2620000 {
> - compatible = "ti,keystone-devctrl", "syscon";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "ti,keystone-devctrl", "syscon", "simple-mfd";
nit, can you please maintain the current order of compatible and reg,
and add the new properties after them.
regards
Suman
> reg = <0x02620000 0x1000>;
> +
> + kirq0: keystone_irq at 2a0 {
> + compatible = "ti,keystone-irq";
> + reg = <0x2a0 0x4>;
> + interrupts = <GIC_SPI 4 IRQ_TYPE_EDGE_RISING>;
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + ti,syscon-dev = <&devctrl 0x2a0>;
> + };
> };
>
> rstctrl: reset-controller {
> @@ -282,14 +293,6 @@
> 1 0 0x21000A00 0x00000100>;
> };
>
> - kirq0: keystone_irq at 26202a0 {
> - compatible = "ti,keystone-irq";
> - interrupts = <GIC_SPI 4 IRQ_TYPE_EDGE_RISING>;
> - interrupt-controller;
> - #interrupt-cells = <1>;
> - ti,syscon-dev = <&devctrl 0x2a0>;
> - };
> -
> pcie0: pcie at 21800000 {
> compatible = "ti,keystone-pcie", "snps,dw-pcie";
> clocks = <&clkpcie>;
>
^ permalink raw reply
* [PATCH v7 02/10] module: allow symbol exports to be disabled
From: Nicolas Pitre @ 2018-01-02 23:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180102200549.22984-3-ard.biesheuvel@linaro.org>
On Tue, 2 Jan 2018, Ard Biesheuvel wrote:
> To allow existing C code to be incorporated into the decompressor or
> the UEFI stub, introduce a CPP macro that turns all EXPORT_SYMBOL_xxx
> declarations into nops, and #define it in places where such exports
> are undesirable. Note that this gets rid of a rather dodgy redefine
> of linux/export.h's header guard.
[...]
> --- a/include/linux/export.h
> +++ b/include/linux/export.h
> @@ -83,6 +83,15 @@ extern struct module __this_module;
> */
> #define __EXPORT_SYMBOL(sym, sec) === __KSYM_##sym ===
>
> +#elif defined(__DISABLE_EXPORTS)
> +
> +/*
> + * Allow symbol exports to be disabled completely so that C code may
> + * be reused in other execution contexts such as the UEFI stub or the
> + * decompressor.
> + */
> +#define __EXPORT_SYMBOL(sym, sec)
> +
I think you should rather put this first thing in the #if sequence so to
override the defined(__KSYM_DEPS__) case too. No need to create build
dependencies for module symbols that you're going to stub out
afterwards anyway.
Nicolas
^ permalink raw reply
* [PATCH v7 02/10] module: allow symbol exports to be disabled
From: Ard Biesheuvel @ 2018-01-02 23:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <nycvar.YSQ.7.76.1801021841410.8567@knanqh.ubzr>
On 2 January 2018 at 23:47, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Tue, 2 Jan 2018, Ard Biesheuvel wrote:
>
>> To allow existing C code to be incorporated into the decompressor or
>> the UEFI stub, introduce a CPP macro that turns all EXPORT_SYMBOL_xxx
>> declarations into nops, and #define it in places where such exports
>> are undesirable. Note that this gets rid of a rather dodgy redefine
>> of linux/export.h's header guard.
> [...]
>
>> --- a/include/linux/export.h
>> +++ b/include/linux/export.h
>> @@ -83,6 +83,15 @@ extern struct module __this_module;
>> */
>> #define __EXPORT_SYMBOL(sym, sec) === __KSYM_##sym ===
>>
>> +#elif defined(__DISABLE_EXPORTS)
>> +
>> +/*
>> + * Allow symbol exports to be disabled completely so that C code may
>> + * be reused in other execution contexts such as the UEFI stub or the
>> + * decompressor.
>> + */
>> +#define __EXPORT_SYMBOL(sym, sec)
>> +
>
> I think you should rather put this first thing in the #if sequence so to
> override the defined(__KSYM_DEPS__) case too. No need to create build
> dependencies for module symbols that you're going to stub out
> afterwards anyway.
>
I wasn't sure, so thanks for clearing that up.
^ permalink raw reply
* [RESEND PATCH v2 12/15] ASoC: qcom: qdsp6: Add support to q6asm dai driver
From: Bjorn Andersson @ 2018-01-03 0:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214173402.19074-13-srinivas.kandagatla@linaro.org>
On Thu 14 Dec 09:33 PST 2017, srinivas.kandagatla at linaro.org wrote:
[..]
> +
> +enum stream_state {
> + IDLE = 0,
> + STOPPED,
> + RUNNING,
These are too generic.
> +};
> +
> +struct q6asm_dai_rtd {
> + struct snd_pcm_substream *substream;
> + dma_addr_t phys;
> + unsigned int pcm_size;
> + unsigned int pcm_count;
> + unsigned int pcm_irq_pos; /* IRQ position */
> + unsigned int periods;
> + uint16_t bits_per_sample;
> + uint16_t source; /* Encoding source bit mask */
> +
> + struct audio_client *audio_client;
> + uint16_t session_id;
> +
> + enum stream_state state;
> + bool set_channel_map;
> + char channel_map[8];
There's a define for this 8
> +};
> +
> +struct q6asm_dai_data {
> + u64 sid;
> +};
> +
> +static struct snd_pcm_hardware q6asm_dai_hardware_playback = {
> + .info = (SNDRV_PCM_INFO_MMAP |
> + SNDRV_PCM_INFO_BLOCK_TRANSFER |
> + SNDRV_PCM_INFO_MMAP_VALID |
> + SNDRV_PCM_INFO_INTERLEAVED |
> + SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME),
> + .formats = (SNDRV_PCM_FMTBIT_S16_LE |
> + SNDRV_PCM_FMTBIT_S24_LE),
> + .rates = SNDRV_PCM_RATE_8000_192000,
> + .rate_min = 8000,
> + .rate_max = 192000,
> + .channels_min = 1,
> + .channels_max = 8,
> + .buffer_bytes_max = (PLAYBACK_MAX_NUM_PERIODS *
> + PLAYBACK_MAX_PERIOD_SIZE),
> + .period_bytes_min = PLAYBACK_MIN_PERIOD_SIZE,
> + .period_bytes_max = PLAYBACK_MAX_PERIOD_SIZE,
> + .periods_min = PLAYBACK_MIN_NUM_PERIODS,
> + .periods_max = PLAYBACK_MAX_NUM_PERIODS,
If you just put the numbers here, instead of using the PLAYBACK_
defines, it's possible to grok the values of this struct without having
to jump to the defines for each one.
> + .fifo_size = 0,
> +};
> +
> +/* Conventional and unconventional sample rate supported */
> +static unsigned int supported_sample_rates[] = {
> + 8000, 11025, 12000, 16000, 22050, 24000, 32000, 44100, 48000,
> + 88200, 96000, 176400, 192000
> +};
> +
> +static struct snd_pcm_hw_constraint_list constraints_sample_rates = {
This is unreferenced.
> + .count = ARRAY_SIZE(supported_sample_rates),
> + .list = supported_sample_rates,
> + .mask = 0,
> +};
> +
> +static void event_handler(uint32_t opcode, uint32_t token,
> + uint32_t *payload, void *priv)
> +{
> + struct q6asm_dai_rtd *prtd = priv;
> + struct snd_pcm_substream *substream = prtd->substream;
> +
> + switch (opcode) {
> + case ASM_CLIENT_EVENT_CMD_RUN_DONE:
> + q6asm_write_nolock(prtd->audio_client,
> + prtd->pcm_count, 0, 0, NO_TIMESTAMP);
> + break;
> + case ASM_CLIENT_EVENT_CMD_EOS_DONE:
> + prtd->state = STOPPED;
> + break;
> + case ASM_CLIENT_EVENT_DATA_WRITE_DONE: {
> + prtd->pcm_irq_pos += prtd->pcm_count;
> + snd_pcm_period_elapsed(substream);
> + if (prtd->state == RUNNING)
> + q6asm_write_nolock(prtd->audio_client,
> + prtd->pcm_count, 0, 0, NO_TIMESTAMP);
> +
> + break;
> + }
> + default:
> + break;
> + }
> +}
> +
> +static int q6asm_dai_prepare(struct snd_pcm_substream *substream)
> +{
> + struct snd_pcm_runtime *runtime = substream->runtime;
> + struct snd_soc_pcm_runtime *soc_prtd = substream->private_data;
> + struct q6asm_dai_rtd *prtd = runtime->private_data;
> + struct q6asm_dai_data *pdata;
> + int ret;
> +
> + pdata = dev_get_drvdata(soc_prtd->platform->dev);
> + if (!pdata)
> + return -EINVAL;
> +
> + if (!prtd || !prtd->audio_client) {
> + pr_err("%s: private data null or audio client freed\n",
> + __func__);
> + return -EINVAL;
> + }
> +
> + prtd->pcm_count = snd_pcm_lib_period_bytes(substream);
> + prtd->pcm_irq_pos = 0;
> + /* rate and channels are sent to audio driver */
> + if (prtd->state) {
> + /* clear the previous setup if any */
> + q6asm_cmd(prtd->audio_client, CMD_CLOSE);
> + q6asm_unmap_memory_regions(substream->stream,
> + prtd->audio_client);
> + q6routing_dereg_phy_stream(soc_prtd->dai_link->id,
> + SNDRV_PCM_STREAM_PLAYBACK);
> + }
> +
> + ret = q6asm_map_memory_regions(substream->stream, prtd->audio_client,
> + prtd->phys,
> + (prtd->pcm_size / prtd->periods),
> + prtd->periods);
> +
> + if (ret < 0) {
> + pr_err("Audio Start: Buffer Allocation failed rc = %d\n",
> + ret);
> + return -ENOMEM;
> + }
> +
> + ret = q6asm_open_write(prtd->audio_client, FORMAT_LINEAR_PCM,
> + prtd->bits_per_sample);
> + if (ret < 0) {
> + pr_err("%s: q6asm_open_write failed\n", __func__);
> + q6asm_audio_client_free(prtd->audio_client);
> + prtd->audio_client = NULL;
Do you need to roll back the q6asm_map_memory_regions?
> + return -ENOMEM;
> + }
> +
> + prtd->session_id = q6asm_get_session_id(prtd->audio_client);
> + ret = q6routing_reg_phy_stream(soc_prtd->dai_link->id, LEGACY_PCM_MODE,
> + prtd->session_id, substream->stream);
> + if (ret) {
> + pr_err("%s: stream reg failed ret:%d\n", __func__, ret);
> + return ret;
> + }
> +
> + ret = q6asm_media_format_block_multi_ch_pcm(
> + prtd->audio_client, runtime->rate,
> + runtime->channels, !prtd->set_channel_map,
> + prtd->channel_map, prtd->bits_per_sample);
set_channel_map and channel_map aren't referenced elsewhere. If this
isn't used consider removing it for now.
> + if (ret < 0)
> + pr_info("%s: CMD Format block failed\n", __func__);
> +
> + prtd->state = RUNNING;
> +
> + return 0;
> +}
> +
[..]
> +static int q6asm_dai_pcm_new(struct snd_soc_pcm_runtime *rtd)
> +{
> + struct snd_pcm *pcm = rtd->pcm;
> + struct snd_pcm_substream *substream;
> + struct snd_card *card = rtd->card->snd_card;
> + struct device *dev = card->dev;
> + struct device_node *node = dev->of_node;
> + struct q6asm_dai_data *pdata = dev_get_drvdata(rtd->platform->dev);
> + struct of_phandle_args args;
> +
> + int size, ret = 0;
> +
> + ret = of_parse_phandle_with_fixed_args(node, "iommus", 1, 0, &args);
> + if (ret < 0)
> + pdata->sid = -1;
> + else
> + pdata->sid = args.args[0];
> +
Is this really how you're supposed to deal with the iommu?
> +
> +
> + substream = pcm->streams[SNDRV_PCM_STREAM_PLAYBACK].substream;
> + size = q6asm_dai_hardware_playback.buffer_bytes_max;
> + ret = snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV, dev, size,
> + &substream->dma_buffer);
> + if (ret) {
> + dev_err(dev, "Cannot allocate buffer(s)\n");
> + return ret;
Just fall through.
> + }
> +
> + return ret;
> +}
> +
[..]
> +static struct snd_soc_dai_driver q6asm_fe_dais[] = {
> + {
> + .playback = {
> + .stream_name = "MultiMedia1 Playback",
> + .rates = (SNDRV_PCM_RATE_8000_192000|
> + SNDRV_PCM_RATE_KNOT),
> + .formats = (SNDRV_PCM_FMTBIT_S16_LE |
> + SNDRV_PCM_FMTBIT_S24_LE),
> + .channels_min = 1,
> + .channels_max = 8,
> + .rate_min = 8000,
> + .rate_max = 192000,
> + },
> + .name = "MM_DL1",
> + .probe = fe_dai_probe,
> + .id = MSM_FRONTEND_DAI_MULTIMEDIA1,
> + },
> + {
> + .playback = {
> + .stream_name = "MultiMedia2 Playback",
> + .rates = (SNDRV_PCM_RATE_8000_192000|
> + SNDRV_PCM_RATE_KNOT),
> + .formats = (SNDRV_PCM_FMTBIT_S16_LE |
> + SNDRV_PCM_FMTBIT_S24_LE),
> + .channels_min = 1,
> + .channels_max = 8,
> + .rate_min = 8000,
> + .rate_max = 192000,
I presume the listed frontend DAIs needs to match the firmware of the
DSP (and features of hardware)? Can we get away with a single list for
all versions of the adsp?
In msm-4.4 the max rate for these where changed to 384000, see:
9c46f74b2724 ("ASoC: msm: add 384KHz playback support")
> + },
> + .name = "MM_DL2",
> + .probe = fe_dai_probe,
> + .id = MSM_FRONTEND_DAI_MULTIMEDIA2,
> + },
> +};
> +
Regards,
Bjorn
^ permalink raw reply
* [RESEND PATCH v2 14/15] ASoC: qcom: apq8096: Add db820c machine driver
From: Bjorn Andersson @ 2018-01-03 0:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214173402.19074-15-srinivas.kandagatla@linaro.org>
On Thu 14 Dec 09:34 PST 2017, srinivas.kandagatla at linaro.org wrote:
> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>
> uThis patch adds support to DB820c machine driver.
Drop 'u' and expand the message to claim that this is the machine driver
for 8996, used by the db820c.
[..]
> +static struct snd_soc_dai_link msm8996_dai_links[] = {
Are there any differences between the DAI links of apq8096 and msm8996?
> + /* FrontEnd DAI Links */
> + {
> + .name = "MultiMedia1 Playback",
> + .stream_name = "MultiMedia1",
> + .cpu_dai_name = "MM_DL1",
> + .platform_name = "q6asm_dai",
> + .dynamic = 1,
> + .dpcm_playback = 1,
> +
> + .codec_dai_name = "snd-soc-dummy-dai",
> + .codec_name = "snd-soc-dummy",
> + },
> + /* Backend DAI Links */
> + {
> + .name = "HDMI Playback",
> + .stream_name = "q6afe_dai",
> + .cpu_dai_name = "HDMI",
> + .platform_name = "q6routing",
> + .no_pcm = 1,
> + .dpcm_playback = 1,
> + .be_hw_params_fixup = msm8996_be_hw_params_fixup,
> + .codec_dai_name = "i2s-hifi",
> + .codec_name = "hdmi-audio-codec.0.auto",
> + },
> +};
> +
> +static int apq8096_sbc_parse_of(struct snd_soc_card *card)
msm8996_parse_of()
> +{
> + struct device *dev = card->dev;
> + int ret;
> +
> + ret = snd_soc_of_parse_card_name(card, "qcom,model");
> + if (ret)
> + dev_err(dev, "Error parsing card name: %d\n", ret);
> +
> + return ret;
> +}
> +
> +static int msm_snd_apq8096_probe(struct platform_device *pdev)
msm_snd_msm8996_probe()?
> +{
> + int ret;
> + struct snd_soc_card *card;
> +
> + card = devm_kzalloc(&pdev->dev, sizeof(*card), GFP_KERNEL);
> + if (!card)
> + return -ENOMEM;
> +
> + card->dev = &pdev->dev;
> +
> + ret = dma_coerce_mask_and_coherent(card->dev, DMA_BIT_MASK(32));
> + if (ret)
> + return ret;
> +
> + card->dai_link = msm8996_dai_links;
> + card->num_links = ARRAY_SIZE(msm8996_dai_links);
> +
> + ret = apq8096_sbc_parse_of(card);
> + if (ret) {
> + dev_err(&pdev->dev, "Error parsing OF data\n");
No need to print in both parse_of() and here.
> + return ret;
> + }
> +
> + ret = devm_snd_soc_register_card(&pdev->dev, card);
> + if (ret)
> + dev_err(&pdev->dev, "sound card register failed (%d)!\n", ret);
> + else
> + dev_err(&pdev->dev, "sound card register Sucessfull\n");
This isn't an error, skip the print here.
> +
> + return ret;
> +}
> +
> +static const struct of_device_id msm_snd_apq8096_dt_match[] = {
> + {.compatible = "qcom,apq8096-sndcard"},
> + {}
> +};
> +
> +static struct platform_driver msm_snd_apq8096_driver = {
> + .probe = msm_snd_apq8096_probe,
> + .driver = {
> + .name = "msm-snd-apq8096",
> + .owner = THIS_MODULE,
Drop the .owner
Regards,
Bjorn
^ permalink raw reply
* [RESEND PATCH v2 15/15] arm64: dts: msm8996: db820c: Add sound card support
From: Bjorn Andersson @ 2018-01-03 0:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214173402.19074-16-srinivas.kandagatla@linaro.org>
On Thu 14 Dec 09:34 PST 2017, srinivas.kandagatla at linaro.org wrote:
> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>
> This patch adds hdmi sound card support to db820c via qdsp.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
> arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 5 +++++
> arch/arm64/boot/dts/qcom/msm8996.dtsi | 33 ++++++++++++++++++++++++++++
> 2 files changed, 38 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
> index 9769053957af..b955769b100d 100644
> --- a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
> +++ b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
> @@ -190,6 +190,11 @@
> };
> };
>
> + snd {
> + compatible = "qcom,apq8096-sndcard";
> + qcom,model = "DB820c";
> + iommus = <&lpass_q6_smmu 1>;
> + };
>
> gpio_keys {
> compatible = "gpio-keys";
> diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> index a144cec7bb71..25c43fb8ab49 100644
> --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> @@ -1262,6 +1262,7 @@
>
> phys = <&hdmi_phy>;
> phy-names = "hdmi_phy";
> + #sound-dai-cells = <0>;
>
> ports {
> #address-cells = <1>;
> @@ -1297,6 +1298,33 @@
> "ref_clk";
> };
> };
> +
> + lpass_q6_smmu: arm,smmu-lpass_q6 at 1600000 {
name this node "iommu"
> + compatible = "qcom,msm8996-smmu-v2";
> + reg = <0x1600000 0x20000>;
> + #iommu-cells = <1>;
> + power-domains = <&gcc HLOS1_VOTE_LPASS_CORE_GDSC>;
Indentation
> +
> + #global-interrupts = <1>;
> + interrupts = <GIC_SPI 404 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 226 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 393 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 394 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 395 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 396 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 397 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 398 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 399 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 400 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 401 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 402 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 403 IRQ_TYPE_LEVEL_HIGH>;
> +
> + clocks = <&gcc GCC_HLOS1_VOTE_LPASS_CORE_SMMU_CLK>,
> + <&gcc GCC_HLOS1_VOTE_LPASS_ADSP_SMMU_CLK>;
> + clock-names = "iface", "bus";
> + status = "okay";
> + };
> };
>
> adsp-pil {
> @@ -1325,6 +1353,11 @@
> qcom,ipc = <&apcs 16 8>;
> qcom,smd-edge = <1>;
> qcom,remote-pid = <2>;
> +
> + apr {
"apr-audio-svc", as this is not the only apr channel on this edge.
> + compatible = "qcom,apr-msm8996";
> + qcom,smd-channels = "apr_audio_svc";
> + };
> };
Regards,
Bjorn
^ permalink raw reply
* [RESEND PATCH v2 13/15] dt-bindings: sound: qcom: Add devicetree bindings for apq8096
From: Bjorn Andersson @ 2018-01-03 0:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214173402.19074-14-srinivas.kandagatla@linaro.org>
On Thu 14 Dec 09:34 PST 2017, srinivas.kandagatla at linaro.org wrote:
> +++ b/Documentation/devicetree/bindings/sound/qcom,apq8096.txt
Wouldn't it be possible to describe all(?) qdsp based machines in this
one document? I.e. should we name it a little bit more generic?
> @@ -0,0 +1,22 @@
> +* Qualcomm Technologies APQ8096 ASoC sound card driver
> +
> +This binding describes the APQ8096 sound card, which uses qdsp for audio.
> +
> +- compatible:
> + Usage: required
> + Value type: <stringlist>
> + Definition: must be "qcom,apq8096-sndcard"
> +
> +- qcom,audio-routing:
> + Usage: Optional
> + Value type: <stringlist>
> + Definition: A list of the connections between audio components.
Double space before A
> + Each entry is a pair of strings, the first being the
> + connection's sink, the second being the connection's
> + source. Valid names could be power supplies, MicBias
> + of codec and the jacks on the board:
> +Example:
> + sound {
> + compatible = "qcom,snd-apq8096";
Indentation
> + qcom,model = "DB820c";
> + };
Regards,
Bjorn
^ permalink raw reply
* [RESEND PATCH v2 01/15] dt-bindings: soc: qcom: Add bindings for APR bus
From: Bjorn Andersson @ 2018-01-03 0:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214173402.19074-2-srinivas.kandagatla@linaro.org>
On Thu 14 Dec 09:33 PST 2017, srinivas.kandagatla at linaro.org wrote:
> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>
> This patch add dt bindings for Qualcomm APR bus driver
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
> .../devicetree/bindings/soc/qcom/qcom,apr.txt | 28 ++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt
>
> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt
> new file mode 100644
> index 000000000000..4e93213ae98d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt
> @@ -0,0 +1,28 @@
> +Qualcomm APR (Asynchronous Packet Router) binding
> +
> +This binding describes the Qualcomm APR. APR is a IPC protocol for
> +communication between Application processor and QDSP. APR is mainly
> +used for audio/voice services on the QDSP.
> +
> +- compatible:
> + Usage: required
> + Value type: <stringlist>
> + Definition: must be "qcom,apr-<SOC-NAME>" example: "qcom,apr-msm8996"
This is not the only apr on msm8996 and some platform seems to have 3-4
aprs. I'm therefor hesitant to use the compatible to pick the static
list of services available on the particular firmware.
If this scheme is followed we at least would need to rename this
qcom,msm8996-apr-audio-svc
But I think it would be preferable to go with qcom,apr-v2 and then list
the static services as child nodes.
> +
> +
> +- qcom,smd-channel:
> + Usage: required
> + Value type: <string>
> + Definition: standard SMD property specifying the SMD channel used for
> + communication with the APR on QDSP.
> + Should be "apr_audio_svc".
This is not the only APR channel, but for apr itself this doesn't matter
and might as well be qcom,glink-channels; so perhaps we can omit this
from this document?
> + Described in soc/qcom/qcom,smd.txt
> +
> += EXAMPLE
> +The following example represents a QDSP based sound card on a MSM8996 device
> +which uses apr as communication between Apps and QDSP.
> +
> + apr {
> + compatible = "qcom,apr-msm8996";
> + qcom,smd-channels = "apr_audio_svc";
> + };
Regards,
Bjorn
^ permalink raw reply
* [PATCH V3] ARM: imx: use outer_disable/resume for low power
From: Peng Fan @ 2018-01-03 0:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514452141-14948-1-git-send-email-peng.fan@nxp.com>
> -----Original Message-----
> From: Peng Fan
> Sent: Thursday, December 28, 2017 5:09 PM
> To: shawnguo at kernel.org
> Cc: linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> van.freenix at gmail.com; Peng Fan <peng.fan@nxp.com>; Sascha Hauer
> <kernel@pengutronix.de>; Fabio Estevam <fabio.estevam@nxp.com>; A.s.
> Dong <aisheng.dong@nxp.com>; Russell King <linux@armlinux.org.uk>
> Subject: [PATCH V3] ARM: imx: use outer_disable/resume for low power
>
> Use outer_disable/resume for suspend/resume and low power idle.
> With the two APIs used, code could be easy to extend to introduce
> l2c_write_sec for i.MX platforms when moving Linux Kernel runs in non-secure
> world.
>
> The cache sync operation and l2c310_early_resume in suspend-imx6.S are kept.
> According to PL310 TRM for dormant mode: "The external power controller
> asserts the reset. Ensure the cache controller is placed back into run mode prior
> to the L1 masters.". So keep l2c310_early_resume.
>
> Another reason is alought L2 controller lose power, L2 memory not lose power.
> If l2c310_early_resume removed, outer_resume will do invalidation which may
> corrupt data. To keep safe, the cache sync operation is also kept.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Dong Aisheng <aisheng.dong@nxp.com>
> Cc: Russell King <linux@armlinux.org.uk>
> ---
>
> V3:
> Continue fix 6SX low power idle. Because L2 memory not lose power,
> outer_disable seems not clearly flush all the data or flush l1 -> flush l2 ->cache
> sync must be followed, outer_resume will invalidate the cache, which corrupt
> data and cause issues. So in V3, only add outer_disable/resume to make it
> simple.
> Add more commit log.
> Based on Shawn/for-next.
> V2:
> Fix 6SX booting. The V1 patch does not take 6SX low power idle into
> consideration.
>
> arch/arm/mach-imx/cpuidle-imx6sx.c | 2 ++
> arch/arm/mach-imx/pm-imx6.c | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/arch/arm/mach-imx/cpuidle-imx6sx.c b/arch/arm/mach-
> imx/cpuidle-imx6sx.c
> index c5a5c3a70ab1..b35841d133dc 100644
> --- a/arch/arm/mach-imx/cpuidle-imx6sx.c
> +++ b/arch/arm/mach-imx/cpuidle-imx6sx.c
> @@ -49,7 +49,9 @@ static int imx6sx_enter_wait(struct cpuidle_device *dev,
> cpu_pm_enter();
> cpu_cluster_pm_enter();
>
A better solution maybe
if (outer_cache.write_sec)
outer_disable();
.....
if (outer_cache.write_sec)
outer_resume();
Then, nothing changed for secure linux. The outer_disable/outer_resume only effects
When linunx running in non-secure world.
Any comments?
> + outer_disable();
> cpu_suspend(0, imx6sx_idle_finish);
> + outer_resume();
>
> cpu_cluster_pm_exit();
> cpu_pm_exit();
> diff --git a/arch/arm/mach-imx/pm-imx6.c b/arch/arm/mach-imx/pm-imx6.c
> index ecdf071653d4..153a0afc7645 100644
> --- a/arch/arm/mach-imx/pm-imx6.c
> +++ b/arch/arm/mach-imx/pm-imx6.c
> @@ -392,8 +392,10 @@ static int imx6q_pm_enter(suspend_state_t state)
> imx6_enable_rbc(true);
> imx_gpc_pre_suspend(true);
> imx_anatop_pre_suspend();
> + outer_disable();
> /* Zzz ... */
> cpu_suspend(0, imx6q_suspend_finish);
> + outer_resume();
> if (cpu_is_imx6q() || cpu_is_imx6dl())
> imx_smp_prepare();
> imx_anatop_post_resume();
> --
> 2.14.1
Thanks,
Peng.
^ permalink raw reply
* [PATCH v7 1/5] clk: Add clock driver for ASPEED BMC SoCs
From: Stephen Boyd @ 2018-01-03 1:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171222024522.10362-2-joel@jms.id.au>
On 12/22, Joel Stanley wrote:
> This adds the stub of a driver for the ASPEED SoCs. The clocks are
> defined and the static registration is set up.
>
> Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v7 2/5] clk: aspeed: Register core clocks
From: Stephen Boyd @ 2018-01-03 1:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171222024522.10362-3-joel@jms.id.au>
On 12/22, Joel Stanley wrote:
> This registers the core clocks; those which are required to calculate
> the rate of the timer peripheral so the system can load a clocksource
> driver.
>
> Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v7 3/5] clk: aspeed: Add platform driver and register PLLs
From: Stephen Boyd @ 2018-01-03 1:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171222024522.10362-4-joel@jms.id.au>
On 12/22, Joel Stanley wrote:
> This registers a platform driver to set up all of the non-core clocks.
>
> The clocks that have configurable rates are now registered.
>
> Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> --
> v6:
> - Add Andrew's reviewed-by
> v5:
> - Remove eclk configuration. We do not have enough information to
> correctly implement the mux and divisor, so it will have to be
> implemented in the future
> v4:
> - Add eclk div table to fix ast2500 calculation
> - Add defines to document the BIT() macros
> - Pass dev where we can when registering clocks
> - Check for errors when registering clk_hws
> v3:
> - Fix bclk and eclk calculation
> - Separate out ast2400 and ast25000 for pll calculation
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v7 4/5] clk: aspeed: Register gated clocks
From: Stephen Boyd @ 2018-01-03 1:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171222024522.10362-5-joel@jms.id.au>
On 12/22, Joel Stanley wrote:
> The majority of the clocks in the system are gates paired with a reset
> controller that holds the IP in reset.
>
> This borrows from clk_hw_register_gate, but registers two 'gates', one
> to control the clock enable register and the other to control the reset
> IP. This allows us to enforce the ordering:
>
> 1. Place IP in reset
> 2. Enable clock
> 3. Delay
> 4. Release reset
>
> There are some gates that do not have an associated reset; these are
> handled by using -1 as the index for the reset.
>
> Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v7 5/5] clk: aspeed: Add reset controller
From: Stephen Boyd @ 2018-01-03 1:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171222024522.10362-6-joel@jms.id.au>
On 12/22, Joel Stanley wrote:
> There are some resets that are not associated with gates. These are
> represented by a reset controller.
>
> Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 1/2] ARM: dts: imx6ul: add 696MHz operating point
From: Anson Huang @ 2018-01-03 2:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5BGmnNzv7YobtB+KOi0PM+qzyYi97q_NZtT1PU_e+Bcbg@mail.gmail.com>
Post this discussion mail to kernel mail list, since last mail is rejected due to incorrect format, sorry for confusion.
Best Regards!
Anson Huang
> -----Original Message-----
> From: Fabio Estevam [mailto:festevam at gmail.com]
> Sent: 2018-01-02 11:32 PM
> To: Anson Huang <anson.huang@nxp.com>
> Cc: moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE <linux-
> arm-kernel at lists.infradead.org>; open list:OPEN FIRMWARE AND FLATTENED
> DEVICE TREE BINDINGS <devicetree@vger.kernel.org>; linux-
> pm at vger.kernel.org; linux-kernel <linux-kernel@vger.kernel.org>; Mark
> Rutland <mark.rutland@arm.com>; A.s. Dong <aisheng.dong@nxp.com>; Jacky
> Bai <ping.bai@nxp.com>; viresh kumar <viresh.kumar@linaro.org>;
> rjw at rjwysocki.net; Russell King - ARM Linux <linux@armlinux.org.uk>; Rob
> Herring <robh+dt@kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> Fabio Estevam <fabio.estevam@nxp.com>; Shawn Guo
> <shawnguo@kernel.org>
> Subject: Re: [PATCH 1/2] ARM: dts: imx6ul: add 696MHz operating point
>
> On Tue, Jan 2, 2018 at 1:12 PM, Anson Huang <anson.huang@nxp.com> wrote:
>
> > There is a comment in VDD_ARM, VDD_SOC must NOT lower than VDD_ARM.
> >
> > Output voltage must be set to the following rules:
> > ? VDD_ARM_CAP <= VDD_SOC_CAP
> > ? VDD_SOC_CAP - VDD_ARM_CAP < 330 mV
>
> Thanks for the clarifcation.
>
> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH 2/2] cpufreq: imx6q: add 696MHz operating point for i.mx6ul
From: Anson Huang @ 2018-01-03 2:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5ADWdbDoCO8b4JVDag=PH2MgLsLbQ6DJU8VvJh6G6qMkQ@mail.gmail.com>
Post the discussion mail to arm kernel mail list, since last mail is rejected due to incorrect format, sorry for the confusion.
Best Regards!
Anson Huang
> -----Original Message-----
> From: Fabio Estevam [mailto:festevam at gmail.com]
> Sent: 2018-01-02 11:33 PM
> To: Anson Huang <anson.huang@nxp.com>
> Cc: moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE <linux-
> arm-kernel at lists.infradead.org>; open list:OPEN FIRMWARE AND FLATTENED
> DEVICE TREE BINDINGS <devicetree@vger.kernel.org>; linux-
> pm at vger.kernel.org; linux-kernel <linux-kernel@vger.kernel.org>; Mark
> Rutland <mark.rutland@arm.com>; A.s. Dong <aisheng.dong@nxp.com>; Jacky
> Bai <ping.bai@nxp.com>; viresh kumar <viresh.kumar@linaro.org>;
> rjw at rjwysocki.net; Russell King - ARM Linux <linux@armlinux.org.uk>; Rob
> Herring <robh+dt@kernel.org>; Sascha Hauer <kernel@pengutronix.de>;
> Fabio Estevam <fabio.estevam@nxp.com>; Shawn Guo
> <shawnguo@kernel.org>
> Subject: Re: [PATCH 2/2] cpufreq: imx6q: add 696MHz operating point for
> i.mx6ul
>
> On Tue, Jan 2, 2018 at 1:17 PM, Anson Huang <anson.huang@nxp.com> wrote:
>
> > This change is only valid for mx6ul and mx6ull, other SoCs like
> > 6q/dl/qp are NOT impacted.
>
> Thanks for the clarification:
>
> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH V3] ARM: imx: use outer_disable/resume for low power
From: Fabio Estevam @ 2018-01-03 2:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DB6PR04MB3221B5BFB31D39309EF5C7EB881E0@DB6PR04MB3221.eurprd04.prod.outlook.com>
Hi Peng,
On Tue, Jan 2, 2018 at 10:53 PM, Peng Fan <peng.fan@nxp.com> wrote:
>
> A better solution maybe
>
> if (outer_cache.write_sec)
> outer_disable();
>
> .....
>
> if (outer_cache.write_sec)
> outer_resume();
>
> Then, nothing changed for secure linux. The outer_disable/outer_resume only effects
> When linunx running in non-secure world.
>
> Any comments?
Looks like a better solution, indeed.
^ permalink raw reply
* [linux-sunxi] [PATCH v4 1/6] ARM: sunxi: h3/h5: add simplefb nodes
From: Chen-Yu Tsai @ 2018-01-03 2:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2823749.lCJ0TQNemj@ice-x220i>
On Tue, Jan 2, 2018 at 4:14 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
> ? 2018?1?2???? CST ??4:11:04?Chen-Yu Tsai ???
>> On Sat, Dec 30, 2017 at 7:30 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
>> > The H3/H5 SoCs have a HDMI output and a TV Composite output.
>> >
>> > Add simplefb nodes for these outputs.
>> >
>> > Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> > ---
>> > Changes in v4:
>> > - Dropped extra clocks (bus clocks and HDMI DDC clocks), only keep the
>> >
>> > clocks that are needed to display framebuffer to the monitor.
>>
>> Looks good. I assume you've tested this? It does continue to work
>> with the bus and DDC clocks disabled, right?
>
> Yes. This patchset is tested in Orange Pi PC and SoPine w/ Baseboard "Model
> A".
Applied this one.
ChenYu
^ permalink raw reply
* [PATCH] ethernet/broadcom: Use zeroing memory allocator than allocator/memset
From: David Miller @ 2018-01-03 2:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514648697-7148-1-git-send-email-himanshujha199640@gmail.com>
From: Himanshu Jha <himanshujha199640@gmail.com>
Date: Sat, 30 Dec 2017 21:14:57 +0530
> Use dma_zalloc_coherent for allocating zeroed
> memory and remove unnecessary memset function.
>
> Done using Coccinelle.
> Generated-by: scripts/coccinelle/api/alloc/kzalloc-simple.cocci
> 0-day tested with no failures.
>
> Suggested-by: Luis R. Rodriguez <mcgrof@kernel.org>
> Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
Applied.
^ permalink raw reply
* [LINUX PATCH 1/4] dmaengine: xilinx_dma: Fix dma_get_slave_caps() API failures
From: Vinod Koul @ 2018-01-03 3:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513851098-15787-2-git-send-email-appanad@xilinx.com>
On Thu, Dec 21, 2017 at 03:41:35PM +0530, Kedareswara rao Appana wrote:
Patch title should say what is does, not the cause/effect
An apt title might be "populate dma caps properly"
> When client driver uses dma_get_slave_caps() api,
> it checks for certain fields of dma_device struct
> currently driver is not settings few fields resulting
> dma_get_slave_caps() returning failure.
It would help to mention the fields you are setting here
>
> This patch fixes this issue by populating proper values
> to the struct dma_device fields.
>
> Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com>
> ---
> drivers/dma/xilinx/xilinx_dma.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 88d317d..21ac954 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -2398,6 +2398,7 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device *xdev,
> chan->direction = DMA_MEM_TO_DEV;
> chan->id = chan_id;
> chan->tdest = chan_id;
> + xdev->common.directions = BIT(DMA_MEM_TO_DEV);
>
> chan->ctrl_offset = XILINX_DMA_MM2S_CTRL_OFFSET;
> if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) {
> @@ -2415,6 +2416,7 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device *xdev,
> chan->direction = DMA_DEV_TO_MEM;
> chan->id = chan_id;
> chan->tdest = chan_id - xdev->nr_channels;
> + xdev->common.directions |= BIT(DMA_DEV_TO_MEM);
>
> chan->ctrl_offset = XILINX_DMA_S2MM_CTRL_OFFSET;
> if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) {
> @@ -2629,6 +2631,8 @@ static int xilinx_dma_probe(struct platform_device *pdev)
> dma_cap_set(DMA_PRIVATE, xdev->common.cap_mask);
> }
>
> + xdev->common.dst_addr_widths = BIT(addr_width / 8);
> + xdev->common.src_addr_widths = BIT(addr_width / 8);
> xdev->common.device_alloc_chan_resources =
> xilinx_dma_alloc_chan_resources;
> xdev->common.device_free_chan_resources =
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
~Vinod
^ permalink raw reply
* [LINUX PATCH 2/4] dmaengine: xilinx_dma: Fix race condition in the driver for cdma
From: Vinod Koul @ 2018-01-03 3:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513851098-15787-3-git-send-email-appanad@xilinx.com>
On Thu, Dec 21, 2017 at 03:41:36PM +0530, Kedareswara rao Appana wrote:
same issue for patch title here too
> when hardware is idle we need to toggle the SG bit
> in the control register, inorder to update new value to the
> current descriptor register other wise undefined
> results will occur.
can you try making it bit more clear..
>
> This patch updates the same.
>
> Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com>
> ---
> drivers/dma/xilinx/xilinx_dma.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 21ac954..8467671 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -1204,6 +1204,12 @@ static void xilinx_cdma_start_transfer(struct xilinx_dma_chan *chan)
> }
>
> if (chan->has_sg) {
> + dma_ctrl_clr(chan, XILINX_DMA_REG_DMACR,
> + XILINX_CDMA_CR_SGMODE);
> +
> + dma_ctrl_set(chan, XILINX_DMA_REG_DMACR,
> + XILINX_CDMA_CR_SGMODE);
> +
> xilinx_write(chan, XILINX_DMA_REG_CURDESC,
> head_desc->async_tx.phys);
>
> @@ -2052,6 +2058,10 @@ static int xilinx_dma_terminate_all(struct dma_chan *dchan)
> chan->cyclic = false;
> }
>
> + if ((chan->xdev->dma_config->dmatype == XDMA_TYPE_CDMA) && chan->has_sg)
> + dma_ctrl_clr(chan, XILINX_DMA_REG_DMACR,
> + XILINX_CDMA_CR_SGMODE);
> +
> return 0;
> }
>
> --
> 2.7.4
>
--
~Vinod
^ permalink raw reply
* [LINUX PATCH 3/4] dmaengine: xilinx_dma: Fix compilation warning
From: Vinod Koul @ 2018-01-03 3:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513851098-15787-4-git-send-email-appanad@xilinx.com>
On Thu, Dec 21, 2017 at 03:41:37PM +0530, Kedareswara rao Appana wrote:
Fix title here too
BTW whats with LINUX tag in patches, pls drop them
> This patch fixes the below sparse warning in the driver
> drivers/dma/xilinx/xilinx_dma.c: In function ?xilinx_vdma_dma_prep_interleaved?:
> drivers/dma/xilinx/xilinx_dma.c:1614:43: warning: variable ?prev? set but not used [-Wunused-but-set-variable]
> struct xilinx_vdma_tx_segment *segment, *prev = NULL;
>
> Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com>
> ---
> drivers/dma/xilinx/xilinx_dma.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 8467671..845e638 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -1611,7 +1611,7 @@ xilinx_vdma_dma_prep_interleaved(struct dma_chan *dchan,
> {
> struct xilinx_dma_chan *chan = to_xilinx_chan(dchan);
> struct xilinx_dma_tx_descriptor *desc;
> - struct xilinx_vdma_tx_segment *segment, *prev = NULL;
> + struct xilinx_vdma_tx_segment *segment;
> struct xilinx_vdma_desc_hw *hw;
>
> if (!is_slave_direction(xt->dir))
> @@ -1665,8 +1665,6 @@ xilinx_vdma_dma_prep_interleaved(struct dma_chan *dchan,
> /* Insert the segment into the descriptor segments list. */
> list_add_tail(&segment->node, &desc->segments);
>
> - prev = segment;
> -
> /* Link the last hardware descriptor with the first. */
> segment = list_first_entry(&desc->segments,
> struct xilinx_vdma_tx_segment, node);
> --
> 2.7.4
>
--
~Vinod
^ permalink raw reply
* [GIT PULL] ARM: aspeed: dts changes for 4.16
From: Joel Stanley @ 2018-01-03 4:17 UTC (permalink / raw)
To: linux-arm-kernel
Hello ARM maintainers,
Here are the ASPEED devicetree updates for 4.16.
They've had a run through a few next trees where Stephen noticed two minor
merge conflicts[1] that should be obvious to resolve, but please let me know if
you have concerns.
[1] https://lkml.org/lkml/2017/12/21/750
As discussed with Arnd, there is a commit for a clock header in
include/dt-bindings
that is also being merged through the clk tree. This should require no special
attention.
Thanks!
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joel/aspeed.git
tags/aspeed-4.16-devicetree
for you to fetch changes up to e40ed274489a5f516da120186578eb379b452ac6:
ARM: dts: aspeed-evb: Add unit name to memory node (2017-12-21 14:03:22 +1030)
----------------------------------------------------------------
ASPEED device tree updates for 4.16
Clock driver support:
Rework all platforms to use proper clock bindings. Linux should now boot
upstream kernels on ast2400 and ast2500 platforms without out of tree
patches.
New systems:
Witherspoon: OpenPower Power9 server manufactured by IBM that uses
the ASPEED ast2500
Zaius: OpenPower Power9 server manufactured by Invatech that uses the
ASPEED ast2500
Q71L: Intel Xeon server manufactured by Qanta that uses the ASPEED ast2400
We also see updates to the Palmetto and Romulus systems to bring them in
line with the functionality of those above.
The systems take advantage of recently added drivers for LPC Snoop
device and the PWM/Tachometer fan controller.
OpenBMC flash layout:
The flash layout used OpenBMC systems is added and the device trees now
use it.
----------------------------------------------------------------
Andrew Jeffery (1):
ARM: dts: aspeed: Add LPC and child devices
Joel Stanley (17):
dt-bindings: clock: Add ASPEED constants
dt-bindings: gpio: Add ASPEED constants
ARM: dts: aspeed: Add proper clock references
ARM: dts: aspeed: Add MAC clocks
ARM: dts: aspeed: Add watchdog clocks
ARM: dts: aspeed: Add flash controller clocks
ARM: dts: aspeed: Add clock phandle to GPIO
ARM: dts: aspeed: Add PWM and tachometer node
ARM: dts: aspeed: Add LPC Snoop device
ARM: dts: aspeed: Remove skeleton.dtsi
ARM: dts: aspeed: Update license headers
ARM: dts: Add OpenBMC flash layout
ARM: dts: aspeed: Sort ASPEED entries in makefile
ARM: dts: aspeed: Add Witherspoon BMC machine
ARM: dts: aspeed-romulus: Update Romulus system
ARM: dts: aspeed-plametto: Add flash layout and fix memory node
ARM: dts: aspeed-evb: Add unit name to memory node
Rick Altherr (1):
ARM: dts: aspeed: Add Qanta Q71L BMC machine
Xo Wang (1):
ARM: dts: aspeed: Add Ingrasys Zaius BMC machine
arch/arm/boot/dts/Makefile | 8 +-
arch/arm/boot/dts/aspeed-ast2500-evb.dts | 4 +-
arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts | 5 +-
arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 135 +++++-
arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts | 548 +++++++++++++++++++++++
arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts | 426 ++++++++++++++++++
arch/arm/boot/dts/aspeed-bmc-quanta-q71l.dts | 458 +++++++++++++++++++
arch/arm/boot/dts/aspeed-g4.dtsi | 165 ++++---
arch/arm/boot/dts/aspeed-g5.dtsi | 156 ++++---
arch/arm/boot/dts/openbmc-flash-layout.dtsi | 32 ++
include/dt-bindings/clock/aspeed-clock.h | 52 +++
include/dt-bindings/gpio/aspeed-gpio.h | 49 ++
12 files changed, 1888 insertions(+), 150 deletions(-)
create mode 100644 arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
create mode 100644 arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts
create mode 100644 arch/arm/boot/dts/aspeed-bmc-quanta-q71l.dts
create mode 100644 arch/arm/boot/dts/openbmc-flash-layout.dtsi
create mode 100644 include/dt-bindings/clock/aspeed-clock.h
create mode 100644 include/dt-bindings/gpio/aspeed-gpio.h
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox