* [PATCH v3 6/6] tty/serial: atmel: changed the driver to work under at91-usart mfd
From: Radu Pirea @ 2018-05-15 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4a75568e-a52e-3872-f465-d707372a5c12@sorico.fr>
On Mon, 2018-05-14 at 12:57 +0200, Richard Genoud wrote:
> Hi,
>
> On 11/05/2018 12:38, Radu Pirea wrote:
> > This patch modifies the place where resources and device tree
> > properties
> > are searched.
> >
> > Signed-off-by: Radu Pirea <radu.pirea@microchip.com>
> > ---
> > drivers/tty/serial/Kconfig | 1 +
> > drivers/tty/serial/atmel_serial.c | 29 +++++++++++++++----------
> > ----
> > 2 files changed, 16 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/tty/serial/Kconfig
> > b/drivers/tty/serial/Kconfig
> > index 3682fd3e960c..25e55332f8b1 100644
> > --- a/drivers/tty/serial/Kconfig
> > +++ b/drivers/tty/serial/Kconfig
> > @@ -119,6 +119,7 @@ config SERIAL_ATMEL
> > depends on ARCH_AT91 || COMPILE_TEST
> > select SERIAL_CORE
> > select SERIAL_MCTRL_GPIO if GPIOLIB
> > + select MFD_AT91_USART
> > help
> > This enables the driver for the on-chip UARTs of the
> > Atmel
> > AT91 processors.
> > diff --git a/drivers/tty/serial/atmel_serial.c
> > b/drivers/tty/serial/atmel_serial.c
> > index df46a9e88c34..6b4494352853 100644
> > --- a/drivers/tty/serial/atmel_serial.c
> > +++ b/drivers/tty/serial/atmel_serial.c
> > @@ -193,8 +193,8 @@ static struct console atmel_console;
> >
> > #if defined(CONFIG_OF)
> > static const struct of_device_id atmel_serial_dt_ids[] = {
> > - { .compatible = "atmel,at91rm9200-usart" },
> > - { .compatible = "atmel,at91sam9260-usart" },
> > + { .compatible = "atmel,at91rm9200-usart-serial" },
> > + { .compatible = "atmel,at91sam9260-usart-serial" },
> > { /* sentinel */ }
> > };
> > #endif
> > @@ -1631,7 +1631,7 @@ static void atmel_tasklet_tx_func(unsigned
> > long data)
> > static void atmel_init_property(struct atmel_uart_port
> > *atmel_port,
> > struct platform_device *pdev)
> > {
> > - struct device_node *np = pdev->dev.of_node;
> > + struct device_node *np = pdev->dev.parent->of_node;
> >
> > /* DMA/PDC usage specification */
> > if (of_property_read_bool(np, "atmel,use-dma-rx")) {
> > @@ -2223,7 +2223,8 @@ static const char *atmel_type(struct
> > uart_port *port)
> > static void atmel_release_port(struct uart_port *port)
> > {
> > struct platform_device *pdev = to_platform_device(port-
> > >dev);
> > - int size = pdev->resource[0].end - pdev->resource[0].start
> > + 1;
> > + int size = to_platform_device(pdev->dev.parent)-
> > >resource[0].end -
> > + to_platform_device(pdev->dev.parent)-
> > >resource[0].start + 1;
>
> I think it may be simpler with something like:
> + struct platform_device *mfd_pdev = to_platform_device(port-
> >dev->parent);
> + int size = mfd_pdev->resource[0].end - mfd_pdev-
> >resource[0].start + 1;
>
> >
> > release_mem_region(port->mapbase, size);
> >
> > @@ -2239,7 +2240,8 @@ static void atmel_release_port(struct
> > uart_port *port)
> > static int atmel_request_port(struct uart_port *port)
> > {
> > struct platform_device *pdev = to_platform_device(port-
> > >dev);
> > - int size = pdev->resource[0].end - pdev->resource[0].start
> > + 1;
> > + int size = to_platform_device(pdev->dev.parent)-
> > >resource[0].end -
> > + to_platform_device(pdev->dev.parent)-
> > >resource[0].start + 1;
> >
>
> ditto
>
> > if (!request_mem_region(port->mapbase, size,
> > "atmel_serial"))
> > return -EBUSY;
> > @@ -2345,23 +2347,23 @@ static int atmel_init_port(struct
> > atmel_uart_port *atmel_port,
>
> Here, we could also add:
> + struct device *mfd_dev = pdev->dev.parent;
> + struct platform_device *mfd_pdev =
> to_platform_device(mfd_dev);
>
> > atmel_init_property(atmel_port, pdev);
> > atmel_set_ops(port);
> >
> > - uart_get_rs485_mode(&pdev->dev, &port->rs485);
> > + uart_get_rs485_mode(pdev->dev.parent, &port->rs485);
>
> ...and use them here
>
> >
> > port->iotype = UPIO_MEM;
> > port->flags = UPF_BOOT_AUTOCONF |
> > UPF_IOREMAP;
> > port->ops = &atmel_pops;
> > port->fifosize = 1;
> > port->dev = &pdev->dev;
> > - port->mapbase = pdev->resource[0].start;
> > - port->irq = pdev->resource[1].start;
> > + port->mapbase = to_platform_device(pdev-
> > >dev.parent)->resource[0].start;
> > + port->irq = to_platform_device(pdev-
> > >dev.parent)->resource[1].start;
>
> and here
> I think it would be easier to read.
>
> > port->rs485_config = atmel_config_rs485;
> > - port->membase = NULL;
> > + port->membase = NULL;
> >
> > memset(&atmel_port->rx_ring, 0, sizeof(atmel_port-
> > >rx_ring));
> >
> > /* for console, the clock could already be configured */
> > if (!atmel_port->clk) {
> > - atmel_port->clk = clk_get(&pdev->dev, "usart");
> > + atmel_port->clk = clk_get(pdev->dev.parent,
> > "usart");
>
> and here
>
> > if (IS_ERR(atmel_port->clk)) {
> > ret = PTR_ERR(atmel_port->clk);
> > atmel_port->clk = NULL;
> > @@ -2656,7 +2658,7 @@ static void atmel_serial_probe_fifos(struct
> > atmel_uart_port *atmel_port,
> > atmel_port->rts_low = 0;
> > atmel_port->rts_high = 0;
> >
> > - if (of_property_read_u32(pdev->dev.of_node,
> > + if (of_property_read_u32(pdev->dev.parent->of_node,
> > "atmel,fifo-size",
> > &atmel_port->fifo_size))
> > return;
> > @@ -2694,11 +2696,10 @@ static void atmel_serial_probe_fifos(struct
> > atmel_uart_port *atmel_port,
> > static int atmel_serial_probe(struct platform_device *pdev)
> > {
> > struct atmel_uart_port *atmel_port;
> > - struct device_node *np = pdev->dev.of_node;
> > + struct device_node *np = pdev->dev.parent->of_node;
> > void *data;
> > int ret = -ENODEV;
> > bool rs485_enabled;
> > -
>
> I think this line feed wasn't so bad.
>
> > BUILD_BUG_ON(ATMEL_SERIAL_RINGSIZE &
> > (ATMEL_SERIAL_RINGSIZE - 1));
> >
> > ret = of_alias_get_id(np, "serial");
> > @@ -2845,7 +2846,7 @@ static struct platform_driver
> > atmel_serial_driver = {
> > .suspend = atmel_serial_suspend,
> > .resume = atmel_serial_resume,
> > .driver = {
> > - .name = "atmel_usart",
> > + .name =
> > "atmel_usart_serial",
> > .of_match_table =
> > of_match_ptr(atmel_serial_dt_ids),
> > },
> > };
> >
>
> After your patch, the DMA is not selected anymore:
> atmel_usart_serial atmel_usart_serial.0.auto: TX channel not
> available, switch to pio
> instead of:
> atmel_usart fffff200.serial: using dma1chan2 for tx DMA transfers
>
Fixed.
> And the kernel doesn't log anymore on the serial console, despite the
> loglevel=8
> (after reverting this series, the kernel logs reappears on the serial
> console)
>
Which serial are you using as console?
> (tests done on sam9g35)
>
I will consider the rest of suggestions.
> regards,
> Richard
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180515/f865516c/attachment.sig>
^ permalink raw reply
* [PATCH 5/6] hwspinlock/u8500: Switch to SPDX license identifier
From: Linus Walleij @ 2018-05-15 12:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511170321.2452-6-s-anna@ti.com>
On Fri, May 11, 2018 at 7:03 PM, Suman Anna <s-anna@ti.com> wrote:
> Use the appropriate SPDX license identifier in the U8500 HWSEM
> driver source file and drop the previous boilerplate license text.
>
> Cc: Mathieu J. Poirier <mathieu.poirier@linaro.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] KVM: arm/arm64: fix unaligned hva start and end in handle_hva_to_gpa
From: Jia He @ 2018-05-15 12:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <14954b3a-6a2a-fe05-47b7-1890375ab8a4@arm.com>
Hi Suzuki
On 5/15/2018 4:36 PM, Suzuki K Poulose Wrote:
>
> Hi Jia
>
> On 05/15/2018 03:03 AM, Jia He wrote:
>> Hi Suzuki
>>
>> I will merge the other thread into this, and add the necessary CC list
>>
>> That WARN_ON call trace is very easy to reproduce in my armv8a server after I
>> start 20 guests
>>
>> and run memhog in the host. Of course, ksm should be enabled
>>
>> For you question about my inject fault debug patch:
>
>
> Thanks for the patch, comments below.
>
>>
>
> ...
>
>> index 7f6a944..ab8545e 100644
>> --- a/virt/kvm/arm/mmu.c
>> +++ b/virt/kvm/arm/mmu.c
>> @@ -290,12 +290,17 @@ static void unmap_stage2_puds(struct kvm *kvm, pgd_t *pgd,
>> ?? * destroying the VM), otherwise another faulting VCPU may come in and mess
>> ?? * with things behind our backs.
>> ?? */
>> +extern int trigger_by_ksm;
>> ??static void unmap_stage2_range(struct kvm *kvm, phys_addr_t start, u64 size)
>> ??{
>> ???????? pgd_t *pgd;
>> ???????? phys_addr_t addr = start, end = start + size;
>> ???????? phys_addr_t next;
>>
>> +?????? if(trigger_by_ksm) {
>> +?????????????? end -= 0x200;
>> +?????? }
>> +
>> ???????? assert_spin_locked(&kvm->mmu_lock);
>> ???????? pgd = kvm->arch.pgd + stage2_pgd_index(addr);
>> ???????? do {
>>
>> I need to point out that I never reproduced it without this debugging patch.
>
> That could trigger the panic iff your "size" <= 0x200, leading to the
> condition (end < start), which can make the loop go forever, as we
> do while(addr < end) and end up accessing something which may not be PGD entry
> and thus get a bad page with bad numbers all around. This case could be hit only
> with your change and the bug in the KSM which gives us an address near the page
> boundary.
No, I injected the fault on purpose to simulate the case when size is less than
PAGE_SIZE(eg. PAGE_SIZE-0x200=65024)
I ever got the panic info [1] *without* the debugging patch only once
[1] https://lkml.org/lkml/2018/5/9/992
>
> So, I think we can safely ignore the PANIC().
> More below.
>
>
>>>> Suzuki, thanks for the comments.
>>>>
>>>> I proposed another ksm patch https://lkml.org/lkml/2018/5/3/1042
>>>> The root cause is ksm will add some extra flags to indicate that the page
>>>> is in/not_in the stable tree. This makes address not be aligned with PAGE_SIZE.
>>> Thanks for the pointer. In the future, please Cc the people relevant to the
>>> discussion in the patches.
>>>
>>>> ? From arm kvm mmu point of view, do you think handle_hva_to_gpa still need
>>>> to handle
>>>> the unalignment case?
>>> I don't think we should do that. Had we done this, we would never have caught
>>> this bug
>>> in KSM. Eventually if some other new implementation comes up with the a new
>>> notifier
>>> consumer which doesn't check alignment and doesn't WARN, it could simply do
>>> the wrong
>>> thing. So I believe what we have is a good measure to make sure that things are
>>> in the right order.
>>>
>>>> IMO, the PAGE_SIZE alignment is still needed because we should not let the
>>>> bottom function
>>>> kvm_age_hva_handler to handle the exception. Please refer to the
>>>> implementation in X86 and
>>>> powerpc kvm_handle_hva_range(). They both aligned the hva with
>>>> hva_to_gfn_memslot.
>>>>
>>> ? From an API perspective, you are passed on a "start" and "end" address. So,
>>> you could potentially
>>> do the wrong thing if you align the "start" and "end". May be those handlers
>>> should also do the
>>> same thing as we do.
>
>> But handle_hva_to_gpa has partially adjusted the alignment possibly:
>> ??? 1750???????? kvm_for_each_memslot(memslot, slots) {
>> ??? 1751???????????????? unsigned long hva_start, hva_end;
>> ??? 1752???????????????? gfn_t gpa;
>> ??? 1753
>> ??? 1754???????????????? hva_start = max(start, memslot->userspace_addr);
>> ??? 1755???????????????? hva_end = min(end, memslot->userspace_addr +
>> ??? 1756???????????????????????????? (memslot->npages << PAGE_SHIFT));
>>
>> at line 1755, let us assume that end=0x12340200 and
>> memslot->userspace_addr + (memslot->npages << PAGE_SHIFT)=0x12340000
>> Then, hva_start is not page_size aligned and hva_end is aligned, and the size
>> will be PAGE_SIZE-0x200,
>> just as what I had done in the inject fault debugging patch.
>
> Thats because we want to limit the handling of the hva/gpa range by memslot. So,
> we make sure we pass on the range within the given memslot
> to hva_to_gfn_memslot(). But we do iterate over the next memslot if the
> original range falls in to the next slot. So, in practice, there is no
> alignment/trimming of the range. Its just that we pass on the appropriate range
> for each slot.
>
Yes, I understand what the codes did in hva_to_gfn_memslot(). What I mean is
hva_end may be changed and (hva_end - hva_start) will not be same as the
parameter _size_ ?
>ret |= handler(kvm, gpa, (u64)(hva_end - hva_start), data);
Anyway, I have to admit that all the exceptions are originally caused by the
STABLE_FLAG in ksm code. What I want to discuss here is how to make arm kvm
handle the exception more gracefully.
--
Cheers,
Jia
^ permalink raw reply
* [PATCH] arm64: dts: exynos: fix type of thermal trip points for Exynos7
From: Bartlomiej Zolnierkiewicz @ 2018-05-15 12:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CGME20180515123755eucas1p278a9c1e9cb0101e406e3839e27f8b3b1@eucas1p2.samsung.com>
Currently Exynos thermal driver treats as "active" all specified
trip points before reaching maximum number of hardware supported
trip points. Moreover polling-delay-passive is specified as "0"
in exynos7.dtsi (IOW passive polling is disabled). Therefore fix
type of cpu-alert-0 to cpu-alert6 trip points to be "active"
instead of "passive" (cpu-alert-7 type is "critical" so it
doesn't need a fixup).
Cc: Alim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
---
arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
Index: b/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi
===================================================================
--- a/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi 2018-05-15 13:57:55.822172496 +0200
+++ b/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi 2018-05-15 14:23:12.594016481 +0200
@@ -10,37 +10,37 @@ trips {
cpu-alert-0 {
temperature = <75000>; /* millicelsius */
hysteresis = <10000>; /* millicelsius */
- type = "passive";
+ type = "active";
};
cpu-alert-1 {
temperature = <80000>; /* millicelsius */
hysteresis = <10000>; /* millicelsius */
- type = "passive";
+ type = "active";
};
cpu-alert-2 {
temperature = <85000>; /* millicelsius */
hysteresis = <10000>; /* millicelsius */
- type = "passive";
+ type = "active";
};
cpu-alert-3 {
temperature = <90000>; /* millicelsius */
hysteresis = <10000>; /* millicelsius */
- type = "passive";
+ type = "active";
};
cpu-alert-4 {
temperature = <95000>; /* millicelsius */
hysteresis = <10000>; /* millicelsius */
- type = "passive";
+ type = "active";
};
cpu-alert-5 {
temperature = <100000>; /* millicelsius */
hysteresis = <10000>; /* millicelsius */
- type = "passive";
+ type = "active";
};
cpu-alert-6 {
temperature = <110000>; /* millicelsius */
hysteresis = <10000>; /* millicelsius */
- type = "passive";
+ type = "active";
};
cpu-crit-0 {
temperature = <115000>; /* millicelsius */
^ permalink raw reply
* [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding
From: Gilad Ben-Yossef @ 2018-05-15 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526387370-17142-1-git-send-email-gilad@benyossef.com>
Add bindings for CryptoCell instance in the SoC.
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 91486b4..6c76841 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -528,6 +528,14 @@
status = "disabled";
};
+ arm_cc630p: crypto at e6601000 {
+ compatible = "arm,cryptocell-630p-ree";
+ interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
+ #interrupt-cells = <2>;
+ reg = <0x0 0xe6601000 0 0x1000>;
+ clocks = <&cpg CPG_MOD 229>;
+ };
+
i2c3: i2c at e66d0000 {
#address-cells = <1>;
#size-cells = <0>;
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] clk: renesas: r8a7795: Add ccree clock
From: Gilad Ben-Yossef @ 2018-05-15 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526387370-17142-1-git-send-email-gilad@benyossef.com>
This patch adds the clock used by the CryptoCell 630p instance in the SoC.
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
---
drivers/clk/renesas/r8a7795-cpg-mssr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/renesas/r8a7795-cpg-mssr.c b/drivers/clk/renesas/r8a7795-cpg-mssr.c
index 775b0ce..642706a 100644
--- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
@@ -132,6 +132,7 @@ static struct mssr_mod_clk r8a7795_mod_clks[] __initdata = {
DEF_MOD("sys-dmac2", 217, R8A7795_CLK_S0D3),
DEF_MOD("sys-dmac1", 218, R8A7795_CLK_S0D3),
DEF_MOD("sys-dmac0", 219, R8A7795_CLK_S0D3),
+ DEF_MOD("ccree", 229, R8A7795_CLK_S3D2),
DEF_MOD("cmt3", 300, R8A7795_CLK_R),
DEF_MOD("cmt2", 301, R8A7795_CLK_R),
DEF_MOD("cmt1", 302, R8A7795_CLK_R),
--
2.7.4
^ permalink raw reply related
* [PATCH 1/3] crypto: ccree: drop signature register check
From: Gilad Ben-Yossef @ 2018-05-15 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526387370-17142-1-git-send-email-gilad@benyossef.com>
We were using the content of the signature register as a sanity
check for the hardware functioning but it turns out not all
implementers use the same values so the check is giving false
negative on certain SoCs and so we drop it.
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
---
drivers/crypto/ccree/cc_driver.c | 18 +++---------------
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/drivers/crypto/ccree/cc_driver.c b/drivers/crypto/ccree/cc_driver.c
index 89ce013..f8ff358 100644
--- a/drivers/crypto/ccree/cc_driver.c
+++ b/drivers/crypto/ccree/cc_driver.c
@@ -38,21 +38,20 @@ MODULE_PARM_DESC(cc_dump_bytes, "Dump buffers to kernel log as debugging aid");
struct cc_hw_data {
char *name;
enum cc_hw_rev rev;
- u32 sig;
};
/* Hardware revisions defs. */
static const struct cc_hw_data cc712_hw = {
- .name = "712", .rev = CC_HW_REV_712, .sig = 0xDCC71200U
+ .name = "712", .rev = CC_HW_REV_712
};
static const struct cc_hw_data cc710_hw = {
- .name = "710", .rev = CC_HW_REV_710, .sig = 0xDCC63200U
+ .name = "710", .rev = CC_HW_REV_710
};
static const struct cc_hw_data cc630p_hw = {
- .name = "630P", .rev = CC_HW_REV_630, .sig = 0xDCC63000U
+ .name = "630P", .rev = CC_HW_REV_630
};
static const struct of_device_id arm_ccree_dev_of_match[] = {
@@ -186,7 +185,6 @@ static int init_cc_resources(struct platform_device *plat_dev)
struct cc_drvdata *new_drvdata;
struct device *dev = &plat_dev->dev;
struct device_node *np = dev->of_node;
- u32 signature_val;
u64 dma_mask;
const struct cc_hw_data *hw_rev;
const struct of_device_id *dev_id;
@@ -275,16 +273,6 @@ static int init_cc_resources(struct platform_device *plat_dev)
return rc;
}
- /* Verify correct mapping */
- signature_val = cc_ioread(new_drvdata, CC_REG(HOST_SIGNATURE));
- if (signature_val != hw_rev->sig) {
- dev_err(dev, "Invalid CC signature: SIGNATURE=0x%08X != expected=0x%08X\n",
- signature_val, hw_rev->sig);
- rc = -EINVAL;
- goto post_clk_err;
- }
- dev_dbg(dev, "CC SIGNATURE=0x%08X\n", signature_val);
-
/* Display HW versions */
dev_info(dev, "ARM CryptoCell %s Driver: HW version 0x%08X, Driver version %s\n",
hw_rev->name, cc_ioread(new_drvdata, CC_REG(HOST_VERSION)),
--
2.7.4
^ permalink raw reply related
* [PATCH 0/3] enable ccree on Renesas R-Car platform
From: Gilad Ben-Yossef @ 2018-05-15 12:29 UTC (permalink / raw)
To: linux-arm-kernel
The following patch set enables CryptoCell present in the Renesas
R-Car SoC.
Gilad Ben-Yossef (3):
crypto: ccree: drop signature register check
clk: renesas: r8a7795: Add ccree clock
arm64: dts: renesas: r8a7795: add ccree binding
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 8 ++++++++
drivers/clk/renesas/r8a7795-cpg-mssr.c | 1 +
drivers/crypto/ccree/cc_driver.c | 18 +++---------------
3 files changed, 12 insertions(+), 15 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 2/2] ARM: dts: stm32: m_can activation on stm32mp157c-ev1
From: Erwan Le Ray @ 2018-05-15 12:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526387039-14813-1-git-send-email-erwan.leray@st.com>
Add activation of the Controller Area Network m_can on stm32mp157c-ev1
board.
Signed-off-by: Bich Hemon <bich.hemon@st.com>
Signed-off-by: Erwan Le Ray <erwan.leray@st.com>
diff --git a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
index 88e9133..2e4c5e3 100644
--- a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
@@ -185,6 +185,19 @@
};
};
+ m_can1_pins_a: m_can1-0 {
+ pins1 {
+ pinmux = <STM32_PINMUX('H', 13, AF9)>; /* CAN1_TX */
+ slew-rate = <1>;
+ drive-push-pull;
+ bias-disable;
+ };
+ pins2 {
+ pinmux = <STM32_PINMUX('I', 9, AF9)>; /* CAN1_RX */
+ bias-disable;
+ };
+ };
+
pwm2_pins_a: pwm2-0 {
pins {
pinmux = <STM32_PINMUX('A', 3, AF1)>; /* TIM2_CH4 */
diff --git a/arch/arm/boot/dts/stm32mp157c-ev1.dts b/arch/arm/boot/dts/stm32mp157c-ev1.dts
index 9382d80..3be73d2 100644
--- a/arch/arm/boot/dts/stm32mp157c-ev1.dts
+++ b/arch/arm/boot/dts/stm32mp157c-ev1.dts
@@ -42,6 +42,12 @@
status = "okay";
};
+&m_can1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&m_can1_pins_a>;
+ status = "okay";
+};
+
&qspi {
pinctrl-names = "default";
pinctrl-0 = <&qspi_clk_pins_a &qspi_bk1_pins_a &qspi_bk2_pins_a>;
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: stm32: m_can support to stm32mp157c
From: Erwan Le Ray @ 2018-05-15 12:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526387039-14813-1-git-send-email-erwan.leray@st.com>
Add support for the Controller Area Network m_can to STM32MP157C SoC.
Signed-off-by: Bich Hemon <bich.hemon@st.com>
Signed-off-by: Erwan Le Ray <erwan.leray@st.com>
diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi b/arch/arm/boot/dts/stm32mp157c.dtsi
index b66f673..12ac73f 100644
--- a/arch/arm/boot/dts/stm32mp157c.dtsi
+++ b/arch/arm/boot/dts/stm32mp157c.dtsi
@@ -556,6 +556,32 @@
};
};
+ m_can1: can at 4400e000 {
+ compatible = "bosch,m_can";
+ reg = <0x4400e000 0x400>, <0x44011000 0x2800>;
+ reg-names = "m_can", "message_ram";
+ interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "int0", "int1";
+ clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
+ clock-names = "hclk", "cclk";
+ bosch,mram-cfg = <0x0 0 0 32 0 0 2 2>;
+ status = "disabled";
+ };
+
+ m_can2: can at 4400f000 {
+ compatible = "bosch,m_can";
+ reg = <0x4400f000 0x400>, <0x44011000 0x2800>;
+ reg-names = "m_can", "message_ram";
+ interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "int0", "int1";
+ clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
+ clock-names = "hclk", "cclk";
+ bosch,mram-cfg = <0x0 0 0 32 0 0 2 2>;
+ status = "disabled";
+ };
+
dma1: dma at 48000000 {
compatible = "st,stm32-dma";
reg = <0x48000000 0x400>;
--
1.9.1
^ permalink raw reply related
* [PATCH 0/2] m_can support to stm32mp157c
From: Erwan Le Ray @ 2018-05-15 12:23 UTC (permalink / raw)
To: linux-arm-kernel
Add support for the Controller Area Network m_can to STM32MP157C SoC and
activation on stm32mp157c-ev1 board
Bich Hemon (2):
ARM: dts: stm32: m_can support to stm32mp157c
ARM: dts: stm32: m_can activation on stm32mp157c-ev1
arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 13 +++++++++++++
arch/arm/boot/dts/stm32mp157c-ev1.dts | 6 ++++++
arch/arm/boot/dts/stm32mp157c.dtsi | 26 ++++++++++++++++++++++++++
3 files changed, 45 insertions(+)
--
1.9.1
^ permalink raw reply
* [PATCH 06/18] arm64: move sve_user_{enable, disable} to <asm/fpsimd.h>
From: Dave Martin @ 2018-05-15 12:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180515103936.v5ytofdq3qqtsomn@lakrids.cambridge.arm.com>
On Tue, May 15, 2018 at 11:39:36AM +0100, Mark Rutland wrote:
> On Mon, May 14, 2018 at 12:06:50PM +0100, Dave Martin wrote:
> > On Mon, May 14, 2018 at 10:46:28AM +0100, Mark Rutland wrote:
> > > In subsequent patches, we'll want to make use of sve_user_enable() and
> > > sve_user_disable() outside of kernel/fpsimd.c. Let's move these to
> > > <asm/fpsimd.h> where we can make use of them.
> > >
> > > To avoid ifdeffery in sequences like:
> > >
> > > if (system_supports_sve() && some_condition
> > > sve_user_disable();
> > >
> > > ... empty stubs are provided when support for SVE is not enabled.
> > >
> > > Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > > Cc: Dave Martin <dave.martin@arm.com>
> > > Cc: Will Deacon <will.deacon@arm.com>
> > > ---
> > > arch/arm64/include/asm/fpsimd.h | 17 ++++++++++++++++-
> > > arch/arm64/kernel/fpsimd.c | 11 -----------
> > > 2 files changed, 16 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h
> > > index aa7162ae93e3..7377d7593c06 100644
> > > --- a/arch/arm64/include/asm/fpsimd.h
> > > +++ b/arch/arm64/include/asm/fpsimd.h
> > > @@ -16,11 +16,13 @@
> > > #ifndef __ASM_FP_H
> > > #define __ASM_FP_H
> > >
> > > -#include <asm/ptrace.h>
> > > #include <asm/errno.h>
> > > +#include <asm/ptrace.h>
> > > +#include <asm/sysreg.h>
> > >
> > > #ifndef __ASSEMBLY__
> > >
> > > +#include <linux/build_bug.h>
> > > #include <linux/cache.h>
> > > #include <linux/init.h>
> > > #include <linux/stddef.h>
> > > @@ -81,6 +83,16 @@ extern int sve_set_vector_length(struct task_struct *task,
> > > extern int sve_set_current_vl(unsigned long arg);
> > > extern int sve_get_current_vl(void);
> > >
> > > +static inline void sve_user_disable(void)
> > > +{
> > > + sysreg_clear_set(cpacr_el1, CPACR_EL1_ZEN_EL0EN, 0);
> > > +}
> > > +
> > > +static inline void sve_user_enable(void)
> > > +{
> > > + sysreg_clear_set(cpacr_el1, 0, CPACR_EL1_ZEN_EL0EN);
> > > +}
> > > +
> > > /*
> > > * Probing and setup functions.
> > > * Calls to these functions must be serialised with one another.
> > > @@ -107,6 +119,9 @@ static inline int sve_get_current_vl(void)
> > > return -EINVAL;
> > > }
> > >
> > > +static inline void sve_user_disable(void) { }
> > > +static inline void sve_user_enable(void) { }
> > > +
> >
> > Alternatively, just move the full definitions outside the #ifdef
> > CONFIG_ARM64_SVE.
>
> Can do, though I was trying to keep the exsting pattern with empty
> inlines for the !CONFIG_ARM64_SVE case.
There isn't really a pattern. I tried to avoid dummy versions where
there's no real reason to have them. I don't _think_ they're really
needed here, unless I missed something. Did you get build failures
without them?
> > All calls to these should be shadowed by an if
> > (system_supports_sve()) in any case, and setting/clearing ZEN_EL0EN
> > in the CPACR_EL1 ought to be harmless now that the meaning of these
> > bits architecturally committed.
> >
> > Ideally we would have a BUG_ON(!system_supports_sve()) in those
> > functions, but we won't won't to pay the cost in a production kernel.
>
> Earlier I'd put BUILD_BUG() in the body for the !CONFIG_ARM64_SVE case,
> to catch that kind of thing -- I could restore that.
IIUC:
if (0) {
BUILD_BUG_ON(1);
}
can still fire, in which case it's futile checking for CONFIG_ARM64_SVE
in most of the SVE support code.
Anyway, CONFIG_ARM64_SVE doesn't capture the whole condition.
>
> > > static inline void sve_init_vq_map(void) { }
> > > static inline void sve_update_vq_map(void) { }
> > > static inline int sve_verify_vq_map(void) { return 0; }
> > > diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> > > index 088940387a4d..79a81c7d85c6 100644
> > > --- a/arch/arm64/kernel/fpsimd.c
> > > +++ b/arch/arm64/kernel/fpsimd.c
> > > @@ -159,7 +159,6 @@ static void sve_free(struct task_struct *task)
> > > __sve_free(task);
> > > }
> > >
> > > -
> >
> > Hmmm, Ack. Check for conflicts with the KVM FPSIMD rework [1] (though
> > trivial).
>
> I'll assume that Ack stands regardless. :)
Actually, I was just commenting on the deleted blank line... not that
there is any massive issue with this patch, though.
Cheers
---Dave
^ permalink raw reply
* [PATCH 0/4] KVM: arm/arm64: Fix locking issues
From: Paolo Bonzini @ 2018-05-15 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b8aae9d6-1413-157d-52c2-e06511975e11@arm.com>
On 15/05/2018 13:54, Marc Zyngier wrote:
> On 15/05/18 12:35, Paolo Bonzini wrote:
>> On 15/05/2018 12:26, Christoffer Dall wrote:
>>> On Fri, May 11, 2018 at 03:20:11PM +0100, Andre Przywara wrote:
>>>> Jan recently reported lockdep complaints regarding various locks in our
>>>> VGIC emulation [1][2].
>>>> This boiled down to two separate issues:
>>>> - When promoting the vgic_irq->irq_lock to require IRQs being disabled,
>>>> we forgot to amend some instances of this lock on the way. Also this
>>>> needs to be applied to dependent locks as well. The first two patches
>>>> fix that. The patch split is designed to simplify backporting.
>>>> Those patches have been posted before, I am resending them as part
>>>> of this series.
>>>> - Calling kvm_read_guest() requires us to be inside an SRCU critical
>>>> section. On some architectures we are always in it when handling VCPU
>>>> exits, but on ARM we need to lock it individually. Patches 3 and 4
>>>> fix that, the split is again made to ease backporting.
>>>> Each of the hunks fix an indiviual commit, but I refrained from
>>>> splitting this down into eight patches just to put proper Fixes: tags
>>>> on it. Eventually those commits are part of one out of two series, I put
>>>> the respective kernel release version as a tag to the Cc: stable line.
>>>>
>>>> I couldn't reproduce the full lockdep splat on my setup, but at least
>>>> could show one instance and prove that these patches fixes that.
>>>>
>>>>
>>> For the series:
>>>
>>> Acked-by: Christoffer Dall <christoffer.dall@arm.com>
>>
>> Shall I put the patches on their route to Linus?
> If you're about to send something, yes please (saves me having to send
> you a pull request). In that case, please add my
Yes, I do - and I was keeping my eyes on this series anyway.
Thanks,
Paolo
> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
>
> to the whole series.
>
> Thanks,
>
> M.
>
^ permalink raw reply
* [PATCH 0/4] KVM: arm/arm64: Fix locking issues
From: Marc Zyngier @ 2018-05-15 11:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <da25660f-7d57-34be-fe99-f42c10d81845@redhat.com>
On 15/05/18 12:35, Paolo Bonzini wrote:
> On 15/05/2018 12:26, Christoffer Dall wrote:
>> On Fri, May 11, 2018 at 03:20:11PM +0100, Andre Przywara wrote:
>>> Jan recently reported lockdep complaints regarding various locks in our
>>> VGIC emulation [1][2].
>>> This boiled down to two separate issues:
>>> - When promoting the vgic_irq->irq_lock to require IRQs being disabled,
>>> we forgot to amend some instances of this lock on the way. Also this
>>> needs to be applied to dependent locks as well. The first two patches
>>> fix that. The patch split is designed to simplify backporting.
>>> Those patches have been posted before, I am resending them as part
>>> of this series.
>>> - Calling kvm_read_guest() requires us to be inside an SRCU critical
>>> section. On some architectures we are always in it when handling VCPU
>>> exits, but on ARM we need to lock it individually. Patches 3 and 4
>>> fix that, the split is again made to ease backporting.
>>> Each of the hunks fix an indiviual commit, but I refrained from
>>> splitting this down into eight patches just to put proper Fixes: tags
>>> on it. Eventually those commits are part of one out of two series, I put
>>> the respective kernel release version as a tag to the Cc: stable line.
>>>
>>> I couldn't reproduce the full lockdep splat on my setup, but at least
>>> could show one instance and prove that these patches fixes that.
>>>
>>>
>> For the series:
>>
>> Acked-by: Christoffer Dall <christoffer.dall@arm.com>
>
> Shall I put the patches on their route to Linus?
If you're about to send something, yes please (saves me having to send
you a pull request). In that case, please add my
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
to the whole series.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* Potential deadlock in vgic
From: Jan Glauber @ 2018-05-15 11:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c243af13-a9c3-6808-6937-f1b882ce7a58@arm.com>
On Fri, May 11, 2018 at 03:29:43PM +0100, Andre Przywara wrote:
> Hi Jan,
>
> On 04/05/18 17:31, Jan Glauber wrote:
> > On Fri, May 04, 2018 at 04:17:40PM +0100, Andre Przywara wrote:
> >> Hi Jan,
> >>
> >> can you please test this patch with your setup, to see if it still
> >> screams? That converts two forgotten irq_lock's over to be irqsafe,
> >> plus lets lpi_list_lock join them (which you already did, IIUC).
> >> That should appease lockdep, hopefully.
> >
> > Hit send too soon, on halting the guest I get:
>
> So I managed to finally wrap my head around this one.
> I sent out a series [1], and failed Cc:ing you under the assumption that
> Reported-by: would be picked up by git send-email. Apologies for that,
> but you should be able to pick it from one of the lists.
>
> Can you please confirm that the last two patches fix the splat below for
> you?
Sorry for the late response, I was offline. With all 4 patches applied
both the locking and the RCU warnings are gone.
Thanks for fixing this!
Gr??e,
Jan
> Thanks for testing and reporting!
> Andre.
>
> [1]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2018-May/577054.html
>
> >
> > [ 1025.694857] =============================
> > [ 1025.694862] WARNING: suspicious RCU usage
> > [ 1025.694868] 4.17.0-rc3-jang+ #73 Not tainted
> > [ 1025.694873] -----------------------------
> > [ 1025.694880] ./include/linux/kvm_host.h:575 suspicious rcu_dereference_check() usage!
> > [ 1025.694884]
> > other info that might help us debug this:
> >
> > [ 1025.694890]
> > rcu_scheduler_active = 2, debug_locks = 1
> > [ 1025.694896] 18 locks held by qemu-system-aar/5540:
> > [ 1025.694901] #0: 000000005e03488a (&kvm->lock){+.+.}, at: vgic_its_set_attr+0x230/0x388
> > [ 1025.694937] #1: 000000004b1a3bb5 (&its->its_lock){+.+.}, at: vgic_its_set_attr+0x23c/0x388
> > [ 1025.694965] #2: 000000003ca8213c (&vcpu->mutex){+.+.}, at: lock_all_vcpus+0x64/0xc0
> > [ 1025.694993] #3: 00000000adb6ae51 (&vcpu->mutex){+.+.}, at: lock_all_vcpus+0x64/0xc0
> > [ 1025.695021] #4: 0000000000563df7 (&vcpu->mutex){+.+.}, at: lock_all_vcpus+0x64/0xc0
> > [ 1025.695048] #5: 00000000da16277a (&vcpu->mutex){+.+.}, at: lock_all_vcpus+0x64/0xc0
> > [ 1025.695076] #6: 00000000bf36d9aa (&vcpu->mutex){+.+.}, at: lock_all_vcpus+0x64/0xc0
> > [ 1025.695103] #7: 00000000607eaa4f (&vcpu->mutex){+.+.}, at: lock_all_vcpus+0x64/0xc0
> > [ 1025.695130] #8: 0000000046dadf65 (&vcpu->mutex){+.+.}, at: lock_all_vcpus+0x64/0xc0
> > [ 1025.695157] #9: 00000000197747b2 (&vcpu->mutex){+.+.}, at: lock_all_vcpus+0x64/0xc0
> > [ 1025.695184] #10: 00000000e4f1282c (&vcpu->mutex){+.+.}, at: lock_all_vcpus+0x64/0xc0
> > [ 1025.695211] #11: 000000007471b896 (&vcpu->mutex){+.+.}, at: lock_all_vcpus+0x64/0xc0
> > [ 1025.695239] #12: 000000005be54486 (&vcpu->mutex){+.+.}, at: lock_all_vcpus+0x64/0xc0
> > [ 1025.695266] #13: 000000000f1fa184 (&vcpu->mutex){+.+.}, at: lock_all_vcpus+0x64/0xc0
> > [ 1025.695293] #14: 0000000093fdb28b (&vcpu->mutex){+.+.}, at: lock_all_vcpus+0x64/0xc0
> > [ 1025.695396] #15: 0000000097cc103c (&vcpu->mutex){+.+.}, at: lock_all_vcpus+0x64/0xc0
> > [ 1025.695426] #16: 00000000d24dd32e (&vcpu->mutex){+.+.}, at: lock_all_vcpus+0x64/0xc0
> > [ 1025.695453] #17: 000000002606c3a7 (&vcpu->mutex){+.+.}, at: lock_all_vcpus+0x64/0xc0
> > [ 1025.695482]
> > stack backtrace:
> > [ 1025.695489] CPU: 29 PID: 5540 Comm: qemu-system-aar Not tainted 4.17.0-rc3-jang+ #73
> > [ 1025.695494] Hardware name: To be filled by O.E.M. Saber/To be filled by O.E.M., BIOS 0ACKL018 03/30/2018
> > [ 1025.695499] Call trace:
> > [ 1025.695505] dump_backtrace+0x0/0x160
> > [ 1025.695510] show_stack+0x24/0x30
> > [ 1025.695517] dump_stack+0x9c/0xd4
> > [ 1025.695524] lockdep_rcu_suspicious+0xcc/0x118
> > [ 1025.695537] gfn_to_memslot+0x174/0x190
> > [ 1025.695546] kvm_read_guest+0x50/0xb0
> > [ 1025.695553] vgic_its_check_id.isra.0+0x114/0x148
> > [ 1025.695560] vgic_its_save_tables_v0+0x1a0/0x320
> > [ 1025.695567] vgic_its_set_attr+0x330/0x388
> > [ 1025.695573] kvm_device_ioctl_attr+0x9c/0xd8
> > [ 1025.695579] kvm_device_ioctl+0x8c/0xf8
> > [ 1025.695587] do_vfs_ioctl+0xc4/0x938
> > [ 1025.695594] ksys_ioctl+0x8c/0x98
> > [ 1025.695601] sys_ioctl+0x34/0x48
> > [ 1025.695609] el0_svc_naked+0x44/0x48
> >
> > --Jan
> >
^ permalink raw reply
* [PATCH v2] PM / AVS: rockchip-io: add io selectors and supplies for PX30
From: Heiko Stuebner @ 2018-05-15 11:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526384899-11644-1-git-send-email-david.wu@rock-chips.com>
Hi David,
Am Dienstag, 15. Mai 2018, 13:48:19 CEST schrieb David Wu:
> This adds the necessary data for handling io voltage domains on PX30.
> As interesting tidbit, the PX30 contains two separate iodomain areas.
> One in the regular General Register Files (GRF) and one in PMUGRF in the
> pmu power domain.
>
> Signed-off-by: David Wu <david.wu@rock-chips.com>
thanks for the fast respin, looks great now.
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* [PATCH v2] PM / AVS: rockchip-io: add io selectors and supplies for PX30
From: David Wu @ 2018-05-15 11:48 UTC (permalink / raw)
To: linux-arm-kernel
This adds the necessary data for handling io voltage domains on PX30.
As interesting tidbit, the PX30 contains two separate iodomain areas.
One in the regular General Register Files (GRF) and one in PMUGRF in the
pmu power domain.
Signed-off-by: David Wu <david.wu@rock-chips.com>
---
.../bindings/power/rockchip-io-domain.txt | 15 +++++
drivers/power/avs/rockchip-io-domain.c | 68 ++++++++++++++++++++++
2 files changed, 83 insertions(+)
diff --git a/Documentation/devicetree/bindings/power/rockchip-io-domain.txt b/Documentation/devicetree/bindings/power/rockchip-io-domain.txt
index 4a4766e..e66fd4e 100644
--- a/Documentation/devicetree/bindings/power/rockchip-io-domain.txt
+++ b/Documentation/devicetree/bindings/power/rockchip-io-domain.txt
@@ -31,6 +31,8 @@ SoC is on the same page.
Required properties:
- compatible: should be one of:
+ - "rockchip,px30-io-voltage-domain" for px30
+ - "rockchip,px30-pmu-io-voltage-domain" for px30 pmu-domains
- "rockchip,rk3188-io-voltage-domain" for rk3188
- "rockchip,rk3228-io-voltage-domain" for rk3228
- "rockchip,rk3288-io-voltage-domain" for rk3288
@@ -51,6 +53,19 @@ a phandle the relevant regulator. All specified supplies must be able
to report their voltage. The IO Voltage Domain for any non-specified
supplies will be not be touched.
+Possible supplies for PX30:
+- vccio6-supply: The supply connected to VCCIO6.
+- vccio1-supply: The supply connected to VCCIO1.
+- vccio2-supply: The supply connected to VCCIO2.
+- vccio3-supply: The supply connected to VCCIO3.
+- vccio4-supply: The supply connected to VCCIO4.
+- vccio5-supply: The supply connected to VCCIO5.
+- vccio-oscgpi-supply: The supply connected to VCCIO_OSCGPI.
+
+Possible supplies for PX30 pmu-domains:
+- pmuio1-supply: The supply connected to PMUIO1.
+- pmuio2-supply: The supply connected to PMUIO2.
+
Possible supplies for rk3188:
- ap0-supply: The supply connected to AP0_VCC.
- ap1-supply: The supply connected to AP1_VCC.
diff --git a/drivers/power/avs/rockchip-io-domain.c b/drivers/power/avs/rockchip-io-domain.c
index ed2b109..d6a5e6b 100644
--- a/drivers/power/avs/rockchip-io-domain.c
+++ b/drivers/power/avs/rockchip-io-domain.c
@@ -39,6 +39,10 @@
#define MAX_VOLTAGE_1_8 1980000
#define MAX_VOLTAGE_3_3 3600000
+#define PX30_IO_VSEL 0x180
+#define PX30_IO_VSEL_VCCIO6_SRC BIT(0)
+#define PX30_IO_VSEL_VCCIO6_SUPPLY_NUM 1
+
#define RK3288_SOC_CON2 0x24c
#define RK3288_SOC_CON2_FLASH0 BIT(7)
#define RK3288_SOC_FLASH_SUPPLY_NUM 2
@@ -151,6 +155,25 @@ static int rockchip_iodomain_notify(struct notifier_block *nb,
return NOTIFY_OK;
}
+static void px30_iodomain_init(struct rockchip_iodomain *iod)
+{
+ int ret;
+ u32 val;
+
+ /* if no VCCIO0 supply we should leave things alone */
+ if (!iod->supplies[PX30_IO_VSEL_VCCIO6_SUPPLY_NUM].reg)
+ return;
+
+ /*
+ * set vccio0 iodomain to also use this framework
+ * instead of a special gpio.
+ */
+ val = PX30_IO_VSEL_VCCIO6_SRC | (PX30_IO_VSEL_VCCIO6_SRC << 16);
+ ret = regmap_write(iod->grf, PX30_IO_VSEL, val);
+ if (ret < 0)
+ dev_warn(iod->dev, "couldn't update vccio0 ctrl\n");
+}
+
static void rk3288_iodomain_init(struct rockchip_iodomain *iod)
{
int ret;
@@ -227,6 +250,43 @@ static void rk3399_pmu_iodomain_init(struct rockchip_iodomain *iod)
dev_warn(iod->dev, "couldn't update pmu io iodomain ctrl\n");
}
+static const struct rockchip_iodomain_soc_data soc_data_px30 = {
+ .grf_offset = 0x180,
+ .supply_names = {
+ NULL,
+ "vccio6",
+ "vccio1",
+ "vccio2",
+ "vccio3",
+ "vccio4",
+ "vccio5",
+ "vccio-oscgpi",
+ },
+ .init = px30_iodomain_init,
+};
+
+static const struct rockchip_iodomain_soc_data soc_data_px30_pmu = {
+ .grf_offset = 0x100,
+ .supply_names = {
+ NULL,
+ NULL,
+ NULL,
+ NULL,
+ NULL,
+ NULL,
+ NULL,
+ NULL,
+ NULL,
+ NULL,
+ NULL,
+ NULL,
+ NULL,
+ NULL,
+ "pmuio1",
+ "pmuio2",
+ },
+};
+
/*
* On the rk3188 the io-domains are handled by a shared register with the
* lower 8 bits being still being continuing drive-strength settings.
@@ -381,6 +441,14 @@ static const struct rockchip_iodomain_soc_data soc_data_rv1108_pmu = {
static const struct of_device_id rockchip_iodomain_match[] = {
{
+ .compatible = "rockchip,px30-io-voltage-domain",
+ .data = (void *)&soc_data_px30
+ },
+ {
+ .compatible = "rockchip,px30-pmu-io-voltage-domain",
+ .data = (void *)&soc_data_px30_pmu
+ },
+ {
.compatible = "rockchip,rk3188-io-voltage-domain",
.data = &soc_data_rk3188
},
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: dts: imx7d: correct cpu supply name for voltage scaling
From: Fabio Estevam @ 2018-05-15 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526375609-17676-1-git-send-email-Anson.Huang@nxp.com>
On Tue, May 15, 2018 at 6:13 AM, Anson Huang <Anson.Huang@nxp.com> wrote:
> diff --git a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
> index 7f64568..60deaf9 100644
> --- a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
> +++ b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
> @@ -33,7 +33,7 @@
> };
>
> &cpu0 {
> - arm-supply = <&sw1a_reg>;
> + cpu-supply = <&sw1a_reg>;
> };
>
> &fec1 {
> @@ -284,4 +284,4 @@
> MX7D_PAD_LPSR_GPIO1_IO05__GPIO1_IO5 0x14 /* OTG PWREN */
> >;
> };
> -};
> \ No newline at end of file
> +};
This change seems unrelated.
Other than that:
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH 0/4] KVM: arm/arm64: Fix locking issues
From: Paolo Bonzini @ 2018-05-15 11:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180515102659.GA38551@C02W217FHV2R.local>
On 15/05/2018 12:26, Christoffer Dall wrote:
> On Fri, May 11, 2018 at 03:20:11PM +0100, Andre Przywara wrote:
>> Jan recently reported lockdep complaints regarding various locks in our
>> VGIC emulation [1][2].
>> This boiled down to two separate issues:
>> - When promoting the vgic_irq->irq_lock to require IRQs being disabled,
>> we forgot to amend some instances of this lock on the way. Also this
>> needs to be applied to dependent locks as well. The first two patches
>> fix that. The patch split is designed to simplify backporting.
>> Those patches have been posted before, I am resending them as part
>> of this series.
>> - Calling kvm_read_guest() requires us to be inside an SRCU critical
>> section. On some architectures we are always in it when handling VCPU
>> exits, but on ARM we need to lock it individually. Patches 3 and 4
>> fix that, the split is again made to ease backporting.
>> Each of the hunks fix an indiviual commit, but I refrained from
>> splitting this down into eight patches just to put proper Fixes: tags
>> on it. Eventually those commits are part of one out of two series, I put
>> the respective kernel release version as a tag to the Cc: stable line.
>>
>> I couldn't reproduce the full lockdep splat on my setup, but at least
>> could show one instance and prove that these patches fixes that.
>>
>>
> For the series:
>
> Acked-by: Christoffer Dall <christoffer.dall@arm.com>
Shall I put the patches on their route to Linus?
Thanks,
Paolo
^ permalink raw reply
* [RFC PATCH 01/10] devfreq: rockchip-dfi: Move GRF definitions to a common place.
From: Robin Murphy @ 2018-05-15 11:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514211610.26618-2-enric.balletbo@collabora.com>
Hi Enric,
On 14/05/18 22:16, Enric Balletbo i Serra wrote:
> Some rk3399 GRF (Generic Register Files) definitions can be used for
> different drivers. Move these definitions to a common include so we
> don't need to duplicate these definitions.
>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> ---
>
> drivers/devfreq/event/rockchip-dfi.c | 23 +++++++----------------
> include/soc/rockchip/rk3399_grf.h | 21 +++++++++++++++++++++
> 2 files changed, 28 insertions(+), 16 deletions(-)
> create mode 100644 include/soc/rockchip/rk3399_grf.h
>
> diff --git a/drivers/devfreq/event/rockchip-dfi.c b/drivers/devfreq/event/rockchip-dfi.c
> index 22b113363ffc..2fbbcbeb644f 100644
> --- a/drivers/devfreq/event/rockchip-dfi.c
> +++ b/drivers/devfreq/event/rockchip-dfi.c
> @@ -26,6 +26,8 @@
> #include <linux/list.h>
> #include <linux/of.h>
>
> +#include <soc/rockchip/rk3399_grf.h>
> +
> #define RK3399_DMC_NUM_CH 2
>
> /* DDRMON_CTRL */
> @@ -43,18 +45,6 @@
> #define DDRMON_CH1_COUNT_NUM 0x3c
> #define DDRMON_CH1_DFI_ACCESS_NUM 0x40
>
> -/* pmu grf */
> -#define PMUGRF_OS_REG2 0x308
> -#define DDRTYPE_SHIFT 13
> -#define DDRTYPE_MASK 7
> -
> -enum {
> - DDR3 = 3,
> - LPDDR3 = 6,
> - LPDDR4 = 7,
> - UNUSED = 0xFF
> -};
> -
> struct dmc_usage {
> u32 access;
> u32 total;
> @@ -83,16 +73,17 @@ static void rockchip_dfi_start_hardware_counter(struct devfreq_event_dev *edev)
> u32 ddr_type;
>
> /* get ddr type */
> - regmap_read(info->regmap_pmu, PMUGRF_OS_REG2, &val);
> - ddr_type = (val >> DDRTYPE_SHIFT) & DDRTYPE_MASK;
> + regmap_read(info->regmap_pmu, RK3399_PMUGRF_OS_REG2, &val);
> + ddr_type = (val >> RK3399_PMUGRF_DDRTYPE_SHIFT) &
> + RK3399_PMUGRF_DDRTYPE_MASK;
>
> /* clear DDRMON_CTRL setting */
> writel_relaxed(CLR_DDRMON_CTRL, dfi_regs + DDRMON_CTRL);
>
> /* set ddr type to dfi */
> - if (ddr_type == LPDDR3)
> + if (ddr_type == RK3399_PMUGRF_DDRTYPE_LPDDR3)
> writel_relaxed(LPDDR3_EN, dfi_regs + DDRMON_CTRL);
> - else if (ddr_type == LPDDR4)
> + else if (ddr_type == RK3399_PMUGRF_DDRTYPE_LPDDR4)
> writel_relaxed(LPDDR4_EN, dfi_regs + DDRMON_CTRL);
>
> /* enable count, use software mode */
> diff --git a/include/soc/rockchip/rk3399_grf.h b/include/soc/rockchip/rk3399_grf.h
> new file mode 100644
> index 000000000000..0f94034e2e9a
> --- /dev/null
> +++ b/include/soc/rockchip/rk3399_grf.h
> @@ -0,0 +1,21 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Rockchip Generic Register Files definitions
Nit: s/Generic/General/
(that's what the TRMs say)
Robin.
> + *
> + * Copyright (c) 2018, Collabora Ltd.
> + * Author: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> + */
> +
> +#ifndef __SOC_RK3399_GRF_H
> +#define __SOC_RK3399_GRF_H
> +
> +/* PMU GRF Registers */
> +#define RK3399_PMUGRF_OS_REG2 0x308
> +#define RK3399_PMUGRF_DDRTYPE_SHIFT 13
> +#define RK3399_PMUGRF_DDRTYPE_MASK 7
> +#define RK3399_PMUGRF_DDRTYPE_DDR3 3
> +#define RK3399_PMUGRF_DDRTYPE_LPDDR2 5
> +#define RK3399_PMUGRF_DDRTYPE_LPDDR3 6
> +#define RK3399_PMUGRF_DDRTYPE_LPDDR4 7
> +
> +#endif
>
^ permalink raw reply
* [PATCH v2 2/2] clk: davinci: psc-dm365: fix few clocks
From: Sekhar Nori @ 2018-05-15 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180515112224.30122-1-nsekhar@ti.com>
Fix parent of EMAC and voice codec PSC clocks. Documentation is clear
on EMAC clock parent, but its not fully clear on parent of voice codec
clock. The implementation chosen is matches arch/arm/mach-davinci/dm365.c.
Add a comment explaining this for posterity.
There is only one power domain on DM365. Fix the power domain of voice
codec and vpss dac modules.
While at it, add a comment explaining how the parent of vpss dac clock was
derived. Note that this patch does not touch the parent of vpss dac clock.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
v2: add comments explaining parents of voice codec and vpss dac clocks
drivers/clk/davinci/psc-dm365.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/davinci/psc-dm365.c b/drivers/clk/davinci/psc-dm365.c
index 3ad915f37376..289af3913fb0 100644
--- a/drivers/clk/davinci/psc-dm365.c
+++ b/drivers/clk/davinci/psc-dm365.c
@@ -65,9 +65,22 @@ static const struct davinci_lpsc_clk_info dm365_psc_info[] = {
LPSC(31, 0, arm, pll2_sysclk2, NULL, LPSC_ALWAYS_ENABLED),
LPSC(38, 0, spi3, pll1_sysclk4, spi3_clkdev, 0),
LPSC(39, 0, spi4, pll1_auxclk, spi4_clkdev, 0),
- LPSC(40, 0, emac, pll2_sysclk4, emac_clkdev, 0),
- LPSC(44, 1, voice_codec, pll1_sysclk3, voice_codec_clkdev, 0),
- LPSC(46, 1, vpss_dac, pll1_sysclk3, vpss_dac_clkdev, 0),
+ LPSC(40, 0, emac, pll1_sysclk4, emac_clkdev, 0),
+ /*
+ * The TRM (ARM Subsystem User's Guide) shows two clocks input into
+ * voice codec module (PLL2 SYSCLK4 with a DIV2 and PLL1 SYSCLK4). Its
+ * not fully clear from documentation which clock should be considered
+ * as parent for PSC. The clock chosen here is to maintain
+ * compatibility with existing code in arch/arm/mach-davinci/dm365.c
+ */
+ LPSC(44, 0, voice_codec, pll2_sysclk4, voice_codec_clkdev, 0),
+ /*
+ * Its not fully clear from TRM (ARM Subsystem User's Guide) as to what
+ * the parent of VPSS DAC LPSC should actually be. PLL1 SYSCLK3 feeds
+ * into HDVICP and MJCP. The clock chosen here is to remain compatible
+ * with code existing in arch/arm/mach-davinci/dm365.c
+ */
+ LPSC(46, 0, vpss_dac, pll1_sysclk3, vpss_dac_clkdev, 0),
LPSC(47, 0, vpss_master, pll1_sysclk5, vpss_master_clkdev, 0),
LPSC(50, 0, mjcp, pll1_sysclk3, NULL, 0),
{ }
--
2.16.2
^ permalink raw reply related
* [PATCH v2 1/2] clk: davinci: pll-dm646x: keep PLL2 SYSCLK1 always enabled
From: Sekhar Nori @ 2018-05-15 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180515112224.30122-1-nsekhar@ti.com>
PLL2 SYSCLK1 on DM646x is connected to DDR2 PHY and cannot
be disabled. Mark it so to prevent unused clock disable
infrastructure from disabling it.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
v2: rebased to apply to v4.17-rc1. No functional change.
drivers/clk/davinci/pll-dm646x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/davinci/pll-dm646x.c b/drivers/clk/davinci/pll-dm646x.c
index a61cc3256418..0ae827e3ce80 100644
--- a/drivers/clk/davinci/pll-dm646x.c
+++ b/drivers/clk/davinci/pll-dm646x.c
@@ -72,7 +72,7 @@ static const struct davinci_pll_clk_info dm646x_pll2_info = {
.flags = 0,
};
-SYSCLK(1, pll2_sysclk1, pll2_pllen, 4, 0);
+SYSCLK(1, pll2_sysclk1, pll2_pllen, 4, SYSCLK_ALWAYS_ENABLED);
int dm646x_pll2_init(struct device *dev, void __iomem *base)
{
--
2.16.2
^ permalink raw reply related
* [PATCH v2 0/2] clk: davinci: some more fixes
From: Sekhar Nori @ 2018-05-15 11:22 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Some more fixes to make DM646x and DM365 EVMs boot after
common clock framework conversion. With this, I have tested
all DaVinci SoCs.
See individual patches for v2 changes.
Sekhar Nori (2):
clk: davinci: pll-dm646x: keep PLL2 SYSCLK1 always enabled
clk: davinci: psc-dm365: fix few clocks
drivers/clk/davinci/pll-dm646x.c | 2 +-
drivers/clk/davinci/psc-dm365.c | 19 ++++++++++++++++---
2 files changed, 17 insertions(+), 4 deletions(-)
--
2.16.2
^ permalink raw reply
* [PATCH 09/21] arm64: dts: allwinner: a64: Add HDMI support
From: Maxime Ripard @ 2018-05-15 11:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMty3ZDCubM2sLBfNVar-kA9djZ8PJDQJOS0Jwi6wWNVeK9mCg@mail.gmail.com>
On Mon, May 14, 2018 at 04:01:15PM +0530, Jagan Teki wrote:
> On Mon, May 14, 2018 at 2:10 PM, Maxime Ripard
> <maxime.ripard@bootlin.com> wrote:
> > On Mon, May 14, 2018 at 02:03:36PM +0530, Jagan Teki wrote:
> >> On Wed, May 2, 2018 at 5:04 PM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >> > Hi,
> >> >
> >> > On Mon, Apr 30, 2018 at 05:10:46PM +0530, Jagan Teki wrote:
> >> >> + hdmi_phy: hdmi-phy at 1ef0000 {
> >> >> + compatible = "allwinner,sun50i-a64-hdmi-phy",
> >> >> + "allwinner,sun8i-h3-hdmi-phy";
> >> >> + reg = <0x01ef0000 0x10000>;
> >> >> + clocks = <&ccu CLK_BUS_HDMI>, <&ccu CLK_HDMI_DDC>,
> >> >> + <&ccu CLK_PLL_VIDEO1>;
> >> >
> >> > You were discussing that the PLL0 could also be used to clock the PHY,
> >> > has that been figured out?
> >>
> >> This is what I understand from Fig: 3-3. Module Clock Diagram, both
> >> tcon0 and tcon1 are using HDMI. I'm thinking based on the tcon
> >> configuration we need use proper PLL or some logic to get common PLL
> >> don't know yet. Since this series adding tcon1 I've attached PLL1.
> >
> > You're not describing the TCON node here though, but the HDMI one, and
> > the HDMI block is listed in both the PLL video 0 and 1.
>
> So how can we attach particular PLL with particular HDMI(PLL0 to HDMI0
> and so-on) or do we need to attached both the PLL's any suggestion?
I'm not sure what your question is here, just add the possibility to
have an extra PLL if that makes sense to the binding.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180515/755566d1/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2 4/4] ARM: PWM: add allwinner sun8i pwm support.
From: Maxime Ripard @ 2018-05-15 11:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJeuY7-Dz1u9J8GMu=OdzJ2cJUnE3wEobJoQz6RV-ibjBjoW4A@mail.gmail.com>
Hi,
On Mon, May 14, 2018 at 10:45:44PM +0800, Hao Zhang wrote:
> 2018-02-26 17:00 GMT+08:00 Maxime Ripard <maxime.ripard@bootlin.com>:
> > Thanks for respinning this serie. It looks mostly good, but you still
> > have a quite significant number of checkpatch (--strict) warnings that
> > you should address.
>
> Thanks for reviews :) ,i'm sorry for that, it will be fixed next
> time. and, besides, in what situation were the checkpatch warning
> can be ignore?
The only one that can be reasonably be ignored is the long line
warning, and only if complying to the limit would make it less easy to
understand.
> >
> > On Sun, Feb 25, 2018 at 09:53:08PM +0800, hao_zhang wrote:
> >> +#define CAPTURE_IRQ_ENABLE_REG 0x0010
> >> +#define CFIE(ch) BIT(ch << 1 + 1)
> >> +#define CRIE(ch) BIT(ch << 1)
> >
> > You should also put your argument between parentheses here (and in all
> > your other macros).
>
> Do you mean like this ?
> #define CFIE(ch) BIT((ch) << 1 + 1)
> #define CRIE(ch) BIT((ch) << 1)
Yep, exactly. Otherwise, if you do something like CRIE(1 + 1), the
result will be BIT(1 + 1 << 1), which will expand to 3, instead of 4.
Also, CFIE looks a bit weird here, is it the offset that is
incremented, or the value? You should probably have parentheses to
make it explicit.
> >
> >> +static const u16 div_m_table[] = {
> >> + 1,
> >> + 2,
> >> + 4,
> >> + 8,
> >> + 16,
> >> + 32,
> >> + 64,
> >> + 128,
> >> + 256
> >> +};
> >
> > If this is just a power of two, you can use either the power of two /
> > ilog2 to switch back and forth, instead of using that table.
>
> I think using table is more explicit and extended...
If you didn't have a simple mapping between the register values and
the divider value, then yeah, sure. But it's not the case here.
Thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180515/23ba351d/attachment.sig>
^ 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