* [PATCH v2 02/10] clk: ccu-sun8i-a33: Add CLK_SET_RATE_PARENT to ac-dig
From: Mylène Josserand @ 2017-01-17 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117140230.23142-1-mylene.josserand@free-electrons.com>
The audio DAI needs to set the clock rates of the ac-dig clock.
To make it possible, the parent PLL audio clock rates should
also be changed. This is possible via "CLK_SET_RATE_PARENT" flag.
Signed-off-by: Myl?ne Josserand <mylene.josserand@free-electrons.com>
---
drivers/clk/sunxi-ng/ccu-sun8i-a33.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
index 9bd1f78a0547..3cd4190ccd59 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
@@ -440,7 +440,7 @@ static SUNXI_CCU_M_WITH_GATE(ve_clk, "ve", "pll-ve",
0x13c, 16, 3, BIT(31), CLK_SET_RATE_PARENT);
static SUNXI_CCU_GATE(ac_dig_clk, "ac-dig", "pll-audio",
- 0x140, BIT(31), 0);
+ 0x140, BIT(31), CLK_SET_RATE_PARENT);
static SUNXI_CCU_GATE(ac_dig_4x_clk, "ac-dig-4x", "pll-audio-4x",
0x140, BIT(30), 0);
static SUNXI_CCU_GATE(avs_clk, "avs", "osc24M",
--
2.11.0
^ permalink raw reply related
* [PATCH v2 01/10] ASoC: sun4i-i2s: Increase DMA max burst to 8
From: Mylène Josserand @ 2017-01-17 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117140230.23142-1-mylene.josserand@free-electrons.com>
As done previously for sun4i-codec, the DMA maxburst of 4
is not supported by every SoCs so the DMA controller engine
returns "unsupported value".
As a maxburst of 8 is supported by all variants, this patch
increases it to 8.
For more details, see commit from Chen-Yu Tsai:
commit 730e2dd0cbc7 ("ASoC: sun4i-codec: Increase DMA max burst to 8")
Signed-off-by: Myl?ne Josserand <mylene.josserand@free-electrons.com>
---
sound/soc/sunxi/sun4i-i2s.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index f24d19526603..4237323ef594 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -694,10 +694,10 @@ static int sun4i_i2s_probe(struct platform_device *pdev)
}
i2s->playback_dma_data.addr = res->start + SUN4I_I2S_FIFO_TX_REG;
- i2s->playback_dma_data.maxburst = 4;
+ i2s->playback_dma_data.maxburst = 8;
i2s->capture_dma_data.addr = res->start + SUN4I_I2S_FIFO_RX_REG;
- i2s->capture_dma_data.maxburst = 4;
+ i2s->capture_dma_data.maxburst = 8;
pm_runtime_enable(&pdev->dev);
if (!pm_runtime_enabled(&pdev->dev)) {
--
2.11.0
^ permalink raw reply related
* [PATCH v2 00/10] Add sun8i A33 audio driver
From: Mylène Josserand @ 2017-01-17 14:02 UTC (permalink / raw)
To: linux-arm-kernel
Hello everyone,
This a V2 of my Allwinner A33 (sun8i) audio codec driver.
Tested on linux-next-20170105 tag with one remaining patch from Chen-Yu's
series:
http://lkml.iu.edu/hypermail/linux/kernel/1611.3/01256.html
Patch to apply before this serie:
https://patchwork.kernel.org/patch/9423999/
Changes since V1:
- Remove the analog codec driver as a better version has been
committed by Chen-Yu Tsai and is already merged.
- Remove the audio-card as simple-card can be used
- The DMA maxburst is set to 8 in the sun4i-i2s instead of
adding the maxburst of 4 in Sun6i dma engine.
- Create a new compatible for sun4i-i2s to handle the reset
line.
- Fix various problems in sun8i-codec driver according to V1's
reviews
- Add the pm_runtime hooks in sun8i-codec driver to prepare/
unprepare clocks.
- Update the DTS according to Chen-Yu's analog codec driver.
- Rename sun8i-codec's clocks to "bus" and "mod"
- The first "delay" issue from V1 is fixed by using a delay
when enabling the headphone amplifier to let the amplifier
being up.
Patch 1 increases the DMA maxburst value of sun4i-i2s to 8.
See Chen-Yu's commit log for more details:
https://patchwork.kernel.org/patch/9411805/
Patch 2 adds the CLK_SET_RATE_PARENT flag to ccu sun8i-a33 clocks.
Patches 3 and 4 add a new compatible "allwinner,sun6i-a31-i2s"
to handle the reset line for sun4i-i2s driver. It uses a quirk to
use a version with or without reset lines.
Patch 5 adds the sun8i codec driver which represents the digital part
of the A33 codec. It supports only playback features.
Path 6 fixes the previous issue of a "first time delay" in V1 (see cover
letter). Do not hesitate if you have comments on this patch.
Patches 7 adds the dt-bindings documentation for new audio driver
added in this serie (sun8i-codec).
Patch 8 adds the cpu DAI, codec and audio nodes to sun8i-a33 device tree.
Patches 9 and 10 enable the audio on Parrot and Sinlinx's boards.
The DAI for this A33 codec is the same than for A20: "sun4i-i2s".
Currently, all the drivers handle only the playback feature.
The other ones (such as capture) and all other interfaces except
headphone are not supported. I will send a patch to handle the
capture with microphones in next few weeks.
Examples of amixer commands:
amixer set 'Headphone' 75%
amixer set 'Headphone' on
amixer set 'DAC' on
amixer set 'Right DAC Mixer RSlot 0' on
amixer set 'Left DAC Mixer LSlot 0' on
It was tested on Parrot and Sinlinx boards.
Let me know if you have any comments on this serie.
Thank you in advance,
Best regards,
Myl?ne Josserand (10):
ASoC: sun4i-i2s: Increase DMA max burst to 8
clk: ccu-sun8i-a33: Add CLK_SET_RATE_PARENT to ac-dig
dt-bindings: sound: Add new reset compatible for sun4i-i2s
ASoC: sun4i-i2s: Add quirks to handle new compatible for reset
ASoC: Add sun8i digital audio codec
ASoC: sun8i-codec-analog: Add amplifier event to fix first delay
dt-bindings: sound: Add sun8i audio documentation
ARM: dts: sun8i: Add audio codec, dai and card for A33
ARM: dts: sun8i: parrot: Enable audio nodes
ARM: dts: sun8i: sinlinx: Enable audio nodes
.../devicetree/bindings/sound/sun4i-i2s.txt | 23 +
.../devicetree/bindings/sound/sun8i-codec.txt | 76 +++
arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 8 +
arch/arm/boot/dts/sun8i-a33.dtsi | 47 ++
arch/arm/boot/dts/sun8i-r16-parrot.dts | 8 +
drivers/clk/sunxi-ng/ccu-sun8i-a33.c | 2 +-
sound/soc/sunxi/Kconfig | 11 +
sound/soc/sunxi/Makefile | 1 +
sound/soc/sunxi/sun4i-i2s.c | 61 ++-
sound/soc/sunxi/sun8i-codec-analog.c | 30 +-
sound/soc/sunxi/sun8i-codec.c | 531 +++++++++++++++++++++
11 files changed, 791 insertions(+), 7 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/sun8i-codec.txt
create mode 100644 sound/soc/sunxi/sun8i-codec.c
--
2.11.0
^ permalink raw reply
* [PATCH v4 4/4] arm64: dts: juno: add missing CoreSight STM component
From: Sudeep Holla @ 2017-01-17 14:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5c742b98-0707-67fd-d8a1-467f34d99cdb@arm.com>
On 17/01/17 13:39, Suzuki K Poulose wrote:
> On 17/01/17 12:15, Sudeep Holla wrote:
>> From: Mike Leach <mike.leach@linaro.org>
>>
>> This patch adds the missing CoreSight STM component definition to the
>> device tree of all the juno variants(r0,r1,r2)
>>
>> STM component is connected to different funnels depending on Juno
>> platform variant.
>>
>> Reviewed-and-Tested-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>> Signed-off-by: Mike Leach <mike.leach@linaro.org>
>> [sudeep.holla at arm.com: minor changelog update and reorganising the STM
>> node back into juno-base.dtsi to avoid duplication]
>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>> ---
>> arch/arm64/boot/dts/arm/juno-base.dtsi | 15 +++++++++++++++
>> arch/arm64/boot/dts/arm/juno-r1.dts | 4 ++++
>> arch/arm64/boot/dts/arm/juno-r2.dts | 4 ++++
>> arch/arm64/boot/dts/arm/juno.dts | 16 ++++++++++++++++
>> 4 files changed, 39 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi
>> b/arch/arm64/boot/dts/arm/juno-base.dtsi
>> index faedf357db3b..58c1773c3aa4 100644
>> --- a/arch/arm64/boot/dts/arm/juno-base.dtsi
>> +++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
>> @@ -185,6 +185,21 @@
>> };
>> };
>>
>> + stm at 20100000 {
>> + compatible = "arm,coresight-stm", "arm,primecell";
>> + reg = <0 0x20100000 0 0x1000>,
>> + <0 0x28000000 0 0x180000>;
>
> The size of the stimulus base is 16MB (as per TRM), implies => 0x1000000.
>
Fixed locally.
Mike,
Can you confirm ? I know TRM had some issues with size of other
coresight components.
> with that fixed :
>
> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>
Thanks.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH 3/4] arm64: dts: r8a7795: Link ARM GIC to clock and clock domain
From: Ramesh Shanmugasundaram @ 2017-01-17 14:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484657360-13101-4-git-send-email-geert+renesas@glider.be>
Hi Geert,
> Subject: [PATCH 3/4] arm64: dts: r8a7795: Link ARM GIC to clock and clock
> domain
>
> Link the ARM GIC to the INTC-AP module clock, and add it to the SYSC
> "always-on" PM Domain, so it can be power managed using that clock.
>
> Note that currently the GIC-400 driver doesn't support module clocks nor
> Runtime PM, so this must be handled as a critical clock.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> arch/arm64/boot/dts/renesas/r8a7795.dtsi | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> index 026a16ac41b422a1..0627df2a0b810c86 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -166,6 +166,9 @@
> <0x0 0xf1060000 0 0x20000>;
> interrupts = <GIC_PPI 9
> (GIC_CPU_MASK_SIMPLE(4) |
> IRQ_TYPE_LEVEL_HIGH)>;
> + clocks = <&cpg CPG_MOD 408>;
> + clock-names = "clk";
Should the module clock be named "fck"?
Thanks,
Ramesh
^ permalink raw reply
* [PATCH v8 14/18] irqdomain: irq_domain_check_msi_remap
From: Auger Eric @ 2017-01-17 13:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8db94e75-7939-c6da-2101-cfa73827c16c@semihalf.com>
Hi Tomasz,
On 17/01/2017 14:40, Tomasz Nowicki wrote:
> On 11.01.2017 10:41, Eric Auger wrote:
>> This new function checks whether all MSI irq domains
>> implement IRQ remapping. This is useful to understand
>> whether VFIO passthrough is safe with respect to interrupts.
>>
>> On ARM typically an MSI controller can sit downstream
>> to the IOMMU without preventing VFIO passthrough.
>> As such any assigned device can write into the MSI doorbell.
>> In case the MSI controller implements IRQ remapping, assigned
>> devices will not be able to trigger interrupts towards the
>> host. On the contrary, the assignment must be emphasized as
>> unsafe with respect to interrupts.
>>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
>>
>> ---
>> v7 -> v8:
>> - remove goto in irq_domain_check_msi_remap
>> - Added Marc's R-b
>>
>> v5 -> v6:
>> - use irq_domain_hierarchical_is_msi_remap()
>> - comment rewording
>>
>> v4 -> v5:
>> - Handle DOMAIN_BUS_FSL_MC_MSI domains
>> - Check parents
>> ---
>> include/linux/irqdomain.h | 1 +
>> kernel/irq/irqdomain.c | 22 ++++++++++++++++++++++
>> 2 files changed, 23 insertions(+)
>>
>> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
>> index bc2f571..188eced 100644
>> --- a/include/linux/irqdomain.h
>> +++ b/include/linux/irqdomain.h
>> @@ -222,6 +222,7 @@ struct irq_domain *irq_domain_add_legacy(struct
>> device_node *of_node,
>> void *host_data);
>> extern struct irq_domain *irq_find_matching_fwspec(struct irq_fwspec
>> *fwspec,
>> enum irq_domain_bus_token bus_token);
>> +extern bool irq_domain_check_msi_remap(void);
>> extern void irq_set_default_host(struct irq_domain *host);
>> extern int irq_domain_alloc_descs(int virq, unsigned int nr_irqs,
>> irq_hw_number_t hwirq, int node,
>> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
>> index 876e131..d889751 100644
>> --- a/kernel/irq/irqdomain.c
>> +++ b/kernel/irq/irqdomain.c
>> @@ -278,6 +278,28 @@ struct irq_domain
>> *irq_find_matching_fwspec(struct irq_fwspec *fwspec,
>> EXPORT_SYMBOL_GPL(irq_find_matching_fwspec);
>>
>> /**
>> + * irq_domain_check_msi_remap - Check whether all MSI
>> + * irq domains implement IRQ remapping
>> + */
>> +bool irq_domain_check_msi_remap(void)
>> +{
>> + struct irq_domain *h;
>> + bool ret = true;
>> +
>> + mutex_lock(&irq_domain_mutex);
>> + list_for_each_entry(h, &irq_domain_list, link) {
>> + if (irq_domain_is_msi(h) &&
>> + !irq_domain_hierarchical_is_msi_remap(h)) {
>> + ret = false;
>> + break;
>> + }
>> + }
>> + mutex_unlock(&irq_domain_mutex);
>> + return ret;
>> +}
>
> Above function returns true, even though there is no MSI irq domains. Is
> it intentional ?
>From the VFIO integration point of view this is what we want. If there
is no MSI controller in the system, we have no vulnerability with
respect to IRQ assignment and we consider the system as safe. If
requested I can add a comment?
Thanks
Eric
>
> Thanks,
> Tomasz
^ permalink raw reply
* arm: Add livepatch arch specific code
From: Miroslav Benes @ 2017-01-17 13:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117002239.GF9045@packer-debian-8-amd64.digitalocean.com>
> > But apply_relocate_add() is not implemented on arm yet. I guess it would
> > nice to have it... otherwise we could get to an unpleasant situation.
> > Livepatch module can rely on its livepatching relocations (that is, there
> > are some). apply_relocate_add() returns 0 on arm, so everything seems to
> > be nice and then boom some time later.
>
> Doesn't it return -ENOEXEC? MODULES_USE_ELF_RELA is not defined
> on arm, I think (see moduleloader.h).
You're right. It confused me too.
> > The question is what happens with normal modules. There are no SHT_RELA
> > records probably.
>
> For arm, I think there are only SHT_REL relocation sections
> (MODULES_USE_ELF_REL is set instead of MODULES_USE_ELF_RELA), so
> during apply_relocations() in load_module(), only apply_relocate()
> should be called, and not apply_relocate_add().
True.
> Hm, I guess that means if we want livepatch support for the
> architectures that don't support RELA relocations, we would have to
> check if the section is SHT_REL or SHT_RELA before calling the right
> apply_relocate* function.
Agreed.
Miroslav
^ permalink raw reply
* Nokia N900: mixers changed between 4.9 and 4.10-rc3, no longer can use in-call speaker
From: Peter Ujfalusi @ 2017-01-17 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <40dbce4e-d99d-d77d-e682-5b004c70ca40@bitmer.com>
On 01/15/2017 09:08 PM, Jarkko Nikula wrote:
> On 01/15/2017 12:05 PM, Pavel Machek wrote:
>>>> So regression seems to be between v4.9 and v4.10. Any ideas?
>>>
>>> Interesting... seems there are no sound relevant changes after v4.9.
>>>
>>> Looks like there are only three commits after v4.9 for sound/soc which
>>> are built for Nokia N900:
>>>
>>> e411b0b5eb9b65257a050eac333d181d6e00e2c6
>>> e7aa450fe17890e59db7d3c2d8eff5b6b41fc531
>>> 63c3194b82530bd71fd49db84eb7ab656b8d404a
>>>
>>> Maybe something not related to sound/soc could broke it?
>>
>> Lets see.
>>
>> a9042defa29a01cc538b742eab047848e9b5ae14 -- works ok.
>> ce38207f161513ee3d2bd3860489f07ebe65bc78 --
>>
>> alsactl: set_control:1328: failed to obtain info for control #229 (No
>> such file or directory)
>>
> I'm unable to test older kernels at the moment since modules don't load
> by some reason (bluetooth: Unknown symbol _GLOBAL_OFFSET_TABLE_ (err
> 0)). Probably some recent regression in my debian/testing installation
> since the same configs were working before.
>
> However v4.9.4 works and with it I can see there is an issue with these
> aic3x controls:
>
> amixer: Unable to find simple control 'Left DAC_L1 Mixer Line',0
>
>
>
> amixer: Unable to find simple control 'Right DAC_R1 Mixer Line',0
These are certainly not the regression between 4.6 and 4.9, more like
more like regression since 2.6:
'Line Switch' -> 'LineL Switch':
54f01916297bafc18bd7df4e2300a0544a84fce3
'LineL Switch' -> 'DACL1 Switch':
c3b79e05b4d9ab2e7c3ba281261ea87ab5b71a92
> At quick look I don't see why above commits could cause it. Maybe
> regression happened earlier between v4.6 and v4.9?
It might be that there were some work to fix control names for different aic
versions to match with the HW or support for new codec is added and some
control gone missing for 3x?
I would compare the 'amixer controls' for the working and regressed
kernel to see what differs. From there git blame or smthing will for
sure point to the correct commit.
--
P?ter
^ permalink raw reply
* [PATCH 2/2] arm64: dts: exynos: Add regulators for Vbus and Vbus-Boost
From: Javier Martinez Canillas @ 2017-01-17 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484649143-19423-3-git-send-email-pankaj.dubey@samsung.com>
Hello Pankaj,
On 01/17/2017 07:32 AM, Pankaj Dubey wrote:
> Adding fixed voltage regulators for Vbus and Vbus-boost required
> by USB 3.0 DRD controller on Exynos7-espresso board.
>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> Signed-off-by: Vivek Gautam <gautamvivek1987@gmail.com>
Same comment than 1/2 here.
> ---
> arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 44 +++++++++++++++++++++++++
> 1 file changed, 44 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> index 9cf73cf..68f3a51 100644
> --- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> @@ -33,6 +33,29 @@
> device_type = "memory";
> reg = <0x0 0x40000000 0x0 0xC0000000>;
> };
> +
> + usb30_vbus_reg: regulator-usb30 {
> + compatible = "regulator-fixed";
> + regulator-name = "VBUS_5V";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + gpio = <&gph1 1 0>;
Please use the GPIO_ACTIVE_HIGH instead for the GPIO polarity.
> + pinctrl-names = "default";
> + pinctrl-0 = <&usb30_vbus_en>;
> + enable-active-high;
> + };
> +
> + usb3drd_boost_5v: regulator-usb3drd-boost {
> + compatible = "regulator-fixed";
> + regulator-name = "VUSB_VBUS_5V";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + gpio = <&gpf4 1 0>;
Same here.
> + pinctrl-names = "default";
> + pinctrl-0 = <&usb3drd_boost_en>;
> + enable-active-high;
> + };
> +
> };
>
> &fin_pll {
> @@ -366,3 +389,24 @@
> vqmmc-supply = <&ldo2_reg>;
> disable-wp;
> };
> +
> +&usbdrd_phy {
> + vbus-supply = <&usb30_vbus_reg>;
> + vbus-boost-supply = <&usb3drd_boost_5v>;
> +};
> +
> +&pinctrl_bus1 {
> + usb30_vbus_en: usb30-vbus-en {
> + samsung,pins = "gph1-1";
> + samsung,pin-function = <1>;
EXYNOS_PIN_FUNC_OUTPUT
> + samsung,pin-pud = <0>;
EXYNOS_PIN_PULL_NONE
> + samsung,pin-drv = <0>;
I see that there are no Exynos7 drive strengths values for
Exynos7 in include/dt-bindings/pinctrl/samsung.h. It would
be good to add those (on a different series of course).
The patch looks good to me, so after the minor nits:
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH] crypto: arm64/aes-blk - honour iv_out requirement in CBC and CTR modes
From: Ard Biesheuvel @ 2017-01-17 13:46 UTC (permalink / raw)
To: linux-arm-kernel
Update the ARMv8 Crypto Extensions and the plain NEON AES implementations
in CBC and CTR modes to return the next IV back to the skcipher API client.
This is necessary for chaining to work correctly.
Note that for CTR, this is only done if the request is a round multiple of
the block size, since otherwise, chaining is impossible anyway.
Cc: <stable@vger.kernel.org> # v3.16+
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/aes-modes.S | 88 ++++++++++----------
1 file changed, 42 insertions(+), 46 deletions(-)
diff --git a/arch/arm64/crypto/aes-modes.S b/arch/arm64/crypto/aes-modes.S
index c53dbeae79f2..838dad5c209f 100644
--- a/arch/arm64/crypto/aes-modes.S
+++ b/arch/arm64/crypto/aes-modes.S
@@ -193,15 +193,16 @@ AES_ENTRY(aes_cbc_encrypt)
cbz w6, .Lcbcencloop
ld1 {v0.16b}, [x5] /* get iv */
- enc_prepare w3, x2, x5
+ enc_prepare w3, x2, x6
.Lcbcencloop:
ld1 {v1.16b}, [x1], #16 /* get next pt block */
eor v0.16b, v0.16b, v1.16b /* ..and xor with iv */
- encrypt_block v0, w3, x2, x5, w6
+ encrypt_block v0, w3, x2, x6, w7
st1 {v0.16b}, [x0], #16
subs w4, w4, #1
bne .Lcbcencloop
+ st1 {v0.16b}, [x5] /* return iv */
ret
AES_ENDPROC(aes_cbc_encrypt)
@@ -211,7 +212,7 @@ AES_ENTRY(aes_cbc_decrypt)
cbz w6, .LcbcdecloopNx
ld1 {v7.16b}, [x5] /* get iv */
- dec_prepare w3, x2, x5
+ dec_prepare w3, x2, x6
.LcbcdecloopNx:
#if INTERLEAVE >= 2
@@ -248,7 +249,7 @@ AES_ENTRY(aes_cbc_decrypt)
.Lcbcdecloop:
ld1 {v1.16b}, [x1], #16 /* get next ct block */
mov v0.16b, v1.16b /* ...and copy to v0 */
- decrypt_block v0, w3, x2, x5, w6
+ decrypt_block v0, w3, x2, x6, w7
eor v0.16b, v0.16b, v7.16b /* xor with iv => pt */
mov v7.16b, v1.16b /* ct is next iv */
st1 {v0.16b}, [x0], #16
@@ -256,6 +257,7 @@ AES_ENTRY(aes_cbc_decrypt)
bne .Lcbcdecloop
.Lcbcdecout:
FRAME_POP
+ st1 {v7.16b}, [x5] /* return iv */
ret
AES_ENDPROC(aes_cbc_decrypt)
@@ -267,24 +269,15 @@ AES_ENDPROC(aes_cbc_decrypt)
AES_ENTRY(aes_ctr_encrypt)
FRAME_PUSH
- cbnz w6, .Lctrfirst /* 1st time around? */
- umov x5, v4.d[1] /* keep swabbed ctr in reg */
- rev x5, x5
-#if INTERLEAVE >= 2
- cmn w5, w4 /* 32 bit overflow? */
- bcs .Lctrinc
- add x5, x5, #1 /* increment BE ctr */
- b .LctrincNx
-#else
- b .Lctrinc
-#endif
-.Lctrfirst:
+ cbz w6, .Lctrnotfirst /* 1st time around? */
enc_prepare w3, x2, x6
ld1 {v4.16b}, [x5]
- umov x5, v4.d[1] /* keep swabbed ctr in reg */
- rev x5, x5
+
+.Lctrnotfirst:
+ umov x8, v4.d[1] /* keep swabbed ctr in reg */
+ rev x8, x8
#if INTERLEAVE >= 2
- cmn w5, w4 /* 32 bit overflow? */
+ cmn w8, w4 /* 32 bit overflow? */
bcs .Lctrloop
.LctrloopNx:
subs w4, w4, #INTERLEAVE
@@ -292,11 +285,11 @@ AES_ENTRY(aes_ctr_encrypt)
#if INTERLEAVE == 2
mov v0.8b, v4.8b
mov v1.8b, v4.8b
- rev x7, x5
- add x5, x5, #1
+ rev x7, x8
+ add x8, x8, #1
ins v0.d[1], x7
- rev x7, x5
- add x5, x5, #1
+ rev x7, x8
+ add x8, x8, #1
ins v1.d[1], x7
ld1 {v2.16b-v3.16b}, [x1], #32 /* get 2 input blocks */
do_encrypt_block2x
@@ -305,7 +298,7 @@ AES_ENTRY(aes_ctr_encrypt)
st1 {v0.16b-v1.16b}, [x0], #32
#else
ldr q8, =0x30000000200000001 /* addends 1,2,3[,0] */
- dup v7.4s, w5
+ dup v7.4s, w8
mov v0.16b, v4.16b
add v7.4s, v7.4s, v8.4s
mov v1.16b, v4.16b
@@ -323,18 +316,12 @@ AES_ENTRY(aes_ctr_encrypt)
eor v2.16b, v7.16b, v2.16b
eor v3.16b, v5.16b, v3.16b
st1 {v0.16b-v3.16b}, [x0], #64
- add x5, x5, #INTERLEAVE
+ add x8, x8, #INTERLEAVE
#endif
- cbz w4, .LctroutNx
-.LctrincNx:
- rev x7, x5
+ rev x7, x8
ins v4.d[1], x7
+ cbz w4, .Lctrout
b .LctrloopNx
-.LctroutNx:
- sub x5, x5, #1
- rev x7, x5
- ins v4.d[1], x7
- b .Lctrout
.Lctr1x:
adds w4, w4, #INTERLEAVE
beq .Lctrout
@@ -342,30 +329,39 @@ AES_ENTRY(aes_ctr_encrypt)
.Lctrloop:
mov v0.16b, v4.16b
encrypt_block v0, w3, x2, x6, w7
+
+ adds x8, x8, #1 /* increment BE ctr */
+ rev x7, x8
+ ins v4.d[1], x7
+ bcs .Lctrcarry /* overflow? */
+
+.Lctrcarrydone:
subs w4, w4, #1
bmi .Lctrhalfblock /* blocks < 0 means 1/2 block */
ld1 {v3.16b}, [x1], #16
eor v3.16b, v0.16b, v3.16b
st1 {v3.16b}, [x0], #16
- beq .Lctrout
-.Lctrinc:
- adds x5, x5, #1 /* increment BE ctr */
- rev x7, x5
- ins v4.d[1], x7
- bcc .Lctrloop /* no overflow? */
- umov x7, v4.d[0] /* load upper word of ctr */
- rev x7, x7 /* ... to handle the carry */
- add x7, x7, #1
- rev x7, x7
- ins v4.d[0], x7
- b .Lctrloop
+ bne .Lctrloop
+
+.Lctrout:
+ st1 {v4.16b}, [x5] /* return next CTR value */
+ FRAME_POP
+ ret
+
.Lctrhalfblock:
ld1 {v3.8b}, [x1]
eor v3.8b, v0.8b, v3.8b
st1 {v3.8b}, [x0]
-.Lctrout:
FRAME_POP
ret
+
+.Lctrcarry:
+ umov x7, v4.d[0] /* load upper word of ctr */
+ rev x7, x7 /* ... to handle the carry */
+ add x7, x7, #1
+ rev x7, x7
+ ins v4.d[0], x7
+ b .Lctrcarrydone
AES_ENDPROC(aes_ctr_encrypt)
.ltorg
--
2.7.4
^ permalink raw reply related
* [PATCH v8 14/18] irqdomain: irq_domain_check_msi_remap
From: Tomasz Nowicki @ 2017-01-17 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484127714-3263-15-git-send-email-eric.auger@redhat.com>
On 11.01.2017 10:41, Eric Auger wrote:
> This new function checks whether all MSI irq domains
> implement IRQ remapping. This is useful to understand
> whether VFIO passthrough is safe with respect to interrupts.
>
> On ARM typically an MSI controller can sit downstream
> to the IOMMU without preventing VFIO passthrough.
> As such any assigned device can write into the MSI doorbell.
> In case the MSI controller implements IRQ remapping, assigned
> devices will not be able to trigger interrupts towards the
> host. On the contrary, the assignment must be emphasized as
> unsafe with respect to interrupts.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
>
> ---
> v7 -> v8:
> - remove goto in irq_domain_check_msi_remap
> - Added Marc's R-b
>
> v5 -> v6:
> - use irq_domain_hierarchical_is_msi_remap()
> - comment rewording
>
> v4 -> v5:
> - Handle DOMAIN_BUS_FSL_MC_MSI domains
> - Check parents
> ---
> include/linux/irqdomain.h | 1 +
> kernel/irq/irqdomain.c | 22 ++++++++++++++++++++++
> 2 files changed, 23 insertions(+)
>
> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
> index bc2f571..188eced 100644
> --- a/include/linux/irqdomain.h
> +++ b/include/linux/irqdomain.h
> @@ -222,6 +222,7 @@ struct irq_domain *irq_domain_add_legacy(struct device_node *of_node,
> void *host_data);
> extern struct irq_domain *irq_find_matching_fwspec(struct irq_fwspec *fwspec,
> enum irq_domain_bus_token bus_token);
> +extern bool irq_domain_check_msi_remap(void);
> extern void irq_set_default_host(struct irq_domain *host);
> extern int irq_domain_alloc_descs(int virq, unsigned int nr_irqs,
> irq_hw_number_t hwirq, int node,
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index 876e131..d889751 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -278,6 +278,28 @@ struct irq_domain *irq_find_matching_fwspec(struct irq_fwspec *fwspec,
> EXPORT_SYMBOL_GPL(irq_find_matching_fwspec);
>
> /**
> + * irq_domain_check_msi_remap - Check whether all MSI
> + * irq domains implement IRQ remapping
> + */
> +bool irq_domain_check_msi_remap(void)
> +{
> + struct irq_domain *h;
> + bool ret = true;
> +
> + mutex_lock(&irq_domain_mutex);
> + list_for_each_entry(h, &irq_domain_list, link) {
> + if (irq_domain_is_msi(h) &&
> + !irq_domain_hierarchical_is_msi_remap(h)) {
> + ret = false;
> + break;
> + }
> + }
> + mutex_unlock(&irq_domain_mutex);
> + return ret;
> +}
Above function returns true, even though there is no MSI irq domains. Is
it intentional ?
Thanks,
Tomasz
^ permalink raw reply
* [PATCH v4 4/4] arm64: dts: juno: add missing CoreSight STM component
From: Suzuki K Poulose @ 2017-01-17 13:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484655313-9025-5-git-send-email-sudeep.holla@arm.com>
On 17/01/17 12:15, Sudeep Holla wrote:
> From: Mike Leach <mike.leach@linaro.org>
>
> This patch adds the missing CoreSight STM component definition to the
> device tree of all the juno variants(r0,r1,r2)
>
> STM component is connected to different funnels depending on Juno
> platform variant.
>
> Reviewed-and-Tested-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Mike Leach <mike.leach@linaro.org>
> [sudeep.holla at arm.com: minor changelog update and reorganising the STM
> node back into juno-base.dtsi to avoid duplication]
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> arch/arm64/boot/dts/arm/juno-base.dtsi | 15 +++++++++++++++
> arch/arm64/boot/dts/arm/juno-r1.dts | 4 ++++
> arch/arm64/boot/dts/arm/juno-r2.dts | 4 ++++
> arch/arm64/boot/dts/arm/juno.dts | 16 ++++++++++++++++
> 4 files changed, 39 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
> index faedf357db3b..58c1773c3aa4 100644
> --- a/arch/arm64/boot/dts/arm/juno-base.dtsi
> +++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
> @@ -185,6 +185,21 @@
> };
> };
>
> + stm at 20100000 {
> + compatible = "arm,coresight-stm", "arm,primecell";
> + reg = <0 0x20100000 0 0x1000>,
> + <0 0x28000000 0 0x180000>;
The size of the stimulus base is 16MB (as per TRM), implies => 0x1000000.
with that fixed :
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
^ permalink raw reply
* [PATCH 1/2] arm64: dts: exynos: Add USB 3.0 controller node for Exynos7
From: Javier Martinez Canillas @ 2017-01-17 13:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484649143-19423-2-git-send-email-pankaj.dubey@samsung.com>
Hello Pankaj,
On 01/17/2017 07:32 AM, Pankaj Dubey wrote:
> Add USB 3.0 DRD controller device node, with its clock
> and phy information to enable the same on Exynos7.
>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> Signed-off-by: Vivek Gautam <gautamvivek1987@gmail.com>
The S-o-B order isn't correct. You are the one posting the patch so
yours should be the last one.
Also, wasn't this patch originally from Vivek? If you didn't change
that much, I think that he should be listed as the patch author.
I don't have an Exynos7 manual to verify but the patch looks good.
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [RFC PATCH 08/10] arm64/sve: ptrace: Wire up vector length control and reporting
From: Alan Hayward @ 2017-01-17 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117100349.GR3699@e103592.cambridge.arm.com>
> On 17 Jan 2017, at 10:03, Dave Martin <Dave.Martin@arm.com> wrote:
>
> On Mon, Jan 16, 2017 at 03:11:56PM +0000, Yao Qi wrote:
>> On 17-01-16 13:32:31, Dave Martin wrote:
>>> On Mon, Jan 16, 2017 at 12:20:38PM +0000, Yao Qi wrote:
>>>> On 17-01-12 11:26:07, Dave Martin wrote:
>>>>> This patch adds support for manipulating a task's vector length at
>>>>> runtime via ptrace.
>>>>>
>>>>
>>>> I hope kernel doesn't provide such interface to ptracer to change vector
>>>> length.
>>>
>>> It does, with this patch, beacuse...
>>>
>>>> The vector length is sort of a read-only property of thread/process/
>>>> program to debugger, unless we really have a clear requirement to modify
>>>> vector length in debugging. I may miss something because I haven't debug
>>>> SVE code yet.
>>>
>>> ...the vector length is no longer read-only for the task, thanks to
>>> the new prctls().
>>
>> What I meant "read-only" is that debugger can't change it, while the program
>> itself can change it via prctl().
>
> I see.
>
>>>
>>> This does add complexity, but I figured that any programmer's model
>>> state that the thread can modify for itself should be modifiable by the
>>> debugger, if for no other reason than the user may want to experiment to
>>> see what happens. Without a ptrace interface, it would be necessary
>>> to inject a prctl() call into the target, which is possible but awkward.
>>
>> We only need such interface if it is useful, see more below.
>>
>> Suppose it is useful to change vector length through ptrace, we should align
>> ptrace interface to prctl() as much as possible. Looks that both prctl
>> change and ptrace change can go through sve_set_vector_length, easy to keep
>> two consistent.
>>
>>>
>>> gdb must already re-detect the vector length on stop, since the target
>>> could have called the prctl() in the meantime.
>>
>> Yes, gdb assumes the vector length may be changed, so it re-detects on
>> every stop, but I don't see the need for gdb to change the vector length.
>>
>>>
>>> Access via ptrace also allows things like trapping on exec, fork or
>>> clone and changing the vector length for the new process or thread
>>> before it starts to run. I'm guessing here, but such a scenario seems
>>> legitimate (?)
>>>
>>
>> Yes, these cases are valid, but the usefulness is still questionable to
>> me. I just doubt that SVE developers do need to change vector length
>> when they are debugging code. Note that it is not my strong objection
>> to this patch, if kernel people believe this is useful, I am fine with
>> it.
>
> That's fair. I'll leave the patch there for now and see if anyone else
> has a comment to make, but it could be removed without affecting
> anything else.
>
I would say that whilst it is a very dangerous thing to do and has many
consequences, there is a requirement for a gdb user to be able to change VL
whilst debugging a running process, and I don?t think we should see
changing VL as much different from changing a register value on the fly.
Say you have a loop in assembly you are trying to debug - you might write
to $x2 and then single step to see how this effects the result. With SVE
code you might want to see how different VL values will effect the layout
of results in the vectors, how it effects the predicates and how it changes
the number of iterations the loop makes. Of course, once you exit the
loop all bets are off - just like if you had been changing register values.
The current proposal for gdb is that we will show $VL in the list of
registers, therefore for consistency it?d make sense for the gdb user to
be able to set it as if it was just another register. For this we need a
simple way to change the VL in another process, and I think ptrace() is
the easiest way (given that prctl() only changes its own process).
> Are there situations in which injecting a function call into the target
> won't work, i.e., where we couldn't do:
>
> set prctl(...)
>
> ?
>
> Using the prctl interface this way, it would also be preferable to refer
> to the #defines by name.
>
> Cheers
> ?Dave
Thanks,
Alan.
^ permalink raw reply
* [PATCH v4 3/4] arm64: dts: juno: add CoreSight support for Juno r1/r2 variants
From: Suzuki K Poulose @ 2017-01-17 13:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484655313-9025-4-git-send-email-sudeep.holla@arm.com>
On 17/01/17 12:15, Sudeep Holla wrote:
> From: Mike Leach <mike.leach@linaro.org>
>
> The CoreSight support added for Juno is valid for only Juno r0.
> The Juno r1 and r2 variants have additional components and alternative
> connection routes between trace source and sinks.
>
> This patch builds on top of the existing r0 support and extends it to
> Juno r1/r2 variants.
>
> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Mike Leach <mike.leach@linaro.org>
> [sudeep.holla at arm.com: minor changelog update and major reorganisation of
> the common coresight components back into juno-base.dtsi to avoid
> duplication, also renamed funnel node names]
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi | 100 ++++++++++++++++++++++++++++++
> arch/arm64/boot/dts/arm/juno-r1.dts | 9 +++
> arch/arm64/boot/dts/arm/juno-r2.dts | 9 +++
> 3 files changed, 118 insertions(+)
> create mode 100644 arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
>
> diff --git a/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi b/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
> new file mode 100644
> index 000000000000..563463ed28c7
> --- /dev/null
> +++ b/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
> @@ -0,0 +1,100 @@
> +/ {
> + funnel at 20130000 { /* cssys2 */
Typo, that should be csys1. Rest looks good to me.
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
^ permalink raw reply
* [PATCH v19 10/15] clocksource/drivers/arm_arch_timer: Refactor the timer init code to prepare for GTDT
From: Fu Wei @ 2017-01-17 13:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117122921.GE11939@leverpostej>
Hi Mark,
On 17 January 2017 at 20:29, Mark Rutland <mark.rutland@arm.com> wrote:
> On Tue, Jan 17, 2017 at 06:18:12AM -0600, Timur Tabi wrote:
>> Fu Wei wrote:
>> >if (i >= ARCH_TIMER_MEM_MAX_FRAMES) {
>> > pr_err(FW_BUG "too many frames, ARMv8 spec only allows 8.\n");
>>
>> pr_err(FW_BUG "too many frames, ARMv8 spec only allows %u.\n",
>> ARCH_TIMER_MEM_MAX_FRAMES);
>
> While I don't see ARCH_TIMER_MEM_MAX_FRAMES changing, this would be
> nicer to ensure the result obviously matches.
>
> As for wording, I'd perfer:
>
> pr_err(FW_BUG "too many frames, only %u are permitted.\n",
> ARCH_TIMER_MEM_MAX_FRAMES);
OK, will do so.
Thanks!
>
> ... so as to avoid any confusion between spec versions and so on. We can
> reconsider the message if/when that changes.
>
> Thanks,
> Mark.
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ permalink raw reply
* [PATCH v8 10/18] iommu/arm-smmu: Implement reserved region get/put callbacks
From: Tomasz Nowicki @ 2017-01-17 13:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484127714-3263-11-git-send-email-eric.auger@redhat.com>
On 11.01.2017 10:41, Eric Auger wrote:
> The get() populates the list with the MSI IOVA reserved window.
>
> At the moment an arbitray MSI IOVA window is set at 0x8000000
> of size 1MB. This will allow to report those info in iommu-group
> sysfs.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Tomasz Nowicki <tomasz.nowicki@caviumnetworks.com>
Thanks,
Tomasz
>
> ---
>
> v3 -> v4:
> - do not handle PCI host bridge windows anymore
> - encode prot
>
> RFC v2 -> v3:
> - use existing get/put_resv_regions
>
> RFC v1 -> v2:
> - use defines for MSI IOVA base and length
> ---
> drivers/iommu/arm-smmu.c | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index a60cded..a354572 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -281,6 +281,9 @@ enum arm_smmu_s2cr_privcfg {
>
> #define FSYNR0_WNR (1 << 4)
>
> +#define MSI_IOVA_BASE 0x8000000
> +#define MSI_IOVA_LENGTH 0x100000
> +
> static int force_stage;
> module_param(force_stage, int, S_IRUGO);
> MODULE_PARM_DESC(force_stage,
> @@ -1549,6 +1552,29 @@ static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
> return iommu_fwspec_add_ids(dev, &fwid, 1);
> }
>
> +static void arm_smmu_get_resv_regions(struct device *dev,
> + struct list_head *head)
> +{
> + struct iommu_resv_region *region;
> + int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
> +
> + region = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH,
> + prot, IOMMU_RESV_MSI);
> + if (!region)
> + return;
> +
> + list_add_tail(®ion->list, head);
> +}
> +
> +static void arm_smmu_put_resv_regions(struct device *dev,
> + struct list_head *head)
> +{
> + struct iommu_resv_region *entry, *next;
> +
> + list_for_each_entry_safe(entry, next, head, list)
> + kfree(entry);
> +}
> +
> static struct iommu_ops arm_smmu_ops = {
> .capable = arm_smmu_capable,
> .domain_alloc = arm_smmu_domain_alloc,
> @@ -1564,6 +1590,8 @@ static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
> .domain_get_attr = arm_smmu_domain_get_attr,
> .domain_set_attr = arm_smmu_domain_set_attr,
> .of_xlate = arm_smmu_of_xlate,
> + .get_resv_regions = arm_smmu_get_resv_regions,
> + .put_resv_regions = arm_smmu_put_resv_regions,
> .pgsize_bitmap = -1UL, /* Restricted during device attach */
> };
>
>
^ permalink raw reply
* [PATCH v4 4/4] cpufreq: dt: Don't use generic platdev driver for ti-cpufreq platforms
From: Dave Gerlach @ 2017-01-17 13:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117131808.29798-1-d-gerlach@ti.com>
Some TI platforms, specifically those in the am33xx, am43xx, dra7xx, and
am57xx families of SoCs can make use of the ti-cpufreq driver to
selectively enable OPPs based on the exact configuration in use. The
ti-cpufreq is given the responsibility of creating the cpufreq-dt
platform device when the driver is in use so drop am33xx and dra7xx
from the cpufreq-dt-platdev driver so it is not created twice.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
drivers/cpufreq/cpufreq-dt-platdev.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index 7fcaf26e8f81..921b4a6c3d16 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -87,8 +87,6 @@ static const struct of_device_id machines[] __initconst = {
{ .compatible = "socionext,uniphier-ld11", },
{ .compatible = "socionext,uniphier-ld20", },
- { .compatible = "ti,am33xx", },
- { .compatible = "ti,dra7", },
{ .compatible = "ti,omap2", },
{ .compatible = "ti,omap3", },
{ .compatible = "ti,omap4", },
--
2.11.0
^ permalink raw reply related
* [PATCH v4 3/4] cpufreq: ti: Add cpufreq driver to determine available OPPs at runtime
From: Dave Gerlach @ 2017-01-17 13:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117131808.29798-1-d-gerlach@ti.com>
Some TI SoCs, like those in the AM335x, AM437x, DRA7x, and AM57x families,
have different OPPs available for the MPU depending on which specific
variant of the SoC is in use. This can be determined through use of the
revision and an eFuse register present in the silicon. Introduce a
ti-cpufreq driver that can read the aformentioned values and provide
them as version matching data to the opp framework. Through this the
opp-supported-hw dt binding that is part of the operating-points-v2
table can be used to indicate availability of OPPs for each device.
This driver also creates the "cpufreq-dt" platform_device after passing
the version matching data to the OPP framework so that the cpufreq-dt
handles the actual cpufreq implementation. Even without the necessary
data to pass the version matching data the driver will still create this
device to maintain backwards compatibility with operating-points v1
tables.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
v3->v4:
Update to use simplified binding, only use "syscon" now to pass control
module register space and add offsets to relevant data for each SoC.
drivers/cpufreq/Kconfig.arm | 11 ++
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/ti-cpufreq.c | 272 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 284 insertions(+)
create mode 100644 drivers/cpufreq/ti-cpufreq.c
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 920c469f3953..6d87742fc5aa 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -247,6 +247,17 @@ config ARM_TEGRA124_CPUFREQ
help
This adds the CPUFreq driver support for Tegra124 SOCs.
+config ARM_TI_CPUFREQ
+ bool "Texas Instruments CPUFreq support"
+ depends on ARCH_OMAP2PLUS
+ help
+ This driver enables valid OPPs on the running platform based on
+ values contained within the SoC in use. Enable this in order to
+ use the cpufreq-dt driver on all Texas Instruments platforms that
+ provide dt based operating-points-v2 tables with opp-supported-hw
+ data provided. Required for cpufreq support on AM335x, AM437x,
+ DRA7x, and AM57x platforms.
+
config ARM_PXA2xx_CPUFREQ
tristate "Intel PXA2xx CPUfreq driver"
depends on PXA27x || PXA25x
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 1e46c3918e7a..2078a0f212d8 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -77,6 +77,7 @@ obj-$(CONFIG_ARM_SPEAR_CPUFREQ) += spear-cpufreq.o
obj-$(CONFIG_ARM_STI_CPUFREQ) += sti-cpufreq.o
obj-$(CONFIG_ARM_TEGRA20_CPUFREQ) += tegra20-cpufreq.o
obj-$(CONFIG_ARM_TEGRA124_CPUFREQ) += tegra124-cpufreq.o
+obj-$(CONFIG_ARM_TI_CPUFREQ) += ti-cpufreq.o
obj-$(CONFIG_ARM_VEXPRESS_SPC_CPUFREQ) += vexpress-spc-cpufreq.o
obj-$(CONFIG_ACPI_CPPC_CPUFREQ) += cppc_cpufreq.o
obj-$(CONFIG_MACH_MVEBU_V7) += mvebu-cpufreq.o
diff --git a/drivers/cpufreq/ti-cpufreq.c b/drivers/cpufreq/ti-cpufreq.c
new file mode 100644
index 000000000000..a2a4e84c6166
--- /dev/null
+++ b/drivers/cpufreq/ti-cpufreq.c
@@ -0,0 +1,272 @@
+/*
+ * TI CPUFreq/OPP hw-supported driver
+ *
+ * Copyright (C) 2016-2017 Texas Instruments, Inc.
+ * Dave Gerlach <d-gerlach@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/cpu.h>
+#include <linux/io.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/pm_opp.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+
+#define REVISION_MASK 0xF
+#define REVISION_SHIFT 28
+
+#define AM33XX_800M_ARM_MPU_MAX_FREQ 0x1E2F
+#define AM43XX_600M_ARM_MPU_MAX_FREQ 0xFFA
+
+#define DRA7_EFUSE_HAS_OD_MPU_OPP 11
+#define DRA7_EFUSE_HAS_HIGH_MPU_OPP 15
+#define DRA7_EFUSE_HAS_ALL_MPU_OPP 23
+
+#define DRA7_EFUSE_NOM_MPU_OPP BIT(0)
+#define DRA7_EFUSE_OD_MPU_OPP BIT(1)
+#define DRA7_EFUSE_HIGH_MPU_OPP BIT(2)
+
+#define VERSION_COUNT 2
+
+struct ti_cpufreq_data;
+
+struct ti_cpufreq_soc_data {
+ unsigned long (*efuse_xlate)(struct ti_cpufreq_data *opp_data,
+ unsigned long efuse);
+ unsigned long efuse_fallback;
+ unsigned long efuse_offset;
+ unsigned long efuse_mask;
+ unsigned long efuse_shift;
+ unsigned long rev_offset;
+};
+
+struct ti_cpufreq_data {
+ struct device *cpu_dev;
+ struct device_node *opp_node;
+ struct regmap *syscon;
+ const struct ti_cpufreq_soc_data *soc_data;
+};
+
+static unsigned long amx3_efuse_xlate(struct ti_cpufreq_data *opp_data,
+ unsigned long efuse)
+{
+ if (!efuse)
+ efuse = opp_data->soc_data->efuse_fallback;
+ /* AM335x and AM437x use "OPP disable" bits, so invert */
+ return ~efuse;
+}
+
+static unsigned long dra7_efuse_xlate(struct ti_cpufreq_data *opp_data,
+ unsigned long efuse)
+{
+ unsigned long calculated_efuse = DRA7_EFUSE_NOM_MPU_OPP;
+
+ /*
+ * The efuse on dra7 and am57 parts contains a specific
+ * value indicating the highest available OPP.
+ */
+
+ switch (efuse) {
+ case DRA7_EFUSE_HAS_ALL_MPU_OPP:
+ case DRA7_EFUSE_HAS_HIGH_MPU_OPP:
+ calculated_efuse |= DRA7_EFUSE_HIGH_MPU_OPP;
+ case DRA7_EFUSE_HAS_OD_MPU_OPP:
+ calculated_efuse |= DRA7_EFUSE_OD_MPU_OPP;
+ }
+
+ return calculated_efuse;
+}
+
+static struct ti_cpufreq_soc_data am3x_soc_data = {
+ .efuse_xlate = amx3_efuse_xlate,
+ .efuse_fallback = AM33XX_800M_ARM_MPU_MAX_FREQ,
+ .efuse_offset = 0x07fc,
+ .efuse_mask = 0x1fff,
+ .rev_offset = 0x600,
+};
+
+static struct ti_cpufreq_soc_data am4x_soc_data = {
+ .efuse_xlate = amx3_efuse_xlate,
+ .efuse_fallback = AM43XX_600M_ARM_MPU_MAX_FREQ,
+ .efuse_offset = 0x0610,
+ .efuse_mask = 0x3f,
+ .rev_offset = 0x600,
+};
+
+static struct ti_cpufreq_soc_data dra7_soc_data = {
+ .efuse_xlate = dra7_efuse_xlate,
+ .efuse_offset = 0x020c,
+ .efuse_mask = 0xf80000,
+ .efuse_shift = 19,
+ .rev_offset = 0x204,
+};
+
+/**
+ * ti_cpufreq_get_efuse() - Parse and return efuse value present on SoC
+ * @opp_data: pointer to ti_cpufreq_data context
+ * @efuse_value: Set to the value parsed from efuse
+ *
+ * Returns error code if efuse not read properly.
+ */
+static int ti_cpufreq_get_efuse(struct ti_cpufreq_data *opp_data,
+ u32 *efuse_value)
+{
+ struct device *dev = opp_data->cpu_dev;
+ u32 efuse;
+ int ret;
+
+ ret = regmap_read(opp_data->syscon, opp_data->soc_data->efuse_offset,
+ &efuse);
+ if (ret) {
+ dev_err(dev,
+ "Failed to read the efuse value from syscon: %d\n",
+ ret);
+ return ret;
+ }
+
+ efuse = (efuse & opp_data->soc_data->efuse_mask);
+ efuse >>= opp_data->soc_data->efuse_shift;
+
+ *efuse_value = opp_data->soc_data->efuse_xlate(opp_data, efuse);
+
+ return 0;
+}
+
+/**
+ * ti_cpufreq_get_rev() - Parse and return rev value present on SoC
+ * @opp_data: pointer to ti_cpufreq_data context
+ * @revision_value: Set to the value parsed from revision register
+ *
+ * Returns error code if revision not read properly.
+ */
+static int ti_cpufreq_get_rev(struct ti_cpufreq_data *opp_data,
+ u32 *revision_value)
+{
+ struct device *dev = opp_data->cpu_dev;
+ u32 revision;
+ int ret;
+
+ ret = regmap_read(opp_data->syscon, opp_data->soc_data->rev_offset,
+ &revision);
+ if (ret) {
+ dev_err(dev,
+ "Failed to read the revision number from syscon: %d\n",
+ ret);
+ return ret;
+ }
+
+ *revision_value = BIT((revision >> REVISION_SHIFT) & REVISION_MASK);
+
+ return 0;
+}
+
+static int ti_cpufreq_setup_syscon_register(struct ti_cpufreq_data *opp_data)
+{
+ struct device *dev = opp_data->cpu_dev;
+ struct device_node *np = opp_data->opp_node;
+
+ opp_data->syscon = syscon_regmap_lookup_by_phandle(np,
+ "syscon");
+ if (IS_ERR(opp_data->syscon)) {
+ dev_err(dev,
+ "\"syscon\" is missing, cannot use OPPv2 table.\n");
+ return PTR_ERR(opp_data->syscon);
+ }
+
+ return 0;
+}
+
+static const struct of_device_id ti_cpufreq_of_match[] = {
+ { .compatible = "ti,am33xx", .data = &am3x_soc_data, },
+ { .compatible = "ti,am4372", .data = &am4x_soc_data, },
+ { .compatible = "ti,dra7", .data = &dra7_soc_data },
+ {},
+};
+
+static int ti_cpufreq_init(void)
+{
+ u32 version[VERSION_COUNT];
+ struct device_node *np;
+ const struct of_device_id *match;
+ struct ti_cpufreq_data *opp_data;
+ int ret;
+
+ np = of_find_node_by_path("/");
+ match = of_match_node(ti_cpufreq_of_match, np);
+ if (!match)
+ return -ENODEV;
+
+ opp_data = kzalloc(sizeof(*opp_data), GFP_KERNEL);
+ if (!opp_data)
+ return -ENOMEM;
+
+ opp_data->soc_data = match->data;
+
+ opp_data->cpu_dev = get_cpu_device(0);
+ if (!opp_data->cpu_dev) {
+ pr_err("%s: Failed to get device for CPU0\n", __func__);
+ return -ENODEV;
+ }
+
+ opp_data->opp_node = dev_pm_opp_of_get_opp_desc_node(opp_data->cpu_dev);
+ if (!opp_data->opp_node) {
+ dev_info(opp_data->cpu_dev,
+ "OPP-v2 not supported, cpufreq-dt will attempt to use legacy tables.\n");
+ goto register_cpufreq_dt;
+ }
+
+ ret = ti_cpufreq_setup_syscon_register(opp_data);
+ if (ret)
+ goto fail_put_node;
+
+ /*
+ * OPPs determine whether or not they are supported based on
+ * two metrics:
+ * 0 - SoC Revision
+ * 1 - eFuse value
+ */
+ ret = ti_cpufreq_get_rev(opp_data, &version[0]);
+ if (ret)
+ goto fail_put_node;
+
+ ret = ti_cpufreq_get_efuse(opp_data, &version[1]);
+ if (ret)
+ goto fail_put_node;
+
+ of_node_put(opp_data->opp_node);
+
+ ret = dev_pm_opp_set_supported_hw(opp_data->cpu_dev, version,
+ VERSION_COUNT);
+ if (ret) {
+ dev_err(opp_data->cpu_dev,
+ "Failed to set supported hardware\n");
+ goto fail_put_node;
+ }
+
+register_cpufreq_dt:
+ platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
+
+ return 0;
+
+fail_put_node:
+ of_node_put(opp_data->opp_node);
+
+ return ret;
+}
+module_init(ti_cpufreq_init);
+
+MODULE_DESCRIPTION("TI CPUFreq/OPP hw-supported driver");
+MODULE_AUTHOR("Dave Gerlach <d-gerlach@ti.com>");
+MODULE_LICENSE("GPL v2");
--
2.11.0
^ permalink raw reply related
* [PATCH v4 2/4] Documentation: dt: add bindings for ti-cpufreq
From: Dave Gerlach @ 2017-01-17 13:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117131808.29798-1-d-gerlach@ti.com>
Add the device tree bindings document for the TI CPUFreq/OPP driver
on AM33xx, AM43xx, DRA7xx, and AM57xx SoCs. The operating-points-v2
binding allows us to provide an opp-supported-hw property for each OPP
to define when it is available. This driver is responsible for reading
and parsing registers to determine which OPPs can be selectively enabled
based on the specific SoC in use by matching against the opp-supported-hw
data.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
v3->v4:
Update to simplify binding, only use "syscon" now to pass control
module register space and let driver handle offsets.
.../devicetree/bindings/cpufreq/ti-cpufreq.txt | 128 +++++++++++++++++++++
1 file changed, 128 insertions(+)
create mode 100644 Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
diff --git a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
new file mode 100644
index 000000000000..58efa4c72545
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
@@ -0,0 +1,128 @@
+TI CPUFreq and OPP bindings
+================================
+
+Certain TI SoCs, like those in the am335x, am437x, am57xx, and dra7xx
+families support different OPPs depending on the silicon variant in use.
+The ti-cpufreq driver can use revision and an efuse value from the SoC to
+provide the OPP framework with supported hardware information. This is
+used to determine which OPPs from the operating-points-v2 table get enabled
+when it is parsed by the OPP framework.
+
+Required properties:
+--------------------
+In 'cpus' nodes:
+- operating-points-v2: Phandle to the operating-points-v2 table to use.
+
+In 'operating-points-v2' table:
+- compatible: Should be
+ - 'operating-points-v2-ti-cpu' for am335x, am43xx, and dra7xx/am57xx SoCs
+- syscon: A phandle pointing to a syscon node representing the control module
+ register space of the SoC.
+
+Optional properties:
+--------------------
+For each opp entry in 'operating-points-v2' table:
+- opp-supported-hw: Two bitfields indicating:
+ 1. Which revision of the SoC the OPP is supported by
+ 2. Which eFuse bits indicate this OPP is available
+
+ A bitwise AND is performed against these values and if any bit
+ matches, the OPP gets enabled.
+
+Example:
+--------
+
+/* From arch/arm/boot/dts/am33xx.dtsi */
+cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu at 0 {
+ compatible = "arm,cortex-a8";
+ device_type = "cpu";
+ reg = <0>;
+
+ operating-points-v2 = <&cpu0_opp_table>;
+
+ clocks = <&dpll_mpu_ck>;
+ clock-names = "cpu";
+
+ clock-latency = <300000>; /* From omap-cpufreq driver */
+ };
+};
+
+/*
+ * cpu0 has different OPPs depending on SoC revision and some on revisions
+ * 0x2 and 0x4 have eFuse bits that indicate if they are available or not
+ */
+cpu0_opp_table: opp_table0 {
+ compatible = "operating-points-v2-ti-cpu";
+ syscon = <&scm_conf>;
+
+ /*
+ * The three following nodes are marked with opp-suspend
+ * because they can not be enabled simultaneously on a
+ * single SoC.
+ */
+ opp50 at 300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ opp-microvolt = <950000 931000 969000>;
+ opp-supported-hw = <0x06 0x0010>;
+ opp-suspend;
+ };
+
+ opp100 at 275000000 {
+ opp-hz = /bits/ 64 <275000000>;
+ opp-microvolt = <1100000 1078000 1122000>;
+ opp-supported-hw = <0x01 0x00FF>;
+ opp-suspend;
+ };
+
+ opp100 at 300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ opp-microvolt = <1100000 1078000 1122000>;
+ opp-supported-hw = <0x06 0x0020>;
+ opp-suspend;
+ };
+
+ opp100 at 500000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ opp-microvolt = <1100000 1078000 1122000>;
+ opp-supported-hw = <0x01 0xFFFF>;
+ };
+
+ opp100 at 600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ opp-microvolt = <1100000 1078000 1122000>;
+ opp-supported-hw = <0x06 0x0040>;
+ };
+
+ opp120 at 600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ opp-microvolt = <1200000 1176000 1224000>;
+ opp-supported-hw = <0x01 0xFFFF>;
+ };
+
+ opp120 at 720000000 {
+ opp-hz = /bits/ 64 <720000000>;
+ opp-microvolt = <1200000 1176000 1224000>;
+ opp-supported-hw = <0x06 0x0080>;
+ };
+
+ oppturbo at 720000000 {
+ opp-hz = /bits/ 64 <720000000>;
+ opp-microvolt = <1260000 1234800 1285200>;
+ opp-supported-hw = <0x01 0xFFFF>;
+ };
+
+ oppturbo at 800000000 {
+ opp-hz = /bits/ 64 <800000000>;
+ opp-microvolt = <1260000 1234800 1285200>;
+ opp-supported-hw = <0x06 0x0100>;
+ };
+
+ oppnitro at 1000000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ opp-microvolt = <1325000 1298500 1351500>;
+ opp-supported-hw = <0x04 0x0200>;
+ };
+};
--
2.11.0
^ permalink raw reply related
* [PATCH v4 1/4] PM / OPP: Expose _of_get_opp_desc_node as dev_pm_opp API
From: Dave Gerlach @ 2017-01-17 13:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117131808.29798-1-d-gerlach@ti.com>
Rename _of_get_opp_desc_node to dev_pm_opp_of_get_opp_desc_node and add it
to include/linux/pm_opp.h to allow other drivers, such as platform OPP
and cpufreq drivers, to make use of it.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
v3->v4:
Export dev_pm_opp_of_get_opp_desc_node for use in modules.
drivers/base/power/opp/of.c | 9 +++++----
include/linux/pm_opp.h | 6 ++++++
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/base/power/opp/of.c b/drivers/base/power/opp/of.c
index 3f7d2591b173..fe14d231f1db 100644
--- a/drivers/base/power/opp/of.c
+++ b/drivers/base/power/opp/of.c
@@ -243,7 +243,7 @@ void dev_pm_opp_of_remove_table(struct device *dev)
EXPORT_SYMBOL_GPL(dev_pm_opp_of_remove_table);
/* Returns opp descriptor node for a device, caller must do of_node_put() */
-static struct device_node *_of_get_opp_desc_node(struct device *dev)
+struct device_node *dev_pm_opp_of_get_opp_desc_node(struct device *dev)
{
/*
* TODO: Support for multiple OPP tables.
@@ -254,6 +254,7 @@ static struct device_node *_of_get_opp_desc_node(struct device *dev)
return of_parse_phandle(dev->of_node, "operating-points-v2", 0);
}
+EXPORT_SYMBOL_GPL(dev_pm_opp_of_get_opp_desc_node);
/**
* _opp_add_static_v2() - Allocate static OPPs (As per 'v2' DT bindings)
@@ -495,7 +496,7 @@ int dev_pm_opp_of_add_table(struct device *dev)
* OPPs have two version of bindings now. The older one is deprecated,
* try for the new binding first.
*/
- opp_np = _of_get_opp_desc_node(dev);
+ opp_np = dev_pm_opp_of_get_opp_desc_node(dev);
if (!opp_np) {
/*
* Try old-deprecated bindings for backward compatibility with
@@ -605,7 +606,7 @@ int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev,
int cpu, ret = 0;
/* Get OPP descriptor node */
- np = _of_get_opp_desc_node(cpu_dev);
+ np = dev_pm_opp_of_get_opp_desc_node(cpu_dev);
if (!np) {
dev_dbg(cpu_dev, "%s: Couldn't find opp node.\n", __func__);
return -ENOENT;
@@ -630,7 +631,7 @@ int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev,
}
/* Get OPP descriptor node */
- tmp_np = _of_get_opp_desc_node(tcpu_dev);
+ tmp_np = dev_pm_opp_of_get_opp_desc_node(tcpu_dev);
if (!tmp_np) {
dev_err(tcpu_dev, "%s: Couldn't find opp node.\n",
__func__);
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index 0edd88f93904..a5b1aaeae229 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -270,6 +270,7 @@ void dev_pm_opp_of_remove_table(struct device *dev);
int dev_pm_opp_of_cpumask_add_table(const struct cpumask *cpumask);
void dev_pm_opp_of_cpumask_remove_table(const struct cpumask *cpumask);
int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev, struct cpumask *cpumask);
+struct device_node *dev_pm_opp_of_get_opp_desc_node(struct device *dev);
#else
static inline int dev_pm_opp_of_add_table(struct device *dev)
{
@@ -293,6 +294,11 @@ static inline int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev, struct
{
return -ENOTSUPP;
}
+
+static inline struct device_node *dev_pm_opp_of_get_opp_desc_node(struct device *dev)
+{
+ return NULL;
+}
#endif
#endif /* __LINUX_OPP_H__ */
--
2.11.0
^ permalink raw reply related
* [PATCH v4 0/4] cpufreq: Introduce TI CPUFreq/OPP Driver
From: Dave Gerlach @ 2017-01-17 13:18 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This is v4 of the series to introduce the ti-cpufreq driver
which parses SoC data and provides opp-supported-hw data to the
OPP core in order to enable the proper OPPs for the silicon in use.
Based on v4.10-rc4.
History:
v3: http://www.spinics.net/lists/linux-omap/msg132733.html
v2: http://www.spinics.net/lists/linux-omap/msg131601.html
v1: http://www.spinics.net/lists/linux-omap/msg129089.html
This series has two changes from v3:
* Export dev_pm_opp_of_get_opp_desc_node for modules
* Simplify the dt binding by just providing a "syscon" phandle and
letting the driver handle offsets.
* Add a patch to remove the automatic platdev creation for am335x
and dra7 platforms as this driver will now do it. Note that this
will *not* break existing cpufreq implementations on these platforms
as the ti-cpufreq can fall back to opp v1 tables for backwards
compatibility.
DT patches to enable this driver will follow after the DT binding is merged.
Finally, branch for testing, with updated DT nodes, pushed here [1].
Regards,
Dave
[1] https://github.com/dgerlach/linux-pm/commits/upstream/ti-cpufreq-driver-new-v4
Dave Gerlach (4):
PM / OPP: Expose _of_get_opp_desc_node as dev_pm_opp API
Documentation: dt: add bindings for ti-cpufreq
cpufreq: ti: Add cpufreq driver to determine available OPPs at runtime
cpufreq: dt: Don't use generic platdev driver for ti-cpufreq platforms
.../devicetree/bindings/cpufreq/ti-cpufreq.txt | 128 ++++++++++
drivers/base/power/opp/of.c | 9 +-
drivers/cpufreq/Kconfig.arm | 11 +
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/cpufreq-dt-platdev.c | 2 -
drivers/cpufreq/ti-cpufreq.c | 272 +++++++++++++++++++++
include/linux/pm_opp.h | 6 +
7 files changed, 423 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
create mode 100644 drivers/cpufreq/ti-cpufreq.c
--
2.11.0
^ permalink raw reply
* [PATCH v2 2/3] spi: pxa2xx: Prepare for edge-triggered interrupts
From: Jarkko Nikula @ 2017-01-17 13:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bfebbcbc-3d02-137b-72c0-7664900fe279@siemens.com>
On 01/17/2017 10:10 AM, Jan Kiszka wrote:
> On 2017-01-17 08:58, Robert Jarzmik wrote:
>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>
>>> When using the a device with edge-triggered interrupts, such as MSIs,
>>> the interrupt handler has to ensure that there is a point in time during
>>> its execution where all interrupts sources are silent so that a new
>>> event can trigger a new interrupt again.
>>>
>>> This is achieved here by looping over SSSR evaluation. We need to take
>>> into account that SSCR1 may be changed by the transfer handler, thus we
>>> need to redo the mask calculation, at least regarding the volatile
>>> interrupt enable bit (TIE).
>>
>> I'd like moreover to add a question here.
>>
>> In pxa architecture, SPI interrupts are already edge-triggered, and it's working
>> well. The interrupt source disabling is not disabled, but the interrupt
>> controller doesn't trigger an interrupt anymore (as it is masked), yet it marks
>> it as pending if an interrupt arrives while the interrupt handler is running.
>>
>> All of this is handled by the interrupt core. My question is why for Intel MSI's
>> is it necessary to make a change in the driver instead or relying on the
>> interrupt core as for the pxa ?
>
> If someone was using this driver with edge-triggered interrupt sources
> so far, it was probably slower hardware and some luck (I've seen this
> when driving fast-clocked devices vs. slower ones - only the latter
> exposed the bug). Or that hardware did some temporary masking at
> interrupt controller level while the handler was running. But that is
> also not by design. It's the driver's task to ensure that all interrupt
> sources are addressed once when returning from an edge-triggered
> handler, and that is missing in this one.
>
Are you seeing actual problem here or adding loop just in case? Is it
really so that PCI bridge doesn't generate another MSI interrupt if SPI
controller has interrupt pending when handler returns? I don't know but
I would expect irq line between SPI controller and PCI bridge is still
level sensitive even PCI bridge issues MSIs to the CPU.
--
Jarkko
^ permalink raw reply
* [PATCH 1/2] power/reset: at91-reset: add samx7 support
From: Alexandre Belloni @ 2017-01-17 12:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160922225322.31677-1-alexandre.belloni@free-electrons.com>
Hi Sebastian,
Did you have any comment on those two patches ?
On 23/09/2016 at 00:53:21 +0200, Alexandre Belloni wrote :
> From: Szemz? Andr?s <sza@esh.hu>
>
> Add samx7 support. It is lacking a few bits and needs a new reset function.
>
> Signed-off-by: Szemz? Andr?s <sza@esh.hu>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> ---
> drivers/power/reset/at91-reset.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/power/reset/at91-reset.c b/drivers/power/reset/at91-reset.c
> index 1b5d450586d1..563722e64d7b 100644
> --- a/drivers/power/reset/at91-reset.c
> +++ b/drivers/power/reset/at91-reset.c
> @@ -134,6 +134,15 @@ static int sama5d3_restart(struct notifier_block *this, unsigned long mode,
> return NOTIFY_DONE;
> }
>
> +static int samx7_restart(struct notifier_block *this, unsigned long mode,
> + void *cmd)
> +{
> + writel(cpu_to_le32(AT91_RSTC_KEY | AT91_RSTC_PROCRST),
> + at91_rstc_base);
> +
> + return NOTIFY_DONE;
> +}
> +
> static void __init at91_reset_status(struct platform_device *pdev)
> {
> u32 reg = readl(at91_rstc_base + AT91_RSTC_SR);
> @@ -173,6 +182,7 @@ static const struct of_device_id at91_reset_of_match[] = {
> { .compatible = "atmel,at91sam9260-rstc", .data = at91sam9260_restart },
> { .compatible = "atmel,at91sam9g45-rstc", .data = at91sam9g45_restart },
> { .compatible = "atmel,sama5d3-rstc", .data = sama5d3_restart },
> + { .compatible = "atmel,samx7-rstc", .data = samx7_restart },
> { /* sentinel */ }
> };
>
> --
> 2.9.3
>
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] ARM: davinci: da850-evm: fix read access to SPI flash
From: Fabien Parent @ 2017-01-17 12:57 UTC (permalink / raw)
To: linux-arm-kernel
Read access to the SPI flash are broken on da850-evm, i.e. the data
read is not what is actually programmed on the flash.
According to the datasheet for the M25P64 part present on the da850-evm,
if the SPI frequency is higher than 20MHz then the READ command is not
usable anymore and only the FAST_READ command can be used to read data.
This commit specifies in the DTS that we should use FAST_READ command
instead of the READ command.
Signed-off-by: Fabien Parent <fparent@baylibre.com>
---
arch/arm/boot/dts/da850-evm.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 41de15fe15a2..78492a0bbbab 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -99,6 +99,7 @@
#size-cells = <1>;
compatible = "m25p64";
spi-max-frequency = <30000000>;
+ m25p,fast-read;
reg = <0>;
partition at 0 {
label = "U-Boot-SPL";
--
2.11.0
^ permalink raw reply related
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