RE: [PATCH 1/1] subsystem: CPU FREQUENCY DRIVERS- Set cpu_load calculation on current frequency
Thanks :) -Original Message- From: Viresh Kumar [mailto:viresh.ku...@linaro.org] Sent: 05 March 2015 10:26 To: Rahul Khandelwal (Rahul Khandelwal) Cc: r...@rjwysocki.net; a...@linux-foundation.org; linux-kernel@vger.kernel.org; sta...@vger.kernel.org Subject: Re: [PATCH 1/1] subsystem: CPU FREQUENCY DRIVERS- Set cpu_load calculation on current frequency On 5 March 2015 at 10:06, Rahul Khandelwal (Rahul Khandelwal) wrote: > Hello Viresh, > > Thank you for your reply and the information. :) > > I have created the patch using the "diff -up" command, I think this way > should be used to create patches as mentioned in > Documentation/SubmittingPatches.. Oh, I was born after git and so never used any other way to send patches. :( > Could you please help me to know whether any kernel release using interactive > governor ? or any way to share the patch the same in any kernel release. Its not part of the kernel, you have to get this into AOSP.
Re: [PATCH v4 0/3] X-Power AXP288 PMIC Fuel Gauge Driver
On Thu, 05 Mar 2015, Sebastian Reichel wrote: > Hi, > > On Wed, Feb 04, 2015 at 04:24:35PM -0800, Todd Brandt wrote: > > New power_supply driver at driver/power which interfaces with the > > axp20x mfd driver as a cell. Provides battery info, monitors for > > changes, and generates alerts on temperature and capacity issues > > > > Sebestian, please review the patch set and consider it for 3.20 rc1. > > I've applied it over git.infradead.org/battery-2.6.git/master and > > verified that it works. Thanks. > > Lee, are you ok with patches 1+2 going through power supply > subsystem? Yeah, go for it. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/38] perf record: Add --index option for building index table
On Tue, Mar 03, 2015 at 12:07:20PM +0900, Namhyung Kim wrote:
SNIP
> +static int record__merge_index_files(struct record *rec, int nr_index)
> +{
> + int i;
> + int ret = -1;
> + u64 offset;
> + char path[PATH_MAX];
> + struct perf_file_section *idx;
> + struct perf_data_file *file = >file;
> + struct perf_session *session = rec->session;
> + int output_fd = perf_data_file__fd(file);
> +
> + /* +1 for header file itself */
> + nr_index++;
> +
> + idx = calloc(nr_index, sizeof(*idx));
> + if (idx == NULL)
> + goto out_close;
> +
> + offset = lseek(output_fd, 0, SEEK_END);
> +
> + idx[0].offset = session->header.data_offset;
> + idx[0].size = offset - idx[0].offset;
> +
> + for (i = 1; i < nr_index; i++) {
> + struct stat stbuf;
> + int fd = rec->fds[i];
> +
> + if (fstat(fd, ) < 0)
> + goto out_close;
> +
> + idx[i].offset = offset;
> + idx[i].size = stbuf.st_size;
> +
> + offset += stbuf.st_size;
> + }
> +
> + /* copy sample events */
> + for (i = 1; i < nr_index; i++) {
> + int fd = rec->fds[i];
> +
> + if (idx[i].size == 0)
> + continue;
> +
> + if (copyfile_offset(fd, 0, output_fd, idx[i].offset,
> + idx[i].size) < 0)
> + goto out_close;
> + }
why not do the copy in previous loop as well?
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC v12 04/19] dt-binding: leds: Add common LED DT bindings macros
On 03/04/2015 05:14 PM, Jacek Anaszewski wrote: Add macros for defining boost mode and trigger type properties of flash LED devices. Signed-off-by: Jacek Anaszewski Acked-by: Kyungmin Park Cc: Bryan Wu Cc: Richard Purdie --- include/dt-bindings/leds/max77693.h | 21 + 1 file changed, 21 insertions(+) create mode 100644 include/dt-bindings/leds/max77693.h This should be obviously include/dt-bindings/leds/common.h. It will affect also max77693-led bindings documentation patch. I'll send the update after receiving review remarks related to the remaining part of the mentioned patches. diff --git a/include/dt-bindings/leds/max77693.h b/include/dt-bindings/leds/max77693.h new file mode 100644 index 000..79fcef7 --- /dev/null +++ b/include/dt-bindings/leds/max77693.h @@ -0,0 +1,21 @@ +/* + * This header provides macros for the common LEDs device tree bindings. + * + * Copyright (C) 2015, Samsung Electronics Co., Ltd. + * + * Author: Jacek Anaszewski + */ + +#ifndef __DT_BINDINGS_LEDS_H__ +#define __DT_BINDINGS_LEDS_H + +/* External trigger type */ +#define LEDS_TRIG_TYPE_EDGE0 +#define LEDS_TRIG_TYPE_LEVEL 1 + +/* Boost modes */ +#define LEDS_BOOST_OFF 0 +#define LEDS_BOOST_ADAPTIVE1 +#define LEDS_BOOST_FIXED 2 + +#endif /* __DT_BINDINGS_LEDS_H */ -- Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 2/2] phy: miphy365x: Convert to use phy.h instead of phy-miphy365x.h
On Thu, 05 Mar 2015, Axel Lin wrote:
> The defines in phy-miphy365x.h are all covered in phy.h:
>
> MIPHY_TYPE_SATA == PHY_TYPE_STA
> MIPHY_TYPE_PCIE == PHY_TYPE_PCIE
> MIPPHY_TYPE_USB == PHY_TYPE_USB2
>
> So covert to use phy.h and then delete phy-miphy365x.h.
>
> Signed-off-by: Axel Lin
> ---
> Documentation/devicetree/bindings/ata/ahci-st.txt | 2 +-
> Documentation/devicetree/bindings/phy/phy-miphy365x.txt | 8
> arch/arm/boot/dts/stih416.dtsi | 4 ++--
> drivers/phy/phy-miphy365x.c | 14 +++---
> include/dt-bindings/phy/phy-miphy365x.h | 14 --
> 5 files changed, 14 insertions(+), 28 deletions(-)
> delete mode 100644 include/dt-bindings/phy/phy-miphy365x.h
Acked-by: Lee Jones
> diff --git a/Documentation/devicetree/bindings/ata/ahci-st.txt
> b/Documentation/devicetree/bindings/ata/ahci-st.txt
> index 0574a77..070748b 100644
> --- a/Documentation/devicetree/bindings/ata/ahci-st.txt
> +++ b/Documentation/devicetree/bindings/ata/ahci-st.txt
> @@ -21,7 +21,7 @@ Example:
> reg = <0xfe38 0x1000>;
> interrupts = ;
> interrupt-names = "hostc";
> - phys= <_phy MIPHY_PORT_0 MIPHY_TYPE_SATA>;
> + phys= <_phy MIPHY_PORT_0 PHY_TYPE_SATA>;
> phy-names = "ahci_phy";
> resets = < STIH416_SATA0_POWERDOWN>,
> < STIH416_SATA0_SOFTRESET>;
> diff --git a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> index 9802d5d..087294d 100644
> --- a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> +++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> @@ -20,8 +20,8 @@ Required nodes : A sub-node is required for each
> channel the controller
> Required properties (port (child) node):
> - #phy-cells : Should be 1 (See second example)
> Cell after port phandle is device type from:
> - - MIPHY_TYPE_SATA
> - - MIPHY_TYPE_PCI
> + - PHY_TYPE_SATA
> + - PHY_TYPE_PCIE
> - reg: Address and length of register sets for each device in
> "reg-names"
> - reg-names : The names of the register addresses corresponding to the
> @@ -68,10 +68,10 @@ property, containing a phandle to the phy port node and a
> device type.
>
> Example:
>
> -#include
> +#include
>
> sata0: sata@fe38 {
> ...
> - phys = <_port0 MIPHY_TYPE_SATA>;
> + phys = <_port0 PHY_TYPE_SATA>;
> ...
> };
> diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
> index ea28eba..eeb7afe 100644
> --- a/arch/arm/boot/dts/stih416.dtsi
> +++ b/arch/arm/boot/dts/stih416.dtsi
> @@ -10,7 +10,7 @@
> #include "stih416-clock.dtsi"
> #include "stih416-pinctrl.dtsi"
>
> -#include
> +#include
> #include
> #include
> / {
> @@ -306,7 +306,7 @@
> reg = <0xfe38 0x1000>;
> interrupts = ;
> interrupt-names = "hostc";
> - phys= <_port0 MIPHY_TYPE_SATA>;
> + phys= <_port0 PHY_TYPE_SATA>;
> phy-names = "sata-phy";
> resets = < STIH416_SATA0_POWERDOWN>,
> < STIH416_SATA0_SOFTRESET>;
> diff --git a/drivers/phy/phy-miphy365x.c b/drivers/phy/phy-miphy365x.c
> index 51b459d..019c2d7 100644
> --- a/drivers/phy/phy-miphy365x.c
> +++ b/drivers/phy/phy-miphy365x.c
> @@ -25,7 +25,7 @@
> #include
> #include
>
> -#include
> +#include
>
> #define HFC_TIMEOUT 100
>
> @@ -177,7 +177,7 @@ static u8 rx_tx_spd[] = {
> static int miphy365x_set_path(struct miphy365x_phy *miphy_phy,
> struct miphy365x_dev *miphy_dev)
> {
> - bool sata = (miphy_phy->type == MIPHY_TYPE_SATA);
> + bool sata = (miphy_phy->type == PHY_TYPE_SATA);
>
> return regmap_update_bits(miphy_dev->regmap,
> miphy_phy->ctrlreg,
> @@ -431,7 +431,7 @@ static int miphy365x_init(struct phy *phy)
> }
>
> /* Initialise Miphy for PCIe or SATA */
> - if (miphy_phy->type == MIPHY_TYPE_PCIE)
> + if (miphy_phy->type == PHY_TYPE_PCIE)
> ret = miphy365x_init_pcie_port(miphy_phy, miphy_dev);
> else
> ret = miphy365x_init_sata_port(miphy_phy, miphy_dev);
> @@ -455,8 +455,8 @@ int miphy365x_get_addr(struct device *dev, struct
> miphy365x_phy *miphy_phy,
> return ret;
> }
>
> - if (!((!strncmp(name, "sata", 4) && type == MIPHY_TYPE_SATA) ||
> - (!strncmp(name, "pcie", 4) && type ==
Re: [PATCH 1/2] phy: miphy365x: Convert to devm_kcalloc and fix wrong sizof
On Thu, 05 Mar 2015, Axel Lin wrote: > Prefer devm_kcalloc over devm_kzalloc with multiply. > In additional, use sizeof(phy) is incorrect, fix it. > > Signed-off-by: Axel Lin > --- > drivers/phy/phy-miphy365x.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) Acked-by: Lee Jones > diff --git a/drivers/phy/phy-miphy365x.c b/drivers/phy/phy-miphy365x.c > index 61177a6..51b459d 100644 > --- a/drivers/phy/phy-miphy365x.c > +++ b/drivers/phy/phy-miphy365x.c > @@ -549,9 +549,8 @@ static int miphy365x_probe(struct platform_device *pdev) > return -ENOMEM; > > miphy_dev->nphys = of_get_child_count(np); > - miphy_dev->phys = devm_kzalloc(>dev, > -sizeof(phy) * miphy_dev->nphys, > -GFP_KERNEL); > + miphy_dev->phys = devm_kcalloc(>dev, miphy_dev->nphys, > +sizeof(*miphy_dev->phys), GFP_KERNEL); > if (!miphy_dev->phys) > return -ENOMEM; > -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 02/21] ACPI / processor: Introduce phys_cpuid_t for CPU hardware ID
On 2015/3/5 6:29, Rafael J. Wysocki wrote:
> On Wednesday, February 25, 2015 04:39:42 PM Hanjun Guo wrote:
>> CPU hardware ID (phys_id) is defined as u32 in structure acpi_processor,
>> but phys_id is used as int in acpi processor driver, so it will lead to
>> some inconsistence for the drivers.
>>
>> Furthermore, to cater for ACPI arch ports that implement 64 bits CPU
>> ids a generic CPU physical id type is required.
>>
>> So introduce typedef u32 phys_cpuid_t for x86 and ia64, and introduce
>> a macro CPU_PHYS_ID_INVALID as (u32)(-1), use phys_cpuid_t when phys_id
>> defined in acpi processor driver, and replace CPU_PHYS_ID_INVALID as -1
>> for phys_id, this will solve the inconsistence in acpi processor driver,
>> and will prepare for the ACPI on ARM64 too.
>>
>> CC: Rafael J Wysocki
>> Suggested-by: Lorenzo Pieralisi
>> Acked-by: Sudeep Holla
>> Signed-off-by: Catalin Marinas
>> [hj: reworked cpu physid map return codes]
>> Signed-off-by: Hanjun Guo
>> ---
>> arch/ia64/include/asm/acpi.h | 4
>> arch/ia64/kernel/acpi.c | 2 +-
>> arch/x86/include/asm/acpi.h | 4
>> arch/x86/kernel/acpi/boot.c | 2 +-
>> drivers/acpi/acpi_processor.c | 7 ---
>> drivers/acpi/processor_core.c | 30 +++---
>> include/acpi/processor.h | 6 +++---
>> include/linux/acpi.h | 2 +-
>> 8 files changed, 33 insertions(+), 24 deletions(-)
>>
>> diff --git a/arch/ia64/include/asm/acpi.h b/arch/ia64/include/asm/acpi.h
>> index a1d91ab..ca1f0e4 100644
>> --- a/arch/ia64/include/asm/acpi.h
>> +++ b/arch/ia64/include/asm/acpi.h
>> @@ -34,6 +34,10 @@
>> #include
>> #include
>>
>> +typedef u32 phys_cpuid_t;
>> +
>> +#define CPU_PHYS_ID_INVALID (u32)(-1)
>> +
>> #ifdef CONFIG_ACPI
>> extern int acpi_lapic;
>> #define acpi_disabled 0 /* ACPI always enabled on IA64 */
>> diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c
>> index 2c44989..067ef44 100644
>> --- a/arch/ia64/kernel/acpi.c
>> +++ b/arch/ia64/kernel/acpi.c
>> @@ -887,7 +887,7 @@ static int _acpi_map_lsapic(acpi_handle handle, int
>> physid, int *pcpu)
>> }
>>
>> /* wrapper to silence section mismatch warning */
>> -int __ref acpi_map_cpu(acpi_handle handle, int physid, int *pcpu)
>> +int __ref acpi_map_cpu(acpi_handle handle, phys_cpuid_t physid, int *pcpu)
>> {
>> return _acpi_map_lsapic(handle, physid, pcpu);
>> }
>> diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
>> index 3a45668..cd788dd 100644
>> --- a/arch/x86/include/asm/acpi.h
>> +++ b/arch/x86/include/asm/acpi.h
>> @@ -32,6 +32,10 @@
>> #include
>> #include
>>
>> +typedef u32 phys_cpuid_t;
>> +
>> +#define CPU_PHYS_ID_INVALID (u32)(-1)
> Can we define those things in one common place instead of having to duplicate
> the definitions for every arch?
As in your reply in patch 14/21, ARM64 will use 64-bit for
phys_cpuid_t.
>
> Also, I'd like to have
>
> static inline bool invalid_cpu_phys_id(phys_cpuid_t phys_id)
> {
> return (int)phys_id < 0;
> }
>
> as that would cover error codes too.
>
> Moreover, why don't you use (phys_cpuid_t)(-1) in the #define? And call is
> PHYS_CPUID_INVALID for that matter (so that the name of the symbol corresponds
> to the name of the type)?
That's pretty fine to me too.
>
>
>> +
>> #ifdef CONFIG_ACPI
>> extern int acpi_lapic;
>> extern int acpi_ioapic;
>> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
>> index 3d525c6..e4f8582 100644
>> --- a/arch/x86/kernel/acpi/boot.c
>> +++ b/arch/x86/kernel/acpi/boot.c
>> @@ -757,7 +757,7 @@ static int _acpi_map_lsapic(acpi_handle handle, int
>> physid, int *pcpu)
>> }
>>
>> /* wrapper to silence section mismatch warning */
>> -int __ref acpi_map_cpu(acpi_handle handle, int physid, int *pcpu)
>> +int __ref acpi_map_cpu(acpi_handle handle, phys_cpuid_t physid, int *pcpu)
>> {
>> return _acpi_map_lsapic(handle, physid, pcpu);
>> }
>> diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
>> index 1020b1b..e6c7c56 100644
>> --- a/drivers/acpi/acpi_processor.c
>> +++ b/drivers/acpi/acpi_processor.c
>> @@ -170,7 +170,7 @@ static int acpi_processor_hotadd_init(struct
>> acpi_processor *pr)
>> acpi_status status;
>> int ret;
>>
>> -if (pr->phys_id == -1)
>> +if (pr->phys_id == CPU_PHYS_ID_INVALID)
>> return -ENODEV;
>>
>> status = acpi_evaluate_integer(pr->handle, "_STA", NULL, );
>> @@ -215,7 +215,8 @@ static int acpi_processor_get_info(struct acpi_device
>> *device)
>> union acpi_object object = { 0 };
>> struct acpi_buffer buffer = { sizeof(union acpi_object), };
>> struct acpi_processor *pr = acpi_driver_data(device);
>> -int phys_id, cpu_index, device_declaration = 0;
>> +phys_cpuid_t phys_id;
>> +int cpu_index, device_declaration = 0;
>> acpi_status status = AE_OK;
>> static int cpu0_initialized;
>> unsigned long long value;
>> @@ -263,7 +264,7 @@ static
Re: [dmidecode] [Patch v3] firmware: dmi-sysfs: add SMBIOS entry point area raw attribute
Hi Ivan, On Wed, 04 Mar 2015 14:28:20 +0200, Ivan.khoronzhuk wrote: > On 02/26/2015 11:41 AM, Jean Delvare wrote: > > On Thu, 26 Feb 2015 09:50:42 +0100, Jean Delvare wrote: > >> Please also note that the recently released version 3.0.0 of the SMBIOS > >> specification introduces a new entry point format, and the firmware is > >> allowed to implement both the old and the new format. It may be > >> desirable to expose both to user-space under different names. > > > > Having read the kernel code meanwhile, I see we will call either > > dmi_smbios3_present or dmi_present successfully, not both, so > > presenting both entry points to user-space would be non-trivial. So I'm > > fine with presenting only one entry point in sysfs for the time being. > > We can always revisit later if it turns out that dmidecode really needs > > both in some cases. > > Why do you need two tables ? If kernel can parse the best one why > it should present the old one? The old is subset of new, so the new must > contain all required information, only format can be slightly different. > If dmidecode has problems in reading new version then dmidecode should > be modified, not kernel. It's not just two tables (I don't expect a lot of BIOSes to provide two tables in practice, and they would have essentially the same format anyway) but more importantly two entry points. The _SM3_ entry point is brand new and most applications (including dmidecode) don't support it yet. It doesn't matter if the kernel itself can parse it, as it passes the raw entry point to applications anyway. It happens that we are introducing this new sysfs raw interface at the same time _SM3_ is being introduced, so we do not have to care about backwards compatibility. Both the kernel and dmidecode will need to be updated to support the new interface, so we can keep things simple and let the kernel expose only the best entry point. If the sysfs raw interface was already present at the time _SM3_ support was being added, then we would have had to present both entry points for backwards compatibility. And if some _SM4_ entry point is ever added in the future with a new format, we will have to export it as a new sysfs attribute so as to not break compatibility. As a summary, I agree that a single entry point file is OK for now, but only because we are lucky that the timing is right. -- Jean Delvare SUSE L3 Support -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/4] init.h: Clean up the __setup()/early_param() macros
Make it all a bit easier on the eyes:
- Move the __setup_param() lines right after their init functions
- Use consistent vertical spacing
- Use more horizontal spacing to make it look like regular C code
- Use standard comment style
Cc: Luis R. Rodriguez
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Borislav Petkov
Cc: Dave Hansen
Cc: David Vrabel
Cc: Dexuan Cui
Cc: Greg Kroah-Hartman
Cc: H. Peter Anvin
Cc: Jan Beulich
Cc: Joonsoo Kim
Cc: Juergen Gross
Cc: Linus Torvalds
Cc: Pavel Machek
Cc: Thomas Gleixner
Cc: Tony Lindgren
Cc: Toshi Kani
Cc: Vlastimil Babka
Cc: Xishi Qiu
Cc: julia.law...@lip6.fr
Signed-off-by: Ingo Molnar
---
include/linux/init.h | 49 +++--
1 file changed, 27 insertions(+), 22 deletions(-)
diff --git a/include/linux/init.h b/include/linux/init.h
index bc11ff96f336..21b6d768edd7 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -253,34 +253,39 @@ struct obs_kernel_param {
* obs_kernel_param "array" too far apart in .init.setup.
*/
#define __setup_param(str, unique_id, fn, early) \
- static const char __setup_str_##unique_id[] __initconst \
- __aligned(1) = str; \
- static struct obs_kernel_param __setup_##unique_id \
- __used __section(.init.setup) \
- __attribute__((aligned((sizeof(long)\
+ static const char __setup_str_##unique_id[] __initconst \
+ __aligned(1) = str; \
+ static struct obs_kernel_param __setup_##unique_id \
+ __used __section(.init.setup) \
+ __attribute__((aligned((sizeof(long)\
= { __setup_str_##unique_id, fn, early }
-#define __setup(str, fn) \
+#define __setup(str, fn) \
__setup_param(str, fn, fn, 0)
-/* NOTE: fn is as per module_param, not __setup! Emits warning if fn
- * returns non-zero. */
-#define early_param(str, fn) \
+/*
+ * NOTE: fn is as per module_param, not __setup!
+ * Emits warning if fn returns non-zero.
+ */
+#define early_param(str, fn) \
__setup_param(str, fn, fn, 1)
-#define early_param_on_off(str_on, str_off, var, config)
\
- int var = IS_ENABLED(config); \
- static int __init parse_##var##_on(char *arg) \
- { \
- var = 1;\
- return 0; \
- } \
- static int __init parse_##var##_off(char *arg) \
- { \
- var = 0;\
- return 0; \
- } \
- __setup_param(str_on, parse_##var##_on, parse_##var##_on, 1); \
+#define early_param_on_off(str_on, str_off, var, config) \
+ \
+ int var = IS_ENABLED(config); \
+ \
+ static int __init parse_##var##_on(char *arg) \
+ { \
+ var = 1;\
+ return 0; \
+ } \
+ __setup_param(str_on, parse_##var##_on, parse_##var##_on, 1); \
+ \
+ static int __init parse_##var##_off(char *arg) \
+ { \
+ var = 0;\
+ return 0; \
+ } \
__setup_param(str_off, parse_##var##_off, parse_##var##_off, 1)
/* Relies on boot_command_line being set */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix do_mbind return value
On 03/05/2015 12:53 AM, David Rientjes wrote:
On Wed, 4 Mar 2015, Kazutomo Yoshii wrote:
I noticed that numa_alloc_onnode() failed to allocate memory on a
specified node in v4.0-rc1. I added a code to check the return value
of walk_page_range() in queue_pages_range() so that do_mbind() only
returns an error number or zero.
I assume this is libnuma-2.0.10?
I used libnuma-2.0.9. Here is a strace output related to
numa_alloc_onnode()
mmap(NULL, 4194304, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) =
0x7fe9b8334000
mbind(0x7fe9b8334000, 4194304, MPOL_BIND, 0x1b43bf0, 1025, 0) = 1
I believe mbind() returning a positive number is just a wrong behavior.
A tricky part is that libnuma only checks a negative error,
so numa_alloc_onnode() itself didn't fail. I noticed this first when I
was checking
memory placement using the proc pagemap.
Signed-off-by: Kazutomo Yoshii
---
mm/mempolicy.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 4721046..ea79171 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -644,6 +644,7 @@ queue_pages_range(struct mm_struct *mm, unsigned long
start, unsigned long end,
.nmask = nodes,
.prev = NULL,
};
+ int err;
struct mm_walk queue_pages_walk = {
.hugetlb_entry = queue_pages_hugetlb,
.pmd_entry = queue_pages_pte_range,
@@ -652,7 +653,10 @@ queue_pages_range(struct mm_struct *mm, unsigned long
start, unsigned long end,
.private = ,
};
- return walk_page_range(start, end, _pages_walk);
+ err = walk_page_range(start, end, _pages_walk);
+ if (err < 0)
+ return err;
+ return 0;
}
/*
I'm afraid I don't think this is the right fix, if walk_page_range()
returns a positive value then it should be supplied by one of the
callbacks in the struct mm_walk, which none of these happen to do. I
think this may be a problem with commit 6f4576e3687b ("mempolicy: apply
page table walker on queue_pages_range()"), so let's add Naoya to the
thread.
Thank you for the pointer!
I think queue_pages_test_walk() returns 1.
My fix may not be in a right place but someone needs to fix this.
- kaz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: mediatek: Export CPU mux clocks for CPU frequency control
+Cc Viresh Kumar
Viresh, this is the patch for the underlying clocks for the Mediatek
cpufreq driver.
On Thu, Mar 05, 2015 at 10:43:21AM +0800, Pi-Cheng Chen wrote:
> Hi Sascha,
>
> On 4 March 2015 at 19:21, Sascha Hauer wrote:
> > On Wed, Mar 04, 2015 at 06:49:11PM +0800, pi-cheng.chen wrote:
> >> This patch adds CPU mux clocks which are used by Mediatek cpufreq driver
> >> for intermediate clock source switching. This patch is based on Mediatek
> >> clock driver patches[1].
> >>
> >> [1] http://thread.gmane.org/gmane.linux.kernel/1892436
> >>
> >> Signed-off-by: pi-cheng.chen
> >> ---
> >> +static long clk_cpumux_determine_rate(struct clk_hw *hw, unsigned long
> >> rate,
> >> + unsigned long min_rate,
> >> + unsigned long max_rate,
> >> + unsigned long *best_parent_rate,
> >> + struct clk_hw **best_parent_p)
> >> +{
> >> + struct clk *clk = hw->clk, *parent;
> >> + unsigned long parent_rate;
> >> + int i;
> >> +
> >> + for (i = MAINPLL_INDEX; i >= ARMPLL_INDEX; i--) {
> >> + parent = clk_get_parent_by_index(clk, i);
> >> + if (!parent)
> >> + return 0;
> >> +
> >> + if (i == MAINPLL_INDEX) {
> >> + parent_rate = __clk_get_rate(parent);
> >> + if (parent_rate == rate)
> >> + break;
> >> + }
> >> +
> >> + parent_rate = __clk_round_rate(parent, rate);
> >> + }
> >> +
> >> + *best_parent_rate = parent_rate;
> >> + *best_parent_p = __clk_get_hw(parent);
> >> + return parent_rate;
> >> +}
> >
> > Why this determine_rate hook? If you want to switch the clock to some
> > intermediate parent I would assume you do this explicitly by setting the
> > parent and not implicitly by setting a rate.
> >
>
> I use determine_rate hook here because I am using generic cpufreq-dt
> driver and I want to make clock switching transparent to cpufreq-dt.
> I.e. when I am trying to switch the clock from ARMPLL to MAINPLL, I
> call clk_set_rate() with the rate of MAINPLL, and determine_rate will
> select MAINPLL as the new parent.
We have clk_set_parent for changing the parent and clk_set_rate to
change the rate. Use the former for changing the parent and the latter
for changing the rate. What you are interested in is changing the
parent, so use clk_set_parent for this and not abuse a side effect
of clk_set_rate.
My suggestion is to take another approach. Implement clk_set_rate for
these muxes and in the set_rate hook:
- switch mux to intermediate PLL parent
- call clk_set_rate() for the real parent PLL
- switch mux back to real parent PLL
This way the things happening behind the scenes are completely transparent
to the cpufreq driver and you can use cpufreq-dt as is without changes.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch -rt 1/2] KVM: use simple waitqueue for vcpu->wq
On 03/05/2015 02:09 AM, Marcelo Tosatti wrote: >> Can you please include the series? >> >> Thanks > > Sebastian? I will pick it up, don't worry. I think I do my -RT day tomorrow. Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
checkpatch spell checking (was: Re: [Intel-gfx] [PATCH] drm/i915: Reudce CHV DPLL min vco frequency to 4.8 GHz)
On Wed, 04 Mar 2015, Ville Syrjälä wrote: > On Wed, Mar 04, 2015 at 08:11:38PM +0530, Purushothaman, Vijay A wrote: >> Minor nitpick: typo in patch title > > Dang. I already fixed a typo there before sending this out, but turns > out I only managed to cchange it into a different typo :( Maybe I need > to invest in a spell checker... These days checkpatch.pl does some of this for you (see scripts/spelling.txt). However your "reudce" isn't there, and, more importantly, AFAICT checkpatch.pl does not look at the patch subject anyway. Joe, Andy, hint, hint. ;) BR, Jani. -- Jani Nikula, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/1] DT: video: atmel_lcdc: Add example of fixed framebuffer memory
This drivers allows a fixed framebuffer memory to be set by an additional
IORESOURCE_MEM resource. Thus add an example to the DT documentation.
Signed-off-by: Alexander Stein
Acked-by: Nicolas Ferre
---
Changes in v2:
* Fix typo noticed by checkpatch.pl
Documentation/devicetree/bindings/video/atmel,lcdc.txt | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/video/atmel,lcdc.txt
b/Documentation/devicetree/bindings/video/atmel,lcdc.txt
index f059dd0..ecb8da0 100644
--- a/Documentation/devicetree/bindings/video/atmel,lcdc.txt
+++ b/Documentation/devicetree/bindings/video/atmel,lcdc.txt
@@ -10,7 +10,9 @@ Required properties:
"atmel,at91sam9g45es-lcdc" ,
"atmel,at91sam9rl-lcdc" ,
"atmel,at32ap-lcdc"
-- reg : Should contain 1 register ranges(address and length)
+- reg : Should contain 1 register ranges(address and length).
+ Can contain an additional register range(address and length)
+ for fixed framebuffer memory. Useful for dedicated memories.
- interrupts : framebuffer controller interrupt
- display: a phandle pointing to the display node
@@ -38,6 +40,14 @@ Example:
};
+Example for fixed framebuffer memory:
+
+ fb0: fb@0x0050 {
+ compatible = "atmel,at91sam9263-lcdc";
+ reg = <0x0070 0x1000 0x7000 0x20>;
+ [...]
+ };
+
Atmel LCDC Display
-
Required properties (as per of_videomode_helper):
--
2.0.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Re: unbind/bind w1-gpio with device tree produce a crash
Hi Ingo,
On Thu, Mar 05, 2015 at 03:56:20AM +0100, Ingo Flaschberger wrote:
> Dear Markus,
>
> as I get no answer at the kernel mailinglist:
> your patch to use devm_kzalloc instead of kzalloc produce driver crashes
> when the 1wire bus is unbound and bound again (see details below).
>
> What do you suggest to solve this problem?
Good point. The easy way to solve this may be to check in the remove
function if the devicetree node for this device is available. If it is,
we know that platform_data was allocated with devm_* and we can set
platform_data to NULL.
I think the better solution would be to create a private structure with
the same data as w1_gpio_platform_data. It may even use the same struct.
But it should not be stored in platform_data. Instead it should be
handled seperately. For DT we can allocate it using devm_kzalloc(). And
for probing with pdata, this could just be the pointer to the pdata
within the device struct.
Adding the list as CC again.
Best Regards,
Markus
>
> Kind regards,
> Ingo Flaschberger
>
> Weitergeleitete Nachricht
> Betreff: Re: unbind/bind w1-gpio with device tree produce a crash
> Datum:Wed, 04 Mar 2015 17:38:48 +0100
> Von: Ingo Flaschberger
> An: linux-kernel@vger.kernel.org
>
>
>
> is it ok, to create a new global variable that tracks if pdata was
> alloced via devm_kzalloc and sets pdata to NULL in w1_gpio_remove?
>
> Am 04.03.2015 um 04:53 schrieb Ingo Flaschberger:
> >If w1-gpio is probed via device-tree configuration, pdata is allocated
> >via devm_kzalloc.
> >When the device is unbind (and bind later) the allocated memory of
> >pdate is freed - but it will not be allocacted again.
> >
> >static int w1_gpio_probe(struct platform_device *pdev)
> >struct w1_bus_master *master;
> >struct w1_gpio_platform_data *pdata = pdev->dev.platform_data;
> >int err;
> >
> >if(pdata == NULL) {
> >if (of_have_populated_dt()) {
> >err = w1_gpio_probe_dt(pdev);
> >if (err < 0)
> >return err;
> >}
> >}
> >
> >How to detect if pdata was allocated via device-tree devm_kzalloc and
> >not "hardcoded"?
> >Then I could set pdev->dev.platform_data to NULL in w1_gpio_remove
> >which will solve the crash.
> >
> >Kind regards,
> > Ingo Flascherger
> >
>
>
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: Digital signature
[PATCH] ipv4: ip_check_defrag should not assume that skb_network_offset is zero
ip_check_defrag() may be used by af_packet to defragment outgoing packets.
skb_network_offset() of af_packet's outgoing packets is not zero.
Signed-off-by: Alexander Drozdov
---
net/ipv4/ip_fragment.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
index 2c8d98e..145a50c 100644
--- a/net/ipv4/ip_fragment.c
+++ b/net/ipv4/ip_fragment.c
@@ -659,27 +659,30 @@ EXPORT_SYMBOL(ip_defrag);
struct sk_buff *ip_check_defrag(struct sk_buff *skb, u32 user)
{
struct iphdr iph;
+ int netoff;
u32 len;
if (skb->protocol != htons(ETH_P_IP))
return skb;
- if (skb_copy_bits(skb, 0, , sizeof(iph)) < 0)
+ netoff = skb_network_offset(skb);
+
+ if (skb_copy_bits(skb, netoff, , sizeof(iph)) < 0)
return skb;
if (iph.ihl < 5 || iph.version != 4)
return skb;
len = ntohs(iph.tot_len);
- if (skb->len < len || len < (iph.ihl * 4))
+ if (skb->len < netoff + len || len < (iph.ihl * 4))
return skb;
if (ip_is_fragment()) {
skb = skb_share_check(skb, GFP_ATOMIC);
if (skb) {
- if (!pskb_may_pull(skb, iph.ihl*4))
+ if (!pskb_may_pull(skb, netoff + iph.ihl * 4))
return skb;
- if (pskb_trim_rcsum(skb, len))
+ if (pskb_trim_rcsum(skb, netoff + len))
return skb;
memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
if (ip_defrag(skb, user))
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] cpufreq-dt: add clock domain and intermediate frequency support
On 5 March 2015 at 11:58, Viresh Kumar wrote: > On 5 March 2015 at 09:02, Pi-Cheng Chen wrote: >> In the case of Mediatek SoC, the intermediate frequency might not be one >> entry >> of OPP table. To elaborate, the source clock node of the CPUs/Cluster on >> Mediatek SoC is a mux. The mux has several PLLs as parents. When we are >> doing CPU frequency scaling, the mux should re-parent to another stable PLL, >> wait until the original parent PLL become stable, and then switch back to the >> original parent. In this case, we could but we might not want the >> intermediate >> frequency as part of OPP table. Therefore I save intermediate_freq instead of >> intermediate frequency index in the cpufreq_dt_platform_datat struct. > > Hmm, I remember that discussion. Okay leave it as is. Okay. > >> BTW, is this case that intermediate frequency is not necessarily be one entry >> of OPP table supported in the OPPv2 bindings? > > Not yet, but will add a property for that. Thanks for taking this case into consideration. Best Regards, Pi-Cheng -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/4] cpufreq: mediatek: add Mediatek cpufreq driver
Hi Viresh,
Thanks for reviewing.
Please see my reply below:
On 4 March 2015 at 19:09, Viresh Kumar wrote:
> Haven't reviewed it completely yet, but this is all I have done.
>
> On 4 March 2015 at 14:19, pi-cheng.chen wrote:
>
>> +static int mtk_cpufreq_notify(struct notifier_block *nb,
>> + unsigned long action, void *data)
>> +{
>> + struct cpufreq_freqs *freqs = data;
>> + struct cpu_opp_table *opp_tbl = dvfs_info->opp_tbl;
>
> There is only one dvfs info ? but there are two clusters, sorry got confused
> a bit..
There are 2 clusters, but only the big cluster need to do voltage scaling in the
notifier, since the voltage controlling is done by cpufreq-dt driver
in this version.
Therefore only one dvfs_info struct here.
>
>> + int old_vproc, new_vproc, old_index, new_index;
>> +
>> + if (!cpumask_test_cpu(freqs->cpu, _info->cpus))
>> + return NOTIFY_DONE;
>> +
>> + old_vproc = regulator_get_voltage(dvfs_info->proc_reg);
>> + old_index = cpu_opp_table_get_volt_index(old_vproc);
>> + new_index = cpu_opp_table_get_freq_index(freqs->new * 1000);
>> + new_vproc = opp_tbl[new_index].vproc;
>> +
>> + if (old_vproc == new_vproc)
>> + return 0;
>> +
>> + if ((action == CPUFREQ_PRECHANGE && old_vproc < new_vproc) ||
>> + (action == CPUFREQ_POSTCHANGE && old_vproc > new_vproc))
>> + mtk_cpufreq_voltage_trace(old_index, new_index);
>> +
>> + return NOTIFY_OK;
>> +}
>> +
>> +static struct notifier_block mtk_cpufreq_nb = {
>> + .notifier_call = mtk_cpufreq_notify,
>> +};
>> +
>> +static int cpu_opp_table_init(struct device *dev)
>> +{
>> + struct device *cpu_dev = dvfs_info->cpu_dev;
>> + struct cpu_opp_table *opp_tbl;
>> + struct dev_pm_opp *opp;
>> + int ret, cnt, i;
>> + unsigned long rate, vproc, vsram;
>> +
>> + ret = of_init_opp_table(cpu_dev);
>> + if (ret) {
>> + dev_err(dev, "Failed to init mtk_opp_table: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + rcu_read_lock();
>> +
>> + cnt = dev_pm_opp_get_opp_count(cpu_dev);
>> + if (cnt < 0) {
>> + dev_err(cpu_dev, "No OPP table is found: %d", cnt);
>> + ret = cnt;
>> + goto out_free_opp_tbl;
>> + }
>> +
>> + opp_tbl = devm_kcalloc(dev, (cnt + 1), sizeof(struct cpu_opp_table),
>> + GFP_ATOMIC);
>> + if (!opp_tbl) {
>> + ret = -ENOMEM;
>> + goto out_free_opp_tbl;
>> + }
>> +
>> + for (i = 0, rate = 0; i < cnt; i++, rate++) {
>> + opp = dev_pm_opp_find_freq_ceil(cpu_dev, );
>> + if (IS_ERR(opp)) {
>> + ret = PTR_ERR(opp);
>> + goto out_free_opp_tbl;
>> + }
>> +
>> + vproc = dev_pm_opp_get_voltage(opp);
>> + vproc = get_regulator_voltage_ceil(dvfs_info->proc_reg,
>> vproc);
>> + vsram = vproc + VOLT_SHIFT_LOWER_LIMIT;
>> + vsram = get_regulator_voltage_ceil(dvfs_info->sram_reg,
>> vsram);
>> +
>> + if (vproc < 0 || vsram < 0) {
>> + ret = -EINVAL;
>> + goto out_free_opp_tbl;
>> + }
>> +
>> + opp_tbl[i].freq = rate;
>> + opp_tbl[i].vproc = vproc;
>> + opp_tbl[i].vsram = vsram;
>> + }
>> +
>> + opp_tbl[i].freq = 0;
>> + opp_tbl[i].vproc = -1;
>> + opp_tbl[i].vsram = -1;
>> + dvfs_info->opp_tbl = opp_tbl;
>> +
>> +out_free_opp_tbl:
>> + rcu_read_unlock();
>> + of_free_opp_table(cpu_dev);
>> +
>> + return ret;
>> +}
>> +
>> +static struct cpufreq_cpu_domain *get_cpu_domain(struct list_head
>> *domain_list,
>> +int cpu)
>> +{
>> + struct list_head *node;
>> +
>> + list_for_each(node, domain_list) {
>> + struct cpufreq_cpu_domain *domain;
>> +
>> + domain = container_of(node, struct cpufreq_cpu_domain, node);
>> + if (cpumask_test_cpu(cpu, >cpus))
>> + return domain;
>> + }
>> +
>> + return NULL;
>> +}
>> +
>> +static int mtk_cpufreq_probe(struct platform_device *pdev)
>
> On a dual cluster big LITTLE (your system), how many times is probe
> getting called ? Once or twice, i.e. for each cluster ??
The probe function will be called only once since it's triggered by the device
tree node in the 2nd patch of this series. Though it's not acceptable obviously.
>
>> +{
>> + struct clk *inter_clk;
>> + struct cpufreq_dt_platform_data *pd;
>> + struct platform_device *dev;
>> + unsigned long inter_freq;
>> + int cpu, ret;
>> +
>> + inter_clk = clk_get(>dev, NULL);
>
> How is this supposed to work ? How will pdev->dev give intermediate
>
[PATCH 6/4] x86/mm: Simplify probe_page_size_mask()
Now that we've simplified the gbpages config space, move the
'page_size_mask' initialization into probe_page_size_mask(), right
next to the PSE and PGE enablement lines.
Cc: Luis R. Rodriguez
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Borislav Petkov
Cc: Dave Hansen
Cc: David Vrabel
Cc: Dexuan Cui
Cc: Greg Kroah-Hartman
Cc: H. Peter Anvin
Cc: jbeul...@suse.com
Cc: Jan Beulich
Cc: Joonsoo Kim
Cc: Juergen Gross
Cc: Linus Torvalds
Cc: Pavel Machek
Cc: Thomas Gleixner
Cc: Tony Lindgren
Cc: Toshi Kani
Cc: Vlastimil Babka
Cc: Xishi Qiu
Cc: julia.law...@lip6.fr
Signed-off-by: Ingo Molnar
---
arch/x86/mm/init.c | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 8704153f2675..6dc85d51cd98 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -131,29 +131,18 @@ void __init early_alloc_pgt_buf(void)
int after_bootmem;
-static int page_size_mask;
-
early_param_on_off("gbpages", "nogbpages", direct_gbpages,
CONFIG_X86_DIRECT_GBPAGES);
-static void __init init_gbpages(void)
-{
- if (direct_gbpages && cpu_has_gbpages) {
- printk(KERN_INFO "Using GB pages for direct mapping\n");
- page_size_mask |= 1 << PG_LEVEL_1G;
- } else
- direct_gbpages = 0;
-}
-
struct map_range {
unsigned long start;
unsigned long end;
unsigned page_size_mask;
};
+static int page_size_mask;
+
static void __init probe_page_size_mask(void)
{
- init_gbpages();
-
#if !defined(CONFIG_DEBUG_PAGEALLOC) && !defined(CONFIG_KMEMCHECK)
/*
* For CONFIG_DEBUG_PAGEALLOC, identity mapping will use small pages.
@@ -173,6 +162,14 @@ static void __init probe_page_size_mask(void)
cr4_set_bits_and_update_boot(X86_CR4_PGE);
__supported_pte_mask |= _PAGE_GLOBAL;
}
+
+ /* Enable 1 GB linear kernel mappings if available: */
+ if (direct_gbpages && cpu_has_gbpages) {
+ printk(KERN_INFO "Using GB pages for direct mapping\n");
+ page_size_mask |= 1 << PG_LEVEL_1G;
+ } else {
+ direct_gbpages = 0;
+ }
}
#ifdef CONFIG_X86_32
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/4] x86/mm: Further simplify 1 GB kernel linear mappings handling
It's a bit pointless to allow Kconfig configuration for 1GB kernel
mappings, it's already hidden behind a 'default y' and CONFIG_EXPERT.
Remove this complication and simplify the code by renaming
CONFIG_ENABLE_DIRECT_GBPAGES to CONFIG_X86_DIRECT_GBPAGES and
document the DEBUG_PAGE_ALLOC and KMEMCHECK quirks.
Cc: Luis R. Rodriguez
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Borislav Petkov
Cc: Dave Hansen
Cc: David Vrabel
Cc: Dexuan Cui
Cc: Greg Kroah-Hartman
Cc: H. Peter Anvin
Cc: jbeul...@suse.com
Cc: Jan Beulich
Cc: Joonsoo Kim
Cc: Juergen Gross
Cc: Linus Torvalds
Cc: Pavel Machek
Cc: Thomas Gleixner
Cc: Tony Lindgren
Cc: Toshi Kani
Cc: Vlastimil Babka
Cc: Xishi Qiu
Cc: julia.law...@lip6.fr
Signed-off-by: Ingo Molnar
---
arch/x86/Kconfig | 23 +++
arch/x86/mm/init.c | 7 +--
2 files changed, 8 insertions(+), 22 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 4d06e1c8294a..54d528a37ff4 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1299,22 +1299,13 @@ config ARCH_DMA_ADDR_T_64BIT
def_bool y
depends on X86_64 || HIGHMEM64G
-config ENABLE_DIRECT_GBPAGES
- def_bool y
- depends on X86_64 && !DEBUG_PAGEALLOC && !KMEMCHECK
-
-config DIRECT_GBPAGES
- bool "Enable 1GB pages for kernel pagetables" if EXPERT
- default y
- depends on ENABLE_DIRECT_GBPAGES
- ---help---
- Enable by default the kernel linear mapping to use 1GB pages on CPUs
- that support it. This can improve the kernel's performance a tiny bit
- by reducing TLB pressure. If in doubt, say "Y". If you've disabled
- option but your platform is capable of handling support for this
- you can use the gbpages kernel parameter. Likewise if you've enabled
- this but you'd like to force disable this option you can use the
- nogbpages kernel parameter.
+config X86_DIRECT_GBPAGES
+ def_bool (X86_64 && !DEBUG_PAGEALLOC && !KMEMCHECK)
+ ---help---
+ Certain kernel features effectively disable kernel
+ linear 1 GB mappings (even if the CPU otherwise
+ supports them), so don't confuse the user by printing
+ that we have them enabled.
# Common NUMA Features
config NUMA
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index c35ba8bce7cb..8704153f2675 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -133,15 +133,10 @@ int after_bootmem;
static int page_size_mask;
-early_param_on_off("gbpages", "nogbpages",
- direct_gbpages, CONFIG_DIRECT_GBPAGES);
+early_param_on_off("gbpages", "nogbpages", direct_gbpages,
CONFIG_X86_DIRECT_GBPAGES);
static void __init init_gbpages(void)
{
- if (!IS_ENABLED(CONFIG_ENABLE_DIRECT_GBPAGES)) {
- direct_gbpages = 0;
- return;
- }
if (direct_gbpages && cpu_has_gbpages) {
printk(KERN_INFO "Using GB pages for direct mapping\n");
page_size_mask |= 1 << PG_LEVEL_1G;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] workqueue: update numa affinity when node hotplug
On 2015/03/05 10:23, Gu Zheng wrote: Hi Kamazawa-san, On 03/04/2015 01:45 PM, Kamezawa Hiroyuki wrote: On 2015/03/03 22:18, Tejun Heo wrote: Hello, Kame. On Tue, Mar 03, 2015 at 03:53:46PM +0900, Kamezawa Hiroyuki wrote: relationship between proximity domain and lapic id doesn't change. relationship between lapic-id and cpu-id changes. pxm <-> memory address : no change pxm <-> lapicid : no change pxm <-> node id : no change lapicid <-> cpu id : change. So, we're changing the cpu ID to NUMA node mapping because current NUMA code is ignoring PXM for memoryless nodes? That's it? For memory-less node case, yes. Another problem is that lapicid <-> cpuid relationship is not persistent. I personally thinks proper fix is building persistent cpu-id <-> lapicid relationship as pxm does rather than creating band-aid. Oh if this is possible, I agree that's the right direction too. Implementation is a bit complicated now :(. Ah well, even then, the obviously right thing to do is updating NUMA code to always keep track of PXM information. We don't really want to pile NUMA hacks in random users of NUMA code. We'd like to start from making apicid <-> cpuid persistent because memory-less node case doesn't cause panic. Gu-san, how do you think ? Fine by me. But it seems that the change will break the re-use of free cpuid when hot add new cpus, I am afraid it may affect other sub-systems, though I can not point out the specific example. That may be concern. But, IHMO, applications should not expect cpuid of newly added cpu. If an application takes care of placement of [thread, memory], OS API should be refreshed to allow user to tell "please pleace [thread, memory] nearby each other" rather than specifying [cpu, memory]. (As Peter Z.'s schedNUMA) If application takes care of physical placement of hardware, ethernet, SSD, etc... it should not depends on cpuid. Some of required features may not be archived yet but cpuid of newly added cpu should not be a big problem for applications, I think. Open dicussion with (x86/sched/mm) maintainers will be required, anyway. I think it's worth trying. Thanks, -Kame -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] crypto: caam: fix some compile warnings
On 03/04/2015 08:34 PM, Kim Phillips wrote: > I don't see how, e.g., for one, dma_map_sg is I/O TLB > implementation-dependent. I'll need some remedial classes on this topic, but for the moment I don't see how this matters for mapping sg chains. Can you share some pointers? Thanks, Cristian S. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 00/21] Introduce ACPI for ARM64 based on ACPI 5.1
On 2015/3/5 6:56, Rafael J. Wysocki wrote: > On Wednesday, February 25, 2015 04:39:40 PM Hanjun Guo wrote: >> Changes since v8: >> - remove MPIDR packing things by introducing phys_cpuid_t; >> >> - update patch acpi: fix acpi_os_ioremap for arm64 to follow >> Rafael's suggestion; >> >> - Squash patch (disable ACPI if ACPI less than 5.1) to patch >> (Get RSDP and ACPI boot-time table); >> >> - Move sleep_arm.c to arch/arm64/ and rename it as acpi_sleep.c >> >> - Rework the uefi generated empty dtb to enable acpi when no dtb >> is available, thanks Ard for the updated patch. >> >> - rework the function of register cpu for kexec case >> >> - use pr_debug() instead of pr_info() when scanning MADT. >> >> - rebase on top of 4.0-rc1 >> >> Thanks >> Hanjun >> >> Al Stone (4): >> ARM64 / ACPI: Get RSDP and ACPI boot-time tables >> ARM64 / ACPI: Introduce early_param "acpi=" to enable/disable ACPI >> ARM64 / ACPI: Select ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on >> ARM64 >> ARM64 / ACPI: additions of ACPI documentation for arm64 >> >> Graeme Gregory (6): >> ACPI: add arm64 to the platforms that use ioremap >> ACPI / sleep: Introduce arm64 specific acpi_sleep.c >> ARM64 / ACPI: If we chose to boot from acpi then disable FDT >> ARM64 / ACPI: Get PSCI flags in FADT for PSCI init >> ARM64 / ACPI: Enable ARM64 in Kconfig >> Documentation: ACPI for ARM64 >> >> Hanjun Guo (8): >> ACPI / table: Use pr_debug() instead of pr_info() for MADT table >> scanning >> ACPI / processor: Introduce phys_cpuid_t for CPU hardware ID >> ARM64 / ACPI: Introduce PCI stub functions for ACPI >> ACPI / table: Print GIC information when MADT is parsed >> ARM64 / ACPI: Parse MADT for SMP initialization >> ACPI / processor: Make it possible to get CPU hardware ID via GICC >> ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi >> clocksource / arch_timer: Parse GTDT to initialize arch timer >> >> Mark Salter (2): >> ARM64: allow late use of early_ioremap >> ACPI: fix acpi_os_ioremap for arm64 >> >> Tomasz Nowicki (1): >> irqchip: Add GICv2 specific ACPI boot support > I've ACKed or commented the ones relevant for me. As for the ARM64-specific > code, I don't think I can give any meaningful input. Hi Rafael, thank you very much for the ACKs and review comments, I will wait for other maintainers comments and then update this patch set. Regards Hanjun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V8 00/10] USB: f81232: V8 patches
On Thu, Mar 05, 2015 at 01:59:45PM +0800, Peter Hung wrote: > Did you received the series of F81232 V8 patches ? Please tell me if > not received. I got it. I just haven't had time to look at it yet. Will try to do so this week. Johan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] locks: fix fasync_struct memory leak in lease upgrade/downgrade handling
Hi Jeff, On 03/05/2015 01:06 AM, Jeff Layton wrote: > Commit 8634b51f6ca2 (locks: convert lease handling to file_lock_context) > introduced a regression in the handling of lease upgrade/downgrades. > > In the event that we already have a lease on a file and are going to > either upgrade or downgrade it, we skip doing any list insertion or > deletion and skip to re-calling lm_setup on the existing lease. > > As of commit 8634b51f6ca2 however, we end up calling lm_setup on the > lease that was passed in, instead of on the existing lease. This causes > us to leak the fasync_struct that was allocated in the event that there > was not already an existing one (as it always appeared that there > wasn't one). > > Fixes: 8634b51f6ca2 (locks: convert lease handling to file_lock_context) Yes, that fixes the problem. Thanks! > Reported-by: Daniel Wagner > Signed-off-by: Jeff Layton Tested-by: Daniel Wagner cheers, daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix do_mbind return value
On Wed, 4 Mar 2015, Kazutomo Yoshii wrote:
> I noticed that numa_alloc_onnode() failed to allocate memory on a
> specified node in v4.0-rc1. I added a code to check the return value
> of walk_page_range() in queue_pages_range() so that do_mbind() only
> returns an error number or zero.
>
I assume this is libnuma-2.0.10?
> Signed-off-by: Kazutomo Yoshii
> ---
> mm/mempolicy.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
> index 4721046..ea79171 100644
> --- a/mm/mempolicy.c
> +++ b/mm/mempolicy.c
> @@ -644,6 +644,7 @@ queue_pages_range(struct mm_struct *mm, unsigned long
> start, unsigned long end,
> .nmask = nodes,
> .prev = NULL,
> };
> + int err;
> struct mm_walk queue_pages_walk = {
> .hugetlb_entry = queue_pages_hugetlb,
> .pmd_entry = queue_pages_pte_range,
> @@ -652,7 +653,10 @@ queue_pages_range(struct mm_struct *mm, unsigned long
> start, unsigned long end,
> .private = ,
> };
> -return walk_page_range(start, end, _pages_walk);
> + err = walk_page_range(start, end, _pages_walk);
> + if (err < 0)
> + return err;
> + return 0;
> }
> /*
I'm afraid I don't think this is the right fix, if walk_page_range()
returns a positive value then it should be supplied by one of the
callbacks in the struct mm_walk, which none of these happen to do. I
think this may be a problem with commit 6f4576e3687b ("mempolicy: apply
page table walker on queue_pages_range()"), so let's add Naoya to the
thread.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 14/15] twl4030_charger: Increase current carefully while watching voltage.
On Mon, 2 Mar 2015 22:29:45 +0100 Pavel Machek wrote:
> On Tue 2015-02-24 15:33:53, NeilBrown wrote:
> > The USB Battery Charging spec (BC1.2) suggests a dedicated
> > charging port can deliver from 0.5 to 5.0A at between 4.75 and 5.25
> > volts.
> >
> > To choose the "correct" current voltage setting requires a trial
> > and error approach: try to draw current and see if the voltage drops
> > too low.
> >
> > Even with a configure Standard Downstream Port, it may not be possible
> > to reliably pull 500mA - depending on cable quality and source
>
> "configured"?
>
> > quality I have reports of charging failure due to the voltage dropping
> > too low.
> >
> > To address both these concern, this patch introduce incremental
>
> concerns.
>
> > current setting.
> > The current pull from VBUS is increased in steps of 20mA every 100ms
> > until the target is reached or until the measure voltage drops below
> > 4.75V. If the voltage does go too long, the target current is reduced
>
> "too low"?
>
> > by 20mA and kept there.
> >
> > This applies to currents selected automatically, or to values
> > set via sysfs. So setting a large value will cause the maximum
> > available to be used - up to the limit of 1.7mA imposed by the
> > hardware.
>
> 1.7A?
>
>
> > @@ -249,8 +261,14 @@ static int twl4030_charger_update_current(struct
> > twl4030_bci *bci)
> > cur = bci->ac_cur;
> > bci->ac_is_active = 1;
> > } else {
> > - cur = bci->usb_cur;
> > + cur = bci->usb_cur_actual;
>
> usb_cur_actual is not a really great variable name...
I changed "usb_cur" to "usb_cur_target" and
"usb_cur_actual" to "usb_cur".
>
> > bci->ac_is_active = 0;
> > + if (cur > bci->usb_cur) {
> > + cur = bci->usb_cur;
> > + bci->usb_cur_actual = cur;
> > + }
> > + if (cur < bci->usb_cur)
> > + schedule_delayed_work(>current_worker,
> > USB_CUR_DELAY);
> > }
> >
> > /* First, check thresholds and see if cgain is needed */
> > @@ -379,6 +397,38 @@ static int twl4030_charger_update_current(struct
> > twl4030_bci *bci)
> > return 0;
> > }
> >
> > +static void twl4030_current_worker(struct work_struct *data)
> > +{
> > + int v;
> > + int res;
> > + struct twl4030_bci *bci = container_of(data, struct twl4030_bci,
> > + current_worker.work);
> > +
> > + res = twl4030bci_read_adc_val(TWL4030_BCIVBUS);
> > + if (res < 0)
> > + v = 0;
> > + else
> > + /* BCIVBUS uses ADCIN8, 7/1023 V/step */
> > + v = res * 6843;
> > +
> > + printk("v=%d cur=%d target=%d\n", v, bci->usb_cur_actual,
> > + bci->usb_cur);
> > +
> > + if (v < USB_MIN_VOLT) {
> > + /* Back up and stop adjusting. */
> > + bci->usb_cur_actual -= USB_CUR_STEP;
> > + bci->usb_cur = bci->usb_cur_actual;
> > + } else if (bci->usb_cur_actual >= bci->usb_cur ||
> > + bci->usb_cur_actual + USB_CUR_STEP > USB_MAX_CURRENT) {
> > + /* Reach target and volts are OK - stop */
>
> Reached ... and the voltage is OK - stop.
>
>
Thanks for all your proof-reading :-)
NeilBrown
pgpWQFKsYY701.pgp
Description: OpenPGP digital signature
Re: [GIT PULL 00/21] perf/core improvements and fixes
On 4 March 2015 at 22:37, Ingo Molnar wrote: > > * Victor Kamensky wrote: > >> Hi Arnaldo, Ingo, >> >> What happened with this pull request? [...] > > This pull request was for v4.1, and I merged it in: Ok, I got it. Sorry I missed that before. > commit 8a26ce4e544659256349551283414df504889a59 > Merge: acba3c7e4652 726f3234dd12 > Author: Ingo Molnar > Date: Wed Feb 18 19:14:54 2015 +0100 > > Merge tag 'perf-core-for-mingo' of > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core > > Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo: > > User visible changes: > >> [...] I already see in v4.0-rc2 changes additions to one requested >> by this pull request, but I don't see this series itself. >> >> For example e370a3d57664cd5e39c0b95d157ebc841b568409 >> "perf symbols: Define EM_AARCH64 for older OSes" by David >> is already in v4.0-rc2 and it is supposed to be addition to >> "perf symbols: Ignore mapping symbols on aarch64" that is part >> of this pull request but it did not make into v4.0-rcX yet. Looks >> quite strange. > > If some commits of the v4.1 queue are needed in v4.0 as well then they > should be cherry-picked back into the urgent queue. > > But maybe e370a3d57 was merged prematurely - in that case it appears > to be harmless and v4.1 will sort it out. Yes, this merge is harmless. Indeed it should be OK with v4.1. Thanks for explanation. - Victor > Arnaldo? > > Thanks, > > Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5] x86: mce: kexec: switch MCE handler for kexec/kdump
On Thu, Mar 05, 2015 at 01:24:47AM +, Horiguchi Naoya(堀口 直也) wrote:
> On Wed, Mar 04, 2015 at 11:12:33PM +, Luck, Tony wrote:
> > > - fixed AR and UC order in enum severity_level because UC is severer than
> > > AR
> > > by definition. Current code is not affected by this wrong order by
> > > chance.
> >
> > AR and AO are both UC errors - that happen also to be recoverable.
>
> Maybe just saying "UC" might be confusing, meaning "UC bit is set" or "type of
> error (defined in Table SDM's Table 15-6 in vol.3B) is 'Uncorrected Error'
> (clearly separate from SRAR/SRAO)". You seem to mean the former, and I meant
> the latter. So I should write the description more accurately like
> "UC=1,PCC=0"
> error and "UC=1,PCC=1" error.
>
> > Are you really sure
> > about this re-order not affecting existing code?
>
> Sorry, I thought I checked that but I missed one, so let me check again now.
> I checked all referencing site of MCE_*_SEVERITY. Most of them are using '=='
> to compare the severity, where the re-order doesn't affect them.
> Some are using inequalities:
>
> - around ./arch/x86/kernel/cpu/mcheck/mce.c:720,
>
> if (mce_severity(m, mca_cfg.tolerant, msg, true) >=
> MCE_PANIC_SEVERITY)
>
> , the re-order doesn't affect.
>
> - ./arch/x86/kernel/cpu/mcheck/mce.c:819:
>
> if (m && global_worst >= MCE_PANIC_SEVERITY && mca_cfg.tolerant < 3)
>
> , the re-order doesn't affect.
>
> - ./arch/x86/kernel/cpu/mcheck/mce.c:832:
>
> if (global_worst <= MCE_KEEP_SEVERITY && mca_cfg.tolerant < 3)
>
> , ditto.
>
> - ./arch/x86/kernel/cpu/mcheck/mce.c:1196:
>
> no_way_out = worst >= MCE_PANIC_SEVERITY;
>
> , ditto.
>
> - ./arch/x86/kernel/cpu/mcheck/mce-severity.c:211:
>
> if (s->sev >= MCE_UC_SEVERITY && ctx == IN_KERNEL) {
>
> , the re-order should change to s->sev >= MCE_AR_SEVERITY to keep the
> kernel behavior.
>
> So I fixed the last part to be included in the re-order patch.
>
> > You might well be right, but as every one
> > else has pointed out mce_severity() is full of odd subtleties that catch
> > people out.
>
> I agree that this one big table is hard to maintain and bug-prone. One problem
> is that it has too many fields to check so the parameter space is huge. I
> think
> some field are checked only once, so separating it out makes table more simple
> and readable.
>
> > Is the "UC" entry at the end of the severities[] table just a catch-all for
> > things that made it
> > past all the other entries? Does it ever really get used?
>
> I read through the severity check table and it seems that all UC=1 case
> are already considered by the above entries, so it seems not used.
>
> > What was the test case that made you promote UC above AR?
>
> I thought of "Action required but unaffected thread is continuable" case
> on kexec kernel, but I'm not sure that such a case really happens.
> My motivation on the promotion was mainly from what SDM says rather than
> the real testcase.
>
> > This absolutely should not be buried in the middle of your other patch - it
> > needs to
> > be separate with a much more than two lines of commit description.
>
> OK, I might not include this part in this series in later post, but if I do,
> I'll separete it out.
Although I don't think we finished the discussion over v4, I updated the
patch to reflect your feedbacks so far.
Of cource, if you still have some comment about the previous version, I'm
glad to hear that.
Thanks,
Naoya Horiguchi
From bf4ce58b8296774a69e5436f43e8dc9eed41a829 Mon Sep 17 00:00:00 2001
From: Naoya Horiguchi
Date: Thu, 5 Mar 2015 15:28:23 +0900
Subject: [PATCH v5] x86: mce: kexec: switch MCE handler for kexec/kdump
kexec disables (or "shoots down") all CPUs other than a crashing CPU before
entering the 2nd kernel. But the MCE handler is still enabled after that,
so if MCE happens and broadcasts over the CPUs after the main thread starts
the 2nd kernel (which might not initialize MCE device yet, or might decide
not to enable it,) MCE handler runs only on the other CPUs (not on the main
thread,) leading to kernel panic with MCE synchronization. The user-visible
effect of this bug is kdump failure.
Our standard MCE handler do_machine_check() assumes some about system's
status and it's hard to alter it to cover kexec/kdump context, so let's add
another kdump-specific one and switch to it.
Note that this problem exists since current MCE handler was implemented in
2.6.32, and recently commit 716079f66eac ("mce: Panic when a core has reached
a timeout") made it more visible by changing the default behavior of the
synchronization timeout from "ignore" to "panic".
Signed-off-by: Naoya Horiguchi
Cc: [2.6.32+]
---
ChangeLog v4 -> v5:
- drop MCE_UC/AR_SEVERITY re-ordering
- move most of code to arch/x86/kernel/crash.c
- export some MCE internal variables/routines via arch/x86/include/asm/mce.h
Re: [PATCH 15/15] twl4030_charger: assume a 'charger' can supply maximum current.
On Mon, 2 Mar 2015 22:29:39 +0100 Pavel Machek wrote: > On Tue 2015-02-24 15:33:53, NeilBrown wrote: > > If it cannot, we will stop pulling more current when voltage drops. > > Can you justify it a bit more? > > I mean... maybe there's a fuse in the charger? Or maybe it will supply > the current but overheat in the process? (USB_MAX_CURRENT is 500mA or > 1.7A?) USB_MAX_CURRENT is 1.7A - the most the twl4030 will manage. The relevant specs say that a charger can deliver from 0.5A to 5.0A at between 4.75 and 5.25 volts. They don't, as far as I can tell, describe how a gadget can determine where in those ranges the charger is actually happy. My understanding of electronics suggests that if you start to pull too much current, the voltage will start to drop. It is that voltage drop across internal resistance which causes over-heating. So if voltage is above 4.75 volts, it seems reasonable to assume that the charger is happy. The code currently (see previous patch) ramps up the current until the voltage drops below 4.75, or until the maximum is reached. If the voltage drops, it backs off. The current should only be too high for 100ms. Hopefully not too long. I'm very open if anyone can suggest a more safe way to make full use of a charger without risking excess current draw, but I cannot find one. Maybe I should measure the unloaded voltage, and not let it drop more than 0.25V below that? I'm also very open to someone finding out how to get the twl4030 to detect a "D+ and D- shorted" charger. I think it is supposed to be able to do this, but I haven't managed to make it work yet. Thanks, NeilBrown pgpieNOVc2eSe.pgp Description: OpenPGP digital signature
Re: [GIT PULL 00/21] perf/core improvements and fixes
* Victor Kamensky wrote: > Hi Arnaldo, Ingo, > > What happened with this pull request? [...] This pull request was for v4.1, and I merged it in: commit 8a26ce4e544659256349551283414df504889a59 Merge: acba3c7e4652 726f3234dd12 Author: Ingo Molnar Date: Wed Feb 18 19:14:54 2015 +0100 Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo: User visible changes: > [...] I already see in v4.0-rc2 changes additions to one requested > by this pull request, but I don't see this series itself. > > For example e370a3d57664cd5e39c0b95d157ebc841b568409 > "perf symbols: Define EM_AARCH64 for older OSes" by David > is already in v4.0-rc2 and it is supposed to be addition to > "perf symbols: Ignore mapping symbols on aarch64" that is part > of this pull request but it did not make into v4.0-rcX yet. Looks > quite strange. If some commits of the v4.1 queue are needed in v4.0 as well then they should be cherry-picked back into the urgent queue. But maybe e370a3d57 was merged prematurely - in that case it appears to be harmless and v4.1 will sort it out. Arnaldo? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 12/15] twl4030_charger: add software controlled linear charging mode.
On Mon, 2 Mar 2015 22:09:26 +0100 Pavel Machek wrote: > On Tue 2015-02-24 15:33:52, NeilBrown wrote: > > Add a 'continuous' option for usb charging which enabled > > the "linear" charging mode of the twl4030. > > Documentation/ :-). ! > > > Linear charging does a good job with not so reliable power sources, since > > several voltage controlling is then often too intelligent. > > Parse error. Linear charging does a good job with not-so-reliable power sources. Auto mode does not work well as it switches off when voltage drops momentarily. Care must be taken not to over-charge. It was used with a bike hub dynamo since a year or so. In that case there are automatically charging stops when the cyclist needs a break. = > > > It was used with a bike hub dynamo since a year or so. In that case there > > are automatically charging stops when the cyclist needs a break. > > > > Orignal-by: Andreas Kemnade > > Signed-off-by: NeilBrown > > > > + ret = twl_i2c_write_u8(TWL_MODULE_MAIN_CHARGE, 0x33, > > + TWL4030_BCIWDKEY); > > + /* 0x24 + EKEY6: off mode */ > > " " -> " " > > > + ret = twl_i2c_write_u8(TWL_MODULE_MAIN_CHARGE, 0x2a, > > + TWL4030_BCIMDKEY); > > + /* EKEY2: Linear charge: usb path */ > > USB > > > + ret = twl_i2c_write_u8(TWL_MODULE_MAIN_CHARGE, 0x26, > > + TWL4030_BCIMDKEY); > > + /* WDKEY5: stop watchdog count */ > > + ret = twl_i2c_write_u8(TWL_MODULE_MAIN_CHARGE, 0xf3, > > + TWL4030_BCIWDKEY); > > + /* enable MFEN3 access */ > > + ret = twl_i2c_write_u8(TWL_MODULE_MAIN_CHARGE, 0x9c, > > + TWL4030_BCIMFKEY); > > +/* ICHGEOCEN - end-of-charge monitor (current < 80mA) > > + * (charging continues) > > + * ICHGLOWEN - current level monitor (charge continues) > > + * don't monitor over-current or heat save > > Heat save? Is ignoring over-current good idea? The data sheet refers to a flag "HSEN" which is "Heat Save function enable". your guess is as good as mine. We don't currently have any code for responding to warnings. Maybe we should. For now this feature is "use at your own risk" - and one person has found it very useful. > > > @@ -650,6 +684,8 @@ twl4030_bci_mode_store(struct device *dev, struct > > device_attribute *attr, > > mode = 0; > > else if (sysfs_streq(buf, modes[1])) > > mode = 1; > > + else if (sysfs_streq(buf, modes[2])) > > + mode = 2; > > Time for loop? When we get one more mode it will be :-) Thanks, NeilBrown pgpWxEIZfiIvS.pgp Description: OpenPGP digital signature
Re: [PATCH v3 8/8] x86: switch to using asm-generic for seccomp.h
* Kees Cook wrote: > Switch to using the newly created asm-generic/seccomp.h for the > seccomp strict mode syscall definitions. The obsolete sigreturn > syscall override is retained in 32-bit mode, and the ia32 syscall > overrides are used in the compat case. Remaining definitions were > identical. > > Signed-off-by: Kees Cook Acked-by: Ingo Molnar Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/15] twl4030_charger: allow max_current to be managed via sysfs.
On Mon, 2 Mar 2015 22:05:26 +0100 Pavel Machek wrote:
> On Tue 2015-02-24 15:33:52, NeilBrown wrote:
> > 'max_current' sysfs attributes are created which allow the
> > max to be set.
> > Whenever a current source changes, the default is restored.
> > This will be followed by a uevent, so user-space can decide to
> > update again.
>
> Does this need Documentation update?
Oh all right... I've created the relevant documentation in Documentation/ABI.
It seems persistence pays off :-)
>
> > Signed-off-by: NeilBrown
> > ---
> > drivers/power/twl4030_charger.c | 76
> > +++
> > 1 file changed, 76 insertions(+)
> >
> > diff --git a/drivers/power/twl4030_charger.c
> > b/drivers/power/twl4030_charger.c
> > index bfc9b808301e..b0242786d047 100644
> > --- a/drivers/power/twl4030_charger.c
> > +++ b/drivers/power/twl4030_charger.c
> > @@ -527,6 +529,67 @@ static irqreturn_t twl4030_bci_interrupt(int irq, void
> > *arg)
> > return IRQ_HANDLED;
> > }
> >
> > +/*
> > + * sysfs max_current store
> > + */
>
> That's not exactly useful comment.
Now:
* Provide "max_current" attribute in sysfs.
>
> > +static ssize_t
> > +twl4030_bci_max_current_store(struct device *dev, struct device_attribute
> > *attr,
> > + const char *buf, size_t n)
> > +{
> > + struct twl4030_bci *bci = dev_get_drvdata(dev->parent);
> > + int cur = 0;
> > + int status = 0;
> > + status = kstrtoint(buf, 10, );
> > + if (status)
> > + return status;
> > + if (cur < 0)
> > + return -EINVAL;
> > + if (dev == bci->ac.dev) {
> > + if (bci->ac_cur == cur)
> > + return n;
> > + bci->ac_cur = cur;
> > + } else {
> > + if (bci->usb_cur == cur)
> > + return n;
> > + bci->usb_cur = cur;
> > + }
> > + twl4030_charger_update_current(bci);
> > + return (status == 0) ? n : status;
> > +}
>
> Uff. but we know that status == 0 at this point, no?
Yes. Fixed.
> Also... is
> optimalization of not calling update_current() when nothing changed
> worth it?
Probably not... and code looks a lot nicer if I remove that.
So I have.
>
> > +/*
> > + * sysfs max_current show
> > + */
> > +static ssize_t twl4030_bci_max_current_show(struct device *dev,
> > + struct device_attribute *attr, char *buf)
> > +{
> > + int status = 0;
> > + int cur = -1;
> > + u8 bcictl1;
> > + struct twl4030_bci *bci = dev_get_drvdata(dev->parent);
> > +
> > + if (dev == bci->ac.dev) {
> > + if (!bci->ac_is_active)
> > + cur = bci->ac_cur;
> > + } else {
> > + if (bci->ac_is_active)
> > + cur = bci->usb_cur;
> > + }
> > + if (cur < 0) {
> > + cur = twl4030bci_read_adc_val(TWL4030_BCIIREF1);
> > + if (cur < 0)
> > + return cur;
> > + status = twl4030_bci_read(TWL4030_BCICTL1, );
> > + if (status < 0)
> > + return status;
> > + cur = regval2ua(cur, bcictl1 & TWL4030_CGAIN);
> > + }
> > + return scnprintf(buf, PAGE_SIZE, "%u\n", cur);
> > +}
>
> Is this in uA or mA? uA. Ok.
uA, now described in Documentation/ABI/testing/sysfs-class-power-twl4030
+What: /sys/class/power_supply/twl4030_ac/max_current
+ /sys/class/power_supply/twl4030_usb/max_current
+Description:
+ Read/Write limit on current which which may
+ be drawn from the ac (Accessory Charger) or
+ USB port.
+
+ Value is in micro-Amps.
+
+ Value is set automatically to an appropriate
+ value when a cable is plugged on unplugged.
+
+ Value can the set by writing to the attribute.
+ The change will only persist until the next
+ plug event. These event are reported via udev.
>
> Acked-by: Pavel Machek
> Pavel
>
Thanks,
NeilBrown
pgp2nlrebNej7.pgp
Description: OpenPGP digital signature
ERINNERUNG (Service-Upgrade)
Letzte Warnung Webmail Benutzer Dies ist eine Nachricht von Ihrem E-Mail-Service-IT-Team, um Ihr Konto zu aktualisieren Wir aktualisieren alle E-Mail-Konten, sind alle Benutzer keine Themen Überprüfung Ihre E-Mail-Konto für die Aktualisierung und Updates. Bitte überprüfen Sie und aktualisieren Sie Ihr Konto nicht zu verlieren Ihre eingehenden Nachrichten in Ihren Posteingang und andere Ordner oder auch gelöscht werden, wenn kein Upgrade / Innerhalb 24 Stunden aktualisiert. Klicken Sie hier:http://tinyurl.com/pqvqy72 Ihre E-Mail zu aktualisieren Webmail-Service IT-Service-Team. Kopieren Sie den Link in Ihren Browser einfügen-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] Support follow_link in RCU-walk.
On Thu, Mar 05, 2015 at 04:21:21PM +1100, NeilBrown wrote:
> Hi Al (and others),
>
> I wonder if you could look over this patchset.
> It allows RCU-walk to follow symlinks in many common cases,
> thus removing a surprising performance hit caused by using symlinks.
>
> The last could of patches make changes to XFS and NFS to support
> this but I haven't forwarded to the relevant lists yet.
> If/when the early code meets with approval I'll do that.
>
> The first patch almost certainly needs to be changed. I originally
> wrote this code when filesystems could see inside nameidata.
> It is now opaque so the simplest solution was to provide an
> accessor function.
> Maybe I should as a 'flags' arg to ->follow_link?? Or have
> ->follow_link and ->follow_link_rcu ??
> What do you suggest?
Umm... Some observations:
* now ->follow_link() can be called in RCU mode, which means
that it can race with fs shutdown; not a problem, except that now it
joins ->lookup() et.al. in "if some data structure is needed in RCU
case of that, make sure it's not destroyed without an RCU delay somewhere
between the entry into ->kill_sb() and destruction.
* highmem pages in symlinks: that BS shouldn't be allowed at
all. Just make sure that at least for those filesystems symlink inodes
get mapping_set_gfp_mask(>i_data, GFP_KERNEL) and be done with that.
* are you sure that security_inode_follow_link() is OK to call in
RCU mode?
* what warranties are you giving for the lifetime of strings
passed to nd_set_link()? Right now it's "should not be freed until the
matching ->put_link()"; what happens for RCU mode?
* really nasty one: creat(2) on a dangling symlink. What's to
preserve the last component if you get into that symlink in RCU mode?
TBH, I'm less than fond of passing nameidata to ->follow_link() at all,
flags or no flags. We could kill current->link_count and
current->total_link_count, replacing them with one void * current->nameidata
and taking counters into struct nameidata itself. Have places like e.g.
kern_path_locked() do
struct nameidata nd, *saved = set_nameidata();
...
set_nameidata(saved);
with set_nameidata(p) doing this:
old = current->nameidata;
current->nameidata = p;
if (p) {
if (!old) {
p->link_count = 0;
p->total_link_count = 0;
} else {
p->link_count = old->link_count;
p->total_link_count = old->total_link_count;
}
}
return old;
Then nd_set_link() et.al. would use current->nameidata instead of an
explicitly passed pointer and ->follow_link() instances wouldn't need
that opaque pointer passed to them at all.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] MAINTAINERS: Add Mediatek SoC mailing list
Add the new list that Mediatek specific patches should also be directed to. Signed-off-by: Matthias Brugger --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index ddc5a8c..3e30c83 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1205,6 +1205,7 @@ F:arch/arm/mach-orion5x/ts78xx-* ARM/Mediatek SoC support M: Matthias Brugger L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) +L: linux-media...@lists.infradead.org (moderated for non-subscribers) S: Maintained F: arch/arm/boot/dts/mt6* F: arch/arm/boot/dts/mt8* -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V8 00/10] USB: f81232: V8 patches
Hello, Peter Hung 於 2015/2/26 下午 06:02 寫道: This series patch V8 is changed from V7 as following: 1. The V7 MSR strange delta value is checked with locking problem. We changed f81232_set_mctrl() & f81232_read_msr() lock mechanism, the old version is only locked with variable protection, new version will lock from start to end with these 2 function. 2. f81232_set_baudrate() add error handling and no longer handle with baudrate B0, change to handle with f81232_set_termios() 3. When user set baudrate larger then 115200, we will change it with 115200 and tty_encode_baud_rate() in f81232_set_termios(). 4. V7 f81232_set_baudrate() divisor declared with type u8, it will make baudrate set failed with smaller then B600 (115200/300=384 overflow :Q). We changed it with integer type for divisor larger then 256. Did you received the series of F81232 V8 patches ? Please tell me if not received. Thanks for your review. -- With Best Regards, Peter Hung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 02/14] ethernet: Use eth__addr instead of memset
On Mon, 2015-03-02 at 19:54 -0800, Joe Perches wrote:
> Use the built-in function instead of memset.
>
> Signed-off-by: Joe Perches
Acked-by: Don Fry
for pcnet32.c
> ---
> drivers/net/ethernet/amd/pcnet32.c | 2 +-
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c | 2 +-
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c| 6 +++---
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c | 2 +-
> drivers/net/ethernet/cisco/enic/enic_main.c | 8
> drivers/net/ethernet/emulex/benet/be_cmds.c | 2 +-
> drivers/net/ethernet/emulex/benet/be_main.c | 2 +-
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 ++--
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 4 ++--
> drivers/net/ethernet/mellanox/mlx4/en_selftest.c| 2 +-
> drivers/net/ethernet/micrel/ksz884x.c | 2 +-
> drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c | 2 +-
> drivers/net/ethernet/qlogic/qlge/qlge_main.c| 2 +-
> drivers/net/ethernet/smsc/smsc911x.c| 2 +-
> drivers/net/ethernet/ti/netcp_core.c| 2 +-
> drivers/net/ethernet/toshiba/ps3_gelic_wireless.c | 4 ++--
> drivers/net/ethernet/xscale/ixp4xx_eth.c| 2 +-
> 17 files changed, 25 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/net/ethernet/amd/pcnet32.c
> b/drivers/net/ethernet/amd/pcnet32.c
> index 11d6e65..8eb37e0 100644
> --- a/drivers/net/ethernet/amd/pcnet32.c
> +++ b/drivers/net/ethernet/amd/pcnet32.c
> @@ -1708,7 +1708,7 @@ pcnet32_probe1(unsigned long ioaddr, int shared, struct
> pci_dev *pdev)
>
> /* if the ethernet address is not valid, force to 00:00:00:00:00:00 */
> if (!is_valid_ether_addr(dev->dev_addr))
> - memset(dev->dev_addr, 0, ETH_ALEN);
> + eth_zero_addr(dev->dev_addr);
>
> if (pcnet32_debug & NETIF_MSG_PROBE) {
> pr_cont(" %pM", dev->dev_addr);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/15] twl4030_charger: use runtime_pm to keep usb phy active while charging.
On Wed, 25 Feb 2015 07:24:43 + Lee Jones wrote: > On Tue, 24 Feb 2015, NeilBrown wrote: > > > The twl4030 usb phy needs to be active while we are using > > the USB VBUS as a current source for charging. > > In particular, the usb3v1 regulator must be enabled and the > > PHY_PWR_PHYPWD bit must be set to keep the phy powered. > > > > commit ab37813f4093a5f59cb8e083cde277289dc72ed3 > > twl4030_charger: Allow charger to control the regulator that feeds it > > > > Gave the charger control over the regulator, but didn't resolve > > the PHY_PWR_PHYPWD issue. > > > > Now that both of these are controlled by runtime_pm in > > phy-twl4030-usb, we can simply take a runtime_pm reference to the USB > > phy whenever the charger wants to use it as a current source. > > > > So this patch reverts the above commit, and adds the necessary > > runtime_pm calls. > > > > Signed-off-by: NeilBrown > > --- > > drivers/mfd/twl-core.c |9 - > > Acked-by: Lee Jones Thanks. I guess that clear it to go in though the 'power supply' tree. NeilBrown pgpRvdk63TBn1.pgp Description: OpenPGP digital signature
[PATCH] netlink: drop (int) cast on length arg in NLMSG_OK
The NLMSG_OK macro compares three things:
- the len arg from the user
- a size_t: sizeof(struct nlmsghdr)
- an int: sizeof(struct nlmsghdr) casted
- an u32: the nlmsghdr->nlmsg_len member
When building with -Wsign-compare, this macro triggers a signed compare
warning. This is because it compares len to an int, and then compares
it to a u32. If len is signed, we get a warning due to the last test.
If len is unsigned, we get a warning due to the first test. Like in
strace:
socketutils.c:145:8: warning: comparison between signed and unsigned
integer expressions [-Wsign-compare]
Lets drop the int cast on the first sizeof. This way, once the user
casts len to an unsigned value, everything shakes out correctly.
Signed-off-by: Mike Frysinger
---
include/uapi/linux/netlink.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/linux/netlink.h b/include/uapi/linux/netlink.h
index 1a85940..3eb4e24 100644
--- a/include/uapi/linux/netlink.h
+++ b/include/uapi/linux/netlink.h
@@ -84,7 +84,7 @@ struct nlmsghdr {
#define NLMSG_DATA(nlh) ((void*)(((char*)nlh) + NLMSG_LENGTH(0)))
#define NLMSG_NEXT(nlh,len) ((len) -= NLMSG_ALIGN((nlh)->nlmsg_len), \
(struct nlmsghdr*)(((char*)(nlh)) +
NLMSG_ALIGN((nlh)->nlmsg_len)))
-#define NLMSG_OK(nlh,len) ((len) >= (int)sizeof(struct nlmsghdr) && \
+#define NLMSG_OK(nlh,len) ((len) >= sizeof(struct nlmsghdr) && \
(nlh)->nlmsg_len >= sizeof(struct nlmsghdr) && \
(nlh)->nlmsg_len <= (len))
#define NLMSG_PAYLOAD(nlh,len) ((nlh)->nlmsg_len - NLMSG_SPACE((len)))
--
2.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/7] Freescale DPAA FMan FLIB(s)
From: Igal Liberman The Freescale Data Path Acceleration Architecture (DPAA) is a set of hardware components on specific QorIQ P and T series multicore processors. This architecture provides the infrastructure to support simplified sharing of networking interfaces and accelerators by multiple CPU cores, and the accelerators themselves. One of the DPAA accelerators is the Frame Manager (FMan), which combines the Ethernet network interfaces with packet distribution logic to provide intelligent distribution and queuing decisions for incoming traffic at line rate. This patch presents the FMan Foundation Libraries (FLIB) headers. The FMan FLIB suite adds basic support for the DPAA FMan hardware register access. The FMan FLIB suite is used in Freescale's SDK Releases. Igal Liberman (7): soc/fman: Add the FMan FLIB headers soc/fman: Add the FMan FLIB soc/fman: Add the FMan port FLIB soc/fman: Add the FMan MAC FLIB soc/fman: Add the FMan parser and KeyGen FLIB(s) soc/fman: Add the FMan RTC FLIB soc/fman: Add the FMan SP FLIB drivers/soc/Kconfig|1 + drivers/soc/Makefile |1 + drivers/soc/fsl/Kconfig|1 + drivers/soc/fsl/Makefile |1 + drivers/soc/fsl/fman/Kconfig | 35 + drivers/soc/fsl/fman/Makefile | 19 + drivers/soc/fsl/fman/flib/common/general.h | 45 + drivers/soc/fsl/fman/flib/fman_common.h| 74 + drivers/soc/fsl/fman/flib/fsl_enet.h | 276 drivers/soc/fsl/fman/flib/fsl_fman.h | 801 ++ drivers/soc/fsl/fman/flib/fsl_fman_dtsec.h | 1017 + drivers/soc/fsl/fman/flib/fsl_fman_dtsec_mii_acc.h | 104 ++ drivers/soc/fsl/fman/flib/fsl_fman_kg.h| 506 +++ drivers/soc/fsl/fman/flib/fsl_fman_memac.h | 492 +++ drivers/soc/fsl/fman/flib/fsl_fman_memac_mii_acc.h | 77 + drivers/soc/fsl/fman/flib/fsl_fman_port.h | 602 drivers/soc/fsl/fman/flib/fsl_fman_prs.h | 106 ++ drivers/soc/fsl/fman/flib/fsl_fman_rtc.h | 415 ++ drivers/soc/fsl/fman/flib/fsl_fman_sp.h| 133 ++ drivers/soc/fsl/fman/flib/fsl_fman_tgec.h | 484 ++ drivers/soc/fsl/fman/fman.c| 1396 ++ drivers/soc/fsl/fman/mac/Makefile | 15 + drivers/soc/fsl/fman/mac/fman_crc32.c | 117 ++ drivers/soc/fsl/fman/mac/fman_crc32.h | 40 + drivers/soc/fsl/fman/mac/fman_dtsec.c | 844 +++ drivers/soc/fsl/fman/mac/fman_dtsec_mii_acc.c | 169 +++ drivers/soc/fsl/fman/mac/fman_memac.c | 504 +++ drivers/soc/fsl/fman/mac/fman_memac_mii_acc.c | 218 +++ drivers/soc/fsl/fman/mac/fman_tgec.c | 372 + drivers/soc/fsl/fman/pcd/Makefile | 13 + drivers/soc/fsl/fman/pcd/fman_kg.c | 850 +++ drivers/soc/fsl/fman/pcd/fman_prs.c| 127 ++ drivers/soc/fsl/fman/port/Makefile | 13 + drivers/soc/fsl/fman/port/fman_port.c | 1536 drivers/soc/fsl/fman/rtc/Makefile | 13 + drivers/soc/fsl/fman/rtc/fman_rtc.c| 354 + drivers/soc/fsl/fman/sp/Makefile | 13 + drivers/soc/fsl/fman/sp/fman_sp.c | 204 +++ 38 files changed, 11988 insertions(+) create mode 100644 drivers/soc/fsl/Kconfig create mode 100644 drivers/soc/fsl/Makefile create mode 100644 drivers/soc/fsl/fman/Kconfig create mode 100644 drivers/soc/fsl/fman/Makefile create mode 100644 drivers/soc/fsl/fman/flib/common/general.h create mode 100644 drivers/soc/fsl/fman/flib/fman_common.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_enet.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_dtsec.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_dtsec_mii_acc.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_kg.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_memac.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_memac_mii_acc.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_port.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_prs.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_rtc.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_sp.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_tgec.h create mode 100644 drivers/soc/fsl/fman/fman.c create mode 100644 drivers/soc/fsl/fman/mac/Makefile create mode 100644 drivers/soc/fsl/fman/mac/fman_crc32.c create mode 100644 drivers/soc/fsl/fman/mac/fman_crc32.h create mode 100644 drivers/soc/fsl/fman/mac/fman_dtsec.c create mode 100644 drivers/soc/fsl/fman/mac/fman_dtsec_mii_acc.c create mode 100644
Re: [PATCH 1/1 linux-next] ceph: remove redundant declaration
On Wed, Mar 4, 2015 at 1:57 AM, Fabian Frederick wrote: > ceph_aops was already defined extern in addr.c section > > Signed-off-by: Fabian Frederick > --- > fs/ceph/super.h |1 - > 1 file changed, 1 deletion(-) > > diff --git a/fs/ceph/super.h b/fs/ceph/super.h > index 04c8124..02ca99c 100644 > --- a/fs/ceph/super.h > +++ b/fs/ceph/super.h > @@ -881,7 +881,6 @@ extern int ceph_mmap(struct file *file, struct > vm_area_struct *vma); > > /* file.c */ > extern const struct file_operations ceph_file_fops; > -extern const struct address_space_operations ceph_aops; > > extern int ceph_open(struct inode *inode, struct file *file); > extern int ceph_atomic_open(struct inode *dir, struct dentry *dentry, > -- > 1.7.9.5 > Added to our testing branch Thanks Yan, Zheng > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] thermal: exynos: Add the support for Exynos5433 TMU
Hi Lukasz,
On 03/04/2015 07:38 PM, Lukasz Majewski wrote:
> Hi Chanwoo,
>
>> This patch adds the support for Exynos5433's TMU (Thermal Management
>> Unit). Exynos5433 has a little different register bit fields as
>> following description:
>> - Support the eight trip points for rising/falling interrupt by using
>> two registers
>> - Read the calibration type (1-point or 2-point) and sensor id from
>> TRIMINFO register
>> - Use a little different register address
>>
>> Cc: Zhang Rui
>> Cc: Eduardo Valentin
>> Signed-off-by: Chanwoo Choi
>> ---
>> drivers/thermal/samsung/exynos_tmu.c | 161
>> +--
>> drivers/thermal/samsung/exynos_tmu.h | 1 + 2 files changed, 157
>> insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/thermal/samsung/exynos_tmu.c
>> b/drivers/thermal/samsung/exynos_tmu.c index 1d30b09..1bb2fb7 100644
>> --- a/drivers/thermal/samsung/exynos_tmu.c
>> +++ b/drivers/thermal/samsung/exynos_tmu.c
>> @@ -97,6 +97,32 @@
>> #define EXYNOS4412_MUX_ADDR_VALUE 6
>> #define EXYNOS4412_MUX_ADDR_SHIFT 20
>>
>> +/* Exynos5433 specific registers */
>> +#define EXYNOS5433_TMU_REG_CONTROL1 0x024
>> +#define EXYNOS5433_TMU_SAMPLING_INTERVAL0x02c
>> +#define EXYNOS5433_TMU_COUNTER_VALUE0 0x030
>> +#define EXYNOS5433_TMU_COUNTER_VALUE1 0x034
>> +#define EXYNOS5433_TMU_REG_CURRENT_TEMP10x044
>> +#define EXYNOS5433_THD_TEMP_RISE3_0 0x050
>> +#define EXYNOS5433_THD_TEMP_RISE7_4 0x054
>> +#define EXYNOS5433_THD_TEMP_FALL3_0 0x060
>> +#define EXYNOS5433_THD_TEMP_FALL7_4 0x064
>> +#define EXYNOS5433_TMU_REG_INTEN0x0c0
>> +#define EXYNOS5433_TMU_REG_INTPEND 0x0c8
>> +#define EXYNOS5433_TMU_EMUL_CON 0x110
>> +#define EXYNOS5433_TMU_PD_DET_EN0x130
>> +
>> +#define EXYNOS5433_TRIMINFO_SENSOR_ID_SHIFT 16
>> +#define EXYNOS5433_TRIMINFO_CALIB_SEL_SHIFT 23
>> +#define EXYNOS5433_TRIMINFO_SENSOR_ID_MASK \
>> +(0xf << EXYNOS5433_TRIMINFO_SENSOR_ID_SHIFT)
>> +#define EXYNOS5433_TRIMINFO_CALIB_SEL_MASK BIT(23)
>> +
>> +#define EXYNOS5433_TRIMINFO_ONE_POINT_TRIMMING 0
>> +#define EXYNOS5433_TRIMINFO_TWO_POINT_TRIMMING 1
>> +
>> +#define EXYNOS5433_PD_DET_EN1
>> +
>> /*exynos5440 specific registers*/
>> #define EXYNOS5440_TMU_S0_7_TRIM0x000
>> #define EXYNOS5440_TMU_S0_7_CTRL0x020
>> @@ -484,6 +510,101 @@ out:
>> return ret;
>> }
>>
>> +static int exynos5433_tmu_initialize(struct platform_device *pdev)
>> +{
>> +struct exynos_tmu_data *data = platform_get_drvdata(pdev);
>> +struct exynos_tmu_platform_data *pdata = data->pdata;
>> +struct thermal_zone_device *tz = data->tzd;
>> +unsigned int status, trim_info;
>> +unsigned int rising_threshold = 0, falling_threshold = 0;
>> +unsigned long temp, temp_hist;
>> +int ret = 0, threshold_code, i, sensor_id, cal_type;
>> +
>> +status = readb(data->base + EXYNOS_TMU_REG_STATUS);
>> +if (!status) {
>> +ret = -EBUSY;
>> +goto out;
>> +}
>> +
>> +trim_info = readl(data->base + EXYNOS_TMU_REG_TRIMINFO);
>> +sanitize_temp_error(data, trim_info);
>> +
>> +/* Read the temperature sensor id */
>> +sensor_id = (trim_info & EXYNOS5433_TRIMINFO_SENSOR_ID_MASK)
>> +>>
>> EXYNOS5433_TRIMINFO_SENSOR_ID_SHIFT;
>> +dev_info(>dev, "Temperature sensor ID: 0x%x\n",
>> sensor_id); +
>
> Isn't dev_info a bit too noisy? IMHO, dev_dbg would be enough
> here.
>
> Please consider this globally.
OK, I'll use dev_dbg.
>
>> +/* Read the calibration mode */
>> +writel(trim_info, data->base + EXYNOS_TMU_REG_TRIMINFO);
>> +cal_type = (trim_info & EXYNOS5433_TRIMINFO_CALIB_SEL_MASK)
>> +>>
>> EXYNOS5433_TRIMINFO_CALIB_SEL_SHIFT; +
>> +switch (cal_type) {
>> +case EXYNOS5433_TRIMINFO_ONE_POINT_TRIMMING:
>> +pdata->cal_type = TYPE_ONE_POINT_TRIMMING;
>> +break;
>> +case EXYNOS5433_TRIMINFO_TWO_POINT_TRIMMING:
>> +pdata->cal_type = TYPE_TWO_POINT_TRIMMING;
>> +break;
>> +default:
>> +pdata->cal_type = TYPE_ONE_POINT_TRIMMING;
>> +break;
>> +};
>> +
>> +dev_info(>dev, "Calibration type is %d-point
>> calibration\n",
>> +cal_type ? 2 : 1);
>> +
>> +/* Write temperature code for rising and falling threshold */
>> +for (i = 0; i < of_thermal_get_ntrips(tz); i++) {
>> +int rising_reg_offset, falling_reg_offset;
>> +int j = 0;
>> +
>> +switch (i) {
>> +case 0:
>> +case 1:
>> +case 2:
>> +case 3:
>> +rising_reg_offset =
>> EXYNOS5433_THD_TEMP_RISE3_0;
>> +falling_reg_offset =
>> EXYNOS5433_THD_TEMP_FALL3_0;
>> +j =
[PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
This patch adds new Exynos5433 dtsi to support 64-bit Exynos5433 SoC based on
Octal core CPUs (quad Cortex-A57 and quad Cortex-A53). And Exynos5433 supports
PSCI (Power State Coordination Interface) v0.1.
This patch includes following dt node to support Exynos5433 SoC:
1. Octa core for big.LITTLE architecture
- Cortex-A53 LITTLE Quad-core
- Cortex-A57 big Quad-core
- Support PSCI v0.1
2. clock controller node:
- CMU_TOP : clocks for IMEM/FSYS/G3D/GSCL/HEVC/MSCL/G2D/MFC/PERIC/PERIS
- CMU_CPIF : clocks for LLI (Low Latency Interface)
- CMU_MIF : clocks for DRAM Memory Controller
- CMU_PERIC : clocks for UART/I2C/SPI/I2S/PCM/SPDIF/PWM/SLIMBUS
- CMU_PERIS : clocks for PMU/TMU/MCT/WDT/RTC/SECKEY/TZPC
- CMU_FSYS : clocks for USB/UFS/SDMMC/TSI/PDMA
- CMU_G2D : clocks for G2D/MDMA
- CMU_DISP : clocks for DECON/HDMI/DSIM/MIXER
- CMU_AUD : clocks for Cortex-A5/BUS/AUDIO
- CMU_BUS{0|1|2} : clocks for global data buses and global peripheral buses
- CMU_G3D : clocks for 3D Graphics Engine
- CMU_GSCL : clocks for GSCALER
- CMU_APOLLO: clocks for Cortex-A53 Quad-core processor.
- CMU_ATLAS : clocks for Cortex-A57 Quad-core processor,
CoreSight and L2 cache controller.
- CMU_MSCL : clocks for M2M (Memory to Memory) scaler and JPEG IPs.
- CMU_MFC : clocks for MFC (Multi-Format Codec) IP.
- CMU_HEVC : clocks for HEVC(High Efficiency Video Codec) decoder IP.
- CMU_ISP : clocks for FIMC-ISP/DRC/SCLC/DIS/3DNR IPs.
- CMU_CAM0 : clocks for MIPI_CSIS{0|1}/FIMC_LITE_{A|B|D}/FIMC_3AA{0|1} IPs.
- CMU_CAM1 : clocks for COrtex-A5/MIPI_CSIS2/FIMC_LITE_C/FIMC-FD IPs.
3. pinctrl node for GPIO:
- alive/aud/cpif/ese/finger/fsys/imem/nfc/peric/touch pad
4. HS (High-Speed) I2C device
5. Serial device
6. ARCH timer (arm,armv8-timer)
7. Interrupt controller (arm,gic-400)
Cc: Kukjin Kim
Cc: Mark Rutland
Cc: Marc Zyngier
Cc: Arnd Bergmann
Cc: Olof Johansson
Cc: Catalin Marinas
Cc: Will Deacon
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
---
arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 698 +
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 668
2 files changed, 1366 insertions(+)
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433.dtsi
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
new file mode 100644
index 000..c56bbf8
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
@@ -0,0 +1,698 @@
+/*
+ * Samsung's Exynos5433 SoC pin-mux and pin-config device tree source
+ *
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung's Exynos5433 SoC pin-mux and pin-config options are listed as device
+ * tree nodes are listed in this file.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+_alive {
+ gpa0: gpa0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ interrupt-parent = <>;
+ interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
+<0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>;
+ #interrupt-cells = <2>;
+ };
+
+ gpa1: gpa1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ interrupt-parent = <>;
+ interrupts = <0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
+<0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>;
+ #interrupt-cells = <2>;
+ };
+
+ gpa2: gpa2 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpa3: gpa3 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+};
+
+_aud {
+ gpz0: gpz0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpz1: gpz1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ i2s0_bus: i2s0-bus {
+ samsung,pins = "gpz0-0", "gpz0-1", "gpz0-2", "gpz0-3",
+ "gpz0-4", "gpz0-5", "gpz0-6";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <1>;
+ samsung,pin-drv = <0>;
+ };
+
+ pcm0_bus: pcm0-bus {
+ samsung,pins = "gpz1-0", "gpz1-1", "gpz1-2", "gpz1-3";
+ samsung,pin-function = <3>;
+ samsung,pin-pud =
[PATCH v5 3/9] arm64: dts: exynos: Add SPI/PDMA dt node for Exynos5433
This patch adds SPI (Serial Peripheral Interface) dt node for Exynos5433 SoC.
SPI transfers serial data by using various peripherals. SPI includes
8-bit/16-bit/32-bit shift registers to transmit and receive data. PDMA is used
for SPI communication.
Cc: Kukjin Kim
Cc: Mark Rutland
Cc: Marc Zyngier
Cc: Arnd Bergmann
Cc: Olof Johansson
Cc: Catalin Marinas
Cc: Will Deacon
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 114 +
1 file changed, 114 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 9b96bdf..710566a 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -399,6 +399,35 @@
interrupts = <1 9 0xf04>;
};
+ amba {
+ compatible = "arm,amba-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ pdma0: pdma@1561 {
+ compatible = "arm,pl330", "arm,primecell";
+ reg = <0x1561 0x1000>;
+ interrupts = <0 228 0>;
+ clocks = <_fsys CLK_PDMA0>;
+ clock-names = "apb_pclk";
+ #dma-cells = <1>;
+ #dma-channels = <8>;
+ #dma-requests = <32>;
+ };
+
+ pdma1: pdma@1560 {
+ compatible = "arm,pl330", "arm,primecell";
+ reg = <0x1560 0x1000>;
+ interrupts = <0 246 0>;
+ clocks = <_fsys CLK_PDMA1>;
+ clock-names = "apb_pclk";
+ #dma-cells = <1>;
+ #dma-channels = <8>;
+ #dma-requests = <32>;
+ };
+ };
+
serial_0: serial@14c1 {
compatible = "samsung,exynos5433-uart";
reg = <0x14c1 0x100>;
@@ -499,6 +528,91 @@
interrupts = <0 442 0>;
};
+ spi_0: spi@14d2 {
+ compatible = "samsung,exynos7-spi";
+ reg = <0x14d2 0x100>;
+ interrupts = <0 432 0>;
+ dmas = < 9>, < 8>;
+ dma-names = "tx", "rx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <_peric CLK_PCLK_SPI0>,
+<_top CLK_SCLK_SPI0_PERIC>;
+ clock-names = "spi", "spi_busclk0";
+ samsung,spi-src-clk = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_bus>;
+ status = "disabled";
+ };
+
+ spi_1: spi@14d3 {
+ compatible = "samsung,exynos7-spi";
+ reg = <0x14d3 0x100>;
+ interrupts = <0 433 0>;
+ dmas = < 11>, < 10>;
+ dma-names = "tx", "rx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <_peric CLK_PCLK_SPI1>,
+<_top CLK_SCLK_SPI1_PERIC>;
+ clock-names = "spi", "spi_busclk0";
+ samsung,spi-src-clk = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_bus>;
+ status = "disabled";
+ };
+
+ spi_2: spi@14d4 {
+ compatible = "samsung,exynos7-spi";
+ reg = <0x14d4 0x100>;
+ interrupts = <0 434 0>;
+ dmas = < 13>, < 12>;
+ dma-names = "tx", "rx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <_peric CLK_PCLK_SPI2>,
+<_top CLK_SCLK_SPI2_PERIC>;
+ clock-names = "spi", "spi_busclk0";
+ samsung,spi-src-clk = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_bus>;
+ status = "disabled";
+ };
+
+ spi_3: spi@14d5 {
+ compatible = "samsung,exynos7-spi";
+ reg = <0x14d5 0x100>;
+ interrupts = <0 447 0>;
+ dmas = < 23>, < 22>;
+ dma-names =
[PATCH v5 5/9] arm64: dts: exynos: Add RTC and ADC dt node for Exynos5433 SoC
This patch adds RTC (Real Time Clock) dt node for Exynos5433 SoC and adds
ADC dt node for Exynos5433 SoC. The c1b501564c98a94b4(iio: adc: exynos_adc:
Add support for exynos7) commit supports the ADC for Exynos7. Exynos5433's ADC
IP is the same with Exynos7's ADC IP. Exynos5433 has a little different from
ADCv2 on ADC_CON2 register. Exynos5433 don't contain OSEL/ESEL /HIGHF of
ADC_CON2.
Cc: Kukjin Kim
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 0cf8a02..760ad81 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -816,6 +816,24 @@
clocks = <>;
};
+ rtc: rtc@1059 {
+ compatible = "samsung,exynos3250-rtc";
+ reg = <0x1059 0x100>;
+ interrupts = <0 385 0>, <0 386 0>;
+ status = "disabled";
+ };
+
+ adc: adc@14d1 {
+ compatible = "samsung,exynos7-adc";
+ reg = <0x14d1 0x100>;
+ interrupts = <0 438 0>;
+ clock-names = "adc";
+ clocks = <_peric CLK_PCLK_ADCIF>;
+ #io-channel-cells = <1>;
+ io-channel-ranges;
+ status = "disabled";
+ };
+
timer {
compatible = "arm,armv8-timer";
interrupts = <1 13 0xff04>,
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 4/9] arm64: dts: exynos: Add PMU dt node for Exynos5433
This patch adds PMU (Power Management Unit) dt node for Exynos5433 SoC and
set the source clock for CLKOUT register as xxti .
Cc: Kukjin Kim
Signed-off-by: Chanwoo Choi
[ideal.song: Add the setting of CLKOUT register]
Signed-off-by: Inha Song
Acked-by: Inki Dae
---
Documentation/devicetree/bindings/arm/samsung/pmu.txt | 1 +
arch/arm64/boot/dts/exynos/exynos5433.dtsi| 8
2 files changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
index 67b2113..a87fc43 100644
--- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
@@ -10,6 +10,7 @@ Properties:
- "samsung,exynos5260-pmu" - for Exynos5260 SoC.
- "samsung,exynos5410-pmu" - for Exynos5410 SoC,
- "samsung,exynos5420-pmu" - for Exynos5420 SoC.
+ - "samsung,exynos5433-pmu" - for Exynos5433 SoC.
- "samsung,exynos7-pmu" - for Exynos7 SoC.
second value must be always "syscon".
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 710566a..0cf8a02 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -808,6 +808,14 @@
status = "disabled";
};
+ pmu_system_controller: system-controller@105c {
+ compatible = "samsung,exynos5433-pmu", "syscon";
+ reg = <0x105c 0x5008>;
+ #clock-cells = <1>;
+ clock-names = "clkout16";
+ clocks = <>;
+ };
+
timer {
compatible = "arm,armv8-timer";
interrupts = <1 13 0xff04>,
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 8/9] arm64: dts: exynos: Add TMU sensor dt node for Exynos5433 SoC
This patch adds the TMU (Thermal Management Unit) sensor devicetree node for
Exynos5433. The Exynos5433 includes the five temperature sensors as following:
- two temperature sensor for Cortex-A57 (ATLAS)
- one temperature sensor for Cortex-A53 (APOLLO)
- one temperature sensor for G3D IP
- one temperature sensor for ISP IP
Cc: Kukjin Kim
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
Reviewed-by: Lukasz Majewski
---
.../dts/exynos/exynos5433-tmu-sensor-conf.dtsi | 22 +
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 55 ++
2 files changed, 77 insertions(+)
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tmu-sensor-conf.dtsi
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tmu-sensor-conf.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433-tmu-sensor-conf.dtsi
new file mode 100644
index 000..396e60f
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tmu-sensor-conf.dtsi
@@ -0,0 +1,22 @@
+/*
+ * Device tree sources for Exynos5433 TMU sensor configuration
+ *
+ * Copyright (c) 2015 Chanwoo Choi
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+
+#thermal-sensor-cells = <0>;
+samsung,tmu_gain = <8>;
+samsung,tmu_reference_voltage = <16>;
+samsung,tmu_noise_cancel_mode = <4>;
+samsung,tmu_efuse_value = <75>;
+samsung,tmu_min_efuse_value = <40>;
+samsung,tmu_max_efuse_value = <150>;
+samsung,tmu_first_point_trim = <25>;
+samsung,tmu_second_point_trim = <85>;
+samsung,tmu_default_temp_offset = <50>;
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 5b80eb8..bde9cba 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -836,6 +836,61 @@
status = "disabled";
};
+ tmu_atlas0: tmu@1006 {
+ compatible = "samsung,exynos5433-tmu";
+ reg = <0x1006 0x200>;
+ interrupts = <0 95 0>;
+ clocks = <_peris CLK_PCLK_TMU0_APBIF>,
+<_peris CLK_SCLK_TMU0>;
+ clock-names = "tmu_apbif", "tmu_sclk";
+ #include "exynos5433-tmu-sensor-conf.dtsi"
+ status = "disabled";
+ };
+
+ tmu_atlas1: tmu@10068000 {
+ compatible = "samsung,exynos5433-tmu";
+ reg = <0x10068000 0x200>;
+ interrupts = <0 96 0>;
+ clocks = <_peris CLK_PCLK_TMU0_APBIF>,
+<_peris CLK_SCLK_TMU0>;
+ clock-names = "tmu_apbif", "tmu_sclk";
+ #include "exynos5433-tmu-sensor-conf.dtsi"
+ status = "disabled";
+ };
+
+ tmu_g3d: tmu@1007 {
+ compatible = "samsung,exynos5433-tmu";
+ reg = <0x1007 0x200>;
+ interrupts = <0 99 0>;
+ clocks = <_peris CLK_PCLK_TMU1_APBIF>,
+<_peris CLK_SCLK_TMU1>;
+ clock-names = "tmu_apbif", "tmu_sclk";
+ #include "exynos5433-tmu-sensor-conf.dtsi"
+ status = "disabled";
+ };
+
+ tmu_apollo: tmu@10078000 {
+ compatible = "samsung,exynos5433-tmu";
+ reg = <0x10078000 0x200>;
+ interrupts = <0 115 0>;
+ clocks = <_peris CLK_PCLK_TMU1_APBIF>,
+<_peris CLK_SCLK_TMU1>;
+ clock-names = "tmu_apbif", "tmu_sclk";
+ #include "exynos5433-tmu-sensor-conf.dtsi"
+ status = "disabled";
+ };
+
+ tmu_isp: tmu@1007c000 {
+ compatible = "samsung,exynos5433-tmu";
+ reg = <0x1007c000 0x200>;
+ interrupts = <0 94 0>;
+ clocks = <_peris CLK_PCLK_TMU1_APBIF>,
+<_peris CLK_SCLK_TMU1>;
+ clock-names = "tmu_apbif", "tmu_sclk";
+ #include "exynos5433-tmu-sensor-conf.dtsi"
+ status = "disabled";
+ };
+
pmu_system_controller: system-controller@105c {
compatible = "samsung,exynos5433-pmu", "syscon";
reg = <0x105c 0x5008>;
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 7/9] arm64: dts: exynos: Add I2S dt node for Exynos5433 SoC
From: Inha Song
This patch adds I2S device tree node for Exynos5433 SoC.
In Exynos5433 SoC, I2S0 is used for audio interface.
Signed-off-by: Inha Song
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index abe8ea2..5b80eb8 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -475,6 +475,23 @@
status = "disabled";
};
+ i2s0: i2s0@1144 {
+ compatible = "samsung,exynos7-i2s";
+ reg = <0x1144 0x100>;
+ dmas = < 0 2>;
+ dma-names = "tx", "rx";
+ interrupts = <0 70 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <_aud CLK_PCLK_AUD_I2S>,
+<_aud CLK_SCLK_AUD_I2S>,
+<_aud CLK_SCLK_I2S_BCLK>;
+ clock-names = "iis", "i2s_opclk0", "i2s_opclk1";
+ pinctrl-names = "default";
+ pinctrl-0 = <_bus>;
+ status = "disabled";
+ };
+
pinctrl_alive: pinctrl@1058 {
compatible = "samsung,exynos5433-pinctrl";
reg = <0x1058 0x1000>;
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 0/9] arm64: Add the support for new Exynos5433 SoC
This patchset adds new 64-bit Exynos5433 Samsung SoC which contains quad
Cortex-A57 and quad Cortex-A53. It is desigend with the 20nm low power process.
Depends on:
- This patch-set has the dependency on Exynos5433 clock driver[1][2] and
pinctrl driver[3].
The Exynos5433 clock controller patch-set[1][2] was merged by Sylwester Nawrocki
and Exynos5433's pinctrl patch[3] receviced the acked message by Tomasz Figa.
(http://git.linuxtv.org/cgit.cgi/snawrocki/samsung.git/,
branch:for-v3.20/clk/next)
[1] [PATCH v5 00/13] clk: samsung: Add the support for exynos5433 clocks
- https://lkml.org/lkml/2015/2/2/368
[2] [PATCH v3 0/9] clk: samsung: Add clocks for remaining domains of Exynos5433
- https://lkml.org/lkml/2015/2/2/784
[3] [PATCH v4] pinctrl: exynos: Add support for Exynos5433
- https://lkml.org/lkml/2015/2/23/728
[4] [PATCH 0/3] thermal: exynos: Add support for Exynos5433 TMU
- https://lkml.org/lkml/2015/2/26/234
Changelog:
Changes from v4:
(https://lkml.org/lkml/2015/2/24/2)
- Rebased it on Linux 4.0-rc2
- Remove CONFIG_ARCH_EXYNOS5433 configuration by Arnd Bergmann's comment
- Move 'aliases' dt node from SoC dtsi to board dts file by Arnd Bergmann's
comment
- Add Exynos5433 TMU patches which got the Lukasz Majewski's reviewed message
Changes from v3:
(https://lkml.org/lkml/2015/2/12/65)
- Rebased it on Linux 4.0-rc1.
- Remove ARM_GIC and ARM_AMBA dependency because CONFIG_ARM64 already included
them.
Changes from v2:
(https://lkml.org/lkml/2014/12/2/134)
: Fix the range of GICC memory map (0x1000 -> 0x2000)
: Fix address space of 'range' property under 'soc' node
: Add ADMA / I2S dt node for sound playback/capture
- Select ARM_AMBA/ARM_GIC/HAVE_S3C_RTC for Exynos5433 in arch/arm64/Kconfig
- Send separate patch-set for Exynos5433 clock controller[1][2] and pinctrl[3]
Changes from v1:
(https://lkml.org/lkml/2014/11/27/92)
- Merge two patches (patch2, patch3) to solve incomplete description
- Exynos5433 Clock driver
: Fix wrong register and code clean by using space instead of tab
: Add CLK_IGNORE_UNUSED flag to pclk_sysreg_* clock for accessing system
control register
: Remove duplicate definition on the patch for CMU_BUS{0|1|2} domain
- Exynos5433 SoC DTS
: Remove un-supported properties of arch_timer
: Remove 'clock-frequency' property from 'cpus' dt node
: Fix interrupt type from edge rising triggering to level high triggering
because Cortex-A53/A57 use level triggering.
: Fix defult address-size/size-celss from 1 to 2 because Exynos5433 is 64-bit
SoC
: Modify 'fin_pll' dt node to remove un-needed and ugly code
: Move 'chipid' dt node under 'soc'
: Use lowercase on all case in exynos5433.dtsi
: Add PSCI dt node for secondary cpu boot
: Add 'samsung,exynos5433' compatible to MCT dt node
- Divide pinctrl patch from this patchset
- Add new following patches:
: clocksource: exynos_mct: Add the support for Exynos 64bit SoC
: arm64: Enable Exynos5433 SoC in the defconfig
Chanwoo Choi (6):
arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
arm64: dts: exynos: Add SPI/PDMA dt node for Exynos5433
arm64: dts: exynos: Add PMU dt node for Exynos5433
arm64: dts: exynos: Add RTC and ADC dt node for Exynos5433 SoC
arm64: dts: exynos: Add TMU sensor dt node for Exynos5433 SoC
arm64: dts: exynos: Add thermal-zones dt node for Exynos5433 SoC
Inha Song (2):
arm64: dts: exynos: Add ADMA dt node for Exynos5433 SoC
arm64: dts: exynos: Add I2S dt node for Exynos5433 SoC
Jaehoon Chung (1):
arm64: dts: exynos: Add MSHC dt node for Exynos5433
.../devicetree/bindings/arm/samsung/pmu.txt| 1 +
arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 698 +++
.../dts/exynos/exynos5433-tmu-sensor-conf.dtsi | 22 +
arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi | 231 +
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 931 +
5 files changed, 1883 insertions(+)
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tmu-sensor-conf.dtsi
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433.dtsi
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 2/9] arm64: dts: exynos: Add MSHC dt node for Exynos5433
From: Jaehoon Chung
This patch adds MSHC (Mobile Storage Host Controller) dt node for Exynos5433
SoC. MSHC is an interface between the system the SD/MMC card.
Cc: Kukjin Kim
Cc: Mark Rutland
Cc: Marc Zyngier
Cc: Arnd Bergmann
Cc: Olof Johansson
Cc: Catalin Marinas
Cc: Will Deacon
Signed-off-by: Jaehoon Chung
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 39 ++
1 file changed, 39 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index ecdb0eb..9b96bdf 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -655,6 +655,45 @@
status = "disabled";
};
+ mshc_0: mshc@1554 {
+ compatible = "samsung,exynos7-dw-mshc-smu";
+ interrupts = <0 225 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x1554 0x2000>;
+ clocks = <_fsys CLK_ACLK_MMC0>,
+<_fsys CLK_SCLK_MMC0>;
+ clock-names = "biu", "ciu";
+ fifo-depth = <0x40>;
+ status = "disabled";
+ };
+
+ mshc_1: mshc@1555 {
+ compatible = "samsung,exynos7-dw-mshc-smu";
+ interrupts = <0 226 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x1555 0x2000>;
+ clocks = <_fsys CLK_ACLK_MMC1>,
+<_fsys CLK_SCLK_MMC1>;
+ clock-names = "biu", "ciu";
+ fifo-depth = <0x40>;
+ status = "disabled";
+ };
+
+ mshc_2: mshc@1556 {
+ compatible = "samsung,exynos7-dw-mshc-smu";
+ interrupts = <0 227 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x1556 0x2000>;
+ clocks = <_fsys CLK_ACLK_MMC2>,
+<_fsys CLK_SCLK_MMC2>;
+ clock-names = "biu", "ciu";
+ fifo-depth = <0x40>;
+ status = "disabled";
+ };
+
timer {
compatible = "arm,armv8-timer";
interrupts = <1 13 0xff04>,
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 9/9] arm64: dts: exynos: Add thermal-zones dt node for Exynos5433 SoC
This patch adds the thermal-zones devicetree node for Exynos5433 SoC.
The thermal-zones has five thermal-zones and then each thermal-zone contains
each thermal-sensor to monitor the temperature of own IP. The {atlas0|apollo}_
thermal zone have the eight trip-points for interrupt method to detect the
over-temperature.
Cc: Kukjin Kim
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
Reviewed-by: Lukasz Majewski
---
arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi | 231 +
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 1 +
2 files changed, 232 insertions(+)
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi
new file mode 100644
index 000..7ff7b0e
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi
@@ -0,0 +1,231 @@
+/*
+ * Device tree sources for Exynos5433 thermal zone
+ *
+ * Copyright (c) 2015 Chanwoo Choi
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+
+/ {
+thermal-zones {
+ atlas0_thermal: atlas0-thermal {
+ thermal-sensors = <_atlas0>;
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+ trips {
+ atlas0_alert_0: atlas0-alert-0 {
+ temperature = <8>; /* millicelsius */
+ hysteresis = <1>; /* millicelsius */
+ type = "active";
+ };
+ atlas0_alert_1: atlas0-alert-1 {
+ temperature = <85000>; /* millicelsius */
+ hysteresis = <1>; /* millicelsius */
+ type = "active";
+ };
+ atlas0_alert_2: atlas0-alert-2 {
+ temperature = <9>; /* millicelsius */
+ hysteresis = <1>; /* millicelsius */
+ type = "active";
+ };
+ atlas0_alert_3: atlas0-alert-3 {
+ temperature = <95000>; /* millicelsius */
+ hysteresis = <1>; /* millicelsius */
+ type = "active";
+ };
+ atlas0_alert_4: atlas0-alert-4 {
+ temperature = <10>; /* millicelsius */
+ hysteresis = <1>; /* millicelsius */
+ type = "active";
+ };
+ atlas0_alert_5: atlas0-alert-5 {
+ temperature = <105000>; /* millicelsius */
+ hysteresis = <1>; /* millicelsius */
+ type = "active";
+ };
+ atlas0_alert_6: atlas0-alert-6 {
+ temperature = <11>; /* millicelsius */
+ hysteresis = <1>; /* millicelsius */
+ type = "active";
+ };
+ };
+ };
+
+ atlas1_thermal: atlas1-thermal {
+ thermal-sensors = <_atlas1>;
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+ trips {
+ atlas1_alert_0: atlas1-alert-0 {
+ temperature = <8>; /* millicelsius */
+ hysteresis = <1>; /* millicelsius */
+ type = "active";
+ };
+ atlas1_alert_1: atlas1-alert-1 {
+ temperature = <85000>; /* millicelsius */
+ hysteresis = <1>; /* millicelsius */
+ type = "active";
+ };
+ atlas1_alert_2: atlas1-alert-2 {
+ temperature = <9>; /* millicelsius */
+ hysteresis = <1>; /* millicelsius */
+ type = "active";
+ };
+ atlas1_alert_3: atlas1-alert-3 {
+ temperature = <95000>; /* millicelsius */
+ hysteresis = <1>; /* millicelsius */
+ type = "active";
+ };
+ atlas1_alert_4: atlas1-alert-4 {
+ temperature = <10>; /* millicelsius */
+ hysteresis = <1>; /* millicelsius */
+
[PATCH v5 6/9] arm64: dts: exynos: Add ADMA dt node for Exynos5433 SoC
From: Inha Song
This patch adds ADMA (Advanced DMA) device tree node for Exynos5433 SoC.
In Exynos5433 SoC, ADMA is used for I2S audio interface.
Cc: Kukjin Kim
Signed-off-by: Inha Song
Acked-by: Inki Dae
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 760ad81..abe8ea2 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -426,6 +426,17 @@
#dma-channels = <8>;
#dma-requests = <32>;
};
+
+ adma: adma@1142 {
+ compatible = "arm,pl330", "arm,primecell";
+ reg = <0x1142 0x1000>;
+ interrupts = <0 73 0>;
+ clocks = <_aud CLK_ACLK_DMAC>;
+ clock-names = "apb_pclk";
+ #dma-cells = <1>;
+ #dma-channels = <8>;
+ #dma-requests = <32>;
+ };
};
serial_0: serial@14c1 {
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [LKP] [mm] 3484b2de949: -46.2% aim7.jobs-per-min
Hi, Mel,
On Sat, 2015-02-28 at 15:30 +0800, Huang Ying wrote:
> On Sat, 2015-02-28 at 01:46 +, Mel Gorman wrote:
> > On Fri, Feb 27, 2015 at 03:21:36PM +0800, Huang Ying wrote:
> > > FYI, we noticed the below changes on
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > > commit 3484b2de9499df23c4604a513b36f96326ae81ad ("mm: rearrange zone
> > > fields into read-only, page alloc, statistics and page reclaim lines")
> > >
> > > The perf cpu-cycles for spinlock (zone->lock) increased a lot. I suspect
> > > there are some cache ping-pong or false sharing.
> > >
> >
> > Are you sure about this result? I ran similar tests here and found that
> > there was a major regression introduced near there but it was commit
> > 05b843012335 ("mm: memcontrol: use root_mem_cgroup res_counter") that
> > cause the problem and it was later reverted. On local tests on a 4-node
> > machine, commit 3484b2de9499df23c4604a513b36f96326ae81ad was within 1%
> > of the previous commit and well within the noise.
>
> After applying the below debug patch, the performance regression
> restored. So I think we can root cause this regression to be cache line
> alignment related issue?
>
> If my understanding were correct, after the 3484b2de94, lock and low
> address area free_area are in the same cache line, so that the cache
> line of the lock and the low address area of free_area will be switched
> between MESI "E" and "S" state because it is written in one CPU (page
> allocating with free_area) and frequently read (spinning on lock) in
> another CPU.
What do you think about this?
Best Regards,
Huang, Ying
> Best Regards,
> Huang, Ying
>
> ---
> include/linux/mmzone.h |2 ++
> 1 file changed, 2 insertions(+)
>
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -468,6 +468,8 @@ struct zone {
> /* Write-intensive fields used from the page allocator */
> spinlock_t lock;
>
> + ZONE_PADDING(_pad_xx_)
> +
> /* free areas of different sizes */
> struct free_areafree_area[MAX_ORDER];
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/7] soc/fman: Add the FMan RTC FLIB
From: Igal Liberman
Signed-off-by: Igal Liberman
---
drivers/soc/fsl/fman/Kconfig| 6 +
drivers/soc/fsl/fman/Makefile | 1 +
drivers/soc/fsl/fman/rtc/Makefile | 13 ++
drivers/soc/fsl/fman/rtc/fman_rtc.c | 354
4 files changed, 374 insertions(+)
create mode 100644 drivers/soc/fsl/fman/rtc/Makefile
create mode 100644 drivers/soc/fsl/fman/rtc/fman_rtc.c
diff --git a/drivers/soc/fsl/fman/Kconfig b/drivers/soc/fsl/fman/Kconfig
index 2559ee9..a144eb5 100644
--- a/drivers/soc/fsl/fman/Kconfig
+++ b/drivers/soc/fsl/fman/Kconfig
@@ -26,4 +26,10 @@ config FSL_FMAN_PCD
help
Freescale DPAA FMan Parse, Classify and Distribute support
+config FSL_FMAN_RTC
+ bool "FMan RTC"
+ default n
+ help
+ Freescale DPAA FMan Real Time Clock (PTP) support
+
endif # FSL_FMAN
diff --git a/drivers/soc/fsl/fman/Makefile b/drivers/soc/fsl/fman/Makefile
index dc37f35..f415188 100644
--- a/drivers/soc/fsl/fman/Makefile
+++ b/drivers/soc/fsl/fman/Makefile
@@ -13,5 +13,6 @@ fsl_fman-objs := fman.o
obj-$(CONFIG_FSL_FMAN_PORT)+= port/
obj-$(CONFIG_FSL_FMAN_MAC) += mac/
obj-$(CONFIG_FSL_FMAN_PCD) += pcd/
+obj-$(CONFIG_FSL_FMAN_RTC) += rtc/
endif
diff --git a/drivers/soc/fsl/fman/rtc/Makefile
b/drivers/soc/fsl/fman/rtc/Makefile
new file mode 100644
index 000..69a92fb
--- /dev/null
+++ b/drivers/soc/fsl/fman/rtc/Makefile
@@ -0,0 +1,13 @@
+ccflags-y += -DVERSION=\"\"
+
+ifeq ($(CONFIG_FSL_FMAN_RTC),y)
+
+FMAN = $(srctree)/drivers/soc/fsl/fman
+
+ccflags-y += -I$(FMAN)/flib
+
+obj-$(CONFIG_FSL_FMAN_RTC) += fsl_fman_rtc.o
+
+fsl_fman_rtc-objs := fman_rtc.o
+
+endif
diff --git a/drivers/soc/fsl/fman/rtc/fman_rtc.c
b/drivers/soc/fsl/fman/rtc/fman_rtc.c
new file mode 100644
index 000..e6d6dae
--- /dev/null
+++ b/drivers/soc/fsl/fman/rtc/fman_rtc.c
@@ -0,0 +1,354 @@
+/*
+ * Copyright 2008-2015 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include "fsl_fman_rtc.h"
+
+void fman_rtc_defconfig(struct rtc_cfg *cfg)
+{
+ int i;
+
+ cfg->src_clk = DEFAULT_SRC_CLOCK;
+ cfg->invert_input_clk_phase = DEFAULT_INVERT_INPUT_CLK_PHASE;
+ cfg->invert_output_clk_phase = DEFAULT_INVERT_OUTPUT_CLK_PHASE;
+ cfg->pulse_realign = DEFAULT_PULSE_REALIGN;
+ for (i = 0; i < FMAN_RTC_MAX_NUM_OF_ALARMS; i++)
+ cfg->alarm_polarity[i] = DEFAULT_ALARM_POLARITY;
+ for (i = 0; i < FMAN_RTC_MAX_NUM_OF_EXT_TRIGGERS; i++)
+ cfg->trigger_polarity[i] = DEFAULT_TRIGGER_POLARITY;
+}
+
+uint32_t fman_rtc_get_events(struct rtc_regs __iomem *regs)
+{
+ return ioread32be(>tmr_tevent);
+}
+
+uint32_t fman_rtc_get_event(struct rtc_regs __iomem *regs, uint32_t ev_mask)
+{
+ return ioread32be(>tmr_tevent) & ev_mask;
+}
+
+uint32_t fman_rtc_get_interrupt_mask(struct rtc_regs __iomem *regs)
+{
+ return ioread32be(>tmr_temask);
+}
+
+void fman_rtc_set_interrupt_mask(struct rtc_regs __iomem *regs, uint32_t mask)
+{
+ iowrite32be(mask, >tmr_temask);
+}
+
+void fman_rtc_ack_event(struct rtc_regs __iomem *regs, uint32_t events)
+{
+ iowrite32be(events, >tmr_tevent);
+}
+
+uint32_t
[PATCH 5/7] soc/fman: Add the FMan parser and KeyGen FLIB(s)
From: Igal Liberman
Signed-off-by: Igal Liberman
---
drivers/soc/fsl/fman/Kconfig| 6 +
drivers/soc/fsl/fman/Makefile | 1 +
drivers/soc/fsl/fman/pcd/Makefile | 13 +
drivers/soc/fsl/fman/pcd/fman_kg.c | 850
drivers/soc/fsl/fman/pcd/fman_prs.c | 127 ++
5 files changed, 997 insertions(+)
create mode 100644 drivers/soc/fsl/fman/pcd/Makefile
create mode 100644 drivers/soc/fsl/fman/pcd/fman_kg.c
create mode 100644 drivers/soc/fsl/fman/pcd/fman_prs.c
diff --git a/drivers/soc/fsl/fman/Kconfig b/drivers/soc/fsl/fman/Kconfig
index c1c258c..2559ee9 100644
--- a/drivers/soc/fsl/fman/Kconfig
+++ b/drivers/soc/fsl/fman/Kconfig
@@ -20,4 +20,10 @@ config FSL_FMAN_MAC
help
Freescale DPAA FMan MAC support
+config FSL_FMAN_PCD
+ bool "FMan PCD"
+ default n
+ help
+ Freescale DPAA FMan Parse, Classify and Distribute support
+
endif # FSL_FMAN
diff --git a/drivers/soc/fsl/fman/Makefile b/drivers/soc/fsl/fman/Makefile
index ffaabd9..dc37f35 100644
--- a/drivers/soc/fsl/fman/Makefile
+++ b/drivers/soc/fsl/fman/Makefile
@@ -12,5 +12,6 @@ fsl_fman-objs := fman.o
obj-$(CONFIG_FSL_FMAN_PORT)+= port/
obj-$(CONFIG_FSL_FMAN_MAC) += mac/
+obj-$(CONFIG_FSL_FMAN_PCD) += pcd/
endif
diff --git a/drivers/soc/fsl/fman/pcd/Makefile
b/drivers/soc/fsl/fman/pcd/Makefile
new file mode 100644
index 000..fa40367
--- /dev/null
+++ b/drivers/soc/fsl/fman/pcd/Makefile
@@ -0,0 +1,13 @@
+ccflags-y += -DVERSION=\"\"
+
+ifeq ($(CONFIG_FSL_FMAN_PCD),y)
+
+FMAN = $(srctree)/drivers/soc/fsl/fman
+
+ccflags-y += -I$(FMAN)/flib
+
+obj-$(CONFIG_FSL_FMAN_PCD) += fsl_fman_pcd.o
+
+fsl_fman_pcd-objs := fman_kg.o fman_prs.o
+
+endif
diff --git a/drivers/soc/fsl/fman/pcd/fman_kg.c
b/drivers/soc/fsl/fman/pcd/fman_kg.c
new file mode 100644
index 000..f420db6
--- /dev/null
+++ b/drivers/soc/fsl/fman/pcd/fman_kg.c
@@ -0,0 +1,850 @@
+/*
+ * Copyright 2008-2015 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include "fsl_fman_kg.h"
+
+/* static functions */
+
+static uint32_t build_ar_bind_scheme(uint8_t hwport_id, bool write)
+{
+ uint32_t rw;
+
+ rw = write ? (uint32_t)FM_KG_KGAR_WRITE : (uint32_t)FM_KG_KGAR_READ;
+
+ return (uint32_t)(FM_KG_KGAR_GO | rw | FM_PCD_KG_KGAR_SEL_PORT_ENTRY |
+ hwport_id | FM_PCD_KG_KGAR_SEL_PORT_WSEL_SP);
+}
+
+static void clear_pe_all_scheme(struct fman_kg_regs __iomem *regs,
+ uint8_t hwport_id)
+{
+ uint32_t ar;
+
+ fman_kg_write_sp(regs, 0x, 0);
+
+ ar = build_ar_bind_scheme(hwport_id, true);
+ fman_kg_write_ar_wait(regs, ar);
+}
+
+static uint32_t build_ar_bind_cls_plan(uint8_t hwport_id, bool write)
+{
+ uint32_t rw;
+
+ rw = write ? (uint32_t)FM_KG_KGAR_WRITE : (uint32_t)FM_KG_KGAR_READ;
+
+ return (uint32_t)(FM_KG_KGAR_GO | rw | FM_PCD_KG_KGAR_SEL_PORT_ENTRY |
+ hwport_id | FM_PCD_KG_KGAR_SEL_PORT_WSEL_CPP);
+}
+
+static void clear_pe_all_cls_plan(struct fman_kg_regs __iomem *regs,
+ uint8_t hwport_id)
+{
+ uint32_t ar;
+
+
[PATCH 2/7] soc/fman: Add the FMan FLIB
From: Igal Liberman
Signed-off-by: Igal Liberman
---
drivers/soc/Kconfig |1 +
drivers/soc/Makefile |1 +
drivers/soc/fsl/Kconfig |1 +
drivers/soc/fsl/Makefile |1 +
drivers/soc/fsl/fman/Kconfig |7 +
drivers/soc/fsl/fman/Makefile | 13 +
drivers/soc/fsl/fman/fman.c | 1396 +
7 files changed, 1420 insertions(+)
create mode 100644 drivers/soc/fsl/Kconfig
create mode 100644 drivers/soc/fsl/Makefile
create mode 100644 drivers/soc/fsl/fman/Kconfig
create mode 100644 drivers/soc/fsl/fman/Makefile
create mode 100644 drivers/soc/fsl/fman/fman.c
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index 76d6bd4..674a6e6 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -1,5 +1,6 @@
menu "SOC (System On Chip) specific Drivers"
+source "drivers/soc/fsl/Kconfig"
source "drivers/soc/qcom/Kconfig"
source "drivers/soc/ti/Kconfig"
source "drivers/soc/versatile/Kconfig"
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 063113d..42836ee 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -2,6 +2,7 @@
# Makefile for the Linux Kernel SOC specific device drivers.
#
+obj-$(CONFIG_FSL_SOC) += fsl/
obj-$(CONFIG_ARCH_QCOM)+= qcom/
obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_SOC_TI) += ti/
diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
new file mode 100644
index 000..38c08ae
--- /dev/null
+++ b/drivers/soc/fsl/Kconfig
@@ -0,0 +1 @@
+source "drivers/soc/fsl/fman/Kconfig"
diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
new file mode 100644
index 000..97d715c
--- /dev/null
+++ b/drivers/soc/fsl/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_FSL_FMAN) += fman/
diff --git a/drivers/soc/fsl/fman/Kconfig b/drivers/soc/fsl/fman/Kconfig
new file mode 100644
index 000..e5009a9
--- /dev/null
+++ b/drivers/soc/fsl/fman/Kconfig
@@ -0,0 +1,7 @@
+menuconfig FSL_FMAN
+ tristate "Freescale DPAA Frame Manager"
+ depends on FSL_SOC || COMPILE_TEST
+ default n
+ help
+ Freescale Data-Path Acceleration Architecture Frame Manager
+ (FMan) support
diff --git a/drivers/soc/fsl/fman/Makefile b/drivers/soc/fsl/fman/Makefile
new file mode 100644
index 000..d7fbecb
--- /dev/null
+++ b/drivers/soc/fsl/fman/Makefile
@@ -0,0 +1,13 @@
+ccflags-y += -DVERSION=\"\"
+
+ifeq ($(CONFIG_FSL_FMAN),y)
+
+FMAN = $(srctree)/drivers/soc/fsl/fman
+
+ccflags-y += -I$(FMAN)/flib
+
+obj-$(CONFIG_FSL_FMAN) += fsl_fman.o
+
+fsl_fman-objs := fman.o
+
+endif
diff --git a/drivers/soc/fsl/fman/fman.c b/drivers/soc/fsl/fman/fman.c
new file mode 100644
index 000..dbf2cd3
--- /dev/null
+++ b/drivers/soc/fsl/fman/fman.c
@@ -0,0 +1,1396 @@
+/*
+ * Copyright 2008-2015 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include "fsl_fman.h"
+
+uint32_t fman_get_bmi_err_event(struct fman_bmi_regs __iomem *bmi_rg)
+{
+ uint32_t event, mask, force;
+
+ event = ioread32be(_rg->fmbm_ievr);
+ mask = ioread32be(_rg->fmbm_ier);
+ event &= mask;
+ /* clear the forced events */
+ force = ioread32be(_rg->fmbm_ifr);
+
[PATCH 3/7] soc/fman: Add the FMan port FLIB
From: Igal Liberman
Signed-off-by: Igal Liberman
---
drivers/soc/fsl/fman/Kconfig | 10 +
drivers/soc/fsl/fman/Makefile |2 +
drivers/soc/fsl/fman/port/Makefile| 13 +
drivers/soc/fsl/fman/port/fman_port.c | 1536 +
4 files changed, 1561 insertions(+)
create mode 100644 drivers/soc/fsl/fman/port/Makefile
create mode 100644 drivers/soc/fsl/fman/port/fman_port.c
diff --git a/drivers/soc/fsl/fman/Kconfig b/drivers/soc/fsl/fman/Kconfig
index e5009a9..a5f981f 100644
--- a/drivers/soc/fsl/fman/Kconfig
+++ b/drivers/soc/fsl/fman/Kconfig
@@ -5,3 +5,13 @@ menuconfig FSL_FMAN
help
Freescale Data-Path Acceleration Architecture Frame Manager
(FMan) support
+
+if FSL_FMAN
+
+config FSL_FMAN_PORT
+ bool "FMan port"
+ default n
+ help
+ Freescale DPAA FMan port support
+
+endif # FSL_FMAN
diff --git a/drivers/soc/fsl/fman/Makefile b/drivers/soc/fsl/fman/Makefile
index d7fbecb..a0132cc 100644
--- a/drivers/soc/fsl/fman/Makefile
+++ b/drivers/soc/fsl/fman/Makefile
@@ -10,4 +10,6 @@ obj-$(CONFIG_FSL_FMAN)+= fsl_fman.o
fsl_fman-objs := fman.o
+obj-$(CONFIG_FSL_FMAN_PORT) += port/
+
endif
diff --git a/drivers/soc/fsl/fman/port/Makefile
b/drivers/soc/fsl/fman/port/Makefile
new file mode 100644
index 000..3e79c3f
--- /dev/null
+++ b/drivers/soc/fsl/fman/port/Makefile
@@ -0,0 +1,13 @@
+ccflags-y += -DVERSION=\"\"
+
+ifeq ($(CONFIG_FSL_FMAN_PORT),y)
+
+FMAN = $(srctree)/drivers/soc/fsl/fman
+
+ccflags-y += -I$(FMAN)/flib
+
+obj-$(CONFIG_FSL_FMAN_PORT)+= fsl_fman_port.o
+
+fsl_fman_port-objs := fman_port.o
+
+endif
diff --git a/drivers/soc/fsl/fman/port/fman_port.c
b/drivers/soc/fsl/fman/port/fman_port.c
new file mode 100644
index 000..cc9ebb0
--- /dev/null
+++ b/drivers/soc/fsl/fman/port/fman_port.c
@@ -0,0 +1,1536 @@
+/*
+ * Copyright 2008-2015 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include "common/general.h"
+
+#include "fman_common.h"
+#include "fsl_fman_port.h"
+
+/* problem Eyal: the following should not be here*/
+#define NIA_FM_CTL_AC_NO_IPACC_PRE_BMI_ENQ_FRAME0x0028
+
+static uint32_t get_no_pcd_nia_bmi_ac_enc_frame(struct fman_port_cfg *cfg)
+{
+ if (cfg->errata_A006675)
+ return NIA_ENG_FM_CTL |
+ NIA_FM_CTL_AC_NO_IPACC_PRE_BMI_ENQ_FRAME;
+ else
+ return NIA_ENG_BMI | NIA_BMI_AC_ENQ_FRAME;
+}
+
+static int init_bmi_rx(struct fman_port *port,
+ struct fman_port_cfg *cfg,
+ struct fman_port_params *params)
+{
+ struct fman_port_rx_bmi_regs __iomem *regs = >bmi_regs->rx;
+ uint32_t tmp;
+
+ /* Rx Configuration register */
+ tmp = 0;
+ if (cfg->discard_override)
+ tmp |= BMI_PORT_CFG_FDOVR;
+ iowrite32be(tmp, >fmbm_rcfg);
+
+ /* DMA attributes */
+ tmp = (uint32_t)cfg->dma_swap_data << BMI_DMA_ATTR_SWP_SHIFT;
+ if (cfg->dma_ic_stash_on)
+ tmp |= BMI_DMA_ATTR_IC_STASH_ON;
+ if (cfg->dma_header_stash_on)
+ tmp |= BMI_DMA_ATTR_HDR_STASH_ON;
+ if (cfg->dma_sg_stash_on)
+
[PATCH 4/7] soc/fman: Add the FMan MAC FLIB
From: Igal Liberman
Signed-off-by: Igal Liberman
---
drivers/soc/fsl/fman/Kconfig | 6 +
drivers/soc/fsl/fman/Makefile | 7 +-
drivers/soc/fsl/fman/mac/Makefile | 15 +
drivers/soc/fsl/fman/mac/fman_crc32.c | 117
drivers/soc/fsl/fman/mac/fman_crc32.h | 40 ++
drivers/soc/fsl/fman/mac/fman_dtsec.c | 844 ++
drivers/soc/fsl/fman/mac/fman_dtsec_mii_acc.c | 169 ++
drivers/soc/fsl/fman/mac/fman_memac.c | 504 +++
drivers/soc/fsl/fman/mac/fman_memac_mii_acc.c | 218 +++
drivers/soc/fsl/fman/mac/fman_tgec.c | 372
10 files changed, 2289 insertions(+), 3 deletions(-)
create mode 100644 drivers/soc/fsl/fman/mac/Makefile
create mode 100644 drivers/soc/fsl/fman/mac/fman_crc32.c
create mode 100644 drivers/soc/fsl/fman/mac/fman_crc32.h
create mode 100644 drivers/soc/fsl/fman/mac/fman_dtsec.c
create mode 100644 drivers/soc/fsl/fman/mac/fman_dtsec_mii_acc.c
create mode 100644 drivers/soc/fsl/fman/mac/fman_memac.c
create mode 100644 drivers/soc/fsl/fman/mac/fman_memac_mii_acc.c
create mode 100644 drivers/soc/fsl/fman/mac/fman_tgec.c
diff --git a/drivers/soc/fsl/fman/Kconfig b/drivers/soc/fsl/fman/Kconfig
index a5f981f..c1c258c 100644
--- a/drivers/soc/fsl/fman/Kconfig
+++ b/drivers/soc/fsl/fman/Kconfig
@@ -14,4 +14,10 @@ config FSL_FMAN_PORT
help
Freescale DPAA FMan port support
+config FSL_FMAN_MAC
+ bool "FMan MAC"
+ default n
+ help
+ Freescale DPAA FMan MAC support
+
endif # FSL_FMAN
diff --git a/drivers/soc/fsl/fman/Makefile b/drivers/soc/fsl/fman/Makefile
index a0132cc..ffaabd9 100644
--- a/drivers/soc/fsl/fman/Makefile
+++ b/drivers/soc/fsl/fman/Makefile
@@ -6,10 +6,11 @@ FMAN = $(srctree)/drivers/soc/fsl/fman
ccflags-y += -I$(FMAN)/flib
-obj-$(CONFIG_FSL_FMAN) += fsl_fman.o
+obj-$(CONFIG_FSL_FMAN) += fsl_fman.o
-fsl_fman-objs := fman.o
+fsl_fman-objs := fman.o
-obj-$(CONFIG_FSL_FMAN_PORT) += port/
+obj-$(CONFIG_FSL_FMAN_PORT)+= port/
+obj-$(CONFIG_FSL_FMAN_MAC) += mac/
endif
diff --git a/drivers/soc/fsl/fman/mac/Makefile
b/drivers/soc/fsl/fman/mac/Makefile
new file mode 100644
index 000..3188c46
--- /dev/null
+++ b/drivers/soc/fsl/fman/mac/Makefile
@@ -0,0 +1,15 @@
+ccflags-y += -DVERSION=\"\"
+
+ifeq ($(CONFIG_FSL_FMAN_MAC),y)
+
+FMAN = $(srctree)/drivers/soc/fsl/fman
+
+ccflags-y += -I$(FMAN)/flib
+
+obj-$(CONFIG_FSL_FMAN_MAC) += fsl_fman_mac.o
+
+fsl_fman_mac-objs := fman_dtsec.o fman_dtsec_mii_acc.o\
+ fman_memac.o fman_tgec.o \
+ fman_crc32.o fman_memac_mii_acc.o
+
+endif
diff --git a/drivers/soc/fsl/fman/mac/fman_crc32.c
b/drivers/soc/fsl/fman/mac/fman_crc32.c
new file mode 100644
index 000..2c85178
--- /dev/null
+++ b/drivers/soc/fsl/fman/mac/fman_crc32.c
@@ -0,0 +1,117 @@
+/*
+ * Copyright 2008-2015 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include "fman_crc32.h"
+#include "common/general.h"
+
+/* precomputed CRC values for address hashing */
+static const uint32_t crc_tbl[256] = {
[PATCH 7/7] soc/fman: Add the FMan SP FLIB
From: Igal Liberman
Signed-off-by: Igal Liberman
---
drivers/soc/fsl/fman/Makefile | 1 +
drivers/soc/fsl/fman/sp/Makefile | 13 +++
drivers/soc/fsl/fman/sp/fman_sp.c | 204 ++
3 files changed, 218 insertions(+)
create mode 100644 drivers/soc/fsl/fman/sp/Makefile
create mode 100644 drivers/soc/fsl/fman/sp/fman_sp.c
diff --git a/drivers/soc/fsl/fman/Makefile b/drivers/soc/fsl/fman/Makefile
index f415188..4a854b3 100644
--- a/drivers/soc/fsl/fman/Makefile
+++ b/drivers/soc/fsl/fman/Makefile
@@ -14,5 +14,6 @@ obj-$(CONFIG_FSL_FMAN_PORT) += port/
obj-$(CONFIG_FSL_FMAN_MAC) += mac/
obj-$(CONFIG_FSL_FMAN_PCD) += pcd/
obj-$(CONFIG_FSL_FMAN_RTC) += rtc/
+obj-$(CONFIG_FSL_FMAN) += sp/
endif
diff --git a/drivers/soc/fsl/fman/sp/Makefile b/drivers/soc/fsl/fman/sp/Makefile
new file mode 100644
index 000..4655c11
--- /dev/null
+++ b/drivers/soc/fsl/fman/sp/Makefile
@@ -0,0 +1,13 @@
+ccflags-y += -DVERSION=\"\"
+
+ifeq ($(CONFIG_FSL_FMAN),y)
+
+FMAN = $(srctree)/drivers/soc/fsl/fman
+
+ccflags-y += -I$(FMAN)/flib
+
+obj-$(CONFIG_FSL_FMAN) += fsl_fman_sp.o
+
+fsl_fman_sp-objs := fman_sp.o
+
+endif
diff --git a/drivers/soc/fsl/fman/sp/fman_sp.c
b/drivers/soc/fsl/fman/sp/fman_sp.c
new file mode 100644
index 000..e11413d
--- /dev/null
+++ b/drivers/soc/fsl/fman/sp/fman_sp.c
@@ -0,0 +1,204 @@
+/*
+ * Copyright 2008-2015 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include "fsl_fman_sp.h"
+
+uint32_t fman_vsp_get_statistics(struct fm_pcd_storage_profile_regs *regs,
+uint16_t index)
+{
+ struct fm_pcd_storage_profile_regs *sp_regs;
+
+ sp_regs = [index];
+ return ioread32be(_regs->fm_sp_acnt);
+}
+
+void fman_vsp_set_statistics(struct fm_pcd_storage_profile_regs *regs,
+uint16_t index, uint32_t value)
+{
+ struct fm_pcd_storage_profile_regs *sp_regs;
+
+ sp_regs = [index];
+ iowrite32be(value, _regs->fm_sp_acnt);
+}
+
+void fman_vsp_defconfig(struct fm_storage_profile_params *cfg)
+{
+ cfg->dma_swap_data = DEFAULT_FMAN_SP_DMA_SWAP_DATA;
+ cfg->int_context_cache_attr =
+ DEFAULT_FMAN_SP_DMA_INT_CONTEXT_CACHE_ATTR;
+ cfg->header_cache_attr = DEFAULT_FMAN_SP_DMA_HEADER_CACHE_ATTR;
+ cfg->scatter_gather_cache_attr =
+ DEFAULT_FMAN_SP_DMA_SCATTER_GATHER_CACHE_ATTR;
+ cfg->dma_write_optimize = DEFAULT_FMAN_SP_DMA_WRITE_OPTIMIZE;
+ cfg->no_scather_gather = DEFAULT_FMAN_SP_NO_SCATTER_GATHER;
+}
+
+static inline uint32_t calc_vec_dep(int max_pools, bool *pools,
+ struct fman_ext_pools *ext_buf_pools,
+ uint32_t mask)
+{
+ int i, j;
+ uint32_t vector = 0;
+
+ for (i = 0; i < max_pools; i++)
+ if (pools[i])
+ for (j = 0; j < ext_buf_pools->num_pools_used; j++)
+ if (i == ext_buf_pools->ext_buf_pool[j].id) {
+ vector |= mask >> j;
+ break;
+ }
+ return vector;
+}
+
+void fman_vsp_init(struct
Re: + zram-support-compaction.patch added to -mm tree
On (03/04/15 14:02), a...@linux-foundation.org wrote:
> +What:/sys/block/zram/compact
> +Date:August 2015
> +Contact: Minchan Kim
> +Description:
> + The compact file is write-only and trigger compaction for
> + allocator zrm uses. The allocator moves some objects so that
> + it could free fragment space.
> +
> +What:/sys/block/zram/num_migrated
> +Date:August 2015
> +Contact: Minchan Kim
> +Description:
> + The compact file is read-only and shows how many object
> + migrated by compaction.
> diff -puN drivers/block/zram/zram_drv.c~zram-support-compaction
> drivers/block/zram/zram_drv.c
> --- a/drivers/block/zram/zram_drv.c~zram-support-compaction
> +++ a/drivers/block/zram/zram_drv.c
> @@ -70,6 +70,27 @@ static inline struct zram *dev_to_zram(s
> return (struct zram *)dev_to_disk(dev)->private_data;
> }
First of all, my apologies to Andrew Morton. if I reply to this email, my mutt
for
some reason replaces akpm at linux-foundation.org with linux-kernel at
vger.kernel.org
(I can't see why this is happening, but this is somehow a `stable behaviour').
I didn't
spot this, so this is why Andrew was not Cc-d to my previous reply to this
eamil.
rather a discussion question.
Minchan, do you want to provide num_migrated as part of zsmalloc stats rather
than having yet another zram attr? we already provide zsmalloc stats and this
type of information seems to belong there. just idea.
-ss
>
> +static ssize_t compact_store(struct device *dev,
> + struct device_attribute *attr, const char *buf, size_t len)
> +{
> + unsigned long nr_migrated;
> + struct zram *zram = dev_to_zram(dev);
> + struct zram_meta *meta;
> +
> + down_read(>init_lock);
> + if (!init_done(zram)) {
> + up_read(>init_lock);
> + return -EINVAL;
> + }
> +
> + meta = zram->meta;
> + nr_migrated = zs_compact(meta->mem_pool);
> + atomic64_add(nr_migrated, >stats.num_migrated);
> + up_read(>init_lock);
> +
> + return len;
> +}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 9/9] NFS: support LOOKUP_RCU in nfs_follow_link.
If the inode is valid and the page has been read in,
then we can follow a link in RCU-walk.
Signed-off-by: NeilBrown
---
fs/nfs/inode.c | 22 ++
fs/nfs/symlink.c | 19 +--
include/linux/nfs_fs.h |1 +
3 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
index 83107be3dd01..80f192405102 100644
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -1123,6 +1123,28 @@ out:
return ret;
}
+int nfs_revalidate_mapping_rcu(struct inode *inode)
+{
+ struct nfs_inode *nfsi = NFS_I(inode);
+ unsigned long *bitlock = >flags;
+ int ret = 0;
+
+ if (IS_SWAPFILE(inode))
+ goto out;
+ if (nfs_mapping_need_revalidate_inode(inode)) {
+ ret = -ECHILD;
+ goto out;
+ }
+ spin_lock(>i_lock);
+ if (test_bit(NFS_INO_INVALIDATING, bitlock) ||
+ (nfsi->cache_validity & NFS_INO_INVALID_DATA))
+ ret = -ECHILD;
+ spin_unlock(>i_lock);
+out:
+ return ret;
+}
+
+
static unsigned long nfs_wcc_update_inode(struct inode *inode, struct
nfs_fattr *fattr)
{
struct nfs_inode *nfsi = NFS_I(inode);
diff --git a/fs/nfs/symlink.c b/fs/nfs/symlink.c
index c9a2d3cc4619..3cd295b7e094 100644
--- a/fs/nfs/symlink.c
+++ b/fs/nfs/symlink.c
@@ -49,8 +49,23 @@ static void *nfs_follow_link(struct dentry *dentry, struct
nameidata *nd)
struct page *page;
void *err;
- if (nd_is_rcu(nd))
- return ERR_PTR(-ECHILD);
+ if (nd_is_rcu(nd)) {
+ err = ERR_PTR(nfs_revalidate_mapping_rcu(inode));
+ if (err)
+ goto read_failed;
+ page = find_get_page(inode->i_mapping, 0);
+ if (page &&
+ (!PageUptodate(page) || PageHighMem(page))) {
+ put_page(page);
+ page = NULL;
+ }
+ if (!page) {
+ err = ERR_PTR(-ECHILD);
+ goto read_failed;
+ }
+ nd_set_link(nd, page_address(page));
+ return page;
+ }
err = ERR_PTR(nfs_revalidate_mapping(inode, inode->i_mapping));
if (err)
goto read_failed;
diff --git a/include/linux/nfs_fs.h b/include/linux/nfs_fs.h
index 2f77e0c651c8..78c2f812eaeb 100644
--- a/include/linux/nfs_fs.h
+++ b/include/linux/nfs_fs.h
@@ -355,6 +355,7 @@ extern int nfs_revalidate_inode(struct nfs_server *server,
struct inode *inode);
extern int nfs_revalidate_inode_rcu(struct nfs_server *server, struct inode
*inode);
extern int __nfs_revalidate_inode(struct nfs_server *, struct inode *);
extern int nfs_revalidate_mapping(struct inode *inode, struct address_space
*mapping);
+extern int nfs_revalidate_mapping_rcu(struct inode *inode);
extern int nfs_setattr(struct dentry *, struct iattr *);
extern void nfs_setattr_update_inode(struct inode *inode, struct iattr *attr);
extern void nfs_setsecurity(struct inode *inode, struct nfs_fattr *fattr,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/9] VFS/namei: use terminate_walk when symlink lookup fails.
Currently following a symlink never uses rcu-walk, so
terminate_walk isn't needed.
That will change in a future patch. In preparation, change
some
path_put_condtional()
path_put()
sequences to
path_to_nameidata()
terminate_walk()
These sequence are identical when in ref-walk, and correct when in
rcu-walk.
Also change two path_put() calls to equivalent terminate_walk().
Signed-off-by: NeilBrown
---
fs/namei.c | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index de508a3cec42..515adc4594be 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -726,6 +726,18 @@ char *nd_get_link(struct nameidata *nd)
}
EXPORT_SYMBOL(nd_get_link);
+static void terminate_walk(struct nameidata *nd)
+{
+ if (!(nd->flags & LOOKUP_RCU)) {
+ path_put(>path);
+ } else {
+ nd->flags &= ~LOOKUP_RCU;
+ if (!(nd->flags & LOOKUP_ROOT))
+ nd->root.mnt = NULL;
+ rcu_read_unlock();
+ }
+}
+
static inline void put_link(struct nameidata *nd, struct path *link, void
*cookie)
{
struct inode *inode = link->dentry->d_inode;
@@ -776,8 +788,8 @@ static inline int may_follow_link(struct path *link, struct
nameidata *nd)
return 0;
audit_log_link_denied("follow_link", link);
- path_put_conditional(link, nd);
- path_put(>path);
+ path_to_nameidata(link, nd);
+ terminate_walk(nd);
return -EACCES;
}
@@ -886,7 +898,7 @@ follow_link(struct path *link, struct nameidata *nd, void
**p)
s = nd_get_link(nd);
if (s) {
if (unlikely(IS_ERR(s))) {
- path_put(>path);
+ terminate_walk(nd);
put_link(nd, link, *p);
return PTR_ERR(s);
}
@@ -908,7 +920,7 @@ follow_link(struct path *link, struct nameidata *nd, void
**p)
out_put_nd_path:
*p = NULL;
- path_put(>path);
+ terminate_walk(nd);
path_put(link);
return error;
}
@@ -1539,18 +1551,6 @@ static inline int handle_dots(struct nameidata *nd, int
type)
return 0;
}
-static void terminate_walk(struct nameidata *nd)
-{
- if (!(nd->flags & LOOKUP_RCU)) {
- path_put(>path);
- } else {
- nd->flags &= ~LOOKUP_RCU;
- if (!(nd->flags & LOOKUP_ROOT))
- nd->root.mnt = NULL;
- rcu_read_unlock();
- }
-}
-
/*
* Do we need to follow links? We _really_ want to be able
* to do this check without having to look at inode->i_op,
@@ -1622,8 +1622,8 @@ static inline int nested_symlink(struct path *path,
struct nameidata *nd)
int res;
if (unlikely(current->link_count >= MAX_NESTED_LINKS)) {
- path_put_conditional(path, nd);
- path_put(>path);
+ path_to_nameidata(path, nd);
+ terminate_walk(nd);
return -ELOOP;
}
BUG_ON(nd->depth >= MAX_NESTED_LINKS);
@@ -3238,8 +3238,8 @@ static struct file *path_openat(int dfd, struct filename
*pathname,
struct path link = path;
void *cookie;
if (!(nd->flags & LOOKUP_FOLLOW)) {
- path_put_conditional(, nd);
- path_put(>path);
+ path_to_nameidata(, nd);
+ terminate_walk(nd);
error = -ELOOP;
break;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/9] VFS/namei: enhance follow_link to support RCU-walk.
If LOOKUP_RCU is set, follow_link will not take/drop reference counts.
Replace cond_resched() with _cond_resched() as the latter
is a no-op if rcu_read_lock() is held while the former will
give a warning in that case.
Signed-off-by: NeilBrown
---
fs/namei.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index 5814d1b2daab..4ddbc1ef5726 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -883,7 +883,8 @@ follow_link(struct path *link, struct nameidata *nd, void
**p)
if (unlikely(current->total_link_count >= 40))
goto out_put_nd_path;
- cond_resched();
+ /* If rcu_read_locked(), this will not resched, and will not warn */
+ _cond_resched();
current->total_link_count++;
if (nd->flags & LOOKUP_RCU) {
@@ -913,11 +914,17 @@ follow_link(struct path *link, struct nameidata *nd, void
**p)
return PTR_ERR(s);
}
if (*s == '/') {
- if (!nd->root.mnt)
- set_root(nd);
- path_put(>path);
- nd->path = nd->root;
- path_get(>root);
+ if (nd->flags & LOOKUP_RCU) {
+ if (!nd->root.mnt)
+ set_root_rcu(nd);
+ nd->path = nd->root;
+ } else {
+ if (!nd->root.mnt)
+ set_root(nd);
+ path_put(>path);
+ nd->path = nd->root;
+ path_get(>root);
+ }
nd->flags |= LOOKUP_JUMPED;
}
nd->inode = nd->path.dentry->d_inode;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/9] VFS/namei: abort RCU-walk on symlink if atime needs updating.
touch_atime is not RCU-safe, and so cannot be called on an
RCU walk.
However in situations where RCU-walk makes a difference,
the symlink will likely to accessed much more often than
it is useful to update the atime.
So split out the test of "Does the atime actually need to be updated"
into atime_needs_update(), and only allow RCU-walk on a symlink if
that fails.
Signed-off-by: NeilBrown
---
fs/inode.c | 26 +++---
fs/namei.c |7 ++-
include/linux/fs.h |1 +
3 files changed, 26 insertions(+), 8 deletions(-)
diff --git a/fs/inode.c b/fs/inode.c
index f00b16f45507..a0da920e4650 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -1584,30 +1584,41 @@ static int update_time(struct inode *inode, struct
timespec *time, int flags)
* This function automatically handles read only file systems and media,
* as well as the "noatime" flag and inode specific "noatime" markers.
*/
-void touch_atime(const struct path *path)
+int atime_needs_update(const struct path *path)
{
struct vfsmount *mnt = path->mnt;
struct inode *inode = path->dentry->d_inode;
struct timespec now;
if (inode->i_flags & S_NOATIME)
- return;
+ return 0;
if (IS_NOATIME(inode))
- return;
+ return 0;
if ((inode->i_sb->s_flags & MS_NODIRATIME) && S_ISDIR(inode->i_mode))
- return;
+ return 0;
if (mnt->mnt_flags & MNT_NOATIME)
- return;
+ return 0;
if ((mnt->mnt_flags & MNT_NODIRATIME) && S_ISDIR(inode->i_mode))
- return;
+ return 0;
now = current_fs_time(inode->i_sb);
if (!relatime_need_update(mnt, inode, now))
- return;
+ return 0;
if (timespec_equal(>i_atime, ))
+ return 0;
+ return 1;
+}
+
+void touch_atime(const struct path *path)
+{
+ struct vfsmount *mnt = path->mnt;
+ struct inode *inode = path->dentry->d_inode;
+ struct timespec now;
+
+ if (!atime_needs_update(path))
return;
if (!sb_start_write_trylock(inode->i_sb))
@@ -1624,6 +1635,7 @@ void touch_atime(const struct path *path)
* We may also fail on filesystems that have the ability to make parts
* of the fs read only, e.g. subvolumes in Btrfs.
*/
+ now = current_fs_time(inode->i_sb);
update_time(inode, , S_ATIME);
__mnt_drop_write(mnt);
skip_update:
diff --git a/fs/namei.c b/fs/namei.c
index a4879bb3b4ee..5814d1b2daab 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -886,7 +886,12 @@ follow_link(struct path *link, struct nameidata *nd, void
**p)
cond_resched();
current->total_link_count++;
- touch_atime(link);
+ if (nd->flags & LOOKUP_RCU) {
+ error = -ECHILD;
+ if (atime_needs_update(link))
+ goto out_put_nd_path;
+ } else
+ touch_atime(link);
nd_set_link(nd, NULL);
error = security_inode_follow_link(link->dentry, nd);
diff --git a/include/linux/fs.h b/include/linux/fs.h
index eaef987ae3cf..6665aa16abcb 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1845,6 +1845,7 @@ enum file_time_flags {
S_VERSION = 8,
};
+extern int atime_needs_update(const struct path *);
extern void touch_atime(const struct path *);
static inline void file_accessed(struct file *file)
{
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/9] XFS: allow follow_link to often succeed in RCU-walk.
If LOOKUP_RCU is set, use GFP_ATOMIC rather than GFP_KERNEL,
and try to get the ilock without blocking.
When these succeed, follow_link() can succeed without dropping
out of RCU-walk.
Signed-off-by: NeilBrown
---
fs/xfs/xfs_ioctl.c |2 +-
fs/xfs/xfs_iops.c| 15 ++-
fs/xfs/xfs_symlink.c | 11 +--
fs/xfs/xfs_symlink.h |2 +-
4 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
index ac4feae45eb3..29d95a1b76c0 100644
--- a/fs/xfs/xfs_ioctl.c
+++ b/fs/xfs/xfs_ioctl.c
@@ -303,7 +303,7 @@ xfs_readlink_by_handle(
goto out_dput;
}
- error = xfs_readlink(XFS_I(dentry->d_inode), link);
+ error = xfs_readlink(XFS_I(dentry->d_inode), link, 0);
if (error)
goto out_kfree;
error = readlink_copy(hreq->ohandle, olen, link);
diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c
index 23cea798b777..2abab666df46 100644
--- a/fs/xfs/xfs_iops.c
+++ b/fs/xfs/xfs_iops.c
@@ -415,15 +415,20 @@ xfs_vn_follow_link(
struct nameidata*nd)
{
char*link;
- int error = -ENOMEM;
+ int error;
- if (nd_is_rcu(nd))
- return ERR_PTR(-ECHILD);
- link = kmalloc(MAXPATHLEN+1, GFP_KERNEL);
+ if (nd_is_rcu(nd)) {
+ error = -ECHILD;
+ link = kmalloc(MAXPATHLEN+1, GFP_ATOMIC);
+ } else {
+ error = -ENOMEM;
+ link = kmalloc(MAXPATHLEN+1, GFP_KERNEL);
+ }
if (!link)
goto out_err;
- error = xfs_readlink(XFS_I(dentry->d_inode), link);
+ error = xfs_readlink(XFS_I(dentry->d_inode), link,
+nd_is_rcu(nd));
if (unlikely(error))
goto out_kfree;
diff --git a/fs/xfs/xfs_symlink.c b/fs/xfs/xfs_symlink.c
index 25791df6f638..87b5b2ba3d38 100644
--- a/fs/xfs/xfs_symlink.c
+++ b/fs/xfs/xfs_symlink.c
@@ -123,7 +123,8 @@ xfs_readlink_bmap(
int
xfs_readlink(
struct xfs_inode *ip,
- char*link)
+ char*link,
+ int rcu)
{
struct xfs_mount *mp = ip->i_mount;
xfs_fsize_t pathlen;
@@ -134,7 +135,11 @@ xfs_readlink(
if (XFS_FORCED_SHUTDOWN(mp))
return -EIO;
- xfs_ilock(ip, XFS_ILOCK_SHARED);
+ if (rcu) {
+ if (xfs_ilock_nowait(ip, XFS_ILOCK_SHARED) == 0)
+ return -ECHILD;
+ } else
+ xfs_ilock(ip, XFS_ILOCK_SHARED);
pathlen = ip->i_d.di_size;
if (!pathlen)
@@ -153,6 +158,8 @@ xfs_readlink(
if (ip->i_df.if_flags & XFS_IFINLINE) {
memcpy(link, ip->i_df.if_u1.if_data, pathlen);
link[pathlen] = '\0';
+ } else if (rcu) {
+ error = -ECHILD;
} else {
error = xfs_readlink_bmap(ip, link);
}
diff --git a/fs/xfs/xfs_symlink.h b/fs/xfs/xfs_symlink.h
index e75245d09116..a71d26643e20 100644
--- a/fs/xfs/xfs_symlink.h
+++ b/fs/xfs/xfs_symlink.h
@@ -21,7 +21,7 @@
int xfs_symlink(struct xfs_inode *dp, struct xfs_name *link_name,
const char *target_path, umode_t mode, struct xfs_inode **ipp);
-int xfs_readlink(struct xfs_inode *ip, char *link);
+int xfs_readlink(struct xfs_inode *ip, char *link, int rcu);
int xfs_inactive_symlink(struct xfs_inode *ip);
#endif /* __XFS_SYMLINK_H */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/9] VFS/namei: enable RCU-walk when following symlinks.
Now that follow_link handles LOOKUP_RCU, we do not need to
'unlazy_walk' when a symlink is found.
Signed-off-by: NeilBrown
---
fs/namei.c | 12
1 file changed, 12 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index 4ddbc1ef5726..11e6b2068c96 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1608,12 +1608,6 @@ static inline int walk_component(struct nameidata *nd,
struct path *path,
goto out_path_put;
if (should_follow_link(path->dentry, follow)) {
- if (nd->flags & LOOKUP_RCU) {
- if (unlikely(unlazy_walk(nd, path->dentry))) {
- err = -ECHILD;
- goto out_err;
- }
- }
BUG_ON(inode != path->dentry->d_inode);
return 1;
}
@@ -3066,12 +3060,6 @@ finish_lookup:
}
if (should_follow_link(path->dentry, !symlink_ok)) {
- if (nd->flags & LOOKUP_RCU) {
- if (unlikely(unlazy_walk(nd, path->dentry))) {
- error = -ECHILD;
- goto out;
- }
- }
BUG_ON(inode != path->dentry->d_inode);
return 1;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/9] VFS/namei: handle LOOKUP_RCU in page_follow_link_light.
If the symlink has already be been read-in, then
page_follow_link_light can succeed in RCU-walk mode.
page_getlink_rcu() is added to support this.
With this many filesystems can follow links in RCU-walk
mode when everything is cached. This includes ext?fs and
others.
If the page is a HighMem page we do *not* try to kmap_atomic,
but simply give up - only page_address() is used.
This is because we need to be able to sleep while holding
the address of the page, particularly over calls to do_last()
which can be quite slow and in particular takes a mutex.
If this were a problem, then copying into a GFP_ATOMIC allocation
might be a workable solution.
Signed-off-by: NeilBrown
---
fs/namei.c | 30 +++---
1 file changed, 27 insertions(+), 3 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index 11e6b2068c96..48571b2eaa18 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -4468,6 +4468,28 @@ static char *page_getlink(struct dentry * dentry, struct
page **ppage)
return kaddr;
}
+/* get the link contents from pagecache under RCU */
+static char *page_getlink_rcu(struct dentry * dentry, struct page **ppage)
+{
+ char *kaddr;
+ struct page *page;
+ struct address_space *mapping = dentry->d_inode->i_mapping;
+ page = find_get_page(mapping, 0);
+ if (page &&
+ (!PageUptodate(page) || PageHighMem(page))) {
+ put_page(page);
+ page = NULL;
+ }
+ if (!page) {
+ *ppage = ERR_PTR(-ECHILD);
+ return NULL;
+ }
+ *ppage = page;
+ kaddr = page_address(page);
+ nd_terminate_link(kaddr, dentry->d_inode->i_size, PAGE_SIZE - 1);
+ return kaddr;
+}
+
int page_readlink(struct dentry *dentry, char __user *buffer, int buflen)
{
struct page *page = NULL;
@@ -4484,8 +4506,9 @@ void *page_follow_link_light(struct dentry *dentry,
struct nameidata *nd)
{
struct page *page = NULL;
if (nd->flags & LOOKUP_RCU)
- return ERR_PTR(-ECHILD);
- nd_set_link(nd, page_getlink(dentry, ));
+ nd_set_link(nd, page_getlink_rcu(dentry, ));
+ else
+ nd_set_link(nd, page_getlink(dentry, ));
return page;
}
EXPORT_SYMBOL(page_follow_link_light);
@@ -4495,7 +4518,8 @@ void page_put_link(struct dentry *dentry, struct
nameidata *nd, void *cookie)
struct page *page = cookie;
if (page) {
- kunmap(page);
+ if (!(nd->flags & LOOKUP_LINK_RCU))
+ kunmap(page);
page_cache_release(page);
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/9] VFS/namei: new flag to support RCU symlinks: LOOKUP_LINK_RCU.
When we support ->follow_link in RCU-walk we will not want to
take a reference to the 'struct path *link' passed to follow_link,
and correspondingly will not want to drop that reference.
As link_path_walk will complete_walk() in the case of an error,
and as complete_walk() will clear LOOKUP_RCU, we cannot test
LOOKUP_RCU to determine if the path should be 'put'.
So introduce a new flag: LOOKUP_LINK_RCU. This is set on
entry to follow_link() if appropriate and put_link() will
only call path_put() if it is clear.
Also, unlazy_walk() will fail if LOOKUP_LINK_RCU is set.
This is because there is no way for unlazy_walk to get references
on all the "struct path *link"s that are protected by that flag.
Signed-off-by: NeilBrown
---
fs/namei.c| 18 +-
include/linux/namei.h |1 +
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index 515adc4594be..a4879bb3b4ee 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -533,6 +533,9 @@ static int unlazy_walk(struct nameidata *nd, struct dentry
*dentry)
struct dentry *parent = nd->path.dentry;
BUG_ON(!(nd->flags & LOOKUP_RCU));
+ if (nd->flags & LOOKUP_LINK_RCU)
+ /* Cannot unlazy in the middle of following a symlink */
+ return -ECHILD;
/*
* After legitimizing the bastards, terminate_walk()
@@ -743,7 +746,8 @@ static inline void put_link(struct nameidata *nd, struct
path *link, void *cooki
struct inode *inode = link->dentry->d_inode;
if (inode->i_op->put_link)
inode->i_op->put_link(link->dentry, nd, cookie);
- path_put(link);
+ if (!(nd->flags & LOOKUP_LINK_RCU))
+ path_put(link);
}
int sysctl_protected_symlinks __read_mostly = 0;
@@ -869,9 +873,10 @@ follow_link(struct path *link, struct nameidata *nd, void
**p)
int error;
char *s;
- BUG_ON(nd->flags & LOOKUP_RCU);
-
- if (link->mnt == nd->path.mnt)
+ nd->flags &= ~LOOKUP_LINK_RCU;
+ if (nd->flags & LOOKUP_RCU)
+ nd->flags |= LOOKUP_LINK_RCU;
+ else if (link->mnt == nd->path.mnt)
mntget(link->mnt);
error = -ELOOP;
@@ -921,7 +926,8 @@ follow_link(struct path *link, struct nameidata *nd, void
**p)
out_put_nd_path:
*p = NULL;
terminate_walk(nd);
- path_put(link);
+ if (!(nd->flags & LOOKUP_LINK_RCU))
+ path_put(link);
return error;
}
@@ -1644,6 +1650,8 @@ static inline int nested_symlink(struct path *path,
struct nameidata *nd)
current->link_count--;
nd->depth--;
+ if (!nd->depth)
+ nd->flags &= ~LOOKUP_LINK_RCU;
return res;
}
diff --git a/include/linux/namei.h b/include/linux/namei.h
index c8990779f0c3..34bc87845b0e 100644
--- a/include/linux/namei.h
+++ b/include/linux/namei.h
@@ -32,6 +32,7 @@ enum {LAST_NORM, LAST_ROOT, LAST_DOT, LAST_DOTDOT, LAST_BIND};
#define LOOKUP_PARENT 0x0010
#define LOOKUP_REVAL 0x0020
#define LOOKUP_RCU 0x0040
+#define LOOKUP_LINK_RCU0x0080
/*
* Intent data
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/9] Support follow_link in RCU-walk.
Hi Al (and others), I wonder if you could look over this patchset. It allows RCU-walk to follow symlinks in many common cases, thus removing a surprising performance hit caused by using symlinks. The last could of patches make changes to XFS and NFS to support this but I haven't forwarded to the relevant lists yet. If/when the early code meets with approval I'll do that. The first patch almost certainly needs to be changed. I originally wrote this code when filesystems could see inside nameidata. It is now opaque so the simplest solution was to provide an accessor function. Maybe I should as a 'flags' arg to ->follow_link?? Or have ->follow_link and ->follow_link_rcu ?? What do you suggest? Thanks, NeilBrown --- NeilBrown (9): FS: make all ->follow_link handlers aware for LOOKUP_RCU VFS/namei: use terminate_walk when symlink lookup fails. VFS/namei: new flag to support RCU symlinks: LOOKUP_LINK_RCU. VFS/namei: abort RCU-walk on symlink if atime needs updating. VFS/namei: enhance follow_link to support RCU-walk. VFS/namei: enable RCU-walk when following symlinks. VFS/namei: handle LOOKUP_RCU in page_follow_link_light. XFS: allow follow_link to often succeed in RCU-walk. NFS: support LOOKUP_RCU in nfs_follow_link. drivers/staging/lustre/lustre/llite/symlink.c |3 + fs/9p/vfs_inode.c |6 + fs/9p/vfs_inode_dotl.c|5 + fs/befs/linuxvfs.c|2 fs/cifs/link.c|2 fs/configfs/symlink.c |7 + fs/ecryptfs/inode.c |7 + fs/fuse/dir.c |2 fs/gfs2/inode.c |2 fs/hostfs/hostfs_kern.c |7 + fs/inode.c| 26 - fs/kernfs/symlink.c |7 + fs/namei.c| 132 - fs/nfs/inode.c| 22 fs/nfs/symlink.c | 17 +++ fs/overlayfs/inode.c |3 + fs/proc/base.c|2 fs/proc/namespaces.c |3 + fs/proc/self.c|4 + fs/proc/thread_self.c |4 + fs/xfs/xfs_ioctl.c|2 fs/xfs/xfs_iops.c | 13 ++ fs/xfs/xfs_symlink.c | 11 ++ fs/xfs/xfs_symlink.h |2 include/linux/fs.h|2 include/linux/namei.h |1 include/linux/nfs_fs.h|1 mm/shmem.c|6 + 28 files changed, 234 insertions(+), 67 deletions(-) -- Signature -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/9] FS: make all ->follow_link handlers aware for LOOKUP_RCU
In preparation for supporting ->follow_link in RCU-walk,
make sure all ->follow_link handers which are not atomic
will fail if LOOKUP_RCU is set.
Later patches will make some of these handle LOOKUP_RCU
more gracefully.
This is current achieved by introducing a new function
"nd_is_rcu" to check if a nameidata has LOOKUP_RCU set.
There must be a better way.
Signed-off-by: NeilBrown
---
drivers/staging/lustre/lustre/llite/symlink.c |3 +++
fs/9p/vfs_inode.c |6 +-
fs/9p/vfs_inode_dotl.c|5 -
fs/befs/linuxvfs.c|2 ++
fs/cifs/link.c|2 ++
fs/configfs/symlink.c |7 ++-
fs/ecryptfs/inode.c |7 ++-
fs/fuse/dir.c |2 ++
fs/gfs2/inode.c |2 ++
fs/hostfs/hostfs_kern.c |7 ++-
fs/kernfs/symlink.c |7 ++-
fs/namei.c|8
fs/nfs/symlink.c |2 ++
fs/overlayfs/inode.c |3 +++
fs/proc/base.c|2 ++
fs/proc/namespaces.c |3 +++
fs/proc/self.c|4
fs/proc/thread_self.c |4
fs/xfs/xfs_iops.c |2 ++
include/linux/fs.h|1 +
mm/shmem.c|6 +-
21 files changed, 78 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/lustre/lustre/llite/symlink.c
b/drivers/staging/lustre/lustre/llite/symlink.c
index 686b6a574cc5..d4ad3925f11f 100644
--- a/drivers/staging/lustre/lustre/llite/symlink.c
+++ b/drivers/staging/lustre/lustre/llite/symlink.c
@@ -125,6 +125,9 @@ static void *ll_follow_link(struct dentry *dentry, struct
nameidata *nd)
int rc;
char *symname = NULL;
+ if (nd_is_rcu(nd))
+ return PTR_ERR(-ECHILD);
+
CDEBUG(D_VFSTRACE, "VFS Op\n");
/* Limit the recursive symlink depth to 5 instead of default
* 8 links when kernel has 4k stack to prevent stack overflow.
diff --git a/fs/9p/vfs_inode.c b/fs/9p/vfs_inode.c
index 3662f1d1d9cf..8aff5d684154 100644
--- a/fs/9p/vfs_inode.c
+++ b/fs/9p/vfs_inode.c
@@ -1281,7 +1281,11 @@ done:
static void *v9fs_vfs_follow_link(struct dentry *dentry, struct nameidata *nd)
{
int len = 0;
- char *link = __getname();
+ char *link;
+
+ if (nd_is_rcu(nd))
+ return ERR_PTR(-ECHILD);
+ link = __getname();
p9_debug(P9_DEBUG_VFS, "%pd\n", dentry);
diff --git a/fs/9p/vfs_inode_dotl.c b/fs/9p/vfs_inode_dotl.c
index 6054c16b8fae..51776a3cc842 100644
--- a/fs/9p/vfs_inode_dotl.c
+++ b/fs/9p/vfs_inode_dotl.c
@@ -914,9 +914,12 @@ v9fs_vfs_follow_link_dotl(struct dentry *dentry, struct
nameidata *nd)
{
int retval;
struct p9_fid *fid;
- char *link = __getname();
+ char *link;
char *target;
+ if (nd_is_rcu(nd))
+ return ERR_PTR(-ECHILD);
+ link = __getname();
p9_debug(P9_DEBUG_VFS, "%pd\n", dentry);
if (!link) {
diff --git a/fs/befs/linuxvfs.c b/fs/befs/linuxvfs.c
index e089f1985fca..bbe8f90924b2 100644
--- a/fs/befs/linuxvfs.c
+++ b/fs/befs/linuxvfs.c
@@ -477,6 +477,8 @@ befs_follow_link(struct dentry *dentry, struct nameidata
*nd)
befs_off_t len = data->size;
char *link;
+ if (nd_is_rcu(nd))
+ return ERR_PTR(-ECHILD);
if (len == 0) {
befs_error(sb, "Long symlink with illegal length");
link = ERR_PTR(-EIO);
diff --git a/fs/cifs/link.c b/fs/cifs/link.c
index 2ec6037f61c7..0dbe1a326632 100644
--- a/fs/cifs/link.c
+++ b/fs/cifs/link.c
@@ -639,6 +639,8 @@ cifs_follow_link(struct dentry *direntry, struct nameidata
*nd)
struct cifs_tcon *tcon;
struct TCP_Server_Info *server;
+ if (nd_is_rcu(nd))
+ return ERR_PTR(-ECHILD);
xid = get_xid();
tlink = cifs_sb_tlink(cifs_sb);
diff --git a/fs/configfs/symlink.c b/fs/configfs/symlink.c
index cc9f2546ea4a..1397342aad5b 100644
--- a/fs/configfs/symlink.c
+++ b/fs/configfs/symlink.c
@@ -282,7 +282,12 @@ static int configfs_getlink(struct dentry *dentry, char *
path)
static void *configfs_follow_link(struct dentry *dentry, struct nameidata *nd)
{
int error = -ENOMEM;
- unsigned long page = get_zeroed_page(GFP_KERNEL);
+ unsigned long page;
+
+ if (nd_is_rcu(nd))
+ return ERR_PTR(-ECHILD);
+
+ page = get_zeroed_page(GFP_KERNEL);
if (page) {
error = configfs_getlink(dentry, (char *)page);
diff --git a/fs/ecryptfs/inode.c b/fs/ecryptfs/inode.c
index b08b5187f662..49d3dd96344c 100644
---
Re: [PATCH v2 3/7] zsmalloc: support compaction
Hello Minchan,
Nice work!
On 03/04/2015 02:01 PM, Minchan Kim wrote:
> +static void putback_zspage(struct zs_pool *pool, struct size_class *class,
> + struct page *first_page)
> +{
> + int class_idx;
> + enum fullness_group fullness;
> +
> + BUG_ON(!is_first_page(first_page));
> +
> + get_zspage_mapping(first_page, _idx, );
> + insert_zspage(first_page, class, fullness);
> + fullness = fix_fullness_group(class, first_page);
Removal and re-insertion of zspage above can be eliminated, like this:
fullness = get_fullness_group(first_page);
insert_zspage(first_page, class, fullness);
set_zspage_mapping(first_page, class->index, fullness);
regards,
heesub
> if (fullness == ZS_EMPTY) {
> + zs_stat_dec(class, OBJ_ALLOCATED, get_maxobj_per_zspage(
> + class->size, class->pages_per_zspage));
> atomic_long_sub(class->pages_per_zspage,
> >pages_allocated);
> +
> free_zspage(first_page);
> }
> }
> -EXPORT_SYMBOL_GPL(zs_free);
> +
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
CONFIG_PREEMPT_RT local_softirq_pending warning when ISR blocks
Hi, I'm seeing "NOHZ: local_softirq_pending" warnings with 3.14.31-rt28 (3.14.3-rt4 too). They're mostly "NOHZ: local_softirq_pending 08" (NET_RX) but they happen occasionally for other softirqs too (0c aka NET_RX and NET_TX is second-most common). CONFIG_PREEMPT_RT_FULL and CONFIG_NO_HZ_FULL(_ALL) are enabled. Heavy load on a CAN card (sja1000) consistently triggers the messages, but they also happen occasionally without explicitly trying to stress the system. I got a trace showing a threaded ISR handler blocking on an rt_mutex after raising a softirq, which results in the CPU going idle with the softirq still pending because irq_exit() hasn't happened yet. I don't know whether the softirq should somehow be getting run at that point, the message is spurious in this situation, or maybe there's some other reason this should never happen. The task holding the rt_mutex was preempted by another ISR handler at the same priority as the one which has the problem. I'm not quite sure, but i think it might have been running a softirq at the time it got preempted if that makes any difference. Here's the parts of the trace that look relevant, split up between the 2 interesting CPUs (both hyperthreads of 1 of the 2 cores in the system). If anybody can think of any other information that would be useful, please do ask. Beforehand, 000 is spending most of its time in interrupts, but bash is doing something related to memory management on it in between. bash-14721 [000] ..1 6854.629126: rt_spin_lock <-free_pcppages_bulk bash-14721 [000] 1.1 6854.629126: mm_page_pcpu_drain: page=ea000fa1aa40 pfn=4097705 order=0 migratetype=1 bash-14721 [000] ..1 6854.629127: get_pfnblock_flags_mask <-free_pcppages_bulk bash-14721 [000] ..1 6854.629127: __mod_zone_page_state <-free_pcppages_bulk bash-14721 [000] 1.1 6854.629127: mm_page_pcpu_drain: page=ea000f572ac0 pfn=4021419 order=0 migratetype=0 bash-14721 [000] ..1 6854.629128: get_pfnblock_flags_mask <-free_pcppages_bulk bash-14721 [000] ..1 6854.629128: __mod_zone_page_state <-free_pcppages_bulk ... # lots more virtually identical repetitions of those last 3 lines bash-14721 [000] 1.1 6854.629139: mm_page_pcpu_drain: page=ea000f481a80 pfn=4005994 order=0 migratetype=1 bash-14721 [000] ..1 6854.629139: get_pfnblock_flags_mask <-free_pcppages_bulk bash-14721 [000] d.1 6854.629139: do_IRQ <-ret_from_intr bash-14721 [000] d.1 6854.629139: irq_enter <-do_IRQ ... # wakes up the can1 ISR thread on 001 and the can0 one on 000 (same physical IRQ line) bash-14721 [000] d...3.1 6854.629261: sched_switch: prev_comm=bash prev_pid=14721 prev_prio=120 prev_state=R+ ==> next_comm=irq/18-can0 next_pid=2015 next_prio=28 ... # runs the can0 ISR irq/18-can0-2015 [000] d...3.. 6854.629283: sched_switch: prev_comm=irq/18-can0 prev_pid=2015 prev_prio=28 prev_state=S ==> next_comm=ksoftirqd/0 next_pid=3 next_prio=98 ... ksoftirqd/0-3 [000] 1.1 6854.629291: softirq_entry: vec=1 [action=TIMER] ... ksoftirqd/0-3 [000] 1.1 6854.629293: softirq_exit: vec=1 [action=TIMER] ... ksoftirqd/0-3 [000] ... 6854.629298: schedule <-smpboot_thread_fn ... ksoftirqd/0-3 [000] d...3.. 6854.629304: sched_switch: prev_comm=ksoftirqd/0 prev_pid=3 prev_prio=98 prev_state=S ==> next_comm=bash next_pid=14721 next_prio=28 ... bash-14721 [000] d...1.1 6854.629308: smp_trace_reschedule_interrupt <-trace_reschedule_interrupt # Actually unnecessary schedule IPI from 001? bash-14721 [000] d...1.1 6854.629309: irq_enter <-smp_trace_reschedule_interrupt ... bash-14721 [000] 1.1 6854.629316: __tick_nohz_task_switch <-__schedule bash-14721 [000] ..1 6854.629316: __mod_zone_page_state <-free_pcppages_bulk bash-14721 [000] 1.1 6854.629317: mm_page_pcpu_drain: page=ea000f57a900 pfn=4021924 order=0 migratetype=0 bash-14721 [000] ..1 6854.629317: get_pfnblock_flags_mask <-free_pcppages_bulk bash-14721 [000] ..1 6854.629317: __mod_zone_page_state <-free_pcppages_bulk ... # more of this like it was doing before I don't see it unlocking the problematic mutex before the trace ends. The relevant part for 001 starts while it's running the can1 ISR. irq/18-can1-7228 [001] 1.1 6854.629275: netif_rx: dev=can1 skbaddr=880412d8fc00 len=16 irq/18-can1-7228 [001] ..1 6854.629275: migrate_disable <-netif_rx_internal irq/18-can1-7228 [001] ..2 6854.629275: enqueue_to_backlog <-netif_rx_internal irq/18-can1-7228 [001] d.2 6854.629276: _raw_spin_lock <-enqueue_to_backlog irq/18-can1-7228 [001] d...1.2 6854.629276: __raise_softirq_irqoff <-enqueue_to_backlog irq/18-can1-7228 [001] d...1.2 6854.629276:
[PATCH] ASoC: fsl_ssi: Don't try to round-up for PM divisor calculation
According to i.MX6 Series Reference Manual, the formula to calculate
the sys clock is
sysclk rate = bclk rate * (div2 + 1) * (7 * psr + 1) * (pm + 1) * 2
Commit aafa85e71a75 ("ASoC: fsl_ssi: Add DAI master mode support for
SSI on i.MX series") added the divisor calculation which relies on
the clk_round_rate(). However, at that time, clk_round_rate() didn't
provide closest clock rates for some cases because it might not use
a correct rounding policy. So using the original formula (pm + 1) for
PM divisor was not able to give us a desired clock rate. And then we
used (pm + 2) to do the trick.
However, the clk-divider driver has been refined a lot since commit
b11d282dbea2 ("clk: divider: fix rate calculation for fractional rates")
Now using (pm + 2) trick would result an incorrect clock rate.
So this patch fixes the problem by removing the useless trick.
Reported-by: Stephane Cerveau
Signed-off-by: Nicolin Chen
---
sound/soc/fsl/fsl_ssi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 05575f4..6b0c8f7 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -603,7 +603,7 @@ static int fsl_ssi_set_bclk(struct snd_pcm_substream
*substream,
factor = (div2 + 1) * (7 * psr + 1) * 2;
for (i = 0; i < 255; i++) {
- tmprate = freq * factor * (i + 2);
+ tmprate = freq * factor * (i + 1);
if (baudclk_is_used)
clkrate = clk_get_rate(ssi_private->baudclk);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the net-next tree
From: Stephen Rothwell
Date: Thu, 5 Mar 2015 13:42:47 +1100
> From: Stephen Rothwell
> Date: Thu, 5 Mar 2015 13:37:05 +1100
> Subject: [PATCH] mpls: using vzalloc requires including vmalloc.h
>
> Fixes this build error:
>
> net/mpls/af_mpls.c: In function 'resize_platform_label_table':
> net/mpls/af_mpls.c:767:4: error: implicit declaration of function 'vzalloc'
> [-Werror=implicit-function-declaration]
> labels = vzalloc(size);
> ^
>
> Fixes: 7720c01f3f59 ("mpls: Add a sysctl to control the size of the mpls
> label table")
> Signed-off-by: Stephen Rothwell
Applied, thanks Stephen.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 2/4] pinctrl: cygnus: add gpio/pinconf driver
Hi Linus, >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >> >> This should be: >> #include In fact, just by trying it out I found I need linux/gpio.h for APIs like gpiochip_add_pin_range, and etc. >> >> > > Great! I will address all comments and re-send a BIG patch series with > the other pinctrl patch series consolidated. > > Thanks! > > Ray > I've consolidated this patch series with the IOMUX and sent out a combined patch series earlier. I believe all other comments have been addressed except the above include header one. Thanks, Ray -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] subsystem: CPU FREQUENCY DRIVERS- Set cpu_load calculation on current frequency
On 5 March 2015 at 10:06, Rahul Khandelwal (Rahul Khandelwal) wrote: > Hello Viresh, > > Thank you for your reply and the information. :) > > I have created the patch using the "diff -up" command, I think this way > should be used to create patches as mentioned in > Documentation/SubmittingPatches.. Oh, I was born after git and so never used any other way to send patches. :( > Could you please help me to know whether any kernel release using interactive > governor ? or any way to share the patch the same in any kernel release. Its not part of the kernel, you have to get this into AOSP. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the akpm-current tree
Hi Andrew,
After merging the akpm-current tree, today's linux-next build (bfin
TCM-BF537_defconfig and many others) failed like this:
(.init.text+0x5f8): undefined reference to `ioremap_huge_init'
Caused by commit 45eaed3ec431 ("lib/ioremap.c: add huge I/O map
capability interfaces"). lib/ioremp.o is only built if CONFIG_MMU is
set ...
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpCHLifB92ND.pgp
Description: OpenPGP digital signature
Re: [PATCH] thermal: cpu_cooling: fix ptr_ret.cocci warnings
On Thu, Mar 05, 2015 at 04:34:02AM +0800, kbuild test robot wrote:
> drivers/thermal/cpu_cooling.c:463:18-24: WARNING: PTR_ERR_OR_ZERO can be used
>
>
> Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
>
> Generated by: scripts/coccinelle/api/ptr_ret.cocci
>
> CC: Javi Merino
> Signed-off-by: Fengguang Wu
> ---
>
> cpu_cooling.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -460,7 +460,7 @@ static int get_static_power(struct cpufr
> if (voltage == 0) {
> dev_warn_ratelimited(cpufreq_device->cpu_dev,
>"Failed to get voltage for frequency %lu:
> %ld\n",
> - freq_hz, IS_ERR(opp) ? PTR_ERR(opp) : 0);
> + freq_hz, PTR_ERR_OR_ZERO(opp));
This patch causes this compilation warning.
In file included from include/linux/device.h:27:0,
from include/linux/thermal.h:30,
from drivers/thermal/cpu_cooling.c:26:
drivers/thermal/cpu_cooling.c: In function ‘get_static_power’:
include/linux/ratelimit.h:31:9: warning: format ‘%ld’ expects argument of type
‘long int’, but argument 4 has type ‘int’ [-Wformat=]
struct ratelimit_state name = \
^
include/linux/device.h:1162:9: note: in expansion of macro
‘DEFINE_RATELIMIT_STATE’
static DEFINE_RATELIMIT_STATE(_rs,\
^
include/linux/device.h:1178:2: note: in expansion of macro
‘dev_level_ratelimited’
dev_level_ratelimited(dev_warn, dev, fmt, ##__VA_ARGS__)
^
drivers/thermal/cpu_cooling.c:463:3: note: in expansion of macro
‘dev_warn_ratelimited’
dev_warn_ratelimited(cpufreq_device->cpu_dev,
^
> return -EINVAL;
> }
>
signature.asc
Description: Digital signature
Re: [PATCH] tick/broadcast-hrtimer : Fix suspicious RCU usage in idle loop
On 03/02/2015 08:23 PM, Peter Zijlstra wrote:
> On Thu, Feb 26, 2015 at 08:52:02AM +0530, Preeti U Murthy wrote:
>> The hrtimer mode of broadcast queues hrtimers in the idle entry
>> path so as to wakeup cpus in deep idle states.
>
> Callgraph please...
cpuidle_idle_call()
| clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, ))
|_tick_broadcast_set_event()
|clockevents_program_event()
|bc_set_next()
>
>> hrtimer_{start/cancel}
>> functions call into tracing which uses RCU. But it is not legal to call
>> into RCU in cpuidle because it is one of the quiescent states. Hence
>> protect this region with RCU_NONIDLE which informs RCU that the cpu
>> is momentarily non-idle.
>
> It it not clear to me that every user of bc_set_next() is from IDLE.
> From what I can tell it ends up being clockevents_program_event() and
> that is called quite a lot.
bc_set_next() is called from at places:
1. Idle entry : It is called when a cpu in its idle entry path finds the
need to reset the broadcast hrtimer.
2. CPU offline operations : When the cpu on which the broadcast hrtimer
is being queued goes offline.
So you see that almost all the time, it is called in idle entry path.
Regards
Preeti U Murthy
>
> Why is bc_set_next() a good function to annotate?
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1] subsystem: CPU FREQUENCY DRIVERS- Set cpu_load calculation on current frequency
Hello Viresh, Thank you for your reply and the information. :) I have created the patch using the "diff -up" command, I think this way should be used to create patches as mentioned in Documentation/SubmittingPatches.. Could you please help me to know whether any kernel release using interactive governor ? or any way to share the patch the same in any kernel release. Otherwise I will share the patch to Android guys. -Original Message- From: Viresh Kumar [mailto:viresh.ku...@linaro.org] Sent: 03 March 2015 16:17 To: Rahul Khandelwal (Rahul Khandelwal) Cc: r...@rjwysocki.net; a...@linux-foundation.org; linux-kernel@vger.kernel.org; sta...@vger.kernel.org Subject: Re: [PATCH 1/1] subsystem: CPU FREQUENCY DRIVERS- Set cpu_load calculation on current frequency Hi Newbie :) On 3 March 2015 at 12:59, Rahul Khandelwal (Rahul Khandelwal) wrote: > From: Rahul Khandelwal > > > > Explanation: When cpu governor fails to set the freq to target_freq, > the cpu_load calculation is incorrect which is calculating on target_freq. > > The cpu_load should be calculated on the pcpu->policy->cur not on the > target_freq, the cpu delta_time and delta_idle is calculated on > current freq. > > > > Signed-off-by: Rahul Khandelwal > Your company probably uses Microsoft exchange server (All do) and that corrupts these mails badly.. Over that I don't know what tool you used to send the patch as it doesn't look like 'git' for sure.. But that's not really a problem if you do it correctly.. > > --- kernel/drivers/cpufreq/cpufreq_interactive.c.orig2015-03-03 > 12:22:39.070543314 +0530 .orig ?? > +++ kernel/drivers/cpufreq/cpufreq_interactive.c 2015-03-03 > 12:22:36.210543640 +0530 And that too on interactive governor. Before sending patches to Linux kernel, go through the rules please. Documentation/SubmittingPatches.. If you have gone through that it would have been nicer, anyway lets proceed. You haven't rebased this on any kernel or rc release of official Linux kernel, but on some release on Android. Android is kept separately and interactive governor is not part of mainline kernel. If you want this patch to go through, you need to use gerrit to send it to Android guys..
Re: [GIT PULL 00/21] perf/core improvements and fixes
Hi Arnaldo, Ingo,
What happened with this pull request? I already
see in v4.0-rc2 changes additions to one requested
by this pull request, but I don't see this series itself.
For example e370a3d57664cd5e39c0b95d157ebc841b568409
"perf symbols: Define EM_AARCH64 for older OSes" by David
is already in v4.0-rc2 and it is supposed to be addition to
"perf symbols: Ignore mapping symbols on aarch64" that is part
of this pull request but it did not make into v4.0-rcX yet. Looks
quite strange.
Thanks,
Victor
On 11 February 2015 at 13:08, Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling,
>
> - Arnaldo
>
> The following changes since commit 2fde4f94e0a9531251e706fa57131b51b0df042e:
>
> perf: Decouple unthrottling and rotating (2015-02-04 08:07:16 +0100)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
> tags/perf-core-for-mingo
>
> for you to fetch changes up to 39f5704399042fff5f0d5f6af32bbbc3e787a897:
>
> perf tools: Define _GNU_SOURCE on pthread_attr_setaffinity_np feature check
> (2015-02-11 17:38:55 -0300)
>
>
> perf/core improvement and fixes:
>
> User visible:
>
> - No need to explicitely enable evsels for workload started from perf, let it
> be enabled via perf_event_attr.enable_on_exec, removing some events that
> take
> place in the 'perf trace' before a workload is really started by it.
> (Arnaldo Carvalho de Melo)
>
> - Fix to handle optimized not-inlined functions in 'perf probe' (Masami
> Hiramatsu)
>
> - Update 'perf probe' man page (Masami Hiramatsu)
>
> Infrastructure:
>
> Arnaldo Carvalho de Melo (4):
> - Introduce {trace_seq_do,event_format_}_fprintf functions to allow
> a default tracepoint field list printer to be used in tools that allows
> redirecting output to a file. (Arnaldo Carvalho de Melo)
>
> - The man page for pthread_attr_set_affinity_np states that _GNU_SOURCE
> must be defined before pthread.h, do it to fix the build in some
> systems (Josh Boyer)
>
> - Cleanups in 'perf buildid-cache' (Masami Hiramatsu)
>
> - Fix dso cache test case (Namhyung Kim)
>
> - Do Not rely on dso__data_read_offset() to open DSO (Namhyung Kim)
>
> - Make perf aware of tracefs (Steven Rostedt).
>
> - Fix build by defining STT_GNU_IFUNC for glibc 2.9 and older (Vinson Lee)
>
> - AArch64 symbol resolution fixes (Victor Kamensky)
>
> Signed-off-by: Arnaldo Carvalho de Melo
>
>
> Arnaldo Carvalho de Melo (4):
> tools lib traceevent: Introduce trace_seq_do_fprintf function
> perf tools: Introduce event_format__fprintf method
> perf trace: No need to enable evsels for workload started from perf
> perf evlist: Fix typo in comment
>
> Josh Boyer (1):
> perf tools: Define _GNU_SOURCE on pthread_attr_setaffinity_np feature
> check
>
> Masami Hiramatsu (4):
> perf probe: Fix to handle optimized not-inlined functions
> perf probe: Update man page
> perf buildid-cache: Remove unneeded debugdir parameters
> perf buildid-cache: Consolidate .build-id cache path generators
>
> Namhyung Kim (3):
> perf test: Fix dso cache testcase
> perf tests: Do not rely on dso__data_read_offset() to open dso
> perf tools: Fix a dso open fail message
>
> Steven Rostedt (Red Hat) (6):
> perf tools: Do not check debugfs MAGIC for tracing files
> tools lib fs: Add helper to find mounted file systems
> tools lib api fs: Add tracefs mount helper functions
> tools lib api debugfs: Add DEBUGFS_DEFAULT_PATH macro
> tools lib api fs: Add {tracefs,debugfs}_configured() functions
> perf tools: Make perf aware of tracefs
>
> Victor Kamensky (2):
> perf symbols: Ignore mapping symbols on aarch64
> perf symbols: debuglink should take symfs option into account
>
> Vinson Lee (1):
> perf symbols: Define STT_GNU_IFUNC for glibc 2.9 and older.
>
> tools/lib/api/Makefile| 4 ++
> tools/lib/api/fs/debugfs.c| 69 +++---
> tools/lib/api/fs/debugfs.h| 13 +
> tools/lib/api/fs/findfs.c | 63
> tools/lib/api/fs/findfs.h | 23
> tools/lib/api/fs/tracefs.c| 78 +
> tools/lib/api/fs/tracefs.h| 21 +++
> tools/lib/traceevent/event-parse.h| 2 +
> tools/lib/traceevent/trace-seq.c | 13 +++--
> tools/perf/Documentation/perf-probe.txt | 16 +-
> tools/perf/builtin-buildid-cache.c| 37 ++--
> tools/perf/builtin-trace.c| 4 +-
> tools/perf/config/feature-checks/Makefile | 2 +-
> tools/perf/tests/dso-data.c | 22 ---
> tools/perf/tests/open-syscall-all-cpus.c | 7 ++-
> tools/perf/tests/open-syscall.c | 7 ++-
>
Re: [PATCH 32/35] clockevents: Fix cpu down race for hrtimer based broadcasting
On 03/02/2015 08:26 PM, Peter Zijlstra wrote:
> On Fri, Feb 27, 2015 at 02:19:05PM +0530, Preeti U Murthy wrote:
>> The problem reported in the changelog of this patch is causing severe
>> regressions very frequently on our machines for certain usecases. It would
>> help to put in a fix in place first and then follow that up with these
>> cleanups. A fix on the below lines :
>
> Regression how? Neither Thomas' Changelog, nor yours mention its a
> regression.
>
> If its a (recent) Regression you need to have a Fixes tag at the very
> least. So when was this broken and by which patch?
>
It was found recently when doing a hotplug stress test on POWER, that
the machine hits lockups spewing
NMI watchdog: BUG: soft lockup - CPU#20 stuck for 23s! [swapper/20:0]
or
INFO: rcu_sched detected stalls on CPUs/tasks: { 2 7 8 9 10 11 12 13 14 15
16 17 18 19 20 21 22 23 2
4 25 26 27 28 29 30 31} (detected by 6, t=2102 jiffies, g=1617, c=1616,
q=1441)
and many other messages about lockups.
This issue was reported here:
http://linuxppc.10917.n7.nabble.com/offlining-cpus-breakage-td88619.html
and was traced to
commit 7cba160ad789a powernv/cpuidle: Redesign idle states management,
which exposed the loophole in commit 5d1638acb9f6(tick: Introduce
hrtimer based broadcast) and is reported in the changelog of the patch.
Regards
Preeti U Murthy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/2] ARM: OMAP2+: wkup_m3_rproc support patches
Hi, This series adds the mach-omap2 code for the wkup_m3_rproc driver submitted here [1]. pdata-quirks patch requires the pdata added with patch 3 of the aforementioned series. The dt patch was previously included as part of the rproc series here [2]. Changes are: v1->v2: -Because the firmware loading has changed, the wkup_m3 node has moved into the soc node and ranges have been added so the device address to virtual address translation can work. -Removed the ti,no-reset-on-init flag as asserting the hard-reset line on init is what the wkup_m3 has by default already. Regards, Dave [1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg114621.html [2] http://www.spinics.net/lists/arm-kernel/msg387984.html Dave Gerlach (2): ARM: OMAP2+: Use pdata-quirks for wkup_m3 deassert_hardreset ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges arch/arm/boot/dts/am33xx.dtsi | 21 + arch/arm/mach-omap2/pdata-quirks.c | 13 + 2 files changed, 26 insertions(+), 8 deletions(-) -- 2.3.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges
Signed-off-by: Suman Anna
Signed-off-by: Dave Gerlach
---
arch/arm/boot/dts/am33xx.dtsi | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index acd3705..086415c 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -77,10 +77,23 @@
*/
soc {
compatible = "ti,omap-infra";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x44d0 0x4000>,
+<0x8 0x44d8 0x2000>;
+
mpu {
compatible = "ti,omap3-mpu";
ti,hwmods = "mpu";
};
+
+ wkup_m3: wkup_m3@44d0 {
+ compatible = "ti,am3353-wkup-m3";
+ reg = <0x0 0x4000>, /* M3 UMEM */
+ <0x8 0x2000>; /* M3 DMEM */
+ ti,hwmods = "wkup_m3";
+ ti,pm-firmware = "am335x-pm-firmware.elf";
+ };
};
am33xx_control_module: control_module@4a002000 {
@@ -755,14 +768,6 @@
reg = <0x4030 0x1>; /* 64k */
};
- wkup_m3: wkup_m3@44d0 {
- compatible = "ti,am3353-wkup-m3";
- reg = <0x44d0 0x4000/* M3 UMEM */
- 0x44d8 0x2000>; /* M3 DMEM */
- ti,hwmods = "wkup_m3";
- ti,no-reset-on-init;
- };
-
elm: elm@4808 {
compatible = "ti,am3352-elm";
reg = <0x4808 0x2000>;
--
2.3.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] ARM: OMAP2+: Use pdata-quirks for wkup_m3 deassert_hardreset
Use pdata-quirks to provide platform data required for reset
of the wkup_m3 during boot.
Signed-off-by: Dave Gerlach
---
This patch requires the pdata introduced in this patch:
https://www.mail-archive.com/linux-omap@vger.kernel.org/msg114622.html
arch/arm/mach-omap2/pdata-quirks.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index 190fa43..7a09513 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -18,6 +18,7 @@
#include
#include
+#include
#include "common.h"
#include "common-board-devices.h"
@@ -287,6 +288,14 @@ static void __init omap3_tao3530_legacy_init(void)
}
#endif /* CONFIG_ARCH_OMAP3 */
+#ifdef CONFIG_SOC_AM33XX
+static struct wkup_m3_platform_data wkup_m3_data = {
+ .reset_name = "wkup_m3",
+ .assert_reset = omap_device_assert_hardreset,
+ .deassert_reset = omap_device_deassert_hardreset,
+};
+#endif
+
#ifdef CONFIG_ARCH_OMAP4
static void __init omap4_sdp_legacy_init(void)
{
@@ -382,6 +391,10 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("ti,am3517-emac", 0x5c00, "davinci_emac.0",
_emac_pdata),
#endif
+#ifdef CONFIG_SOC_AM33XX
+ OF_DEV_AUXDATA("ti,am3353-wkup-m3", 0x44d0, "44d0.wkup_m3",
+ _m3_data),
+#endif
#ifdef CONFIG_ARCH_OMAP4
OF_DEV_AUXDATA("ti,omap4-padconf", 0x4a100040, "4a100040.pinmux",
_pdata),
OF_DEV_AUXDATA("ti,omap4-padconf", 0x4a31e040, "4a31e040.pinmux",
_pdata),
--
2.3.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] drm/msm/mdp5: Make the intf connection in config module
On 03/04/2015 09:14 PM, "Stéphane Viau" wrote:
Hi,
Hi Archit,
On 03/04/2015 12:06 AM, Stephane Viau wrote:
Up until now, we assume that eDP is tight to intf_0 and HDMI to
intf_3. This information shall actually come from the mdp5_cfg
module since it can change from one chip to another.
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 8 +++
drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h | 4 ++
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 111
++--
3 files changed, 74 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
index 72c075a..8bee023 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
@@ -62,6 +62,10 @@ const struct mdp5_cfg_hw msm8x74_config = {
.count = 4,
.base = { 0x12500, 0x12700, 0x12900, 0x12b00 },
},
+ .intfs = {
+ [0] = INTF_eDP,
+ [3] = INTF_HDMI,
+ },
.max_clk = 2,
};
@@ -111,6 +115,10 @@ const struct mdp5_cfg_hw apq8084_config = {
.count = 5,
.base = { 0x12500, 0x12700, 0x12900, 0x12b00, 0x12d00 },
},
+ .intfs = {
+ [0] = INTF_eDP,
+ [3] = INTF_HDMI,
+ },
.max_clk = 32000,
};
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
index be149b3..4e91f14 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
@@ -58,6 +58,8 @@ struct mdp5_smp_block {
int reserved[MAX_CLIENTS]; /* # of MMBs allocated per client */
};
+#define MDP5_INTF_NUM_MAX 5
+
struct mdp5_cfg_hw {
char *name;
@@ -71,6 +73,8 @@ struct mdp5_cfg_hw {
struct mdp5_sub_block ad;
struct mdp5_sub_block intf;
+ u32 intfs[MDP5_INTF_NUM_MAX]; /* array of enum mdp5_intf_type */
+
The array type could be "enum mdp5_intf_type" rather than u32.
The problem here is that mdp5_cfg.h must be included before mdp5.xml.h
(see mdp5_kms.h #24) so that mdp5_cfg pointer can be resolved in the
latter.
mdp5_cfg.h hence cannot use any types defined in mdp5.xml.h, including
'enum mdp5_intf_type'.
Ah okay.
uint32_t max_clk;
};
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index 390d9d2..8cec00e 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -161,6 +161,44 @@ int mdp5_enable(struct mdp5_kms *mdp5_kms)
return 0;
}
+static int construct_encoder(struct mdp5_kms *mdp5_kms,
+ enum mdp5_intf_type intf_type, int intf_num)
+{
+ struct drm_device *dev = mdp5_kms->dev;
+ struct msm_drm_private *priv = dev->dev_private;
+ struct drm_encoder *encoder;
+ struct mdp5_interface intf = {
+ .num= intf_num,
+ .type = intf_type,
+ .mode = MDP5_INTF_MODE_NONE,
+ };
+ int ret = 0;
+
+ encoder = mdp5_encoder_init(dev, );
+ if (IS_ERR(encoder)) {
+ ret = PTR_ERR(encoder);
+ dev_err(dev->dev, "failed to construct encoder: %d\n", ret);
+ return ret;
+ }
+
+ encoder->possible_crtcs = (1 << priv->num_crtcs) - 1;
+ priv->encoders[priv->num_encoders++] = encoder;
+
+ if (intf_type == INTF_HDMI) {
+ ret = hdmi_modeset_init(priv->hdmi, dev, encoder);
+ if (ret)
+ dev_err(dev->dev, "failed to init HDMI: %d\n", ret);
+
+ } else if (intf_type == INTF_eDP) {
+ /* Construct bridge/connector for eDP: */
+ ret = msm_edp_modeset_init(priv->edp, dev, encoder);
+ if (ret)
+ dev_err(dev->dev, "failed to init eDP: %d\n", ret);
+ }
+
+ return ret;
+}
+
static int modeset_init(struct mdp5_kms *mdp5_kms)
{
static const enum mdp5_pipe crtcs[] = {
@@ -171,7 +209,6 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
};
struct drm_device *dev = mdp5_kms->dev;
struct msm_drm_private *priv = dev->dev_private;
- struct drm_encoder *encoder;
const struct mdp5_cfg_hw *hw_cfg;
int i, ret;
@@ -222,56 +259,29 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
}
}
- if (priv->hdmi) {
- struct mdp5_interface intf = {
- .num= 3,
- .type = INTF_HDMI,
- .mode = MDP5_INTF_MODE_NONE,
- };
-
- /* Construct encoder for HDMI: */
- encoder = mdp5_encoder_init(dev, );
- if (IS_ERR(encoder)) {
- dev_err(dev->dev, "failed to construct encoder\n");
-
Re: [PATCH v2 1/4] cpufreq-dt: add clock domain and intermediate frequency support
On 5 March 2015 at 09:02, Pi-Cheng Chen wrote: > In the case of Mediatek SoC, the intermediate frequency might not be one entry > of OPP table. To elaborate, the source clock node of the CPUs/Cluster on > Mediatek SoC is a mux. The mux has several PLLs as parents. When we are > doing CPU frequency scaling, the mux should re-parent to another stable PLL, > wait until the original parent PLL become stable, and then switch back to the > original parent. In this case, we could but we might not want the intermediate > frequency as part of OPP table. Therefore I save intermediate_freq instead of > intermediate frequency index in the cpufreq_dt_platform_datat struct. Hmm, I remember that discussion. Okay leave it as is. > BTW, is this case that intermediate frequency is not necessarily be one entry > of OPP table supported in the OPPv2 bindings? Not yet, but will add a property for that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/3] remoteproc: Introduce wkup_m3_rproc driver
Hi, This patch series is version two of the series to add a wkup_m3_rproc driver for TI AM335x SoCs. This family of SoCs contains an ARM Cortex M3 coprocessor that is responsible for low-level power tasks that cannot be handled by the main ARM Cortex A8 so firmware running from the CM3 can be used instead. This driver handles loading of the firmware and reset of the CM3 once it is booted. The previous version of this series can be found here [1]. I have pushed a branch based on v4.0-rc1 containing the entire am335x suspend series here for a higher level view of the entire series of patch sets here [2]. This patch set contains a new patch from Suman Anna that replaces the RSC_INTMEM patch that this series used to depend on based on comments on that series. More info is included in the patch. Additional changes are: v1 -> v2: -firmware loaded has changed, new code added by Suman Anna -wkup_m3_rproc can now be built and loaded as a module -added binding info and docs for am437x support -dts and pdata-quirks patch split to separate mach-omap2 series -remove ti,no-reset-on-init from required dt binding as it asserts hardreset which is default state of wkup_m3 anyway The driver expects to load firmware am335x-pm-firmware.elf from /lib/firmware which is found here [3]. Regards, Dave [1] http://www.spinics.net/lists/arm-kernel/msg387984.html [2] https://github.com/dgerlach/linux-pm/tree/pm-v4.0-rc1-am335x-suspend [3] https://git.ti.com/ti-cm3-pm-firmware/amx3-cm3/commits/next-upstream Dave Gerlach (2): Documentation: dt: add ti,am3353-wkup-m3 bindings remoteproc: wkup_m3: Add wkup_m3 remoteproc driver Suman Anna (1): remoteproc: add a rproc ops for performing address translation .../bindings/remoteproc/wkup_m3_rproc.txt | 46 + drivers/remoteproc/Kconfig | 13 ++ drivers/remoteproc/Makefile| 1 + drivers/remoteproc/remoteproc_core.c | 31 ++- drivers/remoteproc/wkup_m3_rproc.c | 229 + include/linux/platform_data/wkup_m3.h | 25 +++ include/linux/remoteproc.h | 2 + 7 files changed, 341 insertions(+), 6 deletions(-) create mode 100644 Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt create mode 100644 drivers/remoteproc/wkup_m3_rproc.c create mode 100644 include/linux/platform_data/wkup_m3.h -- 2.3.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/3] remoteproc: wkup_m3: Add wkup_m3 remoteproc driver
Add a remoteproc driver to load the firmware for and boot the wkup_m3
present on am33xx and am43xx. The wkup_m3 is an integrated Cortex M3
that allows the SoC to enter the lowest possible power state by taking
control from the MPU after it has gone into its own low power state and
shutting off any additional peripherals.
Signed-off-by: Dave Gerlach
---
drivers/remoteproc/Kconfig| 13 ++
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/wkup_m3_rproc.c| 229 ++
include/linux/platform_data/wkup_m3.h | 25
4 files changed, 268 insertions(+)
create mode 100644 drivers/remoteproc/wkup_m3_rproc.c
create mode 100644 include/linux/platform_data/wkup_m3.h
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 5e343ba..f73ba65 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -41,6 +41,19 @@ config STE_MODEM_RPROC
This can be either built-in or a loadable module.
If unsure say N.
+config WKUP_M3_RPROC
+ tristate "AMx3xx wkup-m3 remoteproc support"
+ depends on SOC_AM33XX || SOC_AM43XX
+ select REMOTEPROC
+ help
+ Say y here to support AMx3xx wkup-m3.
+
+ Required for Suspend-to-ram on AM33xx and AM43XX. Also needed
+ for deep CPUIdle states on AM33xx. Allows for loading of
+ firmware of CM3 PM coprocessor that is present on AMx3xx
+ family of SoCs.
+ If unsure say N.
+
config DA8XX_REMOTEPROC
tristate "DA8xx/OMAP-L13x remoteproc support"
depends on ARCH_DAVINCI_DA8XX
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index ac2ff75..81b04d1 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -9,4 +9,5 @@ remoteproc-y+= remoteproc_virtio.o
remoteproc-y += remoteproc_elf_loader.o
obj-$(CONFIG_OMAP_REMOTEPROC) += omap_remoteproc.o
obj-$(CONFIG_STE_MODEM_RPROC) += ste_modem_rproc.o
+obj-$(CONFIG_WKUP_M3_RPROC)+= wkup_m3_rproc.o
obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
diff --git a/drivers/remoteproc/wkup_m3_rproc.c
b/drivers/remoteproc/wkup_m3_rproc.c
new file mode 100644
index 000..252f6f7
--- /dev/null
+++ b/drivers/remoteproc/wkup_m3_rproc.c
@@ -0,0 +1,229 @@
+/*
+ * TI AMx3 Wkup M3 Remote Processor driver
+ *
+ * Copyright (C) 2014-2015 Texas Instruments, Inc.
+ *
+ * Dave Gerlach
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "remoteproc_internal.h"
+
+#define WKUPM3_MEM_MAX 2
+
+struct wkup_m3_mem {
+ void __iomem *cpu_addr;
+ phys_addr_t bus_addr;
+ u32 dev_addr;
+ size_t size;
+};
+
+struct wkup_m3_rproc {
+ struct rproc *rproc;
+ struct platform_device *pdev;
+ struct wkup_m3_mem mem[WKUPM3_MEM_MAX];
+};
+
+static int wkup_m3_rproc_start(struct rproc *rproc)
+{
+ struct wkup_m3_rproc *wkupm3 = rproc->priv;
+ struct platform_device *pdev = wkupm3->pdev;
+ struct device *dev = >dev;
+ struct wkup_m3_platform_data *pdata = dev->platform_data;
+
+ if (pdata->deassert_reset(pdev, pdata->reset_name)) {
+ dev_err(dev, "Unable to reset wkup_m3!\n");
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static int wkup_m3_rproc_stop(struct rproc *rproc)
+{
+ struct wkup_m3_rproc *wkupm3 = rproc->priv;
+ struct platform_device *pdev = wkupm3->pdev;
+ struct device *dev = >dev;
+ struct wkup_m3_platform_data *pdata = dev->platform_data;
+
+ if (pdata->assert_reset(pdev, pdata->reset_name)) {
+ dev_err(dev, "Unable to assert reset of wkup_m3!\n");
+ return -ENODEV;
+ }
+ return 0;
+}
+
+static void *wkup_m3_rproc_da_to_va(struct rproc *rproc, u64 da, int len)
+{
+ struct wkup_m3_rproc *wkupm3 = rproc->priv;
+ void *va = NULL;
+ int i;
+ u32 offset;
+
+ if (len <= 0)
+ return NULL;
+
+ for (i = 0; i < WKUPM3_MEM_MAX; i++) {
+ if (da >= wkupm3->mem[i].dev_addr &&
+ da + len <= wkupm3->mem[i].dev_addr +
+ wkupm3->mem[i].size) {
+ offset = da - wkupm3->mem[i].dev_addr;
+ va = (__force void *)(wkupm3->mem[i].cpu_addr + offset);
+ break;
+ }
+ }
+
+ return va;
+}
+
[PATCH v2 2/3] Documentation: dt: add ti,am3353-wkup-m3 bindings
Add the device tree bindings document for ti,am3353-wkup-m3 which is
used by the wkup_m3_rproc driver.
Signed-off-by: Dave Gerlach
---
.../bindings/remoteproc/wkup_m3_rproc.txt | 46 ++
1 file changed, 46 insertions(+)
create mode 100644
Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
diff --git a/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
b/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
new file mode 100644
index 000..995af3d
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
@@ -0,0 +1,46 @@
+Wakeup M3 Remoteproc Driver
+===
+
+TI AMx3 family of devices use a Cortex M3 co-processor to help with various
+low power tasks that cannot be controlled from the MPU. The CM3 requires
+a firmware binary to accomplish this. The wkup_m3 remoteproc driver handles
+the loading of the firmware and booting of the CM3.
+
+Wkup M3 Device Node:
+
+A wkup_m3 device node is used to represent a wakeup M3 IP instance within
+a SoC.
+
+Required properties:
+
+- compatible: Should be:
+ "ti,am3353-wkup-m3" for AM33xx SoCs
+ "ti,am4372-wkup-m3" for AM43xx SoCs
+- reg: Contains the wkup_m3 register address ranges for
+ umem and dmem, from the devices address space.
+ NOTE: Parent node must contains ranges specifying
+ mapping from bus address space to device
+ address space.
+- ti,hwmods: Name of the hwmod associated with the mailbox
+- ti,pm-firmware: Name of firmware file to load for remoteproc.
+
+Example:
+
+/* AM33xx */
+soc {
+compatible = "ti,omap-infra";
+#address-cells = <1>;
+#size-cells = <1>;
+ranges = <0x0 0x44d0 0x4000>,
+ <0x8 0x44d8 0x2000>;
+
+ ...
+
+ wkup_m3: wkup_m3@44d0 {
+ compatible = "ti,am3353-wkup-m3";
+ reg = <0x0 0x4000 /* M3 UMEM */
+ 0x8 0x2000>; /* M3 DMEM */
+ ti,hwmods = "wkup_m3";
+ ti,pm-firmware = "am335x-pm-firmware.elf";
+ };
+};
--
2.3.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/3] remoteproc: add a rproc ops for performing address translation
From: Suman Anna
The rproc_da_to_va API is currently used to perform any device to
kernel address translations to meet the different needs of the remoteproc
core/drivers (eg: loading). The functionality is achieved within the
remoteproc core, and is limited only for carveouts allocated within the
core.
A new rproc ops, da_to_va, is added to provide flexibility to platform
implementations to perform the address translation themselves when the
above conditions cannot be met by the implementations. The rproc_da_to_va()
API is extended to invoke this ops if present, and fallback to regular
processing if the platform implementation cannot provide the translation.
This will allow any remoteproc implementations to translate addresses for
dedicated memories like internal memories, and facilitate the remoteproc
core to also load certain firmware sections into internal memories (eg:
RAM at L1 or L2 levels) for performance or other reasons.
While at this, also update the rproc_da_to_va() documentation since it
is an exported function.
Signed-off-by: Suman Anna
Signed-off-by: Dave Gerlach
---
This patch is a replacement for the patch ("remoteproc: add support to
handle internal memories") @ https://patchwork.kernel.org/patch/5602981/
The representation of internal memory regions is left to the individual
platform implementations, as this might vary from one to another.
drivers/remoteproc/remoteproc_core.c | 31 +--
include/linux/remoteproc.h | 2 ++
2 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 3cd85a63..e9825bd 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -147,28 +147,46 @@ static void rproc_disable_iommu(struct rproc *rproc)
return;
}
-/*
+/**
+ * rproc_da_to_va() - lookup the kernel virtual address for a remoteproc
address
+ * @rproc: handle of a remote processor
+ * @da: remoteproc device address to translate
+ * @len: length of the memory region @da is pointing to
+ *
* Some remote processors will ask us to allocate them physically contiguous
* memory regions (which we call "carveouts"), and map them to specific
- * device addresses (which are hardcoded in the firmware).
+ * device addresses (which are hardcoded in the firmware). They may also have
+ * dedicated memory regions internal to the processors, and use them either
+ * exclusively or alongside carveouts.
*
* They may then ask us to copy objects into specific device addresses (e.g.
* code/data sections) or expose us certain symbols in other device address
* (e.g. their trace buffer).
*
- * This function is an internal helper with which we can go over the allocated
- * carveouts and translate specific device address to kernel virtual addresses
- * so we can access the referenced memory.
+ * This function is a helper function with which we can go over the allocated
+ * carveouts and translate specific device addresses to kernel virtual
addresses
+ * so we can access the referenced memory. This function also allows to perform
+ * translations on the internal remoteproc memory regions through a platform
+ * implementation specific da_to_va ops, if present.
+ *
+ * The function returns a valid kernel address on success or NULL on failure.
*
* Note: phys_to_virt(iommu_iova_to_phys(rproc->domain, da)) will work too,
* but only on kernel direct mapped RAM memory. Instead, we're just using
- * here the output of the DMA API, which should be more correct.
+ * here the output of the DMA API for the carveouts, which should be more
+ * correct.
*/
void *rproc_da_to_va(struct rproc *rproc, u64 da, int len)
{
struct rproc_mem_entry *carveout;
void *ptr = NULL;
+ if (rproc->ops->da_to_va) {
+ ptr = rproc->ops->da_to_va(rproc, da, len);
+ if (ptr)
+ goto out;
+ }
+
list_for_each_entry(carveout, >carveouts, node) {
int offset = da - carveout->da;
@@ -185,6 +203,7 @@ void *rproc_da_to_va(struct rproc *rproc, u64 da, int len)
break;
}
+out:
return ptr;
}
EXPORT_SYMBOL(rproc_da_to_va);
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index 9e7e745..e0c0715 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -330,11 +330,13 @@ struct rproc;
* @start: power on the device and boot it
* @stop: power off the device
* @kick: kick a virtqueue (virtqueue id given as a parameter)
+ * @da_to_va: optional platform hook to perform address translations
*/
struct rproc_ops {
int (*start)(struct rproc *rproc);
int (*stop)(struct rproc *rproc);
void (*kick)(struct rproc *rproc, int vqid);
+ void * (*da_to_va)(struct rproc *rproc, u64 da, int len);
};
/**
--
2.3.0
--
To unsubscribe from this list: send the line
RE: [PATCH v5] modify the IO_TLB_SEGSIZE and IO_TLB_DEFAULT_SIZE configurable as flexible requirement about SW-IOMMU.
> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: Thursday, March 5, 2015 3:43 AM
> To: Wang, Xiaoming
> Cc: ch...@chris-wilson.co.uk; david.vra...@citrix.com;
> lau...@codeaurora.org; heiko.carst...@de.ibm.com; li...@horizon.com;
> l...@aserp2030.oracle.com; Liu, Chuansheng; zh...@aserp2030.oracle.com;
> Zhang, Dongxing; takahiro.aka...@linaro.org; a...@linux-foundation.org;
> linux-m...@linux-mips.org; r...@linux-mips.org; xen-
> de...@lists.xenproject.org; boris.ostrov...@oracle.com;
> d.kasat...@samsung.com; pebo...@tiscali.nl; linux-kernel@vger.kernel.org;
> jbeul...@suse.com
> Subject: Re: [PATCH v5] modify the IO_TLB_SEGSIZE and
> IO_TLB_DEFAULT_SIZE configurable as flexible requirement about SW-
> IOMMU.
>
> On Tue, Mar 03, 2015 at 04:11:09PM +0800, Wang Xiaoming wrote:
> > The maximum of SW-IOMMU is limited to 2^11*128 = 256K.
> > And the size of IO_TLB_DEFAULT_SIZE is limited to (64UL<<20) 64M now.
> > While in different platform and different requirement this seems improper.
> > So modifing the IO_TLB_SEGSIZE to io_tlb_segsize and
> > IO_TLB_DEFAULT_SIZE to io_tlb_default_size which can configure by
> kernel cmdline.
> > This can meet different requirement.
> >
> > Signed-off-by: Chuansheng Liu
> > Signed-off-by: Zhang Dongxing
> > Signed-off-by: Wang Xiaoming
> > ---
> > patch v1 make this change at Kconfig
> > which needs to edit the .config manually.
> > https://lkml.org/lkml/2015/1/25/571
> >
> > patch v2 only change IO_TLB_SEGSIZE configurable.
> > https://lkml.org/lkml/2015/2/5/812
> >
> > patch v3 parsing io_tlb_segsize and
> > io_tlb_default_size independently.
> > https://lkml.org/lkml/2015/2/15/217
> >
> > patch v4 hasn't validated the data from command line.
>
> Thank you for redoing this per review.
>
> > https://lkml.org/lkml/2015/2/17/114
> >
> > Documentation/kernel-parameters.txt |9 -
> > arch/mips/cavium-octeon/dma-octeon.c |2 +-
> > arch/mips/netlogic/common/nlm-dma.c |2 +-
> > drivers/xen/swiotlb-xen.c|6 +--
> > include/linux/swiotlb.h |8 +---
> > lib/swiotlb.c| 68
> > +-
> > 6 files changed, 65 insertions(+), 30 deletions(-)
> >
> > diff --git a/Documentation/kernel-parameters.txt
> > b/Documentation/kernel-parameters.txt
> > index 4df73da..1f50e86 100644
> > --- a/Documentation/kernel-parameters.txt
> > +++ b/Documentation/kernel-parameters.txt
> > @@ -3438,10 +3438,17 @@ bytes respectively. Such letter suffixes can
> also be entirely omitted.
> > it if 0 is given (See
> Documentation/cgroups/memory.txt)
> >
> > swiotlb=[ARM,IA-64,PPC,MIPS,X86]
> > - Format: { | force }
> > + Format: { | force | | }
> ,
>
> s/|/,/
>
How about change the Format to
Format: { ,force,,}
Force the parameter input in consecutive order.
> > -- Number of I/O TLB slabs
> > force -- force using of bounce buffers even if they
> > wouldn't be automatically used by the kernel
> > +-- Maximum allowable number of contiguous
> slabs to map
> > +-- The size of SW-MMU mapped.
> > + Using "," to separate them one by one.
>
> "Use ',' to seperate them."
>
> > + Example:
> > + BOARD_KERNEL_CMDLINE +=
> swiotlb=32768,force,512,268435456
> > + io_tlb_nslabs=32768, swiotlb_force=1,
> > + io_tlb_segsize=512, io_tlb_default_size=268435456
>
> I think you can remove the example - and just have it in the C code.
>
> >
> > switches= [HW,M68k]
> >
> > diff --git a/arch/mips/cavium-octeon/dma-octeon.c
> > b/arch/mips/cavium-octeon/dma-octeon.c
> > index 3778655..a521af6 100644
> > --- a/arch/mips/cavium-octeon/dma-octeon.c
> > +++ b/arch/mips/cavium-octeon/dma-octeon.c
> > @@ -312,7 +312,7 @@ void __init plat_swiotlb_setup(void)
> > swiotlbsize = 64 * (1<<20);
> > #endif
> > swiotlb_nslabs = swiotlbsize >> IO_TLB_SHIFT;
> > - swiotlb_nslabs = ALIGN(swiotlb_nslabs, IO_TLB_SEGSIZE);
> > + swiotlb_nslabs = ALIGN(swiotlb_nslabs, io_tlb_segsize);
> > swiotlbsize = swiotlb_nslabs << IO_TLB_SHIFT;
> >
> > octeon_swiotlb = alloc_bootmem_low_pages(swiotlbsize);
> > diff --git a/arch/mips/netlogic/common/nlm-dma.c
> > b/arch/mips/netlogic/common/nlm-dma.c
> > index f3d4ae8..eeffa8f 100644
> > --- a/arch/mips/netlogic/common/nlm-dma.c
> > +++ b/arch/mips/netlogic/common/nlm-dma.c
> > @@ -99,7 +99,7 @@ void __init plat_swiotlb_setup(void)
> >
> > swiotlbsize = 1 << 20; /* 1 MB for now */
> > swiotlb_nslabs = swiotlbsize >> IO_TLB_SHIFT;
> > - swiotlb_nslabs = ALIGN(swiotlb_nslabs, IO_TLB_SEGSIZE);
> > + swiotlb_nslabs = ALIGN(swiotlb_nslabs, io_tlb_segsize);
Re: [PATCH v3 0/3] epoll: introduce round robin wakeup mode
On 03/04/2015 07:02 PM, Ingo Molnar wrote: > * Andrew Morton wrote: > >> On Fri, 27 Feb 2015 17:01:32 -0500 Jason Baron wrote: >> I don't really understand the need for rotation/round-robin. We can solve the thundering herd via exclusive wakeups, but what is the point in choosing to wake the task which has been sleeping for the longest time? Why is that better than waking the task which has been sleeping for the *least* time? That's probably faster as that task's data is more likely to still be in cache. The changelogs talks about "starvation" but they don't really say what this term means in this context, nor why it is a bad thing. >> I'm still not getting it. >> >>> So the idea with the 'rotation' is to try and distribute the >>> workload more evenly across the worker threads. >> Why? >> >>> We currently >>> tend to wake up the 'head' of the queue over and over and >>> thus the workload for us is not evenly distributed. >> What's wrong with that? >> >>> In fact, we >>> have a workload where we have to remove all the epoll sets >>> and then re-add them in a different order to improve the situation. >> Why? > So my guess would be (but Jason would know this more precisely) that > spreading the workload to more tasks in a FIFO manner, the individual > tasks can move between CPUs better, and fill in available CPU > bandwidth better, increasing concurrency. > > With the current LIFO distribution of wakeups, the 'busiest' threads > will get many wakeups (potentially from different CPUs), making them > cache-hot, which may interfere with them easily migrating across CPUs. > > So while technically both approaches have similar concurrency, the > more 'spread out' task hierarchy schedules in a more consistent > manner. > > But ... this is just a wild guess and even if my description is > accurate then it should still be backed by robust measurements and > observations, before we extend the ABI. > > This hypothesis could be tested by the patch below: with the patch > applied if the performance difference between FIFO and LIFO epoll > wakeups disappears, then the root cause is the cache-hotness code in > the scheduler. > > So what I think you are describing here fits the model where you have single epoll fd (returned by epoll_create()), which is then attached to wakeup fds. So that can be thought of as having a single 'event' queue (the single epoll fd), where multiple threads are competing to grab events via epoll_wait() and things are currently LIFO there as you describe. However, the use-case I was trying to get at is where you have multiple epoll fds (or event queues), and really just one thread doing epoll_wait() against a single epoll fd. So instead of having all threads competing for all events, we have divided up the events into separate queues. Now, the 'problematic' case is where there may be an event source that is shared among all these epoll fds - such as a listen socket or a pipe. Now there are two distinct issues in this case that this series is trying to address. 1) All epoll fds will receive a wakeup (and hence the threads that are potentially blocking there, although they may not return to user-space if the event has already been consumed). I think the test case I posted shows this pretty clearly - http://lwn.net/Articles/632590/. The number of context switches without adding the to the wait queue is 50x the case where they are added exclusively. That's a lot of extra cpu usage. 2) We are using the wakeup in this case to 'assign' work more permanently to the thread. That is, in the case of a listen socket we then add the connected socket to the woken up threads local set of epoll events. So the load persists past the wake up. And in this case, doing the round robin wakeups, simply allows us to access more cpu bandwidth. (I'm also looking into potentially using cpu affinity to do the wakeups as well as you suggested.) Thanks, -Jason -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Mar 5
Hi all, Changes since 20150304: The net-next tree gained a build failure for which I applied a patch. The md tree lost its build failure. The mfd tree lost its build failure. The clk tree lost its build failure. Non-merge commits (relative to Linus' tree): 2570 2666 files changed, 81615 insertions(+), 57368 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 207 trees (counting Linus' and 30 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (6587457b4b3d Merge tag 'dma-buf-for-4.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf) Merging fixes/master (b94d525e58dc Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging kbuild-current/rc-fixes (c517d838eb7d Linux 4.0-rc1) Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4) Merging arm-current/fixes (23be7fdafa50 ARM: 8305/1: DMA: Fix kzalloc flags in __iommu_alloc_buffer()) Merging m68k-current/for-linus (4436820a98cd m68k/defconfig: Enable Ethernet bridging) Merging metag-fixes/fixes (c2996cb29bfb metag: Fix KSTK_EIP() and KSTK_ESP() macros) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-merge/merge (c517d838eb7d Linux 4.0-rc1) Merging powerpc-merge-mpe/fixes (4ad04e598711 powerpc/iommu: Remove IOMMU device references via bus notifier) Merging sparc/master (53eb2516972b sparc: semtimedop() unreachable due to comparison error) Merging net/master (9215f437b85d team: don't traverse port list using rcu in team_set_mac_address) Merging ipsec/master (ac37e2515c1a xfrm: release dst_orig in case of error in xfrm_lookup()) Merging sound-current/for-linus (8cdebf71098c ALSA: dice: fix wrong offsets for Dice interface) Merging pci-current/for-linus (4efe874aace5 PCI: Don't read past the end of sysfs "driver_override" buffer) Merging wireless-drivers/master (c8f034558669 rtlwifi: Improve handling of IPv6 packets) Merging driver-core.current/driver-core-linus (c517d838eb7d Linux 4.0-rc1) Merging tty.current/tty-linus (c517d838eb7d Linux 4.0-rc1) Merging usb.current/usb-linus (b20b1618b8fc cdc-acm: Add support for Denso cradle CU-321) Merging usb-gadget-fixes/fixes (a0456399fb07 usb: gadget: configfs: don't NUL-terminate (sub)compatible ids) Merging usb-serial-fixes/usb-linus (c7d373c3f0da usb: ftdi_sio: Add jtag quirk support for Cyber Cortex AV boards) Merging staging.current/staging-linus (abe46b8932dd staging: comedi: adv_pci1710: fix AI INSN_READ for non-zero channel) Merging char-misc.current/char-misc-linus (6c15a8516b81 mei: make device disabled on stop unconditionally) Merging input-current/for-linus (4a6155a46565 Input: sun4i-ts - add thermal driver dependency) Merging crypto-current/master (001eabfd54c0 crypto: arm/aes update NEON AES module to latest OpenSSL version) Merging ide/master (f96fe225677b Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging devicetree-current/devicetree/merge (6b1271de3723 of/unittest: Overlays with sub-devices tests) Merging rr-fixes/fixes (f47689345931 lguest: update help text.) Merging vfio-fixes/for-linus (7c2e211f3c95 vfio-pci: Fix the check on pci device type in vfio_pci_probe()) Merging kselftest-fixes/fixes (f5db310d77ef selftests/vm: fix link error for transhuge-stress test) Merging drm-intel-fixes/for-linux-next-fixes (ab3be73fa7b4 drm/i915: gen4: work around hang during hibernation) Merging asm-generic/master (643165c8bbc8 Merge tag
Re: [PATCH v2 1/4] cpufreq-dt: add clock domain and intermediate frequency support
Hi Viresh,
Thanks for reviewing. Please see my reply below:
On 4 March 2015 at 18:15, Viresh Kumar wrote:
> On 4 March 2015 at 14:19, pi-cheng.chen wrote:
>> In this patch, CPU clock/power domain information is added into the
>> platform_data of cpufreq-dt so that cpufreq-dt driver could check with CPUs
>> share clock/power. Also, intermediate frequency support is added in this
>
> You should have separate patches for logically separate changes.
Sure. Will do it.
>
>> version. Since the program flows of .target_index and .target_intermediate
>> are quite similar, consolidate the flow as a new function to keep
>> readibility.
>>
>> Signed-off-by: pi-cheng.chen
>> ---
>> drivers/cpufreq/cpufreq-dt.c | 68
>> +++-
>> include/linux/cpufreq-dt.h | 7 +
>> 2 files changed, 68 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
>> index bab67db..5948bdf 100644
>> --- a/drivers/cpufreq/cpufreq-dt.c
>> +++ b/drivers/cpufreq/cpufreq-dt.c
>> @@ -34,25 +34,37 @@ struct private_data {
>> struct regulator *cpu_reg;
>> struct thermal_cooling_device *cdev;
>> unsigned int voltage_tolerance; /* in percentage */
>> + unsigned long intermediate_freq;
>> };
>>
>> -static int set_target(struct cpufreq_policy *policy, unsigned int index)
>> +static unsigned int get_intermediate(struct cpufreq_policy *policy,
>> +unsigned int index)
>> +{
>> + struct private_data *priv = policy->driver_data;
>> + struct cpufreq_frequency_table *freq_table;
>> + unsigned long freq = clk_get_rate(policy->clk);
>
> This will return current freq, which can also be fetched with
> policy->cur.
Will fix it.
>
>> +
>> + freq_table = cpufreq_frequency_get_table(policy->cpu);
>
> instead, freq_table = policy->freq_table.
Will fix it.
>
>> +
>
> Always add a comment over such decision making expressions, on
> why you chose to return 0.
Will fix it.
>
>> + if (freq == priv->intermediate_freq ||
>
> Looks fine, current freq == intermediate freq..
>
>> + freq_table[index].frequency * 1000 == freq)
>
> Absolutely wrong, current-freq == requested-freq.
> Instead it should be:
>
> freq_table[index].frequency * 1000 == priv->intermediate_freq.
>
Thanks for correcting. Will fix it.
>> + return 0;
>> +
>> + return priv->intermediate_freq;
>> +}
>> +
>> +static int set_frequency(struct cpufreq_policy *policy, long freq_Hz)
>> {
>> struct dev_pm_opp *opp;
>> - struct cpufreq_frequency_table *freq_table = policy->freq_table;
>> struct clk *cpu_clk = policy->clk;
>> struct private_data *priv = policy->driver_data;
>> struct device *cpu_dev = priv->cpu_dev;
>> struct regulator *cpu_reg = priv->cpu_reg;
>> unsigned long volt = 0, volt_old = 0, tol = 0;
>> unsigned int old_freq, new_freq;
>> - long freq_Hz, freq_exact;
>> + long freq_exact;
>> int ret;
>>
>> - freq_Hz = clk_round_rate(cpu_clk, freq_table[index].frequency *
>> 1000);
>> - if (freq_Hz <= 0)
>> - freq_Hz = freq_table[index].frequency * 1000;
>> -
>> freq_exact = freq_Hz;
>> new_freq = freq_Hz / 1000;
>> old_freq = clk_get_rate(cpu_clk) / 1000;
>> @@ -112,6 +124,29 @@ static int set_target(struct cpufreq_policy *policy,
>> unsigned int index)
>> return ret;
>> }
>>
>> +static int target_intermediate(struct cpufreq_policy *policy,
>> + unsigned int index)
>> +{
>> + struct private_data *priv = policy->driver_data;
>> + long freq_Hz;
>> +
>> + freq_Hz = priv->intermediate_freq;
>> + return set_frequency(policy, freq_Hz);
>
> Instead, return set_frequency(policy, priv->intermediate_freq);
Will fix it.
>
>> +}
>> +
>> +static int set_target(struct cpufreq_policy *policy, unsigned int index)
>> +{
>> + struct cpufreq_frequency_table *freq_table = policy->freq_table;
>> + struct clk *cpu_clk = policy->clk;
>> + long freq_Hz;
>> +
>> + freq_Hz = clk_round_rate(cpu_clk, freq_table[index].frequency *
>> 1000);
>
> Use policy->clk here directly instead of another local variable.
Will fix it.
>
>> + if (freq_Hz <= 0)
>> + freq_Hz = freq_table[index].frequency * 1000;
>
> Why shouldn't we call clk_round_rate() for intermediate freq as well ?
Yes. Will do it.
> I think, it
> should be called for it as well.. And so you can save intermediate_freq_index
> instead of the freq..
>
Here is the case I wanted to talk to you at HKG15:
In the case of Mediatek SoC, the intermediate frequency might not be one entry
of OPP table. To elaborate, the source clock node of the CPUs/Cluster on
Mediatek SoC is a mux. The mux has several PLLs as parents. When we are
doing CPU frequency scaling, the mux should re-parent to another stable PLL,
wait until
Re: [PATCH v2 04/15] x86, kaslr: get kaslr_enabled back correctly
On Wed, Mar 4, 2015 at 6:58 PM, joeyli wrote: > > After 84c91b7ae merged to v3.17 kernel, hibernate code checks the e280 regions > should not be changed when doing hibernate resume. Without your patch 8, > the hibernate resume checking will randomly fail on the machines that reserved > setup_data in e820 regions. > > Could you please consider to put "[PATCH v2 08/15] x86: Kill > E820_RESERVED_KERN" > to v4.0 kernel? That will trigger SETUP_PCI ioremap warning. That is the reason I want to put it with other setup_data fix. Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Hello
Hi, Happy New Year, Am Miss Noleta Voss, I will so much appreciate your kind reply for i have some thing very important to talk with you...kindly reply me Yours Noleta Voss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 04/15] x86, kaslr: get kaslr_enabled back correctly
Hi Yinghai, On Wed, Mar 04, 2015 at 10:12:58AM -0800, Yinghai Lu wrote: > On Wed, Mar 4, 2015 at 7:54 AM, Jiri Kosina wrote: > > > > > Also this 15-patch series needs to be separated into two patchsets. The > > whole series is not appropriate for -rc3, but this particular one at least > > is a regression fix that has to go in. > > The first 4 should go v4.0. > > could leave others to v4.1 > > Thanks > > Yinghai After 84c91b7ae merged to v3.17 kernel, hibernate code checks the e280 regions should not be changed when doing hibernate resume. Without your patch 8, the hibernate resume checking will randomly fail on the machines that reserved setup_data in e820 regions. Could you please consider to put "[PATCH v2 08/15] x86: Kill E820_RESERVED_KERN" to v4.0 kernel? Thanks a lot! Joey Lee -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
