Re: [PATCH v1 11/30] drm/tegra: dc: Support OPP and SoC core voltage scaling
On Tue, Nov 10, 2020 at 09:29:45PM +0100, Thierry Reding wrote:
> > + err = dev_pm_opp_of_add_table(dc->dev);
> > + if (err) {
> > + dev_err(dc->dev, "failed to add OPP table: %d\n", err);
> > + goto put_hw;
> > + }
> > +
> > + err = devm_add_action(dc->dev, tegra_dc_deinit_opp_table, dc);
> > + if (err)
> > + goto remove_table;
>
> Do these functions return positive values? If not, I'd prefer if this
> check was more explicit (i.e. err < 0) for consistency with the rest of
> this code.
>
Isn't it the other way around? It's only when the check is explicitly
for "if (ret < 0)" that we have to wonder about positives. If the codes
says "if (ret)" then we know that it doesn't return positive values and
every non-zero is an error.
In the kernel "if (ret)" is way more popular than "if (ret < 0)":
$ git grep 'if (\(ret\|rc\|err\))' | wc -l
92927
$ git grep 'if (\(ret\|rc\|err\) < 0)' | wc -l
36577
And some of those are places where "ret" can be positive so we are
forced to use the "if (ret < 0)" format.
Checking for "if (ret)" is easier from a static analysis perspective.
If it's one style is used consistently then they're the same but when
there is a mismatch the "if (ret < 0) " will trigger a false positive
and the "if (ret) " will not.
int var;
ret = frob(&var);
if (ret < 0)
return ret;
Smatch thinks positive returns are not handled so it complains that
"var can be uninitialized".
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1 00/30] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs
On Sun, 8 Nov 2020 at 13:19, Dmitry Osipenko wrote: > > 05.11.2020 18:22, Dmitry Osipenko пишет: > > 05.11.2020 12:45, Ulf Hansson пишет: > > ... > >> I need some more time to review this, but just a quick check found a > >> few potential issues... > > > > Thank you for starting the review! I'm pretty sure it will take a couple > > revisions until all the questions will be resolved :) > > > >> The "core-supply", that you specify as a regulator for each > >> controller's device node, is not the way we describe power domains. > >> Instead, it seems like you should register a power-domain provider > >> (with the help of genpd) and implement the ->set_performance_state() > >> callback for it. Each device node should then be hooked up to this > >> power-domain, rather than to a "core-supply". For DT bindings, please > >> have a look at Documentation/devicetree/bindings/power/power-domain.yaml > >> and Documentation/devicetree/bindings/power/power_domain.txt. > >> > >> In regards to the "sync state" problem (preventing to change > >> performance states until all consumers have been attached), this can > >> then be managed by the genpd provider driver instead. > > > > I'll need to take a closer look at GENPD, thank you for the suggestion. > > > > Sounds like a software GENPD driver which manages clocks and voltages > > could be a good idea, but it also could be an unnecessary > > over-engineering. Let's see.. > > > > Hello Ulf and all, > > I took a detailed look at the GENPD and tried to implement it. Here is > what was found: > > 1. GENPD framework doesn't aggregate performance requests from the > attached devices. This means that if deviceA requests performance state > 10 and then deviceB requests state 3, then framework will set domain's > state to 3 instead of 10. > > https://elixir.bootlin.com/linux/v5.10-rc2/source/drivers/base/power/domain.c#L376 As Viresh also stated, genpd does aggregate the votes. It even performs aggregation hierarchy (a genpd is allowed to have parent(s) to model a topology). > > 2. GENPD framework has a sync() callback in the genpd.domain structure, > but this callback isn't allowed to be used by the GENPD implementation. > The GENPD framework always overrides that callback for its own needs. > Hence GENPD doesn't allow to solve the bootstrapping > state-synchronization problem in a nice way. > > https://elixir.bootlin.com/linux/v5.10-rc2/source/drivers/base/power/domain.c#L2606 That ->sync() callback isn't the callback you are looking for, it's a PM domain specific callback - and has other purposes. To solve the problem you refer to, your genpd provider driver (a platform driver) should assign its ->sync_state() callback. The ->sync_state() callback will be invoked, when all consumer devices have been attached (and probed) to their corresponding provider. You may have a look at drivers/cpuidle/cpuidle-psci-domain.c, to see an example of how this works. If there is anything unclear, just tell me and I will try to help. > > 3. Tegra doesn't have a dedicated hardware power-controller for the core > domain, instead there is only an external voltage regulator. Hence we > will need to create a phony device-tree node for the virtual power > domain, which is probably a wrong thing to do. No, this is absolutely the correct thing to do. This isn't a virtual power domain, it's a real power domain. You only happen to model the control of it as a regulator, as it fits nicely with that for *this* SoC. Don't get me wrong, that's fine as long as the supply is specified only in the power-domain provider node. On another SoC, you might have a different FW interface for the power domain provider that doesn't fit well with the regulator. When that happens, all you need to do is to implement a new power domain provider and potentially re-define the power domain topology. More importantly, you don't need to re-invent yet another slew of device specific bindings - for each SoC. > > === > > Perhaps it should be possible to create some hacks to work around > bullets 2 and 3 in order to achieve what we need for DVFS on Tegra, but > bullet 1 isn't solvable without changing how the GENPD core works. > > Altogether, the GENPD in its current form is a wrong abstraction for a > system-wide DVFS in a case where multiple devices share power domain and > this domain is a voltage regulator. The regulator framework is the > correct abstraction in this case for today. Well, I admit it's a bit complex. But it solves the problem in a nicely abstracted way that should work for everybody, at least in my opinion. Although, let's not exclude that there are pieces missing in genpd or the opp layer, as this DVFS feature is rather new - but then we should just extend/fix it. Kind regards Uffe ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1 01/30] dt-bindings: host1x: Document OPP and voltage regulator properties
On Thu, 5 Nov 2020 at 00:44, Dmitry Osipenko wrote: > > Document new DVFS OPP table and voltage regulator properties of the > Host1x bus and devices sitting on the bus. > > Signed-off-by: Dmitry Osipenko > --- > .../display/tegra/nvidia,tegra20-host1x.txt | 56 +++ > 1 file changed, 56 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt > b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt > index 34d993338453..0593c8df70bb 100644 > --- > a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt > +++ > b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt > @@ -20,6 +20,18 @@ Required properties: > - reset-names: Must include the following entries: >- host1x > > +Optional properties: > +- operating-points-v2: See ../bindings/opp/opp.txt for details. > +- core-supply: Phandle of voltage regulator of the SoC "core" power domain. > + > +For each opp entry in 'operating-points-v2' table of host1x and its modules: > +- opp-supported-hw: One bitfield indicating: > + On Tegra20: SoC process ID mask > + On Tegra30+: SoC speedo ID mask > + > + A bitwise AND is performed against the value and if any bit > + matches, the OPP gets enabled. > + > Each host1x client module having to perform DMA through the Memory Controller > should have the interconnect endpoints set to the Memory Client and External > Memory respectively. > @@ -45,6 +57,8 @@ of the following host1x client modules: >- interconnect-names: Must include name of the interconnect path for each > interconnect entry. Consult TRM documentation for information about > available memory clients, see MEMORY CONTROLLER section. > + - core-supply: Phandle of voltage regulator of the SoC "core" power domain. > + - operating-points-v2: See ../bindings/opp/opp.txt for details. > As discussed in the thread for the cover-letter. We already have DT bindings for power-domains (providers and consumers). Please use them instead of adding SoC specific bindings to each peripheral device. [...] Kind regards Uffe ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1 11/30] drm/tegra: dc: Support OPP and SoC core voltage scaling
On Wed, Nov 11, 2020 at 12:23:41AM +0300, Dmitry Osipenko wrote: > 10.11.2020 23:32, Mark Brown пишет: > >>> + if (!device_property_present(dc->dev, "core-supply")) > >>> + return; > >> This is a potentially heavy operation, so I think we should avoid that > >> here. How about you use devm_regulator_get_optional() in ->probe()? That > >> returns -ENODEV if no regulator was specified, in which case you can set > >> dc->core_reg = NULL and use that as the condition here. > > Or enumerate the configurable voltages after getting the regulator and > > handle that appropriately which would be more robust in case there's > > missing or unusual constraints. > I already changed that code to use regulator_get_optional() for v2. That doesn't look entirely appropriate given that the core does most likely require some kind of power to operate. > Regarding the enumerating supported voltage.. I think this should be > done by the OPP core, but regulator core doesn't work well if > regulator_get() is invoked more than one time for the same device, at > least there is a loud debugfs warning about an already existing I don't understand why this would be an issue - if nothing else the core could just offer an interface to trigger the check. > directory for a regulator. It's easy to check whether the debug > directory exists before creating it, like thermal framework does it for > example, but then there were some other more difficult issues.. I don't > recall what they were right now. Perhaps will be easier to simply get a > error from regulator_set_voltage() for now because it shouldn't ever > happen in practice, unless device-tree has wrong constraints. The constraints might not be wrong, there might be some board which has a constraint somewhere for signature.asc Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Purchase|Outsorucing-Department|
Good morning, I am writing again to inform you that I am yet to receives your email correspondent concerning the previous email I sent to you. Please let me know if you will be able to sale the product's to my director directly. Could you kindly reply, is urgent for business. Regards, Ghana Agricultural Project Commission Purchase|Outsorucing-Department| GGBGZFHNEZBYLRYIDDZYDUPIFDXNRYSCPDGFBE ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Purchase|Outsorucing-Department|
Good morning, I am writing again to inform you that I am yet to receives your email correspondent concerning the previous email I sent to you. Please let me know if you will be able to sale the product's to my director directly. Could you kindly reply, is urgent for business. Regards, Ghana Agricultural Project Commission Purchase|Outsorucing-Department| GGBGZFHNEZBYLRYIDDZYDUPIFDXNRYSCPDGFBE ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/7] sunxi: Remove the calls to dma_direct_set_offset
On 06/11/2020 16:14, Maxime Ripard wrote: > Hi, > > Here's an attempt to removing the dma_direct_set_offset calls we have in > numerous drivers and move all those quirks into a global notifier as suggested > by Robin. For patches 4-7: Acked-by: Hans Verkuil It's fine by me if this series is merged via the drm subsystem. Regards, Hans > > Let me know what you think, > Maxime > > Maxime Ripard (7): > drm/sun4i: backend: Fix probe failure with multiple backends > soc: sunxi: Deal with the MBUS DMA offsets in a central place > drm/sun4i: backend: Remove the MBUS quirks > media: sun4i: Remove the MBUS quirks > media: sun6i: Remove the MBUS quirks > media: cedrus: Remove the MBUS quirks > media: sun8i-di: Remove the call to of_dma_configure > > drivers/gpu/drm/sun4i/sun4i_backend.c | 13 -- > .../platform/sunxi/sun4i-csi/sun4i_csi.c | 27 > .../platform/sunxi/sun6i-csi/sun6i_csi.c | 17 --- > .../media/platform/sunxi/sun8i-di/sun8i-di.c | 4 - > drivers/soc/sunxi/Kconfig | 8 ++ > drivers/soc/sunxi/Makefile| 1 + > drivers/soc/sunxi/sunxi_mbus.c| 132 ++ > drivers/staging/media/sunxi/cedrus/cedrus.c | 1 - > drivers/staging/media/sunxi/cedrus/cedrus.h | 3 - > .../staging/media/sunxi/cedrus/cedrus_hw.c| 18 --- > 10 files changed, 141 insertions(+), 83 deletions(-) > create mode 100644 drivers/soc/sunxi/sunxi_mbus.c > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 6/7] staging: mt7621-dts: make use of new 'mt7621-pll' and 'mt7621-clk'
Clocks for SoC mt7621 have been properly integrated so there is
no need to declare fixed clocks at all in the device tree. Remove
all of them, add new device tree nodes for new mt7621-pll and mt7621-clk
and update the rest of the nodes to use them.
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt7621-dts/gbpc1.dts | 11
drivers/staging/mt7621-dts/mt7621.dtsi | 71 --
2 files changed, 34 insertions(+), 48 deletions(-)
diff --git a/drivers/staging/mt7621-dts/gbpc1.dts
b/drivers/staging/mt7621-dts/gbpc1.dts
index a7c0d3115d72..7716d0efe524 100644
--- a/drivers/staging/mt7621-dts/gbpc1.dts
+++ b/drivers/staging/mt7621-dts/gbpc1.dts
@@ -100,17 +100,6 @@ partition@5 {
};
};
-&sysclock {
- compatible = "fixed-clock";
- /* This is normally 1/4 of cpuclock */
- clock-frequency = <22500>;
-};
-
-&cpuclock {
- compatible = "fixed-clock";
- clock-frequency = <9>;
-};
-
&pcie {
pinctrl-names = "default";
pinctrl-0 = <&pcie_pins>;
diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi
b/drivers/staging/mt7621-dts/mt7621.dtsi
index 82aa93634eda..e615139d2ccb 100644
--- a/drivers/staging/mt7621-dts/mt7621.dtsi
+++ b/drivers/staging/mt7621-dts/mt7621.dtsi
@@ -1,5 +1,6 @@
#include
#include
+#include
/ {
#address-cells = <1>;
@@ -27,26 +28,16 @@ aliases {
serial0 = &uartlite;
};
- cpuclock: cpuclock@0 {
- #clock-cells = <0>;
- compatible = "fixed-clock";
-
- /* FIXME: there should be way to detect this */
- clock-frequency = <88000>;
- };
-
- sysclock: sysclock@0 {
- #clock-cells = <0>;
- compatible = "fixed-clock";
-
- /* This is normally 1/4 of cpuclock */
- clock-frequency = <22000>;
+ pll: pll {
+ compatible = "mediatek,mt7621-pll";
+ #clock-cells = <1>;
+ clock-output-names = "cpu", "ahb", "apb";
};
- mmc_clock: mmc_clock@0 {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <4800>;
+ clkctrl: clkctrl {
+ compatible = "mediatek,mt7621-clk";
+ #clock-cells = <1>;
+ ralink,sysctl = <&sysc>;
};
mmc_fixed_3v3: fixedregulator@0 {
@@ -76,7 +67,7 @@ palmbus: palmbus@1E00 {
#size-cells = <1>;
sysc: sysc@0 {
- compatible = "mtk,mt7621-sysc";
+ compatible = "mtk,mt7621-sysc", "syscon";
reg = <0x0 0x100>;
};
@@ -100,8 +91,8 @@ i2c: i2c@900 {
compatible = "mediatek,mt7621-i2c";
reg = <0x900 0x100>;
- clocks = <&sysclock>;
-
+ clocks = <&clkctrl MT7621_CLK_I2C>;
+ clock-names = "i2c";
resets = <&rstctrl 16>;
reset-names = "i2c";
@@ -118,8 +109,8 @@ i2s: i2s@a00 {
compatible = "mediatek,mt7621-i2s";
reg = <0xa00 0x100>;
- clocks = <&sysclock>;
-
+ clocks = <&clkctrl MT7621_CLK_I2S>;
+ clock-names = "i2s";
resets = <&rstctrl 17>;
reset-names = "i2s";
@@ -155,8 +146,8 @@ uartlite: uartlite@c00 {
compatible = "ns16550a";
reg = <0xc00 0x100>;
- clocks = <&sysclock>;
- clock-frequency = <5000>;
+ clocks = <&clkctrl MT7621_CLK_UART1>;
+ clock-names = "uart1";
interrupt-parent = <&gic>;
interrupts = ;
@@ -172,7 +163,7 @@ spi0: spi@b00 {
compatible = "ralink,mt7621-spi";
reg = <0xb00 0x100>;
- clocks = <&sysclock>;
+ clocks = <&pll MT7621_CLK_AHB>;
resets = <&rstctrl 18>;
reset-names = "spi";
@@ -188,6 +179,8 @@ gdma: gdma@2800 {
compatible = "ralink,rt3883-gdma";
reg = <0x2800 0x800>;
+ clocks = <&clkctrl MT7621_CLK_GDMA>;
+ clock-names = "gdma";
resets = <&rstctrl 14>;
reset-names = "dma";
@@ -205,6 +198,8 @@ hsdma: hsdma@7000 {
compatible = "mediatek,mt7621-hsdma";
reg = <0x7000 0x1000>;
+ clocks = <&clkctrl MT7621_CLK_HSDMA>;
+ clock-names = "hsdma";
[PATCH 4/7] MIPS: ralink: add clock device providing cpu/ahb/apb clock for mt7621
For a long time the mt7621 uses a fixed cpu clock which causes a problem
if the cpu frequency is not 880MHz.
This patch adds cpu/ahb/apb clock calculation code and binds clocks to
mt7621-pll node.
Adapted from OpenWrt:
c7ca224299 ramips: fix cpu clock of mt7621 and add dt clk devices
Signed-off-by: Weijie Gao
Signed-off-by: Chuanhong Guo
Signed-off-by: Sergio Paracuellos
---
arch/mips/include/asm/mach-ralink/mt7621.h | 20 +
arch/mips/ralink/mt7621.c | 87 ++
2 files changed, 107 insertions(+)
diff --git a/arch/mips/include/asm/mach-ralink/mt7621.h
b/arch/mips/include/asm/mach-ralink/mt7621.h
index e1af1ba50bd8..a9f3febddf1c 100644
--- a/arch/mips/include/asm/mach-ralink/mt7621.h
+++ b/arch/mips/include/asm/mach-ralink/mt7621.h
@@ -17,6 +17,10 @@
#define SYSC_REG_CHIP_REV 0x0c
#define SYSC_REG_SYSTEM_CONFIG00x10
#define SYSC_REG_SYSTEM_CONFIG10x14
+#define SYSC_REG_CLKCFG0 0x2c
+#define SYSC_REG_CUR_CLK_STS 0x44
+
+#define MEMC_REG_CPU_PLL 0x648
#define CHIP_REV_PKG_MASK 0x1
#define CHIP_REV_PKG_SHIFT 16
@@ -24,6 +28,22 @@
#define CHIP_REV_VER_SHIFT 8
#define CHIP_REV_ECO_MASK 0xf
+#define XTAL_MODE_SEL_MASK 0x7
+#define XTAL_MODE_SEL_SHIFT6
+
+#define CPU_CLK_SEL_MASK 0x3
+#define CPU_CLK_SEL_SHIFT 30
+
+#define CUR_CPU_FDIV_MASK 0x1f
+#define CUR_CPU_FDIV_SHIFT 8
+#define CUR_CPU_FFRAC_MASK 0x1f
+#define CUR_CPU_FFRAC_SHIFT0
+
+#define CPU_PLL_PREDIV_MASK0x3
+#define CPU_PLL_PREDIV_SHIFT 12
+#define CPU_PLL_FBDIV_MASK 0x7f
+#define CPU_PLL_FBDIV_SHIFT4
+
#define MT7621_DRAM_BASE0x0
#define MT7621_DDR2_SIZE_MIN 32
#define MT7621_DDR2_SIZE_MAX 256
diff --git a/arch/mips/ralink/mt7621.c b/arch/mips/ralink/mt7621.c
index ca0ac607b0f3..4fce37e5ea7a 100644
--- a/arch/mips/ralink/mt7621.c
+++ b/arch/mips/ralink/mt7621.c
@@ -9,12 +9,17 @@
#include
#include
#include
+#include
+#include
+#include
+#include
#include
#include
#include
#include
#include
+#include
#include
@@ -105,11 +110,93 @@ static struct rt2880_pmx_group mt7621_pinmux_data[] = {
{ 0 }
};
+static struct clk *clks[MT7621_CLK_MAX];
+static struct clk_onecell_data clk_data = {
+ .clks = clks,
+ .clk_num = ARRAY_SIZE(clks),
+};
+
phys_addr_t mips_cpc_default_phys_base(void)
{
panic("Cannot detect cpc address");
}
+static struct clk *__init mt7621_add_sys_clkdev(
+ const char *id, const char *parent_id, unsigned long rate)
+{
+ struct clk *clk;
+ int err;
+
+ clk = clk_register_fixed_rate(NULL, id, parent_id, 0, rate);
+ if (IS_ERR(clk))
+ panic("failed to allocate %s clock structure", id);
+
+ err = clk_register_clkdev(clk, id, NULL);
+ if (err)
+ panic("unable to register %s clock device", id);
+
+ return clk;
+}
+
+#define MHZ(x) ((x) * 1000 * 1000)
+
+void __init ralink_clk_init(void)
+{
+ u32 syscfg, xtal_sel, clkcfg, clk_sel, curclk, ffiv, ffrac;
+ u32 pll, prediv, fbdiv;
+ u32 xtal_clk, cpu_clk, ahb_clk, apb_clk;
+ static const u32 prediv_tbl[] = { 0, 1, 2, 2 };
+
+ syscfg = rt_sysc_r32(SYSC_REG_SYSTEM_CONFIG0);
+ xtal_sel = (syscfg >> XTAL_MODE_SEL_SHIFT) & XTAL_MODE_SEL_MASK;
+
+ clkcfg = rt_sysc_r32(SYSC_REG_CLKCFG0);
+ clk_sel = (clkcfg >> CPU_CLK_SEL_SHIFT) & CPU_CLK_SEL_MASK;
+
+ curclk = rt_sysc_r32(SYSC_REG_CUR_CLK_STS);
+ ffiv = (curclk >> CUR_CPU_FDIV_SHIFT) & CUR_CPU_FDIV_MASK;
+ ffrac = (curclk >> CUR_CPU_FFRAC_SHIFT) & CUR_CPU_FFRAC_MASK;
+
+ if (xtal_sel <= 2)
+ xtal_clk = MHZ(20);
+ else if (xtal_sel <= 5)
+ xtal_clk = MHZ(40);
+ else
+ xtal_clk = MHZ(25);
+
+ switch (clk_sel) {
+ case 0:
+ cpu_clk = MHZ(500);
+ break;
+ case 1:
+ pll = rt_memc_r32(MEMC_REG_CPU_PLL);
+ fbdiv = (pll >> CPU_PLL_FBDIV_SHIFT) & CPU_PLL_FBDIV_MASK;
+ prediv = (pll >> CPU_PLL_PREDIV_SHIFT) & CPU_PLL_PREDIV_MASK;
+ cpu_clk = ((fbdiv + 1) * xtal_clk) >> prediv_tbl[prediv];
+ break;
+ default:
+ cpu_clk = xtal_clk;
+ }
+
+ cpu_clk = cpu_clk / ffiv * ffrac;
+ ahb_clk = cpu_clk / 4;
+ apb_clk = MHZ(50);
+
+ clks[MT7621_CLK_CPU] = mt7621_add_sys_clkdev("cpu", NULL, cpu_clk);
+ clks[MT7621_CLK_AHB] = mt7621_add_sys_clkdev("ahb", NULL, ahb_clk);
+ clks[MT7621_CLK_APB] = mt7621_add_sys_clkdev("apb", NULL, apb_clk);
+
+ pr_info("CPU Clock: %dMHz\n", cpu_clk / 100);
+ mips_hpt_frequency = cpu_clk / 2;
+}
+
+static void __init mt7621_clocks_in
[PATCH 1/7] dt-bindings: clock: add dt binding header for mt7621 clocks
Adds dt binding header for 'mediatek,mt7621-pll' PLL controller and for 'mediatek,mt7621-clk' clock gates. Signed-off-by: Sergio Paracuellos --- include/dt-bindings/clock/mt7621-clk.h | 39 ++ 1 file changed, 39 insertions(+) create mode 100644 include/dt-bindings/clock/mt7621-clk.h diff --git a/include/dt-bindings/clock/mt7621-clk.h b/include/dt-bindings/clock/mt7621-clk.h new file mode 100644 index ..8fccfa514185 --- /dev/null +++ b/include/dt-bindings/clock/mt7621-clk.h @@ -0,0 +1,39 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Author: Sergio Paracuellos + */ + +#ifndef _DT_BINDINGS_CLK_MT7621_H +#define _DT_BINDINGS_CLK_MT7621_H + +/* SYS CLOCKS */ +#define MT7621_CLK_CPU 0 +#define MT7621_CLK_AHB 1 +#define MT7621_CLK_APB 2 +#define MT7621_CLK_MAX 3 + +/* CLOCK GATES */ +#define MT7621_CLK_HSDMA 0 +#define MT7621_CLK_FE 1 +#define MT7621_CLK_SP_DIVTX2 +#define MT7621_CLK_TIMER 3 +#define MT7621_CLK_INT 4 +#define MT7621_CLK_MC 5 +#define MT7621_CLK_PCM 6 +#define MT7621_CLK_PIO 7 +#define MT7621_CLK_GDMA8 +#define MT7621_CLK_NAND9 +#define MT7621_CLK_I2C 10 +#define MT7621_CLK_I2S 11 +#define MT7621_CLK_SPI 12 +#define MT7621_CLK_UART1 13 +#define MT7621_CLK_UART2 14 +#define MT7621_CLK_UART3 15 +#define MT7621_CLK_ETH 16 +#define MT7621_CLK_PCIE0 17 +#define MT7621_CLK_PCIE1 18 +#define MT7621_CLK_PCIE2 19 +#define MT7621_CLK_CRYPTO 20 +#define MT7621_CLK_SHXC21 + +#endif /* _DT_BINDINGS_CLK_MT7621_H */ -- 2.25.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/7] dt: bindings: add mt7621-clk device tree binding documentation
Adds device tree binding documentation for clock gates in the
MT7621 SOC.
Signed-off-by: Sergio Paracuellos
---
.../bindings/clock/mediatek,mt7621-clk.yaml | 52 +++
1 file changed, 52 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
b/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
new file mode 100644
index ..89886b066849
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/mediatek,mt7621-clk.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MT7621 Bus Gates Clock Device Tree Bindings
+
+maintainers:
+ - Sergio Paracuellos
+
+description: |
+ The MT7621 can gate SoC device clocks.
+
+ Each clock gate is assigned an identifier and client nodes use this
identifier
+ to specify the clock gate which they consume.
+
+ All these identifiers could be found in:
+ [1]: .
+
+properties:
+ compatible:
+const: mediatek,mt7621-clk
+
+ "#clock-cells":
+description:
+ The first cell indicates the clock gate number, see [1] for available
+ clocks.
+const: 1
+
+ ralink,sysctl:
+$ref: /schemas/types.yaml#/definitions/phandle
+description:
+ phandle to the syscon which is in the same address area with syscon
+ device.
+
+required:
+ - compatible
+ - '#clock-cells'
+ - ralink,sysctl
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+clkctrl {
+ compatible = "mediatek,mt7621-clk";
+ #clock-cells = <1>;
+ ralink,sysctl = <&sysc>;
+};
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/7] dt: bindings: add mt7621-pll device tree binding documentation
Adds device tree binding documentation for PLL controller in
the MT7621 SOC.
Signed-off-by: Sergio Paracuellos
---
.../bindings/clock/mediatek,mt7621-pll.yaml | 51 +++
1 file changed, 51 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/mediatek,mt7621-pll.yaml
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7621-pll.yaml
b/Documentation/devicetree/bindings/clock/mediatek,mt7621-pll.yaml
new file mode 100644
index ..ef58411065e4
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt7621-pll.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/mediatek,mt7621-pll.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MT7621 PLL Controller Device Tree Bindings
+
+maintainers:
+ - Sergio Paracuellos
+
+
+description: |
+ The PLL Controller provides the cpu clock as well as derived
+ clock for the bus and the peripherals.
+
+ Each clock is assigned an identifier and client nodes use this identifier
+ to specify the clock which they consume.
+
+ All these identifiers could be found in:
+ [1]: .
+
+properties:
+ compatible:
+const: mediatek,mt7621-pll
+
+ "#clock-cells":
+description:
+ The first cell indicates the clock number, see [1] for available
+ clocks.
+const: 1
+
+ clock-output-names:
+maxItems: 3
+
+required:
+ - compatible
+ - '#clock-cells'
+ - clock-output-names
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+pll {
+ compatible = "mediatek,mt7621-pll";
+ #clock-cells = <1>;
+ clock-output-names = "cpu", "ahb", "apb";
+};
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 7/7] MAINTAINERS: add MT7621 CLOCK maintainer
Adding myself as maintainer for mt7621 clock driver. Signed-off-by: Sergio Paracuellos --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index f1f088a29bc2..c34c12d62355 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11142,6 +11142,14 @@ L: linux-wirel...@vger.kernel.org S: Maintained F: drivers/net/wireless/mediatek/mt7601u/ +MEDIATEK MT7621 CLOCK DRIVER +M: Sergio Paracuellos +S: Maintained +F: Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml +F: Documentation/devicetree/bindings/clock/mediatek,mt7621-pll.yaml +F: arch/mips/ralink/mt7621.c +F: drivers/clk/ralink/clk-mt7621.c + MEDIATEK MT7621/28/88 I2C DRIVER M: Stefan Roese L: linux-...@vger.kernel.org -- 2.25.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 5/7] clk: ralink: add clock gate driver for mt7621 SoC
In mt7621 SoC register 'SYSC_REG_CPLL_CLKCFG1' allows to handle a bunch of gates to enable/disable clocks for all or some ip cores. Add a driver to properly handle them. Parent clocks for this gates are not documented at all in the SoC documentation so all of them have been assumed looking into the clock frequencies used in its related driver code. There are three main clocks which are "cpu", "ahb" and "apb" from the 'mt7621-pll'. The following parents are set to each GATE: * "hsdma": "ahb" * "fe": "ahb" * "sp_divtx": "ahb" * "timer": "cpu" * "int": "cpu" * "mc": "ahb" * "pcm": "ahb" * "pio": "ahb" * "gdma": "ahb" * "nand": "ahb" * "i2c": "ahb" * "i2s": "ahb" * "spi": "ahb" * "uart1": "apb" * "uart2": "apb" * "uart3": "apb" * "eth": "ahb" * "pcie0": "ahb" * "pcie1": "ahb" * "pcie2": "ahb" * "crypto": "ahb" * "shxc": "ahb" With this information the clk driver will provide gate functionality from a a set of hardcoded clocks allowing to define a nice device tree without fixed clocks. Signed-off-by: Sergio Paracuellos --- drivers/clk/Kconfig | 1 + drivers/clk/Makefile| 1 + drivers/clk/ralink/Kconfig | 14 ++ drivers/clk/ralink/Makefile | 2 + drivers/clk/ralink/clk-mt7621.c | 258 5 files changed, 276 insertions(+) create mode 100644 drivers/clk/ralink/Kconfig create mode 100644 drivers/clk/ralink/Makefile create mode 100644 drivers/clk/ralink/clk-mt7621.c diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index c715d4681a0b..5f94c4329033 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -372,6 +372,7 @@ source "drivers/clk/mediatek/Kconfig" source "drivers/clk/meson/Kconfig" source "drivers/clk/mvebu/Kconfig" source "drivers/clk/qcom/Kconfig" +source "drivers/clk/ralink/Kconfig" source "drivers/clk/renesas/Kconfig" source "drivers/clk/rockchip/Kconfig" source "drivers/clk/samsung/Kconfig" diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index da8fcf147eb1..6578e167b047 100644 --- a/drivers/clk/Makefile +++ b/drivers/clk/Makefile @@ -100,6 +100,7 @@ obj-$(CONFIG_COMMON_CLK_NXP)+= nxp/ obj-$(CONFIG_MACH_PISTACHIO) += pistachio/ obj-$(CONFIG_COMMON_CLK_PXA) += pxa/ obj-$(CONFIG_COMMON_CLK_QCOM) += qcom/ +obj-y += ralink/ obj-y += renesas/ obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/ obj-$(CONFIG_COMMON_CLK_SAMSUNG) += samsung/ diff --git a/drivers/clk/ralink/Kconfig b/drivers/clk/ralink/Kconfig new file mode 100644 index ..7e8697327e0c --- /dev/null +++ b/drivers/clk/ralink/Kconfig @@ -0,0 +1,14 @@ +# SPDX-License-Identifier: GPL-2.0-only +# +# MediaTek Mt7621 Clock Driver +# +menu "Clock driver for mediatek mt7621 SoC" + depends on SOC_MT7621 || COMPILE_TEST + +config CLK_MT7621 + bool "Clock driver for MediaTek MT7621" + depends on SOC_MT7621 || COMPILE_TEST + default SOC_MT7621 + help + This driver supports MediaTek MT7621 basic clocks. +endmenu diff --git a/drivers/clk/ralink/Makefile b/drivers/clk/ralink/Makefile new file mode 100644 index ..cf6f9216379d --- /dev/null +++ b/drivers/clk/ralink/Makefile @@ -0,0 +1,2 @@ +# SPDX-License-Identifier: GPL-2.0 +obj-$(CONFIG_CLK_MT7621) += clk-mt7621.o diff --git a/drivers/clk/ralink/clk-mt7621.c b/drivers/clk/ralink/clk-mt7621.c new file mode 100644 index ..f7279d784a36 --- /dev/null +++ b/drivers/clk/ralink/clk-mt7621.c @@ -0,0 +1,258 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Mediatek MT7621 Clock gate Driver + * Author: Sergio Paracuellos + */ + +#include +#include +#include +#include +#include +#include +#include + +/* clock gate configuration register */ +#define SYSC_REG_CLKCFG1 0x30 + +/* Gate register enable bits */ +#define MT7621_HSDMA_CLK_ENBIT(5) +#define MT7621_FE_CLK_EN BIT(6) +#define MT7621_SP_DIVTX_CLK_EN BIT(7) +#define MT7621_TIMER_CLK_ENBIT(8) +#define MT7621_INT_CLK_EN BIT(9) +#define MT7621_MC_CLK_EN BIT(10) +#define MT7621_PCM_CLK_EN BIT(11) +#define MT7621_PIO_CLK_EN BIT(13) +#define MT7621_GDMA_CLK_EN BIT(14) +#define MT7621_NAND_CLK_EN BIT(15) +#define MT7621_I2C_CLK_EN BIT(16) +#define MT7621_I2S_CLK_EN BIT(17) +#define MT7621_SPI_CLK_EN BIT(18) +#define MT7621_UART1_CLK_ENBIT(19) +#define MT7621_UART2_CLK_ENBIT(20) +#define MT7621_UART3_CLK_ENBIT(21) +#define MT7621_ETH_CLK_EN BIT(23) +#define MT7621_PCIE0_CLK_ENBIT(24) +#define MT7621_PCIE1_CLK_ENBIT(25) +#define MT7621_PCIE2_CLK_ENBIT(26) +#define MT7621_CRYPTO_CLK_EN BIT(29) +#define MT7621_SHXC_CLK_EN BIT(30) + +struct mt7621_clk_provide
[PATCH 0/7] MIPS: ralink: add CPU clock detection and clock gate driver for MT7621
This patchset ports CPU clock detection for MT7621 from OpenWrt and adds a complete clock plan for the mt7621 SOC. The documentation for this SOC only talks about two registers regarding to the clocks: * SYSC_REG_CPLL_CLKCFG0 - provides some information about boostrapped refclock. PLL and dividers used for CPU and some sort of BUS (AHB?). * SYSC_REG_CPLL_CLKCFG1 - a banch of gates to enable/disable clocks for all or some ip cores. No documentation about a probably existant set of dividers for each ip core is included in the datasheets. So we cannot make anything better, AFAICT. Looking into driver code, there is another frequency which is used in some drivers (uart, sd...) which for any reason is always hardcoded to 50 MHz. Taking this into account this patchset provides three main fixed clocks to the SOC in 'mt7621-pll' which are: - "cpu": with detected frequency (900 MHz in my board). - "ahb": cpu / 4 = 225 Mhz. - "apb": 50 Mhz. PLL controller cannot be manipulatedbecause there is no info about how to do it. Because of this, there is nothing related with registers in the included binding. It also provides a clock gate driver 'mt7621-clk' as a platform driver to allow to enable and disable some clocks in the different ip cores. The parent clocks for this clock gates have also set taking into account existant device tree and driver code resulting in the followings: - "hsdma": "ahb" - "fe": "ahb" - "sp_divtx": "ahb" - "timer": "cpu" - "int": "cpu" - "mc": "ahb" - "pcm": "ahb" - "pio": "ahb" - "gdma": "ahb" - "nand": "ahb" - "i2c": "ahb" - "i2s": "ahb" - "spi": "ahb" - "uart1": "apb" - "uart2": "apb" - "uart3": "apb" - "eth": "ahb" - "pcie0": "ahb" - "pcie1": "ahb" - "pcie2": "ahb" - "crypto": "ahb" - "shxc": "ahb" There was a previous attempt of doing this here[0] but the author did not wanted to make assumptions of a clock plan for the platform. I do really want this to be upstreamed so according to the comments in previous attempt[0] from Oleksij Rempel I have tried to do this by myself. All of this patches have been tested in a GNUBee PC1 resulting in a working platform. [0]: https://www.lkml.org/lkml/2019/7/23/1044 Sergio Paracuellos (7): dt-bindings: clock: add dt binding header for mt7621 clocks dt: bindings: add mt7621-pll device tree binding documentation dt: bindings: add mt7621-clk device tree binding documentation MIPS: ralink: add clock device providing cpu/ahb/apb clock for mt7621 clk: ralink: add clock gate driver for mt7621 SoC staging: mt7621-dts: make use of new 'mt7621-pll' and 'mt7621-clk' MAINTAINERS: add MT7621 CLOCK maintainer .../bindings/clock/mediatek,mt7621-clk.yaml | 52 .../bindings/clock/mediatek,mt7621-pll.yaml | 51 MAINTAINERS | 8 + arch/mips/include/asm/mach-ralink/mt7621.h| 20 ++ arch/mips/ralink/mt7621.c | 87 ++ drivers/clk/Kconfig | 1 + drivers/clk/Makefile | 1 + drivers/clk/ralink/Kconfig| 14 + drivers/clk/ralink/Makefile | 2 + drivers/clk/ralink/clk-mt7621.c | 258 ++ drivers/staging/mt7621-dts/gbpc1.dts | 11 - drivers/staging/mt7621-dts/mt7621.dtsi| 71 +++-- include/dt-bindings/clock/mt7621-clk.h| 39 +++ 13 files changed, 567 insertions(+), 48 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt7621-pll.yaml create mode 100644 drivers/clk/ralink/Kconfig create mode 100644 drivers/clk/ralink/Makefile create mode 100644 drivers/clk/ralink/clk-mt7621.c create mode 100644 include/dt-bindings/clock/mt7621-clk.h -- 2.25.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/7] MIPS: ralink: add CPU clock detection and clock gate driver for MT7621
Hi! On Thu, Nov 12, 2020 at 12:30 AM Sergio Paracuellos wrote: > > This patchset ports CPU clock detection for MT7621 from OpenWrt > and adds a complete clock plan for the mt7621 SOC. > > The documentation for this SOC only talks about two registers > regarding to the clocks: > * SYSC_REG_CPLL_CLKCFG0 - provides some information about boostrapped > refclock. PLL and dividers used for CPU and some sort of BUS (AHB?). > * SYSC_REG_CPLL_CLKCFG1 - a banch of gates to enable/disable clocks for > all or some ip cores. > > No documentation about a probably existant set of dividers for each ip > core is included in the datasheets. So we cannot make anything better, > AFAICT. > > Looking into driver code, there is another frequency which is used in > some drivers (uart, sd...) which for any reason is always hardcoded to > 50 MHz. Taking this into account this patchset provides three main fixed > clocks to the SOC in 'mt7621-pll' which are: > - "cpu": with detected frequency (900 MHz in my board). > - "ahb": cpu / 4 = 225 Mhz. > - "apb": 50 Mhz. > > PLL controller cannot be manipulatedbecause there is no info about > how to do it. Because of this, there is nothing related with registers > in the included binding. > > It also provides a clock gate driver 'mt7621-clk' as a platform driver > to allow to enable and disable some clocks in the different ip cores. > The parent clocks for this clock gates have also set taking into account > existant device tree and driver code resulting in the followings: > - "hsdma": "ahb" > - "fe": "ahb" > - "sp_divtx": "ahb" > - "timer": "cpu" > - "int": "cpu" > - "mc": "ahb" > - "pcm": "ahb" > - "pio": "ahb" > - "gdma": "ahb" > - "nand": "ahb" > - "i2c": "ahb" > - "i2s": "ahb" > - "spi": "ahb" > - "uart1": "apb" > - "uart2": "apb" > - "uart3": "apb" > - "eth": "ahb" > - "pcie0": "ahb" > - "pcie1": "ahb" > - "pcie2": "ahb" > - "crypto": "ahb" > - "shxc": "ahb" > > There was a previous attempt of doing this here[0] but the author > did not wanted to make assumptions of a clock plan for the platform. I've already said in previous threads that clock assignment in current linux kernel is not trustworthy. I've got the clock plan for mt7621 now. (Can't share it, sorry.) Most of your clock assumptions above are incorrect. I've made a clock driver with gate support a few months ago.[0] but I don't have much time to really finish it. Maybe you could rework your clock gate driver based on it. [0] https://github.com/981213/linux/commit/2eca1f045e4c3db18c941135464c0d7422ad8133 -- Regards, Chuanhong Guo ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/7] MIPS: ralink: add CPU clock detection and clock gate driver for MT7621
On Thu, Nov 12, 2020 at 9:26 AM Chuanhong Guo wrote: > > I've already said in previous threads that clock assignment in > current linux kernel is not trustworthy. > I've got the clock plan for mt7621 now. (Can't share it, sorry.) > Most of your clock assumptions above are incorrect. > I've made a clock driver with gate support a few months ago.[0] > but I don't have much time to really finish it. > Maybe you could rework your clock gate driver based on it. > > [0] > https://github.com/981213/linux/commit/2eca1f045e4c3db18c941135464c0d7422ad8133 hsdma/eth/pio clocks are still missing in mediatek doc and I just made them up in the driver. Correct clock frequency for them aren't really important for them to work though. And another part I didn't finish is checking clock support for every drivers mt7621 used. Many drivers don't explicitly enable the clock and may be problematic when kernel gates unused clocks. -- Regards, Chuanhong Guo ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 07/11] input: raspberrypi-ts: Release firmware handle when not needed
Hi Nicolas, On Wed, Nov 04, 2020 at 11:39:33AM +0100, Nicolas Saenz Julienne wrote: > Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware > interface when unbinding the device. Unless I am mistaken this driver does not really need the firmware structure past rpi_ts_probe(), and will be fine if it disappears earlier than unbind time. Thanks. > > Signed-off-by: Nicolas Saenz Julienne > > --- > > Changes since v2: > - Use devm_rpi_firmware_get(), instead of remove function > > drivers/input/touchscreen/raspberrypi-ts.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/input/touchscreen/raspberrypi-ts.c > b/drivers/input/touchscreen/raspberrypi-ts.c > index ef6aaed217cf..efed0efa91d9 100644 > --- a/drivers/input/touchscreen/raspberrypi-ts.c > +++ b/drivers/input/touchscreen/raspberrypi-ts.c > @@ -134,7 +134,7 @@ static int rpi_ts_probe(struct platform_device *pdev) > return -ENOENT; > } > > - fw = rpi_firmware_get(fw_node); > + fw = devm_rpi_firmware_get(&pdev->dev, fw_node); > of_node_put(fw_node); > if (!fw) > return -EPROBE_DEFER; > -- > 2.29.1 > -- Dmitry ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/7] MIPS: ralink: add CPU clock detection and clock gate driver for MT7621
Hi Chuanhong, On Thu, Nov 12, 2020 at 2:26 AM Chuanhong Guo wrote: [snip] > > I've already said in previous threads that clock assignment in > current linux kernel is not trustworthy. > I've got the clock plan for mt7621 now. (Can't share it, sorry.) > Most of your clock assumptions above are incorrect. Well, that was of course expected, without a real clock plan this driver was only taking into account Oleksij Rempel suggestions to try to make a driver good enough to properly be maintained :). > I've made a clock driver with gate support a few months ago.[0] > but I don't have much time to really finish it. > Maybe you could rework your clock gate driver based on it. > > [0] > https://github.com/981213/linux/commit/2eca1f045e4c3db18c941135464c0d7422ad8133 Thanks for the link, I see there are three more clocks there with frequencies of 125, 250 and 270 Mhz. all of them having main xtal as parent. Ok, I will take this real information into account and will send v2 after a bit of more feedback comes. > -- > Regards, > Chuanhong Guo Best regards, Sergio Paracuellos ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/7] MIPS: ralink: add CPU clock detection and clock gate driver for MT7621
Hi, On Thu, Nov 12, 2020 at 2:34 AM Chuanhong Guo wrote: > > On Thu, Nov 12, 2020 at 9:26 AM Chuanhong Guo wrote: > > > > I've already said in previous threads that clock assignment in > > current linux kernel is not trustworthy. > > I've got the clock plan for mt7621 now. (Can't share it, sorry.) > > Most of your clock assumptions above are incorrect. > > I've made a clock driver with gate support a few months ago.[0] > > but I don't have much time to really finish it. > > Maybe you could rework your clock gate driver based on it. > > > > [0] > > https://github.com/981213/linux/commit/2eca1f045e4c3db18c941135464c0d7422ad8133 > > hsdma/eth/pio clocks are still missing in mediatek doc and > I just made them up in the driver. Correct clock frequency for > them aren't really important for them to work though. > And another part I didn't finish is checking clock support for > every drivers mt7621 used. Many drivers don't explicitly > enable the clock and may be problematic when kernel > gates unused clocks. > Well, I think they are not important either. Also, by default gate register has all the gate bits enabled. When a gate driver is added, the kernel by default will try to disable those clocks that haven't been requested. To avoid weird behaviour because of some drivers are not using properly clocks we have the CLK_IGNORED_UNUSED, which as you can see is currently being used in my code. Using that all seems to work as expected as it is now. > -- > Regards, > Chuanhong Guo Best regards, Sergio Paracuellos ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: gasket: interrupt: fix the missed eventfd_ctx_put() in gasket_interrupt.c
gasket_interrupt_set_eventfd() misses to call eventfd_ctx_put() in an
error path. We check interrupt is valid before calling
eventfd_ctx_fdget() to fix it.
There is the same issue in gasket_interrupt_clear_eventfd(), Add the
missed function call to fix it.
Fixes: 9a69f5087ccc ("drivers/staging: Gasket driver framework + Apex driver")
Signed-off-by: Jing Xiangfeng
---
drivers/staging/gasket/gasket_interrupt.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/gasket/gasket_interrupt.c
b/drivers/staging/gasket/gasket_interrupt.c
index 2d6195f7300e..864342acfd86 100644
--- a/drivers/staging/gasket/gasket_interrupt.c
+++ b/drivers/staging/gasket/gasket_interrupt.c
@@ -487,14 +487,16 @@ int gasket_interrupt_system_status(struct gasket_dev
*gasket_dev)
int gasket_interrupt_set_eventfd(struct gasket_interrupt_data *interrupt_data,
int interrupt, int event_fd)
{
- struct eventfd_ctx *ctx = eventfd_ctx_fdget(event_fd);
-
- if (IS_ERR(ctx))
- return PTR_ERR(ctx);
+ struct eventfd_ctx *ctx;
if (interrupt < 0 || interrupt >= interrupt_data->num_interrupts)
return -EINVAL;
+ ctx = eventfd_ctx_fdget(event_fd);
+
+ if (IS_ERR(ctx))
+ return PTR_ERR(ctx);
+
interrupt_data->eventfd_ctxs[interrupt] = ctx;
return 0;
}
@@ -505,6 +507,9 @@ int gasket_interrupt_clear_eventfd(struct
gasket_interrupt_data *interrupt_data,
if (interrupt < 0 || interrupt >= interrupt_data->num_interrupts)
return -EINVAL;
- interrupt_data->eventfd_ctxs[interrupt] = NULL;
+ if (interrupt_data->eventfd_ctxs[interrupt]) {
+ eventfd_ctx_put(interrupt_data->eventfd_ctxs[interrupt]);
+ interrupt_data->eventfd_ctxs[interrupt] = NULL;
+ }
return 0;
}
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
