Re: [PATCH v2] staging: media: sunxi: Add bool cast to value
Hi,
On Mon 22 Jul 19, 18:58, Sakari Ailus wrote:
> On Mon, Jul 22, 2019 at 07:14:08PM +0530, Nishka Dasgupta wrote:
> > On 22/07/19 5:54 PM, Paul Kocialkowski wrote:
> > > Hi,
> > >
> > > On Mon 22 Jul 19, 12:12, Jeremy Sowden wrote:
> > > > On 2019-07-22, at 11:36:51 +0530, Nishka Dasgupta wrote:
> > > > > Typecast as bool the return value of cedrus_find_format in
> > > > > cedrus_check_format as the return value of cedrus_check_format is
> > > > > always treated like a boolean value.
> > > > >
> > > > > Signed-off-by: Nishka Dasgupta
> > > > > ---
> > > > > Changes in v2:
> > > > > - Add !! to the returned pointer to ensure that the return value is
> > > > >always either true or false, and never a non-zero value other than
> > > > >true.
> > > > >
> > > > > drivers/staging/media/sunxi/cedrus/cedrus_video.c | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > > > > b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > > > > index e2b530b1a956..b731745f21f8 100644
> > > > > --- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > > > > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > > > > @@ -86,7 +86,7 @@ static struct cedrus_format *cedrus_find_format(u32
> > > > > pixelformat, u32 directions,
> > > > > static bool cedrus_check_format(u32 pixelformat, u32 directions,
> > > > > unsigned int capabilities)
> > > > > {
> > > > > - return cedrus_find_format(pixelformat, directions,
> > > > > capabilities);
> > > > > + return !!(bool)cedrus_find_format(pixelformat, directions,
> > > > > capabilities);
> > > > > }
> > > >
> > > > I think the original was fine. The return value of cedrus_find_format
> > > > will be automatically converted to bool before being returned from
> > > > cedrus_check_format since that is the return-type of the function, and
> > > > the result of converting any non-zero value to bool is 1.
> > >
> > > Okay I was a bit unsure about that and wanted to play it on the safe side
> > > without really looking it up, but that gave me the occasion to verify.
> > >
> > > From what I could find (from my GNU system's
> > > /usr/include/unistring/stdbool.h):
> > >
> > > Limitations of this substitute, when used in a C89 environment:
> > >
> > > - In C99, casts and automatic conversions to '_Bool' or 'bool' are
> > > performed in such a way that every nonzero value gets converted
> > > to 'true', and zero gets converted to 'false'. This doesn't
> > > work
> > > with this substitute. With this substitute, only the values 0
> > > and 1
> > > give the expected result when converted to _Bool' or 'bool'.
> > >
> > > So since the kernel is built for C89 (unless I'm mistaken), I don't think
> > > the
> > > compiler provides any guarantee about bool values being converted to 1
> > > when
> > > they are non-zero. As a result, I think it's best to be careful.
> > >
> > > However, I'm not sure I really see what cocinelle was unhappy about. You
> > > mentionned single-line functions, but I don't see how that can be a
> > > problem.
> >
> > It's not a problem per se. I'm just working on a cleanup project for which I
> > went through all of staging replacing single-line functions with what they
> > were calling. In some cases that makes it easier to figure out what a
> > particular function call does, since the called function actually does
> > something itself instead of just calling a different function?
> > This function was also flagged as one such potentially-removable function by
> > Coccinelle; but in order to do the same replacement that I'd done in other
> > staging drivers, I thought I would do something about the type mismatch
> > first, especially since find_format doesn't appear to be used anywhere else.
> > However, now I won't remove check_format and replace it with find_format as
> > I'd originally planned, since you've said that isn't necessary here. That
> > leaves the return type issue.
> >
> >
> > > So in the end, I think we should keep the !! and drop the (bool) cast if
> > > there's
> > > no particular warning about it.
> >
> > Should I send a version 3 that does this?
>
> bool was introduced in C99. Converting a non-zero value to boolean will
> yield true as a result. Please keep the code as-is; it's much easier to
> read that way.
I was quite doubtful about that given the research and conclusions from
yesterday, but it seems that Linux is built for GNU 89 (not C89) which brings
support for bool "as in C99", so according to what you described.
So tl;dr, I agree with you that we should just keep the code as it is now.
Cheers,
Paul
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdri
Re: [PATCH v3 23/24] erofs: introduce cached decompression
On Mon, Jul 22, 2019 at 06:58:59PM +0800, Gao Xiang wrote: > On 2019/7/22 6:18, David Sterba wrote: > > On Mon, Jul 22, 2019 at 10:50:42AM +0800, Gao Xiang wrote: > >> +choice > >> + prompt "EROFS Data Decompression mode" > >> + depends on EROFS_FS_ZIP > >> + default EROFS_FS_ZIP_CACHE_READAROUND > >> + help > >> +EROFS supports three options for decompression. > >> +"In-place I/O Only" consumes the minimum memory > >> +with lowest random read. > >> + > >> +"Cached Decompression for readaround" consumes > >> +the maximum memory with highest random read. > >> + > >> +If unsure, select "Cached Decompression for readaround" > >> + > >> +config EROFS_FS_ZIP_CACHE_DISABLED > >> + bool "In-place I/O Only" > >> + help > >> +Read compressed data into page cache and do in-place > >> +I/O decompression directly. > >> + > >> +config EROFS_FS_ZIP_CACHE_READAHEAD > >> + bool "Cached Decompression for readahead" > >> + help > >> +For each request, it caches the last compressed page > >> +for further reading. > >> +It still does in-place I/O for the rest compressed pages. > >> + > >> +config EROFS_FS_ZIP_CACHE_READAROUND > >> + bool "Cached Decompression for readaround" > >> + help > >> +For each request, it caches the both end compressed pages > >> +for further reading. > >> +It still does in-place I/O for the rest compressed pages. > >> + > >> +Recommended for performance priority. > > > > The number of individual Kconfig options is quite high, are you sure you > > need them to be split like that? > > You mean the above? these are 3 cache strategies, which impact the > runtime memory consumption and performance. I tend to leave the above > as it-is... No, I mean all Kconfig options, they're scattered over several patches, best seen in the checked out branch. The cache strategies are actually just one config option (choice). > I'm not sure vm_map_ram() is always better than vmap() for all > platforms (it has noticeable performance impact). However that > seems true for my test machines (x86-64, arm64). > > If vm_map_ram() is always the optimal choice compared with vmap(), > I will remove vmap() entirely, that is OK. But I am not sure for > every platforms though. You can select the implementation by platform, I don't know what are the criteria like cpu type etc, but I expect it's something that can be determined at module load time. Eventually a module parameter can be the the way to set it. > > And so on. I'd suggest to go through all the options and reconsider them > > to be built-in, or runtime settings. Debugging features like the fault > > injections could be useful on non-debugging builds too, so a separate > > option is fine, otherwise grouping other debugging options under the > > main EROFS_FS_DEBUG would look more logical. > > The remaining one is EROFS_FS_CLUSTER_PAGE_LIMIT. It impacts the total > size of z_erofs_pcluster structure. It's a hard limit, and should be > configured as small as possible. I can remove it right now since multi-block > compression is not available now. However, it will be added again after > multi-block compression is supported. > > So, How about leave it right now and use the default value? >From the Kconfig and build-time settings perspective I think it's misplaced. This affects testing, you'd have to rebuild and reinstall the module to test any change, while it's "just" a number that can be either module parameter, sysfs knob, mount option or special ioctl. But I may be wrong, EROFS is a special purpose filesystem, so the fine-grained build options might make sense (eg. due to smaller code). The question should be how does each option affect typical production build targets. Fewer is IMHO better. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 23/24] erofs: introduce cached decompression
On 2019/7/23 8:31, David Sterba wrote: > On Mon, Jul 22, 2019 at 06:58:59PM +0800, Gao Xiang wrote: >> On 2019/7/22 6:18, David Sterba wrote: >>> On Mon, Jul 22, 2019 at 10:50:42AM +0800, Gao Xiang wrote: +choice + prompt "EROFS Data Decompression mode" + depends on EROFS_FS_ZIP + default EROFS_FS_ZIP_CACHE_READAROUND + help +EROFS supports three options for decompression. +"In-place I/O Only" consumes the minimum memory +with lowest random read. + +"Cached Decompression for readaround" consumes +the maximum memory with highest random read. + +If unsure, select "Cached Decompression for readaround" + +config EROFS_FS_ZIP_CACHE_DISABLED + bool "In-place I/O Only" + help +Read compressed data into page cache and do in-place +I/O decompression directly. + +config EROFS_FS_ZIP_CACHE_READAHEAD + bool "Cached Decompression for readahead" + help +For each request, it caches the last compressed page +for further reading. +It still does in-place I/O for the rest compressed pages. + +config EROFS_FS_ZIP_CACHE_READAROUND + bool "Cached Decompression for readaround" + help +For each request, it caches the both end compressed pages +for further reading. +It still does in-place I/O for the rest compressed pages. + +Recommended for performance priority. >>> >>> The number of individual Kconfig options is quite high, are you sure you >>> need them to be split like that? >> >> You mean the above? these are 3 cache strategies, which impact the >> runtime memory consumption and performance. I tend to leave the above >> as it-is... > > No, I mean all Kconfig options, they're scattered over several patches, > best seen in the checked out branch. The cache strategies are actually > just one config option (choice). I will change the cache strategy at runtime as Ted suggested. The cost is actually that erofs will always need a managed_cache inode even though users just use in-place IO for their products. However, I notice that using separated Kconfig will make test harder, so that it leads to more bugs, that is what I really care about. Therefore I think making it at runtime is OK for me. > >> I'm not sure vm_map_ram() is always better than vmap() for all >> platforms (it has noticeable performance impact). However that >> seems true for my test machines (x86-64, arm64). >> >> If vm_map_ram() is always the optimal choice compared with vmap(), >> I will remove vmap() entirely, that is OK. But I am not sure for >> every platforms though. > > You can select the implementation by platform, I don't know what are the > criteria like cpu type etc, but I expect it's something that can be > determined at module load time. Eventually a module parameter can be the > the way to set it. OK, module parameter makes sense for me, and the overhead may be unnoticeable. I think it is fine to me. > >>> And so on. I'd suggest to go through all the options and reconsider them >>> to be built-in, or runtime settings. Debugging features like the fault >>> injections could be useful on non-debugging builds too, so a separate >>> option is fine, otherwise grouping other debugging options under the >>> main EROFS_FS_DEBUG would look more logical. >> >> The remaining one is EROFS_FS_CLUSTER_PAGE_LIMIT. It impacts the total >> size of z_erofs_pcluster structure. It's a hard limit, and should be >> configured as small as possible. I can remove it right now since multi-block >> compression is not available now. However, it will be added again after >> multi-block compression is supported. >> >> So, How about leave it right now and use the default value? > > From the Kconfig and build-time settings perspective I think it's > misplaced. This affects testing, you'd have to rebuild and reinstall the > module to test any change, while it's "just" a number that can be either > module parameter, sysfs knob, mount option or special ioctl. > > But I may be wrong, EROFS is a special purpose filesystem, so the > fine-grained build options might make sense (eg. due to smaller code). > The question should be how does each option affect typical production > build targets. Fewer is IMHO better. I have to admit, EROFS still has some special stuffs now (since we still have some TODO), However, I don't think EROFS cannot be effectively used for many productive uses right now. Considering that using linux-staging stuff is dangerous / unsuitable for most of companies, out of staging is better... And we still have to improve it to be more generic by time like what other fses do (IMO, writing a generic compression fs is not hard, many fses are there. I need to think more carefully in case of some performance loss which is out of too straight-forward generic code)... To be more specific, as for EROFS_FS_CLUSTER_PAGE
Re: [PATCH v3] Staging: most: fix coding style issues
Hi Gabriel, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on staging/staging-testing] [cannot apply to v5.3-rc1 next-20190723] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Gabriel-Beauchamp/Staging-most-fix-coding-style-issues/20190701-203804 reproduce: # apt-get install sparse # sparse version: v0.6.1-rc1-7-g2b96cd8-dirty make ARCH=x86_64 allmodconfig make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' If you fix the issue, kindly add following tag Reported-by: kbuild test robot sparse warnings: (new ones prefixed by >>) >> drivers/staging/most/core.c:308:30: sparse: sparse: incorrect type in >> assignment (different modifiers) @@expected char *type @@got char >> const *char *type @@ >> drivers/staging/most/core.c:308:30: sparse:expected char *type >> drivers/staging/most/core.c:308:30: sparse:got char const *const name vim +308 drivers/staging/most/core.c --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] drivers/staging/rtl8192u: fix indentation issue, remove extra tab
From: Colin Ian King
A statement is indented one level too deeply; clean this up by
removing a tab.
Signed-off-by: Colin Ian King
---
drivers/staging/rtl8192u/r8192U_dm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8192u/r8192U_dm.c
b/drivers/staging/rtl8192u/r8192U_dm.c
index ade14ef05730..c23e43b095d9 100644
--- a/drivers/staging/rtl8192u/r8192U_dm.c
+++ b/drivers/staging/rtl8192u/r8192U_dm.c
@@ -1334,7 +1334,7 @@ static void dm_CheckTXPowerTracking_ThermalMeter(struct
net_device *dev)
return;
}
/*DbgPrint("Schedule TxPowerTrackingWorkItem\n");*/
- queue_delayed_work(priv->priv_wq, &priv->txpower_tracking_wq,
0);
+ queue_delayed_work(priv->priv_wq, &priv->txpower_tracking_wq, 0);
TM_Trigger = 0;
}
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8723bs: hal: remove redundant assignment to variable n
From: Colin Ian King
The variable n is being assigned a value that is never read, the
assignment is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/staging/rtl8723bs/hal/rtl8723bs_recv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/rtl8723bs/hal/rtl8723bs_recv.c
b/drivers/staging/rtl8723bs/hal/rtl8723bs_recv.c
index e23b39ab16c5..032d01834f3f 100644
--- a/drivers/staging/rtl8723bs/hal/rtl8723bs_recv.c
+++ b/drivers/staging/rtl8723bs/hal/rtl8723bs_recv.c
@@ -486,7 +486,6 @@ s32 rtl8723bs_init_recv_priv(struct adapter *padapter)
}
if (precvpriv->pallocated_recv_buf) {
- n = NR_RECVBUFF * sizeof(struct recv_buf) + 4;
kfree(precvpriv->pallocated_recv_buf);
precvpriv->pallocated_recv_buf = NULL;
}
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 5/6] staging: mt7621-dts: fix register range of memc node in mt7621.dtsi
The memc node from mt7621.dtsi has incorrect register resource.
Fix it according to the programming guide.
Signed-off-by: Weijie Gao
Signed-off-by: Chuanhong Guo
---
Change since v1: None.
drivers/staging/mt7621-dts/mt7621.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi
b/drivers/staging/mt7621-dts/mt7621.dtsi
index a4c08110094b..d89d68ffa7bc 100644
--- a/drivers/staging/mt7621-dts/mt7621.dtsi
+++ b/drivers/staging/mt7621-dts/mt7621.dtsi
@@ -138,7 +138,7 @@
memc: memc@5000 {
compatible = "mtk,mt7621-memc";
- reg = <0x300 0x100>;
+ reg = <0x5000 0x1000>;
};
cpc: cpc@1fbf {
--
2.21.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 0/6] MIPS: ralink: add CPU clock detection for MT7621
This patchset ports CPU clock detection for MT7621 from OpenWrt. Last time I sent this, I forgot to add an binding include which caused a compile error and the patch doesn't stay in linux-next. This patchset resent the first two commits and also added binding documentation for mt7621-pll and used it in mt7621-dts at drivers/staging. Changes since v1: 1. changed commit title prefix for dt include 2. split the patch adding clock node (details in that patch body) 3. drop useless syscon in dt documentation 4. drop cpuclock node for gbpc1 Chuanhong Guo (6): dt-bindings: clock: add dt binding header for mt7621-pll MIPS: ralink: drop ralink_clk_init for mt7621 MIPS: ralink: add clock device providing cpu/bus clock for mt7621 dt: bindings: add mt7621-pll dt binding documentation staging: mt7621-dts: fix register range of memc node in mt7621.dtsi staging: mt7621-dts: add dt nodes for mt7621-pll .../bindings/clock/mediatek,mt7621-pll.txt| 18 arch/mips/include/asm/mach-ralink/mt7621.h| 20 arch/mips/ralink/mt7621.c | 98 +-- drivers/staging/mt7621-dts/gbpc1.dts | 5 - drivers/staging/mt7621-dts/mt7621.dtsi| 17 ++-- include/dt-bindings/clock/mt7621-clk.h| 14 +++ 6 files changed, 126 insertions(+), 46 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt7621-pll.txt create mode 100644 include/dt-bindings/clock/mt7621-clk.h -- 2.21.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 2/6] MIPS: ralink: drop ralink_clk_init for mt7621
This function isn't called anywhere. just drop it.
Signed-off-by: Chuanhong Guo
---
Change since v1:
New patch. Split from:
"MIPS: ralink: fix cpu clock of mt7621 and add dt clk devices"
arch/mips/ralink/mt7621.c | 43 ---
1 file changed, 43 deletions(-)
diff --git a/arch/mips/ralink/mt7621.c b/arch/mips/ralink/mt7621.c
index 9415be0d57b8..ba39f3f3a7c7 100644
--- a/arch/mips/ralink/mt7621.c
+++ b/arch/mips/ralink/mt7621.c
@@ -18,11 +18,6 @@
#include "common.h"
-#define SYSC_REG_SYSCFG0x10
-#define SYSC_REG_CPLL_CLKCFG0 0x2c
-#define SYSC_REG_CUR_CLK_STS 0x44
-#define CPU_CLK_SEL(BIT(30) | BIT(31))
-
#define MT7621_GPIO_MODE_UART1 1
#define MT7621_GPIO_MODE_I2C 2
#define MT7621_GPIO_MODE_UART3_MASK0x3
@@ -113,44 +108,6 @@ phys_addr_t mips_cpc_default_phys_base(void)
panic("Cannot detect cpc address");
}
-void __init ralink_clk_init(void)
-{
- int cpu_fdiv = 0;
- int cpu_ffrac = 0;
- int fbdiv = 0;
- u32 clk_sts, syscfg;
- u8 clk_sel = 0, xtal_mode;
- u32 cpu_clk;
-
- if ((rt_sysc_r32(SYSC_REG_CPLL_CLKCFG0) & CPU_CLK_SEL) != 0)
- clk_sel = 1;
-
- switch (clk_sel) {
- case 0:
- clk_sts = rt_sysc_r32(SYSC_REG_CUR_CLK_STS);
- cpu_fdiv = ((clk_sts >> 8) & 0x1F);
- cpu_ffrac = (clk_sts & 0x1F);
- cpu_clk = (500 * cpu_ffrac / cpu_fdiv) * 1000 * 1000;
- break;
-
- case 1:
- fbdiv = ((rt_sysc_r32(0x648) >> 4) & 0x7F) + 1;
- syscfg = rt_sysc_r32(SYSC_REG_SYSCFG);
- xtal_mode = (syscfg >> 6) & 0x7;
- if (xtal_mode >= 6) {
- /* 25Mhz Xtal */
- cpu_clk = 25 * fbdiv * 1000 * 1000;
- } else if (xtal_mode >= 3) {
- /* 40Mhz Xtal */
- cpu_clk = 40 * fbdiv * 1000 * 1000;
- } else {
- /* 20Mhz Xtal */
- cpu_clk = 20 * fbdiv * 1000 * 1000;
- }
- break;
- }
-}
-
void __init ralink_of_remap(void)
{
rt_sysc_membase = plat_of_remap_node("mtk,mt7621-sysc");
--
2.21.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 1/6] dt-bindings: clock: add dt binding header for mt7621-pll
This patch adds dt binding header for mediatek,mt7621-pll Signed-off-by: Weijie Gao Signed-off-by: Chuanhong Guo Reviewed-by: Rob Herring --- Change since v1: Change commit title prefix. include/dt-bindings/clock/mt7621-clk.h | 14 ++ 1 file changed, 14 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 ..a29e14ee2efe --- /dev/null +++ b/include/dt-bindings/clock/mt7621-clk.h @@ -0,0 +1,14 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (C) 2018 Weijie Gao + */ + +#ifndef __DT_BINDINGS_MT7621_CLK_H +#define __DT_BINDINGS_MT7621_CLK_H + +#define MT7621_CLK_CPU 0 +#define MT7621_CLK_BUS 1 + +#define MT7621_CLK_MAX 2 + +#endif /* __DT_BINDINGS_MT7621_CLK_H */ -- 2.21.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 3/6] MIPS: ralink: add clock device providing cpu/bus 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/bus clock calculation code and binds clocks to
mt7621-pll node.
Ported from OpenWrt:
c7ca224299 ramips: fix cpu clock of mt7621 and add dt clk devices
Signed-off-by: Weijie Gao
Signed-off-by: Chuanhong Guo
---
Changes since v1:
1. split patch.
2. calculate clocks using the function called by CLK_OF_DECLARE
drop direct function call in timer-gic.c of ralink_clk_init
3. drop assignment of mips-hpt-frequency
arch/mips/include/asm/mach-ralink/mt7621.h | 20 ++
arch/mips/ralink/mt7621.c | 77 ++
2 files changed, 97 insertions(+)
diff --git a/arch/mips/include/asm/mach-ralink/mt7621.h
b/arch/mips/include/asm/mach-ralink/mt7621.h
index 65483a4681ab..51a6e51aef3f 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 ba39f3f3a7c7..baf9033a67b4 100644
--- a/arch/mips/ralink/mt7621.c
+++ b/arch/mips/ralink/mt7621.c
@@ -7,12 +7,16 @@
#include
#include
+#include
+#include
+#include
#include
#include
#include
#include
#include
+#include
#include
@@ -103,11 +107,84 @@ 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, unsigned long rate)
+{
+ struct clk *clk;
+ int err;
+
+ clk = clk_register_fixed_rate(NULL, id, NULL, 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;
+}
+
+static void __init mt7621_clocks_init(struct device_node *np)
+{
+ const static u32 prediv_tbl[] = {0, 1, 2, 2};
+ u32 syscfg, xtal_sel, clkcfg, clk_sel, curclk, ffiv, ffrac;
+ u32 pll, prediv, fbdiv;
+ u32 xtal_clk, cpu_clk, bus_clk;
+
+ 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 = 20 * 1000 * 1000;
+ else if (xtal_sel <= 5)
+ xtal_clk = 40 * 1000 * 1000;
+ else
+ xtal_clk = 25 * 1000 * 1000;
+
+ switch (clk_sel) {
+ case 0:
+ cpu_clk = 500 * 1000 * 1000;
+ 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;
+ bus_clk = cpu_clk / 4;
+
+ clks[MT7621_CLK_CPU] = mt7621_add_sys_clkdev("cpu", cpu_clk);
+ clks[MT7621_CLK_BUS] = mt7621_add_sys_clkdev("bus", bus_clk);
+
+ pr_info("CPU Clock: %dMHz\n", cpu_clk / 100);
+
+ of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data
[PATCH v2 4/6] dt: bindings: add mt7621-pll dt binding documentation
This commit adds device tree binding documentation for MT7621
PLL controller.
Signed-off-by: Chuanhong Guo
---
Change since v1:
drop useless syscon in compatible string
.../bindings/clock/mediatek,mt7621-pll.txt | 18 ++
1 file changed, 18 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/mediatek,mt7621-pll.txt
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7621-pll.txt
b/Documentation/devicetree/bindings/clock/mediatek,mt7621-pll.txt
new file mode 100644
index ..7dcfbd5283e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt7621-pll.txt
@@ -0,0 +1,18 @@
+Binding for Mediatek MT7621 PLL controller
+
+The PLL controller provides the 2 main clocks of the SoC: CPU and BUS.
+
+Required Properties:
+- compatible: has to be "mediatek,mt7621-pll"
+- #clock-cells: has to be one
+
+Optional properties:
+- clock-output-names: should be "cpu", "bus"
+
+Example:
+ pll {
+ compatible = "mediatek,mt7621-pll";
+
+ #clock-cells = <1>;
+ clock-output-names = "cpu", "bus";
+ };
--
2.21.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 6/6] staging: mt7621-dts: add dt nodes for mt7621-pll
This commit adds device-tree node for mt7621-pll and use its clocks
accordingly.
Signed-off-by: Chuanhong Guo
---
Changes since v1:
1. drop cpuclock node in gbpc1.dts
2. drop syscon in mt7621-pll node
drivers/staging/mt7621-dts/gbpc1.dts | 5 -
drivers/staging/mt7621-dts/mt7621.dtsi | 15 +++
2 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/mt7621-dts/gbpc1.dts
b/drivers/staging/mt7621-dts/gbpc1.dts
index 1fb560ff059c..d94b73243268 100644
--- a/drivers/staging/mt7621-dts/gbpc1.dts
+++ b/drivers/staging/mt7621-dts/gbpc1.dts
@@ -106,11 +106,6 @@
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 d89d68ffa7bc..7b82f7f70404 100644
--- a/drivers/staging/mt7621-dts/mt7621.dtsi
+++ b/drivers/staging/mt7621-dts/mt7621.dtsi
@@ -1,4 +1,5 @@
#include
+#include
#include
/ {
@@ -27,12 +28,11 @@
serial0 = &uartlite;
};
- cpuclock: cpuclock@0 {
- #clock-cells = <0>;
- compatible = "fixed-clock";
+ pll: pll {
+ compatible = "mediatek,mt7621-pll";
- /* FIXME: there should be way to detect this */
- clock-frequency = <88000>;
+ #clock-cells = <1>;
+ clock-output-names = "cpu", "bus";
};
sysclock: sysclock@0 {
@@ -155,7 +155,6 @@
compatible = "ns16550a";
reg = <0xc00 0x100>;
- clocks = <&sysclock>;
clock-frequency = <5000>;
interrupt-parent = <&gic>;
@@ -172,7 +171,7 @@
compatible = "ralink,mt7621-spi";
reg = <0xb00 0x100>;
- clocks = <&sysclock>;
+ clocks = <&pll MT7621_CLK_BUS>;
resets = <&rstctrl 18>;
reset-names = "spi";
@@ -372,7 +371,7 @@
timer {
compatible = "mti,gic-timer";
interrupts = ;
- clocks = <&cpuclock>;
+ clocks = <&pll MT7621_CLK_CPU>;
};
};
--
2.21.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Reminder: 1 open syzbot bug in "android/ashmem" subsystem
[This email was generated by a script. Let me know if you have any suggestions to make it better, or if you want it re-generated with the latest status.] Of the currently open syzbot reports against the upstream kernel, I've manually marked 1 of them as possibly being a bug in the "android/ashmem" subsystem. If you believe this bug is no longer valid, please close the syzbot report by sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the original thread, as explained at https://goo.gl/tpsmEJ#status If you believe I misattributed this bug to the "android/ashmem" subsystem, please let me know, and if possible forward the report to the correct people or mailing list. Here is the bug: Title: WARNING in __vm_enough_memory Last occurred: 91 days ago Reported: 554 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=52304f8f4b4e28508d52875f95df5e30417eff1b Original thread: https://lkml.kernel.org/lkml/001a1144593661efb50562d96...@google.com/T/#u This bug has a C reproducer. The original thread for this bug received 1 reply, 553 days ago. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+cc298e15b6a571ba0...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/001a1144593661efb50562d96...@google.com ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
