* [PATCH v2 1/6] arm: Add BTB invalidation on switch_mm for Cortex-A9, A12 and A17
From: Marc Zyngier @ 2018-01-09 14:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <06eb2573-ad3f-c980-ca15-8becfa600f62@arm.com>
On 09/01/18 14:21, Marc Zyngier wrote:
> On 09/01/18 14:14, Andre Przywara wrote:
>> Hi,
>>
>> On 08/01/18 18:55, Marc Zyngier wrote:
>>> In order to avoid aliasing attacks against the branch predictor,
>>> some implementations require to invalidate the BTB when switching
>>> from one user context to another.
>>>
>>> For this, we reuse the existing implementation for Cortex-A8, and
>>> apply it to A9, A12 and A17.
>>>
>>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>>> ---
>>> arch/arm/mm/proc-v7-2level.S | 4 ++--
>>> arch/arm/mm/proc-v7-3level.S | 6 ++++++
>>> arch/arm/mm/proc-v7.S | 30 +++++++++++++++---------------
>>> 3 files changed, 23 insertions(+), 17 deletions(-)
>>>
>>> diff --git a/arch/arm/mm/proc-v7-2level.S b/arch/arm/mm/proc-v7-2level.S
>>> index c6141a5435c3..0422e58b74e8 100644
>>> --- a/arch/arm/mm/proc-v7-2level.S
>>> +++ b/arch/arm/mm/proc-v7-2level.S
>>> @@ -41,7 +41,7 @@
>>> * even on Cortex-A8 revisions not affected by 430973.
>>> * If IBE is not set, the flush BTAC/BTB won't do anything.
>>> */
>>> -ENTRY(cpu_ca8_switch_mm)
>>> +ENTRY(cpu_v7_btbinv_switch_mm)
>>> #ifdef CONFIG_MMU
>>> mov r2, #0
>>> mcr p15, 0, r2, c7, c5, 6 @ flush BTAC/BTB
>>> @@ -66,7 +66,7 @@ ENTRY(cpu_v7_switch_mm)
>>> #endif
>>> bx lr
>>> ENDPROC(cpu_v7_switch_mm)
>>> -ENDPROC(cpu_ca8_switch_mm)
>>> +ENDPROC(cpu_v7_btbinv_switch_mm)
>>>
>>> /*
>>> * cpu_v7_set_pte_ext(ptep, pte)
>>> diff --git a/arch/arm/mm/proc-v7-3level.S b/arch/arm/mm/proc-v7-3level.S
>>> index 7d16bbc4102b..f6adfe88ead2 100644
>>> --- a/arch/arm/mm/proc-v7-3level.S
>>> +++ b/arch/arm/mm/proc-v7-3level.S
>>> @@ -54,6 +54,11 @@
>>> * Set the translation table base pointer to be pgd_phys (physical address of
>>> * the new TTB).
>>> */
>>> +ENTRY(cpu_v7_btbinv_switch_mm)
>>> +#ifdef CONFIG_MMU
>>> + mov r3, #0
>>
>> As Robin pointed out correctly, BPIALL ignores Rt, so you can get rid of
>> that line entirely (which is not matching the actual Rt below, btw).
>> Might be worth to add a comment about this.
> I know. I just kept it out of consistency with the existing Cortex-A8
> workaround, which may or may not behave the same way (I don't have one
> around to test...).
[pressed send too quickly]
And yes, the r2/r3 business is yet another blunder. Duh.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* soc: imx: gpcv2: removing and probing fails
From: Lucas Stach @ 2018-01-09 14:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3f836677c6e98aaf01bc1ac8c3410083@agner.ch>
Am Sonntag, den 07.01.2018, 11:48 +0100 schrieb Stefan Agner:
> Hi Andrew,
>
> I noticed that the driver fails when removing and probing again. As far
> as I can see due to duplicate add of the platform devices.
>
> As far as I can tell the driver should register the remove callback and
> do a platform_device_unregister on the newly created platform devices.
> However, as far as I can tell we don't hold on to a reference to them...
> I guess we could keep references in imx_gpcv2_probe, but maybe there is
> an easier way?
The GPC v1 driver adds the necessary device dependency between the
power domain devices and the GPC parent device. See the
device_link_add() in imx_pgc_power_domain_probe().
Probably something similar can be done to the GPC v2 driver.
Regards,
Lucas
^ permalink raw reply
* [PATCH 06/19] drm/blend: Add a generic alpha property
From: Daniel Vetter @ 2018-01-09 14:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109135322.7lb3snbxfcezobhz@flea>
On Tue, Jan 09, 2018 at 02:53:22PM +0100, Maxime Ripard wrote:
> On Tue, Jan 09, 2018 at 01:32:41PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 09, 2018 at 11:56:25AM +0100, Maxime Ripard wrote:
> > > Some drivers duplicate the logic to create a property to store a per-plane
> > > alpha.
> > >
> > > Let's create a helper in order to move that to the core.
> > >
> > > Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
> > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> >
> > Do we have userspace for this?
>
> Wayland seems to be on its way to implement this, with ChromeOS using
> it:
> https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741.html
>
> and more specifically:
> https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland-protocols/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml#118
Yay, would be good to include these links in the patch description. Really
happy we're having a real standard now used by multiple people.
> > Is encoding a fixed 0-255 range really the best idea?
>
> I don't really know, is there hardware or formats where there is more
> than 255? Or did you mean less than that?
30bit I'd assume wants more alpha. In the past we've done some fixed-point
stuff (e.g. for LUT), using the 0.0-1.0 float range. Using that for the
blend equation docs is also what I recommend (and that we map from 0-255
to 0.0-1.0 logically). Ofc the hw might not do any of that ... I think
0.16 fixed point, stored in a u16 is probably best. That's what we're
doing for gamma tables already, and that way drivers can simply throw away
the lower bits.
> > I know other drivers have skimped on the rules here a bit ... But at least
> > internally (i.e. within the drm_plane_state) we probably should restrict
> > ourselves to u8. And this needs real docs (i.e. the full blend equation
> > drivers are supposed to implement).
>
> You mean straight vs premultiplied? Maybe we should implement this as
> an additional property in read only depending on how the hardware
> behaves?
No need for an additional property right now, but definitely document
whether you mean straight or pre-multiplied. Just writing down the blend
equation is probably best.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [PATCH v2 1/5] pinctrl: imx: use struct imx_pinctrl_soc_info as a const
From: Gary Bisson @ 2018-01-09 14:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f12aa7b7b3aea7a691a1acd14b8daa58@agner.ch>
Hi Stefan,
On Mon, Jan 08, 2018 at 09:52:36PM +0100, Stefan Agner wrote:
> On 2018-01-08 17:48, Gary Bisson wrote:
> > Hi Stefan,
> >
> > On Sat, Jan 06, 2018 at 03:25:49PM +0100, Stefan Agner wrote:
> >> For some SoCs the struct imx_pinctrl_soc_info is passed through
> >> of_device_id.data which is const. Most variables are already const
> >> or otherwise not written. However, some fields are modified at
> >> runtime. Move those fields to the dynamically allocated struct
> >> imx_pinctrl.
> >>
> >> Fixes: b3060044e495 ("pinctrl: freescale: imx7d: make of_device_ids const")
> >> Cc: Shawn Guo <shawnguo@kernel.org>
> >> Cc: Arvind Yadav <arvind.yadav.cs@gmail.com>
> >> Cc: Dong Aisheng <aisheng.dong@nxp.com>
> >> Cc: Gary Bisson <gary.bisson@boundarydevices.com>
> >> Signed-off-by: Stefan Agner <stefan@agner.ch>
> >
> > This is actually more or less a revert of a previous commit:
> > b28742be4709 pinctrl: imx: remove const qualifier of imx_pinctrl_soc_info
>
> Hm, I see. However, back then imx_pinctrl_probe still consumed a
> non-const struct imx_pinctrl_soc_info pointer. So this constifies all
> the way through.
>
> >
> > Note that the idea for this commit was to get dt-overlays working and
> > able to do pinctrl changes using configfs interface to load an overlay
> > (using Pantelis patch). Not sure where we stand on loading such overlay
> > from user-space, is it still something that will happen?
>
> I am all for dt-overlays and actually also hope that it will make it
> completely into mainline. So whatever prevents using device tree
> overlays should be addressed.
>
> It seems that ngroups is now part of struct pinctrl_dev (num_groups),
> which is still writable. So we should be fine?
Correct, I forgot about the generic pinmux/pinctrl patches. Indeed
having the structure as const is perfectly fine now, even with
dt-overlays in mind.
Regards,
Gary
^ permalink raw reply
* [PATCH v2 5/5] pinctrl: imx6ul: add IOMUXC SNVS pinctrl driver for i.MX 6ULL
From: Linus Walleij @ 2018-01-09 14:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5CjCv1Lg6sazyJWS_xZvD6bXhW=1poYMEFUbgodAST5Yg@mail.gmail.com>
On Tue, Jan 9, 2018 at 3:11 PM, Fabio Estevam <festevam@gmail.com> wrote:
> On Tue, Jan 9, 2018 at 12:07 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>
>> Patch applied.
>>
>> I need clear maintainership for Freescale pin controllers.
>>
>> Stefan, would you consider making a patch adding you, Dong
>> Aisheng and Shawn Guo as maintainers in
>> MAINTAINERS for
>> drivers/pinctrl/freescale/*
>> Documentation/devicetree/bindings/pinctrl/fsl,*
>> ?
>>
>> I don't know if Shawn want to be added, but he wrote the first
>> version so unless he says explicitly no I think he should be
>> included.
>>
>> Sascha, do you also wanna be included?
>
> I would also like to be included, if possible.
The more the merrier :D
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: locomo: fix free dev incorrectly
From: Xiongwei Song @ 2018-01-09 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In function locomo_init_one_child, If kzalloc call is failed for dev we
would goto out label, then call kfree for dev, however, dev is NULL, we
shouldn't do this.
Signed-off-by: Xiongwei Song <sxwjean@me.com>
---
arch/arm/common/locomo.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/common/locomo.c b/arch/arm/common/locomo.c
index 51936bde1eb2..fb21b5ade391 100644
--- a/arch/arm/common/locomo.c
+++ b/arch/arm/common/locomo.c
@@ -256,10 +256,9 @@ locomo_init_one_child(struct locomo *lchip, struct locomo_dev_info *info)
NO_IRQ : lchip->irq_base + info->irq[0];
ret = device_register(&dev->dev);
- if (ret) {
- out:
+ if (ret)
kfree(dev);
- }
+ out:
return ret;
}
--
2.15.1
^ permalink raw reply related
* [PATCH] drivers: firmware: xilinx: Add ZynqMP firmware driver
From: Sudeep Holla @ 2018-01-09 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515449227-5096-1-git-send-email-jollys@xilinx.com>
On 08/01/18 22:07, Jolly Shah wrote:
> This patch is adding communication layer with firmware.
> Firmware driver provides an interface to firmware APIs.
> Interface APIs can be used by any driver to communicate to
> PMUFW(Platform Management Unit). All requests go through ATF.
> Firmware-debug provides debugfs interface to all APIs.
> Firmware-ggs provides read/write interface to
> global storage registers.
>
> Signed-off-by: Jolly Shah <jollys@xilinx.com>
> Signed-off-by: Rajan Vaja <rajanv@xilinx.com>
> ---
> .../firmware/xilinx/xlnx,zynqmp-firmware.txt | 16 +
> arch/arm64/Kconfig.platforms | 1 +
> drivers/firmware/Kconfig | 1 +
> drivers/firmware/Makefile | 1 +
> drivers/firmware/xilinx/Kconfig | 4 +
> drivers/firmware/xilinx/Makefile | 4 +
> drivers/firmware/xilinx/zynqmp/Kconfig | 23 +
> drivers/firmware/xilinx/zynqmp/Makefile | 5 +
> drivers/firmware/xilinx/zynqmp/firmware-debug.c | 540 +++++++++++
> drivers/firmware/xilinx/zynqmp/firmware-ggs.c | 298 ++++++
> drivers/firmware/xilinx/zynqmp/firmware.c | 1024 ++++++++++++++++++++
> .../linux/firmware/xilinx/zynqmp/firmware-debug.h | 32 +
> include/linux/firmware/xilinx/zynqmp/firmware.h | 573 +++++++++++
> 13 files changed, 2522 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
> create mode 100644 drivers/firmware/xilinx/Kconfig
> create mode 100644 drivers/firmware/xilinx/Makefile
> create mode 100644 drivers/firmware/xilinx/zynqmp/Kconfig
> create mode 100644 drivers/firmware/xilinx/zynqmp/Makefile
> create mode 100644 drivers/firmware/xilinx/zynqmp/firmware-debug.c
> create mode 100644 drivers/firmware/xilinx/zynqmp/firmware-ggs.c
> create mode 100644 drivers/firmware/xilinx/zynqmp/firmware.c
> create mode 100644 include/linux/firmware/xilinx/zynqmp/firmware-debug.h
> create mode 100644 include/linux/firmware/xilinx/zynqmp/firmware.h
>
> diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
> new file mode 100644
> index 0000000..ace111c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
> @@ -0,0 +1,16 @@
> +Xilinx Zynq MPSoC Firmware Device Tree Bindings
> +
> +The zynqmp-firmware node describes the interface to platform firmware.
> +
> +Required properties:
> + - compatible: Must contain: "xlnx,zynqmp-firmware"
> + - method: The method of calling the PM-API firmware layer.
> + Permitted values are:
> + - "smc" : To be used in configurations without a hypervisor
> + - "hvc" : To be used when hypervisor is present
> +
If we are having a mailbox using smc/hvc, then it can be made generic
rather than xilinx specific. I can see other user of the same. As Jassi
pointed out in some other thread, Andre has some generic implementation.
Please see how it can be reused.
Also please keep any bindings separate from the driver changes so that
it can be reviewed separately.
> +Examples:
> + firmware: firmware {
> + compatible = "xlnx,zynqmp-firmware";
> + method = "smc";
Ideally this should point to mailbox if we move to using smc/hvc based
mailbox.
[...]
> +
> +config ZYNQMP_FIRMWARE_DEBUG
> + bool "Enable Xilinx Zynq MPSoC firmware debug APIs"
> + depends on ARCH_ZYNQMP && DEBUG_FS
Do you need a separate Kconfig option, can't you just use DEBUG_FS ?
[...]
> +
> + if (strncasecmp(pm_api_req, "REQUEST_SUSPEND", 15) == 0)
> + pm_id = REQUEST_SUSPEND;
> + else if (strncasecmp(pm_api_req, "SELF_SUSPEND", 12) == 0)
> + pm_id = SELF_SUSPEND;
> + else if (strncasecmp(pm_api_req, "FORCE_POWERDOWN", 15) == 0)
> + pm_id = FORCE_POWERDOWN;
> + else if (strncasecmp(pm_api_req, "ABORT_SUSPEND", 13) == 0)
> + pm_id = ABORT_SUSPEND;
Can this be changed to a loop with a static structure array containing
{pm_id, pm_string, strlen(pm_string)} ?
Also I see hard-coded string length is wrong in some cases like IOCTL.
Isn't it better to just use strlen("..") instead ?
I will stop here as the patch can be easily split and several features
can be added incrementally making the base patch simpler and shorter.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH net-next v3 4/4] net: mvpp2: 2500baseX support
From: Russell King - ARM Linux @ 2018-01-09 14:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109085945.11916-5-antoine.tenart@free-electrons.com>
On Tue, Jan 09, 2018 at 09:59:45AM +0100, Antoine Tenart wrote:
> This patch adds the 2500Base-X PHY mode support in the Marvell PPv2
> driver. 2500Base-X is quite close to 1000Base-X and SGMII modes and uses
> nearly the same code path.
For 2500Base-X, do you report a speed of 2500Mbps through ethtool, or
are you reporting 1000Mbps? I don't see any code in this patch that
deals with that.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* soc: imx: gpcv2: removing and probing fails
From: Stefan Agner @ 2018-01-09 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515507886.12538.33.camel@pengutronix.de>
On 2018-01-09 15:24, Lucas Stach wrote:
> Am Sonntag, den 07.01.2018, 11:48 +0100 schrieb Stefan Agner:
>> Hi Andrew,
>>
>> I noticed that the driver fails when removing and probing again. As far
>> as I can see due to duplicate add of the platform devices.
>>
>> As far as I can tell the driver should register the remove callback and
>> do a platform_device_unregister on the newly created platform devices.
>> However, as far as I can tell we don't hold on to a reference to them...
>> I guess we could keep references in imx_gpcv2_probe, but maybe there is
>> an easier way?
>
> The GPC v1 driver adds the necessary device dependency between the
> power domain devices and the GPC parent device. See the
> device_link_add() in imx_pgc_power_domain_probe().
Note that despite device_link_add, GPC v1 seems to cause issue with
CONFIG_DEBUG_TEST_DRIVER_REMOVE=y:
https://marc.info/?l=linux-arm-kernel&m=151544599904423&w=4
(sorry, I made it confusing, by adding a stack trace when using GPC v1
in the gpcv2 thread...)
--
Stefan
>
> Probably something similar can be done to the GPC v2 driver.
>
> Regards,
> Lucas
^ permalink raw reply
* [PATCH net-next v3 4/4] net: mvpp2: 2500baseX support
From: Russell King - ARM Linux @ 2018-01-09 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109085945.11916-5-antoine.tenart@free-electrons.com>
On Tue, Jan 09, 2018 at 09:59:45AM +0100, Antoine Tenart wrote:
> This patch adds the 2500Base-X PHY mode support in the Marvell PPv2
> driver. 2500Base-X is quite close to 1000Base-X and SGMII modes and uses
> nearly the same code path.
Sorry, also...
> @@ -4668,6 +4692,10 @@ static void mvpp2_port_mii_gmac_configure_mode(struct mvpp2_port *port)
> */
> val |= MVPP2_GMAC_CONFIG_GMII_SPEED |
> MVPP2_GMAC_CONFIG_FULL_DUPLEX;
> + else if (port->phy_interface == PHY_INTERFACE_MODE_2500BASEX)
> + val |= MVPP2_GMAC_CONFIG_GMII_SPEED |
> + MVPP2_GMAC_CONFIG_MII_SPEED |
> + MVPP2_GMAC_CONFIG_FULL_DUPLEX;
I think you'll find you don't need to set MII_SPEED here, since
MII_SPEED selects between 10 and 100, GMII_SPEED always takes
precidence selecting 1000, and 2500 is done by the comphy
increasing the clocks by 2.5x.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* arm: Is VFP hotplug notifiers wrong?
From: okuno.kohji at jp.panasonic.com @ 2018-01-09 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1801091457210.1766@nanos>
Dear Russel and Thomas,
Thank you for your quick response.
Thomas, do you create the patch?
Best regards,
Kohji Okuno
> -----Original Message-----
> From: Thomas Gleixner [mailto:tglx at linutronix.de]
> Sent: Tuesday, January 9, 2018 10:58 PM
> To: Russell King - ARM Linux
> Cc: Okuno Kohji (?? ??); linux-arm-kernel at lists.infradead.org
> Subject: Re: arm: Is VFP hotplug notifiers wrong?
>
> On Tue, 9 Jan 2018, Russell King - ARM Linux wrote:
>
> > On Tue, Jan 09, 2018 at 08:12:21PM +0900, Kohji Okuno wrote:
> > > Dear Thomas and all,
> > >
> > > Could you please confirm about the following commit, again?
> > >
> > > http://git.armlinux.org.uk/cgit/linux-arm.git/commit/arch/arm/vfp/vf
> > > pmodule.c?id=e5b61bafe70477e05e1dce0d6ca4ec181e23cb2a
> > >
> > >
> > > The avobe commit eliminated the following fix, I think.
> > >
> > > http://git.armlinux.org.uk/cgit/linux-arm.git/commit/arch/arm/vfp/vf
> > > pmodule.c?id=384b38b66947b06999b3e39a596d4f2fb94f77e4
> > >
> > >
> > > vfp_force_reload() called from vfp_dying_cpu() does not clear
> > > vfp_current_hw_state[cpu], because cpu stopper task does not own the
> > > context held in the VFP hardware.
> >
> > You are correct, tglx's patch was wrong, since the state in the CPU
> > may not be the current thread's state, so vfp_force_reload() may not
> > do anything.
> >
> > vfp_force_reload() forces the reload of the specified state for the
> > specified CPU. What the original hotplug code did was to ensure that
> > the CPU's state would be reloaded when it came back up.
> >
> > I do wish that people wouldn't combine functional changes and cleanups
> > into one patch - it makes this kind of thing harder to spot in review
> > and also means when we encounter crap like this, it means we can't
> > simply revert the cleanup.
>
> sorry about that....
^ permalink raw reply
* [PATCH] ARM: realview: remove eb-mp clcd IRQ
From: Linus Walleij @ 2018-01-09 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3cc1ad94-0a62-2f35-d204-2b89b8ba642b@arm.com>
On Mon, Jan 8, 2018 at 5:31 PM, Robin Murphy <robin.murphy@arm.com> wrote:
> On 21/12/17 22:08, Linus Walleij wrote:
>> I do think the reference design has a character LCD, and I
>> do think it has an interrupt, it's just undocumented so
>> someone with this board would have to test it manually
>> to figure out which line it is. Whoever uses this design
>> will get to it if ever.
>
> FWIW the EB baseboard is *physically* the same regardless of the CPU, it's
> just flashed with a Core-Tile-specific FPGA bitstream.
Aha I always wondered how that works :)
> I've just tried
> firing up an 11MPCore one, and indeed the character LCD does light up with
> the kernel version. I can't convince the recalcitrant beast to actually get
> to userspace, though, so I can't confirm what the interrupt's deal is.
Yeah the driver survives fine without an IRQ too so it just works ...
> The baseboard manual (DUI0303E) says it's interrupt 22 on the board-level
> secondary GICs, and since neither the CT11MP nor its corresponding FPGA
> (AN152) mention any alternate routing direct to the Core Tile GIC, I'd guess
> it probably still is. On the other hand, though, it also says this:
>
> "... However this interrupt signal is reserved for future use and you
> must use a polling routine instead of an interrupt service routine."
>
> So maybe it's appropriate to just remove the interrupt everywhere :/
Hm I don't think there will be future releases of these EB
boards anytime soon, so I suspect we could just add it.
But as it works fine without IRQ we can just leave it as well.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: locomo: fix free dev incorrectly
From: Russell King - ARM Linux @ 2018-01-09 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109143755.16931-1-sxwjean@me.com>
On Tue, Jan 09, 2018 at 10:37:55PM +0800, Xiongwei Song wrote:
> In function locomo_init_one_child, If kzalloc call is failed for dev we
> would goto out label, then call kfree for dev, however, dev is NULL, we
> shouldn't do this.
kfree() internally checks for NULL pointers so callers don't have to.
Your patch is not necessary.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* arm: Is VFP hotplug notifiers wrong?
From: Russell King - ARM Linux @ 2018-01-09 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <104db10119fd453ba38edac32a228ab6@JPA000SECMN21.palet.jp.panasonic.com>
On Tue, Jan 09, 2018 at 02:46:30PM +0000, okuno.kohji at jp.panasonic.com wrote:
> Dear Russel and Thomas,
>
> Thank you for your quick response.
> Thomas, do you create the patch?
I'm afraid to say that I think everyone is super busy with spectre
and meltdown at the moment, sorry.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH] soc: brcmstb: Only register SoC device on STB platforms
From: Thierry Reding @ 2018-01-09 14:54 UTC (permalink / raw)
To: linux-arm-kernel
From: Thierry Reding <treding@nvidia.com>
After moving the SoC device initialization to an early initcall in
commit f780429adfbc ("soc: brcmstb: biuctrl: Move to early_initcall"),
the Broadcom STB SoC device is registered on all platforms if support
for the device is enabled in the kernel configuration.
This causes an additional SoC device to appear on platforms that already
register a native one. In case of Tegra the STB SoC device is registered
as soc0 (with totally meaningless content in the sysfs attributes) and
causes various scripts and programs to fail because they don't know how
to parse that data.
To fix this, duplicate the check from brcmstb_soc_device_early_init()
that already prevents the code from doing anything nonsensical on non-
STB platforms.
Fixes: f780429adfbc ("soc: brcmstb: biuctrl: Move to early_initcall")
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
drivers/soc/bcm/brcmstb/common.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/soc/bcm/brcmstb/common.c b/drivers/soc/bcm/brcmstb/common.c
index 781ada62d0a3..4fe1cb73b39a 100644
--- a/drivers/soc/bcm/brcmstb/common.c
+++ b/drivers/soc/bcm/brcmstb/common.c
@@ -89,8 +89,13 @@ early_initcall(brcmstb_soc_device_early_init);
static int __init brcmstb_soc_device_init(void)
{
struct soc_device_attribute *soc_dev_attr;
+ struct device_node *sun_top_ctrl;
struct soc_device *soc_dev;
+ sun_top_ctrl = of_find_matching_node(NULL, sun_top_ctrl_match);
+ if (!sun_top_ctrl)
+ return -ENODEV;
+
soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
if (!soc_dev_attr)
return -ENOMEM;
--
2.15.1
^ permalink raw reply related
* soc: imx: gpcv2: removing and probing fails
From: Lucas Stach @ 2018-01-09 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d71311e13720724b3b3bccd06fe9309b@agner.ch>
Am Dienstag, den 09.01.2018, 15:44 +0100 schrieb Stefan Agner:
> On 2018-01-09 15:24, Lucas Stach wrote:
> > Am Sonntag, den 07.01.2018, 11:48 +0100 schrieb Stefan Agner:
> > > Hi Andrew,
> > >
> > > I noticed that the driver fails when removing and probing again.
> > > As far
> > > as I can see due to duplicate add of the platform devices.
> > >
> > > As far as I can tell the driver should register the remove
> > > callback and
> > > do a platform_device_unregister on the newly created platform
> > > devices.
> > > However, as far as I can tell we don't hold on to a reference to
> > > them...
> > > I guess we could keep references in imx_gpcv2_probe, but maybe
> > > there is
> > > an easier way?
> >
> > The GPC v1 driver adds the necessary device dependency between the
> > power domain devices and the GPC parent device. See the
> > device_link_add() in imx_pgc_power_domain_probe().
>
> Note that despite device_link_add, GPC v1 seems to cause issue with
> CONFIG_DEBUG_TEST_DRIVER_REMOVE=y:
> https://marc.info/?l=linux-arm-kernel&m=151544599904423&w=4
>
> (sorry, I made it confusing, by adding a stack trace when using GPC
> v1
> in the gpcv2 thread...)
IMHO this is an issue with the?CONFIG_DEBUG_TEST_DRIVER_REMOVE option,
as it just blindly calls the remove callback instead of doing a proper
__device_release_driver(). All the regular driver/device unbind paths
will properly unbind the consumer devices before removing the driver.
I think this should be fixed in the device driver core instead of
individual drivers.
Regards,
Lucas
^ permalink raw reply
* arm: Is VFP hotplug notifiers wrong?
From: Fabio Estevam @ 2018-01-09 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <104db10119fd453ba38edac32a228ab6@JPA000SECMN21.palet.jp.panasonic.com>
Hi Okuno,
On Tue, Jan 9, 2018 at 12:46 PM, <okuno.kohji@jp.panasonic.com> wrote:
> Dear Russel and Thomas,
>
> Thank you for your quick response.
> Thomas, do you create the patch?
Looks like the fix should be like this:
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -648,7 +648,7 @@ int vfp_restore_user_hwstate(struct user_vfp __user *ufp,
*/
static int vfp_dying_cpu(unsigned int cpu)
{
- vfp_force_reload(cpu, current_thread_info());
+ vfp_current_hw_state[cpu] = NULL;
return 0;
}
Could you please test it?
Thanks
^ permalink raw reply
* [PATCH net-next v3 4/4] net: mvpp2: 2500baseX support
From: Antoine Tenart @ 2018-01-09 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109144238.GH17719@n2100.armlinux.org.uk>
Hi Russell,
On Tue, Jan 09, 2018 at 02:42:38PM +0000, Russell King - ARM Linux wrote:
> On Tue, Jan 09, 2018 at 09:59:45AM +0100, Antoine Tenart wrote:
> > This patch adds the 2500Base-X PHY mode support in the Marvell PPv2
> > driver. 2500Base-X is quite close to 1000Base-X and SGMII modes and uses
> > nearly the same code path.
>
> For 2500Base-X, do you report a speed of 2500Mbps through ethtool, or
> are you reporting 1000Mbps? I don't see any code in this patch that
> deals with that.
The mvpp2 driver uses phy_ethtool_get_link_ksettings() to report the
link speed to Ethtool. So it's reporting the speed set by the PHY
driver.
So it'll be something to ensure when adding PHYs supporting the mode.
We'll have the opportunity to see this when adding the last mcbin
interface.
Thanks!
Antoine
--
Antoine T?nart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH net-next v3 4/4] net: mvpp2: 2500baseX support
From: Antoine Tenart @ 2018-01-09 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109144447.GI17719@n2100.armlinux.org.uk>
Hi Russell,
On Tue, Jan 09, 2018 at 02:44:48PM +0000, Russell King - ARM Linux wrote:
> On Tue, Jan 09, 2018 at 09:59:45AM +0100, Antoine Tenart wrote:
> > This patch adds the 2500Base-X PHY mode support in the Marvell PPv2
> > driver. 2500Base-X is quite close to 1000Base-X and SGMII modes and uses
> > nearly the same code path.
>
> Sorry, also...
Comments always welcomed :)
> > @@ -4668,6 +4692,10 @@ static void mvpp2_port_mii_gmac_configure_mode(struct mvpp2_port *port)
> > */
> > val |= MVPP2_GMAC_CONFIG_GMII_SPEED |
> > MVPP2_GMAC_CONFIG_FULL_DUPLEX;
> > + else if (port->phy_interface == PHY_INTERFACE_MODE_2500BASEX)
> > + val |= MVPP2_GMAC_CONFIG_GMII_SPEED |
> > + MVPP2_GMAC_CONFIG_MII_SPEED |
> > + MVPP2_GMAC_CONFIG_FULL_DUPLEX;
>
> I think you'll find you don't need to set MII_SPEED here, since
> MII_SPEED selects between 10 and 100, GMII_SPEED always takes
> precidence selecting 1000, and 2500 is done by the comphy
> increasing the clocks by 2.5x.
I just had a look at the datasheet, and as you say it seems GMII_SPEED
takes over MII_SPEED. I'll see if there is a corner case here or if
selecting MII_SPEED doesn't make sense, and update accordingly.
Thanks!
Antoine
--
Antoine T?nart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] ARM: vfp: Go back to using vfp_current_hw_state()
From: Fabio Estevam @ 2018-01-09 15:19 UTC (permalink / raw)
To: linux-arm-kernel
Commit 384b38b66947 ("ARM: 7873/1: vfp: clear vfp_current_hw_state
for dying cpu") fixed the cpu dying notifier by using
vfp_current_hw_state(). However commit e5b61bafe704 ("arm: Convert VFP
hotplug notifiers to state machine") incorrectly used the original
vfp_force_reload() function in the cpu dying notifier.
Fix it by going back to the correct vfp_current_hw_state() usage.
Fixes: e5b61bafe704 ("arm: Convert VFP hotplug notifiers to state machine")
Cc: linux-stable <stable@vger.kernel.org>
Reported-by: Kohji Okuno <okuno.kohji@jp.panasonic.com>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/vfp/vfpmodule.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index a71a48e..aa7496b 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -648,7 +648,7 @@ int vfp_restore_user_hwstate(struct user_vfp __user *ufp,
*/
static int vfp_dying_cpu(unsigned int cpu)
{
- vfp_force_reload(cpu, current_thread_info());
+ vfp_current_hw_state[cpu] = NULL;
return 0;
}
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: imx: Remove epit support
From: Fabio Estevam @ 2018-01-09 15:24 UTC (permalink / raw)
To: linux-arm-kernel
Currently there is no user of EPIT, so remove such unused code.
If someone wants to add EPIT support back, then the person needs to
create a proper support into drivers/clocksource/ and add device
tree support, proper bindings, etc.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/mach-imx/Kconfig | 13 ---
arch/arm/mach-imx/Makefile | 1 -
arch/arm/mach-imx/epit.c | 228 ---------------------------------------------
3 files changed, 242 deletions(-)
delete mode 100644 arch/arm/mach-imx/epit.c
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 782699e..1831319 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -32,18 +32,6 @@ config MXC_DEBUG_BOARD
data/address de-multiplexing and decode, signal level shift,
interrupt control and various board functions.
-config HAVE_EPIT
- bool
-
-config MXC_USE_EPIT
- bool "Use EPIT instead of GPT"
- depends on HAVE_EPIT
- help
- Use EPIT as the system timer on systems that have it. Normally you
- don't have a reason to do so as the EPIT has the same features and
- uses the same clocks as the GPT. Anyway, on some systems the GPT
- may be in use for other purposes.
-
config HAVE_IMX_ANATOP
bool
@@ -85,7 +73,6 @@ config SOC_IMX31
config SOC_IMX35
bool
select ARCH_MXC_IOMUX_V3
- select HAVE_EPIT
select MXC_AVIC
select PINCTRL_IMX35
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index 8ff7105..04ba789 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -20,7 +20,6 @@ obj-$(CONFIG_ARCH_MXC_IOMUX_V3) += iomux-v3.o
obj-$(CONFIG_MXC_TZIC) += tzic.o
obj-$(CONFIG_MXC_AVIC) += avic.o
-obj-$(CONFIG_MXC_USE_EPIT) += epit.o
obj-$(CONFIG_MXC_DEBUG_BOARD) += 3ds_debugboard.o
ifeq ($(CONFIG_CPU_IDLE),y)
diff --git a/arch/arm/mach-imx/epit.c b/arch/arm/mach-imx/epit.c
deleted file mode 100644
index fb9a73a..0000000
--- a/arch/arm/mach-imx/epit.c
+++ /dev/null
@@ -1,228 +0,0 @@
-/*
- * linux/arch/arm/plat-mxc/epit.c
- *
- * Copyright (C) 2010 Sascha Hauer <s.hauer@pengutronix.de>
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version 2
- * of the License, or (at your option) any later version.
- * 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
- * MA 02110-1301, USA.
- */
-
-#define EPITCR 0x00
-#define EPITSR 0x04
-#define EPITLR 0x08
-#define EPITCMPR 0x0c
-#define EPITCNR 0x10
-
-#define EPITCR_EN (1 << 0)
-#define EPITCR_ENMOD (1 << 1)
-#define EPITCR_OCIEN (1 << 2)
-#define EPITCR_RLD (1 << 3)
-#define EPITCR_PRESC(x) (((x) & 0xfff) << 4)
-#define EPITCR_SWR (1 << 16)
-#define EPITCR_IOVW (1 << 17)
-#define EPITCR_DBGEN (1 << 18)
-#define EPITCR_WAITEN (1 << 19)
-#define EPITCR_RES (1 << 20)
-#define EPITCR_STOPEN (1 << 21)
-#define EPITCR_OM_DISCON (0 << 22)
-#define EPITCR_OM_TOGGLE (1 << 22)
-#define EPITCR_OM_CLEAR (2 << 22)
-#define EPITCR_OM_SET (3 << 22)
-#define EPITCR_CLKSRC_OFF (0 << 24)
-#define EPITCR_CLKSRC_PERIPHERAL (1 << 24)
-#define EPITCR_CLKSRC_REF_HIGH (1 << 24)
-#define EPITCR_CLKSRC_REF_LOW (3 << 24)
-
-#define EPITSR_OCIF (1 << 0)
-
-#include <linux/interrupt.h>
-#include <linux/irq.h>
-#include <linux/clockchips.h>
-#include <linux/clk.h>
-#include <linux/err.h>
-#include <asm/mach/time.h>
-
-#include "common.h"
-#include "hardware.h"
-
-static struct clock_event_device clockevent_epit;
-
-static void __iomem *timer_base;
-
-static inline void epit_irq_disable(void)
-{
- u32 val;
-
- val = imx_readl(timer_base + EPITCR);
- val &= ~EPITCR_OCIEN;
- imx_writel(val, timer_base + EPITCR);
-}
-
-static inline void epit_irq_enable(void)
-{
- u32 val;
-
- val = imx_readl(timer_base + EPITCR);
- val |= EPITCR_OCIEN;
- imx_writel(val, timer_base + EPITCR);
-}
-
-static void epit_irq_acknowledge(void)
-{
- imx_writel(EPITSR_OCIF, timer_base + EPITSR);
-}
-
-static int __init epit_clocksource_init(struct clk *timer_clk)
-{
- unsigned int c = clk_get_rate(timer_clk);
-
- return clocksource_mmio_init(timer_base + EPITCNR, "epit", c, 200, 32,
- clocksource_mmio_readl_down);
-}
-
-/* clock event */
-
-static int epit_set_next_event(unsigned long evt,
- struct clock_event_device *unused)
-{
- unsigned long tcmp;
-
- tcmp = imx_readl(timer_base + EPITCNR);
-
- imx_writel(tcmp - evt, timer_base + EPITCMPR);
-
- return 0;
-}
-
-/* Left event sources disabled, no more interrupts appear */
-static int epit_shutdown(struct clock_event_device *evt)
-{
- unsigned long flags;
-
- /*
- * The timer interrupt generation is disabled at least
- * for enough time to call epit_set_next_event()
- */
- local_irq_save(flags);
-
- /* Disable interrupt in GPT module */
- epit_irq_disable();
-
- /* Clear pending interrupt */
- epit_irq_acknowledge();
-
- local_irq_restore(flags);
-
- return 0;
-}
-
-static int epit_set_oneshot(struct clock_event_device *evt)
-{
- unsigned long flags;
-
- /*
- * The timer interrupt generation is disabled at least
- * for enough time to call epit_set_next_event()
- */
- local_irq_save(flags);
-
- /* Disable interrupt in GPT module */
- epit_irq_disable();
-
- /* Clear pending interrupt, only while switching mode */
- if (!clockevent_state_oneshot(evt))
- epit_irq_acknowledge();
-
- /*
- * Do not put overhead of interrupt enable/disable into
- * epit_set_next_event(), the core has about 4 minutes
- * to call epit_set_next_event() or shutdown clock after
- * mode switching
- */
- epit_irq_enable();
- local_irq_restore(flags);
-
- return 0;
-}
-
-/*
- * IRQ handler for the timer
- */
-static irqreturn_t epit_timer_interrupt(int irq, void *dev_id)
-{
- struct clock_event_device *evt = &clockevent_epit;
-
- epit_irq_acknowledge();
-
- evt->event_handler(evt);
-
- return IRQ_HANDLED;
-}
-
-static struct irqaction epit_timer_irq = {
- .name = "i.MX EPIT Timer Tick",
- .flags = IRQF_TIMER | IRQF_IRQPOLL,
- .handler = epit_timer_interrupt,
-};
-
-static struct clock_event_device clockevent_epit = {
- .name = "epit",
- .features = CLOCK_EVT_FEAT_ONESHOT,
- .set_state_shutdown = epit_shutdown,
- .tick_resume = epit_shutdown,
- .set_state_oneshot = epit_set_oneshot,
- .set_next_event = epit_set_next_event,
- .rating = 200,
-};
-
-static int __init epit_clockevent_init(struct clk *timer_clk)
-{
- clockevent_epit.cpumask = cpumask_of(0);
- clockevents_config_and_register(&clockevent_epit,
- clk_get_rate(timer_clk),
- 0x800, 0xfffffffe);
-
- return 0;
-}
-
-void __init epit_timer_init(void __iomem *base, int irq)
-{
- struct clk *timer_clk;
-
- timer_clk = clk_get_sys("imx-epit.0", NULL);
- if (IS_ERR(timer_clk)) {
- pr_err("i.MX epit: unable to get clk\n");
- return;
- }
-
- clk_prepare_enable(timer_clk);
-
- timer_base = base;
-
- /*
- * Initialise to a known state (all timers off, and timing reset)
- */
- imx_writel(0x0, timer_base + EPITCR);
-
- imx_writel(0xffffffff, timer_base + EPITLR);
- imx_writel(EPITCR_EN | EPITCR_CLKSRC_REF_HIGH | EPITCR_WAITEN,
- timer_base + EPITCR);
-
- /* init and register the timer to the framework */
- epit_clocksource_init(timer_clk);
- epit_clockevent_init(timer_clk);
-
- /* Make irqs happen */
- setup_irq(irq, &epit_timer_irq);
-}
--
2.7.4
^ permalink raw reply related
* [PATCH] soc: imx: gpc: de-register power domains only if initialized
From: Lucas Stach @ 2018-01-09 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180107134905.15624-1-stefan@agner.ch>
Am Sonntag, den 07.01.2018, 14:49 +0100 schrieb Stefan Agner:
> If power domain information are missing in the device tree, no
> power domains get initialized. However, imx_gpc_remove tries to
> remove power domains always in the old DT binding case. Only
> remove power domains when imx_gpc_probe initialized them in
> first place.
>
> Fixes: 721cabf6c660 ("soc: imx: move PGC handling to a new GPC
> driver")
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> ?drivers/soc/imx/gpc.c | 10 +++++++++-
> ?1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
> index 53f7275d6cbd..62bb724726d9 100644
> --- a/drivers/soc/imx/gpc.c
> +++ b/drivers/soc/imx/gpc.c
> @@ -470,13 +470,21 @@ static int imx_gpc_probe(struct platform_device
> *pdev)
> ?
> ?static int imx_gpc_remove(struct platform_device *pdev)
> ?{
> + struct device_node *pgc_node;
> ? int ret;
> ?
> + pgc_node = of_get_child_by_name(pdev->dev.of_node, "pgc");
> +
> + /* bail out if DT too old and doesn't provide the necessary
> info */
> + if (!of_property_read_bool(pdev->dev.of_node, "#power-
> domain-cells") &&
> + ????!pgc_node)
> + return 0;
> +
> ? /*
> ? ?* If the old DT binding is used the toplevel driver needs
> to
> ? ?* de-register the power domains
> ? ?*/
> - if (!of_get_child_by_name(pdev->dev.of_node, "pgc")) {
> + if (!pgc_node) {
> ? of_genpd_del_provider(pdev->dev.of_node);
> ?
> ? ret =
> pm_genpd_remove(&imx_gpc_domains[GPC_PGC_DOMAIN_PU].base);
^ permalink raw reply
* [PATCH 03/11] drm/bridge/synopsys: dw-hdmi: Enable workaround for v1.32a
From: Neil Armstrong @ 2018-01-09 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3367423.0HCaRuLuz8@avalon>
Hi,
I think this question is for Jose.
On 09/01/2018 13:56, Laurent Pinchart wrote:
> Hi Jernej,
>
> Thank you for the patch.
>
> On Saturday, 30 December 2017 23:01:55 EET Jernej Skrabec wrote:
>> Allwinner SoCs have dw hdmi controller v1.32a which exhibits same
>> magenta line issue as i.MX6Q and i.MX6DL. Enable workaround for it.
We observe the same issue on Amlogic SoCs with the dw hdmi controller v2.01a.
Rockchip seems to also use count=1 for 0x200a, 0x201a and 0x211a in
https://github.com/rockchip-linux/kernel/commit/cafa8ebd5f4df41425d6f2f61633d5bc64f20e65
Changelog is :
The issue can be worked around by issuing a TMDS software reset and
then write one of the FC registers several times. After tested, the
number of iterations of RK3399/RK3328(v2.11a), RK3368(v2.01a),
RK3288(v2.00a) is one.
Can you confirm it is necessary ?
Neil
>>
>> Tests show that one iteration is enough.
>>
>> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
>
> This does not break R-Car DU, so
>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
>> ---
>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 8 +++++---
>> 1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
>> a38db40ce990..7ca14d7325b5 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -1634,9 +1634,10 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi
>> *hdmi) * then write one of the FC registers several times.
>> *
>> * The number of iterations matters and depends on the HDMI TX revision
>> - * (and possibly on the platform). So far only i.MX6Q (v1.30a) and
>> - * i.MX6DL (v1.31a) have been identified as needing the workaround, with
>> - * 4 and 1 iterations respectively.
>> + * (and possibly on the platform). So far i.MX6Q (v1.30a), i.MX6DL
>> + * (v1.31a) and multiple Allwinner SoCs (v1.32a) have been identified
>> + * as needing the workaround, with 4 iterations for v1.30a and 1
>> + * iteration for others.
>> */
>>
>> switch (hdmi->version) {
>> @@ -1644,6 +1645,7 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi
>> *hdmi) count = 4;
>> break;
>> case 0x131a:
>> + case 0x132a:
>> count = 1;
>> break;
>> default:
>
^ permalink raw reply
* [PATCH] pwm: mediatek: fix up PWM4 and PWM5 malfunction on MT7623
From: Matthias Brugger @ 2018-01-09 15:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7ddf36f5b9400b29578d4897ddea72c57c1c8d11.1514213639.git.sean.wang@mediatek.com>
On 12/25/2017 03:59 PM, sean.wang at mediatek.com wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> Since the offset for both registers, PWMDWIDTH and PWMTHRES, used to
> control PWM4 or PWM5 are distinct from the other PWMs, whose wrong
> programming on PWM hardware causes waveform cannot be output as expected.
> Thus, the patch adds the extra condition for fixing up the weird case to
> let PWM4 or PWM5 able to work on MT7623.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> Cc: Zhi Mao <zhi.mao@mediatek.com>
> Cc: John Crispin <john@phrozen.org>
> ---
> drivers/pwm/pwm-mediatek.c | 24 +++++++++++++++++++++---
> 1 file changed, 21 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
> index f5d97e0..9311574 100644
> --- a/drivers/pwm/pwm-mediatek.c
> +++ b/drivers/pwm/pwm-mediatek.c
> @@ -29,7 +29,9 @@
> #define PWMGDUR 0x0c
> #define PWMWAVENUM 0x28
> #define PWMDWIDTH 0x2c
> +#define PWM45DWIDTH_QUIRK 0x30
> #define PWMTHRES 0x30
> +#define PWM45THRES_QUIRK 0x34
>
> #define PWM_CLK_DIV_MAX 7
>
> @@ -54,6 +56,7 @@ static const char * const mtk_pwm_clk_name[MTK_CLK_MAX] = {
>
> struct mtk_pwm_platform_data {
> unsigned int num_pwms;
> + bool pwm45_quirk;
> };
>
> /**
> @@ -66,6 +69,7 @@ struct mtk_pwm_chip {
> struct pwm_chip chip;
> void __iomem *regs;
> struct clk *clks[MTK_CLK_MAX];
> + const struct mtk_pwm_platform_data *soc;
> };
>
> static const unsigned int mtk_pwm_reg_offset[] = {
> @@ -131,7 +135,8 @@ static int mtk_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> {
> struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip);
> struct clk *clk = pc->clks[MTK_CLK_PWM1 + pwm->hwpwm];
> - u32 resolution, clkdiv = 0;
> + u32 resolution, clkdiv = 0, reg_width = PWMDWIDTH,
> + reg_thres = PWMTHRES;
> int ret;
>
> ret = mtk_pwm_clk_enable(chip, pwm);
> @@ -151,9 +156,18 @@ static int mtk_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> return -EINVAL;
> }
>
> + if (pc->soc->pwm45_quirk && pwm->hwpwm > 2) {
> + /*
> + * PWM[4,5] has distinct offset for PWMDWIDTH and PWMTHRES
> + * from the other PWMs on MT7623.
> + */
> + reg_width = PWM45DWIDTH_QUIRK;
> + reg_thres = PWM45THRES_QUIRK;
> + }
> +
> mtk_pwm_writel(pc, pwm->hwpwm, PWMCON, BIT(15) | clkdiv);
> - mtk_pwm_writel(pc, pwm->hwpwm, PWMDWIDTH, period_ns / resolution);
> - mtk_pwm_writel(pc, pwm->hwpwm, PWMTHRES, duty_ns / resolution);
> + mtk_pwm_writel(pc, pwm->hwpwm, reg_width, period_ns / resolution);
> + mtk_pwm_writel(pc, pwm->hwpwm, reg_thres, duty_ns / resolution);
>
> mtk_pwm_clk_disable(chip, pwm);
>
> @@ -211,6 +225,7 @@ static int mtk_pwm_probe(struct platform_device *pdev)
> data = of_device_get_match_data(&pdev->dev);
> if (data == NULL)
> return -EINVAL;
> + pc->soc = data;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> pc->regs = devm_ioremap_resource(&pdev->dev, res);
> @@ -251,14 +266,17 @@ static int mtk_pwm_remove(struct platform_device *pdev)
>
> static const struct mtk_pwm_platform_data mt2712_pwm_data = {
> .num_pwms = 8,
> + .pwm45_quirk = false,
Hm for me it doesn't look like a quirk but just the values a different. I wonder
why you decided to add a quirk flag. I'd added the access values to the
mtk_pwm_platform_data struct directly.
Regards,
Matthias
^ permalink raw reply
* [PATCH v2] iommu/exynos: Don't unconditionally steal bus ops
From: Robin Murphy @ 2018-01-09 15:34 UTC (permalink / raw)
To: linux-arm-kernel
Removing the early device registration hook overlooked the fact that
it only ran conditionally on a compatible device being present in the
DT. With exynos_iommu_init() now running as an unconditional initcall,
problems arise on non-Exynos systems when other IOMMU drivers find
themselves unable to install their ops on the platform bus, or at worst
the Exynos ops get called with someone else's domain and all hell breaks
loose.
The global ops/cache setup could probably all now be triggered from the
first IOMMU probe, as with dma_dev assigment, but for the time being the
simplest fix is to resurrect the logic from commit a7b67cd5d9af
("iommu/exynos: Play nice in multi-platform builds") to explicitly check
the DT for the presence of an Exynos IOMMU before trying anything.
Fixes: 928055a01b3f ("iommu/exynos: Remove custom platform device registration code")
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
v2: Use the simpler explicit DT check.
drivers/iommu/exynos-iommu.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 79c45650f8de..736d4552d96f 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -1353,8 +1353,15 @@ static const struct iommu_ops exynos_iommu_ops = {
static int __init exynos_iommu_init(void)
{
+ struct device_node *np;
int ret;
+ np = of_find_matching_node(NULL, sysmmu_of_match);
+ if (!np)
+ return 0;
+
+ of_node_put(np);
+
lv2table_kmem_cache = kmem_cache_create("exynos-iommu-lv2table",
LV2TABLE_SIZE, LV2TABLE_SIZE, 0, NULL);
if (!lv2table_kmem_cache) {
--
2.13.4.dirty
^ 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