* [PATCH 3/3] USB: host: ohci-at91: resume: balance the clock start call
From: Nicolas Ferre @ 2019-09-11 6:41 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, stern, gregkh
Cc: Boris.Krasnovskiy, Alexandre Belloni, linux-usb,
Ludovic Desroches
In-Reply-To: <20190911064154.28633-1-nicolas.ferre@microchip.com>
From: Boris Krasnovskiy <Boris.Krasnovskiy@lairdconnect.com>
There is a clock enable counter run away problem in resume ohci_at91. Code
enables clock that was never disabled in case of non wakeup interface. That
would make clock unstoppable in future.
Use proper alternative to start clocks only if they were stopped before.
Signed-off-by: Boris Krasnovskiy <Boris.Krasnovskiy@lairdconnect.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
---
drivers/usb/host/ohci-at91.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 85d67fe42d59..513e48397743 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -643,8 +643,8 @@ ohci_hcd_at91_drv_resume(struct device *dev)
if (ohci_at91->wakeup)
disable_irq_wake(hcd->irq);
-
- at91_start_clock(ohci_at91);
+ else
+ at91_start_clock(ohci_at91);
ohci_resume(hcd, false);
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 1/2] ARM: dts: imx7ulp: remove mipi pll clock node
From: Shawn Guo @ 2019-09-11 6:42 UTC (permalink / raw)
To: Fancy Fang
Cc: Aisheng Dong, Abel Vesa, Anson Huang, sboyd@kernel.org,
mturquette@baylibre.com, Jana Build, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org, LnxRevLi, dl-linux-imx,
kernel@pengutronix.de, festevam@gmail.com, s.hauer@pengutronix.de,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190823003600.8317-1-chen.fang@nxp.com>
On Fri, Aug 23, 2019 at 12:37:30AM +0000, Fancy Fang wrote:
> According to the IMX7ULP reference manual, the mipi pll
> clock comes from the MIPI PHY PLL output. So it should
> not be defined as a fixed clock. So remove this clock
> node and all the references to it.
>
> Signed-off-by: Fancy Fang <chen.fang@nxp.com>
Applied, thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] clk: imx7ulp: remove IMX7ULP_CLK_MIPI_PLL clock
From: Shawn Guo @ 2019-09-11 6:45 UTC (permalink / raw)
To: Fancy Fang
Cc: Aisheng Dong, Abel Vesa, Anson Huang, sboyd@kernel.org,
mturquette@baylibre.com, Jana Build, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org, LnxRevLi, dl-linux-imx,
kernel@pengutronix.de, festevam@gmail.com, s.hauer@pengutronix.de,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190823003600.8317-2-chen.fang@nxp.com>
On Fri, Aug 23, 2019 at 12:37:35AM +0000, Fancy Fang wrote:
> The mipi pll clock comes from the MIPI PHY PLL output, so
> it should not be a fixed clock.
>
> MIPI PHY PLL is in the MIPI DSI space, and it is used as
> the bit clock for transferring the pixel data out and its
> output clock is configured according to the display mode.
>
> So it should be used only for MIPI DSI and not be exported
> out for other usages.
>
> Signed-off-by: Fancy Fang <chen.fang@nxp.com>
> ---
> .../devicetree/bindings/clock/imx7ulp-clock.txt | 1 -
> drivers/clk/imx/clk-imx7ulp.c | 3 +--
> include/dt-bindings/clock/imx7ulp-clock.h | 15 +++++++--------
> 3 files changed, 8 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/imx7ulp-clock.txt b/Documentation/devicetree/bindings/clock/imx7ulp-clock.txt
> index a4f8cd478f92..93d89adb7afe 100644
> --- a/Documentation/devicetree/bindings/clock/imx7ulp-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/imx7ulp-clock.txt
> @@ -82,7 +82,6 @@ pcc2: pcc2@403f0000 {
> <&scg1 IMX7ULP_CLK_APLL_PFD0>,
> <&scg1 IMX7ULP_CLK_UPLL>,
> <&scg1 IMX7ULP_CLK_SOSC_BUS_CLK>,
> - <&scg1 IMX7ULP_CLK_MIPI_PLL>,
> <&scg1 IMX7ULP_CLK_FIRC_BUS_CLK>,
> <&scg1 IMX7ULP_CLK_ROSC>,
> <&scg1 IMX7ULP_CLK_SPLL_BUS_CLK>;
> diff --git a/drivers/clk/imx/clk-imx7ulp.c b/drivers/clk/imx/clk-imx7ulp.c
> index 2022d9bead91..459b120b71d5 100644
> --- a/drivers/clk/imx/clk-imx7ulp.c
> +++ b/drivers/clk/imx/clk-imx7ulp.c
> @@ -28,7 +28,7 @@ static const char * const scs_sels[] = { "dummy", "sosc", "sirc", "firc", "dumm
> static const char * const ddr_sels[] = { "apll_pfd_sel", "upll", };
> static const char * const nic_sels[] = { "firc", "ddr_clk", };
> static const char * const periph_plat_sels[] = { "dummy", "nic1_bus_clk", "nic1_clk", "ddr_clk", "apll_pfd2", "apll_pfd1", "apll_pfd0", "upll", };
> -static const char * const periph_bus_sels[] = { "dummy", "sosc_bus_clk", "mpll", "firc_bus_clk", "rosc", "nic1_bus_clk", "nic1_clk", "spll_bus_clk", };
> +static const char * const periph_bus_sels[] = { "dummy", "sosc_bus_clk", "dummy", "firc_bus_clk", "rosc", "nic1_bus_clk", "nic1_clk", "spll_bus_clk", };
> static const char * const arm_sels[] = { "divcore", "dummy", "dummy", "hsrun_divcore", };
>
> /* used by sosc/sirc/firc/ddr/spll/apll dividers */
> @@ -75,7 +75,6 @@ static void __init imx7ulp_clk_scg1_init(struct device_node *np)
> clks[IMX7ULP_CLK_SOSC] = imx_obtain_fixed_clk_hw(np, "sosc");
> clks[IMX7ULP_CLK_SIRC] = imx_obtain_fixed_clk_hw(np, "sirc");
> clks[IMX7ULP_CLK_FIRC] = imx_obtain_fixed_clk_hw(np, "firc");
> - clks[IMX7ULP_CLK_MIPI_PLL] = imx_obtain_fixed_clk_hw(np, "mpll");
> clks[IMX7ULP_CLK_UPLL] = imx_obtain_fixed_clk_hw(np, "upll");
>
> /* SCG1 */
> diff --git a/include/dt-bindings/clock/imx7ulp-clock.h b/include/dt-bindings/clock/imx7ulp-clock.h
> index 6f66f9005c81..f8d34fb4378f 100644
> --- a/include/dt-bindings/clock/imx7ulp-clock.h
> +++ b/include/dt-bindings/clock/imx7ulp-clock.h
> @@ -49,15 +49,14 @@
> #define IMX7ULP_CLK_NIC1_DIV 36
> #define IMX7ULP_CLK_NIC1_BUS_DIV 37
> #define IMX7ULP_CLK_NIC1_EXT_DIV 38
> -#define IMX7ULP_CLK_MIPI_PLL 39
> -#define IMX7ULP_CLK_SIRC 40
> -#define IMX7ULP_CLK_SOSC_BUS_CLK 41
> -#define IMX7ULP_CLK_FIRC_BUS_CLK 42
> -#define IMX7ULP_CLK_SPLL_BUS_CLK 43
> -#define IMX7ULP_CLK_HSRUN_SYS_SEL 44
> -#define IMX7ULP_CLK_HSRUN_CORE_DIV 45
> +#define IMX7ULP_CLK_SIRC 39
> +#define IMX7ULP_CLK_SOSC_BUS_CLK 40
> +#define IMX7ULP_CLK_FIRC_BUS_CLK 41
> +#define IMX7ULP_CLK_SPLL_BUS_CLK 42
> +#define IMX7ULP_CLK_HSRUN_SYS_SEL 43
> +#define IMX7ULP_CLK_HSRUN_CORE_DIV 44
No. These clock IDs need to be stable, as they are referred by DT.
If you want to remove an ID, just remove it, keep others unchanged.
Shawn
>
> -#define IMX7ULP_CLK_SCG1_END 46
> +#define IMX7ULP_CLK_SCG1_END 45
>
> /* PCC2 */
> #define IMX7ULP_CLK_DMA1 0
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] bus: imx-weim: remove __init from 2 functions
From: Shawn Guo @ 2019-09-11 7:03 UTC (permalink / raw)
To: Ilie Halip
Cc: clang-built-linux, Sascha Hauer, linux-kernel, linux-arm-kernel
In-Reply-To: <20190826095828.8948-1-ilie.halip@gmail.com>
On Mon, Aug 26, 2019 at 12:58:28PM +0300, Ilie Halip wrote:
> A previous commit removed __init from weim_probe(), but this attribute is
> still present for other functions called from it. Thus, these warnings
> are triggered:
> WARNING: Section mismatch in reference from the function weim_probe() to the function .init.text:imx_weim_gpr_setup()
> WARNING: Section mismatch in reference from the function weim_probe() to the function .init.text:weim_timing_setup()
>
> Remove the __init attribute from these functions as well, since they
> don't seem to be used anywhere else.
>
> Signed-off-by: Ilie Halip <ilie.halip@gmail.com>
> Reported-by: "kernelci.org bot" <bot@kernelci.org>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: clang-built-linux@googlegroups.com
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
Applied, thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] clk: at91: allow 24 Mhz clock as input for PLL
From: Nicolas.Ferre @ 2019-09-11 7:03 UTC (permalink / raw)
To: Eugen.Hristev, mturquette, sboyd, alexandre.belloni, linux-clk,
linux-arm-kernel, linux-kernel
In-Reply-To: <1568183622-7858-1-git-send-email-eugen.hristev@microchip.com>
On 11/09/2019 at 08:39, Eugen Hristev - M18282 wrote:
> From: Eugen Hristev <eugen.hristev@microchip.com>
>
> The PLL input range needs to be able to allow 24 Mhz crystal as input
> Update the range accordingly in plla characteristics struct
>
> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Thanks Eugen!
Best regards,
Nicolas
> ---
> drivers/clk/at91/sama5d2.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/at91/sama5d2.c b/drivers/clk/at91/sama5d2.c
> index 6509d09..0de1108 100644
> --- a/drivers/clk/at91/sama5d2.c
> +++ b/drivers/clk/at91/sama5d2.c
> @@ -21,7 +21,7 @@ static const struct clk_range plla_outputs[] = {
> };
>
> static const struct clk_pll_characteristics plla_characteristics = {
> - .input = { .min = 12000000, .max = 12000000 },
> + .input = { .min = 12000000, .max = 24000000 },
> .num_output = ARRAY_SIZE(plla_outputs),
> .output = plla_outputs,
> .icpll = plla_icpll,
>
--
Nicolas Ferre
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH] dt-bindings: arm: Convert Realtek board/soc bindings to json-schema
From: James Tai[戴志峰] @ 2019-09-11 7:19 UTC (permalink / raw)
To: Rob Herring, jamestai.sky@gmail.com
Cc: Mark Rutland, devicetree@vger.kernel.org,
CY_Huang[黃鉦晏], linux-kernel@vger.kernel.org,
Phinex Hung, Andreas Färber,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_JsqKGX1n-jsi0xtG8_Q=1LAhT=ufe0y2ZNBNoE3fR10K_xQ@mail.gmail.com>
> Subject: Re: [PATCH] dt-bindings: arm: Convert Realtek board/soc bindings to
> json-schema
>
> On Thu, Sep 5, 2019 at 9:19 AM <jamestai.sky@gmail.com> wrote:
> >
> > From: "james.tai" <james.tai@realtek.com>
> >
> > Convert Realtek SoC bindings to DT schema format using json-schema.
> >
> > Signed-off-by: james.tai <james.tai@realtek.com>
> > ---
> > .../devicetree/bindings/arm/realtek.txt | 22 -------------------
> > .../devicetree/bindings/arm/realtek.yaml | 17 ++++++++++++++
> > 2 files changed, 17 insertions(+), 22 deletions(-) delete mode
> > 100644 Documentation/devicetree/bindings/arm/realtek.txt
> > create mode 100644
> Documentation/devicetree/bindings/arm/realtek.yaml
>
> I've already submitted a patch for this that's *still* waiting on Andreas to apply
> or comment on the licensing.
Thanks for your reply.
> Also, your patch isn't valid schema. Please check with 'make
> dt_binding_check'.
>
I will check with 'make dt_binding_check'.
Thanks!
> ------Please consider the environment before printing this e-mail.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 4/4] arm64: dts: add support for A1 based Amlogic AD401
From: Jianxin Pan @ 2019-09-11 7:37 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: devicetree, Hanjie Lin, Victor Wan, Neil Armstrong, Kevin Hilman,
linux-kernel, Qiufang Dai, Rob Herring, Jian Hu, Xingyu Chen,
Tao Zeng, Carlo Caione, linux-amlogic, linux-arm-kernel,
Jerome Brunet
In-Reply-To: <CAFBinCAJG4=M3BSXfREGU+iadMPkc7=yt3AdcqA1KAhQx6Wh9w@mail.gmail.com>
Hi Martin,
On 2019/9/10 1:24, Martin Blumenstingl wrote:
> Hi Jianxin,
>
> On Mon, Sep 9, 2019 at 2:03 PM Jianxin Pan <jianxin.pan@amlogic.com> wrote:
>>
>> Hi Martin,
>>
>> On 2019/9/7 23:02, Martin Blumenstingl wrote:
>>> Hi Jianxin,
>>>
>>> On Fri, Sep 6, 2019 at 7:58 AM Jianxin Pan <jianxin.pan@amlogic.com> wrote:
>>> [...]
>>>>> also I'm a bit surprised to see no busses (like aobus, cbus, periphs, ...) here
>>>>> aren't there any busses defined in the A1 SoC implementation or are
>>>>> were you planning to add them later?
>>>> Unlike previous series,there is no Cortex-M3 AO CPU in A1, and there is no AO/EE power domain.
>>>> Most of the registers are on the apb_32b bus. aobus, cbus and periphs are not used in A1.
>>> OK, thank you for the explanation
>>> since you're going to re-send the patch anyways: can you please
>>> include the apb_32b bus?
>>> all other upstream Amlogic .dts are using the bus definitions, so that
>>> will make A1 consistent with the other SoCs
>> In A1 (and the later C1), BUS is not mentioned in the memmap and register spec.
>> Registers are organized and grouped by functions, and we can not find information about buses from the SoC document.
> do you know why the busses are not part of the documentation?
>
>> Maybe it's better to remove bus definitions for these chips.
> my understanding is that devicetree describes the hardware
> so if there's a bus in hardware (that we know about) then we should
> describe it in devicetree
>
> personally I think busses also make the .dts easier to read:
> instead of a huge .dts with all nodes on one level it's split into
> multiple smaller sub-nodes - thus making it easier to keep track of
> "where am I in this file".
>
OK, I will add the bus description for A1.
Thank you for your suggestion.
>
> Martin
>
> .
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] bus: imx-weim: remove __init from 2 functions
From: Ilie Halip @ 2019-09-11 7:40 UTC (permalink / raw)
To: Shawn Guo
Cc: clang-built-linux, Sascha Hauer, Arnd Bergmann, linux-arm-kernel
In-Reply-To: <20190911070314.GE17142@dragon>
Hi Shawn,
I think you can disregard this patch; the issue was already fixed by
Arnd[1] a couple of days after I sent it.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/commit/?h=for-next&id=3b1261fb72c7dc6a9e4604ef1ea01d6bb67cc3d1
Thanks,
I.H.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH] ARM: Add support for Realtek SOC
From: James Tai[戴志峰] @ 2019-09-11 7:45 UTC (permalink / raw)
To: Arnd Bergmann, jamestai.sky@gmail.com
Cc: Rob Herring, Jason A . Donenfeld, Thierry Reding, Ard Biesheuvel,
CY_Huang[黃鉦晏], Linus Walleij, Nicolas Pitre,
Nick Desaulniers, linux-kernel@vger.kernel.org, Stefan Agner,
Russell King, Masahiro Yamada, Paul Burton, Benjamin Gaignard,
Andreas Färber, Mauro Carvalho Chehab, Doug Anderson,
Mike Rapoport, Phinex Hung, Linux ARM
In-Reply-To: <CAK8P3a13=VBZnj6E=s7mZk0o7Q3XkMHgcsL12s-3psuOWsfOtQ@mail.gmail.com>
> Subject: Re: [PATCH] ARM: Add support for Realtek SOC
>
> On Thu, Sep 5, 2019 at 7:48 AM <jamestai.sky@gmail.com> wrote:
> >
> > From: "james.tai" <james.tai@realtek.com>
> >
> > This patch adds the basic machine file for the Realtek RTD16XX
> > platform.
> >
> > Signed-off-by: james.tai <james.tai@realtek.com>
>
> Hi James,
>
> Thanks a lot for your submission! I'm glad to see interest in upstream support
> for this SoC family. I have a few small comments on details, mostly where I
> would either like to see an explanation in the patch description, or things that
> looks like they can be left out from the patch.
>
Thanks for your reply.
> > index 33b00579beff..c7c9a3662eb7 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -836,6 +836,8 @@ source "arch/arm/mach-zx/Kconfig"
> >
> > source "arch/arm/mach-zynq/Kconfig"
> >
> > +source "arch/arm/mach-realtek/Kconfig"
> > +
> > diff --git a/arch/arm/mach-realtek/Kconfig
> b/arch/arm/mach-realtek/Kconfig
> > @@ -225,6 +226,7 @@ machine-$(CONFIG_ARCH_VT8500)
> += vt8500
> > machine-$(CONFIG_ARCH_W90X900) += w90x900
> > machine-$(CONFIG_ARCH_ZX) += zx
> > machine-$(CONFIG_ARCH_ZYNQ) += zynq
> > +machine-$(CONFIG_ARCH_REALTEK) += realtek
> > machine-$(CONFIG_PLAT_SPEAR) += spear
> >
> > # Platform directory name. This list is sorted alphanumerically
>
> Please keep these lists in alphabetical order.
>
I will keep these lists in alphabetical order in new version patch.
> > # ARMv7-M architecture
> > config ARCH_EFM32
> > bool "Energy Micro efm32"
> > diff --git a/arch/arm/Makefile b/arch/arm/Makefile index
> > c3624ca6c0bc..1f0926449d47 100644
> > --- a/arch/arm/Makefile
> > +++ b/arch/arm/Makefile
> > @@ -148,6 +148,7 @@ endif
> > textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
> > textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
> > textofs-$(CONFIG_ARCH_MESON) := 0x00208000
> > +textofs-$(CONFIG_ARCH_REALTEK) := 0x00208000
> > textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
>
> Can you explain why this is needed for your platform?
>
We need to reserve memory (0x00000000 ~ 0x001B0000) for rom and boot code.
> > # Machine directory name. This list is sorted alphanumerically new
> > file mode 100644 index 000000000000..a8269964dbdb
> > --- /dev/null
> > +++ b/arch/arm/mach-realtek/Kconfig
> > @@ -0,0 +1,32 @@
> > +# SPDX-License-Identifier: GPL-2.0-only menuconfig ARCH_REALTEK
> > + bool "Realtek SoCs"
>
> Please add "depends on ARCH_MULTI_V7" to avoid compile time issues when
> selecting it on an earlier architecture.
>
I will add "depends on ARCH_MULTI_V7" in new version patch.
> > + select ARM_GLOBAL_TIMER
> > + select CLKDEV_LOOKUP
> > + select HAVE_SMP
> > + select HAVE_MACH_CLKDEV
> > + select GENERIC_CLOCKEVENTS
> > + select HAVE_SCHED_CLOCK
> > + select ARCH_HAS_CPUFREQ
> > + select CLKSRC_OF
> > + select ARCH_REQUIRE_GPIOLIB
> > + select GENERIC_IRQ_CHIP
> > + select IRQ_DOMAIN
> > + select PINCTRL
> > + select COMMON_CLK
> > + select ARCH_HAS_BARRIERS
> > + select SPARSE_IRQ
> > + select PM_OPP
> > + select ARM_HAS_SG_CHAIN
> > + select ARM_PATCH_PHYS_VIRT
> > + select AUTO_ZRELADDR
> > + select MIGHT_HAVE_PCI
> > + select MULTI_IRQ_HANDLER
> > + select PCI_DOMAINS if PCI
> > + select USE_OF
>
> Almost all of the symbols above are implied by
> ARCH_MULTI_V7 and should not be selected separately.
>
OK, I understand.
> > +config ARCH_RTD16XX
> > + bool "Enable support for RTD1619"
> > + depends on ARCH_REALTEK
> > + select ARM_GIC_V3
> > + select ARM_PSCI
>
> As I understand, this chip uses a Cortex-A55. What is the reason for adding
> support only to the 32-bit ARM architecture rather than 64-bit?
The RTD16XX platform also support the 64-bit ARM architecture.
I will add the 64-bit ARM architecture in new version patch.
> Most 64-bit SoCs are only supported with arch/arm64, but generally speaking
> that is not a requirement. My rule of thumb is that on systems with 1GB of
> RAM or more, one would want to run a 64-bit kernel, while systems with less
> than that are better off with a 32-bit one, but that is clearly not the only reason
> for picking one over the other.
>
Support 32-bit ARM architecture is for application compatibility.
> > +
> > +static int rtk_boot_secondary(unsigned int cpu, struct task_struct
> > +*idle) {
> > + unsigned long entry_pa = __pa_symbol(secondary_startup);
> > +
> > + writel_relaxed(entry_pa | (cpu << CPUID), cpu_release_virt);
> > +
> > + arch_send_wakeup_ipi_mask(cpumask_of(cpu));
> > +
> > + return 0;
> > +}
>
> It's very unusual to see custom smp operations on an ARMv8 system, as we
> normally use PSCI here. Can you explain what is going on here? Are you able to
> use a boot wrapper that implements these in psci instead?
>
The smp operations is porting form other Realtek platform.
Currently, The RTD16XX platform can use the PSCI method.
I will add PSCI method in new version patch.
> > +
> > +#include "platsmp.h"
> > +
> > +#define RBUS_BASE_PHYS (0x98000000)
> > +#define RBUS_BASE_VIRT (0xfe000000)
> > +#define RBUS_BASE_SIZE (0x00100000)
> > +
> > +static struct map_desc rtk_io_desc[] __initdata = {
> > + {
> > + .virtual = (unsigned long) IOMEM(RBUS_BASE_VIRT),
> > + .pfn = __phys_to_pfn(RBUS_BASE_PHYS),
> > + .length = RBUS_BASE_SIZE,
> > + .type = MT_DEVICE,
> > + },
> > +};
>
> This needs a comment: Why do you require a static mapping for
> "RBUS_BASE_PHYS"? Normally device drivers should just use
> ioremap() for mapping whichever registers they want to access.
>
The static mapping is for old Realtek devices driver.
I will 'use ioremap()' to replace with static mapping.
> > +static void __init rtk_dt_init(void)
> > +{
> > + of_platform_populate(NULL, of_default_bus_match_table, NULL,
> > +NULL); }
>
> This should be taken care of by the
> of_platform_default_populate_init() and can be dropped.
>
I will remove rtk_dt_init() in new version patch.
> > +static void __init rtk_timer_init(void) { #ifdef CONFIG_COMMON_CLK
> > + of_clk_init(NULL);
> > +#endif
>
> COMMON_CLK is implied by ARCH_MULTI_V7, so the #ifdef can be dropped.
>
OK, I understand.
> > + timer_probe();
> > + tick_setup_hrtimer_broadcast(); }
>
> What do you need tick_setup_hrtimer_broadcast() for? I don't see any other
> platform calling this.
>
I want to initialize the HR timer.
> > +bool __init rtk_smp_init_ops(void)
> > +{
> > + smp_set_ops(smp_ops(rtk_smp_ops));
> > +
> > + return true;
> > +}
>
> I think this can also be dropped, as you set the smp_ops in the machine
> descriptor.
>
OK, I understand.
> Arnd
>
> ------Please consider the environment before printing this e-mail.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH] ARM: config: Add Realtek RTD16XX defconfig
From: James Tai[戴志峰] @ 2019-09-11 8:02 UTC (permalink / raw)
To: Arnd Bergmann, jamestai.sky@gmail.com
Cc: CY_Huang[黃鉦晏], Phinex Hung,
linux-kernel@vger.kernel.org, Linux ARM, Russell King
In-Reply-To: <CAK8P3a2j2m0mUPLDe5G19Xzu2t+xbO4QWvg=PdQWnGoqTkDpsg@mail.gmail.com>
> Subject: Re: [PATCH] ARM: config: Add Realtek RTD16XX defconfig
>
> On Thu, Sep 5, 2019 at 10:14 AM <jamestai.sky@gmail.com> wrote:
> >
> > From: "james.tai" <james.tai@realtek.com>
> >
> > Add a defconfig for Realtek RTD16XX platform.
> >
> > Signed-off-by: james.tai <james.tai@realtek.com>
> > ---
> > arch/arm/configs/rtd16xx_defconfig | 427
> > +++++++++++++++++++++++++++++
>
> We usually try to have one defconfig per vendor. Expecting that there will be
> other Realtek SoCs in the future that we may add here, I would name this
> 'rtd_defconfig' or 'realtek_defconfig'.
>
I will modify config file name in new version patch.
> Please also add the set of options you want to multi_v7_defconfig so you are
> able to boot with that.
OK, I understand.
> > 1 file changed, 427 insertions(+)
> > create mode 100644 arch/arm/configs/rtd16xx_defconfig
> >
> > diff --git a/arch/arm/configs/rtd16xx_defconfig
> > b/arch/arm/configs/rtd16xx_defconfig
> > new file mode 100644
> > index 000000000000..49bcbe6c6af8
> > --- /dev/null
> > +++ b/arch/arm/configs/rtd16xx_defconfig
> > @@ -0,0 +1,427 @@
> > +CONFIG_SYSVIPC=y
> > +CONFIG_NO_HZ=y
> > +CONFIG_HIGH_RES_TIMERS=y
> > +CONFIG_CGROUPS=y
> > +CONFIG_BLK_DEV_INITRD=y
> > +CONFIG_EMBEDDED=y
>
> I normally would not turn on CONFIG_EMBEDDED, this is only needed to
> change some rare options.
I will turn off CONFIG_EMBEDDED in new version patch.
> > +CONFIG_PERF_EVENTS=y
> > +CONFIG_ARCH_REALTEK=y
> > +CONFIG_ARCH_RTD16XX=y
> > +CONFIG_ARM_THUMBEE=y
>
> ThumbEE is deprecated in ARMv8, and one usually should not rely on it. If you
> don't actually need it, just turn it off.
I will turn off CONFIG_ARM_THUMBEE in new version patch.
> (note: this is unrelated to regular thumb execution, which is enabled by
> default)
>
> > +# CONFIG_CACHE_L2X0 is not set
> > +# CONFIG_ARM_ERRATA_643719 is not set
> CONFIG_ARM_ERRATA_814220=y
> > +CONFIG_SMP=y CONFIG_SCHED_MC=y CONFIG_SCHED_SMT=y
>
> If you don't have SMT in the CPU, there is no need ot enable this.
RTD16XX platform don't have SMT in the CPU.
I will turn off CONFIG_SCHED_SMT in new version patch.
> > +CONFIG_HAVE_ARM_ARCH_TIMER=y
> > +CONFIG_MCPM=y
> > +CONFIG_NR_CPUS=6
> > +CONFIG_HZ_250=y
> > +CONFIG_OABI_COMPAT=y
>
> It seems unlikely you want OABI_COMPAT
>
I will turn off CONFIG_OABI_COMPAT in new version patch.
> > +CONFIG_HIGHMEM=y
> > +CONFIG_FORCE_MAX_ZONEORDER=12
> > +CONFIG_SECCOMP=y
> > +CONFIG_ARM_APPENDED_DTB=y
> > +CONFIG_ARM_ATAG_DTB_COMPAT=y
> > +CONFIG_KEXEC=y
> > +CONFIG_EFI=y
>
> What method do you actually use for booting? New platforms should generally
> not require CONFIG_ARM_APPENDED_DTB or
> CONFIG_ARM_ATAG_DTB_COMPAT, and I suspect you don't use EFI.
>
RTD16XX platform don't use EFI.
I will turn off these config in new version patch.
> > +CONFIG_CPUFREQ_DT=y
> > +CONFIG_QORIQ_CPUFREQ=y
>
> QORIQ_CPUFREQ is a platform specific option that you won't need.
>
I will turn off CONFIG_QORIQ_CPUFREQ in new version patch.
> > +CONFIG_NET_DSA=m
> > +CONFIG_CAN=y
> > +CONFIG_CAN_FLEXCAN=m
> > +CONFIG_CAN_RCAR=m
> > +CONFIG_BT=m
> > +CONFIG_BT_HCIUART=m
> > +CONFIG_BT_HCIUART_BCM=y
> > +CONFIG_BT_MRVL=m
> > +CONFIG_BT_MRVL_SDIO=m
>
> Many more hardware specific drivers here that you should turn off
>
> > +CONFIG_MTD=y
> > +CONFIG_MTD_CMDLINE_PARTS=y
> > +CONFIG_MTD_BLOCK=y
> > +CONFIG_MTD_CFI=y
> > +CONFIG_MTD_PHYSMAP=y
> > +CONFIG_MTD_PHYSMAP_OF=y
> > +CONFIG_MTD_RAW_NAND=y
> > +CONFIG_MTD_NAND_DENALI_DT=y
> > +CONFIG_MTD_NAND_BRCMNAND=y
>
> and here.
I will turn off these config in new version patch.
> > +CONFIG_BLK_DEV_LOOP=y
> > +CONFIG_BLK_DEV_RAM=y
> > +CONFIG_BLK_DEV_RAM_SIZE=65536
>
> Do you require BLK_DEV_RAM for initrd? Normally one uses initramfs instead
> or tmpfs instead.
>
RTD16XX platform have use 'initramfs'.
I will turn off this config in new version patch.
> > +# CONFIG_NET_VENDOR_3COM is not set
> > +# CONFIG_NET_VENDOR_ADAPTEC is not set #
> CONFIG_NET_VENDOR_AGERE is
> > +not set # CONFIG_NET_VENDOR_ALACRITECH is not set #
> > +CONFIG_NET_VENDOR_ALTEON is not set
>
> I would trim the list here, just leave all network device vendors enabled, they
> don't hurt.
>
I will turn on these config in new version patch.
> > +CONFIG_USB_PEGASUS=y
> > +CONFIG_USB_RTL8152=m
> > +CONFIG_USB_LAN78XX=m
> > +CONFIG_USB_USBNET=y
> > +CONFIG_USB_NET_SMSC75XX=y
> > +CONFIG_USB_NET_SMSC95XX=y
> > +CONFIG_BRCMFMAC=m
> > +CONFIG_MWIFIEX=m
> > +CONFIG_MWIFIEX_SDIO=m
> > +CONFIG_RT2X00=m
> > +CONFIG_RT2800USB=m
>
> Do you need all of the above? It's no problem to enable them if you do, it just
> seems unusual.
RTD16XX platform don't need all config.
I will turn off these config in new version patch.
> Arnd
>
> ------Please consider the environment before printing this e-mail.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: Add support for Realtek SOC
From: Arnd Bergmann @ 2019-09-11 8:16 UTC (permalink / raw)
To: James Tai[戴志峰]
Cc: Jason A . Donenfeld, CY_Huang[黃鉦晏],
Linus Walleij, Stefan Agner, Masahiro Yamada, Benjamin Gaignard,
Mauro Carvalho Chehab, Phinex Hung, Rob Herring,
Lorenzo Pieralisi, Russell King, Mike Rapoport, Thierry Reding,
jamestai.sky@gmail.com, Doug Anderson, Linux ARM, Ard Biesheuvel,
Nicolas Pitre, Nick Desaulniers, linux-kernel@vger.kernel.org,
Paul Burton, Andreas Färber
In-Reply-To: <43B123F21A8CFE44A9641C099E4196FFCF8DA1D0@RTITMBSVM04.realtek.com.tw>
On Wed, Sep 11, 2019 at 9:46 AM James Tai[戴志峰] <james.tai@realtek.com> wrote:
> > Subject: Re: [PATCH] ARM: Add support for Realtek SOC
> > > @@ -148,6 +148,7 @@ endif
> > > textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
> > > textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
> > > textofs-$(CONFIG_ARCH_MESON) := 0x00208000
> > > +textofs-$(CONFIG_ARCH_REALTEK) := 0x00208000
> > > textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
> >
> > Can you explain why this is needed for your platform?
> >
> We need to reserve memory (0x00000000 ~ 0x001B0000) for rom and boot code.
Ok.
> > > +config ARCH_RTD16XX
> > > + bool "Enable support for RTD1619"
> > > + depends on ARCH_REALTEK
> > > + select ARM_GIC_V3
> > > + select ARM_PSCI
> >
> > As I understand, this chip uses a Cortex-A55. What is the reason for adding
> > support only to the 32-bit ARM architecture rather than 64-bit?
>
> The RTD16XX platform also support the 64-bit ARM architecture.
> I will add the 64-bit ARM architecture in new version patch.
>
> > Most 64-bit SoCs are only supported with arch/arm64, but generally speaking
> > that is not a requirement. My rule of thumb is that on systems with 1GB of
> > RAM or more, one would want to run a 64-bit kernel, while systems with less
> > than that are better off with a 32-bit one, but that is clearly not the only reason
> > for picking one over the other.
> >
> Support 32-bit ARM architecture is for application compatibility.
Generally speaking, a 64-bit kernel should work better on 64-bit hardware
even when you are running mostly 32-bit applications. However, you may
have device drivers that do not correctly set compat_ioctl handlers.
As I said, it's no problem to allow both, just explain this in the
changelog text for the driver, along with the need for the textofs
setting.
> > It's very unusual to see custom smp operations on an ARMv8 system, as we
> > normally use PSCI here. Can you explain what is going on here? Are you able to
> > use a boot wrapper that implements these in psci instead?
> >
> The smp operations is porting form other Realtek platform.
>
> Currently, The RTD16XX platform can use the PSCI method.
> I will add PSCI method in new version patch.
Ok, perfect!
> > > + timer_probe();
> > > + tick_setup_hrtimer_broadcast(); }
> >
> > What do you need tick_setup_hrtimer_broadcast() for? I don't see any other
> > platform calling this.
> >
> I want to initialize the HR timer.
I'm still unsure about this one. My feeling is that it should not be
in the platform
code, but I don't quite understand which hardware needs it. I see that
Lorenzo Pieralisi added the same code to arm64 in commit 9358d755bd5c
("arm64: kernel: initialize broadcast hrtimer based clock event device"),
but nothing ever calls it on 32-bit arch/arm even though the code does
get built in to the kernel.
My feeling is that either you don't really need it, or this is something
that other platforms should really do as well, and it should be called from
the generic time_init() function in arch/arm/kernel/time.c instead.
Can you try to find out more of the background here, and then
move the call to time_init() assuming it is indeed useful?
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH net-next 0/6] net: stmmac: Improvements for -next
From: David Miller @ 2019-09-11 8:21 UTC (permalink / raw)
To: Jose.Abreu
Cc: Joao.Pinto, alexandre.torgue, netdev, linux-kernel,
mcoquelin.stm32, peppe.cavallaro, linux-stm32, linux-arm-kernel
In-Reply-To: <cover.1568126224.git.joabreu@synopsys.com>
From: Jose Abreu <Jose.Abreu@synopsys.com>
Date: Tue, 10 Sep 2019 16:41:21 +0200
> Misc patches for -next. It includes:
> - Two fixes for features in -next only
> - New features support for GMAC cores (which includes GMAC4 and GMAC5)
Series applied, but what exactly does "ARP offload" even do?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 0/9] i2c: add support for filters
From: Eugen.Hristev @ 2019-09-11 8:24 UTC (permalink / raw)
To: wsa, peda, mark.rutland, Ludovic.Desroches, linux-i2c, devicetree,
linux-arm-kernel, linux-kernel, alexandre.belloni, robh+dt
Cc: Eugen.Hristev
From: Eugen Hristev <eugen.hristev@microchip.com>
Hello,
This series adds support for analog and digital filters for i2c controllers
This series is based on the series:
[PATCH v2 0/9] i2c: at91: filters support for at91 SoCs
and later
[PATCH v4 0/9] i2c: add support for filters
and enhanced to add the bindings for all controllers plus an extra bindings
for the width of the spikes in nanoseconds (digital filters) and cut-off
frequency (analog filters)
First, bindings are created for
'i2c-analog-filter'
'i2c-digital-filter'
'i2c-digital-filter-width-ns'
'i2c-analog-filter-cutoff-frequency'
The support is added in the i2c core to retrieve filter width/cutoff frequency
and add it to the timings structure.
Next, the at91 driver is enhanced for supporting digital filter, advanced
digital filter (with selectable spike width) and the analog filter.
Finally the device tree for two boards are modified to make use of the
new properties.
This series is the result of the comments on the ML in the direction
requested: to make the bindings globally available for i2c drivers.
Changes in v5:
- renamed i2c-filter-width-ns to i2c-digital-filter-width-ns as this
is applicable only to digital filter
- created new binding i2c-digital-filter-width-ns for analog filters.
Changes in v4:
- renamed i2c-ana-filter to i2c-analog-filter
- renamed i2c-dig-filter to i2c-digital-filter
Changes in v3:
- made bindings global for i2c controllers and modified accordingly
- gave up PADFCDF bit because it's a lack in datasheet
- the computation on the width of the spike is based on periph clock as it
is done for hold time.
Changes in v2:
- added device tree bindings and support for enable-ana-filt and
enable-dig-filt
- added the new properties to the DT for sama5d4_xplained/sama5d2_xplained
Eugen Hristev (9):
dt-bindings: i2c: at91: add new compatible
dt-bindings: i2c: add bindings for i2c analog and digital filter
i2c: add support for filters optional properties
i2c: at91: add new platform support for sam9x60
i2c: at91: add support for digital filtering
i2c: at91: add support for advanced digital filtering
i2c: at91: add support for analog filtering
ARM: dts: at91: sama5d2_xplained: add analog and digital filter for
i2c
ARM: dts: at91: sama5d4_xplained: add digital filter for i2c
Documentation/devicetree/bindings/i2c/i2c-at91.txt | 3 +-
Documentation/devicetree/bindings/i2c/i2c.txt | 18 ++++++++
arch/arm/boot/dts/at91-sama5d2_xplained.dts | 6 +++
arch/arm/boot/dts/at91-sama5d4_xplained.dts | 1 +
drivers/i2c/busses/i2c-at91-core.c | 38 +++++++++++++++++
drivers/i2c/busses/i2c-at91-master.c | 49 ++++++++++++++++++++--
drivers/i2c/busses/i2c-at91.h | 13 ++++++
drivers/i2c/i2c-core-base.c | 6 +++
include/linux/i2c.h | 6 +++
9 files changed, 136 insertions(+), 4 deletions(-)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 1/9] dt-bindings: i2c: at91: add new compatible
From: Eugen.Hristev @ 2019-09-11 8:24 UTC (permalink / raw)
To: wsa, peda, mark.rutland, Ludovic.Desroches, linux-i2c, devicetree,
linux-arm-kernel, linux-kernel, alexandre.belloni, robh+dt
Cc: Eugen.Hristev
In-Reply-To: <1568189911-31641-1-git-send-email-eugen.hristev@microchip.com>
From: Eugen Hristev <eugen.hristev@microchip.com>
Add compatible for new Microchip SoC, sam9x60
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
---
Documentation/devicetree/bindings/i2c/i2c-at91.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-at91.txt b/Documentation/devicetree/bindings/i2c/i2c-at91.txt
index b7cec17..2210f43 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-at91.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-at91.txt
@@ -3,7 +3,8 @@ I2C for Atmel platforms
Required properties :
- compatible : Must be "atmel,at91rm9200-i2c", "atmel,at91sam9261-i2c",
"atmel,at91sam9260-i2c", "atmel,at91sam9g20-i2c", "atmel,at91sam9g10-i2c",
- "atmel,at91sam9x5-i2c", "atmel,sama5d4-i2c" or "atmel,sama5d2-i2c"
+ "atmel,at91sam9x5-i2c", "atmel,sama5d4-i2c", "atmel,sama5d2-i2c" or
+ "microchip,sam9x60-i2c"
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: interrupt number to the cpu.
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 3/9] i2c: add support for filters optional properties
From: Eugen.Hristev @ 2019-09-11 8:24 UTC (permalink / raw)
To: wsa, peda, mark.rutland, Ludovic.Desroches, linux-i2c, devicetree,
linux-arm-kernel, linux-kernel, alexandre.belloni, robh+dt
Cc: Eugen.Hristev
In-Reply-To: <1568189911-31641-1-git-send-email-eugen.hristev@microchip.com>
From: Eugen Hristev <eugen.hristev@microchip.com>
i2c-digital-filter-width-ns:
This optional timing property specifies the width of the spikes on the i2c
lines (in ns) that can be filtered out by built-in digital filters which are
embedded in some i2c controllers.
i2c-analog-filter-cutoff-frequency:
This optional timing property specifies the cutoff frequency of a low-pass
analog filter built-in i2c controllers. This low pass filter is used to filter
out high frequency noise on the i2c lines. Specified in Hz.
Include these properties in the timings structure and read them as integers.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
---
drivers/i2c/i2c-core-base.c | 6 ++++++
include/linux/i2c.h | 6 ++++++
2 files changed, 12 insertions(+)
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 9c440fa..c9fcb16 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -1658,6 +1658,12 @@ void i2c_parse_fw_timings(struct device *dev, struct i2c_timings *t, bool use_de
t->sda_fall_ns = t->scl_fall_ns;
device_property_read_u32(dev, "i2c-sda-hold-time-ns", &t->sda_hold_ns);
+
+ device_property_read_u32(dev, "i2c-digital-filter-width-ns",
+ &t->digital_filter_width_ns);
+
+ device_property_read_u32(dev, "i2c-analog-filter-cutoff-frequency",
+ &t->analog_filter_cutoff_freq_hz);
}
EXPORT_SYMBOL_GPL(i2c_parse_fw_timings);
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index fa5552c..26ce143 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -575,6 +575,10 @@ struct i2c_lock_operations {
* @scl_int_delay_ns: time IP core additionally needs to setup SCL in ns
* @sda_fall_ns: time SDA signal takes to fall in ns; t(f) in the I2C specification
* @sda_hold_ns: time IP core additionally needs to hold SDA in ns
+ * @digital_filter_width_ns: width in ns of spikes on i2c lines that the IP core
+ * digital filter can filter out
+ * @analog_filter_cutoff_freq_hz: threshold frequency for the low pass IP core
+ analog filter
*/
struct i2c_timings {
u32 bus_freq_hz;
@@ -583,6 +587,8 @@ struct i2c_timings {
u32 scl_int_delay_ns;
u32 sda_fall_ns;
u32 sda_hold_ns;
+ u32 digital_filter_width_ns;
+ u32 analog_filter_cutoff_freq_hz;
};
/**
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 5/9] i2c: at91: add support for digital filtering
From: Eugen.Hristev @ 2019-09-11 8:24 UTC (permalink / raw)
To: wsa, peda, mark.rutland, Ludovic.Desroches, linux-i2c, devicetree,
linux-arm-kernel, linux-kernel, alexandre.belloni, robh+dt
Cc: Eugen.Hristev
In-Reply-To: <1568189911-31641-1-git-send-email-eugen.hristev@microchip.com>
From: Eugen Hristev <eugen.hristev@microchip.com>
Add new platform data support for digital filtering for i2c.
The sama5d4, sama5d2 and sam9x60 support this feature.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
---
drivers/i2c/busses/i2c-at91-core.c | 9 +++++++++
drivers/i2c/busses/i2c-at91-master.c | 9 +++++++++
drivers/i2c/busses/i2c-at91.h | 5 +++++
3 files changed, 23 insertions(+)
diff --git a/drivers/i2c/busses/i2c-at91-core.c b/drivers/i2c/busses/i2c-at91-core.c
index caf1846..e96360f 100644
--- a/drivers/i2c/busses/i2c-at91-core.c
+++ b/drivers/i2c/busses/i2c-at91-core.c
@@ -68,6 +68,7 @@ static struct at91_twi_pdata at91rm9200_config = {
.has_unre_flag = true,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9261_config = {
@@ -76,6 +77,7 @@ static struct at91_twi_pdata at91sam9261_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9260_config = {
@@ -84,6 +86,7 @@ static struct at91_twi_pdata at91sam9260_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9g20_config = {
@@ -92,6 +95,7 @@ static struct at91_twi_pdata at91sam9g20_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9g10_config = {
@@ -100,6 +104,7 @@ static struct at91_twi_pdata at91sam9g10_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static const struct platform_device_id at91_twi_devtypes[] = {
@@ -130,6 +135,7 @@ static struct at91_twi_pdata at91sam9x5_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static struct at91_twi_pdata sama5d4_config = {
@@ -138,6 +144,7 @@ static struct at91_twi_pdata sama5d4_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = true,
+ .has_dig_filtr = true,
};
static struct at91_twi_pdata sama5d2_config = {
@@ -146,6 +153,7 @@ static struct at91_twi_pdata sama5d2_config = {
.has_unre_flag = true,
.has_alt_cmd = true,
.has_hold_field = true,
+ .has_dig_filtr = true,
};
static struct at91_twi_pdata sam9x60_config = {
@@ -154,6 +162,7 @@ static struct at91_twi_pdata sam9x60_config = {
.has_unre_flag = true,
.has_alt_cmd = true,
.has_hold_field = true,
+ .has_dig_filtr = true,
};
static const struct of_device_id atmel_twi_dt_ids[] = {
diff --git a/drivers/i2c/busses/i2c-at91-master.c b/drivers/i2c/busses/i2c-at91-master.c
index a3fcc35..df80557 100644
--- a/drivers/i2c/busses/i2c-at91-master.c
+++ b/drivers/i2c/busses/i2c-at91-master.c
@@ -31,12 +31,18 @@
void at91_init_twi_bus_master(struct at91_twi_dev *dev)
{
+ struct at91_twi_pdata *pdata = dev->pdata;
+
/* FIFO should be enabled immediately after the software reset */
if (dev->fifo_size)
at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_FIFOEN);
at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_MSEN);
at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_SVDIS);
at91_twi_write(dev, AT91_TWI_CWGR, dev->twi_cwgr_reg);
+
+ /* enable digital filter */
+ if (pdata->has_dig_filtr && dev->enable_dig_filt)
+ at91_twi_write(dev, AT91_TWI_FILTR, AT91_TWI_FILTR_FILT);
}
/*
@@ -793,6 +799,9 @@ int at91_twi_probe_master(struct platform_device *pdev,
dev_info(dev->dev, "Using FIFO (%u data)\n", dev->fifo_size);
}
+ dev->enable_dig_filt = of_property_read_bool(pdev->dev.of_node,
+ "i2c-digital-filter");
+
at91_calc_twi_clock(dev);
dev->adapter.algo = &at91_twi_algorithm;
diff --git a/drivers/i2c/busses/i2c-at91.h b/drivers/i2c/busses/i2c-at91.h
index 499b506..c75447e 100644
--- a/drivers/i2c/busses/i2c-at91.h
+++ b/drivers/i2c/busses/i2c-at91.h
@@ -84,6 +84,9 @@
#define AT91_TWI_ACR_DATAL(len) ((len) & 0xff)
#define AT91_TWI_ACR_DIR BIT(8)
+#define AT91_TWI_FILTR 0x0044
+#define AT91_TWI_FILTR_FILT BIT(0)
+
#define AT91_TWI_FMR 0x0050 /* FIFO Mode Register */
#define AT91_TWI_FMR_TXRDYM(mode) (((mode) & 0x3) << 0)
#define AT91_TWI_FMR_TXRDYM_MASK (0x3 << 0)
@@ -108,6 +111,7 @@ struct at91_twi_pdata {
bool has_unre_flag;
bool has_alt_cmd;
bool has_hold_field;
+ bool has_dig_filtr;
struct at_dma_slave dma_slave;
};
@@ -145,6 +149,7 @@ struct at91_twi_dev {
unsigned smr;
struct i2c_client *slave;
#endif
+ bool enable_dig_filt;
};
unsigned at91_twi_read(struct at91_twi_dev *dev, unsigned reg);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 2/9] dt-bindings: i2c: add bindings for i2c analog and digital filter
From: Eugen.Hristev @ 2019-09-11 8:24 UTC (permalink / raw)
To: wsa, peda, mark.rutland, Ludovic.Desroches, linux-i2c, devicetree,
linux-arm-kernel, linux-kernel, alexandre.belloni, robh+dt
Cc: Eugen.Hristev
In-Reply-To: <1568189911-31641-1-git-send-email-eugen.hristev@microchip.com>
From: Eugen Hristev <eugen.hristev@microchip.com>
Some i2c controllers have a built-in digital or analog filter.
This is specifically required depending on the hardware PCB/board.
Some controllers also allow specifying the maximum width of the
spikes that can be filtered for digital filter. The width length can be
specified in nanoseconds.
Analog filters can be configured to have a cutoff frequency (low-pass filter).
This frequency can be specified in Hz.
Added an optional property for such types of analog filters.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
---
Documentation/devicetree/bindings/i2c/i2c.txt | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt
index 44efafd..9a53df4 100644
--- a/Documentation/devicetree/bindings/i2c/i2c.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c.txt
@@ -55,6 +55,24 @@ wants to support one of the below features, it should adapt the bindings below.
Number of nanoseconds the SDA signal takes to fall; t(f) in the I2C
specification.
+- i2c-analog-filter
+ Enable analog filter for i2c lines.
+
+- i2c-digital-filter
+ Enable digital filter for i2c lines.
+
+- i2c-digital-filter-width-ns
+ Width of spikes which can be filtered by digital filter
+ (i2c-digital-filter). This width is specified in nanoseconds.
+
+- i2c-analog-filter-cutoff-frequency
+ Frequency that the analog filter (i2c-analog-filter) uses to distinguish
+ which signal to filter. Signal with higher frequency than specified will
+ be filtered out. Only lower frequency will pass (this is applicable to
+ a low-pass analog filter). Typical value should be above the normal
+ i2c bus clock frequency (clock-frequency).
+ Specified in Hz.
+
- interrupts
interrupts used by the device.
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 4/9] i2c: at91: add new platform support for sam9x60
From: Eugen.Hristev @ 2019-09-11 8:24 UTC (permalink / raw)
To: wsa, peda, mark.rutland, Ludovic.Desroches, linux-i2c, devicetree,
linux-arm-kernel, linux-kernel, alexandre.belloni, robh+dt
Cc: Eugen.Hristev
In-Reply-To: <1568189911-31641-1-git-send-email-eugen.hristev@microchip.com>
From: Eugen Hristev <eugen.hristev@microchip.com>
Add new platform data support for the sam9x60 SoC
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
---
drivers/i2c/busses/i2c-at91-core.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/i2c/busses/i2c-at91-core.c b/drivers/i2c/busses/i2c-at91-core.c
index 435c7d7..caf1846 100644
--- a/drivers/i2c/busses/i2c-at91-core.c
+++ b/drivers/i2c/busses/i2c-at91-core.c
@@ -148,6 +148,14 @@ static struct at91_twi_pdata sama5d2_config = {
.has_hold_field = true,
};
+static struct at91_twi_pdata sam9x60_config = {
+ .clk_max_div = 7,
+ .clk_offset = 4,
+ .has_unre_flag = true,
+ .has_alt_cmd = true,
+ .has_hold_field = true,
+};
+
static const struct of_device_id atmel_twi_dt_ids[] = {
{
.compatible = "atmel,at91rm9200-i2c",
@@ -174,6 +182,9 @@ static const struct of_device_id atmel_twi_dt_ids[] = {
.compatible = "atmel,sama5d2-i2c",
.data = &sama5d2_config,
}, {
+ .compatible = "microchip,sam9x60-i2c",
+ .data = &sam9x60_config,
+ }, {
/* sentinel */
}
};
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 7/9] i2c: at91: add support for analog filtering
From: Eugen.Hristev @ 2019-09-11 8:24 UTC (permalink / raw)
To: wsa, peda, mark.rutland, Ludovic.Desroches, linux-i2c, devicetree,
linux-arm-kernel, linux-kernel, alexandre.belloni, robh+dt
Cc: Eugen.Hristev
In-Reply-To: <1568189911-31641-1-git-send-email-eugen.hristev@microchip.com>
From: Eugen Hristev <eugen.hristev@microchip.com>
Add support for analog filtering for i2c lines.
The sama5d2 and sam9x60 support this feature.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
---
drivers/i2c/busses/i2c-at91-core.c | 9 +++++++++
drivers/i2c/busses/i2c-at91-master.c | 18 ++++++++++++++----
drivers/i2c/busses/i2c-at91.h | 3 +++
3 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-at91-core.c b/drivers/i2c/busses/i2c-at91-core.c
index 1f4ee7e..e13af48 100644
--- a/drivers/i2c/busses/i2c-at91-core.c
+++ b/drivers/i2c/busses/i2c-at91-core.c
@@ -70,6 +70,7 @@ static struct at91_twi_pdata at91rm9200_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata at91sam9261_config = {
@@ -80,6 +81,7 @@ static struct at91_twi_pdata at91sam9261_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata at91sam9260_config = {
@@ -90,6 +92,7 @@ static struct at91_twi_pdata at91sam9260_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata at91sam9g20_config = {
@@ -100,6 +103,7 @@ static struct at91_twi_pdata at91sam9g20_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata at91sam9g10_config = {
@@ -110,6 +114,7 @@ static struct at91_twi_pdata at91sam9g10_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static const struct platform_device_id at91_twi_devtypes[] = {
@@ -142,6 +147,7 @@ static struct at91_twi_pdata at91sam9x5_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata sama5d4_config = {
@@ -152,6 +158,7 @@ static struct at91_twi_pdata sama5d4_config = {
.has_hold_field = true,
.has_dig_filtr = true,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata sama5d2_config = {
@@ -162,6 +169,7 @@ static struct at91_twi_pdata sama5d2_config = {
.has_hold_field = true,
.has_dig_filtr = true,
.has_adv_dig_filtr = true,
+ .has_ana_filtr = true,
};
static struct at91_twi_pdata sam9x60_config = {
@@ -172,6 +180,7 @@ static struct at91_twi_pdata sam9x60_config = {
.has_hold_field = true,
.has_dig_filtr = true,
.has_adv_dig_filtr = true,
+ .has_ana_filtr = true,
};
static const struct of_device_id atmel_twi_dt_ids[] = {
diff --git a/drivers/i2c/busses/i2c-at91-master.c b/drivers/i2c/busses/i2c-at91-master.c
index 273bd8b..6e0b554 100644
--- a/drivers/i2c/busses/i2c-at91-master.c
+++ b/drivers/i2c/busses/i2c-at91-master.c
@@ -32,6 +32,7 @@
void at91_init_twi_bus_master(struct at91_twi_dev *dev)
{
struct at91_twi_pdata *pdata = dev->pdata;
+ u32 filtr = 0;
/* FIFO should be enabled immediately after the software reset */
if (dev->fifo_size)
@@ -42,13 +43,20 @@ void at91_init_twi_bus_master(struct at91_twi_dev *dev)
/* enable digital filter */
if (pdata->has_dig_filtr && dev->enable_dig_filt)
- at91_twi_write(dev, AT91_TWI_FILTR, AT91_TWI_FILTR_FILT);
+ filtr |= AT91_TWI_FILTR_FILT;
/* enable advanced digital filter */
if (pdata->has_adv_dig_filtr && dev->enable_dig_filt)
- at91_twi_write(dev, AT91_TWI_FILTR, AT91_TWI_FILTR_FILT |
- (AT91_TWI_FILTR_THRES(dev->filter_width) &
- AT91_TWI_FILTR_THRES_MASK));
+ filtr |= AT91_TWI_FILTR_FILT |
+ (AT91_TWI_FILTR_THRES(dev->filter_width) &
+ AT91_TWI_FILTR_THRES_MASK);
+
+ /* enable analog filter */
+ if (pdata->has_ana_filtr && dev->enable_ana_filt)
+ filtr |= AT91_TWI_FILTR_PADFEN;
+
+ if (filtr)
+ at91_twi_write(dev, AT91_TWI_FILTR, filtr);
}
/*
@@ -826,6 +834,8 @@ int at91_twi_probe_master(struct platform_device *pdev,
dev->enable_dig_filt = of_property_read_bool(pdev->dev.of_node,
"i2c-digital-filter");
+ dev->enable_ana_filt = of_property_read_bool(pdev->dev.of_node,
+ "i2c-analog-filter");
at91_calc_twi_clock(dev);
dev->adapter.algo = &at91_twi_algorithm;
diff --git a/drivers/i2c/busses/i2c-at91.h b/drivers/i2c/busses/i2c-at91.h
index d7cf01e3..977a67b 100644
--- a/drivers/i2c/busses/i2c-at91.h
+++ b/drivers/i2c/busses/i2c-at91.h
@@ -86,6 +86,7 @@
#define AT91_TWI_FILTR 0x0044
#define AT91_TWI_FILTR_FILT BIT(0)
+#define AT91_TWI_FILTR_PADFEN BIT(1)
#define AT91_TWI_FILTR_THRES(v) ((v) << 8)
#define AT91_TWI_FILTR_THRES_MAX 7
#define AT91_TWI_FILTR_THRES_MASK GENMASK(10, 8)
@@ -116,6 +117,7 @@ struct at91_twi_pdata {
bool has_hold_field;
bool has_dig_filtr;
bool has_adv_dig_filtr;
+ bool has_ana_filtr;
struct at_dma_slave dma_slave;
};
@@ -154,6 +156,7 @@ struct at91_twi_dev {
struct i2c_client *slave;
#endif
bool enable_dig_filt;
+ bool enable_ana_filt;
u32 filter_width;
};
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 8/9] ARM: dts: at91: sama5d2_xplained: add analog and digital filter for i2c
From: Eugen.Hristev @ 2019-09-11 8:24 UTC (permalink / raw)
To: wsa, peda, mark.rutland, Ludovic.Desroches, linux-i2c, devicetree,
linux-arm-kernel, linux-kernel, alexandre.belloni, robh+dt
Cc: Eugen.Hristev
In-Reply-To: <1568189911-31641-1-git-send-email-eugen.hristev@microchip.com>
From: Eugen Hristev <eugen.hristev@microchip.com>
Add property for analog and digital filter for i2c1 and i2c2 nodes
for sama5d2_xplained
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
---
arch/arm/boot/dts/at91-sama5d2_xplained.dts | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
index 808e399..9d0a7fb 100644
--- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
@@ -334,6 +334,9 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_flx4_default>;
atmel,fifo-size = <16>;
+ i2c-analog-filter;
+ i2c-digital-filter;
+ i2c-digital-filter-width-ns = <35>;
status = "okay";
};
};
@@ -342,6 +345,9 @@
dmas = <0>, <0>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c1_default>;
+ i2c-analog-filter;
+ i2c-digital-filter;
+ i2c-digital-filter-width-ns = <35>;
status = "okay";
at24@54 {
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 9/9] ARM: dts: at91: sama5d4_xplained: add digital filter for i2c
From: Eugen.Hristev @ 2019-09-11 8:24 UTC (permalink / raw)
To: wsa, peda, mark.rutland, Ludovic.Desroches, linux-i2c, devicetree,
linux-arm-kernel, linux-kernel, alexandre.belloni, robh+dt
Cc: Eugen.Hristev
In-Reply-To: <1568189911-31641-1-git-send-email-eugen.hristev@microchip.com>
From: Eugen Hristev <eugen.hristev@microchip.com>
Add property for digital filter for i2c0 node sama5d4_xplained
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
---
arch/arm/boot/dts/at91-sama5d4_xplained.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/at91-sama5d4_xplained.dts b/arch/arm/boot/dts/at91-sama5d4_xplained.dts
index fdfc37d..924d949 100644
--- a/arch/arm/boot/dts/at91-sama5d4_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d4_xplained.dts
@@ -49,6 +49,7 @@
};
i2c0: i2c@f8014000 {
+ i2c-digital-filter;
status = "okay";
};
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 6/9] i2c: at91: add support for advanced digital filtering
From: Eugen.Hristev @ 2019-09-11 8:24 UTC (permalink / raw)
To: wsa, peda, mark.rutland, Ludovic.Desroches, linux-i2c, devicetree,
linux-arm-kernel, linux-kernel, alexandre.belloni, robh+dt
Cc: Eugen.Hristev
In-Reply-To: <1568189911-31641-1-git-send-email-eugen.hristev@microchip.com>
From: Eugen Hristev <eugen.hristev@microchip.com>
Add new platform data support for advanced digital filtering for i2c.
The sama5d2 and sam9x60 support this feature.
This digital filter allows the user to configure the maximum
width of the spikes that can be filtered.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
---
drivers/i2c/busses/i2c-at91-core.c | 9 +++++++++
drivers/i2c/busses/i2c-at91-master.c | 30 +++++++++++++++++++++++++++---
drivers/i2c/busses/i2c-at91.h | 5 +++++
3 files changed, 41 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-at91-core.c b/drivers/i2c/busses/i2c-at91-core.c
index e96360f..1f4ee7e 100644
--- a/drivers/i2c/busses/i2c-at91-core.c
+++ b/drivers/i2c/busses/i2c-at91-core.c
@@ -69,6 +69,7 @@ static struct at91_twi_pdata at91rm9200_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9261_config = {
@@ -78,6 +79,7 @@ static struct at91_twi_pdata at91sam9261_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9260_config = {
@@ -87,6 +89,7 @@ static struct at91_twi_pdata at91sam9260_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9g20_config = {
@@ -96,6 +99,7 @@ static struct at91_twi_pdata at91sam9g20_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9g10_config = {
@@ -105,6 +109,7 @@ static struct at91_twi_pdata at91sam9g10_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static const struct platform_device_id at91_twi_devtypes[] = {
@@ -136,6 +141,7 @@ static struct at91_twi_pdata at91sam9x5_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata sama5d4_config = {
@@ -145,6 +151,7 @@ static struct at91_twi_pdata sama5d4_config = {
.has_alt_cmd = false,
.has_hold_field = true,
.has_dig_filtr = true,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata sama5d2_config = {
@@ -154,6 +161,7 @@ static struct at91_twi_pdata sama5d2_config = {
.has_alt_cmd = true,
.has_hold_field = true,
.has_dig_filtr = true,
+ .has_adv_dig_filtr = true,
};
static struct at91_twi_pdata sam9x60_config = {
@@ -163,6 +171,7 @@ static struct at91_twi_pdata sam9x60_config = {
.has_alt_cmd = true,
.has_hold_field = true,
.has_dig_filtr = true,
+ .has_adv_dig_filtr = true,
};
static const struct of_device_id atmel_twi_dt_ids[] = {
diff --git a/drivers/i2c/busses/i2c-at91-master.c b/drivers/i2c/busses/i2c-at91-master.c
index df80557..273bd8b 100644
--- a/drivers/i2c/busses/i2c-at91-master.c
+++ b/drivers/i2c/busses/i2c-at91-master.c
@@ -43,6 +43,12 @@ void at91_init_twi_bus_master(struct at91_twi_dev *dev)
/* enable digital filter */
if (pdata->has_dig_filtr && dev->enable_dig_filt)
at91_twi_write(dev, AT91_TWI_FILTR, AT91_TWI_FILTR_FILT);
+
+ /* enable advanced digital filter */
+ if (pdata->has_adv_dig_filtr && dev->enable_dig_filt)
+ at91_twi_write(dev, AT91_TWI_FILTR, AT91_TWI_FILTR_FILT |
+ (AT91_TWI_FILTR_THRES(dev->filter_width) &
+ AT91_TWI_FILTR_THRES_MASK));
}
/*
@@ -51,7 +57,7 @@ void at91_init_twi_bus_master(struct at91_twi_dev *dev)
*/
static void at91_calc_twi_clock(struct at91_twi_dev *dev)
{
- int ckdiv, cdiv, div, hold = 0;
+ int ckdiv, cdiv, div, hold = 0, filter_width = 0;
struct at91_twi_pdata *pdata = dev->pdata;
int offset = pdata->clk_offset;
int max_ckdiv = pdata->clk_max_div;
@@ -90,11 +96,29 @@ static void at91_calc_twi_clock(struct at91_twi_dev *dev)
}
}
+ if (pdata->has_adv_dig_filtr) {
+ /*
+ * filter width = 0 to AT91_TWI_FILTR_THRES_MAX
+ * peripheral clocks
+ */
+ filter_width = DIV_ROUND_UP(t->digital_filter_width_ns
+ * (clk_get_rate(dev->clk) / 1000), 1000000);
+ if (filter_width > AT91_TWI_FILTR_THRES_MAX) {
+ dev_warn(dev->dev,
+ "Filter threshold set to its maximum value (%d instead of %d)\n",
+ AT91_TWI_FILTR_THRES_MAX, filter_width);
+ filter_width = AT91_TWI_FILTR_THRES_MAX;
+ }
+ }
+
dev->twi_cwgr_reg = (ckdiv << 16) | (cdiv << 8) | cdiv
| AT91_TWI_CWGR_HOLD(hold);
- dev_dbg(dev->dev, "cdiv %d ckdiv %d hold %d (%d ns)\n",
- cdiv, ckdiv, hold, t->sda_hold_ns);
+ dev->filter_width = filter_width;
+
+ dev_dbg(dev->dev, "cdiv %d ckdiv %d hold %d (%d ns), filter_width %d (%d ns)\n",
+ cdiv, ckdiv, hold, t->sda_hold_ns, filter_width,
+ t->digital_filter_width_ns);
}
static void at91_twi_dma_cleanup(struct at91_twi_dev *dev)
diff --git a/drivers/i2c/busses/i2c-at91.h b/drivers/i2c/busses/i2c-at91.h
index c75447e..d7cf01e3 100644
--- a/drivers/i2c/busses/i2c-at91.h
+++ b/drivers/i2c/busses/i2c-at91.h
@@ -86,6 +86,9 @@
#define AT91_TWI_FILTR 0x0044
#define AT91_TWI_FILTR_FILT BIT(0)
+#define AT91_TWI_FILTR_THRES(v) ((v) << 8)
+#define AT91_TWI_FILTR_THRES_MAX 7
+#define AT91_TWI_FILTR_THRES_MASK GENMASK(10, 8)
#define AT91_TWI_FMR 0x0050 /* FIFO Mode Register */
#define AT91_TWI_FMR_TXRDYM(mode) (((mode) & 0x3) << 0)
@@ -112,6 +115,7 @@ struct at91_twi_pdata {
bool has_alt_cmd;
bool has_hold_field;
bool has_dig_filtr;
+ bool has_adv_dig_filtr;
struct at_dma_slave dma_slave;
};
@@ -150,6 +154,7 @@ struct at91_twi_dev {
struct i2c_client *slave;
#endif
bool enable_dig_filt;
+ u32 filter_width;
};
unsigned at91_twi_read(struct at91_twi_dev *dev, unsigned reg);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3] drm: bridge/dw_hdmi: add audio sample channel status setting
From: Cheng-Yi Chiang @ 2019-09-11 8:26 UTC (permalink / raw)
To: linux-kernel
Cc: alsa-devel, kuninori.morimoto.gx, Neil Armstrong, airlied,
dri-devel, cain.cai, a.hajda, Laurent.pinchart, Yakir Yang, sam,
Jerome Brunet, zhengxing, linux-rockchip, dgreid, cychiang,
tzungbi, Jonas Karlman, jeffy.chen, eddie.cai, linux-arm-kernel,
Jernej Skrabec, dianders, daniel, enric.balletbo, kuankuan.y
From: Yakir Yang <ykk@rock-chips.com>
When transmitting IEC60985 linear PCM audio, we configure the
Aduio Sample Channel Status information in the IEC60958 frame.
The status bit is already available in iec.status of hdmi_codec_params.
This fix the issue that audio does not come out on some monitors
(e.g. LG 22CV241)
Note that these registers are only for interfaces:
I2S audio interface, General Purpose Audio (GPA), or AHB audio DMA
(AHBAUDDMA).
For S/PDIF interface this information comes from the stream.
Currently this function dw_hdmi_set_channel_status is only called
from dw-hdmi-i2s-audio in I2S setup.
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>
---
Change from v2 to v3:
1. Reuse what is already set in iec.status in hw_param.
2. Remove all useless definition of registers and values.
3. Note that the original sampling frequency is not written to
the channel status as we reuse create_iec958_consumer in pcm_iec958.c.
Without that it can still play audio fine.
.../drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 1 +
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 20 +++++++++++++++++++
drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 2 ++
include/drm/bridge/dw_hdmi.h | 1 +
4 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
index 34d8e837555f..20f4f92dd866 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
@@ -102,6 +102,7 @@ static int dw_hdmi_i2s_hw_params(struct device *dev, void *data,
}
dw_hdmi_set_sample_rate(hdmi, hparms->sample_rate);
+ dw_hdmi_set_channel_status(hdmi, hparms->iec.status);
dw_hdmi_set_channel_count(hdmi, hparms->channels);
dw_hdmi_set_channel_allocation(hdmi, hparms->cea.channel_allocation);
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index bd65d0479683..aa7efd4da1c8 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -582,6 +582,26 @@ static unsigned int hdmi_compute_n(unsigned int freq, unsigned long pixel_clk)
return n;
}
+/*
+ * When transmitting IEC60958 linear PCM audio, these registers allow to
+ * configure the channel status information of all the channel status
+ * bits in the IEC60958 frame. For the moment this configuration is only
+ * used when the I2S audio interface, General Purpose Audio (GPA),
+ * or AHB audio DMA (AHBAUDDMA) interface is active
+ * (for S/PDIF interface this information comes from the stream).
+ */
+void dw_hdmi_set_channel_status(struct dw_hdmi *hdmi,
+ u8 *channel_status)
+{
+ /*
+ * Set channel status register for frequency and word length.
+ * Use default values for other registers.
+ */
+ hdmi_writeb(hdmi, channel_status[3], HDMI_FC_AUDSCHNLS7);
+ hdmi_writeb(hdmi, channel_status[4], HDMI_FC_AUDSCHNLS8);
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_set_channel_status);
+
static void hdmi_set_clk_regenerator(struct dw_hdmi *hdmi,
unsigned long pixel_clk, unsigned int sample_rate)
{
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
index 6988f12d89d9..fcff5059db24 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
@@ -158,6 +158,8 @@
#define HDMI_FC_SPDDEVICEINF 0x1062
#define HDMI_FC_AUDSCONF 0x1063
#define HDMI_FC_AUDSSTAT 0x1064
+#define HDMI_FC_AUDSCHNLS7 0x106e
+#define HDMI_FC_AUDSCHNLS8 0x106f
#define HDMI_FC_DATACH0FILL 0x1070
#define HDMI_FC_DATACH1FILL 0x1071
#define HDMI_FC_DATACH2FILL 0x1072
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index cf528c289857..4b3e863c4f8a 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -156,6 +156,7 @@ void dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense);
void dw_hdmi_set_sample_rate(struct dw_hdmi *hdmi, unsigned int rate);
void dw_hdmi_set_channel_count(struct dw_hdmi *hdmi, unsigned int cnt);
+void dw_hdmi_set_channel_status(struct dw_hdmi *hdmi, u8 *channel_status);
void dw_hdmi_set_channel_allocation(struct dw_hdmi *hdmi, unsigned int ca);
void dw_hdmi_audio_enable(struct dw_hdmi *hdmi);
void dw_hdmi_audio_disable(struct dw_hdmi *hdmi);
--
2.23.0.162.g0b9fbb3734-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 2/2] KVM: arm/arm64: Print the EC hex value with its exact width
From: Marc Zyngier @ 2019-09-11 8:31 UTC (permalink / raw)
To: Zenghui Yu
Cc: suzuki.poulose, linux-kernel, james.morse, julien.thierry.kdev,
wanghaibin.wang, kvmarm, linux-arm-kernel
In-Reply-To: <1568169216-12632-3-git-send-email-yuzenghui@huawei.com>
On Wed, 11 Sep 2019 03:33:36 +0100,
Zenghui Yu <yuzenghui@huawei.com> wrote:
>
> EC is the bits [31:26] of ESR_ELx on arm64 (HSR on arm). Print the
> hex value with its exact width (8).
>
> Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
> ---
> virt/kvm/arm/trace.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/virt/kvm/arm/trace.h b/virt/kvm/arm/trace.h
> index 204d210d01c2..022b0a060034 100644
> --- a/virt/kvm/arm/trace.h
> +++ b/virt/kvm/arm/trace.h
> @@ -42,7 +42,7 @@ TRACE_EVENT(kvm_exit,
> __entry->vcpu_pc = vcpu_pc;
> ),
>
> - TP_printk("%s: HSR_EC: 0x%04x (%s), PC: 0x%08lx",
> + TP_printk("%s: HSR_EC: 0x%02x (%s), PC: 0x%08lx",
> __print_symbolic(__entry->ret, kvm_arm_exception_type),
> __entry->esr_ec,
> __print_symbolic(__entry->esr_ec, kvm_arm_exception_class),
Although you're right that 8 bits ought to be enough, this is a change
to the output of the tracepoint, which userspace could (does?) parse.
I'm thus reluctant to change anything there, knowing that we don't
lose any information, and just print two extra zeroes.
Am I missing anything?
Thanks,
M.
--
Jazz is not dead, it just smells funny.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: Add support for Realtek SOC
From: Masahiro Yamada @ 2019-09-11 8:34 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jason A . Donenfeld, CY_Huang[黃鉦晏],
Linus Walleij, Stefan Agner, Benjamin Gaignard,
Mauro Carvalho Chehab, Phinex Hung, Rob Herring,
Lorenzo Pieralisi, Russell King, Mike Rapoport, Thierry Reding,
jamestai.sky@gmail.com, Doug Anderson, Linux ARM,
James Tai[戴志峰], Ard Biesheuvel,
Nicolas Pitre, Nick Desaulniers, linux-kernel@vger.kernel.org,
Paul Burton, Andreas Färber
In-Reply-To: <CAK8P3a39VrC1Xn+HZc5gvh1-nUYKywDGjTfO9WPCqim89WtGAg@mail.gmail.com>
On Wed, Sep 11, 2019 at 5:17 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Wed, Sep 11, 2019 at 9:46 AM James Tai[戴志峰] <james.tai@realtek.com> wrote:
> > > Subject: Re: [PATCH] ARM: Add support for Realtek SOC
>
> > > > @@ -148,6 +148,7 @@ endif
> > > > textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
> > > > textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
> > > > textofs-$(CONFIG_ARCH_MESON) := 0x00208000
> > > > +textofs-$(CONFIG_ARCH_REALTEK) := 0x00208000
> > > > textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
> > >
> > > Can you explain why this is needed for your platform?
> > >
> > We need to reserve memory (0x00000000 ~ 0x001B0000) for rom and boot code.
>
> Ok.
I do not like this much.
This platform is ARCH_MULTI_V7.
ARM_PATCH_PHYS_VIRT allows you to place the kernel image
anywhere in memory as long as the base is aligned at 16MB.
The minimum 'textofs-y := 0x0008000' + extra 16MB offset
will create a space (0x00000000 ~ 0x01008000).
This is more than needed, but it is not a big deal
to waste some megabytes of memory.
--
Best Regards
Masahiro Yamada
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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